diff --git a/fr-ca/articles/_includes/_api-auth-customize-tokens.md b/fr-ca/articles/_includes/_api-auth-customize-tokens.md new file mode 100644 index 0000000000..0c5ca2a2e3 --- /dev/null +++ b/fr-ca/articles/_includes/_api-auth-customize-tokens.md @@ -0,0 +1,19 @@ +You can use [Rules](/rules) to change the returned scopes of the Access Token and/or add claims to it (and the ID Token) with a script like this: + +```javascript +function(user, context, callback) { + + // add custom claims to Access Token and ID Token + context.accessToken['http://foo/bar'] = 'value'; + context.idToken['http://fiz/baz'] = 'some other value'; + + // change scope + context.accessToken.scope = ['array', 'of', 'strings']; + + callback(null, user, context); +} +``` + +::: panel-warning Namespacing Custom Claims +Auth0 returns profile information in a [structured claim format as defined by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. You can [add namespaced claims using Rules](#optional-customize-the-tokens). +::: diff --git a/fr-ca/articles/_includes/_api_auth_intro.md b/fr-ca/articles/_includes/_api_auth_intro.md new file mode 100644 index 0000000000..aab96af74d --- /dev/null +++ b/fr-ca/articles/_includes/_api_auth_intro.md @@ -0,0 +1,3 @@ +::: note +**New to Auth0?** Learn [how Auth0 works](/overview) and read about [implementing API authentication and authorization ](/api-auth) using the OAuth 2.0 framework. +::: diff --git a/fr-ca/articles/_includes/_boxed.html b/fr-ca/articles/_includes/_boxed.html new file mode 100644 index 0000000000..e54755dc57 --- /dev/null +++ b/fr-ca/articles/_includes/_boxed.html @@ -0,0 +1,17 @@ +
+

+ + Logs + +

+ +

Your current subscription allows to keep your logs for the last 30 days.

+
diff --git a/fr-ca/articles/_includes/_callback_url.md b/fr-ca/articles/_includes/_callback_url.md new file mode 100644 index 0000000000..bd1ad7a23c --- /dev/null +++ b/fr-ca/articles/_includes/_callback_url.md @@ -0,0 +1,5 @@ + + +### Configure Callback URLs + +A callback URL is a URL in your application where Auth0 redirects the user after they have authenticated. The callback URL for your app must be added to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications). If this field is not set, users will be unable to log in to the application and will get an error. diff --git a/fr-ca/articles/_includes/_calling_apis.md b/fr-ca/articles/_includes/_calling_apis.md new file mode 100644 index 0000000000..ba355371bf --- /dev/null +++ b/fr-ca/articles/_includes/_calling_apis.md @@ -0,0 +1 @@ +A common need for any client-side application is to access resources from a data API. Some of these data resources will likely need to be protected such that only the user who is authenticated in the client-side app can access them. This can be achieved by protecting your API's endpoints with your Auth0 secret key and sending the user's JWT as an `Authorization` header when calling the API. For more detail on how to secure your API, see the [server API documentation](/quickstart/backend). \ No newline at end of file diff --git a/fr-ca/articles/_includes/_checksession_polling.md b/fr-ca/articles/_includes/_checksession_polling.md new file mode 100644 index 0000000000..9030fb5770 --- /dev/null +++ b/fr-ca/articles/_includes/_checksession_polling.md @@ -0,0 +1,3 @@ +In some multi-application scenarios, where Single Logout is desired (a user logging out of one application needs to be logged out of other applications), an application can be set up to periodically poll Auth0 using `checkSession()` to see if a session exists. If the session does not exist, you can then log the user out of the application. The same polling method can be used to implement silent authentication for a Single Sign-on (SSO) scenario. + +The poll interval between checks to `checkSession()` should be at least 15 minutes between calls to avoid any issues in the future with rate limiting of this call. diff --git a/fr-ca/articles/_includes/_co_authenticate_errors.md b/fr-ca/articles/_includes/_co_authenticate_errors.md new file mode 100644 index 0000000000..af87d27465 --- /dev/null +++ b/fr-ca/articles/_includes/_co_authenticate_errors.md @@ -0,0 +1,26 @@ +## Error Codes and Descriptions + +When ${library} is used for embedded login, it employs the /co/authenticate endpoint, which has the following errors. + +::: warning +The error description is human readable. It **should not be parsed by any code** and it subject to change at any time. +::: + +| Status | Code | Description | +| --- | --- | --- | --- | +| 400 | invalid_request | Invalid request body. All and only of client_id, credential_type, username, otp, realm are required. | +| 401 | unauthorized_client | Cross origin login not allowed. | +| 400 | unsupported_credential_type | Unknown credential type parameter. | +| 400 | invalid_request | Unknown realm non-existent-connection. | +| 403 | access_denied | Wrong email or password. | +| 403 | access_denied | Authentication error | +| 403 | blocked_user | Blocked user | +| 401 | password_leaked | This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application). | +| 429 | too_many_attempts | Your account has been blocked after multiple consecutive login attempts. We’ve sent you an email with instructions on how to unblock it. | +| 429 | too_many_attempts | We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator. | + +In addition, you can also get a generic 403 error without an `error` or `error_description` property. The response body would just include something similar to the following: + +```text +Origin https://test.app is not allowed. +``` diff --git a/fr-ca/articles/_includes/_compat_warning.md b/fr-ca/articles/_includes/_compat_warning.md new file mode 100644 index 0000000000..2209899342 --- /dev/null +++ b/fr-ca/articles/_includes/_compat_warning.md @@ -0,0 +1,3 @@ +::: panel-warning Compatibility Warning +With the new OAuth 2.0 API Authorization features in Auth0, not everything is fully backwards compatible, including 3rd party hosted Lock. This quickstart tutorial uses Auth0 hosted Lock instead. +::: diff --git a/fr-ca/articles/_includes/_contact-sales.md b/fr-ca/articles/_includes/_contact-sales.md new file mode 100644 index 0000000000..b5a08e1e82 --- /dev/null +++ b/fr-ca/articles/_includes/_contact-sales.md @@ -0,0 +1,3 @@ +## More Information + +If you have specific support requirements or need more information about the Professional Services we offer, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales). diff --git a/fr-ca/articles/_includes/_create_resource_server.md b/fr-ca/articles/_includes/_create_resource_server.md new file mode 100644 index 0000000000..e879837b6a --- /dev/null +++ b/fr-ca/articles/_includes/_create_resource_server.md @@ -0,0 +1,50 @@ +## Create the API + +Your resource server (API) needs to be configured to verify the Access Token and any claims contained within it. When you create a resource server in your Auth0 dashboard, it utilizes the RS256 signature method by default, meaning that Access Tokens are signed using Auth0's private key for your account. Verification is done using the corresponding public key. You can read more about the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) standard and also view the [public key(s)](https://${account.namespace}/.well-known/jwks.json) for your Auth0 account (https://${account.namespace}/.well-known/jwks.json). You can also learn how to [manage your signing keys](/tokens/guides/manage-signing-keys). + +You can use any [recommended JWT library](https://jwt.io) to validate the standard claims returned in the token. The following example will demonstrate how to create a resource server API with Node. You can find more information about resource server implementations in the [Access Token documentation](https://auth0.com/docs/api-auth/config/asking-for-access-tokens). + +The Access Token for your API must be verified against your JSON Web Key Set (JWKS) endpoint. This can be done easily with the **jwks-rsa** library available on npm. + +Install the dependencies. + +```bash +npm install express express-jwt jwks-rsa +``` + +Create a middleware which uses **express-jwt** and **jwks-rsa** to verify the Access Token against your JWKS endpoint. + +```js +const express = require('express'); +const app = express(); +const jwt = require('express-jwt'); +const jwksRsa = require('jwks-rsa'); + +const authenticate = jwt({ + // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint. + secret: jwksRsa.expressJwtSecret({ + cache: true, + rateLimit: true, + jwksRequestsPerMinute: 5, + jwksUri: 'https://${account.namespace}/.well-known/jwks.json' + }), + + // Validate the audience and the issuer. + audience: '{API IDENTIFIER}', + issuer: 'https://${account.namespace}/', + algorithms: ['RS256'] +}); + +app.get('/api/public', function(req, res) { + res.json({ message: "Hello from a public endpoint! You don't need to be authenticated to see this." }); +}); + +app.get('/api/private', authenticate, function(req, res) { + res.json({ message: "Hello from a private endpoint! You DO need to be authenticated to see this." }); +}); + +app.listen(3001); +console.log('Listening on http://localhost:3001'); +``` + +Note that you **must** provide the `audience` for your API. This is the identifier you set for it when you create an API in your Auth0 dashboard. diff --git a/fr-ca/articles/_includes/_deprecate-delegation.md b/fr-ca/articles/_includes/_deprecate-delegation.md new file mode 100644 index 0000000000..7317d51f14 --- /dev/null +++ b/fr-ca/articles/_includes/_deprecate-delegation.md @@ -0,0 +1,3 @@ +::: warning +By default, delegation is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_deprecate-impersonation.md b/fr-ca/articles/_includes/_deprecate-impersonation.md new file mode 100644 index 0000000000..4f58b1bb31 --- /dev/null +++ b/fr-ca/articles/_includes/_deprecate-impersonation.md @@ -0,0 +1,3 @@ +::: warning +Impersonation has been deprecated and will not be enabled for new customers. The functionality will continue to work for existing customers who currently have it enabled. If at some point the impersonation feature is changed or removed from service, customers who currently use it will be notified beforehand and given ample time to migrate. +::: diff --git a/fr-ca/articles/_includes/_email-domain-blacklist.md b/fr-ca/articles/_includes/_email-domain-blacklist.md new file mode 100644 index 0000000000..1fdcdd1fc2 --- /dev/null +++ b/fr-ca/articles/_includes/_email-domain-blacklist.md @@ -0,0 +1,3 @@ +::: warning +Auth0 blacklists certain "false" domains commonly used during testing. Use real email addresses to avoid disruption or `domain is blacklisted` errors. +::: diff --git a/fr-ca/articles/_includes/_embedded_login_warning.md b/fr-ca/articles/_includes/_embedded_login_warning.md new file mode 100644 index 0000000000..f37d242c2d --- /dev/null +++ b/fr-ca/articles/_includes/_embedded_login_warning.md @@ -0,0 +1,3 @@ +::: warning +Embedded login for web uses Cross Origin Authentication. In some browsers [this can be unreliable](/cross-origin-authentication#limitations) if you do not set up a [Custom Domain](/custom-domains) **and host your app on the same domain**. Using Custom Domains with Auth0 is a paid feature. If you cannot use Custom Domains, consider [migrating to Universal Login](/guides/login/migration-embedded-universal). +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_enable-third-party-apps-info.md b/fr-ca/articles/_includes/_enable-third-party-apps-info.md new file mode 100644 index 0000000000..e540021871 --- /dev/null +++ b/fr-ca/articles/_includes/_enable-third-party-apps-info.md @@ -0,0 +1,3 @@ +::: note +To use this feature, you must [enable third-party applications for your Auth0 tenant](/applications/guides/enable-third-party-apps). +::: diff --git a/fr-ca/articles/_includes/_enforce-claim-namespacing.md b/fr-ca/articles/_includes/_enforce-claim-namespacing.md new file mode 100644 index 0000000000..3b593d6ccf --- /dev/null +++ b/fr-ca/articles/_includes/_enforce-claim-namespacing.md @@ -0,0 +1,5 @@ +::: warning +By default, Auth0 always enforces namespacing; any custom claims with non-namespaced identifiers will be silently excluded from tokens. + +We do allow non-OIDC claims without a namespace for legacy tenants using a non-OIDC-conformant pipeline with the **Legacy User Profile** enabled, but we strongly recommend that legacy tenants migrate to an OIDC-conformant flow. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_http-method.html b/fr-ca/articles/_includes/_http-method.html new file mode 100644 index 0000000000..cacd38d8f0 --- /dev/null +++ b/fr-ca/articles/_includes/_http-method.html @@ -0,0 +1,4 @@ +

+ ${http_method} + ${path} +

\ No newline at end of file diff --git a/fr-ca/articles/_includes/_ip_whitelist.md b/fr-ca/articles/_includes/_ip_whitelist.md new file mode 100644 index 0000000000..a3d9ad21b8 --- /dev/null +++ b/fr-ca/articles/_includes/_ip_whitelist.md @@ -0,0 +1,3 @@ +::: note Network Firewall +If you are behind a firewall, this feature may require [whitelisting of the appropriate Auth0 IP addresses](/guides/ip-whitelist) to work properly. +::: diff --git a/fr-ca/articles/_includes/_java_new_app.html b/fr-ca/articles/_includes/_java_new_app.html new file mode 100644 index 0000000000..ddfef608da --- /dev/null +++ b/fr-ca/articles/_includes/_java_new_app.html @@ -0,0 +1,7 @@ +<% if (account.userName) { %> +

Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store them somewhere safe. You will need them while configuring your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.

+<% } else { %> +

Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start by downloading the sample after you login as it is configured with your Default App credentials

+<% } %> +

Make sure that your Auth0 Application has one or more connections configured, for example, Google Social Connection, or username-password DB connection. +

diff --git a/fr-ca/articles/_includes/_libraries_support_frameworks.html b/fr-ca/articles/_includes/_libraries_support_frameworks.html new file mode 100644 index 0000000000..b14527fae5 --- /dev/null +++ b/fr-ca/articles/_includes/_libraries_support_frameworks.html @@ -0,0 +1,41 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SDKVersionLevel of Support
Angular Auth0v2
Supported
Angular Lockv2
Supported
Auth0 Servletv3
Supported
Auth0 Java MVC Commonv1
Supported
OIDC Client for .NET Desktop and Mobile applicationsv1
Supported
JWT Auth Bundlev3
Supported
diff --git a/fr-ca/articles/_includes/_libraries_support_lock.html b/fr-ca/articles/_includes/_libraries_support_lock.html new file mode 100644 index 0000000000..b23b2b155f --- /dev/null +++ b/fr-ca/articles/_includes/_libraries_support_lock.html @@ -0,0 +1,36 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibraryVersionLevel of Support
Lock.jsv11
Supported
Lock.Androidv2
Supported
Lock.Androidv1
Bug fixes
Lock for iOS v2v2
Supported
Lock for iOS v1v1
Bug fixes
diff --git a/fr-ca/articles/_includes/_libraries_support_sdks.html b/fr-ca/articles/_includes/_libraries_support_sdks.html new file mode 100644 index 0000000000..9fae1bad76 --- /dev/null +++ b/fr-ca/articles/_includes/_libraries_support_sdks.html @@ -0,0 +1,61 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SDKVersionLevel of Support
Auth0 Single Page Application SDKv1
Supported
Auth0 React SDKv1
Supported
Auth0.jsv9
Supported
Auth0 Androidv1
Supported
Auth0 Swiftv1
Supported
Auth0 .NETv4
Supported
Auth0 Javav1
Supported
Auth0 Nodev2
Supported
Auth0 Pythonv2
Supported
Auth0 PHPv7.3
Supported
diff --git a/fr-ca/articles/_includes/_linking_accounts.md b/fr-ca/articles/_includes/_linking_accounts.md new file mode 100644 index 0000000000..547909a2a2 --- /dev/null +++ b/fr-ca/articles/_includes/_linking_accounts.md @@ -0,0 +1,11 @@ +There may be situations when your users want to log in with multiple accounts that they own. In these cases, you may want to link these accounts together so that they are all reflected in the user's Auth0 profile. For example, if a user has signed up with an email and password (which provides very little information about them), you can ask them to link their account to an OAuth provider like Facebook or Google to gain access to their social profile. See [User Account Linking](/users/concepts/overview-user-account-linking) for details. + +## Linking Accounts + +To link accounts, call the [link a user account](/api/management/v2#!/Users/post_identities) endpoint. You will need the ID Token and `user_id` of the primary account and the ID Token of the secondary account. + +To differentiate the login from the linking login, you will need to create a second instance of `Auth0Lock` to obtain the ID Token of the secondary account. + +Since all instances of `Auth0Lock` will receive the `authenticated` event, you will need a way to determine if authentication came from the primary login or the linking login. + +You can use the `auth.params` property of the [options object](https://github.com/auth0/lock#authentication-options) of `Auth0Lock` to add a `state` property with the value `'linking'`. diff --git a/fr-ca/articles/_includes/_lock-sdk.html b/fr-ca/articles/_includes/_lock-sdk.html new file mode 100644 index 0000000000..d056c8d2da --- /dev/null +++ b/fr-ca/articles/_includes/_lock-sdk.html @@ -0,0 +1,176 @@ + +<% if (meta.path !== "articles/libraries/lock/v11") { %> +

For more information on using Lock v11 see the documentation.

+<% } %> +
+
+ +
+
+
+ 
<script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    auth: {
+      redirectUrl: '${account.callback}',
+      responseType: 'code',
+      params: {
+        scope: 'openid email' // Learn about scopes: https://auth0.com/docs/scopes
+      }
+    }
+  });
+</script>
+<button onclick="lock.show();">Login</button>
+
+
+ 
<div id="root" style="width: 320px; margin: 40px auto; padding: 10px; border-style: dashed; border-width: 1px; box-sizing: border-box;">
+    embedded area
+</div>
+<script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    container: 'root',
+    auth: {
+      redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+      responseType: 'token id_token',
+      params: {
+        scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+      }
+    }
+  });
+  lock.show();
+</script>
+
+
+ 
<script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}', {
+        allowedConnections: ['sms'],             // Should match the SMS connection name  
+        responseType: 'token id_token',
+        auth: {
+          redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+          params: {
+            scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+          }          
+        }
+      }
+  );
+
+  function open() {
+    lock.show();
+  };
+
+</script>
+<button onclick="window.open();">SMS</button>
+
+ +
+ 
<script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}', {
+    allowedConnections: ['email'],           // Should match the Email connection name, it defaults to 'email'     
+    passwordlessMethod: 'code',              // If not specified, defaults to 'code'
+    responseType: 'token id_token',
+    auth: {
+      redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+      params: {
+        scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+      }          
+    }
+  });
+
+  function open() {
+    lock.show();
+  }
+</script>
+<button onclick="window.open();">Email Code</button>
+
+
+ 
<button class="signin-google">Sign in with Google (redirect)</button><br>
+<button class="signin-google-popup">Sign in with Google (popup)</button><br>
+<br><p>--- or ---</p>
+<label>Email</label><input type="text" id="email"><br>
+<label>Password</label><input type="password" id="password"><br>
+<button class="signin-db">Sign in with Email/Password</button>
+
+<script src="${auth0js_url}"></script>
+<script src="http://code.jquery.com/jquery.js"></script>
+<script>
+  var webAuth = new auth0.WebAuth({
+    domain:         '${account.namespace}',
+    clientID:       '${account.clientId}',
+    redirectUri:    '${account.callback}'
+  });
+  // sign-in with social provider with plain redirect
+  $('.signin-google').on('click', function() {
+    webAuth.authorize({
+      connection: 'google-oauth2' // use connection identifier
+    });
+  });
+  // sign-in with social provider using a popup (window.open)
+  $('.signin-google-popup').on('click', function() {
+    webAuth.popup.authorize({
+      connection: 'google-oauth2'
+    });
+  });
+
+  $('.signin-db').on('click', function() {
+    webAuth.login({
+      realm: 'tests',
+      username: 'testuser',
+      password: 'testpass',
+    });
+  });
+  // Parse the authentication result
+  webAuth.parseHash((err, authResult) => {
+    if (authResult) {
+      // Save the tokens from the authResult in local storage or a cookie
+      localStorage.setItem('access_token', authResult.accessToken);
+      localStorage.setItem('id_token', authResult.idToken);
+    } else if (err) {
+      // Handle errors
+      console.log(err);
+    }
+  });
+</script>
+
+ +
+
diff --git a/fr-ca/articles/_includes/_lock_auth0js_deprecations_notice.md b/fr-ca/articles/_includes/_lock_auth0js_deprecations_notice.md new file mode 100644 index 0000000000..9e03f9bb98 --- /dev/null +++ b/fr-ca/articles/_includes/_lock_auth0js_deprecations_notice.md @@ -0,0 +1,3 @@ +::: panel-warning Lock and Auth0.js Deprecations +The Lock v8, v9, and v10 widgets as well as the Auth0.js v6, v7, and v8 SDKs are deprecated and should be migrated away from prior to their removal from service on July 16, 2018. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_login_auth0_hosted_login_page.md b/fr-ca/articles/_includes/_login_auth0_hosted_login_page.md new file mode 100644 index 0000000000..78c16d5875 --- /dev/null +++ b/fr-ca/articles/_includes/_login_auth0_hosted_login_page.md @@ -0,0 +1 @@ +Auth0's [Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. diff --git a/fr-ca/articles/_includes/_logout_url.md b/fr-ca/articles/_includes/_logout_url.md new file mode 100644 index 0000000000..15197d6bc0 --- /dev/null +++ b/fr-ca/articles/_includes/_logout_url.md @@ -0,0 +1,11 @@ + + +### Configure Logout URLs + +A logout URL is a URL in your application that Auth0 can return to after the user has been logged out of the authorization server. This is specified in the `returnTo` query parameter. The logout URL for your app must be added to the **Allowed Logout URLs** field in your [Application Settings](${manage_url}/#/applications). If this field is not set, users will be unable to log out from the application and will get an error. + +<% if (typeof(returnTo) !== "undefined") { %> + ::: note + If you are following along with the sample project you downloaded from the top of this page, the logout URL you need to add to the **Allowed Logout URLs** field is `${returnTo}`. + ::: +<% } %> diff --git a/fr-ca/articles/_includes/_metadata_on_signup_warning.md b/fr-ca/articles/_includes/_metadata_on_signup_warning.md new file mode 100644 index 0000000000..1af9aab000 --- /dev/null +++ b/fr-ca/articles/_includes/_metadata_on_signup_warning.md @@ -0,0 +1,3 @@ +::: note +When setting the `user_metadata` field using the Authentication API's [Signup endpoint](/api/authentication?javascript#signup), you are limited to a maximum of 10 `String` fields and 500 characters. +::: diff --git a/fr-ca/articles/_includes/_native_passwordless_warning.md b/fr-ca/articles/_includes/_native_passwordless_warning.md new file mode 100644 index 0000000000..04eaae8300 --- /dev/null +++ b/fr-ca/articles/_includes/_native_passwordless_warning.md @@ -0,0 +1,3 @@ +::: warning +This functionality has been deprecated in native. After June 2017, tenants cannot use the native passwordless flow. The functionality will continue to work for tenants that currently have it enabled. If at some point the passwordless mode feature is changed or removed from service, customers who currently use it will be notified beforehand and given ample time to migrate. +::: diff --git a/fr-ca/articles/_includes/_new_api.html b/fr-ca/articles/_includes/_new_api.html new file mode 100644 index 0000000000..924a36341f --- /dev/null +++ b/fr-ca/articles/_includes/_new_api.html @@ -0,0 +1,5 @@ +<% if (account.userName) { %> +

In the APIs section in dashboard, click the Create API button. Provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.

+<% } else { %> +

Create an Auth0 account (or login) navigate to the APIs section in Dashboard. Click the Create API button and provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.

+<% } %> \ No newline at end of file diff --git a/fr-ca/articles/_includes/_new_app.md b/fr-ca/articles/_includes/_new_app.md new file mode 100644 index 0000000000..8a8429f0cf --- /dev/null +++ b/fr-ca/articles/_includes/_new_app.md @@ -0,0 +1,28 @@ +## Configure Auth0 +### Get Your Application Keys + +When you signed up for Auth0, a new application was created for you, or you could have created a new one. You will need some details about that application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications) section in the Auth0 dashboard. + +<% if(typeof hideDashboardScreenshot === 'undefined' || hideDashboardScreenshot !== true) { %> +![App Dashboard](/media/articles/dashboard/client_settings.png) +<% } %> + +<% if(typeof isPublicClient === 'undefined' || isPublicClient === true) { %> +::: note +When using the Default App with a Native or Single Page Application, ensure to update the **Token Endpoint Authentication Method** to `None` and set the **Application Type** to either `SPA` or `Native`. +::: +<% } %> + +You need the following information: + +* **Domain** +* **Client ID** +<% if(typeof showClientSecret !== 'undefined' && showClientSecret === true) { %> +* **Client Secret** +<% } %> + +<% if(typeof hideDownloadSample === 'undefined' || hideDownloadSample !== true) { %> +::: note +If you download the sample from the top of this page, these details are filled out for you. +::: +<% } %> diff --git a/fr-ca/articles/_includes/_new_app_no_sample.html b/fr-ca/articles/_includes/_new_app_no_sample.html new file mode 100644 index 0000000000..9697d9891d --- /dev/null +++ b/fr-ca/articles/_includes/_new_app_no_sample.html @@ -0,0 +1,5 @@ +<% if (account.userName) { %> +

Get the client ID and domain for your application from the dashboard. +<% } else { %> +

Create an Auth0 account (or login) and add an authentication application from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). +<% } %> diff --git a/fr-ca/articles/_includes/_package.html b/fr-ca/articles/_includes/_package.html new file mode 100644 index 0000000000..b75f53f111 --- /dev/null +++ b/fr-ca/articles/_includes/_package.html @@ -0,0 +1,41 @@ +

+
+
+

Sample Project

+ <% if (account.userName) { %> +

+ Download a sample project specific to this tutorial configured with your Auth0 API Keys. +

+ <% } else { %> +

+ Download a sample project specific to this tutorial to get started. +
+ +

+ <% } %> +
+
+ <% if (typeof branch !== 'undefined') { %> + Download + Fork on Github + <% } else { %> + Download + Fork on Github + <% } %> +
+
+ <% if (typeof requirements !== 'undefined') { %> +
+
System Requirements
+ +
+
+ Show requirements + +
+ <% } %> +
diff --git a/fr-ca/articles/_includes/_parental-consent.md b/fr-ca/articles/_includes/_parental-consent.md new file mode 100644 index 0000000000..eaa0337c61 --- /dev/null +++ b/fr-ca/articles/_includes/_parental-consent.md @@ -0,0 +1,3 @@ +::: note +If you require a specialized consent prompt, for example a parental consent, you need to build your own custom consent form. Be aware that laws vary according to country. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_pipeline2.md b/fr-ca/articles/_includes/_pipeline2.md new file mode 100644 index 0000000000..0bd9cbb5c8 --- /dev/null +++ b/fr-ca/articles/_includes/_pipeline2.md @@ -0,0 +1,3 @@ +::: note +Heads up! As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. For an overview of these changes, and details on how you adopt them, refer to Introducing OIDC Conformant Authentication. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_rbac_methods.md b/fr-ca/articles/_includes/_rbac_methods.md new file mode 100644 index 0000000000..57feb5baa3 --- /dev/null +++ b/fr-ca/articles/_includes/_rbac_methods.md @@ -0,0 +1,8 @@ +Currently, we provide two ways of implementing [role-based access control (RBAC)](/authorization/concepts/rbac), which you can use in place of or in combination with your API's own internal access control system: + +* [Authorization Core](/authorization/guides/how-to) +* [Authorization Extension](/extensions/authorization-extension) + +We are expanding our Authorization Core feature set to match the functionality of the Authorization Extension. Our new core RBAC implementation improves performance and scalability and will eventually provide a more flexible RBAC system than the Authorization Extension. + +For now, both implement the key features of RBAC and allow you to restrict the custom scopes defined for an API to those that have been assigned to the user as permissions. For a comparison, see [Authorization Core vs. Authorization Extension](/authorization/concepts/core-vs-extension). \ No newline at end of file diff --git a/fr-ca/articles/_includes/_rbac_vs_extensions.md b/fr-ca/articles/_includes/_rbac_vs_extensions.md new file mode 100644 index 0000000000..58e7c0af76 --- /dev/null +++ b/fr-ca/articles/_includes/_rbac_vs_extensions.md @@ -0,0 +1,5 @@ +::: warning +The [Authorization Core](/authorization/guides/how-to) feature set and [Authorization Extension](/extensions/authorization-extension) are completely separate features. To manage groups, roles, or permissions, you will need to use the feature they were originally created in. + +Although the [Delegated Administration Extension](/extensions/delegated-admin) and the [Authorization Core](/authorization/guides/how-to) feature set are completely separate features, you can use the Authorization Core feature set to create and manage roles for the DAE if you use a rule. To learn how, see [Sample Use Cases: Rules with Authorization](/authorization/concepts/sample-use-cases-rules#manage-delegated-administration-extension-roles-using-the-authorization-core-feature-set). +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_refresh_token_rotation_panel.md b/fr-ca/articles/_includes/_refresh_token_rotation_panel.md new file mode 100644 index 0000000000..bb3221d0ff --- /dev/null +++ b/fr-ca/articles/_includes/_refresh_token_rotation_panel.md @@ -0,0 +1,3 @@ +::: note +If you have [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) enabled, a new Refresh Token is generated with each request and issued along with the Access Token. When a Refresh Token is exchanged, the previous Refresh Token is invalidated but information about the relationship is retained by the authorization server. +::: diff --git a/fr-ca/articles/_includes/_refresh_token_rotation_recommended.md b/fr-ca/articles/_includes/_refresh_token_rotation_recommended.md new file mode 100644 index 0000000000..5f52feeac1 --- /dev/null +++ b/fr-ca/articles/_includes/_refresh_token_rotation_recommended.md @@ -0,0 +1,3 @@ +::: panel Refresh Token Rotation +Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies. Auth0 recommends using [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation), which provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP. +::: diff --git a/fr-ca/articles/_includes/_samesite_none.md b/fr-ca/articles/_includes/_samesite_none.md new file mode 100644 index 0000000000..9449a343c0 --- /dev/null +++ b/fr-ca/articles/_includes/_samesite_none.md @@ -0,0 +1,10 @@ +::: note +Previously in Auth0, the [`samesite` cookie attribute](/sessions/concepts/cookie-attributes) options were `true`, `false`, `strict` or `lax`. If you didn't set the attribute manually, Auth0 would use the default value of `false`. + +Effective February 2020, Google Chrome v80 will change the way it handles cookies. To that end, Auth0 plans on implementing the following changes to how it handles cookies: + +* Cookies without the `samesite` attribute set will be set to `lax` +* Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar + +The goal of these changes are to improve security and help mitigate CSRF attacks. +::: diff --git a/fr-ca/articles/_includes/_test-this-endpoint.md b/fr-ca/articles/_includes/_test-this-endpoint.md new file mode 100644 index 0000000000..e2d873ea5d --- /dev/null +++ b/fr-ca/articles/_includes/_test-this-endpoint.md @@ -0,0 +1,16 @@ + +Click on **Install Debugger** to go to the article that explains how (you only have to do this once). + +<% + var urlUS = 'https://' + account.tenant + '.us.webtask.io/auth0-authentication-api-debugger'; + var urlEU = 'https://' + account.tenant + '.eu.webtask.io/auth0-authentication-api-debugger'; + var urlAU = 'https://' + account.tenant + '.au.webtask.io/auth0-authentication-api-debugger'; +%> + +
+ Install Debugger +
+ +**If you have already installed the extension, skip to the Authentication API Debugger.** + +The link varies according to your tenant's region: US West, Europe Central or Australia. diff --git a/fr-ca/articles/_includes/_test-with-postman.md b/fr-ca/articles/_includes/_test-with-postman.md new file mode 100644 index 0000000000..559987c872 --- /dev/null +++ b/fr-ca/articles/_includes/_test-with-postman.md @@ -0,0 +1,7 @@ +You can test this endpoint using [Postman](https://www.getpostman.com/). We have a preconfigured collection that you can download and use. Simply click the button below. For more info refer to [Using the Auth0 API with our Postman Collections](/api/postman). + +

+ + Run in Postman + +

diff --git a/fr-ca/articles/_includes/_token_signature.md b/fr-ca/articles/_includes/_token_signature.md new file mode 100644 index 0000000000..6af09f7685 --- /dev/null +++ b/fr-ca/articles/_includes/_token_signature.md @@ -0,0 +1,9 @@ + + +### Verify JWT Token Signature setting + +JSON Web Tokens (JWTs) should be signed using the RS256 signing algorithm where possible, as it provides [enhanced security over HS256](https://auth0.com/docs/tokens/concepts/signing-algorithms#our-recommendation). + +RS256 is the default, but if you are [running into errors](https://auth0.com/docs/errors/libraries/auth0-js/invalid-token#parsing-an-hs256-signed-id-token-without-an-access-token) you can verify your settings by clicking on **Show Advanced Settings** at the bottom of your Auth0 Application settings screen in the dashboard. Click the **OAuth** tab to show the signature algorithm configuration. **JsonWebToken Signature Algorithm** should be set to **RS256**, and the **OIDC Conformant** setting should be enabled. + +![Token Signature Algorithm configuration](/media/articles/applications/token-signature-algorithm.png) diff --git a/fr-ca/articles/_includes/_topic-links.md b/fr-ca/articles/_includes/_topic-links.md new file mode 100644 index 0000000000..e330d77284 --- /dev/null +++ b/fr-ca/articles/_includes/_topic-links.md @@ -0,0 +1,18 @@ + diff --git a/fr-ca/articles/_includes/_users_update_normalized_profile_attributes.md b/fr-ca/articles/_includes/_users_update_normalized_profile_attributes.md new file mode 100644 index 0000000000..822a2e3d50 --- /dev/null +++ b/fr-ca/articles/_includes/_users_update_normalized_profile_attributes.md @@ -0,0 +1,3 @@ +By default, user profile attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable because they are updated from the identity provider each time the user logs in. + +To be able to edit the `name`, `nickname`, `given_name`, `family_name`, or `picture` root attributes on the normalized user profile, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. These root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/set-root-attributes-user-import) using the Management API. diff --git a/fr-ca/articles/_includes/_uses-delegation.md b/fr-ca/articles/_includes/_uses-delegation.md new file mode 100644 index 0000000000..2a157656f4 --- /dev/null +++ b/fr-ca/articles/_includes/_uses-delegation.md @@ -0,0 +1,3 @@ +::: warning +This feature uses delegation. By default, delegation is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate. In addition, note that delegation does not support the use of custom domains so any features depending on it may not be fully functional alongside a custom domain. +::: diff --git a/fr-ca/articles/_includes/_version_warning_api.md b/fr-ca/articles/_includes/_version_warning_api.md new file mode 100644 index 0000000000..bf86f5773c --- /dev/null +++ b/fr-ca/articles/_includes/_version_warning_api.md @@ -0,0 +1,3 @@ +::: warning +This version of the Management API has been deprecated. We recommend that you use the [new version](/api/management/v2) instead. Please refer to the [Migration Guide](/migrations/guides/management-api-v1-v2) for more information. +::: diff --git a/fr-ca/articles/_includes/_version_warning_auth0js.md b/fr-ca/articles/_includes/_version_warning_auth0js.md new file mode 100644 index 0000000000..3c6104e535 --- /dev/null +++ b/fr-ca/articles/_includes/_version_warning_auth0js.md @@ -0,0 +1,3 @@ +::: version-warning +This document covers a deprecated version of Auth0.js which uses endpoints that have been removed from service. It will no longer function as expected. We recommend that you [migrate to Auth0.js v9](/libraries/auth0js/v9/migration-guide) as soon as possible. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_version_warning_lock.md b/fr-ca/articles/_includes/_version_warning_lock.md new file mode 100644 index 0000000000..707490b682 --- /dev/null +++ b/fr-ca/articles/_includes/_version_warning_lock.md @@ -0,0 +1,3 @@ +::: version-warning +This document covers a deprecated version of Lock which uses endpoints that have been removed from service. It will no longer function as expected. We recommend that you migrate to Lock v11 as soon as possible. +::: \ No newline at end of file diff --git a/fr-ca/articles/_includes/_video.md b/fr-ca/articles/_includes/_video.md new file mode 100644 index 0000000000..7eed662b37 --- /dev/null +++ b/fr-ca/articles/_includes/_video.md @@ -0,0 +1,3 @@ + + diff --git a/fr-ca/articles/_includes/_web_origins.md b/fr-ca/articles/_includes/_web_origins.md new file mode 100644 index 0000000000..57364906f5 --- /dev/null +++ b/fr-ca/articles/_includes/_web_origins.md @@ -0,0 +1,5 @@ + + +### Configure Allowed Web Origins + +You need to add the URL for your app to the **Allowed Web Origins** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). If you don't register your application URL here, the application will be unable to silently refresh the authentication tokens and your users will be logged out the next time they visit the application, or refresh the page. diff --git a/fr-ca/articles/_includes/_webtask.md b/fr-ca/articles/_includes/_webtask.md new file mode 100644 index 0000000000..71356fc124 --- /dev/null +++ b/fr-ca/articles/_includes/_webtask.md @@ -0,0 +1,3 @@ +::: warning +Only tenants created prior to 17 July 2018 have access to Webtask.io and the Webtask CLI. If you are an enterprise customer with a newer tenant, please contact your account representative to request access. Other requests can be made through the [Auth0 Contact Form](https://auth0.com/get-started?place=documentation%20post&type=link&text=auth0%20contact%20form) and will be evaluated on a case-by-case basis. +::: diff --git a/fr-ca/articles/addons/azure-blob-storage.md b/fr-ca/articles/addons/azure-blob-storage.md new file mode 100644 index 0000000000..fa945a5c8b --- /dev/null +++ b/fr-ca/articles/addons/azure-blob-storage.md @@ -0,0 +1,58 @@ +--- +addon: Azure Blob Storage +title: Azure Blob Storage Add-on +thirdParty: true +public: false +url: /addons/azure-blob-storage +alias: + - azure blob storage + - azblob +image: /media/platforms/azure.png +topics: + - quickstart + - azure + - addons +articles: + - authenticate +contentType: how-to +description: Learn how to use Auth0 to authenticate and authorize Azure Blob Storage. +useCase: integrate-third-party-apps +--- + +# Azure Blob Storage Add-on + +<%= include('../_includes/_uses-delegation') %> + +Here's a sample call to the delegation endpoint to get the Shared Access Signature (SAS): + +```text +POST https://${account.namespace}/delegation +Content-Type: 'application/json' +{ + "client_id": "${account.clientId}", + "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer", + "id_token": "YOUR_ID_TOKEN", + "target": "${account.clientId}", + "api_type": "azure_blob", + "scope": "openid" +} +``` + +* The `client_id` value identifies the requesting app (such as your website) and `YOUR_ID_TOKEN` identifies the user you are requesting this on behalf-of. (Notice that the `id_token` is signed with the `client_id` corresponding `clientSecret`). +* The `target` parameter identifies this API endpoint in Auth0 (often the same as `${account.clientId}`. This is the `client_id` of the app where this add-on has been enabled. +* `api_type` must be `azure_blob`. +* `scope` must be `openid`. + +The result of calling the delegation endpoint will be something like: + +```json +{ + "azure_blob_sas": "st=2015-01-08T18%3A45%3A14Z&se=2015-01-08T18%3A50%3A14Z&sp=r&sv=2014-02-14&sr=b&sig=13ABC456..." +} +``` + +You can use the blob SAS token either by appending it to a URL directly or by passing it to one of the Azure Storage SDKs. + +```text +GET https://{STORAGEACCOUNT}.blob.core.windows.net/mycontainer/myblob.txt?st=2015-01-08T18%3A45%3A14Z&se=2015-01-08T18%3A50%3A14Z&sp=r&sv=2014-02-14&sr=b&sig=13ABC456... +``` diff --git a/fr-ca/articles/addons/azure-mobile-services.md b/fr-ca/articles/addons/azure-mobile-services.md new file mode 100644 index 0000000000..2d88dd226a --- /dev/null +++ b/fr-ca/articles/addons/azure-mobile-services.md @@ -0,0 +1,80 @@ +--- +addon: Windows Azure Mobile Services +title: Windows Azure Mobile Services Add-on +thirdParty: true +public: false +url: /addons/azure-mobile-services +image: /media/platforms/azure.png +snippets: + use: server-apis/azure-mobile-services/use +alias: + - windows-azure + - microsoft-azure + - windows-azure-websites + - windows-azure-vm + - azure-websites + - azure-vm +topics: + - azure + - mobile + - addons +contentType: how-to +useCase: integrate-third-party-apps +description: Learn how to use Auth0 to authenticate and authorize Windows Azure Mobile Services (WAMS). +--- + +# Windows Azure Mobile Services Add-on + +<%= include('../_includes/_uses-delegation') %> + +## 1. Create an application + +Windows Azure Mobile Services (WAMS) endpoints can be used from anywhere. To configure an app that interacts with WAMS, you can use any of the following tutorials: + +- [Android](/quickstart/native/android) +- [iOS](/quickstart/native/ios-objc) +- [Windows UWP C#](/quickstart/native/windows-uwp-csharp) +- [JavaScript](/quickstart/spa/vanillajs) +- [Windows Phone](/quickstart/native/wpf-winforms) + +The samples that you can download from the Azure Portal are a good starting point. + +![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-4.png) + +## 2. Modify the sample to use Auth0 + +If you follow the Windows UWP sample (C#), you will end up with an `AuthenticateAsync` method that adds one of the standard WAMS authentication mechanisms. + +To modify the sample to use Auth0, include this code: + +${snippet(meta.snippets.use)} + +The important aspects of these lines are: + +1. The `Auth0Client` class takes 2 parameters: your `namespace` and the `clientId` of the application. +2. There are various overloads for the `LoginAsync` method. In the example above, all options will be presented to the user. You can use other versions of `LoginAsync` to direct login to a specific provider. For example: `LoginAsync("github")` will have users login exclusively with GitHub. +3. The `GetDelegationToken` call exchanges the application token (received in step #2) for another token to be used with WAMS. +4. The input for the `GetDelegationToken` method is the `clientID` of your WAMS enabled app. +5. A new `MobileServiceUser` object is created with the new information. + +The `GetDelegationToken` call allows your app to interact with multiple WAMS APIs (or even other APIs). In Auth0, you can control which applications can call which API. + +For example, you can login a user with GitHub, then connect them to WAMS and also interact with an AWS hosted endpoint. The delegation call allows you to flow the identity of the user securely across multiple environments. + +## 3. Use the user identity in the WAMS backend + +The final step is to use the information in the token in the server code. Most likely you will have to do the following two things: + +1. Change permissions on the table for each operation: + + ![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-5.png) + +2. Use the `user` object to change the behavior of the operation. + +This example inserts the `userId` on new rows: + +![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-6.png) + +Then, when querying, it filters out rows for the logged in user: + +![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-7.png) diff --git a/fr-ca/articles/addons/azure-sb.md b/fr-ca/articles/addons/azure-sb.md new file mode 100644 index 0000000000..da89208289 --- /dev/null +++ b/fr-ca/articles/addons/azure-sb.md @@ -0,0 +1,51 @@ +--- +addon: Azure Service Bus +title: Azure Service Bus Add-on +thirdParty: true +public: false +url: /addons/azure-sb +alias: + - Azure Service Bus +image: /media/platforms/azure.png +topics: + - quickstart + - azure + - addons +articles: + - authenticate +contentType: how-to +useCase: integrate-third-party-apps +description: Learn how to use Auth0 to authenticate and authorize Azure Service Bus. +--- + +# Azure Service Bus Add-on + +<%= include('../_includes/_uses-delegation') %> + +Here's a sample call to the delegation endpoint to get the Shared Access Signature (SAS): + +```text +POST https://${account.namespace}/delegation +Content-Type: 'application/json' +{ + "client_id": "${account.clientId}", + "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer", + "id_token": "{YOUR_ID_TOKEN}", + "target": "${account.clientId}", + "api_type": "azure_sb", + "scope": "openid" +} +``` + +* The `client_id` value identifies the requesting app (such as your website) and `{YOUR_ID_TOKEN}` identifies the user you are requesting this on behalf-of. (Notice that the `id_token` is signed with the `client_id` corresponding `clientSecret`). +* The `target` parameter identifies this API endpoint in Auth0 (often the same as `{CLIENT ID}`. This is the `client_id` of the app where this add-on has been enabled. +* `api_type` must be `azure_sb`. +* `scope` must be `openid`. + +The result of calling the delegation endpoint will be something like: + +```json +{ + "azure_sb_sas": "SharedAccessSignature sig=k8bNfT81R8L...LztXvY%3D&se=14098336&skn=PolicyName&sr=http%3A%2F%2Fnamespace.servicebus.windows.net%2Fmy_queue" +} +``` diff --git a/fr-ca/articles/addons/index.md b/fr-ca/articles/addons/index.md new file mode 100644 index 0000000000..bd86928457 --- /dev/null +++ b/fr-ca/articles/addons/index.md @@ -0,0 +1,48 @@ +--- +url: /addons +title: Add-ons +description: Learn about add-ons and how they are related to Auth0-registered Applications. +public: false +topics: + - applications + - add-ons +contentType: + - concept + - index +useCase: + - build-an-app + - integrate-third-party-apps +--- + +# Add-ons + +<%= include('../_includes/_uses-delegation') %> + +Add-ons are plugins associated with an application registered with Auth0. Usually, they are third-party APIs used by application(s) for which Auth0 generates Access Tokens (e.g., Salesforce, Azure Service Bus, Windows Azure Mobile Services, SAP). + +Some typical scenarios for using add-ons include: + +* **Accessing External APIs**: Using the Delegation endpoint, you can exchange your application's Access Token for a third-party service's (e.g., Salesforce, Amazon) Access Token. + +* **Integrating with Applications using SAML2/WS-Federation**: Since Add-ons allow you to configure every aspect of the SAML2/WS-Federation integration, they allow you to integrate with any custom or Single Sign-on (SSO) integration that does not currently enjoy built-in Auth0 support. + +![Addons Example Diagram](/media/articles/applications/applications-addon-types.png) + +## Available Add-ons + +- Amazon Web Services +- Firebase +- Layer +- Salesforce +- Salesforce (Sandbox) +- SAP +- Azure Mobile Services +- Azure Service Bus +- Azure Blob Storage +- SAML2 +- WS-Fed + +## Keep reading + +- [View Add-ons](/dashboard/guides/applications/view-addons) +- [Set Up Add-Ons](/dashboard/guides/applications/set-up-addons) \ No newline at end of file diff --git a/fr-ca/articles/addons/salesforce-sandbox.md b/fr-ca/articles/addons/salesforce-sandbox.md new file mode 100644 index 0000000000..79bd815fe1 --- /dev/null +++ b/fr-ca/articles/addons/salesforce-sandbox.md @@ -0,0 +1,28 @@ +--- +addon: Salesforce (sandbox) +title: Salesforce (Sandbox) Add-on +thirdParty: true +public: false +url: /addons/salesforce-sandbox +alias: + - salesforce +image: /media/addons/salesforce_sandbox_api.svg +description: Learn how to use Auth0 to authenticate and authorize your Salesforce (Sandbox) services. +topics: + - salesforce + - addons +useCase: integrate-third-party-apps +contentType: how-to +--- + +# Salesforce (Sandbox) Add-on + +<%= include('../_includes/_uses-delegation') %> + +Auth0 supports both the __production__ connection to Salesforce and the __Sandbox__, the only difference being the endpoints hosted by Salesforce: `https://login.salesforce.com` and `https://test.salesforce.com`, respectively. + +::: note + Under the hood, Auth0 uses OAuth 2.0 JWT Bearer Token Flow to obtain an Access Token. All details of construction of the right JWT are taken care of by Auth0. +::: + +![](/media/articles/server-apis/salesforce-data-flow.png) diff --git a/fr-ca/articles/addons/salesforce.md b/fr-ca/articles/addons/salesforce.md new file mode 100644 index 0000000000..54aa6bb93e --- /dev/null +++ b/fr-ca/articles/addons/salesforce.md @@ -0,0 +1,38 @@ +--- +addon: Salesforce +title: Salesforce Add-on +alias: + - salesforce +url: addons/salesforce +thirdParty: true +public: false +image: /media/addons/salesforce.svg +description: Learn how to use Auth0 to authenticate and authorize your Salesforce services. +topics: + - salesforce + - addons +useCase: integrate-third-party-apps +contentType: how-to +--- + +# Salesforce Add-on + +<%= include('../_includes/_uses-delegation') %> + +Auth0 supports both the __production__ connection to Salesforce and the __Sandbox__, the only difference being the endpoints hosted by Salesforce: `https://login.salesforce.com` and `https://test.salesforce.com`, respectively. + +The integration also supports getting tokens for __Salesforce Community Sites__. For this to work, you need to pass two additional parameters: + +``` +... +community_name: 'mycommunity', +community_url_section: 'members' +... + +``` + +::: note + Under the hood, Auth0 uses OAuth 2.0 JWT Bearer Token Flow to obtain an Access Token. All details of construction of the right JWT are taken care of by Auth0. +::: + +![Salesforce data flow](/media/articles/server-apis/salesforce-data-flow.png) diff --git a/fr-ca/articles/addons/sap-odata.md b/fr-ca/articles/addons/sap-odata.md new file mode 100644 index 0000000000..4c5db1bcce --- /dev/null +++ b/fr-ca/articles/addons/sap-odata.md @@ -0,0 +1,30 @@ +--- +addon: SAP OData +title: SAP OData Add-on +alias: + - sap +url: /addons/sap-odata +image: /media/addons/sap_api.svg +description: Learn how to use Auth0 to authenticate and authorize your SAP OData services. +public: false +topics: + - sap + - addons + - odata +useCase: integrate-third-party-apps +contentType: how-to +--- + +# SAP OData Add-on + +<%= include('../_includes/_uses-delegation') %> + +::: warning +This integration is in experimental mode. Contact us if you have questions. +::: + +::: note + Under the hood, Auth0 uses SAML 2.0 Bearer Assertion Flow for OAuth 2.0 to obtain an Access Token. All details of construction of the right SAML token are taken care of by Auth0. +::: + +![](/media/articles/server-apis/sap-data-flow.png) diff --git a/fr-ca/articles/analytics/_includes/_install.md b/fr-ca/articles/analytics/_includes/_install.md new file mode 100755 index 0000000000..4e86feb323 --- /dev/null +++ b/fr-ca/articles/analytics/_includes/_install.md @@ -0,0 +1,20 @@ +## Install + +To add the <%- name %> integration to your app, include a reference to the `Auth0 Analytics.js` script on any pages with Auth0 Lock. Include the script reference **after**** Lock *and* set the configuration options before the script reference. + +``` + + + +``` + +::: note +The script version above uses a placeholder version `X.Y.Z`. For example, to reference release, 1.3.1 use `https://cdn.auth0.com/js/analytics/1.3.1/analytics.min.js`. You can [find the latest release's version number](https://github.com/auth0/auth0-analytics.js/releases/) on GitHub. +::: diff --git a/fr-ca/articles/analytics/_includes/_usage.md b/fr-ca/articles/analytics/_includes/_usage.md new file mode 100755 index 0000000000..9d4a7485c2 --- /dev/null +++ b/fr-ca/articles/analytics/_includes/_usage.md @@ -0,0 +1,20 @@ +## Usage + +After installation on your site, you will start collecting data. Auth0 Analytics will immediately begin sending events to <%- name %>. + +You will see the following events being logged: + +* Auth0 Lock show +* Auth0 Lock hide +* Auth0 Lock unrecoverable_error +* Auth0 Lock authenticated +* Auth0 Lock authorization_error +* Auth0 Lock forgot_password ready +* Auth0 Lock forgot_password submit +* Auth0 Lock signin submit +* Auth0 Lock signup submit +* Auth0 Lock federated login + +Note that some events that Lock emits like `hash_parsed` are not used for analytics purposes. Also, be aware that some events are only available in newer versions of Lock. If you are using an older version of Lock you will only see some of these events. We suggest upgrading to the latest version of Lock to get the most of the Auth0 Analytics integration. + +For more information on the events that are sent see the [Lock API documentation](/libraries/lock/v11/api#on-). diff --git a/fr-ca/articles/analytics/guides/facebook-analytics.md b/fr-ca/articles/analytics/guides/facebook-analytics.md new file mode 100644 index 0000000000..bc4093476f --- /dev/null +++ b/fr-ca/articles/analytics/guides/facebook-analytics.md @@ -0,0 +1,69 @@ +--- +description: Learn how to install and configure the Facebook Analytics for Auth0 integration. +topics: + - facebook + - analytics +public: false +contentType: how-to +useCase: + - manage-analytics + - analyze-external-analytics +--- +# Integrate Facebook Analytics with Auth0 + +Install and configure the **Facebook Analytics for Auth0** integration on your own page that is using [Lock](/libraries/lock) or the [hosted Lock pages](/universal-login). You can configure funnels and reports inside of Facebook Analytics to get the most out of this integration. + +<%= include('../_includes/_install', { name: "Facebook Analytics" }) %> + +## Setup + +If you already have either the Facebook Tracking Pixel or the Facebook Javascript SDK referenced on your site, configure Auth0 Analytics with the `preload` option as shown below. If you don't have either script loaded you need to set your Facebook Analytics App ID using the Facebook Javascript SDK configuration below. + +We recommend [creating funnels](https://www.facebook.com/help/analytics/935921203105136) to measure the success of your acquisition and registration flows using these new events. + +### Configure Facebook Javascript SDK (Recommended) + +The simplest configuration is to let the Analytics script load the Facebook Javascript SDK. You can do this by providing your Facebook Analytics App ID to the analytics options as shown below. + +``` + +``` + +If you have already loaded the Facebook Javascript SDK on your site, configure Auth0 Analytics to not load it again as shown below. + +``` + +``` + +### Configure Facebook Pixel + +If you already have the Facebook Pixel installed on your site you can use that configuration mode. Note that with the Facebook Pixel, certain features of Facebook Analytics are not available. The configuration for using the pixel is shown below. + +``` + +``` + +<%= include('../_includes/_usage', { name: "Facebook Analytics" }) %> + +## Keep reading + +[Facebook Analytics documentation](https://www.facebook.com/help/analytics/1710582659188030) + diff --git a/fr-ca/articles/analytics/guides/google-analytics.md b/fr-ca/articles/analytics/guides/google-analytics.md new file mode 100644 index 0000000000..4367921202 --- /dev/null +++ b/fr-ca/articles/analytics/guides/google-analytics.md @@ -0,0 +1,46 @@ +--- +description: Learn how to install and configure the Google Analytics for Auth0 integration. +topics: + - google + - analytics +public: false +contentType: how-to +useCase: + - manage-analytics + - analyze-external-analytics +--- +# Integrate Google Analytics with Auth0 + +This article explains how to install and configure the **Google Analytics for Auth0** integration. You can use this integration on your own page that is using Lock. You can configure funnels and reports inside of Google Analytics to get the most out of this integration. + +## Setup + +1. Set analytics configuration options *before* you include the references to the Lock and Auth0 Analytics libraries. + + ```javascript + + ``` + +2. Include the script reference to the `auth0-analytics.js`. This needs to be included *after* the call to Lock. + + ```javascript + + + ``` + +::: note +The script version above uses a placeholder version `X.Y.Z`. For example, to reference release 1.3.1 use `https://cdn.auth0.com/js/analytics/1.3.1/analytics.min.js`. You can [find the latest release's version number](https://github.com/auth0/auth0-analytics.js/releases/) on GitHub. +::: + +<%= include('../_includes/_usage', { name: "Google Analytics" }) %> + +## Keep reading + +[Google Analytics documentation](https://support.google.com/analytics) diff --git a/fr-ca/articles/analytics/index.md b/fr-ca/articles/analytics/index.md new file mode 100755 index 0000000000..b40e0508b0 --- /dev/null +++ b/fr-ca/articles/analytics/index.md @@ -0,0 +1,38 @@ +--- +url: /analytics +section: articles +classes: topic-page +title: Analytics Integrations +topics: + - analytics +public: false +contentType: index +useCase: + - manage-analytics + - analyze-external-analytics +--- + +
+
+

Analytics Integrations

+

+ Setup and configure analytics integrations with Auth0. +

+
+ +Analytics tools help you track users on your site or application. Integrating third-party analytics tools with Auth0 enables you to capture and measure identity specific events. You can use this data to create funnels, measure user retention, and improve your sign up flow. + + diff --git a/fr-ca/articles/anomaly-detection/concepts/breached-passwords.md b/fr-ca/articles/anomaly-detection/concepts/breached-passwords.md new file mode 100644 index 0000000000..92f077dc01 --- /dev/null +++ b/fr-ca/articles/anomaly-detection/concepts/breached-passwords.md @@ -0,0 +1,64 @@ +--- +title: Breached Password Security +description: Understand why a user receives a breached password email and general web security tips. +topics: + - security + - passwords +contentType: concept +useCase: customize-anomaly-detection +v2: true +--- + +# Breached Password Security + +When a user receives an email requesting that they change their password immediately, it is because their account could be the victim of a security breach. This may be the result of a compromise by a third-party application that experienced a security breach. The breach may not have happened to this account, but based on available data, the user's credentials may have been released. Since many people reuse passwords, the request to change passwords is a precaution to make sure the user stays protected. + +Users may also want to change their password at any other sites where they suspect they used a shared password. + +## General security tips + +Users can't usually prevent certain sites from experiencing security breaches, but there are some things they can do to help keep their accounts safe. + +### Check emails carefully + +Check where an email is coming from and the links that they provide. Often phishing emails do not include a user's name but something generic such as "Dear Customer." + +### Reset passwords directly from sites + +Always do a password reset through the actual site itself not via potentially false links in emails. Also note that secure website URL always starts with `https`. + +Here are some links for password resets on commonly used sites: +* [Google](https://www.google.com/accounts/recovery/) +* [Facebook](https://www.facebook.com/settings) +* [Twitter](https://twitter.com/settings/password) + +### Never enter personal or financial information in email + +Emails in general are not very secure and are not a good way to communicate sensitive information. A trusted company/application would not ask for information in this way. Make sure not to enter confidential information through false links in emails. + +### Never download files from unreliable sources + +Most web browsers detect suspicious sites. An alert should appear when you try to access a malicious site. Never download files from suspicious emails or websites. + +### Do not reuse passwords + +When one site has a breach of user data, if a user uses the same credentials elsewhere, information in other sites can also be accessed. The only way to prevent this is by not reusing passwords for multiple sites. The problem is that remembering countless passwords is frustrating and often impossible. One solution to this problem is the use of a password manager. There are many password managers available which can help users to use separate and secure passwords for each account, but at the same time not be responsible for remembering all of them. + +### Use strong passwords + +The longer a password is, the harder it becomes to be guessed via brute force methods. Many sites allow the use of pass-phrases (a phrase or sentence instead of just a complicate word.) Try to make passwords long and use a mix of special characters, numbers, and upper- and lowercase letters. + +### Keep software current + +Applications release patches and updates when they find security vulnerabilities in their systems. Keeping applications, web browsers, and operating systems up to date can help prevent security breaches. + +### Check the security of your email inbox + +If you use Gmail, Google offers the [Security Checkup](https://myaccount.google.com/security-checkup) tool to let you know if there are any security issues related to your inbox. + +You can also use third-party tools, such as websites like [HaveIBeenPwned](https://haveibeenpwned.com/PwnedWebsites) to see if there might be security issues associated with your email address. + +## Keep reading + +* [Anomaly Detection](/anomaly-detection) +* [Customize Blocked Account Emails](/anomaly-detection/guides/customize-blocked-account-emails) diff --git a/fr-ca/articles/anomaly-detection/guides/customize-blocked-account-emails.md b/fr-ca/articles/anomaly-detection/guides/customize-blocked-account-emails.md new file mode 100644 index 0000000000..1347250973 --- /dev/null +++ b/fr-ca/articles/anomaly-detection/guides/customize-blocked-account-emails.md @@ -0,0 +1,30 @@ +--- +title: Customize Blocked Account Emails +description: Learn how to customize blocked account emails. +topics: + - security + - anomaly-detection + - brute-force-protection + - breached-password-detection +contentType: how-to +useCase: customize-anomaly-detection +v2: true +--- +# Customize Blocked Account Emails + +When Auth0 sends an email to a user to notify them of the [breached password block action](/anomaly-detection/references/breached-password-detection-triggers-actions), the message contains a link to re-enable the origin of the request. + +::: note +Auth0 never blocks the user itself, just the attempts from the suspicious origin. +::: + +The email sent to the user looks like this: + +![Email Example](/media/articles/brute-force-protection/bfp-2015-12-29_1832.png) + +You can customize the template used for this message on the [Dashboard](${manage_url}/#/emails) under __Emails > Templates > Blocked Account Email__. + +## Keep reading + +* Learn more about [email templates](/email/templates). +* Understand [why a user receives a breached password email](/anomaly-detection/concepts/breached-passwords) and general web security tips. diff --git a/fr-ca/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md b/fr-ca/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md new file mode 100644 index 0000000000..e40844c3be --- /dev/null +++ b/fr-ca/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md @@ -0,0 +1,29 @@ +--- +title: Enable and Disable Brute-Force Protection +description: Learn how to disable and enable brute-force protection. +topics: + - security + - anomaly-detection + - brute-force-protection +contentType: how-to +useCase: customize-anomaly-detection +v2: true +--- +# Enable and Disable Brute-Force Protection + +Brute-force protection is enabled by default for all connections. + +![Brute-Force Protection Shield](/media/articles/anomaly-detection/anomaly-detection-overview.png) + +::: warning +Auth0 strongly recommends that you **do not** set the `brute_force_protection` flag to `false` (effectively disabling brute-force protection for the connection), however if you do, you can change it back in the [Dashboard](${manage_url}/#/anomaly). +::: + +Once enabled, you can [customize](/anomaly-detection/guides/set-anomaly-detection-preferences#brute-force-protection-preferences) your brute-force protection settings. + +![Brute-Force Protection Shield](/media/articles/anomaly-detection/brute-force-shield.png) + +## Keep reading + +* [Brute-Force Protection Triggers and Actions](/anomaly-detection/references/brute-force-protection-triggers-actions) +* [Set Anomaly Detection Preferences](/anomaly-detection/guides/set-anomaly-detection-preferences) \ No newline at end of file diff --git a/fr-ca/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md b/fr-ca/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md new file mode 100644 index 0000000000..c4d5d0b291 --- /dev/null +++ b/fr-ca/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md @@ -0,0 +1,91 @@ +--- +title: Prevent Credential Stuffing Attacks +description: Learn how to prevent credential stuffing attacks on your system. +beta: true +topics: + - anomaly-detection + - credential-stuffing +contentType: how-to +useCase: + - prevent-credential-stuffing +--- +# Prevent Credential Stuffing Attacks + +Credential stuffing attacks (also known as *list validation attacks*) occur when bad actors automate the process of trying username and password combinations (usually stolen from another site) for many accounts in a short period of time. According to recent statistics, as many as 71% of accounts use the same password across multiple sites so a credential stuffing attack has the potential to successfully log into your system. + +Consider, for example, the number of errors caused by an incorrect email or username (identified in the logs as type `fu`) for a particular tenant, which suggests an attack occurred November 20, with some abuse patterns afterwards: + +![Credential Stuffing Attack Example](/media/articles/anomaly-detection/credential-stuffing-attack.png) + +Auth0 provides a number of tools to combat credential stuffing attacks: + +* [Brute Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection) blocks login attempts after a number of consecutive failed logins. + +* [Breached Password Protection](/anomaly-detection/concepts/breached-passwords) identifies credentials that are known to be stolen. + +* [Multi-factor Authentication](/mfa) can be effective in preventing unauthorized logins, but it adds friction to the user experience. + +If you do not want to turn on additional features such as MFA, you can add **Automated Credential Stuffing Attack Protection** to provide a standard level of protection against credential stuffing attacks that does not add any friction to legitimate users. + +## How it works + +Auth0 uses a large amount of data to identify patterns that signal that a credential stuffing attack is taking place. Auth0 uses sophisticated algorithms to determine when bursts of traffic are likely to be from a bot or script. Users attempting to sign in from IPs which are determined to have a high likelihood of being a credential stuffing attack will see a Captcha step. The algorithms are designed so that this only happens for bad traffic; the objective is to not show any friction to legitimate users. + +![Captcha Login Screen Example](/media/articles/anomaly-detection/captcha-login-screen.png) + +## Enable automated credential stuffing attack protection + +### Prerequisites + +* Please read Auth0’s [Beta Service Terms](https://cdn.auth0.com/website/legal/terms/beta-service-terms-11-18-19.pdf) and acknowledge you have read and agreed to the terms by emailing **Antonio Fuentes** at **antonio.fuentes@auth0.com**. + +* Determine which type of login experience you have configured: + + - Go to [Dashboard](${manage_url}/#). + - Navigate to **Universal Login**. + - Determine which login experience is selected (Classic or New). + +### If you are using New Universal Login + +No further configuration is required. If you are part of the Beta program, the Early Access features will work for your tenant immediately. + +### If you are using Classic Universal Login + +Determine if your page is customized. + +1. Select the **Login** tab. + +2. Verify the status of the toggle **Customize Login Page**. + +3. If it is on, you have a customized login page. + +### If you are using customized Classic Universal Login + +Upgrade your version of Lock. + +1. Navigate to the **Universal Login** section in the Dashboard. + +2. Select the **Login** tab. + +3. Update your version of Auth0’s Lock to version v11.20 by replacing the script tag with the tag for version v11.20. + +For example, replace this tag: +```html + +``` + +With the following: +```html + +``` + +## Performance impact + +This feature is intended to reduce the number of login attempts associated with automated or scripted credential stuffing attacks. It is not expected to cause a degradation in the latency or performance of the login flows. Auth0 monitors the impact on these metrics and will share them with you. + +In addition, you can look at the [tenant logs](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection). Events that indicate a credential stuffing attack is happening. + +- `f`: failed login +- `fu`: failed login due to invalid email/username + +If you have questions, you can contact Auth0 through your TAM or contact **antonio.fuentes@auth0.com**. diff --git a/fr-ca/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md b/fr-ca/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md new file mode 100644 index 0000000000..7096901ab2 --- /dev/null +++ b/fr-ca/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md @@ -0,0 +1,70 @@ +--- +title: Set Anomaly Detection Preferences +description: Learn how to set anomaly detection preferences in the Dashboard. +topics: + - security + - anomaly-detection + - brute-force-protection + - breached-password-detection +contentType: how-to +useCase: customize-anomaly-detection +v2: true +--- +# Set Anomaly Detection Preferences + +Customize the actions that occur after the triggers in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly). + +::: warning +Auth0 recommends that you **do not** make changes to your anomaly detection features with the Management API. +::: + +![Anomaly Detection Dashboard](/media/articles/anomaly-detection/anomaly-detection-overview.png) + +## Brute-force protection preferences + +Brute-force protection is enabled by default for all connections. For more information, see [Enable and Disable Brute-Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection). + +::: warning +Auth0 strongly recommends that you **do not** set the `brute_force_protection` flag to `false` (effectively disabling brute-force protection for the connection), however if you do, you can change it back in the [Dashboard](${manage_url}/#/anomaly). +::: + +Limit the amount of signups and failed logins from a suspicious IP address. For more information, see [Brute-Force Protection Triggers and Actions](/anomaly-detection/references/brute-force-protection-triggers-actions). + +1. Click on the **Brute-force Protection** shield. + +![Brute-Force Protection Shield](/media/articles/anomaly-detection/brute-force-shield.png) + +2. Use the toggles to enable or disable actions for single or multiple user accounts. + +3. Add any IP addresses to the **Whitelist** field to avoid erroneously triggering the protection action. + +4. Click **Save** when you are finished. + +## Breached password detection preferences + +Set preferences for breached password detection actions. For more information, see [Breached Password Detection Triggers and Actions](/anomaly-detection/references/breached-password-detection-triggers-actions). + +1. Click on the **Breached-password Detection** shield. + +![Breached Password Detection Shield](/media/articles/anomaly-detection/breached-password-shield.png) + +2. Use the toggles to enable or disable actions when login security breaches are detected. + +3. Determine how administrators are notified. + +4. Click **Save** when you are finished. + +## Restrictions and limitations + +Both brute-force protection and breached password detection depend on the IP address of the user. Because of this, the following use cases are *not* supported: + +* **Using the [Resource Owner](/api/authentication#resource-owner) from the backend of the application.** Using this call does not get the IP address of the user. See point 2 below as an alternative. + +* **Using [Resource Owner Password Grant](/api-auth/grant/password) from the backend of the application.** Using this call does not get the IP address of the user, however, you can [configure your application and send the IP address of the user as part of the request](/api-auth/tutorials/using-resource-owner-password-from-server-side) to make brute-force protection work correctly. + +* **Authenticating many users from the same IP address.** For example, users that are behind a proxy are more likely to reach these limits and trigger the associated protection. It is possible to configure a whitelist for the proxy's IP and CIDR range and avoid erroneously triggering the protection. + +## Keep reading + +* [Anomaly Detection](/anomaly-detection) +* [Breached Password Security](/anomaly-detection/concepts/breached-passwords) \ No newline at end of file diff --git a/fr-ca/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md b/fr-ca/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md new file mode 100644 index 0000000000..fd88341413 --- /dev/null +++ b/fr-ca/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md @@ -0,0 +1,57 @@ +--- +description: Learn how to use tenant traffic log data to view anomaly detection events. +topics: + - security + - anomaly-detection +contentType: how-to +useCase: tenant-logs +--- + +# View Anomaly Detection Events + +The tenant logs contain useful data that you can use to build charts to look at the profile of the traffic going through your tenant. This is helpful when evaluating anomaly detection activity. + +## Authentication failure events + +You can use the log data `event` field to view the tenant traffic data. We recommend building a daily histogram of failure events of the following types: + +| Event Code | Event | +| -- | -- | +| `f` | Failed login | +| `fcoa` | Failed cross-origin authentication | +| `feccft` | Failed exchange | +| `fepft` | Failed exchange | +| `fsa` | Failed silent authentication | +| `fu` | Failed login (invalid email/username) | +| `sepft` | Success exchange | + +These failure events depend on the flow you have set up with Auth0. + +The following example shows a credential stuffing attack on 11/20, with a large surge of events of type `fu` which is a failed username (typical of a credential stuffing attack). + +![Traffic Failure Trends](/media/articles/anomaly-detection/traffic-failure-trends.png) + +## Authenticaton failure events from distinct IPs + +You can use the `ip` event to see the number of distinct IPs that your failure traffic is coming from, in this case, the number of distinct IPs that correspond to your `fu` event traffic. + +## Anomaly detection events + +You can perform the same type of analysis with the events corresponding to anomaly detection events to see how many times they are triggered. Use the following log events which correspond to brute force detection with many accounts, one account, and breached password detection: + +| Event Code | Event | +| -- | -- | +| `limit_mu` | Blocked IP address | +| `limit_wc` | Blocked account | +| `pwd_leak` | Breached password | + +Here's an example of what that data might look like. + +![Anomaly Detection Data](/media/articles/anomaly-detection/anomaly-detection-features.png) + +## Keep reading + +* [Log Event Data](/logs/references/log-events-data) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Export Log Data to External Services](/extensions#Monitor) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) diff --git a/fr-ca/articles/anomaly-detection/index.md b/fr-ca/articles/anomaly-detection/index.md new file mode 100644 index 0000000000..9dc98e5ece --- /dev/null +++ b/fr-ca/articles/anomaly-detection/index.md @@ -0,0 +1,73 @@ +--- +title: Anomaly Detection +description: Understand how Auth0 detects anomalies to stop malicious attempts to access your application, alert you and your users of suspicious activity, and block further login attempts. +toc: true +topics: + - security + - anomaly-detection + - brute-force-protection + - breached-password-detection +contentType: concept +useCase: customize-anomaly-detection +v2: true +--- +# Anomaly Detection + +Auth0 can detect anomalies and stop malicious attempts to access your application. Anomaly detection can alert you and your users of suspicious activity, as well as block further login attempts. You can [set preferences](/anomaly-detection/guides/set-anomaly-detection-preferences) for notifications and decide whether to block a suspicious IP address or not. + +Auth0 has two types of **shields** to handle anomalies and attacks. + +* [Brute-force protection](#brute-force-protection) +* [Breached password detection](#breached-password-detection) + +A **shield** specifies the **action** you wish to take given a specific **trigger**. A **trigger** is a suspicious event that is detected when someone is trying to login to your system, or there may have been a breached password with another third party service. + +Customize the actions in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly). + +::: note +Auth0 recommends that you [create reports using tenant traffic data to see anomaly detection events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection). +::: + +## Brute-force protection + +Brute-force protection is [enabled by default](/anomaly-detection/guides/enable-disable-brute-force-protection) for all connections. There are two different [triggers](/anomaly-detection/references/brute-force-protection-triggers-actions) for the brute-force protection shield, for two slightly different attack scenarios. + +* 10 consecutive failed login attempts for the same user and from the same IP address +* 100 failed login attempts from the same IP address in 24 hours *or* 50 sign up attempts per minute from the same IP address + +For example, if a user with *user_id1* signs in from *IP1* and fails to login consecutively for 10 attempts, their log in attempt from this *IP1* will be blocked. Another user, *user_id2*, signing in from *IP1* will not be blocked. + +## Breached password detection + +Every day, malicious hackers penetrate websites and applications, exposing thousands of email and passwords. Because it's common for users to use the same password to login to multiples sites, this poses a problem, not only for the hacked system, but to any application that shares those [breached passwords](/anomaly-detection/concepts/breached-passwords). + +Auth0 tracks large security breaches that are happening on major third party sites to help keep your users and system secure. By [enabling breached password detection](/anomaly-detection/guides/set-anomaly-detection-preferences), when a [trigger](/anomaly-detection/references/breached-password-detection-triggers-actions) occurs, your users can be notified and/or blocked from logging in if we suspect their credentials were part of a published security breach. You can [customize blocked account emails](/anomaly-detection/guides/customize-blocked-account-emails). + +## Frequently asked questions + +* **Is the user notified at every login?** +We send one email every hour, regardless of the number of logins. For example, if a user tries to log in 200 times in 1 hour and 30 minutes, we will send 2 emails. + +* **Is there a limit to the number of times a user will be notified?** +Users will only be notified once per hour. + +* **How often does Auth0 email administrators when traffic is blocked using Brute Force Protection for multiple accounts?** +In the event of an ongoing attack, traffic can be blocked from thousands of IP addresses at a time. Auth0 will send a single email to each administrator every hour that traffic is blocked, regardless of the number of IPs involved in the attack. + +* **For how long is the reset password link, included in the breached password email, valid?** +Password reset links are valid for 5 days. + +* **Is there a test dataset of breached passwords?** +You can test with **leak-test@example.com** as the email and **Paaf213XXYYZZ** as the password. + +* **Does the breached password detection work when logging in using the Resource Owner password grant?** +Yes. + +* **Does the breached password detection feature work with a custom database?** +Yes. + +* **What Redirect URL applies to the *Change password* link included in the breached password notification email?** +The **RedirectTo** URL is the URL listed in the Dashboard in [Emails > Templates > Change Password Template](${manage_url}/#/emails). + +* **Is there a way to configure the Redirect URL and the length of time that the change password link is valid?** +You can configure the **URL Lifetime** and **Redirect To** values in the Dashboard by going to [Emails > Templates > Change Password Template](${manage_url}/#/emails). \ No newline at end of file diff --git a/fr-ca/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md b/fr-ca/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md new file mode 100644 index 0000000000..c7e0e93b8b --- /dev/null +++ b/fr-ca/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md @@ -0,0 +1,35 @@ +--- +title: Breached Password Detection Triggers and Actions +description: Breached password detection triggers and actions taken upon anomaly detection and how blocks are cleared. +topics: + - security + - anomaly-detection + - breached-password-detection +contentType: reference +useCase: customize-anomaly-detection +v2: true +--- +# Breached Password Detection Triggers and Actions + +## Trigger + +A trigger occurs when Auth0 suspects that a specific user's credentials were included in a major public security breach. + +::: panel Video Tutorial +Watch our [Breached Password Detection 101 video tutorial](https://auth0.com/resources/videos/learn-about-breached-password-detection). +::: + +## Actions + +* Send an email to the affected user. +* Send an email to dashboard owners immediately, and/or have a daily/weekly/monthly summary. +* Block login attempts for suspected user accounts using that username and password combination. + +## Remove block + +This block remains in place until the user changes their password. + +## Keep reading + +* [Anomaly Detection](/anomaly-detection) +* [Breached Password Security](/anomaly-detection/concepts/breached-passwords) \ No newline at end of file diff --git a/fr-ca/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md b/fr-ca/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md new file mode 100644 index 0000000000..3342464d8f --- /dev/null +++ b/fr-ca/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md @@ -0,0 +1,64 @@ +--- +title: Brute-Force Protection Triggers and Actions +description: Brute-force protection triggers and actions taken upon anomaly detection and how blocks are cleared. +topics: + - security + - anomaly-detection + - brute-force-protection +contentType: reference +useCase: customize-anomaly-detection +v2: true +--- +# Brute-Force Protection Triggers and Actions + +## 10 failed login attempts + +### Trigger + +This trigger occurs when there are 10 failed login attempts into a single account from the same IP address. + +::: note +The default trigger amount of 10 cannot be changed. +::: + +### Actions + +* Send an email to the affected user. (You can [customize the email](/anomaly-detection/guides/customize-blocked-account-emails).) +* Block the suspicious IP address for that user. + +### Remove block + +If this block is triggered, it can be cleared the following ways: + +* An administrator removes the block via the [Dashboard](${manage_url}) (by clicking **unblock for all IPs** under the **ACTIONS** button when viewing the user's details) or by using the [Management API](/api/management/v2#!/User_Blocks/delete_user_blocks). +* The user clicks on the **unblock** link provided in the email sent when the block went into effect. +* The user changes their password. + +## 100 failed login attempts *or* 50 sign up attempts + +### Triggers + +A trigger occurs when there are 100 failed login attempts from one IP address using different usernames with incorrect passwords in 24 hours. + +Another trigger occurs if there are 50 sign up attempts per minute from the same IP address. + +### Actions + +* Notify dashboard administrator(s). +* Block suspicious addresses for 15 minutes. + +If this block is triggered, additional access attempts are released one-at-a-time over the course of 24 hours until 100 attempts are allocated. This results in approximately 1 additional attempt every 15 minutes. + +### Remove block + +Auth0 emails the dashboard administrator(s) when this block is triggered. The email contains a link that the owner can click to navigate to tenant logs to examine which IPs have been blocked. Recent blocks can be found using this query: +``` +type:limit_mu +``` +Blocks can then be removed using the [Management API](/api/management/v2#!/Anomaly/delete_ips_by_id). + +## Keep reading + +* [Anomaly Detection](/anomaly-detection) +* [Set Anomaly Detection Preferences](/anomaly-detection/guides/set-anomaly-detection-preferences) +* [Enable and Disable Brute-Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection) diff --git a/fr-ca/articles/api-auth/_includes/_ropg-warning.md b/fr-ca/articles/api-auth/_includes/_ropg-warning.md new file mode 100644 index 0000000000..c19c5320ac --- /dev/null +++ b/fr-ca/articles/api-auth/_includes/_ropg-warning.md @@ -0,0 +1,9 @@ +::: warning +Since the Resource Owner Password Grant (ROPG) flow involves the client handling the user's password, it **must not be used by third-party clients**. In this flow, the user's username and password are exchanged directly for an Access Token. + +Only consider using it when there is a high degree of trust between the user and the application and when other authorization flows (such as redirect-based flows) are not available. + +Instead, Auth0 recommends: +* For confidential clients, like Regular Web Applications, use the [Authorization Code Flow](/flows/concepts/auth-code). +* For public clients, like Native/Mobile Apps and Single-Page Applications, use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). +::: diff --git a/fr-ca/articles/api-auth/apis.md b/fr-ca/articles/api-auth/apis.md new file mode 100644 index 0000000000..da33b407f4 --- /dev/null +++ b/fr-ca/articles/api-auth/apis.md @@ -0,0 +1,85 @@ +--- +url: /apis +toc: true +title: APIs Overview +description: Learn the basics of APIs, their role in OAuth and how to configure an API in Auth0 Dashboard. +crews: crew-2 +topics: + - api-authentication + - oidc + - apis +contentType: concept +useCase: + - secure-api + - call-api +--- +# APIs + +An API is an entity that represents an external resource, capable of accepting and responding to protected resource requests made by applications. At the [OAuth2 spec](https://tools.ietf.org/html/rfc6749) an API maps to the **Resource Server**. + +When an application wants to access an API's protected resources it must provide an Access Token. The same Access Token can be used to access the API's resources without having to authenticate again, until it expires. + +Each API has a set of defined permissions. Applications can request a subset of those defined permissions when they execute the authorization flow, and include them in the Access Token as part of the **scope** request parameter. + +For example, an API that holds a user's appointments, may accept two different levels of authorization: read only (scope `read:appointments`) or write (scope `write:appointments`). When an application asks the API to list a user's appointments, then the Access Token should contain the `read:appointments` scope. In order to edit an existing appointment or create a new one, the Access Token should contain the `write:appointments` scope. See [Tokens](/tokens) for more information. + +## How to configure an API in Auth0 + +Click on the [APIs menu option](${manage_url}/#/apis) on the left. + +::: note +The API tab will already have one API created automatically, the **Auth0 Management API**. For more details on the features of the Management API and its available endpoints, refer to: [Management API](/api/management/v2). +::: + +Click the **+ Create API** button. + +![Create a new API](/media/articles/api/overview/create-api.png) + +You need to provide the following information for your API: + +- **Name**: a friendly name for the API. Does not affect any functionality. + +- **Identifier**: a unique identifier for the API. Auth0 recommends using a URL. Auth0 does differentiate between URLs that include the last forward slash. For example, https://example.com and https://example.com/ are two different identifiers. The URL does not have to be a publicly available URL. Auth0 will not call your API. This value **cannot** be modified afterwards. + +- **Signing Algorithm**: the algorithm to sign the tokens with. The available values are `HS256` and `RS256`. When selecting `RS256` the token will be signed with the tenant's private key. To learn more about signing algorithms, see [Signing Algorithms paragraph](/tokens/concepts/signing-algorithms). + +Fill in the required information and click the **Create** button. + +Once you do so you will be navigated to the *Quick Start* of your API. Here you can find details on the implementation changes you have to do to your API, which basically consists of choosing a JWT library from a predefined list and configuring this library to validate the Access Tokens in your API. + +![API Quick Starts](/media/articles/api/overview/quickstarts-view.png) + + +The other available views for your API are: + +- **Settings**: lists the settings for your API. Some are editable. Here you can change the token expiration time and enable offline access (this way Auth0 will allow your applications to ask for Refresh Tokens for this API). For details refer to the [API Settings paragraph](#api-settings). + +- **Scopes**: here you can define the scopes for this API, by setting a name and a description. + +- **Machine to Machine Applications**: lists all applications for which the **Client Credentials** grant is **enabled**. By default, this grant is **enabled** for [Regular Web Applications and Machine to Machine Applications](/applications). You can authorize any of these applications to request Access Tokens for your API. Optionally, you can select a subset of the defined scopes to limit your authorized application's access. + +- **Test**: from this view, you can execute a sample Client Credentials flow with any of your authorized applications to check that everything is working as expected. + +### API Settings + +Click on the *Settings* tab of your [API](${manage_url}/#/apis) to review the available settings: + +- **Id**: A unique alphanumeric string generated by Auth0. The information is read only and you will only need it if you will be working directly with [Auth0's Management API Resource Servers endpoints](/api/management/v2#!/Resource_Servers/get_resource_servers_by_id). + +- **Name**: A friendly name for the API. Does not affect any functionality. The following characters are not allowed: `< >`. + +- **Identifier**: A unique identifier for your API. This value is set upon API creation and cannot be modified afterwards. We recommend using a URL but note that this doesn't have to be a publicly available URL, Auth0 will not call your API at all. + +- **Token Expiration (Seconds)**: The amount of time (in seconds) before the Auth0 Access Token expires. The default value is 86400 seconds (24 hours). The maximum value you can set is 2592000 seconds (30 days). + +- **Allow Skipping User Consent**: When a first party application requests authorized access against an API with the *Allow Skipping User Consent* flag set, the User Consent dialog will not be shown to the final user. Note that if the hostname of your application's **callback URL** is `localhost` or `127.0.0.1` the consent dialog will always be displayed. + +- **Allow Offline Access**: If this setting is enabled, Auth0 will allow applications to ask for Refresh Tokens for this API. + +- **Signing Algorithm**: The algorithm to sign the tokens with. The available values are `HS256` and `RS256`. When selecting `RS256` (recommended) the token will be signed with the tenant's private key. This value is set upon API creation and cannot be modified afterwards. To learn more about signing algorithms, see [Signing Algorithms](/tokens/concepts/signing-algorithms). + +## Keep reading + +- [API Authorization landing page](/api-auth) +- [Identify the proper OAuth 2.0 flow for your use case](/api-auth/which-oauth-flow-to-use) +- [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/blacklists-vs-grants.md b/fr-ca/articles/api-auth/blacklists-vs-grants.md new file mode 100644 index 0000000000..8a8fbedf29 --- /dev/null +++ b/fr-ca/articles/api-auth/blacklists-vs-grants.md @@ -0,0 +1,78 @@ +--- +description: Understand blacklists vs. grants when it comes handling tokens. +topics: + - api-authentication + - oidc + - security + - blacklists + - application-grants +contentType: concept +useCase: + - secure-api + - call-api +--- + +# Blacklists and Application Grants + +Let's say that you're using a machine to machine [application](/application) to access your API. You have a partner that calls your API, and at the end of your existing contract, you and your partner decide not to renew your partnership. As such, you now want to remove your partner's access to your API. The issue, however, is that you've given your partner an Access Token that lasts for a month. + +* What can you do in this situation? +* How might you configure your Auth0 environment to make such situations easier to handle in the future? + +In this article, we'll cover two methods for revoking access to the protected resource: + +* [Blacklisting the Access Token](#blacklists) +* [Revoking the application grant](#application-grants) + +We will then compare the two methods and provide our recommendations. + +## Blacklists + +Let's say that you grant access to your API to anyone in possession of the appropriate Access Token. One method of revoking access to a user is to blacklist their token so that it can no longer be used. + +Auth0-issued tokens are [JWTs](/tokens/concepts/jwts), so you can set the JWT ID, or `jti`, for the token by including it in the token payload's `jwtid` field. With the `jti` in hand, you can make the appropriate `POST` call to the Management API's [blacklist a token endpoint](/api/management/v2#!/Blacklists/post_tokens). You'll need to provide the JWT's `aud` and `jti` claims. + +::: panel Add a JWT ID +You can add `jti` via a [rule](/rules). Here's a simple example using UUID: + +```js +function (user, context, callback) { + user.jti = require('uuid').v4(); + callback(null, user, context); +} +``` +::: + +Your call might look something like this: + +```text +curl -H "Authorization: Bearer {JWT_API_KEY}" +-X POST +-H "Content-Type: application/json" +-d '{"aud":"u6nnAxGVjbBd8etXjj554YKGAG5HuVrp","jti":"test-token"}' +https://login.auth0.com/api/v2/blacklists/tokens +``` + +## Application Grants + +The main issue in this scenario is the length of time for which the API Access Token is valid: one month. + +By default, Auth0 issues Access Tokens that last for 24 hours. Setting the token's lifetime to 24 hours means that your partner must repeat the client credentials exchange (or whichever grant you've implemented) to obtain a new Access Token every 24 hours. To deny access to your partner due to the expiration of your contract, you can simply delete the application grant so that when their existing token expires, they cannot request a new one. + +You can change the lifetime of a token by setting the `token_lifetime` option. The specific lifetime appropriate to your use case will vary, but we recommend setting this value to be as short as possible. A good starting point for determining this value would be the window you consider allowable for the delay between deleting the grant and final use of the API. + +### Delete an Application Grant + +To delete an application grant, make the appropriate `DELETE` call to the Management API's [Delete an Application Grant endpoint](/api/management/v2#!/Client_Grants/delete_client_grants_by_id). + +::: note +For additional information, please see our docs on [APIs](/apis). +::: + +As part of the call, you'll need to specify the ID of the application grant you want to delete, which you can obtain via the Management API's [Get all Application Grants endpoint](/api/management/v2#!/Client_Grants/get_client_grants) or the Management Dashboard by going to *APIs > Machine to Machine Applications* and expanding the hidden information for the specific machine to machine application in question. + +## Blacklists vs. Application Grants + +For you to blacklist Access Tokens to revoke access, you'll need to identify and blacklist **every** token you've ever assigned to the company whom you no longer want accessing the API. This is because the Auth0 API asks for the tokens' `jti` values to compile the blacklist. As the number of tokens issued grows larger and larger, this method gets more and more difficult to implement and execute correctly. + +On the other hand, configuring your application grant so that the tokens you issue last for only a short period means that when it comes time for you to revoke access to a protected resource, you can simply delete the grant. At this point, the party with the Access Token only has a limited period between when you delete the grant and the token's expiration to make additional API requests. Because this is the easier (and safer) option to implement, we recommend you deny access to your APIs and other protected resources by revoking application grants. diff --git a/fr-ca/articles/api-auth/config/using-the-auth0-dashboard.md b/fr-ca/articles/api-auth/config/using-the-auth0-dashboard.md new file mode 100644 index 0000000000..dde2b216f6 --- /dev/null +++ b/fr-ca/articles/api-auth/config/using-the-auth0-dashboard.md @@ -0,0 +1,33 @@ +--- +description: How to set up a Client Grant using the Auth0 Dashboard +crews: crew-2 +topics: + - client-credentials + - api-authorization +contentType: how-to +useCase: secure-api +--- + +# Set Up Client Credentials Grants Using the Dashboard + +Auth0 lets you authorize applications that have the **Client Credentials** grant type enabled to call APIs using the [Client Credentials Flow](/flows/concepts/client-credentials). + +By default, the **Client Credentials** grant is enabled for all Machine-to-Machine Applications and Regular Web Applications, but they are _not yet_ authorized to call any API. + +To authorize the applications to call an API: + +1. Open the Auth0 Management Dashboard and browse to the [API section](${manage_url}/#/apis). + +2. Select the API you want to invoke using the **Client Credentials** Grant. + +3. Under the **Authorized Application** tab, look for the application you want to authorize, click the Authorize button, and optionally, select the list of scopes that will be granted in the Access Token. This will create a 'client grant' in Auth0, which will allow the application to call the API. + +![Authorize the Application](/media/articles/api-auth/apis-authorize-client-tab.png) + +4. In the Test tab, you can select the application to which you granted access, and see the Access Tokens that will be generated for it. + +## Keep reading + +* [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials) +* [Use Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks) +* [Add Custom Claims Tokens Using Rules](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) diff --git a/fr-ca/articles/api-auth/config/using-the-management-api.md b/fr-ca/articles/api-auth/config/using-the-management-api.md new file mode 100644 index 0000000000..fc9e75f35a --- /dev/null +++ b/fr-ca/articles/api-auth/config/using-the-management-api.md @@ -0,0 +1,69 @@ +--- +description: Learn how to set up a Client Credentials Grant using the Management API. +crews: crew-2 +topics: + - client-credentials + - api-authorization +contentType: how-to +useCase: secure-api +--- + +# Set Up Client Credentials Grants Using the Management API + +Auth0 lets you authorize applications that have the Client Credentials grant type enabled to call APIs using the [Client Credentials Flow](/flows/concepts/client-credentials). + +By default, all Machine-to-Machine Applications and Regular Web Applications have the 'Client Credentials' grant enabled, but they are not authorized to call any API. + +If you want to call an API from these applications, you first need to authorize the application to call the API and specify the scopes that will be granted. You can do that [using the Dashboard](/api-auth/config/using-the-auth0-dashboard), or follow the steps below to use the API. + +You will need the following: + +- A Management API Access Token with the `create:client_grants` scopes. For details on how to get one, refer to [Access Tokens for the Management API](/api/management/v2/tokens). + +- The application information (`Client_Id` and `Client_Secret`) for the application you want to authorize [Auth0 dashboard](${manage_url}/#/applications). + +- The API identifier for the API you want to invoke (${manage_url}/#/apis). + +## Authorize the Application + +To authorize your Application, send a `POST` request to the [/client-grants endpoint of the Management APIv2](/api/management/v2#!/Client_Grants/post_client_grants) with the Management API Access Token. + +The following example authorizes the application with Id `${account.clientId}`, to access the API with Identifier `https://my-api-urn`, while granting the scope `sample-scope`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/client-grants", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "authorization", "value": "Bearer Auth0_MGMT_API_ACCESS_TOKEN" } + ], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\",\"audience\": \"https://my-api-urn\",\"scope\":[\"sample-scope\"]}" + } +} +``` + +Sample response: + +```json +{ + "id": "cgr_JGa6ZckLjnt60rWe", + "client_id": "${account.clientId}", + "audience": "https://test-api", + "scope": [ + "sample-scope" + ] +} +``` + +That's it, you are done! Now that all the elements are in place, you can request Access Tokens for your API from Auth0 using the Client Credentials Flow. + +## Keep reading + +:::next-steps +* [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials) +* [How to change the scopes and add custom claims to a token using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) +* [How to add custom claims to a token using Rules](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) +::: diff --git a/fr-ca/articles/api-auth/dynamic-client-registration.md b/fr-ca/articles/api-auth/dynamic-client-registration.md new file mode 100644 index 0000000000..6bac759f08 --- /dev/null +++ b/fr-ca/articles/api-auth/dynamic-client-registration.md @@ -0,0 +1,148 @@ +--- +description: Learn how to dynamically register applications with Auth0 using the Management API. +crews: crew-2 +toc: true +topics: + - applications +contentType: how-to +useCase: + - secure-api + - call-api +--- + +# Dynamic Client Registration + +Dynamic Client Registration enables you to register [third-party applications](/applications/guides/enable-third-party-apps) dynamically. + +This feature is based on the [OpenID Connect Dynamic Client Registration specification](https://openid.net/specs/openid-connect-registration-1_0.html) and in this article we will see how you can enable and use it. + +## Enable dynamic registration + +::: warning +Auth0 supports **Open Dynamic Registration**, which means that if you enable this feature, **anyone** will be able to create applications in your tenant without a token. +::: + +By default, the feature is disabled for all tenants. To change this, you have to set the `enable_dynamic_client_registration` flag to `true` in your tenant's settings. + +This can be done by enabling the **OIDC Dynamic Application Registration** toggle on your tenant's [Advanced Settings page](${manage_url}/#/tenant/advanced). + +Alternatively, you can update this flag using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings). + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/tenants/settings", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"flags\": { \"enable_dynamic_client_registration\": true } }" + } +} +``` + +You need to update the `API2_ACCESS_TOKEN` with a valid token with the scope `update:tenant_settings`. See [Access Tokens for the Management API](/api/management/v2/tokens) for details on how to do so. + +## Use dynamic registration + +In this section we will see how you can dynamically register and configure an application. + +### Register your application + +To dynamically register an application with Auth0, you need to send an HTTP `POST` message to the Application Registration endpoint: `https://${account.namespace}/oidc/register`. Note that Auth0 supports **Open Dynamic Registration**, which means that the endpoint will accept a registration request without an Access Token. + +To create an application with the name `My Dynamic application` and the callback URLs `https://application.example.com/callback` and `https://application.example.com/callback2`, use the following snippet. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oidc/register", + "headers": [ + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{\"client_name\":\"My Dynamic Application\",\"redirect_uris\": [\"https://application.example.com/callback\", \"https://application.example.com/callback2\"]}" + } +} +``` + +Where: +- **client_name**: The name of the Dynamic Application to be created +- **redirect_uris** (required): An array of URLs that Auth0 will deem valid to call at the end of an authentication flow + +Optionally, you can set a value for `token_endpoint_auth_method`, which can be `none` or `client_secret_post` (default value). Use `token_endpoint_auth_method: none` in the request payload if creating a SPA. + +The response includes the basic application information. + +```json +HTTP/1.1 201 Created +Content-Type: application/json +{ + "client_name": "My Dynamic Application", + "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2", + "client_secret": "Q5O...33P", + "redirect_uris": [ + "https://application.example.com/callback", + "https://application.example.com/callback2" + ], + "client_secret_expires_at": 0 +} +``` + +Where: +- **client_id**: Unique client identifier. This is the ID you will use while configuring your apps to use Auth0. It is generated by the system and it cannot be modified. +- **client_secret**: Alphanumeric 64-bit client secret. This value is used by applications to authenticate to the [token endpoint](/api/authentication#get-token) and for signing and validating [ID Tokens](/tokens/concepts/id-tokens). +- **client_secret_expires_at**: Time at which the `client_secret` will expire. For Auth0 this value will always be zero (`0`) which means that the application never expires. + +Make a note of the Client ID and Secret, as these are the most important pieces for executing [authentication](/application-auth) and [authorization](/api-auth) flows. + +Also, keep in mind that third-party developers are not allowed to modify the application settings. In case this is necessary, they need to contact the tenant owner with their request. + +### Configure your application + +Now that you have a Client ID and Secret, you can configure your application to authenticate users with Auth0. + +We will go through a simple example, that shows how to call an API from a client-side web app, using the [Implicit Flow](/flows/guides/implicit/call-api-implicit). For a list of tutorials on how to authenticate and authorize users, based on your application type, see the [API Authorization](/api-auth) page. + +First, you need to configure your application to send the user to the authorization URL: + +```text +https://${account.namespace}/authorize? + audience={API_AUDIENCE}& + scope={SCOPE}& + response_type={RESPONSE_TYPE}& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + nonce={NONCE} + state={OPAQUE_VALUE} +``` + +Where: +- **audience** (optional): The target API for which the Application is requesting access on behalf of the user. Set this parameter if you need API access. +- **scope** (optional): The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must conform to a namespaced format (see panel below for more info), or any scopes supported by the target API (for example, `read:contacts`). Set this parameter if you need API access. + + ::: panel Custom claims namespaced format + In order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims) to avoid possible collisions with standard OpenID Connect claims. For example, if you choose the namespace `https://foo.com/` and you want to add a custom claim named `myclaim`, you would name the claim `https://foo.com/myclaim`, instead of `myclaim`. + ::: + +- **response_type**: The response type. For Implicit Grant you can either use `token` or `id_token token`. This will specify the type of token you will receive at the end of the flow. Use `token` to get only an Access Token, or `id_token token` to get both an ID Token and an Access Token. +- **client_id**: Your application's Client ID. +- **redirect_uri**: The URL to which the Authorization Server (Auth0) will redirect the User Agent (Browser) after authorization has been granted by the User. The Access Token (and optionally an ID Token) will be available in the hash fragment of this URL. This URL must be specified as a valid callback URL under the Application Settings of your application. +- **state**: An opaque value the applications add to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. +- **nonce**: A string value which will be included in the ID Token response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. + +For example: + +```html + + Sign In + +``` + +This call will redirect the user to Auth0, and upon successful authentication, back to your application (specifically to the **redirect_uri**). + +If you need API access, then following the authentication, you need to extract the Access Token from the hash fragment of the URL, and use it to make calls to the API, by passing it as a `Bearer` token in the `Authorization` header of the HTTP request. diff --git a/fr-ca/articles/api-auth/faq.md b/fr-ca/articles/api-auth/faq.md new file mode 100644 index 0000000000..d5fea1d7e6 --- /dev/null +++ b/fr-ca/articles/api-auth/faq.md @@ -0,0 +1,30 @@ +--- +description: API Authentication and Authorization FAQ +topics: + - api-authentication + - oidc + - user-consent + - resource-servers + - applications +contentType: concept +useCase: + - secure-api + - call-api +--- + +# API Authentication and Authorization FAQ + +## I have an Application that needs to talk to different Resource Servers + +If a single Application needs Access Tokens for different resource servers, then multiple calls to `/authorize` (that is, multiple executions of the same or different Authorization Flow) needs to be performed. Each authorization will use a different value for `audience`, which will result in a different Access Token at the end of the flow. + +For more information, see the [OAuth 2.0: Audience Information Specification](https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3). + +## Can I try the endpoints before I implement my application? + +Sure! You have two options: +- [Download our Postman collection](https://app.getpostman.com/run-collection/2a9bc47495ab00cda178). For more information on how to use our Postman collection refer to [Using the Auth0 API with our Postman Collections](/api/postman). + +- Use our [Authentication API Debugger Extension](/extensions/authentication-api-debugger). You can find detailed instructions per endpoint/grant at our [Authentication API Reference](/api/authentication). + - For the Authorize endpoint, go to [Authorize Application](/api/authentication#authorize-application) and read the _Test this endpoint_ paragraph for the grant you want to test. + - For the Token endpoint, go to [Get Token](/api/authentication#get-token) and read the _Test this endpoint_ paragraph for the grant you want to test. diff --git a/fr-ca/articles/api-auth/grant/authorization-code-pkce.md b/fr-ca/articles/api-auth/grant/authorization-code-pkce.md new file mode 100644 index 0000000000..fb575ab2c1 --- /dev/null +++ b/fr-ca/articles/api-auth/grant/authorization-code-pkce.md @@ -0,0 +1,61 @@ +--- +description: Describes the call APIs from mobile apps using the Authentication Code Grant (PKCE). +topics: + - authorization-code + - pkce + - api-authorization +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs from Mobile Apps + +To access an API from a [mobile app](/quickstart/native), you need to implement the **Authorization Code using Proof Key for Code Exchange (PKCE)** OAuth 2.0 grant. In this document, we will see how this flow works. + +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article. +::: + +## Overview of the flow + +The [Authorization Code Grant](/api-auth/grant/authorization-code) has some security issues when implemented on native applications. For instance, a malicious attacker can intercept the `authorization_code` returned by Auth0 and exchange it for an Access Token (and possibly a Refresh Token). + +The **Proof Key for Code Exchange (PKCE)** (defined in [RFC 7636](https://tools.ietf.org/html/rfc7636)) is a technique used to mitigate this authorization code interception attack. + +With PKCE, the application creates, for every authorization request, a cryptographically random key called `code_verifier` and its transformed value called `code_challenge`, which is sent to Auth0 to get the `authorization_code`. When the application receives the `authorization_code`, it will send the code and the `code_verifier` to Auth0's token endpoint to exchange them for the requested tokens. + +![Authorization Code Grant using PKCE](/media/articles/api-auth/authorization-code-grant-pkce.png) + + 1. The native application initiates the flow and redirects the user to Auth0 (specifically to the [/authorize endpoint](/api/authentication#authorization-code-grant-pkce-)), sending the `code_challenge` and `code_challenge_method` parameters. + + 2. Auth0 redirects the user to the native application with an `authorization_code` in the querystring. + + 3. The native application sends the `authorization_code` and `code_verifier` together with the `redirect_uri` and the `client_id` to Auth0. This is done using the [/oauth/token endpoint](/api/authentication?http#authorization-code-pkce-). + + 4. Auth0 validates this information and returns an Access Token (and optionally a Refresh Token). + + 5. The native application can use the Access Token to call the API on behalf of the user. + +::: note +In OAuth 2.0 terms, the native application is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server. +::: + +## How to implement the flow + +For details on how to implement this using Auth0, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce). + +## Rules + +[Rules](/rules) will run for the Authorization Code (PKCE) grant. If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant. + +For details on how to implement this, refer to [Execute an Authorization Code Grant Flow with PKCE: Customize the Tokens](/api-auth/tutorials/authorization-code-grant-pkce#optional-customize-the-tokens). + +## Keep reading + +::: next-steps +- [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) +- [How to configure an API in Auth0](/apis) +- [Tokens](/tokens) +- [Application Authentication for Mobile & Desktop Apps](/application-auth/mobile-desktop) +::: diff --git a/fr-ca/articles/api-auth/grant/authorization-code.md b/fr-ca/articles/api-auth/grant/authorization-code.md new file mode 100644 index 0000000000..45412c6e0b --- /dev/null +++ b/fr-ca/articles/api-auth/grant/authorization-code.md @@ -0,0 +1,59 @@ +--- +description: Describes how to call APIs from regular web apps using the Authentication Code Grant. +topics: + - authorization-code + - api-authorization +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs from Server-side Web Apps + +In order to access an API from a [regular web app](/quickstart/webapp), you need to implement the **Authorization Code** OAuth 2.0 grant. In this document we will see how this flow works. + +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article. +::: + +## Overview of the flow + +The **Authorization Code Grant** (defined in [RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.1)) is a flow where the browser receives an Authorization Code from Auth0 and sends this to the web app. The web app will then interact with Auth0 and exchange the Authorization Code for an [Access Token](/tokens/concepts/access-tokens), and optionally an [ID Token](/tokens/concepts/id-tokens) and a Refresh Token. The web app can now use this Access Token to call the API on behalf of the user. + +![Authorization Code Grant](/media/articles/api-auth/authorization-code-grant.png) + +1. The web app initiates the flow and redirects the browser to Auth0 (specifically to the [/authorize endpoint](/api/authentication#authorization-code-grant)), so the user can authenticate. + +1. Auth0 authenticates the user (via the browser). The first time the user goes through this flow a consent page will be shown where the permissions are listed that will be given to the application (for example: post messages, list contacts, and so forth). + +1. Auth0 redirects the user to the web app (specifically to the `redirect_uri`, as specified in the [/authorize request](/api/authentication#authorization-code-grant)) with an Authorization Code in the querystring (`code`). + +1. The web app sends the Authorization Code to Auth0 and asks to exchange it with an Access Token (and optionally an ID Token and a Refresh Token). This is done using the [/oauth/token endpoint](/api/authentication?http#authorization-code). When making this request, the web app authenticates with Auth0, using the Client Id and Client Secret. + +1. Auth0 authenticates the web app, validates the Authorization Code and responds back with the token. + +1. The web app can use the Access Token to call the API on behalf of the user. + +::: note +In OAuth 2.0 terms, the web app is the application, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server. +::: + + +## How to implement the flow + +For details on how to implement this using Auth0, refer to [Executing an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant). + +## Rules + +[Rules](/rules) will run for the Authorization Code grant. If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant. + +For details on how to implement this, refer to [Execute an Authorization Code Grant Flow: Customize the Tokens](/api-auth/tutorials/authorization-code-grant#optional-customize-the-tokens). + +## Keep reading + +::: next-steps +- [How to implement an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant) +- [How to configure an API in Auth0](/apis) +- [Tokens](/tokens) +- [Application Authentication for Server-side Web Apps](/application-auth/server-side-web) +::: diff --git a/fr-ca/articles/api-auth/grant/client-credentials.md b/fr-ca/articles/api-auth/grant/client-credentials.md new file mode 100644 index 0000000000..8fa8cd26d3 --- /dev/null +++ b/fr-ca/articles/api-auth/grant/client-credentials.md @@ -0,0 +1,42 @@ +--- +description: Describes how to call APIs from server processes using the Client Credentials Grant. +topics: + - client-credentials + - api-authorization +contentType: concept +useCase: + - secure-api + - call-api +--- +# Client Credentials Grant + +The **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) allows an application to request an Access Token using its __Client Id__ and __Client Secret__. It is used for non interactive applications (a CLI, a daemon, or a Service running on your backend) where the token is issued to the application itself, instead of an end user. + +In order to be able to perform the Client Credentials Grant, the Application needs to have the [Client Credentials grant type](/applications/concepts/application-grant-types) enabled. Machine to Machine Applications and Regular Web Applications have it enabled by default. + +## Client Credentials Grant Flow + +![Client Credentials Grant Flow](/media/articles/api-auth/client-credentials-grant.png) + +1. The application authenticates with Auth0 using its __Client Id__ and __Client Secret__. + +1. Auth0 validates this information and returns an Access Token. + +1. The application can use the Access Token to call the API on behalf of itself. + +::: note +In OAuth 2.0 terms, the application is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server. +::: + +## How to implement the flow + +For details on how to implement this using Auth0, refer to [Execute a Client Credentials Grant](/api-auth/tutorials/client-credentials). + +## Keep reading + +::: next-steps +- [How to implement a Client Credentials flow](/api-auth/tutorials/client-credentials) +- [How to configure an API in Auth0](/apis) +- [Tokens](/tokens) +- [How to change the scopes and add custom claims to the tokens using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) +::: diff --git a/fr-ca/articles/api-auth/grant/hybrid.md b/fr-ca/articles/api-auth/grant/hybrid.md new file mode 100644 index 0000000000..496e658d8b --- /dev/null +++ b/fr-ca/articles/api-auth/grant/hybrid.md @@ -0,0 +1,66 @@ +--- +description: Describes how to call APIs from applications using the Hybrid Flow +public: false +topics: + - authorization-code + - api-authorization + - implicit +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs Using the Hybrid Flow + +The Hybrid Flow is an OpenID Connect (OIDC) flow that draws from the following: + +1. [Authorization Code Flow](/flows/concepts/auth-code) +2. [Implicit Flow](/flows/concepts/implicit) + +The Hybrid Flow enables use cases where your application can immediately use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token (therefore gaining access to protected resources for an extended period of time). + +## Background + +With the [Authorization Code Flow](/flows/concepts/auth-code), Auth0 sends you an authorization code, which your app then sends in to retrieve tokens. Your application authenticates itself with a Client ID and Client Secret stored securely on your server. + +On the other hand, the [Implicit Flow](/flows/concepts/implicit) allows you to request Access Tokens without needing to authenticate your application. Auth0 verifies your app's identity based on the provided redirect URI. Because of this, you shouldn't utilize long-lived Access Tokens, and you cannot use Refresh Tokens. + +## The Hybrid Flow + +The Hybrid Flow allows you to take advantage of aspects of both the Authorization Code and Implicit Grants. For each interaction with Auth0, you will receive two (sometimes three) items in response: + +1. An authorization code and an Access Token +1. An authorization code and an ID Token +1. An authorization code, an Access Token, and an ID Token + +In this article, we will take a closer look at how this flow works. + +## Overview of the flow + +1. The web application initiates the authorization flow and redirects the browser to Auth0 (specifically, the [Authorization Endpoint](/api/authentication#authorization-code-grant)) so that the user can authenticate. + +1. Auth0 authenticates the user via the browser. If this is the first time the user does this, they will see a consent page listing the permissions that Auth0 will give to the application. + +1. Auth0 redirects the user to the app with an [Access Token](/tokens/access-token) and (optionally) an [ID Token](/tokens/concepts/id-tokens) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment. + +1. The application parses out the Authorization Code, sends it to Auth0's [token endpoint](/api/authentication?http#authorization-code), and requests that Auth0 return (in exchange) the Access Token. The application identifies itself during this request using its assigned Client ID and Client Secret. + +1. If the request sent to the token endpoint is valid, Auth0 responds to the application's request with an ID Token, as well as an Access Token (and possibly a Refresh Token). + +1. The application can now validate the ID Token and retrieve the end user's information. The application can also use the Access Token to call desired APIs. + + If the application received an ID Token from the Authorization endpoint already, it should have validated the token's signature, `c_hash`, and any other claims as defined. You must validate such tokens [the way you would for an Implicit Flow](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation). + +## How to implement the flow + +For details on how to implement this using Auth0, refer to [Execute the Hybrid Flow](/api-auth/tutorials/hybrid-flow). + +## Keep reading + +::: next-steps +- [Execute the Hybrid Flow](/api-auth/tutorials/hybrid-flow) +- [How to configure an API in Auth0](/apis) +- [Tokens](/tokens) +- [Application authentication for regular web apps](/flows/concepts/auth-code) +- [Application authentication for single-page apps](/flows/concepts/implicit) +::: \ No newline at end of file diff --git a/fr-ca/articles/api-auth/grant/implicit.md b/fr-ca/articles/api-auth/grant/implicit.md new file mode 100644 index 0000000000..bf1a08f84c --- /dev/null +++ b/fr-ca/articles/api-auth/grant/implicit.md @@ -0,0 +1,65 @@ +--- +title: Call APIs from Client-side Web Apps +description: Learn how to call APIs from client-side web apps using the OAuth 2.0 Implicit Grant. +toc: true +topics: + - implicit + - api-authorization +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs from Client-side Web Apps + +In order to access an API from a [client-side app](/quickstart/spa) (typically a Single-Page Application or a Mobile Application), you need to implement the OAuth 2.0 **Implicit Grant**. In this document we will see how this flow works. + +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article. +::: + +## Overview + +The **Implicit Grant** (defined in [RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.2)) is similar to the [Authorization Code Grant](/api-auth/grant/authorization-code), but the main difference is that the application receives an [Access Token](/tokens/concepts/access-tokens) directly, without the need for an `authorization_code`. This happens because the application, which is typically a JavaScript app running within a browser, is less trusted than a web app running on the server, hence cannot be trusted with the `client_secret` (which is required in the [Authorization Code Grant](/api-auth/grant/authorization-code)). Also, in the Implicit Grant, no Refresh Tokens are returned for the same reason (for an alternative refer to [Silent authentication for SPAs](/api-auth/tutorials/silent-authentication)). + +Once the user authenticates, the application receives the Access Token in the hash fragment of the URI. The application can now use this Access Token to call the API on behalf of the user. + +![Implicit Grant](/media/articles/api-auth/implicit-grant.png) + + 1. The app initiates the flow and redirects the browser to Auth0 (specifically to the [/authorize endpoint](/api/authentication#implicit-grant)), so the user can authenticate. + + 1. Auth0 authenticates the user. The first time the user goes through this flow a consent page will be shown where the permissions, that will be given to the Application, are listed (for example: post messages, list contacts, and so forth). + + 1. Auth0 redirects the user to the app with an [Access Token](/tokens/concepts/access-tokens) (and optionally an [ID Token](/tokens/concepts/id-tokens)) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment. In a Single-Page Application (SPA) this would be done using Javascript and in a Mobile Application this is typically handled by interacting with a Web View. + + 1. The app can use the Access Token to call the API on behalf of the user. + +::: note +In OAuth 2.0 terms, the web app is the Application, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server. +::: + +## How to implement the flow + +For details on how to implement this using Auth0, refer to [Execute an Implicit Grant](/api-auth/tutorials/implicit-grant). + +## Rules + +[Rules](/rules) will run for the Implicit grant. If you wish to execute special logic unique to the Implicit grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-implicit-profile`, then the rule is running during the Implicit grant. + +For details on how to implement this, refer to [How to implement the Implicit Grant: Customize the Tokens](/api-auth/tutorials/implicit-grant#optional-customize-the-tokens). + +## Silent Authentication + +If you need to authenticate your users without a login page (for example, when the user is already logged in via [Single Sign-on (SSO)](/sso) scenario) or get a new Access Token (thus simulate refreshing an expired token), you can use Silent Authentication. + +For details on how to implement this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication). + +## Keep reading + +::: next-steps +* [How to implement the Implicit Grant](/api-auth/tutorials/implicit-grant) +* [How to protect your SPA against replay attacks](/api-auth/tutorials/nonce) +* [How to configure an API in Auth0](/apis) +* [Tokens](/tokens) +* [Application Authentication for Client-side Web Apps](/application-auth/client-side-web) +::: diff --git a/fr-ca/articles/api-auth/grant/password.md b/fr-ca/articles/api-auth/grant/password.md new file mode 100644 index 0000000000..3da4c9a514 --- /dev/null +++ b/fr-ca/articles/api-auth/grant/password.md @@ -0,0 +1,67 @@ +--- +title: Call APIs from Highly Trusted Applications +description: Describes how to call APIs from highly trusted applications using the Resource Owner Password Grant. +topics: + - implicit + - api-authorization + - resource-owner-password +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs from Highly Trusted Applications + +<%= include('../_includes/_ropg-warning') %> + +You can use the ROPG flow for your highly trusted applications to access APIs. In this flow the end-user is asked to fill in credentials (username/password), typically using an interactive form. This information is sent to the backend and from there to Auth0. + +ROPG (defined in [RFC 6749, section 4.3](https://tools.ietf.org/html/rfc6749#section-4.3)) can be used directly as an authorization grant to store the user credentials for future use, by exchanging the credentials for an Access Token, and optionally a Refresh Token. + +![Resource Owner Password Grant](/media/articles/api-auth/password-grant.png) + + 1. The end user enters the credentials into the application. + 1. The application forwards the credentials to Auth0. + 1. Auth0 validates the information and returns an Access Token, and optionally a Refresh Token. + 1. The application can use the Access Token to call the API on behalf of the end user. + +::: note +In OAuth 2.0 terms, the web app is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server. +::: + +## How to implement the flow + +For details on how to implement this using Auth0, see [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant). + +## Realm support + +A extension grant that offers similar functionality with the **Resource Owner Password Grant**, including the ability to indicate a specific realm, is the `http://auth0.com/oauth/grant-type/password-realm`. + +Realms allow you to keep separate user directories and specify which one to use to the token endpoint. For example, you may have an application where both employees and customers can log in but their credentials are kept in separate user directories. You can present a user interface with a dropdown containing `Employees` or `Customers` as realms (which would be connections in [Auth0 dashboard](${manage_url})). The realm value, along with the username and password credentials, will be submitted to the token endpoint. Auth0 will use the realm value to determine which directory (connection) to use when verifying the password. + +For more information on how to implement this extension grant refer to [Executing a Resource Owner Password Grant > Realm Support](/api-auth/tutorials/password-grant#realm-support). + +## Scopes + +Due to the implied trust in these grants (a user providing his or her password to an application), the Access Token returned will include all of the available scopes defined for the audience API. An application can request a restricted set of scopes by using the `scope` parameter, or you can restrict the returned scopes by using a [rule](#customize-the-returned-token). + +## Rules + +[Rules](/rules) will run for the Password Exchange (including the Password Realm extension grant). There are two key differences in the behavior of rules in these flows: + +- Redirect rules won't work. If you try to do a [redirect](/rules/redirect) by specifying `context.redirect` in your rule, the authentication flow will return an error. + +If you wish to execute special logic unique to the Password exchange, you can look at the `context.protocol` property in your rule. If the value is `oauth2-password`, then the rule is running during the password exchange. + +For details on how to implement this, see [Customize the Tokens](/api-auth/tutorials/password-grant#optional-customize-the-tokens). + +## MFA support and anomaly detection + +For details on how to implement multi-factor authentication (MFA), refer to [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password). + +When using this flow from server-side applications, some anomaly detection features might fail because of the particularities of this scenario. For details on how to implement this, while avoiding some common issues, refer to [Using Resource Owner Password from Server side](/api-auth/tutorials/using-resource-owner-password-from-server-side). + +## Keep reading + +* [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant) +* [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/index.md b/fr-ca/articles/api-auth/index.md new file mode 100644 index 0000000000..2c2bdf84b6 --- /dev/null +++ b/fr-ca/articles/api-auth/index.md @@ -0,0 +1,178 @@ +--- +url: /api-auth +section: articles +classes: topic-page +title: API Authorization +topics: + - api-authentication + - oidc +contentType: index +useCase: + - secure-api + - call-api +--- + +
+
+

API Authorization

+

+ How to implement API authentication and authorization using the OAuth 2.0 authorization framework. +

+
+ +At some point, your custom APIs will need to allow limited access to users, servers, or servers on behalf of users. With Auth0 you can manage the authorization requirements for server-to-server and application-to-server applications. + +By using the OAuth 2.0 authorization framework, you can give your own applications or third-party applications limited access to your APIs on behalf of the application itself. With Auth0, you can easily support different flows in your own APIs without worrying about the OAuth 2.0/OpenID Connect (OIDC) specification, or the many other technical aspects of API authorization. + +In this page you can find a list of resources that can help you secure your APIs and access them in a secure manner. + + diff --git a/fr-ca/articles/api-auth/intro.md b/fr-ca/articles/api-auth/intro.md new file mode 100644 index 0000000000..77aa80441c --- /dev/null +++ b/fr-ca/articles/api-auth/intro.md @@ -0,0 +1,327 @@ +--- +description: An overview of the OIDC Conformant authentication flows, why these changes were made and how you can adopt them. +toc: true +topics: + - api-authentication + - oidc +contentType: concept +useCase: + - secure-api + - call-api +--- +# OIDC-Conformant Authentication Overview + +**Released Date**: May 10, 2017 + +As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. This document presents an overview of these changes, explains why they were made and points you to other detailed tutorials to help you adopt these changes. + +We will start by reviewing the [new features](#what-s-new), and then continue with [what changed](#what-is-changing) and how you can [distinguish which authentication flow is used](#how-to-use-the-new-flows) (the latest or the legacy). Towards the end of this doc, you can find a [summarizing table](#legacy-vs-new) and [links for further reading](#keep-reading). + +## What should I read? + +If you are new to Auth0, go through the [What’s New](#what-s-new) section of this doc. There you can find all the cool new features we introduced, like the ability to create APIs, call them from services, or enable external parties or partners to access protected resources at your API in a secure way. Then head off to the [How to use the new flows](#how-to-use-the-new-flows) section and make sure that your new implementation follows our latest, and more secure, authentication pipeline. + +If you are already using Auth0 in your app, you should read the complete doc. We have taken great care to make sure that we do not break our existing customers with this new OIDC conformant implementation. However, you should be aware of all changes and new features, and how you can use them (or avoid doing so). It goes without saying that we strongly encourage you to adopt this authentication pipeline, to improve your app’s security. + +If you are using Auth0 as a [SAML or WS-Federation identity provider](/protocols/saml/saml-idp-generic) for your application (that is, you're not using OIDC/OAuth), then you do not need to make any changes. + +## What's New + +### APIs Section in the Dashboard + +You can now define your resource server APIs as entities separate from applications using our new APIs dashboard area. + +![APIs Dashboard](/media/articles/api-auth/api-dashboard.png) + +This lets you decouple your resource server APIs from the applications that consume them and also lets you define third-party applications that you might not control or even fully trust (keep reading for more info). + +::: note +For more information on APIs, their role in OAuth and how to configure an API in Auth0 Dashboard, refer to [APIs Overview](/apis). +::: + +### Third-Party Applications + +Up until recently we were treating every application as first-party application. This means that all applications were considered trusted. Now you have the option to define an application as either first-party or third-party. + +Third-party applications are applications that are controlled by different people or organizations who most likely should not have administrative access to your Auth0 domain. They enable external parties or partners to access protected resources at your API in a secure way. A practical application of third-party applications is the creation of "developer centers", which allow users to obtain credentials in order to integrate their applications with your API. Similar functionality is provided by well-known APIs such as Facebook, Twitter, Github, and many others. + +So far, third-party applications cannot be created from the dashboard. They must be created through the management API. We have also implemented [Dynamic Client Registration](/api-auth/dynamic-client-registration) functionality. All applications registered through that will be third-party applications. + +::: note +For more information, refer to [User consent and third-party applications](/api-auth/user-consent). +::: + +### Calling APIs from a Service (machine to machine) + +We implemented the OAuth 2.0 Client Credentials grant which allows applications to authenticate as themselves (that is, not on behalf of any user), in order to programmatically and securely obtain access to an API. + +::: note +For more information on the Client Credentials grant, refer to [How to Implement the Client Credentials Grant](/flows/guides/client-credentials/call-api-client-credentials). +::: + +## What is Changing + +### Calling APIs with Access Tokens + +Historically, protecting resources on your API has been accomplished using ID Tokens issued to your users after they authenticate in your applications. From now on, you should only use Access Tokens when calling APIs. ID Tokens should only be used by the application to verify that the user is authenticated and get basic user information. The main reason behind this change is security. For details, refer to [Tokens](/tokens). + +::: note +For more information, refer to [Calling your APIs with Auth0 tokens](/api-auth/tutorials/adoption/api-tokens). +::: + +### User Profile Claims and Scope + +Historically, you were able to define and request arbitrary application-specific claims. From now on, your application can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), as [defined by the OIDC Specification](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims), or any scopes supported by your [API](/apis). + +In order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. + +To customize the tokens, use Hooks for the Client Credentials Flow, and Rules for the rest of the flows: +- __Client Credentials Flow__: [Customize Tokens using Hooks](/flows/guides/client-credentials/call-api-client-credentials#customize-tokens) +- __Trusted App Flow__: [Customize Tokens using Rules](/api-auth/grant/password#customizing-the-returned-tokens) +- __Single-Page Flow__: [Customize Tokens using Rules](/flows/guides/implicit/call-api-auth-code-pkce#customize-tokens) +- __Regular Web App Flow__: [Customize Tokens using Rules](/flows/guides/auth-code/call-api-auth-code#customize-tokens) +- __Native/Mobile Flow__: [Customize Tokens using Rules](/flows/guides/auth-code-pkce/call-api-auth-code-pkce#customize-tokens) + +::: note +For more information, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims). +::: + +### Single Sign-on (SSO) + +Initiating an Single Sign-on (SSO) session must now happen __only__ from an Auth0-hosted page and not from applications. This means that for SSO to work, you must be using Universal Login. Users must be redirected to the login page and then redirected to your application once authentication is complete. + +::: note +Support for SSO from applications is planned for a future release. +::: + +Not all [OAuth 2.0 grants](/protocols/oauth2#authorization-grant-types) support SSO at the moment: + + + + + + + + + + + + + + + + + + + + + + + + + + +
OAuth 2.0 GrantSupports SSO?
Authorization CodeYes
Authorization Code (PKCE)Yes
ImplicitYes
Resource Owner PasswordNo
+ +::: note +For more information, refer to [OIDC Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on). +::: + +### Authorization Code Grant + +Some changes were introduced in the implementation of Authorization Code grant: + +- The `device` request parameter has been removed. +- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued. +- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter. +- A Refresh Token will be returned only if the `offline_access` scope was granted. + +::: note +For more information, refer to [Authorization Code grant](/api-auth/tutorials/adoption/authorization-code). +::: + +### Implicit Grant + +Some changes were introduced in the implementation of Implicit grant: + +- The `device` request parameter has been removed. +- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued. +- The `response_type` request parameter indicates whether we want to receive both an Access Token and ID Token. If using `response_type=id_token`, we will return only an ID Token. +- Refresh Tokens are not allowed. [Use `prompt=none` instead](/api-auth/tutorials/silent-authentication). +- The `nonce` request parameter must be a [cryptographically-secure random string](/api-auth/tutorials/nonce). After validating the ID Token, the application must [validate the nonce to mitigate replay attacks](/api-auth/tutorials/nonce). Requests made without a `nonce` parameter will be rejected. +- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter. +- ID Tokens will be signed asymmetrically using `RS256`. + +::: note +For more information, refer to [Implicit grant](/api-auth/tutorials/adoption/implicit). +::: + +### Resource Owner Password Grant + +Some changes were introduced in the implementation of Resource Owner Password grant: + +- The `device` request parameter has been removed. +- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued. +- The endpoint to execute token exchanges is [/oauth/token](/api/authentication#resource-owner-password). +- [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (`realm`). The [standard OIDC password grant](/api-auth/tutorials/password-grant) is also supported, but it does not accept Auth0-specific parameters such as `realm`. +- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter. +- The ID Token will be forcibly signed using `RS256` if requested by a [public application](/applications/concepts/app-types-confidential-public#public-applications). +- A Refresh Token will be returned only if the `offline_access` scope was granted. + +::: note +For more information, refer to [Resource Owner Password Credentials exchange](/api-auth/tutorials/adoption/password). +::: + +### Delegation + +<%= include('../_includes/_deprecate-delegation') %> + +[Delegation](/api/authentication#delegation) is used for many operations: +- Exchanging an ID Token issued to one application for a new one issued to a different application +- Using a Refresh Token to obtain a fresh ID Token +- Exchanging an ID Token for a third-party API token, such as Firebase or AWS. + +Given that [ID Tokens should no longer be used as API tokens](/api-auth/tutorials/adoption/api-tokens) and that [Refresh Tokens should be used only at the token endpoint](/api-auth/tutorials/adoption/refresh-tokens), this endpoint is now considered deprecated. + +### Passwordless + +Our new implementation only supports an [OIDC-conformant](/api-auth/tutorials/adoption) passwordless authentication mechanism when using web applications (with Lock.js or auth0.js). + +Native applications need to use Universal Login (with an Auth0-hosted login page). Customers can use the Lock (Passwordless) template in the [Dashboard](${manage_url}/#/login_settings) under **Universal Login -> Login -> Default Templates**, or customize it to fit specific requirements. + +### Other Authentication API endpoints + +- [/tokeninfo](/api/authentication#get-token-info): With the new implementation, this endpoint is disabled. + +- [/userinfo](/api/authentication#get-user-info): Responses will conform to the OIDC specification, similar to the contents of ID Tokens. + +- [/oauth/access_token](/api/authentication#social-with-provider-s-access-token): The [/oauth/access_token](/api/authentication#social-with-provider-s-access-token) endpoint, used on native social authentication on mobile devices (for example, use the Facebook SDK and then this endpoint to create the user in Auth0), is now disabled. The alternative is to open the browser to do social authentication, which is what [Google and Facebook are recommending](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html) since last year. + +- [/oauth/ro](/api/authentication#resource-owner): This endpoint will soon be deprecated. Use the password grant instead. Note that the password grant should be used only by highly trusted applications, with the current exception of native apps (not with SPAs). This grant's best use is to be called from the server-side of a regular web app or perhaps the backend API of a SPA. For more information on this grant refer to [Call APIs from Highly Trusted Applications](/api-auth/grant/password). + +## How to use the new flows + +To use the new pipeline, at least one of the following should apply: + +- The application is flagged as __OIDC Conformant__, or +- The `audience` parameter is set in the [/authorize](/api/authentication#authorize-application) or [/token](/api/authentication#get-token) endpoints + +If none of these applies, then the legacy flows will be used. + +To mark your application as OIDC Conformant: go to [Dashboard](${manage_url}) > click [Applications](${manage_url}/#/applications) > select your application > go to _Settings_ > click the _Show advanced settings_ link at the end > click _OAuth_ > toggle the __OIDC Conformant__ flag. + +![OIDC Conformant flag](/media/articles/api-auth/oidc-conformant-flag.png) + +To use the `audience` parameter instead, configure your app to send it when initiating an authorization request. + +## Legacy vs New + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LegacyOIDC
Define APIs in the DashboardNot SupportedSupported
Third-party ApplicationsNot SupportedSupported
Client Credentials GrantThis grant does not exist in the legacy pipeline, but the Resource Owner Password Credentials exchange can be used to simulate it by creating a "service user". We strongly discourage the latter approach in favor of using Client Credentials, since it allows defining fine-grained permissions for each API application.Supported
Token used to call an APIID TokenAccess Token
Add arbitrary claims in TokensSupportedSupported. The namespaced format has to be used.
SSOSupportedNot supported for Resource Owner grant. For the rest, Universal Login must be employed and users redirected to the login page. +
Access Token formatOpaque stringJWT for customer APIs, opaque string for /userinfo only
Authenticate users from a specific connection (realm)Supported (using /oauth/ro)New password-realm extension grant
PasswordlessSupportedNot supported at the moment, will be in future releases
/tokeninfo endpointSupportedDisabled
/delegation endpointSupportedShould only be used to obtain third-party API tokens. A new mechanism will be provided in future releases.
/oauth/access_token endpointSupportedDisabled, an alternative will be added in future releases
/userinfo endpointSupportedSupported. Responses will conform to the OIDC specification, similar to the contents of ID Tokens.
Refresh Tokens with Implicit GrantSupportedDeprecated. Silent authentication should be used instead.
/ssodata endpoint and getSSOData() method from auth0.js + Supported (up to auth0.js v8)Deprecated. Silent authentication should be used instead.
Implicit Grant requests without nonce parameter setSupportedWill be rejected.
device parameter (used to obtain Refresh Tokens)SupportedNot supported. /oauth/token +should be used instead with "grant_type": "refresh_token"
/oauth/ro endpointSupportedReplaced with Password Grant
+ +## Keep reading + +* [API Authorization index](/api-auth) +* [Tokens](/tokens) + diff --git a/fr-ca/articles/api-auth/passwordless.md b/fr-ca/articles/api-auth/passwordless.md new file mode 100644 index 0000000000..cc007bfeb4 --- /dev/null +++ b/fr-ca/articles/api-auth/passwordless.md @@ -0,0 +1,27 @@ +--- +title: Passwordless authentication (OIDC-conformant) +topics: + - api-authentication + - oidc + - passwordless +contentType: concept +useCase: + - secure-api + - call-api +--- + +# OIDC Conformant Passwordless Authentication + +<%= include('./tutorials/adoption/_about.md') %> + +Passwordless connections allow users to login without the need to remember a password. + +This improves the user experience, especially on mobile applications, since users will only need to remember an email address or phone number to authenticate with your application. + +Without passwords, your application will not need to implement a password-reset procedure, and users avoid the insecure practice of using the same password for many purposes. + +## OIDC Conformant Passwordless + +Auth0 currently supports [OIDC-conformant](/api-auth/tutorials/adoption) passwordless authentication using Universal Login as well as in embedded web authentication scenarios using the newest [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js) libraries. + +Native applications need to use Universal Login. Customers can use the Lock (Passwordless) template for the login page in the [Dashboard](${manage_url}) under **Universal Login > Login > Default Templates**, or customize the page to fit specific requirements. diff --git a/fr-ca/articles/api-auth/restrict-access-api.md b/fr-ca/articles/api-auth/restrict-access-api.md new file mode 100644 index 0000000000..ae857bd87b --- /dev/null +++ b/fr-ca/articles/api-auth/restrict-access-api.md @@ -0,0 +1,83 @@ +--- + title: Restrict Access to APIs + description: Learn how to write rules that will restrict user/application access to an API. + topics: + - api-authentication + - oidc + - scopes + - permissions +contentType: how-to +useCase: + - secure-api + - call-api +--- + +# Restrict Access to APIs + +Sometimes you may not want to allow an application or user to access an API. For example, you may want to restrict access to an API based on the calling application or a user's role or location. To do so, we use [rules](/rules). + +## Example: Deny access to anyone calling the API + +In this example, we want to deny access to all users who are calling the API. To do this, we create a [rule](/rules) to deny access depending on the `audience` parameter. In this case, the `audience` value for our API is `http:://todoapi2.api`, so this is the audience we will refuse. + +::: note +The value of an API's `audience` is displayed in the **API Audience** field in the [APIs section of the Auth0 Dashboard](${manage_url}/#/apis). +::: + +When a restricted user attempts to access the API, they will receive an `HTTP 401` response. + +```js +function (user, context, callback) { + + /* + * Denies access to user-based flows based on audience + */ + + var audience = ''; + + audience = audience + || (context.request && context.request.query && context.request.query.audience) + || (context.request && context.request.body && context.request.body.audience); + + if (audience === 'http://todoapi2.api' || !audience) { + return callback(new UnauthorizedError('end_users_not_allowed')); + } + + return callback(null, user, context); +} +``` + +## Example: Deny access to users from a specific calling application + +In this example, we want to deny access to all users who are accessing the API from a specific calling application. To do this, we create a [rule](/rules) to deny access depending on the `client_id` parameter. This is equivalent to disabling all connections for an application. + +::: note +The value of an application's `client_id` is displayed in the **Client ID** field in the [Applications section of the Auth0 Dashboard](${manage_url}/#/applications). +::: + +When a restricted user attempts to access the API, they will receive an `HTTP 401` response. + +```js +function (user, context, callback) { + + /* + * Denies access to user-based flows based on client ID + */ + + var client_id = ''; + client_id = context.clientID; + + if (client_id === 'CLIENT_ID') { + return callback(new UnauthorizedError('end_users_not_allowed')); + } + + return callback(null, user, context); +} +``` +## Example: Deny access to users based on a role + +By default, any user associated with an [Auth0 application](/applications) can request any [custom API scopes](/scopes/current/api-scopes) that have been created. Sometimes you may not want to allow a user to request certain scopes, though. + +To limit a user's scopes, you can assign them a role so that requests on their behalf are limited to just the scopes assigned to that role. To do this, you can use the [Authorization Extension](/extensions/authorization-extension) and a custom [Rule](/rules). + +We discuss this approach in more depth in our [SPA+API Architecture Scenario](/architecture-scenarios/spa-api). Specifically, you can review the [Configure the Authorization Extension](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension) section to learn how to configure the Authorization Extension and create a custom Rule that will ensure scopes are granted based on a user's role. diff --git a/fr-ca/articles/api-auth/token-renewal-in-safari.md b/fr-ca/articles/api-auth/token-renewal-in-safari.md new file mode 100644 index 0000000000..88742f553a --- /dev/null +++ b/fr-ca/articles/api-auth/token-renewal-in-safari.md @@ -0,0 +1,56 @@ +--- +description: Issues with token renewal in Safari when ITP is enabled. +topics: + - safari + - tokens + - token-renewal + - custom-domains +contentType: concept +useCase: + - secure-api + - call-api +--- +# Renew Tokens When Using Safari + +Renewing tokens with the `checkSession()` function does not work correctly with the latest version of the Safari browser. + +Recent versions of the Safari browser introduced a new featured called [Intelligent Tracking Prevention (ITP)](https://webkit.org/blog/category/privacy/). ITP is designed to prevent websites from tracking user activity across multiple websites. + +By default, ITP is active. You can determine if the Safari version you are using has ITP by going to **Preferences > Privacy** tab and seeing if the **Prevent cross-site tracking** option is checked. + +![Safari privacy preferences pane](/media/articles/api-auth/safari-privacy-preferences.png) + +## ITP and browser behavior + +Enabling ITP causes the browser to behave as if you had disabled third-party cookies in the browser: **checkSession()** is unable to access the current user's session, which makes it impossible to obtain a new token without displaying anything to the user. + +This is akin to the way OpenID Connect (OIDC) uses iframes for handling [sessions](/sessions) in SPAs. + +## Workarounds + +Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies. You can use [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) as an alternative that provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP. + +Alternatively, you can work around the issues posed by ITP by using Auth0's [custom domains](/custom-domains) functionality, particularly if the custom domain lives on a *subdomain* of the application's website domain. For example, if your application is hosted on **example.com**, the custom domain would need to be of the format **subdomain.example.com**. + +## ITP debug mode + +[Safari Technology Preview](https://developer.apple.com/safari/technology-preview/) offers an "Intelligent Tracking Prevention Debug Mode" that you can use to troubleshoot ITP issues. You can find instructions on how to debug ITP on [this blog post from WebKit](https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62/). + +**NOTE**: The instructions mention how to permanently classify a custom domain as having tracking abilities for testing purposes. In later versions of Safari Technology Preview, though, the domain to store the User Defaults for this setting changed from `com.apple.SafariTechnologyPreview` to `com.apple.WebKit.Networking`. If you are having trouble with the commands mentioned in the instructions, try these: + +* Classify a site as having tracking abilities: +``` +defaults write com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource example.com +``` + +* Inspect the setting: +``` +defaults read com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource +``` + +* Delete the setting: +``` +defaults delete com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource +``` + +You will need to restart Safari Technology Preview every time you make changes for the settings to take effect. diff --git a/fr-ca/articles/api-auth/tutorials/adoption/_about.md b/fr-ca/articles/api-auth/tutorials/adoption/_about.md new file mode 100644 index 0000000000..e2f174b015 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/_about.md @@ -0,0 +1,4 @@ +:::panel Adoption Guide +This document is part of the adoption guide for OIDC-conformant authentication. +If you haven't already, we strongly suggest [reading the introduction](/api-auth/tutorials/adoption) before reading this document. +::: diff --git a/fr-ca/articles/api-auth/tutorials/adoption/_index.md b/fr-ca/articles/api-auth/tutorials/adoption/_index.md new file mode 100644 index 0000000000..40760b5d79 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/_index.md @@ -0,0 +1,13 @@ +* [Call APIs with Auth0 Tokens](/api-auth/tutorials/adoption/api-tokens) +* [User Consent and Third-Party Applications](/api-auth/user-consent) +* [User Profile Claims and the `scope` Parameter](/api-auth/tutorials/adoption/scope-custom-claims) +* [Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on) +* Initiating authentication flows: + - [Authorization Code Grant](/api-auth/tutorials/adoption/authorization-code) + - [Implicit Grant](/api-auth/tutorials/adoption/implicit) + * [Silent Authentication](/api-auth/tutorials/silent-authentication) (replaces Refresh Tokens for single-page applications) + - [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password) + - [Client Credentials Exchange](/api-auth/tutorials/adoption/client-credentials) (only available in new pipeline) +* [Refresh Tokens](/api-auth/tutorials/adoption/refresh-tokens) +* [Passwordless Authentication](/api-auth/passwordless) +* [OIDC-Conformant Applications](/api-auth/tutorials/adoption/oidc-conformant) diff --git a/fr-ca/articles/api-auth/tutorials/adoption/api-tokens.md b/fr-ca/articles/api-auth/tutorials/adoption/api-tokens.md new file mode 100644 index 0000000000..8c310789ec --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/api-tokens.md @@ -0,0 +1,112 @@ +--- +title: Call APIs with Auth0 Tokens +description: The OIDC-conformant pipeline and how this affects your use of Auth0 tokens with external APIs +topics: + - tokens + - access-tokens + - id-tokens + - scopes + - api-authentication + - oidc +contentType: concept +useCase: + - secure-api + - call-api +--- +# Call APIs with Auth0 Tokens + +<%= include('./_about.md') %> + +With the OIDC-conformant pipeline, all APIs should be secured with Access Tokens, not ID Tokens. In this article, we discuss what this means and what you need to do if you're using Auth0 tokens with your APIs. + +## OIDC-conformant pipeline and tokens + +In the OIDC-conformant pipeline, **ID Tokens should never be used as API tokens**. + +Instead, applications and APIs (resource services) should be defined as separate Auth0 entities. This allows you to obtain Access Tokens for your APIs. + +You get simpler API integration since your APIs are no longer tied to the applications that make calls to it. You're also enabling [machine-to-machine integration scenarios](/flows/concepts/client-credentials), since applications +can authenticate as themselves (that is, they are not acting on behalf of any user) to programmatically and securely obtain an API token. + +For example, [the Auth0 Management API is already defined as a resource server on your +Auth0 domain](${manage_url}/#/apis/management/settings). You can then authorize applications seeking access to obtain API tokens with specific scopes in a secure way. + +### Access vs. ID Tokens + +One way to understand how Access and ID Tokens differ in their behavior is to look at the contents of the tokens themselves. + +**The ID Token** + +```json +{ + "iss": "http://my-domain.auth0.com", + "sub": "auth0|123456", + "aud": "my_client_id", + "exp": 1311281970, + "iat": 1311280970, + "name": "Jane Doe", + "given_name": "Jane", + "family_name": "Doe", + "gender": "female", + "birthdate": "0000-10-31", + "email": "janedoe@example.com", + "picture": "http://example.com/janedoe/me.jpg" +} +``` + +The sample above shows the contents of an ID Token. ID Tokens are meant only for **authenticating** the users to the **application**. + +Note that the audience value (located in the **aud** claim) of the token is set to the application's identifier. This means that only this specific application should consume the token. + +You can think of the ID Token as a performance optimization that allows applications to obtain user profile information without making additional requests after the completion of the authentication process. ID Tokens should never be used to obtain direct access to resources or to make authorization decisions. + +**The Access Token** + +Let's now take a look at the contents of an Access Token: + +```json +{ + "iss": "https://my-domain.auth0.com/", + "sub": "auth0|123456", + "aud": [ + "https://example.com/health-api", + "https://my-domain.auth0.com/userinfo" + ], + "azp": "my_client_id", + "exp": 1311281970, + "iat": 1311280970, + "scope": "openid profile read:patients read:admin" +} +``` + +The Access Token is meant to **authorize** the user to the **API (resource server)**. As such, the token is **Completely opaque to applications** -- applications should not care about the contents of the token. + +The token does not contain any information about the user except for the user ID (located in the **sub** claim). The token only contains authorization information about the actions that application is allowed to perform at the API (such permissions are referred to as **scopes**). + +In many cases, you may find it useful to retrieve additional user information. You can do this by calling the [/userinfo API endpoint](/api/authentication#get-user-info) with the Access Token. Be sure that the API for which the Access Token is issued uses the **RS256** [signing algorithm](/tokens/concepts/signing-algorithms). + +## Scopes + +With the OIDC-conformant pipeline, the **scope** parameter [behaves differently](/api-auth/tutorials/adoption/scope-custom-claims) from the **scope** parameter associated with the legacy pipeline. + +The scope parameter in the OIDC-conformant pipeline determines: + +* The permissions that an authorized application should have for a given resource server +* Which standard profile claims should be included in the ID Token (if the user consents to provide this information to the application) + +If you have multiple apps calling an API under a single client ID, you should represent each application with a single Auth0 application, each of which can interact with the resource server representing the API on which these apps depend. + +Similarly, if you use delegation to exchange tokens obtained by one application for tokens for a different application, you should also be using a multi-application solution, each authenticating to the same resource server. + +If your applications do not depend on external APIs and you just need to authenticate users, you do not need to define a resource server/API as long as the ID Tokens are: + +* Processed only by the application +* Not sent to any external services + +::: note +For more information on API authentication and authorization refer to API Authorization. +::: + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/authorization-code.md b/fr-ca/articles/api-auth/tutorials/adoption/authorization-code.md new file mode 100644 index 0000000000..073cef649a --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/authorization-code.md @@ -0,0 +1,235 @@ +--- +description: OIDC-conformant Authorization Code grant +topics: + - api-authentication + - oidc + - authorization-code +contentType: concept +useCase: + - secure-api + - call-api +--- + +# Authorization Code Grant + +<%= include('./_about.md') %> + +The [Authorization Code Grant](/flows/concepts/auth-code) is used by server-side applications that are capable of securely storing secrets, or by [native applications through PKCE](/flows/concepts/auth-code-pkce). +This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines. + +## Authentication request + +
+
+ +
+
+
+ 
GET /authorize?
+    response_type=code
+    &scope=openid email favorite_color offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com/callback
+    &device=my-device-name
+ +
+
+ 
GET /authorize?
+    response_type=code
+    &scope=openid email offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com/callback
+    &audience=https://api.example.com
+
    +
  • favorite_color is no longer a valid scope value.
    • +
  • The device parameter is removed.
    • +
  • The audience parameter is optional.
    • +
+
+
+
+ +## Authentication response + +The response from Auth0 is identical in both pipelines: + +```text +HTTP/1.1 302 Found +Location: https://app.example.com/callback? + code=SplxlOBeZQQYbYS6WxSbIA + &state=af0ifjsldkj +``` + + +## Code exchange request + +An authorization code can be exchanged in the same way in both pipelines: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData" : { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "${account.callback}" + } + ] + } +} +``` + +## Code exchange response + +
+
+ +
+
+
+ 
HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "SlAV32hkKG",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
+
    +
  • The returned Access Token is only valid for calling the /userinfo endpoint.
    • +
  • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
    • +
+
+
+ 
HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "eyJ...",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
+
    +
  • The returned Access Token is valid for optionally calling the API specified in the audience parameter and the /userinfo endpoint (provided that the API uses RS256 as the signing algorithm and openid is used as a scope parameter). If you are not implementing your own Resource Server (API), then you can use https://{$account.namespace}/userinfo as the audience parameter, which will return an opaque Access Token.
    • +
  • A Refresh Token will be returned only if the offline_access scope was granted.
    • +
+
+
+
+ +## ID Token structure + +
+
+ +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue"
+}
+
    +
  • The favorite_color claim must be namespaced and added through a rule.
    • +
+
+
+
+ +## Access Token structure (optional) + +
+
+ +
+
+
+ 
SlAV32hkKG
+
    +
  • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
    • +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
+
    +
  • The returned Access Token is valid for optionally calling the API specified in the audience parameter and the /userinfo endpoint (provided that the API uses RS256 as the signing algorithm and openid is used as a scope parameter). If you are not implementing your own Resource Server (API), then you can use https://{$account.namespace}/userinfo as the audience parameter, which will return an opaque Access Token.
    • +
+
+
+
+ +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/client-credentials.md b/fr-ca/articles/api-auth/tutorials/adoption/client-credentials.md new file mode 100644 index 0000000000..bc6189bcf3 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/client-credentials.md @@ -0,0 +1,29 @@ +--- +title: Client Credentials exchange +topics: + - api-authentication + - oidc + - client-credentials +contentType: concept +useCase: + - secure-api + - call-api +--- + +# Client Credentials Exchange + +<%= include('./_about.md') %> + +The [Client Credentials exchange](/flows/concepts/client-credentials) allows apps to authenticate as themselves (that is, not on behalf of any user) to programmatically and securely obtain access to an API. + +This exchange does not exist in the legacy pipeline, but the [Resource Owner Password Credentials exchange](/api-auth/tutorials/adoption/password) can be used to simulate it by creating a "service user". + +We strongly discourage the latter approach in favor of using Client Credentials, since it allows defining fine-grained permissions for each API app. + +::: note + For more information on how to execute a Client Credentials exchange, refer to Call API Using the Client Credentials Flow. +::: + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/delegation.md b/fr-ca/articles/api-auth/tutorials/adoption/delegation.md new file mode 100644 index 0000000000..8fea9b651a --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/delegation.md @@ -0,0 +1,37 @@ +--- +title: Delegation and the OIDC-conformant pipeline +topics: + - api-authentication + - oidc + - delegation +contentType: concept +useCase: + - secure-api + - call-api +--- + +# Delegation and the OIDC-Conformant Pipeline + +<%= include('../../../_includes/_deprecate-delegation') %> + +<%= include('./_about.md') %> + +[Delegation](/api/authentication#delegation) is used for many operations, depending on your particular use case: + +* Exchanging an ID Token issued to one application for a new one issued to a different application +* Using a Refresh Token to obtain a fresh ID Token +* Exchanging an ID Token for a third-party API token, such as Firebase or AWS. + +Given that [ID Tokens should no longer be used as API tokens](/api-auth/tutorials/adoption/api-tokens) and that [Refresh Tokens should be used only at the token endpoint](/api-auth/tutorials/adoption/refresh-tokens), this endpoint is now considered deprecated. + +Applications marked as [OIDC-conformant](/api-auth/tutorials/adoption/oidc-conformant) cannot be the source or target of Auth0-to-Auth0 delegation requests. + +## Third-party APIs (such as Firebase or AWS) + +At the moment there is no OIDC-compliant mechanism to obtain third-party API tokens. +In order to facilitate a gradual migration to the new authentication pipeline, delegation can still be used to obtain third-party API tokens. +This will be deprecated in future releases. + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/implicit.md b/fr-ca/articles/api-auth/tutorials/adoption/implicit.md new file mode 100644 index 0000000000..451729f8b3 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/implicit.md @@ -0,0 +1,185 @@ +--- +description: Understand how the implicit grant is used by apps that are incapable of securely storing secrets such as SPA JS apps. +topics: + - api-authentication + - oidc + - implicit +contentType: concept +useCase: + - secure-api + - call-api +--- + +# Implicit Grant + +<%= include('./_about.md') %> + +The [Implicit grant](/flows/concepts/implicit) is used by applications that are incapable of securely storing secrets, such as single-page JavaScript applications. +This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines. + +## Authentication request + +
+
+ +
+
+
+ 
GET /authorize?
+    response_type=token
+    &scope=openid email favorite_color offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com
+    &device=my-device-name
+ +
+
+ 
GET /authorize?
+    response_type=token id_token
+    &scope=openid email
+    &client_id=123
+    &state=af0ifjsldkj
+    &nonce=jxdlsjfi0fa
+    &redirect_uri=https://app.example.com
+    &audience=https://api.example.com
+
    +
  • This response_type parameter indicates that we want to receive both an Access Token and ID Token.
    • +
  • Refresh Tokens are not allowed in the implicit grant. Use prompt=none instead.
    • +
  • favorite_color is no longer a valid scope.
    • +
  • The audience parameter is optional.
    • +
  • The nonce parameter must be a cryptographically-secure random string.
    • +
+
+
+
+ +## Authentication response + +
+
+ +
+
+
+ 
HTTP/1.1 302 Found
+Location: https://app.example.com/#
+    access_token=SlAV32hkKG
+    &expires_in=86400
+    &state=af0ifjsldk
+    &id_token=eyJ...
+    &refresh_token=8xLOxBtZp8
+    &token_type=Bearer
+
    +
  • The returned Access Token is valid for calling the /userinfo endpoint.
    • +
  • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
    • +
+
+
+ 
HTTP/1.1 302 Found
+Location: https://app.example.com/#
+    access_token=eyJ...
+    &expires_in=86400
+    &state=af0ifjsldk
+    &id_token=eyJ...
+    &token_type=Bearer
+
    +
  • The returned Access Token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
    • +
  • If using response_type=id_token, Auth0 will only return an ID Token.
    • +
  • Refresh Tokens are not allowed in the implicit grant. Use prompt=none instead.
    • +
+
+
+
+ + +## ID Token structure + +
+
+ +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue",
+    "nonce": "jxdlsjfi0fa"
+}
+ +
+
+
+ +## Access Token structure (optional) + +
+
+ +
+
+
+ 
SlAV32hkKG
+
    +
  • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
    • +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
+
    +
  • The returned Access Token is a JWT valid for calling the /userinfo endpoint(provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
    • +
  • Note that an opaque Access Token could still be returned if /userinfo is the only specified audience.
    • +
+
+
+
+ +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/index.md b/fr-ca/articles/api-auth/tutorials/adoption/index.md new file mode 100644 index 0000000000..eb7827dc97 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/index.md @@ -0,0 +1,57 @@ +--- +url: /api-auth/tutorials/adoption +title: OIDC Conformant Authentication Adoption Guide +topics: + - api-authentication + - oidc +contentType: concept +useCase: + - secure-api + - call-api +--- + +# OIDC Conformant Authentication Adoption Guide + +Auth0 is a [certified OpenID Connect (OIDC) provider](http://openid.net/certification/), but not all Auth0 documentation and features conform to the [OIDC specification](http://openid.net/specs/openid-connect-core-1_0.html). + +As part of our efforts to improve security and standards-based interoperability, we are rolling out new features exclusively on authentication flows that strictly conform to specifications. The first of these features is [API Authentication and Authorization](/api-auth), which is available today. + +This guide details all the upcoming changes, **some of which will be breaking**, and provides suggestions on how to adapt your existing applications. + +## Who is this guide for? + +This guide is meant for developers and IT admins who manage Auth0 integrations in their applications. If you are not familiar with how OAuth works at a basic level, [we suggest reading our protocol overview](/protocols/oauth2). + +If you are integrating Auth0 as a [SAML or WS-Federation **identity provider**](/saml-idp-generic) for your application (that is, not through OIDC/OAuth), then you do not need to make any changes. + +To make this guide accessible to everyone, any authentication flows will be described only through HTTP requests instead of in the context of any particular language or library's implementation. This is the similar to the descriptions and examples provided by the [official OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html). + +## Terminology + +All of the changes described in this guide apply to the **OIDC Conformant Authentication Pipeline**. This pipeline will be used if **any** of the following are true: + +- An [authentication request](/api/authentication#social) was initiated with an `audience` parameter. + +- The application being used is flagged as **OIDC Conformant** (available at _Dashboard > Applications > Settings > Show advanced settings > OAuth > OIDC Conformant flag_). + +If none of these conditions are met, the **legacy authentication pipeline** will be used, and everything will keep working as usual. + +## My application works just fine, why should I update? + +Any new Auth0 features, examples and documentation moving forward will target only the OIDC-conformant pipeline. All Auth0 SDK versions that depend on the legacy pipeline are deprecated and will not receive updates for new features or non-critical security issues, and will eventually be discontinued. + +The new features provided by the OIDC-conformant pipeline include: + +* [Create third-party applications for your APIs and display consent dialogs for authorization](/api-auth/user-consent) +* Restrict the user profile information provided to applications upon authentication +* [OIDC Dynamic Client Registration](/api-auth/dynamic-client-registration) + +## Is there a deadline to adopt these new features? + +We understand that making changes to the core authentication logic of your application is not something that you want to do every day, and that any changes need to be thoroughly tested. Because of this, we are not setting a deadline to make changes at this time. Instead, both authentication pipelines (OIDC-conformant and legacy) will be usable until further notice. + +All Auth0 documentation, SDKs, libraries and samples will eventually apply only to the OIDC-conformant pipeline. Because of this, we strongly recommend adoption even if you do not need to leverage any new features or functionality in the near future. + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/oidc-conformant.md b/fr-ca/articles/api-auth/tutorials/adoption/oidc-conformant.md new file mode 100644 index 0000000000..a8a601f4ad --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/oidc-conformant.md @@ -0,0 +1,57 @@ +--- +description: List of breaking changes for OIDC-conformant applications +topics: + - api-authentication + - oidc +contentType: concept +useCase: + - secure-api + - call-api +--- + +# OIDC-Conformant Applications + +<%= include('./_about.md') %> + +In order to make the transition to the [OIDC-conformant authentication pipeline](/api-auth/tutorials/adoption) more predictable, applications now include an option called "OIDC Conformant", available under **Advanced Settings > OAuth**: + +![OIDC-conformant application setting](/media/articles/dashboard/oidc_conformant.png) + +The objective of this flag is to disable as many legacy features as possible, so you can run into the OIDC-conformant pipeline's breaking changes at configuration time rather than run time. +Enabling this flag on an application will have the following effects: + +* The following features are deprecated: + - Refresh Tokens on authentication with the [implicit grant](/api-auth/tutorials/adoption/implicit) + - /ssodata endpoint and `getSSOData()` method from Lock/auth0.js +* [Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on) can only be performed from Auth0 login pages. +* Using `response_type=token` will only return an Access Token, not an ID Token. Use `response_type=id_token` or `response_type=token id_token` instead. +* ID Tokens obtained with the implicit grant will be signed asymmetrically using RS256. +* The /tokeninfo endpoint is disabled. +* Responses from /userinfo will [conform to the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse), similar to the [contents of ID Tokens](/api-auth/tutorials/adoption/scope-custom-claims) +* Implicit grant authentication requests made without a [`nonce` parameter](/api-auth/tutorials/nonce) will be rejected. +* [Refresh Tokens must be used at the token endpoint]() instead of /delegation. +* The `device` parameter, originally used to obtain Refresh Tokens, is now considered invalid. +* The legacy [resource owner endpoint](/api/authentication#database-ad-ldap-active-) is disabled. + - Passwordless authentication for embedded login is implemented at this endpoint, so it will be disabled as well. +* The [/oauth/access_token endpoint](/api/authentication#post-oauth-access_token), used for social authentication from native mobile applications, is disabled. + An OIDC-conformant alternative will be added in future releases. +* The [`scope` parameter of authentication requests](/api-auth/tutorials/adoption/scope-custom-claims) will comply to the OIDC specification: + - Custom claims must be [namespaced](/tokens/guides/create-namespaced-custom-claims) and added to ID Tokens or Access Tokens via rules. + - The namespace identifiers for custom claims must be **HTTP** or **HTTPS** URIs. + - Custom scope values can be defined by a [resource server (API)](/api-auth/tutorials/adoption/api-tokens). +* OIDC-conformant applications cannot be the source or target application of a [delegation request](/api-auth/tutorials/adoption/delegation). + +## I don't want to make all these changes at once! + +The "OIDC Conformant" flag will force all of these changes at the same time for a given application, but it's not the only option to gradually transition to the OIDC-conformant authentication pipeline. +Any authentication requests made with an `audience` parameter will use the new pipeline, and all other requests will continue to work as usual. + +If your application doesn't need a resource server but you want opt-in to the new pipeline on a per-request basis, you can use the following `audience` parameter: + +``` +https://${account.namespace}/userinfo +``` + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/password.md b/fr-ca/articles/api-auth/tutorials/adoption/password.md new file mode 100644 index 0000000000..15834e8bba --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/password.md @@ -0,0 +1,198 @@ +--- +description: Understand how the Resource Owner Password Grant (ROPG) is used by highly-trusted apps to provide active authentication. +topics: + - api-authentication + - oidc + - resource-owner-password +contentType: concept +useCase: + - secure-api + - call-api +--- +# Resource Owner Password Credentials Exchange + +<%= include('../../_includes/_ropg-warning.md') %> + +<%= include('./_about.md') %> + +The [Resource Owner Password Credentials exchange](/api-auth/grant/password) is used by highly-trusted applications to provide active authentication. Unlike the authorization code and implicit grants, this authentication mechanism does not redirect users to Auth0. It authenticates users with a single request, exchanging their password credentials for a token. + +This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines. + +## Authentication request + +
+
+ +
+
+
+ 
POST /oauth/ro HTTP 1.1
+Content-Type: application/json
+{
+  "grant_type": "password",
+  "client_id": "123",
+  "username": "alice",
+  "password": "A3ddj3w",
+  "connection": "my-database-connection",
+  "scope": "openid email favorite_color offline_access",
+  "device": "my-device-name"
+}
+ +
+
+ 
POST /oauth/token HTTP 1.1
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fpassword-realm&client_id=123&username=alice&password=A3ddj3w&realm=my-database-connection&scope=openid+email+offline_access&audience=https%3A%2F%2Fapi.example.com
+
+
    +
  • The endpoint to execute token exchanges is /oauth/token.
    • +
  • Auth0's own grant type is used to authenticate users from a specific connection (realm). The standard OIDC password grant is also supported, but it does not accept Auth0-specific parameters such as realm.
    • +
  • favorite_color is no longer a valid scope.
    • +
  • The device parameter is removed.
    • +
  • The audience parameter is optional.
    • +
+
+
+
+ +## Authentication response + +
+
+ +
+
+
+ 
HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "SlAV32hkKG",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
+
    +
  • The returned Access Token is only valid for calling the /userinfo endpoint.
    • +
  • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
    • +
+
+
+ 
HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "eyJ...",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
+
    +
  • The returned Access Token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
    • +
  • The ID Token will be forcibly signed using RS256 if requested by a public application.
    • +
  • A Refresh Token will be returned only if the offline_access scope was granted.
    • +
+
+
+
+ + +## ID Token structure + +
+
+ +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue"
+}
+
    +
  • The ID Token will be forcibly signed using RS256 if requested by a public application.
    • +
  • The favorite_color claim must be namespaced and added through a rule.
    • +
+
+
+
+ +## Access Token structure (optional) + +
+
+ +
+
+
+ 
SlAV32hkKG
+
    +
  • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
    • +
+
+
+ 
{
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
+
    +
  • The returned Access Token is a JWT valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
    • +
  • Note that an opaque Access Token could still be returned if /userinfo is the only specified audience.
    • +
+
+
+
+ +## Standard password grant requests + +The Auth0 password realm grant is not defined by standard OIDC, but it is suggested as an alternative to the legacy resource owner endpoint because it supports the Auth0-specific `realm` parameter. The [standard OIDC grant is also supported](/api-auth/tutorials/password-grant) when using OIDC authentication. + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/refresh-tokens.md b/fr-ca/articles/api-auth/tutorials/adoption/refresh-tokens.md new file mode 100644 index 0000000000..fa8d7447b6 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/refresh-tokens.md @@ -0,0 +1,58 @@ +--- +description: Understand how refresh tokens are used in an OIDC-conformant authentication pipeline. +topics: + - api-authentication + - oidc + - tokens + - refresh tokens +contentType: concept +useCase: + - secure-api + - call-api +--- + +# OIDC-Conformant Refresh Tokens + +<%= include('./_about.md') %> + +There are some changes to how Refresh Tokens are used in the OIDC-conformant authentication pipeline: + +* Using the [implicit grant](/api-auth/tutorials/adoption/implicit) for authentication will no longer return Refresh Tokens. +* Refresh Tokens should only be used by [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications). However, they can also be used by Native (public) applications to obtain Refresh Tokens for mobile apps. +* The `/delegation` endpoint is deprecated. To obtain new tokens from a Refresh Token, the `/oauth/token` endpoint should be used instead: + +
+
+ +
+
+
+ 
POST /delegation
+Content-Type: 'application/json'
+{
+  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
+  "client_id": "...",
+  "refresh_token": "...",
+  "scope": "openid profile"
+}
+
+
+
+ 
POST /oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=refresh_token&refresh_token=123&client_id=123&client_secret=123&scope=openid+profile&audience=https%3A%2F%2Fapi.example.com
+
+
  • The audience and client_secret parameters are optional. The client_secret is not needed when requesting a refresh_token for a mobile app.
+
+
+
+ +Please note that Refresh Tokens must be kept confidential in transit and storage, and they should be shared only among the authorization server and the client to whom the Refresh Tokens were issued. + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/scope-custom-claims.md b/fr-ca/articles/api-auth/tutorials/adoption/scope-custom-claims.md new file mode 100644 index 0000000000..10b72653ed --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/scope-custom-claims.md @@ -0,0 +1,101 @@ +--- +description: Apps can request any standard OIDC scopes such as profile and email as well as any scopes supported by the API they want to access. +topics: + - api-authentication + - oidc + - scopes + - user-profiles + - claims +contentType: concept +useCase: + - secure-api + - call-api +--- + +# User Profile Claims and the `scope` Parameter + +<%= include('./_about.md') %> + +The behavior of the `scope` parameter has been changed to conform to the [OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims). + +Instead of requesting arbitrary application-specific claims, applications can request any of the standard OIDC scopes such as `profile` and `email`, as well as any [scopes supported by the API they want to access](/api-auth/tutorials/adoption/api-tokens). + +## Standard claims + +The OIDC specification defines a [set of standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users that can be returned in ID Tokens or in the response from /userinfo. + +## Custom claims + +To improve compatibility for applications, Auth0 now returns profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). You can still add custom claims, but they must conform to a namespaced format to avoid possible collisions with standard OIDC claims. Otherwise, it is no longer possible to add arbitrary claims to ID Tokens or Access Tokens. + +For example, suppose an identity provider returns a `favorite_color` claim as part of the user’s profile, and that we’ve used the Auth0 management API to set application-specific information for this user. + +This would be the profile stored by Auth0: + +```json +{ + "email": "jane@example.com", + "email_verified": true, + "user_id": "custom|123", + "favorite_color": "blue", + "user_metadata": { + "preferred_contact": "email" + } +} +``` + +This is a [*normalized user profile*](/users/normalized), which is a protocol-agnostic representation of this user as defined by Auth0. When performing an OIDC conformant login, Auth0 would return the following ID Token claims to the application: + +```json +{ + "iss": "https://my-domain.auth0.com/", + "sub": "custom|123", + "aud": "my_client_id", + "exp": 1311281970, + "iat": 1311280970, + "email": "jane@example.com", + "email_verified": true +} +``` + +Note that the `user_id` property is sent as `sub` in the ID Token, and that `favorite_color` and `user_metadata` are not present in the OIDC response from Auth0. This is because OIDC does not define standard claims to represent all the information in this user’s profile. We can, however, define a non-standard claim by namespacing it through a [rule](/rules): + +```js +function (user, context, callback) { + const namespace = 'https://myapp.example.com/'; + context.idToken[namespace + 'favorite_color'] = user.favorite_color; + context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact; + callback(null, user, context); +} +``` + +::: note +If you need to add custom claims to the Access Token, you can use the code sample above with the following change: use `context.accessToken` in place of `context.idToken`. + +Please note that adding custom claims to tokens through this method will also let you obtain them when calling the `/userinfo` endpoint. However, rules run when the user is authenticating, not when `/userinfo` is called. +::: + +Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. The namespace URL does not have to point to an actual resource, it’s only used as an identifier and will not be called by Auth0. + +::: warning +`auth0.com`, `webtask.io` and `webtask.run` are Auth0 domains and therefore cannot be used as a namespace identifier. +::: + +This follows a [recommendation from the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims) stating that custom claim identifiers should be collision-resistant. While this is not mandatory according to the specification, Auth0 will always enforce namespacing when performing OIDC-conformant login flows, meaning that any custom claims without HTTP/HTTPS namespaces will be silently excluded from tokens. + +::: note +Auth0 will allow non-OIDC claims without a namespace (the "legacy" user profile, from which we strongly recommend moving away) if: + +* You are using the non-OIDC conformant pipeline (i.e., you are not using the `audience` parameter in the `/authorize` or token request and the application does not have the [**OIDC-Conformant** toggle](https://auth0.com/docs/api-auth/tutorials/adoption/oidc-conformant) enabled). +* You have the **Legacy User Profile** toggle turned on in the [tenant Advanced Settings](https://manage.auth0.com/#/tenant/advanced), under the **Migrations** section. This setting is only enabled for old tenants, but newly created tenants can't see or enable the **Legacy User Profile**. + +We strongly recommend moving away from the Legacy User Profile. +::: + +## Token refresh flow and custom claims + +When an application requests new tokens using a Refresh Token, the new tokens will not automatically inherit any custom claims previously added. But since rules run on a token refresh flow as well, the same claim customization code will be executed in these cases. This gives the flexibility of adding or changing claims in newly issued tokens without forcing applications to obtain a new refresh token. + +## Keep reading + +<%= include('./_index.md') %> diff --git a/fr-ca/articles/api-auth/tutorials/adoption/single-sign-on.md b/fr-ca/articles/api-auth/tutorials/adoption/single-sign-on.md new file mode 100644 index 0000000000..f421306e27 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/adoption/single-sign-on.md @@ -0,0 +1,62 @@ +--- +description: Understand how OIDC Single Sign-On occurs when a user logs into one app and is then signed into other apps automatically. +topics: + - api-authentication + - oidc + - sso +contentType: concept +useCase: + - secure-api + - call-api +--- + +# OIDC Single Sign-On + +<%= include('./_about.md') %> + +Single Sign-on (SSO) occurs when a user logs into one application and is then signed into other applications automatically. + +In the context of the OIDC-conformant authentication pipeline, SSO must happen at the authorization server (i.e. Auth0) and not applications. + +This means that for SSO to happen, you must employ Universal Login and redirect users to the login page. + +## How it works + +At a general level, this is what happens when performing SSO: + +1. If the user is not logged in locally, redirect them to Auth0 for authentication. This is done using the [Authorization Code Flow](/flows/concepts/auth-code) or [Implicit Flow](/flows/concepts/implicit), depending on the type of application. +2. If the user was logged in through SSO, Auth0 will immediately authenticate them without needing to re-enter credentials. + +An application that does not use SSO might decide to use embedded login to authenticate users instead of redirecting to Auth0 for authentication. + +## Determining if users are logged in via SSO + +An application can easily determine if a user is logged in locally by checking the validity of a local ID Token or session cookie. +However, in some cases your application might need to determine if the user has a valid SSO session at Auth0. +In the legacy authentication pipeline, this could be achieved by using the `/ssodata` endpoint, which would return information about the user's SSO session. +OIDC-conformant applications must use [silent authentication](/api-auth/tutorials/silent-authentication), which either re-authenticates a user if they are already logged in, or returns an error if they need to authenticate. + +## Authentication flows without SSO + +SSO [sessions](/sessions) are managed by Auth0 setting a cookie on your Auth0 domain. +Since cross-origin requests cannot set cookies, this means that SSO sessions must be established by redirecting users to your Auth0 login page (`/authorize`). + +The following flows are redirect-based and are capable of SSO: + +* [Authorization Code Flow](/flows/concepts/auth-code) +* [Implicit Flow](/flows/concepts/implicit) + +The following flows are request-based and are currently not capable of SSO: + +* [Password credentials and realm grants](/api-auth/grant/password) + +## Custom domains + +When using Universal Login, the login page is by default hosted at an Auth0 domain, so any SSO will be performed at an Auth0 domain instead of your organization's domain. + +This is only an aesthetic limitation and does not impact the security or functionality of SSO logins in any way. + +## Keep reading + +* [Custom Domains](/custom-domains) +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) diff --git a/fr-ca/articles/api-auth/tutorials/authorization-code-grant-pkce.md b/fr-ca/articles/api-auth/tutorials/authorization-code-grant-pkce.md new file mode 100644 index 0000000000..e93cd3913b --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/authorization-code-grant-pkce.md @@ -0,0 +1,289 @@ +--- +description: How to execute an Authorization Code Grant flow with PKCE for a Mobile Application +toc: true +topics: + - api-authentication + - oidc + - authorization-code + - pkce +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Execute an Authorization Code Grant Flow with PKCE + +::: note +This tutorial will help you implement the Authorization Code (PKCE) grant. If you are looking for some theory on the flow refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). +::: + +The __Authorization Code with PKCE__ is the OAuth 2.0 grant that [native apps](/quickstart/native) use in order to access an API. In this document we will work through the steps needed in order to implement this: create a code verifier and a code challenge, get the user's authorization, get a token and access the API using the token. + +Before beginning this tutorial, please: + +* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately +* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 + +## 1. Create a Code Verifier + +First, you need to generate and store a `code_verifier`. + +
+
+ +
+
+
+ 
+function base64URLEncode(str) {
+    return str.toString('base64')
+        .replace(/\+/g, '-')
+        .replace(/\//g, '_')
+        .replace(/=/g, '');
+}
+
+var verifier = base64URLEncode(crypto.randomBytes(32));
+
+
+ 
+SecureRandom sr = new SecureRandom();
+byte[] code = new byte[32];
+sr.nextBytes(code);
+String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);
+
+
+ 
+var buffer = [UInt8](repeating: 0, count: 32)
+_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
+let verifier = Data(bytes: buffer).base64EncodedString()
+    .replacingOccurrences(of: "+", with: "-")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
+    .trimmingCharacters(in: .whitespaces)
+
+
+ 
+NSMutableData *data = [NSMutableData dataWithLength:32];
+int result __attribute__((unused)) = SecRandomCopyBytes(kSecRandomDefault, 32, data.mutableBytes);
+NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
+                        stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
+                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
+                             stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];
+
+
+
+ +## 2. Create a Code Challenge + +Using the `code_verifier`, generate a `code_challenge` that will be sent in the authorization request. + +
+
+ +
+
+
+ 
+function sha256(buffer) {
+    return crypto.createHash('sha256').update(buffer).digest();
+}
+
+var challenge = base64URLEncode(sha256(verifier));
+
+
+ 
+byte[] bytes = verifier.getBytes("US-ASCII");
+MessageDigest md = MessageDigest.getInstance("SHA-256");
+md.update(bytes, 0, bytes.length);
+byte[] digest = md.digest();
+//Use Apache "Commons Codec" dependency. Import the Base64 class
+//import org.apache.commons.codec.binary.Base64;
+String challenge = Base64.encodeBase64URLSafeString(digest);
+
+
+ 
+ // You need to import CommonCrypto
+guard let data = verifier.data(using: .utf8) else { return nil }
+var buffer = [UInt8](repeating: 0,  count: Int(CC_SHA256_DIGEST_LENGTH))
+data.withUnsafeBytes {
+    _ = CC_SHA256($0, CC_LONG(data.count), &buffer)
+}
+let hash = Data(bytes: buffer)
+let challenge = hash.base64EncodedString()
+    .replacingOccurrences(of: "+", with: "-")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
+    .trimmingCharacters(in: .whitespaces)
+
+
+ 
+ // You need to import CommonCrypto
+u_int8_t buffer[CC_SHA256_DIGEST_LENGTH * sizeof(u_int8_t)];
+memset(buffer, 0x0, CC_SHA256_DIGEST_LENGTH);
+NSData *data = [verifier dataUsingEncoding:NSUTF8StringEncoding];
+CC_SHA256([data bytes], (CC_LONG)[data length], buffer);
+NSData *hash = [NSData dataWithBytes:buffer length:CC_SHA256_DIGEST_LENGTH];
+NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
+                         stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
+                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
+                       stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];
+
+
+
+ +## 3. Get the User's Authorization + +To begin an Authorization Code Grant flow, your native application should first send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-) including the `code_challenge` and the method used to generate it. + +```text +https://${account.namespace}/authorize? + audience=API_AUDIENCE& + scope=SCOPE& + response_type=code& + client_id=${account.clientId}& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + redirect_uri=${account.callback} +``` + +Where: + +* `audience`: The unique identifier of the API the native app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. + +* `scope`: The scopes that you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)). + +* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code`. + +* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/Applications/${account.clientId}/settings). + +* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/Applications/${account.clientId}/settings). + +* `code_challenge`: Generated challenge from the `code_verifier`. + +* `code_challenge_method`: Method used to generate the challenge. + +::: panel PKCE methods +The PKCE spec defines two methods, `S256` and `plain`, the former is used in this example and is the **only** one supported by Auth0 since the latter is discouraged. +::: + +For example: + +```html + + Sign In + +``` + +## 4. Exchange the Authorization Code for an Access Token + +Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (`code`) from the previous step, you will need to `POST` to the [Token URL](/api/authentication#authorization-code-pkce-) sending also the `code_verifier`: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "code_verifier", + "value": "YOUR_GENERATED_CODE_VERIFIER" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "${account.callback}" + } + ] + } +} +``` + +Where: + +* `grant_type`: This must be `authorization_code`. +* `client_id`: Your application's Client ID. +* `code_verifier`: Cryptographically random key that was used to generate the `code_challenge` passed to `/authorize`. +* `code`: The Authorization Code received from the initial `authorize` call. +* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`. + +The response contains `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "refresh_token": "GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type": "Bearer" +} +``` + +Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information. + +::: warning +The Authorization Code flow with PKCE can only be used for Applications whose type is `Native` or `Single Page Application` in the Dashboard. +::: + +## 5. Call the API + +Once you have the Access Token, you can use it to make calls to the API, by passing it as a Bearer Token in the `Authorization` header of the HTTP request: + +```har +{ + "method": "GET", + "url": "https://someapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` + +## 6. Verify the Token + +Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Optional: Customize the Tokens + +<%= include('../../_includes/_api-auth-customize-tokens') %> + +If you wish to execute special logic unique to the Authorization Code (PKCE) grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code (PKCE) grant. + +## Sample application + +For an example implementation see the [Mobile + API](/architecture-scenarios/application/mobile-api) architecture scenario. + +This is a series of tutorials that describe a scenario for a fictitious company. The company wants to implement a mobile app that the employees can use to send their timesheets to the company's Timesheets API using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets). + +## Keep reading + +- [Tokens](/tokens) +- [Application Authentication for Mobile & Desktop Apps](/Application-auth/mobile-desktop) +- [The OAuth 2.0 protocol](/protocols/oauth2) +- [The OpenID Connect protocol](/protocols/oidc) diff --git a/fr-ca/articles/api-auth/tutorials/authorization-code-grant.md b/fr-ca/articles/api-auth/tutorials/authorization-code-grant.md new file mode 100644 index 0000000000..5ecd2127c1 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/authorization-code-grant.md @@ -0,0 +1,162 @@ +--- +description: How to execute an Authorization Code Grant flow from a Regular Web application +toc: true +topics: + - api-authentication + - oidc + - authorization-code +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Execute an Authorization Code Grant Flow + +::: note +This tutorial will help you implement the Authorization Code grant. If you are looking for some theory on the flow refer to [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code). +::: + +The __Authorization Code__ is an OAuth 2.0 grant that [regular web apps](/quickstart/webapp) use in order to access an API. In this document we will work through the steps needed in order to implement this: get the user's authorization, get a token and access the API using the token. + +Before beginning this tutorial, please: + +* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately +* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 + +## 1. Get the User's Authorization + +To begin an Authorization Code flow, your web application should first send the user to the [authorization URL](/api/authentication#authorization-code-grant): + +```text +https://${account.namespace}/authorize? + audience=YOUR_API_AUDIENCE& + scope=YOUR_SCOPE& + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=YOUR_OPAQUE_VALUE +``` + +Where: + +* `audience`: The unique identifier of the API the web app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. + +* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)). + +* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code`. + +* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + +* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state). + +* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + +For example: + +```html + + Sign In + +``` + +The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) to do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given. + +Note that if you alter the value in `scope`, Auth0 will require consent to be given again. + +## 2. Exchange the Authorization Code for an Access Token + +Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (`code`) from the previous step, you will need to `POST` to the [Token URL](/api/authentication?http#authorization-code): + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "${account.callback}" + } + ] + } +} +``` + +Where: + +* `grant_type`: This must be `authorization_code`. +* `client_id`: Your application's Client ID. +* `client_secret`: Your application's Client Secret. +* `code`: The Authorization Code received from the initial `authorize` call. +* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`. + +The response contains the `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "refresh_token": "GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type": "Bearer" +} +``` + +Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information. + +::: panel-warning Security Warning +It is important to understand that the Authorization Code flow should only be used in cases such as a Regular Web Application where the Client Secret can be safely stored. In cases such as a Single-Page Application, the Client Secret is available to the application (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the [Authorization Code Flow with PKCE ](/flows/concepts/auth-code-pkce) is more appropriate in that case. +::: + +## 3. Call the API + +Once the Access Token has been obtained it can be used to make calls to the API by passing it as a Bearer Token in the `Authorization` header of the HTTP request: + +```har +{ + "method": "GET", + "url": "https://someapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` + +## 4. Verify the Token + +Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Optional: Customize the Tokens + +<%= include('../../_includes/_api-auth-customize-tokens') %> + +If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant. + +## Keep Reading + +- [Refresh Tokens](/tokens/concepts/refresh-token) +- [How to configure an API in Auth0](/apis) +- [Application Authentication for Server-side Web Apps](/application-auth/server-side-web) +- [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/tutorials/client-credentials.md b/fr-ca/articles/api-auth/tutorials/client-credentials.md new file mode 100644 index 0000000000..567e903447 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/client-credentials.md @@ -0,0 +1,113 @@ +--- +description: Learn how to call an API from a server process using OAuth 2.0 and the Client Credentials grant. +toc: true +topics: + - api-authentication + - oidc + - client-credentials +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Implement the Client Credentials Grant + +The **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) allows an application to request an Access Token using its __Client Id__ and __Client Secret__. It is used for non interactive applications (a CLI, a daemon, or a Service running on your backend) where the token is issued to the application itself, instead of an end user. + +Before beginning this tutorial, please: + +* Make sure you that your application has the `Client Credentials` [grant type enabled](/dashboard/guides/applications/update-grant-types). Regular web applications and machine to machine applications have it enabled by default. + +* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 with the required scopes. + +* Authorize the application to call the API by creating a Client Grant either [using the Dashboard](/api-auth/config/using-the-auth0-dashboard) or [using the Management API](/api-auth/config/using-the-management-api). + +## Ask for a token + +To ask Auth0 for tokens for any of your authorized applications, perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint with a payload in the following format: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "client_credentials" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + } + ] + } +} +``` + +Where: + +* `grant_type`: This must be `client_credentials`. +* `client_id`: Your application's Client ID. You can find this value at the [application's settings tab](${manage_url}/#/applications). +* `client_secret`: Your application's Client Secret. You can find this value at the [application's settings tab](${manage_url}/#/applications). +* `audience`: The **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. + +The response contains a signed JSON Web Token (JWT), the token's type (which is `Bearer`), and in how much time it expires in [Unix time](https://en.wikipedia.org/wiki/Unix_time) (86400 seconds, which means 24 hours). + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +If you [decode the `access_token`](https://jwt.io/#debugger-io) you will see that it contains the following claims: + +```json +{ + "iss": "https://${account.namespace}/", + "sub": "YOUR_MACHINE_TO_MACHINE_APPLICATION_CLIENT_ID@clients", + "aud": "YOUR_API_IDENTIFIER", + "exp": 1489715431, // unix timestamp of the token's expiration date, + "iat": 1489679431, // unix timestamp of the token's creation date, + "scope": "" +} +``` + +## Modify scopes and claims + +You can change the scopes and add custom claims to the Access Token you got, using [Hooks](/hooks). + +Hooks allow you to customize the behavior of Auth0 using Node.js code. They are secure, self-contained functions associated with specific extensibility points of the Auth0 platform (like the Client Credentials grant). Auth0 invokes the Hooks at runtime to execute your custom logic. + +For more information and details on how to do that refer to [Using Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks). + +## Verify the token + +Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). You can find examples on how to do it in different platforms in the [Quickstarts for backend applications](/quickstart/backend). + +## Sample application + +For an example implementation see the [Server Client + API](/architecture-scenarios/application/server-api) architecture scenario. + +This is a series of tutorials that describe a scenario for a fictitious company that wants to implement a Timesheets API and send timesheets entries from a server process using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets). + +## Keep reading + +- [Use Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks) +- [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md b/fr-ca/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md new file mode 100644 index 0000000000..e8c5f642f2 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md @@ -0,0 +1,212 @@ +--- +description: How to use Hooks to change the scopes and add custom claims to the tokens you got using Client Credentials Grant. +crews: crew-2 +toc: true +topics: + - api-authentication + - oidc + - client-credentials + - hooks +contentType: tutorial +useCase: + - secure-api + - call-api + - extensibility-hooks +--- + +# Use Hooks with Client Credentials Grant + +You can now add [Hooks](/hooks) into your [client credentials](/api-auth/grant/client-credentials) flow. This way you can change the scopes and add custom claims to the tokens issued by Auth0. + +Hooks allow you to customize the behavior of Auth0 using Node.js code. They are secure, self-contained functions associated with specific extensibility points of the Auth0 platform (like the Client Credentials grant). Auth0 invokes the Hooks at runtime to execute your custom logic. + +You can manage Hooks using the Auth0 Dashboard or the Management API. + +## Before you start + +Create the following: + +- [API defined with the appropriate scopes](${manage_url}/#/apis) +- [Machine-to-machine application](/applications) authorized to use the API + +For details on how to set up the API and the machine-to-machine app, see: +- Set up a Client Grant: + - [Using the Dashboard](/api-auth/config/using-the-auth0-dashboard) + - [Using the Management API](/api-auth/config/using-the-management-api) +- [Execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) + +## Use the Dashboard + +1. Go to [the Hooks page of the Dashboard](${manage_url}/#/hooks). + + ![Dashboard Hooks](/media/articles/api-auth/hooks/dashboard-hooks.png) + +2. Click the __+ Create New Hook__ button. On the _New Hook_ pop-up window, set the __Hook__ dropdown to `Client Credentials Exchange` and set a __Name__ for your hook. Click __Create__. + + ![New Client Credentials Hook](/media/articles/api-auth/hooks/new-cc-hook.png) + + At this point, you will see your newly-created Hook listed under the _Client Credentials Exchange_. + +::: note +You can create more than one hooks per extensibility point but __only one__ can be enabled. The enabled hook will then be executed for __all__ applications and APIs. +::: + +3. Click the __Pencil and Paper__ icon to the right of the Hook to open the Hook Editor. + + ![Edit Client Credentials Hook](/media/articles/api-auth/hooks/edit-cc-hook.png) + +4. Using the Hook Editor, write your Node.js code. As an example, we will add an extra scope. The claim's name will be `https://foo.com/claim` and its value `bar`. Copy the sample code below and paste it in the Editor. + + ```js + module.exports = function(client, scope, audience, context, cb) { + var access_token = {}; + access_token['https://foo.com/claim'] = 'bar'; + access_token.scope = scope; + access_token.scope.push('extra'); + cb(null, access_token); + }; + ``` + + This sample hook will: + - add an arbitrary claim (`https://foo.com/claim`) to the Access Token + - add an `extra` scope to the default scopes configured on your [API](${manage_url}/#/apis). + + ::: panel Custom claims namespaced format + In order to improve compatibility for applications, Auth0 now returns profile information in a [structured claim format as defined by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. + ::: + + ![Hook Editor](/media/articles/api-auth/hooks/cc-webtask-editor.png) + + Click __Save__ (or hit Ctrl+S/Cmd+S) and close the Editor. + +5. That's it! Now you only need to test your hook. You can find detailed instructions at the [Test your Hook](#test-your-hook) paragraph. + +## Test your Hook + +To test the hook you just created you need to run a Client Credentials exchange, get the Access Token, decode it and review its contents. + +To get a token, make a `POST` request at the `https://${account.namespace}/oauth/token` API endpoint, with a payload in the following format. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "client_credentials" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + } + ] + } +} +``` + +::: note +If you don't know where to find the Client Id, Client Secret, or API Identifier information, refer to Where to Find the IDs. +::: + +A successful response will include: +- an `access_token`, +- its expiration time in seconds (`expires_in`), +- the token's type set as `Bearer` (`token_type`), and +- an `extra` scope (`scope`) (this scope was added by your hook) + +```text +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5ESTFNa05DTVRGQlJrVTRORVF6UXpFMk1qZEVNVVEzT1VORk5ESTVSVU5GUXpnM1FrRTFNdyJ9.eyJpc3MiOiJodHRwczovL2RlbW8tYWNjb3VudC5hdXRoMC3jb20vIiwic3ViIjoic0FRSlFpQmYxREw0c2lqSVZCb2pFRUZvcmRoa0o4WUNAY2xpZW50cyIsImF1ZCI6ImRlbW8tYWNjb3VudC5hcGkiLCJleHAiOjE0ODc3NjU8NjYsImlhdCI6MTQ4NzY3OTI2Niwic2NvcGUiOiJyZWFkOmRhdGEgZXh0cmEiLCJodHRwczovL2Zvby5jb20vY2xhaW0iOiKoPXIifQ.da-48mHY_7esfLZpvHWWL8sIH1j_2mUYAB49c-B472lCdsNFvpaLoq6OKQyhnqk9_aW_Xhfkusos3FECTrLFvf-qwQK70QtwbkbVye_IuPSTAYdQ2T-XTzGDm9Nmmy5Iwl9rNYLxVs2OoCdfpVMyda0OaI0AfHBgEdKWluTP67OOnV_dF3KpuwtK3dPKWTCo2j9VCa7X1I4h0CNuM79DHhY2wO7sL8WBej7BSNA3N2TUsp_YTWWfrvsr_vVhJf-32G7w_12ms_PNFUwj2C30ZZIPWc-uEkDztyMLdI-lu9q9TLrLdr0dOhfrtfkdeJx4pUSiHdJHf42kg7UAVK6JcA", + "expires_in": 86400, + "scope": "extra", + "token_type": "Bearer" +} +``` + +Copy the Access Token. + +The easiest way to decode it and review its contents is to use the [JWT.io Debugger](https://jwt.io/#debugger-io). + +Paste your Access Token at the left-hand editor. Automatically the JWT is decoded and its contents are displayed on the right-hand editor. + +![Decode Token with JWT.io](/media/articles/api-auth/hooks/cc-decode-token.png) + +Look into the last two items of the __Payload__. Both have been set by our hook: +- `"scope": "extra"` +- `"https://foo.com/claim": "bar"` + +## Manage your Hooks + +You can disable, enable, delete or edit hooks using either the Auth0 CLI or the [dashboard](${manage_url}/#/hooks). You can also review your logs using the Auth0 CLI. For details, refer to the articles below. + +Use the Dashboard to: +- [Delete Hooks](/auth0-hooks/dashboard/create-delete) +- [Edit Hooks](/auth0-hooks/dashboard/edit) +- [Enable or disable Hooks](/auth0-hooks/dashboard/enable-disable) + +Use the Auth0 CLI to: +- [Delete Hooks](/auth0-hooks/cli/create-delete) +- [Edit Hooks](/auth0-hooks/cli/edit) +- [Enable or disable Hooks](/auth0-hooks/cli/enable-disable) +- [Review Logs](/auth0-hooks/cli/logs) + +## Input Parameters + +The hook takes five input parameters. You can use these values for your custom logic. + +Let's see what each one contains. + +- __client__ (object): Information on the application asking for the token, including the `client` metadata (a key-value pair that can be set by application). Sample snippet: + + ```json + { + "tenant": "tenant_name", + "id": "tenant_id", + "name": "test_client", + "metadata": { + "some_metadata": "value" + } + } + ``` + +- __scope__ (`string array`): The scopes available on the API that you have defined. + +- __audience__ (`string`): The API identifier available via the API settings page. + +- __context__ (`object`): The contextual information about the request. Sample snippet: + + ```json + { + "ip": "123.123.123.123", + "userAgent": "...", + "webtask": { + "secrets": { "FOO": "bar" } + } + } + ``` + +- __cb__: The callback. In our example we returned the token (`cb(null, access_token)`). If you decide, however, not to issue a token, you can return `Error (cb(new Error('access denied')))`. + +## Keep reading + +* [What are Hooks and how you can work with them](/hooks) +* [Overview of the Client Credentials Grant](/api-auth/grant/client-credentials) +* [How to set up a Client Grant using the Dashboard](/api-auth/config/using-the-auth0-dashboard) +* [How to set up a Client Grant using the Management API](/api-auth/config/using-the-management-api) +* [How to execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) diff --git a/fr-ca/articles/api-auth/tutorials/hybrid-flow.md b/fr-ca/articles/api-auth/tutorials/hybrid-flow.md new file mode 100644 index 0000000000..c00ef7443e --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/hybrid-flow.md @@ -0,0 +1,208 @@ +--- +description: Learn how to execute the Hybrid Flow so your app can use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token. +toc: true +public: false +topics: + - api-authentication + - oidc + - hybrid +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Implement the Hybrid Flow + +The [Hybrid Flow](/api-auth/grant/hybrid) is an OpenID Connect (OIDC) grant that enables use cases where your application can immediately use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token (therefore gaining access to protected resources for an extended period of time). + +In this article, we will show you how you can use the Hybrid Flow in Auth0. + +## Prerequisites + +Before you begin this tutorial, please: + +* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately +* [Register your API](/apis#how-to-configure-an-api-in-auth0) with Auth0 + +## 1. Get the User's Authorization + +The first step is to get the user's consent for authentication (and possibly authorization). You can initiate the flow by sending the user to the [authorization URL](/api/authentication#authorization-code-grant) + +```text +https://${account.namespace}/authorize? + audience=YOUR_API_AUDIENCE& + scope=YOUR_SCOPE& + response_type=YOUR_RESPONSE_TYPE& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=YOUR_OPAQUE_VALUE + nonce=NONCE +``` + +Where: + +* `audience`: The unique identifier of the API the web app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. + +* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)). + +* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code id_token`, `code token`, or `code id_token token`. More specifically, `token` returns an Access Token, `id_token` returns an ID Token, and `code` returns the Authorization Code. + +* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + +* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state). + +* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + + ::: warning + Per the [OAuth 2.0 Specification](https://tools.ietf.org/html/rfc6749#section-3.1.2), Auth0 removes everything after the hash and does *not* honor any fragments. + ::: + +* `nonce`: A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. + +For example: + +```html + + Sign In + +``` + +The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) to do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given. + +Note that if you alter the value in `scope`, Auth0 will require consent to be given again. + +## 2. Parsing the Response + +If your call to the `/authorize` endpoint is successful, Auth0 redirects you to a URL similar to the following: + +```text +https://YOUR_REDIRECT_URI + /#access_token=ey...MhPw + &expires_in=7200 + &token_type=Bearer + &code=AUTHORIZATION_CODE + &id_token=ey...qk +``` + +The URL contains the following components: + +* The redirect URI you provided for this application +* The Authorization Code provided by Auth0 +* The ID Token +* The Access Token + +If you've returned an Access Token, you'll also receive `expires_in` and `token_type` values. + +More specifically, here's what you will get back (depending on the value provided in `response_type`): + +| Response Type | Components | +| - | - | +| code id_token | Authorization Code, ID Token | +| code token | Authorization Code, Access Token | +| code id_token token | Authorization Code, ID Token, Access Token | + +### Access Tokens + +There are two ways to get Access Tokens in the Hybrid Flow. + +First, all calls include the `code` value in the `response_type` parameter (e.g., `code id_token`, `code token`, or `code id_token token`). As such, you'll receive an Authorization Code from Auth0 that you can then exchange for an Access Token. + +Second, you can explicitly request an Access Token directly by setting the `response_type` parameter to `code token` or `code id_token token`. + +You can therefore receive two Access Tokens for a given transaction. However, it is important to keep the two separate -- we do not recommend that an Access Token obtained when `response_type=code token` or `code token` or `code id_token token` be used to call APIs. + +## 3. Exchange the Authorization Code for an Access Token + +You can exchange the Authorization Code for an Access Token that will allow you to call the API specified in your initial authorization call. + +Using the Authorization Code (`code`) from the first step, you will need to `POST` to the [Token URL](/api/authentication?http#authorization-code): + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "${account.callback}" + } + ] + } +} +``` + +Where: + +* `grant_type`: This must be `authorization_code`. +* `client_id`: Your application's Client ID. +* `client_secret`: Your application's Client Secret. +* `code`: The Authorization Code received from the initial `authorize` call. +* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`. + +The response contains the `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "refresh_token": "GEbRxBN...edjnXbL", + "id_token": "eyJ0XAi...4faeEoQ", + "token_type": "Bearer" +} +``` + +Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information. + +::: panel-warning Security Warning +It is important to understand that the Authorization Code flow should only be used in cases such as a Regular Web Application where the Client Secret can be safely stored. In cases such as a Single-Page Application, the Client Secret is available to the application (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the [Implicit Flow](/flows/concepts/implicit) is more appropriate in that case. +::: + +## 4. Call the API + +Once the Access Token has been obtained it can be used to make calls to the API by passing it as a Bearer Token in the `Authorization` header of the HTTP request: + +```har +{ + "method": "GET", + "url": "https://someapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" } + ] +} +``` + +## 5. Verify the Token + +Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Keep reading + +- [Tokens](/tokens) +- [Refresh Tokens](/tokens/concepts/refresh-token) +- [Configure an API in Auth0](/apis) +- [Authorization Code Flow](/flows/concepts/auth-code) +- [Implicit Flow](/flows/concepts/implicit) + diff --git a/fr-ca/articles/api-auth/tutorials/implicit-grant.md b/fr-ca/articles/api-auth/tutorials/implicit-grant.md new file mode 100644 index 0000000000..07c8ccc2c5 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/implicit-grant.md @@ -0,0 +1,154 @@ +--- +description: Learn how to execute an Implicit Grant flow from a SPA Client application. +toc: true +topics: + - api-authentication + - oidc + - implicit +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Implement the Implicit Grant + +::: note +This tutorial will help you implement the Implicit Grant. If you are looking for some theory on the flow refer to [Call APIs from Client-side Web Apps](/api-auth/grant/implicit). +::: + +The __Implicit Grant__ is an OAuth 2.0 flow that [client-side apps](/quickstart/spa) use in order to access an API. In this document we will work through the steps needed in order to implement this: get the user's authorization, get a token and access an API using the token. + +Before you begin this tutorial, do the following: + +* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately +* [Register your API](/apis#how-to-configure-an-api-in-auth0) with Auth0 + +## 1. Get the User's Authorization + +First, your app should get consent from the user to invoke the API on their behalf. Auth0 will authenticate the user and obtain consent, unless consent has been previously given. + +To initiate the flow, send the user to the [authorization URL](/api/authentication#implicit): + +```text +https://${account.namespace}/authorize? + audience=YOUR_API_AUDIENCE& + scope=YOUR_SCOPE& + response_type=YOUR_RESPONSE_TYPE& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + nonce=YOUR_CRYPTOGRAPHIC_NONCE& + state=YOUR_OPAQUE_VALUE +``` + +Where: + +* `audience`: The unique identifier of the API the app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. + +* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Note that user's consent will be requested, every time the `scope` value changes. + +* `response_type`: Indicates the type of credentials returned in the response. For this flow you can either use `token` to get only an Access Token, `id_token` to get only an ID Token (if you don't plan on accessing an API), or `id_token token` to get both an ID Token and an Access Token. + +* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + +* `redirect_uri`: The URL to which the Auth0 will redirect the user's browser after authorization has been granted by the user. The Access Token (and optionally an ID Token) will be available in the hash fragment of this URL. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings). + + ::: warning + Per the [OAuth 2.0 Specification](https://tools.ietf.org/html/rfc6749#section-3.1.2), Auth0 removes everything after the hash and does *not* honor any fragments. + ::: + +* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state). + +* `nonce`: A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. + +For example: + +```html + + Sign In + +``` + +## 2. Extract the Access Token + +After Auth0 has redirected back to the app, the hash fragment of the URL contains the following parameters: +- `id_token`: contains an [ID Token](/tokens/concepts/id-tokens) and is present if the request parameter `response_type` included the value `id_token`, or the `scope` request parameter the value `openid` +- `access_token`: contains an [Access Token](/tokens/concepts/access-tokens) and is present if the request parameter `response_type` included the value `token` +- `token_type`: denotes the type of the [Access Token](/tokens/concepts/access-tokens) +- `expires_in`: the lifetime in seconds of the Access Token. For example, the value `3600` denotes that the [Access Token](/tokens/concepts/access-tokens) will expire in one hour from the time the response was generated +- `state`: present in the response if the `state` parameter was present in the request. Holds the exact value received from the client in the request. + +You can extract the `access_token`, and other parameters, from the hash fragment of the URL: + +```js +function getParameterByName(name) { + var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash); + return match && decodeURIComponent(match[1].replace(/\+/g, ' ')); +} + +function getAccessToken() { + return getParameterByName('access_token'); +} + +function getIdToken() { + return getParameterByName('id_token'); +} + +$(function () { + var access_token = getAccessToken(); + + // Optional: an ID Token will be returned by Auth0 + // if your response_type argument contained id_token + var id_token = getIdToken(); + + // Use the Access Token to make API calls + // ... +}); +``` + +## 3. Call the API + +Once you have the `access_token` you can use it to make calls to the API, by passing it as a Bearer Token in the `Authorization` header of the HTTP request: + +``` js +// Use the Access Token to make API calls +$('#get-appointments').click(function(e) { + e.preventDefault(); + + $.ajax({ + cache: false, + url: "http://localhost:7001/api/appointments", + headers: { "Authorization": "Bearer " + access_token } + }); +}); +``` + +## 4. Verify the Token + +Once your API receives a request with a Bearer `access_token`, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Optional: Customize the Tokens + +<%= include('../../_includes/_api-auth-customize-tokens') %> + +If you wish to execute special logic unique to the Implicit grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-implicit-profile`, then the rule is running during the Implicit grant. + +## Optional: Silent Authentication + +If you need to authenticate your users without a login page (for example, when the user is already logged in via [Single Sign-on (SSO)](/sso) scenario) or get a new `access_token` (thus simulate refreshing an expired token), you can use Silent Authentication. + +For details on how to implement this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication). + +## Sample application + +For an example implementation see the [SPA + API](/architecture-scenarios/application/spa-api) architecture scenario. + +This is a series of tutorials that describe a scenario for a fictitious company. The company wants to implement a single-page web app that the employees can use to send their timesheets to the company's Timesheets API using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets). + +## Keep reading + +- [How to protect your SPA against replay attacks](/api-auth/tutorials/nonce) +- [How to configure an API in Auth0](/apis) +- [Application Authentication for Client-side Web Apps](/application-auth/client-side-web) +- [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/tutorials/nonce.md b/fr-ca/articles/api-auth/tutorials/nonce.md new file mode 100644 index 0000000000..c83e542ae8 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/nonce.md @@ -0,0 +1,79 @@ +--- +description: How to securely generate and validate a cryptographic nonce for use with the Implicit Grant. +topics: + - api-authentication + - oidc + - implicit + - nonce +contentType: tutorial +useCase: + - secure-api + - call-api +--- + +# Mitigate Replay Attacks When Using the Implicit Flow + +To mitigate replay attacks when using the [Implicit Flow](/flows/concepts/implicit), a nonce must be sent on authentication requests [as required by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest). + +The nonce is generated by the application, sent as a `nonce` query string parameter in the authentication request, and included in the ID Token response from Auth0. This allows applications to correlate the ID Token response from Auth0 with the initial authentication request. + +For more information on where to include the nonce, see [Call API Using the Implicit Flow](/flows/guides/implicit/call-api-implicit). + +::: note +[Auth0.js](/libraries/auth0js) manages `state` and `nonce` parameters for you when using cross-origin authentication. +::: + +## Generate a cryptographically random nonce + +One way to generate a cryptographically random nonce is to use a tool like [Nano ID](https://github.com/ai/nanoid) or similar. This does require you to bundle the tool with your JavaScript code, however. If that's not possible, you can take advantage of the fact that [modern browsers](http://caniuse.com/#feat=cryptography) can use the [Web Crypto API](https://www.w3.org/TR/WebCryptoAPI/) to generate cryptographically secure random strings for use as nonces. + +```js +function randomString(length) { + var charset = '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZabcdefghijklmnopqrstuvwxyz-._' + result = '' + + while (length > 0) { + var bytes = new Uint8Array(16); + var random = window.crypto.getRandomValues(bytes); + + random.forEach(function(c) { + if (length == 0) { + return; + } + if (c < charset.length) { + result += charset[c]; + length--; + } + }); + } + return result; +} +``` + +## Persist nonces across requests + +The generated nonce must be persisted in your web application using any of the following methods: + +* `HttpOnly` session cookie +* HTML5 local storage value + +For example: + +```js +window.localStorage.setItem('nonce', randomString(16)); +``` + +## Validate the ID Token + +Once Auth0 responds with an ID Token, this token must be validated and decoded as usual. +Its `nonce` claim must contain the exact same value that was sent in the request. +If not, authentication should be rejected by the application. + +```js +var jwt = '...'; // validated and decoded ID Token body +if (jwt.nonce === window.localStorage.getItem('nonce')) { + // Nonce is OK +} else { + // Nonce is not OK! Token replay attack might be underway +} +``` diff --git a/fr-ca/articles/api-auth/tutorials/password-grant.md b/fr-ca/articles/api-auth/tutorials/password-grant.md new file mode 100644 index 0000000000..f8ef39ba44 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/password-grant.md @@ -0,0 +1,219 @@ +--- +description: Learn how to implement the OAuth 2.0 Resource Owner Password Grant +toc: true +topics: + - api-authentication + - oidc + - resource-owner-password +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Implement the Resource Owner Password Grant + +<%= include('../_includes/_ropg-warning') %> + +In this tutorial, we will go through the steps required to implement the Resource Owner Password Grant flow. + +## Before you start + +* Check that your application's grant type is set to "Password". To set an application's grant type: + 1. Go to the [Dashboard](${manage_url}) and select **Applications** + 2. Choose your application from the list + 3. On the **Settings** page scroll down to **Advanced Settings** + 4. Select the **Grant Types** tab + 5. Enable the "Password" grant +* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0. +* Update or disable any [rules](/rules) so they only impact specific connections. If you get an `'access_denied'` error when testing the Password Grant, this could be due to an access control rule. + +## Configure your tenant + +The Password Grant relies on a connection capable of authenticating users via username and password. In order to indicate which connection the Password Grant should use you need to set the value of the `default_directory` tenant setting. + +1. Open the [Dashboard](${manage_url}) and browse to your [Tenant Settings](${manage_url}/#/tenant). +1. Scroll down to the __Settings__ section and locate the __Default Directory__ setting. +1. Enter the name of the connection you would like to use. Keep in mind that only connections capable of authenticating users via username and password can be used (such as database connections, AD, LDAP, Windows Azure AD, ADFS) + +![Update Default Directory](/media/articles/api-auth/default-directory-setting.png) + +## Ask for a Token + +In order to execute the flow the application needs to acquire the Resource Owner's credentials, usually this will be through the use of an interactive form. Once the application has the credentials it needs to forward them to Auth0 with a `POST` to the [/oauth/token endpoint of Auth0's Authentication API](/api/authentication#resource-owner-password). + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "password" + }, + { + "name": "username", + "value": "user@example.com" + }, + { + "name": "password", + "value": "pwd" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + }, + { + "name": "scope", + "value": "read:sample" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + } + ] + } +} +``` + +Where: + +* `grant_type`: This must be `password`. +* `username`: The end user's identifier. +* `password`: The end user's password. +* `audience`: The **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial. +* `client_id`: Your application's Client ID. You can find this value at the [Settings tab of the Machine to Machine Application](${manage_url}/#/applications). +* `client_secret`: Your application's Client Secret. You can find this value at the [Settings tab of the Machine to Machine Application](${manage_url}/#/applications). This is required when the **Token Endpoint Authentication Method** field at your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) is `Post` or `Basic`. Do not set this parameter if your application is not highly trusted (for example, SPA). +* `scope`: String value of the different scopes the application is asking for. Multiple scopes are separated with whitespace. + +The response contains a signed JSON Web Token (JWT), the token's type (which is `Bearer`), and in how much time it expires in [Unix time](https://en.wikipedia.org/wiki/Unix_time). + +```js +{ + "access_token": "eyJz93a...k4laUWw", + "token_type": "Bearer", + "expires_in": 36000 +} +``` + +In case the scopes issued to the application differ from the scopes requested, a `scope` parameter will be included in the response JSON, listing the issued scopes. + +::: panel Password grant and standard scopes +If **no** API scopes (such as `read:notes`) are included in the request, all API scopes (such as `read:notes`, `create:notes`, and so on.) are included in the Access Token. +If only the `openid` scope is included in the request, all `openid` standard scopes will be returned, such as `openid profile email address phone`. +In these cases, the `scope` parameter will be included in the response, listing the issued scopes. This happens because a password is equal to full access and hence any password-based exchange gives access to all scopes. +::: + +::: panel How to get the user's claims +If you need the user's claims you can include the scope `openid` to your request. If the API uses `RS256` as the [signing algorithm](/tokens/concepts/signing-algorithms), the Access Token will now also include `/userinfo` as a valid audience. You can use this Access Token to invoke the [/userinfo endpoint](/api/authentication#get-user-info) and retrieve the user's claims. +::: + +### Realm support + +An extension grant that offers similar functionality to ROPG, including the ability to indicate a specific realm, is the `http://auth0.com/oauth/grant-type/password-realm`. + +Realms allow you to keep separate user directories and specify which one to use to the token endpoint. + +To use this variation you will have to change the following request parameters: +* Set the `grant_type` to `http://auth0.com/oauth/grant-type/password-realm`. +* Set the new request parameter `realm` to the realm the user belongs. This maps to a connection in Auth0. For example, if you have configured a database connection for your internal employees and you have named the connection `employees`, then use this value. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/password-realm" + }, + { + "name": "username", + "value": "user@example.com" + }, + { + "name": "password", + "value": "pwd" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + }, + { + "name": "scope", + "value": "read:sample" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "realm", + "value": "employees" + } + ] + } +} +``` + +::: panel Auth0 Connections as Realms +You can configure Auth0 Connections as realms, as long as they support active authentication. This includes [Database](/connections/database), [Passwordless](/connections/passwordless), [Active Directory/LDAP](/connections/enterprise/active-directory-ldap), [Windows Azure AD](/connections/enterprise/azure-active-directory) and [ADFS](/connections/enterprise/adfs) connections. +::: + +## Use the token + +Once the Access Token has been obtained it can be used to make calls to the Resource Server by passing it as a Bearer Token in the `Authorization` header of the HTTP request: + +```har +{ + "method": "GET", + "url": "https://someapi.com/api", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer {ACCESS_TOKEN}" } + ] +} +``` + +## Verify the token + +Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected. + +For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +## Optional: Customize the Tokens + +<%= include('../../_includes/_api-auth-customize-tokens') %> + +If you wish to execute special logic unique to the Password exchange, you can look at the `context.protocol` property in your rule. If the value is `oauth2-password`, then the rule is running during the password exchange. + +## Optional: Configure MFA + +In case you need stronger authentication, than username and password, you can configure multi-factor authentication (MFA) using the Resource Owner Password Grant. For details on how to implement this refer to [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password). + +## Optional: Configure Anomaly Detection + +When using this flow from server-side applications, some anomaly detection features might fail because of the particularities of this scenario. For details on how to implement this, while avoiding some common issues, refer to [Using Resource Owner Password from Server side](/api-auth/tutorials/using-resource-owner-password-from-server-side). + +## Keep reading + +* [Call APIs from Highly Trusted Applications](/api-auth/grant/password) +* [How to configure an API in Auth0](/apis) +* [Tokens](/tokens) diff --git a/fr-ca/articles/api-auth/tutorials/represent-multiple-apis.md b/fr-ca/articles/api-auth/tutorials/represent-multiple-apis.md new file mode 100644 index 0000000000..5eaf10b709 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/represent-multiple-apis.md @@ -0,0 +1,169 @@ +--- + +description: Learn how to use a single logical API in Auth0 to represent and control access to multiple APIs. +topics: + - api-authentication + - oidc + - apis + - scopes + - permissions +contentType: how-to +useCase: + - secure-api + - call-api +--- + +# Represent Multiple APIs Using a Single Logical API + +If you have multiple distinct API implementations that are all logically a part of the same API, you can simplify your authorization process by representing them with a single logical [API](/apis) in the Auth0 Dashboard. Doing this allows you to implement just one authorization flow, while still controlling access to the individual APIs by assigning the appropriate scopes. + +This tutorial explains how to use and represent multiple APIs as a single Resource Server in Auth0. As a learning tool, we provide a sample application that you can follow along with as you read. + +## The Sample Application + +The sample application uses a microservices architecture and contains: + +* 1 Single-Page Application (SPA) +* 2 APIs (services), called `contacts` and `calendar` + +We will represent the two APIs using just one Auth0 API called `Organizer Service`. We will then create two scopes to demonstrate how you can use the [Implicit Flow](/flows/concepts/implicit) to access the `calendar` and `contacts` APIs from the SPA. + +## Prerequisites + +Before beginning this tutorial: + +* [Register your Application with Auth0](/dashboard/guides/applications/register-app-spa) + * Select an **Application Type** of **Single-Page App**. + * Add **Allowed Callback URLs** of `http://localhost:3000` and `http://localhost:3000/callback.html`. +* [Download the sample application](https://github.com/auth0-samples/auth0-api-auth-implicit-sample), so you can follow along as you read. Please see the `README` for additional information on setting up the sample on your local environment. + +## Steps + +1. [Enable a Connection for your Application](#enable-a-connection-for-your-application): Configure a source of users for your new application. +2. [Create a test user](#create-a-test-user): Associate a test user with your new connection. +3. [Register a logical API in Auth0](#register-a-logical-api-in-auth0): Register a single logical API to represent your multiple APIs. +4. [Configure scopes for the logical API](#configure-scopes-for-the-logical-API): Create the scopes that will allow the logical API to represent your multiple APIs. +5. [Grant access to the logical API](#grant-access-to-the-logical-api): Configure the login link in your sample application, initiate the authorization flow, and extract the Access Token to be used to call your multiple APIs. +Optional: [Implement Single Logout (SLO) or Single Sign-on (SSO)](#implement-single-log-out-slo-or-single-sign-on-sso) + +## Enable a connection for your Application + +You will need a source of users for your newly-registered application, so you will need to configure a [Connection](/identityproviders). For the purpose of this sample, we'll create a simple [Database Connection](/connections/database) that asks only for the user's email address and a password. + +1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [Connections > Database](${manage_url}/#/connections/database) in the left-hand nav. Click **Create DB Connection**. +2. The **Create DB Connection** window will open. Provide a **Name** for your Connection, and click **Create** to proceed. +3. Click the **Applications** tab, and enable the Connection. + +## Create a test user + +Since you're working with a newly-created Connection, there won't be any users associated with it. Before we can test the sample application's login process, we'll need to create and associate a user with the Connection. + +1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [Users](${manage_url}/#/users) in the left-hand nav. Click **Create User**. +2. Provide the requested information about the new user (**email address** and **password**), and select your newly-created **Connection**. +3. Click **Save**. + +## Register a logical API in Auth0 + +Register a single logical [API](/apis) that you will use to represent the multiple APIs contained within the sample application. + +1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [APIs](${manage_url}/#/apis) in the left-hand nav. Click **Create API**. + +![](/media/articles/api-auth/tutorials/represent-multiple-apis/dashboard-apis.png) + +2. When prompted, provide a **name** and **identifier** for the new API, and choose the **signing algorithm** for the tokens obtained for this API. + +For the purpose of this sample, we'll call our API `Organizer Service` and set its unique identifier to `organize`. By default, the [signing algorithm](/tokens/concepts/signing-algorithms) for the tokens obtained for this API is **RS256**, which we will leave as is. + +When finished, click **Create**. + +![](/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png) + +## Configure scopes for the logical API + +To allow the logical API to represent the APIs included within the sample application, you will need to create the proper scopes. + +Scopes allow you to define which API actions will be accessible to calling applications. One scope will represent one API/action combination. + +For example, if you want calling applications to be able to `read` and/or `delete` from one API called `samples` and another one called `examples`, you would need to create the following permissions: + +* `read:samples` +* `delete:samples` +* `read:examples` +* `delete:examples` + +You can think of each one as a microservice. + +1. In your newly-created logical API, click the **Scopes** (or **Permissions**) tab. + +![](/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png) + +2. Add two scopes: + +* `read:calendar` +* `read:contacts` + +**Save** your changes. + +![](/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png) + +## Grant access to the logical API + +You are now ready to provide access to your APIs by allowing the logical API to obtain Access Tokens. By including the necessary scopes, you can control an application's access to the APIs represented by the logical API. + +:::panel Authorization Flows + +The rest of this article covers use of the [Implicit Flow](/flows/concepts/implicit) to reflect the sample. However, you can use whichever flow best suits your needs. For example: + +* If you have a **Machine-to-Machine Application**, you can authorize it to request Access Tokens for your API by executing a [Client Credentials Flow](/flows/concepts/client-credentials). +* If you are building a **Native App**, you can implement the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). + +For a full list of available Authorization flows, see [API Authorization](/api-auth). +::: + +1. The user clicks Login within the SPA, and the app redirects the user to the Auth0 Authorization Server (`/authorize` endpoint). + +```text +https://YOUR_AUTH0_DOMAIN/authorize? +scope=read:contacts%20read:calendar& +audience=organize& +response_type=id_token%20token& +client_id=YOUR_CLIENT_ID& +redirect_uri=http://localhost:3000& +nonce=NONCE +``` + +::: note +For additional information on the call's parameters, refer to our tutorial, [Call Your API Using the Implicit Flow](/flows/guides/implicit/call-api-implicit#authorize-the-user). +::: + +![SPA Home before Login](/media/articles/api-auth/tutorials/represent-multiple-apis/home.png) + +2. Your Auth0 Authorization Server redirects the user to the login page, where the user authenticates using one of the configured login options. + +![SPA Login](/media/articles/api-auth/tutorials/represent-multiple-apis/lock.png) + +3. If this is the first time the user has been through this flow, they see a consent prompt listing the permissions Auth0 will give to the SPA. In this case, the user is asked to consent to the app reading their contacts and calendar. + +![Consent Screen](/media/articles/api-auth/tutorials/represent-multiple-apis/consent-screen.png) + +4. If the user consents, Auth0 redirects the user back to the SPA with tokens in the hash fragment of the URI. The SPA can now extract the tokens from the hash fragment using JavaScript and use the Access Token to call your APIs on behalf of the user. + +```js +function getParameterByName(name) { + var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash); + return match && decodeURIComponent(match[1].replace(/\+/g, ' ')); +} + +function getAccessToken() { + return getParameterByName('access_token'); +} +``` + +In our sample, after you successfully log in, you will see buttons that allow you to call either of your APIs using the Access Token obtained from the logical API. + +![SPA Home after Login](/media/articles/api-auth/tutorials/represent-multiple-apis/apis.png) + + +## Implement Single Logout (SLO) or Single Sign-on (SSO) + +<%= include('../../_includes/_checksession_polling') %> diff --git a/fr-ca/articles/api-auth/tutorials/silent-authentication.md b/fr-ca/articles/api-auth/tutorials/silent-authentication.md new file mode 100644 index 0000000000..cb23a93b46 --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/silent-authentication.md @@ -0,0 +1,143 @@ +--- +description: Learn how to keep users logged in to your application using silent authentication. +toc: true +topics: + - api-authentication + - oidc + - silent-authentication +contentType: how-to +useCase: + - secure-api + - call-api +--- + +# Configure Silent Authentication + +The OpenID Connect protocol supports a `prompt=none` parameter on the authentication request that allows applications to indicate that the authorization server must not display any user interaction (such as authentication, consent or MFA). Auth0 will either return the requested response back to the application or return an error if the user is not already authenticated, or that some type of consent or prompt is required before proceeding. + +Use of the [Implicit Flow](/flows/concepts/implicit) in SPAs presents security challenges requiring explicit mitigation strategies. You can use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) in conjunction with Silent Authentication to renew sessions in SPAs. + +<%= include('../../_includes/_refresh_token_rotation_recommended.md') %> + +## Initiate Silent Authentication requests + +To initiate a silent authentication request, add the `prompt=none` parameter when you redirect a user to the [`/authorize` endpoint of Auth0's authentication API](/api/authentication#authorize-application). (The individual parameters on the authentication request will vary depending on the specific needs of your app. +) + +For example: + +```text +GET https://${account.namespace}/authorize + ?response_type=id_token token& + client_id=...& + redirect_uri=...& + state=...& + scope=openid...& + nonce=...& + audience=...& + response_mode=...& + prompt=none +``` + +The `prompt=none` parameter causes Auth0 to immediately send a result to the specified `redirect_uri` (callback URL) using the specified `response_mode` with one of two possible responses: success or error. + +::: note +Any applicable [rules](/rules) will be executed as part of the silent authentication process. +::: + +### Successful authentication responses + +If the user was already logged in to Auth0 and no other interactive prompts are required, Auth0 will respond exactly as if the user had authenticated manually through the login page. + +For example, when using the Implicit Flow, (`response_type=id_token token`, used for single-page applications), Auth0 will respond with the requested tokens: + +```text +GET ${account.callback} + #id_token=...& + access_token=...& + state=...& + expires_in=... +``` + +This response is indistinguishable from a login performed directly without the `prompt=none` parameter. + +### Error responses + +If the user was not logged in via Single Sign-on (SSO) or their SSO session had expired, Auth0 will redirect to the specified `redirect_uri` (callback URL) with an error: + +``` +GET https://your_callback_url/ + #error=ERROR_CODE& + error_description=ERROR_DESCRIPTION& + state=... +``` + +The possible values for `ERROR_CODE` are defined by the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthError): + +| Response | Description | +| -- | -- | +| `login_required` | The user was not logged in at Auth0, so silent authentication is not possible. This error can occur based on the way the tenant-level **Log In Session Management** settings are configured; specifically, it can occur after the time period set in the **Require log in after** setting. See [Configure Session Lifetime Settings](/dashboard/guides/tenants/configure-session-lifetime-settings) for details. | +| `consent_required` | The user was logged in at Auth0, but needs to give consent to authorize the application. | +| `interaction_required` | The user was logged in at Auth0 and has authorized the application, but needs to be redirected elsewhere before authentication can be completed; for example, when using a [redirect rule](/rules/redirect). | + +If any of these errors are returned, the user must be redirected to the Auth0 login page without the `prompt=none` parameter to authenticate. + +## Renew expired tokens + +You can make a silent authentication request to get new tokens as long as the user still has a valid session at Auth0. The [`checkSession` method from auth0.js](/libraries/auth0js#using-checksession-to-acquire-new-tokens) uses a silent token request in combination with `response_mode=web_message` for SPAs so that the request happens in a hidden iframe. With SPAs, Auth0.js handles the result processing (either the token or the error code) and passes the information through a callback function provided by the application. This results in no UX disruption (no page refresh or lost state). + +::: note +See [Renew Tokens When Using Safari](/api-auth/token-renewal-in-safari) for other important limitations and workarounds with the Safari browser. +::: + +### Access Token expiration + +Access Tokens are opaque to applications. This means that applications are unable to inspect the contents of Access Tokens to determine their expiration date. + +There are two options to determine when an Access Token expires: + +* Read the `expires_in` response parameter returned by Auth0. +* Ignore expiration dates altogether. Instead, renew the Access Token if your API rejects a request from the application (such as with a 401). + +In the case of the [Implicit Flow](/flows/concepts/implicit), the `expires_in` parameter is returned by Auth0 as a hash parameter following a successful authentication. In the [Authorization Code Flow](/flows/concepts/auth-code), it is returned to the backend server when performing the authorization code exchange. + +The `expires_in` parameter indicates how many seconds the Access Token will be valid for, and can be used to anticipate expiration of the Access Token. + +### Error response + +You may receive the `timeout` error response which indicates that timeout during executing `web_message` communication has occurred. This error is typically associated with fallback to cross-origin authentication. To resolve, make sure to add all of the URLs from which you want to perform silent authentication in the **Allowed Web Origins** field for your Application using the Auth0 Dashboard. + +## Poll with `checkSession()` + +<%= include('../../_includes/_checksession_polling') %> + +## Silent authentication with MFA + +In some scenarios, you may want to avoid prompting the user for MFA each time they log in from the same browser. To do this, set up a rule so that MFA occurs only once per session. This is useful when performing silent authentication (`prompt=none`) to renew short-lived Access Tokens in a SPA during the duration of a user's session without having to rely on setting `allowRememberBrowser` to `true`. + +```js +function (user, context, callback) { + const completedMfa = !!context.authentication.methods.find( + (method) => method.name === 'mfa' + ); + + if (completedMfa) { + return callback(null, user, context); + } + + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + + callback(null, user, context); +} +``` + +See [Change Authentication Request Frequency](/mfa/guides/customize-mfa-universal-login#change-authentication-request-frequency) for details. + +## Keep reading + +* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) +* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation) + diff --git a/fr-ca/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md b/fr-ca/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md new file mode 100644 index 0000000000..e6a60b46de --- /dev/null +++ b/fr-ca/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md @@ -0,0 +1,128 @@ +--- +description: Learn how to use Resource Owner Password Grant (ROPG) from the server side together with anomaly detection. +toc: true +topics: + - api-authentication + - oidc + - resource-owner-password + - anomaly-detection +contentType: tutorial +useCase: + - secure-api + - call-api +--- + +# Use Resource Owner Password Grant From the Server Side + +<%= include('../_includes/_ropg-warning') %> + +Server-side applications can use the [Resource Owner Password Grant](/api-auth/grant/password) to access an API. The flow typically involves prompting the user for username and password as credentials which your server will submit to Auth0 to get an Access Token. When using this flow from server side, some anomaly detection features might fail because of the particularities of this scenario. This document details how to use [Resource Owner Password Grant](/api-auth/grant/password) flow from server side preventing some common issues. + +## Prerequisites + +Before you continue, make sure to have [brute force protection](/anomaly-detection/guides/enable-disable-brute-force-protection) enabled from your dashboard. + +## How it works + +1. Your server prompts the user for credentials (such as username and password). This could be achieved in many different ways, for example via a browser UI or providing an API. + +2. The user enters credentials and the client-side application submits them to a backend server under your control. + +3. Your server submits the credentials to Auth0 using the [Resource Owner Password Grant](/api-auth/grant/password) flow. + +4. Auth0 validates the credentials and returns an Access Token. As part of the validation process Auth0 might also execute [anomaly-detection verifications](/anomaly-detection) and perform appropriate actions if an anomaly is detected. + +## Brute-force protection and server-side APIs + +Brute-force protection relies on having the original user's IP. When calling the API from your server, Auth0 treats the IP of your server as the IP of the end user, and uses it as input for the anomaly-detection functionality, in particular, for brute-force protection. This situation could potentially trigger false positives into the brute-force protection shields, causing it to block users or trigger warnings for legitimate requests. + +To prevent this, you may send the end-user's IP address to Auth0 along with the credentials and configure the application to trust the provided IP. Because of security considerations, this configuration is only possible for Authenticated applications (such as those with authentication based on a client secret). + +::: warning +Authenticated applications must only be used from protected resources, typically server-side. Do not use them from native applications or SPAs, as they are not capable of storing secrets. +::: + +### Configure the Auth0 Application to receive and trust the IP sent by your server + +1. Navigate to your [dashboard](${manage_url}) and [configure a regular web application or machine-to-machine application](/applications). + +2. Choose a __Token Endpoint Authentication Method__ other than `None` under the [Settings](/dashboard/reference/settings-application) section. + + ![Token Endpoint Authentication Method](/media/articles/api-auth/client-auth-method.png) + +3. Scroll to the bottom and click _Show Advanced Settings_. + + ::: warning + Due to security considerations, the configuration stated on Step 3 will not be available for Non-Authenticated applications. + ::: + +4. Enable __Trust Token Endpoint IP Header__ under the _OAuth_ tab to configure the application to trust the IP sent from your server. + + ![Enabling Auth0-Forwarded-For](/media/articles/api-auth/enabling-auth0-forwarded-for.png) + +### Send the end-user IP from your server + +If your application is configured to send the `auth0-forwarded-for` header and it authenticates (sends `client_secret` in the request): + +- Only the IP in the `auth0-forwarded-for` header is checked against the brute-force protection whitelist. +- The corollary to the above is the proxy IP is ignored by brute-force protection. Don't add the proxy IP to the whitelist (if you did it would have no effect). +- If specific clients that use the proxy should be whitelisted, add them to the whitelist and they will not be subject to brute-force protection. + +If the application is **not** configured to use the `auth0-forwarded-for` header *or* if it does not authenticate (send `client_secret` in the request): + +- The originating IP of each request is checked against the brute-force protection whitelist. +- Whitelisting the IP proxy exempts **all** traffic passing through the proxy from brute-force protection (this is probably not what you want). + +1. To send the end-user IP from your server, include a `auth0-forwarded-for` header with the value of the end-user IP address. + + If the `auth0-forwarded-for` header is marked as trusted, as explained above, Auth0 will use it as the source IP for [brute-force protection](/anomaly-detection). It is important to make sure the provided IP address really belongs to your end user. + +2. When using the resource owner password grant from your webserver with brute-force protection enabled, specify a whitelist of IPs that will not be considered when triggering brute-force protection. Both the `auth0-forwarded-for` IP address and the IP address of the proxy server will be taken into account for IP address whitelists. + +::: warning +Trusting headers like the `x-forwarded-for` (or, in general, data from application) as source for the end user IP can be a big risk. This should not be done unless you know you can trust that header, since it is easy to spoof and makes possible to bypass the anomaly detection validation. +::: + +### Example + +```javascript +var request = require("request"); + +app.post('/api/auth', function(req, res, next) { + var options = { + method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { + 'content-type': 'application/x-www-form-urlencoded', + 'auth0-forwarded-for': req.ip // End user ip + }, + form: { + grant_type: 'password', + username: 'USERNAME', + password: 'PASSWORD', + audience: 'YOUR_API_IDENTIFIER', + scope: 'SCOPE', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated + } + }; + + request(options, function (error, response, body) { + if (error) return next(error); + + // ... + }); +}); +``` + +### Validate with logs + +If your settings are working correctly, you will see the following in the logs: + +```text +type: sepft +... +ip: +client_ip: +... +``` \ No newline at end of file diff --git a/fr-ca/articles/api-auth/user-consent.md b/fr-ca/articles/api-auth/user-consent.md new file mode 100644 index 0000000000..75c4329390 --- /dev/null +++ b/fr-ca/articles/api-auth/user-consent.md @@ -0,0 +1,134 @@ +--- +description: Learn how to decouple APIs from applications that consume them and define third-party apps that you don't control or may not trust. +topics: + - api-authentication + - oidc + - user-consent +contentType: how-to +useCase: + - secure-api + - call-api +--- + +# User Consent and Third-Party Applications + +The [OIDC-conformant authentication pipeline](/api-auth/tutorials/adoption) supports defining [resource servers (such as APIs) as entities separate from applications](/api-auth/tutorials/adoption/api-tokens). This lets you decouple APIs from the applications that consume them, and also lets you define third-party applications that you might not control or even fully trust. + +All applications created from the [Dashboard](${manage_url}/#/applications) are assumed to be first-party by default. + +Third-party applications cannot be created from the Dashboard. They must be created through the Management API, by setting `is_first_party: false`. + +All applications created through [Dynamic Client Registration](/api-auth/dynamic-client-registration) will be third-party. + +## Consent dialog + +If a user is authenticating through a third-party application and is requesting authorization to access the user's information or perform some action at an API on their behalf, they will see a consent dialog. + +For example: + + + + + + + + +
+
GET /authorize?
+client_id=some_third_party_client
+&redirect_uri=https://fabrikam.com/contoso_social
+&response_type=token id_token
+&scope=openid profile email read:posts write:posts
+&audience=https://social.contoso.com
+&nonce=...
+&state=...
+
+ 		+ Auth0 consent dialog - Fabrikam Application for Contoso is requesting access to your account +
+ +If the user allows the application, this creates a *user grant* which represents the user's consent to this combination of application, resource server, and scopes. + +The application then receives a successful authentication response from Auth0 as usual. Once consent has been given, the user won't see the consent dialog during subsequent logins until consent is revoked explicitly. + +## Scope descriptions + +By default, the consent page will use the scopes' names to prompt for the user's consent. As shown below, you should define scopes using the **action:resource_name** format. + +![API Scopes](/media/articles/api-auth/consent-scopes.png) + +The consent page groups scopes for the same resource and displays all actions for that resource in a single line. For example, the configuration above would result in **Posts: read and write your posts**. + +If you would like to display the **Description** field instead, you can do so by setting the tenant's **use_scope_descriptions_for_consent** to **true**. This will affect consent prompts for all of the APIs on that tenant. + +To set the **use_scope_descriptions_for_consent** flag, you will need to make the appropriate call to the API: + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/tenants/settings", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": true } }" + } +} +``` + +## Handle rejected permissions + +If a user decides to reject consent to the application, they will be redirected to the `redirect_uri` specified in the request with an `access_denied` error: + +``` +HTTP/1.1 302 Found +Location: https://fabrikam.com/contoso_social# + error=access_denied + &state=... +``` + +## Skip consent for first-party applications + +Only first-party applications can skip the consent dialog, assuming the resource server they are trying to access on behalf of the user has the "Allow Skipping User Consent" option enabled. + +::: panel Consent can't be skipped on localhost +Note that this option only allows __verifiable__ first-party applications to skip consent at the moment. As `localhost` is never a verifiable first-party (because any malicious application may run on `localhost` for a user), Auth0 will always display the consent dialog for applications running on `localhost` regardless of whether they are marked as first-party applications. During development, you can work around this by modifying your `/etc/hosts` file to add an entry such as the following: + +```text +127.0.0.1 myapp.example +``` + +Similarly, you **cannot** skip consent (even for first-party applications) if `localhost` appears in any domain in the **Allowed Callback URLs** setting (found in [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings)). Make sure to update **Allowed Callback URLs**, and the callback URL you configured in your application, to match the updated domain-mapping. +::: + +Since third-party applications are assumed to be untrusted, they are not able to skip consent dialogs. + +## Revoke Consent + +If a user has provided consent, but you would like to revoke it, you can do so via [Dashboard > Users](${manage_url}/#/users). Select the user in which you are interested, and switch over to the **Authorized Applications** tab. + +Click **Revoke** next to the appropriate application. + +## Password-based flows + +When performing a [Resource Owner Password Credentials exchange](/api-auth/grant/password), there is no consent dialog involved. +During a password exchange, the user provides their password to the application directly, which is equivalent to granting the application full access to the user's account. + +### Force users to provide consent + +When redirecting to /authorize, the `prompt=consent` parameter will force users to provide consent, even if they have an existing user grant for that application and requested scopes. + +### Customize the consent dialog + +The consent dialog UI cannot be customized or set to a custom domain. + +## Keep reading + +* [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) +* [View Application Ownership](/api/management/guides/applications/view-ownership) +* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public) +* [Enable Third-Party Applications](/applications/guides/enable-third-party-apps) +* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping) diff --git a/fr-ca/articles/api-auth/which-oauth-flow-to-use.md b/fr-ca/articles/api-auth/which-oauth-flow-to-use.md new file mode 100644 index 0000000000..3c2fe7f418 --- /dev/null +++ b/fr-ca/articles/api-auth/which-oauth-flow-to-use.md @@ -0,0 +1,69 @@ +--- +title: Which OAuth 2.0 Flow Should I Use? +toc: true +description: Learn how to identify the proper OAuth 2.0 grant for your use case. +topics: + - api-authentication + - oidc + - application-grants + - flows +contentType: + - concept +useCase: + - secure-api + - call-api +--- + +# Which OAuth 2.0 Flow Should I Use? + +[OAuth 2.0](https://tools.ietf.org/html/rfc6749) supports several different **grants**. Grants are ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Client's type, but other parameters weigh in as well, like the level of trust for the Client, or the experience you want your users to have. + +## OAuth 2.0 terminology + +- **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user. +- **Client**: an application requesting access to a protected resource on behalf of the Resource Owner. +- **Resource Server**: the server hosting the protected resources. This is the API you want to access. +- **Authorization Server**: the server that authenticates the Resource Owner and issues Access Tokens after getting proper authorization. In this case, Auth0. +- **User Agent**: the agent used by the Resource Owner to interact with the Client, for example a browser or a native application. + +## Is the Client the Resource Owner? + +The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed. An example is a cron job that uses an API to import information to a database. In this example, the cron job is the Client and the Resource Owner since it holds the Client ID and Client Secret and uses them to get an Access Token from the Authorization Server. + +If this case matches your needs, then for more information on how this flow works and how to implement it, refer to [Client Credentials Flow (Client Credentials Grant)](/flows/concepts/client-credentials). + +## Is the Client a web app executing on the server? + +If the Client is a regular web app executing on a server, then the **Authorization Code Flow (Authorization Code grant)** is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token. It's considered the safest choice since the Access Token is passed directly to the web server hosting the Client, without going through the user's web browser and risk exposure. + +If this case matches your needs, then for more information on how this flow works and how to implement it, refer to [Authorization Code Flow](/flows/concepts/auth-code). + +## Is the Client absolutely trusted with user credentials? + +This decision point may result in the **Resource Owner Password Credentials Grant**. In this flow, the end-user is asked to fill in credentials (username/password), typically using an interactive form. This information is sent to the backend and from there to Auth0. It is therefore imperative that the Client is absolutely trusted with this information. + +This grant should **only** be used when redirect-based flows (like the [Authorization Code Flow](/flows/concepts/auth-code)) are not possible. If this is your case, then for more information on how this flow works and how to implement it, refer to [Call APIs from Highly Trusted Applications](/api-auth/grant/password). + +## Is the Client a Single Page App? + +If the Client is a Single Page App, an application running in a browser using a scripting language like JavaScript, there are two grant options: the **Authorization Code Grant using Proof Key for Code Exchange (PKCE)** and the **Implicit Grant**. For most cases, we recommend using the Authorization Code Grant with PKCE. + +### Authorization Code Grant with PKCE + +This grant adds the concept of a `code_verifier` to the Authorization Code Grant. When the Client asks for an **Authorization Code** it generates a `code_verifier` and its transformed value called `code_challenge`. The `code_challenge` and a `code_challenge_method` are sent along with the request. When the Client wants to exchange the Authorization Code for an Access Token, it also sends along the `code_verifier`. The Authorization Server transforms this and if it matches the originally sent `code_challenge`, it returns an Access Token. + +The [Auth0 Single Page App SDK](/libraries/auth0-spa-js) provides high-level API for implementing Authorization Code Grant with PKCE in single page applications. + +For more information on how this flow works and how to implement it, refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). + +### Implicit Grant + +In this case, instead of getting an authorization code that needs to be exchanged for an Access Token, the Application directly retrieves an Access Token. On the plus side, this is more efficient since it reduces the number of round trips required to get an Access Token. However, a security consideration is that **the Access Token is exposed on the client side**. Also, note that this flow does not return a Refresh Token because the browser cannot keep it private. + +For more information on how this flow works and how to implement it, refer to [Implicit Flow](/flows/concepts/implicit). + +## Is the Client a Native/Mobile App? + +If the Application is a native app, then the **Authorization Code Flow with PKCE (Authorization Code Grant using Proof Key for Code Exchange)** should be used. + +For more information on how this flow works and how to implement it, refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). diff --git a/fr-ca/articles/api/authentication/_application-reg.md b/fr-ca/articles/api/authentication/_application-reg.md new file mode 100644 index 0000000000..21471c3821 --- /dev/null +++ b/fr-ca/articles/api/authentication/_application-reg.md @@ -0,0 +1,50 @@ +# Dynamic Application (Client) Registration + +```http +POST https://${account.namespace}/oidc/register +Content-Type: application/json +{ + "client_name": "YOUR-NEW-CLIENT-NAME", + "redirect_uris": [], + "token_endpoint_auth_method": "client_secret_post" +} +``` + +```shell +curl --request POST \ + --url https://${account.namespace}/oidc/register \ + --header 'content-type: application/json' \ + --data '{"client_name": "YOUR-NEW-CLIENT-NAME","redirect_uris": [], "token_endpoint_auth_method": "client_secret_post"}' +``` + +> RESPONSE SAMPLE: + +```json +{ + "client_name": "My Dynamic Client", + "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2", + "client_secret": "Q5O...33P", + "redirect_uris": [ + "https://client.example.com/callback", + "https://client.example.com/callback2" + ], + "client_secret_expires_at": 0 +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oidc/register", + "link": "#dynamic-application-client-registration" +}) %> + +With a name and the necessary callback URL, you can dynamically register a client with Auth0. No token is needed for this request. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_name` | The name of the Dynamic Client to be created. It is recommended to provide a value but if it is omitted, the default name "My App" will be used. | +| `redirect_uris`
Required | An array of URLs that Auth0 will deem valid to call at the end of an Authentication flow. | +| `token_endpoint_auth_method` | Default value is `client_secret_post`. Use `token_endpoint_auth_method: none` in the request payload if creating a SPA.| diff --git a/fr-ca/articles/api/authentication/_change-password.md b/fr-ca/articles/api/authentication/_change-password.md new file mode 100644 index 0000000000..00e44b2854 --- /dev/null +++ b/fr-ca/articles/api/authentication/_change-password.md @@ -0,0 +1,87 @@ +# Change Password + +```http +POST https://${account.namespace}/dbconnections/change_password +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "email": "EMAIL", + "connection": "CONNECTION", + "organization": "ORGANIZATION_ID" +} +``` + +```shell +curl --request POST \ + --url https://${account.namespace}/dbconnections/change_password \ + --header 'content-type: application/json' \ + --data '{"client_id": "${account.clientId}","email": "EMAIL", "connection": "CONNECTION", "organization": "ORGANIZATION_ID"}' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/dbconnections/change_password", + "link": "#change-password" +}) %> + +> RESPONSE SAMPLE: + +```JSON +"We've just sent you an email to reset your password." +``` + +Send a change password email to the user's provided email address and `connection`. + +Optionally, you may provide an Organization ID to support Organization-specific variables in [customized email templates](/customize/email/email-templates#common-variables) and to include the `organization_id` and `organization_name` parameters in the **Redirect To** URL. + +Note: This endpoint only works for database connections. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id` | The `client_id` of your client. | +| `email`
Required | The user's email address. | +| `connection`
Required | The name of the database connection configured to your client. | +| `organization` | The `organization_id` of the Organization associated with the user. | + + +### Remarks + +- When the user clicks on the password change link they will be redirected to a page asking them for a new password. +- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits: + * `X-RateLimit-Limit`: Number of requests allowed per minute. + * `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time. + * `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time). + + +### Learn More + +- [Changing a User's Password](/connections/database/password-change) +- [Password Strength in Auth0 Database Connections](/connections/database/password-strength) +- [Password Options in Auth0 Database Connections](/connections/database/password-options) +- [Auth0 API Rate Limit Policy](/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) diff --git a/fr-ca/articles/api/authentication/_introduction.md b/fr-ca/articles/api/authentication/_introduction.md new file mode 100644 index 0000000000..0df041af98 --- /dev/null +++ b/fr-ca/articles/api/authentication/_introduction.md @@ -0,0 +1,145 @@ +# Introduction + +The Authentication API enables you to manage all aspects of user identity when you use Auth0. It offers endpoints so your users can log in, sign up, log out, access APIs, and more. + +The API supports various identity protocols, like [OpenID Connect](/protocols/oidc), [OAuth 2.0](/protocols/oauth2), [FAPI](/secure/highly-regulated-identity#advanced-security-with-openid-connect-fapi-) and [SAML](/protocols/saml). + +:::note +This API is designed for people who feel comfortable integrating with RESTful APIs. If you prefer a more guided approach check out our [Quickstarts](/quickstarts) or our [Libraries](/libraries). +::: + +## Base URL + +The Authentication API is served over HTTPS. All URLs referenced in the documentation have the following base: `https://${account.namespace}` + +## Authentication methods + +You have five options for authenticating with this API: +- OAuth2 Access Token +- Client ID and Client Assertion (confidential applications) +- Client ID and Client Secret (confidential applications) +- Client ID (public applications) +- mTLS Authentication (confidential applications) + +### OAuth2 Access Token + +Send a valid Access Token in the `Authorization` header, using the `Bearer` authentication scheme. + +An example is the [Get User Info endpoint](#get-user-info). In this scenario, you get an Access Token when you authenticate a user, and then you can make a request to the [Get User Info endpoint](#get-user-info), using that token in the `Authorization` header, in order to retrieve the user's profile. + +### Client ID and Client Assertion +Generate a [client assertion](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) containing a signed JSON Web Token (JWT) to authenticate. In the body of the request, include your Client ID, a `client_assertion_type` parameter with the value `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`, and a `client_assertion` parameter with your signed assertion. Review [Private Key JWT]( https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) for examples. + +### Client ID and Client Secret + +Send the Client ID and Client Secret. The method you can use to send this data is determined by the [Token Endpoint Authentication Method](/get-started/applications/confidential-and-public-applications/view-application-type) configured for your application. + +If you are using **Post**, you must send this data in the JSON body of your request. + +If you are using **Basic**, you must send this data in the `Authorization` header, using the `Basic` authentication scheme. To generate your credential value, concatenate your Client ID and Client Secret, separated by a colon (`:`), and encode it in Base64. + +An example is the [Revoke Refresh Token endpoint](#revoke-refresh-token). This option is available only for confidential applications (such as applications that are able to hold credentials in a secure way without exposing them to unauthorized parties). + +### Client ID + +Send the Client ID. For public applications (applications that cannot hold credentials securely, such as SPAs or mobile apps), we offer some endpoints that can be accessed using only the Client ID. + +An example is the [Implicit Grant](#implicit-flow). + +### mTLS Authentication + +Generate a certificate, either [self-signed](/get-started/applications/configure-mtls/configure-mtls-for-a-client#self-signed-certificates) or [certificate authority signed](/get-started/applications/configure-mtls/configure-mtls-for-a-client#certificate-authority-signed-certificates). Then, [set up the customer edge network](/get-started/applications/configure-mtls/set-up-the-customer-edge) that performs the mTLS handshake. + +Once your edge network verifies the certificate, forward the request to the Auth0 edge network with the following headers: + +- The Custom Domain API key as the `cname-api-key` header. +- The client certificate as the `client-certificate` header. +- The client certificate CA verification status as the `client-certificate-ca-verified` header. For more information, see [Forward the Request](/get-started/applications/configure-mtls/set-up-the-customer-edge#forward-the-request-). + +To learn more, read [Authenticate with mTLS](/get-started/authentication-and-authorization-flow/authenticate-with-mtls). + +## Parameters + +For GET requests, any parameters not specified as a segment in the path can be passed as an HTTP query string parameter: + +`GET https://${account.namespace}/some-endpoint?param=value¶m=value` + +For POST requests, parameters not included in the URL should be encoded as JSON with a Content-Type of `application/json`: + +`curl --request POST --url 'https://${account.namespace}/some-endpoint' --header 'content-type: application/json' --data '{"param": "value", "param": "value"}'` + +::: note +An exception to that is the [SAML IdP-Initiated Single Sign-on (SSO) Flow](#idp-initiated-sso-flow), which uses both a query string parameter and a `x-www-form-urlencoded` value. +::: + +## Code samples + +For each endpoint, you will find sample snippets you can use, in three available formats: +- HTTP request +- Curl command +- JavaScript: depending on the endpoint each snippet may use the [Auth0.js library](/libraries/auth0js), Node.js code or simple JavaScript + +Each request should be sent with a Content-Type of `application/json`. + +## Testing + +You can test the endpoints using the [Authentication API Debugger](/extensions/authentication-api-debugger). + +### Authentication API Debugger + +The [Authentication API Debugger](/extensions/authentication-api-debugger) is an Auth0 extension you can use to test several endpoints of the Authentication API. + +<%= include('../../_includes/_test-this-endpoint') %> + +### Configure Connections + +1. On the *Configuration* tab, set the fields **Application** (select the application you want to use for the test) and **Connection** (the name of the social connection to use). + +1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications). + +1. At the *OAuth2 / OIDC* tab, select **OAuth2 / OIDC Login**. + +### Endpoint options +Configure other endpoints with the following options: + +- Passwordless: On the *OAuth2 / OIDC* tab, set **Username** to the user's phone number if `connection=sms`, or the user's email if `connection=email`, and **Password** to the user's verification code. Click **Resource Owner Endpoint**. +- SAML SSO: On the *Other Flows* tab, select **SAML**. +- WS-Federation: On the *Other Flows* tab, select **WS-Federation**. +- Logout: On the *Other Flows* tab, select **Logout**, or **Logout (Federated)** to log the user out of the identity provider as well. +- Legacy Login: On the *OAuth2 / OIDC* tab, set the fields **ID Token**, **Refresh Token** and **Target Client ID**. Click **Delegation**. +- Legacy Delegation: On the *OAuth2 / OIDC* tab, set **Username** and **Password**. Click **Resource Owner Endpoint**. +- Legacy Resource Owner: On the *OAuth2 / OIDC* tab, set the **Username** and **Password**, then select **Resource Owner Endpoint**. + +### Authentications flows + +Configure authentication flows with the following options: +- Authorization Code Flow: On the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](/get-started/authentication-and-authorization-flow/authorization-code-flow), and the **Code Verifier** to the key. Click **OAuth2 Code Exchange**. +- Authorization Code Flow + PKCE: On the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce), and the **Code Verifier** to the key. Click **OAuth2 Code Exchange**. +- Client Credential Flow: On the *OAuth2 / OIDC* tab, select **OAuth2 Client Credentials**. + + +## Errors + +When an error occurs, you will receive an error object. Most of these error objects contain an error code and an error description so that your applications can more efficiently identify the problem. + +If you get an `4xx` HTTP response code, then you can assume that there is a bad request from your end. In this case, check the [Standard Error Responses](#standard-error-responses) for more context. + +`5xx` errors suggest a problem on Auth0's end, so in this case, check [Auth0 Status Page](https://status.auth0.com/) and [@auth0status on Twitter](https://twitter.com/auth0status) to see how our systems are doing. + +In any other case you can use [our support options](#support). + +## Rate limiting + +The Authentication API is subject to rate limiting. The limits differ per endpoint. + +If you exceed the provided rate limit for a given endpoint, you will receive the `429 Too Many Requests` response with the following message: `Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.` + +For details on rate limiting, refer to [Auth0 API Rate Limit Policy](/policies/rate-limits). + +Note that for database connections Auth0 limits certain types of repeat login attempts depending on the user account and IP address. For details, refer to [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits). + +## Support + +If you have problems or need help with your case, you can always reach out to our [Support](${env.DOMAIN_URL_SUPPORT}). + +Note that if you have a free subscription plan, and you are not in your 22-day trial period, you will not be able to access or open tickets in the [Support Center](${env.DOMAIN_URL_SUPPORT}). In this case, you can seek support through the [Auth0 Community](https://community.auth0.com/). For more info on our support program, refer to [Support Options](/support). diff --git a/fr-ca/articles/api/authentication/_login.md b/fr-ca/articles/api/authentication/_login.md new file mode 100644 index 0000000000..291091ada0 --- /dev/null +++ b/fr-ca/articles/api/authentication/_login.md @@ -0,0 +1,373 @@ + +# Login + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#social" +}) %> + +## Social + +```http +GET https://${account.namespace}/authorize? + response_type=code|token& + client_id=${account.clientId}& + connection=CONNECTION& + redirect_uri=${account.callback}& + state=STATE& + ADDITIONAL_PARAMETERS +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +You can connect your Auth0 service to a social identity provider and allow your users to log in to your application via Facebook, Google, Apple, or other supported providers. To learn more about supported providers, visit [Marketplace](https://marketplace.auth0.com/features/social-connections). + +To authenticate users with a social provider, make a `GET` call to the `/authorize` endpoint. It will return a `302` redirect to the social provider specified in the `connection` parameter. + +::: note +Social connections only support browser-based (passive) authentication because most social providers don't allow a username and password to be entered into applications that they don't own. Therefore, the user will be redirected to the provider's sign in page. +::: + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `response_type`
Required | Specifies the token type. Use `code` for server side flows and `token` for application side flows | +| `client_id`
Required | The `client_id` of your application | +| `connection` | The name of a social identity provider configured to your application, for example `google-oauth2` or `facebook`. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget. | +| `redirect_uri`
Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).| +| `state`
Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. | +| `ADDITIONAL_PARAMETERS` | Append any additional parameter to the end of your request, and it will be sent to the provider. For example, `access_type=offline` (for Google Refresh Tokens) , `display=popup` (for Windows Live popup mode). | + +### Remarks + +- If `response_type=token`, after the user authenticates on the provider, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs. + +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Learn More + +- [Supported Social Identity Providers](https://marketplace.auth0.com/features/social-connections) +- [Custom Social Connections](/connections/social/oauth2) +- [State Parameter](/secure/attack-protection/state-parameters) +- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) + +## Database/AD/LDAP (Passive) + +```http +GET https://${account.namespace}/authorize? + response_type=code|token& + client_id=${account.clientId}& + connection=CONNECTION& + redirect_uri=${account.callback}& + scope=openid%20profile%20email& + state=STATE +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +Use the Auth0 user store or your own database to store and manage username and password credentials. If you have your own user database, you can use it as an identity provider in Auth0 to authenticate users. When you make a `GET` call to the `/authorize` endpoint for browser based (passive) authentication. It returns a `302` redirect to the [Auth0 Login Page](https://${account.namespace}/login) that will show the Login Widget where the user can log in with email and password. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `response_type`
Required | Specifies the token type. Use `code` for server side flows and `token` for application side flows. | +| `client_id`
Required | The `client_id` of your application. | +| `connection` | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. | +| `redirect_uri`
Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).| +| `scope`
Recommended | OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a Refresh Token.| +| `state`
Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. | + +### Remarks + +- If `response_type=token`, after the user authenticates, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs. +- The main difference between passive and active authentication is that the former happens in the browser through the [Auth0 Login Page](https://${account.namespace}/login) and the latter can be invoked from anywhere (a script, server to server, and so forth). +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Learn More + +- [Database Identity Providers](/connections/database) +- [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits) +- [Active Directory/LDAP Connector](/connector) +- [State Parameter](/protocols/oauth2/oauth-state) +- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) + +## Enterprise (SAML and Others) + +```http +GET https://${account.namespace}/authorize? + response_type=code|token& + client_id=${account.clientId}& + connection=CONNECTION& + redirect_uri=${account.callback}& + state=STATE +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +You can connect your Auth0 service to an enterprise identity provider and allow your users to log in to your application via Microsoft Azure Active Directory, Google Workspace, Okta Workforce, or other supported providers. To learn more about supported providers, visit [Auth0 Marketplace](https://marketplace.auth0.com/features/enterprise-connections). + +Make a `GET` call to the `/authorize` endpoint for passive authentication. It returns a `302` redirect to the SAML Provider (or Windows Azure AD and the rest, as specified in the `connection`) to enter their credentials. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `response_type`
Required | Specifies the token type. Use `code` for server side flows, `token` for application side flows. | +| `client_id`
Required | The `client_id` of your application. | +| `connection` | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. | +| `redirect_uri`
Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).| +| `state`
Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. | + +### Remarks + +- If no `connection` is specified, it will redirect to the [Login Page](https://${account.namespace}/login) and show the Login Widget. +- If `response_type=token`, after the user authenticates, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs. +- Additional parameters can be sent that will be passed to the provider. +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Learn More + +- [SAML](/protocols/saml) +- [Obtain a Client Id and Client Secret for Microsoft Azure Active Directory](/connections/enterprise/azure-active-directory) +- [State Parameter](/protocols/oauth2/oauth-state) +- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-) + +## Back-Channel Login + +:::note +This feature is currently in Early Access. To request access, contact your Technical Account Manager. +::: + +The Back-Channel Login endpoint enables applications to send an authentication request to a user’s phone, or the authentication device, provided they have an app installed and are enrolled for [push notifications using the Guardian SDK](/secure/multi-factor-authentication/auth0-guardian#enroll-in-push-notifications). + +Use the Back-Channel Login endpoint to authenticate users for the following use cases: + +- Users are not in front of the application that requires authentication, such as when they're telephoning a call center. +- The consumption device, or the device that helps the user consume a service, is insecure for sensitive operations e.g. web browser for financial transactions. +- The consumption device has limited interactive capability e.g. e-bicycles or e-scooters. + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/bc-authorize", + "link": "#back-channel-login" +}) %> + +```http +curl --location 'https://[TENANT_DOMAIN]/bc-authorize' \ +--header 'Content-Type: application/x-www-form-urlencoded' \ +--data-urlencode 'client_id=[CLIENT ID]' \ +--data-urlencode 'client_secret=[CLIENT SECRET]' \ +--data-urlencode 'binding_message=[YOUR BINDING MESSAGE]' \ +--data-urlencode 'login_hint={ "format": "iss_sub", "iss": +"https://[TENANT].auth0.com/", "sub": "auth0|[USER ID]" }' \ +--data-urlencode 'scope=openid' +``` + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Client ID of your application. | +| `binding_message`
Required | Human-readable string displayed on both the device calling `/bc-authorize` and the user’s authentication device (e.g. phone) to ensure the user is approves the correct request. For example: `ABC-123-XYZ`. | +| `login_hint`
Required | String containing information about the user to contact for authentication. It uses the [IETF9493 standard for Subject Identifiers for Security Event Tokens](https://datatracker.ietf.org/doc/html/rfc9493). Auth0 only supports the [Issuer and Identifier format](https://datatracker.ietf.org/doc/html/rfc9493#name-issuer-and-subject-identifi). For an example login hint, review the [Remarks](#remarks). | +| `scope`
Required | Space-separated list of OIDC and custom API scopes. For example: `openid read:timesheets edit:timesheets`. Include `offline_access` to get a refresh token. At a minimum, you must include the scope `openid`. | +| `audience`
Optional | Unique identifier of the audience for an issued token. If you require an access token for an API, pass the unique identifier of the target API you want to access. | +| `request_expiry`
Optional | To configure a custom expiry time in seconds for this request, pass a number between 1 and 300. If not provided, expiry defaults to 300 seconds. | + +### Response Body + +If the request is successful, you should receive a response like the following: + +```http +{ + "auth_req_id": "eyJh...", + "expires_in": 300, + "interval": 5 +} +``` + +The `auth_req_id` value should be kept as it is used later in the flow to identify the authentication request. + +The `expires_in` value tells you how many seconds you have until the authentication request expires. + +The `interval` value tells you how many seconds you must wait between poll requests. + +The request should be approved or rejected on the user’s authentication device using the Guardian SDK. + +### Remarks + +The following code sample is an example login hint: + + ```http + { + "format": "iss_sub", + "iss": "https://[TENANT_DOMAIN]/", + "sub": "auth0|[USER ID]" + } + ``` + +White space is not significant. Replace the `[TENANT_DOMAIN]` with your tenant domain or custom domain. Replace the `[USER ID]` with a valid `user_id` for the authorizing user returned from the [User Search APIs](https://auth0.com/docs/manage-users/user-search). + +Include an optional parameter for application authentication in the request: + +- Client Secret with HTTP Basic auth, in which case no parameters are required. The `client_id` and `client_secret` are passed in a header. +- Client Secret Post, in which case the `client_id` and `client_secret` are required. +- Private Key JWT, where the `client_id`, `client_assertion` and `client_assertion` type are required. +- mTLS, where the `client_id` parameter is required and the `client-certificate` and `client-certificate-ca-verified` headers are required. + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/token", + "link": "#post-token" +}) %> + +```http +curl --location 'https://[TENANT_DOMAIN]/oauth/token' \ +--header 'Content-Type: application/x-www-form-urlencoded' \ +--data-urlencode 'client_id=[CLIENT ID]' \ +--data-urlencode 'client_secret=[CLIENT SECRET]' \ +--data-urlencode 'auth_req_id=[FROM THE BC-AUTHORIZE RESPONSE]' \ +--data-urlencode 'grant_type=urn:openid:params:grant-type:ciba' +``` + +To check on the status of a Back-Channel Login flow, poll the `/oauth/token` endpoint at regular intervals by passing the following: + +- `auth_req_id` returned from the call to `/bc-authorize` +- `urn:openid:params:grant-type:ciba` grant type + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Client ID of your application | +| `auth_req_id`
Required | Used to reference the authentication request. Returned from the call to `/bc-authorize` | +| `grant_type`
Required | Must be set to `urn:openid:params:grant-type:ciba` | + +### Response Body + +If the authorizing user has not yet approved or rejected the request, you should receive a response like the following: + +```http +{ + "error": "authorization_pending", + "error_description": "The end-user authorization is pending" +} +``` + +If the authorizing user rejects the request, you should receive a response like the following: + +```http +{ + "error": "access_denied", + "error_description": "The end-user denied the authorization request or it +has been expired" +} +``` + +If you are polling too quickly (faster than the interval value returned from `/bc-authorize`), you should receive a response like the following: + +```http +{ + "error": "slow_down", + "error_description": "You are polling faster than allowed. Try again in 10 seconds." +} +``` + +In addition, Auth0 will add the the [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) header to the response indicating how many seconds to wait before attempting to poll again. If you consistently poll too frequently, the number of seconds you must wait increases. + +If the authorizing user has approved the push notification, the call returns the ID token and access token (and potentially a refresh token): + +```http +{ + "access_token": "eyJh...", + "id_token": "eyJh...", + "expires_in": 86400, + "scope": "openid" +} +``` + +Once you have exchanged an `auth_req_id` for an ID or access token, it is no longer usable. + +### Remarks + +Include an optional parameter for application authentication in the request: + +- Client Secret with HTTP Basic auth, in which case no parameters are required. The `client_id` and `client_secret` are passed in a header. +- Client Secret Post, in which case the `client_id` and `client_secret` are required. +- Private Key JWT, where the `client_id`, `client_assertion` and `client_assertion` type are required. +- mTLS, where the `client_id` parameter is required and the `client-certificate` and `client-certificate-ca-verified` headers are required. \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/_logout.md b/fr-ca/articles/api/authentication/_logout.md new file mode 100644 index 0000000000..751cd42692 --- /dev/null +++ b/fr-ca/articles/api/authentication/_logout.md @@ -0,0 +1,176 @@ +# Logout +## Auth0 Logout + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/v2/logout", + "link": "#logout" +}) %> + +```http +GET https://${account.namespace}/v2/logout? + client_id=${account.clientId}& + returnTo=LOGOUT_URL +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/v2/logout' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "returnTo":"LOGOUT_URL"}' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +Use this endpoint to logout a user. If you want to navigate the user to a specific URL after the logout, set that URL at the `returnTo` parameter. The URL should be included in any the appropriate `Allowed Logout URLs` list: +- If the `client_id` parameter is included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the application level. To learn more, read [Log Users Out of Applications](/authenticate/login/logout/log-users-out-of-applications). +- If the `client_id` parameter is NOT included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the tenant level. To learn more, read [Log Users Out of Auth0](/authenticate/login/logout/log-users-out-of-auth0). +- If the `client_id` parameter is included and the `returnTo` URL is NOT set, the server returns the user to the first Allowed Logout URLs set in the Dashboard. To learn more, read [Log Users Out of Applications](/authenticate/login/logout/log-users-out-of-applications). + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `returnTo` | URL to redirect the user after the logout. | +| `client_id` | The `client_id` of your application. | +| `federated` | Add this query string parameter to the logout URL, to log the user out of their identity provider, as well: `https://${account.namespace}/v2/logout?federated`. | + +### Remarks + +- Logging the user out of their identity provider is not common practice, so think about the user experience before you use the `federated` query string parameter. +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Learn More + +- [Logout](/logout) + +## OIDC Logout +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/oidc/logout", + "link": "#logout" +}) %> + +```http +GET https://${account.namespace}/oidc/logout? + post_logout_redirect_uri=LOGOUT_URL& + id_token_hint=ID_TOKEN_HINT +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/oidc/logout' \ + --header 'content-type: application/json' \ + --data-raw ' + { + "client_id":"${account.clientId}", + "post_logout_redirect_uri":"LOGOUT_URL", + "id_token_hint":"ID_TOKEN_HINT" + }' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +Use this endpoint to logout a user. If you want to navigate the user to a specific URL after the logout, set that URL at the `post_logout_redirect_uri` parameter. The URL should be included in the appropriate `Allowed Logout URLs` list: + +- If the `id_token_hint` parameter is included: + - When the `client_id` parameter is included, the server uses the URL from the `aud` claim in the `id_token_hint` to select which of the `Allowed Logout URLs` to use from the application specified by the `client_id`. + - When the `client_id` parameter is NOT included, the server uses the URL from the `aud` claim in the `id_token_hint` to select which of the `Allowed Logout URLs` at the tenant level to use. +- If the `id_token_hint` parameter is not included: + - If the `client_id` parameter is included, the `post_logout_redirect_uri` URL must be listed in the `Allowed Logout URLs` set at the application level. + - If the `client_id` parameter is NOT included, the `post_logout_redirect_uri` URL must be listed in the `Allowed Logout URLs` set at the tenant level. + - If the `client_id` parameter is included and the `post_logout_redirect_uri` URL is NOT set, the server returns the user to the first `Allowed Logout URLs` set in Auth0 Dashboard. + + To learn more, read [Log Users Out of Auth0 with OIDC Endpoint](/authenticate/login/logout/log-users-out-of-auth0). + + +### Request Parameters + +| Parameter | Description | +| :------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `id_token_hint` (Recommended) | Previously issued ID Token for the user. This is used to indicate which user to log out. | +| `logout_hint` (Optional) | Optional `sid` (session ID) value to indicate which user to log out. Should be provided when `id_token_hint` is not available. | +| `post_logout_redirect_uri` (Optional) | URL to redirect the user after the logout. | +| `client_id` (Optional) | The `client_id` of your application. | +| `federated` (Optional) | Add this query string parameter to log the user out of their identity provider: `https://YOUR_DOMAIN/oidc/logout?federated`. | +| `state` (Optional) | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the`post_logout_redirect_uri`. | +| `ui_locales` (Optional) | Space-delimited list of locales used to constrain the language list for the request. The first locale on the list must match the enabled locale in your tenant | + +### Remarks + +- Logging the user out of their social identity provider is not common practice, so think about the user experience before you use the `federated` query string parameter with social identity providers. +- If providing both `id_token_hint` and `logout_hint`, the `logout_hint` value must match the `sid` claim from the id_token_hint. +- If providing both `id_token_hint` and `client_id`, the `client_id` value must match the `aud` claim from the `id_token_hint`. +- If `id_token_hint` is not provided, then the user will be prompted for consent unless a `logout_hint` that matches the user's session ID is provided. +- The `POST` HTTP method is also supported for this request. When using `POST`, the request parameters should be provided in the request body as form parameters instead of the query string. The federated parameter requires a value of `true` or `false`. +- This conforms to the [OIDC RP-initiated Logout Specification](https://openid.net/specs/openid-connect-rpinitiated-1_0.html). + +### Learn More + +- [Logout](/logout) +- [Use the OIDC Endpoint to Log Users Out of Auth0](/logout/log-users-out-of-auth0) +- [OIDC RP-initiated Logout Specification](https://openid.net/specs/openid-connect-rpinitiated-1_0.html) + +## SAML Logout + +```http +POST https://${account.namespace}/samlp/CLIENT_ID/logout +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/samlp/CLIENT_ID/logout' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data '{SAML_LOGOUT_REQUEST}' +``` + +Use this endpoint to log out a user from an Auth0 tenant configured as a SAML identity provider (IdP). + +Logout behavior is determined by the configuration of the SAML2 Web App addon for the application on the Auth0 tenant acting as the SAML IdP. To learn more, read [Log Users Out of SAML Identity Providers](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps#configure-slo-when-auth0-is-the-saml-idp). + +### Request Parameters + +| Parameter | Description | +|:--|:--| +| `CLIENT_ID` | Client ID of your application configured with the [SAML2 Web App addon](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/enable-saml2-web-app-addon). | +| `SAML_LOGOUT_REQUEST` | SAML `` message. | + +### Remarks +- The POST body must contain a valid SAML `` message. To learn more, read [Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 on Oasis](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). + +### Learn More +- [Logout](/logout) +- [Log Users Out of SAML Identity Providers](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps) diff --git a/fr-ca/articles/api/authentication/_multifactor-authentication.md b/fr-ca/articles/api/authentication/_multifactor-authentication.md new file mode 100644 index 0000000000..32c6a59802 --- /dev/null +++ b/fr-ca/articles/api/authentication/_multifactor-authentication.md @@ -0,0 +1,662 @@ +# Multi-factor Authentication + +The Multi-factor Authentication (MFA) API endpoints allow you to enforce MFA when users interact with [the Token endpoints](#get-token), as well as enroll and manage user authenticators. + +First, request a challenge based on the challenge types supported by the application and user. If you know that one-time password (OTP) is supported, you can skip the challenge request. + +Next, verify the multi-factor authentication using the `/oauth/token` endpoint and the specified challenge type: a one-time password (OTP), a recovery code, or an out-of-band (OOB) challenge. + +To learn more, read: + +- [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password) +- [Multi-factor Authentication API](/mfa/concepts/mfa-api) +- [Multi-factor Authentication in Auth0](/mfa) + +## Challenge Request + +```http +POST https://${account.namespace}/mfa/challenge +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "client_secret": "YOUR_CLIENT_SECRET", + "mfa_token": "MFA_TOKEN", + "challenge_type": "oob|otp" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/mfa/challenge' \ + --header 'content-type: application/json' \ + --data '{"mfa_token":"MFA_TOKEN", "challenge_type":"oob otp", "client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET"}' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/mfa/challenge', + headers: { 'content-type': 'application/json' }, + body: + { mfa_token: 'MFA_TOKEN', + challenge_type: 'oob otp', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' }, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE FOR OTP: +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "challenge_type":"otp", +} +``` + +> RESPONSE SAMPLE FOR OOB WITHOUT BINDING METHOD: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "challenge_type":"oob", + "oob_code": "abcde...dasg" +} +``` + +> RESPONSE SAMPLE FOR OOB WITH BINDING METHOD: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "challenge_type":"oob", + "binding_method":"prompt", + "oob_code": "abcde...dasg" +} +``` + +Request a challenge for multi-factor authentication (MFA) based on the challenge types supported by the application and user. + +The `challenge_type` is how the user will get the challenge and prove possession. Supported challenge types include: + +- `otp`: for one-time password (OTP) +- `oob`: for SMS/Voice messages or out-of-band (OOB) + +If OTP is supported by the user and you don't want to request a different factor, you can skip the challenge request and [verify the multi-factor authentication with a one-time password](#verify-with-one-time-password-otp-). + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `mfa_token`
Required | The token received from `mfa_required` error. | +| `client_id`
Required | Your application's Client ID. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `challenge_type` | A whitespace-separated list of the challenges types accepted by your application. Accepted challenge types are `oob` or `otp`. Excluding this parameter means that your client application accepts all supported challenge types. | +| `authenticator_id` | The ID of the authenticator to challenge. You can get the ID by querying the list of available authenticators for the user as explained on [List authenticators](#list-authenticators) below. | + +### Remarks + +- This endpoint does not support enrollment; the user must be enrolled with the preferred method before requesting a challenge. +- Auth0 chooses the challenge type based on the application's supported types and types the user is enrolled with. +- An `unsupported_challenge_type` error is returned if your application does not support any of the challenge types the user has enrolled with. +- An `unsupported_challenge_type` error is returned if the user is not enrolled. +- If the user is not enrolled, you will get a `association_required` error, indicating the user needs to enroll to use MFA. Read [Add an authenticator](#add-an-authenticator) below on how to proceed. + +### Learn More + +* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) +* [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage) + +## Verify with One-Time Password (OTP) + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-otp&otp=OTP_CODE +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'mfa_token=MFA_TOKEN&otp=OTP_CODE&grant_type=http://auth0.com/oauth/grant-type/mfa-otp&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: 'MFA_TOKEN', + otp: 'OTP_CODE', + grant_type: 'http://auth0.com/oauth/grant-type/mfa-otp', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE FOR OTP: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#multifactor-authentication" +}) %> + +Verifies multi-factor authentication (MFA) using a one-time password (OTP). + +To verify MFA with an OTP, prompt the user to get the OTP code, then make a request to the `/oauth/token` endpoint. The request must have the OTP code, the `mfa_token` you received (from the `mfa_required` error), and the `grant_type` set to `http://auth0.com/oauth/grant-type/mfa-otp`. + +The response is the same as responses for `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types. + +### Request parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For OTP MFA use `http://auth0.com/oauth/grant-type/mfa-otp`. | +| `client_id` | Your application's Client ID. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method. | +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `mfa_token`
Required | The `mfa_token` you received from `mfa_required` error. | +| `otp`
Required | OTP Code provided by the user. | + +### Learn More + +- [Associate OTP Authenticators](/mfa/guides/mfa-api/otp) + +## Verify with Out-of-Band (OOB) + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-oob&oob_code=OOB_CODE&binding_code=BINDING_CODE +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http://auth0.com/oauth/grant-type/mfa-oob&oob_code=OOB_CODE&binding_code=BINDING_CODE' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: 'MFA_TOKEN', + oob_code: "OOB_CODE", + binding_code: "BINDING_CODE" + grant_type: 'http://auth0.com/oauth/grant-type/mfa-oob', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE FOR PENDING CHALLENGE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "error":"authorization_pending", + "error_description":"Authorization pending: please repeat the request in a few seconds." +} +``` + +> RESPONSE SAMPLE FOR VERIFIED CHALLENGE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +> RESPONSE SAMPLE FOR REJECTED CHALLENGE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "error":"invalid_grant", + "error_description":"MFA Authorization rejected." +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#multifactor-authentication" +}) %> + +Verifies multi-factor authentication (MFA) using an out-of-band (OOB) challenge (either Push notification, SMS, or Voice). + +To verify MFA using an OOB challenge, your application must make a request to `/oauth/token` with `grant_type=http://auth0.com/oauth/grant-type/mfa-oob`. Include the `oob_code` you received from the challenge response, as well as the `mfa_token` you received as part of `mfa_required` error. + +The response to this request depends on the status of the underlying challenge verification: +- If the challenge has been accepted and verified, it will be the same as `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types. +- If the challenge has been rejected, you will get an `invalid_grant` error, meaning that the challenge was rejected by the user. At this point you should stop polling, as this response is final. +- If the challenge verification is still pending (meaning it has not been accepted nor rejected), you will get an `authorization_pending` error, meaning that you must retry the same request a few seconds later. If you request too frequently, you will get a `slow_down` error. + +When the challenge response includes a `binding_method: prompt`, your app needs to prompt the user for the `binding_code` and send it as part of the request. The `binding_code` is usually a 6-digit number (similar to an OTP) included as part of the challenge. No `binding_code` is necessary if the challenge response did not include a `binding_method`. In this scenario, the response will be immediate; you will receive an `invalid_grant` or an `access_token` as response. + +### Request parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For OTP MFA, use `http://auth0.com/oauth/grant-type/mfa-oob`. | +| `client_id`
Required | Your application's Client ID. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `mfa_token`
Required | The `mfa_token` you received from `mfa_required` error. | +| `oob_code`
Required | The oob code received from the challenge request. | +| `binding_code`| A code used to bind the side channel (used to deliver the challenge) with the main channel you are using to authenticate. This is usually an OTP-like code delivered as part of the challenge message. | + +### Learn More + +- [Associate Out-of-Band Authenticators](/mfa/guides/mfa-api/oob) + +## Verify with Recovery Code + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-recovery-code&recovery_code=RECOVERY_CODE +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http://auth0.com/oauth/grant-type/mfa-recovery-code&recovery_code=RECOVERY_CODE' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: 'MFA_TOKEN', + recovery_code: 'RECOVERY_CODE', + grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE FOR OTP: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400, + "recovery_code": "abcdefg" +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#multifactor-authentication" +}) %> + +Verifies multi-factor authentication (MFA) using a recovery code. + +Some multi-factor authentication (MFA) providers (such as Guardian) support using a recovery code to login. Use this method to authenticate when the user's enrolled device is unavailable, or the user cannot receive the challenge or accept it due to connectivity issues. + +To verify MFA using a recovery code your app must prompt the user for the recovery code, and then make a request to `oauth/token` with `grant_type=http://auth0.com/oauth/grant-type/mfa-recovery-code`. Include the collected recovery code and the `mfa_token` from the `mfa_required` error. If the recovery code is accepted, the response will be the same as for `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types. It might also include a `recovery_code` field, which the application must display to the end-user to be stored securely for future use. + +### Request parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For recovery code use `http://auth0.com/oauth/grant-type/mfa-recovery-code`. | +| `client_id`
Required | Your application's Client ID. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `mfa_token`
Required | The `mfa_token` you received from `mfa_required` error. | +| `recovery_code`
Required | Recovery code provided by the end-user. + +## Add an Authenticator + +```http +POST https://${account.namespace}/mfa/associate +Content-Type: application/json +Authorization: Bearer ACCESS_TOKEN or MFA_TOKEN +{ + "client_id": "${account.clientId}", + "client_secret": "YOUR_CLIENT_SECRET", + "authenticator_types": ["oob"], + "oob_channels": "sms", + "phone_number": "+1 555 123456" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/mfa/associate' \ + --header 'authorization: Bearer ACCESS_TOKEN or MFA_TOKEN' \ + --header 'content-type: application/json' \ + --data '{"client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET", "authenticator_types":["oob"], "oob_channels":"sms", "phone_number": "+1 555 123456"}' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/mfa/associate', + headers: { + 'authorization': 'Bearer TOKEN', + 'content-type': 'application/json' + }, + body: + { client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET', + authenticator_types: ["oob"], + oob_channels: "sms", + phone_number: "+1 555 123456" }, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE FOR OOB (SMS channel): + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "oob_code": "Fe26.2**da6....", + "binding_method":"prompt", + "authenticator_type":"oob", + "oob_channels":"sms", + "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"], +} +``` + +> RESPONSE SAMPLE FOR OOB (Auth0 channel): + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "oob_code": "Fe26.2**da6....", + "barcode_uri":"otpauth://...", + "authenticator_type":"oob", + "oob_channels":"auth0", + "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"], +} +``` + +> RESPONSE SAMPLE FOR OTP: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "secret": "ABCDEFGMK5CE6WTZKRTTQRKUJVFXOVRF", + "barcode_uri":"otpauth://...", + "authenticator_type":"otp", + "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"], +} +``` +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/mfa/associate", + "link": "#multifactor-authentication" +}) %> + +Associates or adds a new authenticator for multi-factor authentication (MFA). + +If the user has active authenticators, an Access Token with the `enroll` scope and the `audience` set to `https://${account.namespace}/mfa/` is required to use this endpoint. + +If the user has no active authenticators, you can use the `mfa_token` from the `mfa_required` error in place of an Access Token for this request. + +After an authenticator is added, it must be verified. To verify the authenticator, use the response values from the `/mfa/associate` request in place of the values returned from the `/mfa/challenge` endpoint and continue with the verification flow. + +A `recovery_codes` field is included in the response the first time an authenticator is added. You can use `recovery_codes` to pass multi-factor authentication as shown on [Verify with recovery code](#verify-with-recovery-code) above. + +To access this endpoint, you must set an Access Token at the Authorization header, with the following claims: +- `scope`: `enroll` +- `audience`: `https://${account.namespace}/mfa/` + +### Request parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Your application's Client ID. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field in your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `authenticator_types`
Required | The type of authenticators supported by the client. Value is an array with values `"otp"` or `"oob"`. | +| `oob_channels` | The type of OOB channels supported by the client. An array with values `"auth0"`, `"sms"`, `"voice"`. Required if `authenticator_types` include `oob`. | +| `phone_number` | The phone number to use for SMS or Voice. Required if `oob_channels` includes `sms` or `voice`. | + +### Learn More + +- [Multi-factor Authentication API](/mfa/concepts/mfa-api) + +## List Authenticators + +```http +GET https://${account.namespace}/mfa/authenticators +Content-Type: application/json +Authorization: Bearer ACCESS_TOKEN +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/mfa/authenticators' \ + --header 'authorization: Bearer ACCESS_TOKEN' \ + --header 'content-type: application/json' +``` + +```javascript +var request = require("request"); + +var options = { method: 'GET', + url: 'https://${account.namespace}/mfa/authenticators', + headers: { + 'authorization': 'Bearer ACCESS_TOKEN', + 'content-type': 'application/json' + }, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +[ + { + "id":"recovery-code|dev_DsvzGfZw2Fg5N3rI", + "authenticator_type":"recovery-code", + "active":true + }, + { + "id":"sms|dev_gB342kcL2K22S4yB", + "authenticator_type":"oob", + "oob_channels":"sms", + "name":"+X XXXX1234", + "active":true + }, + { + "id":"sms|dev_gB342kcL2K22S4yB", + "authenticator_type":"oob", + "oob_channels":"sms", + "name":"+X XXXX1234", + "active":false + }, + { + "id":"push|dev_433sJ7Mcwj9P794y", + "authenticator_type":"oob", + "oob_channels":"auth0", + "name":"John's Device", + "active":true + }, + { + "id":"totp|dev_LJaKaN5O3tjRFOw2", + "authenticator_type":"otp", + "active":true + } +] +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/mfa/authenticators", + "link": "#multifactor-authentication" +}) %> + +Returns a list of authenticators associated with your application. + +To access this endpoint you must set an Access Token at the Authorization header, with the following claims: +- `scope`: `read:authenticators` +- `audience`: `https://${account.namespace}/mfa/` + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `ACCESS_TOKEN`
Required | The Access Token obtained during login. | + + +#### Learn More + +- [Manage Authenticators](/mfa/guides/mfa-api/manage) + +## Delete an Authenticator + +```http +DELETE https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID +Authorization: Bearer ACCESS_TOKEN +``` + +```shell +curl --request DELETE \ + --url 'https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID' \ + --header 'authorization: Bearer ACCESS_TOKEN' \ +``` + +```javascript +var request = require("request"); + +var options = { method: 'DELETE', + url: 'https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID', + headers: { + 'authorization': 'Bearer ACCESS_TOKEN', + 'content-type': 'application/json' + }, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 204 OK +``` +<%= include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "DELETE", + "path": "/mfa/authenticators", + "link": "#multifactor-authentication" +}) %> + +Deletes an associated authenticator using its ID. + +You can get authenticator IDs by [listing the authenticators](#list-authenticators). + +To access this endpoint, you must set an Access Token at the Authorization header, with the following claims: +- `scope`: `remove:authenticators` +- `audience`: `https://${account.namespace}/mfa/` + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `ACCESS_TOKEN`
Required | The Access Token obtained during login. | +| `AUTHENTICATOR_ID`
Required | The ID of the authenticator to delete. + +### Learn More + +- [Manage Authenticators](/mfa/guides/mfa-api/manage) diff --git a/fr-ca/articles/api/authentication/_passwordless.md b/fr-ca/articles/api/authentication/_passwordless.md new file mode 100644 index 0000000000..4cb6994684 --- /dev/null +++ b/fr-ca/articles/api/authentication/_passwordless.md @@ -0,0 +1,256 @@ + + +# Passwordless + +Passwordless connections do not require the user to remember a password. Instead, another mechanism is used to prove identity, such as a one-time code sent through email or SMS, every time the user logs in. + +## Get Code or Link + +```http +POST https://${account.namespace}/passwordless/start +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "client_secret": "YOUR_CLIENT_SECRET", // for web applications + "connection": "email|sms", + "email": "USER_EMAIL", //set for connection=email + "phone_number": "USER_PHONE_NUMBER", //set for connection=sms + "send": "link|code", //if left null defaults to link + "authParams": { // any authentication parameters that you would like to add + "scope": "openid", + "state": "YOUR_STATE" + } +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/passwordless/start' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "connection":"email|sms", "email":"USER_EMAIL", "phone_number":"USER_PHONE_NUMBER", "send":"link|code", "authParams":{"scope": "openid","state": "YOUR_STATE"}}' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/passwordless/start", + "link": "#get-code-or-link" +}) %> + +You have three options for [passwordless authentication](/connections/passwordless): + +- Send a verification code using email. +- Send a link using email. +- Send a verification code using SMS. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | +| `client_assertion`
| A JWT containing containing a signed assertion with your applications credentials. Required when Private Key JWT is your application authentication method. | +|`client_assertion_type`| Use the value `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | The `client_secret` of your application. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. Specifically required for Regular Web Applications **only**. | +| `connection`
Required | How to send the code/link to the user. Use `email` to send the code/link using email, or `sms` to use SMS. | +| `email` | Set this to the user's email address, when `connection=email`. | +| `phone_number` | Set this to the user's phone number, when `connection=sms`. | +| `send` | Use `link` to send a link or `code` to send a verification code. If null, a link will be sent. | +| `authParams` | Use this to append or override the link parameters (like `scope`, `redirect_uri`, `protocol`, `response_type`), when you send a link using email. | + + +### Remarks + +- If you sent a verification code, using either email or SMS, after you get the code, you have to authenticate the user using the [/passwordless/verify endpoint](#authenticate-user), using `email` or `phone_number` as the `username`, and the verification code as the `password`. +- This endpoint is designed to be called from the client-side, and is subject to [rate limits](/policies/rate-limit-policy/authentication-api-endpoint-rate-limits). +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Error Codes + +For the complete error code reference for this endpoint refer to [Errors > POST /passwordless/start](#post-passwordless-start). + +### Learn More + +- [Passwordless Authentication](/connections/passwordless) +- [Passwordless Best Practices](/connections/passwordless/best-practices) + +## Authenticate User + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/json +{ + "grant_type" : "http://auth0.com/oauth/grant-type/passwordless/otp", + "client_id": "${account.clientId}", + "client_secret": "YOUR_CLIENT_SECRET", // for web applications + "otp": "CODE", + "realm": "email|sms" //email or sms + "username":"USER_EMAIL|USER_PHONE_NUMBER", // depends on which realm you chose + "audience" : "API_IDENTIFIER", // in case you need an access token for a specific API + "scope": "SCOPE", + "redirect_uri": "REDIRECT_URI" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/json' \ + --data '{"grant_type":"http://auth0.com/oauth/grant-type/passwordless/otp", "client_id":"${account.clientId}", "client_secret":"CLIENT_SECRET", "otp":"CODE", "realm":"email|sms", "username":"USER_EMAIL|USER_PHONE_NUMBER", "audience":"API_IDENTIFIER", "scope":"SCOPE", "redirect_uri": "REDIRECT_URI"}' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#authenticate-user" +}) %> + + +Once you have a verification code, use this endpoint to login the user with their phone number/email and verification code. + +### Request Parameters + +| Parameter |Description | +|:-----------------|:------------| +| `grant_type`
Required | It should be `http://auth0.com/oauth/grant-type/passwordless/otp`. | +| `client_id`
Required | The `client_id` of your application. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | The `client_secret` of your application. Required** when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. Specifically required for Regular Web Applications **only**. | +| `username`
Required | The user's phone number if `realm=sms`, or the user's email if `realm=email`. | +| `realm`
Required | Use `sms` or `email` (should be the same as [POST /passwordless/start](#get-code-or-link)) | +| `otp`
Required | The user's verification code. | +| `audience` | API Identifier of the API for which you want to get an Access Token. | +| `scope` | Use `openid` to get an ID Token, or `openid profile email` to also include user profile information in the ID Token. | +| `redirect_uri`
Required | A callback URL that has been registered with your application's **Allowed Callback URLs**. | + +### Error Codes + +For the complete error code reference for this endpoint refer to [Standard Error Responses](#standard-error-responses). + +### Learn More + +- [Passwordless Authentication](/connections/passwordless) + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/passwordless/verify", + "link": "#authenticate-user-legacy" +}) %> + +::: warning +This feature is disabled by default for new tenants as of 8 June 2017. Please see [Application Grant Types](/applications/concepts/application-grant-types) for more information. +::: + +Once you have a verification code, use this endpoint to login the user with their phone number/email and verification code. This is active authentication, so the user must enter the code in your app. + +### Request Parameters + +| Parameter |Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | +| `connection`
Required | Use `sms` or `email` (should be the same as [POST /passwordless/start](#get-code-or-link)) | +| `grant_type`
Required | Use `password` | +| `username`
Required | The user's phone number if `connection=sms`, or the user's email if `connection=email`. | +| `password`
Required | The user's verification code. | +| `scope` | Use `openid` to get an ID Token, or `openid profile email` to include also user profile information in the ID Token. | + +### Remarks + +- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`. +- The `email` scope value requests access to the `email` and `email_verified` Claims. +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + +### Error Codes + +For the complete error code reference for this endpoint refer to [Errors > POST /passwordless/verify](#post-passwordless-verify). + +### Learn More + +- [Passwordless Best Practices](/connections/passwordless/best-practices) + diff --git a/fr-ca/articles/api/authentication/_saml-sso.md b/fr-ca/articles/api/authentication/_saml-sso.md new file mode 100644 index 0000000000..0769a51318 --- /dev/null +++ b/fr-ca/articles/api/authentication/_saml-sso.md @@ -0,0 +1,120 @@ +# SAML + +The SAML protocol is used mostly for third-party SaaS applications, like Salesforce and Box. Auth0 supports Service Provider (SP) and Identity Provider (IDP) initiated Sign On. To learn more, see [SAML](/protocols/saml). + +## Accept Request + +```http +GET https://${account.namespace}/samlp/${account.clientId}? + connection=CONNECTION +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/samlp/${account.clientId}' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data '"connection"="CONNECTION"' +``` + +<% var acceptReqPath = '/samlp/YOUR_CLIENT_ID'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": acceptReqPath, + "link": "#accept-request" +}) %> + +Use this endpoint to accept a SAML request to initiate a login. + +Optionally, you can include a `connection` parameter to log in with a specific provider. If no connection is specified, the [Auth0 Login Page](/authenticate/login/auth0-universal-login) will be shown. + +Optionally, SP-initiated login requests can include an `organization` parameter to authenticate users in the context of an organization. To learn more, see [Organizations](/organizations). + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Client ID of your application. | +| `connection` | Connection to use during login. | +| `organization` | Organization ID, if authenticating in the context of an organization. | + + +### Remarks + +- All the parameters of the SAML response can be modified with [Rules](/rules). +- The SAML request `AssertionConsumerServiceURL` will be used to `POST` back the assertion. It must match one of the application's `callback_URLs`. + +### Learn More +- [SAML](/protocols/saml) + +## Get Metadata + +```http +GET https://${account.namespace}/samlp/metadata/${account.clientId} +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/samlp/metadata/${account.clientId}' +``` + +<% var getMetadataPath = '/samlp/metadata/YOUR_CLIENT_ID'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": getMetadataPath, + "link": "#get-metadata" +}) %> + +This endpoint returns the SAML 2.0 metadata. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | + + +### Learn More +- [SAML](/protocols/saml) + + +## IdP-Initiated Single Sign-On (SSO) Flow + +```http +POST https://${account.namespace}/login/callback?connection=CONNECTION +Content-Type: 'application/x-www-form-urlencoded' + SAMLResponse=SAML_RESPONSE +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/login/callback' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data '"connection":"CONNECTION", "SAMLResponse":"SAML_RESPONSE"' +``` + +<% var idpInitPath = '/login/callback'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": idpInitPath, + "link": "#idp-initiated-sso-flow" +}) %> + +This endpoint accepts an IdP-Initiated Sign On SAMLResponse from a SAML Identity Provider. The connection corresponding to the identity provider is specified in the query string. The user will be redirected to the application that is specified in the SAML Provider IdP-Initiated Sign On section. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `connection`
Required | The name of an identity provider configured to your application. | +| `SAMLResponse`
Required | An IdP-Initiated Sign On SAML Response. | + +### Learn More +- [SAML](/protocols/saml) diff --git a/fr-ca/articles/api/authentication/_sign-up.md b/fr-ca/articles/api/authentication/_sign-up.md new file mode 100644 index 0000000000..46e637c7bd --- /dev/null +++ b/fr-ca/articles/api/authentication/_sign-up.md @@ -0,0 +1,111 @@ +# Signup + + +```http +POST https://${account.namespace}/dbconnections/signup +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "email": "EMAIL", + "password": "PASSWORD", + "connection": "CONNECTION", + "username": "johndoe", + "given_name": "John", + "family_name": "Doe", + "name": "John Doe", + "nickname": "johnny", + "picture": "http://example.org/jdoe.png" + "user_metadata": { plan: 'silver', team_id: 'a111' } +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/dbconnections/signup' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "email":"test.account@signup.com", "password":"PASSWORD", "connection":"CONNECTION", "username": "johndoe", "given_name": "John", "family_name": "Doe", "name": "John Doe", "nickname": "johnny", "picture": "http://example.org/jdoe.png", "user_metadata":{ "plan": "silver", "team_id": "a111" }}' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +> RESPONSE SAMPLE: + +```json +{ + "_id": "58457fe6b27...", + "email_verified": false, + "email": "test.account@signup.com", + "username": "johndoe", + "given_name": "John", + "family_name": "Doe", + "name": "John Doe", + "nickname": "johnny", + "picture": "http://example.org/jdoe.png" +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/dbconnections/signup", + "link": "#signup" +}) %> + +Given a user's credentials and a `connection`, this endpoint creates a new user. + +This endpoint only works for database connections. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id` | The `client_id` of your client. | +| `email`
Required | The user's email address. | +| `password`
Required | The user's desired password. | +| `connection`
Required | The name of the database configured to your client. | +| `username` | The user's username. Only valid if the connection requires a username. | +| `given_name` | The user's given name(s). | +| `family_name` | The user's family name(s). | +| `name` | The user's full name. | +| `nickname` | The user's nickname. | +| `picture` | A URI pointing to the user's picture. | +| `user_metadata` | The [user metadata](/users/concepts/overview-user-metadata) to be associated with the user. If set, the field must be an object containing no more than ten properties. Property names can have a maximum of 100 characters, and property values must be strings of no more than 500 characters. | + + +### Remarks +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + + +### Learn More + +- [Password Strength in Auth0 Database Connections](/connections/database/password-strength) +- [Password Options in Auth0 Database Connections](/connections/database/password-options) +- [Adding Username for Database Connections](/connections/database/require-username) +- [Metadata Overview](/users/concepts/overview-user-metadata) diff --git a/fr-ca/articles/api/authentication/_userinfo.md b/fr-ca/articles/api/authentication/_userinfo.md new file mode 100644 index 0000000000..f21daa73ff --- /dev/null +++ b/fr-ca/articles/api/authentication/_userinfo.md @@ -0,0 +1,106 @@ +# User Profile +## Get User Info + +```http +GET https://${account.namespace}/userinfo +Authorization: 'Bearer {ACCESS_TOKEN}' +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/userinfo' \ + --header 'Authorization: Bearer {ACCESS_TOKEN}' \ + --header 'Content-Type: application/json' +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +> RESPONSE SAMPLE: + +```json +{ + "sub": "248289761001", + "name": "Jane Josephine Doe", + "given_name": "Jane", + "family_name": "Doe", + "middle_name": "Josephine", + "nickname": "JJ", + "preferred_username": "j.doe", + "profile": "http://exampleco.com/janedoe", + "picture": "http://exampleco.com/janedoe/me.jpg", + "website": "http://exampleco.com", + "email": "janedoe@exampleco.com", + "email_verified": true, + "gender": "female", + "birthdate": "1972-03-31", + "zoneinfo": "America/Los_Angeles", + "locale": "en-US", + "phone_number": "+1 (111) 222-3434", + "phone_number_verified": false, + "address": { + "country": "us" + }, + "updated_at": "1556845729" +} +``` + +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/userinfo", + "link": "#get-user-info" +}) %> + +Given the Auth0 Access Token obtained during login, this endpoint returns a user's profile. + +This endpoint will work only if `openid` was granted as a scope for the Access Token. The user profile information included in the response depends on the scopes requested. For example, a scope of just `openid` may return less information than a scope of `openid profile email`. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `access_token`
Required | The Auth0 Access Token obtained during login. | + + +### Remarks + +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). +- The auth0.js `parseHash` method, requires that your tokens are signed with `RS256`, rather than `HS256`. +- To return `user_metadata` or other custom information from this endpoint, add a custom claim to the ID token with an [Action](/secure/tokens/json-web-tokens/create-custom-claims#create-custom-claims). For more information refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims). +- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits: + - `X-RateLimit-Limit`: Number of requests allowed per minute. + - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time. + - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time). +- The `Email` claim returns a snapshot of the email at the time of login +- Standard claims (other than `email`) return the latest value (unless the value comes from an external IdP) +- Custom claims always returns the latest value of the claim +- To access the most up-to-date values for the `email` or custom claims, you must get new tokens. You can log in using silent authentication (where the `prompt` parameter for your call to the [`authorize` endpoint](/api/authentication#authorization-code-grant) equals `none`) +- To access the most up-to-date values for standard claims that were changed using an external IdP (for example, the user changed their email address in Facebook)., you must get new tokens. Log in again using the external IdP, but *not* with silent authentication. + +### Learn More + +- [Auth0.js v8 Reference: Extract the authResult and get user info](/libraries/auth0js#extract-the-authresult-and-get-user-info) + +- [Auth0 API Rate Limit Policy](/policies/rate-limits) diff --git a/fr-ca/articles/api/authentication/_wsfed-req.md b/fr-ca/articles/api/authentication/_wsfed-req.md new file mode 100644 index 0000000000..c8e94025b2 --- /dev/null +++ b/fr-ca/articles/api/authentication/_wsfed-req.md @@ -0,0 +1,68 @@ +# WS-Federation +## Accept Request + +```http +GET https://${account.namespace}/wsfed/${account.clientId} +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/wsfed/${account.clientId}' +``` + +<% var acceptWSReqPath = '/wsfed/YOUR_CLIENT_ID'; %> +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": acceptWSReqPath, + "link": "#accept-request20" +}) %> + +This endpoint accepts a WS-Federation request to initiate a login. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client-id` | The `client-id` of your application. | +| `wtrealm` | Can be used in place of `client-id`. | +| `whr` | The name of the connection (used to skip the login page). | +| `wctx` | Your application's state. | +| `wreply` | The callback URL. | + +### Remarks + +- The `wtrealm` parameter must be in one of these formats: + - `urn:clientID` (for example, urn:${account.clientId}) + - If this parameter does not begin with a urn, the `client.clientAliases` array is used for look-up. This can only be set with the [/api/v2/clients](/api/management/v2#!/Clients/get_clients) Management API. +- The `whr` parameter is mapped to the connection like this: `urn:CONNECTION_NAME`. For example, `urn:google-oauth2` indicates login with Google. If there is no `whr` parameter included, the user will be directed to the [Auth0 Login Page](/login_page). + +### Learn More +- [WS-Federation](/protocols/ws-fed) + +## Get Metadata + +```http +GET https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml +``` + +```shell +curl --request GET \ + --url 'https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml' +``` + +<% var getMetadataPath = '/wsfed/FederationMetadata/2007-06/FederationMetadata.xml'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": getMetadataPath, + "link": "#get-metadata21" +}) %> + +This endpoint returns the WS-Federation metadata. + +### Learn More + +- [WS-Federation](/protocols/ws-fed) diff --git a/fr-ca/articles/api/authentication/api-authz/_auth-code-flow.md b/fr-ca/articles/api/authentication/api-authz/_auth-code-flow.md new file mode 100644 index 0000000000..2a3e3d4f27 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_auth-code-flow.md @@ -0,0 +1,120 @@ +# Authorization Code Flow +## Authorize + +```http +GET https://${account.namespace}/authorize? + audience=API_IDENTIFIER& + scope=SCOPE& + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=STATE +``` + +> RESPONSE SAMPLE + +```text +HTTP/1.1 302 Found +Location: ${account.callback}?code=AUTHORIZATION_CODE&state=STATE +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#authorization-code-grant" +}) %> + +This is the OAuth 2.0 grant that regular web apps utilize in order to access an API. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `audience`
| The unique identifier of the target API you want to access. | +| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. | +| `response_type`
Required | Indicates to Auth0 which OAuth 2.0 flow you want to use. Use `code` for Authorization Code Grant Flow. | +| `client_id`
Required | Your application's ID. | +| `state`
Recommended | An opaque value the application adds to the initial request that Auth0 includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. | +| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. | +| `connection` | The name of the connection configured to your application. | +| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). | +| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. | +| `invitation` | Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. | + +## Get Token + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=authorization_code&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&code=AUTHORIZATION_CODE&redirect_uri=${account.callback} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'grant_type=authorization_code&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'authorization_code', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET', + code: 'AUTHORIZATION_CODE', + redirect_uri: '${account.callback}' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#authorization-code" +}) %> + +This is the flow that regular web apps use to access an API. Use this endpoint to exchange an Authorization Code for a token. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For Authorization Code, use `authorization_code`. | +| `client_id`
Required | Your application's Client ID. | +| `client_secret`
Required | Your application's Client Secret. | +| `code`
Required | The Authorization Code received from the initial `/authorize` call. | +| `redirect_uri`| This is required only if it was set at the [GET /authorize](#authorization-code-grant) endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. | + +### Learn More + +- [Authorization Code Flow](/flows/concepts/auth-code) +- [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code) +- [State Parameter](/protocols/oauth2/oauth-state) +- [Silent Authentication](/api-auth/tutorials/silent-authentication) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_auth-code-pkce.md b/fr-ca/articles/api/authentication/api-authz/_auth-code-pkce.md new file mode 100644 index 0000000000..23edc9a190 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_auth-code-pkce.md @@ -0,0 +1,126 @@ +# Authorization Code Flow with PKCE +## Authorize + +```http +GET https://${account.namespace}/authorize? + audience=API_IDENTIFIER& + scope=SCOPE& + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256 +``` + +> RESPONSE SAMPLE + +```text +HTTP/1.1 302 Found +Location: ${account.callback}?code=AUTHORIZATION_CODE +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#authorization-code-grant-pkce-" +}) %> + +This is the OAuth 2.0 grant that mobile apps utilize in order to access an API. Before starting with this flow, you need to generate and store a `code_verifier`, and using that, generate a `code_challenge` that will be sent in the authorization request. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `audience`
| The unique identifier of the target API you want to access. | +| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. | +| `response_type`
Required | Indicates to Auth0 which OAuth 2.0 Flow you want to perform. Use `code` for Authorization Code Grant (PKCE) Flow. | +| `client_id`
Required | Your application's Client ID. | +| `state`
Recommended | An opaque value the client adds to the initial request that Auth0 includes when redirecting back to the client. This value must be used by the client to prevent CSRF attacks. | +| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. | +| `code_challenge_method`
Required | Method used to generate the challenge. The PKCE spec defines two methods, `S256` and `plain`, however, Auth0 supports only `S256` since the latter is discouraged. | +| `code_challenge`
Required | Generated challenge from the `code_verifier`. | +| `connection` | The name of the connection configured to your application. | +| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). | +| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. | +| `invitation` | Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. | + +## Get Token +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=authorization_code&client_id=${account.clientId}&code_verifier=CODE_VERIFIER&code=AUTHORIZATION_CODE&redirect_uri=${account.callback} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'grant_type=authorization_code&client_id=${account.clientId}&code_verifier=CODE_VERIFIER&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: { + grant_type:"authorization_code", + client_id: "${account.clientId}", + code_verifier: "CODE_VERIFIER", + code: "AUTHORIZATION_CODE", + redirect_uri: "${account.callback}", } }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#authorization-code-pkce-" +}) %> + +This is the flow that mobile apps use to access an API. Use this endpoint to exchange an Authorization Code for a token. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For Authorization Code (PKCE) use `authorization_code`. | +| `client_id`
Required | Your application's Client ID. | +| `code`
Required | The Authorization Code received from the initial `/authorize` call. | +| `code_verifier`
Required | Cryptographically random key that was used to generate the `code_challenge` passed to `/authorize`. | +| `redirect_uri` | This is required only if it was set at the [GET /authorize](#authorization-code-grant-pkce-) endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. | + +### Remarks + +- In order to improve compatibility for applications, Auth0 will now return profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID tokens or access tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. +- Include `offline_access` to the `scope` request parameter to get a refresh token from [POST /oauth/token](#authorization-code-pkce-). Make sure that the **Allow Offline Access** field is enabled in the [API Settings](${manage_url}/#/apis). +- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications). +- Silent authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. When an Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's Single Sign-on (SSO) session has not expired. + +### Learn More +- [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) +- [Call API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce) +- [Silent Authentication](/api-auth/tutorials/silent-authentication) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_authz-client.md b/fr-ca/articles/api/authentication/api-authz/_authz-client.md new file mode 100644 index 0000000000..4979eff892 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_authz-client.md @@ -0,0 +1,25 @@ +# Authorize Application + +To begin an OAuth 2.0 Authorization flow, your application should first send the user to the authorization URL. + +## Authorize endpoint +The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) and do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given. If you alter the value in `scope`, Auth0 will require consent to be given again. + +The OAuth 2.0 flows that require user authorization are: +- [Authorization Code Flow](/flows/concepts/auth-code) +- [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) +- [Implicit Flow](/flows/concepts/implicit) + +The [Resource Owner Password Grant](/api-auth/grant/password) and [Client Credentials Flow](/flows/concepts/client-credentials) do not use this endpoint since there is no user authorization involved. Instead, they directly invoke the `POST /oauth/token` endpoint to retrieve an Access Token. + +Based on the OAuth 2.0 flow you are implementing, the parameters slightly change. To determine which flow is best suited for your case, refer to: [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use). + +## Get Token +For token-based authentication, use the `oauth/token` endpoint to get an access token for your application to make authenticated calls to a secure API. Optionally, you can also retrieve an ID Token and a Refresh Token. ID Tokens contains user information in the form of scopes you application can extract to provide a better user experience. Refresh Tokens allow your application to request a new access token once the current token expires without interruping the user experience. To learn more, read [ID Tokens](https://auth0.com/docs/secure/tokens/id-tokens) and [Refresh Tokens](https://auth0.com/docs/secure/tokens/refresh-tokens). + +Note that the only OAuth 2.0 flows that can retrieve a Refresh Token are: +- [Authorization Code Flow (Authorization Code)](/flows/concepts/auth-code) +- [Authorization Code Flow with PKCE (Authorization Code with PKCE)](/flows/concepts/auth-code-pkce) +- [Resource Owner Password](/api-auth/grant/password) +- [Device Authorization Flow](/flows/concepts/device-auth) +- Token Exchange\* \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_client-credential.md b/fr-ca/articles/api/authentication/api-authz/_client-credential.md new file mode 100644 index 0000000000..99de17f1d3 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_client-credential.md @@ -0,0 +1,73 @@ +# Client Credential Flow +## Get Token + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +audience=API_IDENTIFIER&grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'audience=API_IDENTIFIER&grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET', + audience: 'API_IDENTIFIER', + grant_type: 'client_credentials' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#client-credentials" +}) %> + +This is the OAuth 2.0 grant that server processes use to access an API. Use this endpoint to directly request an access token by using the application's credentials (a Client ID and a Client Secret). + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For Client Credentials use `client_credentials`. | +| `client_id`
Required | Your application's Client ID. | +| `client_secret`
Required | Your application's Client Secret. | +| `audience`
Required | The unique identifier of the target API you want to access. | + +### Learn More + +- [Client Credentials Flow](/flows/concepts/client-credentials) +- [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials) +- [Setting up a Client Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard) +- [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_device-code.md b/fr-ca/articles/api/authentication/api-authz/_device-code.md new file mode 100644 index 0000000000..11a26b9470 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_device-code.md @@ -0,0 +1,186 @@ +# Device Authorization Flow +## Authorize + +```http +POST https://${account.namespace}/oauth/device/code +Content-Type: application/x-www-form-urlencoded + +client_id=${account.clientId}&scope=SCOPE&audience=API_IDENTIFIER +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/device/code' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'client_id=${account.clientId}&scope=SCOPE&audience=API_IDENTIFIER' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/device/code', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { client_id: '${account.clientId}', + scope: 'SCOPE', + audience: 'API_IDENTIFIER' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "device_code":"GmRh...k9eS", + "user_code":"WDJB-MJHT", + "verification_uri":"https://${account.namespace}/device", + "verification_uri_complete":"https://${account.namespace}/device?user_code=WDJB-MJHT", + "expires_in":900, //in seconds + "interval":5 +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/device/code", + "link": "#device-code" +}) %> + +This is the flow that input-constrained devices use to access an API. Use this endpoint to get a device code. To begin the [Device Authorization Flow](/flows/concepts/device-auth), your application should first request a device code. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `audience`
| The unique identifier of the target API you want to access. | +| `scope` | The scopes for which you want to request authorization. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. | +| `client_id`
Required | Your application's ID. | + +### Response Values + +| Value | Description | +|:-----------------------------|:------------| +| `device_code` | The unique code for the device. When the user visits the `verification_uri` in their browser-based device, this code will be bound to their session. | +| `user_code` | The code that the user should input at the `verification_uri` to authorize the device. | +| `verification_uri` | The URL the user should visit to authorize the device. | +| `verification_uri_complete` | The complete URL the user should visit to authorize the device. Your app can use this value to embed the `user_code` in the URL, if you so choose. | +| `expires_in` | The lifetime (in seconds) of the `device_code` and `user_code`. | +| `interval` | The interval (in seconds) at which the app should poll the token URL to request a token. | + +### Remarks + +- Include `offline_access` to the `scope` request parameter to get a Refresh Token from [POST /oauth/token](#device-auth). Make sure that the **Allow Offline Access** field is enabled in the [API Settings](${manage_url}/#/apis). + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +client_id=${account.clientId}&device_code=YOUR_DEVICE_CODE&grant_type=urn:ietf:params:oauth:grant-type:device_code +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'client_id=${account.clientId}&device_code=YOUR_DEVICE_CODE&grant_type=urn:ietf:params:oauth:grant-type:device_code' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { client_id: '${account.clientId}', + device_code: 'YOUR_DEVICE_CODE', + grant_type: 'urn:ietf:params:oauth:grant-type:device_code' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token": "eyJz93a...k4laUWw", + "id_token": "eyJ...0NE", + "refresh_token": "eyJ...MoQ", + "scope": "...", + "expires_in": 86400, + "token_type": "Bearer" +} +``` + +```JSON +HTTP/1.1 403 Forbidden +Content-Type: application/json + { + // Can be retried + "error": "authorization_pending", + "error_description": "User has yet to authorize device code." + } +``` + +```JSON +HTTP/1.1 429 Too Many Requests +Content-Type: application/json + { + // Can be retried + "error": "slow_down", + "error_description": "You are polling faster than the specified interval of 5 seconds." + } +``` + +```JSON +HTTP/1.1 403 Forbidden +Content-Type: application/json + { + // Cannot be retried; transaction failed + "error": "access_denied|invalid_grant|...", + "error_description": "Failure: User cancelled the confirmation prompt or consent page; the code expired; there was an error." + } +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#device-auth" +}) %> + +This is the OAuth 2.0 grant that input-constrained devices use to access an API. Poll this endpoint using the interval returned with your [device code](/api/authentication#get-device-code) to directly request an access token using the application's credentials (a Client ID) and a device code. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For Device Authorization, use `urn:ietf:params:oauth:grant-type:device_code`. | +| `client_id`
Required | Your application's Client ID. | +| `device_code`
Required | The device code previously returned from the [/oauth/device/code endpoint](/api/authentication#device-authorization-flow). | + +### Remarks +- Because you will be polling this endpoint (using the `interval` from the initial response to determine frequency) while waiting for the user to go to the verification URL and enter their user code, you will likely receive at least one failure before receiving a successful response. See sample responses for possible responses. + +### Learn More + +- [Device Authorization Flow](/flows/concepts/device-auth) +- [Call API using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth) +- [Setting up a Device Code Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_highly-regulated.md b/fr-ca/articles/api/authentication/api-authz/_highly-regulated.md new file mode 100644 index 0000000000..0181295d99 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_highly-regulated.md @@ -0,0 +1,233 @@ + +# Authorization Code Flow with Enhanced Privacy Protection + +## Push Authorization Requests (PAR) + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/par", + "link": "##push-authorization-requests-par-" +}) %> + +```http +POST ${account.namespace}/oauth/par +Content-Type: 'application/x-www-form-urlencoded' + audience={https://yourApi/}& + response_type=code|code id_token& + client_id={yourClientId}& + redirect_uri={https://yourApp/callback}& + state=STATE& + scope=openid|profile|email& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + nonce=NONCE& + connection=CONNECTION& + prompt=login|consent|none& + organisation=ORGANIZATION +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://{yourDomain}/oauth/par, + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: { + audience: '{https://yourApi/}', + response_type: 'code|code id_token', + client_id: '{yourClientId}', + redirect_uri: '{https://yourApp/callback}', + state: 'STATE', + scope: 'openid|profile|email', + authorization_details: JSON.stringify([{ type: 'my_type' }]), + code_challenge: 'CODE_CHALLENGE', + code_challenge_method: 'S256', + nonce: 'NONCE', + connection: 'CONNECTION', + prompt: 'login|consent|none' + organisation: 'ORGANIZATION' + } +}; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); + +``` + +```shell +curl --request POST \ + --url 'https://{yourDomain}/oauth/par' \ + --header 'content-type: application/x-www-form-urlencoded' \ +--data 'audience={https://yourApi/}response_type=code|code id_token&client_id={yourClientId}&redirect_uri={https://yourApp/callback}&state=STATE&scope=openid|profile|email&authorization_details='[{"type":"my_type"}]' +&code_challenge=CODE_CHALLENGE&code_challenge_method=S256&nonce=NONCE&connection=CONNECTION&prompt=login|consent|none&organisation=ORGANIZATION' + +``` + +> RESPONSE SAMPLE: + +``` json +/** +If the request is successful, `/oauth/par` responds with a `JSON` object containing the `request_uri` property, which can be used at the authorization endpoint, and the `expires_in` value, which indicates the number of seconds the `request_uri` is valid. +*/ + +HTTP/1.1 201 Created +Content-Type: application/json + +{ + "request_uri": + "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c", + "expires_in": 30 +} +``` + +::: note +To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to [Auth0 Pricing](https://auth0.com/pricing) for details. +::: + +Authorization Code Flow with [Pushed Authorization Requests (PAR)](/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par) uses the `/oauth/par` endpoint to allow applications to send the authorization parameters usually sent in a `GET` request to `/authorize`. PAR uses a POST method from the backend to keep parameter values secure. The `/oauth/par` endpoint accepts all authorization parameters which can be proivided to `/authorize`. Assuming the call to the `/oauth/par` endpoint is valid, Auth0 will respond with a `redirect_uri` value that can be used as a parameter for the `/authorize` endpoint. + +Assuming the call to the `/oauth/par` endpoint is valid, Auth0 will respond with a `redirect_uri` value also used as a parameter for the `/authorize` endpoint. To learn more about configuring PAR, read [Configure Pushed Authorization Requests (PAR)](/get-started/applications/configure-par). + +### Request Parameters +| Parameter | Description | +|:-----------------|:------------| +|`authorization_details`| Requested permissions for each resource. Similar to scopes. To learn more, read [RAR reference documention](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar). | +|`audience`| The unique identifier of the target API you want to access. | +| `response_type`
Required | Specifies the token type. We recommend you use `code` to request an authorization code, or code `id_token` to receive an authorization code and a [detached signature](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature). | +| `client_id`
Required | The `client_id` of your application. | +| `redirect_uri`
Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).| +| `state`
Recommended | An opaque value the application adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. | +| `scope`
Recommended| OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a refresh token.| +| `code_challenge`
Recommended | OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a refresh token. | +| `code_challenge_method`
Recommended | Method used to generate the challenge. The PKCE specification defines two methods, `S256` and plain, however, Auth0 supports only S256 since the latter is discouraged. [Authorization Code Flow with Proof Key for Code Exchange (PKCE)] (/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).| +| `nonce`
Recommended | A string value which will be included in the ID token response from Auth0, used to prevent token replay attacks. It is required for `response_type=id_token` token. | +| `connection` | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. | +| `prompt` | Can be used to force a particular prompt to display, e.g. `prompt=consent` will always display the consent prompt.| +| `organization` | ID of the organization to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. | + +### Remarks +- To make a call to the PAR endpoint, you must: + - Set the request content type as `application/x-www-form-urlencoded` + - Use `strings` for all passed parameters + - Include an additional parameter for application authentication in the request (e.g. `client_secret`, or `client_assertion` and `client_assertion_type` for JSON Web Token Client Authentication, or pass a `client-certificate` and `client-certificate-ca-verified` header when using Mutual TLS). +- Use the `authorization_details` parameter to request permission for each resource. For example, you can specify an array of JSON objects to convey fine-grained information on the authorization. Each JSON object must contain a `type` attribute. The rest is up to you to define. + +## Authorize + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#redirect-from-par-to-authorize" +}) %> + +```http +GET https://{yourDomain}/authorize + request_uri={yourRequestUri}& + client_id={yourClientId} +``` + +After calling the `/oauth/par` endpoint, redirect the end user to the `/authorize` endpoint using a `GET` call. + +:::note +The `/authorize` endpoint will respond based on the parameters passed to the `/oauth/par` endpoint. If you request a `response_type`, you should receive an authorization code to use at the `/oauth/token` endpoint. +::: + +### Request Parameters +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | +| `request_uri`
Required | The `request_uri` value that was received from the `/oauth/par` endpoint. | + +## Exchange an Authorization Code for a Token + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/token", + "link": "#exchange-an-authorization-code-for-a-token" +}) %> + +```http +POST https://{yourDomain}/oauth/par +Content-Type: 'application/x-www-form-urlencoded' + grant_type=code|code id_token& + client_id={yourClientId}& + code=CODE& + redirect_uri={https://yourApp/callback}& + code_verifier=CODE_VERIFIER +``` + +```javascript +curl --request POST \ + --url 'https://{yourDomain}/oauth/par' \ + --header 'content-type: application/x-www-form-urlencoded' \ +--data 'grant_type=authorization_code& client_id={yourClientId}& code=CODE&redirect_uri={https://yourApp/callback}&code_verifier=CODE_VERIFIER' +``` + +```shell +var request = require("request"); + +var options = { method: 'POST', + url: 'https://{yourDomain}/oauth/token, + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: { + grant_type: 'authorization_code', + client_id: '{yourClientId}', + code: 'CODE', + redirect_uri: '{https://yourApp/callback}', + code_verifier: 'CODE_VERIFIER' + } +}; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: +``` json +/** +The `/oauth/token` endpoint will respond with a JSON object containing an `id_token` property, and potentially also a `refresh_token` if one was requested. +*/ +HTTP/1.1 200 OK +Content-Type: application/json +{ + "refresh_token":"GEbRxBN...edjnXbL", + "access_token":"eybRxBN...edjnXZQ", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400, + "authrorization_details":[ + { + "type":"my_type", + "other_attributes_of_my_type":"value"} + ] +}, + + +``` + +When users are redirected back to your callback, you need to make a `POST` call to the `oauth/token` endpoint to exchange an authorization code for an access and/or an ID token. + +### Request Parameters +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow. Assuming you have an authorization code from the `/authorize` endpoint, use `authorization_code`. | +| `code` | The authorization code from the initial `/authorize` call. | +| `client_id`
Required | The `client_id` of your application. | +| `request_uri`
Required | This is required only if it was set at the `GET` `/oauth/par` endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. | +| `code_verifier`
Recommended | Cryptographically random key used to generate the `code_challenge` passed to `/oauth/par`. If the `code_challenge` parameter is passed in the call to `/oauth/par`, this is required. | + +### Remarks + +To make a call to `/oauth/token` endpoint, you must: +- Set the request content type as `application/x-www-form-urlencoded` +- Use `strings` for all passed parameters +- Include an additional parameter for application authentication in the request (e.g. `client_secret`, or `client_assertion` and `client_assertion_type` for JSON Web Token Client Authentication, or pass a `client-certificate` and `client-certificate-ca-verified` header when using Mutual TLS). \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_implicit.md b/fr-ca/articles/api/authentication/api-authz/_implicit.md new file mode 100644 index 0000000000..a6bf10fdb7 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_implicit.md @@ -0,0 +1,60 @@ +# Implicit Flow +## Authorize + +```http +GET https://${account.namespace}/authorize? + audience=API_IDENTIFIER& + scope=SCOPE& + response_type=token|id_token|id_token token& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=STATE& + nonce=NONCE +``` + +> RESPONSE SAMPLE + +```text +HTTP/1.1 302 Found +Location: ${account.callback}#access_token=TOKEN&state=STATE&token_type=TYPE&expires_in=SECONDS +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#implicit-grant" +}) %> + +This is the OAuth 2.0 grant that web apps utilize in order to access an API. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `audience`
| The unique identifier of the target API you want to access. | +| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`. Custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). | +| `response_type`
Required | This will specify the type of token you will receive at the end of the flow. Use `token` to get only an Access Token, `id_token` to get only an ID token (if you don't plan on accessing an API), or `id_token token` to get both an ID token and an Access Token. | +| `client_id`
Required | Your application's ID. | +| `state`
Recommended | An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. | +| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. | +| `nonce`
Recommended | A string value which will be included in the ID token response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. | +| `connection` | The name of the connection configured for your application. | +| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). | +| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. | +| `invitation` | Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. | + +### Remarks + +- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications). +- If `response_type=token`, after the user authenticates with the provider, this will redirect them to your application callback URL while passing the `access_token` in the address `location.hash`. This is used for Single-Page Apps and on Native Mobile SDKs. +- The Implicit Grant does not support the issuance of Refresh Tokens. Use [Silent Authentication](/api-auth/tutorials/silent-authentication) instead. +- In order to improve compatibility for applications, Auth0 will now return profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. +- Silent Authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. When an Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's Single Sign-on (SSO) session has not expired. + +### Learn More + +- [Implicit Flow](/flows/concepts/implicit) +- [State Parameter](/protocols/oauth2/oauth-state) +- [Mitigate replay attacks when using the Implicit Grant](/api-auth/tutorials/nonce) +- [Silent Authentication](/api-auth/tutorials/silent-authentication) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_refresh-token.md b/fr-ca/articles/api/authentication/api-authz/_refresh-token.md new file mode 100644 index 0000000000..ebd8bbdba7 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_refresh-token.md @@ -0,0 +1,72 @@ +# Refresh Token + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=refresh_token&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&refresh_token=YOUR_REFRESH_TOKEN +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'grant_type=refresh_token&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&refresh_token=YOUR_REFRESH_TOKEN' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'refresh_token', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET', + refresh_token: 'YOUR_REFRESH_TOKEN'} + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token": "eyJ...MoQ", + "expires_in": 86400, + "scope": "openid offline_access", + "id_token": "eyJ...0NE", + "token_type": "Bearer" +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#refresh-token" +}) %> + +Use this endpoint to refresh an Access Token using the Refresh Token you got during authorization. + +## Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. To refresh a token, use `refresh_token`. | +| `client_id`
Required | Your application's Client ID. | +| `client_secret` | Your application's Client Secret. Required when the **Token Endpoint Authentication Method** field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `refresh_token`
Required | The refresh token to use. | +| `scope` | A space-delimited list of requested scope permissions. If not sent, the original scopes will be used; otherwise you can request a reduced set of scopes. Note that this must be URL encoded. | + +## Learn More + +- [Refresh Tokens](/tokens/concepts/refresh-tokens) diff --git a/fr-ca/articles/api/authentication/api-authz/_resource-owner.md b/fr-ca/articles/api/authentication/api-authz/_resource-owner.md new file mode 100644 index 0000000000..c8ce53f4ab --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_resource-owner.md @@ -0,0 +1,96 @@ +# Resource Owner Password Flow +## Get Token + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=password&username=USERNAME&password=PASSWORD&audience=API_IDENTIFIER&scope=SCOPE&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'grant_type=password&username=USERNAME&password=PASSWORD&audience=API_IDENTIFIER&scope=SCOPE&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'password', + username: 'USERNAME', + password: 'PASSWORD', + audience: 'API_IDENTIFIER', + scope: 'SCOPE', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#resource-owner-password" +}) %> + +:::warning +This flow should only be used from highly-trusted applications that **cannot do redirects**. If you can use redirect-based flows from your app, we recommend using the [Authorization Code Flow](#regular-web-app-login-flow) instead. +::: + +This is the OAuth 2.0 grant that highly-trusted apps use to access an API. In this flow, the end-user is asked to fill in credentials (username/password), typically using an interactive form in the user-agent (browser). This information is sent to the backend and from there to Auth0. It is therefore imperative that the application is absolutely trusted with this information. For [single-page applications and native/mobile apps](/flows/concepts/auth-code-pkce), we recommend using web flows instead. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `grant_type`
Required | Denotes the flow you are using. For Resource Owner Password use `password`. To add realm support use `http://auth0.com/oauth/grant-type/password-realm`. | +| `client_id`
Required | Your application's Client ID. | +| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. | +| `audience` | The unique identifier of the target API you want to access. | +| `username`
Required | Resource Owner's identifier, such as a username or email address. | +| `password`
Required | Resource Owner's secret. | +| `scope` | String value of the different scopes the application is asking for. Multiple scopes are separated with whitespace. | +| `realm` | String value of the realm the user belongs. Set this if you want to add realm support at this grant. For more information on what realms are refer to [Realm Support](/api-auth/grant/password#realm-support). | + +### Request headers + +| Parameter | Description | +|:-----------------|:------------| +| `auth0-forwarded-for` | End-user IP as a string value. Set this if you want brute-force protection to work in server-side scenarios. For more information on how and when to use this header, refer to [Using resource owner password from server-side](/api-auth/tutorials/using-resource-owner-password-from-server-side). | + +### Remarks + +- The scopes issued to the application may differ from the scopes requested. In this case, a `scope` parameter will be included in the response JSON. +- If you don't request specific scopes, all scopes defined for the audience will be returned due to the implied trust to the application in this grant. You can customize the scopes returned in a rule. For more information, refer to [Calling APIs from Highly Trusted Applications](/api-auth/grant/password). +- To add realm support set the `grant_type` to `http://auth0.com/oauth/grant-type/password-realm`, and the `realm` to the realm the user belongs. This maps to a connection in Auth0. For example, if you have configured a database connection for your internal employees and you have named the connection `employees`, then use this value. For more information on how to implement this refer to: [Realm Support](/api-auth/tutorials/password-grant#realm-support). +- In addition to username and password, Auth0 may also require the end-user to provide an additional factor as proof of identity before issuing the requested scopes. In this case, the request described above will return an `mfa_required` error along with an `mfa_token`. You can use these tokens to request a challenge for the possession factor and validate it accordingly. For details refer to [Resource Owner Password and MFA](#resource-owner-password-and-mfa). + +### Learn More +- [Calling APIs from Highly-Trusted Applications](/api-auth/grant/password) +- [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant) +- [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_revoke-refresh-token.md b/fr-ca/articles/api/authentication/api-authz/_revoke-refresh-token.md new file mode 100644 index 0000000000..5f44c585e2 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_revoke-refresh-token.md @@ -0,0 +1,79 @@ +# Revoke Refresh Token + +```http +POST https://${account.namespace}/oauth/revoke +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "client_secret": "YOUR_CLIENT_SECRET", + "token": "YOUR_REFRESH_TOKEN", +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/revoke' \ + --header 'content-type: application/json' \ + --data '{ "client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET", "token": "YOUR_REFRESH_TOKEN" }' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/revoke', + headers: { 'content-type': 'application/json' }, + body: + { client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET', + token: 'YOUR_REFRESH_TOKEN' }, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +(empty-response-body) +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/revoke", + "link": "#revoke-refresh-token" +}) %> + +Use this endpoint to invalidate a Refresh Token if it has been compromised. + +The behaviour of this endpoint depends on the state of the [Refresh Token Revocation Deletes Grant](https://auth0.com/docs/tokens/refresh-tokens/revoke-refresh-tokens#refresh-tokens-and-grants) toggle. +If this toggle is enabled, then each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant. This means that **all Refresh Tokens that have been issued for the same user, application, and audience will be revoked**. +If this toggle is disabled, then only the refresh token is revoked, while the grant is left intact. + +## Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | +| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is the application authentication method.| +| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. Required when Private Key JWT is the application authentication method.| +| `client_secret` | The `client_secret` of your application. Required when Client Secret Basic or Client Secret Post is the application authentication method. Specifically required for Regular Web Applications **only**. | +| `token`
Required | The Refresh Token you want to revoke. | + +## Remarks + +- For non-confidential applications that cannot keep the Client Secret safe (for example, native apps), the endpoint supports passing no Client Secret but the application itself must have the property `tokenEndpointAuthMethod` set to `none`. You can do this either from the UI ([Dashboard > Applications > Application Settings](${manage_url}/#/applications)) or using the [Management API](/api/management/v2#!/Applications/patch_applications_by_id). + +## Error Codes + +For the complete error code reference for this endpoint, refer to [Errors > POST /oauth/revoke](#post-oauth-revoke). + +## Learn More + +- [Refresh Tokens](/tokens/concepts/refresh-tokens) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/api-authz/_token-exchange-native-social.md b/fr-ca/articles/api/authentication/api-authz/_token-exchange-native-social.md new file mode 100644 index 0000000000..e234380215 --- /dev/null +++ b/fr-ca/articles/api/authentication/api-authz/_token-exchange-native-social.md @@ -0,0 +1,89 @@ +# Token Exchange for Native Social + +```http +POST https://${account.namespace}/oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=SUBJECT_TOKEN&subject_token_type=SUBJECT_TOKEN_TYPE&client_id=${account.clientId}&audience=API_IDENTIFIER&scope=SCOPE +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/token' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=SUBJECT_TOKEN&subject_token_type=SUBJECT_TOKEN_TYPE&client_id=${account.clientId}&audience=API_IDENTIFIER&scope=SCOPE' + }' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange', + subject_token: 'SUBJECT_TOKEN', + subject_token_type: 'SUBJECT_TOKEN_TYPE', + client_id: '${account.clientId}', + audience: 'API_IDENTIFIER', + scope: 'SCOPE', + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token": "eyJz93a...k4laUWw", + "id_token": "eyJ...0NE", + "refresh_token": "eyJ...MoQ", + "expires_in":86400, + "token_type":"Bearer" +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/token", + "link": "#token-exchange-native-social" +}) %> + +:::warning +This flow is intended for use with native social interactions **only**. Use of this flow outside of a native social setting is highly discouraged. +::: + +When a non-browser-based solution (such as a mobile platform's SDK) authenticates the user, the authentication will commonly result in artifacts being returned to application code. In such situations, this grant type allows for the Auth0 platform to accept artifacts from trusted sources and issue tokens in response. In this way, apps making use of non-browser-based authentication mechanisms (as are common in native apps) can still retrieve Auth0 tokens without asking for further user interaction. + +Artifacts returned by this flow (and the contents thereof) will be determined by the `subject_token_type` and the tenant's configuration settings. + +## Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `auth0-forwarded-for` | End user IP as a string value. Set this if you want brute-force protection to work in server-side scenarios. To learn more about how and when to use this header, read [Using resource owner password from server-side](/api-auth/tutorials/using-resource-owner-password-from-server-side). | +| `grant_type`
Required | Denotes the flow you are using. For Token Exchange for Native Social, use `urn:ietf:params:oauth:grant-type:token-exchange`. | +| `subject_token`
Required | Externally-issued identity artifact representing the user. | +| `subject_token_type`
Required | Identifier that indicates the type of `subject_token`. | +| `client_id`
Required | Your application's Client ID. | +| `audience` | The unique identifier of the target API you want to access. | +| `scope` | String value of the different scopes the application is requesting. Multiple scopes are separated with whitespace. | +| `user_profile`
Only For `apple-authz-code` | Optional element used for native iOS interactions for which profile updates can occur. Expected parameter value will be JSON in the form of: `{ name: { firstName: 'John', lastName: 'Smith }}` | + +## Remarks + +- The scopes issued to the application may differ from the requested scopes. In this case, a `scope` parameter will be included in the response JSON. +- If you don't request specific scopes, all scopes defined for the audience will be returned due to the implied trust to the application in this grant. You can customize the scopes returned in a rule. To learn more, read [Calling APIs from Highly Trusted Applications](/api-auth/grant/password). + +## Learn More +- [Add Sign In with Apple to Native iOS Apps](/connections/apple-siwa/add-siwa-to-native-app) +- [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_errors.md b/fr-ca/articles/api/authentication/errors/_errors.md new file mode 100644 index 0000000000..3b9163d8ae --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_errors.md @@ -0,0 +1,21 @@ +# Standard Error Responses + +The Authentication API may return the following HTTP Status Codes: +| Status | JSON Response | +| :---------------- | :------------ | +| 400 Bad Request|`{"error": "invalid_request", "error_description": "..."}`| +| 400 Bad Request| `{"error": "invalid_request", "error_description": "..."}`| +| 400 Bad Request| `{"error": "invalid_scope", "error_description": "Scope must be an array or a string"}`| +| 401 Unauthorized| `{"error": "invalid_client", "error_description": "..."}`| +| 401 Unauthorized| `{"error": "requires_validation", "error_description": "Suspicious request requires verification"}`| +| 403 Forbidden| `{"error": "unauthorized_client", "error_description": "..."}`| +| 403 Forbidden| `{"error": "access_denied", "error_description": "..."}`| +| 403 Forbidden| `{"error": "access_denied", "error_description": "Unknown or invalid refresh token"}`| +| 403 Forbidden| `{"error": "invalid_grant", "error_description": "..."}`| +| 404 Not Found| `{"error": "endpoint_disabled", "error_description": "..."}`| +| 405 Method Not Allowed| `{"error": "method_not_allowed", "error_description": "..."}`| +| 429 Too Many Requests| `{"error": "too_many_requests", "error_description": "..."}`| +| 500 Internal Server Error | | +| 501 Not Implemented| `{"error": "unsupported_response_type", "error_description": "..."}`| +| 501 Not Implemented| `{"error": "unsupported_grant_type", "error_description": "..."}`| +| 503 Service Unavailable| `{"error": "temporarily_unavailable", "error_description": "..."}`| \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_oauth-access_token.md b/fr-ca/articles/api/authentication/errors/_oauth-access_token.md new file mode 100644 index 0000000000..44b0f7541e --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_oauth-access_token.md @@ -0,0 +1,10 @@ +# POST /oauth/access_token + +| Status | JSON Response | +| :--------------- |:------------- | +| 400 Bad Request | `{"error": "invalid_request", "error_description": "the connection was disabled"}`
The connection is not active or not enabled for your `client_id`.| +| 400 Bad Request | `{"error": "invalid_request", "error_description": "the connection was not found"}` | +| 400 Bad Request | `{"error": "invalid_request", "error_description": "missing client_id parameter"}` | +| 400 Bad Request | `{"error": "invalid_request", "error_description": "missing access_token parameter"}` | +| 401 Unauthorized | `{"error": "invalid_request", "error_description": "invalid access_token: invalid_token"}`
The `access_token` is invalid or does not contain the set `scope`| +| 403 Forbidden | `{"error": "unauthorized_client", "error_description": "invalid client"}` | \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_oauth-revoke.md b/fr-ca/articles/api/authentication/errors/_oauth-revoke.md new file mode 100644 index 0000000000..cbca1e2779 --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_oauth-revoke.md @@ -0,0 +1,7 @@ +# POST /oauth/revoke + +| Status | JSON Response | +| :--------------- | :------------ | +|200 Success | `{"error": "invalid_request", "error_description": "..."}`
The Refresh Token is revoked, does not exist, or was not issued to the client making the revocation request| +|400 Bad Request | `{"error": "invalid_request", "error_description": "..."}` The required parameters were not sent in the request.| +|401 Unauthorized | `{"error": "invalid_client", "error_description": "..."}`
The request is not authorized. Check that the client credentials `client_id` and client_secret` are present in the request and hold valid values. | \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_oauth-ro.md b/fr-ca/articles/api/authentication/errors/_oauth-ro.md new file mode 100644 index 0000000000..e552af873a --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_oauth-ro.md @@ -0,0 +1,34 @@ +# POST /oauth/ro + +## Grant type: jwt-bearer + +| Status | JSON Response | +| :----------------| :------------ | +|400 Bad Request|`{"error": "invalid_request", "error_description": "missing device parameter"}`
You need to provide a device name for the caller device (like a browser, app, and so on) | +|400 Bad Request|`{"error": "invalid_request", "error_description": "missing id_token parameter"}`
For this grant type you need to provide a JWT ID Token | +|400 Bad Request|`{"error": "invalid_grant", "error_description": "..."}`
Errors related to an invalid ID Token or user | + +## Grant type: password + +| Status | JSON Response | +| :----------------| :------------ | +| 400 Bad Request|`{"error": "invalid_request", "error_description": "scope parameter must be a string"}`
Incorrect scope formatting; each scope must be separated by whitespace| +| 400 Bad Request|`{"error": "invalid_request", "error_description": "specified strategy does not support requested operation"}`
The connection/provider does not implement username/password authentication | +| 401 Unauthorized|`{"error": "invalid_user_password", "error_description": "Wrong email or password."}`| +| 401 Unauthorized|`{"error": "unauthorized", "error_description": "user is blocked"}`| +| 401 Unauthorized|`{ "error": "password_leaked", "error_description": "This login has been blocked because your password has been leaked in another website. We’ve sent you an email with instructions on how to unblock it."}`| +| 401 Unauthorized|`{ "error": "requires_verification", "error_description": "Suspicious request requires verification" }`| +| 429 Too Many Requests|`{"error": "too_many_attempts", "error_description": "..."}`
Some attack protection features will return this error| +| 429 Too Many Requests|`{"error": "too_many_logins", "error_description": "..."}`
Some attack protection features will return this error| + +## All grant types + +| Status | JSON Response | +| :--------------- | :----------- | +| 400 Bad Request |`{"error": "invalid_request", "error_description": "missing client_id parameter"}<`| +| 400 Bad Request |`{"error": "invalid_request", "error_description": "the connection was disabled"}`
Check the connection in the dashboard, you may have turned it off for the provided `client_id` | +| 400 Bad Request |`{"error": "invalid_request", "error_description": "The connection is not yet configured..."}`
The connection is not properly configured with custom scripts| +| 400 Bad Request |`{"error": "invalid_request", "error_description": "the connection was not found for tenant..."}`
The connection does not belong to the tenant; check your base url | +| 400 Bad Request |`{"error": "invalid_request", "error_description": "Fields with "." are not allowed, please remove all dotted fields..."}`
If you are using rules, some field name contains dots | +| 403 Forbidden |`{"error": "unauthorized_client", "error_description": "invalid client"}`
The provided `client_id` is not valid | +| 403 Forbidden |`{"error": "access_denied", "error_description": "..."}`
Validation of specific points raised an access issue | \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_passwordless-start.md b/fr-ca/articles/api/authentication/errors/_passwordless-start.md new file mode 100644 index 0000000000..348b707a16 --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_passwordless-start.md @@ -0,0 +1,25 @@ + +# POST /passwordless/start + +| Status | JSON Response | +| :----------------| :------------ | +|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - tenant validation failed: invalid_tenant"}`| +|400 Bad Request|`{"error": "bad.client_id", "error_description": "Missing required property: client_id"}`| +|400 Bad Request|`{"error": "bad.connection", "error_description": "Missing required property: connection"}`| +|400 Bad Request|`{"error": "bad.connection", "error_description": "Connection does not exist"}`| +|400 Bad Request|`{"error": "bad.connection", "error_description": "Connection is disabled"}`| +|400 Bad Request|`{"error": "bad.connection", "error_description": "Invalid connection strategy. It must either be a passwordless connection"}`| +|400 Bad Request|`{"error": "bad.authParams", "error_description": "error in authParams - invalid type: string (expected object)"}`| +|400 Bad Request|`{"error": "bad.request", "error_description": "the following properties are not allowed: "}`| +|400 Bad Request|`{"error": "bad.phone_number", "error_description": "Missing required property: phone_number"}`| +|400 Bad Request|`{"error": "bad.phone_number", "error_description": "String does not match pattern: ^\\+[0-9]{1,15}$"}`| +|400 Bad Request|`{"error": "sms_provider_error", "error_description": " (Code: )"}`| +|400 Bad Request|`{"error": "invalid_request","error_description": "Expected `auth0-forwarded-for` header to be a valid IP address."}`| +|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - could not find tenant in params"}`| +|400 Bad Request|`{"error": "server_error","error_description": "error resolving client"}`| +|400 Bad Request|`{"error": "invalid_request","error_description": "The client_id in the authentication header does not match the client_id in the payload"}`| +|400 Bad Request|`{"error": "bad.connection","error_description": "Public signup is disabled"}`| +|400 Bad Request|`{"error": "bad.connection","error_description": "Unknown error"}`| +|401 Unauthorized|`{"error": "server_error","error_description": "user is blocked"}`| +|403 Forbidden|`{"error": "unauthorized_client","error_description": "Client authentication is required"}`| +|500 Internal Server Error|`{"error": "server_error","error_description": "IdP Error"}`| \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/errors/_passwordless-verify.md b/fr-ca/articles/api/authentication/errors/_passwordless-verify.md new file mode 100644 index 0000000000..1ea71461b4 --- /dev/null +++ b/fr-ca/articles/api/authentication/errors/_passwordless-verify.md @@ -0,0 +1,22 @@ +# POST /passwordless/verify + +| Status | JSON Response | +| :----------------| :------------ | +|400 Bad Request|`{"error": "invalid_request", "error_description": "missing username parameter"}`| +|400 Bad Request|`{"error": "invalid_request", "error_description": "scope parameter must be a string"}`
Incorrect scope formatting; each scope must be separated by whitespace| +|400 Bad Request|`{"error": "invalid_request", "error_description": "missing client_id parameter"}`| +|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was not found"}`| +|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was disabled"}`
Check the connection in the dashboard, you may have turned it off for the provided `client_id`| +|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was not found for tenant..."}`
The connection does not belong to the tenant; check your base url| +|400 Bad Request|`{"error": "invalid_request", "error_description": "Fields with "." are not allowed, please remove all dotted fields..."}`
If you are using rules, some field name contains dots| +|400 Bad Request|`"error": "bad.tenant","error_description": "error in tenant - could not find tenant in params"`| +|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - tenant validation failed: "}`| +|400 Bad Request|`{"error": "bad.connection","error_description": "Connection does not exist"}`| +|400 Bad Request|`{"error": "bad.connection","error_description": "Invalid connection strategy. It must either be a passwordless connection"}`| +|400 Bad Request|`{"error": "bad.connection","error_description": "The connection is disabled"}`| +|401 Unauthorized|`{"error": "invalid_user_password", "error_description": "Wrong email or password."}`| +|401 Unauthorized|`{"error": "unauthorized", "error_description": "user is blocked"}`| +|403 Forbidden|`{"error": "unauthorized_client", "error_description": "invalid client"}`
The provided `client_id` is not valid| +|403 Forbidden|`{"error": "access_denied", "error_description": "..."}`
Validation of specific points raised an access issue| +|429 Too Many Requests|`{"error": "too_many_attempts", "error_description": "..."}`
Some attack protection features will return this error| +|500 Bad Request|`{"error": "server_error","error_description": "..."}`| \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/index.md b/fr-ca/articles/api/authentication/index.md new file mode 100644 index 0000000000..3edd4a539a --- /dev/null +++ b/fr-ca/articles/api/authentication/index.md @@ -0,0 +1,128 @@ +--- +title: Authentication API Explorer +fullWidth: true +contentType: + - index + - reference +--- + +
+ <%= include('./_introduction') %> +
+ +
+ <%= include('./_login') %> +
+ +
+ <%= include('./_logout') %> +
+ +
+ <%= include('./_passwordless') %> +
+ +
+ <%= include('./_sign-up') %> +
+ +
+ <%= include('./_change-password') %> +
+ +
+ <%= include('./_userinfo') %> +
+ +
+ <%= include('./_multifactor-authentication') %> +
+ +
+ <%= include('./_saml-sso') %> +
+ +
+ <%= include('./_wsfed-req') %> +
+ +
+ <%= include('./_application-reg') %> +
+ +API Authorization +
+ <%= include('./api-authz/_authz-client') %> +
+
+ <%= include('./api-authz/_auth-code-flow') %> +
+
+ <%= include('./api-authz/_auth-code-pkce') %>> +
+
+ <%= include('./api-authz/_highly-regulated') %>> +
+
+ <%= include('./api-authz/_client-credential') %>> +
+
+ <%= include('./api-authz/_implicit') %>> +
+
+ <%= include('./api-authz/_resource-owner.md') %>> +
+
+ <%= include('./api-authz/_device-code') %> +
+
+ <%= include('./api-authz/_refresh-token') %> +
+
+<%= include('./api-authz/_revoke-refresh-token') %> +
+
+<%= include('./api-authz/_token-exchange-native-social') %> +
+ +Legacy +
+ <%= include('./legacy/_login') %> +
+
+ <%= include('./legacy/_userinfo') %> +
+
+ <%= include('./legacy/_linking') %> +
+
+ <%= include('./legacy/_delegation') %> +
+
+ <%= include('./legacy/_impersonation') %> +
+
+ <%= include('./legacy/_resource-owner') %> +
+ +Errors +
+ <%= include('./errors/_errors') %> +
+
+ <%= include('./errors/_oauth-revoke') %> +
+
+ <%= include('./errors/_oauth-access_token') %> +
+
+<%= include('./errors/_oauth-ro') %> +
+
+ <%= include('./errors/_passwordless-start') %> +
+
+ <%= include('./errors/_passwordless-verify') %> +
+ + diff --git a/fr-ca/articles/api/authentication/legacy/_delegation.md b/fr-ca/articles/api/authentication/legacy/_delegation.md new file mode 100644 index 0000000000..a173755d24 --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_delegation.md @@ -0,0 +1,73 @@ +# Delegation + +```http +POST https://${account.namespace}/delegation +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer", + "id_token" or "refresh_token" : "TOKEN", + "target": "TARGET_CLIENT_ID", + "scope": "openid", + "api_type": "API_TYPE" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/delegation' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "grant_type":"urn:ietf:params:oauth:grant-type:jwt-bearer", "id_token|refresh_token":"TOKEN", "target":"TARGET_CLIENT_ID", "scope":"openid", "api_type":"API_TYPE"}' +``` + +```javascript +// Delegation is not supported in version 8 of auth0.js. +// For a version 7 sample refer to: https://auth0.com/docs/libraries/auth0js/v7#delegation-token-request +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/delegation", + "link": "#delegation" +}) %> + +::: warning +By default, this feature is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate. +::: + +A delegation token can be obtained and used when an application needs to call the API of an Application Addon, such as Firebase or SAP, registered and configured in Auth0, in the same tenant as the calling program. + +Given an existing token, this endpoint will generate a new token signed with the `target` app' secret. This is used to flow the identity of the user from the application to an API. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Τhe `client_id` of your app | +| `grant_type`
Required | Use `urn:ietf:params:oauth:grant-type:jwt-bearer`| +| `id_token` or `refresh_token`
Required | The existing token of the user. | +| `target` | The target `client_id` | +| `scope` | Use `openid` or `openid profile email` | +| `api_type` | The API to be called. | + +### Remarks + +- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`. + +- The `email` scope value requests access to the `email` and `email_verified` Claims. + +- Delegation is __not supported__ in version 8 of [auth0.js](/libraries/auth0js). For a sample in version 7 of the library, refer to [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request). + +- This endpoint limits up to 10 requests per minute from the same IP address with the same `user_id`. + +- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits: + - `X-RateLimit-Limit`: Number of requests allowed per minute. + - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time. + - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time). + + +### Learn More + +- [Delegation Tokens](/tokens/delegation) +- [Auth0 API Rate Limit Policy](/policies/rate-limits) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/legacy/_impersonation.md b/fr-ca/articles/api/authentication/legacy/_impersonation.md new file mode 100644 index 0000000000..6fd286a04f --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_impersonation.md @@ -0,0 +1,81 @@ +# Impersonation + +```http +POST https://${account.namespace}/users/{user_id}/impersonate +Content-Type: application/json +Authorization: 'Bearer {ACCESS_TOKEN}' +{ + protocol: "PROTOCOL", + impersonator_id: "IMPERSONATOR_ID", + client_id: "${account.clientId}", + additionalParameters: [ + "response_type": "code", + "state": "STATE" + ] +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/users/{user_id}/impersonate' \ + --header 'Authorization: Bearer {ACCESS_TOKEN}' \ + --header 'content-type: application/x-www-form-urlencoded; charset=UTF-8' \ + --data '{"protocol":"PROTOCOL", "impersonator_id":"IMPERSONATOR_ID", "client_id":"${account.clientId}", "additionalParameters": {"response_type": "code", "state": "STATE"}}' +``` + +```javascript +var url = 'https://' + ${account.namespace} + '/users/' + localStorage.getItem('user_id') + '/impersonate'; +var params = 'protocol=PROTOCOL&impersonator_id=IMPERSONATOR_ID&client_id=${account.clientId}'; + +var xhr = new XMLHttpRequest(); + +xhr.open('POST', url); +xhr.setRequestHeader('Content-Type', 'application/json'); +xhr.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('access_token')); + +xhr.onload = function() { + if (xhr.status == 200) { + fetchProfile(); + } else { + alert("Request failed: " + xhr.statusText); + } +}; + +xhr.send(params); +``` + +> RESPONSE SAMPLE: + +```text +https:/YOUR_DOMAIN/users/IMPERSONATOR_ID/impersonate?&bewit=WFh0MUtm... +``` + +<% var path = '/users/{user_id}/impersonate'; %> + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": path, + "link": "#impersonation" +}) %> + +<%= include('../../../_includes/_deprecate-impersonation.md') %> + +Use this endpoint to obtain an impersonation URL to login as another user. Useful for troubleshooting. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `protocol`
Required | The protocol to use against the identity provider: `oauth2`, `samlp`, `wsfed`, `wsfed-rms`. | +| `impersonator_id`
Required | The `user_id` of the impersonator. | +| `client_id`
Required | The `client_id` of the client that is generating the impersonation link.| +| `additionalParameters` | This is a JSON object. You can use this to set additional parameters, like `response_type`, `scope` and `state`. | + +### Remarks + +- This endpoint can only be used with **Global Client** credentials. + +- To distinguish between real logins and impersonation logins, the profile of the impersonated user will contain additional impersonated and impersonator properties. For example: `"impersonated": true, "impersonator": {"user_id": "auth0|...", "email": "admin@example.com"}`. + +- For a regular web app, you should set the `additionalParameters`: set the `response_type` to be `code`, the `callback_url` to be the callback URL to which Auth0 will redirect with the authorization code, and the `scope` to be the JWT claims that you want included in the JWT. diff --git a/fr-ca/articles/api/authentication/legacy/_linking.md b/fr-ca/articles/api/authentication/legacy/_linking.md new file mode 100644 index 0000000000..0e4b6657ce --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_linking.md @@ -0,0 +1,113 @@ +# Account Linking +## Link + +::: warning +This endpoint is **deprecated** for account linking. The [POST /api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) should be used instead. For more information refer to the [Migration Notice](/migrations/past-migrations#account-linking-removal). +::: + +```http +GET https://${account.namespace}/authorize? + response_type=code|token& + client_id=${account.clientId}& + connection=CONNECTION& + redirect_uri=${account.callback}& + access_token=LOGGED_IN_USER_ACCESS_TOKEN +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#link" +}) %> + +Call this endpoint when a user wants to link a second authentication method (for example, a user/password database connection, with Facebook). + +This endpoint will trigger the login flow to link an existing account with a new one. This will return a 302 redirect to the `connection` that the current user wants to add. The user is identified by the Access Token that was returned on login success. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `response_type`
Required | Use `code` for server side flows, `token` for client side flows | +| `client_id`
Required | The `client_id` of your application | +| `connection` | The name of the connection configured to your application. If null, it will redirect to [Auth0 Login Page](https://auth0.com/#/login_page) and show the Login Widget using the first database connection. | +| `redirect_uri`
Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. | +| `access_token`
Required | The logged-in user's Access Token | + + +### Remarks + +- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications). + + +### Learn More + +- [Link User Accounts](/users/guides/link-user-accounts) +- [Link User Accounts Initiated by Users Scenario](/users/references/link-accounts-user-initiated-scenario) +- [Link User Accounts Server-Side Scenario](/users/references/link-accounts-server-side-scenario) + + +## Unlink + +```http +POST https://${account.namespace}/login/unlink +Content-Type: application/json +{ + "access_token": "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity Access Token + "user_id": "LINKED_USER_ID" // (provider|id) +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/login/unlink' \ + --header 'content-type: application/json' \ + --data '{"access_token": "LOGGED_IN_USER_ACCESS_TOKEN", "user_id": "LINKED_USER_ID"}' +``` + +```javascript +var url = 'https://' + ${account.namespace} + '/login/unlink'; +var params = 'access_token=LOGGED_IN_USER_ACCESS_TOKEN&user_id=' + localStorage.getItem('user_id'); + +var xhr = new XMLHttpRequest(); +xhr.open('POST', url); +xhr.setRequestHeader('Content-Type', 'application/json'); + +xhr.onload = function() { + if (xhr.status == 200) { + fetchProfile(); + } else { + alert("Request failed: " + xhr.statusText); + } +}; + +xhr.send(params); +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/login/unlink", + "link": "#unlink" +}) %> + +::: warning +This endpoint is **deprecated**. The [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) should be used instead. +::: + +Given a logged-in user's `access_token` and `user_id`, this endpoint will unlink a user's account from the identity provider. + + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `access_token`
Required | The logged-in user's Access Token | +| `user_id`
Required | The logged-in user's `user_id` | + + +### Learn More + +- [Unlink User Accounts](/users/guides/unlink-user-accounts) diff --git a/fr-ca/articles/api/authentication/legacy/_login.md b/fr-ca/articles/api/authentication/legacy/_login.md new file mode 100644 index 0000000000..4c197080e9 --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_login.md @@ -0,0 +1,197 @@ + +# Login +## Social with Provider's Access Token + +```http +POST https://${account.namespace}/oauth/access_token +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "access_token": "ACCESS_TOKEN", + "connection": "CONNECTION", + "scope": "SCOPE" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/access_token' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "access_token":"ACCESS_TOKEN", "connection":"CONNECTION", "scope":"SCOPE"}' +``` + +```javascript +var url = 'https://' + ${account.namespace} + '/oauth/access_token'; +var params = 'client_id=${account.clientId}&access_token={ACCESS_TOKEN}&connection={CONNECTION}&scope={SCOPE}'; + +var xhr = new XMLHttpRequest(); + +xhr.open('POST', url); +xhr.setRequestHeader('Content-Type', 'application/json'); + +xhr.onload = function() { + if (xhr.status == 200) { + fetchProfile(); + } else { + alert("Request failed: " + xhr.statusText); + } +}; + +xhr.send(params); +``` + +> RESPONSE SAMPLE: + +```JSON +{ + "id_token": "eyJ0eXAiOiJKV1Qi...", + "access_token": "A9CvPwFojaBI...", + "token_type": "bearer" +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/access_token", + "link": "#social-with-provider-s-access-token" +}) %> + +::: warning +This endpoint is part of the legacy authentication pipeline. We recommend that you open the browser to do social authentication instead, which is what [Google and Facebook are recommending](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). + +This feature is disabled by default for new tenants as of 8 June 2017. Please see [Application Grant Types](/applications/concepts/application-grant-types) for more information. + +::: + +Given the social provider's Access Token and the `connection`, this endpoint will authenticate the user with the provider and return a JSON with the Access Token and, optionally, an ID Token. This endpoint only works for Facebook, Google, Twitter, and Weibo. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application. | +| `access_token`
Required | The social provider's Access Token. | +| `connection`
Required | The name of an identity provider configured to your app. | +| `scope` | Use `openid` to get an ID Token, or `openid profile email` to include user information in the ID Token. If null, only an Access Token will be returned. | + + +### Remarks + +- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`. + +- The `email` scope value requests access to the `email` and `email_verified` Claims. + +### Error Codes + +For the complete error code reference for this endpoint refer to [Errors > POST /oauth/access_token](#post-oauth-access_token). + +### Learn More + +- [Call an Identity Provider API](/tutorials/calling-an-external-idp-api) +- [Identity Provider Access Tokens](/tokens/overview-idp-access-tokens) +- [Add scopes/permissions to call Identity Provider's APIs](/connections/adding-scopes-for-an-external-idp) + +## Database/AD/LDAP (Active) + +```http +POST https://${account.namespace}/oauth/ro +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "username": "USERNAME", + "password": "PASSWORD", + "connection": "CONNECTION", + "scope": "openid" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/ro' \ + --header 'content-type: application/json' \ + --data '{"client_id":"${account.clientId}", "username":"USERNAME", "password":"PASSWORD", "connection":"CONNECTION", "scope":"openid"}' + +``` + +```javascript +// Script uses auth0.js. See Remarks for details. + + +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/ro", + "link": "#database-ad-ldap-active-" +}) %> + +::: warning +This endpoint is part of the legacy authentication pipeline and has been replaced in favor of the [Password Grant](#resource-owner-password). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +Use this endpoint for API-based (active) authentication. Given the user credentials and the `connection` specified, it will do the authentication on the provider and return a JSON with the Access Token and ID Token. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | The `client_id` of your application | +| `username`
Required | Username/email of the user to login | +| `password`
Required | Password of the user to login | +| `connection`
Required | The name of the connection to use for login | +| `scope` | Set to `openid` to retrieve also an ID Token, leave null to get only an Access Token | +| `grant_type`
Required | Set to `password` to authenticate using username/password or `urn:ietf:params:oauth:grant-type:jwt-bearer` to authenticate using an ID Token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. | +| `device` | String value. Required when `grant_type` is `urn:ietf:params:oauth:grant-type:jwt-bearer` | +| `id_token` | Used to authenticate using a token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. Required when `grant_type` is `urn:ietf:params:oauth:grant-type:jwt-bearer` | + +### Remarks + +- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS. + +- The main difference between passive and active authentication is that the former happens in the browser through the [Auth0 Login Page](https://${account.namespace}/login) and the latter can be invoked from anywhere (a script, server to server, and so forth). + +- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7). + + +### Error Codes + +For the complete error code reference for this endpoint, refer to [Errors > POST /oauth/ro](#post-oauth-ro). + +### Learn More + +- [Database Identity Providers](/connections/database) +- [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits) +- [Active Directory/LDAP Connector](/connector) \ No newline at end of file diff --git a/fr-ca/articles/api/authentication/legacy/_resource-owner.md b/fr-ca/articles/api/authentication/legacy/_resource-owner.md new file mode 100644 index 0000000000..d191536587 --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_resource-owner.md @@ -0,0 +1,100 @@ +# Resource Owner + +```http +POST https://${account.namespace}/oauth/ro +Content-Type: application/json +{ + "client_id": "${account.clientId}", + "connection": "CONNECTION", + "grant_type": "password", + "username": "USERNAME", + "password": "PASSWORD", + "scope": "SCOPE", + "id_token": "ID_TOKEN", + "device": "DEVICE" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/oauth/ro' \ + --header 'accept: application/json' \ + --header 'content-type: application/json' \ + --data '{ "client_id": "${account.clientId}", "connection": "CONNECTION", "grant_type": "password", "username": "USERNAME", "password": "PASSWORD", "scope": "SCOPE", "id_token": "ID_TOKEN", "device": "DEVICE" }' +``` + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/ro', + headers: { 'content-type': 'application/json', 'accept': 'application/json' }, + body: + { connection: 'CONNECTION', + grant_type: 'PASSWORD', + username: 'USERNAME', + client_id: '${account.clientId}', + password: 'PASSWORD', + scope: 'SCOPE', + id_token: 'ID_TOKEN', + device: 'DEVICE'}, + json: true }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + console.log(body); +}); +``` + +> RESPONSE SAMPLE: + +```JSON +{ + "access_token": "eyJz93a...", + "id_token": "eyJ0XAi...", + "token_type": "Bearer" +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/oauth/ro", + "link": "#resource-owner" +}) %> + +::: warning +This endpoint is part of the legacy authentication pipeline and has been replaced in favor of the [Password Grant](#resource-owner-password-flow). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +Given the user's credentials, this endpoint will authenticate the user with the provider and return a JSON object with the Access Token and an ID Token. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `client_id`
Required | Your application's Application ID. | +| `connection`
Required | The name of the connection configured to your application | +| `grant_type`
Required | Use the value `password` | +| `username`
Required | The user's username | +| `password`
Required | The user's password | +| `scope` | Use `openid` to get an ID Token, `openid profile email` to get an ID Token and the user profile, or `openid offline_access` to get an ID Token and a Refresh Token. | +| `id_token` | Used to authenticate using a token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. | +| `device` | You should set this to a string, if you are requesting a Refresh Token (`scope=offline_access`). | + +### Remarks + +- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS. + +- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`. + +- The `email` scope value requests access to the `email` and `email_verified` Claims. + +### Error Codes + +For the complete error code reference for this endpoint refer to [Errors > POST /oauth/ro](#post-oauth-ro). + +### Learn More + +- [Calling APIs from Highly Trusted Applications](/api-auth/grant/password) diff --git a/fr-ca/articles/api/authentication/legacy/_userinfo.md b/fr-ca/articles/api/authentication/legacy/_userinfo.md new file mode 100644 index 0000000000..d35e12a99e --- /dev/null +++ b/fr-ca/articles/api/authentication/legacy/_userinfo.md @@ -0,0 +1,97 @@ + + +# User Profile +## Get Token Info + +```http +POST https://${account.namespace}/tokeninfo +Content-Type: application/json +{ + "id_token": "ID_TOKEN" +} +``` + +```shell +curl --request POST \ + --url 'https://${account.namespace}/tokeninfo' \ + --header 'content-type: application/json' \ + --data '{"id_token":""}' +``` + +```javascript + + + +webAuth.parseHash(window.location.hash, function(err, authResult) { + if (err) { + return console.log(err); + } + + webAuth.client.userInfo(authResult.accessToken, function(err, user) { + // Now you have the user's information + }); +}); +``` + +> RESPONSE SAMPLE: + +```json +{ + "email_verified": false, + "email": "foo@bar.com", + "clientID": "q2hnj2iug0...", + "updated_at": "2016-12-08T14:26:59.923Z", + "name": "foo@bar.com", + "picture": "https://s.gravatar.com/avatar/foobar.png", + "user_id": "auth0|58454...", + "nickname": "foo.bar", + "identities": [ + { + "user_id": "58454...", + "provider": "auth0", + "connection": "Username-Password-Authentication", + "isSocial": false + } + ], + "created_at": "2016-12-05T11:16:59.640Z", + "global_client_id": "dfas76s..." +} +``` + +<%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/tokeninfo", + "link": "#get-token-info" +}) %> + +::: warning +This endpoint is part of the legacy authentication pipeline and will be disabled for those who use our latest, OIDC conformant, pipeline. We encourage using the [/userinfo endpoint](#get-user-info) instead. For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +This endpoint validates a JSON Web Token (JWT) (signature and expiration) and returns the user information associated with the user id `sub` property of the token. + +### Request Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `id_token`
Required | The ID Token to use. | + + +### Remarks + +- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits: + - `X-RateLimit-Limit`: Number of requests allowed per minute. + - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time. + - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time). + +### Learn More + +- [User Profile Struture](/users/references/user-profile-structure) + +- [Auth0 API Rate Limit Policy](/policies/rate-limits) diff --git a/fr-ca/articles/api/authorization-extension/_groups.md b/fr-ca/articles/api/authorization-extension/_groups.md new file mode 100644 index 0000000000..17bc41355c --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/_groups.md @@ -0,0 +1,1038 @@ +# Groups + +Groups are collections of users. The groups that you will create are dependent on the needs of your business process. For example, you might have a group for your users in Finance, a group for your users in IT, and so on. + +For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#groups). + +## Get all Groups + +
Examples
+ +```http +GET https://{extension_url}/groups +Authorization: 'Bearer {access_token}' +``` + +> RESPONSE SAMPLE: + +```text +{ + "groups":[ + { + "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name":"Test", + "description":"Test", + "members":[ + "auth0|59396da1b3c34a15589c780d" + ], + "mappings":[ + + ] + }, + { + "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace", + "name":"Google", + "description":"Google", + "mappings":[ + { + "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2", + "groupName":"Google", + "connectionName":"google-oauth2" + } + ], + "members":[ + "auth0|59396da1b3c34a15589c780d", + "google-oauth2|113108011846505476166" + ], + "nested":[ + "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f" + ], + "roles":[ + "9b814aac-87ba-4d84-8de6-3bcd0afee761" + ] + } + ], + "total":2 +} +``` + +<% var path = '/groups'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-groups" +}) %> + +Use this endpoint to retrieve all groups. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | + +## Get a single Group + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id} +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id": "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name": "Test", + "description": "Test" +} +``` + +<% var path = '/groups/{group_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-single-group" +}) %> + +Use this endpoint to get a single group based on its unique identifier. Add "?expand" to also load all roles and permissions for this group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to retrieve. | + +## Create Group + +
Examples
+ +```http +``` + +```shell +curl --request POST \ + --url 'https://{extension_url}/groups' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'content-type: application/json' \ + --data '{"name": "My name", "description": "My description"}' +``` + +> RESPONSE SAMPLE: + +```text +{ + "name":"My name", + "description":"My description", + "_id":"3ea7dc85-3e50-4ba8-ae5a-4956ed6b26d5" +} +``` + +<% var path = '/groups'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": path, + "link": "#create-group" +}) %> + +Use this endpoint to create a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +create:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `name`
Required | The name of the new group | +| `description` | A description of the new group | + +## Delete Group + +
Examples
+ +```http +POST https://{extension_url}/groups/{group_id} +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +``` + +```shell +curl --request POST \ + --url 'https://{extension_url}/groups/{group_id}' \ + --header 'Authorization: Bearer {access_token}' \ +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-group" +}) %> + +Use this endpoint to delete a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +delete:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to delete | + +## Update Group + +
Examples
+ +```http +PUT https://{extension_url}/groups/{group_id} +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +{ + name: "New name", + description: "New description" +} +``` + +```shell +curl --request PUT \ + --url 'https://{extension_url}/groups/{group_id}' \ + --header 'Authorization: Bearer {access_token}' \ + --data '{ "name": "New name", "description": "New description" }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id": "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name": "New name", + "description": "New description", + "members": [ + "auth0|59396da1b3c34a15589c780d" + ] +} +``` + +
+ PUT + /groups/{group_id} +
+ +Use this endpoint to update the name or the description of a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to update | +| `name`
Required | The updated group name | +| `description`
Required | The updated group description | + +## Get Group Mappings + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/mappings +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2", + "groupName":"Google", + "connectionName":"google-oauth2 (google-oauth2)" +} +``` + +<% var path = '/groups/{group_id}/mappings'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-group-mappings" +}) %> + +Use this endpoint to retrieve the mappings of a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group whose mappings you want to retrieve | + +## Create Group Mappings + +
Examples
+ +```http +PATCH https://{extension_url}/groups/{group_id}/mappings +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +{ + groupName: "Test", + connectionName: "google-oauth2" +} +``` + +```shell +curl -v -X PATCH \ + --url 'https://{extension_url}/api/groups/{group_id}/mappings' \ + --header 'Content-Type: application/json' \ + --header 'Authorization: Bearer {access_token}' \ + --data '[{"groupName": "Test", "connectionName": "google-oauth2"}]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +
+ PATCH + /groups/{group_id}/mappings +
+ +Use this endpoint to create one or more mappings in a group. + +Group Mappings allow you to dynamically "add" users to different Groups based on the users' Connections. Essentially, using the Connection and the Groups information provided by the Identity Provider, you can dynamically make the user a member of the group in which you've created the appropriate mapping. For more information, refer to [Group Mappings](/extensions/authorization-extension/v2/implementation/setup#group-mappings). + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group whose mappings you want to retrieve | +| `groupName`
Required | Group to add the users to | +| `connectionName`
Required | Connection for the mapping | + +## Delete Group Mappings + +
Examples
+ +```http +DELETE https://{extension_url}/groups/{group_id}/mappings +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +{ + _id: [ + "7b57312c-579a-4798-bd91-9647563e1b8a" + ], +} +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/groups/{group_id}/mappings' \ + --header 'Authorization: Bearer {access_token}' \ + --data '{"_id": ["7b57312c-579a-4798-bd91-9647563e1b8a"]}' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/mappings'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-group-mappings" +}) %> + +Use this endpoint to delete one or more group mappings from a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more information on how to implement this, refer to our [machine-to-machine flow implementation guide](/flows/guides/client-credentials/call-api-client-credentials) | +| `{group_id}`
Required | The id of the group whose mappings you want to delete | + +## Get Group Members + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/members +``` + +> RESPONSE SAMPLE: + +```text +{ + "total":1, + "users":[ + { + "email":"richard.dowinton@auth0.com", + "email_verified":true, + "user_id":"auth0|59396da1b3c34a15589c780d", + "picture":"https://s.gravatar.com/avatar/3e8ce75cfe7c53f13715df274f63e129?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fri.png", + "nickname":"richard.dowinton", + "identities":[ + { + "user_id":"59396da1b3c34a15589c780d", + "provider":"auth0", + "connection":"Username-Password-Authentication", + "isSocial":false + } + ], + "updated_at":"2017-06-25T07:28:54.719Z", + "created_at":"2017-06-08T15:30:41.237Z", + "name":"richard.dowinton@auth0.com", + "app_metadata":{ + "authorization":{ + "roles":[ + + ], + "permissions":[ + + ] + } + }, + "last_ip":"83.208.22.80", + "last_login":"2017-06-25T07:28:54.719Z", + "logins_count":12 + } + ] +} +``` + +<% var path = '/groups/{group_id}/members'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-group-members" +}) %> + +Use this endpoint to get the members for a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group whose members you want to retrieve | +| `{page}` | The page number. One-based. | +| `{per_page}` | The amount of entries per page. Default: `25`. Max value: `25`. | + + +## Add Group Members + +
Examples
+ +```http +PATCH https://{extension_url}/groups/{group_id}/members +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "google-oauth2|113108011846505476166" ] +``` + +```shell +curl --request PATCH \ + --url 'https://{extension_url}/groups/{group_id}/members' \ + --header 'Authorization: Bearer {access_token}' \ + --data '[ "{user_id}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/members'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "PATCH", + "path": path, + "link": "#add-group-members" +}) %> + +Use this endpoint to add one or more members in a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to which you want to add members | +| `{user_id}` | Id of the user to add in a group | + +## Delete Group Members + +
Examples
+ +```http +DELETE https://{extension_url}/groups/{group_id}/members +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +["7b57312c-579a-4798-bd91-9647563e1b8a"] +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/groups/{group_id}/members' \ + --header 'Authorization: Bearer {access_token}' \ + --data '["7b57312c-579a-4798-bd91-9647563e1b8a"]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/members'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-group-members" +}) %> + +Use this endpoint to remove one or more members from a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which you want to remove members | + +## Get Nested Group Members + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/members/nested +``` + +> RESPONSE SAMPLE: + +```text +{ + "total":1, + "nested":[ + { + "user":{ + "user_id":"auth0|59396da1b3c34a15589c780d", + "name":"richard.dowinton@auth0.com", + "nickname":"richard.dowinton", + "email":"richard.dowinton@auth0.com" + }, + "group":{ + "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name":"New name", + "description":"New description" + } + } + ] +} +``` + +<% var path = '/groups/{group_id}/members/nested'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-nested-group-members" +}) %> + +Use this endpoint to get the nested members for a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which the nested members will be retrieved | +| `{page}` | The page number. One-based. | +| `{per_page}` | The amount of entries per page. Default: `25`. Max value: `25`. | + +## Get Nested Groups + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/nested +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name":"Test", + "description":"Test", + "members":[ + "auth0|59396da1b3c34a15589c780d" + ] + } +] +``` + +<% var path = '/groups/{group_id}/nested'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-nested-groups" +}) %> + +Use this endpoint to get the nested groups for a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which the nested members will be retrieved | + +## Add Nested Groups + +
Examples
+ +```http +PATCH https://{extension_url}/groups/{group_id}/nested +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "{group_id_to_add}" ] +``` + +```shell +curl --request PATCH \ + --url 'https://{extension_url}/groups/{group_id}/nested' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'Content-Type: application/json' \ + --data '[ "{group_id_to_add}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/nested'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "PATCH", + "path": path, + "link": "#add-nested-groups" +}) %> + +Use this endpoint to add nested groups. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to which you want to add members | +| `{group_id_to_add}` | List of group IDs that you want to add in the group | + +## Delete Nested Groups + +
Examples
+ +```http +DELETE https://{extension_url}/groups/{group_id}/nested +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +["{NESTED_GROUP_ID}"] +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/groups/{group_id}/nested' \ + --header 'Authorization: Bearer {access_token}' \ + --data '["{NESTED_GROUP_ID}"]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/nested'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-nested-group" +}) %> + +Use this endpoint to remove one or more nested groups. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which you want to remove other group members | +| `{NESTED_GROUP_ID}`
Required | The id of the group to remove | + +## Get Group Roles + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/roles +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Test", + "name":"Test", + "permissions":[ + + ], + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761" + } +] +``` + +<% var path = '/groups/{group_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-group-roles" +}) %> + +Use this endpoint to get the roles for a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which the nested members will be retrieved | + +## Add Group Roles + +
Examples
+ +```http +PATCH https://{extension_url}/groups/{group_id}/roles +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "google-oauth2|113108011846505476166" ] +``` + +```shell +curl --request PATCH \ + --url 'https://{extension_url}/groups/{group_id}/roles' \ + --header 'Authorization: Bearer {access_token}' \ + --data '[ "{role_id}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "PATCH", + "path": path, + "link": "#add-group-roles" +}) %> + +Use this endpoint to add roles to a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group to which you want to add members | +| `{role_id}` | List of role IDs to add in the group | + +## Delete Group Roles + +
Examples
+ +```http +DELETE https://{extension_url}/groups/{group_id}/roles +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +["{GROUP_ROLES_ID}"] +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/groups/{group_id}/roles' \ + --header 'Authorization: Bearer {access_token}' \ + --data '["{role_id}"]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/groups/{group_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-group-roles" +}) %> + +Use this endpoint to remove one or more groups roles. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which you want to remove members | +| `{role_id}`
Required | The IDs of the roles to be removed from the group | + +## Get Nested Group Roles + +
Examples
+ +```http +GET https://{extension_url}/groups/{group_id}/roles/nested +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "role":{ + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Test", + "name":"Test", + "permissions":[ + + ], + "users":[ + "auth0|59396da1b3c34a15589c780d" + ] + }, + "group":{ + "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace", + "name":"Google", + "description":"Google", + "mappings":[ + { + "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2", + "groupName":"Google", + "connectionName":"google-oauth2" + } + ], + "members":[ + "auth0|59396da1b3c34a15589c780d", + "google-oauth2|113108011846505476166" + ], + "nested":[ + "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f" + ], + "roles":[ + "9b814aac-87ba-4d84-8de6-3bcd0afee761" + ] + } + } +] +``` + +<% var path = '/groups/{group_id}/roles/nested'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-nested-roles" +}) %> + +Use this endpoint to get the nested roles for a group. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{group_id}`
Required | The id of the group from which the nested members will be retrieved | diff --git a/fr-ca/articles/api/authorization-extension/_introduction.md b/fr-ca/articles/api/authorization-extension/_introduction.md new file mode 100644 index 0000000000..973481dac2 --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/_introduction.md @@ -0,0 +1,51 @@ +# Introduction + +The Authorization Extension API enables you to: + +- automate provisioning for your users, roles, groups, and permissions +- query the authorization context of your users in real time + +In order to use it, you first have to [enable API access](/extensions/authorization-extension/v2#enable-api-access) from your Authorization Dashboard. + +For more information on the Authorization Extension and how to configure it, refer to [Auth0 Authorization Extension](/extensions/authorization-extension). + +For each endpoint in this explorer, you will find sample snippets you can use, in three available formats: + +- HTTP request +- Curl command +- JavaScript: depending on the endpoint each snippet may use Node.js or simple JavaScript + +Each request should be sent with a Content-Type of `application/json`. + +## Find your extension URL + +All endpoints in this explorer start with `https://{extension_url}`. This is the URL of your Authorization Dashboard. It differs based on you tenant's region: + +<% + var urlUS = 'https://' + account.tenant + '.us.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api'; + var urlEU = 'https://' + account.tenant + '.eu.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api'; + var urlAU = 'https://' + account.tenant + '.au.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api'; +%> + +| Region | Extension URL | +|--------|---------------| +| US West | `${urlUS}` | +| Europe | `${urlEU}` | +| Australia | `${urlAU}` | + +## Get an Access Token + +When you [enabled API access for your tenant](/extensions/authorization-extension/v2#enable-api-access), an API was created at your [dashboard](${manage_url}), which you can use to access the Authorization Extension API. + +To do so you will have to configure a machine to machine application which will have access to this API and which you will use to get an Access Token. + +Follow these steps to set up your application (you will have to do this only once): + +1. Go to [Dashboard > Applications](${manage_url}/#/applications) and create a new application of type `Machine to Machine`. +2. Go to the [Dashboard > APIs](${manage_url}/#/apis) and select the `auth0-authorization-extension-api`. +3. Go to the `Machine to Machine Applications` tab, find the application you created at the first step, and toggle the `Unauthorized` to `Authorized`. +4. Select the [scopes](/scopes/current/api-scopes) that should be granted to your application, based on the endpoints you want to access. For example, `read:users` to [get all users](#get-all-users). + +To get an Access Token, you need to `POST` to the `/oauth/token` endpoint. You can find detailed instructions [here](/flows/guides/client-credentials/call-api-client-credentials#request-token). + +Use this Access Token to access the Authorization Extension API. diff --git a/fr-ca/articles/api/authorization-extension/_permissions.md b/fr-ca/articles/api/authorization-extension/_permissions.md new file mode 100644 index 0000000000..8c1c151fcf --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/_permissions.md @@ -0,0 +1,256 @@ +# Permissions + +Permissions are actions or functions that a user, or group of user, is allowed to do. For example, let's say that you have an application that allows employees to enter in company expenses. You want all employees to be able to submit expenses, but want certain Finance users to have more admin type of actions such as being able to approve or delete expenses. These actions can be mapped to [permissions](/extensions/authorization-extension#permissions) (which later on can be grouped in [roles](/extensions/authorization-extension#roles)): + +For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#permissions). + +## Get all Permissions + +
Examples
+ +```http +GET https://{extension_url}/permissions +``` + +> RESPONSE SAMPLE: + +```text +{ + "permissions":[ + { + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Example permission", + "name":"Example", + "_id":"deeb552d-2d98-4efb-bb84-0c8babe5f431" + } + ], + "total":1 +} +``` + +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": '/permissions', + "link": "#get-permissions" +}) %> + +Use this endpoint to retrieve all permissions. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:permissions + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | + +## Get a single Permission + +
Examples
+ +```http +GET https://{extension_url}/permissions/{permission_id} +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id":"deeb552d-2d98-4efb-bb84-0c8babe5f431", + "name":"Example", + "description":"Example permission" +} +``` + +<% var path = '/permissions/{permission_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-single-permission" +}) %> + +Use this endpoint to get a single permission based on its unique identifier. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:permissions + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{permission_id}`
Required | The id of the permission to retrieve. | + +## Create Permission + +
Examples
+ +```http +``` + +```shell +curl --request POST \ + --url 'https://{extension_url}/permissions' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'content-type: application/json' \ + --data '{ "name":"Example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "name":"Example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "_id":"4dcdbcbb-e598-4b8f-abc1-7feb57dc54fe" +} +``` + +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/permissions", + "link": "#create-permission" +}) %> + +Use this endpoint to create a permission. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +create:permissions + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `name` | The new permission's name | +| `description` | The new permission's description | +| `applicationType` | The new permission's application type | +| `applicationId` | The new permission's application Id | + +## Update Permission + +
Examples
+ +```http +PUT https://{extension_url}/permissions/{permission_id} +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +{ + "name":"New example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" +} +``` + +```shell +curl --request PUT \ + --url 'https://{extension_url}/permissions/{permission_id}' \ + --header 'Authorization: Bearer {access_token}' \ + --data '{ "name":"New example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id":"bc6945e0-393a-4405-99d9-96903eaec4a1", + "name":"New example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" +} +``` + +
+ PUT + /permissions/{permission_id} +
+ +Use this endpoint to update the details of a permission. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:permissions + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{permission_id}`
Required | The id of the permission to update | +| `name` | The updated permission name | +| `description` | The updated permission description | +| `applicationType` | The updated application type | +| `applicationId` | The updated application Id | + +## Delete Permission + +
Examples
+ +```http +DELETE https://{extension_url}/permissions/{permission_id} +Authorization: 'Bearer {access_token}' +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/permissions/{permission_id}' \ + --header 'Authorization: Bearer {access_token}' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/permissions/{permission_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-permission" +}) %> + +Use this endpoint to remove a permission. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +delete:permissions + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{permission_id}`
Required | The id of the permission to delete | \ No newline at end of file diff --git a/fr-ca/articles/api/authorization-extension/_roles.md b/fr-ca/articles/api/authorization-extension/_roles.md new file mode 100644 index 0000000000..45ca6b2d8c --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/_roles.md @@ -0,0 +1,281 @@ +# Roles + +Roles are collections of permissions. For example, let's say that you have an application that allows employees to enter in company expenses. You want all employees to be able to submit expenses, but want certain Finance users to have more admin type of actions such as being able to approve or delete expenses. These actions can be mapped to [Permissions](/extensions/authorization-extension#permissions) and then assigned to a certain role. + +For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#roles). + +## Get all Roles + +
Examples
+ +```http +GET https://{extension_url}/roles +``` + +> RESPONSE SAMPLE: + +```text +{ + "roles":[ + { + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Test", + "name":"Test", + "permissions":[ + + ], + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761" + }, + { + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Example", + "name":"Example 2", + "permissions":[ + + ], + "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692" + } + ], + "total":2 +} +``` + +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": '/roles', + "link": "#get-roles" +}) %> + +Use this endpoint to retrieve all roles. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | + +## Get a single Role + +
Examples
+ +```http +GET https://{extension_url}/roles/{role_id} +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761", + "name":"Test", + "description":"Test" +} +``` + +<% var path = '/roles/{role_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-single-role" +}) %> + +Use this endpoint to get a single role based on its unique identifier. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{role_id}`
Required | The id of the role to retrieve. | + +## Create Role + +
Examples
+ +```http +``` + +```shell +curl --request POST \ + --url 'https://{extension_url}/roles' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'content-type: application/json' \ + --data '{ "name":"My new example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", "permissions":["{permission_id}"] }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "name":"Example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "permissions":[ + "bc6945e0-393a-4405-99d9-96903eaec4a1" + ], + "_id":"22787849-f39c-4165-814f-6996ad8e72a0" +} +``` + +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/roles", + "link": "#create-role" +}) %> + +Use this endpoint to create a role. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +create:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `name` | The new role's name | +| `description` | The new role's description | +| `applicationType` | The new role's application type | +| `applicationId` | The new role's application Id | +| `permissions` | A comma separated list of permissions (`{permission_id}`) for the new role | + +## Update Role + +
Examples
+ +```http +PUT https://{extension_url}/roles/{role_id} +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +{ + "name":"My new example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "permissions":[ + "{permission_id}" + ] +} +``` + +```shell +curl --request PUT \ + --url 'https://{extension_url}/roles/{role_id}' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'Content-Type: application/json' \ + --data '{ "name":"My new example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", "permissions":["{permission_id}"] }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "_id":"22787849-f39c-4165-814f-6996ad8e72a0", + "name":"My new example name", + "description":"Example description", + "applicationType":"client", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "permissions":[ + "deeb552d-2d98-4efb-bb84-0c8babe5f431" + ] +} +``` + +
+ PUT + /roles/{role_id} +
+ +Use this endpoint to update the details of a role. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{role_id}`
Required | The id of the role to update | +| `name` | The updated role name | +| `description` | The updated role description | +| `applicationType` | The updated application type | +| `applicationId` | The updated application Id | +| `permissions` | The updated list of permissions | + +## Delete Role + +
Examples
+ +```http +DELETE https://{extension_url}/roles/{role_id} +Authorization: 'Bearer {access_token}' +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/roles/{role_id}' \ + --header 'Authorization: Bearer {access_token}' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/roles/{role_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#delete-role" +}) %> + +Use this endpoint to remove a role. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +delete:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{role_id}`
Required | The id of the role to delete | \ No newline at end of file diff --git a/fr-ca/articles/api/authorization-extension/_users.md b/fr-ca/articles/api/authorization-extension/_users.md new file mode 100644 index 0000000000..a2337dd9f2 --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/_users.md @@ -0,0 +1,555 @@ +# Users + +These endpoints enable you to manage all the current users of your applications. You can retrieve their profile and edit or view their groups and their roles. + +For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension/v2#users). + +## Get all Users + +
Examples
+ +```http +GET https://{extension_url}/users +``` + +> RESPONSE SAMPLE: + +```text +{ + "start":0, + "limit":100, + "length":5, + "users":[ + { + "logins_count":12, + "identities":[ + { + "isSocial":false, + "user_id":"59091da1b3c34a15589c780d", + "provider":"auth0", + "connection":"Username-Password-Authentication" + } + ], + "user_id":"auth0|59091da1b3c34a15589c780d", + "last_login":"2017-06-25T07:28:54.719Z", + "name":"placeholder.user@example.com", + "picture":"https://s.gravatar.com/avatar/your-gravatar.png", + "email":"richard.dowinton@auth0.com" + } + ], + "total":1 +} +``` + +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": '/users', + "link": "#get-users" +}) %> + +Use this endpoint to retrieve all users. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{page}` | The page number. One-based. | +| `{per_page}` | The amount of entries per page. Default: `100`. Max value: `200`. | + +## Get a single User + +
Examples
+ +```http +GET https://{extension_url}/users/{user_id} +``` + +> RESPONSE SAMPLE: + +```text +{ + "email":"placeholder.user@example.com", + "email_verified":true, + "user_id":"auth0|59091da1b3c34a15589c780d", + "picture":"https://s.gravatar.com/avatar/your-gravatar.png", + "nickname":"placeholder.user", + "identities":[ + { + "user_id":"59091da1b3c34a15589c780d", + "provider":"auth0", + "connection":"Username-Password-Authentication", + "isSocial":false + } + ], + "updated_at":"2017-06-25T07:28:54.719Z", + "created_at":"2017-06-08T15:30:41.237Z", + "name":"placeholder.user@example.com", + "app_metadata":{ + "authorization":{ + "roles":[ + + ], + "permissions":[ + + ] + } + }, + "last_ip":"83.208.22.80", + "last_login":"2017-06-25T07:28:54.719Z", + "logins_count":12 +} +``` + +<% var path = '/users/{user_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-single-user" +}) %> + +Use this endpoint to get a single user based on its unique identifier. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user to retrieve. | + +## Get User Groups + +
Examples
+ +```http +GET https://{extension_url}/users/{user_id}/groups +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name":"Test", + "description":"Test" + }, + { + "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace", + "name":"Google", + "description":"Google" + } +] +``` + +<% var path = '/users/{user_id}/groups'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-user-groups" +}) %> + +Use this endpoint to get the groups of a single user, based on its unique identifier. Add "?expand" to also load all roles and permissions for these groups. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user to retrieve. | + +## Add User to Groups + +
Examples
+ +```http +PATCH https://{extension_url}/users/{user_id}/groups +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "{group_id}" ] +``` + +```shell +curl --request PATCH \ + --url 'https://{extension_url}/users/{user_id}/groups' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'Content-Type: application/json' \ + --data '[ "{group_id}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/users/{user_id}/groups'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "PATCH", + "path": path, + "link": "#add-user-to-groups" +}) %> + +Use this endpoint to add a user to one or more groups. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user that you want to add to groups | +| `{group_id}`
Required | The id of the group to which you want to add users | + +## Calculate Group Memberships + +
Examples
+ +```http +GET https://{extension_url}/users/{user_id}/groups/calculate +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f", + "name":"Test", + "description":"Test" + }, + { + "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace", + "name":"Google", + "description":"Google" + } +] +``` + +<% var path = '/users/{user_id}/groups/calculate'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#calculate-group-memberships" +}) %> + +Use this endpoint to calculate the group memberships for a user (including nested groups). + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:groups + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user for whom you want to calculate the group memberships | + +## Get User Roles + +
Examples
+ +```http +GET https://{extension_url}/users/{user_id}/roles +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761", + "name":"Test", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Test" + }, + { + "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692", + "name":"Example 2", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Example" + } +] +``` + +<% var path = '/users/{user_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#get-user-roles" +}) %> + +Use this endpoint to get the roles of a single user, based on its unique identifier. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user for whom you want to retrieve the roles | + +## Add User to Roles + +
Examples
+ +```http +PATCH https://{extension_url}/users/{user_id}/roles +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "{role_id}" ] +``` + +```shell +curl --request PATCH \ + --url 'https://{extension_url}/users/{user_id}/roles' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'Content-Type: application/json' \ + --data '[ "{role_id}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/users/{user_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-warning", + "http_method": "PATCH", + "path": path, + "link": "#add-user-to-roles" +}) %> + +Use this endpoint to assign a role to a user. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user that you want to assign to roles | +| `{role_id}`
Required | The id of the role to which you want to assign users | + +## Remove User from Roles + +
Examples
+ +```http +DELETE https://{extension_url}/users/{user_id}/roles +Content-Type: 'application/json' +Authorization: 'Bearer {access_token}' +[ "{role_id}" ] +``` + +```shell +curl --request DELETE \ + --url 'https://{extension_url}/users/{user_id}/roles' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'Content-Type: application/json' \ + --data '[ "{role_id}" ]' +``` + +> RESPONSE SAMPLE: + +```text +(empty response body) +``` + +<% var path = '/users/{user_id}/roles'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-danger", + "http_method": "DELETE", + "path": path, + "link": "#remove-user-from-role" +}) %> + +Use this endpoint to remove one or more user from a role. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +update:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user you want to remove from roles | +| `body`
Required | The id of the role(s) you want to remove users from (i.e. `[ "{role_id}" ]`) | + +## Calculate Roles + +
Examples
+ +```http +GET https://{extension_url}/users/{user_id}/roles/calculate +``` + +> RESPONSE SAMPLE: + +```text +[ + { + "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761", + "name":"Test", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Test" + }, + { + "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692", + "name":"Example 2", + "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", + "description":"Example" + } +] +``` + +<% var path = '/users/{user_id}/roles/calculate'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": path, + "link": "#calculate-roles" +}) %> + +Use this endpoint to calculate the roles assigned to the user (including through group memberships). + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:roles + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | The id of the user for whom you want to calculate the roles | + +## Execute Authorization Policy + +
Examples
+ +```http +``` + +```shell +curl --request POST \ + --url 'https://{extension_url}/users/{user_id}/policy/{client_id}' \ + --header 'Authorization: Bearer {access_token}' \ + --header 'content-type: application/json' \ + --data '{ "connectionName": "Username-Password-Database", "groups": [{group_id}] }' +``` + +> RESPONSE SAMPLE: + +```text +{ + "groups":[ + "New name", + "Google", + "My name" + ], + "permissions":[ + + ], + "roles":[ + "Test", + "Example 2" + ] +} +``` + +<% var path = '/users/{user_id}/policy/{client_id}'; %> +<%= +include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": path, + "link": "#execute-authz-policy" +}) %> + +Use this endpoint to execute the authorization policy for a user in the context of a client. This will return the user's groups but also roles and permissions that apply to the current client. + +### Scopes + +The [Access Token](#get-an-access-token) should have the following scopes: + +read:users + +### Parameters + +| Parameter | Description | +|:-----------------|:------------| +| `{extension_url}`
Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) | +| `{access_token}`
Required | The token your client retrieved from Auth0 to access the API. For more info, see [Get an Access Token](#get-an-access-token) | +| `{user_id}`
Required | | +| `{client_id}`
Required | | +| `connectionName`
Required | The name of the connection with which the user logged in | +| `groups` | List of group names received from the IdP (AD, ADFS, and so on) | diff --git a/fr-ca/articles/api/authorization-extension/index.md b/fr-ca/articles/api/authorization-extension/index.md new file mode 100644 index 0000000000..cc27f2407b --- /dev/null +++ b/fr-ca/articles/api/authorization-extension/index.md @@ -0,0 +1,32 @@ +--- +title: Authorization Extension API Explorer +fullWidth: true +topics: + - authorization + - apis + - api-authorization +contentType: + - reference + - index +useCase: invoke-api +--- + +
+ <%= include('./_introduction') %> +
+ +
+ <%= include('./_groups') %> +
+ +
+ <%= include('./_roles') %> +
+ +
+ <%= include('./_permissions') %> +
+ +
+ <%= include('./_users') %> +
diff --git a/fr-ca/articles/api/info.md b/fr-ca/articles/api/info.md new file mode 100644 index 0000000000..44920523b6 --- /dev/null +++ b/fr-ca/articles/api/info.md @@ -0,0 +1,99 @@ +--- +title: Auth0 APIs +description: Learn about Auth0's Management and Authentication APIs. +section: apis +crews: crew-2 +topics: + - management-api + - authorization-api + - apis +contentType: reference +useCase: invoke-api +--- +# Auth0 APIs + +Auth0 exposes the following APIs for developers to consume in their applications. + +## Authentication API + +The Authentication API exposes identity functionality for Auth0 and supported identity protocols (including OpenID Connect, OAuth, and SAML). + +Typically, you should consume this API through one of the Auth0 SDKs, such as [Auth0.js](/libraries/auth0js), or a library like [Lock](/libraries/lock). However, if you are building your authentication UI manually, you will need to call the Authentication API directly. + +Some example tasks include: + +* Get [tokens](/tokens) during authentication +* Request a user's profile using an [Access Token](/tokens/concepts/access-tokens) +* Exchange [Refresh Tokens](/tokens/concepts/refresh-tokens) for new Access Tokens +* Request a challenge for [multi-factor authentication (MFA)](/mfa) + +
+
+
+
+
+
+ +

API Explorer

+

Explore the requests and responses for Auth0 Authentication API endpoints in your browser.

+

Open API Explorer

+
+
+
+
+ +

Postman

+

Try the Auth0 Authentication API in Postman.

+

Run in Postman

+

How to use our Postman Collections

+
+
+
+
+
+
+ +## Management API + +The Management API allows you to manage your Auth0 account programmatically, so you can automate configuration of your environment. Most of the tasks you can perform in the Auth0 Management Dashboard can also be performed programmatically by using this API. + +Some example tasks include: + +* Register your applications and APIs with Auth0 +* Set up [connections](/connections) with which your users can authenticate +* [Manage users](/users) +* [Link user accounts](/users/guides/link-user-accounts) + +
+
+
+
+
+
+ +

API Explorer

+

Learn about and use the Auth0 Management API in the browser.

+

Open API Explorer

+
+
+
+
+ +

Postman

+

Try the Auth0 Management API in Postman.

+

Run in Postman

+

How to use our Postman Collections

+
+
+
+
+
+
+ +### Management API v1 has been deprecated + +The Management API v1 is deprecated and should not be used for new projects. + +Management API v1 will reach its End of Life on **July 13, 2020**. You may be required to take action before that date to ensure no interruption to your service. See [Migrate from Management API v1 to v2](/migrations/guides/management-api-v1-v2) for details. Notifications have been and will continue to be sent to customers that need to complete this migration. + +If your existing application still uses Management API v1, see [Management API v1](/api/management/v1) noting that some endpoints may have limited functionality. \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/apis/enable-rbac.md b/fr-ca/articles/api/management/guides/apis/enable-rbac.md new file mode 100644 index 0000000000..3c9258dbe9 --- /dev/null +++ b/fr-ca/articles/api/management/guides/apis/enable-rbac.md @@ -0,0 +1,58 @@ +--- +title: Enable Role-Based Access Control for APIs +description: Learn how to enable role-based access control (RBAC) for an API using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - roles + - rbac + - apis +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Enable Role-Based Access Control for APIs + +This guide will show you how to enable [role-based access control (RBAC)](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/apis/enable-rbac). This effectively enables the API Authorization Core feature set. + +1. Make a `PATCH` call to the [Update Resource Server endpoint](/api/management/v2#!/resource_servers/patch_resource_server). Be sure to replace `API_ID`, `MGMT_API_ACCESS_TOKEN`, `PERMISSION_NAME`, and `PERMISSION_DESC` placeholder values with your API ID, Management API Access Token, permission name(s), and permission description(s), respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/resource-servers/API_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"enforce_policies\": \"true\", \"token_dialect\": \"TOKEN_DIALECT\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `API_ID` | Τhe ID of the API for which you want to enable RBAC. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:resource_servers`. | +| `TOKEN_DIALECT` | Dialect of the Access Token for the specified API.| + +## Token Dialect Options + +Available options include: + +| Value | Description | +|-------|-------------| +| `access_token` | In the `scope` claim of the Access Token, includes an intersection of the requested permissions and the permissions assigned to the user. No `permissions` claim is passed. | +| `access_token_authz` | In the `scope` claim of the Access Token, includes an intersection of the requested permissions and the permissions assigned to the user. In the `permissions` claim of the Access Token, includes all permissions assigned to the user. Allows you to make minimal calls to retrieve permissions, but increases token size. | + +When RBAC is _disabled_, default behavior is observed; an application can request any permission defined for the API, and the `scope` claim will include all requested permissions. + +::: warning +Remember that any configured [rules](/authorization/concepts/authz-rules) run _after_ the RBAC-based authorization decisions are made, so they may override default behavior. +::: diff --git a/fr-ca/articles/api/management/guides/apis/update-permissions-apis.md b/fr-ca/articles/api/management/guides/apis/update-permissions-apis.md new file mode 100644 index 0000000000..7d39e4ca0c --- /dev/null +++ b/fr-ca/articles/api/management/guides/apis/update-permissions-apis.md @@ -0,0 +1,52 @@ +--- +title: Update API Permissions +description: Learn how to update permissions for APIs using the Auth0 Management API. +topics: + - authorization + - mgmt-api + - RBAC + - scopes + - permissions +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Update API Permissions + +This guide will show you how to update permissions for an API using Auth0's Management API. This task can also be performed using the Dashboard, but first you will need to [delete the permission](/dashboard/guides/apis/delete-permissions-apis) and then [add the permission](/dashboard/guides/roles/apis/add-permissions-apis) again. + +::: warning +By default, any user of any application can ask for any permission defined here. You can implement access policies to limit this behavior via [Rules](/rules). +::: + +::: note +Patching the permissions with an empty object removes the permissions completely. +::: + +1. Make a `PATCH` call to the [Update Resource Server endpoint](/api/management/v2#!/resource_servers/patch_resource_server). Be sure to replace `API_ID`, `MGMT_API_ACCESS_TOKEN`, `PERMISSION_NAME`, and `PERMISSION_DESC` placeholder values with your API ID, Management API Access Token, permission name(s), and permission description(s), respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/resource-servers/API_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"scopes\": [ { \"value\": \"PERMISSION_NAME\", \"description\": \"PERMISSION_DESC\" }, { \"value\": \"PERMISSION_NAME\", \"description\": \"PERMISSION_DESC\" } ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `API_ID` | Τhe ID of the API for which you want to add permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:resource_servers`. | +| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to add for the specified API. | +| `PERMISSION_DESC` | User-friendly description(s) of the permission(s) you would like to add for the specified API. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/applications/remove-app.md b/fr-ca/articles/api/management/guides/applications/remove-app.md new file mode 100644 index 0000000000..9e10014666 --- /dev/null +++ b/fr-ca/articles/api/management/guides/applications/remove-app.md @@ -0,0 +1,34 @@ +--- +title: Remove Application +description: Learn how to remove an Auth0-registered application using the Auth0 Management API. +toc: false +topics: + - applications + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app + - add-login + - call-api +--- +# Remove Application + +This guide will show you how to remove an application using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/remove-app). + +1. Make a `DELETE` call to the [Delete a Client endpoint](/api/management/v2#!/Clients/delete_clients_by_id). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| Value | Description | +| - | - | +| `YOUR_CLIENT_ID` | Τhe ID of the application to be deleted. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `delete:clients`. | diff --git a/fr-ca/articles/api/management/guides/applications/rotate-client-secret.md b/fr-ca/articles/api/management/guides/applications/rotate-client-secret.md new file mode 100644 index 0000000000..464308df41 --- /dev/null +++ b/fr-ca/articles/api/management/guides/applications/rotate-client-secret.md @@ -0,0 +1,42 @@ +--- +title: Rotate Client Secret +description: Learn how to change your application's client secret using the Auth0 Management API. +topics: + - applications + - client-secrets + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app +--- +# Rotate Client Secret + +This guide will show you how to change your application's client secret using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/rotate-client-secret). + +::: warning +New secrets may be delayed while rotating. To minimize downtime, we suggest you store the new client secret in your application's code as a fallback to the previous secret. This way, if the connection doesn't work with the old secret, your app will use the new secret. + +Secrets can be stored in a list (or similar structure) until they're no longer needed. Once you're sure that an old secret is obsolete, you can remove its value from your app's code. +::: + +1. Make a `POST` call to the [Rotate a Client Secret endpoint](/api/management/v2#!/Clients/post_rotate_secret). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID/rotate-secret", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| Value | Description | +| - | - | +| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:client_keys`. | + +2. Update authorized applications + +When you rotate a client secret, you must update any authorized applications with the new value. diff --git a/fr-ca/articles/api/management/guides/applications/update-grant-types.md b/fr-ca/articles/api/management/guides/applications/update-grant-types.md new file mode 100644 index 0000000000..febf502d5a --- /dev/null +++ b/fr-ca/articles/api/management/guides/applications/update-grant-types.md @@ -0,0 +1,51 @@ +--- +title: Update Grant Types +description: Learn how to update an application's grant types using Auth0's Management API. +topics: + - applications + - grant-types + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app +--- +# Update Grant Types + +This guide will show you how to change your application's grant types using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/update-grant-types). + +::: warning +As of 8 June 2017, new Auth0 customers **cannot** add legacy grant types to their Applications. Customers as of 8 June 2017 can add legacy grant types to only their existing Applications. +::: + +::: warning +Attempting to use a flow with an Application lacking the appropriate `grant_types` for that flow (or with the field empty) will result in the following error: + +```text +Grant type `grant_type` not allowed for the client. +``` +::: + +1. Make a `PATCH` call to the [Update a Client endpoint](/api/management/v2#!/Clients/patch_clients_by_id). Be sure to replace `YOUR_CLIENT_ID`, `MGMT_API_ACCESS_TOKEN`, and `GRANT_TYPE` placeholder values with your client ID, Management API Access Token, and desired grant type, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"grant_types\": \"GRANT_TYPES\" }" + } +} +``` + +| Value | Description | +| - | - | +| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:clients`. | +| `GRANT_TYPES` | The grant types you would like to enable for the specified application. | diff --git a/fr-ca/articles/api/management/guides/applications/update-ownership.md b/fr-ca/articles/api/management/guides/applications/update-ownership.md new file mode 100644 index 0000000000..bbe9d019bf --- /dev/null +++ b/fr-ca/articles/api/management/guides/applications/update-ownership.md @@ -0,0 +1,40 @@ +--- +title: Update Application Ownership +description: Learn how to update application ownership using the Auth0 Management API. This will let you specify whether an application is registered with Auth0 as a first-party or third-party application. +toc: true +topics: + - applications + - application-types + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app +--- +# Update Application Ownership + +This guide will show you how to use Auth0's Management API to update application ownership, which allows you to specify whether an application is registered with Auth0 as a first-party or third-party application. + +Make a `PATCH` call to the [Update a Client endpoint](/api/management/v2#!/Clients/patch_clients_by_id). Be sure to replace `YOUR_CLIENT_ID`,`MGMT_API_ACCESS_TOKEN`, and `OWNERSHIP_BOOLEAN` placeholder values with your client ID, Management API Access Token, and boolean representing the application's ownership, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"is_first_party\": \"OWNERSHIP_BOOLEAN\" }" + } +} +``` + +| Value | Description | +| - | - | +| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:clients`. | +| `OWNERSHIP_BOOLEAN` | The ownership you would like to specify for the application. If the application is first-party, `is_first_party` should have a value of `true`. If the application is third-party, `is_first_party` should have a value of `false`. | diff --git a/fr-ca/articles/api/management/guides/applications/view-ownership.md b/fr-ca/articles/api/management/guides/applications/view-ownership.md new file mode 100644 index 0000000000..58d736a93a --- /dev/null +++ b/fr-ca/articles/api/management/guides/applications/view-ownership.md @@ -0,0 +1,35 @@ +--- +title: View Application Ownership +description: Learn how to check whether an application is registered with Auth0 as a first-party or third-party app using the Auth0 Management API. +toc: true +topics: + - applications + - application-types + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app +--- +# View Application Ownership + +This guide will show you how to use Auth0's Management API to check whether an application is registered with Auth0 as a first-party or third-party application. + +1. Make a `GET` call to the [Get a Client endpoint](/api/management/v2#!/Clients/get_clients_by_id). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID?fields=is_first_party&include_fields=true", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| Value | Description | +| - | - | +| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `read:clients`. | + +If the application is first-party, the `is_first_party` field will have a value of `true`. If the application is third-party, the `is_first_party` field will have a value of `false`. diff --git a/fr-ca/articles/api/management/guides/connections/configure-connection-sync.md b/fr-ca/articles/api/management/guides/connections/configure-connection-sync.md new file mode 100644 index 0000000000..c3343c830c --- /dev/null +++ b/fr-ca/articles/api/management/guides/connections/configure-connection-sync.md @@ -0,0 +1,46 @@ +--- +title: Configure Connection Sync with Auth0 +description: Learn how to update connection preferences for an upstream identity provider to control when updates to user profile root attributes will be allowed using the Auth0 Management API. +topics: + - connections + - identity-providers + - user-profile + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app + - customize-connections + - manage-users +--- +# Configure Connection Sync with Auth0 + +This guide will show you how to update connection preferences for an upstream [Identity Provider](/connections) to control when updates to user profile root attributes will be allowed using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/connections/configure-connection-sync). + +::: warning +Before completing this step, you should first [retrieve the existing values of the connection's `options` object](/api/management/guides/connections/retrieve-connection-options) to avoid overriding the current values. If you do not, any missing parameters from the original object will be lost after you update. +::: + +1. Make a `PATCH` call to the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). Make sure you include the original options values in the call to avoid overriding the current values. Also, be sure to replace `CONNECTION_ID`, `MGMT_API_ACCESS_TOKEN`, and `ATTRIBUTE_UPDATE_VALUE` placeholder values with your connection ID, Management API Access Token, and attribute update value, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{\"options\":{\"set_user_root_attributes\": \"ATTRIBUTE_UPDATE_VALUE\"}}" + } +} +``` + +| Value | Description | +| - | - | +| `CONNECTION_ID` | ID of the connection for which you want to allow updates to root attributes. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:connections`. | +| `ATTRIBUTE_UPDATE_VALUE` | Indicates when you want to allow updates to user profile root attributes. Valid values are `on_first_login` and `on_each_login`. Defaults to `on_each_login` for new connections. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/connections/promote-connection-domain-level.md b/fr-ca/articles/api/management/guides/connections/promote-connection-domain-level.md new file mode 100644 index 0000000000..50c1c6f4bc --- /dev/null +++ b/fr-ca/articles/api/management/guides/connections/promote-connection-domain-level.md @@ -0,0 +1,39 @@ +--- +title: Promote Connection to Domain Level +description: Learn how to promote a connection to domain level using the Auth0 Management API. +topics: + - connections + - third-party-app + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Promote Connection to Domain Level + +This guide will show you how to promote connections to domain level using Auth0's Management API. + +1. Make a `PATCH` call to the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). Be sure to replace `CONNECTION_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your connection ID and Management API Access Token, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"is_domain_connection\": true }" + } +} +``` + +| Value | Description | +| - | - | +| `CONNECTION_ID` | Τhe ID of the connection to be promoted. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:connections`. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/connections/retrieve-connection-options.md b/fr-ca/articles/api/management/guides/connections/retrieve-connection-options.md new file mode 100644 index 0000000000..1d62b08e31 --- /dev/null +++ b/fr-ca/articles/api/management/guides/connections/retrieve-connection-options.md @@ -0,0 +1,32 @@ +--- +title: Retrieve Connection Options +description: Learn how to retrieve the options object for a connection using the Auth0 Management API. +topics: + - connections + - mgmt-api +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Retrieve Connection Options + +This guide will show you how to retrieve the options object for a [connection](/connections) using Auth0's Management API. + +1. Make a `GET` call to the [Get Connection endpoint](/api/management/v2#!/Connections/get_connections_by_id). Be sure to replace `CONNECTION_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your connection ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION-ID?fields=options", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| Value | Description | +| - | - | +| `CONNECTION_ID` | Τhe ID of the connection for which you want to retrieve the `options` object. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:connections`. | diff --git a/fr-ca/articles/api/management/guides/roles/add-permissions-roles.md b/fr-ca/articles/api/management/guides/roles/add-permissions-roles.md new file mode 100644 index 0000000000..5c9ce675be --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/add-permissions-roles.md @@ -0,0 +1,45 @@ +--- +title: Add Permissions to Roles +description: Learn how to add permissions to roles for Auth0's API Authorization Core feature using the Auth0 Management API. +topics: + - authorization + - mgmt-api + - roles + - permissions +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Add Permissions to Roles + +This guide will show you how to add permissions to [roles](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/add-permissions-roles). The roles and their permissions can be used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `POST` call to the [Add Role Permissions endpoint](/api/management/v2#!/Roles/post_role_permission_assignment). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `API_IDENTIFIER`, and `PERMISSION_NAME` placeholder values with your role ID, Management API Access Token, API identifier (audience), and permission name(s), respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" } ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role for which you want to add permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. | +| `API_IDENTIFIER` | This is the identifier of the API associated with the permission(s) you would like to add for the specified role, otherwise known as the audience. This is not the API ID. | +| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to add for the specified role. | diff --git a/fr-ca/articles/api/management/guides/roles/create-roles.md b/fr-ca/articles/api/management/guides/roles/create-roles.md new file mode 100644 index 0000000000..3208506c22 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/create-roles.md @@ -0,0 +1,44 @@ +--- +title: Create Roles +description: Learn how to create a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - roles + - rbac +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Create Roles + +This guide will show you how to create [roles](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/create-roles). The roles can be used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `POST` call to the [Create Role endpoint](/api/management/v2#!/Roles/post_roles). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `ROLE_NAME`, and `ROLE_DESC` placeholder values with your Management API Access Token, role name, and role description, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/roles", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"name\": \"ROLE_NAME\", \"description\": \"ROLE_DESC\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:roles`. | +| `ROLE_NAME` | Name of the role you would like to create. | +| `ROLE_DESC` | User-friendly description of the role. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/roles/delete-roles.md b/fr-ca/articles/api/management/guides/roles/delete-roles.md new file mode 100644 index 0000000000..28396f3025 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/delete-roles.md @@ -0,0 +1,37 @@ +--- +title: Delete Roles +description: Learn how to delete a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Delete Roles + +This guide will show you how to delete a [role](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/delete-roles). Roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `DELETE` call to the [Delete Role endpoint](/api/management/v2#!/Roles/delete_roles_by_id). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role you want to delete. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `delete:roles`. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/roles/edit-role-definitions.md b/fr-ca/articles/api/management/guides/roles/edit-role-definitions.md new file mode 100644 index 0000000000..676490c389 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/edit-role-definitions.md @@ -0,0 +1,45 @@ +--- +title: Edit Role Definitions +description: Learn how to edit a role definition using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Edit Role Definitions + +This guide will show you how to edit a [role](/authorization/concepts/rbac) definition using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/edit-role-definitions). Roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `PATCH` call to the [Update Role endpoint](/api/management/v2#!/Roles/patch_roles_by_id). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `ROLE_NAME`, and `ROLE_DESC` placeholder values with your role ID, Management API Access Token, role name, and role description, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"name\": \"ROLE_NAME\", \"description\": \"ROLE_DESC\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role for which you want to edit the definition. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. | +| `ROLE_NAME` | Name of the role. | +| `ROLE_DESC` | User-friendly description of the role. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/roles/remove-role-permissions.md b/fr-ca/articles/api/management/guides/roles/remove-role-permissions.md new file mode 100644 index 0000000000..1bb761e434 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/remove-role-permissions.md @@ -0,0 +1,45 @@ +--- +title: Remove Permissions from Roles +description: Learn how to remove permissions added to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Remove Permissions from Roles + +This guide will show you how to remove the [permissions](/authorization/concepts/rbac) assigned to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/remove-role-permissions). The assigned permissions and roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `DELETE` call to the [Delete Role Permissions endpoint](/api/management/v2#!/Roles/delete_role_permission_assignment). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `API_ID`, and `PERMISSION_NAME` placeholder values with your role ID, Management API Access Token, API ID(s), and permission name(s), respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" } ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role for which you want to remove permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. | +| `API_ID` | ID(s) of the API(s) associated with the permission(s) you would like to remove for the specified role. | +| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to remove for the specified role. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/roles/view-role-permissions.md b/fr-ca/articles/api/management/guides/roles/view-role-permissions.md new file mode 100644 index 0000000000..86a3aec456 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/view-role-permissions.md @@ -0,0 +1,37 @@ +--- +Title: View Role Permissions +description: Learn how to view permissions added to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View Role Permissions + +This guide will show you how to view the [permissions](/authorization/concepts/rbac) added to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/view-role-permissions). The added permissions and roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `GET` call to the [Get Role Permissions endpoint](/api/management/v2#!/Roles/get_role_permission). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role for which you want to get permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:roles`. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/roles/view-role-users.md b/fr-ca/articles/api/management/guides/roles/view-role-users.md new file mode 100644 index 0000000000..8c68a6c5e4 --- /dev/null +++ b/fr-ca/articles/api/management/guides/roles/view-role-users.md @@ -0,0 +1,38 @@ +--- +title: View Role Users +description: Learn how to view users assigned to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - permissions + - roles + - users +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View Role Users + +This guide will show you how to view the users assigned to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/view-role-users). Roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `GET` call to the [Get Role Users endpoint](/api/management/v2#!/Roles/get_role_user). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/roles/ROLE_ID/users", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `ROLE_ID` | Τhe ID of the role for which you want to get users. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:users` and `read:roles`. | diff --git a/fr-ca/articles/api/management/guides/rules/create-rules.md b/fr-ca/articles/api/management/guides/rules/create-rules.md new file mode 100644 index 0000000000..0e102f32c0 --- /dev/null +++ b/fr-ca/articles/api/management/guides/rules/create-rules.md @@ -0,0 +1,43 @@ +--- +title: Create Rules +description: Learn how to create a rule using the Auth0 Management API. You can use rules to customize and extend Auth0's capabilities. +topics: + - mgmt-api + - rules + - extensibility +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Create Rules + +This guide will show you how to create [rules](/rules) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/rules/create-rules). + +1. Make a `POST` call to the [Create Rule endpoint](/api/management/v2#!/Rules/post_rules). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `RULE_NAME`, `RULE_SCRIPT`, `RULE_ORDER`, and `RULE_ENABLED` placeholder values with your Management API Access Token, rule name, rule script, rule order number, and rule enabled value, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/rules", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"name\": \"RULE_NAME\", \"script\": \"RULE_SCRIPT\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:rules`. | +| `RULE_NAME` | Name of the rule you would like to create. The rule name can only contain alphanumeric characters, spaces, and hyphens; it may not start or end with spaces or hyphens. | +| `RULE_SCRIPT` | Script that contains the code for the rule. Should match what you would enter if you were [creating a new rule using the Dashboard](/dashboard/guides/rules/create-rules). | +| `RULE_ORDER` (optional) | Integer that represents the order in which the rule should be executed in relation to other rules. Rules with lower numbers are executed before rules with higher numbers. If no order number is provided, the rule will execute last. +| `RULE_ENABLED` (optional) | Boolean that represents whether the rules is enabled (`true`) or disabled (`false`). | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/tenants/configure-session-lifetime-settings.md b/fr-ca/articles/api/management/guides/tenants/configure-session-lifetime-settings.md new file mode 100644 index 0000000000..2e4421e585 --- /dev/null +++ b/fr-ca/articles/api/management/guides/tenants/configure-session-lifetime-settings.md @@ -0,0 +1,42 @@ +--- +title: Configure Session Lifetime Settings +description: Learn how to configure session lengths and limits for a tenant using the Auth0 Management API. +topics: + - idle-timeout + - absolute-timeout + - session-lifetime-limits + - dashboard +contentType: + - how-to +useCase: + - integrate-saas-sso + - configure-sso + - build-an-app +--- +# Configure Session Lifetime Settings + +This guide will show you how to configure session settings for your tenant using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/tenants/configure-session-lifetime-settings). + +1. Make a `PATCH` call to the [Tenant Settings endpoint](/api/management/v2#!/tenants/patch_settings). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `SESSION_LIFETIME`, and `IDLE_SESSION_LIFETIME` placeholder values with your Management API Access Token, session lifetime value, and idle session lifetime value, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/tenants/settings", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"session_lifetime\": SESSION_LIFETIME_VALUE, \"idle_session_lifetime\": IDLE_SESSION_LIFETIME_VALUE }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:tenant_settings`. | +| `IDLE_SESSION_LIFETIME_VALUE` | Timeframe (in hours) after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 72 hours (3 days) for Developer or Developer Pro or 2,400 hours (100 days) for enterprise plans. | +| `SESSION_LIFETIME_VALUE` | Timeframe (in hours) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 720 hours (30 days) for Developer or Developer Pro or 8,760 hours (365 days) for enterprise plans. | diff --git a/fr-ca/articles/api/management/guides/users/assign-permissions-users.md b/fr-ca/articles/api/management/guides/users/assign-permissions-users.md new file mode 100644 index 0000000000..1bca553a35 --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/assign-permissions-users.md @@ -0,0 +1,50 @@ +--- +title: Assign Permissions to Users +description: Learn how to assign permissions to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Assign Permissions to Users + +This guide will show you how to assign [permissions](/authorization/concepts/rbac) to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/assign-permissions-users). The assigned permissions can be used with the API Authorization Core feature set. + +::: note +Adding permissions directly to a user circumvents the benefits of [role-based access control (RBAC)](/authorization/concepts/rbac) and is not typically recommended. +::: + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `POST` call to the [Assign User Permissions endpoint](/api/management/v2#!/Users/post_permissions). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `API_IDENTIFIER`, and `PERMISSION_NAME` placeholder values with your user ID, Management API Access Token, API Identifier(s), and permission name(s), respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/users/USER_ID/permissions", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" } ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user for whom you want to assign permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. | +| `API_IDENTIFIER` | Identifier(s) of the API(s) associated with the permission(s) you would like to assign for the specified user. | +| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to assign for the specified user. | diff --git a/fr-ca/articles/api/management/guides/users/assign-roles-users.md b/fr-ca/articles/api/management/guides/users/assign-roles-users.md new file mode 100644 index 0000000000..12b652a0d7 --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/assign-roles-users.md @@ -0,0 +1,45 @@ +--- +title: Assign Roles to Users +description: Learn how to assign roles to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - roles + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Assign Roles to Users + +This guide will show you how to assign [roles](/authorization/concepts/rbac) to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/assign-roles-users). The assigned roles can be used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `POST` call to the [Assign User Roles endpoint](/api/management/v2#!/Users/post_user_roles). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, and `ROLE_ID` placeholder values with your user ID, Management API Access Token, and role ID(s), respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/users/USER_ID/roles", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"roles\": [ \"ROLE_ID\", \"ROLE_ID\" ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:roles` and `update:users`. | +| `ROLE_ID` | ID(s) of the role(s) you would like to add for the specified user. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/users/remove-user-permissions.md b/fr-ca/articles/api/management/guides/users/remove-user-permissions.md new file mode 100644 index 0000000000..1cdf1f4c6d --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/remove-user-permissions.md @@ -0,0 +1,46 @@ +--- +title: Remove Permissions from Users +description: Learn how to remove permissions directly assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Remove Permissions from Users + +This guide will show you how to remove the [permissions](/authorization/concepts/rbac) directly assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/remove-user-permissions). The assigned permissions are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `DELETE` call to the [Delete User Permissions endpoint](/api/management/v2#!/Users/delete_permissions). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `API_ID`, and `PERMISSION_NAME` placeholder values with your user ID, Management API Access Token, API ID(s), and permission name(s), respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/users/USER_ID/permissions", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" } ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. | +| `API_ID` | ID(s) of the API(s) associated with the permission(s) you would like to remove for the specified user. | +| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to remove for the specified user. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/users/remove-user-roles.md b/fr-ca/articles/api/management/guides/users/remove-user-roles.md new file mode 100644 index 0000000000..10e60f99fe --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/remove-user-roles.md @@ -0,0 +1,45 @@ +--- +title: Remove Roles from Users +description: Learn how to remove the roles assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles + - users +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Remove Roles from Users + +This guide will show you how to remove the [roles](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed using the Dashboard by either [removing users from a role](/dashboard/guides/users/remove-role-users) or [removing roles from a user](/dashboard/guides/users/remove-user-roles). Roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `DELETE` call to the [Delete User Roles endpoint](/api/management/v2#!/Users/delete_user_roles). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, and `ROLE_ID` placeholder values with your user ID, Management API Access Token, and role ID(s), respectively. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/users/USER_ID/roles", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"roles\": [ \"ROLE_ID\", \"ROLE_ID\" ] }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. | +| `ROLE_ID` | ID(s) of the role(s) you would like to remove for the specified user. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/users/set-root-attributes-user-import.md b/fr-ca/articles/api/management/guides/users/set-root-attributes-user-import.md new file mode 100644 index 0000000000..ac6df80bdd --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/set-root-attributes-user-import.md @@ -0,0 +1,40 @@ +--- +title: Set Root Attributes During User Import +description: Learn how to set root attributes for users during import using the Auth0 Management API. +topics: + - mgmt-api + - root-attributes + - users + - user-profile + - user-import +contentType: + - how-to +useCase: + - manage-users +--- +# Set Root Attributes During User Import + +This guide will show you how to set root attributes for a user during import using Auth0's Management API. This allows you to minimize the number of API calls required to set root attributes when importing users. To see which attributes you can import, visit [Normalized User Profile Structure](/users/references/user-profile-structure). + +1. Make a `POST` call to the [Create Job to Import Users endpoint](/api/management/v2#!/Jobs/post_users_imports). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CONNECTION_ID`, and `JSON_USER_FILE_PATH` placeholder values with your Management API Access Token, connection ID, and users filename, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/jobs/usersimports", + "headers": [ + { "name": "Content-Type", "value": "multipart/form-data " }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ], + "postData": { + "mimetype": "multipart/form-data", + "text": "{ \"connection_id\": \"CONNECTION_ID\", \"users\": \"JSON_USER_FILE_PATH\" }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:users`. | +| `CONNECTION_ID` | ID of the connection to which the users will be inserted. You can retrieve this info using the [Get All Connections endpoint](/api/management/v2#!/Connections/get_connections). | +| `JSON_USER_FILE_PATH` | Filename of the file that contains the users to be imported. File should be in JSON format and include root attributes for users. For a list of available attributes, see [User Profile Attributes](/users/references/user-profile-structure#attributes). For an example of the file format, see [Bulk User Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples). | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/users/set-root-attributes-user-signup.md b/fr-ca/articles/api/management/guides/users/set-root-attributes-user-signup.md new file mode 100644 index 0000000000..7eebeb41e9 --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/set-root-attributes-user-signup.md @@ -0,0 +1,53 @@ +--- +title: Set Root Attributes During User Sign-Up +description: Learn how to set root attributes for users during sign-up using the Auth0 Management API. +topics: + - mgmt-api + - root-attributes + - users + - user-profile + - user-signup +contentType: + - how-to +useCase: + - build-an-app + - add-login + - manage-users +--- +# Set Root Attributes During User Sign-Up + +This guide will show you how to set root attributes for a user during sign-up using Auth0's Management API. This allows you to minimize the number of API calls required to set root attributes when creating users. + +1. Make a `POST` call to the [Create a User endpoint](/api/management/v2#!/Users/post_users). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CONNECTION_NAME`, `EMAIL_VALUE`, `PASSWORD_VALUE`, `GIVEN_NAME_VALUE`, `FAMILY_NAME_VALUE`, `NAME_VALUE`, `NICKNAME_VALUE`, and `PICTURE` placeholder values with your Management API Access Token, initial connection name, email address, password, given name, family name, name, nickname, and picture URL, respectively. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/users", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"connection\": CONNECTION_NAME, \"email\": EMAIL_VALUE, \"password\": PASSWORD_VALUE, \"given_name\": GIVEN_NAME_VALUE, \"family_name\": FAMILY_NAME_VALUE,\"name\": NAME_VALUE, \"nickname\": NICKNAME_VALUE,\"picture\": PICTURE_VALUE }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:users`. | +| `CONNECTION_NAME` | Name of the connection through which the initial user information was received. | +| `EMAIL_VALUE` | Email address of the user to be created. | +| `PASSWORD_VALUE` | Password of the user to be created. | +| `GIVEN_NAME_VALUE` | Given name of the user to be created. | +| `FAMILY_NAME_VALUE` | Family name of the user to be created. | +| `NAME_VALUE` | Full name of the user to be created. | +| `NICKNAME_VALUE` | Nickname of the user to be created. | +| `PICTURE_VALUE` | URL of the picture for the user to be created. | + +::: note +If you are using Lock or the [public signup endpoint](/api/authentication#signup) for user sign-up, you can set root attributes using the same method. +::: diff --git a/fr-ca/articles/api/management/guides/users/update-root-attributes-users.md b/fr-ca/articles/api/management/guides/users/update-root-attributes-users.md new file mode 100644 index 0000000000..97be3eabfd --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/update-root-attributes-users.md @@ -0,0 +1,52 @@ +--- +title: Update Root Attributes for Users +description: Learn how to update root attributes in existing user profiles using the Auth0 Management API. +topics: + - mgmt-api + - root-attributes + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - add-login + - manage-users +--- +# Update Root Attributes for Users + +This guide will show you how to update root attributes for an existing user profile using Auth0's Management API. + +Auth0's [Normalized User Profile](/users/references/user-profile-structure) features [root attributes](/users/references/user-profile-structure#user-profile-attributes) that you can update. The specific root attributes that you can update depend on the [connection](/identityproviders) type you're using. For details relevant to the connection you are using, see [Updating User Profile Root Attributes](/users/normalized/auth0/update-root-attributes). + +1. Make a `PATCH` call to the [Update a User endpoint](/api/management/v2#!/Users/patch_users_by_id). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `GIVEN_NAME_VALUE`, `FAMILY_NAME_VALUE`, `NAME_VALUE`, `NICKNAME_VALUE`, and `PICTURE` placeholder values with your user ID, Management API Access Token, given name, family name, name, nickname, and picture URL, respectively. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }, + { "name": "Cache-Control", "value": "no-cache" } + ], + "postData": { + "mimeType": "application/json", + "text" : "{ \"given_name\": GIVEN_NAME_VALUE, \"family_name\": FAMILY_NAME_VALUE,\"name\": NAME_VALUE, \"nickname\": NICKNAME_VALUE,\"picture\": PICTURE_VALUE }" + } +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user to be updated. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. | +| `GIVEN_NAME_VALUE` | Given name of the user to be updated. | +| `FAMILY_NAME_VALUE` | Family name of the user to be updated. | +| `NAME_VALUE` | Full name of the user to be updated. | +| `NICKNAME_VALUE` | Nickname of the user to be updated. | +| `PICTURE_VALUE` | URL of the picture for the user to be updated. | + +## Removing attributes + +Setting any value to `null` will remove the attribute for the user. diff --git a/fr-ca/articles/api/management/guides/users/view-user-permissions.md b/fr-ca/articles/api/management/guides/users/view-user-permissions.md new file mode 100644 index 0000000000..f24b5c02d7 --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/view-user-permissions.md @@ -0,0 +1,38 @@ +--- +title: View Permissions Assigned to Users +description: Learn how to view permissions assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View Permissions Assigned to Users + +This guide will show you how to view the [permissions](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/view-user-permissions). The assigned permissions are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `GET` call to the [Get User Permissions endpoint](/api/management/v2#!/Users/get_permissions). Be sure to replace `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your user ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/USER_ID/permissions", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user for whom you want to get permissions. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:users`. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/guides/users/view-user-roles.md b/fr-ca/articles/api/management/guides/users/view-user-roles.md new file mode 100644 index 0000000000..af6fb61d60 --- /dev/null +++ b/fr-ca/articles/api/management/guides/users/view-user-roles.md @@ -0,0 +1,39 @@ +--- +title: View Roles Assigned to Users +description: Learn how to view roles assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - mgmt-api + - permissions + - roles + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View Roles Assigned to Users + +This guide will show you how to view the [roles](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/view-user-roles). The assigned roles are used with the API Authorization Core feature set. + +<%= include('../../../../authorization/_includes/_enable-authz-core') %> + +1. Make a `GET` call to the [Get User Roles endpoint](/api/management/v2#!/Users/get_user_roles). Be sure to replace `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your user ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/USER_ID/roles", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `USER_ID` | Τhe ID of the user for whom you want to get roles. | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:users` and `read:roles`. | \ No newline at end of file diff --git a/fr-ca/articles/api/management/v1/index.md b/fr-ca/articles/api/management/v1/index.md new file mode 100644 index 0000000000..e0673851e7 --- /dev/null +++ b/fr-ca/articles/api/management/v1/index.md @@ -0,0 +1,909 @@ +--- +description: An overview of the Auth0 Management API v1 which has been deprecated. +topics: + - apis + - management-api +contentType: + - reference + - index +useCase: invoke-api +--- + +# Management API v1 (deprecated) + +<%= include('../../../_includes/_version_warning_api') %> + +## Authentication + +
+
POST /oauth/token
+
Obtain a token to call the API
+
+ +Auth0 API requires an Access Token. You can get one by authenticating with your `client_id` and `client_secret` (It will be valid for 24 hours). To obtain the global client ID and global client secret see the **Advanced** tab under [Tenant Settings](${manage_url}/#/tenant/advanced) in the Auth0 dashboard. + +```text +POST /oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET +``` + +Once authenticated, the Access Token can be included in the request as part of the query string ( `?access_token=...`) or in an HTTP header (`Authorization: Bearer ...access_token...`). + + +## Users +
+
GET /api/users
+
Gets all users who have logged in
+
+ +Gets all users who have logged in through any of your connections. + +```text +GET /api/users +Authorization: Bearer {token} +``` + +
+
GET /api/users?search={query}
+
Search users
+
+ +Performs a 'starts with' search by name or email. Or search by field, for example: email_verified:true; loginsCount:1; family_name:"johnson" + +```text +GET /api/users?search={query} +Authorization: Bearer {token} +``` + +
+
GET /api/users/{user_id}
+
Gets an user by id
+
+ +Gets a user who has logged in through any of your connections that has a given id. + +```text +GET /api/users/{user_id} +Authorization: Bearer {token} +``` + +
+
GET /api/connections/{connection}/users
+
Gets all users from an enterprise directory
+
+ +Head ups! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection. + +```text +GET /api/connections/{connection}/users +Authorization: Bearer {token} +``` + +
+
GET /api/connections/{connection}/users?search={criteria}
+
Search users from an enterprise directories
+
+ +**Search** remarks: Depending on the connection's type the search will be done in different fields: +* Active Directory/LDAP: by default uses ambiguous name resolution ([ANR](http://technet.microsoft.com/en-us/library/cc755809(v=ws.10).aspx)) which expands to givenName (first name), sn (surname, or last name), displayName, RDN, legacyExchangeDN, physicalDeliveryOfficeName (for example, Building A, Suite 1234), proxyAddresses (the collection of email addresses over all email address spaces that the Exchange server knows about). +* Database Connections (not custom): Name/Email case insensitive. +* G Suite: Email/username case insensitive. +* WAAD/WAAD2: Name/Email case insensitive. +* Windows Azure Active Directory or Office365: name/email case insensitive +Heads up! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection. + +```text +GET /api/connections/{connection}/users?search={query}&per_page={count} +Authorization: Bearer {token} +``` + +
+
GET /api/enterpriseconnections/users?search={criteria}
+
Search users from all enterprise directories
+
+ +Search users from all enterprise directories based on the specified `criteria`. The parameter is mandatory. +**Search** remarks: Depending on the connection's type the search will be done in different fields: +* Active Directory/LDAP: by default uses ambiguous name resolution ([ANR](http://technet.microsoft.com/en-us/library/cc755809(v=ws.10).aspx)) which expands to givenName (first name), sn (surname, or last name), displayName, RDN, legacyExchangeDN, physicalDeliveryOfficeName (for example, Building A, Suite 1234), proxyAddresses (the collection of email addresses over all email address spaces that the Exchange server knows about). +* Database Connections (not custom): Name/Email case insensitive. +* G Suite: Email/username case insensitive. +* WAAD/WAAD2: Name/Email case insensitive. +* Windows Azure Active Directory or Office365: name/email case insensitive +Heads up! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection. + +```text +GET /api/enterpriseconnections/users?search=&per_page= +Authorization: Bearer {token} +``` + +
+
GET /api/socialconnections/users?search={criteria}
+
Gets all users who have logged in with social connections that match the search criteria
+
+ + +Gets all users who have logged in through social connections that match the specified search `criteria`. +Performs a 'starts with' search by name or email. Or searches by field, for example: email_verified:true; loginsCount:1; family_name:"johnson" + +```text +GET /api/socialconnections/users?search=&per_page= +Authorization: Bearer {token} +``` + +
+
GET /api/clients/{client-id}/users
+
Gets all users from a specific application
+
+ +Gets all users who have logged in with a specific application + +```text +GET /api/clients/users +Authorization: Bearer {token} +``` + +
+
POST /api/users
+
Creates a user
+
+ +Creates a user. The body of the request must include the `email`, the `password`, and the `connection` of the user. Also it can include the user's `email_verified` parameter and the `extra attributes` that you want to add. + +```text +POST /api/users/ +Authorization: Bearer {token} +Content-Type: application/json +{ + "email": "", + "password": "", + "connection": "", // only database or passwordless connections + "email_verified": falsetrue, // if true, it won't send an email for confirmation + "vip": true, + "birthdate": "1980-12-23T03:00:00.000Z" +} +``` + +
+
POST /api/users/{user_id}/send_verification_email
+
Resends verification account email
+
+Resends verification account email. + +```text +POST /api/users//`send_verification_email` +Authorization: Bearer {token} +``` + +
+
POST /api/users/{user_id}/change_password_ticket
+
Generates change password ticket
+
+ +Generates change password ticket. The body of the request must include the `newPassword` of the user. Optionally, you can include the `resultUrl` (post verification url). + +```text +POST /api/users/{user_id}/change_password_ticket +Authorization: Bearer {token} +Content-Type: application/json +{ + "newPassword": "", + "resultUrl": "" // optional +} +``` +
+
POST /api/users/{user_id}/verification_ticket
+
Generates verification account ticket
+
+ +Generates verification account ticket. Optionally, you can include the `resultUrl` (post verification url) in the body of the request. + +```text +POST /api/users/{user_id}/verification_ticket +Authorization: Bearer {token} +Content-Type: application/json +{ + "resultUrl": "" // optional +} +``` + +
+
POST /api/users/{user_id}/publickey
+
Saves user public key for specified device
+
+ +Saves user public key for specified device. + +```text +POST /api/users//publickey +Authorization: Bearer {token} +Content-Type: application/json +{ + "device": "", + "public_key": "" +} +``` + +
+
PUT /api/users/{user_id}/email
+
Updates user email
+
+ +Update user email. The body of the request must include the new `email`. + +```text +PUT /api/users/{user_id}/email +Authorization: Bearer {token} +Content-Type: application/json +{ + "email": "", + "verify": truefalse // if false, it won't send an email for verification +} +``` + +
+
PUT /api/users/{user_id}/metadata
+
Updates user metadata
+
+ +Update user metadata. The body of the request must include a `json` object with metadata `attributes`. + +```text +PUT /api/users/{user_id}/metadata +Authorization: Bearer {token} +Content-Type: application/json +{ + "Policy": "1238907654", + "Customer Id": "1234" +} +``` + +
+
PUT /api/users/{user_id}/password
+
Updates user password
+
+ +Update user password. The body of the request must include the new `password`. + +```text +PUT /api/users/{user_id}/password +Authorization: Bearer {token} +Content-Type: application/json +{ + "password": "", + "verify": truefalse, // if false, it won't send an email for confirmation +} +``` + +
+
PUT /api/users/{email}/password
+
Updates user password
+
+ +Update user password. The body of the request must include the `email`, `connection` and the new `password`. + +```text +PUT /api/users/{email}/password +Authorization: Bearer {token} +Content-Type: application/json +{ + "email": "", + "password": "", + "connection": " + ", // only database connections + "verify": truefalse, // if false, it won't send an email for confirmation +} +``` + +
+
PATCH /api/users/{user_id}/metadata
+
Patch user metadata
+
+ +Patch user metadata. The body of the request must include a `json` object with metadata `attributes`. It will not override metadata not specified attributes. + +```text +PATCH /api/users/{user_id}/metadata +Authorization: Bearer {token} +Content-Type: application/json +{ + "Policy": "1238907654", + "Customer Id": "1234" +} +``` + +
+
DELETE /api/users/{user_id}
+
Deletes a user
+
+ +Deletes a user identified by `user_id` + +```text +DELETE /api/users/{user_id} +Authorization: Bearer {token} +``` + +
+
DELETE /api/users/{user_id}/refresh_tokens/{refresh_token}
+
Revokes a Refresh Token
+
+ +Revokes a user's Refresh Token + +```text +DELETE /api/users/{user_id}/refresh_tokens/{refresh_token} +Authorization: Bearer {token} +``` + + +
+
DELETE /api/users/{user_id}/publickey?device={device}
+
Revokes a public key
+
+ +Revokes a user's public key for specified device + +``` +DELETE /api/users/{user_id}/publickey?device={device} +Authorization: Bearer {token} +``` + +## Connections + +
+
GET /api/connections
+
Gets all connections
+
+ +Gets a list of all the connections (enterprise and social) and all its `options` + +```text +GET /api/connections +Authorization: Bearer {token} +``` + +
+
GET /api/connections/{connection-name}
+
Gets one connection by name
+
+ +Gets a connection by name (enterprise and social) and all its `options` + +```text +GET /api/connections/{connection-name} +Authorization: Bearer {token} +``` + +
+
DELETE /api/connections/{connection-name}
+
Removes a connection
+
+ +Deletes a connection identified by `connectionName` + +```text +DELETE /api/connections/{connection-name} +Authorization: Bearer {token} +``` + +
+
POST /api/connections
+
Creates a connection
+
+ +Creates a connection. The body of the request must include the `name`, the authentication `strategy` to use, and an `options` object with the connection parameters. + +```text +POST /api/connections +Authorization: Bearer {token} +Content-Type: application/json +{ + "name": "" + "strategy": "waad|g-suite|adfs|PingFederate|samlp|auth0", + "options": { + "tenant_domain": + "domain_aliases": + "tenant_domain": + "domain_aliases": + "tenant_domain": , + "domain_aliases": , + "adfs_server": + "domain_aliases": , + "PingFederate Base URL": , + "Signing Cert": "", + "signInEndpoint": "", + "signingCert": "", + "tenant_domain": "", + "domain_aliases": , + "signOutEndpoint": "", + } +} +``` + +
+
PUT /api/connections/{connection-name}
+
Updates a connection
+
+ +Updates a connection. The body of the request must include the `options` object with the connection parameters and the `status`. +The request's body depends on the strategy that was used to create the connection. Select a strategy: waad g-suite adfs PingFederate samlp auth0 + +```text +PUT /api/connections/{connection-name} +Authorization: Bearer {token} +Content-Type: application/json +{ + "options": { + "tenant_domain": + "tenant_domain": + "tenant_domain": , + "adfs_server": + "PingFederate Base URL": , + "Signing Cert": "", + "signInEndpoint": "", + "signingCert": "", + "tenant_domain": "", + "signOutEndpoint": "", + } + "status": true|false +} +``` + +## Applications (Clients) + +
+
GET /api/clients
+
Gets all applications/APIs
+
+ +Gets a list of all the applications/APIs (aka clients) and all its `options` + +```text +GET /api/clients +Authorization: Bearer {token} +``` + +
+
POST /api/clients
+
Creates a new applications/APIs
+
+ +Create an application. The body of the request can include the `name` and `callbacks` parameters. + +```text +POST /api/clients +Authorization: Bearer {token} +Content-Type: application/json +{ + "name": "", + "callbacks": "" // You can specify multiple valid URLs by comma-separating them. +} +``` + +
+
PATCH /api/clients/{client-id}
+
Updates an applications/APIs
+
+ +Update an application. The body of the request must include the `name` and `callbacks` parameters. Does not overwrite the entire application, only the provided values. +Additionally the `signingKey` can be overwritten using this method (not provided for trial for safety reasons). Possible formats are: +* `"signingKey": { cert: "%CERT_STRING%" } // using a cert` +* `"signingKey": { key: "%KEY_STRING%" } // using a private key` +* `"signingKey": { pkcs7: "%PKCS7_STRING%" } // using a pkcs7` +* +WARNING! Changing the `signingKey` for the globalClient will change it for all applications. + +```text +PATCH /api/clients/{client-id} +Authorization: Bearer {token} +Content-Type: application/json +{ + "name": "", + "callbacks": "" // You can specify multiple valid URLs by comma-separating them. +} +``` + +## Rules + +
+
GET /api/rules
+
Gets all rules
+
+ +Gets a list of all the rules + +```text +GET /api/rules +Authorization: Bearer {token} +``` + +
+
POST /api/rules
+
Creates a new applications/APIs
+
+ +Create a rule. The body of the request must include the `name`, `status` and `script` parameters. + +```text +POST /api/rules/ +Authorization: Bearer {token} +Content-Type: application/json +{ + "name": "", + "status": true|false, + "script": "function (user, context, callback) { user.foo = 'bar'; callback(null, user, context);}" + // new lines should be encoded as \n + "order": 1 // optional +} +``` + +
+
PUT /api/rules/{rule-name}
+
Updates a rule
+
+ +Update a rule. The body of the request must include the `status` and `script` parameters. + +```text +PUT /api/rules/{rule-name} +Authorization: Bearer {token} +Content-Type: application/json +{ + "status": true|false, + "script": "function (user, context, callback) { user.foo = 'bar'; callback(null, user, context);}" + // new lines should be encoded as \n + "order": 1 // optional +} +``` + +
+
DELETE /api/rules/{rule-name}
+
Deletes a rules
+
+ + +Deletes a rule identified by `rule-name` (url-encoded) + +```text +DELETE /api/rules/{rule-name} +Authorization: Bearer {token} +``` + +## Email Templates + +
+
GET /api/emails/{email-template-name}
+
Gets an email template by name
+
+ +Gets an email template by name + +```text +GET /api/emails/{email-template-name} +Authorization: Bearer {token} +``` + +Template Names: +* `verify_email` +* `welcome_email` +* `reset_email` +* `blocked_account` + +
+
POST /api/emails
+
Creates an email template
+
+ + +Creates an email template. The body of the request must include the `template` name and the `tenant`. + +```text +POST /api/emails/ +Authorization: Bearer {token} +Content-Type: application/json +{ + "template": "template_name", + "disabled": true|false, + "from": "", + "subject": "", + "body": "", + "urlLifetimeInSeconds": "", + "resultUrl": "", + "syntax": "liquid" +} +``` + +Template Names: +* `verify_email` +* `welcome_email` +* `reset_email` +* `blocked_account` + +
+
PUT /api/emails/{email-template-name}
+
Updates an email template
+
+ +Updates an email template. + +```text +PUT /api/emails/{email-template-name} +Authorization: Bearer {token} +Content-Type: application/json +{ + "disabled": true|false, + "from": "", + "subject": "", + "body": "", + "urlLifetimeInSeconds": "", + "resultUrl": "", + "syntax": "liquid" +} +``` + +Template Names: +* `verify_email` +* `welcome_email` +* `reset_email` +* `blocked_account` + +## Logs + +
+
GET /api/logs/{_id}
+
Gets a log entry
+
+ + +Retrieves the data related to the log entry identified by `_id`. + +```text +GET /api/logs/{_id} +Authorization: Bearer {token} +``` + +
+
GET /api/users/{user_id}/logs?page={number}&per_page={items}
+
Gets the logs for a particular user
+
+ +Retrieves the log entries related to the user identified by `user_id`. Log entries are split into pages of a particular size to avoid returning all data at once: +* `page`: The page number. Zero based. +* `items`: The amount of entries per page. + +```text +GET /api/users/{user_id}/logs?page={number}&per_page={items} +Authorization: Bearer {token} +``` + +#### Response fields +The following is a description of the values returned by the request: +* `start`: The absolute number (considering all log entries) of the first entry in the page. +* `length`: The amount of entries in the page (can only be different than `limit` in the last page). +* `total`: The amount of entries in the page. +* `limit`: The maximum amount of items in a page. +* `logs`: A collection of log entries. + * `date`: The moment when the event occurred. + * `connection`: The connection related to the event. + * `client_id`: The id of the application related to the event. + * `client_name`: The name of the application related to the event. + * `ip`: The IP address from where the request that caused the log entry originated. + * `user_id`: The user id related to the event. + * `user_name`: The user name related to the event. + * `description`: The event's description. + * `user_agent`: The user agent that was used to cause the creation of the log entry. + * `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning. + * `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type. +##### Event acronym mappings +The following is the meaning of the event acronyms: +* `s`:Success Login +* `f`:Failed Login +* `fu`:Failed Login (invalid email/username) +* `fp`:Failed Login (wrong password) +* `fc`:Failed by Connector +* `fco`:Failed by CORS +* `con`:Connector Online +* `coff`:Connector Offline +* `ss`:Success Signup +* `fs`:Failed Signup +* `sv`:Success Verification Email +* `fv`:Failed Verification Email +* `scp`:Success Change Password +* `fcp`:Failed Change Password +* `sce`:Success Change Email +* `fce`:Failed Change Email +* `svr`:Success Verification Email Request +* `fvr`:Failed Verification Email Request +* `scpr`:Success Change Password Request +* `fcpr`:Failed Change Password Request +* `fn`:Failed Sending Notification + +
+
GET /api/logs?page={number}&per_page={items}&sort={field}:{-1|1}&fields={fields}&exclude_fields{true|false}
+
Gets log entries
+
+ +Retrieves data about log entries based on the specified parameters. Log entries are split into pages of a particular size to avoid returning all data at once: +* `page`: The page number. Zero based. +* `items`: The amount of entries per page. +* `field`: The field to use for sorting. `1` == ascending and `-1` == descending. +* `fields`: Can be used to either include or exclude the specified fields by providing a comma (,) separated list of fields, for example `at,c,cn,un`. If no list is provided all fields are included in the response. +* `exclude_fields`: To exclude the fields `exclude_fields=true` must be used (if not specified it defaults to false). +Possible values for `field` are: +* `date`: The moment when the event occurred. +* `connection`: The connection related to the event. +* `client_name`: The name of the application related to the event. +* `user_name`: The user name related to the event. + +```text +GET /api/logs?page={number}&per_page={items}&sort={field}:{-1|1}&fields={fields}&exclude_fields{true|false} +Authorization: Bearer {token} +``` + +#### Response fields +The following is a description of the values returned by the request: +* `start`: The absolute number (considering all log entries) of the first entry in the page. +* `length`: The amount of entries in the page (can only be different than `limit` in the last page). +* `total`: The amount of entries in the page. +* `limit`: The maximum amount of items in a page. +* `logs`: A collection of log entries. + * `date`: The moment when the event occurred. + * `connection`: The connection related to the event. + * `client_id`: The id of the application related to the event. + * `client_name`: The name of the application related to the event. + * `ip`: The IP address from where the request that caused the log entry originated. + * `user_id`: The user id related to the event. + * `user_name`: The user name related to the event. + * `description`: The event's description. + * `user_agent`: The user agent that was used to cause the creation of the log entry. + * `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning. + * `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type. +##### Event acronym mappings +The following is the meaning of the event acronyms: +* `s`:Success Login +* `f`:Failed Login +* `fu`:Failed Login (invalid email/username) +* `fp`:Failed Login (wrong password) +* `fc`:Failed by Connector +* `fco`:Failed by CORS +* `con`:Connector Online +* `coff`:Connector Offline +* `ss`:Success Signup +* `fs`:Failed Signup +* `sv`:Success Verification Email +* `fv`:Failed Verification Email +* `scp`:Success Change Password +* `fcp`:Failed Change Password +* `sce`:Success Change Email +* `fce`:Failed Change Email +* `svr`:Success Verification Email Request +* `fvr`:Failed Verification Email Request +* `scpr`:Success Change Password Request +* `fcpr`:Failed Change Password Request +* `fn`:Failed Sending Notification + +
+
GET /api/logs?search={criteria}
+
Gets log entries
+
+ +Retrieves logs that match the specified search `criteria`. This parameter can be combined with all the others in the `/api/logs` endpoint but is specified separately for clarity. +If no fields are provided a case insensitive 'starts with' search is performed on all of the following fields: +* `client_name` +* `connection` +* `user_name` + +Otherwise, you can specify multiple fields and specify the search using the `%field%:%search%`, for example: `application:node user:"John@contoso.com"`. +Values specified without quotes are matched using a case insensitive 'starts with' search. If quotes are used a case insensitive exact search is used. If multiple fields are used, the AND operator is used to join the clauses. + +##### Available Fields +* `application`: Maps to the `client_name` field. +* `connection`: Maps to the `connection` field. +* `user`: Maps to the `user_name` field. + +```text +GET /api/logs?search={criteria} +Authorization: Bearer {token} +``` + +#### Response fields +The following is a description of the values returned by the request: +* `start`: The absolute number (considering all log entries) of the first entry in the page. +* `length`: The amount of entries in the page (can only be different than `limit` in the last page). +* `total`: The amount of entries in the page. +* `limit`: The maximum amount of items in a page. +* `logs`: A collection of log entries. + * `date`: The moment when the event occurred. + * `connection`: The connection related to the event. + * `client_id`: The id of the application related to the event. + * `client_name`: The name of the application related to the event. + * `ip`: The IP address from where the request that caused the log entry originated. + * `user_id`: The user id related to the event. + * `user_name`: The user name related to the event. + * `description`: The event's description. + * `user_agent`: The user agent that was used to cause the creation of the log entry. + * `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning. + * `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type. + +##### Event acronym mappings +The following is the meaning of the event acronyms: +* `s`:Success Login +* `f`:Failed Login +* `fu`:Failed Login (invalid email/username) +* `fp`:Failed Login (wrong password) +* `fc`:Failed by Connector +* `fco`:Failed by CORS +* `con`:Connector Online +* `coff`:Connector Offline +* `ss`:Success Signup +* `fs`:Failed Signup +* `sv`:Success Verification Email +* `fv`:Failed Verification Email +* `scp`:Success Change Password +* `fcp`:Failed Change Password +* `sce`:Success Change Email +* `fce`:Failed Change Email +* `svr`:Success Verification Email Request +* `fvr`:Failed Verification Email Request +* `scpr`:Success Change Password Request +* `fcpr`:Failed Change Password Request +* `fn`:Failed Sending Notification + +
+
GET /api/logs?from={checkpointId}&take={count}
+
Gets log entries from a checkpoint
+
+ +Retrieves `count` log entries that were logged after `checkpointId`. +* If `checkpointId` is not provided it will start retrieving from the first log entry. +* If `count` is not provided the default value is 200 (also the max value). + +```text +GET /api/logs?from={checkpointId}&take={count} +Authorization: Bearer {token} +``` + +#### Response fields +The following is a description of the values returned by the request: +* `start`: The absolute number (considering all log entries) of the first entry in the page. +* `length`: The amount of entries in the page (can only be different than `limit` in the last page). +* `total`: The amount of entries in the page. +* `limit`: The maximum amount of items in a page. +* `logs`: A collection of log entries. + * `date`: The moment when the event occurred. + * `connection`: The connection related to the event. + * `client_id`: The id of the application related to the event. + * `client_name`: The name of the application related to the event. + * `ip`: The IP address from where the request that caused the log entry originated. + * `user_id`: The user id related to the event. + * `user_name`: The user name related to the event. + * `description`: The event's description. + * `user_agent`: The user agent that was used to cause the creation of the log entry. + * `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning. + * `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type. + +##### Event acronym mappings +The following is the meaning of the event acronyms: +* `s`:Success Login +* `f`:Failed Login +* `fu`:Failed Login (invalid email/username) +* `fp`:Failed Login (wrong password) +* `fc`:Failed by Connector +* `fco`:Failed by CORS +* `con`:Connector Online +* `coff`:Connector Offline +* `ss`:Success Signup +* `fs`:Failed Signup +* `sv`:Success Verification Email +* `fv`:Failed Verification Email +* `scp`:Success Change Password +* `fcp`:Failed Change Password +* `sce`:Success Change Email +* `fce`:Failed Change Email +* `svr`:Success Verification Email Request +* `fvr`:Failed Verification Email Request +* `scpr`:Success Change Password Request +* `fcpr`:Failed Change Password Request +* `fn`:Failed Sending Notification diff --git a/fr-ca/articles/api/management/v1/reference.md b/fr-ca/articles/api/management/v1/reference.md new file mode 100644 index 0000000000..3d0af562df --- /dev/null +++ b/fr-ca/articles/api/management/v1/reference.md @@ -0,0 +1,386 @@ +--- +description: Management API V1 reference page. +section: apis +toc: true +topics: + - apis + - management-api +contentType: reference +useCase: invoke-api +--- + +# Auth0 Management API Reference + +<%= include('../../../_includes/_version_warning_api') %> + +### API endpoint + +```text +https://${account.namespace}/api +``` + +### Authentication +Each API request must include an Access Token, either inside the query string: + +```text +https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} +``` + +or in an ```Authorization``` header: + +```text +GET https://${account.namespace}/api/connections +Authorization: bearer {ACCESS-TOKEN} +``` + +A token is obtained using the POST method: + +```text +POST https://${account.namespace}/oauth/token +Content-type: application/x-www-form-urlencoded +client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&type=web_server&grant_type=client_credentials +``` + +The response body of this POST is a JSON object: + +```text +{ + 'access_token': TOKEN + 'token_type':'bearer' +} +``` + +Here is a simple example using cURL: + +```text +curl https://${account.namespace}/oauth/token --data "client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&type=web_server&grant_type=client_credentials" +``` + +### Headers +The `Authorization` header is the only accepted header and is used in place of the query string to send the Access Token. All content is returned in JSON. The `Accept` header is ignored for now. + +```text +Authorization: bearer {ACCESS-TOKEN} +``` + +## Connections + +### Connection Methods +| Verb | URL | +|:-----|:----| +|`GET` | https://${account.namespace}/api/connections | +|`GET` | https://${account.namespace}/api/connections/{connectionName} | +|`POST` | https://${account.namespace}/api/connections | +|`DELETE`| https://${account.namespace}/api/connections/{connectionName} | +|`PUT` | https://${account.namespace}/api/connections/{connectionName} | + +#### List all Connections + +To return a list of all defined connections in Auth0, use this syntax: + +```text +GET https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} +``` + +The body of the response is a `connection` object formatted as follows: + +```text +{ + "client_id": "${account.clientId}", + "name": YOUR-CONNECTION-NAME, + "options": + { + ... + }, + "status": 0, + "strategy": STRATEGY +} +``` + +#### Parameters +| Parameter | Description | +|:-----------|:------------| +| `client_id`| Your client_id (${account.clientId}), used to obtain the authentication token. | +| `name` | The unique name you gave to the connection. | +| `status` | Defines whether the connection is active `1` or not `0`. | +| `strategy` | The type of identity provider associated with this connection. See below for supported strategies.| +| `options` | An object with properties that are dependent on the strategy selected. | + + +#### Strategies + +| Strategy | For Customers Using | +|:---------|:--------------------| +| `adfs` | On Premises Active Directory or any WS-Federation server | +| `g-suite` | G Suite | +| `google-oauth2` |Google (through the OAuth2 protocol) | +| `office365` | Office 365 and Microsoft Azure Active Directory | +| `windowslive` | Microsoft Account (formerly LiveID) | + +When implementing the `office365`, `g-suite` or `adfs` strategies, the following properties are added to the connection object: + +```text +provisioning_ticket: TICKET +provisioning_ticket_url: PROVISIONING-URL +``` + +The `provisioning_ticket_url` is sent to the identity provider administrator and contains information on how to complete the configuration on their side. + +A GET on `connections` with a specified `{connectionName}` in the path will return the matching connection object only. + +###### The cURL sample scripts + +This script returns a specific connection: + +```text +curl https://${account.namespace}/api/connections/?access_token={YOUR ACCESS TOKEN} +``` + +This script returns all connections: + +```text +curl https://${account.namespace}/api/connections/{YOUR-CONNECTION-NAME}?access_token={YOUR ACCESS TOKEN} +``` + +##### Options + +The `options` object returned in the `connection` will be different for each strategy and will typically contain the same information that was entered on the [connections](${manage_url}/#/connections) screen. + +###### ADFS Strategy + +```text +{ + tenant_domain: A-DOMAIN, + adfs_server: YOUR-FEDERATION-METADATA-ENDPOINT, + thumbprints: [ '9b250aad7e4950604072ffaa60cde7795f23b52a', + 'f97702a42c893a0fb1bc6dad21c79fb720473a85', + '9b250aad7e4955604072faca60cde7795f23b52a', + 'f97702a42c893a0fb1bc6dad21c79fb720473a85', + '9b250aad7e4956704072ffaa60cde7795f23b52a', + 'f97702a42c893a0fb1b546dad21c79fb720473a85', + '9b250aad7e4959804072ffaa60cde7795f23b52a' ], + signInEndpoint: ADFS-LOGIN-PAGE +} +``` + +| Parameter | Description | +|:----------|:------------| +| `tenant_domain` | The domain name of the company (If the user's email is _john @mycompany.com_, then _mycompany.com_ is the domain). | +| `adfs_server` | (for example: `the-adfs-server.domain.com/FederationMetadata/2007-06/FederationMetadata.xml`). | +| `signInEndpoint`| The URL of the ADFS server where Auth0 will redirect users for login. (for example: `the-adfs-server.company.com/adfs/ls`). | + +###### G Suite Strategy + +```text +{ + client_id: GOOG-CLIENT-ID, + client_secret: GOOG-CLIENT-SECRET, + tenant_domain: 'company.com', + email: true/false, + profile: true/false, + ext_groups: true/false, + ext_is_admin: true/false, + ext_is_suspended: true/false, + ext_agreed_terms: true/false, + api_enable_users: true/false, + scope: [ 'https://www.googleapis.com/auth/userinfo.email', + 'https://www.googleapis.com/auth/userinfo.profile' ] +} +``` + +To obtain the `client_id` and `client_secret` for G Suite connections, see [Google connections](/connections/social/google). + +###### Google OAuth2 Strategy + +```text +{ + client_id: 'GOOG-CLIENT-ID', + client_secret: 'GOOG-CLIENT-SECRET', + email: true/false, + profile: true/false, + contacts: true/false, + blogger: true/false, + calendar: true/false, + gmail: true/false, + google_plus: true/false, + orkut: true/false, + picasa_web: true/false, + tasks: true/false, + youtube: true/false, + adsense_management: true/false, + google_affiliate_network: true/false, + analytics: true/false, + google_books: true/false, + google_cloud_storage: true/false, + content_api_for_shopping: true/false, + chrome_web_store: true/false, + document_list: true/false, + google_drive: true/false, + google_drive_files: true/false, + latitude_best: true/false, + latitude_city: true/false, + moderator: true/false, + sites: true/false, + spreadsheets: true/false, + url_shortener: true/false, + webmaster_tools: true/false, + scope: [] +} +``` + +###### Office 365 Strategy + +```text +{ + client_id: 'OFFICE-365-CLIENT-ID', + client_secret: 'OFFICE-365-CLIENT-SECRET', + tenant_domain: 'CONNECTION-DOMAIN-ON-OFFICE-365', + basic_profile: true/false, + ext_profile: true/false, + ext_groups: true/false, + ext_assigned_plans: true/false, + api_enable_users: true/false, + app_domain: '${account.namespace}', + thumbprints: [] +} +``` + +To obtain `client_id` and `client_secret` for Office 365 connections, see [o365-clientid](/o365-clientid). + + +###### Microsoft Account Strategy + +```text +{ + client_id: 'MSFT-ACCOUNT-CLIENT-ID', + client_secret: 'MSFT-ACCOUNT-CLIENT-SECRET', + signin: true/false, + emails: true/false, + postal_addresses: true/false, + birthday: true/false, + work_profile: true/false, + basic: true/false, + offline_access: true/false, + calendars: true/false, + calendars_update: true/false, + contacts_birthday: true/false, + contacts_create: true/false, + contacts_calendar: true/false, + contacts_photos: true/false, + contacts_skydrive: true/false, + events_create: true/false, + messenger: true/false, + phone_numbers: true/false, + photos: true/false, + share: true/false, + skydrive: true/false, + skydrive_update: true/false, + applications: true/false, + applications_create: true/false, + scope: [] +} +``` + +To obtain `client_id` and `client_secret` for Microsoft Accounts, see [Microsoft Account Client ID](/ms-account-clientid). + +#### Get a specific Connection + +```text +GET https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=... +``` + +#### Delete a connection + +A Delete operation on the `connections` object will eliminate the connection definition permanently. The parameter for this operation is the name of the connection to delete. + +```text +DELETE https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=... +``` + +If successful, the response body will contain a confirmation object: +```text +{ + "removed": {id} +} +``` + +::: note +Batch operations are not yet supported. +::: + +#### Create a new Connection + +To create a new connection, POST a connection object to the `connections` resource: + +```text +POST https://${account.namespace}/connections +Content-Type: application/json +``` + +The body of the request is formatted as a `connection` object. For example, the following will create a new connection to G Suite, initially inactive (`status=0`): + +```text +{ + "name": A-NAME-FOR-THIS-CONNECTION + "status": 0, + "options": + { + "client_id": GOOG-APPS-CLIENT-ID, + "client_secret": GOOG-APPS-CLIENT-SECRET, + "tenant_domain": GOOG-APP-DOMAIN, + "ext_groups":true //Optional + }, + "strategy": "g-suite" +}; +``` + +Once again, the `options` object is dependent on the strategy specified. + +If successful, the response body will contain a complete `connection` object. This will include additional fields (such as the entity `id`, and so on). + +#### Updating a Connection + +For updates, use the PUT method. A PUT works on a specific `connection`, therefore the connection `name` must be specified. All object parameters must be included, not only those which have changed. + +### Users +| Verb | URL | Description | +|:-----|:----|:------------| +|`GET` |https://${account.namespace}/api/users |Gets all users who have logged in through any of your connections. | +|`GET` |https://${account.namespace}/api/connections/{connection}/users|Gets all users from an enterprise directory like Office365 / Microsoft Azure Active Directory or a G Suite domain.| +|`GET` |https://${account.namespace}/api/socialconnections/users |Gets all users who have logged in through any of the enabled social connections. | + +::: note +If the connection does not support querying for users (for instance: ADFS), the `GET https://${account.namespace}/api/connections/{connection}/users` will return users who have logged in through that connection. +::: + +#### The User Object + +```text +{ + _id: '7eb1ae32568910b0f46e981aa99b56556', + email: 'john@fabrikam.com', + family_name: 'Fabrikam', + given_name: 'John', + identities: [], + issuer: 'https://the-adfs-server.fabrikam.com', + lastLogin: '2013-01-15T01:54:30.578Z', + loginsCount: 13, + name: 'John Fabrikam', + nickname: 'john', + picture: 'https://secure.gravatar.com/avatar/5426f6b9d63ad92d60e6fe9fdf83aa21?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png', + user_id: 'adfs|john@fabrikam.com' +} +``` + +Most attributes in the `user` object are self-explanatory. Some comments are below: + +|Parameter | Description | +|:---------|:------------| +|`issuer` | The name of the authentication server. In the example above it is the URL of Fabrikam's ADFS server used.| +|`user_id` | (for example: _the-adfs-server.domain.com/FederationMetadata/2007-06/FederationMetadata.xml_). | +|`picture` | The URL of the user's gravatar, if available. | +|`user_id` | A "friendly" unique identifier composed of the strategy plus a unique identifier from the `issuer` (for example: email, and so on). | + +#### Other resources + +* [Auth0 node module](/node-auth0client). A simple client library for Node.js apps. diff --git a/fr-ca/articles/api/management/v2/changes.md b/fr-ca/articles/api/management/v2/changes.md new file mode 100644 index 0000000000..b81792b5c1 --- /dev/null +++ b/fr-ca/articles/api/management/v2/changes.md @@ -0,0 +1,245 @@ +--- +description: Describes the major differences between Auth0's Management API v1 and Management API v2, and details the reasons for each change. +section: apis +crews: crew-2 +toc: true +topics: + - management-api + - apis +contentType: reference +useCase: invoke-api +--- +# Management API v1 vs v2 + +This document describes the major differences between Auth0's Management API v1 and the new Management API v2, and details the reasons for each change. + +## tl;dr + +* v2 uses JWTs instead of opaque tokens. +* v2 includes `user_metadata` for trivial data about users and `app_metadata` for data that affects how your application functions. Unlike `metadata` in API v1, these fields are not merged into the root `user` object. +* Fewer endpoints on existing features make development easier. +* All endpoints work with ids. Strings (such as `connection_name`) are no longer used. +* New formats for `user_id` (available as `v2_id` with the "usr\_" prefix) and `clientID` (with the "cli\_" prefix) recognize the entity type based on its id. +* Improved input validation and error messages. +* Only one connection is exposed per tenant, instead of one per application. To enable/disable a connection for an application, use the `enabled_clients` property. +* When updating field values, v2 removes fields with `null` values, instead of storing them with the value `null` + +### User endpoints + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /api/users](/api/v1#!#get--api-users) | None. | [GET /api/v2/users](/api/v2#!/Users/get_users) | +| [GET /api/users?search={criteria}](/api/v1#!#get--api-users-search--criteria-) | Changed parameter and syntax. | See the [get_users](/api/v2#!/Users/get_users) documentation. | +| [GET /api/users/{user\_id}](/api/v1#!#get--api-users--user_id-) | None. | [GET /api/v2/users/{id}](/api/v2#!/Users/get_users_by_id) also accepts `v2\_id` | +| [GET /api/connections/{connection}/users](/api/v1#!#get--api-connections--connection--users) | Changed to use search. | Available using `q=identities.connection:"{connection}"` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. | +| [GET /api/connections/{connection}/users?search={criteria}](/api/v1#!#get--api-connections--connection--users-search--criteria-) | Changed to use search. | Available using `q=identities.connection:"{connection}"` and `search_engine=v3` in the query string. Other conditions and criteria may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. **For enterprise connections**, only supports searching users that have previously logged in; **external user search is no longer supported.** | +| [GET /api/enterpriseconnections/users?search={criteria}](/api/v1#!#get--api-enterpriseconnections-users-search--criteria-) | Changed to use search. | Available using `q=identities.isSocial:false AND NOT identities.provider:auth0` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. Only supports searching users that have previously logged in; **external user search is no longer supported.** | +| [GET /api/socialconnections/users?search={criteria}](/api/v1#!#get--api-socialconnections-users-search--criteria-) | Changed to use search. | Available using `q=identities.isSocial:true` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. | +| [GET /api/clients/{client-id}/users](/api/v1#!#get--api-socialconnections-users-search--criteria-) | Removed. | Removed. | +| [POST /api/users](/api/v1#!#post--api-users) | None. | [POST /api/v2/users](/api/v2#!/Users/post_users) | +| [POST /api/users/{user\_id}/change\_password\_ticket](/api/v1#!#post--api-users--user_id--change_password_ticket) | None. | [POST /api/v2/tickets/password-change](/api/v2#!/tickets/post_password_change) | +| [POST /api/users/{user\_id}/verification\_ticket](/api/v1#!#post--api-users--user_id--verification_ticket) | None. | [POST /api/v2/tickets/email-verification](/api/v2#!/tickets/post_email_verification) | +| [POST /api/users/{user\_id}/publickey](/api/v1#!#post--api-users--user_id--publickey) | Keys are created per device, not per user. | [POST /api/v2/device-credentials](/api/v2#!/Device_Credentials/post_device_credentials) | +| [PUT /api/users/{user\_id}/email](/api/v1#!#put--api-users--user_id--email) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id`. | +| [PUT /api/users/{user\_id}/metadata](/api/v1#!#put--api-users--user_id--metadata) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` | +| [PUT /api/users/{user\_id}/password](/api/v1#!#put--api-users--user_id--password) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` | +| [PUT /api/users/{email}/password](/api/v1#!#put--api-users--email--password) | Removed. | Endpoints only accept ids, not strings. | +| [PATCH /api/users/{user\_id}/metadata](/api/v1#!#patch--api-users--user_id--metadata) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` | +| [DELETE /api/users](/api/v1#!#delete--api-users) | None. | [DELETE /api/v2/users](/api/v2#!/Users/delete_users) | +| [DELETE /api/users/{user\_id}](/api/v1#!#delete--api-users--user_id-) | None. | [DELETE /api/v2/users/{id}](/api/v2#!/Users/delete_users_by_id) also accepts `v2_id` | +| [DELETE /api/users/{user\_id}/refresh_tokens/{refresh\_token}](/api/v1#!#delete--api-users--user_id--refresh_tokens--refresh_token-) | Tokens and public keys are device credentials. | [DELETE /api/v2/device-credentials/{id}](/api/v2#!/Device_Credentials/delete_device_credentials_by_id) | +| [DELETE /api/users/{user\_id}/publickey?device={device}](/api/v1#!#delete--api-users--user_id--publickey-device--device-) | Tokens and public keys are device credentials. | [DELETE /api/v2/device-credentials/{id}](/api/v2#!/Device_Credentials/delete_device_credentials_by_id) | +| [POST /api/users/{user_id}/send_verification_email](/api/v1#!#post--api-users--user_id--send_verification_email) | None. | [POST /api/v2/jobs/verification-email](/api/v2#!/Jobs/post_verification_email) + + +### Application endpoints + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /api/clients](/api/v1#!#get--api-clients) | None. | [GET /api/v2/clients](/api/v2#!/Clients/get_clients) | +| [POST /api/clients](/api/v1#!#post--api-clients) | None. | [POST /api/v2/clients](/api/v2#!/Clients/post_clients) | +| [PUT /api/clients/{client-id}](/api/v1#!#put--api-clients--client-id-) | Removed. | [PUT /api/v2/clients/{id}](/api/v2#!/Clients/patch_clients_by_id) | +| [PATCH /api/clients/{client-id}](/api/v1#!#patch--api-clients--client-id-) | None. | [PATCH /api/v2/clients/{id}](/api/v2#!/Clients/patch_clients_by_id) | +| [DELETE /api/clients/{client-id}](/api/v1#!#delete--api-clients--client-id-) | None. | [DELETE /api/v2/clients/{id}](/api/v2#!/Clients/delete_clients_by_id) | + +### Connection endpoints + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /api/connections](/api/v1#!#get--api-connections) | None. | [GET /api/v2/connections](/api/v2#!/Connections/get_connections) | +| [GET /api/connections/{connection-name}](/api/v1#!#get--api-connections--connection-name-) | Use `id` instead of `connection-name`. | [GET /api/connections/{id}](/api/v2#!/Connections/get_connections_by_id) | +| [POST /api/connections](/api/v1#!#post--api-connections) | Added `enabled_clients` property. | [POST /api/v2/connections](/api/v2#!/Connections/post_connections) | +| [PUT /api/connections/{connection-name}](/api/v1#!#put--api-connections--connection-name-) | Removed; use `id` instead of `connection-name`. | [PATCH /api/v2/connections/{id}](/api/v2#!/Connections/patch_connections_by_id) | +| [DELETE /api/connections/{connection-name}](/api/v1#!#delete--api-connections--connection-name-) | Use `id` instead of `connection-name`. | [DELETE /api/v2/clients/{id}](/api/v2#!/Connections/delete_connections_by_id) | +| [GET /api/connections/{connection}/users](/api/v1) | None. | [GET /api/v2/users](/api/v2#!/Users/get_users) (see note) | +| [GET /api/connections/{connection}/socket](/api/v1) | None. | [GET /api/v2/connections/{id}/status](/api/v2#!/Connections/get_status) | + +::: note +For Private Cloud (search_engine:v2), use `q=identities.connection:"connection_name"` +::: + +### Rules endpoints + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /api/rules](/api/v1#!#get--api-rules-) | None. | [GET /api/v2/rules](/api/v2#!/Rules/get_rules) | +| [POST /api/rules](/api/v1#!#post--api-rules) | None. | [POST /api/v2/rules](/api/v2#!/Rules/post_rules-) | +| [PUT /api/rules/{rule-name}](/api/v1#!#put--api-rules--rule-name-) | Removed; use `id` instead of `rule-name`. | [PATCH /api/v2/rules/{id}](/api/v2#!/Rules/patch_rules_by_id) | +| [DELETE /api/rules/{rule-name}](/api/v1#!#delete--api-rules--rule-name-) | Use `id` instead of `rule-name`. | [DELETE /api/v2/rules/{id}](/api/v2#!/Rules/delete_rules_by_id) | +| [GET /api/rules-configs](/api/v1) | None. | [GET /api/v2/rules-configs](/api/v2#!/Rules_Configs/get_rules_configs) | +| [POST /api/rules-configs](/api/v1) | Removed; perform one call per variable to update. | [PUT /api/v2/rules-configs/{key}](/api/v2#!/Rules_Configs/put_rules_configs_by_key) | + +### Logs endpoints + +Logs endpoints in Management API v2 are described at [Search Log Events](https://auth0.com/docs/api/management/v2#!/Logs/get_logs) + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /logs](/api/v1#logs) | Syntax Changes, described at [Breaking Changes](https://auth0.com/docs/logs/query-syntax#search-engine-v3-breaking-changes) | [GET /api/v2/logs](/api/v2#!/Logs/get_logs) | +| [GET /logs/{id}](/api/v1#logs) | None. | [GET /api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id) | + +### Email Templates endpoints + +| v1 Endpoint | Change | v2 Endpoint | +| ----------- | ------ | ----------- | +| [GET /api/emails/{email-template-name}](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [GET /api/v2/email-templates/{templateName}](/api/v2#!/Email_Templates/get_email_templates_by_templateName) | +| [POST /api/emails](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [POST /api/v2/email-templates](https://auth0.com/docs/api/management/v2#!/Email_Templates/post_email_templates) | +| [PUT /api/emails/{email-template-name}](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [PUT /api/v2/email-templates/{templateName}](https://auth0.com/docs/api/management/v2#!/Email_Templates/put_email_templates_by_templateName) | + +## Authentication mechanism + +Auth0's API v1 requires sending an Access Token obtained by performing a [`POST /oauth/token`](/api/v1#!#post--oauth-token) request along with the `clientId` and `clientSecret`. All subsequent requests must include the Access Token in the `Authorization` header: `Authorization: Bearer {access_token}`. + +Auth0's API v2 requires sending an Access Token with specific scope(s). To perform requests with API v2, use the `Authorization` header: `Authorization: Bearer YOUR_ACCESS_TOKEN`. + +To use an endpoint, at least one of its available scopes (as listed in [Management API v2 explorer](/api/v2)) must be specified for the JWT. The actions available on an endpoint depend on the JWT scope. For example, if a JWT has the `update:users_app_metadata` scope, the [PATCH users `app_metadata`](/api/v2#!/Users/patch_users_by_id) action is available, but not other properties. + +There is a subset of scopes that your application can use in order to perform a subset of operations on behalf of the currently logged-in user. These are: + +* `read:current_user` +* `update:current_user_identities` +* `create:current_user_metadata` +* `update:current_user_metadata` +* `delete:current_user_metadata` +* `create:current_user_device_credentials` +* `delete:current_user_device_credentials` + +So, for example, if the Access Token contains the scope `update:current_user_metadata` then it can be used to update the metadata of the currently logged-in user. If, on the other hand, it contains the scope `update:users_app_metadata` it can be used to update the metadata of any user. + +## User metadata + +In the Management API v1, [`user.metadata`](/api/v1#!#patch--api-users--user_id--metadata) provides additional user information that is not part of the default user claims. When working with rules and other API endpoints, `metadata` is merged into the root user. For example, if the following data is stored for a user with `email` "jane.doe@gmail.com": + +```javascript +{ + metadata: { + hobby: 'surf' + } +} +``` + +when working with rules or retrieving the user from the API, you would get: + +```javascript +console.log(user.email); // "jane.doe@gmail.com" +console.log(user.hobby); // "surf" +``` + +Note that `user.metadata.hobby` is not being used. + +This automatic merging caused confusion for our customers. Also, having a single bucket for all metadata did not work well with our new permissions model for the following reasons: + +* You may want to store information in `metadata` that was core to your application's functionality. +* You may want to allow your users to update their own metadata. + +### app\_metadata and user\_metadata + +In API v2 the concept of `metadata` is divided into: + +* `app_metadata`: Data related to the user that affects the application's core functionality. +* `user_metadata`: Data related to the user that does not affect the application's core functionality. + +Neither of these two properties are merged into the root `user` object. If you stored: + +```javascript +{ + user_metadata: { + hobby: 'surf' + }, + app_metadata: { + plan: 'full' + } +} +``` + +when working in rules or retrieving users from the API you would get: + +```javascript +console.log(user.email); // "jane.doe@gmail.com" +console.log(user.user_metadata.hobby); // "surf" +console.log(user.app_metadata.plan); // "full" +``` + +::: note +User data previously stored under `metadata` will be available under `app_metadata`. +::: + +## Connections + +For every tenant-created, named connection, Management API v1 exposes an individual connection for each of the tenant's applications. + +However, given a named connection, Management API v2 exposes only one connection per tenant. Management of connection-enabled applications is performed using the `enabled_clients` property. + +For example, to create a connection that is enabled for applications `AaiyAPdpYddboKnqNS8HJqRn4T5ti3BQ` and `DaM8bokEXBWrTUFZiXjWn50jei6ardyV`: + +```text +curl -H "Authorization: Bearer {API_TOKEN}" -X POST -H "Content-Type: application/json" +-d '{"name":"new-connection","strategy":"auth0","enabled_clients":["AaiyAPdpYddboKnqNS8HJqRn4T5ti3BQ","DaM8bokEXBWrTUFZiXjWn50jei6ardyV"]}' +https://{YOUR_TENANT}.auth0.com/api/v2/connections +``` + +Connection names cannot be used to manage connections. Instead use the new `id` property. For example, to retrieve the connection with id `'con_UITxoKznrqb1oxIU'`: + +```text +curl -H "Authorization: Bearer {API_TOKEN}" +https://{YOUR_TENANT}.auth0.com/api/v2/connections/con_UITxoKznrqb1oxIU +``` + +## Endpoints + +Some of the changes to endpoints are detailed below. + +### Consolidation + +In Management API v1, different endpoints are used to update the various user properties. For example, changing the following user properties requires using these separate endpoints: + +* [`PUT /api/users/{user_id}/email`](/api/v1#!#put--api-users--user_id--email) +* [`PUT /api/users/{user_id}/metadata`](/api/v1#!#put--api-users--user_id--metadata) +* [`PUT /api/users/{user_id}/password`](/api/v1#!#put--api-users--user_id--password) + +In API v2, these are simplified into the single endpoint [`PATCH /api/v2/users/{id}`](/api/v2#!/Users/patch_users_by_id) which allows you to modify these (and other) user properties. + +### All endpoints require ids + +All endpoints receive an id. This change affects **Rules** and **Connections** particularly. + +Some endpoints, such as [`PUT /api/users/{email}/password`](/api/v1#!#put--api-users--email--password), are no longer available. + +### Improved input validation and error messages + +In Management API v2, all endpoints use [JSON schemas](http://json-schema.org) to validate input. Also, descriptive error messages are returned when a schema's constraints are not met. + +For an example, see the methods in our [Management API v2 explorer](/api/v2). + +## PATCH with null values + +In API v1, when updating field values, if the field is `null`, it will be saved as `null` in the database. In API v2, a `null` field will result in the field being deleted from the database. + +Example: `{metadata: {color: null}}` + +Will be stored as follows: + +* When using API v1: `{metadata: {color: null}}` +* When using API v2: `{user_metadata: {}}` + +So, in API v1, the field's value is stored as `null`, but in API v2, the field is simply removed. diff --git a/fr-ca/articles/api/management/v2/create-m2m-app.md b/fr-ca/articles/api/management/v2/create-m2m-app.md new file mode 100644 index 0000000000..ef3cf0d79c --- /dev/null +++ b/fr-ca/articles/api/management/v2/create-m2m-app.md @@ -0,0 +1,44 @@ +--- +description: How to create and authorize a machine-to-machine application for calling Management API endpoints using Access Tokens. +section: apis +toc: true +topics: + - apis + - management-api + - tokens +contentType: + - how-to +useCase: invoke-api +--- + +# Create and Authorize a Machine-to-Machine Application + +The first time you get a token for the Management API is when you complete the configuration in the Auth0 [Dashboard](${manage_url}). You won't have to do this again unless you create a new tenant. We recommend that you create a token exclusively for authorizing access to the Management API instead of reusing another one you might have. + +To create and authorize a Machine-to-Machine Application for the Management API: + +1. Go to [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer) +2. Click the button __Create & Authorize a Test Application__. A new application has been created and it's authorized to access the Management API. + +![Create and Authorize Application](/media/articles/api/tokens/create-authorize-client.png) + +The application created in the steps above has been granted __all__ the Management API scopes. This means that it can access all endpoints. + +::: panel How can I find out which scopes/permissions are required? +Each machine-to-machine application that accesses an API must be granted a set of scopes. Scopes are permissions that should be granted by the owner. Each [Auth0 Management API v2](/api/management/v2) endpoint requires specific scopes. To see the required scopes/permissions for each endpoint, go to the [Management API Explorer](/api/management/v2#!) and find the endpoint you want to call. Each endpoint has a section called **Scopes** listing all the scopes that the endpoint requires. For example, the [Get all clients](/api/management/v2#!/Clients/get_clients) endpoint requires the scopes `read:clients` and `read:client_keys`. +::: + +## Example: Get All Clients Endpoint + +The [Get all clients](/api/management/v2#!/Clients/get_clients) endpoint requires the scopes `read:clients` and `read:client_keys`, while the [Create an application](/api/management/v2#!/Clients/post_clients) endpoint requires the scope `create:clients`. From that we can deduce that if we need to read _and_ create applications, then our token should include three scopes: `read:clients`, `read:client_keys` and `create:clients`. + +If you have multiple applications that should access the Management API, and you need different sets of scopes per app, we recommend creating a new machine-to-machine application for each one. For example, if one application is to read and create users (`create:users`, `read:users`) and another to read and create applications (`create:clients`, `read:clients`) create two applications (one for user scopes, one for applications) instead of one. + +## Keep reading + +* [Get Access Tokens for Testing](/api/management/v2/get-access-tokens-for-test) +* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production) +* [Get Management API Tokens for Single-page Applications](/api/management/v2/get-access-tokens-for-spas) +* [Applications](/applications) +* [Management API Explorer](/api/management/v2#!) +* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens) diff --git a/fr-ca/articles/api/management/v2/faq-management-api-access-tokens.md b/fr-ca/articles/api/management/v2/faq-management-api-access-tokens.md new file mode 100644 index 0000000000..28600870ec --- /dev/null +++ b/fr-ca/articles/api/management/v2/faq-management-api-access-tokens.md @@ -0,0 +1,33 @@ +--- +description: FAQs for Management API Access Tokens +section: apis +toc: true +topics: + - apis + - management-api + - tokens +contentType: + - reference +useCase: invoke-api +--- + +# Management API Access Token FAQs + +__How long is the token valid for?__
+The Management API token has by default a validity of __24 hours__. After that the token will expire and you will have to get a new one. If you get one manually from [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer) though, you can change the expiration time. However, having non-expiring tokens is not secure. + +__The old way of generating tokens was better, since the token never expired. Why was this changed?__
+The old way of generating tokens was insecure since the tokens had an infinite lifespan. The new implementation allows tokens to be generated with specific scopes and expirations. We decided to move to the most secure implementation because your security, and that of your users, is priority number one for us. + +__Can I change my token's validity period?__
+You cannot change the default validity period, which is set to 24 hours. However, if you get a token manually from [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer) you can change the expiration time for the specific token. Note though, that your applications should use short-lived tokens to minimize security risks. + +__Can I refresh my token?__
+You cannot renew a Management API token. A [new token](#2-get-the-token) should be created when the old one expires. + +__My token was compromised! Can I revoke it?__
+You cannot directly revoke a Management API token, thus we recommend a short validity period. +Note that deleting the application grant will prevent *new tokens* from being issued to the application. You can do this either by [using our API](/api/management/v2#!/Client_Grants/delete_client_grants_by_id), or manually [deauthorize the API application using the dashboard](${manage_url}/#/apis/management/authorized-applications). + +__My Client Secret was compromised! What should I do?__
+You need to change the secret immediately. Go to your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings) and click the __Rotate__ icon , or use the [Rotate a client secret](/api/management/v2#!/Clients/post_rotate_secret) endpoint. Note that previously issued tokens will continue to be valid until their expiration time. diff --git a/fr-ca/articles/api/management/v2/get-access-tokens-for-production.md b/fr-ca/articles/api/management/v2/get-access-tokens-for-production.md new file mode 100644 index 0000000000..fdb44e1706 --- /dev/null +++ b/fr-ca/articles/api/management/v2/get-access-tokens-for-production.md @@ -0,0 +1,180 @@ +--- +description: How to get Access Tokens to make scheduled frequent calls to the Management API. +section: apis +toc: true +topics: + - apis + - management-api + - tokens +contentType: + - how-to +useCase: invoke-api +--- + +# Get Access Tokens for Production + +To make scheduled frequent calls for a production environment, you have to build a process at your backend that will provide you with a token automatically (and thus simulate a non-expiring token). + +## Prerequisite + +* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app). + +## Get Access Tokens + +To ask Auth0 for a Management API v2 token, perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint, using the credentials of the Machine-to-Machine Application you created in the prerequisite step. + +The payload should be in the following format: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "client_credentials" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "https://${account.namespace}/api/v2/" + } + ] + } +} +``` + +The request parameters are: + +| __Request Parameter__ | __Description__ | +| ------ | ----------- | +| __grant_type__ | Denotes which [OAuth 2.0 flow](/protocols/oauth2#authorization-grant-types) you want to run. For machine to machine communication use the value `client_credentials`. | +| __client_id__ | This is the value of the __Client ID__ field of the Machine-to-Machine Application you created. You can find it on the [Settings tab of your Application](${manage_url}/#/applications/${account.clientId}/settings). | +| __client_secret__ | This is the value of the __Client Secret__ field of the Machine-to-Machine Application you created. You can find it at the [Settings tab of your Application](${manage_url}/#/applications/${account.clientId}/settings). | +| __audience__ | This is the value of the __Identifier__ field of the `Auth0 Management API`. You can find it at the [Settings tab of the API](${manage_url}/#/apis). | + +The response will contain a [signed JWT](/tokens/concepts/jwts), when it expires, the scopes granted, and the token type. + +```json +{ + "access_token": "eyJ...Ggg", + "expires_in": 86400, + "scope": "read:clients create:clients read:client_keys", + "token_type": "Bearer" +} +``` + +From the above we can see that our Access Token is a [Bearer Access Token](https://tools.ietf.org/html/rfc6750), it will expire in 24 hours (86400 seconds), and it has been authorized to read and create applications. + +### Use Auth0's Node.js Client Library + +As an alternative to making HTTP calls, you can use the [node-auth0](https://www.npmjs.com/package/auth0) library to automatically [obtain tokens for the Management API](https://www.npmjs.com/package/auth0#user-content-management-api-client). + +## Use Access Tokens + +To use this token, include it in the `Authorization` header of your request. + +```har +{ + "method": "POST", + "url": "http://PATH_TO_THE_ENDPOINT/", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN"} + ] +} +``` + +For example, in order to [Get all applications](/api/management/v2#!/Clients/get_clients) use the following: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/clients", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5ESTFNa05DTVRGQlJrVTRORVF6UXpFMk1qZEVNVVEzT1VORk5ESTVSVU5GUXpnM1FrRTFNdyJ9.eyJpc3MiOiJodHRwczovL2RlbW8tYWNjb3VudC5hdXRoMC5jb20vIiwic3ViIjoib9O7eVBnMmd4VGdMNjkxTnNXY2RUOEJ1SmMwS2NZSEVAY2xpZW50cyIsImF1ZCI6Imh0dHBzOi8vZGVtby1hY2NvdW50LmF1dGgwLmNvbS9hcGkvdjIvIiwiZXhwIjoxNDg3MDg2Mjg5LCJpYXQiOjE5ODY5OTk4ODksInNjb3BlIjoicmVhZDpjbGllbnRzIGNyZWF0ZTpjbGllbnRzIHJlYWQ6Y2xpZW50X2tleXMifQ.oKTT_cEA_U6hVzNYPCl_4-SnEXXvFSOMJbZyFydQDPml2KqBxVw_UPAXhjgtW8Kifc_b2HQ4jFh7nH0KC_j1XjfEJPvwFZgqfI_ILzO3DPfpEIK_n_aX-Tz4okbZe6nj2aT_qLpHimLxK50jOGaMuzp4a1djHJTj5q-NbIiPW8AJowS2-gveP4T3dyyegUsZkmTNwrreqppPApmpWWE-wVsxnVsI_FZFrHnq0rn7lmY_Iz6vyiZjaKrd2C3hFm0zFGTn8FslBfHUldTcDNzOKOpCq7HFMeU0urXBXDetrzkW1afxIqED3G2C51JEV-4nTRYUinnWgXJfLJ87G3ge_A"} + ] +} +``` + +::: note +You can get the curl command for each endpoint from the Management API v2 Explorer. Go to the endpoint you want to call, and click the __get curl command__ link at the __Test this endpoint__ section. +::: + +## Example: Python Implementation + +This python script gets a Management API v2 Access Token, uses it to call the [Get all applications](/api/management/v2#!/Clients/get_clients) endpoint, and prints the response in the console. + +Before you run it make sure that the following variables hold valid values: +- `audience`: The __Identifier__ of the `Auth0 Management API`. You can find it at the [Settings tab of the API](${manage_url}/#/apis). +- `domain`: The __Domain__ of the Machine-to-Machine Application you created. +- `client_id`: The __Client ID__ of the Machine to Machine Application you created. +- `client_secret`: The __Client Secret__ of the Machine-to-Machine Application you created. + +```python +def main(): + import json, requests + from requests.exceptions import RequestException, HTTPError, URLRequired + + # Configuration Values + audience = f"https://${account.namespace}/api/v2/" + domain = "${account.namespace}" + client_id = "${account.clientId}" + client_secret = "YOUR_CLIENT_SECRET" + grant_type = "client_credentials" # OAuth 2.0 flow to use + + # Get an Access Token from Auth0 + base_url = f"https://{domain}" + payload = {'grant_type': 'client_credentials', + 'client_id': client_id, + 'client_secret': client_secret, + 'audience': audience} + res = requests.get(base_url, data=payload) + oauth = json.loads(response.json()) + access_token = oauth.get('access_token') + + # Get all Applications using the token + res = requests.get(base_url + "/api/v2/clients") + header = { + 'Authorization', 'Bearer ' + access_token, + 'Content-Type', 'application/json' + } + + try: + res = request.get(req, header = header) + output = json.loads(res.json()) + print(output) + except HTTPError as e: + print('HTTPError = ' + str(e.code) + ' ' + str(e.reason)) + except URLRequired as e: + print(f'URLRequired = str(e.reason)') + except RequestException as e: + print('RequestException: {e}') + except Exception as e: + print(f'Generic Exception: {e}') + +# Standard boilerplate to call the main() function. +if __name__ == '__main__': + main() +``` + +## Keep reading + +- [Applications](/applications) +* [Management API Explorer](/api/management/v2#!) +* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens) + + diff --git a/fr-ca/articles/api/management/v2/get-access-tokens-for-spas.md b/fr-ca/articles/api/management/v2/get-access-tokens-for-spas.md new file mode 100644 index 0000000000..49f58e6168 --- /dev/null +++ b/fr-ca/articles/api/management/v2/get-access-tokens-for-spas.md @@ -0,0 +1,60 @@ +--- +description: Describes available scopes and endpoints for Management API tokens for Single-page Applications (SPAs). +section: apis +topics: + - apis + - management-api + - tokens +contentType: + - how-to +useCase: invoke-api +--- + +# Get Management API Tokens for Single-page Applications + +In certain cases, you may want to use Auth0's [Management API](/api/management/v2#!) to manage your applications and APIs rather than the Auth0 Management Dashboard. + +To call any Management API endpoints, you must authenticate using a specialized [Access Token](/tokens/overview-access-tokens) called the Management API Token. Management API Tokens are [JSON Web Tokens (JWTs)](/tokens/concepts/jwts) that contain specific granted permissions (also known as scopes) for the Management API endpoints you want to call. + +## Limitations + +Since single-page applications (SPAs) are public clients and cannot securely store sensitive information (such as a **Client Secret**), they must retrieve Management API Tokens from the frontend, unlike other [application types](/applications). This means that Management API Tokens for SPAs have certain limitations. Specifically, they are issued in the context of the user who is currently signed in to Auth0 which limits updates to only the logged-in user's data. Although this restricts use of the Management API, it can still be used to perform actions related to updating the logged-in user's user profile. + +::: warning +Auth0 does not recommend putting Management API Tokens on the frontend that allow users to change user metadata. This can allow users to manipulate their own metadata in a way that could be detrimental to the functioning of the applications. It also allows a customer to do a DoS attack against someone's management API by just spamming it and hitting rate limits. +::: + +## Available scopes and endpoints + +With a Management API Token issued for a SPA, you can access the following scopes (and hence endpoints). + +::: note +Password changes through the [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) endpoint are **not possible** with a Management API Token issued for a SPA. +::: + +| **Scope for Current User** | **Endpoint** | +| -------------------------- | ------------ | +| `read:current_user` | [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id)
[GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) | +| `update:current_user_identities` | [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities)
[DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) | +| `update:current_user_metadata` | [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | +| `create:current_user_metadata` | [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | +| `delete:current_user_metadata` | [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) | +| `create:current_user_device_credentials` | [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) | +| `delete:current_user_device_credentials` | [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | + +::: note +The above scopes and endpoints are subject to [rate limits](/policies/rate-limits#access-tokens-for-spas). +::: + +## Use Management API Token to call Management API from a SPA + +You can retrieve a Management API Token from a SPA and use the token to call the Management API to retrieve the full user profile of the currently logged-in user. + +1. Retrieve a Management API token. Authenticate the user by redirecting them to the Authorization endpoint, which is where users are directed upon login or sign-up. When you receive the Management API Token, it will be in [JSON Web Token format](/tokens/references/jwt-structure). Decode it and review its contents. + +2. Call the Management API to retrieve the logged-in user's user profile from the [Get User by ID](/api/management/v2#!/Users/get_users_by_id) endpoint. To call the endpoint, include the encoded Management API Token you retrieved in the `Authorization` header of the request. Be sure to replace the `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with the logged-in user's user ID (`sub` value from the decoded Management API Token) and the Management API Access Token, respectively. + +## Keep reading + +* [Management API Explorer](/api/management/v2#!) +* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens) diff --git a/fr-ca/articles/api/management/v2/get-access-tokens-for-test.md b/fr-ca/articles/api/management/v2/get-access-tokens-for-test.md new file mode 100644 index 0000000000..ad6a3e6b1b --- /dev/null +++ b/fr-ca/articles/api/management/v2/get-access-tokens-for-test.md @@ -0,0 +1,58 @@ +--- +description: How to get an Access Token manually for testing purposes. +section: apis +toc: true +topics: + - apis + - management-api + - tokens +contentType: + - How-to +useCase: invoke-api +--- + +# Get Access Tokens for Testing + +::: warning +This method for obtaining Access Tokens is **only for test purposes**. Do not get manually long-lived tokens and use them in your applications, because that nullifies the security advantages that tokens offer. +::: + +## Prerequisite + +* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app). + +## Get Access Tokens Manually + +1. Go to [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer). +A token is automatically generated and displayed there. + +2. Click __Copy Token__. +You can now make authorized calls to the [Management API](/api/management/v2) using this token. + +![Test Application](/media/articles/api/tokens/copy-token.png) + +3. Set expiration time. +This token has, by default, an expiration time of __24 hours__ (86400 seconds). After that period, the token expires and you will need to get a new one. To change the expiration time, update the __Token Expiration (Seconds)__ field and click __Update & Regenerate Token__. + +:::warning +These tokens **cannot be revoked** so long expiration times are not recommended. Instead we recommend that you use short expiration times and issue a new one every time you need it. +::: + +## Use Access Tokens for Testing + +To use the Access Token you just created for testing purposes, use the [Management API v2 explorer page](/api/management/v2) to manually call an endpoint with the token. + +1. Go to the [Management API v2 explorer page](/api/management/v2#!). +1. Click the __Set API Token__ button at the top left. +1. Set the __API Token__ field, and click __Set Token__. +1. Under the __Set API Token__ button at the top left, some new information is now displayed: the domain and token set, and the scopes that have been granted to this application. +1. Go to the endpoint you want to call, fill any parameters that might be required and click __Try__. + +![Set the Token](/media/articles/api/tokens/set-token.png) + +## Keep reading + +* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production) +- [Applications](/applications) +* [Management API Explorer](/api/management/v2#!) +* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens) diff --git a/fr-ca/articles/api/management/v2/tokens-flows.md b/fr-ca/articles/api/management/v2/tokens-flows.md new file mode 100644 index 0000000000..18ddec7612 --- /dev/null +++ b/fr-ca/articles/api/management/v2/tokens-flows.md @@ -0,0 +1,49 @@ +--- +description: Describes what changed in the flow for generating Auth0 Management APIv2 tokens and why. +section: apis +crews: crew-2 +toc: true +topics: + - apis + - management-api + - tokens +contentType: concept +useCase: invoke-api +--- +# Changes in Auth0 Management APIv2 Tokens + +Some time ago, we changed the process of getting a Management APIv2 Token. This article explains what changed, why this was done, and how you can work around it (not recommended). + +## What changed and why + +### The User Experience + +Until recently, you could generate a Management APIv2 Token directly from the Management API explorer. You selected the scopes, according to the endpoint you wanted to invoke, and got a token from that same page. + +That way was very easy but it was also __very insecure__. So we changed it. + +The new way uses the [Client Credentials Flow](/flows/concepts/client-credentials). + +::: note +For details on how to follow this new process, see [Access Tokens for the Management API](/api/management/v2/tokens). +::: + +#### Why this changed + +To generate the token, the Management API required access to your __Global Client Secret__ (used to sign the token). This is information that should __not__ be exposed to web browsers. + +Furthermore, the API Explorer has no way to do authorization. This means that if a user could login and access the API explorer, they could generate a token with __any__ scope, even if they were not allowed to have that scope. + +The new OAuth 2.0 Client Credentials grant implementation does not pose such risks. Once you do the initial configuration, you can get a token either by visiting the dashboard, or by making a simple `POST` request to [the `/oauth/token` endpoint of our Authentication API](/api/authentication#client-credentials). + +However, with regards to the manual process, we do understand that changing screens is not always the best user experience, so we are looking into ways to make the new flow more intuitive. + +### The Validity Period + +With the previous flow, the tokens never expired. With the new flow, all Management APIv2 Tokens __expire by default after 24 hours__. + +#### Why this changed + +Having a token that never expires can be very risky, in case an attacker gets hold of it. If the token expires within a few hours the attacker has only a small window to access your protected resources. + +To get a token, you should follow only the process described in [Access Tokens for the Management API](/api/management/v2/tokens). diff --git a/fr-ca/articles/api/management/v2/tokens.md b/fr-ca/articles/api/management/v2/tokens.md new file mode 100644 index 0000000000..4d99886e40 --- /dev/null +++ b/fr-ca/articles/api/management/v2/tokens.md @@ -0,0 +1,38 @@ +--- +description: Overview of how Auth0 Management APIv2 Access Tokens work and how to use them. +section: apis +topics: + - apis + - management-api + - tokens +contentType: + - concept +useCase: invoke-api +--- + +# Access Tokens for the Management API + +To call the [Auth0 Management API v2](/api/management/v2) endpoints, you need to authenticate with a token called the __Auth0 Management API Token__. This token is a JSON Web Token (JWT) and it contains specific granted permissions (known as __scopes__). + +To call an endpoint for test purposes, you can get a token manually using the Dashboard. For production however, the recommended best practice is to get short-lived tokens programmatically. + +To call endpoints, you will need to do the following: + +* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app) +* [Get Access Tokens for Testing](/api/management/v2/get-access-tokens-for-test) +* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production) + +::: note +For single-page applications (SPAs), there are some limitations. See [Get Management API Tokens for SPAs](/api/management/v2/get-access-tokens-for-spas) for more information. +::: + +## Keep reading + +* [Access Tokens](/tokens/concepts/access-tokens) +* [Management API Access Token FAQs](/api/management/v2/faq-management-api-access-tokens) +* [Changes in Auth0 Management API Tokens](/api/management/v2/tokens-flows) +* [Client Credentials Flow](/flows/concepts/client-credentials) +* [Ask for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) +* [User Search](/users/search) +* [User Search Query Syntax](/users/search/v3/query-syntax) + diff --git a/fr-ca/articles/api/postman.md b/fr-ca/articles/api/postman.md new file mode 100644 index 0000000000..7bdcb17983 --- /dev/null +++ b/fr-ca/articles/api/postman.md @@ -0,0 +1,61 @@ +--- +description: Learn how to use Postman Collections to access Auth0 APIs. +section: apis +topics: + - management-api + - authorization-api + - apis +contentType: how-to +useCase: invoke-api +--- + +# Use Auth0 APIs with Postman Collections + +## Install Postman Collections + +To install the Postman Collection, you must first install the Postman App for Windows, Mac, or Chrome. You can download any of these from[Postman Apps](https://www.getpostman.com/apps). + +Next, visit [Auth0 APIs](/api/info) and install the Collection you want to use by clicking on the relevant **Run in Postman** button. + +![Auth0 API Postman Button](/media/articles/api/postman/auth0-api-landing.png) + +Postman will prompt whether you want to open the Collection in Postman for Chrome or Postman for Windows/Mac. Select the application you installed. + +Once you make a selection, the selected Postman application will open and the collection will be imported. + +Our API Collections are organized into folders that categorize the various API calls according to category. For example, you will find all the Users methods under the **Users** folder in the Management API. + +## Configure Postman Environment + +The Auth0 Postman Collections make use of environment variables to customize the requests that are sent. To learn more about managing Postman environments, see [Setting up an environment with variables](https://learning.postman.com/docs/postman/variables-and-environments/variables/). + +You must create an environment and configure the following variables: + +| Variable | Description | +| -- | -- | +| `auth0_domain` | Should contain the domain for your Auth0 tenant, such as `jerrie.auth0.com`. | +| `auth0_token` | Should contain the token needed to make calls to the Management API. Is only required when using the Management API collection. To learn more, see [How to Get an Access Token for the Management API](/api/management/v2/tokens). | + +In the screenshot below, you can see a Postman environment configured with both the `auth0_domain` and `auth0_token` variables defined: + +![Environment Configured](/media/articles/api/postman/environment-configured.png) + +## Execute requests + +Once the environment is configured, you can follow these steps to execute an Auth0 API method: + +1. Select the environment with which you want to work. +2. Select the relevant API method in the collection folder. +3. Click the **Send** button. + +![Execute API Method](/media/articles/api/postman/execute-api-method.png) + +You may also have to configure query parameters or the JSON method body, depending on the API call. To learn more, see [Sending Requests](https://learning.getpostman.com/docs/postman/sending-api-requests/requests/). + +::: warning +Storing tokens in Postman as environment variables could pose a security risk. If you are signed in to the Postman application, it will automatically try to [synchronize entities such as Collections and Environments with the Postman servers](https://www.getpostman.com/docs/sync_overview). This means that a token, which could allow someone else to gain access to your Management API, is leaving the privacy of your computer and being uploaded to Postman's servers. + +That said, Postman has taken measures to ensure that tokens are encrypted and encourages users to store them in Environment Variables. You can read more at [Postman Security](https://www.getpostman.com/security). + +If you feel that this still poses too much of a risk, then you will need to sign out of Postman to ensure that environment variables are not synchronized. +::: \ No newline at end of file diff --git a/fr-ca/articles/appliance/admin/backing-up-the-appliance-instances.md b/fr-ca/articles/appliance/admin/backing-up-the-appliance-instances.md new file mode 100644 index 0000000000..a8a8111de9 --- /dev/null +++ b/fr-ca/articles/appliance/admin/backing-up-the-appliance-instances.md @@ -0,0 +1,20 @@ +--- +section: appliance +description: Recommendations on when to back up PSaaS Appliance instances +topics: + - appliance + - backups +contentType: concept +useCase: appliance +applianceId: appliance1 +sitemap: false +--- + +# PSaaS Appliance Administration: Appliance Backups + +If the PSaaS Appliance is used in a stateless way (such as authentication, SSO), Auth0 recommends that you take **weekly** backups of all nodes using virtual machine snapshots. + +If the PSaaS Appliance is only used to store data (such as database connections, user metadata), Auth0 recommends that you take **daily** backups of all nodes using virtual machine snapshots. + +## For More Information: +- [How to Back Up the PSaaS Appliance Using the CLI](/appliance/cli/backing-up-the-appliance) diff --git a/fr-ca/articles/appliance/admin/disabling-sign-ups.md b/fr-ca/articles/appliance/admin/disabling-sign-ups.md new file mode 100644 index 0000000000..219fc4f573 --- /dev/null +++ b/fr-ca/articles/appliance/admin/disabling-sign-ups.md @@ -0,0 +1,41 @@ +--- +description: Auth0 suggests that you disable sign-ups for the `Initial-Connection` database connection prior to going live in your production environments. +section: appliance +topics: + - appliance + - signups +contentType: how-to +useCase: appliance +applianceId: appliance3 +sitemap: false +--- + +# PSaaS Appliance Administration: Disabling Sign-Ups + +The PSaaS Appliance, when running in multi-tenancy mode, behaves just like the Auth0 cloud environment. Users will be able to sign up and create new accounts in the cluster, and this ability is *not* limited to internal users. For this reason, Auth0 suggests that you disable sign-ups for the `Initial-Connection` database connection prior to going live in your production environments. + +::: panel-warning Connections for the Auth0 Application +The **Auth0** application in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this application is the built-in Database Connection (the default Connection for this application is a Database Connection called *Initial-Connection*) or an enterprise connection like the AD-LDAP Connector. You should **never** enable a Social Connection for the **Auth0** application. + +Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** application. +::: + +Disabling signups will prevent users from signing up for an account in your PSaaS Appliance. Therefore, if you want to [invite co-administrators](/appliance/admin/inviting-coadmins) to a specific tenant, you will need to do the following: + +* create the user manually using the Dashboard; +* send the newly-created user's credentials to your co-administrator; +* invite the user to the appropriate account. + +## How to Disable Signups for a Connection + +Log in to the Auth0 Management Dashboard. + +![Auth0 Management Dashboard Landing Page](/media/articles/appliance/admin/mgmt-dashboard.png) + +Using the left-hand navigation menu, go to **Connections > Database**. + +![Database Connections Page](/media/articles/appliance/admin/connections.png) + +Click the row corresponding to **Initial-Connection** (or the connection for which you are disabling sign-ups). You will be directed to the *Settings* page. Scroll to the bottom, and enable the slider corresponding to the row that reads **Disable Sign Ups**. + +![Connections Settings Page](/media/articles/appliance/admin/disable-sign-ups.png) diff --git a/fr-ca/articles/appliance/admin/federated-access-to-manage.md b/fr-ca/articles/appliance/admin/federated-access-to-manage.md new file mode 100644 index 0000000000..a5633b68fd --- /dev/null +++ b/fr-ca/articles/appliance/admin/federated-access-to-manage.md @@ -0,0 +1,65 @@ +--- +description: How to set up federated login to the Manage Dashboard +section: appliance +topics: + - appliance + - admin + - signups +contentType: how-to +useCase: appliance +applianceId: appliance76 +sitemap: false +--- +# Set Up Federated Login to the Manage Dashboard + +If you use an Identity Provider (IdP) to handle your staff logins, you can use the IdP with your root tenant authority (otherwise known as the RTA or your config tenant) to provide federated access to your Dashboard. + +By using your IdP, this eliminates the need for you to: + +* *For customer-hosted PSaaS Appliance:* Manually create users in the root tenant authority (RTA) +* *For Auth0-hosted PSaaS Appliance:* Open a support case requesting the addition of a Dashboard administrator. + +::: note +If you have an Auth0-hosted PSaaS Appliance, but you do not have access to the root tenant, please submit a [Support Ticket](${env.DOMAIN_URL_SUPPORT}) and the Appliance Services staff will help you set this up. +::: + +## Setting Up Federated Access + +The Auth0 root tenant acts as an identity provider (IdP) for the Manage Dashboard. As such, you will need to add a Service Provider (SP) to your existing IdP to federate access to the Manage Dashboard. + +This process requires the following three steps: + +1. Set up the Auth0 Service Provider (SP) + *For customers with Auth0-hosted PSaaS Appliance: Auth0 will create the Connection for you after you provide the necessary setup information.* +2. Provide your Service Provider metadata to the Identity Provider (IdP) +3. Test the Identity Provider + +Please note that how you complete the three steps above differ slightly based on whether you're working with a customer-hosted PSaaS Appliance or an Auth0-hosted PSaaS Appliance. + +### Customer-hosted PSaaS Appliance + +[Configure Auth0 as the Service Provider (SP)](/protocols/saml/saml-configuration/auth0-as-service-provider) and use both the root tenant authority and the new Service Provider Connection to access Auth0. + +### Auth0-hosted PSaaS Appliance + +[Configure Auth0 as the Service Provider (SP)](/protocols/saml/saml-configuration/auth0-as-service-provider). Follow the tutorial up through the section where you identify the Identity Provider (IdP) and Connection protocol (you will be stopping at the section where you're shown how to Configure Auth0). + +Please be sure to configure your mappings between Auth0 (as the SP) and your IdP in the form of Assertions. You can do so in the Dashboard by going to **Connections** > **Enterprise** > **SAMLP Identity Provider**. Find your connection, and click the cog icon to launch the **Settings** tab. Switch to the **Mappings** view, and provide mappings for **name**, the **name format** (optional), and **value**. The specifics will vary based on the IdP you're using, so please contact Auth0 if you have any questions. + +At this point, send Auth0 the information you've collected in a [Support Ticket](${env.DOMAIN_URL_SUPPORT}) and request that you be granted federated access to the config tenant/RTA. + +In your Support ticket, you should include: + +* The **email domain(s)** that will be redirected to your Identity Provider +* The Identity Provider's **single sign-on URL** +* The Identity Provider's **public key** (encoded in PEM or CER format) +* The **sign out URL** (optional) + +You can find most of this information in the XML metadata file provided by your Identity Provider. If you'd prefer, you can send Auth0 this file, along with the email domains that you will be redirecting to the IdP. + +Once Auth0 receives all of the information we need, we will: + +* Create a Connection in your root tenant +* Provide you with the metadata link containing the information you need to provide to your Identity Provider + +Once you provide this information (as well as the callback URL and the Entity ID) to your IdP, you will be able to test your federated Login to the Dashboard. \ No newline at end of file diff --git a/fr-ca/articles/appliance/admin/importance-of-updates.md b/fr-ca/articles/appliance/admin/importance-of-updates.md new file mode 100644 index 0000000000..c38ad249b4 --- /dev/null +++ b/fr-ca/articles/appliance/admin/importance-of-updates.md @@ -0,0 +1,35 @@ +--- +section: appliance +description: Why it is important to regularly update the PSaaS Appliance +topics: + - appliance + - updates + - security +contentType: concept +useCase: appliance +applianceId: appliance75 +sitemap: false +--- +# Why You Should Update the PSaaS Appliance Regularly + +Though the Auth0 engineering team releases updates to the PSaaS Appliance on a monthly basis, we understand that such frequent updates to your environment (though ideal) are not always possible. Regardless, we recommend updating your PSaaS Appliance on a bi-monthly or quarterly basis at the very least. + +In this article, we will cover why it is essential to update your PSaaS Appliance regularly. + +## Benefits to updating the PSaaS Appliance + +First, each major release contains all of the new features and improvements to existing features that we have made since the prior version. + +However, even if you are happy with your existing feature set, there are also benefits to updating the PSaaS Appliance that extend beyond technological improvements and feature updates. + +More specifically, each major release for the PSaaS Appliance includes fixes for all of the known issues discovered during normal usage of Auth0. We aim to provide as smooth an experience as possible for all of our customers, but an issue-free release is not possible. As such, we ship updates that correct any issues that might become apparent. + +## Problems that may arise due to delayed or skipped updates + +By upgrading routinely, you can be assured that you are working with a version of the PSaaS Appliance that is fully-functional and secure. Conversely, if you do not upgrade, your environment becomes, over time, unsupported and less secure. + +Furthermore, lack of updates to the PSaaS Appliance over time makes it difficult when you do get to the point where you want to update. Because updates are cumulative, skipping updates means that you will have more changes that need to be tested. By updating at each possible opportunity, you are making smaller, incremental changes to your environment. + +## Testing in the Development Environment to ensure smooth updates + +Auth0 provides a Development environment at no cost to you. The purpose of this environment is to test future upgrades to identify any issues before updating your Production environment. Auth0 works with you to resolve any problems identified during your testing, and only when both parties are comfortable should the upgrade proceed to Production. diff --git a/fr-ca/articles/appliance/admin/index.md b/fr-ca/articles/appliance/admin/index.md new file mode 100644 index 0000000000..cdde2ec3c8 --- /dev/null +++ b/fr-ca/articles/appliance/admin/index.md @@ -0,0 +1,26 @@ +--- +url: /appliance/admin +section: appliance +description: > + This document covers factors PSaaS Appliance administrators should be aware of when working with production PSaaS Appliance. +topics: + - appliance + - administration +contentType: index +useCase: appliance +applianceId: appliance4 +sitemap: false +--- + +# PSaaS Appliance: Administrator's Manual + +This document covers factors PSaaS Appliance administrators should be aware of when working with production PSaaS Appliance instances. + +* [Managing the Dashboard](/appliance/admin/managing-the-dashboard) +* [Disabling Sign-ups](/appliance/admin/disabling-sign-ups) +* [Inviting/Adding Co-Administrators](/appliance/admin/inviting-coadmins) +* [Backing up the PSaaS Appliance](/appliance/admin/backing-up-the-appliance-instances) +* [Monitoring & Performing Health Checks on Load Balancers](/appliance/admin/monitoring) +* [Updating the PSaaS Appliance](/appliance/admin/updating-the-appliance) + * [Why You Should Update the PSaaS Appliance Regularly](/appliance/admin/importance-of-updates) +* [Configuring Custom Error Pages](/universal-login/custom-error-pages) diff --git a/fr-ca/articles/appliance/admin/inviting-coadmins.md b/fr-ca/articles/appliance/admin/inviting-coadmins.md new file mode 100644 index 0000000000..a5f17a2222 --- /dev/null +++ b/fr-ca/articles/appliance/admin/inviting-coadmins.md @@ -0,0 +1,42 @@ +--- +section: appliance +description: How to invite additional administrators to your PSaaS Appliance +topics: + - appliance + - coadmins +contentType: how-to +useCase: appliance +applianceId: appliance5 +sitemap: false +--- + +# PSaaS Appliance Administration: Inviting Co-Administrators + +::: panel-warning PSaaS Appliance in the Dedicated Cloud Service +If you have a PSaaS Appliance in the Dedicated Cloud Service, you do not have access to the RTA tenant, since Auth0 manages this on your behalf. To add new administrators, you'll need to [contact Support](${env.DOMAIN_URL_SUPPORT}) (be sure to mention that you have a PSaaS Appliance in the Dedicated Cloud Service). + +If you're an existing tenant administrator, you can simply forward the tenant administrator invitation link to new administrators. +::: + +You may invite additional users to become co-administrators of your PSaaS Appliance. This is done via the PSaaS Appliance configuration area of the Management Dashboard. + +::: panel Root Tenant Authority +Administrators for the PSaaS Appliance are authenticated with the root tenant authority (RTA, the primary tenant, sometimes called the **config** tenant). The Dashboard is represented by the **"Auth0"** app/client in the RTA account. By default the RTA has a DB connection enabled, **"Initial-Connection"**, that is used to authenticate Dashboard users. +Since that connection has signups disabled, users will be have to be created beforehand. +::: + +[![](/media/articles/appliance/admin/invite-co-admins.png)](https://auth0-1.wistia.com/medias/2t8n98qc5j) + +1. In the RTA tenant (usually named **rta** or **config**) add a new user in the **Initial-Connection** connection with the email of the administrator you will invite, and choose a password. Please see the section on [adding users via the Management Dashboard](/creating-users) for additional information. + +2. Switch over to the App Tenant so that you will have access to the PSaaS Appliance configuration options. + +3. Open up the Account Settings page. + +4. Navigate to the Dashboard Admins tab. + +5. Click "Add" to add the user as an administrator. You will be asked to provide the user's email address and to set the Applications over which they will have administrative rights. When finished, click "Send Invite". + +At this point, if you have SMTP configured on the PSaaS Appliance, the user will receive an email inviting them to log in as an administrator. They will need to use the email and password used in step 1. + +If you do not have SMTP configured, hover over the "pending" link next to the user's name, copy the link, and forward it, along with the new username/password, to the user. The user will be able to use the link and credentials to log in as an administrator. diff --git a/fr-ca/articles/appliance/admin/limiting-ssh-access.md b/fr-ca/articles/appliance/admin/limiting-ssh-access.md new file mode 100644 index 0000000000..4d0b93b513 --- /dev/null +++ b/fr-ca/articles/appliance/admin/limiting-ssh-access.md @@ -0,0 +1,18 @@ +--- +section: appliance +description: When and why you should grant SSH access to the PSaaS Appliance +topics: + - appliance + - ssh + - security +contentType: concept +useCase: appliance +applianceId: appliance6 +sitemap: false +--- + +# PSaaS Appliance Administration: Limiting SSH Access + +Auth0 requires SSH access in order to connect to the PSaaS Appliance to perform updates or troubleshooting/accessing required logs. These are the only instances where SSH (by default, port 22) should be exposed on the nodes. + +In all other instances, Auth0 recommends restricting SSH access to the PSaaS Appliance. For Appliance deployments in the cloud, you would *not* enable the SSH endpoint for your virtual machines. For on-premise PSaaS Appliance deployments, you would deny SSH to the virtual machines in your corporate firewall. diff --git a/fr-ca/articles/appliance/admin/managing-the-dashboard.md b/fr-ca/articles/appliance/admin/managing-the-dashboard.md new file mode 100644 index 0000000000..5ad7477bc3 --- /dev/null +++ b/fr-ca/articles/appliance/admin/managing-the-dashboard.md @@ -0,0 +1,61 @@ +--- +section: appliance +description: How to access and restrict access to the PSaaS Appliance Management Dashboard +topics: + - appliance + - dashboard +contentType: how-to +useCase: appliance +applianceId: appliance7 +sitemap: false +--- + +# PSaaS Appliance Administration: Manage the Dashboard + +## Access the Dashboard + +::: panel-warning Connections for the Auth0 Application +The **Auth0** application in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this application is the built-in Database Connection (the default Connection for this application is a Database Connection called *Initial-Connection*) or an enterprise connection like the AD-LDAP Connector. You should **never** enable a Social Connection for the **Auth0** application. + +Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** application. +::: + + +The [Auth0 Dashboard](/appliance/dashboard) uses the PSaaS Appliance to authenticate its users. + +Within the list of applications, you will see the Auth0 Application, which represents the Dashboard itself. It uses a connection called `Initial-Connection`, which stores the credentials of the administrators that have access to the Dashboard. + +::: note +Changes to the Auth0 Application or `Initial-Connection` may result in unexpected Dashboard behavior. Please makes changes with caution. +::: + +Because the Dashboard uses the PSaaS Appliance for authentication, any configured rules will run whenever a user accesses the Dashboard. Because errors in one or more of your rules may result in you losing access to the Dashboard, Auth0 suggests writing rules that exclude the Auth0 application: + +```js + +function (user, context, callback) { + if (context.clientName === 'Auth0') { + return callback(null, user, context); + } + + // Your code. + + callback(null, user, context); +} + +``` + +::: note +The default user `root@auth0.com` has access to the PSaaS Appliance and its configuration area. To prevent unauthorized access with this account, you should block this user via the Auth0 Dashboard. +::: + +To block the user, click *Actions*. Then, in the drop-down menu that appears, click *Block User*. + +## Restrict Access to the Dashboard + +Because the Dashboard uses the PSaaS Appliance to authenticate users, the Dashboard is using Connections, [Rules](/rules), and so on, just like any other application you might add in the future. + +As a result, you have several options for restricting access to the dashboard, including, but not limited to: + +* Writing rules to allow users only from a specific IP address; +* Writing rules to allow only co-administrators of the PSaaS Appliance to authenticate using their Active Directory (via either ADFS or AD Connector). diff --git a/fr-ca/articles/appliance/admin/monitoring.md b/fr-ca/articles/appliance/admin/monitoring.md new file mode 100644 index 0000000000..751be898b9 --- /dev/null +++ b/fr-ca/articles/appliance/admin/monitoring.md @@ -0,0 +1,25 @@ +--- +section: appliance +description: How to monitor the PSaaS Appliance +topics: + - appliance + - monitoring +contentType: how-to +useCase: appliance +applianceId: appliance8 +sitemap: false +--- + +# PSaaS Appliance Administration: Monitoring + +While your existing monitoring platform may already collect data (such as metrics on CPU, disk size, and so on.) at the virtual machine level, it may exclude information regarding the nodes in the cluster. + +Because of this, Auth0 provides [tools for monitoring your individual cluster nodes](/appliance/monitoring). + +For information about general Auth0 Monitoring, please see [this page](monitoring). + +## Performing Health Checks on Load Balancers + +When running the PSaaS Appliance in a High Availability setup, the load balancers will distribute the load over all nodes in the cluster. Most load balancers perform their own health checks on all of the servers to which they distribute the load, allowing them to remove non-responsive servers out of rotation. + +Once source of information for the load balancer can be obtained by running the HTTP health checks to each node in the cluster using the [`testall`](/appliance/monitoring/testall) endpoint. diff --git a/fr-ca/articles/appliance/admin/rate-limiting.md b/fr-ca/articles/appliance/admin/rate-limiting.md new file mode 100644 index 0000000000..5e276a2e64 --- /dev/null +++ b/fr-ca/articles/appliance/admin/rate-limiting.md @@ -0,0 +1,74 @@ +--- +title: Rate Limiting in the PSaaS Appliance +description: How to enable, configure, and test for rate limiting in the Appliance +topics: + - appliance + - rate-limiting +contentType: how-to +useCase: appliance +applianceId: appliance9 +sitemap: false +--- +# PSaaS Appliance: Rate Limiting + +Rate limits for API endpoints can be enabled and configured in the Dashboard. Rate limiting in the PSaaS Appliance is done using [limitd](https://github.com/limitd/limitd#buckets). + +## Enable and Configure Rate Limiting + +In the PSaaS Appliance Dashboard, go to **Rate Limiting**. + +![](/media/articles/appliance/admin/rate-limiting-1.png) + +Click the checkbox next to **Enable** to enable rate limiting. + +![](/media/articles/appliance/admin/rate-limiting-2.png) + +By default, **Configuration of buckets** is empty, which means that limitd's default configuration will be used. Your Customer Success Engineer may advise you to adjust this value if appropriate. + +Click **Save** and wait for the updates to the configuration to complete. + +![](/media/articles/appliance/admin/rate-limiting-3.png) + +## Test Rate Limiting Functionality + +When you've enabled rate limiting, the HTTP response includes the following headers: + +* X-RateLimit-Limit: Request limit +* X-RateLimit-Remaining: Requests available for the current time frame +* X-RateLimit-Reset: Time until the rate limit resets (in UTC [epoch seconds](https://en.wikipedia.org/wiki/Unix_time)) + +To verify that rate limiting is working, you can send a call to any [rate-limited API endpoint](/policies/rate-limits#endpoints-with-rate-limits), such as the [Get All Connections endpoint](/api/management/v2#!/Connections/get_connections): + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer MGMT_API_ACCESS_TOKEN" + }] +} +``` + +Your expected response looks something like this: + +```text +HTTP/1.1 200 OK +Date: Wed, 01 Nov 2017 19:52:28 GMT +Content-Type: application/json; charset=utf-8 +Content-Length: 366 +Connection: keep-alive +Keep-Alive: timeout=100 +x-ratelimit-limit: 50 +x-ratelimit-remaining: 49 +x-ratelimit-reset: 1509565949 +vary: origin,accept-encoding +cache-control: no-cache +accept-ranges: bytes +Strict-Transport-Security: max-age=15724800 +X-Robots-Tag: noindex, nofollow, nosnippet, noarchive + +[{"id":"con_sw...O","options":{"mfa":{"active":true,"return_enroll_settings":true},"disable_signup":true,"brute_force_protection":true,"strategy_version":2},"strategy":"auth0","name":"Initial-Connection","enabled_clients":["aCb...C","ef7...Z"],"is_domain_connection":false,"realms":["Initial-Connection"]}] +``` diff --git a/fr-ca/articles/appliance/admin/updating-the-appliance.md b/fr-ca/articles/appliance/admin/updating-the-appliance.md new file mode 100644 index 0000000000..bfec4751aa --- /dev/null +++ b/fr-ca/articles/appliance/admin/updating-the-appliance.md @@ -0,0 +1,119 @@ +--- +section: appliance +description: How to update the PSaaS Appliance +toc: true +topics: + - appliance + - updates +contentType: how-to +useCase: appliance +applianceId: appliance10 +sitemap: false +--- +# Updating the PSaaS Appliance + +To [ensure that your PSaaS Appliance has the latest functionality, security, and bug fixes](/appliance/admin/importance-of-updates), Auth0 requires you to perform regular updates. While the Auth0 engineering team releases updates on a monthly basis, you should plan updates on a monthly, bi-monthly, and quarterly basis. + +Appliances must be updated using a **major release** at least once every **90 days**. + +## Releases + +For more information about PSaaS Appliance Releases, please see the [Change Log](https://auth0.com/changelog/appliance). + +## Types of updates + +There are two types of updates: **major** and **minor** releases. + +### Major releases + +**Major releases** can be identified by changes in the PSaaS Appliance version number (i.e. from **14591.X** to **15838.X**). These updates include new features and/or changes in existing functionality. + +### Minor releases + +**Minor releases** (or patch releases) can be identified by changes in the *decimal* value of the version number (i.e. **15838.35** is a minor update to **15838.31**). + +Patches are cumulative; that is, patch **15838.85** includes changes included in all prior patches (**15838.75**, **15838.43**, **15838.36**, **15838.35**, and **15838.31**). + +You do *not* need to install all released patches, but we recommend doing so since patches typically include things like bug and security fixes. + +## The update process + +The update process will vary slightly depending on whether you have an **Auth0-hosted PSaaS Appliance** or a **self-hosted PSaaS Appliance**. + +### Auth0-hosted PSaaS Appliance + +When you are ready to update, submit a Support ticket indicating: + +* That you are ready to update your Development environment +* When you would like Auth0 to perform the upgrade +* What version you would like to upgrade to + +We will contact you to determine the specific time frame during which the update occurs. + +Once we have updated your Development environment, we recommend you spend one week testing. If, at that point, everything is working, we will schedule a time frame for updates to the Production environment(s). + +### Self-hosted PSaaS Appliance + +You can apply **minor** updates without coordination with Auth0. However, we recommend updating your Development nodes and testing prior to applying the changes to your Production environment. + +For **major** updates, please submit a Support ticket and Auth0 will reach out to confirm if manual intervention on the part of Auth0 is required. + +To ensure the update process goes as smoothly as possible, we recommend following the best practices detailed below. + +#### Prior to the Update + +* Take a VM snapshot of each node you're updating. +* Ensure that you've enabled access to your nodes for the Auth0 Customer Success Engineer who will be assisting you with the update. +* Complete the pre-check test **one hour** prior the start of the update. + * Please be sure that your infrastructure engineer has administrative access to the Dashboard (specifically the Root Tenant Authority). + * Ensure that all [Health Checks](/appliance/dashboard/troubleshoot#health-check) are okay. +* For multi-node clusters, check the **Enable Sequential Updates** box if you want to reduce downtime during the update. + +::: note +For additional information on gathering testing information, please see [PSaaS Appliance Monitoring](/appliance/monitoring). +::: + +* Update the Development/Test environment prior to upgrading Production. This allows you to test the new version to identify any issues before you apply it to Production. We recommend performing this test for a one-week period. +* Ensure that the PSaaS Appliance is able to access the internet during the update process, as well as the outbound IP addresses listed in the ["Updates" column](/appliance/infrastructure/ip-domain-port-list#external-connectivity). The update is [triggered via the Management Dashboard](/appliance/dashboard/updates) and requires the downloading of the application itself, as well as any operating system updates. + +#### After the update + +::: note +For additional information on gathering testing information, please see [PSaaS Appliance Monitoring](/appliance/monitoring). +::: + +* Perform the post-test check: + * Check to see if all instances list the same update count and that they're currently running the latest version. + * Check that all Health Checks are okay. + +* Run smoke tests to ensure that there are no issues with the update. + + The specifics of what constitutes a complete smoke check for your PSaaS Appliance varies, since the appropriate tests vary based on your implementation and usage of Auth0. Furthermore, each organization prefers different levels of detail when it comes to testing -- some prefer more thorough testing than others. Regardless, we recommend testing at the very least: + + 1. All application functionality that involves authentication flows or user identity changes + 2. Basic access to the Auth0 Management Dashboard + + Some of the areas and processes that you might consider including in your smoke tests include: + + * Registration + * Login (including those involving Social or other identity providers) + * Logout + * Password reset + * Single sign-on (SSO) + * Passwordless/SMS login + * User metadata updates + * Machine-to-machine interactions + * SDK usage + * Mobile and desktop usage + * Login and use of the Auth0 Management Dashboard + * Extensions (make sure that the ones you've installed are functioning as expected + +Please remember that you are responsible for testing and ensuring that all of your applications work as expected. + +## Downtime + +During an upgrade, we expect there to be some downtime. For single-node clusters, we expect there to be 3-5 minutes of downtime. For multi-node clusters, we can perform updates sequentially, where users may see up to 30 seconds of downtime. + +Downtime occurs when we restart services. Because of this, we are willing to schedule updates to Production clusters during non-business hours. Please let us know your preferences in the Support Ticket. + +If you require your Production update during non-business hours, we ask that you confirm the day prior during normal business hours. diff --git a/fr-ca/articles/appliance/appliance-overview.md b/fr-ca/articles/appliance/appliance-overview.md new file mode 100644 index 0000000000..ed9bfb70b7 --- /dev/null +++ b/fr-ca/articles/appliance/appliance-overview.md @@ -0,0 +1,113 @@ +--- +section: appliance +description: The PSaaS Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. +topics: + - appliance +contentType: concept +useCase: appliance +applianceId: appliance52 +sitemap: false +--- + +# PSaaS Appliance Overview + +The PSaaS Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. The PSaaS Appliance can be deployed in one of three places: + +* a dedicated cloud environment hosted by Auth0 (you may opt for a shared cloud environment or an environment where resources are allocated only to your company). +* your cloud environment using **Amazon AWS** + +## Infrastructure + +If you opt to use a dedicated cloud environment hosted by Auth0, Auth0 is responsible for installation, maintenance, patching and updates. + +If you choose to deploy to your own cloud environment or data center, you supply and monitor the infrastructure Auth0 runs on. This includes the VM host, storage, network resources (such as the load balancer, internet access, and so on), and other required dependencies (such as the SMTP, NTP, and so on). + +## Deployment + +You may deploy the PSaaS Appliance in several different configurations and use several different deployment models. The configurations support different levels of scale and high availability, and they are available in any of the PSaaS Appliance deployment models. The following table shows the configuration options: + +PSaaS Appliance HA Options + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Single NodeHigh AvailabilityHigh Capacity
DescriptionIntended for development and testing environments.
  • Three-node redundant cluster
  • Tolerates a single-node outage
  • Recommended for most Production environments
  • Includes a single node for Dev/QA
  • Highly scalable capacity for the most demanding applications
  • Tolerates multi-node outages
  • Recommended for large-scale Production environments
  • Includes a single node for Dev/QA
Geo HANot Available
  • Multiple data center with active-passive clustering and automated failover
  • Auth0 continues to operate if a data center becomes unavailable
  • If the primary data center fails, traffic can quickly be routed to the secondary cluster
  • Cluster topology is replicated in each environment. Requires a global load balancing solution like AWS Route 53 or F5 Global Traffic Manager.
Backup and Recovery
  • Virtual Machine Snapshot
  • Data backup with cluster restore
  • Virtual Machine Snapshot
  • Virtual Machine shipping with scripted restore (if using VMWare)
  • Data backup with cluster restore
+ + +[Auth0 Deployment Models](/overview/deployment-models) provides additional details and explains the differences between each of the PSaaS Appliance deployment models and the standard multi-tenant cloud deployment. + +## Maintenance and Connectivity + +As a managed service, Auth0 performs: + +* initial setup and configuration; +* ongoing maintenance operations (security patching, troubleshooting, and updating). + +Auth0 will closely coordinate access to your PSaaS Appliance instances with your operations team, since these activities will often run on your infrastructure (such as your network, servers, and so on). Depending on the time it takes to prepare the required infrastructure and the deployment complexity, the PSaaS Appliance implementation project typically takes between 1-5 weeks. + +If Auth0 is managing a dedicated environment for you, Auth0 will obtain your consent prior to applying any updates or configuration changes. Auth0 will not access any PSaaS Appliance, nor will any information be transferred off of the PSaaS Appliance without your consent. + +### Connectivity + +During maintenance operations, the PSaaS Appliance instances contact external Auth0 endpoints for updating under your consent and supervision. After maintenance completes, you can [continue to operate with limited internet access](/appliance/infrastructure/internet-restricted-deployment). + +For normal maintenance, Auth0 will access the Management Dashboard (either over a temporary SSH connection or through remote control software) to apply the update. Auth0 will also need SSH access in the event that updates to the PSaaS Appliance are necessary. If you expose API endpoints to be used for monitoring, Auth0 will collect this information to proactively monitor PSaaS Appliance behavior for you. + +Depending on which features are implemented, you may need to permit access to certain websites on the Internet from each PSaaS Appliance instance. For example, if Facebook logins are needed, you must open connectivity from the Auth0 servers to `facebook.com`. If users will be logging in from the Internet (and not through a VPN), you must publish the authentication endpoints. + +### Update Cycle + +The typical update cycle is once per month. You can control and which version is applied. Occasionally, lower-level actions may be performed on the nodes. You will be notified in advance on the nature of activities to be performed, and will be provided instructions on any actions you may need to execute on your side. + +The diagram below details a few of these dependencies: + +Appliance Overview + +## Monitoring and Support + +You are responsible for monitoring all the dependencies the Auth0 Service relies on within your environment, such as the network load balancer, VM hosts, SMTP gateways, and so on. + +If you provide access to the appropriate monitoring endpoints, Auth0 will monitor the nodes' health and notify you of any conditions that require action. + +If Auth0 hosts the PSaaS Appliance for you, then Auth0 will monitor the related services. + +### Monitoring Endpoints +Auth0 provides specific monitoring endpoints that you can attach to your own monitoring tools (such as Microsoft System Center, IBM Tivoli, HP OpenView, and so on) for auditing, load balancing, and performance monitoring, such as in cases where the transaction under test includes application specific functionality (for example, a [rule](/rules) that integrates Auth0 with your own CRM). + +You may find detailed guidance at [Monitoring Auth0](/monitoring). + +In addition, the PSaaS Appliance has authenticated monitoring endpoints for metrics like CPU, memory, and disk space that you can query for more detailed information. + +If the PSaaS Appliance does not perform as expected, you can contact your Auth0 Customer Success Engineer. Auth0 provides an incident escalation procedure during the onboarding process that explains the steps to be followed when an incident occurs. Auth0 has a 24 x 7, around-the-clock support staff. + +## Server Requirements + +You will be asked to set up a Dev/Test (non-Production) environment, as well as a Production environment. + +For the Production environment, the number of virtual machines required to host the PSaaS Appliance depends on the expected traffic and the desired availability. For a highly-available configuration, the Production environment requires a minimum of three network load-balanced PSaaS Appliance instances and one for the Dev/Test (non-Production) environment (which also does *not* required any special load balancing logic/sticky sessions). diff --git a/fr-ca/articles/appliance/cli/adding-node-to-backup-role.md b/fr-ca/articles/appliance/cli/adding-node-to-backup-role.md new file mode 100644 index 0000000000..fad2cdabe9 --- /dev/null +++ b/fr-ca/articles/appliance/cli/adding-node-to-backup-role.md @@ -0,0 +1,35 @@ +--- +section: appliance +description: How to add an PSaaS Appliance node in the backup node +topics: + - appliance + - backups + - cli + - nodes +contentType: how-to +useCase: appliance +applianceId: appliance11 +sitemap: false +--- + +# PSaaS Appliance: Adding a Node to the Backup Role + +## Prerequisites + +* Backup can be configured on single or multiple-node setups. In multi-node setups, the backup must be placed on a non-primary device. +* **A separate, dedicated backup device** with sufficient space to store the backups on the node that you are assigning to the `backup` role. + +## Adding a Node to the Backup Role + +To add a node to the `backup` role, execute the `set-as-backup` command using the PSaaS Appliance's Command-Line Interface. When issuing this command, you will need to specify the device on the target node to be used to store backups. + +`$a0cli -t set-as-backup [force]` + +::: note + If you have already created a backup folder on the node, the command will fail unless you set the `force` argument to `true`. +::: + +## Additional Reading + +* [Configuring and Using the PSaaS Appliance Command Line Interface](/appliance/cli/configure-cli) +* [How to Back Up the PSaaS Appliance Using the CLI](/appliance/cli/backing-up-the-appliance) diff --git a/fr-ca/articles/appliance/cli/backing-up-the-appliance.md b/fr-ca/articles/appliance/cli/backing-up-the-appliance.md new file mode 100644 index 0000000000..f382361fb5 --- /dev/null +++ b/fr-ca/articles/appliance/cli/backing-up-the-appliance.md @@ -0,0 +1,126 @@ +--- +section: appliance +description: How to back up the PSaaS Appliance using its CLI +toc: true +topics: + - appliance + - cli + - backups +contentType: how-to +useCase: appliance +applianceId: appliance12 +sitemap: false +--- + +# How to Back Up the PSaaS Appliance Using the CLI + +You may use the PSaaS Appliance CLI to perform a Mongo backup on a specific node. + +Beginning with version `11638`, the backup doesn't include sensitive configuration information such as encryption keys. + +## Prior to Beginning the Backup + +Please ensure that: +* You have configured the [Command Line Interface](/appliance/cli/configure-cli) on your PSaaS Appliance instances; +* The node has disk space equal to or greater than twice the amount of Auth0 data present. + +::: note +Beginning with PSaaS Appliance version `6868`, you may only back up nodes [added to the `backup` role](/appliance/cli/adding-node-to-backup-role). +::: + +Please be aware that we use the following sample values throughout this document: + +* IP address of the node on the replica set to be backed up: `192.168.1.186`. Generically, the node may also be referred to as ``. +* Password used for encryption: `Passw0rd`. +* The replica set connection string: `a0/a0-1:27017,a0-2:27017,a0-3:27017`. + +## Generate a New Backup + +To initiate a backup, run the following command in your local command-line interface: + +```bash +a0cli -t backup +``` + +For example, if you were to run the above command using the provided sample values, you would run: + +```bash +a0cli -t 192.168.1.186 backup --password Passw0rd +``` + +If the command successfully begins the backup process, you will see the message, "Backup in progress." + +![](/media/articles/appliance/cli/backup-in-progress.png) + +The backup will be encrypted using the `aes-256-crt` algorithm. + +::: note +Only one backup may performed and stored at any given time. Prior to generating a new backup of a node, you must [delete the existing backup](#deleting-the-backup). +::: + +## Back up Sensitive Configuration Info + +Beginning with PSaaS Appliance version `11638`, the `backup` command does **not** save sensitive configuration information such as encryption keys. You need to manually back up these keys (and any other sensitive information) if you want to fully recover an PSaaS Appliance installation using a backup copy. + +To do this, you can use the `backup-sensitive` command, which works the same way as `backup`. You must run the command on a node where you previously ran `set-as-backup`. + +The full instructions (along with the commands you'll need to run) are as follows: + +1. Request a backup: `a0cli -t node_IP_address backup-sensitive --password 0therPassw0rd`; +2. Check the status of a backup: `a0cli -t node_IP_address backup-sensitive-status`; +3. Retrieve backup of sensitive information: `a0cli -t node_IP_address backup-sensitive-retrieve`; +4. Delete the sensitive backup from the node: `a0cli -t node_IP_address backup-sensitive-delete`. + +## Check the Status of the Backup + +You can check on the status of a backup (or whether a backup exists) by running the following command in your local command-line instance: + +```bash +a0cli -t backup-status +``` + +If a backup is available, you will see a message similar to the following: + +```json +{ + "message": "Backup found", + "arguments": { + "name": "file-name.tar.gz" + "md5": "" + } +} +``` + +![](/media/articles/appliance/cli/backup-available.png) + +### Retrieve an Existing Backup + +Before retrieving a backup, we recommend [checking to see if there is one](#checking-the-status-of-the-backup) first. + +To retrieve an existing backup, you will use the "backup-retrieve" message in your local command-line instance: + +```bash +a0cli -t backup-retrieve +``` + +This will download the backup inside of a file called `backup-retrieve.tar.gz.enc`. + +Auth0 recommends checking the md5sum of the retrieved file against that received as part of the back-up status message. + +```bash +md5 backup.tar.gz.enc +``` + +Please remember that the files are encrypted using the `aes-256-crt` algorithm. + +## Delete a Backup + +To delete an existing backup, you will use the "backup-delete" message in your local command-line instance: + +```bash +a0cli -t backup-delete +``` + +## Restore a Backup + +To restore a backup, please open up a ticket requesting assistance via the [Auth0 Support Center](https://support.auth0.com/). diff --git a/fr-ca/articles/appliance/cli/configure-cli.md b/fr-ca/articles/appliance/cli/configure-cli.md new file mode 100644 index 0000000000..90b57df34f --- /dev/null +++ b/fr-ca/articles/appliance/cli/configure-cli.md @@ -0,0 +1,123 @@ +--- +section: appliance +description: How to configure the PSaaS Appliance CLI +topics: + - appliance + - cli +contentType: how-to +useCase: appliance +applianceId: appliance13 +sitemap: false +--- + +# Configuring and Using the Auth0 Appliance Command Line Interface + +The PSaaS Appliance Command Line Interface (CLI) allows you to perform operations on your PSaaS Appliance instances via authorized workstations. + +## Downloading the CLI Setup Files + +To download the files required to set up the CLI, submit a [support ticket](https://support.auth0.com/tickets) for your custom download link. + +## Installing and Using the CLI + +Once you have downloaded and unzipped the `a0cli-v.1.x.x` file, you will select the version that is appropriate for the operating system you are using. Auth0 provides installers for Windows, Macintosh, and Linux systems, and the installer will guide you through the installation process. + +Once this process is complete, you will be able to run the `a0cli` program from your local command-line instance. + +```text +Usage: a0cli [options] + + + Commands: + + create-key Creates private/public keys pair on current path. + show-key Shows public key on current path. + delete-key Deletes keys pair from current path. + update-commands Retrieve available commands from the specified node. + + Options: + + -h, --help output usage information + -V, --version output the version number + -t, --target Host name or IP address of appliance instance. + -p, --port Port number of appliance instance. Default port: 10121 +``` + +However, if you have keys defined and you've run `update-commands`, you will see an extended list of commands: + +```text +Usage: a0cli [options] + + + Commands: + + create-key Creates private/public keys pair on current path. + show-key Shows public key on current path. + delete-key Deletes keys pair from current path. + update-commands Retrieve available commands from the specified node. + backup Creates a new backup. + backup-delete Deletes the current sensitive backup + backup-retrieve retrieves the current backup. + backup-sensitive Creates a new backup of sensitive configuration. + backup-sensitive-delete Deletes the current backup + backup-sensitive-retrieve retrieves the current sensitive backup. + backup-sensitive-status Retrieves the status of the node backup. + backup-status Retrieves the status of the node backup. + nslookup Performs an nslookup to the specified from the target node. + ping Sends a PING message to verify if the target node is up. + re-ip Updates the host entries for instances in the database cluster. Example a0-1:10.1.0.21,a0-2:10.1.0.22 + set-as-backup [force] Add the backup role to the target node. + test-port Verifies if the target ip can listen on . + user-export Exports user to a file. + user-export-delete Deletes the current user-export + user-export-retrieve retrieves the current user-export file. + user-export-status Retrieves the status of the user-export. + + Options: + + -h, --help output usage information + -V, --version output the version number + -t, --target Host name or IP address of appliance instance. + -p, --port Port number of appliance instance. Default port: 10121 + +``` + +::: note + Because the CLI sends commands to the server running on each PSaaS Appliance's node, please ensure that the server is both available and can accept inbound and outbound connections to port `10121`. +::: + +## Granting Access Rights to Users + +Only workstations that you have authorized may perform operations on the PSaaS Appliance. + +To authorize a new workstation for use with the CLI: + +1. Generate a key pair by running, in your local command-line tool, `a0cli create-key`. This outputs a public key, which is now associated with that particular workstation. You will also need to copy for this key to complete the next step. + + ![](/media/articles/appliance/cli/cli-create-key.png) + +2. Navigate to the CLI page of the PSaaS Appliance configuration area, and add the key to your configuration. For additional information on how to do this, please see the [configuration instructions for PSaaS Appliance CLIs](/appliance/dashboard/cli). + + ![](/media/articles/appliance/cli/cli-config-with-key.png) + +::: note +Please note that any user on the workstation with access to the location where the key is stored locally will have access rights to perform operations on the PSaaS Appliance. +::: + +## Updating Command Lists + +To send commands to the PSaaS Appliance's node, you will need to update the command list the node accepts by running the following command: + +`a0cli -t update-commands` + +You may test this process by sending a `ping` message: + +`a0cli -t ping` + +If the test was successful, you will see the following response: + +`{"message": "PONG"}` + +::: note + To get a list of available commands, run `a0cli` (omitting all parameters). +::: diff --git a/fr-ca/articles/appliance/cli/index.md b/fr-ca/articles/appliance/cli/index.md new file mode 100644 index 0000000000..8f2d5a346f --- /dev/null +++ b/fr-ca/articles/appliance/cli/index.md @@ -0,0 +1,22 @@ +--- +url: /appliance/cli +section: appliance +description: How to use the PSaaS Appliance CLI +topics: + - appliance + - cli + - backups +contentType: how-to +useCase: appliance +applianceId: appliance14 +sitemap: false +--- + +# Private SaaS (PSaaS) Appliance Command Line Interface + +The PSaaS Appliance Command Line Interface (CLI) allows you to perform operations on your PSaaS Appliance instances via authorized workstations. + +* [How to Configure the Command Line Interface for User with PSaaS Appliance Instances](/appliance/cli/configure-cli) +* [Backing up PSaaS Appliance Instances with the CLI](/appliance/cli/backing-up-the-appliance) + * [Adding PSaaS Appliance Nodes to the Backup Role](/appliance/cli/adding-node-to-backup-role) +* [How to Reconfigure IP Addresses Using the Command Line Interface](/appliance/cli/reconfiguring-ip) diff --git a/fr-ca/articles/appliance/cli/reconfiguring-ip.md b/fr-ca/articles/appliance/cli/reconfiguring-ip.md new file mode 100644 index 0000000000..8ec85afb75 --- /dev/null +++ b/fr-ca/articles/appliance/cli/reconfiguring-ip.md @@ -0,0 +1,18 @@ +--- +section: appliance +description: How to reconfigure PSaaS Appliance IP Addresses using the CLI +topics: + - appliance + - cli + - ip-addresses +contentType: how-to +useCase: appliance +applianceId: appliance15 +sitemap: false +--- + +# How to Reconfigure IP Addresses Using the Command Line Interface + +When running in a cluster, the PSaaS Appliance nodes need to know the IP addresses of the other nodes within the same cluster (they do not automatically detect each other). Whenever you move the network of the cluster, the IP addresses of the individual nodes need to be re-set to match the original node names. + +Beginning with PSaaS Appliance build **14591**, reconfiguring of IP addresses using the PSaaS Appliance's Command Line Interface (CLI) is no longer possible. Please open a support ticket when you're ready to reconfigure your VMs' IP addresses, as this operation will be carried out by an Auth0 MSE. diff --git a/fr-ca/articles/appliance/clock.md b/fr-ca/articles/appliance/clock.md new file mode 100644 index 0000000000..5674a7c5b0 --- /dev/null +++ b/fr-ca/articles/appliance/clock.md @@ -0,0 +1,48 @@ +--- +section: appliance +description: How to manage the time on PSaaS Appliance +topics: + - appliance + - time-sync +contentType: how-to +useCase: appliance +applianceId: appliance53 +sitemap: false +--- +# Time Synchronization + +Auth0 uses several cryptographic functions that depend on the system clock. + +If you are running Auth0 on an IaaS (Infrastructure as a Service) provider (such as AWS, Microsoft Azure, and so on), time synchronization is managed automatically and you can skip these instructions. + +If you are running Auth0 on your own hardware or a VM host, the PSaaS Appliance must have NTP configured correctly. In most cases, the NTP server is your Domain Controller. Contact your IT administrator for details. + +The NTP server address can be changed in the configuration section of the Dashboard: + +![NTP server address](/media/articles/appliance/clock/ss-2014-12-15T11-34-37.png) + +Enter either the IP address or the DNS name of the NTP server. + +### Configuration options + +Auth0 uses __ntpd__ for internal time synchronization. As described in the [ntpd documentation](http://doc.ntp.org/4.1.1/confopt.htm), to change the various configuration parameters from the default settings, enter these on the same line after the NTP server address. + +For example, the following settings will increase the frequency of updates: + +![Increase the frequency of updates](/media/articles/appliance/clock/ss-2014-12-15T11-36-53.png) + +```text +1.south-america.pool.ntp.org burst iburst minpoll 3 maxpoll 5 +``` + +::: note +These options specify the minimum and maximum poll intervals for NTP messages in seconds to the power of two. The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h). The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 4 (16 s). +::: + +::: note +Fine tuning is only available to Auth0's engineers. +::: + +If the virtual-machine hosting software, such as VMware, has an option for the host operating system (OS) to update the guest OS, this must be turned off so that the host will not interfere with the NTP time synchronization of the guest PSaaS Appliance. + +For example, in VMware Tools, the "sync guest time with host" checkbox must be unchecked (off) for the Auth0 guest virtual machine. diff --git a/fr-ca/articles/appliance/critical-issue.md b/fr-ca/articles/appliance/critical-issue.md new file mode 100644 index 0000000000..d7b7d47801 --- /dev/null +++ b/fr-ca/articles/appliance/critical-issue.md @@ -0,0 +1,73 @@ +--- +sitemap: false +section: appliance +description: Outlines additional support procedure information for enterprise subscription customers with an Auth0 PSaaS Appliance. +topics: + - appliance + - support +contentType: + - how-to + - concept +useCase: appliance +applianceId: appliance54 +sitemap: false +--- + +# Critical Support Issue Guidance for Appliance Customers + +This document outlines additional support procedure information for enterprise subscription customers with an PSaaS Appliance and should be read in conjunction with the general [Enterprise Support Guidance document](/onboarding/enterprise-support). + +PSaaS Appliance customers must have [Enterprise Support](/onboarding/enterprise-support#premium-enterprise-support) as a minimum. Refer to your subscription agreement to confirm if other custom support or SLA coverage has been included. + +Below are special procedures PSaaS Appliance customers should follow for Critical Support Issues. All other information as outlined in the [Enterprise Support Guidance document](/onboarding/enterprise-support) is still valid and should be followed. + +## What is a Critical Issue + +A Critical Issue is defined as an Auth0 issue severely impacting your live or in-production systems where: + +- major business processes and functions are severely impaired or stopped; +- the majority of users are adversely impacted; +- there is no workaround + +::: note +Please do *not* submit an Urgent ticket for non-production environments. Urgent (critical) tickets are reserved for production environments. +::: + +## Special procedures for critical issues impacting production applications for PSaaS Appliance customers + +PSaaS Appliance customers should use the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) as a primary method of logging a critical support issue. As part of the onboarding procedure a cloud account should be created that gives administrators the possibility to log in to Support Center and create new tickets. Set the ticket severity to **Urgent** if you need an immediate response. + +::: note +Using Support Center requires a cloud account setup. If you are unsure about this, please try logging in at the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) or check with your Auth0 Technical Account Manager. +::: + +As a secondary point of escalation, PSaaS Appliance customers can also send an email to `productionoutage@auth0.com` to log a critical support issue. *Note that this should only be a secondary escalation point, as a ticket created in Support Center provides a more reliable way to identify the customer having the problem and interact with the user.* + +### To log a critical support issue in Support Center + +1. Go to the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) and log in with your credentials. +2. Click on the [Open Ticket](${env.DOMAIN_URL_SUPPORT}/tickets/new) button. +3. Select your **Associated Support Cloud Tenant**, **Affected Root Tenant Authority** (optional), and **Affected Tenant** (optional). +4. For **What can we help you with?** select **Appliance Support Incident**. +5. For **Severity** select **Urgent**. + ::: note + If you don't select **Urgent**, the issue will not be treated as critical. You will not be able to change the severity of the ticket once it is created so if, for example, you set Severity to `High` but later realize that the situation is critical, you need to create a new ticket with `Severity` set to Urgent. + ::: +6. Provide an appropriate **Subject** title. +7. Describe the problem as completely as possible. *The more information you can provide about the issue you are having, the better we can provide quick and valuable support.* + +### Information to provide when logging an issue by email + +To speed resolution, please provide the following when logging an issue via email (in addition to other information listed in the [Enterprise Support Guidance document](/onboarding/enterprise-support)): + +* Your Company Name and specific project name (some customers have more than one instance of Auth0) +* Your contact details and the contact details of relevant colleagues such as IT operations staff, including email address and phone numbers with relevant country and area codes. + +### What to expect + +When an issue has been logged correctly: + +* It will be acknowledged immediately by email and assigned a ticket ID number. Additional information may be requested. +* A responding Auth0 support staff member may contact you via email and/or direct you to join a private Slack channel and/or a Zoom web conference to facilitate faster communications. However, it’s important to remember you should not initiate requests for help via a Slack channel - only via the methods outlined above. Slack channels may not be actively monitored. +* In addition to communications over a web conference or Slack, to preserve a record of an issue, any critical information, such as log files, symptoms, and so on should be sent as updates to the ticket via support center.  Any conclusions or next steps should be added to the ticket as well. +* Upon resolution of the issue, an Auth0 support staff member will ask the customer for confirmation the issue has been resolved to their satisfaction and the ticket will be closed only when customer has responded and confirmed issue is resolved. diff --git a/fr-ca/articles/appliance/custom-domains/index.md b/fr-ca/articles/appliance/custom-domains/index.md new file mode 100644 index 0000000000..cb3728aba9 --- /dev/null +++ b/fr-ca/articles/appliance/custom-domains/index.md @@ -0,0 +1,83 @@ +--- +url: /appliance/custom-domains +section: appliance +description: How to set up custom domains for your PSaaS Appliance +topics: + - appliance + - custom-domains +contentType: + - index +useCase: appliance +applianceId: appliance16 +sitemap: false +--- + +# Private SaaS (PSaaS) Appliance: Custom Domains + +::: warning +Private SaaS Deployments (beginning with release 1905) must use the Auth0 [Custom Domains](/custom-domains) feature instead of the PSaas Custom Domains feature when creating new Custom Domains (regardless of whether they have existing Custom Domains using the PSaaS Custom Domains feature or not). **The PSaaS Custom Domains feature is deprecated.** Please contact your Auth0 MSE if you have any questions. +::: + +If you are using **PSaaS Appliance Build 5XXX** or later, you may configure custom domains using the Management Dashboard. + +Custom domains allow you to expose one arbitrary DNS name for a tenant. Conventionally, the PSaaS Appliance uses a three-part domain name for access, and it is the first portion of the domain name that varies depending on the tenant. + +The root tenant authority (RTA) is a special domain that is configured when the PSaaS Appliance cluster(s) are first set up. It is a privileged tenant from which certain manage operations for the cluster are available. The RTA is sometimes called the configuration domain, and all users that have access to the Management Dashboard belong to an application in the RTA. + +::: note + All tenant domain names derive from the root tenant authority, and any changes to this will result in the deletion of all tenants. +::: + +## Custom Domains Features + +The follow is a list of custom domain features that differ in behavior from their implementation in the Auth0 Public Cloud or have yet to be released to PSaaS Appliance implementations. + +| Feature | Currently Supported in the PSaaS Appliance? | +| - | - | +| Use of custom domain in emails | No | +| Custom domain protection via API keys | No | +| Custom domain registration | Yes; accessible via PSaaS Appliance Dashboard | +| Token issuer used as custom domain | No | +| Auth0-managed certificates | No | + + +## Use Example + +Suppose that your RTA is `config.example.com`. From this point on, all of your new tenants' domain names must derive from the base name, `example.com`: + +```text +site1.example.com +site2.example.com +``` + +However, you might want to expose other domain names to your end users, such as: + +* `auth.site2.com` +* `auth.site1.com` +* `auth.site1.example.com` + +You may do so by utilizing the PSaaS Appliance's custom domains feature, which sets the domain used for authentication endpoints. + +## Certificates Required for Custom Domains + +Custom domains map one external DNS to a tenant that follows the standard naming convention. + +Suppose that we have a tenant with the following domain: + +`auth.example.com` + +Suppose that we want the following domain to map to `auth.example.com`: + +```text +auth.site2.com +``` + +The custom domain has its own certificate, which is stored separately. + +## Configuring Custom Domains + +You may configure custom domains for your tenants via the [custom domains set-up area](/appliance/dashboard/tenants#custom-domains) of the [tenants page in the PSaaS Appliance configuration area](/appliance/dashboard/tenants). + +## Custom Domains for PSaaS Appliance's Hosted in Auth0’s Private Cloud + +If your PSaaS Appliance is hosted in Auth0’s private cloud, your domains will end in *auth0.com*. If you want to use a custom domain with your customer-facing applications, see [Information Requirements for Setting Up the PSaaS Appliance in Auth0's Private Cloud](/appliance/private-cloud-requirements). diff --git a/fr-ca/articles/appliance/dashboard/activity.md b/fr-ca/articles/appliance/dashboard/activity.md new file mode 100644 index 0000000000..d73389b069 --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/activity.md @@ -0,0 +1,27 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Activity page +topics: + - appliance + - dashboard +contentType: concept +useCase: appliance +applianceId: appliance17 +sitemap: false +--- + +# PSaaS Appliance Dashboard: Activity + +::: note +For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#psaas-appliance-controls). +::: + +After you begin an update or make a change to the configuration, Auth0 displays progress and logs for those actions on this page in case you need the information for troubleshooting purposes. + +![](/media/articles/appliance/dashboard/activity.png) + +On the Activity page, you will see the Configuration Logs displayed, with individual activities organized by the affected nodes. You will also see the status of that given node at the current moment in time. + +To see the Debug Logs, click on the "Show Debug Logs" button to see any applicable logs for the nodes associated with your PSaaS Appliance. + +![](/media/articles/appliance/dashboard/debug-logs.png) diff --git a/fr-ca/articles/appliance/dashboard/cli.md b/fr-ca/articles/appliance/dashboard/cli.md new file mode 100644 index 0000000000..f817659fb8 --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/cli.md @@ -0,0 +1,33 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard CLI page +topics: + - appliance + - dashboard + - cli +contentType: concept +useCase: appliance +applianceId: appliance18 +sitemap: false +--- + +# PSaaS Appliance Dashboard: CLI + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +If your PSaaS Appliance instances requires integration with the PSaaS Appliance Command Line Interface (CLI), you may add the required access keys to this page. + +![](/media/articles/appliance/dashboard/cli-keys.png) + +Please see your vendor for instructions on generating the public access keys. Once you are in possession of the required key(s), you may associate them with your PSaaS Appliance instance by clicking on "Add Key". You will then be asked for the following pieces of information: + +* **Name**: the name that identifies your key; +* **Key**: the public key string. + +![](/media/articles/appliance/dashboard/cli-keys-add.png) + +Once you have entered this information, click "Add" to persist your changes. + +All of your keys are listed in a tabular format on the CLI page. If, at a later point, you would like to remove a given key from your account, you may do so by clicking on the red "X" located at the end of that key's specific row. diff --git a/fr-ca/articles/appliance/dashboard/index.md b/fr-ca/articles/appliance/dashboard/index.md new file mode 100644 index 0000000000..e77472478b --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/index.md @@ -0,0 +1,47 @@ +--- +section: appliance +description: > + Learn how to use the Management Dashboard to configure things like your Applications, Connections, Users, and Rules. +url: /appliance/dashboard +topics: + - appliance + - dashboard +contentType: + - reference + - concept +useCase: appliance +applianceId: appliance19 +sitemap: false +--- + +# Private SaaS (PSaaS) Appliance Management Dashboard + +Regardless of where you're hosting your PSaaS Appliance, you can use the Management Dashboard to configure things like your Applications, Connections, Users, and Rules. + +## PSaaS Appliance Controls + +There are certain settings that are managed by Auth0 when you use the cloud service or when Auth0 is managing your private deployment. As such, these controls will not be exposed to you directly, though in the latter instance, you would work with Auth0 engineers when changing settings and applying updates. + +These controls, however, are exposed to you if you are managing your PSaaS Appliance instances and are logged in to what is referred to as the **root tenant authority**. If so, you will see a link in the top right corner called **Configuration**. Selecting this link brings you to the PSaaS Appliance configuration area, which contains settings and displays information about your clusters. + +![](/media/articles/appliance/dashboard/primary-dashboard.png) + +For additional information about the pages contained in the PSaaS Appliance configuration area, please refer to the following documents: + +[Nodes](/appliance/dashboard/nodes) + +[Settings](/appliance/dashboard/settings) + +[Tenants](/appliance/dashboard/tenants) + +[Troubleshoot](/appliance/dashboard/troubleshoot) + +[Updates](/appliance/dashboard/updates) + +[Activity](/appliance/dashboard/activity) + +[Rate Limiting](/appliance/dashboard/rate-limiting) + +[CLI](/appliance/dashboard/cli) + +[OSS Components](/appliance/dashboard/oss-components) diff --git a/fr-ca/articles/appliance/dashboard/nodes.md b/fr-ca/articles/appliance/dashboard/nodes.md new file mode 100644 index 0000000000..f406e27741 --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/nodes.md @@ -0,0 +1,38 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Nodes page +topics: + - appliance + - dashboard + - nodes +contentType: concept +useCase: appliance +applianceId: appliance21 +sitemap: false +--- + +# Auth0 Appliance Dashboard: Nodes + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +The Nodes page located under the PSaaS Appliance configuration area provides a high-level overview of the nodes you have running as part of your PSaaS Appliance setup. Each instance that you have with your web service provider is considered a node and is listed individually on this page. + +![](/media/articles/appliance/dashboard/nodes.png) + +The Nodes page displays the following pieces of information for each of your nodes: + +* **Hostname**: the name of the node; +* **IP**: the IP address used to reach that particular node; +* **Memory**: the amount of memory allocated to that node; +* **CPUs**: the number of CPUs allocated to that node; +* **App Update**: the number of times the node has been updated with application-related updates; +* **Setting Update**: the number of times the node's settings have been updated; +* **Heartbeat**: the amount of time elapsed since the Dashboard received communication from the node; +* **Uptime**: the amount of time the node has been continuously running. + +At the end of each row detailing a Node instance are two buttons: + +* **Reboot**: if clicked, Auth0 reboots the node; +* **Remove**: if clicked, Auth0 removes the node from the status list. If the node is still running, the configuration area will publish a new status. diff --git a/fr-ca/articles/appliance/dashboard/oss-components.md b/fr-ca/articles/appliance/dashboard/oss-components.md new file mode 100644 index 0000000000..76c680a20e --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/oss-components.md @@ -0,0 +1,27 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard OSS Components page +topics: + - appliance + - dashboard + - oss +contentType: concept +useCase: appliance +applianceId: appliance22 +sitemap: false +--- + +# OSS Components + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +Auth0 makes use of best-in-class open source software (OSS) components to deliver the Auth0 cloud service. On this page, you will find a comprehensive list of the OSS components that are utilized to deliver Auth0, along with the text of their licenses. + +* [Elasticsearch](https://www.elastic.co/) +* [Puppet](https://puppet.com/) +* [Node.js](https://nodejs.org/en/) +* [NGINX](http://nginx.org/) +* [MongoDB](https://www.mongodb.com/) +* [Ubuntu Linux](http://www.ubuntu.com/) diff --git a/fr-ca/articles/appliance/dashboard/rate-limiting.md b/fr-ca/articles/appliance/dashboard/rate-limiting.md new file mode 100644 index 0000000000..ac92f8c95c --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/rate-limiting.md @@ -0,0 +1,27 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Rate Limiting page +topics: + - appliance + - dashboard + - rate-limiting +conceptType: concept +useCase: appliance +applianceId: appliance23 +sitemap: false +--- + +# Auth0 Appliance Dashboard: Rate Limiting + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +While the Auth0-managed cloud instances automatically includes rate limiting to ensure quality service, you must manually enable rate limiting if you are using Auth0 PSaaS Appliance instances. + +![](/media/articles/appliance/dashboard/rate-limiting.png) + +## Settings + +* **Enabled**: to enable rate limiting, check this box. Auth0 will then limit requests to services like API and logins to help mitigate malicious attacks; +* **Configuration of Buckets**: if you have enabled rate limiting, you will be presented with the various "buckets" that set the limits on calls to the API and logins. You may adjust these as necessary. diff --git a/fr-ca/articles/appliance/dashboard/settings.md b/fr-ca/articles/appliance/dashboard/settings.md new file mode 100644 index 0000000000..842e959bdc --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/settings.md @@ -0,0 +1,113 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Settings page +topics: + - appliance + - dashboard + - settings +contentType: reference +useCase: appliance +applianceId: appliance24 +sitemap: false +--- + +# Auth0 Appliance Dashboard: Settings + +::: note + For additional information on navigating to and using the Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +The Settings page is where you will make most of the changes that pertain to your PSaaS Appliance configuration. + +![](/media/articles/appliance/dashboard/settings.png) + +The Settings page is broken down into the following sections: + +* [General](#general) +* [Dashboard](#dashboard) +* [HTTPS Configuration](#https-configuration) +* [SMTP Server](#smtp-server) +* [Session](#session) +* [Update Settings](#update-settings) +* [Monitoring](#monitoring) +* [API Keys](#api-keys) +* [Advanced Settings](#advanced-settings) +* [Deprecated](#deprecated) + +## General + +* **Company Handle**: the internal identifier for your company. Use only lowercase characters (no spaces or special characters); +* **NTP Servers**: the IP address of an internal NTP server (such as *10.4.2.39*) or a public NTP server (such as *1.north-america.pool.ntp.org burst iburst minpoll 3 maxpoll 5*). This setting is particularly important, since it assists in time synchronization among the various pieces of your infrastructure; +* **Enable GeoIP**: if enabled, Auth0 will update the geo-coding database for mapping IP addresses to locations (you **MUST** permit access to www.maxmind.com through your firewall); +* **Enforce Logout URLs**: if enabled, Auth0 requires the Logout URL used to be included in the list indicated under Allowed Logout URLs. + +## Dashboard + +* **Enable "New Account" in Dashboard**: if enabled, you may create new isolated accounts (called tenants) in the PSaaS Appliance; +* **Federated Logout**: if enabled, signing out of the Dashboard also signs you out from the ldP (such as when using enterprise connections with the Dashboard). + +## HTTPS Configuration + +* **SSL Certificate Format**: indicates whether the certificate is either *PFX/PKCS12* or *Standard PEM*; + + *If you are using a PFX/PKCS12 certificate:* +* **SSL PFX Cert**: the password used to authenticate your PFX Certificate; +* **PFX Certificate**: clicking this button enables you to upload a copy of your PFX Certificate; + + *If you are using a Standard PEM certificate:* +* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key; +* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key; + +* **Disable TLSv1**: disables TLSv1, which reduces compatibility with technologies like .NET 4.0; +* **Disable TLSv1.1**: disables TLSv1.1, which reduces compatibility with older browsers like IE 11. + +## SMTP Server + +* **Send Mails From**: *Deprecated.* The email address used in the "From" field typically comes from that provided on your [custom email template](${manage_url}/#/emails); +* **SMTP Server**: the name of your SMTP server; +* **SMTP Port**: the port through which you access your SMTP server; +* **SMTP User**: the username to log in to your SMTP server; +* **SMTP Password**: the password to log in to your SMTP server. + +## Session + +* **Dashboard Session Timeout (min)**: the amount of idle time allowed prior to the Dashboard session getting logged out. Use 0 to avoid expiration; +* **SSO Session Absolute Timeout**: the absolute time window for which the user can have an SSO session. After this period of time elapses, the user will be required to log in again; +* **SSO Session Inactive Timeout**: the maximum time window for which the user can have an SSO session without logging in again or calling the "ssodata" endpoint. If the user logs in again or calls the "ssodata" endpoint, the time window will be extended again; +* **SSO Session Ephemeral Cookie**: if enabled, the SSO session cookie will not persist and users will lose their SSO session in Auth0 after closing their browsers; +* **MFA Session Absolute Timeout**: the absolute time window for which the user can have an MFA session. After this period of time elapses, the user will be prompted again for MFA; +* **MFA Session Inactive Timeout**: the maximum time window for which the user can have an MFA session without logging in again. If the user logs in prior to the expiration of this time period, the window will be extended. + +### Units of time + +When providing time values to Auth0, please use the following abbreviations to ensure the correct units are used: + +| Abbreviation | Description | +| - | - | +| w | weeks | +| d | days | +| h | hours | +| m | minutes | +| s | seconds | +| ms | milliseconds | + +## Update Settings + +* **Update Proxy**: unless your specific configuration is set up for offline updates, please leave this field blank. + +## API Keys + +* **Health service**: generates a key that authenticates your API calls for status information regarding your PSaaS Appliance instances; + + ![](/media/articles/appliance/dashboard/health-keys-api-service.png) + + **Please be sure to save the Settings page to persist the newly-generated key.** + +## Advanced Settings + +* **Enable Large Cookie Size**: if enabled, cookies larger than 4kb will be permitted (this might be required for protocols such as SAML and WS-Federation). +* **Max Custom Database Timeout**: the maximum time allowed in seconds to make a query to your database (in seconds) for a custom database connection. + +## Deprecated + +* **Updated URL**: unless your specific configuration is set up for offline updates, please update via [Auth0's hosted mirror site](http://apt-mirror.it.auth0.com). diff --git a/fr-ca/articles/appliance/dashboard/tenants.md b/fr-ca/articles/appliance/dashboard/tenants.md new file mode 100644 index 0000000000..120e7b9073 --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/tenants.md @@ -0,0 +1,74 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Tenants page +topics: + - appliance + - dashboard + - tenants +contentType: reference +useCase: appliance +applianceId: appliance25 +sitemap: false +--- + +# PSaaS Appliance Dashboard: Tenants + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +The Tenants page of the PSaaS Appliance Dashboard lists all tenants associated with your PSaaS Appliance instance. + +![](/media/articles/appliance/dashboard/tenants.png) + +For each associated tenant, you will see the following pieces of information: + +* **Name**: the name of the tenant; +* **Applications**: the number of applications associated with the tenant; +* **Connections**: the number of Connections enabled for the tenant; +* **Total Users**: the total number of users associated with the tenant; +* **Total Logins**: the total number of logins by users associated with the tenant. + +## Custom Domains + +![](/media/articles/appliance/dashboard/tenant-custom-domain.png) + +The name column of the Tenants page is a hyperlink. Clicking on this brings up the page where you can set up custom domains for this particular tenant, as well overview information for any currently-existing custom domains. + +### Adding a Custom Domain (legacy PSaaS customers only) + +::: note +The following steps are only required for legacy PSaaS customers. All new customers can use the Custom Domains feature as implemented in the public cloud version. +::: + +To add a custom domain, click on the "Add Domain" button. You will be prompted for the following information: + + +![](/media/articles/appliance/dashboard/tenant-add-custom-domain.png) + +* **Domain**: the custom domain for your tenant; +* **SSL Available**: the SSL certificate format (either *PFX/PKCS12* or *Standard PEM*); + + *If you are using a PFX/PKCS12 certificate:* +* **SSL PFX Cert**: the password associated with your PFX/PKCS12 certificate; +* **PFX Certificate**: clicking this button enables you to upload a copy of your PFX Certificate; + + *If you are using a Standard PEM certificate:* +* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key; +* **Upload Private Key...**: clicking this button enables you to upload the file containing your private key. + + ::: note + The private key cannot be password protected + ::: + +Once you have provided the required information and uploaded your certificate, click the "Add" button to save your changes and add the custom domain. You will then see a green banner appear on the Custom Domain page that says: + +`Updating configuration... check Activity section for progress.` + +Once the change has been implemented and you have refreshed the custom domains page, you will see the following overview information about your newly-created domain: + +* **Domain**: the custom domain URL; +* **SSL Available**: indicates successful application of the SSL certificate; +* **Certificate Subject**: the subject of the certificate, or the target of the certificate (such as what is being secured); +* **Certificate Expiration**: the date and time when the certificate expires; +* **Remove Domain**: clicking the "X" button removes this domain from the tenant. diff --git a/fr-ca/articles/appliance/dashboard/troubleshoot.md b/fr-ca/articles/appliance/dashboard/troubleshoot.md new file mode 100644 index 0000000000..7af19b48fc --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/troubleshoot.md @@ -0,0 +1,62 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Troubleshoot page +topics: + - appliance + - dashboard + - troubleshooting +contentType: reference +useCase: appliance +applianceId: appliance26 +sitemap: false +--- + +# PSaaS Appliance Dashboard: Troubleshoot + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +The Troubleshoot page of the PSaaS Appliance Dashboard provides you with tools to help diagnose any issues that might occur. + +![](/media/articles/appliance/dashboard/troubleshoot.png) + +## Diagnostics Package + +You may create a diagnostic package containing detailed information about your PSaaS Appliance instance(s) by clicking on the "Generate New Package" button. + +Once you've clicked "Generate New Package", you will see a notification message that indicates that your package is being generated. Once your package is ready, the message will disappear and a link to download the package related to a particular node instance will appear in the last column of your Nodes table. + +### Contents of the Diagnostics Package + +Upon downloaded your package, you'll notice that the file name formatted as follows: `appliance-logs-[name of node]`. Within this file are the following sub-folders, each containing a series of logs: + +* auth0 +* mongodb +* nginx +* rabbitmq +* ssh-auth + +## Health Check + +The Health Check offers a quick overview of the status of your PSaaS Appliance instances. Data is available for the past hour through the past twenty-nine (29) days. + +To obtain data for a specific period of time, change the `Day` and/or `Hour` field to correspond to the time period whose data you want to analyze. Click "Get" to return the specified data. + +You can refresh the listed data by clicking on the "refresh" button located on the right hand side. + +The following bits of data are available at a glance: + +* **Status**: in the column headed by a picture of weather clouds are status symbols reflecting the state of a given node. If all is well, the column appears with a green sunshine icon. If there is something that is attention-worthy, the column appears with a red rain/lightening icon; +* **Time**: the time at which the data was retrieved; +* ** All Nodes/IP Addresses: by changing the column heading from "All Nodes" to the IP address of a specific node (and vice versa), you can choose to display data from ALL nodes or just data from a specific node; +* **Host**: the name of the node in question; +* **Avail Memory**: the amount of memory available to the node at the time of the Health Check; +* **CPU**: CPU usage (as a percent) on the node at the time of the Health Check; +* **Email**: indicates status of email services; +* **Disk**: indicates status of disk resources; +* **Network**: indicates status of network availability; +* **Services**: indicates status of services; +* **DB**: indicates status of database availability. + +By clicking on an individual row listed under the Health Check section, you may view additional information about the resources that are currently running. diff --git a/fr-ca/articles/appliance/dashboard/updates.md b/fr-ca/articles/appliance/dashboard/updates.md new file mode 100644 index 0000000000..a78879ad02 --- /dev/null +++ b/fr-ca/articles/appliance/dashboard/updates.md @@ -0,0 +1,39 @@ +--- +section: appliance +description: Overview of the PSaaS Appliance Dashboard Updates page +topics: + - appliance + - dashboard + - updates +contentType: reference +useCase: appliance +applianceId: appliance27 +sitemap: false +--- + +# PSaaS Appliance Dashboard: Updates + +::: note + For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls). +::: + +The Updates page of the PSaaS Appliance configuration area allows you to make the required/selected updates to your PSaaS Appliance instance. + +Auth0 recommends taking VM snapshots and backups prior to beginning an upgrade. If there are issues with you upgrade, it might be possible to roll back the PSaaS Appliance to the version used immediately prior to the upgrade (this is the preferred option, since there would not be any data loss). + +However, if the option of rolling back to the existing version is not possible, Auth0 will need to restore your environment using the VM snapshots created prior to the update (there will be some data loss in this instance). + +![](/media/articles/appliance/dashboard/updates.png) + +## Online Update +The Online Update section allows you to download and install updates from the Auth0 mirror site. This is the recommended way of updating. + +You will be asked to provide the *build number* you would like to apply in the **Update To** field. You may select a provided version, or you may provide a custom *build number*. + +Once you have selected the appropriate build, any **release notes** applicable will display on the screen. + +To begin the update, click on "Update from Internet." You will be prompted once more to confirm to ensure that the appropriate backups have been made, since PSaaS Appliance updates cannot be undone. + +::: note +You should schedule Production updates with your Auth0 Technical Account Manager so that there is an Auth0 Customer Success Engineer available in case any patches need to be manually applied. For more information on updates, see [Updating the PSaaS Appliance](/appliance/admin/updating-the-appliance). +::: diff --git a/fr-ca/articles/appliance/disaster-recovery-raci.md b/fr-ca/articles/appliance/disaster-recovery-raci.md new file mode 100644 index 0000000000..4a9e440e7b --- /dev/null +++ b/fr-ca/articles/appliance/disaster-recovery-raci.md @@ -0,0 +1,174 @@ +--- +description: An in-depth summary of the roles and responsibilities allocated between Auth0 and the subscriber +section: appliance +topics: + - appliance + - disaster-recovery + - raci +contentType: reference +useCase: appliance +applianceId: appliance55 +sitemap: false +--- + + + +# Disaster Recovery: Detailed Division of Responsibility + +The following RACI Matrix provides an in-depth summary of the roles and responsibilities allocated between Auth0 and the subscriber. + +## Definitions + +RACI refers to the following list of definitions: + +* **Responsible**: the assigned party who is responsible for implementing the task as required; +* **Accountable**: the assigned party who is accountable for the task being completed as required; +* **Consulted**: the party (or parties) whose opinions are requested and with whom there is two-way communication; +* **Informed**: the party (or parties) who are kept up-to-date with regards to progress and with whom there is one-way communication + +## Database Backup + +::: note +Please see [Database Backup](/appliance/disaster-recovery#database-backups) for more information. +::: + +The following table details the task division for configuring, creating, and monitoring the data backup process. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
Provision Additional Backup DiskIR, AThe subscriber will need to provision an additional drive for backup purposes.
Download PSaaS Appliance CLI toolCR, AThe subscriber will need to contact their Auth0 Technical Account Manager for the custom download link.
Install PSaaS Appliance CLI ToolIR, AThe subscriber will need to install the CLI tool.
Configure Appliance CLI ToolIR, AThe subscriber will need to add a node to the backup role.
Perform Data Backup via CLI ToolIR, AThe subscriber will need to initiate a backup action via the CLI, as well as check periodically on the status of the backup.
Beginning with version 11638, a separate Sensitive Configuration Backup needs to performed as well.
Store Data Backup at a Secondary SiteIR, AThe subscriber will need to retrieve an existing backup and store it in a safe location outside the PSaaS Appliance.
Delete Data BackupsIR, AOnly one backup should be stored in the backup device. If there exists a backup on the device, the subscriber will be asked to delete it prior to creating a new one.
+ + +## Restore Data Backup + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
Have Data Backup AvailableCR, AThe data backup files should be available and ready to be copied to the Auth0 VMs.
Provide Backup PasswordIR, AThe subscriber will provide the password used to create and encrypt the backup file. Without this password, the backup file cannot be decrypted and used to restore the environment.
Create New Virtual Machines from Auth0 ImagesI, CR, AThe subscriber will be responsible for creating the new virtual machines (where the environment will be restored from the backup) using images provided by Auth0.
Restore the Data BackupR, CIPlease open a ticket in the Auth0 Support Center to request assistance with restoring a backup. Auth0 Customer Success Engineers will review your request, and if necessary, partner with the subscriber's infrastructure engineers to restore the environment. Please note that, in certain cases, a Professional Services fee may apply.
+ + +## Virtual Machine Snapshots + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
Configure / Create VM SnapshotsIR, AThe subscriber is responsible for configuring and create snapshots on a scheduled basis.
Restore VM SnapshotsIR, AThe subscriber is responsible for restoring a VM Snapshot..
Recover Auth0 EnvironmentRI, AAuth0 is responsible for recovering the authentication environment.
+ + +## Backup Cadence Recommendations + +Auth0 recommends backing up your data on a daily basis (usually overnight to lessen impact on performance). However, if you need greater assurance of up-to-date data or have concerns about a logical data corruption, you might choose to backup more frequently. If this is the case, please contact your Auth0 Technical Account Manager to schedule a discussion, since the backup process puts a substantial load on the backup node and may impact your Production environment. + +Auth0 recommends taking **weekly** Virtual Machine Snapshots. diff --git a/fr-ca/articles/appliance/disaster-recovery.md b/fr-ca/articles/appliance/disaster-recovery.md new file mode 100644 index 0000000000..a2296865d2 --- /dev/null +++ b/fr-ca/articles/appliance/disaster-recovery.md @@ -0,0 +1,93 @@ +--- +description: High-level overview of disaster recovery options for the PSaaS Appliance +section: appliance +topics: + - appliance + - disaster-recovery +contentType: concept +useCase: appliance +applianceId: appliance56 +sitemap: false +--- + +# PSaaS Appliance: Disaster Recovery + +When preparing for the possibility of issues with your PSaaS Appliance instances, your options depend on your tolerance for downtime. Below, you will find information on the advantages and disadvantages associated with the various disaster recovery (DR) options available. + +Additionally, there is a difference between PSaaS Appliance availability and data availability/recovery. For example, the standard three-node cluster deployment has high availability and can survive a single-node failing. However, in cases of a data center failure or a logical data corruption, you would need a disaster recovery solution to help recover from that. + +In cases where the data centers have very low latency, you can run individual PSaaS Appliance instances using three different data centers. For example, if you are using AWS, you can run each of your nodes in a different availability zone (though this may incur a higher service cost). + +## Geographic High-Availability PSaaS Appliance Implementation + +If your requirements demand regional resilience with little downtime, we recommend a [Geographic High-Availability PSaaS Appliance](/appliance/geo-ha) implementation. This is the only implementation that has failover between regions. + +Issue detection and failover typically occur at the database level in 30 seconds or less. However, switching over and rerouting traffic from one data center to another is an expensive operation, so we've configured the infrastructure to detect false positives and *not* switch over if one occurs. This secondary detection process reroutes client traffic through failure detection time-out mechanisms that result in an *effective* failover time of approximately ten minutes. + +**Advantages**: + +Geo-HA is a PSaaS Appliance implementation that provides: +* Data center redundancy; +* Rapid failure response; +* The highest form of PSaaS Appliance availability offered by Auth0. + +**Disadvantages**: + +Geo-HA involves: +* A higher cost due to increased complexity; +* Additional PSaaS Appliance Virtual Machines (VM) that need maintenance; +* An additional layer in front of the load balancer for GEO failover, such as F5 Global Traffic Manager or AWS Route 53; +* Additional configuration to handle logical corruption. + +For more information, please see: +* [Geo HA](/appliance/geo-ha) +* [Disaster Recovery](/appliance/geo-ha/disaster-recovery) + +## VM Snapshots +If you have some tolerance for downtime (either in terms of minutes or hours), you can consider using the Virtual Machine (VM) snapshot approach. A VM snapshot contains everything needed to rebuild a PSaaS Appliance. You would be responsible for regularly taking VM snapshots and either storing them either offsite or replicating them to other regions in the cloud. + +**Advantages**: +* Recovery via VM snapshots is quicker than using database backups (though the process is slower than GEO-HA). + +**Disadvantages**: +* You will need manual intervention from an Auth0 Managed Services Engineer (MSE) to restore your cluster. +* VM snapshots can become very large (snapshots are not compressed, and you would need a snapshot of each VM/drive), which makes storage tricky. +* The backup and recovery process requires manual intervention. + +### Basic Steps for Recovering with VM Snapshots + +The following outlines the basic steps required for restoring PSaaS Appliance instances using VM snapshots: + +1. Ensure that you have a snapshot of your VM(s) and that it is stored at a secondary site. In the event of a disaster, your primary site may not be accessible. +2. Restore your VM(s) using your snapshots at your secondary site. +3. Contact a Managed Services Engineer via support ticket to complete the recovery of your environment + +::: panel VMWare's Site Recovery Manager +Site Recovery Manager is not supported on current versions of Auth0 PSaaS Appliance. If you rely on this VMWare feature, please contact your Technical Account Manager for guidance. +::: + +## Database Backups + +Restoring your PSaaS Appliance with database backups requires you to provision new Virtual Machines (VMs). You will then need assistance from an Auth0 Customer Success Engineer (CSE) to configure the PSaaS Appliance and bring it back online with your restored data. + +Database backups are not the same as a snapshot of the whole VM. They are compressed backups created by the [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli). You can then download them from the PSaaS Appliance and store them at a secondary site for recovery in the event you need to implement a recovery scenario. + +If you choose to use database backups as your DR strategy, please note that this process may take up to **24 hours**. + +**Advantages**: +* Database backups are smaller and easier to move offsite than VM snapshots. + +**Disadvantage**: +* You will need manual intervention from an Auth0 MSE to restore your PSaaS Appliance. +* Recovering with a database backup requires the greatest amount of time. + +For more information, please see: +* [Backing Up PSaaS Appliance Instances](/appliance/admin/backing-up-the-appliance-instances) +* [Using the CLI to Backup PSaaS Appliance Instances](/appliance/cli/backing-up-the-appliance) +* [Adding an PSaaS Appliance Node to the Backup Role](/appliance/cli/adding-node-to-backup-role) + +## Combining VM Snapshots and Database Backups + +A middle ground between using VM snapshots and database backups is to take weekly VM snapshots while scheduling nightly database backups. + +The recovery process still requires the assistance of an Auth0 CSE, but because the VMs can be automatically restored, only the database needs manual intervention/assistance. This eliminates some of the downtime resulting from using just database backups. diff --git a/fr-ca/articles/appliance/extensions.md b/fr-ca/articles/appliance/extensions.md new file mode 100644 index 0000000000..b98480d9b1 --- /dev/null +++ b/fr-ca/articles/appliance/extensions.md @@ -0,0 +1,48 @@ +--- +url: /appliance/extensions +section: appliance +description: Explains implementation details for Extensions specific to the PSaaS Appliance. +topics: + - appliance + - extensions +contentType: + - concept + - how-to +useCase: appliance +applianceId: appliance58 +sitemap: false +--- + +# PSaaS Appliance: Extensions + +While using [Extensions](/extensions) in the PSaaS Appliance is very similar to using Extensions in the multi-tenant installation of Auth0, there are some differences. + +You may receive updates to Extensions at any time without prior notice. + +## Set up and enable Webtasks + +You must set up and enable Webtasks before you can use Extensions. + +To [set up and enable your Webtasks](/appliance/infrastructure/extensions#requirements-for-enabling-webtasks), go to the [Webtasks page under Tenant Settings](${manage_url}/#/tenant/webtasks) in the Management Dashboard. + +## Configure Extensions + +When you activate a Webtask in the PSaaS Appliance, you get a URL specific to that instance of the Webtask service. By default, this URL is structured as follows: + +`webtask.` + +In order for you to configure Extensions, you will need to add this URL to the **Allowed Origins (CORS)** section under the [Auth0 Dashboard's Application Settings page](${manage_url}/#/applications). + +![Allowed Origins Section of Application Settings](/media/articles/appliance/allowed-origins.png) + +At this point, you can enable any of the available Extensions [in the dashboard](${manage_url}/#/extensions) and use them just as you would if your Auth0 installation were running in the cloud. + +## Delegated Administration Extension + +The [Delegated Administration](/extensions/delegated-admin) extension is available beginning with version 10755 when User search is enabled. + +## Dedicated Domains + +Beginning with PSaaS Appliance version `13451`, you may now configure Webtask on a [dedicated domain](/appliance/webtasks/dedicated-domains). This enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service). + +If you are planning on using Extensions, you **must** implement Webtask dedicated domains. diff --git a/fr-ca/articles/appliance/geo-ha/disaster-recovery.md b/fr-ca/articles/appliance/geo-ha/disaster-recovery.md new file mode 100644 index 0000000000..8750ac5517 --- /dev/null +++ b/fr-ca/articles/appliance/geo-ha/disaster-recovery.md @@ -0,0 +1,126 @@ +--- +section: appliance +description: Descriptions of PSaaS Appliance Geo HA Failure Scenarios and Testing +topics: + - appliance + - geo-ha +contentType: reference +useCase: appliance +applianceId: appliance28 +sitemap: false +--- + + + +# Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing + +The following table details some of the ways in which the Geographic High-Availability PSaaS Appliance may fail and what the implications of such a failure are. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EventOutcomePerformance Impact
Service and Data are available for Primary Site Nodes 1, 2, 3The primary site continues to serve all traffic.None.
Data Unavailable for Node 1Node 2 or Node 3 becomes the primary data node.None.
Service Unavailable for Node 1Node 1 is pulled from the primary site load balancer and no longer serves requests.Overall handling capacity may be reduced by up to a third.
Service and Data Unavailable for Node 1Node 2 or Node 3 becomes the primary data node. Node 1 is pulled from the primary site load balancer and no longer serves requests.Overall handling capacity may be reduced by up to a third.
Data Unavailable for Nodes 1 and 2Node 3 becomes the primary data node.None.
Service Unavailable for Nodes 1 and 2All requests from the primary load balancer are routed to Node 3.Overall handling capacity is significantly reduced. Possibility of manual failover to a secondary site.
Service and Data Unavailable for Nodes 1 and 2All requests from the primary load balancer are routed to Node 3, which is also the primary data node.Overall handling capacity is significantly reduced. Possibility of manual failover to a secondary site.
Data Unavailable for Nodes 1, 2, and 3The Arbiter elects Node 4, 5, or 6 to become the primary data node.Some performance degradation due to cross-geography data requests while the load balancer continues to service requests from the primary site. Possibility of manual failover to secondary site.
Service Unavailable for Nodes 1, 2, and 3The Global Load Balancer will route traffic to the secondary application servers (Nodes 4-6). These servers will request data from the primary data server, which is still in the primary data center.Some performance degradation due to cross-geography data requests while the load balancer continues to service requests from the primary site. Possibility of manual failover to secondary site.
Data and Service Unavailable for Nodes 1, 2, and 3The PSaaS Appliance instances associated with the secondary site are now serving requests.None.
Connection between the Global Load Balancer and the Primary Site UnavailableAll requests are routed to the secondary site, but the secondary nodes continue to use data on the primary site.Some performance degradation due to cross-geography data requests.
Arbiter is UnavailableIf the primary and secondary sites are still available, there will be no impact to the end user.None.
After failover, some (not all) of the nodes resume operationIf some of the nodes are again available in the primary site, the Global Load Balancer will automatically switch to routing requests to the primary site. The Arbiter sees the higher priority data node and sets it as the primary (once it has been fully synced).Possible transient period of unavailability as the load balancer switches the routing of requests.
All nodes are available again after a failover eventIf the nodes are again available in the primary site, the Global Load Balancer will automatically switch to routing requests to the primary site. The Arbiter sees the higher priority data node and sets it as the primary (once it has been fully synced).None.
+ +## Geographic High-Availability PSaaS Appliance Testing + +To test the Geographic High-Availability PSaaS Appliance (GEO HA) failover/failback procedure, you should: + +1. Take all nodes in the primary data center offline; +2. Run tests against the global load balancer to ensure that traffic gets rerouted to the secondary site. + +GEO HA does not support having both the primary and secondary sites disconnected and active at the same time. Because the data layer is arranged in one stretched cluster, the cluster only permits one data node to act as primary. + +The Arbiter, located in a third site, determines which site stays active in the case of severed connectivity between the two data centers, and during this period, it would continue to elect a node in the primary site to serve as the primary data node. As such, it is **not possible** to have two primary data nodes (one in the primary site and one in the secondary site) within a single cluster. + +The application layer is always active on all nodes. For performance reasons, only the site containing the primary data node typically serves traffic. This is managed by the global load balancer. + +## Backing Up the Geographic High-Availability PSaaS Appliance + +As a customer, it is your responsibility to perform regular backups on your Geographic High-Availability PSaaS Appliance (GEO HA). Auth0 recommends a single backup, since the GEO HA is a single cluster stretched over a distance. + +Typically, Auth0 recommends performing a daily backup. However, if you have concerns about a logical data corruption, or you need greater assurance of up-to-date data, you might choose to backup more frequently. + +Because the backup process puts a substantial load on the backup node, please contact your Auth0 Technical Account Manager to schedule a discussion about performance impact if backups are performed more frequently/during peak usage times. + +## Further Reading + +* [How to Configure the Command Line Interface for Use with PSaaS Appliance Instances](/appliance/cli/adding-node-to-backup-role) +* [Backing Up PSaaS Appliance Instances with the Command Line Interface](/appliance/cli/backing-up-the-appliance) +* [Adding PSaaS Appliance Nodes to the Backup Role](/appliance/cli/configure-cli) diff --git a/fr-ca/articles/appliance/geo-ha/dr-overview.md b/fr-ca/articles/appliance/geo-ha/dr-overview.md new file mode 100644 index 0000000000..32051a5492 --- /dev/null +++ b/fr-ca/articles/appliance/geo-ha/dr-overview.md @@ -0,0 +1,78 @@ +--- +section: appliance +description: Descriptions of PSaaS Appliance Geo HA Failure and Disaster Recovery +topics: + - appliance + - geo-ha + - disaster-recovery +contentType: reference +useCase: appliance +applianceId: appliance29 +sitemap: false +--- + + + +# Geographic High-Availability PSaaS Appliance Failure & Disaster Recovery + +One key aspect of the Geographic High-Availability (GEO HA) PSaaS Appliance is the data center redundancy and failure handling that ensures the highest form of PSaaS Appliance uptime offered by Auth0. + +## Standard Configuration + +The standard configuration of a GEO HA PSaaS Appliance is a stretched cluster that consists of the following pieces: + +* One geographically-aware global load balancer/DNS failover configuration; +* One primary data center with three PSaaS Appliance instances; +* One secondary data center with three PSaaS Appliance instances; +* One arbiter, a seventh instance that is located in its own data center. + +## Failure Scenarios and Handling + +The following table summarizes what might happen and its possible performance impact in the event that any portion of the standard configuration encounters an error. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EventOutcomePerformance Impact
Data unavailable for one or more (but not all) of the primary data center's node(s)Data for one of the remaining nodes becomes the primaryNone
Service unavailable for one or more (but not all) of the primary data center's node(s)The unavailable nodes are removed from the primary site load balancer and no longer serves requestsReduction in overall handling capacity
Data unavailable for all nodes in the primary data centerArbiter elects one of the secondary site's nodes to become the primary data nodePerformance degradation due to cross-geography data requests
Service unavailable for all nodes in the primary data centerGlobal load balancer redirects all requests to the secondary data center's nodes (but still serves data from the primary data center)Performance degradation due to cross-geography data requests
Neither data nor service for the primary data center is availableGlobal load balancer redirects all requests to the secondary data centerNone
Connection failure between global load balancer and primary data centerGlobal load balancer redirects all requests to the secondary data center's nodes (but still serves data from the primary data center)Performance degradation due to cross-geography data requests
Arbiter is unavailableNo impact to the end user if both the primary and secondary data centers are still availableNone
diff --git a/fr-ca/articles/appliance/geo-ha/index.md b/fr-ca/articles/appliance/geo-ha/index.md new file mode 100644 index 0000000000..16329c8635 --- /dev/null +++ b/fr-ca/articles/appliance/geo-ha/index.md @@ -0,0 +1,86 @@ +--- +url: /appliance/geo-ha +section: appliance +description: Descriptions of Appliance Geo HA +topics: + - appliance + - geo-ha + - disaster-recovery +contentType: + - index + - reference +useCase: appliance +applianceId: appliance30 +sitemap: false +--- + +# Private SaaS (PSaaS) Appliance: High Availability Geo Cluster (Geo HA) + +The high availability geo cluster is a PSaaS Appliance implementation that provides regional data center redundancy and rapid failure response. This is the highest form of PSaaS Appliance availability offered by Auth0. + +## Overview + +Auth0 adds to the single data center high availability solution by extending the cluster with a geographically distributed data center where the recommended **maximum round-trip latency should not exceed 100 ms**. The result is the high availability geo cluster, which is an active hot standby configuration with automated failure handling that can survive a regional outage. + +## Standard Configuration + +![](/media/articles/appliance/geo-ha.png) + +The standard configuration is a stretched cluster that consists of the following pieces: + +* One global load balancer/DNS failover configuration; +* One primary data center with three PSaaS Appliance instances; +* One standby data center with three PSaaS Appliance instances; +* One arbiter, a seventh instance that is located in its own data center. + +The standby data center instances possess the same PSaaS Appliance configuration as the primary data center instances, and continuous synchronization ensure that the data on the primary and standby data centers mirror each other. The GEOHA stretched cluster should be in the same provider (all nodes in AWS or all nodes in Azure or all nodes on-prem). + +::: note + Ports 27017 and 7777 must be open between all instances in the cluster. +::: + +### Arbiter + +The Arbiter node acts as an independent witness to the primary and secondary data centers. + +The Arbiter does not store data or execute application logic, but acts as a witness between the primary and standby data centers. By independently verifying if a data center is down or not, it prevents both from becoming active (such a scenario is known as the "split-brain" condition). + +Since the Arbiter isn’t storing data and doesn’t run any services, it can be a small instance with two cores and 4GB of memory. + +You must enable outbound [internet connectivity](/appliance/infrastructure/network#internet-connectivity) from the Arbiter for system updates. + +### Global Load Balancer/DNS Failover Configuration + +You will need to deploy a global load balancer that supports an active/standby configuration. This will be configured to begin using the secondary site if the primary site load balancer is unavailable. + +Two examples of products that support this configuration are the F5 Global Traffic Manager and the AWS Route 53 DNS service. The global load balancer is typically positioned in front of the local load balancers in each data center. + +### Application Tier + +Auth0 requires the use of a load balancer or DNS failover solution that prefers to serve application requests using the primary data center, despite the fact that the PSaaS Appliance instances in the hot standby data center are active and able to serve the requests. + +The application tier remains unaware of the locality of the primary data node, whereas the data layer resolves the location of the primary node (the only node that receives application queries). The primary node serves all read and write activities. For example, if the data centers for the geo cluster are in State A and State B and the ones in State B are active, any request serviced by the State A nodes at the application level requires data to then be written to a node in State B. This generally results in poorer performance due to the requests (and resulting round-trips) required to obtain the necessary data. Using a global load balancer or DNS failover solution to prefer the primary location, unless it is not healthy, mitigates this performance issue. + +### Data Tier + +The data tier operates independently of the application tier as a single cluster stretched across two geographically distributed data centers. Within each data center are three nodes, each provided local data redundancy and failover. + +Only one of the two data centers is designated as primary, and the instances within that data center are weighted such that those are always preferred for incoming requests. All read and write activities then pass through the single, active primary node. + +As long as all instances are visible to each other, the primary data center will always be elected. If the data center fails (that is, the instances are *not* visible to the witness and PSaaS Appliance in the standby data center), then a node in the secondary data center will be elected to become primary. + +If the primary data center becomes available again and its instances are visible to those of the arbiter and the secondary data center, the primary data center will again take precedence over the standby data center when handling incoming requests. + +## Failover Handling + +1. **The primary data center fails.** The nodes in the standby data center and the arbiter can no longer communicate with the nodes in the primary data center. +2. **The standby data center becomes the primary data center.** Because the standby data center instances and the arbiter form a majority, they will elect the standby data center instances to become the primary instances. +3. **The PSaaS Appliance associated with the primary data center begin failing.** Because the primary data center instances cannot communicate with the instances in the standby data center, the associated PSaaS Appliance instances begin to fail. +4. **The global load balancer/DNS failover configuration detects via health checking that the nodes in the primary data center aren't serving.** It will then switch over to sending requests to the instances of the standby data center. +5. **The PSaaS Appliance associated with the standby data center are now serving requests** and acting as the primary data node due to its election in step 2. + +### Keep reading + +::: next-steps +* [Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing](/appliance/geo-ha/disaster-recovery) +::: diff --git a/fr-ca/articles/appliance/index.html b/fr-ca/articles/appliance/index.html new file mode 100644 index 0000000000..56af4b1bc2 --- /dev/null +++ b/fr-ca/articles/appliance/index.html @@ -0,0 +1,145 @@ +--- +url: /appliance +section: appliance +classes: topic-page +title: PSaaS Appliance +topics: + - appliance +useCase: appliance +applianceId: appliance59 +sitemap: false +--- + +
+
+

Private SaaS (PSaaS) Appliance

+

+ An Auth0 deployment that exists in a dedicated area of Auth0's cloud or your AWS cloud. +

+
+ +

What is PSaaS Appliance?

+

+ PSaaS Appliance is a managed service that is typically used if your organization's compliance or policy requirements prevent you from using a multi-tenant cloud service. +

+

+ Auth0 is responsible for installation, maintenance, patching and updates. You are responsible for supplying and monitoring the infrastructure on which Auth0 runs (including, but not limited to, the VM host, storage, network resources, and other required dependencies). +

+ +

PSaaS Appliance Planning

+ + + +

PSaaS Appliance Administration

+ + diff --git a/fr-ca/articles/appliance/infrastructure/dns.md b/fr-ca/articles/appliance/infrastructure/dns.md new file mode 100644 index 0000000000..2466fa2ca1 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/dns.md @@ -0,0 +1,191 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about DNS +topics: + - appliance + - infrastructure + - dns +contentType: reference +useCase: appliance +applianceId: appliance31 +sitemap: false +--- + + + +# DNS + +The following document details the requirements of DNS records used for PSaaS Appliance instances. + +::: note +DNS records must be finalized for all of the tenants prior to PSaaS Appliance deployment. They cannot be changed afterwards. +::: + +You’ll need one certificate per environment (such as if you have a Dev/Test environment and a Prod environment, you’ll need two certs). + +If you’d like to use a [Webtask Dedicated Domain](/appliance/webtasks/dedicated-domains), you’ll need an additional DNS zone and certificate for each environment. If you have a Dev/Test environment and a Prod environment, you’ll need a two total of two certificates per environment. + +Dedicated and non-dedicated host names must be unique. + +## Sample DNS Naming Scheme + + + + + + + + + + + + + + + + + + + + +
Management Dashboardmanage.yourdomain.com
Configurationconfig.yourdomain.com
Webtaskwebtask.yourdomain.com
App Tenant(s)identity.yourdomain.com (for example);
app-project.yourdomain.com (if you want more than 1 App tenant)
...and so on
+ +For a dev/test non-production PSaaS Appliance a common practice is to include "dev” in the domain name: + + + + + + + + + + + + + + + + + + + + +
Management Dashboard (Dev)manage.dev.yourdomain.com
Configuration (Dev)config.dev.yourdomain.com
Webtask (Dev)webtask.dev.yourdomain.com
App Tenant(s) (Dev)identity.dev.yourdomain.com (for example);
app-name.dev.yourdomain.com (if you want more than 1 App tenant)
...and so on
+ +### Definitions of Terms Used in the DNS Naming Scheme + +* **Configuration**: highly-privileged tenant used to do the PSaaS Appliance baseline configuration and for managing the security of other tenants; +* **App**: the name of your application; +* **yourdomain.com**: your organization's domain name. + +![](/media/articles/appliance/infrastructure/appliance-dns.png) + +## Multi-Tenancy + +The Auth0 PSaaS Appliance is capable of supporting multi-tenancy (that is, each tenant may have one or more associated apps). Auth0 may recommend this deployment model when multiple groups within your company share the PSaaS Appliance for different projects. If a customer decides to create multiple app tenants, each app tenant must have its own DNS entry. + +## DNS Configuration Requirements + +In a standard multi-node cluster deployment, the DNS records will point to the IP address of the [load balancer in front of the cluster](/appliance/infrastructure/infrastructure-overview). + +### IP Addresses and DNS Records + +For a single-node PSaaS Appliance instance, the DNS record(s) will point to the IP address of the virtual machine itself (this is often the case for the development/test node). + +::: note + Auth0 does not recommend using the same wildcard certificate(s) for Production **and** non-Production (Test/Development) environments **or** mapping the DNS for both environments to the same servers. +::: + +### Hostnames + +The hostname (such as **manage-project**.yourdomain.com) must be at least three characters long and must **not** contain any underscores(_). + +The following are reserved tenant names and **may not** be used for the **app** tenant. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
loginadminappmanageblog
ftpmailpoppop3imap
smtpstagestatsstatusdev
logswwwdocssdkci
dockerstyleguideaskitcdn
apireleasesreleasespffeedback
helpsupportintauth
+ +::: warning +Please note that the [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance) from **auth0** to the supplied name *must be greater than two*. This means that tenant names like **auth** or **authy** (and other similar names) cannot be used. + +To see if your tenant name meets this requirement, you can validate your selections using a [Levenshtein Distance calculator](http://www.unit-conversion.info/texttools/levenshtein-distance/). +::: + +The Management Dashboard, Configuration Tenant, and App Tenant(s) must all be a part of the same parent domain (such as yourdomain.com). + +Three- or four-part domain names are supported (such as manage.project.yourdomain.com). + +### Custom Domains + +In the PSaaS Appliance, you may map any arbitrary domain name to a tenant using the Custom Domains feature. You may also map multiple custom domains to a single tenant. + +Suppose these were your standard domains: + + + + + + + + + + + + + + +
Root Tenant AuthoritySample TenantCustom Domain for the Sample Tenant
config.example.comauth.example.comnew-name.not-example.com
+ +Please note that all tenant names are derived from the base Configuration Tenant. However, you may set your custom domain to point toward any of your tenants (in the example above, `new-name.not-example.com` maps to `auth.example.com`, and the latter may be used by your applications). diff --git a/fr-ca/articles/appliance/infrastructure/extensions.md b/fr-ca/articles/appliance/infrastructure/extensions.md new file mode 100644 index 0000000000..f2a2e22e74 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/extensions.md @@ -0,0 +1,76 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about enabling Webtasks and Extensions +topics: + - appliance + - infrastructure + - extensions +contentType: + - Reference +useCase: appliance +applianceId: appliance32 +sitemap: false +--- +# Enable Webtasks, Extensions, and User Search + +The PSaaS Appliance supports: + +* Extensions +* [Webtasks](appliance/webtasks) +* User search using Elasticsearch + +## Extensions + +You can find a list of extensions available to you [in the Dashboard](${manage_url}/#/extensions). + +Some of the [Extensions available to users of the Auth0 public cloud](/extensions) are unavailable in the PSaaS Appliance. As such, these do not appear as options in the PSaaS Appliance's Dashboard. + +## Webtasks Requirements + +Your Development and Production environments must meet the following requirements before you can enable Webtasks: + +* All nodes in the cluster have outbound access using **Port 443** to: + * `docker.it.auth0.com` (or `52.9.124.234`) + * `cdn.auth0.com` +* All nodes can communicate with other nodes in the same cluster using ports **8721** and **8701**. +* All [SSL certificates](/appliance/infrastructure/security#ssl-certificates) have the appropriate Webtask DNS entry. Examples: + * `webtask..com` + * `webtask-dev..com` + +## Enable Webtasks + +Once you have met the requirements for enabling Webtasks, submit a Support ticket to request that Auth0 configure Webtasks on your behalf. + +## Dedicated Domains + +You may configure Webtasks on a [dedicated domain](/appliance/webtasks/dedicated-domains). Using dedicated domains enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service). + +If you are planning on using Extensions, you **must** implement Webtask dedicated domains. + +## User search + +The PSaaS Appliance supports User Search using Elasticsearch. This allows you to use extensions that require user search functionality, including the [Delegated Administration extension](/extensions/delegated-admin). + +### Requirements for enabling user search + +To enable User Search, you must increase the amount of storage available in your Development and Production environments. + +* If you have a *single non-Production/Development node*, you need an additional **50 GB** drive; +* If you have a *three-node Production cluster*, you need an extra **100 GB** drive on *each* of your three Virtual Machines; +* If you have a *Geographic High-Availability implementation*, you need an additional **100 GB** drive on *each* of your data nodes in the primary and secondary data centers. + +For all other configuration types, please consult with your Customer Success Engineer. + +## Enabling User Search + +Once you have added the additional drive(s), submit a Support ticket to request that Auth0 enable User Search. + +## Keep reading + +::: next-steps +* [IP Address and Port Requirements](/appliance/infrastructure/ip-domain-port-list) +* [Extensions](/extensions) +* [Delegated Administration extension](/extensions/delegated-admin) +* [Webtasks](/appliance/webtasks) +* [Version Change Logs](https://auth0.com/changelog/appliance) +::: diff --git a/fr-ca/articles/appliance/infrastructure/faq.md b/fr-ca/articles/appliance/infrastructure/faq.md new file mode 100644 index 0000000000..e9dc9fc33e --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/faq.md @@ -0,0 +1,101 @@ +--- +description: This page answers several common questions regarding the PSaaS Appliance infrastructure. +section: appliance +topics: + - appliance + - infrastructure +contentType: reference +useCase: appliance +applianceId: appliance33 +sitemap: false +--- + +# PSaaS Appliance Infrastructure Requirements: Frequently Asked Questions + +#### Are there any functional differences between the Auth0 Cloud and the Auth0 PSaaS Appliance? +If you have been developing applications with Auth0 in the cloud environment, please review the [differences between the two environments](/deployment). Please speak to your Auth0 pre-sales engineer or customer success engineer if you’re unsure as to how this may impact your project. + +#### Can I configure an HTTP proxy for outbound Internet access in the PSaaS Appliance? +While proxies are currently unsupported, please speak to your Auth0 Customer Success Engineer if your needs require the user of a transparent proxy or NAT. + +#### Can I have SSH access to the machines? +No, the PSaaS Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the PSaaS Appliance. Auth0 will manage the PSaaS Appliance internals. + +#### Can I install a monitoring agent in the PSaaS Appliance? +No, the PSaaS Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the PSaaS Appliance. Auth0 will manage the PSaaS Appliance internals. The PSaaS Appliance [exposes monitoring information](/appliance/monitoring) in the Dashboard for common metrics (CPU/memory/and so on) or through the API, which can be used by your operations team and monitoring tools to determine how the PSaaS Appliance is performing. + +[Testall](/appliance/monitoring/testall) is an unauthenticated endpoint that can be used by load balancers. There are also additional authenticated endpoints that provide detailed information. + +#### Can I install anti-virus software on the PSaaS Appliance? +While this is currently not supported, preinstalled anti-virus software may be included in future updates. + +#### Will Auth0 provide me with a CSR file for my SSL Certificate? +No. The details of generating certificates, such as a CSR, vary among public certificate providers. Please work with your public certificate authority for these requirements. + +If Auth0 hosts the PSaaS Appliance, Auth0 will provide the required `*.auth0.com` SSL certificates. + +#### Why do both the DEV (non-prod) node and PROD cluster require unique certificates signed by a public Certificate Authority? +Webtasks and web extensions require this due to Node.js security requirements. + +#### Can I whitelist specific IP addresses on my firewall to the Internet sites the PSaaS Appliance requires outbound access to? + +For Auth0 PSaaS Appliance updates, we can provide you with specific addresses that are required. + +For certain protocols, [Internet connectivity is required during operation](/appliance/infrastructure/internet-restricted-deployment) (such as social connections or emails). + +Your server also needs to be able to access **cdn.auth0.com** if you run web extensions. The browsers used by your admins will also need to access the CDN if they navigate to the Management Dashboard. + +#### Can I use Lock with my PSaaS Appliance implementation? + +Yes, you can use Lock with your PSaaS Appliance implementation. + +However, if you choose to operate your applications connected to the [PSaaS Appliance in an Internet-restricted environment](/appliance/infrastructure/internet-restricted-deployment), you will need to copy the library files to your network (you won't be able to access the CDN that hosts Lock). + +If you choose this option, you are responsible for ensuring that your copy of the Lock source code stays up-to-date. + +#### How is the Auth0 software installed? + +The PSaaS Appliance is a managed service that is deployed as [virtual machines](/appliance/infrastructure/virtual-machines) and runs on your network, so there is no traditional software installation involved. + +Deployment of each PSaaS Appliance node is a manual process that must be performed by Auth0 Managed Service Engineers. + +#### Can the PSaaS Appliance deployment be automated through Chef scripts? + +Deployment of each PSaaS Appliance node is a manual process that must be performed by Auth0 Managed Service Engineers. + +While the images could be deployed via automation, configuration of the Appliance requires the services of an Auth0 Managed Service Engineer. + +#### Can we deploy the PSaaS Appliance using Docker? + +No, the Auth0 services cannot be deployed using Docker containers. + +#### Does the PSaaS Appliance environment autoscale (that is, does it automatically spin up new nodes or remove nodes as load and demand requires)? + +While the PSaaS Appliance can scale out its service layer, it is not currently designed to automatically scale up (or down) from the number of initial nodes deployed. + +Auth0 will work with you during the Sales/Onboarding process to ensure you are deploying the appropriate PSaaS Appliance architecture for your use case. + +Our Professional Services team offers [Performance and Scalability](https://auth0.com/docs/services/performance-scalability) engagements to performance test and subsequently tune the PSaaS Appliance to your specific requirements. + +#### How does Auth0 access customer-hosted PSaaS Appliance VMs? + +Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS Appliance instances to configure, perform updates, perform maintenance, or troubleshoot. The remote access options are: + +1. Jumphost + Firewall Whitelist +2. Two Jumphosts + +We do not support other methods, such as VDI or Screen Sharing mechanisms. + +#### We occasionally tear-down and rebuild environments, and we maintain our data by backing it up first. Is this a problem? + +The Auth0 Appliance is not designed to be torn down and rebuilt easily, and such actions always requires Auth0 involvement. We therefore ask that you not tear down the environment on purpose. + +To assist in the rebuilding of the environment, we would need to have an active Professional Services engagement in place with you, unless there has been a disaster situation. + +#### What are the legal terms of the Private SaaS Appliance? + +You can read the PSaaS Appliance terms [here](https://auth0.com/legal/baseline/PSaaS). + +#### Does the PSaaS Appliance require internet access? + +Please refer to [our documentation on the internet-related requirements](/appliance/infrastructure/internet-restricted-deployment) for the PSaaS Appliance. diff --git a/fr-ca/articles/appliance/infrastructure/index.md b/fr-ca/articles/appliance/infrastructure/index.md new file mode 100644 index 0000000000..6f2919f464 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/index.md @@ -0,0 +1,30 @@ +--- +title: PSaaS Appliance Infrastructure Requirements +url: /appliance/infrastructure +section: appliance +description: This document contains information about the PSaaS Appliance and its infrastructure requirements. +topics: + - appliance + - infrastructure +contentType: + - index + - reference +useCase: appliance +applianceId: appliance34 +sitemap: false +--- + +# Private SaaS (PSaaS) Appliance Infrastructure Requirements + +This document contains the following information about the PSaaS Appliance and its infrastructure requirements: + +* [installation process](/appliance/infrastructure/installation); +* [infrastructure overview](/appliance/infrastructure/infrastructure-overview); +* infrastructure requirements, including details for: + * [Virtual Machines](/appliance/infrastructure/virtual-machines); + * [Network](/appliance/infrastructure/network); + * [IP/Domain and Port List](/appliance/infrastructure/ip-domain-port-list) + * [Security and Access](/appliance/infrastructure/security). +* [Webtasks and Web Extensions](/appliance/infrastructure/extensions) + +Please consult the [FAQ](/appliance/infrastructure/faq) for further information about the PSaaS Appliance. diff --git a/fr-ca/articles/appliance/infrastructure/infrastructure-overview.md b/fr-ca/articles/appliance/infrastructure/infrastructure-overview.md new file mode 100644 index 0000000000..b9e92e633a --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/infrastructure-overview.md @@ -0,0 +1,16 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure overview +topics: + - appliance + - infrastructure +contentType: concept +useCase: appliance +applianceId: appliance35 +sitemap: false +--- +# PSaaS Appliance Deployment Architecture + +The typical Auth0 PSaaS Appliance production deployment is a three-node clusters that allows for high availability. The following diagram outlines the typical architecture. + + \ No newline at end of file diff --git a/fr-ca/articles/appliance/infrastructure/installation.md b/fr-ca/articles/appliance/infrastructure/installation.md new file mode 100644 index 0000000000..4197c25fc8 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/installation.md @@ -0,0 +1,66 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about installation +topics: + - appliance + - infrastructure + - installation +contentType: + - concept + - how-to +useCase: appliance +applianceId: appliance36 +sitemap: false +--- + + + +# PSaaS Appliance Infrastructure Overview + +## Project Coordination and Execution + +Auth0 provides a project plan methodology to help customers get up and running with the PSaaS Appliance as efficiently as possible. This requires significant cooperation and coordination across a number of your internal teams. Below is a list of teams commonly required to be involved in the PSaaS Appliance project and tasks they may be required to complete. In our experience, early exposure of the teams to the project and the tasks they'll have results in a more effective execution of the project plan. + + + + + + + + + + + + + + + + + + + + + + + + + + +
TeamSample Tasks
IT InfrastructureProvision Virtual Machines
IT SecurityGenerate SSL certificates; approve Internet access/ports
IT NetworkingConfigure firewall; deploy/configure load balancer
IT OperationsBackup and monitor PSaaS Appliance infrastructure
+ +## Overview of Required Steps + +The following basic steps are required to get the infrastructure up and running and the PSaaS Appliance deployed: + +1. Understand the PSaaS Appliance infrastructure requirements as detailed in this document. +2. Set up the infrastructure after the Appliance Project Manager has shared the required AMI file with you. +3. Complete and submit the [PSaaS Appliance Install Checklist](https://docs.google.com/forms/d/e/1FAIpQLSckWRi2MWpzhBkUXoqjaEzMPGUsyL4ICbOetcGvSnn64dSM-A/viewform?c=0&w=1) to notify Auth0 that you have the required infrastructure in place and that Auth0 can begin configuring the PSaaS Appliance. +4. Meet with Auth0 to deploy the DEV and PROD environments (the Appliance Project Manager will set up this meeting). + +## Development/Test/Production Lifecycle + +::: note +Production and non-Production (test/development) must be on completely isolated networks. +::: + +All PSaaS Appliance multi-node cluster subscription agreements require the deployment of a single-node Development/Test (non-Production) instance. This node is used to verify that the PSaaS Appliance is working as expected with your applications prior to deployment to Production. It also allows for a thorough PSaaS Appliance update and testing cadence. Lastly, this improves any possible support experiences, since Auth0 engineers prefer testing or reviewing planned changes/fixes to your implementation in a non-Production environment. diff --git a/fr-ca/articles/appliance/infrastructure/internet-restricted-deployment.md b/fr-ca/articles/appliance/infrastructure/internet-restricted-deployment.md new file mode 100644 index 0000000000..352e6b0e36 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/internet-restricted-deployment.md @@ -0,0 +1,66 @@ +--- +title: Internet-Restricted PSaaS Appliance Deployments +description: Operating the PSaaS Appliance in an Internet-Restricted Environment +contentType: reference +useCase: appliance +applianceId: appliance37 +sitemap: false +--- +# PSaaS Appliance Deployments with Limited Internet Connectivity + +The Auth0 PSaaS Appliance is delivered as a managed service that can run in: + +* A data center that you own +* A cloud-based environment that you own +* Auth0's private cloud + +The PSaaS Appliance is designed to mirror the solutions offered via the Auth0 Public Cloud as closely as possible to ensure that features *and* issue fixes can be readily applied to PSaaS Appliance. Though there are differences between the Public Cloud product and the PSaaS Appliance, these are primarily due to technical limitations posed by the PSaaS Appliance environments. + +## Internet-Restricted Environments + +While we make an effort to create PSaaS Appliances that are encapsulated for normal operation, there are several features that require access to external resources for normal functionality. These resources are primarily located on the Auth0 Content Delivery Network (CDN), which is accessed via **cdn.auth0.com**. + +::: warning +The PSaaS Appliance **must** have access to the internet during [update periods](https://auth0.com/docs/appliance/infrastructure/ip-domain-port-list#external-connectivity). +::: + +Operating the PSaaS Appliance in an internet-restricted environment results in the loss of the following features/functionality: + +* Analytics (including usage statistics) +* Authentication API Explorer +* [Extensions](/extensions) +* [Hooks](/hooks) +* Lock +* Management API Explorer +* Management Dashboard +* Quickstarts +* Social Connections + +### Management Dashboard + +The browser that you are using to manage your PSaaS Appliance requires Internet access to navigate to the Management Dashboard (located at **manage.your-domain**). + +You may, however, restrict server-side access to the Management Dashboard. + +To properly render the Dashboard, it accesses the following sites: + +* **cdn.auth0.com**: resources loaded from this CDN are well-known and include CSS, JavaScript, and images. +* **fonts.googleapis.com**: resources loaded include CSS and font files. +* **s.gravatar.com** and **i2.wp.com**: resources include user profile images loaded from WordPress' Gravatar service. +* **fast.fonts.net**: resources include CSS files for font support. + +### Multi-factor Authentication (MFA) + +When using multi-factor authentication (MFA), you will need Internet access for Push notifications, SMS, and Voice. + +For limited connectivity options, you may choose from: + +* One-time password with Google Authenticator, Authy or similar apps +* A custom MFA implementation using redirect rules +* Duo (on-premise versions only) + +## Summary + +The PSaaS Appliance requires access to specific external resources for normal functionality, and we do not recommend restricting access to these resources for optimal function. These resources are primarily located on the Auth0 CDN. + +Currently, there are no plans to reduce the reliance of the PSaaS Appliance on the Auth0 CDN. diff --git a/fr-ca/articles/appliance/infrastructure/ip-domain-port-list.md b/fr-ca/articles/appliance/infrastructure/ip-domain-port-list.md new file mode 100644 index 0000000000..d81d3d2a2f --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/ip-domain-port-list.md @@ -0,0 +1,211 @@ +--- +description: PSaaS Appliance infrastructure information about IP/Domain and Port Usage +section: appliance +topics: + - appliance + - infrastructure + - ip-addresses + - domains + - ports +contentType: reference +useCase: appliance +applianceId: appliance38 +sitemap: false +--- + + + +# PSaaS Appliance Infrastructure Requirements: IP/Domain and Port List + +The PSaaS Appliance requires certain ports within the cluster to be open and able to access each other, as well as selected external sites. + +## Between Cluster Nodes + +When possible, instances within a cluster should have full connectivity to each other so that you do not need to introduce new firewall rules if Auth0 adds new features. However, since this isn't possible in every environment, the following table lists the ports that are required to be open and accessible to other PSaaS Appliance instances in the same cluster: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PortUseRequired?Notes
27017DatabaseYes
7777ControlYes
9001Rate LimitingYesRequired if rate limiting is used
8721Webtask Logging/ControlYesRequired for logging and debugging
8701Webtask Logging/ControlYesRequired for logging and debugging
9200, 9300-9400Elastic SearchYesRequired for Elastic Search
3000Grafana instrumentationNoRequired if you are using Grafana instrumentation
22MaintenanceNoEnables maintenance tasks to be done between nodes
ICMPHealthcheckNoAllows healthchecks between nodes
+ +## External Connectivity + +Auth0 strives to keep these IP addresses stable, though this is not a given. From time to time, Auth0 may add IP addresses or additional servers. During updates and metrics, you must allow your PSaaS Appliance instances to connect to these addresses. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
UseDirectionIP/DNSPortNotesRequired?
AllInboundYour load balancer IP address (often on internal network)80/(443 or 4443)For clusters with more than one node, a load balancer is required for resiliency and performanceYes
WebtaskOutboundYour load balancer IP address (often on internal network)443Allows rules, webtasks, and extensions to call back to Auth0 endpointsYes
Command Line InterfaceInbound and OutboundCLI Applications (often on the internal network)10121Allows use of the PSaaS Appliance Command Line InterfaceNo
UpdatesOutboundapt-mirror.it.auth0.com (52.8.153.197)443Provides update packages for PSaaS Appliance instancesYes
UpdatesOutbounddocker.it.auth0.com (52.9.124.234)443Provides updates for PSaaS Appliance Docker PackagesYes
Web extensions, Hooks, and Management DashboardOutboundcdn.auth0.com443Required to run web extensions and Hooks; also required for admins to browse to the Management DashboardYes
ExamplesOutboundgithub.com443Source to download and repackage example applicationsNo
Usage & TelemetryOutboundapp-gateway.it.auth0.com (52.40.103.203)443Provides usage and telemetry statisticsYes
MaintenanceInboundJump Host22Allows access to PSaaS Appliance instances for support purposesNo
Healthcheck InboundMonitoring Endpoint9110Allows access to Healthcheck endpointsNo
DNSInbound and OutboundLocal domain servers53Required by the PSaaS Appliance to resolve host names internal and external to your environmentYes
SMTPOutboundSMTP Server(s)25/587Allows sending of emails from the ApplianceNo
+ +## Notes + +* If you are using social providers for logins, the cluster must be able to connect to the social providers' endpoints. +* The Jump Host IP is stable and provided at the time of setup. diff --git a/fr-ca/articles/appliance/infrastructure/network.md b/fr-ca/articles/appliance/infrastructure/network.md new file mode 100644 index 0000000000..d197ad2191 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/network.md @@ -0,0 +1,98 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about Networks +topics: + - appliance + - infrastructure + - networks +contentType: reference +useCase: appliance +applianceId: appliance39 +sitemap: false +--- + +# PSaaS Appliance Infrastructure Requirements: Network + +This document details the requirements for the network on which the PSaaS Appliance runs. + +::: note +Auth0 PSaaS Appliance can only be deployed in 1 NIC. +::: + +In on-premise environment, all virtual machines should be in the same LAN in order for database replication to work properly. No other PSaaS Appliance cluster (Dev/Test) should be running on this subnet. + +In AWS Cloud environment, Auth0 supports and recommends cross-LAN availability zones. + +## IP Addresses + +Each PSaaS Appliance virtual machine (VM) must have its own private static IP address and outbound access. This can be accomplished through: + +* a public IP address; +* NAT or transparent proxy. + +For **multi-node** clusters, all virtual machines must be: +* on the same segment of the internal network; +* able to communicate between each other via ports `7777`, `27017`, `8721`, and `8701`. +* able to reach the load balancer via port `443`. + +::: note + Production and non-Production (test/development) must be on completely isolated networks. +::: + +For a full list of IP addresses, domains, and ports used by the PSaaS Appliance clusters, as well as what they are used for, please see [Appliance Infrastructure: IP/Domain and Port List](/appliance/infrastructure/ip-domain-port-list). + + +## Internet Connectivity + +Each PSaaS Appliance VM needs connectivity to the Internet. At a minimum, the VM needs access during Appliance configuration, maintenance windows, and troubleshooting. For implementations requiring integration with social providers and/or third-party API calls, the VM will need Internet access at all times. + +Since the PSaaS Appliance is delivered as a subscription-based managed service, Auth0 will need access to specified endpoints to provide proactive monitoring. + +Your server also needs to be able to access **cdn.auth0.com** if you run web extensions. The browsers used by your admins will also need to access the CDN if they navigate to the Management Dashboard. + +## DNS Records + +DNS records are required for all PSaaS Appliance instances (development/test *and* production). A standard single-node or cluster deployment requires four DNS entries for the following: + +* **Management Dashboard**: the Management Dashboard is the web interface that acts as an application for the configuration and application tenants on the PSaaS Appliance; +* **Root Tenant Authority**: the tenant on the PSaaS Appliance that controls PSaaS Appliance settings, configuration, and local Dashboard Admin users; +* **webtask**: webtask DNS is used for web extensions and to use Webtasks externally; +* **App Tenant**: the tenant on the PSaaS Appliance created for your apps. It manages settings for your apps, user profiles, rules, and so on. This is the tenant you will interact with primarily through the Management Dashboard and the API. + +Each additional DNS zone requires an additional certificate. Please refer to the [DNS page](/appliance/infrastructure/dns) for specific requirements. + +## Load Balancers (for Multi-Node Clusters only) + +You must include a round-robin load balancer in your infrastructure when implementing a multi-node cluster PSaaS Appliance with high-availability. + +We recommend a layer 7/application layer load balancer that supports: + +* HTTP health monitoring. The [testall](/appliance/monitoring/testall) endpoint is an unauthenticated endpoint that will be used for monitoring by load balancers; +* Awareness of websockets (this is required if using the Auth0 AD/LDAP Connector); +* TCP/IP: + * If your deployment requires geo-location data for users authenticating with Auth0, support for `proxy_protocols` (which append the remote UP address when opening a connection to the backend) will be exposed to the nodes. If `proxy_protocols` is not supported, the IP address information captured for individual logins will always appear as the Load Balancer IP address; +* HTTPS: + * If your deployment requires geo-location data for users authenticating with Auth0, you must support SSL offloading (or HTTP/1.1 with UPGRADE if you require websockets). It should support both the "Connection: Upgrade" and the "X-Forwarded-For" header. These are required to capture accurate IP address information. + +::: note + For AWS deployments, you must use TCP/IP. +::: + +### Software Load Balancers + +You may use NGINX or HA Proxy as a software load balancer in front of the PSaaS Appliance. The reverse proxy must be configured with: + +* TCP mode with Proxy Protocol or HTTPS mode (SSL offloading) +* the incoming hostname forwarded to the PSaaS Appliance nodes + +::: note + The Auth0 AD/LDAP Connector does not work in HTTPS mode. +::: + +In addition to load balancing, you may use this for **IP address whitelisting** and **endpoint filtering** (only authentication endpoints are publicly available). + +#### SSL Offloading + +The PSaaS Appliance supports the use of SSL offloading at the load balancer if your IT standards require the use of HTTP within the local network. The load balancer must add a `X-Forwarded-Proto` header with the value `https`. + +Please note that the use of SSL offloading is not required to achieve high throughput. diff --git a/fr-ca/articles/appliance/infrastructure/security.md b/fr-ca/articles/appliance/infrastructure/security.md new file mode 100644 index 0000000000..adc6c39577 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/security.md @@ -0,0 +1,99 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about security +topics: + - appliance + - infrastructure + - security +contentType: reference +useCase: appliance +applianceId: appliance40 +sitemap: false +--- + +# PSaaS Appliance Infrastructure Requirements: Security and Access + + This document details the security and access requirements for your PSaaS Appliance instances. + + ## SSL Certificates + +When using the PSaaS Appliance, you will need to provide several SSL certificates. You must create and install a unique SSL certificate for: + +* Each PSaaS Appliance (e.g., your production cluster, your development node, your QA environment) +* [Extensions](/appliance/extensions) +* [Custom Domains](/appliance/custom-domains) +* [Webtasks](/appliance/webtasks) (with or without [Dedicated Domains](/appliance/webtasks/dedicated-domains)) + + ::: note + If you are unsure of where to get SSL Certificates, please contact your network security team. They are usually the ones familiar with the required processes and working with the appropriate certificate authorities (CA) to generate new certificates. + ::: + +The SSL Certificate: + +* must be created by a public certificate authority. They cannot be self-signed; +* can be a wildcard *or* a multi-domain (SAN) certificate; +* must contain all required DNS/domain names, including those for the: + * Management Dashboard; + * Configuration Tenant; + * webtask; + * App Tenant(s) (current *and* future) specific to that particular PSaaS Appliance instance. + +Auth0 accepts the following certificate format: + +* PFX/PKCS12 + +If you are using CER / PEM format, you should [convert to PFX format](http://stackoverflow.com/questions/2957742/how-to-convert-pkcs8-formatted-pem-private-key-to-the-traditional-format). + +::: note + The PFX certificate must contain the full chain (all intermediate certificates must be included in the public key). +::: + +```text +-----BEGIN CERTIFICATE----- +MY-PUBLIC-KEY +-----END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +PARENT +-----END CERTIFICATE----- +``` + +If you're uploading the public and private keys separately, convert the private key to RSA as follows: + +```text +-----BEGIN RSA PRIVATE KEY----- +PRIVATE-KEY +-----END RSA PRIVATE KEY----- +``` + +## Transparent Proxies + +If you are behind a transparent proxy, you will need to: + +* obtain certificate(s) for your proxy created by a public certificate authority. +* add an exception so that the PSaaS Appliance instance(s) may get through the proxy unauthenticated. + +## HTTPS or TLS + +Users must connect to the PSaaS Appliance using secure protocols (HTTPS or TLS). Depending on your network design, you could terminate the Secure Channel at the load balancer or the PSaaS Appliance. In both cases, your SSL/TLS certificate must be locally installed on the PSaaS Appliance. + +## SMTP + +You must configure an SMTP server for the PSaaS Appliance to send emails. The PSaaS Appliance requires an authentication SMTP server that has been configured with SMTP PLAIN authentication. + +**AWS SES Users**: If your domain is not validated, you will not be able to send email with AWS SES. + +Optionally, you may use a Transactional Email Provider (such as SendGrid, Amazon SES, Mandrill). + +The PSaaS Appliance supports STARTTLS, but it is not required. + +## Auth0 Remote Access + +Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS Appliance instances to perform updates, maintenance, or troubleshooting. + +### Initial Configuration + +Auth0's remote access method for initial configuration requires SSH access via Jumphost. After the initial setup, please feel free to disable this connection. + +### Updates, Maintenance, and Troubleshooting + +Typically, updates are performed via the Auth0 Dashboard. If Auth0 needs to remote in to identify and troubleshoot issues, an Auth0 Customer Success Engineer will need access to the PSaaS Appliance through SSH access via Jumphost. This connection can be enabled for and disabled after the agreed-upon time frames for work. diff --git a/fr-ca/articles/appliance/infrastructure/virtual-machines.md b/fr-ca/articles/appliance/infrastructure/virtual-machines.md new file mode 100644 index 0000000000..45851327f6 --- /dev/null +++ b/fr-ca/articles/appliance/infrastructure/virtual-machines.md @@ -0,0 +1,48 @@ +--- +section: appliance +description: PSaaS Appliance infrastructure information about virtual machines +topics: + - appliance + - infrastructure + - virtual-machines +contentType: reference +useCase: appliance +applianceId: appliance41 +sitemap: false +--- + +# PSaaS Appliance Infrastructure Requirements: Virtual Machines + +You may deploy the PSaaS Appliance on your premises using your own infrastructure or the infrastructure of a cloud provider. Currently, Auth0 supports PSaaS Appliance usage on Amazon Web Services (AWS). + +## Virtual Machine Templates + +Auth0 provides the PSaaS Appliance via a Virtual Machine Template for you to provision on to your infrastructure. The template differs depending on the platform you are using for virtualization. For example, if you are using AWS, Auth0 will provide you with an [Amazon Machine Image](http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/AMIs.html) (AMI) or a [CloudFormation](https://aws.amazon.com/cloudformation/aws-cloudformation-templates/) template. + +## Virtual Machine Infrastructure Requirements + +When provisioning the PSaaS Appliance from the templates, Auth0 recommends the following specifications for the Virtual Machine infrastructure. For multi-node clusters, each node requires a separate VM that meet the specifications. + +* **Memory**: 32 GB RAM (minimum); +* **CPU**: 8 vCPU (minimum); +* **Storage**: + * *For Non-Production Nodes*: 4 drives: 60 GB for system/operating system storage, 50 GB for data storage, 50 GB for User Search, and 50 GB for backup purposes (if you want to test the backup process). + * *For three-node, high availability Production clusters*: + * Two of the virtual machines with 3 drives: 60 GB for system/operating system storage, 100 GB for data storage, and 100 GB for User Search; + * One virtual machine with 4 drives: 60 GB for system/operating system storage, 100 GB for data storage, 100 GB for User Search, and 100 GB for backup purposes. + * If you anticipate more than 10 million users, please let us know for additional storage requirements and considerations. + * Drives should be thick provisioned. + +::: note + Large installations will require higher IO performance. Auth0 will work with you to determine the required storage performance levels. +::: + +For multi-node clusters, Auth0 recommends deploying the PSaaS Appliance virtual machines across more than one physical host server/blade. + +## For AWS Users + +* The *recommended* [instance type](https://aws.amazon.com/ec2/instance-types/) is **m5.2xlarge** (minimum). +* Auth0 will need the following pieces of information to share the AMI with you: + * AWS account number; + * AWS region name. The region should have at least three [availability zones](https://aws.amazon.com/about-aws/global-infrastructure) for your Production cluster. +* If your production and development/test environments are within separate AWS accounts/regions, Auth0 will require the account number for both environments. diff --git a/fr-ca/articles/appliance/instrumentation.md b/fr-ca/articles/appliance/instrumentation.md new file mode 100644 index 0000000000..1aea21eb0a --- /dev/null +++ b/fr-ca/articles/appliance/instrumentation.md @@ -0,0 +1,61 @@ +--- +section: appliance +description: This document covers why and how to enable instrumentation in the PSaaS Appliance. +topics: + - appliance + - instrumentation +contentType: + - how-to +useCase: appliance +applianceId: appliance45 +sitemap: false +--- +# PSaaS Appliance Monitoring: Instrumentation + +The PSaaS Appliance allows you to collect time series data about individual processes and the overall cluster. + +To collect and analyze time series data, you must: + +* Have instrumentation enabled (please contact Auth0 for assistance with this) +* Export the data collected to DataDog + +If you've chosen to host the PSaaS Appliance in your on-premise data center or in a cloud data center to which you've subscribed (e.g. AWS or Azure), you must use the instrumentation feature to monitor your PSaaS Appliance. + +If Auth0 hosts the PSaaS Appliance on your behalf, you do not have access to this feature – Auth0's Managed Service Engineering (MSE) team will use instrumentation to monitor the PSaaS Appliance for you. + +## Alerts + +The PSaaS Appliance does not come with any built-in tool for sending alerts. To remedy this, we rely on DataDog and Telegraf to help implement robust monitoring and alerting strategies for the PSaaS Appliance. + +### Signals to Monitor + +These are the signals that the PSaaS Appliance makes available to DataDog via the Telegraf agent. The Telegraf agent defines these signals automatically. + +* [CPU](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/CPU_README.md) +* [Disk](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/DISK_README.md) +* [Disk IO](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/DISK_README.md) +* [Memory](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/MEM_README.md) +* [Processes](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/PROCESSES_README.md) +* [Swap](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/MEM_README.md) +* [System](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/SYSTEM_README.md) +* [MongoDB](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/mongodb/README.md) +* [Net](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/net.go) +* [NGINX](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/nginx/README.md) +* [RabbitMQ](https://github.com/influxdata/telegraf/tree/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/rabbitmq) +* [Procstat](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/procstat/README.md) +* [X509](https://github.com/influxdata/telegraf/blob/release-1.11/plugins/inputs/x509_cert/README.md) + +### Auth0 Signals to Monitor + +Please note that Auth0 exposes many internal metrics that will be visible in your DataDog console. The names of these metrics typically begin with `auth0_`. + +The internal metrics may change at any point, so in most cases, we do not recommend that you build monitoring strategies based on these signals (you can safely ignore these metrics, if you'd like). However, there are a few that you **should** monitor. We list the exceptions in the table below. + +| Signal | Description | +| - | - | +| auth0_http_requests_received | The total number of requests received by the PSaaS Appliance. | +| auth0_http_requests_replied | The total number of requests replied to by the PSaaS Appliance. | +| auth0_http_response_time.count | The number of responses issued by the PSaaS Appliance. This metric corresponds to `auth0_http_requests_replied`. | +| auth0_http_response_time.lower | The shortest amount of time it took for the PSaaS Appliance to respond to a request. | +| auth0_http_response_time.mean | The average time it took for the PSaaS Appliance to respond to a request. | +| auth0_http_response_time.upper | The longest amount of time it took for the PSaaS Appliance to respond to a request. | diff --git a/fr-ca/articles/appliance/modules.md b/fr-ca/articles/appliance/modules.md new file mode 100644 index 0000000000..494289c92f --- /dev/null +++ b/fr-ca/articles/appliance/modules.md @@ -0,0 +1,49 @@ +--- +section: appliance +description: For security reasons, rules and custom database connections for PSaaS Appliance run in a JavaScript sandbox. You can use the full power of the ECMAScript 5 language and a few selected libraries. +topics: + - appliance + - js-modules + - sandbox +contentType: reference +useCase: appliance +applianceId: appliance60 +sitemap: false +--- + +# Node.js Modules Available in Rules and Custom Database Connections + +For security reasons, you must execute rules and custom database logic for PSaaS Appliance using [the Webtask stage/sandbox](/appliance/webtasks). The sandbox offers you a performant environment running ECMAScript 6 and provides isolation for the code you've written. + +The current sandbox supports: + +| Module | Version (If Applicable) | Notes | +| - | - | - | +| [async](https://github.com/caolan/async) | ~2.1.2 | | +| [auth0](https://github.com/auth0/node-auth0) | 2.13.0 | 2.13.0 | +| [bcrypt](https://github.com/ncb000gt/node.bcrypt.js) | ~3.0.0 | | +| [Buffer](http://nodejs.org/docs/v0.10.24/api/buffer.html) | | | +| [cql](https://github.com/jorgebay/node-cassandra-cql) | ~0.4.4 | | +| [crypto](http://nodejs.org/docs/v0.10.24/api/crypto.html) | | | +| [ip](https://github.com/keverw/range_check) | 0.3.2 | | +| [jsonwebtoken](https://github.com/auth0/node-jsonwebtoken) | ~7.1.9 | | +| [knex](http://knexjs.org) | ~0.8.6 | The function returned by `require('knex')` is available as `Knex`. | +| [lodash](https://github.com/lodash/lodash) | ~4.17.10 | | +| [node-mongodb-native](https://github.com/mongodb/node-mongodb-native) | ~2.0.33 | | +| [node-mongodb-native - BSON](http://mongodb.github.io/node-mongodb-native/api-bson-generated/bson.html) | 0.3.2 | | +| [node-mongodb-native - Double](http://mongodb.github.io/node-mongodb-native/api-bson-generated/double.html) | | | +| [node-mongodb-native - Long](http://mongodb.github.io/node-mongodb-native/api-bson-generated/long.html) | | | +| [node-mongodb-native - ObjectID](http://mongodb.github.io/node-mongodb-native/api-bson-generated/objectid.html) | | | +| [node-mongodb-native - Timestamp](http://mongodb.github.io/node-mongodb-native/api-bson-generated/timestamp.html) | | | +| [mysql](https://github.com/felixge/node-mysql) | ~2.15.0 | | +| [pbkdf2](https://github.com/davidmurdoch/easy-pbkdf2) | 0.0.2 | | +| [pg](https://github.com/brianc/node-postgres) | 6.1.2 | | +| [pubnub](https://github.com/pubnub) | 3.7.11 | | +| [q](https://github.com/kriskowal/q) | ~1.4.1 | | +| [querystring](http://nodejs.org/api/querystring.html) | 0.2.0 | | +| [request](https://github.com/mikeal/request) | ~2.81.0 | | +| [uuid](https://github.com/kelektiv/node-uuid) | ~3.3.2 | | +| [xml2js](https://github.com/Leonidas-from-XIV/node-xml2js) | ~0.11.2 | | +| [xmldom](https://github.com/jindw/xmldom) | ~0.1.13 | | +| [xpath](https://github.com/goto100/xpath) | 0.0.9 | | +| [xtend](https://github.com/Raynos/xtend) | ~4.0.0 | | diff --git a/fr-ca/articles/appliance/monitoring/authenticated-endpoints.md b/fr-ca/articles/appliance/monitoring/authenticated-endpoints.md new file mode 100644 index 0000000000..50fa8bc069 --- /dev/null +++ b/fr-ca/articles/appliance/monitoring/authenticated-endpoints.md @@ -0,0 +1,171 @@ +--- +section: appliance +description: Overview of using the authenticated endpoint with the PSaaS Appliance +topics: + - appliance + - monitoring + - testing +contentType: how-to +useCase: appliance +applianceId: appliance47 +sitemap: false +--- + +# PSaaS Appliance: Authenticated Testing Endpoints + +Auth0 offers endpoints that allow you to check the system health of a specific resource. In this article, we will cover the authenticated endpoints, which are available to those who submit requests whose header contains the appropriate credentials. + +The authenticated endpoints are similar to the Test All endpoints in that both return positive or negative status information about system resources. + +Authenticated endpoints do not provide detailed information about the system's resource utilization. Instead, they return an HTTP status reflecting the status of a given resource. Using the third-party tools of your choice, you can set up alerts that activate based on the status codes returned by Auth0's endpoints. + +## How to generate an API key + +To send requests to the authenticated endpoints, you will need to generate and include an API key in the header of your request. + +Begin by navigating to the [Settings](/appliance/dashboard/settings) page of your PSaaS Appliance Dashboard. Scroll down to the [API Keys section](/appliance/dashboard/settings#api-keys). + +If this is the first time you are doing this, you'll see that there is no key. You can generate your first key by clicking the **Generate** button to the right. + +![](/media/articles/appliance/api-keys/no-key.png) + +You will be prompted to confirm the new key generation. + +Once confirmed, you will see that the key now populates the previously-blank field. + +![](/media/articles/appliance/api-keys/key.png) + +Scroll to the bottom of the page, and click Save to apply the new API Key value. + +At this point, Auth0 does a reconfiguration and restarts the health service. Once this process completes, you will be able to use your new API key. + +:::panel-warning Changing Your API Key +You may only use one API key at a time. If you generate a new key, be sure to provide the new key to your existing applications and services; otherwise, they will fail. +::: + +## Authenticated API Endpoints + +The API exposes a number of endpoints that you can use to test the status of the service. + +**Each node comes with its own set of endpoints, so you will need to make multiple calls if you are monitoring a multi-node PSaaS Appliance implementation.** The exception is the `GET /status/replicaset` endpoint, which reports on multiple nodes. + +There are two ways you can call a specific API endpoint: + +* Submit your request to the node directly +* Issue your request through the load balancer using the manage domain + +If you're checking the status of a specific node, it's best to submit your request to the node directly: + +```text +curl -v https://{node-ip}/health/status/cpu --user api_keys_health:YOUR_API_KEY +``` + +Otherwise, you can issue your request through the load balancer using the **manage** domain: + +```text +curl -v https://{manage-dashboard-domain}/health/status/cpu --user api_keys_health:YOUR_API_KEY +``` + +### Response Codes + +Each endpoint will return one of three status codes to communicate the status of the resource in question: + +| Response Code | Response | +| ------------- | -------- | +| 204 | OK | +| 429 | Too many requests | +| 520 | Warning | + +Additionally, each status code conveys additional information depending on the endpoint being queried. You'll find more information on this in the following sections that cover the specific endpoints available to you. + +None of the responses will include a body. + +#### GET /status/cpu + +This endpoint returns information about the overall available CPU capacity in the last minute on the PSaaS Appliance. Overall CPU capacity means that all CPU time is aggregated and compared with the time that any core was not idle. For example, if a four-core PSaaS Appliance node had two cores completely utilized and two cores completely idle, the CPU capacity calculated will be 50%. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The system had more than 20% of the total CPU capacity available in the last minute. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The system had 20% of the total CPU capacity (or less) available in the last minute. | + +#### GET /status/memory + +This endpoint returns information on the amount of memory available on the PSaaS Appliance. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The system has more than 10% of its memory available. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The system has 10% (or less) of its memory available. | + +#### GET /status/disk + +This endpoint returns information on disk utilization. Each node has a set number of volumes; if there is at least one volume that's utilizing more than 90% of the allocated disk space, the endpoint returns a warning. + +| Response Code | Response | +| ------------- | -------- | +| 204 | No volume on the node exceeds 90% utilization. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | One or more disk(s) on the node has exceeded 90% utilization. | + +#### GET /status/services + +This endpoint checks to see if any of the node's core Auth0 services are down. + +| Response Code | Response | +| ------------- | -------- | +| 204 | Every core service is running on the node. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | At least one of the core services on the node is not running. | + +#### GET /status/network + +This endpoint reports the status of the network for the node. The node issues a PING command to each node in the cluster, and if it fails to PING any node, the endpoint will return an error code. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The node was able to successfully ping every other node in the cluster. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The node was not able to ping at least one node in the cluster, indicating there's a network problem. | + +#### GET /status/internet + +This endpoint tests outbound internet connectivity on the node over port 443. This endpoint issues a `HEAD` request to `https://apt-mirror.it.auth0.com`. If the request returns anything other than a 200 status code, this endpoint will return an HTTP code indicating failure. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The node was able to successful issue a `HEAD` request to `https://apt-mirror.it.auth0.com`. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The was unable to issue a `HEAD` request, or the node received an error message after sending a `HEAD` request to `https://apt-mirror.it.auth0.com`. | + +#### GET /status/email + +This endpoint tests the SMTP connection using the provided configuration settings. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The node was able to use the provided configuration settings to connect to the SMTP server. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The node was unable to connect to the SMTP server. | + +#### GET /status/db + +This endpoint checks to see if the node can run database queries and receive the results. + +| Response Code | Response | +| ------------- | -------- | +| 204 | The node was able to successfully query the database. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | The node was not able to connect and run a query against the database. | + +#### GET /status/replicaset + +This endpoint checks to see if the replica set is healthy. If there is at least one node that is down, the endpoint will return an HTTP code indicating failure. + +| Response Code | Response | +| ------------- | -------- | +| 204 | All nodes in the replica set are up. | +| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. | +| 520 | At least one node in the replica set is down. | diff --git a/fr-ca/articles/appliance/monitoring/index.md b/fr-ca/articles/appliance/monitoring/index.md new file mode 100644 index 0000000000..a7f8f588d9 --- /dev/null +++ b/fr-ca/articles/appliance/monitoring/index.md @@ -0,0 +1,77 @@ +--- +url: /appliance/monitoring +section: appliance +description: Ways to monitor the PSaaS Appliance +topics: + - appliance + - monitoring +contentType: +- index +- concept +useCase: appliance +applianceId: appliance48 +sitemap: false +--- + +# Monitoring the Private SaaS (PSaaS) Appliance + +The PSaaS Appliance is a managed service, which means that Auth0 is responsible for: + +* Installation +* Updates +* General maintenance tasks + +However, the deployment option you choose affects the scope of what Auth0 can do when it comes to *monitoring* the PSaaS Appliance. Currently, Auth0 supports the following deployment options: + +* The subscriber's Amazon Web Services cloud environment +* An Auth0-controlled data center + +If you choose to deploy the PSaaS Appliance to an Auth0-controlled data center, we have control over every aspect involved (DNS, certificates, infrastructure, Auth0 software stack). This level of control allows us to assist you in monitoring the health of the PSaaS Appliance and acting to prevent or remediate issues. + +However, if you choose to deploy the PSaaS Appliance to AWS, **you are responsible for monitoring the deployment. Auth0 is unable to monitor such environments.** + +::: note +Please review [PSaaS Appliance: Roles and Responsibilities](https://auth0.com/docs/appliance/raci) for information on who is responsible for various activities related to managing and monitoring the PSaaS Appliance. +::: + +## Features Aiding Monitoring + +The PSaaS Appliance offers a number of tools to help you monitor the software that is running, as well as the infrastructure on which it runs. You can find additional information on these monitoring tools in the chart that follows: + +| Tool | Description | +| - | - | +| Service Status Check | The [`/testall` endpoint](/appliance/monitoring/testall) reports the overall status of core Auth0 services. You can call this endpoint from the load balancer or from an individual node. If called from the load balancer, you can determine if there's a system-wide service outage. If called from a specific node, you'll receive information on the status of core services running on that node alone. | +| System Health Checks | The [authenticated endpoints](/appliance/monitoring/authenticated-endpoints) provide a more granular health check than the `/testall` endpoint, allowing you to see the status of lower level system resources. With these endpoints, you can monitor the status of the PSaaS Appliance as it relates to memory, disk, network, internet, email, database, replica set, services, and the cluster.

The authenticated endpoints return status codes indicating whether the system resource in question is healthy or not. | +| [Instrumentation](/appliance/instrumentation) | The PSaaS Appliance offers instrumentation data, which is a vital component of monitoring and detecting anomalies or problems *before* they occur. To review your PSaaS Appliance instrumentation data, you can send it to DataDog. With DataDog, you can set up robust monitoring and alerts strategies to review the health of your PSaaS Appliance. | +| Dashboards | The PSaaS Appliance's [Troubleshooting](/appliance/dashboard/troubleshoot) dashboard allows you to view [Health Check](/appliance/dashboard/troubleshoot#health-check) results for the past 29 days. Please note that this dashboard does not provide any alerts functionality and should not be used as your only monitoring strategy. | +| Audit and Tenant Events | The [Tenant Logs](https://auth0.com/docs/logs) track processed transactions and provide an overview of application activity in your tenant. | +| Synthetic Transactions | You can use any third-party service that supports synthetic transaction to monitor PSaaS Appliance service availability. | + +## Recommended Monitoring Strategy + +Because each subscriber's implementation is different, the monitoring strategy you employ should match the needs of your use case. + +With that said, Auth0 suggests the following as a starting point for monitoring the PSaaS Appliance. The signals mentioned are indicators that there might be an unhealthy scenario occurring and provide information on the appropriate action for you to take: + +| Signal | Trigger | Action | +| - | - | - | +| [/testall at load balancer level](/appliance/monitoring/testall) | Does not return 200 with body OK | [Submit a support ticket](/support/tickets) with a severity of **Urgent** | +| [/testall at node level](/appliance/monitoring/testall#monitoring-individual-nodes) | Does not return 200 with body OK | [Submit a support ticket](/support/tickets) with a severity of **High** | +| [GET /status/memory](/appliance/monitoring/authenticated-endpoints#get-status-memory) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/disk](/appliance/monitoring/authenticated-endpoints#get-status-disk) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/network](/appliance/monitoring/authenticated-endpoints#get-status-network) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/internet](/appliance/monitoring/authenticated-endpoints#get-status-internet) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/email](/appliance/monitoring/authenticated-endpoints#get-status-email) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/db](/appliance/monitoring/authenticated-endpoints#get-status-db) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| [GET /status/replicaset](/appliance/monitoring/authenticated-endpoints#get-status-replicaset) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** | +| Synthetic Transaction: Login | Synthetic login failed | [Submit a support ticket](/support/tickets) with a severity of **Normal** | + +When building your monitoring strategy for a PSaaS Appliance implementation hosted on an environment you own or control, remember that you are responsible for using the instrumentation and tenant log data to watch for anomalies. + +## Your Responsibilities in Monitoring the Auth0-Hosted PSaaS Appliance + +If Auth0 hosts your PSaaS Appliance, you won't have access to instrumentation data. However, you are still expected to monitor your tenant logs for anomalies, since this provides you information on the health of your PSaaS Appliance-dependent applications. + +If Auth0 hosts your PSaaS Appliance implementation, Auth0's Managed Service Engineering (MSE) team is responsible for monitoring. However, the MSE team is focused on the health of the PSaaS Appliance – you are responsible for tracking the health of your applications, as well as its usage of Auth0. + +If you provide Auth0 with the appropriate email addresses, Auth0 can send a daily uptime report of your hosted PSaaS Appliance service to those email addresses. You can also specify one or more email addresses to which Auth0 will send alerts in the event that there is an issue. diff --git a/fr-ca/articles/appliance/monitoring/testall.md b/fr-ca/articles/appliance/monitoring/testall.md new file mode 100644 index 0000000000..442f42ee39 --- /dev/null +++ b/fr-ca/articles/appliance/monitoring/testall.md @@ -0,0 +1,48 @@ +--- +section: appliance +description: Overview of using the testall endpoint with the PSaaS Appliance +topics: + - appliance + - monitoring + - testing +contentType: how-to +useCase: appliance +applianceId: appliance49 +sitemap: false +--- + +# Using the `testall` Endpoint + +The `testall` endpoint can be accessed via http or https: + +```text +GET https://{your_auth0_server}/testall +``` + +The `/testall` endpoint checks the availability of the core Auth0 Authentication Service, as well as other services such as the Management Dashboard and Documentation pages. If all is well, the endpoint returns a response code of `200`. + +```text +200 +content-type: text/plain +OK +``` + +Alternatively, if there are any issues, `/testall` returns a `5xx` response code. + +## Monitoring Individual Nodes + +Typically, the above endpoint will reach the load balancer, but since a typical, highly-available deployment will have at least three nodes, Auth0 recommends monitoring those endpoints as well: + +* `http://{IP Address Node 1}/testall` +* `http://{IP Address Node 2}/testall` +* `http://{IP Address Node 3}/testall` + +Be sure to use the `http` *not* `https` in your URLs. + +### Non-Responsive Nodes + +The load balancer may remove nodes that are not responding or time out **without affecting service**, because all nodes of a cluster can serve requests from applications. All configuration information is continuously replicated across nodes. + +::: note + These endpoints are typically used by the Load Balancer to decide whether or not a node should be removed from the cluster. If a node stops responding, and the Load Balancer removes it, please contact [Auth0 Support](${env.DOMAIN_URL_SUPPORT}) for additional assistance. +::: diff --git a/fr-ca/articles/appliance/private-cloud-requirements.md b/fr-ca/articles/appliance/private-cloud-requirements.md new file mode 100644 index 0000000000..58a4f080df --- /dev/null +++ b/fr-ca/articles/appliance/private-cloud-requirements.md @@ -0,0 +1,130 @@ +--- +section: appliance +description: This document details the requirements for the Auth0 Dedicated Cloud Service. +toc: true +topics: + - appliance + - private-cloud + - requirements +contentType: reference +useCase: appliance +applianceId: appliance61 +sitemap: false +--- +# Requirements for the Auth0 Dedicated Cloud Service + +If your subscription agreement includes a Private SaaS (PSaaS) Appliance that is hosted in a dedicated area of Auth0's cloud, Auth0 will set up the PSaaS Appliance on your behalf. + +## Support + +Auth0 will provide you with an account to access the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}), where you can obtain information about your Auth0 environment and open support tickets. This account will be linked to your PSaaS Appliance and current [Support](/support) plan. + +In general, the tenant name you'll use for support is formatted as follows: **customer_name**-support + +You will also be asked to provide a list of tenant admins. Note that tenant admins can invite other support users. + +## Preferred AWS Regions + +You'll be asked for your preferred AWS regions, such as `AWS US-WEST-2`, `AWS US-East-1`, `AWS EU-Central-1`, and so on. You'll need to select: + +* One region for your Development node +* One region (with at least three [availability zones](https://aws.amazon.com/about-aws/global-infrastructure)) for your Production cluster + +## DNS Records + +::: warning +Please finalize DNS names prior to PSaaS Appliance deployment. +::: + +Auth0 provides the domain names needed for your DNS zones/certificates. If you have Development and Production environments, your domain names will typically be formatted as follows: + +| Environment | Sample Domain Name | +| ----------- | --------------------------- | +| Development | **company**-dev.auth0.com | +| Production | **company**.auth0.com | + +You will also need names for the Management Dashboard, Webtask endpoints, Webtask dedicated domain, and App Tenant. + +| | Description | +| - | ----------- | +| Management Dashboard | The Management Dashboard is your web application's management interface. You'll typically choose the name **manage**, but you can use something else if needed | +| Webtask Endpoints | The Webtask DNS is used for web extensions and external use of Webtasks. You'll typically use the name **webtask**, but you can use something else if needed | +| Webtask Dedicated Domain | Beginning with Appliance version 13451, Webtask may now be configured on a dedicated domain. This enables safely using extensions in multi-tenant environments in the same manner as the Auth0 Public Cloud Service. Auth0 will set up a DNS zone to host the name entries for each tenant. Auth0 recommends `*.wt..auth0.com`. | +| App Tenant | The App Tenant is the initial tenant where your applications reside. The is the tenant your users will interact with primarily, and you'll manage this using the Management Dashboard and API. + +### Sample Domain Name Sets + +The following is a sample set of domain names for a typical Development and Production environment setup where the App Tenant's name is **identity**. + +**Development** + +* **manage**.mycompany-dev.auth0.com +* **webtask**.mycompany-dev.auth0.com +* *.wt.mycompany-dev.auth0.com +* **identity**.mycompany-dev.auth0.com + +**Production** + +* **manage**.mycompany.auth0.com +* **webtask**.mycompany.auth0.com +* *.wt.mycompany.auth0.com +* **identity**.mycompany.auth0.com + +### Domain Name Patterns + +Each domain name will end in `auth0.com`. + +The Management Dashboard, Webtask, and App Tenant(s) **must** be a part of the same parent domain (such as `yourdomain.auth0.com`). + +The hostname (such as **manage-project**.yourdomain.auth0.com) must be at least three characters long and must **not** contain any underscores(_). + +The word `login` is reserved and **cannot** be used. Please also refer to the [full list of reserved words](/appliance/infrastructure/dns#hostnames). + +The domain name you use for tenants hosted in the Dedicated Cloud Service **cannot** be the same as any you're using for tenants hosted in the Public Cloud Service. + +**If you want to use your domain name in use on the Public Cloud Service in the Dedicated Cloud Service, we will need to delete your Public Cloud Service account.** + +## Administrator Email Addresses + +We will need the email addresses for the administrators of the **Manage** and **App** tenants in both the Development and Production environments + +### Group Email Address + +Auth0 will provide a daily uptime report of your PSaaS Appliance service, which is sent to an email address (with a group alias) specified by you. + +In the event that there is an issue, you can specify a group alias to receive alerts. + +### SMTP Settings + +::: note +This information is not required until the required environments are ready. Auth0 will work with you to update your settings. See the [SMTP section](/appliance/infrastructure/security#smtp) of the PSaaS Appliance infrastructure manual. +::: + +We will need the following SMTP-related values: + +* Host name +* Port number +* Username +* Password + +## Custom Domain + +::: note +A custom domain is optional, and Auth0 SLAs do **not** cover this portion of the PSaaS Appliance infrastructure. +::: + +You can configure a single custom domain name for your app tenants' domains. + +If you choose to use a custom domain, you'll need to manage the DNS name record, [SSL Certificate](/appliance/infrastructure/security#ssl-certificates), and add the appropriate DNS entry that alias the Auth0 identity. + +For example, you'll need to map `identity..auth0.com` to `identity..com`. + +::: warning +Webtask does not support custom domains. +::: + +### Keep Reading + +::: next-steps +* [Custom Domains on the PSaaS Appliance](/appliance/custom-domains) +::: diff --git a/fr-ca/articles/appliance/raci.md b/fr-ca/articles/appliance/raci.md new file mode 100644 index 0000000000..4d86c2fe93 --- /dev/null +++ b/fr-ca/articles/appliance/raci.md @@ -0,0 +1,64 @@ +--- +section: appliance +description: This document details who is responsible for what aspects of a given PSaaS Appliance installation. +topics: + - appliance + - raci +contentType: reference +useCase: appliance +applianceId: appliance62 +sitemap: false +--- + +# PSaaS Appliance: Roles and Responsibilities + +The PSaaS Appliance is a managed service that is used if your organization's compliance and/or policy requirements prevent you from utilizing a multi-tenant cloud service. The PSaaS Appliance provides the packaging and services required to run the Auth0 code base in a third-party environment. + +## General Division of Responsibilities + +**Auth0** is responsible for: + +* Initial installation; +* General maintenance; +* Installation of patches/updates. + +The **subscriber** is responsible for supplying and monitoring the infrastructure on which the PSaaS Appliance runs. This includes, but is not limited to: + +* The Virtual Machine host; +* Storage; +* Network resources; +* Required dependencies. + +## Detailed Division of Responsibilities + +The following RACI Matrix provides a more in-depth summary of the roles and responsibilities that will be allocated between Auth0 and the subscriber. + +### RACI + +* **Responsible**: the assigned party who is responsible for implementing the task as required; +* **Accountable**: the assigned party who is accountable for the task being completed as required; +* **Consulted**: the party (or parties) whose opinions are requested and with whom there is two-way communication; +* **Informed**: the party (or parties) who are kept up-to-date with regards to progress and with whom there is one-way communication + +|PSaaS Appliance-Related Tasks or Deliverables|Auth0|Subscriber|Notes| +|---|---|---|---| +|Preparing VM Infrastructure, including: memory, storage, processors, load balances, networks, SSL certificates, DNS records, SMTP servers, enabling Auth0 access via Jumphost/VPN|C|R, A (subscriber's infrastructure engineer)|The subscriber will submit the PSaaS Appliance Infrastructure Checklist when the VMs are ready and the [infrastructure requirements](/appliance/infrastructure) are met.| +|Deployment to Development and Production environments|R, A - Auth0 Managed Service Engineer (MSE)|I|The Auth0 Managed Service Engineer will SSH into the VMs and deploy the Appliance.| +|Configuration of Development and Production environments|C|R|The Auth0 MSE will show the subscriber's infrastructure engineer [how to upload the SSL certificates, enter the SMTP credentials, and add administrators](/appliance/dashboard).| +|Operations Handover|R|C|Auth0 Managed Service Engineers will provide a 90-minute Operations Handover meeting to review information regarding PSaaS Appliance monitoring, backup, and updates, as well as answer questions.| +|Monitoring|I|R, A|The subscriber is responsible for [monitoring the PSaaS Appliance](/appliance/monitoring).| +|Backing Up|I (in the event that there are issues)|R, A|The subscriber is responsible for [backing up the PSaaS Appliance](/appliance/disaster-recovery) using the [Command-Line Tools](/appliance/cli).| +|Code Integration into Applications|C, I (in the event that there are issues)|R, A|The subscriber is responsible for Auth0 code integration.| +|User Migration (if required)|C, I (in the event that there are issues)|R, A|The subscriber is responsible for migrating users where appropriate.| +|Updates|R|R, A|Auth0 Managed Service Engineers will partner with the subscriber's infrastructure engineers to update the PSaaS Appliance on an agreed-upon basis. The subscriber is responsible for: taking VM snapshot(s) prior to the update, providing access to the PSaaS Appliance, being present as the PSaaS Appliance updates. Auth0 is responsible for: running manual scripts (if required), informing the subscriber on the status of the upgrade.| +|Testing Updates|C, I (in the event that there are questions/issues)|R, A|The subscriber will test the PSaaS Appliance after the Development node has been updated and inform Auth0 about any issues.| +|Issue Identification and Support Ticket Submission|C|R, A|The subscriber is responsible for submitting issues via the [Support Center](/onboarding/enterprise-support).| +|Issue Resolution|R|C|Auth0 will provide support for issues within the *core* of the PSaaS Appliance. Auth0 will *consult* on issues pertaining to integration between Auth0 APIs and Dashboards.| + +### Keep Reading + +* [Overview](/appliance/appliance-overview ) +* [Infrastructure](/appliance/infrastructure) +* [Disaster Recovery](/appliance/disaster-recovery) +* [Enterprise Support](/onboarding/enterprise-support) +* [Critical Support Issues Guidance](/appliance/critical-issue) diff --git a/fr-ca/articles/appliance/remote-access-options.md b/fr-ca/articles/appliance/remote-access-options.md new file mode 100644 index 0000000000..586fd59a1f --- /dev/null +++ b/fr-ca/articles/appliance/remote-access-options.md @@ -0,0 +1,56 @@ +--- +title: PSaaS Appliance Remote Access Options +description: Remote Access Options Available for those with PSaaS Appliance +topics: + - appliance + - remote-access +contentType: reference +useCase: appliance +applianceId: appliance63 +sitemap: false +--- +# PSaaS Appliance Remote Access Options + +The Auth0 Private SaaS (Software as a Service) Appliance, or PSaaS Appliance, is an Auth0 deployment that exists in a dedicated area of Auth0's cloud, a cloud under your control, or your own data center. This article covers the remote options available to you if you opt for the PSaaS Appliance. + +## Customer Choices + +When the PSaaS Appliance is hosted in your cloud environment or datacenter, it requires regular access by our managed service engineering team to keep it up to date, fix problems, and optimize security and performance. There is a trade-off between maintaining strict isolation behind the customer’s firewall and the service level that we can offer. The options presented below offer the best balance between a high degree of isolation and support. Note that all options provide end-to-end SSH encryption of PSaaS Appliance management traffic and allow the customer to disable Auth0 access if needed. + +::: panel Jumphost +A Jumphost is a security-hardened virtual machine with the ability to act as a secure communication relay through SSH to the Auth0 PSaaS Appliance VMs. Jumphost initiates the connection from a whitelisted IP address provided by Auth0. You would open/close access to Jumphost on demand in situations where we require access, such as maintenance or support events. These connections originate from a VPN-secured network using public key access to your Jumphost, so that only authorized Auth0 managed service engineers can access your environment from a secure connection within Auth0. +::: + +### Option 1: Jumphost + Firewall Whitelist + +In this configuration, an external Auth0-managed Jumphost is permitted sole SSH management access to the PSaaS Appliance. + +![](/media/articles/appliance/remote-access/jumpshot-fw.png) + +*Pros*: + +* Jumphost provides a single point of access and auditing +* Audit, session recording, VPN access to Jumphost, and Identity Management done by Auth0 +* Access could be disabled via Firewall rules or Security Groups. + +### Option 2: Two Jumphosts + +Similar to option 1, this configuration permits an external Auth0 Jumphost to connect via firewall whitelist to an internal, customer-managed Jumphost. This second Jumphost then provides actual access to the PSaaS Appliance nodes. + +![](/media/articles/appliance/remote-access/jumpshot-fw-csjs.png) + +*Pros*: + +* Jumphost provides a single point of access and auditing +* Audit, session recording, VPN access to Jumphost, and Identity Management is done by Auth0 +* Disabling Auth0 access is as simple as shutting down a server +* Could be installed in DMZ if needed + +*Cons*: + +* Additional virtual Jumphost required in customer infrastructure + + +### Unsupported Configurations + +We do not support other methods, such as VDI or Screen Sharing mechanisms. They introduce compliance concerns, including (but not limited to) Auth0’s inability to internally audit connections and SSH sessions, enforce identity management on Auth0 employee accounts, exposure to untrusted systems on customer’s end running non-standard software (from where the connections are generated to Auth0 VMs), and inability to verify the identity of participants on the other end. diff --git a/fr-ca/articles/appliance/webtasks/dedicated-domains.md b/fr-ca/articles/appliance/webtasks/dedicated-domains.md new file mode 100644 index 0000000000..11bbe60ff3 --- /dev/null +++ b/fr-ca/articles/appliance/webtasks/dedicated-domains.md @@ -0,0 +1,97 @@ +--- +section: appliance +title: Configure Webtask with Dedicated Domains +description: How to use dedicated domains with your PSaaS Appliance Webtask +toc: true +topics: + - appliance + - webtask + - domains +contentType: + - concept + - reference + - how-to +useCase: appliance +applianceId: appliance50 +sitemap: false +--- +# PSaaS Appliance: Webtask with Dedicated Domains + +In order to use extensions, such as the [Authorization Extension](/extensions/authorization-extension/v2), you will need to configure Webtasks on a dedicated domain in PSaaS Appliance environments. This enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service). + +::: note +If you are planning on using [Extensions](/appliance/extensions), you must implement Webtask dedicated domains. +::: + +## Background + +Auth0 Extensions provide extra functionality to the core Auth0 services (Auth0 Platform) using the Webtask extensibility platform. By running these extensions in Webtask, we ensure that the extensions do not impact the regular operations of the Auth0 tenant. + +The PSaaS Appliance is a multi-tenant platform, which means that you can host and run multiple tenants in the same environment. Each of your tenants has full functionality of the Auth0 Platform, including use of the different extensions provided by Auth0. + +We found that extension developers needed what we call the **Full Trust mode** to improve the usability and functionality of the extensions they created. By enabling Full Trust mode, Webtask and extensions can create cookies and get increased control over the response sent to the browser. + +However, Full Trust mode raises security-related implications. More specifically, we want to ensure that enabling Full Trust mode did not overstep the boundaries established by individual tenants when it came to Webtask and extensions. As such, we ask that customers create a new root domain for Webtask that allows each tenant to have a dedicated domain. + +Essentially, this allows tenants to use extensions without providing access to cookies in the authentication domain. + +## Requirements + +For each environment (such as Development, Testing, or Production), you will need: + +* A certificate for your Webtask dedicated domain + * Dedicated and non-dedicated host names must be unique. +* A DNS zone for each domain to manage the name records of your tenants + +### Sample Architecture + +To clarify the requirements, let's look at a sample setup. + +The following are applicable to your environment as it current exists: + +* Your Production environment is accessible via `example.com` +* Your primary Auth0 tenant is `identity.example.com` +* Your current certificate is `identity.example.com` (or similar) + +You plan to implement the following change: + +* You want a Webtask dedicated domain configured to be `wt.example.com` + +To implement your change, you'll need: + +* A DNS zone for `wt.example.com` +* A certificate with the names of all your tenants *or* a wildcard certificate for `*.wt.example.com` + +Once complete, you'll be able to use the following for all containers under your primary tenant: + +```text +identity.wt.example.com/your-container-name +``` + +## Configuration + +To configure Webtask on a dedicated domain, you will need to set up a DNS zone to host the name entries for *each* tenant. As with the authentication domain, the Webtask dedicated domain requires a valid certificate issued by a public certificate authority (CA). If you're not certain how many tenants you'll be hosting, we recommend using a wildcard certificate such as `*.your-webtask-dedicated-domain`. + +This will give to each container a URL of the form: + +```text +tenant-name.webtask-dedicated-domain/container-name +``` + +For example, let's say that your tenant name is `acme` and your Webtask dedicated domain is `wt.example.com`. If you create a container named `hello`, your Webtask URL will be `acme.wt.example.com/hello`. + +Note that you can still use the original Webtask URL (for example, `webtask.example.com/api/run/acme/hello`). The primary difference is that, during runtime, the Webtask will remove any headers bearing cookies from the request. + +## Frequently Asked Questions + +**Can I use the same root domain for Auth0 and Webtask?** + +No. Because the tenant name is used in the first part of the domains for the Auth0 tenant and Webtask tenants, the *root* domain must differ. + +**Do I have to enable Webtask Dedicated Domains?** + +Yes, if you are planning on using Extensions, you must implement Webtask dedicated domains. + +**Can the Webtask tenant names differ from the one used by the Auth0 tenant?** + +No. The Webtask tenant name has to be the same as the Auth0 tenant name. diff --git a/fr-ca/articles/appliance/webtasks/index.md b/fr-ca/articles/appliance/webtasks/index.md new file mode 100644 index 0000000000..c390c9c027 --- /dev/null +++ b/fr-ca/articles/appliance/webtasks/index.md @@ -0,0 +1,122 @@ +--- +section: appliance +description: How to use Webtasks on the PSaaS Appliance +topics: + - appliance + - webtask +contentType: + - concept + - index +useCase: appliance +applianceId: appliance51 +sitemap: false +--- + +# PSaaS Appliance: Webtasks + +Beginning with Build 7247, you may use the PSaaS Appliance's version of [Webtasks](http://webtask.io/) to execute your rules and custom database logic. + +::: panel Prerequisites +Prior to working with Webtasks, please ensure that you have configured the: + +* [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli/configure-cli); +* [Webtask Command Line Interface (`wt-cli`)](https://webtask.io/docs/101) +::: + +Auth0 provides `auth0-sandbox`, a stage (sometimes referred to as a *sandbox*) on which you may run your rules and custom database logic. + +## Working with Webtasks + +You may use Webtasks by calling its endpoints directly. This can be done using the Webtask Command Line Interface (`wt-cli`) and specifying the ``--url "https://webtask..com"`` parameter (where `a0url` is the address of the PSaaS Appliance node). For additional information on setting up the `wt-cli`, please see [Getting Started with Webtasks](https://webtask.io/docs/101). + +### Node.js Modules + +Currently, not all of the [Node.js modules available for the Auth0 Cloud Environment](https://auth0-extensions.github.io/canirequire/) are available for the PSaaS Appliance. + +To see which modules are available for Webtasks running on PSaaS Appliance instances, execute the [`List Modules` Webtask](https://github.com/auth0-extensions/canirequire/blob/gh-pages/tasks/list_modules.js) on your PSaaS Appliance instance. + +#### Set up the List Modules Webtask + +First, copy locally the [`List Modules` Webtask](https://github.com/auth0-extensions/canirequire/blob/gh-pages/tasks/list_modules.js), either by downloading the file from GitHub or by copying this code: + +```js +'use npm'; +const Fs = require('fs'); +const Verquire = require('verquire'); +const _ = require('lodash@4.8.2'); + +const abcsort = function (a, b) { + if (a.name < b.name) { + return -1; + } + + if (a.name > b.name) { + return 1; + } + + return 0; +}; + + +const natives = Object.keys(process.binding("natives")) + .filter(nativeDep => nativeDep[0] !== '_') + .map(dep => ({name: dep, version: 'native'})) + .sort(abcsort); + + +const modules = _.flatMap(Verquire.modules, (versions, module_name) => { + return versions.map((version) => { + const moduleObj = { + name: module_name, + version: version + }; + + return moduleObj; + }); +}).sort(abcsort); + +module.exports = cb => { + cb(null, { + node_version: process.version, + modules: natives.concat(modules) + }); +}; +``` + +Next, create a Webtask profile using `wt-cli` (if you don't already have one): + +```bash +wt init --container "YOUR_TENANT_NAME" --url "WEBTASK_URL" --token "eyJhbGci..." -p "a``YOUR_TENANT_NAME-default" +``` + +Finally, you are ready to register your Webtask using the `wt create` command. This command receives as input a path or URL of the ebtask's code and provides as output the URL where the Webtask is available. + +If you saved the file under a `my-webtasks` directory as `list_modules.js` you would use the following: + +```bash +wt create ./my-webtasks/list_modules.js +``` + +You should get a message that the Webtask was created, alongside with the URL to access it. The response is a JSON object. + +```json +{ + "node_version":"v4.4.5", + "modules":[ + {"name":"assert","version":"native"}, + {"name":"buffer","version":"native"}, + {"name":"child_process","version":"native"}, + {"name":"assert-plus","version":"0.1.5"}, + ... + ] +} +``` + +## Keep reading + +::: next-steps +* [Getting Started with Webtasks](https://webtask.io/docs/101) +* [Using Webtasks as Code Sandboxes](https://webtask.io/docs/sample_multitenant) +* [HTTP API: Executing Webtasks](https://webtask.io/docs/api_run) +* [Webtasks with Dedicated Domains](/appliance/webtasks/dedicated-domains) +::: diff --git a/fr-ca/articles/application-auth/current/client-side-web.md b/fr-ca/articles/application-auth/current/client-side-web.md new file mode 100644 index 0000000000..8d504faa5c --- /dev/null +++ b/fr-ca/articles/application-auth/current/client-side-web.md @@ -0,0 +1,305 @@ +--- +title: Authentication for Client-side Web Apps +description: Explains how to authenticate users in a Client-side Web application. +toc: true +topics: + - spa + - authentication + - oauth2 + - implicit +contentType: + - concept + - how-to +useCase: + - add-login +--- + +# Authentication for Client-side Web Apps + +You can use the Auth0 Authentication API to create client-side web applications that use [OpenID Connect](/protocols/oidc) and [OAuth 2.0](/protocols/oauth2) to authenticate users and get their authorization to access protected resources. + +## Overview + +Auth0 exposes endpoints that you can use to authenticate users and get their authorization. You can redirect the user from your JavaScript application to these endpoints in the web browser. Auth0 will handle the authentication of the user, get their authorization for the resources your app wants to access, and then redirect the user back to a pre-configured callback URL, returning an [ID Token](/tokens/concepts/id-tokens) and [Access Token](/tokens/concepts/access-tokens) in the hash fragment of the request. + +## The Authentication Flow + +The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Client-side Web applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2). + +The Implicit Grant flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders). + +After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along the [ID Token](/tokens/concepts/id-tokens) as parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier). The [ID Token](/tokens/concepts/id-tokens) is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes (referred to as Claims) regarding the user, such as the user's name, email address, profile picture and so on. + +The [ID Token](/tokens/concepts/id-tokens) can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example. + +::: note +You can potentially also receive an Access Token which can be used to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or your own APIs. + +For more information on calling APIs from Client-side Web Apps, please see [Call APIs from Client-side Web Apps](/api-auth/grant/implicit) +::: + +![](/media/articles/client-auth/client-side-web/client-side-web-flow.png) + +1. The Applications initiates the flow and redirects the user to the Authorization Server +2. The user authenticates +3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment +4. The Applications can now extract the token from the hash fragment. + +## Register your Applications + +The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication. + +Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Applications** button. + +The **Create Applications** window will open, allowing you to enter the name of your new application. Choose **Single-Page Web Applications** as the **Applications Type** and click on the **Create** button to create the new applications. + +![](/media/articles/client-auth/client-side-web/create-client.png) + +Once the application has been created you can navigate to the **Settings** tab of the applications and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `https://YOUR_APP/callback`. + +This URL must be part of your application, as your application will need to extract the ID Token from the hash fragment of this URL. + +![](/media/articles/client-auth/client-side-web/allowed-callback-url.png) + +Next, click on **Show Advanced Settings**. Go to the **OAuth** tab and ensure that you have enabled the **OIDC Conformant** switch: + +![](/media/articles/client-auth/client-side-web/oidc-conformant.png) + +Save the Settings. + +## Call the Authorization URL + +The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. + +This endpoint supports the following query string parameters: + +| Parameter | Description | +|:------------------|:---------| +| response_type | The response type specifies the Grant Type you want to use. For client-side web applications using the Implicit Grant Flow, this should be `id_token`. (If you also want to receive an Access Token it should be set to `token id_token`.) | +| client_id | The Client ID of the Applications you registered in Auth0. This can be found on the **Settings** tab of your Applications in the Auth0 Dashboard | +| scope | Specifies the claims (or attributes) of the user you want the be returned in the [ID Token](/tokens/concepts/id-tokens). To obtain an [ID Token](/tokens/concepts/id-tokens) you need to specify at least a scope of `openid`. If you want to return the user's full profile information, you can request `openid profile`.

You can read up more about [scopes](/scopes). | +| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `https://YOUR_APP/callback`| +| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

If this parameter is not specified, the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your applications. | +| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) | +| nonce | A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). **This is required.** | + +::: note + Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Applications inside the [Auth0 Dashboard](${manage_url}). +::: + +## Handle the callback + +After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the [ID Token](/tokens/concepts/id-tokens) in the hash fragment of the URL, such as + +```text +https://YOUR_APP/callback#id_token=eyJ0... +``` + +The [ID Token](/tokens/concepts/id-tokens) will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can access the hash fragment using the `window.location.hash` property and then use basic JavaScript string manipulation to access the ID Token. + +You will need to decode the [ID Token](/tokens/concepts/id-tokens) in order to read the claims (or attributes) of the user. + +Once the JWT is decoded, you can extract the information about the user from the payload of the [ID Token](/tokens/concepts/id-tokens). This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. + +The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you in decoding the JWT by calling the `parseHash` function, and then access the ID Token values from the `idTokenPayload` property: + +```html + + + + + Document + + + + + + + + + +``` + +### The ID Token payload + +An example payload for an [ID Token](/tokens/concepts/id-tokens) may look something like this: + +```json +{ + "name": "Jerrie Pelser", + "email": "jerrie@j...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129, + "nonce": "..." +} +``` + +The payload above contains the following claims: + +| Parameter | Description | +|:------------------|:---------| +| name | The name of the user which is returned from the Identity Provider. | +| email | The email address of the user which is returned from the Identity Provider. | +| picture | The profile picture of the user which is returned from the Identity Provider. | +| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. | +| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued [ID Token](/tokens/concepts/id-tokens), this will be **the URL of your Auth0 tenant**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued [ID Token](/tokens/concepts/id-tokens), this will be the **Client ID of your Auth0 Applications**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| nonce | A string value which was sent with the request to the `/authorize` endpoint. This is used to [prevent token replay attacks](/api-auth/tutorials/nonce). | + +The exact claims contained in the [ID Token](/tokens/concepts/id-tokens) will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an [ID Token](/tokens/concepts/id-tokens) issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned. + +::: note +The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token. +::: + +### Keep the user logged in + +Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use `localStorage` to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the [ID Token](/tokens/concepts/id-tokens). + +You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience. + +## Examples + +### A Basic Authentication Request + +The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections. + +```text +https://${account.namespace}/authorize + ?response_type=id_token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &nonce=abc +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... +``` + +And this is an example of the decoded payload of the [ID Token](/tokens/concepts/id-tokens) which will be returned: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929, + "nonce": "abc" +} +``` + +### Request the Name and Profile Picture + +You can request a user's profile attributes, such as name and profile picture, by requesting the `profile` scope. + +```text +https://${account.namespace}/authorize + ?response_type=id_token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile + &nonce=abc +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... +``` + +The name and profile picture will be available in the `name` and `picture` claims of the returned [ID Token](/tokens/concepts/id-tokens): + +```json +{ + "name": "jerrie@...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129, + "nonce": "abc" +} +``` + +### Request a User Log In With GitHub + +You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid` and `profile` scopes: + +```text +https://${account.namespace}/authorize + ?response_type=id_token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile + &connection=github + &nonce=abc +``` + +::: panel Log in with other social providers +You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info: +- [Identity Providers Supported by Auth0](/identityproviders) +- [Social Login using the Authentication API](/api/authentication#social) +::: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... +``` + +The user's name and profile attributes, such as the name, nickname and picture will be available in the `name`, `nickname` and `picture` claims of the returned [ID Token](/tokens/concepts/id-tokens). You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: + +```json +{ + "name": "Jerrie Pelser", + "nickname": "jerriep", + "picture": "https://avatars.githubusercontent.com/u/1006420?v=3", + "iss": "https://auth0pnp.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` diff --git a/fr-ca/articles/application-auth/current/index.md b/fr-ca/articles/application-auth/current/index.md new file mode 100644 index 0000000000..685c9b3586 --- /dev/null +++ b/fr-ca/articles/application-auth/current/index.md @@ -0,0 +1,35 @@ +--- +classes: topic-page +title: Application Authentication +description: Introduction to authentication and the various application authentication flows. +topics: + - authentication + - oauth2 +contentType: index +useCase: + - add-login +--- + +# Authentication + +Authentication refers to the process of confirming identity. While often used interchangeably with [authorization](/authorization), authentication represents a fundamentally different function. + +In authentication, a user or application proves they are who they say they are by providing valid credentials for verification. Authentication is often proved through a username and password, sometimes combined with other elements called _factors_, which fall into three categories: what you know, what you have, or what you are. + +* **Single-Factor Authentication** relies on a password. Example: a school website that only requires validating a password against a username. +* **Two-Factor Authentication** relies on a piece of confidential information in addition to a username and password. Example: a banking website that validates a password against a username and then requires the user to enter a PIN known to only the user. +* **Multi-Factor Authentication (MFA)** uses two or more security factors from independent categories. Example: a hospital system that requires a username and password, a security code received on the user's smartphone, and fingerprint. + +For a comparison of authentication and authorization, see [Authentication vs. Authorization](/authorization/concepts/authz-and-authn). + +# Application Authentication Flows + +Auth0 uses [OpenID Connect](/protocols/oidc) and [OAuth 2.0](/protocols/oauth2) to authenticate users and verify their identity. + +We support scenarios for mobile, desktop, server-side, or client-side applications. You can get more details on implementing these flows by exploring: + +<%= include('../../_includes/_topic-links', { links: [ + 'flows/guides/auth-code-pkce/add-login-auth-code-pkce', + 'flows/guides/implicit/add-login-implicit', + 'flows/guides/auth-code/add-login-auth-code' +] }) %> diff --git a/fr-ca/articles/application-auth/current/mobile-desktop.md b/fr-ca/articles/application-auth/current/mobile-desktop.md new file mode 100644 index 0000000000..183b936bb5 --- /dev/null +++ b/fr-ca/articles/application-auth/current/mobile-desktop.md @@ -0,0 +1,389 @@ +--- +title: Authentication for Mobile & Desktop Apps +description: Explains how to authenticate users in a mobile or desktop application. +toc: true +topics: + - authentication + - oauth2 + - mobile-apps + - desktop-apps +contentType: + - concept + - how-to +useCase: + - add-login +--- +# Authentication for Mobile & Desktop Apps + +You can authenticate users of your mobile/desktop applications by: + +* Using [Lock](/libraries/lock), a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface; +* Using one of the [Auth0 SDKs](/libraries), which are client-side libraries that **do not** include a user interface but allow for expanded customization of the authentication behavior and appearance of the login screen; +* Calling the Auth0 [Authentication API](/api/authentication) endpoints, which allows you to integrate with Auth0 without requiring the user of Auth0's libraries. + +This article will cover how to call the Auth0 [Authentication API](/api/authentication) endpoints using [Proof Key for Code Exchange (PKCE)](/api-auth/grant/authorization-code-pkce) during the authentication and authorization process. + +If you would like to implement this functionality using either Lock or one of the Auth0 SDKs, please refer to the following resources: + +* Lock + * [Lock for Web](/libraries/lock) + * [Lock for iOS](/libraries/lock-ios) + * [Lock for Android](/libraries/lock-android) +* Auth0 SDK + * [Auth0 SDK for Web](/libraries/auth0js) + * [Auth0 SDK for iOS](/libraries/auth0-swift) + * [Auth0 SDK for Android](/libraries/auth0-android) + +## Overview + +Auth0 exposes endpoints that you can use to authenticate users and get their authorization. + +You can call these endpoints through an embedded browser in your **native** application. After authentication completes, you can return an [ID Token](/tokens/concepts/id-tokens) (which contains information about the identity of the user) and an [Access Token](/tokens/concepts/access-tokens). + +::: note +Instead of following this tutorial, you can use any of Auth0's client libraries. They encapsulate all the logic required and make it easier for your to implement authentication. Please refer to our [Native Quickstarts](/quickstart/native) to get started. +::: + +## Register your application + +If you haven't already created a new [application](/applications) in Auth0, you'll need to do so before implementing your authentication flow. The Auth0 Application maps to your application and allows your application to use Auth0 for authentication purposes. + +Go to the [Auth0 Dashboard](${manage_url}) and click on [Applications](${manage_url}/#/applications) in the left-hand navigation bar. Click **Create Application**. + +The **Create Application** window will open, allowing you to enter the name of your new Application. Choose **Native** as the **Application Type**. When done, click on **Create** to proceed. + +::: warning +The Authorization Code flow with PKCE can only be used for Native Applications. +::: + +![](/media/articles/client-auth/mobile-desktop/create-client.png) + +Once Auth0 creates the Application, navigate to the Application's **Settings** tab to: + +* Add the following URL to the **Allowed Callback URLs** field: `https://${account.namespace}/mobile`; +* Enable the **OIDC Conformant** Flag under the *OAuth* area of *Advanced Settings*. + +Scroll to the bottom of the page and click **Save**. + +![](/media/articles/client-auth/mobile-desktop/allowed-callback-url.png) + +## Implement Authentication + +For our mobile app, we will implement the [OAuth 2.0 Authorization Code Grant Flow using Proof Key for Code Exchange](/api-auth/grant/authorization-code-pkce). + +### Step 1: Create a Random Key and the Code Challenge + +First, you will need to generate and store a `code_verifier`, which is a cryptographically random key that, along with its transformed value (called the `code_challenge`), will be sent to Auth0 for an `authorization_code`. + +For sample scripts, to generate a `code_verifier` and a `code_challenge`, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#1-create-a-code-verifier). + +### Step 2: Authorize the User + +Once you've created the `code_verifier` and the `code_challenge`, you'll need to get the user's authorization. This is technically the beginning of the authorization flow, and this step may include one or more of the following processes: + +* Authenticating the user; +* Redirecting the user to an Identity Provider to handle authentication; +* Checking for active Single Sign-on (SSO) [sessions](/sessions). + +To authorize the user, your application must send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-) (which includes the `code_challenge` you generated in the previous step, as well as the method you used to generate the `code_challenge`). Your URL should follow this format: + +```text +https://${account.namespace}/authorize? + scope=SCOPE& + response_type=code& + client_id=${account.clientId}& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + redirect_uri=${account.namespace}/mobile +``` + +Note that the sample Authorization URL doesn't include an `audience` parameter. In this scenario, your app needs to authenticate only the user, not access an API, so we omit `audience`. + +For details on the request parameters, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#3-get-the-user-s-authorization). + +As an example, your HTML snippet for your authorization URL might look like the following: + +```html + + Sign In + +``` + +If all goes well, you'll receive an `HTTP 302` response: + +```text +HTTP/1.1 302 Found +Location: https://${account.namespace}/mobile?code=AUTHORIZATION_CODE +``` + +Note the authorization code included at the end of the included URL. + +### Step 3: Obtain an ID Token + +Using the authorization code obtained in step 2, you can obtain the ID Token by making the appropriate `POST` call to the [tokens endpoint](api/authentication#authorization-code-pkce-). + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "code_verifier", + "value": "YOUR_GENERATED_CODE_VERIFIER" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "https://${account.namespace}/mobile" + } + ] + } +} +``` + +For details on the request parameters, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#4-exchange-the-authorization-code-for-an-access-token). + +If all goes well, you'll receive an HTTP 200 response with the following payload: + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +::: note +You can use the Access Token to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info). +::: + +## The ID Token + +Once you've decoded the ID Token, you can extract user information from it. The JSON payload contains the user claims (attributes), as well as metadata, and it will look something like this: + +```json +{ + "name": "John Smith", + "email": "jsmith@example.com", + "picture": "https://example.com/profile-pic.png", + "iss": "https://auth0user.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +For additional details, please see our docs [on the ID Token and its claims](/tokens/id-tokens#id-token-payload). + +::: note +For a list of libraries you can use to verify and decode tokens refer to [JWT.io](https://jwt.io/#libraries-io). +::: + +## Example Use Cases + +This section covers use cases that illustrate the authentication process using PKCE. + +### Request the User's Name and Profile Picture + +In addition to the usual authentication, this example shows how you can request additional user details. + +We assume that your app is capable of generating the appropriate `code_verifier` and `code_challenge`. + +To return the user's `name` and `picture`, add the appropriate scopes to your call to the `/authorize` endpoint. Therefore, the initial authorization URL is as follows: + +```text +https://${account.namespace}/authorize? + scope=openid%20name%20picture& + response_type=code& + client_id=${account.clientId}& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + redirect_uri=${account.namespace}/mobile +``` + +After the user submits the request, the app receives an `TTP 302` response with a URL containing the authorization code at the end: `https://${account.namespace}/callback?code=AUTHORIZATION_CODE` + +Using the authorization code, you can obtain the ID Token by making a `POST` call to the [tokens](/api/authentication#authorization-code-pkce-) endpoint. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "code_verifier", + "value": "YOUR_GENERATED_CODE_VERIFIER" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "https://${account.namespace}/mobile" + } + ] + } +} +``` + +If all goes well, you'll receive an HTTP 200 response with the following payload: + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +By extracting the ID Token, which now contains the additional `name` and `picture` claims you requested, you'll see something similar to the following once you've decoded the payload: + +```json +{ + "name": "auth0user@...", + "picture": "https://example.com/profile-pic.png", + "iss": "https://auth0user.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +### Request a User Log In with GitHub + +You can send a user directly to the GitHub authentication screen by passing the `connection` parameter and setting its value to `github`. + +:::panel Logins with Social Providers +While this example shows how to log in users via GitHub, you can just as easily request that a user log in with other Social providers, such as Google or Facebook. + +To do this, configure the appropriate Connection in the [Auth0 Dashboard](${manage_url}/#/connections/social) and change the `connection` value of the call to `/authorize` to the name of the Connection (`google-oauth2` for Google, `facebook` for Facebook, and so on). You can get the Connection's name from the *Settings* tab of the [Connections](${manage_url}/#/connections/social) page. + +Read more: + +* [Identity Providers Supported by Auth0](/identityproviders) +* [Social Login using the Authentication API](/api/authentication#social) +::: + +```text +https://${account.namespace}/authorize? + scope=openid%20name%20picture& + response_type=code& + client_id=${account.clientId}& + code_challenge=CODE_CHALLENGE& + code_challenge_method=S256& + redirect_uri=https://${account.namespace}/mobile& + connection=github +``` + +After the user submits the request, the app receives an `HTTP 302` response with a URL containing the authorization code at the end: `https://${account.namespace}/callback?code=AUTHORIZATION_CODE` + +Using the authorization code, you can obtain the ID Token by making a `POST` call to the [tokens](/api/authentication#authorization-code-pkce-) endpoint. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "code_verifier", + "value": "YOUR_GENERATED_CODE_VERIFIER" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "https://${account.namespace}/mobile" + } + ] + } +} +``` + +If all goes well, you'll receive an `HTTP 200` response with the following payload: + +```json +{ + "access_token":"eyJz93a...k4laUWw", + "refresh_token":"GEbRxBN...edjnXbL", + "id_token":"eyJ0XAi...4faeEoQ", + "token_type":"Bearer", + "expires_in":86400 +} +``` + +You can pull the user's name, profile picture, and email address from the `name`, `picture`, and `email` claims of the returned ID Token. Note that the `sub` claim contains the user's unique ID as returned from GitHub: + +```json +{ + "name": "John Smith", + "picture": "https://avatars.example.com", + "email": "jsmith@...", + "email_verified": true, + "iss": "https://auth0user.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` + +## How to implement + +For most common types of applications, we have SDKs available which handle the PKCE protocol for you. The exact implementation will be different based on the technology being used. Please refer to our [Mobile / Native App Quickstarts](/quickstart/native), select the appropriate Quickstart based on your application, and follow the code samples provided. diff --git a/fr-ca/articles/application-auth/current/server-side-web.md b/fr-ca/articles/application-auth/current/server-side-web.md new file mode 100644 index 0000000000..026aa3dab9 --- /dev/null +++ b/fr-ca/articles/application-auth/current/server-side-web.md @@ -0,0 +1,295 @@ +--- +title: Authentication for Server-side Web Apps +description: Explains how to authenticate users in a Server-side Web application. +toc: true +topics: + - oauth2 + - authentication + - server-side-apps +contentType: + - concept + - how-to +useCase: + - add-login +--- + +# Authentication for Server-side Web Apps + +You can use the Auth0 Authentication API to create server-side web applications that uses OAuth 2.0 and OpenID Connect (OIDC) to authenticate users and get their authorization to access protected resources. + +## Overview + +Auth0 exposes endpoints that you can use to authenticate users and get their authorization. + +You can redirect the user from your web application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to a pre-configured callback URL, returning an authorization code in the query string parameters of the callback URL. This code can then be exchanged for an [ID Token](/tokens/concepts/id-tokens) (which contains information about the identity of the user) and an [Access Token](/tokens/concepts/access-tokens). + +## The Authentication Flow + +The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Server-side Web applications is known as the [Authorization Code flow](https://tools.ietf.org/html/rfc6749#section-1.3.1). + +The Authorization Code flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders). + +After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along a `code` parameter in the query string of the Callback URL. This `code` can then be exchanged for an [ID Token](/tokens/concepts/id-tokens) by making a request to the `/oauth/token` endpoint. + +The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes regarding the user, such as the user's name, email address, profile picture and so on. These attributes are referred to as **Claims** and they can be extracted from the ID Token and used in your application (for example, to display a user's name and profile image). + +::: note +You will also receive an [Access Token](/tokens/concepts/access-tokens) which you can use to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or your own APIs. For more information on calling APIs web apps running on the server, see [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code) +::: + +![Authentication flow for server-side web apps](/media/articles/client-auth/server-side-web/server-side-web-flow.png) + +1. The Application initiates the flow and redirects the user to the Authorization Server. +2. The user authenticates. +3. The Authorization Server redirects to the `redirect_uri` with a `code` in the query string. +4. The Application sends the `code` together with the Client ID, Client Secret and `redirect_uri` to the Authorization Server. +5. The Authorization Server validates this information and returns an ID Token. + +## Register your Application + +The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication. + +Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button. + +The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Regular Web Applications** as the **Application Type** and click on the **Create** button to create the new application. + +![](/media/articles/client-auth/server-side-web/create-client.png) + +Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `${account.callback}`. + +This URL must be part of your application, as your application will need to retrieve the `code` and exchange it for the ID Token. + +![](/media/articles/client-auth/server-side-web/allowed-callback-url.png) + +Next, click on **Show Advanced Settings**. Go to the **OAuth** tab and ensure that you have enabled the **OIDC Conformant** switch: + +![](/media/articles/client-auth/server-side-web/oidc-conformant.png) + +Save the Settings. + +## Call the Authorization URL + +The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. + +This endpoint supports the following query string parameters: + +| Parameter | Description | +|:------------------|:---------| +| response_type | The response type specifies the Grant Type you want to use. For server-side web applications using the Authorization Code Flow this **must be set** to `code` | +| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard | +| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To get an ID Token in the response, you need to specify at least the scope of `openid` in the request. If you want to return the user's full profile information, you can request `openid profile`.

You can read the [scopes documentation](/scopes) for more information. | +| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`| +| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application. | + +::: note + Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}). +::: + +## Exchange the code for an ID Token + +After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along a `code` as a query string parameter of the URL, such as + +```text +${account.callback}?code=tQPUv... +``` + +You application will need to handle the request to this callback URL, extract the `code` query string parameter and call the `/oauth/token` endpoint of the Auth0 Authentication API in order to exchange the `code` for the ID Token: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "https://${account.callback}" + } + ] + } +} +``` + +The response from `/oauth/token` contains `access_token`, `expires_in`, `id_token` and `token_type` values (and also potentially a `refresh_token`), for example: + +```json +{ + "access_token": "subBe48...", + "expires_in": 86400, + "id_token": "eyJ0eXAi...", + "token_type": "Bearer" +} +``` + +The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You will need to decode the ID Token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT. + +You can refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token. + +Once the JWT is decoded, you can extract the information about the user from the payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. + +### The ID Token payload + +An example payload for an ID Token may look something like this: + +```json +{ + "name": "Jerrie Pelser", + "email": "jerrie@j...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +The payload above contains the following claims: + + +| Parameter | Description | +|:------------------|:---------| +| name | The name of the user which is returned from the Identity Provider. | +| email | The email address of the user which is returned from the Identity Provider. | +| picture | The profile picture of the user which is returned from the Identity Provider. | +| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. | +| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | + +The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned. + +::: note +The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token. +::: + +### Keep the user logged in + +Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use a cookie or other session storage to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token. + +You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience. + +## Examples + +### A Basic Authentication Request + +The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections. + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `code` for an ID Token. This is an example of the decoded payload of the ID Token which will be returned: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the Name and Profile Picture + +You can request a user's profile information, for example their name and profile picture, by requesting the `profile` scope in addition to the `openid` scope: + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `code` for an ID Token. The profile attributes of the user, such as the name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: + +```json +{ + "name": "jerrie@...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +### Request a User Log In With GitHub + +You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter: + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile + &connection=github +``` + +::: note +You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info: +- [Identity Providers Supported by Auth0](/identityproviders) +- [Social Login using the Authentication API](/api/authentication#social) +::: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `code` for an ID Token. Since we also requested the `profile` scope, the user's Github profile attributes will also be available. In the example below you will notice the `name`, `nickname` and `picture` attributes are returned with the values from GitHub. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: + +```json +{ + "name": "Jerrie Pelser", + "nickname": "jerriep", + "picture": "https://avatars.githubusercontent.com/u/1006420?v=3", + "iss": "https://auth0pnp.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` diff --git a/fr-ca/articles/application-auth/index.yml b/fr-ca/articles/application-auth/index.yml new file mode 100644 index 0000000000..2132d215a0 --- /dev/null +++ b/fr-ca/articles/application-auth/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: application-auth + current: current + versions: + - legacy + - current + defaultArticles: + legacy: index + current: index diff --git a/fr-ca/articles/application-auth/legacy/client-side-web.md b/fr-ca/articles/application-auth/legacy/client-side-web.md new file mode 100644 index 0000000000..da677b5d3a --- /dev/null +++ b/fr-ca/articles/application-auth/legacy/client-side-web.md @@ -0,0 +1,271 @@ +--- +description: Explains how to authenticate users in a Client-side Web application. +toc: true +topics: + - spa + - authentication + - oauth2 + - implicit +contentType: + - concept + - how-to +useCase: + - add-login +--- +# Authentication for Client-side Web Apps + +::: version-warning +This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +The Auth0 OAuth 2.0 authentication endpoints support Client-side Web Applications. These applications are also referred to as JavaScript or Single-Page Applications. + +## Overview + +Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can redirect the user from your JavaScript application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to the Callback URL, returning the ID Token in the hash fragment of the request. + +## The Authentication Flow + +The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Client-side Web applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2). + +The Implicit Grant flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders). + +After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along an `id_token` parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier). The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on. + +The ID Token can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example. + +![](/media/articles/client-auth/client-side-web/client-side-web-flow.png) + +1. The Application initiates the flow and redirects the user to the Authorization Server +2. The user authenticates +3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment +4. The Application can now extract the token from the hash fragment. + +## Register your Application + +The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication. + +Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button. + +The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Single-Page Web Applications** as the **Application Type** and click on the **Create** button to create the new application. + +![](/media/articles/client-auth/client-side-web/create-client.png) + +Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `https://YOUR_APP/callback`. + +This URL must be part of your application, as your application will need to extract the ID Token from the hash fragment of this URL. Save the Settings. + +![](/media/articles/client-auth/client-side-web/allowed-callback-url.png) + +## Call the Authorization URL + +The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. + +This endpoint supports the following query string parameters: + +| Parameter | Description | +|:------------------|:---------| +| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For client-side web applications using the Implicit Grant Flow this **must be set** to `token` | +| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard | +| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

You can read up more about [scopes](/scopes). | +| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`.| +| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application. | +| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) | +| nonce | A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. | + +::: note + Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}). +::: + +## Handle the callback + +After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the ID Token and the `token_type` in the hash fragment of the URL, such as + +```text +https://YOUR_APP/callback#id_token=eyJ0...&token_type=Bearer +``` + +The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can access the hash fragment using the `window.location.hash` property and then use basic JavaScript string manipulation to access the ID Token. + +As mentioned, the ID Token is a JWT and you will need to decode this token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT. + +Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. + +The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you in decoding the JWT by calling the `parseHash` function, and then access the ID Token values from the `idTokenPayload` property: + +``` + + + + Document + + + + + + + +``` + +### The ID Token Payload + +An example payload for an ID Token may look something like this: + +```json +{ + "name": "Jerrie Pelser", + "email": "jerrie@j...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +The payload above contains the following claims: + +| Parameter | Description | +|:------------------|:---------| +| name | The name of the user which is returned from the Identity Provider. | +| email | The email address of the user which is returned from the Identity Provider. | +| picture | The profile picture of the user which is returned from the Identity Provider. | +| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. | +| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | + +The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned. + +::: note +The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token. +::: + +### Keep the user logged in + +Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use `localStorage` to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token. + +You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience. + +## Examples + +### A Basic Authentication Request + +The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections. + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=${account.callback} +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... + &token_type=Bearer +``` + +And this is an example of the decoded payload of the ID Token which will be returned: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the Name and Profile Picture + +You can request a user's name and profile picture by requesting the `name` and `picture` scopes. + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20name%20picture +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... + &token_type=Bearer +``` + +The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: + +```json +{ + "name": "jerrie@...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +### Request a User Log In With GitHub + +You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes: + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20name%20picture%20email + &connection=github +``` + +::: panel Log in with other social providers +You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info: +- [Identity Providers Supported by Auth0](/identityproviders) +- [Social Login using the Authentication API](/api/authentication#social) +::: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment: + +```text +${account.callback} + #id_token=eyJ0... + &token_type=Bearer +``` + +The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: + +```json +{ + "name": "Jerrie Pelser", + "picture": "https://avatars.githubusercontent.com/u/1006420?v=3", + "email": "jerrie@...", + "email_verified": true, + "iss": "https://auth0pnp.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` diff --git a/fr-ca/articles/application-auth/legacy/index.md b/fr-ca/articles/application-auth/legacy/index.md new file mode 100644 index 0000000000..56a74c0a5b --- /dev/null +++ b/fr-ca/articles/application-auth/legacy/index.md @@ -0,0 +1,23 @@ +--- +classes: topic-page +title: Application Authentication +description: Introduction to the various application authentication flows. +topics: + - authentication + - oauth2 +contentType: index +useCase: + - add-login +--- + +# Application Authentication + +Auth0 uses the OAuth 2.0 protocol for authentication and authorization. We support common OAuth 2.0 scenarios for Mobile Applications, Desktop Applications, Server-side web applications or Client-side Web Applications. + +You can get more details on implementing these flows by following one of the following links: + +<%= include('../../_includes/_topic-links', { links: [ + 'application-auth/legacy/mobile-desktop', + 'application-auth/legacy/server-side-web', + 'application-auth/legacy/client-side-web' +] }) %> diff --git a/fr-ca/articles/application-auth/legacy/mobile-desktop.md b/fr-ca/articles/application-auth/legacy/mobile-desktop.md new file mode 100644 index 0000000000..04b9497aee --- /dev/null +++ b/fr-ca/articles/application-auth/legacy/mobile-desktop.md @@ -0,0 +1,245 @@ +--- +description: Explains how to authenticate users in a mobile or desktop application. +toc: true +topics: + - authentication + - oauth2 + - mobile-apps + - desktop-apps +contentType: + - concept + - how-to +useCase: + - add-login +--- +# Authentication for Mobile & Desktop Apps + +::: version-warning +This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +You can easily authenticate users in your mobile and desktop applications by using either the Lock application libraries, or by calling the Auth0 OAuth 2.0 endpoints yourself. + +## Overview + +Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can call these endpoints through an embedded browser in your application, and then intercept the request to the callback URL to extract the ID Token which contains the user's profile information. + +We also make a set of application libraries available which encapsulates all the logic for you and makes it much easier to implement authentication in all the popular mobile and desktop platforms. Please refer to our [Native Quickstarts](/quickstart/native) to get started with any of these. + +## The Authentication Flow + +The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for mobile applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2). + +The Implicit Grant flow is initiated by redirecting the user in an embedded web browser inside of your application to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders). + +After the user has authenticated, Auth0 will redirect the browser back to the `redirect_uri` (also known as the **Callback URL**), passing along an `id_token` parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier) or the URL. The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on. + +The ID Token can be decoded to extract the claims and you can use these inside of your application, to display a user's name and profile image for example. + +![](/media/articles/client-auth/mobile-desktop/mobile-desktop-flow.png) + +1. The Application initiates the flow and redirects the user to the Authorization Server +2. The user authenticates +3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment +4. The Application can now extract the token from the hash fragment. + +## Register your Application + +The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication. + +Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button. + +The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Native** as the **Application Type** and click on the **Create** button to create the new application. + +![](/media/articles/client-auth/mobile-desktop/create-client.png) + +Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add the URL `https://${account.namespace}/mobile`. Save the Settings. + +![](/media/articles/client-auth/mobile-desktop/allowed-callback-url.png) + +## Call the Authorization URL + +The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. + +This endpoint supports the following query string parameters: + +| Parameter | Description | +|:------------------|:---------| +| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For mobile applications using the Implicit Grant Flow this **must be set** to `token` | +| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard | +| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

You can read up more about [scopes](/scopes). | +| redirect_uri | The URL where the user will be redirected to after they have authenticated. For mobile applications you should specify this as `https://${account.namespace}/mobile`| +| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `google-oauth2` to send the user directly to Google to log in with their Google account.

If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application. | +| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) | + +::: note + Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}). +::: + +## Handle the callback + +After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the `id_token` and the `token_type` in the hash fragment of the URL, such as + +```text +https://${account.namespace}/mobile#id_token=eyJ0...&token_type=Bearer +``` + +The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can extract both of these values from the URL using basic string manipulation techniques in whatever programming language you are using. + +As mentioned, the ID Token is a JWT and you will need to decode this token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT. + +You can also refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token. + +Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. + +### The ID Token Payload + +An example payload for an ID Token may look something like this: + +```json +{ + "name": "Jerrie Pelser", + "email": "jerrie@j...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +The payload above contains the following claims: + +| Parameter | Description | +|:------------------|:---------| +| name | The name of the user which is returned from the Identity Provider. | +| email | The email address of the user which is returned from the Identity Provider. | +| picture | The profile picture of the user which is returned from the Identity Provider. | +| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. | +| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | + +The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned. + +::: panel Debugging a JWT +The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token. +::: + +### Keep the user logged in + +Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can keep a global variable or a singleton object inside your application which will keep track of whether the user has logged in. + +You can also use this object to store information about the user (such as name, profile image, and so on.) and then use those inside of your application to display the user's information or otherwise personalize the user's experience. + +## Examples + +### A Basic Authentication Request + +The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections. + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=https://${account.namespace}/mobile +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment: + +```text +https://${account.namespace}/mobile + #id_token=eyJ0... + &token_type=Bearer +``` + +And this is an example of the decoded payload of the ID Token which will be returned: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the Name and Profile Picture + +You can request a user's name and profile picture by requesting the `name` and `picture` scopes. + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=https://${account.namespace}/mobile + &scope=openid%20name%20picture +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment: + +```text +https://${account.namespace}/mobile + #id_token=eyJ0... + &token_type=Bearer +``` + +The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: + +```json +{ + "name": "jerrie@...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +### Request a User Log In With GitHub + +You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes: + +```text +https://${account.namespace}/authorize + ?response_type=token + &client_id=${account.clientId} + &redirect_uri=https://${account.namespace}/mobile + &scope=openid%20name%20picture%20email + &connection=github +``` + +::: panel Log in with other social providers +You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info: +- [Identity Providers Supported by Auth0](/identityproviders) +- [Social Login using the Authentication API](/api/authentication#social) +::: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment: + +```text +https://${account.namespace}/mobile + #id_token=eyJ0... + &token_type=Bearer +``` + +The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: + +```json +{ + "name": "Jerrie Pelser", + "picture": "https://avatars.githubusercontent.com/u/1006420?v=3", + "email": "jerrie@...", + "email_verified": true, + "iss": "https://auth0pnp.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` diff --git a/fr-ca/articles/application-auth/legacy/server-side-web.md b/fr-ca/articles/application-auth/legacy/server-side-web.md new file mode 100644 index 0000000000..5cb0b0ac58 --- /dev/null +++ b/fr-ca/articles/application-auth/legacy/server-side-web.md @@ -0,0 +1,287 @@ +--- +title: Authentication for Server-side Web Apps +description: Explains how to authenticate users in a Server-side Web application. +toc: true +topics: + - oauth2 + - authentication + - server-side-apps +contentType: + - concept + - how-to +useCase: + - add-login +--- +# Authentication for Server-side Web Apps + +::: version-warning +This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro). +::: + +You can use the Auth0 Authentication API to create server-side web applications that uses OAuth 2.0 authorization to authenticate users. + +## Overview + +Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can redirect the user from your web application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to the `redirect_uri` (also referred to as the Callback URL), returning an `authorization_code` in the query string parameters of the Callback URL. This `authorization_code` can then be exchanged for an ID Token which contains the identity of the user. + +## The Authentication Flow + +The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Server-side Web applications is known as the [Authorization Code flow](https://tools.ietf.org/html/rfc6749#section-1.3.1). + +The Authorization Code flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders). + +After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along an `authorization_code` parameter in the query string of the Callback URL. This code can then be exchanged for an ID Token by making a request to the `/oauth/token` endpoint. + +The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on.. The ID Token can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example. + +![](/media/articles/client-auth/server-side-web/server-side-web-flow.png) + +1. The Application initiates the flow and redirects the user to the Authorization Server. +2. The user authenticates. +3. The Authorization Server redirects to the `redirect_uri` with an `authorization_code` in the query string. +4. The Application sends the `authorization_code` together with the `redirect_uri` and the Client Id/Client Secret to the Authorization Server. +5. The Authorization Server validates this information and returns an ID Token. + +## Register your Application + +The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication. + +Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button. + +The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Regular Web Applications** as the **Application Type** and click on the **Create** button to create the new application. + +![](/media/articles/client-auth/server-side-web/create-client.png) + +Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `${account.callback}`. + +This URL must be part of your application, as your application will need to retrieve the `code` and exchange it for the ID Token. + +![](/media/articles/client-auth/server-side-web/allowed-callback-url.png) + +## Call the Authorization URL + +The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication. + +This endpoint supports the following query string parameters: + +| Parameter | Description | +|:------------------|:---------| +| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For server-side web applications using the Authorization Code Flow this **must be set** to `code` | +| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard | +| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

You can read up more about [scopes](/scopes). | +| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`| +| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application. | +| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) | + +::: note + Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}). +::: + +## Exchange the `access_code` for an ID Token + +After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along an `access_token` in the `code` query string parameter of the URL, such as + +```text +${account.callback}?code=2OKj... +``` + +You application will need to handle the request to this callback URL, extract the `access_code` from the `code` query string parameter and call the `/oauth/token` endpoint of the Auth0 Authentication API in order to exchange the `access_code` for the ID Token: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "authorization_code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "code", + "value": "YOUR_AUTHORIZATION_CODE" + }, + { + "name": "redirect_uri", + "value": "https://${account.callback}" + } + ] + } +} +``` + +The response from `/oauth/token` contains an `access_token`, `id_token` and `token_type` values (and also potentially a `refresh_token`), for example: + +```json +{ + "access_token": "AP16...", + "id_token": "eyJ0...", + "token_type": "Bearer" +} +``` + +The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You will need to decode the ID Token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT. + +You can refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token. + +Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata. + +### The ID Token Payload + +An example payload for an ID Token may look something like this: + +```json +{ + "name": "Jerrie Pelser", + "email": "jerrie@j...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +The payload above contains the following claims: + +| Parameter | Description | +|:------------------|:---------| +| name | The name of the user which is returned from the Identity Provider. | +| email | The email address of the user which is returned from the Identity Provider. | +| picture | The profile picture of the user which is returned from the Identity Provider. | +| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. | +| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | +| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

**This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** | + +The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned. + +::: note +The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token. +::: + +### Keep the user logged in + +Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use a cookie or other session storage to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token. + +You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience. + +## Examples + +### A Basic Authentication Request + +The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections. + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `access_code` for an ID Token. This is an example of the decoded payload of the ID Token which will be returned: + +```json +{ + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt9...", + "exp": 1478112929, + "iat": 1478076929 +} +``` + +### Request the Name and Profile Picture + +You can request a user's name and profile picture by requesting the `name` and `picture` scopes. + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20name%20picture +``` + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `access_code` for an ID Token. The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token: + +```json +{ + "name": "jerrie@...", + "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png", + "iss": "https://auth0pnp.auth0.com/", + "sub": "auth0|581...", + "aud": "xvt...", + "exp": 1478113129, + "iat": 1478077129 +} +``` + +### Request a User Log In With GitHub + +You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes: + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20name%20picture%20email + &connection=github +``` + +::: panel Log in with other social providers +You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info: +- [Identity Providers Supported by Auth0](/identityproviders) +- [Social Login using the Authentication API](/api/authentication#social) +::: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment: + +After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter: + +```text +${account.callback}?code=2OKj... +``` + +You can then exchange the `access_code` for an ID Token. The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub: + +```json +{ + "name": "Jerrie Pelser", + "picture": "https://avatars.githubusercontent.com/u/1006420?v=3", + "email": "jerrie@...", + "email_verified": true, + "iss": "https://auth0pnp.auth0.com/", + "sub": "github|100...", + "aud": "xvt...", + "exp": 1478114742, + "iat": 1478078742 +} +``` diff --git a/fr-ca/articles/applications/application-settings/_adv-settings-mobile.md b/fr-ca/articles/applications/application-settings/_adv-settings-mobile.md new file mode 100644 index 0000000000..fb14954545 --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_adv-settings-mobile.md @@ -0,0 +1,8 @@ + +#### Device Settings + +If you're developing a mobile application, you can provide the necessary iOS/Android parameters here. + +When developing iOS apps, you'll provide your **Team ID** and **App Bundle Identifier**. + +When developing Android apps, you'll provide your **App Package Name** and your **Key Hashes**. diff --git a/fr-ca/articles/applications/application-settings/_adv-settings.md b/fr-ca/articles/applications/application-settings/_adv-settings.md new file mode 100644 index 0000000000..f86aa43c4a --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_adv-settings.md @@ -0,0 +1,25 @@ + + +The **Advanced Settings** section allows you to: + +* Manage or add Application Metadata, Mobile, OAuth, and WS-Federation settings +* Obtain certificates and token endpoint information +* Set the grant type(s) for the Application + +![Advanced Application Settings Page](/media/articles/applications/advanced-settings.png) + +#### Application Metadata + +Application metadata are custom string keys and values (each of which has a character maximum of 255), set on a per application basis. Metadata is exposed in the Application object as client_metadata, and in Rules as context.clientMetadata + +You can create up to 10 sets of metadata. + +#### OAuth + +Set the OAuth-related settings on this tab: + +* By default, all apps/APIs can make a delegation request, but if you want to explicitly grant permissions to selected apps/APIs, you can do so in **Allowed Apps/APIs**. + +* Set the algorithm used (**HS256** or **RS256**) for signing your JSON Web Tokens. + +* Toggle the switch to indicate if your application is OIDC Conformant or not. \ No newline at end of file diff --git a/fr-ca/articles/applications/application-settings/_settings-pt2.md b/fr-ca/articles/applications/application-settings/_settings-pt2.md new file mode 100644 index 0000000000..cbd497d7b3 --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_settings-pt2.md @@ -0,0 +1,17 @@ +::: note +You can provide up to 100 URLs in the **Allowed Callback URLs**, **Allowed Web Origins**, **Allowed Logout URLs**, **Allowed Origins (CORS)** fields. +::: + +- **Allowed Callback URLs**: Set of URLs to which Auth0 is allowed to redirect the users after they authenticate. You can specify multiple valid URLs by comma-separating them (typically to handle different environments like QA or testing). For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Make sure to specify the protocol, `http://` or `https://`, otherwise the callback may fail in some cases. + +- **Allowed Web Origins**: List of URLs from where an authorization request, using [`web_message` as the response mode](/protocols/oauth2#how-response-mode-works), can originate from. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. + +- **Allowed Logout URLs**: After a user logs out from Auth0 you can redirect them with the `returnTo` query parameter. The URL that you use in `returnTo` must be listed here. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Notice that querystrings and hash information are not taken into account when validating these URLs. Read more about this at: [Logout](/logout). + +- **Allowed Origins (CORS)**: Set of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS). This prevents same-origin policy errors when using Auth0 from within a web browser. By default, all your callback URLs will be allowed. This field allows you to enter other origins if you need to. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Notice that paths, querystrings and hash information are not taken into account when validating these URLs (and may, in fact, cause the match to fail). + +- **ID Token Expiration (seconds)**: The amount of time (in seconds) before the Auth0 ID Token expires. The default value is `36000` seconds which is 10 hours. + +- **Use Auth0 instead of the IdP to do Single Sign-on**: If enabled, this setting prevents Auth0 from redirecting authenticated users with valid [sessions](/sessions) to the identity provider (such as Facebook, ADFS, and so on). **Legacy tenants only.** + +![Application Settings Page](/media/articles/applications/settings.png) diff --git a/fr-ca/articles/applications/application-settings/_settings.md b/fr-ca/articles/applications/application-settings/_settings.md new file mode 100644 index 0000000000..7a276d13d1 --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_settings.md @@ -0,0 +1,17 @@ + + +- **Name**: The name of your application. This information is editable and you will see in the portal, emails, logs, and so on. + +- **Domain**: Your Auth0 tenant name. Note that the domain name is chosen when you create a new Auth0 tenant and cannot be changed. If you need a different one you have to register for a new tenant by selecting **+ Create Tenant** in the top right menu. + +- **Client ID**: The unique identifier for your application. This is the ID you will use with when configuring authentication with Auth0. It is generated by the system when you create a new application and it cannot be modified. + +- **Client Secret**: A string used to sign and validate ID Tokens for authentication flows and to gain access to select Auth0 API endpoints. By default, the value is hidden, so check the **Reveal Client Secret** box to see this value. + + ::: warning + While the Client ID is considered public information, the Client Secret **must be kept confidential**. If anyone can access your Client Secret they can issue tokens and access resources they shouldn't. + ::: + +- **Description**: A free-text description of the Application's purpose with a maximum of 140 characters. + +- **Application Logo**: The URL to a logo (recommended size: 150x150 pixels) to be displayed for the application. This will appear in several areas, including the list of applications in the Dashboard, as well as things like customized consent forms. diff --git a/fr-ca/articles/applications/application-settings/_token-endpoint-auth-method.md b/fr-ca/articles/applications/application-settings/_token-endpoint-auth-method.md new file mode 100644 index 0000000000..be1b5f2d98 --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_token-endpoint-auth-method.md @@ -0,0 +1,3 @@ + + +- **Token Endpoint Authentication Method**: Defines the requested authentication method for the token endpoint. Possible values are `None` (public client without a client secret), `Post` (client uses HTTP POST parameters) or `Basic` (client uses HTTP Basic). \ No newline at end of file diff --git a/fr-ca/articles/applications/application-settings/_trust-token-endpoint-ip-header.md b/fr-ca/articles/applications/application-settings/_trust-token-endpoint-ip-header.md new file mode 100644 index 0000000000..9f1da28c81 --- /dev/null +++ b/fr-ca/articles/applications/application-settings/_trust-token-endpoint-ip-header.md @@ -0,0 +1,3 @@ + + +* Toggle the **Trust Token Endpoint IP Header** setting; if this is enabled, the `auth0-forwarded-for` is set as trusted and used as a source of end user IP information for protection against brute-force attacks on the token endpoint. diff --git a/fr-ca/articles/applications/concepts/app-types-confidential-public.md b/fr-ca/articles/applications/concepts/app-types-confidential-public.md new file mode 100644 index 0000000000..8a5e97d787 --- /dev/null +++ b/fr-ca/articles/applications/concepts/app-types-confidential-public.md @@ -0,0 +1,63 @@ +--- +description: Understand the difference between confidential and public application types. +toc: true +topics: + - applications + - application-types +contentType: concept +useCase: + - build-an-app +--- +# Confidential and Public Applications + +According to the [OAuth 2.0 spec](https://tools.ietf.org/html/rfc6749#section-2.1), applications can be classified as either confidential or public. The main difference relates to whether or not the application is able to hold credentials (such as a client ID and secret) securely. + +When you create an application using the Dashboard, Auth0 will ask you what [Auth0 application type](/applications) you want to assign to the new application and use that information to determine whether the application is confidential or public. + +To check whether your application is confidential or public, see [View Application Type: Confidential or Public](/dashboard/guides/applications/view-app-type-confidential-public). + +## Confidential applications + +Confidential applications can hold credentials in a secure way without exposing them to unauthorized parties. They require a trusted backend server to store the secret(s). + +### Grant types + +Because they use a trusted backend server, confidential applications can use grant types that require them to authenticate by specifying their client ID and secret when calling the token endpoint. + +The following are considered to be confidential applications: + +* A web application with a secure backend that uses the [Authorization Code Flow](/flows/concepts/auth-code), [Password grant](/api-auth/grant/password), or [Password grant with Realm support](/api-auth/tutorials/password-grant#realm-support) +* A machine-to-machine (M2M) application that uses the [Client Credentials Flow](/flows/concepts/client-credentials) + +### ID Tokens + +Because confidential applications are capable of holding secrets, you can have ID Tokens issued to them that have been signed in one of two ways: + +* Symmetrically, using their client secret (`HS256`) +* Asymmetrically, using a private key (`RS256`) + +## Public applications + +Public applications **cannot** hold credentials securely. + +### Grant types + +Public applications can only use grant types that do not require the use of their client secret. + +The following are public applications: + +* A native desktop or mobile application that uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) +* A JavaScript-based client-side web application (such as a single-page app) that uses the [Implicit Flow](/flows/concepts/implicit) grant + +### ID Tokens + +Because public applications are unable to hold secrets, [ID Tokens](/tokens/concepts/id-tokens) issued to them must be: + +* Signed asymmetrically using a private key (`RS256`) +* Verified using the public key corresponding to the private key used to sign the token + +## Keep reading + +* [View Application Type](/dashboard/guides/applications/view-app-type-confidential-public) +* [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) +* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping) diff --git a/fr-ca/articles/applications/concepts/app-types-first-third-party.md b/fr-ca/articles/applications/concepts/app-types-first-third-party.md new file mode 100644 index 0000000000..1412c22625 --- /dev/null +++ b/fr-ca/articles/applications/concepts/app-types-first-third-party.md @@ -0,0 +1,43 @@ +--- +description: Understand the difference between confidential and public application types. +topics: + - applications + - application-types +contentType: concept +useCase: + - build-an-app +--- +# First-Party and Third-Party Applications + +Applications can be classified as either first-party or third-party, which refers to the ownership of the application. The main difference relates to who has administrative access to your Auth0 domain. + +## First-party applications + +First-party applications are those controlled by the same organization or person who owns the Auth0 domain. For example, let's say you created both a Contoso API and an application that logs into `contoso.com` and consumes the Contoso API. You would register both the API and application under the same Auth0 domain, and the application would be a first-party application. By default, all applications created via the [Auth0 Dashboard](${manage_url}/#/applications) are first-party applications. + +## Third-party applications + +Third-party applications are controlled by someone who most likely should *not* have administrative access to your Auth0 domain. Third-party applications enable external parties or partners to securely access protected resources behind your API. An example of this is with Facebook, let's say you created an application to get a client ID and secret to integrate with your service. That application is considered third-party because it is not owned by Facebook but a third-party that wants to integrate with Facebook APIs and services. + +::: note +All applications created through [Dynamic Client Registration](/api-auth/dynamic-client-registration) will be third-party. + +Third-party applications cannot be created using the Dashboard, but must be created through the [Auth0 Management API](/api/management/v2#!/Clients/post_clients) by setting `is_first_party` to `false`. +::: + +Third-party applications have the following unique characteristics: + +- **User Consent**: You must require user consent when consuming APIs because anyone can create an application. Requiring the user to provide consent improves security. + +- **ID Tokens**: [ID Tokens](/tokens/concepts/id-tokens) generated for third-party applications hold only minimum user profile information. + +- **Connections**: You can only use tenant-level connections or *domain connections*. For more informations, see [Enable Third-party Applications](/applications/guides/enable-third-party-apps). + +## Keep reading + +* [View Application Ownership](/api/management/guides/applications/view-ownership) +* [Applications](/applications) +* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public) +* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping) +* [User consent and third-party applications](/api-auth/user-consent) + \ No newline at end of file diff --git a/fr-ca/articles/applications/concepts/application-grant-types.md b/fr-ca/articles/applications/concepts/application-grant-types.md new file mode 100644 index 0000000000..76ced1103e --- /dev/null +++ b/fr-ca/articles/applications/concepts/application-grant-types.md @@ -0,0 +1,32 @@ +--- +title: Application Grant Types +description: Learn about the concept of grant types and how they relate to applications. +topics: + - applications + - grant-types +contentType: + - concept +useCase: + - build-an-app +--- +# Application Grant Types + +Application grant types (or _flows_) are methods through which applications can gain [Access Tokens](/tokens/concepts/access-tokens) and by which you grant limited access to your resources to another entity without exposing credentials. The [OAuth 2.0 protocol](/protocols/oauth2) supports several types of grants, which allow different types of access. + +Based on the needs of your application, some grant types are more appropriate than others. Auth0 provides many different authentication and authorization flows and allows you to indicate which grant types are appropriate based on the `grant_types` property of your Auth0-registered Application. + +For example, let's say you are securing a mobile app. In this case, you'd use the [Authorization Code using Proof Key for Code Exchange (PKCE) Grant](/flows/concepts/auth-code-pkce). + +Alternatively, if you were securing a client-side app (such as a single-page app), you'd use the [Implicit Grant](/flows/concepts/implicit). + +::: note +Not sure which grant type is appropriate for your use case? Refer to [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) for help. +::: + +## Keep Reading + +* [Available Grant Types](/applications/reference/grant-types-available) +* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping) +* [Update Grant Types Using the Dashboard](/dashboard/guides/applications/update-grant-types) +* [Update Grant Types Using the Management API](/api/management/guides/applications/update-grant-types) +* [Legacy Grant Types](/applications/concepts/grant-types-legacy) diff --git a/fr-ca/articles/applications/concepts/client-secret.md b/fr-ca/articles/applications/concepts/client-secret.md new file mode 100644 index 0000000000..3c97f7efa3 --- /dev/null +++ b/fr-ca/articles/applications/concepts/client-secret.md @@ -0,0 +1,17 @@ +--- +title: Client Secret +description: Learn about client secrets. +topics: + - applications + - client-secrets +contentType: + - concept +useCase: + - build-an-app +--- + +# Client Secret + +A client secret is a secret known only to your application and the authorization server. It protects your resources by only granting [tokens](/tokens) to authorized requestors. + +Protect your client secrets and never include them in mobile or browser-based apps. If your client secret is ever compromised, you should [rotate to a new one](/dashboard/guides/applications/rotate-client-secret) and update all authorized apps with the new client secret. \ No newline at end of file diff --git a/fr-ca/articles/applications/concepts/grant-types-legacy.md b/fr-ca/articles/applications/concepts/grant-types-legacy.md new file mode 100644 index 0000000000..795ad11152 --- /dev/null +++ b/fr-ca/articles/applications/concepts/grant-types-legacy.md @@ -0,0 +1,36 @@ +--- +title: Legacy Grant Types +description: Learn about legacy grant types and more secure alternatives. +topics: + - applications + - client-secrets +contentType: concept +useCase: + - build-an-app +--- + +# Legacy Grant Types + +Legacy grant types are traditional grant types supported for legacy customers only. If you are a legacy customer, we highly recommend moving to a more secure alternative. + +::: warning +As of 8 June 2017, all Auth0 Applications were given a `grant_types` property that **must** be populated. To avoid changes in functionality for Auth0 customers at that time, we populated the `grant_types` property for all existing Applications with **all** Auth0 legacy, Auth0 extension, and specification-conforming grant types. + +At this time, new Auth0 customers were no longer able to add legacy grant types to their applications. Legacy grant types are only available for previous customers while they migrate to new flows, to avoid breaking changes. If you were a customer prior to 8 June 2017, you can [use the Dashboard](/dashboard/guides/applications/update-grant-types) or [use the Management API](/api/management/guides/applications/update-grant-types) to enable a legacy grant type. +::: + +## Secure Alternatives + +If you're currently using a legacy grant type, refer to the chart below to see which of the secure alternatives you should use instead. + +| Legacy Grant Type | Alternative | +|:-----|:----| +|`http://auth0.com/oauth/legacy/grant-type/ro` | Use the [/oauth/token](/api/authentication#authorization-code) endpoint with a grant type of `password`. See [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password) and [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant) for additional information. | +| `http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer` | This feature is disabled by default. If you would like this feature enabled, please [contact support](https://support.auth0.com/) to discuss your use case and prevent the possibility of introducing security vulnerabilities. | +| `http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token` | Use the `oauth/token` endpoint to obtain Refresh Tokens. See [OIDC-conformant Refresh Tokens](/api-auth/tutorials/adoption/refresh-tokens) for more info. | +| `http://auth0.com/oauth/legacy/grant-type/delegation/id_token` | This feature is disabled by default. If you would like this feature enabled, please [contact support](https://support.auth0.com/) to discuss your use case and prevent the possibility of introducing security vulnerabilities. | +| `http://auth0.com/oauth/legacy/grant-type/access_token` | Use browser-based social authentication. | + +::: note +Those implementing Passwordless Authentication should use [Universal Login](/universal-login) instead of the `oauth/ro` endpoint. +::: diff --git a/fr-ca/articles/applications/guides/enable-third-party-apps.md b/fr-ca/articles/applications/guides/enable-third-party-apps.md new file mode 100644 index 0000000000..bcd3c1712c --- /dev/null +++ b/fr-ca/articles/applications/guides/enable-third-party-apps.md @@ -0,0 +1,91 @@ +--- +title: Enable Third-Party Applications +description: Learn how to enable third-party applications for your tenant. +topics: + - applications + - application-types + - third-party-applications +contentType: + - how-to +useCase: + - build-an-app +--- +# Enable Third-Party Applications + +You can enable third-party applications for your tenant. See [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) for details on the differences between the two types of applications. + +1. [Update your application's ownership to third-party](/api/management/guides/applications/update-ownership) in Auth0. + + By default, applications registered in Auth0 are first-party applications. If you want your application to be a third-party application, you must update its ownership. + +2. [Promote the connections you will use with third-party applications to domain level](/api/management/guides/connections/promote-connection-domain-level) in Auth0. + + Third-party applications can only authenticate users from [connections](/connections) flagged as domain-level connections. Domain-level connections can be enabled for selected first-party applications while also being open to all third-party application users for authentication. + +3. Update your application's login page. If you use [Lock](/libraries/lock/v11) in the [Universal Login Page](/universal-login/classic), you must also: + + - Upgrade to Lock version 11 or later + - Set the `__useTenantInfo: config.isThirdPartyClient` flag when instantiating Lock + - *For [Private Cloud](/private-cloud) users only*: Set the [`configurationBaseUrl` option](https://auth0.com/docs/libraries/lock/v11/configuration#configurationbaseurl-string-) to `https://{config.auth0Domain}/` when instantiating Lock + +## Access Token `current_user_*` scopes + +Neither first- nor third-party applications can use [ID Tokens](/tokens/concepts/id-tokens) to invoke [Management API](/api/management/v2) endpoints. Instead, they should get [Access Tokens](/api/management/v2/tokens) with the following `current_user_*` scopes required by each endpoint: + +| Scope | Endpoint | +| - | - | +| `read:current_user` | [List or search users](/api/management/v2#!/Users/get_users) | +| | [Get a user](/api/management/v2#!/Users/get_users_by_id) | +| | [Get user MFA enrollments](/api/management/v2#!/Users/get_enrollments) | +| `update:current_user_metadata` | [Update a user](/api/management/v2#!/Users/patch_users_by_id) | +| | [Delete a user's multi-factor provider](/api/management/v2#!/Users/delete_multifactor_by_provider) | +| `create:current_user_device_credentials` | [Create a device public key](/api/management/v2#!/Device_Credentials/post_device_credentials) | +| `delete:current_user_device_credentials` | [Delete a device credential](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | +| `update:current_user_identities` | [Link a user account](/api/management/v2#!/Users/post_identities) | +| | [Unlink a user identity](/api/management/v2#!/Users/delete_user_identity_by_user_id) | + +## Sample script + +```html + +... + +``` + +## Keep reading +* [View Application Ownership](/api/management/guides/applications/view-ownership) +* [Applications](/applications) +* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public) +* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping) +* [User consent and third-party applications](/api-auth/user-consent) diff --git a/fr-ca/articles/applications/index.md b/fr-ca/articles/applications/index.md new file mode 100644 index 0000000000..2f3bf9a89a --- /dev/null +++ b/fr-ca/articles/applications/index.md @@ -0,0 +1,52 @@ +--- +description: Understand the basics of creating and using Auth0 Applications. +topics: + - applications +contentType: + - concept +useCase: + - build-an-app +--- +# Applications in Auth0 + +The term *application* or *app* in Auth0 does not imply any particular implementation characteristics. For example, it could be a native app that executes on a mobile device, a single-page app that executes on a browser, or a regular web app that executes on a server. + +Auth0 categorizes apps based on these characteristics: + +* **What type of app is it?**: To add authentication to your app, you must register it in the Auth0 Dashboard and select from one of the following app types: + - [Regular web app](/dashboard/guides/applications/register-app-regular-web): Traditional web apps that perform most of their application logic on the server (such as Express.js or ASP.NET). + - [Single-page app (SPA)](/dashboard/guides/applications/register-app-spa): JavaScript apps that perform most of their user interface logic in a web browser, communicating with a web server primarily using APIs (such as AngularJS + Node.js or React). + - [Native app](/dashboard/guides/applications/register-app-native): Mobile or Desktop apps that run natively in a device (such as iOS or Android). + - [Machine-to-machine (M2M) app](/dashboard/guides/applications/register-app-m2m): Non-interactive apps, such as command-line tools, daemons, IoT devices, or services running on your back-end. Typically, you use this option if you have a service that requires access to an API. + +* **Can the app securely hold credentials?**: According to the [OAuth 2.0 spec](https://tools.ietf.org/html/rfc6749#section-2.1), apps can be classified as either *public* or *confidential*; confidential apps can hold credentials securely, while public apps cannot. See [Confidential and Public Applications](/applications/concepts/app-types-confidential-public) for details. + +* **Who owns the app?**: Whether an app is classified as first- or third-party depends on the app ownership and control. First-party apps are controlled by the same organization or person that owns the Auth0 domain. Third-party apps enable external parties or partners to securely access protected resources behind your API. See [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) for details. + +## Manage app settings + +You register apps on the [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings) page. See [Application Settings](/dashboard/reference/settings-application) for details. + +In addition to setting up apps in the Dashboard, you can also set up apps programmatically as described in the [OpenID Connect (OIDC) Dynamic Client Registration 1.0 ](https://openid.net/specs/openid-connect-registration-1_0.html) specification. See [Dynamic Client Registration](/api-auth/dynamic-client-registration) for details. + +::: panel Multi-Tenancy +You can set up up a more complex configuration that allows users to log in differently for different apps. See [Using Auth0 to Secure Your Multi-Tenant Applications](/design/using-auth0-with-multi-tenant-apps) and [Create Multiple Tenants](/dashboard/guides/tenants/create-multiple-tenants). +::: + +By default, Auth0 enables all connections associated with your tenant when you create a new application. To change this, [update application connections](/dashboard/guides/applications/update-app-connections) in the Application Settings in the Dashboard. + +## Monitor apps + +You can [monitor apps](/monitoring/guides/monitor-applications) and perform end-to-end testing using your own tests. Auth0 stores [log data](/logs) including Dashboard administrator actions, successful and failed user authentications, and password change requests. You can use Auth0 [Extensions](/extensions) to export your log data and use tools like Sumo Logic, Splunk, or Loggly to analyze and store your log data. + +## Remove apps + +You can [remove an application using the Auth0 Dashboard](/dashboard/guides/applications/remove-app) or the [Management API](/api/management/guides/applications/remove-app). + +## Manage client secrets + +You can [rotate an app's Client Secret](/dashboard/guides/applications/rotate-client-secret) using the Auth0 Dashboard or the [Management API](/api/management/guides/applications/rotate-client-secret). + +## Grant types + +Auth0 provides many different authentication and authorization grant types or *flows* and allows you to indicate which grant types are appropriate based on the `grant_types` property of your Auth0-registered app. See [Application Grant Types](/applications/concepts/application-grant-types) for more details. diff --git a/fr-ca/articles/applications/reference/grant-types-auth0-mapping.md b/fr-ca/articles/applications/reference/grant-types-auth0-mapping.md new file mode 100644 index 0000000000..d0808c59d3 --- /dev/null +++ b/fr-ca/articles/applications/reference/grant-types-auth0-mapping.md @@ -0,0 +1,61 @@ +--- +title: Auth0 Grant Types Mapping +description: Learn which grant types are available to which application types with Auth0. +toc: true +topics: + - applications + - application-types + - grant-types +contentType: reference +useCase: + - build-an-app +--- + +# Auth0 Grant Types Mapping + +When registered, Auth0 Applications have access to different grant types based on [application](/applications) type. The biggest deciding factor is whether the application is [confidential or public](/applications/concepts/app-types-confidential-public). + +Additionally, trusted first-party applications have access to additional grant types. + +## Public applications + +When a **Native App** or **Single-Page App** is registered in the Dashboard, it is automatically flagged as a public application, which is indicated by a `token_endpoint_auth_method` flag set to `none`. + +By default, Auth0 creates public applications with the following `grant_types` enabled: + +* `implicit` +* `authorization_code` +* `refresh_token` + +**Native Apps** can also use the `device_code` grant type. + +::: note +Public applications **cannot** use the `client_credentials` grant type. To use this grant type, you must indicate that the application is confidential rather than public. Use the [Management API](/api/management/v2#!/Clients/patch_clients_by_id) to set the **token_endpoint_auth_method** to `client_secret_post` or `client_secret_basic`. +::: + +## Confidential applications + +When a **Regular Web App** or **Machine-to-Machine (M2M) App** is registered in the Dashboard, it is automatically flagged as a confidential application, which is indicated by a `token_endpoint_auth_method` flag set to anything *except* `none`. + +By default, Auth0 creates confidential applications with the following `grant_types` enabled: + +* `implicit` +* `authorization_code` +* `refresh_token` +* `client_credentials` + +## Trusted first-party applications + +Trusted first-party applications have the same `grant_types` enabled as confidential applications, plus the following: + +* `password` +* `http://auth0.com/oauth/grant-type/password-realm` +* `http://auth0.com/oauth/grant-type/mfa-oob` +* `http://auth0.com/oauth/grant-type/mfa-otp` +* `http://auth0.com/oauth/grant-type/mfa-recovery-code` + +::: note +If you are using the [Dashboard](${manage_url}) to enable or disable these grant types, be aware that all the Password and MFA grant types are enabled when you add the `Password` or `MFA` grant type to your Application. You cannot select them individually. +::: + +For more info about first-party and third-party applications, see [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party). diff --git a/fr-ca/articles/applications/reference/grant-types-available.md b/fr-ca/articles/applications/reference/grant-types-available.md new file mode 100644 index 0000000000..f4f2946b74 --- /dev/null +++ b/fr-ca/articles/applications/reference/grant-types-available.md @@ -0,0 +1,55 @@ +--- +title: Available Grant Types +description: Learn which grant types are available with Auth0. +toc: true +topics: + - applications + - grant-types +contentType: reference +useCase: + - build-an-app +--- +# Available Grant Types + +Various grant types are valid when registering Auth0 Applications. These can be divided into the following categories: + +* **[Spec-conforming grants](#spec-conforming-grants)**: Grants defined by and conforming to external specifications (such as OpenID Connect (OIDC)). +* **[Auth0 extension grants](#auth0-extension-grants)**: Auth0-specific grants that conform to the [OAuth extension mechanism](https://tools.ietf.org/html/rfc6749#section-4.5) to support additional clients or to provide a bridge between OAuth and other trust frameworks. +* **[Auth0 legacy grants](#auth0-legacy-grants)**: Traditional grant types supported for legacy customers only. If you are a legacy customer, we highly recommend moving to a more secure alternative. For info on working with legacy grant types and their alternatives, see [Legacy Grant Types](/applications/concepts/grant-types-legacy). + +## Spec-conforming grants + +| `grant_type` | More info | +|:-----|:----| +| `implicit` | [Implicit Grant](/flows/concepts/implicit) | +| `authorization_code` | [Authorization Code Grant](/flows/concepts/auth-code) | +| `client_credentials` | [Client Credentials Grant](/flows/concepts/client-credentials) | +| `password` | [Resource Owner Password Grant](/api-auth/grant/password) | +| `refresh_token` | [Use Refresh Tokens](/tokens/guides/use-refresh-tokens) | +| `urn:ietf:params:oauth:grant-type:device_code` | [Device Authorization Grant](/flows/concepts/device-auth) | + +## Auth0 extension grants + +| `grant_type` | More info | +|:-----|:----| +| `http://auth0.com/oauth/grant-type/password-realm` | [Use an extension grant similar to the Resource Owner Password Grant that includes the ability to indicate a specific realm](/api-auth/grant/password#realm-support) | +| `http://auth0.com/oauth/grant-type/mfa-oob` | [Multi-factor Authentication OOB Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-oob-grant-request) | +| `http://auth0.com/oauth/grant-type/mfa-otp` | [Multi-factor Authentication OTP Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-otp-grant-request) | +| `http://auth0.com/oauth/grant-type/mfa-recovery-code` | [Multi-factor Authentication Recovery Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-recovery-grant-request) | +| `http://auth0.com/oauth/grant-type/passwordless/otp` | [Embedded Passwordless Login Grant Request](/connections/passwordless#implementing-login) | + +## Auth0 legacy grants + +Legacy grants include: + +* `http://auth0.com/oauth/legacy/grant-type/ro` +* `http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer` +* `http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token` +* `http://auth0.com/oauth/legacy/grant-type/delegation/id_token` +* `http://auth0.com/oauth/legacy/grant-type/access_token` + +For info on working with legacy grant types and their alternatives, see [Legacy Grant Types](/applications/concepts/grant-types-legacy). + +## Keep reading + +* To learn which grant types are enabled for different application types, see [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping). diff --git a/fr-ca/articles/applications/reference/wildcard-subdomains.md b/fr-ca/articles/applications/reference/wildcard-subdomains.md new file mode 100644 index 0000000000..74f968b6d1 --- /dev/null +++ b/fr-ca/articles/applications/reference/wildcard-subdomains.md @@ -0,0 +1,35 @@ +--- +title: Wildcards for Subdomains +description: Describes wildcards for subdomains function in application configuration. +toc: true +topics: + - applications +contentType: reference +useCase: + - build-an-app +--- +# Wildcards for Subdomains + +You can use wildcards for subdomain URL registration in your application configuration in the Dashboard with these fields: + +* **Allowed Callback URLs**: Set of URLs to which Auth0 is allowed to redirect users after they authenticate. +* **Allowed Logout URLs**: List of URLs to which you can redirect users after they log out from Auth0. +* **Allowed Origins (CORS)**: Set of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS). + +::: warning +Avoid using wildcards for subdomains in application callbacks and allowed origins as it can make your application vulnerable to attacks. See [Application Settings Best Practices](/best-practices/application-settings) for this and other recommended settings. +::: + +You can use the star symbol (`*`) as a wildcard for subdomains, but it must be used in accordance with the following rules in order to properly function: + +* The protocol of the URL **must** be `http:` or `https:`. `com.example.app://*.example.com` will not work. + +* The wildcard **must** be located in a subdomain within the hostname component. `https://*.com` will not work. + +* The wildcard **must** be located in the subdomain furthest from the root domain. `https://sub.*.example.com` will not work. + +* The URL **must not** contain more than one wildcard. `https://*.*.example.com` will not work. + +* A wildcard **may** be prefixed and/or suffixed with additional valid hostname characters. `https://prefix-*-suffix.example.com` will work. + +* A URL with a valid wildcard **will not** match a URL more than one subdomain level in place of the wildcard. `https://*.example.com` will not work with `https://sub1.sub2.example.com`. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md b/fr-ca/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md new file mode 100644 index 0000000000..7c95f9b91b --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md @@ -0,0 +1,44 @@ +## API Authentication and Authorization + +An API is a way to expose functionality of your application to other applications. An application can make a request by sending a message to an endpoint on an API and receive information as a response. + +An API endpoint can be secured or not. In our case, since the timesheets are sensitive information that affect reviews and payments, it is important to ensure that only authorized users and applications can call the endpoints on our API. When a client application wants to access protected endpoints on an API, it needs to present an Access Token as proof that it has the required permissions for making the call to the endpoint. + +An Access Token is obtained by authenticating the user with an Authorization Server and the user can then, in turn, authorize the application to access the API on their behalf. + +::: panel What is an Access Token? +An Access Token (also referred to as `access_token`) is an opaque string representing an authorization issued to the application. It may denote an identifier used to retrieve the authorization information or may self-contain the authorization information (for example, the user's identity, permissions, and so forth) in a verifiable manner. + +It is quite common for Access Tokens to be implemented as [JSON Web Tokens](/tokens/concepts/jwts). + +For more information on Auth0 Access Tokens refer to [Access Token](/tokens/concepts/access-tokens). +::: + +An API can enforce fine-grained control over who can access the various endpoints exposed by the API. These permissions are expressed as scopes. + +When a user authorizes a client application, the application can also indicate which permissions it requires. The user is then allowed to review and grant these permissions. These permissions are then included in the Access Token as part of the `scope` claim. + +Subsequently, when the client passes along the Access Token when making requests to the API, the API can inspect the `scope` claim to ensure that the required permissions were granted in order to call the particular API endpoint. + +::: panel What are Scopes? +Each Access Token may include a list of the permissions that have been granted to the client. When a client authenticates with Auth0, it will specify the list of scopes (or permissions) it is requesting. If those scopes are authorized, then the Access Token will contain a list of authorized scopes. + +For example, the timesheet API may accept four different levels of authorization: reading timesheets (scope `read:timesheets`), creating timesheets (scope `create:timesheets`), deleting timesheets (scope `delete:timesheets`) and approving timesheets (scope `approve:timesheets`). + +When a client asks the API to create a new timesheet entry, then the Access Token should contain the `create:timesheets` scope. In a similar fashion, in order to delete existing timesheets, the Access Token should contain the `delete:timesheets` scope. + +For more information on scopes refer to [Scopes](/scopes). +::: + +By using the OAuth 2.0 authorization framework, you can give your own applications or third-party applications limited access to your APIs on behalf of the application itself. Using Auth0, you can easily support different flows in your own APIs without worrying about the OAuth 2.0/OpenID Connect (OIDC) specification, or the many other technical aspects of API authorization. + +::: panel OAuth Roles +In any OAuth 2.0 flow we can identify the following roles: + +- __Resource Owner__: the entity that can grant access to a protected resource. Typically this is the end-user. +- __Resource Server__: the server hosting the protected resources. This is the API you want to access. +- __Client__: an application requesting access to a protected resource on behalf of the Resource Owner. +- __Authorization Server__: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0. + +Using [different grants types (or flows)](/api-auth/which-oauth-flow-to-use), these participants will interact to grant to the client apps limited access to the APIs you are building. As a result, the client app will obtain an Access Token that can be used to call the API on behalf of the user. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_api-configure-scopes.md b/fr-ca/articles/architecture-scenarios/_includes/_api-configure-scopes.md new file mode 100644 index 0000000000..148a374c9a --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_api-configure-scopes.md @@ -0,0 +1,7 @@ +### Configure the Permissions + +Once the application has been created you will need to configure the Permissions which applications can request during authorization. + +In the settings for your API, go to the **Permissions** tab. In this section you can add all four of the scopes which were discussed before, namely `read:timesheets`, `create:timesheets`, `delete:timesheets`, `approve:timesheets`. + +![Add Scopes](/media/articles/architecture-scenarios/mobile-api/add-permissions.png) \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/_includes/_api-implement.md b/fr-ca/articles/architecture-scenarios/_includes/_api-implement.md new file mode 100644 index 0000000000..3a217a0af4 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_api-implement.md @@ -0,0 +1,67 @@ +In this section we will see how we can implement an API for our scenario. + +::: note +For simplicity reasons we will keep our implementation solely focused on the authentication and authorization part. As you will see in the samples the input timesheet entry will be hard-coded and the API will not persist the timesheet entry, simply echo back some of the info. +::: + +## Define the API endpoints + +First we need to define the endpoints of our API. + +::: panel What is an API endpoint? +An **API endpoint** is a unique URL that represents an object. In order to interact with this object you need to point your application towards that URL. For example, if you had an API that could return either order or customers, you might configure two endpoints: `/orders` and `/customers`. Your client would interact with these endpoints using different HTTP methods, for example `POST /orders` to create a new order, or `GET /orders` to retrieve the dataset of one or more orders. +::: + +For this implementation we will only define two endpoints; one for retrieving a list of all timesheets for an employee, and another which will allow an employee to create a new timesheet entry. + +An `HTTP GET` request to the `/timesheets` endpoint will allow a user to retrieve their timesheets, and an `HTTP POST` request to the `/timesheets` endpoint will allow a user to add a new timesheet. + +::: note +See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#1-define-the-api-endpoints) +::: + +### Secure the Endpoints + +When an API receives a request with a bearer Access Token as part of the header, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request must be rejected with a `Missing or invalid token` error message to the calling app. + +The validations that the API should perform are: + +- Check that the JWT is well formed +- Check the signature +- Validate the standard claims + +::: note +[JWT.io](https://jwt.io/) provides a list of libraries that can do most of the work for you: parse the JWT, verify the signature and the claims. +::: + +Part of the validation process is to also check the Client permissions (scopes), but we will address this separately in the next paragraph of this document. + +For more information on validating Access Tokens, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). + +::: note +See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#2-secure-the-api-endpoints) +::: + +### Check the Client's Permissions + +By now we have verified that the JWT is valid. The last step is to verify that the client has the permissions required to access the protected resources. + +To do so, the API needs to check the [scopes](/scopes) of the decoded JWT. This claim is part of the payload and it is a space-separated list of strings. + +::: note +See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#3-check-the-client-permissions) +::: + +### Determine user identity + +For both endpoints (retrieving the list of timesheets, and adding a new timesheet) we will need to determine the identity of the user. + +For retrieving the list of timesheets this is to ensure that we only return the timesheets belonging to the user making the request, and for adding a new timesheet this is to ensure that the timesheet is associated with the user making the request. + +One of the standard JWT claims is the `sub` claim which identifies the principal that is the subject to the claim. In the case of the Implicit Grant flow this claim will contain the user's identity, which will be the unique identifier for the Auth0 user. You can use this to associate any information in external systems with a particular user. + +You can also use a custom claim to add another attribute of the user - such as their email address - to the Access Token and use that to uniquely identify the user. + +::: note +See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#4-determine-the-user-identity) +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_api-overview-of-solution.md b/fr-ca/articles/architecture-scenarios/_includes/_api-overview-of-solution.md new file mode 100644 index 0000000000..0ba99615fc --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_api-overview-of-solution.md @@ -0,0 +1 @@ +In order to ensure that only authorized users and applications are allowed access to the Timesheets API, ExampleCo has decided to make use of the [OAuth 2.0 authorization framework](https://tools.ietf.org/html/rfc6749). The framework provides the flexibility the company wants since the different grants can allow them to easily authorize the various types of applications which need to communicate with the Timesheets API. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_api-signing-algorithms.md b/fr-ca/articles/architecture-scenarios/_includes/_api-signing-algorithms.md new file mode 100644 index 0000000000..26c06a5eaf --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_api-signing-algorithms.md @@ -0,0 +1,19 @@ +#### Signing Algorithms + +When you create an API you have to select the algorithm your tokens will be signed with. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way. + +::: note +The signature is part of a JWT. If you are not familiar with the JWT structure please refer to: [JSON Web Token Structure](/tokens/references/jwt-structure). +::: + +To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. That algorithm, which is part of the JWT header, is the one you select for your API: `HS256` or `RS256`. + +- __RS256__ is an [asymmetric algorithm](https://en.wikipedia.org/wiki/Public-key_cryptography) which means that there are two keys: one public and one private (secret). Auth0 has the secret key, which is used to generate the signature, and the consumer of the JWT has the public key, which is used to validate the signature. +- __HS256__ is a [symmetric algorithm](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) which means that there is only one secret key, shared between the two parties. The same key is used both to generate the signature and to validate it. Special care should be taken in order for the key to remain confidential. + +The most secure practice, and our recommendation, is to use __RS256__. Some of the reasons are: + +- With RS256 you are sure that only the holder of the private key (Auth0) can sign tokens, while anyone can check if the token is valid using the public key. +- Under HS256, If the private key is compromised you would have to re-deploy the API with the new secret. With RS256 you can request a token that is valid for multiple audiences. +- With RS256 you can implement key rotation without having to re-deploy the API with the new secret. + diff --git a/fr-ca/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md new file mode 100644 index 0000000000..0f2d1ea2a4 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md @@ -0,0 +1,16 @@ +When you setup your Auth0 tenant, the URL for accessing that tenant will be of the form `https://${account.tenant}.auth0.com`. Providing a [Custom Domain](/custom-domains) (also known as a vanity URL), for your Auth0 tenant is not only an important factor for supporting your Branding requirements, but more importantly will also provide you with security benefits too: + +* Some browsers will, by default, make it [difficult to communicate in an iFrame if you don't have a shared domain](/api-auth/token-renewal-in-safari). +* A vanity URL makes phishing more difficult as the phisher must also create a vanity URL to mimic yours. For example, with a custom domain you can use your own certificate to get an "Extended Validation", making phishing even harder. + +::: note +You are allowed only one custom domain per Auth0 Tenant. This is because a tenant in Auth0 is intended to represent a “domain” of users. If you need more than one vanity URL, then you likely have more than one domain of users and should be using multiple tenants. +::: + +Your custom domain name should also give the user confidence that this is the appropriate place to enter their credentials, and we recommend that you create your custom domain in all environments early on to ensure that you are testing consistently between environments. **It's extremely important to train your users to to look for suspicious URLs when entering their credentials!** + +::: panel Best Practice +Create a custom domain (a.k.a. `CNAME`) for your Auth0 tenant, and also create one in development too so you can ensure you have managed the `CNAME` correctly. For example, you could create a `CNAME` which maps `login.mycompany.com` to `mycompany-prod.auth0.com`. +::: + +In almost all cases, customers have been most successful when adopting a strategy of a centralised domain for authentication across multiple product or service brands. This strategy provides users with a consistent UX, and also mitigates the complexity of deploying and maintaining multiple Auth0 tenants in a production environment. If you are considering having multiple domains for different brands, please refer to the [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) guidance before you begin implementing. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_architecture/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_introduction.md new file mode 100644 index 0000000000..ab22539da6 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_introduction.md @@ -0,0 +1,37 @@ +Understanding your application is key to understanding how Auth0 can be leveraged to meet your needs. From experience, our most successful customers start with a visualization of their proposed - or in many cases existing - architecture and use this as a basis for reference as they progress. Understanding where your application fits within your organization is also important; Auth0 [Accounts and Tenants](/getting-started/the-basics#account-and-tenants) form the basis for the grouping and structuring of Auth0 assets, and it may be that you’ll need to leverage an existing Auth0 deployment in order to integrate with [Single Sign-on (SSO)](/sso/current/introduction), centralized user [Profile Management](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt), consolidated billing, or the like. + +::: panel Best Practice +If you do have multiple applications, and you need to leverage SSO, then we recommend you check out our [How to Implement Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) training guidance before continuing. +::: + +The value of investing time on the landscape of the architecture up-front is something that we have found pays dividends in the long run, and there are a number of things you will want to consider when looking at functionality and workflow: + +* What should the URL look like when Auth0 needs to present a web page to a user? +* How can Auth0 be structured to support your SDLC (Software Development Lifecycle)? +* How can you ensure that your Auth0 tenants are appropriately associated with your contract? +* What do you need to consider if there are other projects in your organization integrating with Auth0? Particularly projects that target their own, or a different domain of users (for example, applications that only employees will use)? +<% if (platform === "b2b") { %> +* How can you align the structure and domain of your customers’ organization with your Auth0 deployment? +<% } %> + +Organizations often service more than one domain of user - customers, employees, and affiliates being the most frequently encountered, with typically little to no cross-over: employees, say, don’t use the same applications as customers and vice-versa. In some cases there can also be a need to partition further within a domain - separate groups of customers, say, who use different and unconnected products. Auth0 provides a way to segregate your users and the associated collateral, and [tenant provision](#tenant-provision) covers this in more detail. If you need to provision an independent tenant then you’ll also want to [associate this with your existing Auth0 account](#tenant-association), so that you can take full advantage of the benefits provided at your organization’s contracted subscription level. + +::: panel Best Practice +It’s not uncommon for companies to have identity requirements that address multiple user communities: customers, partners, employees, etc. So be sure to consider other projects or future requirements when designing your architecture. +::: + +In addition, you’ll undoubtedly have an established set of processes and procedures as part of your Software Development Lifecycle (SDLC). So you’ll want to check out our [SDLC support](#sdlc-support) guidance regarding Auth0 Tenant provision in support of that too. + +For customer-facing applications, we typically see [OpenID Connect (OIDC)](/protocols/oidc) as being the most frequently used protocol. OIDC makes use of web based workflows with browser URLs that are presented to the user. Out-of-the-box, client facing URLs as part of Auth0 OIDC support are Auth0 branded, however we recommend using the Auth0 [custom domain](#custom-domains) capability to provide for consistent corporate identity and to also address potential user confidence concerns before they arise. + +::: panel Best Practice +Other groups within your organization may also be working with Auth0; it’s not uncommon for our customers to have disparate departments that serve different user communities. Identifying these will potentially influence your design choices, and doing so early could mitigate decisions that might prove costly later on. +::: + +<% if (platform === "b2b") { %> +If your customers' organizations support the use of multiple IdPs, then we recommend that you can create separate Auth0 tenants for that organization; see [Tenant provision for complex organizations](#tenant-provision-for-complex-organizations) for further details. This allows you to keep the rest of your setup much simpler by maintaining a one-to-one connection relationship between your organization and all your customer organizations within your main tenant. +<% } %> + +::: panel Get Started with Auth0 Video +Watch this short video [Architecture: Your Tenant](/videos/get-started/01-architecture-your-tenant) to learn what an Auth0 tenant is and how to configure it in the Auth0 Dashboard. Understand why you may want more than one tenant if you have different user communities, and also how you can use more than one tenant to support your Software Development Life Cycle (SDLC). Understand the importance of tenant naming and custom domain usage best practices. Also learn how to set up additional tenant administrators and how to associate tenants with your Auth0 account. +::: \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md new file mode 100644 index 0000000000..bddb0fea0d --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md @@ -0,0 +1,17 @@ +Every company has some form of Software Development Life Cycle (SDLC), and throughout the development process you will want to align with that strategy. For instance, you need to be able to test your integration with Auth0 in a similar fashion as you test the applications themselves. It is therefore important to [structure Auth0 tenants to support your SDLC](/dev-lifecycle/setting-up-env), and there is a consistent pattern which our customers typically follow when it comes to the best practices associated with tenant layout for doing so: + +| Environment | Sample Tenant Name | Description | +| - | - | - | +| Development | **company-dev** | A shared environment where most of your development work occurs | +| QA/Testing | **company-qa** or **company-uat** | An environment for formal testing of the changes you've made | +| Production | **company-prod** | The production tenant | + +In some cases you may also want to create one or more sandboxes (e.g., **company-sandbox1**, **company-sandbox2**) so that you can test changes without compromising your development environment. This might be where you test deployment scripts and the like. + +::: panel Best Practice +You can also take advantage of our [Implementation Checklists](/architecture-scenarios/checklists) that you can download and customize to meet your implementation project needs. +::: + +::: warning +Though Auth0 allows you to create as many free tenants as you'd like, you may be limited for the number of tenants where all paid features are enabled. If elegible, you can be provided with up to **three** tenants where all features are shared. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md new file mode 100644 index 0000000000..dc2739a4cf --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md @@ -0,0 +1 @@ +To ensure that your [tenants are all associated with your Auth0 contractual agreement](/dev-lifecycle/child-tenants) and have the same features, ensure all your tenants are associated with your company account. If you have individual developers that want to create their own sandboxes for testing, make sure they get associated with your account so they have the same permissions too. To do this you should contact your Auth0 representative or the Auth0 Support Center at ${env.DOMAIN_URL_SUPPORT}. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md new file mode 100644 index 0000000000..f502ca08a7 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md @@ -0,0 +1,7 @@ +Everything starts with an Auth0 tenant. This is where you will be configuring your use of Auth0, and the where Auth0 assets - such as [Applications](/applications), [Connections](/connections) and [user profiles](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt) are defined, managed and stored. Access to an Auth0 tenant is performed via the Auth0 [Dashboard](/dashboard), and via the Dashboard you can also create additional, associated tenants; you’re allowed to create more than one Auth0 tenant so that you can structure your tenants in a way that will isolate different domains of users and also support your [Software Development Life Cycle](#sdlc-support) (SDLC). + +::: warning +Tenant names cannot be changed, nor reused once deleted. So, make sure you're happy with your name(s) before you create your Auth0 tenants. +::: + +Determining the level of isolation you require when it comes to your user domains is an important step, and together with your branding requirements will subsequently help you determine the number of Auth0 tenants that will be required in your production environment. As we recommend you create a full suite of [SDLC supporting tenants](#sdlc-support) for every Auth0 tenant you will run in a production environment, the number of Auth0 tenants you will need to manage can quickly grow. Therefore you should consider carefully before creating multiple Auth0 tenants for production, and should consult our guidance on [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) before making your final decision. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_application-integration.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_application-integration.md new file mode 100644 index 0000000000..8580bb8809 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_application-integration.md @@ -0,0 +1,60 @@ +Once you've figured out how you want to authenticate your users, the next step is to determine how you will initiate that authentication. Each application will typically have its own starting point. + +::: warning +Native mobile applications (and desktop applications) should use the system browser for authentication, or they open themselves up to additional security risks. See [Native vs. Browser Login on Mobile](/design/browser-based-vs-native-experience-on-mobile) for more information. +::: + +As discussed, we've found that most of our customers use [OpenID Connect (OIDC)](/protocols/oidc) as the industry-standard protocol when it comes to their customer-facing applications. Figuring out which [OIDC flow](/api-auth/intro) to use is your first task, and you will want to start by reviewing the our [grant mapping](/applications/reference/grant-types-auth0-mapping) guidance in the first instance. + +If you want to allow anonymous users access to any part of our application then you need to determine if you will be redirecting right away or prompting your users to redirect only when required (or perhaps some combination of both; see [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login) for further discussion). If users can [deep link](#deep-linking-to-protected-endpoints) to a protected version (or area) of your site then you will need to determine the links to your application that will result in an automatic redirect to Auth0. + +### Anonymous access + +It is important to consider the user experience when someone first comes to your application. If your application supports anonymous user access (quite common for eCommerce applications) there are different scenarios to consider: + +* Are they returning to the application after having already logged in, or +* If this is the first time they are accessing the application: + * Have they already accessed a different application that uses the same Auth0 tenant, + * Have they ever (or perhaps not in a long time) authenticated on this device or browser. + +When an anonymous user accesses your application, it can often be desirable for the application to discover if the user has already logged into a different application in the same family, or to remember this user even if the application is a [SPA](/quickstart/spa) with no state. For example, if you can determine that the user is already logged in, you might decide to have the UI header in the application skip displaying a login button and instead have an account or profile menu for the user. To accomplish this you will want to utilize "[silent authentication](/api-auth/tutorials/silent-authentication)". Silent authentication will allow you to check to see if the user is logged in without prompting them to log in if they are not. Then the application can present a login button if necessary. If the user is logged in already, however, then you will receive tokens and will not have to present the user with a login button again. + +::: warning +Checking for a login session by redirecting to Auth0 can be really helpful for your application, but if this will result in a lot of requests it is important to employ some sort of throttling mechanism to avoid latency and/or rate limiting. <%= include('../../_includes/_rate-limit-policy.md') %> +::: + +### Deep linking to protected endpoints + +There are a variety of reasons why someone might link directly to a particular page within your application that is only accessible by authenticated users. If this is possible for your application you should automatically redirect your user to Auth0 if they are not authenticated. Once they authenticate and the authorization server returns them to your application, you can [redirect them](/users/guides/redirect-users-after-login) to where they intended to go in the first place. + +::: panel Best Practice +Most modern authentication frameworks support middleware for redirecting to an authorization server such as Auth0. Ensure yours: + +* Is configurable +* Can check expirations +* Supports Refresh Tokens (for confidential clients) +::: + +### Authenticating the user + +Authentication is the process of determining user identity. The result of authentication in an OIDC context is an ID Token. This token contains information about the user and should only be able to be obtained if the user authenticates using one or more factors as defined by the authorization server (the most common form being [user ID and password](#username-and-password-authentication)). There are a few things you may also need to consider in addition to obtaining an ID Token: + +* Do we also need an [Access Token](/tokens/concepts/access-tokens) in order to call a shared API? +* Is your application a single-page application and only requires an [ID Token](/tokens/concepts/id-tokens)? See [Implicit Grant](/api-auth/tutorials/implicit-grant) for more information. +* Is your application a native application (mobile or desktop) and/or do you need a [Refresh Token](/tokens/concepts/refresh-tokens)? See [Authorization Code Grant with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) for more information. + +::: warning +Before you go live, you should ensure that **only** the grants that you are using for each application are enabled in your [configuration for your Application](/dashboard/guides/applications/update-grant-types). +::: + +### Implicit grant + +If all your application needs is the ID Token and the application is browser-based, then you can always use the [implicit grant](/api-auth/tutorials/implicit-grant) to get your ID Token. This is a simple authentication flow and should be supported by your SDK (depending on the language you are developing in). + +::: warning +If you need a [Refresh Token](/tokens/concepts/refresh-tokens) so that you can obtain a new Access Token or ID Token without having to re-authenticate the user, then you must use the [authorization code grant](/api-auth/tutorials/authorization-code-grant). +::: + +### Authorization code grant (with or without PKCE) + +If your SDK only supports the Authorization Code grant, or you need an Access Token or Refresh Token, then Authorization Code grant (with or without [PKCE](/flows/concepts/auth-code-pkce)) can also be used to retrieve an ID Token. The Authorization Code grant includes an additional API call to exchange the code for a token which can result in additional unnecessary latency if all you need is the ID Token. In many cases the [hybrid flow](/api-auth/tutorials/hybrid-flow) is implemented to provide optimum access to the ID Token while still leveraging Authorization Code grant workflow for the secure and safe retrieval of Access and Refresh Tokens. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md new file mode 100644 index 0000000000..42aeb1a83b --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md @@ -0,0 +1,5 @@ +The reason that authentication systems are important is to prevent bad actors from accessing applications and user data that they should not. We want to place as many barriers as possible between those bad actors and access to our systems. One of the easiest ways to do this is to ensure that your [attack protection](/attack-protection) with Auth0 is configured correctly, so take a moment to read the guidance on this subject and ensure that it's working correctly for you. + +::: panel Best Practice +Attack protection is handled behind the scenes by Auth0 and provides a great security feature for your product. If you're going to utilize it, ensure that you have set up your [Email Provider](/architecture-scenarios/implementation/${platform}/${platform}-operations#email-provider-setup) and configured your [Email Templates](/architecture-scenarios/implementation/${platform}/${platform}-branding#email-template-customization) before turning on email delivery to your users. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_introduction.md new file mode 100644 index 0000000000..1921e46883 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_introduction.md @@ -0,0 +1,46 @@ +In order to provide services to your users, you must be able to identify who those users are. This process is called User Authentication. There are a number of ways to perform authentication of a user - via social media accounts, username and password, passwordless - and it's often recommended that you go beyond a first factor for authenticating the user by enabling multi-factor authentication (MFA). + +::: panel Best Practice +It's important to consider both security and user experience when designing how you will authenticate your users. Providing for multiple primary factors, and/or enforcing more than one factor during authentication, are ways that you can provide both. +::: + +There are a number of things you will want to consider when looking at functionality and workflow: + +* Where will users enter their credentials? +* How will you keep user credentials safe? +* How will you maintain your authentication system? +* How can you provide password authentication for your users? +* How can you prevent hackers from trying to log in as your users? +* How will you implement authentication in different kinds of applications? +* How can you make login easy for your users when they come from different language backgrounds? +* How will you provide a good user experience as you migrate away from any legacy authentication system? +* What should you consider when integrating applications with Auth0? +<% if (platform === "b2c") { %> +* Can users log in using their existing social (e.g., Facebook or Google) accounts? +<% } %> +* Do you need to provide multi-factor authentication? +* What do you do if you have a service that doesn't have a way for the user to log in ahead of time? +* Can you pass the same user access token from one API to another? +<% if (platform === "b2b") { %> +* What do you do if you need to isolate users by organization? +* How will you handle identifying which organization users belong to? +* What’s the benefit of providing enterprise connections for your organizations? +<% } %> + +Auth0 [Universal Login](#universal-login) provides users with a safe and secure experience - no matter whether you choose to provide for user ID/password credentials sign in, or allow the so-called Bring Your Own Identity scenarios provided via [Social Login](https://auth0.com/learn/social-login/). There are also brand recognition benefits to centralizing the login experience with Universal Login, even if you feel you will also have product-specific [branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) requirements. The Auth0 UI widgets typically used with Universal Login also provide out-of-the-box support with regards to [internationalization](/libraries/lock/v11/i18n) for users with different language requirements, and out-of-the-box support for Auth0 features such as [MFA](#multi-factor-authentication-mfa-) and [attack protection](#attack-protection) allow you to put barriers in place in order to prevent hackers attempting to access users' accounts. + +Allowing users to sign in via user ID/password credentials means that you're not reliant on the status of third-party identity providers for your users to access your system. You also have the means require the credentials used to align with your corporate policies. Auth0 assists with this by providing you with multiple options in support of user ID/password logins, and the [guidance provided](#username-and-password-authentication) will help you understand you can leverage these options. Adding [social](#social-authentication) support at some stage, as an additional primary authentication factor, gives you added flexibility and can help you better understand your users without the need to question them further by leveraging the information already stored by the various social login [providers](/connections/identity-providers-social). + +If you have an existing legacy identity store, you’ll also want to see [User Migration](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#user-migration). This section discusses the advantages of migrating to Auth0’s managed identity storage in terms of safety and security. + +For customer facing applications, OpenID Connect ([OIDC](/protocols/oidc)) is the most frequently used industry standard protocol, and OIDC has first-class citizen support in Auth0. Auth0 provides support for various different approaches for integrating various different applications, so you'll want to see the section on [application integration](#application-integration) for the information you'll need to make an informed choice. + +When calling one API from another API, or from any situation where there is no authenticated user context - such as one or more cron jobs, report generators, or continuous integration/delivery systems - you will need a way to authorize the _application_ instead of a _user_. This is a one step process where the application is authenticated (using a client ID and secret) and then authorized in one call. You can learn more about this in our authorization workstream under [machine-to-machine (m2m) authorization](/architecture-scenarios/implementation/${platform}/${platform}-authorization#machine-to-machine-m2m-authorization). + +<% if (platform === "b2b") { %> +Often companies need to segregate their users by organization and sometimes users can have access to more than one organization. Knowing which of these scenarios is relevant to your company will help define how to determine in which connection a user exists: whether you need to do it, when you need to do it, and how to accomplish it. See [Home Realm Discovery](#home-realm-discovery) to determine if this is something relevant to your company. +<% } %> + +::: panel Get Started with Auth0 Videos +Watch these two short videos [Authenticate: How It Works](/videos/get-started/04_01-authenticate-how-it-works) and [Authenticate: SPA Example](/videos/get-started/04_01-authenticate-spa-example) to learn about the differences between authentication, authorization, and access control. Understand when and why you might use each type of authentication method: first factors, second factors, and multi-factor. Learn about the OpenID Connect (OIDC) authentication protocol. See an example using the Auth0 Quickstart for a single-page application (SPA) implementation. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_mfa.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_mfa.md new file mode 100644 index 0000000000..ec67e73549 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_mfa.md @@ -0,0 +1,16 @@ +In an era where misuse of user credentials is at an all-time high, protecting _your_ systems when it’s so common for hackers to steal users identity information in general is a challenge. One of the most effective ways though is to provide users with the ability to configure a second factor for protecting their account. More commonly referred to as [Multi-Factor Authentication](/mfa). This will ensure that only a valid user can access their account, even if they use a username and password that may have been compromised from a different application. + +::: panel Best Practice +It's quite common for customer facing applications to provide users with an _option_ for adding a second factor rather than _forcing_ them to use a second factor. For more information regarding this, see [providing your users with an option to add MFA](https://auth0.com/learn/multifactor-authentication-customers/). +::: + +Auth0 supports a number of different options when it comes to enabling MFA for protecting user account access, and there are several practices to ensure that you will truly be providing a flexible second factor barrier to access: + +* Auth0 [Guardian](https://auth0.com/multifactor-authentication): a service that provides both _Push_ notification generation and an application for allowing or denying requests. _Push_ sends notification to a user’s pre-registered device - typically a mobile or tablet - from which a user can immediately allow or deny account access via the simple press of a button. +* Time-based One-Time Password (TOTP): allows you to register a device - such as Google Authenticator - that will generate a one-time password which changes over time and which can be entered as the second factor to validate a user’s account. +* SMS: for sending a one-time code over SMS which the user is then prompted to enter before they can finish authenticating. +* Voice: for delivering a one-time code through a phone call which the user is then prompted to enter before they can finish authenticating. +* Duo: allows you to use your Duo account for multi-factor authentication. +* Email: allows you to use your email account for multi-factor authentication. + +Whilst MFA workflow using technologies such as Guardian or Google Authenticator is typically provided via a separate application that runs on a mobile or tablet device, if you don’t want your customers to have to download a separate application Auth0 also provides you with an SDK that you can use to build second factor workflow right in your existing mobile device application(s). diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md new file mode 100644 index 0000000000..262ba3477c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md @@ -0,0 +1,13 @@ +The “bring your own identity” scenario offered by Facebook, Google, etc., is a valuable way of simplifying the user authentication experience without compromising security, and using [Universal Login](#universal-login) makes it easy to start adding support for [Social Connections](/connections/identity-providers-social) with minimal disruption. + +::: warning +Auth0 provides a simple way to test social connections using [pre-configured developer keys](/connections/social/devkeys). However, these have [limitations](/connections/social/devkeys#limitations-of-developer-keys), and before going into production, you’ll need to set up your own application-specific keys by following the [instructions](/connections/identity-providers-social) for your chosen social provider(s). +::: + +With [social](https://auth0.com/learn/social-login/) support, user identities and credentials are managed by the social provider, as are certain identity claims—which Auth0 will use to populate the user [profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt). Auth0 can also provide access to Social Identity Providers' (Social IdPs') [Access Tokens](/tokens/overview-idp-access-tokens), so that your application can also call 3rd-party Social IdP APIs on behalf of the user. + +::: panel Best Practice +Social is a great feature to provide, but when you offer more than one way to sign in, you need to consider the possibility that your customers will actually use more than one way to sign in. By default, every user identity in Auth0 has its own user profile, so you’ll probably want to consider Auth0's capability to [link user accounts](/users/concepts/overview-user-account-linking) to provide an effective way of associating one user profile with multiple identities. +::: + +Auth0 [Custom Social Connections](/connections/social/oauth2) extend social authentication even further by allowing you to connect with any OAuth2 identity provider not supported out-of-box. For example, support for the government-issued-identity provider [SwissID](https://www.swissid.ch/) can be configured in Auth0 by using a Custom Social Connection. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md new file mode 100644 index 0000000000..58df288183 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md @@ -0,0 +1,10 @@ +In a large scale re-structure it's not always possible—or practical—to update all your applications at once. In fact, our recommended best practice is to plan for an iterative-style approach when it comes to integrating with Auth0. If your applications already participate in Single Sign-on (SSO), and your legacy identity system supports protocols such as OIDC or SAML, then you have a couple of options available if you want to continue to provide SSO as you integrate with Auth0: + +* Update your existing identity provider in your legacy SSO system to redirect to Auth0 for login (e.g., using [SAML](/protocols/saml/saml-configuration/auth0-as-identity-provider)), or +* Have Auth0 redirect to your legacy SSO system to login. This requires configuring your legacy system as an IdP in Auth0 (i.e., either using [SAML](/protocols/saml/saml-configuration/auth0-as-service-provider) or [OIDC](/connections/social/oauth2)). + +::: panel Best Practice +Supporting an SSO experience with your legacy system can add complexity, but may be worth it to generate a more seamless user experience as you integrate with Auth0. If you intend to go down this path, planning for it early can help ensure that it is possible to achieve. If you don't already have SSO at a centralized service, then the complexity to add it will unlikely be worth the benefits. +::: + +This is a complex topic that will likely need some additional investigation depending on your current legacy architecture, and we recommend you only look into this if you currently have SSO support in your legacy system. Note: if you are currently redirecting from your applications to a centralized system to authenticate your users and that system only asks for credentials if you don’t already have a session with the centralized system, then you have a legacy SSO implementation. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_universal-login.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_universal-login.md new file mode 100644 index 0000000000..57dc6a92d7 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_universal-login.md @@ -0,0 +1,11 @@ +Do you have, or will you have, more than one application in your system? If the answer to this question is yes, then you will want a centralized sign in experience. To achieve a seamless Single Sign-on (SSO) experience between multiple applications, it is critical to have a centralized location to redirect your users for authentication. This allows you a way to provide your users with a consistent experience if you add social authentication in the future, add third party applications to your system, or add multi-factor authentication as an option (or requirement) for your users - and also allow you to take advantage of new features for improving your users’ experience with little, if any, added development effort. + +::: panel Best Practice +If you have more than one application, the best practice is to redirect to a [centralized location](/universal-login) to authenticate the user. With Auth0, this means taking advantage of [Universal Login](/universal-login), which provides many security and user experience benefits out-of-the-box, including [SSO](/sso/current). +::: + +Auth0 Universal Login makes authenticating users a short, easy process which can be accomplished in three easy steps (all of our Quickstarts demonstrate this and our SDKs hide the complexity for you too): + +1. Determine how and when you want to [redirect from your application](#application-integration). +2. Set up the appropriate [branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) and/or customized HTML in your Auth0 configuration. +3. Set up your application to [receive and handle the response](#application-integration) from the Authorization Server. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md new file mode 100644 index 0000000000..6668a0c76d --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md @@ -0,0 +1,9 @@ +Nearly every B2C application provides the ability for their customers to create a new set of credentials. This is a common form of authentication that all users are familiar with. + +Username password authentication comes in multiple flavors at Auth0. If your application is a green-field application with no existing user base, then a simple Auth0 out-of-the-box [Database Connection](/connections/database) will give you everything you need to start authenticating your users. However, if you have a legacy user store (such as your own database of users or an existing LDAP system) you have a couple of different options for migrating your users as discussed in our guidance on [User migration](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#user-migration). + +However you end up provisioning the users for your database connection, the authentication of those users is quite similar. It requires you to present users with a form to enter their username and password. As mentioned in the guidance concerning [Universal Login](#universal-login), the simplest and safest way to authenticate users with a username and password is to redirect them to a centralized login page and collect their username and password there. This allows Auth0 to determine whether they have already authenticated and skip the login form entirely when it's not needed. + +::: panel Best Practice +Collecting credentials only at the centralized login page will reduce the surface area for potential leak of user secrets. It will also reduce the need to collect credentials unnecessarily. See [Universal Login](#universal-login) for more information. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authorization/_api-integration.md b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_api-integration.md new file mode 100644 index 0000000000..879f473836 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_api-integration.md @@ -0,0 +1,37 @@ +In this scenario your Auth0 tenant can provide an OAuth2 [Access Token](/tokens/concepts/access-tokens), typically expressed as a [JWT](/tokens/concepts/jwts), which [can be used by your API to restrict access to certain parties](/api-auth). In addition, Auth0 provides support for what is notionally described as both [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party). + +Acting as the authorization server, and with the consent of the user (the resource owner), your Auth0 tenant can be used to provide an Access Token - typically expressed as a [JWT](/tokens/concepts/jwts) - to an application (client) so that it can access a protected resources hosted by a resource server on behalf of the resource owner. The issued Access Token is typically passed as the Bearer token in the HTTP Authorization header sent to an API. + +Whether you have a single API, or perhaps a suite of logically related [microservice APIs](/api-auth/tutorials/represent-multiple-apis), you can leverage the Access Tokens that Auth0 provides in order to secure access to your service(s). Though relatively easy to set this up in the [Auth0 Dashboard](/apis) or through the [Auth0 Management API](/api/management/v2#!/Resource_Servers/post_resource_servers), it's important to review the different application scenarios and API layouts to determine the best architecture for your system. + +::: note +OAuth2 Access Tokens are primarily designed for use in securing public facing APIs; when expressed as a JWT, an Access Token is a self contained entity which can be verfied without the need to make any additional 3rd party API call. If your APIs do not fall into this category - i.e they are part of an application itself (as in only called by that application) or are sat behing your firewall - then protecting them with tokens may well be overkill, and your existing cookie based (et al) workflow may well suffice. +::: + +OAuth2 was designed specifically with third-party access in mind, For example, a scenario might be that a user (resource owner) wants to use an application (a client) that does not belong to the same organization as the service that provides the user's data (the reseource server). In this case, when the application needs to access data that the user owns, it redirects to the organization where the user’s data resides, which in turn authenticates the user and then prompts the user to give the application permission to access their data. This prompting for permission is referred to as providing *[consent](/api-auth/user-consent)* and is a large part of what providing support for [third party applications](/scopes/current/api-scopes#example-an-api-called-by-a-third-party-application) entails. If you are planning to integrate third-party applications, then it's important you [mark them as third-party](/api-auth/user-consent) early on so that Auth0 will handle prompting for user consent. + +On the other hand, if your organization *owns* the application(s), the user data itself and the API(s) through which that data is accessed, then consent is not typically required as the interactions are all [first-party](/scopes/current/api-scopes#example-an-api-called-by-a-first-party-application). If you're only creating first-party applications, then you can ensure that you are not presenting your users with any unnecessary consent screen(s) by [allowing user consent to be skipped](/apis#api-settings) as part of any resource service definition. + +::: warning +Though you can configure your applications to be first-party and subsequently configure your APIs to allow first-party clients to ignore consent, if you are using `localhost` then Auth0 cannot verify that the application is truly a first-party app so your users will be prompted for consent anyway. To work around this constraint, when testing on your local machine during development, create a [fake local hostname and use that instead](https://community.auth0.com/t/how-do-i-skip-the-consent-page-for-my-api-authorization-flow/6035). +::: + +Alternatively, you may have data relating to a user for which additional [functionality is provided](/scopes/current/api-scopes#example-an-api-called-by-a-back-end-service) and for which explicit user consent cannot be obtained (i.e. there is no authenticated user who can provide it). In this scenario, a [list of applications for which Client Credentials grant is enabled](/flows/concepts/client-credentials) can be defined. + +### Access Token claims + +As is the case with ID Tokens, you can [add custom claims to Access Tokens](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) using Auth0 Rule extensibility. Once added, your API can then verify an Access Token for the necessary claims and either allow or prevent access to certain functionality as required. + +::: panel Best Practice +When you are considering adding custom claims, we recommend that you store any access control data you may need to include within claims as part of the user's [`app_metadata`](/users/concepts/overview-user-metadata). Firstly, this prevents you from needing to call an external API to fetch the data, which can negatively impact performance and scalability. Secondly `app_metadata` **cannot** be modified by a user - so the user cannot directly circumvent any access control restrictions by modifying their own metadata. Also remember to check out our [metadata best practices](architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt#metadata) guidance too. +::: + +### Access Token scopes + +[OAuth2 Scopes](/scopes/current/api-scopes) are typically used as the mechanism by which an API can determine what actions can be performed on behalf of a user. Scopes can be added on a per API basis to [define specific access permissions](/dashboard/guides/apis/add-permissions-apis) in the Auth0 Dashboard or through the Auth0 Management API). Scopes can also be manipulated via Auth0 extensibility (e.g. via a Rule, as in this [example](/architecture-scenarios/spa-api/part-2#create-a-rule-to-validate-token-scopes)). The scopes an application requests for accessing an API should depend on what functionality the application needs the user to give permission for the application to use. Once the requested scopes are authorized, they will be returned in the Access Token which can be subsequently verified by said [API](/tokens/guides/validate-access-tokens). A good example of this is when you log in to an application that is using a social provider for login: the social provider API requires that the application specifies whether the user will want the application to post items on your behalf. This allows the user to accept or deny this request. This example demonstrates how the user is delegating permission to the application - which is different than the API restricting access based on a user's role, and should be handled differently. + +::: panel Best Practice +Even though you have the ability to fully manipulate Access Token Scopes via Auth0 extensibility, as a security best practice you should only remove scopes which are not authorized and refrain from adding scopes that were not requested. +::: + +Though scopes are often used as a way to enforce access permissions for a user, there are situations where it can become tricky when you use them in this manner. We therefore recommend that you use scopes for their intended purpose (i.e. delegating permission to an application) and use [custom claims](#access-token-claims) for your role-based or other access control scenarios. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authorization/_application-integration.md b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_application-integration.md new file mode 100644 index 0000000000..bf785f09e1 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_application-integration.md @@ -0,0 +1,17 @@ +In this scenario, your Auth0 tenant provides a token as an indicator of authorized access to an application. For applications utilizing [OpenID Connect (OIDC)](/protocols/oidc), the industry-standard protocol we typically find most utilized when it comes to customer facing applications, this would be an ID Token expressed as a [JWT](/tokens/concepts/jwts). + +### ID Token claims + +Using Rule extensibility, Auth0 allows you to easily [add custom claims to an ID Token](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) based on, for example, a user’s [Metadata](/users/concepts/overview-user-metadata) content. Your application can then verify the ID Token for the necessary claims, and either allow or prevent access to certain functionality as required. Note that though the process of adding custom claims via Rule is streamlined, the Rule engine is flexible and allows you to write custom code that may have negative effects. Therefore it’s important to follow our [rules best practice](/best-practices/rules) guidance anytime you use this extensibility feature. + +::: panel Best Practice +When you are considering adding custom claims, we recommend that you store any access control data you may need to include within claims as part of the user's [`app_metadata`](/users/concepts/overview-user-metadata). Firstly, this prevents you from needing to call an external API to fetch the data, which can negatively impact the performance and scalability of the login sequence. Secondly `app_metadata` **cannot** be modified by a user - so the user cannot directly circumvent any access control restrictions by modifying their own metadata. Also remember to check out our [metadata best practices](architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt#metadata) guidance too. +::: + +<% if (platform === "b2b") { %> +If you are creating different instances of your application for your customer organizations, a common practice is to create a custom claim in your ID token to represent the user's organization. For example, `context.idToken["http://yourdomain.com/claims/organization"]= "organization A";` +<% } %> + +### ID Token scopes + +[OIDC Scopes](/scopes/current/oidc-scopes) are typically used by an application to obtain consent for authorized access to a user's details during authentication. Each of the pre-defined scopes returns the set of [standard claims](/scopes/current/oidc-scopes#standard-claims) where defined, and as described in the [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). The scopes an application requests depend on which user attributes the application needs. Once the requested scopes are authorized by the user, the claims are returned in the ID Token and are also made available via the [/userinfo](https://auth0.com/docs/api/authentication#get-user-info) endpoint. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authorization/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_introduction.md new file mode 100644 index 0000000000..b1720ae98f --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_introduction.md @@ -0,0 +1,47 @@ +Let's start by taking a step back and talking about Access Control. There isn't one clear cut definition of Access Control in the industry, but if you spend some time searching and reading you'll see that most authoritative sources agree that it is the umbrella concept that puts all of Authentication, Authorization, Consent, and Policy Enforcement together to ensure that only the right people and services have access to your applications and APIs. Next, let's look more closely into the distinctions between Authentication, Authorization, Consent, and Policy Enforcement. Your Auth0 tenant (your Authorization Server) is typically responsible for Authentication and Consent, and some or all of Authorization and Policy Enforcement. Additionally, an Application or API itself almost always is the primary enforcer of policies, especially where contextual access is required: + +* **Authentication**: the process of determining if a principal (a user or application) is who or what they say they are. +* **Authorization**: the process of determining what is allowed, based on the principal, what permissions they have been given, and/or the set of contextually specific access criteria. +* **Consent**: what permissions the user (Resource Owner) has given permission to an application to do on its behalf. This is generally a requirement of delegated authorization. The user has to give permission to the Client to access the user's data in a different system. +* **Policy Enforcement**: The act of enforcing the policies of the application or API, rejecting or allowing access based on a user's authentication and/or authorization information. + +In general we typically group different types of access control into three distinct categories so that it's easier to understand a) which actor is responsible for storing the information, b) which actor is responsible for making decisions, and c) which is responsible for enforcing the restrictions. + +* The first category is where access is either granted or denied to an application or an API in its entirety. Both the data required to enforce this and the enforcement process is typically defined in the context of the Authorization Server For example, by using [`app_metadata`](/users/concepts/overview-user-metadata) associated with a user and a [Rule](/rules) defined in your Auth0 tenant. + +* The second category is where access is either granted or denied to a specific subset of application or API functionality. The data required to enforce this is typically stored in the Authorization Server For example, by using [`app_metadata`](/users/concepts/overview-user-metadata) on a user in your Auth0 tenant with the enforcement process performed in the application or API itself. In this scenario, the data is typically communicated as one or more custom claims in an [`id`](/tokens/concepts/id-tokens) or [`access`](/tokens/concepts/access-tokens) token. + +* The third category is where access is either granted or denied depending on what the principal (subject) can operate on within the context of an application or API. Both the data required to enforce this, and the enforcement process is typically defined in the context of the application or API. In this scenario, the data communicated as one or more custom claims in an [`id`](/tokens/concepts/id-tokens) or [`access`](/tokens/concepts/access-tokens) token may be consumed with or without data from an external source that is not Auth0. + +In addition, Role-based Access Control (RBAC) and Attribute-based Access Control (ABAC) mechanisms can be applied in any of the Access Control categories described above. Whatever your use case then, there are a number of things you will want to consider when looking at the functionality and workflow you require: + +* Are there scenarios where access to an entire application or API should be rejected? +* Will you be providing APIs that can be accessed by third-party applications? +* Will your APIs also be accessed by your own (first-party) applications? +* Will your application be calling a third-party API? +* Should your applications and/or APIs be enforcing access control based on user claims? +<% if (platform === "b2b") { %> +* What if I need to know which organization an access token or id token is associated with? +<% } %> + +Auth0 supports access restriction for either applications or APIs based on certain conditions. In certain scenarios, you may want to create a [Rule](/rules) that returns an `UnauthorizedError` when, for example, a user attempts access to an application or an API at an incorrect time (as described in this [example](/authorization/concepts/sample-use-cases-rules#allow-access-only-on-weekdays-for-a-specific-application)) - or if the user doesn’t have the right claim(s) contained in their [`app_metadata`](/users/concepts/overview-user-metadata). For an _application_ using [OpenID Connect (OIDC)](/protocols/oidc), this would prevent the allocation of the [ID Token](/tokens/concepts/id-tokens) used to authorize access. Similarly, for an _API_, allocation of any OAuth2 [Access Token](/tokens/concepts/access-tokens) (used when calling the API), could be prevented as described in this [example](/api-auth/restrict-access-api#example-deny-access-to-anyone-calling-the-api). + +::: panel Best Practice +In the main, we have found that [OIDC](/protocols/oidc) is the most commonly used industry-standard protocol used by Auth0 customers when it comes to authentication in their applications. We have also found that, even though [OAuth2](protocols/oauth2) was created as a delegation protocol, it is commonly used within first party applications when there is an API that does not have a shared session with the application. +::: + +Auth0 also can provide the information needed so that an application can enforce restrictions. For [application level integration](#application-integration), Auth0 allows you to add [custom claims](#id-token-claims) to an ID Token, which your application can then verify and subsequently use to perform policy enforcement. In this case you will need to decide what information you require for your application to make enforcement decisions. If you need to make decisions at an API instead of in your application, you will likely need to use an Access Token instead of an ID token. Continue reading for more information. + +::: warning +When deciding what data to include in your ID token and/or access token, consider token size, especially if you are passing the token in the URL. Even if you are not passing tokens in the URL, you will also need to consider the potential of exposing sensitive PII (Personally Identifiable Information). Token information is not encrypted, so although it isn't generally a security issue for an ID token to be leaked, it can become a privacy issue depending on the data that is included in the token. +::: + +For [API level integration](#api-integration), Auth0 supports both [custom claims](#access-token-claims) as well as [scope](#access-token-scopes) re-configuration, both within the context of an Access Token. Again, you will need to decide what information will be required in order for your API to make access decisions, and your API will need to enforce that by validating the contents of the Access Token. + +::: panel Best Practice +When deciding whether you should use permissions through custom claims or scopes, you should make sure you understand the nature and purpose of scopes. +::: + +<% if (platform === "b2b") { %> +For multi-organization scenarios, it can often be important to know which organization an access token (or even an ID token) applies to. Taking care to follow the [best practices](#organization-data-in-an-access-token) can save you time and effort. +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authorization/_m2m.md b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_m2m.md new file mode 100644 index 0000000000..f22d07cc27 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_m2m.md @@ -0,0 +1,13 @@ +There are many scenarios that require an application _without_ any user-interactive session to obtain an access token in order to call an API. In such scenarios you must authenticate the client instead of the user, and OAuth 2 provides the [client credentials](/flows/concepts/client-credentials) grant type to make this easy to achieve. Some common examples of where this is required include: +* A cron job or other service that needs to communicate with your API (e.g. where a daily report needs to be generated and emailed it to an administrator). +* A separate API the supports privileged access (e.g. the API is not exposed to users directly, but instead to a backend only). +* In certain microservice architectures, where some API layers need to communicate to other API layers without a user involvement, or after a user token has expired. +* A privileged API that may need to be called before a user has authenticated (i.e. from a rule or custom DB script in your Auth0 tenant) + +::: panel best practice +Traditionally, a special "service account" would have been created in order to cater for these scenarios: a user with a username and password that was configured for services which supported non-interactive use cases. That is no longer a recommended approach for many reasons, and the current best practice is to use [OAuth 2.0 Client Credentials Grant](/flows/concepts/client-credentials) in these situations. +::: + +::: warning +Though the [Client Credentials Exchange Hook](/hooks/extensibility-points/client-credentials-exchange) in Auth0 can be used to add custom claims, it's important to consider the purpose for which a token was requested and to avoid extending use of the token beyond its intended purpose. Doing otherwise can result in the creation of unintended attack vectors for attackers to exploit. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_authorization/_rbac.md b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_rbac.md new file mode 100644 index 0000000000..68df646d59 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_authorization/_rbac.md @@ -0,0 +1 @@ +Auth0 has out-of-box support for Role Based Access Control ([RBAC](/authorization/concepts/rbac)). RBAC refers to assigning permissions to users based on their _role_ within an organization, and provides for simpler access control by offering a more manageable approach that is less prone to error. \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/_includes/_base-intro.md b/fr-ca/articles/architecture-scenarios/_includes/_base-intro.md new file mode 100644 index 0000000000..2dfc169d6e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_base-intro.md @@ -0,0 +1,5 @@ +Customers using Auth0 for <% if (platform === "b2c") { %>Business-to-Consumer (B2C)<% } else { %>Business-to-Business (B2B)<% } %> projects typically share a common set of goals and objectives, and in the sections that follow we'll focus on our real-world customer implementation experiences to help you deliver your solution efficiently. + +::: panel Best Practice +Auth0 provides recommendations and best practice suggestions in an *ad hoc* way throughout this guide in panels like this one. You can also obtain detailed guidance regarding specific functionality by speaking with your account representative or a member of our Auth0 [Professional Services](/services) team. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md b/fr-ca/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md new file mode 100644 index 0000000000..7089399c48 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md @@ -0,0 +1 @@ +There are many different ways Auth0 can be integrated into the <% if (platform === "b2c") { %>CIAM<% } else { %>B2B IAM<% } %> project architecture. Auth0's flexibility comprehensively supports many different use cases however your project may not require all of the capabilities provided by Auth0. Knowing what, when, and how best to implement something will help you focus on completing the necessary tasks at the right time. \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md new file mode 100644 index 0000000000..ae02a82b67 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md @@ -0,0 +1,15 @@ +By default, the URL associated with your tenant will include its name and possibly a region-specific identifier. For example, tenants based in the US have the a URL similar to `https://example.auth0.com` while those based in Europe have something that is of the fashion `https://example.eu.auth0.com`. A [Custom Domain](/custom-domains) offers a way of providing your users with a consistent experience by using a name that’s consistent with your organization's brand. + +::: warning +Only one custom Domain Name can be applied per Auth0 Tenant, so if you absolutely must have independent domain name branding then you will require an [architecture](/architecture-scenarios/implementation/${platform}/${platform}-architecture) where multiple Auth0 Tenants are deployed to production. +::: + +In addition, Custom Domain functionality offers you complete control over the [certificate management](/custom-domains#certificate-management) process. By default, Auth0 provides standard SSL certificates, but if you configure a custom domain, you can use Extended Validation (EV) SSL certificates or similar to provide the visual, browser-based cues that offer your visitors additional peace of mind. + +In general, we see customers having the most success when they use a centralized domain for authentication - this is especially the case if the company offers multiple products or service brands. By using a centralized domain, you can provide end users with a consistent user experience while also minimizing the need to maintain multiple production tenants in Auth0. + +<% if (platform === "b2b") { %> +::: warning +If your customer organizations will be isolated from each other, and you require that users are presented a login page for each organization via a custom domain URL, then your only option is to create a [separate tenant for each organization](/architecture-scenarios/${platform}/${platform}-architecture#tenant-provision-for-complex-organizations). +::: +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_email-templates.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_email-templates.md new file mode 100644 index 0000000000..3b3dccdf63 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_email-templates.md @@ -0,0 +1,9 @@ +Auth0 makes extensive use of email to provide both user notifications and to drive the functionality needed for secure identity management (for example, email verification, account recovery, and brute force protections), and Auth0 provides a number of templates for these. + +::: note +Before customizing email templates, please set up your [Email Provider](/architecture-scenarios/implementation/${platform}/${platform}-operations#email-provider-setup). +::: + +Out of the box, the email templates used contain standard verbiage and Auth0 branding. However, you can configure almost every aspect of these templates to reflect the verbiage and user experience you want and make changes to things like the preferred language, accessibility options, and so forth. + +Email templates are customized using [Liquid syntax](/email/liquid-syntax). If you are interested in customizing your templates based on user preferences, you will also have access to the [metadata](/users/concepts/overview-user-metadata) located in users' profiles, as well as any specific application metadata too. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_error-page.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_error-page.md new file mode 100644 index 0000000000..4f74e4757a --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_error-page.md @@ -0,0 +1,5 @@ +If there are issues encountered during user interactive workflow (e.g. user sign up or login), Auth0 provides error messages that indicate what the problem is under the hood. The default messages are somewhat cryptic, especially to the end user, since they will likely be missing context that only you can supply. As such, we recommend [customizing your error pages](/universal-login/custom-error-pages) to provide the missing context-specific information directly to your users. Furthermore, customizing your error pages allows you to display your branding, not Auth0's, as well as provide useful information to your users as to what should be done next. This information might include a link to a FAQ or how to get in touch with your company's support team or help desk. + +::: panel Best Practice +Out-of-the-box there is no user interface for customizing Auth0 provided error pages, but you can use the [Tenant Settings endpoint of the Management API](/api/management/v2#!/Tenants/patch_settings) to configure them. Alternatively, if you can create and host your own error page, then you can have Auth0 direct users to that page instead of using the Auth0-hosted option. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_guardian.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_guardian.md new file mode 100644 index 0000000000..99b6009f56 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_guardian.md @@ -0,0 +1,3 @@ +The Multi-factor Authentication pages can be customized by adjusting the Universal Login branding options in the [Universal Login Settings](${manage_url}/#/login_settings) section. + +If you need further customization, you can also customize [the full HTML content](/universal-login/multifactor-authentication#customizing-the-html-for-the-mfa-page) to reflect your organization's particular UX requirements. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_introduction.md new file mode 100644 index 0000000000..387c2dc354 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_introduction.md @@ -0,0 +1,35 @@ +Auth0 can be customized with a look and feel that aligns with your organization's brand requirements and user expectations. Branding Auth0 collateral provides a consistent user experience for your customers, and gives them peace of mind that they’re using a product from a trusted and secure provider. + +Auth0 provides support for [internationalization (I18N)](/i18n) and localization (L10N), both of which are important if you work on branding for an international clientele. Out-of-box collateral, such as the Auth0 Lock UI widget, comes ready enabled for multiple language support, with built-in extensibility for adding more languages if what you require [doesn’t already exist](/libraries/lock/v11/i18n). + +::: panel Best Practice +Almost all applications need Internationalization and/or Localization in one form or another. Auth0 makes it easy to add, but you need to account for it up front: retro-fitting localization, for example, can be a painful process if left too late. +::: + +When considering the items you want to brand, as well as how best to brand them, there are a number of things you'll want to review: + +* Do you need to brand your login page? +* Do you need to localize your login page? +<% if (platform === "b2b") { %> +* If you are sharing an Auth0 tenant across customer organizations, should you add organization-specific branding to their login experience? +<% } %> +* How can you customize emails so that they're not just branded, but vary based on user preference? +* How will users know that they're still on your domain when they see your login page? +* What do you need to do to provide additional browser security (e.g., implement Extended Validation)? +* Where do you want to direct users in the event of errors? + +Auth0 provides tremendous flexibility when it comes to customizing and configuring Auth0 pages such as [Universal Login](#universal-login-and-login-pages) and [Password Reset](#password-reset-page-customization). So you can pretty much set up whatever UX look and feel you require. For many, the out-of-the-box experience - with perhaps a little alteration - is all that's required. However, for others the value of their brand and brand awareness requires more extensive customization. This flexibility extends to not only Auth0 pages, but via extensibility can also be applied to the [email templates](/architecture-scenarios/implementation/${platform}/${platform}-branding#email-template-customization). Auth0 [Custom Domain](/architecture-scenarios/implementation/${platform}/${platform}-branding#custom-domain-naming) functionality further enhances consumer awareness by providing users with the confidence and peace of mind when it comes to safety and security. + +<% if (platform === "b2b") { %> +If you are sharing an Auth0 tenant across multiple customer organizations, providing each organization with their own domain of users and managing their credentials, you will need to consider how each user will know which credentials they should use and how they will trust that they are entering them somewhere safe and secure. See [Branding login by organization](#branding-login-by-organization) for details. +<% } %> + +While Auth0 provides for default information when it comes to error situations, out-of-the-box information can be somewhat cryptic as the context that can only be provided by you is missing. Auth0 [error page customization](/architecture-scenarios/implementation/${platform}/${platform}-branding#error-page-customization) guidance can however help mitigate that by allowing you to provide information of a more context-specific nature via your own support organization. + +::: panel Best Practice +To provide helpful resources for users who experience problems, you should also configure a friendly name and a logo, as well as provide the support email address and URL for your organization. To learn how, see [Dashboard Tenant Settings](/dashboard/reference/settings-tenant#settings). +::: + +::: panel Get Started with Auth0 Videos +Watch three short videos—[Brand: How It Works](/videos/get-started/07_01-brand-how-it-works), [Brand: Signup and Login Pages](/videos/get-started/07_02-brand-signup-login-pages), and [Brand: Emails and Error Pages](/videos/get-started/08-brand-emails-error-pages)—to learn how branding works with Auth0, how to use Auth0’s Universal Login feature to customize your sign up and login pages, and how to use Auth0 email templates and make changes to the reply email address, subject, redirect URL, and URL lifetime. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_password-reset.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_password-reset.md new file mode 100644 index 0000000000..c3b0785c61 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_password-reset.md @@ -0,0 +1,8 @@ +The [Password Reset](/universal-login/password-reset) page is used whenever a user takes advantage of password change functionality and, as with the login page, you can [customize it](/universal-login/password-reset#edit-the-password-reset-page) to reflect your organization's particular branding requirements. + +<% if (platform === "b2b") { %> +If your organization users will all be isolated from each other (i.e, each organization gets its own Auth0 [database connection](/connections/database)), and you are branding the [Universal Login](#universal-login-and-login-pages) pages by organization, then it's also important to brand things like the [password reset](/universal-login/password-reset) page so users know for which organization the password change is occurring. This can be done in a couple of ways: + +* Create JavaScript on the Password Reset page that can pull resources from a CDN based on the connection parameter that indicates from which organization the user is coming. +* Create a separate tenant for an organization and use Universal Login to customize what is required for that organization. +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_branding/_universal-login.md b/fr-ca/articles/architecture-scenarios/_includes/_branding/_universal-login.md new file mode 100644 index 0000000000..69e2691da7 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_branding/_universal-login.md @@ -0,0 +1,5 @@ +[Universal Login](/universal-login) is the recommended method for authenticating users, and it centers around use of the Login page. You can customize the Login page to support your organization's [branding requirements](/universal-login#customizing-universal-login). + +::: panel Best Practice +If you choose to customize the Universal Login page script, we strongly recommend that you make use of version control. To do this, you should deploy the script to your Auth0 tenant via [deployment automation](/architecture-scenarios/implementation/${platform}/${platform}-deployment) or via one of the [alternative strategies](/universal-login/version-control). +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_deployment/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_deployment/_introduction.md new file mode 100644 index 0000000000..c301f040e3 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_deployment/_introduction.md @@ -0,0 +1,31 @@ +In addition to adopting best practices for change management and [QA](/architecture-scenarios/implementation/${platform}/${platform}-qa), successful customers will also integrate Auth0 collateral management as part of some automated deployment process. As discussed in the Architecture section under [SDLC support](/architecture-scenarios/implementation/${platform}/${platform}-architecture#sdlc-support), you will want to ensure you configure separate Auth0 tenants for development, testing, and production environments, and you will want that configuration to be almost identical for the tenant in each environment. Using deployment automation helps ensure this, so that each environment tenant is configured the same, and you will be less likely to see bugs show up as a result of mismatched configurations between environments. + +::: panel Best Practice +However you configure deployment automation, we’d recommend you unit test your rules, custom DB scripts, and hooks prior to deployment, and run some integration tests against your tenant post-deployment too. For more details regarding this, see the [Quality Assurance](/architecture-scenarios/implementation/${platform}/${platform}-qa) guidance provided. +::: + +Auth0 provides support for a couple of different options when it comes to the deployment automation approaches you can use, and each can be used in conjunction with the other if desired: + +* The [Auth0 Deploy CLI tooling](/extensions/deploy-cli) provides you with an easy-to-use script that can help you integrate with your existing Continuous Integration/Continuous Deployment (CI/CD) pipeline. +* If you can’t integrate directly with, or for some reason you don’t have a CI/CD pipeline, then the Auth0 [Source Control Extensions](/extensions#deploy-hosted-pages-rules-and-database-connections-scripts-from-external-repositories) can provide an easy-to-set-up basic automation process with very low maintenance. + +::: warning +Note that both the Deploy CLI Tool and source control extensions can cause destructive changes; manual changes made directly in the dashboard between automated deployments could be lost! For this reason, if either is used, then **all** changes should be deployed from the source control subsystem referenced via the tooling and not made manually. +::: + +Each environment may also need some environment-specific configuration--Application Client ID’s and Client Secrets will be different between the Auth0 tenants, for example--so you’re going to want some way of being able to dynamically reference this rather than having hard-coded values. Auth0 provides support for handling environment-specific configuration information through one of the following two approaches: + +* Use [Tenant Specific Variables](#tenant-specific-variables) +* Use [keyword replacement](extensions/deploy-cli/references/environment-variables-keyword-mappings) if using the Auth0 Deploy CLI tool + +## Tenant specific variables + +Auth0 allows you to configure variables that are available from within custom [extensibility](/topics/extensibility); these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time: + +* For use of variables in Rules, see how to [configure values](/rules/guides/configuration#configure-values) +* For use of variables in Hooks, see how to configure [secrets](/hooks/secrets) in the editor +* For use of variables in Custom DB Scripts, see the [configuration parameters](/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters) + +::: panel Best Practice +It’s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub/Gitlab/Bitbucket/VSTS, then using a tenant-specific variable avoids exposure of sensitive values via your repository. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_implementation-checklists.md b/fr-ca/articles/architecture-scenarios/_includes/_implementation-checklists.md new file mode 100644 index 0000000000..c4624b459c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_implementation-checklists.md @@ -0,0 +1,13 @@ +Use the links below to download a spreadsheet that includes tasks for each phase of an Software Development Lifecycle (SDLC) project. + +Analyze Checklist + +Design Checklist + +Build Checklist + +Test Checklist + +Deploy Checklist + +Monitor Checklist diff --git a/fr-ca/articles/architecture-scenarios/_includes/_keep-reading.md b/fr-ca/articles/architecture-scenarios/_includes/_keep-reading.md new file mode 100644 index 0000000000..9697768911 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_keep-reading.md @@ -0,0 +1,37 @@ + +<% if (self !== "architecture") { %> +* [Architecture](/architecture-scenarios/implementation/${platform}/${platform}-architecture) +<% } %> +<% if (self !== "provisioning") { %> +* [Provisioning](/architecture-scenarios/implementation/${platform}/${platform}-provisioning) +<% } %> +<% if (self !== "authentication") { %> +* [Authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication) +<% } %> +<% if (self !== "branding") { %> +* [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) +<% } %> +<% if (self !== "deployment") { %> +* [Deployment Automation](/architecture-scenarios/implementation/${platform}/${platform}-deployment) +<% } %> +<% if (self !== "qa") { %> +* [Quality Assurance](/architecture-scenarios/implementation/${platform}/${platform}-qa) +<% } %> +<% if (self !== "profile-mgmt") { %> +* [Profile Management](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt) +<% } %> +<% if (self !== "authorization") { %> +* [Authorization](/architecture-scenarios/implementation/${platform}/${platform}-authorization) +<% } %> +<% if (self !== "operations") { %> +* [Operations](/architecture-scenarios/implementation/${platform}/${platform}-operations) +<% } %> +<% if (self !== "logout") { %> +* [Logout](/architecture-scenarios/implementation/${platform}/${platform}-logout) +<% } %> +<% if (self !== "operations") { %> +* [Operations](/architecture-scenarios/implementation/${platform}/${platform}-operations) +<% } %> +<% if (self !== "launch") { %> +* [Launch Preparation](/architecture-scenarios/implementation/${platform}/${platform}-launch) +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_compliance.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_compliance.md new file mode 100644 index 0000000000..8538d072c5 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_compliance.md @@ -0,0 +1,37 @@ +There are several requirements related to privacy and compliance. Auth0 cannot provide legal guidance on your privacy or other regulatory obligations, but we can provide a curated list of privacy requirements below for which Auth0 offers features that may help you meet your obligations. Prior to launch, you should check that you’ve met all your privacy obligations and review the features outlined below to ensure you’re leveraging all the available Auth0 features to help you meet your privacy and compliance requirements. + +## Publish privacy policy and obtain user consent + +If you collect or process personal data about users, you should have published a privacy policy and have established procedures to ensure your operations abide by the contents of the policy. You also need to obtain a user’s consent for the collection and processing of information. Auth0 provides options for [displaying a link to your privacy policy storing user consent](/compliance/gdpr/features-aiding-compliance#conditions-for-consent). + +## Provide access to view, correct and erase data + +Privacy legislation often requires that users have the right to view and correct any data held about them. If you are a data controller, you should provide a mechanism for this. Auth0 customers can [build a self-service feature to access and correct data via the management API](/compliance/gdpr/features-aiding-compliance#right-to-access-correct-and-erase-data). + +## Provide access to data portability + +If you are a data controller, you may be obligated to provide users a means to export their data from your system in a transportable format. Auth0 provides [user data portability mechanisms](/compliance/gdpr/features-aiding-compliance#data-portability) to help you satisfy this obligation via both manual export capabilities and the Management API which enables you to implement a self-service feature for users. + +## Take steps to minimize personal data + +You should have reviewed the personal data you collect about users to ensure it is legitimately required for the purposes of the processing covered in the privacy policy and consent. You should also confirm you have [minimized the data you collect](/compliance/gdpr/features-aiding-compliance#data-minimization), and established a data retention policy. You can optionally elect to encrypt data you store in user metadata for additional protection. + +## Data retention policy enforcement automated + +You should have a published data retention policy and automate the enforcement of it. The Auth0 management API or the Auth0 dashboard can be used to facilitate [erasure of user accounts](/compliance/gdpr/features-aiding-compliance/right-to-access-data). + +## Protect personal data + +Regardless of whether you are a data controller or a data processor, you have obligations to protect the personal data you hold about users. This includes use of encryption where possible, and implementing reasonable security measures to protect user accounts. Prior to launch, you should check if you are using all the security features available from Auth0 to help with this such as Brute Force Detection, Multi-Factor Authentication (for both users and administrators), and a strong password policy if using passwords. You should also ensure you have a process ready to respond to [Brute Force attacks](/compliance/gdpr/features-aiding-compliance#protect-and-secure-user-data). + +## Supplier evaluation + +Another common compliance obligation is to perform due diligence review of the security of any third-party suppliers to which you expose personal data. For Auth0, you will find information to facilitate this task on the Auth0 [security and certifications](https://auth0.com/security/) page where you can view the security certifications Auth0 has obtained. + +## Additional resources + +Additional resurces that may be useful for your compliance requirements include: +* [Auth0 Privacy Policy](https://auth0.com/privacy) +* [Security and Compliance](https://auth0.com/security/) +* [GDPR and Compliance Frameworks](/compliance) +* [Auth0 support for customer requirements](/compliance/gdpr/features-aiding-compliance) diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_introduction.md new file mode 100644 index 0000000000..4909da3507 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_introduction.md @@ -0,0 +1 @@ +Use this guide as you prepare for the launch of your application. We’ve included reminders about some content you may have viewed earlier during your planning or development phases as well as some new content unique to the launch phase. The sections below are useful to developers and project owners to ensure that you have everything lined up for a smooth launch. There are several things to check so it may help to assign ownership of different sections to different members of your team. \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_launch.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_launch.md new file mode 100644 index 0000000000..c0c5526d56 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_launch.md @@ -0,0 +1,112 @@ +## Notifications / announcements + +It helps a launch go smoothly if all stakeholders are aware of the impending launch and understand the launch plan as well as their role and responsibilities. In addition to notifying teams that will be actively involved, it can help to notify teams that might be needed if anything goes wrong. Having someone on standby during a launch can help expedite response. Be sure to identify and notify any team that might need to answer questions from customers, including on social media. + +### Parties to notify + +* Customers +* Business parters, if applicable +* Application team(s) impacted by launch +* Support teams +* Network teams (network changes, on standby, in case of issues) +* Security teams (on standby, in case of issues) +* Marketing teams (ready for announcements, response to issues) +* Social media teams (ready to monitor social media, respond) +* Sales teams (prepared to answer questions from customers) +* Customer success teams (prepared to answer questions from customers) + +## Notification plan + +Your notification plan should include elements such as the target audience, the key takeaways for the audience, the message content, the plans for distributing the notification and how to test the messaging. + +A list of elements to include in the plan are: + +* Target audience (consider both internal & external audiences) +* Message +* Timing +* Dependencies +* Responsible parties (who will send it) +* Mechanism (how it will be communicated) +* Test message and delivery (if applicable - test to ensure notifications sent) + +## Notification distribution + +A common tactic is to release notifications in batches to spread out the initial onslaught of load and reduce the scope of confusion if there are any unforeseen glitches. It’s easier to correct issues with a small group than during a big-bang launch. + +* One approach is to start with a relatively small batch of notifications, and if no issues are identified, increase the size of the batches over time. +* You can also send out batches on a rolling schedule around the globe to spread out load hitting the system at once and have notifications arrive at an optimal time within each timezone to increase the likelihood of the messages being read. +* You can do a soft-launch to a portion of users, such as individual customers, regions or some other grouping that makes sense for your application. + +## Outage windows (if needed) + +Some organizations require a formal request for an outage window if any outages or downtime is required for a launch. If your organization requires this, be sure to identify if any downtime is required for the cutover or launch (or other dependent systems) and file the necessary outage or change requests in advance of any lead-time requirements. + +## Cutover plan (if needed) + +Some launches involve cutover from a previous solution to a new solution. If your project fits this scenario, you should be sure to identify everything that needs to happen as well as any dependencies, the responsible party for each task, and necessary timing. You may wish to plan alternates for all important roles or in each region in case anyone is unexpectedly sick or otherwise unavailable. A checklist of items to consider for the cutover plan is: + +* Have you documented the cutover plan and rollback plan if needed? +* Are backups needed of anything prior to change? +* Are any preparatory data changes required? +* Any DNS records to be changed? +* Any Firewall changes? +* Any new monitoring targets? +* Any software to be deployed? + +## Go / no-go criteria + +In your overall launch plan, it is helpful to have go/no-go criteria and to have discussed in advance the types of issues which could occur and which could be worked through vs would require reverting. A launch plan can specify periodic check-in timeframes with criteria of what to assess at each checkpoint and how long to allow an issue to continue unresolved. + +For each stage of the launch, it helps to have success criteria defined, that indicate the launch is proceeding as planned and can continue. Some example criteria could be: + +* User signups growing with minimal errors +* User logins at expected rate, minimal errors +* Reported support issues below a certain threshold +* No issues identified that could lead to corrupted data + +It’s also helpful to have identified criteria which could trigger a “no-go” decision to halt the launch. The risk tolerance for each environment varies, but a few example criteria might include: + +* High percent of user signup or login resulting in errors that cannot be resolved quickly +* High number of support issues that cannot be resolved quickly +* Condition identified that could lead to data corruption +* High severity security issue discovered + +## Rollback + +It is always wise to have a plan for how to rollback or revert a launch, just in case something unforeseeable occurs which cannot be resolved. Reviewing the launch plan for every step which involves a change can help identify the tasks or changes requires to revert a launch or cutover. + +The rollback plan should include the steps to take, the sequence, how long each is likely to take and the responsible party. Understanding the cumulative time required to roll back can help to determine the timing of the final go/no-go decision to fit within any required outage window. + +If any data is migrated or changed for the launch, the plan should include how to revert it, if needed. Reverting may require running scripts to undo operational changes or restoring a data store from a backup taken before the launch process began. + +It is also necessary to plan for the case where some data is entered into a new system before it has to be reverted. Will such data / transactions need to be abandoned with the rollback or will you have a way to capture and apply them elsewhere so they aren’t lost? + +If the resolution of issues or process to revert could potentially take longer than one shift, you’ll want to ensure you have a primary and perhaps a secondary person available and prepared to handle things during each work shift. If an issue results in the need for prolonged response, significantly beyond one shift, there are limits for how long people can realistically function without a break. It can help to be prepared with resources for a follow-the-sun issue response effort if needed. + +## Standby contacts + +As the launch day approaches, it’s a good idea to identify all contacts who might be needed for troubleshooting or resolving issues and request them to be on standby and ready to help if needed. The launch leader should have contact information for each person on the standby list to expedite communications. + +If there is a physical or virtual "launch room", the people on standby should know where it is and be ready to join if needed. Having a central room or video conference prepared can expedite communications and troubleshooting across all parties if an issue occurs. + +## Success Criteria + +A lot of planning goes into a launch in order to be successful, but will you know how to evaluate the launch? If you define success criteria before the launch, you can determine what to monitor and if any additional monitoring or checks need to be in place to evaluate the launch. +For example - if one element of the success criteria is the number of sign-ups or logins - do you have a way of monitoring that and has it been tested to ensure it is accurate? + +You’ll want statistics to be able to trumpet the success of your launch. You don’t want to find out after the launch that you didn’t capture any data to quantify all the hard work your team put into the launch. + +## Risks & mitigations plan + +It’s no fun to think of things that could go wrong, but if anything happens, you’ll be glad you did as having a plan can expedite response. A few examples to plan for include: + +* Software application bug +* Application incompatibility with user browser settings +* Network failure/outage +* DoS attack +* Hosting environment failure +* Load / capacity issues +* Data / corruption issues +* Security vulnerability discovered + +If you had a beta period, it may help to review the results of the beta to identify additional possible failure scenarios. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_operations.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_operations.md new file mode 100644 index 0000000000..22a43ad85d --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_operations.md @@ -0,0 +1,96 @@ +## Status + +You should ensure your operations staff knows how to monitor Auth0 service status and has set up a means to subscribe to updates on Auth0 status. + +<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2b' }) %> + +## Email provider setup + +You should double check that you have set up your own email provider to support production volumes of emails that might be sent to customers for signup, email validation, account recovery and the like. + +<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2b' }) %> + +## Infrastructure + +<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2b' }) %> + +## NTP + +If this is not handled automatically by your hosting environment, you should have scripts which will automatically restart NTP (Network Time Protocol) if it fails and alerts that will notify someone if NTP is not running. Authentication transactions rely on accurate system time because security tokens may be evaluated as expired when received if there are time discrepancies between sending and receiving systems. + +## LoadBalancer timeouts checked + +If you use the AD/LDAP connector, you should check the load balancer settings in your environment to see if they terminate long running connections that are inactive. If they do, you can modify the [Auth0 AD/LDAP Connection settings](/connector/modify#configuration-file) to use the `LDAP_HEARTBEAT_SECONDS` setting to send periodic heartbeat messages to keep the connection open. + +## LoadBalancer configuration + +If your application maintains server state such that it depends on sticky load balancing to route users to a particular server, it can be beneficial to double check that all load balancer configurations are correct. One load balancer in a pool that is out of sync can cause intermittent errors that are hard to troubleshoot. A quick check of load balancer configuration can avoid such issues in the first place. + +## Logs + +You should check that you have set up the ability to capture log data, that logs are covered by your data retention policy and you have mechanisms to enforce logs data retention limits. You should also make sure that your development, support, and security teams know how to access logs data for troubleshooting and forensics purposes. Exporting log files to services that provide comprehensive analytics can help you identify patterns such as usage trends and errors. + +<%= include('../../_includes/_operations/_logging.md', { platform: 'b2b' }) %> + +## Monitoring + +Be sure to set up proactive monitoring of the Auth0 service as well as end-to-end authentication through your application. + +<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2b' }) %> + +## Auth0 Notifications + +You should ensure your team is monitoring all of the following communication channels from Auth0 to stay abreast of important announcements and changes. + +<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2b' }) %> + +In addition, you should periodically check the [Auth0 migrations page](/product-lifecycle/migrations) for news about upcoming deprecations that might require your team to make changes. + +## Automated Deployment, version control + +While not required, it is highly recommended that you have deployment automation set up. You can respond more efficiently if you need to make any changes after launch if you have automated the ability to deploy and revert changes to dev, test and production environments. + +<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2b' }) %> + +## Backup / Restore + +You should have a plan and mechanism in place to support any backup/restore capability needed for your project. This can be done using the Auth0 Management API for data as well as the Automated Deployment capabilities described in the automated deployment section for Auth0 configuration. + +As noted in the Auth0 [Data Tenant Restore policy](policies/restore-deleted-tenant) and [Data Transfer policy](policies/data-transfer), Auth0 does not restore deleted tenants or move data between tenants. Auth0 provides the Auth0 Management API to provide customers a completely flexible capability to backup, restore and move data as needed. Customers can write scripts to retrieve data from Auth0 for backup purposes, and similarly write scripts for use with the Automated Deployment capability to restore any aspect of their Auth0 configuration. + +## Versions Up to Date + +You should double check that all technologies in your application stack, as well as browser versions used by your users are on current, up-to-date versions as this will impact Auth0’s ability to provide support if issues arise. +* Check you are using the latest supported version of node.js in [Auth0 dashboard settings](/dashboard/dashboard-tenant-settings#extensibility). +* Check you are using a version of SDK/Libraries supported by Auth0 per the [Auth0 Support Matrix](/support/matrix). + +## Certificate rollover plan + +Certificates may be used in identity deployments. To ensure a certificate expiration does not catch you by surprise, you should have a list of certificates in your environment along with the expiration dates, how you will be notified when expiration draws near and how the certificate rollover process works. + +### SAML connections + +For SAML connections, you obtain a certificate from the IdP and upload it to a SAML connection for the IdP in your Auth0 dashboard. When one of these certificates is about to expire, Auth0 will send email to dashboard administrators warning of the upcoming expiration. You can obtain the new certificate and upload it using the connection configuration screen. + +### WS-Fed connections + +For WS-Fed connections, if you configure them by specifying an ADFS URL, any changes will be picked up by a daily update. You can trigger an update manually by visiting the connection configuration page in the Auth0 dashboard and doing a Save. If a certificate is changed at the remote IdP, Auth0 can be updated by those mechanisms or by uploading a new metadata file in the same connection configuration screen. + +## Disaster Recovery / Business Continuity Plan in place + +While not an absolute requirement prior to launch, it is useful to have a disaster recovery plan in place to ensure business continuity in the face of different types of disasters, including system outages and natural disasters hitting a region where critical staff is located. + +## Processes documented + +Another item which is not an absolute requirement, but also recommended is to ensure all processes related to Auth0 are documented. This can include the following: + +* Change management for configuration +* Deployment of new changes and any automatic deployment mechanisms used, how to revert to previous version if issues found +* Certificate rollover processes, if any +* Adding or removing new Identity Providers, if applicable +* Changes to user profile structure in Auth0 or in directories Auth0 pulls from +* Adding or removing applications or APIs +* Capturing and exporting logs +* Backup/restore process you have implemented +* User management (forgotten password, lost phone) +* Root cause analysis after an incident diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_support.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_support.md new file mode 100644 index 0000000000..3eea47b43a --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_support.md @@ -0,0 +1,61 @@ +## Review Auth0 Policies + +When starting to prepare for your launch, be sure to read through [Auth0 Policies](/policies) and prepare your production operations accordingly for any required lead times or responsibilities on your part, according to the policies. + +## Review your Support plan, SLAs, Severity definitions and Support center documentation + +You should review the specifics of the [support plan](/support#support-center) you’ve purchased and the [Service Level Agreements](/support#defect-responses) associated with it, to ensure it is adequate for your needs. If you haven’t already done so, explore the [support center](https://support.auth0.com/) and familiarize yourself with support features such as viewing suggested solutions to common issues and [filing tickets](/support/tickets) and viewing your quota usage. It will be helpful to review the [severity level definitions](/support#defect-resolution-procedures) for support tickets so that you file tickets with the correct severity. One important note is that it is not possible today in the Support Center to increase the severity of a support ticket. If you file a ticket for a medium-grade issue which later becomes a high severity issue, you should file a new urgent, high severity ticket that explains anything new that triggers the urgency and references the original ticket for details. + +You should also ensure your development and support teams are familiar with the [Auth0 community forum](https://community.auth0.com/), discussed further below. Customers can often find answers there right away to common issues, avoiding the need to file a ticket, so it should be your first stop for technical questions. + +## Review the Auth0 community forum + +The [Auth0 community forum](https://community.auth0.com/) contains a wealth of information. If you have a question, chances are someone else has already asked the question on the forum. Answers are contributed by both Auth0 staff and the larger community of Auth0 users. + +Important notices are posted to the community forum to help you stay abreast of important news. Be sure to check out the “Community” and “FAQ” categories. The Community category contains pro-active posts on product announcements, roadmap information, How-To videos as well as important information about any upcoming feature deprecations. + +It’s a good idea to check out the Auth0 Community on a regular basis, not just when you have questions. While you are there, if you see a question you’ve already solved, please contribute your wisdom to help others! + +## Gather Auth0 troubleshooting information needed for support tickets + +We recommend your support team become familiar with our [troubleshooting guides](/troubleshoot) specific to identity protocols and Auth0. This includes the questions to research and information to collect before posting a question on the Auth0 forum or filing a support ticket. Authentication transactions often span multiple systems so there are some specialized troubleshooting techniques that are helpful to learn. + +## Have troubleshooting tools ready + +Your team will doubtless have already done some troubleshooting during the development of your application, but we recommend making sure your support team is also familiar with any tools below relevant to your project. If you need to file a ticket, the Auth0 support team may ask for a HAR (HTTP Archive) file to help analyze the issue so it’s helpful for your support staff to be familiar with how to do this. + +### Capture HAR file + +A [HAR file](/troubleshoot/guides/generate-har-files) captures a sequence of browser interactions and is a commonly used tool when debugging authentication issues. The process of authenticating a user often involves redirecting the user’s browser from an application to Auth0, and possibly to another remote Identity Provider, depending on the type of connection used. You can capture the redirection and the responses and analyze it to find clues about the cause of an issue. + +### Analyze HAR file + +Analyze the [HAR file](/troubleshoot/guides/generate-har-files#analyze-har-files) to obtain valuable troubleshooting information. It shows the sequence of browser redirects involved in an authentication transaction, along with the parameters used. The HAR file also shows if the authentication process stopped mid-stream and if so where, which helps to pinpoint the location of the issue. The HAR file contains tokens returned to the application front-end, and these can be pasted into appropriate viewers to see if they contain the expected contents. + +### View JWT + +The [jwt.io](https://jwt.io) tool was written by Auth0 and allows you to view the contents of a JWT-formatted token. Applications that delegate authentication to Auth0 via OIDC will receive an ID Token from Auth0. Depending on your type of application, the ID Token may be captured in a HAR file. The ID Token is in JWT format and can be pasted into jwt.io to view the contents of the ID Token. + +### View SAML request/response + +There are many SAML decoders available. The [samltool.io](https://samltool.io) decoder was written by Auth0 and allows you to view the contents of a SAML Request or Response. Applications that delegate authentication to Auth0 via SAML or use a SAML type of connection in Auth0 will use SAML Requests and Responses. These SAML Requests and Responses may be captured in a HAR file. The requests and responses can be pasted into samltool.io or other SAML decoders to view the contents of the SAML Request or Response. + +## Review Auth0 support matrix + +One potential cause of issues is using out of date versions of SDKs or libraries. We strongly recommend your team check your software stack, browsers, SDKs and libraries against the [Auth0 support matrix](/support/matrix) to ensure you are running on up-to-date, supported versions. In the event of an issue, the Auth0 support team may ask you to upgrade to a supported version. To avoid slowing down progress on issue resolution, be sure you are on up-to-date versions. + +## Use Auth0 feedback portal + +Auth0 welcomes feedback and ideas from Auth0 customers. If you have a suggestion for our product team, you can submit product feedback directly on the [Product Feedback portal](https://auth0.com/feedback). + +## Prepare real-time webtask log extension + +For debugging and supporting custom code in Auth0, including Rules, Hooks, Custom DB Scripts, and Custom OAuth Connections, knowledge of the [Realtime Webtask Log](/extensions/realtime-webtask-logs) is essential. This enables you to view output from your custom code, including output from console.log statements. + +::: panel Best Practice +We recommend installing the real-time webtask log extension and getting familiar with using it to view log output from your custom code as a debugging and support tool. +::: + +## Troubleshooting + +You should prepare to [troubleshoot issues](/troubleshoot/basics) both during your development as well as after your application or API goes live. Make sure your development and support teams are prepared with knowledge of troubleshooting tools, and the list of common issues to check when troubleshooting an issue. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_tenant-check.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_tenant-check.md new file mode 100644 index 0000000000..2f9f2ce0d5 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_tenant-check.md @@ -0,0 +1,112 @@ +## Tenant Check + +This section covers a list of configurations to check in your tenant. This should be done periodically during development and sufficiently before launch so you have time to fix anything amiss. + +### General tenant check + +#### Tenant preparation check + +Check to ensure you have [set up tenant environments](/dev-lifecycle/setting-up-env) to support your SDLC lifecycle and that Dev, Test and Prod tenants are cleanly separated so that ongoing development work after launch doesn’t negatively impact your production environment. + +<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2c' }) %> + +#### Tenant association check + +<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2c' }) %> + +#### Specify production tenant + +To ensure Auth0 recognizes your production tenant, be sure to [set your production tenant](/dev-lifecycle/setting-up-env#set-the-environment +) with the “production” flag in the Support Center. + +#### Tenant production Check + +Auth0 provides a [Production Check](/pre-deployment) facility to detect many common errors. You should ensure this has been run and any findings from the report mitigated before launch. + +In addition, you should check the [best practice configurations advice](/pre-deployment/tests/best-practice), for which checking cannot be automated. + +#### Tenant Settings Check + +##### Tenant Settings + +Make sure to follow the [Auth0 tenant settings best practices](/best-practices/tenant-settings#set-up-branding-configuration) in configuring your logo as well as your support email and support URL so user's know how to get help if an issue occurs. You'll want to check your SSO Session Timeout settings and the list of dashboard admins with access to your production tenant as well. For further information on tenant setting, see the Auth0 dashboard [tenant settings documentation](/dashboard/dashboard-tenant-settings#settings). + +##### Error Page Customization + +<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2c' }) %> + +##### Legacy feature flags off + +If you have an older tenant, you may have various legacy feature flags enabled in your [tenant settings advanced tab](/dashboard/dashboard-tenant-settings#advanced). If you have any toggles on in the “Migrations” section of this tab, you should review your usage and make plans to migrate off the legacy feature. + +##### Delegated admin extension + +While you are checking the list of users with access to your production tenant, don't forget to check any users specified in the [Delegated Admin Extension](/extensions/delegated-admin/v3). + +#### Custom Domain Naming set up + +<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2c' }) %> + +### Application and Connection settings check + +Each of your application configurations in Auth0 should be checked against the [application configuration best practices](/best-practices/application-settings). + +Each of your connection settings should be reviewed against the [connection configuration best practices](/best-practices/connection-settings). + +In addition, you should review that all connections are appropriate and that no experimental connections are left in your production tenant as they could enable unauthorized access. + +If you use SAML connections, it is a best practice to configure the connections to sign SAML requests. + +### Page customization check + +If you use the Auth0 universal login page, password reset page, or Guardian multi-factor authentication, you should check that you have adequately customized the pages displayed to the end user. + +#### Universal Login Page + +<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2c' }) %> + +#### Password Reset Page customization + +<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2c' }) %> + +#### Guardian + +<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2c' }) %> + +### Authorization check + +If you are using Auth0’s [authorization feature](https://auth0.com/docs/authorization), be sure to double check all privileges granted to ensure authorizations are appropriate for your production environment. + +### API configuration check + +#### Access token expiration + +You should double check the [API access token expiration settings](/dashboard/reference/settings-api) to ensure they are appropriate for each API in your production environment. + +#### API offline access + +If your application does not request refresh tokens, this should be off. + +#### Access token signing algorithm + +It is recommended that the [API access token signing algorithm](/getting-started/set-up-api#signing-algorithms) be set to RS256 rather than HS256 to minimize exposure of the signing key. + +#### API Access token validation + +If you have any custom APIs, be sure to check that they are adequately [validating the access tokens](/api-auth/tutorials/verify-access-token) they receive before using the information in them. + +### API Scopes + +If you have applications making machine-to-machine calls to any of your APIs, you should review the scopes specified for the API to ensure they are all appropriate for your production environment. For further information see the documentation on [client credentials grant](/api-auth/config/using-the-auth0-dashboard). + +### Rules/Hooks check + +You should also have aligned your rules with Auth0 [rules best practices](/best-practices/rules). + +### Email templates customized + +<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2b' }) %> + +### Attack protection configured + +<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2b' }) %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_launch/_testing.md b/fr-ca/articles/architecture-scenarios/_includes/_launch/_testing.md new file mode 100644 index 0000000000..7ceb804ac1 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_launch/_testing.md @@ -0,0 +1,25 @@ +Prior to launch, you should have completed all the testing that applies to your environment. + +<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2c' }) %> + +### Unit testing + +<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2c' }) %> + +### Integration testing + +<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2c' }) %> + +### Mock Testing + +<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2c' }) %> + +### Pen testing (optional) + +If you will be conducting penetration tests, you should be aware of Auth0’s [penetration testing policy](/policies/penetration-testing) and abide by it. Penetration tests require advance notice to Auth0 so that your tests are not mistaken for malicious activity and shut down. + +### Load testing (optional) + +If you will be conducting load tests, you should be aware of Auth0’s [load testing policy](/policies/load-testing) and abide by it. Load tests require advance notice to Auth0. In planning your load testing, you will also need to be aware of Auth0’s [API rate limits](/policies/rate-limits). + +<%= include('../../_includes/_qa/_load-testing.md', { platform: 'b2c' }) %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_logout/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_logout/_introduction.md new file mode 100644 index 0000000000..08510e5ea8 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_logout/_introduction.md @@ -0,0 +1,47 @@ +[Logout](/logout) is the act of terminating an authenticated session when it's no longer needed, thus minimizing the likelihood that unauthorized parties can "take over" the session. This is typically achieved by provisioning a logout option on the user interface you provide to your users. Multiple types of sessions can be created when a user logs in (e.g., local application sessions, Auth0 session, third-party Identity Provider sessions), and you will need to determine which of these sessions need to be terminated when the user clicks any **Logout** option. + +::: panel Best Practice +Your logout behavior should make it clear to a user which session(s) are being terminated, and ideally, will display a visual confirmation of logout afterward. +::: + +When configuring logout behavior, you'll need to consider: + +* Which sessions should be terminated when the user initiates logout? +* What information should you provide to users as confirmation of the sessions terminated? +* Where should users be redirected to after logout completes? +* How long do you want sessions to last in the event that users do not trigger the logout process? +<% if (platform === "b2b") { %> +* Should the End User be logged out of all of their application sessions when they log out of one? +* Should the session with an organization's IDP also be terminated at logout? +<% } %> + +Given the varying types of sessions that can be created whenever a user logs in, there are several types of logout possible. Local application logout ends the session with the application, whereas Auth0 logout [terminates the Auth0 session](/logout/guides/logout-auth0). If you have organizations that are using their own IDP, you may want to consider a [Federated Logout](#federated-logout) strategy and implement accordingly. Global, or [Single Logout](/logout/guides/logout-applications) (SLO), ends the Auth0 session and also sends a logout request/notice to applications relying on the Auth0 session. + +The functionality provided by your application, as well as your use of features like [Single Sign-on (SSO)](/sso), will inform your decision as to what type of logout is required and what visual confirmation you'll need to provide to your users. Regardless of which option you choose, the logout process you implement should make it clear to the user which sessions are being terminated, and also when the logout process has completed. + +::: warning +If the logout feature in one application terminates an Auth0 SSO session that is used by other applications, the user may lose work if they have uncommitted transactions. Be sure to add the functionality needed to handle such conditions to minimize the likelihood of lost work. +::: + +<% if (platform === "b2b") { %> +In some situations, a user may be expected to logout of all associated applications when they log out of any one of the applications you provide. This is something that can add complexity. However if you have concerns that users could leave themselves vulnerable (perhaps due to data sensitivity or the like), then you will likely need to review [Single Logout](#single-logout) and implement accordingly. + +<% } %> + +## Where to send users after logout + +Once your user logs out, they will be redirected to a specific location of your choosing. This location is specified as the **logout redirect URL**, and you can [define this as a parameter](/logout/guides/redirect-users-after-logout) via the Auth0 Dashboard. + +The URL(s) you use to redirect users after logging out must be [whitelisted in the Dashboard](/logout#redirect-users-after-logout) to mitigate open-redirect security vulnerabilities. You can whitelist them at the tenant or application levels. + +::: note +If the user logs out and you redirect them back to the application, and the application redirects to an Identity Provider that still has a valid session for the user, the user will be logged in silently to the application. This may appear to the user as if the logout process didn't function properly. +::: + +## Automatic termination of sessions + +Not all users will trigger the logout process manually, so Auth0 also provides **session timeout** to prevent overly long-lived sessions. This setting is [available and configurable via the Auth0 Dashboard](/dashboard/reference/settings-tenant#login-session-management). + +::: panel Get Started with Auth0 Video +Watch this short video [Logout](/videos/get-started/10-logout) to learn about different kinds of logout behavior and different session layers. Learn how to configure callback URLs in the application and tenant settings in the Dashboard. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_multitenancy.md b/fr-ca/articles/architecture-scenarios/_includes/_multitenancy.md new file mode 100644 index 0000000000..50c06de00b --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_multitenancy.md @@ -0,0 +1,3 @@ +Many B2B platforms implement some form of isolation and/or branding for their customers' organization, and this can add complexity to any Identity and Access Management (IAM) system. If this applies to you, then we recommend you take some time to read through our guidance and best practice advice concerning this type of environment. + +Multiple Organization Architecture (Multitenancy) Overview diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_email-provider.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_email-provider.md new file mode 100644 index 0000000000..8f83e0bece --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_email-provider.md @@ -0,0 +1,5 @@ +Auth0 sends [emails](/email) to users for events such as signup welcome, email validation, breached password, and password reset events. You can customize the email templates for each type of event, and advanced customization of email handling is also possible. Auth0 provides a test email provider with limited capacity for basic testing, but you must set up your own email provider for production use, and customization of email templates will not work until you have established your own provider. + +::: panel Best Practice +The default Auth0 email provider does not support sending production volumes of email or customization of email templates. You should therefore configure your own email provider before deploying to production. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_infrastructure.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_infrastructure.md new file mode 100644 index 0000000000..540e16cd72 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_infrastructure.md @@ -0,0 +1,3 @@ +### Firewalls + +If custom code executing in Auth0 (such as in a Rule, Hook, or Custom DB scripts) will call a service inside your network, or if you configure an on-premise SMTP provider in Auth0, then you may need to configure your firewall to allow [inbound traffic from Auth0](/guides/ip-whitelist#inbound-calls). The IP addresses to allow through the firewall are specific to each region and are listed on the Rules, Hooks, Custom DB scripts, and email provider configuration screens in your Auth0 dashboard (as described in [Whitelist IP Addresses](/guides/ip-whitelist)). diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_introduction.md new file mode 100644 index 0000000000..33fb73bae3 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_introduction.md @@ -0,0 +1,29 @@ +Operationalization requires configuring or setting up infrastructure to support the scalable, measurable, and quantifiable operation that’s necessary for business continuity. In Auth0, this includes configuring supporting services (such as email providers), monitoring services for your deployment, detecting anomalous situations, and making preparations to recover quickly and smoothly when something goes wrong in a production environment. + +Establishing effective operational behaviors is something that successful customers have found pays dividends, and there are a number of things you will want to consider when looking at your workflow: + +* What should you do to proactively detect failures? +* How can you obtain data on Auth0’s operational status? +* What should you do about Auth0 security bulletins related to the Auth0 service? +* Does Auth0 provide information regarding impending changes in the Auth0 service? +* How can you check for important notices from Auth0? +* What should you do with Auth0 log data so that you can analyze it and keep it for longer than Auth0’s limited data retention period? +* How can you scan Auth0 logs to determine if peak loads in your application trigger any rate limits or other errors? +* What email services should you use to support production volumes of email messages to users? Can I use Auth0's out-of-box email provider in my production environment? +* Do you need to configure your firewall and what firewall ports will you need to open for internal services that need to receive communications from Auth0 (such as custom databases, web services, and email servers)? +<% if (platform === "b2b") { %> +* How will you provision new organizations? +* Do you need to provide self-service provisioning for your customer so that they can configure their own organizational IdPs? +<% } %> + +Auth0 supports functionality for [monitoring](#monitoring) Auth0 service operation as well as providing information regarding Auth0 [service status](#service-status). In addition, Auth0 makes security-related bulletins as well as information regarding upcoming changes to the Auth0 service available via various [notifications](#notifications). Auth0 [logging](#logging) services also provide extensive functionality for tracing and identifying operational anomalies, including restrictions encountered due to rate limiting and/or excessive loading. + +Out-of-box, Auth0 provides email delivery services to help you accelerate your integration. These services, however, are not meant for scale-of-use in production environments, and do not provide for any specific service level or guarantee when it comes to email delivery. Our best practice recommendation, which customers typically follow, involves configuring your own [email service provider](#email-provider-setup). + +You may also need to make changes to [infrastructure](#infrastructure) configuration in order to support integration with Auth0 and to support use of Auth0 extensibility. For example, if you need to provide callbacks to your internal or even external infrastructure (e.g., if you need to make external API calls in Rules or Hooks, or via custom database scripts if you need to leverage existing legacy identity storage), then you may need to configure your Firewall settings. + +<% if (platform === "b2b") { %> +Once you know how you want organizations to be represented in your system, you will want too consider how you are going to provision the organization itself. See [Provisioning organizations](#provisioning-organizations) for more information. + +In addition, many of our customers have developed one or more self-service portals for use by their customers' organization admins to provide self-service capabilities for configuring their own [IdPs](#self-service-idp-provisioning). +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_logging.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_logging.md new file mode 100644 index 0000000000..41ce91d599 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_logging.md @@ -0,0 +1,15 @@ +Auth0 provides extensive capability when it comes to the logging of events, and also in the scanning of logs in order to identify event anomalies (see [logs documentation](/logs) for further details). Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services will allow you to retain logs outside of this, and will also provide for log aggregation across your organization. + +::: panel Best Practice +You should leverage one of the Auth0 logs extensions to send log data to an external log analytics service. This will enable keeping data for longer periods of time and provide advanced analytics on the log data. +::: + +You should review the log data [retention period](/logs/references/log-data-retention) for your subscription level, and implement a log data export extension to send log data to an external log analytics service. Development teams can use log files for troubleshooting and detecting intermittent errors that may be hard to find via QA tests. Security teams will probably want log data in case forensic data is ever needed. Exporting log files to services that provide comprehensive analytics can help you see patterns such as usage trends and attack protection triggers. + +### Rate limits and other errors + +Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You should set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you will find it helpful to scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)). + +::: panel Best Practice +Calling the Management API to retrieve user profile information from within a Rule is a common cause of rate limit errors because such API calls can execute for every login as well as periodic session checks. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_monitoring.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_monitoring.md new file mode 100644 index 0000000000..d64277752e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_monitoring.md @@ -0,0 +1,5 @@ +You should establish mechanisms for [monitoring Auth0 implementations](/monitoring), so your support or operations team receives the timely information needed to proactively handle service outages. Auth0 provides monitoring endpoints that can be incorporated into your monitoring infrastructure. These endpoints are designed to provide a response suitable for consumption by monitoring services. It should be noted that they only provide data on Auth0. For complete end-to-end monitoring, which is essential for checking the ability of users to log in, we recommend that you set up synthetic transaction monitoring. This will provide greater granularity for your monitoring and enable you to detect outages unrelated to Auth0 as well as degradation of performance, so you can respond more proactively. + +::: panel Best Practice +You should set up the ability to send synthetic login transactions to facilitate end-to-end monitoring of authentication. You can do this with a simple application that uses the [Resource Owner Password Grant](/api-auth/tutorials/password-grant) in combination with a test user that has no privileges, and don’t forget about [Auth0 rate limiting policies](/policies/rate-limits) too. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_notifications.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_notifications.md new file mode 100644 index 0000000000..57dd93c1f9 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_notifications.md @@ -0,0 +1,21 @@ +There are several different types of notifications from Auth0 that you should watch for as they contain important information that could impact your tenant(s) and project. + +::: note +Proactive security notifications and other operational announcements are sent by Auth0 to dashboard administrators. You should ensure that the people who need to receive such messages are dashboard administrators. +::: + +### Dashboard notifications + +From time to time, Auth0 may send an important announcement related to your tenant. These announcements about your service will be sent to your Auth0 dashboard and depending on the severity of the announcement, via email to the registered Auth0 dashboard administrators. You should make a regular practice of logging in to the dashboard and checking the bell icon at the top for any important notices. In addition, you should review emails from Auth0 in a timely fashion as they may convey important information about changes or actions you need to take. + +### Auth0 security bulletins + +Auth0 regularly conducts a number of security-related tests, and if any issues are found, will proactively identify and notify customers who need to make security-related changes. Due to the extensible nature of the Auth0 product, however, it may not be possible for Auth0 to identify every impacted customer, so you should regularly check Auth0 [security bulletins](/security/bulletins). You should make sure a security contact for your organization is listed in Support Center. + +::: panel Best Practice +It is a best practice to check the Auth0 [Security Bulletins](/security/bulletins) page periodically and take the recommended action if you are impacted by any security bulletins. +::: + +### Change log + +Auth0 provides information on changes to the service in the Auth0 [change log](https://auth0.com/changelog). You should make a regular practice of reviewing Auth0 change logs to be aware of changes. Support teams researching an issue may find it useful to review the change log to determine if recent changes might be related, especially if these are [breaking changes](/migrations). Development teams will also want to review the change logs to identify new features that may be beneficial. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_operations/_service-status.md b/fr-ca/articles/architecture-scenarios/_includes/_operations/_service-status.md new file mode 100644 index 0000000000..a42bdbd948 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_operations/_service-status.md @@ -0,0 +1,7 @@ +The Auth0 [status dashboard](https://status.auth0.com/) together with the Auth0 [uptime dashboard](http://uptime.auth0.com/) shows current and past status of the Auth0 service in a human-readable format. If any monitoring alerts are triggered, and as a first step in troubleshooting, your operations staff should check the status dashboard to see if there is a current outage. The public cloud status page also provides a facility for subscribing to outage notifications, and we also recommend that you check the status of any 3rd party, [external services](/monitoring/guides/check-external-services) you depend on - such as Social Providers. Having this information handy can help quickly eliminate possible causes when troubleshooting an issue and should be at the top of a troubleshooting checklist for developers as well as the helpdesk staff. + +::: panel Best Practice +Information on how to check the status of Auth0 as well as any dependent services (such as Social Providers) should be at the top of a troubleshooting checklist for both developers and helpdesk staff, and we recommend you subscribe via the Auth0 status page to set up notification of any status updates. +::: + +In the event of an outage to the public cloud service, Auth0 performs a Root Cause Analysis (RCA) and publishes the results on the [Auth0 status page](/support#auth0-status). Auth0 performs a thorough investigation after an outage--including a determination of root cause, as well as contributing factors and how to prevent the issue from occurring again--and as a result, an RCA document can take a few weeks to be published. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_planning.md b/fr-ca/articles/architecture-scenarios/_includes/_planning.md new file mode 100644 index 0000000000..8ad9191355 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_planning.md @@ -0,0 +1,9 @@ +We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies. + +<% if (platform === "b2b") { %> +B2B IAM Project Planning Guide +<% } %> + +<% if (platform === "b2c") { %> +B2C IAM Project Planning Guide +<% } %> diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md new file mode 100644 index 0000000000..0306b71049 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md @@ -0,0 +1,3 @@ +You’ll also need to work with a verified user account at all times and make use of the mechanisms Auth0 provides. You should also consider regulatory compliance like [GDPR](https://eugdpr.org/) which has very specific requirements for protecting EU citizens from privacy and data breaches. + +Auth0 provides out-of-box functionality for sending a [verification email](/email/custom#verification-email) to a user's email address to verify their account. By default, Auth0 automatically sends verification emails for any [Database Connection](/connections/database) identity created as part of [self sign-up](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#self-sign-up). However, Auth0 also provides a [Management API endpoint](/api/v2#!/Tickets/post_email_verification) that you can use to send verification emails in cases where email address validation is not performed by a Social Provider upon user registration. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md new file mode 100644 index 0000000000..d66954e4a6 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md @@ -0,0 +1,3 @@ +[Blocking user access](/users/guides/block-and-unblock-users) in Auth0 provides a way to prevent user login to applications under certain conditions. By default, the Auth0 Dashboard provides an out-of-the-box mechanism to give administrators the ability to both block and unblock user access to all applications, and you can implement this functionality via use of the [Auth0 Management API](/api/management/v2#!/Users/patch_users_by_id). You can also use Auth0 extensibility to [disable user access to certain applications](/users/guides/manage-user-access-to-applications) as well as provide more fine-grained [access control](/architecture-scenarios/implementation/${platform}/${platform}-authorization). + +In addition, the Auth0 Management API provides you with the ability to [unblock](/api/management/v2#!/User_Blocks/delete_user_blocks_by_id) users disabled due to excessive use of incorrect credentials. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md new file mode 100644 index 0000000000..cfbccfab6c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md @@ -0,0 +1,7 @@ +Your application may need to support a user’s request to remove their account (for example, you might need to meet [GDPR](https://eugdpr.org/) requirements). You can implement such a feature, along with a number of other profile-related functions, using the [Management API](/api/management/v2#!/Users). The Management API allows you to retrieve information stored about a user and update it as required. + +Auth0 is capable of supporting various privacy-related requirements including the display of links to consent notices on signup and data protection to support the rights of users to view and correct data you’ve collected about them. + +::: note +[GDPR](https://eugdpr.org/) and other privacy directives require that users have the right to view and correct data held about them. They also have the right to be “forgotten.” You can use the Management API to address these requirements and meet your legislative obligations. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md new file mode 100644 index 0000000000..d0098b386d --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md @@ -0,0 +1,49 @@ +At some point, you may need to change the information stored in a user’s [profile](/users/concepts/overview-user-profile). A user’s profile (also known as the user’s account) is stored in Auth0, and changes to the information it contains may need to happen for a number of different reasons: + +* Self-served information updates +* Mandatory updates concerning your organizations T's & C’s +* Changes due to regulatory compliance + +::: warning +You cannot directly access a user profile across multiple Auth0 tenants. If you’re deploying multiple Auth0 tenants to production then this is something you need to be aware of. +::: + +An [Identity Provider](/identityproviders) populates a user’s profile using data supplied during the login process, and this is referred to as the [Normalized User Profile](/users/normalized/auth0). + +::: note +The Normalized User Profile is updated from the identity provider during login, and you can change the limited set of the information it contains through the Auth0 Management API. You can also use Auth0 extensibility, such as [Rules](/rules), as an alternative to override information in the Normalized User Profile. See [User Profile Data Modification](/users/concepts/overview-user-profile#user-profile-data-modification) for more information. +::: + +By default, there is one user profile created for each user identity, and there are a number of things to consider: + +* What should you do if you need to store information to help customize a user’s experience? +* What if you need to store user information that didn’t originate from an identity provider? +* Why would you need to store user-related information that a user cannot modify? +* What do you do if you need to store user-related information that a user cannot modify? +* What happens if a user forgets their password? +* What should a user do if they want to change their password? +<% if (platform === "b2b") { %> +* How do you provide an administrator from a third-party organization with the ability to manage their users? +<% } %> + +Auth0 provides for the storage of [Metadata](#metadata) against a user’s profile, which allows for the capture of additional information, such as preference for language and/or accessibility in order to enhance the user experience. Metadata can be used to store both information that a user can change, and also information they can’t; the latter giving you the capability of associating, for example, a user profile with records in your existing systems without modifying existing implementation. + +For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism (or self-service mechanism you have planned), you can leverage Auth0-provided [Password Reset](#password-reset) functionality. This can be integrated with your existing implementation and comes already incorporated with any out-of-box Auth0 UI widgets including [Universal Login](/universal-login). + +You’ll also want to make sure that you are working with a [verified user account](#account-verification) at all times. Auth0 provides out-of-box mechanisms for doing that too. You should also consider [regulatory compliance](/compliance) such as ([GDPR](https://eugdpr.org/) which has very specific requirements when it comes to protecting EU citizens from privacy and data breaches. + +Though Auth0 doesn’t currently provide a centralized profile management portal out-of-the-box, for the purpose of self-serviced profile management, you can use the Auth0 Management API to build your own or utilize an already built UI. See our Auth0 [community guidance](https://community.auth0.com/t/how-to-allow-the-end-user-to-update-their-own-profile-information/6228)which describes the Management API endpoint. All calls to the Management API will require use of an [Access Token](/tokens/concepts/access-tokens). + +::: warning +Self-service profile management can raise security as well as data privacy concerns. For example, you may want to allow a user to change their email address, however, doing so without following best practice security guidance could result in a user locking themselves out of their account, leaking Personally Identifiable Information (PII), or worse, opening up a potential breach in security. +::: + +Alternatively, you can use the Auth0 Dashboard to [manage aspects of a user’s profile](users/guides/manage-users-using-the-dashboard). Managing a user’s profile via the Auth0 Dashboard is more of an administrative provision and **should not** be used for self-serviced profile management in a production environment. However, the interface provided by the Dashboard can be extremely useful during development as it provides a quick and simple way of manipulating a user’s profile information. + +<% if (platform === "b2b") { %> +If you need to provide a way for your customers to have an administrator manage their own users when they are storing those credentials in your system, you can either build something yourself or use an Auth0 Extension. See [Admin Portal](#admin-portal) for more information. +<% } %> + +::: panel Get Started with Auth0 Video +Watch this video [User Profiles](/videos/get-started/06-user-profiles) to learn what Auth0 User Profiles are used for and what they contain. Understand how Auth0 normalizes user profile data from various identity providers and uses metadata and root attributes. You can manage user profiles with the Auth0 Dashboard. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md new file mode 100644 index 0000000000..572f16a38e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md @@ -0,0 +1,9 @@ +By default, there is one [user profile](/users/concepts/overview-user-profile) (user account) for each user identity. If you enable login from multiple identity providers - via Facebook or Google [social authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#social-authentication) as well as via Auth0 [username and password authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#username-and-password-authentication) - then each will have a separate user profile. You can use Auth0’s functionality for [linking user accounts](/users/concepts/overview-user-account-linking) to create one profile for a user as an aggregate of all their associated identities. + +The process of linking accounts merges user profiles in pairs: a primary account and a secondary account must be specified in the linking process. The number of accounts that can be linked, however, extends beyond a single pair. For example, you can use an account which already has multiple accounts merged with it as the primary, and link an additional secondary account to it. This means that one user account can have multiple identities associated with it, which provides a number of advantages: + +* Users can log in using multiple identities without creating a separate profile for each one. +* Registered users can use new login identities, but continue using their existing profile. +* Users can carry their profile around, irrespective of which identity they use for login. +* Users can link to an account with more identity information in order to provide a more complete profile. +* Your applications can retrieve connection-specific user profile data. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md new file mode 100644 index 0000000000..8fe125d585 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md @@ -0,0 +1,23 @@ +In addition to the Normalized User Profile information, [Metadata](/users/concepts/overview-user-metadata) can be stored in an Auth0 user profile. Metadata provides a way to store information that did not originate from an identity provider, or a way to store information that overrides what an identity provider supplies. + +::: panel Best Practice +Use of Metadata should follow Auth0 [user data storage best practices](/best-practices/user-data-storage-best-practices#metadata). Metadata storage is not designed to be a general purpose data store, and you should still use your own external storage facility when possible. Metadata size and complexity should also be kept to a minimum, and the Auth0 Management API has a strict set of guidance when it comes to updating and/or deleting metadata associated with a user. +::: + +You can manipulate metadata via both the Auth0 Management API and the Auth0 Authentication API. See [Manage User Metadata](/users/guides/manage-user-metadata) for more information. As is the case when managing the Normalized User Profile, calls to the Management API for manipulating Metadata requires use of an [Access Token](api/management/v2/tokens). + +::: warning +<%= include('../../_includes/_rate-limit-policy.md') %> +::: + +### User metadata + +User metadata (also referred to as `user_metadata`) is information that can be stored against a user profile and that a user can read and update as part of any self-service profile management. Metadata of this nature may be something like salutation for a user, or a user’s preferred language which could be used to [customize the emails](/email/templates#common-variables) sent by Auth0. + +::: panel Best Practice +Store any information that you want use to customize Auth0 emails in metadata and preferably `user_metadata` if the user is allowed to change it, such as information used to determine the language for an email. +::: + +### App metadata + +App metadata (also referred to as `app_metadata`) is, on the other hand, information that can be stored with a user profile but can **only be read or updated with appropriate authorization**; `app_metadata` is not directly accessible to a user. This type of metadata could be something like a flag to indicate that the last set of valid terms and conditions was accepted by the user, and a date to indicate when the user accepted them. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md new file mode 100644 index 0000000000..0407264659 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md @@ -0,0 +1,9 @@ +For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism, Auth0 provides [Password Reset](/connections/database/password-change) functionality. You can integrate this with your existing implementation and comes already incorporated with out-of-the-box Auth0 UI widgets included as part of [Universal Login](/universal-login). + +::: warning +Password change and password reset is only supported for Auth0 [Database Connection](/connections/database) types. +::: + +Auth0 Universal Login provides built-in UX support for password reset using Auth0 Authentication API functionality. Alternatively, you can use the [Auth0 Authentication API](/connections/database/password-change#use-the-authentication-api), through one of the Auth0 SDKs appropriate to your development environment. Email templates used during password reset workflow can also be fully customized, whether you use Auth0 out-of-box UI widgets or customized Universal Login. + +You can use the Auth0 Management API, on the other hand, to [directly change the password](/connections/database/password-change#directly-set-the-new-password) for a user identity defined using a Database Connection type. You can use the Auth0 Management API as part of any self-service profile management implementation, and also as part of any [Change Password page customization](/architecture-scenarios/implementation/${platform}/${platform}-branding#change-password-page-customization). diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md new file mode 100644 index 0000000000..5571357acc --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md @@ -0,0 +1 @@ +Auth0 will *not* communicate with the upstream IdP if there is an active SSO session with Auth0, unless you force it with a `prompt=login`. If one of your customer organizations can not manage logout for those users, they may still have access after they’ve been decommissioned. Depending on the IdP, if Auth0 gets a token for their API, you can request information about the user from the IdP in a [rule](/rules) to poll whether that user should still have access or not. If you don’t have this ability, you will have to provide your customer organizations a way to trigger a block or decommission of users in your system either through an API call or a UI. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_introduction.md new file mode 100644 index 0000000000..4a6ec7c089 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_introduction.md @@ -0,0 +1,33 @@ +Determining how users get signed up is important to address early, and the decisions you make here will influence many of the decisions you will need to make going forward. We’ve found there are a typical set of patterns for how users will get added to your system, and things to take note of when considering workflow design too. + +::: panel Best Practice +Whilst Auth0 supports numerous workflows, web based workflows using Auth0 [Universal Login](/universal-login) for sign up are considered both industry and Auth0 best practice as they provide for optimal functionality and the best security. +::: + +Auth0 supports user sign up via a number of different [identity providers](/identityproviders). During sign up, Auth0 provisions the [user profile](/users/concepts/overview-user-profile) so that it contains the user’s account information. There are a number of things to consider when looking at functionality and workflow: + +<% if (platform==="b2b") { %> +* Does a user get added to your company's domain or do they belong to or remain in their organization's domain? +* If the user stays in their own domain, do they belong to a single organization or can they belong to multiple organizations? +* How do you provision the organization itself in your system? +<% } %> +* Should you use Auth0 as an identity store? +* Can you use your own (legacy) identity store with Auth0? +* How do you migrate user identities from your identity store to Auth0? +<% if (platform==="b2c") { %> +* Can your users sign up using their existing social accounts such as Google and Facebook? +<% } %> +<% if (platform==="b2b") { %> +* Can your users sign up using their organization's identity provider? +* Can your users be invited or self register? + +One of the first determinations to make when providing your service(s) to other businesses is identifying to which domain users belong. Based on the answer to that question, there are a couple of different approaches you can take to provision those users. See [Provisioning organization users](#provisioning-organization-users) for more information. Once you know how you want organizations to be represented in your system, you will want too consider how you are going to provision the organization itself. See [Provisioning organizations](#provisioning-organizations) for more information. +<% } %> + +Auth0 provides out-of-the-box identity storage that can be leveraged to store user credentials safely and securely. See [Self Sign Up](#self-sign-up) for more information. If you already have a legacy identity store and you want to offload the management of it, then the [User Migration](#user-migration) capabilities provide you with a number of options to do so. + +Alternatively, if you have to maintain your legacy identity store - perhaps because you’ve got applications which you aren’t ready to migrate or which can’t be migrated - then you can use the [identity store proxy](#identity-store-proxy) capability. Allowing your customers to use “bring their own identity” is also an attractive proposition and though we find our customers don’t initially do so, you can use the [Social Sign Up](#social-sign-up) capability to provide it. + +::: panel Get Started with Auth0 Videos +Watch these two short videos [Provision: Users Stores](/videos/get-started/02-provision-user-stores) and [Provision: Import Users](/videos/get-started/03-provision-import-users) to learn how user profiles are provisioned within an Auth0 tenant and how Auth0 allows you to move your existing users to an Auth0 user store. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_organizations.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_organizations.md new file mode 100644 index 0000000000..7dd959ad2c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_organizations.md @@ -0,0 +1,30 @@ +::: panel best practice +What you need to do when provisioning an organization will depend on how organizations are represented in your system. This can take some time to step back and consider how users of those organizations will be interacting with your applications. See [Multiple Organization Architecture](/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf) to determine how to configure organizations for your IAM system. +::: + +When provisioning organizations you need to consider the following: + +* You will need to add the organization to your own application configuration and/or database +* You will need to make changes to your Auth0 configuration. This will include doing some or all of the following: + * Create a unique tenant + * Add a database connection (if you have isolated users per organization) + * Add an enterprise connection for this organization + * This will include working with the organization to either update their existing configuration or add configuration for your Auth0 tenant if they are not a legacy organization. + * Provision an administrator for the organization +* To avoid mistakes, you may want to create an [Organization Admin Portal](#organization-admin-portal) to make it easier to provision new organizations. + +### Organization Admin Portal +An organization admin portal is a portal that allows your administrators to create, modify, and remove organizations. There are multiple activities that need to be done both in your own system and your Auth0 tenant. This portal will likely need to exist in your own system so it has access to your datastores and configuration. However, Auth0 provides the [**Auth0 Management API**](/api/management/v2) so that you can incorporate changes to your Auth0 tenant at the same time that you create the changes in your own system. + +There are two main approaches that can be taken for creating a new organization. The one you choose depends highly on your tolerance for how long it would take to deploy a new organization. +* **Live Updates to your Auth0 Tenant**: If you want to be able to create new organizations in real-time, then you will likely want to make the changes directly to your Auth0 tenant using the Auth0 Management API. This allows the changes to take place in real-time and allow the addition of a new organization to take effect immediately. + +::: warning + Live Updates do come with some things to consider. There are certain operations that must be done in serial to avoid issues. Enabling clients on a connection, adding callback URL's to an Application are two examples. Any operation in the Management API where you must retrieve an entire list and re-submit the entire list with the new value added to it are operations that must be done in serial to avoid two parallel operations overwriting one of the values. +::: + +* **Change the Repository and Re-deploy**: If you are taking advantage of the Deploy CLI (or a custom CLI) as part of your [CI/CD pipeline]( /architecture-scenarios/implementation/${platform}/${platform}-deployment), you may prefer to push your changes directly to your repository and then kickoff a new deployment instead. This can take a little more time, but it has benefits associated with version history and the ability to backout a change by re-deploying the previous version. + +::: panel Best Practice +You may want to have a separate repository just for the items that the organizations need so that you don't have to re-deploy other common components and risk making an error. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md new file mode 100644 index 0000000000..6799c34345 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md @@ -0,0 +1,5 @@ +Self sign up leverages Auth0 [Database Connections](/connections/database) to store the user ID, password, and (optional) username identity information collected from new users during the sign up process. Database connection policies governing things such as minimum [username length](connections/database/require-username#username-length) or [password strength and complexity](/connections/database/password-options) can be configured via the Auth0 Dashboard. + +::: panel Best Practice +Auth0 [Universal Login](/universal-login) as well Auth0 widgets such as [Lock](https://auth0.com/lock) integrate with Database Connections to provide comprehensive user interface functionality for sign up out-of-the-box. These UI artifacts are fully reactive, and with feature rich configuration and comprehensive customization, you can deploy functionality for user self sign up as well as login. +::: diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md new file mode 100644 index 0000000000..c581a3e097 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md @@ -0,0 +1 @@ +Social signup is synonymous with sign in via [social authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#social-authentication) - there’s no distinction here *per se*, as user [profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt) creation happens automatically upon first social login. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md new file mode 100644 index 0000000000..fea6aca40e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md @@ -0,0 +1,17 @@ +In addition to hosting the [User Profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt), Auth0 also has the capability to both [proxy](#identity-store-proxy) your own legacy identity store and provide a secure Auth0 hosted replacement. Both of these capabilities are supported via the use of Auth0 [Database Connections](/identityproviders#database-and-custom-connections). If you decide to use Auth0 as a replacement for your legacy identity store then you can migrate users either all at once with [Bulk Migration](users/concepts/overview-user-migration#bulk-user-imports-with-the-management-api), or progressively with [Automatic Migration](users/concepts/overview-user-migration#automatic-migrations). + +::: panel Best Practice +Customers often opt for a two-stage approach to user migration, using Automatic Migration first to migrate as many users as possible, then using Bulk Migration for the users that remain. See [User Migration Scenarios](users/references/user-migration-scenarios) for more information. +::: + +Automatic Migration is preferred as it allows users to be migrated individually and also allows them to retain their existing password in almost all situations. For Bulk Migration, we recommend using the [Management API](api/management/v2#!/Jobs/post_users_imports) over the [User Import/Export extension](/users/concepts/overview-user-migration#migrate-users-with-the-user-import-export-extension) in all but the most simple cases, as the Management API provides for greater flexibility and control. + +With Bulk Migration users typically need to **reset their password once migration is complete**, _unless_ passwords are stored hashed in your legacy identity store using bcrypt (or you can generate them in bcrypt form). In this case, you _may_ be able to use bulk migration and **preserve user passwords** as part of the process, depending on the bcrypt algorithm and the number of salt rounds used. See [Bulk Import Database Schema Examples](/users/references/bulk-import-database-schema-examples) for more information. + +::: panel Best Practice +<%= include('../../_includes/_rate-limit-policy.md') %> +::: + +### Identity store proxy + +Auth0 Database Connection types can also be configured to proxy an existing (legacy) identity store. If you need to keep user identities defined in your own legacy store - for example, if you have one or more business critical applications that you can’t migrate to Auth0, but which still need access to these identities - then you can easily integrate with Auth0. See [Authenticate Users Using Your Database](/connections/database/custom-db) for more information. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_qa/_integration-testing.md b/fr-ca/articles/architecture-scenarios/_includes/_qa/_integration-testing.md new file mode 100644 index 0000000000..629c1f9d99 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_qa/_integration-testing.md @@ -0,0 +1,13 @@ +It is a recommended best practice that you set up different tenants for development, testing, and production as discussed in Architecture guidance for [SDLC support](architecture-scenarios/implementation/${platform}/${platform}-architecture#sdlc-support). Auth0 allows you to configure variables that are available from within custom [extensibility](/topics/extensibility); these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time: + +* For use of variables in Rules, see how to [configure values](/rules/guides/configuration#configure-values) +* For use of variables in Hooks, see how to configure [secrets](/hooks/secrets) in the editor +* For use of variables in Custom DB Scripts, see the [configuration parameters](/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters) + +::: panel Best Practice +It’s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub, then using a tenant-specific variable avoids exposure of sensitive values via your GitHub repository. +::: + +### Test automation + +You can automate your overall build process by incorporating deployment automation as well as test automation. This can be used to deploy new versions of configuration and/or custom code to Auth0 and execute automated tests. If the tests uncover any failures, the deployment automation capabilities can be used to revert to the last working version. For further information, see the [deployment automation guidance](/architecture-scenarios/implementation/${platform}/${platform}-deployment) provided. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_qa/_introduction.md b/fr-ca/articles/architecture-scenarios/_includes/_qa/_introduction.md new file mode 100644 index 0000000000..9f423218bc --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_qa/_introduction.md @@ -0,0 +1,11 @@ +Quality Assurance is important in identifying issues before they impact your customers and, depending on the nature of your project, there are several different types of quality assurance testing that you’re going to want to consider as part of your integration with Auth0: + +* Is your application easy to understand and use, even by those with a disability? +* Does your application need to work across various different browsers and devices? +* Does your application need to work in multinational and/or international environments? +* How will your application perform when subjected to unexpected production loads? +* How can you ensure your application is safe from security-related vulnerabilities? + +Auth0 [Universal Login](/universal-login) and associated UI widgets (such as [Lock](/libraries/lock)) have already been designed and built following usability and accessibility best practices, and provide tested out-of-box support for a whole host of [browsers and devices](/support/matrix#browsers). Support for [internationalization](/i18n) (I18N) is also provided out-of-box, with built-in extensibility designed for custom multi-language and localization (L10N) situations. + +To ensure functional requirements are met and unexpected events are handled correctly, guidance is provided for testing the [integration](#integration-testing) between your application(s) and Auth0, and for [unit testing](#unit-testing) individual extensibility modules (such as [Rules](/rules/guides/debug#try-this-rule), [Hooks](/hooks/update), and Custom Database scripts). Guidance is also provided regarding Auth0's [penetration testing policy](/policies/penetration-testing) to help when testing for security vulnerability, and also how [Mock](#mock-testing) testing can be leveraged in conjunction with our [load testing policy](/policies/load-testing) to help ensure your application(s) perform under unexpected load. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_qa/_load-testing.md b/fr-ca/articles/architecture-scenarios/_includes/_qa/_load-testing.md new file mode 100644 index 0000000000..1761e56882 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_qa/_load-testing.md @@ -0,0 +1,15 @@ +Load tests require prior approval from Auth0, as explained in the Auth0 [load test policy](/policies/load-testing). Be sure to note the lead time for a request to be reviewed and allow enough time for review as well as conducting the tests. If your load test request has been approved, the following guidance can help avoid errors and faulty test results. + +* Run an HTTP trace on a test execution of your application to identify all the calls your application or intended test needs to make, and make sure your test includes them so it is representative of what will happen in production. +* Design your test to be mindful of Auth0 API rate limits. +* Use of any custom code in Auth0 (Rules, Custom DB scripts, Hooks, Custom OAuth connections) will invoke the Auth0 custom code sandbox and this may cost more in terms of performance. Turn off Rules unless they are essential to the test. If they are off you will have higher throughput than if they are on. +* Estimate the expected overall load for your production environment and percent of calls to each endpoint and structure your performance test accordingly so it gives you a realistic test result. Different endpoints have different performance costs. Failure to design a representative test will result in misleading results. +* Don’t make calls that depend on the results of earlier calls without checking that pre-requisite calls or responses have completed. Simply building in a delay may not be adequate. +* Be sure to implement adequate error handling. A frequent cause of issues during tests is errors in custom code (rules, hooks, Custom db scripts, Custom OAuth connection scripts) caused by unhandled exceptions in the custom code. +* Load tests should be written to start at a low level and increase the load gradually, capturing data at each level, to get the most useful results. Starting at a high level and immediately failing gives less information about what the system can sustain. +* It is normal to need to run a performance test multiple times, possibly adjusting the code under test or the test harness/configuration. Be sure to start your testing early to allow enough time for more than one iteration. +* Use your own mail provider account and make sure to arrange ahead of time for enough mail-sending quota or you may be rate-limited by the mail provider. Turn off mail sending if you do not use it. +* Be sure to use your own account credentials for all social connections rather than Auth0 dev keys. In the Auth0 dashboard, go to Connections -> Social -> {name of connection} - to see instructions for how to add your own social provider account credentials into the connection. +Note: some social providers do not allow load testing. Check your provider(s) for their policy +* In order to avoid rate limiting, and more accurately simulate real load, your tests will need to send requests for different users, not all requests for the same user. If you use only one or a few users, caching may reduce the effective load and not provide realistic results. +* Be sure to stay within the agreed-upon parameters for the test and the Auth0 [load test policy](/policies/load-testing). Auth0 reserves the right to terminate any performance/load testing which does not stay within the bounds of agreed-upon parameters or which extends beyond the scheduled test window. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_qa/_mock-testing.md b/fr-ca/articles/architecture-scenarios/_includes/_qa/_mock-testing.md new file mode 100644 index 0000000000..786ee3b346 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_qa/_mock-testing.md @@ -0,0 +1 @@ +In a balance between Auth0’s [load testing policy](/policies/load-testing) and the desire to load test, it is common practice among Auth0’s customers to mock out Auth0’s endpoints. This is a valuable practice in order to ensure that your application works with your expected interfaces without having to restrict your testing, and tools such as [MockServer](http://www.mock-server.com/), [JSON Server](https://github.com/typicode/json-server) or even [Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/) can be used to assist. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_qa/_unit-testing.md b/fr-ca/articles/architecture-scenarios/_includes/_qa/_unit-testing.md new file mode 100644 index 0000000000..a8ebd23233 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_qa/_unit-testing.md @@ -0,0 +1 @@ +The objective of unit testing is to test individual units of code. If you create custom code within Auth0 in the form of Rules, Hooks, and/or Custom DB scripts, you should consider use a testing framework (such as [Mocha](https://mochajs.org/)) to test your code. Companies who have been most successful with Auth0 have found it useful to execute these unit tests prior to [automatically deploying](/architecture-scenarios/implementation/${platform}/${platform}-deployment) Auth0 tenant configuration and collateral. diff --git a/fr-ca/articles/architecture-scenarios/_includes/_rate-limit-policy.md b/fr-ca/articles/architecture-scenarios/_includes/_rate-limit-policy.md new file mode 100644 index 0000000000..ce743cf61d --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/_includes/_rate-limit-policy.md @@ -0,0 +1 @@ +Calls to the Management API are subject to [Auth0 Rate Limiting policy](/policies/rate-limits). You must take this into consideration, and to assist, Auth0 generally recommends use of the appropriate [Auth0 SDK](/libraries) for your development environment rather than calling our APIs directly. diff --git a/fr-ca/articles/architecture-scenarios/b2b-b2e.md b/fr-ca/articles/architecture-scenarios/b2b-b2e.md new file mode 100644 index 0000000000..590a1cea72 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/b2b-b2e.md @@ -0,0 +1,44 @@ +--- +order: 07 +title: Business to Business + Employees Identity Scenarios +image: /media/articles/architecture-scenarios/b2b-b2e.png +extract: This is essentially a hybrid between B2B and B2E where you have a larger SAAS application, like Zendesk for example, where users are grouped into companies. +description: Explains the architecture scenario of a hybrid between B2B and B2E where you have a larger SAAS application. +beta: true +topics: + - b2b + - b2e + - architecture + - lockjs + - saml + - active-directory + - social-connections +contentType: concept +useCase: + - invoke-api + - secure-an-api + - build-an-app +--- + +# Business to Business + Employees Identity Scenarios + +::: note +This architecture scenario is under construction and will be updated soon. +::: + +![](/media/articles/architecture-scenarios/b2b-b2e.png) + +This is essentially a hybrid between B2B and B2E for larger SAAS applications (such as Zendesk). In a situation like this, users would primarily be grouped into companies, but you may also have internal users (employees) who log into perform support or administrative tasks. Those internal users will typically use federated identity to authenticate. + +## Read More + +The following is a list of articles on this website which will help you to implement this scenario: + +* [Lock](https://auth0.com/lock) +* [Protocols supported by Auth0](/protocols) +* [Connect Active Directory with Auth0](/connections/enterprise/active-directory-ldap) +* [SAML](/saml-configuration) +* [Using Auth0 in SaaS, multi-tenant Apps](/saas-apps) +* [Identity Providers supported by Auth0](/identityproviders) +* [Social Login](https://auth0.com/learn/social-login/) +* [Auth0 SSO Dashboard (sample)](https://github.com/auth0-samples/auth0-sso-dashboard) diff --git a/fr-ca/articles/architecture-scenarios/b2b.md b/fr-ca/articles/architecture-scenarios/b2b.md new file mode 100644 index 0000000000..ec33e404f6 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/b2b.md @@ -0,0 +1,52 @@ +--- +url: /architecture-scenarios/b2b +classes: topic-page +title: Business to Business Identity and Access Management +description: Explains the architecture scenario B2B IAM with a SAAS application. +topics: + - b2b + - b2biam + - SDLC +contentType: index +useCase: + - implementation +--- + +
+
+

Business to Business Identity and Access Management

+

+ This guidance is relevant to all project stakeholders. We recommend reading it in its entirety at least once, even if you've already started your journey with Auth0. We provide a Project Planning Guide in PDF format, details about how to get started with each phase of the implementation process, and checklists to help you manage the tasks in each phase. +

+
+ +<%= include('./_includes/_base-ways-to-integrate.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('./_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('./_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Get started + +<%= include('./_includes/_base-intro.md', { platform: 'b2b' }) %> + +<%= include('../_includes/_topic-links', { links: [ + 'architecture-scenarios/implementation/b2b/b2b-architecture', + 'architecture-scenarios/implementation/b2b/b2b-provisioning', + 'architecture-scenarios/implementation/b2b/b2b-authentication', + 'architecture-scenarios/implementation/b2b/b2b-branding', + 'architecture-scenarios/implementation/b2b/b2b-deployment', + 'architecture-scenarios/implementation/b2b/b2b-qa', + 'architecture-scenarios/implementation/b2b/b2b-profile-mgmt', + 'architecture-scenarios/implementation/b2b/b2b-authorization', + 'architecture-scenarios/implementation/b2b/b2b-logout', + 'architecture-scenarios/implementation/b2b/b2b-operations' +] }) %> + +## Implementation planning checklists + +<%= include('./_includes/_implementation-checklists.md') %> diff --git a/fr-ca/articles/architecture-scenarios/b2c.md b/fr-ca/articles/architecture-scenarios/b2c.md new file mode 100644 index 0000000000..f9e43afa16 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/b2c.md @@ -0,0 +1,49 @@ +--- +url: /architecture-scenarios/b2c +classes: topic-page +title: Business to Consumer Identity and Access Management +description: Explains the architecture scenario B2C IAM with an eCommerce or SAAS application. +topics: + - b2c + - CIAM + - SDLC +contentType: concept +useCase: + - implementation +--- + +
+
+

Business to Consumer Identity and Access Management

+

+ This guidance is relevant to all project stakeholders. We recommend reading it in its entirety at least once, even if you've already started your journey with Auth0. We provide a Project Planning Guide in PDF format, details about how to get started with each phase of the implementation process, and checklists to help you manage the tasks in each phase. +

+
+ +<%= include('./_includes/_base-ways-to-integrate.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('./_includes/_planning.md', { platform: 'b2c' }) %> + +## Get started + +<%= include('./_includes/_base-intro.md', { platform: 'b2c' }) %> + +<%= include('../_includes/_topic-links', { links: [ + 'architecture-scenarios/implementation/b2c/b2c-architecture', + 'architecture-scenarios/implementation/b2c/b2c-provisioning', + 'architecture-scenarios/implementation/b2c/b2c-authentication', + 'architecture-scenarios/implementation/b2c/b2c-branding', + 'architecture-scenarios/implementation/b2c/b2c-deployment', + 'architecture-scenarios/implementation/b2c/b2c-qa', + 'architecture-scenarios/implementation/b2c/b2c-profile-mgmt', + 'architecture-scenarios/implementation/b2c/b2c-authorization', + 'architecture-scenarios/implementation/b2c/b2c-logout', + 'architecture-scenarios/implementation/b2c/b2c-operations', + 'architecture-scenarios/implementation/b2c/b2c-launch' +] }) %> + +## Implementation planning checklists + +<%= include('./_includes/_implementation-checklists.md') %> diff --git a/fr-ca/articles/architecture-scenarios/b2e.md b/fr-ca/articles/architecture-scenarios/b2e.md new file mode 100644 index 0000000000..a35f10a932 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/b2e.md @@ -0,0 +1,114 @@ +--- +order: 06 +title: Business to Employees Identity Scenarios +image: /media/articles/architecture-scenarios/b2e.png +extract: Large organization who wants to federate their existing enterprise directory service to allow employees to log in to applications using their existing enterprise credentials. +description: Explains the architecture scenario of B2E with a large organization that wants to extend their existing enterprise directory service. +topics: + - b2e + - architecture + - lockjs + - active-directory + - saml + - sso +contentType: concept +useCase: + - invoke-api + - secure-an-api + - build-an-app +--- + +# Business to Employees Identity Scenarios + +The B2E (Business to Employees) scenario involves applications that are used by employee users. These are applications that are targeted toward users who are typically acting on behalf of an organization such as an employer, a university, or a group in which they are a member, as opposed to acting on their own behalf. + +Such applications that are custom written by the organization may use the OIDC/OAuth protocol to externalize authentication whereas those that have been purchased will often use the SAML protocol. In either case, the enterprise will typically want to use some form of Enterprise connection, such as a SAML Identity Provider, ADFS, G Suite, Azure AD or a directory service such as AD or OpenLDAP, and less frequently, a custom DB, for authentication of enterprise users. + +For a business that is creating or integrating applications with Auth0 for a B2E environment, there are several requirements that are common for this scenario. This guide will summarize the most common requirements for B2E applications and explain the Auth0 features which help meet each need. + +## Enterprise providers + +Most businesses already have a corporate identity repository which has information on all the employee users and user profile information. It may also contain information on partners and contractors. A common requirement for the B2E scenario therefore, is to allow such users to log in via [Auth0 Enterprise connections](/connections/identity-providers-enterprise) such as SAML2 providers, ADFS, G Suite, Azure AD or an on-premise corporate directory service. This is attractive to users because it allows them to avoid creating yet another username and password for each application and instead leverage the same login credential across all their enterprise applications. + +This is especially attractive to security interests within the company because user credentials are only exposed to the identity stack instead of to each application. Furthermore, this architecture allows the business to retain control over access to applications because the enterprise identity provider provides a single shutoff point. If a user leaves the organization, administrators can simply disable the user’s account in the corporate identity provider and the user can no longer log in to any of the applications using that identity provider. + +Auth0 makes it easy to enable login via a wide variety of enterprise providers with just a few simple configuration steps. + +## Groups and roles + +With a lot of users, you may set up groups and roles to manage access and privileges. Often, these are stored and administered in a directory service. + +Auth0 can get user attributes, like groups and roles, from a directory service or enterprise identity provider during authentication. You can then make the attributes available through tokens returned to the application or with the Auth0 Management API. + +## Profile translation + +Sometimes a directory or identity provider returns attributes in one format, but your application uses another format. Using Auth0's [Rules](/rules/current/metadata-in-rules), you can [map and translate user profile attributes](https://auth0.com/rules/saml-attribute-mapping). You can even translate between OIDC/OAuth, SAML, WS-Fed, and LDAP. + +For example, you retrieve attributes in SAML assertion format from a SAML Identity Provider. With a rule you can then translate the attributes to custom claims in an ID Token for an OIDC/OAuth application. + +You can also map SAML attributes to the Auth0 user profile from the dashboard. To do this, go to [Connections > Enterprise > SAMLP Identity Provider](${manage_url}/#/connections/enterprise), select your SAML connection, and set your attribute mappings in the **Mappings** tab. + +## Extensibility with augmented user profiles + +You may want to enrich user profiles with attributes or data retrieved from other services. For example, you might receive an address or phone number and wish to translate that into a geographic region. [Auth0 Rules](/rules) enable you to write small snippets of code that execute during the authentication transaction. This lets you execute logic or call other services for user information, then add [user metadata](/users/concepts/overview-user-metadata) to the Auth0 user profile and optionally the resulting tokens sent to your applications. + +## Single Sign-on + +If you have several internal applications, you can set up [Single Sign-on (SSO)](/sso) across them so users only have to log in once. + +Auth0 supports integration with applications that externalize authentication using industry standard identity protocols: + +* OIDC/OAuth +* SAML2 +* WS-Fed + +After some configuration, all your applications can leverage your enterprise identity provider. In this setup, Auth0 is the broker between your applications and enterprise identity providers. + +Now when a user signs in to one application, they can access other applications integrated with Auth0 without having to log in again. This will be true until their SSO session expires. You should configure the SSO session length within Auth0 to meet security policies. + +## Single Sign-on integrations + +You can also integrate purchased applications with Auth0 for Single Sign-on (SSO). Auth0 provides [pre-built integrations](/integrations/sso) for applications such as: + +* Salesforce +* Zendesk +* Slack +* New Relic + +## Branding + +Branding is an important part of any application. Your logo, colors and styles should be consistent in all parts of the application. You can [customize](/libraries/custom-signup) the login, signup, and error pages displayed by Auth0 so it matches your application. Add your own logo, text, and colors. There's also I18N/L10N support for global rollouts. [Emails for verification or password resets](/email/templates) are customizable too. + +[Login screens](/libraries/lock/v11/ui-customization) should appear to come from your application’s branded domain name. To maintain consistency, you can define a [custom domain name](/custom-domains) for the login screen displayed by Auth0. + +## Multi-factor authentication + +Internal or employee applications often deal with sensitive content. [Multi-factor authentication (MFA)](/mfa) helps protect your data and applications. Auth0 provides a variety of ways to implement MFA. And for more flexibility, you can use Rules to turn it on only for the applications or user groups that need it. + +## Logs export + +Need to analyze logs or store them long-term? Auth0 provides extensions to [export logs to external tools](/logs) for analysis and retention. You can also retrieve log data with the Management API. + +## Audit + +Companies have many uses for logs data, one of which is audit reports. Auth0 captures a variety of data in log files, which may be useful for your audit reporting. The logs have information on authenticated users, the identity provider used, and when significant administrative changes are made in the Auth0 dashboard. + +Log events each have an event type. You can use event types as filters when querying log data with the Management API, or when exporting logs to log analysis tools. + +## Monitoring + +Monitoring the infrastructure and services that your applications depend on is critical. Auth0 provides an [Auth0 Status](https://status.auth0.com) page you can subscribe to. + +Auth0 makes every effort to minimize outages, but if there is any disruption to service, it will appear on the status page. To support requirements for root cause analysis documentation after a disruption, Auth0 conducts internal analysis and publishes the results on the disruption notice when the analysis is completed. + +## Anomaly Detection + +An unfortunate part of modern life on the internet is hackers. Hackers are constantly trying to find a way into applications. For example, they may try to log in using common passwords. Or they may use credentials stolen from elsewhere, hoping that users re-used the same passwords at other sites. + +Auth0's [Attack Protection](/attack-protection) detects these situations for Auth0 Database connections and provides options for how to respond. Turn on Attack Protection and configure the response options so you can respond appropriately if such an event occurs. + +## Github Deployment + +Do you manage a lot of your application code in Github? You can deploy code for rules, hooks, or custom database access from there with Auth0's [Github Deployment extension](/extensions/github-deploy). + +If you have a full continuous integration/continuous deployment pipeline, use the [Auth0 Deploy CLI tool](https://github.com/auth0/auth0-deploy-cli) for greater flexibility. diff --git a/fr-ca/articles/architecture-scenarios/checklists.md b/fr-ca/articles/architecture-scenarios/checklists.md new file mode 100644 index 0000000000..16712907ca --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/checklists.md @@ -0,0 +1,72 @@ +--- +title: Implementation Planning Checklists +description: Links to checklists for your implementation. +topics: + - SDLC + - checklists + - best practices + - implementation checklist +contentType: reference +useCase: + - implementation +--- +# Implementation Planning Checklists + +Click the links below to download a checklist that corresponds to a phase in the SDLC (Software Development Lifecycle). You can open the checklist in any spreadsheet application and customize them to suit your needs. + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Analyze Checklist + +Analyze Checklist Download + +In the Analyze phase, analyze end-user business requirements and determine project goals as part of the high-level plan for the project. Convert the requirements and goals into system functions that the organization intends to develop. Activities include: + +* Gathering business requirements +* Creating process diagrams +* Performing detailed analysis +* Alignment to project plan + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Design Checklist + +Design Checklist Download + +In the Design phase, describe the desired features and operations of the system, including business rules, pseudo-code, screen layouts, and other necessary documentation. Activities include: + +* Infrastructure design +* System model design + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Build Checklist + +Build Checklist Download + +In the Build phase, develop the actual system through implementation of infrastructure and code. Activities include: + +* Infrastructure implementation +* Code implementation + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Test Checklist + +Test Checklist Download + +In the Test phase, integrate and deploy all implemented code in the testing environment infrastructure. Testing then follows Software Testing Life Cycle activities to check the system for errors, bugs, and defects to verify that system features work as expected (or not). Activities include: + +* Write test cases +* Execute test cases + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Deploy Checklist + +Deploy Checklist Download + +In the Deploy phase, deploy the system to either a staging or production environment, where actual users begin to operate and interact with it. + +Eventually, you deploy all components of the system to the production environment when you make a live release. + +## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Monitor Checklist + +Monitor Checklist Download + +In the Monitor phase, make enhancements, corrections, and changes to ensure the system continues to work and stays updated to meet the business objectives and support the needs of the users. Activities include: + +* Monitoring +* Maintenance +* Changes and adjustments +* Upgrade and adapt to future needs diff --git a/fr-ca/articles/architecture-scenarios/implementation-resources.md b/fr-ca/articles/architecture-scenarios/implementation-resources.md new file mode 100644 index 0000000000..b4c4f6a955 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation-resources.md @@ -0,0 +1,115 @@ +--- +title: Implementation Resources +description: Learn about all the resources Auth0 provides to help you with your Auth0 implementation. +toc: true +topics: + - architecture + - api-auth + - sample-code + - sdks + - documentation + - guides + - quickstarts +contentType: concept +useCase: + - get-started + - implementation + - learning + - testing + - run-sample-code + - get-help + - enter-support-ticket +--- +# Implementation Resources + +Auth0 provides a wealth of resources to help you effectively engage with our product and community. This list provides links to the resources available, by category. + +## Get started + +Resources designed to help you learn the basics of Auth0 include: + +* [**Getting Started documentation**](/getting-started): Explore the Auth0 Dashboard and common terms used for components of the Auth0 service. Gain a broad understanding of Auth0 and learn the terminology you might hear when working with Auth0 staff or reading our docs. + +* [**Get Started with Auth0 Video Series**](/videos/get-started): In these short videos, we cover how easy it is to complete the basic steps to use Auth0 with your applications. Watch the series before you start your project so you can get the benefit of our knowledge and experience with other customers. We cover tenant configuration, provisioning user stores and importing users, authentication, authorization, and branding and customization of everything shown to your users. + +* [**Architecture scenarios**](/architecture-scenarios): Review common architecture scenarios and learn how to implement them with Auth0. Scenarios include tutorials for common architecture patterns, such as a Single-Page Application (SPA) calling an API. High-level descriptions are useful for architects, while tutorials will help development teams. + +* [**Implementation guides**](/topics/guides): Learn how to implement commonly-used features, such as user management and multi-factor authentication (MFA). This information is useful for both architects and developers. + +## Learn + +Auth0 provides numerous tutorials, guides, white papers, and blog posts that focus on both learning and providing quick reference checks. + +* [**Docs site**](https://auth0.com/docs/): Browse through our docs to explore a wealth of available topics, or use our search to quickly find content related to a topic or term. + +* [**Feature descriptions and white papers**](https://auth0.com/learn/): Investigate short descriptions of features, industry case studies, and reference white papers. The Auth0 Learn site provides a quick overview of Auth0 features and their business value; it is helpful for project owners as well as architects and developers. + +* [**Blog posts**](https://auth0.com/blog/): Read blog posts written by experts on a variety of topics--from time-honored advice to breaking news in the identity space. Many blog posts are oriented toward architects and developers. + +## Run sample code + +Once your development team is ready to build, Auth0 provides sample programs, SDKs, and libraries to speed your project along. + +* [**Quickstarts**](/quickstarts): Investigate a rich array of small sample programs that demonstrate how to implement the key features you’ll want to include in your program, such as authentication, session management, profile updates, and logout. Quickstarts will give developers a head start on understanding how to integrate applications with Auth0. + +* [**Libraries and SDKs**](/libraries): Simplify your custom application development by using our extensive set of libraries and SDKs, which abstract many of the details of identity protocols for you. Auth0 SDKs support numerous languages and frameworks to simplify your integration with Auth0. We also provide a library for Lock, a login widget, that you can use across several platforms, including iOS and Android. + +* [**Management API**](/api/management/v2): Explore and manipulate objects, configurations, and settings within Auth0. The Management API Explorer allows you to quickly manipulate individual objects and settings on an *ad-hoc* basis and test API calls before coding them into your applications. + +* [**Authentication API**](/api/authentication): Authenticate and authorize users via the OIDC, OAuth, and SAML protocols. The Authentication API Explorer allows you to experiment with authentication and authorization flows, and test API calls before coding them into your applications. + +## Try out features and API calls + +While building, Auth0 allows you to experiment with and test out various product features. + +* **TRY buttons/links**: Quickly try out Auth0 product features. **TRY** buttons are located throughout Auth0 and allow you to experiment with connections, rules, hooks, and email templates. + +* [**Authentication API Explorer**](/api/authentication#introduction): Experiment with authentication and authorization flows, and test API calls before coding them into your applications. + +* [**Management API Explorer**](/api/management/v2): Quickly manipulate individual objects and settings on an *ad-hoc* basis and test API calls before coding them into your applications. + +* [**Postman Collections**](/api/postman): Easily dissect our APIs' calls using Postman by importing our Postman Collections. + +## Get help + +Auth0 resources that help you troubleshoot your implementation include: + +* [**Auth0 Community forum**](https://community.auth0.com/): Connect with the world of Auth0 via Auth0 posts, FAQs, and community Q&As. Architects and developers find this a valuable source of information for learning and connecting with others as well as getting help on issues. + +* [**Support Center**](https://support.auth0.com/): View and manage your subscription and tenants, file and view support requests, run automated production checks on a tenant, and view compliance information. Paid subscribers will find the support center a valuable resource if an issue or question cannot be solved by documentation or by searching the forum. + + * [**Create support cases**](/support/tickets): Create and file a support case if you need help. + + * [**Support Plans and Service Level Agreements**](/support#defect-responses): Learn about multiple levels of support available for purchase. + + * [**Troubleshooting tips**](/onboarding/enterprise-support#what-to-check-before-logging-an-issue) and [**Information to include in your support case**](/onboarding/enterprise-support#information-to-provide-when-logging-an-issue): Get advice to help your development and support teams analyze issues. + +* [**Supported versions**](/support/matrix): Understand which versions of SDKs, browsers, and languages are supported. Architects and developers should review this to ensure your project employs languages, libraries, and SDKs that will allow your implementation to work with Auth0. + +* [**Feedback Portal**](https://auth0.com/feedback): Make product suggestions. (You can also do this via the Support Center if you want better visibility into what you’ve filed over time.) Architects and developers can use this site to provide feedback on the Auth0 product for consideration as enhancements in the future. + +* [**Professional Services**](/services): Engage our world-wide professional services team to help speed your project to success. Project owners will find this useful for learning how Auth0 identity experts can help accelerate your project or fill in any temporary skill gaps. + +## Setup and monitor operations + +When you're ready to plan your launch, Auth0 provides the following resources: + +* [**Pre-launch advice**](/pre-deployment) and [**Production check**](/pre-deployment/how-to-run-test): Get tips and tools to help you plan your launch. Project managers and development and operations teams should explore these tips to leverage advice for a smooth launch. + +* [**Operational policies**](/policies): Familiarize yourself with Auth0's policies, so you know lead times for operational requests. Policies are useful for an entire team, but project owners and operations teams in particular should be aware of Auth0's operational policies. + +* [**Status Dashboard**](https://status.auth0.com): Quickly determine the availability of Auth0 services and subscribe to status updates. Although service interruptions are rare, when one occurs Auth0 conducts a root cause analysis and publishes the results on this site. Operations and support teams should be familiar with how to check Auth0 status. + +* [**Monitor endpoints**](/monitoring): Learn how to integrate our monitoring endpoints into your monitoring infrastructure. This information is of particular use to operations teams and project owners. + +* [**Log data**](/logs): Learn about the types of logs Auth0 provides, log data retention, and tools you can use to export log data to external analytical tools for analysis and long-term data storage. This information is useful for developers and operations teams, as well as compliance teams interested in data retention. + +* [**Dashboard notices**](/architecture-scenarios/implementation/b2c/b2c-operations#notifications): Stay informed about important announcements from Auth0. From time to time, Auth0 notifies you of important information via your Auth0 Dashboard and (depending on the severity of the information) via email to your registered Auth0 Dashboard Admins. You should regularly log in to the Dashboard and check the bell icon at the top for any important notices. + +## Satisfy privacy, security, and compliance needs + +View info on Auth0’s privacy policy, security policy, compliance certifications, and how Auth0 can help you with your compliance needs. This information is useful for project owners as well as security, privacy teams, and procurement teams. + +* [Privacy and Cookie Policy](https://auth0.com/privacy) +* [Security, Privacy and Compliance](https://auth0.com/security/) +* [Compliance Frameworks and Certifications](/compliance) diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md new file mode 100644 index 0000000000..b38753d752 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md @@ -0,0 +1,56 @@ +--- +title: Architecture +description: How you configure your Auth0 tenant architecture affects your B2B IAM implementation. +toc: true +topics: + - b2b + - b2biam + - architecture +contentType: concept +useCase: + - tenant-architecture +--- +# Architecture + +<%= include('../../_includes/_architecture/_introduction.md', { platform: 'b2b' }) %> + +## Tenant provision + +<%= include('../../_includes/_architecture/_tenant-provision.md', { platform: 'b2b' }) %> + +### Tenant provision for complex organizations + +In most cases, provisioning separate Auth0 tenants for your customer's organizations is not necessary. However, in certain circumstances this can be something that is valuable for reducing the complexity of your setup. For instance, we recommend provisioning a separate Auth0 tenant for your customers' organization as a best practice if: + +* Your customers' organizations have isolated users that aren't shared with other organizations. +* You have some customer organizations that support more than one IdP. For example, your customer has their own IdP but also has some users that aren't in their IdP and whose credentials you will need to store. Or, your customer wants to provide for one or more social connections in addition to their enterprise IdP. + +If both of these situations are the case, then we recommend that you create separate Auth0 tenants for each customer that needs it. This allows you to have a separate custom domain for them and to easily customize their login experience, including [Home Realm Discovery](/architecture-scenarios/implementation/b2b/b2b-authentication#home-real-discovery) on their login page. + +::: warning +Maintaining multiple Auth0 tenants can add complexity to your system and should not be done unless absolutely necessary. +::: + +## Tenant association + +<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2b' }) %> + +## Custom domains + +<%= include('../../_includes/_architecture/_custom-domains.md', { platform: 'b2b' }) %> + +## SDLC support + +<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'architecture' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md new file mode 100644 index 0000000000..4414be9c8f --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md @@ -0,0 +1,127 @@ +--- +title: Authentication +description: How authentication works in your B2B IAM implementation. +toc: true +topics: + - b2b + - b2biam + - authentication + - universal-login +contentType: concept +useCase: + - authentication +--- +# Authentication + +<%= include('../../_includes/_authentication/_introduction.md', { platform: 'b2b' }) %> + +## Universal Login + +<%= include('../../_includes/_authentication/_universal-login.md', { platform: 'b2b' }) %> + +## Home realm discovery + +Home realm discovery (HRD) is the process of identifying which identity provider (or which connection in Auth0) the user belongs to *before* authenticating them. There are two ways HRD can occur: + +* Provide a way for the decision to be made at the application +* Have Home Realm Discovery happen on the Universal Login page + +Your system may need to do either or both methods so it is important to understand all approaches to HRD so that you can apply the one(s) that make the most sense to your applications. + +::: panel Best practice +If you don’t need to know ahead of time (for example, all of your users are in a shared user pool), then you don’t need to do HRD. You can allow users to authenticate first and then determine which organization they belong to using app metadata. HRD is really only needed if you have multiple connections within your Auth0 tenant. +::: + +### Application driven HRD + +A common and effective way for determining which realm a user belongs to is when an application is branded for each organization. The organization has its own instance of the application. This copy or instance can be physically isolated (running on a separate set of servers) or virtually isolated (running on shared servers, but presented as if it could be isolated), and is generally denoted through either a custom hostname (`companyA.application1.yourcompany.com`) or path (`application1.yourcompany.com/companyA`). + +::: warning +This method will only work if you are not sharing users between organizations. If you are sharing users within organizations, then you must support [Home Realm Discovery on the Universal Login Page](#hrd-through-universal-login) +::: + +::: panel Best practice +If your application already knows what connection (IdP) the user needs, then pass that along when you redirect the user to `/authorize` using the connection query parameter. +::: + +If this is the case for your application(s) then home realm discovery is a simple matter of storing the Auth0 connection name with the organization specific application configuration and sending that connection name as a parameter when redirecting the user for Universal Login. Sending the connection parameter can be achieved by adding it as a query parameter when you redirect them to the authorize endpoint. For more information see the [Authentication API docs](/api/authentication#authorization-code-flow); however, you will generally accomplish this using the SDK for whichever language your application is written in. + +::: panel Best practice +If an organization needs more than one IdP, then you will have to do a second round of Home Realm Discovery once identifying their organization. This can be achieved with Auth0 through creating a dedicated Auth0 tenant for that organization and creating an enterprise connection to that tenant. +::: + +### HRD through Universal Login + +There are three main approaches to Home Realm Discovery through Universal Login: + +* Discover the realm through the user’s email subdomain. +* Discover the realm by looking up a user identifier in some sort of map of identifier to realm map. +* Allow the user to choose or enter their realm (or organization). + +In both of the first two approaches, you may consider doing “Identifier First Login”. This means that you present only the ability to enter an identifier first. After which you collect the user’s identifier, and then based on the identifier you either automatically redirect the user or present a way for the user to enter their password if redirection is unnecessary. + +::: warning +Though it is possible to implement Identifier First Login or allow a user to select their organization at the application instead of on the Universal Login Page, this can add complexity with respect to single sign on as well as complexity associated with replicating that behavior in all of your applications. Instead Auth0 recommends implementing some form of HRD through Universal Login. +::: + +#### HRD through Universal Login using the email subdomain + +The simplest way to implement home realm discovery on the universal login page is to utilize the email subdomain of the user’s identifier to map that to their Identity Provider. This, of course, only works in situations where the email subdomain will be a 1:1 mapping to an organization or at least to an Identity Provider. Auth0’s Lock widget can do this for you if you are using the domain map in an enterprise connection, however if you want to build this yourself, you can, but it requires you to build a mapping of email subdomain to connection. + +#### HRD through Universal Login using the Identifier to Realm Map + +A second, more complex alternative is to store a map of identifier’s to IdP and provide a public endpoint to access that information. Then on the Universal Login page you can find the connection and redirect back to /authorize with the connection. The main drawbacks to this approach are latency, and more importantly security when it comes to identifier discovery: if you’re using email addresses, this makes it much easier for someone to discover whether a particular email address is a user of yours. + +::: panel Best practice +Any public endpoint should have rate limiting applied to it to prevent hackers from using it to discover information and to prevent denial of service attacks. +::: + +#### HRD through Universal Login using user choice + +The other simple option is to allow your users to choose from a list, if you don’t mind making public the list of organizations who use your product, or by allowing the user to enter their organization name explicitly. Once the user tells you which organization they belong to, you can redirect back to Auth0 with the connection for that organization specified, or simply prompt them for their username and password if the connection is a database connection. + +## Username and password authentication + +<%= include('../../_includes/_authentication/_username-and-password-authentication.md', { platform: 'b2b' }) %> + +## Application integration + +<%= include('../../_includes/_authentication/_application-integration.md', { platform: 'b2b' }) %> + +## Anomaly detection + +<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2b' }) %> + +## SSO with legacy systems + +<%= include('../../_includes/_authentication/_sso-legacy.md', { platform: 'b2b' }) %> + +## Enterprise Login + +The “bring your own identity” scenario has become a must-have for almost all B2B applications. Most enterprise companies expect to be able to integrate their IdP into your application so their employees don't need to store another set of credentials. This is a valuable way of simplifying the user authentication experience without compromising security, and using [Universal Login](#universal-login) makes it easy to start adding support for [Enterprise Connections](/connections/identity-providers-enterprise) with minimal disruption. + +::: panel Best Practice +Once you start supporting enterprise connections for users, you must do some form of [Home Realm Discovery](#home-realm-discovery) so that you can determine which connection to send the user to for authentication. +::: + +With enterprise connection support, user identities and credentials are managed by the identity provider of your customers' organization, as well as certain identity claims - which Auth0 will use to populate the user [profile](/architecture-scenarios/implementation/b2b/b2b-profile-mgmt). + +::: panel Best Practice +"Bring your own identity" is a great feature to provide, but if you don't support this from day one, and sometimes even if you do, you may have an organization that wants to switch to their own IdP after already having used the application for a while. You will need a way to [link user accounts](/users/concepts/overview-user-account-linking) to provide an effective way of associating the new identity with the old database identity. +::: + +## Multi-factor authentication (MFA) + +<%= include('../../_includes/_authentication/_mfa.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'authentication' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md new file mode 100644 index 0000000000..5d0ca8d405 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md @@ -0,0 +1,61 @@ +--- +title: Authorization +description: User authorization and related planning considerations for your B2B IAM implementation. +toc: true +topics: + - b2b + - b2biam + - user-authorization +contentType: concept +useCase: + - user-authorization +--- +# Authorization + +<%= include('../../_includes/_authorization/_introduction.md', { platform: 'b2b' }) %> + +## Application integration + +<%= include('../../_includes/_authorization/_application-integration.md', { platform: 'b2b' }) %> + +## API integration + +<%= include('../../_includes/_authorization/_api-integration.md', { platform: 'b2b' }) %> + +## Role Based Access Control (RBAC) + +<%= include('../../_includes/_authorization/_rbac.md', { platform: 'b2b' }) %> + +The core RBAC feature can be used in many multi-organization scenarios. See [Organization Data in an Access Tokens](#organization-data-in-an-access-token) for more information on how to ensure your setup can support your RBAC needs. + +## Machine-to-Machine (M2M) authorization + +<%= include('../../_includes/_authorization/_m2m.md', { platform: 'b2b' }) %> + +## Organization Data in an Access Token + +If you have a separate API from your application in your system that supports your multi-organization application, it is important to restrict operations to only the organization that the token was generated for. This requires that there is some sort of information in the access token to tell the API which organization the access token was issued for. This can be done in a couple of different ways depending on the answers to a couple of simple questions: + +1. Will the End Users in this organization potentially have more than one organization, or is each End User isolated to a specific organization? +2. Will you be allowing any Machine-to-Machine (M2M) access to your API? +3. If you are allowing Machine-to-Machine (M2M) access to your API, Will you have any developers who need a single client ID and secret to access multiple organizations (but not *all* organizations)? +4. Will you be allowing the creating of third-party apps that require consent? + +If End Users are isolated to a single organization **and** you will either not be allowing M2M access to your API or you will have a separate client ID/secret for each organization that needs access **and** you will *not* be allowing third-party apps that require consent, then the simplest approach is to just create a custom claim in the access token [using rules for the user based tokens](#access-token-claims) and [using the client credentials hook for M2M calls](#machine-to-machine-m2m-authorization). You can store organization name in client metadata and extract it from rules or hooks to include in access_token as a custom claim. RBAC will work out of the box for this approach as well as long as each End User can only belong to one organization. + +If End Users have more than one organization they can belong to or you might give a single developer a client ID and secret for M2M calls to more than one organization, then you will be best served by creating a separate audience (a separate API instance in your Auth0 tenant) for each organization. This gives you a few nice abilities: +1. First, it allows you to pass the audience as a first-class parameter to Auth0 without having to create a custom parameter. The benefit of this is that Auth0 will help enforce the existence of the audience, and it will pass it to your rules. It will also ensure that an issued refresh token will only work for the specific audience it was originally issued to. +2. It allows you to restrict client grants to only specific organizations out of the box. The alternative is to create a more complicated client credentials hook to attempt to retrieve the restrictions from somewhere else and also require a much more complex and potentially troublesome way to tell the client credentials call which organization to issue the access token for. +3. This also allows you to use the core RBAC feature with Auth0 and ensure that the End Users who have access to more than one organization can have a potentially different role for each organization. + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'authorization' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-branding.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-branding.md new file mode 100644 index 0000000000..b2da74226e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-branding.md @@ -0,0 +1,65 @@ +--- +title: Branding +description: How to configure Auth0 items to reflect your brand and desired user experience. +toc: true +topics: + - b2b + - b2biam + - branding + - universal-login + - login-pages + - password-reset-pages + - custom-domains + - error-pages +contentType: concept +useCase: + - user-logout +--- +# Branding + +<%= include('../../_includes/_branding/_introduction.md', { platform: 'b2b' }) %> + +## Universal login and login pages + +<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2b' }) %> + +## Branding login by organization + +Whether or not you need to do special customization on the Universal Login page is determined by how you plan to manage your customers’ organization. Before reading through this section, make sure you have read through the [Universal Login section](#universal-login-and-login-pages) and know how you are approaching organizations by reviewing [Multiple Organization Architecture](https://drive.google.com/a/auth0.com/file/d/1y2G8RNHTBujcCrnMRhp6_phQiRAkZzfF/view?usp=sharing). + +If your organization users will all be isolated from each other, than it’s important to make it clear on the Universal Login page which organization the login page is for. This can be done in a couple of ways: + +* Create JavaScript on the Universal Login Page that can pull resources from a CDN based on the organization presented to it. +* Create a separate tenant for the organization and use the Universal Login page to customize as desired for that organization. + +## Custom domain naming + +<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2b' }) %> + +## Email template customization + +<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2b' }) %> + +## Password reset page customization + +<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2b' }) %> + +## Error page customization + +<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2b' }) %> + +## Guardian multi-factor page customization + +<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'branding' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md new file mode 100644 index 0000000000..8f0c437182 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md @@ -0,0 +1,28 @@ +--- +title: Deployment Automation +description: How Auth0 tooling helps to automate tenant deployment. +topics: + - b2b + - b2biam + - tenants + - deployment +contentType: concept +useCase: + - tenant-deployment +--- + +# Deployment Automation + +<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'deployment' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch.md new file mode 100644 index 0000000000..358e53464e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch.md @@ -0,0 +1,30 @@ +--- +classes: topic-page +title: Launch Preparation +description: Launch preparation considerations for your B2B IAM implementation. +topics: + - b2b + - ciam + - launch +contentType: concept +useCase: + - launch +--- +# Launch Preparation + +<%= include('../../_includes/_launch/_introduction.md', { platform: 'b2b' }) %> +<%= include('../../../_includes/_topic-links', { links: [ + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck', + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing', + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations', + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance', + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support', + 'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch' + ] }) %> + +## Project Planning Guide +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'launch' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md new file mode 100644 index 0000000000..01a2a4ce91 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md @@ -0,0 +1,24 @@ +--- +title: Compliance Readiness +description: Compliance checks to perform before launch of your B2B IAM implementation. +topics: + - b2b + - ciam + - launch + - compliance +contentType: concept +useCase: + - launch +--- + +# Compliance + +<%= include('../../../_includes/_launch/_compliance.md', { platform: 'b2b' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md new file mode 100644 index 0000000000..835be1391e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md @@ -0,0 +1,23 @@ +--- +title: Launch Day Preparation +description: Launch preparation considerations for your B2B IAM implementation. +topics: + - b2b + - ciam + - launch +contentType: concept +useCase: + - launch +--- + +# Launch Day Readiness + +<%= include('../../../_includes/_launch/_launch.md', { platform: 'b2b' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md new file mode 100644 index 0000000000..e4742e5f13 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md @@ -0,0 +1,24 @@ +--- +title: Operations Readiness +description: Operations checks to perform before launch of your B2B IAM implementation. +topics: + - b2b + - ciam + - launch + - operations +contentType: concept +useCase: + - launch +--- + +# Operational Readiness + +<%= include('../../../_includes/_launch/_operations.md', { platform: 'b2b' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md new file mode 100644 index 0000000000..818c04db04 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md @@ -0,0 +1,23 @@ +--- +title: Support Readiness +description: Support readiness for the launch of your B2B IAM implementation. +topics: + - b2b + - ciam + - launch + - support +contentType: concept +useCase: + - launch +--- + +# Support Readiness + +<%= include('../../../_includes/_launch/_support.md', { platform: 'b2b' }) %> + +# Project Planning Guide +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md new file mode 100644 index 0000000000..bbe597465c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md @@ -0,0 +1,24 @@ +--- +title: Tenant Check +description: Tenant Checks to perform before launch of your B2B IAM implementation. +topics: + - b2b + - ciam + - launch + - configuration +contentType: concept +useCase: + - launch +--- + +# Tenant configuration check + +<%= include('../../../_includes/_launch/_tenant-check.md', { platform: 'b2b' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md new file mode 100644 index 0000000000..e3c2314ffe --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md @@ -0,0 +1,24 @@ +--- +title: Testing Complete +description: Testing preparation for the launch of your B2B IAM implementation. +topics: + - b2b + - ciam + - launch + - testing +contentType: concept +useCase: + - launch +--- + +# Testing + +<%= include('../../../_includes/_launch/_testing.md', { platform: 'b2b' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-logout.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-logout.md new file mode 100644 index 0000000000..f818eb1ceb --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-logout.md @@ -0,0 +1,58 @@ +--- +title: Logout +description: User logout planning considerations for your B2B IAM implementation. +topics: + - b2b + - b2biam + - logout + - sessions +contentType: concept +useCase: + - user-logout +--- +# Logout + +<%= include('../../_includes/_logout/_introduction.md', { platform: 'b2b' }) %> + +## Single Logout + +If you are doing [Federated Logout](#federated-logout) you will likely also want to do Single Logout (SLO), and there are two main approaches you can take. + +::: warning +SLO can add complexity to your system, so you need to ensure that you really need it before adding the extra development and maintenance time to your system. +::: + +### Short-lived tokens + +::: panel Best Practice +You want to avoid making too many calls to your Auth0 tenant to avoid rate limiting and poor performance. A best practice is to only request new tokens if tokens have expired and a user takes an action. This will avoid applications that are simply open, but not in use, from continually polling for new tokens. +::: + +This is by far the simplest approach to Single Logout. Each application enforces a short time within which a user can use the system, say, 5-10 minutes. On each action a user performs, if the time has expired then either a redirect to Auth0 (for regular web apps), or [Silent Authentication](https://auth0.com/docs/api-auth/tutorials/silent-authentication) for client side Single Page Applications will be used to obtain new tokens. Ordinarily new tokens will be issued silently due to the Single Sign On (SSO) session. However, after logout, all applications will fail to get new tokens silently because the SSO session will have been removed, and the user will need to re-enter their credentials. + +::: warning +If you are automatically forwarding the user directly to their own IdP as part of an enterprise connection using the connection parameter, this can break this technique unless you are also doing [Federated Logout](#federated-logout) +::: + +### Build a logout service + +Another technique you can use is to build a logout service that can track and destroy application sessions. Each application would notify the logout service when it creates and removes a session. The (logout) service would either have direct access to all application's server side sessions and destroy them directly, or it will have the ability to make a back-channel call to each application to tell the application that it must remove its session. + +This technique can be quite effective as there is low-latency between when a user calls logout, and when they are then logged out of all applications. However it can add complexity and also additional development time for implementation. It will also require some way to ensure that new applications added to the system are added to this service. + +## Federated Logout + +[Federated User Logout](/logout/guides/logout-idps) may be something that you need to consider for your application. If you or your customers will be using a third-party IdP (i.e., something other than a [Database Identity Provider](/connections/database)) then the question of whether you need to log the user out of the IdP when they log out of your application is something you will need to answer. The answer depends on what your users would expect. If the application and/or IdP you use is tied closely to a customer organization and a central part of day-to-day operations, then it may be frustrating for users to get logged out of their IdP when they log out of your application. If not, then being logged out of the IdP may be expected, or in some cases even desired. In most B2B scenarios, our customers find that it is preferable *not* to perform federated logout for a user. + + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'logout' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-operations.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-operations.md new file mode 100644 index 0000000000..7efd77e295 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-operations.md @@ -0,0 +1,62 @@ +--- +title: Operations +description: How to operationalize your Auth0 tenant environments. +toc: true +topics: + - b2b + - b2biam + - tenants + - operations +contentType: concept +useCase: + - tenant-operations +--- + +# Operations + +<%= include('../../_includes/_operations/_introduction.md', { platform: 'b2b' }) %> + +## Service status + +<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2b' }) %> + +## Email provider setup + +<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2b' }) %> + +## Infrastructure + +<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2b' }) %> + +## Logging + +<%= include('../../_includes/_operations/_logging.md', { platform: 'b2b' }) %> + +## Monitoring + +<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2b' }) %> + +## Notifications + +<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2b' }) %> + +## Provisioning organizations + +<%= include('../../_includes/_provisioning/_organizations.md', { platform: 'b2b' }) %> + +## Self-Service IdP provisioning + +While Auth0 [connections](/identityproviders) make it easy to configure IdPs, it can be a time-consuming process to onboard customer organization IdPs especially if you are selling to new customer organizations on a regular basis or existing organizations have changing IdP requirements. As a result, many of our customers have found it worthwhile to build a self-service portal for their customers' organization admins so that they can configure their own IdPs. This cuts down on your IT department's workload. The [Auth0 Management API](/api/management/v2) provides all necessary [connection](/api/management/v2#!/Connections/get_connections) management functionality to achieve this. + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'operations' }) %> + diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md new file mode 100644 index 0000000000..bdc3ed3749 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md @@ -0,0 +1,57 @@ +--- +title: Profile Management +description: User profile management planning considerations for your B2B IAM implementation. +toc: true +topics: + - b2b + - b2biam + - user-profiles +contentType: concept +useCase: + - profile-management + - manage-user-profiles +--- +# Profile Management + +<%= include('../../_includes/_profile-mgmt/_introduction.md', { platform: 'b2b' }) %> + +## Metadata + +<%= include('../../_includes/_profile-mgmt/_metadata.md', { platform: 'b2b' }) %> + +## Password reset + +<%= include('../../_includes/_profile-mgmt/_password-reset.md', { platform: 'b2b' }) %> + +## Account verification + +<%= include('../../_includes/_profile-mgmt/_account-verification.md', { platform: 'b2b' }) %> + +## Blocking users + +<%= include('../../_includes/_profile-mgmt/_blocking-users.md', { platform: 'b2b' }) %> + +## Admin portal + +An admin portal is an application where you can create new users, edit a user’s profile, see activity about a user, etc. This application should be accessible by administrators only. Though Auth0 provides its management dashboard, it is not advised to give access to the management dashboard to many people as there are a lot of ways someone can unintentionally break your Auth0 tenant. Instead, Auth0 provides two other options: + +* [**Auth0 Management API**](/api/management/v2): With the Management API you can easily construct an application that provides administrators the ability to manage users. You can either incorporate this into an existing application that already exists for your administrators, or create a new one with a UI that matches your current applications. + +* [**Auth0 Delegated Administration Extension**](/extensions/delegated-admin/v3): This powerful and flexible extension allows you to customize a user administration experience. You can tailor this extension so that you can allow your customer admins to log in and allow them to only see and manage users within their organization. + +::: panel Best practice +If you are providing your own way for an administrator to manage users, you should only allow administrators to send users a change password link through email rather than allowing administrators to set passwords directly. If you must go against this recommendation and allow your administrators to set someone’s password, you should force the user to change their password at their next login so that only they know the password (and not an administrator as well). +::: + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'profile-mgmt' }) %> + diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md new file mode 100644 index 0000000000..8f2fe1e387 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md @@ -0,0 +1,117 @@ +--- +title: Provisioning +description: User provisioning functionality and considerations for your B2B IAM implementation. +toc: true +topics: + - b2b + - b2biam + - user-migration + - custom-db + - universal-login + - user-profiles +contentType: concept +useCase: + - user-provisioning + - store-user-data +--- +# Provisioning + +<%= include('../../_includes/_provisioning/_introduction.md', { platform: 'b2b' }) %> + +## Provisioning organizations + +<%= include('../../_includes/_provisioning/_organizations.md', { platform: 'b2b' }) %> + +## User migration + +<%= include('../../_includes/_provisioning/_user-migration.md', { platform: 'b2b' }) %> + +## Provisioning organization users + +An organization should map directly to one of your business customers/partners. Each business/partner that you are working with has users who will be logging in. We call those end users *organization users*. +There are two different approaches to how to store your organization users: + +* **Isolated to the organization**: Every user *belongs* to exactly one organization. It would not make sense for that user to be a part of more than one organization, and even if they were, it would make sense for them to have a separate “identity” for that other organization. For example, a retail employee that works part time at two different stores has two different logins for each of those stores even if the stores both use the SaaS application. To learn more, see [Provisioning users isolated to the organization](#provisioning-users-isolated-to-the-organization). +* **Shared between organizations**: In a case like this, users either create credentials in your company, or they can access other organizations instances of your application using credentials from their own organization. A simple way to look at this is that one user may be authorized to access more than one organization’s instance of the application. A user would understand that they can use the same credentials to access both instances of an application. For example, some doctors contract with multiple clinics and may need to be able to sign into each separate clinic with their same credentials. To learn more, see [Provisioning users shared between organizations](#provisioning-users-shared-between-organizations). + +### Provisioning users isolated to the organization + +Isolating users to the organization can provide a nice clean barrier between organizations. If no users ever need to access more than one organization (or you would rather force them to create multiple accounts), then this is an attractive approach. + +You need to provision those users at the IdP level. Each of the organizations will have its own IdP for accomplishing this. This IdP will come in one of three flavors: + +* **Your Auth0 Tenant is the IdP**: A Database Connection in your main tenant dedicated to this organization. +* **Organizations bring their own IdP**: You set up an Enterprise Connection for them. +* **Organizations with more than one IdP**: This situation is a little more tricky becasue you have multiple options for approaching this situation. In descending order of complexity, these include: + * You convince them to create (or find that they already have) one main IdP that can route to their individual IdPs. + * You create separate organizations (e.g. customerorg-department1 and customerorg-department2) in your applications. + * You set up a new Auth0 tenant just for them and add as many IdPs as they need (which may include a database in Auth0) to that tenant, along with their own custom domain and branding. + * You make your existing tenant and login page more complex to handle [Home Realm Discovery](/architecture-scenarios/implementation/b2b/b2b-authentication#home-real-discovery) just for organizations that have more than one IdP. + +We recommend using Auth0 as an IdP as a starting point because it’s simple to implement a user invite workflow: an administrator creates a user; a randomly-generated password is created for that user, but never stored or shown to anyone; and then the user receives a welcome email with a link to set their password. Compared to other invite flows, the only thing special about this is that the person who is creating the user will have to either select the organization ahead of time, or the system will force the organization to match that of the user doing the inviting (in situations where there is an organization administrator who belongs to that organization only). To learn more, see [User invite](#user-invite). + +::: panel Best Practice +If you can keep a main Auth0 tenant with a one-to-one mapping between organization and connection, it will greatly simplify your login system, making it more maintainable and extendable for the future. See [Multiple Organization Architecture documents: isolated users by organization](https://drive.google.com/a/auth0.com/file/d/1fzWWu7CUWaPpmaSO01gEhVYmkSXvV28l/view?usp=sharing) for a more in-depth view. +::: + +### Provisioning users shared between organizations + +When sharing users between organizations, you will need a way to authorize access. Because you won’t know where a user might belong when authenticating, we typically recommend storing your users in a single domain and then figuring out which organizations they can access by using user app metadata. Because of this, provisioning will often be done by starting with a User Invite workflow for the single database connection, and then app metadata will be used to authorize access. User app metadata allows information to be stored in a user’s profile that can impact a user's capabilities but which a user cannot change. Let’s say I’m a doctor and I belong to Clinic A and Clinic B. I might have an organizations object in my app metadata that looks like: `{ “organizations”: [“clinicA”,”clinicB”] }`, and then when attempting to log into the app for Clinic B, a rule can check that Clinic B is in the `organizations` array. + +::: panel Best Practice +Because users are shared, you won’t be able to determine who has access by isolating them to their own connection, therefore you will need to use their app metadata to make the determination. When provisioning, you will need a way to set the organizations they have access to or add a new organization to an already existing user. +::: + +### Deprovisioning limitations + +<%= include('../../_includes/_provisioning/_deprovisioning.md', { platform: 'b2b' }) %> + +## User invite + +In most B2B scenarios, only particular individuals are allowed access to the application. As a result, it is often simpler to have an administrator provision user accounts rather than having users sign up and then have an administrator approve them. Provisioning can often be done in an automated fashion when users are added to a centralized system as well. + +There are three different personas who might be [inviting users](/design/creating-invite-only-applications): + +* An administrator at your company may create the users for each organization. +* An administrator from each organization may be assigned to creating users. +* Another system responsible for creating users mahy exist, and that system may then create a user in Auth0. +Regardless of the audience, the technique can be similar, with the exception of the third option which would require the use of the management API and could not be done using the Delegated Administration Extension. The rest is a matter of using the right authorization model for the application. + +User invite can be accomplished in a few ways: + +* Using the [Delegated Administration Extension](/extensions/delegated-admin/v3) +* Updating a pre-existing user administration system that you’ve already created to use the [Management API](/api/management/v2) +* Creating a new application to do this using the Management API. + +::: panel Best Practice +Whether you are using the Management API or the Delegated Administration Extension, it is important to create each user with a random temporary password and *not* store that password anywhere! Then, use the Management API to send an email to the user with a link to set their password. This ensures that the only person who knows the password is the user themselves. +::: + +::: warning +One of the main principles of OIDC is that no one except the user themselves ever knows their password. If you are doing an invite flow, have your backend system randomly generate a password and then discard it and have your user reset their password before ever logging in. Do not create a temporary password and give it to them to log in the first time. +::: + +## Enterprise sign up + +Enterprise sign up is synonymous with sign in via [enterprise login](/architecture-scenarios/implementation/b2b/b2b-authentication#enterprise-login)—there’s no distinction here *per se*, as user [profile](/architecture-scenarios/implementation/b2b/b2b-profile-mgmt) creation happens automatically upon first enterprise login. + +::: panel best practice +A nice advantage of allowing your customers to use their own IdP is that they can administer their users and assign roles and access in their own IdP setup instead of forcing you to build administration for them. Working out the mapping for those customers will make this much easier. +::: + +::: warning + If mapping isn't enough and you must put some metadata in your system, keep in mind that Auth0 will not create the user until they log in to the system the first time. Therefore, you will need to use rule extensibility to pull the initial information from somewhere else, or force users to log in the first time before you can add the metadata. +::: + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'provisioning' }) %> + diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-qa.md b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-qa.md new file mode 100644 index 0000000000..2aa5556410 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2b/b2b-qa.md @@ -0,0 +1,41 @@ +--- +title: Quality Assurance +description: Quality Assurance considerations for your B2B IAM implementation. +toc: true +topics: + - qa + - b2b + - b2biam + - quality +contentType: concept +useCase: + - quality-assurance +--- +# Quality Assurance + +<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2b' }) %> + +## Unit testing + +<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2b' }) %> + +## Integration testing + +<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2b' }) %> + +## Mock testing + +<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2b' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %> + +## Multiple Organization Architecture (Multitenancy) + +<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'qa' }) %> + diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md new file mode 100644 index 0000000000..9d01f715a0 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md @@ -0,0 +1,40 @@ +--- +title: Architecture +description: How you configure your Auth0 tenant architecture affects your B2C IAM implementation. +toc: true +topics: + - b2c + - ciam + - tenants +contentType: concept +useCase: + - tenant-architecture +--- + +# Architecture + +<%= include('../../_includes/_architecture/_introduction.md', { platform: 'b2c' }) %> + +## Tenant provision + +<%= include('../../_includes/_architecture/_tenant-provision.md', { platform: 'b2c' }) %> + +## Tenant association + +<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2c' }) %> + +## Custom domains + +<%= include('../../_includes/_architecture/_custom-domains.md', { platform: 'b2c' }) %> + +## SDLC support + +<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'architecture' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md new file mode 100644 index 0000000000..daffa7e833 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md @@ -0,0 +1,52 @@ +--- +title: Authentication +description: How authentication works in your B2C IAM implementation. +toc: true +topics: + - b2c + - ciam + - authentication + - universal-login +contentType: concept +useCase: + - authentication +--- +# Authentication + +<%= include('../../_includes/_authentication/_introduction.md', { platform: 'b2c' }) %> + +## Universal Login + +<%= include('../../_includes/_authentication/_universal-login.md', { platform: 'b2c' }) %> + +## Username and password authentication + +<%= include('../../_includes/_authentication/_username-and-password-authentication.md', { platform: 'b2c' }) %> + +## Application integration + +<%= include('../../_includes/_authentication/_application-integration.md', { platform: 'b2c' }) %> + +## Anomaly detection + +<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2c' }) %> + +## SSO with legacy systems + +<%= include('../../_includes/_authentication/_sso-legacy.md', { platform: 'b2c' }) %> + +## Social authentication + +<%= include('../../_includes/_authentication/_social-authentication.md', { platform: 'b2c' }) %> + +## Multi-factor authentication (MFA) + +<%= include('../../_includes/_authentication/_mfa.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'authentication' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md new file mode 100644 index 0000000000..4394f0b496 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md @@ -0,0 +1,39 @@ +--- +title: Authorization +description: User authorization and related planning considerations for your B2C IAM implementation. +toc: true +topics: + - b2c + - ciam + - user-authorization +contentType: concept +useCase: + - user-authorization +--- +# Authorization + +<%= include('../../_includes/_authorization/_introduction.md', { platform: 'b2c' }) %> + +## Application integration + +<%= include('../../_includes/_authorization/_application-integration.md', { platform: 'b2c' }) %> + +## API integration + +<%= include('../../_includes/_authorization/_api-integration.md', { platform: 'b2c' }) %> + +## Role Based Access Control (RBAC) + +<%= include('../../_includes/_authorization/_rbac.md', { platform: 'b2c' }) %> + +## Machine-to-Machine (M2M) Authorization + +<%= include('../../_includes/_authorization/_m2m.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'authorization' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-branding.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-branding.md new file mode 100644 index 0000000000..cba76c1648 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-branding.md @@ -0,0 +1,52 @@ +--- +title: Branding +description: How to configure Auth0 items to reflect your brand and desired user experience. +toc: true +topics: + - b2c + - ciam + - branding + - universal-login + - login-pages + - password-reset-pages + - custom-domains + - error-pages +contentType: concept +useCase: + - user-logout +--- +# Branding + +<%= include('../../_includes/_branding/_introduction.md', { platform: 'b2c' }) %> + +## Universal login and login pages + +<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2c' }) %> + +## Custom domain naming + +<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2c' }) %> + +## Email template customization + +<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2c' }) %> + +## Password reset page customization + +<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2c' }) %> + +## Error page customization + +<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2c' }) %> + +## Guardian multi-factor page customization + +<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'branding' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md new file mode 100644 index 0000000000..896280664b --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md @@ -0,0 +1,24 @@ +--- +title: Deployment Automation +description: How Auth0 tooling helps to automate tenant deployment. +topics: + - b2c + - ciam + - tenants + - deployment +contentType: concept +useCase: + - tenant-deployment +--- + +# Deployment Automation + +<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'deployment' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch.md new file mode 100644 index 0000000000..8eed687f5e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch.md @@ -0,0 +1,30 @@ +--- +classes: topic-page +title: Launch Preparation +description: Launch preparation considerations for your B2C IAM implementation. +topics: + - b2c + - ciam + - launch +contentType: concept +useCase: + - launch +--- +# Launch Preparation + +<%= include('../../_includes/_launch/_introduction.md', { platform: 'b2c' }) %> +<%= include('../../../_includes/_topic-links', { links: [ + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck', + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing', + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations', + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance', + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support', + 'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch' + ] }) %> + +## Project Planning Guide +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'launch' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md new file mode 100644 index 0000000000..1712d77cc6 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md @@ -0,0 +1,24 @@ +--- +title: Compliance Readiness +description: Compliance checks to perform before launch of your B2C IAM implementation. +topics: + - b2c + - ciam + - launch + - compliance +contentType: concept +useCase: + - launch +--- + +# Compliance + +<%= include('../../../_includes/_launch/_compliance.md', { platform: 'b2c' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md new file mode 100644 index 0000000000..3459fb54f8 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md @@ -0,0 +1,23 @@ +--- +title: Launch Day Preparation +description: Launch preparation considerations for your B2C IAM implementation. +topics: + - b2c + - ciam + - launch +contentType: concept +useCase: + - launch +--- + +# Launch Day Readiness + +<%= include('../../../_includes/_launch/_launch.md', { platform: 'b2c' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md new file mode 100644 index 0000000000..eb2a8942e8 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md @@ -0,0 +1,24 @@ +--- +title: Operations Readiness +description: Operations checks to perform before launch of your B2C IAM implementation. +topics: + - b2c + - ciam + - launch + - operations +contentType: concept +useCase: + - launch +--- + +# Operational Readiness + +<%= include('../../../_includes/_launch/_operations.md', { platform: 'b2c' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md new file mode 100644 index 0000000000..188827213e --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md @@ -0,0 +1,23 @@ +--- +title: Support Readiness +description: Support readiness for the launch of your B2C IAM implementation. +topics: + - b2c + - ciam + - launch + - support +contentType: concept +useCase: + - launch +--- + +# Support Readiness + +<%= include('../../../_includes/_launch/_support.md', { platform: 'b2c' }) %> + +# Project Planning Guide +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md new file mode 100644 index 0000000000..dc54e51cb3 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md @@ -0,0 +1,24 @@ +--- +title: Tenant Check +description: Tenant Checks to perform before launch of your B2C IAM implementation. +topics: + - b2c + - ciam + - launch + - configuration +contentType: concept +useCase: + - launch +--- + +# Tenant configuration check + +<%= include('../../../_includes/_launch/_tenant-check.md', { platform: 'b2c' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> \ No newline at end of file diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md new file mode 100644 index 0000000000..6e313784cb --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md @@ -0,0 +1,24 @@ +--- +title: Testing Complete +description: Testing preparation for the launch of your B2C IAM implementation. +topics: + - b2c + - ciam + - launch + - testing +contentType: concept +useCase: + - launch +--- + +# Testing + +<%= include('../../../_includes/_launch/_testing.md', { platform: 'b2c' }) %> + +# Project Planning Guide + +<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %> + +# Keep reading + +<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-logout.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-logout.md new file mode 100644 index 0000000000..79659c64c7 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-logout.md @@ -0,0 +1,23 @@ +--- +title: Logout +description: User logout planning considerations for your B2C IAM implementation. +topics: + - b2c + - ciam + - logout + - sessions +contentType: concept +useCase: + - user-logout +--- +# Logout + +<%= include('../../_includes/_logout/_introduction.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'logout' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-operations.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-operations.md new file mode 100644 index 0000000000..b10ab32dcc --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-operations.md @@ -0,0 +1,49 @@ +--- +title: Operations +description: How to operationalize your Auth0 tenant environments. +toc: true +topics: + - b2c + - ciam + - tenants + - operations +contentType: concept +useCase: + - tenant-operations +--- + +# Operations + +<%= include('../../_includes/_operations/_introduction.md', { platform: 'b2c' }) %> + +## Service status + +<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2c' }) %> + +## Email provider setup + +<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2c' }) %> + +## Infrastructure + +<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2c' }) %> + +## Logging + +<%= include('../../_includes/_operations/_logging.md', { platform: 'b2c' }) %> + +## Monitoring + +<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2c' }) %> + +## Notifications + +<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'operations' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md new file mode 100644 index 0000000000..5065318caf --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md @@ -0,0 +1,48 @@ +--- +title: Profile Management +description: User profile management planning considerations for your B2C IAM implementation. +toc: true +topics: + - b2c + - ciam + - user-profiles +contentType: concept +useCase: + - profile-management + - manage-user-profiles +--- +# Profile Management + +<%= include('../../_includes/_profile-mgmt/_introduction.md', { platform: 'b2c' }) %> + +## Metadata + +<%= include('../../_includes/_profile-mgmt/_metadata.md', { platform: 'b2c' }) %> + +## Password reset + +<%= include('../../_includes/_profile-mgmt/_password-reset.md', { platform: 'b2c' }) %> + +## Account verification + +<%= include('../../_includes/_profile-mgmt/_account-verification.md', { platform: 'b2c' }) %> + +## Blocking users + +<%= include('../../_includes/_profile-mgmt/_blocking-users.md', { platform: 'b2c' }) %> + +## Linking user accounts + +<%= include('../../_includes/_profile-mgmt/_linking-accounts.md', { platform: 'b2c' }) %> + +## De-provisioning + +<%= include('../../_includes/_profile-mgmt/_de-provisioning.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'profile-mgmt' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md new file mode 100644 index 0000000000..df2c065de1 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md @@ -0,0 +1,39 @@ +--- +title: Provisioning +description: User provisioning functionality and considerations for your B2C IAM implementation. +toc: true +topics: + - b2c + - ciam + - user-migration + - custom-db + - universal-login + - user-profiles +contentType: concept +useCase: + - user-provisioning + - store-user-data +--- +# Provisioning + +<%= include('../../_includes/_provisioning/_introduction.md', { platform: 'b2c' }) %> + +## User migration + +<%= include('../../_includes/_provisioning/_user-migration.md', { platform: 'b2c' }) %> + +## Self sign up + +<%= include('../../_includes/_provisioning/_self-signup.md', { platform: 'b2c' }) %> + +## Social sign up + +<%= include('../../_includes/_provisioning/_social-signup.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'provisioning' }) %> diff --git a/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-qa.md b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-qa.md new file mode 100644 index 0000000000..e27135e1cf --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/implementation/b2c/b2c-qa.md @@ -0,0 +1,36 @@ +--- +title: Quality Assurance +description: Quality Assurance considerations for your B2C IAM implementation. +toc: true +topics: + - qa + - b2c + - ciam + - quality +contentType: concept +useCase: + - quality-assurance +--- +# Quality Assurance + +<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2c' }) %> + +## Unit testing + +<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2c' }) %> + +## Integration testing + +<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2c' }) %> + +## Mock testing + +<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2c' }) %> + +## Project Planning Guide + +<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %> + +## Keep reading + +<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'qa' }) %> diff --git a/fr-ca/articles/architecture-scenarios/index.md b/fr-ca/articles/architecture-scenarios/index.md new file mode 100644 index 0000000000..5f1cf6d905 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/index.md @@ -0,0 +1,78 @@ +--- +url: /architecture-scenarios +classes: topic-page +title: Architecture Scenarios +description: Learn about the common architecture scenarios that you will use to solve the authorization and authentication needs of your application. +topics: + - architecture + - api-auth + - authorization-code + - b2c + - b2b + - ciam +contentType: index +useCase: + - invoke-api + - secure-an-api + - build-an-app + - implementation +--- + +
+
+

Architecture Scenarios

+

+ This page describes the typical architecture scenarios we have identified when working with customers on implementing Auth0. +

+
+ +## Application configurations + +These scenarios describe the different type of technology architectures your application may use, and how Auth0 can help for each of those. + +The goal of these scenarios is to walk you through the implementation process from beginning to end. + +
    +
  • + Business to Business Identity and Access Management +

    SaaS applications with users associated with third-party companies registered as tenants of the SaaS app.

    +
    • +
  • + Business to Consumer Identity and Access Management +

    SaaS/eCommerce apps with customers as end users using the OpenID Connect protocol.

    +
    • +
  • + Business to Employee Identity Scenarios +

    Enterprise directory services using federation to allow employees to log in to applications using their existing enterprise credentials.

    +
    • +
  • + Single Sign-On for Regular Web Apps +

    Traditional web application which needs to authenticate users using OpenID Connect (OIDC).

    +
    • +
  • + Server Application + API +

    Server to server communication where a server needs to make secure calls to an API.

    +
    • +
  • + SPA + API +

    Single-Page Web Application which talks to an API. The application will use OpenID Connect with the Implicit Grant Flow to authenticate users with Auth0.

    +
    • +
  • + Mobile + API +

    Mobile Application which talks to an API. The application will use OpenID Connect with the Authorization Code Grant using Proof Key for Code Exchange (PKCE) to authenticate users.

    +
    • +
+ +## Implementation checklists + +<%= include('./_includes/_implementation-checklists.md') %> + +## Implementation resources + +Auth0 provides many [resources](/architecture-scenarios/implementation-resources) to help you learn about Auth0, get started quickly, test sample code, and try out APIs. + +The Auth0 [Community](https://community.auth0.com) forum and [Blog](https://auth0.com/blog) connect you with the world of Auth0, while our [Support Center](https://support.auth0.com) helps you report issues and manage your subscription. Additionally, you can submit suggested product enhancements through our feedback portal. + +We've also made it easy to use our [Status Dashboard](https://status.auth0.com), monitor endpoints, and log data. Notifications keep you up-to-date with Auth0 announcements, and we provide a variety of methods to stay informed about privacy, security, and compliance. + +In addition, our [Professional Services](/services) team is available to help you with any architecture needs, including pre-launch advice, production checklists, and operational policies. diff --git a/fr-ca/articles/architecture-scenarios/mobile-api/_stepnav.html b/fr-ca/articles/architecture-scenarios/mobile-api/_stepnav.html new file mode 100644 index 0000000000..8e021cac76 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/mobile-api/_stepnav.html @@ -0,0 +1,14 @@ +
+ <% if (typeof prev !== 'undefined') { %> +
+
Previous Tutorial
+ ${prev[0]} +
+ <% } %> + <% if (typeof next !== 'undefined') { %> +
+
Next Tutorial
+ ${next[0]} +
+ <% } %> +
diff --git a/fr-ca/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md b/fr-ca/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md new file mode 100644 index 0000000000..7f02afc324 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md @@ -0,0 +1,256 @@ +--- +description: The Node.js implementation of the API for the Mobile + API architecture scenario +toc: true +topics: + - mobile-apps + - api-auth + - nodejs + - architecture + - authorization-code + - pkce +contentType: tutorial +useCase: + - invoke-api + - secure-an-api + - enable-mobile-auth + - build-an-app +--- + +# Mobile + API: Node.js Implementation for the API + +This document is part of the [Mobile + API Architecture Scenario](/architecture-scenarios/application/mobile-api) and it explains how to implement the API in Node.js. Please refer to the scenario for information on the implemented solution. + +::: note +The full source code for the Node.js API implementation can be found in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-api/node). +::: + +## 1. Define the API endpoints + +We will use the [Express web application framework](http://expressjs.com/) to build our Node.js API. + +### Create a package.json File + +Create a folder for your API, navigate into it and run `npm init`. This will setup your `package.json` file. + +You can leave the default settings or change them as you see fit. + +Our sample's `package.json` looks like the following: + +```json +{ + "name": "timesheets-api", + "version": "1.0.0", + "description": "API used to add timesheet entries for employees and contractors", + "main": "index.js", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1" + }, + "repository": { + "type": "git", + "url": "git+https://github.com/auth0-samples/auth0-pnp-timesheets.git" + }, + "author": "Auth0", + "license": "MIT", + "bugs": { + "url": "https://github.com/auth0-samples/auth0-pnp-timesheets/issues" + }, + "homepage": "https://github.com/auth0-samples/auth0-pnp-timesheets#readme" +} +``` + +### Install the Dependencies + +Next, we need to set our dependencies. We will use the following modules: + +- **express**: This module adds the [Express web application framework](https://expressjs.com/). + +- **cors**: This module adds support for enabling [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) which is required since the API will be called from a Single-Page Application running on a different domain inside a web browser. + +- **jwks-rsa**: This library retrieves RSA signing keys from a **JWKS** (JSON Web Key Set) endpoint. Using `expressJwtSecret` we can generate a secret provider that will provide the right signing key to `express-jwt` based on the `kid` in the JWT header. For more information refer to the [node-jwks-rsa GitHub repository](https://github.com/auth0/node-jwks-rsa). + +- **express-jwt**: This module lets you authenticate HTTP requests using JWT tokens in your Node.js applications. It provides several functions that make working with JWTs easier. For more information refer to the [express-jwt GitHub repository](https://github.com/auth0/express-jwt). + +- **body-parser**: This is a Node.js body parsing middleware. It extracts the entire body portion of an incoming request stream and exposes it on `req.body` as something easier to interface with.For more information and several alternatives refer to the body-parser GitHub repository. + +To install these dependencies run the following: + +```bash +npm install express cors express-jwt jwks-rsa body-parser express-jwt-authz --save +``` + +### Implement the Endpoints + +Navigate to your API directory and create a `server.js` file. Your code needs to: + +- Get the dependencies. +- Implement the endpoint(s). +- Launch the API server. + +This is our sample implementation: + +```js +const express = require('express'); +const app = express(); +const jwt = require('express-jwt'); +const jwksRsa = require('jwks-rsa'); +const cors = require('cors'); +const bodyParser = require('body-parser'); + +// Enable CORS +app.use(cors()); + +// Enable the use of request body parsing middleware +app.use(bodyParser.json()); +app.use(bodyParser.urlencoded({ + extended: true +})); + +// Create timesheets API endpoint +app.post('/timesheets', function(req, res){ + res.status(201).send({message: "This is the POST /timesheets endpoint"}); +}) + +// Launch the API Server at localhost:8080 +app.listen(8080); +``` + +Launch your API server using `node server` and make an HTTP POST request to `localhost:8080/timesheets`. You should see a JSON response with the message `This is the POST /timesheets endpoint`. + +So now we have our endpoint but anyone can call it. Continue to the next paragraph to see how we can fix this. + +## 2. Secure the API endpoints + +In order to validate our token we will use the `jwt` function, provided by the [express-jwt middleware](https://github.com/auth0/express-jwt#usage), and the `jwks-rsa` to retrieve our secret. The libraries do the following: + +1. `express-jwt` will decode the token and pass the request, the header and the payload to `jwksRsa.expressJwtSecret`. + +1. `jwks-rsa` will then download all signing keys from the JWKS endpoint and see if a one of the signing keys matches the `kid` in the header of the JWT. If none of the signing keys match the incoming `kid`, an error will be thrown. If we have a match, we will pass the right signing key to `express-jwt`. + +1. `express-jwt` will the continue its own logic to validate the signature of the token, the expiration, `audience` and the `issuer`. + +The steps we will follow in our code are: + +- Create the middleware function to validate the Access Token. +- Enable the use of the middleware in our routes. + +You can also write some code to actually save the timesheet to a database. This is our sample implementation (some code is omitted for brevity): + +```js +// set dependencies - code omitted + +// Enable CORS - code omitted + +// Create middleware for checking the JWT +const checkJwt = jwt({ + // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint + secret: jwksRsa.expressJwtSecret({ + cache: true, + rateLimit: true, + jwksRequestsPerMinute: 5, + jwksUri: `https://${account.namespace}/.well-known/jwks.json` + }), + + // Validate the audience and the issuer + audience: '{YOUR_API_IDENTIFIER}', //replace with your API's audience, available at Dashboard > APIs + issuer: 'https://${account.namespace}/', + algorithms: [ 'RS256' ] +}); + +// Enable the use of request body parsing middleware - code omitted + +// create timesheets API endpoint - code omitted +app.post('/timesheets', checkJwt, function(req, res){ + var timesheet = req.body; + + // Save the timesheet to the database... + + //send the response + res.status(201).send(timesheet); +}); +// launch the API Server at localhost:8080 - code omitted +``` + +If we launch our server now and do an HTTP POST to `localhost:8080/timesheets` we should get the error message `Missing or invalid token` (which is perfectly fine since we didn’t send an Access Token in our request). + +In order to test the working scenario as well we need to: + +- Get an Access Token. For details on how to do so refer to: [Get an Access Token](/architecture-scenarios/application/server-api#get-an-access-token). +- Invoke the API while adding an `Authorization` header to our request with the value `Bearer ACCESS_TOKEN` (where *ACCESS_TOKEN* is the value of the token we retrieved in the first step). + +## 3. Check the application permissions + +In this step we will add to our implementation the ability to check if the application has permissions (or `scope`) to use our endpoint in order to create a timesheet. In particular we want to ensure that the token has the correct scope, which is `batch:upload`. + +In order to do this we will make use of the `express-jwt-authz` Node.js package, so go ahead and add that to your project: + +```bash +npm install express-jwt-authz --save +``` + +Now it is as simple as adding a call to `jwtAuthz(...)` to your middleware to ensure that the JWT contain a particular scope in order to execute a particular endpoint. + +We will add an additional dependency. The **express-jwt-authz** library, which is used in conjunction with express-jwt, validates the [JWT](/tokens/concepts/jwts) and ensures it bears the correct permissions to call the desired endpoint. For more information refer to the [express-jwt-authz GitHub repository](https://github.com/auth0/express-jwt-authz). + +This is our sample implementation (some code is omitted for brevity): + +```js +// set dependencies - some code omitted +const jwtAuthz = require('express-jwt-authz'); + +// Enable CORS - code omitted + +// Create middleware for checking the JWT - code omitted + +// Enable the use of request body parsing middleware - code omitted + +// create timesheets API endpoint +app.post('/timesheets', checkJwt, jwtAuthz(['create:timesheets']), function(req, res){ + var timesheet = req.body; + + // Save the timesheet to the database... + + //send the response + res.status(201).send(timesheet); +}) + +// launch the API Server at localhost:8080 - code omitted +``` + +If we invoke our API with a token that does not include this scope we should get the error message Forbidden with the HTTP status code `403`. You can test this by removing this scope from your API. + +## 4. Determine the User Identity + +The `express-jwt` middleware which is used to validate the JWT, also sets the `req.user` with the information contained in the JWT. If you want to use the `sub` claim to identify the user uniquely, you can simply use `req.user.sub`. + +In the case of the timesheets application however, we want to use the email address of the user as the unique identifier. + +The first thing we need to do is to write a rule which will add the email address of the user to the Access Token. Go to the [Rules section](${manage_url}/#/rules}) of the Dashboard and click on the __Create Rule__ button. + +You can give the rule a descriptive name, for example `Add email to Access Token`, and then use the following code for the rule: + +```js +function (user, context, callback) { + const namespace = 'https://api.exampleco.com/'; + context.accessToken[namespace + 'email'] = user.email; + callback(null, user, context); +} +``` + +The `namespace` is used to ensure the claim has a unique name and does not clash with the names of any of the standard OIDC claims. For more info on namespaced claims, see [Namespacing Claims](/tokens/guides/create-namespaced-custom-claims). + +Next, inside your API, you can retrieve the value of the claim from `req.user`, and use that as the unique user identity which you can associate with timesheet entries. + +```js +app.get('/timesheets', checkJwt, jwtAuthz(['read:timesheets']), function(req, res) { + var timesheet = req.body; + + // Associate the timesheet entry with the current user + var userId = req.user['https://api.exampleco.com/email']; + timesheet.user_id = userId; + + // Save the timesheet to the database... + + //send the response + res.status(201).send(timesheet); +}); +``` diff --git a/fr-ca/articles/architecture-scenarios/mobile-api/index.md b/fr-ca/articles/architecture-scenarios/mobile-api/index.md new file mode 100644 index 0000000000..c96949af52 --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/mobile-api/index.md @@ -0,0 +1,60 @@ +--- +order: 04 +title: Mobile + API +image: /media/articles/architecture-scenarios/mobile-api.png +extract: Mobile application which talks to an API. The application will use OpenID Connect (OIDC) with the Authorization Code Grant using Proof Key for Code Exchange (PKCE) to authenticate users. +description: Explains the architecture scenario with a mobile application communicating with an API. +toc: true +topics: + - architecture + - mobile-apps + - api-auth + - authorization-code + - pkce +contentType: + - index + - tutorial +useCase: + - invoke-api + - secure-an-api + - enable-mobile-auth + - build-an-app +--- + +# Mobile + API + +In this scenario we will build a Timesheet API for a fictitious company named ExampleCo. The API will allow management of timesheet entries for an employee or a contractor. + +We will also be building a mobile application which will be used to view and log timesheet entries in the centralized timesheet database using the API. + + +::: panel TL;DR +* Auth0 provides API Authentication and Authorization as a means to secure access to API endpoints (see [API Authentication and Authorization](/architecture-scenarios/mobile-api/part-1#api-authentication-and-authorization)) +* For authorizing a mobile app user and granting access to the API, Auth0 supports the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) (see [Proof Key for Code Exchange](/architecture-scenarios/mobile-api/part-1#proof-key-for-code-exchange-pkce-)) +* Both the mobile app and the API must be configured in the Auth0 Dashboard (see [Auth0 Configuration](/architecture-scenarios/mobile-api/part-2)) +* User Permissions can be enforced using the Authorization Extension (see [Configure the Authorization Extension](/architecture-scenarios/mobile-api/part-2#configure-the-authorization-extension)) +* The API is secured by ensuring that a valid [Access Token](/tokens/concepts/access-tokens) is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/architecture-scenarios/mobile-api/part-3#secure-the-endpoints)) +* The Auth0.Android SDK can be used to authorize the user of the mobile app and obtain a valid Access Token which can be used to call the API (see [Authorize the User](/architecture-scenarios/mobile-api/part-3#authorize-the-user)) +* The mobile app can retrieve the user's profile information by decoding the ID Token (see [Get the User Profile](/architecture-scenarios/mobile-api/part-3#get-the-user-profile)) +* UI Elements can be displayed conditionally based on the scope that was granted to the user (see [Display UI Elements Conditionally Based on Scope](/architecture-scenarios/mobile-api/part-3#display-ui-elements-conditionally-based-on-scope)) +* The mobile app provides the Access Token in the HTTP Authorization header when making calls to the API (see [Call the API](/architecture-scenarios/mobile-api/part-3#call-the-api)) +* The mobile app user's Access Token can be renewed to ensure the user does not have to log in again during a session (see [Renew the Token](/architecture-scenarios/mobile-api/part-3#renew-the-token)) +::: + +## The Premise + +ExampleCo is a consulting startup company. Currently they have approximately 100 employees and they also outsource several activities to external contractors. All employees and external contractors are required to fill in their timesheets every week. + +The company has built a timesheets application, a scenario we covered in [Single Sign-On for Regular Web Apps](/architecture-scenarios/application/web-app-sso). The internal employees use this web app to fill in their timesheets, but the company wants a mobile application for employees and contractors to use while not on the premises. The app will be used to log timesheet entries and send the data to the centralized timesheet database using the API. The app will also allow managers to approve timesheet entries. + +### Goals & Requirements + +ExampleCo wants to build a flexible solution. There are potential multiple employees and contractors who should be able to log timesheet entries, as well as batch processes which may upload timesheet entries from other, external systems. + +Hence the company has decided to develop a single Timesheets API which will be used to log time not only by this mobile app, but by all other apps as well. They want to put in place a security architecture that is flexible enough to accommodate this. ExampleCo wants to ensure that a large part of the code and business logic for the application can be shared across the different applications. + +It is required that only authorized users and applications are allowed access to the Timesheets API. + +<%= include('./_stepnav', { + next: ["1. Solution Overview", "/architecture-scenarios/mobile-api/part-1"] +}) %> diff --git a/fr-ca/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md b/fr-ca/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md new file mode 100644 index 0000000000..13dabfaf1c --- /dev/null +++ b/fr-ca/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md @@ -0,0 +1,1418 @@ +--- +description: The Android implementation of the API for the Mobile + API architecture scenario +toc: true +topics: + - mobile-apps + - api-auth + - android + - architecture + - authorization-code + - pkce +contentType: tutorial +useCase: + - invoke-api + - secure-an-api + - enable-mobile-auth + - build-an-app +--- + +# Mobile + API: Android Implementation for the Mobile App + +This document is part of the [Mobile + API Architecture Scenario](/architecture-scenarios/application/mobile-api) and it explains how to implement the mobile application in Android. Please refer to the scenario for information on the implemented solution. + +## 1. Set Up the Application + +<%= include('../../_includes/_package', { + org: 'auth0-samples', + repo: 'auth0-pnp-exampleco-timesheets', + path: 'timesheets-mobile/android', + requirements: [ + 'Android Studio 2.3', + 'Android SDK 25', + 'Emulator - Nexus 5X - Android 6.0' + ] +}) %> + +### Set the Dependencies + +For this implementation, we will use the following dependencies within the app’s `build.gradle` file: + +- [Auth0.Android](https://github.com/auth0/Auth0.Android): this package enables integration with Auth0 to authenticate users. +- [OkHttp](http://square.github.io/okhttp/): this package provides an HTTP application to make requests to the Node.JS API. +- [JWTDecode.Android](https://github.com/auth0/JWTDecode.Android): this package will assist with decoding JWTs. +- AppCompat: this package lets us use the toolbar widget for navigation in our activities. + +```gradle +dependencies { + compile 'com.squareup.okhttp:okhttp:2.7.5' + compile 'com.auth0.android:auth0:1.10.0' + compile 'com.auth0.android:jwtdecode:1.1.1' + compile 'com.android.support:appcompat-v7:25.3.1' + testCompile 'junit:junit:4.12' +} +``` + +### Update the Manifest + +Open the application's `AndroidManifest.xml` and add the internet permission: + +```xml + +``` + +We’ll also update the application details to utilize the Toolbar widget: + +```xml + + +``` + +### Set Configuration Values + +Set your Auth0 Client ID, Auth0 Domain, and API’s url in the `strings.xml` resource located in `/res/values/strings.xml`: + +```xml + + ExampleCo Timesheets + Log in + ... + ... + http://10.0.2.2:8080/timesheets + +``` + +### Create Package Structure + +For this implementation, create directories for activities, models, and utils in the application package. + +- `activities/`: this package will contain the `LoginActivity.java`, `TimeSheetActivity.java`, `FormActivity.java`, and `UserActivity.java`. +- `models/`: this package will contain the `TimeSheet.java` and `User.java` data models. +- `utils/`: this package will contain the `UserProfileManager.java`, `TimeSheetAdapter.java`, and `ImageTask.java` + +## 2. Authorize the User + +### Update the Manifest + +Open the app's `AndroidManifest.xml` and add the `LoginActivity`: + +```xml + + + + + + + + + + + + + + + + +``` + +### Create the Login Activity Layout + +Next create `login_activity.xml`, the layout for the `LoginActivity`: + +```xml + + + + + + +``` + +After copying the changes to your S3 bucket, attempt to remove a pet while logged in as a social user. + +##### Update the Home Controller Logic to Allow Social Users to Purchase Pets + +In `home.js`, modify the `buyPet` function to enable pet purchases: + +```js +function buyPet(user, id) { + var apigClient = getSecureApiClient(); + + apigClient.petsPurchasePost({},{userName:user, petId:id}) + .then(function(response) { + console.log(response); + $scope.pets = response.data; + $scope.$apply(); + }).catch(function (response) { + alert('buy pets failed'); + showError(response); + }); +} +… +``` + +Copy the code to your S3 bucket, log out, and then log back in in as a social user by clicking on the Amazon icon in the Lock login dialog. You may need to click **SHOW ALL** if your previous login persists in the Lock pane. + +![Login using AWS](/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png) + +Note that, as an Amazon user, you can buy a pet, but not add or remove pets. However, if you log in with a user associated with a Database Connection, you are able to add and remove pets, but not buy pets. + +### Enforce Role Assignment with Auth0 Rules + +In some cases, you might determine the appropriate role using the Application (as shown here), but for security reasons (you might want to prevent the user from assuming a more privileged role than necessary), you might want to determine user privileges on the server-side. + +With Auth0, this is done via [rules](/rules), which are service logic statements you define that are then run during the Auth0 authentication process. For example, you could create rules to: + +* Eliminate the passing of role information from the browser to the Application; +* Insert role information into the delegation request based on the authentication source. + +#### Enforce Role Assignment + +You will add a rule that will check to see if the role requested by the user is allowed, depending on its association with a Social or Database Connection. + +Go to the [Auth0 Management Dashboard](${manage_url}), and click on **Rules** in the left-hand menu. + +Click the **+ Create Rule** button near the top left of the screen. + +![Dashboard Rules Screen](/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png) + +At this point, you will be asked to pick a rule template. Select the one for **empty rule**. + +![Choose Rules Template](/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png) + +You will now edit the empty rule. First, name the rule *AWS Pets Rule* (or something similar). Then, populate the body of the rule with the following JavaScript code: + +```js +function (user, context, callback) { + if(context.clientID === '${account.clientId}') { + var socialRoleInfo = { + role:"arn:aws:iam:::role/auth0-api-social-role", + principal: "arn:aws:iam::your account>:saml-provider/auth0" + }; + + var adminRoleInfo = { + role:"arn:aws:iam:::role/auth0-api-role", + principal: "arn:aws:iam:::saml-provider/auth0" + }; + + var requestRole = context.request.body.role; + var requestPrincipal = context.request.body.principal; + var allowedRole = null; + + if(user.identities[0].isSocial === false) { + allowedRole = adminRoleInfo; + } else { + allowedRole = socialRoleInfo; + } + + if((requestRole && requestRole !== allowedRole.role) || + (requestPrincipal && requestPrincipal !== allowedRole.principal)) { + console.log('mismatch in requested role:',requestRole, ':', requestPrincipal); + console.log('overridding'); + } else { + console.log('valid or no role requested for delegation'); + } + + context.addonConfiguration = context.addonConfiguration || {}; + context.addonConfiguration.aws = context.addonConfiguration.aws || {}; + context.addonConfiguration.aws.role = allowedRole.role; + context.addonConfiguration.aws.principal = allowedRole.principal; + callback(null, user, context); + + } else { + callback(null, user, context); + } +} +``` + +Be sure to adjust the above code with the correct values for your integration. The fields are: + +* `Princial` ARN: +* `Role` ARN; +* Client Secret + +**Save** your changes. + +#### Caveats + +* Rules run at a global scope for every authentication. You should only run the logic on authentication requests associated with a given application (which is why the script used asks for the *clientID*. Without this information, the logic runs for every authentication request associated with your Auth0 account. +* Information is passed into the rule with the *context* and the *user*. +* You can extend the objects passed in to the rule. In the code above, the rule checks the body of the request for the role information. The role is set into the context *addonConfiguration* of the allowed role, which always overrides settings in the request body. + +#### Debug Your Rule + +At this point, you are ready to debug your rule(s). Click **Try This Rule**, and you will be presented with a script that tries the rule's logic. + +![Try Rule Script](/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png) + +At the bottom of the screen, click **Try**. + +![Try Rule Button](/media/articles/integrations/aws-api-gateway/part-4/try-button.png) + +You will then be presented with the output of running your rule. + +![Output from Trying Rules](/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png) + +<%= include('./_stepnav', { + prev: ["3. Building the Application", "/integrations/aws-api-gateway/delegation/part-3"], + next: ["5. Using Identity Tokens", "/integrations/aws-api-gateway/delegation/part-5"] +}) %> diff --git a/fr-ca/articles/integrations/aws-api-gateway/delegation/part-5.md b/fr-ca/articles/integrations/aws-api-gateway/delegation/part-5.md new file mode 100644 index 0000000000..0b8697e298 --- /dev/null +++ b/fr-ca/articles/integrations/aws-api-gateway/delegation/part-5.md @@ -0,0 +1,177 @@ +--- +title: Amazon API Gateway Tutorial - Flowing Identity +description: Step 5 of Amazon API Gateway Tutorial +topics: + - integrations + - aws + - api-gateway +contentType: tutorial +useCase: + - secure-an-api +--- +# AWS API Gateway Tutorial + +<%= include('./_delegation-version-warning') %> + +## Step 5 - Use Identity Tokens to Flow Identity + +In this final step, you will: + +* Flow identity to the service by passing your OpenID JSON Web Token (JWT); +* Validate the token; +* Extract profile information to assign a buyer for a pet. + +## Use an Identity Token + +You can use your Lambda function to process and obtain information about the user. For example, during a purchasing transaction, you retrieved the username from the profile returned with the identity token. However, you can also choose to have the user's information embedded with the identity itself, which is a JSON Web Token (JWT). + +The advantages of using JWTs is that you can: + +1. Verify the authenticity of the JWT; +2. Be sure that the calling user is authenticated (instead of relying on a plain-text parameter that could have been tampered with). + +In addition, you can use the JWT for authorization, which allows you to bypass the IAM integration with Amazon API Gateway. Please note, however, that using the API Gateway for authorization allows you to halt the API call prior to invocation of your Lambda function. + +![AWS Identity Flow](/media/articles/integrations/aws-api-gateway/identity-flow.png) + +### Add Information to the JWT + +There are several ways of adding a user's information to the JWT. The following example adds the user's email address to the JWT, but the concepts are same for other user datapoints. + +#### Use Rules + +One way to add a user's email address to the JWT is to use a [rule](/rules). This is a good approach if you want to make sure that this value is always available in the JWT for an authenticating user. + +In `login.js`, you can see this scope specified in the parameters passed to `auth.signin`: + +```js +$scope.login = function() { + var params = { + authParams: { + scope: 'openid email' + } + }; + + auth.signin(params, function(profile, token) { + ... + } + } +``` + +While you can include the full profile of the user within the JWT, you will want to include only what is necessary since the JWT is typically passed with *every* request. + +## Validate the JWT Token + +Because the AWS Lambda console has access to a limited number of Node modules that can be used when you enter your Node.js code using the browser console, you'll need to include additional modules and upload the Lambda function as a package to process the identity token. + +::: note +For additional details, see [Creating Deployment Packages using Node.js](http://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-deployment-pkg.html) and [Uploading Deployment Packages and Testing](http://docs.aws.amazon.com/lambda/latest/dg/walkthrough-s3-events-adminuser-create-test-function-upload-zip-test.html). +::: + +The following seed project contains the code you'll need for your updated AWS Lambda function. + +<%= include('../../../_includes/_package', { + org: 'auth0', + repo: 'auth0-aws', + path: 'examples/api-gateway/lambda' +}) %> + +You'll see two custom JavaScript files within the seed project: + +* `index.js`: contains your main code; +* `auth0-variables`: contains the code you need to update. + +In addition to the custom files, there is a standard Node.js `package.json` file. + +The code adds functionality to extract information from and validate the JWT. By default, Auth0 uses a symmetric key for signing the JWT, though you may opt to use asymmetric keys (if you need to allow third-party validation of your token, you should use an asymmetric key and share only your public key). + +>For more information about token verification, see [Identity Protocols Supported by Auth0](/protocols). + +Update `auth0-variables.js` with your secret key, which can be found on the *Settings* tab of your Application in the Auth0 Dashboard: + +```js +var env={}; +env.AUTH0_SECRET='ADD-YOUR-SECRET'; +module.exports = env; +``` + +Run **npm install** from the directory where your files are, zip up the contents (`index.js` must be at the root of the zip), and upload it for use by the `PurchasePet` Lambda function. If you test this, you should see an authorization failure, since the JWT is not in the message body. + +Take a look at the logic in `index.js`. You will see logic around line 60 that validates the token and extracts the decoded information that contains the identity information used for the purchase logic: + +```js + if(event.authToken) { + jwt.verify(event.authToken, secret, function(err, decoded) { + if(err) { + console.log('failed jwt verify: ', err, 'auth: ', event.authToken); + context.done('authorization failure', null); + } else if(!decoded.email) + { + console.log('err, email missing in jwt', 'jwt: ', decoded); + context.done('authorization failure', null); + } else { + userEmail = decoded.email; + console.log('authorized, petId', petId, 'userEmail:', userEmail); + dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, readcb); + } + }); + } else { + console.log('invalid authorization token', event.authToken); + context.done('authorization failure', null); + } + ... +``` + +### Extract Profile Information to Assign a Buyer + +The final step is to pass the JWT to the method used by the browser client. + +The standard method comes with an `Authorization` header as a *bearer* token, and you can use this method by turning off IAM authorization and relying solely on the OpenID Token for authorization (you will also need to map the Authorization header into the event data passed to the AWS Lambda function). + +If, however, you are using IAM, then the AWS API Gateway uses the `Authorization` header to contain the signature of the message, and you will break the authentication by inserting the JWT into this header. To do this, you can either: + +* Add a custom header for the JWT; +* Put the custom header into the body of the message. + +If you choose to use a custom header, you'll also need to do some mapping for the *Integration Request* of the *POST* method for `pets/purchase`. + +To keep the validation process simple, pass the JWT in the body of the post to the AWS Lambda function. To do this, update the `buyPet` method in `home.js` by removing the `userName` from the body, and adding `authToken` as follows: + +```js +function buyPet(user, id) { + var apigClient = getSecureApiClient(); + var body = { + petId:id, + authToken: store.get('token') + }; + + apigClient.petsPurchasePost({}, body) + .then(function(response) { + console.log(response); + $scope.pets = response.data; + $scope.$apply(); + }).catch(function (response) { + alert('buy pets failed'); + showError(response); + }); +} +``` + +Upload your code to your S3 bucket and try to purchase a pet. You will see the email of the purchaser in the resulting message. + +If you have any errors, double check that you have properly set your secret key. One useful tool for checking issues with your token decoding is [jwt.io](http://jwt.io/). + +## Summary + +In this tutorial, you have: + +* Created an API using AWS API Gateway that includes methods using AWS Lamdba functions; +* Secured access to your API using IAM roles; +* Integrated a SAML identity provider with IAM to tie access to the API to your user base; +* Provided different levels of access based on whether a user authenticated from the Database or Social Connection; +* Used an Auth0 rule to enforce role assignment; +* Used a JWT to provide further authorization context and pass identity information into the appropriate Lambda function. + +<%= include('./_stepnav', { + prev: ["4. Using Multiple Roles", "/integrations/aws-api-gateway/delegation/part-4"] +}) %> diff --git a/fr-ca/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md b/fr-ca/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md new file mode 100644 index 0000000000..09bdb2005f --- /dev/null +++ b/fr-ca/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md @@ -0,0 +1,59 @@ +--- +title: Amazon API Gateway Tutorial - Secure AWS API Gateway Using Cognito +description: How to secure the API Gateway Tutorial using Cognito instead of IAM roles and policies. +topics: + - integrations + - aws + - api-gateway + - cognito +contentType: tutorial +useCase: + - secure-an-api +--- + +# Secure AWS API Gateway Using Cognito + +Instead of using IAM roles and policies to secure your API, you can do so using user pools in Amazon Cognito. + +::: note +Please [create the appropriate Amazon Cognito User Pools](http://docs.aws.amazon.com/cognito/latest/developerguide/setting-up-cognito-user-identity-pools.html) prior to beginning this tutorial. +::: + +## Integrate the Cognito User Pool with the API Gateway API + +Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway). Using the left-hand navigation bar, select the **SecurePets** API. + +Then, select **Authorizers** for the **SecurePets** API. + +![API nav area to select authorizers](/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png) + +On the *Authorizers* column near the center of the screen, choose **Create** and indicate that you are creating a **Cognito User Pool Authorizer**. + +![API config page for authorizers](/media/articles/integrations/aws-api-gateway/config-authorizer.png) + +To configure your authorizer: + +1. Choose the **Cognito region** in which you created your User Pool. +2. Customize the **Authorizer name** field, if desired (it will be automatically populated with the name of the chosen User Pool, so you can opt to leave it as is) +3. Customize the **Identity token source** field. By default, this field is set to `method.request.header.Authorization`, which sets the name of the incoming request header containing the API caller's identity token to `Authorization`. +4. If desired, add a regular expression to the **App client ID regex** field to validate client IDs associated with the User Pool. + +When you've finished configuring your authorizer, click **Create** to integrate the User Pool with your API. + +## Enable the User Pool Authorizer on Methods + +For each method that you want the User Pool to act as an authorizer, you must enable the User Pool to do so for that particular method. + +To enable the User Pool authorizer on the `GET` method: + +1. After selecting the *SecurePets* API, select the `GET` method listed under `/pets`. + + ![enabling authorizer for API method](/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png) + +2. Click on **Method Request**. +3. Under *Authorization Settings*, click on the **edit icon** next to the *Authorization* field. +4. Choose the appropriate Cognito User Pool authorizer from the list. Click the **checkmark icon** to save your selection. + + ![selecting authorizer for a given API method](/media/articles/integrations/aws-api-gateway/set-authorizer.png) + +Repeat this process for any additional methods for which you want the Cognito User Pool to act as an authorizer (`GET` and `PURCHASE` for `/pets`, as well as `POST` for `/purchase`). diff --git a/fr-ca/articles/integrations/aws-api-gateway/index.yml b/fr-ca/articles/integrations/aws-api-gateway/index.yml new file mode 100644 index 0000000000..0ed4f10449 --- /dev/null +++ b/fr-ca/articles/integrations/aws-api-gateway/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: integrations/aws-api-gateway + current: custom-authorizers + versions: + - custom-authorizers + - delegation + defaultArticles: + custom-authorizers: index + delegation: index diff --git a/fr-ca/articles/integrations/aws/aws-api-setup.md b/fr-ca/articles/integrations/aws/aws-api-setup.md new file mode 100644 index 0000000000..4612c92ce4 --- /dev/null +++ b/fr-ca/articles/integrations/aws/aws-api-setup.md @@ -0,0 +1,130 @@ +--- +description: How to Set Up AWS for Delegated Authentication +url: /aws-api-setup +toc: true +topics: + - integrations + - aws +contentType: how-to +useCase: secure-an-api +--- +# How to Set Up AWS for Delegated Authentication + +This doc will walk you through setting up AWS for delegated authentication. You'll need to perform these steps any time you want to use Auth0 with AWS. Note that this tutorial does not walk you through a full integration. See the [Configure Single Sign-on (SSO) with the AWS Console](/integrations/aws/sso) or [API Gateway](/integrations/aws-api-gateway) tutorials for complete examples. + +## Step 1: Create a SAML Provider in AWS + +Log in to AWS, and navigate to the [IAM console](https://console.aws.amazon.com/iam). Using the left-hand navigation menu, select **Identity Providers**. Click **Create Provider**. + +![](/media/articles/integrations/aws/create-provider.png) + +Set the following parameters: + +| Parameter | Description and Sample Value | +| - | - | +| Provider Type | The type of provider. Set as `SAML` | +| Provider Name | A descriptive name for the provider, such as `auth0SamlProvider` | +| Metadata Document | Upload the file containing the Auth0 metadata, found in **Dashboard > Applications > Application Settings > Advanced Settings > Endpoints > SAML Metadata URL** | + +![](/media/articles/integrations/aws/aws-configure-provider.png) + +Click **Next Step**. Verify your settings and click **Create** if everything is correct. + +![](/media/articles/integrations/aws/create-provider-confirm.png) + +## Step 2: Create a Role for Your SAML Provider + +To use the provider, you must create an IAM role using the provider in the role's trust policy. + +In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home#/roles). Click **Create role**. + +![](/media/articles/tutorials/aws/roles1.png) + +You'll be redirected to the **Trust** page. Indicate **Saml 2.0 federation** under **Select type of trusted entity**. + +![](/media/articles/tutorials/aws/roles3.png) + +Provide the following values: + +| Parameter | Value | +| - | - | +| SAML Provider | The name for your new role | +| Attribute | `SAML:iss` | +| Value | `urn:${account.namespace}` | + +![](/media/articles/tutorials/aws/roles4.png) + +Click **Next: Permissions** to proceed. + +You will need to attach permissions policies to your new role. You'll attach a custom policy. To create one, click **Create Policy**. + +![](/media/articles/tutorials/aws/roles5.png) + +In the **Create policy** editor that launches, switch over to the **JSON** tab. + +![](/media/articles/tutorials/aws/roles6.png) + +Provide a custom policy. + +```text +{ + "Version": "2012-10-17", + "Statement": [{ + "Effect": "Allow", + "Action": [ + "*" + ], + "Resource": [ + "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>", + "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>/*"] + }] +} +``` + +This defines the permissions that users granted this role will have with AWS. Click **Review policy**. + +![](/media/articles/tutorials/aws/roles7.png) + +Review the policy that you've created. Be sure to provide a **Name** for your policy and (optionally) a **Description**. + +Click **Create policy** when done. + +![](/media/articles/tutorials/aws/roles8.png) + +If successful, you'll see the following message confirming the creation of your new policy. + +![](/media/articles/tutorials/aws/roles9.png) + +Returning to the role creation wizard (you should be on step **2 - Permissions**), find the new policy you just create and click its checkbox to attach the policy to your role. We recommend using the **Customer managed** filter to find your policy. + +Click **Next: Review** to proceed. + +![](/media/articles/tutorials/aws/roles11.png) + +Review the information about your role, provide a **Role name** and (optionally) a **Role description**. You'll see the policy you attached as well. If everything looks correct, click **Create role** to proceed. + +![](/media/articles/tutorials/aws/roles12.png) + +Once created, you can find your roles located on the primary **Roles** page. + +![](/media/articles/tutorials/aws/roles13.png) + +## Copy the ARN Values + +The following instructions will show you where you can find the Provider and Role ARN values. + +### Provider ARN + +In the IAM console, navigate to [Identity providers](https://console.aws.amazon.com/iam/home#/providers). Select the role in which you're interested to open up its summary page. Copy the **Provider ARN** value, which is listed first under **Summary**. + +![](/media/articles/tutorials/aws/provider-summary.png) + +### Role ARN + +In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home#/roles). Select the role in which you're interested to open up its summary page. Copy the **Role ARN** value, which is listed first under **Summary**. + +![](/media/articles/tutorials/aws/role-summary2.png) + +### Next Steps + +* [AWS Services Supported by IAM](http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html). diff --git a/fr-ca/articles/integrations/aws/index.md b/fr-ca/articles/integrations/aws/index.md new file mode 100644 index 0000000000..e61b193cd1 --- /dev/null +++ b/fr-ca/articles/integrations/aws/index.md @@ -0,0 +1,41 @@ +--- +classes: topic-page +title: Amazon Web Services (AWS) +url: /integrations/aws +topics: + - integrations + - aws +contentType: index +useCase: + - secure-an-api + - integrate-third-party-apps +--- + +
+
+

Integrate Auth0 with Amazon Web Services (AWS)

+

+ Auth0 supports integration with AWS' Identity and Access Management (IAM) service. +

+
+ + \ No newline at end of file diff --git a/fr-ca/articles/integrations/aws/session-tags.md b/fr-ca/articles/integrations/aws/session-tags.md new file mode 100644 index 0000000000..d147362eae --- /dev/null +++ b/fr-ca/articles/integrations/aws/session-tags.md @@ -0,0 +1,152 @@ +--- +title: Use AWS Session Tags with AWS APIs and Resources +description: Learn how to use AWS Session Tags to implement role-based access control (RBAC) for AWS APIs and Resources. +toc: true +topics: + - integrations + - aws + - session-tags + - rbac +contentType: how-to +useCase: + - secure-an-api + - integrate-third-party-apps + - integrate-saas-sso +--- +# Use AWS Session Tags with AWS APIs and Resources + +With AWS Session Tags, you can tag resources and assign users key/value pairs, which allows you to implement role-based access control (RBAC) for AWS APIs and Resources. + +In the example included in this guide, we will tag our AWS resources with AWS Session Tags, then create a policy for an AWS IAM role that will allow users with this role and the appropriate tags to perform specific actions on our AWS resources. We will then create a rule in Auth0 that will attach our AWS IAM role and appropriate AWS Session Tags to an Auth0 user and pass them through SAML assertions in the token. This example builds on the example provided in our [Configure Single-Sign-on (SSO) with the AWS Console](/integrations/aws/sso) guide. + +## Prerequisites + +::: panel Amazon Web Services (AWS) Account +Before proceeding, you will need a valid [Amazon Web Services (AWS) account](https://portal.aws.amazon.com/billing/signup#/start) for which you are an administrator. +::: + +**Before beginning this guide:** + +* [Configure Single Sign-on (SSO) with the AWS Console](/integrations/aws/sso) +* [Set up some AWS VM Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance). For the example in this guide, we use three separate instances. + +## Steps + +To use AWS Session Tags with AWS APIs and Resources, you must: + +1. [Tag AWS instances](#tag-aws-instances) +2. [Create a specialized AWS IAM role](#create-a-specialized-AWS-IAM-role) +3. [Create an Auth0 rule](#create-an-auth0-rule) +4. [Test your setup](#test-your-setup) + +### Tag AWS instances + +First, you'll need to add tags to your AWS resources. To learn how to do so, follow instructions in [Amazon Elastic Compute Cloud User Guide for Linux Instances: Adding and Deleting Tags on an Individual Resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). + +For the example in this guide, you should have created three instances. Add the following tags: + +| Instance | Tags | +| -------- | ---- | +| 1  | Key: `CostCenter`, Value: `marketing`.
Key: `Project`, Value: `website`. | +| 2  | Key: `CostCenter`, Value: `engineering`.
Key: `Project`, Value: `management_dashboard`. | +| 3  | Key: `CostCenter`, Value: `marketing`.
Key: `Project`, Value: `community_site`. | + +### Create a specialized AWS IAM role + +Now, create an IAM role using the AWS SAML identity provider you set up during the [prerequisites for this guide](#prerequisites).  + +To learn how to set up an IAM user role with AWS, follow [AWS Identity and Access Management User Guide: Creating a Role for SAML 2.0 Federation (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html). + +While setting up your role, make sure you use the following parameters: + +| Parameter | Description and Sample Value | +| --------- | ---------------------------- | +| SAML Provider | Name of the identity provider you created in the prerequisites, such as `auth0SamlProvider`. Select **Allow programmatic and AWS Management Console access**. | + +When asked to **Attach permissions policies**, create a policy with the following JSON and name it `VirtualMachineAccessByCostCenter`. + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "ec2:DescribeInstances" + ], + "Resource": "*" + }, + { + "Effect": "Allow", + "Action": [ + "ec2:StartInstances", + "ec2:StopInstances" + ], + "Resource": "*", + "Condition": { + "StringEquals": { + "ec2:ResourceTag/CostCenter": "<%= "${aws:PrincipalTag/CostCenter}" %>" + } + } + } + ] +} +``` + +Once the policy has been created, refresh the policy list for the role, then filter and select the new policy. + +When reviewing your settings, make sure you use the following parameters: + +| Parameter | Description |  +| --------- | ----------- | +| Role name | Descriptive name for your role, such as `AccessByCostCenter`. | +| Role description | Description of the purpose for which your role is used. | + +### Create an Auth0 rule + +To map the AWS role and tags to a user, you'll need to create a [rule](/rules) in Auth0. These values will then be passed through the SAML assertions in the token. + +For the example in this guide, [create the following rule](/dashboard/guides/rules/create-rules): + +::: note +Notice that you'll need to replace the `awsAccount` variable value with your own account number. +::: + +```js +function(user, context, callback) { + var awsAccount = '013823792818'; + var rolePrefix = `arn:aws:iam::` + awsAccount; + var samlIdP = rolePrefix + `:saml-provider/auth0SamlProvider`; + + user.awsRole = rolePrefix + `:role/AccessByCostCenter,` + samlIdP; + user.awsRoleSession = user.email; + user.awsTagKeys = ['CostCenter', 'Project']; + user.CostCenter = 'marketing'; + user.Project = 'website'; + + context.samlConfiguration.mappings = { + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession', + 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter': 'CostCenter', + 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project': 'Project' + }; + + callback(null, user, context); +} +``` + +### Test your setup + +You should now be able to log in to the AWS Console using an Auth0 user and test your implementation. + +To log in, you will need the SSO login for the AWS Console. To find it: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +2. Click **Add-ons**, then the **SAML2 Web App** add-on. + +3. Click the **Usage** tab, and locate **Identity Provider Login URL**. Navigate to the indicated URL. + +Once you have signed in, from **EC2**, select **Instances**. Click one of the instances tagged with a `CostCenter` of `marketing`, and click **Actions** > **Instance State** > **Stop**. Notice that the action completes successfully. + +Next, click the instance tagged with a `CostCenter` of `engineering`, and click **Actions** > **Instance State** > **Stop**. Notice that the action fails with an error. diff --git a/fr-ca/articles/integrations/aws/sso.md b/fr-ca/articles/integrations/aws/sso.md new file mode 100644 index 0000000000..cd4f6d2506 --- /dev/null +++ b/fr-ca/articles/integrations/aws/sso.md @@ -0,0 +1,211 @@ +--- +description: Learn how to use Single Sign-on (SSO) with AWS using the SAML2 Web App addon. +toc: true +topics: + - integrations + - aws + - sso +contentType: how-to +useCase: + - secure-an-api + - integrate-third-party-apps + - integrate-saas-sso +--- + +# Configure Single Sign-On with the AWS Console + +By integrating Auth0 with AWS, you'll allow your users to log in to AWS using any supported [identity provider](/identityproviders). + +## Configure external Identity Provider in AWS + +Set up an external identity provider in AWS using AWS's [Connect to your External Identity Provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) doc--with one slight change. Rather than downloading the AWS metadata file, click **Show Individual Metadata Values**, and copy the **AWS SSO issuer URL** and **AWS SSO ACS URL**. You will use these in the next section. + +Leave this page open in your browser, as you'll need to complete configuration in a future section. + +## Configure Auth0 + +1. Log in to the [Auth0 Dashboard](${manage_url}/#/applications), and create a new [Application](/application) (you can also use an existing Application if you'd like). On the **Addons** tab, enable the **SAML2 Web App** addon. + + ![Applications](/media/articles/dashboard/guides/app-list.png) + +2. When the configuration pop-up appears, on the **Settings** tab, populate **Application Callback URL** with `https://signin.aws.amazon.com/saml`. + + ![SAML2 Web App Settings](/media/articles/integrations/aws/configure.png) + +Then paste the following SAML configuration code into **Settings**. Be sure to replace the AWS_SSO_ISSUER_URL and AWS_SSO_ACS_URL placeholders with the values you copied from AWS in the previous section. + +```js +{ + "audience": "AWS_SSO_ISSUER_URL", + "destination": "AWS_SSO_ACS_URL", + "mappings": { + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +3. Scroll to the bottom, and click **Enable**. + +4. Click over to the **Usage** tab. You'll need to complete your AWS configuration of Auth0 as the external identity provider (IdP) in the next section, which requires you to provide the appropriate metadata to AWS. To download a file containing this information, click **Identity Provider Metadata**. + + ![SAML2 Web App Usage](/media/articles/integrations/aws/idp-download.png) + +## Complete external Identity Provider configuration in AWS + +Return to the AWS SSO page you left open during the first section, and upload the metadata file you downloaded and saved in the previous section. Review and Confirm that you are changing the identity source. + +## Create an AWS IAM Role + +To use the provider, you must create an IAM role using the provider in the role's trust policy. + +1. In the sidebar, under **Access Management**, navigate to **[Roles](https://console.aws.amazon.com/iam/home#/roles)**. Click **Create Role**. + +2. On the next page, you will be asked to select the type of trusted entity. Select **SAML 2.0 Federation**. + +3. When prompted, set the provider you created above as the **SAML provider**. Select **Allow programmatic and AWS Management Console access**. Click **Next** to proceed. + +4. On the **Attach Permission Policies** page, select the appropriate policies to attach to the role. These define the permissions that users granted this role will have with AWS. For example, to grant your users read-only access to IAM, filter for and select the `IAMReadOnlyAccess` policy. Once you are done, click **Next Step**. + +5. The third **Create Role** screen is **Add Tags**. You can use tags to organize the roles you create if you will be creating a significant number of them. + +6. On the **Review** page, set the **Role Name** and review your settings. Provide values for the following parameters: + + | Parameter | Definition | + | - | - | + | Role name | A descriptive name for your role | + | Role description | A description of what your role is used for | + +7. Review the **Trusted entities** and **Policies** information, then click **Create Role**. At this point, you'll have created the necessary role to associate with your provider. + +## Map the AWS Role to a User + +::: note +For an example of defining a server-side rule that assigns a role in an advanced use case, see the [Amazon API Gateway tutorial](/integrations/aws-api-gateway). +::: + +The **AWS roles** specified will be associated with an **IAM policy** that enforces the type of access allowed to a resource, including the AWS Consoles. To learn more about roles and policies, see [Creating IAM Roles](http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-creatingrole.html). + +To map an AWS role to a user, you'll need to create a [rule](/rules): + +```js +function (user, context, callback) { + + user.awsRole = 'arn:aws:iam::951887872838:role/TestSAML,arn:aws:iam::951887872838:saml-provider/MyAuth0'; + user.awsRoleSession = user.name; + + context.samlConfiguration.mappings = { + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession' + }; + + callback(null, user, context); + +} +``` + +In the code snippet above, `user.awsRole` identifies the AWS role and the IdP. The AWS role identifier comes before the comma, and the IdP identifier comes after the comma. + +Your rule can obtain these two values in multiple ways. You can get these values from the IAM Console by selecting the items you created in AWS in the previous steps from the left sidebar. Both the Identity Provider and the Role you created have an ARN available to copy if you select them in the Console. + +In the example above, both of these values are hard-coded into the rule. Alternatively, you might also store these values in the [user profile](/users/concepts/overview-user-profile) or derive them using other attributes. For example, if you're using Active Directory, you can map properties associated with users, such as group to the appropriate AWS role: + +```js +var awsRoles = { + 'DomainUser': 'arn:aws:iam::951887872838:role/TestSAML,arn:aws:iam::95123456838:saml-provider/MyAuth0', + 'DomainAdmins': 'arn:aws:iam::957483571234:role/SysAdmins,arn:aws:iam::95123456838:saml-provider/MyAuth0' +}; +user.awsRole = awsRoles[user.group]; +user.awsRoleSession = user.email; + +context.samlConfiguration.mappings = { + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession', +}; +``` + +### Map Multiple Roles + +You can also assign an array to the role mapping (so you'd have `awsRoles = [ role1, role2 ]` instead of `awsRoles: role1`) + +For example, let's say that you have Active Directory Groups with the following structure: + +```text + var user = { + app_metadata: { + ad_groups: { + "admins": "some info not aws related", + "aws_dev_Admin": "arn:aws:iam::123456789111:role/Admin,arn:aws:iam::123456789111:saml-provider / Auth0", + "aws_prod_ReadOnly": "arn:aws:iam::123456789999:role/ReadOnly,arn:aws:iam::123456789999:saml-provider / Auth0" + } + } + }; +``` + +Your rule might therefore looking something like this: + +```js +function (user, context, callback) { + + var userGroups = user.app_metadata.ad_groups; + + function awsFilter(group) { + return group.startsWith('aws_'); + } + + function mapGroupToRole(awsGroup) { + return userGroups[awsGroup]; + } + + user.awsRole = Object.keys(userGroups).filter(awsFilter).map(mapGroupToRole); + user.awsRoleSession = 'myawsuser'; // unique per user http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + + context.samlConfiguration.mappings = { + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession' + }; + + callback(null, user, context); + +} +``` + +## Configure Session Expiration + +If you want to extend the amount of time allowed to elapse before the AWS session expires (which is, by default, **3600 seconds**), you can do so using a custom [rule](/rules). Your rule sets the [**SessionDuration** attribute](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html) that changes the duration of the session. + +```js +function (user, context, callback) { + if(context.clientID !== 'YOUR_CLIENT_ID_HERE'){ + return callback(null, user, context); + } + + user.awsRole = 'YOUR_ARN_HERE'; + user.awsRoleSession = 'YOUR_ROLE_SESSION_HERE'; + user.time = 1000; // time until expiration in seconds + + context.samlConfiguration.mappings = { + 'https://aws.amazon.com/SAML/Attributes/Role': 'YOUR-AWS-ROLE-NAME', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'YOUR-AWS-ROLE-SESSION-NAME', + 'https://aws.amazon.com/SAML/Attributes/SessionDuration': 'time' }; + + callback(null, user, context); +} +``` + +## Test setup + +You are now set up for Single Sign-on (SSO) to AWS and can test your setup. + +1. Go to [Auth0 Dashboard > Application](${manage_url}/#/applications), and click the name of your application. +2. Click the **Addons** tab, and select the **SAML2 Web App** add-on. +3. Click the **Usage** tab. +4. Navigate to the **Identity Provider Login URL**. You should be redirected to the Auth0 login page. If you successfully sign in, you'll be redirected again--this time to AWS. diff --git a/fr-ca/articles/integrations/aws/tokens.md b/fr-ca/articles/integrations/aws/tokens.md new file mode 100644 index 0000000000..cd984901df --- /dev/null +++ b/fr-ca/articles/integrations/aws/tokens.md @@ -0,0 +1,204 @@ +--- +description: How to call AWS APIs and Resources Using Tokens +toc: true +topics: + - integrations + - aws + - tokens +contentType: tutorial +useCase: + - secure-an-api + - integrate-third-party-apps + - integrate-saas-sso +--- +# Call AWS APIs and Resources Securely with Tokens + +<%= include('../../_includes/_uses-delegation') %> + +Auth0 integrates with the AWS Security Token Service (STS) to obtain an limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). These credentials can then be used to call the AWS API of any Auth0-supported [identity provider](/identityproviders). + +## Sample Configuration + +![](/media/articles/integrations/aws/aws-sts.png) + +1. The web app authenticates its users via Social providers, such as [Facebook](/connections/social/facebook), [LinkedIn](/connections/social/linkedin), or [Twitter](/connections/social/twitter), or corporate credentials, such as [Active Directory](/connections/social/active-directory), [Azure Active Directory](/connections/enterprise/azure-active-directory), or [Salesforce](connections/social/salesforce). +2. The app calls Auth0's **delegation** endpoint to request a token for use with AWS. +3. Auth0 obtains the token from AWS on behalf of the app. +4. The app uses the newly-obtained token to connect with any AWS API. + +### Set Up Delegation + +::: note +For detailed instructions on configuring delegation, see [How to Set Up AWS for Delegated Authentication](/aws-api-setup). +::: + +Log in to Auth0's Management Dashboard, navigate to the [Applications](${manage_url}/#/applications) area, and find the [application](/applications) associated with your app. Click on **Settings** and click over to the **Addons** tab. Enable the **Amazon Web Services** addon. + +![](/media/articles/integrations/aws/aws-addon.png) + +::: panel Username Length with AWS +Users of Auth0's database or a custom database should note that [AWS usernames must be between 2-64 characters in length](http://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html#troubleshoot_saml_invalid-rolesessionname). If you're using an Auth0 database, you can enforce this by setting your [username length settings](/connections/database/require-username#length) accordingly. If you're using a custom database, you can implement a similar policy within your application. +::: + +#### IAM policy + +The following is a sample AWS IAM policy: + +```text +{ + "Version": "2012-10-17", + "Statement": [ + { + "Action": [ + "s3:DelObject", + "s3:GetObject", + "s3:PutObject", + "s3:PutObjectAcl" + ], + "Resource": [ + "arn:aws:s3:::YOUR_BUCKET_NAME/<%= "${saml:sub}" %>/*" + ], + "Effect": "Allow" + } + ] +} +``` + +The IAM policy is a dynamic policy that gives access to a folder in a bucket. The folder name is set based on an attribute of the digitally-signed SAML token that Auth0 exchanges with AWS on your behalf. + +The `<%= "${saml:sub}" %>` will be automatically mapped from the authenticated user (`sub` means `subject` and is equal to the user identifier), which allows the *original* identity of the user to be used throughout your app and AWS. + +### Get the AWS Token for an Authenticated User + +When a user successfully authenticates, Auth0 returns an ID Token, which is a [JWT](/tokens/concepts/jwts)). This ID Token is then used to request an Auth0 and AWS token using the delegation endpoint. + +Here is a sample request on the delegation endpoint: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/delegation", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"${account.clientId}\", \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\", \"id_token\": \"YOUR_ID_TOKEN\", \"target\": \"${account.clientId}\", \"api_type\": \"aws\" }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +| Parameters | Description | +| - | - | +| `client_id` | The ID of your Auth0 application | +| `grant_type` | Set as `urn:ietf:params:oauth:grant-type:jwt-bearer` | +| `id_token` | The existing ID Token for the user requesting access | +| `target` | The target application's ID | +| `api_type` | The API the user wants to call (this must be `aws`) | + +AWS also requires the **role** and **principal** ARN values. You can set these values using [rules](/rules). The following is a sample rule that you can use. [Copy the provider (for use as the principle ARN) and role ARN values](/aws-api-setup#copy-the-arn-values), and paste them into the sample where it currently says `[omitted]`: + +```js +function (user, context, callback) { + if (context.clientID === 'CLIENT_ID' && + context.protocol === 'delegation') { + // set AWS settings + context.addonConfiguration = context.addonConfiguration || {}; + context.addonConfiguration.aws = context.addonConfiguration.aws || {}; + context.addonConfiguration.aws.principal = 'arn:aws:iam::[omitted]:saml-provider/auth0-provider'; + context.addonConfiguration.aws.role = 'arn:aws:iam::[omitted]:role/auth0-role'; + } + + callback(null, user, context); +} +``` + +Optionally, you can set `context.addonConfiguration.aws.region` to target a specific AWS region. For example, `region: 'cn-north-1'` will direct requests to the Chinese north region. Temporary credentials from AWS GovCloud (US) and China (Beijing) can be used only in the region from which they originated. + +The `context.addonConfiguration.aws.mappings` variable allows you to specify parameters that are sent to AWS to assume a Role. By default, Auth0 will use these mappings: + +```text + mappings: { + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'name', + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsrole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'rolesessionname' + } +``` + +[Other mappings are available in AWS](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html), so if you wanted to use the `eduPersonAffiliation` AWS Context Key, you can set this mapping in a rule as follows: + +```js +function(user, context, callback){ + + context.addonConfiguration.aws.mappings: { + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'name', + 'https://aws.amazon.com/SAML/Attributes/Role': 'awsrole', + 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'rolesessionname', + 'urn:oid:1.3.6.1.4.1.5923.1.1.1.1': 'awsGroup' + }; + + callback(null,user,context); +} +``` + +The example above assumes the `user` object contains an `awsGroup` property with the expected value. + +The result of calling the delegation endpoint will contain the AWS token in the `Credentials` field: + +```js +{ + "ResponseMetadata":{ + "RequestId":"ec4cb90f-8a17-11e5-84bf-a9c4083f50c5" + }, + "Credentials":{ + "AccessKeyId":"ASIAIJGOICAGFNVWAENA", + "SecretAccessKey":"mRXhJySQHYZVg8...iCh+JeyBQ==", + "Expiration":"2015-11-13T16:05:05.000Z" + }, + "AssumedRoleUser":{ + "AssumedRoleId":"AROAID6UVEPILQXDCMMWK:johndoe", + "Arn":"arn:aws:sts::010616021751:assumed-role/access-to-s3-per-user/johndoe" + }, + "Subject":"google-oauth2|113015401123457192604", + "SubjectType":"persistent", + "Issuer":"urn:matugit.auth0.com", + "Audience":"https://signin.aws.amazon.com/saml", + "NameQualifier":"z32keR+u/IrT0MrUVEfqYUGiqvE=" +} +``` + +:::panel Auth0 Libraries +The [Auth0 application libraries](/libraries) simplify the process of calling these endpoints. See an example for client-side JavaScript at [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request). Please note that this example is for **version 7** of the `auth0js` library; delegation is *not* supported in version 8 of `auth0js`. + +Additionally, AWS requires two additional parameters: **role** and **principal**. To modify the `role` and `principal` strings, specify the appropriate ARN values where the sample currently says `[omitted]` via [Rules](${manage_url}/#/rules). If you do not have these values, please see [Copy the ARN Values](/aws-api-setup#copy-the-arn-values) section of the AWS setup doc. +::: + +Here is an example of client-side code used to obtain the token: + +```html + + +``` diff --git a/fr-ca/articles/integrations/azure-api-management/_stepnav.html b/fr-ca/articles/integrations/azure-api-management/_stepnav.html new file mode 100644 index 0000000000..f679e60997 --- /dev/null +++ b/fr-ca/articles/integrations/azure-api-management/_stepnav.html @@ -0,0 +1,14 @@ +
+ <% if (typeof prev !== 'undefined') { %> +
+
Previous
+ ${prev[0]} +
+ <% } %> + <% if (typeof next !== 'undefined') { %> +
+
Next
+ ${next[0]} +
+ <% } %> +
diff --git a/fr-ca/articles/integrations/azure-api-management/configure-auth0.md b/fr-ca/articles/integrations/azure-api-management/configure-auth0.md new file mode 100644 index 0000000000..d8eb7151d5 --- /dev/null +++ b/fr-ca/articles/integrations/azure-api-management/configure-auth0.md @@ -0,0 +1,89 @@ +--- +description: Configure Auth0 for use as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service +toc: true +topics: + - integrations + - azure + - api-management +contentType: tutorial +useCase: + - secure-an-api +--- +# Configure Auth0 + +To use Auth0 as an [OAuth 2.0 authorization server](/protocols/oauth2#oauth-roles), you'll need to execute the following setup steps: + +1. Create an Auth0 API and Machine to Machine Application. +2. Create a Connection to store your users. +3. Create a user so that you can test your integration when you've finished setting it up. + +## Step 1: Create an API and Machine to Machine Application + +An API is an entity that represents an external resource that's capable of accepting and responding to requests made by applications. You'll need to create an [Auth0 API](/apis) using the Management Dashboard to represent the API managed by Azure's API Management Service that you want secured by Auth0. + +You'll also need a [Machine to Machine Application](/applications), which represents your application and allows use of Auth0 for authentication. When you create an API, Auth0 automatically creates an associated Machine to Machine Application by default. + +To begin, you'll need to log into the Auth0 Management Dashboard. Go the [APIs](${manage_url}/#/apis) and click **Create API**. + +![](/media/articles/integrations/azure-api-mgmt/auth0/apis.png) + +Set the following parameters to create your new API: + +| Parameter | Description | +| --------- | ----------- | +| Name | A descriptive name for your API. In this example, we'll use `Basic Calculator` | +| Identifier | A logical and unique identifier for your API. We recommend using a URL, but it doesn't have to be a publicly-available URL since Auth0 doesn't call your API. You cannot modify this value at a later point. We'll use `basic-calculator`. | +| Signing Algorithm | The method used to sign the tokens issued by Auth0. Choose from `HS256` and `RS256` (we'll use the latter for this example). If you choose `RS256`, Auth0 signs your tokens with your private key. To learn more, see [Signing Algorithms](/tokens/concepts/signing-algorithms). | + +When complete, click **Create**. + +![](/media/articles/integrations/azure-api-mgmt/auth0/api-config.png) + +When your API is ready, you'll be shown the **Quick Start** page for the API. Switch over to the **Machine to Machine Applications** tab. You'll see that Auth0 has also created and enabled a [Machine to Machine Application](/applications) for use with your API. + +![](/media/articles/integrations/azure-api-mgmt/auth0/api-nic.png) + +## Step 2: Create a Connection + + +::: note +If you already have a set of users, you may [import them](/extensions/user-import-export) or create a [custom database connection](https://auth0.com/docs/connections/database/mysql). +::: + +Go to the Management Dashboard. Navigate to [**Connections** > **Database Connections**](${manage_url}/#/connections/database), and click **Create DB Connection**. + +![](/media/articles/integrations/azure-api-mgmt/auth0/db-connections.png) + +The only thing you'll need to provide at this time is a descriptive **Name** for your connection. We suggest choosing a name that reflects the source of users (such as `Facebook` for a Connection that contains users using their Facebook credentials or `site-sign-ups` for a database connection where users sign up on your site). + +![](/media/articles/integrations/azure-api-mgmt/auth0/new-db-connection-config.png) + +Click **Create** to proceed. + +### Enable the Connection for Your Application + +Once Auth0 has created your Connection, you'll be redirected to your Connection's **Settings** page. Switch over to the **Applications** tab, where you'll see a full list of all the Applications you have with this account. You'll need to enable the Connection for use with the Machine to Machine Application that you're using with your API. + +![](/media/articles/integrations/azure-api-mgmt/auth0/connection-application.png) + +## Step 3: Create a User + +Finally, we'll create a user that we use later on to test the integration. + +Go to the [Users section](${manage_url}/#/users) of the Management Dashboard. Click **Create User**. + +![](/media/articles/integrations/azure-api-mgmt/auth0/user.png) + +Provide an **email** and **password** for your new user. Be sure to indicate that this user should use **BasicCalculator** in the **Connection** field. + +Set `Connection` to the connection you created earlier (which, if you're following along with our example, is `BasicCalculator`). + +![](/media/articles/integrations/azure-api-mgmt/auth0/create-user.png) + +Click **Save** to proceed. + +At this point, you've set up Auth0 for use as an OAuth 2.0 authorization server. You will now configure the Azure API Management Service and import an API for use with the service. + +<%= include('./_stepnav', { + prev: ["Integrate Azure API Management Service with Auth0", "/integrations/azure-api-management"], next: ["2. Configure Azure API Management", "/integrations/azure-api-management/configure-azure"] +}) %> diff --git a/fr-ca/articles/integrations/azure-api-management/configure-azure.md b/fr-ca/articles/integrations/azure-api-management/configure-azure.md new file mode 100644 index 0000000000..fd8219189b --- /dev/null +++ b/fr-ca/articles/integrations/azure-api-management/configure-azure.md @@ -0,0 +1,143 @@ +--- +description: Configure Azure to accept Auth0 for use as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service +toc: true +topics: + - integrations + - azure + - api-management +contentType: tutorial +useCase: + - secure-an-api +--- +# Configure Azure + +::: warning +To complete this tutorial you will need to have an account that grants you access to Microsoft's [Azure Portal](https://portal.azure.com). +::: + +In this section, you'll: + +* Create an API management instance +* Import the Basic Calculator API +* Configure an OAuth 2.0 Server +* Set Auth0 as the OAuth 2.0 Server handling authentication requests to the API +* Test the Auth0-Azure API integration + +## Step 1: Create Your API Management Instance + +To create a new API management service, click **Create a resource** in the left-hand navigation bar. Once redirected, click **Web** > **API Management**. + +You'll be asked to provide the following configuration variables: + +| Parameter | Description | +| --------- | ----------- | +| Name | The name for your service (which will also be used to create the URL you need to access the service) | +| Subscription | The Azure subscription plan with which you'll use with the service | +| Resource group | The collection of [resources](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-portal) sharing a lifecycle, permissions, and policies. You can use an existing resource group or you can create a new one (you'll need to provide a name for the group if you create a new one) | +| Location | Choose the location that services your API instance | +| Organization name | The name of your organization | +| Administrator email | The email address of the person who will be administering this instance | +| Pricing tier | The pricing tier you want, which determines the number of calls you can make to your API, as well as the maximum amount of data transfer allowed. You must opt for the [Developer plan](https://azure.microsoft.com/en-us/pricing/details/api-management/) or higher; the Consumption plan does not offer sufficient functionality for this integration to work. | + +You can also choose to **Enable Application Insights**. If you do, select the **Application Insights instance** you would like to use. + +Click **Create** to begin provisioning your service. + +## Step 2: Import Your API + +For this tutorial, we will be importing and using the Calculator API provided by Microsoft. You can, however, create your own API instead of using the Calculator API. + +For detailed instructions on how to do so, see [Import and Publish Your First API](https://docs.microsoft.com/en-us/azure/api-management/import-and-publish#go-to-your-api-management-instance) + +When done, click **Create** to import your API. You'll be redirected to the summary page for your API when it's fully imported. + +## Step 3: Configure Your OAuth 2.0 Authorization Server + +To use Auth0 to secure your API, you'll need to register Auth0 as an OAuth 2.0 Authorization Server. You can do so using the Azure Publisher Portal. + +Find the **Security** area of your API Management service instance's near left navigation bar, and click **OAuth 2.0**. + +Click on **Add**. You'll see the **Add OAuth2 service** configuration screen that lets you provide details about your Auth0 tenant. + +For the purposes of this example, we'll use the **Authorization Code grant type**, but you're free to use whichever grant type is most appropriate for your use case. Azure currently supports the following grant types: [Authorization Code](/flows/concepts/auth-code), [Implicit](/flows/concepts/implicit), [Resource Owner Password](/api-auth/grant/password), [Client Credentials](/flows/concepts/client-credentials). + +Set the following parameters: + +| Parameter | Description | +| --------- | ----------- | +| Display name | A descriptive name for your authorization server, such as `Auth0` | +| Id | The identifying name for this Azure resource -- this field should auto-populate based on the display name you provide | +| Description | A description for your authorization server, such as `Auth0 API Authentication` | +| Client registration page URL | The page where users can create or manage their accounts; for the purposes of this example, we'll use `https://placeholder.contoso.com` as the placeholder | +| Authorization code grant types | The grant type used for authorization. Select `authorization code` | +| Authorization endpoint URL | The URL Azure uses to make the authorization request. See the [Auth0 docs on generating the URL](/flows/guides/auth-code/call-api-auth-code#authorize-the-user) | +| Authorization request method | The HTTP method used by Azure to make the authorization request. By default, this is `GET` | +| Token endpoint URL | The endpoint used to exchange authorization grants for Access Tokens; Auth0's can be reached at `https://auth0user.auth0.com/oauth/token` | +| Client authentication methods | Method used to authenticate the application; Auth0's is `BASIC` | +| Access Token sending method | The location of the Access Token in the sending method (typically the **Authorization header**) | +| Default scope | Specify a default scope (if necessary) | + +Because we're using the **authorization code** grant, we'll need to provide the **client ID** and **client secret** for the [Auth0 Application we previously registered](/integrations/azure-api-management/configure-auth0#step-1-create-an-api-and-machine-to-machine-application). You can find both values in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). + +Once you've provided both the client ID and client secret, you'll see an auto-generated **redirect URI**. Copy this URL, since you'll need to provide this URI in your Auth0 Application Settings page in the Allowed Callback URLs section. + +::: note +If you're using the [resource owner password](/api-auth/grant/password) flow, you'll need to provide the **resource owner username** and **resource owner password** instead of the client ID and secret. +::: + +When complete, click **Create** to persist your changes. + +### Set the Allowed Callback URL + +You'll need to provide the **redirect URI** that was auto-generated during the OAuth 2.0 authorization server setup process to Auth0. Log into the Management Dashboard, and navigate to **Applications**. Select your Application, and click **Settings**. Paste the URL into the **Allowed Callback URLs** field. + +![](/media/articles/integrations/azure-api-mgmt/azure/set-callback-url.png) + +Click **Save**. + +## Step 4: Authorize Auth0 for Use with Your API + +Before you can use Auth0 to secure your API, you'll need to set your API to use Auth0. + +In the near-left navigation column, click **APIs**. Select the Basic Calculator API; this redirects you to the **Design** tab. + +Click over to the **Settings** tab. + +Scroll to the **Security** section, and under **User Authorization**, select **OAuth 2.0**. In the **Authorization Server** field that appears, select the server you configured in the previous step. + +Click **Save**. + +## Step 5: Test Your Integration + +While logged in to the Azure Portal, open up your instance of the API Management Service. Click **Developer Console** to launch the developer-facing side of your APIs. + +Go to APIs > Basic Calculator (or the API you've created for this tutorial). This opens up to the page where you can make a `GET` call that allows you to add two integers. + +Click **Try It**. This will bring up the page where you can provide the parameters for your call. + +Scroll down to the **Authorization** section. Next to the **Auth0** field, select **Authorization Code**. + +At this point, you'll see the Auth0 login widget in a popup window (if you don't, disable your popup blocker). Provide the credentials for the Auth0 user you created earlier in the tutorial, and sign in. + +If you were able to successfully sign in, you'll see a message appear with the expiration date of the Access Token you need to call the API. + +Scroll to the bottom, and click **Send** to send your request. If successful, you'll see a message containing the `HTTP 200` response at the bottom of the page. + +## Configure a JWT validation policy for Access Tokens + +In the previous step, the user is prompted to sign in when they try to make a call from the Developer Console. The Developer Console attempts to obtain an Access Token on behalf of the user to be included in the API request. All Access Tokens will be passed to the API via the `Authorization` header. + +If you want to validate the Access Token included with each request, you can do so by using the [Validate JWT](https://docs.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT) policy. Please refer to Microsoft's documentation on [setting an API Management policy](https://docs.microsoft.com/en-us/azure/api-management/set-edit-policies). + +## Summary + +In this tutorial, you: + +1. Configured your Auth0 tenant to act as an OAuth 2.0 server. +2. Set up an API Management Service in Azure. +3. Imported an API that's managed by Azure's API Management Service. +4. Secured your API using Auth0 and (optionally) verified the Access Token. + +<%= include('./_stepnav', { + prev: ["1. Configure Auth0", "/integrations/azure-api-management/configure-auth0"] +}) %> \ No newline at end of file diff --git a/fr-ca/articles/integrations/azure-api-management/index.md b/fr-ca/articles/integrations/azure-api-management/index.md new file mode 100644 index 0000000000..f3419f00af --- /dev/null +++ b/fr-ca/articles/integrations/azure-api-management/index.md @@ -0,0 +1,30 @@ +--- +description: Using Auth0 as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service +topics: + - integrations + - azure + - api-management +contentType: tutorial +useCase: + - secure-an-api +--- + +# Integrate Azure API Management Service with Auth0 + +If you have an API that you want published and secured, you can do so using Azure API Management in conjunction with Auth0. + +Azure's API Management Service allows you to create new APIs or import existing API definitions and publish them for use by the approved audiences. Auth0 makes authorizing users of your API (using OAuth 2.0 standards) easy. + +In this tutorial, we will show you how to [create a representation of your API in Auth0](/integrations/azure-api-management/configure-auth0), set up the [Azure API Management service, import an existing API, and secure it using Auth0](/integrations/azure-api-management/configure-azure). More specifically, we will: + +1. Set up Auth0 by creating an API and Machine to Machine Application, Connection, and User +2. Create an API Management Service on the Azure Portal +3. Import a Basic Calculator API (this sample API is provided by Microsoft) +4. Set up Auth0 for use as an OAuth 2.0 Server in Azure +5. Secure access to your Basic Calculator API using Auth0 + +We will also test the integration. You'll see that, whenever a user attempts to make a call to the Basic Calculator API, they are asked to provide credentials to an Auth0-provided login screen. Only by providing valid credentials is the user allowed to make a call to the API. + +<%= include('./_stepnav', { + next: ["1. Configure Auth0", "/integrations/azure-api-management/configure-auth0"] +}) %> \ No newline at end of file diff --git a/fr-ca/articles/integrations/azure-tutorial.md b/fr-ca/articles/integrations/azure-tutorial.md new file mode 100644 index 0000000000..e3f8078c28 --- /dev/null +++ b/fr-ca/articles/integrations/azure-tutorial.md @@ -0,0 +1,71 @@ +--- +description: How to use Auth0 with Microsoft Azure. +url: /azure-tutorial +topics: + - integrations + - microsoft + - azure +contentType: +- how-to +- index +useCase: integrate-saas-sso +--- +# Using Auth0 with Microsoft Azure + +Auth0 is as simple to integrate in an application deployed on [Microsoft Azure](https://azure.microsoft.com) as it is for any other environment. To get started, please see: + +* [ASP.NET application](/quickstart/backend/aspnet-core-webapi-v1_1)
+Simple non-intrusive integration with any version of ASP.NET. + +* [Node.js application](/quickstart/backend/nodejs)
+Integration using [passport](http://passportjs.org/). + +--- + +### Tip: change Auth0 configuration when deploying to Microsoft Azure + +You'll need to make some configuration changes when deploying to Microsoft Azure. Auth0 recommends creating one application per environment (e.g. Development, Test, Production). This is because each environment should have and use a different `Client Id` and `Client Secret`, as well as the appropriate `Callback URL`. + +For ASP.NET applications, we recommend utilizing [Web.config transformations](http://msdn.microsoft.com/en-us/library/dd465326.aspx) to make configuration changes targeted for each environment. Application settings that appear in the transformed `web.config` will depend on the build target name used at compilation and deployment. + +The following is an example of how you can compile and deploy your application. The example focuses on deploying to Production, but you can use it to create builds in your ASP.NET application targeting your other environments. + + +This is the base configuration in `Web.config`: + +```xml + + + +``` + +The following snippet, `Web.Release.config`, contains the necessary transformations. We want to utilize the `Release` build and are targeting Production. + +```xml + + + + + + + +``` + +If you need to refer to the `Client Id`, `Client Secret` or `Callback URL`, you can do so using the [`ConfigurationManager`](https://docs.microsoft.com/en-us/dotnet/api/system.configuration.configurationmanager?view=netframework-4.7.2) class. Below is an example of using the `ConfigurationManager` within an ASP.NET MVC Razor view. + +```html + + +``` + +Running `web.config` transformations are helpful whether deploying to a [Microsoft Azure App Service](https://azure.microsoft.com/en-us/services/app-service/) or a [Microsoft Azure Cloud Service](https://azure.microsoft.com/en-us/services/cloud-services/). + +::: note +Use the [Web.config Transformation Tester](http://webconfigtransformationtester.apphb.com/) to verify the results of any `web.config` transformations. +::: diff --git a/fr-ca/articles/integrations/configure-wsfed-application.md b/fr-ca/articles/integrations/configure-wsfed-application.md new file mode 100644 index 0000000000..d6629e86c7 --- /dev/null +++ b/fr-ca/articles/integrations/configure-wsfed-application.md @@ -0,0 +1,25 @@ +--- +description: How to configure a WS-Fed application to use Auth0 as an identity provider. +topics: + - integrations + - ws-fed +contentType: how-to +useCase: integrate-saas-sso +--- + +# How to configure a WS-Fed application + +If a WS-Fed application (Service Provider) is to use Auth0 as an Identity Provider, this is configured in one of two places. + +Some commonly used WS-Fed applications are pre-configured in Auth0 and available via `Single Sign-On Integrations`. + +If a WS-Fed application is not listed in `Single Sign-On Integrations`, the generic WS-Fed application configuration can be accessed via: + +1. In the Auth0 Dashboard, click on `Applications`, `+ CREATE APP`, enter a name and press Save. +2. Then click on the `Addons` tab -> `WS-Fed Web App`. +3. Enter the `Application Callback URL` - this is the your callback URL in the WS-Fed application to which the WS-Fed response will be posted. It may also called the `ACS` or `Assertion Consumer Service URL` in some applications. +4. Enter the `Realm` - this is an identifier sent by the WS-Fed application and is used to identify the application in the response. + +::: note +If you want to use your WS-Fed applications with the [custom domains](/custom-domains) feature and with Auth0 as the IDP, you must update your Service Provider with new Identity Provider metadata from Auth0. You can obtain the metadata reflecting the custom domain from: `https:///wsfed/FederationMetadata/2007-06/FederationMetadata.xml`. +::: \ No newline at end of file diff --git a/fr-ca/articles/integrations/google-cloud-platform.md b/fr-ca/articles/integrations/google-cloud-platform.md new file mode 100644 index 0000000000..5b8581ee99 --- /dev/null +++ b/fr-ca/articles/integrations/google-cloud-platform.md @@ -0,0 +1,217 @@ +--- +title: Securing Google Cloud Endpoints with Auth0 +description: How to secure a Google Cloud Endpoints API with Auth0. +toc: true +topics: + - integrations + - google-cloud +contentType: how-to +useCase: integrate-saas-sso +--- + +# Securing Google Cloud Endpoints with Auth0 + +[Google Cloud Endpoints (GCE)](https://cloud.google.com/endpoints/) is an API management system providing features to help you create, maintain, and secure your APIs. GCE uses [OpenAPI](https://www.openapis.org/) to define your API's endpoints, input and output, errors, and security description. + +::: note +For more information on the OpenAPI spec, see the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification) repository on GitHub. +::: + +This tutorial will cover how to secure Google Cloud Endpoints with Auth0. + +## Prerequisites + +Before you begin you'll need a deployed GCE API. If you haven't already created an API, complete the [Cloud Endpoints Quickstart](https://cloud.google.com/endpoints/docs/quickstart-endpoints). + +The quickstart will walk you through creating a simple GCE API with a single endpoint, `/airportName`, that returns the name of an airport from its three-letter [IATA code](https://en.wikipedia.org/wiki/IATA_airport_code). + +```har +{ + "method": "GET", + "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName", + "headers": [], + "queryString" : [ + { + "name": "iataCode", + "value": "SFO" + } + ] +} +``` + +## Define the API in Auth0 + +Open [Dashboard > APIs](${manage_url}/#/apis) and create a new API. + +![Create API](/media/articles/tutorials/gce-create-api.png) + +Make note of the **API Audience** identifier (`http://google_api` in the screenshot above) to use in the following step. + +## Update the API Configuration + +Next, we'll update the OpenAPI configuration file for the GCE API. For the sample API created during the quickstart this file is `openapi.yaml`. + +### Add Security Definitions + +Open the configuration file and add a new `securityDefinitions` section. In this section, add a new definition (`auth0_jwt`) with the following fields: + +Field | Description +------|------------ +`authorizationUrl` | The authorization URL, should be set to `"https://${account.namespace}/authorize"` +`flow` | The flow used by the OAuth2 security scheme. Valid values are `"implicit"`, `"password"`, `"application"` or `"accessCode"`. +`type` | The type of the security scheme. Valid values are `"basic"`, `"apiKey"` or `"oauth2"` +`x-google-issuer` | The issuer of a credential, should be set to `"https://${account.namespace}/"` +`x-google-jwks_uri` | The URI of the public key set to validate the JSON Web Token (JWT) signature. Set this to `"https://${account.namespace}/.well-known/jwks.json"` +`x-google-audiences` | The API's identifier, make sure this value matches what you defined on the Auth0 dashboard for the API. + + +```yaml +securityDefinitions: + auth0_jwt: + authorizationUrl: "https://${account.namespace}/authorize" + flow: "implicit" + type: "oauth2" + x-google-issuer: "https://${account.namespace}/" + x-google-jwks_uri: "https://${account.namespace}/.well-known/jwks.json" + x-google-audiences: "{YOUR_API_IDENTIFIER}" +``` + +### Update the Endpoint + +Now, update the endpoint by adding a `security` field with the `securityDefinition` we created in the previous step. + +```yaml +paths: + "/airportName": + get: + description: "Get the airport name for a given IATA code." + operationId: "airportName" + parameters: + - + name: iataCode + in: query + required: true + type: string + responses: + 200: + description: "Success." + schema: + type: string + 400: + description: "The IATA code is invalid or missing." + security: + - auth0_jwt: [] +``` + +In the above example, the `security` field tells the GCE proxy that our `/airportName` path expects to be secured with the `auth0-jwt` definition. + +After updating the OpenAPI configuration, it should look something like this: + +```yaml +--- +swagger: "2.0" +info: + title: "Airport Codes" + description: "Get the name of an airport from its three-letter IATA code." + version: "1.0.0" +host: "YOUR_GCE_PROJECT.appspot.com" +schemes: + - "https" +paths: + "/airportName": + get: + description: "Get the airport name for a given IATA code." + operationId: "airportName" + parameters: + - + name: iataCode + in: query + required: true + type: string + responses: + 200: + description: "Success." + schema: + type: string + 400: + description: "The IATA code is invalid or missing." + security: + - auth0_jwt: [] +securityDefinitions: + auth0_jwt: + authorizationUrl: "https://${account.namespace}/authorize" + flow: "implicit" + type: "oauth2" + x-google-issuer: "https://${account.namespace}/" + x-google-jwks_uri: "https://${account.namespace}/.well-known/jwks.json" + x-google-audiences: "{YOUR_API_IDENTIFIER}" +``` + +### Redeploy the API + +Next, redeploy your GCE API to apply the configuration changes. If you followed along with the [Cloud Endpoints Quickstart](https://cloud.google.com/endpoints/docs/quickstart-endpoints) you can redeploy by entering the following in Google's Cloud Shell: + +```bash +cd endpoints-quickstart/scripts +./deploy_api.sh +``` + +## Test the API + +Once you've redeployed, call the API again with no security. + +```har +{ + "method": "GET", + "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName", + "headers": [], + "queryString" : [ + { + "name": "iataCode", + "value": "SFO" + } + ] +} +``` + +You'll get the following response: + +```json +{ + "code": 16, + "message": "JWT validation failed: Missing or invalid credentials", + "details": [ + { + "@type": "type.googleapis.com/google.rpc.DebugInfo", + "stackEntries": [], + "detail": "auth" + } + ] +} +``` + +Which is exactly what we want! + +Now go to the **Test** page of your Google Endpoints API definition on the [Auth0 Dashboard](${manage_url}/#/apis), and copy the Access Token: + +![Copy Token](/media/articles/tutorials/gce-copy-token.png) + +Perform a `GET` request to your API with an Authorization Header of `Bearer {ACCESS_TOKEN}` to obtain authorized access: + +```har +{ + "method": "GET", + "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName", + "headers": [ + { "name": "Authorization", "value": "Bearer {ACCESS_TOKEN}" } + ], + "queryString" : [ + { + "name": "iataCode", + "value": "SFO" + } + ] +} +``` + +And that's it! diff --git a/fr-ca/articles/integrations/index.md b/fr-ca/articles/integrations/index.md new file mode 100644 index 0000000000..c73d303ef5 --- /dev/null +++ b/fr-ca/articles/integrations/index.md @@ -0,0 +1,217 @@ +--- +classes: topic-page +title: Auth0 Integrations +description: Learn how to integrate Auth0 with other applications and services. +topics: + - integrations +contentType: index +useCase: + - integrate-third-party-apps + - integrate-analytics + - integrate-marketing + - integrate-saas-sso +--- + +
+
+

Auth0 Integrations

+

Tailor your identity flows with custom code and integrate with third-party systems. +

+
+ + diff --git a/fr-ca/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md b/fr-ca/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md new file mode 100644 index 0000000000..77803499d1 --- /dev/null +++ b/fr-ca/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md @@ -0,0 +1,114 @@ +--- +description: How to integrate Auth0 with Amazon Cognito using an OpenID Connect (OIDC) Provider. +topics: + - integrations + - amazon + - cognito + - oidc +contentType: how-to +useCase: integrate-saas-sso +--- +# Integrate Auth0 with Amazon Cognito + +**Amazon Cognito** is a backend as a service that lets you focus on writing a fantastic user experience for your application (native or web). + +This document will explain how you can integrate your app with two solutions: Auth0 to get authentication with either [Social Providers](/connections/identity-providers-social) (Facebook, Twitter, and so on), [Enterprise providers](/connections/identity-providers-enterprise) or regular Username and Password, and [Amazon Cognito](http://aws.amazon.com/cognito/), to get a backend for your app without writing a line of code. + +## Configure Amazon Web Services + +### Create a new OpenID Connect Provider + +The first step is to create an OpenID Connect (OIDC) Provider pointing to your Auth0 account. Please take a note of your Auth0 **domain** (`${account.namespace}`) and your **applicationId** these values can be found in the [Settings of your chosen Application](${manage_url}/#/clients/). These values will be used to create the Identity Pool in the [IAM Console](https://console.aws.amazon.com/iam/home). + +1. In the [IAM Console](https://console.aws.amazon.com/iam/home) click on the **Identity Providers** link in the left sidebar. Click the **Create Provider** button. + + ![Create Provider](/media/articles/scenarios/amazon-cognito/create-provider.png) + +1. Next you will choose the provider type, select **OpenID Connect** from the dropdown. For the **Provider URL** enter: `https://YOUR_ACCOUNT_NAME.auth0.com` and for **Audience** enter your **ClientId** ([find your ClientID](${manage_url}#/applications/)). + + ![Configure Provider](/media/articles/scenarios/amazon-cognito/configure-provider.png) + +1. This will bring you to the **Verify Provider Information** screen, click the **Create** button. + + ![Verify Provider](/media/articles/scenarios/amazon-cognito/verify-provider.png) + +1. Then you will be able to click on your newly created provider to find the **Provider ARN** which will be used in a later step. + +1. Use the Thumbprint to verify the server certificate of your IdP. To learn how, see [Obtaining the Thumbprint for an OpenID Connect Identity Provider](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html). + +::: note +It's not necessary to set up an IAM role after creating the identity provider. If you don't have one already, Cognito will create a default IAM role in the next step. +::: + +To obtain the Auth0 Dashboard's Thumbprint value: + +1. [Retrieve your Auth0 Domain's certificate chain.](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html?icmpid=docs_iam_console) +2. Once you've obtained the certificate chain, isolate the last certificate in the chain. +3. Using the last certificate in the chain, [compute the fingerprint](https://www.samltool.com/fingerprint.php). +4. Convert the fingerprint to a thumbprint by removing all of the `:` characters. +5. Use the computed thumbprint when calling the `aws iam create-open-id-connect-provider` command. + +### Create a Cognito Identity Pool + +Now, you need to create an Identity Pool in the [Cognito Console](https://console.aws.amazon.com/cognito/home). This will be used to log in to Amazon Cognito using the Auth0 Identity Provider that you created in the previous step. + +1. Sign in to the [Cognito Console.](https://console.aws.amazon.com/cognito/home) + +1. Click **Manage Federated Identities** to start creating a new identity pool. + +1. For **Identity Pool Name**, specify a name for the pool e.g. `Auth0`. Under **Authentication Providers**, click the **OpenID** tab and select the name of the provider you created in the previous steps. Click **Create Pool**. + + ![Create Identity Pool](/media/articles/scenarios/amazon-cognito/identity-pool.png) + +1. This will bring up a confirmation page for allowing access to your resources. By default, Amazon Cognito creates a new role with limited permissions - end users only have access to Cognito Sync and Mobile Analytics. You can modify the roles if your application needs access to other AWS resources, such as S3 or DynamoDB. Click **Allow** to finish creating the new identity pool. + + ![Confirmation page](/media/articles/scenarios/amazon-cognito/allow-role.png) + +1. Click **Edit Identity Pool** to view the Identity Pool ID. + + ![View the Identity Pool ID](/media/articles/scenarios/amazon-cognito/pool-id.png) + +1. Finally, grab the ARN of the role that was automatically created in the previous step from the [IAM console](https://console.aws.amazon.com/iam/home) this value will be used when sending credentials to Cognito. + + ![Role ARN](/media/articles/scenarios/amazon-cognito/role-arn.png) + +## Auth0 Configuration + +Amazon will use the public signing key from the [OpenID Provider Metadata](https://subscription.auth0.com/.well-known/jwks.json) to validate the signature of the JSON Web Token (JWT). + +By default Auth0 will use the HS256 signature algorithm which is not supported in this scenario (this will result in "Invalid login token" errors). Go to your application in the [dashboard](${manage_url}/#/applications), click the **Show Advanced Settings** link and then **OAuth** and change the algorithm to **RS256**. + +![Change to RS256](/media/articles/scenarios/amazon-cognito/jwt-algorithm.png) + +## Implementation + +You can use Auth0 Lock to log the user in. You can read detailed instructions on how to implement Lock in [the libraries documentation](/libraries#lock-login-signup-widgets). + +Once the user is successfully logged in with Auth0, the next step is to send their credentials to Amazon Cognito [see the Cognito docs](http://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html) to see how to implement this with depending on the platform. + +Cognito takes the ID Token that you obtain from the OIDC identity provider and uses it to manufacture unique Cognito IDs for each person who uses your app. When the user is logged in to Cognito through Auth0 you can store information in Cognito that only this user will be able to access. + +For example (with Swift): + +```swift +let cognitoSync = AWSCognito.defaultCognito() +let dataset = cognitoSync.openOrCreateDataset("MainDataset") +// Get an existing value +dataset.synchronize().continueWithBlock { (task) -> AnyObject! in + dispatch_async(dispatch_get_main_queue(), { () -> Void in + self.textValue.text = dataset.stringForKey("value") + }) + return nil +} + +// Set a new value +dataset.setString(self.textValue.text, forKey: "value") +dataset.synchronize() +``` + +## Keep reading + +::: next-steps +* [Amazon Cognito: OpenID Connect Providers](http://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html) +* [Amazon IAM: Creating OpenID Connect (OIDC) Identity Providers](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) +::: diff --git a/fr-ca/articles/integrations/marketing/adobe-campaign/index.md b/fr-ca/articles/integrations/marketing/adobe-campaign/index.md new file mode 100644 index 0000000000..9e1dcd8e58 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/adobe-campaign/index.md @@ -0,0 +1,66 @@ +--- +title: Export User Data To Adobe Campaign +description: Learn how to export your Auth0 user data and import it into Adobe Campaign. +toc: true +topics: + - marketing + - adobe + - adobe-campaign +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Adobe Campaign + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Adobe Campaign with the [Adobe Campaign Import Wizard](https://docs.campaign.adobe.com/doc/AC/en/PTF_Importing_and_exporting_data_Importing_data.html). + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Adobe Campaign accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Adobe Campaign Documentation: Importing Data](https://docs.adobe.com/content/help/en/campaign-classic/using/getting-started/importing-and-exporting-data/importing-data.html) +::: + +Log in to your Adobe Campaign client dashboard and navigate to **Profiles and Targets > Jobs**. Create a new import job by clicking the **Create** button and selecting **New Import**. + +A new **Import Wizard** window should open. On the **Template Selection** step you can set your import parameters. + +Parameter | Description +----------|------------ +Import template (leave as default) | The job template, set to `New text import` by default. +Label | A label for the job, for example: `Importing Auth0 users`. +Description | A brief description of the job. +Import type | Set to `Simple import` for single file imports and `Multiple import` for multiple file imports. +Folder | Select the folder to save the import file to. + +Once you've configured your import parameters, click the **Next** button to continue. + +On the **File to Import** step upload the user data CSV file you exported from Auth0 in the previous section. Click the **Next** button to proceed to **Field Mapping**. + +Next, map the export file schema to your Adobe Campaign database schema. Check that the field names and field types are correct, then click the **Next** button. + +Complete the remaining configuration steps by defining your data reconciliation mode and selecting a folder, list, or service for the users being imported. + +Finally, begin the import by clicking the **Start** button on the **Data Import Execution** window. + +That's it! You successfully imported your Auth0 users into Adobe Campaign. diff --git a/fr-ca/articles/integrations/marketing/alterian/index.md b/fr-ca/articles/integrations/marketing/alterian/index.md new file mode 100644 index 0000000000..5f39fbdff9 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/alterian/index.md @@ -0,0 +1,61 @@ +--- +title: Export User Data To Alterian +description: Learn how to export your Auth0 user data and import it into Alterian. +toc: true +topics: + - marketing + - alterian +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Alterian + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Alterian with the campaign manager's data import tool. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Alterian accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Alterian Campaign Manager: Data Import](http://cm.help.alterian.com/CM404/Default.htm#Customer_Analytics/Import_Export/Data_Import.htm) +::: + +To import your CSV file into Alterian, follow these steps: + +1. Open your Alterian Campaign Manager and click **Documents**. + +2. Choose the directory to import the file to. + +3. Click **Upload Files** and select your CSV file. + +4. Click **Upload**. + +5. Once the upload is complete, open the **Data Import** tool. + +6. Configure your import settings using the provided fields on the **New Imports data** window. + + ![Data Import: New Imports](/media/articles/integrations/marketing/alterian/new-data-imports.png) + +7. After you've reviewed your settings, click **Run Processes**. + +That's it! You successfully imported your Auth0 users into Alterian. diff --git a/fr-ca/articles/integrations/marketing/constant-contact/index.md b/fr-ca/articles/integrations/marketing/constant-contact/index.md new file mode 100644 index 0000000000..55048e1ca4 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/constant-contact/index.md @@ -0,0 +1,57 @@ +--- +title: Export User Data To Constant Contact +description: Learn how to export your Auth0 user data and import it into Constant Contact. +toc: true +topics: + - marketing + - constant-contact +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Constant Contact + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Constant Contact dashboard. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Constant Contact accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Constant Contact Knowledge Base: Import or Upload a File of Contact Email Addresses](https://knowledgebase.constantcontact.com/articles/KnowledgeBase/5296-import-or-upload-a-file-of-contact-email-addresses) +::: + +To import your CSV file into Constant Contact, follow these steps: + +1. [Log in to Constant Contact](https://login.constantcontact.com) and navigate to **Contacts**. + +2. From the **Contacts** page, click **Add Contacts > Upload from file**. + +3. Provide you CSV file on the **Upload from file** page then click **Continue**. + +4. Review the columns and match them with your Constant Contact fields. Once you're finished click **Continue**. + +5. On the **Select lists** page, choose the list or lists to add your contacts to. + +6. Click **Upload**. + +That's it! You successfully imported your Auth0 users into Constant Contact. \ No newline at end of file diff --git a/fr-ca/articles/integrations/marketing/eloqua/index.md b/fr-ca/articles/integrations/marketing/eloqua/index.md new file mode 100644 index 0000000000..7b3e3bad71 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/eloqua/index.md @@ -0,0 +1,58 @@ +--- +title: Export User Data To Oracle Eloqua +description: Learn how to export your Auth0 user data and import it into Oracle Eloqua. +toc: true +topics: + - marketing + - eloqua + - oracle +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Oracle Eloqua + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Eloqua with the contact upload wizard. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Eloqua accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Oracle Eloqua Help Center: Uploading Contacts](https://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/index.html#Help/Contacts/Tasks/UploadingContacts.htm) +::: + +To import your CSV file into Eloqua, follow these steps: + +1. Log in to Eloqua and navigate to **Audience > Contacts > Upload** to open the **Contact Upload Wizard**. + +2. Configure the import using the provided fields on the **Pick Data Source** tab. + +3. Click the **Cloud** button and select the file to upload. + +4. After you've verified the file contents on the **Review** tab, click **Next Step**. + +5. Under the **Map Fields** tab, enter the field mapping settings to match your CSV file data to contact fields. Click **Next Step** to continue. + +6. Complete the final step of the wizard and click **Finish**. + +That's it! You successfully imported your Auth0 users into Eloqua. \ No newline at end of file diff --git a/fr-ca/articles/integrations/marketing/index.md b/fr-ca/articles/integrations/marketing/index.md new file mode 100644 index 0000000000..b562fe8e1b --- /dev/null +++ b/fr-ca/articles/integrations/marketing/index.md @@ -0,0 +1,30 @@ +--- +classes: topic-page +title: Export User Data To Marketing Tools +description: Learn how to export Auth0 user data to marketing applications and services. +topics: + - marketing +contentType: index +useCase: export-users-marketing +--- + +
+
+

Export User Data To Marketing Tools

+

+ The better the data, the better the marketing campaign. With Auth0 you can provide user data for your marketing tools to personalize marketing and increase user engagement. Take a look below for tutorials to get started! +

+
+ +<%= include('../../_includes/_topic-links', { links: [ + 'integrations/marketing/adobe-campaign', + 'integrations/marketing/alterian', + 'integrations/marketing/constant-contact', + 'integrations/marketing/eloqua', + 'integrations/marketing/mailchimp', + 'integrations/marketing/marketo', + 'integrations/marketing/sailthru', + 'integrations/marketing/salesforce', + 'integrations/marketing/salesforce-marketing-cloud', + 'integrations/marketing/watson-campaign-automation' +] }) %> \ No newline at end of file diff --git a/fr-ca/articles/integrations/marketing/mailchimp/index.md b/fr-ca/articles/integrations/marketing/mailchimp/index.md new file mode 100644 index 0000000000..6b9c68dafc --- /dev/null +++ b/fr-ca/articles/integrations/marketing/mailchimp/index.md @@ -0,0 +1,65 @@ +--- +title: Export User Data To MailChimp +description: Learn how to export your Auth0 user data and import it into MailChimp. +toc: true +topics: + - marketing + - mailchimp +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To MailChimp + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the [MailChimp dashboard](https://login.mailchimp.com/). + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. MailChimp accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For MailChimp, an email field with the column name `Email Address` is required, so make sure to include it. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +::: note +[MailChimp Knowledge Base: Format Guidelines for Your Import File](https://kb.mailchimp.com/lists/growth/format-guidelines-for-your-import-file) +::: + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[MailChimp Knowledge Base: Import Subscribers to a List](https://kb.mailchimp.com/lists/growth/import-subscribers-to-a-list) +::: + +Log in to your MailChimp account and go to the **Lists** page. Select a list to import your Auth0 users into ([or create a new list](https://kb.mailchimp.com/lists/growth/create-a-new-list)). On your MailChimp List page, click on **Import Contacts** from the **Add Contacts** menu. + +![MailChimp List: Import Contacts](/media/articles/integrations/marketing/mailchimp/import-contacts.png) + +On the next page, select the `CSV or tab-delimited text file` option to import contacts from. + +![MailChimp List Import Source](/media/articles/integrations/marketing/mailchimp/import-source.png) + +Next, upload the user data CSV file you exported from Auth0 in the previous section. MailChimp will interpret your user data on the following page. + +![MailChimp Import Column Match](/media/articles/integrations/marketing/mailchimp/import-column-match.png) + +Check that the column names and field types are correct, when you're ready to proceed click the **Next** button. + +![MailChimp Start Import](/media/articles/integrations/marketing/mailchimp/import-start.png) + +After reviewing your selections and setting the import category, click on the **Import** button to start the user import. + +That's it! You successfully imported your Auth0 users into MailChimp. diff --git a/fr-ca/articles/integrations/marketing/marketo/index.md b/fr-ca/articles/integrations/marketing/marketo/index.md new file mode 100644 index 0000000000..4df61e62c9 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/marketo/index.md @@ -0,0 +1,119 @@ +--- +title: Export User Data To Marketo +description: Learn how to export your Auth0 user data and import it into Marketo. +toc: true +topics: + - marketing + - marketo +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Marketo + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Marketo using the [Bulk Leads endpoint](http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#/Bulk_Leads) of the Marketo REST API. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Marketo accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +### Import a user data file + +::: note +[Marketo Documentation: Bulk Lead Import](http://developers.marketo.com/rest-api/bulk-import/bulk-lead-import/) +::: + +To import the user data file to Marketo, perform a POST request to the [Bulk Leads endpoint](http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#/Bulk_Leads). Set the content-type header of the request to `multipart/form-data` and include a `file` parameter with your exported CSV file as well as format parameter set to `csv`. For example: + +```har +{ + "method": "POST", + "url": "https://MARKETO_REST_API_BASE_URL/bulk/v1/leads.json", + "headers": [ + { + "name": "Authorization", + "value": "Bearer {MARKETO_ACCESS_TOKEN}" + } + ], + "postData": { + "mimeType": "multipart/form-data", + "params": [ + { + "name": "file", + "fileName": "auth0_users.csv", + "contentType": "text/csv" + }, + { + "name": "format", + "value": "csv", + "contentType": "text/plan" + } + ] + } +} +``` + +The response should look something like this: + +```json +{ + "requestId": "e42b#14272d07d78", + "success": true, + "result": [{ + "batchId": 1234, + "status": "Importing" + }] +} +``` + +You can check the status of your import using the [Get Import Lead Status API]() and your import job's `batchId`. For example: + +```har +{ + "method": "GET", + "url": "https://MARKETO_REST_API_BASE_URL/bulk/v1/leads/batch/BATCH_ID.json", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [ + { "name": "Authorization", "value": "Bearer {MARKETO_ACCESS_TOKEN}" } + ], + "headersSize" : 150, + "bodySize" : 0, + "comment" : "" +} +``` + +And the response: + +```json +{ + "requestId": "8136#146daebc2ed", + "success": true, + "result": [{ + "batchId": 1234, + "status": "Complete", + "numOfLeadsProcessed": 123, + "numOfRowsFailed": 0, + "numOfRowsWithWarning": 0 + }] +} +``` + +That's it! You successfully imported your Auth0 users into Marketo. diff --git a/fr-ca/articles/integrations/marketing/sailthru/index.md b/fr-ca/articles/integrations/marketing/sailthru/index.md new file mode 100644 index 0000000000..c4eaeb32a1 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/sailthru/index.md @@ -0,0 +1,55 @@ +--- +title: Export User Data To Sailthru +description: Learn how to export your Auth0 user data and import it into Sailthru. +toc: true +topics: + - marketing + - sailthru +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Sailthru + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Sailthru dashboard. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Sailthru accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +### Import a user data file + +::: note +[Sailthru Documentation: Adding Users to Sailthru and Sailthru Lists](https://getstarted.sailthru.com/audience/managing-users/add-users-to-sailthru-and-lists/#List_File_Upload) +::: + +To import your CSV file into Sailthru, follow these steps: + +1. Log in to Sailthru and navigate to [Lists](https://my.sailthru.com/lists). + +2. Choose a list, then click **Upload List** and select your CSV file. + +3. Select **Add To List** for the **Action**. + +4. Set your **Replace Vars** option and enter an email to receive notifications if desired. + +5. Review your settings and click **Submit** to upload the file. + +That's it! You successfully imported your Auth0 users into Sailthru. \ No newline at end of file diff --git a/fr-ca/articles/integrations/marketing/salesforce-marketing-cloud/index.md b/fr-ca/articles/integrations/marketing/salesforce-marketing-cloud/index.md new file mode 100644 index 0000000000..95a203e3a0 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/salesforce-marketing-cloud/index.md @@ -0,0 +1,61 @@ +--- +title: Export User Data To Salesforce Marketing Cloud +description: Learn how to export your Auth0 user data and import it into Salesforce Marketing Cloud. +toc: true +topics: + - marketing + - salesforce + - marketing-cloud +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Salesforce Marketing Cloud + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Salesforce Marketing Cloud using [Email Studio](https://help.salesforce.com/articleView?id=mc_es_get_started_with_email_studio.htm&type=5). + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Salesforce Marketing Cloud accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Email Studio: Import Subscribers](https://help.marketingcloud.com/en/documentation/exacttarget/subscribers/subscribers_for_interactive_marketing_hub/imports/importing_subscribers/) +::: + +Before you begin, make sure your Salesforce account has the required [user permissions](https://help.salesforce.com/articleView?id=faq_import_general_permissions.htm) to import records. + +To import your CSV file into Salesforce Marketing Cloud, follow these steps: + +1. Log in to Salesforce Marketing Cloud and open **Email Studio**. + +2. Navigate to **Subscribers > Lists**. + +3. Choose the list to import to and select the **Import** action. + +4. After the import wizard's introduction, select your CSV file as the **Upload Source** and select CSV as the **Data Format**. Enter the remaining settings and click **Next**. + +5. In the **Map Attributes** dialog, map your CSV file's data fields to the correct data fields. When you've finished your mappings click **Next**. + +6. After you've verified your mappings in the **Confirmed Mappings** dialog, click **Begin** to start the import. + +That's it! You successfully imported your Auth0 users into Salesforce Marketing Cloud. + diff --git a/fr-ca/articles/integrations/marketing/salesforce/index.md b/fr-ca/articles/integrations/marketing/salesforce/index.md new file mode 100644 index 0000000000..586964c0f1 --- /dev/null +++ b/fr-ca/articles/integrations/marketing/salesforce/index.md @@ -0,0 +1,68 @@ +--- +title: Export User Data To Salesforce +description: Learn how to export your Auth0 user data and import it into Salesforce. +toc: true +topics: + - marketing + - salesforce +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Salesforce + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Salesforce using the [Data Import Wizard](https://help.salesforce.com/articleView?id=data_import_wizard.htm). + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Salesforce accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +::: note +[Salesforce: Prepare Your Data for Import](https://help.salesforce.com/articleView?id=import_prepare.htm) +::: + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Salesforce: Import Data with the Data Import Wizard](https://help.salesforce.com/articleView?id=import_with_data_import_wizard.htm) +::: + +Before you begin, make sure your Salesforce account has the required [user permissions](https://help.salesforce.com/articleView?id=faq_import_general_permissions.htm) to import records. + +To import your CSV file into Salesforce, follow these steps: + +1. Login to [Salesforce](https://login.salesforce.com/). + +2. Navigate to **Setup** and open the **Data Import Wizard**. + +4. Click **Launch Wizard**. + +5. Configure the import and select your CSV file to upload using the fields provided. + +6. Click **Next**. + +7. On the **Edit Field Mapping** page, map your CSV file's data fields to Salesforce data fields. Click **Next** to proceed. + +8. After you've verified the information on the **Review** page, click **Start Import**. + +9. Check out the **Recent Import Jobs** tab on the **Data Import Wizard** home page for updates on the status of your import. + +That's it! You successfully imported your Auth0 users into Salesforce. + diff --git a/fr-ca/articles/integrations/marketing/watson-campaign-automation/index.md b/fr-ca/articles/integrations/marketing/watson-campaign-automation/index.md new file mode 100644 index 0000000000..5f65f357ce --- /dev/null +++ b/fr-ca/articles/integrations/marketing/watson-campaign-automation/index.md @@ -0,0 +1,69 @@ +--- +title: Export User Data To Watson Campaign Automation +description: Learn how to export your Auth0 user data and import it into Watson Campaign Automation. +toc: true +topics: + - marketing + - watson-campaign +contentType: how-to +useCase: export-users-marketing +--- + +# Export User Data To Watson Campaign Automation + +In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Watson Campaign Automation dashboard. + +## Create a user data file + +Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu. + +Next, set the **Export Format** to the required file format. Watson Campaign Automation accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option. + +![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png) + +At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example: + +User Field | Column Name +-----------|------------ +`email` | Email Address +`created_at` | Created At +`given_name` | First Name +`family_name` | Last Name + +![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png) + +::: note +[Watson Campaign Automation: Considerations for importing databases](https://www.ibm.com/support/knowledgecenter/en/SSWU4L/Data/imc_Data/import_details.html) +::: + +After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section. + +## Import a user data file + +::: note +[Watson Campaign Automation: About importing a database](https://www.ibm.com/support/knowledgecenter/en/SSWU4L/Data/imc_Data/Import_a_Database.html) +::: + +To import your CSV file into Watson Campaign Automation, follow these steps: + +1. Log in to Watson Campaign Automation and navigate to **Data > Import New**. + +2. On the **Select File** step, enter the new database's settings in the provided fields. + +3. Select the option to upload a file from a local hard drive, then click **Browse** to select the file. + +4. Set the file type to CSV (comma-separated values). + +5. Click **Next** to proceed to the **Define Data Format** step. + +6. Make sure your data was processed correctly, then click **Next**. + +7. On the **Map Fields** step, choose which fields to include in the import as well as their types. + +8. Click **Next** to proceed to the **Edit Field Settings** step. + +9. Edit the settings on default or new fields as needed. + +10. To start the import click **Next**. + +That's it! You successfully imported your Auth0 users into Watson Campaign Automation. \ No newline at end of file diff --git a/fr-ca/articles/integrations/office-365-custom-provisioning.md b/fr-ca/articles/integrations/office-365-custom-provisioning.md new file mode 100644 index 0000000000..cddf7399d4 --- /dev/null +++ b/fr-ca/articles/integrations/office-365-custom-provisioning.md @@ -0,0 +1,287 @@ +--- +description: How to setup Microsoft Office 365 custom provisioning. +topics: + - integrations + - microsoft + - office-365 +contentType: + - how-to + - concept +useCase: integrate-saas-sso +--- + +# Office 365 Custom Provisioning + +The default Office 365 setup will include Active Directory and DirSync/Azure AD Sync Services to synchronize and provision your AD users in Azure AD for SSO. Auth0 will then be configured to be an identity provider which is providing Single Sign-on (SSO) for these users. + +All of this is fine when you want SSO for your own users living in your AD. But for scenarios where you want to allow contractors, partners or even customers to access your Office 365 environment (eg: SharePoint) this approach is not optimal since these users would need to be created in your own AD environment. This is why Auth0 allows custom provisioning of Azure AD users from our rules. This would allow you to create users in Azure AD (and effectively Office 365) just as they login from any connection available in Auth0 (in that case your rule will take over DirSync's task for any type of connection where DirSync would not work). This will allow you to offer Facebook, LinkedIn, G Suite, ... logins to your Office 365 environment. + +## Configuring Office 365 + +The [Office 365 tutorial](/integrations/office-365) explains how to register a custom domain and how to configure Office 365 as a third party application in Auth0. This step is required before custom provisioning can be configured. + +## Configuring Azure AD + +Custom provisioning uses the Azure AD Graph API to provision new users in Azure AD. In order to access the Azure AD Graph API an application must be created within the Azure AD Directory that has been linked to the Office 365 subscription. + +1. Log into the [Azure Portal](https://portal.azure.com). +2. Choose [Azure Active Directory in the left navigation](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview). +3. Select **App registrations** in the new menu. +4. Click on **New application registration**. +5. Fill the form: + 1. Input a name for the application (such as `Auth0 Provisioning`) + 2. Select **Web app / API** as the **Application type**. + 3. Insert a sign-on URL. Any valid url as this won't be really used. +5. The recently created app will appear in the **App registrations** list. Select it. +6. In the **Settings** blade (Microsoft call these sections as blade), choose **Keys**. +7. Input a **Description** (like `Auth0 Provision`) and choose a **Duration** for the new key. If you choose to issue non-permanent key, take note of the expiration date and create a reminder to replace the key with a new one before it expires. +8. Click on save the key and copy the **App Key**. This key will be shown only once and it's needed for the Auth0 rule. +![Creating a key on Azure AD apps registration](/media/articles/integrations/office-365/office-365-app-key.png) +9. Choose **Required permissions** and click **Add** in the new blade. +10. Select the **Microsoft Graph** API and then check `Read and write directory data` under **Application Permissions**. +11. Back in the **Required permissions**, click on the **Grant Permissions** button and then click **Yes** to grant the requested permissions. + +## Azure AD Provisioning Rule + +The following rule shows the provisioning process: + + 1. If the user comes from the AD connection, skip the provisioning process (because this will be handled by DirSync) + 2. If the user was already provisioned in Azure AD, just continue with the login transaction. + 3. Get an Access Token of the Graph API using the Azure AD Client ID and Key + 4. Create a user in Azure AD + 5. Assign a license to the user. + 6. Continue with the login transaction. + +The username is generated with the `createAzureADUser` function, which by default generates a username in the format `auth0-c3fb6eec-3afd-4d52-8e0a-d9f357dd19ab@fabrikamcorp.be`. You can change this to whatever you like, just make sure this value is unique for all your users. + +Make sure you set the correct values for the `AUTH0_OFFICE365_CLIENT_ID`, `AAD_CUSTOM_DOMAIN`, `AAD_DOMAIN`, `AAD_APPLICATION_ID` and `AAD_APPLICATION_API_KEY` values in your [configuration object](/rules/current#use-the-configuration-object) to make the values available in your rule code. + +In the code you'll also see that the rule will wait about 15 seconds after the user is provisioned. This is because it takes a few seconds before the provisioned user is available for Office 365. + +```js +function (user, context, callback) { + // Require the Node.js packages that we are going to use. + // Check this website for a complete list of the packages available: + // https://auth0-extensions.github.io/canirequire/ + var rp = require('request-promise'); + var uuidv4 = require('uuid'); + + // The name of your Active Directory connection (if using one) + var AUTH0_AD_CONNECTION = 'FabrikamAD'; + // The client_id of your Office 365 SSO integration + // You can get it from the URL when editing the SSO integration, + // it will look like + // https://manage.auth0.com/#/externalapps/{the_client_id}/settings + var AUTH0_OFFICE365_CLIENT_ID = configuration.AUTH0_OFFICE365_CLIENT_ID; + // The main domain of our company. + var YOUR_COMPANY_DOMAIN = 'mycompanyurl.com'; + // Your Azure AD domain. + var AAD_DOMAIN = configuration.AAD_DOMAIN; + // The Application ID generated while creating the Azure AD app. + var AAD_APPLICATION_ID = configuration.AAD_APPLICATION_ID; + // The generated API key for the Azure AD app. + var AAD_APPLICATION_API_KEY = configuration.AAD_APPLICATION_API_KEY; + // The location of the users that are going to access Microsoft products. + var AAD_USAGE_LOCATION = 'US'; + // Azure AD doesn't recognize the user instantly, it needs a few seconds + var AAD_USER_CREATE_DELAY = 15000; + // The key that represents the license that we want to give the new user. + // Take a look in the following URL for a list of the existing licenses: + // https://gist.github.com/Lillecarl/3c4727e6dcd1334467e0 + var OFFICE365_KEY = 'O365_BUSINESS'; + + // Only execute this rule for the Office 365 SSO integration. + if (context.clientID !== AUTH0_OFFICE365_CLIENT_ID) { + return callback(null, user, context); + } + + // Skip custom provisioning for AD users. + if (context.connection === AUTH0_AD_CONNECTION) { + return callback(null, user, context); + } + + // If the user is already provisioned on Microsoft AD, we skip + // the rest of this rule + user.app_metadata = user.app_metadata || {}; + if (user.app_metadata.office365Provisioned) { + return connectWithUser(); + } + + // Global variables that we will use in the different steps while + // provisioning a new user. + var token; + var userPrincipalName; + var mailNickname = user.email.split('@')[0]; + var uuid = uuidv4.v4(); + var immutableId = new Buffer(uuid).toString('base64'); + var userId; + + // All the steps performed to provision new Microsoft AD users. + // The definition of each function are below. + getAzureADToken() + .then(createAzureADUser) + .then(getAvailableLicenses) + .then(assignOffice365License) + .then(saveUserMetadata) + .then(waitCreateDelay) + .then(connectWithUser) + .catch(callback); + + // Requests an Access Token to interact with Windows Graph API. + function getAzureADToken() { + var options = { + method: 'POST', + url: 'https://login.windows.net/' + AAD_DOMAIN + '/oauth2/token?api-version=1.5', + headers: { + 'Content-type': 'application/json', + }, + json: true, + form: { + client_id: AAD_APPLICATION_ID, + client_secret: AAD_APPLICATION_API_KEY, + grant_type: 'client_credentials', + resource: 'https://graph.windows.net' + }, + }; + + return rp(options); + } + + // Gets the Access Token requested above and assembles a new request + // to provision the new Microsoft AD user. + function createAzureADUser(response) { + token = response.access_token; + userPrincipalName = 'auth0-' + uuid + '@' + YOUR_COMPANY_DOMAIN; + + var options = { + url: 'https://graph.windows.net/' + AAD_DOMAIN + '/users?api-version=1.6', + headers: { + 'Content-type': 'application/json', + 'Authorization': 'Bearer ' + token + }, + json: true, + body: { + accountEnabled: true, + displayName: user.nickname, + mailNickname: mailNickname, + userPrincipalName: userPrincipalName, + passwordProfile: { + password: immutableId, + forceChangePasswordNextLogin: false + }, + immutableId: immutableId, + usageLocation: AAD_USAGE_LOCATION + }, + }; + + return rp(options); + } + + // After provisioning the user, we issue a request to get the list + // of available Microsoft products licenses. + function getAvailableLicenses(response) { + userId = response.objectId; + var options = { + url: 'https://graph.windows.net/' + AAD_DOMAIN + '/subscribedSkus?api-version=1.6', + json: true, + headers: { + 'Content-type': 'application/json', + 'Authorization': 'Bearer ' + token + } + }; + return rp(options); + } + + // With the licenses list, we iterate over it to get the id (skuId) of the + // license that we want to give to the new user (office 365 in this case). + // We also issue a new request to the Graph API to tie the user and the + // license together. + function assignOffice365License(response) { + var office365License; + + for (var i = 0; i < response.value.length; i++) { + if (response.value[i].skuPartNumber === OFFICE365_KEY) { + office365License = response.value[i].skuId; + break; + } + } + + var options = { + url: ' https://graph.windows.net/' + AAD_DOMAIN + '/users/' + userId + '/assignLicense?api-version=1.6', + headers: { + 'Content-type': 'application/json', + 'Authorization': 'Bearer ' + token + }, + json: true, + body: { + 'addLicenses': [ + { + 'disabledPlans': [], + 'skuId': office365License + } + ], + 'removeLicenses': [] + } + }; + return rp(options); + } + + // After provisioning the user and giving a license to them, we record + // (on Auth) that this G Suite user has already been provisioned. We + // also record the user's principal username and immutableId to properly + // redirect them on future logins. + function saveUserMetadata() { + user.app_metadata = user.app_metadata || {}; + + user.app_metadata.office365Provisioned = true; + user.app_metadata.office365UPN = userPrincipalName; + user.app_metadata.office365ImmutableId = immutableId; + + return auth0.users.updateAppMetadata(user.user_id, user.app_metadata); + } + + // As mentioned, Windows Graph API needs around 10 seconds to finish + // provisioning new users (even though it returns ok straight away) + function waitCreateDelay() { + return new Promise(function (resolve) { + setTimeout(function() { + resolve(); + }, AAD_USER_CREATE_DELAY); + }); + } + + // Adds the principal username and immutableId to the user object and ends + // the rule. + function connectWithUser() { + user.upn = user.app_metadata.office365UPN; + user.inmutableid = user.app_metadata.office365ImmutableId; + return callback(null, user, context); + } +} +``` + +::: note +This code shows the provisioning process of a new user, but you can also adapt the code to synchronize metadata of existing users. +::: + +## End-user Experience + +The easiest way for your external users to authenticate is by using IdP initiated login: [Using smart links or IdP initiated authentication with Office 365](https://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365). + +You will basically need to redirect your users to the following URL (eg: using a "smart link" like `https://office.fabrikamcorp.com`): + +``` +https://${account.namespace}/login?client=AUTH0_OFFICE365_CLIENT_ID&protocol=wsfed&state=&redirect_uri=& +``` + +::: panel AUTH0_OFFICE365_CLIENT_ID +The `AUTH0_OFFICE365_CLIENT_ID` value can be obtained from the URL when working with the Dashboard. When viewing or editing the settings for the Office 365 SSO Integration in Auth0, you will see a URL in the form of `${manage_url}/#/externalapps/${account.clientId}/settings`. The `${account.clientId}` is the value you need here. +::: + +This will show them the Auth0 login page after which they'll be redirected to Office 365. It will be important to explain external users that this is the only way they can authenticate, since the Office 365 login page does not support Home Realm Discover for these external users. This also means that, when they try to open a link, they'll need to visit the smart link first before the can access the link they tried to open. + +![Different connections enabled for Office 365](/media/articles/integrations/office-365/office-365-different-connections.png) + +In this example Fabrikam enabled a few social accounts and a database connection for their Office 365 Third Party application in Auth0. + +<%= include('./_office-365-deep-linking') %> diff --git a/fr-ca/articles/integrations/office-365.md b/fr-ca/articles/integrations/office-365.md new file mode 100644 index 0000000000..03c17657ba --- /dev/null +++ b/fr-ca/articles/integrations/office-365.md @@ -0,0 +1,204 @@ +--- +description: Overview of Microsoft Office 365 Integration with Auth0. +toc: true +topics: + - integrations + - microsoft + - office-365 +contentType: how-to +useCase: integrate-saas-sso +--- +# Office 365 Integration + +Auth0 can help radically simplify the authentication process for Office 365. In this tutorial, you'll learn how to add Single Sign-on (SSO) to Office 365 using Auth0. + +## Why use Auth0 for Office 365 + +Your users will be able to log in using their existing Active Directory credentials, with support for Integrated Windows Authentication (Kerberos) if they're on a domain-joined machine in the corporate network. + +This would typically require you to setup [an advanced ADFS infrastructure](https://msdn.microsoft.com/en-us/library/azure/dn151324.aspx) with Federation Servers in the corporate network and Web Application Proxies exposed in the DMZ. But with Auth0 as an identity provider for Office 365 all of this is handled by the [AD Connector](/connector/overview) which doesn't require you to expose any of your servers to the outside world. + +In addition to that users can also setup SSO with custom apps or integrations like Salesforce, Dropbox, and SharePoint Server. + +## High-level Overview + +Office 365 is a service that consists of a number of products and services. Users are added to an Office 365 subscription after which licenses can be assigned to them (such as Lync Online, Exchange Online). + +![Office 365 Users](/media/articles/integrations/office-365/office-365-users-overview.png) + +Office 365 uses Azure AD as an identity store which supports different account management and authentication models: + +1. **Cloud Identity**: Users are created in the cloud (Office 365/Azure AD) with no relation to an on-premises directory. Authentication happens with Azure AD. +2. **Synchronized Identity**: Users are synchronized from an on-premises LDAP directory (like Active Directory) to Azure AD. This means the user management can happen on-premises but authentication will always happen in the cloud using Azure AD. +3. **Federated Identity**: Users are synchronized from an on-premises LDAP directory (like Active Directory) to Azure AD. In this case Azure AD will act as the user store, but authentication will happen with a SAML 2.0 identity provider configured by the customer. This can be an ADFS server, Shibboleth, or in our case, Auth0. With this third model you can add SSO support to Office 365. + +This means that even if you use Auth0 for SSO support in Office 365, you will always need to synchronize your on-premises users to Office 365/Azure AD because it will be used as a user store (for user information, assigning licenses to those users, and so on.). + +![Office 365 High-level Overview](/media/articles/integrations/office-365/office-365-high-level-overview.png) + +When authentication is handed over to Auth0 it will use the AD Connector to authenticate the user. The link between the Auth0 user and the user in Azure AD is made using the `User Principal Name`. When Jack is synchronized to Azure AD his UPN will be `jack@fabrikamcorp.be` and when Jack authenticates using Auth0 the same UPN will be included in the SAML assertion to identify the authenticated user to the user stored in Azure AD. + +::: note +If you're interested in providing SSO to Office 365 using other connections (like Database Connections or traditional AD) you can [write a rule with custom provisioning logic](/integrations/office-365-custom-provisioning) +::: + +## Configure Synchronization With Office 365 / Azure AD + +The synchronization with your local LDAP directory can be configured in Office 365 or Azure AD (if you have an Azure Subscription). + +Before setting up the actual synchronization we'll need to add a custom domain for which federation can be enabled (this does not work with the default `tenant.onmicrosoft.com` domain). + +![Office 365 Domain](/media/articles/integrations/office-365/office-365-domain.png) + +The domain can be configured under the **Domains** menu of the Admin Center where you'll need to validate it (using a TXT or MX record). + +Once the domain is validated you can [Activate Active Directory synchronization](https://portal.office.com/Default.aspx#@/DirSync/DirectorySynchronization.aspx), run the IdFix tool (to fix common errors in Active Directory) and finally install and configure **Azure AD Sync Services**. + +![AAD Sync](/media/articles/integrations/office-365/office-365-aad-sync.png) + +After installing and configuring the tool you'll be able to start the synchronization and your AD users will start showing up in the Admin Center user overview. + +## Configure SSO With Auth0 + +Everything in terms of synchronization has been configured and we can now proceed to the SSO configuration with Auth0. We will start by adding Office 365 as a SSO Integration in the dashboard. + +![](/media/articles/integrations/office-365/office-365-SSO.png) + +On the **Settings** tab we'll need to enter our custom domain name (eg: `fabrikamcorp.be`) and choose the Active Directory connection we want to use. + +![Settings Page](/media/articles/integrations/office-365/office-365-settings-page.png) + +The **Tutorial** page will now be updated to match the settings and we'll need to run the few lines of PowerShell in the [Azure Active Directory Module for Windows PowerShell](https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx). + +Here's the script Fabrikam Corporation will be running to configure their Office 365 subscription: + +```powershell +$cred = Get-Credential +Connect-MsolService –Credential $cred + +Set-MsolDomainAuthentication + -DomainName "fabrikamcorp.be" + -FederationBrandName "fabrikamcorp.be" + -Authentication Federated + -PassiveLogOnUri "https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi" + -ActiveLogonUri "https://fabrikam.auth0.com/yNqQMENaYIONxAaQmrct341tZ9joEjTi/trust/usernamemixed?connection=FabrikamAD" + -MetadataExchangeUri "https://fabrikam.auth0.com/wsfed/FederationMetadata/2007-06/FederationMetadata.xml?connection=FabrikamAD" + -SigningCertificate "MIID..." + -IssuerUri "urn:fabrikam" + -LogOffUri "https://fabrikam.auth0.com/logout" + -PreferredAuthenticationProtocol WsFed +``` + +## End-user Experience + +Depending on which device the user is connecting from and the user's location (within the corporate network or not) the end-user experience will be different. + +### With Kerberos + +If Kerberos has been configured for the Active Directory connection and the users are on a domain-joined machine in the corporate network they'll be able to authenticate using Integrated Windows Authentication (Kerberos) without having to enter their credentials. + +To skip the Auth0 page with the **windows authentication** button you can append `?whr={name-of-the-ad-connection}` to the `PassiveLogOnUri` parameter of the PowerShell script. + +``` +-PassiveLogOnUri "https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi?whr=FabrikamAD" +``` + +### Without Kerberos + +When authentication with Kerberos is not possible (eg: not enabled for the connection, not a domain-joined machine, not in the corporate network, and so on.) the users will see the username/password login page instead. + +![Login Page](/media/articles/integrations/office-365/office-365-login-page.png) + +This is where they'll enter their Active Directory credentials after which they'll be signed in to Office 365. + +## Log in Users without the Azure AD Portal + +When users navigate to [https://portal.office.com](https://portal.office.com) they will always see the Azure AD login page which will redirect the users to the configured identity provider after entering their username. Using the IdP initiated login flow we can skip this step. + +Auth0 exposes an endpoint that can immediately start the login without showing the Azure AD login page. The format is as follows: + +`https://{tenant}.auth0.com/wsfed/{client-id}?whr={AD-connection-name}` + +For Fabrikam's SSO Integration the URL will look like this: + +`https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi?whr=FabrikamAD` + +Fabrikam can now host a simple website, like `http://office.fabrikamcorp.com` which contains a redirect to this url to trigger the automatic login flow. + +``` + + + Fabrikam Office + + + +``` + +For users without Kerberos this will immediately show the login page. Users on a domain-joined machine will immediately be signed in to Office 365. + +<%= include('./_office-365-deep-linking') %> + +## Handling multiple domains + +If you have multiple domains associated to your Microsoft account, you will have to run the PowerShell script once for each domain, choosing a different `IssuerUri` for each domain. The `IssuerUri` is an arbitrary value, but it makes sense to make it match the domain and at least have a consistent naming convention. Here's the script that Fabrikam would use for its `contoso.com` domain: + +```powershell +$cred = Get-Credential +Connect-MsolService –Credential $cred + +Set-MsolDomainAuthentication + -DomainName "contoso.com" + -FederationBrandName "contoso.com" + -IssuerUri "urn:contoso.com" + [...other options remain the same for all domains...] +``` + +### Multiple domains and products using Legacy Authentication + +Office products support [Modern Authentication](https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517) ("ADAL") and/or "Legacy" authentication (depending on product and version number). Every response sent by Auth0 to Office 365 includes a fixed "Issuer" attribute that is `urn:{your Auth0 account}`. If your setup requires that one or more Office products use legacy authentication, you will have to create a rule that changes the `Issuer` dynamically depending on the domain. To do this: + +1. Go to your Office 365 SSO Integration settings in Auth0, and copy the client ID from the URL. The URL will look like this: +``` +${manage_url}/#/externalapps/YOUR_CLIENT_ID/settings +``` +You will need the `YOUR_CLIENT_ID` part of the segment. + +2. Go to the **Rules** section and create a new rule. Start from the **Empty** template, name it `Set Issuer for Office 365 SSO Integration` and write code similar to this to set the issuer according to the domain of the user's email: + +```js +function (user, context, callback) { + // retrieve values from the configuration object + const office365ClientId = configuration.OFFICE365_CLIENT_ID; // put the right client id + const primaryDomain = configuration.PRIMARY_DOMAIN; // for example, exampleco.com + const secondaryDomain = configuration.SECONDARY_DOMAIN; + + if (context.clientID !== office365ClientId) + return callback(null, user, context); + + var getIssuerURI = function(domain) { + // write code that returns the right issuer URI + // for each domain + if (domain === primaryDomain) { + return 'urn:' + primaryDomain; + } else if (domain === secondaryDomain) { + return 'urn:' + secondaryDomain; + } + return null; + } + + var domain = (user.userPrincipalName || user.email).split('@')[1]; + + // set the issuer according to the domain from + // the user's email address + var issuer = getIssuerURI(domain); + + if (issuer) { + context.samlConfiguration = context.samlConfiguration || {}; + context.samlConfiguration.issuer = issuer; + } + + callback(null, user, context); +} +``` + +Remember to set the right `office365ClientId` and adjust the mapping logic according to the IssuerURIs selected for each domain. diff --git a/fr-ca/articles/integrations/office365-connection-deprecation-guide.md b/fr-ca/articles/integrations/office365-connection-deprecation-guide.md new file mode 100644 index 0000000000..28a608c5ca --- /dev/null +++ b/fr-ca/articles/integrations/office365-connection-deprecation-guide.md @@ -0,0 +1,30 @@ +--- +description: Details migrating Office365 connections to Windows Azure AD. +topics: + - integrations + - microsoft + - office-365 + - windows + - azure-ad + - active-directory +contentType: how-to +useCase: integrate-saas-sso +--- + +# Migrate Office365 Connections to Windows Azure AD + +::: warning +Office365 has been deprecated. You should migrate your Office365 Connections to Windows Azure AD Connections. +::: + +Since early days, we supported authenticating users with Office365. Office365 has always used Windows Azure AD behind the scenes, but there wasn't a good UI to create an "application" in Windows Azure AD. That's why you had to create it in the Seller Dashboard. Moving forward Microsoft wants you to use Windows Azure AD and you can now easily create a directory associated with your Office365 account and the application. + +## How to migrate to Azure + +1. Create a Windows Azure AD subscription (free) + +2. Create a Directory (that will be associated with your Office365 account) and an application as explained [here](/waad-clientid). + +::: warning +If you were using the `user_id` in your application, notice that it will change from `office365|....some-guid....` to `waad|...email....`. +::: diff --git a/fr-ca/articles/integrations/sharepoint-apps.md b/fr-ca/articles/integrations/sharepoint-apps.md new file mode 100644 index 0000000000..54666c43c3 --- /dev/null +++ b/fr-ca/articles/integrations/sharepoint-apps.md @@ -0,0 +1,91 @@ +--- +description: How to connect provider hosted apps to SharePoint Online. +topics: + - integrations + - sharepoint +contentType: how-to +useCase: integrate-saas-sso +--- +# Connecting Provider Hosted Apps to SharePoint Online + +Auth0 can help radically simplify the authentication process for SharePoint Apps. Auth0 will negotiate an Access Token you can the use to call SharePoint APIs. + +You won't need any special libraries. You can use any of the SDKs supported by Auth0. + +## 1. Register your application in Auth0 + +Just register a new application in Auth0 as you would normally do: __Applications > NEW__. Pick up any of the SDKs available for detailed instructions. Keep the `client_id` handy, as you will need it in the next step. + +## 2. Create a package for your application + +You need to obtain a __Client ID__ and a __Client Secret__ for your application. There are many ways of registering your application depending on the expected usage. + +::: note +[This article](http://msdn.microsoft.com/en-us/library/office/jj687469(v=office.15).aspx) explains all different ways of registering your application in SharePoint. This step in the tutorial will use the simplest form: using self-registration in a specific tenant (yours). +::: + +### Open SharePoint Online + +The URL for the dashboard is `https://{your Office365 tenant}.sharepoint.com/_layouts/15/appregnew.aspx` + +### Generate a __Client_Id__ and __ClientSecret__: + +![](/media/articles/integrations/sharepoint-apps/90SvG.png) + +### Complete the information in the form: + +Since Auth0 is in between your app and the Office 365 infrastructure, you need to use this URL for the app: + +**App Domain**: + + ${account.namespace} + +**Redirect URI**: + + https://${account.namespace}/login/callback?SP_APP_TOKEN&connection=CONNECTION&client_id=${account.clientId}&redirect_uri=${account.callback} + +* `connection` is just the name you will use in Auth0's connections (such as "sharepoint"). +* `client_id` identifies your app in Auth0 (created in steps 1). +* `redirect_uri` is the location in your actual app, where your users will land eventually after all negotiations complete. If you don't specify it, it will always be the app's callback URL defined in Auth0 (it could be localhost) + +### Package the app and upload to SharePoint: + +Complete the information in your app manifest in Visual Studio: + +![](/media/articles/integrations/sharepoint-apps/90SEc.png) + +Notice the `Query string` will be exactly like the `Redirect URI` you completed before. Then right-click on the project and select `Publish`: + +![](/media/articles/integrations/sharepoint-apps/90SUB.png) + +Create a __Publishing Profile__ (you will have to enter the same __Client Id__ & __Client Secret__ obtained in the SharePoint dashboard). + +Click on __Package__ and upload the resulting file to SharePoint. + + +## 3. Create the Connection in Auth0 + +The last step in the integration is to add a SharePoint connection in Auth0: + +![](/media/articles/integrations/sharepoint-apps/8XoVl.png) + +You will need: + +* `Connection Name`. This is an arbitrary name. It has to match with what you entered in step 2. +* `Client Id` & `Client Secret`. Also need to match what you entered in step 2. +* `Test SharePoint Site Url`. This is the SP site URL used to test the connection. (such as when pressing the 'Try' button on the dashboard). This is never used at runtime because users will always follow the link to your site from within SharePoint. + + +Users will install your app from the Office Marketplace. When they click on the link, they will be directed to Auth0, which will negotiate the Access Token for you, and finally to your app. Your app will receive a `User Profile` that will look like this: + +![](/media/articles/integrations/sharepoint-apps/8Xp6x.png) + +::: note +Notice that the following properties will be included: `cacheKey`, `refresh_token`, `host`, and `site`. These will allow you to call back SharePoint APIs (such as lists). +::: + +```text + GET https://yoursite.sharepoint.com/_api/web/lists + Accept: application/json;odata=verbose + Authorization: Bearer THE_ACCESS_TOKEN +``` diff --git a/fr-ca/articles/integrations/sharepoint.md b/fr-ca/articles/integrations/sharepoint.md new file mode 100644 index 0000000000..4870a916cb --- /dev/null +++ b/fr-ca/articles/integrations/sharepoint.md @@ -0,0 +1,289 @@ +--- +description: How to integrate with SharePoint 2010/2013, including setup, troubleshooting, accessing logs and next steps. +topics: + - integrations + - sharepoint +contentType: how-to +useCase: integrate-saas-sso +--- + +# SharePoint 2010/2013 Integration + +Auth0 can help to radically simplify the authentication process for SharePoint. In this tutorial, you'll learn how to add Single Sign-on (SSO) to Sharepoint using Auth0. Your users will be able to log in using any of our [Social Identity Providers](/identityproviders) (Facebook, Twitter, Github, and so on), [Enterprise Providers](/identityproviders) (LDAP, Active Directory, ADFS, and so on) or with a username and password. + +## Setup + +### 1. Adding the Integration to your account + +The first thing you need to do is go to the [SSO Integrations](${manage_url}/#/externalapps/create) section in the Dashboard and choose **SharePoint** from the list of apps. + +![Create a new SSO Integration](/media/articles/integrations/sharepoint/sharepoint-new-sso.png) + +### 2. Follow the Live Documentation + +::: note +If your SharePoint server does not have Internet access, you will need to download the installation files to a SharePoint server manually ([Learn more about offline installation](https://github.com/auth0/auth0-sharepoint/tree/master/auth0-authentication-provider#offline-installation)). +::: + +On the **Settings** tab you'll need to enter the URL of the SharePoint Web Application and the external URL (typically the internet endpoint in your Alternate Access Mappings). + +![Tutorial](/media/articles/integrations/sharepoint/sharepoint-app-tutorial.png) + +The Live Documentation will first start with the installation of the Auth0 CmdLets for SharePoint: + +![Auth0 CmdLets for SharePoint](/media/articles/integrations/sharepoint/sharepoint-cmdlets-installation.png) + +Once these have been installed you'll be able to enable/disable Auth0 and the Claims Provider for the different Web Applications. You will need to enable authentication with Auth0: + +![Auth0 Authentication for SharePoint](/media/articles/integrations/sharepoint/sharepoint-auth-installation.png) + +And then install the Claims Provider, to make sure that the People Picker and permissions work correctly: + +![Claims Provider for SharePoint](/media/articles/integrations/sharepoint/sharepoint-cp-installation.png) + +Once these scripts have been executed you'll complete the configuration in Central Administration: + +![Central Administration](/media/articles/integrations/sharepoint/sharepoint-central-admin.png) + +Note that the call to `Enable-Auth0` can be adapted to: + + - Change the unique identifier for users (such as email or a user id) + - Allow additional claims to be passed through to SharePoint + - Enable or disable the default Windows Authentication + +The following example also adds the Role claim to the claims mapping and allows Windows Authentication: + +``` +Enable-Auth0 + -auth0Domain:"fabrikam.auth0.com" + -clientId:"bOFty3tWgpijnwMcltysNFqHgO1ziz1I" + -webAppUrl:"http://fabrikam-sp/" + -identifierClaimType:"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + -claims:@( + "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "Client ID|http://schemas.auth0.com/clientID", + "Given Name|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "Surname|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "Picture|http://schemas.auth0.com/picture") + -allowWindowsAuth +``` + +### 3. You now have Sharepoint configured + +You have configured SharePoint to use Auth0 as the SSO broker. When your users visit your site they'll be presented with a login page showing all the connections enabled for that application. + +![SharePoint Login Page](/media/articles/integrations/sharepoint/sharepoint-login-page.png) + +Depending on which claims have been mapped when installing the claims provider this additional information will also be available in the user's personal settings page: + +![SharePoint User Info](/media/articles/integrations/sharepoint/sharepoint-user-info.png) + +## Customizing the Login Page + +You can customize the login page by following the instructions in the [documentation on customizing the login page](/universal-login#simple-customization). + +You might wish to provide a way to let users authenticate with Sharepoint using Windows Authentication, bypassing Auth0. You can do that by customizing the login page, adding a link to the Windows Authentication endpoint (usually similar to `https://yoursharepointserver/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx`). + +On way of doing it is by using jQuery to modify the Lock widget and add a link to the Windows Authentication endpoint. + +You need to add a reference to jQuery at the top of the `` section of the customized login page. + +```js + +``` + +Before calling `lock.show()`, add code to modify the HTML DOM that adds the link. + +```js +// construct Lock +// var lock = ... +[...] +// One or more SharePoint client IDs here for which you want +// a Windows Auth button +var sharepointClientIDs = ['your_sharepoint_client_id']; + +if (sharepointClientIDs.indexOf(config.clientID) >= 0) { + lock.on('signin ready', function() { + var getParameterByName = function(name) { + name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]"); + var regexS = "[\\?&]" + name + "=([^&#]*)"; + var regex = new RegExp(regexS); + var results = regex.exec(window.location.search); + if (results == null) return null; + else return results[1]; + }; + // get the host from the callback URL + var parser = document.createElement('a'); + parser.href = config.callbackURL; + var host = parser.host; + var windowsAuthURL = "https://" + host + "/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx"; + var wctx = getParameterByName("wctx"); + if (wctx) { + windowsAuthURL += "&Source=" + wctx; + } + + $('.auth0-lock-tabs-container') + .after('').attr('href','https://nowhere'); + }); +} + +lock.show(); +``` + +![SharePoint Login Page Windows Auth](/media/articles/integrations/sharepoint/sharepoint-login-page-windows-auth.png) + +## Troubleshooting + +When working with additional claims and authorization it can always be useful to view the claims for the current user. [Liam Clearly](https://www.helloitsliam.com)'s [Claims Viewer Web Part](https://sharepointobservations.wordpress.com/2013/08/21/sharepoint-2013-and-adfs-2-0-test-with-claims-viewer-web-part/) can be used to troubleshoot any issues with the user's claims: + +![Claims Webpart](/media/articles/integrations/sharepoint/sharepoint-claims-webpart.png) + +### Logs in SP2010 + +Errors and warnings are logged to SharePoint's Unified Logging Service and tools like the [ULS Viewer](http://www.microsoft.com/en-us/download/details.aspx?id=44020) can be used to troubleshoot any issues you might have when using the Claims Provider. + +![ULS](/media/articles/integrations/sharepoint/sharepoint-uls-logs.png) + +### Logs in SP2013 + +For SharePoint 2013 we no longer use the Unified Logging Service for our logs, but we've moved to Event Tracing for Windows instead. This delivers more performance and gives you multiple ways of capturing all the logged events. + +To view the logs in real-time you can download [the Logs Processor](https://github.com/auth0/auth0-sharepoint/releases). Run this tool on your SharePoint Server(s) to see every call SharePoint is making to the Claims Provider: + +![ETW](/media/articles/integrations/sharepoint/sharepoint-logs-real-time.png) + +## Next Steps + +### Authorization + +The claims being passed through from Auth0 can also be used for authorization in SharePoint. For example, a user with the Role claim containing **Fabrikam HR** should have access or be a Contributor on a specific site. + +Let's take Azure AD as an example. In this Cloud Directory users can be part of groups and David is part of Fabrikam HR. + +![Azure AD Group Member](/media/articles/integrations/sharepoint/sharepoint-group-member.png) + +When David logs in using his Azure AD account (and the Security Groups attribute is enabled for that connection) the group memberships will be stored in the `groups` attribute of the user's profile. + +![User Groups](/media/articles/integrations/sharepoint/sharepoint-profile-groups.png) + +If we want to make these groups available as Roles in SharePoint we'll need to write a [Rule](${manage_url}/#/rules) that adds this to the SAML configuration. This rule will only run for the application named **Fabrikam Intranet (SharePoint)**. + +``` +function (user, context, callback) { + if (context.clientName === 'Fabrikam Intranet (SharePoint)') { + context.samlConfiguration.mappings = { + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'user_id', + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress': 'email', + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name': 'name', + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname': 'given_name', + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname': 'family_name', + 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn': 'upn', + 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role': 'groups' + }; + } + + callback(null, user, context); +} +``` + +This will add an additional outgoing claim `http://schemas.microsoft.com/ws/2008/06/identity/claims/role` containing the `groups` and which will be used by SharePoint for authorization. + +When installing the Claims Provider we need to allow the Role claim to be passed through to SharePoint, by adding it to the claims mapping list: + +``` +Enable-Auth0 + -auth0Domain:"fabrikam.auth0.com" + ... + -claims:@( + "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", + ...) + ... + -Verbose +``` + +By default a user won't have access to the site: + +![Access Denied](/media/articles/integrations/sharepoint/sharepoint-no-access.png) + +Now instead of adding that specific user to a SharePoint Group (eg: Contributors) we can now add a **Role** to a SharePoint Group. Here's a sample PowerShell script that shows how to add "Fabrikam HR" members to the Contributors group: + +``` +$webName = "http://fabrikam-sp" +$groupName = "Contributors" +$roleClaim = "Fabrikam HR" + +$sts = Get-SPTrustedIdentityTokenIssuer "Auth0" +$claimPrincipal = New-SPClaimsPrincipal -ClaimValue $roleClaim -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts + +$web = Get-SPWeb $webName +$user = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web + +$group = $web.SiteGroups[$groupName] +$group.AddUser($user) +``` + +After adding this claim value to the Contributors group David will be able to access the site and edit its contents. + +### User Profile Synchronization + +By default SharePoint is able to synchronize user profile information originating from Active Directory. Now with Auth0 users can come from different types of connections (from social to enterprise) which will require a different approach to synchronize user profiles. + +A first approach would be to create a timer job that runs every few hours, queries the Auth0 Users Endpoint and synchronizes the profile information for those users. + +```cs +using System; + +using Microsoft.SharePoint; +using Microsoft.SharePoint.Administration; + +using Microsoft.Office.Server; +using Microsoft.Office.Server.UserProfiles; + +namespace UserProfileSync +{ + class Program + { + static void Main(string[] args) + { + // Call the Auth0 Management API - https://docs.auth0.com/api/v2 + + using (var site = new SPSite("http://servername")) + { + var context = SPServiceContext.GetContext(site); + var profileManager = new UserProfileManager(context); + + var accountName = "i:05.t|auth0|john@example.org"; + var userProfile = profileManager.GetUserProfile(accountName); + userProfile[PropertyConstants.HomePhone].Value = "+1 594 9392"; + userProfile.Commit(); + } + } + } +} +``` + +Alternatively this logic could also be implemented as an HttpModule which runs each time the user logs in: + +```cs +public class PersistUserClaimsHttpModule : IHttpModule +{ + private SPFederationAuthenticationModule FederationModule + { + get { return HttpContext.Current.ApplicationInstance.Modules["FederatedAuthentication"] as SPFederationAuthenticationModule; } + } + + public void Init(HttpApplication context) + { + FederationModule.SecurityTokenValidated += OnFederationSecurityTokenValidated; + } + + private void OnFederationSecurityTokenValidated(object sender, SecurityTokenValidatedEventArgs e) + { + // Use e.ClaimsPrincipal + } +} +``` diff --git a/fr-ca/articles/integrations/sso/_template.md b/fr-ca/articles/integrations/sso/_template.md new file mode 100644 index 0000000000..3cf0d599a6 --- /dev/null +++ b/fr-ca/articles/integrations/sso/_template.md @@ -0,0 +1,174 @@ +# Configure SSO Integration for ${service} + +This guide will show you how to configure an SSO integration. + +<% if (service === "Active Directory RMS") { %> +::: warning +The steps in this guide are valid for Active Directory Rights Management Services 2008 and earlier. +::: +<% } %> + +The ${service} [Single Sign-on (SSO)](/sso) Integration lets you create a client application that uses Auth0 for authentication and provides SSO capabilities. Your users log in to ${service} with Auth0 [identity providers](/identityproviders), which means they perform the identity credentials verification. + +## Create an SSO Integration + +To create a new SSO Integration, navigate to [Dashboard > SSO Integrations](https://manage.auth0.com/#/externalapps) and click **+ Create SSO Integration**. + +![](/media/articles/sso/integrations/new.png) + +Next, select a provider. + +![](/media/articles/sso/integrations/options.png) + +Set the name for your SSO Integration. Click **Create**. + +![](/media/articles/sso/integrations/name.png) + +You will be brought to the **Tutorial** page for the provider, which contains instructions on how you can complete the integration with the external services provider so that it works with Auth0 for authentication. + +![](/media/articles/sso/integrations/${img}.png) + +Once you're done configuring your integration, note that there are two additional tabs with additional options for you to manage: + +1. **Settings**, which will allow you to change the integration's settings +2. **Connections**, which will allow you to enable/disable the integration for the connections associated with your tenant + +### Settings + +On the **Settings** page, configure the following values: + + + + + + + + + + + + + + <% if (service === "Active Directory RMS") { %> + + + + + <% } %> + <% if (service === "EchoSign") { %> + + + + + <% } %> + <% if (service === "Egnyte") { %> + + + + + <% } %> + <% if (service === "New Relic") { %> + + + + + <% } %> + <% if (service === "Microsoft Dynamics CRM") { %> + + + + + + + + + <% } %> + <% if (service === "Office 365") { %> + + + + + + + + + <% } %> + <% if (service === "Sentry") { %> + + + + + + + + + <% } %> + <% if (service === "Slack") { %> + + + + + <% } %> + <% if (service === "Salesforce") { %> + + + + + + + + + <% } %> + <% if (service === "SharePoint") { %> + + + + + + + + + <% } %> + <% if (service === "SpringCM") { %> + + + + + <% } %> + <% if (service === "Zendesk") { %> + + + + + <% } %> + <% if (service === "Zoom") { %> + + + + + <% } %> + + + + + +
SettingDescription
NameThe name for your SSO integration (if you would like to change the value you provided when you first set up the integration).
Rights Management Services URLThe URL of your Active Directory Rights Management Server.
EchoSign Custom DomainThe domain of your EchoSign URL ( https://{domain}.echosign.com).
Egnyte DomainThe domain of your Egnyte URL ( https://{domain}.egnyte.com).
New Relic Account NumberYour account number for New Relic, can be found in the url after the /account/ path.
Server URLThe URL for your Microsoft Dynamics CRM server.
X.509 Encryption CertificateThe certificate (DER encoded binary X.509) used to encrypt tokens sent to Microsoft Dynamics CRM by Auth0.
DomainYour Office 365 domain.
Auth0 ConnectionThe connection to use with this integration, typically an Active Directory connection.
Organization SlugThe generated slug for your Sentry organization found in your URL (i.e., the slug for `https://sentry.acme.com/acme-org/` would `acme-org`.
Sentry URL PrefixYour URL prefix if you're using Sentry Community Edition; otherwise, leave blank.
Team NameThe name of your Slack team.
Salesforce DomainYour Salesforce Domain.
Entity IDThe arbitrary URL that identifies the Saleforce resource.
SharePoint URLThe internal URL for the SharePoint application.
External URLs (optional)A comma-separated list of URLs, only required if the SharePoint application is exposed to the internet.
SpringCM ACS URLThe ACS URL for your SpringCM.
Zendesk Account NameYour Zendesk account name.
Zoom Account NameYour Zoom account name.
Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of ${service}.
+ +Click **Save**. + +### Enable Connections + +<% if (service === "Zendesk") { %> +::: warning +Zendesk **requires** that all users have an email address. When enabling Enterprise or Social connections, make sure that they will provide an email address +that can be sent to Zendesk. +::: + +<% } %> +The **Connections** tab features a list of user sources available to your tenant. Your connections are organized by type (e.g., Database, Social, Enterprise, Passwordless). + +You can choose the connections that you want used with your newly-created SSO integration; this allows the users in those connections to log in to ${service}. + +## Complete Set Up + +Once you've followed the configuration instructions in the tutorial, modified your settings (if necessary), and enabled your connection(s), you're done with setting up an SSO integration between ${service} and Auth0. diff --git a/fr-ca/articles/integrations/sso/ad-rms.md b/fr-ca/articles/integrations/sso/ad-rms.md new file mode 100644 index 0000000000..c54065deb4 --- /dev/null +++ b/fr-ca/articles/integrations/sso/ad-rms.md @@ -0,0 +1,21 @@ +--- +title: Active Directory RMS Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Active Directory RMS and Auth0. +toc: true +public: true +topics: + - sso + - microsoft + - active-directory-rms + - windows +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/ad-rms/0') %> +<%= include('../../../snippets/sso-integrations/ad-rms/1') %> +<%= include('../../../snippets/sso-integrations/ad-rms/2') %> +<%= include('../../../snippets/sso-integrations/ad-rms/3') %> +<%= include('../../../snippets/sso-integrations/ad-rms/4') %> +<%= include('../../../snippets/sso-integrations/ad-rms/5') %> +<%= include('../../../snippets/sso-integrations/ad-rms/6') %> +<%= include('../../../snippets/sso-integrations/ad-rms/7') %> diff --git a/fr-ca/articles/integrations/sso/adobe-sign.md b/fr-ca/articles/integrations/sso/adobe-sign.md new file mode 100644 index 0000000000..ade392a1f9 --- /dev/null +++ b/fr-ca/articles/integrations/sso/adobe-sign.md @@ -0,0 +1,21 @@ +--- +title: Adobe Sign Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Adobe Sign and Auth0. +toc: true +public: true +topics: + - sso + - adobe + - sign + - echosign +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/adobe-sign/0') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/1') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/2') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/3') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/4') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/5') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/6') %> +<%= include('../../../snippets/sso-integrations/adobe-sign/7') %> diff --git a/fr-ca/articles/integrations/sso/box.md b/fr-ca/articles/integrations/sso/box.md new file mode 100644 index 0000000000..808a65ec41 --- /dev/null +++ b/fr-ca/articles/integrations/sso/box.md @@ -0,0 +1,19 @@ +--- +title: Box Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Box and Auth0. +toc: true +public: true +topics: + - sso + - box +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/box/0') %> +<%= include('../../../snippets/sso-integrations/box/1') %> +<%= include('../../../snippets/sso-integrations/box/2') %> +<%= include('../../../snippets/sso-integrations/box/3') %> +<%= include('../../../snippets/sso-integrations/box/4') %> +<%= include('../../../snippets/sso-integrations/box/5') %> +<%= include('../../../snippets/sso-integrations/box/6') %> +<%= include('../../../snippets/sso-integrations/box/7') %> \ No newline at end of file diff --git a/fr-ca/articles/integrations/sso/cisco-webex.md b/fr-ca/articles/integrations/sso/cisco-webex.md new file mode 100644 index 0000000000..2619fcdd71 --- /dev/null +++ b/fr-ca/articles/integrations/sso/cisco-webex.md @@ -0,0 +1,19 @@ +--- +title: Cisco WebEx Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Cisco WebEx and Auth0. +toc: true +public: true +topics: + - sso + - cisco-webex +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/cisco-webex/0') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/1') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/2') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/3') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/4') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/5') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/6') %> +<%= include('../../../snippets/sso-integrations/cisco-webex/7') %> diff --git a/fr-ca/articles/integrations/sso/cloudbees.md b/fr-ca/articles/integrations/sso/cloudbees.md new file mode 100644 index 0000000000..912c641323 --- /dev/null +++ b/fr-ca/articles/integrations/sso/cloudbees.md @@ -0,0 +1,19 @@ +--- +title: CloudBees Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with CloudBees and Auth0. +toc: true +public: true +topics: + - sso + - cloudbees +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/cloudbees/0') %> +<%= include('../../../snippets/sso-integrations/cloudbees/1') %> +<%= include('../../../snippets/sso-integrations/cloudbees/2') %> +<%= include('../../../snippets/sso-integrations/cloudbees/3') %> +<%= include('../../../snippets/sso-integrations/cloudbees/4') %> +<%= include('../../../snippets/sso-integrations/cloudbees/5') %> +<%= include('../../../snippets/sso-integrations/cloudbees/6') %> +<%= include('../../../snippets/sso-integrations/cloudbees/7') %> diff --git a/fr-ca/articles/integrations/sso/concur.md b/fr-ca/articles/integrations/sso/concur.md new file mode 100644 index 0000000000..96a7527cca --- /dev/null +++ b/fr-ca/articles/integrations/sso/concur.md @@ -0,0 +1,19 @@ +--- +title: Concur Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Concur and Auth0. +toc: true +public: true +topics: + - sso + - concur +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/concur/0') %> +<%= include('../../../snippets/sso-integrations/concur/1') %> +<%= include('../../../snippets/sso-integrations/concur/2') %> +<%= include('../../../snippets/sso-integrations/concur/3') %> +<%= include('../../../snippets/sso-integrations/concur/4') %> +<%= include('../../../snippets/sso-integrations/concur/5') %> +<%= include('../../../snippets/sso-integrations/concur/6') %> +<%= include('../../../snippets/sso-integrations/concur/7') %> diff --git a/fr-ca/articles/integrations/sso/datadog.md b/fr-ca/articles/integrations/sso/datadog.md new file mode 100644 index 0000000000..3cf7f55a83 --- /dev/null +++ b/fr-ca/articles/integrations/sso/datadog.md @@ -0,0 +1,19 @@ +--- +title: Datadog Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Datadog and Auth0. +toc: true +public: true +topics: + - sso + - dropxbox +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/datadog/0') %> +<%= include('../../../snippets/sso-integrations/datadog/1') %> +<%= include('../../../snippets/sso-integrations/datadog/2') %> +<%= include('../../../snippets/sso-integrations/datadog/3') %> +<%= include('../../../snippets/sso-integrations/datadog/4') %> +<%= include('../../../snippets/sso-integrations/datadog/5') %> +<%= include('../../../snippets/sso-integrations/datadog/6') %> +<%= include('../../../snippets/sso-integrations/datadog/7') %> diff --git a/fr-ca/articles/integrations/sso/disqus.md b/fr-ca/articles/integrations/sso/disqus.md new file mode 100644 index 0000000000..def0e7328a --- /dev/null +++ b/fr-ca/articles/integrations/sso/disqus.md @@ -0,0 +1,169 @@ +--- +title: Disqus Single Sign-On Integration +description: Learn how to set up Single Sign-on (SSO) integration with Disqus and Auth0. +toc: true +public: false +topics: + - sso + - disqus +contentType: how-to +useCase: integrate-saas-sso +--- + +# Disqus Single Sign-On Integration + +Disqus allows you to embed a discussion section onto your site where your users can enter comments and interact with you and your other visitors. By implementing a Single Sign-on (SSO) integration between Disqus and Auth0, users that have signed in and authenticated via Auth0 can leave comments as themselves in your Disqus discussion section. + +## Install and Configure Disqus + +1. If you don't already have an account with Disqus, create one. If you do, log in. +2. Select the **I want to install Disqus on my site** box. + + ![](/media/articles/integrations/disqus/disqus-on-site.png) + +3. You will be directed to the *Create a new site* page. Provide your **Website Name** and your website's **Category**. When you've provided the requested information, click **Create Site** to continue. + + ::: note + You **Website Name** will become your unique Disqus URL. Make note of this URL, since it is required to configure your Auth0 Application. + ::: + + ![](/media/articles/integrations/disqus/create-new-site.png) + +4. Select your site's platform to receive customized instructions on installing Disqus and embedding its UI onto your site. If the platform you're using isn't listed, select **I don't see my platform, install manually with Universal Code** at the bottom of the page. + + ![](/media/articles/integrations/disqus/platforms.png) + + When you have finished the installation process, click **Configure** to move on to the next step. + +5. Configure your Disqus installation by providing the requested information about your website. When done (or if you want to complete this at a later time using the *Settings* page), click **Complete Setup**. + +## Enable and Configure Single Sign-on with Disqus + +Once you have installed and configured your Disqus instance, you need to enable SSO. + +::: warning +A Disqus Pro level subscription is required to use the [Disqus Single Sign-on (SSO) add-on](https://help.disqus.com/customer/portal/articles/236206-integrating-single-sign-on). +::: + +1. Navigate to the [Applications section of the Disqus API](https://disqus.com/api/applications/) to register your application. + + ![](/media/articles/integrations/disqus/register-api-app.png) + +2. Provide the requested details about your application. When complete, click **Register my application**. + + ![](/media/articles/integrations/disqus/register.png) + +3. You will now see your Auth0 application listed in the Disqus Applications panel. + + ![](/media/articles/integrations/disqus/register-api-app.png) + +4. Click on the [Single Sign-On](https://disqus.com/api/sso/) tab to go to the SSO management area where you will configure your remote domain and test the payload you create. Provide the following for your integration: + + * **Name**: the name used to identify your domain + * **Slug**: the prefixed value for your account + + **Notes**: + + * Refrain from using any non-alphanumeric characters to prevent conflicts from happening. * The name assigned to your remote domain is permanent and non-transferable. + * You can have only one remote domain per user account, and you should use a single remote domain per site (created using the moderator account). + + Click **Save Changes** when you're done. + + ![](/media/articles/integrations/disqus/sso-config.png) + +5. Return to the *Settings* page of the *Applications* tab. +6. Scroll to the *Settings* section and provide the following information: + + * **Domains**: the domain(s) of the site in which you've embedded Disqus; + * **SSO Domain**: the Disqus account for which you have SSO enabled. + + Under the *Authentication* section, provide the following information: + + * **Default Access**: Set to *Read and Write*. + + ![](/media/articles/integrations/disqus/disqus-app-settings.png) + + When done, click **Save Changes**. + +6. At this point, SSO is fully configured for your Disqus account. You will now need to [finish configuring the integration](https://help.disqus.com/customer/portal/articles/236206-single-sign-on) from the Auth0 side. + + ![](/media/articles/integrations/disqus/sso-config.png) + +## Integrate Disqus with Auth0 + +At this point, you will embed code onto your site that will generate a secured message that is passed to Disqus. + +When you are signed in to Auth0, you have user information including (but not limited to): + +* `user_id`; +* `username`; +* `displayName`. + +You can host [server-side code](https://github.com/disqus/DISQUS-API-Recipes/tree/master/sso) that generates the secure authentication message to pass the user's data to Disqus. This message contains three parts, each of which is separated with a single whitespace character: + +* The message body in a JSON-serialized form; +* The HMA-SHA1 signature; +* The timestamp of the message. + +You can host this code server-side as a Node service that's protected by Auth0 so that only authorized entities can access it. + +```js +var JSON = require('json3'); +var CryptoJS = require("crypto-js"); +var DISQUS_SECRET = "disqus_secret"; +var DISQUS_PUBLIC = "disqus_public"; +var data = disqusSignon(); + + +function disqusSignon() { + var disqusData = { + id: "auth0|577d19a858dd4da46509080'", + username: "test1234@gmail.com", + email: "test1234@gmail.com" + }; + + var disqusStr = JSON.stringify(disqusData); + + var timestamp = Math.round(+new Date() / 1000); + + var message = new Buffer(disqusStr).toString('base64'); + + /* + * CryptoJS (included in the directory) is required for hashing + * https://code.google.com/p/crypto-js/ + */ + + var result = CryptoJS.HmacSHA1(message + " " + timestamp, DISQUS_SECRET); + var hexsig = CryptoJS.enc.Hex.stringify(result); + + return { + pubKey: DISQUS_PUBLIC, + auth: message + " " + hexsig + " " + timestamp + }; +} +``` + +To complete the integration and pass the authentication data to Disqus, you'll need to add user-related entries to the `disqus_config` variable in your app's code. + +```js +var disqus_config = function() { + // Replace PAGE_URL with your page's canonical URL variable + this.page.url = 'http://PAGE_URL.disqus.com'; + this.page.identifier = '1234567'; + this.page.title = 'Landing Page' + + //Call the Node.js service to get auth data for user + + /* + var user = { + pubKey : 'PUBLIC_KEY', + auth : message + " " + hexsig + " " + timestamp + } + */ + + this.page.remote_auth_s3 = user.auth; + this.page.api_key = user.pubKey; +}; +``` + +At this point, you will see the option to SSO using Disqus when authenticating in to your app. diff --git a/fr-ca/articles/integrations/sso/dropbox.md b/fr-ca/articles/integrations/sso/dropbox.md new file mode 100644 index 0000000000..8e4f2b3105 --- /dev/null +++ b/fr-ca/articles/integrations/sso/dropbox.md @@ -0,0 +1,19 @@ +--- +title: Dropbox Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Dropbox and Auth0. +toc: true +public: true +topics: + - sso + - dropxbox +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/dropbox/0') %> +<%= include('../../../snippets/sso-integrations/dropbox/1') %> +<%= include('../../../snippets/sso-integrations/dropbox/2') %> +<%= include('../../../snippets/sso-integrations/dropbox/3') %> +<%= include('../../../snippets/sso-integrations/dropbox/4') %> +<%= include('../../../snippets/sso-integrations/dropbox/5') %> +<%= include('../../../snippets/sso-integrations/dropbox/6') %> +<%= include('../../../snippets/sso-integrations/dropbox/7') %> diff --git a/fr-ca/articles/integrations/sso/dynamics-crm.md b/fr-ca/articles/integrations/sso/dynamics-crm.md new file mode 100644 index 0000000000..70382fd3bc --- /dev/null +++ b/fr-ca/articles/integrations/sso/dynamics-crm.md @@ -0,0 +1,20 @@ +--- +title: Microsoft Dynamics CRM Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Microsoft Dynamics CRM and Auth0. +toc: true +public: true +topics: + - sso + - microsoft + - dynamics-crm +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/dynamics-crm/0') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/1') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/2') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/3') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/4') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/5') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/6') %> +<%= include('../../../snippets/sso-integrations/dynamics-crm/7') %> diff --git a/fr-ca/articles/integrations/sso/egencia.md b/fr-ca/articles/integrations/sso/egencia.md new file mode 100644 index 0000000000..032d4f2031 --- /dev/null +++ b/fr-ca/articles/integrations/sso/egencia.md @@ -0,0 +1,19 @@ +--- +title: Egencia Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Egencia and Auth0. +toc: true +public: true +topics: + - sso + - egencia +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/egencia/0') %> +<%= include('../../../snippets/sso-integrations/egencia/1') %> +<%= include('../../../snippets/sso-integrations/egencia/2') %> +<%= include('../../../snippets/sso-integrations/egencia/3') %> +<%= include('../../../snippets/sso-integrations/egencia/4') %> +<%= include('../../../snippets/sso-integrations/egencia/5') %> +<%= include('../../../snippets/sso-integrations/egencia/6') %> +<%= include('../../../snippets/sso-integrations/egencia/7') %> diff --git a/fr-ca/articles/integrations/sso/egnyte.md b/fr-ca/articles/integrations/sso/egnyte.md new file mode 100644 index 0000000000..fd5395bcac --- /dev/null +++ b/fr-ca/articles/integrations/sso/egnyte.md @@ -0,0 +1,19 @@ +--- +title: Egnyte Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Egnyte and Auth0. +toc: true +public: true +topics: + - sso + - egnyte +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/egnyte/0') %> +<%= include('../../../snippets/sso-integrations/egnyte/1') %> +<%= include('../../../snippets/sso-integrations/egnyte/2') %> +<%= include('../../../snippets/sso-integrations/egnyte/3') %> +<%= include('../../../snippets/sso-integrations/egnyte/4') %> +<%= include('../../../snippets/sso-integrations/egnyte/5') %> +<%= include('../../../snippets/sso-integrations/egnyte/6') %> +<%= include('../../../snippets/sso-integrations/egnyte/7') %> diff --git a/fr-ca/articles/integrations/sso/eloqua.md b/fr-ca/articles/integrations/sso/eloqua.md new file mode 100644 index 0000000000..3c1fe2c7e2 --- /dev/null +++ b/fr-ca/articles/integrations/sso/eloqua.md @@ -0,0 +1,19 @@ +--- +title: Eloqua Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Eloqua and Auth0. +toc: true +public: true +topics: + - sso + - eloqua +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/eloqua/0') %> +<%= include('../../../snippets/sso-integrations/eloqua/1') %> +<%= include('../../../snippets/sso-integrations/eloqua/2') %> +<%= include('../../../snippets/sso-integrations/eloqua/3') %> +<%= include('../../../snippets/sso-integrations/eloqua/4') %> +<%= include('../../../snippets/sso-integrations/eloqua/5') %> +<%= include('../../../snippets/sso-integrations/eloqua/6') %> +<%= include('../../../snippets/sso-integrations/eloqua/7') %> diff --git a/fr-ca/articles/integrations/sso/freshdesk.md b/fr-ca/articles/integrations/sso/freshdesk.md new file mode 100644 index 0000000000..46018221fe --- /dev/null +++ b/fr-ca/articles/integrations/sso/freshdesk.md @@ -0,0 +1,19 @@ +--- +title: Freshdesk Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Freshdesk and Auth0. +toc: true +public: true +topics: + - sso + - freshdesk +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/freshdesk/0') %> +<%= include('../../../snippets/sso-integrations/freshdesk/1') %> +<%= include('../../../snippets/sso-integrations/freshdesk/2') %> +<%= include('../../../snippets/sso-integrations/freshdesk/3') %> +<%= include('../../../snippets/sso-integrations/freshdesk/4') %> +<%= include('../../../snippets/sso-integrations/freshdesk/5') %> +<%= include('../../../snippets/sso-integrations/freshdesk/6') %> +<%= include('../../../snippets/sso-integrations/freshdesk/7') %> diff --git a/fr-ca/articles/integrations/sso/github-enterprise-cloud.md b/fr-ca/articles/integrations/sso/github-enterprise-cloud.md new file mode 100644 index 0000000000..8ad8b8220d --- /dev/null +++ b/fr-ca/articles/integrations/sso/github-enterprise-cloud.md @@ -0,0 +1,19 @@ +--- +title: GitHub Enterprise Cloud Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with GitHub Enterprise Cloud and Auth0. +toc: true +public: true +topics: + - sso + - github-enterprise-cloud +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/0') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/1') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/2') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/3') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/4') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/5') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/6') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/7') %> diff --git a/fr-ca/articles/integrations/sso/github-enterprise-server.md b/fr-ca/articles/integrations/sso/github-enterprise-server.md new file mode 100644 index 0000000000..3a49e22ce5 --- /dev/null +++ b/fr-ca/articles/integrations/sso/github-enterprise-server.md @@ -0,0 +1,19 @@ +--- +title: GitHub Enterprise Server Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with GitHub Enterprise Server and Auth0. +toc: true +public: true +topics: + - sso + - github-enterprise-server +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/github-enterprise-server/0') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/1') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/2') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/3') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/4') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/5') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/6') %> +<%= include('../../../snippets/sso-integrations/github-enterprise-server/7') %> diff --git a/fr-ca/articles/integrations/sso/google-workspace.md b/fr-ca/articles/integrations/sso/google-workspace.md new file mode 100644 index 0000000000..b9abad69f3 --- /dev/null +++ b/fr-ca/articles/integrations/sso/google-workspace.md @@ -0,0 +1,19 @@ +--- +title: Google Workspace Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Google Workspace and Auth0. +toc: true +public: true +topics: + - sso + - Google Workspace +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/google-workspace/0') %> +<%= include('../../../snippets/sso-integrations/google-workspace/1') %> +<%= include('../../../snippets/sso-integrations/google-workspace/2') %> +<%= include('../../../snippets/sso-integrations/google-workspace/3') %> +<%= include('../../../snippets/sso-integrations/google-workspace/4') %> +<%= include('../../../snippets/sso-integrations/google-workspace/5') %> +<%= include('../../../snippets/sso-integrations/google-workspace/6') %> +<%= include('../../../snippets/sso-integrations/google-workspace/7') %> diff --git a/fr-ca/articles/integrations/sso/heroku.md b/fr-ca/articles/integrations/sso/heroku.md new file mode 100644 index 0000000000..9ad96804fb --- /dev/null +++ b/fr-ca/articles/integrations/sso/heroku.md @@ -0,0 +1,19 @@ +--- +title: Heroku Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Heroku and Auth0. +toc: true +public: true +topics: + - sso + - heroku +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/heroku/0') %> +<%= include('../../../snippets/sso-integrations/heroku/1') %> +<%= include('../../../snippets/sso-integrations/heroku/2') %> +<%= include('../../../snippets/sso-integrations/heroku/3') %> +<%= include('../../../snippets/sso-integrations/heroku/4') %> +<%= include('../../../snippets/sso-integrations/heroku/5') %> +<%= include('../../../snippets/sso-integrations/heroku/6') %> +<%= include('../../../snippets/sso-integrations/heroku/7') %> diff --git a/fr-ca/articles/integrations/sso/hosted-graphite.md b/fr-ca/articles/integrations/sso/hosted-graphite.md new file mode 100644 index 0000000000..e72168fcc7 --- /dev/null +++ b/fr-ca/articles/integrations/sso/hosted-graphite.md @@ -0,0 +1,19 @@ +--- +title: Hosted Graphite Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Hosted Graphite and Auth0. +toc: true +public: true +topics: + - sso + - hosted-graphite +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/hosted-graphite/0') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/1') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/2') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/3') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/4') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/5') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/6') %> +<%= include('../../../snippets/sso-integrations/hosted-graphite/7') %> diff --git a/fr-ca/articles/integrations/sso/index.md b/fr-ca/articles/integrations/sso/index.md new file mode 100644 index 0000000000..afe2efda39 --- /dev/null +++ b/fr-ca/articles/integrations/sso/index.md @@ -0,0 +1,48 @@ +--- +title: Single Sign-On Integrations +description: Learn about Auth0 Single Sign-on (SSO) Integrations. +topics: + - sso +contentType: + - index +useCase: integrate-saas-sso +--- +# Single Sign-On Integrations + +Single Sign-on (SSO) Integrations are client applications that enable the use of external services (e.g., Dropbox, Slack, or Zoom) for SSO. The integration allows your users to log in using Auth0's [identity providers](/identityproviders). + +Auth0 provides SSO Integrations for the following services: + +- [Active Directory RMS](/integrations/sso/ad-rms) +- [Adobe Sign](/integrations/sso/adobe-sign) +- [Box](/integrations/sso/box) +- [Cisco WebEx](/integrations/sso/cisco-webex) +- [CloudBees](/integrations/sso/cloudbees) +- [Concur](/integrations/sso/concur) +- [Datadog](/integrations/sso/datadog) +- [Dropbox](/integrations/sso/dropbox) +- [Dynamics CRM](/integrations/sso/dynamics-crm) +- [Egencia](/integrations/sso/egencia) +- [Egnyte](/integrations/sso/egnyte) +- [Eloqua](/integrations/sso/eloqua) +- [Freshdesk](/integrations/sso/freshdesk) +- [Google Workspace](/integrations/sso/google-workspace) +- [GitHub Enterprise Cloud](/integrations/sso/github-enterprise-cloud) +- [GitHub Enterprise Server](/integrations/sso/github-enterprise-server) +- [Heroku](/integrations/sso/heroku) +- [Hosted Graphite](/integrations/sso/hosted-graphite) +- [Litmos](/integrations/sso/litmos) +- [New Relic](/integrations/sso/new-relic) +- [Office 365](/integrations/sso/office-365) +- [Pluralsight](/integrations/sso/pluralsight) +- [Salesforce](/integrations/sso/salesforce) +- [Sentry](/integrations/sso/sentry) +- [Slack](/integrations/sso/slack) +- [SpringCM](/integrations/sso/springcm) +- [Sprout Video](/integrations/sso/sprout-video) +- [Tableau Online](/integrations/sso/tableau-online) +- [Tableau Server](/integrations/sso/tableau-server) +- [Workday](/integrations/sso/workday) +- [Workpath](/integrations/sso/workpath) +- [Zendesk](/integrations/sso/zendesk) +- [Zoom](/integrations/sso/zoom) diff --git a/fr-ca/articles/integrations/sso/litmos.md b/fr-ca/articles/integrations/sso/litmos.md new file mode 100644 index 0000000000..d29d7ccc42 --- /dev/null +++ b/fr-ca/articles/integrations/sso/litmos.md @@ -0,0 +1,19 @@ +--- +title: Litmos Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Litmos and Auth0. +toc: true +public: true +topics: + - sso + - litmos +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/litmos/0') %> +<%= include('../../../snippets/sso-integrations/litmos/1') %> +<%= include('../../../snippets/sso-integrations/litmos/2') %> +<%= include('../../../snippets/sso-integrations/litmos/3') %> +<%= include('../../../snippets/sso-integrations/litmos/4') %> +<%= include('../../../snippets/sso-integrations/litmos/5') %> +<%= include('../../../snippets/sso-integrations/litmos/6') %> +<%= include('../../../snippets/sso-integrations/litmos/7') %> diff --git a/fr-ca/articles/integrations/sso/new-relic.md b/fr-ca/articles/integrations/sso/new-relic.md new file mode 100644 index 0000000000..68fbf8906b --- /dev/null +++ b/fr-ca/articles/integrations/sso/new-relic.md @@ -0,0 +1,20 @@ +--- +title: New Relic Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with New Relic and Auth0. +toc: true +public: true +topics: + - sso + - new-relic +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/new-relic/0') %> +<%= include('../../../snippets/sso-integrations/new-relic/1') %> +<%= include('../../../snippets/sso-integrations/new-relic/2') %> +<%= include('../../../snippets/sso-integrations/new-relic/3') %> +<%= include('../../../snippets/sso-integrations/new-relic/4') %> +<%= include('../../../snippets/sso-integrations/new-relic/5') %> +<%= include('../../../snippets/sso-integrations/new-relic/6') %> +<%= include('../../../snippets/sso-integrations/new-relic/7') %> + diff --git a/fr-ca/articles/integrations/sso/office-365.md b/fr-ca/articles/integrations/sso/office-365.md new file mode 100644 index 0000000000..155d016fdd --- /dev/null +++ b/fr-ca/articles/integrations/sso/office-365.md @@ -0,0 +1,19 @@ +--- +title: Office 365 Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Office 365 and Auth0. +toc: true +public: true +topics: + - sso + - office-365 +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/office-365/0') %> +<%= include('../../../snippets/sso-integrations/office-365/1') %> +<%= include('../../../snippets/sso-integrations/office-365/2') %> +<%= include('../../../snippets/sso-integrations/office-365/3') %> +<%= include('../../../snippets/sso-integrations/office-365/4') %> +<%= include('../../../snippets/sso-integrations/office-365/5') %> +<%= include('../../../snippets/sso-integrations/office-365/6') %> +<%= include('../../../snippets/sso-integrations/office-365/7') %> diff --git a/fr-ca/articles/integrations/sso/pluralsight.md b/fr-ca/articles/integrations/sso/pluralsight.md new file mode 100644 index 0000000000..48c55cfa21 --- /dev/null +++ b/fr-ca/articles/integrations/sso/pluralsight.md @@ -0,0 +1,19 @@ +--- +title: Pluralsight Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Pluralsight and Auth0. +toc: true +public: true +topics: + - sso + - dropxbox +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/pluralsight/0') %> +<%= include('../../../snippets/sso-integrations/pluralsight/1') %> +<%= include('../../../snippets/sso-integrations/pluralsight/2') %> +<%= include('../../../snippets/sso-integrations/pluralsight/3') %> +<%= include('../../../snippets/sso-integrations/pluralsight/4') %> +<%= include('../../../snippets/sso-integrations/pluralsight/5') %> +<%= include('../../../snippets/sso-integrations/pluralsight/6') %> +<%= include('../../../snippets/sso-integrations/pluralsight/7') %> diff --git a/fr-ca/articles/integrations/sso/salesforce.md b/fr-ca/articles/integrations/sso/salesforce.md new file mode 100644 index 0000000000..2946044f0f --- /dev/null +++ b/fr-ca/articles/integrations/sso/salesforce.md @@ -0,0 +1,19 @@ +--- +title: Salesforce Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Salesforce and Auth0. +toc: true +public: true +topics: + - sso + - salesforce +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/salesforce/0') %> +<%= include('../../../snippets/sso-integrations/salesforce/1') %> +<%= include('../../../snippets/sso-integrations/salesforce/2') %> +<%= include('../../../snippets/sso-integrations/salesforce/3') %> +<%= include('../../../snippets/sso-integrations/salesforce/4') %> +<%= include('../../../snippets/sso-integrations/salesforce/5') %> +<%= include('../../../snippets/sso-integrations/salesforce/6') %> +<%= include('../../../snippets/sso-integrations/salesforce/7') %> diff --git a/fr-ca/articles/integrations/sso/sentry.md b/fr-ca/articles/integrations/sso/sentry.md new file mode 100644 index 0000000000..5bf371deb2 --- /dev/null +++ b/fr-ca/articles/integrations/sso/sentry.md @@ -0,0 +1,19 @@ +--- +title: Sentry Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Sentry and Auth0. +toc: true +public: true +topics: + - sso + - sentry +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/sentry/0') %> +<%= include('../../../snippets/sso-integrations/sentry/1') %> +<%= include('../../../snippets/sso-integrations/sentry/2') %> +<%= include('../../../snippets/sso-integrations/sentry/3') %> +<%= include('../../../snippets/sso-integrations/sentry/4') %> +<%= include('../../../snippets/sso-integrations/sentry/5') %> +<%= include('../../../snippets/sso-integrations/sentry/6') %> +<%= include('../../../snippets/sso-integrations/sentry/7') %> diff --git a/fr-ca/articles/integrations/sso/sharepoint.md b/fr-ca/articles/integrations/sso/sharepoint.md new file mode 100644 index 0000000000..8fde6b36df --- /dev/null +++ b/fr-ca/articles/integrations/sso/sharepoint.md @@ -0,0 +1,19 @@ +--- +title: SharePoint Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with SharePoint and Auth0. +toc: true +public: false +topics: + - sso + - sharepoint +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/sharepoint/0') %> +<%= include('../../../snippets/sso-integrations/sharepoint/1') %> +<%= include('../../../snippets/sso-integrations/sharepoint/2') %> +<%= include('../../../snippets/sso-integrations/sharepoint/3') %> +<%= include('../../../snippets/sso-integrations/sharepoint/4') %> +<%= include('../../../snippets/sso-integrations/sharepoint/5') %> +<%= include('../../../snippets/sso-integrations/sharepoint/6') %> +<%= include('../../../snippets/sso-integrations/sharepoint/7') %> diff --git a/fr-ca/articles/integrations/sso/slack.md b/fr-ca/articles/integrations/sso/slack.md new file mode 100644 index 0000000000..7fff98bb76 --- /dev/null +++ b/fr-ca/articles/integrations/sso/slack.md @@ -0,0 +1,23 @@ +--- +title: Slack Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Slack and Auth0. +toc: true +public: true +topics: + - sso + - slack +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/slack/0') %> +<%= include('../../../snippets/sso-integrations/slack/1') %> +<%= include('../../../snippets/sso-integrations/slack/2') %> +<%= include('../../../snippets/sso-integrations/slack/3') %> +<%= include('../../../snippets/sso-integrations/slack/4') %> +<%= include('../../../snippets/sso-integrations/slack/5') %> +<%= include('../../../snippets/sso-integrations/slack/6') %> +<%= include('../../../snippets/sso-integrations/slack/7') %> + +::: note +For more information, check out Slack's article on [enabling SAML-based Single Sign-on (SSO)](https://get.slack.help/hc/en-us/articles/203772216-Enabling-SAML-based-single-sign-on). +::: diff --git a/fr-ca/articles/integrations/sso/springcm.md b/fr-ca/articles/integrations/sso/springcm.md new file mode 100644 index 0000000000..ca7ea7e521 --- /dev/null +++ b/fr-ca/articles/integrations/sso/springcm.md @@ -0,0 +1,19 @@ +--- +title: SpringCM Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with SpringCM and Auth0. +toc: true +public: true +topics: + - sso + - springcm +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/springcm/0') %> +<%= include('../../../snippets/sso-integrations/springcm/1') %> +<%= include('../../../snippets/sso-integrations/springcm/2') %> +<%= include('../../../snippets/sso-integrations/springcm/3') %> +<%= include('../../../snippets/sso-integrations/springcm/4') %> +<%= include('../../../snippets/sso-integrations/springcm/5') %> +<%= include('../../../snippets/sso-integrations/springcm/6') %> +<%= include('../../../snippets/sso-integrations/springcm/7') %> diff --git a/fr-ca/articles/integrations/sso/sprout-video.md b/fr-ca/articles/integrations/sso/sprout-video.md new file mode 100644 index 0000000000..9299a866ec --- /dev/null +++ b/fr-ca/articles/integrations/sso/sprout-video.md @@ -0,0 +1,19 @@ +--- +title: Sprout Video Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Sprout Video and Auth0. +toc: true +public: true +topics: + - sso + - sprout-video +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/sprout-video/0') %> +<%= include('../../../snippets/sso-integrations/sprout-video/1') %> +<%= include('../../../snippets/sso-integrations/sprout-video/2') %> +<%= include('../../../snippets/sso-integrations/sprout-video/3') %> +<%= include('../../../snippets/sso-integrations/sprout-video/4') %> +<%= include('../../../snippets/sso-integrations/sprout-video/5') %> +<%= include('../../../snippets/sso-integrations/sprout-video/6') %> +<%= include('../../../snippets/sso-integrations/sprout-video/7') %> diff --git a/fr-ca/articles/integrations/sso/tableau-online.md b/fr-ca/articles/integrations/sso/tableau-online.md new file mode 100644 index 0000000000..89848db4c2 --- /dev/null +++ b/fr-ca/articles/integrations/sso/tableau-online.md @@ -0,0 +1,19 @@ +--- +title: Tableau Online Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Tableau Online and Auth0. +toc: true +public: true +topics: + - sso + - tableau-online +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/tableau-online/0') %> +<%= include('../../../snippets/sso-integrations/tableau-online/1') %> +<%= include('../../../snippets/sso-integrations/tableau-online/2') %> +<%= include('../../../snippets/sso-integrations/tableau-online/3') %> +<%= include('../../../snippets/sso-integrations/tableau-online/4') %> +<%= include('../../../snippets/sso-integrations/tableau-online/5') %> +<%= include('../../../snippets/sso-integrations/tableau-online/6') %> +<%= include('../../../snippets/sso-integrations/tableau-online/7') %> diff --git a/fr-ca/articles/integrations/sso/tableau-server.md b/fr-ca/articles/integrations/sso/tableau-server.md new file mode 100644 index 0000000000..648e77c4ab --- /dev/null +++ b/fr-ca/articles/integrations/sso/tableau-server.md @@ -0,0 +1,19 @@ +--- +title: Tableau Server Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Tableau Server and Auth0. +toc: true +public: true +topics: + - sso + - tableau-server +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/tableau-server/0') %> +<%= include('../../../snippets/sso-integrations/tableau-server/1') %> +<%= include('../../../snippets/sso-integrations/tableau-server/2') %> +<%= include('../../../snippets/sso-integrations/tableau-server/3') %> +<%= include('../../../snippets/sso-integrations/tableau-server/4') %> +<%= include('../../../snippets/sso-integrations/tableau-server/5') %> +<%= include('../../../snippets/sso-integrations/tableau-server/6') %> +<%= include('../../../snippets/sso-integrations/tableau-server/7') %> diff --git a/fr-ca/articles/integrations/sso/workday.md b/fr-ca/articles/integrations/sso/workday.md new file mode 100644 index 0000000000..d77f02f586 --- /dev/null +++ b/fr-ca/articles/integrations/sso/workday.md @@ -0,0 +1,19 @@ +--- +title: Workday Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Workday and Auth0. +toc: true +public: true +topics: + - sso + - workday +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/workday/0') %> +<%= include('../../../snippets/sso-integrations/workday/1') %> +<%= include('../../../snippets/sso-integrations/workday/2') %> +<%= include('../../../snippets/sso-integrations/workday/3') %> +<%= include('../../../snippets/sso-integrations/workday/4') %> +<%= include('../../../snippets/sso-integrations/workday/5') %> +<%= include('../../../snippets/sso-integrations/workday/6') %> +<%= include('../../../snippets/sso-integrations/workday/7') %> diff --git a/fr-ca/articles/integrations/sso/workpath.md b/fr-ca/articles/integrations/sso/workpath.md new file mode 100644 index 0000000000..6857d56b43 --- /dev/null +++ b/fr-ca/articles/integrations/sso/workpath.md @@ -0,0 +1,19 @@ +--- +title: Workpath Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Workpath and Auth0. +toc: true +public: true +topics: + - sso + - workpath +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/workpath/0') %> +<%= include('../../../snippets/sso-integrations/workpath/1') %> +<%= include('../../../snippets/sso-integrations/workpath/2') %> +<%= include('../../../snippets/sso-integrations/workpath/3') %> +<%= include('../../../snippets/sso-integrations/workpath/4') %> +<%= include('../../../snippets/sso-integrations/workpath/5') %> +<%= include('../../../snippets/sso-integrations/workpath/6') %> +<%= include('../../../snippets/sso-integrations/workpath/7') %> diff --git a/fr-ca/articles/integrations/sso/zendesk.md b/fr-ca/articles/integrations/sso/zendesk.md new file mode 100644 index 0000000000..f4409ec17d --- /dev/null +++ b/fr-ca/articles/integrations/sso/zendesk.md @@ -0,0 +1,19 @@ +--- +title: Zendesk Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Zendesk and Auth0. +toc: true +public: true +topics: + - sso + - zendesk +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/zendesk/0') %> +<%= include('../../../snippets/sso-integrations/zendesk/1') %> +<%= include('../../../snippets/sso-integrations/zendesk/2') %> +<%= include('../../../snippets/sso-integrations/zendesk/3') %> +<%= include('../../../snippets/sso-integrations/zendesk/4') %> +<%= include('../../../snippets/sso-integrations/zendesk/5') %> +<%= include('../../../snippets/sso-integrations/zendesk/6') %> +<%= include('../../../snippets/sso-integrations/zendesk/7') %> diff --git a/fr-ca/articles/integrations/sso/zoom.md b/fr-ca/articles/integrations/sso/zoom.md new file mode 100644 index 0000000000..c987b3d838 --- /dev/null +++ b/fr-ca/articles/integrations/sso/zoom.md @@ -0,0 +1,19 @@ +--- +title: Zoom Single Sign-On Integration +description: Learn how to set up a Single Sign-on (SSO) integration with Zoom and Auth0. +toc: true +public: true +topics: + - sso + - zoom +contentType: how-to +useCase: integrate-saas-sso +--- +<%= include('../../../snippets/sso-integrations/zoom/0') %> +<%= include('../../../snippets/sso-integrations/zoom/1') %> +<%= include('../../../snippets/sso-integrations/zoom/2') %> +<%= include('../../../snippets/sso-integrations/zoom/3') %> +<%= include('../../../snippets/sso-integrations/zoom/4') %> +<%= include('../../../snippets/sso-integrations/zoom/5') %> +<%= include('../../../snippets/sso-integrations/zoom/6') %> +<%= include('../../../snippets/sso-integrations/zoom/7') %> diff --git a/fr-ca/articles/integrations/using-auth0-to-secure-a-cli.md b/fr-ca/articles/integrations/using-auth0-to-secure-a-cli.md new file mode 100644 index 0000000000..deacfe2ad6 --- /dev/null +++ b/fr-ca/articles/integrations/using-auth0-to-secure-a-cli.md @@ -0,0 +1,44 @@ +--- +title: Secure a CLI with Auth0 +description: How to use Auth0 to secure a CLI. +topics: + - integrations + - cli +contentType: how-to +useCase: + - integrate-saas-sso + - cli-authentication + - +--- + +# Secure a CLI with Auth0 + +There are three ways to secure a CLI with Auth0 in order of most secure to least secure: + +* [Device Authorization Flow](#device-authorization-flow) +* [Client Credentials Grant Flow](#client-credentials-grant-flow) +* [Resource Owner Password Grant Flow](#resource-owner-password-grant-flow) (not recommended) + +The first two options are for user-based authentication, whereas the third option is only when you're attempting to authenticate the CLI client itself, which is a very rare situation. + +## Device Authorization Flow + +With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device. This avoids a poor user experience for devices that do not have an easy way to enter text. To do this, device apps use the Device Authorization Flow (drafted in [OAuth 2.0](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15)), in which they pass along their Client ID to initiate the authorization process and get a token. + +The easiest way to implement the [Device Authorization Flow](/flows/concepts/device-auth) is to follow the steps in [Call API Using Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth). + +## Client Credentials Grant Flow + +Use the Client Credentials Grant (CCG) flow when users and downstream identity providers aren't involved and you want to authenticate based on distinct machines or devices. + +If your identity provider supports sending credentials, then you should use the [Client Credentials Flow](/flows/concepts/client-credentials). For details on how to implement this, refer to [Call API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials). + +## Resource Owner Password Grant Flow + +We do not recommend using the Resource Owner Password Grant (ROPG) flow for native applications. In the [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252) from the Internet Engineering Task Force (IETF), it is recommended that “OAuth 2.0 authorization request from native apps should ONLY be made through external user-agents, primarily the user’s browser”. For details, see [RFC 8252 Embedded User-Agents](https://tools.ietf.org/html/rfc8252#section-8.12). + +Using Resource Owner Password Grant (ROPG) are less secure than the redirect-based options described above. ROPG is only for legacy. In the context of CLIs, it only makes sense for things like connection strings where you need to support legacy programs. + +::: note +If you must use ROPG in your native app instead of Device Flow as we recommend, then you can use our [OIDC compliant ROPG endpoint](/api/authentication#resource-owner-password). +::: \ No newline at end of file diff --git a/fr-ca/articles/libraries/_includes/_change_get_profile.md b/fr-ca/articles/libraries/_includes/_change_get_profile.md new file mode 100644 index 0000000000..96838117ae --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_change_get_profile.md @@ -0,0 +1,5 @@ +### Change calls to getProfile() + +The deprecated `getProfile()` function was reimplemented in Lock 11. The previous implementation received an [ID Token](/tokens/concepts/id-tokens) as a parameter and returned the user profile. + +The new implementation requires an Access Token parameter instead. diff --git a/fr-ca/articles/libraries/_includes/_configure_custom_domain.md b/fr-ca/articles/libraries/_includes/_configure_custom_domain.md new file mode 100644 index 0000000000..5a98890df2 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_configure_custom_domain.md @@ -0,0 +1,29 @@ +### Configure your custom domain + +1. Ensure that your application updates are made prior to setting up custom domains in your application, as the older versions of ${library} will not work when configured with a custom domain. + +2. Set up your [custom domain](/custom-domains) in the Auth0 [Dashboard](${manage_url}/#/tenant). + +3. Use the custom domain when instantiating Lock. + +``` +var lock = new Auth0Lock('${account.clientId}', 'login.your-domain.com', options); +``` + +4. Set the `configurationBaseUrl` option to `https://cdn.us.auth0.com`. + +``` +var options = { + configurationBaseUrl: 'https://cdn.us.auth0.com' +}; +``` + +::: note +The CDN URL varies by region. Tenants created before 11 June 2020 should use `https://cdn.auth0.com` if the region is the United States, or add `eu` or `au` for Europe or Australia. If your tenant was created after 11 June 2020, use `https://cdn.us.auth0.com` if the region is the United States. +::: + +#### Management Application + +If you intend to use the Auth0.js `auth0.Management` to get user information or perform account linking operations, you will need to instantiate a new Auth0 object with the Auth0 domain rather than your custom domain. The Management API only accepts Auth0 domains. + +See the Auth0.js documentation on [user management](/libraries/auth0js/v9#user-management) for more information on using the Management API in Auth0.js. \ No newline at end of file diff --git a/fr-ca/articles/libraries/_includes/_configure_embedded_login.md b/fr-ca/articles/libraries/_includes/_configure_embedded_login.md new file mode 100644 index 0000000000..3585ca28f0 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_configure_embedded_login.md @@ -0,0 +1,7 @@ +### Configure your Auth0 application for embedded login + +When implementing embedded login, ${library} will use cross-origin calls inside hidden iframes to perform authentication. To make sure this can be done securely, Auth0 needs to know the domains where you will be hosting your applications. + +Add the domain to the **Allowed Web Origins** field. You can find this field in the [Application Settings](${manage_url}/#/application/${account.clientId}/settings) area of your Dashboard. + +![Allowed Web Origins](/media/articles/libraries/lock/allowed-origins.png) diff --git a/fr-ca/articles/libraries/_includes/_default_values.md b/fr-ca/articles/libraries/_includes/_default_values.md new file mode 100644 index 0000000000..48b1b9eff4 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_default_values.md @@ -0,0 +1,11 @@ +### Default values + +Auth0.js v9 will default the value of the scope parameter to `openid profile email`. + +If you are running your website from `http://localhost` or `http://127.0.0.1` and you do not specify the `openid profile email` scope when initializing auth0.js, calling the `getSSOData()` method will result in the following error in the browser console: + +```text +Consent required. When using `getSSOData`, the user has to be authenticated with the following scope: `openid profile email` +``` + +This will not happen when you run your application in production, or if you specify the required [scope](/scopes). You can read more about this scenario in the documentation on [skipping consent for first-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications). diff --git a/fr-ca/articles/libraries/_includes/_default_values_lock.md b/fr-ca/articles/libraries/_includes/_default_values_lock.md new file mode 100644 index 0000000000..b66229d099 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_default_values_lock.md @@ -0,0 +1,11 @@ +### Default values + +Lock 11 will default the scope parameter to `'openid profile email'`. This is to make the **Last time you logged in with** window work correctly. + +If you are running your website from `http://localhost` or `http://127.0.0.1` and you do not specify the `openid profile email` scope when initializing Lock, you may get the following error in the browser console: + +```text +Consent required. When using `getSSOData`, the user has to be authenticated with the following scope: `openid profile email` +``` + +This will not happen when you run your application in production, or if you specify the required [scope](/scopes). You can read more about this scenario in the documentation on [skipping consent for first-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications). diff --git a/fr-ca/articles/libraries/_includes/_embedded_sso.md b/fr-ca/articles/libraries/_includes/_embedded_sso.md new file mode 100644 index 0000000000..bd379358ae --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_embedded_sso.md @@ -0,0 +1,10 @@ +### Single Sign-On with embedded authentication + +Apps with embedded login must meet two criteria in order to have Single Sign-on (SSO). + +1. Both of the applications attempting SSO must be first-party applications. SSO with third-party applications will not work. +1. They need to make use of [custom domains](/custom-domains) and have both the applications which intend to have SSO as well as the Auth0 tenant on the same domain. Traditionally, Auth0 domains are in the format `foo.auth0.com`, but custom domains allow you to use the same domain for each of the applications in question as well as your Auth0 tenant, preventing the risk of CSRF attacks. + +::: note +Our recommendation is to use Universal Login instead of setting up SSO in embedded login scenarios. Universal Login is the most reliable and stable way to perform SSO, and is the only way to do so if you must use multiple domains for your applications, or use [third-party applications](/applications/guides/enable-third-party-apps). +::: diff --git a/fr-ca/articles/libraries/_includes/_get_auth0_js_latest_version.md b/fr-ca/articles/libraries/_includes/_get_auth0_js_latest_version.md new file mode 100644 index 0000000000..c372c1c25b --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_get_auth0_js_latest_version.md @@ -0,0 +1,23 @@ +### Update auth0.js + +Update the Auth0.js library using npm or yarn. + +```bash +# installation with npm +npm install --save auth0-js + +# installation with yarn +yarn add auth0-js +``` + +Once updated, you can add it to your build system or bring it in to your project with a script tag. + +```html + +``` + +If you do not want to use a package manager, you can retrieve Auth0.js from Auth0's CDN. + +```html + +``` diff --git a/fr-ca/articles/libraries/_includes/_get_lock_latest_version.md b/fr-ca/articles/libraries/_includes/_get_lock_latest_version.md new file mode 100644 index 0000000000..8f775a2240 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_get_lock_latest_version.md @@ -0,0 +1,23 @@ +### Update Lock + +Update the Lock library using npm or yarn. + +```bash +# installation with npm +npm install --save auth0-lock + +# installation with yarn +yarn add auth0-lock +``` + +Once updated, you can add it to your build system or bring it in to your project with a script tag. + +```html + +``` + +If you do not want to use a package manager, you can retrieve Lock from Auth0's CDN. + +```html + +``` diff --git a/fr-ca/articles/libraries/_includes/_ip_ranges.md b/fr-ca/articles/libraries/_includes/_ip_ranges.md new file mode 100644 index 0000000000..b3813c37ce --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_ip_ranges.md @@ -0,0 +1,7 @@ +### Single sign-on using IP ranges + +In earlier versions of Lock, you could configure an IP range in an Active Directory/LDAP connection. You could then use that range to allow integrated Windows Authentication if the user's IP was within the range. When this was true, Lock would display a button that users could click and get redirected to the integrated authentication dialog. + +![SSO With Lock 10 and Windows IP Ranges](/media/articles/libraries/lock/lock-11-windows-authentication.png) + +This functionality has been removed from embedded login using Lock 11. There is no IP detection, and the user will need to type user and password in Lock. It is still available when using Universal Login. diff --git a/fr-ca/articles/libraries/_includes/_last_logged_in_window.md b/fr-ca/articles/libraries/_includes/_last_logged_in_window.md new file mode 100644 index 0000000000..696166ebfb --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_last_logged_in_window.md @@ -0,0 +1,9 @@ +### Last time you logged in with window with authorization code flow + +Lock 11 will never show the **Last time you logged in with** window when using the [Authorization Code Flow](/flows/concepts/auth-code) (that is, when specifying `response_type='code'`). It will always prompt for credentials. + +### Last time you logged in with window and redirects + +The **Last time you logged in with** window will never do a redirect, even when the `redirect` option is set to `true`. Lock11 still emits the `authenticated` event and you should subscribe to that event to [get the authentication result](/libraries/lock/v11#2-authenticating-and-getting-user-info). + +If you want to avoid showing the Lock dialog when there's an existing session in the server, you can use Auth0.js's [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) function. diff --git a/fr-ca/articles/libraries/_includes/_legacy_flows.md b/fr-ca/articles/libraries/_includes/_legacy_flows.md new file mode 100644 index 0000000000..b6793b4966 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_legacy_flows.md @@ -0,0 +1,5 @@ +### Migrating from legacy authentication flows + +The OIDC conformant flows disallow certain practices that were common when developing applications with older versions of the library, like using Refresh Tokens, using [ID Tokens](/tokens/concepts/id-tokens) to call APIs, and [accessing non-standard claims in the user profile](/api-auth/tutorials/adoption/scope-custom-claims). + +Follow the steps in the [Migration from Legacy Authentication Flows](guides/migration-legacy-flows) to learn what changes you need to make in your application. diff --git a/fr-ca/articles/libraries/_includes/_migrate_universal.md b/fr-ca/articles/libraries/_includes/_migrate_universal.md new file mode 100644 index 0000000000..c43bcae9f8 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_migrate_universal.md @@ -0,0 +1,3 @@ +::: note +If you do not have the ability to use [custom domains](/custom-domains) or prefer not to use them, and your application currently uses embedded login, the best migration path is to [migrate to Universal Login](/guides/login/migration-embedded-universal). +::: \ No newline at end of file diff --git a/fr-ca/articles/libraries/_includes/_oidc_conformant.md b/fr-ca/articles/libraries/_includes/_oidc_conformant.md new file mode 100644 index 0000000000..ec12a82cf5 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_oidc_conformant.md @@ -0,0 +1,5 @@ +### Remove the oidcConformant parameter + +When the `oidcConformant` flag was set to true, Lock 10 used [Cross Origin Authentication](/cross-origin-authentication), and did not use the '/usernamepassword/login' and '/ssodata' endpoints. + +Given Lock 11 always uses Cross Origin Authentication and does not use the '/ssodata' endpoint, this flag is not longer needed. If specified, it will be ignored. diff --git a/fr-ca/articles/libraries/_includes/_popup_mode.md b/fr-ca/articles/libraries/_includes/_popup_mode.md new file mode 100644 index 0000000000..6de2c95a77 --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_popup_mode.md @@ -0,0 +1,3 @@ +### Usage in popup mode + +When using [popup mode](libraries/lock/authentication-modes#popup-mode) in previous versions of Lock, a new browser window was opened and immediately closed in order to complete the authentication transaction. In Lock 11, that window is opened on a hidden iframe, providing a better user experience. diff --git a/fr-ca/articles/libraries/_includes/_review_get_ssodata.md b/fr-ca/articles/libraries/_includes/_review_get_ssodata.md new file mode 100644 index 0000000000..509974a67a --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_review_get_ssodata.md @@ -0,0 +1,26 @@ +### Review calls to getSSOData() + +The deprecated `getSSOData()` function was reimplemented in Auth0.js v9 to simplify migration from older versions, but the behavior is not exactly the same. + +The function will not work as expected when you use it in Web Applications that use the [Authorization Code Flow](/flows/concepts/auth-code) (such as when you specify `response_type='code'`). It will always return that there is not a current session. + +If you want to avoid showing the Lock dialog when there is an existing session in the server, you can use the [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) function in Auth0.js. + +We recommend that you do not use `getSSOData()` and use [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) instead. Note that in order for `checkSession()` to work properly, it requires that you set the **Allowed Web Origins** field in the dashboard. + +::: note +Note that `checkSession()` triggers any [rules](/rules) you may have set up, whereas `getSSOData()` does not. It is possible that this could cause unintended behavior depending on what rules you have set up (if any) so you should check on your rules in the [Dashboard](${manage_url}/#/rules) prior to switching methods. +::: + +If you are going to keep using `getSSOData()`, take into account the changes in the return values described in the table below. In most applications, the only value that was actually used was the `sso` property, which still has the same semantics. + +| **Property** | **Old Value** | **New Value** | +| --- | --- | --- | +| sso | `true` if user has an existing session, `false` if not | The same | +| sessionClients | List of applications ids the user has active sessions with | List with a single element with the client id configured in auth0.js | +| lastUsedClientId | The client id for the last active connection | The last application used when authenticating from the current browsers | +| lastUsedUserId | The user id for the current session | The same | +| lastUsedUsername | User's email or name | The same (requires `scope=’openid profile email’)` | +| lastUsedConnection | Last used connection and strategy. | Last connection used when authenticated from the current browser. It will be `null` if the user authenticated via Universal Login. It will not return `strategy`, only `name` | + +For the function to work properly, you need to ask for `scope='openid profile email'` when you initialize Auth0.js. diff --git a/fr-ca/articles/libraries/_includes/_spa_js_faq.md b/fr-ca/articles/libraries/_includes/_spa_js_faq.md new file mode 100644 index 0000000000..0595e4e5fb --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_spa_js_faq.md @@ -0,0 +1,5 @@ + + +::: note +If you encounter some problems or errors when using the new JavaScript SDK, please [check out the FAQ](https://github.com/auth0/auth0-spa-js/blob/master/FAQ.md) to see if your issue is covered there. +::: \ No newline at end of file diff --git a/fr-ca/articles/libraries/_includes/_verifying_migration.md b/fr-ca/articles/libraries/_includes/_verifying_migration.md new file mode 100644 index 0000000000..a4edd88b3c --- /dev/null +++ b/fr-ca/articles/libraries/_includes/_verifying_migration.md @@ -0,0 +1,12 @@ +### Verifying your migration + +Once you have migrated your codebase, you should no longer see [deprecation notes in your logs](/troubleshoot/guides/check-deprecation-errors). + +If you would like to be sure that your applications are no longer calling the legacy endpoints, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy Lock API switch. Turning off this switch will disable the deprecated Lock / Auth0.js endpoints for your tenant, preventing them from being used at all. + +![Legacy Lock API](/media/articles/libraries/lock/migration-toggles.png) + +After disabling this switch, if the Legacy Lock API errors in your logs do not clear up or if turning it off results in failed logins, this is a sign that you have yet to completely remove all instances of legacy code from your applications. + +Once migrations have been successfully performed in production environments, the switch can be toggled off and left off, to ensure that the deprecated features can no longer be used. + diff --git a/fr-ca/articles/libraries/auth0-android/configuration.md b/fr-ca/articles/libraries/auth0-android/configuration.md new file mode 100644 index 0000000000..08e87aef3f --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/configuration.md @@ -0,0 +1,116 @@ +--- +section: libraries +toc: true +description: How to configure Auth0.Android to meet your application's needs +topics: + - libraries + - android +contentType: how-to +useCase: enable-mobile-auth +--- +# Auth0.Android Configuration Options + +Auth0.Android can be configured with a variety of options, listed below. + +## withConnection + +The `withConnection` option allows you to specify a connection that you wish to authenticate with. + +```java +WebAuthProvider.login(account) + .withConnection("twitter") + .start(this, authCallback); +``` + +## useCodeGrant + +Code grant is the default mode, and will always be used unless calling `useCodeGrant` with `false`, or unless the device doesn't support the signing/hashing algorithms. + +Before you can use `Code Grant` in Android, make sure to go to your [Dashboard](${manage_url}/#/applications) and check in the application's settings that `Application Type` is `Native`. + +```java +WebAuthProvider.login(account) + .useCodeGrant(true) + .start(this, authCallback); +``` + +## withScope + +Using scopes can allow you to return specific claims for specific fields in your request. Adding parameters to `withScope` will allow you to add more scopes. You should read our [documentation on scopes](/scopes) for further details about them. + +```java +WebAuthProvider.login(account) + .withScope("openid email profile") + .start(this, authCallback); +``` + +::: panel Scope +Note that the default scope used is `openid` +::: + +## withConnectionScope + +There may be times when you need to authenticate with particular connection scopes, or permissions, from the Authentication Provider in question. Auth0 has [documentation on setting up connection scopes for external Authentication Providers](/connections/adding-scopes-for-an-external-idp). However, if you need specific access for a particular situation in your app you can do so by passing parameters to `withConnectionScope`. A full listing of available parameters can be found in that connection's settings in your [Dashboard](${manage_url}), or from the Authentication Providers's documentation. The scope requested here is added on top of the ones specified in the connection's settings in the Dashboard. + +```java +WebAuthProvider.login(account) + .withConnectionScope("email", "profile", "calendar:read") + .start(this, authCallback); +``` + +## withParameters + +To send additional parameters on the authentication, use `withParameters`: + +```java +Map parameters = new HashMap<>(); +//Add entries +WebAuthProvider.login(account) + .withParameters(parameters) + .start(this, authCallback); +``` + +## withScheme + +If you are not using Android "App Links" or you want to use a different scheme for the redirect URI, then use `withScheme`. Note that you'll need to update the `auth0Scheme` Manifest Placeholder in the `app/build.gradle` file and the whitelisted **Allowed Callback URLs** on the [Dashboard](${manage_url}) in the Application's settings to match the chosen scheme. + +```java +WebAuthProvider.login(account) + .withScheme("myapp") + .start(this, authCallback); +``` + +::: note +Scheme must be lowercase! +::: + +## withAudience + +To provide an audience, use `withAudience`. + +```java +WebAuthProvider.login(account) + .withScope("openid") + .withAudience("https://${account.namespace}/userinfo") + .start(this, authCallback); +``` + +## withState + +By default a random [state](/protocols/oauth2/oauth-state) is always generated and sent. If you need to use a custom value instead, use `withState`: + +```java +WebAuthProvider.login(account) + .withState("my-custom-state") + .start(this, authCallback); +``` + +## withNonce + +By default a random nonce is generated and sent when the response type includes `id_token`. If you need to use a custom value instead, use `withNonce`: + +```java +WebAuthProvider.login(account) + .withNonce("my-custom-nonce") + .start(this, authCallback); +``` diff --git a/fr-ca/articles/libraries/auth0-android/database-authentication.md b/fr-ca/articles/libraries/auth0-android/database-authentication.md new file mode 100644 index 0000000000..430ed70c91 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/database-authentication.md @@ -0,0 +1,64 @@ +--- +section: libraries +toc: true +description: How to use Auth0.Android with database connections +topics: + - libraries + - android + - db-connections +contentType: how-to +useCase: enable-mobile-auth +--- +# Auth0.Android Database Authentication + +::: panel-warning Database authentication on Native Platforms +Username/Email & Password authentication from native applications is disabled by default for new tenants as of 8 June 2017. Users are encouraged to use Universal Login and perform Web Authentication instead. If you still want to proceed you'll need to enable the Password Grant Type on your dashboard first. See [Application Grant Types](/applications/concepts/application-grant-types) for more information. +::: + +## Log in with a database connection + +To log in with a database connection, call `login` with the user's **email**, **password**, and the **connection** you wish to authenticate with. The response will be a Credentials object. + +Additionally, specifying the **audience** will yield an OIDC-conformant response during authentication. + +```java +authentication + .login("info@auth0.com", "a secret password", "my-database-connection") + .setAudience("https://${account.namespace}/userinfo") + .start(new BaseCallback() { + @Override + public void onSuccess(Credentials payload) { + //Logged in! + } + + @Override + public void onFailure(AuthenticationException error) { + //Error! + } + }); +``` + +::: note +The default scope used is `openid`. +::: + +## Sign up with database connection + +To sign up with a database connection you have to call the `signUp` method, passing the user's email, password, and connection name. + +```java +authentication + .signUp("info@auth0.com", "a secret password", "my-database-connection") + .setAudience("https://${account.namespace}/userinfo") + .start(new BaseCallback() { + @Override + public void onSuccess(Credentials payload) { + //Signed Up & Logged in! + } + + @Override + public void onFailure(AuthenticationException error) { + //Error! + } + }); +``` diff --git a/fr-ca/articles/libraries/auth0-android/index.md b/fr-ca/articles/libraries/auth0-android/index.md new file mode 100644 index 0000000000..adfdcc3f4d --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/index.md @@ -0,0 +1,219 @@ +--- +section: libraries +toc: true +description: How to install, initialize and use Auth0.Android +url: /libraries/auth0-android +topics: + - libraries + - android +contentType: + - how-to + - index +useCase: enable-mobile-auth +--- +# Auth0.Android + +Auth0.Android is a client-side library you can use with your Android app to authenticate users and access [Auth0 APIs](/api/info). + +::: note +Check out the [Auth0.Android repository](https://github.com/auth0/Auth0.Android) on GitHub. +::: + +## Requirements + +Android API version 15 or newer is required. + +## Installation + +<%= include('../../quickstart/native/android/_includes/_gradle.md') %> + +## Permissions + +Open your app's `AndroidManifest.xml` file and add the following permission. + +```xml + +``` + +## Initialize Auth0 + +Save your application information in the `strings.xml` file using the following names: + +```xml + + ${account.clientId} + ${account.namespace} + + +``` + +And then create your new Auth0 instance by passing an Android Context: + +```java +Auth0 account = new Auth0(context); +``` + +## OIDC Conformant Mode + +It is strongly encouraged that this SDK be used in [OIDC Conformant mode](/api-auth/intro). When this mode is enabled, it will force the SDK to use Auth0's current authentication methods and will prevent it from reaching legacy endpoints. By default is `false`. + +```java +Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); +//Configure the account in OIDC conformant mode +account.setOIDCConformant(true); +//Use the account in the API applications +``` + +## Authentication via Universal Login + +First, go to the [Dashboard](${manage_url}/#/applications) and go to your application's settings. Make sure you have in **Allowed Callback URLs** a URL with the following format: + +``` +https://${account.namespace}/android/{YOUR_APP_PACKAGE_NAME}/callback +``` + +::: note +Replace `{YOUR_APP_PACKAGE_NAME}` with your actual application's package name, available in your `app/build.gradle` file as the `applicationId` value. +::: + +Then in your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI. + +```groovy +apply plugin: 'com.android.application' + +android { + compileSdkVersion 25 + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 15 + targetSdkVersion 25 + //... + + //---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"] + //<--- + } + //... +} +``` + +::: note +It's a good practice to define reusable resources like `@string/com_auth0_domain` (as done in a previous step with `strings.xml`) rather than just hard-coding them. +::: + +Alternatively, you can declare the `RedirectActivity` in the `AndroidManifest.xml` file with your own **intent-filter** so it overrides the library's default. If you do this then the Manifest Placeholders don't need to be set as long as the activity declaration contains the `tools:node="replace"` attribute: + +```xml + + + + + + + + + + + /callback" + android:scheme="https" /> + + + + + + + +``` + +Finally, don't forget to add the internet permission: + +```xml + +``` + +::: note +In versions 1.8.0 or lower of Auth0.Android you had to define the **intent-filter** inside your activity to capture the authentication result in the `onNewIntent` method and then call `WebAuthProvider.resume()` with the received data. The intent-filter declaration and resume call are no longer required for versions greater than 1.8.0, as it's now done internally by the library for you. +::: + +Now, let's authenticate a user by presenting the universal [login page](/universal-login): + +```java +WebAuthProvider.login(account) + .withAudience("https://${account.namespace}/userinfo") + .start(this, authCallback); +``` + +The authentication result will be delivered to the callback. + +To ensure a response that complies with OpenID Connect (OIDC), you must either set an `audience` using [withAudience](/libraries/auth0-android/configuration#withAudience) or enable the **OIDC Conformant** switch in your Auth0 dashboard under **Dashboard > Settings > Advanced > OAuth**. You can read more about this in the documentation page on [how to use new flows](/api-auth/intro#how-to-use-the-new-flows). + +## Using the Authentication API + +The Authentication Application provides methods to accomplish authentication and related tasks. Create a new instance by passing in the Auth0 object created in the previous step. + +```java +AuthenticationAPIClient authentication = new AuthenticationAPIClient(account); +``` + +### Get user information + +To get the information associated with a given user's Access Token, you can call the `userInfo` endpoint, passing the token. + +```java +authentication + .userInfo("Access Token") + .start(new BaseCallback() { + @Override + public void onSuccess(UserProfile information) { + //user information received + } + + @Override + public void onFailure(AuthenticationException error) { + //user information request failed + } + }); +``` + +### Password Resets + +To initiate a password reset for a user, call `resetPassword` with the user's email address and the database connection name as parameters. + +```java +String connectionName = "Username-Password-Authentication"; +authentication + .resetPassword("foo@bar.com", connectionName) + .start(new AuthenticationCallback() { + @Override + public void onSuccess(Void payload) { + //Password Reset requested + } + + @Override + public void onFailure(AuthenticationException error) { + //Request failed + } + }); +``` + +::: note +Password reset requests will fail on network related errors, but will not fail if the designated email does not exist in the database (for security reasons). +::: + +## Next Steps + +Take a look at the following resources to see how the Auth0.Android SDK can be customized for your needs: + +::: next-steps +* [Auth0.Android Configuration Options](/libraries/auth0-android/configuration) +* [Auth0.Android Database Authentication](/libraries/auth0-android/database-authentication) +* [Auth0.Android Passwordless Authentication](/libraries/auth0-android/passwordless) +* [Auth0.Android Refresh Tokens](/libraries/auth0-android/save-and-refresh-tokens) +* [Auth0.Android User Management](/libraries/auth0-android/user-management) +::: diff --git a/fr-ca/articles/libraries/auth0-android/passwordless.md b/fr-ca/articles/libraries/auth0-android/passwordless.md new file mode 100644 index 0000000000..166610f555 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/passwordless.md @@ -0,0 +1,81 @@ +--- +section: libraries +toc: true +description: How to use Auth0.Android with passwordless connections +topics: + - libraries + - android + - passwordless +contentType: how-to +useCase: enable-mobile-auth +--- +# Auth0.Android Passwordless Authentication + +Passwordless can be done via email or via SMS, and either by sending the user a code, or sending them a link which contains a code. All of these methods of Passwordless authentication will require two steps - requesting the code, and then inputting the code for verification. + +## Configure Auth0 and the Android SDK + +### Enable the Passwordless OTP Grant for the Application + +In order to be able to use the Passwordless API from a Native client, you first need to enable the Passwordless OTP grant for your application in **Dashboard > Applications > (YOUR APPLICATION) > Settings > Advanced Settings > Grant Types**. + +### Initialize the Android SDK + +Using the Passwordless API requires setting using the Auth0 Android SDK version 1.20 or higher, configured to work in OIDC conformant mode. This can be achieved by setting the `OIDCConformant` property to `true`: + +```java +Auth0 account = new Auth0("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}"); +//Configure the account in OIDC conformant mode +account.setOIDCConformant(true); +//Use the account in the API clients +``` + +## Implement Passwordless Authentication Steps + +## Request the code + +In this example, requesting the code is done by calling `passwordlessWithEmail` with the user's email, `PasswordlessType.CODE`, and the name of the connection as parameters. On success, you may wish to display a notice to the user that their code is on the way, and perhaps route them to the view where they will input that code. + +```java +authentication + .passwordlessWithEmail("info@auth0.com", PasswordlessType.CODE, "my-passwordless-connection") + .start(new BaseCallback() { + @Override + public void onSuccess(Void payload) { + //Code sent! + } + + @Override + public void onFailure(AuthenticationException error) { + //Error! + } + }); +``` + +You can use the `passwordlessWithSms` method to send the code using SMS. + +## Input the code + +Once the user has a code, they can input it. Call the `loginWithEmail` method, and pass in the user's email, the code they received, and the name of the connection in question. Upon success, you will receive a Credentials object in the response. + +```java +authentication + .loginWithEmail("info@auth0.com", "123456", "my-passwordless-connection") + .start(new BaseCallback() { + @Override + public void onSuccess(Credentials payload) { + //Logged in! + } + + @Override + public void onFailure(AuthenticationException error) { + //Error! + } + }); +``` + +You can use the `loginWithSms` method to send the code received by SMS and authenticate the user. + +::: note +The default scope used is `openid`. +::: diff --git a/fr-ca/articles/libraries/auth0-android/save-and-refresh-tokens.md b/fr-ca/articles/libraries/auth0-android/save-and-refresh-tokens.md new file mode 100644 index 0000000000..c70ab2403e --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/save-and-refresh-tokens.md @@ -0,0 +1,135 @@ +--- +section: libraries +description: Keeping your user logged in with Auth0.Android +toc: true +topics: + - libraries + - android + - tokens +contentType: how-to +useCase: enable-mobile-auth +--- +# Auth0.Android Saving and Renewing Tokens + +When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new user token, without forcing the user to perform authentication again. + +## Credentials Manager + +[Auth0.Android](https://github.com/auth0/Auth0.Android) provides a utility class to streamline the process of storing and renewing credentials. You can access the `accessToken` or `idToken` properties from the [Credentials](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/result/Credentials.java) instance. This is the preferred method to manage user credentials. + +Credential Managers are included as part of the Auth0.Android SDK. If this is not part of your dependencies yet, make sure to [check the documentation](/libraries/auth0-android). + +Next, decide which class to use depending on your Android SDK target version. + +### API less than 21 + +If you require APIs lower than 21 (Lollipop) create a new instance of `CredentialsManager`. This class makes use of the `Context.MODE_PRIVATE` to store the credentials in a key-value preferences file, accessible only to your app. The data is stored in plaintext. + +### API equal to or greater than 21 + +If you require APIs equal or greater than 21 (Lollipop) create a new instance of `SecureCredentialsManager`. This class has the same methods as the one above, but encrypts the data before storing it using a combination of _RSA_ and _AES_ algorithms along with the use of [Android KeyStore](https://developer.android.com/reference/java/security/KeyStore.html). + +## Using the CredentialsManager class + +### Setup the CredentialsManager + +Create a new instance by passing an `AuthenticationAPIClient` and a `Storage` implementation. + +```java +Auth0 auth0 = new Auth0(this); +AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0); +CredentialsManager manager = new CredentialsManager(apiClient, new SharedPreferencesStorage(this)); +``` + +### Current State of the Authentication + +Stored credentials are considered valid if they have not expired or can be refreshed. Check if a user has already logged in: + +```java +boolean loggedIn = manager.hasValidCredentials(); +``` + +When you want to log the user out of your app, remove the stored credentials and direct them to the login screen. + +```java +manager.clearCredentials(); +//Show login screen +``` + +### Retrieving Credentials + +Because the credentials may need to be refreshed against Auth0 Servers, this method is asynchronous. Pass a callback implementation where you'd like to receive the credentials. Credentials returned by this method upon success are always valid. + +```java +manager.getCredentials(new BaseCallback() { + @Override + public void onSuccess(Credentials credentials) { + //Use credentials + } + + @Override + public void onFailure(CredentialsManagerException error) { + //No credentials were previously saved or they couldn't be refreshed + } +}); +``` + +::: note +If the `accessToken` has expired, the manager will automatically use the `refreshToken` and renew the credentials for you. New credentials will be stored for future access. +::: + +### Save new Credentials + +You can save the credentials obtained during authentication in the manager. + +```java +manager.saveCredentials(credentials); +``` + +## Using the SecureCredentialsManager class + +### Setup the SecureCredentialsManager + +Setup is a little different to the CredentialsManager class. Create a new instance by passing a valid android `Context`, an `AuthenticationAPIClient` and a `Storage` implementation. + +```java +Auth0 auth0 = new Auth0(this); +AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0); +SecureCredentialsManager manager = new SecureCredentialsManager(this, apiClient, new SharedPreferencesStorage(this)); +``` + +The methods to obtain, save, check for existence and clearing the credentials are the ones explained before. + +### Pre-Authenticate the User + +This class provides optional functionality for additional authentication using the device's configured Lock Screen. If the Lock Screen Security is set to something different than PIN, Pattern, Password or Fingerprint, this feature won't be available. You need to call the method below to enable the authentication. Pass a valid `Activity` context, a request code, and 2 optional Strings to use as title and description for the Lock Screen. + +```java +private static final int RC_UNLOCK_AUTHENTICATION = 123; + +//Called from an Activity +boolean available = manager.requireAuthentication(this, RC_UNLOCK_AUTHENTICATION, getString(R.string.unlock_authentication_title), getString(R.string.unlock_authentication_description)); +``` + +If the feature was enabled, the manager will prompt the user to authenticate using the configured Lock Screen. The result of this call will be obtained in the `onActivityResult` method of the activity passed before as first parameter. If the feature was not enabled, Lock Screen authentication will be skipped. + +After checking that the received request code matches the one used in the configuration step, redirect the received parameters to the manager to finish the authentication. The credentials will be yield to the original callback. + +```java +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + if (requestCode == RC_UNLOCK_AUTHENTICATION && manager.checkAuthenticationResult(requestCode, resultCode)) { + return; + } + super.onActivityResult(requestCode, resultCode, data); +} +``` + +### Handling usage exceptions + +In the event that something happened while trying to save or retrieve the Credentials, a `CredentialsManagerException` will be thrown. These are some of the failure scenarios you can expect: + +- The Credentials to be stored are invalid, e.g. some of the following fields are not defined: access_token, id_token or expires_at. +- The stored Credentials have expired but there is no refresh_token available to renew them automatically. +- Device's Lock Screen security settings have changed (e.g. the security PIN code was changed). Even when `hasCredentials` returns _true_, the encryption keys will be deemed invalid and until `saveCredentials` is called again it won't be possible to decrypt any previously existing content, since they keys used back then are not the same as the new ones. +- Device is not compatible with some of the cryptography algorithms required by the `SecureCredentialsManager` class. This is considered a _catastrophic event_ and is the only exception that will prevent you from using this implementation. This scenario happens when the OEM has modified the Android ROM of the device removing some of the algorithms officially included in every Android distribution. Nevertheless, you can check if this is the case in the exception instance itself by calling the `isDeviceIncompatible` method. By doing so you can decide the fallback implementation for storing the Credentials, such as using the regular `CredentialsManager` class. diff --git a/fr-ca/articles/libraries/auth0-android/user-management.md b/fr-ca/articles/libraries/auth0-android/user-management.md new file mode 100644 index 0000000000..51c085825e --- /dev/null +++ b/fr-ca/articles/libraries/auth0-android/user-management.md @@ -0,0 +1,97 @@ +--- +section: libraries +toc: true +description: How to use Auth0.Android to manage users +topics: + - libraries + - android + - users +contentType: how-to +useCase: enable-mobile-auth +--- +# Use Auth0.Android to Manage Users + +The Management API provides functionality that you can use to manage users of your application, including tasks such as the following. + +* Link separate user accounts from different providers, tying them to a single profile (See [User Account Linking](/users/concepts/overview-user-account-linking) for details.) +* Unlink user accounts, returning them to separate identities +* Update [user metadata](/users/concepts/overview-user-metadata) + +## Initialize the UsersAPIClient + +To get started, create a new `UsersAPIClient` instance by passing it the `account` and the token for the primary identity. In the case of linking users, this primary identity is the user profile that you want to "keep" the data for, and which you plan to link other identities to. + +```java +Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); +UsersAPIClient users = new UsersAPIClient(account, "token"); +``` + +## Link users + +Linking user accounts will allow a user to authenticate from any of their accounts and no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish a user's accounts to refer to the same profile, you must perform account linking. + +The `link` method accepts two parameters, the primary user id and the secondary user token (the token obtained after login with this identity). The user id in question is the unique identifier for this user account. If the id is in the format `facebook|1234567890`, the id required is the portion after the delimiting pipe. + +```java +users + .link("primary user id", "secondary user token") + .start(new BaseCallback, ManagementException>() { + @Override + public void onSuccess(List payload) { + //Got the updated identities! Accounts linked. + } + + @Override + public void onFailure(ManagementException error) { + //Error! + } + }); +``` + +## Unlink users + +Unlinking users is a similar process to the linking of users. The `unlink` method takes three parameters, though: the primary user id, the secondary user id, and the secondary provider (of the secondary user). + +```java +users + .unlink("primary user id", "secondary user id", "secondary provider") + .start(new BaseCallback, ManagementException>() { + @Override + public void onSuccess(List payload) { + //Got the updated identities! Accounts linked. + } + + @Override + public void onFailure(ManagementException error) { + //Error! + } + }); +``` + +::: note +When accounts are linked, the secondary account's metadata is **not** merged with the primary account's metadata. Similarly, when unlinking two accounts, the secondary account does not retain the primary account's metadata when it becomes separate again. +::: + +## Updating user metadata + +When updating user metadata, you will create a `metadata` object, and then call the `updateMetadata` method, passing it the user id and the `metadata` object. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata. + +```java +Map metadata = new HashMap<>(); +metadata.put("name", Arrays.asList("My", "Name", "Is")); +metadata.put("phoneNumber", "1234567890"); + +users + .updateMetadata("user id", metadata) + .start(new BaseCallback() { + @Override + public void onSuccess(UserProfile payload) { + //Metadata updated + } + + @Override + public void onFailure(ManagementException error) { + //Error! + } + }); +``` diff --git a/fr-ca/articles/libraries/auth0-php/authentication-api.md b/fr-ca/articles/libraries/auth0-php/authentication-api.md new file mode 100644 index 0000000000..570ccc6e83 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/authentication-api.md @@ -0,0 +1,205 @@ +--- +section: libraries +toc: true +description: Using Auth0's Authentication API with your PHP applications. +topics: + - libraries + - php +contentType: + - how-to + - reference +useCase: + - add-login +--- +# PHP: Using the Authentication API + +The Auth0 PHP SDK provides a `Auth0\SDK\API\Authentication` class, which houses the methods you can use to access the [Authentication API](/api/authentication) directly. Please note that this interface is intended for more advanced applications and in general does provide a means of keeping track of user sessions. For most use cases, you'll want to work with the [Auth0 base class](/libraries/auth0-php/basic-use). + +In this article, you'll find examples of common authentication operations. + +## Prerequisites + +The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there. + +## Authorization Code Flow + +An [Authorization Code grant](/api-auth/tutorials/authorization-code-grant) is the basic way to grant users access to your application. This flow is the same one used on the [Basic Use page](/libraries/auth0-php/basic-use#login). If you need more granular control over the login or callback process, this section walks through how to use the Authentication API directly. + +Users must authenticate with Auth0 to generate the authorization code. This is done by redirecting to the `/authorize` endpoint for your tenant domain. The following code would appear on a page that requires authentication: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there. + +// Setup a PHP session, which we'll use as a custom session store for the authenticated user. +session_start(); + +// $user will be null if no session is available; otherwise it will contain user data. +$user = $_SESSION['user'] ?? null; + +// Has the user authenticated with us yet? +if ($user === null) { + // Generates cryptographically secure pseudo-random bytes to use as a CSRF mitigating value. + // Store this for retrieval after authentication. + $_SESSION['state'] = bin2hex(random_bytes(16)); + + // Generate the authorize URL, and redirect the user to it. + header('Location: ' . $auth0->authentication()->getLoginLink($_SESSION['state'])); + exit; +} + +echo '

Sensitive data!

'; +``` + +The process above does the following: + +1. We check if there is an authenticated user state stored in our custom session handler. Your application might handle user sessions differently. +2. If there is no session, then we need to log the user in by redirecting them to the Universal Login Page. +3. We set a state value with the login request and then verify that value when the code is returned on the callback URL. We're storing this in our PHP session under the 'state' key. +4. The `getLoginLink()` call builds the correct `/authorize` link with the correct response type (`code` in this case), redirect URI (wherein the application we will handle the response, explained below), and state (from above). +5. We then redirect to this URL and wait for the user to be redirected back to us. + +After authentication, the user is redirected back to our application at the callback URL, which is handled with the following: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there. + +// Ensure we have our PHP session open so we can retrieve our stored state for comparison. +session_start(); + +// Extract `code` and `state` parameters from the request query, if present. +$code = filter_var($_GET['code'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE); +$state = filter_var($_GET['state'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE); + +// Check if a code is present in the request query. +if ($code === null) { + die('No authorization code found.'); +} + +// Check if a state is present, and compare it with the one we generated and stored before redirecting the user. +if ($state === null || $state !== $_SESSION['state']) { + die('Invalid state.'); +} + +// We have compared states, we should discard this stored value now. +unset($_SESSION['state']); + +// Attempt to get an access_token with the code returned and original redirect URI. (This returns a PSR-7 ResponseInterface.) +$response = $auth0->authentication()->codeExchange($code); + +// Does the status code of the response indicate failure? +if ($response->getStatusCode() !== 200) { + die("Code exchange failed."); +} + +// Decode the JSON response into a PHP array: +$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR); + +// Create an array to store our session information in. +$session = [ + 'id_token' => $response['id_token'] ?? null, + 'access_token' => $response['access_token'] ?? null, + 'scope' => $response['scope'] ?? null, + 'refresh_token' => $response['refresh_token'] ?? null, + 'expires_in' => $response['expires_in'] ?? null, + 'user' => null +]; + +// We retrieved an ID token; let's process it! +if ($session['id_token'] !== null) { + // The Auth0 SDK includes a helpful token processing utility we'll leverage for this: + $token = new \Auth0\SDK\Token($auth0->configuration(), $session['id_token'], \Auth0\SDK\Token::TYPE_ID_TOKEN); + + // Verify the token, and validate it's claims. These will throw an \Auth0\SDK\Exception\InvalidTokenException if a check fails. + $token->verify(); + $token->validate(); + + $session['user'] => $token->toArray(); +} + +// Store our authenticated session state. +$_SESSION['user'] = $session; + +// Let's echo the user claims/identity as a demo of a successful authentication flow: +print_r($session['user']); +``` + +Walking through the process in detail: + +1. We look for a `code` parameter in a request query. If it's missing, we abort authentication. +2. We check to make sure we have a `state` value and make sure it matches the same one we generated. This is important to avoid CSRF attacks ([more information](/protocols/oauth2/mitigate-csrf-attacks).) +3. We attempt a code exchange with the `codeExchange()` call, making sure to pass in the `code` Auth0 gave our application when it returned the authenticating user back to us. +4. If this succeeds, we know the exchange was successful, and we have an ID Token and an Access Token among other potential values. +5. We validate the ID Token and use the claims for the user identity. +6. If this last step succeeds, we store the user and redirect back to our sensitive data. + +## Client Credentials Flow + +A [Client Credentials grant](/api-auth/tutorials/client-credentials) gives an application access to a specific API based on the scopes set in the Auth0 Dashboard. This is how applications can, for example, make calls to the Management API. Successful authentication will result in an Access Token being issued for the API requested. + +First, turn on the **Client Credentials** grant on then **Advanced settings > Grant Types** tab on the Application settings page. + +Next, authorize the Application for the API being used on the **Machine to Machine Applications** tab on the API's **Settings** page. Make sure all necessary scopes are selected (but no more) and **Update**. Switch back to the **Settings** tab and copy the **Identifier** value. This needs to be added to a `AUTH0_MANAGEMENT_AUDIENCE` key in your `.env` file. + +Request an Access Token for the API using the example below: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. + +// Begin a client credentials exchange: +$response = $auth0->authentication()->clientCredentials([ + 'audience' => $env['AUTH0_MANAGEMENT_AUDIENCE'] +]); + +// Does the status code of the response indicate failure? +if ($response->getStatusCode() !== 200) { + die("Code exchange failed."); +} + +// Decode the JSON response into a PHP array: +$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR); + +// Echo the response to the browser +print_r($response, true); +``` + +If the grant was successful, you should see something like the following: + +``` +Array +( + [access_token] => eyJ0eXAi...eyJpc3Mi...QoB2c24w + [scope] => read:users read:clients ... + [expires_in] => 86400 + [token_type] => Bearer +) +``` + +See the [Management API page](/libraries/auth0-php/management-api) for more information on how to use this Access Token. + +## Single Sign-on Logout + +While destroying the local session with a `session_destroy()` would be sufficient in deauthenticating a user from your application, you should close your end user's session with Auth0 as well. This ensures that the next time the user sees an Auth0 login form, they will be required to provide their credentials to log in. + +First, determine where the user should end up after the logout has completed. Save this in the Auth0 Application settings in the "Allowed Logout URLs" field. Also, add an `AUTH0_LOGOUT_RETURN_URL` key with this URL as the value in your `.env` file. + +Add the following to your application logout code: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. + +// Deauthenticate the user's local session in your application. +session_destroy(); + +// Redirect to Auth0's logout URL to end their Auth0 session: +header("Location: " . $auth0->authentication()->getLogoutLink($env['AUTH0_LOGOUT_RETURN_URL']); +``` + +### Read more + +::: next-steps +* [PHP Getting Started](/libraries/auth0-php) +* [PHP Basic Use](/libraries/auth0-php/basic-use) +* [PHP Management API](/libraries/auth0-php/management-api) +* [PHP JWT Validation](/libraries/auth0-php/jwt-validation) +* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting) +::: diff --git a/fr-ca/articles/libraries/auth0-php/basic-use.md b/fr-ca/articles/libraries/auth0-php/basic-use.md new file mode 100644 index 0000000000..758fd798ad --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/basic-use.md @@ -0,0 +1,110 @@ +--- +section: libraries +toc: true +description: Integrate a frictionless login and signup experience for your PHP applications. +topics: + - libraries + - php +contentType: + - how-to + - reference +useCase: + - add-login +--- +# PHP: Basic Usage + +The Auth0 PHP SDK bundles three core classes: `Auth0\SDK\Auth0`, `Auth0\SDK\API\Authentication` and `Auth0\SDK\API\Management`, each offering interfaces for different functionality across Auth0's APIs. If you're building a stateful web application that needs to keep track of users' sessions, the base `Auth0` class is what you'll be working with the most. It provides methods for handling common authentication and session handling tasks such as logging in and out, retrieving user credentials, checking of an available session, and callback handling. These tasks are explained below. + +## Prerequisites + +The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there. + +## Logging In + +The default login process in the PHP SDK uses an [Authentication Code grant](/api-auth/tutorials/authorization-code-grant) combined with Auth0's Universal Login Page. In short, that process is: + +1. A user requesting access is redirected to the Universal Login Page. +2. The user authenticates using one of [many possible connections](https://auth0.com/docs/identityproviders): social (Google, Twitter, Facebook), database (email and password), passwordless (email, SMS), or enterprise (ActiveDirectory, ADFS, Office 365). +3. The user is redirected or posted back to your application's callback URL with `code` and `state` values if successful or an `error` and `error_description` if not. +4. If the authentication was successful, the `state` value is validated. +5. If the `state` is valid, the `code` value is exchanged with Auth0 for an ID Token and/or an Access Token. +6. The identity from the ID token can be used to create an account, to start an application-specific session, or to persist as the user session. + +Auth0-PHP handles most of these steps automatically for you. Your application will need to: + +1. Call `Auth0\SDK\Auth0::login()` when users need to login (for example: click a link, visit walled content, etc.) +2. Call `Auth0\SDK\Auth0::exchange()` when users are redirected to your callback URL. +3. Call `Auth0\SDK\Auth0::getCredentials()` when you need to check if a user is logged in and retrieve user information. + +A simple implementation of these steps looks like this: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there. + +// getExchangeParameters() can be used on your callback URL to verify all the necessary parameters are present for post-authentication code exchange. +if ($auth0->getExchangeParameters()) { + // If they're present, we should perform the code exchange. + $auth0->exchange(); +} + +// Check if the user is logged in already +$session = $auth0->getCredentials(); + +if ($session === null) { + // User is not logged in! + // Redirect to the Universal Login Page for authentication. + header("Location: " . $auth0->login()); + exit; +} + +// 🎉 At this point we have an authenticated user session accessible from $session; your application logic can continue from here! +echo "Authenticated!"; +``` + +Finally, you'll need to add you're application's URL to your Auth0 Application's "Allowed Callback URLs" field on the settings page. After that, loading your scripted page should: + +1. Immediately redirect you to an Auth0 login page for your tenant. +2. After successfully logging in using any connection, redirect you back to your app. +3. Display a simple page showing 'Authenticated!'. + +## Profile + +Now that we have authenticated a user, we can work with their persisted session data to do things like display user profiles. + +```php +// 👆 We're continuing from code above. Append this to the index.php file. + +printf( + '

Hi %s!

+

+

Last update: %s

+

Contact: %s %s

+

Logout

', + isset($session->user['nickname']) ? strip_tags($session->user['nickname']) : '[unknown]', + isset($session->user['picture']) ? filter_var($session->user['picture'], FILTER_SANITIZE_URL) : 'https://gravatar.com/avatar/', + isset($session->user['updated_at']) ? date('j/m/Y', strtotime($session->user['updated_at'])) : '[unknown]', + isset($session->user['email']) ? filter_var($session->user['email'], FILTER_SANITIZE_EMAIL) : '[unknown]', + ! empty($session->user['email_verified']) ? '✓' : '✗' +); +``` + +## Logout + +In addition to logging in, we also want users to be able to log out. When users log out, they must invalidate their session for the application. For this SDK, that means destroying their persistent user and token data: + +```php +// Log out of the application. +header("Location: $auth0->logout()); +``` + +If you're using Single Sign-on (SSO) and also want to end their Auth0 session, see the [SSO Logout section here](/libraries/auth0-php/authentication-api#sso-logout). More information about logging out, in general, can be found [here](/logout). + +### Read more + +::: next-steps +* [PHP Getting Started](/libraries/auth0-php) +* [PHP Authentication API](/libraries/auth0-php/authentication-api) +* [PHP Management API](/libraries/auth0-php/management-api) +* [PHP JWT Validation](/libraries/auth0-php/jwt-validation) +* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting) +::: diff --git a/fr-ca/articles/libraries/auth0-php/index.md b/fr-ca/articles/libraries/auth0-php/index.md new file mode 100644 index 0000000000..666ad55e32 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/index.md @@ -0,0 +1,113 @@ +--- +section: libraries +toc: true +description: Integrate a frictionless login and signup experience for your PHP applications. +url: /libraries/auth0-php +topics: + - libraries + - php +contentType: + - how-to + - index + - reference +useCase: + - add-login +--- +# PHP: Getting Started + +The Auth0-PHP SDK can integrate into your PHP applications to provide a straightforward way to log your users in and to sign them up in your app. It provides support for social identity providers such as Facebook, Google, or Twitter, as well as enterprise providers such as Active Directory. The SDK provides convenient methods for accessing Auth0's Authentication and Management endpoints. + +The Auth0-PHP repository is open source and [hosted on GitHub](https://github.com/auth0/auth0-PHP). We appreciate all contributions, including bug reports, enhancement proposals, and pull requests. + +## Requirements + +- PHP 7.4+ (8.0+ recommended) +- [Composer](https://getcomposer.org/doc/00-intro.md) 2 + +## Installation + +Installing the Auth0 PHP SDK requires [Composer](https://getcomposer.org/doc/00-intro.md#installation-linux-unix-macos), the standard dependency management utility for PHP. Composer allows you to declare the dependent libraries your project needs and installs them for you. Please ensure Composer is installed and accessible from your shell before continuing. + +Next, run the following shell command within your project directory to install the SDK: + +```sh +composer require auth0/auth0-php +``` + +This will create a `vendor` folder within your project and download all the dependencies needed to use the PHP SDK. This will also create a `vendor/autoload.php` file necessary for the SDK to work with your application, which we'll import later. + +## Getting Started + +To use the Auth0 Authentication and Management APIs, you'll need a free Auth0 account and an Application: + +1. Go to [auth0.com/signup](https://auth0.com/signup) and create an account. +2. From your dashboard, go to **Applications**, then **Create Application**. +3. Give your Application a name, select **Regular Web Application**, then **Create** +4. Click the **Settings** tab for the required credentials used below. More information about these settings is [here](/dashboard/reference/settings-application). + +### Configure the SDK + +You should use [environment variables](https://secure.php.net/manual/en/reserved.variables.environment.php) to store and load sensitive Auth0 credentials. This eliminates the need for hardcoding them into your application. Let's create an `.env` file within the root of our project directory to store our application's credentials: + +```sh +# The URL of our Auth0 Tenant Domain. +# If we're using a Custom Domain, be sure to set this to that value instead. +AUTH0_DOMAIN='https://${account.namespace}' + +# Our Auth0 application's Client ID. +AUTH0_CLIENT_ID='${account.clientId}' + +# Our Auth0 application's Client Secret. +AUTH0_CLIENT_SECRET='${account.clientSecret}' + +# A long secret value we'll use to encrypt session cookies. This can be generated using `openssl rand -hex 32` from our shell. +AUTH0_COOKIE_SECRET='SEE COMMENT ABOVE' + +# The base URL of our application. +AUTH0_BASE_URL='http://127.0.0.1:3000' +``` + +You should never commit this file to version control or share it in an unsecure manner. The contents should be handled with care and treated like a password. + +As PHP is unable to read our `.env` file natively, you'll need to install a PHP library to do so. For the purposes of this documentation we'll be using `vlucas/phpdotenv`, but any 'dotenv' library you prefer will work. From our project directory, run the following shell command to install the library: + +```sh +composer require vlucas/phpdotenv +``` + +### Initialize the SDK + +We're ready to configure and initialize an instance of the SDK within our new PHP application. Let's start by creating the PHP source file we'll be working with for this demonstration, `index.php`, and use the following snippet to get started: + +```php +load(); + +// Now instantiate the Auth0 class with our configuration: +$auth0 = new \Auth0\SDK\Auth0([ + 'domain' => $env['AUTH0_DOMAIN'], + 'clientId' => $env['AUTH0_CLIENT_ID'], + 'clientSecret' => $env['AUTH0_CLIENT_SECRET'], + 'cookieSecret' => $env['AUTH0_COOKIE_SECRET'] +]); +``` + +Congratulations, your application is now setup and ready to use with Auth0! You can now move on to building an example application using one of our PHP quickstarts. Choose the type of application you're looking to build to follow along with a quickstart suited for your needs: + +* [PHP Web Application](/quickstart/webapp/php/) +* [PHP Backend API](/quickstart/backend/php/) + +## Next Steps + +::: next-steps +* [PHP Basic Usage](/libraries/auth0-php/basic-use) +* [PHP Authentication API](/libraries/auth0-php/authentication-api) +* [PHP Management API](/libraries/auth0-php/management-api) +* [PHP JWT Validation](/libraries/auth0-php/jwt-validation) +* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting) +::: diff --git a/fr-ca/articles/libraries/auth0-php/jwt-validation.md b/fr-ca/articles/libraries/auth0-php/jwt-validation.md new file mode 100644 index 0000000000..3c98d21c19 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/jwt-validation.md @@ -0,0 +1,75 @@ +--- +section: libraries +toc: true +description: Validating JSON Web Tokens (JWTs) with your PHP applications. +topics: + - libraries + - php +contentType: + - how-to + - reference +--- +# PHP: Validating JWTs + +The Auth0 PHP SDK provides a `Auth0\SDK\Token` class used for processing JSON Web Tokens (JWT). It enables you to decode, validate and verify tokens for use by your application. More information on JWTs and how to build and decode them can be found [jwt.io](https://jwt.io/). + +The class can process both HS256 and RS256 tokens. Both types require the algorithm and valid audiences to be configured with the SDK before processing. HS256 tokens require the client secret to be configured. RS256 tokens require an authorized issuer, which is used to fetch a JWKs file during the decoding process. + +## Prerequisites + +The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there. + +## Example Usage + +The following is an example of a small, URL-based JSON Web Token processor based on the SDK's `Token` class. + +```php +load(); + +$token = filter_var($_GET['token'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE); +$algorithm = filter_var($_GET['algorithm'] ?? 'HS256', FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE); + +if ($token === null) { + die('No `token` request parameter.'); +} + +if (! in_array($algorithm, ['HS256', 'RS256'])) { + die('Invalid `algorithm` supplied.'); +} + +// The Auth0 SDK includes a helpful token processing utility we'll leverage for this: +$token = new \Auth0\SDK\Token([ + 'domain' => $env['AUTH0_DOMAIN'], + 'clientId' => $env['AUTH0_CLIENT_ID'], + 'clientSecret' => $env['AUTH0_CLIENT_SECRET'], + 'tokenAlgorithm' => $algorithm +], $token, \Auth0\SDK\Token::TYPE_ID_TOKEN); + +// Verify the token: (This will throw an \Auth0\SDK\Exception\InvalidTokenException if verification fails.) +$token->verify(); + +// Validate the token claims: (This will throw an \Auth0\SDK\Exception\InvalidTokenException if validation fails.) +$token->validate(); + +echo '
';
+print_r($token->toArray(), true);
+echo '
'; +``` + +Both `verify()` and `validate()` offer a number of options arguments that can be used to customize their behavior, including validating nonce claims, restricting maximum time since a token's `auth_time`, `leeway` clock tolerance for time checks, and more. These methods are fully commented for review of these options either via the source code or your IDE of choice. + +### Read more + +::: next-steps +* [PHP Getting Started](/libraries/auth0-php) +* [PHP Basic Use](/libraries/auth0-php/basic-use) +* [PHP Authentication API](/libraries/auth0-php/authentication-api) +* [PHP Management API](/libraries/auth0-php/management-api) +* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting) +::: diff --git a/fr-ca/articles/libraries/auth0-php/management-api.md b/fr-ca/articles/libraries/auth0-php/management-api.md new file mode 100644 index 0000000000..2fbae10fe9 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/management-api.md @@ -0,0 +1,123 @@ +--- +section: libraries +toc: true +description: Using Auth0's Management API with your PHP applications. +topics: + - libraries + - php +contentType: + - how-to + - reference +--- +# PHP: Using the Management API + +The Auth0 PHP SDK provides a `Auth0\SDK\API\Management` class, which houses the methods you can use to access the [Management API](/api/management/v2) and perform operations on your Auth0 tenant. Using this interface, you can easily: + +- Search for and create users +- Create and update Applications +- Retrieve log entries +- Manage rules + +... and much more. See our [APi reference](/api/management/v2) for information on what's possible! + +## Authentication + +To use the Management API, you must authenticate one of two ways: + +- For temporary access or testing, you can [manually generate an API token](/api/management/v2/tokens#get-a-token-manually) and save it in your `.env` file. +- For extended access, you must create and execute and Client Credentials grant when access is required. This process is detailed on the [Authentication API page](/libraries/auth0-php/authentication-api#regular-web-app-login-flow). + +Regardless of the method, the token generated must have the scopes required for the operations your app wants to execute. Consult the [API documentation](/api/management/v2) for the scopes required for the specific endpoint you're trying to access. + +To grant the scopes needed: + +1. Go to [APIs](https://manage.auth0.com/#/apis) > Auth0 Management API > **Machine to Machine Applications** tab. +2. Find your Application and authorize it. +3. Click the arrow to expand the row and select the scopes required. + +Now you can authenticate one of the two ways above and use that token to perform operations: + +```php +// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there. + +if (isset($env['AUTH0_MANAGEMENT_API_TOKEN'])) { + $auth0->configuration()->setManagementToken($env['AUTH0_MANAGEMENT_API_TOKEN']); +} + +// Create a configured instance of the `Auth0\SDK\API\Management` class, based on the configuration we setup the SDK ($auth0) using. +// If no AUTH0_MANAGEMENT_API_TOKEN is configured, this will automatically perform a client credentials exchange to generate one for you, so long as a client secret is configured. +$management = $auth0->management(); +``` + +The `Management` class stores access to endpoints as factory methods of its instances, for example `$management->users()` returns an instance of `Auth0\SDK\API\Management\Users` that you can use to interact with the /users Management API endpoints. + +### Example: Search Users + +This endpoint is documented [here](/api/management/v2#!/Users/get_users). + +```php +// 👆 We're continuing from the code above. Append this to your source code file. + +$response = $management->users()->getAll(['q' => 'josh']); + +// Does the status code of the response indicate failure? +if ($response->getStatusCode() !== 200) { + die("API request failed."); +} + +// Decode the JSON response into a PHP array: +$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR); + +if (! empty($response)) { + echo '

User Results

'; + + foreach ($response as $result) { + printf( + '

%s <%s> - %s

', + !empty($result['nickname']) ? $result['nickname'] : 'No nickname', + !empty($result['email']) ? $result['email'] : 'No email', + $result['user_id'] + ); + } +} +``` + +### Example: Get All Clients + +This endpoint is documented [here](/api/management/v2#!/Clients/get_clients). + +```php +// 👆 We're continuing from the code above. Append this to your source code file. + +$response = $management->clients()->getAll(['q' => 'josh']); + +// Does the status code of the response indicate failure? +if ($response->getStatusCode() !== 200) { + die("API request failed."); +} + +// Decode the JSON response into a PHP array: +$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR); + +if (! empty($response)) { + echo '

Get All Clients

'; + + foreach ($response as $result) { + printf( + '

%s - %s

', + $result['name'], + $result['client_id'] + ); + } +} +``` + +### Read more + +::: next-steps +* [PHP Introduction](/libraries/auth0-php) +* [PHP Basic Use](/libraries/auth0-php/basic-use) +* [PHP Authentication API](/libraries/auth0-php/authentication-api) +* [PHP JWT Validation](/libraries/auth0-php/jwt-validation) +* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting) +::: diff --git a/fr-ca/articles/libraries/auth0-php/troubleshooting.md b/fr-ca/articles/libraries/auth0-php/troubleshooting.md new file mode 100644 index 0000000000..cbd531246b --- /dev/null +++ b/fr-ca/articles/libraries/auth0-php/troubleshooting.md @@ -0,0 +1,40 @@ +--- +section: libraries +toc: true +description: Troubleshooting commons issues with your PHP applications. +topics: + - libraries + - php +contentType: + - reference +--- +# PHP: Troubleshooting the SDK + +The following is a list of issues you might see when using the Auth0 PHP library and how you might troubleshoot these issues. + +### I'm getting an "Invalid State" exception when trying to log in. + +[State validation](https://auth0.com/docs/protocols/oauth2/oauth-state) was added in 5.1.0 for improved security. By default, this uses session storage and will happen automatically if you are using a combination of `Auth0::login()` and any method which calls `Auth0::exchange()` in your callback. + +If your users encounter this error: +- Ensure your application is not accidentally invoking `Auth0::login()` more than once, which could invalidate the state stored on the end user's device. +- The end user is using a modern browser on their device and not blocking cookies. + +### I am getting `curl error 60: SSL certificate problem: self-signed certificate in certificate chain` on Windows + +This is a common issue with the latest PHP versions under **Windows OS** (it is related to an incompatibility between Windows and OpenSSL CA's database). + +1. Download this CA database `https://curl.haxx.se/ca/cacert.pem` to `c:/cacert.pem`. +2. Edit your php.ini and add `openssl.cafile=c:/cacert.pem`. (It should point to the file you downloaded.) + +### My host does not allow using Composer + +The PHP SDK requires Composer for maintaining dependencies (external PHP libraries). If Composer is now allowed to be installed globally on your host, you can still install it locally to run on your user shell account. Instructions for this can be found on the Composer website: https://getcomposer.org/doc/00-intro.md#locally + +## Keep reading + +* [PHP Introduction](/libraries/auth0-php) +* [PHP Basic Use](/libraries/auth0-php/basic-use) +* [PHP Authentication API](/libraries/auth0-php/authentication-api) +* [PHP Management API](/libraries/auth0-php/management-api) +* [PHP JWT Validation](/libraries/auth0-php/jwt-validation) diff --git a/fr-ca/articles/libraries/auth0-react/index.md b/fr-ca/articles/libraries/auth0-react/index.md new file mode 100644 index 0000000000..c490c1e05e --- /dev/null +++ b/fr-ca/articles/libraries/auth0-react/index.md @@ -0,0 +1,232 @@ +--- +section: libraries +toc: true +title: Auth0 React SDK +description: Auth0 SDK for React Single Page Applications. +topics: + - libraries + - auth0-react +contentType: + - index +--- + + + +# Auth0 React SDK + + +The Auth0 React SDK is a JavaScript library for implementing authentication & authorization in React apps with Auth0. It provides a custom React hook and other Higher Order Components so you can secure React apps using best practices while writing less code. + +The Auth0 React SDK handles grant and protocol details, token expiration and renewal, as well as token storage and caching. Under the hood, it implements [Universal Login](/universal-login) and the [Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce). + +The library is [hosted on GitHub](https://github.com/auth0/auth0-react) where you can [read more about the API](https://auth0.github.io/auth0-react/). + +## Installation + +Using [npm](https://npmjs.org): + +```sh +npm install @auth0/auth0-react +``` + +Using [yarn](https://yarnpkg.com): + +```sh +yarn add @auth0/auth0-react +``` + +## Getting Started + +First, you'll need to wrap your application in a single `Auth0Provider` component. This will provide the React Context to components that are placed inside your application. + +```jsx +import React from 'react'; +import ReactDOM from 'react-dom'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +ReactDOM.render( + + + , + document.getElementById('app') +); +``` + +Use the `useAuth0` hook in your components to access the React Context's authentication state (`isLoading`, `isAuthenticated` and `user`) and authentication methods (`loginWithRedirect` and `logout`). + +### isLoading and error + +Wait for the SDK to initialise and handle any errors with the `isLoading` and `error` states. + +```jsx +import React from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +function Wrapper({ children }) { + const { + isLoading, + error, + } = useAuth0(); + + if (isLoading) { + return
Loading...
; + } + if (error) { + return
Oops... {error.message}
; + } + return <>{children}; +} + +export default Wrapper; +``` + +### Login + +Use `loginWithRedirect` or `loginWithPopup` to log your users in. + +```jsx +import React from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +function LoginButton() { + const { + isAuthenticated, + loginWithRedirect, + } = useAuth0(); + + return !isAuthenticated && ( + + ); +} + +export default LoginButton; +``` + +### Logout + +Use `logout` to log your users out. Make sure `returnTo` is specified in "Allowed Logout URLs" in your Auth0 Dashboard. + +```jsx +import React from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +function LogoutButton() { + const { + isAuthenticated, + logout, + } = useAuth0(); + + return isAuthenticated && ( + + ); +} + +export default Logout; +``` + +### User + +Access user profile information with the `user` value. + +```jsx +import React from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +function Profile() { + const { user } = useAuth0(); + + return
Hello {user.name}
; +} + +export default Profile; +``` + +### Use with a class component + +Use the `withAuth0` Higher Order Component to add the `auth0` property to class components instead of using the hook. + +```jsx +import React, { Component } from 'react'; +import { withAuth0 } from '@auth0/auth0-react'; + +class Profile extends Component { + render() { + const { user } = this.props.auth0; + return
Hello {user.name}
; + } +} + +export default withAuth0(Profile); +``` + +### Protect a route + +Protect a route component using the `withAuthenticationRequired` higher order component. Visits to this route when unauthenticated will redirect the user to the login page and back to this page after login. + +```jsx +import React from 'react'; +import { withAuthenticationRequired } from '@auth0/auth0-react'; + +const PrivateRoute = () => (
Private
); + +export default withAuthenticationRequired(PrivateRoute, { + // Show a message while the user waits to be redirected to the login page. + onRedirecting: () => (
Redirecting you to the login page...
) +}); +``` + +**Note** If you are using a custom router, you will need to supply the `Auth0Provider` with a custom `onRedirectCallback` method to perform the action that returns the user to the protected page. See examples for [react-router](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-react-router-dom-v6-app), [Gatsby](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-gatsby-app) and [Next.js](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-nextjs-app-in-spa-mode). + +### Call an API + +To call a protected API with an Access Token, be sure to specify the `audience` and `scope` of your access token, either in `Auth0Provider` or `getAccessTokenSilently`. Then use it to call a protected API by passing it in the `Authorization` header of your request. + +```jsx +import React, { useEffect, useState } from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +const Posts = () => { + const { getAccessTokenSilently } = useAuth0(); + const [posts, setPosts] = useState(null); + + useEffect(() => { + (async () => { + try { + const token = await getAccessTokenSilently({ + audience: 'https://api.example.com/', + scope: 'read:posts', + }); + const response = await fetch('https://api.example.com/posts', { + headers: { + Authorization: `Bearer <%= "${token}" %>`, + }, + }); + setPosts(await response.json()); + } catch (e) { + console.error(e); + } + })(); + }, [getAccessTokenSilently]); + + if (!posts) { + return
Loading...
; + } + + return ( +
    + {posts.map((post, index) => { + return
  • {post}
    • ; + })} +
+ ); +}; + +export default Posts; +``` diff --git a/fr-ca/articles/libraries/auth0-spa-js/index.md b/fr-ca/articles/libraries/auth0-spa-js/index.md new file mode 100644 index 0000000000..0055131f0e --- /dev/null +++ b/fr-ca/articles/libraries/auth0-spa-js/index.md @@ -0,0 +1,340 @@ +--- +section: libraries +toc: true +title: Auth0 Single Page App SDK +description: Auth0 SDK for single page applications using Authorization Code Grant Flow with PKCE. +topics: + - libraries + - auth0-spa-js +contentType: + - index +--- + + + +# Auth0 Single Page App SDK + +The Auth0 Single Page App SDK is a new JavaScript library for implementing authentication & authorization in single page apps (SPA) with Auth0. It provides a high-level API and handles a lot of the details so you can secure SPAs using best practices while writing less code. + +The Auth0 SPA SDK handles grant and protocol details, token expiration and renewal, as well as token storage and cacheing. Under the hood, it implements [Universal Login](/universal-login) and the [Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce). + +The library is [hosted on GitHub](https://github.com/auth0/auth0-spa-js) and you can find the API documentation [here](https://auth0.github.io/auth0-spa-js/). + +If your SPA is based on React, check out the [Auth0 React SDK](/libraries/auth0-react). + +<%= include('../_includes/_spa_js_faq.md') %> + +## Installation + +You have a few options for using auth0-spa-js in your project: + +From the CDN: + +```html + +``` + +Using [npm](https://npmjs.org): + +```sh +npm install @auth0/auth0-spa-js +``` + +Using [yarn](https://yarnpkg.com): + +```sh +yarn add @auth0/auth0-spa-js +``` + +## Getting Started + +### Create the client + +First, you'll need to create a new instance of `Auth0Client` client object. Create the `Auth0Client` instance before rendering or initializing your application. You can do this using either the async/await method, or with promises. You should only create one instance of the client. + +```js +import createAuth0Client from '@auth0/auth0-spa-js'; + +// either with async/await +const auth0 = await createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}' +}); +``` + +```js +// or with promises +createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}' +}).then(auth0 => { + //... +}); +``` + +Using `createAuth0Client` does a couple of things automatically: + +* It creates an instance of `Auth0Client`. +* It calls `getTokenSilently` to refresh the user session. +* It suppresses all errors from `getTokenSilently`, except `login_required`. + +You can also create the client directly using the `Auth0Client` constructor. This can be useful if: + +* You wish to bypass the call to `getTokenSilently` on initialization. +* You wish to do custom error handling. +* You wish to initialize the SDK in a synchronous way. + +```js +import { Auth0Client } from '@auth0/auth0-spa-js'; + +const auth0 = new Auth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}' +}); +``` + +### Login and get user info + +Next, create a button users can click to start logging in. + +```html + +``` + +Listen for click events on the button you created. When the event occurs, use the desired login method to authenticate the user (`loginWithRedirect()` in this example). After the user is authenticated, you can retrieve the user profile with the `getUser()` method. + +```js +// either with async/await +document.getElementById('login').addEventListener('click', async () => { + await auth0.loginWithRedirect({ + redirect_uri: 'http://localhost:3000/' + }); + //logged in. you can get the user profile like this: + const user = await auth0.getUser(); + console.log(user); +}); +``` + +```js +// or with promises +document.getElementById('login').addEventListener('click', () => { + auth0.loginWithRedirect({ + redirect_uri: 'http://localhost:3000/' + }).then(token => { + //logged in. you can get the user profile like this: + auth0.getUser().then(user => { + console.log(user); + }); + }); +}); +``` + +### Call an API + +To call your API, start by getting the user's Access Token. Then use the Access Token in your request. In this example the `getTokenSilently` method is used to retrieve the Access Token. + +```html + +``` + +```js +// either with async/await +document.getElementById('callApi').addEventListener('click', async () => { + const accessToken = await auth0.getTokenSilently(); + const result = await fetch('https://exampleco.com/api', { + method: 'GET', + headers: { + Authorization: 'Bearer ' + accessToken + } + }); + const data = await result.json(); + console.log(data); +}); +``` + +```js +// or with promises +document.getElementById('callApi').addEventListener('click', () => { + auth0 + .getTokenSilently() + .then(accessToken => + fetch('https://exampleco.com/api', { + method: 'GET', + headers: { + Authorization: 'Bearer ' + accessToken + } + }) + ) + .then(result => result.json()) + .then(data => { + console.log(data); + }); +}); +``` + +### Logout + +Add a button users can click to logout. + +```html + +``` + +```js +document.getElementById('logout').addEventListener('click', () => { + auth0.logout(); +}); +``` + +### Change storage options + +The Auth0 SPA SDK stores tokens in memory by default. However, this does not provide persistence across page refreshes and browser tabs. Instead, you can opt-in to store tokens in local storage by setting the `cacheLocation` property to `localstorage` when initializing the SDK. This can help to mitigate some of the effects of browser privacy technology that prevents access to the Auth0 session cookie by storing Access Tokens for longer. + +::: warning +Storing tokens in browser local storage provides persistence across page refreshes and browser tabs. However, if an attacker can achieve running JavaScript in the SPA using a cross-site scripting (XSS) attack, they can retrieve the tokens stored in local storage. A vulnerability leading to a successful XSS attack can be either in the SPA source code or in any third-party JavaScript code (such as bootstrap, jQuery, or Google Analytics) included in the SPA. + +Read more about [token storage](/tokens/concepts/token-storage#single-page-app-scenarios). +::: + +```js +const auth0 = await createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}', + cacheLocation: 'localstorage' +}); +``` + +### Use rotating Refresh Tokens + +The Auth0 SPA SDK can be configured to use [rotating Refresh Tokens](/tokens/concepts/refresh-token-rotation) to get new access tokens silently. These can be used to bypass browser privacy technology that prevents access to the Auth0 session cookie when authenticating silently, as well as providing [built-in reuse detection](/tokens/concepts/refresh-token-rotation#automatic-reuse-detection). + +Configure the SDK to do this by setting `useRefreshTokens` to `true` on initialization: + +```js +const auth0 = await createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}', + useRefreshTokens: true +}); + +// Request a new access token using a refresh token +const token = await auth0.getTokenSilently(); +``` + +Refresh Tokens will also need to be [configured for your tenant](/tokens/guides/configure-refresh-token-rotation) before they can be used in your SPA. + +Once configured, the SDK will request the `offline_access` scope during the authorization step. Furthermore, `getTokenSilently` will then call the `/oauth/token` endpoint directly to exchange refresh tokens for access tokens. + +:::note +The SDK will obey the storage configuration when storing refresh tokens. If the SDK has been configured using the default in-memory storage mechanism, refresh tokens will be lost when refreshing the page. +::: + +## Usage + +Below are examples of usage for various methods in the SDK. Note that jQuery is used in these examples. + +### Login with popup + +```js +$('#loginPopup').click(async () => { + await auth0.loginWithPopup(); +}); +``` + +### Login with redirect + +```js +$('#loginRedirect').click(async () => { + await auth0.loginWithRedirect({ + redirect_uri: 'http://localhost:3000/' + }); +}); +``` + +Redirect to the `/authorize` endpoint at Auth0, starting the [Universal Login](/universal-login) flow. + +### Login with redirect callback + +```js +$('#loginRedirectCallback').click(async () => { + await auth0.handleRedirectCallback(); +}); +``` + +### Get Access Token with no interaction + +Get a new Access Token silently using either a hidden iframe and `prompt=none`, or by using a rotating Refresh Token. Refresh Tokens are used when `useRefreshTokens` is set to `true` when configuring the SDK. + +If in-memory storage (the default) and refresh tokens are used, new tokens are retrieved using a web worker on supported browsers. + +```js +$('#getToken').click(async () => { + const token = await auth0.getTokenSilently(); +}); +``` + +The `getTokenSilently()` method requires you to have **Allow Skipping User Consent** enabled in your [API Settings in the Dashboard](${manage_url}/#/apis). Additionally, user consent [cannot be skipped on 'localhost'](/api-auth/user-consent#skipping-consent-for-first-party-applications). + +### Get Access Token with popup + +```js +$('#getTokenPopup').click(async () => { + const token = await auth0.getTokenWithPopup({ + audience: 'https://mydomain/api/', + scope: 'read:rules' + }); +}); +``` + +### Get Access Token for a different audience + +```js +$('#getToken_audience').click(async () => { + const differentAudienceOptions = { + audience: 'https://mydomain/another-api/', + scope: 'read:rules', + redirect_uri: 'http://localhost:3000/callback.html' + }; + const token = await auth0.getTokenSilently(differentAudienceOptions); +}); +``` + +### Get user + +```js +$('#getUser').click(async () => { + const user = await auth0.getUser(); +}); +``` + +### Get ID Token claims + +```js +$('#getIdTokenClaims').click(async () => { + const claims = await auth0.getIdTokenClaims(); + // if you need the raw id_token, you can access it + // using the __raw property + const id_token = claims.__raw; +}); +``` + +### Logout (default) + +```js +$('#logout').click(async () => { + auth0.logout({ + returnTo: 'http://localhost:3000/' + }); +}); +``` + +### Logout with no client ID + +```js +$('#logoutNoClientId').click(async () => { + auth0.logout({ + client_id: null, + returnTo: 'http://localhost:3000/' + }); +}); +``` diff --git a/fr-ca/articles/libraries/auth0-spa-js/migrate-from-auth0js.md b/fr-ca/articles/libraries/auth0-spa-js/migrate-from-auth0js.md new file mode 100644 index 0000000000..40ce0aa180 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-spa-js/migrate-from-auth0js.md @@ -0,0 +1,244 @@ +--- +section: libraries +title: Migrate from Auth0.js to the Auth0 Single Page App SDK +description: How to migrate single page applications from Auth0.js to Auth0 Single Page App SDK +public: false +topics: + - libraries + - auth0-spa-js + - migrations +contentType: + - how-to +useCase: + - migrate +--- + +# Migrate from Auth0.js to the Auth0 Single Page App SDK + +In this article, you’ll see how to migrate your single page app (SPA) from [auth0.js](/libraries/auth0js) to [auth0-spa-js](/libraries/auth0-spa-js). Listed below are scenarios using auth0.js and the equivalent auth0-spa-js code. + +## Functionality that cannot be migrated + +Not all auth0.js functionality can be directly migrated to auth0-spa-js. Scenarios that cannot be directly migrated include: + +- embedded [login with username/password](https://auth0.github.io/auth0.js/global.html#login) as well as embedded [passwordless login](https://auth0.github.io/auth0.js/global.html#passwordlessLogin) +- user [signup](https://auth0.github.io/auth0.js/global.html#signup) +- [get a user profile from /userinfo endpoint](https://auth0.github.io/auth0.js/global.html#userInfo) +- [request an email to change the user's password](https://auth0.github.io/auth0.js/global.html#changePassword) +- [link users with the Management API](https://auth0.github.io/auth0.js/global.html#linkUser) +- [get user with the Management API](https://auth0.github.io/auth0.js/global.html#getUser) +- [update user attributes with the Management API](https://auth0.github.io/auth0.js/global.html#patchUserAttributes) +- [update user metadata with the Management API](https://auth0.github.io/auth0.js/global.html#patchUserMetadata) +- There are also some options that are configurable in Auth0.js that do not have a counterpart in the auth0-spa-js. An example of this is `responseType`. There is a reason that there is not a direct 1:1 mapping for each option. In this case, `responseType` is unnecessary, because the SDK is only for use in SPAs, and so one would not need to change the response type. + +## Authentication Parameters are not modified anymore + +Auth0.js converts custom parameters you set from `camelCase` to `snake_case` internally. For example, if you set `deviceType: 'offline'`, auth0.js actually sends `device_type: 'offline'` to the server. + +When using auth0-spa-js, custom parameters **are not converted** from `camelCase` to `snake_case`. It will relay whatever parameter you send to the authorization server. + +## Create the client + +### auth0.js + +* [WebAuth](https://auth0.github.io/auth0.js/WebAuth.html) + +```js +import { WebAuth } from 'auth0.js'; + +window.addEventListener('load', () => { + var auth0 = new WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + redirectUri: '${account.callback}' + }); +}); +``` + +### auth0-spa-js + +* [createAuth0Client()](https://auth0.github.io/auth0-spa-js/globals.html#createauth0client) +* [Auth0ClientOptions](https://auth0.github.io/auth0-spa-js/interfaces/auth0clientoptions.html) + +```js +import createAuth0Client from '@auth0/auth0-spa-js'; + +window.addEventListener('load', () => { + const auth0 = await createAuth0Client({ + domain: '${account.namespace}', + client_id: '${account.clientId}', + redirect_uri: '${account.callback}' + }); +}); +``` + +## Redirect to the Universal Login Page + +### auth0.js + +* [authorize()](https://auth0.github.io/auth0.js/global.html#authorize) + +```js +document.getElementById('login').addEventListener('click', () => { + auth0.authorize(); +}); +``` + +### auth0-spa-js + +* [Auth0Client.loginWithRedirect()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#loginwithredirect) +* [RedirectLoginOptions](https://auth0.github.io/auth0-spa-js/interfaces/redirectloginoptions.html) + +```js +document.getElementById('login').addEventListener('click', async () => { + await auth0.loginWithRedirect(); +}); +``` + +## Parse the hash after the redirect + +### auth0.js + +* [parseHash()](https://auth0.github.io/auth0.js/global.html#parseHash) + +```js +window.addEventListener('load', () => { + auth0.parseHash({ hash: window.location.hash }, function(err, authResult) { + if (err) { + return console.log(err); + } + console.log(authResult); + }); +}); +``` + +### auth0-spa-js + +* [Auth0Client.handleRedirectCallback()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#handleredirectcallback) + +```js +window.addEventListener('load', async () => { + await auth0.handleRedirectCallback(); +}); +``` + +## Get the user information + +### auth0.js + +The `userInfo()` function makes a call to the [/userinfo endpoint](https://auth0.com/docs/api/authentication#user-profile) and returns the user profile. + +* [userInfo()](https://auth0.github.io/auth0.js/global.html#userInfo) + +```js +window.addEventListener('load', () => { + auth0.client.userInfo(accessToken, function(err, user) { + console.log(user) + }); +}); +``` + +### auth0-spa-js + +Unlike auth0.js, the Auth0 SPA SDK does not call to the [/userinfo endpoint](https://auth0.com/docs/api/authentication#user-profile) for the user profile. Instead `Auth0Client.getUser()` returns user information from the decoded `id_token`. + +* [Auth0Client.getUser()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#getuser) +* [GetUserOptions](https://auth0.github.io/auth0-spa-js/interfaces/getuseroptions.html) + +```js +window.addEventListener('load', async () => { + const user = await auth0.getUser(); + console.log(user); +}); +``` + +## Open the Universal Login Page in a popup + +### auth0.js + +```js +document.getElementById('login').addEventListener('click', () => { + auth0.popup.authorize(); +}); +``` + +### auth0-spa-js + +* [Auth0Client.loginWithPopup()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#loginwithpopup) +* [PopupLoginOptions](https://auth0.github.io/auth0-spa-js/interfaces/popuploginoptions.html) + +```js +document.getElementById('login').addEventListener('click', async () => { + await auth0.loginWithPopup(); +}); +``` + +## Refresh tokens + +### auth0.js + +* [checkSession()](https://auth0.github.io/auth0.js/global.html#checkSession) + +```js +document.getElementById('login').addEventListener('click', () => { + auth0.checkSession({}, function(err, authResult) { + // Authentication tokens or error + }); +}); +``` + +### auth0-spa-js + +The Auth0 SPA SDK handles Access Token refresh for you. Every time you call `getTokenSilently`, you'll either get a valid Access Token or an error if there's no session at Auth0. + +* [Auth0Client.getTokenSilently()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokensilently) + +```js +document.getElementById('login').addEventListener('click', async () => { + await auth0.getTokenSilently(); +}); +``` + +## Get a token for a different audience or with more scopes + +### auth0.js + +* [checkSession()](https://auth0.github.io/auth0.js/global.html#checkSession) + +```js +document.getElementById('login').addEventListener('click', () => { + auth0.checkSession({ + audience: 'https://mydomain/another-api/', + scope: 'read:messages' + }, function(err, authResult) { + // Authentication tokens or error + }); +}); +``` + +### auth0-spa-js + +The Auth0 SPA SDK handles Access Token refresh for you. Every time you call `getTokenSilently`, you'll either get a valid Access Token or an error if there's no session at Auth0. + +* [Auth0Client.getTokenSilently()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokensilently) +* [GetTokenSilentlyOptions](https://auth0.github.io/auth0-spa-js/interfaces/gettokensilentlyoptions.html) + +```js +document.getElementById('login').addEventListener('click', async () => { + await auth0.getTokenSilently({ + audience: 'https://mydomain/another-api/', + scope: 'read:messages' + }); +}); +``` + +Use [getTokenWithPopup](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokenwithpopup) to open a popup and allow the user to consent to the new API: + +```js +document.getElementById('login').addEventListener('click', async () => { + await auth0.getTokenWithPopup({ + audience: 'https://mydomain/another-api/', + scope: 'read:messages' + }); +}); +``` diff --git a/fr-ca/articles/libraries/auth0-swift/database-authentication.md b/fr-ca/articles/libraries/auth0-swift/database-authentication.md new file mode 100644 index 0000000000..039f9467b1 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/database-authentication.md @@ -0,0 +1,64 @@ +--- +section: libraries +toc: true +description: Using database connections with Auth0.Swift +topics: + - libraries + - swift + - db-connections +contentType: how-to +useCase: enable-mobile-auth +--- + +# Using Database Connections with Auth0.Swift + +::: panel-warning Database authentication on Native Platforms +Username/Email & Password authentication from native applications is disabled by default for new tenants as of 8 June 2017. Users are encouraged to use Universal Login and perform Web Authentication instead. If you still want to proceed you'll need to enable the Password Grant Type on your dashboard first. See [Application Grant Types](/applications/concepts/application-grant-types) for more information. +::: + +The Authentication API provides methods to authenticate and sign up database users. + +## Signing up with a database connection + +Signing up requires calling the `createUser` method, passing the user's given `email`, `password`, and the `connection` name to initiate the signup process. You can also specify additional user metadata to store. + +```swift +Auth0 + .authentication() + .createUser( + email: "support@auth0.com", + password: "secret-password", + connection: "Username-Password-Authentication", + userMetadata: ["first_name": "First", + "last_name": "Last"]) + .start { result in + switch result { + case .success(let user): + print("User: \(user)") + case .failure(let error): + print("Failed with \(error)") + } + } +``` + +## Login with a database connection + +Logging in with a database connection requires calling `login` with the user's username/email, password, and the name of the connection (such as `Username-Password-Authentication`) you wish to authenticate with. The response will be a Credentials object. + +```swift +Auth0 + .authentication() + .login( + usernameOrEmail: "support@auth0.com", + password: "secret-password", + realm: "Username-Password-Authentication", + scope: "openid") + .start { result in + switch result { + case .success(let credentials): + print("Credentials: \(credentials)") + case .failure(let error): + print("Failed with \(error)") + } + } +``` diff --git a/fr-ca/articles/libraries/auth0-swift/index.md b/fr-ca/articles/libraries/auth0-swift/index.md new file mode 100644 index 0000000000..bc88fd539e --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/index.md @@ -0,0 +1,243 @@ +--- +section: libraries +toc: true +description: How to install, initialize and use Auth0.Swift +url: /libraries/auth0-swift +topics: + - libraries + - swift +contentType: + - how-to + - index +useCase: enable-mobile-auth +--- + +# Auth0.swift + +Auth0.swift is a client-side library for Auth0. + +::: note +Check out the [Auth0.swift repository](https://github.com/auth0/Auth0.swift) on GitHub. +::: + +## Requirements + +- iOS 9+ / macOS 10.11+ / tvOS 9.0+ / watchOS 2.0+ +- Xcode 11.4+ / 12.x +- Swift 4.x / 5.x + +## Installation + +### Cocoapods + +If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`: + +```ruby +pod 'Auth0', '~> 1.0' +``` + +Then run `pod install`. + +::: note +For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html). +::: + +### Carthage + +If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`: + +```ruby +github "auth0/Auth0.swift" ~> 1.0 +``` + +Then run `carthage bootstrap`. + +::: note +For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). +::: + +### SPM + +If you are using the Swift Package Manager, open the following menu item in Xcode: + +**File > Swift Packages > Add Package Dependency...** + +In the **Choose Package Repository** prompt add this url: + +```text +https://github.com/auth0/Auth0.swift.git +``` + +Then press **Next** and complete the remaining steps. + +::: note +For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app). +::: + +## Adding Auth0 Credentials + +You will need to add an `Auth0.plist` file, containing your Auth0 client id and domain, to your main bundle. Here is an example of the file contents: + +```xml + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` + +### Web-based Auth (iOS / macOS 10.15+) + +First go to [Auth0 Dashboard](${manage_url}/#/applications) and go to application's settings. Make sure you have in **Allowed Callback URLs** a URL with the following format: + +```text +{YOUR_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{YOUR_BUNDLE_IDENTIFIER}/callback +``` + +In your application's `Info.plist` file register your iOS Bundle Identifier as a custom scheme like this: + +```xml +CFBundleURLTypes + + + CFBundleTypeRole + None + CFBundleURLName + auth0 + CFBundleURLSchemes + + {YOUR_BUNDLE_IDENTIFIER} + + + +``` + +::: note +If your `Info.plist` is not shown in this format, you can **Right Click** on `Info.plist` in Xcode and then select **Open As / Source Code**. +::: + +::: note +Auth0.swift will only handle URLs with your Auth0 domain as host, for example `com.auth0.MyApp://samples.auth0.com/ios/com.auth0.MyApp/callback` +::: + +Allow Auth0 to handle authentication callbacks. In your `AppDelegate.swift`, add the following: + +##### iOS + +```swift +func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any]) -> Bool { + return Auth0.resumeAuth(url) +} +``` + +##### macOS + +```swift +func application(_ application: NSApplication, open urls: [URL]) { + Auth0.resumeAuth(urls) +} +``` + +#### Authenticate with Universal Login + +The first step in adding authentication to your application is to provide a way for your users to log in. The fastest, most secure, and most feature-rich way to do this with Auth0 is to use Universal Login. + +::: note +For more information on the two types of login flows, please refer to [Browser-Based vs. Native Login Flows on Mobile Devices](/design/browser-based-vs-native-experience-on-mobile) +::: + +```swift +Auth0 + .webAuth() + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { // Auth0.Result + case .success(let credentials): + print("Credentials: \(credentials)") + case .failure(let error): + print(error) + } + } +``` + +::: warning +If you're using **Swift 5+**, `Auth0.Result` may shadow Swift's `Result` type. To prevent that, replace it with `Swift.Result` whenever you want to refer to Swift's built-in type. This will be fixed in the next major version of Auth0.swift. +::: + +::: note +To ensure a response that complies with OpenID Connect (OIDC), you must either request an `audience` or enable the **OIDC Conformant** switch in your [Auth0 dashboard](${manage_url}), under **Application > Settings > Show Advanced Settings > OAuth**. For more information, refer to [How to use the new flows](/api-auth/tutorials/adoption#how-to-use-the-new-flows). +::: + +#### Authenticate with a specific Auth0 connection + +The `connection` option allows you to specify a connection that you wish to authenticate with. If no connection is specified here, the browser will show the login page, with all of the connections which are enabled for this application. + +```swift +Auth0 + .webAuth() + .connection("facebook") + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { + case .success(let credentials): + print("Credentials: \(credentials)") + case .failure(let error): + print(error) + } + } +``` + +#### Authenticate using a specific scope + +Using scopes can allow you to return specific claims for specific fields in your request. Adding parameters to `scope` will allow you to add more scopes. The default scope is `openid`, and you should read our [documentation on scopes](/scopes/current) for further details about them. + +```swift +Auth0 + .webAuth() + .scope("openid email") + .connection("google-oauth2") + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { + case .success(let credentials): + print("Credentials: \(credentials)") + case .failure(let error): + print(error) + } + } +``` + +### Getting user information + +In order to retrieve a user's profile, you call the `userInfo` method and pass it the user's `accessToken`. Although the call returns a [UserInfo](https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift) instance, this is a basic OIDC conformant profile and the only guaranteed claim is the `sub`, which contains the user's ID. Depending on the requested scope, the claims returned may vary. You can also use the `sub` value to call the [Management API](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) and return a full user profile. + +```swift +Auth0 + .authentication() + .userInfo(withAccessToken: accessToken) + .start { result in + switch result { + case .success(let profile): + print("User Profile: \(profile)") + case .failure(let error): + print("Failed with \(error)") + } + } +``` + +## Next Steps + +Take a look at the following resources to see how the Auth0.swift SDK can be customized for your needs: + +::: next-steps +* [Auth0.Swift Database Authentication](/libraries/auth0-swift/database-authentication) +* [Auth0.Swift Passwordless Authentication](/libraries/auth0-swift/passwordless) +* [Auth0.Swift Refresh Tokens](/libraries/auth0-swift/save-and-refresh-jwt-tokens) +* [Auth0.Swift User Management](/libraries/auth0-swift/user-management) +* [Auth0.Swift Touch ID / Face ID Authentication](/libraries/auth0-swift/touchid-authentication) +::: diff --git a/fr-ca/articles/libraries/auth0-swift/passwordless.md b/fr-ca/articles/libraries/auth0-swift/passwordless.md new file mode 100644 index 0000000000..664f8e8d7f --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/passwordless.md @@ -0,0 +1,109 @@ +--- +section: libraries +toc: true +description: Using Auth0.Swift in passwordless mode +topics: + - libraries + - swift + - passwordless +contentType: how-to +useCase: enable-mobile-auth +--- + +# Passwordless Authentication with Auth0.Swift + +Passwordless authentication allows users to login using only an email address or phone number, reducing the friction that occurs when a user must remember a password. Passwordless authentication can be done via email or via SMS, and either by sending the user a code, or sending them a link which contains a code. + +To use Passwordless Authentication you need Auth0.Swift version `1.20.0` or greater. + +## How Passwordless works + +Passwordless requires two steps: + +1. Request the code +2. Input the code + +When using links, the same thing happens, but in a slightly different way, because the user does not have to input a code themselves. The code is included in the URL. + +### Step 1: Request the code + +In this example, requesting the code is done by calling `startPasswordless` with the user's email, and the type of connection. The `type` parameter will default to `Code`. On success, you'll probably display a notice to the user that their code is on the way, and perhaps route them to a view to input that code. + +```swift +Auth0 + .authentication() + .startPasswordless(email: "support@auth0.com") + .start { result in + switch result { + case .success: + print("Sent OTP to support@auth0.com!") + case .failure(let error): + print(error) + } + } +``` + +### Step 2: Input the code + +Once the user has a code, they can input it. Call the `login` method, and pass in the user's email, the code they received, and the name of the connection in question. Upon success, you will receive a Credentials object in the response. + +```swift +Auth0 + .authentication() + .login( + email: "support@auth0.com", + code: "123456", + audience: "https://myapi.com/api", + scope: "openid email") + .start { result in + switch result { + case .success(let credentials): + print("Access Token: \(credentials.accessToken)") + case .failure(let error): + print(error) + } + } +``` + +If you used SMS, the call would be like: + +```swift +Auth0 + .authentication() + .login( + phoneNumber: "+4591131761367", + code: "123456", + audience: "https://myapi.com/api", + scope: "openid email") + .start { result in + switch result { + case .success(let credentials): + print("Access Token: \(credentials.accessToken)") + case .failure(let error): + print(error) + } + } +``` + +## Passwordless parameters + +Passwordless authentication can be started with a variety of different parameters. + +For example: + +```swift +.startPasswordless(email: String, type: String, connection: String) +``` + +or + +```swift +.startPasswordless(phoneNumber: String, type: String, connection: String) +``` + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `email` | required | (String) Either `email` or `phoneNumber` is required (not both), depending on which will be used. | +| `phoneNumber` | required | (String) Either `email` or `phoneNumber` is required (not both), depending on which will be used. | +| `type` | optional | (String) The type of Passwordless transaction to use, either `.Code` or `.iOSLink`. Defaults to `.Code`. | +| `connection` | optional | (String) The name of the connection to use for the Passwordless authentication. Defaults to `sms` for the SMS overload or to `email` for the email overload | diff --git a/fr-ca/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md b/fr-ca/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md new file mode 100644 index 0000000000..c633a9c650 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md @@ -0,0 +1,135 @@ +--- +section: libraries +description: Keeping your user logged in with Auth0.swift +topics: + - libraries + - swift + - tokens +contentType: how-to +useCase: enable-mobile-auth +--- + +# Auth0.swift Saving and Renewing Tokens + +When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new token without asking for credentials again. + +## Credentials Manager + +[Auth0.swift](https://github.com/auth0/Auth0.swift) provides a utility class to streamline the process of storing and renewing credentials. You can access the `accessToken` or `idToken` properties from the [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) instance. This is the preferred method to manage user credentials. + +First import the `Auth0` module: + +```swift +import Auth0 +``` + +Next present the Universal Login page: + +```swift +let credentialsManager = CredentialsManager(authentication: Auth0.authentication()) + +Auth0 + .webAuth() + .scope("openid profile offline_access") + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { + case .failure(let error): + // Handle error + case .success(let credentials): + // Pass the credentials over to the Credentials Manager + credentialsManager.store(credentials: credentials) + } +} +``` + +::: warning +The Keychain items do not get deleted after your app is uninstalled. We recommend to always clear all of your app's Keychain items on first launch. +::: + +### Credentials Check + +It can be useful to perform a quick sanity check to ensure that you have valid credentials stored in the manager. If not, the user can then be directed to authenticate. + +```swift +guard credentialsManager.hasValid() else { + // Present login screen +} +``` + +### Retrieving User Credentials + +You can retrieve the user's credentials as follows: + +```swift +credentialsManager.credentials { error, credentials in + guard error == nil, let credentials = credentials else { + // Handle error, present login page + } + // Valid credentials; you can access token properties such as `idToken`, `accessToken`. +} +``` + +::: note +Renewing a user's credentials works exactly the same way if the token has expired. The Credentials Manager will automatically renew the credentials, store the renewed credentials to the Keychain, then return them in the closure. +::: + +## Alternative Method - SimpleKeychain + +If you are familiar with Lock v1, you may already be using the [SimpleKeychain](https://github.com/auth0/SimpleKeychain) SDK to handle iOS Keychain read/write access. This section is for developers who would prefer to keep using the SimpleKeychain and not upgrade to the preferred Credentials Manager. + +The first thing you will do is store the tokens you need. In this case, you will store the `access_token` and `refresh_token` in the Keychain after a successful authentication. + +```swift +let keychain = A0SimpleKeychain(service: "Auth0") + +Auth0 + .webAuth() + .scope("openid profile offline_access") + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { + case .failure(let error): + // Handle error + case .success(let credentials): + guard let accessToken = credentials.accessToken, + let refreshToken = credentials.refreshToken else { + // Handle error + return + } + keychain.setString(accessToken, forKey: "access_token") + keychain.setString(refreshToken, forKey: "refresh_token") + // You might want to route to a user profile screen at this point + } +} +``` + +Once you have those stored, you can at any point request a fresh [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) instance. + +### Renewing User Credentials + +```swift +let keychain = A0SimpleKeychain(service: "Auth0") + +Auth0 + .authentication() + .renew(withRefreshToken: refreshToken) + .start { result in + switch(result) { + case .success(let credentials): + // If you have Refresh Token Rotation enabled, you get a new Refresh Token + // Otherwise you only get a new Access Token + guard let accessToken = credentials.accessToken, + let refreshToken = credentials.refreshToken else { + // Handle error + return + } + // Store the new tokens + keychain.setString(accessToken, forKey: "access_token") + keychain.setString(refreshToken, forKey: "refresh_token") + case .failure(let error): + keychain.clearAll() + // Handle error + } +} +``` diff --git a/fr-ca/articles/libraries/auth0-swift/touchid-authentication.md b/fr-ca/articles/libraries/auth0-swift/touchid-authentication.md new file mode 100644 index 0000000000..e86bcad058 --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/touchid-authentication.md @@ -0,0 +1,85 @@ +--- +section: libraries +description: How to implement Touch ID / Face ID authentication with Auth0.swift. +topics: + - libraries + - swift + - touch-id + - face-id +contentType: how-to +useCase: enable-mobile-auth +--- + +# Auth0.swift Touch ID / Face ID Authentication + +Here's the scenario: After user authentication, you want to store the user's credentials and use them as long as they are valid. Once they expire, you would want to renew them using the `refreshToken` in order to avoid presenting the login page again. Rather than doing this automatically, you require the user to validate with their fingerprint or face. + +You will be using the [Credentials Manager](https://github.com/auth0/Auth0.swift/blob/master/Auth0/CredentialsManager.swift) utility in [Auth0.swift](https://github.com/auth0/Auth0.swift/) to streamline the management of user credentials and perform biometric authentication. + +## Getting Started + +First, import the `Auth0` module: + +```swift +import Auth0 +``` + +### Credentials Manager + +Before retrieving credentials, you can also engage the biometric authentication (Face ID or Touch ID) supported by your iOS device. + +Begin by setting up the Credentials Manager. Then enable biometrics. You can also pass in a title to show in the prompt. + +```swift +var credentialsManager = CredentialsManager(authentication: Auth0.authentication()) +credentialsManager.enableBiometrics(withTitle: "Touch ID / Face ID Login") +``` + +We strongly recommend that you add the [NSFaceIDUsageDescription](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW75) setting to your project's `Info.plist` to display a reason for using Face ID. In some cases, if you do not provide a description string and the user attempts Face ID authentication, the user's attempt may fail. + +```xml +... +NSFaceIDUsageDescription +Reason why we use Face ID here +... +``` + +### Login + +Present the Universal Login page and, upon successful authentication, pass the credentials to the Credentials Manager. + +```swift +Auth0 + .webAuth() + .scope("openid profile offline_access") + .audience("https://${account.namespace}/userinfo") + .start { result in + switch result { + case .failure(let error): + // Handle error + case .success(let credentials): + // Store credentials securely with the Credentials Manager + credentialsManager.store(credentials: credentials) + } +} +``` + +### Renew User Credentials + +When you need to renew the user's credentials, you can call the `credentials` method from the Credentials Manager. + +```swift +credentialsManager.credentials { error, credentials in + guard error == nil, let credentials = credentials else { + // Handle error + // Fallback to login screen + } + // Continue routing the user as authentication was successful +} +``` + +There is no need manually store the new credentials as this is handled by the Credentials Manager during the renewal. + +## Next Steps + +You can download a sample project and follow the instructions in the iOS quickstart section on [Touch ID / Face ID in iOS](/quickstart/native/ios-swift/08-touch-id-authentication). diff --git a/fr-ca/articles/libraries/auth0-swift/user-management.md b/fr-ca/articles/libraries/auth0-swift/user-management.md new file mode 100644 index 0000000000..c2ad08deab --- /dev/null +++ b/fr-ca/articles/libraries/auth0-swift/user-management.md @@ -0,0 +1,92 @@ +--- +section: libraries +toc: true +description: User Management with Auth0.Swift +topics: + - libraries + - swift + - users +contentType: how-to +useCase: enable-mobile-auth +--- + +# User Management with Auth0.Swift + +The Management API provides [User Account Linking](/users/concepts/overview-user-account-linking), which allows you to link and unlink separate user accounts from different providers, tying them to a single profile. It also allows you to update user metadata and other profile information. + +## Link users + +Linking user accounts will allow a user to authenticate from any of their accounts and, no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish for a user's accounts to be linked, this is the way to go. + +The `link` method accepts two parameters: the primary profile's user ID and the secondary profile's Access Token (the token obtained after login with this identity). The user ID in question is the unique identifier for this user account. If the ID is in the format `facebook|1234567890`, the ID required is the portion after the delimiting pipe (in this case, `1234567890`). + +```swift +Auth0 + .users(token: "user-scoped access token") + .link(userId, withOtherUserToken: "another user token") + .start { result in + switch result { + case .success(let userInfo): + print("User: \(userInfo)") + case .failure(let error): + print(error) + } + } +``` + +## Unlink users + +Unlinking users is a similar process to linking users. The `unlink` method takes three parameters: the secondary profile's user ID, the secondary profile's provider (the connection's identity provider), and the primary profile's user ID. +The parameters read, essentially: "Unlink this **secondary user** (with this **provider**) from this **primary user**". + +```swift +Auth0 + .users(token: "user-scoped access token") + .unlink(identityId: identifier, provider: provider, fromUserId:userId) + .start { result in + switch result { + case .success(let userInfo): + print("User: \(userInfo)") + case .failure(let error): + print(error) + } + } +``` + +::: note +Note that when accounts are linked, the metadata from the secondary account's profile is not merged with the metadata from the primary account's profile. Similarly, when unlinking accounts, the secondary account's profile does not retain metadata from the primary account's profile. +::: + +## Retrieve user metadata + +```swift +Auth0 + .users(token: "user-scoped access token") + .get(userId, fields: ["user_metadata"], include: true) + .start { result in + switch result { + case .success(let userInfo): + print("User: \(userInfo)") + case .failure(let error): + print(error) + } + } +``` + +## Update user metadata + +When updating user metadata, you will create a `userMetadata` object and then call the `patch` method, passing it the user ID and the `userMetadata` object. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata. + +```swift +Auth0 + .users(token: "user-scoped access token") + .patch("user identifier", userMetadata: ["first_name": "John", "last_name": "Doe"]) + .start { result in + switch result { + case .success(let userInfo): + print("User: \(userInfo)") + case .failure(let error): + print(error) + } + } +``` diff --git a/fr-ca/articles/libraries/auth0js/index.yml b/fr-ca/articles/libraries/auth0js/index.yml new file mode 100644 index 0000000000..44a74ecb88 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/index.yml @@ -0,0 +1,7 @@ +versioning: + baseUrl: libraries/auth0js + current: v9 + versions: + - v9 + defaultArticles: + v9: index diff --git a/fr-ca/articles/libraries/auth0js/v9/index.md b/fr-ca/articles/libraries/auth0js/v9/index.md new file mode 100644 index 0000000000..4366c9d400 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/index.md @@ -0,0 +1,580 @@ +--- +section: libraries +toc: true +title: auth0.js v9 Reference +description: How to install, initialize and use auth0.js v9 +topics: + - libraries + - auth0js +contentType: + - index + - how-to +useCase: add-login +--- +# auth0.js v9 Reference + +auth0.js is a client-side library for Auth0. It is recommended for use in single-page apps, preferably in conjunction with [Universal Login](/universal-login), which should be used whenever possible. Using auth0.js in your SPA makes it easier to do authentication and authorization with Auth0. + +The full API documentation for the library is [here](https://auth0.github.io/auth0.js/index.html). + +<%= include('../../../_includes/_embedded_login_warning') %> + +## Ready-to-go example + +The [example directory](https://github.com/auth0/auth0.js/tree/master/example) of the auth0.js library is a ready-to-go app that can help you to quickly and easily try out auth0.js. In order to run it, follow these quick steps: + +1. If you don't have [node](http://nodejs.org/) installed, do that now +1. Download dependencies by running `npm install` from the root of this project +1. Finally, execute `npm start` from the root of this project, and then browse to your app running on the node server, presumably at `http://localhost:3000/example`. + +## Setup and initialization + +Now, let's get started integrating auth0.js into your project. We'll cover [methods of installation](#installation-options), [how to initialize auth0.js](#initialization), [signup](#signup), [login](#login), [logout](#logout), and more! + +<%= include('../../_includes/_configure_embedded_login', { library: 'Auth0.js v9' }) %> + + +### Installation options + +You have a few options for using auth0.js in your project. Pick one of the below depending on your needs: + +Install via [npm](https://npmjs.org) or [yarn](https://yarnpkg.com): + +```sh +npm install auth0-js + +yarn add auth0-js +``` + +Include via our CDN: + +```html + +``` + +If you are using a bundler, you will want to install with `npm i auth0-js --production --save`. + +### Initialization + +Initialize a new instance of the Auth0 application as follows: + +```html + +``` + +#### Available parameters + +There are two required parameters that must be passed in the `options` object when instantiating `webAuth`, and more that are optional. + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `domain` | required | (String) Your Auth0 account domain (ex. myaccount.auth0.com) | +| `clientID` | required | (String) Your Auth0 client ID | +| `redirectUri` | optional* | (String) The default `redirectUri` used. Defaults to an empty string (none). **If you do not provide a global `redirectUri` value here, you will need to provide a redirectUri value for *each* method you use.** | +| `scope` | optional | (String) The default scope(s) used by the application. Using scopes can allow you to return specific claims for specific fields in your request. You should read our [documentation on scopes](/scopes) for further details. | +| `audience` | optional | (String) The default audience to be used for requesting API access. | +| `responseType` | optional* | (String) The default `responseType` used. It can be any space separated list of the values `code`, `token`, `id_token`. It defaults to `'token'`, unless a `redirectUri` is provided, then it defaults to `'code'`. **If you do not provide a global `responseType` value, you will need to provide a `responseType` value for *each* method you use.** | +| `responseMode` | optional | (String) This option is omitted by default. Can be set to `'form_post'` in order to send the token or code to the `'redirectUri'` via POST. Supported values are `query`, `fragment` and `form_post`. | +| `leeway` | optional | (Integer) A value in seconds; leeway to allow for clock skew with regard to ID Token expiration times. | +| `_disableDeprecationWarnings` | optional | (Boolean) Disables the deprecation warnings, defaults to `false`. | + +::: note +Because of clock skew issues, you may occasionally encounter the error `The token was issued in the future`. The `leeway` parameter can be used to allow a few seconds of leeway to ID Token expiration times, to prevent that from occurring. +::: + +##### Scope + +The default `scope` value in auth0.js v9 is `openid profile email`. + +::: panel Running auth0.js Locally +If you don't specify at least the above scope when initializing auth0.js, and you are running your website from `http://localhost` or `http://127.0.0.1`, calling the `getSSOData()` method will result in the following error in the browser console: + +`Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email` + +That will not happen when you run your application in production or if you specify the `openid profile email` scope. You can read more about this in the [User consent and third-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications) document. +::: + +## Login + +You can choose a method for login based on the type of auth you need in your application. + +### webAuth.authorize() + +The `authorize()` method can be used for logging in users via Universal Login, or via social connections, as exhibited in the examples below. This method invokes the [/authorize endpoint](/api/authentication?javascript#social) of the Authentication API, and can take a variety of parameters via the `options` object. + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `audience` | optional | (String) The default audience to be used for requesting API access. | +| `connection` | optional | (String) Specifies the connection to use rather than presenting all connections available to the application. | +| `scope` | optional | (String) The scopes which you want to request authorization for. These must be separated by a space. You can request any of the standard OIDC scopes about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. | +| `responseType` | optional | (String) It can be any space separated list of the values `code`, `token`, `id_token`. It defaults to `'token'`, unless a `redirectUri` is provided, then it defaults to `'code'`. | +| `clientID` | optional | (String) Your Auth0 client ID. | +| `redirectUri` | optional | (String) The URL to which Auth0 will redirect the browser after authorization has been granted for the user. | +| `state` | optional | (String) An arbitrary value that should be maintained across redirects. It is useful to mitigate CSRF attacks and for any contextual information (for example, a return URL) that you might need after the authentication process is finished. For more information, see [State Parameter](/protocols/oauth2/oauth-state). auth0.js, when used in single-page applications, handles the state generation and validation automatically if not specified. | +| `prompt` | optional | (String) A value of `login` will force the login page to show regardless of current session. A value of `none` will attempt to bypass the login prompts if a session already exists (see the [silent authentication](/sso/current/single-page-apps#silent-authentication) documentation for more details). | + +For hosted login, one must call the `authorize()` method. + +```js +webAuth.authorize({ + //Any additional options can go here +}); +``` + +For social logins, the `connection` parameter will need to be specified: + +```js +webAuth.authorize({ + connection: 'twitter' +}); +``` + +### webAuth.popup.authorize() + +For popup authentication the `popup.authorize` method can be used. + +Hosted login with popup: + +```js +webAuth.popup.authorize({ + redirectUri: 'https://YOUR_APP/popup_response_handler.html' + //Any additional options can go here +}, function(err, authResult) { + //do something +}); +``` + +And for social login with popup using `authorize`: + +```js +webAuth.popup.authorize({ + redirectUri: 'https://YOUR_APP/popup_response_handler.html', + connection: 'twitter' +}, function(err, authResult) { + //do something +}); +``` + +#### Handling popup authentication results + +When using popup authentication, you'll have to provide a `redirectUri` where the destination page communicates the authorization results back to the callback by using the `webAuth.popup.callback` method. A simple implementation would be something like this: + +```HTML + + + + + + + +``` + +An ideal handler would contain just this minimal functionality (i.e. avoid reloading the whole application just to handle the response). +You will need to add the `redirectUri` to the application's **Allowed Callback URLs** list in the application configuration page on the Dashboard. + +### webAuth.login() + +<%= include('../../../_includes/_embedded_login_warning') %> + +The `login` method allows for [cross-origin authentication](/cross-origin-authentication) for database connections, using `/co/authenticate`. + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `username` | optional | (String) The username to present for authentication. **Either** `username` or `email` must be present. | +| `email` | optional | (String) The email to present for authentication. **Either** `username` or `email` must be present.| +| `password` | required | (String) The password to present for authentication. | +| `realm` | required | (String) The name of the database connection against which to authenticate. See [realm documentation](/api-auth/tutorials/password-grant#realm-support) for more information | + +```js +webAuth.login({ + realm: 'tests', + username: 'testuser', + password: 'testpass', +}); +``` + +### webAuth.crossOriginVerification() + +The `crossOriginVerification()` method can be used to help provide cross-origin authentication to customers who have third-party cookies disabled in their browsers. Further details about its usage can be read in the [cross-origin authentication](/cross-origin-authentication#create-a-cross-origin-fallback-page) document. + +### buildAuthorizeUrl(options) + +The `buildAuthorizeUrl` method can be used to build the `/authorize` URL, in order to initialize a new transaction. Use this method if you want to implement browser based (passive) authentication. + +```js +// Calculate URL to redirect to +var url = webAuth.client.buildAuthorizeUrl({ + clientID: '${account.clientId}', // string + responseType: 'token id_token', // code + redirectUri: '${account.callback}', + state: 'YOUR_STATE', + nonce: 'YOUR_NONCE' +}); + +// Redirect to url +// ... +``` + +::: note +The `state` parameter is an opaque value that Auth0 will send back to you. This method helps prevent CSRF attacks, and it needs to be specified if you redirect to the URL yourself instead of calling `webAuth.authorize()`. For more information, see [State Parameter](/protocols/oauth2/oauth-state). +::: + +<%= include('../../_includes/_embedded_sso') %> + +## Passwordless login + +Passwordless authentication allows users to log in by receiving a one-time password via email or text message. The process will require you to start the Passwordless process, generating and dispatching a code to the user, (or a code within a link), followed by accepting their credentials via the verification method. That could happen in the form of a login screen which asks for their (email or phone number) and the code you just sent them. It could also be implemented in the form of a Passwordless link instead of a code sent to the user. They would simply click the link in their email or text and it would hit your endpoint and verify this data automatically using the same verification method (just without manual entry of a code by the user). + +In order to use Passwordless, you will want to initialize auth0.js with a `redirectUri` and to set the `responseType: 'token'`. + +```js +var webAuth = new auth0.WebAuth({ + clientID: '${account.clientId}', + domain: '${account.namespace}', + redirectUri: 'http://example.com', + responseType: 'token id_token' +}); +``` + +### Start passwordless + +The first step in Passwordless authentication with auth0.js is the `passwordlessStart` method, which has several parameters which can be passed within its `options` object: + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `connection` | required | (String) Specifies how to send the code/link to the user. Value must be either `email` or `sms`. | +| `send` | required | (String) Value must be either `code` or `link`. If `null`, a link will be sent. | +| `phoneNumber` | optional | (String) The user's phone number for delivery of a code or link via SMS. | +| `email` | optional | (String) The user's email for delivery of a code or link via email. | + +Note that exactly _one_ of the optional `phoneNumber` and `email` parameters must be sent in order to start the Passwordless transaction. + +```js +webAuth.passwordlessStart({ + connection: 'email', + send: 'code', + email: 'foo@bar.com' + }, function (err,res) { + // handle errors or continue + } +); +``` + +### Passwordless Login + +If sending a code, you will then need to prompt the user to enter that code. You will process the code, and authenticate the user, with the `passwordlessLogin` method, which has several parameters which can be sent in its `options` object: + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `connection` | required | (String) Specifies how to send the code/link to the user. Value must be either `email` or `sms` and the same as the value passed to `passwordlessStart`. | +| `verificationCode` | required | (String) The code sent to the user, either as a code or embedded in a link. | +| `phoneNumber` | optional | (String) The user's phone number to which the code or link was delivered via SMS. | +| `email` | optional | (String) The user's email to which the code or link was delivered via email. | + +As with `passwordlessStart`, exactly _one_ of the optional `phoneNumber` and `email` parameters must be sent in order to verify the Passwordless transaction. + +::: note +In order to use `passwordlessLogin`, the options `redirectUri` and `responseType` must be specified when first initializing WebAuth. +::: + +```js +webAuth.passwordlessLogin({ + connection: 'email', + email: 'foo@bar.com', + verificationCode: '389945' + }, function (err,res) { + // handle errors or continue + } +); +``` + +## Extract the authResult and get user info + +After authentication occurs, you can use the `parseHash` method to parse a URL hash fragment when the user is redirected back to your application in order to extract the result of an Auth0 authentication response. You may choose to handle this in a callback page that will then redirect to your main application, or in-page, as the situation dictates. + +The `parseHash` method takes an `options` object that contains the following parameters: + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `state` | optional | (String) An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value is used by auth0.js to prevent CSRF attacks. | +| `nonce` | optional | (String) Used to verify the ID Token +| `hash` | optional | (String) The URL hash (if not provided, `window.location.hash` will be used by default) | + +The contents of the authResult object returned by `parseHash` depend upon which authentication parameters were used. It can include: + +| **Item** | **Description** | +| --- | --- | +| `accessToken` | An Access Token for the API, specified by the `audience` | +| `expiresIn` | A string containing the expiration time (in seconds) of the `accessToken` | +| `idToken` | An ID Token JWT containing user profile information | + +```js +webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) { + if (err) { + return console.log(err); + } + + webAuth.client.userInfo(authResult.accessToken, function(err, user) { + // Now you have the user's information + }); +}); +``` + +As shown above, the `client.userInfo` method can be called passing the returned `accessToken`. It will make a request to the `/userinfo` endpoint and return the `user` object, which contains the user's information, formatted similarly to the below example. + +```json +{ + "sub": "auth0|123456789012345678901234", + "nickname": "johnfoo", + "name": "johnfoo@gmail.com", + "picture": "https://gravatar.com/avatar/example.png", + "updated_at": "2018-05-07T14:16:52.013Z", + "email": "johnfoo@gmail.com", + "email_verified": "false" +} +``` + +You can now do something else with this information as your application needs, such as acquire the user's entire set of profile information with the Management API, as described below. + +## Using nonces + +By default (and if `responseType` contains `id_token`), `auth0.js` will generate a random `nonce` when you call `webAuth.authorize`, store it in local storage, and pull it out in `webAuth.parseHash`. The default behavior should work in most cases, but some use cases may require a developer to control the `nonce`. +If you want to use a developer generated `nonce`, then you must provide it as an option to both `webAuth.authorize` and `webAuth.parseHash`. + +```js +webAuth.authorize({nonce: '1234', responseType: 'token id_token'}); +webAuth.parseHash({nonce: '1234'}, callback); +``` + +If you're calling `webAuth.checkSession` instead of `webAuth.authorize`, then you only have to specify your custom `nonce` as an option to `checkSession`: + +```js +webAuth.checkSession({ + nonce: '1234', +}, function (err, authResult) { + ... +}); +``` + +The `webAuth.checkSession` method will automatically verify that the returned ID Token's `nonce` claim is the same as the option. + +<%= include('../../../_includes/_co_authenticate_errors', { library : 'Auth0.js v9'}) %> + +## Logout + +To log out a user, use the `logout` method. This method accepts an options object, which can include the following parameters. + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `returnTo` | optional | (String) URL to redirect the user to after the logout. | +| `clientID` | optional | (String) Your Auth0 client ID | +| `federated` | optional | (Querystring parameter) Add this querystring parameter to the logout URL, to log the user out of their identity provider, as well: `https://${account.namespace}/v2/logout?federated`. | + +::: panel returnTo parameter +Note that if the `clientID` parameter is included, the `returnTo` URL that is provided must be listed in the Application's **Allowed Logout URLs** in the [Auth0 dashboard](${manage_url}). However, if the `clientID` parameter _is not_ included, the `returnTo` URL must be listed in the **Allowed Logout URLs** at the *account level* in the [Auth0 dashboard](${manage_url}). +::: + +```js +webAuth.logout({ + returnTo: 'some url here', + clientID: 'some client ID here' +}); +``` + +## Signup + +To sign up a user, use the `signup` method. This method accepts an options object, which can include the following parameters. + +| **Parameter** | **Required** | **Description** | +| --- | --- | --- | +| `email` | required | (String) User's email address | +| `password` | required | (String) User's desired password | +| `username` | required\* | (String) User's desired username.
\*Required if you use a database connection and you have enabled **Requires Username** | +| `connection` | required | (String) The database connection name on your application upon which to attempt user account creation | +| `user_metadata` | optional | (JSON object) Additional attributes used for user information. Will be stored in [user_metadata](/users/concepts/overview-user-metadata) | + +Signups should be for database connections. Here is an example of the `signup` method and some sample code for a form. + +```html +

Signup Database Connection

+ + + + +``` + +## Using checkSession to acquire new tokens + +The `checkSession` method allows you to acquire a new token from Auth0 for a user who is already authenticated against Auth0 for your domain. The method accepts any valid OAuth2 parameters that would normally be sent to `authorize`. If you omit them, it will use the ones provided when initializing Auth0. + +The call to `checkSession` can be used to get a new token for the API that was specified as the audience when `webAuth` was initialized: + +```js +webAuth.checkSession({}, function (err, authResult) { + // err if automatic parseHash fails + ... +}); +``` + +See [Extract the AuthResult and Get User Info](#extract-the-authresult-and-get-user-info) for the format of `authResult`. + +Or, the token can be acquired for a different API than the one used when initializing `webAuth` by specifying an `audience` and `scope`: + +```js +webAuth.checkSession( + { + audience: `https://mydomain/another-api/˜`, + scope: 'read:messages' + }, function (err, authResult) { + // err if automatic parseHash fails + ... +}); +``` + +::: note +Note that `checkSession()` triggers any [rules](/rules) you may have set up, so you should check on your rules in the [Dashboard](${manage_url}/#/rules) prior to using it. +::: + +The actual redirect to `/authorize` happens inside an iframe, so it will not reload your application or redirect away from it. + +However, the browser **must** have third-party cookies enabled. Otherwise, **checkSession()** is unable to access the current user's session (making it impossible to obtain a new token without displaying anything to the user). The same will happen if users have [Safari's ITP enabled](/api-auth/token-renewal-in-safari). + +Remember to add the URL where the authorization request originates from, to the **Allowed Web Origins** list of your Auth0 application in the [Dashboard](${manage_url}) under your application's **Settings**. + +::: warning +If the connection is a social connection and you are using Auth0 dev keys, the `checkSession` call will always return `login_required`. +::: + +### Polling with checkSession() + +<%= include('../../../_includes/_checksession_polling') %> + +## Password reset requests + +If attempting to set up a password reset functionality, you'll use the `changePassword` method and pass in an "options" object, with a "connection" parameter and an "email" parameter. + +```js + $('.change_password').click(function () { + webAuth.changePassword({ + connection: 'db-conn', + email: 'foo@bar.com' + }, function (err, resp) { + if(err){ + console.log(err.message); + }else{ + console.log(resp); + } + }); + }); +``` + +The user will then receive an email which will contain a link that they can follow to reset their password. + +## User management + +The Management API provides functionality that allows you to link and unlink separate user accounts from different providers, tying them to a single profile (See [User Account Linking](/users/concepts/overview-user-account-linking) for details.) It also allows you to update user metadata. + +To get started, you first need to obtain a an Access Token that can be used to call the Management API. You can do it by specifying the `https://${account.namespace}/api/v2/` audience when initializing auth0.js, in which case you will get the Access Token as part of the authentication flow. + +::: note +If you use [custom domains](/custom-domains), you will need to instantiate a new copy of `webAuth` using your Auth0 domain rather than your custom one, for use with the Management API calls, as it only works with Auth0 domains. +::: + +```js +var webAuth = new auth0.WebAuth({ + clientID: '${account.clientId}', + domain: '${account.namespace}', + redirectUri: 'http://example.com', + audience: `https://${account.namespace}/api/v2/`, + scope: 'read:current_user', + responseType: 'token id_token' +}); +``` + +You can also do so by using `checkSession()`: + +``` +webAuth.checkSession( + { + audience: `https://${account.namespace}/api/v2/`, + scope: 'read:current_user' + }, function(err, result) { + // use result.accessToken + } +); +``` + +You must specify the specific scopes you need. You can ask for the following scopes: + +* `read:current_user` +* `update:current_user_identities` +* `create:current_user_metadata` +* `update:current_user_metadata` +* `delete:current_user_metadata` +* `create:current_user_device_credentials` +* `delete:current_user_device_credentials` + +Once you have the Access Token, you can create a new `auth0.Management` instance by passing it the account's Auth0 domain, and the Access Token. + +```js +var auth0Manage = new auth0.Management({ + domain: '${account.namespace}', + token: 'ACCESS_TOKEN' +}); +``` + +### Getting the user profile + +In order to get the user profile data, use the `getUser()` method, with the `userId` and a callback as parameters. The method returns the user profile. Note that the `userID` required here will be the same one fetched from the `client.userInfo` method. + +```js +auth0Manage.getUser(userId, cb); +``` + +### Updating the user profile + +When updating user metadata, you will need to first create a `userMetadata` object, and then call the `patchUserMetadata` method, passing it the user id and the `userMetadata` object you created. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata. See the [Metadata](/users/concepts/overview-user-metadata) documentation for more details on user metadata. + +```js +auth0Manage.patchUserMetadata(userId, userMetadata, cb); +``` + +### Linking users + +Linking user accounts will allow a user to authenticate from any of their accounts and no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish a user's accounts to be linked, this is the way to go. + +The `linkUser` method accepts two parameters, the primary `userId` and the secondary user's ID Token (the token obtained after login with this identity). The user ID in question is the unique identifier for the primary user account. The ID should be passed with the provider prefix, e.g., `auth0|1234567890` or `facebook|1234567890`, when using this method. See [User Account Linking](/users/concepts/overview-user-account-linking) for details. + +```js +auth0Manage.linkUser(userId, secondaryUserToken, cb); +``` + +After linking the accounts, the second account will no longer exist as a separate entry in the user database, and will only be accessible as part of the primary one. + +::: note +Note that when accounts are linked, the secondary account's metadata is **not** merged with the primary account's metadata, and if they are ever unlinked, the secondary account will likewise not retain the primary account's metadata when it becomes separate again. +::: diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-angular.md b/fr-ca/articles/libraries/auth0js/v9/migration-angular.md new file mode 100644 index 0000000000..ee64ca6012 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-angular.md @@ -0,0 +1,21 @@ +--- +section: libraries +title: Migrating Angular applications to Auth0.js v9 +description: How to migrate Angular applications to Auth0.js v9 +public: false +topics: + - libraries + - auth0js + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 2+ Applications to Auth0.js v9 + +Angular 2+ applications can use auth0.js directly without any kind of wrapper library. + +All Angular 2+ applications will be using auth0.js v8, so you can follow the [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9) guide. diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v6.md b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v6.md new file mode 100644 index 0000000000..b87b3568e6 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v6.md @@ -0,0 +1,22 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications From auth0.js v6 to v9 +description: How to migrate Angular 1.x Applications From auth0.js v6 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x applications from Auth0.js v6 to v9 + +The [auth0.js](/libraries/auth0js) v6 API is the same as the v7 one. + +You can use the [Migrating Angular 1.x Applications from Auth0.js v7 to v9](/libraries/auth0js/v9/migration-angular-v7) to understand how your application code needs to be adjusted. diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v7.md b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v7.md new file mode 100644 index 0000000000..6020f63d6c --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v7.md @@ -0,0 +1,51 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications From auth0.js v7 to v9 +description: How to migrate Angular 1.x Applications From auth0.js v7 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x applications from Auth0.js v7 to v9 + +This guide includes all the information you need to update auth0.js from v7 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide). + +## Migration Steps + +### Update angular-auth0 + +Angular 1.x applications usually use the [angular-auth0 package](https://www.npmjs.com/package/angular-auth0)when authenticating with Auth0. If you are using auth0.js v7, you should be using the v1 of that package. To use auth0.js v9 you need to update to the latest version (3.x). + +You can update the angular-auth0 library using npm or yarn. + +```bash +# installation with npm +npm install --save angular-auth0 + +# installation with yarn +yarn add angular-auth0 +``` + +The script files need to be added to your build system, or added to the project with a script tag. + +```html + +``` + +<%= include('../../_includes/_get_auth0_js_latest_version') %> + +### Next steps + +The angular-auth0 library is just a thin wrapper over auth0.js, so you will need to adjust your code in the same way you do it when migrating a non-Angular project. + +You can find instructions on how to do it in the [How to migrate from Auth0.js v7 to v9](/libraries/auth0js/v9/migration-v7-v9). + diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v8.md b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v8.md new file mode 100644 index 0000000000..edea9b70ee --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-angularjs-v8.md @@ -0,0 +1,51 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications From auth0.js v8 to v9 +description: How to migrate Angular 1.x Applications From auth0.js v8 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x applications from Auth0.js v8 to v9 + +This guide includes all the information you need to update auth0.js from v8 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide). + +## Migration steps + +### Update angular-auth0 + +Angular 1.x applications usually use the [angular-auth0 package](https://www.npmjs.com/package/angular-auth0)when authenticating with Auth0. To use auth0.js v9 you need to update to the latest version (3.x). + +You can update the angular-auth0 library using npm or yarn. + +```bash +# installation with npm +npm install --save angular-auth0 + +# installation with yarn +yarn add angular-auth0 +``` + +The script files need to be added to your build system, or added to the project with a script tag. + +```html + +``` + +<%= include('../../_includes/_get_auth0_js_latest_version') %> +<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %> +<%= include('../../_includes/_change_get_profile') %> +<%= include('../../_includes/_review_get_ssodata') %> + +## Behavioral changes + +<%= include('../../_includes/_default_values') %> diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-guide.md b/fr-ca/articles/libraries/auth0js/v9/migration-guide.md new file mode 100644 index 0000000000..51c3f7a950 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-guide.md @@ -0,0 +1,55 @@ +--- +section: libraries +title: Migrating to Auth0.js v9 +description: How to migrate to Auth0.js v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating to Auth0.js v9 + +[Auth0.js v9](/libraries/auth0js) has been improved to operate with enhanced security and removes dependencies that have been deprecated as per Auth0's roadmap. In some cases, these security enhancements may impact application behavior when upgrading from an earlier versions of auth0.js. + +## Should I migrate to v9? + +Everyone should migrate to v9. All previous versions are deprecated, and the deprecated endpoints used by them were removed from service on August 6, 2018. For applications that use Auth0.js within an Auth0 login page, this migration is recommended; for applications with Auth0.js embedded within them, this migration is mandatory. + +## Migration Instructions + +The documents below describe all the changes that you should be aware of when migrating from different versions of Auth0.js to v9. Make sure you go through the relevant guide(s) before upgrading. + +* [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9) + * [Recommendations for migrating from Auth0.js v8 when Single Sign-on (SSO) is required](/guides/login/migration-sso) +* [Migrating from Auth0.js v7](/libraries/auth0js/v9/migration-v7-v9) +* [Migrating from Auth0.js v6](/libraries/auth0js/v9/migration-v6-v9) +* [Migrating from Auth0.js v8 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v8) +* [Migrating from Auth0.js v7 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v7) +* [Migrating from Auth0.js v6 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v6) +* [Migrating from Auth0.js v8 in Angular 2.x Applications](/libraries/auth0js/v9/migration-angular) +* [Migrating from Auth0.js v8 in React.js Applications](/libraries/auth0js/v9/migration-react) + +If you have any questions or concerns, you can discuss them in the [Auth0 Community](https://community.auth0.com/), submit them using the [Support Center](${env.DOMAIN_URL_SUPPORT}), or directly through your account representative, if applicable. + +<%= include('../../../_includes/_embedded_login_warning') %> + +## Troubleshooting + +### I upgraded but I still get deprecation warnings in the logs + +You have already migrated to Auth0.js 9 but you still see this error in your logs: + +```text +Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application. +``` + +These deprecation notices most likely originate from a user visiting the Universal Login [page](/universal-login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. After August 6, 2018, these users will not be able to log in. + +See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors. diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-react.md b/fr-ca/articles/libraries/auth0js/v9/migration-react.md new file mode 100644 index 0000000000..633c543fbb --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-react.md @@ -0,0 +1,23 @@ +--- +section: libraries +title: Migrating React Applications to Auth0.js v9 +description: How to migrate React applications to Auth0.js v9 +public: false +topics: + - libraries + - auth0js + - migrations + - react +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating React Applications to Auth0.js v9 + +React applications use auth0.js directly without any kind of wrapper library. + +Most React applications will be using auth0.js v8, so you can follow the [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9) guide. + +If you were an early React and Auth0 adopter, and are using auth0.js v7, you can follow the [Migrating from Auth0.js v7](/libraries/auth0js/v9/migration-v7-v9) guide. diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-v6-v9.md b/fr-ca/articles/libraries/auth0js/v9/migration-v6-v9.md new file mode 100644 index 0000000000..99375af3f5 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-v6-v9.md @@ -0,0 +1,19 @@ +--- +section: libraries +title: Migrating from Auth0.js v6 to v9 +description: How to migrate from Auth0.js v6 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating from Auth0.js v6 to v9 + +The [auth0.js](/libraries/auth0js) v6 API is the same as the v7 one. You can use the [Migrating from Auth0.js v7 to v9 guide](/libraries/auth0js/v9/migration-v7-v9) to understand how your application code needs to be adjusted. diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-v7-v9.md b/fr-ca/articles/libraries/auth0js/v9/migration-v7-v9.md new file mode 100644 index 0000000000..7a1c5bb666 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-v7-v9.md @@ -0,0 +1,304 @@ +--- +section: libraries +title: Migrating from Auth0.js v7 to v9 +description: How to migrate from Auth0.js v7 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating from Auth0.js v7 to v9 + +This guide includes all the information you need to update [Auth0.js](/libraries/auth0js) from v7 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide). + +The [Auth0.js v7 to v8 Migration Guide](/libraries/auth0js/v8/migration-guide) has detailed information on how to migrate from v7 to v8, and that information is still valid, v7 is very similar to v9. This document will go over some common usage patterns, and focus on things that changed after that guide was created. + +## Migration Steps + +<%= include('../../_includes/_get_auth0_js_latest_version') %> + +## Using Auth0.js to Log In Users + +### Using Auth0.js v7 + +```js +var auth0 = new Auth0({ + domain:'${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// With Universal Login +auth0.login({}); + +// With a social or enterprise connection +auth0.login({ + connection: 'twitter' +}); + +// With username and password +auth0.login({ + connection: 'my-db-connection', + username: 'the-username', + password: 'the-password' +}); +``` + +### Using Auth0.js v9 + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token id_token' +}); + +// with Universal Login +webAuth.authorize({}); + +// with a social or enterprise connection +webAuth.authorize({ + connection: 'twitter' +}); + +// with username and password +webAuth.login({ + realm: 'my-db-connection', + username: 'the-username', + //email: 'the@email.com', + password: 'the-password' +}); +``` +## Using Auth0.js to log in users in 'popup mode' + +### Using Auth0.js v7 + +```js +var auth0 = new Auth0({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// With Universal Login +auth0.login({ + popup: true +}); + +//with a social or enterprise connection +auth0.login({ + popup: true, + connection: 'twitter' +}); + +//with username and password +auth0.login({ + popup: true, + connection: 'my-db-connection', + username: 'the-username', + password: 'the-password' +}); +``` + +### Using Auth0.js v9 + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// with Universal Login +webAuth.popup.authorize({}); + +// with a social or enterprise connection +webAuth.popup.authorize({ + connection: 'twitter' +}); + +// with username and password +webAuth.popup.loginWithCredentials({ + connection: 'my-db-connection', + username: 'the-username', + //email: 'the@email.com', + password: 'the-password' +}); +``` +## Using Auth0.js to sign up users + +### Using Auth0.js v7 + +```js +var auth0 = new Auth0({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// signup only +auth0.signup({ + connection: 'my-db-connection', + username: 'the-username', + password: 'the-password', + auto_login: false +}, function (err) { + if (err) return alert('Something went wrong: ' + err.message); + alert('success signup without login!') +}); + +// signup and login +auth0.signup({ + connection: 'my-db-connection', + username: 'the-username', + password: 'the-password', + auto_login: true +}, function (err) { + if (err) alert('Something went wrong: ' + err.message); +}); +``` + +### Using Auth0.js v9 + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// signup only + +webAuth.signup({ + connection: 'my-db-connection', + email: 'the-email', +  password: 'the-password', + user_metadata: { plan: 'silver', team_id: 'a111' } +}, function (err) { + if (err) return alert('Something went wrong: ' + err.message); + alert('success signup without login!') +}); + +// signup and login +webAuth.redirect.signupAndLogin({ + connection: 'my-db-connection', + email: 'the-email', +  password: 'the-password', + user_metadata: { plan: 'silver', team_id: 'a111' } +}, function(err) { + if (err) alert('Something went wrong: ' + err.message); +}); +``` + +## Using Auth0.js to log in users using passwordless + +### Using Auth0.js v7 + +```js +var auth0 = new Auth0({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token' +}); + +// with a magic link sent via email +auth0.requestMagicLink( + { + email: 'the@email.com' + }, + function(err) {} +); + +// with a code sent via email +auth0.requestEmailCode( + { + email: 'the@email.com' + }, + function(err) {} +); + +// verifying the email code +auth0.verifyEmailCode( + { + email: 'the@email.com', + code: 'the-code' + }, + function(err, result) {} +); + +// with a code sent via sms +auth0.requestSMSCode( + { + phoneNumber: '+the_phone_number' + }, + function(err) {} +); + +// verifying the sms code +auth0.verifySMSCode( + { + phoneNumber: '+the_phone_number', + code: 'the-code' + }, + function(err, result) {} +); +``` + +### Using Auth0.js v9 + +```js +var webAuth = new auth0.WebAuth({ + domain: ''${account.namespace}'', + clientID: ''${account.clientId}'', + responseType: 'token' +}); + +// with a magic link sent via email +webAuth.passwordlessStart({ + send: 'link', + email: 'the@email.com', + connection: 'email' +}); + +// with a code sent via email +webAuth.passwordlessStart({ + send: 'code', + email: 'the@email.com', + connection: 'email' +}); + +// verifying the email code +webAuth.passwordlessLogin({ + email: 'the@email.com', + verificationCode: 'the-code', + connection: 'email' +}); + +// with a code sent via sms +webAuth.passwordlessStart({ + phoneNumber: '+the_phone_number', + connection: 'sms' +}); + +// verifying the sms code +webAuth.passwordlessLogin({ + phoneNumber: '+the_phone_number', + verificationCode: 'the-code', + connection: 'sms' +}); +``` + +<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %> +<%= include('../../_includes/_review_get_ssodata') %> +<%= include('../../_includes/_legacy_flows') %> + +## Behavioral Changes + +<%= include('../../_includes/_default_values') %> diff --git a/fr-ca/articles/libraries/auth0js/v9/migration-v8-v9.md b/fr-ca/articles/libraries/auth0js/v9/migration-v8-v9.md new file mode 100644 index 0000000000..2a40de08b2 --- /dev/null +++ b/fr-ca/articles/libraries/auth0js/v9/migration-v8-v9.md @@ -0,0 +1,44 @@ +--- +section: libraries +title: Migrating to from Auth0.js v8 to v9 +description: How to migrate from Auth0.js v8 to v9 +public: false +toc: true +topics: + - libraries + - auth0js + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating from Auth0.js v8 to v9 + +This guide includes all the information you need to update [Auth0.js](/libraries/auth0js) from v8 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide). + +## Migration demo + +
 
+ +## Migration steps + +<%= include('../../_includes/_migrate_universal') %> +<%= include('../../_includes/_get_auth0_js_latest_version') %> +<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %> +<%= include('../../_includes/_review_get_ssodata') %> + +#### Migration with getSSOData demo + +
 
+ +<%= include('../../_includes/_configure_custom_domain', { library : 'Auth0.js v9'}) %> + +<%= include('../../_includes/_legacy_flows') %> + +<%= include('../../_includes/_verifying_migration') %> + +## Behavioral Changes + +<%= include('../../_includes/_default_values') %> diff --git a/fr-ca/articles/libraries/custom-signup.md b/fr-ca/articles/libraries/custom-signup.md new file mode 100644 index 0000000000..fe0c3841bf --- /dev/null +++ b/fr-ca/articles/libraries/custom-signup.md @@ -0,0 +1,183 @@ +--- +section: libraries +description: How to customize the user signup form with additional fields using Lock or the Auth0 API. +toc: true +topics: + - libraries + - lock + - custom-signups +contentType: + - how-to + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Custom Signup + +You can customize the user signup form with more fields in addition to email and password when using Lock or the Auth0 API. + +There are many factors to consider before you choose [Lock vs. Custom UI](/libraries/when-to-use-lock). For example, using Lock, you can redirect to another page to capture data or use progressive profiling. When using the Auth0 API, you can capture custom fields and store them in a database. There are certain limitations to the customization that should be considered when choosing the method that best suits your purpose. Some typical customizations include adding a username and verifying password strength. + +:::panel Universal Login +Auth0 offers a Universal Login option that you can use instead of designing your own custom signup page. If you want to offer signup and login options, and you only need to customize the application name, logo and background color, then Universal Login via an Auth0 login page might be an easier option to implement. +::: + +## Using Lock + +Lock supports [custom fields signup](/libraries/lock/customization#additionalsignupfields-array-). + +![custom signup fields](/media/articles/libraries/lock/v10/signupcustom.png) + +Lock's `additionalSignUpFields` option will only work with database signups. For signups using social identity providers, collecting these fields in the same manner is not possible with Lock, but there are two other options to allow social IDP signups with Lock while still collecting additional custom fields. + +### Redirect to another page + +One way to use social provider signups with Lock and collect custom fields is to use [redirect rules](/rules/guides/redirect) to redirect the user to another page where you ask for extra information, and then redirect back to finish the authentication transaction. + +### Progressive profiling + +Another way to collect custom field data when signing users up with social providers is via [progressive profiling](/users/concepts/overview-progressive-profiling) whereby you can slowly build up user profile data over time. You collect the bare minimum details upon signup, but when a user later interacts with your app, you collect a small amount of data (perhaps one question) each time until their profile is complete. This allows you to collect the desired information but with less friction, since the goal of using a social IDP for signup is making it more effortless and streamlined for the user. + +## Using the API + +### Create a signup form to capture custom fields + +```html +
+
+ Sign up +

+ +

+

+ +

+

+ +

+

+ +

+ +
+
+``` + +The `name` is a user profile attribute and `color` is a custom field. + +::: note +There is currently no way to validate user-supplied custom fields when signing up. Validation must be done from an Auth0 [Rule](/rules) at login, or with custom, **server-side** logic in your application. +::: + +### Send the form data + +Send a POST request to the [/dbconnections/signup](/api/authentication/reference#signup) endpoint in Auth0. + +You will need to send: +- Your application's `client_id` +- The `email` and `password` of the user being signed up +- The name of the database `connection` to store your user's data +- Any user profile attribute you want to update for the user, which can include `given_name`, `family_name`, `name`, `nickname`, and `picture`. +- Any custom fields as part of `user_metadata` + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/dbconnections/signup", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\",\"email\": \"$('#signup-email').val()\",\"password\": \"$('#signup-password').val()\",\"connection\": \"YOUR_CONNECTION_NAME\",\"name\": \"$('#name').val()\",\"user_metadata\": {\"color\": \"red\"}}" + } +} +``` + +## Custom fields limitations + +When your users sign up, the custom fields are sent as part of `user_metadata`. The limitations of this field are: + +* `user_metadata` must contain no more than 10 fields +* `user_metadata.field` must be a string +* `user_metadata.field.value.length` must be fewer than 500 characters +* `user_metadata.field.length` must be fewer than 100 characters +* The current size limit for `user_metadata` is **16 MB** + +## Redirect mode + +After a successful login, Auth0 will redirect the user to your configured callback URL with a JWT (`id_token`) in the query string. + +::: note +To learn more about the differences between popup and redirect modes, please refer to [this document](/libraries/lock/v10/popup-mode). +::: + +```js +window.auth0 = new Auth0({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + // Callback made to your server's callback endpoint + callbackURL: '${account.callback}', +}); +``` + +Your server will then need to call APIv2 to add the necessary custom fields to the user's profile. + +## Add username to the signup form + +One common signup customization is to add a username to the signup. + +To enable this feature, turn on the **Requires Username** setting on the [Connections > Database](${manage_url}/#/connections/database/) section of the dashboard under the **Settings** tab for the connection you wish to edit. + +Capture the `username` field in your custom form, and add the `username` to your request body. + +```html +
+
+ Sign up +

+ +

+

+ +

+

+ +

+ +
+
+``` + +```js +var settings = { + "async": true, + "crossDomain": true, + "url": "https://${account.namespace}/dbconnections/signup", + "method": "POST", + "headers": { + "content-type": "application/x-www-form-urlencoded" + }, + "data": { + "client_id": "${account.clientId}", + "email": $('#signup-email').val(), + "password": $('#signup-password').val(), + "connection": "YOUR_CONNECTION_NAME", + "username": $('#username').val() + } +} + +$.ajax(settings).done(function (response) { + console.log(response); +}); +``` + +## Optional: Verify password strength + +Password policies for database connections can be configured in the dashboard. For more information, see: [Password Strength in Auth0 Database Connections](/connections/database/password-strength). + +If required for implementation of custom signup forms, the configured password policies, along with other connection information, can be retrieved from the [Management v2 API](/api/management/v2#!/Connections/get_connections_by_id). The result can be parsed client-side, and will contain information about the current password policy (or policies) configured in the dashboard for that connection. diff --git a/fr-ca/articles/libraries/error-messages.md b/fr-ca/articles/libraries/error-messages.md new file mode 100644 index 0000000000..a6c1e29606 --- /dev/null +++ b/fr-ca/articles/libraries/error-messages.md @@ -0,0 +1,49 @@ +--- +section: libraries +description: Describes common sign up and login errors that you might see when you authenticate users using Auth0 libraries. +topics: + - libraries + - lock + - auth0js + - error-messages +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Common Auth0 Library Authentication Errors + +The actions or input data of your users, during the sign up or the log in processes, might trigger errors. Here is a list of the most common errors that you might get if you use any of the Auth0 libraries for authentication. + +## Sign up + +In the case of a failed signup, the most common errors are: + +| **Error** | **Description** | +|-|-| +| **invalid_password** | If the password used doesn't comply with the password policy for the connection | +| **invalid_signup** | The user your are attempting to sign up is invalid | +| **password_dictionary_error** | The chosen password is too common | +| **password_no_user_info_error** | The chosen password is based on user information | +| **password_strength_error** | The chosen [password is too weak](/connections/database/password-strength) | +| **unauthorized** | If you cannot sign up for this application. May have to do with the violation of a specific rule | +| **user_exists** | The user you are attempting to sign up has already signed up | +| **username_exists** | The username you are attempting to sign up with is already in use | + +## Log in + +In the case of a failed login, the most common errors are: + +| **Error** | **Description** | +|-|-| +| **access_denied** | When using web-based authentication, the resource server denies access per OAuth2 specifications | +| **invalid_user_password** | The username and/or password used for authentication are invalid | +| **mfa_invalid_code** | The multi-factor authentication (MFA) code provided by the user is invalid/expired | +| **mfa_registration_required** | The administrator has required [multi-factor authentication](/mfa), but the user has not enrolled | +| **mfa_required** | The user must provide the [multi-factor authentication](/mfa) code to authenticate | +| **password_leaked** | If the password has been leaked and a different one needs to be used | +| **PasswordHistoryError** | The password provided for sign up/update has already been used (reported when [password history](/connections/database/password-options#password-history) feature is enabled) | +| **PasswordStrengthError** | The password provided does not match the connection's [strength requirements](/connections/database/password-strength) | +| **too_many_attempts** | The account is blocked due to too many attempts to sign in | +| **unauthorized** | The user you are attempting to sign in with is blocked | \ No newline at end of file diff --git a/fr-ca/articles/libraries/index.md b/fr-ca/articles/libraries/index.md new file mode 100644 index 0000000000..cb41e46b6c --- /dev/null +++ b/fr-ca/articles/libraries/index.md @@ -0,0 +1,79 @@ +--- +section: libraries +classes: topic-page +title: Auth0 Libraries +description: Auth0 Libraries and SDKs overview +topics: + - libraries + - lock + - auth0js +contentType: + - index + - concept +--- + +
+
+

Auth0 Libraries

+

+ Auth0 offers widgets and SDKs to provide a simple and frictionless experience for you when using Auth0. Take a look at the options listed to find documentation and links to repositories for the tools you need to get started. +

+
+ +<%= include('../_includes/_embedded_login_warning') %> + +## Lock + + + +### Lock repositories and support status + +<%= include('../_includes/_libraries_support_lock') %> + +## SDKs + + + +### SDK repositories and support status + +<%= include('../_includes/_libraries_support_sdks') %> + +### Platform integration repositories and support status + +<%= include('../_includes/_libraries_support_frameworks') %> + +::: note +Auth0 reserves the right to downgrade an SDK from **Supported** to **Community-Supported** at any time. +::: diff --git a/fr-ca/articles/libraries/lock-android/_includes/_lock-version.md b/fr-ca/articles/libraries/lock-android/_includes/_lock-version.md new file mode 100644 index 0000000000..4c92f0862e --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/_includes/_lock-version.md @@ -0,0 +1,3 @@ +::: version-warning +This document covers an outdated version of Lock for Android. We recommend you to upgrade to v2. +::: \ No newline at end of file diff --git a/fr-ca/articles/libraries/lock-android/_includes/_next-steps.md b/fr-ca/articles/libraries/lock-android/_includes/_next-steps.md new file mode 100644 index 0000000000..98cf862b59 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/_includes/_next-steps.md @@ -0,0 +1,11 @@ +## Lock for Android v1 Resources + +* [Lock v1 Configuration](/libraries/lock-android/v1/configuration) +* [Lock v1 Use Your Own UI](/libraries/lock-android/v1/use-your-own-ui) +* [Auth0 Error Messages](/libraries/error-messages) +* [Lock v1 Native Social Authentication](/libraries/lock-android/v1/native-social-authentication) +* [Lock v1 Magic Links](/libraries/lock-android/v1/passwordless-magic-link) +* [Lock v1 Refresh Tokens](/libraries/lock-android/v1/refresh-jwt-tokens) +* [Lock v1 Sending Authentication Params](/libraries/lock-android/v1/sending-authentication-parameters) +* [Lock v1 Installation and Setup](/libraries/lock-android/v1) +* [Logging out Users](/logout) diff --git a/fr-ca/articles/libraries/lock-android/index.yml b/fr-ca/articles/libraries/lock-android/index.yml new file mode 100644 index 0000000000..f8c9d39302 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: libraries/lock-android + current: v2 + versions: + - v1 + - v2 + defaultArticles: + v1: index + v2: index diff --git a/fr-ca/articles/libraries/lock-android/v1/configuration.md b/fr-ca/articles/libraries/lock-android/v1/configuration.md new file mode 100644 index 0000000000..918f0e31ed --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/configuration.md @@ -0,0 +1,248 @@ +--- +toc: true +title: Lock for Android v1 Configuration +description: Configuration options and methods for Lock for Android v1 +public: false +topics: + - libraries + - lock + - android +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Configuration + +<%= include('../_includes/_lock-version') %> + +These are options that can be used to configure Lock for Android v1 to your project's needs. + +## Lock + +### Lock Constants + +```java +public static final String AUTHENTICATION_ACTION; +``` + +Action sent in `LocalBroadcastManager` when a user authenticates. It will include an instance of `UserProfile` and `Token`. + +```java +public static final String AUTHENTICATION_ACTION_PROFILE_PARAMETER; +``` + +Name of the parameter that will include user's profile + +```java +public static final String AUTHENTICATION_ACTION_TOKEN_PARAMETER; +``` + +Name of the parameter that will include user's token information + +```java +public static final String CANCEL_ACTION; +``` + +Action sent when the user navigates back closing `LockActivity` or `LockSMSActivity` + +```java +public static final String CANCEL_ACTION; +``` + +Action sent when the user change its password + +### Lock Properties + +```java +public boolean shouldUseWebView(); +public void setUseWebView(boolean useWebView); +``` + +Forces Lock to use an embedded `android.webkit.WebView` and by default is `false`. + +```java +public boolean shouldLoginAfterSignUp(); +public boolean setLoginAfterSignUp(boolean loginAfterSignUp); +``` + +Lock will login the user after a successful sign up. By default is `true` + +```java +public boolean isClosable(); +public boolean setClosable(boolean closable); +``` + +Allows Lock activities to be closed by pressing back button. Default is `false` + +```java +public boolean shouldUseEmail(); +public void setUseEmail(boolean useEmail); +``` + +Lock will ask for the user's email instead of a username. By default is `true`. + +```java +public Map getAuthenticationParameters(); +public void setAuthenticationParameters(Map authenticationParameters); +``` + +Map with parameters that will be sent on every authentication request with Auth0 API. + +```java +public List getConnections(); +public void setConnections(List connections); +``` + +Tells Lock to use the connections whose name is included in the list. By default the list is null or empty which means that all enabled connections in your application will be used. + +```java +public String getDefaultDatabaseConnection(); +public void setDefaultDatabaseConnection(String defaultDatabaseConnection); +``` + +Lock will use the Database Connection whose name matches the one provided. By default its null, which means it will pick the first of the list. + +```java +public void setFullscreen(boolean fullscreen); +public boolean isFullscreen(); +``` + +If Lock's activities should be displayed in Fullscreen. Default is `false` + +### Lock Methods + +```java +public void setProvider(String serviceName, IdentityProvider provider); +``` + +Change the default identity provider handler for Social and Enterprise connections. By default all social/enterprise authentication are done using Web flow with a Browser. + +```java +public void resetAllProviders(); +``` + +Removes all session information the Identity Provider handlers might have. + +## Lock.Builder + +A simple builder to help you create and configure Lock in your application. + +### Lock.Builder Constants + +```java +public static final String CLIENT_ID_KEY = "com.auth0.lock.client-id"; +``` + +Key value used by Lock to search in your application's meta-data for the ClientID. + +```java +public static final String TENANT_KEY = "com.auth0.lock.tenant"; +``` + +Key value used by Lock to search in your application's meta-data for tenant name. + +```java +public static final String DOMAIN_URL_KEY = "com.auth0.lock.domain-url"; +``` + +Key value used by Lock to search in your application's meta-data for domain Url. + +```java +public static final String CONFIGURATION_URL_KEY = "com.auth0.lock.configuration-url"; +``` + +Key value used by Lock to search in your application's meta-data for configuration Url. + +### Lock.Builder Methods + +```java +public Builder clientId(String clientId); +``` + +Set the clientId of your application in Auth0. This value is mandatory. + +```java +public Builder tenant(String tenant); +``` + +Set the tenant name of your application. This value is optional if you supply a domain url. + +```java +public Builder domainUrl(String domain); +``` + +Set the domain Url for Auth0's API. This value is optional if you provide a tenant name, it will default to Auth0 cloud API `https://tenant_name.auth0.com`. + +```java +public Builder configurationUrl(String configuration); +``` + +Set the Url where Lock fetches the App configuration. By default it asks Auth0 for this info. + +```java +public Builder useWebView(boolean useWebView); +``` + +Make Lock use an embedded WebView for Social+Enterprise authentications. + +```java +public Builder closable(boolean closable); +``` + +Allow the user to close Lock's activity by pressing back button. + +```java +public Builder loginAfterSignUp(boolean loginAfterSignUp); +``` + +After a successful sign up of a user, sign him/her in too. + +```java +public Builder authenticationParameters(Map parameters); +``` + +Extra parameters sent to Auth0 Auth API during authentication. By default it has `scope` defined as `openid offline_access` and a device name stored in `device` parameter key. For more information check out our [documentation on sending authentication parameters](/libraries/lock-android/v1/sending-authentication-parameters) + +```java +public Builder useEmail(boolean useEmail); +``` + +Lock will ask for an email for authentication, otherwise it will ask for a username. By default is `true`. + +```java +public Builder useConnections(String ...connectionNames); +``` + +Make Lock pick these connections for authentication from all the enabled connections in your app. + +```java +public Builder defaultDatabaseConnection(String name); +``` + +Make Lock use the Database Connection whose name matches the one provided. + +```java +public Builder loadFromApplication(Application application); +``` + +Load ClientID, Tenant name, Domain and configuration URLs from the Android app's metadata (if available). +These are the values that can be defined and it's keys: + +* __com.auth0.lock.client-id__: Application's clientId in Auth0. +* __com.auth0.lock.tenant__: Application's owner tenant name. (Optional if you supply Domain and Configuration URLs) +* __com.auth0.lock.domain-url__: URL where the Auth0 API is available. (Optional if you supply ClientID/Tenant and you use Auth0 in the cloud) +* __com.auth0.lock.configuration-url__: URL where Auth0 apps information is available. (Optional if you supply ClientID/Tenant and you use Auth0 in the cloud) + +```java +public Builder fullscreen(boolean fullscreen); +``` + +Make Lock's activities fullscreen. Default is `false` + +```java +public Lock build(); +``` + +Creates a new instance of `Lock` and configure it with the values passed to the builder. \ No newline at end of file diff --git a/fr-ca/articles/libraries/lock-android/v1/delegation-api.md b/fr-ca/articles/libraries/lock-android/v1/delegation-api.md new file mode 100644 index 0000000000..f868a9de45 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/delegation-api.md @@ -0,0 +1,64 @@ +--- +toc: true +title: Lock for Android v1 Delegation +description: Integrate with third-party apps with the delegation API. +public: false +topics: + - libraries + - lock + - delegation + - android +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Delegation API + +<%= include('../_includes/_lock-version') %> + +<%= include('../../../_includes/_deprecate-delegation') %> + +After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/auth-api#!#post--delegation) using a valid JWT. + +Here's an example + +```java +Lock lock = LockContext.getLock(this); +AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); +String apiType = "firebase"; +String token = .... //Your Auth0 ID Token of the logged in User +Map parameters = ParameterBuilder.newEmptyBuilder() + .set("id_token", token) + .set("api_type", apiType) + .asDictionary(); +client + .delegation() + .addParameters(parameters).start(new BaseCallback>() { + @Override + public void onSuccess(Map payload) { + //Your Firebase token will be in payload + } + + @Override + public void onFailure(Throwable error) { + //Delegation call failed + } + }); +``` + +::: note +The delegation response is a generic Map since the structure of it will depend of the `api_type` used for delegation +::: + +The only two parameters required are `id_token` and `api_type`, the former is the token returned by Auth0 after a successful authentication, the latter specifies the API credentials we want to retrieve, and these are its supported values: + +* app: Your Auth0 application. This will get a new JWT token. +* aws: Amazon Web Services API. +* azure_sb: Windows Azure Service Bus. +* firebase: Firebase API. +* salesforce_api: Salesforce API. +* salesforce_sandbox_api: Salesforce Sandbox API. +* sap_api: SAP OData. +* wams: Windows Azure Mobile Services. diff --git a/fr-ca/articles/libraries/lock-android/v1/index.md b/fr-ca/articles/libraries/lock-android/v1/index.md new file mode 100644 index 0000000000..9c2bdbf318 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/index.md @@ -0,0 +1,208 @@ +--- +section: libraries +toc: true +title: Lock for Android v1 +description: A widget that provides a frictionless login and signup experience for your native Android apps. +public: false +mobileimg: media/articles/libraries/lock-android.png +topics: + - libraries + - lock + - android +contentType: + - index + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Getting Started + +<%= include('../_includes/_lock-version') %> + +::: note +Check out the [Lock.Android repository](https://github.com/auth0/Lock.Android/tree/v1) on GitHub. +::: + +## Requirements + +Android API level 15+ is required in order to use Lock's UI. +If you'll create your own API and just call Auth0 API via the `com.auth0.android:core:1.+`, the minimum required API level is 9. + +## Install + +Lock is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To start using *Lock* add these lines to your `build.gradle` dependencies file: + +```gradle +compile 'com.auth0.android:lock:1.+' +``` + +Once it's installed, you'll need to configure LockActivity in your`AndroidManifest.xml`, inside the `application` tag: + +```xml + + + + + + + + + + + + +``` + +::: note +The value `@string/auth0_client_id` is your application's clientID and `@string/auth0_domain` is your tenant's domain in Auth0, both values can be found in your app's settings. +::: + +::: note +The final value of `android:scheme` must be in lowercase. +::: + +Also, you'll need to add *Internet* permission to your application: + +```xml + +``` + +Finally, make your Application class (The one that extends from `android.app.Application`) implement the interface `com.auth0.lock.LockProvider` and add the following code: + +```java +public class MyApplication extends Application implements LockProvider { + + private Lock lock; + + public void onCreate() { + super.onCreate(); + lock = new Lock.Builder() + .loadFromApplication(this) + /** Other configuration goes here */ + .closable(true) + .build(); + } + + @Override + public Lock getLock() { + return lock; + } +} +``` + +::: note +You can check [here](#lock-builder) for more configuration options +::: + +You should also add your Application class to the `AndroidManifest.xml`. + +```xml + + + + +``` + +And include the following code in your `build.gradle` file. + +```gradle +android { + //... + packagingOptions { + exclude 'META-INF/NOTICE' + exclude 'META-INF/LICENSE' + } +} +``` + +## Authentication with Lock + +`LockActivity` will handle Email/Password, Enterprise & Social authentication based on your Application's connections enabled in your Auth0's Dashboard. + +When a user authenticates successfully, LockActivity will send an Action using LocalBroadcastManager and then finish itself (by calling finish()). The activity that is interested in receiving this Action (In this case the one that will show Lock) needs to register a listener in the LocalBroadcastManager: + +```java +// This activity will show Lock +public class HomeActivity extends Activity { + + private LocalBroadcastManager broadcastManager; + + private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() { + @Override + public void onReceive(Context context, Intent intent) { + UserProfile profile = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_PROFILE_PARAMETER); + Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER); + Log.i(TAG, "User " + profile.getName() + " logged in"); + } + }; + + @Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + //Customize your activity + + broadcastManager = LocalBroadcastManager.getInstance(this); + broadcastManager.registerReceiver(authenticationReceiver, new IntentFilter(Lock.AUTHENTICATION_ACTION)); + } + + @Override + protected void onDestroy() { + super.onDestroy(); + broadcastManager.unregisterReceiver(authenticationReceiver); + } +} +``` + +Then just start `LockActivity` + +```java +Intent lockIntent = new Intent(this, LockActivity.class); +startActivity(lockIntent); +``` + +And you'll see our native login screen + +![Lock Screenshot](/media/articles/libraries/lock-android/Lock-Widget-Android-Screenshot.png) + +::: note +By default all social authentication will be done using an external browser, if you want native integration please check this [wiki page](/libraries/lock-android/native-social-authentication). +::: + +## Proguard + +In the [proguard directory](https://github.com/auth0/Lock.Android/tree/master/proguard) you can find the *Proguard* configuration for Lock and its dependencies. +By default you should at least use the following files: + +* `proguard-square-okhttp.pro` +* `proguard-jackson-2.pro` +* `proguard-square-otto.pro` +* `proguard-lock.pro` + +and if you use Facebook or Google+ native integration, you'll need `proguard-facebook.pro` and `proguard-google-play-services.pro` respectively. + +You specify several files in you application's `build.gradle` like this: + +```gradle +buildTypes { + release { + minifyEnabled true + proguardFile '../proguard/proguard-facebook.pro' //facebook native auth + proguardFile '../proguard/proguard-google-play-services.pro' //G+ native auth + proguardFile '../proguard/proguard-square-okhttp.pro' //Auth0 core + proguardFile '../proguard/proguard-jackson-2.pro' //Auth0 core + proguardFile '../proguard/proguard-square-otto.pro' //Lock + proguardFile '../proguard/proguard-lock.pro' //Lock + //Add your app's specific proguard rules + } +} +``` + +<%= include('../_includes/_next-steps') %> diff --git a/fr-ca/articles/libraries/lock-android/v1/internationalization.md b/fr-ca/articles/libraries/lock-android/v1/internationalization.md new file mode 100644 index 0000000000..141c75ae56 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/internationalization.md @@ -0,0 +1,47 @@ +--- +section: libraries +title: Lock Android v1 Internationalization +description: Internationalization support in Lock for Android +public: false +topics: + - libraries + - lock + - i18n + - android +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Internationalization + +<%= include('../_includes/_lock-version') %> + +By default, **Lock.Android** displays all text in English. If you wish to display text in another language, you may provide a `strings.xml` file and define values to be used for the various text items that Lock might display. + +Android asks the device what _locale_ was configured by the user and tries to fetch the list of localized texts for that language. For this to work, the developer needs to add each translation file into the app by using a special folder naming convention as per Android standards. More information can be found in the [Android developer docs](https://developer.android.com/training/basics/supporting-devices/languages.html). + +Some of the default values provided by Lock include: + +```html + + Login SMS + Login not found + ... + +``` + +By providing your own `strings.xml` file, these values can be adjusted as such: + +```html + + Login with SMS + This user was not found! + ... + +``` + +## Lock String Values + +For a full list of the names used by Lock, see the [default strings.xml file](https://github.com/auth0/Lock.Android/blob/v1/app/src/main/res/values/strings.xml) in the Lock.Android repository. diff --git a/fr-ca/articles/libraries/lock-android/v1/native-social-authentication.md b/fr-ca/articles/libraries/lock-android/v1/native-social-authentication.md new file mode 100644 index 0000000000..295964224c --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/native-social-authentication.md @@ -0,0 +1,97 @@ +--- +title: Lock Android v1 Native Social Authentication +description: How to implement native social authentication with Lock Android +public: false +topics: + - libraries + - lock + - native + - social-connections + - android +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Native Social Authentication + +<%= include('../_includes/_lock-version') %> + +::: warning +This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. +We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login). +::: + +**Lock** by default handles all social authentication with a Browser installed in your Android device, but for some social connections you can take advantage of our native integration. +We implemented native integration with Facebook and Google+ and bundled each of them in a separate Android Library (*aar* file), to start using them just add these lines in your `build.gradle`: + +```gradle +compile 'com.auth0.android:lock-facebook:2.3.+' +compile 'com.auth0.android:lock-googleplus:2.3.+' +``` + +## Configuration + +### Facebook + +Lock uses Facebook Android SDK to obtain the user's credentials and use them to login with your Auth0 application. + +To get started, in your `AndroidManifest.xml` you need to add the following: + +```xml + + +``` + +Where `@string/facebook_app_id` is your Facebook Application ID that you can get from [Facebook Dev Site](https://developers.facebook.com/apps). + +::: note +For more information please check [Facebook Getting Started Guide](https://developers.facebook.com/docs/android/getting-started). +::: + +Finally, you need to register Auth0 Facebook Provider with Lock so it can do all Facebook authentication. This can be done in your Application object `onCreate` method right after you initialise Lock: + +```java +@Override +public void onCreate() { + super.onCreate(); + lock = new Lock.Builder() + .loadFromApplication(this) + .withIdentityProvider(Strategies.Facebook, new FacebookIdentityProvider(this)) + .build(); +} +``` + +### Google + +For Google login we use Google Signin library that is part of Google Play Services. + +Before we start, you'll need to register your application in Google Developers and create a OAuth 2.0 client, to do that follow this [wizard](https://developers.google.com/mobile/add?platform=android) + +The next step is to configure your Google connection in Auth0 Dashboard with the newly created OAuth 2.0 client information. Just go to [Social Connections](${manage_url}/#/connections/social), select **Google** and in the field named `Allowed Mobile Client IDs` add the ID of the OAuth 2.0 client. + +Then in your `AndroidManifest.xml` add these permissions and meta-data value for Google Play Services: + +```xml + + + +``` + +And finally register Google Identity Provider with Lock in your Application object `onCreate`: + +```java +@Override +public void onCreate() { + super.onCreate(); + lock = new LockBuilder() + .loadFromApplication(this) + .withIdentityProvider(Strategies.GooglePlus, new GooglePlusIdentityProvider(this)) + .build(); +} +``` diff --git a/fr-ca/articles/libraries/lock-android/v1/passwordless-magic-link.md b/fr-ca/articles/libraries/lock-android/v1/passwordless-magic-link.md new file mode 100644 index 0000000000..a318f4fb5f --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/passwordless-magic-link.md @@ -0,0 +1,195 @@ +--- +title: Lock Android v1 Passwordless with Magic Link +description: Passwordless with Magic Link with Lock Android +public: false +topics: + - libraries + - lock + - android + - passwordless + - magic-link +contentType: + - how-to + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Passwordless Magic link + +<%= include('../_includes/_lock-version') %> + +::: warning +Passwordless on native platforms is disabled by default for new tenants as of 8 June 2017. If you would like this feature enabled, please contact support to discuss your use case. See [Application Grant Types](/applications/concepts/application-grant-types) for more information. Alternatively, you can use Lock Passwordless with Auth0's Universal Login. +::: + +## Passwordless Authentication with Magic Link + +In order to avoid asking the user to input the one-time password sent for passwordless authentication in Android apps, we introduced the ability to send a link that the user can tap to login without any code input involved. + +These links include the same code that would be used in the traditional passwordless flow, but with the correct configuration they will be handled automatically by the Android system and our application will log in the users effortlessly by relying on **Android App Links**. + +With App Links, in Android 6.0 (API level 23) and higher, Android allows an app to designate itself as the default handler of a given type of link, without asking the user whether to use the browser or the app to open the link. + +Automatic handling of links requires the cooperation of our app and website (our Auth0 authentication server). The app must declare the association with the website and request that the system verify it. The website must, in turn, provide that verification by publishing a [Digital Asset Links](https://developers.google.com/digital-asset-links/) file. + +This feature works as long as the user has not already chosen a default app to handle that URI pattern. + +You could find more information about App Links in the [Android docs](http://developer.android.com/training/app-links/index.html). + +::: note +The links will work in all versions of Android, but the dialog asking the user whether to use the browser or the app to open the link will be displayed (whether the verification passed or not) in versions of Android prior to 6.0, at least until the user chooses to always open the links with the app. +::: + +In this article we'll show how Auth0 helps you set up your app to use app links to log in. + +### Auth0 account configuration + +Auth0 will generate the [Digital Asset Links](https://developers.google.com/digital-asset-links/) file automatically, all you need to do is configure the required parameters, some via API and others in your [dashboard](${manage_url}/#/connections/passwordless). We'll show you how to do it. + +### Application configuration + +We'll have to configure/add some field to our Auth0 application. The fields we need to configure are: + +- **app\_package\_name**: This is the package name, as declared in the app's manifest. An example would be *com.example.android.myapp* +- **sha256\_cert\_fingerprints**: This is an array of the SHA256 fingerprints of our android app’s signing certificates. This is an arbitrary length array, it can include all the fingerprints we want, so for example we could add both our release and debug fingerprints. + +#### Getting your signing certificates fingerprint + +You can use the following command to generate the fingerprint via the Java keytool: + +```bash +keytool -list -v -keystore my-release-key.keystore +``` + +or to obtain the default debug key: + +```bash +keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android +``` + +#### Configure Auth0 via API + +Once we have the package name and the SHA256 fingerprint, we'll update our Auth0 application via API with [patch\_clients\_by\_id](/api/v2#!/Clients/patch_clients_by_id) (they aren't yet available in the dashboard). + +In the *id* field we must introduce the *client_id* of our Auth0 App, and the *body* should look like this: + +```json +{ + "mobile": { + "android": { + "app_package_name": "", + "sha256_cert_fingerprints": ["", ""] + } + } +} +``` + +::: warning +Don't forget to change the body to use your package name and keystore fingerprint! +::: + +### Connection Configuration + +Next we'll have to configure either the SMS or Email connection. This is available from the dashboard, so we'll show how to do it from there. + +#### SMS + +In case we'll use a passwordless connection via SMS, we'll need to update the SMS message template from the [dashboard](${manage_url}/#/connections/passwordless). + +All you need to do is choose **Liquid** as the SMS Syntax and make sure the message contains something like this: + +```liquid +{% if send == 'link_ios' or send == 'link_android' %} +Your verification link is: {{ link }} +{% else %} +Your verification code is: {{ code }} +{% endif %} +``` + +::: note +We assume that you have the SMS connection correctly configured, including the Twilio account. If you haven't, please do so. +::: + +#### Email + +Otherwise, if we'll use a passwordless connection via Email, we'll need to make sure the template is **HTML + Liquid** and that the email body contains *somewhere* a conditional like this: + +```liquid +{% if send == 'link' or send == 'link_ios' or send == 'link_android' %} +Your verification link is: {{ link }} +{% elsif send == 'code' %} +Your verification code is: {{ code }} +{% endif %} +``` + +### Application configuration + +Now that we have the Auth0 application configured, before we start with the Android configuration we must follow the instructions and set up Lock.Android and LockPasswordlessActivity as seen in the [passwordless docs](/libraries/lock-android#passwordless). + +Now, in order to use App Links, there is an additional configuration step we must follow. We must declare an intent filter in the `AndroidManifest.xml`, inside the `LockPasswordlessActivity` activity tag. This filter will allow the app lo handle the links we'll send by Email or SMS. + +```xml + + + + + + + + + + + + + + + + + + + + + +``` + +The value `@string/auth0_domain` is your tenant's domain in Auth0, which can be found in your app's settings. + +In `android:pathPrefix` you must replace the package name of the application, as configured in the Auth0 account. + +As can be seen, it's a regular *intent-filter*, with the exception of the `android:autoVerify="true"` field. This is used since Android API 23 (Android 6.0) to indicate that we would like to verify the link association. **This is extremely important to avoid the dialog asking the user which application to use.** + +Also notice that in case we'll only use one passwordless method (SMS or Email) you could delete the other intent filter (see the last segment of the pathPrefix: `/email` or `/sms`). + +### Usage + +As you should already know, `LockPasswordlessActivity` authenticates users by sending them an Email or SMS, in this case we'll send them a link instead of a code. The only difference w.r.t. the regular passwordless is that we now explicitly indicate that we will use magic/app links. This is accomplished using the appropriate mode. + +If we would like to send app links by **Email**, just start `LockPasswordlessActivity` specifying the passwordless mode `MODE_EMAIL_MAGIC_LINK`: + +```java +LockPasswordlessActivity.showFrom(MyActivity.this, + LockPasswordlessActivity.MODE_EMAIL_MAGIC_LINK); +``` + +and we'll see the **Email** login screen + +![Email](/media/articles/libraries/lock-android/passwordless-magic-link/lock-android-pwdless-email.png) + +or for **SMS** the mode `MODE_SMS_MAGIC_LINK`: + +```java +LockPasswordlessActivity.showFrom(MyActivity.this, + LockPasswordlessActivity.MODE_SMS_MAGIC_LINK); +``` + +and we'll see the **SMS** login screen + +![SMS](/media/articles/libraries/lock-android/passwordless-magic-link/lock-android-pwdless-sms.png) + +After requesting the magic link from Auth0, via SMS or Email, the next screen will indicate that in order to log in, the user should tap it. We also offer a backup option to enter the code manually, just in case the links don't work. diff --git a/fr-ca/articles/libraries/lock-android/v1/passwordless.md b/fr-ca/articles/libraries/lock-android/v1/passwordless.md new file mode 100644 index 0000000000..473c2ee94a --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/passwordless.md @@ -0,0 +1,115 @@ +--- +section: libraries +title: Lock Android v1 Passwordless +description: Guide on implementing Passwordless authentication with Lock for Android +public: false +topics: + - libraries + - lock + - android + - passwordless + - tokens +contentType: + - how-to + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Passwordless + +<%= include('../_includes/_lock-version') %> + +Lock Passwordless authenticates users by sending them an Email or SMS with a one-time password that the user must enter and confirm to be able to log in, similar to how WhatsApp authenticates you. This article will explain how to send a **CODE** using the `Lock.Android` library. + +::: note +You can achieve a similar result by sending a **LINK** that the user can click to finish the passwordless authentication automatically, but a few more configuration steps are involved. You can check that article [here](/libraries/lock-android/v1/passwordless-magic-link). +::: + +In order to be able to authenticate the user, your application must have the Email/SMS connection enabled and configured in your [Auth0 Dashboard](${manage_url}/#/connections/passwordless). + +Note that Passwordless Lock *cannot be used* with the [OIDC Conformant Mode](/libraries/lock-android/index#oidc-conformant-mode) set to `true`. For more information, please see the [OIDC adoption guide](https://auth0.com/docs/api-auth/tutorials/adoption). + +## Passwordless Authentication + +`LockPasswordlessActivity` authenticates users by sending them an Email or SMS (similar to how WhatsApp authenticates you). In order to be able to authenticate the user, your application must have the SMS/Email connection enabled and configured in your [dashboard](${manage_url}/#/connections/passwordless). + +`LockPasswordlessActivity` is not included in `com.auth0:lock:aar` as it's part of the library `lock-passwordless`, but you can add it with this line in your `build.gradle`: + +```gradle +compile 'com.auth0.android:lock-passwordless:1.+' +``` + +Then in your `AndroidManifest.xml` register the following activities: + +```xml + + + + + +``` + +Just like `LockActivity`, when a user authenticates successfully, `LockPasswordlessActivity` will send an `Action` using `LocalBroadcastManager` and then finish itself (by calling `finish()`). The activity that is interested in receiving this `Action` (in this case the one that will show Lock) needs to register a listener in the `LocalBroadcastManager`: + +```java +// This activity will show Lock +public class HomeActivity extends Activity { + private LocalBroadcastManager broadcastManager; + + private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() { + @Override + public void onReceive(Context context, Intent intent) { + UserProfile profile = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_PROFILE_PARAMETER); + Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER); + Log.i(TAG, "User " + profile.getName() + " logged in"); + } + }; + + @Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + //Customize your activity + + broadcastManager = LocalBroadcastManager.getInstance(this); + broadcastManager.registerReceiver(authenticationReceiver, new IntentFilter(Lock.AUTHENTICATION_ACTION)); + } + + @Override + protected void onDestroy() { + super.onDestroy(); + broadcastManager.unregisterReceiver(authenticationReceiver); + } +} +``` + +Then just start `LockPasswordlessActivity` specifying the Passwordless type you want to use, so for **Email** + +```java +LockPasswordlessActivity.showFrom(MyActivity.this, LockPasswordlessActivity.MODE_EMAIL_CODE); +``` + +or just for **SMS** + +```java +LockPasswordlessActivity.showFrom(MyActivity.this, LockPasswordlessActivity.MODE_SMS_CODE); +``` + +and you'll see the **SMS** login screen + +![Lock Screenshot](/media/articles/libraries/lock-android/Lock-SMS-Android-Screenshot.png) + +Passworless scenarios and types: + +| Channel \ Mode | Code | Magic Link | +| :-----: |:---------------:| :--------------: | +| SMS | `LockPasswordlessActivity.MODE_SMS_CODE` | `LockPasswordlessActivity.MODE_SMS_LINK` | +| Email | `LockPasswordlessActivity.MODE_EMAIL_CODE` | `LockPasswordlessActivity.MODE_EMAIL_LINK` | + +You can find more information about Magic Links [here](/libraries/lock-android/v1/passwordless-magic-link). diff --git a/fr-ca/articles/libraries/lock-android/v1/refresh-jwt-tokens.md b/fr-ca/articles/libraries/lock-android/v1/refresh-jwt-tokens.md new file mode 100644 index 0000000000..6460b9756c --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/refresh-jwt-tokens.md @@ -0,0 +1,82 @@ +--- +title: Lock Android v1 Refreshing JWT Tokens +description: Keeping your user logged in +public: false +topics: + - libraries + - lock + - android + - passwordless + - tokens +contentType: + - how-to + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Refreshing JWT Tokens + +<%= include('../_includes/_lock-version') %> + +<%= include('../../../_includes/_uses-delegation') %> + +When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new JWT token and avoid asking the user for their credentials again. + +::: note +Lock.Android will include the `offline_scope` scope by default. +::: + +Before we start, we have to retrieve the ID Token or Refresh Token from the token when the user logs in. + +```java +private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() { + @Override + public void onReceive(Context context, Intent intent) { + Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER); + String idToken = token.getIdToken(); + String refreshToken = token.getRefreshToken(); + // Store ID Token or Refresh Token in secure storage + } +}; +``` + +Then, we need to store the ID Token or Refresh Token in secure storage after the user is authenticated by Auth0. And finally, we can request a new ID Token using either of them by calling Auth0`s **delegation** endpoint. + +## Using a non-expired ID Token + +```java +String idToken = // Retrieve ID Token from secure storage +Lock lock = LockContext.getLock(this); +AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); +client.delegationWithIdToken(idToken).start(new RefreshIdTokenCallback() { + @Override + public void onSuccess(String idToken, String tokenType, int expiresIn) { + //SUCCESS + } + + @Override + public void onFailure(Throwable error) { + //FAILURE + } +}); +``` + +## Using Refresh Token + +```java +String refreshToken = // Retrieve Refresh Token from secure storage +Lock lock = LockContext.getLock(this); +AuthenticationAPIClient client = lock.getAuthenticationAPIClient(); +client.delegationWithRefreshToken(refreshToken).start(new RefreshIdTokenCallback() { + @Override + public void onSuccess(String idToken, String tokenType, int expiresIn) { + //SUCCESS + } + + @Override + public void onFailure(Throwable error) { + //FAILURE + } +}); +``` diff --git a/fr-ca/articles/libraries/lock-android/v1/sending-authentication-parameters.md b/fr-ca/articles/libraries/lock-android/v1/sending-authentication-parameters.md new file mode 100644 index 0000000000..9ebaa1ad4e --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/sending-authentication-parameters.md @@ -0,0 +1,76 @@ +--- +title: Lock Android v1 Sending Authentication Parameters +description: Sending Authentication parameters with Lock Android +public: false +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Sending Authentication Parameters + +<%= include('../_includes/_lock-version') %> + +You can specify additional authentication parameters, before starting `LockActivity` or when calling any API method using `APIClient`, by using `ParameterBuilder` object to build the parameter dictionary. By default `ParameterBuilder` has the parameter `scope` with `openid offline_access` and `device` with the name obtained from + +```java +android.os.Build.MODEL +``` + +The following example adds a `scope` parameter with the value `login`. + +```java +ParameterBuilder builder = ParameterBuilder.newBuilder(); +Map parameters = builder.setScope("login").asDictionary(); +``` + +The following parameters are supported: + +* `access_token` +* `scope` +* `protocol` +* `device` +* `connection_scopes` +* `nonce` +* `offline_mode` +* `state`. + +There are other extra parameters that will depend on the provider. For example, Google allows you to get back a Refresh Token only if you explicitly ask for `access_type=offline`. + +We support sending arbitrary parameters like this: + +```java +ParameterBuilder builder = ParameterBuilder.newBuilder(); +Map parameters = builder + .set("access_type", "offline") + .set("my_arbitrary_param", "foo") + .asDictionary(); +``` + +## Supported Parameters + +### scope:`String` + +There are different values supported for scope: + +* `'openid'`: It will return, not only the Access Token, but also an ID Token which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim). You can use constant `ParameterBuilder.SCOPE_OPENID`. +* `'openid profile'`: (not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (such as when using response_type=token) and will likely create an unnecessarily large token (especially with Azure AD which returns a fairly long JWT). Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. +* `'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the ID Token (for example: `scope: 'openid name email picture'`). + +Also when you need to keep the ID Token alive, you can request a Refresh Token adding to the scope the value `offline_access` (Or use the constant `ParameterBuilder.SCOPE_OFFLINE_ACCESS`). + +By default in Lock for Android, the scope is set to `openid offline_access`. + +### device:`String` + +This value is only required when one of the scopes is `offline_access`. By default it has the name of the device obtained from calling the following method: + +```java +android.os.Build.MODEL +``` diff --git a/fr-ca/articles/libraries/lock-android/v1/use-your-own-ui.md b/fr-ca/articles/libraries/lock-android/v1/use-your-own-ui.md new file mode 100644 index 0000000000..5ab6f8899c --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v1/use-your-own-ui.md @@ -0,0 +1,324 @@ +--- +title: Lock Android v1 Customize Your UI +description: Customize the UI of Lock in your App +public: false +topics: + - libraries + - lock + - android + - lock-ui +contentType: + - how-to + - concept + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Customize Your UI + +<%= include('../_includes/_lock-version') %> + +:::note +We are going to use the library [EventBus](https://github.com/greenrobot/EventBus) in order to post authentication related events like **authentication done** and **Authentication failed** +::: + +Add the following dependencies to your project: + +```gradle +compile 'com.auth0.android:core:1.+' +compile 'de.greenrobot:eventbus:2.4.+' +``` + +Create a new resource file named `auth0.xml` under `values` and add the following content, replacing the values with your Auth0 ClientId and Domain + +```xml + + + ${account.clientId} + ${account.namespace} + +``` + +Create two classes `AuthenticationEvent` and `ErrorEvent` that will represent a successful authentication or a failed one + +```java +public class AuthenticationEvent { + private final UserProfile profile; + private final Token token; + + public AuthenticationEvent(UserProfile profile, Token token) { + this.profile = profile; + this.token = token; + } + + public Token getToken() { return token; } + + public UserProfile getProfile() { return profile; } +} + +public class ErrorEvent { + private Dialog dialog; + private int title; + private int message; + private Throwable throwable; + + public ErrorEvent(Dialog dialog) { + this.dialog = dialog; + } + + public ErrorEvent(int title, int message, Throwable throwable) { + this.title = title; + this.message = message; + this.throwable = throwable; + } +} +``` + +Then in your Login *Activity* add the following fields + +```java +private AuthenticationAPIClient client; +private EventBus eventBus; +``` + +In the same *Activity* `onCreate` method add the following lines to initialize **Auth0** and the fields we added earlier + +```java +Auth0 auth0 = new Auth0(getString(R.string.auth0_client_id), getString(R.string.auth0_domain_name)); +this.client = auth0.newAuthenticationAPIClient(); +this.eventBus = new EventBus(); +``` + +When you need to login your user with email/password credentials, just paste the following code + +```java +String email = ... // Get email +String password = ... // Get password +//add your DB connection name, since you are using email / pwd login +//will throw a 400 error if not set +ParameterBuilder parameterBuilder = ParameterBuilder.newBuilder(); +Map authenticationParameters = parameterBuilder + .setConnection("YOUR_DB_CONNECTION_NAME") + .asDictionary(); +client.login(email, password) + .addParameters(authenticationParameters) + .start(new AuthenticationCallback() { + @Override + public void onSuccess(UserProfile userProfile, Token token) { + eventBus.post(new AuthenticationEvent(userProfile, token)); + } + + @Override + public void onFailure(Throwable throwable) { + eventBus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable)); + } + }); +``` + +::: note +For more details about the parameters you can check [this wiki page](/libraries/lock-android/sending-authentication-parameters). +::: + +Finally handle both `AuthenticationEvent` and `ErrorEvent` + +```java +@Override +protected void onStart() { + super.onStart(); + eventBus.register(this); +} + +@Override +protected void onStop() { + super.onStop(); + eventBus.unregister(this); +} + +public void onEvent(ErrorEvent event) { + //Handle Error +} + +public void onEvent(AuthenticationEvent event) { + //Handle authentication +} +``` + +## Social Authentication + +::: warning +This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. +We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login). +::: + +Include the following libraries in your `build.gradle`: + +```gradle +compile 'com.auth0.android:identity-core:1.+' +compile 'com.auth0.android:lock-facebook:2.4.+' +compile 'com.auth0.android:lock-googleplus:2.4.+' +``` + +In your `auth0.xml` file add the following entry + +```xml +a0${account.clientId.toLowerCase()} +``` + +Configure your Login *Activity* adding the following intent filters in your `AndroidManifest.xml` file + +```xml + + + + + + +``` + +Create a new class that implements `IdentityProviderCallback`, that will handle social authentication (via native integration or using web browser) and post a new event either on success or failure + +```java +public class MyIdentityProviderCallback implements IdentityProviderCallback { + private final EventBus bus; + private final AuthenticationAPIClient client; + + public MyIdentityProviderCallback(EventBus bus, AuthenticationAPIClient client) { + this.bus = bus; + this.client = client; + } + + @Override + public void onFailure(Dialog dialog) { + //Authentication failed and a Error dialog is provided + bus.post(new ErrorEvent(dialog)); + } + + @Override + public void onFailure(int title, int message, Throwable throwable) { + //Authentication failed and a title & message resource are provided. + //The throwable parameter will include the reason (if any) + bus.post(new ErrorEvent(title, message, throwable)); + } + + @Override + public void onSuccess(String serviceName, String accessToken) { + //Authenticate with Auth0 using the IdP token obtained from a native integration like Facebook + client.loginWithOAuthAccessToken(accessToken, serviceName) + .start(new AuthenticationCallback() { + @Override + public void onSuccess(UserProfile userProfile, Token token) { + bus.post(new AuthenticationEvent(userProfile, token)); + } + + @Override + public void onFailure(Throwable throwable) { + bus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable)); + } + }); + } + + @Override + public void onSuccess(final Token token) { + //Already authenticated with Auth0 using Web Browser (when no native integration is available), then we just fetch the user's profile + client.tokenInfo(token.getIdToken()) + .start(new BaseCallback() { + @Override + public void onSuccess(UserProfile profile) { + bus.post(new AuthenticationEvent(profile, token)); + } + + @Override + public void onFailure(Throwable throwable) { + bus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable)); + } + }); + } +} +``` + +In your Login *Activity* add the following fields + +```java +private WebIdentityProvider webProvider; +private IdentityProvider identity; +private GooglePlusIdentityProvider googleplus; +private FacebookIdentityProvider facebook; +``` + +And implement the following methods + +```java +@Override +protected void onStop() { + webProvider.stop(); +} + +@Override +protected void onNewIntent(Intent intent) { + super.onNewIntent(intent); + Log.v(TAG, "Received new Intent with URI " + intent.getData()); + if (identity != null) { + identity.authorize(this, IdentityProvider.WEBVIEW_AUTH_REQUEST_CODE, RESULT_OK, intent); + } +} + +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + super.onActivityResult(requestCode, resultCode, data); + if (identity != null) { + identity.authorize(this, requestCode, resultCode, data); + } +} +``` + +In the method `onCreate` initialize Auth0 web provider and store it in a field + +```java +final MyIdentityProviderCallback callback = new MyIdentityProviderCallback(eventBus, client); +this.webProvider = new WebIdentityProvider(new CallbackParser(), auth0.getClientId(), auth0.getAuthorizeUrl()); +this.webProvider.setCallback(callback); +``` + +Configure Facebook Native integration + +```java +this.facebook = new FacebookIdentityProvider(this); +this.facebook.setCallback(callback); +``` + +:::note +You need to [configure](https://developers.facebook.com/docs/android/getting-started#app_id) your Android app for Facebook +::: + +Configure Google+ Native integrationApplication class) + +```java +this.googleplus = new GooglePlusIdentityProvider(this); +this.googleplus.setCallback(callback); +``` + +:::note +Before using Google+, you need to register your Application with Google as explained in this [guide](https://developers.google.com/+/mobile/android/getting-started) +::: + +To trigger Facebook authentication just add the following code: + +```java +identity = facebook; +identity.start(this, Strategies.Facebook.getName()); +``` + +To trigger Google+ authentication just add the following code: + +```java +identity = googleplus; +identity.start(this, Strategies.GooglePlus.getName()); +``` + +To trigger authentication with any IdP without native integration just add the following code: + +```java +identity = webProvider; +identity.start(this, Strategies.Twitter.getName()); +``` \ No newline at end of file diff --git a/fr-ca/articles/libraries/lock-android/v2/configuration.md b/fr-ca/articles/libraries/lock-android/v2/configuration.md new file mode 100644 index 0000000000..0a6bc8c3f2 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/configuration.md @@ -0,0 +1,72 @@ +--- +section: libraries +title: Lock for Android v2 Configuration +description: Altering the appearance and behavior of Lock for Android +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Configuration + +These are options that can be used to configure Lock for Android to your project's needs. **Note that if you are a user of Lock v1 who is now migrating to Lock v2**, you'll want to take note first of those [options that have been renamed or whose behavior have changed](/libraries/lock-android/migration-guide), and then look over the new list below, which contains quite a few options new to v2. + +Configurations options are added to the Lock Builder using the following format: + +```java + lock = Lock.newBuilder(auth0, callback) + // Configuration options + .closable(true) + .allowSignUp(false) + .setPrivacyURL('http://example.com/privacy') + .setTermsURL('http://example.com/terms') + // End configuration options + .build(this); +``` + +## UI options + +- **closable(boolean)**: Defines if the LockActivity can be closed. By default it's not closable. +- **allowedConnections(List)**: Filters the allowed connections from the list configured in the Dashboard. By default if this value is empty, all the connections defined in the dashboard will be available. + +## Authentication options + +- **withAuthenticationParameters(Map)**: Defines extra authentication parameters to be sent on each log in and sign up call. The default `scope` used on authentication calls is `openid`. If you want to specify a different one, use `withAuthenticationParameters` and add a different value for the `scope` key. +- **withScope(String)**: Changes the scope requested when performing an authentication request. + +## Database options + +- **withUsernameStyle(int)**: Defines if it should ask for email only, username only, or both of them. The accepted values are `USERNAME` and `EMAIL`. By default it will respect the Dashboard configuration of the parameter `requires_username`. +- **loginAfterSignUp(boolean)**: Whether after a `SignUp` event the user should be logged in automatically. Defaults to `true`. +- **initialScreen(int)**: Allows to customize which form will first appear when launching Lock. The accepted values are `LOG_IN`, `SIGN_UP`, and `FORGOT_PASSWORD`. By default `LOG_IN` is the initial screen. +- **allowSignUp(boolean)**: Shows the Sign Up form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`. +- **allowLogIn(boolean)**: Shows the Log In form if a Database connection is configured. Defaults to `true`. +- **allowForgotPassword(boolean)**: Shows the Forgot Password form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`. +- **allowShowPassword(boolean)**: Shows a button to toggle the input visibility of a Password field. Defaults to `true`. +- **setDefaultDatabaseConnection(String)**: Defines which will be the default Database connection. This is useful if your application has many Database connections configured. +- **withSignUpFields(List)**: Shows a second screen with extra fields for the user to complete after the username/email and password were completed in the sign up screen. Values submitted this way can be stored in the user profile using either a root attribute or the `user_metadata` attribute. For more info, see [Lock Android: Custom Fields at Signup](/libraries/lock-android/custom-fields). +- **setPrivacyURL(String)**: Allows to customize the Privacy Policy URL. Defaults to `https://auth0.com/privacy`. +- **setTermsURL(String)**: Allows to customize the Terms of Service URL. Defaults to `https://auth0.com/terms`. +- **setSupportURL(String)**: Allows to set a Support URL that will be displayed in case that a non-recoverable error raises on Lock. +- **setMustAcceptTerms(boolean)**: Forces the user to accept the Terms&Policy before signing up. Defaults to `false`. +- **useLabeledSubmitButton(boolean)**: If set to `true`, it will display a label of the current mode (sign up/ log in) in the submit button instead of an icon. Defaults to `true`. If the `hideMainScreenTitle` option is set to true this setting is ignored and a label will be used anyways. +- **hideMainScreenTitle(boolean)**: If set to `true`, the header on the main screen won't display the title. + +## OAuth options + +- **withAuthStyle(String, int)**: Customize the look and feel of a given connection (name) with a specific style. See [this document on custom oauth connections](/libraries/lock-android/v2/custom-theming#custom-oauth-connection-buttons) for more information. +- **withAuthHandlers(AuthHandler...)**: Customize the authentication process by passing an array of AuthHandlers. See [this document on custom authentication parameters](/libraries/lock-android/custom-authentication-providers) for more information. +- **withConnectionScope(String, String...)**: Allows to specify additional scopes for a given Connection name, which will be request along with the ones defined in the connection settings in the [Auth0 Dashboard](${manage_url}). The scopes are not validated in any way and need to be recognized by the given authentication provider. For a list, check in the [Auth0 Dashboard](${manage_url}) under the settings for the connection in question. +- **withScheme(String)**: Allows to change the scheme of the `redirect_uri` sent on the authorize call. By default, the scheme is `https`. When changing this setting, the intent-filter on the `AndroidManifest.xml` file and the Allowed Callbacks URLs on the application dashboard must be updated too. + +## Passwordless options + +- **useCode()**: Send a code instead of a link via email/SMS for Passwordless authentication. +- **useLink()**: Send a link instead of a code via email/SMS for Passwordless authentication. +- **rememberLastLogin(boolean)**: Whether the email or phone used in the last successful authentication will be saved to auto-login the next time a Passwordless authentication is requested. diff --git a/fr-ca/articles/libraries/lock-android/v2/custom-authentication-providers.md b/fr-ca/articles/libraries/lock-android/v2/custom-authentication-providers.md new file mode 100644 index 0000000000..44e93d8d40 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/custom-authentication-providers.md @@ -0,0 +1,77 @@ +--- +section: libraries +title: Lock Android v2 Custom Authentication Providers +description: Implementing custom authentication providers +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Custom Authentication Providers + +**Auth0.Android** includes the `WebAuthProvider` class to handle the authorize flow using the Browser. But what if you want to use your own implementation or a Native version of an `AuthProvider`? + +## The AuthProvider class + +Create a class that implements the `AuthProvider` interface and override its methods. + +You can also use any **Native** implementation already provided by Auth0. The [native social authentication](/libraries/lock-android/v2/native-social-authentication) providers currently available are Google and Facebook. + +::: warning +The native social providers rely on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login). +::: + +## The AuthHandler class + +**Auth0.Android** includes an interface for you to implement and define which provider to use given a Strategy and Connection name. It has a single method that returns an `AuthProvider` for a given strategy/connection name. If no provider can handle those values, it should return `null`. On **Lock** side, when no provider is returned it will default to `WebAuthProvider`. + +```java +public interface AuthHandler { + //Will return a nullable AuthProvider to handle that strategy/connection. + @Nullable + AuthProvider providerFor(@Nullable String strategy, @NonNull String connection); +} +``` + +### Usage Example + +```java +public class MyAuthHandler implements AuthHandler { + + @Nullable + @Override + public AuthProvider providerFor(@Nullable String strategy, @NonNull String connection){ + AuthProvider provider = null; + if ("linkedin".equals(strategy)) { + provider = new MyLinkedInProvider(); + } else if ("twitter".equals(strategy)) { + if (connection.equals("twitter-dev")) { + provider = new TwitterDevProvider(); + } else { + provider = new TwitterProvider(); + } + } + return provider; + } +} +``` + +Finally, on the `Lock.Builder` class you need to set the AuthHandlers to use on that **Lock** instance. + +```java +builder.withAuthHandlers(Arrays.asList(new MyAuthHandler())); +``` + +This way when **Lock** needs to authenticate a user with OAuth, it will ask the handlers **respecting the given order**, which of them can handle a given connection/strategy name. If the first one can handle it, the second won't be called. If no handlers can match the request (Lock received `null`), Lock will internally default to use `WebAuthProvider`. Also note that `strategy` can be null. + +::: note +In this example we used `MyLinkedInProvider`, `TwitterDevProvider` and `TwitterProvider` classes **not** included in **Lock**. +::: + +Our Google and Facebook [native social providers](/libraries/lock-android/v2/native-social-authentication) will provide `AuthHandler`s for you to use directly with **Lock**. diff --git a/fr-ca/articles/libraries/lock-android/v2/custom-fields.md b/fr-ca/articles/libraries/lock-android/v2/custom-fields.md new file mode 100644 index 0000000000..f68d7cf54b --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/custom-fields.md @@ -0,0 +1,84 @@ +--- +section: libraries +title: Lock Android v2 Custom Fields at Signup +description: Adding additional fields to signups with Lock for Android +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Custom Fields at Signup + +**Lock.Android** allows you to specify additional fields that the user must complete before creating a new account. The extra fields will be shown on a second screen after the user completes the basic fields (email, username, password). + +## Create the Custom Fields + +Create a new `CustomField` object passing all these 4 mandatory parameters. + +1. Icon: The `int` that points to the resource you want to use as Icon (keep it small). +1. Type: The `FieldType` to use in this field. The type defines the keyboard layout and sometimes the input validation. +1. Key: The `String` that identifies this value in the result JSON. It shouldn't be repeated! Repeated field keys will result in the second field getting removed from the list. +1. Hint: The `@StringRes` of the text to show as hint in the field. + +In addition, you can specify where the field is going to be stored on the user's profile. See the [Storage](#storage) section below for details. + +```java +List customFields = new ArrayList<>(); + +CustomField fieldName = new CustomField(R.drawable.ic_field_person, FieldType.TYPE_TEXT_NAME, "firstName", R.string.hint_first_name); +customFields.add(fieldName); +``` + +Repeat the above steps as many times as fields you need. + +## Use the Custom Fields + +Create a new `List` to store the fields. Pass the list to the `Lock.Builder` before you build it, using the method `withSignUpFields()`. + +```java +Lock lock = Lock.newBuilder(auth0, callback) + .withSignUpFields(customFields) + //... + .build(this); +``` + +That's it! If you have enabled users Sign Up in the Application's Dashboard, after they complete the basic fields (email/username, password) and hit Submit, they will be prompted to fill the remaining fields. + +::: note +The user must fill all of the custom fields before being able to complete signup. +::: + +When requesting a user Sign Up or Sign In, the extra fields will be attached to the `user_metadata` attribute in the request body. You can access them by querying the user profile at any time, even from the Dashboard in the User's section. + +## Field Types + +Each custom field can only have one `FieldType` associated. + +* TYPE_NAME +* TYPE_NUMBER +* TYPE_PHONE_NUMBER +* TYPE_EMAIL + +## Storage + +Each custom field can only have one `Storage` associated. You can choose to store it right at the root level in a root attribute or inside the `user_metadata` attribute. To specify the storage location, use the five-parameter constructor and pass the `Storage` parameter of your choice (see below). By default, fields will be stored inside the `user_metadata` attribute. + +Available choices: + +* PROFILE_ROOT +* USER_METADATA (default) + +```java +CustomField fieldName = new CustomField(R.drawable.ic_field_person, FieldType.TYPE_TEXT_NAME, "firstName", R.string.hint_first_name, Storage.PROFILE_ROOT); +``` + +::: note +For the fields to be saved at the root level of the user's profile, their keys must match the ones listed in the [endpoint documentation](/api/authentication#signup). +::: + diff --git a/fr-ca/articles/libraries/lock-android/v2/custom-theming.md b/fr-ca/articles/libraries/lock-android/v2/custom-theming.md new file mode 100644 index 0000000000..9ed6a02d3f --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/custom-theming.md @@ -0,0 +1,107 @@ +--- +section: libraries +title: Lock Android v2 Custom Theming +description: Customizing the Lock for Android UI +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Custom Theming + +The **Lock.Android** UI is very customizable. Various items such as the header logo and title, some colors, buttons, and other items can be altered. + +## Supported attributes list + +| Name | Type | Description | +| :--- | :---: | :--- | +|Auth0.HeaderLogo | drawable - reference | Logo drawable to display inside the header. | +|Auth0.HeaderTitle | string - reference | Text to display as Title inside the header. | +|Auth0.HeaderTitleColor | color - reference | Color for the Title text. | +|Auth0.HeaderBackground | color - reference | Used as background color in the header. | +|Auth0.PrimaryColor | color - reference | Used as _normal_ state in widgets like the Submit button. Also used as _accent_ color. | +|Auth0.DarkPrimaryColor | color - reference | Used as _pressed_ state in widgets like the Submit button. | + +## Create a New Resource File + +First you need to create a new `Theme` that extends from `Lock.Theme`, and override the attributes you want to customize. + +styles.xml + +```xml + + + +``` + +::: note +Those attributes not overridden by the user will default to the ones defined in `Lock.Theme`. +::: + +Then, you need to tell the Manifest that you want to use the new `MyTheme` in the `Activity`. This is **very important**!! + +```xml + + + + + + +``` + +## Pay Attention to the Manifest + +Please note that if you define your own Theme in a style resource file and forget to specify that the Theme's parent is `Lock.Theme`, or you forget to tell the Manifest which will be the Theme for the Activity, you will end up with a really bad looking UI. This may also happen if the values you specify in your custom Theme are invalid. + +## Custom OAuth Connection Buttons + +::: note +In order to customize OAuth connection styles, first you must create a new connection by using the `Custom Social Connections` [extension](${manage_url}/#/extensions), filling in every required field before saving the changes. +::: + +To customize OAuth connection styles in Lock you can call the builder passing both the `connectionName` and the `style` to use. + +First create a custom style extending `Lock.Theme.AuthStyle` and define the logo, background color and name of the connection. + +```xml + +``` + +Now in the builder's setup add the `AuthStyle` for the connection name that you want to override. + +```java +builder.withAuthStyle("facebook", R.style.Style_Facebook) + .build(...); +``` + +When **Lock** needs to display that connection in a **SocialButton**, it will first search for user-overridden styles, and if none are found, it will default to the Lock social defaults. This means that for `facebook` in particular it would use Facebook background color, Facebook logo and `FACEBOOK` as name. + +As the builder method receives the `connectionName` you can then customize `oauth2` strategy type connections. The default values for this strategy (if none are provided) are the Auth0 logo, Auth0 background color, and `OAUTH2` as the name. diff --git a/fr-ca/articles/libraries/lock-android/v2/delegation-api.md b/fr-ca/articles/libraries/lock-android/v2/delegation-api.md new file mode 100644 index 0000000000..98291b7eb8 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/delegation-api.md @@ -0,0 +1,57 @@ +--- +section: libraries +title: Lock for Android v2 Delegation API +description: Integrate with third-party apps with the delegation API. +topics: + - libraries + - lock + - android +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Delegation API + +<%= include('../../../_includes/_deprecate-delegation') %> + +After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/api/authentication/reference#delegation) using a valid JWT. + +Here's an example + +```java +Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); +auth0.setOIDCConformant(true); +AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); +String apiType = "firebase"; +String token = //Your Auth0 ID Token of the logged in User +client.delegationWithIdToken(token, apiType) + .start(new BaseCallback, AuthenticationException>() { + @Override + public void onSuccess(Map payload) { + //Your Firebase token will be in payload + } + + @Override + public void onFailure(AuthenticationException error) { + //Delegation call failed + } + }); +``` + +::: note +The delegation response is a generic Map since the structure of it will depend of the `api_type` used for delegation +::: + +The only two parameters required are `id_token` and `api_type`, the former is the token returned by Auth0 after a successful authentication, the latter specifies the API credentials we want to retrieve, and these are its supported values: + +* app: Your Auth0 application. This will get a new JWT token. +* aws: Amazon Web Services API. +* azure_sb: Windows Azure Service Bus. +* firebase: Firebase API. +* salesforce_api: Salesforce API. +* salesforce_sandbox_api: Salesforce Sandbox API. +* sap_api: SAP OData. +* wams: Windows Azure Mobile Services. diff --git a/fr-ca/articles/libraries/lock-android/v2/index.md b/fr-ca/articles/libraries/lock-android/v2/index.md new file mode 100644 index 0000000000..1eb9d180a9 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/index.md @@ -0,0 +1,297 @@ +--- +section: libraries +toc: true +title: Lock for Android v2 +description: A widget that provides a frictionless login and signup experience for your native Android apps. +mobileimg: media/articles/libraries/lock-android.png +topics: + - libraries + - lock + - android +contentType: + - index + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Getting Started + +::: warning +Auth0 encourages the use of [web authentication via Universal Login](/guides/login/universal-vs-embedded) rather than native username/password authentication whenever possible. +::: + +Lock for Android can integrate into your native Android apps to provide a beautiful way to log your users in and to sign them up in your app. It provides support for social identity providers such as Facebook, Google, or Twitter, as well as enterprise providers such as Active Directory. + +Get started using Lock for Android below, or if you're looking for a specific document beyond basic setup of Lock, try the listing of [next steps](#next-steps) for working with Lock for Android. + +::: note +Check out the [Lock.Android repository](https://github.com/auth0/Lock.Android) on GitHub. +::: + +## Requirements + +To use Lock's UI or your own UI via the [Auth0.Android library](https://github.com/auth0/Auth0.Android) the minimum required Android API level is 15+. + +## Installation + +Lock is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To start using *Lock* add these lines to your `build.gradle` dependencies file: + +```gradle +compile 'com.auth0.android:lock:2.+' +``` + +::: note +You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock). +::: + +After adding your Gradle dependency, make sure to remember to sync your project with Gradle files. + +## Dashboard settings + +You need to fill in a few settings in your [Auth0 Dashboard](${manage_url}) before you get started. + +### Callback URL + +Head over to your Auth0 Dashboard and go to the application's settings. Add the following URL to the application's "Allowed Callback URLs" + +```text +https://${account.namespace}/android/{YOUR_APP_PACKAGE_NAME}/callback +``` + +::: note +Replace `{YOUR_APP_PACKAGE_NAME}` with your actual application's package name, available in your `app/build.gradle` file as the `applicationId` value. +::: + +### Keystores and key hashes + +You will need a [Keystore](https://developer.android.com/studio/publish/app-signing.html) for signing your Android app. If you already have one, you can continue and skip the instructions about acquiring one. + +During development, you can use the default "android debug keystore" to sign your application. For instructions on how to generate the key hashes using this keystore, use our [Android Keystores and Key Hashes Guide](/libraries/lock-android/v2/keystore). + +For a release keystore, replace the file, alias, store password and key password with your own values. + +## Implementing Lock (Social, Database, Enterprise) + +The following instructions discuss implementing Lock for Android. If you specifically are looking to implement Passwordless Lock for Android, read the [Passwordless Authentication with Lock for Android](/libraries/lock-android/v2/passwordless) page. + +### Configuring the SDK + +In your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI. + +```groovy +apply plugin: 'com.android.application' + +android { + compileSdkVersion 25 + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 15 + targetSdkVersion 25 + //... + + //---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"] + //<--- + } + //... +} +``` + +It's a good practice to define reusable resources like `@string/com_auth0_domain` but you can also hard code the value to `${account.namespace}` in the file. + +Next, modify the `AndroidManifest.xml` file. Add the `android.permission.INTERNET` permission to allow Lock to make requests to the Auth0 API. + +```xml + +``` + +Add the `LockActivity`. + +```xml + +``` + +::: note +In versions 2.5.0 or lower of Lock.Android you had to define an **intent-filter** inside the `LockActivity` to make possible to the library to capture the authentication result. This intent-filter declaration is no longer required for versions greater than 2.5.0, as it's now done internally by the library for you. +::: + +In case you are using an older version of Lock the **intent-filter** must be added to the `LockActivity` by you: + +```xml + + + + + + /callback" + android:scheme="https" /> + + +``` + +#### Some restrictions + +* Make sure the `LockActivity` launchMode is declared as `singleTask` or the result won't come back after the authentication. +* Also note that for the time being, `LockActivity` can't be launched by calling `startActivityForResult`. + +### Auth0 + +Create an `Auth0` instance to hold your account details, which are the `AUTH0_CLIENT_ID` and the `AUTH0_DOMAIN`. + +```java +Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); +``` + +### OIDC Conformant Mode + +It is strongly encouraged that Lock be used in OIDC Conformant mode. When this mode is enabled, it will force Lock to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. By default is `false`. + +```java +Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); +//Configure the account in OIDC conformant mode +account.setOIDCConformant(true); +//Use the account to launch Lock +``` + +For more information, please see the [OIDC adoption guide](/api-auth/tutorials/adoption). + +### Authentication callback + +You'll also need a `LockCallback` implementation. Here is an example which will notify you about Authentication events (logins). + +```java +private LockCallback callback = new AuthenticationCallback() { + @Override + public void onAuthentication(Credentials credentials) { + //Authenticated + } + + @Override + public void onCanceled() { + //User pressed back + } + + @Override + public void onError(LockException error) + //Exception occurred + } + }; +``` + +::: note +The results of the AuthenticationCallback are in a `credentials` object. This object contains the tokens that you will require for authentication related operations in your app; see [Tokens](/tokens) for more specifics. +::: + +### Lock.Builder + +To create a new `Lock` instance and configure it, use the `Lock.Builder` class. Call the static method `Lock.newBuilder(Auth0, LockCallback)`, passing the account details and the callback implementation, and start configuring the Options as you need. After you're done, build the Lock instance and use it to start the `LockActivity`. + +To ensure a response that complies with OpenID Connect (OIDC), you must either request an `audience` or enable the **OIDC Conformant** switch in your Auth0 dashboard under `Application / Settings / Advanced OAuth`. You can read more about this [here](/api-auth/intro#how-to-use-the-new-flows). + +This is an example of what your `Activity` should look: + +```java +public class MainActivity extends Activity { + private Lock lock; + + @Override + protected void onCreate(@Nullable Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + // Your own Activity code + Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); + auth0.setOIDCConformant(true); + lock = Lock.newBuilder(auth0, callback) + .withAudience("https://${account.namespace}/userinfo") + // ... Options + .build(this); + } + + @Override + public void onDestroy() { + super.onDestroy(); + // Your own Activity code + lock.onDestroy(this); + lock = null; + } + + private LockCallback callback = new AuthenticationCallback() { + @Override + public void onAuthentication(Credentials credentials) { + //Authenticated + } + + @Override + public void onCanceled() { + //User pressed back + } + + @Override + public void onError(LockException error) { + //Exception occurred + } + }; +} +``` + +Remember to notify Lock's instance when your activity calls the `OnDestroy` method, as it helps to keep the state. + +Then, start `Lock` from inside your activity. + +```java +startActivity(lock.newIntent(this)); +``` + +That's it! Lock will handle the rest for you. + +### Android App Links - Custom Scheme + +The callback URI scheme used in this article is `https`. This works best for Android Marshmallow (API 23) or newer if you're using [Android App Links](https://developer.android.com/training/app-links/index.html), but in previous Android versions this may show the intent chooser dialog prompting the user to chose either your application or the browser to resolve the intent. You can change this behavior by using a custom unique scheme so that the OS opens the link directly with your app. +Do so by updating the `app/build.gradle` file and changing the `auth0Scheme` value. Then go to your application's dashboard and update the "Allowed callback URL" value to match the new scheme. Now call `withScheme()` in the Lock.Builder and pass the custom value so that Lock requests the correct redirect URI. + +## Implementing Passwordless authentication with Lock for Android + +For instructions on how to implement Passwordless authentication with Lock for Android, please see the [Passwordless Guide](/libraries/lock-android/v2/passwordless). + +## Proguard + +The proguard rules should be applied automatically if your application is using `minifyEnabled = true`. If you want to include them manually check the [proguard directory](https://github.com/auth0/Lock.Android/tree/master/proguard). By default you should at least use the following files: + +By default you should at least use the following files: + +* `proguard-gson.pro` +* `proguard-otto.pro` +* `proguard-lock-2.pro` + +As this library depends on `Auth0.Android`, you should keep the files up to date with the proguard rules defined in that [repository](https://github.com/auth0/Lock.Android). + +## Lock configuration + +For a full list of Lock's configuration options, check out the [Lock for Android Configuration Reference](/libraries/lock-android/v2/configuration). + +## Error messages + +For descriptions of common error messages, check out the [Error Messages](/libraries/error-messages) page. Also, if your callback receives an `AuthenticationException` you can check [source](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/authentication/AuthenticationException.java) to learn how to identify each error scenario. + +## Next Steps + +::: next-steps +* [Customizing the Style of Lock](/libraries/lock-android/custom-theming) +* [Customizing the Behavior of Lock](/libraries/lock-android/configuration) +* [Adding Custom Signup Fields to Lock](/libraries/lock-android/custom-fields) +* [Lock Internationalization](/libraries/lock-android/internationalization) +* [Logging out Users](/logout) +::: diff --git a/fr-ca/articles/libraries/lock-android/v2/internationalization.md b/fr-ca/articles/libraries/lock-android/v2/internationalization.md new file mode 100644 index 0000000000..f2dc13d979 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/internationalization.md @@ -0,0 +1,44 @@ +--- +section: libraries +title: Lock Android v2 Internationalization +description: Internationalization support in Lock for Android +topics: + - libraries + - lock + - android + - i18n +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Internationalization + +By default, **Lock.Android** displays all text in English. If you wish to display text in another language, you may provide a `strings.xml` file and define values to be used for the various text items that Lock might display. + +Android asks the device what _locale_ was configured by the user and tries to fetch the list of localized texts for that language. For this to work, the developer needs to add each translation file into the app by using a special folder naming convention as per Android standards. More information can be found in the [Android developer docs](https://developer.android.com/training/basics/supporting-devices/languages.html). + +Some of the default values provided by Lock include: + +```html + + Error parsing Authentication data + There was an error during authentication + ... + +``` + +By providing your own `strings.xml` file, these values can be adjusted as such: + +```html + + There was an authentication error! + Social login error!! + ... + +``` + +## Lock String Values + +For a full list of the names used by Lock, see the [default strings.xml file](https://github.com/auth0/Lock.Android/blob/master/lib/src/main/res/values/strings.xml) in the Lock.Android repository. diff --git a/fr-ca/articles/libraries/lock-android/v2/keystore.md b/fr-ca/articles/libraries/lock-android/v2/keystore.md new file mode 100644 index 0000000000..7b31c26d29 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/keystore.md @@ -0,0 +1,64 @@ +--- +section: libraries +title: Android Development Keystores and Key Hashes +description: Instructions on acquiring development keystores/key hashes during Android app development. +topics: + - libraries + - lock + - android +contentType: + - how-to + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Android Development Keystores and Key Hashes + +When creating a new OAuth Credential for many connections you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's configuration in the [Auth0 Dashboard](${manage_url}) you will also need to provide the SHA-256 value. + +Locate the certificate you're using to sign your application. If you don't have one you can generate it. For production applications, you should do this. + +During development, you can sign your application with the default `android.keystore` certificate that was generated automatically for you when you installed the SDK. In this example we're going to use this default keystore. To generate the key hashes using this keystore follow the examples below. + +## Generating your key hashes + +**On Windows:** + +```bash +keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android +``` + +**On Linux / macOS:** + +```bash +keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android +``` + +**Sample output:** + +```text +Alias name: androiddebugkey +Creation date: Jan 01, 2013 +Entry type: PrivateKeyEntry +Certificate chain length: 1 +Certificate[1]: +Owner: CN=Android Debug, O=Android, C=US +Issuer: CN=Android Debug, O=Android, C=US +Serial number: 4aa9b300 +Valid from: Mon Jan 01 08:04:04 UTC 2013 until: Mon Jan 01 18:04:04 PST 2033 +Certificate fingerprints: + MD5: AE:9F:95:D0:A6:86:89:BC:A8:70:BA:34:FF:6A:AC:F9 + SHA1: BB:0D:AC:74:D3:21:E1:43:07:71:9B:62:90:AF:A1:66:6E:44:5D:75 + SHA256: 15:B9:F9:33:9F:E4:E3:68:C2:10:49:17:5D:A8:77:12:7C:8E:57:E9:FF:B7:23:EA:CC:DD:56:08:06:C9:5E:33 + Signature algorithm name: SHA256withRSA + Version: 3 +``` + +## Using your key hashes + +Once you have your key hashes output, copy the resulting SHA256 value and go to your application's settings in the [Auth0 Dashboard](${manage_url}/#/applications). Click "Show Advanced Settings", and in the "Device Settings" tab, under "Android", fill the "App Package Name" with your application's package name, and the "Key Hashes" field with the SHA256 value you copied. Don't forget to save the changes. + +::: warning +If you don't add the Callback URL to the application settings nor the Key Hashes to the application's device settings, the Auth0 server won't return the call result to your application. +::: diff --git a/fr-ca/articles/libraries/lock-android/v2/migration-guide.md b/fr-ca/articles/libraries/lock-android/v2/migration-guide.md new file mode 100644 index 0000000000..7fcc499bb9 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/migration-guide.md @@ -0,0 +1,67 @@ +--- +section: libraries +title: Lock Android v2 Migration Guide +description: A reference for changed option names and behaviors in Lock for Android v2 +public: false +topics: + - libraries + - lock + - android + - migrations +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth + - migrate +--- +# Lock Android: Migration Guide + +## Application Class and Initializing Lock + +In v1 of Lock for Android, you were asked to create a custom `Application` class and initialize the `Lock.Context` there. **Now this is no longer needed**. In v2, to create a new `Lock` instance and configure it, you will just use the `Lock.Builder` class. The configurable options in v2 have been expanded, allowing more configuration while making the implementation and customization process easier than in v1. + +## Obtaining the User's Profile + +In v1, when an authentication was successful, you could obtain the UserProfile from the received Intent. As of v2, the only received value is a `Credentials` object. You can get the Access Token and request the information associated to that user, by making a request to Auth0. + +1. Create a new `AuthenticationAPIClient` instance by passing an instance of the `Auth0` object. It can be the same instance used to launch Lock in the first place. +1. Call the `userInfo` method on the API application passing the previously obtained Access Token. +1. A `UserProfile` instance is returned + +```java +Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); +auth0.setOIDCConformant(true); +String accessToken = credentials.getAccessToken(); +AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0); + +apiClient.userInfo(accessToken) + .start(new BaseCallback() { + @Override + public void onSuccess(final UserProfile information) { + //user information received + } + + @Override + public void onFailure(AuthenticationException error) { + //user information request failed + } + }); +``` + +## Changed Configuration Options + +As in the previous version, Lock for Android v2 can be configured with extra options. Check below if the behavior for the option has changed, or if they only got renamed. + +* `shouldUseWebView`: This option was renamed to `useBrowser`, but is now entirely **deprecated** and should not be used. +* `shouldUseEmail`: Renamed to `withUsernameStyle`. Defines if it should ask for email only, username only, or both of them. By default it'll respect the Dashboard configuration of the parameter `requires_username`. +* `isClosable`: Renamed to `closable`. Defines if the `LockActivity` can be closed. By default it's not closable. +* `shouldLoginAfterSignUp`: Renamed to `loginAfterSignUp`. Determines whether after a signup the user should be logged in automatically. Defaults to `true`. +* `disableSignupAction`: Renamed to `allowSignUp`. Shows the Sign Up form if a Database connection is configured. Defaults to `true`. +* `disableResetAction`: Renamed to `allowForgotPassword`. Shows a link to the Forgot Password form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`. +* `defaultUserPasswordConnection`: Renamed to `setDefaultDatabaseConnection`. Defines which will be the default Database connection. This is useful if your application has many Database connections configured. +* `setConnections`: Renamed to `allowedConnections`. Filters the allowed connections from the list configured in the Dashboard. If this value is empty, all the connections defined in the dashboard will be available. This is also the default behavior. +* `setAuthenticationParameters`: Renamed to `withAuthenticationParameters`. Defines extra authentication parameters to be sent on sign up and log in/sign in. The default `scope` used on authentication calls is `openid`. This is changed from v1, which also included the `offline_access` scope. + +Lock for Android v2 also features a bunch of new options. Check the [configuration options page](/libraries/lock-android/configuration) for a complete list of them. diff --git a/fr-ca/articles/libraries/lock-android/v2/native-social-authentication.md b/fr-ca/articles/libraries/lock-android/v2/native-social-authentication.md new file mode 100644 index 0000000000..94576b4705 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/native-social-authentication.md @@ -0,0 +1,405 @@ +--- +section: libraries +title: Lock Android v2 Native Social Authentication +description: Lock for Android - Native Social Authentication +topics: + - libraries + - lock + - android + - native + - social-connections +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Native Social Authentication + +::: warning +This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. +We recommend using browser-based flows, as explained in [Authentication via Auth0 Universal Login](/libraries/auth0-android#authentication-via-universal-login). +::: + +## Native Provider - Google + +You can use Google AuthProvider to log in with or without **Lock**. Make sure to follow the instructions in the [setup](#setup) section. + +[Lock-Google.Android](https://github.com/auth0/Lock-Google.Android) + requires Android API 15 or later & Google Play Services 10.+ + +### Latest version of Lock-Google + +The Lock-Google is available through [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To install it, simply add the following line to your `build.gradle`: + +```gradle +compile 'com.auth0.android:lock-google:1.+' +``` + +::: note +You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock-Google.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock-google%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock-google). +::: + +### Lock-Google Setup + +#### Google Developers Console + +1. Go to the [Google Developers Console](https://console.developers.google.com/) and create a new Project. +2. Complete the [OAuth Consent Screen](https://console.developers.google.com/apis/credentials/consent) by at least providing a valid Email Address and Name. +3. On the left side you have the navigation drawer, click [Credentials](https://console.developers.google.com/apis/credentials). +4. Create a new credential by clicking the [Create Credentials](https://console.developers.google.com/apis/credentials/oauthclient) button and choosing **OAuth client ID**. Next, choose **Web Application** and give it a name like "Auth0 Server Google-OAuth". Complete the **Authorized redirect URIs** by filling the field with your callback URL, which should look like `https://${account.namespace}/login/callback`. Make sure to press ENTER before leaving the field and then click the Create button. Take note of the `CLIENT ID` and `CLIENT SECRET` values as we're going to use them later. +5. Create a new credential by clicking the [Create Credentials](https://console.developers.google.com/apis/credentials/oauthclient) button and choosing **OAuth client ID**. Next, choose **Android** and give it a name like "Auth0 Android Google-OAuth". Obtain the **SHA-1** of the certificate you're using to sign your application and complete the first field with it. If you need help obtaining the SHA-1 check [this](#certificate-fingerprints) section. Finally, complete the last field with your android application **Package Name** and then click the Create button. Take note of the `CLIENT ID` value as we're going to use it later. + +#### Auth0 Dashboard + +1. Go to the Auth0 Dashboard and click [Social Connections](${manage_url}/#/connections/social). +2. Click **Google** and a dialog will prompt. +3. Complete the "Client ID" field with the `CLIENT ID` value obtained in the step 4 of the **Google Developers Console** section above. +4. Complete the "Client Secret" field with the `CLIENT SECRET` value obtained in the step 4 of the **Google Developers Console** section above. +5. Complete the "Allowed Mobile Client IDs" field with the `CLIENT ID` obtained in the step 5 of the **Google Developers Console** section above. +6. Click the Save button. +7. Go to the Auth0 Dashboard and click [Applications](${manage_url}/#/applications). If you haven't created yet one, do that first and get into your application configuration page. +8. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Device Settings" tab. +9. In the Android section, complete the **Package Name** with your application's package name. Finally, complete the **Key Hashes** field with the SHA-256 of the certificate you're using to sign your application. If you need help obtaining the SHA-256 check [this](#certificate-fingerprints) section. Click the "Save Changes" button. + +#### Android application + +1. In your android application, create a new String resource in the `res/strings.xml` file. Name it `google_server_client_id` and set as value the `CLIENT_ID` obtained in the step 5 of the **Google Developers Console** setup section above. +2. Add the Google Play Services version MetaData to the `AndroidManifest.xml` file, inside the Application tag. + +```xml + +``` + +3. Add the Internet Android permission to your `AndroidManifest.xml` file. + +```xml + +``` + +4. When creating a new instance of the `GoogleAuthProvider` pass the `google_server_client_id` value obtained previously as the first parameter: + +```java +public class MainActivity extends AppCompatActivity { + private GoogleAuthProvider provider; + // ... + + @Override + protected void onCreate(Bundle savedInstanceState) { + Auth0 auth0 = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain)); + auth0.setOIDCConformant(true); + AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); + provider = new GoogleAuthProvider(getString(R.string.google_server_client_id), client); + } + + // ... +} +``` + +::: note +If you need further help with the Google SDK setup, please check Google's [Sign-In for Android Guide](https://developers.google.com/identity/sign-in/android). +::: + +### Usage with Lock + +If you plan to use this provider with **Lock**, pass the instance of the provider to the `GoogleAuthHandler` class and add it to Lock's Builder when you create the Lock instance. + +```java +GoogleAuthHandler handler = new GoogleAuthHandler(provider); +lock = Lock.newBuilder(auth0, authCallback) + .withAuthHandlers(handler) + //... + .build(this); +``` + +### Usage without Lock + +If you plan to use this provider without **Lock**, make sure you override the `onActivityResult()` method and redirect the call to the provider instance. Finally, call start to begin the authentication process. + +```java +// Define your own request codes +private static final int RC_PERMISSIONS = 101; +private static final int RC_AUTHENTICATION = 102; + +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + if (provider.authorize(requestCode, resultCode, data)) { + return; + } + super.onActivityResult(requestCode, resultCode, data); +} + +private void beginAuthentication(){ + provider.start(this, callback, RC_PERMISSIONS, RC_AUTHENTICATION); +} +``` + +That's it, you're ready to run the application and log in using Google native provider!! + +### Additional Options + +#### Using a custom connection name + +To use a custom social connection name to authorize against Auth0, create the GoogleAuthProvider instance using the second constructor: + +```java +GoogleAuthProvider provider = new GoogleAuthProvider("my-connection", "google-server-client-id", client); +``` + +#### Send additional authentication parameters + +To send additional parameters on the authentication call `setParameters`. + +```java +Map parameters = new HashMap<>(); +//Add entries +provider.setParameters(parameters); +``` + +#### Requesting a custom Google scope + +By default, the scope `Scopes.PLUS_LOGIN` is requested. You can customize the Scopes by calling `setScopes` with the list of Scopes. Each Google API (Auth, Drive, Plus..) specify its own list of Google Scopes. + +```java +provider.setScopes(Arrays.asList(new Scope(Scopes.PLUS_ME), new Scope(Scopes.PLUS_LOGIN))); +``` + +#### Requesting custom Android runtime permissions + +This provider doesn't require any special _Android Manifest Permissions_ to authenticate the user. But if your use case requires them, you can let the AuthProvider handle them for you. Use the `setRequiredPermissions` method. + +```java +provider.setRequiredPermissions(new String[]{"android.permission.GET_ACCOUNTS"}); +``` + +If you're not using Lock then you'll have to handle the permission request result yourself. To do so, make your activity implement the `ActivityCompat.OnRequestPermissionsResultCallback` interface. When the `onRequestPermissionsResult` method gets called pass the result to the provider by calling `provider.onRequestPermissionsResult`. + +#### Log out / clear account. + +To log out the user so that the next time they are prompted to input their credentials call `clearSession`. After you do this the provider state will be invalid and you will need to call `start` again before trying to `authorize` a result. Calling `stop` has the same effect. + +```java +provider.clearSession(); +``` + +#### Remember the last login + +By default this provider will remember the last account used to log in. If you want to change this behavior, use the following method. + +```java +provider.rememberLastLogin(false); +``` + +#### Certificate fingerprints + +When creating a new OAuth Credential in the Google Developers Console you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's Configuration in the Auth0 Dashboard you will also need to provide the SHA-256 value. Here is an example of the terminal command to acquire the value, and a sample result. + +Command: + +```sh +keytool -exportcert -alias androiddebugkey -keystore -storepass android | openssl sha1 -binary | openssl base64 +``` + +Sample output: + +```text +no71633JAC3qgzQYCbskprUr55k= +``` + +If you need assistance, you can follow this [Keystores Guide](/libraries/lock-android/keystore) to acquire those values. + + +## Native Provider - Facebook + +You can use Facebook AuthProvider to log in with or without **Lock**. Make sure to follow the instructions in the [setup](#setup) section. + +[Lock-Facebook](https://github.com/auth0/Lock-Facebook.Android) requires Android API 15 or later & Facebook Android SDK 4.+ + +## Latest version + +The Lock-Facebook is available through [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To install it, simply add the following line to your `build.gradle`: + +```gradle +compile 'com.auth0.android:lock-facebook:3.+' +``` + +_You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock-Facebook.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock-facebook%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock-facebook)._ + +### Lock-Facebook Setup + +#### Facebook Developers Console + +1. Go to the [Facebook Developers Console](https://developers.facebook.com/) and create a new App: Choose "Android" and give it a valid name. Click "Create new Facebook App ID". +2. Add your application's **Package Name** and the name of the **Activity class** where you're using the provider and click the Next button. +3. Add the **SHA-1** Base64 encoded Key Hashes of the certificates you're using to sign your application and click the Next button. If you need help obtaining the SHA-1 check [this](#certificate-fingerprints) section. +4. Finally, scroll to the top of the page and click the Skip Quickstart button to go to your Facebook app's page. +5. On the top of the page, you will find the `APP ID` and `APP SECRET` values. Save them as you're going to need them later. +6. On the left side you have the navigation drawer. Click Settings and then Basic. Turn ON the **Single Sign-On** switch and click the Save button. +7. Click Settings and then Advanced. Turn ON the **Native or desktop app?** switch. + +#### Auth0 dashboard + +1. Go to the Auth0 Dashboard and click [Social Connections](${manage_url}/#/connections/social). +2. Click **Facebook** and a dialog will prompt. +3. Complete the "App ID" field with the `APP ID` value obtained in the step 5 of the **Facebook Developers Console** section above. +4. Complete the "App Secret" field with the `APP SECRET` value obtained in the step 5 of the **Facebook Developers Console** section above. +5. Click the Save button. +6. Go to the Auth0 Dashboard and click [Applications](${manage_url}/#/applications). If you haven't created yet one, do that first and get into your application configuration page. +7. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Device Settings" tab. +8. In the Android section, complete the **Package Name** with your application's package name. Finally, complete the **Key Hashes** field with the SHA-256 of the certificate you're using to sign your application. If you need help obtaining the SHA-256 check [this](#certificate-fingerprints) section. Click the "Save Changes" button. + +#### Android application + +1. In your android application, create a new String resource in the `res/strings.xml` file. Name it `facebook_app_id` and set as value the `APP ID` obtained in the step 5 of the **Facebook Developers Console** setup section above. +2. Add the `FacebookActivity` and `facebook_app_id` MetaData to the `AndroidManifest.xml` file, inside the Application tag. + +```xml + + +``` + +3. Add the Internet Android permission to your `AndroidManifest.xml` file. + +```xml + +``` + +4. Create a new instance of the `FacebookAuthProvider`. + +```java +public class MainActivity extends AppCompatActivity { + private FacebookAuthProvider provider; + // ... + + @Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + Auth0 auth0 = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain)); + auth0.setOIDCConformant(true); + AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); + provider = new FacebookAuthProvider(client); + } + + // ... +} +``` + +::: note +If you need further help with the Facebook SDK setup, please check Facebook's [Getting Started Guide](https://developers.facebook.com/docs/android/getting-started). +::: + +### Usage with Lock + +If you plan to use this provider with **Lock**, pass the instance of the provider to the `FacebookAuthHandler` class and add it to Lock's Builder when you create the instance. + +```java +FacebookAuthHandler handler = new FacebookAuthHandler(provider); +lock = Lock.newBuilder(auth0, authCallback) + .withAuthHandlers(handler) + //... + .build(this); +``` + +### Usage without Lock + +If you plan to use this provider without **Lock**, make sure you override the `onActivityResult()` method of your activity and redirect the call to the provider instance. Finally, call start to begin the authentication process. + +```java +// Define your own request codes +private static final int RC_PERMISSIONS = 101; +private static final int RC_AUTHENTICATION = 102; + +@Override +protected void onActivityResult(int requestCode, int resultCode, Intent data) { + if (provider.authorize(requestCode, resultCode, data)) { + return; + } + super.onActivityResult(requestCode, resultCode, data); +} + +private void beginAuthentication(){ + provider.start(this, callback, RC_PERMISSIONS, RC_AUTHENTICATION); +} +``` + +That's it, you're ready to run the application and log in using Facebook native provider!! + +### Additional options + +#### Using a custom connection name + +To use a custom social connection name to authorize against Auth0, call `setConnection` with your new connection name. + +```java +FacebookAuthProvider provider = new FacebookAuthProvider("my_connection_name", client); +``` + +#### Send additional authentication parameters + +To send additional parameters on the authentication call `setParameters`. + +```java +Map parameters = new HashMap<>(); +//Add entries +provider.setParameters(parameters); +``` + +#### Requesting custom Facebook permissions + +By default, the permission `public_profile` is requested. You can customize them by calling `setPermissions` with the list of Facebook Permissions. + +```java +provider.setPermissions(Arrays.asList("public_profile", "user_photos")); +``` + +#### Requesting custom Android runtime permissions + +This provider doesn't require any special _Android Manifest Permissions_ to authenticate the user. But if your use case requires them, you can let the AuthProvider handle them for you. Use the `setRequiredPermissions` method to specify them. + +```java +provider.setRequiredPermissions(new String[]{"android.permission.GET_ACCOUNTS"}); +``` + +If you're not using Lock then you'll have to handle the permission request result yourself. To do so, make your activity implement the `ActivityCompat.OnRequestPermissionsResultCallback` interface. When the `onRequestPermissionsResult` method gets called pass the result to the provider by calling `provider.onRequestPermissionsResult`. + +#### Log out / clear account. + +To log out the user so that the next time they are prompted to input their credentials call `clearSession`. After you do this the provider state will be invalid and you will need to call `start` again before trying to `authorize` a result. Calling `stop` has the same effect. + +```java +provider.clearSession(); +``` + +#### Remember the last Login + +By default this provider will remember the last account used to log in. If you want to change this behavior, use the following method. + +```java +provider.rememberLastLogin(false); +``` + +### Certificate fingerprints + +When creating a new OAuth Credential in the Facebook Developers Console you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's Configuration in the Auth0 Dashboard you will also need to provide the SHA-256 value. Here is an example of the terminal command to acquire the value, and a sample result. + +Command: + +```sh +keytool -exportcert -alias androiddebugkey -keystore -storepass android | openssl sha1 -binary | openssl base64 +``` + +Sample output: + +```text +SHA1: BB:0D:AC:74:D3:21:E1:43:07:71:9B:62:90:AF:A1:66:6E:44:5D:75 +SHA256: 15:B9:F9:33:9F:E4:E3:68:C2:10:49:17:5D:A8:77:12:7C:8E:57:E9:FF:B7:23:EA:CC:DD:56:08:06:C9:5E:33 +``` + +If you need assistance, you can follow this [Keystores Guide](/libraries/lock-android/keystore) to acquire those values. diff --git a/fr-ca/articles/libraries/lock-android/v2/passwordless-magic-link.md b/fr-ca/articles/libraries/lock-android/v2/passwordless-magic-link.md new file mode 100644 index 0000000000..b2479a7542 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/passwordless-magic-link.md @@ -0,0 +1,167 @@ +--- +section: libraries +title: Lock Android v2 Passwordless with Magic Link +description: Passwordless with Magic Link with Lock Android +topics: + - libraries + - lock + - android + - passwordless + - magic-link +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Passwordless with Magic Link + +In order to avoid asking the user to input the one-time password sent for passwordless authentication in Android apps, we introduced the ability to send a link that the user can tap to login without any manual input involved. + +These links include the same code that would be used in the traditional passwordless flow, but with the correct configuration they will be handled automatically by the Android system and delivered to our application. + +## Auth0 Dashboard Configuration + +Go to your [application settings](${manage_url}/#/applications/${account.clientId}/settings) and click "Show Advanced Settings" at the bottom of the page. Then in the "Mobile Settings" tab you will need to provide both the Application's **Package Name** and certificate **Key Hash**. + +- **App Package Name**: This is the package name, as declared in the app's manifest. It's also available in the `app/build.gradle` file as the `applicationId` attribute. An example would be `com.example.android.myapp` +- **Key Hashes**: This is an array of the SHA256 fingerprints of our android app’s signing certificates. This is an arbitrary length array, it can include all the fingerprints we want, so for example we could add both our release and debug fingerprints. An example would be `DE:1A:5B:75:27:AA:48:D5:A6:72:2F:76:43:95:9B:79:C6:86:1A:5B:75:27:AA:48:D5:A6:73:FE`. + +After you set the values make sure to click the "Save Changes" button. Next we'll have to configure either the Email connection. + +### Getting your Signing Certificates Fingerprint + +You can use the following command to generate the fingerprint via the Java keytool: + +```bash +keytool -list -v -keystore my-release-key.keystore +``` + +or to obtain the default debug key: + +```bash +keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android +``` + +The value required by the dashboard is the one listed as **SHA256**. + +### Using Email Connection + +To use a passwordless connection via Email, we'll need to make sure the template is **HTML + Liquid** and that the email body contains *somewhere* a conditional like this: + +```liquid +{% if send == 'link' or send == 'link_ios' or send == 'link_android' %} +Your verification link is: {{ link }} +{% elsif send == 'code' %} +Your verification code is: {{ code }} +{% endif %} +``` + +## Application Configuration + +Now that we have the Auth0 application configured, before we start with the android configuration we must follow the instructions and set up PasswordlessLock with `Lock.Android` as seen in the [passwordless docs](/libraries/lock-android/v2/passwordless). The only difference is that we'll add **Intent-Filters** that will capture the link click and redirect the user back to our app. + +In the `AndroidManifest.xml` file add the intent-filters inside the `PasswordlessLockActivity` activity tag. Depending on the chosen passwordless connection, the `pathPrefix` of the filter changes. + +```xml + + + + + + + /email" + android:scheme="https" /> + + + +``` + +Make sure the Activity's `launchMode` is declared as `singleTask` or the result won't come back after the authentication. + +## Usage + +Lock Passwordless authenticates users by sending them an Email with a one-time password, which in this case will be a **LINK** instead of a CODE. We'll indicate this by calling the `useLink()` method. + +```java +public class MyActivity extends AppCompatActivity { + private PasswordlessLock lock; + + @Override + @SuppressWarnings("ConstantConditions") + protected void onCreate(@Nullable Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + // Your own Activity code + Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); + auth0.setOIDCConformant(true); + lock = PasswordlessLock.newBuilder(auth0, callback) + .useLink() + .build(this); + } + + @Override + public void onDestroy() { + super.onDestroy(); + // Your own Activity code + lock.onDestroy(this); + lock = null; + } + + private LockCallback callback = new AuthenticationCallback() { + @Override + public void onAuthentication(Credentials credentials) { + //Authenticated + } + + @Override + public void onCanceled() { + //User pressed back + } + + @Override + public void onError(LockException error) { + //Exception occurred + } + }; +} +``` + +Finally, just start `PasswordlessLock` from inside your activity and perform the login. + +```java +startActivity(lock.newIntent(this)); +``` + +After requesting the magic link from Auth0, the next screen will indicate that in order to log in, the user should tap it. We also offer a backup option to enter the code manually, just in case the links don't work. + +## Optional: Use Android App Links + +With App Links, in Android 6.0 (API level 23) and higher, Android allows an app to designate itself as the default handler of a given type of link, without asking the user whether to use the Browser or our app to open the link. +Automatic handling of links requires the cooperation of our app and website (our Auth0 Authentication Server). The app must declare the association with the website and request that the system verify it. The website must, in turn, provide that verification by publishing a [Digital Asset Links](https://developers.google.com/digital-asset-links/) file. +This feature works as long as the user has not already chosen a default app to handle that URI pattern in the Android settings. + +Auth0 will generate the [Digital Asset Links](https://developers.google.com/digital-asset-links/) file automatically for you after you've configured the **App Package Name** and **Key Hash** as shown before. If you've followed all the steps on this article, the only change you need to do is add an attribute to the **Intent-Filter** declaration in order to ask the OS to verify the link at install time. Go to the `AndroidManifest.xml` file where you have declared the Intent-Filter and add the `android:autoVerify="true"` attribute indicating use of an email connection: + +```xml + + + + + + /email" + android:scheme="https" /> + +``` + +This attribute is used since Android API 23 (Android 6.0) to indicate that we would like to verify the link association. **This is extremely important to avoid the dialog asking the user which application to use.** Although links will work on all versions of Android, the dialog asking the user whether to use the Browser or our app to open the link will be displayed (whether the verification passed or not) in versions of Android prior to 6.0, at least until the user chooses to always open the links with our app. + +You could find more information about App Links in the [Android docs](http://developer.android.com/training/app-links/index.html). diff --git a/fr-ca/articles/libraries/lock-android/v2/passwordless.md b/fr-ca/articles/libraries/lock-android/v2/passwordless.md new file mode 100644 index 0000000000..c5bbd7d967 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/passwordless.md @@ -0,0 +1,176 @@ +--- +section: libraries +title: Lock Android v2 Passwordless +description: Guide on implementing Passwordless authentication with Lock for Android +topics: + - libraries + - lock + - android + - passwordless +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Passwordless + +Lock Passwordless authenticates users by sending them an Email or SMS with a one-time password that the user must enter and confirm to be able to log in, similar to how WhatsApp authenticates you. This article will explain how to send a **CODE** using the `Lock.Android` library. + +::: note +You can achieve a similar result by sending a **LINK** that the user can click to finish the passwordless authentication automatically, but a few more configuration steps are involved. You can check that article [here](/libraries/lock-android/v2/passwordless-magic-link). +::: + +In order to be able to authenticate the user, your application must have the Email/SMS connection enabled and configured in your [Auth0 Dashboard](${manage_url}/#/connections/passwordless). + +To use Passwordless Authentication with Lock, you need to use Lock Android v2.17 or greater, and it needs to be configured with [OIDC Conformant Mode](/libraries/lock-android#oidc-conformant-mode) set to `true`. + +## Implementing CODE Passwordless + +In your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI. + +```groovy +apply plugin: 'com.android.application' + +android { + compileSdkVersion 25 + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 15 + targetSdkVersion 25 + //... + + //---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"] + //<--- + } + //... +} +``` + +It's a good practice to define reusable resources like `@string/com_auth0_domain` but you can also hard code the value to `${account.namespace}` in the file. + +Next, modify the `AndroidManifest.xml` file. Add the `android.permission.INTERNET` permission to allow Lock to make requests to the Auth0 API. + +```xml + +``` + +Add the `PasswordlessLockActivity`. Depending on which passwordless connection you need to handle, the `data` attribute of the **intent-filter** will differ: + +```xml + + + + + + /email" + android:scheme="https" /> + + +``` + +The `data` attribute of the intent-filter defines which syntax of "Callback URI" your app is going to capture. In the above case it's going to capture calls from `email` passwordless connections. In case you're using the `sms` passwordless connection, the `pathPrefix` would end in `sms`. + +::: note +In versions 2.5.0 or lower of Lock.Android you had to define an **intent-filter** inside the `PasswordlessLockActivity` to make possible to the library to capture a **Social** provider's authentication result. This intent-filter declaration is no longer required for versions greater than 2.5.0 , as it's now done internally by the library for you. +::: + +In case you are using an older version of Lock for Social Authentication, the **data** attribute that captures the "/callback" redirect URI inside the intent-filter must be added to the `PasswordlessLockActivity` by you. + +```xml + + + + + + + /email" + android:scheme="https" /> + + /callback" + android:scheme="demo" /> + + +``` + +Make sure the Activity's `launchMode` is declared as `singleTask` or the result won't come back in the authentication. + +When the Passwordless connection is SMS you must also add the `CountryCodeActivity` to allow the user to change the **Country Code** prefix of the phone number. + +```xml + +``` + +## Usage + +In any of your activities, you need to initialize `PasswordlessLock` and tell it to send a **CODE**. We'll indicate this by calling the `useCode()` method. + +```java +public class MainActivity extends Activity { + + private PasswordlessLock lock; + + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + // Your own Activity code + Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); + auth0.setOIDCConformant(true); + + lock = PasswordlessLock.newBuilder(auth0, callback) + .useCode() + .build(this); + } + + @Override + protected void onDestroy() { + super.onDestroy(); + // Your own Activity code + lock.onDestroy(this); + lock = null; + } + + private LockCallback callback = new AuthenticationCallback() { + @Override + public void onAuthentication(Credentials credentials) { + //Authenticated + } + + @Override + public void onCanceled() { + //User pressed back + } + + @Override + public void onError(LockException error) { + //Exception occurred + } + }; +} +``` + +Finally, just start `PasswordlessLock` from inside your activity and perform the login. + +```java +startActivity(lock.newIntent(this)); +``` + +Depending on which passwordless connections are enabled, Lock will send the CODE in an Email or SMS. The 'email' connection is selected first if available. Then the user must input the CODE in the confirmation step. If the value equals to the one the server is expecting, the authentication will be successful. diff --git a/fr-ca/articles/libraries/lock-android/v2/refresh-jwt-tokens.md b/fr-ca/articles/libraries/lock-android/v2/refresh-jwt-tokens.md new file mode 100644 index 0000000000..3f039ce2c3 --- /dev/null +++ b/fr-ca/articles/libraries/lock-android/v2/refresh-jwt-tokens.md @@ -0,0 +1,70 @@ +--- +section: libraries +title: Lock Android v2 Refreshing JWTs +description: Keeping your user logged in +topics: + - libraries + - lock + - android + - tokens +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Android: Refreshing JWT Tokens + +<%= include('../../../_includes/_uses-delegation') %> + +When an authentication is performed with the `offline_access` scope included, the returned Credentials will contain a Refresh Token and an ID Token. Both tokens can be used to request a new Access Token and avoid asking the user their credentials again. + +We need to store the tokens in a secure storage after a successful authentication. Keep in mind that Refresh Tokens **never expire**. To request a new token you'll need to use `auth0.android`'s `AuthenticationAPIClient`. Don't forget to request the same scope used in the first login call. + +## Using Refresh Token + +```java +String refreshToken = // Retrieve Refresh Token from secure storage +Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); +auth0.setOIDCConformant(true); + +AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); +client.renewAuth(refreshToken) + .addParameter("scope", "openid email") + .start(new BaseCallback() { + @Override + public void onSuccess(Credentials credentials) { + //SUCCESS + String accessToken = credentials.getAccessToken(); + } + + @Override + public void onFailure(AuthenticationException error) { + //FAILURE + } +}); +``` + +## Using a non-expired ID Token + +```java +String idToken = // Retrieve ID Token from the secure storage +Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); +auth0.setOIDCConformant(true); + +AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); +client.delegationWithIdToken(idToken) + .setScope("openid email") + .start(new BaseCallback() { + @Override + public void onSuccess(Delegation delegation) { + //SUCCESS + String idToken = delegation.getIdtoken(); + } + + @Override + public void onFailure(AuthenticationException error) { + //FAILURE + } + }); +``` diff --git a/fr-ca/articles/libraries/lock-ios/_includes/_dependencies.md b/fr-ca/articles/libraries/lock-ios/_includes/_dependencies.md new file mode 100644 index 0000000000..f0b8babdc6 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/_includes/_dependencies.md @@ -0,0 +1,47 @@ +## Install + +### Cocoapods + +If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`: + +```ruby +pod 'Lock', '~> 2.0' +``` + +Then run `pod install`. + +::: note +For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html). +::: + +### Carthage + +If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`: + +```ruby +github "auth0/Lock.swift" ~> 2.0 +``` + +Then run `carthage bootstrap`. + +::: note +For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). +::: + +### SPM + +If you are using the Swift Package Manager, open the following menu item in Xcode: + +**File > Swift Packages > Add Package Dependency...** + +In the **Choose Package Repository** prompt add this url: + +```text +https://github.com/auth0/Lock.swift.git +``` + +Then press **Next** and complete the remaining steps. + +::: note +For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app). +::: diff --git a/fr-ca/articles/libraries/lock-ios/_includes/_lock-version-1.md b/fr-ca/articles/libraries/lock-ios/_includes/_lock-version-1.md new file mode 100644 index 0000000000..fb21b112e4 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/_includes/_lock-version-1.md @@ -0,0 +1,3 @@ +::: version-warning +This document covers an outdated version of Lock for iOS. We recommend that you upgrade to v2. +::: diff --git a/fr-ca/articles/libraries/lock-ios/_includes/_lock-version.md b/fr-ca/articles/libraries/lock-ios/_includes/_lock-version.md new file mode 100644 index 0000000000..2596ef64e6 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/_includes/_lock-version.md @@ -0,0 +1,3 @@ +::: note +This document uses the latest version of Lock for iOS - version 2. We recommend using this version, but if you are already using version 1, you can access it using the dropdown at the top of this document. +::: diff --git a/fr-ca/articles/libraries/lock-ios/_includes/_roadmap.md b/fr-ca/articles/libraries/lock-ios/_includes/_roadmap.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/fr-ca/articles/libraries/lock-ios/index.yml b/fr-ca/articles/libraries/lock-ios/index.yml new file mode 100644 index 0000000000..4e65cc67bb --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: libraries/lock-ios + current: v2 + versions: + - v1 + - v2 + defaultArticles: + v1: index + v2: index diff --git a/fr-ca/articles/libraries/lock-ios/v1/customization.md b/fr-ca/articles/libraries/lock-ios/v1/customization.md new file mode 100644 index 0000000000..ed76e46250 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/customization.md @@ -0,0 +1,111 @@ +--- +section: libraries +title: Customization +description: Learn how to customize the look and feel of Lock +public: false +topics: + - libraries + - lock + - ios +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Customization + +<%= include('../_includes/_lock-version-1') %> + +Lock UI can be customized by creating your own `A0Theme` and overriding the default one before displaying `A0LockViewController`: + +```objc +A0Theme *myAwesomeTheme = [[A0Theme alloc] init]; +//Customize your theme +[[A0Theme sharedInstance] registerTheme:myAwesomeTheme]; +``` +```swift +let myAwesomeTheme = A0Theme() +//Customize your theme +A0Theme.sharedInstance().register(myAwesomeTheme) +``` + +## How to configure your Theme + +**Lock**'s UI is composed of several parts that can be customized + +Here is a list of the available values that can be customized: + +![](/media/articles/libraries/lock-ios/customization/Lock-UI-Parts.png) + +You can either configure some type of properties which are: + +* Color: `UIColor` instance. +* Image: `NSString` with image name. +* Font: `UIFont` instance. + +Example Usage + +``` +myAwesomeTheme.registerColorForKey(UIColor.redColor(), "A0ThemePrimaryButtonNormalColor"); +``` + +This is the list of properties that can be customized: + +### Primary Button + +* A0ThemePrimaryButtonNormalColor +* A0ThemePrimaryButtonHighlightedColor +* A0ThemePrimaryButtonNormalImageName +* A0ThemePrimaryButtonHighlightedImageName +* A0ThemePrimaryButtonFont +* A0ThemePrimaryButtonTextColor + +### Secondary Button + +* A0ThemeSecondaryButtonBackgroundColor +* A0ThemeSecondaryButtonNormalImageName +* A0ThemeSecondaryButtonHighlightedImageName +* A0ThemeSecondaryButtonFont +* A0ThemeSecondaryButtonTextColor + +### TextField + +* A0ThemeTextFieldFont +* A0ThemeTextFieldTextColor +* A0ThemeTextFieldPlaceholderTextColor +* A0ThemeTextFieldIconColor + +### Title + +* A0ThemeTitleFont +* A0ThemeTitleTextColor + +### Icon + +* A0ThemeIconBackgroundColor +* A0ThemeIconImageName + +### Background + +* A0ThemeScreenBackgroundColor +* A0ThemeScreenBackgroundImageName + +### Message & Description + +* A0ThemeDescriptionFont +* A0ThemeDescriptionTextColor +* A0ThemeSeparatorTextFont +* A0ThemeSeparatorTextColor + +### CredentialBox + +* A0ThemeCredentialBoxBorderColor +* A0ThemeCredentialBoxSeparatorColor +* A0ThemeCredentialBoxBackgroundColor + +### Close Button + +* A0ThemeCloseButtonTintColor diff --git a/fr-ca/articles/libraries/lock-ios/v1/delegation-api.md b/fr-ca/articles/libraries/lock-ios/v1/delegation-api.md new file mode 100644 index 0000000000..81be9f0cf1 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/delegation-api.md @@ -0,0 +1,70 @@ +--- +section: libraries +title: Delegation API +description: Integrate with third-party apps with the delegation API. +public: false +topics: + - libraries + - lock + - ios + - delegation +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Delegation API + +<%= include('../_includes/_lock-version-1') %> + +<%= include('../../../_includes/_deprecate-delegation') %> + +After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/api/authentication/reference#delegation) using a valid JWT. + +Here's an example + +```objc +A0Lock *lock = [A0Lock sharedLock]; +NSString *token = ...; // Auth0's ID Token obtained on login +A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{ + @"id_token": token, + A0ParameterAPIType: @"firebase", + }]; +[[lock apiClient] fetchDelegationTokenWithParameters:parameters success:^(NSDictionary *delegationToken) { + // delegationToken will have your firebase token +} failure:^(NSError *error) { + // Something went wrong +}]; +``` + +```swift +let client = A0Lock.shared().apiClient() +let token = // Auth0's ID Token obtained on login +let parameters = A0AuthParameters.new(with: [ + "id_token": token, + A0ParameterAPIType: "firebase" + ]) +client.fetchDelegationToken(with: parameters, + success: { payload in + // payload will have your firebase token + }, + failure: { error in + // Something went wrong + }) +``` + +The only two parameters required are `id_token` and the `api_type` (the value of `A0ParameterAPIType` constant). + +`api_type` specifies the API credentials we want to retrieve, and the API supported are: + +* app: Your Auth0 application. This will get a new JWT token. +* aws: Amazon Web Services API. +* azure_sb: Windows Azure Service Bus. +* firebase: Firebase API. +* salesforce_api: Salesforce API. +* salesforce_sandbox_api: Salesforce Sandbox API. +* sap_api: SAP OData. +* wams: Windows Azure Mobile Services. diff --git a/fr-ca/articles/libraries/lock-ios/v1/index.md b/fr-ca/articles/libraries/lock-ios/v1/index.md new file mode 100644 index 0000000000..57b47e6a6c --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/index.md @@ -0,0 +1,430 @@ +--- +section: libraries +toc: true +url: /libraries/lock-ios/v1 +title: Lock v1 for iOS and macOS +snippets: + dependencies: native-platforms/ios-objc/dependencies +description: A widget that provides a frictionless login and signup experience for your native iOS and macOS apps. +public: false +topics: + - libraries + - lock + - ios +contentType: + - index + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock v1 for iOS and macOS + +<%= include('../_includes/_lock-version-1') %> + +Auth0 is an authentication broker that supports social identity providers as well as enterprise identity providers such as Active Directory, LDAP, G Suite and Salesforce. + +## Key features + +* **Integrates** your iOS app with **Auth0** (OS X coming soon). +* Provides a elegant **native UI** to log in your users. +* Provides support for **Social Providers** (Facebook, Twitter, and so on), **Enterprise Providers** (AD, LDAP, and so on) and **Username & Password** authentication. +* Provides the ability to do **Single Sign-on (SSO)** with 2 or more mobile apps, similar to Facebook and Messenger apps. +* [1Password](https://agilebits.com/onepassword) integration using the **iOS 8** [Extension](https://github.com/AgileBits/onepassword-app-extension). + +::: note +Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift/tree/v1) on GitHub. +::: + +## Requirements + +iOS 7+. If you need to use our SDK with an earlier version, use the previous SDK pod `Auth0Client`, or see the [old-sdk](https://github.com/auth0/Lock.iOS-OSX/tree/old-sdk) branch of the Lock.iOS-OSX repo. + +## Installation + +Lock is available through [CocoaPods](http://cocoapods.org). To install it, simply add the following line to your Podfile: + +${snippet(meta.snippets.dependencies)} + +Then, in your project's `Info.plist` file, add the following string entries: + +* __Auth0ClientId__: The client ID of your Auth0 application. +* __Auth0Domain__: Your Auth0 account domain. + +For example: +![plist](/media/articles/libraries/lock-ios/plist.png) + +::: note +You can find these values in your [Application Settings](${manage_url}/#/applications) in the Auth0 dashboard. +::: + +You will also need to register a **Custom URL** type with a custom scheme in the following format: + +`a0{Your Client ID}` + +For example, if your Client ID is `Exe6ccNagokLH7mBmzFejP`, the custom scheme would be `a0Exe6ccNagokLH7mBmzFejP`. + +Before you can begin using Lock, you will need to import Lock into your codebase. + +If you are working in Objective-C, import this header when you need to use Lock's classes: + +```objc +#import +``` + +The same applies if you are working in Swift and Lock is included as a static library. In this case, the header must also be included in your _Objective-C Bridging Header_. + +::: note +If you need help creating the Objective-C Bridging Header, see: [Swift and Objective-C in the Same Project](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html). +::: + +If you are working in Swift with Lock included as an framework, just include the module in your Swift files like this: + +```swift +import Lock +``` + +Now you can initialize `A0Lock` (which handles authentication) and keep it in your `AppDelegate` as a **strong** property. + +::: note +You can store `A0Lock` in a different location as long as you keep it alive as long as it is needed. +::: + +This examples creates `A0Lock` inside `-application:didFinishLaunchingWithOptions:` + +**Objective C**: + +```objc +self.lock = [A0Lock newLock]; +``` + +**Swift**: + +```swift +self.lock = A0Lock() +``` + +Then call this method: + +**Objective C**: + +```objc +[self.lock applicationLaunchedWithOptions:launchOptions]; +``` + +**Swift**: + +```swift +lock.applicationLaunched(options: launchOptions) +``` + +Lastly, you will need to handle the already registered custom scheme in your `AppDelegate`. To do so, override the `-application:openURL:options:` method and add the following line: + +**Objective C**: + +```objc +- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url + options:(NSDictionary *)options { + return [self.lock handleURL:url sourceApplication:app]; +} +``` + +**Swift**: + +```swift +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + return self.lock.handle(url, sourceApplication: app) +} +``` + +This call is required to be able to return to your application when authenticating with Safari, or with native integration with Facebook or Twitter. This call checks the URL and handles those that have the custom scheme. + +## Usage + +### Email/password, enterprise, and social provider authentication + +`A0LockViewController` will handle email/password, enterprise, and social provider authentication based on the connections enabled on your application in the [Auth0 Dashboard](${manage_url}/#/connections/social). + +First, instantiate `A0LockViewController` and register the authentication callback that will receive the authenticated user's credentials. Then present it as a modal view controller: + +#### Objective C + +```objc +A0Lock *lock = ... //Fetch Lock from where its stored +A0LockViewController *controller = [lock newLockViewController]; +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + // Do something with token & profile (such as save them). + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + [self dismissViewControllerAnimated:YES completion:nil]; +}; +[self presentViewController:controller animated:YES completion:nil]; +``` + +#### Swift + +```swift +let lock = ... // Fetch Lock from where its stored +let controller: A0LockViewController = lock.newLockViewController() +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismiss(animated: true, completion: nil) +} +lock.present(controller, from: self) +``` + +You will see the Lock native login screen: + +
Lock-iOS
+ +::: note +By default, all social authentication will be done using Safari. If you want native integration, see: [Lock iOS: Native Social Authentication](/libraries/lock-ios/native-social-authentication). +::: + +### Close Lock UI + +You can add a **Close** button to Lock UI. For this to function, you will need to set the `closable` property to allow the `A0AuthenticationViewController` to be dismissed. The default value is `NO`. + +If you want to handle the closing event, you will need to add the `onUserDismissBlock` block which will be called when the user dismisses the Login screen only if the `closable` property is set to `YES`. + +#### Objective C + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0LockViewController *controller = [lock newLockViewController]; +controller.closable = YES; + +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + // Do something with token & profile (such as save them). + // And dismiss the ViewController +}; + +controller.onUserDismissBlock = ^(){ + NSLog(@"User closed Lock UI"); +}; + +[self presentViewController:controller animated:YES completion:nil]; +``` + +#### Swift + +```swift +let controller: A0LockViewController = A0Lock.shared().newLockViewController() +controller.closable = true + +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // And dismiss the ViewController +} + +controller.onUserDismissBlock = { _ in + print("User closed Lock UI") +} + +self.present(controller, animated: true, completion: nil) +``` + +### Sign-up + +There are different approaches to implement Sign-up functionality: + +1. You can add or hide the **Sign Up** button in Lock UI by setting the `disableSignUp` property which will hide the **Sign Up** button when set to `YES`. The default value is `NO`. + +2. Another approach is to use the `A0LockSignUpViewController` directly: + +#### Objective-C + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0LockSignUpViewController *controller = [lock newSignUpViewController]; + +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + // Do something with token & profile (such as save them). + // And dismiss the ViewController +}; + +[self presentViewController:controller animated:YES completion:nil]; +``` + +#### Swift + +```swift +let controller: A0LockViewController = A0Lock.shared().newSignUpViewController() +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // And dismiss the ViewController +} + +self.present(controller, animated: true, completion: nil) +``` + + +3. A third option is to create your own sign up `viewController` to implement the sign-up logic with one of the `A0APIClient` methods: + +``` +- (NSURLSessionDataTask *)signUpWithEmail:(NSString *)email + username:(nullable NSString *)username + password:(NSString *)password + loginOnSuccess:(BOOL)loginOnSuccess + parameters:(nullable A0AuthParameters *)parameters + success:(A0APIClientSignUpSuccess)success + failure:(A0APIClientError)failure; +``` + +Your `viewController` should also implement the `A0LockEventDelegate` methods: + +``` +- (void)backToLock; - Dismisses all custom UIViewControllers pushed inside Lock and shows the main UI. +- (void)dismissLock; - Dismisses A0LockViewController, like clicking the Close button if `closable` is true +- (void)userAuthenticatedWithToken:(A0Token *)token profile:(A0UserProfile *)profile; - Calls `onAuthenticationBlock` of `A0LockViewController` with token and profile +``` + +After implementing your `viewController`, you will need to return it in a `customSignUp` block of `A0LockViewController`. The default value for this block is `nil`. + +**Objective-C**: + +```objc +A0Lock *lock = [A0Lock sharedLock]; + +A0LockViewController *controller = [lock newLockViewController]; +controller.closable = YES; + +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + [self dismissViewControllerAnimated:YES completion:nil]; +}; + +//Create custom SignUp view controller +controller.customSignUp = ^ UIViewController *(A0Lock *lock, A0LockEventDelegate *delegate) { + + YourCustomSignUpVC *signUpVC = …//your viewController; + signUpVC.delegate = delegate; + signUpVC.lock = lock; + + return signUpVC; +}; + +UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller]; + +if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) { + navController.modalPresentationStyle = UIModalPresentationFormSheet; +} + +[self presentViewController:navController animated:YES completion:nil]; +``` + +**Swift**: + +```swift +let controller: A0LockViewController = A0Lock.shared().newLockViewController() + +controller.onAuthenticationBlock = { (profile, token) in + self.dismiss(animated: true, completion: nil) +} + +// Create custom SignUp view controller +controller.customSignUp = { (lock, delegate) in + let YourCustomSignUpVC = // Your viewController; + signUpVC.lock = lock + signUpVC.delegate = delegate + + return signUpVC +} + +let navController:UINavigationController = UINavigationController.init(rootViewController: controller) + +if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiom.pad) { + navController.modalPresentationStyle = UIModalPresentationStyle.formSheet + +} +self.present(navController, animated: true, completion: nil) +``` + +### Automatic login after sign-up + +After a successful sign-up, the user can be logged in automatically using the `loginAfterSignUp` property. If `loginAfterSignUp` is set to `YES`, `A0AuthenticationViewController` will attempt to log in the user . Otherwise, it will call `onAuthenticationBlock` with both parameters set to `nil`. The default value of `loginAfterSignUp` is `YES`. + +### Disclaimer View + +If you want to show a disclaimer for your app, you will need to set `signUpDisclaimerView`. This view will appear at the bottom of the sign-up screen. + +## Logout + +To log out a user, call `clearSessions` for `A0Lock`. This method removes all stored sessions of any IdP in your application. + +:::note +* If the user has logged in using Safari, their sessions will not be cleared. +* If you stored the credentials in the keychain, you need to clear them there as well. +::: + +### Objective-C + +```objc +A0Lock *lock = [A0Lock sharedLock]; +[lock clearSessions]; +A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:]; +[keychain clearAll]; +//redirect the user to Login Page +``` + +### Swift + +```swift +A0Lock.shared().clearSessions() +let keychain = A0SimpleKeychain(service: ) +keychain.clearAll() +//redirect the user to Login Page +``` + +## WebView + +When authenticating with a social connection, you can choose between using Safari or the embedded webView. To use embedded webView, set the `useWebView` property to `YES`. The default value is `YES`. + +### Objective-C + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0LockViewController *controller = [lock newLockViewController]; +controller.useWebView = NO; + +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + // Do something with token & profile (such as save them). + // And dismiss the ViewController +}; +controller.onUserDismissBlock = ^(){ +[self presentViewController:controller animated:YES completion:nil]; +``` + +### Swift + +```swift +let controller: A0LockViewController = A0Lock.shared().newLockViewController() +controller.useWebView = false +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // And dismiss the ViewController +} +self.present(controller, animated: true, completion: nil) +``` + +## Additional Information + +See the [Swift](https://github.com/auth0-samples/auth0-ios-swift-sample) and [Objective-C](https://github.com/auth0-samples/auth0-ios-objc-sample) example apps. + +For more information on how to use Lock with Swift, see: [Lock iOS: Using Swift](/libraries/lock-ios/swift). + +For more information on Lock for CocoaPods, see the [Lock documentation in CocoaDocs](http://cocoadocs.org/docsets/Lock). + +## Further reading + +::: next-steps +- [Customization of the Look and Feel of Lock iOS](/libraries/lock-ios/v1/customization) +- [Lock iOS API](/libraries/lock-ios/v1/lock-ios-api) +- [Native Social Authentication](/libraries/lock-ios/v1/native-social-authentication) +- [Passwordless](/libraries/lock-ios/v1/passwordless) +- [Sending Authentication Parameters](/libraries/lock-ios/v1/sending-authentication-parameters) +- [Using Swift with Lock iOS v1](/libraries/lock-ios/v1/swift) +::: diff --git a/fr-ca/articles/libraries/lock-ios/v1/lock-ios-api.md b/fr-ca/articles/libraries/lock-ios/v1/lock-ios-api.md new file mode 100644 index 0000000000..660eb5dbe3 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/lock-ios-api.md @@ -0,0 +1,245 @@ +--- +section: libraries +title: Lock Objective-C API +description: Description of the Lock Objective-C API +public: false +topics: + - libraries + - lock + - ios + - objective-c +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock Objective-C API + +<%= include('../_includes/_lock-version-1') %> + +## A0Lock + +### A0Lock#newLock + +```objc ++ (instancetype)newLock; +``` + +Creates a new `A0Lock` instance using account information from Info.plist file. + +```objc +A0Lock *lock = [A0Lock newLock]; +``` + +#### A0Lock#newLockWithClientId:domain: + +```objc ++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain; +``` + +Creates a new `A0Lock` instance with Auth0 clientId and domain. + +```objc +A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN"]; +``` + +#### A0Lock#newLockWithClientId:domain:configurationDomain: + +```objc ++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain configurationDomain:(NSString *)configurationDomain; +``` + +Creates a new `A0Lock` instance with Auth0 clientId, domain and configurationDomain. + +```objc +A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN" configurationDomain:@"YOUR_CONFIG_DOMAIN"]; +``` + +#### A0Lock#apiClient + +```objc +- (A0APIClient *)apiClient; +``` + +Returns an instance of the API application for Authentication API configured for your application. + +```objc +A0APIClient *client = [lock apiClient]; +``` + +#### A0Lock#newUserAPIClientWithIdToken + +```objc +- (A0UserAPIClient *)newUserAPIClientWithIdToken:(NSString *)idToken; +``` + +Returns a new instance of the API client for Auth0 API with the credentials of a authenticated user obtained from the **ID Token** + +```objc +A0UserAPIClient *client = [lock newUserAPIClientWithIdToken:@"AN ID TOKEN"]; +``` + +#### A0Lock#handleURL:sourceApplication: + +```objc +- (BOOL)handleURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication; +``` + +Handle URL received from AppDelegate when application is called from a third party at the end of an authentication flow. + +```objc +[lock handleURL:URL sourceApplication:sourceApplication]; +``` + +#### A0Lock#registerAuthenticators + +```objc +- (void)registerAuthenticators:(NSArray *)authenticators; +``` + +Register IdP authenticators that will be used for Social & Enterprise connections. By default all Social & Enterprise authentications are performed by using the web flow with Safari but you can plug your own authenticator for a connection (for example, you can register `A0FacebookAuthenticator` in order to login with FB native SDK). + +```objc +[lock registerAuthenticators:@[facebook, twitter]]; +``` + +#### A0Lock#applicationLaunchedWithOptions + +```objc +- (void)applicationLaunchedWithOptions:(NSDictionary *)launchOptions; +``` + +Handle application launched event. + +```objc +[lock applicationLaunchedWithOptions:launchOptions]; +``` + +#### A0Lock#clearSessions + +```objc +- (void)clearSessions; +``` + +Remove all stored sessions of any IdP in your application. If the user logged in using Safari, those sessions will not be cleaned. + +```objc +[lock clearSessions]; +``` + +### A0LockViewController + +#### A0LockViewController#init + +```objc +- (instancetype)initWithLock:(A0Lock *)lock; +``` + +Initialise 'A0LockViewController' using a `A0Lock` instance. + +```objc +A0LockViewController *controller = [[A0LockViewController alloc] initWithLock:lock]; +``` + +#### A0LockViewController#onAuthenticationBlock + +```objc +@property (copy, nonatomic) void(^onAuthenticationBlock)(A0UserProfile *profile, A0Token *token); +``` + +Block that is called on successful authentication. It has two parameters profile and token, which will be non-nil unless login is disabled after signup. + +```objc +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + NSLog(@"Auth successful: profile %@, token %@", profile, token); +}; +``` + +#### A0LockViewController#onUserDismissBlock + +```objc +@property (copy, nonatomic) void(^onUserDismissBlock)(); +``` + +Block that is called on when the user dismisses the Login screen. Only when `closable` property is `YES`. + +```objc +controller.onUserDismissBlock = ^() { + NSLog(@"User dismissed login screen."); +}; +``` + +#### A0LockViewController#usesEmail + +```objc +@property (assign, nonatomic) BOOL usesEmail; +``` + +Enable the username to be treated as an email (and validated as one too) in all Auth0 screens. Default is `YES` + +```objc +controller.usesEmail = NO; +``` + +#### A0LockViewController#closable + +```objc +@property (assign, nonatomic) BOOL closable; +``` + +Allows the `A0LockViewController` to be dismissed by adding a button. Default is `NO` + +```objc +controller.closable = YES; +``` + +#### A0LockViewController#loginAfterSignup + +```objc +@property (assign, nonatomic) BOOL loginAfterSignUp; +``` + +After a successful Signup, `A0LockViewController` will attempt to login the user if this property is `YES` otherwise will call `onAuthenticationBlock` with both parameters nil. Default value is `YES` + +```objc +controller.loginAfterSignup = NO; +``` + +#### A0LockViewController#authenticationParameters + +```objc +@property (assign, nonatomic) A0AuthParameters *authenticationParameters; +``` + +List of optional parameters that will be used for every authentication request with Auth0 API. By default it only has 'openid' and 'offline_access' scope values. For more information check out our [Wiki](/libraries/lock-ios/sending-authentication-parameters) + +```objc +controller.authenticationParameters.scopes = @[A0ScopeOfflineAccess, A0ScopeProfile]; +``` + +### A0LockViewController#signupDisclaimerView + +```objc +@property (strong, nonatomic) UIView *signUpDisclaimerView; +``` + +View that will appear in the bottom of Signup screen. It should be used to show Terms & Conditions of your app. + +```objc +UIView *view = //.. +controller.signupDisclaimerView = view; +``` + +#### A0LockViewController#useWebView + +```objc +@property (assign, nonatomic) BOOL useWebView; +``` + +When the authentication requires to open a web login, for example Linkedin, it will use an embedded UIWebView instead of Safari if it's `YES`. We recommend using Safari for Authentication since it will always save the User session. This means that if the user is already signed in, for example in Linkedin, and they click on the Linkedin button, it will just work. Default values is `NO` + +```objc +controller.useWebView = YES +``` diff --git a/fr-ca/articles/libraries/lock-ios/v1/logging.md b/fr-ca/articles/libraries/lock-ios/v1/logging.md new file mode 100644 index 0000000000..f33ff75ea7 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/logging.md @@ -0,0 +1,72 @@ +--- +section: libraries +title: Logging +description: Learn how to debug Lock by enabling logging. +public: false +topics: + - libraries + - lock + - ios +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Logging + +<%= include('../_includes/_lock-version-1') %> + +Lock logs several pieces of useful debugging information using [CocoaLumberjack](https://github.com/CocoaLumberjack/CocoaLumberjack). + + +::: note +If you are using a Lock version older than `1.10.0` please check [here](#lock-versions-1-10-0) +::: + +By default all log messages are disabled but you can enable them in your `AppDelegate.m` (or `AppDelegate.swift`), for example if you want __Lock__'s error messages just add this line: + +```objc +[A0LockLogger logError]; +``` +```swift +A0LockLogger.logError() +``` + +Or if you want to all debug messages: + +```objc +[A0LockLogger logAll]; +``` +```swift +A0LockLogger.logAll() +``` + +::: note +If you are already using `CocoaLumberjack`, you need to enable __Lock__'s log after you register CocoaLumberjack's loggers. +::: + +## Lock versions < 1.10.0 +Go to `A0Logging.h` and change the `auth0LogLevel` variable with the Log Level you'll want to see. for example: +```objc +static const int auth0LogLevel = LOG_LEVEL_ALL; +``` + +And then you'll need to configure CocoaLumberjack (if you haven't done it for your app). You need to do it once so we recommend doing it in your `AppDelegate`: + +```objc +#import +#import +#import + +@implementation A0AppDelegate + +- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { + [DDLog addLogger:[DDASLLogger sharedInstance]]; + [DDLog addLogger:[DDTTYLogger sharedInstance]]; + return YES; +} + +@end +``` diff --git a/fr-ca/articles/libraries/lock-ios/v1/native-social-authentication.md b/fr-ca/articles/libraries/lock-ios/v1/native-social-authentication.md new file mode 100644 index 0000000000..56a08f5617 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/native-social-authentication.md @@ -0,0 +1,97 @@ +--- +section: libraries +title: Native Social Authentication +description: How to enable native login for some the supported social social connections. +public: false +topics: + - libraries + - lock + - ios + - native + - social-connections +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Native Social Authentication + +<%= include('../_includes/_lock-version-1') %> + +::: warning +This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. +We recommend using browser-based flows, as explained in [Web-based auth](/libraries/auth0-swift#web-based-auth-ios-only-). +::: + +**Lock** by default handles all social authentication with Safari (Web Login), but you can enable native login for some social connections. Currently we only provide integration with Facebook, Google & Twitter that can be included like this in your `Podfile` +```ruby +pod 'Lock-Facebook' +pod 'Lock-Twitter' +pod 'Lock-Google' +``` + +::: note +We recommend to at least fix the major version instead of always obtaining the latest version, e.g `pod 'Lock-Facebook', '~> 2.0` +::: + +## Configuration + +::: note +Before following these steps, please check our [documentation](/libraries/lock-ios) +::: + +### Facebook + +Lock uses Facebook iOS SDK to obtain user's Access Token so you'll need to configure it using your Facebook App info: + +First, add the following entries to the `Info.plist`: +* _FacebookAppID_: `YOUR_FACEBOOK_APP_ID` +* _FacebookDisplayName_: `YOUR_FACEBOOK_DISPLAY_NAME` + +Then register a custom URL Type with the format `fb`. For more information please check [Facebook Getting Started Guide](https://developers.facebook.com/docs/ios/getting-started). + +Here's an example of how the entries should look like in your `Info.plist` file: + +![FB plist](/media/articles/libraries/lock-ios/fb-plist.png) + +Finally, you need to register `A0FacebookAuthenticator` with your instance of `A0Lock`: + +```objc +A0Lock *lock = ...//Get your Lock instance +A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticationWithDefaultPermissions]; +[lock registerAuthenticators:@[facebook]]; +``` + +### Twitter + +Twitter authentication is done using [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth) in order to obtain a valid Access Token that can be sent to Auth0 Server and validate the user. By default we use iOS Twitter Integration but we support OAuth Web Flow (with Safari) as a fallback mechanism in case a user has no accounts configured in his/her Apple Device. + +To support Twitter authentication you need to register `A0TwitterAuthenticator` with your instance of `A0Lock`: + +```objc +A0Lock *lock = ...//Get your Lock instance +NSString *twitterApiKey = ... //Remember to obfuscate your api key +NSString *twitterApiSecret = ... //Remember to obfuscate your api secret +A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticatorWithKey:twitterApiKey andSecret:twitterApiSecret]; +[lock registerAuthenticators:@[twitter]]; +``` + +We need your twitter app's key & secret in order to sign the reverse auth request. For more info please read the Twitter documentation related to [Authorizing Requests](https://dev.twitter.com/docs/auth/authorizing-request) and [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth). + +### Google + +Google authentication uses [Google Sign-In](https://developers.google.com/identity/sign-in/ios/) iOS library, so you'll need to register your iOS application in [Google Developer Console](https://console.developers.google.com/project) and get your clientId. + +We recommend following [this wizard](https://developers.google.com/mobile/add?platform=ios) instead and download the file `GoogleServices-Info.plist` that is generated at the end. + +Then add that file to your application's target and the last step is to register two custom URL for your application. + +The first URL should have a scheme equal to your application Bundle Identifier, the other one should be your Google clientId reversed, so if your clientID is `CLIENTID.apps.googleusercontent.com` the scheme will be `com.googleusercontent.apps.CLIENTID`. + +::: note +This last value can be found in `GoogleServices-Info.plist` under the key `REVERSED_CLIENT_ID`. For more information please check Google's [documentation](https://developers.google.com/identity/sign-in/ios/). +::: + +And finally with your Mobile clientID from Google, go to [Social Connections](${manage_url}/#/connections/social), select **Google** and add the clientID to the field named `Allowed Mobile Client IDs` diff --git a/fr-ca/articles/libraries/lock-ios/v1/password-reset-ios.md b/fr-ca/articles/libraries/lock-ios/v1/password-reset-ios.md new file mode 100644 index 0000000000..9d7462f62f --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/password-reset-ios.md @@ -0,0 +1,66 @@ +--- +section: libraries +title: Password Reset +description: All you need to know about password reset with Lock for iOS. +public: false +topics: + - libraries + - lock + - ios + - passwords +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock iOS: Password Reset + +<%= include('../_includes/_lock-version-1') %> + +You can allow the user to reset their password for any database connections. + +If you use Lock UI, you can hide or show a **Reset password** button by setting the `disableResetPassword` property, which will default to `false`. + +If you implement a custom UI, you need to send a password reset email to the user using `A0APIClient`. + +::: note +Please see [Password Strength in Auth0 Database Connections](/connections/database/password-strength) before implementing password reset. +::: + +## Important considerations + +Passwords can only be changed for users signing in using database connections. If a user is signing in with a social or enterprise connection, their password would need to be reset in those platforms. + +## Example: Objective-C + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0APIClient *client = [lock apiClient]; +A0AuthParameters *params = [A0AuthParameters newDefaultParams]; +params[A0ParameterConnection] = @"Username-Password-Authentication"; + // Or your configured DB connection + +[client requestChangePasswordForUsername: + parameters:params + success:^{ + NSLog(@"Please check your email!"); + } failure:^(NSError * _Nonnull error) { + NSLog(@"Oops something went wrong: %@", error); + }]; +``` + +## Example: Swift + +```swift +let client = A0Lock.shared().apiClient() +let params = A0AuthParameters.newDefaultParams(); +params[A0ParameterConnection] = "Username-Password-Authentication"; +// Or your configured DB connection +client.requestChangePassword(forUsername: "", parameters: params, +success: { _ in + print("Please check your email!") +}, failure: { error in + print("Oops something went wrong: \(error)") +}) +``` diff --git a/fr-ca/articles/libraries/lock-ios/v1/passwordless.md b/fr-ca/articles/libraries/lock-ios/v1/passwordless.md new file mode 100644 index 0000000000..6296f23b3c --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/passwordless.md @@ -0,0 +1,119 @@ +--- +section: libraries +title: Passwordless in Lock iOS v1 +description: How to implement Passwordless authentication in Lock v1 +public: false +topics: + - libraries + - lock + - ios + - passwordless +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Passwordless in Lock iOS v1 + +<%= include('../_includes/_lock-version-1') %> + +<%= include('../../../_includes/_native_passwordless_warning') %> + +## Passwordless with SMS + +`A0SMSLockViewController` authenticates without using a password with SMS. In order to be able to authenticate the user, your application must have the SMS connection enabled and configured in your [dashboard](${manage_url}/#/connections/passwordless). + +First instantiate `A0SMSLockViewController` and register the authentication callback that will receive the authenticated user's credentials. + +The next step is register a block to return an API Token used to register the phone number and send the login code with SMS. This token can be generated in [Auth0 API v2 page](/api/v2), just select the scope `create:users` and copy the generated API Token. + +Finally present it to the user: +```objc +A0Lock *lock = ... //Fetch Lock from where its stored +A0SMSLockViewController *controller = [lock newSMSViewController]; +controller.auth0APIToken = ^{ + return @"Copy API v2 token here"; +}; +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + // Do something with token & profile (such as save them). + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + [self dismissViewControllerAnimated:YES completion:nil]; +}; +[lock presentSMSController:controller fromController:self]; +``` + +```swift +let lock = ... // Fetch Lock from where its stored +let controller: A0SMSLockViewController = lock.newSMSViewController() +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismiss(animated: true, completion: nil) +} +lock.presentSMSController(controller, from: self) +``` +And you'll see SMS login screen + +![Lock SMS Screenshot](/media/articles/libraries/lock-ios/Lock-SMS-Screenshot.png) + +## Passwordless with Touch ID + +Lock provides passwordless authentication with Touch ID for your Auth0 DB connection. To start authenticating your users with Touch ID please follow those steps: + +1. Add `TouchID` subspec module of **Lock** to your `Podfile` + ```ruby + pod 'Lock/TouchID' + ``` + +1. Import **Lock**'s umbrella header + ```objc + #import + ``` + ::: note + If your are coding in Swift, you need to import the header in your app's [Bridging Header](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html). + ::: + +1. Instantiate `A0TouchIDLockViewController` and register authentication callback + ```objc + A0TouchIDLockViewController *controller = [[A0TouchIDLockViewController alloc] init]; + controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + //Store token & profile. For example in the keychain using SimpleKeychain. + [self dismissViewControllerAnimated:YES completion:nil]; + }; + ``` + ```swift + let lock = A0Lock.shared() + let controller: A0TouchIDLockViewController = lock.newTouchIDViewController() + controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile (such as save them). + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismiss(animated: true, completion: nil) + } + ``` + +1. Present `A0TouchIDLockViewController` as the root controller of a `UINavigationController` + ```objc + UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller]; + if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) { + navController.modalPresentationStyle = UIModalPresentationFormSheet; + } + [self presentViewController:navController animated:YES completion:nil]; + ``` + ```swift + let navController = UINavigationController(rootViewController: controller) + if UIDevice.current.userInterfaceIdiom == .pad { + navController.modalPresentationStyle = .FormSheet + } + self.presentViewController(navController, animated: true, completion:nil) + ``` + ::: note + It's mandatory to present `A0TouchIDLockViewController` embedded in a `UINavigationController`. + ::: + +And you'll see TouchID login screen. + +![Lock Screenshot](/media/articles/libraries/lock-ios/Lock-TouchID-Screenshot.png) diff --git a/fr-ca/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md b/fr-ca/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md new file mode 100644 index 0000000000..69be180f58 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md @@ -0,0 +1,146 @@ +--- +section: libraries +title: Saving and Refreshing JWT Tokens +description: Keeping your user logged in +public: false +topics: + - libraries + - lock + - ios + - tokens +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Saving and Refreshing JWT Tokens + +<%= include('../_includes/_lock-version-1') %> + +<%= include('../../../_includes/_uses-delegation') %> + +When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new JWT token and avoid asking the user his/her +credentials again. + +::: note +We are using [SimpleKeychain](https://github.com/auth0/SimpleKeychain) to handle iOS Keychain access. +::: + +First thing we need to do is store the ID Token and Refresh Token in the iOS Keychain after a successful authentication. + +```objc +A0LockViewController *controller = ...; +controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) { + A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"]; + [keychain setString:token.idToken forKey:@"id_token"]; + [keychain setString:token.refreshToken forKey:@"refresh_token"]; + [keychain setData:[NSKeyedArchiver archivedDataWithRootObject:profile] forKey:@"profile"]; + // Other stuff. Don't forget to dismiss lock +}; +``` + +```swift +let controller: A0LockViewController = ... +controller.onAuthenticationBlock = { (profile, token) in + guard let profile = profile, let token = token else { + return //it's a sign up + } + let keychain = A0SimpleKeychain(service: "Auth0") + keychain.setString(token.idToken, forKey: "id_token") + if let refreshToken = token.refreshToken { + keychain.setString(refreshToken, forKey: "refresh_token") + } + keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile") + // Other stuff. Don't forget to dismiss lock +} +``` +Once you have those stored, you can at any point request a new ID Token using either of by calling to Auth0`s **delegation** endpoint. + +## Using a non-expired ID Token + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"]; +NSString* token = [keychain stringForKey:@"id_token"]; +A0APIClient *client = [lock apiClient]; +[client fetchNewIdTokenWithIdToken:token parameters:nil success:^(A0Token *token) { + [keychain setString:token.idToken forKey:@"id_token"]; + //Just got a new ID Token! +} failure:^(NSError *error) { + [keychain clearAll]; //Cleaning stored values since they are no longer valid + //ID Token is no longer valid. + //You should ask the user to login again!. +}]; +``` + +```swift +let keychain = A0SimpleKeychain(service: "Auth0") +if let token = keychain.stringForKey("id_token") { + let client = A0Lock.sharedLock().apiClient() + client.fetchNewIdTokenWithIdToken(token, + parameters: nil, + success: { token in + keychain.setString(token.idToken, forKey: "id_token") + //Just got a new ID Token! + }, failure: { error in + keychain.clearAll() //Cleaning stored values since they are no longer valid + //ID Token is no longer valid. + //You should ask the user to login again!. + }) +} +``` + +## Using Refresh Token + +```objc +A0Lock *lock = [A0Lock sharedLock]; +A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"]; +NSString* refreshToken = [keychain stringForKey:@"refresh_token"]; +A0APIClient *client = [lock apiClient]; +[client fetchNewIdTokenWithRefreshToken:refreshToken parameters:nil success:^(A0Token *token) { + [keychain setString:token.idToken forKey:@"id_token"]; + //Just got a new ID Token! +} failure:^(NSError *error) { + [keychain clearAll]; //Cleaning stored values since they are no longer valid + //Refresh Token is no longer valid. + //You should ask the user to login again!. +}]; +``` + +```swift +let keychain = A0SimpleKeychain(service: "Auth0") +if let token = keychain.stringForKey("refresh_token") { + let client = A0Lock.sharedLock().apiClient() + client.fetchNewIdTokenWithRefreshToken(token, + parameters: nil, + success: { token in + keychain.setString(token.idToken, forKey: "id_token") + //Just got a new ID Token! + }, failure: { error in + keychain.clearAll() //Cleaning stored values since they are no longer valid + //Refresh Token is no longer valid. + //You should ask the user to login again!. + }) +} +``` + +## Retrieving the user profile from Keychain + +If you need to show profile information in your application, just retrieve the saved profile and pick what you need. For example: + +```objc +A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"]; +A0UserProfile *profile = [NSKeyedUnarchiver unarchiveObjectWithData:[keychain dataForKey:@"profile"]]; +self.nameLabel.text = profile.name; +self.emailLabel.text = profile.email; +``` + +```swift +let keychain = A0SimpleKeychain(service: "Auth0") +if let data = keychain.dataForKey("profile"), let profile = NSKeyedUnarchiver.unarchiveObjectWithData(data) { + self.nameLabel.text = profile.name + self.emailLabel.text = profile.email +} +``` diff --git a/fr-ca/articles/libraries/lock-ios/v1/sending-authentication-parameters.md b/fr-ca/articles/libraries/lock-ios/v1/sending-authentication-parameters.md new file mode 100644 index 0000000000..325e52750d --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/sending-authentication-parameters.md @@ -0,0 +1,89 @@ +--- +section: libraries +title: Sending Authentication Parameters +description: How to send authentication parameters, and what parameters are supported when using Lock iOS. +public: false +topics: + - libraries + - lock + - ios +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Sending Authentication Parameters + +<%= include('../_includes/_lock-version-1') %> + +You can send parameters, before displaying `A0AuthenticationViewController` or when calling any API method using `A0APIClient`, by adding them to a `A0AuthParameters` object. By default `A0AuthParameters` has the parameter `scope` with `openid offline_access` and `device` with the name obtained from calling +```objc +[[UIDevice currentDevice] name]; +``` +The following example adds a `scope` parameter with the value `login`. +```objc +A0AuthParameters *parameters = [A0AuthParameters newDefaultParams]; +parameters.scope = @"login"; +``` + +The following parameters are supported: +* `access_token` +* `scope` +* `protocol` +* `device` +* `connection_scopes` +* `nonce` +* `offline_mode` +* `state`. + +There are other extra parameters that will depend on the provider. For example, Google allows you to get back a `refresh_token` only if you explicitly ask for `access_type=offline`. + +We support sending arbitrary parameters like this: + +```objc +A0AuthParameters *parameters = [A0AuthParameters newDefaultParams]; +[parameters setValue:@"offline" forKey:@"access_type"]; +[parameters setValue:@"foo" forKey:@"my_arbitrary_param"]; +``` + +## Supported parameters +### scope:`NSString` + +There are different values supported for scope: + +* `'openid'`: It will return, not only the Access Token, but also an ID Token, which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim). You can use objc constant `A0ScopeOpenId`. +* `'openid profile'`:(not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (for example, when using response_type=token) and will likely create an unnecessarily large token(especially with Azure AD which returns a fairly long JWT). Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. You can use objc constant `A0ScopeProfile`. +* `'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the ID Token (for example: `scope: 'openid name email picture'`). + +Also, when you need to keep the ID Token alive, you can request a Refresh Token adding to the scope the value `offline_access` (Or use the constant `A0ScopeOfflineAccess`). + +By default in Auth0.iOS, the scope is set to `openid offline_access`. + +### device:`NSString` + +This value is only required when one of the scopes is `offline_access`. By default it has the name of the device obtained from calling the following method: + +```objc +[[UIDevice currentDevice] name]; +``` + +### connection_scopes:`NSDictionary` + +The `connection_scopes` parameter allows for dynamically specifying scopes on any connection. This is useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request the user for extra permissions or attributes. + +The object keys must be the names of the connections and the values must be arrays containing the scopes to request to append to the dashboard specified scopes. An example is shown below: + +```objc +A0AuthParameters *parameters = [A0AuthParameters newDefaultParams]; +parameter.connectionScopes = @{ + @"facebook": [@"public_profile", @"user_friends"], + @"google-oauth2": [@"https://www.googleapis.com/auth/orkut"], + // none for twitter +}; +``` + +::: note +The values for each scope are not transformed in any way. They must match exactly the values recognized by each identity provider. +::: diff --git a/fr-ca/articles/libraries/lock-ios/v1/swift.md b/fr-ca/articles/libraries/lock-ios/v1/swift.md new file mode 100644 index 0000000000..de468cce8c --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/swift.md @@ -0,0 +1,58 @@ +--- +section: libraries +title: Using Lock with Swift +description: How to use Swift with Lock iOS. +public: false +topics: + - libraries + - lock + - ios + - swift +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Using Swift + +<%= include('../_includes/_lock-version-1') %> + +**Lock** was written in Objective-C but it can be used from a pure Swift project or a Hybrid project (Swift & Objective-C). + +## Create Objective-C Bridging Header +In order to use **Lock** classes in any Swift file, you need to add a Objective-C Bridging Header to your project. The easiest way is to create a dummy Objective-C file in your Swift project (or Swift file in a Objective-C project), this will make Xcode prompt to create the bridging header, just press _"YES"_. After that you can delete the dummy file from your project and open the bridging header file which is called `-Bridging-Header.h`. + +::: note +For more information, please check [this guide](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html) from Apple. +::: + +## Use Lock +In `-Bridging-Header.h` just add the following line +```objc +#import +``` + +And **Lock** classes will be available in all your Swift codebase. So to show `A0LockViewController` just use the following snippet: + +```swift +let authController: A0LockViewController = A0Lock.shared().newLockViewController() +authController.onAuthenticationBlock = { (profile, token) in + guard let profile = profile, let token = token else { + return //it's a sign up + } + + let keychain = A0SimpleKeychain(service: "Auth0") + keychain.setString(token.idToken, forKey: "id_token") + if let refreshToken = token.refreshToken { + keychain.setString(refreshToken, forKey: "refresh_token") + } + keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile") + + // Other stuff + + self.dismiss(animated: true, completion: nil) +} +self.present(authController, animated: true, completion: nil) +``` diff --git a/fr-ca/articles/libraries/lock-ios/v1/use-your-own-ui.md b/fr-ca/articles/libraries/lock-ios/v1/use-your-own-ui.md new file mode 100644 index 0000000000..e7cd769663 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v1/use-your-own-ui.md @@ -0,0 +1,163 @@ +--- +section: libraries +title: Build your own UI +description: Customize the UI of Lock in your App +public: false +topics: + - libraries + - lock + - ios + - custom-ui +contentType: + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock iOS: Build your own UI + +<%= include('../_includes/_lock-version-1') %> + +<%= include('../../../_includes/_package', { + org: 'auth0', + repo: 'native-mobile-samples', + path: 'iOS/custom-ui-sample-swift' +}) %> + +**Otherwise, if you already have an existing application, please follow the steps below.** + +1. Add the following dependencies to your project using Cocoapods: + ```ruby + pod "Lock/Core", "~> 1.16" + pod "Lock-Facebook", "~> 2.0" #If you need FB native integration + pod "Lock-Twitter", "~> 1.1" #If you need Twitter native integration + ``` + +2. Open your app's `Info.plist` file and add two new entries `Auth0ClientId` and `Auth0Domain` with the following values `${account.clientId}` and `${account.namespace}` + +3. Create a new instantiate of `A0Lock` and store it where is easily accessible: + ```objc + self.lock = [A0Lock newLock]; + ``` + ```swift + self.lock = A0Lock() + ``` + +4. When you need to login your user with email/password credentials, just paste the following code + ```objc + NSString *email = ... // User's email + NSString *password = ... // User's password + A0Lock *lock = ... // Get your Lock instance + A0APIClient *client = [lock apiClient]; + A0APIClientAuthenticationSuccess success = ^(A0UserProfile *profile, A0Token *token) { + NSLog(@"We did it!. Logged in with Auth0."); + }; + A0APIClientError failure = ^(NSError *error){ + NSLog(@"Oops something went wrong: %@", error); + }; + A0AuthParameters *params = [A0AuthParameters newDefaultParams]; + params[A0ParameterConnection] = @"Username-Password-Authentication"; // Or your configured DB connection + [client loginWithUsername:email + password:password + parameters:params + success:success + failure:error]; + ``` + + ```swift + let email = ... // User's email + let password = ... // User's password + let lock = ... // Get your Lock instance + let client = lock.apiClient() + let parameters = A0AuthParameters(dictionary: [A0ParameterConnection : "Username-Password-Authentication"]) + client.login(withUsername: email, password: password, parameters: parameters, success: { profile, token in + print("We did it!. Logged in with Auth0.") + }, failure: { error in + print("Oops something went wrong: \(error)") + }) + ``` +::: note +More details about the parameters you can use check [this wiki page](/libraries/lock-ios/sending-authentication-parameters). +::: + +After that, you may want to save the user's token to be able to use them later, you can find how to do it [here](/libraries/lock-ios/save-and-refresh-jwt-tokens). + +## Social Authentication + +1. In your `AppDelegate` method named `application:didFinishLaunchingWithOptions` add the following line: + ```objc + A0Lock *lock = ... //Get your Lock instance + [lock applicationLaunchedWithOptions:launchOptions]; + ``` + ```swift + let lock = ... // Get your Lock instance + lock.applicationLaunched(options: launchOptions) + ``` + +2. Also add the following lines to your `AppDelegate` too + ```objc +- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options { + A0Lock *lock = ... // Get your Lock instance + return [lock handleURL:url sourceApplication:app]; + } + ``` + ```swift + func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + let lock = ... // Get your Lock instance + return lock.handle(url, sourceApplication: app) + } + ``` + +3. Configure Facebook Native Integration + ```objc + A0Lock *lock = ... //Get your Lock instance + A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticatorWithDefaultPermissions]; + [lock registerAuthenticators:@[facebook]]; + ``` + ```swift + let lock = ... //Get your Lock instance + let facebook = A0FacebookAuthenticator.newAuthenticatorWithDefaultPermissions() + lock.registerAuthenticators([facebook]) + ``` + ::: note + You need to configure your iOS App for Facebook, please check [this guide](/libraries/lock-ios/native-social-authentication#facebook) for more information. + ::: + +4. Configure Twitter Native Integration + ```objc + NSString *twitterApiKey = ... //Remember to obfuscate your api key + NSString *twitterApiSecret = ... //Remember to obfuscate your api secret + A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticationWithKey:twitterApiKey andSecret:twitterApiSecret]; + A0Lock *lock = ... //Get your Lock instance + [lock registerAuthenticators:@[twitter]]; + ``` + ```swift + let twitterApiKey = ... //Remember to obfuscate your api key + let twitterApiSecret = ... //Remember to obfuscate your api key + let twitter = A0TwitterAuthenticator.newAuthenticationWithKey(twitterApiKey, andSecret:twitterApiSecret) + let lock = ... //Get your Lock instance + lock.registerAuthenticators([twitter]) + ``` + +5. Authenticate with a social connection + ```objc + void(^success)(A0UserProfile *, A0Token *) = ^(A0UserProfile *profile, A0Token *token) { + NSLog(@"We did it!. Logged in with Auth0."); + }; + void(^error)(NSError *) = ^(NSError *error) { + NSLog(@"Oops something went wrong: %@", error); + }; + A0Lock *lock = ... //Get your Lock instance + [[lock identityProviderAuthenticator] authenticateWithConnectionName:@"facebook" parameters:nil success:success failure:failure]; + ``` + ```swift + let success = { (profile: A0UserProfile, token: A0Token) in + println("We did it!. Logged in with Auth0.") + } + let failure = { (error: NSError) in + println("Oops something went wrong: \(error)") + } + let lock = ... //Get your Lock instance + lock.identityProviderAuthenticator().authenticateWithConnectionName("facebook", parameters: nil, success: success, failure: failure) + ``` diff --git a/fr-ca/articles/libraries/lock-ios/v2/configuration.md b/fr-ca/articles/libraries/lock-ios/v2/configuration.md new file mode 100644 index 0000000000..20831500fb --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/configuration.md @@ -0,0 +1,248 @@ +--- +section: libraries +toc: true +url: /libraries/lock-ios/v2/configuration +title: Lock for iOS v2 Configuration Options +description: Behavior configuration options available with Lock v2 for iOS +topics: + - libraries + - lock + - ios +contentType: + - reference + - how-to +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock v2 for iOS - Configuration Options + +There are numerous options to configure Lock's behavior listed below. In addition, there are also quite a few options available to alter Lock's appearance and style in the [Style Customization Options](/libraries/lock-ios/v2/customization) page. + +## Configuring Lock's behavior + +Configuration options can be added to your Lock initialization using `withOptions`. + +```swift +Lock + .classic() + .withOptions { + $0.closable = true + $0.usernameStyle = [.Username] + $0.allow = [.Login, .ResetPassword] + } + .present(from: self) +``` + +## Behavior Options + +### closable + +Allows Lock to be dismissed by the user. By default this is `false`. + +```swift +.withOptions { + $0.closable = true +} +``` + +### scope + +Scope used for authentication. By default is `openid`. It will return not only the **Access Token**, but also an **ID Token** which is a JSON Web Token (JWT) containing user information. See the documentation on [Scopes](/scopes) for more information about authentication scopes. + +```swift +.withOptions { + $0.scope = "openid name email picture" +} +``` + +#### Refresh Tokens + +Specifying the `offline_access` scope in your Lock options will allow a [Refresh Token](/tokens/concepts/refresh-tokens) to be returned along with the access\_token and the id\_token. Refresh Tokens can be saved and used to acquire a new Access Token when the old one expires. For more information about using Refresh Tokens for Auth0 authentication, take a look at the reference documentation for the [Auth0.Swift SDK](/libraries/auth0-swift), which you would use to implement Refresh Tokens, or at the [Swift Quickstart Guide](/quickstart/native/ios-swift/03-user-sessions), which provides a comprehensive example of use of Auth0 in Swift development, including the management of Refresh Tokens. + +### termsOfService + +By default Lock will use Auth0's [Terms of Service](https://auth0.com/terms) and [Privacy Policy](https://auth0.com/privacy), but other URLs can be filled in to link to other terms and policies. + +```swift +.withOptions { + $0.termsOfService = "https://mycompany.com/terms" + $0.privacyPolicy = "https://mycompany.com/privacy" +} +``` + +### Show Terms of Service + +Database connections display the Terms of Service dialog. Default is `true`. Note that the Terms of Service will always be shown if the `mustAcceptTerms` flag is enabled. + +```swift +.withOptions { + $0.showTerms = true +} +``` + +### Require users to accept the Terms of Service + +Database connection require explicit acceptance of the Terms of Service. + +```swift +.withOptions { + $0.mustAcceptTerms = true +} +``` + +## Web Authentication Options + +### leeway + +Clock skew used for ID token validation. It expands the time window in which the ID token will still be considered valid, to account for the difference between server time and client time. By default is **60000 milliseconds** (60 seconds). + +```swift +.withOptions { + $0.leeway = 30000 // 30 seconds +} +``` + +### maxAge + +Allowable elapsed time (in milliseconds) since the user last authenticated. Used for ID token validation. If set, the ID token will contain an `auth_time` claim with the authentication timestamp. Defaults to `nil`. + +```swift +.withOptions { + $0.maxAge = 86400000 // 1 day +} +``` + +## Database options + +### allow + +Which database screens will be accessible, the default is enable all screens such as `.Login, .Signup, .ResetPassword`. + +```swift +.withOptions { + $0.allow = [.Login, .ResetPassword] +} +``` + +### initialScreen + +The first screen to present to the user. The default is `.Login`, other options include `.Signup` and `ResetPassword`. + +```swift +.withOptions { + $0.initialScreen = .login +} +``` + +### usernameStyle + +Specify the type of identifier the login will require. The default is either: `[.Username, .Email]`, but it can also accept `[.Username]` or `[.Email]`. However it's important to note that this option is only active if you have set the `requires_username` flag to `true` in your [Auth0 Dashboard](${manage_url}/#/) + +```swift +.withOptions { + $0.usernameStyle = [.Username] +} +``` + +#### Custom Signup Fields + +When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata). Note that you must specify the icon to use with your custom text field. + +```swift +.withOptions { + $0.customSignupFields = [ + CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)), + CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)) + ] +} +``` + +::: note +You can also specify icons from other bundles, such as in the following example: +CustomTextField(name: "slack_handle", placeholder: "Slack Handle", icon: LazyImage(name: "ic_slack", bundle: Bundle(identifier: "CustomBundle"))) +::: + +## Enterprise Options + +There are also configuration options specific to Enterprise connections: + +### enterpriseConnectionUsingActiveAuth + +By default Enterprise connections will use Web Authentication. However, you can specify which connections will alternatively use credential authentication and prompt for a username and password. + +```swift +.withOptions { + $0.enterpriseConnectionUsingActiveAuth = ["enterprisedomain.com"] +} +``` + +### activeDirectoryEmailAsUsername + +When in credential authentication mode, should the user require their email as an identifier? The default is `false`, and instead requires a username. + +```swift +.withOptions { + $0.activeDirectoryEmailAsUsername = true +} +``` + +## Logging Options + +Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings. + +### logLevel + +By default this is `.off`, *Syslog* logging levels are supported. + +```swift +.withOptions { + $0.logLevel = .all +} +``` + +### logHttpRequest + +Whether or not to log Auth0.swift API requests. By default this is `false`. + +```swift +.withOptions { + $0.logHttpRequest = true +} +``` + +### loggerOutput + +Specify logger output handler, by default this uses the `print` statement. + +```swift +.withOptions { + $0.loggerOutput = CleanroomLockLogger() +} +``` + +In the code above, the *loggerOutput* has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the *loggerOutput* protocol. You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger. + +```swift +class CleanroomLockLogger: LoggerOutput { + func message(_ message: String, level: LoggerLevel, filename: String, line: Int) { + let channel: LogChannel? + switch level { + case .debug: + channel = Log.debug + case .error: + channel = Log.error + case .info: + channel = Log.info + case .verbose: + channel = Log.verbose + case .warn: + channel = Log.warning + default: + channel = nil + } + channel?.message(message, filePath: filename, fileLine: line) + } +} +``` diff --git a/fr-ca/articles/libraries/lock-ios/v2/custom-fields.md b/fr-ca/articles/libraries/lock-ios/v2/custom-fields.md new file mode 100644 index 0000000000..3ce74320cf --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/custom-fields.md @@ -0,0 +1,44 @@ +--- +section: libraries +title: Custom Fields at Signup +description: Adding additional fields to signups with Lock v2 for iOS +topics: + - libraries + - lock + - ios +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock v2 for iOS - Custom Fields at Signup + +**Lock v2 for iOS** allows you to specify additional fields that the user must complete before creating a new account. The extra fields will be shown after the basic fields (email, username, password). + +## Adding custom fields + +When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata). + +```swift +.withOptions { + $0.customSignupFields = [ + CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)), + CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)) + ] +} +``` + +::: note +You must specify the icon to use with your custom text field. +::: + +That's it! If you have enabled users Sign Up in the Application's Dashboard, after they complete the basic fields (email/username, password) and hit Submit, they will be prompted to fill the remaining fields. + +::: note +Note that the user must fill all of the custom fields before being able to complete signup. +::: + +When requesting a user Sign Up or Sign In, the extra fields will be attached to the `user_metadata` attribute in the request body. You can access them by querying the user profile at any time, even from the Dashboard in the User's section. diff --git a/fr-ca/articles/libraries/lock-ios/v2/customization.md b/fr-ca/articles/libraries/lock-ios/v2/customization.md new file mode 100644 index 0000000000..438a224801 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/customization.md @@ -0,0 +1,371 @@ +--- +section: libraries +toc: true +url: /libraries/lock-ios/v2/customization +title: Lock for iOS v2 Style Customization Options +description: Styling and customization options for the style of Lock v2 for iOS +topics: + - libraries + - lock + - ios +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Lock v2 for iOS - Style Customization Options + +There are numerous options to configure Lock's style and appearance listed below. In addition, there are also quite a few options available to alter Lock's behavior and functionality in the [Behavior Configuration Options](/libraries/lock-ios/v2/configuration) page. + +## Customizing Lock's appearance + +Style customization options can be added to your Lock initialization using `withStyle`. + +```swift +Lock + .classic() + .withStyle { + $0.title = "Company LLC" + $0.logo = LazyImage(name: "company_logo") + $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0) + } + .present(from: self) +``` + +## Header Style Options + +### headerBlur + +Blur effect style used. It can be any value defined in `UIBlurEffectStyle`. + +```swift +.withStyle { + $0.headerBlur = .extraLight +} +``` + +### headerColor + +Color used as the header background color. By default it has no color, just a blur. + +```swift +.withStyle { + $0.headerColor = UIColor? = nil +} +``` + +### logo + +Header logo image + +```swift +.withStyle { + $0.logo = LazyImage(name: "company_logo") +} +``` + +### headerCloseIcon + +The "close" icon in the header can be altered. + +```swift +.withStyle { + $0.headerCloseIcon = LazyImage(name: "ic_close") +} +``` + +### headerBackIcon + +The "back" icon in the header can be altered. + +```swift +.withStyle { + $0.headerBackIcon = LazyImage(name: "ic_close") +} +``` + +## Title Style Options + +### hideTitle + +Hide header title and show only the logo. By default this option is false. + +```swift +.withStyle { + $0.hideTitle = false +} +``` + +### title + +Title text used in the header + +```swift +.withStyle { + $0.title = "Company LLC" +} +``` + +### titleColor + +Color used as the header title color. + +```swift +.withStyle { + $0.titleColor = UIColor.black +} +``` + +## Button and Component Style Options + +### buttonTintColor + +Color used as the primary button tint color. + +```swift +.withStyle { + $0.buttonTintColor = UIColor.white +} +``` + +### disabledColor + +Color used as the Lock disabled component color. + +```swift +.withStyle { + $0.disabledColor = UIColor(red: 0.8902, green: 0.898, blue: 0.9059, alpha: 1.0) +} +``` + +### disabledTextColor + +Color used as the Lock disabled component text color. + +```swift +.withStyle { + $0.disabledTextColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0) +} +``` + +### hideButtonTitle + +Hide primary button title and show only the icon. By default this option is false. + +```swift +.withStyle { + $0.hideButtonTitle = false +} +``` + +### primaryColor + +Color used as the Lock primary color. + +```swift +.withStyle { + $0.primaryColor = UIColor.orange +} +``` + +## Input Field Styles + +### inputTextColor + +The color of input field text. + +```swift +.withStyle { + $0.inputTextColor = UIColor.black +} +``` + +### inputPlaceholderTextColor + +The color of the placeholder text in input fields. + +```swift +.withStyle { + $0.inputPlaceholderTextColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00) +} +``` + +### inputBorderColor + +The color of the border of input fields. + +```swift +.withStyle { + $0.inputBorderColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00) +} +``` + +### inputBorderColorError + +The color of the border of input fields which have invalid values. + +```swift +.withStyle { + $0.inputBorderColorError = UIColor.red +} +``` + +### inputBackgroundColor + +The color of the background of input fields. + +```swift +.withStyle { + $0.inputBackgroundColor = UIColor.white +} +``` + +### inputIconBackgroundColor + +The color of the background of input field icons. + +```swift +.withStyle { + $0.inputIconBackgroundColor = UIColor(red: 0.9333, green: 0.9333, blue: 0.9333, alpha: 1.0) +} +``` + +### inputIconColor + +The color of the input field icons. + +```swift +.withStyle { + $0.inputIconColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0) +} +``` + +## Status Bar Styles + +### UIStatusBarAnimation + +The Lock Controller Status Bar update animation. + +```swift +.withStyle { + $0.UIStatusBarAnimation = .none +} +``` + +### statusBarHidden + +The Lock Controller Status Bar's visibility. + +```swift +.withStyle { + $0.statusBarHidden = false +} +``` + +### UIStatusBarStyle + +The Lock Controller Status Bar style. + +```swift +.withStyle { + $0.UIStatusBarStyle = .default +} +``` + +### UISearchBarStyle + +The Lock Passwordless Search Bar style. + +```swift +.withStyle { + $0.UISearchBarStyle = .default +} +``` + +## Other Style Options + +### textColor + +The color for the text in the body. + +```swift +.withStyle { + $0.textColor = UIColor.black +} +``` + +### backgroundColor + +Color used as the Lock background color. + +```swift +.withStyle { + $0.backgroundColor = UIColor.white +} +``` + +### backgroundImage + +Image used as the Lock background + +```swift +.withStyle { + $0.backgroundImage = LazyImage(name: "company_logo") +} +``` + +### oauth2 + +Any non-db OAuth2 connection can have styles customized by mapping a connection name with an `AuthStyle` + +```swift +.withStyle { + $0.oauth2["slack"] = AuthStyle( + name: "Slack", + color: UIColor(red: 0.4118, green: 0.8078, blue: 0.6588, alpha: 1.0), + withImage: LazyImage(name: "ic_slack") + ) +} +``` + +### seperatorTextColor + +Social separator label color. + +```swift +.withStyle { + $0.seperatorTextColor = UIColor(red: 0.0, green: 0.0, blue: 0.0, alpha: 0.54) +} +``` + +### secondaryButtonColor + +The color of secondary buttons. + +```swift +.withStyle { + $0.secondaryButtonColor = UIColor.black +} +``` + +### tabTextColor + +The color of the text on the database login tab. + +```swift +.withStyle { + $0.tabTextColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6) +} +``` + +### tabTintColor + +The color of the tinting on the database login tab. + +```swift +.withStyle { + $0.tabTintColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6) +} +``` diff --git a/fr-ca/articles/libraries/lock-ios/v2/index.md b/fr-ca/articles/libraries/lock-ios/v2/index.md new file mode 100644 index 0000000000..ccde6a136d --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/index.md @@ -0,0 +1,228 @@ +--- +section: libraries +toc: true +title: Lock v2 for iOS +description: A widget that provides a frictionless login and signup experience for your native iOS apps. +mobileimg: media/articles/libraries/lock-ios.png +topics: + - libraries + - lock + - ios +contentType: + - reference + - index + - how-to +useCase: + - add-login + - enable-mobile-auth +--- +# Lock v2 for iOS + +::: warning +Auth0 encourages the use of [web authentication via Universal Login](/guides/login/universal-vs-embedded) rather than native username/password authentication whenever possible. +::: + +This reference guide will show you how to implement the Lock user interface, and give you the details on configuring and customizing Lock in order to use it as the UI for your authentication needs. However, if you'd like to learn how to do more with Auth0 and Swift, such as how to save, call and refresh Access Tokens, get user profile info, and more, check out the [Auth0.swift SDK](/libraries/auth0-swift). Or, take a look at the [Swift Quickstart](/quickstart/native/ios-swift) to walk through complete examples and see options, both for using Lock as the interface, and for using a custom interface. + +::: note +Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift) on GitHub. +::: + +## Requirements + +- iOS 9+ +- Xcode 10+ +- Swift 4+ + +<%= include('../_includes/_dependencies') %> + +## Setup + +### Integrate with your Application + +Lock needs to be notified when the application is asked to open a URL. You can do this in the `AppDelegate` file. + +```swift +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { + return Lock.resumeAuth(url, options: options) +} +``` + +### Import Lock + +Import **Lock** wherever you'll need it + +```swift +import Lock +``` + +### Auth0 Credentials + +In order to use Lock you need to provide your Auth0 Client Id and Domain, which can be found in your [Auth0 Dashboard](${manage_url}), under your Application's settings. + +In your application bundle you can add a `plist` file named `Auth0.plist` that will include your credentials with the following format. + +```xml + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` + +## Implementation of Lock Classic + +Lock Classic handles authentication using Database, Social, and Enterprise connections. + +### OIDC Conformant Mode + +It is strongly encouraged that this SDK be used in OIDC Conformant mode. When this mode is enabled, it will force the SDK to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. By default this is `false` + +```swift +.withOptions { + $0.oidcConformant = true +} +``` + +::: note +For more information, please see our [Introduction to OIDC Conformant Authentication](/api-auth/intro) and the [OIDC adoption guide](/api-auth/tutorials/adoption). +::: + +To show Lock, add the following snippet in your `UIViewController`. + +```swift +Lock + .classic() + // withConnections, withOptions, withStyle, and so on + .withOptions { + $0.oidcConformant = true + $0.scope = "openid profile" + } + .onAuth { credentials in + // Let's save our credentials.accessToken value + } + .present(from: self) +``` + +## Use Auth0.Swift Library to access user profile + +To access user profile information, you will need to use the `Auth0.Swift` library: + +```swift +guard let accessToken = credentials.accessToken else { return } +Auth0 + .authentication() + .userInfo(withAccessToken: accessToken) + .start { result in + switch result { + case .success(let profile): + // You've got a UserProfile object + case .failure(let error): + // You've got an error + } +} +``` + +Check out the [Auth0.Swift Library Documentation](/libraries/auth0-swift) for more information about its uses. + +## Specify Connections + +Lock will automatically load the connections configured for your application. If you wish to override the default behavior, you can manually specify which connections it should display to users as authentication options. This can be done by calling the method and supplying a closure that can specify the connection(s). + +Adding a database connection: + +```swift +.withConnections { + $0.database(name: "Username-Password-Authentication", requiresUsername: true) +} +``` + +Adding multiple social connections: + +```swift +.withConnections { + $0.social(name: "facebook", style: .Facebook) + $0.social(name: "google-oauth2", style: .Google) +} +``` + +## Styling and Customization + +Lock provides many styling options to help you apply your own brand identity to Lock using `withStyle`. For example, changing the primary color and header text of your Lock widget: + +### Customize your title, logo, and primary color + +```swift +.withStyle { + $0.title = "Company LLC" + $0.logo = LazyImage(named: "company_logo") + $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0) +} +``` + +::: note +You can see the complete set of styling options to alter the appearance of Lock for your app in the [Customization Guide](/libraries/lock-ios/v2/customization). +::: + +## Configuration Options + +There are numerous options to configure Lock's behavior. Below is an example of Lock configured to allow it to be closable, to limit it to only usernames (and not emails), and to only show the Login and Reset Password screens. + +```swift +Lock + .classic() + .withOptions { + $0.closable = true + $0.usernameStyle = [.Username] + $0.allow = [.Login, .ResetPassword] + } +``` + +::: note +You can see the complete set of behavior configuration options to alter the way Lock works for your app in the [Configuration Guide](/libraries/lock-ios/v2/configuration). +::: + +## Password Manager Support + +By default, password manager support using [1Password](https://1password.com/) is enabled for database connections. 1Password support will still require the user to have the 1Password app installed for the option to be visible in the login and signup screens. You can disable 1Password support using the enabled property of the passwordManager. + +```swift +.withOptions { + $0.passwordManager.enabled = false +} +``` + +By default the `appIdentifier` will be set to the app's bundle identifier and the `displayName` will be set to the app's display name. You can customize these as follows: + +```swift +.withOptions { + $0.passwordManager.appIdentifier = "www.myapp.com" + $0.passwordManager.displayName = "My App" +} +``` + +You will need to add the following to your app's `info.plist`: + +``` +LSApplicationQueriesSchemes + + org-appextension-feature-password-management + +``` + +<%= include('../_includes/_roadmap') %> + +## Next Steps + +::: next-steps +- [Customizing the Style of Lock](/libraries/lock-ios/v2/customization) +- [Customizing the Behavior of Lock](/libraries/lock-ios/v2/configuration) +- [Adding Custom Signup Fields to Lock](/libraries/lock-ios/v2/custom-fields) +- [Lock Internationalization](/libraries/lock-ios/v2/internationalization) +- [Logging out Users](/logout) +::: diff --git a/fr-ca/articles/libraries/lock-ios/v2/internationalization.md b/fr-ca/articles/libraries/lock-ios/v2/internationalization.md new file mode 100644 index 0000000000..cda2d77a2b --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/internationalization.md @@ -0,0 +1,70 @@ +--- +section: libraries +title: Internationalization in Lock v2 for iOS +description: Internationalization support in Lock v2 for iOS +topics: + - libraries + - lock + - ios + - i18n +contentType: + - how-to + - reference +useCase: + - add-login + - enable-mobile-auth +--- + +# Internationalization + +By default, **Lock v2 for iOS** displays all text in English. If you wish to display text in another language, or you wish to alter the text values for your application, you may provide a `Lock.strings` file and define values to be used for the various text items that Lock might display. + +More information about how to handle languages can be found in the official Apple documentation on [Internationalization and Localization](https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/Introduction/Introduction.html#//apple_ref/doc/uid/10000171i-CH1-SW1) + +## Lock String Values + +For a full list of the terms used by Lock, see the base [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file in the Lock.swift repository. + +### Providing alternative English strings + +If you want to change some or all of the existing terms, you can do this by downloading and adding the [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file to your project. + +Select the **Lock.strings** file and in the `File inspector` click on `Localize...` + +![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize.png) + +Then select `English`: + +![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize_english.png) + +Now lets take a couple of terms in **Lock.strings** and update them with alternative text: + +```text +// Forgot password +"com.auth0.lock.database.button.forgot_password" = "Did you forget your password?"; +// tos & privacy +"com.auth0.lock.database.button.tos" = "Signing up is an indication of your agreement to our terms of\n service and privacy policy"; +``` + +### Supporting other languages + +To add another language you first of all need to add the new language under `Project/Info` + +![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language.png) + +Add the new language and ensure that **Lock.strings** is selected + +![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language_step_2.png) + +You will notice under **Lock.strings** a new file has been created for your specified language, based upon the **Reference Language** selection. + +Now you are ready to translate to your desired language. + +### Notes + +Some terms use parameters and it's important to note their placement in your translation. In particular multiple parameter terms such as: + +```text +// No more than %@{count} identical characters in a row (such as, \"%@{identical sample}\" not allowed) +"com.auth0.lock.error.password.no_more_identical" = "No more than %1$d identical characters in a row (such as, \"%2$@\" not allowed)"; +``` diff --git a/fr-ca/articles/libraries/lock-ios/v2/logging.md b/fr-ca/articles/libraries/lock-ios/v2/logging.md new file mode 100644 index 0000000000..821a5dae26 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/logging.md @@ -0,0 +1,73 @@ +--- +section: libraries +title: Logging in Lock for iOS v2 +description: Logging in Lock for iOS v2 +topics: + - libraries + - lock + - ios + - logs +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Logging in Lock for iOS v2 + +Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings. + +## logLevel + +By default this is `.off`, *Syslog* logging levels are supported. + +```swift +.withOptions { + $0.logLevel = .all +} +``` + +## logHttpRequest + +This option allows you to choose whether or not to log Auth0.swift API requests. By default this is `false`. + +```swift +.withOptions { + $0.logHttpRequest = true +} +``` + +## loggerOutput + +You can specify a logger output handler, by default this uses the `print` statement. + +```swift +.withOptions { + $0.loggerOutput = CleanroomLockLogger() +} +``` + +In the code above, the `loggerOutput` has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the `loggerOutput` protocol. You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger. + +```swift +class CleanroomLockLogger: LoggerOutput { + func message(_ message: String, level: LoggerLevel, filename: String, line: Int) { + let channel: LogChannel? + switch level { + case .debug: + channel = Log.debug + case .error: + channel = Log.error + case .info: + channel = Log.info + case .verbose: + channel = Log.verbose + case .warn: + channel = Log.warning + default: + channel = nil + } + channel?.message(message, filePath: filename, fileLine: line) + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/libraries/lock-ios/v2/migration.md b/fr-ca/articles/libraries/lock-ios/v2/migration.md new file mode 100644 index 0000000000..274c9bd896 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/migration.md @@ -0,0 +1,292 @@ +--- +section: libraries +toc: true +url: /libraries/lock-ios/v2/migration +title: Migrating from v1 to v2 of Lock for iOS +description: A migration guide to assist with migration from Lock v1 (Swift) to Lock v2 (Swift). +public: false +topics: + - libraries + - lock + - ios + - migrations +contentType: + - reference + - how-to +useCase: + - add-login + - enable-mobile-auth + - migrate +--- +# Migrating from Lock iOS v1 to v2 + +Lock 2.0 is the latest major release of Lock iOS-OSX. This guide is provided in order to ease the transition of existing applications using Lock 1.x to the latest APIs. + +## Requirements + +- iOS 9.0+ +- Xcode 8.0+ +- Swift 3.0+ + +### Objective-C support + +Lock v2 cannot be used from Objective-C, since its public API relies on Swift features and that makes them unavailable in ObjC codebases. + +If you are willing to have some Swift code in your existing application, you can follow this [guide](https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html) on how to mix Objective-C and Swift and then use Lock v2 from the Swift files. + +If that's not an option, we recommend sticking with Lock v1 or using [Auth0.swift](/libraries/auth0-swift) to build your own interface for user logins and signups. + +## Benefits of upgrading + +- **Complete Swift 3 Compatibility:** The new version includes the adoption of the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). +- **Improved UI:** having a professional looking login box that displays well on any device. +- **Extensive configuration:** Lock provides improved configuration options to help customize the experience to your users needs. +- **Safari controller for web-based Auth:** Following Google's recent ban of WebView based auth, Lock (and Auth0.swift) will always use `SFSafariViewController` when web auth is needed. +- **API Authorization support:** Adds support for Auth0 [API Authorization](https://auth0.com/docs/api-auth) + +## Changes from v1 + +Lock 2.0 has adopted to all of the new Swift 3 changes and conventions, including the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). Because of this, almost every API in Lock has been modified in some way. This guide will attempt to identify the most common usages and how they have changed, to help you get started with Lock 2.0. For yet more information on Lock 2.0, you can also see the [Lock 2.0 Reference](libraries/lock-ios) documentation. + +### Integration with your Application + +Lock needs to be notified for some of your application state changes and some events/notifications your application receives from the OS. You can do all these things in the `AppDelegate` + +#### Application finished launching + +In Lock v1 you'd add the following: + +```swift +func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool { + A0Lock.sharedLock().applicationLaunchedWithOptions(launchOptions) + //Your code + return true +} +``` + +In Lock v2, this is no longer required. + +#### Application is asked to open URL + +In Lock v1 you'd add the following: + +```swift +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + return A0Lock.shared().handle(url, sourceApplication: app) +} +``` + +In Lock v2 you need to instead use the following: + +```swift +func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + return Lock.resumeAuth(url, options: options) +} +``` + +#### Application is asked to continue a User Activity + +If you are using Lock passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`: + +```swift +func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool { + return Lock.continueAuth(using: userActivity) +} +``` + +### Usage + +`Lock` by default will handle Email/Password, Enterprise & Social authentication based on your application's connections enabled in your [Auth0 Dashboard](${manage_url}) under "Connections" in your application settings. + +#### Auth0 credentials + +Like in v1, in your application bundle you can add a `plist` file named `Auth0.plist` with the following format: + +```xml + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` + +This will load your Auth0 credentials. + +#### Classic mode (Database, Enterprise & Social authentication) + +In v1 to show Lock from a `UIViewController` you'd add the following code: + +```swift +let lock = A0Lock.shared() +let controller = lock.newLockViewController() +controller.onAuthenticationBlock = {(profile, token) in + // Do something with token & profile, such as save them. + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismissViewController(animated: true, completion: nil) +} +lock.present(controller, from: self) +``` + +In v2, to show Lock, the following code will be necessary: + +```swift +Lock + .classic() + .onAuth { credentials in + print("Authenticated!") + } + .present(from: self) +``` + +So, in the `onAuth` callback, you'd only receive the credentials of the user when the authentication is successful. + +::: note +In contrast with Lock v1, in v2, Lock will dismiss itself so there is no need to call `dismissViewController(animated:, completion:)` in any of the callbacks. +::: + +In the case you need to know about the errors or signup, there are the corresponding `onError` and `onSignUp` callbacks that can be employed. + +```swift +Lock + .classic() + .onAuth { credentials in + print("Authenticated!") + } + .onSignUp { email, attributes in + print("New user with email \(email)!") + } + .onError { error in + print("Failed with error \(error.localizedString)") + } + .present(from: self) +``` + +::: note +The callback `onSignUp` is only called when the "login after signup" is disabled. +::: + +#### Passwordless mode (Email & SMS connections) + +In v1 to show Lock Passwordless from a `UIViewController` you'd need to use either: + +Email: + +```swift +let lock = A0Lock.shared() +let controller: A0EmailLockViewController = lock.newEmailViewController() +controller.useMagicLink = true +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile, such as save them. + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismiss(animated: true, completion: nil) +} +lock.presentEmailController(controller, from: self) +``` + +or SMS: + +```swift +let lock = A0Lock.shared() +let controller: A0SMSLockViewController = lock.newSMSViewController() +controller.useMagicLink = true +controller.onAuthenticationBlock = { (profile, token) in + // Do something with token & profile, such as save them. + // Lock will not save the Token and the profile for you. + // And dismiss the UIViewController. + self.dismiss(animated: true, completion: nil) +} +lock.presentSMSController(controller, from: self) +``` + +In V2 both email and sms now use the same method: + +```swift +Lock + .passwordless() + .onAuth { credentials in + print("Authenticated!") + } + .present(from: self) +``` + +**Notes:** + +- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS. +- The `audience` option is not available in Passwordless. + +#### Configuration options + +If you needed to tweak Lock behaviour using its options in v1, you would use the following format: + +```swift +let controller = A0Lock.shared().newLockViewController() +controller?.closable = true +controller?.connections = ["facebook", "github", "my-database"] +``` + +In Lock v2 you can do it all before presenting Lock by using this format: + +```swift +Lock + .withOptions { options in + options.closable = true + options.allowedConnections = ["facebook", "github", "my-database"] + } + // continue configuring and then present Lock +``` + +#### UI customizations + +In v1 all UI customizations were performed using the `A0Theme` object in this format: + +```swift +let theme = A0Theme() +theme.register(.blue, forKey: A0ThemeTitleTextColor) +A0Theme.sharedInstance().register(theme) +``` + +In Lock v2, the UI customization is done using the `withStyle` function: + +```swift +Lock + .classic() + .withStyle { style in + style.titleColor = .blue + } + // other customizations + .present(from: self) +``` + +## Use Auth0.Swift Library to access user profile + +Lock can no longer directly access user profile information. To do so, you will now need to use the [Auth0.Swift library](/libraries/auth0-swift). Below is an example of accessing `userInfo` with `Auth0.Swift`: + +```swift +guard let accessToken = credentials.accessToken else { return } +Auth0 + .authentication() + .userInfo(token: accessToken) + .start { result in + switch result { + case .success(let profile): + // You've got a UserProfile object + case .failure(let error): + // You've got an error + } +} +``` + +### Delegation + +<%= include('../../../_includes/_deprecate-delegation') %> + +Delegation is not available through Lock. It can be implemented via a legacy method in [Auth0.Swift](/libraries/auth0-swift) for tenants which existed prior to June 2017. + +<%= include('../_includes/_roadmap') %> diff --git a/fr-ca/articles/libraries/lock-ios/v2/passwordless.md b/fr-ca/articles/libraries/lock-ios/v2/passwordless.md new file mode 100644 index 0000000000..5f9478eca3 --- /dev/null +++ b/fr-ca/articles/libraries/lock-ios/v2/passwordless.md @@ -0,0 +1,59 @@ +--- +section: libraries +title: Lock Passwordless for iOS +description: Using Passwordless authentication with Lock for iOS v2 +topics: + - libraries + - lock + - ios + - passwordless +contentType: + - reference +useCase: + - add-login + - enable-mobile-auth +--- +# Lock Passwordless for iOS + +Lock Passwordless handles passwordless authentication using email and sms connections. + +To use Passwordless Authentication you need Lock.Swift version 2.14.0 or greater. + +To show Lock, add the following snippet in your `UIViewController`. + +```swift +Lock + .passwordless() + .withOptions { + $0.oidcConformant = true + } + // withConnections, withOptions, withStyle, and so on. + .onAuth { credentials in + // Save the Credentials object + } + .present(from: self) +``` + +**Notes:** + +- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS. + +### Passwordless Method + +When using Lock Passwordless the default `passwordlessMethod` is `.code` which sends the user a one time passcode to login. If you want to use [Universal Links](/dashboard/guides/applications/enable-universal-links) you can add the following: + +```swift +.withOptions { + $0.passwordlessMethod = .magicLink +} +``` + +### Activity callback + +If you are using Lock Passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`: + +```swift +func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool { + return Lock.continueAuth(using: userActivity) +} +``` diff --git a/fr-ca/articles/libraries/lock/index.yml b/fr-ca/articles/libraries/lock/index.yml new file mode 100644 index 0000000000..a120986e44 --- /dev/null +++ b/fr-ca/articles/libraries/lock/index.yml @@ -0,0 +1,7 @@ +versioning: + baseUrl: libraries/lock + current: v11 + versions: + - v11 + defaultArticles: + v11: index diff --git a/fr-ca/articles/libraries/lock/v11/api.md b/fr-ca/articles/libraries/lock/v11/api.md new file mode 100644 index 0000000000..58949c9ed4 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/api.md @@ -0,0 +1,308 @@ +--- +section: libraries +toc: true +description: Details on the Lock v11 API. +topics: + - libraries + - lock +contentType: + - reference +useCase: + - add-login +--- +# Lock API Reference + +Lock has many methods, features, and configurable options. This reference is designed to direct you to the ones that you need, and discuss how to use them. Click below to go straight the method you're looking for, or just browse! If you're looking for information about events emitted by Lock, they're listed under the [on()](#on-) method section! + +- [new Auth0Lock](#auth0lock) - Instantiating Lock +- [getUserInfo()](#getuserinfo-) - Obtaining the profile of a logged in user +- [show()](#show-) - Showing the Lock widget +- [on()](#on-) - Listening for events +- [resumeAuth()](#resumeauth-) - Use to complete authentication flow when `autoParseHash` is false +- [checkSession()](#checksession-) - Get a new token from Auth0 for an authenticated user +- [logout()](#logout-) - Log out the user + +## Auth0Lock + +```js +new Auth0Lock(clientID, domain, options) +``` + +Initializes a new instance of `Auth0Lock` configured with your application's `clientID` and your account's `domain` from your [Auth0](${manage_url}/) management dashboard. The third and optional parameter is an `options` object used to configure Lock for your application's needs. You can find this information at your [application settings](${manage_url}/#/applications). + +- **clientId {String}**: Required parameter. Your application's _clientId_ in Auth0. +- **domain {String}**: Required parameter. Your Auth0 _domain_. Usually _your-account.auth0.com_. +- **options {Object}**: Optional parameter. Allows for the configuration of Lock's appearance and behavior. See [the configuration options page](/libraries/lock/v11/configuration) for details. + +**Example:** + +```js +var Auth = (function() { + + var privateStore = {}; + + function Auth() { + // Instantiate Lock - without custom options + this.lock = new Auth0Lock( + '', + '' + ); + } + + Auth.prototype.getProfile = function() { + return privateStore.profile; + }; + + Auth.prototype.authn = function() { + // Listening for the authenticated event and get profile + this.lock.on("authenticated", function(authResult) { + // Use the token in authResult to getUserInfo() and save it if necessary + this.getUserInfo(authResult.accessToken, function(error, profile) { + if (error) { + // Handle error + return; + } + + //save Access Token only if necessary + privateStore.accessToken = accessToken; + privateStore.profile = profile; + + // Update DOM + }); + }); + }; + return Auth; +}()); +``` + +## getUserInfo() + +```js +getUserInfo(accessToken, callback) +``` + +Once the user has logged in and you are in possession of a token, you can use that token to obtain the user's profile with `getUserInfo`. This method replaces the deprecated `getProfile()`. + +- **accessToken {String}**: User token. +- **callback {Function}**: Will be invoked after the user profile been retrieved. + +**Example:** + +```js +lock.getUserInfo(accessToken, function(error, profile) { + if (!error) { + alert("hello " + profile.name); + } +}); +``` + +## show() + +```js +show(options) +``` + +The `show` method displays the widget. Beginning with Lock version 10.2.0, the `show` method can now accept an `options` object as a parameter. Note that this parameter is meant to be used as a way to _override_ your Lock's `options` for this particular displaying of the widget - options should be _set_ when instantiating Lock, and _overridden_, only if needed for your specific use case, here. + +The following subset of `options` to be overridden from the values they were given (or their defaults) when Lock was instantiated: + +- [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-) +- [auth.params](/libraries/lock/v11/configuration#params-object-) +- [allowLogin](/libraries/lock/v11/configuration#allowlogin-boolean-) +- [allowSignUp](/libraries/lock/v11/configuration#allowsignup-boolean-) +- [allowForgotPassword](/libraries/lock/v11/configuration#allowforgotpassword-boolean-) +- [initialScreen](/libraries/lock/v11/configuration#initialscreen-string-) +- [rememberLastLogin](/libraries/lock/v11/configuration#rememberlastlogin-boolean-) + +For more detail on the entire list of configurable options that can be chosen when instantiating Lock, as opposed to the limited subset above that can be overridden in the `show` method, please see the [user configurable options page](/libraries/lock/v11/configuration). + +Options override examples: + +```js +// Show the Lock widget, without overriding any options +lock.show(); +``` + +```js +// Show the Lock widget, overriding some options +lock.show({ + allowedConnections: ["twitter", "facebook"], + allowSignUp: false +}); +``` + +::: panel When to set your configuration options +Options should be set when first instantiating Lock `var lock = new Auth0Lock(clientId, domain, options);`. Options should only be passed to `show` in order to override your previously set options while displaying the widget at this particular time and place. + +Previous users of Lock 9 should note that this is a different behavior from `options` in Lock 9, where all options were set as parameters of `show` and not at instantiation. +::: + +There is an additional option that can be set in the `show` method called `flashMessage`. + +### flashMessage + +This object is _only_ available as an option for the `show` method, not for use in the normal `options` object when instantiating Lock. The `flashMessage` object shows an error or success flash message when Lock is shown. It has the following parameters: + +- **type** {String}: The message type, it should be either `error` or `success`. +- **text** {String}: The text to show. + +An example of usage: + +```js +lock.show({ + flashMessage:{ + type: 'success', + text: 'Amazing Success!!' + } +}); +``` + +![Lock - Flash Message](/media/articles/libraries/lock/v10/flashMessage.png) + +A practical application of the `flashMessage` option is to handle authorization errors. The `flashMessage` can be populated with error description text. + +```js +lock.on('authorization_error', function(error) { + lock.show({ + flashMessage: { + type: 'error', + text: error.errorDescription + } + }); +}); +``` + +So, if `tester@example.com` were now to try to sign in, being a user who is blocked, the user will be shown Lock again, and receive the following error message: + +![Lock - Flash Message](/media/articles/libraries/lock/v10/flashmessage2.png) + +Rather than simply failing to login, and Lock closing. + +## hide() + +```js +hide() +``` + +The `hide` method closes the widget if it is currently open. The widget closes itself under most circumstances, so this method would primarily be invoked in specific use cases only. For instance, one might wish to listen for the `unrecoverable_error` event and then `hide` the Lock and redirect to their own custom error page. Another example is users who are implementing [popup mode](/libraries/lock/v11/popup-mode), and might need to manually `hide` the widget after the `authenticated` event fires. + +Example usage to hide (close) the Lock widget in popup mode: + +```js +// Listen for authenticated event and hide Lock +lock.on("authenticated", function() { + lock.hide(); + + // Whatever else you'd like to do on authenticated event + +}); +``` + +## on() + +```js +on(event, callback) +``` + +Lock will emit events during its lifecycle. The `on` method can be used to listen for particular events and react to them. + +- `show`: emitted when Lock is shown. Has no arguments. +- `hide`: emitted when Lock is hidden. Has no arguments. +- `unrecoverable_error`: emitted when there is an unrecoverable error, for instance when no connection is available. Has the error as the only argument. +- `authenticated`: emitted after a successful authentication. Has the authentication result as the only argument. The authentication result contains the token which can be used to get the user's profile or stored to log them in on subsequent checks. +- `authorization_error`: emitted when authorization fails. Has error as the only argument. +- `hash_parsed`: every time a new Auth0Lock object is initialized in redirect mode (the default), it will attempt to parse the hash part of the url looking for the result of a login attempt. This is a low level event for advanced use cases and `authenticated` and `authorization_error` should be preferred when possible. After that this event will be emitted with `null` if it couldn't find anything in the hash. It will be emitted with the same argument as the `authenticated` event after a successful login or with the same argument as `authorization_error` if something went wrong. This event won't be emitted in [popup mode](/libraries/lock/v11/authentication-modes) because there is no need to parse the url's hash part. +- `forgot_password ready`: emitted when the "Forgot password" screen is shown. (Only in Version >`10.18`) +- `forgot_password submit`: emitted when the user clicks on the submit button of the "Forgot password" screen. (Only in Version >`10.14`) +- `signin ready`: emitted when the "Sign in" screen is shown. +- `signup ready`: emitted when the "Sign up" screen is shown. +- `signin submit`: emitted when the user clicks on the submit button of the "Login" screen. (Only in Version >`10.18`) +- `signup submit`: emitted when the user clicks on the submit button of the "Sign Up" screen. (Only in Version >`10.18`) +- `federated login`: emitted when the user clicks on a social connection button. Has the connection name and the strategy as arguments. (Only in Version >`10.18`) +- `socialOrPhoneNumber ready`: emitted when the Passwordless screen with Social + Phone Number is shown +- `socialOrPhoneNumber submit`: emitted when the Passwordless screen with Social + Phone Number is submitted +- `socialOrEmail ready`: emitted when the Passwordless screen with Social + Email is shown +- `socialOrEmail submit`: emitted when the Passwordless screen with Social + Email is submitted +- `vcode ready`: emitted when the Passwordless screen with the one-time-password is shown +- `vcode submit`: emitted when the Passwordless screen with the one-time-password is submitted + +The `authenticated` event listener has a single argument, an `authResult` object. This object contains the following properties: `accessToken`, `idToken`, `state`, `refreshToken` and `idTokenPayload`. + +An example use of the `authenticated` event: + +```js +var Auth = (function() { + + var privateStore = {}; + + function Auth() { + this.lock = new Auth0Lock( + '', + '' + ); + } + + Auth.prototype.getProfile = function() { + return privateStore.profile; + }; + + Auth.prototype.authn = function() { + // Listening for the authenticated event + this.lock.on("authenticated", function(authResult) { + // Use the token in authResult to getUserInfo() and save it if necessary + this.getUserInfo(authResult.accessToken, function(error, profile) { + if (error) { + // Handle error + return; + } + + privateStore.profile = profile; + + }); + }); + }; + return Auth; +}()); +``` + +## resumeAuth() + +This method can only be used when you set the [auth.autoParseHash](/libraries/lock/v11/configuration#autoparsehash-boolean-) option to `false`. You'll need to call `resumeAuth` to complete the authentication flow. This method is useful when you're using a client-side router that uses a `#` to handle urls (angular2 with `useHash`, or react-router with `hashHistory`). + +- **hash** {String}: The hash fragment received from the redirect. +- **callback** {Function}: Will be invoked after the parse is done. Has an error (if any) as the first argument and the authentication result as the second one. If there is no hash available, both arguments will be `null`. + +```js +lock.resumeAuth(hash, function(error, authResult) { + if (error) { + alert("Could not parse hash"); + } + //This is just an example; you should not log Access Tokens in production. + console.log(authResult.accessToken); +}); +``` + +## checkSession() + +The `checkSession` method allows you to acquire a new token from Auth0 for a user who is already authenticated against Auth0 for your domain. It takes the following parameters: + +- **options** {Object}: Optional. Accepts any valid OAuth2 parameters that would normally be sent to `/authorize`. If you omit them, it will use the ones provided when initializing Auth0. +- **callback** {Function}: Will be invoked with the token renewal result. Has an error (if any) as the first argument and the authentication result as the second one. + +```js +lock.checkSession({}, function(err, authResult) { + // handle error or new tokens +}); +``` + +## logout() + +Logs out the user. + +- **options** {Object}: This is optional and follows the same rules as [auth0.js logout](/libraries/auth0js#logout) + +```js +lock.logout({ + returnTo: 'https://myapp.com/bye-bye' +}); +``` diff --git a/fr-ca/articles/libraries/lock/v11/authentication-modes.md b/fr-ca/articles/libraries/lock/v11/authentication-modes.md new file mode 100644 index 0000000000..b11a8d6310 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/authentication-modes.md @@ -0,0 +1,62 @@ +--- +section: libraries +description: Details about Authentication Modes with Lock v11. +toc: true +topics: + - libraries + - lock +contentType: + - how-to + - concept +useCase: + - add-login +--- +# Lock Authentication Modes + +Lock can function in two different modes. The default mode is **redirect mode**. In this mode, your user is redirected to be authenticated, and then is returned to the application. In the second mode, **popup mode**, a popup window allows the user to authenticate with the identity provider without leaving the application. + +## Redirect Mode + +When you click the IdP button (For example, Facebook) with redirect mode, you are redirected to Facebook momentarily. Redirect mode is the default with Lock v11, and is the recommended mode for almost all use cases. Once you successfully login (to Facebook, in this example), Facebook will redirect you back to your app (through Auth0). The majority of examples or samples in the reference documentation employ redirect mode. + +## Popup Mode + +If after you click on the IdP button (Facebook for example), a popup (new tab or window) is opened, it means you are using popup mode. In that popup, you'll see that Facebook page is displayed. Once you successfully login to Facebook, the popup will be closed and your web app will recognize that the user has been authenticated. The web app has **never been redirected to any other page**. + +Implementing Lock with Popup Mode is again a simple change of the `redirect` option from its default. + +```js +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}', + { + auth: { + redirect: false + } + } +); +``` + +::: note +Multi-factor authentication (MFA) is not supported when Lock is in popup mode and embedded in your application. +::: + +::: note +Popup mode does not work with Universal Login. +::: + +Some Auth0 features such as [Single Sign-out (SSO)](/sso/current/sso-auth0) between multiple applications depend on users being redirected to Auth0 to set a cookie on `'${account.namespace}'`. + +When using popup mode, a popup window will be displayed in order to set this cookie. If prompts are unnecessary, this popup window will be blank and be in a hidden iframe to minimize disruption. The reason for this is that cross-origin requests sent from your application to Auth0 are not be able to set cookies. + +If you do not want to display a popup window and do not need SSO between multiple applications, you can set `sso: false` when using Lock or auth0.js. + +For example: + +```js +var options = { + auth: { + sso: false + } +} +``` diff --git a/fr-ca/articles/libraries/lock/v11/configuration.md b/fr-ca/articles/libraries/lock/v11/configuration.md new file mode 100644 index 0000000000..d5c1e9492c --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/configuration.md @@ -0,0 +1,973 @@ +--- +section: libraries +toc: true +description: Lock v11 has many configurable options that allow you to change the behavior, appearance, and connectivity of the Lock widget - this resource provides the details on those options for you! +topics: + - libraries + - lock +contentType: + - how-to + - reference +useCase: + - add-login +--- +# Lock Configuration Options + +The **Auth0Lock** can be configured through the `options` parameter sent to the constructor. These options can alter the way that the Lock widget behaves, how it deals with connections, additional signup fields that you require for your project, the language and text values, colors, and images on the widget, and many more. Take a look at the index below if you know what you are looking for, or browse the options for more details. + +```js +var lock = new Auth0Lock('clientID', 'account.auth0.com', options); +``` + +## UI + +| Option | Description | +| --- | --- | +| [allowAutocomplete](#allowautocomplete-boolean-) | Enable or disable autocompletion on the email or username inputs | +| [allowPasswordAutocomplete](#allowpasswordautocomplete-boolean-) | Enable or disable autocompletion on password input | +| [allowShowPassword](#allowshowpassword-boolean-) | Specifies if the user can choose to show password while typing it | +| [allowedConnections](#allowedconnections-array-) | List of connections that will be available to perform authentication | +| [autoclose](#autoclose-boolean-) | Specifies if Lock closes after a login | +| [autofocus](#autofocus-boolean-) | Specifies if focus is set on the first input field | +| [avatar](#avatar-object-) | Specifies if an avatar and a username should be displayed on the Lock's header once an email or username has been entered and how to obtain it | +| [closable](#closable-boolean-) | Determines whether or not Lock can be closed | +| [container](#container-string-) | The HTML element where Lock will be rendered. This causes Lock to appear inline instead of in a modal window | +| [flashMessage](#) | Shows an `error` or `success` flash message when Lock is shown | +| [language](#language-string-) | Specifies the language of the widget | +| [languageDictionary](#languagedictionary-object-) | Change text in particular sections of Lock | +| [popupOptions](#popupoptions-object-) | Customize the location of the popup in the screen | +| [rememberLastLogin](#rememberlastlogin-boolean-) | Whether or not to show a screen that allows you to quickly log in with the account you used the last time | +| [scrollGlobalMessagesIntoView](#scrollglobalmessagesintoview-boolean-) | Specify if a globalMessage should be scrolled into the user's viewport | + +## Theme + +Theme options are grouped in the `theme` property of the `options` object. + +| Option | Description | +| --- | --- | +| [authButtons](#authbuttons-object-) | Customize the appearance of specific connection buttons | +| [labeledSubmitButton](#labeledsubmitbutton-boolean-) | whether or not the submit button has text | +| [logo](#logo-string-) | What logo should be used | +| [primaryColor](#primarycolor-string-) | Color of the primary button on the widget | + +## Authentication + +Authentication options are grouped in the `auth` property of the `options` object. + +| Option | Description | +| --- | --- | +| [audience](#audience-string-) | The API which will be consuming your Access Token | +| [autoParseHash](#autoparsehash-boolean-) | Whether or not to automatically parse hash and continue | +| [connectionScopes](#connectionscopes-object-) | Specify connection scopes | +| [params](#params-object-) | Option to send parameters at login | +| [redirect](#redirect-boolean-) | Whether or not to use redirect mode | +| [redirectUrl](#redirecturl-string-) | The URL to redirect to after auth | +| [responseMode](#responsemode-string-) | Option to send response as POST | +| [responseType](#responsetype-string-) | Response as a code or token | +| [sso](#sso-boolean-) | Determines whether Single Sign-On is enabled or not in Lock | + +### Database + +| Option | Description | +| --- | --- | +| [additionalSignUpFields](#additionalsignupfields-array-) | Additional fields collected at signup | +| [allowLogin](#allowlogin-boolean-) | Whether or not to allow login on widget | +| [allowForgotPassword](#allowforgotpassword-boolean-) | Whether or not to allow forgot password on widget | +| [allowSignUp](#allowsignup-boolean-) | Whether or not to allow signup on widget | +| [defaultDatabaseConnection](#defaultdatabaseconnection-string-) | Default shown DB connection | +| [initialScreen](#initialscreen-string-) | Which screen to show when the widget is opened | +| [loginAfterSignUp](#loginaftersignup-boolean-) | After signup, whether or not to auto login | +| [forgotPasswordLink](#forgotpasswordlink-string-) | Link to a custom forgot password page | +| [showTerms](#showterms-boolean-) | Specify if signup terms should be display | +| [mustAcceptTerms](#mustacceptterms-boolean-) | Whether or not terms must be accepted (checkbox) | +| [prefill](#prefill-object-) | Prefill values for email/username fields | +| [signUpLink](#signuplink-string-) | Set a custom url to fire when clicking "sign up" | +| [usernameStyle](#usernamestyle-string-) | Limit username field to accept only "username" values or only "email" values | +| [signUpFieldsStrictValidation](#signUpFieldsStrictValidation-boolean-) | Strict format validation for username and email fields at signup | + +## Enterprise + +| Option | Description | +| --- | --- | +| [defaultEnterpriseConnection](#defaultenterpriseconnection-string-) | Specifies a connection if more than one present | + +## Passwordless + +| Option | Description | +| --- | --- | +| [passwordlessMethod](#passwordlessmethod-string-) | When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user | + +### Other + +| Option | Description | +| --- | --- | +| [configurationBaseUrl](#configurationbaseurl-string-) | Override your application's base URL | +| [languageBaseUrl](#languagebaseurl-string-) | Override your language file base URL | +| [hashCleanup](#hashcleanup-boolean-) | Override the default removal of the hash from the URL | +| [connectionResolver](#connectionresolver-function-) | Optional callback function for choosing a connection based on the username information | + +--- + +## UI Options + +### allowAutocomplete {Boolean} + +Determines whether or not the email or username fields will allow autocomplete (``). Defaults to `false`. + +```js +var options = { + allowAutocomplete: true +}; +``` + +### allowPasswordAutocomplete {Boolean} + +Determines whether or not the password field will allow autocomplete (``). Defaults to `false`. + +Set `allowPasswordAutocomplete` to `true` for password manager support and to avoid other cases of adverse behavior. + +```js +var options = { + allowPasswordAutocomplete: true +}; +``` + +### allowShowPassword {Boolean} + +This option determines whether or not to add a checkbox to the UI which, when selected, will allow the user to show their password when typing it. The option defaults to `false`. + +```js +var options = { + allowShowPassword: true +}; +``` + +Lock with `allowShowPassword` set to `true` and toggled to show the password: + +![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png) + +### allowedConnections {Array} + +Array of connections that will be used for the `signin|signup|reset` actions. Defaults to all enabled connections. + +```js +// The following will only display +// username and password sign in form +var options = { + allowedConnections: ['Username-Password-Authentication'] +}; + +// ... social connections only +var options = { + allowedConnections: ['twitter', 'facebook', 'linkedin'] +}; + +// ... enterprise connections only +var options = { + allowedConnections: ['qraftlabs.com'] +}; +``` + +Examples of `allowedConnections`: + +![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png) + +![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png) + +### autoclose {Boolean} + +Determines whether or not the Lock will be closed automatically after a successful sign in. Defaults to false. + +::: note +If the Lock is not `closable` it won't be closed, even if this option is set to true. +::: + +```js +var options = { + autoclose: true +}; +``` + +### autofocus {Boolean} + +If true, the focus is set to the first field on the widget. Defaults to `false` when being rendered on a mobile device, or if a `container` option is provided; defaults to `true` in all other cases. + +```js +var options = { + autofocus: false +}; +``` + +### avatar {Object} + +By default, Gravatar is used to fetch the user avatar and display name, but you can obtain them from anywhere with the `avatar` option. + +```js +var options = { + avatar: { + url: function(email, cb) { + // Obtain the avatar url for the email input by the user, Lock + // will preload the image before displaying it. + // Note that in case of an error you call cb with the error in + // the first arg instead of `null`. + var url = obtainAvatarUrl(email); + cb(null, url); + }, + displayName: function(email, cb) { + // Obtain the display name for the email input by the user. + // Note that in case of an error you call cb with the error in + // the first arg instead of `null`. + var displayName = obtainDisplayName(email); + cb(null, displayName); + } + } +}; +``` + +Or, if you want to display no avatar at all, simply pass in `null`. + +```js +var options = { + avatar: null +}; +``` + +Default behavior with Gravatar: + +![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-avatar.png) + +### closable {Boolean} + +Determines whether or not the Lock can be closed. When a `container` option is provided its value is always `false`, otherwise it defaults to `true`. + +```js +var options = { + closable: false +}; +``` + +![Lock - Closable](/media/articles/libraries/lock/v11/customization/lock-closable.png) + +### container {String} + +The `id` of the html element where the widget will be shown. + +This makes the widget appear inline within your `div` instead of in a modal pop-out window. + +```html +
+ + +``` + +![Lock - Container](/media/articles/libraries/lock/v11/customization/lock-container.png) + +### flashMessage {Object} + +Shows an `error` or `success` flash message when Lock is shown. This object has the following properties: + +- type {String}: The message type, supported types are `error`, `info`, and `success` +- text {String}: The text to show. + +```js +var options = { + flashMessage: { + type: 'success', + text: 'Welcome!' + } +}; +``` + +### language {String} + +Specifies the language of the widget. Defaults to "en". See the [internationalization directory](https://github.com/auth0/lock/blob/master/src/i18n/) for a current list of provided languages. + +```js +// select a supported language +var options = { + language: 'es' +}; +``` + +![Lock - Language](/media/articles/libraries/lock/v11/customization/lock-language.png) + +### languageDictionary {Object} + +Allows customization of every piece of text displayed in the Lock. Defaults to {}. See English language [Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) for the full list of `languageDictionary` values able to be altered with this object. + +```js +var options = { + languageDictionary: { + emailInputPlaceholder: "something@youremail.com", + title: "Log me in" + }, +}; +``` + +![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png) + +Additionally, check out the [Customizing Error Messages](/libraries/lock/v11/customizing-error-messages) page or the [Internationalization](/libraries/lock/v11/i18n) page for more information about the use of the `languageDictionary` option. + +### popupOptions {Object} + +Allows the customization the location of the popup in the screen. Any position and size feature allowed by window.open is accepted. Defaults to {}. + +Options for the `window.open` [position and size][windowopen-link] features. This only applies if `redirect` is set to `false`. + +```js +var options = { + auth: { + redirect: false + }, + popupOptions: { width: 300, height: 400, left: 200, top: 300 } +}; +``` + +### rememberLastLogin {Boolean} + +Determines whether or not to show a screen that allows you to quickly log in with the account you used the last time. +Requests Single Sign-on (SSO) data and enables a **Last time you signed in with[...]** message. Defaults to `true`. This information comes from the user's Auth0 session, so this ability will last as long as their Auth0 session would (which is [configurable](/dashboard/reference/settings-tenant#login-session-management). + +```js +var options = { + rememberLastLogin: false +}; +``` +::: note +New tenants [automatically have Seamless SSO enabled](https://auth0.com/docs/dashboard/guides/tenants/enable-sso-tenant). With this enabled, the `rememberLastLogin` option will not be relevant because if there is a session in place then the hosted login page will not be displayed at all. Using Seamless SSO is highly recommended because it provides a seamless authentication experience: users log in once and won’t have to enter credentials again when they navigate either through the applications you have built, or third party apps. If the user is not logged in they will be redirected to the login screen, as expected. +::: + +::: note +The **Last time you signed in with [...]** message will not be available under the following circumstances: + +- You used Lock in a [Hosted Login Page](/universal-login) with the session established using [Passwordless authentication](/connections/passwordless). +- You used Lock in an [embedded login scenario](/guides/login/universal-vs-embedded#embedded-login-with-auth0) where `responseType: code` (indicating the [Authorization Code Flow](/flows/concepts/auth-code), which is used for Regular Web Apps). +::: + +### scrollGlobalMessagesIntoView {Boolean} + +Determines whether or not a `globalMessage` should be scrolled into the user's viewport. Defaults to `true`. + +## Theme Options + +Theme options are grouped in the `theme` property of the `options` object. + +```js +var options = { + theme: { + labeledSubmitButton: false, + logo: "https://example.com/assets/logo.png", + primaryColor: "green", + authButtons: { + connectionName: { + displayName: "...", + primaryColor: "...", + foregroundColor: "...", + icon: "https://.../logo.png" + } + } + } +}; +``` + +### authButtons {Object} + +Allows the customization of buttons in Lock with custom OAuth2 connections. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below: + +- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login). +- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`. +- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`. +- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`. + +```js +var options = { + theme: { + authButtons: { + "testConnection": { + displayName: "Test Conn", + primaryColor: "#b7b7b7", + foregroundColor: "#000000", + icon: "http://example.com/icon.png" + }, + "testConnection2": { + primaryColor: "#000000", + foregroundColor: "#ffffff", + } + } + } +}; +``` + +### labeledSubmitButton {Boolean} + +This option indicates whether or not the submit button should have a label, and defaults to `true`. When set to `false`, an icon will be shown instead. + +```js +var options = { + theme: { + labeledSubmitButton: false + } +}; +``` + +![Lock - Labeled Submit Button](/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png) + +If the label is set to true, which is the default, the label's text can be customized through the [languageDictionary](#languagedictionary-object-) option. + +### logo {String} + +The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience. + +```js +var options = { + theme: { + logo: 'https://example.com/logo.png' + } +}; +``` + +![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png) + +### primaryColor {String} + +The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`. + +```js +var options = { + theme: { + logo: 'https://example.com/logo.png', + primaryColor: '#31324F' + } +}; +``` + +![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png) + +## Authentication Options + +Authentication options are grouped in the `auth` property of the `options` object. + +The default scope used by Lock is `openid profile email`. + +```js +var options = { + auth: { + params: { + param1: "value1", + scope: "openid profile email" + }, + autoParseHash: true, + redirect: true, + redirectUrl: "some url", + responseMode: "form_post", + responseType: "token", + sso: true, + connectionScopes: { + connectionName: [ 'scope1', 'scope2' ] + } + } +}; +``` + +### audience {String} + +The `audience` option indicates the API which will be consuming the Access Token that is received after authentication. + +```js +var options = { + auth: { + audience: 'https://${account.namespace}/userinfo', + } +} +``` + +### autoParseHash {Boolean} + +When `autoParseHash` is set to `true`, Lock will parse the `window.location.hash` string when instantiated. If set to `false`, you'll have to manually resume authentication using the [resumeAuth](/libraries/lock/v11/api#resumeauth-) method. + +```js +var options = { + auth: { + autoParseHash: false + } +}; +``` + +### connectionScopes {Object} + +This option allows you to set scopes to be sent to the oauth2/social connection for authentication. + +```js +var options = { + auth: { + connectionScopes: { + 'facebook': ['scope1', 'scope2'] + } + } +}; +``` + +A listing of particular scopes for your social connections can be acquired from the provider in question. For example, [Facebook for Developers](https://developers.facebook.com/docs/facebook-login/permissions/) reference has a listing of separate permissions that can be requested for your connection. + +### params {Object} + +You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `foo` and also adds a `scope` parameter (which includes the scope, and then the requested attributes). [Read here][authparams-link] to learn more about what `authParams` can be set. + +```js +var options = { + auth: { + params: { + state: 'foo', + scope: 'openid email user_metadata app_metadata picture' + } + } +}; +``` + +::: note +For more details about supported parameters check the [Authentication Parameters][authparams-link] documentation page. +::: + +### redirect {Boolean} + +Defaults to true. When set to true, redirect mode will be used. If set to false, [popup mode](/libraries/lock/v11/authentication-modes#popup-mode) is chosen. + +```js +var options = { + auth: { + redirect: false + } +}; +``` + +### redirectUrl {String} + +The URL Auth0 will redirect back to after authentication. Defaults to the empty string "" (no redirect URL). + +```js +var options = { + auth: { + redirectUrl: 'http://testurl.com' + } +}; +``` + +::: note +When the `redirectUrl` is provided (set to non blank value) the `responseType` option will be defaulted to `code` if not manually set. +::: + +### responseMode {String} + +Should be set to `"form_post"` if you want the code or the token to be transmitted via an HTTP POST request to the `redirectUrl`, instead of being included in its query or fragment parts. + +Otherwise, this option should be omitted, and is omitted by default. + +```js +var options = { + auth: { + responseMode: 'form_post' + } +}; +``` + +### responseType {String} + +The value of `responseType` should be set to "token" for Single-Page Applications, and "code" otherwise. Defaults to "code" when redirectUrl is provided, and to "token" otherwise. + +```js +var options = { + auth: { + responseType: 'token' + } +}; +``` + +::: note +When the `responseType` is set to `code`, Lock will never show the **Last time you logged in with** message, and will always prompt the user for credentials. +::: + +## Database Options + +### additionalSignUpFields {Array} + +Extra input fields can be added to the sign up screen with the `additionalSignUpFields` option. Each option added in this manner will then be added to that user's `user_metadata`. See [Metadata](/users/concepts/overview-user-metadata) for more information. Every input must have a `name` and a `placeholder`, and an `icon` URL can also be provided. Also, the initial value can be provided with the `prefill` option, which can be a string with the value or a function that obtains it. Other options depend on the type of the field, which is defined via the type option and defaults to "text". + +::: panel Intended for use with database signup only +`additionalSignUpFields` are intended for use with database signups only. If you have social sign ups too, you can ask for the additional information after the users sign up (see this [page about custom signup](/libraries/custom-signup) for more details). You can use the `databaseAlternativeSignupInstructions` i18n key to display these instructions. +::: + +The new fields are rendered below the regular sign up input fields in the order they are provided. + +#### Text Fields + +Text fields are the default type of additional signup field. Note that a `validator` function can also be provided. + +```js +var options = { + additionalSignUpFields: [{ + name: "address", + placeholder: "enter your address", + // The following properties are optional + icon: "https://example.com/assests/address_icon.png", + prefill: "street 123", + validator: function(address) { + return { + valid: address.length >= 10, + hint: "Must have 10 or more chars" // optional + }; + } + }, + { + name: "full_name", + placeholder: "Enter your full name" + }] +} +``` + +If you don't specify a `validator` the text field will be **required**. If you want to make the text field optional, use a validator that always returns `true` like this: + +```js +var options = { + additionalSignUpFields: [{ + name: "favorite_color", + placeholder: "Enter your favorite color (optional)", + validator: function() { + return true; + } + }] +} +``` + +If you want to save the value of the attribute in the root of your profile, use `storage: 'root'`. Only a subset of values can be stored this way. The list of attributes that can be added to your root profile is [here](/api/management/v2#!/Users/patch_users_by_id). By default, every additional sign up field is stored inside the user_metadata object. + +```js +var options = { + additionalSignUpFields: [{ + name: "name", + storage: "root" + }] +}; +``` + +![Lock - Additional Signup Fields](/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png) + +#### Select Field + +The signup field `type: "select"` will allow you to use select elements for the user to choose a value from. + +```js +var options = { + additionalSignUpFields: [{ + type: "select", + name: "location", + placeholder: "choose your location", + options: [ + {value: "us", label: "United States"}, + {value: "fr", label: "France"}, + {value: "ar", label: "Argentina"} + ], + // The following properties are optional + icon: "https://example.com/assests/location_icon.png", + prefill: "us" + }] +} +``` + +The `options` array items for `select` fields must adhere to the following format: +`{label: “non empty string”, value: “non empty string”}`, and at least one option must be defined. + +The `options` and `prefill` values can be provided through a function: + +```js +var options = { + additionalSignUpFields: [{ + type: "select", + name: "location", + placeholder: "choose your location", + options: function(cb) { + // obtain options, in case of error you call cb with the error in the + // first arg instead of null + cb(null, options); + }, + icon: "https://example.com/assests/location_icon.png", + prefill: function(cb) { + // obtain prefill, in case of error you call cb with the error in the + // first arg instead of null + cb(null, prefill); + } + }] +} +``` + +#### Checkbox Field + +The third type of custom signup field is the `type: "checkbox"`. The `prefill` value can determine the default state of the checkbox (`true` or `false`), and it is required. + +```js +var options = { + additionalSignUpFields: [{ + type: "checkbox", + name: "newsletter", + prefill: "true", + placeholder: "I hereby agree that I want to receive marketing emails from your company" + }] +} +``` + +#### Hidden field + +The signup field `type: "hidden"` will allow you to use a hidden input with a fixed value. + +```js +var options = { + additionalSignUpFields: [{ + type: "hidden", + name: "signup_code", + value: "abc123" + }] +} +``` + +::: note +Some use cases may be able to use `additionalSignUpFields` data for email templates, such as an option for language preferences, the value of which could then be used to set the language of templated email communications. +::: + +### allowLogin {Boolean} + +When set to `false` the widget won't display the login screen. This is useful if you want to use the widget just for signups (the login and signup tabs in the signup screen will be hidden) or to reset passwords (the back button in the forgot password screen will be hidden). In such cases you may also need to specify the `initialScreen`, `allowForgotPassword` and `allowSignUp` options. It defaults to `true`. + +```js +// +var options = { + allowLogin: false +}; +``` + +![Lock - Allow Login](/media/articles/libraries/lock/v11/customization/lock-allowlogin.png) + +### allowForgotPassword {Boolean} + +When set to false, `allowForgotPassword` hides the "Don't remember your password?" link in the Login screen, making the Forgot Password screen unreachable. Defaults to true. + +::: note +Keep in mind that if you are using a database connection with a custom database which doesn't have a change password script the Forgot Password screen won't be available. +::: + +```js +// +var options = { + allowForgotPassword: false +}; +``` + +![Lock - Allow Forgot Password](/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png) + +### allowSignUp {Boolean} + +When set to `false`, hides the login and sign up tabs in the login screen, making the sign up screen unreachable. Defaults to `true`. Keep in mind that if the database connection has sign ups disabled or you are using a custom database which doesn't have a create script, then the sign up screen won't be available. + +Also bear in mind that this option **only** controls client-side appearance, and does not completely stop new sign ups from determined anonymous visitors. If you are looking to fully prevent new users from signing up, you must use the **Disable Sign Ups** option in the dashboard, in the connection settings. + +```js +var options = { + allowSignUp: false +}; +``` + +![Lock - Social Button Style](/media/articles/libraries/lock/v11/customization/lock-allowsignup.png) + +### defaultDatabaseConnection {String} + +Specifies the database connection that will be used when there is more than one available. + +```js +var options = { + defaultDatabaseConnection: 'test-database' +}; +``` + +### initialScreen {String} + +The name of the screen that will be shown when the widget is opened. Valid values are `login`, `signUp`, and `forgotPassword`. If this option is left unspecified, the widget will default to the first screen that is available from that list. + +```js +var options = { + initialScreen: 'forgotPassword' +}; +``` + +### loginAfterSignUp {Boolean} + +Determines whether or not the user will be automatically signed in after a successful sign up. Defaults to `true`. + +```js +var options = { + loginAfterSignUp: false +}; +``` + +### forgotPasswordLink {String} + +Set the URL for a page that allows the user to reset their password. When set to a non-empty string, the user will be sent to the provided URL when clicking the "Don't remember your password?" link in the login screen. + +```js +var options = { + forgotPasswordLink: 'https://yoursite.com/reset-password' +}; +``` + +### showTerms {Boolean} + +When set to `true` displays the `languageDictionary.signUpTerms` string. Defaults to `true`. + +### mustAcceptTerms {Boolean} + +When set to `true` displays a checkbox input alongside the terms and conditions that must be checked before signing up. The terms and conditions can be specified via the `languageDictionary` option. This option will only take effect for users signing up with database connections. Defaults to `false`. + +```js +var options = { + mustAcceptTerms: true +}; +``` + +### prefill {Object} + +Allows to set the initial value for the email and/or username inputs. When omitted, no initial value will be provided. + +```js +var options = { + prefill: { + email: "someone@auth0.com", + username: "someone", + phoneNumber: "+1234567890" + } +}; +``` + +### signUpLink {String} + +Set the URL to be requested when clicking on the Signup button. + +::: panel Side effects +When set to a non empty string, this option forces `allowSignUp` to `true`. +::: + +```js +var options = { + signUpLink: 'https://yoursite.com/signup' +}; +``` + +### usernameStyle {String} + +Determines what will be used to identify the user for a Database connection that has the `requires_username` flag set (if it is not set, `usernameStyle` option will be ignored). Possible values are `"username"` and `"email"`. By default both `username` and `email` are allowed; setting this option will limit logins to use one or the other. + +```js +var options = { + // Limits logins to usernames only, not emails + usernameStyle: 'username' +}; +``` + +### signUpFieldsStrictValidation {Boolean} + +This option enables strict format validation for username and email fields at the signup screen. This ensures presenting validation errors instead of the generic "We're sorry, something went wrong when attempting to sign up." message. Defaults to `false`. + +```js +var options = { + signUpFieldsStrictValidation: true +}; +``` + +## Enterprise Options + +### defaultEnterpriseConnection {String} + +Specifies the enterprise connection which allows to login using a username and a password that will be used when there is more than one available or there is a database connection. If a `defaultDatabaseConnection` is provided the database connection will be used and this option will be ignored. + +```js +var options = { + defaultEnterpriseConnection: 'test-database' +}; +``` + +### defaultADUsernameFromEmailPrefix {Boolean} + +Resolve the AD placeholder username from the email's prefix. Defaults to `true`. + +```js +var options = { + defaultADUsernameFromEmailPrefix: false +}; +``` + +## Passwordless Options + +### passwordlessMethod {String} + +When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user. Available values for email connections are `code` and `link`. Defaults to `code`. SMS passwordless connections will always use `code`. + +## Other Options + +### configurationBaseUrl {String} + +This option can provide a URL to override the application settings base URL. By default, it uses Auth0's CDN URL when the domain has the format `*.auth0.com`. For example, if your URL is `contoso.eu.auth0.com`, then by default, the `clientBaseUrl` is `cdn.eu.auth0.com`. If the `clientBaseUrl` option is set to something else instead, it uses the provided domain. This would only be necessary if your specific use case dictates that your application not use the default behavior. + +```js +var options = { + clientBaseUrl: "https://www.example.com" +}; +``` + +### languageBaseUrl {String} + +Overrides the language source url for Auth0's provided translations. By default, this option uses Auth0's CDN URL `https://cdn.auth0.com` since this is where all of the provided translations are stored. By providing another value, you can use another source for the language translations if needed. + +```js +var options = { + languageBaseUrl: "https://www.example.com" +}; +``` + +### hashCleanup {Boolean} + +When the `hashCleanup` option is enabled, it will remove the hash part of the callback URL after the user authentication. It defaults to true. + +```js +var options = { + hashCleanup: false +}; +``` + +### connectionResolver {Function} + +When in use, provides an extensibility point to make it possible to choose which connection to use based on the username information. + +Has `username`, `context`, and `callback` as parameters. The callback expects an object like: `{type: 'database', name: 'connection name'}`. **This only works for database connections.** Keep in mind that this resolver will run in the form's `onSubmit` event, so keep it simple and fast. + +This is a beta feature. If you find a bug, please open a GitHub [issue](https://github.com/auth0/lock/issues/new). + +### leeway {Integer} + +The `leeway` option can be set to an integer - a value in seconds - which can be used to account for clock skew in ID Token expirations. Typically the value is no more than a minute or two at maximum. + +```js +var options = { + leeway: 30 +}; +``` + + + +[authparams-link]: /libraries/lock/v11/sending-authentication-parameters +[windowopen-link]: https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Position_and_size_features diff --git a/fr-ca/articles/libraries/lock/v11/customizing-error-messages.md b/fr-ca/articles/libraries/lock/v11/customizing-error-messages.md new file mode 100644 index 0000000000..1d06250ce5 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/customizing-error-messages.md @@ -0,0 +1,50 @@ +--- +section: libraries +description: Customizing error messages with Lock v11 +topics: + - libraries + - lock + - error-messages +contentType: + - how-to + - reference +useCase: + - add-login +--- +# Customizing Lock Error Messages + +You can customize the error messages that will be displayed in certain situations by providing a [languageDictionary option](/libraries/lock/v11/configuration#languagedictionary-object-). A full listing of available `languageDictionary` fields to customize can be found in the GitHub repository's [English Dictionary file for Lock v11](https://github.com/auth0/lock/blob/master/src/i18n/en.js). Below is an example of some customized error messages: + +```js +// Examples of customized error messages in the languageDictionary option +var options = { + languageDictionary: { + error: { + login: { + "lock.invalid_email_password": "Custom message about invalid credentials", + "lock.network": "Custom message indicating a network error and suggesting the user check connection", + "lock.unauthorized": "Custom message about a failure of permissions", + "too_many_attempts": "Custom message indicating the user has failed to login too many times." + }, + signUp: { + "invalid_password": "Custom message indicating a password was invalid", + "user_exists": "Custom message indicating that a user already exists" + } + } + } +}; + +// Initiating our Auth0Lock +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}', + options +); +``` + +## Custom errors in Rules + +If you are returning custom error codes from a [rule](/rules) or a [custom database script](/connections/database/custom-db#error-handling), you can handle custom errors: + +* In your application's redirect URL by reading the `error` and `error_mesage` query string parameters. +* By redirecting the user back to your hosted pages with a custom error message and displaying the message with a [flash message](/libraries/lock/v11/api#flashmessage). diff --git a/fr-ca/articles/libraries/lock/v11/i18n.md b/fr-ca/articles/libraries/lock/v11/i18n.md new file mode 100644 index 0000000000..cdd35c7c3e --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/i18n.md @@ -0,0 +1,116 @@ +--- +section: libraries +description: Lock v11 supports multiple languages, and allows for the addition of other custom language files, as well as for customizing the values of specific pieces of text that are displayed in the Lock widget. +topics: + - libraries + - lock + - i18n +contentType: + - how-to + - concept +useCase: + - add-login +--- +# Lock Internationalization + +You can change the language of Lock by using the `language` configuration option. This will pull the corresponding language file from the `i18n` directory in Lock. + +## Provided languages + +Take a look at the [i18n directory](https://github.com/auth0/lock/blob/master/src/i18n/) for language files. + +| Language | Code | Source | +|----------|------|--------| +| Afrikaans | `'af'` | [af.js](https://github.com/auth0/lock/blob/master/src/i18n/af.js) | +| Catalan | `'ca'` | [ca.js](https://github.com/auth0/lock/blob/master/src/i18n/ca.js) | +| Chinese | `'zh'` | [zh.js](https://github.com/auth0/lock/blob/master/src/i18n/zh.js) | +| Chinese (Taiwan) | `'zh-tw'` | [zh-tw.js](https://github.com/auth0/lock/blob/master/src/i18n/zh-tw.js) | +| Croatian | `'hr'` | [hr.js](https://github.com/auth0/lock/blob/master/src/i18n/hr.js) | +| Czech | `'cs'` | [cs.js](https://github.com/auth0/lock/blob/master/src/i18n/cs.js) | +| Danish | `'da'` | [da.js](https://github.com/auth0/lock/blob/master/src/i18n/da.js) | +| Dutch | `'nl'` | [nl.js](https://github.com/auth0/lock/blob/master/src/i18n/nl.js) | +| English | `'en'` | [en.js](https://github.com/auth0/lock/blob/master/src/i18n/en.js) | +| Estonian | `'et'` | [et.js](https://github.com/auth0/lock/blob/master/src/i18n/et.js) | +| Farsi (Persian) | `'fa'` | [fa.js](https://github.com/auth0/lock/blob/master/src/i18n/fa.js) | +| Finnish | `'fi'` | [fi.js](https://github.com/auth0/lock/blob/master/src/i18n/fi.js) | +| French | `'fr'` | [fr.js](https://github.com/auth0/lock/blob/master/src/i18n/fr.js) | +| German | `'de'` | [de.js](https://github.com/auth0/lock/blob/master/src/i18n/de.js) | +| Greek | `'el` | [el.js](https://github.com/auth0/lock/blob/master/src/i18n/el.js) | +| Hebrew | `'he'` | [he.js](https://github.com/auth0/lock/blob/master/src/i18n/he.js) | +| Hungarian | `'hu'` | [hu.js](https://github.com/auth0/lock/blob/master/src/i18n/hu.js) | +| Italian | `'it'` | [it.js](https://github.com/auth0/lock/blob/master/src/i18n/it.js) | +| Japanese | `'ja'` | [ja.js](https://github.com/auth0/lock/blob/master/src/i18n/ja.js) | +| Korean | `'ko'` | [ko.js](https://github.com/auth0/lock/blob/master/src/i18n/ko.js) | +| Lithuanian | `'lt'` | [lt.js](https://github.com/auth0/lock/blob/master/src/i18n/lt.js) | +| Norwegian | `'no'` | [no.js](https://github.com/auth0/lock/blob/master/src/i18n/no.js) | +| Norwegian (Bokmål) | `'nb'` | [nb.js](https://github.com/auth0/lock/blob/master/src/i18n/nb.js) | +| Norwegian (Nynorsk) | `'nn'` | [nn.js](https://github.com/auth0/lock/blob/master/src/i18n/nn.js) | +| Polish | `'pl'` | [pl.js](https://github.com/auth0/lock/blob/master/src/i18n/pl.js) | +| Portuguese (Brazil) | `'pt-br'` | [pt-br.js](https://github.com/auth0/lock/blob/master/src/i18n/pt-br.js) | +| Romanian | `'ro'` | [ro.js](https://github.com/auth0/lock/blob/master/src/i18n/ro.js) | +| Russian | `'ru'` | [ru.js](https://github.com/auth0/lock/blob/master/src/i18n/ru.js) | +| Slovak | `'sk'` | [sk.js](https://github.com/auth0/lock/blob/master/src/i18n/sk.js) | +| Slovenian | `'sl'` | [sl.js](https://github.com/auth0/lock/blob/master/src/i18n/sl.js) | +| Spanish | `'es'` | [es.js](https://github.com/auth0/lock/blob/master/src/i18n/es.js) | +| Swedish | `'sv'` | [sv.js](https://github.com/auth0/lock/blob/master/src/i18n/sv.js) | +| Turkish | `'tr'` | [tr.js](https://github.com/auth0/lock/blob/master/src/i18n/tr.js) | +| Ukrainian | `'ua'` | [ua.js](https://github.com/auth0/lock/blob/master/src/i18n/uk.js) | +| Vietnamese | `'vi'` | [vi.js](https://github.com/auth0/lock/blob/master/src/i18n/vi.js) | + +## Set language option + +To use the following examples, you'll need to first include Lock in your page: + +```html + + +``` + +Next define your `options` object and include the `language` option. The `language` option needs to be a string matching the name of the corresponding file in the `i18n` directory [within Lock](https://github.com/auth0/lock/tree/master/src/i18n). Then instantiate Lock. + +For example, + +```js +// Select a supported language +var options = { + language: 'es' +}; + +// Initiating our Auth0Lock +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}', + options +); +``` + +::: panel Missing translation values +Translation data for Lock comes from language files which have key-value pairs representing various translations. For some languages, certain values may be missing, in which case you will see a warning: `language does not have property `. We encourage you to submit a [pull request](https://github.com/auth0/lock/tree/master/src/i18n) to add these missing values. Alternatively, you may define the missing values in your Lock `options` (see below). +::: + +## Replace dictionary terms + +You can also customize your own specific dictionary items using the `languageDictionary` option. This is useful if you are using one of the supported languages, but change the specific wording of a few items. For example, you might re-word the `title` or change the way other labels display to the user while leaving the remaining text on the widget intact. + +```js +// Customize some languageDictionary attributes +var options = { + languageDictionary: { + emailInputPlaceholder: "something@youremail.com", + title: "Log me in" + }, +}; + +// Initiating our Auth0Lock +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}', + options +); +``` + +::: note +For an example of available `languageDictionary` property names and how to structure a `language` file, see the [English dictionary file for Lock](https://github.com/auth0/lock/blob/master/src/i18n/en.js). +::: + +The `languageBaseUrl` option, which takes a string value (a URL), overrides the language source URL for Auth0's provided translations. By default, it uses the Auth0's CDN URL `https://cdn.auth0.com` because that is where the provided language translations are stored. By providing another value, you can use your own source for the language translations as needed for your applications. Your language source should be a JavaScript file. diff --git a/fr-ca/articles/libraries/lock/v11/index.md b/fr-ca/articles/libraries/lock/v11/index.md new file mode 100644 index 0000000000..babcef08a8 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/index.md @@ -0,0 +1,250 @@ +--- +section: libraries +toc: true +title: Lock v11 for Web +description: A widget that provides a frictionless login and signup experience for your web apps. +img: media/articles/libraries/lock-web.png +topics: + - libraries + - lock +contentType: + - how-to + - index +useCase: + - add-login +--- +# Lock v11 for Web + +Lock is an embeddable login form that can be [configured to your needs](/libraries/lock/v11/configuration) and is recommended for use in single-page apps, preferably in conjunction with [Universal Login](/universal-login), which should be used whenever possible. Lock enables you to easily add social identity providers, so that your users can log in seamlessly using any desired provider. + +<%= include('../../../_includes/_embedded_login_warning') %> + +## Lock Installation + +You can install Lock v11 via several methods. Select any of the following installation sources that best suit your environment and application. + +### Installation Sources + +Install via [npm](https://npmjs.org): + +```sh +npm install auth0-lock +``` + +Install via [bower](http://bower.io): + +```sh +bower install auth0-lock +``` + +Include via our CDN (Replace `.x` and `.y` with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock/releases): + +```html + + + + + +``` + +::: panel Updating patch versions +It is recommended that production applications use a specific patch version, or at the very least a specific minor version. Regardless of the method by which Lock is included, the recommendation is that the version should be locked down and only manually updated, to ensure that those updates do not adversely affect your implementation. Check the [GitHub repository](https://github.com/auth0/lock/releases) for a current list of releases. +::: + +### Mobile + +If you are targeting mobile audiences, Auth0 recommends that you add the following meta tag to your application's `head`: + +```html + +``` + +### Bundling Dependencies + +If you are using browserify or webpack to build your project and bundle its dependencies, after installing the `auth0-lock` module, you will need to bundle it with all its dependencies. Examples are available for [Browserify](https://github.com/auth0/lock/tree/master/examples/bundling/browserify) and [webpack](https://github.com/auth0/lock/tree/master/examples/bundling/webpack). + +### Cross-Origin Authentication + +<%= include('../../../_includes/_embedded_login_warning') %> + +Embedding Lock within your application requires [cross-origin authentication](/cross-origin-authentication) to be properly configured. Specifically, you need to set the **Allowed Web Origins** property to the domain making the request. You can find this field in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). + +![Allowed Web Origins](/media/articles/libraries/lock/allowed-origins.png) + +Make sure you read about the [limitations of cross-origin authentication](/cross-origin-authentication#limitations) before implementing Lock. + +## Usage + +### 1. Initializing Lock + +First, you'll need to initialize a new `Auth0Lock` object, and provide it with your Auth0 client ID (the unique client ID for each Auth0 application, which you can get from the [management dashboard](${manage_url})) and your Auth0 domain (for example, `yourname.auth0.com`). + +```js +// Initializing our Auth0Lock +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}' +); +``` + +### 2. Authenticating and Getting User Info + +Next, listen using the `on` method for the `authenticated` event. When the event occurs, use the `accessToken` which was received to call the `getUserInfo` method and acquire the user's profile information (as needed). + +```js +var Auth = (function() { + + var wm = new WeakMap(); + var privateStore = {}; + var lock; + + function Auth() { + this.lock = new Auth0Lock( + '', + '' + ); + wm.set(privateStore, { + appName: "example" + }); + } + + Auth.prototype.getProfile = function() { + return wm.get(privateStore).profile; + }; + + Auth.prototype.authn = function() { + // Listening for the authenticated event + this.lock.on("authenticated", function(authResult) { + // Use the token in authResult to getUserInfo() and save it if necessary + this.getUserInfo(authResult.accessToken, function(error, profile) { + if (error) { + // Handle error + return; + } + + //we recommend not storing Access Tokens unless absolutely necessary + wm.set(privateStore, { + accessToken: authResult.accessToken + }); + + wm.set(privateStore, { + profile: profile + }); + + }); + }); + }; + return Auth; +}()); + +``` + +You can then manipulate page content and display profile information to the user (for example, displaying their name in a welcome message). + +```html +

Welcome

+``` + +::: note +Note that if you are storing the user profile, you will want to `JSON.stringify` the profile object and then, when using it later, `JSON.parse` it, because it will need to be stored in `localStorage` as a string rather than a JSON object. +::: + +### 3. Showing Lock + +Here you're showing the Lock widget after the user clicks a login button; you can just as easily show Lock automatically when arriving at a page by just using `lock.show();` on page load. + +This will show the Lock widget, and paired with the above, you're now ready to handle logins! + +```js +document.getElementById('btn-login').addEventListener('click', function() { + lock.show(); +}); +``` + +## Passwordless + +::: note +Lock's Passwordless Mode is only available in Lock v11.2.0 and later. Please use the [latest release of Lock](https://github.com/auth0/lock/releases) for this feature! +::: + +You can use Lock's Passwordless Mode to allow users to authenticate using just an email or mobile number. They will receive the code and then return to input it, or click the link, and they can be authenticated without remembering a password. + +In Lock v11, in order to implement Passwordless Mode, you initialize Lock in a slightly different manner, with `Auth0LockPasswordless` rather than with `Auth0Lock`: + +```js +var lockPasswordless = new Auth0LockPasswordless( + '${account.clientId}', + '${account.namespace}' +); +``` + +### Passwordless options + +Additionally, Lock's Passwordless Mode has a couple of configuration options that are unique to it. + +In order to indicate which connection type you would like, you initialize Lock with the `allowedConnections` option with either `email` or `sms` as the value: + +```js +var passwordlessOptions = { + allowedConnections: ['sms'] +} +``` + +::: note +Remember to enable the passwordless connection of your choice in the [Dashboard](${manage_url}) under **Connections -> Passwordless**, and then to enable it for your application, that way when Lock tries to use it, it is already set up and linked to the application. +::: + +If you choose to use `email`, you have one more option to select - whether you wish your users to receive a code to input, or a "magic link" to use. This is done via the `passwordlessMethod` option, which takes values of `code` or `link`. + +```js +var passwordlessOptions = { + allowedConnections: ['email'], + passwordlessMethod: 'code' +} +``` + +### Passwordless example + +```js +var passwordlessOptions = { + allowedConnections: ['email'], + passwordlessMethod: 'code', + auth: { + redirectUrl: 'http://localhost:3000/callback', + responseType: 'token id_token', + params: { + scope: 'openid email' + } + } +} + +var lockPasswordless = new Auth0LockPasswordless( + '${account.clientId}', + '${account.namespace}', + passwordlessOptions +); +``` + +<%= include('../../_includes/_embedded_sso') %> + +<%= include('../../../_includes/_co_authenticate_errors', { library : 'Lock v11'}) %> + +## Browser Compatibility + +Browser compatibility is ensured for **Chrome**, **Safari**, **Firefox** and **IE >= 10**. Auth0 currently uses [zuul](https://github.com/defunctzombie/zuul) along with [Saucelabs](https://saucelabs.com) to run integration tests on each push. + +## More Examples + +The below widget displays brief examples of implementing Auth0 in several ways: Lock as a modal "popup" widget, Lock embedded inline in a div, Lock Passwordless, a custom UI with [Auth0.js](/libraries/auth0js), and a simple link using the API. + +<%= include('../../../_includes/_lock-sdk') %> + +## Next Steps + +This document has shown how to use Lock 11 within a Single-Page Application (SPA). Take a look at the following resources to see how Lock can be used with other kinds of web apps, or how it can be customized for your needs: + +::: next-steps +* [Lock v11 API Reference](/libraries/lock/v11/api) +* [Lock Configuration Options](/libraries/lock/v11/configuration) +* [Lock UI Customization](/libraries/lock/v11/ui-customization) +::: diff --git a/fr-ca/articles/libraries/lock/v11/migration-angular.md b/fr-ca/articles/libraries/lock/v11/migration-angular.md new file mode 100644 index 0000000000..1eb1e5647d --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-angular.md @@ -0,0 +1,21 @@ +--- +section: libraries +title: Migrating Angular applications to Lock v11 +description: How to migrate Angular applications to Lock v11 +public: false +topics: + - libraries + - lock + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular Applications to Lock v11 + +Angular applications can use Lock directly without any kind of wrapper library. + +All Angular applications will be using Lock 10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide. diff --git a/fr-ca/articles/libraries/lock/v11/migration-angularjs-v10.md b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v10.md new file mode 100644 index 0000000000..621be6bea3 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v10.md @@ -0,0 +1,53 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications to from Lock v10 to Lock v11 +description: How to migrate Angular 1.x Applications from Lock v10 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x applications from Lock v10 to v11 + +## Migration steps + +<%= include('../../_includes/_get_lock_latest_version') %> + +### Update angular-lock + +AngularJS (a.k.a. Angular 1.x) applications usually use the [angular-lock package](https://www.npmjs.com/package/angular-lock). To use Lock v11 you need to update to the latest version (3.x). + +You can update the angular-lock library using npm or yarn. + +```bash +# installation with npm +npm install --save angular-lock + +# installation with yarn +yarn add angular-lock +``` + +The script files need to be added to your build system, or added to the project with a script tag. + +```html + +``` + +<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %> +<%= include('../../_includes/_change_get_profile') %> +<%= include('../../_includes/_oidc_conformant') %> + +## Behavioral Changes in Lock v11 + +<%= include('../../_includes/_popup_mode') %> +<%= include('../../_includes/_last_logged_in_window') %> +<%= include('../../_includes/_ip_ranges') %> +<%= include('../../_includes/_default_values_lock') %> diff --git a/fr-ca/articles/libraries/lock/v11/migration-angularjs-v8.md b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v8.md new file mode 100644 index 0000000000..8152ec0ef0 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v8.md @@ -0,0 +1,22 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications to from Lock v8 to Lock v11 +description: How to migrate Angular 1.x Applications from Lock v8 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x Applications from Lock v8 to v11 + +Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint. + +You can follow the instructions on [how to migrate Angular 1.x applications from Lock v9 to v11]((/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock 8. diff --git a/fr-ca/articles/libraries/lock/v11/migration-angularjs-v9.md b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v9.md new file mode 100644 index 0000000000..6217541cf6 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-angularjs-v9.md @@ -0,0 +1,207 @@ +--- +section: libraries +title: Migrating Angular 1.x Applications to from Lock v9 to Lock v11 +description: How to migrate Angular 1.x Applications from Lock v9 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations + - angular +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating Angular 1.x Applications from Lock v9 to v11 + +This guide will help you migrating your Angular 1.x application from Lock 9 to Lock v11. + +<%= include('../../_includes/_get_lock_latest_version') %> + +## Add the angular-lock library + +Most Angular 1.x apps used the [auth0-angular](https://www.npmjs.com/package/auth0-angular) which is currently deprecated. This guide will use [auth0-lock](https://www.npmjs.com/package/auth0-lock) 3.0 to simplify using Lock v11. + +Use npm to uninstall the old library and install the new one. + +``` +npm uninstall auth0-angular --save +npm install angular-lock --save +``` + +Then include it in your `index.html` file: + +```html + + +``` + +## Update the app.js file + +In your `app.js` file: + +* Add `auth0.lock` to your Angular module +* Inject `lockProvider` in your configuration +* Initialize a Lock instance in `config()` +* Inject your authentication service in `run()` and call the method that listens for authentication events (we will implement changes in the authentication service next) + +```js +// app.js +(function() { + 'use strict'; + + angular + .module('app', ['ngRoute', +// 'auth0' + 'auth0.lock']) // Add auth0.lock + .config(config) + .run(run); + + config.$inject = [ + '$locationProvider', + '$routeProvider', + // 'authProvider', + 'lockProvider' // Inject lockProvider + ]; + + function config( + $locationProvider, + $routeProvider, +// authProvider + lockProvider // Provide lockProvider + ) { + $routeProvider + .when('/', { + controller: 'HomeController', + templateUrl: 'app/home/home.html', + controllerAs: 'vm' + }) + .otherwise({ + redirectTo: '/' + }); + + $locationProvider.hashPrefix(''); + $locationProvider.html5Mode(true); + + // Configure Auth0 Lock instance + // Read more about configuration here: + // https://auth0.com/docs/libraries/lock/v11 + lockProvider.init({ + domain: '${account.namespace}'), + clientID: '${account.clientId}', + options: { + autoclose: true, + auth: { + responseType: 'token id_token', + audience: 'https://' + '${account.namespace}' + '/userinfo', + params: { + scope: 'openid profile email' + } + } + } + }); + } + + // Inject authentication service and + // run method to handle authentication + run.$inject = ['authService']; + + function run(authService) { + authService.handleAuthentication(); + } + +}()); +``` + +## Update the authentication service + +If you are using an authentication service, you will need to make a few minor changes there as well. Lock v11 provides events so you can execute functionality when the user is authenticated, when there is an authentication error, and so on. You can read more at the [Lock v11 documentation](/libraries/lock/v11). + +```js +// auth.service.js +(function() { + 'use strict'; + + angular.module('app').service('authService', authService); + + // Inject 'lock' + authService.$inject = ['lock', '$location']; + + function authService(lock, $location) { + + function login() { + // Display the Lock widget using the + // instance initialized in the app.js config + lock.show(); + } + + function logout() { + // Remove tokens and expiry time from localStorage + localStorage.removeItem('access_token'); + localStorage.removeItem('id_token'); + localStorage.removeItem('expires_at'); + $location.path('/'); + } + + function handleAuthentication() { + // Uncomment if you are not using HTML5Mode + // lock.interceptHash(); + + lock.on('authenticated', function(authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + console.log('Authenticated!', authResult); + _setSession(authResult); + } + }); + lock.on('authorization_error', function(err) { + console.log(err); + alert( + 'Error: ' + err.error + '. Check the console for further details.' + ); + }); + } + + function _setSession(authResult) { + // Set the time that the Access Token will expire + var expiresAt = JSON.stringify( + authResult.expiresIn * 1000 + new Date().getTime() + ); + // Save tokens and expiration to localStorage + localStorage.setItem('access_token', authResult.accessToken); + localStorage.setItem('id_token', authResult.idToken); + localStorage.setItem('expires_at', expiresAt); + } + + function isAuthenticated() { + // Check whether the current time is + // past the Access Token's expiry time + var expiresAt = JSON.parse(localStorage.getItem('expires_at')); + return new Date().getTime() < expiresAt; + } + + return { + login: login, + logout: logout, + handleAuthentication: handleAuthentication, + isAuthenticated: isAuthenticated + }; + } +})(); +``` + +::: note +If you are not using a service, you can implement the `handleAuthentication()` method's functionality in your app's `run()` method, and implement the `login()`, `logout()`, and `_setSession()` functionality in the controller where your login is located. +::: + +<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %> +<%= include('../../_includes/_change_get_profile') %> + +## Behavioral Changes in Lock v11 + +<%= include('../../_includes/_popup_mode') %> +<%= include('../../_includes/_last_logged_in_window') %> +<%= include('../../_includes/_ip_ranges') %> +<%= include('../../_includes/_default_values_lock') %> diff --git a/fr-ca/articles/libraries/lock/v11/migration-cordova.md b/fr-ca/articles/libraries/lock/v11/migration-cordova.md new file mode 100644 index 0000000000..ce7a0e9ef2 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-cordova.md @@ -0,0 +1,21 @@ +--- +title: Migration from Lock 10 in Cordova Apps +description: Learn how to migrate from Lock 10 in your Cordova app. +public: false +topics: + - libraries + - lock + - migrations + - cordova +contentType: + - how-to +useCase: + - add-login + - migrate +--- + +# Migration from Lock in Cordova Applications + +For Cordova applications, the only migration path forward at this time is to [migrate to Universal Login](/guides/login/migration-embedded-universal). Embedded Lock will not be supported in Cordova apps going forward, as part of an effort to align Auth0's Cordova support with more stringent standards and security policies. + +Instead of updating embedded Lock versions, Cordova apps using Auth0 should instead use the [auth0-cordova](https://github.com/auth0/auth0-cordova) library to initiate Universal Login in Cordova apps. See the [Cordova Quickstart](/quickstart/native/cordova/01-login) for an example of setting this up. diff --git a/fr-ca/articles/libraries/lock/v11/migration-guide.md b/fr-ca/articles/libraries/lock/v11/migration-guide.md new file mode 100644 index 0000000000..a815c11a66 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-guide.md @@ -0,0 +1,68 @@ +--- +section: libraries +title: Migrating to Lock v11 +description: How to migrate to Lock v11 +public: false +topics: + - libraries + - lock + - migrations +contentType: + - how-to + - reference + - concept +useCase: + - add-login + - migrate +--- +# Migrating to Lock v11 + +[Lock v11](/libraries/lock) operates with enhanced security and removes dependencies that have been deprecated as per Auth0's roadmap. In some cases, these security enhancements may impact application behavior when upgrading from an earlier version of Lock. + +## Should I migrate to v11? + +Everyone should migrate to v11. All previous versions are deprecated, and the Legacy Lock API was removed from service on August 6, 2018. For applications that use Lock within an Auth0 login page, this migration is recommended; for applications with Lock embedded within them, this migration is mandatory. + +## Migration instructions + +The documents below describe all the changes that you should be aware of when migrating from different versions of Lock. Make sure you go through the relevant guide(s) before upgrading. + +* [Migrating from the lock-passwordless widget](/libraries/lock/v11/migration-lock-passwordless) +* [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) +* [Recommendations for migrating from Lock v10 when Single Sign-on (SSO) is required](/guides/login/migration-sso) +* [Migrating from Lock v10 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v10) +* [Migrating from Lock v10 in Angular 2+ Applications](/libraries/lock/v11/migration-angular) +* [Migrating from Lock v10 in React Applications](/libraries/lock/v11/migration-react) +* [Migrating from Lock v10 in Cordova Applications](/libraries/lock/v11/migration-cordova) +* [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11) +* [Migrating from Lock v9 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v9) +* [Migrating from Lock v8](/libraries/lock/v11/migration-v8-v11) +* [Migrating from Lock v8 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v8) + +If you have any questions or concerns, you can discuss them in the [Auth0 Community](https://community.auth0.com/), submit them using the [Support Center](${env.DOMAIN_URL_SUPPORT}), or directly through your account representative, if applicable. + +<%= include('../../../_includes/_embedded_login_warning') %> + +## Troubleshooting + +### Lock takes too long to display the login options + +If Lock takes a lot of time to display the login options, it could be because the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property is not correctly set. + +To verify that this is a problem check your logs at [Dashboard > Logs](${manage_url}/#/logs). If you see an entry with the following error description, set the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property and try again. + +```text +The specified redirect_uri 'https://YOUR_APP_URL' does not have a registered domain. +``` + +### I upgraded but I still get deprecation warnings in the logs + +You have already migrated to Lock 11 but you still see this error in your logs: + +```text +Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application. +``` + +These deprecation notices most likely originate from a user visiting the Universal Login [page](/universal-login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. After August 6, 2018, these users will not be able to log in. + +See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors. diff --git a/fr-ca/articles/libraries/lock/v11/migration-lock-passwordless.md b/fr-ca/articles/libraries/lock/v11/migration-lock-passwordless.md new file mode 100644 index 0000000000..3108edcae5 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-lock-passwordless.md @@ -0,0 +1,208 @@ +--- +section: libraries +toc: true +description: Migration Guide from lock-passwordless to Lock v11 with Passwordless Mode +public: false +topics: + - libraries + - lock + - migrations + - passwordless +contentType: + - how-to + - reference + - concept +useCase: + - add-login + - migrate +--- +# Migration Guide for lock-passwordless to Lock v11 with Passwordless Mode + +The following instructions assume you are migrating from the **lock-passwordless** widget to Lock v11.2+ using **Passwordless Mode**. + +The [lock-passwordless](https://github.com/auth0/lock-passwordless) widget was previously a standalone library, separate from [Lock](/libraries/lock). Now, you can migrate your apps to use the Passwordless Mode which is integrated directly into Lock v11. Lock v11 with Passwordless Mode is the latest method by which to deploy a login widget for passwordless authentication in your apps. + +To get started, you will need to remove **lock-passwordless** from your project, and instead include the [latest release version of Lock v11](https://github.com/auth0/lock/releases). + +::: note +To use Passwordless Mode, you must use Lock v11.2 or above. +::: + +Beyond that, you will then need to take a careful look at each of the sections in this migration guide in order to find out which changes you will need to make to your implementation. Of particular importance will be the following: + +* The initialization of `Auth0LockPasswordless` +* Your calls to Lock methods (now the same methods as used in Lock v11) +* Your previously implemented customization options, which will need inspected and changed to use the corresponding options for Lock v11. + +## General changes and additions + +### Importing Auth0LockPasswordless + +You can import Auth0LockPasswordless in the same ways as you would normally import Lock; using the CDN or via NPM. + +#### Using the CDN + +If you're loading from the CDN, you can still use `Auth0LockPasswordless`. The difference is that you'll provide your options in the constructor, like we do with `Auth0Lock`: + +
+
+ +
+
+
+ 

+    <script src="http://cdn.auth0.com/js/lock-passwordless-2.2.3.min.js"></script>
+    <script>
+      var lock = new Auth0LockPasswordless(clientID, domain);
+    </script>
+
+
+
+ 

+    <script src="${lock_url}"></script>
+    <script>
+      // example use of options
+      var options = {
+        closable: false
+      }
+      var lock = new Auth0LockPasswordless(clientID, domain, options);
+    </script>
+
+
+
+
+ +#### Using npm + module bundler + +
+
+ +
+
+
+ 

+    import Auth0LockPasswordless from 'auth0-lock-passwordless';
+    var lock = new Auth0LockPasswordless(clientID, domain);
+
+
+
+ 

+    import {Auth0LockPasswordless} from 'auth0-lock';
+    var options = {
+      closable: false
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+
+
+
+
+ +### Initialization options + +`Auth0LockPasswordless` has the same [options available](/libraries/lock/v11/configuration) as `Auth0Lock` in addition to a single new option that determines if you want to use a Magic Link or a Email Code when using an email passwordless connection. For this property, `passwordlessMethod`, only two values are accepted: + +- `code` if you want to use an Email Code +- `link` if you want to use a Magic Link + +
+
+ +
+
+
+ 

+    var options = {
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+
+
+ +
+
+ +### Choose between SMS or email + +We recommend that you setup which passwordless connections you want enabled in [the dashboard](${manage_url}/#/connections/passwordless), but if you want to have more than one passwordless connection enabled in the dashboard, you can restrict `Auth0LockPasswordless` to use only one of them using the [allowedConnections](/libraries/lock/v11/customization#allowedconnections-array-) option. +If you have both `sms` and `email` passwordless connections enabled in the dashboard, `Auth0LockPasswordless` will use `email` by default. + +
+
+ +
+
+
+ 

+    var options = {
+      allowedConnections: ['sms']
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+
+
+
+ 

+    var options = {
+      allowedConnections: ['email'],
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+
+
+
+
+ +### Show the widget + +In the old `lock-passwordless`, you could call the passwordless method directly (sms, socialOrMagiclink, socialOrSms etc). In Lock v11, you'll have to use [the show method](/libraries/lock/v11/api#show-) in order to display the widget. + +```js +var lock = new Auth0LockPasswordless(clientID, domain); +lock.show(); +``` + +### Subscribe to events + +Lock exposes a few events that you can subscribe to in order to be notified when the user is authenticated or an error occurs. So, instead of callbacks from `lock-passwordless`, you have to subscribe to events that you want to know about. To read more about Lock events, see [here](/libraries/lock/v11/api#on-). + +```js +var lock = new Auth0LockPasswordless(clientID, domain); +lock.on("authenticated", function(authResult) { + alert(authResult.accessToken); +}); +``` + +### Customization options + +Some options have to be renamed. + +* `dict` is now [languageDictionary](/libraries/lock/v11/configuration#languagedictionary-object-) +* `connections` is now [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-) +* `socialBigButtons` is no longer available as an option and all the social connection buttons will be shown with a "big" style. +* all the authentication options were moved into an [auth object](/libraries/lock/v11/configuration#auth-object-) + +## Further Reading + +::: next-steps +- [Lock 11 Reference - an overview on how Lock works](/libraries/lock/v11) +- [Lock 11 Configuration - details on the available configuration options for Lock](/libraries/lock/v11/configuration) +::: diff --git a/fr-ca/articles/libraries/lock/v11/migration-react.md b/fr-ca/articles/libraries/lock/v11/migration-react.md new file mode 100644 index 0000000000..fbac6ae04c --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-react.md @@ -0,0 +1,23 @@ +--- +section: libraries +title: Migrating React applications to Lock v11 +description: How to migrate React applications to Lock v11 +public: false +topics: + - libraries + - lock + - migrations + - react +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating React Applications to Lock v11 + +React applications use Lock directly without any kind of wrapper library. + +Most React applications will be using Lock v10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide. + +If you were an early React and Auth0 adopter, and are using Lock v9, you can follow the [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11) guide. diff --git a/fr-ca/articles/libraries/lock/v11/migration-v10-v11.md b/fr-ca/articles/libraries/lock/v11/migration-v10-v11.md new file mode 100644 index 0000000000..16e9b75071 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-v10-v11.md @@ -0,0 +1,41 @@ +--- +section: libraries +title: Migrating from Lock v10 to v11 +description: How to migrate from Lock v10 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrate from Lock v10 to v11 + +This guide includes all the information you need to update your Lock v10 application to [Lock v11](/libraries/lock). + +## Migration demo + +
 
+ +## Migration steps + +<%= include('../../_includes/_migrate_universal') %> +<%= include('../../_includes/_get_lock_latest_version') %> +<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %> +<%= include('../../_includes/_change_get_profile') %> +<%= include('../../_includes/_oidc_conformant') %> +<%= include('../../_includes/_configure_custom_domain', { library : 'Lock v11'}) %> +<%= include('../../_includes/_verifying_migration') %> + +## Behavioral changes in Lock v11 + +<%= include('../../_includes/_popup_mode') %> +<%= include('../../_includes/_last_logged_in_window') %> +<%= include('../../_includes/_ip_ranges') %> +<%= include('../../_includes/_default_values_lock') %> +<%= include('../../_includes/_embedded_sso') %> diff --git a/fr-ca/articles/libraries/lock/v11/migration-v8-v11.md b/fr-ca/articles/libraries/lock/v11/migration-v8-v11.md new file mode 100644 index 0000000000..2f2e3e53c6 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-v8-v11.md @@ -0,0 +1,22 @@ +--- +section: libraries +title: Migrating from Lock v8 to v11 +description: How to migrate from Lock v8 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating from Lock v8 to v11 + +Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint. + +You can follow the instructions on [how to migrate from Lock v9 to Lock v11](/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock v8. + diff --git a/fr-ca/articles/libraries/lock/v11/migration-v9-v11.md b/fr-ca/articles/libraries/lock/v11/migration-v9-v11.md new file mode 100644 index 0000000000..cb56f72034 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/migration-v9-v11.md @@ -0,0 +1,201 @@ +--- +section: libraries +title: Migrating from Lock v9 to v11 +description: How to migrate from Lock v9 to v11 +public: false +toc: true +topics: + - libraries + - lock + - migrations +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Migrating from Lock v9 to v11 + +This guide includes all the information you need to update your Lock v9 applications to [Lock v11](/libraries/lock). + +## Migration Steps + +Given that Lock v10 is very similar to Lock v11 you can read the [Lock v9 to Lock v10 migration guide](/libraries/lock/v10/migration-guide). + +Building Single-Page Applications with Lock v9 has some key differences with the way they should be built in Lock v11. Lock v11 uses OIDC conformant APIs that are more secure, and some of the coding patterns with Lock v9 need to be changed. + +<%= include('../../_includes/_get_lock_latest_version') %> + +### Using Lock in SPAs with Popup Mode + +In Lock v9 the code to use `popup mode` looked similar to the below example. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); +function login() +{ + lock.show({ + responseType : "token", + authParams: { + scope: 'openid email offline_access' + } + }, + function (err, profile, id_token, access_token, state, refresh_token) { + if (!err) { + setSession(profile, id_token, access_token, refresh_token); + lock.getProfile(hash.id_token, function(err, userInfo) { + if (!err) { + /// use the userInfo + } + }); + } + } + }) +} +``` + +In Lock v11, the code would instead use the following format. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { + { + popup: true, + auth: { + responseType: 'token id_token', + audience: 'https://' + '${account.namespace}' + '/userinfo', + params: { + scope: 'openid email profile' + } + } + } + ); + +lock.on('authenticated', function(authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult); + + lock.getUserInfo(authResult.accessToken, function(err, userInfo) { + if (!err) { + // use the userInfo + } + }); + } +}); +function login() +{ + lock.show() +} +``` + +Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that the callback specified in `show()` is replaced by an `authenticated` event handler. + +### Using Lock in SPAs with Redirect Mode + +In Lock v9 the code to use `redirect mode` looked similar to the below example. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); +var hash = lock.parseHash(); + +if (hash) { + if (!hash.error) { + setSession(hash.profile, hash.id_token, hash.access_token, hash.refresh_token); + + lock.getProfile(hash.id_token, function(err, userInfo) { + if (!err) { + // use the userInfo + } + }); + } +} + +function login() { + lock.show({ + callbackURL: '${account.callback}', + responseType : "token", + authParams: { + scope: 'openid email offline_access' + } + }); +} +``` + +In Lock v11, the code should instead use the following format. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { + { + auth: { + redirectUrl: '${account.callback}', + responseType: 'token id_token', + params: { + scope: 'openid email profile' + } + } + } + ); + +lock.on('authenticated', function(authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult); + // use authResult.idTokenPayload for profile information + } +}); + +function login() { + lock.show() +} +``` + +Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that instead of calling `parseHash()`, you need to write an `authenticated` event handler. + +### Using Lock in Web Applications + +When using Lock v9 for Web Applications, the code would be similar to the below example. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); + +function login() { + lock.show({ + auth: { + redirectUrl: '${account.callback}', + responseType: 'code', + params: { + scope: 'openid profile email' + } + } + } +``` + +In Lock v11, the code should instead use the following format. + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { + { + auth: { + redirectUrl: '${account.callback}', + responseType: 'code', + params: { + scope: 'openid email profile' + } + } + } +); + +function login() { + lock.show() +} +``` + +Note that, once more, the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11. + +<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %> +<%= include('../../_includes/_legacy_flows') %> +<%= include('../../_includes/_change_get_profile') %> + +## Behavioral Changes in Lock v11 + +<%= include('../../_includes/_popup_mode') %> +<%= include('../../_includes/_default_values_lock') %> +<%= include('../../_includes/_ip_ranges') %> diff --git a/fr-ca/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md b/fr-ca/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md new file mode 100644 index 0000000000..928c694dac --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md @@ -0,0 +1,139 @@ +--- +section: libraries +description: How to select different connection types for multiple login options with Lock V11. +topics: + - libraries + - lock + - connections +contentType: + - how-to +useCase: + - add-login + - customize-connections +--- +# Selecting from Multiple Connection Options + +With Auth0 you can offer users multiple methods of authenticating. This is important with SaaS or multi-tenant apps, where many organization use a single app. Each organization might use different systems such as LDAP, Active Directory, G Suite, or username/password stores. + +In Auth0, you can associate different *connections* (methods of authentication) to specific applications, or directly to a tenant (as [domain connections](/api/management/guides/connections/promote-connection-domain-level)). When a user logs in, one of these connections will need to be selected as the one to use. + +![](/media/articles/hrd/sd4h-6wlwOsQA1PCQKLAmtQ.png) + +::: note +Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery". +::: + +If you use at most one database connection and zero or more social connections the selection process is straightforward. The user will either: + +* Click on one of the social identity providers buttons (e.g. "Log in with Google") +* Enter their email and password (meaning "I will use the database connection"). + +But if the application or tenant have other connection types enabled (like enterprise connections or multiple databases) the selection process might be more involved. How do you indicate that a user wants to use a specific database connection if more than one is enabled? What if a user wants to use an enterprise connection to log in using Single Sign-on (SSO)? + +If you implement [a custom login UI](/libraries/when-to-use-lock#when-to-implement-lock-vs-a-custom-ui) you have full control over the authentication flow. You can choose the connection based on context (like the given email address) or by asking the user, then provide the `connection` parameter to one of Auth0.js' [login methods](/libraries/auth0js/v9#login). + +## Lock and multiple connections + +Lock has built in functionality for identity provider selection. For social connections, it shows logos for all those enabled in a particular app. It also provides username/email and password fields if a database connection or Active Directory connection are enabled. + +## Using email domains with enterprise connections + +An additional feature in Lock is the use of email domains as a way of routing authentication requests. Enterprise connections in Auth0 can be mapped to `domains`. For example, when configuring an ADFS or a SAML-P identity provider: + +![](/media/articles/libraries/lock/enterprise-connection.png) + +If a connection has domains mapped to it, then the password input field gets disabled automatically when a user enters an email with a mapped domain. + +![Lock using HRD/SSO](/media/articles/libraries/lock/hrd-sso.png) + +In the example above the domain `auth0.com` has been mapped to an enterprise connection. + +Notice that you can associate multiple domains to a single connection. + +## Selecting among multiple database connections + +If your application has multiple database connections enabled, Lock needs to know which one to use. You can provide a [`connectionResolver` option](https://github.com/auth0/lock#other-options), which takes a function that decides the connection to use based on the user input and context. In this example an alternative database connection is used if the email domain is "auth0.com": + +``` +var options = { + connectionResolver: function (username, context, cb) { + var domain = username.indexOf('@') !== -1 && username.split('@')[1]; + if (domain && domain ==='auth0.com') { + // If the username is test@auth0.com, the connection used will be the `auth0-users` connection. + cb({ type: 'database', name: 'auth0-users' }); + } else { + // Use the default approach to figure it out the connection + cb(null); + } + } +} +``` + +You can use the [`defaultDatabaseConnection` option](/libraries/lock/v11/configuration#defaultdatabaseconnection-string-) to specify the database connection that will be used by default. + +## Filtering available connections programmatically + +The [`allowedConnections` option](/libraries/lock/v11/configuration#allowedconnections-array-) in Lock lets you indicate which of the available connections should be presented as an option to the user. + +This lets you tailor the experience based on additional input or context (e.g. "Click here to log in as a student, or here to log in as a faculty member"). + + +```js +var lock = new Auth0Lock( + '${account.clientId}', + '${account.namespace}', + { + allowedConnections: ['YOUR CONNECTION HERE']; + } +); +``` + +::: note +Note that you can also provide the `allowedConnections` option to the `lock.show()` method if providing it at instantiation is not ideal for your use case. Please refer to the [API documentation](/libraries/lock/v11/api#show-) for the `show` method for more information. +::: + +# Sending realm information from the application + +Sometimes the application requesting an authentication can know, in advance, the realm intented to be used by the user. E.g. a multi-tenant application might use URLs in the form of: `https://{customer}.yoursite.com` or `https://www.yoursite.com/{customer}`. When a user arrives at your application with the vanity URL, you can pick up that `tenant` value and pass it as the `login_hint` in the `authorize` request: + +``` +https://{YOUR_AUTH0_DOMAIN}/authorize?client_id=[...]&login_hint={customer} +``` + +`login_hint` is a hint to the authorization server (Auth0) to indicate what the user might use to log in. In this case, based on the URL where the user landed, we treat the "customer" as the realm. + +The default hosted login page code uses it to pre-fill the email field in Lock, but we can modify the code to alter the default database connection to be used if a realm is provided instead of an actual email address: + +```js +// from the default Hosted Login Page template +var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@')))); +[...] + +var loginHint = config.extraParams.login_hint; +var realmHint; + +// if the login hint is not an email address, we treat it as a realm hint +if (loginHint && loginHint.indexOf('@') < 0) { + realmHint = loginHint; + loginHint = null; +} + +// now we map the realm into an actual database +var defaultDatabaseConnection; +if (realmHint === 'acme') { + defaultDatabaseConnection = 'acme-users'; +} else if (realmHint === 'auth0') { + defaultDatabaseConnection = 'auth0-DB'; +} + +// When configuring Lock, we provide the values obtained before +var lock = new Auth0Lock(config.clientID, config.auth0Domain, { + [...] // other options + prefill: loginHint ? { email: loginHint, username: loginHint } : null, + defaultDatabaseConnection: defaultDatabaseConnection +} +``` + +The above code is, of course, just a sample. You could expand this logic to filter out social connections, or to set a default connection to be used even if an email address is provided as a `login_hint`. + +Mapping the "customer" as a realm is an arbitrary design decision for this example. But it is generally a good idea to isolate applications from the actual "connection" concept used within Auth0 and use the more abstract "realm" concept instead, possibly doing a realm-to-connection mapping within the hosted login page (where it's easier to make changes if necessary). diff --git a/fr-ca/articles/libraries/lock/v11/sending-authentication-parameters.md b/fr-ca/articles/libraries/lock/v11/sending-authentication-parameters.md new file mode 100644 index 0000000000..fa5e7055ff --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/sending-authentication-parameters.md @@ -0,0 +1,85 @@ +--- +section: libraries +description: Lock v11 documentation on setting authentication parameters. +topics: + - libraries + - lock +contentType: + - how-to + - reference +useCase: + - add-login +--- +# Lock Authentication Parameters + +You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `'foo'`. + +```js +var options = { + auth: { + params: {state: 'foo'}, + } +}; +``` + +The following parameters are supported: `scope`, `device`, `nonce` and `state`. + +::: note +This would be analogous to triggering the login with `https://${account.namespace}/authorize?state=foo&...`. +::: + +## Supported parameters + +### scope {string} + +```js +var options = { + auth: { + params: {scope: 'openid email user_metadata app_metadata picture'}, + } +}; +``` + +There are different values supported for scope. Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. + +The default `scope` value in Lock v11 is `openid profile email`. This minimum scope value is required to make the **Last time you logged in with** feature work correctly. + +::: panel Running Lock Locally +If you don't specify at least the above scope when initializing Lock, and you are running your website from `http://localhost` or `http://127.0.0.1`, you will get the following error in the browser console: + +`Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email` + +That will not happen when you run your application in production or if you specify the `openid profile email` scope. You can read more about this in the [User consent and third-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications) document. +::: + +For more information about scopes, see the [scopes documentation page](/scopes). + +#### Example: retrieve a token + +In Lock v11, if you wish to receive a token with the ability to fetch the user's profile data, you should add the `scope` parameter. + +```js +var options = { + auth: { + params: { + scope: 'openid profile' + } + } +}; +``` + +::: note +There is also a `connectionScopes` configuration option for Lock v11, which allows you to specify scopes on any specific connection. This will be useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request additional permissions or attributes from a specific connection. Read more about it on the [Lock Configuration Options](/libraries/lock/v11/configuration#connectionscopes-object-) page. +::: + +### state {string} + +The `state` parameter is an arbitrary state value that will be maintained across redirects. It is useful to mitigate [XSRF attacks](http://en.wikipedia.org/wiki/Cross-site_request_forgery) and for any contextual information, [such as a return url](/protocols/oauth2/redirect-users) that you might need after the authentication process is finished. If a custom state parameter is not provided, Lock will automatically generate one. For more information, see [State Parameter](/protocols/oauth-state). + +### nonce {string} + +The `nonce` parameter is used to help prevent replay attacks, and will be automatically generated by Lock if a custom value is not provided. + +### device {string} + +The `device` parameter sets the name of the device or browser requesting authentication. diff --git a/fr-ca/articles/libraries/lock/v11/ui-customization.md b/fr-ca/articles/libraries/lock/v11/ui-customization.md new file mode 100644 index 0000000000..6bbb747ae9 --- /dev/null +++ b/fr-ca/articles/libraries/lock/v11/ui-customization.md @@ -0,0 +1,129 @@ +--- +section: libraries +description: Customizing the appearance of your Lock widget can be important for branding and a cohesive UI, and this resource highlights the ways in which you can do so while implementing Lock in your project. +topics: + - libraries + - lock + - lock-ui +contentType: + - how-to + - reference +useCase: + - add-login +--- +# Lock UI Customization + +You can customize the appearance of your Lock widget in a few different ways. The best and safest way to do so is with the provided JavaScript options. + +## JavaScript Options + +You can set up a variety of customizations to your Lock via the `options` parameter when you instantiate your Lock. Some of them allow you to customize your UI. The UI customization options are a work in progress - we expect to be adding more as we go. + +First, you'll define the `options` object, containing whichever options you're wanting to customize. Then you'll need to include that options object as the third parameter when you instantiate Lock; more on that below. + +### Theming Options + +There are a couple of theming options currently available, namespaced under the `theme` property. + +#### logo {String} + +![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png) + +The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience. + +```js +var options = { + theme: { + logo: 'https://example.com/logo.png' + } +}; +``` + +#### primaryColor {String} + +![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png) + +The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`. + +```js +var options = { + theme: { + logo: 'https://example.com/logo.png', + primaryColor: '#31324F' + } +}; +``` + +#### authButtons {Object} + +Allows the customization of buttons in Lock. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below: + +- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login). +- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`. +- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`. +- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`. + +```js +var options = { + theme: { + authButtons: { + "testConnection": { + displayName: "Test Conn", + primaryColor: "#b7b7b7", + foregroundColor: "#000000", + icon: "http://example.com/icon.png" + }, + "testConnection2": { + primaryColor: "#000000", + foregroundColor: "#ffffff", + } + } + } +}; +``` + +### Customizing Text + +The `languageDictionary` option allows customization of every piece of text displayed in the Lock. Defaults to {}. See below for an example. + +```js +var options = { + languageDictionary: { + emailInputPlaceholder: "something@youremail.com", + title: "Log me in" + }, +}; +``` + +![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png) + +::: note +For a complete list of the items able to be customized using `languageDictionary`, see the [English Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) in the repository. +::: + +### Instantiating Lock + +Finally, you'll want to go ahead and instantiate your Lock, with the `options` object that you've defined with your custom options in it. + +```js +// Initiating our Auth0Lock +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', options); +``` + +## Overriding CSS + +Customizing your Lock by overriding its CSS isn't recommended. The issue is that with new releases of Lock, some styling may change, leading to unintended problems if you are overriding the CSS. Additionally, it's possible to simply overlook use of styles in other places and while the change may look fine in one view, it might not in another. + +If you still intend to override CSS to further style your Lock, we recommend that you use a specific patch version of Lock rather than a major or minor version, so that you limit the amount of unexpected results that may occur when you alter the styles, and then another patch is deployed that might cause unexpected behavior in your UI due to the changes. This can be done by ensuring that you specify that patch version (`x.y.z`) when including Lock, or downloading it. + +Additionally, we of course recommend that you test your CSS changes exhaustively, to ensure that the experience is the one you intend it to be for your customers. + +::: panel-warning Regarding Lock CSS Themes +At this time, Auth0 doesn't offer any alternative pre-made CSS themes for Lock v11, and the ones that existed for earlier versions of Lock will not work with Lock v11. +::: + +## Further Information + +If you're looking for more detailed information while working to customize Lock for your application, check out the [configuration options](/libraries/lock/v11/configuration) page or the [Lock API](/libraries/lock/v11/api) page! + +If you have specific theming options that you would like to see added, let us know. We are working on improving the customization options that are available through JavaScript, and this list will be updated as new options are added. diff --git a/fr-ca/articles/libraries/secure-local-development.md b/fr-ca/articles/libraries/secure-local-development.md new file mode 100644 index 0000000000..577adafce8 --- /dev/null +++ b/fr-ca/articles/libraries/secure-local-development.md @@ -0,0 +1,143 @@ +--- +section: libraries +description: Securing local development servers to work with samesite cookies +topics: + - libraries + - samesite +contentType: + - guide +--- + +# Secure Local Development +Local development environments typically run on non-secure channels (ie: `http://localhost`) out of the box. This guide will discuss when you should run a secure local server and how to setup `https` on localhost. + +## When to use a secure local server +Testing over non-secure channels `http` is generally safe for local servers that don't communicate with external services, like Auth0. However, when your local server is communicating with external services, we recommend running your local server on `https` for the following reasons: + +- Communication between an external service and your localhost should be encrypted to protect any sensitive information. +- It tests a very critical part of the development stack if you run your server on secure channels in production. +- Cookies using a Secure attribute or SameSite attribute set to `None` will not be sent across insecure channels, disrupting authentication and other functionality. + +## How to set up a secure local server +When you visit a secure web page (served over https), your browser will verify the SSL certificate supplied by the server with a Certificate Authority. When loading a secure web page from a local server, you can create an authority just for your machine and generate certificates that only your browser will trust. + +The process to do this is: + +1. Create and install a local Certificate Authority +2. Generate an SSL certificate for the domain being used (ie. localhost) using this new Authority. +3. Serve the SSL certificate from your web application + +### 1. Install Mkcert Utility +To get started, download [mkcert](https://github.com/FiloSottile/mkcert) and follow the [installation instructions](https://github.com/FiloSottile/mkcert#installation) for your specific operating system. + +### 2. Install local Certificate Authority +The Certificate Authority is a trusted entity that the web browser uses to verify the certificate supplied by a webserver. Installing a local Certificate Authority will allow you to generate your own SSL Certificates to be used locally. + +```powershell +> mkcert -install +# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨ +# The local CA is now installed in the system trust store! 👍 +# The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊 +``` + +### 3. Generate an SSL Certificate +The next step is to generate the SSL certificate. This example will assume you are running your local server on `https://localhost:{port}`. + +```powershell +> mkcert localhost +# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨ + +# Created a new certificate valid for the following names 📜 +# - "localhost" + +# The certificate is at "./localhost.pem" and the key at "./localhost-key.pem" ✅ +``` + +:::note +The utility saves the certificate `localhost.pem` and a key file `localhost-key.pem` in the folder where the command was executed. +::: + +### 4. Serve the SSL certificate +Now that you have generated an SSL certificate and key, you need to load them when starting your server. The way certificates are loaded depends on the technology used to serve the application. Please see below for examples. + +#### Node.js with Express + +```js +// app.js + +const express = require('express'); +const https = require('https'); +const fs = require('fs'); + +const key = fs.readFileSync('./localhost-key.pem'); +const cert = fs.readFileSync('./localhost.pem'); + +https.createServer({key, cert}, express()).listen('3000', () => { + console.log('Listening on https://localhost:3000'); +}); +``` + +#### webpack DevServer + +```js +// webpack.config.js + +module.exports = { + //... + devServer: { + https: { + key: fs.readFileSync('./localhost-key.pem'), + cert: fs.readFileSync('./localhost.pem'), + } + } +}; +``` + +#### Apache (including PHP, Python, Ruby) + +The actual path of the files mentioned below will differ depending on the OS and install method. The paths below are from Homebrew-installed Apache on macOS. + +``` +# /usr/local/etc/httpd/httpd.conf +# Find and uncomment the lines below + +LoadModule socache_shmcb_module lib/httpd/modules/mod_socache_shmcb.so +# ... +LoadModule ssl_module lib/httpd/modules/mod_ssl.so +# ... +Include /usr/local/etc/httpd/extra/httpd-ssl.conf +``` + +``` +# /usr/local/etc/httpd/extra/httpd-ssl.conf + +# Listen 8443 +Listen 443 +# ... + +# Change the line below and comment out the two lines referenced below +# + +# ... +# DocumentRoot "/usr/local/var/www" +# ServerName www.example.com:8443 +``` + +``` +# /usr/local/etc/httpd/extra/httpd-vhosts.conf + + + # Make sure this path points to your local application. + DocumentRoot "/path/to/application/root" + ServerName localhost + SSLEngine on + SSLCertificateFile "/usr/local/etc/httpd/localhost.pem" + SSLCertificateKeyFile "/usr/local/etc/httpd/localhost-key.pem" + +``` + +#### Nginx (for PHP) + +#### WordPress + +The WordPress documentation has some [specific considerations for running WordPress over HTTPS](https://make.wordpress.org/support/user-manual/web-publishing/https-for-wordpress/). Please see the Apache or nginx sections above for specifics on loading the certificates. diff --git a/fr-ca/articles/libraries/when-to-use-lock.md b/fr-ca/articles/libraries/when-to-use-lock.md new file mode 100644 index 0000000000..fba0c02d30 --- /dev/null +++ b/fr-ca/articles/libraries/when-to-use-lock.md @@ -0,0 +1,167 @@ +--- +section: libraries +description: When customizing the Classic Universal Login page what tools should you use? Lock (Auth0's drop-in authentication widget) or a custom UI built on top of an Auth0 SDK? This guide will help you decide. +topics: + - libraries + - lock + - custom-ui +contentType: + - concept +useCase: + - add-login + - enable-mobile-auth +--- +# Universal Login Page Customization + +When adding Auth0 to your web apps, the best solution is to use Auth0's Universal Login. If you plan to use the [New Experience](/universal-login/new), you won't even need to choose an Auth0 library to use inside of the login page, and can stop here. If you are using the [Classic Experience](/universal-login/classic), this guide will help you choose a technology to power your login page. + +Universal Login is less complex than embedding the authentication process within your app. It also prevents the dangers of cross-origin authentication. + +The Classic login page uses the Lock Widget by default for user authentication. It also has templates for Lock in Passwordless Mode and for a custom UI built with the Auth0.js SDK. + +* [Lock for Web](/libraries/lock), Auth0's drop-in login and signup widget +* The [Auth0 SDK for Web](/libraries/auth0js) with your custom designed interface +* Or, a custom user interface that you have created which directly ties into the [Authentication API](/auth-api). + +::: note +Passwordless authentication from native mobile apps currently must use Universal Login - there is no native passwordless option at this time. +::: + +## When to Implement Lock vs. a Custom UI + +**Lock** is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface. + +**Auth0 SDKs** are client-side libraries that **do not** come with a user interface but allow for expanded customization of the behavior and appearance of the login page. + +The **Authentication API** provides integration without requiring the use of Auth0 SDKs. The best option to choose will depend on the needs of your app. + +Below is a quick overview of reasons you might want to use Lock, versus using an Auth0 SDK or the authentication API. There are details about each option (Lock, Auth0 SDKs, Authentication API) below the table, to assist you in finding the right way to implement Auth0 in your application! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Desired UI Attributes:LockCustom UI
Has a simple design that fits in with most modern websites with just a few tweaks to its options.YesNo
Adapts to your configuration and only show the allowable options in the appropriate situationsYesNo
Chooses the correct connection automaticallyYesNo
Remembers the last used connection for a given userYesNo
Automatically accommodates internationalizationYesNo
Automatically provides password policy checking at signupYesNo
Provide secure authentication via Auth0YesYes
Potential to provide auth without having to create custom code to deal directly with Auth0's APIYesYes
Follows strict appearance requirements as set by your companyNoYes
Allows you to retain your existing UI for authenticationNoYes
Allows for expert usage of HTML, CSS, and JavaScript for customizationNoYes
Handles multiple databases or Active Directory connectionsNoYes
+ +## Lock + +**Lock** is a login form that makes it easy for your users to authenticate using a selected connection. **Lock** will automatically handle most of the details involved in creating and authenticating users. [Lock](/libraries/lock) is provided as a drop-in solution for the Classic Universal Login experience. + +![](/media/articles/libraries/lock/lock-default.png) + +With **Lock**, you will be implementing a UI that: + +* Is robust and provides an excellent user experience on any device with any resolution +* Has a simple design that fits in with most websites with just a few tweaks to its custom color +* Adapts to your configuration, displaying the appropriate form controls for each available connection and only those which are allowed (such as sign up or password reset) +* Selects the correct connection automatically. You may specify a desired default behavior for ambiguous cases +* Remembers the last used connection for a given user +* Automatically accommodates internationalization +* Provides instant password policy checking at sign up + +Although you cannot alter Lock's behavior significantly, you can configure several [basic options](/libraries/lock/customization) to make Lock look and behave differently. + +![](/media/articles/libraries/lock/lock-phantom.png) + +### When to use Lock + +Consider using **Lock** if: + +* You like the structure, look, and feel of **Lock** +* You prefer a quicker and easier implementation of Auth0 and a ready-made responsive UI +* Your process includes many of the use cases that **Lock** handles out of the box: + * Enterprise logins + * Databases with password policies + * User signup and password reset + * Authentication using social providers + * Avatars + +## Custom User Interface + +If the requirements of your app cannot be met by the standardized behavior of **Lock**, or if you have a complex custom authentication process, a custom user interface is needed. You also might prefer this option if you already have a user interface which you would prefer to keep. + +With Auth0's library for [Web](/libraries/auth0js), you can customize the behavior and flow of the process used to trigger signup and authentication. You can also directly use the [Authentication API](/auth-api), without any wrapper at all, if you so choose. + +![](/media/articles/libraries/lock-vs-customui/customui.png) + +Unlike with **Lock**, neither of these options includes a user interface. You will have complete control over the user experience for signup and authentication flow, and for the UI aspects of layout, look and feel, branding, internationalization, RTL support, and more. + +### When to use a custom user interface + +Consider implementing a custom user interface in conjunction with an Auth0 library or the Authentication API for your app if: + +* You have strict requirements for the appearance of the user interface +* You have strict requirements for file sizes - the Auth0 libraries are significantly smaller than Lock, and if you instead choose to deal with the API directly, that would not require any additional weight. +* You are comfortable with HTML, CSS, and JavaScript - you'll be creating your own UI +* You only need to handle username/password and social provider authentication +* You have multiple database or Active Directory Connections + +## See Also + +You can also see specific examples of the usage of both Lock and Auth0 SDKs for a wide variety of programming languages and platforms in our [Quickstarts](/quickstart). These guides may further assist you in your decision about which to use for your specific app needs. diff --git a/fr-ca/articles/login/embedded/index.md b/fr-ca/articles/login/embedded/index.md new file mode 100644 index 0000000000..a2f469081e --- /dev/null +++ b/fr-ca/articles/login/embedded/index.md @@ -0,0 +1,15 @@ +--- +description: A brief overview of Embedded Login with Auth0 +topics: + - login + - embedded-login + - hosted-pages +contentType: index +useCase: customize-hosted-pages +--- + +# Embedded Login + +Embedded Login is the scenario in which users login directly in your application, and credentials are transmitted to the Auth0 server. There are security concerns with this approach, particularly if you do not use the [Custom Domains](/custom-domains) feature at Auth0, as this potentially opens your application up to [cross-origin authentication](/cross-origin-authentication) issues. + +If you need to implement embedded login, you need to have a custom domain set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication). diff --git a/fr-ca/articles/login/index.md b/fr-ca/articles/login/index.md new file mode 100644 index 0000000000..ec29764282 --- /dev/null +++ b/fr-ca/articles/login/index.md @@ -0,0 +1,74 @@ +--- +description: Overview of Universal Login with Auth0 +topics: + - login + - universal-login + - password-reset + - mfa + - error-pages + - hosted-pages +contentType: index +toc: true +useCase: customize-hosted-pages +--- +# Login with Auth0 + +Auth0 provides two ways to implement authentication for your applications: + +* Universal Login: users log in to your application through a page hosted by Auth0. +* Embedded Login: users log in to your application through a page you host. + +For the vast majority use cases, we recommend Universal Login. It's safe and easy to implement. Check out [our comparison guide](/guides/login/universal-vs-embedded) for more on the differences between Universal Login and Embedded Login within your application. + +## Universal Login + +Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. With Universal Login, users are redirected from your application to a login page hosted by Auth0. Auth0 then authenticates the user and returns them to your application. Since login and authentication take place on the same domain, credentials are not sent across origins, increasing security and protecting against attacks such as phishing and man-in-the-middle. + +Universal Login functionality and features are driven from web pages served by Auth0, so you can adjust the login experience in real-time without changing your application code. Universal Login page appearance and behavior is customizable right from the [Dashboard](${manage_url}). + +### Classic or New? + +There are two versions of Universal Login: + +* Classic Universal Login: Auth0-hosted pages built with [Lock.js](/libraries/lock) and other Javascript widgets, or with a library like [Auth0.js](/libraries/auth0js). HTML and CSS can also be customized. +* New Universal Login: Auth0-hosted pages, rendered server-side, that do not use [Lock.js](/libraries/lock) or other Javascript widgets and libraries. Can only be customized based on the configuration available. HTML, CSS, and JS cannot be customized. + +In the [Dashboard](${manage_url}), the dialog shown below lets you select which Experience will be used for default, non-customized pages: + +![Login Page](/media/articles/universal-login/experience-picker.png) + +To learn more about each experience and their differences, check out the following articles: + +* [Classic Universal Login Experience](/universal-login/classic) +* [New Universal Login Experience](/universal-login/new) +* [New Universal Login Limitations](/universal-login/new-experience-limitations) + +### Implementing Universal Login + +In addition to configuring Universal Login for your tenant's applications, you will also need to complete a few other steps: + +1. Set up a connection(s) in the [Dashboard](${manage_url}) (Choose **Connections** in the Dashboard's sidebar, then choose a type and pick one to configure, such as a database or a social login provider). +1. Set up your application in the [Dashboard](${manage_url}/#/applications). +1. Configure your application's code to call Auth0's [`/authorize`](/api/authentication#login) endpoint in order to trigger Universal Login, and then to deal with the response. You can either do this directly or use one of our SDKs to make the process easier. + +For step by step instructions on setting up your application to use Universal Login, check out our [Quickstart guides](/quickstarts). + +### Simple Customization + +![Customization Settings for Login Page](/media/articles/universal-login/settings.png) + +In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab. + +The settings available here are: + +* Logo +* Primary Color +* Background Color + +These settings, once changed, will take effect on all your Universal Login pages if you have not enabled customization of the pages' code. The settings will also work if you have enabled customization but are using the predefined templates and have not changed those options in the code. + +If you select the New Universal Login Experience, you can also configure the favicon URL and a custom font URL using [the Branding API](/api/management/v2#!/Branding). + +## Embedded Login + +Embedded Login refers to implementations where users log in on a page hosted by your application, and credentials are sent to Auth0. There are security concerns with this approach since login and authentication take place on the different domains. If you need to implement Embedded Login, you need to have a [custom domain](/custom-domains) set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication). diff --git a/fr-ca/articles/login/spa/authenticate-with-cookies.md b/fr-ca/articles/login/spa/authenticate-with-cookies.md new file mode 100644 index 0000000000..aa00106d1a --- /dev/null +++ b/fr-ca/articles/login/spa/authenticate-with-cookies.md @@ -0,0 +1,221 @@ +--- +title: Single-Page App Authentication Using Cookies +description: Use your backend server to authenticate a single page app with cookies +topics: + - login + - spa +contentType: how-to +toc: true +useCase: spa-cookies +--- + +# Single-Page App Authentication Using Cookies + +Securing a single-page application (SPA) can be a challenge. However, if your SPA: + +* is served to the client using your own backend +* has the same domain as your backend +* makes API calls that require authentication to your backend + +Then you can simplify your implementation by using cookies to authenticate your SPA. In the following guide you'll find an overview of this approach as well as a sample implementation using [Node.js](https://nodejs.org/en/). + +## How it works + +The steps below show how tokens are retrieved and used. In this approach, the [Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) is used instead of a traditional [Authorization Code flow](/flows/concepts/auth-code). This is because Form Post Response Mode is a simpler way to implement login when it’s your own resource you are requesting access to. + +![SPA Cookie Authentication](/media/articles/login/spa/image1.png) + +1. The user accesses a protected route using the browser, or performs some action that requires an authentication step to be initiated (such as clicking on a Login button) +2. The browser client redirects to a `/login` route on the backend, or to the protected route depending on what the user did +3. The backend constructs a request to the authorization server’s `/authorize` endpoint and redirects the browser client there +4. The user is prompted to authenticate themselves using whatever method the authorization server presents +5. The authorization server POSTs the tokens to the redirect URI as a URL-encoded form post. The backend is able to retrieve those tokens by parsing the body data. + +At this point, the user is authenticated and the backend has the required tokens. A cookie can now be created to represent this state on the client. The client browser is then redirected to a route that serves the SPA and also receives the authentication cookie. + +From now on, this cookie is traded between the client and backend when API calls are made using an AJAX call. On each request, the backend verifies if the cookie is still valid and if so, allows the request to continue. + +![Cookie Exchange Between Client & Backend](/media/articles/login/spa/image2.png) + +### Dealing with invalid or missing cookies + +When implementing this approach you'll need to handle cases where the authentication cookie is invalid or missing. The API call to the backend from the client happens in the background, so the client has to deal with any response from the server indicating the user should reauthenticate. + +In the following sample application, this case is handled in a naive way by prompting the user to reauthenticate if the API call results in a 302 Redirect result. The 302 occurs because, upon unsuccessful validation of the cookie, the server tries to redirect to the authorization endpoint of the authorization server and sends this response to the client. + +## Example: Authenticating a SPA using cookies + +The example application uses Node.js and Express to demonstrate the concepts covered above. + +### Prerequisites + +To follow along, make sure you have the [latest version of Node](https://nodejs.org/en/download/) installed. + +Once Node is installed, [download or clone the source code](https://github.com/auth0-blog/spa-cookie-demo/) and open the project folder inside a terminal window. + +```bash +// Clone the tutorial respository using SSH +git clone git@github.com:auth0-blog/spa-cookie-demo +// ... or if you use HTTPS: +git clone https://github.com/auth0-blog/spa-cookie-demo.git +// Move into the project directory +cd spa-cookie-demo +``` +The `master` branch represents the state of the application before any authentication is added. If you would like to refer to the final version of the application, `checkout` the `with-oidc` branch: +```bash +git checkout with-oidc +``` +### Initialize the Node.js application +Install the application dependencies by running `npm install` from your terminal window. To run the application, use `npm run dev`. This starts the Express server. Go to [http://localhost:3000](http://localhost:3000) in your browser to view the application. +::: note +The development server uses [`nodemon`](https://www.npmjs.com/package/nodemon), which automatically restarts whenever it detects any file changes. +::: +### Explore the application +With the application open at [http://localhost:3000](http://localhost:3000), click the **Call API** button. You should see a message displayed on the screen. +![Call API Message](/media/articles/login/spa/image3.png) +Note that you were able to make the API call without being logged in. Let's fix that by adding authentication some middleware that requires the user to authenticate before the API call can be made. +### Adding authentication middleware +Inside the terminal, run the following command to install the additional libraries: +```bash +npm install express-session express-openid-connect +``` +- [`express-openid-connect`](https://www.npmjs.com/package/express-openid-connect) — OpenID Connect middleware for Express. Creates authentication sessions and protects application routes +- [`express-session`](https://www.npmjs.com/package/express-session) — session middleware for Express; required by `express-openid-connect` +Next, open `server/index.js` and add in the middleware libraries underneath the existing `require` statements at the top of the file: +```js +// server/index.js +// Other 'require' statements... +// NEW - bring in our new middleware libraries +const { auth } = require("express-openid-connect") +const session = require("express-session") +``` +The `express-session` middleware can now be configured by adding the following code above the existing configuration for `body-parser` further down the file: +```js +// server/index.js +// Existing config for morgan +app.use(morgan("dev", { + stream: { + write: m => debug(m) + } +})) +// NEW - add this configuration for express-session +app.use( + session({ + secret: process.env.APP_SECRET || "keyboard cat", + resave: false, + saveUninitialized: true, + cookie: { + secure: process.env.NODE_ENV === "production", + httpOnly: true + } + }) +) +// Existing config for body-parser +app.use(bodyParser.urlencoded({ + extended: false +})) +``` +Finally, add in the configuration for the `express-openid-connect` middleware. The location of this is important; it should be inserted _after_ the configuration for the static file server, but _before_ the definition of the API routes. This ensures the static files can be served without requiring authentication, but the API routes are secured: +```js +// server/index.js +// Existing config for the static file server +app.use(express.static(join(__dirname, "..", "public"))) +// NEW - Configure the OpenID Connect middleware +app.use( + auth({ + required: req => req.originalUrl !== "/" + }) +) +// Existing config for the API routes +app.use("/api", require("./api")) +``` +Note that in this case, the authentication step is only applied if the request is for something other than the homepage. This lets us show some kind of UI even if the user is not logged in. We can display a "log in" button if they have not yet authenticated, or some other UI if they have. +After these changes, your server script should more-or-less look like this: +```js +require("dotenv").config() +const express = require("express") +const helmet = require("helmet") +const morgan = require("morgan") +const debug = require("debug")("app:server") +const session = require("express-session") +const bodyParser = require("body-parser") +const { + auth +} = require("express-openid-connect") +const { + join +} = require("path") +const app = express() +app.use(helmet()) +app.use(morgan("dev", { + stream: { + write: m => debug(m) + } +})) +// Set up express-session (required by express-openid-connect) +app.use( + session({ + secret: process.env.APP_SECRET || "keyboard cat", + resave: false, + saveUninitialized: true, + cookie: { + secure: process.env.NODE_ENV === "production", + httpOnly: true + } + }) +) +app.use(bodyParser.urlencoded({ + extended: false +})) +app.use(express.static(join(__dirname, "..", "public"))) +// Set up authentication middleware, only strictly required if +// the request isn't for the home page +app.use( + auth({ + required: req => req.originalUrl !== "/" + }) +) +app.use("/api", require("./api")) +app.get("/*", (req, res) => { + res.sendFile(join(__dirname, "..", "public", "index.html")) +}) +const port = process.env.PORT || 3000 +app.listen(port, () => debug("Application listening on port " + port)) +``` +### Setting up the environment +In order for the application to work with authentication, `express-openid-connect` requires some environment variables to be present. For this application, these variables can be specified in a `.env` file. +Create a `.env` file in the root of the project directory and populate it with the following: +```bash +ISSUER_BASE_URL= +CLIENT_ID= +BASE_URL=http://localhost:3000 +``` +### Setting up an Auth0 app +If you don't already have an Auth0 account, you can [sign up for a free Auth0 account here](https://auth0.com/signup). +Next, set up an Auth0 Client and API so Auth0 can interface with your app and API. +![Create App Dashboard](/media/articles/login/spa/image4.png) +1. Go to your [Auth0 Dashboard](${manage_url}) and click the [Create Application](https://manage.auth0.com/#/applications/create) button. +2. Name your new app, select **Regular Web Applications** and click the **Create** button. +3. In the **Settings** for your new Auth0 app, add `http://localhost:3000/callback` to the **Allowed Callback URLs**. +4. Add `http://localhost:3000` to the **Allowed Logout URLs**. +5. Click the **Save Changes** button. +6. If you'd like, you can [set up some social connections](${manage_url}/#/connections/social). You can then enable them for your app in the **Application** options under the **Connections** tab. The example shown in the screenshot above utilizes username/password database, Facebook, Google, and Twitter. +On the **Settings** screen, note the domain and client ID settings at the top. +![Application Settings](/media/articles/login/spa/image5.png) +These are the two values that need to be configured as part of the application. Reopen the `.env` file and set these values: +``` +ISSUER_BASE_URL=${account.namespace} +CLIENT_ID=${account.clientId} +BASE_URL=http://localhost:3000 +``` +### Running the application +With the server and environment configuration done, find your browser window that has the application open. If you've closed the browser and stopped the server, run the following from the terminal to restart the application +```bash +npm run dev +``` +Then open [http://localhost:3000](http://localhost:3000) in the browser. From a user interface perspective, the application should look the same. However, this time when the **Call API** button is clicked, you should receive a warning that the user is not logged in. Also note that you do not see the "Hello, World" message as before, since the call to the API has been rejected. +![User Is Not Logged In](/media/articles/login/spa/image6.png) +Click the "Log in now" to login. Once you have been authenticated, you'll return to the application and see an updated UI that reflects your newly-logged in state. You should be able to press the **Call API** button once more to invoke an API call to the server, and it now works! +![User Is Logged In](/media/articles/login/spa/image7.png) +You can click the "Profile" link at the top of the page to show user information retrieved from the ID token. +![User Profile](/media/articles/login/spa/image8.png) \ No newline at end of file diff --git a/fr-ca/articles/logout/_includes/_logout-endpoint.md b/fr-ca/articles/logout/_includes/_logout-endpoint.md new file mode 100644 index 0000000000..e1ee68dda9 --- /dev/null +++ b/fr-ca/articles/logout/_includes/_logout-endpoint.md @@ -0,0 +1,4 @@ +The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways: + +- Clears the Single Sign-on (SSO) cookie in Auth0. +- Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google). diff --git a/fr-ca/articles/logout/guides/logout-applications.md b/fr-ca/articles/logout/guides/logout-applications.md new file mode 100644 index 0000000000..2368fd165f --- /dev/null +++ b/fr-ca/articles/logout/guides/logout-applications.md @@ -0,0 +1,27 @@ +--- +title: Log Users Out of Applications +description: Learn how to force a user to log out of applications using the Auth0 logout endpoint. +topics: + - logout +contentType: + - how-to +useCase: + - manage-logout +--- + +# Log Users Out of Applications + +Enterprise users typically have Single Sign-on (SSO) enabled for multiple applications (e.g., SharePoint, a few .NET applications, a few Java applications, Zendesk). In this case, when users sign out, often they must be signed out for all of their applications. + +<%= include('../_includes/_logout-endpoint') %> + +Redirecting users to the logout endpoint **does not** cover the scenario where users need to be signed out of all of the applications they used. If you need to provide this functionality you will have to handle this in one of two ways: +* Have short timeouts on your local session and redirect to Auth0 at short intervals to re-authenticate. NOTE: this can be done by calling `checkSession` from the client which does this redirect in a hidden iFrame. If you take the hidden iFrame approach you need to be aware of rate limits and third-party cookie issues. +* Handle this entirely at the application level by providing your applications a way to notify all other applications when a logout occurs. + +## Keep reading + +* [Log Users Out of Auth0](/logout/guides/logout-auth0) +* [Log Users Out of Identity Providers](/logout/guides/logout-idps) +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) diff --git a/fr-ca/articles/logout/guides/logout-auth0.md b/fr-ca/articles/logout/guides/logout-auth0.md new file mode 100644 index 0000000000..638f134afd --- /dev/null +++ b/fr-ca/articles/logout/guides/logout-auth0.md @@ -0,0 +1,30 @@ +--- +title: Log Users Out of Auth0 +description: Learn how to force a user to log out of Auth0 using the Auth0 logout endpoint. +topics: + - logout +contentType: how-to +useCase: + - manage-logout +--- + +# Log Users Out of Auth0 + +The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways: + +1. **Clears the Single Sign-on (SSO) cookie in Auth0.** To force a logout, redirect the user to the following URL: + +```text +https://${account.namespace}/v2/logout +``` + +2. **Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google).** To [log the user out of both Auth0 *and* the IdP](/logout/guides/logout-idps), you must include the `federated` querystring parameter with your call to the logout endpoint. + +Redirecting the user to this URL clears all Single Sign-on (SSO) cookies set by Auth0 for the user. + +## Keep reading + +* [Log Users Out of Applications](logout/guides/logout-applications) +* [Log Users Out of Identity Providers](/logout/guides/logout-idps) +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) diff --git a/fr-ca/articles/logout/guides/logout-idps.md b/fr-ca/articles/logout/guides/logout-idps.md new file mode 100644 index 0000000000..c62112ac76 --- /dev/null +++ b/fr-ca/articles/logout/guides/logout-idps.md @@ -0,0 +1,73 @@ +--- +title: Log Users Out of Identity Providers +description: Learn how to force a user to log out of their identity provider. +topics: + - logout + - federated-logout +contentType: how-to +useCase: + - manage-logout +--- +# Log Users Out of Identity Providers + +Although this is not common practice, you can force the user to log out of their identity provider. + +For many providers, Auth0 will give you this behavior by simply having you add the `federated` query parameter to the redirect to `/v2/logout`. This will then additionally redirect the user to their identity provider and log them out there as well. + +To do this, add a `federated` querystring parameter to the logout URL: + +```text +https://${account.namespace}/v2/logout?federated +``` + +## Limitations + +There are a few limitations to federated logout to keep in mind: + +* No validation is performed on any URL provided as a value to the returnTo parameter, nor any querystring or hash information provided as part of the URL. + +* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the returnTo parameter differently and for some, it will not work. Please check your social provider's settings to determine how it will behave. + +* If you are working with social identity providers such as Google or Facebook, you must set your Client ID and Secret for these providers in the Dashboard for the logout to function properly. + +* If you are an Auth0 Enterprise user, you will typically have SSO enabled for multiple applications, for example, SharePoint, a few .NET applications, a few Java applications, Zendesk, etc. In this case, it's very common that when users sign out, this needs to happen for all of their applications. + +::: panel-warning Single logout +Redirecting users to the Auth0 `logout` endpoint does not cover all scenarios where users need to be signed out of all of the applications they use. Other than when Auth0 is using SAML, Auth0 does not natively support Single Logout. Single Logout can be achieved by having each application check the active session after their tokens expire, or you can force log out by terminating your application sessions at the application level. + +You can configure Single Logout URLs for SAML that can log out of all SAML sessions, although Auth0 supports front-channel SAML SLO only, Auth0 does not support back-channel SLO. +Auth0 provides quickstart guides that show you how to implement logout functionality in your specific type of application and provides sample code. These quickstarts support native/mobile apps, single-page apps, and web apps. +::: + +## Federated logout support + +The following identity providers support federated logout: + +* Evernote +* Facebook +* Fitbit +* GitHub +* Google + * Apps + * OAuth 2.0 +* Microsoft + * Active Directory Federation Services + * Office 365 + * Windows Azure Active Directory + * Windows Live +* Salesforce/Salesforce Sandbox +* Twitter +* Yahoo +* Yammer + +::: panel-warning Clear your application session +The Auth0 [logout endpoint](/api/authentication?javascript#logout) logs you out from Auth0 and, optionally, from your identity provider. It does *not* log you out of your application! This is something that you must implement on your side. You need to log out the user from your application by clearing their session. +::: + +## Keep reading + +* [Log Users Out of Auth0](/logout/guides/logout-auth0) +* [Log Users Out of Applications](logout/guides/logout-applications) +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) +* [Sessions](/sessions) diff --git a/fr-ca/articles/logout/guides/logout-saml-idps.md b/fr-ca/articles/logout/guides/logout-saml-idps.md new file mode 100644 index 0000000000..a2bf39e8c8 --- /dev/null +++ b/fr-ca/articles/logout/guides/logout-saml-idps.md @@ -0,0 +1,44 @@ +--- +title: Log Users Out of SAML Identity Providers +description: Learn how to log users out of an external SAML identity provider. +topics: + - logout + - SAML-logout + - identity-providers +contentType: how-to +useCase: + - manage-logout +--- + +# Log Users Out of SAML Identity Providers + +To logout users from an external SAML identity provider, you must configure a [SAML logout URL](/saml-sp-generic#1-obtain-information-from-idp) in the SAML connection settings. If you don't configure a logout URL, Auth0 will use the __SAML login URL__. + +Auth0 will initiate a logout by sending a SAML logout request to the external identity provider if the `federated` query string parameter is included when redirecting the user to the [logout endpoint](/api/authentication?javascript#logout). + +The external SAML identity provider will need to know where to send SAML logout requests (if initiating the logout) and responses. The __SingleLogout service URL__ that will consume this SAML messages is the following: + +```text +https://${account.namespace}/logout +``` + +When viewing the logout metadata for your Auth0 Connection, you will notice two `SingleLogoutService` bindings with the above URL. + +* **SAML Request Binding** (also known as the **Protocol Binding**): Used for the transaction from Auth0 to the IdP. If the IdP provides a choice, select `HTTP-Redirect`. + +* **SAML Response Binding**: Used for transactions from the IdP to Auth0. It indicates to Auth0 what protocol the IdP will use to respond. If the IdP provides a choice, indicate that `HTTP-POST` should be used for Authentication Assertions. + +::: panel Unable to Logout Using a SAML Identity Provider +When logging in (with Auth0 as the SAML Service Provider), the SAML identity provider uniquely identifies the user's session with a `SessionIndex` attribute in the `AuthnStatement` element of the SAML assertion. The `SessionIndex` value must be used again when the user logs out. + +Occasionally, the `SessionIndex` value may not be present in the initial login assertion. When the user logs out, the request to the SAML identity provider will fail due to the missing value. + +In these cases, Auth0 may not be able to complete a logout request to the SAML identity provider even if the logout URL has been configured correctly. +::: + +## Keep reading + +* [Log Users Out of Auth0](/logout/guides/logout-auth0) +* [Log Users Out of Applications](logout/guides/logout-applications) +* [Log Users Out of Identity Providers](/logout/guides/logout-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) diff --git a/fr-ca/articles/logout/guides/redirect-users-after-logout.md b/fr-ca/articles/logout/guides/redirect-users-after-logout.md new file mode 100644 index 0000000000..1d7fc0ad91 --- /dev/null +++ b/fr-ca/articles/logout/guides/redirect-users-after-logout.md @@ -0,0 +1,85 @@ +--- +title: Redirect Users After Logout +description: Learn how to redirect users after logout. +topics: + - logout + - redirect +contentType: how-to +useCase: + - manage-logout +--- + +# Redirect Users After Logout + +You can redirect users to a specific URL after they logout. You will need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings. + +1. Add a `returnTo` querystring parameter with the target URL as the value. Encode the target URL being passed in. For example, to redirect the user to `http://www.example.com` after logout, make the following request: + + ```text + https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com + ``` + +2. Add the non-encoded `returnTo` URL (for these examples, it is `http://www.example.com`) as an **Allowed Logout URLs** in one of two places: + + - **Tenant Settings**: For logout requests that do not include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the [Advanced tab of your Tenant Settings](${manage_url}/#/tenant/advanced). For example: + + ```text + https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com + ``` + + To add a list of URLs that the user may be redirected to after logging out at the tenant level, go to the [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced) of the Auth0 Dashboard. + + ![Tenant level logout screen](/media/articles/logout/tenant-level-logout.png) + + - **Auth0 Application Settings**: For logout requests that include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 app that is associated with the specified `CLIENT_ID`. For example: + + ```text + https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com&client_id=CLIENT_ID + ``` + + To redirect the user after they log out from a specific application, you must add the URL used in the `returnTo` parameter of the redirect URL to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 application that is associated with the `CLIENT_ID` parameter. + + ![Application level logout screen](/media/articles/logout/client-level-logout.png) + + When providing the URL list, you can: + + * Specify multiple, valid, comma-separated URLs. + * Use `*` as a [wildcard for subdomains](/applications/reference/wildcard-subdomains) (such as `http://*.example.com`). + +::: warning +If the `client_id` parameter is included and the `returnTo` URL is NOT set, the server returns the user to the first Allowed Logout URLs set in the Dashboard. +::: + +::: note +In order to avoid validation errors, make sure that you include the protocol part of the URL. For example, setting the value to `*.example.com` will result in a validation error, so you should use `http://*.example.com` instead. +::: + +## Limitations + +* The validation of URLs provided as values to the `returnTo` parameter, the querystring, and hash information provided as part of the URL are not taken into account. + +* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the `returnTo` parameter differently and for some it will not work. Please check your social provider's settings to ensure that they will accept the `returnTo` parameter and how it will behave. + +* The URLs provided in the **Allowed Logout URLs** list are case-sensitive, so the URL used for logouts must match the case of the logout URL configured on the dashboard. However, do note that the scheme and host parts are case insensitive. For example, if your URL is `http://www.Example.Com/FooHoo.html`, the `http://www.Example.Com` portion is case insensitive, while the `FooHoo.html` portion is case sensitive. + +::: note +If you are working with social identity providers such as Google or Facebook, you must set your `Client ID` and `Secret` for these providers in the [Dashboard](${manage_url}) for the logout to function properly. +::: + +## Additional requirements for Facebook + +If you are using Facebook, you will also need to encode the `returnTo` parameter. For example: + +```text +https://${account.namespace}/v2/logout?federated& + returnTo=https%3A%2F%2F${account.namespace}%2Flogout%3FreturnTo%3Dhttp%3A%2F%2Fwww.example.com + &access_token=[facebook access_token] +``` + +## Keep reading + +* [Log Users Out of Auth0](/logout/guides/logout-auth0) +* [Log Users Out of Applications](logout/guides/logout-applications) +* [Log Users Out of Identity Providers](/logout/guides/logout-idps) +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) diff --git a/fr-ca/articles/logout/index.md b/fr-ca/articles/logout/index.md new file mode 100644 index 0000000000..55c25449b5 --- /dev/null +++ b/fr-ca/articles/logout/index.md @@ -0,0 +1,64 @@ +--- +description: Understand how logout works with Auth0. +topics: + - logout +contentType: index +useCase: + - manage-logout +--- + +# Logout + +You can log a user out of the Auth0 session and (optionally) from the identity provider (IdP) session. When you're implementing the logout functionality, there are typically three session layers you need to consider: + +1. **Application Session Layer**: The first layer is the session inside your application. Though your application uses Auth0 to authenticate users, you'll still need to track that the user has logged in to your application. In a regular web application, you achieve this by storing information inside a cookie. [Log users out of your applications](/logout/guides/logout-applications) by clearing their session. You should handle the application session in your application. + +2. **Auth0 Session Layer**: Auth0 also maintains a session for the user and stores their information inside a cookie. The next time a user is redirected to the Auth0 Lock screen, the user's information will be remembered. [Log users out of Auth0](/logout/guides/logout-auth0) by clearing the Single Sign-on (SSO) cookie. + +3. **Identity Provider Session Layer**: The last session layer is the identity provider layer (for example, Facebook or Google). When users attempt to sign in with any of these providers and they are already signed into the provider, they will not be prompted again to sign in. The users may be asked to give permission to share their information with Auth0 and, in turn, your application. It is not necessary to log the users out of this session layer, but you can force the logout. (For more information, see [Log Users Out of Identity Providers](/logout/guides/logout-idps) and [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps).) + +## Quickstarts for logout functionality + +For guidance on how to implement logout functionality in your specific type of application and sample code, refer to our [Quickstarts](/quickstarts) for the following types of applications: + +### Native/Mobile Apps + +* [Android](/quickstart/native/android/03-session-handling#log-out) +* [Chrome Extension](/quickstart/native/chrome) +* [Cordova](/quickstart/native/cordova) +* [Ionic 3+](/quickstart/native/ionic3) +* [iOS Objective-C](/quickstart/native/ios-objc/03-user-sessions#on-logout-clear-the-keychain) +* [iOS Swift](/quickstart/native/ios-swift/03-user-sessions#on-logout-clear-the-keychain) + +### Single-Page Apps + +* [Angular 2+](/quickstart/spa/angular2) +* [JavaScript](/quickstart/spa/vanillajs) +* [React](/quickstart/spa/react) +* [Vue](/quickstart/spa/vuejs) + +### Web Apps + +* [ASP.NET (OWIN)](/quickstart/webapp/aspnet-owin/01-login#add-login-and-logout-methods) +* [ASP.NET Core](/quickstart/webapp/aspnet-core/01-login#add-login-and-logout-methods) +* [Java](/quickstart/webapp/java) +* [Java Spring MVC](/quickstart/webapp/java-spring-mvc) +* [Java Spring Security](/quickstart/webapp/java-spring-security-mvc) +* [NancyFX](/quickstart/webapp/nancyfx) +* [Node.js](/quickstart/webapp/nodejs) +* [PHP (Laravel)](/quickstart/webapp/laravel) +* [PHP (Symfony)](/quickstart/webapp/symfony) +* [Python](/quickstart/webapp/python#6-logout) +* [Ruby on Rails](/quickstart/webapp/rails/02-session-handling#logout-action) + +## Redirect users after logout + +After users log out, you can [redirect users](/logout/guides/redirect-users-after-logout) to a specific URL. You need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings. + +## Keep reading + +* [Log Users Out of Auth0](/logout/guides/logout-auth0) +* [Log Users Out of Applications](logout/guides/logout-applications) +* [Log Users Out of Identity Providers](/logout/guides/logout-idps) +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout) diff --git a/fr-ca/articles/logs/concepts/logs-admins-devs.md b/fr-ca/articles/logs/concepts/logs-admins-devs.md new file mode 100644 index 0000000000..802913210f --- /dev/null +++ b/fr-ca/articles/logs/concepts/logs-admins-devs.md @@ -0,0 +1,37 @@ +--- +description: Examples of how logs are used if you are an administrator or a developer. +topics: + - logs +contentType: concept +useCase: + - analyze-logs + - integrate-analytics +--- +# Administrator and Developer Log Usage Examples + +## Administrator + +If you are an administrator, there are many helpful metrics and bits of information you can gather from the Logs. If a customer has raised a support ticket that they are unable to sign in to your service or application, you can verify in the logs that they have indeed tried, and are attempting in the manner they say they are. They may think it's a password issue, but you may discover they never completed setting up their multi-factor authentication (MFA). Additionally, Logs can help expose some business metrics you may not have had available before. These could include: + +- Finding prime times of usage for different regions +- Identifying a target audience +- Detecting patterns in user behavior that can be optimized +- Identifying problematic actors by IP address +- Calculating frequency and type of Anomaly Detection triggers + + The deeper the analysis, the more you can learn about your customers and your business. + +## Developer + +When debugging an issue, or setting up an integrations, logs are as good as gold. You can utilize the logs as a history of events to see where a flow may be broken, or where customers are getting confused. You can also detect nefarious behavior, or verify that Auth0 anomaly detection is being triggered during questionable behavior. We support searching the logs for specific events using our Dashboard or Management API directly, but also support exporting logs to your existing log processing systems, like Splunk or Sumo Logic, for deeper analysis over time. See [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) for more information. + +## Keep reading + +* [Log Data Retention](/logs/references/log-data-retention) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Log Event Filters](/logs/references/log-event-filters) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) \ No newline at end of file diff --git a/fr-ca/articles/logs/guides/migrate-logs-v2-v3.md b/fr-ca/articles/logs/guides/migrate-logs-v2-v3.md new file mode 100644 index 0000000000..8c803ae79c --- /dev/null +++ b/fr-ca/articles/logs/guides/migrate-logs-v2-v3.md @@ -0,0 +1,79 @@ +--- +title: Migrate from Logs Search v2 to v3 +description: Learn how to migrate from Auth0 Logs Search v2 to v3. +topics: + - logs + - search +contentType: how-to +useCase: + - logs +--- + +# Migrate from Logs Search v2 to v3 + +To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3. +Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt-in for v3 during the provided grace period. + +## Am I affected by the migration? + +Affected customers are those who meet all of the following criteria: +* With tenants created before or on May 21st, 2019 +* With tenants hosted in Auth0's public cloud in the AU or EU regions +* Who use the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or the [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoint with the parameter `include_totals=true` or the `q` parameter. +* Who paginate through more than 1000 results +* Who use the Delegated Admin Extension + * Older versions of the extension will continue to work after your Tenant is migrated to Logs Search Engine v3, however you might notice pagination totals being incorrect when viewing logs. Updating to v3.7 of the extension will address this. + +The following tenants are NOT affected: +* Cloud customers in the US region. The US region has been fully migrated and is already using Search Engine v3. +* Private Cloud customers (Migration for Private Cloud customers will begin at a later date). +* Cloud tenants in the EU and AU regions that: + * are not using the `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` endpoints of Management API at all. + * are consuming the logs from the Dashboard Logs section only. + * are using the `GET /api/v2/logs endpoint` with the by checkpoint method (using `from` parameter). + * are consuming logs using any of the [Auth0 Logs to External Service Dashboard extensions](/extensions#export-auth0-logs-to-an-external-service) (which use the by checkpoint method). + +## How can I check to see if I've migrated all my queries? + +You can search your tenant logs with the following to look for queries that would throw errors after you migrate to v3: + +``` +type:depnote AND description:*logs* +``` + +These log entries include a `description` field that specifies the deprecated behavior you're using. You can also check the `details.request.path` and `client_name` fields to see what application is calling either `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs`. + +::: note +Auth0 generates only one log of the same **type** and **description** every 60 minutes. No matter how many calls you make using deprecated features to the impacted endpoints, you will still see a single log for *each* deprecated feature each hour. + +If you implement changes to your queries, you'll need to allow 60 minutes to elapse before you can conclusively determine that the lack of new `depnote` logs means the deprecated behavior has been removed from your code. +::: + +## What’s changing? + +The breaking changes are minor, but you should review your queries to make sure the results you are getting are as expected. + +Breaking changes are related to: +#### Pagination +* When your tenant is migrated to logs v3 the value of the `total` field returned in the summary result when calling `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` is changing. When searching for logs using search engine v2, the totals field in your results tells you the number of logs that match the query you provided. However, in v3, the totals field tells you how many logs are returned in the page (similar to what the length field returns). To avoid any potential disruption, if your application relies on the total field for pagination purposes, you should update your logic to handle this change appropriately. +* There is an existing limit of 100 logs per request. When your tenant is migrated to logs v3 you may only paginate through a maximum of 1,000 search results, resulting in calls for anything over 1,000 results returning an error. To avoid any potential disruption, you should review your queries to avoid this limit or handle errors accordingly. +#### `q` parameter validation +* The query syntax when using the `q` parameter in the `GET /api/v2/logs` has minor changes that need to be taken into account. When your tenant is migrated to logs v3 this validation will be enforced resulting in this query returning an error. To avoid any potential disruption, you should review your queries to make sure they comply with the supported query syntax. +* The `q` parameter includes an invalid field. When your tenant is migrated to logs v3 this validation will be enforced resulting in this call returning an error. To avoid any potential disruption, you should review your queries to make sure that only searchable fields are included. + +## How to Migrate? + +After reviewing your queries, you can opt-in to Tenant Logs Search Engine v3 via the Dashboard. Go to *Tenant Settings > Advanced*, then scroll down to *Migrations*. Toggle the *Legacy Logs Search V2* switch to off. +Toggling this switch to off disables the deprecated logs search engine v2 and forces the use of search engine v3. + +::: note +If you do not see the **Legacy Logs Search V2** toggle, you've already been migrated to v3. No further action is required. +::: + +![](/media/articles/logs/tenant-logs-migration.png) + +If you need help with the migration, contact us using the [Support Center](https://support.auth0.com/). + +## Keep reading + +* [Logs](/logs) diff --git a/fr-ca/articles/logs/guides/retrieve-logs-mgmt-api.md b/fr-ca/articles/logs/guides/retrieve-logs-mgmt-api.md new file mode 100644 index 0000000000..c8cec6a38d --- /dev/null +++ b/fr-ca/articles/logs/guides/retrieve-logs-mgmt-api.md @@ -0,0 +1,88 @@ +--- +description: Learn how to retrieve logs using the Auth0 Management API get_logs endpoint by checkpoint or by search criteria. +topics: + - logs +contentType: how-to +useCase: + - analyze-logs + - integrate-analytics +--- + +# Retrieve Logs Using the Management API + +You can use the Management API v2 to retrieve your logs using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, which supports two types of consumption: [by checkpoint](/logs#get-logs-by-checkpoint) or [by search criteria](#get-logs-by-search-criteria). + +::: note +We highly recommend using [the checkpoint approach](#get-logs-by-checkpoint) to export logs to the external system of your choice and perform any search or analysis there, as logs stored in our system are subject to the [retention period](/logs/references/log-data-retention). You can use any of the [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) extensions to export the logs to the system of your choice (like Sumo Logic, Splunk or Loggly). +::: + +If you would like to perform a search for specific events you can also use the [search criteria approach](#get-logs-by-search-criteria), which is also the one used by the Management Dashboard. + +::: note +When you query for logs with the [list or search logs](/api/v2#!/Logs/get_logs) endpoint, you can retrieve a maximium of 100 logs per request. +::: + +## Get logs by checkpoint + +This method allows to retrieve logs from a particular `log_id`. For searching by checkpoint use the following parameters: + +| Parameter | Description | +| -- | -- | +| `from` | Log Event Id to start retrieving logs. You can limit the amount of logs using the take parameter. | +| `take` | The total amount of entries to retrieve when using the from parameter. | + +::: note +When fetching logs by checkpoint, the `q` or any parameter other than `from` and `take` will be ignored. Also the order by date is not guaranteed. +::: + +## Get logs by search criteria + +This method retrieves log entries that match the specified search criteria (or list all entries if no criteria is used). To search by criteria use the following parameters: + +| Parameter | Description | +| -- | -- | +| `q` | Search Criteria using Query String Syntax. See [Query Syntax](/logs/references/query-syntax) for information of how to build the queries. | +| `page` | The zero-based page number. | +| `per_page` | The number of entries per page. | +| `sort` | The field to use for sorting. Use `field:order`, where `order` is `1` for ascending and `-1` for descending. For example `date:-1`. | +| `fields:` | A comma-separated field list to include or exclude (depending on `include_fields`) from the result. Leave empty to retrieve all fields. | +| `include_fields` | `true` if the fields specified are to be included in the result, `false` otherwise. Defaults to `true`. | + +For the list of fields that can be used in the search query and the `fields` and `sort` parameters, see [Query Syntax: Searcheable fields](logs/references/query-syntax#searchable-fields). + +## Limitations + +Besides the limitation of 100 logs per request to retrieve logs, you may only paginate through up to 1,000 search results. + +If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search. + +::: panel Private Cloud Users +For Private Cloud users searching tenant logs, note that only the following fields are searchable at this time: + +* `user` +* `connection` +* `application` +* `type` +* `ip` + +Use double quotes for exact searches (e.g., `application:"test"` will search for all log entries specific to the application named `test`, but `application:test` will search log entries for applications with test in their name. +::: + +## Other log endpoints + +As an alternative or complement to retrieving logs by checkpoint or search criteria using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, you can also use the following endpoints to look for logs: + +* [/api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id): Retrieves the single log entry associated with the provided log id. +* [/api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user): Retrieves log events for a specific user id. + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [Log Data Retention](/logs/references/log-data-retention) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection) +* [Log Event Filters](/logs/references/log-event-filters) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) +* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization) \ No newline at end of file diff --git a/fr-ca/articles/logs/guides/view-log-data-dashboard.md b/fr-ca/articles/logs/guides/view-log-data-dashboard.md new file mode 100644 index 0000000000..fc0cbcaa41 --- /dev/null +++ b/fr-ca/articles/logs/guides/view-log-data-dashboard.md @@ -0,0 +1,32 @@ +--- +description: Learn how to view log data in the Auth0 Dashboard for all events that occur including user authentication and administrative actions such as adding and updating applications, connections, and rules. +topics: + - logs +contentType: how-to +useCase: + - analyze-logs + - integrate-analytics +--- +# View Log Data in the Dashboard + +The **Logs** page of the [Dashboard](${manage_url}/#/logs) displays all events that occur, including user authentication and administrative actions such as adding/updating Applications, Connections, and Rules. + +![Log Search](/media/articles/logs/dashboard-logs.png) + +Please note that administrative actions will show up in the logs as `API Operation` events. + +## Event type filters + +You can choose a [filter](/logs/references/log-event-filters) for log error, warning, and success events. For example, you can choose the **Deprecation Notice** warning to filter logs related to deprecation warnings. + +![Log Event Filter](/media/articles/logs/log-event-filter.png) + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [Log Data Retention](/logs/references/log-data-retention) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) +* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization) \ No newline at end of file diff --git a/fr-ca/articles/logs/index.md b/fr-ca/articles/logs/index.md new file mode 100644 index 0000000000..b8a85708f2 --- /dev/null +++ b/fr-ca/articles/logs/index.md @@ -0,0 +1,29 @@ +--- +description: Understand how Auth0 logs work. +url: /logs +classes: topic-page +topics: + - logs +contentType: index +useCase: + - analyze-logs + - integrate-analytics +--- +# Logs + +Using the [Dashboard](${manage_url}/#/logs) or the [Management API logs endpoint](/api/v2#!/Logs/get_logs), you can pull log data on actions performed by administrators using the Dashboard, operations performed via the Management API, and authentications made by your users. + +::: warning +Auth0 does not provide real-time logs for your tenant. While we do our best to index events as they arrive, you may see some delays. +::: + +<%= include('../_includes/_topic-links', { links: [ + 'logs/streams', + 'logs/references/log-data-retention', + 'logs/guides/view-log-data-dashboard', + 'logs/references/log-event-filters', + 'logs/guides/retrieve-logs-mgmt-api', + 'logs/references/log-event-type-codes', + 'logs/references/query-syntax', + 'logs/concepts/logs-admins-devs' +] }) %> diff --git a/fr-ca/articles/logs/references/log-data-retention.md b/fr-ca/articles/logs/references/log-data-retention.md new file mode 100644 index 0000000000..4ea7b2c72d --- /dev/null +++ b/fr-ca/articles/logs/references/log-data-retention.md @@ -0,0 +1,58 @@ +--- +title: Log Data Retention +description: Describes how long log data is stored depending on your Auth0 plan. +topics: + - logs + - log-data +contentType: + - reference +useCase: + - manage-logs +--- +# Log Data Retention + +Auth0 provides event logging capability and you can scan logs to identify event anomalies. Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services allows you to retain logs outside of this timeframe, and will also provide for log aggregation across your organization. + +To understand how you will use the Auth0 logs in your situation, review the log data retention period for your subscription level. + +Plan | Log Retention +-----|-------------- +Free | 2 days +Developer | 2 days +Developer Pro | 10 days +Enterprise | 30 days + +You can implement an Auth0 log data export extension to send log data to an external log analytics service. For example, you can use log files for troubleshooting and detecting intermittent errors that may be hard to find with quality assurance testing. You may also want log data in case forensic data is ever needed for security purposes. Log data can also provide comprehensive analytics to help you see patterns in usage trends and anomaly detection triggers. + +Auth0 extensions support following third-party services: + +- [Application Insights](/extensions/application-insight) +- [AWS Cloudwatch](/extensions/cloudwatch) +- [Azure Blob Storage](/extensions/azure-blob-storage) +- [Logentries](/extensions/logentries) +- [Loggly](/extensions/loggly) +- [Logstash](/extensions/logstash) +- [Mixpanel](/extensions/mixpanel) +- [Papertrail](/extensions/papertrail) +- [Sumo Logic](/extensions/sumologic) +- [Splunk](/extensions/splunk) + +You can also export logs to the following services using Auth0 Rules: + +* [Keen](/monitoring/guides/send-events-to-keenio) +* [Segment](/monitoring/guides/send-events-to-segment) +* [Splunk](/monitoring/guides/send-events-to-splunk) + +## Rate limits exceeded and other errors + +Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You can set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you can scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls. (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)). + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Log Event Filters](/logs/references/log-event-filters) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) \ No newline at end of file diff --git a/fr-ca/articles/logs/references/log-event-filters.md b/fr-ca/articles/logs/references/log-event-filters.md new file mode 100644 index 0000000000..6faa84fbf8 --- /dev/null +++ b/fr-ca/articles/logs/references/log-event-filters.md @@ -0,0 +1,148 @@ +--- +title: Log Event Filters +description: Lists the log filters for errors, warnings, and success events. +topics: + - logs + - log-data + - log-filter +contentType: + - reference +useCase: + - manage-logs + - filter-log-events +--- +# Log Event Filters + +You can filter logs for errors, warnings, and success events in the [Dashboard](${manage_url}/#/logs) when you click the **Filter** down arrow. + +## Error event filters + +| Filter | Description | +| -- | -- | +| Block Account | IP blocked for >10 failed attempts to login to single account | +| Blocked IP Address | IP blocked for >100 failed login attempts or >50 signup attempts | +| Breached password | Attempted login with a leaked password | +| Connector Offline | AD/LDAP Connector is offline | +| Device Confirmation Canceled by User | User did not confirm device | +| Error sending MFA Push Notification | Push notification for MFA failed | +| Error sending MFA SMS | SMS for MFA failed | +| Failed API Operation | Operation on API failed | +| Failed Change Email | Failed to change user email | +| Failed Change Password | Failed to change user password | +| Failed Change Password Request | Change password request failed | +| Failed Change Phone Number | Failed to change user phone number | +| Failed Change Username | Failed to change username | +| Failed Connector Provisioning | Failed to provision a AD/LDAP connector | +| Failed Delegation | Failed to generate delegation token | +| Failed Exchange | Token Exchange | +| Failed Exchange | Native Socal Login | +| Failed Exchange | Authorization Code for Access Token | +| Failed Exchange | Client Credentials for Access Token | +| Failed Exchange | Password for Access Token | +| Failed Exchange | Refresh Token for Access Token | +| Failed Exchange | Password and OOB Challenge for Access Token | +| Failed Exchange | Password and OTP Challenge for Access Token | +| Failed Exchange | Password and MFA Recovery code for Access Token | +| Failed Exchange | Device Code for Access Token | +| Failed Login | User failed to login | +| Failed Login (invalid email/username) | User failed to login due to invalid username | +| Failed Login (wrong password) | User failed to login due to invalid password | +| Failed Logout | User logout failed | +| Failed Post Change Password Hook | Post-change password hook failed | +| Failed Post User Registration Hook | Post user registration hook failed | +| Failed Sending Notification | Failed to send email notification | +| Failed Signup | Sign up failed | +| Failed Silent Auth | Silent authentication failed | +| Failed User Deletion | User deletion failed | +| Failed Verification Email | Failed to send verification email | +| Failed Verification Email Request | Failed to process verification email request | +| Failed CORS | Origin is not in the Allowed Origins list for the specified application | +| Failed by Connector | AD/LDAP Connector Failure | +| Failed cross origin authentication | Cross-origin authentication failed | +| Failed device activation | Failed to activate device | +| Failed device authorization request | Device authorization request failed | +| MFA Enrollment start failed | Multi-factor authentication enroll failed | +| OTP Auth failed | One-time password authentication failed | +| OTP Auth rejected | One-time password authentication rejected | +| Rate Limit on API | Maximum number of requests to the Authentication API in given time has been reached | +| Recovery failed | Multi-factor recovery code failed | +| Second factor email failed | Email for MFA failed | +| Too Many Calls to /delegation | Rate limt exceeded to /delegation endpoint | +| Too Many Calls to /userinfo | Rate limit exceeded to /userinfo endpoint | +| Too Many Invalid Device Codes | Rate limit exceeded for invalid device codes | + +## Warning event filters + +| Filter | Description | +| -- | -- | +| Deprecation Notice | Feature is deprecated | +| Too many failures | Multi-factor OTP has failed too many times | +| Too many failures | Mutli-factor recovery code has failed too many times | +| Users import | Failed to import users | +| Warning During Login | Warnings during login | + +## Success event filters + +| Filter | Description | +| -- | -- | +| API Operation | API operation completed successfully | +| Account unblocked | User block setup by anomay detection has been released | +| Auth0 OS Update Ended | Auth0 OS update ended | +| Auth0 OS Update Started | Auth0 OS update started | +| Auth0 Update Ended | Auth0 update ended | +| Auth0 Update Launched | New version of Auth0 released | +| Auth0 Update Started | Auth0 update started | +| Code Sent | Passwordess login code has been sent | +| Code/Link Sent | Passwordless lgoin code/link has been sent | +| Configuration read | PSaaS configuration has been read | +| Configuration status checked | PSaaS configuration's status has been checked | +| Configuration updated | PSaaS configuration has been updated | +| Connector Online | AD/LDAP Connector is online and working | +| Enroll started | Multi-factor authentication enroll has started | +| MFA enrollment complete | Multi-factor authentication enroll has completed | +| MFA settings update | Mutli-factor tenant settings updated | +| Module switch | Multi-factor module switched | +| OTP Auth Succeed | One-time password authentication success | +| Push notification sent | Push notification for MFA successfully sent | +| Recovery succeed | Multi-factor recovery code succeeded authorization | +| SMS Sent | SMS for MFA sent successfully sent | +| Second factor email sent | Email for MFA successfully sent | +| Second factor started | Second factor authentication event started for MFA | +| Success Change Email | Email changed successfully | +| Success Change Password | Password changed successfully | +| Success Change Password Request | Change password request succeeded | +| Success Change Phone Number | Phone number changed successfully | +| Success Change Username | Username changed successfully | +| Success Delegation | Delegation token generated successfully | +| Success Exchange | Authorization Code for Access Token | +| Success Exchange | Client Credentials for Access Token | +| Success Exchange | Password for Access Token | +| Success Exchange | Refresh Token for Access Token | +| Success Exchange | Token Exchange | +| Success Exchange | Native Social Login | +| Success Exchange | Password and OOB Challenge for Access Token | +| Success Exchange | Password and OTP Challenge for Access Token | +| Success Exchange | Password and MFA Recovery code for Access Token | +| Success Exchange | Device Code for Access Token | +| Success Login | Successful Login | +| Success Logout | User successfully logged out | +| Success Post Change Password Hook | Post-change password hook ran successfully | +| Success Signup | Successful signup | +| Success Silent Auth | Successful silent authentication | +| Success Verification Email | Successful verification email | +| Success Verification Email Request | Successful verification email request | +| Success cross origin authentication | Successful cross-origin authentication | +| Successful User Deletion | User successfully deleted | +| Unenroll device account | Device used for second factor authentication has been unenrolled | +| Update device account | Device used for second factor authentication has been updated | +| User delete | Deleted multi-factor user account | +| Users import | Successfully imported users | + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) \ No newline at end of file diff --git a/fr-ca/articles/logs/references/log-event-type-codes.md b/fr-ca/articles/logs/references/log-event-type-codes.md new file mode 100644 index 0000000000..e7496892b8 --- /dev/null +++ b/fr-ca/articles/logs/references/log-event-type-codes.md @@ -0,0 +1,132 @@ +--- +title: Log Event Type Codes +description: Lists the event codes associated with log events. +topics: + - logs + - log-data +contentType: + - reference +useCase: + - manage-logs +--- +# Log Event Type Codes + +The following table lists the codes associated with the each log event. + +| **Event Code** | **Event** | **Event Description** | **Additional Info** | +| --- | --- | --- | --- | +| `api_limit` | Rate Limit on the Authentication API | The maximum number of requests to the Authentication API in given time has reached. | [Rate Limit Policy](/policies/rate-limits) | +| `cls` | Code/Link Sent | Passwordless login code/link has been sent | [Passwordless](/connections/passwordless) | +| `coff` | Connector Offline | AD/LDAP Connector is offline | [Active Directory/LDAP Connector](/connector) | +| `con` | Connector Online | AD/LDAP Connector is online and working | [Active Directory/LDAP Connector](/connector) | +| `cs` | Code Sent | Passwordless login code has been sent | [Passwordless](/connections/passwordless) | +| `depnote` | Deprecation Notice | | | +| `du` | Deleted User | User has been deleted. | [User Profile](/users/concepts/overview-user-profile) | +| `f` | Failed Login | | | +| `fc` | Failed by Connector | | [Active Directory/LDAP Connector](/connector) | +| `fce` | Failed Change Email | Failed to change user email | [User Profile](/users/concepts/overview-user-profile) | +| `fco` | Failed by CORS | Origin is not in the Allowed Origins list for the specified application | [Applications](/dashboard/reference/settings-application) | +| `fcoa` | Failed cross-origin authentication | | | +| `fcp` | Failed Change Password | | [Changing a User's Password](/connections/database/password-change) | +| `fcph` | Failed Post Change Password Hook | | | +| `fcpn` | Failed Change Phone Number | | [User Profile](/users/concepts/overview-user-profile) | +| `fcpr` | Failed Change Password Request | | [Changing a User's Password](/connections/database/password-change) | +| `fcpro` | Failed Connector Provisioning | Failed to provision a AD/LDAP connector | [Active Directory/LDAP Connector](/connector) | +| `fcu` | Failed Change Username | Failed to change username | [User Profile](/users/concepts/overview-user-profile) | +| `fd` | Failed Delegation | Failed to generate delegation token | [Delegation Tokens](/tokens/delegation) | +| `fdeac` | Failed Device Activation | Failed to activate device. | [Device Authorization Flow](/flows/concepts/device-auth) | +| `fdeaz` | Failed Device Authorization Request | Device authorization request failed. | [Device Authorization Flow](/flows/concepts/device-auth) | +| `fdecc` | User Canceled Device Confirmation | User did not confirm device. | [Device Authorization Flow](/flows/concepts/device-auth) | +| `fdu` | Failed User Deletion | | [User Profile](/users/concepts/overview-user-profile) | +| `feacft` | Failed Exchange | Failed to exchange authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code) +| `feccft` | Failed Exchange | Failed exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) | +| `fede` | Failed Exchange | Failed to exchange Device Code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) | +| `fens` | Failed Exchange | Failed exchange for Native Social Login | | +| `feoobft` | Failed Exchange | Failed exchange of Password and OOB Challenge for Access Token | | +| `feotpft` | Failed Exchange | Failed exchange of Password and OTP Challenge for Access Token | | +| `fepft` | Failed Exchange | Failed exchange of Password for Access Token | | +| `fercft` | Failed Exchange | Failed Exchange of Password and MFA Recovery code for Access Token | | +| `fertft` | Failed Exchange | Failed Exchange of Refresh Token for Access Token | | +| `ferrt` | Failed Exchange | Failed Exchange of Rotating Refresh Token | | +| `flo` | Failed Logout | User logout failed | [Logout](/logout) | +| `fn` | Failed Sending Notification | Failed to send email notification | [Emails](/email) | +| `fp` | Failed Login (Incorrect Password) | | | +| `fs` | Failed Signup | | | +| `fsa` | Failed Silent Auth | | | +| `fu` | Failed Login (Invalid Email/Username) | | | +| `fui` | Failed users import | Failed to import users | [User Import/Export](/extensions/user-import-export) | +| `fv` | Failed Verification Email | Failed to send verification email | [Verification Email](/email/custom#verification-email) | +| `fvr` | Failed Verification Email Request | Failed to process verification email request | [Verification Email](/email/custom#verification-email) | +| `gd_auth_failed` | MFA Auth failed | Multi-factor authentication failed. This could happen due to a wrong code entered for SMS/Voice/Email/TOTP factors, or a system failure. | [Multi-factor Authentication](/mfa) | +| `gd_auth_rejected` | MFA Auth rejected | A user rejected a Multi-factor authentication request via push-notification. | [Multi-factor Authentication](/mfa) | +| `gd_auth_succeed` | MFA Auth success | Multi-factor authentication success. | [Multi-factor Authentication](/mfa) | +| `gd_enrollment_complete` | MFA enrollment complete | A first time MFA user has successfully enrolled using one of the factors.| | +| `gd_otp_rate_limit_exceed` | Too many failures | A user, during enrollment or authentication, enters an incorrect code more than the maximum allowed number of times. Ex: A user enrolling in SMS enters the 6-digit code wrong more than 10 times in a row.| | +| `gd_recovery_failed` | Recovery failed | A user enters a wrong recovery code when attempting to authenticate. | [Multi-factor Authentication](/mfa) | +| `gd_recovery_rate_limit_exceed` | Too many failures | A user enters a wrong recovery code too many times. | [Multi-factor Authentication](/mfa) | +| `gd_recovery_succeed` | Recovery success | A user successfully authenticates with a recovery code. | [Multi-factor Authentication](/mfa) | +| `gd_send_pn` | Push notification sent | Push notification for MFA sent successfully sent. | [MFA with Push Notifications](/mfa/concepts/mfa-factors#push-notifications) | +| `gd_send_sms` | SMS sent | SMS for MFA successfully sent. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) | +| `gd_send_sms_failure` | SMS sent failures | Attempt to send SMS for MFA failed. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) | +| `gd_send_voice` | Voice call made | Voice call for MFA successfully made. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) | +| `gd_send_voice_failure` | Voice call failure | Attempt to make Voice call for MFA failed. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) | +| `gd_start_auth` | Second factor started | Second factor authentication event started for MFA. | [Multi-factor Authentication](/mfa) | +| `gd_start_enroll` | Enroll started | Multi-factor authentication enroll has started. | [Multi-factor Authentication](/mfa) | +| `gd_tenant_update` | Guardian tenant update | | [Hosted MFA Page](/universal-login/multifactor-authentication) | +| `gd_unenroll` | Unenroll device account | Device used for second factor authentication has been unenrolled. | [Multi-factor Authentication](/mfa) | +| `gd_update_device_account` | Update device account | Device used for second factor authentication has been updated. | [Multi-factor Authentication](/mfa) | +| `limit_delegation` | Too Many Calls to /delegation | Rate limit exceeded to `/delegation` endpoint | [API Rate Limit Policy](/policies/rate-limits) | +| `limit_mu` | Blocked IP Address | An IP address is blocked with 100 failed login attempts using different usernames, all with incorrect passwords in 24 hours, or 50 sign-up attempts per minute from the same IP address. | [Anomaly Detection](/anomaly-detection) | +| `limit_wc` | Blocked Account | An IP address is blocked with 10 failed login attempts into a single account from the same IP address. | [Anomaly Detection](/anomaly-detection) | +| `mfar` | MFA Required | A user has been prompted for multi-factor authentication. In the case of Adaptive MFA, details regarding the risk assessment are included. | Available in only [Resource Owner Password Flow](/flows/resource-owner-password-flow). | +| `pwd_leak` | Breached password | Someone behind the IP address: `ip` attempted to login with a leaked password. | [Anomaly Detection](/anomaly-detection) | +| `s` | Success Login | Successful login event. | | +| `sapi` | Success API Operation | | | +| `sce` | Success Change Email | | [Emails in Auth0](/email) | +| `scoa` | Success cross-origin authentication | | | +| `scp` | Success Change Password | | | +| `scph` | Success Post Change Password Hook | | | +| `scpn` | Success Change Phone Number | | | +| `scpr` | Success Change Password Request | | | +| `scu` | Success Change Username | | | +| `sd` | Success Delegation | | [Delegation Tokens](/tokens/delegation) | +| `sdu` | Success User Deletion | User successfully deleted | [User Profile](/users/concepts/overview-user-profile) | +| `seacft` | Success Exchange | Successful exchange of authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code) | +| `seccft` | Success Exchange | Successful exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) | +| `sede` | Success Exchange | Successful exchange of device code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) | +| `sens` | Success Exchange | Native Social Login | | +| `seoobft` | Success Exchange | Successful exchange of Password and OOB Challenge for Access Token | | +| `seotpft` | Success Exchange | Successful exchange of Password and OTP Challenge for Access Token | | +| `sepft` | Success Exchange | Successful exchange of Password for Access Token | | +| `sercft` | Success Exchange | Successful exchange of Password and MFA Recovery code for Access Token | | +| `sertft` | Success Exchange | Successful exchange of Refresh Token for Access Token | | +| `slo` | Success Logout | User successfully logged out | [Logout](/logout) | +| `ss` | Success Signup | | | +| `ssa` | Success Silent Auth | | | +| `sui` | Success users import | Successfully imported users | [User Import/Export](/extensions/user-import-export) | +| `sv` | Success Verification Email | | | +| `svr` | Success Verification Email Request | | | +| `ublkdu` | User login block released | User block setup by anomaly detection has been released | | +| `w` | Warnings During Login | | | + +# Managed Private Cloud Only + +These events are only generated in the [Managed Private Cloud](https://auth0.com/docs/private-cloud/managed-private-cloud) deployment model of Auth0. + +| **Event Code** | **Event** | **Event Description** | **Additional Info** | +| --- | --- | --- | --- | +| `admin_update_launch` | Auth0 Update Launched | | +| `sys_os_update_end` | Auth0 OS Update Ended | | | +| `sys_os_update_start` | Auth0 OS Update Started | | | +| `sys_update_end` | Auth0 Update Ended | | | +| `sys_update_start` | Auth0 Update Started | | | + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [Anomaly Detection](/anomaly-detection) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Log Event Filters](/logs/references/log-event-filters) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) diff --git a/fr-ca/articles/logs/references/query-syntax.md b/fr-ca/articles/logs/references/query-syntax.md new file mode 100644 index 0000000000..c8d5bfe1cb --- /dev/null +++ b/fr-ca/articles/logs/references/query-syntax.md @@ -0,0 +1,129 @@ +--- +title: Log Search Query Syntax +description: Describes search query syntax using a subset of the Lucene query syntax to refine Auth0 log searches. +toc: true +topics: + - logs + - log-management + - search + - query-syntax +contentType: + - reference +useCase: + - manage-logs +--- +# Log Search Query Syntax + +When searching for logs, you can create queries using a subset of [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) to refine your search. + +The query string is parsed into a series of terms and operators: + +* A term can be a single word such as `jane` or `smith`. +* A term can be a phrase surrounded by double quotes (`"customer log"`), which will match all words in the phrase in the same order. +* A term without a field name will only match [these selected fields](/logs/query-syntax#fields-searchable-against-bare-terms) fields. +* Multiple terms can be grouped together with parentheses to form sub-queries. +* All search fields are case sensitive. +* Operators (`AND`, `OR`, `NOT`) work on all searchable fields. + +## Searchable fields + +The following list of fields are searchable and case sensitive: + +* `log_id`: the id of the log event +* `date`: The moment when the event occurred. +* `connection`: The connection name related to the event. +* `connection_id`: The connection id related to the event. +* `client_id`: The client id related to the event +* `client_name`: The name of the client related to the event. +* `ip`: The IP address from where the request that caused the log entry originated. +* `user_id`: The user id related to the event. +* `user_name`: The user name related to the event. +* `description`: The description of the event. +* `user_agent`: The user agent that is related to the event. +* `type`: One of the [possible event types](/logs#log-data-event-listing). +* `strategy`: The connection strategy related to the event. +* `strategy_type`: The connection strategy type related to the event. +* `hostname`: the hostname that is being used for the authentication flow. + +## Fields searchable against bare terms + +If a search term is entered without a field name, it will only be searched against the following fields: + +* `user_name` +* `connection` +* `client_name` +* `type` +* `ip` +* `log_id` +* `description` + +## Exact matching + +To find exact matches, use double quotes: `description:"Username invalid"`. + +For example, to find logs with the description `Username invalid`, use `q=description:"Username invalid"`: + +## Wildcards + +Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters: `user_name:john*`. They can be used for prefix matching, for example `user_name:j*`. For other uses of wildcards (e.g. suffix matching), literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not. + +The question mark character (`?`), is currently not supported. + +For example, to find all logs for users whose usernames start with `john`, use `q=user_name:john*`: + +## Ranges + +You can use ranges in your log search queries. For inclusive ranges use square brackets: `[min TO max]`, and for exclusive ranges use curly brackets: `{min TO max}`. + +Curly and square brackets can be combined in the same range expression. You can also use wildcards within ranges. + +As an example, to find all logs from December 18, 2018 until the present, use `q=date:[2018-12-18 TO *]`. +If you'd like to search logs from the beginning of your retention period until, but not including, December 19, 2018, use `q=date:[* TO 2018-12-19}`. + +## Example queries + +Below are some examples to show the kinds of queries you can make with the Management API. + +Use Case | Query +---------|------ +Search all logs with connections that contains "Pass" | `connection:*pass*` +Search all logs for users with a user name that contains "fred" | `user_name:*fred*` +Search all logs with user id's matching exactly "123" | `user_id:"123"` +Search for all logs with a type starting with "s" | `type:s*` +Search for user names that start with "jane" and end with "smith" | `user_name:jane*smith` +Search for all logs in December 2018 | `date:[2018-12 TO 2018-01-01}` +Search for all logs from December 10, 2018 forward | `date:[2018-12-10 TO *]` +Search for all logs from January 1, 2019 at 1AM, until, but not including January 1, 2019 at 12:23:45 | `date:[2019-01-01T01:00:00 TO 2019-01-01T12:23:45}` + +## Limitations + +* If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search. +* Log fields are not tokenized , so `description:rule` will not match a description with value `Create a rule` nor `Update a rule`. Instead, use `description:*rule`. See [wildcards](#wildcards) and [exact matching](#exact-matching). +* The `.raw` field extension is not supported. Fields match the whole value that is provided and are not tokenized. +* To search for a specific value nested in the `details` field, use the path to the field (i.e., `details.request.channel:"https://manage.auth0.com/"`). Bare searches like `details:"https://manage.auth0.com/"` do not work. + +## Pagination + +When calling the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoints using the `include_totals` parameter, the result is a JSON object containing a summary of the results **and** the requested logs. The JSON object looks something like: + +```js +{ + "length": 5, + "limit": 5, + "logs": [...], + "start": 0, + "total": 5 +} +``` + +When searching for logs, the `totals` field tells you how many logs are returned in the page (similar to what the `length` field returns). + +## Keep reading + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Event Filters](/logs/references/log-event-filters) +* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge) \ No newline at end of file diff --git a/fr-ca/articles/logs/streams/amazon-eventbridge.md b/fr-ca/articles/logs/streams/amazon-eventbridge.md new file mode 100644 index 0000000000..7c9aa10283 --- /dev/null +++ b/fr-ca/articles/logs/streams/amazon-eventbridge.md @@ -0,0 +1,86 @@ +--- +title: Amazon EventBridge Log Streams +description: Learn how to create an event-driven workflow using Amazon EventBridge to send your tenant logs to the targets of your choice, such as AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks. +toc: true +topics: + - integrations + - logs + - streams + - event-streams + - aws + - eventbridge + - amazon +contentType: how-to +--- +# Amazon EventBridge Log Streams + +Amazon EventBridge is a serverless event bus that acts as an intermediary allowing you to send data from your applications to AWS services. You can create an event-driven workflow using EventBridge to send your Auth0 tenant logs to the targets of your choice (e.g., AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks). + +## Steps + +To send Auth0 events to Amazon EventBridge, you will need to: + +1. Set up a partner event source (in this case, this is Auth0) +2. Set up a partner event bus that matches incoming events with the routes to which they should be targeted +3. Set up rules to route incoming events to your choice of AWS service +4. Test the integration + +You can send events from Auth0 to AWS once you have [matched your partner event source to the partner event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-partner-event-bus.html). + +### Set up Auth0 as the partner event source + +First, you will need to set up Auth0 for use as the event source in the [Dashboard](${manage_url}). + +1. Log in to the [Auth0 Dashboard](${manage_url}). + +2. Navigate to **Logs > Streams**. + +3. Click **+ Create Stream**. + +4. Select **Amazon EventBridge**, and enter a unique name for your new Amazon EventBridge Event Stream. + +5. Create the Event Source by providing your **AWS Account ID** and **AWS Region**. Note that the region you select must match the region in which your Amazon EventBridge resides. + +6. Click **Save**. Auth0 provides you with an **Event Source Name**. Make sure to save your **Event Source Name** value because you will be providing it to AWS at a later point to complete the integration. + +### Set up event bus in AWS + +1. Go to the [Amazon EventBridge partners tab](https://console.aws.amazon.com/events/home?region=us-east-1#/partners) in your AWS account, and make sure you are in the **AWS Region** where the event source was created. + +2. Paste the **Event Source Name** in the event source search box to find the newly-created Event Source, and click on it to associate it with an Event Bus. +**Note**: The Event Source will remain in pending state until it gets associated with an Event Bus, and all the events sent to that Event Source will be dropped. + +3. Once you click on the Event Source, click **Associate with Event Bus**. + +4. Name the Event Bus the same name as the Event Source. At this point, you can specify permissions for this Event Bus or simply associate it. + +### Create EventBridge rules + +At this point, the events that you send are available on your Event Bus. However, before you can use the data you send to AWS services, you must [create rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-event-bus.html) that map those events to specific targets. + +Amazon EventBridge uses rules, which are definitions specifying how you want incoming events routed to the desired targets. Targets are the services, such as EC2 instances, Lambda functions, Kinesis streams, or ECS tasks, that process the event-driven data that they receive. Data received by targets are JSON-formatted. + +A single rule can route to one or more targets (if there are more than one, AWS processes all in parallel). + +To create a rule: + +1. Go to the [EventBridge page](https://console.aws.amazon.com/events/home?region=us-east-1#/), and click **Create rule**. + +2. Provide the name of the Event Bus, and specify your targets. + +### Test integration + +As soon as Auth0 writes the next tenant log, you should see a copy of the log Auth0 has written in JSON format at the target you defined in your EventBridge rule. + +## Delivery attempts and retries + +Auth0 events are delivered to AWS via a streaming mechanism that sends each event as it is triggered in our system. If EventBridge is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure, and you will see the failure in the **Health** tab for your log stream. + +## More on Log Streams + +::: next-steps +* [HTTP Event Log Streams](/logs/streams/http-event) +* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack) +* [Datadog Event Log Streams](/logs/streams/datadog) +* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid) +::: diff --git a/fr-ca/articles/logs/streams/azure-event-grid.md b/fr-ca/articles/logs/streams/azure-event-grid.md new file mode 100644 index 0000000000..ae1f8b63aa --- /dev/null +++ b/fr-ca/articles/logs/streams/azure-event-grid.md @@ -0,0 +1,113 @@ +--- +title: Azure Event Grid Log Streams +description: Learn how to create an event-driven workflow using Azure Event Grid and send your tenant logs anywhere within the Azure ecosystem. +toc: false +topics: + - logs + - streams + - event-streams +contentType: how-to +--- + +# Integrate Azure Event Grid with Auth0 + +Azure Event Grid is a serverless event bus that lets you send event data from any source to any destination. + +You can create event-driven workflows using Event Grid to send your Auth0 tenant logs to targets, such as Azure Functions, Event Hubs, Sentinel, and Logic Apps. + +For a full list of the event type codes that Auth0 supports, see [Log Event Type Codes](/logs/references/log-event-type-codes). + +## Send events from Auth0 to Azure Event Grid + +To send Auth0 events to Azure, you must: + +1. Enable the Event Grid resource provider. +2. Set up an event source (in this case, this is Auth0). +3. Set up an event handler, which is the app or service where the event will be sent. + +To learn more, see [Microsoft's Concepts in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/concepts). + +### Enable Event Grid resource provider + +If you haven’t previously used Event Grid, you will need to register the Event Grid resource provider. If you've used Event Grid before, skip to the next section. + +In your Azure portal: + +1. Select Subscriptions. +2. Select the subscription you’re using for Event Grid. +3. On the left menu, under **Settings**, select Resource providers. +4. Find `Microsoft.EventGrid`. +5. Select **Register**. +6. Refresh to make sure the status changes to `Registered`. + +### Set up an Auth0 event source + +Use the Auth0 Dashboard to set up Auth0 for use as an event source. + +1. Log in to the [Auth0 Dashboard](${manage_url}). +2. Navigate to **Logs > Streams**. +3. Click **+ Create Stream**. +4. Select **Azure Event Grid**, and enter a unique name for your new stream. +5. On the next screen, provide the following settings for your Event Grid stream: + +| Setting | Description | +|---------|-------------| +| Name | A unique display name to distinguish this integration from other integrations. | +| Azure Subscription ID | The unique alphanumeric string that identifies your Azure subscription. | +| Azure Region | The region in which your Azure subscription is hosted. | +| Resource Group name | The name of the Azure resource group, which allows you to manage all Azure assets within one subscription. | + +6. Click **Save**. + +#### Activate your Auth0 Partner Topic in Azure + +Activating the Auth0 topic in Azure allows events to flow from Auth0 to Azure. + +1. Log in to the [Azure Portal](https://portal.azure.com/). +2. Search `Partner Topics` at the top, and click `Event Grid Partner Topics` under services. +3. Click on the topic that matches the stream you created in your Auth0 Dashboard. +4. Confirm that the `Source` field matches your Auth0 account. +5. Click **Activate**. + +#### Subscribe to your Partner Topic + +Subscribe to an Event Grid partner topic to tell Event Grid which events to send to your event handler. + +1. On the Event Grid partner topic Overview page, select **+ Event Subscription** on the toolbar. +2. On the Create Event Subscription page: + 1. Enter a name for the event subscription. + 2. Select your desired Azure service or WebHook for the Endpoint type. + 3. Follow the instructions for the particular service. + 4. Back on the Create Event Subscription page, select Create. + +To send events to your topic, please follow the instructions in this article. + +### Set up an event handler + +Go to your Azure subscription and spin up a service that is supported as an event handler. For a full list of supported event handlers, see [Microsoft's Event Handlers in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/event-handlers). + +## Testing + +At this point, your Event Grid workflow should be complete. + +### Verify the integration + +To verify that the integration is working as expected: + +1. Log in to the [Auth0 Dashboard](${manage_url}). +2. Navigate to **Logs > Streams**. +3. Click on your Event Grid stream. +4. Once on the stream, click the **Health** tab. The stream should be active and as long as you don't see any errors, the stream is working. + +## Delivery attempts and retries + +Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will try to redeliver it up to three times. If still unsuccessful, Auth0 will log the failure to deliver, and you will be able see these failures in the Health tab for your log stream. + +## More on Log Streams + +::: next-steps +* [HTTP Event Log Streams](/logs/streams/http-event) +* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack) +* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge) +* [Datadog Event Log Streams](/logs/streams/datadog) +::: diff --git a/fr-ca/articles/logs/streams/datadog.md b/fr-ca/articles/logs/streams/datadog.md new file mode 100644 index 0000000000..6cac684506 --- /dev/null +++ b/fr-ca/articles/logs/streams/datadog.md @@ -0,0 +1,96 @@ +--- +title: Datadog Log Streams +description: Learn how to export your log events in near real-time to Datadog. +toc: false +topics: + - logs + - streams + - event-streams +contentType: how-to +--- + +# Datadog Log Streams + +Datadog is a monitoring platform for cloud applications. It brings together data from servers, containers, databases, and third-party services to make your stack entirely observable. You can use it to create monitoring, alerting, and analysis dashboards for Auth0 tenants. + +## Prerequisites + +To send Auth0 events to Datadog, you will need: + +* a `Log Management` plan with Datadog. See [Datadog plans](https://www.datadoghq.com/pricing/). +* a Datadog API Key. See below. +* your Datadog dashboard region. + +## Steps + +To send Auth0 events to Datadog, you will need to: + +1. Copy your API Key from Datadog +2. Set up an Event Stream in Auth0 + +### Copy API Key from Datadog + +1. Log in to the Datadog dashboard. +2. Navigate to **Integrations** > **APIs**. +![Integrations Dashboard](/media/articles/logs/datadog/tutorial-1.png) +3. Expand the API Keys section, and copy the API Key that you would like to use. +![API Keys Section](/media/articles/logs/datadog/tutorial-2.png) + +### Set up Event Stream in Auth0 + +1. Log in to the [Auth0 Dashboard](${manage_url}). +2. Navigate to **Logs > Streams**. +3. Click **+ Create Stream**. +4. Select **Datadog**, and enter a unique name for your new Datadog Event Stream. +5. On the next screen, provide the following settings for your Datadog Event Stream: + +| Setting | Description | +|---------|-------------| +| API Key | The Datadog API key you copied from the Datadog dashboard. | +| Region | If you are in the Datadog EU site (app.datadoghq.eu), the `Region` should be `EU`; otherwise, it should be `US`. | + +![Datadog Settings Form](/media/articles/logs/datadog/tutorial-3.png) + +6. Click **Save**. +7. You're done! When Auth0 writes the next log event, you'll receive a copy of that log event in Datadog with the `source` and `service` set to `auth0`. + +### View logs in Datadog + +1. Navigate to **Logs** > **Livetail**. +2. See Auth0 logs by setting the `source` to `auth0`. +![Datadog Logs Dashboard](/media/articles/logs/datadog/tutorial-4.png) + +## Delivery attempts and retries + +Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will retry delivering it up to three times. If still unsuccessful, Auth0 will log the failure, and you will see these failure in the **Health** tab for your log stream. + +## Enhancement to log data + +One of the unique values of Datadog as a monitoring tool, specifically when it comes to integrations, is the data enhancement they provide to ensure customers can rely on receiving specific data fields regardless of the system with which they are integrating. As part of this Auth0 Log Streaming integration, Datadog has enhanced our data. The following new fields can be found in our logs when using the Log Streaming integration with Datadog: + +| Fields | Auth0 attribute | +|---------|-------------| +| Official Log date | `data.date` | +| `network.client.ip` | `data.ip` | +| `network.client.geoip` | `data.ip` (parsed) | +| `http.useragent` | `data.user_agent` | +| `http.useragent_details` | `data.user_agent` (parsed) | +| `usr.id` | `data.user_name` | +| `usr.name` | `data.user_name` | +| `usr.email` | `data.details.request.auth.user.email` (when available) | +| `data.type` | `evt.name` | +| `message` | Event description (For a list of descriptions, see [Log Event Type Codes](/logs/references/log-event-type-codes).) | + +To learn more about Datadog transformations, see: + +* For US: [Datadog US Log Pipelines](https://app.datadoghq.com/logs/pipelines) +* For EU: [Datadog EU Log Pipelines](https://app.datadoghq.EU/logs/pipelines) + +## More on Log Streams + +::: next-steps +* [HTTP Event Log Streams](/logs/streams/http-event) +* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack) +* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge) +* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid) +::: diff --git a/fr-ca/articles/logs/streams/http-event-to-slack.md b/fr-ca/articles/logs/streams/http-event-to-slack.md new file mode 100644 index 0000000000..2b245b2d37 --- /dev/null +++ b/fr-ca/articles/logs/streams/http-event-to-slack.md @@ -0,0 +1,188 @@ +--- +title: Stream Auth0 Log Events to Slack +description: Use the HTTP Event Log Streams to send failed events to Slack. +toc: false +topics: + - logs + - streams + - event-streams + - http-event + - Slack +contentType: how-to +--- + +# Send Auth0 Failed Log Events to Slack + +This guide explains how to use [Auth0 Log Streaming](/logs/streams) to send specific logged events to Slack. The events sent in this guide include all failures (e.g., logins, signups, token exchange) and limits (e.g., rate limits, anomaly detection). + +Using this guide, you will build the following: + +![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-diagram.png) + +1. Application 1 and 2 both redirect to Auth0 to log in +2. The login for Application 2 succeeds, but the login for Application 1 fails; both events create a distinct log record +3. Both applications receive a response from Auth0 +4. These log events are sent together in a JSON payload to the custom webhook +5. The webhook filters out the successful event +6. The webhook sends the failed event to Slack + +To learn how to adjust the filter used here for different scenarios, see our [Log Event Type Codes](/logs/references/log-event-type-codes) reference. + +## What is Slack + +Slack is a business communication platform that can be extended using custom applications. Many companies, including Auth0, use Slack for general team communication as well as a notification platform. + +## Get started with Slack + +Go to [Slack API Applications](https://api.slack.com/apps), and log in to your Slack account. Follow instructions in the [Incoming Webhooks for Slack](https://slack.com/help/articles/115005265063-Incoming-Webhooks-for-Slack) guide to create a Slack endpoint that will accept the failed log events. Make sure to leave your browser tab open or copy the URL provided as you'll need that later in this guide. + +## Deploy the webhook + +You'll build a simple Express API that provides a single `/api/logs` route accepting POST requests. When any log event happens, it will be sent to this endpoint. If the request is formatted properly, the log events for failures will be parsed and sent to Slack. + + Start with a simple Express application: + +```js +// app.js +require("dotenv").config(); + +const express = require("express"); +const http = require("http"); + +const app = express(); +app.use(express.json()); + +app.post("/api/logs", require("./api/logs")); + +const port = process.env.PORT || 3000; +http.createServer(app).listen(port, () => { + console.log(`Listening on port <%= "${port}" %>`); +}); +``` + +Then add the endpoint middleware: + +```js +// api/logs/index.js +const got = require("got"); + +module.exports = async (req, res, next) => { + const { body, headers } = req; + + if (!body || !Array.isArray(body)) { + return res.sendStatus(400); + } + + if (headers.authorization !== process.env.AUTH0_LOG_STREAM_TOKEN) { + return res.sendStatus(401); + } + + const failedLogs = body.filter((log) => { + return "f" === log.data.type[0] || /limit/.test(log.data.type); + }); + + if (failedLogs.length === 0) { + return res.sendStatus(204); + } + + const reqUrl = process.env.SLACK_WEBHOOK_URL; + const reqOpts = { + json: { + attachments: failedLogs.map((log) => { + return { + pretext: "*Auth0 log alert*", + title: `<%= " ${log.data.description}" %> [type: <%= "${log.data.type}" %>]`, + color: "#ff0000", + title_link: `https://manage.auth0.com/#/logs/<%= "${log.data.log_id}" %>` + }; + }), + }, + }; + + try { + const slackResponse = await got.post(reqUrl, reqOpts); + res.status(slackResponse.statusCode); + return res.end(slackResponse.body); + } catch (error) { + next(error); + } +}; +``` + +Finally, add the NPM package file: + +```json +// package.json +{ + "dependencies": { + "dotenv": "^8.2.0", + "express": "^4.17.1", + "got": "^10.7.0" + }, + "scripts": { + "start": "node app.js", + } +} +``` + +To configure this application, you'll also need the following environment variables: + +- `SLACK_WEBHOOK_URL`: The URL provided by Slack for your incoming webhook application. +- `AUTH0_LOG_STREAM_TOKEN`: Optional, but recommended. A long, random string used to protect the endpoint from unauthorized requests. You will use this value in the Auth0 configuration steps below as well. + +If you are testing this locally or hosting this endpoint yourself, these can be saved in a `.env` file in the application's root directory. For hosting providers like Heroku, Dokku, and similar, consult the platform's documentation for the correct way to deploy these. + +Once configured locally or deployed to your host, you can test the endpoint and its connection to Slack with the following: + +```bash +npm install # If running yourself +added XX packages from XX contributors in XX.XXs + +npm start # If running yourself +Listening on port 3000 + +# Replace the Authorization header below +curl \ + --header "Authorization: AUTH0_LOG_STREAM_TOKEN_VALUE" \ + --header "Content-Type: application/json" \ + --request POST \ + --data '[{"data": {"type": "f", "description": "Test failure", "client_id": "TestClientId", "client_name": "Test Client Name", "log_id": "abc1234567890"}}]' \ + http://localhost:3000/api/logs +ok +``` + +The `ok` above signals that the request was accepted and processed correctly. In Slack, you should see the following message in the channel you configured: + +![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-message.png) + +## Configure an Auth0 log stream + +The final step is to configure Auth0 to send log events to this webhook using an HTTP event stream. + +To create a new stream poinint to your deployed Express application, follow the instructions in [HTTP Event](/logs/streams/http-event). Use the following field values: + +- **Payload URL**: URL to your deployed webhook like `https://[host domain]/api/logs` +- **Authorization Token**: Value configured above +- **Content Type**: Use "application/json" +- **Content Format**: Use "JSON Array" + +Once this is saved, your log stream is ready to use. To test, you'll need to trigger a failing log event. The simplest way to do that is to attempt to log in with an incorrect email or password. If the stream is configured correctly, you should see a Slack message saying: + +`Wrong email or password. [type: fu]` + +## Troubleshoot + +If you're not seeing the Slack message appear after several seconds, you'll need to walk down the same path a log event would: + +1. Check the Dashboard **Logs > Search** screen to make sure the record is there. +2. Check the **Health** tab for the stream ([delivery attempts and retries](/logs/streams/http-event#delivery-attempts-and-retries)). +3. If the webhook delivery is succeeding, check the logs for your deployed application. + +## More on Log Streams + +::: next-steps +* [HTTP Event Log Streams](/logs/streams/http-event) +* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge) +* [Datadog Event Log Streams](/logs/streams/datadog) +* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid) +::: diff --git a/fr-ca/articles/logs/streams/http-event.md b/fr-ca/articles/logs/streams/http-event.md new file mode 100644 index 0000000000..a12963907c --- /dev/null +++ b/fr-ca/articles/logs/streams/http-event.md @@ -0,0 +1,52 @@ +--- +title: HTTP Event Log Streams +description: HTTP Event Log Streams let you export your events in near real-time to your own server. +toc: false +topics: + - logs + - streams + - event-streams + - http-event +contentType: how-to +--- + +# HTTP Event Log Streams + +HTTP Event Log Streams let you export your log events to the server or target of your choice. When Auth0 creates a log entry for your tenant, a copy is automatically sent to a given URL via an HTTP POST request. + +If you use Amazon Web Services, Auth0 also offers an [AWS EventBridge integration](/logs/streams/amazon-eventbridge). + +See our example [HTTP Event Log Stream example using Slack](/logs/streams/http-event-to-slack). + +## Create an HTTP Event Stream + +1. Log in to the [Auth0 Dashboard](${manage_url}). +2. Navigate to **Logs > Streams**. +3. Click **+ Create Stream**. +4. Select **Custom Webhook** and enter a unique name for your new HTTP Event Stream. +5. On the next screen, provide the following settings for your HTTP Event Stream: + +| Setting | Description | +|---------|-------------| +| Name | A unique display name to distinguish this integration from other integrations | +| Payload URL | The URL where the event payloads are sent as HTTP POST requests. | +| Authorization Token | (Optional) Set in the Authorization header of the request if provided. | +| Content Type | The media type of the payload that will be delivered to the webhook. | + +![Create a new HTTP Event Log Stream](/media/articles/logs/http-event-stream.png) + +6. Click **Save**. +7. You're done! Now when Auth0 writes the next tenant log, you'll receive a copy of that log event as a POST request at the `Payload URL` you provided. + +## Delivery attempts and retries + +Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered in our system. If your server is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure to deliver in our system, and you will be able see these failures in the Health tab for your log stream. + +## More on Log Streams + +::: next-steps +* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack) +* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge) +* [Datadog Event Log Streams](/logs/streams/datadog) +* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid) +::: diff --git a/fr-ca/articles/logs/streams/index.md b/fr-ca/articles/logs/streams/index.md new file mode 100644 index 0000000000..73403ee075 --- /dev/null +++ b/fr-ca/articles/logs/streams/index.md @@ -0,0 +1,52 @@ +--- +title: Log Streams +description: Learn about using Log Streams to export your log events in near real-time. +classes: topic-page +toc: false +topics: + - logs + - streams + - event-streams +contentType: index +--- + +# Log Streams + +Log Streams let you export your log events to a target of your choice given URL or one of our integrations. With Log Streams you can: + +* export logs to a tool or service you already use +* react to events, such as changed passwords or new registrations, with your own business logic by sending log events to custom webhooks +* send events to Amazon EventBridge or Azure Event Grid + +## Log Stream Health + +You can troubleshoot potential issues with your stream by looking in the `Health` tab. + +1. Log in to the [Auth0 Dashboard](${manage_url}). +2. Navigate to **Logs > Streams**. +3. Click on a stream. +4. Select the **Health** tab. + +## Log Stream Status + +| Status | Description | +|---------|-------------| +| Active | Your stream is enabled with us, and we will attempt to deliver the next log events. | +| Paused | You have requested that we stop delivery attempts for the stream. You may click the `Resume Stream` option at any time to change the status back to `Active`. | +| Disabled | We have disabled your stream because of successive errors. You may click the `Restart Stream` option at any time to change the status back to `Active` and re-attempt delivery for this stream. | + +![Pause a Stream](/media/articles/logs/health/pause-a-stream.png) + +## Delivery Errors + +To help diagnose issues with your stream, you can see the last ten errors we encountered while attempting to deliver logs to your stream within the last 5 days. + +![Stream Errors](/media/articles/logs/health/health-errors.png) + +<%= include('../../_includes/_topic-links', { links: [ + 'logs/streams/http-event', + 'logs/streams/http-event-to-slack', + 'logs/streams/amazon-eventbridge', + 'logs/streams/datadog', + 'logs/streams/azure-event-grid' +] }) %> diff --git a/fr-ca/articles/mfa/_includes/_authenticator-before-start.md b/fr-ca/articles/mfa/_includes/_authenticator-before-start.md new file mode 100644 index 0000000000..89d496c5ea --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_authenticator-before-start.md @@ -0,0 +1,3 @@ +## Prerequisite + +Before you can use the MFA APIs, you'll need to enable the MFA grant type for your application. You can enable the MFA grant by going to [Applications > Your Application > Advanced Settings > Grant Types](${manage_url}/#/applications) and selecting MFA. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_configure-sns.md b/fr-ca/articles/mfa/_includes/_configure-sns.md new file mode 100644 index 0000000000..75d826d044 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_configure-sns.md @@ -0,0 +1,3 @@ +## Configure SNS for native apps + +For your native application to receive push notifications from Guardian, you will need to override the default SNS settings. See [Configure Push Notifications for MFA](/mfa/guides/configure-push) for details. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_enable-push-notifications.md b/fr-ca/articles/mfa/_includes/_enable-push-notifications.md new file mode 100644 index 0000000000..82be4f2aea --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_enable-push-notifications.md @@ -0,0 +1,7 @@ +## Enable Guardian push notifications + +1. To enable Guardian push notifications for your users, go to the [Multi-factor Auth](${manage_url}/#/guardian) section of the Dashboard. + +2. Toggle the **Push Notification** slider to enable it. + +![Enable Push Notifications](/media/articles/mfa/mfa-dashboard.png) \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_get_mfa_token.md b/fr-ca/articles/mfa/_includes/_get_mfa_token.md new file mode 100644 index 0000000000..eda25ae672 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_get_mfa_token.md @@ -0,0 +1,5 @@ +Depending on when you are triggering enrollment, you can obtain an access token for using the MFA API in different ways: + +- If you are enrolling during authentication, check [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate). + +- If you want to let the user enroll a factor at any moment, check [Managing MFA Enrollments](/mfa/guides/mfa-api/manage). diff --git a/fr-ca/articles/mfa/_includes/_get_mfa_token_challenge.md b/fr-ca/articles/mfa/_includes/_get_mfa_token_challenge.md new file mode 100644 index 0000000000..b0d61e66c7 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_get_mfa_token_challenge.md @@ -0,0 +1 @@ +Get an MFA token following the steps described in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_recovery_codes.md b/fr-ca/articles/mfa/_includes/_recovery_codes.md new file mode 100644 index 0000000000..e5f6ab8dc8 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_recovery_codes.md @@ -0,0 +1 @@ +If this is the first time the user is associating an authenticator, you'll notice the response includes `recovery_codes`. Recovery codes are used to access the user's account in the event that they lose access to the account or device used for their second factor authentication. These are one-time usable codes, and new ones are generated as necessary. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_request_association.md b/fr-ca/articles/mfa/_includes/_request_association.md new file mode 100644 index 0000000000..7d7ce5babc --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_request_association.md @@ -0,0 +1 @@ +Make a `POST` request to the `/mfa/associate` endpoint to enroll the user's authenticator. The Bearer Token required by this endpoint is the MFA token obtained in the previous step. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_successful_challenge.md b/fr-ca/articles/mfa/_includes/_successful_challenge.md new file mode 100644 index 0000000000..c68b5367db --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_successful_challenge.md @@ -0,0 +1,11 @@ +If the call was successful, you'll receive a response in the below format, containing the Access Token: + +``` +{ + "id_token": "eyJ...i", + "access_token": "eyJ...i", + "expires_in": 600, + "scope": "openid profile", + "token_type": "Bearer" +} +``` diff --git a/fr-ca/articles/mfa/_includes/_successful_confirmation.md b/fr-ca/articles/mfa/_includes/_successful_confirmation.md new file mode 100644 index 0000000000..1159ca96d2 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_successful_confirmation.md @@ -0,0 +1,15 @@ +If the call was successful, you'll receive a response in the below format, containing the Access Token: + +``` +{ + "id_token": "eyJ...i", + "access_token": "eyJ...i", + "expires_in": 600, + "scope": "openid profile", + "token_type": "Bearer" +} +``` + +At this point, the authenticator is fully associated and ready to be used, and you have the authentication tokens for the user. + +You can check at any point to verify whether an authenticator has been confirmed by calling the [`mfa/authenticators` endpoint](/mfa/guides/mfa-api/manage#list-authenticators). If the authenticator is confirmed, the value returned for `active` is `true`. \ No newline at end of file diff --git a/fr-ca/articles/mfa/_includes/_test-setup.md b/fr-ca/articles/mfa/_includes/_test-setup.md new file mode 100644 index 0000000000..ea25a2a065 --- /dev/null +++ b/fr-ca/articles/mfa/_includes/_test-setup.md @@ -0,0 +1,3 @@ +::: warning +The following steps will add text-message-based multi-factor to the login flow for the tenant in which you're working. We **highly** recommend testing this setup on a [staging or development server](/dev-lifecycle/setting-up-env) before making the changes to your production login flow. +::: \ No newline at end of file diff --git a/fr-ca/articles/mfa/concepts/guardian.md b/fr-ca/articles/mfa/concepts/guardian.md new file mode 100644 index 0000000000..65d97d5a10 --- /dev/null +++ b/fr-ca/articles/mfa/concepts/guardian.md @@ -0,0 +1,96 @@ +--- +title: Auth0 Guardian +description: Understand how Guardian works and how Guardian SDK helps you build your own authenticator and Guardian-like applications. +topics: + - mfa + - guardian + - android + - iOS +contentType: + - concept +useCase: + - customize-mfa +--- +# Auth0 Guardian + +Auth0 multi-factor authentication (MFA) supports these authentication factors: + +* One-time password (OTP) +* SMS +* Voice +* Push +* Duo +* Email + +Auth0 Guardian is a mobile app that can deliver push notifications to a user’s pre-registered device - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the press of a button. It can also generate one-time passwords if that factor is preferred. + +The push factor is offered with the Guardian mobile app, available for both iOS and Android. In addition, the technology is also available as whitelabelled Guardian SDK which can be used in custom mobile applications to act as second factor push responder. + +Auth0 Guardian is available on ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) and the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833?mt=8)). + +::: note +See the documentation for [Apple Push Notification service (APNs)](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html) for details on setting up APNs. +::: + +## How it works + +Instead of integrating with each vendor-specific push notification service, Auth0 push notification is implemented using AWS Simple Notification Service (SNS) which handles the vendor specific integration. + +![Guardian Functionality](/media/articles/mfa/guardian-functionality.png) + +## Guardian and push notifications + +When enabling push, end-users will need to have Auth0 Guardian or a custom application built with the Guardian SDK installed in their device. The app is sent push notifications when the user attempts to authenticate, and the user must respond to it in order to login, ensuring that they not only know their login information but also possess the device set up for MFA. + +End users will be prompted to download Auth0 Guardian when trying to sign up or log in to your application. Once they indicate that they have successfully downloaded the app, a QR code will appear on screen. They will have a short amount of time in which to scan the code with the designated app. Once this is done, they should see a confirmation screen. + +Once this is all set up, when the user attempts to authenticate as normal, their device will receive a push notification via the app, and once they approve the request, they will be logged in. + +
Guardian Push
+ +## Guardian and One-Time Passwords + +![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png) + +Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. + +Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code: + +
Google Authenticator OTP
+ +And enter the code at the prompt: + +![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png) + +Your users will need to have an OTP Authenticator app installed in their mobile devices. + +## Guardian SDKs + +You can [install the Guardian SDK](/mfa/guides/guardian/install-guardian-sdk), available for [iOS](/mfa/guides/guardian/configure-guardian-ios) and [Android](/mfa/guides/guardian/configure-guardian-android) to build your own whitelabel multi-factor authentication application with complete control over the branding and look-and-feel. + +With the Guardian SDK, you can build your own custom mobile applications that works like Guardian or integrate some Guardian functionalities, such as receiving push notifications in your existing mobile applications. + +A typical scenario could be for a banking app. You can use the Guardian SDK in your existing mobile app to receive and confirm push notifications when someone performs an ATM transaction. + +See [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js) for more information. + +## Migration to Firebase Cloud Messaging + +Auth0’s Guardian SDKs for iOS and Android help you create custom mobile apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. + +The [Android SDK](/mfa/guides/guardian/guardian-android-sdk) library was built to send push notifications using Google Cloud Messaging, which [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced with Firebase Cloud Messaging. Google Cloud Messaging will stop working on April 11th 2019. **Note that existing applications should [keep working as-is](https://aws.amazon.com/blogs/messaging-and-targeting/the-end-of-google-cloud-messaging-and-what-it-means-for-your-apps/)**. + +You can learn more about how to migrate from GCM to FCM by following [Google’s documentation](https://developers.google.com/cloud-messaging/android/android-migrate-fcm). + +The main difference between sending notifications to GCM and to FCM is the payload received in the notification. While it was previously possible for customers using the Android SDK to adapt the payload received before calling the SDK method, we have upgraded the library to accept the new payload, making it simpler to adopt FCM. + +The Guardian Android SDK 0.4.0 version is available in Maven Central and includes this change. The sample application was also upgraded, so it can be tested by providing the google-services.json file and a guardian-url. + +## Keep reading + +* [Configure Push Notifications for MFA](/mfa/guides/configure-push) +* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket) +* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference) +* [Auth0 Management API](/api/management/v2) +* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html) +* [Getting Started with Firebase Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html) diff --git a/fr-ca/articles/mfa/concepts/mfa-api.md b/fr-ca/articles/mfa/concepts/mfa-api.md new file mode 100644 index 0000000000..6154ac2805 --- /dev/null +++ b/fr-ca/articles/mfa/concepts/mfa-api.md @@ -0,0 +1,31 @@ +--- +title: Multi-factor Authentication API +description: Overview of available multi-factor authentication APIs +topics: + - mfa + - mfa-api +contentType: + - index +useCase: + - customize-mfa +--- +# Multi-factor Authentication API + +Auth0 provides a built-in Multi-factor Authentication (MFA) enrollment and authentication flow using [Universal Login](/universal-login). + +You will need to use the MFA API in the following scenarios: + +- If you are [authenticating users with the Resource Owner Password Grant](/mfa/guides/mfa-api/authenticate). + +- If you want to build an interface to let users [manage their authentication factors](/mfa/guides/mfa-api/manage). + +<%= include('../_includes/_authenticator-before-start') %> + +## Limitations + +The MFA API is designed to work with SMS, Push via Guardian, Email, and OTP factors. It does not currently support enrolling with Duo or with the legacy 'google-authenticator' factor (Google Authenticator can still be enrolled using the OTP factor). + +## Keep reading + +* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) +* [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage) diff --git a/fr-ca/articles/mfa/concepts/mfa-developer-resources.md b/fr-ca/articles/mfa/concepts/mfa-developer-resources.md new file mode 100644 index 0000000000..735ce8aee0 --- /dev/null +++ b/fr-ca/articles/mfa/concepts/mfa-developer-resources.md @@ -0,0 +1,35 @@ +--- +description: Learn about developer resources such as the Auth0 MFA API and the Guardian SDKs for MFA. +topics: + - mfa + - guardian +contentType: + - index +useCase: + - customize-mfa +--- +# Developer Resources for Multi-factor Authentication + +Using Auth0 SDKs, you can customize your users' multi-factor authentication (MFA) experience and even build applications on top of our multi-factor capabilities. + +## MFA API + +[MFA API](/mfa/concepts/mfa-api) endpoints allow you to enforce MFA when users interact with [the Token endpoints](/api/authentication#get-token), as well enroll and manage MFA factors. + +## Customize the multi-factor authentication page + +Use the following client libraries to customize the look-and-feel of the MFA page so it matches your organization. + +* [Client library for Auth0 MFA](https://github.com/auth0/auth0-guardian.js) +* [Creating a Custom MFA Widget](https://github.com/auth0/auth0-guardian.js/tree/master/example) + +## Manage enrollments + +You can [customise the enrollment](/mfa/guides/guardian/create-enrollment-ticket) process for your users. + +## Build custom mobile applications + +Build custom _white-label_ Guardian-like applications, or add multi-factor functionality into your applications. + +* [Guardian for Android](/mfa/guides/guardian/guardian-android-sdk) +* [Guardian for iOS](/mfa/guides/guardian/guardian-ios-sdk) diff --git a/fr-ca/articles/mfa/concepts/mfa-factors.md b/fr-ca/articles/mfa/concepts/mfa-factors.md new file mode 100644 index 0000000000..26141b8f56 --- /dev/null +++ b/fr-ca/articles/mfa/concepts/mfa-factors.md @@ -0,0 +1,77 @@ +--- +description: Understand how MFA works in Auth0, the authentication factors, policies and use cases. +toc: true +topics: + - mfa +contentType: + - concept +useCase: + - customize-mfa +--- +# Multi-factor Authentication Factors + +Auth0 supports a number of different options when it comes to enabling MFA for protecting user account access. An MFA workflow is typically provided via a separate application that runs on a mobile or tablet device. + +If you don’t want your customers to have to download a separate application, Auth0 also provides an [SDK](/mfa/guides/guardian/install-guardian-sdk) that you can use to build a second factor workflow in your existing mobile device app. + +On the [Dashboard > Multifactor Auth](${manage_url}/#/mfa) page, you can select the factors to use for MFA for your tenant. + +![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png) + +Auth0 supports the following factors for implementing MFA. You must enable at least one to use MFA, but you can choose to enable and make available more than one factor if you wish. Available factors are dependent on your subscription plan. + +## Push notifications + +Send users push notifications to a their pre-registered devices - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the simple press of a button. Push factor is offered with the [Guardian](/mfa/concepts/guardian) mobile app, available for both [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk). + +## SMS notifications + +[Send users a one-time code over SMS](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating. + +## Voice notifications + +[Deliver users a one-time code through a voice call](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating. + +## One-Time passwords + +[One-Time Password (OTP)](/mfa/guides/configure-otp) allows you to use an Authenticator application in your personal device - such as Google Authenticator - that will generate a one-time password which changes over time and which can be entered as the second factor to validate a user’s account. + +## Email notifications + +You can [use email](/mfa/guides/configure-email) when you want to provide users a way to perform MFA when they don't have their phone to receive an SMS or push notification. + +## Duo Security + +[Duo](/mfa/guides/configure-cisco-duo) is a multi-faceted provider and can only be used if it's the only factor available for the user. Use your Duo account to manage MFA with Auth0. + +## Policies + +Policies determine when a user will be prompted to complete additional steps to prove they own a particular account. Use policies to define your own level of acceptable risk. You can choose between **Never** and **Always**. + +You can achieve more refined multifactor configurations (such as per application, per user, etc.) by using [Rules](/rules/references/use-cases#multi-factor-authentication). + +::: note +Rules affecting MFA take precedence over the policy configuration in the Dashboard. +::: + +## MFA use cases + +There are different ways to manage MFA depending on your environment: + +* B2B: Your customers manage MFA factors for their users. +* B2C: End users manage their own MFA factors via the My MFA Settings Page. +* B2E: You manage MFA factors for your users. + +To learn about the API endpoints you can use to build a user interface that allows users to manage MFA factors, see [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage). + +Applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources. For details, see [Step-Up Authentication](/mfa/concepts/step-up-authentication). + +You can configure a rule in **Dashboard > Rules** to define the conditions that will trigger additional authentication challenges. Use rules to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers. + +Add contextual MFA which allows you to define arbitrary conditions that will trigger additional authentication challenges to your customers for increased security, for example, geographic location (geo-fencing), address or type of network used (IP filtering), time of day, day of the week or change in the location or device being used to log in. + +## Keep reading + +* [Enable MFA](/mfa/guides/enable-mfa) +* [Configure Push Notifications for MFA](/mfa/guides/configure-push) +* [Developer Resources for Multi-factor Authentication](/mfa/concepts/mfa-developer-resources) diff --git a/fr-ca/articles/mfa/concepts/step-up-authentication.md b/fr-ca/articles/mfa/concepts/step-up-authentication.md new file mode 100644 index 0000000000..ce09fe0084 --- /dev/null +++ b/fr-ca/articles/mfa/concepts/step-up-authentication.md @@ -0,0 +1,57 @@ +--- +description: Understand how step-up authentication works for APIs and web apps to verify that the user has logged in using MFA and if not, require the user to step-up to access certain resources. +topics: + - mfa + - step-up-authentication +contentType: + - concept +useCase: + - customize-mfa +--- +# Step-up Authentication + +With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources. + +For example, Fabrikam's Intranet requires users to authenticate with their username and password to access customer data. However, a request for access to employee data (which may contain sensitive salary information) triggers a stronger authentication mechanism like multi-factor authentication (MFA). + +You can add step-up authentication to your app with Auth0's extensible multi-factor authentication support. Your app can verify that the user has logged in using multi-factor authentication (MFA) and, if not, require the user to step-up to access certain resources. + +![Step-up flow](/media/articles/mfa/step-up-flow.png) + +## Step-up Authentication for APIs + +When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens and [Rules](/rules/references/use-cases#multi-factor-authentication). + +::: note +An Access Token is a credential you can use to access an API. The actions that you can perform to that API are defined by the scopes your Access Token includes. The rules are JavaScript functions you can use to run custom logic when a user authenticates. +::: + +You can use a rule to trigger the step-up authentication mechanism (for example, prompt MFA) whenever the user requests scopes that map to sensitive resources. + +This is best explained with an example. + +A user signs into Fabrikam's web app. The standard login gives to this user the ability to interact with their API and fetch the users account list. This means that the Access Token that the application receives after the user authentication contains a scope like `read:accounts`. + +Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction. In order to perform this action, the API requires the scope `transfer:funds`. + +The Access Token that the user currently has does not include this scope and the application knows it since it knows the set of scopes it requested in the initial authentication call. + +The solution is that the application performs another authentication call, but this time it requests the required scope. The browser redirects to Auth0 and a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested. + +Once the user successfully authenticates with MFA, a new Access Token which includes the high-value scope is generated and sent. The application will pass the Access Token to the API which will discard it after verification, thereby treating it like a single-use token. + +For details and sample code, see [Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis). + +## Step-up Authentication for Web Apps + +If it is a web app that verifies the authentication level, and not an API, then you do not have an Access Token. In this case you can check if a user has logged in with MFA by reviewing the contents of their [ID Token](/tokens/concepts/id-tokens). You can then configure your application to deny access to pages with sensitive information if the ID Token indicates that the user did not log in with MFA, and use a rule to trigger the step-up authentication mechanism (for example, prompt MFA). + +For example, you might have an employee app that authenticates users with username and password, but if a user wants to access salary information, they have to provide a second factor, using for example a mobile push notification. + +You can implement this by checking the ID Token when the user tries to access that screen. If the claims show that the user has authenticated with MFA already then display the sensitive information. Otherwise, trigger authentication again, and using a rule, prompt the user to authenticate with MFA. + +For details and sample code, see [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-web-apps). + +## Keep reading + +* [Authentication policy definitions](http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#rfc.section.4) diff --git a/fr-ca/articles/mfa/guides/a.json b/fr-ca/articles/mfa/guides/a.json new file mode 100644 index 0000000000..c7a8387871 --- /dev/null +++ b/fr-ca/articles/mfa/guides/a.json @@ -0,0 +1 @@ +{ "message_types": ["sms", "voice"] } \ No newline at end of file diff --git a/fr-ca/articles/mfa/guides/configure-cisco-duo.md b/fr-ca/articles/mfa/guides/configure-cisco-duo.md new file mode 100644 index 0000000000..a47cc6ee98 --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-cisco-duo.md @@ -0,0 +1,52 @@ +--- +description: Learn how to configure Cisco Duo for MFA. +topics: + - mfa + - duo +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure Cisco Duo for MFA + +Cisco Duo is a multi-faceted authentication provider and can only be used on your Auth0 tenant if all other factors are disabled. + +## Administrative setup + +Your Duo account can be configured to support push notifications, SMS, OTP, phone callback, and more. See the [Duo documentation](https://duo.com/docs) for more details on Duo setup. + +::: note +Create an integration in Duo Security of type **Web SDK** and use those credentials to fill in the Duo settings in the Auth0 Dashboard as noted below. +::: + +When enabling Duo in the Dashboard, you will need to click on the Duo factor and fill in a few settings fields in order to link your Duo account to Auth0. + +![MFA Duo Settings](/media/articles/mfa/duo-settings.png) + +::: warning +If other factors are enabled alongside Duo, Duo will be unavailable. Duo is only available to end users when it is the **sole** factor enabled. +::: + +## MFA sessions + +Duo does not provide an option for "Remember Me" behavior, so a 30-day MFA session is hard-coded to remember a logged-in user and not prompt them every time they log in. If you wish to force end-users to log in with Duo every time, you may implement this functionality by creating a rule with `allowRememberBrowser: false` instead. + +```js +function (user, context, callback) { + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + + callback(null, user, context); +} +``` + +## End user experience + +The user will see a prompt for the second factor with Duo, listing the options you have enabled in your Duo account. + +![Duo Login](/media/articles/mfa/duo-login.png) + +Your end users can download Duo from [Google Play](https://play.google.com/store/apps/details?id=com.duosecurity.duomobile) or from the [App Store](https://itunes.apple.com/us/app/duo-mobile/id422663827?mt=8) for use as a second factor. diff --git a/fr-ca/articles/mfa/guides/configure-email.md b/fr-ca/articles/mfa/guides/configure-email.md new file mode 100644 index 0000000000..0b8c75500f --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-email.md @@ -0,0 +1,43 @@ +--- +description: Learn how to configure email as an MFA factor for users who don't have their primary factor available. +topics: + - mfa + - email +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure Email Notifications for MFA + +Using email as an MFA factor is useful when you want to provide users a way to perform MFA when they don't have their primary factor available (e.g. they don't have their phone to receive an SMS or push notification). + +You can only enable email as an MFA factor if there is already another factor enabled. Email will only be functional as a factor from Universal Login when you have the [New Universal Login Experience](/universal-login/new) enabled. + +Once Email MFA is enabled user will be prompted to complete MFA with the other enabled factor. If they have a **verified email** they will be given the option to select Email, and get an one time code in their email which they can then enter to complete MFA. + +Users do not need to explicitly enroll with email MFA. They will get be able to use it when they have a verified email. This happens when they completed the email verification flow, when the updated the email_verified field using the Management API, or when they logged-in with a connection that provides verified emails (e.g. Google). + +Note that Email is not true multi-factor authentication (MFA) as it does not represent a different factor than the password. It does not represent 'something I have' or 'something I am', but rather just another 'something I know' (the email password). It is also weaker than other factors, in that it's only as secure as the email itself (e.g. is it encrypted end-to-end?). + +## End-user experience + +After the login step, users will be prompted with the most secure enabled factor. If they select 'Try another method', and then pick Email, they will be sent an email with a six-digit code that they will need to enter to complete the authentication flow. + +![Email End User 1](/media/articles/mfa/mfa-email.png) + +## Using the MFA API + +You can explicitly enroll an email for MFA [using the MFA API](/mfa/guides/mfa-api/email). If users have a verified email and one or more explicitly enrolled emails, they'll be able to select which email they want to use to complete MFA when logging-in using Universal Login. + +## Administrative setup + +In order to set up Email, you need to enable the Email factor in the Dashboard. You will only be able to enable it if there is another factor enabled. + +![MFA Email Settings](/media/articles/mfa/email-settings.png) + +[Auth0 provides a test email provider](/email) but it only allows a limited amount of emails, so you should [configure your own email provider](/email/providers). + +## Keep reading + +* [Enroll and Challenge Email Authenticators using the MFA API](/mfa/guides/mfa-api/email) \ No newline at end of file diff --git a/fr-ca/articles/mfa/guides/configure-otp.md b/fr-ca/articles/mfa/guides/configure-otp.md new file mode 100644 index 0000000000..2ac05eb434 --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-otp.md @@ -0,0 +1,36 @@ +--- +description: Learn how to configure time-based one time passwords for MFA. +topics: + - mfa + - duo +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure One Time Passwords for MFA + +To use one time passwords as an authentication factor, users need an Authenticator app such as: + +* Authy ([Google Play](https://play.google.com/store/apps/details?id=com.authy.authy) / [App Store](https://itunes.apple.com/us/app/authy/id494168017)). +* Google Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) / [App Store](https://itunes.apple.com/us/app/google-authenticator/id388497605)). +* Auth0 Guardian ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) / [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833)). +* Microsoft Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.azure.authenticator) / [App Store](https://itunes.apple.com/us/app/microsoft-authenticator/id983156458)). + +![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png) + +Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. + +Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code: + +
Google Authenticator OTP
+ +And enter the code at the prompt: + +![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png) + +Your users will need to have an OTP Authenticator app installed in their mobile devices. + +## Keep reading + +* [Enroll and Challenge OTP Authenticators using the MFA API](/mfa/guides/mfa-api/otp) \ No newline at end of file diff --git a/fr-ca/articles/mfa/guides/configure-phone.md b/fr-ca/articles/mfa/guides/configure-phone.md new file mode 100644 index 0000000000..9b37a8fdd1 --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-phone.md @@ -0,0 +1,128 @@ +--- +title: Configure SMS and Voice Notifications for MFA +description: Learn how to configure SMS and Voice notifications for MFA. +topics: + - mfa + - twilio +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure SMS and Voice Notifications for MFA + +If you use SMS or Voice as an authentication factor, when an end user attempts to authenticate with your application, they are sent a code via SMS or Voice, which they will have to enter to complete the transaction. This implies that they both know their login credentials and are in possession of the phone number that they have registered for Multi-factor Authentication (MFA) use. + +You can configure this factor to send messages through SMS, Voice, or to let the end users choose how they want the code to be delivered. + +::: warning +- Using Voice as an MFA factor is currently a Beta feature. It should not be used in production environments. +- Voice as an MFA factor is not available when using the [Classic Universal Login Experience](/universal-login/classic). +::: + +## End user experience - Voice and SMS + +When Voice and SMS are enabled, users are given the option to enroll by getting the code sent by SMS or Voice: + +![Voice and SMS - End User](/media/articles/mfa/mfa-sms-voice.png) + +When only SMS is enabled, the flow is simpler: + +![SMS - End User](/media/articles/mfa/mfa-sms.png) + +After users are enrolled, the next time they authenticate they will get the Voice or SMS message in their registered phone. + +## Administrative setup + +![MFA Phone Message Settings](/media/articles/mfa/mfa-phone-settings.png) + +### Message Delivery Provider and Method + +To allow users to authenticate with SMS or Voice, you must enable the Phone factor and select your preferred delivery method: + +* **Auth0**: Sends the messages using Auth0's internally-configured SMS delivery provider. It can be used for evaluation and testing purposes, and there is a maximum of 100 messages per tenant during the entire tenant lifetime. New codes are not received after reaching the 100 message limit. You can't use this provider to send Voice messages. + +* **Twilio**: Sends the messages using the [Twilio Programmable SMS API](https://www.twilio.com/sms) for SMS or [Twilio Programmable Voice API](https://www.twilio.com/voice) for Voice. You will need to provide [your own Twilio credentials](#twilio-configuration). Make sure you use Twilio **Live Credentials**, not the **Test Credentials**. The test credentials are not meant to be used to send messages in a production environment. + +* **Custom**: Sends the messages by invoking the [Send Phone Message Hook](/hooks/extensibility-points/send-phone-message). + +You can also choose if you want to give users the option of getting text messages, voice calls, or both. + +### Twilio configuration + +If you choose to deliver SMS via Twilio, follow these steps to configure your SMS factor. + +![MFA Phone Settings](/media/articles/mfa/mfa-phone-twilio.png) + +1. Open an account with Twilio. You will need a [Twilio Account SID](https://www.twilio.com/help/faq/twilio-basics/what-is-an-application-sid) and a [Twilio Auth Token](https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it). These are the Twilio API credentials that Auth0 will use to send messages to your users. + + You may also need to enable permissions for your geographic region for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://www.twilio.com/console/voice/calls/geo-permissions). If you use Voice, your account needs to have a Twilio phone number enabled to make Voice calls. This can be an external phone number [verified with Twilio](https://support.twilio.com/hc/en-us/articles/223180048-Adding-a-Verified-Phone-Number-or-Caller-ID-with-Twilio) or you can purchase and set up a Twilio Phone Number from within your account. + +2. Configure the connection. Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields. + +3. Choose your **SMS Source**. + + * If you choose **Use From**, you will need to enter the **From** phone number that users will see as the sender. You may also configure this in Twilio. + + * If you choose **Use Messaging Services**, you will need to enter a [Messaging Service SID](https://www.twilio.com/docs/sms/services/services-send-messages). + + If you are using Voice, you always need to configure 'From' even if you are using 'Messaging Services' for SMS. Make sure the phone number is configured to send both SMS and Voice messages. + +5. Click **Save**. + +### Custom Phone Messaging providers + +Phone Messaging providers not currently integrated with Auth0 can be implemented by using the [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook. To learn how to do this in your MFA flow, check the examples for different providers below: + +* [Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Twilio](/mfa/send-phone-message-hook-twilio) +* [Infobip](/mfa/send-phone-message-hook-infobip) +* [TeleSign](/mfa/send-phone-message-hook-telesign) +* [Vonage](/mfa/send-phone-message-hook-vonage) +* [Esendex](/mfa/send-phone-message-hook-esendex) +* [Mitto](/mfa/send-phone-message-hook-mitto) + +## Custom SMS or Voice Notification Templates + +Optionally, you can [customize your SMS or Voice notification templates](/mfa/guides/customize-phone-messages). + +## Using the Management API to configure Voice or SMS + +You can use the Management API to configure which Message Delivery Methods are enabled by using the `/api/v2/guardian/factors/phone/message-types` endpoint. + +The `messages_types` parameter is an array that can have `["sms"]`, `["voice"]`, or `["sms", "voice"]`. You need a [Management API Token](/api/management/v2/tokens) with the `update:guardian_factors` scope as a Bearer Token to call the API: + + ```har + { + "method": "PUT", + "url": "https://${account.namespace}/api/v2/guardian/factors/phone/message-types", + "headers": [ + { "name": "Content-Type", "value": "application/json" }, + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"message_types\": [\"sms\", \"voice\"] }" + } + } +``` + +## Security Considerations + +When using any phone messaging provider, you need to be aware that attackers abusing the signup flow could cause you financial damage. + +Auth0 will limit a single user to sending up to 10 SMS or voice messages per hour. To further protect your account, you can consider: + +- Enabling [Brute Force Protection](/anomaly-detection/references/brute-force-protection-triggers-actions#100-failed-login-attempts-or-50-sign-up-attempts). Auth0 will block an IP if it attempts to do more than 50 signup requests per minute. + +- Enable [Log Streaming](/logs/streams) and create alerts using your favorite monitoring tool, when you see spikes in the number of `gd_send_voice` or `gd_send_voice_failure` [log events](/logs/references/log-event-type-codes). + +Phone Messaging providers have additional protections. If you are using Twilio, make sure you read the [Anti-Fraud Developer Guide](https://www.twilio.com/docs/usage/anti-fraud-developer-guide). We recommend that you consider the following options: + +- Limit the countries that you will send messages for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://support.twilio.com/hc/en-us/articles/223180228-International-Voice-Dialing-Geographic-Permissions-Geo-Permissions-and-How-They-Work). This is particularly useful if there are countries with a higher risk of [toll fraud](https://www.twilio.com/learn/voice-and-video/toll-fraud) or more expensive calling rates in which you do not typically do business. + +- Enable Twilio [usage triggers](https://support.twilio.com/hc/en-us/articles/223132387-Protect-your-Twilio-project-from-Fraud-with-Usage-Triggers) to protect your account against fraud and coding mistakes. + +## Keep Reading + +* [Enroll and Challenge SMS and Voice Authenticators using the MFA API](/mfa/guides/mfa-api/phone) diff --git a/fr-ca/articles/mfa/guides/configure-push.md b/fr-ca/articles/mfa/guides/configure-push.md new file mode 100644 index 0000000000..4bed2fc849 --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-push.md @@ -0,0 +1,42 @@ +--- +description: Learn how to configure push notification using Guardian SDKs for multi-factor authentication. +topics: + - mfa + - guardian-sdk + - push +contentType: + - how-to +useCase: + - configure-push-notifications +--- +# Configure Push Notifications for MFA + +Use a custom app built using the Guardian SDKs for [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk) that relies on vendor-specific push notification services. + +1. [Create an SNS Platform Application](https://console.aws.amazon.com/sns/v3/home?region=us-east-1#/mobile/push-notifications/platform-applications) using AWS Management console and note it’s ARN. + +2. Create an AWS Access Key authorized to create Platform application endpoints. Guardian automatically creates a platform application endpoint with appropriate device token as part of a successful enrollment. + +3. To receive push notifications from Guardian, it's necessary to override Guardian's default SNS settings. + + Go to the [Multi-factor Authentication](${manage_url}/#/guardian) section of the Dashboard. + +4. Toggle **Custom App** option in the **Push via Auth0 Guardian** section and set your AWS Access Key and ARN from the AWS Management Console. + + Name | Description + -----|------------ + AWS Access Key Id | Your AWS Access Key ID. + AWS Secret Access Key | Your AWS Secret Access Key. + AWS Region | Your AWS application's region. + APNS ARN | The Amazon Resource Name for your [Apple Push Notification Service](http://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html). + GCM ARN | The Amazon Resource Name for your [Firebase Cloud Messaging Service](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html). + +5. Click **SAVE**. + +## Keep reading + +* [Guardian iOS SDK](/mfa/guides/guardian/guardian-ios-sdk) +* [Guardian Android SDK](/mfa/guides/guardian/guardian-android-sdk) +* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket) +* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference) +* [Enroll and Challenge Push Authenticators using the MFA API](/mfa/guides/mfa-api/push) diff --git a/fr-ca/articles/mfa/guides/configure-step-up-apis.md b/fr-ca/articles/mfa/guides/configure-step-up-apis.md new file mode 100644 index 0000000000..8b5357dc01 --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-step-up-apis.md @@ -0,0 +1,217 @@ +--- +title: Configure Step-up Authentication for APIs +description: Learn how an API can check if a user has logged in with Multi-factor Authentication by examining their Access Token. +topics: + - mfa + - step-up-authentication + - apis +contentType: + - how-to + - concept +useCase: + - customize-mfa +--- +# Configure Step-up Authentication for APIs + +With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions. + +For instance, a user of a bankin app may be allowed to transfer money between accounts only after they have confirmed their identity using multi-factor authentication (MFA). + +When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens, and [Rules](/rules/references/use-cases#multi-factor-authentication). + +## How it works + +When an application wants to access an API's protected resources, it must provide an Access Token. The resources that it will have access to depend on the permissions that are included in the Access Token. These permissions are defined as **scopes**. + +For example, a banking API may accept two different levels of authorization: view account balance (scope `view:balance`) or transfer funds (scope `transfer:funds`). When an application asks the API to retrieve the user's balance, then the Access Token should contain the `view:balance` scope. To transfer money to another account, the Access Token should contain the `transfer:funds` scope. + +The flow for this example: + +1. The user logs in to the application using username/password authentication. The standard login gives this user the ability to interact with the API and fetch their balance. This means that the Access Token that the app receives after the user authenticates contains the `view:balance` scope. +2. The application sends a request to the API to retrieve the balance, using the Access Token as credentials. +3. The API validates the token and sends the balance info to the application, so the user can view it. +4. Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction that requires the `transfer:funds` scope. The application sends a request to the API using the same Access Token. +5. The API validates the token and denies access because the token is missing the required `transfer:funds` scope. +6. The application redirects to Auth0, where a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested. Once the user successfully authenticates with MFA, a new Access Token that includes the correct scope is generated and sent to the application as part of the response. +7. The application sends another transfer funds request using the new Access Token, which includes the `transfer:funds` scope this time. +8. The API validates the token, discards it (thereby treating it like a single-use token), and proceeds with the operation. + +## Validate Access Tokens + +Besides checking the scope, the API must perform additional validation on the Access Token. It must also: + +* verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way. + +* validate the standard claims: + + | Claim | Description | + | --- | --- | + | `exp` | Token expiration | + | `iss` | Token issuer | + | `aud` | Intended recipient of the token | + +For more information, see [Validate an Access Token: Custom API Access Tokens](/tokens/guides/validate-access-tokens#custom-api-access-tokens). + +## Sample scenario + +In the following scenario, we will learn how to implement the flow described above. + +For this example, we assume that we have already done the following: + +- [Registered an application](/applications). For this example, we'll use a single-page web app. +- [Created a database connection](${manage_url}/#/connections/database). +- [Registered the API](/apis#how-to-configure-an-api-in-auth0). During this process, we should create two scopes: `view:balance` and `transfer:funds`. +- [Enabled Multi-factor Authentication](/mfa). For this example, we'll use push notifications. + +1. Create a rule that challenges the user to authenticate with MFA when the `transfer:funds` scope is requested. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content: + + ```js + function(user, context, callback) { + + var CLIENTS_WITH_MFA = ['${account.clientId}']; + // run only for the specified clients + if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { + // ask for MFA only if scope transfer:funds was requested + if (context.request.query.scope.indexOf('transfer:funds') > -1) { + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + } + } + + callback(null, user, context); + } + ``` + + - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.) + + - The `context.request.query.scope` property contains all the scopes for which the authentication request asked. If it includes the value `transfer:funds`, then we ask for MFA by setting the `context.multifactor` property to the appropriate value. In this case, we are asking for MFA using [Push](/mfa/concepts/mfa-factors#push-notifications). + +2. Configure the app to send the appropriate authentication request to the API, depending on whether the user is attempting to perform the high-value transaction of transferring funds. Notice that the only difference between the two authentication requests (with or without MFA) is the scope. + +
+
+ +
+
+
+ 
+        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+
+
+
+ 
+        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance%20transfer:funds&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+
+
+
+
+ +| Parameter | Setting | +| --- | --- | +| `audience` | Set to the **Identifier** of your API (find it at [API Settings](${manage_url}/#/apis/)). We set ours to `https://my-banking-api`. | +| `response_type` | Set to `id_token token` so we get both an ID Token and an Access Token in the response. | +| `client_id` | Set to the Client ID of your application (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). | +| `redirect_uri` | Set to a URL in your application that Auth0 should redirect back to after authentication (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). | +| `nonce` | Set to a secure string value which will be included in the response from Auth0. This is [used to prevent token replay attacks](/api-auth/tutorials/nonce) and is required for `response_type=id_token token`. | +| `state` | Set to an opaque value that Auth0 includes when redirecting back to the application. This value must be used by the application to [prevent CSRF attacks](/protocols/oauth2/oauth-state). | + +3. Configure the API to validate the incoming token according to the steps described in the [Validate Access Tokens](#validate-access-tokens) section and check the authorized permissions. + + In this scenario, we will configure two endpoints for our API: + + - `GET /balance`: to retrieve the current balance + - `POST /transfer`: to transfer funds + + We will use `Node.js` and a number of modules: + + - [express](https://expressjs.com/): adds the Express web application framework. + - [jwks-rsa](https://github.com/auth0/node-jwks-rsa): retrieves RSA signing keys from a **JWKS** (JSON Web Key Set) endpoint. Using `expressJwtSecret`, we can generate a secret provider that will issue the right signing key to `express-jwt` based on the `kid` in the JWT header. + - [express-jwt](https://github.com/auth0/express-jwt): lets you authenticate HTTP requests using JWT tokens in your Node.js applications. It provides several functions that make working with JWTs easier. + - [express-jwt-authz](https://github.com/auth0/express-jwt-authz): checks if the Access Token contains a specific scope. + + Start with installing the dependencies: + + `npm install express express-jwt jwks-rsa express-jwt-authz --save` + + Next, define the API endpoints, create a middleware function to validate the Access Token, and secure the endpoints using that middleware. The code in your `server.js` file should look like the following sample script: + + ```js + // set dependencies + const express = require('express'); + const app = express(); + const jwt = require('express-jwt'); + const jwksRsa = require('jwks-rsa'); + const jwtAuthz = require('express-jwt-authz'); + + // Create middleware for checking the JWT + const checkJwt = jwt({ + // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint + secret: jwksRsa.expressJwtSecret({ + cache: true, + rateLimit: true, + jwksRequestsPerMinute: 5, + jwksUri: `https://${account.namespace}/.well-known/jwks.json` + }), + + // Validate the audience and the issuer + audience: 'https://my-banking-api', // replace with your API's audience, available at Dashboard > APIs + issuer: 'https://${account.namespace}/', + algorithms: [ 'RS256' ] // we are using RS256 to sign our tokens + }); + + // create retrieve balance endpoint + app.get('/balance', checkJwt, jwtAuthz(['view:balance']), function (req, res) { + // code that retrieves the user's balance and sends it back to the calling app + res.status(201).send({message: "This is the GET /balance endpoint"}); + }); + + + // create transfer funds endpoint + app.post('/transfer', checkJwt, jwtAuthz(['transfer:funds']), function (req, res) { + // code that transfers funds from one account to another + res.status(201).send({message: "This is the POST /transfer endpoint"}); + }); + + // launch the API Server at localhost:8080 + app.listen(8080); + console.log('Listening on http://localhost:8080'); + ``` + + Each time the API receives a request the following happens: + + 1. The endpoint calls the `checkJwt` middleware. + 2. `express-jwt` decodes the token and passes the request, the header, and the payload to `jwksRsa.expressJwtSecret`. + 3. `jwks-rsa` downloads all signing keys from the JWKS endpoint and checks if one of the signing keys matches the `kid` in the header of the Access Token. If none of the signing keys match the incoming `kid`, an error is thrown. If there is a match, we pass the right signing key to `express-jwt`. + 4. `express-jwt` continues its own logic to validate the signature of the token, the expiration, audience, and the issuer. + 5. `jwtAuthz` checks if the scope that the endpoint requires is part of the Access Token. + +## Keep reading + +* [Access Tokens](/tokens/concepts/access-tokens) +* [Rules Uses Cases](/rules/references/use-cases#multi-factor-authentication) +* [Scopes](/scopes) +* [Validate Access Tokens](/tokens/guides/validate-access-tokens) +* [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-for-web-apps) diff --git a/fr-ca/articles/mfa/guides/configure-step-up-web-apps.md b/fr-ca/articles/mfa/guides/configure-step-up-web-apps.md new file mode 100644 index 0000000000..af00fbc2ed --- /dev/null +++ b/fr-ca/articles/mfa/guides/configure-step-up-web-apps.md @@ -0,0 +1,167 @@ +--- +title: Configure Step-up Authentication for Web Apps +description: Learn how to check if a user has logged in your web app with Multi-factor Authentication by examining their ID Token. +topics: + - mfa + - step-up-authentication + - web-apps +contentType: + - how-to + - concept +useCase: + - customize-mfa +--- +# Configure Step-up Authentication for Web Apps + +With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions. + +For instance, a user may be allowed to access views with sensitive data or reset their password only after confirming their identity using multi-factor authentication (MFA). + +To accomplish step-up authentication for your web app, you will create a rule that challenges the user to authenticate with MFA when the web app asks for it, check the ID Token claims for MFA if the user tries to access a restricted page, and then challenge the user if MFA is not included in the claim. + +## How it works + +When a user logs in, you retrieve an [ID Token](/tokens/concepts/id-tokens), which is a JSON Web Token (JWT) that contains information relevant to the user's session in the form of claims. For this scenario, the relevant claim is `amr`, which indicates the authentication method used during login; it **must** be present in the ID Token's payload and **must** contain the value `mfa`. Because it can contain claims other than `mfa`, when validating you must both test for its existence and examine its contents for a value of `mfa`. + +::: panel Authentication Methods Reference +The `amr` claim is a JSON array of strings that indicates the authentication method used during login. Its values may include any of the pre-defined [Authentication Method Reference Values](https://tools.ietf.org/html/rfc8176). For example, the `amr` claim may contains the pre-defined value `mfa`, which indicates that the user has authenticated using MFA. +::: + +If a user attempts to access a restricted page and the token shows that the user has **not** authenticated with MFA, then you can retrigger authentication, which you have configured to trigger MFA using a rule. Once the user provides the second factor, a new ID Token that contains the `amr` claim is generated and sent to the app. + +## Validate ID Tokens for MFA + +1. Retrieve the ID Token. +2. Verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way. +3. Validate the following claims: + + | Claim | Description | + | --- | --- | + | `exp` | Token expiration | + | `iss` | Token issuer | + | `aud` | Intended recipient of the token | + | `amr` | If `amr` does not exist in the payload or does not contain the value `mfa`, the user did not log in with MFA. If `amr` exists in the payload and contains the value `mfa`, then the user did log in with MFA. | + + In the example below, you can compare the potential values included in an ID Token's payload when a user has authenticated with MFA versus when they have not. + +
+
+ +
+
+
+ 
+        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054,
+    "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor",
+    "amr": [
+        "mfa"
+    ]
+}
+        
+
+
+
+ 
+        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054
+}
+        
+
+
+
+
+ +## Sample scenario + +In the following scenario, a web app authenticates users with username and password. When users want to access a specific screen with sensitive information, such as salary data, they must authenticate with another factor, such as Guardian push notifications. + +For this example, we assume that we have already done the following: + +- [Registered an application](/applications). For this example, we'll use a regular web app. +- [Created a database connection](${manage_url}/#/connections/database). +- [Enabled Multi-factor Authentication](/mfa/guides/enable-mfa) using push notifications. + +1. Create a rule that challenges the user to authenticate with MFA when the web app requests it. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content: + + ```js + function(user, context, callback) { + + var CLIENTS_WITH_MFA = ['${account.clientId}']; + // run only for the specified clients + if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { + // ask for MFA only if the web app said so in the authentication request + if (context.request.query.acr_values === 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'){ + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + } + } + + callback(null, user, context); + } + ``` + + - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.) + + - The `context.request.query.acr_values` property contains the context class that the Authorization Server is being requested to use when processing requests from the application. It only exists when the application includes it in the authentication request. In this example, our web app will include it in the authentication request, but only when a user who has not already authenticated ith MFA tries to access salary information. When our web app includes it, it will set a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which indicates that we want the Authorization Server to require MFA, and the `context.multifactor` property value that we set in our code will specify MFA via [Push notification](/mfa/concepts/mfa-factors#push-notifications). + +2. Configure the app to check that the user has authenticated using MFA when a user tries to acces the restricted salary information page. (When a user has authenticated with MFA, the ID Token claims contain the `amr` claim with a value of `mfa`). If the user has already authenticated with MFA, then the web app will display the restricted page; otherwise, the web app will send a new authentication request that includes the `acr_values` parameter with a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which will trigger our rule. + + The web app in this scenario uses the [Authorization Code Flow](/flows/concepts/auth-code) to authenticate, so the request is as follows: + + ```text + https://${account.namespace}/authorize? + audience=https://${account.namespace}/userinfo& + scope=openid& + response_type=code& + client_id=${account.clientId}& + redirect_uri=${account.callback}& + state=YOUR_OPAQUE_VALUE& + acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor + ``` + + Once the user authenticates with MFA, the web app receives the authorization code, which must be exchanged for the new ID Token, which should now contain the `amr` claim with a value of `mfa`. To learn how to exchange the code for an ID Token, see [Add Login Using the Authorization Code Flow: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens). + +3. Validate the incoming ID Token using the steps described in the [Validate ID Tokens for MFA](#validate-id-tokens-for-mfa) section. In this scenario, we perform these validations using the [JSON Web Token Sample Code](https://github.com/auth0/node-jsonwebtoken), which verifies the token's signature (`jwt.verify`), decodes the token, checks whether the payload contains `amr`, and if so, logs the results in the console. + + ```js + const AUTH0_CLIENT_SECRET = '${account.clientSecret}'; + const jwt = require('jsonwebtoken') + + jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] }, function(err, decoded) { + if (err) { + console.log('invalid token'); + return; + } + + if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) { + console.log('You used mfa'); + return; + } + + console.log('you are not using mfa'); + }); + ``` + +## Keep reading + +* [ID Tokens](/tokens/concepts/id-tokens) +* [Rules Use Cases](/rules/references/use-cases#multi-factor-authentication) +* [JSON Web Tokens](/tokens/concepts/jwts) +* [OpenID Connect (OIDC) specification](http://openid.net/specs/openid-connect-core-1_0.html) +* [Configure Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis) diff --git a/fr-ca/articles/mfa/guides/customize-mfa-universal-login.md b/fr-ca/articles/mfa/guides/customize-mfa-universal-login.md new file mode 100644 index 0000000000..876b69c42d --- /dev/null +++ b/fr-ca/articles/mfa/guides/customize-mfa-universal-login.md @@ -0,0 +1,174 @@ +--- +description: Learn how to customize MFA pages with Universal Login branding options. +topics: + - mfa + - custom-mfa +contentType: + - how-to +useCase: + - customize-mfa +--- +# Customize Multi-Factor Authentication + +::: note +These customizations do not apply to Duo, which has its own UI. +::: + +The multi-factor authentication pages that appear to your users can be customized by adjusting the Universal Login branding options in the [Universal Login Settings](${manage_url}/#/login_settings) section. + +If you need further customization, you can also customize [the full HTML content](/universal-login/multifactor-authentication#customize-the-html-for-the-mfa-page) to reflect your organization's particular UX requirements. + +With the New Universal Login Experience, MFA is presented even more simply to the user. Once they have entered their credentials to log in, they are presented with the MFA screen. If they have no MFA factor enrolled, they will be asked to enroll, and if they do, they will be asked to present their MFA credential. + +![MFA with New UL](/media/articles/universal-login/new-ul-mfa1.png) + +Note that in addition to complying with the requested factor, a user can also click the link at the bottom and be taken to a screen which presents all available MFA factors for this application, and select another to enroll or use. + +![MFA with New UL - Select a Factor](/media/articles/universal-login/new-ul-mfa2.png) + +## Customize via Rules + +If you need to customize the multi-factor experience you are offering to your users, you may do so via custom rules configurations for multi-factor authentication. This might be needed, for example, if you wish to trigger MFA for only specific applications, or for specific users based on user metadata or on IP addresses. + +## MFA API + +Additionally, the [MFA API](/mfa/concepts/mfa-api) is available for other customized MFA requirements. + +You can configure a [rule](/rules/references/use-cases#multi-factor-authentication) in [Dashboard > Rules](${manage_url}/#/rules) for custom multi-factor authentication (MFA) processes, which allow you to define the conditions that will trigger additional authentication challenges. Rules can be used to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers. + +::: note +The MFA settings defined in rules will always take precedence over the toggles in the Multi-factor Auth section of the Dashboard. +::: + +## `provider` setting + +The `provider` setting is a way to specify whether to force MFA, and which factor to you use. The behavior is different depending if you use the Classic or the New Universal Login experience: + +| Provider | Classic Experience | New Experience | +|----------------------|:-----------------------:|------------------------:| +| any | Push, SMS or OTP using | Push, SMS, Voice, OTP or Email | +| guardian | Push, SMS or OTP using | Push, SMS, OTP or Email | +| google-authenticator | Google Authenticator | Push, SMS, OTP or Email | +| duo | Duo | Duo | + +If you are using the New Experience you can get the behavior of the Classic experience if you enable customization of the MFA login page. + +The `guardian` and `google-authenticator` options are legacy settings that are kept for backwards compatibility reasons, and should not be used moving forward. We recommend using `any`. The 'google-authenticator' option does not let users enroll a recovery code. + +Setting the `provider` to a specific option manually will override the enabled/disabled toggles in the Dashboard. The following rule will prompt the user to enroll for Duo even if other factor are enabled in the Dashboard: + +```js +function (user, context, callback) { + + // Forcing the provider to Duo programmatically + context.multifactor = { + provider: 'duo' + }; + + callback(null, user, context); +} +``` + +## Implement contextual MFA + +The exact requirements for configuring Contextual MFA will vary. Below are sample snippets you might consider using as you customize your specific solution. + +### Customize MFA for select users + +You may customize MFA to run only for users who are authenticating against specific applications in your tenant, or only for users who are marked to use MFA. To enable this behavior you need to have the "Always require Multi-factor Authentication" toggle turned off, and enable MFA using a rule for specific users or applications. + +```js +function (user, context, callback) { + + //var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID']; + // run only for the specified applications + // if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) { + // uncomment the following if clause in case you want to request a second factor only from user's that have user_metadata.use_mfa === true + // if (user.user_metadata && user.user_metadata.use_mfa){ + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + // } + //} + + callback(null, user, context); +} +``` + +If you choose to selectively apply MFA, you will need the appropriate `clientID` values, and the code will be executed as part of a [Rule](/rules) whenever a user logs in. + +More specifically, you will uncomment and populate the following line of the rule template above with the appropriate client IDs: + +`var CLIENTS_WITH_MFA = ['REPLACE_WITH_CLIENT_ID'];` + +By setting `allowRememberBrowser: false`, the user will always be prompted for MFA when they login. This prevents the browser cookie from saving the credentials and helps make logins more secure, especially from untrusted machines. + +### Change authentication request frequency + +In some scenarios you may want to avoid prompting the user for MFA each time they log in from the same browser. The default behavior is: + +- The user will be prompted for MFA every 30 days when `provider` is set to `google-authenticator` or `duo` +- The user will be able to decide if they want to skip MFA for the next 30 days when `provider` is set to other values. + +You can alter that behavior by using the `allowRememberBrowser` property: + +```JS +function (user, context, callback) { + + if (conditionIsMet()){ + context.multifactor = { + allowRememberBrowser: false, + provider: 'any' + }; + } + + callback(null, user, context); +} +``` + +Depending on the property value the behavior will be as follows: + +- `true`: when `provider` is set to `google-authenticator` or `duo`, the user will be prompted for MFA once every 30 days. For other provider values, the user will be able to decide if they want to skip MFA for the next 30 days. +- `false`: the user will be prompted for MFA each time they authenticate. + +::: note +These time values are for active users. If a user is inactive for a period of seven days or more, their cookie will expire anyway, and they will be prompted for MFA on their next login attempt, even if `allowRememberBrowser` is `true` and it has not been thirty days since their last MFA prompt. +::: + +In order to let the user skip MFA, a cookie will be stored in the user's browser. If the user has the cookie set but you still want the user to perform MFA, you have these options: + +- Set `allowRememberBrowser` to `false` +- Set `acr_values` to `http://schemas.openid.net/pape/policies/2007/06/multi-factor` when calling the `/authorize` endpoint. + +If you want to require a specific user to be prompted for MFA during their next log in, you can call the [Invalidate Remember Browser API endpoint](https://auth0.com/docs/api/management/v2#!/Users/post_invalidate_remember_browser). This is useful for situations where the user loses a trusted device. + +### Customize MFA for users outside the network + +Assuming that access to the specified network of internal IP addresses is well controlled, you can also have Auth0 request MFA from only users whose requests originate from outside the corporate network: + +```js +function (user, context, callback) { + var ipaddr = require('ipaddr.js'); + var corp_network = "192.168.1.134/26"; + + var current_ip = ipaddr.parse(context.request.ip); + if (!current_ip.match(ipaddr.parseCIDR(corp_network))) { + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + } + + callback(null, user, context); +} +``` + +## Customize MFA with social connections + +If you are using MFA after an authentication with one or more social providers, you need to use your own application `ID` and `Secret` in the connection to the provider's site in place of the default Auth0 development credentials. For instructions on how to get the credentials for each social provider, select your particular from the list at: [Identity Providers](/identityproviders). In production usage, you should always use your own credentials instead of [Auth0 devkeys](/connections/social/devkeys). + +## Keep reading + +* [Resource Owner](/mfa/guides/mfa-api/multifactor-resource-owner-password) +* [Configure Silent Authentication](/api-auth/tutorials/silent-authentication) \ No newline at end of file diff --git a/fr-ca/articles/mfa/guides/customize-phone-messages.md b/fr-ca/articles/mfa/guides/customize-phone-messages.md new file mode 100644 index 0000000000..a33701d54b --- /dev/null +++ b/fr-ca/articles/mfa/guides/customize-phone-messages.md @@ -0,0 +1,54 @@ +--- +description: Customize SMS or Voice Messages +topics: + - mfa + - guardian + - sms +contentType: + - how-to +useCase: + - customize-mfa +--- +# Customize SMS or Voice Messages + +To customize the SMS or Voice messages sent by Auth0 during enrollment or verification, do the following: + +First, go to the [Multi-factor Auth page](${manage_url}/#/mfa), then click on the **Phone** box to configure your Phone Messaging settings. + +![MFA Phone Settings](/media/articles/mfa/mfa-phone-templates.png) + +You have two fields to customize your messages: + +* **Enrollment Template**: the message sent by Auth0 during enrollment. +* **Verification Template**: the message sent by Auth0 during authentication. + +[Liquid](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) syntax is the supported templating engine to use when accessing user attributes in SMS templates. The following attributes are available: + +* `message_type`: Can be "sms" or "voice", and can be used to indicate which kind of message is being sent. +* `code`: The Enrollment/Verification code. When sending voice messages, this variable will have the value with dots between the digits (e.g. ‘1.2.3.4.5.6’), so it can be pronounced as independent digits by voice messaging providers. +* `locale`: When using the New Universal Login experience or the MFA API, it will have the the [language selected for the login flow](/universal-login/i18n). +* `requestInfo.lang`: The browser Accept-Language header (ie, `es-AR,es;q=0.8`,`en-US,en`, and so on.). It can be used for localization when using the Classic Login Experience. +* `tenant.friendlyName`: The **Friendly Name** set in [Tenant Settings](${manage_url}/#/tenant). +* `pause`: A special variable that can be used when you want to make a pause during a voice message. + +## Examples + +``` +{% if message_type == "voice" %} + {% if locale contains "fr" %} + Bonjour, vous avez demandé à recevoir un code de vérification pour vous enregister avec {{tenant.friendly_name}}. Votre code est: {{pause}} {{code}}. Je répète, votre code est: {{pause}}{{code}}. + {% elsif locale contains "es" %} + Usted ha requerido un código de verificación para inscribirse con {{tenant.friendly_name}}. Su código es: {{pause}}{{code}}. Repito, su código es: {{pause}}{{code}}. + {% else %} + Hello, you requested a verification code to enroll with {{tenant.friendly_name}}. Your code is: {{pause}}{{code}}. I repeat, your code is: {{pause}}{{code}}. + {% endif %} +{% else %} + {% if locale contains "fr" %} + {{code}} est votre code de vérification pour vous enregistrer avec {{tenant.friendly_name}}. + {% elsif locale contains "es" %} + {{code}} es su código para inscribirse con {{tenant.friendly_name}}. + {% else %} + {{code}} is your verification code to enroll with {{tenant.friendly_name}}. + {% endif %} +{% endif %} +``` diff --git a/fr-ca/articles/mfa/guides/enable-mfa.md b/fr-ca/articles/mfa/guides/enable-mfa.md new file mode 100644 index 0000000000..fc86a9e176 --- /dev/null +++ b/fr-ca/articles/mfa/guides/enable-mfa.md @@ -0,0 +1,40 @@ +--- +description: Learn how to enable MFA in the Dashboard. +topics: + - mfa +contentType: + - how-to +useCase: + - enable-mfa-dashboard +--- +# Enable Multi-Factor Authentication + +To enable MFA, you toggle on the factors (such as push notifications or SMS) you choose to enable in the Dashboard on your tenant. Next, you perform any further setup required to configure that factor, and last, you choose whether you wish to force MFA for all users or not. + +You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication), to allow MFA to only be required in specific circumstances or force a particular factor to be used. + +1. To enable the factors you require, go to [Dashboard > Multifactor Auth](${manage_url}/#/mfa). Here you will find a series of toggles for the MFA factors supported by Auth0. + +![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png) + +Any or all of these factors can be enabled simultaneously. When logging in the first time, the user will be shown the most secure factor available, but will be allowed to choose another factor to use if you have more than one factor enabled in the Dashboard. The Phone messaging and the Duo factors require further setup. You will have to click on the factor and fill in a few further settings before continuing. + +::: note +Duo will only be available to end-users as a factor if it is the only factor that is enabled. +::: + +2. Under **Policies**, next to **Require Multi-factor Auth**, choose **Always** or **Never**. If set to **Always**, users will be able to use any of the factors enabled in the Dashboard. + +3. Click **Save**. + +4. Configure your [factors](/mfa/concepts/mfa-factors). + +## Keep reading + +* [Configure Push Notifications for MFA](/mfa/guides/configure-push) +* [Configure One Time Passwords for MFA](/mfa/guides/configure-otp) +* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone) +* [Configure Email Notifications for MFA](/mfa/guides/configure-email) +* [Configure Cisco Duo](/mfa/guides/configure-cisco-duo) +* [Customize SMS or Voice Messages](/mfa/guides/customize-phone-messages) +* [Customize Multi-factor Authentication](/mfa/guides/customize-mfa-universal-login) diff --git a/fr-ca/articles/mfa/guides/guardian/create-enrollment-ticket.md b/fr-ca/articles/mfa/guides/guardian/create-enrollment-ticket.md new file mode 100644 index 0000000000..f50d2e5fef --- /dev/null +++ b/fr-ca/articles/mfa/guides/guardian/create-enrollment-ticket.md @@ -0,0 +1,134 @@ +--- +description: Learn how to create an enrollment ticket from the MFA API. +topics: + - mfa + - step-up-authentication + - api + - custom-enrollment + - tickets +contentType: + - how-to +useCase: + - customize-mfa +--- +# Create Custom Enrollment Tickets + +It is also possible to manage users' enrollments by creating _enrollment tickets_ via the [post_ticket API](/api/management/v2#!/Guardian/post_ticket). + +This API will return an _enrollment ticket_ containing a `ticket_id` and a `ticket_url`, which can be used to enroll a user. + +The `ticket_url` can be delivered to the user (for instance, via email) and used to kick off the enrollment process. + +Alternatively, the ticket can be leveraged inside the [MFA Page](${manage_url}/#/mfa_page) to customize the Auth0 MFA widget's appearance: + +```html + + + + 2nd Factor Authentication + + + + + + + +
+
+

Welcome! {{ userData.email }} enroll your device

+
+ + +
+
+
+
+ + + + + + +``` + +This custom page displays the Auth0 MFA widget in both enrollment and standard multi-factor authentication (MFA) login scenarios. You can use the ticket variable to check which scenario is in use and control the content accordingly. + +For example, the following code displays a different message depending on whether the user is enrolling or authenticating: + +```html +{% if ticket %} +

Welcome, {{ userData.email }}, enroll your device below

+{% else %} +

Welcome back, {{ userData.email }}, authenticate below

+{% endif %} +```` + +::: note +The conditional logic around the existence of the `ticket` variable is also used in the initialization of the `Auth0MFAWidget` above. +::: + +## Keep reading + +* [MFA Widget Reference](/mfa/references/mfa-widget-reference) \ No newline at end of file diff --git a/fr-ca/articles/mfa/guides/guardian/guardian-android-sdk.md b/fr-ca/articles/mfa/guides/guardian/guardian-android-sdk.md new file mode 100644 index 0000000000..48f60e38c5 --- /dev/null +++ b/fr-ca/articles/mfa/guides/guardian/guardian-android-sdk.md @@ -0,0 +1,162 @@ +--- +title: Guardian for Android SDK +description: Learn how to install, use and configure options for the Guardian for Android SDK. +topics: + - mfa + - guardian + - android +contentType: + - how-to +useCase: + - customize-mfa +--- +# Guardian for Android SDK + +The [Guardian for Android SDK](https://github.com/auth0/Guardian.Android) helps you create Android apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization. + +## Requirements + +Android API level 15+ is required in order to use the Guardian Android SDK. + +## Install Guardian Android SDK + +Guardian is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). + +1. To start using *Guardian* add these lines to your `build.gradle` dependencies file: + + ```gradle + implementation 'com.auth0.android:guardian:0.4.0' + ``` + +::: note +You can check for the latest version on the repository [Releases](https://github.com/auth0/GuardianSDK.Android/releases) tab, in [Maven](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.auth0.android%22%20AND%20a%3A%22guardian%22), or in [JCenter](https://bintray.com/auth0/android/Guardian.Android). +::: + +2. After adding your Gradle dependency, make sure to remember to sync your project with Gradle files. + +<%= include('../../_includes/_enable-push-notifications') %> + +<%= include('../../_includes/_configure-sns') %> + +## Use the SDK + +Guardian is the core of the SDK. You'll need to create an instance of this class for your specific tenant/url. + +```java +Uri url = Uri.parse("https://tenant.guardian.auth0.com/"); + +Guardian guardian = new Guardian.Builder() + .url(url) + .build(); +``` + +or + +```java +String domain = "tenant.guardian.auth0.com"; + +Guardian guardian = new Guardian.Builder() + .domain(domain) + .build(); +``` + +### Enroll + +The link between the second factor (an instance of your app on a device) and an Auth0 account is referred to as an enrollment. + +You can create an enrollment using the `Guardian.enroll` function, but first you'll have to create a new pair of RSA keys for it. The private key will be used to sign the requests to allow or reject a login. The public key will be sent during the enroll process so the server can later verify the request's signature. + +```java +KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA"); +keyPairGenerator.initialize(2048); // you MUST use at least 2048 bit keys +KeyPair keyPair = keyPairGenerator.generateKeyPair(); +``` + +Next, obtain the enrollment information by scanning the Guardian QR code, and use it to enroll the account: + +```java +Uri enrollmentUriFromQr = ...; // the URI obtained from a Guardian QR code + +CurrentDevice device = new CurrentDevice(context, "fcmToken", "deviceName"); + +Enrollment enrollment = guardian + .enroll(enrollmentUriFromQr, device, keyPair) + .execute(); +``` + +Alternatively, you can execute the request in a background thread: + +```java +guardian + .enroll(enrollmentUriFromQr, device, keyPair) + .start(new Callback { + @Override + void onSuccess(Enrollment enrollment) { + // we have the enrollment data + } + + @Override + void onFailure(Throwable exception) { + // something failed + } + }); +``` + +The `deviceName` and `fcmToken` are data that you must provide: + +- The `deviceName` is the name that you want for the enrollment. It will be displayed to the user when the second factor is required. +- The `fcmToken` is the token for Firebase Cloud Messaging push notification service. See the [docs](https://firebase.google.com/docs/cloud-messaging/android/client#sample-register) for more information about the FCM token. + +### Unenroll + +To disable multi-factor authentication you can delete the enrollment: + +```java +guardian + .delete(enrollment) + .execute(); // or start(new Callback<> ...) +``` + +### Allow a login request + +Once you have the enrollment in place, you'll receive a FCM push notification every time the user needs multi-factor authentication. + +Guardian provides a method to parse the `Map` data inside the [RemoteMessage](https://firebase.google.com/docs/reference/android/com/google/firebase/messaging/RemoteMessage) received from FCM and return a `Notification` instance ready to be used. + +```java +// at the FCM listener you receive a RemoteMessage +@Override +public void onMessageReceived(RemoteMessage message) { + Notification notification = Guardian.parseNotification(message.getData()); + if (notification != null) { + // you received a Guardian notification, handle it + handleGuardianNotification(notification); + return; + } + + /* handle other push notifications you might be using ... */ +} +``` + +Once you have the notification instance, you can approve the authentication request by using the `allow` method. You'll also need the enrollment that you obtained previously. If there are multiple enrollments, be sure to use the one that has the same `id` as the notification (the `enrollmentId` property). + +```java +guardian + .allow(notification, enrollment) + .execute(); // or start(new Callback<> ...) +``` + +### Reject a login request + +To deny an authentication request, use `reject` instead. You can also add an optional reason for the rejection, which will be available in the guardian logs. + +```java +guardian + .reject(notification, enrollment) // or reject(notification, enrollment, reason) + .execute(); // or start(new Callback<> ...) +``` + +## Keep reading + +* [Getting Started with Google Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html) +* diff --git a/fr-ca/articles/mfa/guides/guardian/guardian-ios-sdk.md b/fr-ca/articles/mfa/guides/guardian/guardian-ios-sdk.md new file mode 100644 index 0000000000..125aa8a0c3 --- /dev/null +++ b/fr-ca/articles/mfa/guides/guardian/guardian-ios-sdk.md @@ -0,0 +1,187 @@ +--- +title: Guardian for iOS SDK +description: Learn how to install, use and configure options for the Guardian for iOS SDK. +topics: + - mfa + - guardian + - ios +contentType: + - how-to +useCase: + - customize-mfa +--- +# Guardian for iOS SDK + +The [Guardian for iOS Software Development Kit](https://github.com/auth0/GuardianSDK.iOS) helps you create iOS apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization. + +For more general information on MFA, see [multi-factor authentication](/mfa). + +## Requirements + +The Guardian iOS SDK requires iOS 9.3+ and Swift 3. + +## Install Guardian iOS SDK + +### CocoaPods + +Guardian.swift is available through [CocoaPods](http://cocoapods.org). +To install it, simply add the following line to your Podfile: + +```ruby +pod "Guardian" +``` + +### Carthage + +In your Cartfile add this line + +``` +github "auth0/Guardian.swift" +``` + +<%= include('../../_includes/_enable-push-notifications') %> + +<%= include('../../_includes/_configure-sns') %> + +## Using the SDK + +`Guardian` is the core of the SDK. To get things going you'll have to import the library: + +```swift +import Guardian +``` + +Then you'll need the Auth0 Guarduan domain for your account: + +```swift +let domain = "{YOUR_ACCOUNT_NAME}.guardian.auth0.com" +``` + +### Enroll + +An enrollment is a link between the second factor and an Auth0 account. When an account is enrolled you'll need it to provide the second factor required to verify the identity. + +For an enrollment you need the following things, besides your Guardian Domain: + +- Enrollment Uri: The value encoded in the QR Code scanned from Guardian Web Widget or in your enrollment ticket sent to you, for example, by email. +- APNS Token: Apple APNS token for the device and **MUST** be a `String`containing the 64 bytes (expressed in hexadecimal format) +- Key Pair: A RSA (Private/Public) key pair used to assert your identity with Auth0 Guardian + +::: note +In case your app is not yet using push notifications or you're not familiar with it, you should check their [docs](https://developer.apple.com/go/?id=push-notifications). +::: + +After your have all of them, you can enroll your device: + +```swift +Guardian + .enroll(forDomain: "{YOUR_GUARDIAN_DOMAIN}", + usingUri: "{ENROLLMENT_URI}", + notificationToken: "{APNS_TOKEN}", + keyPair: keyPair) + .start { result in + switch result { + case .success(let enrollment): + // success, we have the enrollment data available + case .failure(let cause): + // something failed, check cause to see what went wrong + } + } +``` + +On success you'll obtain the enrollment information, that should be secured stored in your application. This information includes the enrollment identifier, and the token for Guardian API associated to your device for updating or deleting your enrollment. + +#### RSA key pair + +Guardian.swift provides a convenience class to generate an RSA key pair and store it in iOS Keychain. + +```swift +let rsaKeyPair = RSAKeyPair.new( + usingPublicTag: "com.auth0.guardian.enroll.public", + privateTag: "com.auth0.guardian.enroll.private" + ) +``` + +::: note +The tags should be unique since it's the identifier of each key inside iOS Keychain. +::: + +::: note +Since the keys are already secured stored inside iOS Keychain, you olny need to store the identifiers +::: + +### Allow a login request + +Once you have the enrollment in place, you will receive a push notification every time the user has to validate their identity with MFA. + +Guardian provides a method to parse the data received from APNs and return a `Notification` instance ready to be used. + +```swift +if let notification = Guardian.notification(from: notificationPayload) { + // we have received a Guardian push notification +} +``` + +Once you have the notification instance, you can easily allow the authentication request by using +the `allow` method. You'll also need the enrollment that you obtained previously. +In case you have more than one enrollment, you'll have to find the one that has the same `id` as the +notification (the `enrollmentId` property). + +```swift +Guardian + .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment) + .allow(notification: notification) + .start { result in + switch result { + case .success: + // the auth request was successfully allowed + case .failure(let cause): + // something failed, check cause to see what went wrong + } + } +``` + +### Reject a login request + +To deny an authentication request call `reject` instead. You can also send an optional reject reason if +you want. The reject reason will be available in the guardian logs. + +```swift +Guardian + .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment) + .reject(notification: notification) + // or reject(notification: notification, withReason: "hacked") + .start { result in + switch result { + case .success: + // the auth request was successfully rejected + case .failure(let cause): + // something failed, check cause to see what went wrong + } + } +``` + +### Unenroll + +If you want to delete an enrollment -for example if you want to disable MFA- you can make the +following request: + +```swift +Guardian + .api(forDomain: "{YOUR_GUARDIAN_DOMAIN}") + .device(forEnrollmentId: "{USER_ENROLLMENT_ID}", token: "{ENROLLMENT_DEVICE_TOKEN}") + .delete() + .start { result in + switch result { + case .success: + // success, the enrollment was deleted + case .failure(let cause): + // something failed, check cause to see what went wrong + } + } +``` + +## Keep reading + +* [Configure Push Notifications for MFA](/mfa/guides/configure-push) +* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html) diff --git a/fr-ca/articles/mfa/guides/guardian/install-guardian-sdk.md b/fr-ca/articles/mfa/guides/guardian/install-guardian-sdk.md new file mode 100644 index 0000000000..a1fe64bcfc --- /dev/null +++ b/fr-ca/articles/mfa/guides/guardian/install-guardian-sdk.md @@ -0,0 +1,221 @@ +--- +description: Learn how to install, use and configure options for the Guardian SDKs. +topics: + - mfa + - guardian + - ios +contentType: + - how-to +useCase: + - customize-mfa +--- +# Install Guardian SDK + +The Guardian SDK provides a UI-less client for Guardian. + +```text +npm install auth0-guardian-js +``` + +## Source files + +* [Full Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.js) +* [Minified Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.min.js) + +## Configure Guardian + +```js +var auth0GuardianJS = require('auth0-guardian-js')({ + // For US tenants: https://{name}.guardian.auth0.com + // For AU tenants: https://{name}.au.guardian.auth0.com + // For EU tenants: https://{name}.eu.guardian.auth0.com + serviceUrl: "https://{{ userData.tenant }}.guardian.auth0.com", + requestToken: "{{ requestToken }}", // or ticket: "{{ ticket }}" - see below + + issuer: { + // The issuer name to show in OTP Generator apps + label: "{{ userData.tenantFriendlyName }}", + name: "{{ userData.tenant }}", + }, + + // The account label to show in OTP Generator apps + accountLabel: "{{ userData.friendlyUserId }}", + + // Optional, for debugging purpose only, + // ID that allows to associate a group of requests + // together as belonging to the same "transaction" (in a wide sense) + globalTrackingId: "{{ globalTrackingId }}" +}); +``` + +Use of `requestToken` or `ticket` depends on the authentication method. Ticket corresponds to a previously generated [enrollment ticket](/mfa/guides/guardian/create-enrollment-ticket). + +## Enroll devices + +Enrolling devices consists of the following steps: + +1. Start the transaction. +2. (optional) Chck if the user is already enrolled. You cannot enroll twice. +3. Send the information needed to enroll. +4. Confirm enrollment. +5. Show recovery code. + +Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. Some of the methods end up completing the authentication, whereas some others need an extra authentication step. You can know that by listening to the `enrollment-complete` event. + +```js +function enroll(transaction, method) { + if (transaction.isEnrolled()) { + console.log('You are already enrolled'); + return; + } + + var enrollData = {}; + + if (method === 'sms') { + enrollData.phoneNumber = prompt('Phone number'); // Collect phone number + } + + return transaction.enroll(method, enrollData, function (err, otpEnrollment) { + if (err) { + console.error(err); + return; + } + + var uri = otpEnrollment.getUri(); + if (uri) { + showQR(uri); + } + + var confirmData = {}; + if (method === 'otp' || method === 'sms') { + confirmData.otpCode = prompt('Otp code'); // Collect verification otp + } + + otpEnrollment.confirm(confirmData); + }); +} + +auth0GuardianJS.start(function(err, transaction) { + if (err) { + console.error(err); + return; + } + + transaction.on('error', function(error) { + console.error(error); + }); + + transaction.on('timeout', function() { + console.log('Timeout'); + }); + + transaction.on('enrollment-complete', function(payload) { + if (payload.recoveryCode) { + alert('Recovery code is ' + payload.recoveryCode); + } + + if (payload.authRequired) { + showAuthenticationFor(transaction, payload.enrollment); + return; + } + }); + + transaction.on('auth-response', function(payload) { + if (payload.recoveryCode) { + alert('The new recovery code is ' + payload.recoveryCode); + } + + if (!payload.accepted) { + alert('Authentication has been rejected'); + return; + } + + auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature }); + }); + + var availableEnrollmentMethods = transaction.getAvailableEnrollmentMethods(); + + method = prompt('What method do you want to use, select one of ' + + availableEnrollmentMethods.join(', ')); + + enroll(transaction, method) // For sms +}); +``` + +## Authenticate + +To authenticate with a method you need to execute the following steps: + +1. Start the transaction. +2. (optional) Check if the user is already enrolled. You need to be enrolled to authenticate. +3. Request the auth (the push notification / sms). Request is a noop for OTP. +4. Verify the otp (`.verify` is a noop for push) + +Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. After the factor is verified or the push accepted you will receive an `auth-response` event with the payload to send to the server, you can use the `auth0GuardianJS.formPostHelper('{{ postActionURL }}', payload)` to post back the message to the server. + +You may also receive `auth-rejected` if the push notification was received. + +```js +function authenticate(method) { + auth0GuardianJS.start(function (err, transaction) { + if (err) { + console.error(err); + return; + } + + if (!transaction.isEnrolled()) { + console.log('You are not enrolled'); + return; + } + + transaction.on('error', function(error) { + console.error(error); + }); + + transaction.on('timeout', function() { + console.log('Timeout'); + }); + + transaction.on('auth-response', function(payload) { + if (payload.recoveryCode) { + alert('The new recovery code is ' + payload.recoveryCode); + } + + if (!payload.accepted) { + alert('Authentication has been rejected'); + return; + } + + auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature }); + }); + + var enrollment = transaction.getEnrollments()[0]; + + if (enrollment.getAvailableAuthenticatorTypes().length === 0) { + alert('Somethings went wrong, seems that there is no authenticators'); + return; + } + + transaction.requestAuth(enrollment, { method: method } function(err, auth) { + if (err) { + console.error(err); + return; + } + + var data = {}; + if (method === 'sms' || method === 'otp') { + data.otpCode = prompt('Otp code'); + } else if (method === 'recovery-code') { + data.recoveryCode = prompt('Recovery code'); + } + + return auth.verify(data); + }); + }); +} +``` + +## Keep reading + +* [Full Guardian API](https://github.com/auth0/auth0-guardian.js#full-api) +* [Guarding SDK Error Code Reference](/mfa/references/guardian-error-code-reference) diff --git a/fr-ca/articles/mfa/guides/import-user-mfa.md b/fr-ca/articles/mfa/guides/import-user-mfa.md new file mode 100644 index 0000000000..963de16bd9 --- /dev/null +++ b/fr-ca/articles/mfa/guides/import-user-mfa.md @@ -0,0 +1,163 @@ +--- +description: Import MFA enrollments for your existing users. +topics: + - mfa +contentType: + - how-to +useCase: + - import-mfa +--- +# Import Multi-Factor Authenticators + +You can import a user's MFA enrollments with [automatic migration](/users/guides/configure-automatic-migration) and [bulk user imports](/users/guides/bulk-user-imports). The supported enrollment types are: + +* Email: for [email](/mfa/concepts/mfa-factors#email-notifications) verification. +* Phone: for [SMS](/mfa/concepts/mfa-factors#sms-notifications) or [Voice](/mfa/concepts/mfa-factors#voice-notifications) verification. +* TOTP: for [One-Time Passwords (OTP)](/mfa/concepts/mfa-factors#one-time-passwords) used with authenticator applications, such as Google Authenticator. + +Importing MFA enrollments provides a seamless user experience, since users won't have to re-enroll after migration. + +::: warning +Please note that the classic login experience does not support factor selection for users with multiple factors. If you plan to import users with multiple registered factors, consider using the [universal login](/universal-login) experience. + +::: + +## Schema + +The schema applies to MFA factors for both of the aforementioned workflows. + +```json +{ + "type": "array", + "items": { + "type": "object", + "properties": { + "totp": { + "type": "object", + "properties": { + "secret": { + "type": "string", + "pattern": "^[A-Z2-7]+$", + "description": "The OTP secret is used for MFA authentication with Google Authenticator type apps. It must be supplied in un-padded Base32 encoding, such as: JBTWY3DPEHPK3PNP" + }, + }, + "additionalProperties": false, + "required": ["secret"], + }, + "phone": { + "type": "object", + "properties": { + "value": { + "type": "string", + "pattern": "^\\+[0-9]{1,15}$", + "description": "The phone number for SMS or Voice MFA. The phone number should include a country code and begin with +, such as: +12125550001" + }, + }, + "additionalProperties": false, + "required": ["value"], + }, + "email": { + "type": "object", + "properties": { + "value": { + "type": "string", + "format": "email", + "description": "The email address for MFA" + }, + }, + "additionalProperties": false, + "required": ["value"], + }, + }, + "maxProperties": 1, + "additionalProperties": false, + }, + "minItems": 1, + "maxItems": 10 +} +``` + +## Bulk User Import + +To begin, prepare a `users.json` file as described [here](/users/guides/bulk-user-imports). Be sure to include any existing MFA enrollments for each user. Next, start a bulk user import (described in more detail [here](/users/guides/bulk-user-imports#request-bulk-user-import)). You can _update_ the factors of any existing users by enabling the `upsert` option in your initial request. + +Once the import job completes, check the response for any errors. If any of the users' MFA factors failed to import, you will see errors such as: + +```json +{ + "code": "MFA_FACTORS_FAILED", + "message": "Unable to import factors" +} +``` + +When using the `upsert` option, any non-MFA related updates to existing users will have been applied to the user's profile. For example, the following error summary shows the user's `picture` attribute was successfully set to `http://example.org/jdoe.png`, however we were unable to import the provided MFA factors. In cases like this it is safe to retry the import for failed users. + +```json +[ + { + "user": { + "email": "antoinette@contoso.com", + "picture": "http://example.org/jdoe.png", + "mfa_factors": [ + { + "totp": { + "secret": "2PRXZWZAYYDAWCD" + } + }, + { + "phone": { + "value": "+15551112233" + } + }, + { + "email": { + "value": "antoinette@antoinette.biz" + } + } + ] + }, + "errors": [ + { + "code": "MFA_FACTORS_FAILED", + "message": "Unable to import factors" + } + ] + } +] +``` + +## Automatic Migration + +MFA enrollments can also be imported during an [automatic migration](/connections/database/custom-db/overview-custom-db-connections#automatic-migration-scenario). This can be accomplished by providing any existing enrollments in the `mfa_factors` field of the user that is provided to the callback at the end of your custom DB [login script](/connections/database/custom-db/templates/login). + +Any failures will appear in your tenant logs as failed logins, and will be distinguishable from other failures by their description: `Unable to import MFA factors`. For instance: + +```json +{ + "_id": "5e9df3b29ebabe00571c04a7", + "date": "2020-04-20T19:10:42.916Z", + "type": "fu", + "description": "Unable to import MFA factors.", + "connection": "Username-Password-Authentication", + "connection_id": "con_mMkvaycgzgCS0p0z", + "client_id": "aCbTAJNi5HbsjPJtRpSP6BIoLPOrSj2Cgg", + "client_name": "All Applications", + "ip": "10.12.13.1", + "client_ip": null, + "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36", + "details": { + "error": { + "message": "Unable to import MFA factors." + } + }, + "user_name": "test@test.io", + "strategy": "auth0", + "strategy_type": "database" +} +``` + +## Recovery Codes + +Auth0 does not provide a way to import Recovery Codes. When the users's MFA factors are imported, they won't have a recovery code. + +If you want to provide users for a recovery code, you can check if they have one enrolled, and if not, use the [recovery code regeneration](/api/management/v2#!/Users/post_recovery_code_regeneration) API endpoint to generate a new one. diff --git a/fr-ca/articles/mfa/guides/mfa-api/authenticate.md b/fr-ca/articles/mfa/guides/mfa-api/authenticate.md new file mode 100644 index 0000000000..219932f6e9 --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/authenticate.md @@ -0,0 +1,137 @@ +--- +title: Authenticate With Resource Owner Password Grant and MFA +description: Authenticate With Resource Owner Password Grant and MFA +topics: + - mfa + - mfa-api + - mfa-authenticators + - otp +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Authenticate With Resource Owner Password Grant and MFA + +This guide explains how to use the MFA API to complete the authentication flow using [Resource Owner Password Grant](/api-auth/tutorials/password-grant) when MFA is enabled. + +<%= include('../../_includes/_authenticator-before-start') %> + +## 1. Authenticate the User + +When you use the Resource Owner Password Grant to authenticate, you call the `/oauth/token` endpoint with the user's username/password: + +```har +{ +"method": "POST", +"url": "https://${account.namespace}/oauth/token", +"headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } +], +"postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "password" + }, + { + "name": "username", + "value": "user@example.com" + }, + { + "name": "password", + "value": "pwd" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "https://someapi.com/api" + }, + { + "name": "scope", + "value": "openid profile read:sample" + } + ] +} +} +``` + +When MFA is enabled, the response will include an `mfa_required` error and a `mfa_token`. + +```json +{ + "error": "mfa_required", + "error_description": "Multifactor authentication required", + "mfa_token": "Fe26...Ha" +} +``` + +## 2. Retrieve the Enrolled Authenticators + +After getting the error above, you need to find out if the user has an MFA factor enrolled or not. Call [`/mfa/authenticators`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint, using the MFA token obtained in the previous step. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/mfa/authenticators", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ] +} +``` + +You will get an array with the available authenticators. The array will be empty if the user did not enroll any factor. + +```json +[ + { + "id": "recovery-code|dev_O4KYL4FtcLAVRsCl", + "authenticator_type": "recovery-code", + "active": true + }, + { + "id": "email|dev_NU1Ofuw3Cw0XCt5x", + "authenticator_type": "oob", + "active": true, + "oob_channels": "email", + "name": "email@address.com" + } +] +``` + +## 3. Enroll an MFA Factor + +If the user is not enrolled in MFA, use the MFA token obtained earlier, and enroll it using the `/mfa/associate` endpoint. The documents linked below explain how to implement this flow depending on the authentication factor: + +- [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice) +- [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp) +- [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push) +- [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email) + +## 4. Challenge the User with MFA + +If the user is already enrolled in MFA, you need to challenge the user with one of the existing factors. Use the `authenticator_id` returned by the `/mfa/authenticators` endpoint when calling the `/mfa/challenge` endpoint. + +After the challenge is completed, call `/oauth/token` again to finalize the authentication flow and get the authentication tokens. + +The documents linked below explain how to implement this flow depending on the authentication factor: + +- [Challenging with SMS](/mfa/guides/mfa-api/phone#challenging-with-sms-or-voice) +- [Challenging with OTP](/mfa/guides/mfa-api/otp#challenging-with-otp) +- [Challenging with Push](/mfa/guides/mfa-api/push#challenging-with-push) +- [Challenging with Email](/mfa/guides/mfa-api/email#challenging-with-email) +- [Challenging with Recovery Code](/mfa/guides/mfa-api/recovery-code) + +## Keep reading + +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) diff --git a/fr-ca/articles/mfa/guides/mfa-api/email.md b/fr-ca/articles/mfa/guides/mfa-api/email.md new file mode 100644 index 0000000000..4cd4ba8dbb --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/email.md @@ -0,0 +1,208 @@ +--- +title: Enroll and Challenge Email Authenticators +description: Build your own MFA flows using email as a factor. +topics: + - mfa + - mfa-api + - mfa-authenticators + - email +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Enroll and Challenge Email Authenticators + +Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. + +This guide will explain how to enroll and challenge users with Email using the MFA API. Make sure that Email is [enabled as factor](/mfa/guides/configure-email) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name). + + +::: note +When Email is enabled as factor, all users with verified emails will be able to use them to complete MFA. + +Email authenticators are not supported when using the Classic Universal Login experience. +::: + +<%= include('../../_includes/_authenticator-before-start') %> + +## Enrolling with Email + +If you want to enable users enroll additional emails, in addition of the verified email in their primary identity, you need to complete the following steps. + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token') %> + +### 2. Enroll the Authenticator + +To enroll with Email, you need to use the following parameters: + +- `authentication_types` = `[oob]` +- `oob_channels` = `[email]` +- `email` = `email@address.com`, the user's email address. + + ```har + { + "method": "POST", + "url": "https://${account.namespace}/mfa/associate", + "headers": [{ + "name": "Authorization", + "value": "Bearer MFA_TOKEN" + }], + "postData": { + "mimeType": "application/json", + "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"email\"], \"email\" : \"email@address.com\" }" + } + } + ``` + + If successful, you'll receive a response like this: + + ```json + { + "authenticator_type": "oob", + "binding_method": "prompt", + "oob_code" : "Fe26..nWE", + "oob_channel": "email", + "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ] + } + ``` + +If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor. + +#### Recovery Codes + +<%= include('../../_includes/_recovery_codes') %> + +### 3. Confirm the email enrollment + +The user should receive an email containing the 6-digit code, which they can provide to the application. + +To complete enrollment of the email authenticator make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the email message. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + }, + { + "name": "binding_code", + "value": "USER_EMAIL_OTP_CODE" + }, + { + "name": "client_id", + "value": "${account.clientId}" + } + ] + } +} +``` + +For more information on how to customize the email that users get, check [Customizing Your Emails](/email/templates). + +<%= include('../../_includes/_successful_confirmation') %> + +## Challenging with Email + +To challenge a user with Email, follow the steps detailed below. + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token_challenge') %> + +### 2. Challenge the user with Email + +To challenge the user you first need to obtain the id of the authenticator you want to challenge using the [`/mfa/enrollments`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint. + +To trigger an email challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/challenge", + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"email|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }" + } +} +``` + +### 3. Complete authentication using the received code + +If successful, you'll get the following response, and the user will get an email message containing the six-digit code: + +```json +{ + "challenge_type": "oob", + "oob_code": "abcd1234...", + "binding_method": "prompt" +} +``` + +Your application needs to prompt the user for the code, and send it as part of the request, in the `binding_code` parameter, in the following call to the `/oauth/token` endpoint: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + }, + { + "name": "binding_code", + "value": "USER_EMAIL_OTP_CODE" + } + ] + } +} +``` + +<%= include('../../_includes/_successful_challenge') %> + +## Keep Reading + +* [Configure Email Notifications for MFA](/mfa/guides/configure-email) +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) +* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push) +* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp) +* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms) +* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code) diff --git a/fr-ca/articles/mfa/guides/mfa-api/manage.md b/fr-ca/articles/mfa/guides/mfa-api/manage.md new file mode 100644 index 0000000000..128406fe8a --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/manage.md @@ -0,0 +1,149 @@ +--- +title: Manage Authenticator Factors using the MFA API +description: Learn how to manage your MFA authenticators +topics: + - mfa + - mfa-api + - mfa-authenticators +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Manage Authenticator Factors using the MFA API + +Auth0 provides several API endpoints to help you manage the authenticators you're using with an application for multi-factor authentication (MFA). + +You can use these endpoints to build a complete user interface for letting users manage their authenticator factors. + +<%= include('../../_includes/_authenticator-before-start') %> + +## Getting an MFA API Access Token + +In order to call the MFA API to manage enrollments, you first need to obtain an Access Token for the MFA API. + +If you want to use the MFA API as part of an authentication flow, you can follow the steps detailed in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document. + +If you are building a user interface to manage authentication factors, you'll need to obtain a token you can use for the MFA API at any moment, not only during authentication: + +* If you are using [Universal Login](/universal-login), redirect to the `/authorize` endpoint, specifying the `https://${account.namespace}/mfa/` audience, before using calling the MFA API. +* If you are using the Resource Owner Password Grant, you have two options: + * Ask for the `https://${account.namespace}/mfa/` audience when logging-in, and use a [Refresh Token](/tokens/concepts/refresh-tokens) to refresh it later. + * If you need to list and delete authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) with `/oauth/token`, specifying the `https://${account.namespace}/mfa/` audience. Users will need to complete MFA before being able to list/delete the authentication factors. + * If you only need to list authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) using `/oauth/token`, with username/password. The endpoint will return an `mfa_required` error, and an `mfa_token` you can use to list authenticators. Users will need to provide their password to see their authenticators. + +When you request a token for the MFA audience, you can request the following scopes: + +* `enroll`: needed to enroll a new authenticator +* `read:authenticators`: needed to list existing authenticators +* `remove:authenticators`: needed to delete an authenticator + +## List Authenticators + +To get the list of the authenticators for a user, you can call the `/mfa/authenticators` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/mfa/authenticators", + "headers": [{ + "name": "Authorization", + "value": "Bearer MFA_TOKEN" + }] +} +``` + +You should receive information about the authenticator type(s) in the response: + +```json +[ + { + "authenticator_type": "recovery-code", + "id": "recovery-code|dev_IsBj5j3H12VAdOIj", + "active": true + }, + { + "authenticator_type": "otp", + "id": "totp|dev_nELLU4PFUiTW6iWs", + "active": true, + }, + { + "authenticator_type": "oob", + "oob_channels": "sms", + "id": "sms|dev_sEe99pcpN0xp0yOO", + "name": "+1123XXXXX", + "active": true + } +] +``` + +For the purposes of building an user interface for end users to manage their factors, you should ignore authenticators that have `active` = `false`. Those authenticators are not confirmed by users, so they can't be used to challenge for MFA. + +::: note +- When a user enrolls with Push, Auth0 creates an OTP enrollment. You will see both when listing enrollments. +- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`. +- When Email MFA is enabled, all verified emails will be listed as authenticators. +- When a user enrolls any factor Auth0 creates a recovery code that will be listed as an authenticator. +::: + +## Enroll Authenticators + +The documents below explain how to enroll with different factors: + +* [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice) +* [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp) +* [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push) +* [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email) + +You can also [use the Universal Login flow](/mfa/guides/guardian/create-enrollment-ticket) for enrolling users at any moment. + +## Delete Authenticators + +To delete an associated authenticator, send a `DELETE` request to the `/mfa/authenticators/AUTHENTICATOR_ID` endpoint. You can get the `ID` when listing authenticators. + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID", + "headers": [{ + "name": "Authorization", + "value": "Bearer MFA_TOKEN" + }] +} +``` + +If the authenticator was deleted, a 204 response is returned. + +:::note +- When you enroll a Push authenticator, Auth0 also enrolls an OTP one. If you delete any of them, the other one will be also deleted. +- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`. When you delete one, the other will also be deleted. +- If Email MFA is enabled, all verified emails will be listed as authenticators, but you can't delete them. You can only delete email authenticators that were enrolled explicitly. +::: + +## Delete a Recovery Code + +To delete a Recovery Code, you need to use Management API's `/api/v2/users/USER_ID/recovery-code-regeneration` endpoint. You previously need to get a [Management API Access Token](/api/management/v2/tokens). + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/users/USER_ID/recovery-code-regeneration", + "headers": [{ + "name": "Authorization", + "value": "Bearer MANAGEMENT_API_TOKEN" + }] +} +``` + +You will get a new recovery code that the end user will need to capture: + +```json +{ + "recovery_code": "FA45S1Z87MYARX9RG6EVMAPE" +} +``` + +## Keep reading + +* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) diff --git a/fr-ca/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md b/fr-ca/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md new file mode 100644 index 0000000000..61398e8c4b --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md @@ -0,0 +1,347 @@ +--- +title: Multi-factor Authentication and Resource Owner Password +description: How to use Multi-factor Authentication with Resource Owner Password Grant. +toc: true +topics: + - api-authentication + - oidc + - mfa + - resource-owner-password +contentType: tutorial +useCase: + - secure-api + - call-api +--- +# Multi-factor Authentication and the Resource Owner Password Grant + +Highly-trusted applications can use the [Resource Owner Password Grant](/api-auth/grant/password) to access an API. The flow typically involves prompting the user for username and password as credentials to be submitted to Auth0. In some scenarios, however, stronger authentication may be required. This document outlines using multi-factor authentication (MFA) with the [Resource Owner Password Grant](/api-auth/grant/password). + +## Prerequisites + +Before you continue, make sure that you've met the following prerequisites: + +1. MFA is enabled on the [Auth0 dashboard](${manage_url}). [Duo Security](/mfa/guides/configure-cisco-duo) is __not__ supported as a factor with this flow. + +1. An Application is configured to execute the Resource Owner Password Grant (either [password](/api-auth/tutorials/password-grant) or [password-realm](/api-auth/tutorials/password-grant#realm-support) grant types). For details on how to implement this, refer to [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant). + +1. End users are enrolled in MFA. + +## Initiate Multi-factor Authentication + +The flow starts by collecting end-user credentials and sending them to Auth0, as described in [Resource Owner Password Grant](/api-auth/grant/password). Both [password](/api-auth/tutorials/password-grant) and [password-realm](/api-auth/tutorials/password-grant#realm-support) flows are available. + +1. The user enters their credentials into the Application. + +2. The Application forwards the credentials to Auth0. + +3. Auth0 validates the credentials and executes any applicable [rules](/rules). + +4. If any rule triggers MFA for the current user, an error code of `mfa_required` is returned. The error will additionally contain an `mfa_token` property. + + ```json + HTTP/1.1 403 Forbidden + Content-Type: application/json + { + "error": "mfa_required", + "error_description": "Multi-factor authentication required", + "mfa_token": "eyJ0eXAiOiJKV1QiLCJhbGci....D3QCiQ" + } + ``` + +5. The Application will then make a request to the [MFA challenge](/api/authentication#resource-owner-password-and-mfa) endpoint, specifying the challenge types it supports. Valid challenge types are: [OTP](#challenge-type-otp), [OOB with binding method `prompt`](#challenge-type-oob-and-binding-method-prompt), and [OOB with no binding method](#challenge-type-oob-with-no-binding-method). If you already know that `otp` is supported by the end-user and you don't want to request a different factor, you can skip this and the next steps an go directly to [Challenge Type `OTP`](#challenge-type-otp) below. + +6. Auth0 sends a response containing the `challenge_type` derived from the types supported by the Application and the specific user. Additionally, extra information, such as `binding_method` may be included to assist in resolving the challenge and displaying the correct UI to the user. + +The supported challenge types are: + +- `otp`: A one-time password generated by an app setup with a seed or by token generation hardware. This mechanism does not require an extra channel to prove possession of the device; you can get it directly from the app / hardware device. + +- `oob`: The proof of possession of the device here is done 'out of band' via a side channel. There are several different channels, including push notification-based authenticators, SMS, and Voice based authenticators. Depending on the channel and the authenticator chosen at enrollment, you may need to provide a `binding_code` used to bind the side channel and the channel used for authentication. + +To execute MFA, follow the next steps according to the challenge type you will use: + +- [OTP](#challenge-type-otp): for this challenge type, your application must prompt the end-user for an OTP code and continue the flow using the __mfa-otp__ grant type. + +- [OOB and binding method `prompt`](#challenge-type-oob-and-binding-method-prompt): the challenge will be sent through a side channel (such as SMS or Voice), and your application will need to prompt the user for the `binding_code` that was included as part of the challenge sent, as well as the `oob_code` received as response to this request to prove possession of the device. + +- [OOB with no binding method](#challenge-type-oob-with-no-binding-method): in this case, the proof of possession will be driven entirely in a side channel (such as a push notification-based authenticator). The response will include an `oob_code` that the Application will use to periodically check for the resolution of the transaction. Continue the flow using the __mfa-oob__ grant type. + +## Execute Multi-factor Authentication + +The following sections cover how to execute MFA based on the challenge type used. + +### Challenge Type: `OTP` + +![Resource Owner MFA OTP](/media/articles/api-auth/challenge-type-otp.png) + +For this type of challenge, the Application must get an one-time password (`otp`) code from a OTP Generator app, such as Google Authenticator or Microsoft Authenticator. + +::: note +If you already know that the user supports OTP, then steps 5 and 6 above of the [Initiate Multi-factor Authentication](#initiate-multifactor-authentication) section are optional. +::: + +7. The Application prompts the end user to enter an OTP code. + +8. The end user enters their OTP into the Application. + +9. The Application forwards the OTP code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` obtained in step 4 above. + +10. Auth0 validates the provided OTP and returns the Access Token and the Refresh Token. + +11. The Application can use the Access Token to call the API on behalf of the end user. + +### Challenge Type: `OOB` with Binding Method `prompt` + +![Resource Owner MFA OOB Prompt](/media/articles/api-auth/challenge-type-oob-with-binding-method.png) + +This challenge type, together with `prompt` binding method, indicates that the challenge will be delivered to the user using a side channel (such as SMS or Voice) and that a `binding_code` is needed to bind the side channel to the one being authenticated. The binding code is sent as part of the challenge message and it is usually an OTP-like code composed of 6 numeric digits. + +7. The Application prompts the user for the `binding_code` and stores the `oob_code` from step 6 for future use. + +8. The end user receives the challenge on the side channel and enters the `binding_code` into the Application. + +9. The Application forwards the `binding_code` to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6). + +10. Auth0 validates the `binding_code` and `oob_code` and returns the Access Token and the Refresh Token. + +11. The Application can use the Access Token to call the API on behalf of the end user. + +### Challenge Type: `OOB` with No Binding Method + +![Resource Owner MFA OOB](/media/articles/api-auth/challenge-type-oob-no-binding-method.png) + +In this scenario, the challenge will be sent using a side channel, however, there is no need for a `binding_code`. Currently, the only mechanism supported for this scenario is Push Notification with the Guardian Provider. + +7. The Application asks the user to accept the delivered challenge and keeps the `oob_code` from step 6 for future use. + +8. The Application polls Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6). + +9. Auth0 validates the provided `oob_code`, the `mfa_token` and returns: + - `authorization_pending` error: if the challenge has not been accepted nor rejected. + - `slow_down` error: if the polling is too frequent. + - an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point. + - `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point. + +10. The Application can use the Access Token to call the API on behalf of the end user. + +## Using Recovery Codes + +::: note +This flow is not available when the user uses provider = `google-authenticator` or provider = `duo`. +::: + +![Resource Owner MFA Recovery](/media/articles/api-auth/recovery-code.png) + +Some providers support using a recovery code to login in case the enrolled device is not available, or if lack of connectivity prevents receiving an OTP code or push notification. + +Using a recovery code is similar to using an OTP code to login. The main difference is that a new recovery code will be generated, and that the application must display this new recovery code to the user for secure storage. + +Steps 1-4 are the same as above. + +5. End user chooses to use the recovery code. + +6. The Application prompts the end user to enter recovery code. + +7. The end user enters their recovery code into the Application. + +8. The Application forwards the recovery code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` from step 4. + +9. Auth0 validates the recovery code and returns the Access Token and the Refresh Token. + +10. The Application can use the Access Token to call the API on behalf of the end user. + +## Samples + +The following are sample implementations involving MFA. + +### Resource Owner Password Grant Request + +```javascript +var request = require("request"); + +var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'password', + username: 'USERNAME', + password: 'PASSWORD', + audience: 'API_IDENTIFIER', + scope: 'SCOPE', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + +request(options, function (error, response, body) { + if (error) throw new Error(error); + + if (body.error === 'mfa_required') { + // Show mfa flow and give user option to go to the recovery flow (if supported) + + if (/* MFA Recovery is requested*/) { + const recovery_code = // Prompt for recovery code + mfaRecovery(body.mfa_token, recovery_code) // See MFA Recovery grant + } else { + mfaChallenge(body.mfa_token) + } + } +}); +``` + +### Challenge Request + +```javascript +function mfaChallenge(mfa_token) { + var options = { method: 'POST', + url: 'https://${account.namespace}/mfa/challenge', + headers: { 'content-type': 'application/json' }, + body: + { mfa_token: mfa_token, + challenge_type: 'oob otp', // Supported challenge types, space separated + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' }, + json: true }; + + request(options, function (error, response, body) { + if (error) throw new Error(error); + + if (body.challenge_type === 'otp') { + const otp = // Prompt for otp code (see MFA OTP grant request) + mfaOTP(mfa_token, otp) + } else if (body.challenge_type === 'oob') { + if (body.binding_method === 'prompt') { + const binding_code = // Prompt for binding code (see MFA OOB with binding code grant request) + mfaOOB(mfa_token, body.oob_code, binding_code) + } else if (!body.binding_method) { + // Ask the user to accept the challenge and start polling (see MFA OOB without binding code grant request) + mfaOOB(mfa_token, body.oob_code) + } else { + console.error('Unsupported binding_method'); + } + } else { + console.error('Something went wrong'); + } + }); +} +``` + +### MFA OTP Grant Request + +```javascript +function mfaOTP(mfa_token, otp) { + var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: mfa_token, + otp: otp, + grant_type: 'http://auth0.com/oauth/grant-type/mfa-otp', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + + request(options, function (error, response, body) { + if (error) throw new Error(error); + + if (response.statusCode === 200) { + // The tokens returned depend on the scopes requested on the password grant request + console.log(body.access_token, body.id_token, body.refresh_token); + } else if (body.error === 'invalid_grant') { + // Invalid otp code + console.error('Invalid otp'); + } else { + console.error('Something went wrong'); + } + }); +} +``` + +### MFA OOB Grant Request + +```javascript +function mfaOOB(mfa_token, oob_code, /* optional */ binding_code) { + makeOOBGrantRequest(mfa_token, oob_code, binding_code, function(error, result) { + if (error) { throw error; } + + if (result.state === 'authorization_pending') { + // Poll every 10 seconds + setTimeout(() => makeOOBGrantRequest(mfa_token, oob_code, binding_code), 10000); + } else if (result.state === 'authorized') { + console.log(result.body.access_token, result.body.id_token, result.body.refresh_token); + } else { + console.error('You are not authorized') + } + }); +} + +function makeOOBGrantRequest(mfa_token, oob_code, /* optional */ binding_code, cb) { + var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: mfa_token, + oob_code: oob_code, + binding_code: binding_code, // Only when binding_method = prompt + grant_type: 'http://auth0.com/oauth/grant-type/mfa-oob', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + + request(options, function (error, response, body) { + if (error) { return cb(error); } + + if (response.statusCode === 200) { + // The tokens returned depend on the scopes requested on the password grant request + cb(null, { state: 'authorized', body }); + } else if (body.error === 'invalid_grant') { + // Invalid otp code + cb(null, { state: 'not_authorized' }); + } else if (body.error === 'authorization_pending') { + cb(null, { state: 'authorization_pending' }); + } else if (body.error === 'slow_down') { + // You are polling too fast, slow down the polling rate, + // You may want to check rate-limiting headers to manage your polling rate + setTimeout(() => cb({ state: 'authorization_pending' }), 20000); + } else { + cb(new Error('Something went wrong')) + } + }); +} +``` + +### MFA Recovery Grant Request + +```javascript +function mfaRecovery(mfa_token, recovery_code) { + var options = { method: 'POST', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { mfa_token: mfa_token, + recovery_code: recovery_code, + grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code', + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; + + request(options, function (error, response, body) { + if (error) throw new Error(error); + + if (response.statusCode === 200) { + console.log('Please store this new recovery code safely -- the previous code will no longer work.', body.recovery_code) + + // The tokens returned depend on the scopes requested on the password grant request + console.log(body.access_token, body.id_token, body.refresh_token); + } else if (body.error === 'invalid_grant') { + // Invalid recovery code + console.error('Invalid recovery_code'); + } else { + console.error('Something went wrong'); + } + }); +} +``` + +## MFA API + +See [MFA API](/mfa/concepts/mfa-api) for detailed information about Auth0's MFA API endpoints. diff --git a/fr-ca/articles/mfa/guides/mfa-api/otp.md b/fr-ca/articles/mfa/guides/mfa-api/otp.md new file mode 100644 index 0000000000..f2efd0e81a --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/otp.md @@ -0,0 +1,221 @@ +--- +title: Enroll and Challenge OTP Authenticators +description: Build your own MFA flows using OTP as a factor. +topics: + - mfa + - mfa-api + - mfa-authenticators + - otp +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Enroll and Challenge OTP Authenticators + +Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. + +This guide explains how to enroll and challenge users with OTP using the MFA API. First, make sure that OTP is [enabled as factor](/mfa/guides/configure-otp) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name). + +<%= include('../../_includes/_authenticator-before-start') %> + +## Enrolling with OTP + +### 1. Get the MFA Token + +<%= include('../../_includes/_get_mfa_token') %> + +### 2. Enroll the Authenticator + +<%= include('../../_includes/_request_association') %> + +To enroll with OTP you need to set the `authenticator_types` parameter to `[otp]`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/associate", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"authenticator_types\": [\"otp\"] }" + } +} +``` + +If successful, you'll receive a response like this: + +```json +{ + "authenticator_type": "otp", + "secret": "EN...S", + "barcode_uri": "otpauth://totp/tenant:user?secret=...&issuer=tenant&algorithm=SHA1&digits=6&period=30", + "recovery_codes": [ "N3B...XC"] +} +``` + +If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor. + +#### Recovery Codes + +<%= include('../../_includes/_recovery_codes') %> + +### 3. Confirm the OTP enrollment + +To confirm the enrollment, the end user will need to enter the secret obtained in the previous step in an OTP generator application like Google Authenticator. They can enter the secret by scanning a QR code with the `barcode_uri` or by typing the `secret` code manually in that OTP application. You should provide users a way to get the `secret` as text in case they cannot scan the QR code (e.g. if they are enrolling from a mobile device, or using a desktop OTP application). + +After the users enter the secret, the OTP application will display a 6-digit code, that the user should enter in your application. The application should then make a `POST` request to the `oauth/token` endpoint, including that `otp` value. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-otp" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "otp", + "value": "USER_OTP_CODE" + } + ] + } +} +``` + +<%= include('../../_includes/_successful_confirmation') %> + +## Challenging with OTP + +To challenge a user with OTP, follow the steps detailed below. + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token_challenge') %> + +### 2. Retrieve the enrolled authenticators + +To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/mfa/authenticators", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ] +} +``` + +You will get a list of authenticators with the format below: + +```json +[ + { + "id": "recovery-code|dev_qpOkGUOxBpw6R16t", + "authenticator_type": "recovery-code", + "active": true + }, + { + "id": "totp|dev_6NWz8awwC8brh2dN", + "authenticator_type": "otp", + "active": true + } +] +``` + +### 3. Challenge the user with OTP + +To trigger an OTP challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/challenge", + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"challenge_type\": \"otp\", \"mfa_token\": \"MFA_TOKEN\", \"authenticator_id\" : \"totp|dev_6NWz8awwC8brh2dN\" }" + } +} +``` + +### 4. Complete authentication using the received code + +If successful, you'll receive the following response: + +```json +{ + "challenge_type": "otp" +} +``` + +The user will collect a one-time password, which you will then collect from them. You can the verify the code and get authentication tokens using the `/oauth/token` endpoint, specifying the one-time password in the `otp` parameter: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-otp" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "otp", + "value": "USER_OTP_CODE" + } + ] + } +} +``` + +<%= include('../../_includes/_successful_challenge') %> + +## Keep Reading + +* [Configure One-Time Passwords for MFA](/mfa/guides/configure-otp) +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) +* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push) +* [Enroll and Challenge SMS or Voice Authenticators](/mfa/guides/mfa-api/phone) +* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email) +* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code) diff --git a/fr-ca/articles/mfa/guides/mfa-api/phone.md b/fr-ca/articles/mfa/guides/mfa-api/phone.md new file mode 100644 index 0000000000..02ec707bba --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/phone.md @@ -0,0 +1,256 @@ +--- +title: Enroll and Challenge SMS or Voice Authenticators +description: Build your own MFA flows using SMS or Voice as a factor. +topics: + - mfa + - mfa-api + - mfa-authenticators + - sms +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Enroll and Challenge SMS or Voice Authenticators + +Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. + +::: warning +Voice MFA is currently a Beta feature. It should not be used in production environments. +::: + +This guide explains how to enroll and challenge users with SMS or a voice call using the MFA API. First, make sure that Phone is [enabled as factor](/mfa/guides/configure-phone) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name). + +<%= include('../../_includes/_authenticator-before-start') %> + +## Enrolling with SMS or Voice + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token') %> + +### 2. Enroll the Authenticator + +<%= include('../../_includes/_request_association') %> + +When a user enrolls with Voice or SMS, they are actually enrolling a phone number that can be challenged either with SMS or Voice. + +You need to specify the parameters below to call the endpoint. The `oob_channels` parameter indicates how you want to send the code to the user (SMS or Voice): + +- `authentication_types` = `[oob]` +- `oob_channels` = `[sms]` or `[voice]`. +- `phone_number` = `+11...9`, the phone number [E.164 format](https://en.wikipedia.org/wiki/E.164) + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/associate", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"sms\"], \"phone_number\": \"+11...9\" }" + } +} +``` + +If successful, you'll receive a response like the one below: + +```json +{ + "authenticator_type": "oob", + "binding_method": "prompt", + "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ], + "oob_channels": "sms", + "oob_code": "ata6daXAiOi..." +} +``` + +If you get a `User is already enrolled error`, it is because the user already has an MFA factor enrolled. Before associating it with another factor, you need to challenge the user with the existing one. + +#### Recovery Codes + +<%= include('../../_includes/_recovery_codes') %> + +### 3. Confirm the SMS or Voice enrollment + +Users should receive an message with a 6-digit code that they need to provide to the application. + +To complete enrollment, make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the message. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + }, + { + "name": "binding_code", + "value": "USER_OTP_CODE" + } + ] + } +} +``` + +<%= include('../../_includes/_successful_confirmation') %> + +## Challenging with SMS or Voice + +To challenge a user with SMS or Voice, follow the steps detailed below. + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token_challenge') %> + +### 2. Retrieve the enrolled authenticators + +To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/mfa/authenticators", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ] +} +``` + +You will get a list of authenticators with the format below: + +```json +[ + { + "id": "recovery-code|dev_O4KYL4FtcLAVRsCl", + "authenticator_type": "recovery-code", + "active": true + }, + { + "id": "sms|dev_NU1Ofuw3Cw0XCt5x", + "authenticator_type": "oob", + "active": true, + "oob_channels": "sms", + "name": "XXXXXXXX8730" + }, + { + "id": "voice|dev_NU1Ofuw3Cw0XCt5x", + "authenticator_type": "oob", + "active": true, + "oob_channels": "voice", + "name": "XXXXXXXX8730" + } +] +``` + +Note that you have two authenticators with different `authenticator_id` for Voice or SMS. + +### 3. Challenge the user with SMS or Voice + +To trigger the challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` and the MFA Access Token. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/challenge", + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"sms|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }" + } +} +``` + +### 4. Complete authentication using the received code + +If successful, you'll receive the following response, and the user will get a message containing the required six-digit code: + +```json +{ + "challenge_type": "oob", + "oob_code": "asdae35fdt5...", + "binding_method": "prompt" +} +``` + +Your application needs to prompt the user for 6-digit code sent in the message, and should be set in the `binding_code` parameter. + +You can then verify the code and get the authentication tokens using the `/oauth/token` endpoint, using the `binding_code` and the `oob_code` returned by the previous call: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + }, + { + "name": "binding_code", + "value": "USER_OTP_CODE" + } + ] + } +} +``` + +<%= include('../../_includes/_successful_challenge') %> + +## Keep reading + +* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone) +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) +* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push) +* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp) +* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email) +* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code) diff --git a/fr-ca/articles/mfa/guides/mfa-api/push.md b/fr-ca/articles/mfa/guides/mfa-api/push.md new file mode 100644 index 0000000000..d2d0902bdd --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/push.md @@ -0,0 +1,250 @@ +--- +title: Enroll and Challenge Push Authenticators +description: Build your own MFA flows using Push as a factor. +topics: + - mfa + - mfa-api + - mfa-authenticators +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Enroll and Challenge Push using Guardian + +Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. + +This guide explains to enroll and challenge users using Push Notifications with the Guardian Application or SDK, using the MFA API. First, make sure that Push is [enabled as factor](/mfa/guides/configure-push) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name). + +<%= include('../../_includes/_authenticator-before-start') %> + +## Enrolling with Push + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token') %> + +### 2. Enroll the Authenticator + +<%= include('../../_includes/_request_association') %> + +To enroll with Push, you need to use the following parameters: + +- `authentication_types` = `[oob]` +- `oob_channels` = `[auth0]` + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/associate", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"auth0\"] }" + } +} +``` + +If successful, you'll receive a response like the one below: + +```json +{ + "authenticator_type": "oob", + "barcode_uri": "otpauth://totp/tenant:user?enrollment_tx_id=qfjn2eiNYSjU3xID7dBYeCBSrdREWJPY&base_url=tenan", + "recovery_codes": [ + "ALKE6EJZ4853BJYLM2DM2WU7" + ], + "oob_channels": "auth0", + "oob_code": "Fe26.2...SYAg" +} +``` + +If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor. + +#### Recovery Codes + +<%= include('../../_includes/_recovery_codes') %> + +### 3. Confirm the Push enrollment + +To confirm the enrollment, the end user will need to scan the a QR code with the `barcode_uri` in the Guardian App. Once that is done the Guardian App will notify Auth0 that the user enrolled successfully. To know if that happened, you need to poll the `/oauth/token` endpoint with the `oob_code` returned by the `/associate` call: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + } + ] + } +} +``` + +If the user did has not scanned the code, it will return an `authorization_pending` response, indicating you need to call `oauth_token` again in a few seconds: + +```json +{ + "error": "authorization_pending", + "error_description": "Authorization pending: please repeat the request in a few seconds." +} +``` + +<%= include('../../_includes/_successful_confirmation') %> + +## Challenging with Push + +To challenge a user with Push, follow the steps detailed below. + +### 1. Get the MFA token + +<%= include('../../_includes/_get_mfa_token_challenge') %> + +### 2. Retrieve the enrolled authenticators + +To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/mfa/authenticators", + "headers": [ + { "name": "Authorization", "value": "Bearer MFA_TOKEN" }, + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ] +} +``` + +You will get a list of authenticators with the format below: + +```json +[ + { + "id": "recovery-code|dev_Ahb2Tb0ujX3w7ilC", + "authenticator_type": "recovery-code", + "active": true + }, + { + "id": "push|dev_ZUla9SQ6tAIHSz6y", + "authenticator_type": "oob", + "active": true, + "oob_channels": "auth0", + "name": "user's device name" + }, + { + "id": "totp|dev_gJ6Y6vpSrjnKeT67", + "authenticator_type": "otp", + "active": true + } +] +``` + +Note that when users enroll with Push, they also get enrolled in OTP, as Guardian supports [challenging with OTP](/mfa/guides/mfa-api/otp/#challenging-with-otp) for scenarios where the user does not have connectivity. + +### 3. Challenge the user with Push + +To trigger an Push challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/mfa/challenge", + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"push|dev_ZUla9SQ6tAIHSz6y\", \"mfa_token\": \"MFA_TOKEN\" }" + } +} +``` + +### 4. Complete authentication using the received code + +If successful, you'll receive the following response, and the user will get an Push notification: + +```json +{ + "challenge_type": "oob", + "oob_code": "Fe26...jGco" +} + +``` + +Your application needs to start polling the `/oauth/token` endpoint until the user accepts the Push notification. If the endpoint returns ` + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-oob" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "oob_code", + "value": "OOB_CODE" + } + ] + } +} +``` + +This call can return one of the following results: + +- `authorization_pending` error: if the challenge has not been accepted nor rejected. +- `slow_down` error: if the polling is too frequent. +- an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point. +- `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point. + +## Keep Reading + +* [Configure Push Notifications for MFA](/mfa/guides/configure-push) +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) +* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms) +* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp) +* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email) +* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code) diff --git a/fr-ca/articles/mfa/guides/mfa-api/recovery-code.md b/fr-ca/articles/mfa/guides/mfa-api/recovery-code.md new file mode 100644 index 0000000000..038abaefc1 --- /dev/null +++ b/fr-ca/articles/mfa/guides/mfa-api/recovery-code.md @@ -0,0 +1,91 @@ +--- +description: Use the MFA API to challenge users who lose access to their device or account using recovery codes. +topics: + - mfa + - mfa-api + - mfa-authenticators + - recovery-codes +contentType: + - how-to + - reference +useCase: + - customize-mfa +--- +# Challenge with Recovery Codes + +Auth0 automatically generates recovery codes when users enroll with MFA. These codes can be used when users lost access to the device or account they used to enroll MFA. + +This guide explains how to enable users to authenticate using a recovery code using the MFA API. + +## 1. Prompt the user for the recovery code + +When the user enrolls with MFA, Auth0 generates a recovery code, that the user should capture. That value should be entered in the application for the user to authenticate. + +::: note +Auth0 does not generate recovery codes for DUO and for the legacy `google-authenticator` factor. +::: + +## 2. Authenticate using the Recovery Code + +Call the `/oauth/token` endpoint with the recovery code to authenticate and generate a new recovery code. You need to specify the following parameters: + +- `grant_type` : `http://auth0.com/oauth/grant-type/mfa-recovery-code` +- `recovery_code` : the recovery code provided by the user + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "http://auth0.com/oauth/grant-type/mfa-recovery-code" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "mfa_token", + "value": "MFA_TOKEN" + }, + { + "name": "recovery_code", + "value": "RECOVERY_CODE" + } + ] + } +} +``` + +### 3. Ask the user to capture the new Recovery Code + +If the call is successful, you'll get the authentication tokens and a new recovery code: + +```json +{ + "access_token": "O3...H4", + "id_token": "eyJh...w", + "scope": "openid profile", + "expires_in": 86400, + "recovery_code": "K6LGLV3RSH3VERMKET8L7QKU", + "token_type": "Bearer" +} +``` + +You should let the user know that a new recovery code was generated and ask them to capture it. + +* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage) +* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push) +* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp) +* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms) +* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email) diff --git a/fr-ca/articles/mfa/guides/reset-user-mfa.md b/fr-ca/articles/mfa/guides/reset-user-mfa.md new file mode 100644 index 0000000000..fde72fc781 --- /dev/null +++ b/fr-ca/articles/mfa/guides/reset-user-mfa.md @@ -0,0 +1,52 @@ +--- +description: Learn how to reset a user's MFA in case they lose their mobile device and do not have a recovery code. +topics: + - mfa + - user-management +contentType: + - how-to +useCase: + - customize-mfa +--- +# Reset User's MFA + +If a user has lost their mobile device, they can use their recovery code to log in. If they do not have a recovery code, they will need their tenant administrator to reset their multi-factor authentication (MFA). + +This action is equivalent to removing or deleting the user's MFA registration. The MFA settings associated with their user will be removed, which allows them to set up MFA as if they were a new user on their next login attempt. + +::: note +If you need to reset an admin's MFA as opposed to an end user's MFA, please contact [Auth0 Support](https://auth0.com/docs/support). +::: + +## Reset MFA in the Dashboard + +1. Go to [Dashboard > Users & Roles > Users](${manage_url}/#/users). +2. Click on the user whose MFA you want to reset. +3. Click on the **Actions** button on the top right of the screen. +4. Select **Reset Multi-factor** from the dropdown. + + Admins will also see a **Reset MFA** link at the bottom of the **Multi-Factor Authentication** tab of the **User Details** page if the user is already enrolled in MFA. Both these methods function the same way. + +5. There will be a pop up box to confirm your decision. Click **YES, RESET IT** to reset the user's MFA. + +The next time the user logs in, they will need to setup their MFA just like a new user. + +## Reset MFA using the Management API + +As an admin, you can also use the Management API to delete a user's MFA enrollment using `DELETE /api/v2/guardian/enrollments/{id}`. This requires getting the enrollment ID first with a `GET` to the same endpoint. If the user has more than one enrollment, you will need to repeat the process for each enrollment. + +## Recovery codes + +With most MFA factors, the end user will be given a recovery code upon signup, which should be noted and kept secret. If they do not have their device or are otherwise temporarily unable to use their normal MFA process, the user can log in by entering this code after their username and password. + +![MFA Recovery Code](/media/articles/mfa/recovery-code.png) + +::: note +If a recovery code is used, a new recovery code will be provided at that time. +::: + +If a user uninstalls then later re-installs Guardian, they may be prompted to enter their recovery code. If the recovery code has been lost, the user can perform a new installation of the app by disabling automatic restoration of their Guardian backup. To do so, the user will need to uninstall Guardian, temporarily disable automatic restoration of backups within their device settings (steps to do so will vary according to the device), then re-install the app. They will then need to add their MFA account(s) to the app as if performing a first-time setup. If automatic backups or automatic restoration are not enabled on the user's device, re-installation of the app will not prompt for a recovery code and the user will be required to add their MFA account(s) as in a first-time setup. + +## Keep reading + +* [Reset Auth0 Account Password](/support/reset-account-password) diff --git a/fr-ca/articles/mfa/index.md b/fr-ca/articles/mfa/index.md new file mode 100644 index 0000000000..a31faa4646 --- /dev/null +++ b/fr-ca/articles/mfa/index.md @@ -0,0 +1,31 @@ +--- +title: Multi-factor Authentication +description: Understand how MFA works in Auth0. +classes: topic-page +topics: + - mfa +contentType: + - index +useCase: + - customize-mfa +--- +# Multi-factor Authentication + +Multi-factor Authentication (MFA) provides a method to verify a user's identity by requiring them to provide more than one piece of identifying information. This ensures that only valid users can access their accounts even if they use a username and password that may have been compromised from a different application. + +To enable MFA, go to [Dashboard > Multifactor Auth](${manage_url}/#/guardian) and toggle on the factors you want to enable on your tenant, such as push notifications or SMS. Next, perform any further setup required to configure that factor, then choose whether you wish to force MFA for all users or not. You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication) to allow MFA to only be required in specific circumstances or force a particular factor to be used. + +See the following sections for more details: + +<%= include('../_includes/_topic-links', { links: [ + 'mfa/concepts/mfa-factors', + 'mfa/guides/enable-mfa', + 'mfa/concepts/guardian', + 'mfa/guides/customize-mfa-universal-login', + 'mfa/guides/reset-user-mfa', + 'mfa/guides/import-user-mfa', + 'mfa/concepts/mfa-developer-resources', + 'mfa/concepts/step-up-authentication', + 'mfa/references/troubleshoot-mfa' +] }) %> + diff --git a/fr-ca/articles/mfa/references/guardian-error-code-reference.md b/fr-ca/articles/mfa/references/guardian-error-code-reference.md new file mode 100644 index 0000000000..696d3e70de --- /dev/null +++ b/fr-ca/articles/mfa/references/guardian-error-code-reference.md @@ -0,0 +1,49 @@ +--- +title: Guardian Error Code Reference +description: Lists Guardian error codes and descriptions. +topics: + - guardian +contentType: + - reference +useCase: + - customize-mfa +--- +# Guardian Error Code Reference + +Use the error codes to display informative messages and to distinguish between recoverable and unrecoverable errors. + +| Error Code | Description | +| -- | -- | +| `invalid_token` | Invalid request or transaction token +| `insufficient_scope` | You don't have enought grants to perform the requested operation +| `invalid_bearer_format` | The bearer put in authentication header was not valid +| `enrollment_conflict` | There is another enrollment for the same user. You cannot enroll twice. +| `tenant_not_found` | The tenant associated cannot be found. Should not normally happen at least that you delete the tenant +| `login_transaction_not_found` | The mfa auth transaction is not active or has already expired +| `error_sending_push_notification` | Push notification delivery failed +| `push_notification_wrong_credentials` | Push notification delivery failed because of wrong credentials +| `invalid_otp` | Provided otp code was not valid +| `invalid_recovery_code` | Provided recovery code was not valid +| `invalid_body` | Body validation failed. Bad request. +| `invalid_query_string` | Query string validation failed. Bad request. +| `enrollment_transaction_not_found` | The mfa enrollment transaction is not active or has expired +| `invalid_phone_number` | The provided phone number is invalid +| `error_sending_sms` | SMS Delivery error +| `feature_disabled` | The requested feature is currently globally not available (contact the provider) +| `feature_disabled_by_admin` | The requested feature is currently disabled by your admin +| `pn_endpoint_disabled` | We were unable to deliver the push notification after retrying many times. Try removing you account for the device and adding it again. +| `too_many_sms` | You have exeed the amount of SMSs assigned to your user +| `too_many_pn` | You have exeed the amount of push notifications assigned to your user +| `too_many_sms_per_tenant` | You have exeed the amount of SMSs assigned to your tenant +| `too_many_pn_per_tenant` | You have exeed the amount of push notifications assigned to your tenant +| `field_required` | A field is required to perform the operation (this errors has a field attribute with a code for the field: `otpCode`, `recoveryCode`) +| `method_not_found` | You have requested a method that is currently not supported (should not happen) +| `no_method_available` | There is currently no method to enroll (all of them are disabled) +| `enrollment_method_disabled` | The specified enrollment method is disabled, this error has also a .method field +| `auth_method_disabled` | The specified authentication method is disabled, this error has also a .method field +| `invalid_otp_format` | OTP format validation error +| `invalid_recovery_code_format` | Recovery code format validation error +| `transaction_expired` | The transaction has already expired +| `already_enrolled` | You are already enrolled, cannot enroll again +| `not_enrolled` | You not enrolled. Must enroll first +| `invalid_enrollment` | The enrollment provided to transaction#requestAuth method is not valid or is null/undefined diff --git a/fr-ca/articles/mfa/references/language-dictionary.md b/fr-ca/articles/mfa/references/language-dictionary.md new file mode 100644 index 0000000000..614f9d1c5f --- /dev/null +++ b/fr-ca/articles/mfa/references/language-dictionary.md @@ -0,0 +1,231 @@ +--- +description: Describes the MFA hosted page configuration options for customizing the theme properties of the MFA pages. +topics: + - mfa + - hosted-pages +contentType: reference +useCase: customize-hosted-pages +--- +# MFA Theme Language Dictionary + +## defaultLocation + +```js +return new Auth0MFAWidget({ + +... + + defaultLocation : ['United Kingdom', 'GB', '+44'], + +... + +}) +``` + +## languageDictionary + +The `languageDictionary` can be used to override the text for many areas of the MFA process on Universal Login Classic Experience. You do this with the following format: + +``` +languageDictionary: + optionsCategory: + option: value +``` + +Here is an example, modifying the `headerText` attribute in `smsEnrollmentConfirm`: + +```js +return new Auth0MFAWidget({ + +... + + languageDictionary:{ // Use the Language Dictionary option + smsEnrollmentConfirm:{ // Indicate which category/section you are modifying + headerText: "Some custom text - In order to confirm enrollment we need to confirm your phone. Please enter the received code." // Provide the new value for the specific attribute you wish to modify + } + } + +... + +}) +``` + +See below for a list of available categories and options. + +### languageDictionary options + +```js +defaults: { + iddleHelpUrl: '#', + rememberBrowserCheckbox: 'Remember this browser', + title: 'Login to {tenantName}' +}, + +downloadApp: { + headerText: 'Download Auth0 Guardian for free:', + pushEnrollmentAction: 'I\'ve already downloaded it', + smsAndTotpEnrollmentActions: 'I\'d rather use SMS or Google Authenticator', + pushAndTotpEnrollmentActions: 'I\'d rather use Guardian or Google Authenticator', + pushAndSmsEnrollmentActions: 'I\'d rather use Guardian or SMS', + totpEnrollmentActions: 'I\'d rather use Google Authenticator', + smsEnrollmentActions: 'I\'d rather use SMS', + pushEnrollmentActions: 'I\'d rather use Guardian', + iosLabel: 'App Store', + iosUrl: 'https://itunes.apple.com/us/app/auth0-guardian/id1093447833?ls=1&mt=8', + iosImg: '', + androidLabel: 'Google Play', + androidUrl: 'https://play.google.com/store/apps/details?id=com.auth0.guardian', + androidImg: '' +}, + +pushAuth: { + pushSent: { + useTotpFallback: 'If you haven\'t received the notification,

just enter the code manually.' + }, + + pushTimeout: { + resendAction: 'Resend push notification', + timeoutText: 'Didn\'t receive the push notification?', + useRecoveryCode: 'Lost your device? Use the recovery code', + useTotpFallback: 'Enter the code manually' + } +}, + +totpAuth: { + codePlaceholder: 'Enter the 6-digit code', + headerText: 'Get a verification code from the Google Authenticator (or similar) app:', + useRecoveryCode: 'Lost your device? Use the recovery code' +}, + +smsAuth: { + codePlaceholder: 'Enter the 6-digit code', + headerText: 'Enter the 6-digit code we\'ve just sent to your phone.', + useRecoveryCode: 'Lost your device? Use the recovery code' +}, + +guardianTotpAuth: { + codePlaceholder: 'Enter the 6-digit code', + headerText: 'Get a verification code from the Auth0 Guardian app.' +}, + +recoveryCodeAuth: { + codePlaceholder: 'Enter your code here', + headerText: 'We will generate a new recovery code
once you\'ve logged in:' +}, + +pushEnrollment: { + headerText: 'Scan this code with Auth0 Guardian:' +}, + +enrollmentCongrats: { + congrats: 'Congratulations, you are all set.
In the future when logging in you\'ll want your device handy.', + continueButtonText: 'Continue' +}, + +reportRecoveryCode: { + headerText: 'In the event that you need to login without your device you\'ll need a recovery code. Take a note and keep this somewhere safe:', + confirmationLabel: 'I have safely recorded this code' +}, + +generalError: { + errorsRecoveryHelp: { + default: 'Looks like something went wrong.
Please try logging in again from the application.', + + globalTransactionExpired: 'The login was not successful.
Please try again.', + + // Auth0 Server Errors + guardianInvalidNonce: 'Please try logging in again from the application.', + guardianInvalidToken: 'Please try logging in again from the application.', + invalidLoginTokenStatus: 'Please try logging in again from the application.', + loginTokenInvalidSignature: 'Please try logging in again from the application.', + loginTokenTransactionExpired: 'Please try logging in again from the application.' + } +}, + +smsEnrollmentConfirm: { + codePlaceholder: 'Enter the 6-digit code', + headerText: 'In order to confirm enrollment we need to confirm your phone. Please enter the received code.' +}, + +totpEnrollment: { + codePlaceholder: 'Enter your passcode here', + headerText: 'Scan this QR code with Google Authenticator (or similar) app:' +}, + +totpEnrollmentCode: { + codePlaceholder: 'Enter your passcode here', + headerText: 'Manually enter the following code into your preferred authenticator app and then enter the provided one-time code below.', + copyCodeButton: 'Copy code' +}, + +smsEnrollmentAddPhoneNumber: { + headerText: 'Please enter your phone
in order to enroll.', + phoneNumberLabel: 'A code will be sent to this number:', + phoneNumberPlaceholder: 'Your phone number' + // countryCodes: { 'US': 'Translation of United States', ... '': '' } +}, + +authCongrats: { + congrats: 'We have verified your identity. Redirecting...', + congratsNoRedirect: 'We have verified your identity.', + continueButtonText: 'Continue' +}, + +errorMessages: { + alreadyEnrolled: 'You are already enrolled, cannot enroll again', + authMethodDisabled: 'The specified authentication method is disabled', + connectionError: 'Looks like we cannot contact our server. Please check your internet connection and retry.', + default: 'Looks like something went wrong. Please retry.', + defaultRequest: 'Looks like we found a problem contacting our server. Please retry.', + enrollmentConflict: 'Seems that you have already enrolled. Try logging in again from the application.', + enrollmentMethodDisabled: 'The specified enrollment method is disabled', + enrollmentNotFound: 'We couldn\'t find your enrollment. You\'ve probably started enrollment from another device. Finish it there or try logging in again from the application.', + enrollmentTransactionNotFound: 'The mfa enrollment transaction is not active or has expired. Please try again.', + errorSendingPushNotification: 'We found an error sending your notification. Please try again.', + errorSendingPushNotificationManualFallback: 'We could not send the push. Please enter the code manually.', + errorSendingSms: 'We found an error sending your code. Please try again in a few seconds.', + errorSendingSmsManualFallback: 'We could not send the sms. Please try the recovery code.', + featureDisabled: 'This module is currently disabled.', + featureDisabledByAdmin: 'This module was disabled by the admin.', + fieldRequired: 'Please fill out required field.', + globalTransactionExpired: 'Your login attempt has timed out.', + guardianInvalidNonce: 'There was a problem authenticating your request origin. Have you started too many parallel logins?', + guardianInvalidToken: 'There was a problem validating authentication request format.', + insufficientScope: 'Seems that you are not authorized to perform this action.', + invalidBearerFormat: 'Seems that you are not authorized to perform this action.', + invalidLoginTokenStatus: 'Unexpected state validating your request.', + invalidOtp: 'Seems that your code is not valid, please check and retry.', + invalidOtpFormat: 'OTP Code must have 6 numeric characters', + invalidPhoneNumber: 'Seems that your phone number is not valid. Please check and retry.', + invalidRecoveryCode: 'Seems that your recovery code is not valid. Please check and try again.', + invalidRecoveryCodeFormat: 'Recovery code must have 24 alphanumeric characters', + invalidToken: 'Seems that you are not authorized to perform this action.', + loginRejected: 'Auth has been rejected. Try again.', + loginTokenInvalidSignature: 'We cannot verify who seems to be the issuer for this request', + loginTokenTransactionExpired: 'Your authentication request is expired. Is your connection slow?', + loginTransactionNotFound: 'Seems that your device has taken too long to login. Please try again.', + noMethodAvailable: 'There is currently no authentication method available.', + noPublicKeyAvailable: 'We cannot verify your identity. Contact tenant admin.', + pnEndpointDisabled: 'Seems that we cannot deliver messages to your cell phone. Please try again.', + pushNotificationNotConfigured: 'Seems that enrollment was not finished. Please try logging in again from the application.', + pushNotificationWrongCredentials: 'Seems that your device credentials are outdated. Please re-enroll your device or wait for them to be updated.', + smsNotConfigured: 'You cannot use this module because you\'ve enrolled with a different one.', + socketError: 'We cannot connect to real time channel.', + // tenant_not_found | The tenant associated cannot be found. Should not normally happen at least that you delete the tenant + tooManyPn: 'You have exceeded the amount of push notifications per minute. Please wait and try again.', + tooManyPnPerTenant: 'There are too many push requests right now. Wait a few minutes and try again.', + tooManySms: 'You have exceeded the amount of SMSs per hour. Wait a few minutes and try again.', + tooManySmsPerTenant: 'There are too many SMSs right now. Wait a few minutes and try again.' + // | transaction_expired | The transaction has already expired | +}, + +successMessages: { + auth: 'We have successfully verified your identity. Redirecting...', + pushSent: 'We\'ve sent a push to: {enrollmentName}', + smsSent: 'We\'ve sent an sms to: {phoneNumber}' +}, + +infoMessages: { + iddle: 'Can we help you?

Click here to learn more' +} +``` diff --git a/fr-ca/articles/mfa/references/mfa-widget-reference.md b/fr-ca/articles/mfa/references/mfa-widget-reference.md new file mode 100644 index 0000000000..edcdd1dce7 --- /dev/null +++ b/fr-ca/articles/mfa/references/mfa-widget-reference.md @@ -0,0 +1,59 @@ +--- +description: Describes the MFA Widget theme options for customizing the theme properties of the MFA pages. +topics: + - mfa + - hosted-pages +contentType: reference +useCase: customize-hosted-pages +--- +# MFA Widget Theme Options + +When using your own HTML, it uses the Auth0 MFA Widget, which has the following limitations: +- It does not support MFA with Email. +- If users enrolled more than one factor, they cannot select which one to use, the MFA widget will ask them to login with the most secure factor. +- It does not use Universal Login's [internationalization](/universal-login/i18n) features + +There are a few theming options for the MFA Widget, namespaced under the `theme` property. + +## icon + +The value for `icon` is the URL for an image that will be used in the MFA Widget header, which defaults to the Auth0 logo. It has a recommended max height of `58px` for a better user experience. + +```js +return new Auth0MFAWidget({ + +... + + theme: { + icon: 'https://example.com/assets/logo.png' + }, + +... + +}) +``` + +## primaryColor + +The `primaryColor` property defines the primary color of the MFA Widget. This option is useful when providing a custom `icon`, to ensure all colors go well together with the `icon`'s color palette. Defaults to `#ea5323`. + +```js +return new Auth0MFAWidget({ + +... + + theme: { + icon: 'https://example.com/assets/logo.png', + primaryColor: 'blue' + }, + +... + +}) +``` + +## Keep reading + +* [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js) +* [Widget Example Using auth0-guardian.js](https://github.com/auth0/auth0-guardian.js/tree/master/example) +* [Multi-factor Authentication with Classic Universal Login](/universal-login/multifactor-authentication) diff --git a/fr-ca/articles/mfa/references/troubleshoot-mfa.md b/fr-ca/articles/mfa/references/troubleshoot-mfa.md new file mode 100644 index 0000000000..be1bb19a8e --- /dev/null +++ b/fr-ca/articles/mfa/references/troubleshoot-mfa.md @@ -0,0 +1,63 @@ +--- +description: Describes basic troubleshooting of MFA issues for end-users. +topics: + - mfa +contentType: + - reference +useCase: + - customize-mfa +--- +# Troubleshoot Multi-Factor Authentication + +This guide serves as a troubleshooting reference if you have end-users unable to log in with multi-factor authentication (MFA). + +## Generic issues + +### If you do not have your mobile device, or your mobile device is turned off + +If you have lost your device, you can finish authentication using the recovery code provided when you first signed up. + +1. Enter your email and password to log in, and click the **Use the recovery code** link. +2. Enter your recovery code. + +If you no longer have your recovery code, you will not be able to log in. Contact your system administrator for help accessing your account. + +### If you forget your password + +If you have forgotten your password, click the **Don't remember your password?** link located underneath the email and password fields. Then, enter your email address to receive an email containing a link you can use to reset your password. + +### If your transaction expires + +When logging in via MFA, there is a five-minute maximum between providing your first and second factors. You can see how much time has elapsed since you logged in using the first factor by checking the timestamp on the messages provided. + +If more than five minutes has elapsed, you will need to log in again and obtain a new code or notification. + +If you are requesting SMS or Voice messages, make sure you are not [exceeding rate limits](#sms-rate-limits). + +### If you need to remove or delete MFA from a user in your tenant + +If you need to remove, delete, or reset MFA for a user, you should [reset MFA](/mfa/guides/reset-user-mfa). + +## Phone messaging-related issues + +### SMS message rate limits + +If a user attempts to send more than ten SMS or Voice messages within one hour, they will see an error message saying so. + +When they exceed your messaging limit, they'll need to wait at least an hour after they sent the first message before sending another. They will receive an additional attempt after the passage of each additional hour. + +## Rejected Codes + +If the 6-digit code in the Guardian or the Google Authenticator app are being rejected for sign in (often with the message `Incorrect Code`), first check that you are selecting the right application from the list in your authenticator app. If you've verified that you're selecting the correct application, make sure that your mobile device's clock settings are correct. One-time passwords are generated using Coordinated Universal Time (UTC), so your device's time must be correct for your code to work. + +To check your clock settings: + +* **Android Devices** - Go **Settings** > **Date & Time**. Make sure that the box next to **Automatic** is checked. + +* **iOS Devices** - Go to **Settings** > **General** > **Date & Time**. Enable **Set Automatically**. If this setting was already enabled, you can disable it for a moment, then re-enable. + +## Duo-related issues + +For questions or issues specifically regarding Duo, [see Duo's documentation](https://guide.duo.com). + +Android, then tap "Settings." Scroll down to the bottom of the Settings menu, then tap "Date & Time." Tap the box next to "Automatic" to un-check it. diff --git a/fr-ca/articles/mfa/send-phone-message-hook-amazon-sns.md b/fr-ca/articles/mfa/send-phone-message-hook-amazon-sns.md new file mode 100644 index 0000000000..e5ad994552 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-amazon-sns.md @@ -0,0 +1,152 @@ +--- +title: Configure a Custom SMS Provider for MFA using Amazon SNS +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Amazon SNS. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Amazon SNS + +This guide explains how to send Multi-factor Authentication (MFA) text messages using the Amazon Simple Notification Service (SNS). + +<%= include('./_includes/_test-setup') %> + +## What is Amazon SNS? + +Amazon Simple Notification Service (SNS) is a pub/sub messaging service that enables Auth0 to deliver multi-factor verification via text messages. To learn more, see [Amazon's SNS Overview](https://aws.amazon.com/sns). + +## Prerequisites + +Before you begin this tutorial, please: + +* Sign up for an [Amazon Web Services](https://portal.aws.amazon.com/billing/signup#/start). +* Capture your Amazon Web Service region. +* Create a new Amazon IAM User with the `AmazonSNSFullAccess` role. +* Capture the user's access key and secret key details. + +## Steps + +To configure a custom SMS provider for MFA using Amazon SNS, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the AWS SNS call](#add-the-aws-sns-call) +4. [Add the AWS SDK NPM package](#add-the-aws-sdk-npm-package) +5. [Test your Hook implementation](#test-your-hook-implementation) +6. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +7. [Test the MFA flow](#test-the-mfa-flow) + +Optional: [Troubleshoot](#troubleshoot) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook secrets + +Add three [Hook Secrets](/hooks/secrets/create) with keys `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_REGION`, with the corresponding values from your Amazon account. + +### Add the AWS SNS call + +To make the call to AWS SNS, add the appropriate code to the Hook. + +Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling AWS SNS to send a verification code via SMS. + +```js +// Load the SDK +var AWS = require("aws-sdk"); + +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one-time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + process.env.AWS_ACCESS_KEY_ID = context.webtask.secrets.AWS_ACCESS_KEY_ID; + process.env.AWS_SECRET_ACCESS_KEY = context.webtask.secrets.AWS_SECRET_ACCESS_KEY; + process.env.AWS_REGION = context.webtask.secrets.AWS_REGION; + + var params = { Message: text, PhoneNumber: recipient }; + + var publishTextPromise = new AWS.SNS({ apiVersion: "2010-03-31" }) + .publish(params) + .promise(); + + publishTextPromise + .then(function() { + cb(null, {}); + }) + .catch(function(err) { + cb(err); + }); +}; +``` + +### Add the AWS SDK NPM package + +The Hook uses the [AWS SDK for JavaScript in Node.js](https://aws.amazon.com/sdk-for-node-js/), so you'll need to include this package in your Hook. + +1. Click the **Settings** icon again, and select **NPM Modules**. + +2. Search for `aws-sdk` and add the module that appears. + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes via the Vonage SMS API. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and ensure that: + +- The Hook is active and the SMS configuration is set to use `Custom`. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones you created in the Amazon Web Services portal. +- Your Amazon Web Services user has access to the `AmazonSNSFullAccess` role. +- Your Amazon Web Services account is active (not suspended). +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-esendex.md b/fr-ca/articles/mfa/send-phone-message-hook-esendex.md new file mode 100644 index 0000000000..8292c86b70 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-esendex.md @@ -0,0 +1,150 @@ +--- +title: Configure a Custom SMS Provider for MFA using Esendex +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Esendex. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Esendex + +This guide explains how to send Multi-factor Authentication (MFA) text messages using Esendex and the Send Phone Message Hook. + +<%= include('./_includes/_test-setup') %> + +## What is Esendex? + +Esendex provides an SMS messaging service that can be used by Auth0 to deliver multi-factor verification via text messages. + +## Prequisites + +Before you begin this tutorial, please: + +- [Sign up with Esendex](https://www.esendex.co.uk/#freetrialformblock) and complete your profile and confirmation steps. Once this is complete, you should be able to access the SMS API. Here, you can try out the API with a test number. + +## Steps + +To configure a custom SMS provider for MFA using Esendex, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the Esendex call](#add-the-esendex-call) +4. [Test your Hook implementation](#test-your-hook-implementation) +5. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +6. [Test the MFA flow](#test-the-mfa-flow) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook Secrets + +You're going to store the values needed from Esendex in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +[Add Hook Secrets](/hooks/secrets/create) with the following settings: + +* `ESENDEX_ACCOUNT` - Esendex Account (from the [Esendex Dashboard](https://admin.esendex.com/accounts)) +* `ESENDEX_USERNAME` - Esendex Username +* `ESENDEX_PASSWORD` - Esendex Password + +### Add the Esendex call + +To make the call to Esendex, add the appropriate code to the Hook. + +Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Esendex to send a verification code via SMS. You can learn more about the Esendex API in [Esendex's API documentation](https://developers.esendex.com/api-reference#smsapis). + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + const axios = require('axios').default; + + const instance = axios.create({ + baseURL: "https://api.esendex.com/", + headers: { + "Content-Type": "application/json", + "Accept-Encoding": "gzip, deflate, br", + "Accept": "application/json" + }, + }); + instance({ + method: 'post', + auth: { + username: context.webtask.secrets.ESENDEX_USERNAME, + password: context.webtask.secrets.ESENDEX_PASSWORD + }, + url: '/v1.0/messagedispatcher', + data: JSON.stringify({ + accountreference: context.webtask.secrets.ESENDEX_ACCOUNT, + messages: [{ to: recipient, body: text }] + }) + }) + .then((response) => { + cb(null, {}); + }) + .catch((error) => { + cb(error); + }); +}; +``` + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and make sure that: + +- The Hook is active and the SMS configuration is set to use 'Custom'. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones you got from Esendex. +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-infobip.md b/fr-ca/articles/mfa/send-phone-message-hook-infobip.md new file mode 100644 index 0000000000..7922543369 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-infobip.md @@ -0,0 +1,156 @@ +--- +title: Configure a Custom SMS Provider for MFA using Infobip +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Infobip. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Infobip + +This guide explains how to send Multi-factor Authentication (MFA) text messages using Infohip. + +<%= include('./_includes/_test-setup') %> + +## What is Infobip? + +Infobip SMS is a messaging platform that enables Auth0 to deliver multi-factor verification via text messages. To learn more, see [Infobip's SMS Overview](https://www.infobip.com/products/sms). + +## Prerequisites + +Before you begin this tutorial, please: + +* Log in to the [Infobip Portal](https://portal.infobip.com/) or [sign up for a free trial](https://www.infobip.com/signup). +* Create and capture a new API Key on the [Infobip API Keys](https://portal.infobip.com/.settings/accounts/api-keys) page. + +## Steps + +To configure a custom SMS provider for MFA using Infobip, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the Infobip call](#add-the-infobip-call) +4. [Test your Hook implementation](#test-your-hook-implementation) +5. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +6. [Test the MFA flow](#test-the-mfa-flow) + +Optional: [Troubleshoot](#troubleshoot) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook Secrets + +You're going to store the value needed from the Infobip portal in a [Hook Secret](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +[Add a Hook Secret](/hooks/secrets/create) with the following settings. You can find the value for the secret on the [Infobip API Keys](https://portal.infobip.com/.settings/accounts/api-keys) page. + +* `INFOBIP_API_KEY` - Infobip API key + +### Add the Infobip call + +To make the call to Infobip, add the appropriate code to the Hook. + +Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Infobip to send a verification code via SMS. + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + + const axios = require('axios').default; + const API_KEY = context.webtask.secrets.API_KEY;; + const BASE_URL = 'https://2622w.api.infobip.com'; + const instance = axios.create({ + baseURL: BASE_URL, + headers: { + 'Authorization': 'App ' + API_KEY, + 'Accept': 'application/json', + 'Content-Type': 'application/json' + }, + }); + instance({ + method: 'post', + url: '/sms/2/text/advanced', + data: { + "messages": [ + { + "destinations": [ + { "to": recipient } + ], + "text": text + } + ] + } + }) + .then((response) => { + cb(null, {}); + }) + .catch((error) => { + cb(error); + }); + +}; +``` + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes via Infobip. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and make sure that: + +- The Hook is active and the SMS configuration is set to use 'Custom'. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones you created in the Infobip portal. +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-mitto.md b/fr-ca/articles/mfa/send-phone-message-hook-mitto.md new file mode 100644 index 0000000000..3398326f20 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-mitto.md @@ -0,0 +1,142 @@ +--- +title: Configure a Custom SMS Provider for MFA using Mitto +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Mitto. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Mitto + +This guide explains how to send Multi-factor Authentication (MFA) text messages using Mitto and the Send Phone Message Hook. + +<%= include('./_includes/_test-setup') %> + +## What is Mitto? + +Mitto provides an SMS messaging service that can be used by Auth0 to deliver multi-factor verification via text messages. + +## Prequisites + +Before you begin this tutorial, please [create an account with Mitto](https://info.mitto.ch/mitto-auth0). You will get an API Key and a Sender ID that you can then use to invoke Mitto's APIs. + +## Steps + +To configure a custom SMS provider for MFA using Mitto, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the Mitto call](#add-the-mitto-call) +4. [Test your Hook implementation](#test-your-hook-implementation) +5. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +6. [Test the MFA flow](#test-the-mfa-flow) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook Secrets + +You're going to store the values needed from Mitto in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +[Add Hook Secrets](/hooks/secrets/create) with the following settings: + +* `MITTO_API_KEY` - The API Key provided by Mitto + +### Add the Mitto call + +To make the call to Mitto, add the appropriate code to the Hook. + +Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Mitto to send a verification code via SMS. You can learn more about the Mitto API in [Mitto's API documentation](https://info.mitto.ch/hubfs/Developer%20Guides/Mitto%20SMS%20API%202.0%20Developer%20Guide%20v2.5.pdf). + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + const axios = require('axios').default; + + const instance = axios.create({ + baseURL: "https://rest.mittoapi.com/", + headers: { + "Content-Type": "application/json", + "X-Mitto-API-Key": context.webtask.secrets.MITTO_API_KEY + }, + }); + instance({ + method: 'post', + url: '/sms.json', + data: JSON.stringify({ + to: recipient, + from: "Mitto SMS", // The Mitto Sender ID + text: text + }) + }) + .then((response) => { + cb(null, {}); + }) + .catch((error) => { + cb(error); + }); +}; +``` + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and make sure that: + +- The Hook is active and the SMS configuration is set to use 'Custom'. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones you got from Mitto. +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-telesign.md b/fr-ca/articles/mfa/send-phone-message-hook-telesign.md new file mode 100644 index 0000000000..1d13504eaa --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-telesign.md @@ -0,0 +1,207 @@ +--- +title: Configure a Custom SMS Provider for MFA using TeleSign +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using TeleSign. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using TeleSign + +This guide explains how to send Multi-factor Authentication (MFA) text messages using Telesign. + +<%= include('./_includes/_test-setup') %> + +## What is Telesign? + +Telesign provides two different APIs, both of which may be used alongside Auth0 to deliver multi-factor verification via text messages: + +* [TeleSign SMS](https://www.telesign.com/products/sms-api): Allows you to build and manage SMS communications and security verification processes. +* [TeleSign SMS Verify](https://www.telesign.com/products/sms-verify): Helps you manage the SMS verification process and is available in the Enterprise plan. + +## Prerequisites + +Before you begin this tutorial, please: + +* Log in to your TeleSign portal (either the [TeleSign Enterprise Portal](https://teleportal.telesign.com) or the [TeleSign Standard Portal](https://portal.telesign.com/)). +* Capture the Customer ID and API Keys from your TeleSign account. + +## Steps + +To configure a custom SMS provider for MFA using Telesign, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the Telesign call](#add-the-telesign-call) +4. [Test your Hook implementation](#test-your-hook-implementation) +5. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +6. [Test the MFA flow](#test-the-mfa-flow) + +Optional: [Troubleshoot](#troubleshoot) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook Secrets + +You're going to store the values needed from the Telesign portal in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +[Add Hook Secrets](/hooks/secrets/create) with the following settings. You can find the values for the secrets in your Telesign portal. + +* `TELESIGN_CUSTOMER_ID`: Telesign Customer ID +* `TELESIGN_API_KEY`: Telesign API Key + +### Add the Telesign call + +To make the call to Telesign, add the appropriate code to the Hook. + +Copy the appropriate code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Telesign to send a verification code via SMS. + +#### SMS API + +If you are calling the SMS API, use the following code: + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function (recipient, text, context, cb) { + + const axios = require('axios').default; + const querystring = require('querystring'); + + const customerId = context.webtask.secrets.TELESIGN_CUSTOMER_ID; + const restApiKey = context.webtask.secrets.TELESIGN_REST_API_KEY; + + const instance = axios.create({ + // If you are using the standard TeleSign plan the URL should be https://rest-api.telesign.com/ + baseURL: "https://rest-ww.telesign.com", + headers: { + 'Content-Type': 'application/x-www-form-urlencoded' + }, + }); + + instance({ + method: 'post', + auth: { + username: customerId, + password: restApiKey + }, + url: '/v1/messaging', + data: querystring.stringify({ + phone_number: recipient, + message_type: 'ARN', + message: text + }) + }) + .then((response) => { + cb(null, {}); + + }) + .catch((error) => { + cb(error); + }); +} +``` + +#### SMS Verify API + +If you are calling the SMS Verify API, use the following code: + +```js +module.exports = function(recipient, text, context, cb) { + + const axios = require('axios').default; + const querystring = require('querystring'); + + const customerId = context.webtask.secrets.TELESIGN_CUSTOMER_ID; + const restApiKey = context.webtask.secrets.TELESIGN_API_KEY; + + const instance = axios.create({ + baseURL: "https://rest-ww.telesign.com", + headers: { + 'Content-Type': 'application/x-www-form-urlencoded' + }, + }); + + instance({ + method: 'post', + auth: { + username: customerId, + password: restApiKey + }, + url: '/v1/verify/sms', + data: querystring.stringify({ + phone_number: recipient, + template: text + }) + }) + .then((response) => { + cb(null, {}); + }) + .catch((error) => { + cb(error); + }); +} +``` + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes via the Telesign. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and make sure that: + +- The Hook is active and the SMS configuration is set to use 'Custom'. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones provided in the TeleSign portal. +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-twilio.md b/fr-ca/articles/mfa/send-phone-message-hook-twilio.md new file mode 100644 index 0000000000..6abffb4b49 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-twilio.md @@ -0,0 +1,211 @@ +--- +title: Configure a Custom SMS Provider for MFA using Twilio +description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Twilio. +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Twilio + +This guide explains how to send Multi-factor Authentication (MFA) text messages using Twilio and the Send Phone Message Hook. + +Auth0 has built-in support for sending messages through Twilio. However, you may want to add specific logic before sending a message or want to send a different message depending on the user or the application. In this case, you would configure SMS MFA to use a Send Phone Message Hook. + +<%= include('./_includes/_test-setup') %> + +## What is Twilio? + +Twilio provides an SMS messaging service which can be used by Auth0 to deliver multi-factor verification via text messages. It provides two different APIs: + + - [Programmable SMS](https://www.twilio.com/sms) is a flexible API designed to fully automate SMS communications. + - [Verify](https://www.twilio.com/verify) is an API designed to send one-time codes while hiding the complexity of SMS delivery. + +## Prerequisites + +Before you begin this tutorial, please: + +* Sign up for a [Twilio](https://www.twilio.com/try-twilio) account. +* Create a new Messaging Service in the [Programmable SMS console](https://www.twilio.com/console/sms/services) or in the [Verify console](https://www.twilio.com/console/verify/services) depending on the API you want to use. +* If you use Programmable SMS, you need to add a phone number that is enabled for SMS to your service and capture the number. +* If use the Verify API, you need to make sure that the Twilio Verify Service is configured to accept a custom code. At the time of writing, you need to contact Twilio support to get it enabled. +* Capture the Account SID and Authorization Token by clicking *Show API Credentials* in the [Twilio SMS Dashboard](https://www.twilio.com/console/sms/dashboard) + +## Steps + +To configure a custom SMS provider for MFA using Twilio, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Add the Twilio call](#add-the-twilio-call) +4. [Add the Twilio Node JS Helper NPM package](#add-the-twilio-node-js-helper-npm-package) +5. [Test your Hook implementation](#test-your-hook-implementation) +6. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +7. [Test the MFA flow](#test-the-mfa-flow) + +### Create a Send Phone Message Hook + +You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation. + +::: note +You can only have **one** Send Phone Message Hook active at a time. +::: + +### Configure Hook Secrets + +You're going to store the values needed from the Twilio SMS Dashboard in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +[Add Hook Secrets](/hooks/secrets/create) with the following settings. You can find the values for the secrets in your [Twilio SMS Dashboard](https://www.twilio.com/console/sms/dashboard). + +* `TWILIO_ACCOUNT_SID`: Twilio Account SID +* `TWILIO_AUTH_TOKEN`: Twilio Authorization token +* `TWILIO_PHONE_NUMBER`: Twilio "from" sending number + +### Add the Twilio call + +To make the call to Twilio, add the appropriate code to the Hook. + +[Edit](/hooks/update) the Send Phone Message Hook code and copy of the code snippets below, depending on the API you want to use. This function will run each time a user requires MFA, calling Twilio to send a verification code via SMS. + +To use the Programmable SMS API, use the code below. + +```js +/** +@param {string} recipient - phone number +@param {string} text - message body +@param {object} context - additional authorization context +@param {string} context.factor_type - 'first' or 'second' +@param {string} context.message_type - 'sms' or 'voice' +@param {string} context.action - 'enrollment' or 'authentication' +@param {string} context.language - language used by login flow +@param {string} context.code - one time password +@param {string} context.ip - ip address +@param {string} context.user_agent - user agent making the authentication request +@param {string} context.client_id - to send different messages depending on the client id +@param {string} context.name - to include it in the SMS message +@param {object} context.client_metadata - metadata from client +@param {object} context.user - To customize messages for the user +@param {function} cb - function (error, response) +*/ +module.exports = function(recipient, text, context, cb) { + + const accountSid = context.webtask.secrets.TWILIO_ACCOUNT_SID; + const authToken = context.webtask.secrets.TWILIO_AUTH_TOKEN; + const fromPhoneNumber = context.webtask.secrets.TWILIO_PHONE_NUMBER; + + const client = require('twilio')(accountSid, authToken); + + if (context.message_type === "sms") { + client.messages + .create({ + body: text, + from: fromPhoneNumber, + to: recipient + }) + .then(function() { + cb(null, {}); + }) + .catch(function(err) { + cb(err); + }); + } + else { + const sayInCall = ` + + Hello, your code is {{code}}. + ` + client.calls + .create({ + twiml: sayInCall, + to: recipient, + from: fromPhoneNumber, + timeout: 30, + }) + .then(function() { + cb(null, {}) + ) + .catch(function(err) { + cb(err) + } + }; + } +}; +``` + +To use the Verify API, use the code below. + +```js +module.exports = function(recipient, text, context, cb) { + + const accountSid = context.webtask.secrets.TWILIO_ACCOUNT_SID; + const authToken = context.webtask.secrets.TWILIO_AUTH_TOKEN; + const fromPhoneNumber = context.webtask.secrets.TWILIO_PHONE_NUMBER; + + const client = require('twilio')(accountSid, authToken); + + client.verify.services(accountSid) + .verifications + .create({ + to: recipient, + channel: 'sms', + customCode: context.code + }) + .then(function() { + cb(null, {}); + }) + .catch(function(err) { + cb(err); + }); +}; +``` + +### Add the Twilio Node JS Helper NPM package + +The Hook uses the [Twilio Node.JS Helper Library](https://github.com/twilio/twilio-node), so you'll need to include this package in your Hook. + +1. Click the **Settings** icon again, and select **NPM Modules**. + +2. Search for `twilio-node` and add the module that appears. + +### Test your Hook implementation + +Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button. + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes via Twilio. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +### Test the MFA flow + +Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs). + +## Troubleshoot + +If you do not receive the SMS, please look at the logs for clues and make sure that: + +- The Hook is active and the SMS configuration is set to use 'Custom'. +- You have configured the Hook Secrets as per Step 2. +- The configured Hook Secrets are the same ones you created in the Twilio SMS Dashboard. +- Your are sending the messages from a phone number that is linked to your Twilio account. +- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164). + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/mfa/send-phone-message-hook-vonage.md b/fr-ca/articles/mfa/send-phone-message-hook-vonage.md new file mode 100644 index 0000000000..98a46e1a78 --- /dev/null +++ b/fr-ca/articles/mfa/send-phone-message-hook-vonage.md @@ -0,0 +1,172 @@ +--- +description: Configure a Custom SMS Provider for MFA using Vonage +topics: + - mfa + - sms + - custom-sms-provider +contentType: + - how-to +useCase: + - customize-mfa +--- +# Configure a Custom SMS Provider for MFA using Vonage + +This guide explains how to send Multi-factor Authentication (MFA) text messages using the Vonage (previously Nexmo) SMS API. + +<%= include('./_includes/_test-setup') %> + +## What is Vonage? + +Vonage provides an SMS API which can be used by Auth0 to deliver multi-factor verification via text messages. To learn more, see [Vonage's SMS API Overview](https://www.vonage.com/communications-apis/sms/). + +## Get Started with Vonage + +First, [sign up with Vonage](https://dashboard.nexmo.com/sign-up) and complete your profile and confirmation steps. Once done, you should be able to access the [SMS API screen of the Vonage dashboard](https://dashboard.nexmo.com/getting-started/sms). Here, you can try out the API with a test number. + +![Vonage Dashboard Test SMS API](/media/articles/mfa/01-guide-vonage-dashboard-sms-api-test.png) + +Once you've successfully tested the SMS API and can receive a text message, you're ready to integrate with Auth0. + +## Steps + +To configure a custom SMS provider for MFA using Vonage, you will: + +1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook) +2. [Configure Hook Secrets](#configure-hook-secrets) +3. [Include the nexmo module](#include-the-nexmo-module) +4. [Add the Vonage API Call](#add-the-vonage-api-call) +5. [Test your Hook implementation](#test-your-hook-implementation) +6. [Activate the custom SMS factor](#activate-the-custom-sms-factor) +7. [Test the MFA flow](#test-the-mfa-flow) + +Optional: [Troubleshoot](#troubleshoot) + +### Create a Send Phone Message Hook + +You're going to use a Hook in the Auth0 dashboard to send the text message when MFA is required. To do that, you need the API information for your Vonage account and a simple Node function to send the message. + +1. Navigate to the [Hooks screen](${manage_url}/#/hooks) in the Auth0 Dashboard, scroll down to **Send Phone Message**, and click **Create New Hook**. + +![Auth0 Dashboard: Add New Hook](/media/articles/mfa/02-guide-auth0-add-new-hook.png) + +2. Give the Hook a name, click **Create**, then click the **Edit Hook** button to configure secrets and add the Vonage API call. + +![Auth0 dashboard edit SMS hook](/media/articles/mfa/03-guide-auth0-edit-new-sms-hook.png) + +### Configure Hook Secrets + +You're going to store each of the values needed from the Vonage dashboard in a [Hook Secret](/hooks/secrets). This way, the values are secure and can be used easily in your function. + +Click the **Settings** icon (wrench) on the top left and select **Secrets**, then click **Add Secret**, and add the following secrets. You can find the values for all three of these secrets in the [Getting Started Guide](https://dashboard.nexmo.com/getting-started-guide) in the Vonage dashboard. + +* `VONAGE_API_KEY`: Vonage API key +* `VONAGE_API_SECRET`: Vonage API secret +* `VONAGE_FROM_NUMBER`: Vonage "from" sending number + +![Auth0 Dashboard: Add Hook Secret](/media/articles/mfa/04-guide-auth0-add-hook-secrets.png) + +### Include the nexmo module + +The Hook uses the [Nexmo Client Library for Node.js](https://aws.amazon.com/sdk-for-node-js/), so you'll need to include this package in your Hook. + +Next, you'll need to include the `nexmo` module in your hook. + +1. Click the **Settings** icon again, and select **NPM Modules**. + +2. Search for `nexmo` and add the module that appears. + +![Auth0 Dashboard: Add Hook Module](/media/articles/mfa/05-guide-auth0-add-nexmo-module.png) + +## Add the Vonage API call + +To make the call to the Vonage API, add the appropriate code to the Hook. + +Copy the code block below and paste it into the Hooks code editor. This function will run each time a user requires MFA, calling the Vonage API to send a verification code via SMS. + +```js +module.exports = function(toNumber, text, context, cb) { + const Nexmo = require('nexmo'); + const nexmo = new Nexmo({ + apiKey: context.webtask.secrets.VONAGE_API_KEY, + apiSecret: context.webtask.secrets.VONAGE_API_SECRET, + }); + + const fromNumber = context.webtask.secrets.VONAGE_FROM_NUMBER; + toNumber = toNumber.replace(/\D/g, ''); + + nexmo.message.sendSms(fromNumber, toNumber, text, (err, responseData) => { + if (err) { + return cb(err); + } + + const firstMsg = responseData.messages[0]; + if (firstMsg['status'] !== '0') { + return cb(new Error('Message failed: ' + firstMsg['error-text'])); + } + + return cb(null, {}); + }); +}; +``` + +### Test your Hook implementation + +Click the **Runner** button to try the completed Hook. Make sure to change the `recipient` value in the body to your test number from the Vonage API. + +You should receive a test text message, and the webtask should complete successfully. + +![Auth0 Dashboard: Run SMS Hook](/media/articles/mfa/06-guide-auth0-run-sms-hook.png) + +### Activate the custom SMS factor + +The Hook is now ready to send MFA codes via the Vonage SMS API. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow. + +1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box. + +2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal. + +3. Enable the SMS factor using the toggle switch. + +![Auth0 Dashboard: Activate SMS Factor](/media/articles/mfa/07-guide-auth0-activate-sms-factor.png) + +::: note +To use the SMS factor, your tenant needs to have MFA enabled globally or required for specific contexts using Rules. To learn how to enable the MFA feature itself, see the following docs: + +- [Enable Multi-Factor Authentication](/mfa/guides/enable-mfa) +- [Customize Multi-Factor Authentication](/mfa/guides/customize-mfa-universal-login) +::: + +### Test the MFA flow + +You can now test your authentication flow to see the Vonage API in action. + +![Test MFA SMS verification](/media/articles/mfa/08-guide-test-sms-verification.png) + +## Troubleshoot + +If something was misconfigured in Vonage, the Hook, or the SMS Factor, you may see an error message on the login form when trying this factor out for the first time. + +![Auth0 Universal Login MFA SMS Error](/media/articles/mfa/09-guide-login-sms-error-message.png) + +The best place to start debugging this issue is the [Logs screen](${manage_url}/#/logs) in the Auth0 dashboard. Look for a failed SMS log entry: + +![Auth0 Logs: Error Sending MFA SMS](/media/articles/mfa/10-guide-auth0-log-sms-error.png) + +To learn which event types to search, see our [Log Event Type Code list](/logs/references/log-event-type-codes). Otherwise, use the **Filter** control to find `MFA` errors. + +Once you find a log entry of interest, scroll down in the **Raw** tab to see an error message explaining what went wrong: + +![Auth0 Logs: Error Sending MFA SMS Details](/media/articles/mfa/11-guide-auth0-log-sms-error-details.png) + +If this does not solve your issue, the next step would be to check the [Vonage SMS API logs](https://dashboard.nexmo.com/sms) for a sent message and check its status. If there is no record of the message with Vonage, then the API call likely failed and the problem is in the Hook code. + +## Additional providers + +::: next-steps +* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns) +* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio) +* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip) +* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign) +* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex) +* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto) +::: diff --git a/fr-ca/articles/microsites/add-login/add-login-native-mobile-app.md b/fr-ca/articles/microsites/add-login/add-login-native-mobile-app.md new file mode 100644 index 0000000000..13eb995054 --- /dev/null +++ b/fr-ca/articles/microsites/add-login/add-login-native-mobile-app.md @@ -0,0 +1,83 @@ +--- +title: Add Login to Your Native/Mobile App +description: Everything you need to know to implement login for a native/mobile app +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/native +public: false +template: microsite +topics: + - authentication + - oauth2 + - mobile-apps + - desktop-apps + - native-apps +useCase: + - add-login +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application. + +## How it works + +In a native/mobile application, the default experience will open a SafariViewController in iOS or a Custom Chrome Tab in Android.  + +1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server. +2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests the user's ID Token. +4. Auth0 responds with the user's ID Token. + +For security in native/mobile devices, Auth0 uses the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). + +Flow Overview for Native/Mobile Apps + +## Implementation overview + +::: steps + 1.

Configure the sign-in methods

Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled. + + 2.

Customize the sign-in UI (optional)

The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

Default Login Screen for Native/Mobile Apps + + 3.

Use the Auth0 SDK to trigger the flow

The SDK will take care of the details of opening the SafariViewController or Chrome Custom Tab, parsing the response back from Auth0, and validating the ID Token.

Your app can store the Access Token and a Refresh Token used to renew the Access Token without asking the user to re-enter their credentials. Follow one of our Native/Mobile Quickstarts to get started with the integration. + +::: + +## Alternative: Use Embedded Login + +While we strongly recommend that you use our hosted universal login page, if you prefer to embed your own login pages within your native/mobile app, you can implement our login widget (Lock UI) directly into your app with our: + +* [iOS Lock UI Component library](/libraries/lock-ios/v2) +* [Android Lock UI Component library](/libraries/lock-android/v2) + +:::: further-reading + +::: guides + * [Auth0 Mobile/Native App Quickstarts](/quickstart/native) + * [Add login using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce) + * [Add Facebook Login to Native Apps](/connections/nativesocial/facebook) + * [Add Sign In with Apple to Native iOS Apps](/connections/nativesocial/apple) + * [Embedded Passwordless Login in Native Applications](/connections/passwordless/embedded-login-native) + * [Customize the universal login page](/universal-login) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Identity Providers supported by Auth0](/connections) +::: + +::: concepts + * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded) + * [ID Tokens](/tokens/concepts/id-tokens) + * [Access Tokens](/tokens/access-token) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * Most native/mobile apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Native/Mobile App](/microsites/call-api/call-api-native-mobile-app). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). +::: + diff --git a/fr-ca/articles/microsites/add-login/add-login-regular-web-app.md b/fr-ca/articles/microsites/add-login/add-login-regular-web-app.md new file mode 100644 index 0000000000..fcab4a04bb --- /dev/null +++ b/fr-ca/articles/microsites/add-login/add-login-regular-web-app.md @@ -0,0 +1,72 @@ +--- +title: Add Login to Your Regular Web App +description: Everything you need to know to implement login for a regular web app +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/webapp +public: false +template: microsite +topics: + - authentication + - oauth2 + - regular-web-apps + - server-side +useCase: + - add-login +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application. + +## How it works + +In a regular web application:  + +1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server. +3. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests the user's ID Token. +4. Auth0 responds with the user's ID Token. + +For security in server-side web apps, Auth0 uses the [Authorization Code Flow](/flows/concepts/auth-code). + +Flow Overview for Regular Web Apps + +## Implementation overview + +::: steps + 1.

Configure the sign-in methods

Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled. + + 2.

Customize the sign-in UI (optional)

The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

Default Login Screen for Native/Mobile Apps + + 3.

Use an SDK for your chosen platform to trigger the flow

An open-source OpenID Connect (OIDC) SDK for your chosen platform can redirect to the Auth0 Universal Login page and handle the response, validating the ID Token.

Your app can store the ID Token. Follow one of our Regular Web App Quickstarts to get started with the integration. +::: + +:::: further-reading + +::: guides + * [Auth0 Regular Web App Quickstarts](/quickstart/webapp) + * [Add login using the Authorization Code Flow](/flows/guides/auth-code/add-login-auth-code) + * [Customize the universal login page](/universal-login) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Identity Providers supported by Auth0](/connections) +::: + +::: concepts + * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded) + * [ID Tokens](/tokens/concepts/id-tokens) + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * Most regular web apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Regular Web App](/microsites/call-api/call-api-regular-web-app). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). +::: + + diff --git a/fr-ca/articles/microsites/add-login/add-login-single-page-app.md b/fr-ca/articles/microsites/add-login/add-login-single-page-app.md new file mode 100644 index 0000000000..7a63e2d626 --- /dev/null +++ b/fr-ca/articles/microsites/add-login/add-login-single-page-app.md @@ -0,0 +1,72 @@ +--- +title: Add Login to Your Single-Page App +description: Everything you need to know to implement login for a single-page app (SPA) +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/spa +public: false +template: microsite +topics: + - authentication + - oauth2 + - single-page-apps + - client-side +useCase: + - add-login +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application. + +## How it works + +In a single-page application (SPA):  + +1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server. +2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests the user's ID Token. +4. Auth0 responds with the user's ID Token. + +For security in SPAs, Auth0 uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). + +Flow Overview for Single-Page Apps with Auth Code Flow with PKCE + +## Implementation overview + +::: steps + 1.

Configure the sign-in methods

Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled. + + 2.

Customize the sign-in UI (optional)

The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

Default Login Screen for Native/Mobile Apps + + 3.

Use the Auth0 SDK to trigger the flow

The SDK will take care of the details of redirecting to Auth0, parsing the response back, and validating the ID Token.

Your app can keep the ID Token in memory.

The easiest way to implement the Authorization Code Flow with PKCE is to follow our Single-Page App Quickstarts. You can also use our Auth0 Single-Page App SDK. +::: + +:::: further-reading + +::: guides + * [Auth0 Single-Page App Quickstarts](/quickstart/spa) + * [Add login using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce) + * [Add login using the Implicit Flow](/flows/guides/implicit/add-login-implicit) + * [Customize the universal login page](/universal-login) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Identity Providers supported by Auth0](/connections) +::: + +::: concepts + * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded) + * [ID Tokens](/tokens/concepts/id-tokens) + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * Many single-page apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Single-Page App](/microsites/call-api/call-api-single-page-app). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). +::: + diff --git a/fr-ca/articles/microsites/call-api/call-api-device.md b/fr-ca/articles/microsites/call-api/call-api-device.md new file mode 100644 index 0000000000..c6e23b60fc --- /dev/null +++ b/fr-ca/articles/microsites/call-api/call-api-device.md @@ -0,0 +1,80 @@ +--- +title: Call Your API from an Input-Constrained Device +description: Everything you need to know to call your API from your input-constrained device. For use with native apps. +public: false +template: microsite +topics: + - authorization + - oauth2 + - device + - mobile-apps + - desktop-apps + - native-apps +useCase: + - call-api +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +With input-constrained devices, however, rather than immediately authenticating the user, the device asks the user to go to a link on their computer or smartphone to authenticate. This avoids a poor user experience for devices that do not have an easy way to enter text. If you’ve ever signed in to your Netflix account on a device like a Roku, you’ve already encountered this workflow. + +Your user will authenticate on their computer or smartphone, and Auth0 will generate an Access Token that will be passed back to your device application. The Access Token can then be used to call your API. + +This flow can be used with native applications only. + +## How it works + +When your app needs to fetch user data from your API: + +1. If the device is not already authorized, your device app calls your Auth0 Authorization Server to retrieve a device code. +2. Auth0 responds with a URL and user code that your device app can use when asking the user to visit a specific URL on their laptop or smartphone and provide an activation code. +3. Your device app begins to poll your Auth0 Authorization Server for an Access Token. +4. The user authenticates with Auth0 on its computer or smartphone using one of your configured login options (e.g., username/password, social identity provider, SAML). +5. Auth0 responds to your device app with an Access Token. +6. The Access Token can be used to call your API and retrieve requested data. + +For devices, Auth0 uses the [Device Authorization Flow](/flows/concepts/device-auth). + +Flow Overview for Device Apps + +## Implementation overview + +::: steps + 1.

Configure your API

Once you have created your API, you will need to authorize your device's application and configure any scopes that applications can request during authorization. + + 2.

Get an Access Token

Your device requests an Access Token from your Auth0 Authorization Server using the Device Authorization Flow. + + 3.

Call your API

When your device calls your API, it includes the retrieved Access Token in the HTTP Authorization header. +::: + + +To implement the Device Authorization Flow, you can follow our tutorial: [Call Your API Using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth). + +:::: further-reading + +::: guides + * [Auth0 Backend/API Quickstarts](/quickstart/backend) + * [Call Your API Using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth) + * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Auth0 Authentication API](/api/authentication) + * [OAuth 2.0](/protocols/oauth2) +::: + +::: concepts + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * The device authorization flow works for native apps. Learn how to [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app) + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).[;] + " + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + * Learn more about the ways Auth0 can help you [manage user profiles](/microsites/manage-users/manage-users-and-user-profiles) and [maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data). +::: diff --git a/fr-ca/articles/microsites/call-api/call-api-m2m-app.md b/fr-ca/articles/microsites/call-api/call-api-m2m-app.md new file mode 100644 index 0000000000..5f8d1154f5 --- /dev/null +++ b/fr-ca/articles/microsites/call-api/call-api-m2m-app.md @@ -0,0 +1,72 @@ +--- +title: Call Your API from a Machine-to-Machine App +description: Everything you need to know to call your API from your machine-to-machine (M2M) app +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/backend +public: false +template: microsite +topics: + - authentication + - oauth2 + - m2m +useCase: + - call-api +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +With machine-to-machine (M2M) apps, however, the system authenticates and authorizes the app rather than a user. + +## How it works + +When your app needs to fetch user data from your API: + +1. Your M2M application authenticates with your Auth0 Authorization Server. +2. Auth0 responds with an Access Token. +3. The Access Token can be used to call your API and retrieve requested data. + +For M2M applications, Auth0 uses the [Client Credentials Flow](/flows/concepts/client-credentials). + +Flow Overview for Machine-to-Machine Apps + +## Implementation overview + +::: steps + 1.

Configure your API

Once you have created your API, you will need to authorize your M2M application and configure any scopes that applications can request during authorization. + + 2.

Get an Access Token

Your app requests an Access Token from your Auth0 Authorization Server using the Client Credentials Flow. + + 3.

Call your API

When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header. +::: + + +To implement the Client Credentials Flow, [follow our Backend/API Quickstarts](/quickstart/backend). The "Calling your API" section shows the required steps. + +Or, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials). + +:::: further-reading + +::: guides + * [Auth0 Backend/API Quickstarts](/quickstart/backend) + * [Call Your API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials) + * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Auth0 Authentication API](/api/authentication) + * [OAuth 2.0](/protocols/oauth2) +::: + +::: concepts + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + * Learn more about the ways Auth0 can help you [manage user profiles](/microsites/manage-users/manage-users-and-user-profiles) and [maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data). +::: diff --git a/fr-ca/articles/microsites/call-api/call-api-native-mobile-app.md b/fr-ca/articles/microsites/call-api/call-api-native-mobile-app.md new file mode 100644 index 0000000000..d5442b350d --- /dev/null +++ b/fr-ca/articles/microsites/call-api/call-api-native-mobile-app.md @@ -0,0 +1,87 @@ +--- +title: Call Your API from Your Native/Mobile App +description: Everything you need to know to call your API from your native/mobile app +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/native +public: false +template: microsite +topics: + - authentication + - oauth2 + - mobile-apps + - desktop-apps + - native-apps +useCase: + - call-api +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API. + +## How it works + +In a native/mobile application, the default experience will open a SafariViewController in iOS or a Custom Chrome Tab in Android.  + +When your app needs to fetch user data from your API: + +1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server. +2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests an ID Token, Access Token, and Refresh Token. +4. Auth0 responds with the requested tokens. +5. The Access Token can be used to call your API and retrieve requested data. + +For security in native/mobile devices, Auth0 uses the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce). + +Flow Overview for Native/Mobile Apps + +## Implementation overview + +::: steps + 1.

Configure your API

Once you have created your API, you will need to configure any scopes that applications can request during authorization. + + 2.

Get an Access Token

Your app requests an Access Token (and optionally, a Refresh Token) from your Auth0 Authorization Server using the Authorization Code Flow with PKCE. + + 3.

Call your API

When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header. + + 4.

Refresh your Access Token

When the Access Token expires you can use the Refresh Token to get a new one from your Auth0 Authorization Server. + +::: + + +The easiest way to implement the Authorization Code Flow with PKCE is to [follow our Mobile/Native Quickstarts](/quickstart/native). + +You can also use our mobile SDKs: + +* [Auth0 Swift SDK](/libraries/auth0-swift) +* [Auth0 Android SDK](/libraries/auth0-android) + +Finally, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce). + +:::: further-reading + +::: guides + * [Auth0 Mobile/Native App Quickstarts](/quickstart/native) + * [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce) + * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Auth0 Authentication API](/api/authentication) + * [OAuth 2.0](/protocols/oauth2) +::: + +::: concepts + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + * If you would like to make your native/mobile app work with input-constrained devices, see [Call Your API from an Input-Constrained Device](/microsites/call-api/call-api-device). + * If you need to add login to your own native/mobile app, learn how at: [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app). +::: diff --git a/fr-ca/articles/microsites/call-api/call-api-regular-web-app.md b/fr-ca/articles/microsites/call-api/call-api-regular-web-app.md new file mode 100644 index 0000000000..a13e6cdd73 --- /dev/null +++ b/fr-ca/articles/microsites/call-api/call-api-regular-web-app.md @@ -0,0 +1,78 @@ +--- +title: Call Your API from Your Regular Web App +description: Everything you need to know to call your API from your regular web app +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/webapp +public: false +template: microsite +topics: + - authentication + - oauth2 + - regular-web-apps + - server-side-apps +useCase: + - call-api +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API and extract attributes for that user (such as name, email, role, or a custom attribute) + +## How it works + +When your app needs to fetch user data from your API: + +1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server. +2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests an ID Token, Access Token, and Refresh Token. +4. Auth0 responds with the requested tokens. +5. The Access Token can be used to call your API and retrieve requested data. + +For server-side web apps, Auth0 uses the [Authorization Code Flow](/flows/concepts/auth-code). + +Flow Overview for Regular Web Apps + +## Implementation overview + +::: steps + 1.

Configure your API

Once you have created your API, you will need to configure any scopes that applications can request during authorization. + + 2.

Get an Access Token

Your app requests an Access Token (and optionally, a Refresh Token) from your Auth0 Authorization Server using the Authorization Code Flow. + + 3.

Call your API

When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header. + + 4.

Refresh your Access Token

When the Access Token expires you can use the Refresh Token to get a new one from your Auth0 Authorization Server. + +::: + + +The easiest way to implement the Authorization Code Flow is to [follow our Regular Web App Quickstarts](/quickstart/webapp). + +Or, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow](/authorization/flows/call-your-api-using-the-authorization-code-flow). + +:::: further-reading + +::: guides + * [Auth0 Regular Web App Quickstarts](/quickstart/webapp) + * [Call Your API Using the Authorization Code Flow](/authorization/flows/call-your-api-using-the-authorization-code-flow) + * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Auth0 Authentication API](/api/authentication) + * [OAuth 2.0](/protocols/oauth2) +::: + +::: concepts + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + * If you need to add login to your own regular web app, learn how at: [Add Login to Your Regular Web App](/microsites/add-login/add-login-regular-web-app). +::: diff --git a/fr-ca/articles/microsites/call-api/call-api-single-page-app.md b/fr-ca/articles/microsites/call-api/call-api-single-page-app.md new file mode 100644 index 0000000000..edaf4ea6e8 --- /dev/null +++ b/fr-ca/articles/microsites/call-api/call-api-single-page-app.md @@ -0,0 +1,74 @@ +--- +title: Call Your API from Your Single-Page App +description: Everything you need to know to call your API from your single-page app (SPA) +ctaText: Go to Quickstart +ctaLink: /docs/quickstart/spa +public: false +template: microsite +topics: + - authentication + - oauth2 + - single-page-apps + - client-side-apps +useCase: + - call-api +--- + +Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in. + +Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API. + +## How it works + +When your app needs to fetch user data from your API: + +1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server. +2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML). +3. Your app requests an ID Token and Access Token. +4. Auth0 responds with the requested tokens. +5. The Access Token can be used to call your API and retrieve requested data. + +For single-page apps, Auth0 uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce). + +Flow Overview for Single-Page Apps with Auth Code Flow with PKCE + +## Implementation overview + +::: steps + 1.

Configure your API

Once you have created your API, you will need to configure any scopes that applications can request during authorization. + + 2.

Get an Access Token

Your app requests an Access Token from your Auth0 Authorization Server using the Authorization Code Flow with PKCE. + + 3.

Call your API

When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header. +::: + +The easiest way to implement the Authorization Code Flow with PKCE is to [follow our Single-Page App Quickstarts](/quickstart/spa). You can also use our [Auth0 Single-Page App SDK](/libraries/auth0-spa-js). + +Finally, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce). + +:::: further-reading + +::: guides + * [Auth0 Single-Page App Quickstarts](/quickstart/spa) + * [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce) + * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks) + * [Token Storage](/tokens/concepts/token-storage) +::: + +::: references + * [SDKs](/libraries) + * [Auth0 Authentication API](/api/authentication) + * [OAuth 2.0](/protocols/oauth2) +::: + +::: concepts + * [Access Tokens](/tokens/concepts/access-tokens) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + * If you need to add login to your own single-page app, learn how at: [Add Login to Your Single-Page App](/microsites/add-login/add-login-single-page-app). +::: diff --git a/fr-ca/articles/microsites/manage-users/define-maintain-custom-user-data.md b/fr-ca/articles/microsites/manage-users/define-maintain-custom-user-data.md new file mode 100644 index 0000000000..64c9a50e4c --- /dev/null +++ b/fr-ca/articles/microsites/manage-users/define-maintain-custom-user-data.md @@ -0,0 +1,81 @@ +--- +title: Define and Maintain Custom User Data +description: An introduction to how Auth0 helps you manage user metadata and custom profile information +contentType: microsite +topics: + - users + - user-management + - define-user-data +useCase: manage-users +template: microsite +v2: True +--- + +After you have set up your [user profiles](/microsites/manage-users/manage-users-and-user-profiles), Auth0 can help you define custom user data using the [metadata](/users/concepts/overview-user-metadata) within the user profiles. + +## How it works + +There are two kinds of metadata in Auth0: + +* **`user_metadata`** stores user attributes (such as preferences) that do not impact users' core functionality. An authenticated user can modify this type of data. +* **`app_metadata`** stores information (such as users' support plans, security roles, and access control groups) that can impact users' core functionality. For example, how an application functions or what the user can access. A user cannot modify this type of data. + +For example, suppose the following metadata is stored for a use with the email address `jane.doe@example.com`: + +```json +{ + "emails": "jane.doe@example.com", + "user_metadata": { + "hobby": "surfing" + }, + "app_metadata": { + "plan": "full" + } +} +``` +To read metadata, simply access the correct property as you would from any JSON object. For example, if you were working with the above example metadata within a Rule or via a call to the Management API, you could reference specific items from the data set as follows: + +```js +console.log(user.email); // "jane.doe@example.com" +console.log(user.user_metadata.hobby); // "surfing" +console.log(user.app_metadata.plan); // "full" +``` + +## Customize and maintain user data + +There are a few different ways you can customize the user metadata: + +* Use [Rules](/rules), which execute after a user has been authenticated, to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. + +* Use the `GET/userinfo` endpoint to get a user's `user-metadata`, however you must first write a Rule to [copy metadata properties to the ID Token](/rules/current#copy-user-metadata-to-id-token). + +* If you have a database connection, use the [Authentication API](/api/authentication) with the [Signup](/api/authentication?shell#signup) endpoint to set the `user-metadata` for a user. For an example, refer to [Custom Signup > Using the API](/libraries/custom-signup#using-the-api). + +* You can use the [Management API](/api/management/v2) to create, retrieve, or update both the `user-metadata` and `app-metadata` fields. + +After you have customized the user metadata, you can manage and store data related to each of your users that doesn't originate from identity providers in the Auth0 data store or your own custom database. + +:::: further-reading +::: concepts + * [User Management](/users) + * [User Profiles](/users/concepts/overview-user-profile) + * [Metadata](/users/concepts/overview-user-metadata) + * [Normalized User Profiles](/users/normalized/auth0) +::: + +::: guides + * [Manage User Metadata](/users/guides/manage-user-metadata) + * [User Metadata in Rules](/rules/current/metadata-in-rules) + ::: + +::: references + * [User Data Storage Best Practices](/users/references/user-data-storage-best-practices) + * [User Data Storage Scenario](/users/references/user-data-storage-scenario) + * [Authorization Extension](/extensions/authorization-extension/v2) +::: +:::: + +::: whats-next +* Learn more about the tools available to [manage users and user profiles](/microsites/manage-users/manage-users-and-user-profiles). +* If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + ::: diff --git a/fr-ca/articles/microsites/manage-users/manage-users-and-user-profiles.md b/fr-ca/articles/microsites/manage-users/manage-users-and-user-profiles.md new file mode 100644 index 0000000000..5e564f2bc4 --- /dev/null +++ b/fr-ca/articles/microsites/manage-users/manage-users-and-user-profiles.md @@ -0,0 +1,71 @@ +--- +title: Manage Users and User Profiles +description: An introduction to how Auth0 helps you manage users and their profile information +contentType: microsite +public: false +topics: + - users + - user-management +useCase: manage-users +template: microsite +v2: true +--- + +Auth0 stores user profiles for your application in a hosted cloud database. User profile information can come from your users directly or from any number of other external sources including Social Identity Providers, Enterprise connections like SAML, or custom sources like Active Directory. Auth0 refers to all user profile attribute sources as connections because Auth0 *connects* to them to authenticate the user. + +You can manage and store custom user attributes such as favorite color or phone number along with the standard profile information. Using our Rules engine you can modify or enhance the user profiles. + +## How it works + +Within the Auth0 database: + +1. Auth0 creates a user profile for each unique user of your applications. +2. Auth0 fills that profile with information provided by the user directly or from their chosen connection. +3. If the information is sourced from a connection, Auth0 refreshes that data each time the user authenticates. +4. Each connection may return a set of attributes about the user, and each provider may use different names for the same attribute, such as surname, last name, and family name. To handle such differences, Auth0 applies a Normalized User Profile, which returns a basic set of information using specific attribute names. + +Manage Users and User Profiles + +## Manage user identities and profile information + +There are several ways you can modify information in a user profile or an ID Token. + +* **Scopes**: The authentication flows supported by Auth0 include an optional parameter that allows you to specify a scope. This controls the user profile information (claims) included in the ID Token (JWT). + +* **Management Dashboard**: On the dashboard administrators can manually edit portions of the user profile for a particular user. This mechanism can be used to alter the user_metadata and app_metadata portions of the user profile. + +* **Management API**: Provides access to read, update, and delete user profiles stored in the Auth0 database. + +* **Custom database scripts**: If a custom database is used as the connection, you can write scripts to implement lifecycle events such as create, login, verify, delete and change password. Auth0 provides templates for these scripts that you can modify for the particular database and schema. + +* **Rules**: Rules execute after a user has been authenticated. Use Rules to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. + +:::: further-reading +::: concepts + * [User Management](/users) + * [User Profiles](/users/concepts/overview-user-profile) + * [Metadata](/users/concepts/overview-user-metadata) + * [Normalized User Profiles](/users/normalized) + ::: + +::: guides + * [Scopes](/scopes) + * [Manage Users Using the Dashboard](/users/guides/manage-users-using-the-dashboard) + * [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api) + * [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database) + * [Custom Database Script Templates](/connections/database/custom-db/templates) + * [User Metadata in Rules](/rules/current/metadata-in-rules) +::: + +::: references + * [User Profile Structure](/users/references/user-profile-structure) + * [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices) + * [User Data Storage Scenario](/users/references/user-data-storage-scenario) + * [Identity Providers Supported](/identityproviders) + ::: +:::: + +::: whats-next +* Learn about the tools available to [define and maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data). +* If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api). + ::: diff --git a/fr-ca/articles/microsites/protect-api/protect-api.md b/fr-ca/articles/microsites/protect-api/protect-api.md new file mode 100644 index 0000000000..647d41f77d --- /dev/null +++ b/fr-ca/articles/microsites/protect-api/protect-api.md @@ -0,0 +1,68 @@ +--- +title: Protect Your API +description: Everything you need to know to protect your API +template: microsite +topics: + - authentication + - oauth2 + - apis +useCase: + - secure-api +public: false +--- + +Using Auth0 to protect your API means that you will be "outsourcing" the authentication process to a centralized service that will help you ensure only approved applications can access your data. The calling application will authenticate the user, and Auth0 will generate tokens that can be passed to your API. Auth0 can also help you verify the tokens you receive from the applications that call your API. + +## How it works + +Your API will receive a request including an Access Token:  + +1. An app authenticates a user with Auth0. +2. Auth0 responds with the user's ID Token and Access Token. +3. The app calls your API, passing along the Access Token. +4. Your API validates the Access Token. +5. Your API responds with the requested information. + +Flow Overview for Protect API + +## Implementation overview + +::: steps + 1.

Configure your API

Auth0 supports access from various application types. If you expect a machine-to-machine (M2M) app to call your API, go to the dashboard and authorize them to request Access Tokens.
You can also allow your API to skip user consent for your own apps and identify your API's scopes. If you're building a public-facing API, you'll need to let external callers know which of these scopes are available to them and provide guidance on how they can call your API. + + 2.

Use a JWT validation library to validate tokens

The library will take care of the details of parsing and validating the received tokens. This consists of a series of steps, and if any of these fails, then you must reject the application's request. Follow one of our Backend/API Quickstarts to get started. + + 3.

Respond to the request

Once your token has been successfully validated, respond to the calling application with their requested data. + +::: + + +:::: further-reading + +::: guides + * [Configure an API](/apis#how-to-configure-an-api-in-auth0) + * [Auth0 Backend/API Quickstarts](/quickstart/backend) + * [Validate an Access Token for custom APIs](/tokens/guides/validate-access-tokens) +::: + +::: references + * [OAuth 2.0](/protocols/oauth2) + * [Auth0 Authentication API](/api/authentication) +::: + +::: concepts + * [Tokens](/tokens) + * [Access Tokens](/tokens/concepts/access-tokens) + * [Scopes](/scopes) + * [Dynamic client registration](/api-auth/dynamic-client-registration) +::: + +:::: + +::: whats-next + * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks). + * Learn how to call your API from your app: [Call Your API from My Native/Mobile App](/microsites/call-api/call-api-native-mobile-app), [Call Your API from My Regular Web App](/microsites/call-api/call-api-regular-web-app), [Call Your API from Your Single-Page App](/microsites/call-api/call-api-single-page-app), or [Call Your API from a M2M App](/microsites/call-api/call-api-m2m-app). + * If you are building your own application and you want to log users in using Auth0, learn to add login to your app: [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app), [Add Login to Your Regular Web App](/microsites/add-login/add-login-regular-web-app), or [Add Login to Your Single-Page App](/microsites/add-login/add-login-single-page-app). +::: + + diff --git a/fr-ca/articles/migrations/guides/_forced-logouts.md b/fr-ca/articles/migrations/guides/_forced-logouts.md new file mode 100644 index 0000000000..91bbc59482 --- /dev/null +++ b/fr-ca/articles/migrations/guides/_forced-logouts.md @@ -0,0 +1,3 @@ +::: warning +When a user's `/oauth/ro` based access token has expired, Auth0 **forces them to reauthenticate** (forced logout required) because the `/oauth/ro` refresh token cannot be used to call `/oauth/token` for a new Access Token. All currently logged in user's must log in again during an `/oauth/ro` to `/oauth/token` migration. +::: diff --git a/fr-ca/articles/migrations/guides/_get-token-auth0js.md b/fr-ca/articles/migrations/guides/_get-token-auth0js.md new file mode 100644 index 0000000000..52d002f06e --- /dev/null +++ b/fr-ca/articles/migrations/guides/_get-token-auth0js.md @@ -0,0 +1,63 @@ +
+
+ +
+
+
+ 
+        
+// get an ID Token
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: '${account.callback}',
+  scope: 'openid',
+  responseType: 'id_token'
+});
+// create a new instance
+var auth0Manage = new auth0.Management({
+  domain: '${account.namespace}',
+  token: 'ID_TOKEN'
+});
+        
+
+
+
    +
  • Asks for an ID Token in the response (responseType: 'id_token')
    • +
  • Authenticates with the Management API using the ID Token
    • +
+
+
+
+ 
+        
+// get an Access Token
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: '${account.callback}',
+  audience: 'https://${account.namespace}/api/v2/',
+  scope: '${scope}',
+  responseType: 'token id_token'
+});
+// create a new instance
+var auth0Manage = new auth0.Management({
+  domain: '${account.namespace}',
+  token: 'ACCESS_TOKEN'
+});
+        
+
+
+
    +
  • Asks for both an ID Token and an Access Token in the response (responseType: 'token id_token')
    • +
  • Sets the Management API as the intended audience of the token (audience: 'https://${account.namespace}/api/v2/')
    • +
  • Asks for the required permission (scope: '${scope}')
    • +
  • Authenticates with the Management API using the Access Token
    • +
+
+
+
+
diff --git a/fr-ca/articles/migrations/guides/_get-token-authorize.md b/fr-ca/articles/migrations/guides/_get-token-authorize.md new file mode 100644 index 0000000000..304e3c93b9 --- /dev/null +++ b/fr-ca/articles/migrations/guides/_get-token-authorize.md @@ -0,0 +1,58 @@ +
+
+ +
+
+
+ 
+        
+https://${account.namespace}/authorize?
+  scope=openid
+  &response_type=id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &nonce=NONCE
+  &state=OPAQUE_VALUE
+        
+
+
+
+ 
+        
+https://${account.namespace}/authorize?
+  audience=https://${account.namespace}/api/v2/
+  &scope=${scope}
+  &response_type=token%20id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &nonce=NONCE
+  &state=OPAQUE_VALUE
+        
+
+
+
+
+ +To get an Access Token that can access the Management API: +- We set the `audience` to `https://${account.namespace}/api/v2/` +- We asked for the scope `${scope}` +- We set the `response_type` to `id_token token` so Auth0 will sent us both an ID Token and an Access Token + +If we decode the Access Token and review its contents we can see the following: + +```text +{ + "iss": "https://${account.namespace}/", + "sub": "auth0|5a620d29a840170a9ef43672", + "aud": "https://${account.namespace}/api/v2/", + "iat": 1521031317, + "exp": 1521038517, + "azp": "${account.clientId}", + "scope": "${scope}" +} +``` + +Notice that the `aud` is set to your tenant's API URI, the `scope` to `${scope}`, and the `sub` to the user ID of the logged in user. \ No newline at end of file diff --git a/fr-ca/articles/migrations/guides/account-linking.md b/fr-ca/articles/migrations/guides/account-linking.md new file mode 100644 index 0000000000..c56e1766b1 --- /dev/null +++ b/fr-ca/articles/migrations/guides/account-linking.md @@ -0,0 +1,246 @@ +--- +description: Auth0 is deprecating the usage of ID Tokens in the Account Linking process. This article will help you migrate your solution from the old implementation to the new one. +toc: true +topics: + - account-linking + - migrations +contentType: + - concept + - how-to +useCase: + - manage-accounts +--- + +# Migration Guide: Account Linking with Access Tokens vs. ID Tokens + +This guide is part of the [Deprecating the usage of ID Tokens on the Auth0 Management API](/migrations#deprecating-the-usage-of-id-tokens-on-the-auth0-management-api) migration, and focuses on the [account linking process](/users/concepts/overview-user-account-linking). + +For some use cases you could use [ID Tokens](/tokens/concepts/id-tokens) to link and unlink user accounts. This functionality is being deprecated. You will have to use Access Tokens in all cases. + +The changes in account linking are: + +- You can no longer use an ID Token at the `Authorization` header, an Access Token must be used instead +- If you use an Access Token at the `Authorization` header, with `update:users` as the granted permission, then you can send at the request's body either the `user_id` or the ID Token of the secondary account. +- If you use an Access Token at the `Authorization` header, with `update:current_user_metadata` as the granted permission, then you can only send the ID Token of the secondary account in the request's body. +- If you send the ID Token of the secondary account in the request's body (that is, the use cases described in the previous two bullets), then the following must apply: + - The ID Token must be signed using `RS256` (you can set this value at *Dashboard > Clients > Client Settings > Advanced Settings > OAuth*) + - The claim `aud` of the ID Token, must identify the client, and be the same value with the `azp` claim of the Access Token + +The change in the unlinking of accounts is that you can no longer use an ID Token at the `Authorization` header. An Access Token must be used instead. See [#security-considerations] below for details. + +::: warning +This migration is specifically targeted to mitigate a possible security vulnerability. Auth0 strongly recommendeds that you update your code as soon as possible. +::: + +## Are you affected? + +There are several ways you can link and unlink accounts. Some change, some remain the same, and a new variation is introduced. In the following matrix you can see a list of the use cases and their status based on this migration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Use caseStatusMore info
You link user accounts with the Link a user account endpoint of the Management API, and you send the primary account's ID Token in the Authorization header.
Affected
Link current user accounts with the API
You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token (with scope update:users) in the Authorization header, and the secondary account's user_id in the payload
No change
N/A
You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token (with scope update:current_user_identities) in the Authorization header, and the secondary account's user_id in the payload
Affected
Link current user accounts with the API
You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token in the Authorization header, and the secondary account's ID Token in the payload
New use case
Link any user account with the API
You link user accounts with the Auth0.js library, and you use the primary account's ID Token to instantiate auth0.Management
Affected
Link current user accounts with Auth0.js
You link user accounts with the Auth0.js library, and you use an Access Token (with scope update:users) to instantiate auth0.Management
No change
N/A
You link user accounts with the Auth0.js library, and you use an Access Token (with scope update:current_user_identities) to instantiate auth0.Management
Affected
Link current user accounts with Auth0.js
You unlink user accounts with the Unlink a user identity endpoint of the Management API, and you send the primary account's ID Token in the Authorization header
Affected
How to unlink accounts
You unlink user accounts with the Unlink a user identity endpoint of the Management API, and you send an Access Token in the Authorization header
No change
N/A
+ +## Link user accounts + +In order to link accounts you can either call directly the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint of the Management API, or use the [Auth0.js library](/auth0js#user-management). + +### Link current user accounts with the Management API + +A common use case is to allow the logged-in user to link their various accounts using your app. + +Until now you could use the primary user's ID Token or Access Token (which contained the `update:current_user_identities` scope) in order to authenticate with the Management API and use the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint. + +With this migration, you must get an Access Token (which must contain the `update:current_user_identities` scope) and use that to authenticate with the API and use the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint. The payload must be the ID Token of the secondary user. + +First, you must get an Access Token with the `update:current_user_identities` scope. + +::: note +In the example that follows, we use the [Implicit Flow](/flows/guides/implicit/call-api-implicit), the recommended OAuth 2.0 flow for client-side apps). You can get Access Tokens though for any application type (see [Get Access Tokens](/tokens/get-access-tokens). +::: + +<%= include('./_get-token-authorize.md', { scope: 'update:current_user_identities', idPrevious: 'authZ-id-token', idCurrent: 'authZ-access-token' }) %> + +**The following must apply:** +- The secondary account's ID Token must be signed with `RS256` +- The `aud` claim in the secondary account's ID Token must identify the client, and hold the same value with the `azp` claim of the Access Token used to make the request. + +Once you have the Access Token you can use it to link user accounts. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer ACCESS_TOKEN" + }, + { + "name": "content-type", + "value": "application/json" + }], + "postData" : { + "mimeType": "application/json", + "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}" + } +} +``` + +### Link current user accounts with Auth0.js + +If you use [Auth0.js library](/libraries/auth0js#user-management) to access the Management API and link accounts, then you probably use the ID Token of the user's primary identity to instantiate `auth0.Management` and use it to link accounts. + +With this migration, you must get an Access Token (with the `update:current_user_identities` scope) and use that to instantiate the object. + +First, you must get an Access Token with the `update:current_user_identities` scope. Then use this token to instantiate `auth0.Management`. The final call to `linkUser` remain the same. + +<%= include('./_get-token-auth0js.md', { scope: 'update:current_user_identities' }) %> + +### Link any user account with the Management API + +If you get an Access Token for account linking, that contains the `update:users` scope, and send the secondary account's `user_id` and `provider` in the request, then you don't have to make any changes. + +However, this migration does introduce an alternative to this. You still use an Access Token that contains the `update:users` scope to authenticate with the API, but in the request's payload you can send the secondary's account ID Token (instead of `user_id` and `provider`). + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer ACCESS_TOKEN" + }, + { + "name": "content-type", + "value": "application/json" + }], + "postData" : { + "mimeType": "application/json", + "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}" + } +} +``` + +**The following must apply:** +- The secondary account's ID Token must be signed with `RS256` +- The `aud` claim in the secondary account's ID Token must identify the client, and hold the same value with the `azp` claim of the Access Token used to make the request. + +## Unlink user accounts + +If you use ID Tokens in order to unlink accounts, then you must update your implementation to use Access Tokens. + +First, you must get an Access Token with the `update:current_user_identities` scope. + +Use the sample script that follows as a guide. On the **Legacy (ID Token)** panel you can see an implementation of the old approach that gets an ID Token. On the **Current (Access Token)** panel you can see the new approach that gets an Access Token as well. + +<%= include('./_get-token-authorize.md', { scope: 'update:current_user_identities', idPrevious: 'unlink-id-token', idCurrent: 'unlink-access-token' }) %> + +Once you have the Access Token, you can call the [Unlink a user identity](/api/management/v2#!/Users/delete_user_identity_by_user_id) endpoint of the Management API, using it in the `Authorization` header. + +
+
+ +
+
+
+ 
+        
+DELETE https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID
+Authorization: 'Bearer ID_TOKEN-OR-ACCESS_TOKEN'
+        
+
+
+
+ 
+        
+DELETE https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID
+Authorization: 'Bearer ACCESS_TOKEN'
+        
+
+
+
+
+ +## Security considerations + +We have identified a weakness in a particular account linking flow that could allow it to be misused in specific circumstances. We have found no evidence that this has been used maliciously but have decided to deprecate the flow to prevent that ever happening. + +Therefore, Auth0 requires customers using the affected account linking flow to migrate to a more secure implementation before October 19th, 2018. Migration paths are provided in this guide, which should not result in any lost functionality. + +On October 19th, 2018 or anytime after, the affected account linking flow will be disabled and customers using it will experience run-time errors. + +### What's the impact + +You are impacted if you call the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) endpoint using a token (ID or Access Token) with the scope `update:current_user_identities` in the Authorization header and include the secondary account's `user_id` in the payload. + +No other use cases are impacted. + +## Next steps + +You should review all your calls to the account linking endpoint ([/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities)) and update those that make use of the vulnerable flow described above. You can update your calls to either of the following: + +1. **Client-side / user-initiated linking scenarios** -- For client-side linking scenarios, make the call to the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) using an Access Token with the `update:current_user_identities` scope, and provide the ID Token of the secondary account in the payload (`link_with`). This ID Token must be obtained through an OAuth/OIDC-conformant flow. See [Link User Accounts Initiated by Users Scenario](/users/references/link-accounts-user-initiated-scenario) for more details. +2. **Server-side linking scenarios** -- For server-side linking scenarios, make the call to the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) endpoint using an Access Token with the `update:users` scope and provide the `user_id` of the secondary account in the payload. See [Link User Accounts Server-Side Scenario](/users/references/link-accounts-server-side-scenario) for details. + +## Keep reading + +- [Link User Accounts](/users/guides/link-user-accounts) +* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario) +* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario) diff --git a/fr-ca/articles/migrations/guides/calling-api-with-idtokens.md b/fr-ca/articles/migrations/guides/calling-api-with-idtokens.md new file mode 100644 index 0000000000..471a05cdc5 --- /dev/null +++ b/fr-ca/articles/migrations/guides/calling-api-with-idtokens.md @@ -0,0 +1,197 @@ +--- +title: "Migration Guide: Management API and ID Tokens" +description: Auth0 is deprecating the usage of ID Tokens as credentials for the Management API. This article will help you migrate your solution from the old implementation to the new one. +toc: true +topics: + - migrations + - management-api + - id-tokens + - tokens +contentType: + - concept + - how-to + - reference +useCase: + - manage-accounts +--- + +# Migration Guide: Management API and ID Tokens + +For some use cases you could use [ID Tokens](/tokens/concepts/id-tokens) in order to call some of the [Users](/api/management/v2#!/Users/get_users_by_id) and [Device Credentials](/api/management/v2#!/Device_Credentials/get_device_credentials) endpoints of the Management API. + +This functionality is being deprecated. You will have to use proper [Access Tokens](/tokens/access-token) in order to access any of the endpoints of the [Management API](/api/management/v2). Make sure the `Allow ID Tokens for Management API v2 Authentication` toggle is turned off after completing the migration to Access Tokens. + +The grace period for this migration started on **March 31, 2018** and at the moment is open-ended. This means that you will still be able to use ID Tokens to access these endpoints. When a mandatory opt-in date is set for this migration customers will be notified beforehand. + +Customers are encouraged to migrate to Access Tokens. This guide will help you with that. + +First, we will see which use cases are affected. We will continue with reviewing how you can use [scopes](/scopes) to get tokens with different access rights, and then see all the ways you can use to get an Access Token. Finally, we will review the changes introduced in the [User Account Linking](/users/concepts/overview-user-account-linking) process. + +## Does this affect me? + +If you use ID Tokens to call any of the following endpoints, then you are affected by this migration: + +| **Endpoint** | **Use Case** | +|-|-| +| [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id) | Retrieve a user's information | +| [GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) | Retrieve all [Guardian](/mfa/concepts/guardian) MFA enrollments for a user | +| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | Update a user's information | +| [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) | Delete the MFA provider settings for a user | +| [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) | Create a public key for a device | +| [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | Delete a device credential | +| [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) | [Link user accounts](/users/guides/link-user-accounts) from various identity providers | +| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) | [Unlink user accounts](/users/guides/unlink-user-accounts) | + +These endpoints can now accept regular [Access Tokens](/tokens/concepts/access-tokens). + +Note that the last two endpoints are used for Account Linking. To review these changes, see [Changes in Account Linking](#changes-in-account-linking). + +**Nothing else changes in how the endpoints work**. You should expect the same request and response schemas and only need update the token that you use for authorization. + +## Changes in scopes + +The actions you can perform with the Management API depend on the [scopes](/scopes/current/api-scopes) that your Access Token contains. With this migration you can either get a "limited" Access Token that can update only the logged-in user's data, or an Access Token that can update the data of any user. In the following matrix you can see the scopes that your token needs to have per case and per endpoint. + +| **Endpoint** | **Scope for current user** | **Scope for any user** | +|-|-|-| +| [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id) | `read:current_user` | `read:users` | +| [GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) | `read:current_user` | `read:users` | +| [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) | `update:current_user_identities` | `update:users` | +| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) | `update:current_user_identities` | `update:users` | +| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | `update:current_user_metadata` | `update:users` | +| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | `create:current_user_metadata` | `update:users` | +| [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) | `delete:current_user_metadata` | `update:users` | +| [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) | `create:current_user_device_credentials` | `create:device_credentials` | +| [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | `delete:current_user_device_credentials` | `delete:device_credentials` | + +For example, if I get an Access Token that contains the scope `read:users` I can retrieve the data of **any user** using the [GET /api/v2/users/{id} endpoint](/api/management/v2#!/Users/get_users_by_id). But if my token contains the scope `read:current_user` I can only retrieve the information of the **currently logged-in user** (the one that the token was issued for). + +## Restrictions + +The Access Tokens used to access the Management API **must hold only one value at the `aud` claim**. If your token contains more than one value, then your request to the Management API will error out. + +## How to get an Access Token + +In this section we will see the changes that are introduced in how you get a token for the aforementioned endpoints. We will see sample scripts side-by-side so you can identify the changes. + +There are several variations on how you authenticate a user and get tokens, depending on the technology and the [OAuth 2.0 flow you use to authenticate](/api-auth/which-oauth-flow-to-use): +- Using the [Authorization endpoint](/api/authentication#authorize-application). This is where you redirect your users to login or sign up. You get your tokens from this endpoint if you authenticate users from a [single-page app](/api/authentication#implicit-grant) (running on the browser). +- Using the [Token endpoint](/api/authentication#get-token). You get your tokens from this endpoint if you authenticate users from a [web app](/api/authentication#authorization-code) (running on a server), a [mobile app](/api/authentication#authorization-code-pkce-), a [server process](/api/authentication#client-credentials), or a [highly trusted app](/api/authentication#resource-owner-password). +- Using [Lock](/libraries/lock/v11#cross-origin-authentication) or [auth0.js](/libraries/auth0js/v9#configure-your-auth0-application-for-embedded-login) embedded in your application. In this case you are using [cross-origin authentication](/cross-origin-authentication) (used to authenticate users when the requests come from different domains). + +### The Authorization endpoint + +In this section we will use an example to showcase the differences in how you get a token with the [Authorization endpoint](/api/authentication#authorize-application). Keep in mind though that no matter which endpoint you want to migrate, the changes are the same, the only thing that differs is the [scopes](#changes-in-scopes) you will specify in the request. + +In the example below, we want to use the [GET User by ID endpoint](/api/management/v2#!/Users/get_users_by_id) to retrieve the full profile information of the logged-in user. To do so, first we will authenticate our user (using the [Implicit grant](/api/authentication?http#implicit-grant)) and retrieve the token(s). + +On the `Legacy (ID Token)` panel you can see an implementation of the old approach that gets an ID Token (and then uses it to call the endpoint). On the `Current (Access Token)` panel you can see the new approach that gets an Access Token as well. + +<%= include('./_get-token-authorize.md', { scope: 'read:current_user', idPrevious: 'authZ-id-token', idCurrent: 'authZ-access-token' }) %> + +Once you have the Access Token you can use it to call the endpoint. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }] +} +``` + +### The Token endpoint + +In this section we will use an example to showcase the differences in how you get a token with the [Token endpoint](/api/authentication#get-token). Keep in mind though that no matter which endpoint you want to migrate, the changes are the same, the only thing that differs is the [scopes](#changes-in-scopes) you will specify in the request. + +In the example below, we want to use the [GET User by ID endpoint](/api/management/v2#!/Users/get_users_by_id) to retrieve the full profile information of the logged-in user. To do so, first we will authenticate our user (using the [Password Exchange grant](/api/authentication?http#resource-owner-password)) and retrieve the token(s). + +On the `Legacy (ID Token)` script you can see an implementation of the old approach that gets an ID Token (and then uses it to call the endpoint). On the `Current (Access Token)` script you can see the new approach that gets an Access Token as well. + +
+
+ +
+
+
+ 
+        
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+{
+  "grant_type": "password",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "scope": "openid",
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+}
+        
+
+
+
+ 
+        
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+{
+  "grant_type": "password",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "audience": "https://${account.namespace}/api/v2/",
+  "scope": "read:current_user",
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+}
+        
+
+
+
+
+ +In order to get an Access Token that can access the Management API: +- We set the `audience` to `https://${account.namespace}/api/v2/` +- We asked for the scope `read:current_user` + +Once you have the Access Token you can use it to call the endpoint. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }] +} +``` + +### Lock or auth0.js (embedded) + +If you embed either [Lock v11](/libraries/lock/v11) or [auth0.js v9](/libraries/auth0js/v9) in your application, then you are using [cross-origin authentication](/cross-origin-authentication). This is used to authenticate users when the requests come from different domains. + +If you use auth0.js to access the Management API and manage your users, then your script will have to be updated. + +<%= include('./_get-token-auth0js.md', { scope: 'read:current_user' }) %> + +## Changes in Account Linking + +The changes in this functionality are the following: + +- You can no longer use an ID Token at the `Authorization` header +- If you use an Access Token at the `Authorization` header, with `update:users` as the granted permission, then you can send at the request's body either the `user_id` or the ID Token of the secondary account +- If you use an Access Token at the `Authorization` header, with `update:current_user_metadata` as the granted permission, then you can only send the ID Token of the secondary account in the request's body. The following must apply: + - The ID Token must be signed using `RS256` (you can set this value at *Dashboard > Applications > Application Settings > Advanced Settings > OAuth*) + - The claim `aud` of the ID Token, must identify the application, and be the same value with the `azp` claim of the Access Token + +For a detailed overview of these changes and migration steps per use case, see [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking). + +## Keep reading + +- [Get Access Tokens](/tokens/guides/get-access-tokens) +- [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking) diff --git a/fr-ca/articles/migrations/guides/clickjacking-protection.md b/fr-ca/articles/migrations/guides/clickjacking-protection.md new file mode 100644 index 0000000000..877e705f0c --- /dev/null +++ b/fr-ca/articles/migrations/guides/clickjacking-protection.md @@ -0,0 +1,27 @@ +--- +title: Migration Guide: Enabling Clickjacking Protection for Universal Login +description: Auth0 is adding a way to prevent the Universal Login pages to be embedded in an iframe. +toc: true +topics: + - universal-login + - migrations +contentType: + - concept + - how-to +--- +# Migration Guide: Enabling Clickjacking Protection + +Clickjacking is an attack that tricks a user into clicking a web page element which is invisible or disguised as another element. This is done by loading content in an iframe and rendering elements on top of it. In the context of the Universal Login pages, an attacker could trick the user into clicking a 'Login', or 'Reset Password' button. + +This can be prevented by setting the following HTTP headers: + +``` +X-Frame-Options: deny +Content-Security-Policy: frame-ancestors 'none' +``` + +Even if the potential attack does not entail significant risk, it's a good security practice to add the headers. It is also detected by security scanners, so reports from penetration testers might mention the lack of these headers. + +In a case where you are rendering the login page in an iframe, adding these headers could be a breaking change. Instead of adding these headers for all customers, therefore, Auth0 has added an opt-in for these headers which we strongly recommend you to enable. + +You can do this by navigating to [Tenant Settings > Advanced Settings](${manage_url}/#/tenant/advanced), scrolling to 'Migrations', and turning OFF the 'Disable clickjacking protection for Classic Universal Login' setting. This action is not required if you are using the [New Universal Login Experience](/universal-login/new) as those headers are always set. diff --git a/fr-ca/articles/migrations/guides/extensibility-node12.md b/fr-ca/articles/migrations/guides/extensibility-node12.md new file mode 100644 index 0000000000..2ef5c6f878 --- /dev/null +++ b/fr-ca/articles/migrations/guides/extensibility-node12.md @@ -0,0 +1,191 @@ +--- +title: "Migration Guide: Extensibility and Node 12" +description: Learn about the Auth0 features affected by the Node.js v8 to Node.js v12 migration and review our recommendations for ensuring a smooth migration process. +toc: true +topics: + - migrations + - extensibility + - nodejs + - rules + - hooks + - custom-db + - custom-social-connections + - extensions +contentType: + - concept + - how-to +useCase: + - manage-accounts + - migrate +--- +# Migration Guide: Extensibility and Node 12 + +On December 31, 2019, [Node.js v8 went out of long-term support (LTS)](https://github.com/nodejs/Release#release-schedule), which means that the Node.js development team no longer back-ports critical security fixes to this version. This _could_ expose your extensibility code to security vulnerabilities. + +As such, Auth0 is migrating from Node 8 to Node 12. + +In this document, we: + +* Provide recommendations on how you can ensure a smooth migration for your environment +* Detail the specific modules affected + +## Summary of the migration + +The Webtask runtime powering the following Auth0 features use Node 8: + +* Rules +* Hooks +* Custom database connections +* Custom social connections +* Extensions + +If you do not use any of the extensibility features mentioned above, you are not affected by this migration. + +## Verified extensions + +As part of this migration, the Auth0 development team has performed extensive testing to proactively detect any breaking changes. + +Verified extensions for Node 12 include: + +* Realtime Webtask Logs +* Deploy extensions (Github, Gitlab, etc.) +* Deploy CLI + +Still, there may be behavioral changes as a result of this migration, so we have provided a migration switch that allows you to control the migration of your environment to the new Webtask runtime using Node 12. + +## Enable the Node 12 runtime + +Node 12 can be enabled through the new Extensibility panel on the [Advanced Tenant Settings](${manage_url}/#/tenant/advanced) page of the Dashboard. + +![Runtime toggle](/media/articles/migrations/node-runtime1.png) + +![Runtime toggle options](/media/articles/migrations/node-runtime2.png) + +::: warning +Changing the runtime may break your existing Rules, Hooks, and Custom Database/Social Connections. We recommend that you first switch your development tenant to the Node 12 runtime, test your setup, and switch your production tenant only when you have identified there are no breaking changes. +::: + +## Whitelist the new URLs + +The [Delegated Administration Extension](/extensions/delegated-admin) and the [Single Sign-on (SSO) Dashboard Extension](/extensions/sso-dashboard) require whitelisting the URLs used to access extensions and custom webtasks. When you upgrade to Node 12, the URLs you use to access extensions and custom webtasks will change. This is a breaking change for these extensions. + +If you use any of these extensions, **you must whitelist the new URLs** both as Allowed Callback and as Allowed Logout URLs. + +The region portion of the URL will change from 8 to 12. If you access an extension using the URL `https://${account.tenant}.us8.webtask.io/dummy-extension-url`, when you upgrade to Node 12 the URL will be `https://${account.tenant}.us12.webtask.io/dummy-extension-url`. + +To do so, go to [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings), and add the URL to the fields **Allowed Callback URLs** and **Allowed Logout URLs**. + +The execution URLs will also change for custom webtasks in your Auth0 container. You must update any external applications that call those webtasks. + +### Authorization Extension Changes + +If you use the Authorization Extension, it generates an `auth0-authorization-extension` rule. Republishing this rule from within the Authorization Extension will update the URLs automatically. + +To ensure a clean upgrade: + +1. Ensure you have upgraded to the latest version of the Authorization Extension from the "Installed Extensions" tab. If the upgrade button is present, click to upgrade. If the button is not present, you are already on the latest version of the extension. +2. Open the Authorization Extension configuration page. +3. To update the URL in the rule, publish the rule again by clicking the "Publish Rule" button. +4. Test to make sure everything is still working. +5. If you see an "Invalid API Key" error after updating, use the "Rotate" button to generate a new API key. + +![Authorization Extension Configuration](/media/articles/migrations/node-auth-ext-config.png) + +![Authorization Extension Buttons](/media/articles/migrations/node-auth-ext-buttons.png) + +### Delegated Administration URLs + +If you use the Delegated Administration Extension, the matrix that follows contains the updated URLs you must configure after you migrate to Node 12. The URL varies based on your location. + +| Location | Allowed Callback URL for Node 12 | Allowed Logout URL for Node 12 | +| --- | --- | --- | +| USA | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin` | +| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin` | +| Australia | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin` | + +For example, if you are located in the USA and you use the Delegated Administration, you should update the following fields in your application's settings: +- **Allowed Callback URLs**: `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin/login` +- **Allowed Logout URLs**: `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin` + +### SSO Dashboard URLs + +The matrix that follows contains the updated URLs you must configure after you migrate to Node 12. The URL varies based on your location. + +The login URL for **Admins**: + +| Location | Allowed Callback URL | +| --- | --- | +| USA | `https://${account.tenant}.us12.webtask.io/auth0-sso-dashboard/admins/login` | +| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-sso-dashboard/admins/login` | +| Australia | `https://${account.tenant}.au12.webtask.io/auth0-sso-dashboard/admins/login` | + +The login URL for **Users**: + +| Location | Allowed Callback URL | +| --- | --- | +| USA | `https://${account.tenant}.us12.webtask.io/auth0-sso-dashboard/login` | +| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-sso-dashboard/login` | +| Australia | `https://${account.tenant}.au12.webtask.io/auth0-sso-dashboard/login` | + +### All Extensions + +Most extensions use the `PUBLIC_WT_URL` hidden secret for authorization. This secret depends on the runtime version and does not update automatically. + +To update it, you need to save the extension's settings (no changes are necessary). To do so, after switching the runtime to `Node 12`, you need to open the extension's settings in the extensions dashboard (gear icon) and hit `Save`. After that, the extensions gallery will update the `PUBLIC_WT_URL` secret accordingly based on the selected runtime. + +If you do not update the `PUBLIC_WT_URL` hidden secret, you will receive the following error: + +![Misconfiguration or Service Outage Error](/media/articles/migrations/node-hidden-secret-error.png) + +## How to ensure a stable migration + +As part of the process of introducing Node 12 in our Webtask runtime, we ran a number of tests to determine which modules are not forward-compatible from Node 8 to 12. Most customers _should_ be able to upgrade to Node 12 without any issues. + +With that said, before you migrate, we highly recommend testing all of your: + +* Rules +* Hooks +* Custom Database Connections/Scripts +* Custom Social Connections +* Extensions + +Furthermore, we recommend that the testing be done in your development tenant and migrating your production tenant only if you see no issues in development. + +You can query the Management API for your Rules, Hooks, Custom Database scripts, and Custom Social Connections. This will make it easier for you to move items from your production tenant to development tenant for testing purposes. + +Please see our documentation on the [Connections](/api/management/v2#!/Connections), [Rules](/api/management/v2#!/Rules/get_rules), and [Hooks](/api/management/v2/#!/Hooks/get_hooks) endpoints for additional information on this process. + +When using the [Connections](/api/management/v2#!/Connections) endpoints in the Management API, Custom Database Scripts can be retrieved or updated using `options.customScripts`. + +Similarly, you can find Custom Social Connections in `options.scripts.fetchUserProfile`. + +## Affected modules + +If you are using the following built-in modules (that is, modules that you did not explicitly require), please be aware that some versions were updated to work with Node 12. The following table summarizes the changes. + +| Module name | Old version | New version | +| - | - | - | +| couchbase | ~2.5.1 | 2.6.10 | +| bcrypt | 1.0.3 | 3.0.8 | + +These new versions should remain backwards compatible with their previous versions. + +### Pinned modules + +If you have manually pinned modules, you may need to manually update them so that your code runs with Node 12. + +For example, you must change + +`var bcrypt = require(‘bcrypt@1.0.3’);` + +to + +`var bcrypt = require(‘bcrypt’);` + +or, if the module must be pinned to a specific version: + +`var bcrypt = require(‘bcrypt@3.0.8’);` + +### Notes for Node 10 and Node 12 changes + +For additional information, please consult Node.js's [Node 10 release notes](https://nodejs.org/fr/blog/release/v10.0.0/) and [Introducing Node.js 12](https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f). diff --git a/fr-ca/articles/migrations/guides/facebook-graph-api-deprecation.md b/fr-ca/articles/migrations/guides/facebook-graph-api-deprecation.md new file mode 100644 index 0000000000..39159f0b6e --- /dev/null +++ b/fr-ca/articles/migrations/guides/facebook-graph-api-deprecation.md @@ -0,0 +1,120 @@ +--- +title: Changes to Facebook Graph API +description: The latest version of the Facebook Graph API changes what permissions and fields can be requested. +toc: true +contentType: + - how-to +useCase: + - add-login + - migrate +--- + +# Changes to Facebook Login and Graph API + +The latest version of the Facebook Graph API changes what permissions and fields can be requested. We've updated Facebook Connections to reflect these changes and tweaked the connection interface for clarity. + +::: note +[Facebook Login Changelog: Recent Changes to Facebook Login](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02) +::: + +This update may not require changes to your code or configuration, but your application might receive additional profile data if the existing permissions allow it. But keep in mind that: + +* If your Facebook connection is configured to request one of the removed permissions, your Access Token will not get them in scope. +* If your Facebook application is marked as "development" then you may still see an error temporarily while trying the connection. +* If you add new permissions to the connection, end users will be prompted for consent next time they log in. See the Facebook documentation for how to handle actions for users that don't have a specific permission. + +## Facebook Login Permissions + +[Facebook Login permissions](https://developers.facebook.com/docs/facebook-login/permissions) are requested by your application when a user logs in using Facebook. If the user is logging in for the first time or if the permissions have changed, they will be shown a consent window in Facebook showing the new permissions requested. Once those permissions are granted, your application can then act on behalf of that user with a Facebook access token. + +The Facebook Connection interface has been updated to show both the regular name as well as the machine name for all permissions displayed. This makes it easier to find the permissions you need and map that to any code you might be running using these permission names. + +![Facebook Connection Permissions](/media/articles/connections/social/facebook/facebook-connection-permissions.png) + +### Permissions added + +The following permissions were added to the Facebook connection interface: + +- business_management +- groups_access_member_info +- leads_retrieval +- pages_manage_instant_articles +- publish_to_groups +- publish_to_groups +- user_age_range +- user_gender +- user_link + +### Permissions removed + +The following permissions were removed from the Facebook connection interface: + +- read_custom_friendlists +- rsvp_event +- user_about_me +- user_actions-books +- user_actions-fitness +- user_actions-music +- user_actions-news +- user_actions-video +- user_education_history +- user_games_activity +- user_relationship_details +- user_relationships +- user_religion_politics +- user_website +- user_work_history + +### Permissions moved to deprecated + +The following permissions were moved to the **Deprecated** section and should not be used with the latest version of the Graph API: + +- publish_actions +- user_managed_groups + +## Facebook Graph API Fields + +The [Facebook Graph API](https://developers.facebook.com/docs/graph-api/reference/v3.2/user) is used after a user logs in to retrieve profile data for the Auth0 user. The user data permissions requested determine what information is retrieved from the Graph API. The fields that are returned depend on the permissions requested and the existence of those fields in the Facebook user profile. + +This change upgraded the Graph API from v2.8 to v3.2 and will ask for the following user data fields on login: + +- address (added) +- age_range +- birthday +- context +- cover +- currency (added) +- devices +- email +- favorite_athletes +- favorite_teams +- first_name +- gender +- hometown +- id +- inspirational_people +- install_type (added) +- installed +- is_verified +- languages +- last_name +- link +- locale +- location +- meeting_for (added) +- middle_name +- name +- name_format +- picture +- public_key (added) +- quotes +- security_settings (added) +- short_name (added) +- significant_other +- sports (added) +- third_party_id +- timezone +- updated_time +- verified +- video_upload_limits (added) +- viewer_can_send_gift (added) diff --git a/fr-ca/articles/migrations/guides/facebook-social-context.md b/fr-ca/articles/migrations/guides/facebook-social-context.md new file mode 100644 index 0000000000..d3a06f3de5 --- /dev/null +++ b/fr-ca/articles/migrations/guides/facebook-social-context.md @@ -0,0 +1,32 @@ +--- +title: 'Context' Facebook Field Deprecation +public: false +description: Facebook is removing access to the 'social context' field from their profile +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# 'Context' Facebook Field Deprecation + +On **July 30th 00:00 UTC**, Facebook connections that request the `context` field will fail, so Auth0 will stop requesting it for all connections at that time. + +On April 30th [Facebook deprecated]( https://developers.facebook.com/docs/graph-api/changelog/4-30-2019-endpoint-deprecations) the use of the ‘Social Context’ field for new applications. Auth0 continued to request that field by default for Facebook connections created before April 30th 2019. You can make sure the field is not requested before July 30th by unchecking the ‘Social context’ field in the User Data connection section: + +![facebook context](/media/articles/migrations/facebook-context.png) + +Once you uncheck ‘Social context’, the profile data will not include the context field. The field has the following content: + +``` +"context": { + "mutual_likes": {"data": [],"summary": {"total_count": 0}}, + "id": "dXNlcl9...UZD" +} +``` + +**Do I need to take any action?** + +If you are not using the ‘context’ field in the Facebook profile returned by Auth0 in your application, then your application will keep working without changes. Otherwise, you will need to adjust your application code so it does not rely on it. + +If you want to make sure your application is not affected on July 30th we recommend you to uncheck the ‘Social context’ field in the Facebook connection properties. diff --git a/fr-ca/articles/migrations/guides/google_cloud_messaging.md b/fr-ca/articles/migrations/guides/google_cloud_messaging.md new file mode 100644 index 0000000000..3b8e862174 --- /dev/null +++ b/fr-ca/articles/migrations/guides/google_cloud_messaging.md @@ -0,0 +1,27 @@ +--- +title: Google Cloud Messaging Deprecation +description: This article describes how you can migrate your applications based on the Android Guardian SDK to Firebase Cloud Messaging +public: false +contentType: + - concept + - how-to +useCase: + - customize-mfa + - migrate +--- +# Migration to Firebase Cloud Messaging + +Auth0’s Guardian SDKs for iOS and Android helps you create custom Mobile apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. + +The Android SDK library was built to send Push Notifications using Google Cloud Messaging, which [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced with Firebase Cloud Messaging. Google Cloud Messaging will stop working on April 11th 2019. **Note that existing applications should [keep working as-is](https://aws.amazon.com/blogs/messaging-and-targeting/the-end-of-google-cloud-messaging-and-what-it-means-for-your-apps/)**. + +You can learn more about how to migrate from GCM to FCM check [Google’s documentation](https://developers.google.com/cloud-messaging/android/android-migrate-fcm). + +The main difference between how you send notifications to GCM and FCM is in the payload received in the notification. While it was possible for existing customers using the Android SDK to adapt the payload received before calling the SDK method, we have upgraded the library so it accepts the new payload, making it simpler to adopt FCM. More details [here](https://github.com/auth0/Guardian.Android/pull/84). + +The Guardian Android SDK 0.4.0 version is already available in Maven Central and includes this change. The sample application was also upgraded, so it can be tested by providing the google-services.json file and a guardian-url. + +You can check the updated documentation for the [Guardian Android SDK](/mfa/guides/guardian/guardian-android-sdk). + + + diff --git a/fr-ca/articles/migrations/guides/instagram-deprecation.md b/fr-ca/articles/migrations/guides/instagram-deprecation.md new file mode 100644 index 0000000000..d801742b37 --- /dev/null +++ b/fr-ca/articles/migrations/guides/instagram-deprecation.md @@ -0,0 +1,40 @@ +--- +title: Instagram Connection Deprecation +description: Instagram is deprecating their Authentication API +toc: true +contentType: + - how-to +useCase: + - add-login + - migrate +--- +# Instagram Connection Deprecation + +Facebook [announced](https://developers.facebook.com/blog/post/2019/10/15/launch-instagram-basic-display-api/) that on March 31th, 2020, they will turn off the Instagram legacy APIs in favor of a new set of APIs: + +- The [Instagram Graph API](https://developers.facebook.com/docs/instagram-api) which is designed for Instagram Professional Accounts, not for end-user authentication. +- The [The Instagram Basic Display API](https://developers.facebook.com/docs/instagram-basic-display-api), which is an OAuth2 API, and enables you to grant access to your basic Instagram account data to a third-party app. + +Even if it is a common industry practice to use OAuth2 as an authentication API, Facebook is explicitly forbidding using it as such, requiring applications to implement Facebook Login for authentication. Facebook will not approve applications that use the Instagram Basic Display API for authentication. + +In order to let existing users continue to access your application, you will need to ask users that are authenticating using Instagram to authenticate in a different way, and use [Account Linking](/link-accounts) to link the new identity with the old one. + +An example flow would be: + +- The user authenticates with Instagram. +- The application tells the user that they won't be able to authenticate with Instagram anymore, and that they should do it in a different way. +- The application lists the options the user has for authentication, for example: + - Facebook + - Username and Password +- After the user authenticates in a different way, you link the accounts using [Account Linking](/link-accounts). + +## Why can't Auth0 use the Instagram Basic Display OAuth endpoint + +While we could replace our current implementation and use the [Instagram Basic Display OAuth flow](https://developers.facebook.com/docs/instagram-basic-display-api/guides/getting-access-tokens-and-permissions), this would not be accepted by Facebook's policies. You would need to create an Instagram application in Facebook and, in that app, there's a notification saying: + +> Note that Basic Display is not an authentication tool. Data returned by the API cannot be used to authenticate your app users or log them into your app. If your app uses API data to authenticate users, it will be rejected during App Review. If you need an authentication solution, use Facebook Login instead. + +This means that even if Auth0 implemented this flow, your Instagram application would not be approved by Facebook. + +If you need to access Instagram data, you will need to authenticate your user in other way (for example, using Facebook Login or username/password), and implement the Instagram OAuth flow in your application. + diff --git a/fr-ca/articles/migrations/guides/legacy-lock-api-deprecation.md b/fr-ca/articles/migrations/guides/legacy-lock-api-deprecation.md new file mode 100644 index 0000000000..5398d83618 --- /dev/null +++ b/fr-ca/articles/migrations/guides/legacy-lock-api-deprecation.md @@ -0,0 +1,175 @@ +--- +title: Legacy Lock API Deprecation +description: This article covers the Legacy Lock API deprecation and gives direction as to migration paths and changes required. +toc: true +public: false +contentType: + - concept + - how-to +useCase: + - add-login + - migrate +--- +# Legacy Lock API Deprecation + +On April 4, 2018, Auth0 publicly disclosed a vulnerability. That vulnerability resulted in the deprecation of two endpoints in the Auth0 API, and the libraries and SDKs which used those endpoints. These endpoints were disabled on **July 16, 2018**, beginning a [brief grace period](https://community.auth0.com/t/soft-removal-of-legacy-lock-api/12949) in which usage of the endpoints could be re-enabled on a per-tenant basis until a migration could be completed. The endpoints have been removed from service as of **August 6, 2018**. + +The purpose of this guide is to help you to select the best migration path for your application(s) if you are impacted by the deprecation. + +## Am I affected? + +If your applications match any of the following cases, you are affected: + +* Use of versions of Lock previous to v11 and versions of Auth0.js previous to v9 in embedded login scenarios +* Use of /usernamepassword/login endpoint directly from applications +* Use of /user/ssodata endpoint directly from applications + +If you do not use the above libraries and do not specifically call the above endpoints, you are not affected. No libraries which are not specifically named are affected by this vulnerability, or in turn, by the migration. + +### If you already use Universal Login / Hosted Login Page + +Applications which log users in via Universal Login through an Auth0-hosted page are not _required_ to update the version of Lock or Auth0.js that they use _inside_ that login page (if you have customized your login page in the [Dashboard](${manage_url}/#/login_page). However, the use of the newest library versions is strongly recommended, even in the Universal Login Page. For those who have not customized their login page, the Lock v11 widget is already in use and no further action is required. + +### If you use embedded login + +Embedded login with Lock v11 and Auth0.js v9 now rely entirely on [cross-origin authentication](/cross-origin-authentication) for any form of username/password authentication (such as Auth0 DB, Custom DB, or LDAP connections). Cross-origin authentication is the situation in which credentials are collected on one domain, but validated on another. + +This cross-origin authentication protocol relies on cookies, which will be considered third-party cookies if the domain of the application and Auth0 tenant do not match. Unfortunately, some browsers block third-party cookies, and even if supported, many users may have manually disabled third-party cookies in their browsers. + +Because of these [cross-origin authentication issues](/cross-origin-authentication#limitations), there are only two general implementations that can be recommended. + +1. [Migrate to Universal Login](#1-migrate-to-universal-login). Universal Login will work with or without [custom domains](/custom-domains), and will work from most application types as well. It requires the least application code to implement and is the most secure option. + +2. [Continue to use embedded login and migrate to newer library versions](#2-continue-to-use-embedded-login-and-migrate). A crucial part of this implementation is employing a custom domain to prevent cross-origin issues. The following caveats apply: + * Only one custom domain can be applied per Auth0 tenant, so all applications on the tenant will use the same custom domain (they will need to use the same top-level domain as well). + * This option may not be viable for customers who are not eligible to use custom domains, or who choose not to do so. In those cases, Universal Login is the best approach. + +<%= include('../../_includes/_embedded_login_warning') %> + +If neither of these recommendations (Universal Login or embedded + custom domains) seem to work for your situation, please visit our [Support Center](${env.DOMAIN_URL_SUPPORT}) and file a support ticket or a community post for further guidance. + +## What do I do? + +All applications _must_ stop using the deprecated endpoints / library versions, as they have been removed from service as of August 6, 2018. Applications using those endpoints will no longer function correctly. There are two options for migration: + +### 1. Migrate to Universal Login + +Universal Login is **strongly** recommended for most use cases because it [offers many advantages](/guides/login/universal-vs-embedded) over the embedded form of login screen. These advantages include: + +* Developed, hosted and maintained by Auth0 (less maintenance required by your team). +* Provides a single place to make changes. +* More secure because credentials are collected and verified within the same domain. This reduces exposure of static credentials to multiple applications as well as the possibility of CSRF and man-in-the-middle attacks. +* Provides reliable Single Sign-on (SSO) functionality without relying on third-party cookies or restricting the domain of applications. +* Fully customizable in terms of colors, text, logos, buttons as well as [custom domain](/custom-domains). +* Provides proper cache control to avoid browsers caching old versions. +* Can leverage either the [Lock Widget](/libraries/lock) or [Auth0.js SDK](/libraries/auth0js) for flexibility in appearance and function. +* Works with any type of Auth0 connection as well as multi-factor authentication (MFA). + +#### Universal Login migration guides + + + +### 2. Continue to use embedded login and migrate + +Embedded login (embedding Lock or a custom authentication UI) should be used only if the Universal Login Page **cannot** be used. If you intend to continue using embedded login, you **must** upgrade applications from deprecated library versions. + +#### Embedded login migration guides + +
    +
  • + Auth0.js v9 Migration Guide +

    + This document presents an overview of the updates to Auth0.js in version 9 and points to technology and version-specific tutorials to help you with your migration. +

    +
    • +
+ +Continued use of embedded login will require the use of [custom domains](/custom-domains) in order to prevent cross-origin authentication issues. The custom domains documentation includes important information on the use of custom domains, how to set them up, and what configuration is required for more intricate use cases, such as custom domains with SAML. + +## Other considerations + +A few specific items are changing with the new versions / endpoints. If you use any of the following features, you might want to take a look at the corresponding section below. + +* [How to get user info](#how-to-get-user-info) +* [How to check for an existing session](#session-management) +* [How to log users out](#how-to-log-users-out) + +## How to get user info + +Once a user has been authenticated, an application may wish to retrieve information about a user. The recommended way to do this now is via the [/userinfo](/api/authentication#get-user-info) endpoint. If you are using Auth0.js v8 or v9 and using the [userInfo()](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) method, you already have made this change. + +For customers who are using the [/tokeninfo](/api/authentication#get-token-info) endpoint, this endpoint is being replaced with the /userinfo endpoint. Customers should migrate to use the /userinfo endpoint instead of /tokeninfo. The /userinfo endpoint is the only one that will be maintained going forward and is the only endpoint for user information that is supported with the [custom domains](/custom-domains) feature. + +As explained in the /userinfo endpoint docs entry, /userinfo obtains information using the Management API and therefore requires an Access Token (obtained during login) instead of the [ID Token](/tokens/concepts/id-tokens) used by /tokeninfo. + +Note also that the [/userinfo response](/api-auth/tutorials/adoption/scope-custom-claims) may vary based on scopes requested and the value of the [OIDC Conformant](/api-auth/tutorials/adoption/oidc-conformant) setting in the [Dashboard](${manage_url}) under **Applications > (Your Application) > Settings > Advanced Settings**. In that case, application code might need adjusted to handle the slightly altered response format. + +### Session management + +#### Single-Page Applications + +If a user navigates to a new page in a Single-Page Application, your application may wish to check if a user already has an existing session. In order to do this, you may have directly called the /ssodata endpoint or utilized the `getSSOData()` function in Auth0.js v8 or prior. The /ssodata endpoint is deprecated and was removed from service on **August 6, 2018**. The `getSSOData()` function will continue to work, but will behave differently, and in most cases, can be replaced with use of `checkSession()`. + +::: note +The `getSSOData()` and `checkSession()` functions should only be used from a Single-Page Application +::: + +##### checkSession() + +* The Auth0.js `checkSession()` function can be used to check whether or not a user has an existing session in Auth0. +* Invoking the `checkSession()` function will trigger an /authorize call, which will in turn result in the execution of [rules](/rules). +* The new `checkSession()` function is more lightweight and should be used as a replacement for `getSSOData()` unless `getSSOData()` features are needed. + +##### getSSOData() + +* The Auth0.js v9 `getSSOData()` function will continue to work, but it now behaves differently than in the past. +* In Auth0.js v9, `getSSOData()` will check if a user has an existing session and perform a further check to determine if the user is the same one as in the last interactive authentication transaction. This supports Lock’s feature of showing the last logged-in user to facilitate subsequent logins. +* Invoking the `getSSOData()` function will now trigger a call to the [/authorize](/api/authentication#authorize-application) endpoint, which will in turn result in the execution of [rules](/rules). + +##### Polling for an existing session + +<%= include('../../_includes/_checksession_polling') %> + +This was previously done with `getSSOData()`. The `getSSOData()` function performs more work behind the scenes than is needed for this purpose and applications that are not switched to `checkSession()` will suffer a needless performance penalty. + +#### Web applications + +In "web applications", the backend typically has a session for the user. Over time, the application session may expire, in which case the application should renew the session. The application backend should invoke a call to the [/authorize](/api/authentication#authorize-application) endpoint to get a new token. If the Authorization Server (Auth0 in this case) still has a session for the user, the user will not have to re-enter their credentials to log in again. If Auth0 no longer has a session for the user, the user has to log in again. + +Customers with web applications which call the API from their backend should use this approach. Specifically, they should [call /oauth/token](/tokens/guides/use-refresh-tokens) to renew their token. + +### How to log users out + +The deprecation does not require any changes for [logout](/logout), but if a custom domain has been configured and is used when invoking authentication, the /logout endpoint should be invoked using the custom domain as well. + +### Using Lock with AD/LDAP and Kerberos + +If your application is using Lock in embedded mode with the goal of detecting IP ranges with AD/LDAP + Kerberos, this will no longer work. + +The solution for the Kerberos case is to [migrate to Universal Login](#1-migrate-to-universal-login). Lock will no longer attempt to detect an IP range by itself when embedded in an application. However, when using Universal Login with Lock inside your hosted login page, it will use the /user/ssodata endpoint (which still works from within the login page), and that endpoint will still return “true” when the user is in the Kerberos IP range. That means that using Universal Login you can: + +* Use `getSSOData()` to achieve an automatic login +* Use Lock and get the **Use Windows Authentication** button (log in with Kerberos). + +## Troubleshooting + +See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors. diff --git a/fr-ca/articles/migrations/guides/linkedin-api-deprecation.md b/fr-ca/articles/migrations/guides/linkedin-api-deprecation.md new file mode 100644 index 0000000000..011ba33906 --- /dev/null +++ b/fr-ca/articles/migrations/guides/linkedin-api-deprecation.md @@ -0,0 +1,54 @@ +--- +title: Migration to LinkedIn API V2 +description: This article covers the LinkedIn API deprecation and how to update your Auth0 LinkedIn Connection. +toc: true +public: false +contentType: + - how-to +useCase: + - add-login + - migrate +--- + +# Migration to LinkedIn API V2 + +In December 2018, LinkedIn [deprecated version 1.0 of their sign-in API](https://engineering.linkedin.com/blog/2018/12/developer-program-updates). The final shutdown date we set for March 1st, 2019 then moved to May 1st, 2019. In June 2019, the current status is that "Applications requesting Version 1.0 APIs may experience issues as we begin to remove services." + +LinkedIn replaced the sign-in API with [version 2.0, which has some key differences](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq?context=linkedin/consumer/context). + +We've added the option to set the LinkedIn API version for LinkedIn Connections. You can change the API version for a LinkedIn Connection through the Auth0 Dashboard by selecting a **Strategy Version** under the connection's settings. + +![New LinkedIn Connection Settings](/media/articles/connections/social/linkedin/linkedin-connection-new.png) + +Auth0 will not automatically migrate all connections to Version 2 until Version 1 stops working completely. We strongly recommend that you update your connection settings to Version 2. You may need to update your application code to accommodate these API changes. + +## What's changed? + +There are changes in the user attributes you can request. + +For version 1.0 we exposed these attributes: + +| **Auth0 Attribute**| **Linkedin Scope**| +|----------------|---------------| +| Profile| r_basicprofile| +| Full Profile | r_fullprofile| +| Network | r_network| +| Email | r_emailaddress| + +For version 2.0 we expose these options: + +| **Auth0 Attribute**| **Linkedin Scope**| +|----------------|---------------| +|Profile| r_liteprofile| +|Basic Profile| r_basicprofile| +|Email| r_emailaddress| + +As you can see version 2.0: + +* Adds support for the `r_liteprofile` scope +* Removes support for the `r_fullprofile` and `r_network` scopes +* Supports the `r_basicprofile` scope only for clients that are part of [LinkedIn’s Developer Enterprise](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq#what-are-the-main-differences-with-the-new-sign-in-with-linkedin) services. + +::: note +Not all applications registered with LinkedIn can access their new API. For more details, check [Microsoft’s documentation](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq#does-my-developer-application-have-access-to-the-linkedin-v2-api). +::: diff --git a/fr-ca/articles/migrations/guides/liveid-api-deprecation.md b/fr-ca/articles/migrations/guides/liveid-api-deprecation.md new file mode 100644 index 0000000000..bdf60569cf --- /dev/null +++ b/fr-ca/articles/migrations/guides/liveid-api-deprecation.md @@ -0,0 +1,118 @@ +--- +title: Microsoft Account Migration +description: This article covers the Live Connect + SDK deprecation and how to update your Auth0 Microsoft Account Connection. +toc: true +public: false +contentType: + - how-to +useCase: + - add-login + - migrate +--- + +# Microsoft Account Migration to Azure AD (personal accounts) + Microsoft Graph + +In October 2017, Microsoft announced the [deprecation of the Live Connect API and Live SDK](https://developer.microsoft.com/en-us/office/blogs/outlook-rest-api-v1-0-office-365-discovery-and-live-connect-api-deprecation). This is a Microsoft deprecation that will affect Auth0 users using the Microsoft social connection. The change implies switching how Auth0 interacts with the Microsoft authentication APIs, and it might imply changes in customers application's code. + +The change implies switching: + +- From the Live Connect API to the Azure Active Directory v2 and OIDC protocol for Microsoft Account authentication +- From the Live SDK to Microsoft Graph to be able to get other resources including user profiles, contacts, files, etc + +Note that even though Azure AD is used, this connection type will only accept personal accounts. For work or school accounts you should use the enterprise Azure AD connection type. + +You can decide if Auth0 uses Live Connect + Live SDK or Azure AD + Microsoft Graph using the 'Strategy Version' field in the Microsoft Account connection settings page. + +![New Microsoft Connection Settings](/media/articles/connections/social/microsoft-account/microsoft-account-azureid.png) + +You need to switch to 'Azure AD (personal accounts)' to ensure your applications will keep working after Microsoft decommissions the API. + +**Microsoft Application Registration** + +Depending on when you created your Live SDK application, it might or not support Azure Active Directory v2. If it's not supported, you will need to create a different application and update your Client ID and Client Secret in the Auth0 Microsoft connection settings. As a rule, if your Client ID looks like `00000000400FFF55`, you'll need to create a new application. + +For more information, check [Microsoft's documentation](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-registration-portal). + + +**User Profile** + +Microsoft Graph provides different user profile information compared to the Live Connect and Live SDK user profile. In particular, some of the user profile fields that were previously available are not available anymore: + + +***OIDC Profile*** + +| Field | Live SDK | Microsoft Graph | +|--------|---------------|------------------| +| picture | Returned a URL for the user picture | Auth0 will build a URL that will return a default picture for the user based on their initials | +| locale | Returned a string in the format en_US | Not available | + +***Raw Profile*** + +The raw user profile that can be obtained calling the [Get User By Id Endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) has several differences when using Live SDK or Microsoft Graph. + +The JSON below shows the fields that are in the Live SDK profile but are not present, or are different, in the Microsoft Graph one: + +```js +{ + "locale": "en_ZA", + "work": [], + "emails": [ + "john.doe@windowslive.com" + ], + "addresses": { + "personal": { + "street": null, + "street_2": null, + "city": null, + "state": null, + "postal_code": null, + "region": null + }, + "business": { + "street": null, + "street_2": null, + "city": null, + "state": null, + "postal_code": null, + "region": null + } + }, + "phones": { + "personal": null, + "business": null, + "mobile": null + }, + "nickname": "john.doe@windowslive.com", + ] +} +``` + +This other one shows the fields that are in the Microsoft Graph profile but are not present, or are different, in the Live SDK one one: + +```js +{ + "strategy_version": 2, + "displayName": "John Doe", + "userPrincipalName": "john.doe@windowslive.com", + "businessPhones": [], + "nickname": "john.doe", +} +``` + +Key differences are: + +- `strategy_version` has the value `1` when the user last logged-in with Live Connect, or `2` when they last logged in with Azure AD. +- `nickname` has a different format. +- `locale`, `work`, `emails` array, `addresses`, `phones` are present in Live SDK but not in Microsoft Graph. +- `displayName`, `userPrincipalName`, `businessPhones` array are present in Microsoft Graph but not in Live SDK. + +If a user that has previously logged in with Live Connect logs in with AzureAD, the profiles will be merged. The new profile will have both the content of the Live ID profile plus the fields from the Microsoft Graph profile. + +The `strategy_version` will be set to '2' for users that last logged in with Azure AD, to '1' for users that logged in with Live Connect recently, and will not be present for users that did not login recently. You can use this field to better interpret the profile content. + +Note that the `user_id` field will be the same regardless of the API used to connect with Microsoft, even if you had to create another application to use Azure Active Directory v2. + +**Permissions** + +Auth0 lets you select which permissions you want to ask from the Microsoft Graph APIs. The ones that Live SDK and Microsoft Graph support might provide similar functionality, but the data returned by them and their format may be completely different. See [Migrating from Live SDK - Permissions](https://docs.microsoft.com/en-us/onedrive/developer/rest-api/concepts/migrating-from-live-sdk?view=odsp-graph-online#permissions) to understand what changes are required in your code. + diff --git a/fr-ca/articles/migrations/guides/management-api-v1-v2.md b/fr-ca/articles/migrations/guides/management-api-v1-v2.md new file mode 100644 index 0000000000..65ea5d6bfb --- /dev/null +++ b/fr-ca/articles/migrations/guides/management-api-v1-v2.md @@ -0,0 +1,108 @@ +--- +title: Migrate from Management API v1 to v2 +description: Learn how to migrate from Auth0 Management API v1 to v2. +topics: + - management api +contentType: + - concept + - how-to +useCase: + - management api +--- +# Migrate from Management API v1 to v2 + +Auth0’s Management API v1 was deprecated in 2016 and replaced with the [Auth0 Management API v2](/api/management/v2/). Management API v1 will reach its End Of Life in the Public Cloud on **July 13th, 2020**. Requests will begin failing with a `410` HTTP status code on or after that date. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1. + +## Key Dates + +The following are key dates for this migration: + +| Date | Public Cloud | Private Cloud | +|------|--------------|---------------| +| Jan 13, 2020 | Initial Public Announcement | N/A | +| May 21, 2020 | N/A | Initial Public Announcement | +| July 13, 2020 | End of Life for Management API v1 | N/A | +| November 2020 | N/A | Support removed from release for Mgmt API V1 | + +## Am I affected by the migration? + +Affected tenants are those who meet all of the following criteria: + +* Created before January 2, 2020 +* Actively making requests to Auth0 endpoints directly under the `/api/` path from your application. + +The following tenants are NOT affected: + +* Created after January 2, 2020 +* Exclusively using the Auth0 Management API v2 endpoints +* Using the Authentication API exclusively, the Authentication API is not affected by this deprecation. + +## How can I check to see if I've migrated all my requests? + +Deprecation Notices will be recorded in your Tenant Logs for requests that will fail at API v1’s End of Life. You can search for relevant Deprecation Notices in your tenant logs with the following query: + +``` +type:depnote AND description:*APIv1* +``` + +::: note +**Private Cloud Customers** + +- You must be running release [2003](https://auth0.com/releases/2003) or later to see Deprecation Notices. + +- If searching tenant logs from the Dashboard, search for `type:depnote`. Searching by `description` is not currently supported in the tenant logs search available in the Dashboard. If you [export your logs to an external service](/extensions#logs-export), you can leverage it to query for APIv1 Deprecation Notices using a combination of `type` and `description`. +::: + +![Management API Version 1 Log Query](/media/articles/migrations/apiv1-log-query.png) + +To help identify the Application making requests, logs will include the `client_id` used to make the request. You can also find the endpoint being used in the logs `details.path` field. + +Note that our current SDKs all use Management API v2. If you're seeing API v1 activity from an Application that is leveraging an older SDK, you should upgrade to the latest version. + +![Management API Versiion 1 Log Example](/media/articles/migrations/apiv1-log-example.png) + +::: note +Auth0 generates only one log for each `client_id` and `details.path` combination every 60 minutes. No matter how many calls you make to the deprecated endpoints, you will still see a single log per hour for *each* deprecated endpoint an application calls. + +If you implement changes to your requests, you'll need to allow 60 minutes to elapse before you can conclusively determine that the lack of new `depnote` logs means the deprecated endpoints have been removed from your code. +::: + +## What’s changing? + +For a complete list of breaking changes associated with this deprecation, see [Management API v2 Changes](/api/management/v2/changes). + +## How do I migrate? + +After replacing all calls to the Management API v1 with their [Management API v2 replacements](/api/management/v2/changes), you should confirm you are no longer seeing Deprecation Notices in your Tenant Logs and **disable the Management API v1 for your tenant.** + +You can disable API v1 by going **Tenant Settings** > **Advanced** > **Migration** in the [Auth0 Dashboard](http://manage.auth0.com/). This will simulate the expected behavior after the End of Life date, causing calls to API v1 to fail with a `410` HTTP status code. You will be able to re-enable API v1 any time before the End of Life date. + +By migrating your requests to API v2 and disabling API v1 as soon as possible, you will ensure that your systems will continue to operate uninterrupted after the **July 13th, 2020** End of Life date, at which time the option to enable API v1 will be removed. + +![Toggle Management API Version](/media/articles/migrations/apiv1-toggle.png) + +::: note +Note that tenants created after January 2, 2020 will not have access to API v1. If you need API v1 enabled on a tenant for testing your migration, please open a ticket in our [Support Center](https://support.auth0.com/tickets). +::: + +If you need help with the migration, contact us using the [Support Center](https://support.auth0.com/) or our [Community Site](https://community.auth0.com/c/auth0-community/Migrations). + +## Auth0 AD/LDAP Connector Health Monitor extension + +The [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector) extension v1 uses the API v1 `GET /api/connections/{connection-name}` and `GET /api/connections/{connection-name}/socket` endpoints. + +Please upgrade to the latest version of the extension before disabling API v1 support. + +## SharePoint Integration Custom Claims Provider + +The Custom Claims Provider of the [Auth0 SharePoint Integration](https://auth0.com/docs/integrations/sharepoint) leverages three API v1 endpoints : `/api/enterpriseconnections/users`, `/api/socialconnections/users`, and `/api/connections`. + +If you are calling these endpoints from the SharePoint integration, they will continue to work after the API v1 End of Life date. You may continue see `depnote` tenant logs for this activity. If the `client_id` in the tenant log is a SharePoint application, you can disregard this warning. + +If you are calling these endpoints directly from your code, you will need to migrate those calls off of API v1. + +## Keep reading + +* [Complete list of changes](/api/management/v2/changes) +* [Management APIv1 documentation](/api/management/v1) +* [Management APIv2 documentation](/api/management/v2) diff --git a/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md b/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md new file mode 100644 index 0000000000..2af6b0ea4e --- /dev/null +++ b/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md @@ -0,0 +1,121 @@ +--- +title: Migration Guide for Resource Owner Passwordless Authentication +description: Learn how to migrate your Passwordless API calls and responses from /oauth/ro to /oauth/token +toc: true +contentType: + - concept +useCase: + - secure-an-api + - migrate +--- +# Migration Guide for Resource Owner Passwordless Credentials Exchange + +Support for Resource Owner Password was added to [/oauth/token](/api/authentication#authorization-code). Usage of the [/oauth/ro](/api/authentication#resource-owner) endpoint was deprecated on July 08, 2017. This endpoint was used to exchange an OTP received by the end-user by email or SMS with for an `id_token` and an `access_token`. + +We have implemented a new API that replaces `oauth/ro` for this use case, and we recommend customers to migrate to the new implementation. + +## Does this affect me ? + +This change affects you if you use the resource owner passwordless credentials exchange and call `/oauth/ro` directly without the use of any Auth0 libraries or SDKs. + +<%= include('./_forced-logouts.md') %> + +## Changes to requests + +Previously, the payload of a request to `/oauth/ro` looked similar to this: + +```json +{ + "grant_type": "password", + "client_id": "123", + "username": "alice", + "password": "A3ddj3w", + "connection": "my-database-connection", + "scope": "openid email favorite_color offline_access", + "device": "my-device-name" +} +``` + +These are the changes for the new implementation: + +* The endpoint to execute token exchanges is now `/oauth/token` +* [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (or `realm`). +* Auth0 supports the [standard OIDC scopes](/scopes/current/oidc-scopes), along with the scopes which you have defined in your [custom API](/api-auth/apis). +* A scope that does not fit in one of these categories, such as the above `favorite_color`, is no longer a valid scope. +* The `device` parameter is removed. +* The `audience` parameter is optional. + +Here is an example of the payload of a request to `/oauth/token`: + +```json +{ + "grant_type" : "http://auth0.com/oauth/grant-type/passwordless/otp", + "client_id": "YOUR_CLIENT_ID", + "client_secret": "YOUR_CLIENT_SECRET", // only for web apps, native apps don’t have a client secret + "username": "", // or "" + "otp": "CODE", + "realm": "email", // or "sms" + "audience" : "your-api-audience", // in case you need an access token for a specific API + "scopes": "openid profile email" // whatever scopes you need +} +``` + +* The grant type is specified here as `http://auth0.com/oauth/grant-type/passwordless/otp` +* The parameters `client_id` and `username` are unchanged. +* The `client_secret` needs to be specified for confidential clients (e.g. regular web apps). +* The one-time password needs to be sent in the `otp` parameter instead of the `password` parameter. +* The `realm` is used to identify the connection, and replaces the `connection` parameter from previous calls. +* The `scope` parameter is mostly the same, but does not accept non-OIDC values. +* The `audience` parameter can be added, indicating the API audience the token will be intended for. + +## Changes to responses + +Responses from `/oauth/ro` were similar in format to the following: + +```json +{ + "access_token": "SlAV32hkKG", + "token_type": "Bearer", + "refresh_token": "8xLOxBtZp8", + "expires_in": 3600, + "id_token": "eyJ..." +} +``` + +* The returned Access Token is valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) (provided that the API specified by the `audience` param uses RS256 as [signing algorithm](/tokens/concepts/signing-algorithms)) and optionally the [custom API](/api-auth/apis) if one was specified. +* The ID Token will be forcibly signed using RS256 if requested by a [public client](/clients/client-types#public-clients). +* A Refresh Token will be returned only if the `offline_access` scope was granted and the API has **Allow offline access** set. + +Here is an example of the response from `/oauth/token`: + +```json +{ + "access_token": "eyJ...", + "token_type": "Bearer", + "refresh_token": "8xLOxBtZp8", + "expires_in": 3600, + "id_token": "eyJ..." +} +``` + +## Code changes when using the SDKs + +If your application uses the Auth0 native libraries for Android or iOS, be sure that the version of the library you are including is at least the minimum listed below (or higher). Also, be sure to set the 'OIDC Conformant' flag to `true` when configuring the libraries. + +|Library|Minimum Version| +|---|---| +|[Android SDK](/libraries/auth0-android/passwordless)|1.2| +|[Lock Android](/libraries/lock-android/passwordless)|2.17| +|[Swift SDK](/libraries/auth0-swift/passwordless)|1.20.0| +|[Lock iOS](/libraries/lock-ios/passwordless)|2.14.0| + +## Verifying your migration + +Once you have migrated your codebase, if you would like to be sure that your applications are no longer calling the legacy endpoint. + +You can verify whether you are still using the deprecated endpoint by checking the [tenant logs](${manage_url}/#/logs), filtering by "Deprecation Notice" and check for logs saying "oauth/ro passwordless: This feature is being deprecated". You can also perform this search directly with the following query: `type:depnote AND description:*passwordless*`. + +Once you made sure your applications are not calling the endpoint, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy `/oauth/ro` Endpoint switch. Turning off this switch will disable the deprecated endpoint for your tenant, preventing it from being used at all. + +![Legacy Migration Toggles](/media/articles/libraries/lock/migration-toggles.png) + diff --git a/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken.md b/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken.md new file mode 100644 index 0000000000..cf4d290c1f --- /dev/null +++ b/fr-ca/articles/migrations/guides/migration-oauthro-oauthtoken.md @@ -0,0 +1,102 @@ +--- +title: Migration Guide for Resource Owner Password Credentials Exchange +description: Learn how to migrate your API calls and responses from /oauth/ro to /oauth/token +toc: true +contentType: + - concept +useCase: + - secure-an-api + - migrate +--- +# Migration Guide for Resource Owner Password Credentials Exchange + +Support for Resource Owner Password was added to [oauth/token](/api/authentication#authorization-code). Usage of the [oauth/ro](/api/authentication#resource-owner) endpoint was deprecated on July 08, 2017. + +## Does this affect me ? + +This change affects you if you use the resource owner password credentials exchange, and call `/oauth/ro` directly, without the use of any Auth0 libraries or SDKs. The major Auth0 libraries such as [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js) have already been updated to stop using /oauth/ro internally. If you use the `lock-passwordless` library, you can now use [Passwordless Mode](/libraries/lock/v11#passwordless) in Lock v11 instead. + +<%= include('./_forced-logouts.md') %> + +## Changes to requests + +Previously, the payload of a request to /oauth/ro looked similar to this: + +```json +{ + "grant_type": "password", + "client_id": "123", + "username": "alice", + "password": "A3ddj3w", + "connection": "my-database-connection", + "scope": "openid email favorite_color offline_access", + "device": "my-device-name" +} +``` + +* The endpoint to execute token exchanges is now /oauth/token +* [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (or `realm`). +* Auth0 supports the [standard OIDC scopes](/scopes/current/oidc-scopes), along with the scopes which you have defined in your [custom API](/api-auth/apis). +* A scope that doesn't fit in one of these categories, such as the above `favorite_color`, is no longer a valid scope. +* The `device` parameter is removed. +* The `audience` parameter is optional. + +Here is an example of the payload of a request to /oauth/token: + +```json +{ + "grant_type": "http://auth0.com/oauth/grant-type/password-realm", + "client_id": "123", + "username": "alice", + "password": "A3ddj3w", + "realm": "my-database-connection", + "scope": "openid email offline_access", + "audience": "https://api.example.com" +} +``` + +* The grant type is specified here as `password-realm`, rather than the standard `password`. +* The parameters `client_id`, `username`, and `password` are unchanged. +* The `realm` is included because we are using Password Realm grant type, and replaces the `connection` parameter from previous calls. +* The `scope` parameter is mostly the same, but does not accept non-OIDC values. +* The `audience` parameter can be added, indicating the API audience the token will be intended for. + +## Changes to responses + +Responses from `oauth/ro` were similar in format to the following: + +```json +{ + "access_token": "SlAV32hkKG", + "token_type": "Bearer", + "refresh_token": "8xLOxBtZp8", + "expires_in": 3600, + "id_token": "eyJ..." +} +``` + +* The returned Access Token is valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) (provided that the API specified by the `audience` param uses RS256 as [signing algorithm](/tokens/concepts/signing-algorithms)) and optionally the [custom API](/api-auth/apis) if one was specified. +* The ID Token will be forcibly signed using RS256 if requested by a [public client](/clients/client-types#public-clients). +* A Refresh Token will be returned only if the `offline_access` scope was granted and the API has **Allow offline access** set. + +Here is an example of the OIDC conformant response from `oauth/token`: + +```json +{ + "access_token": "eyJ...", + "token_type": "Bearer", + "refresh_token": "8xLOxBtZp8", + "expires_in": 3600, + "id_token": "eyJ..." +} +``` + +### Verifying your migration + +Once you have migrated your codebase, if you would like to be sure that your applications are no longer calling the legacy endpoint, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy /oauth/ro Endpoint switch. Turning off this switch will disable the deprecated endpoint for your tenant, preventing it from being used at all. + +![Legacy Migration Toggles](/media/articles/libraries/lock/migration-toggles.png) + +If turning this switch off results in failed logins, this is a sign that you have yet to completely remove all instances of legacy code from your applications. + +Once migrations have been successfully performed in production environments, the switch can be toggled off and left off, to ensure that the deprecated features can no longer be used. \ No newline at end of file diff --git a/fr-ca/articles/migrations/guides/passwordless-start.md b/fr-ca/articles/migrations/guides/passwordless-start.md new file mode 100644 index 0000000000..690d1f5786 --- /dev/null +++ b/fr-ca/articles/migrations/guides/passwordless-start.md @@ -0,0 +1,100 @@ +--- +title: Migration Guide for the Use of /passwordless/start from Confidential Applications +description: Auth0 is deprecating the usage of the /passwordless/start endpoint from confidential applications without a client secret in the request. +topics: + - passwordless + - migrations +contentType: + - concept + - how-to +useCase: + - customize-connections +--- +# Migration Guide: Use of /passwordless/start from Confidential Applications + +Auth0 is deprecating the use of the `/passwordless/start` endpoint from confidential applications when Auth0 cannot authenticate that the call is made on behalf of the application. + +OAuth uses the term 'confidential' for applications that can store secrets. In Auth0, those are 'Regular Web Applications', which serve web pages from a backend app. Single Page Applications and Native Applications are considered 'public' applications, and are not affected by this change. + +Auth0 can authenticate calls to `/passwordless/start` when they include a `client_secret` as a parameter, or when the calls are made from the custom login page in Universal Login and forward the `state` parameter. + +## Does this affect me? + +If any of your applications currently call the `/passwordless/start` endpoint directly to begin passwordless authentication from a Web Application, and you are not sending the `client_secret` as a parameter, this deprecation does affect you. + +If you are implementing passwordless authentication through the Universal Login page and you changed the default way Auth0 libraries are initialized, it might also affect you too. + +You can verify whether you are affected by checking the [tenant logs](${manage_url}/#/logs), filtering by "Deprecation Notice" and check for logs saying "Enforce client authentication for passwordless connections". You can also perform this search directly with the following query: `type:depnote AND description:*passwordless*`. Note that this specific query will only work for public cloud tenants, as private cloud logs cannot be searched on the description field. + +## What do I need to do? + +If you are calling the `/passwordless/start` endpoint without proper application authentication you should: + +- Follow the instructions described below to adjust the code to properly call `/passwordless/start`. +- Check your [tenant logs](${manage_url}/#/logs) to verify the change was made correctly and no deprecation logs are being generated for "Enforce client authentication for passwordless connections". +- In the **Migrations** section of Advanced Tenant Settings, turn on the **Enforce client authentication for passwordless connections** toggle. + +## How I need to change my code? + +There are a few use cases that might be affected, but for each, the migration path is fairly straightforward: + +### 1. API calls from your backend + +For any calls from your backend to the `/passwordless/start` endpoint, your call must include the client secret as a parameter. + +If making a POST request directly to `/passwordless/start`, include the `client_secret` as part of the payload: + +```json +POST https://YOUR_AUTH0_DOMAIN/passwordless/start +Content-Type: application/json +{ + "client_id": "YOUR_CLIENT_ID", + "client_secret": "YOUR_CLIENT_SECRET", + "connection": "email|sms", + "email": "EMAIL", //set for connection=email + "phone_number": "PHONE_NUMBER", //set for connection=sms + "send": "link|code", + "authParams": { + "scope": "openid", + "state": "YOUR_STATE" + } +} +``` + +If you are using an SDK, add the parameter to the method that initiates the passwordless flow. This is different for each SDK, and not all SDKs have been updated yet. If you are using an SDK that was not updated, you can make the HTTP call directly until that work is completed. + +### 2. Using Auth0.js or Lock.js in the Universal Login page + +If the Universal Login page is used for Passwordless Authentication for a Web Application, it will be making calls to the `/passwordless/start` endpoint, by either using Lock.js or Auth0.js. + +Given you can't store a client secret in a web page, the way to authenticate the call is by forwarding the `state` parameter that is received in the Universal Login page to the `/passwordless/start` endpoint. That parameter is stored in the `config.internalOptions` field in the custom login page. + +The default templates for customizing the login page use it in the following way when initializing Lock.js or auth0.js: + +```js +var lock = new Auth0Lock(config.clientID, config.auth0Domain, { + auth: { + // .. other fields set + params: config.internalOptions + }) +``` + +```js +var params = Object.assign({ + // .. some fields set +}, config.internalOptions); + +var webAuth = new auth0.WebAuth(params); +``` + +Please check in your custom page implementation to verify that you have not removed that code. + +### 3. Calling /passwordless/start from the client in a web application + +We found that some customers are calling the `/passwordless/start` endpoint from a page using JavaScript (for example, they might be using auth0.js on the page) from Regular Web Applications. This will not be possible, as you cannot specify a client secret in a call made using JavaScript. If this is currently the case for your application, you will need to change your applications so that `/passwordless/start` is called from the backend of your web application, rather than from the frontend. + +## Rate Limits + +A consequence of adding client authentication to `/passwordless/start` is that Auth0 can trust the headers sent with the request. Auth0 takes into account the `auth0-forwarded-for` header when enforcing rate limits. If you set that header with the end user's IP address when making the call from the server, Auth0 will rate limit the endpoint based on the end user's IP, instead of the server IP. + +You can read more about this in the [passwordless endpoints](/connections/passwordless/relevant-api-endpoints#rate-limiting-in-passwordless-endpoints) documentation. diff --git a/fr-ca/articles/migrations/guides/unpaginated-requests.md b/fr-ca/articles/migrations/guides/unpaginated-requests.md new file mode 100644 index 0000000000..6ee5a263c8 --- /dev/null +++ b/fr-ca/articles/migrations/guides/unpaginated-requests.md @@ -0,0 +1,67 @@ +--- +title: Migrate to Management API v2 Endpoint Paginated Queries +description: Query requests to specific Management API endpoints will return up to 50 results instead of all available items. You must now specify `page` and `per_page` parameters. +topics: + - pagination + - migrations +contentType: + - concept + - how-to +useCase: + - paginated-results +--- +# Migrate to Management API v2 Endpoint Paginated Queries + +After **26 January 2021**, requests to Management API v2 endpoints will return a maximum of 50 items for tenants in the Public Cloud. To retrieve more items, you must include the `page` and `per_page` parameters. Beginning on **21 July 2020**, Auth0 will display tenant logs and a migration toggle to help you prepare for this change. + +Affected tenants are those that meet the following criteria: + +* Auth0 Public Cloud (currently) +* Created **before 21 July 2020** +* Actively making calls to the affected endpoints without passing the `per_page` parameter for queries that can return more than 1 result. + +The following tenants are not affected: + +* Created **on or after 21 July 2020** +* Not using any of the affected endpoints +* Using the affected endpoints and passing the `per_page` parameter, or making queries that will always return a single result. + +## Endpoints affected + +Calls to the following Management API v2 endpoints are affected: + +* [`GET /api/v2/clients`](/api/management/v2#!/Clients/get_clients) +* [`GET /api/v2/client_grants`](/api/management/v2#!/Clients/client_grants) +* [`GET /api/v2/grants`](/api/management/v2#!/Clients/grants) +* [`GET /api/v2/connections`](/api/management/v2#!/Clients/connections) +* [`GET /api/v2/device-credentials`](/api/management/v2#!/Clients/device_credentials) (when `type` query parameter is provided) +* [`GET /api/v2/resource-servers`](/api/management/v2#!/Clients/resource_servers) +* [`GET /api/v2/rules`](/api/management/v2#!/Clients/rules) + +Deprecation notices will be recorded in your tenant logs for all requests without pagination options that are currently returning more than 1 item, once per hour, for each different client and endpoint. + +## Actions + +1. Replace all calls to the affected endpoints by providing the `page` and `per_page` parameters. + +| Parameter | Type | Description | +| -- | -- | -- | +| `page` | Integer | Page index of the results to return. First page is 0. If `page` is not specified, it will default to 0. | +| `per_page` | Integer | Number of results per page. Paging is disabled if the parameter is not sent. `per_page` has a maximum value of 100. | + +2. Confirm that you are no longer seeing deprecation notices in your tenant logs. Check if a request returned more than 50 items. Look at the `details.size_exceeded` field and check if it’s `true`. + - Use the following log query to return all calls without pagination options with more than 1 result: `type:depnote AND description:*Unpaginated*` + - Use the following log query to return all calls without pagination options with more than 50 results: `type:depnote AND description:*Unpaginated* AND details.size_exceeded:true` + + To identify the application making request, logs will include the `client_id` used to make the request. You can also find the endpoint being used in the logs `details.path` field. + +3. Disable Management API unpaginated requests for your tenant. Go to [**Dashboard > Tenant Settings > Advanced > Migration**](${manage_url}/#/tenant/advanced). This will simulate the expected behavior after the migration window closes, causing calls to affected endpoints to return up to 50 results. + + You will be able to re-enable unpaginated requests any time before that date. + +### Update extensions + +You may need to update from previous versions of [Auth0 Extensions](/extensions) and custom extensions may need to be updated to their latest versions to make sure they are only performing paginated queries. + +1. Check your tenant logs for deprecation notices for clients with an ID matching an extension URL. It means you will need to update that extension. +2. Go to [**Dashboard > Extensions**](${manage_url}/#/extensions), select **Installed Extensions**, and click on the extension's **Update** link if present. diff --git a/fr-ca/articles/migrations/guides/yahoo-userinfo-updates.md b/fr-ca/articles/migrations/guides/yahoo-userinfo-updates.md new file mode 100644 index 0000000000..33bd6ea68a --- /dev/null +++ b/fr-ca/articles/migrations/guides/yahoo-userinfo-updates.md @@ -0,0 +1,58 @@ +--- +title: Changes to Yahoo Profile +description: The latest version of the Yahoo API changes the structure of the user profile +toc: true +contentType: + - how-to +useCase: + - add-login + - migrate +--- + +# Changes to Yahoo Profile + +Yahoo changed the API that applications need to use to retrieve the User Profile from their [Social Directory API](https://developer.yahoo.com/oauth/social-directory-eol/) to a Yahoo `/userinfo` endpoint. This change implies that the structure of the user profile for Yahoo users in Auth0 will change. + +Auth0 previously loaded all the profile data that Yahoo returned, and added these additional fields that were mapped from the Yahoo profile: + +|Auth0 field|Yahoo field| +|---|---| +|user_id|guid| +|sub|guid| +|name|nickname| +|time_zone|timeZone| +|uri|uri| +|url|profileUrl| +|isConnected|isConnected| +|email_verified|verified| +|email|email| + +Yahoo stopped returning `url`, `profileUrl`, `isConnected`, and a set of other fields listed in [Yahoo’s documentation](https://developer.yahoo.com/oauth/social-directory-eol/) (see ‘List Of Attributes Deprecated in Social Directory Profile Api’). Those other fields will also not be part of the profile. + +The Yahoo `/userinfo` endpoint will return different fields depending on the API Permissions you configure in the [Yahoo Application](https://developer.yahoo.com/apps/) definition. + +Yahoo lets you grant one of four permissions in the **Profile (Social Directory)** permissions section: + +- Read Public Basic +- Read Public Extended +- Read Write Public +- Read Write Public and Private + +When configuring the Yahoo Connection in your Auth0 Dashboard, you need to select the attribute that corresponds to the permissions you granted in your Yahoo setup. If you choose an attribute that does not match what you specified on Yahoo, the login transaction will fail. + +|Yahoo Connection Attributes|Profile Fields| +|--|--| +|Basic Profile| sub, name, given_name, family_name, locale| +|Basic Profile Write| sub, name, given_name, family_name, locale| +|Extended Profile |sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number, nickname | +|Extended Write | sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number, nickname | + +If you do not select any permissions in the Auth0 connection settings, Auth0 will by default ask for the `openid` scope, which will return the profile fields that correspond to whatever API Permission you specified in the Yahoo Application. For example, if your Yahoo application is configured with `Read Public Extended`, it will return the `sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number and nickname` fields. + +**Do I need to take any action?** + +Auth0 will default to send the `openid` scope when authenticating with Yahoo. + +If you are using the Yahoo connection to authenticate users and get their basic information, your application will continue to work without changes. + +If your application is accessing fields in the user profile that are no longer available, then you will need to make sure you enable the right Connection Attribute in the Auth0 dashboard and adjust your application code to use the proper field names. diff --git a/fr-ca/articles/migrations/past-migrations.md b/fr-ca/articles/migrations/past-migrations.md new file mode 100644 index 0000000000..5956128735 --- /dev/null +++ b/fr-ca/articles/migrations/past-migrations.md @@ -0,0 +1,272 @@ +--- +toc: true +description: List of Auth0 migrations that have already been enabled for all customers +topics: + - migrations +contentType: + - reference +useCase: + - migrate +--- +# Past Migrations + +These are migrations that have already been enabled for all customers. + +## Introducing Lock v11 and Auth0.js v9 + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Medium | 2017-12-21 | 2018-08-06 | + +We are continually improving the security of our service. As part of this effort, we have deprecated the Legacy Lock API, which consists of the /usernamepassword/login and /ssodata endpoints. These endpoints are used by Lock.js v8, v9, and v10 and Auth0.js, v6, v7, and v8, and can also be called directly from applications. + +As of August 6, 2018, Auth0 has permanently disabled the Legacy Lock API. This removal of service fully mitigates the CSRF vulnerability disclosed in April 2018. This also ends the soft removal grace period that was [first announced on July 16, 2018](https://community.auth0.com/t/auth0-legacy-lock-api-disabled-grace-period-available/12949), meaning the Legacy Lock API can no longer be re-enabled. + +If your Legacy Lock API migration has not yet been completed, your users may experience an outage, failed logins, or other adverse effects. You will need to complete your migration in order to restore normal functionality. See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) to identify the source(s) of any errors in your tenant logs related to deprecations. + +### Am I affected by the change? + +If you are currently implementing login in your application with Lock v8, v9, or v10, or Auth0.js v6, v7, or v8, you are affected by these changes. Additionally, you are affected if your application calls the /usernamepassword/login or /ssodata endpoints directly via the API. + +We **recommend** that applications using [Universal Login](/universal-login) update the library versions they use inside of the login page. + +However, those who are using Lock or Auth0.js embedded within their applications, or are calling the affected API endpoints directly, are **required** to update, and applications which still use deprecated endpoints will cease to function properly after the removal of service date. + +Libraries and SDKs not explicitly named here are not affected by this migration. + +## New IP Addresses for Whitelisting in Australia + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Low | 2017-08-22 | 2017-09-30 | + +Auth0 is updating its cloud environments, and traffic from these regions will originate from new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules. + +### Am I affected by the change? + +If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall: + +``` +13.55.232.24, 13.54.254.182, 13.210.52.131, 52.62.91.160, 52.63.36.78, 52.64.84.177, 52.64.111.197, 52.64.120.184, 54.66.205.24, 54.79.46.4, 54.153.131.0 +``` + +If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +## New IP Addresses for Whitelisting in Europe + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Low | 2017-08-22 | 2017-09-30 | + +Auth0 is updating its cloud environments, and traffic from these regions will originate from new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules. + +### Am I affected by the change? + +If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall: + +``` +34.253.4.94, 35.156.51.163, 35.157.221.52, 52.16.193.66, 52.16.224.164, 52.28.45.240, 52.28.56.226, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.50.106.250, 52.57.230.214, 52.211.56.181, 52.213.216.142, 52.213.38.246, 52.213.74.69 +``` + +If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +## CDN provider migration in the Europe and Australia environments + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Low | N/A | 2017-07-12 | + +The existing Auth0 CDN service is one of our older services. It was been built and maintained internally since the early days of the company. To improve its scaling and availability, we are changing providers to use Amazon CloudFront on July 12, at 1pm UTC. We have already made this change in the US environment, and are now ready to do so in Europe and Australia. + +### Am I using the CDN? + +If you use Lock (hosted by our CDN) in Europe or Australia, yes. + +### Do I need to do something? + +This change shouldn't cause any disruption or change in behavior in your applications, so you don't have to do anything. This notification is for information only. + +If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +## Whitelisting IP Address Ranges (Q1 2017) + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Low | 2017-01-15 | 2017-02-20 | + +Auth0 is expanding into new US regions, and traffic originating from these regions will have new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules. + +### Am I affected by the change? + +If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to add the following IP addresses to your firewall rules: + +``` +138.91.154.99, 54.183.64.135, 54.67.77.38, 54.67.15.170, +54.183.204.205, 54.173.21.107, 54.85.173.28, 35.167.74.121, 35.160.3.103, +35.166.202.113, 52.14.40.253, +52.14.38.78, 52.14.17.114, 52.71.209.77, 34.195.142.251, 52.200.94.42 +``` + +If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +## Vulnerable Password Flow + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Medium | 2016-03-22 | 2017-02-01 | + +The current password reset flow on Auth0 allows a user to enter their email and a new password. This triggers a confirmation email that is sent to the user asking them to confirm that they requested a password reset. + +The issue is that the confirmation link may be inadvertently clicked by a user, which would result in the user's password being changed by an attacker. + +Lock version 9 and above uses the [new password reset flow](/connections/database/password-change) exclusively. Lock 8 and below does not handle the new password reset flow. We strongly recommend upgrading to Lock 9 or greater as soon as possible. + +::: panel Security Warning +Even if you are not using Lock, the vulnerable reset flow can be accessed directly through the API. (See the [/dbconnections/change_password](/api/authentication/reference#change-password) endpoint for details.) We strongly encourage any app using the current flow to move immediately to the new reset flow and enable this migration. +::: + +## Account Linking Removal + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Medium | 2017-01-03 | 2017-03-01 | + +As part of Auth0's efforts to improve security and standards compliance, we will stop supporting account linking as part of the authorization callback (that is, accepting an Access Token as part of the [authorize](/api/authentication#authorization-code-grant) call as stated [in the account linking section](/api/authentication?http#account-linking). + +### Am I affected by the change? + +If you received an email notification about it, then you are impacted by this change. As you work to update your applications to [use the Management API to link accounts](/api/management/v2#!/Users/post_identities), you can check if you are still impacted, by checking your tenant logs for warnings indicating _"Account linking via /authorize is being deprecated. See [User Account Linking](/users/concepts/overview-user-account-linking) for supported ways to link an account."_. These entries will be logged if you are sending an Access Token in your [authorize](/api/authentication#authorization-code-grant) calls. + +If you need help with the migration, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}) + +## Password and Refresh Token Exchange Rules Migration Notice + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | +| Medium | 2017-02-23 | 2017-05-31 | + +As part of Auth0's efforts to improve security, we recently added the ability to execute rules during the OAuth 2.0 Resource Owner Password Grant exchange (the password exchange) and the Refresh Token exchange. + +You are using this feature if you are calling the [/oauth/token](/api/authentication#authorization-code) endpoint of our Authentication API with `grant_type = "password"` , `grant_type = "http://auth0.com/oauth/grant-type/password-realm"`, or `grant_type = "refresh_token"`. + +### Am I affected by the change? + +You could be impacted if you are currently using these exchanges and have Rules defined in Dashboard. In order to ensure a smooth transition, we have disabled the rules execution on these specific exchanges for your tenant. These rules will now execute for all new customers, as well as customers who have not yet used these exchanges. + +You can add logic to your rules to alter their behavior for these exchanges by checking the `context.protocol` property: +- `oauth2-password` indicates the password (and password-realm) exchange +- `oauth2-refresh-token` indicates the Refresh Token exchange + +If you would like to enable the new behavior on this tenant for testing before the mandatory opt-in date, login to [Dashboard](${manage_url}) and enable the __Run Rules on Password and Refresh Token Exchanges__ toggle in [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced). + +If you need help with the migration, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}) + +## Email Delivery Changes: "From" Address + +| Severity | Platforms | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | --- | +| Medium | Auth0 Cloud Only | 2016-04-20 | 2016-04-27 | + +Auth0's built-in email provider starting sending all emails from a predefined "from" address (`no-reply@auth0user.net`). Custom Email Providers will now be free for every customer, and to be able to customize the "from" address you can switch to an Auth0-supported [third-party service](/email/providers) ([Amazon SES](https://aws.amazon.com/ses/), [Mandrill](https://www.mandrill.com/signup/), [SendGrid](https://sendgrid.com/pricing)) or another [SMTP-based provider](/email/custom). + +If you already use a custom email provider, nothing will change. + +For more information, see: [Emails in Auth0](/email). + +## TokenInfo endpoint validation + +| Severity | Mandatory Opt-In| +| --- | --- | +| Low | 2016-06-01 | + +When calling the [TokenInfo](/api/authentication/reference#get-token-info) endpoint, the URL of the API call (for example `https://${account.namespace}/`) must match the value of the `iss` attribute of the ID Token being validated. + +If these values do not match, the response will be `HTTP 400 - Bad Request`. + +### Am I affected by the change? + +If you are calling the [tokeninfo](/api/authentication#get-token-info) endpoint directly, make sure that the value of the `iss` attribute of the ID Token being validated matches your Auth0 tenant namespace: `https://${account.namespace}/`. + +::: note +You can use [jwt.io](https://jwt.io/) to decode the token to confirm the `iss` attribute value. +::: + +## Identity Provider Access Tokens removed from user profile and ID Token + +| Severity | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | --- | +| Medium | 2016-07-11 | 2016-08-18 | + +The format of the user profile JSON object (ID Token) that is returned by Auth0 Authentication APIs has been changed to remove the Identity Provider's Access Token, which had been included in the user profile `identities` array. + +Now, to obtain a user's IdP Access Token, you will need to make an HTTP GET call to the `/api/v2/users/{user-id}` endpoint containing an API token generated with `read:user_idp_tokens` scope. + +::: note +You will still have access to the Identity Provider Access Token in the `user` argument in Auth0 [rules](/rules). +::: + +### Am I affected by the change? + +You are affected by the change only if you are using the Identity Provider Access Token (`identities[0].access_token` in the user profile) outside of rules to call other services from the Identity Provider (such as Facebook Graph API, Google APIs, and so on). + +For more information on how to obtain an Access Token, see: [Call an Identity Provider API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api) and [Identity Provider Access Tokens](/tokens/overview-idp-access-tokens). + +::: note +If your tenant was created after the change, this update will be applied automatically. +::: + +## Email Delivery Changes: Template Customizations + +| Severity | Platforms | Grace Period Start | Mandatory Opt-In| +| --- | --- | --- | --- | +| Medium | Auth0 Cloud Only | 2016-07-21 | 2016-08-29 | + +Auth0's built-in email provider will no longer be supported for use in a production environment. The emails sent using the Auth0 provider will no longer be customizable. They will be restricted to the template and you will not be able to change the *from address* or subject line. + +The built-in email service may still be used for test purposes but you must switch to an Auth0-supported [third-party service](/email/providers) ([Amazon SES](https://aws.amazon.com/ses/), [Mandrill](https://www.mandrill.com/signup/), [SendGrid](https://sendgrid.com/pricing)) or another [SMTP-based provider](/email/custom) before moving your apps to production. + +If you already use a custom email provider, no action is necessary. + +For more information, see: [Emails in Auth0](/email). + +## Delete All Users Endpoint Change + +| Severity | Effective Date | +| --- | --- | --- | --- | +| Low | 2016-09-13 | + +The previous endpoint for deleting all users was `DELETE /api/v2/users`. This is rather similar to the endpoint to delete _one_ user: [DELETE /api/v2/users](/api/management/v2#!/Users/delete_users_by_id). To prevent accidental requests to the delete all users endpoint, the url has been changed to `DELETE /api/v2/allusers`. This should ensure that only intentional calls to this endpoint get made. + +### Am I affected by the change? + +You are affected by the change only if you currently make use of the delete all users endpoint. If so, the only change you need to make is to change the URL as explained above. + +## State Parameter required on redirect from rule + +| Severity | Effective Date | +| --- | --- | --- | --- | +| High | 2016-11-01 | + +When a redirect is done from an Auth0 rule, Auth0 takes care of generating and sending a state parameter in HTTP and Auth0 will check for a valid state parameter when flow returns to the /continue endpoint. The site to which the redirect goes has to capture the value of the state parameter and return it by adding it as a parameter when returning to the /continue endpoint. + +This is documented [here](/rules/redirect#what-to-do-after-redirecting) + +### Am I affected by the change? + +You are effected by the change only if you redirect from rules, and do not yet capture and return (to the /continue end point) the state parameter. + +## Patch and Post endpoints no longer accept secret_encoded flag + +| Severity | Effective Date | +| --- | --- | --- | --- | +| High | 2016-12-06 | + +The `jwt_configuration.secret_encoded` configuration is no longer accepted by the PATCH and POST applications endpoints. + +In order to further comply with the OIDC specification, Auth0 will no longer generate or accept base64 encoded application secrets for new applications. + +Existing applications with encoded secrets stored will remain intact and unchanged, but *new* applications will no longer use base64 encoding. The `secret_encoded` flag is no longer accepted or necessary, as a result. + +### Am I affected by the change? + +You are affected by this change only if you interact with these endpoints directly. diff --git a/fr-ca/articles/monitoring/_includes/_monitor-private-cloud.md b/fr-ca/articles/monitoring/_includes/_monitor-private-cloud.md new file mode 100644 index 0000000000..a0dc01777f --- /dev/null +++ b/fr-ca/articles/monitoring/_includes/_monitor-private-cloud.md @@ -0,0 +1,3 @@ +::: panel Monitor a dedicated deployment +See the [Private Cloud](/private-cloud) documentation for information on [monitoring](/appliance/monitoring) a dedicated deployment. +::: \ No newline at end of file diff --git a/fr-ca/articles/monitoring/guides/check-external-services.md b/fr-ca/articles/monitoring/guides/check-external-services.md new file mode 100644 index 0000000000..3dfbf87d5f --- /dev/null +++ b/fr-ca/articles/monitoring/guides/check-external-services.md @@ -0,0 +1,46 @@ +--- +title: Check External Services Status +description: Learn how to check the status of services external to Auth0. +topics: + - monitoring +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics +--- + +# Check External Services Status + +You may want to monitor any remote identity providers you use with your Auth0 connections to quickly isolate the source of the problem. + +If you see potential issues with your Auth0 service, but [Auth0 Status](https://status.auth0.com) doesn't indicate any problems, check the status of any external services that you use with Auth0, such as: + +* [Amazon Web Services](https://status.aws.amazon.com/) +* [Azure Active Directory](https://azure.microsoft.com/en-us/status/) +* [Citrix](https://status.cloud.com/) +* [Facebook](https://developers.facebook.com/status/) +* [GitHub](https://status.github.com/) +* [Google Cloud](https://status.cloud.google.com/) +* [Google's G Suite](https://www.google.com/appsstatus#hl=en&v=status) +* [Heroku](https://status.heroku.com/) +* [IBM](https://console.bluemix.net/status) +* [Mandrill](http://status.mandrillapp.com/) +* [Microsoft Azure](https://azure.microsoft.com/en-gb/status/) +* [SAP](https://www.sap.com/about/cloud-trust-center/cloud-service-status.html) +* [SendGrid](http://status.sendgrid.com/) +* [SFDC](https://status.salesforce.com/) +* [Slack](https://status.slack.com/) +* [Twilio](https://status.twilio.com/) +* [VM Ware](https://status.vmware-services.io/) + +::: note +Your customers may have some of the same concerns, so you may want to document any monitoring pages or endpoints that they can view to help them troubleshoot and narrow down the location of an issue. +::: + +## Keep reading + +* [Check Auth0 Status](/monitoring/guides/check-status) +* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM) +* [Monitor Applications](/monitoring/guides/monitor-applications) diff --git a/fr-ca/articles/monitoring/guides/check-status.md b/fr-ca/articles/monitoring/guides/check-status.md new file mode 100644 index 0000000000..98f4181a57 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/check-status.md @@ -0,0 +1,44 @@ +--- +title: Check Auth0 Status +description: Learn how to check Auth0 public cloud service availability, incident reports, and historical uptime reports. +topics: + - monitoring +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics +--- + +# Check Auth0 Status + +Auth0 makes every effort to minimize outages, but if there is any disruption to service, it will appear on the [Auth0 Status](https://status.auth0.com) page. To support requirements for root cause analysis documentation after a disruption, Auth0 conducts internal analysis and publishes the results of the disruption notice. If there's an outage listed on the status page, you do not need to file a ticket. Auth0 is already working on the issue. + +## Check status + +Go to [Auth0 Status](https://status.auth0.com) to check the service availability of the cloud version of Auth0. + +You can see the status of a region or expand a region and see the status of individual services supporting functionality such as the authentication API or execution of custom code (used within custom DB connections and rules). + +## Subscribe to status updates + +On the [Auth0 Status](https://status.auth0.com) page, choose your region and environment and click **Subscribe to Updates** to get updates. You can choose from two options to view status: + +* Follow [@auth0status](https://twitter.com/auth0status) on Twitter to get the latest status updates. + +* Subscribe to the Auth0 Atom feed to get status updates that affect your tenant. Using an RSS feed aggregator of your choice (such as https://feeder.co/reader), use the following RSS feed URL to view the status of your tenant. Replace `YOUR-TENANT` with your tenant name. + + `status.auth0.com/feed?domain={YOUR-TENANT}.auth0.com` + +## Historical uptime reports + +Current and historical Auth0 uptime reports are available at [Auth0 Uptime](http://uptime.auth0.com). + +## Keep reading + +* [Check External Services Status](/monitoring/guides/check-external-services) +* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM) +* [Monitor Applications](/monitoring/guides/monitor-applications) +* [Troubleshooting](/troubleshoot) +* [Support Options](/support) diff --git a/fr-ca/articles/monitoring/guides/monitor-applications.md b/fr-ca/articles/monitoring/guides/monitor-applications.md new file mode 100644 index 0000000000..f84e4eb665 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/monitor-applications.md @@ -0,0 +1,32 @@ +--- +title: Monitor Applications +description: Learn how to monitor your own applications and perform end-to-end testing using your own tests. +topics: + - monitoring +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics + - synthetic-authentication + - synthetic-transactions +--- +# Monitor Applications + +If you would like to monitor your own [application](/applications) or conduct end-to-end testing, you’ll need to set up your own tests. + +If you've extended Auth0 through [rules](/rules) or a [custom database connection](/connections/database/custom-db), you can build a synthetic transaction that exercises these capabilities using the [Resource Owner Password Grant](/api-auth/tutorials/password-grant). One way of doing this is to [Monitor Auth0 Using SCOM](/monitoring/guides/monitor-using-SCOM). + +Auth0 recommends using an authentication flow that doesn't require a user interface such as the **Resource Owner Password Grant**. That way, you can use a monitoring tool that doesn't have to mimick the actions of a user. Many monitoring services exist with this capability including: + +* [New Relic](http://newrelic.com) +* [Pingdom](http://pingdom.com) + +Use one of these services to execute synthetic authentication requests. + +## Keep reading + +* [Check Auth0 Status](/monitoring/guides/check-status) +* [Check External Services Status](/monitoring/guides/check-external-services) +* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM) diff --git a/fr-ca/articles/monitoring/guides/monitor-using-SCOM.md b/fr-ca/articles/monitoring/guides/monitor-using-SCOM.md new file mode 100644 index 0000000000..97918bb43f --- /dev/null +++ b/fr-ca/articles/monitoring/guides/monitor-using-SCOM.md @@ -0,0 +1,80 @@ +--- +title: Monitor Auth0 Using System Center Operations Manager +description: Learn how to monitor Auth0 as a standard web application using System Center Operations Manager (SCOM) or any tool that supports synthetic transactions. +toc: true +topics: + - monitoring +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics + - synthetic-authentication + - synthetic-transactions +--- +# Monitor Auth0 Using System Center Operations Manager + +You can monitor Auth0 as a standard web application using System Center Operations Manager (SCOM) or any tool that supports synthetic transactions. + +We recommend monitoring a synthetic login transaction that includes the extensions your applications rely on (such as rules that execute custom code for integration with your company's other services). + +## Set up SCOM + +1. Add a new SCOM instance using the **Add Monitoring Wizard**: + + | **Field** | **Description** | + | ---| ---| + | **Name** | Description name for the SCOM instance. | + | **Description** | Description of what this SCOM instance monitors. | + | **Select destination management pack** | Default Management Pack | + + When finished, click **Next** to continue. + + ![ss-2014-11-21T15-44-34.png](/media/articles/monitoring/ss-2014-11-21T15-44-34.png) + +2. Click **Add** to enter the URLs you want SCOM to monitor. When finished, click **Next** to continue. + + ![ss-2014-11-21T16-31-15.png](/media/articles/monitoring/ss-2014-11-21T16-31-15.png) + +3. Click **Add** to set up a location from which you want to monitor. + + In the pop-up dialog, search for **Internal location - Agent**. Select the appropriate address, and click **Add**. Then click **Ok** to finish selecting the location. When finished, click **Next** to continue. + + ![ss-2014-11-21T16-32-25.png](/media/articles/monitoring/ss-2014-11-21T16-32-25.png) + +4. Set the frequency with which SCOM collects data from each endpoint: + + | **Data** | **Frequency** | + | --- | --- | + | **Test frequency** | 60 seconds | + | **Performance data collection interval** | 60 seconds | + | **Test time-out** | 30 seconds | + | **HTTP status code** | Greater than or equals 400 | + + When finished, click **Next** to continue. + + ![ss-2014-11-21T16-33-51.png](/media/articles/monitoring/ss-2014-11-21T16-33-51.png) + +## Run SCOM tests + +1. Click **Run Test** to test each endpoint and ensure that the connection settings provided are correct. + + ![ss-2014-11-21T16-34-25.png](/media/articles/monitoring/ss-2014-11-21T16-34-25.png) + +2. Once you have finished configuring your SCOM instance, you can view activity through the **Monitoring** tab: + + ![ss-2014-11-25T17-20-47.png](/media/articles/monitoring/ss-2014-11-25T17-20-47.png) + +## Review test results + +Click **Web Application Status** to bring up the information SCOM has gathered. + +![ss-2014-11-25T17-22-10.png](/media/articles/monitoring/ss-2014-11-25T17-22-10.png) + +## Keep reading + +* [Monitoring the AD/LDAP Connector with System Center Operations Manager](/connector/scom-monitoring) +* [Check Auth0 Status](/monitoring/guides/check-status) +* [Check External Services Status](/monitoring/guides/check-external-services) +* [Monitor Applications](/monitoring/guides/monitor-applications) diff --git a/fr-ca/articles/monitoring/guides/send-events-to-keenio.md b/fr-ca/articles/monitoring/guides/send-events-to-keenio.md new file mode 100644 index 0000000000..22fc43d835 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/send-events-to-keenio.md @@ -0,0 +1,77 @@ +--- +title: Send Logging Events to Keen +description: Learn how to send logging events to Keen from Auth0. +topics: + - monitoring + - keenio +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - analyze-external-analytics + - integrate-analytics +--- +# Send Logging Events to Keen + +[Keen](http://keen.io) provides a service to capture and analyze events generated in your apps. In their words: + +> Analytics transforms data into answers – the kind of answers every company deserves. Unfortunately, a lot of companies a) can't find an analytics service that's right for their specific needs, and b) don't have the resources to develop their own analytics infrastructure. That's why we started Keen IO. Basically, we built it, so you don't have to. And we made it powerful, flexible, and scalable enough that you can use it however you need to – even if those needs change over time. + +In this example, you will learn how to connect Auth0 to Keen and stream `signup` events. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline. + +![Keen IO Dataflow](/media/articles/tutorials/keen-io-dataflow.png) + +## Record a sign-up event in Keen + +Create a rule that will record user `signup` events for your apps in Keen. Please note: + +* In this example, we expect your Keen credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your **Write Key** here before running your rule. Doing this allows you to use your key in multiple rules and prevents you from having to store it directly in the code. + +* For this rule, we send contextual information, such as IP address (can be used to deduce location), user ID, and username. However, you can send any number of properties. + +* For this rule, we track the event type using a __persistent__ property called `user.signedUp`. When the property is set to `true`, we return immediately. Otherwise, we assume the event is a new `signup`, and if everything goes well, we set the property to `true`. The next time the user signs in, this rule will be skipped. + + +```js +function(user, context, callback) { + + var request = require('request'); + + if(user.signedUp){ + return callback(null, user, context); + } + + var writeKey = configuration.KEENIO_WRITE_KEY; + var projectId = configuration.KEENIO_PROJECT_ID; + var eventCollection = 'signups'; + + var keenEvent = { + userId: user.user_id, + name: user.name, + ip: context.request.ip //Potentially any other properties in the user profile/context + }; + + request.post({ + method: 'POST', + url: 'https://api.keen.io/3.0/projects/' + projectId + '/events/' + eventCollection, + headers: { + "Authorization: " + writeKey, + 'Content-type': 'application/json' + }, + body: JSON.stringify(keenEvent), + }, + function (e, r, body) { + if( e ) return callback(e,user,context); + //We assume everything went well + user.persistent.signedUp = true; + return callback(null, user, context); + }); +} +``` + +## Keep reading +Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples: + +* Rules for access control +* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com), [Segment](https://segment.com/) diff --git a/fr-ca/articles/monitoring/guides/send-events-to-segmentio.md b/fr-ca/articles/monitoring/guides/send-events-to-segmentio.md new file mode 100644 index 0000000000..51f8030308 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/send-events-to-segmentio.md @@ -0,0 +1,90 @@ +--- +title: Send Logging Events to Segment +description: Learn how to send logging events to Segment from Auth0. +topics: + - monitoring + - segmentio +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - analyze-external-analytics + - integrate-analytics +--- +# Send Logging Events to Segment + +[Segment](https://segment.com/) provides a large number of analytics-related functionality with a single, simple to use API. + +In this example, you will learn how to connect Auth0 to Segment and stream `signup` and `login` events. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline. + +![Segment Flow](/media/articles/monitoring/segment/segment-io-dataflow.png) + +You'll be using [Segment's Node.js library](https://github.com/segmentio/analytics-node) to record Auth0 data. + +## 1. Find your Segment Write Key + +To configure this integration, you'll need your Segment **Write Key**. You can find this under Segment's **Settings** > **API**. + +![Segment API Keys](/media/articles/monitoring/segment/segment-3.png) + +## 2. Record sign-up and log-in events in Segment + +Create a rule to record user `signup` and `login` events for your apps and send the information to Segment using Segment's Node.js library. + +In this example, we expect your Segment credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your **Write Key** here before running your rule. Doing this allows you to use your key in multiple rules and prevents you from having to store it directly in the code. + + +```js +function(user, context, callback) { + var Analytics = require('analytics-node'); + var analytics = new Analytics(configuration.WRITE_KEY, { flushAt: 1 }); + + // Note: Set { flushAt: 1 } and use analytics.flush to ensure + // the data is sent to Segment before the rule/Webtask terminates + + // Identify your user + analytics.identify({ + userId: user.user_id, + traits: { + email: user.email, + signed_up: user.created_at, + login_count: user.logins_count + }, + "context": { + "userAgent": context.request.UserAgent, + "ip": context.request.ip + } + }); + analytics.track({ + userId: user.user_id, + event: 'Logged In', + properties: { + clientName: context.clientName, + clientID: context.clientID, + connection: context.connection + }, + "context": { + "userAgent": context.request.UserAgent, + "ip": context.request.ip + } + }); + analytics.flush(function(err, batch){ + callback(null, user, context); + }); +} +``` + +## 3. Check your integration + +See if your integration works by checking the Segment Debugger to see if your Auth0 events are appearing. + +![Segment Debugger](/media/articles/monitoring/segment/segment-14.png) + + +## Keep reading + +Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples: + +* Rules for access control +* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com), [Keen](https://keen.io/) diff --git a/fr-ca/articles/monitoring/guides/send-events-to-splunk.md b/fr-ca/articles/monitoring/guides/send-events-to-splunk.md new file mode 100644 index 0000000000..a805b82ebe --- /dev/null +++ b/fr-ca/articles/monitoring/guides/send-events-to-splunk.md @@ -0,0 +1,88 @@ +--- +title: Export Logs to Splunk Using Rules +description: Learn how to send logging events to Splunk from Auth0 using rules. +topics: + - monitoring + - splunk +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - analyze-external-analytics + - integrate-analytics +--- +# Export Logs to Splunk Using Rules + +[Splunk](http://splunk.com) provides a platform that allows you to easily get insights into all the information generated by your IT infrastructure. + +In this example, you will learn how to connect Auth0 to Splunk and stream `signup` and `login` events with user contextual information. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline. + +![](/media/articles/tutorials/splunk-dataflow.png) + +## Record sign-up or log-in event in Splunk + +Create a rule that will record user `signup` and `login` events for your apps using the [Splunk REST API](http://dev.splunk.com/view/rest-api-overview/SP-CAAADP8). When enabled, this rule will send events that will then show on Splunk's dashboard: + +![](/media/articles/scenarios/splunk/splunk-dashbaord.png) + + +Please note: + +* Splunk's API supports basic & token-based auth. In this example, we use token-based auth and expect your Splunk credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your token here before running your rule. Doing this allows you to use your token in multiple rules and prevents you from having to store it directly in the code. + +* For this rule, we send contextual information, such as IP address (can be used to deduce location), application name, and username. However, you can send any number of properties. + +* For this rule, we track the event type using a property called `user.app_metadata.signedUp`. When the property is set to `true`, we assume the event is a `login`. Otherwise, we assume the event is a new `signup`, and if everything goes well, we set it to `true`. Thus, the next time the user logs in, the event will be recorded as a `login`. + + +```js +function (user, context, callback) { + const request = require('request'); + + user.app_metadata = user.app_metadata || {}; + const endpoint = 'https://http-inputs-mysplunkcloud.example.com:443/services/collector'; // replace with your Splunk HEC endpoint; + + //Add any interesting info to the event + const hec_event = { + event: { + message: user.app_metadata.signedUp ? 'Login' : 'Signup', + application: context.clientName, + clientIP: context.request.ip, + protocol: context.protocol, + userName: user.name, + userId: user.user_id + }, + source: 'auth0', + sourcetype: 'auth0_activity' + }; + + request.post({ + url: endpoint, + headers: { + 'Authorization': 'Splunk ' + configuration.SPLUNK_HEC_TOKEN + }, + strictSSL: true, // set to false if using a self-signed cert + json: hec_event + }, function(error, response, body) { + if (error) return callback(error); + if (response.statusCode !== 200) return callback(new Error('Invalid operation')); + user.app_metadata.signedUp = true; + auth0.users.updateAppMetadata(user.user_id, user.app_metadata) + .then(function () { + callback(null, user, context); + }) + .catch(function (err) { + callback(err); + }); + }); + +} +``` + +## Keep reading + +Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples: + +* Rules for access control +* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Segment](https://segment.com/), [Keen](https://keen.io/) diff --git a/fr-ca/articles/monitoring/guides/test-testall-endpoints.md b/fr-ca/articles/monitoring/guides/test-testall-endpoints.md new file mode 100644 index 0000000000..df71f9c74d --- /dev/null +++ b/fr-ca/articles/monitoring/guides/test-testall-endpoints.md @@ -0,0 +1,69 @@ +--- +title: Check Auth0 Authentication and Supporting Services +description: Learn how check the status of the Auth0 authentication service as well as supporting services such as the Dashboard and documentation using the test and testall endpoints. +public: false +topics: + - monitoring +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics + - synthetic-authentication + - synthetic-transactions +--- +# Check Auth0 Authentication and Supporting Services + +::: warning +The `/test` and `/testall` endpoints are best for determining if everything is functioning but *not* for determining if something is down. They do not provide a complete status picture. +::: + +Use the `/test` and `/testall` endpoints as a supplement to your other monitoring. You should use synthetic transactions against a test account to ensure that everything is functional. You should also track your own logs and other metrics to calls to Auth0 from servers and/or clients. + +## Test endpoint + +The `/test` endpoint checks the status of the core Auth0 authentication service. + +Here is an example of a call to the `/test` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/test" +} +``` + +If the service is up, the endpoint returns a `200` HTTP response code; if it is not, it returns a `5xx` response code. + +Additionally, this endpoint returns a JSON object: + +```json +{ + "clock": 1417220191640 +} +``` + +## Testall endpoint + +The `/testall` endpoint checks the status of the core Auth0 authentication service, as well as supporting services such as those for the [Dashboard](${manage_url}) and documentation. + +Here is an example call to the `/testall` endpoint: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/testall" +} +``` + +If all services are up, the endpoint returns the `200` HTTP response code and a simple text message of `OK`. If any service is down, it returns a `5xx` response code. + +<%= include('../_includes/_monitor-private-cloud.md') %> + +## Keep reading + +* [Check Auth0 Status](/monitoring/guides/check-status) +* [Check External Services Status](/monitoring/guides/check-external-services) +* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM) +* [Monitor Applications](/monitoring/guides/monitor-applications) diff --git a/fr-ca/articles/monitoring/guides/track-leads-salesforce.md b/fr-ca/articles/monitoring/guides/track-leads-salesforce.md new file mode 100644 index 0000000000..0c277f7219 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/track-leads-salesforce.md @@ -0,0 +1,186 @@ +--- +title: Track New Leads in Salesforce +description: Learn how to track new leads in Salesforce and augment user profiles with public information gathered from TowerData. +topics: + - monitoring + - marketing + - salesforce + - towerdata +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - analyze-external-analytics + - integrate-analytics +--- + +# Track New Leads in Salesforce + +You can track new leads in Salesforce with TowerData-Enriched User Profiles. + +Whenever a new user signs up with a website using any social credential we want to: + +1. __Augment the user profile__ with additional public information obtained through [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement). + +2. __Record the sign-up as a New Lead__ on [Salesforce](http://www.salesforce.com/), so a sales professional can follow up. + +To implement this with Auth0, you just need to create two [Rules](/rules) in your pipeline: + +![](/media/articles/tutorials/rapleaf-salesforce.png) + +## 1. Enrich User Profile with TowerData + +Create a rule that will obtain more information about the user by retrieving public information from TowerData's API using the user's email address as input. + +Once the call to TowerData completes, we store this additional information in a property called `towerdata`: + +:::note +We ignore certain conditions that exist in the API and only do this when there's a successful call (`statusCode=200`). This rule will also be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 2). +::: + +```js +function (user, context, callback) { + + //Filter by app + //if(context.clientName !== 'AN APP') return callback(null, user, context); + + var request = require('request'); + + if (!user.email || !user.email_verified) { + return callback(null, user, context); + } + + request.get('https://api.towerdata.com/v5/td', { + qs: { + email: user.email, + api_key: configuration.TOWERDATA_API_KEY + }, + json: true + }, + (err, response, body) => { + if (err) return callback(err); + + if (response.statusCode === 200) { + context.idToken['https://example.com/towerdata'] = body; + } + + return callback(null, user, context); + }); +} +``` + +## 2. Create New Lead in Salesforce + +Create a rule that will record the information as a __New Lead__ in Salesforce, so the sales department can follow up. Please note: + +* The Salesforce REST API uses an OAuth Access Token. So for this rule, we use the OAuth2 `Resource Owner Password Credential Grant` to obtain this token, and use the `getToken` function, which uses credentials as input, as opposed to an `API-KEY` as was used in the rule in the previous step. + +* In this example, we expect your Salesforce credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your credentials here before running your rule. Doing this allows you to use your credentials in multiple rules and prevents you from having to store them directly in the code. + +* For this rule, we record only the username and a fixed company name. However, we could use anything available in the enriched user profile we obtained in step 1 to record more information and provide additional context for the sales representative. + +* For this rule, we use a property called `user.app_metadata.recordedAsLead`, and if everything goes well, we set it to `true`. The next time the user signs in, this rule will be skipped. + +```js +function (user, context, callback) { + + const request = require('request'); + + user.app_metadata = user.app_metadata || {}; + if (user.app_metadata.recordedAsLead) { + return callback(null,user,context); + } + + const MY_SLACK_WEBHOOK_URL = 'YOUR SLACK WEBHOOK URL'; + const slack = require('slack-notify')(MY_SLACK_WEBHOOK_URL); + + //Populate the variables below with appropriate values + const SFCOM_CLIENT_ID = configuration.SALESFORCE_CLIENT_ID; + const SFCOM_CLIENT_SECRET = configuration.SALESFORCE_CLIENT_SECRET; + const USERNAME = configuration.SALESFORCE_USERNAME; + const PASSWORD = configuration.SALESFORCE_PASSWORD; + getAccessToken( + SFCOM_CLIENT_ID, + SFCOM_CLIENT_SECRET, + USERNAME, + PASSWORD, + (response) => { + if (!response.instance_url || !response.access_token) { + slack.alert({ + channel: '#some_channel', + text: 'Error Getting SALESFORCE Access Token', + fields: { + error: response + } + }); + + return; + } + + createLead( + response.instance_url, + response.access_token, + (err, result) => { + if (err || !result || !result.id) { + slack.alert({ + channel: '#some_channel', + text: 'Error Creating SALESFORCE Lead', + fields: { + error: err || result + } + }); + + return; + } + + user.app_metadata.recordedAsLead = true; + auth0.users.updateAppMetadata(user.user_id, user.app_metadata); + }); + }); + + //See http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_lead.htm + function createLead(url, access_token, callback){ + //Can use many more fields + const data = { + LastName: user.name, + Company: 'Web channel signups' + }; + + request.post({ + url: url + "/services/data/v20.0/sobjects/Lead", + headers: { + "Authorization": "OAuth " + access_token + }, + json: data + }, (err, response, body) => { + return callback(err, body); + }); + } + + //Obtains a SFCOM access_token with user credentials + function getAccessToken(client_id, client_secret, username, password, callback) { + request.post({ + url: 'https://login.salesforce.com/services/oauth2/token', + form: { + grant_type: 'password', + client_id: client_id, + client_secret: client_secret, + username: username, + password: password + }}, (err, respose, body) => { + return callback(JSON.parse(body)); + }); + } + + // don’t wait for the SF API call to finish, return right away (the request will continue on the sandbox)` + callback(null, user, context); +} +``` + +## Keep reading + +Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples: + +* Rules for access control +* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [Parse](http://parse.com), [Splunk](https://www.splunk.com/), [Segment](https://segment.com/), [Keen](https://keen.io/) diff --git a/fr-ca/articles/monitoring/guides/track-signups-salesforce.md b/fr-ca/articles/monitoring/guides/track-signups-salesforce.md new file mode 100644 index 0000000000..6120985e99 --- /dev/null +++ b/fr-ca/articles/monitoring/guides/track-signups-salesforce.md @@ -0,0 +1,238 @@ +--- +title: Track New Sign-Ups in Salesforce +description: Learn how to track your sign-ups in Salesforce MixPanel, enrich your user profiles with public information gathered from FullContact, and generate new sales leads. +topics: + - monitoring + - marketing +contentType: + - how-to +useCase: + - analyze-auth0-analytics + - analyze-logs + - analyze-external-analytics + - integrate-analytics +--- + +# Track New Sign-Ups in Salesforce + +You can track new sign-ups in Salesforce with FullContact-Enriched User Profiles, and Send Auth0 Events to MixPanel. + +Whenever a new user signs up with a website using a social credential, you want to: + +1. __Record a `signup` event__ in [MixPanel](https://mixpanel.com). +2. __Augment the user profile__ with additional public information through [FullContact](http://www.fullcontact.com/). +3. __Record the sign-up as a New Lead__ in [Salesforce](http://www.salesforce.com/), so a sales professional can follow up. + +To implement this with Auth0, you need to create three [Rules](/rules) in your pipeline: + +![](/media/articles/tutorials/signups.png) + +## 1. Record sign-up event in MixPanel + +Create a rule to record the event by calling MixPanel. In the example below, we record the application name in the `application` property to help you filter information in MixPanel. However, the full `context` and `user` properties are available as sources of additional information (e.g., IP addresses, agent). + +::: note +This rule will be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 3). +::: + +```js +function (user, context, callback) { + + const request = require('request'); + + const mpEvent = { + "event": "Sign up", + "properties": { + "distinct_id": user.user_id, + "token": configuration.MIXPANEL_API_TOKEN, + "application": context.clientName + } + }; + + const base64Event = Buffer.from(JSON.stringify(mpEvent)).toString('base64'); + + request.get({ + url: 'http://api.mixpanel.com/track/', + qs: { + data: base64Event + } + }, (err, res, body) => { + // don’t wait for the MixPanel API call to finish, return right away (the request will continue on the sandbox)` + callback(null, user, context); + }); +} +``` + +## 2. Enrich user profile with FullContact + +Create a rule to obtain more information about the user by retrieving public information from FullContact's API using the user's email address as input. + +Once the call to FullContact completes, we store this additional information in a property called `fullContactInfo`: + +:::note +We ignore certain conditions that exist in the API and only do this when there's a successful call (`statusCode=200`). This rule will also be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 3). +::: + +```js +function (user, context, callback) { + + const request = require('request'); + + const FULLCONTACT_KEY = configuration.FULLCONTACT_KEY; + const SLACK_HOOK = configuration.SLACK_HOOK_URL; + + const slack = require('slack-notify')(SLACK_HOOK); + + // skip if no email + if (!user.email) return callback(null, user, context); + + // skip if fullcontact metadata is already there + if (user.user_metadata && user.user_metadata.fullcontact) return callback(null, user, context); + + request.get('https://api.fullcontact.com/v2/person.json', { + qs: { + email: user.email, + apiKey: FULLCONTACT_KEY + }, + json: true + }, (error, response, body) => { + if (error || (response && response.statusCode !== 200)) { + + slack.alert({ + channel: '#slack_channel', + text: 'Fullcontact API Error', + fields: { + error: error ? error.toString() : (response ? response.statusCode + ' ' + body : '') + } + }); + + // swallow fullcontact api errors and just continue login + return callback(null, user, context); + } + + // if we reach here, it means fullcontact returned info and we'll add it to the metadata + user.user_metadata = user.user_metadata || {}; + user.user_metadata.fullcontact = body; + + auth0.users.updateUserMetadata(user.user_id, user.user_metadata); + context.idToken['https://example.com/fullcontact'] = user.user_metadata.fullcontact; + return callback(null, user, context); + }); +} +``` + +## 3. Create New Lead in Salesforce + +Create a rule to record the information as a New Lead in Salesforce, so the sales department can follow up. Please note: + +* The Salesforce REST API uses an OAuth Access Token. So for this rule, we use the OAuth2 `Resource Owner Password Credential Grant` to obtain this token, and use the `getToken` function, which uses credentials as input, as opposed to an `API-KEY` as was used in the rules in the previous steps. + +* In this example, we expect your Salesforce credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your credentials here before running your rule. Doing this allows you to use your credentials in multiple rules and prevents you from having to store them directly in the code. + +* For this rule, we record only the username and a fixed company name. However, we could use anything available in the enriched user profile we obtained in step 2 to record more information and provide additional context for the sales representative. + +* For this rule, we use a property called `user.app_metadata.recordedAsLead`, and if everything goes well, set it to true. The next time the user signs in, all of these rules will be skipped. + + +```js +function (user, context, callback) { + + const request = require('request'); + + user.app_metadata = user.app_metadata || {}; + if (user.app_metadata.recordedAsLead) { + return callback(null,user,context); + } + + const MY_SLACK_WEBHOOK_URL = 'YOUR SLACK WEBHOOK URL'; + const slack = require('slack-notify')(MY_SLACK_WEBHOOK_URL); + + //Populate the variables below with appropriate values + const SFCOM_CLIENT_ID = configuration.SALESFORCE_CLIENT_ID; + const SFCOM_CLIENT_SECRET = configuration.SALESFORCE_CLIENT_SECRET; + const USERNAME = configuration.SALESFORCE_USERNAME; + const PASSWORD = configuration.SALESFORCE_PASSWORD; + getAccessToken( + SFCOM_CLIENT_ID, + SFCOM_CLIENT_SECRET, + USERNAME, + PASSWORD, + (response) => { + if (!response.instance_url || !response.access_token) { + slack.alert({ + channel: '#some_channel', + text: 'Error Getting SALESFORCE Access Token', + fields: { + error: response + } + }); + + return; + } + + createLead( + response.instance_url, + response.access_token, + (err, result) => { + if (err || !result || !result.id) { + slack.alert({ + channel: '#some_channel', + text: 'Error Creating SALESFORCE Lead', + fields: { + error: err || result + } + }); + + return; + } + + user.app_metadata.recordedAsLead = true; + auth0.users.updateAppMetadata(user.user_id, user.app_metadata); + }); + }); + + //See http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_lead.htm + function createLead(url, access_token, callback){ + //Can use many more fields + const data = { + LastName: user.name, + Company: 'Web channel signups' + }; + + request.post({ + url: url + "/services/data/v20.0/sobjects/Lead", + headers: { + "Authorization": "OAuth " + access_token + }, + json: data + }, (err, response, body) => { + return callback(err, body); + }); + } + + //Obtains a SFCOM access_token with user credentials + function getAccessToken(client_id, client_secret, username, password, callback) { + request.post({ + url: 'https://login.salesforce.com/services/oauth2/token', + form: { + grant_type: 'password', + client_id: client_id, + client_secret: client_secret, + username: username, + password: password + }}, (err, respose, body) => { + return callback(JSON.parse(body)); + }); + } + + // don’t wait for the SF API call to finish, return right away (the request will continue on the sandbox)` + callback(null, user, context); +} +``` + +## Keep reading + +Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples: + +* Rules for access control +* Integration with other services: [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com/), [Segment](https://segment.com/), [Keen](https://keen.io/) diff --git a/fr-ca/articles/monitoring/index.md b/fr-ca/articles/monitoring/index.md new file mode 100644 index 0000000000..7fd1ac6b73 --- /dev/null +++ b/fr-ca/articles/monitoring/index.md @@ -0,0 +1,46 @@ +--- +title: Monitor Auth0 Implementations +description: Understand how to monitor your Auth0 implementation and track your Auth0 usage, as well as how to send events and logs to external tools. +topics: + - monitoring +contentType: + - concept + - index +useCase: + - analyze-auth0-analytics + - analyze-logs + - integrate-analytics +--- +# Monitor Auth0 Implementations + +You can monitor your Auth0 implementation and Auth0 status and services, as well as send logging event data to third-party tools. + +<%= include('./_includes/_monitor-private-cloud.md') %> + +## Check availability and status + +* [Check Auth0 Status](/monitoring/guides/check-status) +* [Check External Services Status](/monitoring/guides/check-external-services) +* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM) +* [Monitor Applications](/monitoring/guides/monitor-applications) + +## Log events + +Need to analyze logs or store them long-term? Auth0 provides extensions to [export logs to external tools](/logs) for analysis and retention. You can also retrieve log data with the Management API. Auth0 only retains logs for a limited period of time, governed by the type of subscription purchased. If your required data retention period is longer than the retention period for your subscription,export logs so you can keep them as long as you wish. + +* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs) +* [Log Data Retention](/logs/references/log-data-retention) +* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard) +* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api) +* [Log Event Type Codes](/logs/references/log-event-type-codes) +* [Log Search Query Syntax](/logs/references/query-syntax) +* [Send Logging Events to Keen](/monitoring/guides/send-events-to-keenio) +* [Send Logging Events to Segment](/monitoring/guides/send-events-to-segmentio) +* [Send Logging Events to Splunk](/monitoring/guides/send-events-to-splunk) +* [Send Logging Events to Loggly](/extensions/loggly) +* [Send Logging Events to Mixpanel](/extensions/mixpanel) + +## Track new signups and leads + +* [Track New Sign-Ups in Salesforce](/monitoring/guides/track-signups-salesforce) +* [Track New Leads in Salesforce](/monitoring/guides/track-leads-salesforce) diff --git a/fr-ca/articles/onboarding/appliance-sprint.md b/fr-ca/articles/onboarding/appliance-sprint.md new file mode 100644 index 0000000000..1beb874949 --- /dev/null +++ b/fr-ca/articles/onboarding/appliance-sprint.md @@ -0,0 +1,58 @@ +--- +sitemap: false +section: appliance +description: PSaaS Appliance Sprint is Auth0’s onboarding program for enterprise customers choosing an PSaaS Appliance. It helps you achieve value quickly with your Auth0 enterprise subscription. +topics: + - appliance + - onboarding +contentType: + - concept +useCase: + - appliance +applianceId: appliance64 +--- +# PSaaS Appliance Deployment Project + +PSaaS Appliance Sprint is Auth0’s onboarding program for enterprise customers choosing an PSaaS Appliance. It helps you achieve value quickly with your Auth0 enterprise subscription. + +Sprint is Auth0’s onboarding program for enterprise customers. For customers subscribed to an Auth0 private instance to be deployed on-premises or in the customers cloud provider of choice, the first part of the Sprint program will be the PSaaS Appliance deployment project. Here's an overview of the main steps: + +## PSaaS Appliance Deployment Project Overview + +The following sections describe what happens during each step of the PSaaS Appliance deployment process. + +### Step 1 - Project Kickoff + +**When?** This session is generally booked within 5 days of signing your subscription agreement. + +**What?** Deploying the PSaaS Appliance on your cloud or on-premises infrastructure is a team effort. This is where we run through how we’re going to get it done! An Auth0 project manager will work with your designated project manager to build the project plan in this session. + +[PSaaS Appliance Docs](/appliance) - Get up to speed on all things PSaaS Appliance in this high level overview doc. + +### Step 2 - Infrastructure Ready + +**When?** Varies by customer and complexity of their deployment. Ideally 1-3 weeks after signing the subscription agreement. + +**What?** Your team prepares the relevant infrastructure based on our guidance. + +[PSaaS Appliance Infrastructure Requirements Docs](/appliance/infrastructure) + +### Step 3 - PSaaS Appliance Setup + +**When?** Varies by customer and complexity of their deployment. Ideally 2-4 weeks after signing the subscription agreement. + +**What?** Our team configures the PSaaS Appliance on your infrastructure. + +### Step 4 - PSaaS Appliance Handover + +**When?** 30-45 days after signing your subscription agreement. + +**What?** An operational handover session with your team to learn how to administer the PSaaS Appliance. + +[PSaaS Appliance Configuration](/appliance/dashboard) - See our Docs on the configuration settings within the Appliance. + +[PSaaS Appliance Administrator's Manual](/appliance/admin) + +## What's next? + +Once the PSaaS Appliance is deployed, an Auth0 Technical Account Manager will work with you to build a joint success plan to drive value throughout the subscription lifecycle. \ No newline at end of file diff --git a/fr-ca/articles/onboarding/enterprise-support.md b/fr-ca/articles/onboarding/enterprise-support.md new file mode 100644 index 0000000000..1a2979c5fe --- /dev/null +++ b/fr-ca/articles/onboarding/enterprise-support.md @@ -0,0 +1,123 @@ +--- +toc: true +section: appliance +description: Outlines the Auth0 enterprise support options, definitions, coverage offered and procedures to follow for the best support experience. +topics: + - appliance + - onboarding +contentType: + - concept +useCase: + - appliance +applianceId: appliance66 +--- +# Enterprise Support Guidance + +This document outlines the Auth0 enterprise support options, definitions, coverage offered, and procedures to follow for the best support experience. It is relevant for customers only with Enterprise Plan subscription agreements, which differ from the standard pay-as-you-go/self-service subscription offerings acquired directly from our website. + +Refer to your subscription agreement to confirm which support offering is included in your subscription. + +## For General Queries + +For general queries related to functionality, integration, best practice, or advice, you can use the following resources: + +- The [Auth0 Community](https://community.auth0.com/): Post questions to our audience of Customer Success Engineers, as well as other Auth0 users, or search and read existing posts for useful information. +- Your __Technical Account Manager__: Your Auth0 Technical Account Manager is always available for general queries and helping you navigate to the right Auth0 resource. The orientation information you received during onboarding should have the contact details for your Technical Account Manager. +- The [Auth0 Docs](/search#gsc.tab=0) + +## For Issues Impacting Production Environments (SLA Applicable) + +::: note + +Critical Production issues should always be reported via the [Support Center](${env.DOMAIN_URL_SUPPORT}) for fastest response. + +[Learn more about creating tickets with Support Center](/support/tickets) +::: + + +For the purposes of the following descriptions, the following capitalized words and phrases are ascribed the following meanings: + +**“Defect”** means a failure of the Auth0 Platform, in the form provided or modified by Auth0, to conform to its applicable specifications set forth in the Documentation. A Defect includes a failure of one or more components of the environment or infrastructure provided by Auth0 or AWS to perform in accordance with their applicable documentation or specifications. + +**“Demand Services”** has the meaning ascribed to it in Section 7 below. + +**“Fix”** means a modification or an addition to the Auth0 Platform that overcomes a Defect when made or added to the Auth0 Platform. Auth0 may provide a Workaround in lieu of a Fix in Auth0’s sole discretion, but will provide a Fix to you as specified in Section 3.2 below. + +**“Response Time”** means, for purposes of this Support Program description, the time between Auth0’s receipt of a Defect notification from you, and Auth0’s confirmation via one of its personnel that Auth0 is working on resolution of the Defect. (While your submission of a trouble ticket may trigger an automated response from Auth0, automated responses are disregarded for purposes of determining Response Times.) + +**“Update”** means a patch, correction, or other modification or addition to the Auth0 Platform that Auth0 makes generally available to you for maintenance fixes, Defect corrections, and minor improvements to the Auth0 Platform, including fixes, patches, updates and releases to address any security vulnerabilities. “Update” also includes significant enhancements, or new features or functionalities that Auth0 makes generally available to you. + +**“Workaround”** means a set of procedures that you may follow to circumvent or mitigate the impact of a Defect, notwithstanding that the Defect still exists. + +## Defect Resolution Procedures + +Auth0 will assign all Defects one of four response priorities, dependent upon the problems caused by the Defect. Auth0 may re-assign prioritization levels assigned by you in Auth0’s trouble ticketing system, to reflect the problem descriptions below. Auth0’s assignment will be consistent with the problem descriptions described below. Priority categories are as follows: + +| Severity Level | Description | +| - | - | +| 1 (Urgent) | **Emergency Issue**. Defect resulting in full or partial system outage or a condition that makes the Auth0 Platform unusable or unavailable in production for all of your Users. | +| 2 (High) | **Significant Business Impact**. Defect resulting in a condition where major functionality is impacted or significant performance degradation is experienced; issue is persistent and affects many Users and/or major functionality. | +| 3 (Normal) | **Minor Feature / Function Issue / General Question**. Defect results in a component of the Auth0 Platform not performing as expected or documented **or** an inquiry by your representatives regarding general technical issues/questions | +| 4 (Low) | **Minor Problem / Enhancement Request**. Information requested on Auth0 Platform capabilities, navigation, installation, or configuration; enhancement request. | + +## Guidance for Logging Support Issues + +To ensure that your support issue is assigned the correct priority and SLA, it must be logged via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}). Other methods may not track your issue correctly. + +## What to Expect + +After you've correctly logged your issue: + +1. Your issue will be acknowledged immediately to confirm that it was submitted successfully. You'll be assigned and receive a ticket ID number. +2. Auth0 support staff may direct you to join a private Slack channel and/or a Zoom web conference to facilitate faster communications. Please remember that you should not initiate support requests via Slack -- you should only use the [Support Center](${env.DOMAIN_URL_SUPPORT}). +3. Be sure to send any critical information, such as log files, issue-related descriptions, and so on, to the [Support Center](${env.DOMAIN_URL_SUPPORT}) so that they can be attached to the ticket you opened. + +Upon resolution of the issue, an Auth0 support staff member will ask you for confirmation the issue has been resolved to you satisfaction. The ticket will be closed only when you have responded and confirmed issue is resolved. + +## What to Check Before Logging an Issue + +To speed resolution, please check the following before logging an issue: + +* Is the issue experienced by all users or just a few? + * All? - Could be a service or configuration issue + * Check status of Auth0 service + * Americas: (https://status.auth0.com) + * EU Region: (https://status.auth0.com/?region=EU) + * APAC Region: (https://status.auth0.com/?region=AU) + * You can subscribe to updates via the button on those pages + * Check authentication services (connections) are up and reachable + * Check application components - make sure they are functioning + * Check certificates - make sure valid/not expired (cert-related errors) + * Check NTP running on Auth0 AD/LDAP connector, IDPs + * Check if any Rules have changed recently + * Check if any recent changes on IDPs that could cause error + * Can users log into other apps that use the same authentication provider? + * Few users impacted - usually a user profile or browser/device issue + * Have user clear cookies and try again + * Make sure user isn’t hitting the ‘back’ button + * Make sure user has cookies and javascript turned on in browser + * Check user profile in the authentication service + * Check if any rules changed recently that impact user profile + * Is user device in violation of MDM device policies (if used) + * Does it happen consistently and can be repeated? + +## Information to Provide When Logging an Issue + +To speed resolution, please provide the following when logging an issue: + +* Name of Auth0 account/tenant +* Name of application(s) +* Name of connection(s) +* Description of the problem - what happens?  How far into login sequence does user get? (for example, does issue happen before or after entering credentials, and so on) +* When did it start?  (first noticed) +* Issue experienced by all users or just some? +* Issue experienced by users every time or just some times? +* Issue experienced with all browsers or just one? +* Screenshot of error message (if any) +* HTTP trace in the form of a [HAR file](/troubleshoot/guides/generate-har-files) + +*For Private Cloud Customers*: + +* Private Cloud version/build number (top left hand corner of configuration screen on config tenant, such as https://yourmanage.yourdomain.com/configuration#/) +* Status of nodes (https://yourmanage.yourdomain.com/configuration#/nodes) +* Status of health check (https://yourmanage.yourdomain.com/configuration#/troubleshoot) \ No newline at end of file diff --git a/fr-ca/articles/policies/billing.md b/fr-ca/articles/policies/billing.md new file mode 100644 index 0000000000..2de85a2518 --- /dev/null +++ b/fr-ca/articles/policies/billing.md @@ -0,0 +1,120 @@ +--- +description: Describes the Billing policy which governs requests for billing mechanisms within the Auth0 dashboard +crews: crew-2 +topics: + - auth0-policies + - billing +contentType: + - reference +useCase: + - support +--- + +# Billing Policy + +The following policy governs requests for billing mechanisms within the Auth0 dashboard. + +## Change of billing email address + +It is possible to change the billing email address, but for security reasons the request should be performed by a Tenant Administrator by filing a new ticket through our [Support Center](${env.DOMAIN_URL_SUPPORT}). A member of our support team will then contact you in that same ticket with steps on how the request will proceed. +Please note that if you are not a Tenant Administrator, we will not process this request. + +### Special case + +Please note that the customers who created tenants via the Heroku hosting platform have to change the billing email address (or any other billing details) in those platforms. We cannot edit any billing information if you have used one of those services. + +## Why is my credit card failing? + +The only way to determine the reason for the failure is for the customer to contact their credit card company by calling the number on the back. This can be triggered by a credit card reaching the limit or simply being rejected by the bank, for example. + +### My credit card is failing and some features are not available anymore + +If your credit card fails to be charged, we automatically retry to charge it up to 4 times. If you fix the issue before the fourth failure (by entering new card information or by solving the issue with the bank), then the charge will go through and everything will work as expected. + +However, if the problem is not fixed prior to the fourth failure, all past due invoices will be manually initiated by Auth0. This means that you may be charged on an unexpected date. + +::: note +If you are having issues with the service, it is not due to the credit card failing. +::: + +## How can I cancel my subscription? + +Please proceed by downgrading your subscription to free or by cancelling your subscription via the Auth0 Dashboard. + +1. Login to the [Dashboard](${manage_url}). +2. Click on your tenant name in the top right corner to bring up the associated dropdown box. +3. Select **Settings**. +4. On the [Tenant Settings](${manage_url}/#/tenant/) page, click on the **Subscription** tab. +5. On the **Subscription** tab, scroll down to the box associated with the Free plan and click **Checkout**. +6. To confirm your subscription change, click **Subscribe Now**. + +## Refunds + +### I signed up for a paid plan but haven't used my tenant since then, can I get a refund? + +We understand that sometimes developers create tenants for demo or testing purposes. So if you have a subscription plan, but you have not been using our service in a while and you would like to get a refund, you should [downgrade](/tutorials/cancel-paid-subscriptions#downgrade-a-paid-subscription-to-a-free-subscription) your tenant to use a Free Plan. Notice that we do not provide refunds for when a plan is downgraded to another paid one that has less features. + +If you have already downgraded, please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide information about why the tenant has not been used and for how long. Please note that this request must come from a Tenant Administrator. + +We will evaluate the case and verify that the tenant has not been used in the aforementioned period in order to process the refund. Please note that if we consider the usage of the tenant not to be minimal, we reserve the right to not refund your card. + +### I purchased more tenant subscriptions than desired/needed, can I get a refund? + +If you bought unneeded subscriptions, you are eligible for a refund. + +Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator. + +### I purchased a wrong plan in self service or trial and would like to downgrade, can I get a refund? + +You can get a refund only for an unused portion of subscription of 3 months or less, when there has been no logins. + +Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator. + +### Any other scenario not mentioned above + +Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator. + +## Where can I get a copy of an invoice? + +Invoices can be seen directly in the Dashboard by going to the [Tenant Settings](${manage_url}/#/tenant/) and clicking on the **Payments** tab. There you view all your Payment History, and you can get the invoices by clicking on the corresponding month. Please note that only Tenant Administrators can see the invoices. + +## How can I get a receipt for my payment? + +The way to do this is by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +Please note that you have to be a Tenant admin to do this request. + +Also, more than often the email which receives the receipt is the one that created the Auth0 tenant. Please make sure that you are in touch with the owner of that email. That person can also forward you the receipt of the payment. If you want to change this setting, please let us know through our [Support Center](${env.DOMAIN_URL_SUPPORT}). + +## Do you charge sales tax? + +For US-based customers, we will charge sales tax where applicable. This is dependent on your state's sales tax laws and requirements. For non-US customers, we will not charge sales tax. + +You can determine if you will be responsible for sales tax during the checkout process after you provide your billing address. If the billing address provided is tax-eligible, you'll see the sales tax added to your total. You will also see the sales tax amount on all of your Auth0 invoices and receipts. + +## In our pricing, what is the difference between internal and external users? Are they different technically? + +An active user is a user that has authenticated with a username/password combination, a Passwordless connection, or any social provider in a given calendar month. + +Auth0 counts users on a per-tenant basis. That means that somebody who logs in to multiple applications still counts as one user as long as you've created all of the applications using a single tenant. + +You will find that for certain plans, you have the ability to select between being charged for external users or for internal users. There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee. + +External users are most likely not going to be using Auth0 on a daily basis, and therefore this plan uses the active users criteria to calculate the price. + +On the other hand, internal users have to login everyday to their different tools and platforms in order to get the work done, so for this case you would pay a flat rate per user. + +## Can we scale the number of users as needed each month? + +Definitely. In the Dashboard, you can do this by going to the upper right corner, and selecting **Settings** from the drop down menu. Then in the **Subscriptions** tab you can select them depending on your needs. More information about it can be found there or in our [Pricing page](https://auth0.com/pricing/). + +## Can we combine billing for multiple tenants? + +Unfortunately combined billing is not supported for regular self-service tenants. The only two cases where we support combined billing are: + +1. For enterprise customers +2. For customers whose master tenant is billed at $167 per month (or more). In this case, we mark the testing tenant as [a child tenant](https://auth0.com/docs/dev-lifecycle/child-tenants) and bill only the master tenant. + +## How can I convert my tenant from a free trial to any other version? + +You can do this by heading to the upper right corner of the Dashboard, clicking your tenant name and selecting **Settings**. Then in the **Subscriptions** tab you can select the plan that best suits your needs. More information about this can be found there or in our [Pricing page](https://auth0.com/pricing/). diff --git a/fr-ca/articles/policies/dashboard-authentication.md b/fr-ca/articles/policies/dashboard-authentication.md new file mode 100644 index 0000000000..23d1a8d253 --- /dev/null +++ b/fr-ca/articles/policies/dashboard-authentication.md @@ -0,0 +1,47 @@ +--- +description: Describes the Dashboard Authentication Policy which governs requests for special authentication mechanisms for the Auth0 dashboard. +crews: crew-2 +topics: + - auth0-policies + - dashboard +contentType: + - reference +useCase: + - support +--- + +# Dashboard Authentication Policy + +The following policy governs requests for special authentication mechanisms for the Auth0 dashboard. + +## Multi-factor Authentication + +You can enable multi-factor authentication for logging in to the dashboard with your account. + +To enable multi-factor authentication for your account: + +1. Go to your [Account Profile page](${manage_url}/#/profile) +2. Scroll down to the **Multi-factor** section. +3. Click the **Enroll Your Device Now** link to get started. + +The process for setting up each form of authentication is the same as using MFA with an application, [click here for more information on each type of authentication.](/mfa) + +### Unenrolling a Device from Multi-factor + +To stop using multi-factor authentication to log in to your dashboard: + +1. Go to your [Account Profile page](${manage_url}/#/profile) +2. Scroll down to the **Multi-factor** section and click the **REMOVE** button next to the enrolled device. +3. To verify this request you will need to login once more with multi-factor authentication. + +## Other forms of authentication + +At this time, other forms of authentication for dashboard authentication are not supported. + +## Effectivity + +This policy is effective April 4, 2016 + +This policy may be revised when we are able to make configuration and troubleshooting visibility available on a self-service basis for other forms of authentication. + +Any accounts with special dashboard authentication implemented before the effective date of this policy shall be allowed to continue. diff --git a/fr-ca/articles/policies/data-export.md b/fr-ca/articles/policies/data-export.md new file mode 100644 index 0000000000..e4442cef34 --- /dev/null +++ b/fr-ca/articles/policies/data-export.md @@ -0,0 +1,26 @@ +--- +description: Auth0 policies on exporting data. +topics: + - auth0-policies + - data + - data-exports +contentType: + - reference +useCase: + - support +--- +# Data Export Policy + +If you would like to export your data from Auth0 there are a several ways you can do this. Please note these tools do not export password hashes of your [Auth0-hosted database users](/connections/database). You can still request this information by opening a [support ticket](https://support.auth0.com/). Please note that in order to make this request you must be signed in to the Developer plan for one month. + +## Use the Import/Export Extension + +You can use our [Import/Export Extension](/extensions/user-import-export) to export nearly all data in your Auth0 tenant. + +## Use the Management API + +If you want to export certain sets of data programmatically, the **Management API** can assist you with this. For more information on using the Management API, you can: + +* Browse the [Management API documentation](/api/management/v2). +* Read about [obtaining a token](/api/management/v2/tokens) which you can use to call the Management API. +* Read about [searching for users](/users/search) as well as the [query syntax](/users/search/v3/query-syntax) that can be used. diff --git a/fr-ca/articles/policies/data-transfer.md b/fr-ca/articles/policies/data-transfer.md new file mode 100644 index 0000000000..e3cd3206a9 --- /dev/null +++ b/fr-ca/articles/policies/data-transfer.md @@ -0,0 +1,27 @@ +--- +description: Describes the Data Transfer Policy which governs requests for transfer of data from one Auth0 tenant to another. +topics: + - auth0-policies + - data + - data-transfer +contentType: + - reference +useCase: + - support +--- + +# Data Transfer Policy + +At this time, Auth0 will not transfer data from one Auth0 tenant to another. This applies to both Public Cloud and Private Cloud customers. + +All data in your Auth0 tenant is always under your control and is [available through the Management API](/api/v2) at any time. The only information which is not available through the API are the password hashes of your [Auth0-hosted database users](/connections/database) and private keys, for security reasons. + +If you are opting to move out from our service, then you might want to check [this section](/moving-out). Please notice that in order to make this request you must be signed in to the Developer plan for one month. + +## Frequently made requests that are not supported + +* Transfer data from a non-production tenant to a production tenant +* Rename a tenant +* Re-use the name of a previously deleted tenant +* Rename a connection +* Migrate a tenant from one region to another (for example, from US to EU) diff --git a/fr-ca/articles/policies/endpoints.md b/fr-ca/articles/policies/endpoints.md new file mode 100644 index 0000000000..0ad9cc03ba --- /dev/null +++ b/fr-ca/articles/policies/endpoints.md @@ -0,0 +1,32 @@ +--- +description: Lists all the endpoints used by Auth0 public cloud service. +topics: + - auth0-policies + - endpoints +contentType: + - reference +useCase: + - support +--- + +# Auth0 Public Cloud Service Endpoints + +The following endpoints are used by Auth0 public cloud service: + +## United States Region + +* https://manage.auth0.com +* https://auth0.com +* https://login.us.auth0.com +* https://cdn.us.auth0.com (or https://cdn.auth0.com if your tenant was created prior to 11 June 2020) +* https://{YOUR ACCOUNT}.us.auth0.com +* https://{YOUR ACCOUNT}.guardian.us.auth0.com + +## Europe and Australia Regions + +* https://manage.auth0.com +* https://auth0.com +* https://login.[eu|au].auth0.com +* https://cdn.[eu|au].auth0.com +* https://{YOUR ACCOUNT}.[eu|au].auth0.com +* https://{YOUR ACCOUNT}.guardian.[eu|au].auth0.com diff --git a/fr-ca/articles/policies/entity-limits.md b/fr-ca/articles/policies/entity-limits.md new file mode 100644 index 0000000000..24f00d44c1 --- /dev/null +++ b/fr-ca/articles/policies/entity-limits.md @@ -0,0 +1,52 @@ +--- +title: Entity Limit Policy +description: Describes Auth0's tenant entity limit policy for subscribers. +topics: + - auth0-policies + - rate-limits + - entity-limits +contentType: + - reference +useCase: + - support +--- +# Entity Limit Policy + +::: note +This policy is effective for all Developer, Developer Pro, and free subscriptions made on or after May 19, 2020. Starting on **June 18, 2020**, the policy will apply to all Developer, Developer Pro, and free subscriptions. +::: + +Entities in Auth0 are tenant configuration elements such as applications, connections, rules, and API resource servers. + +Auth0 limits the number of entities you can have depending on your subscription level. Auth0 provides notifications to you when you are approaching (80%) and when you have reached your respective entity limits (100% or higher). We will also provide messages to prevent you from attempting to configure entities that would be rejected because they would put you over your limit. Here is an example of a message you would see if you reached your connection limit: + +![Entity Limit Reached](/media/articles/policies/entity-limit-reached.png) + +::: note +Entity counts may take a few seconds to update. If you see a warning that you believe is in error, try again after a few seconds or contact support if the issue persists. +::: + +## Developer and Developer Pro subscription limits + +| Entity | Maximum | +| - | - | +| Applications | 100 | +| Connections | 100 | +| Rules | 100 | +| API Resource Servers | 100 | + +## Free subscription limits + +| Entity | Maximum | +| - | - | +| Applications | 10 | +| Connections | 10 | +| Rules | 10 | +| API Resource Servers | 10 | + +## Keep reading + +* [Rate Limit Policy](/policies/rate-limits) +* [Management API Endpoint Rate Limits](/policies/rate-limits-mgmt-api) +* [Authentication API Endpoint Rate Limits](/policies/rate-limits-auth-api) +* [Legacy Rate Limits](/policies/legacy-rate-limits) diff --git a/fr-ca/articles/policies/index.md b/fr-ca/articles/policies/index.md new file mode 100644 index 0000000000..f404b79512 --- /dev/null +++ b/fr-ca/articles/policies/index.md @@ -0,0 +1,26 @@ +--- +url: /policies +description: List of all of Auth0's established operational policies. +topics: + - auth0-policies +contentType: + - index +useCase: + - support +--- +# Operational Policies + +Auth0 has established the following operational policies. + +- [Billing](/policies/billing) +- [Dashboard Authentication](/policies/dashboard-authentication) +- [Data Export](policies/data-export) +- [Data Transfer](/policies/data-transfer) +- [Endpoints](/policies/endpoints) +- [Load Testing](/policies/load-testing) +- [Penetration Testing](/policies/penetration-testing) +- [Migrations](/migrations) +- [Rate Limits](/policies/rate-limits) +- [Entity Limits](/policies/entity-limits) +- [Tenant Restoration](/policies/restore-deleted-tenant) +- [Unsupported Requests](/policies/unsupported-requests) \ No newline at end of file diff --git a/fr-ca/articles/policies/legacy-rate-limits.md b/fr-ca/articles/policies/legacy-rate-limits.md new file mode 100644 index 0000000000..a1ddda609d --- /dev/null +++ b/fr-ca/articles/policies/legacy-rate-limits.md @@ -0,0 +1,173 @@ +--- +description: Describes Auth0's rate limit policy for subscriptions created before 05-21-2020 when working with Auth0 API endpoints. +topics: + - auth0-policies + - rate-limits +contentType: + - reference +useCase: + - support +--- +# Management API Endpoint Rate Limits before May 19, 2020 + +**This policy is effective for all paid and free subscriptions made before May 19, 2020.** + +::: warning +All subscriptions made on or after **May 19, 2020** are subject to the [updated rate limits](/policies/rate-limits-mgmt-api). +Starting on **June 18, 2020**, the new limits will apply to all tenants. You will be notified of the new limits through a **Dashboard Notification**. If the changes will impact your tenant, you will be notified directly via email with additional information about minimizing API calls and upgrading plans. +::: + +The rate limits for Auth0 Management API differ depending on whether your tenant is free or paid, production or not. + +| Tenant Type | Limit | +| - | - | +| Free or Trial | 2 requests per second (and bursts up to 10 requests) | +| Non-Production (Paid) | 2 requests per second (and bursts up to 10 requests) | +| Production (Paid) | 15 requests per second (and bursts up to 50 requests) | + +The aforementioned rate limits include calls made via [Rules](/rules) and are set **by tenant** and not by endpoint. + +The following Auth0 Management API endpoints return rate limit-related headers. For additional information about these endpoints, please consult the [Management API explorer](/api/management/v2). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EndpointGETPOSTDELETEPATCHPUT
Application Grants/client-grants/client-grants/client-grants/{id}/client-grants/{id}
Signing Keys/keys/signing
/keys/signing/{id}		/keys/signing/rotate
Limited to 5 requests per day		/keys/signing/{kid}/revoke
Applications/client
/client/{id}		/client/client/{id}/client/{id}
Connections/connections
/connections/{id}		/connections/connections/{id}
/connections/{id}/users		/connections/{id}
Device Credentials/device-credentials/device-credentials/device-credentials/{id}
Logs/logs
/log/{id}
Rules/rules
/rules/{id}		/rules/rules/{id}/rules/{id}
User Blocks/user-blocks
/user-blocks/{id}		/user-blocks
/user-blocks/{id}
Users/users
/users/{id}
/users/{id}/logs
/users/{id}/enrollments		/users
/users/{id}/identities		/users/{id}
/users/{id}/identities
/users/{id}/multifactor/{provider}		/users/{id}
Emails/emails/provider/emails/provider/emails/provider
Jobs/jobs/{id}
/jobs/{id}/errors		/jobs/verification-email
/jobs/users-imports
/jobs/users-exports
Resource Servers/resource-servers
/resource-servers/{id}		/resource-servers/resource-servers/{id}/resource-servers/{id}
Stats/stats/active-users
/stats/daily
Tenants/tenants/settings/tenants/settings
+ +#### Concurrent import users jobs + +The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of two concurrent import jobs. Requesting additional jobs while there are two pending returns a `429 Too Many Requests` response: + +```json +{ + "statusCode": 429, + "error": "Too Many Requests", + "message": "There are 2 active import users jobs, please wait until some of them are finished and try again +} +``` + +#### Access tokens for SPAs + +If you obtain Access Tokens for your SPAs, note that there are rate limits that are applicable when working with the available `current_user`-related [scopes and endpoints](/api/management/v2/get-access-tokens-for-spas#available-scopes-and-endpoints). You are allowed a maximum of **10 requests per minute per user**. diff --git a/fr-ca/articles/policies/load-testing.md b/fr-ca/articles/policies/load-testing.md new file mode 100644 index 0000000000..fe8a00fbdb --- /dev/null +++ b/fr-ca/articles/policies/load-testing.md @@ -0,0 +1,71 @@ +--- +description: This page details Auth0's Load Testing Policy. +topics: + - auth0-policies + - load-testing + - testing +contentType: + - reference +useCase: + - support +--- +# Load Testing Policy + +Auth0 recognizes that customers may occasionally need to perform load tests against its production cloud service. In order to ensure a successful test and maintain a high quality of service for all customers, Auth0 has established the following guidelines. Any load testing in Auth0 must be conducted in accordance with this Policy. + +Only customers who have purchased an Enterprise subscription may conduct load testing. Free, Developer, Developer Pro and other non-Enterprise customers may not conduct load testing. Customers with an Enterprise subscription may request one load test (with up to 2 repeats) per year against an Auth0 production tenant. Performance and load testing is only allowed with Auth0's prior written approval. Once approved, testing can only target tenants that we have approved. + +::: note +Auth0 reserves the right to reject the load test request or ask for modifications. Failure to abide by this policy may result in temporary blocking of access to a tenant until the issue is remediated. +::: + +## How to request + +Customers must file a load testing request via the Auth0 Support Center. Under the Issue typefield, select Public Cloud Support Incident. + +To be considered for approval, the request must: + +* Be filed at least two (2) weeks prior to the desired test date; in many cases, Auth0 encourages one (1) month of advance notice to ensure time for a thorough review and any required modifications. +* Be approved in writing before any testing is conducted. +* Stay within our [published production rate limits](/policies/rate-limits). +* Include all information described below. + +## Information to include in requests + +The load testing request must include the following: + +* A description of the test to be done +* The name and region of the Auth0 tenant to be used during the test +* The requested date and time of the test, including time zone +* The requested duration of the test (2 hour maximum) +* The platforms to be used for the test (desktop/laptop, iOS, Android, other) +* The Auth0 features (such as rules or email) used during the test +* The Auth0 API methods and endpoints to be used (for example `GET /api/v2/clients`) +* The maximum requests per second for each type of request or endpoint +* The types of Auth0 connections involved in the test +* Which Auth0 Rules, if any, will execute during the test +* Which Custom DB, if any, will be used +* Which Auth0 Webtasks, if any, will be used +* Whether verification, welcome or other emails will be sent +* The peak load, specified in requests-per-second, expected for each API endpoint or Auth0 feature involved in the test +* An explanation/justification for the peak load numbers, including the size of the target user population and realistic estimates of logins per hour +* The ramp-up rate for the test +* Contacts who will be available during the test and how to reach them +* Number of unique users participating in the load test + +## Email considerations + +Before any testing, customers must: + +* Configure their own email provider in Auth0 +* Receive approval from their email provider to send the expected volume of email +* Make arrangements for bounced emails +* Establish a mechanism for testing that emails arrived + +## Test requirements + +Load testing windows are subject to availability so advance notice is highly recommended. Once approved, load testing windows will have a scheduled start and end time not to exceed two (2) hours in duration. All testing must begin and end during this window. + +Auth0 strongly recommends including a brief "ramp up" period to the desired load test target numbers. For example, a load test request of 100 RPS might be preceded by three five minute periods: 5 minutes at 25 RPS, 5 minutes at 50 RPS, and 5 minutes at 75 RPS. This ramp up period allows Auth0 and the customer to observe and compare effects at increasing RPS levels prior to peak RPS. If a ramp up period is not possible, please indicate why. + +_Updated February 4, 2019_ diff --git a/fr-ca/articles/policies/penetration-testing.md b/fr-ca/articles/policies/penetration-testing.md new file mode 100644 index 0000000000..850efd2fc0 --- /dev/null +++ b/fr-ca/articles/policies/penetration-testing.md @@ -0,0 +1,48 @@ +--- +description: This page details Auth0's Penetration Testing Policy. +topics: + - auth0-policies + - penetration-testing + - testing +contentType: + - reference +useCase: + - support +--- +# Penetration Testing Policy + +**This policy is effective July 1, 2019.** + +If you have a *paid* Auth0 subscription, you may conduct a security test of your application involving Auth0 infrastructure (e.g. `your-tenant.auth0.com`) with **prior approval**. + +To conduct a security test, please notify us in advance via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}). Auth0 requires at least **1 week's (7 days')** notice prior to your test's planned start date. + +If the test is isolated to your infrastructure (that is, there will be no testing of Auth0 services), you do not need to notify Auth0. + +## Information required + +Please provide the following information in the support ticket when requesting approval for testing: + +1. The specific dates/times of the test and timezone +2. The high level scope of the test +3. IP address(es) the scan will come from +4. The Auth0 tenant(s) involved +5. Two (2) contacts who will be available during the entire test period in case we need to contact you. If we have any questions, we will make a reasonable attempt to contact you. If you cannot be reached, we reserve the right to take measures to protect the service, which may include shutting down or blocking your tenant and/or the source of the intrusion traffic. + +## Requirements + +Auth0 requires that: + +* The test be restricted to only your tenant +* You disclose any suspected findings to the Auth0 Security team for explanation/discussion +* You understand that your tenant will be moved between environments during testing. Auth0 will move your tenant from the Production environment to the Preview environment before the testing commences. Auth0 will then return your tenant to the Production environment once the testing period ends. Note that while your tenant is on the Preview environment it may receive updates more rapidly. + +## Private Cloud customers + +Private Cloud customers should also request permission to run a penetration test via the [Auth0 support center](${env.DOMAIN_URL_SUPPORT}). Please include the [information listed above](/policies/penetration-testing#information-required) with your support request. + +## Restrictions + +* You may not conduct any [load testing](/policies/load-testing) (such as Denial of Service testing) per the load testing policy. +* You may not conduct any penetration testing targeting our management dashboard. Management and Authentication APIs are allowed. +* You may not conduct any penetration testing targeting tenants that we have not approved. diff --git a/fr-ca/articles/policies/rate-limits-auth-api.md b/fr-ca/articles/policies/rate-limits-auth-api.md new file mode 100644 index 0000000000..546658f45a --- /dev/null +++ b/fr-ca/articles/policies/rate-limits-auth-api.md @@ -0,0 +1,297 @@ +--- +title: Authentication API Endpoint Rate Limits +description: Describes Auth0's rate limit policy when working with Auth0 Authentication API endpoints. +toc: true +topics: + - auth0-policies + - rate-limits +contentType: + - reference +useCase: + - support +--- +# Authentication API Endpoint Rate Limits + +Each Authentication API endpoint is configured with a bucket that defines: + +- Request limit +- Rate limit window (per second, per minute, per day, etc.) + +```text +bucket: + size: x + per_minute: y +``` + +For example, the above states that, for the given bucket, there is a maximum request limit of `x` per minute, and for each minute that elapses, permissions for `y` requests are added back. In other words, for each `60 / y` seconds, one additional request is added to the bucket. This occurs automatically until the bucket contains the maximum permitted number of requests. + +For some API endpoints, the rate limits are defined per bucket, so the origins of the call do not influence the rate limit changes. For other buckets, the rate limits are defined using different keys, so the originating IP address is considered when counting the number of received API calls. + +::: note +If you are using an API endpoint **not** listed below and you receive rate limit headers as part of your response, see [Anomaly Detection](/anomaly-detection) for more information. +::: + +## Limits for production tenants of paying customers + +| Endpoint | Path | Limited By | Rate Limit | +| - | - | - | - | +| All Endpoints | [All Authentication API endpoints](/api/authentication) | Sum of all combined requests to any Authentication API endpoint | 100 requests per second | +| User Profile | `/tokeninfo` (Legacy) | IP Address | 800 requests per minute | +| | `/userinfo` | User ID | 5 requests per minute with bursts up to 10 requests | +| Delegation | `/delegation` | User ID, IP Address | 10 requests per second | +| Change Password | `/dbconnections/change_password` | User Email, IP Address | 1 request per minute with bursts up to 10 requests | +| Signup | `/dbconnections/signup` | IP Address | 50 requests per minute | +| Get Passwordless Code or Link | `/passwordless/start` | IP Address | 50 requests per hour when using non-authenticated calls. It's considered an Authentication API endpoint otherwise. | + +## Limits for non-production tenants of paying customers and all tenants of free customers + +| Endpoint | Path | Limited By | Rate Limit | +| - | - | - | - | +| User Profile | `/tokeninfo` (Legacy) | IP Address | 800 requests per minute | +| | `/userinfo` | User ID | 5 requests per minute with bursts up to 10 requests | +| Delegation | `/delegation` | User ID, IP Address | 10 requests per second | +| Change Password | `/dbconnections/change_password` | User Email, IP Address | 1 request per minute with bursts up to 10 requests | +| Signup | `/dbconnections/signup` | IP Address | 50 requests per minute | +| Get Passwordless Code or Link | `/passwordless/start` | IP Address | 50 requests per hour | +| Get Token | `/oauth/token` | Any request | 30 requests per second | +| Cross Origin Authentication | `/co/authenticate` | Any request | 5 requests per second | +| Authentication | `usernamepassword/login` | Any request | 5 requests per second | +| Resource Owner (Legacy) | `/oauth/ro` | Any request | 10 requests per second | +| JSON Web Token Keys | `/.well-known/jwks.json` | Any request | 20 requests per second | + +## Free tenant global limits + +To ensure Auth0's quality of service, the Authentication API is subject to several levels of rate limiting for free subscribers. Auth0's Authentication API has a global limit of **300 requests per minute** for free tenants. + +::: note +The limit is global for the tenant and not per endpoint. +::: + +### Affected endpoints + +The global rate limit applies to all [Authentication API](/api/authentication) endpoints. A complete list of endpoints that are affected by this limit, along with the associated response if the rate limit is exceeded, is a follows: + +Endpoint | Response +---------|--------- +`GET /authorize` | [Error Page](#error-page) +`GET /passwordless/verify_redirect` | [Error Page](#error-page) +`POST /dbconnections/change_password` | [JSON Error](#json-error) (`too_many_requests`) +`GET /dbconnections/change_password` | [JSON Error](#json-error) (`too_many_requests`) +`POST /dbconnections/self_change_password` | [JSON Error](#json-error) (`too_many_requests`) +`POST /co/authenticate` | [JSON Error](#json-error) (`access_denied`) +`POST /delegation` | [JSON Error](#json-error) (`too_many_requests`) +`GET /delegation` | [JSON Error](#json-error) (`too_many_requests`) +`GET /activate` | [Error Page](#error-page) +`POST /activate` | [Error Page](#error-page) +`POST /oauth/device/code` | [JSON Error](#json-error) (`access_denied`) +`POST /oauth/ro` | [JSON Error](#json-error) (`access_denied`) +`GET /oauth/ro` | [JSON Error](#json-error) (`access_denied`) +`POST /oauth/token` | [JSON Error](#json-error) (`access_denied`) +`POST /oauth/introspect` | [JSON Error](#json-error) (`access_denied`) +`GET /passwordless/start` | [JSON Error](#json-error) (`too_many_requests`) +`POST /passwordless/start` | [JSON Error](#json-error) (`too_many_requests`) +`POST /u/reset-password/request/:connection` | [Error Page](#error-page) +`GET /u/consent` | [Error Page](#error-page) +`POST /u/consent` | [Error Page](#error-page) +`GET /u/login` | [Error Page](#error-page) +`POST /u/login` | [Error Page](#error-page) +`GET /u/mfa-country-codes` | [Error Page](#error-page) +`POST /u/mfa-country-codes` | [Error Page](#error-page) +`GET /u/mfa-email-challenge` | [Error Page](#error-page) +`POST /u/mfa-email-challenge` | [Error Page](#error-page) +`GET /u/mfa-email-enrollment` | [Error Page](#error-page) +`POST /u/mfa-email-enrollment` | [Error Page](#error-page) +`GET /u/mfa-email-enrollment-verify` | [Error Page](#error-page) +`POST /u/mfa-email-enrollment-verify` | [Error Page](#error-page) +`GET /u/mfa-email-list` | [Error Page](#error-page) +`POST /u/mfa-email-list` | [Error Page](#error-page) +`GET /u/mfa-enroll-options` | [Error Page](#error-page) +`POST /u/mfa-enroll-options` | [Error Page](#error-page) +`GET /u/mfa-guardian-list` | [Error Page](#error-page) +`POST /u/mfa-guardian-list` | [Error Page](#error-page) +`GET /u/mfa-guardian-welcome` | [Error Page](#error-page) +`POST /u/mfa-guardian-welcome` | [Error Page](#error-page) +`GET /u/mfa-login-options` | [Error Page](#error-page) +`POST /u/mfa-login-options` | [Error Page](#error-page) +`GET /u/mfa-otp-challenge` | [Error Page](#error-page) +`POST /u/mfa-otp-challenge` | [Error Page](#error-page) +`GET /u/mfa-otp-enrollment` | [Error Page](#error-page) +`POST /u/mfa-otp-enrollment` | [Error Page](#error-page) +`GET /u/mfa-push-challenge` | [Error Page](#error-page) +`POST /u/mfa-push-challenge` | [Error Page](#error-page) +`GET /u/mfa-push-enrollment` | [Error Page](#error-page) +`POST /u/mfa-push-enrollment` | [Error Page](#error-page) +`GET /u/mfa-recovery-code-challenge` | [Error Page](#error-page) +`POST /u/mfa-recovery-code-challenge` | [Error Page](#error-page) +`GET /u/mfa-recovery-code-challenge-new-code` | [Error Page](#error-page) +`POST /u/mfa-recovery-code-challenge-new-code` | [Error Page](#error-page) +`GET /u/mfa-recovery-code-enrollment` | [Error Page](#error-page) +`POST /u/mfa-recovery-code-enrollment` | [Error Page](#error-page) +`GET /u/mfa-sms-challenge` | [Error Page](#error-page) +`POST /u/mfa-sms-challenge` | [Error Page](#error-page) +`GET /u/mfa-sms-enrollment` | [Error Page](#error-page) +`POST /u/mfa-sms-enrollment` | [Error Page](#error-page) +`GET /u/mfa-sms-enrollment-verify` | [Error Page](#error-page) +`POST /u/mfa-sms-enrollment-verify` | [Error Page](#error-page) +`GET /u/mfa-sms-list` | [Error Page](#error-page) +`POST /u/mfa-sms-list` | [Error Page](#error-page) +`GET /u/reset-password` | [Error Page](#error-page) +`POST /u/reset-password` | [Error Page](#error-page) +`GET /u/reset-password/request/:connection` | [Error Page](#error-page) +`GET /u/signup` | [Error Page](#error-page) +`POST /u/signup` | [Error Page](#error-page) +`GET /tokeninfo` | Text: "Rate limit exceed" +`POST /tokeninfo` | Text: "Rate limit exceed" +`POST /userinfo` | Text: "Rate limit exceed" +`GET /userinfo` | Text: "Rate limit exceed" +`POST /usernamepassword/login` | [JSON Error](#json-error) (`too_many_requests`) +`GET /usernamepassword/login` | [JSON Error](#json-error) (`too_many_requests`) +`GET /.well-known/jwks.json` | Text: "Rate limit exceed" +`GET /.well-known/openid-configuration` | [JSON Error](#json-error) (`access_denied`) +`GET /cer/:clientID?` | Text: "Rate limit exceed" +`GET /pb7/:clientID?` | Text: "Rate limit exceed" +`GET /pem/:clientID?` | Text: "Rate limit exceed" +`GET /rawpem/:clientID?` | Text: "Rate limit exceed" +`GET /samlp/:clientID` | Text: "Rate limit exceed" +`POST /samlp/:clientID` | Text: "Rate limit exceed" +`GET /samlp/metadata` | Text: "Rate limit exceed" +`GET /samlp/metadata/:clientID` | Text: "Rate limit exceed" +`GET /:clientID/trust/mex` | XML Error (`wst:RequestFailed`) +`POST /:clientID/trust/usernamemixed` | XML Error (`wst:RequestFailed`, Status Code: 500) +`GET /decision` | [Error Page](#error-page) +`POST /decision` | [Error Page](#error-page) +`POST /drwatson` | Text: "Rate limit exceed" +`POST /mfa/associate` | [JSON Error](#json-error) (`access_denied`) +`GET /mfa/authenticators` | [JSON Error](#json-error) (`access_denied`) +`DELETE /mfa/authenticators/:authenticator_id` | [JSON Error](#json-error) (`access_denied`) +`POST /mfa/challenge` | [JSON Error](#json-error) (`access_denied`) +`GET /oauth/access_token` | [JSON Error](#json-error) (`access_denied`) +`POST /oauth/access_token` | [JSON Error](#json-error) (`access_denied`) +`GET /p/:strategy/:ticket` | Text: "Rate limit exceed" +`POST /p/:strategy/:ticket` | Text: "Rate limit exceed" +`GET /p/:strategy/:ticket/info` | Text: "Rate limit exceed" +`GET /passwordless/verify` | [JSON Error](#json-error) (`too_many_requests`) +`POST /passwordless/verify` | [JSON Error](#json-error) (`too_many_requests`) +`GET /rms` | [Error Page](#error-page) +`GET /rms/:clientID/adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`) +`POST /rms/:clientID/adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`) +`GET /rms/:clientID/FederationMetadata/2007-06/FederationMetadata.xml` | [JSON Error](#json-error) (`too_many_requests`) +`GET /samlp/:clientID/logout` | [Error Page](#error-page) +`POST /samlp/:clientID/logout` | [Error Page](#error-page) +`GET /samlp/idp/slo` | Text: "Rate limit exceed" +`GET /sso_dbconnection_popup/:clientID` | [JSON Error](#json-error) (`access_denied`) +`GET /wsfed` | [Error Page](#error-page) +`GET /wsfed/:clientID` | [Error Page](#error-page) +`GET /wsfed/:clientID/FederationMetadata/2007-06/FederationMetadata.xml` | [Error Page](#error-page) +`GET /wsfed/FederationMetadata/2007-06/FederationMetadata.xml` | [Error Page](#error-page) +`GET /.well-known/apple-app-site-association` | [JSON Error](#json-error) (`access_denied`) +`GET /.well-known/assetlinks.json` | [JSON Error](#json-error) (`access_denied`) +`GET /adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`) +`POST /adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`) +`GET /apple-app-site-association` | [JSON Error](#json-error) (`access_denied`) +`GET /aws-saml/metadata` | Text: "Rate limit exceed" +`GET /changepwd/completed` | [JSON Error](#json-error) (`too_many_requests`) +`GET /changepwd/form` | [Error Page](#error-page) +`POST /changepwd/reset` | [JSON Error](#json-error) (`too_many_requests`) +`POST /co/verify` | Text: "Rate limit exceed" +`GET /continue` | [Error Page](#error-page) +`POST /continue` | [Error Page](#error-page) +`GET /custom-login/preview` | [JSON Error](#json-error) (`too_many_requests`) +`POST /dbconnections/delete` | [JSON Error](#json-error) (`too_many_requests`) +`GET /dbconnections/login` | [JSON Error](#json-error) (`too_many_requests`) +`POST /dbconnections/login` | [JSON Error](#json-error) (`too_many_requests`) +`GET /dbconnections/signup` | [JSON Error](#json-error) (`too_many_requests`) +`POST /dbconnections/signup` | [JSON Error](#json-error) (`too_many_requests`) +`POST /dbconnections/verify_email` | [JSON Error](#json-error) (`too_many_requests`) +`GET /FederationMetadata/2007-06/FederationMetadata.xml` | XML Error (`fed:BadRequest`) +`GET /i/login` | [Error Page](#error-page) +`GET /i/login/sso/:provider` | Text: "Rate limit exceed" +`GET /i/oauth2/authorize` | [JSON Error](#json-error) (`access_denied`) +`GET /login` | [Error Page](#error-page) +`GET /login/callback` | [Error Page](#error-page) +`POST /login/callback` | [Error Page](#error-page) +`GET /logout` | [Error Page](#error-page) +`POST /logout` | [Error Page](#error-page) +`GET /mf` | [Error Page](#error-page) +`POST /mf` | [Error Page](#error-page) +`POST /oauth/reverse` | [JSON Error](#json-error) (`access_denied`) +`POST /oauth/revoke` | [JSON Error](#json-error) (`access_denied`) +`POST /state/introspect` | [JSON Error](#json-error) (`too_many_requests`) +`GET /unblock` | [Error Page](#error-page) +`POST /unlink` | [JSON Error](#json-error) (`too_many_requests`) +`GET /user/ssodata` | Text: "Rate limit exceed" +`GET /users/:id/impersonate` | [JSON Error](#json-error) (`too_many_requests`) +`POST /users/:id/impersonate` | [JSON Error](#json-error) (`too_many_requests`) +`GET /v2/logout` | [Error Page](#error-page) + +## Exceeding the Rate Limit + +If you exceed the rate limit for a given API endpoint, you'll receive an [HTTP 429 (Too Many Requests)](http://tools.ietf.org/html/rfc6585#section-4) response (except for the cases documented in the [previous section](#affected-endpoints)). The response will also contain [HTTP Response Headers](/policies/rate-limits#http-response-headers) that provide additional information on the rate limits applicable to that endpoint. + +If you exceed the global rate limit, the following example log entry will be emitted to your logs: **You have reached the global limit for your account**. There will be a single log entry per hour while your account exceeds the rate limit. + +To view the log entries for a subscription, navigate the to [Logs](${manage_url}#/logs) page in the [Dashboard](${manage_url}). + +### Reducing the number of calls to Auth0 + +When you exceed your rate limits, you'll need to reduce the number of calls you make to Auth0. The specifics depend on your use case, but here are some recommendations: + + * Cache `/.well-known/*` responses: This information does not change frequently, so you can usually cache it to reduce the number of times you need to call Auth0. + + * Consider requesting an `id_token` instead of calling `/userinfo` to get information about the user. + +### Response body + +The response body you receive depends on the endpoint. Each endpoint typically provides a return value in a different format (for example, some return an HTTP response, while others redirect to a URL and pass values in the query string). If the endpoint typically provides the response expected as JSON in the HTTP body, then a JSON error response will be sent if a rate limit is reached (exceptions are documented above). + +To view the particular response per endpoint, see [Affected endpoints](#affected-endpoints). Descriptions of each possible error are listed below. + +#### Error Page + +The Error Page response is sent for endpoints that render HTML content to the end user. When you exceed the rate limit, Auth0 renders the [Error Page](/universal-login/custom-error-pages) instead of the expected content. + +#### JSON Error + +Endpoints that usually provide JSON-formatted responses will return a JSON object containing an error code and description. + +```json +{ + "error": "access_denied or too_many_requests", + "error_description": "Global rate limit exceeded", + "error_uri": "https://.../... documentation url" +} +``` + +The error you receive depends on the type of endpoint you're calling: + +* `access_denied`: for OAuth endpoints +* `too_many_requests`: for endpoints that return JSON + +#### XML Error + +XML Errors are returned for endpoints that normally return XML. + +```xml + + + + + env:Sender + + fed:BadRequest or wst:RequestFailed + + + + Global rate limit exceeded + + + + + + +``` + +The error you receive depends on the type of endpoint you're calling: + +- `fed:BadRequest` will be sent for WSFed-related endpoints. +- `wst:RequestFailed` will be used in for WSTrust-related endpoints. diff --git a/fr-ca/articles/policies/rate-limits-mgmt-api.md b/fr-ca/articles/policies/rate-limits-mgmt-api.md new file mode 100644 index 0000000000..6c8340b61b --- /dev/null +++ b/fr-ca/articles/policies/rate-limits-mgmt-api.md @@ -0,0 +1,100 @@ +--- +title: Management API Endpoint Rate Limits +description: Describes Auth0's rate limit policy when working with Auth0 Management API endpoints. +toc: true +topics: + - auth0-policies + - rate-limits +contentType: + - reference +useCase: + - support +--- +# Management API Endpoint Rate Limits + +**This policy is effective May 19, 2020.** + +::: warning +If you subscribed before **May 19, 2020**, the [previous rate limit policy](/policies/legacy-rate-limits) applies to you until **June 18, 2020**. Starting on **June 18, 2020**, these limits will apply to all tenants. You will be notified of the new limits through a **Dashboard Notification**. If the new limits impact your tenant, you will be notified directly via email with additional information about minimizing API calls and upgrading plans. +::: + +The rate limits for this API differ depending on whether your tenant is free or paid, production or not. + +| Tenant Type | Rate Limit (per second) | Rate Limit (per minute) | +| - | - | - | +| Free or Trial | 10 | 120 | +| Developer or Developer Pro (created before May 19, 2020) | 50 | 1000 | +| Enterprise (Production) | 50 | 1000 | +| Enterprise (Non-production) | 10 | 120 | + +The rate limits include calls made via [Rules](/rules) and are set **by tenant** and not by endpoint. + +Each endpoint is configured with a bucket that defines: + +- Request limit +- Rate limit window (per second, per minute, per day, etc.) + +```text +bucket: + size: x + per_minute: y +``` + +For example, the above states that, for the given bucket, there is a maximum request limit of `x` per minute, and for each minute that elapses, permissions for `y` requests are added back. In other words, for each `60 / y` seconds, one additional request is added to the bucket. This occurs automatically until the bucket contains the maximum permitted number of requests. + +For some API endpoints, the rate limits are defined per bucket, so the origins of the call do not influence the rate limit changes. For other buckets, the rate limits are defined using different keys, so the originating IP address is considered when counting the number of received API calls. + +::: note +If you are using an API endpoint **not** listed below and you receive rate limit headers as part of your response, see [Anomaly Detection](/anomaly-detection) for more information. +::: + +The following Auth0 Management API endpoints return rate limit-related headers. For additional information about these endpoints, please consult the [Management API explorer](/api/management/v2). + +## Developer and Developer Pro subscription limits + +| Endpoint Group | Path | Rate Limit (per second) | Rate Limit (per minute) | +| - | - | - | - | +| Read users | `GET /api/v2/users` | 40 | 500 | +| | `GET /api/v2/users-by-email` | | | +| | `GET /api/v2/users/{id}` | | | +| Write users | `POST /api/v2/users` | 20 | 200 | +| | `POST /api/v2/users/{id}/identities` | | | +| | `PATCH /api/v2/users/{id}` | | | +| | `DELETE /api/v2/connections/{id}/users` | | | +| | `DELETE /api/v2/users/{id}/identities/{provider}/{user_id}` | | | +| | `DELETE /api/v2/users/{id}` | | | +| Read logs | `GET /api/v2/logs` | 10 | 100 | +| | `GET /api/v2/logs/{id}` | | | +| | `GET /api/v2/users/{id}/logs` | | | +| Read clients | `GET /api/v2/clients` | 5 | 100 | +| | `GET /api/v2/clients/{id}` | | | +| Read connections | `GET /api/v2/connections` | 10 | 100 | +| | `GET /api/v2/connections/{id}` | | | +| Write device credentials | `POST /api/v2/device-credentials` | 5 | 100 | +| | `DELETE /api/v2/device-credentials/{id}` | | | +| All other endpoints combined | | 10 | 150 | + +## Endpoint limits for all subscriptions + +| Endpoint | Path | Rate Limit (per second) | Rate Limit (per minute) | Rate Limit (per day) | +| - | - | - | - | - | +| Verify custom domain | `POST /api/v2/custom-domains{id}/verify` | n/a | 5 | n/a | +| Register dynamic client | `POST /oidc/register` | 5 | n/a | n/a | +| Read connection status | `GET /api/v2/connections/{id}/status` | 15 | n/a | n/a | +| Rotate signing keys | `POST /api/v2/keys/signing/rotate` | n/a | n/a | 5 | + +## Concurrent import users job limits + +The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of 2 concurrent import jobs. If you request additional jobs while there are 2 pending returns, the following response occurs: + +```json +{ + "statusCode": 429, + "error": "Too Many Requests", + "message": "There are 2 active import users jobs, please wait until some of them are finished and try again +} +``` + +## Access token limits for SPAs + +If you obtain Access Tokens for your SPAs, there are rate limits that are applicable when working with the available `current_user`-related [scopes and endpoints](/api/management/v2/get-access-tokens-for-spas#available-scopes-and-endpoints). You are allowed a maximum of **10 requests per minute per user**. diff --git a/fr-ca/articles/policies/rate-limits.md b/fr-ca/articles/policies/rate-limits.md new file mode 100644 index 0000000000..3c86e92079 --- /dev/null +++ b/fr-ca/articles/policies/rate-limits.md @@ -0,0 +1,79 @@ +--- +title: Rate Limit Policy +description: Describes Auth0's rate limit policy. +toc: true +topics: + - auth0-policies + - rate-limits +contentType: + - reference +useCase: + - support +--- +# Rate Limit Policy + +Actions such as rapidly updating configuration settings, aggressive polling, or making highly concurrent API calls may result in your app being rate limited. + +Auth0's rate limits vary based on the tenant type you have. The tenants that have no credit card associated in the [Dashboard](${manage_url}/#/tenant/billing/payment) are free. There are also variations in terms of paid tenant types (e.g., non-production, production). To set an environment for your tenant (development, staging or production), go to [Support Center > Tenants](${env.DOMAIN_URL_SUPPORT}/tenants/public), find your tenant, select __Assign Environment Tag__, set the environment and save changes. + +## API endpoint limits + +To ensure the quality of Auth0's services, the Auth0 APIs are subject to rate limiting. Depending on the API endpoint, the request limit and the rate limit window in which the request limit resets, varies. + +Using the Management API for free and trial tenants is restricted to **2 requests per second** (with bursts of up to **10 requests**). Exceeding these values triggers an HTTP 429 error, but the error message states, "Global limit has been reached." These are in addition to those indicated in the rate limit response headers. + +If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed. + +See the rate limits for [Management API Endpoints](/policies/rate-limits-mgmt-api) and [Authentication API Endpoints](/policies/rate-limits-auth-api) for complete details on each endpoint limitation. + +### Review HTTP response headers + +Auth0 reserves the right to modify the rate limits at any time. For the up-to-date information on rate limits, you can review the HTTP response headers returned from rate limited endpoints. + +API requests to selected [Authentication](/api/authentication) or [Management API](/api/management/v2) endpoints will return HTTP response headers that provide relevant data on the current status of your rate limits for that endpoint. If you receive a rate limit-related response header, it will include numeric information detailing your status. + +* **X-RateLimit-Limit**: The maximum number of requests available in the current time frame. +* **X-RateLimit-Remaining**: The number of remaining requests in the current time frame. +* **X-RateLimit-Reset**: A [UNIX timestamp](https://en.wikipedia.org/wiki/Unix_time) of the expected time when the rate limit will reset. + +### Handle rates limitations in code + +You should add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 429 (Too Many Requests). In this case, if a retry is needed, it is best to allow for a back-off to avoid going into an infinite retry loop. + +For scripts and rules that call Auth0 APIs, you should always handle rate limiting by checking the `X-RateLimit-Remaining` header and acting appropriately when the number returned nears 0. + +## Database login limits + +For database connections, Auth0 limits certain types of repeat login attempts depending on the user account and IP address. For more information, see [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits). + +## SMS/Voice message limits for multi-factor authentication + +There's a limit of 10 SMS or Voice messages/hour per user for MFA. For more information, see [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone). + +## Native social login limits + +Limits are only applied to requests related to the Native Social Login flows, which are identified based on the body of the requests with the following initial criteria: + +| Request Type | Body | +| - | - | +| `grant_type` | `urn:ietf:params:oauth:grant-type:token-exchange` | +| `subject_token_type` | `http://auth0.com/oauth/token-type/apple-authz-code` | + +### Limits for production tenants of paying customers + +| Endpoint | Path | Limited By | Rate Limit | +| - | - | - | - | +| Get Token | `/oauth/token` | Any native social login request | 50 per minute with bursts up to 500 requests | + +### Limits for non-production tenants of paying customers and all tenants of free customers + +| Endpoint | Path | Limited By | Rate Limit | +| - | - | - | - | +| Get Token | `/oauth/token` | Native social login requests and IP | 30 per minute | + +## Keep reading + +* [Management API Endpoint Rate Limits](/policies/rate-limits-mgmt-api) +* [Authentication API Endpoint Rate Limits](/policies/rate-limits-auth-api) +* [Legacy Rate Limits](/policies/legacy-rate-limits) +* [Entity Limit Policy](/policies/entity-limits) diff --git a/fr-ca/articles/policies/restore-deleted-tenant.md b/fr-ca/articles/policies/restore-deleted-tenant.md new file mode 100644 index 0000000000..a9e135d7c6 --- /dev/null +++ b/fr-ca/articles/policies/restore-deleted-tenant.md @@ -0,0 +1,23 @@ +--- +description: This page details Auth0's deleted tenant restoration policy. +topics: + - auth0-policies + - tenants + - tenant-restoration +contentType: + - reference +useCase: + - support +--- + +# Tenant Restoration Policy + +::: warning +**Deleted tenants cannot be restored** and the **tenant name may not be used again** when creating new tenants. +::: + +**Before you delete your tenant, please check out the following resources for alternative options:** +* [Updating a Tenant Admin](https://auth0.com/docs/dashboard/manage-dashboard-admins#update-admin) **for changing ownership of the tenant** +* [Delete or Reset Tenants](/tutorials/delete-reset-tenant) for reseting tenant configuration. + +If you've deleted your tenant, and you require the use of a particular domain name, we recommend configuring a [custom domain name](/custom-domains) for your new tenant. diff --git a/fr-ca/articles/policies/unsupported-requests.md b/fr-ca/articles/policies/unsupported-requests.md new file mode 100644 index 0000000000..793fd7ff2f --- /dev/null +++ b/fr-ca/articles/policies/unsupported-requests.md @@ -0,0 +1,41 @@ +--- +description: The following is a list of requests Auth0 currently doesn't support. +topics: + - auth0-policies + - support +contentType: + - reference +useCase: + - support +--- + +# Unsupported Requests + +Our support team strives to assist you to the best of our ability. However, we are currently unable to grant the following requests: + +* Transferring data from a non-production to a production account + +* Renaming a tenant + +* Renaming a connection + +* Re-using the name of a previously deleted tenant + +* Migrating a tenant from one region to another (for example, from US to EU) + +* Ad hoc usage data reports. + +* Restore any deleted or modified data or settings in tenants, including: + + * Database connections and their users and passwords + * Users, their profile information, metadata, roles membership + * Roles and permissions + * Applications + * SSO Integrations + * APIs + * Connections + * Rules + * Hooks + * Extensions + * Email templates + * Tenant logs once the [standard retention time](/logs/references/log-data-retention) passed diff --git a/fr-ca/articles/pre-deployment/how-to-run-test.md b/fr-ca/articles/pre-deployment/how-to-run-test.md new file mode 100644 index 0000000000..f06bf5038a --- /dev/null +++ b/fr-ca/articles/pre-deployment/how-to-run-test.md @@ -0,0 +1,69 @@ +--- +description: How to run the Auth0 Production Check to ensure that your Applications are production-ready +topics: + - pre-deployment + - pre-deployments-tests + - tests + - production-checks +contentType: + - reference + - how-to +useCase: + - support +--- + +# How to Run the Production Checks + +The Production Checks can be reviewed in the [Auth0 Support Center Tenants section](${env.DOMAIN_URL_SUPPORT}/tenants/public). + +![](/media/articles/support/pre-deployment-tests/support-home.png) + +Once you've logged in to your account, click **Tenants** in the navigation bar. + +![](/media/articles/support/pre-deployment-tests/tenants.png) + +You'll see a listing of all tenants associated with your Auth0 account. Each tenant displays in its own box. Identify the tenant for which you want to run the Production Checks, and click on the **gear icon** located in the top right-hand corner of its box. + +![](/media/articles/support/pre-deployment-tests/tenants-tests.png) + +Click **Run Production Check** to launch the testing interface. + +At this point, you'll be able to select one or more [Applications](/applications) associated with this tenant for which you want checks run. + +![](/media/articles/support/pre-deployment-tests/choose-applications.png) + +Once you've selected your applications, click **Run Check**. + +When the test is complete, your screen will automatically refresh to display your check results. + +![](/media/articles/support/pre-deployment-tests/results.png) + + +## Production Check Results + +There are three types of check results: Required, Recommended, and Best Practices. + +| Result Type | Description | +| ----------- | ----------- | +| Required | These checks see if you are missing any steps you **must** complete before deploying to Production; otherwise you'll see errors. | +| Recommended | These checks see if you are missing any steps **recommended** by Auth0. While you do not have to complete the steps suggested, we recommend that you at least review the results to see if any of them are helpful to your implementation. +| Best Practices | These areas are ones where Auth0 cannot use automated checks. We list areas of possible concern, and we suggest that you review your implementation to see if you're compliant with Auth0 recommendations. | + +## How to Read Your Results Set + +The following are possible results for your check: Passed, Failed, Unable to Verify. + +Under each set of check results, Auth0 tells you how many checks your Application passed, as well as how many checks your Application failed. + +![](/media/articles/support/pre-deployment-tests/reading-results.png) + +If your Application **failed** one or more checks, Auth0 provides: + +* The name of the check +* Information on what the check is looking for +* Details on the error thrown to and retrieved by the check +* Hyperlink to the appropriate area where you can make the required fixes so that your Application passes the check + +![](/media/articles/support/pre-deployment-tests/detailed-results.png) + +All of the checks that your Application **passed** are grouped together at the bottom of the results set. You can view the name of and information about the check, as well as review the associated documentation and use the hyperlink to go to the corresponding configuration area where you can make changes (if desired). diff --git a/fr-ca/articles/pre-deployment/index.html b/fr-ca/articles/pre-deployment/index.html new file mode 100644 index 0000000000..d3f15af976 --- /dev/null +++ b/fr-ca/articles/pre-deployment/index.html @@ -0,0 +1,59 @@ +--- +classes: topic-page +title: Production Checks +topics: + - pre-deployment + - pre-deployments-tests + - tests + - production-checks +contentType: + - index +useCase: + - support +--- + +
+
+

Production Checks

+

+ Before you go live, run Auth0's production checks suite to ensure that your tenants are ready for use in a production environment. +

+
+ + diff --git a/fr-ca/articles/pre-deployment/prelaunch-tips.md b/fr-ca/articles/pre-deployment/prelaunch-tips.md new file mode 100644 index 0000000000..c82eac9222 --- /dev/null +++ b/fr-ca/articles/pre-deployment/prelaunch-tips.md @@ -0,0 +1,65 @@ +--- +title: Pre-Launch Tips +description: A list of helpful tips for when getting started with Auth0 services based on feedback and experience from others. +topics: + - pre-deployment + - pre-launch + - tips-and-tricks + - production-checks +contentType: + - reference +useCase: + - support +--- + +# Pre-Launch Tips + +Here is a list of tips our customers have found most useful when first getting started with Auth0 services: + +* Check the URLs in your allowed callbacks, CORS and allowed redirect URLs for Logout to make sure they are correct, complete, and do not involve use of `file:///` or `localhost`. Minimize the use of wildcards and consider carefully the security ramifications of wildcards. + +* Separate production use from ongoing development work by [using separate tenants for prod, test and dev.](/dev-lifecycle/setting-up-env) + +* Configure your network correctly to allow traffic to and from our sets of public APIs (prod envs might have a different setup than dev/staging). + +* Check the expiration date of certificates you have added to your configuration to make sure certificates uploaded during development cycles won’t expire during or shortly after launch. + +* Make sure any remote IDPs are running NTP so that the time will be properly synced. + +* The number of days of log data available varies by plan up to a max of 30 days. If you need log data for a longer retention period, you should set up one of the [Auth0 extensions](/extensions#export-auth0-logs-to-an-external-service) that will send log data to a third party service. This will enable you to keep log data for longer periods. Be sure to set this up before you go live so you are sure to have log data when you need it. + +* Make sure your usage of our APIs remains within [allowed limits](/policies/rate-limits) and you have written your code to dynamically adjust to rate limit information returned in the header and to handle errors. If you anticipate rate limits being a problem for your application, discuss with us up-front to check if it would be possible to momentarily raise them until the traffic returns to normal. You should consider using a cache of user data in order to not have to query an API endpoint more than necessary. + +* If using [social connections](/identityproviders) make sure to obtain your own credentials from the provider and add them to the configuration of the social connection. + +* If using [custom DB connections](/connections/database/mysql) make sure all custom DB scripts are implemented and return a consistent user-profile with a unique user ID. + +* For sending emails first make sure to [setup a custom email provider.](/email/providers) + +* If you use our CDN for the Lock widget, make sure to [pin to a specific version.](/libraries/lock/v10#installation-sources) + +* Make sure **external** components called from rules, hooks and custom DB connection scripts can handle the expected load. + +* Adequately protect any client secret values. + +* Check your [grant types](/applications/concepts/application-grant-types) for your applications. Make sure you have the right ones enabled and more importantly, disable any grant types that aren't needed. + +* If you make use of [user_metadata](/users/concepts/overview-user-metadata) confirm that this is data that users should be able to change on their own (eg. not “payment status”). + +* Review your [Anomaly Detection settings](${manage_url}/#/anomaly) and read the [Anomaly Detection doc](/anomaly-detection) to understand how to unblock users that have been blocked. + +* Review your [Tenant Settings Admin section](${manage_url}/#/tenant/admins) to make sure that only appropriate admins have access to the Auth0 dashboard. + +* Make sure you have tested all core use cases for your application on all devices that might be used by the end-user population for your application. Be sure to test both login, single-sign-on (if supported) and log as well as what happens if a user runs your application in multiple browser tabs. + +* Review your [list of rules](${manage_url}/#/rules) and make sure only the appropriate rules are turned on. + +* Review your rule code, any custom DB scripts and any custom code in the login page to ensure that every call has adequate error trapping and handling. Also review to make sure that return/callback statements are called correctly. + +* Configure your application name, support URL and support email in the [Tenant Settings General](${manage_url}/#/tenant) section so when an error occurs your end users will be directed to an appropriate page. + +* Make sure that your application is [dynamically obtaining a management API token](/api/management/v2/tokens) and make sure to read the [Management API Access Token FAQs](/api/management/v2/faq-management-api-access-tokens). + +* Remove any `console.log` statements from your rules or custom DB scripts. Especially those that might leak user identifiable information such as email, username or password. + +* Do not use plain text secrets in rules or db-connections. They should be added in the configuration part of the interface. The configuration is encrypted and provided just in time. Do not log the configuration object. diff --git a/fr-ca/articles/pre-deployment/tests/best-practice.md b/fr-ca/articles/pre-deployment/tests/best-practice.md new file mode 100644 index 0000000000..ff5bd52ff9 --- /dev/null +++ b/fr-ca/articles/pre-deployment/tests/best-practice.md @@ -0,0 +1,27 @@ +--- +description: Checks to ensure that your Applications comply with Auth0 best practices +topics: + - pre-deployment + - pre-deployments-tests + - tests + - best-practices + - production-checks +contentType: + - reference +useCase: + - support +--- + +# Production Checks: Best Practices + +The following checks cannot be automated, so we recommend manually checking these areas prior to deployment to Production. + +| Check | Description | +| ---- | ----------- | +| [Anomaly Detection](/anomaly-detection) | Review your account's [Anomaly Detection capability and configuration](${manage_url}/#/anomaly). | +| Externalize [Configuration Parameters](/connections/database/mysql#4-add-configuration-parameters) | [Externalize, instead of hard code, all configuration parameters](${manage_url}/#/connections/database), such as credentials, connection strings, API keys, and so on, when developing Rules, Hooks, or custom database connections. | +| [Restrict Delegation](/dashboard/reference/settings-application#advanced-settings) | If not using Delegation, set the Allowed Apps and APIs field of your Application Settings to the current Client ID. | +| Single Sign-on (SSO) Timeout Values | Review the default [SSO cookie timeout values](${manage_url}/#/account/advanced) and ensure they align with your requirements. | +| Tenants and Administrators | Review all tenants and tenant administrators to ensure they are correct. Decommission tenants that are no longer in use. Ensure that tenant administrators are limited to the necessary users. | +| Verify Client IDs in App Code | Ensure that the Client IDs in your application code align with their Auth0 Application configurations. | +| Whitelist Auth0 Public IPs | Whitelist Auth0 IPs if you're connecting to internal services or services behind a firewall when using Rules, Hooks, or custom databases. You can get a list of IP addresses in the tool tip when configuring any of these items. | diff --git a/fr-ca/articles/pre-deployment/tests/recommended.md b/fr-ca/articles/pre-deployment/tests/recommended.md new file mode 100644 index 0000000000..77969efda4 --- /dev/null +++ b/fr-ca/articles/pre-deployment/tests/recommended.md @@ -0,0 +1,33 @@ +--- +description: Recommendations on how you can improve your Auth0 Application prior to production deployment +topics: + - pre-deployment + - pre-deployments-tests + - tests + - recommendations + - production-checks +contentType: + - reference +useCase: + - support +--- + +# Production Checks: Recommended Fixes + +The following checks see if you've completed all recommendations (which are optional) for successful deployment to Production. + +::: note +See [How to Read Your Results Set](/pre-deployment/how-to-run-test#how-to-read-your-results-set) for additional information on your checks output. +::: + +| Check | Description | +| ---- | ----------- | +| [Authorization Extension](/extensions/authorization-extension/v2) | Evaluate the [Authorization Extension if you have authorization requirements](${manage_url}/#/extensions). | +| [Custom Domain](/custom-domains) is configured | Use [custom domains with Universal Login](${manage_url}/#/tenant/custom_domains) for the most seamless and secure experience for your end users. | +| [Custom Error Page](/universal-login/custom-error-pages) is configured | [Configure a Custom Error Page](${manage_url}/#/account) with your application-specific details and corporate branding. | +| [Email Templates](/email/custom) are configured | [Configure custom email templates](${manage_url}/#/emails) with your application specific details and corporate branding. | +| [Guardian Multi-factor](/mfa) or other Multi-factor Authentication Providers | Consider [multi-factor authentication](${manage_url}/#/guardian) as part of the authentication strategy. | +| [MFA for Tenant Administrators](/tutorials/manage-dashboard-admins) is enabled | [Enable multi-factor authentication](${manage_url}/#/account/admins) for tenant administrators. | +| [Universal Login Password Reset Page](/universal-login/password-reset) is customized | [Configure a Custom Universal Login Page for Password Reset](${manage_url}/#/password_reset) with your application details and corporate branding. | +| [Redirect Logout URL](/logout#set-the-allowed-logout-urls-at-the-account-level) | Review the [Allowed Redirect Logout URLs](${manage_url}/#/account/advanced) for your Application. | +| Use RS256 Instead of HS256 | Set the JSONWebToken [Signature Algorithm](/apis#signing-algorithms) to RS256 instead of HS256. | diff --git a/fr-ca/articles/pre-deployment/tests/required.md b/fr-ca/articles/pre-deployment/tests/required.md new file mode 100644 index 0000000000..848f2ea432 --- /dev/null +++ b/fr-ca/articles/pre-deployment/tests/required.md @@ -0,0 +1,36 @@ +--- +description: Fixes you must make to your Auth0 Application prior to production deployment +topics: + - pre-deployment + - pre-deployments-tests + - tests + - requirements + - production-checks +contentType: + - reference +useCase: + - support +--- + +# Production Checks: Required Fixes + +The following checks see if you've completed all requirements for successful deployment to Production. + +::: note +See [How to Read Your Results Set](/pre-deployment/how-to-run-test#how-to-read-your-results-set) for additional information on your checks output. +::: + +| Check | Description | +| ---- | ----------- | +| [Allow ID Tokens for Management API v2 Authentication](/migrations/guides/calling-api-with-idtokens) is disabled | The capabilities for using ID Tokens to authorize some of the Users and Device Credentials endpoints of the Management API are being deprecated. After completing migration to Access Tokens, make sure the [`Allow ID Tokens for Management API v2 Authentication` toggle is turned off](${manage_url}/#/tenant/advanced). If you can't see this setting, then your tenant was created after this feature was deprecated, so it is already disabled by default. | +| [Allowed Callback URLs](/protocols/oauth2/redirect-users) are not Localhost | Validates the [Application Allowed Callback URLs do not point to localhost](${manage_url}/#/applications), 127.0.0.1, and so on. | +| [Allowed Origins (CORS)](/cross-origin-authentication) is not Localhost | Validates that the [Location URL for the page does not point to localhost](${manage_url}/#/applications). | +| [Allowed Web Origins are not Localhost](/dashboard/reference/settings-application) | Validates that the [Allowed Web Origins URLs do not point to localhost](${manage_url}/#/applications). | +| [Email Provider](/email/providers) is configured | Verifies that the [custom email provider has been configured](${manage_url}/#/emails/provider). | +| [SMS or Voice Provider](/mfa/guides/configure-phone) is configured (Dependency: MFA is configured) | Ensures that [Twilio SMS is configured](${manage_url}/#/mfa) if you're using MFA with SMS or Voice. | +| Legacy Lock Migration is disabled | The `/usernamepassword/login` and `/ssodata` endpoints will be removed from service on July 16th, 2018. These are used by Lock.js v8, v9, v10, and auth0.js v6, v7 and v8. After completing the migration to the latest versions, make sure the [`Legacy Lock Migration` toggle is turned off](${manage_url}/#/account/advanced). | +| [Legacy User Profile](/guides/migration-legacy-flows#user-profiles) is disabled | The legacy authentication flows that allow ID Tokens and the `/userinfo` endpoint to include the complete user profile are being deprecated. After completing the migration to the new OIDC-conformant APIs, make sure the [`Legacy User Profile` toggle is turned off](${manage_url}/#/account/advanced). | +| [Social Connections](/connections/social/devkeys) are not using Auth0 Developer Keys | Verifies that [Social Connections are not using the default Auth0 developer keys](${manage_url}/#/connections/social). | +| Support Email is configured | Ensures the [Support Email is configured](${manage_url}/#/account) in Tenant Settings. | +| Support URL is configured | Ensures the [Support URL is configured](${manage_url}/#/account) in Tenant Settings. | +| Tenant Environment Tag is configured | Ensures the [tenant environment tag is set](${env.DOMAIN_URL_SUPPORT}/tenants/public) appropriately to Production, Staging, or Development. | diff --git a/fr-ca/articles/private-cloud/add-ons.md b/fr-ca/articles/private-cloud/add-ons.md new file mode 100644 index 0000000000..5e5ec04cab --- /dev/null +++ b/fr-ca/articles/private-cloud/add-ons.md @@ -0,0 +1,90 @@ +--- +section: private-cloud +description: Overview of the add-on options available to Private Cloud customers +topics: private-cloud +contentType: concept +useCase: private-cloud +sitemap: false +--- +# Private Cloud Add-On Options + +The follow add-on options are available to Private Cloud customers: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Customer-Hosted MPCAuth0-Hosted MPCPrivate CloudPublic Cloud
Enhanced Uptime Guarantee (SLA)
Yes
Yes
Yes
No
High Capacity +
Yes
Yes
Yes
No
PCI Certified +
No
Yes
Yes
No
GEO-HA
Yes
Yes
No
No
Additional Pre-Production Environment
Yes
Yes
No
No
+ +## Enhanced Uptime Guarantee (SLA) + +The Enhanced Uptime Guarantee (SLA) increases the Private Cloud standard SLA of 99.95% to 99.99%. + +While Auth0's Public Cloud offers a 99.9% uptime guarantee, the Private Cloud's single tenant instances with dedicated resources can offer a higher SLA of 99.95%. For an additional cost, you can request the highest SLA of 99.99% uptime. + +## High Capacity + +The High Capacity add-on increases the maximum requests per second (RPS) the Private Cloud can handle from 500 RPS to 1500 RPS. + +Auth0 guarantees that the Private Cloud can handle up to 500 requests per second (RPS), but if you are looking for greater scalability for the most demanding applications, the High Capacity add-on increases this number to 1500 RPS. This is recommended for large-scale production operations supporting over 1 million users or to support your business requirements. + +## PCI Certified + +Auth0's dedicated deployments are ISO27001, SOC 2 Type II, ISO27018 and HIPAA BAA compliant, but the PCI Certified add-on ensures that your deployment is compliant with PCI-DSS requirements as well. + +## GEO-HA + +With the Geographic High Availability (GEO-HA) add-on, you will have the highest form of dedicated deployment availability offered by Auth0. + +The standard dedicated deployment is a single-region, high availability solution, but the GEO-HA add-on extends the cluster with a geographically-distributed region where the maximum round-trip latency does not exceed 100 milliseconds. This is referred to as a high-availability GEO cluster, which is a warm standby configuration with failure handling for rapid recovery during a regional outage. + +## Additional Pre-Production Environment + +The Managed Private Cloud includes a fully-isolated and independently-updated instance for development and testing. You can add additional Pre-Production Environments to meet your business requirements. + +::: note +Guaranteed Requests per Second and SLA do not apply to Pre-Production Environments. +::: diff --git a/fr-ca/articles/private-cloud/custom-domain-migration.md b/fr-ca/articles/private-cloud/custom-domain-migration.md new file mode 100644 index 0000000000..7922c55bae --- /dev/null +++ b/fr-ca/articles/private-cloud/custom-domain-migration.md @@ -0,0 +1,79 @@ +# Custom Domain Migration + +Beginning with Private Cloud release 1906, dedicated deployments will include the ability to fully utilize the [Auth0 Custom Domains](/custom-domains) feature. + +Existing Private Cloud customers using Custom Domains must complete a migration of their Private Cloud Custom Domains to the Auth0 Custom Domains features. New customers/deployments will automatically use the Auth0 Custom Domains features. + +::: note +The Auth0 Custom Domains feature will be available in release 1905 for those who wish to opt-in early. +::: + +## Background + +Auth0 added support for custom domains in the Private Cloud platform in January 2016. This implementation allowed Private Cloud administrators to create one or more custom domains per tenant and invoke the Authentication API endpoints using those domains. + +In March 2018, Auth0 added support for custom domains for those deploying on the Public Cloud. However, the feature included additional capabilities not included on the Private Cloud implementation. The following table summarizes the differences. + +| Feature | New Custom Domains | Legacy Custom Domains | +| - | - | - | +| Use of custom domain in emails | Yes | No | +| Custom domain protection via API keys | Yes | No | +| Custom domain registration | Yes | Yes | +| Token issuer used as custom domain | Yes | No | +| Auth0-managed certificates | Yes | No | +| Use of multiple domains | No | Yes | + +## Requirements + +* A new DNS domain dedicated to the Custom Domain's origin server hostname. This could be a subdomain of your existing Auth0 Domain (i.e., if your domain name is `*.auth.mydomain.com`, the new subdomain would be `*.cd.auth.mydomain.com`). +* A wildcard public SSL certificate for the new DNS domain. +* A layer 4 network load balancer. This could be the existing one used by your Private Cloud deployment. Please note that if you are using a layer 7 load balancer, you **must** add a layer 4 load balancer. +* A DNS record pointing to the layer 4 load balancer. + +## Migration + +Current Private Cloud customers using the existing Private Cloud Custom Domains functionality **must migrate to the Auth0 Custom Domains** feature to fully benefit from the features available. + +## Migration process + +The Custom Domains migration process involves three phases, each of which requires several steps. + +### Communication Phase + +Before beginning the migration process, Auth0 will reach out to you to explain the migration process and discuss the following: + +* The certificate management model you would like to use + + Auth0 offers [two certificate management models](/custom-domains/#certificate-management). To simplify the migration process, we suggest using one model for all of your tenants (though you can use a different certificate model for each tenant if necessary). + +* The type of load balancer you're using (i.e. network (layer 4) or application (layer 7)) + + If your dedicated deployment is AWS-hosted, we will need to confirm the type of load balanced you're using. If you are using an application load balancer, you will need to provision an additional network load balancer. + +* Allocating new DNS resources to meet stated requirements (if necessary) + + You will need to have ready the **edge domain name** and accompanying **SSL certificate**, the **CNAME host name**, and the **email address** to be used as the Let's Encrypt contact. + +### Infrastructure preparation phase + +::: note +If your Private Cloud deployment resides in an Auth0-hosted environment, Auth0 will prepare your environment for migration on your behalf. +::: + +During this stage, you will need to: + +1. Set up the network load balancer +2. Set up your new DNS records +3. Validate and verify that your set up is correct + +### Migration phase + +The goal of the migration phase is to create custom domains that have all the new functionality and to update all dependencies to function correctly with your newly-created domain names. + +The first step is to create new domains using the Auth0 [Custom Domains](/custom-domains) feature. + +Once done, you may have [additional configuration steps](/custom-domains/additional-configuration#configure-social-identity-providers), depending on the Auth0 features you use. + +#### Final configuration + +One you have completed all of the required modifications on your applications, a Managed Services Engineer will assist you in completing the migration process. diff --git a/fr-ca/articles/private-cloud/index.md b/fr-ca/articles/private-cloud/index.md new file mode 100644 index 0000000000..044901fc2b --- /dev/null +++ b/fr-ca/articles/private-cloud/index.md @@ -0,0 +1,94 @@ +--- +section: private-cloud +description: Overview of the Private Cloud deployment options +classes: topic-page +topics: + - private-cloud + - managed-private-cloud +contentType: concept +useCase: private-cloud +title: Private Cloud Deployment +--- +
+
+

Private Cloud Deployment

+

+ A low-friction, dedicated Auth0 deployment that exists in Auth0's Private Cloud or a Customer-Hosted Cloud. +

+
+ +Users with requirements not met by the Auth0 Public Cloud may instead opt for a Private Cloud deployment option. + +Auth0 currently offers two Private Cloud deployment models: + +* [**Standard** Private Cloud](/private-cloud/standard-private-cloud) +* [**Managed** Private Cloud](/private-cloud/managed-private-cloud), either hosted by Auth0 or hosted by you on an AWS environment and operated by Auth0 as a managed service + +Private Cloud deployments are single-subscriber, isolated instances where none of a customer's resources (software and infrastructure) are shared with any other tenants. This offers increased performance, stability, and availability. + +## Private Cloud options and comparison + +Here is how the two Private Cloud deployment options compare to each other, as well as how they compare to the Enterprise (Public Cloud) option. + +| | Managed | Standard | Public Cloud (Enterprise Subscription Plan) | +| - | - | - | - | +| Instance Type | **Dedicated** Cloud Instance | **Dedicated** Cloud Instance | **Shared** Cloud Instance | +| Deployment Location | Auth0 Private Cloud *or* Customer-Owned AWS Cloud | Auth0 Private Cloud | Auth0 Public Cloud | +| Pre-Production Environment | Includes fully-isolated and independently updated instance for development and testing | Additional tenants within the same instance as the production tenant available | Additional tenant within the shared environment | +| Updates | Choice of update frequency to be coordinated with Auth0. Update cycle begins with the Pre-Production Environment | Automatic Monthly Updates | Automatic Updates | +| Uptime Guarantee | 99.95% SLA with optional upgrade to 99.99% | 99.95% SLA with optional upgrade to 99.99% | 99.90% (no upgrade option available) | +| Requests per Second | 500 requests per second with optional upgrade to 1500 requests per second | 500 requests per second with optional upgrade to 1500 requests per second | See [Rate Limit Policy for Auth0 APIs](/policies/rate-limits) | +| [Data Residency](#data-residency) | Region of Choice | Region of Choice | Varies based on tenant location | +| PCI Certified | Add-on available | Add-on available | No | +| Geographic High Availability (GEOHA) | Add-on available | No | No | + +## Data residency + +Private Cloud customers can choose the region where their data is stored -- any region with three (3) availability zones can be used for the Private Cloud. All data will remain and be stored in the chosen region. This is crucial in instances where regulations prevent data from being sent outside the origin region. + +For Auth0-hosted Private Cloud customers: + +* Backups will be processed and stored in the US +* Service logs will be processed in the region closest to where the customer hosts their Private Cloud; the current options include Japan, Germany, United Kingdom, United States, Canada, or Australia. + +If you are a **Private Cloud** customer with data sovereignty requirements, Auth0 supports Private Cloud deployments in the following regions: USA, Europe, Australia, Canada, and Japan. Otherwise, the Private Cloud can be supported in other regions (except China). Furthermore, Auth0 can: + +* Deploy backups to AWS' S3 service in the same region that hosts the Private Cloud +* Send service logs to Japan, Germany, United Kingdom, United States, Canada, or Australia (regardless of which region you've chosen to host the Private Cloud). You may also opt to not send any service logs + +We are currently unable to offer deployments to China. + +## Additional information + + \ No newline at end of file diff --git a/fr-ca/articles/private-cloud/managed-private-cloud/index.md b/fr-ca/articles/private-cloud/managed-private-cloud/index.md new file mode 100644 index 0000000000..085561e65e --- /dev/null +++ b/fr-ca/articles/private-cloud/managed-private-cloud/index.md @@ -0,0 +1,49 @@ +--- +section: private-cloud +description: Overview of the Managed Private Cloud deployment option +topics: managed-private-cloud +contentType: concept +useCase: private-cloud +--- +# Managed Private Cloud + +Auth0's **Managed Private Cloud** (MPC) is a specially customized Auth0 deployment that gives you greater flexibility and increased input when it comes to day-to-day operations. + +## Benefits of the Managed Private Cloud + +With a Managed Private Cloud, we work closely with you to make sure that all aspects of your Auth0 environment and deployment are tuned to best meet the needs of your business. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BenefitDetails
On-Demand BalancingIf you're expecting a usage spike, contact us and we'll scale your environment so that you have the capacity you need to handle the your traffic load
Annual Load TestingYou may choose to load test your Auth0 environment if desired. While not required, Auth0 appreciates notification of such tests ahead of time.
Scheduled UpdatesScheduled updates to create a release cadence to fit your team and your business' schedule
Staging EnvironmentDedicated environment to test new releases and changes
GEO-HAOptional. Add-on available for Geographic High Availability.
Customer-HostingOptional. Can host your Auth0 deployment in an AWS cloud owned by you
diff --git a/fr-ca/articles/private-cloud/managed-private-cloud/raci.md b/fr-ca/articles/private-cloud/managed-private-cloud/raci.md new file mode 100644 index 0000000000..8c343a461b --- /dev/null +++ b/fr-ca/articles/private-cloud/managed-private-cloud/raci.md @@ -0,0 +1,157 @@ +--- +section: private-cloud +description: Differences between the two Managed Private Cloud deployment options and the Customer-Hosted RACI +topics: managed-private-cloud +contentType: concept +useCase: private-cloud +--- +# Customer-Hosted Differences and RACI + +The customer-hosted Managed Private Cloud provides you with everything you need to run Auth0 in your Amazon Web Services environment. + +## Differences between the Auth0-Hosted and the Customer-Hosted Managed Private Cloud + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Auth0-HostedCustomer-Hosted on AWS
Public-Facing?YesCan be configured to be public-facing or not
Service and Uptime ReportingAuth0 responsible for monitoringCustomer responsible for monitoring
Infrastructure and Backup ResponsibilityAuth0 responsible for backupsCustomer responsible for backups
PCI Compliance Add-OnAvailableNot available
Breached Password DetectionAvailableNot available
AWS CostsNot applicableCustomer responsible for all AWS costs associated with running the infrastructure required for a customer-hosted deployment
+ +## Responsibilities regarding the Customer-Hosted Private Cloud + +Auth0 is responsible for: + +* The initial installation +* General maintenance +* Installation of patches and updates + +The subscriber/customer is responsible for supplying and monitoring the infrastructure on which the Private Cloud runs. This includes, but is not limited to: + +* The EC2 hosts +* Data storage +* Network resources +* Any required dependencies + +### Detailed Division of Responsibilities + +The following RACI Matrix provides an in-depth summary of the roles and responsibilities that will be allocated between Auth0 and the customer/subscriber. + +**RACI**: + +* **Responsible**: the assigned party who is responsible for executing the task +* **Accountable**: the assigned party who is accountable for the task being completed +* **Consulted**: the party/parties whose opinions are requested and with whom there is two-way communication +* **Informed**: the party/parties who are kept up-to-date with regards to progress and with whom there is one-way communication + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Private Cloud-Related Tasks or DeliverablesAuth0Customer/SubscriberNotes
Preparing AWS Infrastructure (including memory, storage, processors, load balances, networks, SSL certificates, DNS records, SMTP servers, enabling Auth0 access via Jumphost/VPN)CR, A (the subscriber's infrastructure engineer)The subscriber will contact Auth0 when the AWS environment is ready and the infrastructure requirements are met
Set up Development and Production environmentsR, A (the Managed Services Engineer (MSE))IThe Auth0 Managed Service Engineer will SSH into the AWS environment and deploy the Auth0 Private Cloud
Configure Development and Production environmentsCRThe Auth0 Managed Service Engineer will show the subscriber's infrastructure engineer how to upload the SSL certificates, enter the SMTP credentials, and add administrators
Operations HandoverRCThe Auth0 Managed Service Engineer and Technical Account Managers will hold an Operations Handover meeting to review information regarding Private Cloud monitoring, backup, and updates and to answer questions
MonitoringIR, AThe subscriber is responsible for monitoring the Private Cloud Deployment
Backing UpI (in the event there are issues)R, AThe subscriber is responsible for backing up the Private Cloud deployment using the Command-Line Tools
User Migration (if required)C, I (in the event there are issues)R, AThe subscriber is responsible for migrating users where appropriate
UpdatesRR, AThe Auth0 Managed Service Engineers will partner with the subscriber's infrastructure engineers to update the Private Cloud Deployment on an agreed-upon basis. The subscriber is responsible for taking AMI snapshot(s) prior to the update, providing access to the Private Cloud deployment, and being present during the update. Auth0 is responsible for running manual scripts (if required) and informing the subscriber on the status of the update
Testing Updates in Non-Production Environment(s)C, I (in the event that there are questions/issues)R, AThe subscriber will test the Private Cloud after the Development node has been updated and inform Auth0 of any issues
Testing Updates in ProductionC, I (in the event that there are questions/issues)R, AThe subscriber will test the Private Cloud after the Production node has been updated and inform Auth0 of any issues
Issue Identification and Support Ticket SubmissionCR, AThe subscriber is responsible for submitting issues via the Support Center
Issue ResolutionR, CCAuth0 will provide support for issues within the *core* of the Auth0 product. Auth0 will consult on issues pertaining to integration with the Auth0 product
\ No newline at end of file diff --git a/fr-ca/articles/private-cloud/managed-private-cloud/zones.md b/fr-ca/articles/private-cloud/managed-private-cloud/zones.md new file mode 100644 index 0000000000..d7452081aa --- /dev/null +++ b/fr-ca/articles/private-cloud/managed-private-cloud/zones.md @@ -0,0 +1,95 @@ +--- +section: private-cloud +description: Configuring Parameters for a Group of Auth0 Nodes +topics: managed-private-cloud +contentType: concept +useCase: private-cloud +--- +# Work with Zones in the Managed Private Cloud + +Beginning with **Managed** Private Cloud Release **1910.0**, you will be able to: + +* Group your Auth0 nodes into **zones** +* Uniquely configure each zone so that each zone has its own parameters and configuration settings + +## Zones 101 + +If you have multiple nodes, you can group the nodes into zones. For example, you might group six nodes as follows: + +* **Region 1** consists of nodes `a0-1`, `a0-2`, and `a0-3`. +* **Region 2** consists of nodes `a0-4`, `a0-5`, and `a0-6`. + +Each zone has its own configuration, which informs the base configuration for a zone (therefore, the configuration for a node is inherited from the zone). + +## How to create zones + +You can create new zones via the Private Cloud Dashboard. + +Go to **/psaas/dashboard** (replace **manage_url** with your specific URL). In the left-hand navigation bar, click **Zones**. + +![](/media/articles/private-cloud/zones/zones-1.png) + +In the top-right corner, click **Create Zone**. Auth0 will create for you a new, inactive zone. + +![](/media/articles/private-cloud/zones/zones-2.png) + +Click on the downward pointing arrow to reveal the zones creation screen. You'll be asked to provide a **Name** for the zone, as well as the nodes you want to be **Members** of the zone. + +![](/media/articles/private-cloud/zones/zones-3.png) + +Once you provide a **Name** and indicate the **Members** of the zone, you can click **Save Zones** to persist your changes. Your zone remains inactive until you switch the toggle to **Active** (only one zone may be active at any given time). + +![](/media/articles/private-cloud/zones/zones-4.png) + +Once you have a zone created, you will see a new drop-down menu in the left-hand navigation bar. + +![](/media/articles/private-cloud/zones/zones-6.png) + +This new drop-down menu allows you to switch between zones for configuration. + +![](/media/articles/private-cloud/zones/zones-5.png) + +## Configure zones + +To change the configuration for your zone, go to **Cloud Resources** using the left-hand navigation bar. + +Recall that the drop-down menu on the left-hand navigation bar allows you to switch between zones for configuration. Make sure that this area shows the zone for which you are adjusting the configuration. + +![](/media/articles/private-cloud/zones/zones-7.png) + +Once you've made sure that you're adjusting the settings for the correct zone, you can change the **Credentials**, information about the **PostgreSQL instance**, and **Listener** information. + +### Configuration notes + +By default, the **Base Configuration**, which contains the configuration parameters all nodes that don't belong to a zone get, is propagated to all nodes and is the default selection. + +Any changes you make to the configuration when you have a specific zone selected will be propagated **only to the nodes that are members of that zone**. + +When working with zones, modify parameters on a per-zone basis. Any parameters that are shared between multiple nodes should be specified at the Base Configuration level. + +### A configuration example + +If your **Base Configuration** for your PostgreSQL instance is: + +```code +PostgreSQL: + **host**: foo.bar + **username**: auth0 + **password**: password +``` + +And you change, for a given zone, the **host**: + +```code +PostgreSQL: + **host**: bar.baz +``` + +Then the specific configuration applied to a node that's a member of the zone is: + +```code +PostgreSQL: + **host**: bar.baz + **username**: auth0 + **password**: password +``` diff --git a/fr-ca/articles/private-cloud/onboarding/index.md b/fr-ca/articles/private-cloud/onboarding/index.md new file mode 100644 index 0000000000..d3dbb390a2 --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/index.md @@ -0,0 +1,13 @@ +--- +section: private-saas-deployment +description: Onboarding +topics: private-cloud +contentType: concept +useCase: private-saas-deployment +--- +# Onboarding + +To provide clarity around the onboarding and implementation processes for the Private SaaS Deployment options, Auth0 has created the following documentation: + +* [Private Cloud](/private-saas-deployment/onboarding/private-cloud) +* [Managed Private Cloud](/private-saas-deployment/onboarding/managed-private-cloud) \ No newline at end of file diff --git a/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/index.md b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/index.md new file mode 100644 index 0000000000..68f9de8246 --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/index.md @@ -0,0 +1,85 @@ +--- +section: private-cloud +description: Overview of the Private Cloud onboarding process +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Managed Private Cloud Onboarding + +This article will cover all facets of the **Managed Private Cloud** (both Auth0-hosted and customer-hosted) onboarding process, including timelines, information about future updates, technical requirements, and implementation instructions for key Managed Private Cloud features. + +::: note +If you are a Private Cloud customer, please see [Private Cloud Onboarding](/private-cloud/onboarding/private-cloud). +::: + +## Timeline + +After your purchase of the Managed Private Cloud, Auth0 will host a **kickoff meeting** with you to begin the implementation process. We strongly recommend that this meeting occur no later than **five (5) days** after the contract signing. + +### Auth0-Hosted Managed Private Cloud + +Implementation begins immediately after the kickoff meeting, and the process takes **two (2) weeks**. At this point, you're ready for the **Environment Handover**, where your Private Cloud deployment is ready for Production use. + +### Customer-Hosted Managed Private Cloud + +Implementation begins immediately after the kickoff meeting, and the process takes between **three (3) to four (4) weeks**. The specific amount of time required is highly dependent on the amount of time you need to provision your infrastructure per Auth0 requirements. + +At the end of the implementation process, you're ready for the **Environment Handover**. Your Managed Private Cloud deployment is, at this point, ready for Production use. + +## Infrastructure + +Customers hosting Auth0 using Amazon Web Services should review the [infrastructure requirements](/private-cloud/onboarding/managed-private-cloud/infrastructure), as well as the [IP/Domain and Port List](/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list) required for Private Cloud deployments. + +## Updates + +Auth0 provides monthly releases to the Managed Private Cloud, of which the four most recent are considered *active*. Updating to an active release is mandatory and ensures that you receive: + +* The latest features +* Security fixes and enhancements +* Bug fixes + +Auth0 will reach out to you to coordinate the specific dates and times during which updates are applied to your deployment. + +The [Private Cloud Release Notes](https://auth0.com/releases/) will contain full details on the changes made to your deployment. + +## Custom domains + +See [Custom Domains](/custom-domains) for instructions on how to map your tenant domain to a custom domain of your choosing, as well as how to manage the required certificates. + +If you are a customer-hosted Managed Private Cloud customer using the legacy custom domains feature, you will need to migrate your custom domains to the Auth0 Custom Domains feature. Please consult Auth0 for additional assistance. + +## Tenant logging + +Auth0 provides [logs](/logs) that are accessible via the Dashboard of the Management API's [`logs` endpoint](/api/v2#!/Logs/get_logs). + +You can also choose to send the data logged by Auth0 to an external service. To help with this, there are Auth0 extensions that support automatic log export to services like Sumo Logic or Loggly. The following is a list of Auth0 log export extensions currently available: + +* [Auth0 Logs to Application Insights](/extensions/application-insight) +* [Auth0 Logs to Azure Blob Storage](/extensions/azure-blob-storage) +* [Auth0 Logs to Loggly](/extensions/loggly) +* [Auth0 Logs to Papertrail](/extensions/papertrail) +* [Auth0 Logs to Sumo Logic](/extensions/sumologic) +* [Auth0 Logs to Splunk](/extensions/splunk) +* [Auth0 Logs to Logstash](/extensions/logstash) +* [Auth0 Logs to Mixpanel](/extensions/mixpanel) +* [Auth0 Logs to Logentries](/extensions/logentries) + +## Rate limits + +To ensure the quality of Auth0's services, the APIs are subject to rate limiting. + +## Support + +You can reach out to the Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) team with any questions or concerns you might have. To help expedite your request, please provide as much information as possible in the [Support ticket you open](/support/tickets). + +## Remote Access Options + +The Managed Private Cloud requires regular access by our Managed Services Engineering team to install patches, updates, and upgrades, troubleshoot and fix issues, and optimize security and performance. See [Remote Access Options](/private-cloud/onboarding/managed-private-cloud/remote-access-options) for information on the options available. + +## Create Dashboard administrators + +To create additional Dashboard administrators, an *existing* administrator must reach out to Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) requesting that an additional administrative account be made. Please include in your request: + +* The name(s) of the tenant(s) for which the new administrator should have access +* The email addresses of those to be invited diff --git a/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md new file mode 100644 index 0000000000..ad68965f76 --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md @@ -0,0 +1,137 @@ +--- +section: private-cloud +description: Infrastructure requirements for the customer-hosted Managed Private Cloud +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Infrastructure Requirements for the Customer-Hosted Managed Private Cloud + +If you are a Managed Private Cloud customer hosting Auth0 using Amazon Web Services, the following are the requirements you should be aware of when setting up your cloud environment. + +## Choosing your AWS regions + +The AWS Region(s) in which your deployments are hosted must support: + +* At least **three (3)** availability zones +* Cross-LAN availability zones +* M4 or M4 instance types +* RDS for PostgreSQL + +## AWS instance types + +The size of your AWS instance must be, at minimum, **M4.2xlarge**, though the **M5.2xlarge** size is preferred. + +We ask that the individual volumes have the following resource allocation: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
System / Operating SystemDatabaseUser SearchBackup
a0-1 (PROD)60 GB100 GB100 GB--
a0-2 (PROD)60 GB100 GB100 GB--
a0-3 (PROD)60 GB100 GB100 GB100 GB
DEV (non-PROD)60 GB50 GB50 GB50 GB
+ +Please note that you may have a different number of instances based on your specific deployment type. + +## Network + +All servers in the cluster must: + +* Have outbound access +* Be on the same subnet +* Be able to communicate over ports 7777, 27017, 8721, and 8701 +* Listen for and accept traffic from the load balancer over ports 443 and 4443 + +For a complete listing of IP addresses and ports used, see the [IP/Domain and Port List](/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list). + +## Internet connectivity + +Internet connectivity is required for all servers in the cluster. + +All servers in the cluster require outbound access to: +* **docker.it.auth0.com** (**52.9.124.234**) on port 443. +* **cdn.auth0.com** on port 443. +* Social providers and third-party APIs (as needed) + +## DNS records + +Each environment (e.g., Development, Staging, Production), which are represented by ``, requires a separate namespace when it comes to DNS records. + +You will need DNS records for the following namespaces: + +| **Namespace/Environment | Notes | +| - | - | +| **Auth0 environment Namespace** (e.g., `*..customer.com`)| You can choose to use a catch-all CNAME record that represents all of your tenants and Dashboard endpoints **or** individual CNAME records for each tenant. The following `env-names` cannot be used: **manage** (reserved for the Dashboard), **config** (reserved for the root tenant authority), **webtask** (reserved for extensibility) | +| **Auth0 Webtask with Dedicated Domains Namespace** (e.g., `*.wt..customer.com`) | You can choose to use a catch-all CNAME record to represent all of your tenants **or** you can use an individual CNAME record for each tenant pointing to the balanced endpoint | +| **Custom Domains Namespace** | Requires a catch-all CNAME record redirecting custom domains to the custom domains balanced endpoint **and** an alias record using `edge..customer.com ` that points to the custom domains balanced endpoint | + +## Load balancers + +You must use either an ALB or ELB. For HTTP health check monitoring, you can use the `testall` endpoint provided by Auth0. + +### Software Load Balancers + +You can use either NGINX or HA Proxy as the software load balancer in front of the Auth0 environment or for IP whitelisting and/or endpoint filtering (only authentication endpoints are publicly available). If you are using NGINX or HA Proxy as the software load balancer, you must: + +* Use TCP mode with Proxy Protocol or HTTPS mode (SSL offloading). In HTTPS mode the connector will not work. +* Forward the incoming hostname to the nodes + +## SSL Certificates + +Your SSL certificates must: + +* Be signed by a public certificate authority +* Contain all of the required DNS names (if the certificate is not a wildcard certificate) +* Be in the PFX or PKCS12 formats +* Contain the full chain + +## TLS + +Auth0 requires TLS 1.1 or later. + +## SMTP + +You must set up and configure a SMTP provider (or a global default email provider) to send emails. Optionally,, you can set up transactional email providers (e.g., SendGrid, Amazon SES, Mandrill) for individual tenants. + +STARTTLS is supported by Auth0, but is not required. + +## Amazon RDS for PostgreSQL + +Amazon RDS for PostgreSQL is currently used to support the Authorization Roles-Based Access Control functionality, but it will be used to support other functionality in the future. + +We ask that, at minimum, you use **postgres10, db.r3.xlarge** with 10 GB of storage. You should also allow automated snapshots with seven-day snapshot retention and multi-AZ deployments with automated failover. + +## Remote Access + +Forthcoming. \ No newline at end of file diff --git a/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md new file mode 100644 index 0000000000..a86e9c3097 --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md @@ -0,0 +1,201 @@ +--- +section: private-cloud +description: Infrastructure requirements for the customer-hosted Managed Private Cloud +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Private Cloud IP/Domain and Port List + +Private Cloud deployments require certain ports within the cluster to be open and able to communicate with one another, as well as selected external sites. + +## Between Cluster Nodes + +When possible, instances within a cluster should have full connectivity to each other so that you do not need to introduce new firewall rules if Auth0 adds new features. However, since this isn't possible in every environment, the following table lists the ports that are required to be open and accessible to other Private Cloud instances in the same cluster: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PortUseRequired?Notes
27017DatabaseYes
7777ControlYes
9001Rate LimitingYesRequired if rate limiting is used
8721Webtask Logging/ControlYesRequired for logging and debugging
8701Webtask Logging/ControlYesRequired for logging and debugging
9200, 9300-9400Elastic SearchYesRequired for Elastic Search
3000Grafana instrumentationNoRequired if you are using Grafana instrumentation
22MaintenanceNoEnables maintenance tasks to be done between nodes
ICMPHealthcheckNoAllows healthchecks between nodes
+ +## External Connectivity + +Auth0 strives to keep these IP addresses stable, though this is not a given. From time to time, Auth0 may add IP addresses or additional servers. During updates and metrics, you must allow your Private Cloud instances to connect to these addresses. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
UseDirectionIP/DNSPortNotesRequired?
AllInboundYour load balancer IP address (often on internal network)80/(443 or 4443)For clusters with more than one node, a load balancer is required for resiliency and performanceYes
WebtaskOutboundYour load balancer IP address (often on internal network)443Allows rules, webtasks, and extensions to call back to Auth0 endpointsYes
Command Line InterfaceInbound and OutboundCLI Applications (often on the internal network)10121Allows use of the Private Cloud Command Line InterfaceNo
UpdatesOutboundapt-mirror.it.auth0.com (52.8.153.197)443Provides update packages for Private Cloud deploymentsYes
UpdatesOutbounddocker.it.auth0.com (52.9.124.234)443Provides updates for Private Cloud Docker PackagesYes
Web extensions, Hooks, and Management DashboardOutboundcdn.auth0.com443Required to run web extensions and Hooks; also required for admins to browse to the Management DashboardYes
ExamplesOutboundgithub.com443Source to download and repackage example applicationsNo
Usage & TelemetryOutboundapp-gateway.it.auth0.com (52.40.103.203)443Provides usage and telemetry statisticsYes
MaintenanceInboundJump Host22Allows access to Private Cloud instances for support purposesNo
Healthcheck InboundMonitoring Endpoint9110Allows access to Healthcheck endpointsNo
DNSInbound and OutboundLocal domain servers53Required by the Private Cloud deployment to resolve host names internal and external to your environmentYes
SMTPOutboundSMTP Server(s)25/587Allows sending of emails from the Private Cloud deploymentNo
+ +## Notes + +* If you are using social providers for logins, the cluster must be able to connect to the social providers' endpoints. +* The Jump Host IP is stable and provided at the time of setup. diff --git a/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md new file mode 100644 index 0000000000..ecc40318ff --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md @@ -0,0 +1,56 @@ +--- +section: private-cloud +description: Remote access options for the Managed Private Cloud +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Remote Access Options for the Managed Private Cloud + +This article covers the remote access options available to you as a Managed Private Cloud customer. + +The Managed Private Cloud requires regular access by our Managed Services Engineering team to install patches, updates, and upgrades, troubleshoot and fix issues, and optimize security and performance. + +::: panel Jumphost +A Jumphost is a security-hardened virtual machine (VM) that acts as a secure communication relay using SSH. The Jumphost initiates the connection from an Auth0 (using a whitelisted IP address) to the Managed Private Cloud VMs. (You would open access to the Jumphost to allow Auth0 access when necessary). + +Auth0's connections originate from a VPN-secured network using public key access to your Jumphost so that only authorized Managed Service Engineers can access connect to your environment. +::: + +## Option 1: Jumphost + Firewall Whitelist + +In this configuration, an external Auth0-managed Jumphost is permitted sole SSH management access to the Managed Private Cloud. + +![](/media/articles/private-cloud/one-jumphost.png) + +*Benefits*: + +* Jumphost provides a single point of access and auditing +* Auth0 handles tasks related to auditing, session recording, VPN access to Jumphost, and Identity Management +* Access could be disabled via firewall rules or security groups + +## Option 2: Two Jumphosts + +Similar to [option 1](#option-1-jumphost--firewall-whitelist), this configuration permits an external Auth0 Jumphost to connect via firewall whitelist to an internal, customer-managed Jumphost. This second Jumphost then provides actual access to the Managed Private Cloud nodes. + +![](/media/articles/private-cloud/two-jumphosts.png) + +*Benefits*: + +* Jumphost provides a single point of access and auditing +* Auth0 handles tasks related to auditing, session recording, VPN access to Jumphost, and Identity Management +* Disabling Auth0 access is as simple as shutting down a server +* Can be installed in DMZ (if necessary) + +*Concerns*: + +* Additional virtual Jumphost required in your infrastructure + +## Unsupported configurations + +Auth0 does not support other remote access options, such as VDI or Screen Sharing mechanisms. The alternative options introduce compliance concerns, including (but not limited to): + +* Not being able to internally audit connections and SSH sessions +* Not being able to enforce identity management on Auth0 employee accounts +* Potential exposure to untrusted systems running non-standard software (from where the connections are generated to Auth0 VMs) +* Inability to verify the identity of participants on the other end diff --git a/fr-ca/articles/private-cloud/onboarding/private-cloud.md b/fr-ca/articles/private-cloud/onboarding/private-cloud.md new file mode 100644 index 0000000000..807ed16c83 --- /dev/null +++ b/fr-ca/articles/private-cloud/onboarding/private-cloud.md @@ -0,0 +1,63 @@ +--- +section: private-cloud +description: Overview of the Private Cloud onboarding process +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Private Cloud Onboarding + +This article will cover all facets of the **Private Cloud** onboarding process, including timelines, information about future updates, technical requirements, and implementation instructions for key Private Cloud features. + +::: note +If you are a **Managed** Private Cloud customer, please see [Managed Private Cloud Onboarding](/private-cloud/onboarding/managed-private-cloud). +::: + +## Timeline + +After your purchase of the Private Cloud, Auth0 will host a **kickoff meeting** with you to begin the implementation process. We strongly recommend that this meeting occur no later than **five (5) days** after the contract signing. + +Implementation begins immediately after the kickoff meeting, and the process takes **two (2) weeks**. At this point, you're ready for the **Environment Handover**, where your Private Cloud deployment is ready for Production use. + +## Updates + +Auth0 will issue monthly updates to the Private Cloud automatically. The [Private Cloud Release Notes](https://auth0.com/releases/) will contain full details on the changes made to your deployment. + +::: note +The four most recent Private Cloud releases are considered to be the **Active Releases**. +::: + +## Custom domains + +See [Custom Domains](/custom-domains) for instructions on how to map your tenant domain to a custom domain of your choosing, as well as how to manage the required certificates. + +## Tenant logging + +Auth0 provides [logs](/logs) that are accessible via the Dashboard of the Management API's [`logs` endpoint](/api/v2#!/Logs/get_logs). + +You can also choose to send the data logged by Auth0 to an external service. To help with this, there are Auth0 extensions that support automatic log export to services like Sumo Logic or Loggly. The following is a list of Auth0 log export extensions currently available: + +* [Auth0 Logs to Application Insights](/extensions/application-insight) +* [Auth0 Logs to Azure Blob Storage](/extensions/azure-blob-storage) +* [Auth0 Logs to Loggly](/extensions/loggly) +* [Auth0 Logs to Papertrail](/extensions/papertrail) +* [Auth0 Logs to Sumo Logic](/extensions/sumologic) +* [Auth0 Logs to Splunk](/extensions/splunk) +* [Auth0 Logs to Logstash](/extensions/logstash) +* [Auth0 Logs to Mixpanel](/extensions/mixpanel) +* [Auth0 Logs to Logentries](/extensions/logentries) + +## Rate limits + +To ensure the quality of Auth0's services, the APIs are subject to rate limiting. + +## Support + +You can reach out to the Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) team with any questions or concerns you might have. To help expedite your request, please provide as much information as possible in the [Support ticket you open](/support/tickets). + +## Create Dashboard administrators + +To create additional Dashboard administrators, an *existing* administrator must reach out to Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) requesting that an additional administrative account be made. Please include in your request: + +* The name(s) of the tenant(s) for which the new administrator should have access +* The email addresses of those to be invited \ No newline at end of file diff --git a/fr-ca/articles/private-cloud/standard-private-cloud/index.md b/fr-ca/articles/private-cloud/standard-private-cloud/index.md new file mode 100644 index 0000000000..39b3ccb2c8 --- /dev/null +++ b/fr-ca/articles/private-cloud/standard-private-cloud/index.md @@ -0,0 +1,14 @@ +--- +section: private-cloud +description: Overview of the Private Cloud deployment option +topics: private-cloud +contentType: concept +useCase: private-cloud +--- +# Private Cloud + +Auth0's **Private Cloud** option provides you with a dedicated (or single-subscriber) environment. You'll get enhanced performance, security, and compliance over what we include in our standard Public Cloud offering. + +With the Private Cloud, Auth0 will handle a majority of the requirements for initial setup and maintenance. Afterward, you'll be on a set update pattern, typically no more frequent than every 30 days. + +You'll get the ease of management that comes with using our Public Cloud combined with the power and security of our [Managed Private Cloud](/private-cloud/managed-private-cloud). diff --git a/fr-ca/articles/product-lifecycle/index.md b/fr-ca/articles/product-lifecycle/index.md new file mode 100644 index 0000000000..c2e91485da --- /dev/null +++ b/fr-ca/articles/product-lifecycle/index.md @@ -0,0 +1,38 @@ +--- +toc: true +classes: topic-page +title: Product Lifecycle +description: Learn about the Auth0 product lifecycle, including product release stages, deprecations, end-of-life, the migration process, and active migrations. +topics: + - deprecations + - migrations + - product-lifecycle +contentType: + - index + - reference +useCase: + - migrate +--- + +
+
+

Product Lifecycle

+

+ We apply an iterative approach to product delivery, including an iterative product release lifecycle that allows us to introduce and improve upon new functionality. +

+
+ +When building Auth0 products, we resolve to + +* deliver value to customers early and often, iterating based on their feedback +* seek a deep understanding of our customers and consider them in every decision +* relentlessly acquire and analyze data, so we can make better choices +* visualize and design for current, idealized, and future versions of our whole product when adding features + +To best serve these goals, we apply an iterative approach to product delivery, including an iterative product release lifecycle that allows us to introduce and improve upon new functionality. + +<%= include('../_includes/_topic-links', { links: [ +'product-lifecycle/product-release-stages', +'product-lifecycle/migration-process', +'product-lifecycle/migrations', +] }) %> diff --git a/fr-ca/articles/product-lifecycle/migration-process.md b/fr-ca/articles/product-lifecycle/migration-process.md new file mode 100644 index 0000000000..8443e5a533 --- /dev/null +++ b/fr-ca/articles/product-lifecycle/migration-process.md @@ -0,0 +1,41 @@ +--- +toc: true +title: Migration Process +description: Learn about the migration process at Auth0, including End of Life announcements, migration windows, and migration guides. +topics: + - migrations + - product-lifecycle + - breaking-changes +contentType: + - reference +useCase: + - migrate +--- + +# Migration Process + +To keep our platform stable and secure, we must occasionally modify or remove features or behaviors. These changes will sometimes result in a breaking change. + +When we must introduce a breaking change, we first deprecate the affected feature or behavior and announce the Deprecation to our customers. When a new Deprecation is announced, customers should engage in a Migration to move away from the deprecated feature or behavior. + +For a list of all Deprecations with active Migrations, see [Active Migrations](/product-lifecycle/migrations). + +To learn more about Auth0 product release stages, see [Product Release Stages](/product-lifecycle/product-release-stages). + +## End of Life announcement + + When we announce a Deprecation, we typically include the date that the feature or behavior will be moved into the End of Life product release stage and removed from the platform. In some cases, we will immediately deprecate a feature to prevent further adoption and will determine the End of Life date at a later time. End of Life dates can vary between plan types. + +## Migration window + +When we make an End Of Life announcement, we will also open a migration window to allow customers to prepare for the End of Life date. + +Whenever possible, we provide at least a six-month migration window between the End Of Life announcement and the End Of Life date. In case of emergency (for example, critical vulnerabilities that require remediation or changes required by applicable law or third-party certification standards), we may accelerate this time frame. In such cases, we will provide as much prior notice as is reasonable under the circumstances. + +## Migration guides + +Auth0 Deprecations usually involve replacing deprecated behavior with substantially comparable functionality (although at times, we may elect to discontinue support for some functionality entirely). + +To help you migrate to the new functionality and determine the impact on your tenants, we will publish a migration guide, which will detail any necessary modifications to your application's code, inform you of any other required actions, and instruct you about how you opt in to the new behavior prior to the End of Life date. + + Once the End of Life date is reached, the new behavior will automatically be enabled for tenants that did not opt in during the migration window. \ No newline at end of file diff --git a/fr-ca/articles/product-lifecycle/migrations.md b/fr-ca/articles/product-lifecycle/migrations.md new file mode 100644 index 0000000000..253d55524d --- /dev/null +++ b/fr-ca/articles/product-lifecycle/migrations.md @@ -0,0 +1,112 @@ +--- +title: Active Migrations +description: View all Deprecations with active Migrations that may impact your tenant. +topics: + - migrations +contentType: + - reference +useCase: + - migrate +--- + +# Active Migrations + +We are actively migrating customers to new behaviors for all Deprecations listed below. Please review these carefully to ensure you've taken any necessary steps to avoid service disruption. To learn more, see [Migration Process](/product-lifecycle/migration-process). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Feature/BehaviorDeprecatedEnd Of Life DateDetails
Unpaginated Managment API v2 Request deprecation21 July 2020 (Public Cloud)26 January 2021 + After 26 January 2021, requests to the following Management API v2 endpoints will return a maximum of 50 items for Public Cloud tenants. To retrieve more items, you must include the page and per_page parameters. Beginning on 21 July 2020, Auth0 will display tenant logs and a migration toggle to help you prepare for this change. +
    +
  • GET /api/v2/clients +
  • GET /api/v2/client-grants +
  • GET /api/v2/grants +
  • GET /api/v2/connects +
  • GET /api/v2/device-crecentials (when type query parameter is used) +
  • GET /api/v2/resource-servers +
  • GET /api/v2/rules +
+ All Public Cloud tenants are affected that are created before 21 July 2020 and are actively calling affected endpoints without passing the per_page parameter for queries that can return more than 1 result. + Tenants are not affected if they are created after 21 July 2020, are not using the affected endpoints, are using the affected endpoints and passing the per_page parameter, or are making queries that always return only 1 result. +
Node.js v8 Extensibility Runtime15 April 2020TBA + The Webtask engine powering Auth0 extensibility points currently uses Node 8. Beginning 31 December 2019, Node.js v8 was no longer under long-term support (LTS). This means that critical security fixes were no longer back-ported to this version. As such, Auth0 is migrating the Webtask runtime from Node.js v8 to Node.js v12.

On 15 April 2020, we made the Node 12 runtime available for extensibility to all public cloud customers. You have been provided a migration switch that allows you to control your environment's migration to the new runtime environment.

To learn more about this migration and the steps you should follow to upgrade your implementation, see Migration Guide: Extensibility and Node.js v12. +
Instagram Connection Deprecation5 March 202031 March 2020Facebook announced that on March 31th, 2020, they will turn off the Instagram legacy APIs, and they won't provide an alternative to implement Login with Instagram
Changes in the Yahoo user profile1 March 20201 March 2020Yahoo changed the way to retrieve the user profile and the information included on it.
Management API v1October 2016 + Public Cloud: 13 July 2020
+ Private Cloud: November 2020 release
+ 		Management API v1 will reach its End of Life in the Public Cloud on July 13, 2020. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1. You may be required to take action before that date to ensure no interruption to your service. A migration guide is available to walk you through the required steps. Notifications have been and will continue to be sent to customers that need to complete this migration.
Useful Resources:
+ Management API v1 to v2 Migration Guide
+ Management API v2 documentation
+ Management API v1 documentation
+ Breaking changes
+
/oauth/ro deprecation for Passwordless Connections8 June 2017 + TBD + On June 8th 2017 we deprecated the /oauth/ro endpoint for passwordless connections. You can now implement the same functionality using the /oauth/token endpoint.
User Search v26 June 201830 June 2019User Search v2 is being deprecated and you may be required to take action before June 30, 2019. A migration guide is available to walk you through the steps required. Notifications have been and will continue to be sent to customers that need to complete this migration.
Useful Resources:
+ User Search v3
+ User Search v3 - Query Syntax
+ User Search Best Practices
+ User Search v2 to v3 Migration Guide
+
Tenant Logs Search v221 May 2019 + Free: 9 July 2019
+ Developer: 20 August 2019
+ Developer Pro: 20 August 2019
+ Enterprise: 4 November 2019 + 		To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3. Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt in for v3 during the provided grace period. See the migration guide for more information.
+ +If you have any questions, please visit the Migrations section of the [Auth0 Community site](https://community.auth0.com/c/auth0-community/Migrations) or create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}). diff --git a/fr-ca/articles/product-lifecycle/product-release-stages.md b/fr-ca/articles/product-lifecycle/product-release-stages.md new file mode 100644 index 0000000000..f663e50032 --- /dev/null +++ b/fr-ca/articles/product-lifecycle/product-release-stages.md @@ -0,0 +1,71 @@ +--- +toc: true +title: Product Release Stages +description: Learn how we stage, release, and retire product functionality. +topics: + - migrations + - product-lifecycle +contentType: + - reference +useCase: + - migrate +--- + +# Product Release Stages + +Product release stages describe how we stage, release, and retire product functionality. Product features may not progress through all release stages, and the time in each stage will vary depending on the scope and impact of the feature. + +## Early Access (Alpha) + +Early access offerings give a limited number of subscribers or customer development partners (CDPs) the opportunity to test and provide feedback on future functionality. At this stage, functionality may not be complete, but is ready for validation. + +During this stage, we work with participants to + +* confirm that functionality aligns with the intended goal +* validate that the solution is usable in practice +* elicit suggested improvement + +During this stage, our goal is to ensure that the eventual release provides the maximum value to our customers. + +When participating in an early access program, you should understand the following: + +* Functionality is under active development, so we do not yet support it for production use. +* We expect breaking changes, but will do our best to communicate them. +* The program provides a private preview available to only a limited number of select subscribers. +* Your feedback may help shape the General Availability (GA) or a subsequent release. + +Early Access offerings are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal). + +## Beta (Private or Public) + +Beta releases give subscribers time to explore and adopt new product capabilities while providing final feedback prior to a General Availability (GA) release. Functionality is code-complete, stable, useful in a variety of scenarios, and believed to meet or almost meet quality expectations for a GA release. Beta releases may be restricted to a select number of subscribers (private) or open to all subscribers (public). + +When participating in a beta release, you should understand the following: + +* Functionality is feature complete, but we do not yet support it for production use. +* Breaking changes may occur, and we will do our best to communicate them. +* Your feedback may help prioritize improvements and fixes in a subsequent release. + +Beta releases are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal). + +## General Availability + +General Availability (GA) releases are fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, we provide a period of backward compatibility in accordance with our deprecation policy and inform customers so they have time to adopt the new release. + +## Deprecation + +Deprecated features are not supported for use by new subscribers, are not actively being enhanced, and are being only minimally maintained. Tenants using the feature at the time of deprecation will continue to have access. + +Deprecation begins when we introduce new behavior that customers would experience as a breaking change without mediation and ends when the old behavior moves into the End of Life product release stage. During Deprecation, customers should engage in a migration to move away from the deprecated feature or behavior. To learn more, see [Migration Process](/product-lifecycle/migration-process). + +Although we know that deprecations can be disruptive, they are necessary to allow us to upgrade technology, improve security and quality, and continue to invest in resources that provide the most value for our customers. + +We are committed to transparency, so we try to proactively notify subscribers when deprecations result in breaking changes or cause altered use of Auth0. Additionally, we try to provide end-of-life notices with accompanying recommendations for migration and replacement capabilities where available. + +For self-service subscribers, Deprecation is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, Deprecation is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). + +## End Of Life + +Features that reach this stage are removed from the platform. Continued use of these features will likely result in errors. + +For self-service subscribers, End of Life is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, End of Life is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). \ No newline at end of file diff --git a/fr-ca/articles/protocols/index.html b/fr-ca/articles/protocols/index.html new file mode 100644 index 0000000000..18daba8d31 --- /dev/null +++ b/fr-ca/articles/protocols/index.html @@ -0,0 +1,77 @@ +--- +url: /protocols +section: articles +classes: topic-page +title: Protocols +description: Which authentication and authorization protocols Auth0 supports and how they work. +topics: + - protocols + - oauth2 + - oidc + - saml + - ws-fed + - ldap +contentType: + - index +useCase: + - add-idp +--- + +
+
+

Protocols

+

+ Which authentication and authorization protocols Auth0 supports and how they work. +

+
+ +

+ Auth0 implements proven, common and popular identity protocols used in consumer oriented web products (OAuth 2.0, OpenID Connect (OIDC)) and in enterprise deployments (SAML, WS-Federation, LDAP). +

+ +
    +
  • + OAuth 2.0 +

    + OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to resources the end-user owns. It is about resource access and sharing. +

    + +
    • +
  • + OpenID Connect +

    + OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information. At the core, OIDC is about user authentication. +

    +
    • +
  • + SAML +

    + Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. The Identity Provider authenticates users and provides to Service Providers an Authentication Assertion that indicates a user has been authenticated. +

    +
    • +
  • + WS-Federation +

    + WS-Federation is part of the larger WS-Security framework and an extension to the functionality of WS-Trust. The features of WS-Federation can be used directly by SOAP applications and web services. +

    +
    • +
  • + LDAP +

    + Lightweight Directory Access Protocol (LDAP) is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. +

    +
    • +
diff --git a/fr-ca/articles/protocols/ldap/index.md b/fr-ca/articles/protocols/ldap/index.md new file mode 100644 index 0000000000..03aaf00b10 --- /dev/null +++ b/fr-ca/articles/protocols/ldap/index.md @@ -0,0 +1,24 @@ +--- +description: Details about the LDAP protocol and how it is used by Auth0. +topics: + - protocols + - ldap +contentType: + - concept +useCase: + - development +--- + +# LDAP + +The **Lightweight Directory Access Protocol (LDAP)** is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. + +The function of LDAP is to enable access to an existing directory, like Active Directory. + +In Auth0 we use LDAP to integrate with Active Directory/LDAP through the Active Directory/LDAP Connector that you install in your network. + +For more information refer to [Active Directory/LDAP Connector](/connector). + +::: note +You can use [this endpoint proxy implementation](https://github.com/auth0/auth0-ldap-endpoint) to connect a legacy application to Auth0 using the LDAP protocol. +::: diff --git a/fr-ca/articles/protocols/oauth2/index.md b/fr-ca/articles/protocols/oauth2/index.md new file mode 100644 index 0000000000..528c308a9a --- /dev/null +++ b/fr-ca/articles/protocols/oauth2/index.md @@ -0,0 +1,171 @@ +--- +description: What is the OAuth 2.0 Authorization Framework and how it works. +toc: true +topics: + - protocols + - oauth2 + - oauth +contentType: + - concept +useCase: + - development +--- +# OAuth 2.0 Authorization Framework + +[OAuth 2.0](https://tools.ietf.org/html/rfc6749) is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. + +OAuth introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token; a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. + +::: panel Access Token Format +By default, Auth0 generates Access Tokens for [API Authorization scenarios](/api-auth) in JSON Web Token (JWT) format. JWTs contain three parts: a header, a payload, and a signature: +- The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents. +- The payload contains a set of claims, which are statements about the permissions that should be allowed, and other information like the intended audience and the expiration time. +- The signature is used to validate that the token is trustworthy and has not been tampered with. +::: + +The permissions represented by the access token, in OAuth terms are known as **scopes**. When an application authenticates with Auth0, it specifies the scopes it wants. If those scopes are authorized by the user, then the access token will represent these authorized scopes. For example, a Contacts API may accept three different authorization levels specifying the corresponding scopes: +- Reading contacts (`read:contacts`) +- Creating contacts (scope `create:contacts`) +- Deleting contacts (scope `delete:contacts`) + +For more information refer to [Scopes](/scopes). + +## OAuth roles + +In any OAuth 2.0 flow we can identify the following roles: + +- **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user. + +- **Resource Server**: the server hosting the protected resources. This is the API you want to access. + +- **Client**: the app requesting access to a protected resource on behalf of the Resource Owner. + +- **Authorization Server**: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0. + +## Protocol flow + +We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (called authorization grant types) that you can use. For now we will have a more generic look into the flow. + +![Generic OAuth Flow](/media/articles/protocols/oauth2-generic-flow.png) + +1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources. + +1. Provided that the Resource Owner authorizes this access, the Application receives an **Authorization Grant**. This is a credential representing the Resource Owner's authorization. + +1. The Application requests an **Access Token** by authenticating with the Authorization Server and giving the Authorization Grant. + +1. Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application. + +1. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token. + +1. Provided that the Access Token is valid, the Resource Server serves the Application's request. + +## Authorization grant types + +The [OAuth 2.0 Authorization Framework specification](https://tools.ietf.org/html/rfc6749) defines four flows to get an Access Token. These flows are called **grant types**. Deciding which one is suited for your case depends mostly on the type of your application. + +- [Authorization Code](/flows/concepts/auth-code): used by Web Apps executing on a server. This is also used by mobile apps, using the [Proof Key for Code Exchange (PKCE) technique](/flows/concepts/auth-code-pkce). + +- [Implicit](/flows/concepts/implicit): used by JavaScript-centric apps (Single-Page Applications) executing on the user's browser. + +- [Resource Owner Password Credentials](/api-auth/grant/password): used by trusted apps. + +- [Client Credentials](/flows/concepts/client-credentials): used for machine-to-machine communication. + +The specification also provides an extensibility mechanism for defining additional types. + +For details on how each grant type works and when it should be used refer to [API Authorization](/api-auth). + +## OAuth endpoints + +OAuth 2.0 utilizes two endpoints: the **Authorization** endpoint and the **Token** endpoint. + +### Authorization endpoint + +The Authorization endpoint is used to interact with the resource owner and get the authorization to access the protected resource. To better understand this, imagine that you want to log in to a service using your Google account. First, the service redirects you to Google in order to authenticate (if you are not already logged in) and then you will get a consent screen, where you will be asked to authorize the service to access some of your data (protected resources); for example, your email address and your list of contacts. + +The request parameters of the Authorization endpoint are: +- `response_type`: Tells the authorization server which grant to execute. Refer to the [How Response Type Works paragraph](#how-response-type-works) for details. +- `client_id`: The id of the application that asks for authorization. +- `redirect_uri`: Holds a URL. A successful response from this endpoint results in a redirect to this URL. +- `scope`: A space-delimited list of permissions that the application requires. +- `state`: An opaque value, used for security purposes. If this request parameter is set in the request, then it is returned to the application as part of the `redirect_uri`. + +#### How response type works + +This endpoint is used by the **Authorization Code** and the **Implicit** [grant types](#authorization-grant-types). The authorization server needs to know which grant type the application wants to use, since it affects the kind of credential it will issue: +- For **Authorization Code** grant it will issue an authorization code (which can later be exchanged with an access token) +- For **Implicit** grant it will issue an **access token**. + +An access token is an opaque string (or a [JWT](/tokens/concepts/jwts) in an Auth0 implementation) that denotes who has authorized which permissions (scopes) to which application. It is meant to be exchanged with an access token at the [token endpoint](#token-endpoint). + +To inform the authorization server which grant type to use, the `response_type` request parameter is used as follows: + +- For **Authorization Code** grant, use `response_type=code` to include an authorization code. + +- For **Implicit** grant, use `response_type=token` to include an access token. An alternative is to set `response_type=id_token token` to include both an access token and an ID token. + +::: panel ID Token +The ID Token is a JWT that contains information about the logged in user. It was introduced by **OpenID Connect (OIDC)**. For more info, see [OpenID Connect](/protocols/oidc) and [ID Token](/tokens/concepts/id-tokens). +::: + +#### How response mode works + +The [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html) specification added a new parameter that specifies how the result of the authorization request is formatted. This parameter is called `response_mode`, it's optional and can take the following values: + +- `query`: This is the default for **Authorization Code** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri`. The response parameters are embedded in the query component (the part after `?`) of the `redirect_uri` in the `Location` header. + + For example, a response might be: + + ```text + HTTP/1.1 302 Found + Location: https://my-redirect-uri/callback?code=js89p2x1 + ``` + + Where, the `redirect_uri` is `https://my-redirect-uri/callback` and the authorization code is `js89p2x1`. + +- `fragment`: This is the default for **Implicit** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri` (which is a request parameter). The response parameters are embedded in the fragment component (the part after `#`) of the `redirect_uri` in the `Location` header. + + For example, a response might be: + + ```text + HTTP/1.1 302 Found + Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600 + ``` + + Where, the `redirect_uri` is `https://my-redirect-uri/callback`, the Access Token is `eyB...78f`, it's a Bearer token and it expires in 3600 seconds. + +- `form_post`: This response mode is defined in the [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) specification. A successful response is `200 OK` and the response parameters are embedded in an HTML form as hidden params. The `action` of the form is the `redirect_uri` and the `onload` attribute is configured to submit the form. After the HTML is loaded by the browser, a redirect to the `redirect_uri` is done. + + For example, a response might be: + + ```html + HTTP/1.1 200 OK + + Submit + +
+ + +
+ + + ``` + +- `web_message`: This response mode is defined in the [OAuth 2.0 Web Message Response Mode specification](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00). It uses HTML5 Web Messaging instead of the redirect for the Authorization Response from the Authorization Endpoint. This is particularly useful when using [Silent Authentication](/api-auth/tutorials/silent-authentication). To use this response mode you have to register your app's URL at the __Allowed Web Origins__ field of your [Application's settings](${manage_url}/#/applications/${account.clientId}/settings). + +### Token endpoint + +The Token endpoint is used by the application in order to get an [access token](/tokens/concepts/access-tokens) or a [refresh token](/tokens/concepts/refresh-tokens). It is used by all flows, except for the [Implicit Flow](/flows/concepts/implicit) (since an access token is issued directly). + +- In the [Authorization Code Flow](/flows/concepts/auth-code), the application exchanges the authorization code it got from the Authorization endpoint for an access token. + +- In the [Client Credentials Flow](/flows/concepts/client-credentials) and [Resource Owner Password Credentials Grant](/api-auth/grant/password), the application authenticates using a set of credentials and then gets an access token. + +## Keep reading + +* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) +* [API Authorization](/api-auth) +* [State Parameter](/protocols/oauth2/oauth-state) +* [Mitigate CSRF Attacks](/protocols/oauth2/mitigate-csrf-attacks) +* [Redirect Users](/protocols/oauth2/redirect-users) diff --git a/fr-ca/articles/protocols/oauth2/mitigate-csrf-attacks.md b/fr-ca/articles/protocols/oauth2/mitigate-csrf-attacks.md new file mode 100644 index 0000000000..28dc65952a --- /dev/null +++ b/fr-ca/articles/protocols/oauth2/mitigate-csrf-attacks.md @@ -0,0 +1,74 @@ +--- +title: Mitigate CSRF Attacks with State Parameters +description: Learn how to use the OAuth 2.0 state parameters against CSRF attacks. +topics: + - protocols + - oauth + - state-parameter + - csrf + - xsrf +contentType: how-to +useCase: development +--- +# Mitigate CSRF Attacks With State Parameters + +You can deny malicious requests by using the `state` parameter to hold a correlation value for verification. + +A CSRF attack can occur when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate an action instead of getting user data because the attacker has no way to see the response to the forged request. + +The state parameter helps mitigate CSRF attacks to ensure that the response belongs to a request that was initiated by the same user. For the most basic cases the state parameter should be a nonce, used to correlate the request with the response received from the authentication. + +::: note +Most modern OIDC and OAuth2 SDKs, including Auth0.js in single-page applications, handle the state generation and validation automatically. +::: + +1. Before redirecting a request to the [IdP](/identityproviders), have the application generate a random string. For example: + + ```text + xyzABC123 + ``` + +::: note +The allowed length for state is not unlimited. If you get the error `414 Request-URI Too Large` try a smaller value. +::: + +2. Store this string locally. Choose a method based on your type of application. For example: + + * For regular web apps, use a cookie or session + * For a single-page app, use local storage in the browser + * For a native app, use memory or local storage + + ```text + storeStateLocally(xyzABC123) + ``` + +3. Add the `state` parameter to the request (URL-encoding if necessary). + + ```js + // Encode the String + tenant.auth0.com/authorize?...&state=xyzABC123 + ``` + + After the request is sent, the user is redirected back to the application by Auth0. The `state` value will be included in this redirect. Note that depending on the type of connection used, this value might be in the body of the request or in the query string. + + ```text + /callback?...&state=xyzABC123 + ``` + +4. Retrieve the returned `state` value and compare it with the one you stored earlier. If the values match, then approve the authentication response, else deny it. + + ```js + // Decode the String + var decodedString = Base64.decode(encodedString); + if(receivedState === retrieveStateStoredLocally()) { + // Authorized request + } else { + // This response is not for us, reject it + } + ``` + +## Keep reading + +* [State Parameter Overview](/protocols/oauth2/oauth-state) +* [OAuth 2.0 Framework](/protocols/oauth2) +* [Protecting against other common threats](/security/common-threats) diff --git a/fr-ca/articles/protocols/oauth2/oauth-state.md b/fr-ca/articles/protocols/oauth2/oauth-state.md new file mode 100644 index 0000000000..4667907642 --- /dev/null +++ b/fr-ca/articles/protocols/oauth2/oauth-state.md @@ -0,0 +1,51 @@ +--- +title: State Parameter +description: Explains how to use the state parameter in authentication requests to help prevent CSRF attacks and restore state +topics: + - protocols + - oauth + - state-parameter + - csrf + - xsrf + - redirecting + - manage-users +contentType: + - concept +useCase: + - development +--- + +# State Parameter + +Authorization protocols provide a `state` parameter that allows you to restore the previous state of your application. The `state` parameter preserves some state object set by the client in the Authorization request and makes it available to the client in the response. + +## CSRF attacks + +The primary reason for using the `state` parameter is to mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery). + +When you use `state` for CSRF mitigation on the redirection endpoint, that means that within the `state` value there is a unique and non-guessable value associated with each authentication request about to be initiated. It’s that unique and non-guessable value that allows you to prevent the attack by confirming if the value coming from the response matches the one you expect (the one you generated when initiating the request). The `state` parameter is a string so you can encode any other information in it. + +The way this works is that you send a random value when starting an authentication request and validate the received value when processing the response. This requires you to store something on the client application side (in session or another medium) that allows you to perform the validation. If you receive a response with a state that does not match, you may be the target of an attack because this is either a response for an unsolicited request or someone trying to forge the response. For more information, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks). + +![Diagram of CSRF attack](/media/articles/protocols/CSRF_Diagram.png) + +::: warning +The cookie in which the `state` value is stored should be signed to prevent attackers to forge it. +::: + +## Redirect users + +You can also use the `state` parameter to encode an application state that will round-trip to the client application after the transaction completes. In this way, the application can put the user where they were before the authentication process happened. For more information, see [Redirect Users With State Parameters](/protocols/oauth2/redirect-users). + +## Limitations + +* From a security perspective, neither the request nor the response is integrity-protected so a user can manipulate them. That is true for adding a parameter to the `redirect_uri` as well. +* The allowed length for `state` is not unlimited. If you get the error `414 Request-URI Too Large`, try a smaller value. + +## Keep reading + +* [OAuth 2.0 Authorization Framework](/protocols/oauth2) +* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) +* [API Authorization](/api-auth) +* [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks) +* [Redirect Users With State Parameters](/protocols/oauth2/redirect-users) diff --git a/fr-ca/articles/protocols/oauth2/redirect-users.md b/fr-ca/articles/protocols/oauth2/redirect-users.md new file mode 100644 index 0000000000..5ccdcadfa4 --- /dev/null +++ b/fr-ca/articles/protocols/oauth2/redirect-users.md @@ -0,0 +1,63 @@ +--- +title: Redirect Users With State Parameters +description: How to redirect users with the OAuth 2.0 state parameter. +topics: + - users + - user-management + - state-parameter + - redirection +contentType: how-to +useCase: manage-users +--- +# Redirect Users with State Parameters + +You can store the application state parameter before you redirect users to authenticate so that you can redirect them back to a URL. For example, if a user intends to access a protected page in your application, and that action triggers the request to authenticate, you can store that URL to redirect the user back to their intended page after the authentication finishes. + +Use the `state` parameter to lookup and restore the previous state of your application. Generate and store a `nonce` locally (cookies/session/localstorage), along with any desired state data (like the redirect URL). Use the `nonce` as a state in the protocol message. If the returned state matches the stored nonce, accept the OAuth2 message and fetch the corresponding state data from storage. This is the approach used by Auth0.js. + +::: warning +Passing URLs in plaintext or in any predictable way is unsafe. State should always be unique and opaque to ensure that: + +* `state` can be used for defense against CSRF attacks +* your app is not vulnerable to open redirect exploits, which can lead to phishing attacks +::: + +1. Generate the `nonce` that you will use to protect against CSRF attacks as explained before. Store the `nonce` locally, using it as the key to store all the other application state like the URL where the user intended to go. For example: + + ```json + { + "xyzABC123" : { + redirectUrl: '/protectedResource', + expiresOn: [...] + } + } + ``` + +2. Authenticate the user, sending the generated `nonce` as the state. + +3. As part of the callback processing and response validation, verify that the state returned matches the `nonce` stored locally. If it does, retrieve the rest of the application state (like the `redirectUrl`). + +4. Once you complete the callback processing, redirect the user to the URL previously stored. + + Again, how you store the `nonce` and the URL or other information pertinent to the application state depends on your application's type. It can be local storage in single-page or native apps or a cookie in a regular web app. + +## Alternate method + +Alternatively, you can: + +1. Generate and store a `nonce` locally. + +2. Encode any desired `state` (like the redirect URL) along with the `nonce` in a protected message (that will need to be encrypted/signed to avoid tampering). + +3. In the response processing, unprotect the message, getting the `nonce` and other properties stored. + +4. Validate that the included `nonce` matches what was stored locally and, if so, accept the OAuth2 message. + +## Keep reading + +* [OAuth 2.0 Authorization Framework](/protocols/oauth2) +* [State Parameter](/protocols/oauth2/oauth-state) +* [Rules](/rules) +* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login) +* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) +* [API Authorization](/api-auth) diff --git a/fr-ca/articles/protocols/oidc/identity-providers/okta.md b/fr-ca/articles/protocols/oidc/identity-providers/okta.md new file mode 100644 index 0000000000..b0e4ca230e --- /dev/null +++ b/fr-ca/articles/protocols/oidc/identity-providers/okta.md @@ -0,0 +1,178 @@ +--- +description: How to configure Okta for use as an OpenID Connect identity provider. +toc: true +topics: + - protocols + - oidc + - okta +contentType: + - concept +useCase: + - development + - add-idp +--- +# Configure Okta as an OpenID Connect Identity Provider + +This article walks you through configuring Okta for use as an OpenID Connect (OIDC) identity provider. + +## 1. Create an Okta Application + +First, [log in to your Okta account](https://login.okta.com) and head to your Okta dashboard. + +Select **Applications** on the top menu. On the Applications page, click the **Add Application** button to create a new app. + +![Okta Applications Dashboard](/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png) + +On the **Create New Application** page, select the **Platform** for your application. + +![Okta Create Application Select Platform](/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png) + +Next, provide the following information for your application settings: + +Field | Description +------|------------ +Name | The name of your application. +Base URIs (optional) | The domain(s) of your application. +Login redirect URIs | This should be set to `https://${account.namespace}/login/callback`. +Group assignments (optional) | The user groups that can sign in to this application. +Grant type allowed | The grant types to enable for your application. + +::: note +The application settings fields may differ depending on the platform your choose. +::: + +![Okta Create Application Settings](/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png) + +Click **Done** to proceed. You'll be taken to the **General** page of your app. + +## 2. Get Your Client ID and Client Secret + +Go to the **General** page of your app and scroll down to the **Client Credentials** section. This section contains the **Client ID** and **Client Secret** to be used in the next step. + +## 3. Create a Custom OpenID Connection with Auth0 + +At this point, you will configure the integration from the Auth0 side. + +Auth0 supports creating custom OpenID Connections by using the [Custom Social Connections Extension](/extensions/custom-social-extensions). Follow the guide to [Setup a New Social Connection](/extensions/custom-social-extensions#set-up-a-new-social-connection) and use the following values for the connection settings: + +- __Name__: The name of the connection. Use a name that clearly identify the okta account, you are free to name the connection whatever you would like; +- __Client ID__: Use the **Client ID** you obtained in the *General* page of your application in Okta; +- __Client Secret__: Use the **Client Secret** you obtained in the *General* page of your application in Okta; +- __Authorization URL__: Set `https://{okta-account}/oauth2/v1/authorize`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application; +- __Token URL__: Set `https://{okta-account}/oauth2/v1/token`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application; +- __Scope__: The scope parameters to get the profile, as a first approach you can use `openid email profile`; +- __Fetch User Profile Script__: Use the following Script, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application. + ```javascript + function(accessToken, ctx, cb) { + request({ + url: "https://{okta-account}/oauth2/v1/userinfo", + method: "GET", + headers: { + "Authorization": "Bearer " + accessToken, + "Content-Type": "application/json" + } + }, + function(e, r, b) { + if (e) return cb(e); + if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode)); + profile = JSON.parse(b); + profile.user_id = profile.sub; + delete profile.sub; + cb(null, profile); + } + ); + } + ``` +- __Custom Headers__: Leave it empty + +Click **Save** to proceed and then continue following the instructions to enable the [connection in your applications](/extensions/custom-social-extensions#new-connection-apps). + +## 4. Create an Okta Authorization Server + +To retrieve custom claims from Okta, ensure you've set up an Okta authorization server and configured your custom claims in the authorization server settings. + +::: note +For more information on creating an Okta authorization server and adding claims, check out the [Set Up an Authorization Server](https://developer.okta.com/docs/how-to/set-up-auth-server.html) page of the Okta documentation. +::: + +Once the Okta authorization server is set up, continue with the following sections to update the [custom connection](/extensions/custom-social-extensions) you previously created for Okta. + +## 5. Get Your Okta Authorization Server Issuer URI + +[Log in](https://login.okta.com) to your Okta dashboard and select **Authorization Servers** from the **API** menu at the top. + +![Okta Dashboard API Menu](/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png) + +On the **Authorization Servers** page, locate the authorization server you created, and make note of the **Issuer URI**. The **Issuer URI** should have the following structure: + +`https://{okta-account}/oauth2/{authorization-server-id}` + +The **Issuer URI** will be used in the next step. + +## 6. Update Your Custom Okta Connection + +Visit to the [Extensions](${manage_url}/#/extensions) page on the Auth0 dashboard and click **Custom Social Connections**. + +![Manage Auth0 Extensions](/media/articles/oidc/identity-providers/okta/extensions.png) + +Next, select your custom Okta connection. In the **Settings** section, update the following fields with your **Issuer URI** and the appropriate endpoint: + +Field | Value +------|------ +Authorization URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/authorize` +Token URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/token` + +Then, scroll down to the **Fetch User Profile Script**, it should look something like this: + +```javascript +function(accessToken, ctx, cb) { + request({ + url: "https://{okta-account}/oauth2/v1/userinfo", + method: "GET", + headers: { + "Authorization": "Bearer " + accessToken, + "Content-Type": "application/json" + } + }, + function(e, r, b) { + if (e) return cb(e); + if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode)); + profile = JSON.parse(b); + profile.user_id = profile.sub; + delete profile.sub; + cb(null, profile); + } + ); +} +``` + +Update the `request.url` with your **Issuer URI** and the `/userinfo` endpoint. For example: + +```javascript +function(accessToken, ctx, cb) { + request({ + url: "https://{okta-account}/oauth2/{authorization-server-id}/v1/userinfo", + method: "GET", + headers: { + "Authorization": "Bearer " + accessToken, + "Content-Type": "application/json" + } + }, + function(e, r, b) { + if (e) return cb(e); + if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode)); + profile = JSON.parse(b); + profile.user_id = profile.sub; + delete profile.sub; + cb(null, profile); + } + ); +} +``` + +Next, click the **Try** button to test the connection. If accepted, you should see the **It Works!** confirmation page. + +## Keep reading + +* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery) +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) \ No newline at end of file diff --git a/fr-ca/articles/protocols/oidc/index.md b/fr-ca/articles/protocols/oidc/index.md new file mode 100644 index 0000000000..1c0ecdbdf1 --- /dev/null +++ b/fr-ca/articles/protocols/oidc/index.md @@ -0,0 +1,54 @@ +--- +url: /protocols/oidc +title: OpenID Connect +description: Learn about the OpenID Connect (OIDC) protocol and how it works. +topics: + - protocols + - connections + - oidc + - open-id-connect +contentType: + - index + - concept +useCase: + - development + - oidc +--- +# OpenID Connect + +OpenID Connect (OIDC) is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications. + +While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you login, and then taken back to the website. + +For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google will send back to Auth0 information about the user and the authentication performed. This information is returned in a JWT. You'll receive an Access Token and, if requested, an ID Token. + +## How it works + +Let's use the example we mentioned earlier, signing into Auth0 using your Google account, for a high level overview on how the flow works: + +1. When you choose to sign in to Auth0 using your Google account, Auth0 sends an **Authorization Request** to Google. +1. Google authenticates your credentials or asks you to login if you are not already signed in, and asks for your authorization (lists all the permissions that Auth0 wants, for example read your email address, and asks you if you are ok with that). +1. Once you authenticate and authorize the sign in, Google sends an Access Token, and (if requested) an ID Token, back to Auth0. +1. Auth0 can retrieve user information from the ID Token or use the Access Token to invoke a Google API. + +## Access Tokens + +[Access Tokens](/tokens/concepts/access-tokens) are credentials that can be used by an application to access an API. Access Tokens can be an opaque string, JWT, or non-JWT token. Its purpose is to inform the API that the bearer of this token has been granted delegated access to the API and request specific actions (as specified by the scopes that have been granted). + +## ID Tokens + +The [ID Token](/tokens/id_token) is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth, typically used for UI display. ID Tokens conforms to an industry standard (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) and contain three parts: a header, a body and a signature. + +### Claims + +JWT Tokens contain [claims](/tokens/concepts/jwt-claims), which are statements (such as name or email address) about an entity (typically, the user) and additional metadata. + +The [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) defines a set of [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). The set of standard claims include name, email, gender, birth date, and so on. However, if you want to capture information about a user and there currently isn't a standard claim that best reflects this piece of information, you can create [custom claims and add them to your tokens](/scopes/current/sample-use-cases#add-custom-claims-to-a-token). + +## Keep reading + +* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery) +* [User Profiles Returned from OIDC-Compliant Pipelines](/users/normalized/oidc) +* [OIDC Conformant Authentication Adoption Guide](/api-auth/tutorials/adoption) +* [Webinar: Intro to OpenID Connect](https://auth0.com/resources/webinars/intro-openid-connect) +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) \ No newline at end of file diff --git a/fr-ca/articles/protocols/oidc/openid-connect-discovery.md b/fr-ca/articles/protocols/oidc/openid-connect-discovery.md new file mode 100644 index 0000000000..8f2a93e9ca --- /dev/null +++ b/fr-ca/articles/protocols/oidc/openid-connect-discovery.md @@ -0,0 +1,72 @@ +--- +description: How to use OpenID Connect discovery to configure applications with Auth0. +topics: + - protocols + - oidc-discovery + - oidc +contentType: + - how-to +useCase: + - development + - configure-apps + - oidc-discovery +--- + +# Configure Applications with OpenID Connect Discovery + +Auth0 exposes OpenID Connect (OIDC) discovery documents (`https://${account.namespace}/.well-known/openid-configuration`). These can be used to automatically configure applications. + +A good example is __OpenID Connect middleware for Katana v3 (OWIN)__: + +![](/media/articles/oidc-rs256-owin/oidc-discovery.png) + +1. Install the nuget package `Microsoft.Owin.Security.OpenIdConnect` (v3.x.x) +2. Go to `App_Start\Startup.Auth.cs`, and replace your implementation with the following: + + ```cs + app.UseCookieAuthentication(new CookieAuthenticationOptions + { + AuthenticationType = CookieAuthenticationDefaults.AuthenticationType + }); + + app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions + { + Authority = "https://${account.namespace}/", + ClientId = "{YOUR_AUTH0_CLIENT_ID}", + SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType, + ResponseType = "token", + Notifications = new OpenIdConnectAuthenticationNotifications + { + // OPTIONAL: you can read/modify the claims that are populated based on the JWT + SecurityTokenValidated = context => + { + // add Auth0 Access Token as claim + var accessToken = context.ProtocolMessage.AccessToken; + if (!string.IsNullOrEmpty(accessToken)) + { + context.AuthenticationTicket.Identity.AddClaim(new Claim("access_token", accessToken)); + } + + return Task.FromResult(0); + } + } + }); + ``` + +## Use RSA algorithm for JWTs + +The OpenID Connect middleware does not support JWTs signed with symmetric keys. Make sure you configure your app to use the RSA algorithm using public/private keys: + +On the Auth0 dashboard: + +1. Go to ${manage_url}/#/applications/{YOUR_AUTH0_CLIENT_ID}/settings +2. Click on `Show Advanced Settings`. +3. Set `RS256` as `JsonWebToken Token Signature Algorithm` and click on `Save`. + +![RSA 256](/media/articles/oidc-rs256-owin/rsa256.png) + +With this setting, Auth0 will issue JWTs signed with your private signing key. Your app will verify them with your public signing key. + +## Keep reading + +* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) diff --git a/fr-ca/articles/protocols/saml/adfs.md b/fr-ca/articles/protocols/saml/adfs.md new file mode 100644 index 0000000000..1651e92e6f --- /dev/null +++ b/fr-ca/articles/protocols/saml/adfs.md @@ -0,0 +1,128 @@ +--- +description: How to Set up an Auth0 SAML Connection Against ADFS +toc: true +topics: + - saml + - adfs + - active-directory-federation-services +contentType: + - how-to +useCase: + - add-idp + - saml-adfs +--- + +# Set Up an ADFS SAML Connection + +Create a custom SAML connection to Microsoft's Active Directory Federation Services (ADFS) to get more flexibility when configuring your mappings. + +To create the custom connection, you will need to: + +1. Configure ADFS. +2. Create a SAML connection where Auth0 acts as the service provider. +3. Edit the Relying Party Trust in ADFS. +4. Enable and test your integration. + +The following sections will guide you through this process. + +## Configure ADFS + +### Add a Relying Party Trust + +See [Create a relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) for complete details. + +1. Launch your instance of ADFS and start the **Add Relying Party Trust** wizard. +2. On the **Welcome** page, choose **Claims aware** and click **Start**. +3. On the **Select Data Source** page, select **Enter data about the relying party manually** and click **Next**. +4. On the **Specify Display Name** page, provide a descriptive name for your relying party (the typical format is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`) and a brief description under **Notes**. Be sure to replace `YOUR_CONNECTION_NAME` with a unique name you will also use to create a connection in Auth0 in a [later step](#Create-a-SAML-connection-with-Auth0-as-the-service-provider). If you are unsure of the connection name at this time, you can always edit the connection name later. Click **Next**. +5. On the **Configure Certificate** page, click **Next**. (We will come back to configure the certificate later.) +6. On the **Configure URL** page, check the box for **Enable support for the SAML 2.0 WebSSO protocol**. The wizard then asks for a **Relying party SAML 2.0 SSO service URL**. For the time being, provide a placeholder URL; we will return to this step later. Click **Next**. +7. On the **Configure Identifiers** page, indicate that the **Relying party trust identifier** is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (or whatever value you used as the display name when you started using the wizard). Click **Next**. +8. On the **Choose Access Control Policy** page, select **Permit everyone** and click **Next**. +9. Review the settings you provided on the **Ready to Add Trust** page and click **Next** to save your information. If you were successful, you'll see a message indicating that on the **Finish** page. +10. Make sure that the **Configure claims issuance policy for this application** checkbox is selected, and click **Close**. + +### Edit the Claim Issuance Policy + +After you close the **Add Relying Party Trust** wizard, the **Edit Claim Issuance Policy** window appears. + +1. Click **Add Rule...** to launch the wizard. +2. Select **Send LDAP Attributes as Claims** for your **Claim rule template**, and click **Next**. +3. Provide a value for the **Claim rule name**, such as "LDAP Attributes" (it can be anything you want). +4. Choose **Active Directory** as your **Attribute Store**. +5. Map your LDAP attributes to the following outgoing claim types: + + | LDAP Attribute | Outgoing Claim | + | - | - | + | E-Mail-Addresses | E-Mail Address | + | Display-Name | Name | + | User-Principal-Name | Name ID | + | Given-Name | Given Name | + | Surname | Surname | + + ::: note + The `Name ID` outgoing claim should always be present to ensure correct session handling. We strongly recommend adding all of the claims listed above, especially `E-Mail Address`, since they are the ones most commonly used. + ::: + + You can add additional claim mappings if necessary. See [Connect Your Application to Microsoft ADFS](/connections/enterprise/adfs#add-additional-ldap-attributes) for details. + +6. Click **Finish**. +7. In the **Edit Claim Issuance Policy** window, click **Apply**. You can now exit out of this window. + +### Export the Signing Certificate + +Finally, you'll need to export the signing certificate from the ADFS console to upload it to Auth0. + +1. Using the left-hand navigation pane, go to **ADFS > Service > Certificates**. Select the **Token-signing** certificate, and right click to select **View Certificate**. +2. On the **Details** tab, click **Copy to File...**. This launches the **Certificate Export Wizard**. Click **Next**. +3. Choose **Base-64 encoded X.509 (.CER)** as the format you'd like to use. Click **Next**. +4. Provide the location to where you want the certificate exported. Click **Next**. +5. Verify that the settings for your certificate are correct and click **Finish**. + +## Create a SAML connection with Auth0 as the service provider + +1. Follow the tutorial on creating a SAML connection where [Auth0 acts as the service provider](/protocols/saml/saml-sp-generic). Where prompted, upload the signing certificate you exported from ADFS. + + The sign in and sign out URLs are usually in the form of `https://your.adfs.server/adfs/ls`. + +2. Click **Save**. A page with instructions for creating a new Relying Party Trust in ADFS appears displaying the exact values required for your Auth0 account/connection. Make a note of these values. + + Here is an example: + + | Parameter | Example Value | + | - | - | + | Post-back URL | `https:///login/callback?connection=YOUR_CONNECTION_NAME` if a [custom domain](/custom-domains) is configured | + | --- | `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` if not using custom domains | + | Entity ID | `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` | + +## Edit the Relying Party Trust + +1. In the ADFS console, go to **ADFS > Relying Party Trusts** using the left-hand navigation pane. Select the Relying Party Trust you created earlier and click **Properties** (located on the right-hand navigation pane). +2. Select the **Identifiers** tab, and populate the **Relying Party Identifier** with the **Entity ID** value from the previous screen. Be sure to click **Add** to add the identifier to your list. +3. Select the **Endpoints** tab, and select the placeholder URL you provided earlier. Click **Edit...**. +4. Populate the **Trusted URL** with the **Post-back URL** value. +5. Click **OK**. Finally, click **Apply** and exit the Properties window. + +## Optional: Enable sign requests + +Optionally, you can sign your SAML requests to the ADFS server. + +1. Go to the **Settings** page for your SAMLP Identity Provider in the Auth0 Dashboard. +2. Enable **Sign Requests**. +3. Just below the **Sign Requests** toggle is a link to download your certificate. +4. Return to ADFS and load the downloaded certificate using the **Signatures** tab of the Relying Party properties dialog. + +## Enable and test your integration + +Before you test your integration, make sure that you've completed the following steps: + +* Create a user on the IdP that you can use to test your new connection. +* [Enable your Connection](/connections) for at least one application. + +1. To test your connection, navigate to **Connections > Enterprise > SAML**. +2. Click the ADFS row (or the hamburger icon to the right to bring up a list of your SAML connections). +3. Select the one you want to test and click the **play** button to test the connection. + +## Keep reading + +* [Troubleshooting SAML Configuration](/protocols/saml/saml-configuration/troubleshoot) diff --git a/fr-ca/articles/protocols/saml/identity-providers/index.md b/fr-ca/articles/protocols/saml/identity-providers/index.md new file mode 100644 index 0000000000..6b88cd5e80 --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/index.md @@ -0,0 +1,24 @@ +--- +title: SAML Identity Providers +description: How to configure Auth0 to use other SAML Identity Providers. +classes: topic-page +topics: + - connections + - saml +contentType: + - index +useCase: customize-connections +--- + +# SAML Identity Providers + +The following articles will cover how you can configure these tools for use with Auth0 as SAML Identity Providers. + +<%= include('../../../_includes/_topic-links', { links: [ + 'protocols/saml/identity-providers/okta', + 'protocols/saml/identity-providers/onelogin', + 'protocols/saml/identity-providers/ping7', + 'protocols/saml/identity-providers/salesforce', + 'protocols/saml/identity-providers/siteminder', + 'protocols/saml/identity-providers/ssocircle' +] }) %> \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/identity-providers/okta.md b/fr-ca/articles/protocols/saml/identity-providers/okta.md new file mode 100644 index 0000000000..aa6b9c3a9b --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/okta.md @@ -0,0 +1,78 @@ +--- +title: Okta +description: How to configure Okta for use as an identity provider. +toc: true +topics: + - saml + - identity-providers + - okta +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Okta as an Identity Provider + +In this article, we will cover how you can configure Okta for use with Auth0 as a SAML Identity Provider. + +## Configure Okta + +1. Sign in to the [Okta Developer Console](https://login.okta.com). If you don't already have an Okta account, you will need to create one. +2. Use the [App Integration Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm) to add an application for use with Auth0. +3. Use Okta's [SAML App Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm#SAMLWizard) to create your SAML integration. When done, you'll be directed to the **Sign On** page for your newly-created app. Click on **View Setup Instructions** to complete the process. +4. Take note of the **Identity Provider Single Sign-On URL**, and download a copy of the X.509 certificate. + +## Configure Auth0 + +At this point, you will configure the integration from the Auth0 side. + +Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection. + +You will be prompted to provide the appropriate configuration settings for this Connection. + +The only mandatory fields are as follows: + +* **Connection Name**: a friendly name for your new Connection; +* **Sign In URL**: the **Identity Provider Single Sign-On URL** you made note of when you set up your Okta app; +* **X509 Signing Certificate**: the certificate you downloaded from Okta. You will need to upload the certificate directly to Auth0. + +Click **Save** to persist your changes and proceed. + +In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration. + +## Enable Access to the Connection + +Now that you've created and configured your Connection, you'll need to enable access to the Connection for your Application(s). + +Using the [Management Dashboard](${manage_url}), go to the [Applications](${manage_url}/#/applications) to see the list of Applications associated with your Auth0 account. + +To enable your Connection for a given Application, click **Connections** on its associated row. + +Scroll down to the *Enterprise* section, and click the slider to enable your Okta Connection for the associated Application. + +## Test your Connection + +You can test your Okta-Auth0 integration using the [Management Dashboard](${manage_url}) if you are an Okta user. + +Go to **Connections** -> **Enterprise** -> **SAML**. On the row associated with Okta, click the **play** icon to *Try* your Connection. + +If your test was successful, you'll see the **It works!** screen. If not, you'll see an error message containing details on what the issue might be. + +::: note +The **Try** button works for users logged in to Auth0 dashboard. You can't send this to an anonymous user, such as a customer. If you don't have a Okta user, you'll need to configure [IdP Initiated SignOn](#idp-initiated-signon) so the someone else can try on their portal. +::: + +## IdP Initiated SignOn + +Okta provides an Application Portal/Launcher for their users. If you would like to support the Okta Application Portal/Launcher, change the **Single Sign-on URL** in the Okta dashboard to `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` + +Be sure to change `YOUR_CONNECTION_NAME` to the name of your Auth0 Connection. + +See [IdP-Initiated SSO](/protocols/saml/idp-initiated-sso) for information on configuring your Auth0 Connection to route the incoming SAML Response. + +## Troubleshooting + +The user might see the Okta dashboard after authenticating using a Service Provider-initiated login flow. If you integrated you application with Auth0 using the OpenID Connect (OIDC) protocol, Auth0 takes the value of the `state` parameter and passes it to Okta using the SAML "RelayState" parameter. As such, make sure that you set `state` to a value that Okta can use. + +<%= include('../../../connections/_quickstart-links.md') %> diff --git a/fr-ca/articles/protocols/saml/identity-providers/onelogin.md b/fr-ca/articles/protocols/saml/identity-providers/onelogin.md new file mode 100644 index 0000000000..373d099c62 --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/onelogin.md @@ -0,0 +1,141 @@ +--- +title: OneLogin +description: How to configure OneLogin as an identity provider. +toc: true +topics: + - saml + - identity-providers + - onelogin +contentType: + - how-to +useCase: + - add-idp +--- +# Configure OneLogin as an Identity Provider + +In this article, we will cover how you can configure OneLogin for use with Auth0 as a SAML Identity Provider. + +## Step 1: Configure OneLogin + +1. Log in to the [OneLogin](https://www.onelogin.com/) Dashboard, and click **Apps** > **Add Apps**. +2. Search for **SAML**, and select **SAML Test Connector (IdP w/attr)**. +3. When prompted, change the **Display Name** of your app. Click **SAVE**. +4. Go to the **SSO** tab, and copy the values for **SAML 2.0 Endpoint (HTTP)** and **SLO Endpoint (HTTP)**. Click on the **View Details** link at the **X.509 Certificate** field. +5. Download the X.509 certificate **onelogin.pem**. + +## Step 2: Configure the connection using the Auth0 dashboard + +At this point, you will configure the integration from the Auth0 side. + +Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection. + +You will be prompted to provide the appropriate configuration settings for this Connection. + +The only mandatory fields are as follows: + +* **Sign In URL**: provide the **SAML 2.0 Endpoint (HTTP)** value you made note of when setting up your OneLogin app +* **Sign Out URL**: provide the **SLO Endpoint (HTTP)** value you made note of when setting up your OneLogin app +* **X509 Signing Certificate**: the certificate you downloaded from Onelogin. You will need to upload the certificate directly to Auth0. + +Click **Save** to persist your changes and proceed. + +In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration. + +### Auth0 configuration values + +To finish configuration of the SAML application, the admin will need the following information regarding Auth0: + +* **SAML Consumer URL**: `https://${account.namespace}/login/callback` +* **SAML Audience**: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` + +Also make sure to copy the values of the **post-back URL** and the **Entity ID** before heading back to the Configuration tab of your [OneLogin](https://www.onelogin.com/) app: + +| Auth0 value | OneLogin configuration field | +| - | - | +| Post-back URL | ACS (Consumer) URL **and** Recipient | +| Entity ID | Audience | + +You'll also need to provide a valid regular expression for the **ACS (Consumer) URL Validator** (for example, `[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)`) + +## Step 3: Test your connection + +Before testing your connection: + +* Be sure that you have a OneLogin user that you can use for testing. If not, go to the **Users** tab on the OneLogin dashboard and add one +* Be sure that your new Auth0 SAMLP connection has been associated with an [application](/application) (otherwise you will get an `invalid_request: the connection was disabled` error) + +At this point, you are set to test the connection! Next to your **SAML** connection, click the **Try** button. + +If all goes well, you will be redirected to a page informing you that the connection works. + +::: note +The **Try** button only works for users logged in to the Auth0 dashboard. You cannot provide a link to this to an anonymous user (such as a customer) for testing. + +If you don't have a OneLogin user, please read the following section on configuring IdP-Initiated Signon so that your customer can test using their portal. +::: + +## IdP-initiated sign on + +OneLogin offers an Application Portal/Launcher to their users. If you want to take advantage of this functionality, you will have to change the **SAML Consumer URL** in OneLogin dashboard to include the `connection` parameter (e.g., `https://${account.namespace}/login/callback?connection=onelogin-customer`). Be sure to replace `onelogin-customer` with the name of your Auth0 connection. + +Finally, be sure to pick the application to which your user is redirected *after* the SAML assertion is consumed. You can find more information in the [IdP-Initiated SSO page](/protocols/saml/idp-initiated-sso). + +## Edit connection mappings + +If you use OneLogin and Auth0 out of the box, users logging in using OneLogin and being created in the Auth0 dashboard will be missing some profile information you might like to have. + +To collect additional user information, you must edit the appropriate parameters in the OneLogin dashboard, include the parameters in the SAML assertion, and create the mappings in the Auth0 connection. + +### User profile attributes + +Sometimes the standard User Profile Attributes are not enough for the functionality you want to build. If this is the case, you can use custom attributes in order to enhance the SAML token. Let's work through a basic example. + +The SAML token contains, among others, two attributes: `FirstName` and `LastName`. Let's add a new custom attribute, named `FullName`, that will contain the concatenation of first and last name. + +In order to do so, navigate to the OneLogin dashboard and edit your app. + +On the __Parameters__ tab, click __Add Parameter__. + +In the pop-up, set a name for your new custom attribute using the __Field name__ text box. Make sure you check the __Include in SAML assertion__ flag. Click __Save__. + +The new attribute you created is displayed. Click on the __Value__ field, which is currently displaying `- No default -`. + +Click the __Value__ dropdown menu and select `- Macro -`. + +At the text box, set the value to `{firstname} {lastname}`. Click __Save__. + +At this point, we're ready to test our changes. + +Go back to [Auth0 dashboard > Connections > Enterprise > SAML](${manage_url}/#/connections/enterprise). On your __SAML__ connection, click the __Try__ button. The result should include the new attribute `FullName`. + +::: note +You can find more information on _Attribute Macros_ at the [OneLogin Help Center](https://support.onelogin.com/hc/en-us/articles/201174464-Attribute-macros). +::: + +### Add new parameter to the SAML assertion + +For the purposes of demonstration, let's see how we can add the `EmailAddress` information, which is more than the concatenation of two fields we're already sending, to our login. + +### OneLogin configuration + +Before you can map users' **EmailAddress**, you must add this field as a custom parameter to the OneLogin dashboard. Set **Field name** to `EmailAddress` and **Value** as `Email`. + +You can find details on the steps needed to customize the user profile [in the section above](#customize-the-user-profile). + +Once you've made your changes, save them, and test your connection once again. + +Now, review your Auth0 user, making sure that the `EmailAddress` information is now included and that the value is correct. + +### Auth0 mappings + +You are now ready to proceed with mapping the user information fields in Auth0. + +Go to the __Settings__ of your [SAML](${manage_url}/#/connections/enterprise) and navigate to the tab __Mappings__. For the email addresses, copy the mapping below, and paste it into the text box. + +```javascript +{ + "email": "EmailAddress" +} +``` + +Save your changes, and try your connection again. Once you have successfully logged in, go to [Dashboard > Users](${manage_url}/#/users), and check your login. You will see additional information for the appropriate user. \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/identity-providers/ping7.md b/fr-ca/articles/protocols/saml/identity-providers/ping7.md new file mode 100644 index 0000000000..1165cfb3d1 --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/ping7.md @@ -0,0 +1,69 @@ +--- +title: PingFederate +description: How to configure PingFederate as an identity provider. +topics: + - saml + - identity-providers + - pingfederate +contentType: + - how-to +useCase: + - add-idp +--- +# Configure PingFederate as an Identity Provider + +In this article, we will cover how you can configure PingFederate for use with Auth0 as a SAML Identity Provider. + +PingFederate is a federation server that provides identity management, single sign-on, and API security for the enterprise. To configure Auth0 to use PingFederate as an identity provider, you will use primarily the default values and your Auth0 tenant metadata file to upload the required configuration parameter values for your Auth0 tenant. If the metadata upload fails for some reason, these are the most important configuration parameters: + +* __EntityID:__ `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` +* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback` +* __Logout URL:__ `https://${account.namespace}/logout` +* __HTTP-Redirect__ binding for SAML Request +* __HTTP-POST__ binding for SAML Response + +::: panel IdP-Initiated SSO +If you want to use **IdP-Initiated SSO**, make sure to include the `connection` parameter in the Assertion Consumer Service URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`. +::: + +1. Download your Auth0 metadata file from `https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME`. Make sure that you use your custom domain if you have one configured. You will upload this file to import your Auth0 tenant information into the PingFederate configuration. + +2. Sign on to your PingFederated account and select **Create New** from the **SP Connections** section. + +3. Configure the __SP Connection__. + + - Select the __Browser SSO Profiles__ as the __Connection Type__. + - Select __Browser SSO__ as the __Connection Options__. + +4. Upload the metadata file that you downloaded in step 1. The __Entity ID__, __Connection Name__ and the __Base URL__ will be automatically populated based on the information from the metadata file. + +5. Configure __Browser SSO__. + + - Select __SP-Initiated SSO__ and __SP-Initiated SLO__ in __SAML Profiles__. + - Go to the __Assertion Creation__ section and click __Configure Assertion__. Accept all defaults for the next two screens. + +6. Go to the __IdP Adapter Mapping__ section. This is where users will be authenticated. Likely, you already have one configured in your PingFederate installation. Select one, or add a new one. + + ::: note + Auth0 only requires the __NameIdentifier__ claim. All other attributes will be passed further to the end application. + ::: + +7. Configure __Protocol Settings__. Values for __Protocol Settings__ are imported from the metadata file. Next, you will see the __Assertion Consumer Service URL__ and the Sign-Out URLs. Click __Next__ to the __Allowable SAML Bindings__ section. + +8. Leave __POST__ and __Redirect__ enabled. Make sure __SAML Assertion__ is always signed. + +9. Configure __Credentials__. On __Digital Signature Settings__, select your signing certificate and make sure you check the option to include it in the `` element. + +10. Configure the certificate used to sign incoming requests. You can download the Auth0 certificate (use `https://YOUR_TENANT.auth0.com/pem`) and upload it here. + + ::: note + Auth0 signs `SAMLRequests` by default; you can change that when you configure the connection. + ::: + +11. Review your settings and set as __Active__ or __Inactive__. + +12. Click __Save__ at the bottom of the screen. You should see the new SP Connection on the __Main__ screen. + +## Keep reading + +* See the complete PingFederate instructions to [configure PingFederate as an identity provider](https://docs.pivotal.io/p-identity/1-5/pingfederate/config-pingfederate.html). \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/identity-providers/salesforce.md b/fr-ca/articles/protocols/saml/identity-providers/salesforce.md new file mode 100644 index 0000000000..35bbe93e2b --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/salesforce.md @@ -0,0 +1,138 @@ +--- +description: How to configure Auth0 to use Salesforce as an identity provider. +topics: + - saml + - identity-providers + - salesforce +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Salesforce as an Identity Provider + +In this article, we will cover how you can configure Salesforce for use with Auth0 as a SAML Identity Provider. + +There are 6 steps to this sample: + +1. Obtain Salesforce certificate and metadata. +2. Set up Auth0 as a Service Provider. +3. Configure the Salesforce Identity Provider (IDP). +4. Grant Privileges to users in Salesforce. +5. Test the connection to the Salesforce IDP. +6. Troubleshooting + +## 1. Obtain Salesforce Certificate and Metadata + +1. Register for a [Salesforce.com](http://salesforce.com) account. You must select one of the account types that include Identity Provider support. +2. Create your [Salesforce Domain](https://help.salesforce.com/apex/HTViewHelpDoc?id=domain_name_setup.htm&language=en_US). +2. Log into your Salesforce domain `https://YOUR_DOMAIN.my.salesforce.com` and click on **Setup** on the top right. +4. In the left menu, expand **Security Controls** and select **Identity Provider**. + +5. Create an Identity Provider by clicking **Enable Identity Provider**. + +6. Select the default certificate and click **Save**. + +7. Click **Download Certificate** to download the Identity Provider certificate. + +8. Click **Download Metadata** to download the Identity Provider metadata. + +## 2. Set up Auth0 as a Service Provider + +In this step, you will configure Auth0 as a Service Provider to communicate with the **Salesforce** Identity Provider for Single Sign-on (SSO). + +1. Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard. +2. Click on **SAML** +3. Click on **Create New Connection** +4. In the configuration window, enter the following information: + + **Connection Name:** You can choose any name, such as "SFIDP". + + **Email Domains:** Enter the email domain name that your users will be logging in from. For example, if your users have an email domain of `abc-example.com`, you would enter that into this field. You can enter multiple email domains if needed. + + **Sign In URL:** Open the metaData file you downloaded from Salesforce and locate the line that contains the `SingleSignOnService` binding. The value of the `Location` attribute on this line is your Sign In URL. It will be something like: + + `https://{sf-account-name}.my.salesforce.com/idp/endpoint/HttpRedirect` + + where "{sf-account-name}" is your Salesforce account domain name. + + **Sign Out URL:** enter the same URL that was entered for Sign In URL. + + **Certificate:** The certificate downloaded from Salesforce is in .crt format. Convert this certificate to .pem format with the following command. + + `openssl x509 -in original.crt -out sfcert.pem -outform PEM` + + where `original.crt` is the filename of the downloaded .crt file. + +5. Click **UPLOAD CERTIFICATE** and select the `.pem` file you just created. (`sfcert.pem` in the example above). You can ignore the rest of the fields for now. + +6. Click **SAVE**. + +7. Click **CONTINUE**. In the window that appears, SAML metadata for the Auth0 Service Provider will be displayed. Keep this window open since you will need to enter some of this information into Salesforce to finish the configuration. + +::: note +You can always access the metadata for an Auth0 SAML connection with this URL syntax: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`. +::: + +## 3. Configure the Salesforce Identity Provider + +In this step, you will configure Salesforce with the metadata from Auth0 so it can receive and respond to SAML-based authentication requests from Auth0. + +1. Open **[salesforce.com](http://salesforce.com)**. +2. Go to **Setup** > **Manage Apps**. Click **Connected Apps**. +3. Create a new Connected App and fill out the following fields: + + **Entity ID:** `urn:auth0:${account.namespace}:YOUR_CONNECTION_NAME` + + **ACS URL:** `https://${account.namespace}/login/callback` + + **Subject Type:** `Persistent ID` + + **Name ID Format:** Choose the one with emailAddress + + **Issuer:** `https://{your-saleforce-domain}.my.salesforce.com` + +6. Click **Save** to complete the configuration of the IDP. + +## 4. Grant Privileges to Users in Salesforce + +1. Open **[salesforce.com](http://salesforce.com)** and click **Setup**. +2. Under **Manage Users**, click **Profiles**. +3. Scroll down to find the profile called **Standard User** (on page 2). +4. Click on **Edit** to edit the profile. +5. Scroll down to the **Connected App Access** section. +6. Check the box next to the name of your connected app to enable it for this profile. +7. Click **Save**. +8. Under **Manage Users**, click **Users**. +9. Click **Edit** to edit your test user and set the profile to **Standard User**. + +::: note +If you wish to use a different Salesforce profile, you must enable the connected app for that profile and ensure that all users that login through the Salesforce Identity Provider have that profile. +::: + +## 5. Test the connection to the Salesforce IDP + +In this step, you will test the SAML configuration between Auth0 and Salesforce. + +* Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard. Select the **SAMLP Identity Provider**. +* Click the **Try** button for the SAML connection you created earlier. You should be redirected from Auth0 to the Salesforce login page. +* Once you are at the **Salesforce login screen**, login with the credentials you provided when you created the Salesforce account. + +If the SAML configuration works, your browser will be redirected back to an Auth0 page that says **"It works!!!"**. This page will display the contents of the SAML authentication assertion sent by the Salesforce IDP to Auth0. + +If it didn't work, double check the steps above and consult the **troubleshooting** section below. + +::: note +The **Try** button only works for users logged into the Auth0 dashboard. +::: + +## 6. Troubleshooting + +When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction and save it in a HAR file. See [Generate and Analyze HAR Files](/troubleshoot/guides/generate-har-files) for details. + +Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace for the sequence of GETs. You should see a redirect from your original site to the IDP, a post of credentials if you had to log in, and then a redirect back to the callback URL. The HAR file will also contain the SAML response. + +Make sure that cookies and JavaScript are enabled for your browser. + +Make sure that the user's profile in Salesforce has permission to login via the Salesforce IDP (See section 4 above). diff --git a/fr-ca/articles/protocols/saml/identity-providers/siteminder.md b/fr-ca/articles/protocols/saml/identity-providers/siteminder.md new file mode 100644 index 0000000000..f8a0765b73 --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/siteminder.md @@ -0,0 +1,71 @@ +--- +title: SiteMinder +description: How to configure SiteMinder as an identity provider. +topics: + - saml + - identity-providers + - siteminder +contentType: + - how-to +useCase: + - add-idp +--- +# Configure SiteMinder as an Identity Provider + +In this article, we will cover how you can configure SiteMinder for use with Auth0 as a SAML Identity Provider. + +When configuring SiteMinder, you will use the default values for most options. However, you will need the following Auth0-related values in the configuration steps were cover later on in this guide: + +* __EntityID:__ `urn:auth0:${account.tenant}` +* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback` +* __Logout URL:__ `https://${account.namespace}/logout` +* __HTTP-Redirect__ binding for SAML Request +* __HTTP-POST__ binding for SAML Response + +The instructions below will guide you into where these values need to be entered in SiteMinder. + +### 1. Open the SAML Service Provider Dialog + +Provide an appropriate name for this Service Provider. We suggest using: + +* __Name:__ `${account.tenant}` + +### 2. Defining NameIdentifier + +You can define many ways of generating a `NameIdentifier` for users authenticating with SiteMinder. Typically you will map this value to one of the user properties in the User Directory as `uid`. + +### 3. Configure the Service Provider General SAML properties + +Use the following values when prompted: + +* __SP ID:__ `urn:auth0:${account.tenant}` +* __SAML Version:__ `2.0` +* __Skew Time:__ `30 seconds` + +### 4. Configure the Assertion Consumer Service URL + +The __Assertion Consumer Service URL__ is the location where SiteMinder will POST back the SAML Token. This Service Provider (${account.tenant}) only supports the `HTTP-POST` binding for SAML Responses. Use these values: + +* __Assertion Consumer Service:__ `https://${account.namespace}/login/callback` +* __HTTP-Post__: `checked` + +### 5. Configure additional user properties to send in the token + +Add any other properties you wish to share about the authenticated user to this Service Provider. Common values are: `name`, `lastname`, `email address`, and so on. This Service Provider will use the `NameIdentifier` defined in [step 2](#2-defining-nameidentifier) as a unique handle of the user. These attributes will be treated as reference information. + +### 6. Enter the Single Sign-Out URL + +* __SLO Location URL:__ `https://${account.namespace}/logout` + +### 7. Optional Assertion Encryption + +The Service Provider supports encryption of Assertions. +To use this option, do the following to download the Service Provider public key certificate. + +* In the Auth0 Dashboard, click on __Connections__ and then __Enterprise__ +* Click on SAMLP Identity Provider +* Click on the Setup icon (pencil) + +In the window which appears, the seventh (last) bullet gives you links to download the .pem or .cer format certificate. + +Download the desired certificate and add it to the SiteMinder __Policy Server Keystore__. \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/identity-providers/ssocircle.md b/fr-ca/articles/protocols/saml/identity-providers/ssocircle.md new file mode 100644 index 0000000000..b5b1f0448e --- /dev/null +++ b/fr-ca/articles/protocols/saml/identity-providers/ssocircle.md @@ -0,0 +1,188 @@ +--- +title: SAML Single Sign-On with SSOCircle as an Identity Provider +description: Learn how to configure an application to use Auth0 for SAML Single Sign-on (SSO), authenticating users against SSOCircle +toc: true +topics: + - saml + - identity-providers + - ssocircle +contentType: + - how-to +useCase: + - add-idp +--- +# Configure SSOCircle as an Identity Provider + +In this article, we will cover how you can configure SSOCircle for use with Auth0 as a SAML Identity Provider. + +::: warning +As of July 8, 2016, SSOCircle supports integration via [manual configuration using public settings](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration/). If you have previously used account-specific metadata, your integration will still function, though this usage is now deprecated. +::: + +## 1. Obtain the SSOCircle Metadata + +Navigate to [SSOCircle's IDP page](https://idp.ssocircle.com/) to see the metadata required for integration. You will be shown an XML file. + +From this page, you will need to save the following attributes (you will use these values for Step 2 of this tutorial): + +1. The Location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type. + +2. The Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type. + +[Download](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration) and save the SSOCircle CA Certificate. You will also use this in Step 2. + +## 2. Configure an enterprise connection in Auth0 + +In this step, you will configure the integration from the Auth0 side. + +To do so, see [Connect Your App to SAML Identity Providers](/connections/enterprise/saml). + +While setting up your connection, make sure you use the following settings: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **IdP Domains** (optional) | Comma-separated list of valid domains. Only needed if using the Lock login widget. | +| **Sign In URL** | SAML single login URL. Enter the location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. | +| **X.509 Signing Certificate** | Signing certificate (encoded in PEM or CER). Upload the **SSOCircle CA Certificate** you saved in [step 1](#1-obtain-the-ssocircle-metadata). | +| **Sign Out URL** (optional) | SAML single logout URL. Enter the Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. | + +When setting up mappings, use the following JSON to properly map SAML attributes from SSO Circle, and click **Save**: + +```json +{ + "email": "EmailAddress", + "given_name": "FirstName", + "family_name": "LastName" +} +``` + +::: note +In general, you can access the metadata for an Auth0 SAML connection using a URL with the following format: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`. + +You will need to provide this metadata to SSOCircle at a later point during the configuration process. +::: + +## 3. Configure the SSOCircle Identity Provider + +In this step, you will configure the integration from the SSOCircle side. + +Log in to your [SSOCircle](http://ssocircle.com) account. You will be directed to your user profile, and to the left of that is a navigation bar. + +In the navigation bar, click **Manage Metadata**. + +Select **Add New Service Provider**, and provide the following information to configure the new service provider (which, in this case, is Auth0): + +* **FQDN of the ServiceProvider:** `auth0.com` +* **Attributes to send in assertion:** check the box for `EmailAddress` +* **Insert your metadata information:** paste in the XML metadata that you downloaded after you configured your Auth0 Connection (the file begins with `callback URLs includes those to which users will be redirected after authentication. The URL(s) entered here must match the **callback URL** in the HTML code you will create in a later step. Normally, you would enter a URL for your Application, but to keep this example simple, users will simply be sent to the Auth0 JWT Tool. + +Click **SAVE CHANGES**. + +Returning to the top of **Settings**, click on **Connections**. + +Scroll down to the section with the **Enterprise** heading. Find the row for the SAML Connection you created above and click the on/off toggle to enable the SAML Connection. + +## 5. Test the Auth0-SSOCircle Connection + +In this step, you will test to make sure the SAML configuration between Auth0 and SSOCircle is working. + +To test your connection, see [Test Enterprise Connections](/dashboard/guides/connections/test-connections-enterprise). + +During this process you will be asked to log in and consent. Everything should go smoothly, but if the test shows that something didn't work, please review the above steps and consult the [Troubleshooting](#8-troubleshooting) section. + +Additionally, if you receive a window that says, "Your session has timed out," click the **Return to Login page** link below the message. + +## 6. Create the HTML Page for the Test Application + +In this section, you will create a simple HTML page that uses the **Auth0 Lock Widget**. Lock will then trigger the SAML login sequence. + +```html + + + +

Click on the button to log in

+ + + + + + +``` + +Be sure to fill in the first parameter of the `Auth0Lock` with your Client ID. To find the Client ID, go to **[Auth0 Dashboard](${manage_url}) > [Applications](${manage_url}/#/applications)** and click the **Settings** icon to the right of your Application name. Copy the **Client ID** value. + +Save this file. For the purposes of this example, we'll call it `hello-saml.html`. + +## 7. Test Your Sample Application + +In this step, you will complete an end-to-end test using your sample HTML application that uses the Auth0 SAML connection you set up to perform SSO with SSOCircle. + +Open the `hello-saml.html` file with a web browser. You should see a white page with a login button on it. + +![Test Homepage](/media/articles/saml/identity-providers/ssocircle/hello-saml.png) + +Click **Login**. The **Auth0 Lock** Widget will appear. + +::: note +If you are prompted to enter an email address, make sure the domain for the email address you enter is listed under **Settings** for the Auth0 Application you previously configured. +::: + +Provide the requested log in credentials and click **Access** to initiate the SAML SSO sequence with SSOCircle. + +At this point, you will be redirected to the SSOCircle IDP to log in. + +![Login Screen](/media/articles/saml/identity-providers/ssocircle/login.png) + +Once you have logged in, you will see a SAML Consent Page. Click the box indicating that you're not a robot, then click **Continue SAML Single Sign-On**. + +![Consent to SAML Screen Screen](/media/articles/saml/identity-providers/ssocircle/saml-consent.png) + +::: note +Please note that you will not be prompted for your credentials if you still have an active session at SSOCircle. If this is the case, you will simply be redirected to the callback URL specified in `hello-saml.html`. +::: + +If you successfully authenticate, you will be redirected to the callback URL specified in `hello-saml.html` (`http://jwt.io`). You will see the token that your Application receives. + +## 8. Troubleshooting + +* If logging in to your Application doesn't work the first time, clear your browser's history and cookies before testing again. The browser may not be picking up the latest version of your HTML. +* When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis (search for "HTTP Trace" to find one appropriate for your needs). Once you have an HTTP tracer, capture the login sequence from start to finish and analyze the trace to see the sequence of `GET` requests to see where the error occurs. You should see: + * A redirect from your original site to the IDP; + * A post of credentials (if you were asked to log in); + * A redirect to the callback URL. +* Ensure that your browser has enabled cookies and JavaScript. +* Check to make sure that the callback URL specified in the HTML is also listed in the **Allowed Callback URLs** field in the **Settings** tab of the Auth0 Application. diff --git a/fr-ca/articles/protocols/saml/idp-initiated-sso.md b/fr-ca/articles/protocols/saml/idp-initiated-sso.md new file mode 100644 index 0000000000..bf2e5617b9 --- /dev/null +++ b/fr-ca/articles/protocols/saml/idp-initiated-sso.md @@ -0,0 +1,91 @@ +--- +title: IdP-Initiated Single Sign-On +description: How to setup SAML Identity Provider-initiated Single Sign-on (SSO). +topics: + - saml + - sso +contentType: + - how-to + - concept +useCase: + - add-idp +--- + +# IdP-Initiated Single Sign-On + +Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider. The service provider redirects the user to the identity provider for the purposes of authentication. This process is commonly used for consumer-facing scenarios. + +However, in enterprise scenarios, it is sometimes common to begin with the identity provider initiating SSO, not the service provider. For example, an enterprise company might set up a portal to ensure that users navigate to the correct application after they sign on to the portal. + +## Risks of using an IdP-Initiated SSO flow + +::: warning +IdP-Initiated flows carry a security risk and are therefore NOT recommended. Make sure you understand the risks before enabling IdP-Initiated SSO. +::: + +In an IdP-initiated flow neither Auth0 (which receives the unsolicited response from the Identity Provider) nor the application (that receives the unsolicited response generated by Auth0) can verify that the user actually started the flow. Because of this, enabling this flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/support/solutions/articles/48001048951-login-csrf), where an attacker can trick a legitimate user into unknowingly logging into the application with the identity of the attacker. + +The recommendation is to use SP-Initiated flows whenever possible. + +### On IdP-Initiated flows and OpenID Connect + +OpenID Connect (OIDC) does not support the concept of an IdP-Initiated flow. So while Auth0 offers the possibility of translating a SAML IdP-Initiated flow (from a SAML connection) into an OIDC response for an application, any application that properly implements the OIDC/OAuth2 protocol will reject an unrequested response. + +When using OIDC applications, the best option is to have the users start the login flow **at the application** or configure the portals to send the user to the application's login initiation endpoint (without an IdP-Initiated SAML response) so that, again, the application starts the authentication flow. + +## How to set up IDP-initiated SSO + + + +To setup IdP-Initiated SSO, go to the [Enterprise Connections](${manage_url}/#/connections/enterprise) section of the dashboard and choose **SAMLP Identity Provider**. Under the **Settings** section you can see the configuration for IdP-Initiated SSO. + +![Configure SAML Idp-Initiated SSO Settings](/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png) + +**Default Application:** When the IdP initiated login succeeds this is the application where users are routed. This setting shows available applications enabled for this connection. Select the application from the dropdown that you want the users to login with IdP initiated. Only one application can be selected for an IdP-initiated login per SAML connection. + +**Response Protocol:** This is the protocol used to connect your selected **Default Application**. Most commonly applications are configured with the OpenID Connect protocol (read [here](#on-idp-initiated-flows-and-OIDC) for possible pitfalls). However if you have configured a SAML2 Web App addon for your application and want to route the SAML assertion you will need to select SAML. + +**Query String:** Query string options help to customise the behavior when the OpenID Connect protocol is used. You can set multiple options similar to setting parameters with a [query string](https://en.wikipedia.org/wiki/Query_string). You can set: + +* `redirect_uri`: When the IdP-initiated login has completed the request is then redirected to the first URL listed in the **Allowed Callback URLs** for the application. However if you set a `redirect_uri` the IdP will redirect to this URL. This brings flexibility for cases like when you have set subdomain scheme with a wildcard and you only want to redirect to one specific subdomain. +* `scope`: You could define scopes for the ID Token sent. Note that it is possible to set multiple scopes. +* `response_type`: This field is used to set the token for Implicit Grant Flow for SPA applications. You could set code for Authorization Code Grant Flow for regular web applications. + +Example Query String: + +`redirect_uri=https://jwt.io&scope=openid email&response_type=token` + +## Post-back URL + +When using **IdP-Initiated SSO**, please make sure to include the `connection` parameter in the post-back URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` + +## Lock/Auth0.js + +If your application is a Single-Page Application that uses Lock or Auth0.js to process the authentication results, you will have to explicitly indicate that you want to allow IdP-Initiated flows (and thus [open the application to possible Login CSRF attacks](#risks-of-using-an-idp-Initiated-SSO-flow)). + +If you are using [Auth0.js](/libraries/auth0js), you have to update the **webAuth.parseHash** of the [library](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) and set the flag **__enableIdPInitiatedLogin** to `true`. + +```javascript +var data = webAuth.parseHash( + { + ... + __enableIdPInitiatedLogin: true + ... + } +``` + +If you're using [Lock](/lock), you can include the flag using the options parameter sent to the constructor. + +```javascript +const lock = new Auth0Lock(clientID, domain, options) +``` + +Here's the flag itself: + +```javascript +var options = { + _enableIdPInitiatedLogin: true +}; +``` + +Note that the **enableIdPInitiatedLogin** flag is preceded by **one** underscore when used with Lock and **two** underscores when used with the auth0.js library. diff --git a/fr-ca/articles/protocols/saml/index.html b/fr-ca/articles/protocols/saml/index.html new file mode 100644 index 0000000000..7be7d02149 --- /dev/null +++ b/fr-ca/articles/protocols/saml/index.html @@ -0,0 +1,114 @@ +--- +url: /protocols/saml +section: articles +classes: topic-page +title: SAML +topics: + - saml +contentType: + - index +useCase: + - add-idp +--- + +
+
+

SAML

+

+ Documentation on SAML protocol. +

+
+ + diff --git a/fr-ca/articles/protocols/saml/saml-apps/_header.md b/fr-ca/articles/protocols/saml/saml-apps/_header.md new file mode 100644 index 0000000000..d3708bc803 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/_header.md @@ -0,0 +1,5 @@ +# ${meta.title} + +## SAML Configuration + +Use the following SAML configuration: diff --git a/fr-ca/articles/protocols/saml/saml-apps/atlassian.md b/fr-ca/articles/protocols/saml/saml-apps/atlassian.md new file mode 100644 index 0000000000..7d2bae9c92 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/atlassian.md @@ -0,0 +1,73 @@ +--- +description: Learn how to configure Single Sign-on (SSO) with Atlassian. +topics: + - saml + - identity-providers + - atlassian +contentType: + - how-to +useCase: + - add-idp +--- + +# Atlassian SAML Configuration + +You can configure Auth0 as the SAML SSO identity provider for Atlassian. + +## Prerequisites + +* A verified domain in your [Atlassian Organization](https://admin.atlassian.com/). +* [Atlassian Access](https://www.atlassian.com/software/access) + +## Configure Auth0 identity provider application + +1. Go to [Dashboard > Applcations](${manage_url}/#/applications) and click **Regular Web Applications** to create an app. +2. Add connections to your app. Make sure that the correct set of Auth0 connections are associated with your identity provider app. +3. Go to **Addons** tab and enable the **SAML2 Web App** addon. +4. Click the **Usage** tab. Here you will find information to populate SAML metadata in Atlassian Access. Note the settings. + +## Configure Atlassian SAML connection + +1. Log in to your [Atlassian Admin](https://admin.atlassian.com/) dashboard. +2. Go to **Organization > Security > SAML single sign-on**. +3. Copy the configuration settings from the Auth0 SAML2 Web App addon usage page: + +| Setting | Description| +| -- | -- | +| **Identity provider Entity ID** | `urn:TENANT.auth0.com` | +| **Identity provider SSO URL** | `https://TENANT.auth0.com/samlp/APP_ID` | +| **Public x509 certificate** | Content from your .pem file: `https://TENANT.auth0.com/pem` | + +4. Click **Save configuration**. +5. On the summary page, copy the **SP Assertion Consumer Service URL**. + +## Configure callback URL in Auth0 + +1. Go back to [Dashboard > Applcations](${manage_url}/#/applications) to your applications SAML2 addon settings. +2. Update the **Application Callback URL** with the **SP Assertion Consumer Service URL** you copied in the previous section. +3. On the **Settings** tab, update the metadata mapping file. For example: + +```js +{ + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" + }, + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" + ], + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email" +} +``` + +![SAML2 Web App Settings](/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png) + +4. Click **Save**. + +## Test connection + +1. Go to [id.atlassian.com](https://id.atlassian.com/) and log in. +2. Login with SAML identity provider and return to Atlassian. diff --git a/fr-ca/articles/protocols/saml/saml-apps/cisco-webex.md b/fr-ca/articles/protocols/saml/saml-apps/cisco-webex.md new file mode 100644 index 0000000000..4c32cef3d7 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/cisco-webex.md @@ -0,0 +1,37 @@ +--- +title: Cisco WebEx SAML Configuration +description: Cisco WebEx SAML Configuration +topics: + - saml + - identity-providers + - cisco + - cisco-webex +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "mappings": { + "email": ["email", "uid", "Name_ID"] + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "email", + ] +} +``` + +Notice that Webex has an option to automatically provision new users. You will need to send that info along as claims (lastname, and so on). + +:::note +If you integrate Auth0 with Cisco Spark services, you might find this article helpful: [Single Sign-On with Cisco Spark Services](https://collaborationhelp.cisco.com/article/en-us/lfu88u). +::: diff --git a/fr-ca/articles/protocols/saml/saml-apps/datadog.md b/fr-ca/articles/protocols/saml/saml-apps/datadog.md new file mode 100644 index 0000000000..45b50ab027 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/datadog.md @@ -0,0 +1,34 @@ +--- +title: Datadog SAML Configuration +description: Datadog SAML Configuration +topics: + - saml + - identity-providers + - datadog +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://app.datadoghq.com/account/saml/metadata.xml", + "mappings": { + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + ], +} +``` + +The **Callback URL** is `https://app.datadoghq.com/account/saml/assertion`. + +Notice that Datadog has an option to automatically provision new users. Check [Datadog docs](http://docs.datadoghq.com/guides/saml/) for more details. diff --git a/fr-ca/articles/protocols/saml/saml-apps/egencia.md b/fr-ca/articles/protocols/saml/saml-apps/egencia.md new file mode 100644 index 0000000000..6fbc053c54 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/egencia.md @@ -0,0 +1,33 @@ +--- +title: Egencia SAML Configuration +description: Egencia SAML Configuration +topics: + - saml + - identity-providers + - egencia +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + + +```json +{ + "audience": "https://{YOUR_ACCOUNT_NAME}.egencia.com", + "mappings": { + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + ], +} +``` + +The **Callback URL** is `https://www.egencia.com/auth/v1/artifactConsumer`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/eloqua.md b/fr-ca/articles/protocols/saml/saml-apps/eloqua.md new file mode 100644 index 0000000000..cabc886eb5 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/eloqua.md @@ -0,0 +1,39 @@ +--- +title: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration +description: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration +topics: + - saml + - identity-providers + - eloqua +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + + +```json +{ +"audience": "", + "recipient": "https://login.eloqua.com/auth/saml2/acs", + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", +   }, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ], + "destination": "https://login.eloqua.com/auth/saml2/acs" + } + +``` + +The **Callback URL** is `https://login.eloqua.com/auth/saml2/acs`. + +::: note +The Service Provider Entity URL copied from within the IDP settings in Eloqua to set the audience restriction within Auth0. +::: \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/saml-apps/freshdesk.md b/fr-ca/articles/protocols/saml/saml-apps/freshdesk.md new file mode 100644 index 0000000000..5e528c57ff --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/freshdesk.md @@ -0,0 +1,39 @@ +--- +title: Freshdesk SAML Configuration +description: Freshdesk SAML Configuration +topics: + - saml + - identity-providers + - freshdesk +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + + +The Application Callback URL would found at: Freshworks Dashboard => Security => SAML SSO => Assertion Consumer Service(ACS) URL +The audience can be at Freshworks Dashboard => Security => SAML SSO => Service Provider(SP) Entity ID URL + +```json +{ + "audience": "https://{FD Domain}.freshworks.com/sp/SAML/{xxxxxxxxxxxxxxxxxxx}/metadata", + "mappings": { + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +The **Callback URL** is `https://{FD Domain}.freshdesk.com/login/saml`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/github-cloud.md b/fr-ca/articles/protocols/saml/saml-apps/github-cloud.md new file mode 100644 index 0000000000..fdd173f9e9 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/github-cloud.md @@ -0,0 +1,88 @@ +--- +title: Configure Auth0 as Identity Provider for GitHub Enterprise Cloud +description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Cloud (github.com) organization. +topics: + - saml + - identity-providers + - github +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as Identity Provider for GitHub Enterprise Cloud + +These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Cloud](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) (i.e., github.com). Note that GitHub requires an Enterprise-level subscription to enable using an external SAML identity provider. + +When setting up SAML Single Sign-on (SSO) in your organization, you can test your implementation without affecting your organization members by leaving Require SAML SSO authentication for all members of the organization name organization unchecked. See [GitHub documentation on authentication with SAML](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) for more information. + +::: note +**Heads up!** This article applies to GitHub Enterprise Cloud (github.com). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Server (private instance), check [this page](/protocols/saml/saml-apps/github-server) instead. +::: + +## Configure the Addon: SAML2 Web App + +Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. + +Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch. + +![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png) + +The *Settings* window will be displayed. Set the following values: + +- **Application Callback URL**: `https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}/saml/consume` + +- **Settings**: + +```json +{ + "audience": "https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}", + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "emails", + "name": "full_name" + }, + "passthroughClaimsWithNoMapping": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha256", + "digestAlgorithm": "sha256", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" + ] +} +``` + +**Note**: Make sure to replace `{YOUR_GITHUB_ORG_NAME}` with the GitHub organization name that corresponds to your subscription. + +The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). + +As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this: + +```json +{ + [...] + "mappings": { + "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "emails", + "name": "full_name" + }, + [...] +} +``` + +## Configure SAML Single Sign-On on GitHub +Follow the instruction from GitHub's [Enabling and testing SAML Single Sign-on (SSO) for your organization](https://help.github.com/en/articles/enabling-and-testing-saml-single-sign-on-for-your-organization) to complete the configuration on GitHub Enterprise Cloud. You will need the following information: + +* **Sign On URL** (for step 6): `https://${account.namespace}/samlp/{CLIENT_ID}` + `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0. +* **Issuer** (step 7): `urn:auth0:${account.tenant}` +* **Public Certificate** (step 8): Download it from `https://${account.namespace}/pem`. Open the downloaded file with a text editor, copy the contents and paste them in the text area on GitHub. +* **Signature method** (step 9): `RSA256-SHA256` +* **Digest method** (step 9): `SHA256` + +The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog: + +![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png) + +As recommended in GitHub's documentation, before enabling SAML SSO for your organization, click **Test SAML configuration** to ensure that the information you've entered is correct. \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/saml-apps/github-server.md b/fr-ca/articles/protocols/saml/saml-apps/github-server.md new file mode 100644 index 0000000000..4495d0bca6 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/github-server.md @@ -0,0 +1,85 @@ +--- +title: Configure Auth0 as Identity Provider for GitHub Enterprise Server +description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Server private instance. +topics: + - saml + - identity-providers + - github +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as Identity Provider for GitHub Enterprise Server + +These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Server](https://help.github.com/en/enterprise/2.16/admin/user-management/using-saml) (i.e. your private GitHub appliance). + +::: note +**Heads up!** This article applies to GitHub Enterprise Server (deployed as a private instance). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Cloud (github.com), check [this page](/protocols/saml/saml-apps/github-cloud) instead. +::: + +## Configure the Addon: SAML2 Web App + +Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. + +Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch. + +![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png) + +The *Settings* window will be displayed. Set the following values: + +- **Application Callback URL**: `{YOUR_GITHUB_SERVER_URL}/saml/consume` + +- **Settings**: + +```json +{ + "audience": "{YOUR_GITHUB_SERVER_URL}", + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "emails", + "name": "full_name" + }, + "passthroughClaimsWithNoMapping": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha256", + "digestAlgorithm": "sha256", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" + ] +} +``` + +**Note**: Make sure to replace `{YOUR_GITHUB_SERVER_URL}` with the URL assigned to your GitHub Server (i.e. `https://github.example.com`). + +The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). + +As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this: + +```json +{ + [...] + "mappings": { + "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "emails", + "name": "full_name" + }, + [...] +} +``` + +## Configure SAML Single Sign-on on GitHub +Follow the instruction from [Using SAML on Enterprise Server- GitHub Help](https://help.github.com/en/enterprise/admin/user-management/using-saml#configuring-saml-settings) to complete the configuration on GitHub Enterprise Cloud. You will need the following information: + +* **Sign On URL**: `https://${account.namespace}/samlp/{CLIENT_ID}` + `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0. +* **Issuer**: `urn:auth0:${account.tenant}` +* **Verification Certificate**: You will need to download it from `https://${account.namespace}/pem` and upload it in this field. +* **User Attributes**: you should leave the defaults here, as the mapping that we configured in the SAML Web App addon uses the default attribute names proposed by GitHub. +* **Signature method**: `RSA256-SHA256` +* **Digest method**: `SHA256` + +The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog: + +![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png) diff --git a/fr-ca/articles/protocols/saml/saml-apps/google-apps.md b/fr-ca/articles/protocols/saml/saml-apps/google-apps.md new file mode 100644 index 0000000000..1bb7255078 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/google-apps.md @@ -0,0 +1,35 @@ +--- +title: G Suite SAML Configuration +description: G Suite SAML Configuration +topics: + - saml + - identity-providers + - g-suite +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs", + "mappings": { + "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha256", + "digestAlgorithm": "sha256", + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ], +} +``` + +The **Callback URL** is `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/heroku.md b/fr-ca/articles/protocols/saml/saml-apps/heroku.md new file mode 100644 index 0000000000..2cefaeeea2 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/heroku.md @@ -0,0 +1,75 @@ +--- +description: Learn how to configure Single Sign-on (SSO) with Heroku. +topics: + - saml + - identity-providers + - heroku +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Single Sign-on with Heroku + +::: note +You must have administrative rights to your organization account on Heroku to configure Single Sign-on (SSO). Organization accounts are included with Heroku Enterprise plans. +::: + +You can configure Single Sign-on (SSO) so that your users can log into Heroku using any of Auth0's supported [identity providers](/identityproviders). + +## 1. Obtain Your Heroku Identifiers + +On the Settings page for your organization in Heroku, scroll to the **Single Sign-On (SSO)** section. + +![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png) + +You will need the following two parameters from this section to integrate with Auth0: + +* __Heroku Entity ID__ +* __ACS URL__ + +## 2. Register Heroku with Auth0 + +Log in to your [Auth0 Dashboard](${manage_url}/#/applications) and select the [application](/applications) for which you want to configure SSO with Heroku. Go to the __Addons__ section of your Application, and enable __SAML2 Web App__: + +![](/media/articles/saml/saml-apps/heroku/auth0-dashboard.png) + +Enter the __ACS URL__ from the previous step into the __Application Callback URL__ field and update the settings as follows: + +```json +{ + "audience":"THE-HEROKU-ENTITY-ID", + "mappings": { + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png) + +::: note +The `audience` parameter is the __Heroku Entity ID__. It will be formatted like this: `https://sso.heroku.com/saml/YOUR-HEROKU-ORG` +::: + +Click **Save**. + +![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png) + +## 3. Provide Auth0 Metadata to Heroku + +Open up the __Usage__ section of the SAML2 Web App Configuration pop-up and download the __Identity Provider Metadata__. + +Return to Heroku. Click on __Upload Metadata__ and select the file containing the **Identity Provider Metadata** you downloaded in the previous step. + +![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png) + +Once you've uploaded your metadata, your SSO integration is fully set up. \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/saml-apps/hosted-graphite.md b/fr-ca/articles/protocols/saml/saml-apps/hosted-graphite.md new file mode 100644 index 0000000000..cbeb6da827 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/hosted-graphite.md @@ -0,0 +1,26 @@ +--- +title: Hosted Graphite SAML Configuration +description: Hosted Graphite SAML Configuration +topics: + - saml + - identity-providers + - hosted-graphite +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://www.hostedgraphite.com/metadata/{YOUR-USER-ID}/", + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +The **Callback URL** is `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/index.md b/fr-ca/articles/protocols/saml/saml-apps/index.md new file mode 100644 index 0000000000..472ae21b8d --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/index.md @@ -0,0 +1,44 @@ +--- +title: SAML Configurations for Single Sign-on Integrations +description: This page lists SAML Configurations for various Single Sign-on (SSO) integrations including G Suite, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday, Pluralsight and Workpath. +classes: topic-page +topics: + - saml + - identity-providers +contentType: + - index +useCase: + - add-idp +--- + + +
+
+

SAML Configurations for Single Sign-on Integrations

+

+ This page lists SAML Configurations for various Single Sign-on (SSO) integrations. +

+
+ +## SAML Configuration Tutorials + +<%= include('../../../_includes/_topic-links', { links: [ + 'protocols/saml/saml-apps/atlassian', + 'protocols/saml/saml-apps/cisco-webex', + 'protocols/saml/saml-apps/datadog', + 'protocols/saml/saml-apps/egencia', + 'protocols/saml/saml-apps/eloqua', + 'protocols/saml/saml-apps/freshdesk', + 'protocols/saml/saml-apps/github-cloud', + 'protocols/saml/saml-apps/github-server', + 'protocols/saml/saml-apps/google-apps', + 'protocols/saml/saml-apps/heroku', + 'protocols/saml/saml-apps/hosted-graphite', + 'protocols/saml/saml-apps/litmos', + 'protocols/saml/saml-apps/pluralsight', + 'protocols/saml/saml-apps/sprout-video', + 'protocols/saml/saml-apps/tableau-online', + 'protocols/saml/saml-apps/tableau-server', + 'protocols/saml/saml-apps/workday', + 'protocols/saml/saml-apps/workpath' +] }) %> diff --git a/fr-ca/articles/protocols/saml/saml-apps/litmos.md b/fr-ca/articles/protocols/saml/saml-apps/litmos.md new file mode 100644 index 0000000000..756f9ca3b4 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/litmos.md @@ -0,0 +1,131 @@ +--- +title: Litmos SAML Configuration +description: Litmos SAML Configuration +topics: + - saml + - identity-providers + - litmos +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "Email", + "given_name": "FirstName", + "family_name": "LastName" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha1", + "digestAlgorithm": "sha1", + "destination": "https://{YOUR DOMAIN}.litmos.com/integration/samllogin", + "lifetimeInSeconds": 3600, + "signResponse": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +The **Callback URL** is `https://{YOUR DOMAIN}.litmos.com/integration/samllogin`. + +## Sample SAML + +```xml + + urn:{tenant}.auth0.com + + + + + urn:{tenant}.auth0.com + + + + + + + + + + + cdFGeW7M8cxg9xEVh/gLxRKlWDA= + + + ********* + + + ********* + + + + + brandon@litmos.com + + + + + + + + + + + + urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport + + + + + Smith + + + John + + + john@mail.com + + + + +``` diff --git a/fr-ca/articles/protocols/saml/saml-apps/pluralsight.md b/fr-ca/articles/protocols/saml/saml-apps/pluralsight.md new file mode 100644 index 0000000000..ea769d56c2 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/pluralsight.md @@ -0,0 +1,37 @@ +--- +title: Pluralsight SAML Configuration +description: Pluralsight SAML Configuration +topics: + - saml + - identity-providers + - pluralsight +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + + +```json +{ + "audience": "www.pluralsight.com", + "mappings": { + "user_id": "id", + "email": "email", + "given_name": "firstName", + "family_name": "lastName" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +The **Callback URL** is `https://prod-pf.pluralsight.com/sp/ACS.saml2`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/sprout-video.md b/fr-ca/articles/protocols/saml/saml-apps/sprout-video.md new file mode 100644 index 0000000000..fd4ada302c --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/sprout-video.md @@ -0,0 +1,32 @@ +--- +title: Sprout Video SAML Configuration +description: Sprout Video SAML Configuration +topics: + - saml + - identity-providers + - sprout-video +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io", + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + ], +} +``` diff --git a/fr-ca/articles/protocols/saml/saml-apps/tableau-online.md b/fr-ca/articles/protocols/saml/saml-apps/tableau-online.md new file mode 100644 index 0000000000..685f3b65b4 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/tableau-online.md @@ -0,0 +1,40 @@ +--- +title: Tableau Online SAML Configuration +description: Tableau Online SAML Configuration +topics: + - saml + - identity-providers + - tableau +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://sso.online.tableau.com/public/sp/metadata?alias={YOUR TABLEAU ALIAS}", + "recipient": "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}", + "mappings": { + "email": "Email" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha1", + "digestAlgorithm": "sha1", + "destination": "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}", + "lifetimeInSeconds": 3600, + "signResponse": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" + ] +} +``` +The **Callback URL** is `https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}`. +The recipient, destination and callback URLL value is same as Assertion Consumer Service URL from Tableau Authentication Page. +See [https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm](https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm) for more information. diff --git a/fr-ca/articles/protocols/saml/saml-apps/tableau-server.md b/fr-ca/articles/protocols/saml/saml-apps/tableau-server.md new file mode 100644 index 0000000000..e299a22d92 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/tableau-server.md @@ -0,0 +1,39 @@ +--- +title: Tableau Server SAML Configuration +description: Tableau Server SAML Configuration +topics: + - saml + - identity-providers + - tableau +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "{YOUR TABLEAU AUDIENCE}", + "recipient": "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html", + "mappings": { + "email": "username" + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "signatureAlgorithm": "rsa-sha1", + "digestAlgorithm": "sha1", + "destination": "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html", + "lifetimeInSeconds": 3600, + "signResponse": false, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" + ] +} +``` + +The **Callback URL** is `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html`. diff --git a/fr-ca/articles/protocols/saml/saml-apps/workday.md b/fr-ca/articles/protocols/saml/saml-apps/workday.md new file mode 100644 index 0000000000..1e3f3f6970 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/workday.md @@ -0,0 +1,35 @@ +--- +title: Workday SAML Configuration +description: Workday SAML Configuration +topics: + - saml + - identity-providers + - workday +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "http://www.workday.com", + "recipient": "https://www.myworkday.com//login-saml.htmld", + "mappings": { + }, + "createUpnClaim": false, + "passthroughClaimsWithNoMapping": false, + "mapUnknownClaimsAsIs": false, + "mapIdentities": false, + "signResponse": true, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + ], + "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:X509", +} +``` + +The **Callback URL** is `https://impl.workday.com//login-saml.htmld`. You may want to change the subdomain `impl` depending on the Workday data center you are using. diff --git a/fr-ca/articles/protocols/saml/saml-apps/workpath.md b/fr-ca/articles/protocols/saml/saml-apps/workpath.md new file mode 100644 index 0000000000..60e2f170b2 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-apps/workpath.md @@ -0,0 +1,23 @@ +--- +title: Workpath SAML Configuration +description: Workpath SAML Configuration +contentType: + - how-to +useCase: + - add-idp +--- + +<%= include('./_header') %> + +```json +{ + "audience": "https://api.workpath.com/v1/saml/metadata/{YOUR-WORKPATH-SUBDOMAIN}", + "mappings": { + "email": "email", + "given_name": "first_name", + "family_name": "last_name" + } +} +``` + +The **Callback URL** is `https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}`. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md new file mode 100644 index 0000000000..999e7a133b --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md @@ -0,0 +1,30 @@ +--- +description: How to configure Auth0 for use as a SAML service AND identity provider +topics: + - saml +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as a Service and Identity Provider + +::: note +Auth0 provides a non-exhaustive [list of SAML-compliant providers](/samlp-providers). +::: + +::: warning +Auth0 only supports: +* Using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**. +* Using Auth0 as the identity provider in SAML configurations with **SAML 2.0**. +::: + +When using Auth0 as both the SAML Service and Identity Provider, you need to configure **two** federations: + +* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider) +* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider). + +## Using Two Auth0 Tenants + +The section above assumes that you're using the same Auth0 tenant as the service provider *and* the identity provider. However, you can also implement a [SAML scenario using **two** Auth0 tenants](/samlsso-auth0-to-auth0) (usually for testing purposes), where one tenant acts as the identity provider and the other acts as the service provider. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md new file mode 100644 index 0000000000..56178f72e1 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md @@ -0,0 +1,72 @@ +--- +description: How to configure Auth0 for use as a SAML identity provider +topics: + - saml +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as an Identity Provider + +::: warning +Auth0 only supports using Auth0 as the identity provider in SAML configurations with **SAML 2.0**. +::: + +Depending on the type of application you're working with, configuring Auth0 to serve as the SAML Identity Provider (IdP) is done in several places. + +## Single Sign-on Integrations with Built-in Auth0 Support + +For some Single Sign-on (SSO) Integrations that support SAML, the configuring Auth0 is done using the [**SSO Integrations** area of the Management Dashboard](${manage_url}/#/externalapps). To create a new integration, click **Create SSO Integration**. + +![](/media/articles/protocols/saml/saml-configuration/sso-integrations.png) + + On the *New Single Sign-On Integration* page, select the integration in which you're interested. Currently, your options are as follows: + +* Active Directory +* Box +* CloudBees +* Concur +* Dropbox +* Microsoft Dynamics CRM +* Adobe EchoSign +* Egnyte +* New Relic +* Office 365 +* Salesforce +* SharePoint +* Slack +* SpringCM +* Zendesk +* Zoom + +![](/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png) + +Provide a name for your new integration. Click **Create** to proceed. + +You will now see additional configuration instructions that are specific to the integration that you have chosen. + +![](/media/articles/protocols/saml/saml-configuration/name-sso-integration.png) + +You can also refer to [Using Auth0 in SAML2 Web Apps](/saml2webapp-tutorial) for instructions specific to configuring a given SSO Integration. + +## Manually Configure a SSO Integration + +If the Service Provider option you've chosen doesn't come with built-in Auth0 support, you can [manually add the configuration](/saml-idp-generic). + +Navigate to the [Applications section of the Management Dashboard](${manage_url}/#/applications), find the Application you're working with, and click on **Settings**. + +![](/media/articles/protocols/saml/saml-configuration/applications.png) + +Switch over to the **Addons** tab. + +![](/media/articles/protocols/saml/saml-configuration/add-ons.png) + +Enable **SAML2 Web App**. You will see a screen asking you to provide additional configuration information, with details on what the fields mean and what the expected value types are located directly on that page. + +![](/media/articles/protocols/saml/saml-configuration/configure-app.png) + +In addition, [SAML Settings Needed for Some SSO Integrations](/saml-apps) provide additional information for integrations that require special settings. + +When done, click **Save**. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md new file mode 100644 index 0000000000..7ed558c5f6 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md @@ -0,0 +1,34 @@ +--- +description: How to configure Auth0 for use as a SAML service provider +topics: + - saml +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as a Service Provider + +::: warning +Auth0 only supports using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**. +::: + +This video provides an overview of how to configure Auth0 for use as a SAML service provider. + + + + +When Auth0 serves as the SAML service provider, you need to use an Auth0 Connection to configure the service provider side of each SAML federation. + +Finally, you'll configure the Identity Provider (IdP) portion of your SAML setup. We have docs for the following providers: + +* [ADFS](/adfs) +* [Okta](/okta) +* [OneLogin](/onelogin) +* [Ping7](/ping7) +* [Salesforce](/saml/identity-providers/salesforce) +* [SiteMinder](/siteminder) +* [SSOCircle](/ssocircle) + +If you are using any other SAML-compliant IdP with Auth0 as the Service Provider, you can use the [Generic Service Provider Configuration Instructions](/saml-sp-generic). diff --git a/fr-ca/articles/protocols/saml/saml-configuration/deprovision-users.md b/fr-ca/articles/protocols/saml/saml-configuration/deprovision-users.md new file mode 100644 index 0000000000..08d1523ec3 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/deprovision-users.md @@ -0,0 +1,18 @@ +--- +description: Best practices on deprovision users of your SAML integration +topics: + - saml +contentType: + - how-to + - concept +useCase: + - add-idp +--- + +# Deprovision Users + +If you ever need to remove application access for users, you'll need to *deprovision* them, at minimum, with the identity provider. Depending on the identity provider you're using, the steps required to deprovision a user account varies; check with your provider for further instructions. + +Once a user's account is removed or disabled with the identity provider, the user will not be able to log in. + +You may also want to remove the Auth0 user accounts for those who've been deprovisioned if Auth0 is the service provider or if your app integrates with Auth0. Regardless of whether Auth0 is the identity or service provider, you can remove users using the Management [Dashboard](${manage_url}/#/users) or [API](/api/management/v2#!/Users/delete_users_by_id). diff --git a/fr-ca/articles/protocols/saml/saml-configuration/design-considerations.md b/fr-ca/articles/protocols/saml/saml-configuration/design-considerations.md new file mode 100644 index 0000000000..68ac4fbf90 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/design-considerations.md @@ -0,0 +1,46 @@ +--- +description: Things to consider when designing your SAML integration +topics: + - saml +contentType: + - concept +useCase: + - add-idp +--- + +# SAML Design Considerations + +Regardless of how you implement SAML Single Sign-on (SSO), it's important to consider: + +* Which system(s) will serve as the authoritative source for user profile information if there's ever a conflict between two or more sources; +* What user profile attributes each application needs; +* How user profile information will be distributed to the systems that need it. + +## Considerations for Using Auth0 as Service Provider + +* If Auth0 serves as the Service Provider in a SAML federation, Auth0 can [route authentication requests to an Identity Provider](/hrd) without already having an account pre-created for a specific user. Using the assertion returned by the identity provider, Auth0 can capture information needed to create a user profile for the user (this process is sometimes called just-in-time provisioning). + +* Even though Auth0 doesn't require pre-created user accounts prior to the authentication process, the application integrated with Auth0 might. If this is the case, you have several options when it comes to handling this: + + * After the identity provider creates the user, you can use an out-of-band process can create the accompanying user in the application (or Auth0) and add any user profile attributes required by the application. If, after authentication, any attributes are missing in the profile, the application can obtain them from the appropriate source and store them in the Auth0 user profile. The additional attributes are then sent to the application (in addition to any added by the identity provider) the next time the user logs in. + + * You can use an Auth0 [rule](/rules) to call an API to retrieve any missing information and dynamically add it to the Auth0 profile (which is then returned to the application). Rules execute after successful authentication, and your application can retrieve profile attributes each time *or* you can save the attributes to the Auth0 profile. + + * Auth0 can pass the basic profile information from the identity provider to the application, which then retrieves any missing information from another source. With the two sets of information, the application creates a local user profile. + +* You can specify email domains as part of the Auth0 SAMLP Connection configuration to control the IDP that handles a select group of users. For example, if you add email domain `example.com` to the Auth0 SAMLP Connection configuration for Company X, all users with emails with the `example.com` domain get handled by the specific IDP for Company X. + +## Considerations for Using Auth0 as Identity Provider + +If Auth0 is serving as the Identity Provider in a SAML federation, user accounts may be created multiple ways: + +* Using a back-end authentication system, such as an LDAP directory, a database, or another SAML identity provider; +* Using the [Auth0 Management Dashboard](${manage_url}/#/users); +* Calling the [Auth0 Management API](/api/management/v2#!/Users/post_users); +* Implementing self-service user signup. + +If your application is written to retrieve user profile information from a local store, you'll need to create the local profile after the accounts have been created in Auth0. Some of the ways you might do this include: + + * An out-of-band process creating user profiles in the application; + * An Auth0 [rule](/rules) that executes on first login that calls an application API to create the user profile in the application; + * Modifying the application to create user profiles dynamically, based on information in the SAML assertion. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/index.md b/fr-ca/articles/protocols/saml/saml-configuration/index.md new file mode 100644 index 0000000000..0c6ff2b5b3 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/index.md @@ -0,0 +1,57 @@ +--- +description: An overview of the SAML configuration process +topics: + - saml + - saml-configuration +contentType: + - index +useCase: + - add-idp +--- + +# SAML Configuration + +SAML-based federation involves two parties: + +1. An **identity provider** (IdP): authenticates users and provides to Service Providers an Authentication Assertion if successful; +2. A **service provider** (SP): relies on the Identity Provider to authenticate users. + +Auth0 supports the SAML protocol and can serve as the identity provider, the service provider, or both. + +## SAML Identity Providers + +Some applications (such as Salesforce, Box, and Workday) allow users to authenticate against an external IdP using the SAML protocol. You can then integrate the application with Auth0, which serves as the application's SAML IdP. + +Application users will be redirected to Auth0 to log in, and Auth0 can authenticate them using any backend authentication connection, such as an LDAP directory, a database, or another SAML IdP or Social Provider. + +Once the user is authenticated, Auth0 returns a SAML assertion to the application that indicates such. + +![](/media/articles/saml/saml-configuration/saml-case2.png) + +## SAML Service Providers + +Applications, especially custom ones, can authenticate users against an external IdP using protocols such as OpenID Connect (OIDC) or OAuth 2.0. However, you might want to leverage an enterprise SAML provider for authentication, even if you wrote your application to utilize either protocol. + +![](/media/articles/saml/saml-configuration/saml-case1.png) + +## Auth0 as the SAML Service and Identity Providers + +You may opt to use Auth0 as both the SAML Service Provider **and** SAML Identity Provider. + +![](/media/articles/saml/saml-configuration/saml-case3.png) + +## Configuration + +The following documentation cover the different aspects of SAML configuration: + +* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider) +* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider) +* [Configure Auth0 as Both Service and Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider) +* [SAML Design Considerations](/protocols/saml/saml-configuration/design-considerations) +* [Supported SAML Options and Bindings](/protocols/saml/saml-configuration/supported-options-and-bindings) +* [Special Configuration Scenarios](/protocols/saml/saml-configuration/special-configuration-scenarios) +* [Customize SAML Assertions](/protocols/saml/saml-configuration/saml-assertions) +* [Select Between Multiple Identity Providers](/hrd) +* [Logout](/protocols/saml/saml-configuration/logout) +* [Deprovision Users](/protocols/saml/saml-configuration/deprovision-users) +* [Troubleshoot](/protocols/saml/saml-configuration/troubleshoot) diff --git a/fr-ca/articles/protocols/saml/saml-configuration/logout.md b/fr-ca/articles/protocols/saml/saml-configuration/logout.md new file mode 100644 index 0000000000..efc2414f46 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/logout.md @@ -0,0 +1,76 @@ +--- +description: Learn how to log users out of Auth0 as the SAML identity provider. +topics: + - saml + - logout + - session-termination +contentType: + - how-to +useCase: + - add-idp + - manage-logout + - user-management +--- +# Log Users Out of Auth0 as the SAML Identity Provider + +When integrating with a SAML identity provider, there are many ways to implement logout or *user session termination*. + +SAML logout is configured differently depending on whether Auth0 acts as the service provider (when you create a SAML **connection**) the identity provider (when you have an application with the SAML2 Web App addon) or both. + +## Logout scenarios + +When Auth0 is acting as a [SAML Identity Provider](/protocols/saml/saml-idp-generic), you can have the following two scenarios: + +* Single logout +* Non-single logout + +### SAML Single Logout (SLO) Scenario + +After determining that your service provider supports SAML SLO, configure the service provider to call `https://${account.namespace}/samlp/CLIENT_ID/logout` (also listed in the SAML IdP metadata). + +When a logout request is triggered by the service provider, a SAML logout request is sent to this endpoint. Auth0 starts the SAML SLO flow by notifying the existing session participants using a frontend channel. + +1. Log into the [Management Dashboard](${manage_url}) + +2. Navigate to your [Application's Addons page](${manage_url}/#/applications/${account.clientId}/addons). + +3. Click to open the **SAML2 Web App** addon. + +4. In the **Settings** editor, uncomment the `logout` portion and update it with your callback URL: + + ```json + "logout": { + "callback": "CALLBACK_URL" + } + ``` + + To prevent a session participant from being notified, you can set `logout.slo_enabled` to `false` in the `SAML2 Web App` application addon's settings. + +5. Click **Save**. + +For SAML-compliant endpoints, Auth0 uses this URL to send SAML logout requests or logout responses (the exact choice depends on whether the service provider initiated the session or not). If you don't want to notify the service provider about a session termination, you can set the `slo_enabled` key inside logout to `false`: + +```json +"logout": { + "callback": "CALLBACK_URL", + "slo_enabled": false +} +``` + +By default, SAML logout responses are sent using the **HTTP-POST** protocol binding. If you want to use **HTTP-Redirect** you can configure the `binding` key to `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`: + +```json +"logout": { + "callback": "CALLBACK_URL" +}, +"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" +``` + +### Non-Single Logout Scenario + +If your service provider does not support SAML SLO, but provides a redirect URL where the user will be redirected to after logging out of the service provider, configure the redirect URL to `https://${account.namespace}/v2/logout`. This won't notify other session participants that a logout was initiated, but it will remove the session from Auth0. + +## Keep reading + +* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps) +* [Logout](/logout) diff --git a/fr-ca/articles/protocols/saml/saml-configuration/saml-assertions.md b/fr-ca/articles/protocols/saml/saml-configuration/saml-assertions.md new file mode 100644 index 0000000000..797c742986 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/saml-assertions.md @@ -0,0 +1,117 @@ +--- +description: How to customize SAML assertions +topics: + - saml + - saml-assertions +contentType: + - how-to +useCase: + - add-idp +--- + +# Customize SAML Assertions + +You can customize your SAML assertions, as well as the SAML and WS-Fed protocol parameters. + +## Auth0 as the Identity Provider + +To customize your SAML assertions when Auth0 acts as the identity provider, you can do so by configuring the addon itself or using [rules](/rules). + +### Use the Application Addon + +To customize your SAML assertion using the application add-on, navigate to [Applications > Settings > Addons](${manage_url}/#/applications/${account.clientId}/addons). Click on **SAML2 Web App** to launch the *Settings* tab that allows you to make several types of customizations including: + +* Specifying an audience other than the default issuer of the SAML request; +* Specifying a recipient; +* Mapping profile attributes to specific attribute statements; +* Changing the signature or digest algorithm; +* Specifying whether just the assertion or the entire response should be signed. + +### Use Rules + +You can use rules to add more extensive or dynamic customizations to the SAML response. + +Customizations done in Rules override customizations done using the Application Addons tab. + +::: note +The `context.samlConfiguration.mappings` object is used to override default SAML attributes or add new attributes. The object keys are the name of the SAML attribute to override or add and the values are a string of the `user` object property to use as the attribute value. +::: + +#### Example: Changing the SAML Token Lifetime and Using UPN as NameID + +```js +function (user, context, callback) { + // change SAML token lifetime to 10 hours + context.samlConfiguration.lifetimeInSeconds = 36000; + + // if available, use upn as NameID + if (user.upn) { + context.samlConfiguration.mappings = { + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "upn" // use user.upn as the value + } + } + + callback(null, user, context); +} +``` + +#### Example: Include `user_metadata` Attributes in an Assertion + +```js +function (user, context, callback) { + user.user_metadata = user.user_metadata || {}; + user.user_metadata.color = "purple"; + context.samlConfiguration.mappings = { + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "user_metadata.color", // use user.user_metadata.color as the value + }; + callback(null, user, context); +} +``` + +## Configuration Options + +The following is a list of customization options for your SAML assertions. + +* **audience** (string): The audience of the SAML Assertion. Default will be the Issuer on SAMLRequest. + +* **recipient** (string): The recipient of the SAML Assertion (SubjectConfirmationData). Default is `AssertionConsumerUrl` on SAMLRequest or Callback URL if no SAMLRequest was sent. + +* **mappings** (Object): The mappings between Auth0 profile and the output attributes on the SAML Assertion. Default mapping is shown above. + +* **createUpnClaim** (bool): Whether or not a UPN claim should be created. Default is true. + +* **passthroughClaimsWithNoMapping** (bool): If true (default), for each claim that is not mapped to the common profile, Auth0 will passthrough those in the output assertion. If false, those claims won't be mapped. Default is true. + +* **mapUnknownClaimsAsIs** (bool): if `passthroughClaimsWithNoMapping` is true and this is false (default), for each claim that is not mapped to the common profile Auth0 will add a prefix `http://schema.auth0.com`. If true it will passthrough the claim as-is. Default is false. + +* **mapIdentities**: If true, it will will add more information in the token like the provider used (google, adfs, ad, and so on) and the Access Token if available. Default is true. + +* **signatureAlgorithm**: Signature algorithm to sign the SAML Assertion or response. Default is `rsa-sha1` and it could be `rsa-sha256`. + +* **digestAlgorithm**: Digest algorithm to calculate digest of the SAML Assertion or response. Default is `sha1` and it could be `sha256`. + +* **destination**: Destination of the SAML Response. If not specified, it will be `AssertionConsumerUrl` of SAMLRequest or Callback URL if there was no SAMLRequest. + +* **lifetimeInSeconds** (int): Expiration of the token. Default is `3600` seconds (1 hour). + +* **signResponse** (bool): Whether or not the SAML Response should be signed. By default the SAML Assertion will be signed, but not the SAML Response. If true, SAML Response will be signed instead of SAML Assertion. + +* **nameIdentifierFormat** (string): Default is `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`. + +* **nameIdentifierProbes** (Array): Auth0 will try each of the attributes of this array in order. If one of them has a value, it will use that for the Subject/NameID. The order is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (mapped from user_id), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress (mapped from email), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name (mapped from name). + +* **authnContextClassRef** (string): Default is `urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified`. + +* **typedAttributes** (bool): Default is `true`. When set to true, we infer the xs:type of the element. Types are `xs:string`, `xs:boolean`, `xs:double `and `xs:anyType`. When set to false all `xs:type` are `xs:anyType` + +* **includeAttributeNameFormat** (bool): Default is `true`. When set to `true`, we infer the NameFormat based on the attribute name. NameFormat values are `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`, `urn:oasis:names:tc:SAML:2.0:attrname-format:basic` and `urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified`. If set to `false`, the attribute NameFormat is not set in the assertion. + +* **logout** (object): An object that controls SAML logout. It can contain two properties:`callback` (of type `string`), that contains the service provider (client application)'s **Single Logout Service URL**, where Auth0 will send logout requests and responses, and `slo_enabled`(boolean) that controls whether Auth0 should notify service providers of session termination. The default value is`true` (notify service providers). + +* **binding** (string): Optionally indicates the protocol binding used for SAML logout responses. By default Auth0 uses `HTTP-POST`, but you can switch to `HTTP-Redirect` by setting `"binding"` to `"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"`. + +* **signingCert** (string): Optionally indicates the public key certificate used to validate SAML requests. If set, SAML requests will be required to be signed. A sample value would be + + ``` + "-----BEGIN PUBLIC KEY-----\nMIGf...bpP/t3\n+JGNGIRMj1hF1rnb6QIDAQAB\n-----END PUBLIC KEY-----\n" + ``` diff --git a/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md new file mode 100644 index 0000000000..09ec481adf --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md @@ -0,0 +1,66 @@ +--- + description: Learn to set up IdP-initiated Single Sign-on (SSO) + topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- + +# Special Configuration Scenarios: IdP-Initiated Single Sign-On + +Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider: + +1. The service provider returns a browser redirect so that the user authenticates using the identity provider. +2. After authentication, the browser redirects the user back to the Service Provider with a SAML assertion containing information about the authentication status. + +This is commonly used for consumer-facing scenarios. + +## Alternative to Service Provider-Initiated SSO + +You might choose to begin with the identity provider initiating SSO instead of the service provider. The user: + +1. Invokes a URL on the identity provider; +2. Is prompted to authenticate +3. Is redirected to the service provider with a SAML assertion + +This is commonly used in enterprise scenarios. + +For example, an organization might set up a portal to ensure that users navigate to the correct application: + +1. The user navigates to the portal's URL; +2. The user is redirected to the IdP, which authenticates the user; +3. If successfully authenticated, the user clicks on the appropriate link; +4. The user is redirected to the service provider with a SAML assertion. + +## Risks of Using an IdP-Initiated SSO Flow + +In general, it is recommended to use Service-Provided flows whenever available. When an application actively requests an authentication as a first step (as is the case for SP-Initiated flows), it can check that the authentication response matches the original request. +In IdP-initiated scenarios, on the other hand, the application can not verify that the user actually started the flow. Because of this, the IdP-Initiated flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/customer/portal/articles/1969819-login-csrf), where an attacker can trick a legitimate user into using a session created by the attacker. + +Login CSRF attacks are generally less of a concern in enterprise-only scenarios, as any would-be attacker would have to come from the same directory of users. But it's definitely a security concern in consumer-facing applications, so we strongly advise against enabling IdP-Inititated flows on SAML connections. + +## Auth0 as Service Provider Where IdP Initiates SSO + +For information on how to configure IdP-Initiated flows when Auth0 is the Service Provider see [How to setup IdP-Initiated SSO in a SAML connection](/protocols/saml/idp-initiated-sso). + +## Auth0 as Identity Provider Where IdP Initiates SSO + +If Auth0 acts as the identity provider, you can use the application's SAML Sign In URL endpoint directly (without a SAML request): + +* Invoke the IdP-initiated login using the following URL: + + ```text + https://${account.namespace}/samlp/${account.clientId} + ``` + +* Append the `RelayState` parameter to the URL to which the service provider redirects the user after processing the SAML response. For example, the following URL is where the service provider redirects the URL after its processed the SAML response from Auth0: + + ```text + https://${account.namespace}/samlp + /${account.clientId}?RelayState=https://FINAL_DESTINATION_URL + ``` + +Note: it's up to the target application to accept IdP-Initiated flows and use the `RelayState` in a meaningful way if provided. \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md new file mode 100644 index 0000000000..d27d7e9011 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md @@ -0,0 +1,24 @@ +--- +description: Special configuration scenarios when setting up a SAML Integration + topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- +# Special Configuration Scenarios + +Once you've set up a basic SAML Integration, there are a number of additional requirements you might need to implement so that your integration reflects your needs and requirements. + +## Prerequisites + +This article assumes that you've already set up a [Connection](/protocols/saml/saml-configuration/auth0-as-service-provider) or an [Application](/protocols/saml/saml-configuration/auth0-as-identity-provider). + +The instructions below assume that you're altering specific settings for an existing SAML integration, not configuring an integration from scratch. + +## Scenarios + +* [IdP-Initiated SSO](/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso) +* [Signing and Encrypting SAML Requests](/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests) diff --git a/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md new file mode 100644 index 0000000000..dc76d7a160 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md @@ -0,0 +1,255 @@ +--- +description: Signing and encrypting SAML requests + topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- + +# Special Configuration Scenarios: Signing and Encrypting SAML Requests + +To increase the security of your transactions, you can sign or encrypt both your requests and your responses in the SAML protocol. In this article you'll find configurations for specific scenarios, separated under two use cases: + +- Auth0 as the SAML **service provider** (i.e. a SAML **Connection**) +- Auth0 as the SAML **identity provider** (i.e. an **Application** configured with the **SAML Web App Addon**) + +## Auth0 as the SAML Service Provider + +These scenarios apply when Auth0 is the SAML Service Provider, i.e. Auth0 connects to a SAML identity provider by creating a SAML connection. + +### Sign the SAML Authentication Request + +If Auth0 is the SAML **service provider**, you can sign the authentication request Auth0 sends to the IdP as follows: + +1. For the Connection in which you're interested, navigate to **Enterprise** -> **SAMLP Identity Provider** -> **Settings**. +2. Enable the **Sign Request** toggle. +3. Download the certificate beneath the **Sign Request** toggle and provide it to the IdP so that it can validate the signature. + +#### Enable/Disable Deflate Encoding + +By default, SAML authentication requests are sent via HTTP-Redirect and use deflate encoding, which puts the signature in a query parameter. + +To turn off deflate encoding, you can make a [PATCH call to the Management API's Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) and set the `deflate` option to `false`. + +::: note +Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it. +::: + +Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID` + +Payload: + +```json +{ + { + "options" : { + [...], // all the other connection options + "deflate": false + } +} +``` + +### Use a custom certificate to sign requests + +By default, Auth0 uses the tenant private key to sign SAML requests (when the **Sign Request** toggle is enabled). You can also provide your own private/public key pair to sign requests coming from a specific connection. + +You can generate your own certificate and private key using this command: + +```shell +openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crt +``` + +Changing the key used to sign requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `signing_key` property to the `options` object, as shown in the payload example below. + +::: note +Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it. +::: + +Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID` + +Payload: + +```json +{ + { + "options" : { + [...], // all the other connection options + "signing_key": { + "key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----", + "cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----" + } + } +} +``` + +See [Working with private and public keys as strings](#working-with-certificates-as-strings) for details on how to get the private key and certificate formatted as a JSON string to use in the payload. + +### Receive Signed SAML Authentication Responses + +If Auth0 is the SAML **service provider**, all SAML responses from your identity provider should be signed to indicate it hasn't been tampered with by an unauthorized third-party. + +You will need to configure Auth0 to validate the responses' signatures by: + +* Obtaining a signing certificate from the IdP +* Loading the certificate from the IdP into your Auth0 Connection (in the Management Dashboard, go to the **Upload Certificate** section for your Connection by navigating to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** -> **Settings**) + +Auth0 can accept a signed response for the assertion, the response, or both. + +### Receive Encrypted SAML Authentication Assertions + +If Auth0 is the SAML **service provider**, it may need to receive encrypted assertions from an identity provider. To do this, you must provide tenant's public key certificate to the IdP. The IdP encrypts the SAML assertion using the public key and sends it to Auth0, which decrypts it using the tenant's private key. + +To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}), go to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** and click on the **Setup Instructions** button next to the connection. + +Navigate to the section titled **Encrypted Assertions** and download the certificate in the format requested by the IdP. + +### Use your own key pair to decrypt encrypted responses + +As noted above, Auth0 will by default use your tenant's private/public key pair to handle encryption. You can also provide your own public/private key pair if an advanced scenario requires so. + +Changing the key pair used to encrypt and decrypt requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `decryptionKey` property to the `options` object, as shown in the payload example below. + +::: note +Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it. +::: + +Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID` + +Payload: + +```json +{ + { + "options" : { + [...], // all the other connection options + "decryptionKey": { + "key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----", + "cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----" + } + } +} +``` + +The SAML metadata available for the connection will be updated with the provided certificate, so that the identity provider can pick it up to sign the SAML response. + +## Auth0 as the SAML Identity Provider + +This scenarios apply when Auth0 is the SAML Identity Provider for an application. This is represented in the dashboard by an **Application** that has the SAML Web App Addon enabled. + +### Sign the SAML Responses/Assertions + +If Auth0 is the SAML **identity provider**, it will sign SAML assertions with the tenant's private key and provide the service provider with the public key/certificate necessary to validate the signature. + +To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}): + +1. Go to **Applications** -> **Settings** -> **Show Advanced Settings**. +2. Scroll to the *Certificates* section, and click **Download Certificate* to obtain the signing certificate you need to provide to your IdP. +3. Send your certificate to the service provider. + +By default, Auth0 signs the SAML **assertion** within the response. If you want to sign the SAML **response** instead, follow this instructions: + +1. In the [Management Dashboard](${manage_url}), navigate to **Applications**. Find the Application you're interested in go to **Addons** > SAML2 WEB APP > Settings. +2. Look for the `"signResponse"` key. Add it or uncommented if required, and set its value to `true` (the default value is `false`). The configuration should look like this: + +```json +{ + [...], // other settings + "signResponse": true +} +``` + +#### Change the signing key for SAML responses + +Auth0 will by default use the private/public key pair assigned to your tenant to sign SAML responses or assertions. For very specific scenarios you might wish to provide your own key pair. You can do so with a rule like this: + +```javascript +function (user, context, callback) { + // replace with the ID of the application that has the SAML Web App Addon enabled + // for which you want to change the signing key pair. + var samlIdpClientId = 'YOUR_SAML_APP_CLIENT_ID'; + // only for a specific client + if (context.clientID !== samlIdpClientId) { + return callback(null, user, context); + } + + // provide your own private key and certificate here + context.samlConfiguration.cert = "-----BEGIN CERTIFICATE-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END CERTIFICATE-----\n"; + context.samlConfiguration.key = "-----BEGIN PRIVATE KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END PRIVATE KEY-----\n"; + + callback(null, user, context); +} +``` + +Take a look at [Working with certificates as strings](#working-with-certificates-as-strings) for information on how to turn the private key and certificate files into strings that you can use in a rule. + +### Receive Signed SAML Authentication Requests + +If Auth0 is the SAML **identity provider**, it can received requests signed with the service provider's private key. Auth0 will then use the service providers' public key/certificate to validate the signature. + +To configure signature validation, you'll need to download the service provider's certificate with the public key and store the value in the `signingCert` key of the SAML Web App Addon `options` JSON object. You can find the `options` JSON object field in the [Management Dashboard](${manage_url}) by going to **Applications** > **Addons** > **SAML2 WEB APP** > **Settings**. + +The configuration should look like this: + +```json +{ + [...], // other settings + "signingCert": "-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n" +} +``` + +### Send Encrypted SAML Authentication Assertions + +If Auth0 is the SAML **identity provider**, you can use [Rules](/rules) to encrypt the SAML assertions it sends. + +You'll need to obtain the certificate and the public key from the service provider. If you only got the certificate, you can derive the public key using `openssl`. Assuming that the certificate file is named `certificate.pem` you can do: + +```shell +openssl x509 -in certificate.pem -pubkey -noout > public_key.pem +``` + +Once you get the certificate and public key files, you'll need to [turn them into strings](#working-with-certificates-as-strings) to use them in a rule. The rule will look like this: + +```js +function (user, context, callback) { + // this rule sets a specific public key to encrypt the SAML assertion generated from Auth0 + if (context.clientID === 'THE_CLIENT_ID_OF_THE_APP_WITH_THE_SAML_APP_ADDON') { + context.samlConfiguration = (context.samlConfiguration || {}); + context.samlConfiguration.encryptionPublicKey = "-----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PUBLIC KEY-----\n"; + context.samlConfiguration.encryptionCert = "-----BEGIN CERTIFICATE-----\nnnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n"; + } + callback(null, user, context); +} +``` + +The following algorithms are used: + +* AES256 (`http://www.w3.org/2001/04/xmlenc#aes256-cbc`) for assertion encryption +* RSA-OAEP (including MGF1 with SHA1, `http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p`) for key transport + +## Working with certificates as strings + +When working with certificates or keys in rules or Management API v2 requests, you will most likely require a string representation of the file. + +If you open a certificate file (`cer`, `pem`) with a text editor, you'll see something like this: + +``` +-----BEGIN CERTIFICATE----- +MIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh +cjEZMBcGA1UEAwwQaHR0cHM6Ly9uaWNvLmNvbTAeFw0xOTA0MDgxODA3NTVaFw0y +// +// more lines of base64-encoded information +// +nSWyabd+LiBGtLTMB+ZLbOIi3EioWPGw/nHOI8jzPrqhiCLuZCSQmiqrLQYNsc1W +-----END CERTIFICATE----- +``` + +The lines between the `-----BEGIN CERTIFICATE-----` header and `-----END CERTIFICATE-----` footer contain base64-encoded binary information. Public keys and private keys (`.key` files) will look similar, with just a different header/footer. + +For a string representation of a certificate/key file, you will need to concatenate everything in one line, with a `\n` (escaped new-line) sequence replacing the actual new lines in the file. So from the above sample you'd obtain something like this: + +``` +"-----BEGIN CERTIFICATE-----\nMIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh\n[..all the other lines..]-----END CERTIFICATE-----\n" +``` diff --git a/fr-ca/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md b/fr-ca/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md new file mode 100644 index 0000000000..64d9449197 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md @@ -0,0 +1,24 @@ +--- +description: Supported SAML bindings and options +topics: + - saml + - saml-bindings +contentType: + - reference +useCase: + - add-idp +--- + +# Supported SAML Bindings and Options + +Auth0 supports the following SAML bindings: + +* HTTP Redirect +* HTTP POST + +Auth0 supports the following SAML options: + +* Web Browser SSO Profile +* Single Logout Profile +* Name Identifier Management Profile +* Name Identifier Mapping Profile diff --git a/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md new file mode 100644 index 0000000000..39fa5e5c5b --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md @@ -0,0 +1,140 @@ +--- +description: How to troubleshoot SAML-related configuration issues when Auth0 is the identity provider +toc: true + topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- + +# Troubleshooting SAML when Auth0 is the Identity Provider + +When troubleshooting a SAML login, there are four primary stages to check: + +* Stage 1: The user is successfully redirected to IDP and is able to login. +* Stage 2: After login with the IDP, the user returns to Auth0 with a successful login event recorded. +* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct. +* Stage 4: The user successfully redirects back to application and is able to access application. + +The following sections describe how to check each stage and how to identify if there are any issues with a given stage. + +## A successful login event does not show up in Auth0 logs + +In this case, the user successfully logs in with the idp, but a successful login event does *not* show up in auth0 logs. + +* If you're using an Auth0 Database Connection: + + * Check that the user exists and the entered password is correct. + + * Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process. + + * If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process. + +* If you're using an Auth0 Database Connection **or** a remote SAML connection: + + * Check that the SAML Connection works by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display). + +## The user's profile attributes are incorrect + +In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, but the user's profile attributes are incorrect. + +If the user: + +* Appears to log in successfully + +* The [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard should successful login events + +The next step is to check that the user's profile contains the necessary user profile attributes. + +### Checking the user profile + +1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users). + +2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection. + +3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider. + +If an attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0. + +## The user cannot access the application + +In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, and the user's profile attributes are correct, but the user cannot access the application. + +* Check to see if the user's Auth0 profile populated correctly: + + 1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users). + + 2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection. + + 3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider. Ensure that the profile includes all of the details required by the application. + + If a user attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0. + +* Check the application's log files to see if there are any error messages indicating why the user is unable to access the application. The two most common causes for this issue are missing user profile information or incorrect/missing authorization information. + +* Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files). To analyze the HTTP trace: + + 1. View the trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). + + 2. Scan through the sequence of URLS invoked in the HTTP trace: + + * The first few will be URLs for your application. + + * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`). + + * After one or more intervening URLS, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information. Be sure that the assertion includes this information: + + 1. Click on the row for the POST call in the HAR analyzer. + + 2. Switch to the POST Data tab, and look for the SAML response. + + 3. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/). + + 4. Remove the SAML response at the beginning, as well as anything beginning with `&RelayState=` at the end. + + 5. Click **Decode SAML message** and check the following fields: + + * **Destination**: the application URL that consumes the SAML assertion (and is also known as the Assertion Callback URL) + + * **Status Field**: this field should indicate success: `` + + * **Recipient**: the correct URL appears in the recipient field (indicated by th `urn:{DOMAIN}:{YOUR APPLICATION}` + + * **Naming**: the attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address) + + * **Signature Key**: check that the value indicated by the `X509Certificate` element matches the value provided to your connection + + * **Certificate**: compare the certificate sent to the one that you provided to the application + +* Ensure that the SAML assertion contains any additional information required by the application and that the information is present in the attributes expected by the application. + + * If you need to alter the assertion sent from Auth0 to your application, you can add or map attributes using [rules](/rules). + + * Log into Auth0 and [navigate to Rules](${manage_url}/#/rules). + + * Click **Create Rule** and, in the next page, choose the **Change your SAML configuration** template. + + * In the rules editor, uncomment the lines you want to use. Lines 9-17 in the template can be used to map attributes as needed. You can also add lines to implement mappings. The left side of each line specifies the identifier for the attribute in the assertion. The right side of each line references the Auth0 user profile attribute whose value will be used to populate the outgoing assertion sent to the application. + + ```text + //context.samlConfiguration.mappings = { + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "user_id", + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "email", + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "name", + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "given_name", + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "family_name", + // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "upn", + // "http://schemas.xmlsoap.org/claims/Group": "groups" + // }; + ``` + + ![](/media/articles/protocols/saml/saml-configuration/saml-rules.png) + +## When I try to logout I get the error: No active session(s) found matching LogoutRequest + +The `SessionIndex` and `NameID` values in the SAML Logout request need to match the ones received by the service provider in the original SAML assertion. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md new file mode 100644 index 0000000000..b80302d710 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md @@ -0,0 +1,212 @@ +--- +description: How to troubleshoot SAML-related configuration issues when Auth0 is the service provider +toc: true +topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- + +# Troubleshooting SAML when Auth0 is the Service Provider + +When troubleshooting a SAML login, there are four primary stages to check: + +* Stage 1: The user is successfully redirected to an identity provider (IdP) and is able to login. +* Stage 2: After login with the IdP, the user returns to Auth0 with a successful login event recorded. +* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct. +* Stage 4: The user successfully redirects back to application and is able to access application. + +The following sections describe how to check each stage and how to identify if there are any issues with a given stage. + +## Issue: The IdP Login Page Doesn't Display + +### Test the Connection + +Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Try** (represented by the triangle icon) next to the Connection to test the interaction between Auth0 and the remote IdP. + +If the Connection does **not** work, continue with the steps detailed in this section. If it does, [proceed to the next section](#). + + ![](/media/articles/protocols/saml/saml-configuration/test-connection.png) + +### Check the Connection's Settings + +Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Settings** (represented by the gear icon) to launch the tab associated with your Connection. + + ![](/media/articles/protocols/saml/saml-configuration/check-connection-settings.png) + +Check and confirm the following with the IdP administrator: + +* That the Sign In URL is the correct Single Sign-on (SSO) URL. This is the URL that Auth0 will redirect the user to for authentication. +* If the IdP expects HTTP-POST binding or HTTP-Redirect binding. You can switch the default binding in the __Settings__ tab. +* If your authentication requests should be signed. If so, which signing algorithm does the IdP expect you to use? (Note that authentication requests are not commonly signed.) If you're sending signed requests, enable the Connection Settings **Sign Request** toggle and make sure the **Signing Algorithm** value matches what the IdP expects. +* Ask the IdP administrator to check for log entries that might provide information on the problem. + +## Issue: Auth0 Logs Don't Show Successful Login Event + +In this case, the user successfully logs in with the identity provider, but the Auth0 logs do not show a successful login event. You can check the [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard to see if Auth0 shows a successful login event. + +If Auth0's logs don't show a successful login event, there is probably an issue with the SAML Authentication Assertion returned by the IdP or Auth0 is unable to consume the assertion. + +### Check the SAML Authentication Assertion + +Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace. + +#### Retrieve the Assertion + +You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). + +1. First, scan through the sequence of URLs invoked in the HTTP trace. + * The first few will be URLs for your application. + * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`). +2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of Auth0, which consumes the assertion and extracts the needed information. +3. Click on the row for the POST call in the HAR analyzer. +4. Switch to the POST Data tab, and look for the SAML response. +5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/). +6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end. + +#### Check the Assertion + +After retrieving and decoding the SAML message, check the following fields: + +Field | Description +------|------------- +Destination | Check that the destination for the SAML response is the correct Auth0 Tenant and Connection (`https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}`). +Status Field | This field should indicate success. (``). +Recipient | Check that the `urn:auth0:{TENANT}:{CONNECTION}`). +Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address). +Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection. +Certificate | Compare the certificate sent to the one that you provided to the application + +## Issue: The User's Profile Attributes are Incorrect + +In this case the user successfully logs in with the IdP, the Auth0 logs show a successful login event, but the user's profile attributes are __not__ correct + +Check to see if the user's Auth0 profile populated correctly: + + 1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users). + + 2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection. + + 3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider. + +### If the User Profile Attribute is Missing + +If the attribute is missing, check to see if the attribute was included in the assertion. You can do this by [decoding the SAML assertion](#), or you can enable debugging for the connection. + +To enable debugging for the connection, navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and enable **Debug Mode**. + +![](/media/articles/protocols/saml/saml-configuration/debug-connection.png) + +With **Debug Mode** enabled, **Success Login** log entries [in the dashboard](${manage_url}/#/logs) will have an `original_profile` property listing every attribute included in the SAML assertion by the Identity Provider. You can use this list to see the information that the IdP is sending and to help you create the mappings. If the missing attribute is not in the assertion at all, please work with the IdP to make sure it is included. + +### If the User Profile Attribute is Incorrectly Mapped + +If an attribute value exists in the Auth0 user profile, but is not mapped to the right attribute, you can correct this via the Connection Mapping capability. + +You can do this by navigating to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and switching over to the **Mappings** tab. + +![](/media/articles/protocols/saml/saml-configuration/mappings.png) + +Within the provided editor, there is a JSON snippet you can edit to configure your mappings. The name on the left is the Auth0 user profile attribute to which the assertion value will be mapped. The value on the right is the identifier in the SAML assertion from which the attribute comes. + +::: warning +When Auth0 incorporates unmapped SAML attributes into the user profile, attribute identifiers containing dots `.` are replaced with semicolons `:`. While configuring your mappings, ensure the identifiers you provide match those in the SAML assertion. +::: + +## Issue: The User Cannot Access the Application + +In this case the user successfully logs in with the identity provider, Auth0 logs show a successful login event, and the user's profile attributes are correct; but the user __cannot__ access the application. + +### Check the Application Logs + +Check your application's log files to see if there are any error messages indicating why the user is unable to access the application. + +The two most common causes for this issue are: + +* Missing user profile information +* Incorrect or missing authorization information. + +### Check the SAML Assertion + +Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace. + +#### Retrieve the Assertion + +You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). + +1. First, scan through the sequence of URLs invoked in the HTTP trace. + * The first few will be URLs for your application. + * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`). +2. After one or more intervening URLs, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information. +3. Click on the row for the POST call in the HAR analyzer. +4. Switch to the POST Data tab, and look for the SAML response. +5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/). +6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end. + +#### Check the Assertion + +After retrieving and decoding the SAML message, check the following fields: + +Field | Description +------|------------- +Destination | The application URL that consumes the SAML assertion, also known as the Assertion Callback URL. +Status Field | This field should indicate success. (``). +Recipient | Check that the correct URL appears in the recipient field (indicated by the `urn:auth0:{TENANT}:{CONNECTION}`). +Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address). +Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection. +Certificate | Compare the certificate sent to the one that you provided to the application. + +### Check the ID Token + +If your authorization flow uses an OIDC-conformant protocol, you can [capture a HAR trace](/troubleshoot/guides/generate-har-files) and view it using [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). + +1. Scan through the sequence of URLs in the trace, and look for the following: + + * The first few will be URLs for your application. + + * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`). + +2. Further down is your application's callback URL. Make sure that it's correct. + +3. Retrieve the ID Token from this call, and paste it into [a JWT decoder](https://jwt.io/). Check that the claims in the token contain the information needed by the application. + +### Troubleshooting IdP-initiated Flows + +If you're using an IdP-initiated flow (for example, the user starts at the identity provider in a portal application), be sure that: + +* The Assertion Consumer Service (ACS) URL at the identity provider includes the connection name (for example `https://${account.namespace}/login/callback?connection=CONNECTION_NAME`) + +* The IdP-initiated configuration tab for the Connection is properly filled in, including: + + * The application to which the user should be sent; + + * The protocol between the application and Auth0 (which is not necessarily **SAML** like the connection, and most likely is **OpenID Connect**); + + * Any protocol-specific values to include in the query string, such as `scope`, `response_type`, `redirect_uri`, and `audience`. These values should match the ones expected by the application when using a SP-initiated flow. + +* Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process. + +* If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process. + +* Check that the SAML Connection works in an SP-Initiated flow by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display). + +## Error: The request could not be performed due to an error on the part of the SAML responder or SAML authority + +The error may appear as follows: + +```text + + + +``` + +### How to Fix + +Make sure that the signature algorithm on your Auth0 connection is the same as the configuration on the ADFS side: either `rsa-sha256` or `rsa-sha1`. Alternatively you can contact your ADFS administrator to learn the expected signing method or to see if their logs contain further information about the reason for the error. + +![ADFS SAML Properties](/media/articles/protocols/saml-adfs/adfs-saml-properties.png) diff --git a/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md new file mode 100644 index 0000000000..6f438059d8 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md @@ -0,0 +1,102 @@ +--- +description: Common SAML errors and troubleshooting steps +topics: + - saml + - sso + - errors +contentType: + - reference + - how-to +useCase: + - add-idp +--- + +# Common SAML Errors + +This article covers SAML errors you might encounter when Auth0 acts as the service provider and the steps you should take to resolve them. + +## Error: The Connection was Disabled + +```json +{ + "error": "invalid_request", + "error_description": "the connection was disabled" +} +``` + +This message indicates that the Application doesn't have an active Connection associated. + +### How to Fix + +1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). +2. Find your Connection, and click on **Settings**. +3. Switch to the *Applications* tab. +4. Enable at least one Application (if you don't see any in the list, you will need to [create an application](/applications) before proceeding). + +## Error: IdP-Initiated Default App Not Configured + +```json +{ + "invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter." +} +``` + +This error typically occurs because the ACS URL configured in the IdP used the default Auth0 tenant domain, whereas the authentication transaction was started by calling the custom domain `/authorize` endpoint. + +The ACS URL should use the same domain as the initial authentication request. If using custom domains, this should use the custom domain callback URL. + +### How to Fix + +1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). +2. Find your Connection, and click on **Settings**. +3. Switch to the **IdP-Initiated** tab. +4. Select the **Default Application** and the **Response Protocol** used by that Application, and (optionally) specify any additional parameters you want passed to the Application. + +::: panel SP-Initiated Login +If you see this error when using a SP-initiated flow, one of the following is missing or empty: + +* The `RelayState` parameter +* The `InResponseTo` attribute in the SAML response + +If these are missing or empty, Auth0 treats the login as IdP-initiated. You can fix this error by checking your configuration to ensure that both fields are populated and returned appropriately. +::: + +## Error: Missing RelayState + +This error occurs when the identity provider doesn't return the `RelayState` parameter along with its response. + +### How to Fix + +Work with the identity provider to ensure that it returns the `RelayState` parameter. + +## Error: Audience is Invalid + +This error occurs if the value of the `audience` element from the identity provider's SAML response doesn't match the value expected by Auth0. Auth0 expects the value to be the Entity ID for the Connection. + +**Find Your Connection's Entity ID** + +1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). Find your Connection, and click on **Setup Instructions**. +2. Under the *Common Settings* section, your **Entity ID** is the second parameter provided. + +### How to Fix + +Make sure that the identity provider sends the correct `audience` value in the SAML response. + +## Error: Specifying the Incorrect Protocol + +One common error is specifying the incorrect response protocol on the IdP-Initiated tab. The response protocol is the one used between Auth0 and the Application (not the remote identity provider). For example, if you set this value to **SAML** when your Application expects **OpenID Connect** or **WS-Fed** results in errors due to the incorrect configuration. + +### How to Fix + +1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). +2. Find your Connection, and click on **Settings**. +3. Switch to the *IdP-Initiated* tab. +4. Check the value you have set in the **Response Protocol** field. + +## Issue: User isn't logged out from the IdP + +When ADFS is configured as SAML IdP, if the ADFS is relaying party trust `Name ID` attribute isn't mapped the logout flow fails. For example, with the federated parameter `v2/logout?federated&...` user isn't redirected to the ADFS SAML logout endpoint but redirects back to application callback URL directly. As a consequence, the user isn't logged out from the IdP in that case. + +### How to Fix + +Add the `Name ID` attribute as a rule on the SAML Relaying Party Trust. diff --git a/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/index.md b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/index.md new file mode 100644 index 0000000000..044c1a5c7c --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-configuration/troubleshoot/index.md @@ -0,0 +1,88 @@ +--- +description: Describes troubleshooting for SAML configuration issues. +toc: true +topics: + - saml + - sso +contentType: + - index + - reference +useCase: + - add-idp +--- + +# Troubleshoot SAML Configuration + +This guide serves to help you troubleshoot any issues that may arise during the SAML configuration process. It is not intended to be an exhaustive guide, but one that covers the most commonly encountered issues during setup. + +## Understand the Situation + +When troubleshooting, it's important that all parties involved are using the same terminology to facilitate understanding. This section describes key vocabulary and situations that will be referred to later in this guide. + +* **Is Auth0 serving as the SAML Service Provider (SP), the SAML Identity Provider (IdP), or both?** + + Generally speaking, the SP redirects users elsewhere for authentication. The IdP authenticates the user by prompting them to login and validating the information provided. If your application redirects the user to Auth0 for authentication via SAML, then Auth0 is the IdP. If Auth0 redirects users via a Connection to a remote IdP via SAML, then Auth0 is the SP to the remote IdP. + + Auth0 can act as the SP, IdP, or both. + +* **Does your authentication flow use an SP-initiated model, an IdP-initiated model, or both?** + + SP-initiated authentication flows begin with the user navigating to the SP application and getting redirected to the IdP for login. An IdP-initiated flow means the user navigates to the IdP, logs in, and then gets redirected to the SP application. + + Within enterprise settings, the IdP-initiated flow is most common. + +* **Which user profile attribute identifies the user at the IdP (during login) and within each application?** + + If the naming attribute differs between the IdP and the application(s), you'll need to configure the appropriate mappings within Auth0 so that it sends the correct user profile attributes to the application(s). + + * From our experience, using the email address as the unique identifier is the easiest option, though there are privacy concerns with this option. + * Enterprise organizations often use an internal ID of some type with the IdP, which needs to be mapped to another attribute meaningful to outsourced SaaS applications. + +* **Are your authentication requests signed?** +* **Are your authentication assertions encrypted?** + +## Information Gathering + +When troubleshooting, we recommend beginning by gathering information that helps answer the following questions: + +1. How many users experience the issue? Just one user? All users? +2. Is this an issue with a new setup, or is this an existing integration that's stopped working? +3. How many applications does the issue affect? +4. What is the expected behavior? What is the behavior you're seeing? +5. How far through the login sequence does the user get? + +## Troubleshooting approaches + +* [Troubleshooting SAML when Auth0 is the Service Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp) +* [Troubleshooting SAML when Auth0 is the Identity Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp) + +## If the Issue Affects Only One (or Just a Few) Users + +* Check the user's profile, browser, or device for any issues. +* Check to see if it happens in all browsers for the affected users (indicating a data issue) or just certain types of browsers (indicating a browser-specific issue). +* Check to see if the browser has enabled JavaScript and cookies. +* Check that the caps lock key is disabled. +* If the user is using a mobile device, check to see if there's any software that might impact authentication and/or authorization (such as not running some type of required software). +* Check to see if the user can access some of the app's key URLs, such as the IdP's Single Sign-on (SSO) URL (indicating a network connectivity issue). + +## Next Steps + +If the troubleshooting steps listed above don't solve the issue you're seeing, please request assistance from Auth0 by opening up a ticket in the Support Center. Be sure to include the following information: + +1. The number of users experiencing this issue. One? All? +2. Whether this issue involves a new setup or if it involves an existing integration that suddenly stopped working +3. The number of applications affected +4. What the expected behavior is, as well as what the current behavior is +5. How far through the login sequence the user gets +6. The name of the application registered in Auth0 and the identity protocol it uses +7. The name of the Connection involved +8. Whether or not you're using the Auth0 Lock widget (if so, what version?) +9. Is a customized version of Lock used? +10. An HTTP trace of the SSO interaction in [a .har file](/troubleshoot/guides/generate-har-files) +11. An Auth0 log entry for the failed authentication +12. An authentication log file from any third-party applications (such as Sharepoint) involved + +### Keep reading + +* [Common SAML Errors](/protocols/saml/saml-configuration/troubleshoot/common-saml-errors) + diff --git a/fr-ca/articles/protocols/saml/saml-idp-eloqua.md b/fr-ca/articles/protocols/saml/saml-idp-eloqua.md new file mode 100644 index 0000000000..89817dd1d3 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-idp-eloqua.md @@ -0,0 +1,103 @@ +--- +description: How to configure Auth0 to serve as an Identity Provider for Oracle Eloqua. +topics: + - saml + - oracle + - eloqua +contentType: + - how-to +useCase: + - add-idp +--- + +# Configure Auth0 as Identity Provider for Oracle Eloqua + +These instructions explain how to configure Auth0 to serve as an Identity Provider for [Oracle Eloqua Marketing Cloud](http://www.oracle.com/partners/en/products/applications/eloqua-marketing-cloud-service/get-started/index.html). + +## Configure the Addon: SAML2 Web App + +Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). + +Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch. + +![Application Addons](/media/articles/protocols/saml/eloqua/client-addons.png) + +The *Settings* window will be displayed. Set the following values: + +- **Application Callback URL**: `https://login.eloqua.com/auth/saml2/acs` + +- **Settings**: + + ```text + { + "audience": "http://foo", + "recipient": "https://login.eloqua.com/auth/saml2/acs", + "mappings": { + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", + "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", + "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", + "groups": "http://schemas.xmlsoap.org/claims/Group" + }, + "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ], + "destination": "https://login.eloqua.com/auth/saml2/acs" + } + + ``` + +Note that the `audience` is set to `http://foo`. This will be changed when the Identity Provider settings are completed on the Eloqua side. + +Click **Save**. + +Go to the *Usage* tab and download the Identity Provider metadata. This IDP metadata will be used while setting up the configuration in Eloqua. + +![Download Identity Provider Metadata](/media/articles/protocols/saml/eloqua/download-idp-metadata.png) + +## Configure Oracle Eloqua + +Login as Admin on Eloqua and click on *Settings > Users > Single Sign-On > Identity Provider Settings*. + +Click **Upload Identity Provider from Metadata**. You should upload here the Identity Provider metadata you downloaded in the previous from the Auth0 dashboard. + +![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-1.png) + +Browse to find the downloaded metadata file. + +![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-2.png) + +Edit the newly added identity provider and complete the following steps: + +- Set the **User Identity Mapping** to `Assertion contains the Email Address from the User object` and click **Save**. + +- From the *Identity Provider Details* copy the **Service Provider Entity URL**. + +- Within ELOQUA IDP settings, if this is the default IDP, mark this IDP as default. + + +## Update the Audience Restriction + +We will now use the **Service Provider Entity URL** copied from within the IDP settings in Eloqua to set the `audience` restriction within Auth0. + +Navigate to __Dashboard > Applications > select your application > Addons > SAML2 Web App > Settings__ and set the `audience` to the value you copied. + +## Test + +Login to Eloqua with Auth0 should be enabled now. You can sign in to Eloqua with both IDP initiated login and SP initiated login. + +### SP Initiated Login + +Navigate to [https://login.eloqua.com/auth/saml2](https://login.eloqua.com/auth/saml2) , enter your company name and start the SAML login process with Auth0. + +![Eloqua SP Initiated Login](/media/articles/protocols/saml/eloqua/sp-login.png) + + +### IdP Initiated Login + +For IDP Initiated login use the **Identity Provider Login URL** defined under the **Dashboard > Applications > select your application > Addons > SAML 2 Web App > Usage**. + +![Eloqua IdP Initiated Login](/media/articles/protocols/saml/eloqua/idp-login.png) diff --git a/fr-ca/articles/protocols/saml/saml-idp-generic.md b/fr-ca/articles/protocols/saml/saml-idp-generic.md new file mode 100644 index 0000000000..5c5576a8e3 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-idp-generic.md @@ -0,0 +1,80 @@ +--- +title: Auth0 as Identity Provider +description: How to configure Auth0 to serve as an Identity Provider in a SAML federation. +toc: true +topics: + - saml +contentType: + - how-to +useCase: + - add-idp +--- +# Auth0 as Identity Provider + +These instructions explain how to configure Auth0 to serve as an Identity Provider in a SAML federation. + +## 1. Obtain Information from the Service Provider + +You will need to obtain from the Service Provider (application) the URL to which the SAML Authentication Assertion should be sent. This may be called **Assertion Consumer Service URL**, **the Post-back URL**, or **Callback URL**. + +## 2. Configure Auth0 as IDP + +In this section you will configure Auth0 to serve as an Identity Provider. You will do this by registering an application and using an addon. + +1. Go to [Dashboard > Applications](${manage_url}/#/applications). +1. Click the **+ CREATE APPLICATION** button on the right. +1. In the **Name** field, enter a name like `MySAMLApp`, and select the [application type](/applications). +1. Click **SAVE**. +1. Go back to [Dashboard > Applications](${manage_url}/#/applications). +1. Find the row for the application you just created, and click on the **Settings** icon to the right of the application name. (the round gear icon) +1. Scroll down and click on the **Advanced Settings** link. +1. In the expanded window, select the **Certificates** tab and click on the **DOWNLOAD CERTIFICATE** button. In the popup which appears, select `PEM` to select a PEM-formatted certificate. The certificate will be downloaded to a file called `${account.tenant}.pem`. Save this file as you will need to upload it when you configure the Service Provider. + ![Download Certificate](/media/articles/saml/saml-idp-generic/saml-idp-generic1.png) +1. Select the **Endpoints** tab and scroll down to **SAML**. Copy the contents of the **SAML Protocol URL** field and save it as you will need to provide it to the Service Provider. + ![SAML Protocol URL](/media/articles/saml/saml-idp-generic/saml-idp-generic2.png) +1. Scroll back up and click on the **Addons** tab. Then click on **SAML2 WEB APP**. + ![SAML2 WEB APP](/media/articles/saml/saml-idp-generic/saml-idp-generic3.png) +1. In the **Application Callback URL** field, enter the URL of the Service Provider (or application) to which the SAML assertions should be sent after Auth0 has authenticated the user. This is the Assertion Consumer Service (ACS) URL. If your Service Provider is sending multiple ACS URLs in the SAML Request, you will need to whitelist them by adding them to the Application's **Allowed Callback URLs** setting in Application Settings. + ![Application Callback URL](/media/articles/saml/saml-idp-generic/saml-idp-generic4.png) +1. In the Addon SAML2 Web App popup, click on the **Usage** tab. This tab will provide you with the information needed to configure the Service Provider application. + ![Usage](/media/articles/saml/saml-idp-generic/saml-idp-generic5.png) + +## 3. Configure the Service Provider + +In this section you will add some information to the Service Provider so they know how to send SAML-based authentication requests to Auth0. + +The instructions provided here are generic. You will need to find the appropriate screens and fields on the Service Provider. + +If the Service Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above (**Applications > Addons > Usage**). + +If the Service Provider does not support uploading a metadata file, you can configure it manually, using the information from the Auth0 **Applications > Addons > Usage** screen as follows: + +- **Identity Provider Login URL**: This is the URL to which the Service Provider should send its SAML Authentication Requests. + +Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, instead of using a URL in the format of `https://[YOUR TENANT].auth0.com/samlp/CLIENTID?connection=Username-Password-Authentication` you will want to use one in this format: `https://[YOUR CUSTOM DOMAIN]/samlp/CLIENTID?connection=Username-Password-Authentication`. + +If the Service Provider also has a field for a Logout URL, you can enter the same **Identity Provider Login URL**. Both login and logout are handled by the same URL. + +The Service Provider will need a certificate from Auth0. + +You can download this certificate from the **Applications > Addons > Usage** screen. This certificate will be used to validate the signature of the SAML Authentication Assertions sent from Auth0 to the Service Provider. + +If the Service Provider asks for an Issuer, this can also be obtained from the same screen. + +## 4. Test + +Once you have completed the above configuration, test the login. + +If the Service Provider has been configured correctly, it should redirect the user browser to Auth0 for login. After authenticating the user, Auth0 should redirect the user browser back to the application. + +## 5. Troubleshooting + +This section has a few ideas for things to check if your sample doesn't work. + +- If your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution. + +- When troubleshooting Single Sign-on (SSO), it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis. Search for `HTTP Trace` to find some. Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from the Service Provider to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider application. + +- Make sure cookies and javascript are enabled for your browser. + +- The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool. diff --git a/fr-ca/articles/protocols/saml/saml-sp-generic.md b/fr-ca/articles/protocols/saml/saml-sp-generic.md new file mode 100644 index 0000000000..2a110ab059 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml-sp-generic.md @@ -0,0 +1,180 @@ +--- +description: How to configure Auth0 to serve as a Service Provider in a SAML federation. +toc: true +topics: + - saml +contentType: + - how-to +useCase: + - add-idp +--- + +# Auth0 as Service Provider + +These instructions explain how to configure Auth0 to serve as a Service Provider in a SAML federation. + +There are **5 sections**, including a troubleshooting section at the end. + +1. Obtain information from IDP +2. Configure Auth0 as Service Provider +3. Add your Service Provider metadata to the Identity Provider +4. Test the connection from Service Provider to Identity Provider +5. Troubleshooting + +## 1. Obtain information from IDP + +You will need to obtain some information from the Identity Provider. The instructions here will be generic. You will have to locate this information in your specific Identity Provider. + +* **SSO URL** - The URL at the Identity Provider to which SAML authentication requests should be sent. This is often called a Single Sign-on (SSO) URL. +* **Logout URL** - The URL at the Identity Provider to which SAML logout requests should be sent. This is often called a logout URL, a global logout URL or single logout URL. +* **Signing certificate** - The Identity Provider will digitally sign authentication assertions and the signing certificate is needed by the Service Provider to validate the signature of the signed assertions. There should be a place to download the signing certificate from the Identity Provider. If the certificate is not in .pem or .cer format, you should convert it to one of those formats. + +## 2. Configure Auth0 as Service Provider + +In this section you will configure Auth0 to serve as a SAML Service Provider. + +**In the Auth0 dashboard:** + +1. Click on **"Connections"** link at left. +1. In the list of options below "Connections", click on **"Enterprise"**. +1. Click on the **"Create Connection"** button. + +In the **"New SAML Connection"** window, enter the following information: + +- **Connection Name:** You can enter any name, such as `SAML-SP`. +- **Display Name:** If a value is provided, Universal Login will have the button say "Continue with (Display Name)". +- **IdP Domains:** (optional) Provide a comma-separated list of the domains that can be authenticated in the Identity Provider. This step is only needed for identifier-first authentication flows If you leave this field blank, users with any email domain can use the IdP. +- **Sign In URL:** Enter the **SAML SSO URL** that you obtained from the Identity Provider. +- **Sign Out URL:** Enter the **SAML Logout URL** obtained from the Identity Provider. +- **Certificate:** Click on the red **"UPLOAD CERTIFICATE"** button and select the `.pem` file you obtained from the Identity Provider. +- **User Id Attribute**: The attribute in the SAML token that will be mapped to the `user_id` property in Auth0. If not set, then the `user_id` will be retrieved from the following (in listed order): + - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier` + - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` + - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` + +You can ignore the rest of the fields for now. + +Click on the blue **"SAVE"** button at the bottom. + +A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it) + +Click on the **"CONTINUE"** button. + +In the window that appears, metadata about this SAML service provider is displayed. You will need to use the information from this screen to configure the Identity Provider. + +The first bullet is the post-back URL or Assertion Consumer Service (ACS) URL. This is the URL the Identity Provider will send Authentication Assertions to after authenticating a user. Enter this value where the Identity Provider asks for Assertion Consumer Service URL. It may just call this a Service Provider URL. + +The second bullet tells you the **"Entity ID"**. It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__. + +Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. Use this value if the Identity Provider asks for Entity ID or SAML Audience. + +The third bullet indicates the binding that will be used to send the SAML Request from Auth0 to the Identity Provider. If the Identity Provider provides a choice, select HTTP-Redirect as shown on your metadata screen. + +The fourth bullet indicates that Auth0 expects the Identity Provider to respond with an HTTP POST, such as the Authentication Assertion from the Identity Provider will be sent using the HTTP POST binding. If the Identity Provider provides a choice, indicate that HTTP-POST binding should be used for Authentication Assertions. + +The nameid format is the format for the attribute that will be used to identify users. + +In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_. + +In general, you can access the metadata for a SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`. + +Make a note of this metadata URL as you may be able to use it to configure the Identity Provider in the next step. + +## 3. Add your Service Provider metadata to the Identity Provider + +In this section you will add some information to the Identity Provider so the Identity Provider knows how to receive and respond to SAML-based authentication requests from the Auth0 Service Provider. The instructions provided here are generic. You will need to find the appropriate screens and fields on the Identity Provider. + +Locate the screens in the Identity Provider that allow you to configure SAML. + +If the Identity Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above. + +If the Identity Provider does not support uploading a metadata file, you can configure it manually as follows: + +The Identity Provider will need to know where to send the SAML assertions after it has authenticated a user. This is the **Assertion Consumer Service URL** in Auth0. The Identity Provider may call this any of the following: + +* Assertion Consumer Service URL +* Application Callback URL + +```text +https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME +``` + +The `connection` URL parameter is required for identity provider-initiated flows. + +Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, it should be in the format of `https://YOUR_CUSTOM_COMAIN/login/callback?connection=YOUR_CONNECTION_NAME`. + +If the Identity Provider has a field called "Audience" or "Entity ID", you should enter into that field the **Entity ID** from Auth0: + +```text +"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME" +``` + +If the Identity Provider provides a choice for bindings, you should select **HTTP-Redirect** for Authentication Requests. + +The **Single Logout Service URL**, where SAML logout requests and/or responses from the Identity Provider must be sent, should be configured as: + +```text +https://${account.namespace}/logout +``` + +**Signing Logout Requests**: When configuring the Identity Provider, make sure that SAML Logout Requests sent to the Service Provider are signed. + +## 4. Test the connection from Service Provider to Identity Provider + +In this section, you will test to make sure the SAML configuration between Auth0, the Service Provider, and the remote SAML Identity Provider is working. + +* In the [Dashboard](${manage_url}), navigate to: __Connections > Enterprise > SAMLP Identity Provider__. + +* Click on the triangular **Try** button for the SAML connection you created earlier. This button is to the right of the name of the connection. You can hover your mouse over the button to have the text label appear. + +* You will first see a Lock login widget appear that is triggered by the Service Provider. Enter the username. If you entered an email domain in the SAMLP connection configuration, the username should belong to that email domain. + +You will then be redirected to the login screen of the Identity Provider. Login with the credentials for a user that exists in the Identity Provider. + +If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __It works__. This page will display the contents of the SAML authentication assertion sent by the Identity Provider to Auth0 Service Provider. +This means the SAML connection from Auth0 Service Provider to Identity Provider is working. + +If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document. + +::: note +The **Try** button only works for users logged in to the Auth0 dashboard. You cannot send this to an anonymous user to have them try it. +::: + +Here is a sample of the **It Works** screen: + +![](/media/articles/saml/saml-sp-generic/saml-auth0-9.png) + +## 5. Troubleshooting + +This section has a few ideas for things to check if your sample doesn't work. + +Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your HTML page or it may have stale cookies that impact execution. + +When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis. Search for "HTTP Trace" to find some. Once you have an HTTP trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application. + +Be sure to check to make sure cookies and javascript are enabled for your browser. + +Check to make sure that the callback URL specified by your application in its authentication request is listed in the **Allowed Callback URLs** field. + +To do so, go to [Dashboard](${manage_url}), click on __Applications__, then on the __Settings__ icon to the right of the application name. + +The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool. + +## Supported algorithms for signatures + +We currently support the following algorithms for processing XML Digital Signatures: + +* Canonicalization + * 'http://www.w3.org/2001/10/xml-exc-c14n#' + * 'http://www.w3.org/2001/10/xml-exc-c14n#WithComments' + * 'http://www.w3.org/2000/09/xmldsig#enveloped-signature' + +* Signature + + * 'http://www.w3.org/2000/09/xmldsig#rsa-sha1' + * 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' + +* Digest + + * 'http://www.w3.org/2000/09/xmldsig#sha1' + * 'http://www.w3.org/2001/04/xmlenc#sha256' diff --git a/fr-ca/articles/protocols/saml/saml2webapp-tutorial.md b/fr-ca/articles/protocols/saml/saml2webapp-tutorial.md new file mode 100644 index 0000000000..26cc31a6f7 --- /dev/null +++ b/fr-ca/articles/protocols/saml/saml2webapp-tutorial.md @@ -0,0 +1,82 @@ +--- +description: How to use Auth0 in a SAML2 web application. +topics: + - saml + - web-apps +contentType: + - how-to +useCase: + - add-idp +--- + +# Using Auth0 with a SAML2 Web App + +You can configure a SAML2 Web Application for use with an Auth0 Application via the Management Dashboard. + +## Enable the SAML2 Web App Addon for your Auth0 Application + +1. Log in to Auth0, and navigate to the [Applications](${manage_url}/#/applications) page of the [Management Dashboard](${manage_url}). + + ![](/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png) + +2. Identify the Application with which you want to use a SAML2 Web Application. Click the Application's name to go to its configuration settings pages. +3. Go to the *Addons* page for the Application. + + ![](/media/articles/protocols/saml/saml2-web-app/select-addon.png) + +4. In the SAML2 Web App box, click the slider to enable the Addon. You will see a *Settings* page for the Addon. + + ![](/media/articles/protocols/saml/saml2-web-app/configure-addon.png) + +5. To enable the Addon from the Auth0 side, you will need to provide your **Application Callback URL**, which receives the SAML response, as well as the **Settings** for your setup. Within the *Settings* page, there is a sample object that you can use when determining which settings you want to enable: + +```js +{ +// "audience": "urn:foo", +// "recipient": "http://foo", +// "mappings": { +// "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", +// "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", +// "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", +// "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", +// "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", +// "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", +// "groups": "http://schemas.xmlsoap.org/claims/Group" +// }, +// "createUpnClaim": true, +// "passthroughClaimsWithNoMapping": true, +// "mapUnknownClaimsAsIs": false, +// "mapIdentities": true, +// "signatureAlgorithm": "rsa-sha1", +// "digestAlgorithm": "sha1", +// "destination": "http://foo", +// "lifetimeInSeconds": 3600, +// "signResponse": false, +// "typedAttributes": true, +// "includeAttributeNameFormat": true, +// "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", +// "nameIdentifierProbes": [ +// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", +// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", +// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" +// ], +// "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified", +// "logout": { +// "callback": "http://foo/logout" +// } +} +``` + +You can click **Debug** to test if your provided parameters are valid. + +Click **Save** when done. + +## Provide Your Auth0 Application Details to Your SAML2 Web App + +While the specific steps for providing your Auth0 Application details to your SAML2 Web App will vary, you can get the configuration information you need from the *Usage* tab after you have set up the Addon from the Auth0 side. + + ![](/media/articles/protocols/saml/saml2-web-app/usage.png) + +## Passive SAML Requests + +Currently, the SAML2 Web App addon does *not* support passive SAML requests (e.g. where `isPassive=true`). \ No newline at end of file diff --git a/fr-ca/articles/protocols/saml/samlp-providers.md b/fr-ca/articles/protocols/saml/samlp-providers.md new file mode 100644 index 0000000000..b42a172665 --- /dev/null +++ b/fr-ca/articles/protocols/saml/samlp-providers.md @@ -0,0 +1,38 @@ +--- +description: List of Identity Provider services known to support the SAML protocol. +topics: + - saml +contentType: + - reference +useCase: + - add-idp +--- +# List of SAML-P Identity Providers + +This is a list of Identity Provider services known to support the SAML protocol. There may be additional services beyond what is shown below. + +## SAML-P + +The following providers have participated in a Kantara inter-operability test and are therefore likely to conform well to the SAML spec. + + * __adAS__ + * __ADFS__ + * __Dot Net Workflow__ + * __Elastic SSO Team & Enterprise__ + * __Entrust GetAccess & IdentityGuard__ (check protocol supported) + * __EIC__ (check protocol supported) + * __Ilex Sign&go__ + * __iWelcome__ + * __NetIQ Access Manager__ + * __OpenAM__ + * __RCDevs Open SAMPL IdP__ + * __Optimal IdM VIS Federation Services__ + * __Oracle Access Manager__ (Oracle Identity Federation merged into this) + * __PingFederate__ (IDP Light) + * __RSA Federated Identity__ (IDP Light) + * __SecureAuth__ + * __Symplified__ + * __Tivoli Federated Identity Manager__ + * __TrustBuilder__ + * __Ubisecure SSO__ + * __WSO2 Identity Server__ diff --git a/fr-ca/articles/protocols/saml/samlp.md b/fr-ca/articles/protocols/saml/samlp.md new file mode 100644 index 0000000000..3b32321d29 --- /dev/null +++ b/fr-ca/articles/protocols/saml/samlp.md @@ -0,0 +1,74 @@ +--- +title: SAML +description: SAML Identity Provider Configuration +topics: + - saml + - samlp +contentType: + - reference +useCase: + - add-idp +--- + +# SAML Identity Provider Configuration + +## Common settings + +These are the parameters used to configure a SAML Identity Provider (IdP): + +* The __post-back URL__ (also called __Assertion Consumer Service URL__) is: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` +* The __Entity ID__ of the Service Provider is: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (default value). Use `connection.options.entityId` if available. You can obtain this value using the [Get a connection by its id APIv2 endpoint](/api/management/v2#!/Connections/get_connections_by_id): + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ACCESS_TOKEN" + }] +} +``` + +::: note +You need to replace the `ACCESS_TOKEN` header value, with a Management APIv2 Access Token. For information on how to do that see [Access Tokens for the Management API](/api/management/v2/tokens). +::: + +* The __SAML Request Binding__ (also called the __Protocol Binding__): sent to the IdP from Auth0. If possible, dynamically set the value based on `connection.options.protocolBinding`: + +| `connection.options.protocolBinding` value | SAML Request Binding value | +| ---------------------------------------------------- | -------------------------- | +| Empty value ("") or not present | `HTTP-Redirect` | +| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect` | `HTTP-Redirect` | +| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST` | `HTTP-POST` | + +If dynamically setting the value isn't possible, then set as either `HTTP-Redirect` (default) or `HTTP-Post` if you selected this option in **Protocol Binding** + +* The __SAML Response Binding__ : how the SAML token is received by Auth0 from IdP, set as `HTTP-Post` +* The __NameID format__: `unspecified` +* The SAML assertion, and the SAML response can be individually or simultaneously signed. +* The __SingleLogout service URL__, where the SAML Identity Provider will send logout requests and responses, is: `https://${account.namespace}/logout`. SAML logout requests must be signed by the Identity Provider. + +## Signed assertions + +By default, SAML assertions for IdP connections are signed, which we recommend. You can use the following public keys to configure the IdP: + +* [CER](https://${account.namespace}/cer?cert=connection) +* [PEM](https://${account.namespace}/pem?cert=connection) +* [raw PEM](https://${account.namespace}/rawpem?cert=connection) +* [PKCS#7](https://${account.namespace}/pb7?cert=connection) +* [Fingerprint](https://${account.namespace}/fingerprint?cert=connection) + +## IdP-initiated Single Sign-on + +[Click here to learn more about IdP-Initiated Single Sign-on (SSO)](/protocols/saml/idp-initiated-sso) + +## Metadata + +Some SAML Identity Providers can accept importing metadata directly with all the required information. You can access the metadata for your connection in Auth0 here: + +```text +https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME +``` diff --git a/fr-ca/articles/protocols/saml/samlsso-auth0-to-auth0.md b/fr-ca/articles/protocols/saml/samlsso-auth0-to-auth0.md new file mode 100644 index 0000000000..6440d44a11 --- /dev/null +++ b/fr-ca/articles/protocols/saml/samlsso-auth0-to-auth0.md @@ -0,0 +1,340 @@ +--- +description: Learn how to use SAML Single Sign-on (SSO) with Auth0 as both the Service Provider and Identity Provider, using two Auth0 tenants, allowing you to test your Auth0 SAML without configuring another provider to do so. +toc: true +topics: + - saml + - sso +contentType: + - how-to +useCase: + - add-idp +--- + +# SAML SSO with Auth0 as Service Provider and as an Identity Provider + +This tutorial will create a simple example application that uses Auth0 to do SAML Single Sign-on (SSO), using one Auth0 tenant (tenant 1) as a SAML Service Provider(SP), and authenticating users against a second Auth0 tenant (tenant 2) serving as SAML Identity Provider(IDP). This gives you a way to test your Auth0 SAML tenant (tenant 1) configuration, using Auth0 as an IDP so you don't have to learn and set up another IDP. + +There are **9 steps** to this sample and the tenth is a troubleshooting section to help resolve any problems that might arise. + +1. [Establish two Auth0 tenants](#1-establish-two-auth0-tenants) +2. [Set up the Auth0 Identity Provider (IDP) (tenant 2)](#2-set-up-the-auth0-idp-tenant-2-) +3. [Set up the Auth0 Service Provider (SP) (tenant 1)](#3-set-up-the-auth0-service-provider-tenant-1-) +4. [Add your Service Provider metadata to the Identity Provider](#4-add-your-service-provider-metadata-to-the-identity-provider) +5. [Test the Identity Provider](#5-test-identity-provider) +6. [Register a simple HTML application with which to test the end-to-end connection](#6-register-a-simple-html-application-with-which-to-test-the-end-to-end-connection-) +7. [Test the connection from Service Provider to Identity Provider](#7-test-the-connection-from-service-provider-to-identity-provider) +8. [Create the HTML page for the application](#8-create-the-html-page-for-a-test-application) +9. [Test your sample application](#9-test-your-sample-application) +10. [Troubleshooting](#10-troubleshooting) + +## 1. Establish two Auth0 Tenants + +If you do not already have two Auth0 tenants, you will need to create them. If you do already have two tenants, you can skip to step #2. + +### In the Auth0 Dashboard + +In the upper right corner, click on the name of your tenant and in the popup menu which appears, select **+ Create Tenant**. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-01.png) + +In the window which appears, enter a name for your second tenant in the **"Your Auth0 domain"** field and press the **"SAVE"** button. + +You can switch back and forth between the tenants by going to the upper right corner of the dashboard, clicking on the name of the current tenant, and using the popup menu which appears to switch between your tenants. + +## 2. Set up the Auth0 IDP (tenant 2) + +In this section you will configure one Auth0 tenant (tenant 2) to serve as an Identity Provider. You will do this by registering an application, but in this case, the 'application' you register is really a representation of tenant 1, the SAML Service Provider. + +Log into **Tenant 2** + +**In the Auth0 dashboard:** + +1. Click on **"Applications"** link at left. + +2. Click on the red **"+ CREATE APPLICATION"** button on the right. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-02.png) + +3. In the **Name** field, enter a name like "My-Auth0-IDP". + +4. Press the blue **"SAVE"** button. + +5. Click on the **"Settings"** tab. + +6. Scroll down and click on the **"Show Advanced Settings"** link. + +7. In the expanded window, scroll down to the **"Certificates"** section and click on the **"DOWNLOAD CERTIFICATE"** link and select PEM from the dropdown, to download a PEM-formatted certificate. The certificate will be downloaded to a file called "${account.tenant}.pem". Save this file as you will need to upload this file when configuring the other Auth0 tenant, tenant 1. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-03.png) + +8. Click on the **"Endpoints"** tab and go to the **"SAML"** section. Copy the entire contents of the **"SAML Protocol URL"** field and save it as in the next step you will need to paste it into the other Auth0 tenant, tenant 1. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-04.jpg) + +Next, create a user to use in testing the SAML SSO sequence. +**In the Auth0 dashboard:** + +1. Click on the **"+ CREATE YOUR FIRST USER"** button. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-05.png) + +2. In the **Email** field, enter an email for your test user. The domain name for the email should match what you enter in section 3 below. For example, if your user is `john.doe@abc-example.com`, you would enter that here, and then enter "abc-example.com" in step 3 below for the Email domain. + +3. Enter a password for the user + +4. For the Connection, leave it at the default value. (Username-Password-Authentication) + +5. Press the blue **"SAVE"** button. + + +## 3. Set up the Auth0 service provider (tenant 1) + +In this section you will configure another Auth0 tenant (tenant 1) so it knows how to communicate with the second Auth0 tenant (tenant 2) for SSO via the SAML protocol. + +Switch to **Tenant 1**. You can do this using the **Switch tenant** option in the upper-right menu. + +**In the Auth0 dashboard:** + +1. Click on **"Connections"** link at left. +2. In the list of options below "Connections", click on **"Enterprise"** +3. In the middle of the screen, click on **"SAMLP Identity Provider"** + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-06.jpg) + +4. Click on the blue **"Create New Connection"** button + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-07.jpg) + +In the **"Create SAMLP Identity Provider"** connection window, enter the following information into the "Configuration" tab. + +**Connection Name:** You can enter any name, such as "SAML-Auth0-IDP" + +**Email Domains:** In this example, we will use the Lock widget, so in the Email Domains field enter the email domain name for the users that will log in via this connection. +For example, if your users have an email domain of 'abc-example.com', you would enter that into this field. You can enter multiple email domains if needed. Make sure the test user you created in section 2 has an email address with email domain that matches what you enter here. + +**Sign In URL:** enter the **SAML Protocol URL** field that you copied in section 2 above (from tenant 2, go to: **Dashboard > Applications > Settings > Advanced Settings > ENDPOINTS section > SAML tab > SAML Protocol URL field**). + +**Sign Out URL:** enter the same URL as for the Sign In URL above. + +**X509 Signing Certificate:** +Click on the red **"UPLOAD CERTIFICATE..."** button and select the `.pem` file you downloaded from tenant 2 in section 2 above. + +You can ignore the rest of the fields for now. + +**Save:** Click on the blue **"SAVE"** button at the bottom. + +After pressing the **"SAVE"** button, A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it) + +Copy and save the URL below the **"CONTINUE"** button, and then click on the **"CONTINUE"** button. + +In the window that appears, metadata about this SAML provider (tenant 1) should be displayed. If you are not logged into the Auth0 documentation site, generic SAML provider configuration data will be displayed. Click "Login" in the top right corner of the page, log in with your Auth0 management dashboard credentials, and then go to the URL you saved in the previous step. + +You will need to collect two pieces of information about this Auth0 tenant (the service provider) that you will then paste into the other Auth0 tenant you set up (the identity provider). + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-08.jpg) + +First, look for the second bullet in the list of information that tells you the **"Entity ID"**. It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__. + +Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. You will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above). + +In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_. + +Copy the URL below that line into your browser address bar. Again, you will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above). + +In general, you can access the metadata for a given SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`. + +Once you go to that metadata URL, it will display the metadata (or prompt you to save the metadata file) for this connection in tenant 1 (service provider side of the federation). It will look something like the following with your tenant name in place of the 'xxxxx': + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-09.jpg) + +You need to locate the row that starts with **"AssertionConsumerService"** and copy the value of the **"Location"** field. It will be a URL of the form `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`. + +Copy and save this URL. This is the URL on Tenant 1 that will receive the SAML assertion from the IDP. In the next section you will give this URL to the IDP so it knows where to send the SAML assertion. + +## 4. Add your Service Provider metadata to the Identity Provider + +In this section you will go back and add some information about the Service Provider (Tenant 1) to the Identity Provider (tenant 2) so the Identity Provider Auth0 tenant knows how to receive and respond to SAML-based authentication requests from the Service Provider Auth0 tenant. + +* Switch back to **Tenant 2**. + +**In the Auth0 dashboard:** for Tenant 2 + +1. Click on **"Applications"** link at left. + +2. Find the row for the application you created earlier, and click on the **"Add Ons"** icon to the right of the application name. (the angle bracket and slash icon) +3. Locate the box with the **"SAML2 WEB APP"** label and click on the circle toggle to turn it green. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-10.jpg) + +4. Next, a configuration window will pop up for the **"Addon: SAML2 Web App"**. Make sure you are in the **Settings**" tab. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-11.png) + +5. In the **"Application Callback URL"** field, paste in the **Assertion Consumer Service URL** that you copied and saved in section 3 above (the last step). + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-12.png) + +6. In the Settings field below, go to line 2 that has the "audience" attribute. + +First remove the "//" at the beginning of the line to uncomment it, and remove the comma (',') from the end of the line. + +Next, replace the original value (urn:foo) with the **Entity ID** value you saved and copied in step 3 above (including your actual connection name). The new line 2 should look something like: + +```text +"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME" +``` + +7. Click on the blue **"SAVE"** button at the bottom of the screen + +## 5. Test Identity Provider + +In the same screen, click on the red **"DEBUG"** button. + +That will trigger a login screen from tenant 2, the Identity Provider. + +Log in with the credentials for the user you created above. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-13.png) + +If your configuration is correct, you will see a screen titled **"It works!"** + +This screen will show you the encoded and decoded SAML response that would be sent by the Identity Provider. + +Check the decoded SAML response and locate (about half-way down) the `""` tag and make sure it matches the **Entity ID** you entered in the previous screen (obtained during step 3). + +Click on **"Close this window"** at the bottom of the screen. + +## 6. Register a simple HTML application with which to test the end-to-end connection. + +In this section, you will register an application in Auth0 that will use the SAML connection you set up in the above steps. + +Make sure you are logged into the **Tenant 1 Auth0 dashboard**. + +* In the **Auth0 dashboard**, click on the **"Applications"** link at left. + +* Click on the red **"+ CREATE APP"** button on the right. + +* In the **Name** field, enter a name like "My-HTML-SAML-App". + +* Select "Regular Web App" + +* Press the blue **"SAVE"** button. + +* Click on the **"Settings"** tab. + +* Save the **"Domain"** and **"Client ID"** values for use below in step 8. + +* In the **"Allowed Callback URLs"** field, enter **[http://jwt.io](http://jwt.io)**. + +* The list of allowed callback URLs is a list of URL(s) to which users will be redirected after authentication. The URL(s) entered here must match the **"callback URL"** in the HTML code created in the next step. Normally you would enter a URL for your application, but to keep this example simple, users will simply be sent to the Auth0 JWT online tool which will provide some information about the JSON Web Token (JWT) returned at the end of the authentication sequence. + +* Press the blue **"SAVE CHANGES"** button at the bottom of the screen. + +* In the same screen, click on the blue **"Connections"** tab (In the row that says Quick Start, Settings and so on. + +* Scroll down to the section near the bottom where it says **"ENTERPRISE"**. + +* Find the row for the SAML connection you created above and click on the on/off toggle at right so that it is green, for "on". That enables the SAML connection for this application. + +## 7. Test the connection from Service Provider to Identity Provider + +In this section, you will test to make sure the SAML configuration between Auth0 tenant 1 (Service Provider) and Auth0 tenant 2 (Identity Provider) is working. + +* On the [Dashboard](${manage_url}), navigate to: __Connections -> Enterprise -> SAMLP Identity Provider__. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-14.jpg) + +* Click on the triangular **"Try"** button for the SAML connection you created earlier. This button is to the right of the name of the connection. You can hover your mouse over the button to have the text label appear. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-15.png) + +* Because you already logged in while testing this connection above, you will likely be sent directly to the "It Works!" page shown previously. If you are presented with the Lock login screen, login using the credentials for the user you created above. On some older tenants, you may see the "Last time you signed in using" dialog as shown below, in which case you can just click on your email address to continue. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-16.png) + +If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __"It works!"__. This page will display the contents of the SAML authentication assertion sent by the Auth0 Identity Provider to Auth0 Service Provider. +This means the SAML connection from Auth0 Service Provider to Auth0 Identity Provider is working. + +If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document. + +::: note +The **Try** button only works for users logged in to the Auth0 dashboard. You cannot send this to an anonymous user to have them try it. +::: + +## 8. Create the HTML page for a test application + +In this section you will create a very simple HTML page that invokes the **Auth0 Lock Widget** which will trigger the SAML login sequence. This will enable an end-to-end test of the SAML SSO. + +Create an HTML page and insert the following HTML and javascript code: + +```html + + + +

Click on the button to log in

+ + + + + + + +``` + +Make sure you replace **YOUR_CLIENT_ID** and **YOUR_DOMAIN** with the actual values of the app you registered in step 6 above. If you did not record these values in step 6, they can be found in the **Auth0 dashboard** for **Tenant 1** by going to "Applications" link and clicking on the "Settings" (gear) icon to the right of your application's name. + +You can also replace **audience** with the value appropriate for your Application -- however, for the purposes of this test, a placeholder will work. When specifying the **audience** parameter, be sure that it matches an identifier of an existing API that [has been configured in Auth0](/apis#how-to-configure-an-api-in-auth0). + +Save this file in a place where you can access it via a browser. +For this example, we'll call it **"hello-saml.html"**. + +## 9. Test your sample application + +In this step, you will test your sample HTML application that uses the Auth0 SAML connection you set up in Tenant 1 to perform SSO via SAML against Tenant 2, serving as the SAML Identity Provider. + +* Open the HTML file created above with a browser. You should first see a white page with a login button on it. + +* Click on the **login** button. + +The **Auth0 Lock** widget should appear with one login option. + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-18.png) + +If you have other connections turned on for your application, your **Auth0 Lock Widget** may look slightly different. If you are prompted to enter an email address, make sure the email address you enter has the same domain name as the domain(s) you entered in the __Settings__ tab for the application in the Tenant 1 Auth0 dashboard (__Applications > Settings__). + +![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-19.png) + +After entering your email address, the blue button on the Lock widget may have a new label. Click on the button which may be labeled **"saml"** or **ACCESS** or with the email domain of the email address you are logging in with, to initiate the SAML sso sequence with the Auth0 Identity Provider. + +* As above, whether you are prompted for credentials or immediately redirected to the callback URL depends on whether you still have an active session at the Identity Provider. + +From the "try me" test you did earlier, you may still have an active session at the Identity Provider. If this is the case, you will not be prompted to log in again and will simply be redirected to the callback URL specified in the HTML file. (Remember that this callback URL must also be in the __Allowed Callback URLs__ in the application's Settings tab in the Auth0 dashboard.) + +If sufficient time has passed, or if you delete your browser cookies before initiating the test, then you will be prompted to login when redirected to the Identity Provider. Log in to the Identity Provider using the credentials for the test user you created in Auth0 Tenant 2. + +## 10. Troubleshooting + +This section has a few ideas for things to check if your sample doesn't work. + +Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution. + +When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis. Search for "HTTP Trace" to find some. Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application. + +Be sure to check to make sure cookies and javascript are enabled for your browser. + +Check to make sure that the callback URL specified in the HTML file is also listed in the **Allowed Callback URLs** field in the "Settings" tab of the application registered in the Auth0 Dashboard. (In dashboard, Click on Applications link, then on the "Settings" icon to the right of the application's name.) + +The **[http://samltool.io](http://samltool.io)** tool can decode a SAML assertion and is a useful debugging tool. diff --git a/fr-ca/articles/protocols/ws-fed/index.md b/fr-ca/articles/protocols/ws-fed/index.md new file mode 100644 index 0000000000..bff4091e38 --- /dev/null +++ b/fr-ca/articles/protocols/ws-fed/index.md @@ -0,0 +1,76 @@ +--- +description: The WS-Federation protocol and how it is used in Auth0. +topics: + - saml + - ws-federation +contentType: + - how-to +useCase: + - add-idp +--- +# WS-Federation + +WS-Federation (which is short for Web Services Federation) is a protocol that can be used to negotiate the issuance of a token. You can use this protocol for your applications (such as a Windows Identity Foundation-based app) and for identity providers (such as Active Directory Federation Services or Azure AppFabric Access Control Service). + +## For Applications (Clients) + +By registering your application as an [application](/applications) in Auth0, it will automatically be assigned a WS-Fed endpoint of the form: + +```text +https://${account.namespace}/wsfed/${account.clientId} +``` + +You can find all available options for configuring WS-Federation under the [advanced settings](${manage_url}/#/applications/${account.clientId}/settings) area for your application. + +![WS-Fed Endpoints](/media/articles/protocols/ws-fed-endpoints.png) + +You will need to configure the **Relying Party**, which can be done using the following metadata endpoint: + +```text +https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml +``` + +You can also use the **samlConfiguration** object (available in [rules](/rules)) to configure claims sent via the token, as well as other lower-level WS-Fed and SAML-P settings. + +When redirecting your users to your WS-Fed endpoint, you can use the following (optional) parameters: + +* `wa=wsignin1.0`: whether Auth0 should issue a token for the relying party (this is the default action) +* `wa=wsignout1.0`: whether Auth0 should clear the user session/log the user out +* `wreply={callback_URL}`: specifies where the response should be sent +* `wctx={state}`: your application's state +* `whr={connection_name}`: connection to be used (allows users to skip the Auth0 login page) +* `wfresh=0`: whether the user must re-authenticate, even if there's a session in place (`0` requires re-authentication) + +Here's a sample of what your URL with the optional parameters might look like: + +```text +https://${account.namespace}/wsfed/${account.clientId}?whr=google-oauth2 +``` + +## Identity Providers + +If you're using Auth0 with an identity provider that utilizes the WS-Federation protocol (such as Active Directory Federation Services, Azure AppFabric Access Control Service, and IdentityServer), the easiest way to set up your integration is to create and use the **ADFS** connection type. When setting up an ADFS-based connection, you can import the required parameters by providing Auth0 with the **Federation Metadata** endpoint *or* by importing uploading your Federation Metadata file. + +![New Connection Configuration Screen](/media/articles/protocols/create-adfs-connection.png) + +Click **Save** to proceed. You will then be presented with the instructions you need to finish configuring the integration. + +The Federation Metadata file contains information about the identity provider's certificates. If you provide the Federation Metadata endpoint (typically of the form ending with `/FederationMetadata/2007-06/FederationMetadata.xml`), Auth0 can check daily for changes in the configuration, such as the addition of a new signing certificate that was added in preparation for a rollover. + +Because of this, enabling the Federation Metadata endpoint is preferred to providing a standalone metadata file. If you provide a standalone metadata file, we will notify you via email when the certificates are close to their expiration date. + +::: note +If the Federation Metadata contains both the primary **and** secondary certificates, you can use both in Auth0. +::: + +To roll over certificates using the Federation Metadata endpoint, you must: + +1. Generate a new certificate and add as the secondary in your ADFS environment at least two days before the certificate expiry of your current primary certificate. + +1. Generate a new certificate, and add it as the **secondary certificate** for your ADFS environment. This should be **done at least two days before** the expiration of your active primary certificate. + +1. Allow Auth0 to obtain your new certificate from the Federation Metadata endpoint. Auth0 checks your endpoints once a day, so be sure to allow sufficient time for Auth0 to complete this step. + + Alternatively, you can manually complete this step by logging in to the Auth0 Dashboard, navigating to the appropriate ADFS connection, and click **Save**. This action results in Auth0 downloading the certificates immediately. + +1. Set the now-secondary certificate as the primary certificate **before** the existing primary certificate expires in your ADFS environment. diff --git a/fr-ca/articles/quickstart/_includes/_auth0-angular-install.md b/fr-ca/articles/quickstart/_includes/_auth0-angular-install.md new file mode 100644 index 0000000000..4dd7e6ae4a --- /dev/null +++ b/fr-ca/articles/quickstart/_includes/_auth0-angular-install.md @@ -0,0 +1,11 @@ + + +## Install the Auth0 Angular SDK + +Run the following command within your project directory to install the Auth0 Angular SDK: + +```bash +npm install @auth0/auth0-angular +``` + +The SDK exposes several types that help you integrate Auth0 with your Angular application idiomatically, including a module and an authentication service. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/_includes/_auth0-react-classes-info.md b/fr-ca/articles/quickstart/_includes/_auth0-react-classes-info.md new file mode 100644 index 0000000000..b01542e23e --- /dev/null +++ b/fr-ca/articles/quickstart/_includes/_auth0-react-classes-info.md @@ -0,0 +1,5 @@ + + +:::note +This guide focuses on using the `useAuth0()` custom React Hook. If you are using class components, check out [these samples using the `withAuth0()` higher-order component](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#use-with-a-class-component). +::: \ No newline at end of file diff --git a/fr-ca/articles/quickstart/_includes/_auth0-react-install.md b/fr-ca/articles/quickstart/_includes/_auth0-react-install.md new file mode 100644 index 0000000000..e7a4d96fd7 --- /dev/null +++ b/fr-ca/articles/quickstart/_includes/_auth0-react-install.md @@ -0,0 +1,11 @@ + + +## Install the Auth0 React SDK + +Run the following command within your project directory to install the Auth0 React SDK: + +```bash +npm install @auth0/auth0-react +``` + +The SDK exposes methods and variables that help you integrate Auth0 with your React application idiomatically using [React Hooks](https://reactjs.org/docs/hooks-overview.html) or [Higher-Order Components](https://reactjs.org/docs/higher-order-components.html). \ No newline at end of file diff --git a/fr-ca/articles/quickstart/_includes/_auth0-vue-install.md b/fr-ca/articles/quickstart/_includes/_auth0-vue-install.md new file mode 100644 index 0000000000..c2cc9be635 --- /dev/null +++ b/fr-ca/articles/quickstart/_includes/_auth0-vue-install.md @@ -0,0 +1,11 @@ + + +## Install the Auth0 Vue SDK + +Run the following command within your project directory to install the Auth0 Vue SDK: + +```bash +npm install @auth0/auth0-vue +``` + +The SDK exposes several types that help you integrate Auth0 with your Vue application idiomatically, including a module and an authentication service. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/_includes/_configure_auth0_interactive.md b/fr-ca/articles/quickstart/_includes/_configure_auth0_interactive.md new file mode 100644 index 0000000000..a603228285 --- /dev/null +++ b/fr-ca/articles/quickstart/_includes/_configure_auth0_interactive.md @@ -0,0 +1,39 @@ +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing. + +### Configure an application + +Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future. + +If you would rather explore a complete configuration, you can view a sample application instead. + +### Configure Callback URLs + +A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in. + +::: note +If you are following along with our sample project, set this to `${callback}`. +::: + +### Configure Logout URLs + +A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error. + +::: note +If you are following along with our sample project, set this to `${returnTo}`. +::: + +<% if (typeof showWebOriginInfo !== 'undefined' && showWebOriginInfo === true) { %> + +### Configure Allowed Web Origins + +An Allowed Web Origin is a URL that you want to be allowed to access to your authentication flow. This must contain the URL of your project. If not properly set, your project will be unable to silently refresh authentication tokens, so your users will be logged out the next time they visit your application or refresh a page. + +::: note +If you are following along with our sample project, set this to `${webOriginUrl}`. +::: + +<% } %> \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_auth_preamble.md b/fr-ca/articles/quickstart/backend/_includes/_api_auth_preamble.md new file mode 100644 index 0000000000..443f2c5a67 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_auth_preamble.md @@ -0,0 +1,6 @@ + +This example demonstrates: + +* How to check for a JSON Web Token (JWT) in the `Authorization` header of an incoming HTTP request. + +* How to check if the token is valid, using the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) for your Auth0 account. To learn more about validating Access Tokens, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_create.html b/fr-ca/articles/quickstart/backend/_includes/_api_create.html new file mode 100644 index 0000000000..32e85b9c9d --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_create.html @@ -0,0 +1,7 @@ +

Before applying authentication to your resource server/API, you need to create an entry for it in the Auth0 dashboard. This is done from the APIs section which can be found in the sidebar.

+ +<% if (account.userName) { %> +

In the APIs section in dashboard, click the Create API button. Provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.

+<% } else { %> +

Create an Auth0 account (or login) navigate to the APIs section in Dashboard. Click the Create API button and provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.

+<% } %> \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_create_new.md b/fr-ca/articles/quickstart/backend/_includes/_api_create_new.md new file mode 100644 index 0000000000..4310502988 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_create_new.md @@ -0,0 +1,16 @@ +## Configure Auth0 APIs + +### Create an API + +In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. Leave the **Signing Algorithm** as **RS256**. + +![Create API](/media/articles/server-apis/create-api.png) + +<% if (typeof sampleLink == 'string') { %> +<%= include('./_api_jwks_description', { sampleLink: sampleLink }) %> +<% } else { %> +<%= include('./_api_jwks_description') %> +<% } %> + +### Define permissions +<%= include('./_api_scopes_access_resources') %> diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_create_new_2.md b/fr-ca/articles/quickstart/backend/_includes/_api_create_new_2.md new file mode 100644 index 0000000000..ba4222d532 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_create_new_2.md @@ -0,0 +1,5 @@ +## Create a Resource Server (API) + +In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. For **Signing Algorithm**, select **RS256**. + +![Create API](/media/articles/server-apis/create-api.png) \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_endpoints.md b/fr-ca/articles/quickstart/backend/_includes/_api_endpoints.md new file mode 100644 index 0000000000..bc59e707e0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_endpoints.md @@ -0,0 +1,5 @@ +The routes shown below are available for the following requests: + +- `GET /api/public`: available for non-authenticated requests +- `GET /api/private`: available for authenticated requests containing an access token with no additional scopes +- `GET /api/private-scoped`: available for authenticated requests containing an access token with the `read:messages` scope granted diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description.md b/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description.md new file mode 100644 index 0000000000..23d2c5b8b4 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description.md @@ -0,0 +1,7 @@ +By default, your API uses RS256 as the algorithm for signing tokens. Since RS256 uses a private/public keypair, it verifies the tokens against the public key for your Auth0 account. The public key is in the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) format, and can be accessed [here](https://${account.namespace}/.well-known/jwks.json). + +<% if (typeof sampleLink == 'string') { %> +::: note +We recommend using the default RS256 [signing algorithm](/tokens/concepts/signing-algorithms) for your API. If you need to use the HS256 algorithm, see the [HS256 integration sample](${sampleLink}). +::: +<% } %> diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md b/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md new file mode 100644 index 0000000000..a27211ec1f --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md @@ -0,0 +1 @@ +By default, your API will be set up to use RS256 as the algorithm for signing tokens. Since RS256 works by using a private/public keypair, tokens can be verified against the public key for your Auth0 account. This public key is accessible at [https://${account.namespace}/.well-known/jwks.json](https://${account.namespace}/.well-known/jwks.json). \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_scope_description.md b/fr-ca/articles/quickstart/backend/_includes/_api_scope_description.md new file mode 100644 index 0000000000..f7144c1f4c --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_scope_description.md @@ -0,0 +1,3 @@ +So far, the API is only checking for whether the incoming request has valid authentication information. This solves the case of restricting endpoints such that only authenticated users can access them; however, it doesn't currently provide any way to check for **authorization**. + +Authorization can be added to your authentication flow by use of a **scope** claim in the Access Token which provides some indication of what that token allows access to. For more information on how to add scopes to an Access Token, see the [Scopes documentation](/scopes). diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_scopes_access_resources.md b/fr-ca/articles/quickstart/backend/_includes/_api_scopes_access_resources.md new file mode 100644 index 0000000000..c2bb5146e9 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_scopes_access_resources.md @@ -0,0 +1,9 @@ +Permissions let you define how resources can be accessed on behalf of the user with a given access token. For example, you might choose to grant read access to the `messages` resource if users have the manager access level, and a write access to that resource if they have the administrator access level. + +You can define allowed permissions in the **Permissions** view of the Auth0 Dashboard's [APIs](${manage_url}/#/apis) section. + +![Configure Permissions](/media/articles/server-apis/configure-permissions.png) + +::: note +This example uses the `read:messages` scope. +::: diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_troubleshooting.md b/fr-ca/articles/quickstart/backend/_includes/_api_troubleshooting.md new file mode 100644 index 0000000000..892df4b22d --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_troubleshooting.md @@ -0,0 +1,46 @@ + + +If you configured JWT validation correctly, you will be able to get proper responses from your API when you make requests. However, in the case where you get a 401 (Unauthorized) response from your API, it is because the configuration of your JWT middleware does not match with the JWT which was passed. + +This document will help you troubleshoot your JWT middleware configuration. + +## How Does a Token Get Validated? + +In terms of validating a JWT, there are various things to consider: + +1. **Is the token well-formed?** In other words, is this token conforming to the structure of a JSON Web Token (JWT)? To get more information on the structure of a JWT, please refer to [this section on the structure of a JWT](/jwt#what-is-the-json-web-token-structure-) + +2. **Has the token been tampered with?** The last part of a JWT is the signature. The signature is used to verify that the token was in fact signed by the sender and not altered in any way. + +3. **Has the token been received in its validity period?** JWTs are only valid for a specified time period (as expressed in the `exp` claim). + +4. **Is the token coming from the intended Authority?** This consists of 2 parts + + * **Signature Verification**: Can we confirm that the JWT is correctly signed using the key issued by the issuing authority? + + * **Issuer Value**: The Issuer is defined in the `iss` claim. Once again does this claim match up with what your application expects? + +5. **Is the token intended for the current application?** So does the `aud` claim of the JWT match with what your application is expecting? + +## Inspecting a Token + +A quick way to inspect a JWT is by using the [JWT.io](https://jwt.io/) website. It has a handy debugger which allows you to quickly check that a JWT is well-formed, and also inspect the values of the various claims. + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png) + +In the screenshot above you can see that the token was signed using the **RS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://rs256.test.api**. + +So, in other words, these values in your JWT validation configuration registration must match **exactly** - including the trailing slash for the Issuer, such as + +``` +audience = "https://rs256.test.api", +domain = "https://jerrie.auth0.com/" +}; +``` + +For a token signed using HS256, the debugger view will look a little different: + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png) + +In the screenshot above you can see that the token was signed using the **HS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://hs256.test.api**. + diff --git a/fr-ca/articles/quickstart/backend/_includes/_api_using.md b/fr-ca/articles/quickstart/backend/_includes/_api_using.md new file mode 100644 index 0000000000..c85b97671b --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_api_using.md @@ -0,0 +1,120 @@ + + +## Calling the API From Your Application + +You can call the API from your application by passing an Access Token in the `Authorization` header of your HTTP request as a Bearer token. + +```har +{ + "method": "GET", + "url": "http://localhost:3010/api/private", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" } + ] +} +``` + +## Obtaining an Access Token + +If you are calling the API from a Single-Page Application or a Mobile/Native application, after the authorization flow is completed, you will get an Access Token. How you get the token and how you make the call to the API will be dependent on the type of application you are developing and the framework you are using. For more information refer to the relevant application Quickstarts which contain detailed instructions: + +* [Single-Page Applications](/quickstart/spa) +* [Mobile / Native Application](/quickstart/native) + +If you are calling the API from a command-line tool or another service, where there isn't a user entering their credentials, you need to use the [OAuth Client Credentials flow](/api/authentication#client-credentials). To do that, register a [Machine to Machine Application](${manage_url}/#/applications), and then subsequently use the **Client ID** and **Client Secret** of this application when making the request below and pass those along in the `client_id` and `client_secret` parameters respectively. Also include the Audience for the API you want to call. + +:::note +Read [Application Settings](https://auth0.com/docs/get-started/dashboard/application-settings) for more information on getting the Client ID and Client Secret for your machine-to-machine app. +::: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "client_credentials" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "YOUR_API_IDENTIFIER" + } + ] + } +} +``` + +:::note +Auth0 customers are billed based on the number of Machine to Machine Access Tokens issued by Auth0. Once your application gets an Access Token it should keep using it until it expires, to minimize the number of tokens requested. +::: + +For testing purposes, you can also get an Access Token from the **Test** tab in your [API settings](${manage_url}/#/apis). + +## Test Your API + +**1. Calling the secure endpoint** + +You can make a request to the `/api/private` endpoint without passing any Access Token: + +```har +{ + "method": "GET", + "url": "http://localhost:3010/api/private" +} +``` + +The API will return a 401 HTTP (Unauthorized) status code: + +![Response for unauthorized API request](/media/articles/server-apis/using/private-unauthorized.png) + +Once again, make the same request but this time pass along the Access Token as a Bearer token in the **Authorization** header of the request: + +```har +{ + "method": "GET", + "url": "http://localhost:3010/api/private", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" } + ] +} +``` + +This time the API will return a successful response: + +![Response for authorized API request](/media/articles/server-apis/using/private.png) + +**2. Testing the scoped endpoint** + +To test the endpoint that requires a scope, pass the Access Token containing the correct scope as a Bearer token in the Authorization header: + +```har +{ + "method": "GET", + "url": "http://localhost:3010/api/private-scoped", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" } + ] +} +``` + +If the required scope is present, the API call is successful: + +![Response for scoped API request](/media/articles/server-apis/using/private-scoped.png) + +If the required scope is not present, the API returns a 403 HTTP Status (Forbidden): + +![Response for forbidden scoped API request](/media/articles/server-apis/using/private-scoped-forbidden.png) \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/_includes/_call_api.md b/fr-ca/articles/quickstart/backend/_includes/_call_api.md new file mode 100644 index 0000000000..eb4073dc35 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_call_api.md @@ -0,0 +1,19 @@ + + +### Make a Call to Your API + +To make calls to your API, you need an Access Token. You can get an Access Token for testing purposes from the **Test** view in your [API settings](${manage_url}/#/apis). + +![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png) + +Provide the Access Token as an `Authorization` header in your requests. + +```har +{ + "method": "GET", + "url": "http://your-domain.com/api_path", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN_HERE" } + ] +} +``` diff --git a/fr-ca/articles/quickstart/backend/_includes/_updating_notice.md b/fr-ca/articles/quickstart/backend/_includes/_updating_notice.md new file mode 100644 index 0000000000..2aa91865c6 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_includes/_updating_notice.md @@ -0,0 +1,3 @@ +## Update Notice + +This doc is currently being updated, please check back soon. diff --git a/fr-ca/articles/quickstart/backend/_thirdPartyApi.md b/fr-ca/articles/quickstart/backend/_thirdPartyApi.md new file mode 100644 index 0000000000..f8a12791b9 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/_thirdPartyApi.md @@ -0,0 +1,24 @@ +# <%= meta.name %> API + +Please follow the steps below to configure your Auth0 tenant to work with <%= meta.name %>. + +## 1. Activate the add-on + +<% if (account.clientId) { %> +Go to Application Add-ons page and activate the <%= meta.name %> add-on. +<% } else { %> +Go to Application Add-ons page and activate the <%= meta.name %> add-on. +<% } %> + + +![](/media/articles/server-apis/addons.png) + +Each integration is different and requires different parameters and configuration. Once the add-on is activated, you will see tailored instructions with details on how to get this done. + +## 2. Use it + +The key to this integration is the Delegation endpoint in Auth0. Check the documentation of any of our frontend or Mobile SDKs to learn how to call [the /delegation endpoint](/api/authentication#delegation). You can download your favorite library from any of the [Quickstarts](/). + +## 3. You are done! + +Congrats! You've implemented Delegation for the <%= meta.name %> API diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md new file mode 100644 index 0000000000..f2fbe4fe37 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md @@ -0,0 +1,188 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to an ASP.NET Core Web API application using the standard JWT middleware. +budicon: 500 +topics: + - quickstart + - backend + - aspnetcore + - web-api +github: + path: Quickstart/01-Authorization +contentType: tutorial +useCase: quickstart +--- + + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Configure the Sample Project + +The sample code has an `appsettings.json` file which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page while logged in, it will be automatically filled. If you use the example from Github, you will need to fill it yourself. + +```json +{ + "Auth0": { + "Domain": "${account.namespace}", + "Audience": "${apiIdentifier}" + } +} +``` + +## Validate Access Tokens + +### Install dependencies + +The seed project already contains a reference to the `Microsoft.AspNetCore.Authentication.JwtBearer`, which is needed in order to validate Access Tokens. +However, if you are not using the seed project, add the package to your application by installing it using Nuget: + +```text +Install-Package Microsoft.AspNetCore.Authentication.JwtBearer +``` + +### Configure the middleware + +The ASP.NET Core JWT Bearer authentication handler downloads the JSON Web Key Set (JWKS) file with the public key. The handler uses the JWKS file and the public key to verify the Access Token's signature. + +In your application, register the authentication services: + +1. Make a call to the `AddAuthentication` method. Configure `JwtBearerDefaults.AuthenticationScheme` as the default schemes. +2. Make a call to the `AddJwtBearer` method to register the JWT Bearer authentication scheme. Configure your Auth0 domain as the authority, and your Auth0 API identifier as the audience. In some cases the access token will not have a `sub` claim which will lead to `User.Identity.Name` being `null`. If you want to map a different claim to `User.Identity.Name` then add it to `options.TokenValidationParameters` within the `AddAuthentication()` call. + +```csharp +// Program.cs +var builder = WebApplication.CreateBuilder(args); +var domain = $"https://{builder.Configuration["Auth0:Domain"]}/"; +builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) +.AddJwtBearer(options => +{ + options.Authority = domain; + options.Audience = builder.Configuration["Auth0:Audience"]; + options.TokenValidationParameters = new TokenValidationParameters + { + NameClaimType = ClaimTypes.NameIdentifier + }; +}); +``` + +To add the authentication and authorization middleware to the middleware pipeline, add a call to the `UseAuthentication` and `UseAuthorization` methods in your Program.cs file: + +```csharp +// Program.cs +var app = builder.Build(); + +app.UseAuthentication(); +app.UseAuthorization(); +app.UseEndpoints(endpoints => +{ + endpoints.MapControllers(); +}); +``` + +### Validate scopes + +To make sure that an Access Token contains the correct scope, use the [Policy-Based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) in ASP.NET Core. + +Create a new authorization requirement called `HasScopeRequirement`. This requirement checks if the `scope` claim issued by your Auth0 tenant is present. If the `scope` claim exists, the requirement checks if the `scope` claim contains the requested scope. + +```csharp +// HasScopeRequirement.cs + +public class HasScopeRequirement : IAuthorizationRequirement +{ + public string Issuer { get; } + public string Scope { get; } + + public HasScopeRequirement(string scope, string issuer) + { + Scope = scope ?? throw new ArgumentNullException(nameof(scope)); + Issuer = issuer ?? throw new ArgumentNullException(nameof(issuer)); + } +} +``` + +```csharp +// HasScopeHandler.cs + +public class HasScopeHandler : AuthorizationHandler +{ + protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, HasScopeRequirement requirement) + { + // If user does not have the scope claim, get out of here + if (!context.User.HasClaim(c => c.Type == "scope" && c.Issuer == requirement.Issuer)) + return Task.CompletedTask; + + // Split the scopes string into an array + var scopes = context.User.FindFirst(c => c.Type == "scope" && c.Issuer == requirement.Issuer).Value.Split(' '); + + // Succeed if the scope array contains the required scope + if (scopes.Any(s => s == requirement.Scope)) + context.Succeed(requirement); + + return Task.CompletedTask; + } +} +``` + +In your Program.cs file, add a call to the `AddAuthorization` method. To add policies for the scopes, call `AddPolicy` for each scope. Also ensure that you register the `HasScopeHandler` as a singleton: + +```csharp +// Program.cs + +builder.Services.AddAuthorization(options => +{ + options.AddPolicy("read:messages", policy => policy.Requirements.Add(new + HasScopeRequirement("read:messages", domain))); +}); + +builder.Services.AddSingleton(); +``` + +## Protect API Endpoints + +The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/) and [Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/) mechanisms. + +To secure an endpoint, you need to add the `[Authorize]` attribute to your controller action: + +```csharp +// Controllers/ApiController.cs + +[Route("api")] +[ApiController] +public class ApiController : ControllerBase +{ + [HttpGet("private")] + [Authorize] + public IActionResult Private() + { + return Ok(new + { + Message = "Hello from a private endpoint! You need to be authenticated to see this." + }); + } +} +``` + +To secure endpoints that require specific scopes, we need to make sure that the correct scope is present in the `access_token`. To do that, add the `Authorize` attribute to the `Scoped` action and pass `read:messages` as the `policy` parameter. + +```csharp +// Controllers/ApiController.cs + +[Route("api")] +public class ApiController : Controller +{ + [HttpGet("private-scoped")] + [Authorize("read:messages")] + public IActionResult Scoped() + { + return Ok(new + { + Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this." + }); + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/02-using.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/02-using.md new file mode 100644 index 0000000000..143001841d --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/02-using.md @@ -0,0 +1,14 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - aspnetcore + - web-api +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md new file mode 100644 index 0000000000..5b80f0b41e --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md @@ -0,0 +1,201 @@ +--- +title: Troubleshooting +description: This document will help you troubleshoot your configuration if you get 401 (Unauthorized) response from your API. +budicon: 500 +topics: + - quickstart + - backend + - aspnetcore + - web-api +contentType: tutorial +useCase: quickstart +--- + + + +If the configuration of your JSON Web Token (JWT) middleware does not match the JWT that was passed to the API, you get a 401 (Unauthorized) response from your API. + +This document will help you troubleshoot your JWT middleware configuration. + +## Check the Token Validation + +There are 5 criteria for validating a JWT token. + +1. **Is the token formed properly?** +Check if the structure of the token matches the structure of a JSON Web Token. Read more about the [JSON Web Token structure](/jwt#what-is-the-json-web-token-structure-). + +2. **Has the token been tampered with?** +The last part of a JWT is the signature. The signature is used to verify that the token was signed by the sender and not altered in any way. + +3. **Has the token been received in its validity period?** +JWTs are only valid for a specified time, defined in the `exp` claim. + +4. **Is the token coming from the intended Authority?** +Check the following two criteria: + + * **Signature verification**: Check if the JWT is correctly signed with the key issued by the issuing authority. + + * **Issuer value**: The Issuer is defined in the `iss` claim. Check if this claim matches up with what your application expects. + +5. **Is the token intended for the current application?** +Check if the `aud` claim of the JWT matches with what your application expects. + +## Inspect a Token + +You can inspect a JWT with the [JWT.io](https://jwt.io/) website. Use the debugger on the website to check if your JWT is well formed. You can also inspect values of the various claims. + +The screenshot below shows the following information: +* The token is signed with the RS256 algorithm +* The issuer of the token is `https://jerrie.auth0.com/` +* The audience of the token is `https://rs256.test.api` + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png) + +Check if the values of the JWT token match exactly the values in your JWT middleware registration. This includes the trailing slash for the Issuer. + +```csharp +var options = new JwtBearerOptions +{ + Audience = "https://rs256.test.api", + Authority = "https://jerrie.auth0.com/" +}; +app.UseJwtBearerAuthentication(options); +``` + +If your token is signed with the HS256 algorithm, the debugger view is different. + +The screenshot below shows the following information: +* The token is signed with the HS256 algorithm +* The issuer of the token is `https://jerrie.auth0.com/` +* The audience of the token is `https://hs256.test.api` + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png) + +If your token is signed with the HS256 algorithm, the middleware needs to be configured in the following way: + +```csharp +var options = new JwtBearerOptions +{ + TokenValidationParameters = + { + ValidIssuer = "https://jerrie.auth0.com/", + ValidAudience = "https://hs256.test.api", + IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your api secret")) + } +}; +app.UseJwtBearerAuthentication(options); +``` + +## Debug Configuration Issues Using Log Files + +To debug potential configuration issues, inspect the log files for your application. For more information, refer to the [Logging in ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging) document. + +In this example, we run the application from the command line and inspect the console log output. + +### 1. Are you passing the JWT in the Authorization header? + +Check if you are passing the JWT as a Bearer token in the `Authorization` header of the HTTP request. + +If you are not passing the token, you will see the following warning: + +![Not specifying an Authorization Header](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png) + +Look for the following warning message: + +```text +Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter' +``` + +To resolve this issue, make sure you are passing the JWT as the Bearer token in the `Authorization` header of the HTTP request. + +### 2. Did you configure the JWT middleware for the correct signing algorithm? + +Make sure that the [signing algorithm](/tokens/concepts/signing-algorithms) you used to sign your token matches the signing algorithm configured in your middleware. + +The following screenshots show two messages: +* A warning message: "Authorization failed..." +* A message with more information + +The following example shows that the JWT is signed with the HS256 algorithm and the middleware is configured to expect RS256 tokens: + +![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png) + +Look for the following warning message: + +```text +System.ArgumentException: IDX10634: Unable to create the SignatureProvider. + +SignatureAlgorithm: 'HS256', SecurityKey: 'Microsoft.IdentityModel.Tokens.RsaSecurityKey' is not supported. +``` + +The following example shows that the JWT is signed with the RS256 algorithm and the middleware is configured to expect HS256 tokens: + +![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png) + +Look for the following warning message: + +```text +Bearer was not authenticated. Failure message: IDX10501: Signature validation failed. Unable to match 'kid': 'NTF...' +``` + +To resolve this issue, make sure that the algorithm for the JWT matches with the configuration of your middleware. + +### 3. Has your token expired? + +Each JSON Web Token is valid until the time defined in the `exp` claim runs out. If you send an expired token, the token will be rejected: + +![Token Expired](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-token-expired.png) + +Look for the following error message: + +```text +IDX10223: Lifetime validation failed. The token is expired +``` + +To resolve this issue, check if the token you are sending has not expired. + +::: note +The value of the `exp` claim is a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time. If you want to see the date/time for the value, visit [EpochConverter](http://www.epochconverter.com/). +::: + +### 4. Did you configure the correct issuer? + +The Issuer specified in your token must match exactly with your JWT middleware configuration. + +![Issuer Validation Failed](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-issuer-validation-failed.png) + +Look for the following warning message: + +::: note +You will get this message only for the tokens signed with the HS256 algorithm. +::: + +```text +IDX10205: Issuer validation failed. +``` + +To resolve this issue, make sure that you specify the correct issuer for your JWT middleware. + +For HS256 signed tokens, specify the correct value for the `ValidIssuer` property of `TokenValidationParameters`. + +::: note +For RS256 tokens, the JWT middleware downloads the OIDC discovery document from `Authority` and configures the Issuer based on the `issuer` attribute specified in that document. + +If you are using RS256 tokens, the system checks their signature before it checks the Issuer. +::: + +### 5. Does the audience match your JWT middleware configuration? + +Check if the audience specified in your token matches your JWT middleware configuration. + +![Audience Validation Failed](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-audience-validation-failed.png) + +Look for the following error message: + +```text +IDX10214: Audience validation failed +``` + +To resolve this issue, make sure you specify the correct audience for your JWT middleware. Depending on how your JWT middleware was configured, do the following: +* Set the correct `Audience` property of `JwtBearerOptions` +* Set the `ValidAudience` property of `TokenValidationParameters` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/download.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/download.md new file mode 100644 index 0000000000..667eb06da6 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/download.md @@ -0,0 +1,15 @@ +To run the sample you need [.NET Core](https://www.microsoft.com/net/download) installed, and run the following commands: + +```bash +dotnet restore +dotnet run +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md new file mode 100644 index 0000000000..2f9657aef0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md @@ -0,0 +1,30 @@ +--- +name: ApiController.cs +language: csharp +--- + +```csharp +[Route("api")] +public class ApiController : Controller +{ + [HttpGet("private")] + [Authorize] + public IActionResult Private() + { + return Ok(new + { + Message = "Hello from a private endpoint!" + }); + } + + [HttpGet("private-scoped")] + [Authorize("read:messages")] + public IActionResult Scoped() + { + return Ok(new + { + Message = "Hello from a private-scoped endpoint!" + }); + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md new file mode 100644 index 0000000000..ba8da8ddc4 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md @@ -0,0 +1,13 @@ +--- +name: appsettings.json +language: json +--- + +```json +{ + "Auth0": { + "Domain": "${account.namespace}", + "Audience": "${apiIdentifier}" + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md new file mode 100644 index 0000000000..e2eea05829 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md @@ -0,0 +1,35 @@ +--- +name: Program.cs +language: csharp +--- + +```csharp +var builder = WebApplication.CreateBuilder(args); +builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) +.AddJwtBearer(options => +{ + options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}/"; + options.Audience = builder.Configuration["Auth0:Audience"]; + options.TokenValidationParameters = new TokenValidationParameters + { + NameClaimType = ClaimTypes.NameIdentifier + }; +}); + + builder.Services + .AddAuthorization(options => + { + options.AddPolicy( + "read:messages", + policy => policy.Requirements.Add( + new HasScopeRequirement("read:messages", domain) + ) + ); + }); + + builder.Services.AddSingleton(); + +var app = builder.Build(); +app.UseAuthentication(); +app.UseAuthorization(); +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md new file mode 100644 index 0000000000..71b02ea80f --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md @@ -0,0 +1,28 @@ +--- +name: HasScopeHandler.cs +language: csharp +--- + +```csharp +public class HasScopeHandler : AuthorizationHandler +{ + protected override Task HandleRequirementAsync( + AuthorizationHandlerContext context, + HasScopeRequirement requirement + ) { + // If user does not have the scope claim, get out of here + if (!context.User.HasClaim(c => c.Type == "scope" && c.Issuer == requirement.Issuer)) + return Task.CompletedTask; + + // Split the scopes string into an array + var scopes = context.User + .FindFirst(c => c.Type == "scope" && c.Issuer == requirement.Issuer).Value.Split(' '); + + // Succeed if the scope array contains the required scope + if (scopes.Any(s => s == requirement.Scope)) + context.Succeed(requirement); + + return Task.CompletedTask; + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md new file mode 100644 index 0000000000..f3481fc996 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md @@ -0,0 +1,18 @@ +--- +name: HasScopeRequirement.cs +language: csharp +--- + +```csharp +public class HasScopeRequirement : IAuthorizationRequirement +{ + public string Issuer { get; } + public string Scope { get; } + + public HasScopeRequirement(string scope, string issuer) + { + Scope = scope ?? throw new ArgumentNullException(nameof(scope)); + Issuer = issuer ?? throw new ArgumentNullException(nameof(issuer)); + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/index.yml b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/index.yml new file mode 100644 index 0000000000..47a5ed7ab9 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/index.yml @@ -0,0 +1,55 @@ +title: ASP.NET Core Web API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/asp.png +logo: dotnet-platform +alias: + - asp.net core webapi + - aspnet core webapi + - asp.net core webapi 6.0 + - asp.net core webapi 7.0 + - asp.net core webapi 8.0 +language: + - C# +framework: + - ASP.NET Core +author: + name: Damien Guard + email: damien.guard@auth0.com + community: false +thirdParty: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/aspnet-core-webapi/dependencies +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-aspnetcore-webapi-samples + branch: master +requirements: + - .NET 6.0 + - .NET 7.0 + - .NET 8.0 +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/aspnet-core-webapi/interactive.md b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/interactive.md new file mode 100644 index 0000000000..b4e7b4dea1 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/aspnet-core-webapi/interactive.md @@ -0,0 +1,168 @@ +--- +title: Add Authorization to an ASP.NET Core Web API application +description: This tutorial demonstrates how to add authorization to an ASP.NET Core Web API application using the standard JWT middleware. +budicon: 500 +topics: + - quickstart + - backend + - aspnetcore + - web-api +github: + path: Quickstart/01-Authorization +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/appsettings + - files/configure-middleware + - files/has-scope-handler + - files/has-scope-requirement + - files/api-controller +--- + +# Add Authorization to Your ASP.NET Core Web API Application + +Auth0 allows you to add authentication and access user profile information in almost any application type quickly. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET Web API application using the `Microsoft.AspNetCore.Authentication.JwtBearer` package. + +If you haven't created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with. + +Alternatively, you can [read our getting started guide](/get-started/auth0-overview/set-up-apis), which will help you set up your first API through the Auth0 Dashboard. + +Note that every API in Auth0 is configured using an API Identifier; your application code will use the API Identifier as the Audience to validate the access token. + + + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +## Install dependencies + +To allow your application to validate access tokens, add a reference to the `Microsoft.AspNetCore.Authentication.JwtBearer` Nuget package: + +```text +Install-Package Microsoft.AspNetCore.Authentication.JwtBearer +``` + +## Configure the middleware {{{ data-action=code data-code="Startup.cs" }}} + +Set up the authentication middleware by configuring it in your application's `Program.cs` file: + +1. Register the authentication services by making a call to the `AddAuthentication` method. Configure `JwtBearerDefaults.AuthenticationScheme` as the default scheme. + +2. Register the JWT Bearer authentication scheme by making a call to the `AddJwtBearer` method. Configure your Auth0 domain as the authority and your Auth0 API Identifier as the audience, and be sure that your Auth0 domain and API Identifier are set in your application's **appsettings.json** file. + +:::note +In some cases, the access token will not have a `sub` claim; in this case, the `User.Identity.Name` will be `null`. If you want to map a different claim to `User.Identity.Name`, add it to `options.TokenValidationParameters` within the `AddJwtBearer()` call. +::: + +3. Add the authentication and authorization middleware to the middleware pipeline by adding calls to the `UseAuthentication` and `UseAuthorization` methods under the `var app = builder.Build();` method. + +## Validate scopes {{{ data-action=code data-code="HasScopeHandler.cs" }}} + +To ensure that an access token contains the correct scopes, use [Policy-Based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) in the ASP.NET Core: + +1. Create a new authorization requirement called `HasScopeRequirement`, which will check whether the `scope` claim issued by your Auth0 tenant is present, and if so, will check that the claim contains the requested scope. +2. Under your `Program.cs` file's `var builder = WebApplication.CreateBuilder(args);` method, add a call to the `app.AddAuthorization` method. +3. Add policies for scopes by calling `AddPolicy` for each scope. +4. Register a singleton for the `HasScopeHandler` class. + +## Protect API endpoints {{{ data-action=code data-code="ApiController.cs" }}} + +The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/) and [Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/) mechanisms. + +To secure an endpoint, add the `[Authorize]` attribute to your controller action (or the entire controller if you want to protect all of its actions). + +When securing endpoints that require specific scopes, make sure that the correct scope is present in the `access_token`. To do so, add the `Authorize` attribute to the `Scoped` action and pass `read:messages` as the `policy` parameter. + +## Call your API + +The way in which you call your API depends on the type of application you are developing and the framework you are using. To learn more, read the relevant application Quickstart: + +* [Single-Page Applications](/quickstart/spa) +* [Mobile / Native Application](/quickstart/native) + +### Get an access token + +Regardless of the type of application you are developing or the framework you are using, to call your API, you need an access token. + +If you are calling your API from a Single-Page Application (SPA) or a Native application, after the authorization flow completes, you will get an access token. + +If you are calling the API from a command-line tool or another service where a user entering credentials does not exist, use the [OAuth Client Credentials Flow](/api/authentication#client-credentials). To do so, register a [Machine-to-Machine Application](${manage_url}/#/applications), and pass in the **Client ID** as the `client_id` parameter, the **Client Secret** as the `client_secret` parameter, and the API Identifier (the same value you used to configure the middleware earlier in this quickstart) as the `audience` parameter when making the following request: + +:::note +To learn more about getting the Client ID and Client Secret for your machine-to-machine application, read [Application Settings](/get-started/dashboard/application-settings). +::: + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [ + { "name": "Content-Type", "value": "application/x-www-form-urlencoded" } + ], + "postData": { + "mimeType": "application/x-www-form-urlencoded", + "params": [ + { + "name": "grant_type", + "value": "client_credentials" + }, + { + "name": "client_id", + "value": "${account.clientId}" + }, + { + "name": "client_secret", + "value": "YOUR_CLIENT_SECRET" + }, + { + "name": "audience", + "value": "${apiIdentifier}" + } + ] + } +} +``` + +### Call a secure endpoint + +Now that you have an access token, you can use it to call secure API endpoints. When calling a secure endpoint, you must include the access token as a Bearer token in the **Authorization** header of the request. For example, you can make a request to the `/api/private` endpoint: + +```har +{ + "method": "GET", + "url": "http://localhost:3010/api/private", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" } + ] +} +``` + +Call the `/api/private-scoped` endpoint in a similar way, but ensure that the API permissions are configured correctly and that the access token includes the `read:messages` scope. + +::::checkpoint + +:::checkpoint-default +You should now be able to call the `/api/private` and `/api/private-scoped` endpoints. + +Run your application, and verify that: + +- `GET /api/private` is available for authenticated requests. +- `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope. + +::: + +:::checkpoint-failure +Sorry about that. Here are a few things to double check: + +- make sure `ValidIssuer` and `ValidAudience` are configured correctly +- make sure the token is added as the `Authorization` header +- check that the token has the correct scopes (you can use [jwt.io](https://jwt.io/) to verify) + +Still having issues? To get more help, check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com). + +::: + +:::: diff --git a/fr-ca/articles/quickstart/backend/config.yml b/fr-ca/articles/quickstart/backend/config.yml new file mode 100644 index 0000000000..4f677dfe66 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/config.yml @@ -0,0 +1,2 @@ +sample_download_required_data: + - api diff --git a/fr-ca/articles/quickstart/backend/django/01-authorization.md b/fr-ca/articles/quickstart/backend/django/01-authorization.md new file mode 100644 index 0000000000..e4a427cddc --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/01-authorization.md @@ -0,0 +1,276 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to a Django REST Framework API. +topics: + - quickstart + - backend + - django +github: + path: 01-Authorization +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Setup the Django Application + +### Install dependencies + + Add the following dependencies to your `requirements.txt` and run `pip install -r requirements.txt`. + +```python +cryptography~=2.8 +django~=2.2.7 +djangorestframework~=3.10.31 +django-cors-headers~=3.1.1 +drf-jwt~=1.13.3 +pyjwt~=1.7.1 +requests~=2.22.0 +``` + +### Create a Django project + +This guide assumes you already have a Django application set up. If that is not the case, follow the steps in the [Django Tutorial](https://docs.djangoproject.com/en/2.2/intro/tutorial01/). + +The sample project was created with the following commands: + +```bash +django-admin startproject apiexample +cd apiexample +python manage.py startapp auth0authorization +``` + +### Add a Django remote user + +You need to define a way to map the username from the Access Token payload to the Django authentication system user. + +Add [`RemoteUserMiddleware`](https://docs.djangoproject.com/en/2.2/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) middleware component after `AuthenticationMiddleware` to middleware list. + +```python +# apiexample/settings.py + +MIDDLEWARE = [ + # ... + 'django.contrib.auth.middleware.AuthenticationMiddleware', + 'django.contrib.auth.middleware.RemoteUserMiddleware', +] +``` + +Add `ModelBackend` and `RemoteUserBackend` to the Authentication Backends. + +```python +# apiexample/settings.py + +AUTHENTICATION_BACKENDS = [ + 'django.contrib.auth.backends.ModelBackend', + 'django.contrib.auth.backends.RemoteUserBackend', +] +``` + +Create `utils.py` file in your application's folder and define a function that maps the `sub` field from the `access_token` to the username. Then, the [authenticate](https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend.authenticate) method from [RemoteUserBackend](https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) will create a remote user in the Django authentication system and return a User object for the username. + +```python +# auth0authorization/utils.py + +from django.contrib.auth import authenticate + +def jwt_get_username_from_payload_handler(payload): + username = payload.get('sub').replace('|', '.') + authenticate(remote_user=username) + return username +``` + +## Validate Access Tokens + +The `settings.py` file contains the configuration of the Django project. + +Add `rest_framework` app to the `INSTALLED_APPS` entry. + +```python +# apiexample/settings.py + +INSTALLED_APPS = [ + # ... + 'rest_framework' +] +``` + +Add `JSONWebTokenAuthentication` to Django REST framework's `DEFAULT_AUTHENTICATION_CLASSES`. + +```python +# apiexample/settings.py + +REST_FRAMEWORK = { + 'DEFAULT_PERMISSION_CLASSES': ( + 'rest_framework.permissions.IsAuthenticated', + ), + 'DEFAULT_AUTHENTICATION_CLASSES': ( + 'rest_framework_jwt.authentication.JSONWebTokenAuthentication', + 'rest_framework.authentication.SessionAuthentication', + 'rest_framework.authentication.BasicAuthentication', + ), +} +``` + +Configure the [Django REST Framework JWK](https://github.com/Styria-Digital/django-rest-framework-jwt/) by setting the `JWT_AUTH` variable. + +Set the `JWT_AUDIENCE` to your API identifier and the `JWT_ISSUER` to your Auth0 domain. By default, those values will be retrieved from the `.env` file. + +```python +# apiexample/settings.py + +JWT_AUTH = { + 'JWT_PAYLOAD_GET_USERNAME_HANDLER': + 'auth0authorization.utils.jwt_get_username_from_payload_handler', + 'JWT_DECODE_HANDLER': + 'auth0authorization.utils.jwt_decode_token', + 'JWT_ALGORITHM': 'RS256', + 'JWT_AUDIENCE': '${apiIdentifier}', + 'JWT_ISSUER': 'https://${account.namespace}/', + 'JWT_AUTH_HEADER_PREFIX': 'Bearer', +} +``` + +Create the function to fetch the JWKS from your Auth0 account to verify and decode the incoming Access Token. + +```python +# auth0authorization/utils.py + +import json + +import jwt +import requests + +def jwt_decode_token(token): + header = jwt.get_unverified_header(token) + jwks = requests.get('https://{}/.well-known/jwks.json'.format('${account.namespace}')).json() + public_key = None + for jwk in jwks['keys']: + if jwk['kid'] == header['kid']: + public_key = jwt.algorithms.RSAAlgorithm.from_jwk(json.dumps(jwk)) + + if public_key is None: + raise Exception('Public key not found.') + + issuer = 'https://{}/'.format('${account.namespace}') + return jwt.decode(token, public_key, audience='${apiIdentifier}', issuer=issuer, algorithms=['RS256']) +``` + +### Validate scopes + +Add the following methods to the `views.py` file to create a decorator that will check the granted scopes from the `access_token`. + +```python +# auth0authorization/views.py + +from functools import wraps +import jwt + +from django.http import JsonResponse + +def get_token_auth_header(request): + """Obtains the Access Token from the Authorization Header + """ + auth = request.META.get("HTTP_AUTHORIZATION", None) + parts = auth.split() + token = parts[1] + + return token + +def requires_scope(required_scope): + """Determines if the required scope is present in the Access Token + Args: + required_scope (str): The scope required to access the resource + """ + def require_scope(f): + @wraps(f) + def decorated(*args, **kwargs): + token = get_token_auth_header(args[0]) + decoded = jwt.decode(token, verify=False) + if decoded.get("scope"): + token_scopes = decoded["scope"].split() + for token_scope in token_scopes: + if token_scope == required_scope: + return f(*args, **kwargs) + response = JsonResponse({'message': 'You don\'t have access to this resource'}) + response.status_code = 403 + return response + return decorated + return require_scope +``` + +## Protect API Endpoints + +<%= include('../_includes/_api_endpoints') %> + +In the file `views.py` add `public` and `private` endpoints. Add the `@api_view` decorator to all the endpoints to indicate that the method requires authentication. Lastly, add the decorator `@permission_classes([AllowAny])` to the `public` endpoint to accept unauthenticated requests. + +```python +# auth0authorization/views.py + +from django.http import JsonResponse +from rest_framework.decorators import api_view, permission_classes +from rest_framework.permissions import AllowAny + +@api_view(['GET']) +@permission_classes([AllowAny]) +def public(request): + return JsonResponse({'message': 'Hello from a public endpoint! You don\'t need to be authenticated to see this.'}) + + +@api_view(['GET']) +def private(request): + return JsonResponse({'message': 'Hello from a private endpoint! You need to be authenticated to see this.'}) +``` + +Use the `requires_scope` decorator in the methods that require specific scopes granted. The method below requires the `read:messages` scope granted. + +```python +# auth0authorization/views.py + +@api_view(['GET']) +@requires_scope('read:messages') +def private_scoped(request): + return JsonResponse({'message': 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.'}) +``` + +### Add URL mappings + +In previous steps, we added methods to the `views.py` file. We need to map those methods to URLs. + +Django has a [URL dispatcher](https://docs.djangoproject.com/en/2.2/topics/http/urls/) that lets you map URL patterns to views. + +Create the file `urls.py` in your application folder. Add the URL patterns. + +```python +# auth0authorization/urls.py + +from django.urls import path + +from . import views + +urlpatterns = [ + path('api/public', views.public), + path('api/private', views.private), + path('api/private-scoped', views.private_scoped), +] +``` + +The Django project also has a `urls.py` file. Add a reference to your application's `urls.py` file. + +```python +# apiexample/urls.py + +from django.contrib import admin +from django.urls import include, path + +urlpatterns = [ + path('admin/', admin.site.urls), + path('', include('auth0authorization.urls')) +] +``` diff --git a/fr-ca/articles/quickstart/backend/django/02-using.md b/fr-ca/articles/quickstart/backend/django/02-using.md new file mode 100644 index 0000000000..00fd101849 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - django +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/django/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/django/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/django/download.md b/fr-ca/articles/quickstart/backend/django/download.md new file mode 100644 index 0000000000..e50de77b51 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/download.md @@ -0,0 +1,16 @@ +To run it from the command line: + +```bash +pip install -r requirements.txt +python manage.py migrate +python manage.py runserver 3010 +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/django/files/urls.md b/fr-ca/articles/quickstart/backend/django/files/urls.md new file mode 100644 index 0000000000..f5a6dc9e24 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/files/urls.md @@ -0,0 +1,20 @@ +--- +name: apiexample/urls.py +language: python +--- + + + +```python +from django.contrib import admin +from django.urls import path +from . import views + + +urlpatterns = [ + path('admin/', admin.site.urls), + path('api/public', views.public), + path('api/private', views.private), + path('api/private-scoped', views.private_scoped) +] +``` diff --git a/fr-ca/articles/quickstart/backend/django/files/validator.md b/fr-ca/articles/quickstart/backend/django/files/validator.md new file mode 100644 index 0000000000..839a4e5abf --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/files/validator.md @@ -0,0 +1,31 @@ +--- +name: apiexample/validator.py +language: python +--- + + + +```python +import json +from urllib.request import urlopen + +from authlib.oauth2.rfc7523 import JWTBearerTokenValidator +from authlib.jose.rfc7517.jwk import JsonWebKey + + +class Auth0JWTBearerTokenValidator(JWTBearerTokenValidator): + def __init__(self, domain, audience): + issuer = f"https://{domain}/" + jsonurl = urlopen(f"{issuer}.well-known/jwks.json") + public_key = JsonWebKey.import_key_set( + json.loads(jsonurl.read()) + ) + super(Auth0JWTBearerTokenValidator, self).__init__( + public_key + ) + self.claims_options = { + "exp": {"essential": True}, + "aud": {"essential": True, "value": audience}, + "iss": {"essential": True, "value": issuer}, + } +``` diff --git a/fr-ca/articles/quickstart/backend/django/files/views.md b/fr-ca/articles/quickstart/backend/django/files/views.md new file mode 100644 index 0000000000..b44ec9baed --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/files/views.md @@ -0,0 +1,42 @@ +--- +name: apiexample/views.py +language: python +--- + + + +```python +from authlib.integrations.django_oauth2 import ResourceProtector +from django.http import JsonResponse +from . import validator + +require_auth = ResourceProtector() +validator = validator.Auth0JWTBearerTokenValidator( + "${account.namespace}", + "${apiIdentifier}" +) +require_auth.register_token_validator(validator) + + +def public(request): + """No access token required to access this route + """ + response = "Hello from a public endpoint! You don't need to be authenticated to see this." + return JsonResponse(dict(message=response)) + + +@require_auth(None) +def private(request): + """A valid access token is required to access this route + """ + response = "Hello from a private endpoint! You need to be authenticated to see this." + return JsonResponse(dict(message=response)) + + +@require_auth("read:messages") +def private_scoped(request): + """A valid access token and an appropriate scope are required to access this route + """ + response = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this." + return JsonResponse(dict(message=response)) +``` diff --git a/fr-ca/articles/quickstart/backend/django/index.yml b/fr-ca/articles/quickstart/backend/django/index.yml new file mode 100644 index 0000000000..67bb80cabe --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/index.yml @@ -0,0 +1,53 @@ +title: Django API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/django.png +logo: django +alias: + - Django +languages: + - Python +author: + name: Luciano Balmaceda + email: luciano.balmaceda@auth0.com + community: false +thirdParty: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/django/dependencies + setup: server-apis/django/setup + use: server-apis/django/use +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +seo_alias: django +default_article: 01-authorization +show_steps: true +github: + org: auth0-samples + repo: auth0-django-api +requirements: + - Python 3.5 and up + - Django 2.2.* + - djangorestframework 3.10.* + - drf-jwt 1.13.* +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/django/interactive.md b/fr-ca/articles/quickstart/backend/django/interactive.md new file mode 100644 index 0000000000..3d4301e943 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/django/interactive.md @@ -0,0 +1,88 @@ +--- +title: Add Authorization to a Django API Application +description: This tutorial demonstrates how to add authorization to a Python API built with Django. +interactive: true +files: + - files/validator + - files/views + - files/urls +github: + - path: 01-Authorization + - branch: py-vnext +--- + + + +# Add Authorization to Your Django API Application + +This guide demonstrates how to integrate Auth0 with any new or existing Python API built with [Django](https://www.djangoproject.com/). + +If you haven't created an API in your Auth0 Dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with. + +Alternatively, you can read our [getting started guide](/get-started/auth0-overview/set-up-apis), which will help you set up your first API through the Auth0 Dashboard. + +Every API in Auth0 is configured using an API Identifier that your application code will use as the Audience to validate the Access Token. + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +# Configure Django to use Auth0 + +## Install dependencies + +1. Add the following dependencies to your `requirements.txt`: + +```python +# /requirements.txt + +Authlib~=1.0.0 +Django~=4.0.3 +python-dotenv~=0.19.2 +``` + +2. Run `pip install -r requirements.txt` + +### Create a Django application + +```shell +django-admin startproject apiexample +cd apiexample +``` + +## Create the JWT validator {{{ data-action=code data-code="apiexample/validator.py" }}} + +You're going to use a library called [Authlib](https://github.com/lepture/authlib) to create a [ResourceProtector](https://docs.authlib.org/en/latest/flask/1/resource-server.html), which is a type of [Django view decorator](https://docs.djangoproject.com/en/4.0/topics/http/decorators/) that protects your resources (API views) with a given validator. + +The validator will verify the Access Token that you pass to the resource by checking that it has a valid signature and claims. + +You can use AuthLib's `JWTBearerTokenValidator` validator with a few tweaks to make sure it conforms to our requirements on [validating Access Tokens](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens). + +To create your `Auth0JWTBearerTokenValidator`, you need to pass it your `domain` and `audience` (API Identifier). It will then get the public key required to verify the token's signature and pass it to the `JWTBearerTokenValidator` class. + +You'll then override the class's `claims_options` to make sure the token's `expiry`, `audience`, and `issue` claims are validated according to our requirements. + +Create the file `apiexample/validator.py` using the code from the interactive panel. + +## Create the API views {{{ data-action=code data-code="apiexample/views.py" }}} + +Next, you'll create three API views in `apiexample/views.py`: + +- `/api/public`: A public endpoint that requires no authentication. +- `/api/private`: A private endpoint that requires a valid Access Token JWT. +- `/api/private-scoped`: A private endpoint that requires a valid Access Token JWT containing the given `scope`. + +The protected routes will have a `require_auth` decorator, which is a `ResourceProtector` that uses the `Auth0JWTBearerTokenValidator` you created earlier. + +To create the `Auth0JWTBearerTokenValidator`, you'll pass it your tenant's domain and the API Identifier of the API you created earlier. + +The `require_auth` decorator on the `private_scoped` route accepts an additional argument `"read:messages"`, which checks the Access Token for the Permission (Scope) you created earlier. + +## Add URL mappings {{{ data-action=code data-code="apiexample/urls.py#8:10" }}} + +In previous steps, you added methods to the `views.py` file. You need to map those methods to URLs using Django's [URL dispatcher](https://docs.djangoproject.com/en/4.0/topics/http/urls/), which lets you map URL patterns to views. + +Add the URL patterns to `apiexample/urls.py`: + +<%= include('../_includes/_call_api') %> diff --git a/fr-ca/articles/quickstart/backend/golang/01-authorization.md b/fr-ca/articles/quickstart/backend/golang/01-authorization.md new file mode 100644 index 0000000000..8fa1a0a938 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/01-authorization.md @@ -0,0 +1,257 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to a Go API. +topics: + - quickstart + - backend + - golang +github: + path: 01-Authorization-RS256 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Validate Access Tokens + +### Download dependencies + +Add a `go.mod` file to list all the dependencies to be used. + +```text +// go.mod + +module 01-Authorization-RS256 + +go 1.21 + +require ( + github.com/auth0/go-jwt-middleware/v2 v2.2.0 + github.com/joho/godotenv v1.5.1 +) +``` + +Download dependencies by running the following shell command: + +```shell +go mod download +``` + +### Configure your application + +Create a `.env` file within the root of your project directory to store the app configuration, and fill in the +environment variables: + +```sh +# The URL of our Auth0 Tenant Domain. +# If you're using a Custom Domain, be sure to set this to that value instead. +AUTH0_DOMAIN='${account.namespace}' + +# Our Auth0 API's Identifier. +AUTH0_AUDIENCE='YOUR_API_IDENTIFIER' +``` + +### Create a middleware to validate Access Tokens + +Access Token validation will be done in the `EnsureValidToken` middleware function which can be applied to any +endpoints you wish to protect. If the token is valid, the resources which are served by the endpoint can be released, +otherwise a `401 Authorization` error will be returned. + +Setup **go-jwt-middleware** middleware to verify Access Tokens from incoming requests. + +```go +// middleware/jwt.go + +package middleware + +import ( + "context" + "log" + "net/http" + "net/url" + "os" + "time" + + jwtmiddleware "github.com/auth0/go-jwt-middleware/v2" + "github.com/auth0/go-jwt-middleware/v2/jwks" + "github.com/auth0/go-jwt-middleware/v2/validator" +) + +// CustomClaims contains custom data we want from the token. +type CustomClaims struct { + Scope string `json:"scope"` +} + +// Validate does nothing for this example, but we need +// it to satisfy validator.CustomClaims interface. +func (c CustomClaims) Validate(ctx context.Context) error { + return nil +} + +// EnsureValidToken is a middleware that will check the validity of our JWT. +func EnsureValidToken() func(next http.Handler) http.Handler { + issuerURL, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/") + if err != nil { + log.Fatalf("Failed to parse the issuer url: %v", err) + } + + provider := jwks.NewCachingProvider(issuerURL, 5*time.Minute) + + jwtValidator, err := validator.New( + provider.KeyFunc, + validator.RS256, + issuerURL.String(), + []string{os.Getenv("AUTH0_AUDIENCE")}, + validator.WithCustomClaims( + func() validator.CustomClaims { + return &CustomClaims{} + }, + ), + validator.WithAllowedClockSkew(time.Minute), + ) + if err != nil { + log.Fatalf("Failed to set up the jwt validator") + } + + errorHandler := func(w http.ResponseWriter, r *http.Request, err error) { + log.Printf("Encountered error while validating JWT: %v", err) + + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusUnauthorized) + w.Write([]byte(`{"message":"Failed to validate JWT."}`)) + } + + middleware := jwtmiddleware.New( + jwtValidator.ValidateToken, + jwtmiddleware.WithErrorHandler(errorHandler), + ) + + return func(next http.Handler) http.Handler { + return middleware.CheckJWT(next) + } +} +``` + +<%= include('../_includes/_api_jwks_description') %> + + +## Protect API Endpoints + +To protect individual routes, pass `middleware` (defined above) to the http route. + +```go +// main.go + +package main + +import ( + "log" + "net/http" + + "github.com/joho/godotenv" + + "01-Authorization-RS256/middleware" +) + +func main() { + if err := godotenv.Load(); err != nil { + log.Fatalf("Error loading the .env file: %v", err) + } + + router := http.NewServeMux() + + // This route is always accessible. + router.Handle("/api/public", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a public endpoint! You don't need to be authenticated to see this."}`)) + })) + + // This route is only accessible if the user has a valid access_token. + router.Handle("/api/private", middleware.EnsureValidToken()( + http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + // CORS Headers. + w.Header().Set("Access-Control-Allow-Credentials", "true") + w.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000") + w.Header().Set("Access-Control-Allow-Headers", "Authorization") + + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`)) + }), + )) + + log.Print("Server listening on http://localhost:3010") + if err := http.ListenAndServe("0.0.0.0:3010", router); err != nil { + log.Fatalf("There was an error with the http server: %v", err) + } +} +``` + +### Validate scopes + +The `middleware` above verifies that the Access Token included in the request is valid; however, it doesn't yet include +any mechanism for checking that the token has the sufficient **scope** to access the requested resources. + +Create a function to check and ensure the Access Token has the correct scope before returning a successful response. + +```go +// 👆 We're continuing from the steps above. Append this to your middleware/jwt.go file. + +// HasScope checks whether our claims have a specific scope. +func (c CustomClaims) HasScope(expectedScope string) bool { + result := strings.Split(c.Scope, " ") + for i := range result { + if result[i] == expectedScope { + return true + } + } + + return false +} +``` + +Use this function in the endpoint that requires the scope `read:messages`. + +```go +// 👆 We're continuing from the steps above. Append this to your main.go file. + +func main() { + // ... + + // This route is only accessible if the user has a + // valid access_token with the read:messages scope. + router.Handle("/api/private-scoped", middleware.EnsureValidToken()( + http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + // CORS Headers. + w.Header().Set("Access-Control-Allow-Credentials", "true") + w.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000") + w.Header().Set("Access-Control-Allow-Headers", "Authorization") + + w.Header().Set("Content-Type", "application/json") + + token := r.Context().Value(jwtmiddleware.ContextKey{}).(*validator.ValidatedClaims) + + claims := token.CustomClaims.(*middleware.CustomClaims) + if !claims.HasScope("read:messages") { + w.WriteHeader(http.StatusForbidden) + w.Write([]byte(`{"message":"Insufficient scope."}`)) + return + } + + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`)) + }), + )) + + // ... +} +``` + +In this example, only the `read:messages` scope is checked. You may want to extend the `HasScope` function or make it +a standalone middleware that accepts multiple scopes to fit your use case. diff --git a/fr-ca/articles/quickstart/backend/golang/02-using.md b/fr-ca/articles/quickstart/backend/golang/02-using.md new file mode 100644 index 0000000000..bb649cc040 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - golang +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/golang/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/golang/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/golang/download.md b/fr-ca/articles/quickstart/backend/golang/download.md new file mode 100644 index 0000000000..a33eed6906 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/download.md @@ -0,0 +1,15 @@ +To run it from the command line: + +```bash +go mod vendor +go run main.go +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` diff --git a/fr-ca/articles/quickstart/backend/golang/files/jwt.md b/fr-ca/articles/quickstart/backend/golang/files/jwt.md new file mode 100644 index 0000000000..d9aba4c4f1 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/files/jwt.md @@ -0,0 +1,90 @@ +--- +name: middleware/jwt.go +language: go +--- + + + +```go +package middleware + +import ( + "context" + "log" + "net/http" + "net/url" + "os" + "strings" + "time" + + jwtmiddleware "github.com/auth0/go-jwt-middleware/v2" + "github.com/auth0/go-jwt-middleware/v2/jwks" + "github.com/auth0/go-jwt-middleware/v2/validator" +) + +// CustomClaims contains custom data we want from the token. +type CustomClaims struct { + Scope string `json:"scope"` +} + +// Validate does nothing for this example, but we need +// it to satisfy validator.CustomClaims interface. +func (c CustomClaims) Validate(ctx context.Context) error { + return nil +} + +// EnsureValidToken is a middleware that will check the validity of our JWT. +func EnsureValidToken() func(next http.Handler) http.Handler { + issuerURL, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/") + if err != nil { + log.Fatalf("Failed to parse the issuer url: %v", err) + } + + provider := jwks.NewCachingProvider(issuerURL, 5*time.Minute) + + jwtValidator, err := validator.New( + provider.KeyFunc, + validator.RS256, + issuerURL.String(), + []string{os.Getenv("AUTH0_AUDIENCE")}, + validator.WithCustomClaims( + func() validator.CustomClaims { + return &CustomClaims{} + }, + ), + validator.WithAllowedClockSkew(time.Minute), + ) + if err != nil { + log.Fatalf("Failed to set up the jwt validator") + } + + errorHandler := func(w http.ResponseWriter, r *http.Request, err error) { + log.Printf("Encountered error while validating JWT: %v", err) + + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusUnauthorized) + w.Write([]byte(`{"message":"Failed to validate JWT."}`)) + } + + middleware := jwtmiddleware.New( + jwtValidator.ValidateToken, + jwtmiddleware.WithErrorHandler(errorHandler), + ) + + return func(next http.Handler) http.Handler { + return middleware.CheckJWT(next) + } +} + +// HasScope checks whether our claims have a specific scope. +func (c CustomClaims) HasScope(expectedScope string) bool { + result := strings.Split(c.Scope, " ") + for i := range result { + if result[i] == expectedScope { + return true + } + } + + return false +} +``` diff --git a/fr-ca/articles/quickstart/backend/golang/files/main.md b/fr-ca/articles/quickstart/backend/golang/files/main.md new file mode 100644 index 0000000000..5e8d5498df --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/files/main.md @@ -0,0 +1,70 @@ +--- +name: main.go +language: go +--- + + + +```go +package main + +import ( + "01-Authorization-RS256/middleware" + "log" + "net/http" + + jwtmiddleware "github.com/auth0/go-jwt-middleware/v2" + "github.com/auth0/go-jwt-middleware/v2/validator" + "github.com/joho/godotenv" +) + +func main() { + if err := godotenv.Load(); err != nil { + log.Fatalf("Error loading the .env file: %v", err) + } + + router := http.NewServeMux() + + // This route is always accessible. + router.Handle("/api/public", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a public endpoint! You don't need to be authenticated to see this."}`)) + })) + + // This route is only accessible if the user has a valid access_token. + router.Handle("/api/private", middleware.EnsureValidToken()( + http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + w.Header().Set("Content-Type", "application/json") + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`)) + }), + )) + + // This route is only accessible if the user has a + // valid access_token with the read:messages scope. + router.Handle("/api/private-scoped", middleware.EnsureValidToken()( + http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + w.Header().Set("Content-Type", "application/json") + + token := r.Context().Value(jwtmiddleware.ContextKey{}).(*validator.ValidatedClaims) + + claims := token.CustomClaims.(*middleware.CustomClaims) + if !claims.HasScope("read:messages") { + w.WriteHeader(http.StatusForbidden) + w.Write([]byte(`{"message":"Insufficient scope."}`)) + return + } + + w.WriteHeader(http.StatusOK) + w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`)) + }), + )) + + log.Print("Server listening on http://localhost:3010") + if err := http.ListenAndServe("0.0.0.0:3010", router); err != nil { + log.Fatalf("There was an error with the http server: %v", err) + } +} + +``` diff --git a/fr-ca/articles/quickstart/backend/golang/index.yml b/fr-ca/articles/quickstart/backend/golang/index.yml new file mode 100644 index 0000000000..08e116eafa --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/index.yml @@ -0,0 +1,54 @@ +title: Go API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/golang.png +logo: golang +thirdParty: false +alias: + - go + - golang +languages: + - Go +author: + name: Sergiu Ghitea + email: sergiu.ghitea@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/golang/dependencies + setup: server-apis/golang/setup + use: server-apis/golang/use +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +default_article: 01-authorization +show_steps: true +github: + org: auth0-samples + repo: auth0-golang-api-samples +sdk: + name: go-jwt-middleware + url: https://github.com/auth0/go-jwt-middleware + logo: golang +requirements: + - Go 1.21+ +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/golang/interactive.md b/fr-ca/articles/quickstart/backend/golang/interactive.md new file mode 100644 index 0000000000..3493a2b987 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/golang/interactive.md @@ -0,0 +1,114 @@ +--- +title: Add authorization to a Go API +description: This tutorial demonstrates how to add authorization to a Go API. +topics: + - quickstart + - backend + - golang +interactive: true +github: + path: 01-Authorization-RS256 +contentType: tutorial +useCase: quickstart +files: + - files/jwt + - files/main +--- + + + +# Add Authorization to Your Go Application +This guide demonstrates how to integrate Auth0 with any new or existing Go API application using the [go-jwt-middleware](https://github.com/auth0/go-jwt-middleware) package. + +If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API for your project. + +To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis). + +Each Auth0 API uses the API Identifier, which your application needs to validate the access token. + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +## Install dependencies + +Add a `go.mod` file to list all the necessary dependencies. + +```text +// go.mod + +module 01-Authorization-RS256 + +go 1.21 + +require ( + github.com/auth0/go-jwt-middleware/v2 v2.2.0 + github.com/joho/godotenv v1.5.1 +) +``` + +Download dependencies by running the following shell command: + +```shell +go mod download +``` + +## Configure your application + +Create a `.env` file within the root of your project directory to store the app configuration, and fill in the +environment variables: + +```sh +# The URL of our Auth0 Tenant Domain. +# If you're using a Custom Domain, be sure to set this to that value instead. +AUTH0_DOMAIN='${account.namespace}' + +# Our Auth0 API's Identifier. +AUTH0_AUDIENCE='${apiIdentifier}' +``` + +## Create a middleware to validate access tokens {{{ data-action=code data-code="middleware/jwt.go" }}} + +The `EnsureValidToken` middleware function validates the access token. You can apply this function to any endpoints you wish to protect. +If the token is valid, the endpoint releases the resources. If the token is not valid, the API returns a `401 Authorization` error. + +Setup the **go-jwt-middleware** middleware to verify access tokens from incoming requests. + +<%= include('../_includes/_api_jwks_description_no_link') %> + +Include a mechanism to check that the token has sufficient **scope** to access the requested resources. + + +Create a function `HasScope` to check and ensure the access token has the correct scope before returning a successful response. + +## Protect API endpoints {{{ data-action=code data-code="main.go" }}} + +In this example, create an `/api/public` endpoint that does not use the `EnsureToken` middleware as it is accessible to non-authenticated requests. + +Create an `/api/private` endpoint that requires the `EnsureToken` middleware as it is only available to authenticated requests containing an access token with no additional scope. + +Create an `/api/private-scoped` endpoint that requires the `EnsureToken` middleware and `HasScope` as it is only available for authenticated requests containing an access token with the `read:messages` scope granted. + +::: note +Only the `read:messages` scope is checked by the `HasScope` function, you may want to extend it or make it a standalone middleware that accepts multiple scopes to fit your use case. +::: + +<%= include('../_includes/_call_api') %> + +::::checkpoint +:::checkpoint-default +Now that you have configured your application, run your application to verify that: +* `GET /api/public` is available for non-authenticated requests. +* `GET /api/private` is available for authenticated requests. +* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope. +::: + +:::checkpoint-failure +If your application did not start successfully: +* Verify you added the token as the `Authorization` header +* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/). + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/01-authorization.md b/fr-ca/articles/quickstart/backend/java-spring-security5/01-authorization.md new file mode 100644 index 0000000000..fa3cf07bb4 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/01-authorization.md @@ -0,0 +1,205 @@ +--- +title: Authorization +name: How to secure your API with Spring Boot +description: This tutorial demonstrates how to add authorization to an API using the Okta Spring Boot Starter. +budicon: 500 +topics: + - quickstart + - backend + - java + - spring-security +github: + path: 01-Authorization-MVC +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_auth_preamble') %> + +<%= include('../../../_includes/_api_auth_intro') %> + +::: note +This Quickstart uses Spring MVC. If you are using Spring WebFlux, the steps to secure an API are similar, but some of the implementation details are different. Refer to the [Spring Security WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-security5-api-sample/tree/master/01-Authorization-WebFlux) to see how to integrate Auth0 with your Spring WebFlux API. +::: + + +<%= include('../_includes/_api_create_new') %> + +## Configure the Sample Project + +The sample project uses a `/src/main/resources/application.yml` file, which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page it will be automatically configured. If you clone the example from GitHub, you will need to fill it in yourself. + +```yaml +okta: + oauth2: + # Replace with the domain of your Auth0 tenant. + issuer: https://${account.namespace}/ + # Replace with the API Identifier for your Auth0 API. + audience: ${apiIdentifier} +``` + +| Attribute | Description| +| --- | --- | +| `okta.oauth2.audience` | The unique identifier for your API. If you are following the steps in this tutorial it would be `https://quickstarts/api`. | +| `okta.oauth2.issuer` | The issuer URI of the resource server, which will be the value of the `iss` claim in the JWT issued by Auth0. Spring Security will use this property to discover the authorization server's public keys and validate the JWT signature. The value will be your Auth0 domain with an `https://` prefix and a `/` suffix (the trailing slash is important). | + +## Install dependencies + +If you are using Gradle, you can add the required dependencies using the [Spring Boot Gradle Plugin](https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/) and the [Dependency Management Plugin](https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/) to resolve dependency versions: + +```groovy +// build.gradle + +plugins { + id 'java' + id 'org.springframework.boot' version '3.1.5' + id 'io.spring.dependency-management' version '1.1.3' +} + +dependencies { + implementation 'org.springframework.boot:spring-boot-starter-web' + implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5' +} +``` + +If you are using Maven, add the Spring dependencies to your `pom.xml` file: + +```xml +// pom.xml + + + org.springframework.boot + spring-boot-starter-parent + 3.1.5 + + + + + + org.springframework.boot + spring-boot-starter-web + + + com.okta + okta-spring-boot-starter + 3.0.5 + + +``` + +## Protect API endpoints + +<%= include('../_includes/_api_endpoints') %> + +To configure the application as a Resource Server and validate the JWTs, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), an instance of `SecurityFilterChain`, and add the `@Configuration` annotation. + +The example below shows how to secure API methods using the `HttpSecurity` object provided in the `filterChain()` method of the `SecurityConfig` class. Route matchers are used to restrict access based on the level of authorization required: + +```java +// src/main/java/com/auth0/example/security/SecurityConfig.java + +import org.springframework.context.annotation.Bean; +import org.springframework.security.config.annotation.web.builders.HttpSecurity; +import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; +import org.springframework.security.web.SecurityFilterChain; + +@EnableWebSecurity +public class SecurityConfig { + + @Bean + public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { + http.authorizeRequests() + .mvcMatchers("/api/public").permitAll() + .mvcMatchers("/api/private").authenticated() + .mvcMatchers("/api/private-scoped").hasAuthority("SCOPE_read:messages") + .and().cors() + .and().oauth2ResourceServer().jwt(); + return http.build(); + } +} +``` + +::: note +By default, Spring Security will create a `GrantedAuthority` for each scope in the `scope` claim of the JWT. This is what enables using the `hasAuthority("SCOPE_read:messages")` method to restrict access to a valid JWT that contains the `read:messages` scope. +::: + +### Create the API controller + +Create a new record named `Message`, which will be the domain object the API will return: + +```java +// src/main/java/com/auth0/example/model/Message.java + +public record Message(String message) {} +``` + +Create a new class named `APIController` to handle requests to the endpoints: + +```java +// src/main/java/com/auth0/example/web/APIController.java + +import com.auth0.example.model.Message; +import org.springframework.http.MediaType; +import org.springframework.web.bind.annotation.CrossOrigin; +import org.springframework.web.bind.annotation.GetMapping; +import org.springframework.web.bind.annotation.RequestMapping; +import org.springframework.web.bind.annotation.RestController; + +/** + * Handles requests to "/api" endpoints. + * @see com.auth0.example.security.SecurityConfig to see how these endpoints are protected. + */ +@RestController +@RequestMapping(path = "api", produces = MediaType.APPLICATION_JSON_VALUE) +// For simplicity of this sample, allow all origins. Real applications should configure CORS for their use case. +@CrossOrigin(origins = "*") +public class APIController { + + @GetMapping(value = "/public") + public Message publicEndpoint() { + return new Message("All good. You DO NOT need to be authenticated to call /api/public."); + } + + @GetMapping(value = "/private") + public Message privateEndpoint() { + return new Message("All good. You can see this because you are Authenticated."); + } + + @GetMapping(value = "/private-scoped") + public Message privateScopedEndpoint() { + return new Message("All good. You can see this because you are Authenticated with a Token granted the 'read:messages' scope"); + } +} +``` + +## Run the Application + +To build and run the sample project, execute the `bootRun` Gradle task. + +Linux or macOS: + +```bash +./gradlew bootRun +``` + +Windows: + +```bash +gradlew.bat bootRun +``` + +If you are configuring your own application using Maven and the [Spring Boot Maven Plugin](https://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-maven-plugin.html), you can execute the `spring-boot:run` goal. + +Linux or macOS: + +```bash +mvn spring-boot:run +``` + +Windows: + +```bash +mvn.cmd spring-boot:run +``` + +The sample application will be available at `http://localhost:3010/`. Read about how to test and use your API in the [Using Your API](/quickstart/backend/java-spring-security5/02-using) article. diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/02-using.md b/fr-ca/articles/quickstart/backend/java-spring-security5/02-using.md new file mode 100644 index 0000000000..466de7dabc --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/02-using.md @@ -0,0 +1,14 @@ +--- +title: Using Your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - java + - spring-security +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/download.md b/fr-ca/articles/quickstart/backend/java-spring-security5/download.md new file mode 100644 index 0000000000..baced1678f --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/download.md @@ -0,0 +1,27 @@ +The sample can be run from the command line as follows: + +Linux / macOS: +```bash +./gradlew clean bootRun +``` + +Windows: +```bash +gradlew.bat clean bootRun +``` + +The application will be served from `http://localhost:3010/`. + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# Linux / macOs +sh exec.sh +``` + +```bash +# Windows +./exec.ps1 +``` + +The application will be served from `http://localhost:3010/`, just as if running with Gradle. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/files/api-controller.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/api-controller.md new file mode 100644 index 0000000000..ece3064bdf --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/api-controller.md @@ -0,0 +1,34 @@ +--- +name: APIController.java +language: java +--- +```java +import com.auth0.example.model.Message; +import org.springframework.http.MediaType; +import org.springframework.web.bind.annotation.CrossOrigin; +import org.springframework.web.bind.annotation.GetMapping; +import org.springframework.web.bind.annotation.RequestMapping; +import org.springframework.web.bind.annotation.RestController; + +@RestController +@RequestMapping(path = "api", produces = MediaType.APPLICATION_JSON_VALUE) +// For simplicity of this sample, allow all origins. Real applications should configure CORS for their use case. +@CrossOrigin(origins = "*") +public class APIController { + + @GetMapping(value = "/public") + public Message publicEndpoint() { + return new Message("All good. You DO NOT need to be authenticated to call /api/public."); + } + + @GetMapping(value = "/private") + public Message privateEndpoint() { + return new Message("All good. You can see this because you are Authenticated."); + } + + @GetMapping(value = "/private-scoped") + public Message privateScopedEndpoint() { + return new Message("All good. You can see this because you are Authenticated with a Token granted the 'read:messages' scope"); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/files/application.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/application.md new file mode 100644 index 0000000000..f12a521ce0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/application.md @@ -0,0 +1,12 @@ +--- +name: application.yml +language: yaml +--- +```yaml +okta: + oauth2: + # Replace with the domain of your Auth0 tenant. + issuer: https://${account.namespace}/ + # Replace with the API Identifier for your Auth0 API. + audience: ${apiIdentifier} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/files/message.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/message.md new file mode 100644 index 0000000000..99f4056914 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/message.md @@ -0,0 +1,11 @@ +--- +name: Message.java +language: java +--- +```java +/** + * Simple domain object for our API to return a message. + */ +public record Message(String message) {} + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/files/security-config.md b/fr-ca/articles/quickstart/backend/java-spring-security5/files/security-config.md new file mode 100644 index 0000000000..257bdbaa32 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/files/security-config.md @@ -0,0 +1,42 @@ +--- +name: SecurityConfig.java +language: java +--- +```java +package com.auth0.example.security; + + +import org.springframework.context.annotation.Bean; +import org.springframework.context.annotation.Configuration; +import org.springframework.security.config.annotation.web.builders.HttpSecurity; +import org.springframework.security.web.SecurityFilterChain; + +import static org.springframework.security.config.Customizer.withDefaults; + +/** + * Configures our application with Spring Security to restrict access to our API endpoints. + */ +@Configuration +public class SecurityConfig { + + @Bean + public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { + /* + This is where we configure the security required for our endpoints and setup our app to serve as + an OAuth2 Resource Server, using JWT validation. + */ + return http + .authorizeHttpRequests((authorize) -> authorize + .requestMatchers("/api/public").permitAll() + .requestMatchers("/api/private").authenticated() + .requestMatchers("/api/private-scoped").hasAuthority("SCOPE_read:messages") + ) + .cors(withDefaults()) + .oauth2ResourceServer(oauth2 -> oauth2 + .jwt(withDefaults()) + ) + .build(); + } +} + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/index.yml b/fr-ca/articles/quickstart/backend/java-spring-security5/index.yml new file mode 100644 index 0000000000..9baab5db4c --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/index.yml @@ -0,0 +1,62 @@ +title: Spring Boot API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/java.png +logo: spring +thirdParty: false +author: + name: Jim Anderson + email: jim.anderson@auth0.com + community: false +sdk: + name: Okta Spring Boot Starter + url: https://github.com/okta/okta-spring-boot/ + logo: spring +alias: + - spring security + - spring +languages: + - Java +framework: + - Spring +topics: + - quickstart +contentType: tutorial +useCase: quickstart +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +default_article: 01-authorization +hidden_articles: + - "interactive" +show_steps: true +github: + org: auth0-samples + repo: auth0-spring-security5-api-sample +requirements: + - Java 17 +next_steps: + - path: 01-authorization + list: + - text: "Part 2: Using Your API" + icon: 345 + href: "/quickstart/backend/java-spring-security5/02-using" + - path: 02-using + list: + - text: "Part 3: Troubleshooting Your API" + icon: 345 + href: "/quickstart/backend/java-spring-security5/03-troubleshooting" + - path: 03-troubleshooting + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about Role-Based Access Control + icon: 345 + href: "/authorization/concepts/rbac" \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/java-spring-security5/interactive.md b/fr-ca/articles/quickstart/backend/java-spring-security5/interactive.md new file mode 100644 index 0000000000..6ec61b3fe1 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/java-spring-security5/interactive.md @@ -0,0 +1,156 @@ +--- +title: Spring Boot API +description: Secure your API using the Okta Spring Boot Starter +interactive: true +alias: + - spring security + - spring +topics: + - quickstart + - backend + - spring +files: + - files/application + - files/security-config + - files/message + - files/api-controller +github: + path: 01-Authorization-MVC +--- + +# Add Authorization to Your Spring Boot Application + +Auth0 allows you to quickly add authorization to your application. This guide demonstrates how to integrate Auth0 with any new or existing Spring Boot application. + +If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with. + +Review [our getting started guide](get-started/auth0-overview/set-up-apis) to set up your first API through the Auth0 dashboard. + +Each Auth0 API uses the API Identifier, which your application needs to validate the access token. + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +## Configure the sample project {{{ data-action=code data-code="application.yml#1:8" }}} + +The sample project uses a `/src/main/resources/application.yml` file, which configures it to use the correct Auth0 **domain** and **API Identifier** for your API. If you download the code from this page it will be automatically configured. If you clone the example from GitHub, you will need to fill it in yourself. + +| Attribute | Description| +| --- | --- | +| `okta.oauth2.audience` | The unique identifier for your API. If you are following the steps in this tutorial it would be `https://quickstarts/api`. | +| `okta.oauth2.issuer` | The issuer URI of the resource server, which will be the value of the `iss` claim in the JWT issued by Auth0. Spring Security will use this property to discover the authorization server's public keys and validate the JWT signature. The value will be your Auth0 domain with an `https://` prefix and a `/` suffix (the trailing slash is important). + +## Install dependencies {{{ data-action=code data-code="application.yml#1:8" }}} + +If you are using Gradle, you can add the required dependencies using the [Spring Boot Gradle Plugin](https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/) and the [Dependency Management Plugin](https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/) to resolve dependency versions: + +```groovy +// build.gradle + +plugins { + id 'java' + id 'org.springframework.boot' version '3.1.5' + id 'io.spring.dependency-management' version '1.1.3' +} + +dependencies { + implementation 'org.springframework.boot:spring-boot-starter-web' + implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5' +} +``` + +If you are using Maven, add the Spring dependencies to your `pom.xml` file: + +```xml +// pom.xml + + + org.springframework.boot + spring-boot-starter-parent + 3.1.5 + + + + + + org.springframework.boot + spring-boot-starter-web + + + com.okta.spring + okta-spring-boot-starter + 3.0.5 + + +``` + + +## Configure the resource server {{{ data-action=code data-code="SecurityConfig.java" }}} + +To configure the application as a Resource Server and validate the JWTs, create a class that will provide an instance of `SecurityFilterChain`, and add the `@Configuration` annotation. + +### Protect API endpoints + +<%= include('../_includes/_api_endpoints') %> + +The example below shows how to secure API methods using the `HttpSecurity` object provided in the `filterChain()` method of the `SecurityConfig` class. Route matchers restrict access based on the level of authorization required. + +::: note +By default, Spring Security creates a `GrantedAuthority` for each scope in the `scope` claim of the JWT. This scope enables using the `hasAuthority("SCOPE_read:messages")` method to restrict access to a valid JWT that contains the `read:messages` scope. +::: + +## Create the Domain Object {{{ data-action=code data-code="Message.java#1:11" }}} + +To make your endpoint return a JSON, you can use a Java record. The member variables of this object is serialized into the key value for your JSON. Create a new record named `Message` as an example domain object to return during the API calls. + +## Create the API controller {{{ data-action=code data-code="APIController.java" }}} + +Create a new class named `APIController` to handle requests to the endpoints. The `APIController` has three routes as defined in the [Protect API Endpoints](/quickstart/backend/java-spring-security5/interactive/#configure-the-resource-server) section. For this example, allow all origins through `@CrossOrigin` annotation. Real applications should configure `CORS` for their use case. + +## Run the application {{{ data-action=code data-code="APIController.java" }}} + +To build and run the sample project, execute the `bootRun` Gradle task. + +Linux or macOS: + +```bash +./gradlew bootRun +``` + +Windows: + +```bash +gradlew.bat bootRun +``` + +If you are configuring your own application using Maven and the [Spring Boot Maven Plugin](https://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-maven-plugin.html), you can execute the `spring-boot:run` goal. + +Linux or macOS: + +```bash +mvn spring-boot:run +``` + +Windows: + +```bash +mvn.cmd spring-boot:run +``` + +::::checkpoint + +:::checkpoint-default + +The sample application will be available at `http://localhost:3010/`. Read about how to test and use your API in the [Using Your API](/quickstart/backend/java-spring-security5/02-using) article. +::: + +:::checkpoint-failure +If your application did not launch successfully: +* Use the [Troubleshooting](/quickstart/backend/java-spring-security5/03-troubleshooting) section to check your configuration. + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: diff --git a/fr-ca/articles/quickstart/backend/laravel/01-authorization.md b/fr-ca/articles/quickstart/backend/laravel/01-authorization.md new file mode 100644 index 0000000000..f1611bab94 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/laravel/01-authorization.md @@ -0,0 +1,245 @@ +--- +title: Add Authorization to a Laravel Application +description: Auth0's Laravel SDK allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application. +topics: + - quickstart + - backend + - laravel + - authorization + - php + - laravel +contentType: tutorial +useCase: quickstart +github: + path: sample +--- + + + +--- + +**Backend applications differ from traditional web applications in that they do not handle user authentication or have a user interface. They provide an API that other applications can interact with. They accept [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) from `Authorization` headers in requests to control access to routes.** + +Separate front-end applications are usually built to interact with these types of backends. These can be anything from [single-page applications](https://auth0.com/docs/quickstart/spa) or [native or mobile apps](https://auth0.com/docs/quickstart/native) (all of which Auth0 also provides SDKs for!) + +When users need to interact with your backend application, they first authenticate with Auth0 using the frontend application. The frontend application then retrieves an access token from Auth0, which it can use to make requests to your backend application on behalf of the user. + +As their name implies, [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) are designed to address matters of access control (authorization), and do not contain information about the user. **Backend applications work exclusively with access tokens.** You can retrieve information about the user who created the token using the [Management API](https://auth0.com/docs/api/management/v2), which we will demonstrate later. + +## Laravel Installation + +**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command: + +```shell +composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0 +``` + +All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory: + +```shell +cd auth0-laravel-api +``` + +## SDK Installation + +Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0): + +```shell +composer require auth0/login:^7.8 --update-with-all-dependencies +``` + +Then generate an SDK configuration file for your application: + +```shell +php artisan vendor:publish --tag auth0 +``` + +## SDK Configuration + +Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli): + +```shell +curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b . +``` + +Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted: + +```shell +./auth0 login +``` + +Next, create a new application with Auth0: + +```shell +./auth0 apps create \ + --name "My Laravel Backend" \ + --type "regular" \ + --auth-method "post" \ + --callbacks "http://localhost:8000/callback" \ + --logout-urls "http://localhost:8000" \ + --reveal-secrets \ + --no-input \ + --json > .auth0.app.json +``` + +You should also create a new API: + +```shell +./auth0 apis create \ + --name "My Laravel Backend API" \ + --identifier "https://github.com/auth0/laravel-auth0" \ + --offline-access \ + --no-input \ + --json > .auth0.api.json +``` + +This produces two files in your project directory that configure the SDK. + +As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file: + +```bash +echo ".auth0.*.json" >> .gitignore +``` + +## Access Control + +You can use the Auth0 SDK's authorization guard to restrict access to your application's routes. + +To reject requests that do not contain a valid access token in the `Authorization` header, you can use Laravel's `auth` middleware: + +```php +Route::get('/private', function () { + return response()->json([ + 'message' => 'Your token is valid; you are authorized.', + ]); +})->middleware('auth'); +``` + +You can also require the provided token to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware: + +```php +Route::get('/scope', function () { + return response()->json([ + 'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.', + ]); +})->middleware('auth')->can('read:messages'); +``` + +## Token Information + +Information about the provided access token is available through Laravel's `Auth` Facade, or the `auth()` helper function. + +For example, to retrieve the user's identifier and email address: + +```php +Route::get('/', function () { + if (! auth()->check()) { + return response()->json([ + 'message' => 'You did not provide a valid token.', + ]); + } + + return response()->json([ + 'message' => 'Your token is valid; you are authorized.', + 'id' => auth()->id(), + 'token' => auth()?->user()?->getAttributes(), + ]); +}); +``` + +## Retrieve User Information + +You can retrieve information about the user who created the access token from Auth0 using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). The SDK provides a convenient wrapper for this API, accessible through the SDK's `management()` method. + +**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant. + +For the following example, you should grant the `read:users` scope. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2). + +```php +use Auth0\Laravel\Facade\Auth0; + +Route::get('/me', function () { + $user = auth()->id(); + $profile = cache()->get($user); + + if (null === $profile) { + $endpoint = Auth0::management()->users(); + $profile = $endpoint->get($user); + $profile = Auth0::json($profile); + + cache()->put($user, $profile, 120); + } + + $name = $profile['name'] ?? 'Unknown'; + $email = $profile['email'] ?? 'Unknown'; + + return response()->json([ + 'name' => $name, + 'email' => $email, + ]); +})->middleware('auth'); +``` + +::: note +**You should cache user information in your application for brief periods.** This reduces the number of requests your application makes to Auth0, and improves performance. You should avoid storing user information in your application for long periods as this can lead to stale data. You should also avoid storing user information beyond the user's identifier in persistent databases. +::: + +## Run the Application + +You are now ready to start your Laravel application, so it can accept requests: + +```shell +php artisan serve +``` + +## Retrieve a Test Token + +You can learn more about [retrieving access tokens here](https://auth0.com/docs/secure/tokens/access-tokens/get-access-tokens). For this quickstart, however, you can simply use an access token from [your API settings' "test" view](https://manage.auth0.com/#/apis). + +::: note +The `/me` route we created above will not work with a test token as there is no actual user associated with it. +::: + +## Checkpoint + +Open a shell and try issuing requests to your application. + +Begin by requesting the public route: + +```shell +curl --request GET \ + --url http://localhost:8000/api \ + --header 'Accept: application/json' +``` + +Next, use your access token in an `Authorization` header to request a protected route: + +```shell +curl --request GET \ + --url http://localhost:8000/api/private \ + --header 'Accept: application/json' \ + --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' +``` + +Finally, try requesting the scope-protected route, which will only succeed if the access token has the `read:messages` scope granted: + +```shell +curl --request GET \ + --url http://localhost:8000/api/scope \ + --header 'Accept: application/json' \ + --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' +``` + +If you have any issues, here are a couple of things to try: + +- Try running `php artisan optimize:clear` to clear Laravel's cache. +- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project. +- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/). + +Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions. + +### Additional Reading + +- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database. +- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration. +- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application. diff --git a/fr-ca/articles/quickstart/backend/laravel/download.md b/fr-ca/articles/quickstart/backend/laravel/download.md new file mode 100644 index 0000000000..e149badf02 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/laravel/download.md @@ -0,0 +1,8 @@ +Open a shell to the downloaded project directory, and run the following command: + +```bash +composer install +php artisan migrate +php artisan key:generate +php artisan serve +``` diff --git a/fr-ca/articles/quickstart/backend/laravel/files/api.md b/fr-ca/articles/quickstart/backend/laravel/files/api.md new file mode 100644 index 0000000000..3fe3a4e6b3 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/laravel/files/api.md @@ -0,0 +1,58 @@ +--- +name: routes/api.php +language: php +--- + +```php +json([ + 'message' => 'Your token is valid; you are authorized.', + ]); +})->middleware('auth'); + +Route::get('/scope', function () { + return response()->json([ + 'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.', + ]); +})->middleware('auth')->can('read:messages'); + +Route::get('/', function () { + if (! auth()->check()) { + return response()->json([ + 'message' => 'You did not provide a valid token.', + ]); + } + + return response()->json([ + 'message' => 'Your token is valid; you are authorized.', + 'id' => auth()->id(), + 'token' => auth()?->user()?->getAttributes(), + ]); +}); + +Route::get('/me', function () { + $user = auth()->id(); + $profile = cache()->get($user); + + if (null === $profile) { + $endpoint = Auth0::management()->users(); + $profile = $endpoint->get($user); + $profile = Auth0::json($profile); + + cache()->put($user, $profile, 120); + } + + $name = $profile['name'] ?? 'Unknown'; + $email = $profile['email'] ?? 'Unknown'; + + return response()->json([ + 'name' => $name, + 'email' => $email, + ]); +})->middleware('auth'); +``` diff --git a/fr-ca/articles/quickstart/backend/laravel/index.yml b/fr-ca/articles/quickstart/backend/laravel/index.yml new file mode 100644 index 0000000000..34db441699 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/laravel/index.yml @@ -0,0 +1,36 @@ +title: Laravel API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/php.png +logo: laravel +alias: + - laravel +languages: + - PHP +framework: + - Laravel +author: + name: Evan Sims + email: evan.sims@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +articles: + - 01-authorization +hidden_articles: + - interactive +default_article: 01-authorization +seo_alias: laravel +github: + org: auth0-samples + repo: laravel + branch: 7.x +sdk: + name: laravel-auth0 + url: https://github.com/auth0/laravel-auth0 + logo: laravel +requirements: + - Laravel 9 / 10 + - PHP 8.0+ + - Composer diff --git a/fr-ca/articles/quickstart/backend/laravel/interactive.md b/fr-ca/articles/quickstart/backend/laravel/interactive.md new file mode 100644 index 0000000000..0efae4e396 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/laravel/interactive.md @@ -0,0 +1,263 @@ +--- +title: Add Authorization to a Laravel Application +description: Auth0's Laravel SDK allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application. +topics: + - quickstart + - backend + - laravel + - authorization + - php + - laravel +contentType: tutorial +useCase: quickstart +default: true +github: + path: app +interactive: true +files: + - files/api +--- + +# Add Authorization to Your Laravel Application + +[Auth0's Laravel SDK](https://github.com/auth0/laravel-auth0) allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new (or existing) [Laravel 9 or 10](https://github.com/auth0/laravel-auth0#support-policy) application. + +--- + +**Backend applications differ from traditional web applications in that they do not handle user authentication or have a user interface. They provide an API that other applications can interact with. They accept [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) from `Authorization` headers in requests to control access to routes.** + +Separate front-end applications are usually built to interact with these types of backends. These can be anything from [single-page applications](https://auth0.com/docs/quickstart/spa) or [native or mobile apps](https://auth0.com/docs/quickstart/native) (all of which Auth0 also provides SDKs for!) + +When users need to interact with your backend application, they first authenticate with Auth0 using the frontend application. The frontend application then retrieves an access token from Auth0, which it can use to make requests to your backend application on behalf of the user. + +As their name implies, [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) are designed to address matters of access control (authorization), and do not contain information about the user. **Backend applications work exclusively with access tokens.** You can retrieve information about the user who created the token using the [Management API](https://auth0.com/docs/api/management/v2), which we will demonstrate later. + +## Laravel Installation + +**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command: + +```shell +composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0 +``` + +All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory: + +```shell +cd auth0-laravel-api +``` + +## SDK Installation + +Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0): + +```shell +composer require auth0/login:^7.8 --update-with-all-dependencies +``` + +Then generate an SDK configuration file for your application: + +```shell +php artisan vendor:publish --tag auth0 +``` + +## SDK Configuration + +Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli): + +```shell +curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b . +``` + +Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted: + +```shell +./auth0 login +``` + +Next, create a new application with Auth0: + +```shell +./auth0 apps create \ + --name "My Laravel Backend" \ + --type "regular" \ + --auth-method "post" \ + --callbacks "http://localhost:8000/callback" \ + --logout-urls "http://localhost:8000" \ + --reveal-secrets \ + --no-input \ + --json > .auth0.app.json +``` + +You should also create a new API: + +```shell +./auth0 apis create \ + --name "My Laravel Backend API" \ + --identifier "https://github.com/auth0/laravel-auth0" \ + --offline-access \ + --no-input \ + --json > .auth0.api.json +``` + +This produces two files in your project directory that configure the SDK. + +As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file: + +```bash +echo ".auth0.*.json" >> .gitignore +``` + +## Access Control {{{ data-action=code data-code="routes/api.php#6:16" }}} + +The SDK automatically registers its authorization guard with your Laravel application for use with the `api` middleware, which by default Laravel applies to all routes in your application's `routes/api.php` file. + +::: warning +For the SDK to work as expected without additional configuration, **you should define your routes in the `routes/api.php` file.** +::: + +You can use the Auth0 SDK's authorization guard to restrict access to your application's routes. + +To reject requests that do not contain a valid access token in the `Authorization` header, you can use Laravel's `auth` middleware: + +```php +Route::get('/private', function () { + return response()->json([ + 'message' => 'Your token is valid; you are authorized.', + ]); +})->middleware('auth'); +``` + +You can also require the provided token to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware: + +```php +Route::get('/scope', function () { + return response()->json([ + 'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.', + ]); +})->middleware('auth')->can('read:messages'); +``` + +## Token Information {{{ data-action=code data-code="routes/api.php#18:30" }}} + +Information about the provided access token is available through Laravel's `Auth` Facade, or the `auth()` helper function. + +For example, to retrieve the user's identifier and email address: + +```php +Route::get('/', function () { + if (! auth()->check()) { + return response()->json([ + 'message' => 'You did not provide a valid token.', + ]); + } + + return response()->json([ + 'message' => 'Your token is valid; you are authorized.', + 'id' => auth()->id(), + 'token' => auth()?->user()?->getAttributes(), + ]); +}); +``` + +## Retrieve User Information {{{ data-action=code data-code="routes/api.php#32:51" }}} + +You can retrieve information about the user who created the access token from Auth0 using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). The SDK provides a convenient wrapper for this API, accessible through the SDK's `management()` method. + +**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant. + +For the following example, you should grant the `read:users` scope. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2). + +```php +use Auth0\Laravel\Facade\Auth0; + +Route::get('/me', function () { + $user = auth()->id(); + $profile = cache()->get($user); + + if (null === $profile) { + $endpoint = Auth0::management()->users(); + $profile = $endpoint->get($user); + $profile = Auth0::json($profile); + + cache()->put($user, $profile, 120); + } + + $name = $profile['name'] ?? 'Unknown'; + $email = $profile['email'] ?? 'Unknown'; + + return response()->json([ + 'name' => $name, + 'email' => $email, + ]); +})->middleware('auth'); +``` + +::: note +**You should cache user information in your application for brief periods.** This reduces the number of requests your application makes to Auth0, and improves performance. You should avoid storing user information in your application for long periods as this can lead to stale data. You should also avoid storing user information beyond the user's identifier in persistent databases. +::: + +## Run the Application + +You are now ready to start your Laravel application, so it can accept requests: + +```shell +php artisan serve +``` + +## Retrieve a Test Token + +You can learn more about [retrieving access tokens here](https://auth0.com/docs/secure/tokens/access-tokens/get-access-tokens). For this quickstart, however, you can simply use an access token from [your API settings' "test" view](https://manage.auth0.com/#/apis). + +::: note +The `/me` route we created above will not work with a test token as there is no actual user associated with it. +::: + +::::checkpoint +:::checkpoint-default +Open a shell and try issuing requests to your application. + +Begin by requesting the public route: + +```shell +curl --request GET \ + --url http://localhost:8000/api \ + --header 'Accept: application/json' +``` + +Next, use your access token in an `Authorization` header to request a protected route: + +```shell +curl --request GET \ + --url http://localhost:8000/api/private \ + --header 'Accept: application/json' \ + --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' +``` + +Finally, try requesting the scope-protected route, which will only succeed if the access token has the `read:messages` scope granted: + +```shell +curl --request GET \ + --url http://localhost:8000/api/scope \ + --header 'Accept: application/json' \ + --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' +``` + +::: + +:::checkpoint-failure +Here are a couple of things to try: + +- Try running `php artisan optimize:clear` to clear Laravel's cache. +- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project. +- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/). + +Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions. + +::: +:::: + +### Additional Reading + +- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database. +- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration. +- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application. diff --git a/fr-ca/articles/quickstart/backend/nginx/01-authorization.md b/fr-ca/articles/quickstart/backend/nginx/01-authorization.md new file mode 100644 index 0000000000..0d2db63f36 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nginx/01-authorization.md @@ -0,0 +1,82 @@ +--- +title: Authorization +description: This tutorial demonstrates how to use the Auth0 Nginx SDK to add authentication and authorization to your API. +topics: + - quickstart + - backend + - nginx +contentType: tutorial +useCase: quickstart +--- + +::: panel-info System Requirements +This tutorial and seed project have been tested with the following: +* Openresty 1.9.7.2 +::: + +**Please follow the steps below to secure your existing API with an Nginx reverse-proxy that's configured to process JWT's generated by your Auth0 account.** + +## Install the `nginx-jwt` script into your Nginx server + +The [`nginx-jwt`](https://github.com/auth0/nginx-jwt) script is a Lua script that is designed to run on Nginx servers that have the [HttpLuaModule](https://github.com/openresty/lua-nginx-module#readme) installed. But ultimately its dependencies require components available in the [OpenResty](http://openresty.org/) distribution of Nginx. Therefore, it is recommended that you use **OpenResty** as your Nginx server, and these instructions make that assumption. + +1. Download the latest archive package from [releases](https://github.com/auth0/nginx-jwt/releases). +1. Extract the archive and deploy its contents to a directory on your Nginx server. +1. Specify this directory's path using ngx_lua's [lua_package_path](https://github.com/openresty/lua-nginx-module#lua_package_path) directive: + +```lua +# nginx.conf: + +http { + lua_package_path "/path/to/lua/scripts;;"; + ... +} +``` + +## Configure `nginx-jwt` with your Auth0 account + +1. Export the `JWT_SECRET` environment variable on the Nginx host, setting it equal to your Client Secret. +1. Expose this environment variable to the Nginx server: + +```lua +# nginx.conf: + +env JWT_SECRET; +``` + +## Secure your API + +Now, secure one or more locations that point to your backing service endpoints by using the [access_by_lua](https://github.com/openresty/lua-nginx-module#access_by_lua) directive to call the `nginx-jwt` script's [`auth()`](https://github.com/auth0/nginx-jwt#auth) function before executing any [proxy_* directives](http://nginx.org/en/docs/http/ngx_http_proxy_module.html): + + +```lua +# nginx.conf: + +server { + location /secure_this { + access_by_lua ' + local jwt = require("nginx-jwt") + jwt.auth() + '; + + proxy_pass http://my-backend.com$uri; + } +} +``` + +Click [here](https://github.com/auth0/nginx-jwt#usage) for more usage examples. + + +## Call Your API + +You can now make requests against your secure API by providing the Authorization header in your requests with a valid JWT ID Token. + +```har +{ + "method": "GET", + "url": "http://localhost:8000/path_to_your_api", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" } + ] +} +``` diff --git a/fr-ca/articles/quickstart/backend/nodejs/01-authorization.md b/fr-ca/articles/quickstart/backend/nodejs/01-authorization.md new file mode 100644 index 0000000000..0dd2779686 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/01-authorization.md @@ -0,0 +1,93 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to an Express.js API. +topics: + - quickstart + - backend + - nodejs +github: + path: 01-Authorization-RS256 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new', { sampleLink: 'https://github.com/auth0-samples/auth0-express-api-samples/tree/master/02-Authorization-HS256' }) %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Validate Access Tokens + +### Install dependencies + +This guide shows you how to protect an Express API using the [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) middleware. + +First install the SDK using npm. + +```bash +npm install --save express-oauth2-jwt-bearer +``` +### Configure the middleware + +Configure `express-oauth2-jwt-bearer` with your Domain and API Identifier. + +```js +// server.js + +const express = require('express'); +const app = express(); +const { auth } = require('express-oauth2-jwt-bearer'); + +// Authorization middleware. When used, the Access Token must +// exist and be verified against the Auth0 JSON Web Key Set. +const checkJwt = auth({ + audience: '${apiIdentifier}', + issuerBaseURL: `https://${account.namespace}/`, +}); +``` + +The `checkJwt` middleware shown above checks if the user's Access Token included in the request is valid. If the token is not valid, the user gets a 401 Authorization error when they try to access the endpoints. The middleware doesn't check if the token has the sufficient scope to access the requested resources. + +## Protect API Endpoints + +<%= include('../_includes/_api_endpoints') %> + +To protect an individual route that requires a valid JWT, configure the route with the `checkJwt` `express-oauth2-jwt-bearer` middleware. + +```js +// server.js + +// This route doesn't need authentication +app.get('/api/public', function(req, res) { + res.json({ + message: 'Hello from a public endpoint! You don\'t need to be authenticated to see this.' + }); +}); + +// This route needs authentication +app.get('/api/private', checkJwt, function(req, res) { + res.json({ + message: 'Hello from a private endpoint! You need to be authenticated to see this.' + }); +}); +``` + +You can configure individual routes to look for a particular scope. To achieve that, set up another middleware with the `requiresScope` method. Provide the required scopes and apply the middleware to any routes you want to add authorization to. + +Pass the `checkJwt` and `requiredScopes` middlewares to the route you want to protect. + +```js +// server.js +const { requiredScopes } = require('express-oauth2-jwt-bearer'); + +const checkScopes = requiredScopes('read:messages'); + +app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) { + res.json({ + message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' + }); +}); +``` + +In this configuration, only Access Tokens with the `read:messages` scope can access the endpoint. diff --git a/fr-ca/articles/quickstart/backend/nodejs/02-using.md b/fr-ca/articles/quickstart/backend/nodejs/02-using.md new file mode 100644 index 0000000000..d7c9301b35 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - nodejs +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/nodejs/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/nodejs/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/nodejs/download.md b/fr-ca/articles/quickstart/backend/nodejs/download.md new file mode 100644 index 0000000000..c65790273f --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/download.md @@ -0,0 +1,15 @@ +To run the example you need [Node.JS LTS](https://nodejs.org/en/download/) installed, and to run the following commands: + +```bash +npm install +npm start +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/nodejs/files/server.md b/fr-ca/articles/quickstart/backend/nodejs/files/server.md new file mode 100644 index 0000000000..859872d4de --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/files/server.md @@ -0,0 +1,45 @@ +--- +name: server.js +language: javascript +--- + + + +```javascript +const express = require('express'); +const app = express(); +const { auth, requiredScopes } = require('express-oauth2-jwt-bearer'); + +// Authorization middleware. When used, the Access Token must +// exist and be verified against the Auth0 JSON Web Key Set. +const checkJwt = auth({ + audience: '${apiIdentifier}', + issuerBaseURL: `https://${account.namespace}/`, +}); + +// This route doesn't need authentication +app.get('/api/public', function(req, res) { + res.json({ + message: 'Hello from a public endpoint! You don\'t need to be authenticated to see this.' + }); +}); + +// This route needs authentication +app.get('/api/private', checkJwt, function(req, res) { + res.json({ + message: 'Hello from a private endpoint! You need to be authenticated to see this.' + }); +}); + +const checkScopes = requiredScopes('read:messages'); + +app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) { + res.json({ + message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' + }); +}); + +app.listen(3000, function() { + console.log('Listening on http://localhost:3000'); +}); +``` diff --git a/fr-ca/articles/quickstart/backend/nodejs/index.yml b/fr-ca/articles/quickstart/backend/nodejs/index.yml new file mode 100644 index 0000000000..dd58dfd65c --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/index.yml @@ -0,0 +1,56 @@ +title: Node (Express) API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/node.png +logo: nodejs +thirdParty: false +alias: + - node + - nodejs + - node.js + - express +languages: + - Javascript +author: + name: David Patrick + email: david.patrick@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/nodejs/dependencies + setup: server-apis/nodejs/setup + use: server-apis/nodejs/use +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +default_article: 01-authorization +show_steps: true +github: + org: auth0-samples + repo: auth0-express-api-samples +sdk: + name: express-oauth2-jwt-bearer + url: https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer + logo: nodejs +requirements: + - express-oauth2-jwt-bearer 1.0.0 +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/nodejs/interactive.md b/fr-ca/articles/quickstart/backend/nodejs/interactive.md new file mode 100644 index 0000000000..75bd51786e --- /dev/null +++ b/fr-ca/articles/quickstart/backend/nodejs/interactive.md @@ -0,0 +1,76 @@ +--- +title: Add authorization to an Express.js API application +description: This tutorial demonstrates how to add authorization to an Express.js API. +topics: +- quickstart +- backend +- express +github: + path: 01-Authorization-RS256 +contentType: tutorial +useCase: quickstart +interactive: true +files: +- files/server +--- + + + +# Add Authorization to Your Express.js API Application +This guide demonstrates how to integrate Auth0 with any new or existing Express.js API application using the `express-oauth2-jwt-bearer` package. + +If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing project API. + +To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis). +Each Auth0 API uses the API Identifier, which your application needs to validate the access token. + + + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +## Install dependencies + +First, install the SDK with `npm`. + +```bash +npm install --save express-oauth2-jwt-bearer +``` + +## Configure the middleware {{{ data-action=code data-code="server.js#1:10" }}} + +Configure `express-oauth2-jwt-bearer` with your Domain and API Identifier. + +The `checkJwt` middleware shown to the right checks if the user's access token included in the request is valid. If the token is not valid, the user gets a 401 Authorization error when they try to access the endpoints. + +The middleware does not check if the token has sufficient scope to access the requested resources. + +## Protect API endpoints {{{ data-action=code data-code="server.js#12:32" }}} + +To protect an individual route by requiring a valid JWT, configure the route with the `checkJwt` middleware constructed from `express-oauth2-jwt-bearer`. + +You can configure individual routes to look for a particular scope. To achieve that, set up another middleware with the `requiresScope` method. Provide the required scopes and apply the middleware to any routes you want to add authorization to. + +Pass the `checkJwt` and `requiredScopes` middlewares to the route you want to protect. + +In this configuration, only access tokens with the `read:messages` scope can access the endpoint. + +<%= include('../_includes/_call_api') %> + +::::checkpoint +:::checkpoint-default +Now that you have configured your application, run your application to verify that: +* `GET /api/public` is available for non-authenticated requests. +* `GET /api/private` is available for authenticated requests. +* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope. +::: + +:::checkpoint-failure +If your application did not start successfully: +* Verify you added the token as the `Authorization` header +* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/). + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: diff --git a/fr-ca/articles/quickstart/backend/php/01-authorization.md b/fr-ca/articles/quickstart/backend/php/01-authorization.md new file mode 100644 index 0000000000..5bf983addd --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/01-authorization.md @@ -0,0 +1,177 @@ +--- +title: Authorization +default: true +description: This guide demonstrates how to integrate Auth0 with a PHP backend API using the Auth0 PHP SDK. +budicon: 448 +topics: + - quickstart + - backend + - authorization + - api + - php +contentType: tutorial +useCase: quickstart +github: + path: app +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Integrating your PHP Backend API + +Let's create a sample application that authorizes an Auth0-signed token with a backend API we've written in PHP. We'll take a simple approach here, appropriate for the written format. Still, you should check out the accompanying [Quickstart app on GitHub](https://github.com/auth0-samples/auth0-php-api-samples/) for a more robust example. + +### Installing HTTP Client and Messaging Factories + +The Auth0 PHP SDK supports many PHP-FIG standards to offer maximum interoperability with your project's architecture, but two of particular importance are [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/). These standards allow you to "plugin" networking components of your choice to handle messaging and requests. You will need to install compatible libraries in your project for the SDK to use. + +The most prolific networking library for PHP is Guzzle, although many are available to pick from within the PHP community. Let's use Guzzle for this sample application: + +```sh +composer require guzzlehttp/guzzle guzzlehttp/psr7 http-interop/http-factory-guzzle +``` + +### Installing the PHP SDK + +${snippet(meta.snippets.install)} + +### Configure the SDK + +To begin, let's create a `.env` file within the root of your project directory to store our sample application's configuration and fill in the environment variables: + +```sh +# The URL of our Auth0 Tenant Domain. +# If we're using a Custom Domain, be sure to set this to that value instead. +AUTH0_DOMAIN='https://${account.namespace}' + +# Our Auth0 application's Client ID. +AUTH0_CLIENT_ID='${account.clientId}' + +# Our Auth0 application's Client Secret. +AUTH0_CLIENT_SECRET='${account.clientSecret}' + +# Our Auth0 API's Identifier. +AUTH0_AUDIENCE='YOUR_API_IDENTIFIER' +``` + +As PHP isn't able to read our `.env` file by itself, we'll want to install a library to help with that. Although we'll be using a particular library for our sample application's purposes, any 'dotenv' loader of preference will work in a real-world application. From our project directory, let's run the following shell command to install the library: + +```sh +composer require vlucas/phpdotenv +``` + +Next, let's create the PHP source file we'll be using for these code samples, `index.php`, and let's configure an instance of the Auth0 PHP SDK for our sample application: + +```php +load(); + +// Now instantiate the Auth0 class with our configuration: +$auth0 = new \Auth0\SDK\Auth0([ + 'strategy' => \Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API, + 'domain' => $_ENV['AUTH0_DOMAIN'], + 'clientId' => $_ENV['AUTH0_CLIENT_ID'], + 'clientSecret' => $_ENV['AUTH0_CLIENT_SECRET'], + 'audience' => ($_ENV['AUTH0_AUDIENCE'] ?? null) !== null ? [trim($_ENV['AUTH0_AUDIENCE'])] : null, +]); +``` + + +### Authenticating the user + +For this sample application, we're focusing on [authorization](https://auth0.com/intro-to-iam/authentication-vs-authorization/). There's numerous routes you could go for authenticating your users before they hit your backend API for authorization, such as using [Auth0's SPA.js library](https://github.com/auth0/auth0-spa-js). This approach is demonstrated in [this Quickstart app accompanying Github project](https://github.com/auth0-samples/auth0-php-api-samples/). Regardless of the approach you take, this sample application expects you to pass your Access Token to it through a request parameter or header to work. + +### Authorizing an Access Token + +First, we need to extract the JSON Web Token (JWT) from the incoming HTTP request. Let's look for a `?token` parameter in a GET request or an `HTTP_AUTHORIZATION` or `Authorization` header. + +```PHP +// 👆 We're continuing from the steps above. Append this to your index.php file. + +$jwt = $_GET['token'] ?? $_SERVER['HTTP_AUTHORIZATION'] ?? $_SERVER['Authorization'] ?? null; +``` + +Next, let's decode the token, if one is present: + +```PHP +// 👆 We're continuing from the steps above. Append this to your index.php file. + +// If a token is present, process it. +if ($jwt !== null) { + // Trim whitespace from token string. + $jwt = trim($jwt); + + // Remove the 'Bearer ' prefix, if present, in the event we're getting an Authorization header that's using it. + if (substr($jwt, 0, 7) === 'Bearer ') { + $jwt = substr($jwt, 7); + } + + // Attempt to decode the token: + try { + $token = $auth0->decode($jwt, null, null, null, null, null, null, \Auth0\SDK\Token::TYPE_TOKEN); + define('ENDPOINT_AUTHORIZED', true); + } catch (\Auth0\SDK\Exception\InvalidTokenException $exception) { + // The token wasn't valid. Let's display the error message from the Auth0 SDK. + // We'd probably want to show a custom error here for a real world application. + die($exception->getMessage()); + } +} +``` + +Depending on how you configure your API routing, how exactly you integrate these checks might look a little different, but the principle is the same: check the token, and in the event your API endpoint requires authorization, deny access if the token isn't valid or acceptable: + +```PHP +// 👆 We're continuing from the steps above. Append this to your index.php file. + +// Is the request authorized? +if (defined('ENDPOINT_AUTHORIZED')) { + // Respond with a JSON response: + echo json_encode([ + 'authorized' => true, + 'data' => $token->toArray() + ], JSON_PRETTY_PRINT); + + exit; +} + +// Issue a HTTP 401 Unauthorized status: +http_response_code(401); + +// Respond with a JSON response: +echo json_encode([ + 'authorized' => false, + 'error' => [ + 'message' => 'You are NOT authorized to be here!' + ] +], JSON_PRETTY_PRINT); +``` + +### Caching + +This works, but in a real-world application, we'll want to use caching to ensure we don't hit our Auth0 rate limits or slow down our application with unnecessary network requests. The Auth0 PHP SDK supports a caching interface called [PSR-6](https://www.php-fig.org/psr/psr-6), which you can plug [any compatible caching library](https://packagist.org/providers/psr/cache-implementation) into for the SDK to fit in nicely with your architecture. + +For our sample, let's use the [Symfony caching component](https://symfony.com/doc/current/components/cache.html) library. From our root project directory, issue the following shell command: + +```sh +composer require symfony/cache +``` + +Next, we need to update our SdkConfiguration to tell the SDK to use it: + +```PHP +// ✋ Insert this BEFORE the token handling we added in the step above, so the SDK uses the cache. + +$tokenCache = new \Symfony\Component\Cache\Adapter\FilesystemAdapter(); +$auth0->configuration()->setTokenCache($tokenCache); +``` + +Our sample application will now cache our token-related network requests. diff --git a/fr-ca/articles/quickstart/backend/php/02-using.md b/fr-ca/articles/quickstart/backend/php/02-using.md new file mode 100644 index 0000000000..6697281ace --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - php +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/php/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/php/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/php/download.md b/fr-ca/articles/quickstart/backend/php/download.md new file mode 100644 index 0000000000..7a3b438ed0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/download.md @@ -0,0 +1,11 @@ +To run the sample, make sure [PHP](http://php.net/downloads.php) and [Composer](https://getcomposer.org/download/) are installed and execute the following commands in the sample's directory: + +```bash +composer run app +``` + +You can also run it from [Docker](https://www.docker.com) with the following commands: + +```bash +composer run docker +``` diff --git a/fr-ca/articles/quickstart/backend/php/files/index.md b/fr-ca/articles/quickstart/backend/php/files/index.md new file mode 100644 index 0000000000..171b3b5524 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/files/index.md @@ -0,0 +1,32 @@ +--- +name: index.php +language: php +--- + +```php +getBearerToken( + get: ['token'], + server: ['Authorization'] + ); + + require('router.php'); +``` diff --git a/fr-ca/articles/quickstart/backend/php/files/router.md b/fr-ca/articles/quickstart/backend/php/files/router.md new file mode 100644 index 0000000000..779733d4b4 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/files/router.md @@ -0,0 +1,63 @@ +--- +name: router.php +language: php +--- + +```php + 'Hello from a public endpoint! You don\'t need to be authenticated to see this.', + 'token' => $token + ]); + }); + + Route::add('/api/private', function() use ($token) { + if ($token === null) { + http_response_code(401); + exit; + } + + routeResponse([ + 'message' => 'Hello from a private endpoint! You need to be authenticated to see this.', + 'token' => $token, + ]); + }); + + Route::add('/api/private-scoped', function() use ($token) { + if ($token === null) { + http_response_code(401); + exit; + } + + if (! in_array('read:messages', $token['scopes'], true)) { + http_response_code(401); + exit; + } + + routeResponse([ + 'message' => 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.', + 'token' => $token, + ]); + }); + + // The following route is just to avoid confusion. + // We're not using an 'index route' in this app, so redirect requests to /api/public. + Route::add('/', function() { + header('Location: /api/public'); + }); + + Route::run(); +``` diff --git a/fr-ca/articles/quickstart/backend/php/index.yml b/fr-ca/articles/quickstart/backend/php/index.yml new file mode 100644 index 0000000000..0bac6302ec --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/index.yml @@ -0,0 +1,53 @@ +title: PHP API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/php.png +logo: php +seo_alias: php +alias: + - php +languages: + - PHP +author: + name: Evan Sims + email: evan.sims@auth0.com + community: false +thirdParty: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + install: server-platforms/php/install +default_article: 01-authorization +articles: + - 01-authorization +hidden_articles: + - 'interactive' +show_steps: true +github: + org: auth0-samples + repo: auth0-php-api-samples + branch: main +sdk: + name: Auth0-PHP + url: https://github.com/auth0/auth0-php + logo: php +requirements: + - PHP 7.4+ (8.0 recommended) + - Auth0-PHP 8.0 + - Composer +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about rules + icon: 345 + href: '/rules' diff --git a/fr-ca/articles/quickstart/backend/php/interactive.md b/fr-ca/articles/quickstart/backend/php/interactive.md new file mode 100644 index 0000000000..6b7f4ed30e --- /dev/null +++ b/fr-ca/articles/quickstart/backend/php/interactive.md @@ -0,0 +1,109 @@ +--- +title: Add endpoint authorization to your PHP application +description: "Auth0 allows you to add token-based endpoint authorization to your PHP application quickly and to protect your routes. This guide demonstrates how to integrate Auth0 with any new or existing PHP application using the Auth0 PHP SDK." +interactive: true +files: + - files/index + - files/router +github: + path: app +--- + +# Add Authorization to Your PHP Application + +Auth0 allows you to add token-based endpoint authorization to almost any application type quickly. This guide demonstrates how to integrate Auth0, add token-based authorization, and protect application routes using the Auth0 PHP SDK. + +To use this quickstart, you’ll need to: +- Sign up for a free Auth0 account or log in to Auth0. +- Have a working PHP project that you want to integrate with Auth0. Alternatively, you can view or download a sample application after logging in. + +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need to have an application registered in the Auth0 Dashboard. The Auth0 application is where you configure how you want authentication to work for your project. + +### Configure an application + +Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code uses to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart automatically updates for your application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample application instead. + +### Configure an API + +Similarly, you need to create a new Auth0 API or use an existing API that represents the project you're integrating from the Dashboard. Choose a unique identifier for the API and make a note of it. You need that identifier to configure your application below. + +## Install the Auth0 PHP SDK {{{ data-action=code data-code="index.php" }}} + +Auth0 provides a [PHP SDK](https://github.com/auth0/auth0-PHP) (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps. + +The Auth0 PHP SDK requires [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/) installed, compatible HTTP libraries for managing network requests. If you don't have libraries available, you can install reliable choices by running the following commands in your terminal: + +```bash +cd +composer require symfony/http-client nyholm/psr7 +``` + +Now, install the Auth0 PHP SDK by running the following command in your terminal: + +```bash +composer require auth0/auth0-php +``` + +### Configure the Auth0 SDK {{{ data-action=code data-code="index.php#7:16" }}} + +For the SDK to function properly, you must set the following properties in the Auth0 SDK during initialization: + +- `strategy`: The strategy helps guide the behavior of the SDK for the use case of your app. In this case, you want to set this to the constant `Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API`. +- `domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under Application's Settings in the _Domain_ field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead. +- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the _Client ID_ field. +- `clientSecret`: The secret of the Auth0 application you created earlier in this quickstart. Client secret is in the Auth0 Dashboard under your Application's Settings in the _Client Secret_ field. +- `audience`: The identifier of the Auth0 API you registered above. This must be provided as an array. + +::::checkpoint +:::checkpoint-default + +Your Auth0 SDK is now properly configured. Run your application to verify that: +- The SDK is initializing correctly. +- Your application is not throwing any errors related to Auth0. + +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* Make sure the correct application is selected. +* Did you save after entering your URLs? +* Make sure the domain and client ID imported correctly. + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Listen for bearer tokens {{{ data-action=code data-code="index.php#20:23" }}} + +Next, expand your application to retrieve and process bearer tokens. Bearer tokens are access tokens provided to your API with requests from clients on a users' behalf. Access tokens approve or deny access to routes in your application. This is referred to as endpoint authorization. + +The easiest way to retrieve access tokens from a request is using the PHP SDK's `getBearerToken()` method. This method fetches tokens from GET parameters, POST bodies, request headers, and other sources. In this case, the PHP SDK processes tokens passed from GET requests in the `token` parameter or from the HTTP `Authorization` header. + +## Create and configure routes {{{ data-action=code data-code="router.php" }}} + +Now, install a routing library to help direct incoming requests to your application. This isn't a required step, but simplifies the application structure for the purposes of this quickstart. + +```bash +composer require steampixel/simple-php-router +``` + +Create a new file in your application called `router.php` to define the routes. Copy in the code from the interactive panel to the right under the router.php tab. + +## Configue endpoint authorization {{{ data-action=code data-code="router.php#21:31" }}} + +Now that you have configured your Auth0 application, the Auth0 PHP SDK, and you application retrieves bearer tokens from requests, the next step is to set up endpoint authorization for your project. The `getBearerToken()` method you implemented above returns a `Token` class that includes details on the request's access. + +Since the `getBearerToken()` method automatically validates and verifies the incoming request, your application determines the details of the access token by evaluating the method's response. When the response is null, no valid token has been provided. Otherwise, inspect the contents of the response to learn more about the request. + +In the interactive panel to the right, you can see a check if the response is null or not to filter access to your `/api/private` route. + +## Authorize with scopes {{{ data-action=code data-code="router.php#33:48" }}} + +In some cases, you may want to filter access to a specific route based on the requested scopes in an access token. As shown in the interactive panel on the right, evaluate the contents of the 'scope' property from the `getBearerToken()` method's response to check the scopes granted by the access token. diff --git a/fr-ca/articles/quickstart/backend/python/01-authorization.md b/fr-ca/articles/quickstart/backend/python/01-authorization.md new file mode 100644 index 0000000000..eb175496f5 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/01-authorization.md @@ -0,0 +1,183 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to a Python API built with Flask. +topics: + - quickstart + - backend + - python +github: + path: 00-Starter-Seed +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Validate Access Tokens + +### Install dependencies + + Add the following dependencies to your `requirements.txt`: + +```python +# /requirements.txt + +flask +python-dotenv +python-jose +flask-cors +six +``` + +### Create a Flask application + +Create a `server.py` file and initialize the [Flask](http://flask.pocoo.org/) application. Set the domain, audience and the error handling. + +```python +# /server.py + +import json +from six.moves.urllib.request import urlopen +from functools import wraps + +from flask import Flask, request, jsonify, _request_ctx_stack +from flask_cors import cross_origin +from jose import jwt + +AUTH0_DOMAIN = '${account.namespace}' +API_AUDIENCE = YOUR_API_AUDIENCE +ALGORITHMS = ["RS256"] + +APP = Flask(__name__) + +# Error handler +class AuthError(Exception): + def __init__(self, error, status_code): + self.error = error + self.status_code = status_code + +@APP.errorhandler(AuthError) +def handle_auth_error(ex): + response = jsonify(ex.error) + response.status_code = ex.status_code + return response +``` + +### Create the JWT validation decorator + +Add a decorator which verifies the Access Token against your JWKS. + +```python +# /server.py + +# Format error response and append status code +def get_token_auth_header(): + """Obtains the Access Token from the Authorization Header + """ + auth = request.headers.get("Authorization", None) + if not auth: + raise AuthError({"code": "authorization_header_missing", + "description": + "Authorization header is expected"}, 401) + + parts = auth.split() + + if parts[0].lower() != "bearer": + raise AuthError({"code": "invalid_header", + "description": + "Authorization header must start with" + " Bearer"}, 401) + elif len(parts) == 1: + raise AuthError({"code": "invalid_header", + "description": "Token not found"}, 401) + elif len(parts) > 2: + raise AuthError({"code": "invalid_header", + "description": + "Authorization header must be" + " Bearer token"}, 401) + + token = parts[1] + return token + +def requires_auth(f): + """Determines if the Access Token is valid + """ + @wraps(f) + def decorated(*args, **kwargs): + token = get_token_auth_header() + jsonurl = urlopen("https://"+AUTH0_DOMAIN+"/.well-known/jwks.json") + jwks = json.loads(jsonurl.read()) + unverified_header = jwt.get_unverified_header(token) + rsa_key = {} + for key in jwks["keys"]: + if key["kid"] == unverified_header["kid"]: + rsa_key = { + "kty": key["kty"], + "kid": key["kid"], + "use": key["use"], + "n": key["n"], + "e": key["e"] + } + if rsa_key: + try: + payload = jwt.decode( + token, + rsa_key, + algorithms=ALGORITHMS, + audience=API_AUDIENCE, + issuer="https://"+AUTH0_DOMAIN+"/" + ) + except jwt.ExpiredSignatureError: + raise AuthError({"code": "token_expired", + "description": "token is expired"}, 401) + except jwt.JWTClaimsError: + raise AuthError({"code": "invalid_claims", + "description": + "incorrect claims," + "please check the audience and issuer"}, 401) + except Exception: + raise AuthError({"code": "invalid_header", + "description": + "Unable to parse authentication" + " token."}, 401) + + _request_ctx_stack.top.current_user = payload + return f(*args, **kwargs) + raise AuthError({"code": "invalid_header", + "description": "Unable to find appropriate key"}, 401) +    return decorated +``` + +### Validate scopes + +Individual routes can be configured to look for a particular `scope` in the Access Token by using the following: + +```python +# /server.py + +def requires_scope(required_scope): + """Determines if the required scope is present in the Access Token + Args: + required_scope (str): The scope required to access the resource + """ + token = get_token_auth_header() + unverified_claims = jwt.get_unverified_claims(token) + if unverified_claims.get("scope"): + token_scopes = unverified_claims["scope"].split() + for token_scope in token_scopes: + if token_scope == required_scope: + return True + return False +``` + +## Protect API Endpoints + +<%= include('../_includes/_api_endpoints') %> + +You can use the decorators and functions define above in the corresponding endpoints. + +${snippet(meta.snippets.use)} diff --git a/fr-ca/articles/quickstart/backend/python/02-using.md b/fr-ca/articles/quickstart/backend/python/02-using.md new file mode 100644 index 0000000000..776d13c743 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - python +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/python/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/python/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/python/download.md b/fr-ca/articles/quickstart/backend/python/download.md new file mode 100644 index 0000000000..e6f16b42ac --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/download.md @@ -0,0 +1,15 @@ +To run it from the command line: + +```bash +pip install -r requirements.txt +python server.py +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/python/files/server.md b/fr-ca/articles/quickstart/backend/python/files/server.md new file mode 100644 index 0000000000..38a189d539 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/files/server.md @@ -0,0 +1,60 @@ +--- +name: server.py +language: python +--- + + + +```python +"""Python Flask API Auth0 integration example +""" + +from os import environ as env + +from dotenv import load_dotenv, find_dotenv +from flask import Flask, jsonify +from authlib.integrations.flask_oauth2 import ResourceProtector +from validator import Auth0JWTBearerTokenValidator + +require_auth = ResourceProtector() +validator = Auth0JWTBearerTokenValidator( + "${account.namespace}", + "${apiIdentifier}" +) +require_auth.register_token_validator(validator) + +APP = Flask(__name__) + + +@APP.route("/api/public") +def public(): + """No access token required.""" + response = ( + "Hello from a public endpoint! You don't need to be" + " authenticated to see this." + ) + return jsonify(message=response) + + +@APP.route("/api/private") +@require_auth(None) +def private(): + """A valid access token is required.""" + response = ( + "Hello from a private endpoint! You need to be" + " authenticated to see this." + ) + return jsonify(message=response) + + +@APP.route("/api/private-scoped") +@require_auth("read:messages") +def private_scoped(): + """A valid access token and scope are required.""" + response = ( + "Hello from a private endpoint! You need to be" + " authenticated and have a scope of read:messages to see" + " this." + ) + return jsonify(message=response) +``` diff --git a/fr-ca/articles/quickstart/backend/python/files/validator.md b/fr-ca/articles/quickstart/backend/python/files/validator.md new file mode 100644 index 0000000000..75d432e488 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/files/validator.md @@ -0,0 +1,31 @@ +--- +name: validator.py +language: python +--- + + + +```python +import json +from urllib.request import urlopen + +from authlib.oauth2.rfc7523 import JWTBearerTokenValidator +from authlib.jose.rfc7517.jwk import JsonWebKey + + +class Auth0JWTBearerTokenValidator(JWTBearerTokenValidator): + def __init__(self, domain, audience): + issuer = f"https://{domain}/" + jsonurl = urlopen(f"{issuer}.well-known/jwks.json") + public_key = JsonWebKey.import_key_set( + json.loads(jsonurl.read()) + ) + super(Auth0JWTBearerTokenValidator, self).__init__( + public_key + ) + self.claims_options = { + "exp": {"essential": True}, + "aud": {"essential": True, "value": audience}, + "iss": {"essential": True, "value": issuer}, + } +``` diff --git a/fr-ca/articles/quickstart/backend/python/index.yml b/fr-ca/articles/quickstart/backend/python/index.yml new file mode 100644 index 0000000000..765d5a3e18 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/index.yml @@ -0,0 +1,55 @@ +title: Python API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/python.png +logo: python +alias: + - python +languages: + - Python +author: + name: Luciano Balmaceda + email: luciano.balmaceda@auth0.com + community: false +thirdParty: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/python/dependencies + setup: server-apis/python/setup + use: server-apis/python/use +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +default_article: 01-authorization +show_steps: true +github: + org: auth0-samples + repo: auth0-python-api-samples +sdk: + name: auth0-python + url: https://github.com/auth0/auth0-python + logo: python +hidden_articles: + - interactive +requirements: + - Python 3.6 and up + - Flask 2.0 + - Authlib 1.0 +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/python/interactive.md b/fr-ca/articles/quickstart/backend/python/interactive.md new file mode 100644 index 0000000000..dfbeffb192 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/python/interactive.md @@ -0,0 +1,69 @@ +--- +title: Add Authorization to a Flask API application +description: This tutorial demonstrates how to add authorization to a Python API built with Flask. +interactive: true +files: + - files/validator + - files/server +github: + - path: 00-Starter-Seed + - branch: pyvnext-rewrite +--- + + + +# Add Authorization to Your Flask API Application + +This guide demonstrates how to integrate Auth0 with any new or existing Python API built with [Flask](https://flask.palletsprojects.com/). + +If you haven't created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with. + +Alternatively, you can read [our getting started guide](get-started/auth0-overview/set-up-apis) that helps you set up your first API through the Auth0 dashboard. + +Every API in Auth0 is configured using an API Identifier that your application code will use as the Audience to validate the Access Token. + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +# Configure Flask to Use Auth0 + +## Install dependencies + +Add the following dependencies to your `requirements.txt`: + +```python +# /requirements.txt + +flask +Authlib +``` + +## Create the JWT validator {{{ data-action=code data-code="validator.py" }}} + +We're going to use a library called [Authlib](https://github.com/lepture/authlib) to create a [ResourceProtector](https://docs.authlib.org/en/latest/flask/1/resource-server.html), which is a type of [Flask decorator](https://flask.palletsprojects.com/patterns/viewdecorators/) that protects our resources (API routes) with a given validator. + +The validator will validate the Access Token that we pass to the resource by checking that it has a valid signature and claims. + +We can use AuthLib's `JWTBearerTokenValidator` validator with a few tweaks to make sure it conforms to our requirements on [validating Access Tokens](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens). + +To create our `Auth0JWTBearerTokenValidator` we need to pass it our `domain` and `audience` (API Identifier). It will then get the public key required to verify the token's signature and pass it to the `JWTBearerTokenValidator` class. + +We'll then override the class's `claims_options` to make sure the token's expiry, audience and issue claims are validated according to our requirements. + +## Create a Flask application {{{ data-action=code data-code="server.py" }}} + +Next we'll create a Flask application with 3 API routes: + +- `/api/public` A public endpoint that requires no authentication. +- `/api/private` A private endpoint that requires a valid Access Token JWT. +- `/api/private-scoped` A private endpoint that requires a valid Access Token JWT that contains the given `scope`. + +The protected routes will have a `require_auth` decorator which is a `ResourceProtector` that uses the `Auth0JWTBearerTokenValidator` we created earlier. + +To create the `Auth0JWTBearerTokenValidator` we'll pass it our tenant's domain and the API Identifier of the API we created earlier. + +The `require_auth` decorator on the `private_scoped` route accepts an additional argument `"read:messages"`, which checks the Access Token for the Permission (Scope) we created earlier. + +<%= include('../_includes/_call_api') %> diff --git a/fr-ca/articles/quickstart/backend/rails/01-authorization.md b/fr-ca/articles/quickstart/backend/rails/01-authorization.md new file mode 100644 index 0000000000..2d9d33bad0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/01-authorization.md @@ -0,0 +1,285 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to a Ruby on Rails API. +topics: + - quickstart + - backend + - rails +github: + path: 01-Authentication-RS256 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new', { sampleLink: 'https://github.com/auth0-samples/auth0-rubyonrails-api-samples/tree/OIDC/02-Authentication-HS256' }) %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Validate Access Tokens + +### Install dependencies + +This tutorial performs access token validation using the **[jwt](https://github.com/jwt/ruby-jwt)** Gem within a custom `Auth0Client` class. A Concern called `Secured` is used to authorize endpoints which require authentication through an incoming access token. + +Install the **jwt** Gem. + +```bash +gem 'jwt' +bundle install +``` + +### Create an Auth0Client class + +Create a class called `Auth0Client` which decodes and verifies the incoming access token taken from the `Authorization` header of the request. The public key for your Auth0 tenant can be fetched to verify the token. + +```rb +# app/lib/auth0_client.rb + +# frozen_string_literal: true + +require 'jwt' +require 'net/http' + +class Auth0Client + + # Auth0 Client Objects + Error = Struct.new(:message, :status) + Response = Struct.new(:decoded_token, :error) + + # Helper Functions + def self.domain_url + "https://#{Rails.configuration.auth0.domain}/" + end + + def self.decode_token(token, jwks_hash) + JWT.decode(token, nil, true, { + algorithm: 'RS256', + iss: domain_url, + verify_iss: true, + aud: Rails.configuration.auth0.audience, + verify_aud: true, + jwks: { keys: jwks_hash[:keys] } + }) + end + + def self.get_jwks + jwks_uri = URI("#{domain_url}.well-known/jwks.json") + Net::HTTP.get_response jwks_uri + end + + # Token Validation + def self.validate_token(token) + jwks_response = get_jwks + + unless jwks_response.is_a? Net::HTTPSuccess + error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error) + return Response.new(nil, error) + end + + jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys + + decoded_token = decode_token(token, jwks_hash) + + Response.new(decoded_token, nil) + rescue JWT::VerificationError, JWT::DecodeError => e + error = Error.new('Bad credentials', :unauthorized) + Response.new(nil, error) + end +end +``` + +### Define a Secured concern + +Create a Concern called `Secured` which looks for the access token in the `Authorization` header of an incoming request. If the token is present, it should be passed to `Auth0Client.validate_token`. + +```rb +# app/controllers/concerns/secured.rb + +# frozen_string_literal: true + +module Secured + extend ActiveSupport::Concern + + REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze + BAD_CREDENTIALS = { + message: 'Bad credentials' + }.freeze + MALFORMED_AUTHORIZATION_HEADER = { + error: 'invalid_request', + error_description: 'Authorization header value must follow this format: Bearer access-token', + message: 'Bad credentials' + }.freeze + + def authorize + token = token_from_request + + return if performed? + + validation_response = Auth0Client.validate_token(token) + + return unless (error = validation_response.error) + + render json: { message: error.message }, status: error.status + end + + private + + def token_from_request + authorization_header_elements = request.headers['Authorization']&.split + + render json: REQUIRES_AUTHENTICATION, status: :unauthorized and return unless authorization_header_elements + + unless authorization_header_elements.length == 2 + render json: MALFORMED_AUTHORIZATION_HEADER, status: :unauthorized and return + end + + scheme, token = authorization_header_elements + + render json: BAD_CREDENTIALS, status: :unauthorized and return unless scheme.downcase == 'bearer' + + token + end +end +``` + +### Validate scopes + +The `Auth0Client.validate_token` method above verifies that the access token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources. + +To look for a particular `scope` in an access token, create a new struct in your `Auth0Client` class called `Token` and define a new method inside, `validate_permissions`, that given an array of required scopes it will check if they are present in the payload of the token. + +Go to the `Auth0Client` class. Add the new `Token` struct and update the return value of the `validate_token` method as follows: + +```ruby +# app/lib/auth0_client.rb + +# frozen_string_literal: true + +require 'jwt' +require 'net/http' + +class Auth0Client + + # Auth0 Client Objects + Error = Struct.new(:message, :status) + Response = Struct.new(:decoded_token, :error) + + Token = Struct.new(:token) do + def validate_permissions(permissions) + required_permissions = Set.new permissions + scopes = token[0]['scope'] + token_permissions = scopes.present? ? Set.new(scopes.split(" ")) : Set.new + required_permissions <= token_permissions + end + end + + # ... + + # Token Validation + def self.validate_token(token) + jwks_response = get_jwks + + unless jwks_response.is_a? Net::HTTPSuccess + error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error) + return Response.new(nil, error) + end + + jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys + + decoded_token = decode_token(token, jwks_hash) + + Response.new(Token.new(decoded_token), nil) + rescue JWT::VerificationError, JWT::DecodeError => e + error = Error.new('Bad credentials', :unauthorized) + Response.new(nil, error) + end +end +``` + +Next, in the `Secured` concern, define a new error constant `INSUFFICIENT_PERMISSIONS` to return a proper error message in case there was a attempt to request a resource without the right permissions. Next, update the return value of the `Auth0Client.validate_token` call and finally create a new method `validate_permissions` where to check if the token has the right permissions, or return a `403 FORBIDDEN` status code with the `INSUFFICIENT_PERMISSIONS` error message otherwise. + +Apply these changes in your `Secured` concern by adding the following code: + +```rb +# app/controllers/concerns/secured.rb + +# frozen_string_literal: true + +module Secured + extend ActiveSupport::Concern + + # ... + + INSUFFICIENT_PERMISSIONS = { + error: 'insufficient_permissions', + error_description: 'The access token does not contain the required permissions', + message: 'Permission denied' + }.freeze + + def authorize + token = token_from_request + + return if performed? + + validation_response = Auth0Client.validate_token(token) + + @decoded_token = validation_response.decoded_token # Add this line + + return unless (error = validation_response.error) + + render json: { message: error.message }, status: error.status + end + + def validate_permissions(permissions) + raise 'validate_permissions needs to be called with a block' unless block_given? + return yield if @decoded_token.validate_permissions(permissions) + + render json: INSUFFICIENT_PERMISSIONS, status: :forbidden + end + + private + # ... +end +``` + +## Protect API Endpoints + +<%= include('../_includes/_api_endpoints') %> + +Add the `Secured` concern to the `ApplicationController`: + +```ruby +class ApplicationController < ActionController::API + include Secured +end +``` + +You only ned to protect the `PrivateController` as follows: + +```ruby +class PrivateController < ApplicationController + before_action :authorize + + # ... +end +``` + +In order to check that your access token has the right permissions, call the `validate_permissions` method as follows in the `private-scoped` action: + +```ruby +class PrivateController < ApplicationController + before_action :authorize + + def private + render json: { message: 'Hello from a private endpoint! You need to be authenticated to see this.' } + end + + def private_scoped + validate_permissions ['read:messages'] do + render json: { message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' } + end + end +end +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/rails/02-using.md b/fr-ca/articles/quickstart/backend/rails/02-using.md new file mode 100644 index 0000000000..ea41ac4cc4 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - rails +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> diff --git a/fr-ca/articles/quickstart/backend/rails/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/rails/03-troubleshooting.md new file mode 100644 index 0000000000..1190a67ac8 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/03-troubleshooting.md @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT validator configuration +description: This document will help you troubleshoot your configuration if you get unexpected responses from your API. +budicon: 500 +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_troubleshooting') %> diff --git a/fr-ca/articles/quickstart/backend/rails/download.md b/fr-ca/articles/quickstart/backend/rails/download.md new file mode 100644 index 0000000000..e7fdcab9ad --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/download.md @@ -0,0 +1,15 @@ +To run it from the command line: + +```bash +bundle install +rails s --port 3010 +``` + +The sample includes a [Docker](https://www.docker.com) image ready to run with the following command: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/rails/files/application_controller.md b/fr-ca/articles/quickstart/backend/rails/files/application_controller.md new file mode 100644 index 0000000000..6b31483dfc --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/files/application_controller.md @@ -0,0 +1,14 @@ +--- +name: app/controllers/application_controller.rb +language: ruby +--- + + + +```ruby +# frozen_string_literal: true + +class ApplicationController < ActionController::API + include Secured +end +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/rails/files/auth0_client.md b/fr-ca/articles/quickstart/backend/rails/files/auth0_client.md new file mode 100644 index 0000000000..a57b2c9b36 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/files/auth0_client.md @@ -0,0 +1,68 @@ +--- +name: app/lib/auth0_client.rb +language: ruby +--- + + + +```ruby +# frozen_string_literal: true + +require 'jwt' +require 'net/http' + +# Auth0Client class to handle JWT token validation +class Auth0Client + # Auth0 Client Objects + Error = Struct.new(:message, :status) + Response = Struct.new(:decoded_token, :error) + Token = Struct.new(:token) do + def validate_permissions(permissions) + required_permissions = Set.new permissions + scopes = token[0]['scope'] + token_permissions = scopes.present? ? Set.new(scopes.split(" ")) : Set.new + required_permissions <= token_permissions + end + end + + # Helper Functions + def self.domain_url + "https://#{Rails.configuration.auth0.domain}/" + end + + def self.decode_token(token, jwks_hash) + JWT.decode(token, nil, true, { + algorithm: 'RS256', + iss: domain_url, + verify_iss: true, + aud: Rails.configuration.auth0.audience, + verify_aud: true, + jwks: { keys: jwks_hash[:keys] } + }) + end + + def self.get_jwks + jwks_uri = URI("#{domain_url}.well-known/jwks.json") + Net::HTTP.get_response jwks_uri + end + + # Token Validation + def self.validate_token(token) + jwks_response = get_jwks + + unless jwks_response.is_a? Net::HTTPSuccess + error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error) + return Response.new(nil, error) + end + + jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys + + decoded_token = decode_token(token, jwks_hash) + + Response.new(Token.new(decoded_token), nil) + rescue JWT::VerificationError, JWT::DecodeError => e + error = Error.new('Bad credentials', :unauthorized) + Response.new(nil, error) + end +end +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/rails/files/private.md b/fr-ca/articles/quickstart/backend/rails/files/private.md new file mode 100644 index 0000000000..65d1d14f24 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/files/private.md @@ -0,0 +1,23 @@ +--- +name: app/controllers/private_controller.rb +language: ruby +--- + + + +```rb +# frozen_string_literal: true +class PrivateController < ApplicationController + before_action :authorize + + def private + render json: { message: 'Hello from a private endpoint! You need to be authenticated to see this.' } + end + + def private_scoped + validate_permissions ['read:messages'] do + render json: { message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' } + end + end +end +``` diff --git a/fr-ca/articles/quickstart/backend/rails/files/public.md b/fr-ca/articles/quickstart/backend/rails/files/public.md new file mode 100644 index 0000000000..841a3118a1 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/files/public.md @@ -0,0 +1,15 @@ +--- +name: app/controllers/public_controller.rb +language: ruby +--- + + + +```rb +# frozen_string_literal: true +class PublicController < ApplicationController + def public + render json: { message: 'All good. You don\'t need to be authenticated to call this.' } + end +end +``` diff --git a/fr-ca/articles/quickstart/backend/rails/files/secured.md b/fr-ca/articles/quickstart/backend/rails/files/secured.md new file mode 100644 index 0000000000..b89e6bc2a0 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/files/secured.md @@ -0,0 +1,69 @@ +--- +name: app/controllers/concerns/secured.rb +language: ruby +--- + + + +```rb +# frozen_string_literal: true + +module Secured + extend ActiveSupport::Concern + + REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze + BAD_CREDENTIALS = { + message: 'Bad credentials' + }.freeze + MALFORMED_AUTHORIZATION_HEADER = { + error: 'invalid_request', + error_description: 'Authorization header value must follow this format: Bearer access-token', + message: 'Bad credentials' + }.freeze + INSUFFICIENT_PERMISSIONS = { + error: 'insufficient_permissions', + error_description: 'The access token does not contain the required permissions', + message: 'Permission denied' + }.freeze + + def authorize + token = token_from_request + + return if performed? + + validation_response = Auth0Client.validate_token(token) + + @decoded_token = validation_response.decoded_token + + return unless (error = validation_response.error) + + render json: { message: error.message }, status: error.status + end + + def validate_permissions(permissions) + raise 'validate_permissions needs to be called with a block' unless block_given? + return yield if @decoded_token.validate_permissions(permissions) + + render json: INSUFFICIENT_PERMISSIONS, status: :forbidden + end + + private + + def token_from_request + authorization_header_elements = request.headers['Authorization']&.split + + render json: REQUIRES_AUTHENTICATION, status: :unauthorized and return unless authorization_header_elements + + unless authorization_header_elements.length == 2 + render json: MALFORMED_AUTHORIZATION_HEADER, + status: :unauthorized and return + end + + scheme, token = authorization_header_elements + + render json: BAD_CREDENTIALS, status: :unauthorized and return unless scheme.downcase == 'bearer' + + token + end +end +``` diff --git a/fr-ca/articles/quickstart/backend/rails/index.yml b/fr-ca/articles/quickstart/backend/rails/index.yml new file mode 100644 index 0000000000..0c802dd929 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/index.yml @@ -0,0 +1,57 @@ +title: Ruby On Rails API +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/rails.png +logo: rails +alias: + - rails + - ror +languages: + - Ruby +framework: + - Ruby on Rails +author: + name: Josh Cunningham + email: josh.cunningham@auth0.com + community: false +thirdParty: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: server-apis/rails/dependencies + setup: server-apis/rails/setup + use: server-apis/rails/use +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +default_article: 01-authorization +show_steps: true +github: + org: auth0-samples + repo: auth0-rubyonrails-api-samples +sdk: + name: omniauth-auth0 + url: https://github.com/auth0/omniauth-auth0 + logo: rails +requirements: + - Ruby 2.1.8 + - Rails 4.2.5 +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/backend/rails/interactive.md b/fr-ca/articles/quickstart/backend/rails/interactive.md new file mode 100644 index 0000000000..4a0af13b65 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/rails/interactive.md @@ -0,0 +1,96 @@ +--- +title: Add authorization to a Ruby on Rails API +description: This tutorial demonstrates how to add authorization to a Ruby on Rails API. +topics: + - quickstart + - backend + - rails +github: + path: 01-Authentication-RS256 +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/application_controller + - files/auth0_client + - files/secured + - files/public + - files/private +--- + + +# Add Authorization to Your Ruby on Rails API +This tutorial performs access token validation using the **[jwt](https://github.com/jwt/ruby-jwt)** Gem within a custom `Auth0Client` class. A Concern called `Secured` is used to authorize endpoints which require authentication through an incoming access token. + +If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API for your project. + +To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis). + +Each Auth0 API uses the API Identifier, which your application needs to validate the access token. + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + +## Install dependencies +Install the **jwt** Gem. + +```bash +gem 'jwt' +bundle install +``` + +## Create an Auth0Client class {{{ data-action=code data-code="app/lib/auth0_client.rb" }}} + +Create a class called `Auth0Client`. This class decodes and verifies the incoming access token taken from the `Authorization` header of the request. + +The `Auth0Client` class retrieves the public key for your Auth0 tenant and then uses it to verify the signature of the access token. The `Token` struct defines a `validate_permissions` method to look for a particular `scope` in an access token by providing an array of required scopes and check if they are present in the payload of the token. + +## Define a Secured concern {{{ data-action=code data-code="app/controllers/concerns/secured.rb" }}} + +Create a Concern called `Secured` which looks for the access token in the `Authorization` header of an incoming request. + +If the token is present, the `Auth0Client.validate_token` will use the `jwt` Gem to verify the token's signature and validate the token's claims. + +In addition to verifying that the access token is valid, the Concern also includes a mechanism for confirming the token has the sufficient **scope** to access the requested resources. In this example we define a `validate_permissions` method that receives a block and checks the permissions by calling the `Token.validate_permissions` method from the `Auth0Client` class. + +For the `/private-scoped` route, the scopes defined will be intersected with the scopes coming in the payload, to determine if it contains one or more items from the other array. + +## Include the Secure concern in your ApplicationController {{{ data-action=code data-code="app/controllers/application_controller.rb" }}} + +By adding the `Secure` concern to your application controller, you'll only need to use a `before_action` filter in the controller that requires authorization. + +## Create the public endpoint {{{ data-action=code data-code="app/controllers/public_controller.rb" }}} + +Create a controller to handle the public endpoint `/api/public`. + +The `/public` endpoint does not require any authorization so no `before_action` is needed. + +## Create the private endpoints {{{ data-action=code data-code="app/controllers/private_controller.rb" }}} + +Create a controller to handle the private endpoints: `/api/private` and `/api/private-scoped`. + +`/api/private` is available for authenticated requests containing an access token with no additional scopes. + +`/api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope granted + +The protected endpoints need to call the `authorize` method from the `Secured` concern, for that you use `before_action :authorize`, this ensure the `Secured.authorize` method is called before every action in the `PrivateController`. + +<%= include('../_includes/_call_api') %> + +::::checkpoint +:::checkpoint-default +Now that you have configured your application, run your application to verify that: +* `GET /api/public` is available for non-authenticated requests. +* `GET /api/private` is available for authenticated requests. +* `GET /api/private-scoped` is available for authenticated requests containing an Access Token with the `read:messages` scope. +::: + +:::checkpoint-failure +If your application did not start successfully: +* Verify you added the token as the `Authorization` header +* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/). + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/01-authorization.md b/fr-ca/articles/quickstart/backend/webapi-owin/01-authorization.md new file mode 100644 index 0000000000..364e547522 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/01-authorization.md @@ -0,0 +1,196 @@ +--- +title: Authorization +description: This tutorial demonstrates how to add authorization to an ASP.NET OWIN API using the standard JWT middleware. +budicon: 500 +topics: + - quickstart + - backend + - webapi-owin +github: + path: Quickstart/Sample +contentType: tutorial +useCase: quickstart +--- + +<%= include('../../../_includes/_api_auth_intro') %> + +<%= include('../_includes/_api_create_new') %> + +<%= include('../_includes/_api_auth_preamble') %> + +## Configure the Sample Project + +The sample code has an `appsettings` section in `Web.config` which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page it will be automatically filled. If you use the example from Github, you will need to fill it yourself. + +```xml +// web.config + + + + + +``` + +## Validate Access Tokens + +### Install dependencies + +To use Auth0 Access Tokens with ASP.NET you will use the OWIN JWT Middleware which is available in the `Microsoft.Owin.Security.Jwt` NuGet package. + +```bash +Install-Package Microsoft.Owin.Security.Jwt +``` + +### Verifying the token signature +As the OWIN JWT middleware doesn't use Open ID Connect Discovery by default, you will need to provide a custom `IssuerSigningKeyResolver`. To do this, add the following to the `Support/OpenIdConnectSigningKeyResolver.cs` file: + +:::note +Such a custom resolver was previously published as part of the `Auth0.OpenIdConnectSigningKeyResolver` package through Nuget. As [this package is not available anymore](https://github.com/auth0/auth0-aspnet-owin/blob/master/SECURITY-NOTICE.md), you will need to provide this yourself. +::: + +```javascript +public class OpenIdConnectSigningKeyResolver +{ + private readonly OpenIdConnectConfiguration openIdConfig; + + public OpenIdConnectSigningKeyResolver(string authority) + { + var cm = new ConfigurationManager($"{authority.TrimEnd('/')}/.well-known/openid-configuration", new OpenIdConnectConfigurationRetriever()); + openIdConfig = AsyncHelper.RunSync(async () => await cm.GetConfigurationAsync()); + } + + public SecurityKey[] GetSigningKey(string kid) + { + return new[] { openIdConfig.JsonWebKeySet.GetSigningKeys().FirstOrDefault(t => t.KeyId == kid) }; + } +} +``` + +The `OpenIdConnectSigningKeyResolver` will automatically download the JSON Web Key Set used to sign the RS256 tokens from the OpenID Connect Configuration endpoint (at `/.well-known/openid-configuration`). You can then use it subsequently to resolve the Issuer Signing Key, as will be demonstrated in the JWT registration code below. + +### Configuration + +Go to the `Configuration` method of your `Startup` class and add a call to `UseJwtBearerAuthentication` passing in the configured `JwtBearerAuthenticationOptions`. + +The `JwtBearerAuthenticationOptions` needs to specify your Auth0 API Identifier in the `ValidAudience` property, and the full path to your Auth0 domain as the `ValidIssuer`. You will need to configure the `IssuerSigningKeyResolver` to use the instance of `OpenIdConnectSigningKeyResolver` to resolve the signing key: + +```csharp +// Startup.cs + +public void Configuration(IAppBuilder app) +{ + var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/"; + var apiIdentifier = ConfigurationManager.AppSettings["Auth0ApiIdentifier"]; + var keyResolver = new OpenIdConnectSigningKeyResolver(domain); + + app.UseJwtBearerAuthentication( + new JwtBearerAuthenticationOptions + { + AuthenticationMode = AuthenticationMode.Active, + TokenValidationParameters = new TokenValidationParameters() + { + ValidAudience = apiIdentifier, + ValidIssuer = domain, + IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid) + } + }); + + // Configure Web API + WebApiConfig.Configure(app); +} +``` + +::: panel-warning Do not forget the trailing backslash +Please ensure that the URL specified for `ValidIssuer` contains a trailing backslash as this needs to match exactly with the issuer claim of the JWT. This is a common misconfiguration error which will cause your API calls to not be authenticated correctly. +::: + +### Validate scopes + +The JWT middleware above verifies that the Access Token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources. + +Create a class called `ScopeAuthorizeAttribute` which inherits from `System.Web.Http.AuthorizeAttribute`. This Authorization Attribute will check that the `scope` claim issued by your Auth0 tenant is present, and if so it will ensure that the `scope` claim contains the requested scope. + +```csharp +// Controllers/ScopeAuthorizeAttribute.cs + +public class ScopeAuthorizeAttribute : AuthorizeAttribute +{ + private readonly string scope; + + public ScopeAuthorizeAttribute(string scope) + { + this.scope = scope; + } + + public override void OnAuthorization(HttpActionContext actionContext) + { + base.OnAuthorization(actionContext); + + // Get the Auth0 domain, in order to validate the issuer + var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/"; + + // Get the claim principal + ClaimsPrincipal principal = actionContext.ControllerContext.RequestContext.Principal as ClaimsPrincipal; + + // Get the scope claim. Ensure that the issuer is for the correct Auth0 domain + var scopeClaim = principal?.Claims.FirstOrDefault(c => c.Type == "scope" && c.Issuer == domain); + if (scopeClaim != null) + { + // Split scopes + var scopes = scopeClaim.Value.Split(' '); + + // Succeed if the scope array contains the required scope + if (scopes.Any(s => s == scope)) + return; + } + + HandleUnauthorizedRequest(actionContext); + } +} +``` + +## Protect API Endpoints + +<%= include('../_includes/_api_endpoints') %> + +The JWT middleware integrates with the standard ASP.NET Authentication and Authorization mechanisms, so you only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint. + +```csharp +// Controllers/ApiController.cs + +[RoutePrefix("api")] +public class ApiController : ApiController +{ + [HttpGet] + [Route("private")] + [Authorize] + public IHttpActionResult Private() + { + return Json(new + { + Message = "Hello from a private endpoint! You need to be authenticated to see this." + }); + } +} +``` + +To ensure that a scope is present in order to call a particular API endpoint, you simply need to decorate the action with the `ScopeAuthorize` attribute and pass the name of the required `scope` in the `scope` parameter. + +```csharp +// Controllers/ApiController.cs + +[RoutePrefix("api")] +public class ApiController : ApiController +{ + [HttpGet] + [Route("private-scoped")] + [ScopeAuthorize("read:messages")] + public IHttpActionResult Scoped() + { + return Json(new + { + Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this." + }); + } +} +``` diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/02-using.md b/fr-ca/articles/quickstart/backend/webapi-owin/02-using.md new file mode 100644 index 0000000000..2c15aa3d87 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/02-using.md @@ -0,0 +1,13 @@ +--- +title: Using your API +description: This tutorial will show you how to use your API. +budicon: 500 +topics: + - quickstart + - backend + - webapi-owin +contentType: tutorial +useCase: quickstart +--- + +<%= include('../_includes/_api_using') %> \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/03-troubleshooting.md b/fr-ca/articles/quickstart/backend/webapi-owin/03-troubleshooting.md new file mode 100644 index 0000000000..329b9ef37e --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/03-troubleshooting.md @@ -0,0 +1,177 @@ +--- +title: Troubleshooting +name: Shows how to troubleshoot the JWT middleware configuration +description: This document will help you troubleshoot your configuration if you get a 401 (Unauthorized) response from your API. +budicon: 500 +topics: + - quickstart + - backend + - webapi-owin +contentType: tutorial +useCase: quickstart +--- + +If you configured the JWT middleware correctly, you will be able to get proper responses from your API when you make requests. However, in the case where you get a 401 (Unauthorized) response from your API, it is because the configuration of your JWT middleware does not match with the JWT which was passed. + +This document will help you troubleshoot your JWT middleware configuration. + +## How does a token get validated? + +In terms of validating a JWT, there are various things to consider: + +1. **Is the token well-formed?** In other words, is this token conforming to the structure of a JSON Web Token (JWT)? To get more information on the structure of a JWT, please refer to [this section on the structure of a JWT](/jwt#what-is-the-json-web-token-structure-) + +2. **Has the token been tampered with?** The last part of a JWT is the signature. The signature is used to verify that the token was in fact signed by the sender and not altered in any way. + +3. **Has the token been received in its validity period?** JWTs are only valid for a specified time period (as expressed in the `exp` claim). + +4. **Is the token coming from the intended Authority?** This consists of 2 parts + + * **Signature Verification**: Can we confirm that the JWT is correctly signed using the key issued by the issuing authority? + + * **Issuer Value**: The Issuer is defined in the `iss` claim. Once again does this claim match up with what your application expects? + +5. **Is the token intended for the current application?** So does the `aud` claim of the JWT match with what your application is expecting? + +## Inspecting a token + +A quick way to inspect a JWT is by using the [JWT.io](https://jwt.io/) website. It has a handy debugger which allows you to quickly check that a JWT is well-formed, and also inspect the values of the various claims. + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png) + +In the screenshot above you can see that the token was signed using the **RS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://quickstarts/api**. + +So in other words these values in your JWT middleware registration must match **exactly** - including the trailing slash for the Issuer, such as + +```csharp +var keyResolver = new OpenIdConnectSigningKeyResolver("https://jerrie.auth0.com/"); +app.UseJwtBearerAuthentication( + new JwtBearerAuthenticationOptions + { + AuthenticationMode = AuthenticationMode.Active, + TokenValidationParameters = new TokenValidationParameters() + { + ValidAudience = "https://quickstarts/api", + ValidIssuer = "https://jerrie.auth0.com/", + IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid) + } + }); +``` + +For a token signed using HS256, the debugger view will look a little different: + +![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png) + +In the screenshot above you can see that the token was signed using the **HS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://quickstarts/api/hs256**. + +In this case, the middleware needs to be configured as follows: + +```csharp +app.UseJwtBearerAuthentication( + new JwtBearerAuthenticationOptions + { + AuthenticationMode = AuthenticationMode.Active, + AllowedAudiences = new[] { "https://quickstarts/api/hs256" }, + IssuerSecurityKeyProviders = new IIssuerSecurityKeyProvider[] + { + new SymmetricKeyIssuerSecurityKeyProvider("https://jerrie.auth0.com/", + Encoding.UTF8.GetBytes("your api secret")) + } + }); +``` + +## Using the log files to debug configuration issues + +In order to inspect the log message which are generated by the OWIN middleware, you need to set the logging level to Verbose. So in your `web.config` file, add the following: + +```xml + + + + + +``` + +This will log all OWIN log messages to the Output window in Visual Studio when running your application in Debug Mode. + +### 1. Are you actually passing the JWT in the Authorization header? + +The first thing is to ensure that you actually pass along the JWT as a Bearer token in the Authorization header of the request. If you get a 401 (Unauthorized) response from your Web API, but you do not see any other error messages being logged to the Output Window, then most likely you are simply not sending the JWT in the Authorization header of the request. + +To resolve this issue, ensure that you send the JWT as a bearer token in the Authorization header. + +## 2. Did you configure the JWT middleware for the correct signing algorithm? + +Another common mistake is that your tokens are signed using the HS256 [signing algorithm](/tokens/concepts/signing-algorithms), but your middleware is configured for RS256 - or vice versa. + +In the following screenshot, you can see that we get an error message that the signature validation failed. This is because the JWT middleware was configured to handle tokens signed using RS256, but instead, a token was sent which was signed using HS256. + +![Wrong Signature Configured](/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-rs256.png) + +The relevant error message to look for is the following: + +```text +IDX10503: Signature validation failed. Keys tried: 'null'. +``` + +In the case where you configured your middleware for HS256, but you are sending an RS256 signed token the error message will be different: + +![Wrong Signature Configured](/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-hs256.png) + +In this case, the relevant error message to look for is the following: + +```text +IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier... +``` + +To resolve this issue, be sure that the signature algorithm with which the JWT was signed matches how your middleware is configured. + +## 3. Has your token expired? + +Each JSON Web Token is only valid until the time specified in the `exp` claim. If you and send a token which has expired, the token will be rejected: + +![Token Expired](/media/articles/server-apis/webapi-owin/troubleshoot-token-expired.png) + +The error message to look for is the following: + +```text +Expired bearer token received +``` + +The resolve this issue, be sure to send a token which has not expired. + +::: panel exp + The value of the `exp` claim is a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time. If you want to see the actual date/time for the value, you can visit EpochConverter. +::: + +## 4. Did you configure the correct Issuer? + +The Issuer specified in your token must match exactly with what is configured in your JWT middleware. + +![Issuer Validation Failed](/media/articles/server-apis/webapi-owin/troubleshoot-issuer-validation-failed.png) + +The error message to look for is the following: + +```text +IDX10205: Issuer validation failed. +``` + +The resolve this issue, ensure that you specify the correct issuer for your JWT middleware. If your middleware is configured for RS256 signed tokens, this means ensuring that you have specified the correct value for the `TokenValidationParameters.ValidIssuer` property of the `JwtBearerAuthenticationOptions` parameter passed when calling `app.UseJwtBearerAuthentication(...)`. + +If your middleware is configured for HS256 signed tokens, this means ensuring that you have passed the correct value to the constructor of `SymmetricKeyIssuerSecurityTokenProvider` which was configured as one of the `IssuerSecurityTokenProviders` for the `JwtBearerAuthenticationOptions`. + +## 5. Does the audience match? + +The audience specified in your token must match exactly with what is configured in your JWT middleware. + +![Audience Validation Failed](/media/articles/server-apis/webapi-owin/troubleshoot-audience-validation-failed.png) + +The error message to look for is the following: + +```text +IDX10214: Audience validation failed. +``` + +The resolve this issue, ensure that you specify the correct audience for your JWT middleware. If your middleware is configured for RS256 signed tokens, this means ensuring that you have specified the correct value for the `ValidAudience` property of the `TokenValidationParameters` + +If your middleware is configured for HS256 signed tokens, this means ensuring that you have added the correct audience to the list of `AllowedAudiences` for the `JwtBearerAuthenticationOptions`. diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/download.md b/fr-ca/articles/quickstart/backend/webapi-owin/download.md new file mode 100644 index 0000000000..453a159648 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/download.md @@ -0,0 +1,3 @@ +To run the sample, open the solution in [Visual Studio](https://visualstudio.microsoft.com/vs/). + +Click the `Start` button or select the menu option `Debug | Start Debugging` or use the keyboard shortcut `F5`. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/api-controller.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/api-controller.md new file mode 100644 index 0000000000..9c04dd06e5 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/api-controller.md @@ -0,0 +1,42 @@ +--- +name: ApiController.cs +language: csharp +--- + +```csharp +[RoutePrefix("api")] +public class ApiController : ApiController +{ + [HttpGet] + [Route("public")] + public IHttpActionResult Public() + { + return Json(new + { + Message = "Hello from a public endpoint!" + }); + } + + [HttpGet] + [Route("private")] + [Authorize] + public IHttpActionResult Private() + { + return Json(new + { + Message = "Hello from a private endpoint! You need to be authenticated to see this." + }); + } + + [HttpGet] + [Route("private-scoped")] + [ScopeAuthorize("read:messages")] + public IHttpActionResult Scoped() + { + return Json(new + { + Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this." + }); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md new file mode 100644 index 0000000000..a1aaee90b9 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md @@ -0,0 +1,22 @@ +--- +name: OpenIdConnectSigningKeyResolver.cs +language: csharp +--- + +```csharp +public class OpenIdConnectSigningKeyResolver +{ + private readonly OpenIdConnectConfiguration openIdConfig; + + public OpenIdConnectSigningKeyResolver(string authority) + { + var cm = new ConfigurationManager($"{authority.TrimEnd('/')}/.well-known/openid-configuration", new OpenIdConnectConfigurationRetriever()); + openIdConfig = AsyncHelper.RunSync(async () => await cm.GetConfigurationAsync()); + } + + public SecurityKey[] GetSigningKey(string kid) + { + return new[] { openIdConfig.JsonWebKeySet.GetSigningKeys().FirstOrDefault(t => t.KeyId == kid) }; + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md new file mode 100644 index 0000000000..ec5670f427 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md @@ -0,0 +1,41 @@ +--- +name: ScopeAuthorizeAttribute.cs +language: csharp +--- + +```csharp +public class ScopeAuthorizeAttribute : AuthorizeAttribute +{ + private readonly string scope; + + public ScopeAuthorizeAttribute(string scope) + { + this.scope = scope; + } + + public override void OnAuthorization(HttpActionContext actionContext) + { + base.OnAuthorization(actionContext); + + // Get the Auth0 domain, in order to validate the issuer + var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/"; + + // Get the claim principal + ClaimsPrincipal principal = actionContext.ControllerContext.RequestContext.Principal as ClaimsPrincipal; + + // Get the scope clain. Ensure that the issuer is for the correcr Auth0 domain + var scopeClaim = principal?.Claims.FirstOrDefault(c => c.Type == "scope" && c.Issuer == domain); + if (scopeClaim != null) + { + // Split scopes + var scopes = scopeClaim.Value.Split(' '); + + // Succeed if the scope array contains the required scope + if (scopes.Any(s => s == scope)) + return; + } + + HandleUnauthorizedRequest(actionContext); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/files/startup.md b/fr-ca/articles/quickstart/backend/webapi-owin/files/startup.md new file mode 100644 index 0000000000..5890cc00fd --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/files/startup.md @@ -0,0 +1,28 @@ +--- +name: Startup.cs +language: csharp +--- + +```csharp +public void Configuration(IAppBuilder app) +{ + var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/"; + var apiIdentifier = ConfigurationManager.AppSettings["Auth0ApiIdentifier"]; + var keyResolver = new OpenIdConnectSigningKeyResolver(domain); + + app.UseJwtBearerAuthentication( + new JwtBearerAuthenticationOptions + { + AuthenticationMode = AuthenticationMode.Active, + TokenValidationParameters = new TokenValidationParameters() + { + ValidAudience = apiIdentifier, + ValidIssuer = domain, + IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid) + } + }); + + // Configure Web API + WebApiConfig.Configure(app); +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/index.yml b/fr-ca/articles/quickstart/backend/webapi-owin/index.yml new file mode 100644 index 0000000000..9980953c84 --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/index.yml @@ -0,0 +1,48 @@ +title: ASP.NET Web API (OWIN) +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/asp.png +logo: dotnet +alias: + - owin +languages: + - C# +thirdParty: false +framework: + - OWIN +author: + name: Damien Guard + email: damien.guard@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +articles: + - 01-authorization + - 02-using + - 03-troubleshooting +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-aspnet-owin-webapi-samples +requirements: + - Microsoft Visual Studio 2015 Update 3 + - System.IdentityModel.Tokens.Jwt NuGet Package v5.2.2 + - Microsoft.Owin.Security.Jwt NuGet Package V4.0.0 +next_steps: + - path: 01-authorization + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" \ No newline at end of file diff --git a/fr-ca/articles/quickstart/backend/webapi-owin/interactive.md b/fr-ca/articles/quickstart/backend/webapi-owin/interactive.md new file mode 100644 index 0000000000..956cd2da2d --- /dev/null +++ b/fr-ca/articles/quickstart/backend/webapi-owin/interactive.md @@ -0,0 +1,98 @@ +--- +title: Add Authorization to an ASP.NET Owin Web API application +description: This tutorial demonstrates how to add authorization to an ASP.NET OWIN API using the standard JWT middleware. +budicon: 448 +topics: + - quickstart + - backend + - webapi-owin +github: + path: Quickstart/Sample +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/startup + - files/openid-connect-signing-key-resolver + - files/scope-authorize-attribute + - files/api-controller +--- + +# Add Authorization to Your ASP.NET Owin Web API Application +Auth0 allows you to add authorization to any kind of application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET Owin Web API application using the `Microsoft.Owin.Security.Jwt` package. + +If you have not created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API for your project. + +To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis). + +Each Auth0 API uses the API Identifier, which your application needs to validate the access token. + + + +<%= include('../../../_includes/_api_auth_intro') %> + +## Define permissions +<%= include('../_includes/_api_scopes_access_resources') %> + + +## Install dependencies + +Install the `Microsoft.Owin.Security.Jwt` NuGetPackage. This package contains the OWIN JWT Middleware necessary to use Auth0 access tokens in the ASP.NET Owin Web API. +```bash +Install-Package Microsoft.Owin.Security.Jwt +``` + +## Configure the middleware {{{ data-action=code data-code="Startup.cs" }}} + +Go to the `Configuration` method of your `Startup` class and add a call to `UseJwtBearerAuthentication` passing in the configured `JwtBearerAuthenticationOptions`. + +The `JwtBearerAuthenticationOptions` needs to specify your Auth0 API Identifier in the `ValidAudience` property, and the full path to your Auth0 domain as the `ValidIssuer`. You will need to configure the `IssuerSigningKeyResolver` to use the instance of `OpenIdConnectSigningKeyResolver` to resolve the signing key: + +::: panel-warning Do not forget the trailing slash +Ensure the URL specified for `ValidIssuer` contains a trailing forward slash (`/`). This must match exactly with the JWT issuer claim. API calls will not authenticate correctly if you misconfigured this value. +::: + +## Verifying the token signature {{{ data-action=code data-code="OpenIdConnectSigningKeyResolver.cs" }}} +The OWIN JWT middleware does not use Open ID Connect Discovery by default, so you must provide a custom `IssuerSigningKeyResolver`. Create the `OpenIdConnectSigningKeyResolver` class and ensure to return the correct `SecurityKey` by implementing `GetSigningKey`. +This class is then used as `TokenValidationParameters.IssuerSigningKeyResolver` while configuring the middleware in `Startup.cs`. + +:::note +This custom resolver is deprecated and [no longer available](https://github.com/auth0/auth0-aspnet-owin/blob/master/SECURITY-NOTICE.md). You must provider this customer resolver yourself. +::: + +## Validate scopes {{{ data-action=code data-code="ScopeAuthorizeAttribute.cs" }}} + +The JWT middleware verifies that the access token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources. + +Create a class called `ScopeAuthorizeAttribute` which inherits from `System.Web.Http.AuthorizeAttribute`. This attribute will check that the `scope` claim issued by your Auth0 tenant is present, and if so it will ensure that the `scope` claim contains the requested scope. + +## Protect API endpoints {{{ data-action=code data-code="ApiController.cs" }}} + +<%= include('../_includes/_api_endpoints') %> + +The JWT middleware integrates with the standard ASP.NET authentication and authorization mechanisms, so you only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint. + +Update the action with the `ScopeAuthorize` attribute and pass the name of the required `scope` in the `scope` parameter. This ensures the correct scope is available to call a specific API endpoing. + +::::checkpoint + +:::checkpoint-default + +Now that you have configured your application, run your application to verify that: +* `GET /api/public` is available for non-authenticated requests. +* `GET /api/private` is available for authenticated requests. +* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope. + +::: + +:::checkpoint-failure +If your application did not start successfully: +* Ensure your configured the `ValidIssuer` and `ValidAudience` values correctly +* Verify you added the token as the `Authorization` header +* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/). + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: + +:::: diff --git a/fr-ca/articles/quickstart/config.yml b/fr-ca/articles/quickstart/config.yml new file mode 100644 index 0000000000..a99856f831 --- /dev/null +++ b/fr-ca/articles/quickstart/config.yml @@ -0,0 +1,4 @@ +author: + name: Auth0 + email: support@auth0.com + community: false diff --git a/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md b/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md new file mode 100644 index 0000000000..ef210437db --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md @@ -0,0 +1,11 @@ +First, you will create a rule that assigns users to either an `admin` role, or a single `user` role. Go to the [New Rule](${manage_url}/#/rules/new) page on the Auth0 dashboard and select the **Set Roles To A User** template, under **Access Control**. + +By default, this rule will assign the user an `admin` role if their email contains `@example.com`. Otherwise, they will be assigned a regular `user` role. + +You can modify this line in the default script to change the domain name to one suitable for your setup: + +`if (user.email.indexOf('@example.com') > -1)` + +::: note +You can set roles other than `admin` and `user` or customize the rule as needed. +::: diff --git a/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md b/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md new file mode 100644 index 0000000000..a96342dad8 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md @@ -0,0 +1,5 @@ +Many identity providers will supply access claims, like roles or groups, with the user. You can request these in the token by setting `scope: openid roles` or `scope: openid groups`. However, not every identity provider supplies this type of information. Fortunately, Auth0 has an alternative, which is to create a rule for assigning different roles to different users. + +::: note +This tutorial assumes that you have already completed the [rules tutorial](${ruleslink}) and that you know how to implement a basic rule in your app. +::: diff --git a/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md b/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md new file mode 100644 index 0000000000..8b41d237de --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md @@ -0,0 +1,9 @@ + + +A callback URL is a URL in your application where Auth0 redirects the user after they have been authenticated. Auth0 adds parameters to the callback URL, including a token. + +Callback URLs can be manipulated by attackers. For security, add your application's URL to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). + +If you do not add your application's URL to the list of Allowed Callback URLs, your users will see a mismatch error when they try to log in. + +![Callback error](/media/articles/angularjs/callback_error.png) \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md new file mode 100644 index 0000000000..755ffb537d --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md @@ -0,0 +1,7 @@ +## Create an Auth0 API + +In the [APIs section](${manage_url}/#/apis) of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API. +You will use the identifier later when you're preparing the Web Authentication. +For **Signing Algorithm**, select **RS256**. + +![Create API](/media/articles/api-auth/create-api.png) diff --git a/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md new file mode 100644 index 0000000000..6ea9af9d0b --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md @@ -0,0 +1,11 @@ +## Add a Scope + +By default, the Access Token does not contain any authorization information. To limit access to your resources based on authorization, you must use scopes. Read more about scopes in the [scopes documentation](/scopes). + +In the Auth0 dashboard, in the [APIs section](${manage_url}/#/apis), click **Scopes**. Add any scopes you need to limit access to your API resources. + +::: note +You can give any names to your scopes. A common pattern is `:`. The example below uses the name `read:messages` for a scope. +::: + +![create scope](/media/articles/api-auth/create-scope.png) diff --git a/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md b/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md new file mode 100644 index 0000000000..2c03b6254d --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md @@ -0,0 +1,30 @@ +To integrate Auth0 in a hybrid Cordova application, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception. + +::: note +Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser. +::: + +<%= include('../../../_includes/_new_app') %> + +<%= include('../../../_includes/_callback_url') %> + +The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app. + +Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box. + +```bash +# replace YOUR_PACKAGE_ID with your app package ID +YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback +``` + +Add `file` as an allowed origin to the **Allowed Origins (CORS)** box. + +```bash +file://* +``` + +Lastly, be sure that the **Application Type** for your application is set to **Native** in its settings. + +${snippet(meta.snippets.dependencies)} + +${snippet(meta.snippets.setup)} \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/_create_application.md b/fr-ca/articles/quickstart/native/_includes/_create_application.md new file mode 100644 index 0000000000..a91678b6e6 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_create_application.md @@ -0,0 +1,3 @@ +## Create an application + +Create a new application in your [Auth0 dashboard](${manage_url}/#/application). For **Type**, select **Native**. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md b/fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md b/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md new file mode 100644 index 0000000000..9a6db5a92e --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md @@ -0,0 +1,62 @@ +## Set up the “Continue with Facebook” button + +This guide will help you add authentication with Auth0 to the application you built in the first step. + +### Request Facebook permissions + +Your application is already able to sign in with Facebook. However, to ensure you have a rich user profile, you need to update the permissions with which the Facebook Login Button was set up. + +${snippet(meta.snippets.facebook_button_permissions)} + +Now, to kick off the authentication process with Auth0, create a new method in which you will prepare the payload to be sent. + +${snippet(meta.snippets.facebook_button_config)} + +## Integrate Facebook + +When you sign in with Facebook at Auth0, the backend will perform some checks in the background to ensure the user is who they say they are. To achieve this, it needs to be provided with a Session Access Token. + +Furthermore, if a user needs to be created on Auth0 to represent this Facebook user, the backend will require some of their information, such as their name, last name, and email. The email, if provided, will be **flagged as non-verified** on the Auth0 user profile. + +To obtain the Session Access Token and the user profile, two additional requests need to be made against the Facebook API. + +### Fetch Facebook session Access Token + +Make a new GET request against the Facebook API's `/oauth/access_token` endpoint. +Use the following query parameters: +- `grant_type`: `fb_attenuate_token`. +- `fb_exchange_token`: the access token received upon login. +- `client_id`: your App ID. This value comes from the Facebook Developer's dashboard and should already be in use in your application if you have integrated Facebook Login successfully. + +Put the logic from this step in its own method. You will be calling it later from the previously-added method. + +${snippet(meta.snippets.facebook_fetch_session_token)} + +### Fetch Facebook user profile + +Now make another GET request, just like in the step above. The endpoint path will be the User ID value from the Facebook login result (for example, `/904636746222815`). +Use the following parameters: +- `access_token`: the access token received upon login. +- `fields`: the fields from the user profile that you'd like to get back in the response. These are directly tied to the Facebook Login Button permissions that were configured at the beginning. When a permission is optional, the user must first consent to give access to it. For the purpose of signing up a user at Auth0, their full name and email will suffice. + +${snippet(meta.snippets.facebook_fetch_profile)} + +## Integrate Auth0 + +Now that the required artifacts have been obtained, you are ready to trade them for Auth0 user credentials, such as the ID and Access Tokens. But first, you must set up the Auth0 SDK to make that last request. + +### Get your application keys + +Go to the **Applications** section of the [Auth0 Dashboard](https://manage.auth0.com/) and select the existing application in which you enabled **Sign in with Facebook**. If you need help with this step, please check the requirements section at the top of this article. + +Copy the **Domain** and **Client ID** values from the application settings page. These are required by the SDK. + +${snippet(meta.snippets.facebook_app_credentials)} + +### Install the Auth0 SDK + +${snippet(meta.snippets.facebook_install_auth0_sdk)} + +### Exchange the received data for Auth0 tokens + +${snippet(meta.snippets.facebook_token_exchange)} diff --git a/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md b/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md new file mode 100644 index 0000000000..ae286d7f70 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md @@ -0,0 +1,6 @@ +This tutorial describes how to implement login with the [Facebook SDK](https://developers.facebook.com/docs/). +​ +## Before You Start +​ +- Install and configure the [Facebook Login SDK](https://developers.facebook.com/docs/facebook-login/). You’ll also go through the process of creating a Facebook app in [https://developers.facebook.com](https://developers.facebook.com). **When you finish this step, you should have a mobile app running with Facebook Login integrated.** +- Configure your Auth0 application in the dashboard to use Facebook Native Sign In. See [Add Facebook Login to Native Apps](/connections/nativesocial/facebook). **When you finish this step, your application will be able to implement Facebook Native Login.** diff --git a/fr-ca/articles/quickstart/native/_includes/_getting_started.md b/fr-ca/articles/quickstart/native/_includes/_getting_started.md new file mode 100644 index 0000000000..23cbcdbe4f --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_getting_started.md @@ -0,0 +1,7 @@ +::: note +**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Native Applications](/architecture-scenarios/application/mobile-api) and which [protocol](/api-auth/grant/authorization-code-pkce) it uses. +::: + +<%= include('../../../_includes/_new_app') %> + + diff --git a/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md b/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md new file mode 100644 index 0000000000..9638a40d51 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md @@ -0,0 +1,57 @@ +To integrate Auth0 in a hybrid Ionic app, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception. + +::: note +Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser. +::: + +<%= include('../../../_includes/_new_app') %> + +<%= include('../../../_includes/_callback_url') %> + +The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app. + +Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box. + +```bash +# replace YOUR_PACKAGE_ID with your app package ID +YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback +``` + +Add `file` as an allowed origin to the **Allowed Origins (CORS)** box. + +```bash +file://* +``` + +Lastly, be sure that the **Application Type** for your application is set to **Native** in the application settings. + +## Install the Dependencies + +The required dependencies for using Auth0 in an Ionic application are **auth0.js** and **auth0-cordova**. Install them with npm or yarn. + +```bash +# installation with npm +npm install auth0-js @auth0/cordova --save + +# installation with yarn +yarn add auth0-js @auth0/cordova +``` + +## Add Cordova Plugins + +You must install the `SafariViewController` plugin from Cordova to be able to use Universal Login. The downloadable sample project already has this plugin added, but if you are embedding Auth0 in your own application, install the plugin via the command line. + +```bash +ionic cordova plugin add cordova-plugin-safariviewcontroller +``` + +The `CustomURLScheme` plugin from Cordova is also required to handle redirects properly. The sample project has it already, but if you're adding Auth0 to your own project, install this plugin as well. + +```bash +# replace YOUR_PACKAGE_ID with your app identifier +ionic cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_HOST=${account.namespace} --variable ANDROID_PATHPREFIX=/cordova/{YOUR_PACKAGE_ID}/callback +``` + +## Modify config.xml + +Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app. diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_config.md b/fr-ca/articles/quickstart/native/_includes/_ios_config.md new file mode 100644 index 0000000000..d5e5a479a9 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_ios_config.md @@ -0,0 +1,62 @@ + + +## Add Auth0 Credentials + +You will need some details about this application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 dashboard. + +You need the following information: +* **Client ID** +* **Domain** + +::: note +If you download the sample from the top of this page, these details are filled out for you. +::: + +Add your credentials in `Auth0.plist`. If the file does not exist in your project yet, create one with the information below ([Apple documentation on Property List Files](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)): + +```xml + + + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` + +<%= include('../../../_includes/_callback_url') %> + +In your application's `Info.plist` file, register your iOS Bundle identifier as a custom scheme: + +```xml + + +CFBundleURLTypes + + + CFBundleTypeRole + None + CFBundleURLName + auth0 + CFBundleURLSchemes + + $(PRODUCT_BUNDLE_IDENTIFIER) + + + +``` + +::: note +If your `Info.plist` file is not in the format shown above, you can right-click `Info.plist` in Xcode and select **Open As** > **Source Code**. +::: + +Go to your [Dashboard Settings](${manage_url}/#/applications/${account.clientId}/settings) and make sure that the **Allowed Callback URLs** field contains the following callback URL: + +```text +{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback +``` diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md b/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md new file mode 100644 index 0000000000..86e62af190 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md @@ -0,0 +1,49 @@ + + +## Install Dependencies + +### Cocoapods + +If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`: + +```ruby +pod 'Auth0', '~> 1.0' +``` + +Then run `pod install`. + +::: note +For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html). +::: + +### Carthage + +If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`: + +```ruby +github "auth0/Auth0.swift" ~> 1.0 +``` + +Then run `carthage bootstrap`. + +::: note +For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). +::: + +### SPM + +If you are using the Swift Package Manager, open the following menu item in Xcode: + +**File > Add Packages...** + +In the **Search or Enter Package URL** search box enter this url: + +```text +https://github.com/auth0/Auth0.swift.git +``` + +Then select the dependency rule and press **Add Package**. + +::: note +For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/swift_packages/adding_package_dependencies_to_your_app). +::: diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md b/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md new file mode 100644 index 0000000000..956318d9bb --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md @@ -0,0 +1,6 @@ +## Link the Accounts + +Now, you can link the accounts. To do this, you need the following values: +- `id`: the logged-in user's ID (see `profile.sub`) +- `accessToken`: a Management API access token for the saved account the user initially logged in to; must have the `update:current_user_identities` scope +- `otherUserToken`: the ID Token for the second account received in the last login response diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md b/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md new file mode 100644 index 0000000000..c4c1ea1510 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md @@ -0,0 +1,5 @@ +## Unlink the Accounts + +To unlink the accounts, you need to specify the following: +* `id`: the logged-in user's ID (see `profile.sub`) +* `userId` and `provider`: the values in the `identity` object you want to unlink diff --git a/fr-ca/articles/quickstart/native/_includes/_new_app.html b/fr-ca/articles/quickstart/native/_includes/_new_app.html new file mode 100644 index 0000000000..6b84b0d4e5 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_new_app.html @@ -0,0 +1,5 @@ +<% if (account.userName) { %> +

Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store somewhere safe. You will need them while configuing Angular in your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.

+<% } else { %> +

Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start be downloading the sample after you login as it is configured with your `Default App` credentials

+<% } %> diff --git a/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html b/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html new file mode 100644 index 0000000000..039e33abfb --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html @@ -0,0 +1,5 @@ +<% if (account.userName) { %> +

Get your credentials (Domain, Client ID, and Client Secret) from the dashboard. Be sure to select Native as the Application Type. +<% } else { %> +

Create an Auth0 account (or login) and add an authentication application instance from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). Be sure to select Native as the Application Type. +<% } %> diff --git a/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md b/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md new file mode 100644 index 0000000000..c5503ba31a --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md @@ -0,0 +1 @@ +Auth0 allows you to store user information that has not come from the identity provider as metadata. There are two types of metadata, **user_metadata** and **app_metadata**. For more information, see: [Metadata](/users/concepts/overview-user-metadata). \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/_rules-create-section.md b/fr-ca/articles/quickstart/native/_includes/_rules-create-section.md new file mode 100644 index 0000000000..32426a0548 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_rules-create-section.md @@ -0,0 +1,11 @@ +To create a rule, go to the [New Rule](${manage_url}/#/rules/new) page. You can create a rule from scratch by selecting an empty rule, or use one of the existing templates. These templates are written by Auth0 to assist you to in executing common tasks. + +For this example, select the **Add country to the user profile** rule. + +![Empty rule](/media/articles/rules/rule-choose-add-country-template.png) + +This rule extracts the `country_name` from the `context` and adds it to the user profile as a new `country` attribute. + +![Add country rule](/media/articles/rules/rule-create-add-country-country.png) + +This is just the beginning, you can edit the rule to meet your business needs. Once complete, click **Save**. The rule will execute any time a user logs in, and the country will be added to the user's profile. diff --git a/fr-ca/articles/quickstart/native/_includes/_rules-introduction.md b/fr-ca/articles/quickstart/native/_includes/_rules-introduction.md new file mode 100644 index 0000000000..ffd19a504a --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_rules-introduction.md @@ -0,0 +1 @@ +Rules are one of the most powerful features of Auth0. As JavaScript functions that execute each time a user authenticates, rules serve as middleware to extend the flexibility of your authentication flow. For a detailed description of rules, see the [full documentation](/rules). \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/_rules-test-result-intro.md b/fr-ca/articles/quickstart/native/_includes/_rules-test-result-intro.md new file mode 100644 index 0000000000..af8850b325 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/_rules-test-result-intro.md @@ -0,0 +1,3 @@ +To see the results of a created rule, login and fetch user profile information as explained in the [User Profile](${profilelink}) step. + +Then you can display the user profile's new `country` attribute added by the rule: \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_add_login_intro.md b/fr-ca/articles/quickstart/native/_includes/ionic/_add_login_intro.md new file mode 100644 index 0000000000..368ce98b12 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_add_login_intro.md @@ -0,0 +1,7 @@ + + +In a Capacitor application, the [Capacitor's Browser plugin](https://capacitorjs.com/docs/apis/browser) performs a redirect to the Auth0 [Universal Login Page](https://auth0.com/universal-login). Set the `openUrl` parameter on the `loginWithRedirect` function to use `Browser.open` so that the URL is opened using the device's system browser component ([SFSafariViewController](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) on iOS, and [Chrome Custom Tabs](https://developer.chrome.com/docs/android/custom-tabs) on Android). + +:::note +By default, the SDK's `loginWithRedirect` method uses `window.location.href` to navigate to the login page in the default browser application on the user's device rather than the system browser component appropriate for the platform. The user would leave your application to authenticate and could make for a suboptimal user experience. +::: \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_add_logout_intro.md b/fr-ca/articles/quickstart/native/_includes/ionic/_add_logout_intro.md new file mode 100644 index 0000000000..0cf81e522f --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_add_logout_intro.md @@ -0,0 +1,13 @@ + + +Now that users can log in, you need to configure [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Users must redirect to the Auth0 logout endpoint in the browser to clear their browser session. Again, Capacitor's Browser plugin should perform this redirect so that the user does not leave your app and receive a suboptimal experience. + +To achieve this with Ionic and Capacitor in conjunction with the Auth0 SDK: + +* Construct the URL for your app Auth0 should use to redirect to after logout. This is a URL that uses your registered custom scheme and Auth0 domain. Add it to your **Allowed Logout URLs** configuration in the Auth0 Dashboard +* Logout from the SDK by calling `logout`, and pass your redirect URL back as the `logoutParams.returnTo` parameter. +* Set the `openUrl` parameter to a callback that uses the Capacitor browser plugin to open the URL using `Browser.open`. + +:::note +Similar to the login step, if you do not set `openUrl` when calling `logout`, the SDK redirects the user to the logout URL using the default browser application on the device, which provides a suboptimal user experience. +::: \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_article_intro.md b/fr-ca/articles/quickstart/native/_includes/ionic/_article_intro.md new file mode 100644 index 0000000000..df7c935695 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_article_intro.md @@ -0,0 +1,7 @@ + + +## Getting started + +This quickstart assumes you already have an [Ionic](https://ionicframework.com/) application up and running with [Capacitor](https://capacitorjs.com/). If not, check out the [Using Capacitor with Ionic Framework guide](https://capacitorjs.com/docs/getting-started/with-ionic) to get started with a simple app, or clone [our sample apps](https://github.com/auth0-samples/auth0-ionic-samples). + +You should also be familiar with the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow). diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls.md b/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls.md new file mode 100644 index 0000000000..e17a9f3f2a --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls.md @@ -0,0 +1,35 @@ + + +<%= include('../../../../_includes/_callback_url') %> + +:::note +Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info. +::: + +Go to the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box. + +You should set the **Allowed Callback URL** to: + +```bash +YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback +``` + +<%= include('../../../../_includes/_logout_url') %> + +You should set the **Allowed Logout URLs** to + +```bash +YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback +``` + +### Configure Origins + +To be able to make requests from your application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). + +```bash +capacitor://localhost, http://localhost +``` + +These origins are required for iOS and Android respectively. + +Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md b/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md new file mode 100644 index 0000000000..b3ffd9d464 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md @@ -0,0 +1,43 @@ + + +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project. + +:::note +Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info. +::: + +### Configure an application + +Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample application instead. + +### Configure Callback URLs + +A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in. + +::: note +If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback` +::: + +### Configure Logout URLs + +A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error. + +::: note +If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback`. +::: + +### Configure Allowed Origins + +To be able to make requests from your native application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). + +::: note +If you are following along with our sample project, set this to `capacitor://localhost, http://localhost` for iOS and Android respectively. +::: + +Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md b/fr-ca/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md new file mode 100644 index 0000000000..eaa4e75188 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md @@ -0,0 +1,7 @@ + + +Once users logs in with the Universal Login Page, they redirect back to your app via a URL with a custom URL scheme. The `appUrlOpen` event must be handled within your app. You can call the `handleRedirectCallback` method from the Auth0 SDK to initialize the authentication state. + +You can only use this method on a redirect from Auth0. To verify success, check for the presence of the `code` and `state` parameters in the URL. + +The `Browser.close()` method should close the browser when this event is raised. diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_install_plugins.md b/fr-ca/articles/quickstart/native/_includes/ionic/_install_plugins.md new file mode 100644 index 0000000000..b0e37b311a --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_install_plugins.md @@ -0,0 +1,16 @@ + + +### Install Capacitor plugins + +This quickstart and sample make use of some of Capacitor's official plugins. Install these into your app using the following command: + +```bash +npm install @capacitor/browser @capacitor/app +``` + +- [`@capacitor/browser`](https://capacitorjs.com/docs/apis/browser) - allows you to interact with the device's system browser and is used to open the URL to Auth0's authorizaction endpoint +- [`@capacitor/app`](https://capacitorjs.com/docs/apis/app) - allows you to subscribe to high-level app events, useful for handling callbacks from Auth0 + +:::note +Capacitor's Browser plugin on iOS uses [`SFSafariViewController`](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller), which on iOS 11+ does not share cookies with Safari on the device. This means that [SSO](https://auth0.com/docs/sso) will not work on those devices. If you need SSO, please instead use a compatible plugin that uses [ASWebAuthenticationSession](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession). +::: diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md b/fr-ca/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md new file mode 100644 index 0000000000..b5002538c0 --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md @@ -0,0 +1,5 @@ + + +:::note +This article assumes you will be using Custom URL Schemes to handle the callback within your application. To do this, register your `YOUR_PACKAGE_ID` as a URL scheme for your chosen platform. To learn more, read [Defining a Custom URL Scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) for iOS, or [Create Deep Links to App Content](https://developer.android.com/training/app-links/deep-linking) for Android. +::: diff --git a/fr-ca/articles/quickstart/native/_includes/ionic/_note_storage.md b/fr-ca/articles/quickstart/native/_includes/ionic/_note_storage.md new file mode 100644 index 0000000000..89e9cde61f --- /dev/null +++ b/fr-ca/articles/quickstart/native/_includes/ionic/_note_storage.md @@ -0,0 +1,9 @@ + + +:::warning +To persist authentication after closing and reopening the application, you may want to set `cacheLocation` to `localstorage` when configuring the SDK, but please be aware of [the risks of storing tokens in localstorage](https://auth0.com/docs/libraries/auth0-single-page-app-sdk#change-storage-options). Also, localstorage should be treated as **transient** in Capacitor app as the data might be recovered unexpectedly in certain circumstances. Please read the [guidance on storage in the Capacitor docs](https://capacitorjs.com/docs/guides/storage#why-cant-i-just-use-localstorage-or-indexeddb). + +Additionally, the SDK has the ability to [use a custom cache implementation](https://github.com/auth0/auth0-spa-js/blob/master/EXAMPLES.md#creating-a-custom-cache) to store tokens, if you have a requirement to use a more secure and persistent storage mechanism. + +**Note** that we recommend **against** using [Capacitor's Storage plugin](https://capacitorjs.com/docs/apis/storage) to store tokens, as this is backed by [UserDefaults](https://developer.apple.com/documentation/foundation/userdefaults) and [SharedPreferences](https://developer.android.com/reference/android/content/SharedPreferences) on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud. +::: diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/00-login-facebook.md b/fr-ca/articles/quickstart/native/android-facebook-login/00-login-facebook.md new file mode 100644 index 0000000000..d0fc42be23 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android-facebook-login/00-login-facebook.md @@ -0,0 +1,23 @@ +--- +title: Login +description: This tutorial demonstrates how to add user login to an Android application using native Facebook Login. +budicon: 448 +topics: + - quickstarts + - native + - android + - facebook native +github: + path: 00-login-facebook +contentType: tutorial +useCase: quickstart +requirements: + - Android Studio 3.6.1 + - Android SDK 25 + - Emulator - Nexus 5X - Android 6.0 +--- + + + +<%= include('../_includes/_facebook_login_prerequisites') %> +<%= include('../_includes/_facebook_login_howto') %> diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/download.md b/fr-ca/articles/quickstart/native/android-facebook-login/download.md new file mode 100644 index 0000000000..20fbcf5b47 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android-facebook-login/download.md @@ -0,0 +1,16 @@ +To run it from the **command line**: + +1) Make sure the target device is available and install the App running the next command: + +```bash +# In Linux / macOS +./gradlew installDebug +# In Windows +gradlew installDebug +``` +2) On the Android device, locate the App icon on the App Drawer and click it to launch it. + +To run it from the **Android Studio IDE**: + +1) Open the project on [Android Studio](https://developer.android.com/studio/index.html). +2) Click the `Run` button (The green play) or select the menu option `Run | Run 'app'`, and then choose a target device. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/android-facebook-login/index.yml b/fr-ca/articles/quickstart/native/android-facebook-login/index.yml new file mode 100644 index 0000000000..28ad3647d3 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android-facebook-login/index.yml @@ -0,0 +1,53 @@ +title: Android - Facebook Login +# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.s +image: /media/platforms/android.png +logo_name: android +logo: android +alias: + - Android +language: + - Java +hybrid: false +author: + name: Luciano Balmaceda + email: luciano.balmaceda@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: android-facebook-login +snippets: + facebook_button_permissions: native-platforms/android-facebook-login/facebook-button-permissions + facebook_button_config: native-platforms/android-facebook-login/facebook-button-config + facebook_fetch_session_token: native-platforms/android-facebook-login/facebook-fetch-session-token + facebook_fetch_profile: native-platforms/android-facebook-login/facebook-fetch-profile + facebook_app_credentials: native-platforms/android-facebook-login/facebook-app-credentials + facebook_install_auth0_sdk: native-platforms/android-facebook-login/facebook-install-auth0-sdk + facebook_token_exchange: native-platforms/android-facebook-login/facebook-token-exchange +default_article: 00-login-facebook +articles: + - 00-login-facebook +next_steps: + - path: 00-login-facebook + list: + - text: Learn how to securely store tokens + icon: 345 + href: "/libraries/auth0-android/save-and-refresh-tokens" + - text: Learn to call an API + icon: 345 + href: "/quickstart/native/android/01-user-metadata" + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Learn more about the Android SDK + icon: 345 + href: "/libraries/auth0-android" +show_steps: true +github: + org: auth0-samples + repo: auth0-android-native-social-sample +requirements: + - Android Studio 3.6.1 + - Android SDK 25 + - Emulator - Nexus 5X - Android 6.0 diff --git a/fr-ca/articles/quickstart/native/android/00-login.md b/fr-ca/articles/quickstart/native/android/00-login.md new file mode 100755 index 0000000000..36bdc1e9a5 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/00-login.md @@ -0,0 +1,246 @@ +--- +title: Login +description: This quickstart demonstrates how to add user login to an Android application using Auth0. +seo_alias: android +budicon: 448 +topics: + - quickstarts + - native + - android +github: + path: 00-Login-Kt +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/_getting_started', { library: 'Android' }) %> + +<%= include('../../../_includes/_callback_url') %> + +::: note +If you are following along with the sample project you downloaded from the top of this page, you should set the **Allowed Callback URL** to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`. +::: + +Replace `YOUR_APP_PACKAGE_NAME` with your application's package name, available as the `applicationId` attribute in the `app/build.gradle` file. + +<%= include('../../../_includes/_logout_url', { returnTo: 'demo://' + account.namespace + '/android/YOUR_APP_PACKAGE_NAME/callback' }) %> + +Replace `YOUR_APP_PACKAGE_NAME` with your application's package name, available as the `applicationId` attribute in the `app/build.gradle` file. + +## Install the Auth0 Android SDK + +Add the [Auth0 Android](https://github.com/auth0/Auth0.Android) SDK into your project. The library will make requests to the Auth0's Authentication and Management APIs. + +### Add Auth0 to Gradle + +In your app's `build.gradle` dependencies section, add the following: + +```groovy +dependencies { + // Add the Auth0 Android SDK + implementation 'com.auth0.android:auth0:2.+' +} +``` + +In the android section, target Java 8 byte code for Android and Kotlin plugins respectively. + +```groovy +android { + compileOptions { + sourceCompatibility JavaVersion.VERSION_1_8 + targetCompatibility JavaVersion.VERSION_1_8 + } + kotlinOptions { + jvmTarget = '1.8' + } +} +``` + +::: panel Sync Project with Gradle Files +Remember to synchronize using the Android Studio prompt or run `./gradlew clean build` from the command line. For more information about Gradle usage, check [their official documentation](http://tools.android.com/tech-docs/new-build-system/user-guide). +::: + +Add manifest placeholders required by the SDK. The placeholders are used internally to define an `intent-filter` that captures the authentication callback URL. For this, the Auth0 tenant domain and the scheme that take part in the callback URL must be set. + +::: note +We've used a value of `demo` for `auth0Scheme` here, so that a custom URL scheme can be used for the URL that Auth0 redirects to after login. The alternative is `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK readme](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking). +::: + +To add the manifest placeholders, add the next line: + +```groovy +// app/build.gradle + +apply plugin: 'com.android.application' +compileSdkVersion 30 +android { + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 21 + targetSdkVersion 30 + // ... + + // ---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"] + // <--- + } +} +``` + +::: note +You do not need to declare a specific `intent-filter` for your activity, because you have defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values and the library will handle the redirection for you. +::: + +Finally, ensure that the `android.permissions.INTERNET` permission is specified in the `AndroidManifest.xml` file: + +```xml + +``` + +Run **Sync Project with Gradle Files** inside Android Studio or execute `./gradlew clean assembleDebug` from the command line. + +::: note +For more information about using Gradle, check the [Gradle official documentation](https://gradle.org/getting-started-android-build/). +::: + +## Add Login to your App + +[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features. + +In the `onCreate` method, create a new instance of the `Auth0` class to hold user credentials: + +```kotlin +// Import the parts needed by the SDK +import com.auth0.android.Auth0 +import com.auth0.android.provider.WebAuthProvider + +class MainActivity : AppCompatActivity() { + + private lateinit var account: Auth0 + + override fun onCreate(savedInstanceState: Bundle?) { + super.onCreate(savedInstanceState) + + // Set up the account object with the Auth0 application details + account = Auth0( + "${account.clientId}", + "${account.namespace}" + ) + } +} +``` + +:::note +We suggest you do not hardcode the values for `clientId` and `domain` as you may need to change them in the future. Instead, use [String Resources](https://developer.android.com/guide/topics/resources/string-resource.html), such as `@string/com_auth0_domain`, to define the values. +::: + +Finally, create a `loginWithBrowser` method and use the `WebAuthProvider` class to authenticate with any connection you enabled on your application in the [Auth0 dashboard](${manage_url}/#/). Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration: + +```kotlin +private fun loginWithBrowser() { + // Setup the WebAuthProvider, using the custom scheme and scope. + + WebAuthProvider.login(account) + .withScheme("demo") + .withScope("openid profile email") + // Launch the authentication passing the callback where the results will be received + .start(this, object : Callback { + // Called when there is an authentication failure + override fun onFailure(exception: AuthenticationException) { + // Something went wrong! + } + + // Called when authentication completed successfully + override fun onSuccess(credentials: Credentials) { + // Get the access token from the credentials object. + // This can be used to call APIs + val accessToken = credentials.accessToken + } + }) +} +``` + +After you call the `WebAuthProvider#start` function, the browser launches and shows the login page. Once the user authenticates, the callback URL is called. The callback URL contains the final result of the authentication process. + +:::note +There are many options to customize the authentication with the `WebAuthProvider` builder. You can read about them in the [Auth0 SDK for Android documentation](/libraries/auth0-android). + +

+ Universal Login +
+::: + +:::panel Checkpoint +Add a button to your application that calls `loginWithBrowser`. When you click it, verify that your Android application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects back to your app. +::: + +## Add Logout to your App + +Use `WebAuthProvider` to remove the cookie set by the Browser at authentication time, so that the users are forced to re-enter their credentials the next time they try to authenticate. + +Add a `logout` method to your app to remove the user's session and log them out of the app. Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration: + +```kotlin +private fun logout() { + WebAuthProvider.logout(account) + .withScheme("demo") + .start(this, object: Callback { + override fun onSuccess(payload: Void?) { + // The user has been logged out! + } + + override fun onFailure(error: AuthenticationException) { + // Something went wrong! + } + }) +} +``` + +The logout is achieved by using the `WebAuthProvider` class. This call will open the Browser and navigate the user to the logout endpoint. If the log out is cancelled, you might want to take the user back to where they were before attempting to log out. + +:::panel Checkpoint +Add a button to your app that calls `logout` and logs the user out of your application. When you click it, verify that your Android app redirects you logout page and back again, and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +Use the `AuthenticationAPIClient` class to [retrieve the user's profile from Auth0](https://auth0.com/docs/users/user-profiles#user-profile-management-api-access). This requires: + +- The access token as received during the login phase +- The `profile` scope to be included when `WebAuthProvider.login` is called + +The `email` scope must also be specified if the user's email address is to be retrieved. + +:::note +This quickstart sets the `openid profile email` scopes by default during the login step above. +::: + +The following demonstrates a function that can be used to retrieve the user's profile and show it on the screen: + +```kotlin +private fun showUserProfile(accessToken: String) { + var client = AuthenticationAPIClient(account) + + // With the access token, call `userInfo` and get the profile from Auth0. + client.userInfo(accessToken) + .start(object : Callback { + override fun onFailure(exception: AuthenticationException) { + // Something went wrong! + } + + override fun onSuccess(profile: UserProfile) { + // We have the user's profile! + val email = profile.email + val name = profile.name + } + }) +} +``` + +:::panel Checkpoint +Call the `showUserProfile` function after login and verify that the user's profile information has been returned in the `onSuccess` callback. +::: diff --git a/fr-ca/articles/quickstart/native/android/01-user-metadata.md b/fr-ca/articles/quickstart/native/android/01-user-metadata.md new file mode 100644 index 0000000000..8ed1322a43 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/01-user-metadata.md @@ -0,0 +1,127 @@ +--- +title: User Metadata +description: This quickstart demonstrates how to make API calls to the Auth0 Management API to read and update user metadata. +seo_alias: android +budicon: 448 +topics: + - quickstarts + - native + - android + - api +github: + path: 00-Login-Kt +sample_download_required_data: + - client + - api +contentType: tutorial +useCase: quickstart +--- + + + +::: note +Before you continue with this tutorial, make sure that you have completed the [Login chapter](/quickstart/native/android) +::: + +As an example of using the SDK to call APIs that may require custom scopes and audiences, we will demonstrate these settings by reading and updating user profile information. + +## Read User Metadata + +In [the previous chapter](/quickstart/native/android/00-login#show-user-profile-information), you saw how to access [basic user profile information](https://auth0.com/docs/users/user-profiles) using the `/userinfo` endpoint. This profile information may not include everything about a user that you might need. For example, in order to access the user's metadata, you must make an API call to the Management API using the user ID and the access token. With the Android SDK, this is done using the `UsersAPIClient` object. + +To be able to correctly read and update the user metadata, ensure the authorization server allows you to read and edit the current user profile by specifying the `openid profile email read:current_user update:current_user_metadata` scopes. In addition, specify the audience for the [Auth0 Management API](https://auth0.com/docs/api), which happens to include the User Info audience as well. + +Find the code in your project that initializes the `WebAuthProvider` class, and make the following changes if necessary: + +* amend the argument given to `withScope` to be `openid profile email offline_access read:current_user update:current_user_metadata` +* add a call to `withAudience` and pass the audience for the Auth0 Management API: `https://${account.namespace}/api/v2/` (please note the trailing slash - this is required) + +```kotlin +WebAuthProvider.login(account) + .withScheme("demo") + // modify the scopes to enable read and write of user_metadata + .withScope("openid profile email read:current_user update:current_user_metadata") + // specify the audience for the Auth0 Management API + .withAudience("https://${account.namespace}/api/v2/") + .start(this, /* .. callback .. */) +``` + +:::note +In the case of the Auth0 Management API, the `read:current_user` and `update:current_user_metadata` scopes let you get an access token that can retrieve user details and update the user's information. In the case of your APIs, you'll define custom [API scopes](https://auth0.com/docs/scopes/current/api-scopes) to implement access control, and you'll identify them in the calls that your client applications make to that API. + +In addition, in the case of the Auth0 Management API, the audience is `https://${account.namespace}/api/v2/`. In the case of your APIs, you create an _Identifier_ value that serves as the _Audience_ value whenever you [set up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0. +::: + +Once you have a `UserProfile` instance (retrieved by calling `userInfo` from the previous chapter), get the user's ID and then use the `UsersAPIClient` to get the full profile for the user in another `UserProfile` instance. This profile will include all of the previous user profile information, as well as additional fields such as `user_metadata` and `app_metadata`. + +:::note +Fields such as `user_metadata` and `app_metadata` are not available on the user profile that is returned by calling `userInfo`, as these fields are [proprietary fields to Auth0](https://auth0.com/docs/users/normalized-user-profiles) and not part of the OIDC spec. You must call the [Auth0 Management API](https://auth0.com/docs/users/manage-user-metadata#management-api) to get these fields, which is what you are doing by using the `UsersAPIClient` in the snippet below. +::: + +The metadata can then be retrieved by using the `getUserMetadata` method on the `UserProfile` object. + +```kotlin +fun getUserMetadata(userId: String, accessToken: String) { + // Get the user ID and call the full getUser Management API endpoint, to retrieve the full profile information + // Create the user API client using the account details and the access token from Credentials + val usersClient = UsersAPIClient(account, accessToken) + + // Get the full user profile + usersClient + .getProfile(userId) + .start(object: Callback { + override fun onFailure(exception: ManagementException) { + // Something went wrong! + } + + override fun onSuccess(profile: UserProfile) { + // Retrieve the "country" field, if one appears in the metadata + val country = profile.getUserMetadata()["country"] as String? + } + }) +} +``` + +:::note +At this stage, if you are logging in as a brand new user, they are unlikely to have a "country" field inside their metadata. You can [read more about how user metadata](https://auth0.com/docs/users/manage-user-metadata) is managed on our Docs site. +::: + +:::panel Checkpoint +Add the above code to your application at the point where you already get the basic user profile, and observe that you are able to get the "country" field, which may be empty if the user does not have that field in their user metadata. In the next section you will see how to update the user with this metadata using the Management API. +::: + +## Update User Metadata + +Updating user metadata is done in a very similar fashion. Call the `updateMetadata` method on the `UsersAPIClient` object to update the metadata for a specific user. You must also supply a map of data that is used to update the user metadata with. + +```kotlin +fun patchUserMetadata(userId: String, accessToken: String) { + // Create the UsersAPIClient with the account details + // and the access token from the Credentials object + val usersClient = UsersAPIClient(account, accessToken) + + // Create a map of data to update the user metadata with. + // In this case, we're adding/updating a custom "country" field + val metadata = mapOf("country" to "United States") + + // Call updateMetadata with the id of the user to update, and the map of data + usersClient.updateMetadata(userId, metadata) + .start(object: Callback { + override fun onFailure(exception: ManagementException) { + // Something went wrong! + } + + override fun onSuccess(profile: UserProfile) { + // The metadata was updated and we're given the updated user profile. + // Retrieve the "country" field, if one appears in the metadata + val country = profile.getUserMetadata()["country"] as String? + } + }) +} +``` + +:::panel Checkpoint +Add the above code to your application at the point where you already get the basic user profile, and observe that the `onSuccess` callback is executed. Then, re-run the code to _read_ the user metadata, and you should see that a value for "country" is now returned. + +You can also see the updated metadata in the [Auth0 Dashboard](https://manage.auth0.com) by [inspecting the user](https://auth0.com/docs/users/manage-users-using-the-dashboard) and looking at the metadata collection in your web browser. +::: diff --git a/fr-ca/articles/quickstart/native/android/download.md b/fr-ca/articles/quickstart/native/android/download.md new file mode 100644 index 0000000000..62632e454f --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/download.md @@ -0,0 +1,31 @@ + + +To run the sample first set the **Callback URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to + +```text +demo://${account.namespace}/android/com.auth0.androidsample/callback +``` + +To run the sample first set the **Logout URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to + +```text +demo://${account.namespace}/android/com.auth0.androidsample/callback +``` + +Then, to run it from the **command line**: + +1) Make sure the target device is available and install the App running the next command: + +```bash +# In Linux / macOS +./gradlew installDebug +# In Windows +gradlew installDebug +``` + +2) On the Android device, locate the App icon on the App Drawer and click it to launch it. + +To run it from the **Android Studio IDE**: + +1) Open the project on [Android Studio](https://developer.android.com/studio/index.html). +2) Click the `Run` button (The green play) or select the menu option `Run | Run 'app'` and then choose a target device. \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/android/files/build.md b/fr-ca/articles/quickstart/native/android/files/build.md new file mode 100644 index 0000000000..6ab782ff49 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/files/build.md @@ -0,0 +1,25 @@ +--- +name: build.gradle +language: groovy +--- +```groovy +apply plugin: 'com.android.application' + +android { + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 21 + targetSdkVersion 30 + // ... + + // ---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"] + // <--- + } +} + +dependencies { + // Add the Auth0 Android SDK + implementation 'com.auth0.android:auth0:2.+' +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/android/files/main.md b/fr-ca/articles/quickstart/native/android/files/main.md new file mode 100644 index 0000000000..94497915cc --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/files/main.md @@ -0,0 +1,77 @@ +--- +name: MainActivity.kt +language: kotlin +--- +```kotlin +import com.auth0.android.Auth0 +import com.auth0.android.provider.WebAuthProvider + +class MainActivity : AppCompatActivity() { + + private lateinit var account: Auth0 + + override fun onCreate(savedInstanceState: Bundle?) { + super.onCreate(savedInstanceState) + + // Set up the account object with the Auth0 application details + account = Auth0( + getString(R.string.com_auth0_client_id), + getString(R.string.com_auth0_domain), + ) + } + + private fun loginWithBrowser() { + // Setup the WebAuthProvider, using the custom scheme and scope. + + WebAuthProvider.login(account) + .withScheme("demo") + .withScope("openid profile email") + // Launch the authentication passing the callback where the results will be received + .start(this, object : Callback { + // Called when there is an authentication failure + override fun onFailure(exception: AuthenticationException) { + // Something went wrong! + } + + // Called when authentication completed successfully + override fun onSuccess(credentials: Credentials) { + // Get the access token from the credentials object. + // This can be used to call APIs + val accessToken = credentials.accessToken + } + }) + } + + private fun logout() { + WebAuthProvider.logout(account) + .withScheme("demo") + .start(this, object : Callback { + override fun onSuccess(payload: Void?) { + // The user has been logged out! + } + + override fun onFailure(error: AuthenticationException) { + // Something went wrong! + } + }) + } + + private fun showUserProfile(accessToken: String) { + var client = AuthenticationAPIClient(account) + + // With the access token, call `userInfo` and get the profile from Auth0. + client.userInfo(accessToken) + .start(object : Callback { + override fun onFailure(exception: AuthenticationException) { + // Something went wrong! + } + + override fun onSuccess(profile: UserProfile) { + // We have the user's profile! + val email = profile.email + val name = profile.name + } + }) + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/android/files/strings.md b/fr-ca/articles/quickstart/native/android/files/strings.md new file mode 100644 index 0000000000..7a292938a3 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/files/strings.md @@ -0,0 +1,10 @@ +--- +name: strings.xml +language: xml +--- +```xml + + "YOUR_DOMAIN" + "YOUR_CLIENT_ID" + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/android/index.yml b/fr-ca/articles/quickstart/native/android/index.yml new file mode 100755 index 0000000000..0e64b75a56 --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/index.yml @@ -0,0 +1,57 @@ +title: Android +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/android.png +logo: android +alias: + - Android +language: + - Kotlin +hybrid: false +author: + name: Luciano Balmaceda + email: luciano.balmaceda@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +show_releases: true +snippets: + dependencies: native-platforms/android/dependencies + setup: native-platforms/android/setup + use: native-platforms/android/use +seo_alias: android +default_article: 00-login +hidden_articles: + - interactive +articles: + - 00-login + - 01-user-metadata +next_steps: + - path: 00-login + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" +show_steps: true +github: + org: auth0-samples + repo: auth0-android-sample + branch: master +sdk: + name: Auth0.Android + url: https://github.com/auth0/Auth0.Android + logo: android +requirements: + - Android Studio 4.1.0 + - Android SDK 30 + - Emulator - Android 11.0 diff --git a/fr-ca/articles/quickstart/native/android/interactive.md b/fr-ca/articles/quickstart/native/android/interactive.md new file mode 100644 index 0000000000..c546e1b21b --- /dev/null +++ b/fr-ca/articles/quickstart/native/android/interactive.md @@ -0,0 +1,174 @@ +--- +title: Add Login to your Android App +description: This quickstart demonstrates how to add user login to an Android application using Auth0. +seo_alias: android +interactive: true +files: + - files/build + - files/strings + - files/main +github: + path: 00-Login-Kt +--- + +# Add Login to Your Android Application + + + + + +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure authentication in your project. +### Configure an application + +Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future. + +If you would rather explore a complete configuration, you can view a sample application instead. + +### Configure callback URLs + +A callback URL is the application URL that Auth0 will direct your users to once they have authenticated. If you do not set this value, Auth0 will not return users to your application after they log in. + +::: note +If you are following along with our sample project, set this to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`. +::: + +### Configure logout URLs + +A logout URL is the application URL Auth0 will redirect your users to once they log out. If you do not set this value, users will not be able to log out from your application and will receive an error. + +::: note +If you are following along with our sample project, set this to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`. +::: + +## Install the Auth0 Android SDK {{{ data-action=code data-code="build.gradle#18" }}} + +Add the [Auth0 Android](https://github.com/auth0/Auth0.Android) SDK into your project. The library will make requests to the Auth0's Authentication and Management APIs. + +In your app's `build.gradle` dependencies section, add the following: + +```groovy +implementation 'com.auth0.android:auth0:2.+' +``` + +Ensure you target Java 8+ byte code for Android and Kotlin plugins respectively. + +## Add manifest placeholders {{{ data-action=code data-code="build.gradle#10:12" }}} + +The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set Auth0 tenant domain and the callback URL scheme. + +You do not need to declare a specific `intent-filter` for your activity, because you have defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values and the library will handle the redirection for you. + +::: note +We've used a value of `demo` for `auth0Scheme` here, so that a custom URL scheme can be used for the URL that Auth0 redirects to after login. The alternative is `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking). +::: + +## Configure your application {{{ data-action=code data-code="strings.xml#2:3" }}} + +For the SDK to function properly, you must set the following properties in `strings.xml`: + +- `com_auth0_domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead. +- `com_auth0_client_id`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field. + +Ensure that the `AndroidManifest.xml` file specifies the `android.permissions.INTERNET` permission: + +```xml + +``` + +Run **Sync Project with Gradle Files** inside Android Studio or execute `./gradlew clean assembleDebug` from the command line. + +::: note +For more information about using Gradle, check the [Gradle official documentation](https://gradle.org/getting-started-android-build/). +::: + +## Add login to your application {{{ data-action=code data-code="MainActivity.kt#6:38" }}} + +[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features. + +In the `onCreate` method, create a new instance of the `Auth0` class to hold user credentials. + +Create a `loginWithBrowser` method and use the `WebAuthProvider` class to authenticate with any connection you enabled on your application in the [Auth0 dashboard](${manage_url}/#/). Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration. + +After you call the `WebAuthProvider#start` function, the browser launches and shows the login page. Once the user authenticates, the callback URL is called. The callback URL contains the final result of the authentication process. + +::::checkpoint + +:::checkpoint-default + +Add a button to your application that calls `loginWithBrowser`. When you click it, verify that your Android application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects back to your app. + +::: + +:::checkpoint-failure + +If your application did not launch successfully: +* Ensure you set the Allowed Callback URLs are correct +* Verify you saved your changes after entering your URLs +* Make sure the domain and cliend ID values imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="MainActivity.kt#40:52" }}} + +Use `WebAuthProvider` to remove the cookie set by the browser at authentication time, so that the users are forced to re-enter their credentials the next time they try to authenticate. + +Add a `logout` method to your app to remove the user's session and log them out of the app. Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration. + +Use the `WebAuthProvider` class to implement logout. This call opens the browser and navigates the user to the logout endpoint. If the user cancels the logout, consider redirected the user to their previous URL. +::::checkpoint + +:::checkpoint-default + +Add a button to your app that calls `logout` and logs the user out of your application. When you click it, verify that your Android app redirects you logout page and back again, and that you are no longer logged in to your application. + +::: + +:::checkpoint-failure +If your application did not logout successfully: +* Ensure the Allowed Logout URLs are set properly +* Verify you saved your changes after entering your URLs + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Show user profile information {{{ data-action=code data-code="MainActivity.kt#54:70" }}} + +Use the `AuthenticationAPIClient` class to [retrieve the user's profile from Auth0](https://auth0.com/docs/users/user-profiles#user-profile-management-api-access). This requires: + +- The access token returned from the login phase +- The `WebAuthProvider.login` must contain the `profile` scope + +You must specify the `email` scope if you need to retreive the user's email address. + +:::note +This quickstart sets the `openid profile email` scopes by default during the login step above. +::: + +The following demonstrates a function that can be used to retrieve the user's profile and show it on the screen: + +::::checkpoint + +:::checkpoint-default +Call the `showUserProfile` function after login. Verify the `onSuccess` callback returns the user's profile information. + +::: + +:::checkpoint-failure +If your application did not return user profile information: +* Verify the `accessToken` is valid + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: diff --git a/fr-ca/articles/quickstart/native/config.yml b/fr-ca/articles/quickstart/native/config.yml new file mode 100644 index 0000000000..51f64e8751 --- /dev/null +++ b/fr-ca/articles/quickstart/native/config.yml @@ -0,0 +1,2 @@ +sample_download_required_data: + - client diff --git a/fr-ca/articles/quickstart/native/device/01-login.md b/fr-ca/articles/quickstart/native/device/01-login.md new file mode 100644 index 0000000000..5902c598bf --- /dev/null +++ b/fr-ca/articles/quickstart/native/device/01-login.md @@ -0,0 +1,14 @@ +--- +title: Login +description: This tutorial demonstrates how to call your API from an input-constrained device using the Device Authorization flow. +budicon: 448 +topics: + - quickstarts + - native + - cordova +github: + path: 01-Login +contentType: tutorial +useCase: quickstart +--- +<%= include('../../../flows/guides/device-auth/includes/index.md') %> diff --git a/fr-ca/articles/quickstart/native/device/index.yml b/fr-ca/articles/quickstart/native/device/index.yml new file mode 100644 index 0000000000..22ff3ff856 --- /dev/null +++ b/fr-ca/articles/quickstart/native/device/index.yml @@ -0,0 +1,24 @@ +title: Device Authorization Flow +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/device.svg +logo: auth0 +author: + name: Rachel Khoriander + email: rachel.khoriander@auth0.com + community: false +hybrid: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: +alias: + - device + - device-auth + - device-flow + - device-authorization-flow +seo_alias: device +default_article: 01-login +articles: + - 01-login +show_steps: false diff --git a/fr-ca/articles/quickstart/native/flutter/01-login.md b/fr-ca/articles/quickstart/native/flutter/01-login.md new file mode 100644 index 0000000000..d0c303707b --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/01-login.md @@ -0,0 +1,319 @@ +--- +title: Add login to your Flutter app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Android, iOS, or macOS Flutter app using the Auth0 Flutter SDK +budicon: 448 +topics: + - quickstarts + - native + - flutter + - dart + - ios + - macos + - android +contentType: tutorial +useCase: quickstart +files: + - files/build + - files/main + - files/profile +github: + path: sample +--- + +# Add login to your Flutter app + +Auth0 allows you to quickly add authentication and access user profile information in your app. This guide demonstrates how to integrate Auth0 with a Flutter app using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter). + +:::note +The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS. +::: + +## Getting started + +This quickstart assumes you already have a [Flutter](https://flutter.dev/) app up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app. + +You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli). + +Finally, you will need a **Native** Auth0 application. If you don’t have a Native Auth0 application already, [create one](/get-started/auth0-overview/create-applications/native-apps) before continuing. Avoid using other application types, as they have different configurations and may cause errors. + +### Configure the callback and logout URLs + +The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie. + +If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error. + +Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page. + +::: note +On Android, the value of the `SCHEME` placeholder can be `https` or some other custom scheme. `https` schemes require enabling [Android App Links](https://auth0.com/docs/get-started/applications/enable-android-app-links-support). + +On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links (`https` scheme) as callback and logout URLs. When enabled, the SDK will fall back to using a custom URL scheme on older iOS / macOS versions –your app's [bundle identifier](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids). +**This feature requires Xcode 15.3+ and a paid Apple Developer account**. +::: + +#### Android + +```text +SCHEME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback +``` + +#### iOS + +```text +https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback +``` + +#### macOS + +```text +https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback +``` + +For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be: + +```text +https://example.us.auth0.com/ios/com.example.MyApp/callback, +com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback +``` + +## Install the Auth0 Flutter SDK + +Add the Auth0 Flutter SDK into the project: + +```shell +flutter pub add auth0_flutter +``` + +## Configure Android + +If you are not developing for the Android platform, skip this step. + +The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set the Auth0 tenant domain and the callback URL scheme. + +Modify `app/build.gradle` to include manifest placeholders for `auth0Domain` and `auth0Scheme` inside the `defaultConfig` section: + +```groovy +apply plugin: 'com.android.application' + +android { + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 21 + targetSdkVersion flutter.targetSdkVersion + // ... + + // ---> Add the next line + manifestPlaceholders += [auth0Domain: "${account.namespace}", auth0Scheme: "https"] + // <--- + } +} +``` + +- `auth0Domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under your **Application Settings** in the Domain field. If you are using a custom domain, you should set this to the value of your custom domain instead. +- `auth0Scheme`: The scheme to use. Can be a custom scheme, or `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking). + +:::note +You do not need to declare a specific `intent-filter` for your activity because you defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values. The library handles the redirection for you. +::: + +Run **Sync Project with Gradle Files** inside Android Studio to apply your changes. + +## Configure iOS/macOS + +If you are not developing for the iOS or macOS platforms, skip this step. + +::: warning +This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead. +::: + +#### Configure the Team ID and bundle identifier + +Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier. + +

Screenshot of the iOS section inside the Auth0 application settings page

+ +This will add your app to your Auth0 tenant's `apple-app-site-association` file. + +#### Add the associated domain capability + +Open your app in Xcode by running `open ios/Runner.xcworkspace` (or `open macos/Runner.xcworkspace` for macOS). Go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of the **Runner** target settings, and press the **+ Capability** button. Then select **Associated Domains**. + +

Screenshot of the capabilities library inside Xcode

+ +Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**: + +```text +webcredentials:${account.namespace} +``` + +If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page. + +::: note +For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application. +::: + +## Add login to your app + +[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your app. We recommend using it for the best experience, best security, and the fullest array of features. + +Integrate Auth0 Universal Login in your Flutter app by importing the SDK and instantiating the `Auth0` class using your Auth0 domain and Client ID values. See this example, which instantiates the class inside a widget state object: + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; + +class MainView extends StatefulWidget { + const MainView({Key? key}) : super(key: key); + + @override + State createState() => _MainViewState(); +} + +class _MainViewState extends State { + Credentials? _credentials; + + late Auth0 auth0; + + @override + void initState() { + super.initState(); + auth0 = Auth0('${account.namespace}', '${account.clientId}'); + } + + @override + Widget build(BuildContext context) { + // ... + } +} +``` + +Next, redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens. See this example of a `ElevatedButton` widget that logs the user in when clicked. Note that `_credentials` is used to determine locally within your app whether or not a user is signed in: + +```dart +if (_credentials == null) { + ElevatedButton( + onPressed: () async { + // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+ + // useHTTPS is ignored on Android + final credentials = + await auth0.webAuthentication().login(useHTTPS: true); + + setState(() { + _credentials = credentials; + }); + }, + child: const Text("Log in") + ) +} +``` + +**Android**: if you are using a custom scheme, pass this scheme to the login method so that the SDK can route to the login page and back again correctly: + +```dart +await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login(); +``` + +When a user logs in, they are redirected back to your app. Then, you are able to access the ID and access tokens for this user. + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `webAuthentication().login()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your app. + +Verify that you can get access to the tokens on the result of calling `login`. +::: + +:::checkpoint-failure +If your app did not launch successfully: + +- Ensure you set the Allowed Callback URLs are correct +- Verify you saved your changes after entering your URLs +- Make sure the domain and client ID values are imported correctly +- If using Android, ensure that the manifest placeholders have been set up correctly, otherwise the redirect back to your app may not work + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add logout to your app + +To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `webAuthentication().logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout). + +See this example of an `ElevatedButton` widget that logs the user out of the app. Note that `_credentials` is set to `null`, indicating that the user is no longer signed in to your app: + +```dart +ElevatedButton( + onPressed: () async { + // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+ + // useHTTPS is ignored on Android + await auth0.webAuthentication().logout(useHTTPS: true); + + setState(() { + _credentials = null; + }); + }, + child: const Text("Log out")) +``` + +**Android**: if you are using a custom scheme, pass this scheme to the logout method so that the SDK can route back to your app correctly: + +``` +await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout(); +``` + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `webAuthentication().logout()` and logs the user out of your app. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your app. +::: + +:::checkpoint-failure +If your app did not log out successfully: + +- Ensure the Allowed Logout URLs are set properly +- Verify you saved your changes after entering your URLs + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Show user profile information + +The user profile automatically retrieves user profile properties for you when you call `webAuthentication().login()`. The returned object from the login step contains a `user` property with all the user profile properties, which populates by decoding the ID token. + +See this example of a `View` component that displays the user profile on the screen: + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:flutter/material.dart'; + +class ProfileView extends StatelessWidget { + const ProfileView({Key? key, required this.user}) : super(key: key); + + final UserProfile user; + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (user.name != null) Text(user.name!), + if (user.email != null) Text(user.email!) + ], + ); + } +} +``` + +::::checkpoint +:::checkpoint-default +Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`. +::: +:::checkpoint-failure +If your app did not return user profile information: + +- Verify the access token is valid + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/native/flutter/_configure_urls_interactive.md b/fr-ca/articles/quickstart/native/flutter/_configure_urls_interactive.md new file mode 100644 index 0000000000..e1a0c2f280 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/_configure_urls_interactive.md @@ -0,0 +1,51 @@ +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project. + +### Configure an Auth0 application + +Use the interactive selector to create a new Auth0 application or select an existing **Native** Auth0 application. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample app instead. + +### Configure the callback and logout URLs + +The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie. If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error. + +Set the callback and logout URLs to the following values, depending on your platform. + +::: note +On Android, the value of the `SCHEME` placeholder can be `https` or some other custom scheme. `https` schemes require enabling [Android App Links](https://auth0.com/docs/get-started/applications/enable-android-app-links-support). + +On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links (`https` scheme) as callback and logout URLs. When enabled, the SDK will fall back to using a custom URL scheme on older iOS / macOS versions –your app's [bundle identifier](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids). +**This feature requires Xcode 15.3+ and a paid Apple Developer account**. +::: + +#### Android + +```text +SCHEME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback +``` + +#### iOS + +```text +https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback +``` + +#### macOS + +```text +https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback +``` + +For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be: + +```text +https://example.us.auth0.com/ios/com.example.MyApp/callback, +com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback +``` diff --git a/fr-ca/articles/quickstart/native/flutter/download.md b/fr-ca/articles/quickstart/native/flutter/download.md new file mode 100644 index 0000000000..8973142196 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/download.md @@ -0,0 +1,25 @@ + + +> On every step, if you have a [custom domain](https://auth0.com/docs/customize/custom-domains), replace the `YOUR_AUTH0_DOMAIN` placeholder with your custom domain instead of the value from the settings page. + +## 1. Configure the Auth0 application + +Open the settings page of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform you want to use. + +- Android: `com.auth0.sample://YOUR_AUTH0_DOMAIN/android/com.auth0.sample/callback` +- iOS: `https://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback` +- macOS: `https://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback` + +## 2. Configure the associated domain (iOS/macOS only) + +> **This following requires Xcode 15.3+ and a paid Apple Developer account**. If you do not have a paid Apple Developer account, skip this step, and set the `useHTTPS` parameter to `false` in the `login()` and `logout()` calls at `lib/example_app.dart`. + +Open `ios/Runner.xcodeproj` (or `macos/Runner.xcodeproj`, for macOS) in Xcode and go to the settings of the **Runner** app target. In the **Signing & Capabilities** tab, change the bundle identifier from the default `com.auth0.samples.FlutterSample` to another value of your choosing. Then, make sure the **Automatically manage signing** box is checked, and that your Apple Team is selected. + +Next, find the `webcredentials:YOUR_AUTH0_DOMAIN` entry under **Associated Domains**, and replace the `YOUR_AUTH0_DOMAIN` placeholder with the domain of your Auth0 application. + +Finally, open the settings page of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to the app's bundle identifier. + +## 3. Run the app + +Use the [Flutter CLI](https://docs.flutter.dev/reference/flutter-cli) to run the app: `flutter run`. diff --git a/fr-ca/articles/quickstart/native/flutter/files/build.md b/fr-ca/articles/quickstart/native/flutter/files/build.md new file mode 100644 index 0000000000..39842f5c24 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/files/build.md @@ -0,0 +1,21 @@ +--- +name: app/build.gradle +language: groovy +--- + +```groovy +apply plugin: 'com.android.application' + +android { + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 21 + targetSdkVersion flutter.targetSdkVersion + // ... + + // ---> Add the next line + manifestPlaceholders += [auth0Domain: "${account.namespace}", auth0Scheme: "https"] + // <--- + } +} +``` diff --git a/fr-ca/articles/quickstart/native/flutter/files/main.md b/fr-ca/articles/quickstart/native/flutter/files/main.md new file mode 100644 index 0000000000..b0f41fd59a --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/files/main.md @@ -0,0 +1,68 @@ +--- +name: main_view.dart +language: dart +--- + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:flutter/material.dart'; +import 'profile_view.dart'; + +class MainView extends StatefulWidget { + const MainView({Key? key}) : super(key: key); + + @override + State createState() => _MainViewState(); +} + +class _MainViewState extends State { + Credentials? _credentials; + + late Auth0 auth0; + + @override + void initState() { + super.initState(); + auth0 = Auth0('${account.namespace}', '${account.clientId}'); + } + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (_credentials == null) + ElevatedButton( + onPressed: () async { + // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+ + // useHTTPS is ignored on Android + final credentials = + await auth0.webAuthentication().login(useHTTPS: true); + + setState(() { + _credentials = credentials; + }); + }, + child: const Text("Log in")) + else + Column( + children: [ + ProfileView(user: _credentials!.user), + ElevatedButton( + onPressed: () async { + // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+ + // useHTTPS is ignored on Android + await auth0.webAuthentication().logout(useHTTPS: true); + + setState(() { + _credentials = null; + }); + }, + child: const Text("Log out")) + ], + ) + ], + ); + } +} +``` diff --git a/fr-ca/articles/quickstart/native/flutter/files/profile.md b/fr-ca/articles/quickstart/native/flutter/files/profile.md new file mode 100644 index 0000000000..37883b3fa3 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/files/profile.md @@ -0,0 +1,26 @@ +--- +name: profile_view.dart +language: dart +--- + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:flutter/material.dart'; + +class ProfileView extends StatelessWidget { + const ProfileView({Key? key, required this.user}) : super(key: key); + + final UserProfile user; + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (user.name != null) Text(user.name!), + if (user.email != null) Text(user.email!) + ], + ); + } +} +``` diff --git a/fr-ca/articles/quickstart/native/flutter/index.yml b/fr-ca/articles/quickstart/native/flutter/index.yml new file mode 100644 index 0000000000..c09ff74e18 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/index.yml @@ -0,0 +1,55 @@ +title: Flutter +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/flutter.jpeg +logo_name: flutter +logo: flutter +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - flutter +language: + - Dart +framework: + - Flutter +sdk: + name: auth0-flutter + url: https://www.github.com/auth0/auth0-flutter/ + logo: flutter +hybrid: true +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: flutter +default_article: 01-login +articles: + - 01-login +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-flutter-samples + branch: main +requirements: + - Flutter 3+ + - Android API 21+ and Android Studio 4+ (for Android) + - iOS 13+ and Xcode 14+ (for iOS) + - macOS 11+ and Xcode 14+ (for macOS) +next_steps: + - path: interactive + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about Actions + icon: 345 + href: '/customize/actions' diff --git a/fr-ca/articles/quickstart/native/flutter/interactive.md b/fr-ca/articles/quickstart/native/flutter/interactive.md new file mode 100644 index 0000000000..8735a35d88 --- /dev/null +++ b/fr-ca/articles/quickstart/native/flutter/interactive.md @@ -0,0 +1,171 @@ +--- +title: Add login to your Flutter app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Android, iOS, or macOS Flutter app using the Auth0 Flutter SDK +budicon: 448 +topics: + - quickstarts + - native + - flutter + - dart + - ios + - macos + - android +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/build + - files/main + - files/profile +github: + path: sample +--- + +# Add Login to Your Flutter Application + +Auth0 allows you to quickly add authentication and access user profile information in your app. This guide demonstrates how to integrate Auth0 with a Flutter app using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter). + +:::note +The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS. +::: + +This quickstart assumes you already have a [Flutter](https://flutter.dev/) app up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app. + +You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli). + +<%= include('_configure_urls_interactive') %> + +## Install the Auth0 Flutter SDK + +Add the Auth0 Flutter SDK into the project: + +```shell +flutter pub add auth0_flutter +``` + +## Configure Android {{{ data-action=code data-code="app/build.gradle#11" }}} + +If you are not developing for the Android platform, skip this step. + +The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set the Auth0 tenant domain and the callback URL scheme. + +[The sample](https://github.com/auth0-samples/auth0-flutter-samples/tree/main/sample/android) uses the following placeholders: + +- `auth0Domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under your **Application Settings** in the Domain field. If you are using a custom domain, you should set this to the value of your custom domain instead. +- `auth0Scheme`: The scheme to use. Can be a custom scheme, or `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking). + +:::note +You do not need to declare a specific `intent-filter` for your activity because you defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values. The library handles the redirection for you. +::: + +Run **Sync Project with Gradle Files** inside Android Studio to apply your changes. + +## Configure iOS/macOS + +If you are not developing for the iOS or macOS platforms, skip this step. + +::: warning +This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead. +::: + +### Configure the Team ID and bundle identifier + +Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier. + +

Screenshot of the iOS section inside the Auth0 application settings page

+ +This will add your app to your Auth0 tenant's `apple-app-site-association` file. + +### Add the associated domain capability + +Open your app in Xcode by running `open ios/Runner.xcworkspace` (or `open macos/Runner.xcworkspace` for macOS). Go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of the **Runner** target settings, and press the **+ Capability** button. Then select **Associated Domains**. + +

Screenshot of the capabilities library inside Xcode

+ +Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**: + +```text +webcredentials:${account.namespace} +``` + +If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page. + +::: note +For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application. +::: + +## Add login to your application {{{ data-action="code" data-code="main_view.dart#29:40" }}} + +[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your app. We recommend using it for the best experience, best security, and the fullest array of features. + +Integrate Auth0 Universal Login in your Flutter app by using the `Auth0` class. Redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens. + +**Android**: if you are using a custom scheme, pass this scheme to the login method so that the SDK can route to the login page and back again correctly: + +```dart +await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login(); +``` + +When a user logs in, they are redirected back to your app. Then, you are able to access the ID and access tokens for this user. + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `webAuthentication().login()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your app. + +Verify that you can get access to the tokens on the result of calling `login`. +::: + +:::checkpoint-failure +If your app did not launch successfully: + +- Ensure you set the Allowed Callback URLs are correct +- Verify you saved your changes after entering your URLs +- Make sure the domain and client ID values are imported correctly +- If using Android, ensure that the manifest placeholders have been set up correctly, otherwise the redirect back to your app may not work + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="main_view.dart#45:55"}}} + +To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `webAuthentication().logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout). + +**Android**: if you are using a custom scheme, pass this scheme to the logout method so that the SDK can route back to your app correctly: + +``` +await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout(); +``` + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `webAuthentication().logout()` and logs the user out of your app. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your app. +::: + +:::checkpoint-failure +If your app did not log out successfully: + +- Ensure the Allowed Logout URLs are set properly +- Verify you saved your changes after entering your URLs + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Show user profile information {{{ data-action="code" data-code="profile_view.dart" }}} + +The user profile automatically retrieves user profile properties for you when you call `webAuthentication().login()`. The returned object from the login step contains a `user` property with all the user profile properties, which populates by decoding the ID token. + +::::checkpoint +:::checkpoint-default +Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`. +::: +:::checkpoint-failure +If your app did not return user profile information: + +- Verify the access token is valid + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/native/ionic-angular/01-login.md b/fr-ca/articles/quickstart/native/ionic-angular/01-login.md new file mode 100644 index 0000000000..e6f6e8c374 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/01-login.md @@ -0,0 +1,255 @@ +--- +title: Login +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Angular & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - angular + - capacitor +github: + path: angular +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/_getting_started', { library: 'Ionic' }) %> + +<%= include('../_includes/ionic/_configure_urls') %> + +<%= include('../../_includes/_auth0-angular-install') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +### Configure your App module + +The SDK exports `AuthModule`, a module that contains all the services required for the SDK to function. To register this with your application: + +- Open the `app.module.ts` file +- Import the `AuthModule` type from the `@auth0/auth0-angular` package +- Add `AuthModule` to the application by calling `AuthModule.forRoot` and adding to your application module's `imports` array +- Specify the configuration for the Auth0 Angular SDK + +```javascript +// Import the types from the SDK +import { AuthModule } from '@auth0/auth0-angular'; +import config from '../../capacitor.config'; + +// .. + +// Build the URL that Auth0 should redirect back to +const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +// Register AuthModule with your AppModule +@NgModule({ + declarations: [AppComponent], + entryComponents: [], + imports: [ + BrowserModule, + IonicModule.forRoot(), + AppRoutingModule, + AuthModule.forRoot({ + domain: "${account.namespace}", + clientId: "${account.clientId}", + useRefreshTokens: true, + useRefreshTokensFallback: false, + authorizationParams: { + redirect_uri, + } + }), + ], + providers: [{ provide: RouteReuseStrategy, useClass: IonicRouteStrategy }], + bootstrap: [AppComponent], +}) +``` + +The `AuthModule.forRoot` function takes the following configuration: + +- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains) +- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard +- `useRefreshTokens`: To use auth0-angular with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-angular with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +:::panel Checkpoint +Now that you have configured your app with the Auth0 Angular SDK, run your application to verify that the SDK is initializing without error and that your application runs as it did before. +::: + +## Add Login to Your Application + +<%= include('../_includes/ionic/_add_login_intro') %> + +Add a new `LoginButton` component to your application with the following code: + +```js +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { Browser } from '@capacitor/browser'; +import { mergeMap } from 'rxjs/operators'; + +@Component({ + selector: 'app-login-button', + template: `Login`, +}) +export class LoginButtonComponent { + constructor(public auth: AuthService) {} + + login() { + this.auth + .loginWithRedirect({ + async openUrl(url: string) { + await Browser.open({ url, windowName: '_self' }); + } + }) + .subscribe(); + } +} +``` + +This component: + +- defines a template with a simple button that logs the user in when clicked +- uses `loginWithRedirect` to login using Auth0's Universal Login page +- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user + +### Handling the callback + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +Modify your `App` component and use the `ngOnInit` method to handle the callback from Auth0. + +```js +import { Component, OnInit, NgZone } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { mergeMap } from 'rxjs/operators'; +import { Browser } from '@capacitor/browser'; +import { App } from '@capacitor/app'; + +const callbackUri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +@Component({ + selector: 'app-root', + templateUrl: 'app.component.html', + styleUrls: ['app.component.scss'], +}) +export class AppComponent implements OnInit { + // Import the AuthService module from the Auth0 Angular SDK + constructor(public auth: AuthService, private ngZone: NgZone) {} + + ngOnInit(): void { + // Use Capacitor's App plugin to subscribe to the `appUrlOpen` event + App.addListener('appUrlOpen', ({ url }) => { + // Must run inside an NgZone for Angular to pick up the changes + // https://capacitorjs.com/docs/guides/angular + ngZone.run(() => { + if (url?.startsWith(callbackUri)) { + // If the URL is an authentication callback URL.. + if ( + url.includes('state=') && + (url.includes('error=') || url.includes('code=')) + ) { + // Call handleRedirectCallback and close the browser + this.auth + .handleRedirectCallback(url) + .pipe(mergeMap(() => Browser.close())) + .subscribe(); + } else { + Browser.close(); + } + } + }); + }); + } +} +``` + +Note that the `appUrlOpen` event callback is wrapped in `ngZone.run`, which means that the changes to observables that occur when `handleRedirectCallback` runs are picked up by the Angular app. Please read [Using Angular with Capacitor](https://capacitorjs.com/docs/guides/angular) for more details. Otherwise, the screen will not update to show the authenticated state after you log in. + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +:::panel Checkpoint +Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects you back to your application. +::: + +## Add Logout to Your Application + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +Create a new `LogoutButton` component and add the following code to the file. Then, add the `LogoutButton` component to your app. + +```js +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { Browser } from '@capacitor/browser'; +import { tap } from 'rxjs/operators'; + +// Build the URL to return back to your app after logout +const returnTo = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +@Component({ + selector: 'app-logout-button', + template: `Log out`, +}) +export class LogoutButtonComponent { + // Import the AuthService module from the Auth0 Angular SDK + constructor(public auth: AuthService) {} + + logout() { + this.auth + .logout({ + logoutParams: { + returnTo, + }, + async openUrl(url: string) { + await Browser.open({ url }); + } + }) + .subscribe(); + } +} +``` + +:::panel Checkpoint +Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +The Auth0 SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` property exposed by `AuthService`. + +Create a new component `Profile`, and use the following code to display user profile information in your app. + +```js +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-profile', + template: ` +
+ + + +

{{ user.name }}

+

{{ user.email }}

+
`, +}) +export class ProfileComponent { + constructor(public auth: AuthService) {} +} + +``` + +:::panel Checkpoint +Add `ProfileComponent` to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in. +::: diff --git a/fr-ca/articles/quickstart/native/ionic-angular/download.md b/fr-ca/articles/quickstart/native/ionic-angular/download.md new file mode 100644 index 0000000000..83a60e3629 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/download.md @@ -0,0 +1,37 @@ + + +To run the sample follow these steps: + +1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +3) Add the following to **Allowed Origins (CORS)** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +capacitor://localhost, http://localhost +``` + +4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed. + +5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory: + +```bash +npm install +npm run build + +# to test it in iOS +npx cap run ios +# to test it in Android +npx cap run android +``` + +Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site. diff --git a/fr-ca/articles/quickstart/native/ionic-angular/files/app-component.md b/fr-ca/articles/quickstart/native/ionic-angular/files/app-component.md new file mode 100644 index 0000000000..7923e1cbd0 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/files/app-component.md @@ -0,0 +1,49 @@ +--- +name: app.component.ts +language: javascript +--- + +```javascript +import { Component, OnInit, NgZone } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { mergeMap } from 'rxjs/operators'; +import { Browser } from '@capacitor/browser'; +import { App } from '@capacitor/app'; + +const callbackUri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +@Component({ + selector: 'app-root', + templateUrl: 'app.component.html', + styleUrls: ['app.component.scss'], +}) +export class AppComponent implements OnInit { + // Import the AuthService module from the Auth0 Angular SDK + constructor(public auth: AuthService, private ngZone: NgZone) {} + + ngOnInit(): void { + // Use Capacitor's App plugin to subscribe to the `appUrlOpen` event + App.addListener('appUrlOpen', ({ url }) => { + // Must run inside an NgZone for Angular to pick up the changes + // https://capacitorjs.com/docs/guides/angular + ngZone.run(() => { + if (url?.startsWith(callbackUri)) { + // If the URL is an authentication callback URL.. + if ( + url.includes('state=') && + (url.includes('error=') || url.includes('code=')) + ) { + // Call handleRedirectCallback and close the browser + this.auth + .handleRedirectCallback(url) + .pipe(mergeMap(() => Browser.close())) + .subscribe(); + } else { + Browser.close(); + } + } + }); + }); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-angular/files/app-module.md b/fr-ca/articles/quickstart/native/ionic-angular/files/app-module.md new file mode 100644 index 0000000000..37b7db07fe --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/files/app-module.md @@ -0,0 +1,37 @@ +--- +name: app.module.ts +language: javascript +--- + +```javascript +// Import the types from the SDK +import { AuthModule } from '@auth0/auth0-angular'; +import config from '../../capacitor.config'; + +// .. + +// Build the URL that Auth0 should redirect back to +const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +// Register AuthModule with your AppModule +@NgModule({ + declarations: [AppComponent], + entryComponents: [], + imports: [ + BrowserModule, + IonicModule.forRoot(), + AppRoutingModule, + AuthModule.forRoot({ + domain: "${account.namespace}", + clientId: "${account.clientId}", + useRefreshTokens: true, + useRefreshTokensFallback: false, + authorizationParams: { + redirect_uri + } + }), + ], + providers: [{ provide: RouteReuseStrategy, useClass: IonicRouteStrategy }], + bootstrap: [AppComponent], +}) +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-angular/files/login-button.md b/fr-ca/articles/quickstart/native/ionic-angular/files/login-button.md new file mode 100644 index 0000000000..dc3616f928 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/files/login-button.md @@ -0,0 +1,29 @@ +--- +name: login-button.ts +language: javascript +--- + +```javascript +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { Browser } from '@capacitor/browser'; +import { mergeMap } from 'rxjs/operators'; + +@Component({ + selector: 'app-login-button', + template: `Login`, +}) +export class LoginButtonComponent { + constructor(public auth: AuthService) {} + + login() { + this.auth + .loginWithRedirect({ + async openUrl(url: string) { + await Browser.open({ url, windowName: '_self' }); + } + }) + .subscribe(); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-angular/files/logout-button.md b/fr-ca/articles/quickstart/native/ionic-angular/files/logout-button.md new file mode 100644 index 0000000000..21ad6aad68 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/files/logout-button.md @@ -0,0 +1,36 @@ +--- +name: logout-button.ts +language: javascript +--- + +```javascript +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { Browser } from '@capacitor/browser'; +import { tap } from 'rxjs/operators'; + +// Build the URL to return back to your app after logout +const returnTo = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +@Component({ + selector: 'app-logout-button', + template: `Log out`, +}) +export class LogoutButtonComponent { + // Import the AuthService module from the Auth0 Angular SDK + constructor(public auth: AuthService) {} + + logout() { + this.auth + .logout({ + logoutParams: { + returnTo, + }, + async openUrl(url: string) { + await Browser.open({ url }); + } + }) + .subscribe(); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-angular/files/user-profile.md b/fr-ca/articles/quickstart/native/ionic-angular/files/user-profile.md new file mode 100644 index 0000000000..96be742cdd --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/files/user-profile.md @@ -0,0 +1,24 @@ +--- +name: user-profile.ts +language: javascript +--- + +```javascript +import { Component, OnInit } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-profile', + template: ` +
+ + + +

{{ user.name }}

+

{{ user.email }}

+
`, +}) +export class ProfileComponent { + constructor(public auth: AuthService) {} +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-angular/index.yml b/fr-ca/articles/quickstart/native/ionic-angular/index.yml new file mode 100644 index 0000000000..8eac1d65b1 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/index.yml @@ -0,0 +1,55 @@ +title: Ionic & Capacitor (Angular) +# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'. +image: /media/platforms/ionic.jpeg +logo_name: ionic +logo: ionic +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - ionic + - angular + - capacitor + - auth0-angular +language: + - Typescript +framework: + - Ionic + - Capacitor + - Angular +hybrid: true +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: ionic-angular +default_article: 01-login +hidden_articles: + - interactive +articles: + - 01-login +show_steps: true +github: + org: auth0-samples + repo: auth0-ionic-samples + branch: main +requirements: + - Node & Npm (LTS) + - XCode 12+ (for iOS) + - Android Studio 4+ (for Android) +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about rules + icon: 345 + href: '/rules' diff --git a/fr-ca/articles/quickstart/native/ionic-angular/interactive.md b/fr-ca/articles/quickstart/native/ionic-angular/interactive.md new file mode 100644 index 0000000000..c6db4b0e82 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-angular/interactive.md @@ -0,0 +1,135 @@ +--- +title: Add login to your Ionic Angular with Capacitor app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Angular & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - angular + - capacitor +github: + path: angular +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/app-module + - files/app-component + - files/login-button + - files/logout-button + - files/user-profile +--- + +# Add Login to Your Ionic Angular with Capacitor Application + +Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (Angular) & Capacitor application using the [Auth0 Angular SDK](https://github.com/auth0/auth0-angular). + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/ionic/_configure_urls_interactive') %> + +<%= include('../../_includes/_auth0-angular-install.md') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +## Register and configure the authentication module {{{ data-action=code data-code="app.module.ts" }}} + +The SDK exports `AuthModule`, a module that contains all the services required for the SDK to function. This module should be registered with your application and be configured with your Auth0 domain and Client ID. + +The `AuthModule.forRoot` function takes the following configuration: + +- `domain`: The `domain` value present under the **Settings** of the application you created in the Auth0 Dashboard, or your custom domain if you are using Auth0's [custom domains feature](http://localhost:3000/docs/custom-domains). +- `clientId`: The Client ID value present under the **Settings** of the application you created in the Auth0 Dashboard. +- `useRefreshTokens`: To use auth0-angular with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-angular with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +::::checkpoint +:::checkpoint-default +Now that you have configured your app with the Auth0 Angular SDK, run your application to verify that the SDK is initializing without error, and that your application runs as it did before. +::: +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* ensure the correct application is selected +* did you save after entering your URLs? +* make sure the domain and Client ID imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add login to your application {{{ data-action=code data-code="login-button.ts" }}} + +<%= include('../_includes/ionic/_add_login_intro') %> + +::::checkpoint +::: checkpoint-default +The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors. +::: + +::: checkpoint-failure +Sorry about that. Here's a couple things to double check: + +* ensure that there are no errors in the browser's console window at the point of login +* ensure the domain and Client ID are correct according to your Auth0 application in the Dashboard +* if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure +::: +:::: + +## Handling the login callback {{{ data-action=code data-code="app.component.ts" }}} + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +Note that the `appUrlOpen` event callback is wrapped in `ngZone.run`. Changes to observables that occur when `handleRedirectCallback` runs are picked up by the Angular app. To learn more, read [Using Angular with Capacitor](https://capacitorjs.com/docs/guides/angular). Otherwise, the screen doesn't update to show the authenticated state after log in. + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +::::checkpoint +:::checkpoint-default +Add the `appUrlOpen` to your application's `App` component and log in. The browser window should close once the user authenticates and logs in to your app. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +* check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) for Android +* if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the error code +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="logout-button.ts" }}} + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +::::checkpoint +:::checkpoint-default +Provide a way for your users to log out of your application. Verify the redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Make sure users are no longer logged in to your application. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +* check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard +::: +:::: + +## Show the user profile {{{ data-action=code data-code="user-profile.ts" }}} + +The Auth0 SDK retrieves the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` property exposed by `AuthService`. + +::::checkpoint +:::checkpoint-default +Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +* check that you are only reading the user's profile when `isLoading` is `false` +* check that `user` resolves to an object and is not `undefined` +::: +:::: diff --git a/fr-ca/articles/quickstart/native/ionic-react/01-login.md b/fr-ca/articles/quickstart/native/ionic-react/01-login.md new file mode 100644 index 0000000000..1dd8536765 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/01-login.md @@ -0,0 +1,228 @@ +--- +title: Login +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - react + - capacitor +github: + path: react +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/_getting_started', { library: 'Ionic' }) %> + +<%= include('../_includes/ionic/_configure_urls') %> + +<%= include('../../_includes/_auth0-react-install.md') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +### Configure the `Auth0Provider` component + +Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK. + +Open `src/index.tsx` and wrap the `App` component in the `Auth0Provider` component. + +```javascript +import React from 'react'; +import { createRoot } from 'react-dom/client'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +const root = createRoot(document.getElementById('root')); + +root.render( + + + +); +``` + +The `Auth0Provider` component takes the following props: + +- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains) +- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard +- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +:::panel Checkpoint +Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0. +::: + +## Add Login to Your Application + +<%= include('../_includes/ionic/_add_login_intro') %> + +Add a new file `LoginButton.tsx` with the following code: + +```js +import { useAuth0 } from '@auth0/auth0-react'; +import { Browser } from '@capacitor/browser'; +import { IonButton } from '@ionic/react'; + +const LoginButton: React.FC = () => { + const { loginWithRedirect } = useAuth0(); + + const login = async () => { + await loginWithRedirect({ + async openUrl(url) { + // Redirect using Capacitor's Browser plugin + await Browser.open({ + url, + windowName: "_self" + }); + } + }); + }; + + return Log in; +}; + +export default LoginButton; +``` + +This component: + +- defines a template with a simple button that logs the user in when clicked +- uses `loginWithRedirect` to login using Auth0's Universal Login page +- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user + +<%= include('../../_includes/_auth0-react-classes-info.md') %> + +### Handling the callback + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +Add the following `useEffect` hook to your main `App` component: + +```js +// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`, +// as well as the bits needed for Auth0 and React +import { App as CapApp } from '@capacitor/app'; +import { Browser } from '@capacitor/browser'; +import { useEffect } from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +// ... + +const App: React.FC = () => { + // Get the callback handler from the Auth0 React hook + const { handleRedirectCallback } = useAuth0(); + + useEffect(() => { + // Handle the 'appUrlOpen' event and call `handleRedirectCallback` + CapApp.addListener('appUrlOpen', async ({ url }) => { + if (url.includes('state') && (url.includes('code') || url.includes('error'))) { + await handleRedirectCallback(url); + } + // No-op on Android + await Browser.close(); + }); + }, [handleRedirectCallback]); + + // .. +}; +``` + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +:::panel Checkpoint +Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects you back to your application. +::: + +## Add Logout to Your Application + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +Create a new file `LogoutButton.tsx` and add the following code to the file. Then, add the `LogoutButton` component to your app. + +```js +import { useAuth0 } from '@auth0/auth0-react'; +import { Browser } from '@capacitor/browser'; +import { IonButton } from '@ionic/react'; + +// This should reflect the URL added earlier to your "Allowed Logout URLs" setting +// in the Auth0 dashboard. +const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback'; + +const LogoutButton: React.FC = () => { + const { logout } = useAuth0(); + + const doLogout = async () => { + await logout({ + logoutParams: { + returnTo: logoutUri, + }, + async openUrl(url) { + // Redirect using Capacitor's Browser plugin + await Browser.open({ + url, + windowName: "_self" + }); + } + }); + }; + + return Log out; +}; + +export default LogoutButton; +``` + +:::panel Checkpoint +Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it: + +```js +import { useAuth0 } from '@auth0/auth0-react'; + +const Profile: React.FC = () => { + const { user, isLoading } = useAuth0(); + + // If the SDK is not ready, or a user is not authenticated, exit. + if (isLoading || !user) return null; + + return ( +
+ {user.name} +

{user.name}

+

{user.email}

+
+ ); +}; + +export default Profile; +``` + +The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`. + +:::panel Checkpoint +Add the `Profile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in. +::: diff --git a/fr-ca/articles/quickstart/native/ionic-react/download.md b/fr-ca/articles/quickstart/native/ionic-react/download.md new file mode 100644 index 0000000000..dc7d46dcf4 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/download.md @@ -0,0 +1,37 @@ + + +To run the sample follow these steps: + +1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +capacitor://localhost, http://localhost +``` + +4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed. + +5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory: + +```bash +npm install +npm run build + +# to test it in iOS +npx cap run ios +# to test it in Android +npx cap run android +``` + +Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site. diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/app.md b/fr-ca/articles/quickstart/native/ionic-react/files/app.md new file mode 100644 index 0000000000..4933e1a6de --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/files/app.md @@ -0,0 +1,33 @@ +--- +name: app.tsx +language: javascript +--- + +```javascript +// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`, +// as well as the bits needed for Auth0 and React +import { App as CapApp } from '@capacitor/app'; +import { Browser } from '@capacitor/browser'; +import { useEffect } from 'react'; +import { useAuth0 } from '@auth0/auth0-react'; + +// ... + +const App: React.FC = () => { + // Get the callback handler from the Auth0 React hook + const { handleRedirectCallback } = useAuth0(); + + useEffect(() => { + // Handle the 'appUrlOpen' event and call `handleRedirectCallback` + CapApp.addListener('appUrlOpen', async ({ url }) => { + if (url.includes('state') && (url.includes('code') || url.includes('error'))) { + await handleRedirectCallback(url); + } + // No-op on Android + await Browser.close(); + }); + }, [handleRedirectCallback]); + + // .. +}; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/index.md b/fr-ca/articles/quickstart/native/ionic-react/files/index.md new file mode 100644 index 0000000000..762a3d2f70 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/files/index.md @@ -0,0 +1,27 @@ +--- +name: index.tsx +language: javascript +--- + +```javascript +import React from 'react'; +import { createRoot } from 'react-dom/client'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +const root = createRoot(document.getElementById('root')); + +root.render( + + + +); +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/login-button.md b/fr-ca/articles/quickstart/native/ionic-react/files/login-button.md new file mode 100644 index 0000000000..563b1ee5af --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/files/login-button.md @@ -0,0 +1,30 @@ +--- +name: login-button.tsx +language: javascript +--- + +```javascript +import { useAuth0 } from '@auth0/auth0-react'; +import { Browser } from '@capacitor/browser'; +import { IonButton } from '@ionic/react'; + +const LoginButton: React.FC = () => { + const { loginWithRedirect } = useAuth0(); + + const login = async () => { + await loginWithRedirect({ + async openUrl(url) { + // Redirect using Capacitor's Browser plugin + await Browser.open({ + url, + windowName: "_self" + }); + } + }); + }; + + return Log in; +}; + +export default LoginButton; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/logout-button.md b/fr-ca/articles/quickstart/native/ionic-react/files/logout-button.md new file mode 100644 index 0000000000..a4a1ceb4f1 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/files/logout-button.md @@ -0,0 +1,37 @@ +--- +name: logout-button.tsx +language: javascript +--- + +```javascript +import { useAuth0 } from '@auth0/auth0-react'; +import { Browser } from '@capacitor/browser'; +import { IonButton } from '@ionic/react'; + +// This should reflect the URL added earlier to your "Allowed Logout URLs" setting +// in the Auth0 dashboard. +const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback'; + +const LogoutButton: React.FC = () => { + const { logout } = useAuth0(); + + const doLogout = async () => { + await logout({ + logoutParams: { + returnTo: logoutUri + }, + async openUrl(url) { + // Redirect using Capacitor's Browser plugin + await Browser.open({ + url, + windowName: "_self" + }); + } + }); + }; + + return Log out; +}; + +export default LogoutButton; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/user-profile.md b/fr-ca/articles/quickstart/native/ionic-react/files/user-profile.md new file mode 100644 index 0000000000..d3d719713b --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/files/user-profile.md @@ -0,0 +1,25 @@ +--- +name: user-profile.tsx +language: javascript +--- + +```javascript +import { useAuth0 } from '@auth0/auth0-react'; + +const Profile: React.FC = () => { + const { user, isLoading } = useAuth0(); + + // If the SDK is not ready, or a user is not authenticated, exit. + if (isLoading || !user) return null; + + return ( +
+ {user.name} +

{user.name}

+

{user.email}

+
+ ); +}; + +export default Profile; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-react/index.yml b/fr-ca/articles/quickstart/native/ionic-react/index.yml new file mode 100644 index 0000000000..135bac3db8 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/index.yml @@ -0,0 +1,56 @@ +title: Ionic & Capacitor (React) +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/ionic.jpeg +logo_name: ionic +logo: ionic +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - ionic + - react + - capacitor + - auth0-react +language: + - Typescript +framework: + - Ionic + - Capacitor + - React +hybrid: true +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: ionic-react +default_article: 01-login +articles: + - 01-login +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-ionic-samples + branch: main +requirements: + - Node & Npm (LTS) + - XCode 12+ (for iOS) + - Android Studio 4+ (for Android) + - React 18 +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about rules + icon: 345 + href: '/rules' diff --git a/fr-ca/articles/quickstart/native/ionic-react/interactive.md b/fr-ca/articles/quickstart/native/ionic-react/interactive.md new file mode 100644 index 0000000000..c983cb56e2 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-react/interactive.md @@ -0,0 +1,137 @@ +--- +title: Add login to your Ionic React with Capacitor app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - react + - capacitor +github: + path: react +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/index + - files/login-button + - files/logout-button + - files/app + - files/user-profile +--- + +# Add login to your Ionic React with Capacitor app + +Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (React) & Capacitor application using the [Auth0 React SDK](https://github.com/auth0/auth0-react). + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/ionic/_configure_urls_interactive') %> + +<%= include('../../_includes/_auth0-react-install.md') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +## Configure the `Auth0Provider` component {{{ data-action=code data-code="index.tsx" }}} + +Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` you can import from the SDK. + +The `Auth0Provider` component takes the following props: + +- `domain`: The `domain` value present under the **Settings** of the application you created in your Auth0 Dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains). +- `clientId`: The Client ID value present under the **Settings** of the application you created in your Auth0 Dashboard. +- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +:::: checkpoint +:::checkpoint-default +Add the `Auth0Provider` component in a way that wraps your `App` component, then run your application to verify that the SDK is initializing correctly and your application is not throwing any errors related to Auth0. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- ensure the correct application is selected +- did you save after entering your URLs? +- make sure the domain and Client ID imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add login to your application {{{ data-action=code data-code="login-button.tsx" }}} + +<%= include('../_includes/ionic/_add_login_intro') %> + +::::checkpoint +::: checkpoint-default +The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors. +::: + +::: checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- ensure that there are no errors in the browser's console window at the point of login +- ensure the domain and Client ID are correct according to your Auth0 application in the dashboard +- if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure + ::: + :::: + +## Handle the login callback {{{ data-action=code data-code="app.tsx" }}} + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +::::checkpoint +:::checkpoint-default +Add the `appUrlOpen` to your application's `App` component and log in. The browser window should close once the user authenticates and logs in to your app. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) on Android +- if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the reason for the error + ::: + :::: + +## Add logout to your application {{{ data-action=code data-code="logout-button.tsx" }}} + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +::::checkpoint +:::checkpoint-default +Provide a way for your users to log out of your application. Verify that you redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Check that you are no longer logged in to your application. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard + ::: + :::: + +## Show the user profile {{{ data-action=code data-code="user-profile.tsx" }}} + +The Auth0 React SDK retrieves the [user's profile](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. + +Initializing the SDK is asynchronous, and you should guard the user profile by checking the `isLoading` and `user` properties. Once `isLoading` is `false` and `user` has a value, the user profile can be used. + +::::checkpoint +:::checkpoint-default +Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that you are only reading the user's profile when `isLoading` is `false` +- check that `user` resolves to an object and is not `undefined` + ::: + :::: diff --git a/fr-ca/articles/quickstart/native/ionic-vue/01-login.md b/fr-ca/articles/quickstart/native/ionic-vue/01-login.md new file mode 100644 index 0000000000..f29168389b --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/01-login.md @@ -0,0 +1,271 @@ +--- +title: Login +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - vue + - capacitor +github: + path: vue +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/_getting_started', { library: 'Ionic' }) %> + +<%= include('../_includes/ionic/_configure_urls') %> + +<%= include('../../_includes/_auth0-vue-install.md') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +### Configure the `createAuth0` plugin + +The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. To register this with your application: + +Open `src/main.ts` and install the plugin using `app.use` + +```javascript +import { createApp } from "vue"; +import App from "./App.vue"; +import router from "./router"; + +import { IonicVue } from "@ionic/vue"; + +import { createAuth0 } from "@auth0/auth0-vue"; +import config from "./auth.config"; + +// .. + +// Build the URL that Auth0 should redirect back to +const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +const app = createApp(App).use(IonicVue).use(router); + +app.use( + createAuth0({ + domain: "${account.namespace}", + clientId: "${account.clientId}", + useRefreshTokens: true, + useRefreshTokensFallback: false, + authorizationParams: { + redirect_uri + } + }) +); + +router.isReady().then(() => { + app.mount("#app"); +}); +``` + +The `createAuth0` plugin takes the following props: + +- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains) +- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard +- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +:::panel Checkpoint +Now that you have configured `createAuth0` plugin, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0. +::: + +## Add Login to Your Application + +<%= include('../_includes/ionic/_add_login_intro') %> + +Add a new file `LoginButton.vue` with the following code: + +```html + + + +``` + +This component: + +- defines a template with a simple button that logs the user in when clicked +- uses `loginWithRedirect` to login using Auth0's Universal Login page +- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user + +### Handling the callback + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +Add the following capacitor application listener to your main `App` component: + +```html + + + +``` + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +:::panel Checkpoint +Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects you back to your application. +::: + +## Add Logout to Your Application + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +Create a new file `LogoutButton.vue` and add the following code to the file. Then, add the `LogoutButton` component to your app. + +```html + + + +``` + +:::panel Checkpoint +Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +The Auth0 Vue SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable. Take this `UserProfile` component as an example of how to use it: + +```html + + + +``` + +The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before Vue renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`. + +:::panel Checkpoint +Add the `UserProfile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in. +::: diff --git a/fr-ca/articles/quickstart/native/ionic-vue/download.md b/fr-ca/articles/quickstart/native/ionic-vue/download.md new file mode 100644 index 0000000000..a0589fcf12 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/download.md @@ -0,0 +1,38 @@ + + +To run the sample follow these steps: + +1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback +``` + +3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) + +```text +capacitor://localhost, http://localhost +``` + +4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed. + +5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory: + +```bash +npm install +npm run build + +# to test it in iOS +npx cap run ios + +# to test it in Android +npx cap run android +``` + +Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site. diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/app.md b/fr-ca/articles/quickstart/native/ionic-vue/files/app.md new file mode 100644 index 0000000000..b8129bb76a --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/files/app.md @@ -0,0 +1,45 @@ +--- +name: App.vue +language: html +--- + +```html + + + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/login-button.md b/fr-ca/articles/quickstart/native/ionic-vue/files/login-button.md new file mode 100644 index 0000000000..a18deea1df --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/files/login-button.md @@ -0,0 +1,40 @@ +--- +name: LoginButton.vue +language: html +--- + +```html + + + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/logout-button.md b/fr-ca/articles/quickstart/native/ionic-vue/files/logout-button.md new file mode 100644 index 0000000000..43940c7d70 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/files/logout-button.md @@ -0,0 +1,44 @@ +--- +name: LogoutButton.vue +language: html +--- + +```html + + + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/main.md b/fr-ca/articles/quickstart/native/ionic-vue/files/main.md new file mode 100644 index 0000000000..9585448275 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/files/main.md @@ -0,0 +1,38 @@ +--- +name: main.ts +language: javascript +--- + +```javascript +import { createApp } from "vue"; +import App from "./App.vue"; +import router from "./router"; + +import { IonicVue } from "@ionic/vue"; + +import { createAuth0 } from "@auth0/auth0-vue"; +import config from "./auth.config"; + +// .. + +// Build the URL that Auth0 should redirect back to +const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`; + +const app = createApp(App).use(IonicVue).use(router); + +app.use( + createAuth0({ + domain: "${account.namespace}", + clientId: "${account.clientId}", + useRefreshTokens: true, + useRefreshTokensFallback: false, + authorizationParams: { + redirect_uri + } + }) +); + +router.isReady().then(() => { + app.mount("#app"); +}); +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/user-profile.md b/fr-ca/articles/quickstart/native/ionic-vue/files/user-profile.md new file mode 100644 index 0000000000..e0c6f390ea --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/files/user-profile.md @@ -0,0 +1,35 @@ +--- +name: UserProfile.vue +language: html +--- + +```html + + + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/ionic-vue/index.yml b/fr-ca/articles/quickstart/native/ionic-vue/index.yml new file mode 100644 index 0000000000..52cbadde94 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/index.yml @@ -0,0 +1,55 @@ +title: Ionic & Capacitor (Vue) +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/ionic.jpeg +logo_name: ionic +logo: ionic +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - ionic + - vue + - capacitor + - auth0-vue +language: + - Typescript +framework: + - Ionic + - Capacitor + - Vue +hybrid: true +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: ionic-vue +default_article: 01-login +articles: + - 01-login +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-ionic-samples + branch: main +requirements: + - Node & Npm (LTS) + - XCode 12+ (for iOS) + - Android Studio 4+ (for Android) +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about rules + icon: 345 + href: '/rules' diff --git a/fr-ca/articles/quickstart/native/ionic-vue/interactive.md b/fr-ca/articles/quickstart/native/ionic-vue/interactive.md new file mode 100644 index 0000000000..6227d5b364 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ionic-vue/interactive.md @@ -0,0 +1,137 @@ +--- +title: Add login to your Ionic Vue with Capacitor app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application. +budicon: 448 +topics: + - quickstarts + - native + - ionic + - vue + - capacitor +github: + path: vue +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/main + - files/login-button + - files/logout-button + - files/app + - files/user-profile +--- + +# Add login to your Ionic Vue with Capacitor app + +Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (Vue) & Capacitor application using the [Auth0 Vue SDK](https://github.com/auth0/auth0-vue). + +<%= include('../_includes/ionic/_article_intro') %> + +<%= include('../_includes/ionic/_configure_urls_interactive') %> + +<%= include('../../_includes/_auth0-vue-install.md') %> + +<%= include('../_includes/ionic/_install_plugins') %> + +## Configure the `createAuth0` plugin {{{ data-action=code data-code="main.ts" }}} + +The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. This composable should be registered with your application and be configured with your Auth0 domain and Client ID. + +The `createAuth0` composable takes the following configuration: + +- `domain`: The `domain` value present under the **Settings** of the application you created in the Auth0 Dashboard, or your custom domain if you are using Auth0's [custom domains feature](http://localhost:3000/docs/custom-domains). +- `clientId`: The Client ID value present under the **Settings** of the application you created in the Auth0 Dashboard. +- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens. +- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback. +- `authorizationParams.redirect_uri`: The URL to redirect your users after they authenticate with Auth0. + +<%= include('../_includes/ionic/_note_storage') %> + +:::: checkpoint +:::checkpoint-default +Now that you have configured your app with the Auth0 Vue SDK, run your application to verify that the SDK is initializing without error, and that your application runs as it did before. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- ensure the correct application is selected +- did you save after entering your URLs? +- make sure the domain and Client ID imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add login to your application {{{ data-action=code data-code="LoginButton.vue" }}} + +<%= include('../_includes/ionic/_add_login_intro') %> + +::::checkpoint +::: checkpoint-default +The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors. +::: + +::: checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- ensure that there are no errors in the browser's console window at the point of login +- ensure the domain and Client ID are correct according to your Auth0 application in the dashboard +- if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure + ::: + :::: + +## Handle the login callback {{{ data-action=code data-code="App.vue" }}} + +<%= include('../_includes/ionic/_handle_callback_intro') %> + +<%= include('../_includes/ionic/_note_custom_schemes') %> + +::::checkpoint +:::checkpoint-default +Add the `appUrlOpen` to your application's `App` component setup and log in. The browser window should close once the user authenticates and logs in to your app. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) on Android +- if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the reason for the error + ::: + :::: + +## Add logout to your application {{{ data-action=code data-code="LogoutButton.vue" }}} + +<%= include('../_includes/ionic/_add_logout_intro.md') %> + +::::checkpoint +:::checkpoint-default +Provide a way for your users to log out of your application. Verify that you redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Check that you are no longer logged in to your application. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard + ::: + :::: + +## Show the user profile {{{ data-action=code data-code="UserProfile.vue" }}} + +The Auth0 Vue SDK retrieves the [user's profile](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable. + +Initializing the SDK is asynchronous, and you should guard the user profile by checking the `isLoading` and `user` properties. Once `isLoading` is `false` and `user` has a value, the user profile can be used. + +::::checkpoint +:::checkpoint-default +Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- check that you are only reading the user's profile when `isLoading` is `false` +- check that `user` resolves to an object and is not `undefined` + ::: + :::: diff --git a/fr-ca/articles/quickstart/native/ios-swift/01-login.md b/fr-ca/articles/quickstart/native/ios-swift/01-login.md new file mode 100755 index 0000000000..24cdf22165 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/01-login.md @@ -0,0 +1,267 @@ +--- +title: Login +description: This guide demonstrates how to integrate Auth0 with any new or existing iOS / macOS app using the Auth0.swift SDK. +seo_alias: swift +budicon: 448 +topics: + - quickstarts + - native + - ios + - macos + - swift +github: + path: Sample-01 +contentType: tutorial +useCase: quickstart +--- + + + +## Configure Auth0 + +You will need a **Native** Auth0 application. If you don’t have a Native Auth0 application already, [create one](/get-started/auth0-overview/create-applications/native-apps) before continuing. Avoid using other application types, as they have different configurations and may cause errors. + +### Configure the callback and logout URLs + +The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie. + +If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error. + +::: note +On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links as callback and logout URLs. When enabled, Auth0.swift will fall back to using a custom URL scheme on older iOS / macOS versions. + +**This feature requires Xcode 15.3+ and a paid Apple Developer account**. +::: + +Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of the value from the settings page. + +#### iOS + +```text +https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback +``` + +#### macOS + +```text +https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback +``` + +For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be: + +```text +https://example.us.auth0.com/ios/com.example.MyApp/callback, +com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback +``` + +### Configure the associated domain + +::: warning +This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead. +::: + +#### Configure the Team ID and bundle identifier + +Scroll to the end of the settings page of your Auth0 application and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier. + +

Screenshot of the iOS section inside the Auth0 application settings page

+ +This will add your app to your Auth0 tenant's `apple-app-site-association` file. + +#### Add the associated domain capability + +In Xcode, go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of your app's target settings, and press the **+ Capability** button. Then select **Associated Domains**. + +

Screenshot of the capabilities library inside Xcode

+ +Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**: + +```text +webcredentials:${account.namespace} +``` + +If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page. + +::: note +For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application. +::: + +## Install the SDK + +Add the [Auth0.swift](https://github.com/auth0/Auth0.swift) SDK to your project. The library will make requests to the Auth0 Authentication and Management APIs. + +### Using the Swift Package Manager + +Open the following menu item in Xcode: + +**File > Add Package Dependencies...** + +In the **Search or Enter Package URL** search box enter this URL: + +```text +https://github.com/auth0/Auth0.swift +``` + +Then, select the dependency rule and press **Add Package**.. + +::: note +For further reference on SPM, check its [official documentation](https://developer.apple.com/documentation/xcode/adding-package-dependencies-to-your-app). +::: + +### Using Cocoapods + +Add the following line to your `Podfile`: + +```ruby +pod 'Auth0', '~> 2.0' +``` + +Then, run `pod install`. + +::: note +For further reference on Cocoapods, check their [official documentation](https://guides.cocoapods.org/using/getting-started.html). +::: + +### Using Carthage + +Add the following line to your `Cartfile`: + +```text +github "auth0/Auth0.swift" ~> 2.0 +``` + +Then, run `carthage bootstrap --use-xcframeworks`. + +::: note +For further reference on Carthage, check their [official documentation](https://github.com/Carthage/Carthage#getting-started). +::: + +## Configure the SDK + +The Auth0.swift SDK needs the **Client ID** and **domain** of the Auth0 application to communicate with Auth0. You can find these details in the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application. If you are using a [custom domain](/customize/custom-domains), use the value of your custom domain instead of the value from the settings page. + +<% if(typeof hideDashboardScreenshot === 'undefined' || hideDashboardScreenshot !== true) { %> +![Screenshot of the Auth0 application settings page](/media/articles/dashboard/client_settings.png) +<% } %> + +Create a `plist` file named `Auth0.plist` in your app bundle with the following content: + +```xml + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` + +::: note +<% if(typeof hideDownloadSample === 'undefined' || hideDownloadSample !== true) { %> +If you download the sample from the top of this page, these details are filled out for you. +<% } %> +You can also configure the SDK programmatically. Check the [README](https://github.com/auth0/Auth0.swift#configure-client-id-and-domain-programmatically) to learn more. +::: + +::: panel Checkpoint +Now that you have configured Auth0.swift with the Client ID and domain, run your app to verify that it is not producing any errors related to the SDK. +::: + +## Login + +Import the `Auth0` module in the file where you want to present the login page. + +```swift +import Auth0 +``` + +Then, present the [Universal Login](/authenticate/login/auth0-universal-login) page in the action of your **Login** button. + +```swift +Auth0 + .webAuth() + .useHTTPS() // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+ + .start { result in + switch result { + case .success(let credentials): + print("Obtained credentials: \(credentials)") + case .failure(let error): + print("Failed with: \(error)") + } + } +``` + +::: note +You can use async/await or Combine instead of the callback-based API. Check the [README](https://github.com/auth0/Auth0.swift#web-auth-login-ios--macos) to learn more. +::: + +
Screenshot of the Universal Login page
+ +::: panel Checkpoint +Verify that pressing the **Login** button shows an [alert box](https://github.com/auth0/Auth0.swift#sso-alert-box-ios--macos) asking for consent and that choosing **Continue** opens the Universal Login page in a Safari modal. Verify that you can log in or sign up using a username and password or a social provider. + +Once that is complete, verify that the Safari modal closes automatically. +::: + +## Logout + +Now that you can log in to your app, you need a way to [log out](/authenticate/login/logout). In the action of your **Logout** button, call the `clearSession()` method to clear the Universal Login session cookie. + +```swift +Auth0 + .webAuth() + .useHTTPS() // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+ + .clearSession { result in + switch result { + case .success: + print("Logged out") + case .failure(let error): + print("Failed with: \(error)") + } + } +``` + +::: panel Checkpoint +Verify that pressing the **Logout** button shows an alert box asking for consent and that choosing **Continue** opens a page in a Safari modal. Verify that the Safari modal closes automatically soon after. +::: + +## Access User Profile Information + +The `Credentials` instance you obtained after logging in includes an [ID Token](/secure/tokens/id-tokens). The ID Token contains the profile information associated with the logged-in user, such as their email and profile picture. You can use these details to personalize the user interface of your app. + +The Auth0.swift SDK includes a [utility](https://github.com/auth0/JWTDecode.swift) for decoding [JWTs](https://jwt.io/) like the ID Token. Start by importing the `JWTDecode` module in the file where you want to access the user profile information. + +```swift +import JWTDecode +``` + +Then, use the `decode(jwt:)` method to decode the ID Token and access the claims it contains. + +```swift +guard let jwt = try? decode(jwt: credentials.idToken), + let name = jwt["name"].string, + let picture = jwt["picture"].string else { return } +print("Name: \(name)") +print("Picture URL: \(picture)") +``` + +::: note +You can retrieve the latest user information with the `userInfo(withAccessToken:)` method. Check the [EXAMPLES](https://github.com/auth0/Auth0.swift/blob/master/EXAMPLES.md#retrieve-user-information) to learn more. +::: + +::: panel Checkpoint +Verify that you can access the `email`, `picture`, or any other [claim](/secure/tokens/id-tokens/id-token-structure) after you have logged in. +::: + +## What's Next? + +Check the SDK documentation to learn how to perform some common tasks, explore more advanced use cases, and discover all the available features: + +- [Next steps](https://github.com/auth0/Auth0.swift#next-steps) +- [API documentation](https://auth0.github.io/Auth0.swift/) +- [FAQ](https://github.com/auth0/Auth0.swift/blob/master/FAQ.md) diff --git a/fr-ca/articles/quickstart/native/ios-swift/download.md b/fr-ca/articles/quickstart/native/ios-swift/download.md new file mode 100644 index 0000000000..4e7e9e3db7 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/download.md @@ -0,0 +1,20 @@ + + +> On every step, if you have a [custom domain](https://auth0.com/docs/customize/custom-domains), replace the `YOUR_AUTH0_DOMAIN` placeholder with your custom domain instead of the value from the settings page. + +## 1. Configure the associated domain + +> **This requires Xcode 15.3+ and a paid Apple Developer account**. If you do not have a paid Apple Developer account, skip this step, and comment out the two `useHTTPS()` calls in `MainView.swift`. + +Open `SwiftSample.xcodeproj` in Xcode and go to the settings of the app target you want to run. There are two app targets available: **SwiftSample (iOS)** and **SwiftSample (macOS)**. Change the bundle identifier from the default `com.auth0.samples.SwiftSample` to another value of your choosing. Then, make sure the **Automatically manage signing** box is checked, and that your Apple Team is selected. + +Next, go to the **Signing & Capabilities** tab of the app's target settings. Find the `webcredentials:YOUR_AUTH0_DOMAIN` entry under **Associated Domains**, and replace the `YOUR_AUTH0_DOMAIN` placeholder with the domain of your Auth0 application. + +Finally, open the settings page of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to the app's bundle identifier. + +## 2. Configure the Auth0 application + +Open the settings page of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the app target you want to run. + +- **SwiftSample (iOS)**: `https://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback` +- **SwiftSample (macOS)**: `https://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback` diff --git a/fr-ca/articles/quickstart/native/ios-swift/files/Auth0.md b/fr-ca/articles/quickstart/native/ios-swift/files/Auth0.md new file mode 100644 index 0000000000..a989cbd06a --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/files/Auth0.md @@ -0,0 +1,17 @@ +--- +name: Auth0.plist +language: xml +--- + +```xml + + + + + ClientId + ${account.clientId} + Domain + ${account.namespace} + + +``` diff --git a/fr-ca/articles/quickstart/native/ios-swift/files/MainView.md b/fr-ca/articles/quickstart/native/ios-swift/files/MainView.md new file mode 100644 index 0000000000..e62095b332 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/files/MainView.md @@ -0,0 +1,54 @@ +--- +name: MainView.swift +language: swift +--- + +```swift +import SwiftUI +import Auth0 + +struct MainView: View { + @State var user: User? + + var body: some View { + if let user = self.user { + VStack { + ProfileView(user: user) + Button("Logout", action: self.logout) + } + } else { + Button("Login", action: self.login) + } + } +} + +extension MainView { + func login() { + Auth0 + .webAuth() + .useHTTPS() // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+ + .start { result in + switch result { + case .success(let credentials): + self.user = User(from: credentials.idToken) + case .failure(let error): + print("Failed with: \(error)") + } + } + } + + func logout() { + Auth0 + .webAuth() + .useHTTPS() // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+ + .clearSession { result in + switch result { + case .success: + self.user = nil + case .failure(let error): + print("Failed with: \(error)") + } + } + } +} +``` diff --git a/fr-ca/articles/quickstart/native/ios-swift/files/ProfileView.md b/fr-ca/articles/quickstart/native/ios-swift/files/ProfileView.md new file mode 100644 index 0000000000..e476520a9d --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/files/ProfileView.md @@ -0,0 +1,19 @@ +--- +name: ProfileView.swift +language: swift +--- + +```swift +import SwiftUI + +struct ProfileView: View { + let user: User + + var body: some View { + VStack { + AsyncImage(url: URL(string: user.picture)) + Text("Email: \(user.email)") + } + } +} +``` diff --git a/fr-ca/articles/quickstart/native/ios-swift/files/User.md b/fr-ca/articles/quickstart/native/ios-swift/files/User.md new file mode 100644 index 0000000000..95b9bf43c2 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/files/User.md @@ -0,0 +1,27 @@ +--- +name: User.swift +language: swift +--- + +```swift +import JWTDecode + +struct User { + let id: String + let email: String + let picture: String +} + +extension User { + init?(from idToken: String) { + guard let jwt = try? decode(jwt: idToken), + let id = jwt.subject, + let email = jwt["email"].string, + let picture = jwt["picture"].string + else { return nil } + self.id = id + self.email = email + self.picture = picture + } +} +``` diff --git a/fr-ca/articles/quickstart/native/ios-swift/index.yml b/fr-ca/articles/quickstart/native/ios-swift/index.yml new file mode 100755 index 0000000000..db922d99d6 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/index.yml @@ -0,0 +1,38 @@ +title: iOS / macOS +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/ios.png +logo: apple +alias: + - ios + - macos + - swift +language: + - Swift +hybrid: false +author: + name: Rita Zerrizuela + email: rita.zerrizuela@auth0.com + community: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: swift +show_releases: true +show_steps: true +requirements: + - iOS 13+ or macOS 11+ + - Xcode 14.x +default_article: 01-login +articles: + - 01-login +hidden_articles: + - interactive +sdk: + name: Auth0.swift + url: https://github.com/auth0/Auth0.swift + logo: apple +github: + org: auth0-samples + repo: auth0-ios-swift-sample + branch: master diff --git a/fr-ca/articles/quickstart/native/ios-swift/interactive.md b/fr-ca/articles/quickstart/native/ios-swift/interactive.md new file mode 100644 index 0000000000..10babccc90 --- /dev/null +++ b/fr-ca/articles/quickstart/native/ios-swift/interactive.md @@ -0,0 +1,256 @@ +--- +title: Add Login to your iOS or macOS app +description: This guide demonstrates how to add authentication and gain access to user profile information in any iOS / macOS app using the Auth0.swift SDK. +interactive: true +files: + - files/Auth0 + - files/MainView + - files/ProfileView + - files/User +seo_alias: swift +budicon: 448 +topics: + - quickstarts + - native + - ios + - macos + - swift +github: + path: Sample-01 +contentType: tutorial +useCase: quickstart +--- + +# Add Login to Your iOS or macOS Application + +This guide demonstrates how to add authentication and access user profile information in any iOS / macOS app using the [Auth0.swift](https://github.com/auth0/Auth0.swift) SDK. + +To use this quickstart, you need to: +* Sign up for a free Auth0 account or log in to Auth0. +* Have an existing iOS / macOS app that you want to integrate. Alternatively, you can view or download a sample app after logging in. + +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the app you are developing. + +### Configure an Auth0 application + +Use the interactive selector to create a new Auth0 application or select an existing **Native** Auth0 application. Auth0 assigns every application an alphanumeric, unique Client ID that your app uses to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart automatically update your Auth0 application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample app instead. + +### Configure callback and logout URLs + +Auth0 invokes the callback and logout URLs to redirect users back to your app. Auth0 invokes the callback URL after authenticating the user and the logout URL after removing the session cookie. If you do not set the callback and login URLs, users will not be able to log in and out of the app, and your app will produce an error. + +::: note +On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links as callback and logout URLs. When enabled, Auth0.swift will fall back to using a custom URL scheme on older iOS / macOS versions. + +**This feature requires Xcode 15.3+ and a paid Apple Developer account**. +::: + +Add the following URLs to **Callback URLs** and **Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain. + +#### iOS + +```text +https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback +``` + +#### macOS + +```text +https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback +``` + +For example, if your iOS bundle identifier was `com.example.MyApp` and your Auth0 domain was `example.us.auth0.com`, then this value would be: + +```text +https://example.us.auth0.com/ios/com.example.MyApp/callback, +com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback +``` + +### Configure the associated domain + +::: warning +This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead. +::: + +#### Configure the Team ID and bundle identifier + +Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier. + +

Screenshot of the iOS section inside the Auth0 application settings page

+ +This will add your app to your Auth0 tenant's `apple-app-site-association` file. + +#### Add the associated domain capability + +In Xcode, go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of your app's target settings, and press the **+ Capability** button. Then select **Associated Domains**. + +

Screenshot of the capabilities library inside Xcode

+ +Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**: + +```text +webcredentials:${account.namespace} +``` + +If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain. + +::: note +For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application. +::: + +## Install the SDK + +### Using the Swift Package Manager + +Open the following menu item in Xcode: + +**File > Add Package Dependencies...** + +In the **Search or Enter Package URL** search box enter this URL: + +```text +https://github.com/auth0/Auth0.swift +``` + +Then, select the dependency rule and press **Add Package**. + +::: note +For further reference on SPM, check its [official documentation](https://developer.apple.com/documentation/xcode/adding-package-dependencies-to-your-app). +::: + +### Using Cocoapods + +Add the following line to your `Podfile`: + +```ruby +pod 'Auth0', '~> 2.0' +``` + +Then, run `pod install`. + +::: note +For further reference on Cocoapods, check their [official documentation](https://guides.cocoapods.org/using/getting-started.html). +::: + +### Using Carthage + +Add the following line to your `Cartfile`: + +```text +github "auth0/Auth0.swift" ~> 2.0 +``` + +Then, run `carthage bootstrap --use-xcframeworks`. + +::: note +For further reference on Carthage, check their [official documentation](https://github.com/Carthage/Carthage#getting-started). +::: + +## Configure the SDK {{{ data-action=code data-code="Auth0.plist" }}} + +The Auth0.swift SDK needs your Auth0 **domain** and **Client ID**. You can find these values in the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application. + +- **domain**: The domain of your Auth0 tenant. If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain. +- **Client ID**: The alphanumeric, unique ID of the Auth0 application you set up earlier in this quickstart. + +Create a `plist` file named `Auth0.plist` in your app bundle containing the Auth0 domain and Client ID values. + +::: note +You can also configure the SDK programmatically. Check the [README](https://github.com/auth0/Auth0.swift#configure-client-id-and-domain-programmatically) to learn more. +::: + +::::checkpoint +:::checkpoint-default +You configured the Auth0.swift SDK. Run your app to verify that it is not producing any errors related to the SDK. +::: + +:::checkpoint-failure +If your app produces errors related to the SDK: +- Make sure you selected the correct Auth0 application +- Verify you saved your URL updates +- Ensure you set the Auth0 domain and Client ID correctly + +Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add login to your application {{{ data-action=code data-code="MainView.swift#20:31" }}} + +Import the `Auth0` module in the file where you want to present the login page. Then, present the [Universal Login](/authenticate/login/auth0-universal-login) page in the action of your **Login** button. + +::: note +You can use async/await or Combine instead of the callback-based API. Check the [README](https://github.com/auth0/Auth0.swift#web-auth-login-ios--macos) to learn more. +::: + +
Screenshot of the Universal Login page
+ +::::checkpoint +:::checkpoint-default +Press the **Login** button and verify that: +- An [alert box](https://github.com/auth0/Auth0.swift#sso-alert-box-ios--macos) shows up asking for consent. +- Choosing **Continue** opens the Universal Login page in a Safari modal. +- You can log in or sign up using a username and password or a social provider. +- The Safari modal closes automatically afterward. +::: + +:::checkpoint-failure +If login fails or produces errors: +- Verify you entered the correct callback URL +- Ensure you set the Auth0 domain and Client ID correctly + +Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="MainView.swift#33:44" }}} + +Now that you can log in to your app, you need a way to [log out](/authenticate/login/logout). In the action of your **Logout** button, call the `clearSession()` method to clear the Universal Login session cookie. + +::::checkpoint +:::checkpoint-default +Press the **Logout** button and verify that: +- An alert box shows up asking for consent. +- Choosing **Continue** opens a page in a Safari modal. +- The Safari modal closes automatically soon after. +::: + +:::checkpoint-failure +If logout fails or produces errors: +- Verify you entered the correct callback URL +- Ensure you set the Auth0 domain and Client ID correctly + +Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Access user profile information {{{ data-action=code data-code="User.swift#11:14" }}} + +The `Credentials` instance you obtained after logging in includes an [ID token](/secure/tokens/id-tokens). The ID token contains the profile information associated with the logged-in user, such as their email and profile picture. You can use these details to personalize the user interface of your app. + +The Auth0.swift SDK includes a [utility](https://github.com/auth0/JWTDecode.swift) for decoding [JWTs](https://jwt.io/) like the ID token. Start by importing the `JWTDecode` module in the file where you want to access the user profile information. Then, use the `decode(jwt:)` method to decode the ID token and access the claims it contains. + +::: note +You can retrieve the latest user information with the `userInfo(withAccessToken:)` method. Check the [EXAMPLES](https://github.com/auth0/Auth0.swift/blob/master/EXAMPLES.md#retrieve-user-information) to learn more. +::: + +::::checkpoint +:::checkpoint-default +Verify that you can access the `email`, `picture`, or any other [claim](/secure/tokens/id-tokens/id-token-structure) after you have logged in. +::: + +:::checkpoint-failure +If you cannot access the user information: +- Verify you imported the `JWTDecode` module where you invoke the `decode(jwt:)` method +- Make sure you spelled your claims correctly + +Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community forums](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/native/maui/01-login.md b/fr-ca/articles/quickstart/native/maui/01-login.md new file mode 100755 index 0000000000..3242d02d90 --- /dev/null +++ b/fr-ca/articles/quickstart/native/maui/01-login.md @@ -0,0 +1,157 @@ +--- +title: Add login to your MAUI application +default: true +description: This tutorial demonstrates how to add user login with Auth0 to a .NET MAUI application. +budicon: 448 +topics: + - quickstarts + - native + - xamarin + - dotnet + - android + - ios +github: + path: Sample +contentType: tutorial +useCase: quickstart +--- + +::: note +The MAUI SDK supports Android, iOS, macOS, and Windows. Continue reading for platform-specific configuration. +::: + + + + +<%= include('../_includes/_getting_started') %> + +<%= include('../../../_includes/_callback_url') %> + +Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and appends additional parameters to it, including an access code which will be exchanged for an ID Token, Access Token, and Refresh Token. + +Since callback URLs can be manipulated, you will need to add your application's URL to your application's *Allowed Callback URLs* for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful. + +::: note +When following along with this quickstart, configure `myapp://callback` as the *Allowed Callback URLs*. +::: + +<%= include('../../../_includes/_logout_url') %> + +::: note +When following along with this quickstart, configure `myapp://callback` as the *Allowed Logout URLs*. +::: + +## Install the Auth0 SDK + +Auth0 provides a [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/) SDK to simplify the process of implementing Auth0 authentication in MAUI applications. + +Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.MAUI` package. + +Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`). + +```ps +Install-Package Auth0.OidcClient.MAUI +``` +``` +dotnet add package Auth0.OidcClient.MAUI +``` + +## Platform specific configuration + +You need some platform-specific configuration to use the SDK with Android and Windows. + +### Android +Create a new Activity that extends `WebAuthenticatorCallbackActivity`: + +```csharp +[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)] +[IntentFilter(new[] { Intent.ActionView }, + Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable }, + DataScheme = CALLBACK_SCHEME)] +public class WebAuthenticatorActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity +{ + const string CALLBACK_SCHEME = "myapp"; +} +``` + +The above activity will ensure the application can handle the `myapp://callback` URL when Auth0 redirects back to the Android application after logging in. + +### Windows +To make sure it can properly reactivate your application after being redirected back to Auth0, you need to do two things: + +- Add the corresponding protocol to the `Package.appxmanifest`. In this case, this is set to `myapp`, but you can change this to whatever you like (ensure to update all relevant Auth0 URLs as well). + ```xml + + + + + + + + + + ``` +- Call `Activator.Default.CheckRedirectionActivation()` in the Windows-specific `App.xaml.cs` file. + ```csharp + public App() + { + if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation()) + return; + + this.InitializeComponent(); + } + ``` + +## Instantiate the Auth0Client + +To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain, Client ID and the required Scopes. +Additionally, you also need to configure the `RedirectUri` and `PostLogoutRedirectUri` to ensure Auth0 can redirect back to the application using the URL(s) configured. + +```csharp +using Auth0.OidcClient; + +var client = new Auth0Client(new Auth0ClientOptions +{ + Domain = "${account.namespace}", + ClientId = "${account.namespace}", + RedirectUri = "myapp://callback", + PostLogoutRedirectUri = "myapp://callback", + Scope = "openid profile email" +}); +``` + +By default, the SDK will leverage Chrome Custom Tabs for Android, ASWebAuthenticationSession for iOS and macOS and use your system's default browser on Windows. + +## Add Login to Your Application + +Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. + +```csharp +var loginResult = await client.LoginAsync(); +``` + +If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`. + +## Add Logout to Your Application + +Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart. + +```csharp +await client.LogoutAsync(); +``` + +## Show User Profile Information + +Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project. + +The Auth0 SDK for MAUI provides user information through the `LoginResult.User` property. + +```csharp +if (loginResult.IsError == false) +{ + var user = loginResult.User; + var name = user.FindFirst(c => c.Type == "name")?.Value; + var email = user.FindFirst(c => c.Type == "email")?.Value; + var picture = user.FindFirst(c => c.Type == "picture")?.Value; +} +``` diff --git a/fr-ca/articles/quickstart/native/maui/download.md b/fr-ca/articles/quickstart/native/maui/download.md new file mode 100644 index 0000000000..65c7470855 --- /dev/null +++ b/fr-ca/articles/quickstart/native/maui/download.md @@ -0,0 +1,22 @@ +To run the sample first set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings): + + ```text +myapp://callback + ``` + +Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings): + + ```text +myapp://callback + ``` + +Then, to run it **on Windows**: + +1) Open the Auth0MauiApp.sln in [Visual Studio 2022](https://www.visualstudio.com/vs/). +2) Click the **Start** button (the green play button), ensure to select your target device. +You can also start the application using the **Debug | Start Debugging** option from the main menu. + +To run it on **macOS**: + +1) Open the Auth0MauiApp.sln in [Visual Studio for Mac](https://visualstudio.microsoft.com/vs/mac/). +2) Click the **Start** button (the play button), ensure to select your target device. You can also start the application using the **Run | Start Debugging** option from the application menu diff --git a/fr-ca/articles/quickstart/native/maui/files/main-page.md b/fr-ca/articles/quickstart/native/maui/files/main-page.md new file mode 100644 index 0000000000..6bb02cb95e --- /dev/null +++ b/fr-ca/articles/quickstart/native/maui/files/main-page.md @@ -0,0 +1,74 @@ +--- +name: MainPage.xaml.cs +language: csharp +--- + +```csharp +public partial class MainPage : ContentPage +{ + Auth0Client client = new Auth0Client(new Auth0ClientOptions + { + Domain = "${account.namespace}" + ClientId = "${account.clientId}", + RedirectUri = "myapp://callback", + PostLogoutRedirectUri = "myapp://callback", + Scope = "openid profile email" + }); + + public MainPage() + { + InitializeComponent(); + } + + private async void OnLoginClicked(object sender, EventArgs e) + { + var extraParameters = new Dictionary(); + var audience = ""; // FILL WITH AUDIENCE AS NEEDED + + if (!string.IsNullOrEmpty(audience)) + extraParameters.Add("audience", audience); + + var result = await client.LoginAsync(extraParameters); + + DisplayResult(result); + } + + private async void OnLogoutClicked(object sender, EventArgs e) + { + BrowserResultType browserResult = await client.LogoutAsync(); + + if (browserResult != BrowserResultType.Success) + { + ErrorLabel.Text = browserResult.ToString(); + return; + } + + LogoutBtn.IsVisible = false; + LoginBtn.IsVisible = true; + + HelloLabel.Text = $"Hello, World!"; + ErrorLabel.Text = ""; + } + + private void DisplayResult(LoginResult loginResult) + { + if (loginResult.IsError) + { + ErrorLabel.Text = loginResult.Error; + return; + } + + var user = loginResult.User; + var name = user.FindFirst(c => c.Type == "name")?.Value; + var email = user.FindFirst(c => c.Type == "email")?.Value; + var picture = user.FindFirst(c => c.Type == "picture")?.Value; + + LogoutBtn.IsVisible = true; + LoginBtn.IsVisible = false; + + + HelloLabel.Text = $"Hello, {loginResult.User.Identity.Name}"; + ErrorLabel.Text = ""; + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/maui/index.yml b/fr-ca/articles/quickstart/native/maui/index.yml new file mode 100755 index 0000000000..f0dc62f629 --- /dev/null +++ b/fr-ca/articles/quickstart/native/maui/index.yml @@ -0,0 +1,49 @@ +title: MAUI +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/xamarin.png +logo: dotnet-platform +author: + name: Frederik Prijck + email: frederik.prijck@okta.com + community: false +language: + - C# +framework: + - maui +hybrid: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: maui +default_article: 01-login +hidden_articles: + - interactive +articles: + - 01-login +show_steps: true +github: + org: auth0-samples + repo: auth0-maui-samples +sdk: + name: auth0-oidc-client-net + url: https://github.com/auth0/auth0-oidc-client-net + logo: dotnet +requirements: + - Visual Studio 2022+ or Visual Studio for Mac + - .NET6+ +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/native/maui/interactive.md b/fr-ca/articles/quickstart/native/maui/interactive.md new file mode 100644 index 0000000000..03c9607e77 --- /dev/null +++ b/fr-ca/articles/quickstart/native/maui/interactive.md @@ -0,0 +1,203 @@ +--- +title: Add login to your .NET MAUI application +default: true +description: This tutorial demonstrates how to add user login with Auth0 to a .NET MAUI application. +budicon: 448 +topics: + - quickstarts + - native + - maui + - dotnet + - android + - ios + - windows +github: + path: Sample +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/main-page +--- + +# Add Login to Your MAUI Application + +Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any .NET MAUI application using the Auth0 SDKs for [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/). + +::: note +The MAUI SDK supports Android, iOS, macOS, and Windows. Continue reading for platform-specific configuration. +::: + +<%= include('../../_includes/_configure_auth0_interactive', { + callback: 'myapp://callback', + returnTo: 'myapp://callback' +}) %> + +## Install the Auth0 SDK + +Auth0 provides a [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/) SDK to simplify the process of implementing Auth0 authentication in MAUI applications. + +Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.MAUI` package. + +Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`). + +```ps +Install-Package Auth0.OidcClient.MAUI +``` +``` +dotnet add package Auth0.OidcClient.MAUI +``` + +## Platform specific configuration + +You need some platform-specific configuration to use the SDK with Android and Windows. + +### Android +Create a new Activity that extends `WebAuthenticatorCallbackActivity`: + +```csharp +[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)] +[IntentFilter(new[] { Intent.ActionView }, + Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable }, + DataScheme = CALLBACK_SCHEME)] +public class WebAuthenticatorActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity +{ + const string CALLBACK_SCHEME = "myapp"; +} +``` + +The above activity will ensure the application can handle the `myapp://callback` URL when Auth0 redirects back to the Android application after logging in. + +### Windows +To make sure it can properly reactivate your application after being redirected back to Auth0, you need to do two things: + +- Add the corresponding protocol to the `Package.appxmanifest`. In this case, this is set to `myapp`, but you can change this to whatever you like (ensure to update all relevant Auth0 URLs as well). + ```xml + + + + + + + + + + ``` +- Call `Activator.Default.CheckRedirectionActivation()` in the Windows-specific `App.xaml.cs` file. + ```csharp + public App() + { + if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation()) + return; + + this.InitializeComponent(); + } + ``` + +## Instantiate the Auth0Client {{{ data-action="code" data-code="MainPage.xaml.cs#3-10" }}} + +To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain, Client ID and the required Scopes. +Additionally, you also need to configure the `RedirectUri` and `PostLogoutRedirectUri` to ensure Auth0 can redirect back to the application using the URL(s) configured. + +```csharp +using Auth0.OidcClient; + +var client = new Auth0Client(new Auth0ClientOptions +{ + Domain = "${account.namespace}", + ClientId = "${account.clientId}", + RedirectUri = "myapp://callback", + PostLogoutRedirectUri = "myapp://callback", + Scope = "openid profile email" +}); +``` + +By default, the SDK will leverage Chrome Custom Tabs for Android, ASWebAuthenticationSession for iOS and macOS and use your system's default browser on Windows. + +::::checkpoint + +:::checkpoint-default + +Your `Auth0Client` should now be properly instantiated. Run your application to verify that: +- the `Auth0Client` is instantiated correctly in the `MainPage`. +- your application is not throwing any errors related to Auth0 + +::: + +:::checkpoint-failure +Sorry about that. Here are a couple things to double-check: +* make sure the correct application is selected +* did you save after entering your URLs? +* make sure the domain and client ID are imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add login to your application {{{ data-action="code" data-code="MainPage.xaml.cs#25" }}} + +Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. + +```csharp +var loginResult = await client.LoginAsync(); +``` + +If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`. + +::::checkpoint + +:::checkpoint-default + +You should now be able to log in or sign up using a username and password. + +Click the login button and verify that: +* your application redirects you to the Auth0 Universal Login page +* you can log in or sign up +* Auth0 redirects you to your application. + +::: + +:::checkpoint-failure +Sorry about that. Here's something to double-check: +* you called `LoginAsync` as expected + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add logout to your application {{{ data-action="code" data-code="MainPage.xaml.cs#32" }}} + +Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart. + +```csharp +await client.LogoutAsync(); +``` + +::::checkpoint + +:::checkpoint-default + +Run your application and click the logout button, verify that: +* your application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings +* you are no longer logged in to your application + +::: + +:::checkpoint-failure +Sorry about that. Here are a couple things to double-check: +* you configured the correct Logout URL +* you called `LogoutAsync` as expected. + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: + +:::: + +## Show User Profile Information {{{ data-action="code" data-code="MainPage.xaml.cs#55-58" }}} + +Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project. + +The Auth0 SDK for MAUI provides user information through the `LoginResult.User` property. diff --git a/fr-ca/articles/quickstart/native/net-android-ios/01-login.md b/fr-ca/articles/quickstart/native/net-android-ios/01-login.md new file mode 100755 index 0000000000..992d4e2d37 --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/01-login.md @@ -0,0 +1,227 @@ +--- +title: Add login to your .NET Android or iOS application +default: true +description: This tutorial demonstrates how to add user login with Auth0 to a .NET Android or iOS application. +budicon: 448 +topics: + - quickstarts + - native + - xamarin + - dotnet + - android + - ios +github: + path: Quickstart/01-Login +contentType: tutorial +useCase: quickstart +--- + +::: note +This quickstart focusses on .NET Android and iOS, as they are the next generation of `Xamarin.Android` and `Xamarin.iOS`. If you are still using `Xamarin.Android` and `Xamarin.iOS`, you can follow this guide as well as integration is identical and the SDKs are compatible. +::: + + + +<%= include('../_includes/_getting_started', { library: 'Xamarin') %> + +<%= include('../../../_includes/_callback_url') %> + +Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and appends additional parameters to it, including an access code which will be exchanged for an ID Token, Access Token, and Refresh Token. + +Since callback URLs can be manipulated, you will need to add your application's URL to your application's *Allowed Callback URLs* for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful. + +* For Android, the callback URL will be in the format + + ```text + YOUR_ANDROID_PACKAGE_NAME://${account.namespace}/android/YOUR_ANDROID_PACKAGE_NAME/callback + ``` + + where `YOUR_ANDROID_PACKAGE_NAME` is the Package Name for your application, such as `com.mycompany.myapplication`. + +* For iOS, the callback URL will be in the format + + ```text + YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback + ``` + + where `YOUR_BUNDLE_IDENTIFIER` is the Bundle Identifier for your application, such as `com.mycompany.myapplication`. + +Ensure that the Callback URL is in lowercase. + +<%= include('../../../_includes/_logout_url') %> + +::: note +If you are following along with the sample project you downloaded from the top of this page, the logout URL you need to add to the Allowed Logout URLs field is the same as the callback URL. +::: + +## Install Dependencies + +${snippet(meta.snippets.dependencies)} + +## Trigger Authentication + +To integrate Auth0 login into your application, instantiate an instance of the `Auth0Client` class, configuring the Auth0 Domain and Client ID: + +${snippet(meta.snippets.setup)} + +Then, call the `LoginAsync` method which will redirect the user to the login screen. You will typically do this in the event handler for a UI control such as a Login button. + +```cs +var loginResult = await client.LoginAsync(); +``` + +### Handing the callback URL + +After a user has logged in, they will be redirected back to your application at the **Callback URL** that was registered before. In both Android and iOS you need to handle this callback to complete the authentication flow. + +### Android + +Register an intent which will handle this callback URL. An easy way to do this is to register the intent on the same activity from which you called the `LoginAsync` method to initiate the authentication flow. + +```csharp +[Activity(Label = "AndroidSample", MainLauncher = true, Icon = "@drawable/icon", + LaunchMode = LaunchMode.SingleTask)] +[IntentFilter( + new[] { Intent.ActionView }, + Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable }, + DataScheme = "YOUR_ANDROID_PACKAGE_NAME", + DataHost = "${account.namespace}", + DataPathPrefix = "/android/YOUR_ANDROID_PACKAGE_NAME/callback")] +public class MainActivity : Activity +{ + // Code omitted +} +``` + +Replace `YOUR_ANDROID_PACKAGE_NAME` in the code sample above with the actual Package Name for your application, such as `com.mycompany.myapplication`. Also ensure that all the text for the `DataScheme`, `DataHost`, and `DataPathPrefix` is in lower case. Also, set `LaunchMode = LaunchMode.SingleTask` for the `Activity`, otherwise the system will create a new instance of the activity every time the Callback URL gets called. + +Now write code to handle the intent. You can do this by overriding the `OnNewIntent` method. Inside the method you need to call the `Send` method on the `ActivityMediator` to complete the authentication cycle: + +```csharp +protected override async void OnNewIntent(Intent intent) +{ + base.OnNewIntent(intent); + + Auth0.OidcClient.ActivityMediator.Instance.Send(intent.DataString); +} +``` + +### iOS + +Register the URL scheme for your Callback URL which your application should handle: + +1. Open your application's `Info.plist` file in Visual Studio for Mac, and go to the **Advanced** tab. +2. Under **URL Types**, click the **Add URL Type** button +3. Set the **Identifier** as `Auth0`, the **URL Schemes** the same as your application's **Bundle Identifier**, and the **Role** as `None` + +This is an example of the XML representation of your `info.plist` file after you have added the URL Type: + +```xml +CFBundleURLTypes + + + CFBundleTypeRole + None + CFBundleURLName + Auth0 + CFBundleURLSchemes + + YOUR_BUNDLE_IDENTIFIER + + + +``` + +You need to handle the Callback URL in the `OpenUrl` event in your `AppDelegate` class. You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, pass along the URL that was sent in: + +```csharp +using Auth0.OidcClient; + +[Register("AppDelegate")] +public class AppDelegate : UIApplicationDelegate +{ + public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation) + { + ActivityMediator.Instance.Send(url.AbsoluteString); + + return true; + } +} +``` + +### Run the application + +With the above code in place, a user can log in to your application using Auth0. + +
+ Universal Login +
+ +## Accessing the User's Information + +The returned login result will indicate whether authentication was successful and if so contain the tokens and claims of the user. + +### Authentication Error + +You can check the `IsError` property of the result to see whether the login has failed. The `ErrorMessage` will contain more information regarding the error which occurred. + +```csharp +var loginResult = await client.LoginAsync(); + +if (loginResult.IsError) +{ + Debug.WriteLine($"An error occurred during login: {loginResult.Error}") +} +``` + +### Accessing the tokens + +On successful login, the login result will contain the ID Token and Access Token in the `IdentityToken` and `AccessToken` properties respectively. + +```csharp +var loginResult = await client.LoginAsync(); + +if (!loginResult.IsError) +{ + Debug.WriteLine($"id_token: {loginResult.IdentityToken}"); + Debug.WriteLine($"access_token: {loginResult.AccessToken}"); +} +``` + +### Obtaining the User Information + +On successful login, the login result will contain the user information in the `User` property, which is a [ClaimsPrincipal](https://msdn.microsoft.com/en-us/library/system.security.claims.claimsprincipal(v=vs.110).aspx). + +To obtain information about the user, you can query the claims. You can, for example, obtain the user's name and email address from the `name` and `email` claims: + +```csharp +if (!loginResult.IsError) +{ + Debug.WriteLine($"name: {loginResult.User.FindFirst(c => c.Type == "name")?.Value}"); + Debug.WriteLine($"email: {loginResult.User.FindFirst(c => c.Type == "email")?.Value}"); +} +``` + +::: note +The exact claims returned will depend on the scopes that were requested. For more information see the [Using Scopes](https://auth0.github.io/auth0-oidc-client-net/documentation/advanced-scenarios/scopes.html) in the Auth0 OIDC Application documentation. +::: + +You can obtain a list of all the claims contained in the ID Token by iterating through the `Claims` collection: + +```csharp +if (!loginResult.IsError) +{ + foreach (var claim in loginResult.User.Claims) + { + Debug.WriteLine($"{claim.Type} = {claim.Value}"); + } +} +``` + +## Logout + +To log the user out call the `LogoutAsync` method. + +```csharp +BrowserResultType browserResult = await client.LogoutAsync(); +``` diff --git a/fr-ca/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md b/fr-ca/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md new file mode 100644 index 0000000000..471c0f77bb --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md @@ -0,0 +1,37 @@ +## Configure Auth0 {{{ data-action=configure }}} + +To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project. + +### Configure an application + +Use the interactive selector to create a new "Native Application", or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample application instead. + +### Configure Callback URLs + +A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in. + +::: note +If you are following along with our sample project, set this to one of the following URLs, depending on your platform: + +**Android**: `YOUR_PACKAGE_NAME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback` + +**iOS**: `YOUR_BUNDLE_ID://${account.namespace}/ios/YOUR_BUNDLE_ID/callback` +::: + +### Configure Logout URLs + +A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error. + +::: note +If you are following along with our sample project, set this to one of the following URLs, depending on your platform: + +**Android**: `YOUR_PACKAGE_NAME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback` + +**iOS**: `YOUR_BUNDLE_ID://${account.namespace}/ios/YOUR_BUNDLE_ID/callback` +::: + +Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). diff --git a/fr-ca/articles/quickstart/native/net-android-ios/download.md b/fr-ca/articles/quickstart/native/net-android-ios/download.md new file mode 100644 index 0000000000..6aca335de9 --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/download.md @@ -0,0 +1,22 @@ +To run the sample first set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) so it works for both Android and iOS apps: + + ```text +com.auth0.quickstart://${account.namespace}/android/com.auth0.quickstart/callback com.auth0.iossample://${account.namespace}/ios/com.auth0.iossample/callback + ``` + +Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) so it works for both Android and iOS apps: + + ```text +com.auth0.quickstart://${account.namespace}/android/com.auth0.quickstart/callback com.auth0.iossample://${account.namespace}/ios/com.auth0.iossample/callback + ``` + +Then, to run it **on Windows**: + +1) Open the AndroidSample.sln or iOSSample.sln solution in [Visual Studio 2017](https://www.visualstudio.com/vs/). +2) Click the **Start** button (the green play button), optionally selecting your target device. +You can also start the application using the **Debug | Start Debugging** option from the main menu. + +To run it on **macOS**: + +1) Open the AndroidSample.sln or iOSSample.sln solution in [Visual Studio for Mac](https://visualstudio.microsoft.com/vs/mac/). +2) Click the **Start** button (the play button), optionally selecting your target device. You can also start the application using the **Run | Start Debugging** option from the application menu diff --git a/fr-ca/articles/quickstart/native/net-android-ios/files/app-delegate.md b/fr-ca/articles/quickstart/native/net-android-ios/files/app-delegate.md new file mode 100644 index 0000000000..4968ce3e1e --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/files/app-delegate.md @@ -0,0 +1,19 @@ +--- +name: AppDelegate.cs +language: csharp +--- + +```csharp +using Auth0.OidcClient; + +[Register("AppDelegate")] +public class AppDelegate : UIApplicationDelegate +{ + public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation) + { + ActivityMediator.Instance.Send(url.AbsoluteString); + + return true; + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/net-android-ios/files/main-activity.md b/fr-ca/articles/quickstart/native/net-android-ios/files/main-activity.md new file mode 100644 index 0000000000..513b7067ee --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/files/main-activity.md @@ -0,0 +1,57 @@ +--- +name: MainActivity.cs +language: csharp +--- + +```csharp +// Example of a full Android Activity +[Activity(Label = "AndroidSample", MainLauncher = true, Icon = "@drawable/icon", + LaunchMode = LaunchMode.SingleTask)] +[IntentFilter( + new[] { Intent.ActionView }, + Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable }, + DataScheme = "YOUR_ANDROID_PACKAGE_NAME", + DataHost = "{yourDomain}", + DataPathPrefix = "/android/YOUR_ANDROID_PACKAGE_NAME/callback")] +public class MainActivity : Activity +{ + private Auth0Client _auth0Client; + + protected override void OnNewIntent(Intent intent) + { + base.OnNewIntent(intent); + ActivityMediator.Instance.Send(intent.DataString); + } + + protected override void OnCreate(Bundle bundle) + { + base.OnCreate(bundle); + + Auth0ClientOptions clientOptions = new Auth0ClientOptions + { + Domain = "${account.namespace}" + ClientId = "${account.clientId}" + }; + + _auth0Client = new Auth0Client(clientOptions, this); + } + + private async void LoginButtonOnClick(object sender, EventArgs eventArgs) + { + var loginResult = await _auth0Client.LoginAsync(); + + if (loginResult.IsError == false) + { + var user = loginResult.User; + var name = user.FindFirst(c => c.Type == "name")?.Value; + var email = user.FindFirst(c => c.Type == "email")?.Value; + var picture = user.FindFirst(c => c.Type == "picture")?.Value; + } + } + + private async void LogoutButtonOnClick(object sender, EventArgs e) + { + await _auth0Client.LogoutAsync(); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/net-android-ios/files/my-view-controller.md b/fr-ca/articles/quickstart/native/net-android-ios/files/my-view-controller.md new file mode 100644 index 0000000000..e67f6d00fc --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/files/my-view-controller.md @@ -0,0 +1,47 @@ +--- +name: MyViewController.cs +language: csharp +--- + +```csharp +// Example of a full iOS UIViewController +public partial class MyViewController : UIViewController +{ + private Auth0Client _auth0Client; + + public MyViewController() : base("MyViewController", null) + { + } + + public override void ViewDidLoad() + { + base.ViewDidLoad(); + + Auth0ClientOptions clientOptions = new Auth0ClientOptions + { + Domain = "${account.namespace}" + ClientId = "${account.clientId}" + }; + + _auth0Client = new Auth0Client(clientOptions, this); + } + + private async void LoginButton_TouchUpInside(object sender, EventArgs e) + { + var loginResult = await _auth0Client.LoginAsync(); + + if (loginResult.IsError == false) + { + var user = loginResult.User; + var name = user.FindFirst(c => c.Type == "name")?.Value; + var email = user.FindFirst(c => c.Type == "email")?.Value; + var picture = user.FindFirst(c => c.Type == "picture")?.Value; + } + } + + private async void LogoutButton_TouchUpInside(object sender, EventArgs e) + { + await _auth0Client.LogoutAsync(); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/native/net-android-ios/index.yml b/fr-ca/articles/quickstart/native/net-android-ios/index.yml new file mode 100755 index 0000000000..7c97755a57 --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/index.yml @@ -0,0 +1,53 @@ +title: .NET Android and iOS +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/xamarin.png +logo: dotnet +author: + name: Frederik Prijck + email: frederik.prijck@auth0.com + community: false +language: + - C# +framework: + - net-android-ios +hybrid: false +topics: + - quickstart +contentType: tutorial +useCase: quickstart +snippets: + dependencies: native-platforms/xamarin/dependencies + setup: native-platforms/xamarin/setup +seo_alias: xamarin +default_article: 01-login +hidden_articles: + - interactive +articles: + - 01-login +show_steps: true +github: + org: auth0-samples + repo: auth0-xamarin-oidc-samples +sdk: + name: auth0-oidc-client-net + url: https://github.com/auth0/auth0-oidc-client-net + logo: xamarin +requirements: + - Visual Studio 2022+ or Visual Studio for Mac + - Xamarin for Visual Studio + - .NET6+ +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/native/net-android-ios/interactive.md b/fr-ca/articles/quickstart/native/net-android-ios/interactive.md new file mode 100644 index 0000000000..b1a779cc84 --- /dev/null +++ b/fr-ca/articles/quickstart/native/net-android-ios/interactive.md @@ -0,0 +1,208 @@ +--- +title: Add login to your .NET Android or iOS application +default: true +description: This tutorial demonstrates how to add user login with Auth0 to a .NET Android or iOS application. +budicon: 448 +topics: + - quickstarts + - native + - xamarin + - dotnet + - android + - ios +github: + path: Quickstart/01-Login +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/main-activity + - files/app-delegate + - files/my-view-controller +--- + +# Add Login to Your .NET Android and iOS Application + +Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any .NET Android and iOS application using the Auth0 SDKs for [Android](https://www.nuget.org/packages/Auth0.OidcClient.AndroidX/) and [iOS](https://www.nuget.org/packages/Auth0.OidcClient.iOS). + +::: note +This quickstart focusses on .NET Android and iOS, as they are the next generation of `Xamarin.Android` and `Xamarin.iOS`. If you are still using `Xamarin.Android` and `Xamarin.iOS`, you can follow this guide as well as integration is identical and the SDKs are compatible. +::: + +To use this quickstart, you’ll need to: + +- Sign up for a free Auth0 account or log in to Auth0. +- Have a working Android or iOS project using .NET 6 (or above) that you want to integrate with. Alternatively, you can view or download a sample application after logging in. + +<%= include('_configure_urls_interactive') %> + +## Install the Auth0 SDK + +Auth0 provides an [Android](https://www.nuget.org/packages/Auth0.OidcClient.AndroidX/) and [iOS](https://www.nuget.org/packages/Auth0.OidcClient.iOS) SDK to simplify the process of implementing Auth0 authentication in .NET Android and iOS applications. + +Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.AndroidX` or `Auth0.OidcClient.iOS` package, depending on whether you are building an Android or iOS application. + +Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`). + +```ps +Install-Package Auth0.OidcClient.AndroidX +Install-Package Auth0.OidcClient.iOS +``` +``` +dotnet add Auth0.OidcClient.AndroidX +dotnet add Auth0.OidcClient.iOS +``` + +## Instantiate the Auth0Client + +To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain and Client ID. + +```csharp +using Auth0.OidcClient; + +var client = new Auth0Client(new Auth0ClientOptions +{ + Domain = "${account.namespace}", + ClientId = "${account.namespace}" +}, this); +``` + +By default, the SDK will leverage Chrome Custom Tabs for Android and ASWebAuthenticationSession for iOS. + +::::checkpoint + +:::checkpoint-default + +Your `Auth0Client` should now be properly instantiated. Run your application to verify that: +- the `Auth0Client` is instantiated correctly in the `Activity` (Android) or `UIViewController` (iOS) +- your application is not throwing any errors related to Auth0 + +::: + +:::checkpoint-failure +Sorry about that. Here are a couple things to double-check: +* make sure the correct application is selected +* did you save after entering your URLs? +* make sure the domain and client ID are imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Configure Android {{{ data-action="code" data-code="MainActivity.cs#2-9,14-18" }}} + +After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart. + +To handle the callback on Android devices, you need to register an intent that handles this callback URL. An easy way to do this is to register the intent on the same activity from which you called the LoginAsync method to instantiate the authentication flow. + +Ensure to replace `YOUR_ANDROID_PACKAGE_NAME` in the code sample with the actual Package Name for your application, such as com.mycompany.myapplication, and ensure that all the text for the `DataScheme`, `DataHost`, and `DataPathPrefix` is in lower case. Also, set `LaunchMode = LaunchMode.SingleTask` for the Activity, otherwise the system will create a new instance of the activity every time the Callback URL gets called. + +Additionally, you need to handle the intent in the `OnNewIntent` event in your `Activity` class. You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, passing along the URL that was sent in. + +## Configure iOS {{{ data-action="code" data-code="AppDelegate.cs#6-11" }}} + +After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart. + +To handle the callback on iOS devices: + +- Open your application's `Info.plist` file in Visual Studio, and go to the **Advanced** tab. +- Under **URL Types**, click the **Add URL Type** button +- Set the **Identifier** as Auth0, the **URL Schemes** the same as your application's Bundle Identifier, and the **Role** as None + +This is an example of the XML representation of your `info.plist` file after you have added the URL Type: + +```xml +CFBundleURLTypes + + + CFBundleTypeRole + None + CFBundleURLName + Auth0 + CFBundleURLSchemes + + YOUR_BUNDLE_IDENTIFIER + + + +``` + +Additionally, you need to handle the Callback URL in the `OpenUrl` event in your `AppDelegate` class. You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, passing along the URL that was sent in. + +## Add login to your application + +Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. + +```csharp +var loginResult = await client.LoginAsync(); +``` + +If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`. + +::::checkpoint + +:::checkpoint-default + +You should now be able to log in or sign up using a username and password. + +Click the login button and verify that: +* your Android or iOS application redirects you to the Auth0 Universal Login page +* you can log in or sign up +* Auth0 redirects you to your application. + +::: + +:::checkpoint-failure +Sorry about that. Here's something to double-check: +* you called `LoginAsync` as expected + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add logout to your application + +Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart. + +```csharp +await client.LogoutAsync(); +``` + +::::checkpoint + +:::checkpoint-default + +Run your application and click the logout button, verify that: +* your Android or iOS application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings +* you are no longer logged in to your application + +::: + +:::checkpoint-failure +Sorry about that. Here are a couple things to double-check: +* you configured the correct Logout URL +* you called `LogoutAsync` as expected. + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: + +:::: + +## Show User Profile Information + +Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project. + +The Auth0 SDK for Android and iOS provides user information through the `LoginResult.User` property. + +```csharp +if (loginResult.IsError == false) +{ + var user = loginResult.User; + var name = user.FindFirst(c => c.Type == "name")?.Value; + var email = user.FindFirst(c => c.Type == "email")?.Value; + var picture = user.FindFirst(c => c.Type == "picture")?.Value; +} +``` diff --git a/fr-ca/articles/quickstart/native/react-native-expo/00-login.md b/fr-ca/articles/quickstart/native/react-native-expo/00-login.md new file mode 100644 index 0000000000..fcd7798b09 --- /dev/null +++ b/fr-ca/articles/quickstart/native/react-native-expo/00-login.md @@ -0,0 +1,221 @@ +--- +title: Login +description: This tutorial demonstrates how to add user login to an Expo application using Auth0. +budicon: 448 +topics: + - quickstarts + - native + - react-native + - expo +github: + path: 00-Login-Expo +contentType: tutorial +useCase: quickstart +--- + + +This Quickstart is for the Expo framework. To integrate Auth0 into your React Native application, please refer to the [React Native Quickstart](https://auth0.com/docs/quickstart/native/react-native/interactive) + +::: warning +This SDK is not compatible with "Expo Go" app. It is compatible only with Custom Dev Client and EAS builds +::: + +<%= include('../_includes/_getting_started', { library: 'Expo'}) %> + +## Install Dependencies + +How to install the React Native Auth0 module. + +::: note +Please refer to the [official documentation](https://docs.expo.dev/) for additional details on Expo. +::: + +### Yarn + +```bash +yarn add react-native-auth0 +``` + +::: note +For further reference on yarn, check [their official documentation](https://yarnpkg.com/en/docs). +::: + +### npm + +```bash +npm install react-native-auth0 --save +``` + +The first step in adding authentication to your application is to provide a way for your users to log in. The fastest, most secure, and most feature-rich way to do this with Auth0 is to use the hosted [login page](/hosted-pages/login). + +
Universal Login
+ +## Integrate Auth0 in Your Application + +### Setup Auth0 Config Plugin + +The Auth0 package runs custom native code that needs to be configured at build time. We will use [Expo Config Plugin](https://docs.expo.dev/guides/config-plugins/) to achieve this. + +Add the `react-native-auth0` plugin to the [Expo config](https://docs.expo.dev/workflow/configuration/) file at `app.json` or `app.config.js`. + +```json +{ + "expo": { + ... + "plugins": [ + [ + "react-native-auth0", + { + "domain": "${account.namespace}" + } + ] + ] + } +} +``` + +### Generate native source code + +You must generate the native code for the above configuration to be set. To do this, run the following command: + +```bash +expo prebuild +``` + +You will be prompted to provide the [Android package](https://github.com/expo/fyi/blob/main/android-package.md) and [iOS bundle identifier](https://github.com/expo/fyi/blob/main/bundle-identifier.md) if they are not already present in the Expo config: + +```bash +? What would you like your Android package name to be? > com.auth0samples # or your desired package name + +? What would you like your iOS bundle identifier to be? > com.auth0samples # or your desired bundle identifier +``` + +These values are found in the Expo config file at `app.json` or `app.config.js`. It will be used in the callback and logout URLs: + +```json +{ + ... + "android": { + "package": "YOUR_ANDROID_PACKAGE_NAME_IS_FOUND_HERE" + }, + "ios": { + "bundleIdentifier": "YOUR_IOS_BUNDLE_IDENTIFIER_IS_FOUND_HERE" + } + } +} +``` + +### Configure Callback and Logout URLs + +The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your application. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie. + +If the callback and logout URLs are not set, users will be unable to log in and out of the application and will get an error. + +Go to the settings page of your [Auth0 application](${manage_url}/#/applications/${account.clientId}/settings) and add the corresponding URL to **Allowed Callback URLs** and **Allowed Logout URLs**, according to the platform of your application. If you are using a [custom domain](/customize/custom-domains), use the value of your custom domain instead of the Auth0 domain from the settings page. + +#### iOS +```text +BUNDLE_IDENTIFIER.auth0://${account.namespace}/ios/BUNDLE_IDENTIFIER/callback +``` +#### Android +```text +PACKAGE_NAME.auth0://${account.namespace}/android/PACKAGE_NAME/callback +``` + +::: note +If you are following along with our sample project, set this +- for iOS - `com.auth0samples.auth0://${account.namespace}/ios/com.auth0samples/callback` +- for Android - `com.auth0samples.auth0://${account.namespace}/android/com.auth0samples/callback` +::: + +## Add login to your app + +First, import the `useAuth0` hook and the `Auth0Provider` component from the `react-native-auth0` package. + +```js +import {useAuth0, Auth0Provider} from 'react-native-auth0'; +``` + +Next, wrap your application in the `Auth0Provider` component, providing your Auth0 domain and Client ID values: + +```js +const App = () => { + return ( + + {/* your application */} + + ); +}; +``` + +Finally, present the hosted login screen using the `authorize` method from the `useAuth0` hook. See this usage example showing logging in on a button click: + +```js +const LoginButton = () => { + const {authorize} = useAuth0(); + + const onPress = async () => { + try { + await authorize(); + } catch (e) { + console.log(e); + } + }; + + return ', + standalone: true +}) +export class AuthButtonComponent { + // Inject the authentication service into your component through the constructor + constructor(public auth: AuthService) {} +} +``` + +:::panel Checkpoint +Add the `AuthButtonComponent` component to your application. When you click it, verify that your Angular application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects back to your application's homepage. +::: + +![Auth0 Universal Login](/media/quickstarts/universal-login.png) + +<%= include('../_includes/_auth_note_dev_keys') %> + +## Add Logout to Your Application + +Now that you can log in to your Angular application, you need [a way to log out](/logout/guides/logout-auth0). You can create a logout button using the `logout()` method from the `AuthService` service. Executing `logout()` redirects your users to your [Auth0 logout endpoint](/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them to your application. + +Here is a modified version of the `AuthButtonComponent` component above that uses both `loginWithRedirect()` and `logout()`, as well as checking the authentication state using the `isAuthenticated$` observable: + +```javascript +import { Component, Inject } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { DOCUMENT } from '@angular/common'; + +@Component({ + selector: 'app-auth-button', + template: ` + + + + + + + + `, + standalone: true +}) +export class AuthButtonComponent { + constructor(@Inject(DOCUMENT) public document: Document, public auth: AuthService) {} +} +``` + +Specify the `returnTo` option when calling `logout` to tell Auth0 where it should redirect to after a successful logout. This value must be specified in [the **Allowed Logout URLs** setting](#configure-logout-urls) in the dashboard. + +:::note +Here we use `http://localhost:4200` as the value for `logoutParams.returnTo`, but the associate sample uses `window.location.origin`, which in this case would resolve to the same value. Ultimately, this value should point to the root URL for your application. +::: + +:::panel Checkpoint +Add a button to the component template that logs the user out of your application. When you click it, verify that your Angular application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +The Auth0 Angular SDK helps you retrieve the [profile information](/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` observable exposed by the `AuthService` service. Take this `Profile` component as an example of how to use it: + +```javascript +import { Component } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-user-profile', + template: ` +
    +
  • {{ user.name }}
    • +
  • {{ user.email }}
    • +
`, + standalone: true +}) +export class UserProfileComponent { + constructor(public auth: AuthService) {} +} +``` + +The `user$` observable contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. Fortunately, the `user$` observable is configured so that it only starts to emit values once the `isAuthenticated$` observable is true, so there is no need to manually check the authentication state before accessing the user profile data. + +:::panel Checkpoint +Verify that you can display the `user.name` or [any other `user` property](/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in. +::: \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/02-calling-an-api.md b/fr-ca/articles/quickstart/spa/angular/02-calling-an-api.md new file mode 100644 index 0000000000..0bff352ad4 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/02-calling-an-api.md @@ -0,0 +1,163 @@ +--- +title: Call an API +description: This tutorial demonstrates how to make API calls to the Auth0 Management API. +budicon: 448 +topics: + - quickstarts + - spa + - angular + - api +github: + path: Standalone +sample_download_required_data: + - client + - api +contentType: tutorial +useCase: quickstart +--- + + + +:::note +Visit the [Integrate Angular with an API Server](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication#integrate-angular-with-an-api-server) section of the [Angular Authentication By Example](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication) guide for a deep dive into calling a protected API from Angular. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application. +::: + +<%= include('../_includes/_calling_api_preamble_api2") %> + +This article builds upon [the previous chapter](/quickstart/spa/angular-next), adding the capability to automatically attach an access token to outgoing requests made using Angular's built-in `HttpClient` service. + +:::note +If you followed the [previous section where you added user log in to Angular](/quickstart/spa/angular-next#add-login-to-your-application), make sure that you log out of your application as you'll need a new access token to call APIs. +::: + +## Provide the HTTP Interceptor + +To install and configure the HTTP interceptor, perform the following steps: + +* Import the `authHttpInterceptorFn` type from the Auth0 Angular SDK +* Import `provideHttpClient` from `@angular/common/http` +* Register `authHttpInterceptorFn` in `provideHttpClient` using `withInterceptors`. +* Add configuration to specify audience, scope, and which requests should have an `Authorization` header attached automatically + +The following is an example of an Angular module (based upon the default implementation when you create a new app using `ng new`) that supports `AuthHttpInterceptor`, configured to call the Auth0 Management API with the ability to read the current user profile: + +To begin, open your `app.module.ts` file and add the necessary imports at the top: + +```javascript +// Import the injector module and the HTTP client module from Angular +import { provideHttpClient, withInterceptors } from '@angular/common/http'; + +// Import the HTTP interceptor from the Auth0 Angular SDK +import { authHttpInterceptorFn } from '@auth0/auth0-angular'; +``` + +Next, add `provideHttpClient` to the `providers` of the `bootstrapApplication` function, and add `authHttpInterceptorFn` using `withInterceptors`: + +```javascript +bootstrapApplication(AppComponent, { + providers: [ + provideHttpClient(withInterceptors([authHttpInterceptorFn])), + ] +}); +``` + +Finally, modify the configuration given to `provideAuth0()` to specify the `audience` and `scope` values required by the API you want to call, as well as the API routes that should be intercepted by `authHttpInterceptorFn`. + +In this case, the audience and scope for the Auth0 Management API are given, which allows your app to retrieve information about the current user. + +```javascript +provideAuth0({ + // The domain and clientId were configured in the previous chapter + domain: '${account.namespace}', + clientId: '${account.clientId}', + + authorizationParams: { + redirect_uri: window.location.origin, + + // Request this audience at user authentication time + audience: 'https://${account.namespace}/api/v2/', + + // Request this scope at user authentication time + scope: 'read:current_user', + }, + + // Specify configuration for the interceptor + httpInterceptor: { + allowedList: [ + { + // Match any request that starts 'https://${account.namespace}/api/v2/' (note the asterisk) + uri: 'https://${account.namespace}/api/v2/*', + tokenOptions: { + authorizationParams: { + // The attached token should target this audience + audience: 'https://${account.namespace}/api/v2/', + + // The attached token should have these scopes + scope: 'read:current_user' + } + } + } + ] + } +}) +``` + +:::note +As Auth0 can only issue tokens for custom scopes that exist on your API, ensure that you define the scopes used above when [setting up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0. +::: + +Please [refer to the docs](https://github.com/auth0/auth0-angular/blob/main/EXAMPLES.md#configure-authhttpinterceptor-to-attach-access-tokens) for more information on the available options for the HTTP interceptor. + +## Make an API Call + +With your app module configured with the HTTP interceptor from the Angular SDK, calls you make using Angular's built-in `HttpClient` to the Auth0 Management API will have the appropriate access token specified in the `Authorization` header. Let's use this as an example for showing user metadata. + +The following component demonstrates how to display the `user_metadata` field from the authenticated user's profile, by making a call to the `/api/v2/users` endpoint using `HttpClient`: + +```js +import { Component, OnInit } from '@angular/core'; +import { concatMap, tap, map } from 'rxjs/operators'; + +// Import the HttpClient for making API requests +import { HttpClient } from '@angular/common/http'; + +// Import AuthService from the Auth0 Angular SDK to get access to the user +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-metadata', + template: `
+ 
{{ metadata | json }}
+
`, + standalone: true, +}) +export class UserMetadataComponent implements OnInit { + metadata = {}; + + // Inject both AuthService and HttpClient + constructor(public auth: AuthService, private http: HttpClient) {} + + ngOnInit(): void { + this.auth.user$ + .pipe( + concatMap((user) => + // Use HttpClient to make the call + this.http.get( + encodeURI(`https://${account.namespace}/api/v2/users/<%= "${user?.sub}" %>`) + ) + ), + map((user: any) => user.user_metadata), + tap((meta) => (this.metadata = meta)) + ) + .subscribe(); + } +} +``` + +This call succeeds because the HTTP interceptor took care of making sure the correct access token was included in the outgoing request. + +:::panel Checkpoint +Your application will show an empty JSON object if you have not set any `user_metadata` for the logged-in user. To further test out this integration, head to the [Users section of the Auth0 dashboard](https://manage.auth0.com/#/users) and click on the user who is logged in. Update the `user_metadata` section with a value like `{ "theme": "dark" }` and click "Save". Refresh your Angular application and verify that it reflects the new `user_metadata`. +::: + +Please refer to the [Auth0 API quickstarts](https://auth0.com/docs/quickstart/backend) to learn how to integrate Auth0 with your backend platform. diff --git a/fr-ca/articles/quickstart/spa/angular/download.md b/fr-ca/articles/quickstart/spa/angular/download.md new file mode 100644 index 0000000000..6780e018b5 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/download.md @@ -0,0 +1,29 @@ + + +To run the sample follow these steps: + +1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:4200 +``` +2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:4200 +``` +3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:4200 +``` +4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory: +```bash +npm install && npm start +``` + +You can also run it from a [Docker](https://www.docker.com) image with the following commands: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/files/index.md b/fr-ca/articles/quickstart/spa/angular/files/index.md new file mode 100644 index 0000000000..da47c6b504 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/files/index.md @@ -0,0 +1,22 @@ +--- +name: main.ts +language: javascript +--- + +```javascript +import { bootstrapApplication } from '@angular/platform-browser'; +import { provideAuth0 } from '@auth0/auth0-angular'; +import { AppComponent } from './app.component'; + +bootstrapApplication(AppComponent, { + providers: [ + provideAuth0({ + domain: '${account.namespace}', + clientId: '${account.clientId}', + authorizationParams: { + redirect_uri: window.location.origin + } + }), + ] +}); +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/files/login.md b/fr-ca/articles/quickstart/spa/angular/files/login.md new file mode 100644 index 0000000000..d5c245b6dc --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/files/login.md @@ -0,0 +1,22 @@ +--- +name: login-button.ts +language: javascript +--- + +```javascript +import { Component } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-login-button', + template: '', + standalone: true +}) +export class LoginButtonComponent { + constructor(private auth: AuthService) {} + + login() { + this.auth.loginWithRedirect(); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/files/logout.md b/fr-ca/articles/quickstart/spa/angular/files/logout.md new file mode 100644 index 0000000000..126448a5e0 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/files/logout.md @@ -0,0 +1,34 @@ +--- +name: logout-button.ts +language: javascript +--- + +```javascript +import { Component, Inject } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; +import { DOCUMENT } from '@angular/common'; + +@Component({ + selector: 'app-logout-button', + template: ` + + `, + standalone: true +}) +export class LogoutButtonComponent { + constructor( + @Inject(DOCUMENT) public document: Document, + private auth: AuthService + ) {} + + logout() { + this.auth.logout({ + logoutParams: { + returnTo: this.document.location.origin + } + }); + } +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/files/profile.md b/fr-ca/articles/quickstart/spa/angular/files/profile.md new file mode 100644 index 0000000000..562ec1280b --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/files/profile.md @@ -0,0 +1,22 @@ +--- +name: user-profile.ts +language: javascript +--- + +```javascript +import { Component } from '@angular/core'; +import { AuthService } from '@auth0/auth0-angular'; + +@Component({ + selector: 'app-user-profile', + template: ` +
    +
  • {{ user.name }}
    • +
  • {{ user.email }}
    • +
`, + standalone: true +}) +export class UserProfileComponent { + constructor(public auth: AuthService) {} +} +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/angular/index.yml b/fr-ca/articles/quickstart/spa/angular/index.yml new file mode 100644 index 0000000000..69ed119319 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/index.yml @@ -0,0 +1,57 @@ +title: Angular +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/angular.png +logo: angular +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - angular +logo_name: angular2 +language: + - Javascript +framework: + - Angular +topics: + - quickstart +contentType: tutorial +useCase: quickstart +show_releases: true +sdk: + name: auth0-angular + url: https://github.com/auth0/auth0-angular + logo: angular +snippets: + dependencies: application-platforms/angular2/dependencies + setup: application-platforms/angular2/setup + use: application-platforms/angular2/use +seo_alias: angular +default_article: 01-login +articles: + - 01-login + - 02-calling-an-api +hidden_articles: + - "interactive" +show_steps: true +github: + org: auth0-samples + repo: auth0-angular-samples + branch: main +requirements: + - Angular 12+ +next_steps: + - path: 01-login + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" diff --git a/fr-ca/articles/quickstart/spa/angular/interactive.md b/fr-ca/articles/quickstart/spa/angular/interactive.md new file mode 100644 index 0000000000..7514393223 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/angular/interactive.md @@ -0,0 +1,160 @@ +--- +title: Add Login to your Angular Application +description: "Auth0 allows you to add authentication to your Angular application and gain access to user profile information. This guide demonstrates common snippets used to integrate Auth0 with any new or existing Angular application using the Auth0 Angular SDK." +interactive: true +files: + - files/index + - files/login + - files/logout + - files/profile +github: + path: Sample-01 +--- + +:::note +Visit the [Angular Authentication By Example](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication) guide for a deep dive into implementing user authentication in Angular. This guide provides additional details on how to create a sign-up button, add route guards, and call a protected API from Angular. +::: + +# Add Login to Your Angular Application + +Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Angular application using the [Auth0 Angular SDK](https://github.com/auth0/auth0-angular). + +To use this quickstart, you’ll need to: + +- Sign up for a free Auth0 account or log in to Auth0. +- Have a working Angular project that you want to integrate with. Alternatively, you can view or download a sample application after logging in. + +<%= include('../../_includes/_configure_auth0_interactive', { + callback: 'http://localhost:4200', + returnTo: 'http://localhost:4200', + webOriginUrl: 'http://localhost:4200', + showWebOriginInfo: true +}) %> + +## Install the Auth0 Angular SDK + +Auth0 provides an [Angular SDK](https://github.com/auth0/auth0-angular) to simplify the process of implementing Auth0 authentication and authorization in Angular applications. + +Install the Auth0 Angular SDK by running the following command in your terminal: + +```bash +npm install @auth0/auth0-angular +``` + +The SDK exposes several types that help integrate Auth0 in an Angular application idiomatically, including a module and an authentication service. + +## Register and providing Auth0 {{{ data-action="code" data-code="main.ts#7:13" }}} + +The SDK exports `provideAuth0`, which is a provide function that contains all the services required for the SDK to function. To register this with your application: + +1. Open the `main.ts` file. +2. Import the `provideAuth0` function from the `@auth0/auth0-angular` package. +3. Add `provideAuth0` to the application by adding it to the `providers` inside `bootstrapApplication`. +4. Inject `AuthService` into `AppComponent`. + +The `provideAuth0` function takes the properties `domain` and `clientId`; the values of these properties correspond to the **Domain** and **Client ID** values that you can find under **Settings** in the Single-Page Application (SPA) that you registered with Auth0. On top of that, we configure `authorizationParams.redirect_uri`, which allows Auth0 to redirect the user back to the specific URL after successfully authenticating. + +<%= include('../_includes/_auth_note_custom_domains') %> + +## Add login to your application {{{ data-action=code data-code="login-button.ts#11:13" }}} + +Now that you have configured your Auth0 Application and the Auth0 Angular SDK, you need to set up login for your project. To do this, you will use the SDK’s `loginWithRedirect()` method from the `AuthService` class to redirect users to the Auth0 Universal Login page where Auth0 can authenticate them. After a user successfully authenticates, they will be redirected to your application and the callback URL you set up earlier in this quickstart. + +Create a login button in your application that calls `loginWithRedirect()` when selected. + +::::checkpoint + +:::checkpoint-default +You should now be able to log in to your application. + +Run your application, and select the login button. Verify that: + +- you can log in or sign up using a username and password. +- your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page. +- you are redirected to Auth0 for authentication. +- Auth0 successfully redirects back to your application after authentication. +- you do not receive any errors in the console related to Auth0. + +::: + +:::checkpoint-failure +Sorry about that. Here are a few things to double check: + +- make sure you configured the correct `authorizationParams.redirect_uri` +- make sure you added the `LoginButtonComponent` button to the module's declarations + +Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com). + +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="logout-button.ts#19:25" }}} + +Users who log in to your project will also need [a way to log out](/logout/guides/logout-auth0). The SDK provides a `logout()` method on the `AuthService` class that you can use to log a user out of your app. When users log out, they will be redirected to your [Auth0 logout endpoint](/api/authentication?javascript#logout), which will then immediately redirect them to your application and the logout URL you set up earlier in this quickstart. + +Create a logout button in your application that calls `logout()` when selected. + +:::note +The SDK exposes an `isAuthenticated$` observable on the `AuthService` class that allows you to check whether a user is authenticated or not. You can render the login and logout buttons conditionally based on the value of the `isAuthenticated$` observable. Alternatively, you can use a single button to combine both login and logout buttons as well as their conditional rendering. +::: + +::::checkpoint + +:::checkpoint-default +You should now be able to log out of your application. + +Run your application, log in, and select the logout button. Verify that: + +- you are redirected to Auth0's logout endpoint. +- Auth0 successfully redirects back to your application and the correct logout URL. +- you are no longer logged in to your application. +- you do not receive any errors in the console related to Auth0. + +::: + +:::checkpoint-failure +Sorry about that. Here are a few things to double check: + +- make sure that you configured the logout URL as one of the **Allowed Logout URLS** in your application's **Settings** +- check that you added the `LogoutButtonComponent` to the module's declarations +- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors + +Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com). + +::: + +:::: + +## Show user profile information {{{ data-action=code data-code="user-profile.ts" }}} + +Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to personalize the user interface by displaying a logged-in user’s name or profile picture. + +The Auth0 Angular SDK provides user information through the `user$` observable exposed by the `AuthService` class. Because the `user$` observable contains sensitive information and artifacts related to the user's identity, its availability depends on the user's authentication status. Fortunately, the `user$` observable is configured to only emit values once the `isAuthenticated$` observable is true, so there is no need to manually check the authentication state before accessing the user profile data. + +The SDK also exposes an `isAuthenticated$` observable on the `AuthService` class that allows you to check whether a user is authenticated or not, which you can use to determine whether to show or hide UI elements, for example. + +Review the `UserProfileComponent` code in the interactive panel to see examples of how to use these functions. + +::::checkpoint + +:::checkpoint-default +You should now be able to view user profile information. + +Run your application, and verify that: + +- user information displays correctly after you have logged in. +- user information does not display after you have logged out. + +::: + +:::checkpoint-failure +Sorry about that. Here are a few things to double check: + +- make sure you are logged in +- make sure you are trying to access an existing property such as `user.name` +- make sure you added the `UserProfileComponent` component to the correct module's declarations + +Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com). +::: + +:::: diff --git a/fr-ca/articles/quickstart/spa/config.yml b/fr-ca/articles/quickstart/spa/config.yml new file mode 100644 index 0000000000..51f64e8751 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/config.yml @@ -0,0 +1,2 @@ +sample_download_required_data: + - client diff --git a/fr-ca/articles/quickstart/spa/flutter/01-login.md b/fr-ca/articles/quickstart/spa/flutter/01-login.md new file mode 100644 index 0000000000..a68d11d9fe --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/01-login.md @@ -0,0 +1,184 @@ +--- +title: Add login to your Flutter app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to an Flutter Web application using the Auth0 Flutter SDK +budicon: 448 +topics: + - quickstarts + - native + - flutter + - dart + - ios + - android +contentType: tutorial +useCase: quickstart +github: + path: sample +--- + + + +# Add login to your Flutter app + +Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with a Flutter Web application using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter). + +:::note +The Flutter SDK currently only supports Flutter applications running on Android, iOS, or Web platforms. +::: + +## Getting started + +This quickstart assumes you already have a [Flutter](https://flutter.dev/) application up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app. + +You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli). + +<%= include('../_includes/_getting_started', { library: 'Flutter', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %> + +<%= include('_install_sdk') %> + +## Add login to your app + +[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security, and the fullest array of features. + +Integrate Auth0 Universal Login in your Flutter app by importing the SDK and instantiating the `Auth0` class using your Auth0 domain and Client ID values. See this example, which instantiates the class inside a widget state object: + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:auth0_flutter/auth0_flutter_web.dart'; + +class MainView extends StatefulWidget { + const MainView({Key? key}) : super(key: key); + + @override + State createState() => _MainViewState(); +} + +class _MainViewState extends State { + Credentials? _credentials; + + late Auth0Web auth0; + + @override + void initState() { + super.initState(); + auth0 = Auth0Web('${account.namespace}', '${account.clientId}'); + } + + @override + Widget build(BuildContext context) { + // ... + } +} +``` + +Next, redirect your users to the Auth0 Universal Login page using `loginWithRedirect`. See this example of a `ElevatedButton` widget that logs the user in when clicked: + +:::note +You will normally need to specify the `redirectUrl` parameter to `loginWithRedirect`. Omitting this will cause Auth0 to use the [default login route](https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes), which is not configured by default. +::: + +```dart +if (_credentials == null) { + ElevatedButton( + onPressed: () => auth0.loginWithRedirect(redirectUrl: 'http://localhost:3000'), + child: const Text("Log in") + ) +} +``` + +When a user logs in, they are redirected back to your application. You are then able to access the ID and access tokens for this user by calling `onLoad` during startup and handling the credentials that are given to you: + +```dart +auth0.onLoad().then((final credentials) => setState(() { + // Handle or store credentials here + _credentials = credentials; + })); +``` + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `loginWithRedirect()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your application. + +Verify that you can access `credentials` as a result of calling `onLoad` and that you're able to access the ID and access tokens. +::: + +:::checkpoint-failure +If your application did not launch successfully: + +- Ensure the Allowed Callback URLs are set properly +- Verify you saved your changes after entering your URLs +- Make sure the domain and client ID values are imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add logout to your app + +To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout). + +See this example of an `ElevatedButton` widget that logs the user out of the app: + +```dart +ElevatedButton( + onPressed: () async { + await auth0.logout(); + }, + child: const Text("Log out")) +``` + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `logout()` and logs the user out of your application. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your application. +::: + +:::checkpoint-failure +If your application did not log out successfully: + +- Ensure the Allowed Logout URLs are set properly +- Verify you saved your changes after entering your URLs + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Show user profile information + +The user profile automatically retrieves user profile properties for you when the page loads, and can be accessed and stored by calling `onLoad` during application startup. The returned object from `onLoad` contains a `user` property with all the user profile properties. This is internally populated by decoding the ID token. + +See this example of a `View` component that displays the user profile on the screen: + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:flutter/material.dart'; + +class ProfileView extends StatelessWidget { + const ProfileView({Key? key, required this.user}) : super(key: key); + + final UserProfile user; + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (user.name != null) Text(user.name!), + if (user.email != null) Text(user.email!) + ], + ); + } +} +``` + +::::checkpoint +:::checkpoint-default +Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`. +::: +:::checkpoint-failure +If your application did not return user profile information: + +- Verify the ID token is valid + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/spa/flutter/_install_sdk.md b/fr-ca/articles/quickstart/spa/flutter/_install_sdk.md new file mode 100644 index 0000000000..63b1fb626d --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/_install_sdk.md @@ -0,0 +1,15 @@ + + +## Install the Auth0 Flutter SDK + +Add the Auth0 Flutter SDK into the project: + +```shell +flutter pub add auth0_flutter +``` + +Add the following script tag to your `index.html` page: + +```html + +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/flutter/download.md b/fr-ca/articles/quickstart/spa/flutter/download.md new file mode 100644 index 0000000000..7e0790884d --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/download.md @@ -0,0 +1,33 @@ + + +To run the sample follow these steps: + +1. Set the **Allowed Callback URLs** and **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to the following value so it works for both Android and iOS apps: + +```text +com.auth0.samples.FlutterSample://${account.namespace}/ios/com.auth0.samples.FlutterSample/callback,com.auth0.sample://${account.namespace}/android/com.auth0.sample/callback +``` + +2. Rename the file `.env.example` to `.env` and fill in the following values: + +```sh +AUTH0_DOMAIN=${account.namespace} +AUTH0_CLIENT_ID=${account.clientId} +AUTH0_CUSTOM_SCHEME=com.auth0.sample +``` + +3. Rename the file `strings.xml.example` in `android/app/src/main/res/values` to `strings.xml` and fill in the following values: + +```xml + + + ${account.namespace} + com.auth0.sample + +``` + +4. Use the [Flutter CLI's](https://docs.flutter.dev/reference/flutter-cli) `run` command to run the app: + +```sh +flutter run +``` diff --git a/fr-ca/articles/quickstart/spa/flutter/files/main.md b/fr-ca/articles/quickstart/spa/flutter/files/main.md new file mode 100644 index 0000000000..a1241cf2bf --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/files/main.md @@ -0,0 +1,59 @@ +--- +name: main_view.dart +language: dart +--- + + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:auth0_flutter/auth0_flutter_web.dart'; +import 'package:flutter/material.dart'; +import 'profile_view.dart'; + +class MainView extends StatefulWidget { + const MainView({Key? key}) : super(key: key); + + @override + State createState() => _MainViewState(); +} + +class _MainViewState extends State { + Credentials? _credentials; + + late Auth0Web auth0; + + @override + void initState() { + super.initState(); + auth0 = Auth0Web('${account.namespace}', '${account.clientId}'); + + auth0.onLoad().then((final credentials) => setState(() { + _credentials = credentials; + })); + } + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (_credentials == null) + ElevatedButton( + onPressed: () => auth0.loginWithRedirect(redirectUrl: 'http://localhost:3000'), + child: const Text("Log in")) + else + Column( + children: [ + ProfileView(user: _credentials!.user), + ElevatedButton( + onPressed: () async { + await auth0.logout(returnToUrl: 'http://localhost:3000'); + }, + child: const Text("Log out")) + ], + ) + ], + ); + } +} +``` diff --git a/fr-ca/articles/quickstart/spa/flutter/files/profile.md b/fr-ca/articles/quickstart/spa/flutter/files/profile.md new file mode 100644 index 0000000000..16d93d8620 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/files/profile.md @@ -0,0 +1,27 @@ +--- +name: profile_view.dart +language: dart +--- + + +```dart +import 'package:auth0_flutter/auth0_flutter.dart'; +import 'package:flutter/material.dart'; + +class ProfileView extends StatelessWidget { + const ProfileView({Key? key, required this.user}) : super(key: key); + + final UserProfile user; + + @override + Widget build(BuildContext context) { + return Column( + mainAxisAlignment: MainAxisAlignment.center, + children: [ + if (user.name != null) Text(user.name!), + if (user.email != null) Text(user.email!) + ], + ); + } +} +``` diff --git a/fr-ca/articles/quickstart/spa/flutter/index.yml b/fr-ca/articles/quickstart/spa/flutter/index.yml new file mode 100644 index 0000000000..0b5b439218 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/index.yml @@ -0,0 +1,52 @@ +title: Flutter (Web) +logo_name: flutter +logo: flutter +author: + name: Steve Hobbs + email: steve.hobbs@auth0.com + community: false +alias: + - flutter +language: + - Dart +framework: + - Flutter +sdk: + name: auth0-flutter + url: https://www.github.com/auth0/auth0-flutter/ + logo: flutter +hybrid: true +topics: + - quickstart +contentType: tutorial +useCase: quickstart +seo_alias: flutter +default_article: 01-login +articles: + - 01-login +hidden_articles: + - interactive +show_steps: true +github: + org: auth0-samples + repo: auth0-flutter-samples + branch: main +requirements: + - Flutter 3+ + - Xcode 14+ (for iOS) + - Android Studio 4+ (for Android) +next_steps: + - path: interactive + list: + - text: Configure other identity providers + icon: 345 + href: '/identityproviders' + - text: Enable multifactor authentication + icon: 345 + href: '/multifactor-authentication' + - text: Learn about attack protection + icon: 345 + href: '/attack-protection' + - text: Learn about Actions + icon: 345 + href: '/customize/actions' diff --git a/fr-ca/articles/quickstart/spa/flutter/interactive.md b/fr-ca/articles/quickstart/spa/flutter/interactive.md new file mode 100644 index 0000000000..143ed0b85d --- /dev/null +++ b/fr-ca/articles/quickstart/spa/flutter/interactive.md @@ -0,0 +1,116 @@ +--- +title: Add login to your Flutter app +default: true +description: This tutorial demonstrates how to add user login with Auth0 to a Flutter Web application using the Auth0 Flutter SDK +budicon: 448 +topics: + - quickstarts + - flutter + - dart + - spa + - web + - browser +contentType: tutorial +useCase: quickstart +interactive: true +files: + - files/main + - files/profile +github: + path: sample +--- + + + +# Add Login to Your Flutter Application + +Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with a Flutter application using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter). + +:::note +The Flutter SDK currently only supports Flutter applications running on Android, iOS, or Web platforms. +::: + +This quickstart assumes you already have a [Flutter](https://flutter.dev/) application up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app. + +You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli). + +<%= include('../_includes/_getting_started', { library: 'Flutter', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %> + +<%= include('_install_sdk') %> + +## Add login to your application {{{ data-action="code" data-code="main_view.dart#34" }}} + +[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security, and the fullest array of features. + +Integrate Auth0 Universal Login in your Flutter Web app by using the `Auth0Web` class. Redirect your users to the Auth0 Universal Login page using `loginWithRedirect()`. + +:::note +You will normally need to specify the `redirectUrl` parameter to `loginWithRedirect`. Omitting this will cause Auth0 to use the [default login route](https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes), which is not configured by default. +::: + +When a user logs in, they are redirected back to your application. You are then able to access the ID and access tokens for this user by calling `onLoad` during startup and handling the credentials that are given to you: + +```dart +auth0.onLoad().then((final credentials) => setState(() { + // Handle or store credentials here + _credentials = credentials; + })); +``` + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `loginWithRedirect()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your application. + +Verify that you can access `credentials` as a result of calling `onLoad` and that you're able to access the ID and access tokens. +::: + +:::checkpoint-failure +If your application did not launch successfully: + +- Ensure the Allowed Callback URLs are set properly +- Verify you saved your changes after entering your URLs +- Make sure the domain and client ID values are imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="main_view.dart#46"}}} + +To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout). + +:::note +You will normally want to specify `returnToUrl` when calling `logout`, otherwise Auth0 [will default to the first URL in the Allowed Logout URLs list](https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout). +::: + +::::checkpoint +:::checkpoint-default +Add a button to your app that calls `logout()` and logs the user out of your application. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your application. +::: + +:::checkpoint-failure +If your application did not log out successfully: + +- Ensure the Allowed Logout URLs are set properly +- Verify you saved your changes after entering your URLs + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: + +## Show user profile information {{{ data-action="code" data-code="profile_view.dart" }}} + +The user profile automatically retrieves user profile properties for you when the page loads, and can be accessed and stored by calling `onLoad` during application startup. The returned object from `onLoad` contains a `user` property with all the user profile properties. This is internally populated by decoding the ID token. + +::::checkpoint +:::checkpoint-default +Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`. +::: +:::checkpoint-failure +If your application did not return user profile information: + +- Verify the ID token is valid + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: +:::: diff --git a/fr-ca/articles/quickstart/spa/react/01-login.md b/fr-ca/articles/quickstart/spa/react/01-login.md new file mode 100644 index 0000000000..5f432df0b2 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/01-login.md @@ -0,0 +1,152 @@ +--- +title: Login +description: "Auth0 allows you to add authentication to your React application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing React application using the Auth0 React SDK." +budicon: 448 +topics: + - quickstarts + - spa + - react + - login +github: + path: Sample-01 +contentType: tutorial +useCase: quickstart +--- + + +:::note +Visit the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into implementing user authentication in React. This guide provides additional details on how to create a sign-up button and add route guards using React Router. +::: + +<%= include('../_includes/_getting_started', { library: 'React', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %> + +<%= include('../../_includes/_auth0-react-install.md') %> + +### Configure the `Auth0Provider` component + +Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK. + +```javascript +import React from 'react'; +import { createRoot } from 'react-dom/client'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +const root = createRoot(document.getElementById('root')); + +root.render( + + + , +); +``` + +The `Auth0Provider` component takes the following props: + +- `domain` and `clientId`: The values of these properties correspond to the "Domain" and "Client ID" values present under the "Settings" of the single-page application that you registered with Auth0. + +<%= include('../_includes/_auth_note_custom_domains') %> + +- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0. + +`Auth0Provider` stores the authentication state of your users and the state of the SDK — whether Auth0 is ready to use or not. It also exposes helper methods to log in and log out your users, which you can access using the `useAuth0()` hook. + +:::panel Checkpoint +Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0. +::: + +## Add Login to Your Application + +The Auth0 React SDK gives you tools to quickly implement user authentication in your React application, such as creating a [login](https://auth0.com/docs/login) button using the `loginWithRedirect()` method from the `useAuth0()` hook. Executing `loginWithRedirect()` redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application. + +```javascript +import React from "react"; +import { useAuth0 } from "@auth0/auth0-react"; + +const LoginButton = () => { + const { loginWithRedirect } = useAuth0(); + + return ; +}; + +export default LoginButton; +``` + +<%= include('../../_includes/_auth0-react-classes-info.md') %> + +:::panel Checkpoint +Add the `LoginButton` component to your application. When you click it, verify that your React application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider. + +Once that's complete, verify that Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` that you used to configure the `Auth0Provider`. +::: + +![Auth0 Universal Login](/media/quickstarts/universal-login.png) + +<%= include('../_includes/_auth_note_dev_keys') %> + +## Add Logout to Your Application + +Now that you can log in to your React application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). You can create a logout button using the `logout()` method from the `useAuth0()` hook. Executing `logout()` redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them to your application. + +```javascript +import React from "react"; +import { useAuth0 } from "@auth0/auth0-react"; + +const LogoutButton = () => { + const { logout } = useAuth0(); + + return ( + + ); +}; + +export default LogoutButton; +``` + +:::panel Checkpoint +Add the `LogoutButton` component to your application. When you click it, verify that your React application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application. +::: + +## Show User Profile Information + +The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it: + +```javascript +import React from "react"; +import { useAuth0 } from "@auth0/auth0-react"; + +const Profile = () => { + const { user, isAuthenticated, isLoading } = useAuth0(); + + if (isLoading) { + return
Loading ...
; + } + + return ( + isAuthenticated && ( +
+ {user.name} +

{user.name}

+

{user.email}

+
+ ) + ); +}; + +export default Profile; +``` + +The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`. + +:::panel Checkpoint +Verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in. +::: + diff --git a/fr-ca/articles/quickstart/spa/react/02-calling-an-api.md b/fr-ca/articles/quickstart/spa/react/02-calling-an-api.md new file mode 100644 index 0000000000..fc7b231bc0 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/02-calling-an-api.md @@ -0,0 +1,165 @@ +--- +title: Call an API +description: This tutorial demonstrates how to make API calls to the Auth0 Management API. +budicon: 448 +topics: + - quickstarts + - spa + - react + - login +github: + path: Sample-01 +contentType: tutorial +sample_download_required_data: + - client + - api +useCase: quickstart +--- + + +:::note +Visit the [Integrate React with an API Server](https://developer.auth0.com/resources/guides/spa/react/basic-authentication#integrate-react-with-an-api-server) section of the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into calling a protected API from React. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application. +::: + +<%= include('../_includes/_calling_api_preamble_api2") %> + +:::note +If you followed the [previous section where you added user log in to React](/quickstart/spa/auth0-react#add-login-to-your-application), make sure that you log out of your application as you'll need a new access token to call APIs. +::: + +## Set Up the Auth0 Service + +The `Auth0Provider` setup is similar to the one discussed in the [Configure the `Auth0Provider` component](/quickstart/spa/auth0-react#configure-the-auth0provider-component) section: you wrap your root component with `Auth0Provider` to which you pass the `domain` and `clientId` props. The values of these two props come from the ["Settings" values](https://auth0.com/docs/quickstart/spa/react#configure-auth0) of the single-page application you've registered with Auth0. + +However, your React application needs to pass an access token when it calls a target API to access private resources. You can [request an access token](https://auth0.com/docs/tokens/guides/get-access-tokens) in a format that the API can verify by passing the `audience` and `scope` props to `Auth0Provider` as follows: + +```javascript +import React from 'react'; +import { createRoot } from 'react-dom/client'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +const root = createRoot(document.getElementById('root')); + +root.render( + + + +); +``` + +:::note +As Auth0 can only issue tokens for custom scopes that exist on your API, ensure that you define the scopes used above when [setting up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0. +::: + +Auth0 uses the value of the `authorizationParams.audience` prop to determine which resource server (API) the user is authorizing your React application to access. + +:::note +In the case of the Auth0 Management API, the audience is `https://${account.namespace}/api/v2/`. In the case of your APIs, you create an _Identifier_ value that serves as the _Audience_ value whenever you [set up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0. +::: + +The actions that your React application can perform on the API depend on the [scopes](https://auth0.com/docs/scopes/current) that your access token contains, which you define as the value of `authorizationParams.scope`. Your React application will request authorization from the user to access the requested scopes, and the user will approve or deny the request. + +:::note +In the case of the Auth0 Management API, the `read:current_user` and `update:current_user_metadata` scopes let you get an access token that can retrieve user details and update the user's information. In the case of your APIs, you'll define custom [API scopes](https://auth0.com/docs/scopes/current/api-scopes) to implement access control, and you'll identify them in the calls that your client applications make to that API. +::: + +## Get an Access Token + +Once you configure `Auth0Provider`, you can easily get the access token using the [`getAccessTokenSilently()`](https://auth0.github.io/auth0-react/interfaces/Auth0ContextInterface.html#getAccessTokenSilently) method from the [`useAuth0()`](https://auth0.github.io/auth0-react/functions/useAuth0.html) custom React Hook wherever you need it. + +Take this `Profile` component as an example: + +```javascript +import React, { useEffect, useState } from "react"; +import { useAuth0 } from "@auth0/auth0-react"; + +const Profile = () => { + const { user, isAuthenticated, getAccessTokenSilently } = useAuth0(); + const [userMetadata, setUserMetadata] = useState(null); + + return ( + isAuthenticated && ( +
+ {user.name} +

{user.name}

+

{user.email}

+

User Metadata

+ {userMetadata ? ( + 
{JSON.stringify(userMetadata, null, 2)}
+ ) : ( + "No user metadata defined" + )} +
+ ) + ); +}; + +export default Profile; +``` + +As it is, `userMetadata` is always `null` in the `Profile` component. Add the following `useEffect()` hook to the component to fetch the user metadata from an API: + +```javascript +useEffect(() => { + const getUserMetadata = async () => { + const domain = "${account.namespace}"; + + try { + const accessToken = await getAccessTokenSilently({ + authorizationParams: { + audience: `https://<%= "${domain}" %>/api/v2/`, + scope: "read:current_user", + }, + }); + + const userDetailsByIdUrl = `https://<%= "${domain}" %>/api/v2/users/<%= "${user.sub}" %>`; + + const metadataResponse = await fetch(userDetailsByIdUrl, { + headers: { + Authorization: `Bearer <%= "${accessToken}" %>`, + }, + }); + + const { user_metadata } = await metadataResponse.json(); + + setUserMetadata(user_metadata); + } catch (e) { + console.log(e.message); + } + }; + + getUserMetadata(); +}, [getAccessTokenSilently, user?.sub]); +``` + +You use a React Effect Hook to call an asynchronous `getUserMetadata()` function. The function first calls `getAccessTokenSilently()`, which returns a Promise that resolves to an access token that you can use to make a call to a protected API. + +You pass an object with the `authorizationParams.audience` and `authorizationParams.scope` properties as the argument of `getAccessTokenSilently()` to ensure that the access token you get is for the intended API and has the required permissions to access the desired endpoint. + +:::note +In the case of the Auth0 Management API, one of the scopes that the [`/api/v2/users/{id}` endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) requires is `read:current_user`. +::: + +You can then include the access token in the authorization header of the API call that you make. The API will take care of validating the access token and processing the request. + +Upon success, you extract the `user_metadata` property from the API response and use `setUserMetadata()` to make React aware of it. + +:::panel Checkpoint +Your application will show "No user metadata defined" if you have not set any `user_metadata` for the logged-in user. To further test out this integration, head to the [Users section of the Auth0 dashboard](https://manage.auth0.com/#/users) and click on the user who is logged in. Update the `user_metadata` section with a value like `{ "theme": "dark" }` and click "Save". Refresh your React application and verify that it reflects the new `user_metadata`. +::: + +:::note +The `getAccessTokenSilently()` method can renew the access and ID token for you using [refresh tokens](https://auth0.com/docs/tokens/concepts/refresh-tokens). To [get a refresh token](https://auth0.com/docs/tokens/guides/get-refresh-tokens) when a user logs in, pass `useRefreshTokens={true}` as a prop to `Auth0Provider`. +::: + +As a final reminder, consult the [Auth0 API quickstarts](https://auth0.com/docs/quickstart/backend) to learn how to integrate Auth0 with your backend platform. + diff --git a/fr-ca/articles/quickstart/spa/react/download.md b/fr-ca/articles/quickstart/spa/react/download.md new file mode 100644 index 0000000000..6f559d951d --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/download.md @@ -0,0 +1,28 @@ + + +To run the sample follow these steps: + +1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:3000 +``` +2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:3000 +``` +3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to +```text +http://localhost:3000 +``` +4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory: +```bash +npm install && npm start +``` +You can also run it from a [Docker](https://www.docker.com) image with the following commands: + +```bash +# In Linux / macOS +sh exec.sh +# In Windows' Powershell +./exec.ps1 +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/files/app.md b/fr-ca/articles/quickstart/spa/react/files/app.md new file mode 100644 index 0000000000..7e4b2f7e01 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/files/app.md @@ -0,0 +1,29 @@ +--- +name: app.js +language: javascript +--- + +```javascript +import { useAuth0 } from "@auth0/auth0-react"; +import React from "react"; + +const Profile = () => { + const { user, isAuthenticated, isLoading } = useAuth0(); + + if (isLoading) { + return
Loading ...
; + } + + return ( + isAuthenticated && ( +
+ {user.name} +

{user.name}

+

{user.email}

+
+ ) + ); +}; + +export default Profile; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/files/index.md b/fr-ca/articles/quickstart/spa/react/files/index.md new file mode 100644 index 0000000000..e5c5e1d111 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/files/index.md @@ -0,0 +1,25 @@ +--- +name: index.js +language: javascript +--- + +```javascript +import React from 'react'; +import { createRoot } from 'react-dom/client'; +import { Auth0Provider } from '@auth0/auth0-react'; +import App from './App'; + +const root = createRoot(document.getElementById('root')); + +root.render( + + + , +); +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/files/login.md b/fr-ca/articles/quickstart/spa/react/files/login.md new file mode 100644 index 0000000000..f00fbd0507 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/files/login.md @@ -0,0 +1,17 @@ +--- +name: login.js +language: javascript +--- + +```javascript +import { useAuth0 } from "@auth0/auth0-react"; +import React from "react"; + +const LoginButton = () => { + const { loginWithRedirect } = useAuth0(); + + return ; +}; + +export default LoginButton; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/files/logout.md b/fr-ca/articles/quickstart/spa/react/files/logout.md new file mode 100644 index 0000000000..89caeb8029 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/files/logout.md @@ -0,0 +1,21 @@ +--- +name: logout.js +language: javascript +--- + +```javascript +import { useAuth0 } from "@auth0/auth0-react"; +import React from "react"; + +const LogoutButton = () => { + const { logout } = useAuth0(); + + return ( + + ); +}; + +export default LogoutButton; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/files/profile.md b/fr-ca/articles/quickstart/spa/react/files/profile.md new file mode 100644 index 0000000000..6ae27c8bea --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/files/profile.md @@ -0,0 +1,29 @@ +--- +name: profile.js +language: javascript +--- + +```javascript +import { useAuth0 } from "@auth0/auth0-react"; +import React from "react"; + +const Profile = () => { + const { user, isAuthenticated, isLoading } = useAuth0(); + + if (isLoading) { + return
Loading ...
; + } + + return ( + isAuthenticated && ( +
+ {user.name} +

{user.name}

+

{user.email}

+
+ ) + ); +}; + +export default Profile; +``` \ No newline at end of file diff --git a/fr-ca/articles/quickstart/spa/react/index.yml b/fr-ca/articles/quickstart/spa/react/index.yml new file mode 100644 index 0000000000..591b6725fe --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/index.yml @@ -0,0 +1,65 @@ +title: React +# TODO remove 'image' once new QS page is live. Then only use 'logo'. +image: /media/platforms/react.png +logo: react +alias: + - react + - reactjs +language: + - Javascript +author: + name: Dan Arias + email: dan.arias@auth0.com + community: false +framework: + - React +topics: + - quickstart +contentType: tutorial +useCase: quickstart +show_releases: true +sdk: + name: auth0-react + url: https://www.github.com/auth0/auth0-react/ + logo: react +snippets: + dependencies: application-platforms/react/dependencies + setup: application-platforms/react/setup + use: application-platforms/react/use +seo_alias: react +default_article: "01-login" +articles: + - "01-login" + - "02-calling-an-api" +hidden_articles: + - "interactive" +show_steps: true +github: + org: auth0-samples + repo: auth0-react-samples + branch: master +requirements: + - React 18 +next_steps: + - path: 01-login + list: + - text: "Part 2: Calling an API using an access token" + icon: 345 + href: "/quickstart/spa/react/02-calling-an-api" + - path: 02-calling-an-api + list: + - text: Configure other identity providers + icon: 345 + href: "/identityproviders" + - text: Enable multifactor authentication + icon: 345 + href: "/multifactor-authentication" + - text: Learn about attack protection + icon: 345 + href: "/attack-protection" + - text: Learn about rules + icon: 345 + href: "/rules" +troubleshooting_steps: + + diff --git a/fr-ca/articles/quickstart/spa/react/interactive.md b/fr-ca/articles/quickstart/spa/react/interactive.md new file mode 100644 index 0000000000..182acd7c70 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/react/interactive.md @@ -0,0 +1,158 @@ +--- +title: Add Login to your React App +description: "Auth0 allows you to add authentication to your React application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing React application using the Auth0 React SDK." +interactive: true +files: + - files/index + - files/login + - files/logout + - files/profile +github: + path: Sample-01 +--- + +:::note +Visit the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into implementing user authentication in React. This guide provides additional details on how to create a sign-up button, add route guards using React Router, and call a protected API from React. +::: + +# Add Login to Your React Application + +Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any React application using the Auth0 React SDK. + +To use this quickstart, you’ll need to: +- Sign up for a free Auth0 account or log in to Auth0. +- Have a working React project that you want to integrate with. Alternatively, you can view or download a sample application after logging in. + +<%= include('../../_includes/_configure_auth0_interactive', { + callback: 'http://localhost:3000', + returnTo: 'http://localhost:3000', + webOriginUrl: 'http://localhost:3000', + showWebOriginInfo: true +}) %> + +## Install the Auth0 React SDK {{{ data-action=code data-code="index.js#13:22" }}} + +Auth0 provides a [React SDK](https://github.com/auth0/auth0-react) (auth0-react.js) to simplify the process of implementing Auth0 authentication and authorization in React apps. + +Install the Auth0 React SDK by running the following commands in your terminal: + +```bash +cd +npm install @auth0/auth0-react +``` + +### Configure the Auth0Provider component + +For the SDK to function properly, you must set the following properties in the Auth0Provider component: + +- `domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead. +- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field. +- `authorizationParams.redirect_uri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. You can also find this value in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error. + +::::checkpoint + +:::checkpoint-default + +Your Auth0Provider component should now be properly configured. Run your application to verify that: +- the SDK is initializing correctly +- your application is not throwing any errors related to Auth0 + +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* make sure the correct application is selected +* did you save after entering your URLs? +* make sure the domain and client ID imported correctly + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add login to your application {{{ data-action=code data-code="login.js#4:7" }}} + +Now that you have configured your Auth0 Application and the Auth0 React SDK, you need to set up login for your project. To do this, you will use the SDK’s loginWithRedirect() method to create a login button that redirects users to the Auth0 Universal Login page. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart. + +<%= include('../../_includes/_auth0-react-classes-info.md') %> + +Create a new file in your application called `login.js` for the login button component, and copy in the code from the interactive panel to the right, which contains the logic needed for login. Then, update your `index.js` file to include the new login button. + +::::checkpoint + +:::checkpoint-default + +You should now be able to log in or sign up using a username and password. + +Click the login button and verify that: +* your React Application redirects you to the Auth0 Universal Login page +* you can log in or sign up +* Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` you used to configure the `Auth0Provider` + +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* you configured the correct `authorizationParams.redirect_uri` +* you added the Login button to the `index.js` file + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: +:::: + +## Add logout to your application {{{ data-action=code data-code="logout.js#10:18" }}} + +Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s logout() method. When users log out, they will be redirected to your [Auth0 logout](https://auth0.com/docs/api/authentication?javascript#logout) endpoint, which will then immediately redirect them to the logout URL you set up earlier in this quickstart. + +Create a new file in your application called `logout.js` for the logout button component, and copy in the code from the interactive panel, which contains the logic needed for logout. Then, update your `index.js` file to include the logout button. + +::::checkpoint + +:::checkpoint-default + +Run your application and click the logout button, verify that: +* your React application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings +* you are no longer logged in to your application + +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* you configured the correct Logout URL +* you added the Logout button to the `index.js` file + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. + +::: + +:::: + +## Show User Profile Information {{{ data-action=code data-code="profile.js#11:26" }}} + +Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project. + +The Auth0 React SDK provides user information through the `user` property. Review the `profile.js` code in the interactive panel to see an example of how to use it. + +Because the `user` property contains sensitive information related to the user's identity, its availability depends on the user's authentication status. To prevent render errors, you should always: +- use the `isAuthenticated` property to determine whether Auth0 has authenticated the user before React renders any component that consumes the `user` property. +- ensure that the SDK has finished loading by checking that `isLoading` is false before accessing the `isAuthenticated` property. + +::::checkpoint + +:::checkpoint-default + +Verify that: +* you can display the `user.name` or any other user property within a component correctly after you have logged in + +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: +* you added the `isLoading` check before accessing the `isAuthenticated` property +* you added the `Profile` component to the `index.js` file + +Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help. +::: + +:::: diff --git a/fr-ca/articles/quickstart/spa/vanillajs/01-login.md b/fr-ca/articles/quickstart/spa/vanillajs/01-login.md new file mode 100644 index 0000000000..dc9497c854 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/vanillajs/01-login.md @@ -0,0 +1,20 @@ +--- +title: Login +description: This tutorial demonstrates how to add user login to a Javascript application using Auth0. +budicon: 448 +topics: + - quickstarts + - spa + - vanillajs + - login +github: + path: 01-Login +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/_getting_started', { library: 'JavaScript', callback: 'http://localhost:3000', showLogoutInfo: true, returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showWebOriginInfo: true, new_js_sdk: true }) %> + +<%= include('_includes/_centralized_login') %> diff --git a/fr-ca/articles/quickstart/spa/vanillajs/02-calling-an-api.md b/fr-ca/articles/quickstart/spa/vanillajs/02-calling-an-api.md new file mode 100644 index 0000000000..7f4a3b9c04 --- /dev/null +++ b/fr-ca/articles/quickstart/spa/vanillajs/02-calling-an-api.md @@ -0,0 +1,271 @@ +--- +title: Calling an API +description: This tutorial demonstrates how to make API calls for protected resources on your server. +budicon: 546 +topics: + - quickstarts + - spa + - vanillajs + - apis +github: + path: 02-Calling-an-API +sample_download_required_data: + - client + - api +contentType: tutorial +useCase: quickstart +--- + + + +<%= include('../_includes/_calling_api_preamble') %> + +<%= include('../_includes/_calling_api_create_api') %> + +## Create a Backend API + +In this section, you will modify the [ExpressJS](https://expressjs.com) that you created in part 1 so that it supports a new endpoint. This endpoint will require a valid access token to be sent in the `Authorization` header for the call to be successful. + +### Add middleware to the backend + +To begin, let's install an NPM package that will be used to validate incoming tokens to the server. From the terminal: + +```bash +npm install express-oauth2-jwt-bearer +``` + +Next, open `server.js` and bring in these libraries as imports at the top of the file. Also bring in the `auth_config.json` file so that the script can get access to the authentication credentials that have been configured: + +```js +// .. other imports + +const { auth } = require("express-oauth2-jwt-bearer"); +const authConfig = require("./auth_config.json"); +``` + +- [`express-oauth2-jwt-bearer`](https://npmjs.com/package/express-oauth2-jwt-bearer) - validates JWTs from the `authorization` header and sets the `req.auth` object + +Then add a call to `auth()`, which creates the middleware needed in order to validate and parse incoming access tokens. This should go after the `require` statements but before any routes are defined in your app: + +```js +// create the JWT middleware +const checkJwt = auth({ + audience: authConfig.audience, + issuerBaseURL: `https://<%= "${authConfig.domain}" %>` +}); +``` + +This code configures the `express-oauth2-jwt-bearer` middleware with the settings that relate to your Auth0 application. + +Next, open the `auth_config.json` file and modify the data so that the `audience` appears as a key within the JSON, using the value that you just used when creating the API: + +```json +{ + "domain": "${account.namespace}", + "clientId": "${account.clientId}", + "audience": "${apiIdentifier}" +} +``` + +::: note +As `auth_config.json` is served publicly, this file should **never** contain sensitive information such as passwords and client secrets. +::: + +The values for `domain` and `clientId` should have already been specified as part of the [Login tutorial](/quickstarts/spa/vanillajs/01-login). They should point to the Domain and Client ID values for your Auth0 app respectively. + +### Add a protected endpoint + +The last thing to do on the server side is to add an API endpoint that requires an access token to be provided for the call to succeed. This endpoint will use the middleware that you created earlier in the tutorial to provide that protection in a scalable way. + +Open `server.js` and add a new route for `/api/external` above the other routes that returns some JSON: + +```js +// .. + +app.get("/api/external", checkJwt, (req, res) => { + res.send({ + msg: "Your access token was successfully validated!" + }); +}); + +// .. +``` + +Note that `checkJwt` is used as the second argument here. This causes `checkJwt` to be executed before the main route handler, and will reject the call and return a 401 response if: + +- there is no access token present in the `Authorization` header, +- or the token itself is not valid + +Finally, add an error handler so that a JSON response is returned from your API in the event of a missing or invalid token: + +```js +// .. + +app.use(function(err, req, res, next) { + if (err.name === "UnauthorizedError") { + return res.status(401).send({ msg: "Invalid token" }); + } + + next(err, req, res); +}); + +//.. +``` + +At the end, your `server.js` file will look something like the following: + +```js +const express = require("express"); +const { auth } = require("express-oauth2-jwt-bearer"); +const { join } = require("path"); +const authConfig = require("./auth_config.json"); + +const app = express(); + +// Serve assets from the /public folder +app.use(express.static(join(__dirname, "public"))); + +// Create the JWT validation middleware +const checkJwt = auth({ + audience: authConfig.audience, + issuerBaseURL: `https://<%= "${authConfig.domain}" %>` +}); + +// Create an endpoint that uses the above middleware to +// protect this route from unauthorized requests +app.get("/api/external", checkJwt, (req, res) => { + res.send({ + msg: "Your access token was successfully validated!" + }); +}); + +// Serve the auth configuration file +app.get("/auth_config.json", (req, res) => { + res.sendFile(join(__dirname, "auth_config.json")); +}); + +// Serve the index page to everything else +app.get("/*", (req, res) => { + res.sendFile(join(__dirname, "index.html")); +}); + +// Error handler +app.use(function(err, req, res, next) { + if (err.name === "UnauthorizedError") { + return res.status(401).send({ msg: "Invalid token" }); + } + + next(err, req, res); +}); + +module.exports = app; +``` + +### Test the API + +With this in place, run the application using `npm run dev`. In another terminal window, use the `curl` tool to make a request to this API endpoint and observe the results: + +```bash +curl -I localhost:3000/api/external +``` + +You should find that a 401 Unauthorized result is returned, because it requires a valid access token: + +```bash +HTTP/1.1 401 Unauthorized +X-DNS-Prefetch-Control: off +X-Frame-Options: SAMEORIGIN +Strict-Transport-Security: max-age=15552000; includeSubDomains +X-Download-Options: noopen +X-Content-Type-Options: nosniff +X-XSS-Protection: 1; mode=block +Content-Security-Policy: default-src 'self' +Content-Type: text/html; charset=utf-8 +Content-Length: 1582 +Date: Wed, 03 Apr 2019 13:10:43 GMT +Connection: keep-alive +``` + +## Calling the API + +Now you can turn your attention to the front-end application. You will update the application to provide a button to call a function which will in turn call the API that you created in the previous section. + +Open `index.html` and add a new button that will invoke the API call, as well as a `pre` element with an ID of `api-call-result` to show the result of the API call in the browser: + +```html + + + +

+```
+
+Next, open `public/js/app.js`. Configure the `auth0` client object to specify the audience value that was added earlier to the `auth_config.json` file:
+
+```js
+const configureClient = async () => {
+  const response = await fetchAuthConfig();
+  const config = await response.json();
+
+  auth0 = await auth0Client.createAuth0Client({
+    domain: config.domain,
+    clientId: config.clientId,
+    authorizationParams: {
+      audience: config.audience   // NEW - add the audience value
+    }
+  });
+};
+```
+
+Add a new function called `callApi` to `app.js`, with the following content:
+
+```js
+const callApi = async () => {
+  try {
+
+    // Get the access token from the Auth0 client
+    const token = await auth0Client.getTokenSilently();
+
+    // Make the call to the API, setting the token
+    // in the Authorization header
+    const response = await fetch("/api/external", {
+      headers: {
+        Authorization: `Bearer <%= "${token}" %>`
+      }
+    });
+
+    // Fetch the JSON result
+    const responseData = await response.json();
+
+    // Display the result in the output element
+    const responseElement = document.getElementById("api-call-result");
+
+    responseElement.innerText = JSON.stringify(responseData, {}, 2);
+
+} catch (e) {
+    // Display errors in the console
+    console.error(e);
+  }
+};
+```
+
+Finally, find the `updateUI` function within `app.js` and modify it so that the button for calling the API is enabled when the user logs in:
+
+```js
+// public/js/app.js
+
+const updateUI = async () => {
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+
+  // NEW - enable the button to call the API
+  document.getElementById("btn-call-api").disabled = !isAuthenticated;
+
+  // .. other code omitted for brevity ..
+};
+```
+
+Now, open the browser in the application at [http://localhost:3000](http://localhost:3000). If the application has been stopped, run it again from the terminal using `npm run dev`.
+
+When the application starts, log in. Then, press the **Call API** button to make a request to the API and put the results on the screen. You should find that the result from the server is displayed on the page.
diff --git a/fr-ca/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md b/fr-ca/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
new file mode 100644
index 0000000000..095335a80e
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
@@ -0,0 +1,401 @@
+
+
+<%= include('../../_includes/_login_preamble', { library: 'JavaScript' }) %>
+
+## Setting Up the Application
+
+### Create a basic HTML page
+
+Create a folder on your machine to house the application, then add an `index.html` file to the root of the project. This HTML page will display a welcome message and have a "gated" section which requires the user to be authenticated before accessing. You can copy/paste the following content into the file. You will be adding more lines as you progress with this article.
+
+Add the following content to the `index.html` file you just created:
+
+```html
+
+
+  
+    
+    SPA SDK Sample
+    
+  
+
+  
+    
SPA Authentication Sample

+    
Welcome to our page!

+    
+    
+  
+
+```
+
+Additionally, create a new folder called `public`, a folder inside that called `css` and a new file in there called `main.css`. This will be used to define how the gated content elements will be hidden in the page.
+
+Open the newly-created `public/css/main.css` file and add the following CSS:
+
+```css
+.hidden {
+  display: none;
+}
+
+label {
+  margin-bottom: 10px;
+  display: block;
+}
+```
+
+Finally, create a new directory in the `public` folder called `js`, and a new file in there called `app.js`. This will house the application-specific logic that you will create over the next few sections.
+
+The folder structure so far should look like the following:
+
+```
+.
+├── index.html
+└── public
+    ├── css
+    │   └── main.css
+    └── js
+        └── app.js
+```
+
+### Reference the SDK
+
+This article is based on the new SPA SDK available [here](https://github.com/auth0/auth0-spa-js/). You can reference the package from the CDN in the `index.html` file by placing the script tags at the very bottom of the `body` tag:
+
+```html
+
+  
+  
+  
+  
+  
+  
+
+```
+
+### Configure credentials
+
+Create an `auth_config.json` in the root of the project. The values from `domain` and `clientId` should be populated from your [Auth0 application settings](${manage_url}/#/applications/${account.clientId}/settings) as configured [above](#get-your-application-keys).
+
+```json
+{
+  "domain": "${account.namespace}",
+  "clientId": "${account.clientId}"
+}
+```
+
+:::note
+As `auth_config.json` is served publicly, this file should **never** contain sensitive information such as passwords and client secrets.
+:::
+
+## Create the server
+
+In this section you will create a basic web server using [ExpressJS](https://expressjs.com). This will be used to serve our HTML page, along with any assets that it requires (JavaScript, CSS, etc).
+
+Run the following command in the same folder as the `index.html` file you created earlier:
+
+```bash
+npm init -y
+```
+
+This will initialize a new NPM project and get us ready to install dependencies.
+
+### Installing dependencies
+
+In the terminal, install the dependencies that are necessary to get the server up and running:
+
+```bash
+npm install express
+```
+
+Also install [`nodemon`](https://npmjs.org/package/nodemon) so that our server can be restarted on any code changes:
+
+```bash
+npm install -D nodemon
+```
+
+Finally, open the `package.json` file and modify the "scripts" entry to look like the following:
+
+```json
+{
+  // ...
+  "scripts": {
+    "start": "node server.js",
+    "dev": "nodemon server.js"
+  },
+  // ...
+}
+```
+
+- `npm start` will run the application as normal
+- `npm run dev` will run the application using `nodemon`, watching for changes as we modify files
+
+### Creating server.js
+
+Next, create a new file in the root of the project alongside `index.html` and `package.json`, called `server.js`. This will be our backend server and will be used to serve the SPA pages.
+
+Populate `server.js` with the following code:
+
+```js
+const express = require("express");
+const { join } = require("path");
+const app = express();
+
+// Serve static assets from the /public folder
+app.use(express.static(join(__dirname, "public")));
+
+// Endpoint to serve the configuration file
+app.get("/auth_config.json", (req, res) => {
+  res.sendFile(join(__dirname, "auth_config.json"));
+});
+
+// Serve the index page for all other requests
+app.get("/*", (_, res) => {
+  res.sendFile(join(__dirname, "index.html"));
+});
+
+// Listen on port 3000
+app.listen(3000, () => console.log("Application running on port 3000"));
+```
+
+The server provides two endpoints:
+
+- one which serves the authentication configuration file to the client-side app
+- another which serves every other request to the `index.html` file, which will provide support for any client-side routing as all routes go to the same page
+
+The app also serves all of the static files, such as the `.js` and `.css` files from the `/public` folder.
+
+## Initialize the SDK
+
+The SDK must be properly initialized with the information of the Auth0 application created above.
+
+To start, open the `public/js/app.js` file and add a variable to hold the Auth0 client object:
+
+```js
+let auth0Client = null;
+```
+
+This must be initialized using the values from the `auth_config.json` file. This can be done by calling the endpoint on the server that was created in the previous section. To do this, create a new function called `fetchAuthConfig` further down the `app.js` file, which can be used to download this information:
+
+```js
+
+// ..
+
+const fetchAuthConfig = () => fetch("/auth_config.json");
+```
+
+Next, create another new function called `configureClient`. This will use `fetchAuthConfig` to download the configuration file and initialize the `auth0Client` variable:
+
+```js
+// ..
+
+const configureClient = async () => {
+  const response = await fetchAuthConfig();
+  const config = await response.json();
+
+  auth0Client = await auth0.createAuth0Client({
+    domain: config.domain,
+    clientId: config.clientId
+  });
+};
+```
+
+This call will also populate the in-memory cache with a valid access token and user profile information if someone has already authenticated before and that session is still valid.
+
+Add a handler for the `window.onload` function that will then make this call to initialize the application:
+
+```js
+// ..
+
+window.onload = async () => {
+  await configureClient();
+}
+```
+
+Now go and access it at [http://localhost:3000](http://localhost:3000). You should see the welcome message and both authentication buttons disabled. Note however that some browsers cache the page sources. When checking each step results you should perform a full page refresh ignoring the cache. This can be achieved by using the `CMD+SHIFT+R` keys on OSX and `CTRL+SHIFT+R` keys on Windows.
+
+<%= include('../../_includes/_silent-auth-social-idp') %>
+
+## Evaluate the authentication state
+
+As a first approach, you want to make sure anyone is able to visit the public page but not the page that is meant for authenticated users only, such as a settings panel or the user profile details. You can decide which content is available by hiding, disabling, or removing it if no user is currently logged in. You do so by checking the result of calling the `auth0Client.isAuthenticated()` method. Use this to enable or disable the **Log in** and **Log out** buttons, which are disabled by default. This can be part of a new `updateUI()` function called from the `window.onload` method right after the initialization.
+
+Still inside the `app.js` file, add a new function called `updateUI` and modify the `onload` handler to call this new function:
+
+```js
+// ..
+
+window.onload = async () => {
+  await configureClient();
+
+  // NEW - update the UI state
+  updateUI();
+};
+
+// NEW
+const updateUI = async () => {
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+};
+```
+
+> **Checkpoint:** If you run the project again, you should see that the "Log in" button is shown as enabled as no user has previously logged in. But clicking it will not do anything as there is no logic associated to that action yet.
+
+## Log In to the Application
+
+Authentication is achieved through a redirect to the Auth0 [Universal Login Page](https://auth0.com/docs/hosted-pages/login). Once the user signs up or logs in, the result will be passed to your app's redirect URI, which is provided with the authorization request.
+
+Inside the `app.js` file, provide a `login` function that calls `auth0Client.loginWithRedirect()` to perform the login step. The `login` function is called by the **Log in** button previously defined in the HTML page. In this sample, you will redirect the user back to the same page they are now. You can obtain that value from `window.location.origin` property:
+
+```js
+// ..
+
+const login = async () => {
+  await auth0Client.loginWithRedirect({
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  });
+};
+```
+
+Additionally, because this is a _single page application_, the result of this call needs to be handled in the same context. This means that when the page is loaded and the user is not authenticated you could be in one of the following two scenarios:
+
+1. The user does not want to authenticate and is just navigating through public content or
+2. The user has recently initiated the authentication process and is now looking to complete it.
+
+This second scenario is the one you need to handle. In your `window.onload` method, check whether the user is authenticated or not, and if the URL query contains both a `code` and `state` parameter. This will indicate that an authentication result is present and needs to be parsed. In that scenario, you do so by calling the `auth0Client.handleRedirectCallback()` method. This will attempt to exchange the result that the Auth0 backend gave you back for real tokens you can use.
+
+In addition, the query parameters must be removed from the URL so that if the user refreshes the page, the app does not try to parse the `state` and `code` parameters again. This is achieved with the `window.history.replaceState` method.
+
+Modify the `window.onload` function inside `app.js` to include these changes:
+
+```js
+// ..
+
+window.onload = async () => {
+
+  // .. code ommited for brevity
+
+  updateUI();
+
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  if (isAuthenticated) {
+    // show the gated content
+    return;
+  }
+
+  // NEW - check for the code and state parameters
+  const query = window.location.search;
+  if (query.includes("code=") && query.includes("state=")) {
+
+    // Process the login state
+    await auth0Client.handleRedirectCallback();
+    
+    updateUI();
+
+    // Use replaceState to redirect the user away and remove the querystring parameters
+    window.history.replaceState({}, document.title, "/");
+  }
+};
+
+// ..
+```
+
+The callback is now handled properly and the authentication can be completed successfully.
+
+Run the project and click the **Log in** button. You should be taken to the Universal Login Page configured for your application. Go ahead and create a new user or log in using a social connection. After authenticating successfully, you will be redirected to the page you were before. This time, the result will be present in the URL query and the exchange will happen automatically. If everything went fine, you will end up with no query parameters in the URL, the user would now be logged in and the "Log out" button will be enabled.
+
+:::note
+If you see any errors from the Auth0 server, check that you have not forgotten to register the callback URL or the allowed origins as explained initially.
+:::
+
+## Log the User Out
+
+You may have noticed that the **Log out** button is clickable when the user is authenticated, but does nothing. You need to add the code that will log the user out from the Auth0 backend.
+
+Start the log out by calling the `auth0Client.logout()` method passing a valid return-to URI. In this sample you will return the user back to the same page they are now. You can obtain that value from `window.location.origin` property. Abstract this logic into a `logout()` method.
+
+```js
+// public/js/app.js
+
+const logout = () => {
+  auth0Client.logout({
+    logoutParams: {
+      returnTo: window.location.origin
+    }
+  });
+};
+```
+
+> **Checkpoint:** Being authenticated click the **Log out** button. You should be taken to the Universal Login Page configured for your application and then back to the page you were before. Now the authentication cookies were cleared and the user is logged out. The "Log in" button will be enabled back again.
+
+If you see any errors from the Auth0 server, check that you have not forgotten to register the logout URL as explained initially.
+
+## Read the User Profile
+
+Every time a user is logged in you get access both to the **access token** and the **ID token**. The user's profile information is then extracted from the ID token. Typically, the token is used to call your backend application and the profile information is used to display their name and profile picture. In this section you are going to display them in separate text areas so you can easily inspect them.
+
+Open the `index.html` file and insert the following lines at the bottom of the body.
+
+```html
+
+  
+
+  
+  
+  
+
+```
+
+Now re-open the `app.js` file and modify the `updateUI()` function declared previously. Add the logic such that when the user is logged in the gated content is shown. Use the existing variables and functions from the SDK client to obtain and display this information on the page.
+
+In addition, at the start of this article you added a `public/css/main.css` file with the definition of the `hidden` class, which can be used to easily hide elements on the page. Using the authenticated flag as shown below, add or remove this class to the elements you want to show or hide in the `updateUI()` function:
+
+```js
+// ...
+
+const updateUI = async () => { 
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+  
+  // NEW - add logic to show/hide gated content after authentication
+  if (isAuthenticated) {
+    document.getElementById("gated-content").classList.remove("hidden");
+
+    document.getElementById(
+      "ipt-access-token"
+    ).innerHTML = await auth0Client.getTokenSilently();
+
+    document.getElementById("ipt-user-profile").textContent = JSON.stringify(
+      await auth0Client.getUser()
+    );
+
+  } else {
+    document.getElementById("gated-content").classList.add("hidden");
+  }
+};
+
+// ..
+```
+
+Note that calls to the SDK instance can throw an exception if the authentication fails, if there is no user currently authenticated, or if the access token needs to be refreshed and that request fails. You will need to put a try/catch block around them to correctly handle any errors. These error checks are not shown on the article but they are available on the final sample app that you can download.
+
+> **Checkpoint:** Go ahead and run the project for the last time. Now if the user is authenticated you will get to see their access token and profile data. See how this content disappears when you log out.
diff --git a/fr-ca/articles/quickstart/spa/vanillajs/download.md b/fr-ca/articles/quickstart/spa/vanillajs/download.md
new file mode 100644
index 0000000000..6f559d951d
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/download.md
@@ -0,0 +1,28 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm start
+```
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vanillajs/files/app.md b/fr-ca/articles/quickstart/spa/vanillajs/files/app.md
new file mode 100644
index 0000000000..4f8815c99a
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/files/app.md
@@ -0,0 +1,53 @@
+---
+name: app.js
+language: javascript
+---
+
+```javascript
+auth0.createAuth0Client({
+  domain: "${account.namespace}",
+  clientId: "${account.clientId}",
+  authorizationParams: {
+    redirect_uri: window.location.origin
+  }
+}).then(async (auth0Client) => {
+  // Assumes a button with id "login" in the DOM
+  const loginButton = document.getElementById("login");
+
+  loginButton.addEventListener("click", (e) => {
+    e.preventDefault();
+    auth0Client.loginWithRedirect();
+  });
+
+  if (location.search.includes("state=") && 
+      (location.search.includes("code=") || 
+      location.search.includes("error="))) {
+    await auth0Client.handleRedirectCallback();
+    window.history.replaceState({}, document.title, "/");
+  }
+
+  // Assumes a button with id "logout" in the DOM
+  const logoutButton = document.getElementById("logout");
+
+  logoutButton.addEventListener("click", (e) => {
+    e.preventDefault();
+    auth0Client.logout();
+  });
+
+  const isAuthenticated = await auth0Client.isAuthenticated();
+  const userProfile = await auth0Client.getUser();
+
+  // Assumes an element with id "profile" in the DOM
+  const profileElement = document.getElementById("profile");
+
+  if (isAuthenticated) {
+    profileElement.style.display = "block";
+    profileElement.innerHTML = `
+            
<%= "${userProfile.name}" %>

+            " />
+          `;
+  } else {
+    profileElement.style.display = "none";
+  }
+});
+```
diff --git a/fr-ca/articles/quickstart/spa/vanillajs/index.yml b/fr-ca/articles/quickstart/spa/vanillajs/index.yml
new file mode 100644
index 0000000000..69ef28e4e9
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/index.yml
@@ -0,0 +1,63 @@
+title: JavaScript
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/html5.png
+logo: javascript
+language:
+  - JavaScript
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-spa-js
+  url: https://github.com/auth0/auth0-spa-js
+  logo: javascript
+snippets:
+  dependencies: application-platforms/vanillajs/dependencies
+  setup: application-platforms/vanillajs/setup
+  use: application-platforms/vanillajs/use
+alias:
+  - vanilla
+  - vanillajs
+  - spa
+  - single-page-app
+  - html5
+  - backendless
+  - javascript-app
+seo_alias: vanillajs
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+  - 02-calling-an-api
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-javascript-samples
+  branch: master
+next_steps:
+  - path: 01-login
+    list:
+      - text: 'Part 2: Calling an API using an access token'
+        icon: 345
+        href: '/quickstart/spa/vanillajs/02-calling-an-api'
+  - path: 02-calling-an-api
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/fr-ca/articles/quickstart/spa/vanillajs/interactive.md b/fr-ca/articles/quickstart/spa/vanillajs/interactive.md
new file mode 100644
index 0000000000..1e3fbbf521
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vanillajs/interactive.md
@@ -0,0 +1,160 @@
+---
+title: Add login to your JavaScript App
+description: 'Auth0 allows you to add authentication to your JavaScript application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing JavaScript application using the Auth0 SPA SDK.'
+interactive: true
+github:
+  path: 01-Login
+files:
+  - files/app
+---
+
+# Add Login to Your JavaScript Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in a Single-Page Application (SPA) that uses plain JavaScript, using the [Auth0 SPA SDK](https://github.com/auth0/auth0-spa-js).
+
+To use this quickstart, you’ll need to:
+
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+:::note
+This quickstart assumes you are adding Auth0 to a plain JavaScript application, as opposed to using a framework such as React or Angular.
+:::
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000',
+returnTo: 'http://localhost:3000',
+webOriginUrl: 'http://localhost:3000',
+showWebOriginInfo: true
+}) %>
+
+## Add the Auth0 SPA SDK
+
+Auth0 provides a SPA SDK (auth0-spa-js) to simplify the process of implementing Auth0 authentication and authorization in JavaScript applications. You can install the Auth0 SPA SDK as an NPM package or from the CDN. For the purpose of this quickstart, we will use the CDN. Include this script tag on your HTML page:
+
+```html
+
+```
+
+## Create the Auth0 client {{{ data-action=code data-code="app.js#1:7" }}}
+
+Create a new instance of the Auth0 client provided by the Auth0 SPA SDK and provide the Auth0 application details you created earlier in this quickstart.
+
+If a user has previously logged in, the client will refresh the authentication state on page load; the user will still be logged in once the page is refreshed.
+
+## Add login to your application {{{ data-action=code data-code="app.js#8:14" }}}
+
+Now that you have configured your Auth0 Application, added the Auth0 SPA SDK, and created the Auth0 client, you need to set up login for your project. To do this, you will use the SDK’s `loginWithRedirect()` method to redirect users to the Auth0 Universal Login page where Auth0 can authenticate them. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+Create a login button in your application that calls `loginWithRedirect()` when selected.
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to log in to your application.
+
+Run your application, and select the login button. Verify that:
+
+- you can log in or sign up using a username and password
+- your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page
+- you are redirected to Auth0 for authentication
+- Auth0 successfully redirects back to your application after authentication
+- you do not receive any errors in the console related to Auth0
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure that the correct application is selected
+- make sure you saved after entering your URLs
+- make sure the Auth0 client has been correctly configured with your Auth0 domain and client ID
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+
+:::
+::::
+
+## Handle the callback from Auth0 {{{ data-action=code data-code="app.js#16:21" }}}
+
+When the browser is redirected back to your application process, your application should call the `handleRedirectCallback()` function on the Auth0 client only when it detects a callback from Auth0. One way to do this is to only call `handleRedirectCallback()` when `code` and `state` query parameters are detected.
+
+If handling the callback was successful, the parameters should be removed from the URL so the callback handler will not be triggered the next time the page loads.
+
+::::checkpoint
+::: checkpoint-default
+Your callback from Auth0 should now be properly handled.
+
+Run your application, and select the login button again. Verify that:
+
+- Auth0 successfully redirects back to your application after authentication.
+- the query parameters are removed from the URL.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- check that the `redirect_uri` option has been configured to your application's URL
+- if you have an `error` query parameter, inspect it to learn the cause of the error
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="app.js#23:29" }}}
+
+Users who log in to your project will also need [a way to log out](/logout/guides/logout-auth0). The Auth0 client provides a `logout()` method that you can use to log a user out of your app. When users log out, they will be redirected to your [Auth0 logout endpoint](/api/authentication?javascript#logout), which will then immediately redirect them to your application and the logout URL you set up earlier in this quickstart.
+
+Create a logout button in your application that calls `logout()` when selected.
+
+:::note
+The SDK exposes an `isAuthenticated()` function that allows you to check whether a user is authenticated or not. You can render the login and logout buttons conditionally based on the value of the `isAuthenticated()` function. Alternatively, you can use a single button to combine both login and logout buttons as well as their conditional rendering.
+:::
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to log out of your application.
+
+Run your application, log in, and select the logout button. Verify that:
+
+- you are redirected to Auth0's logout endpoint.
+- Auth0 successfully redirects back to your application and the correct logout URL.
+- you are no longer logged in to your application.
+- you do not receive any errors in the console related to Auth0.
+
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure that you configured the logout URL as one of the **Allowed Logout URLS** in your application's **Settings**
+- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
+
+## Show user profile information {{{ data-action=code data-code="app.js#31:45" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to personalize the user interface by displaying a logged-in user’s name or profile picture.
+
+The Auth0 SPA SDK provides user information through the `getUser()` function exposed by the Auth0 client. The Auth0 client also exposes an `isAuthenticated()` function that allows you to check whether a user is authenticated or not, which you can use to determine whether to show or hide UI elements, for example. Review the code in the interactive panel to see examples of how to use these functions.
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to view user profile information.
+
+Run your application, and verify that:
+
+- user information displays correctly after you have logged in.
+- user information does not display after you have logged out.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- ensure that all the previous steps work without issue
+- check your code that manages the UI in response to the authentication state
+- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors relating to silent authentication
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
diff --git a/fr-ca/articles/quickstart/spa/vuejs/01-login.md b/fr-ca/articles/quickstart/spa/vuejs/01-login.md
new file mode 100644
index 0000000000..51ca055afa
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/01-login.md
@@ -0,0 +1,29 @@
+---
+title: Login
+description: This quickstart demonstrates how to add user login to a Vue.JS application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - login
+github:
+  path: 01-Login
+sample_download_required_data:
+  - client
+contentType: tutorial
+useCase: quickstart
+---
+
+
+:::note
+Visit the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication) guide for a deep dive into implementing user authentication in Vue. This guide provides additional details on how to create a sign-up button and add route guards to a Vue application.
+:::
+
+::: warning
+This quickstart is designed for using [Auth0 Vue](https://github.com/auth0/auth0-vue) with Vue 3 applications. If you are using Vue 2, please check out the [Vue 2 Tutorial with Auth0 SPA SDK](https://github.com/auth0/auth0-vue/blob/main/tutorial/vue2-login.md) instead or visit the [Vue.js Authentication 2 By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/v2-javascript) guide.
+:::
+
+<%= include('../_includes/_getting_started', { library: 'Vue.js', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %>
+
+<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vuejs/02-calling-an-api.md b/fr-ca/articles/quickstart/spa/vuejs/02-calling-an-api.md
new file mode 100644
index 0000000000..2d21253081
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/02-calling-an-api.md
@@ -0,0 +1,113 @@
+---
+title: Calling an API
+description: This quickstart demonstrates how to make calls to an external API from a Vue.JS application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - apis
+github:
+  path: 02-Calling-an-API
+sample_download_required_data:
+  - client
+  - api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+:::note
+Visit the [Integrate Vue.js with an API Server](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication#integrate-vue-js-with-an-api-server) section of the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication) guide for a deep dive into calling a protected API from Vue. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application.
+:::
+
+<%= include('../_includes/_calling_api_create_api') %>
+
+## Configuring the plugin
+To call an API, configure the plugin by setting the `audience` to the **API Identifier** of the API you want to call:
+
+```ts
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin,
+      audience: "${apiIdentifier}",
+    }
+  })
+);
+
+app.mount('#app');
+```
+
+## Retrieving an Access Token
+With the plugin configured using an `audience`, Auth0 will return an Access Token that can be sent to your API.
+You can retrieve an Access Token by using the `getAccessTokenSilently` function thats exposed by our SDK.
+
+```html
+
+```
+
+### Using the Options API
+
+If you are using the Options API, you can use the same `getAccessTokenSilently` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+```
+
+## Calling an API
+To call an API, include the token in the `Authorization` header of your request.
+There are many ways to make HTTP calls with Vue. Here is an example using the `fetch` API with Vue's Composition API:
+
+```html
+
+```
diff --git a/fr-ca/articles/quickstart/spa/vuejs/_includes/_centralized_login.md b/fr-ca/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
new file mode 100644
index 0000000000..25d782b80f
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
@@ -0,0 +1,203 @@
+
+
+## Install the SDK
+
+Install the [Auth0 Vue SDK](https://github.com/auth0/auth0-vue) using npm:
+
+```bash
+npm install @auth0/auth0-vue
+```
+
+### Register the plugin
+
+To use the SDK in your Vue application, register the plugin with your Vue application by passing the return value of `createAuth0` to `app.use()`.
+
+```js
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  })
+);
+
+app.mount('#app');
+```
+
+The plugin will register the SDK using both `provide` and `app.config.globalProperties`, allowing the SDK to be used with both the [Composition API](https://v3.vuejs.org/guide/composition-api-introduction.html) and [Options API](https://vuejs.org/guide/introduction.html#options-api).
+
+## Add Login to Your Application
+
+To add login to your application, use the `loginWithRedirect` function that is exposed on the return value of `useAuth0`, which you can access in your component's `setup` function.
+
+```html
+
+
+```
+
+The `loginWithRedirect` function will redirect the user to Auth0, and redirect them back to the `redirect_uri` (provided when calling `createAuth0()`) after entering their credentials.
+
+#### Using the Options API
+If you are using the Options API, you can use the same `loginWithRedirect` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
+
+## Add Logout to Your Application
+Use the `logout` function that is exposed on the return value of `useAuth0`, which you can access in your component's `setup` function, to log the user out of your application.
+
+```html
+
+
+```
+
+The `logout()` function will redirect the user to Auth0 to ensure their session is ended with Auth0 as well. Once the user is logged out successfully, they will be redirected back to the specified `returnTo` parameter.
+
+:::note
+To log the user out of your application but not from Auth0, use `logout({ localOnly: true })`.
+:::
+
+#### Using the Options API
+If you're using the Options API, you can use the same `logout` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
+
+## Show User Profile Information
+
+Once the user authenticates, the SDK extracts the user's profile information and stores it in memory. It can be accessed by using the reactive `user` property exposed by the return value of `useAuth0`, which you can access in your component's `setup` function.
+
+```html
+
+
+```
+
+:::note
+Ensure the user is authenticated by implementing login in your application before accessing the user's profile.
+:::
+
+#### Using the Options API
+If you're using the Options API, you can use the same reactive `user` property from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
diff --git a/fr-ca/articles/quickstart/spa/vuejs/download.md b/fr-ca/articles/quickstart/spa/vuejs/download.md
new file mode 100644
index 0000000000..cbbe03dedc
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/download.md
@@ -0,0 +1,29 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Callback URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to 
+
+```text
+http://localhost:3000
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm run serve
+```
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS         
+sh exec.sh                 
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/spa/vuejs/files/index.md b/fr-ca/articles/quickstart/spa/vuejs/files/index.md
new file mode 100644
index 0000000000..71bed0022e
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/index.md
@@ -0,0 +1,22 @@
+---
+name: index.js
+language: javascript
+---
+
+```javascript
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  })
+);
+
+app.mount('#app');
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vuejs/files/login.md b/fr-ca/articles/quickstart/spa/vuejs/files/login.md
new file mode 100644
index 0000000000..7fff90e3d7
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/login.md
@@ -0,0 +1,37 @@
+---
+name: login.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vuejs/files/logout.md b/fr-ca/articles/quickstart/spa/vuejs/files/logout.md
new file mode 100644
index 0000000000..08ffe42448
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vuejs/files/profile.md b/fr-ca/articles/quickstart/spa/vuejs/files/profile.md
new file mode 100644
index 0000000000..cd9f847bbd
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/files/profile.md
@@ -0,0 +1,50 @@
+---
+name: profile.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/spa/vuejs/index.yml b/fr-ca/articles/quickstart/spa/vuejs/index.yml
new file mode 100644
index 0000000000..ead0c3b600
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/index.yml
@@ -0,0 +1,60 @@
+title: Vue
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/vue.png
+logo: vuejs
+language:
+  - Javascript
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+framework:
+  - Vue.js
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-vue
+  url: https://www.github.com/auth0/auth0-vue
+  logo: vuejs
+snippets:
+  dependencies: application-platforms/vuejs/dependencies
+  setup: application-platforms/vuejs/setup
+  use: application-platforms/vuejs/use
+alias:
+  - vue
+  - vuejs
+  - vue.js
+seo_alias: vuejs
+default_article: 01-login
+articles:
+  - 01-login
+  - 02-calling-an-api
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-vue-samples
+  branch: master
+requirements:
+  - Vue 3+
+next_steps:
+  - path: 01-login
+    list:
+    - text: "Part 2: Calling an API using an access token"
+      icon: 345
+      href: "/quickstart/spa/vuejs/02-calling-an-api"
+  - path: 02-calling-an-api
+    list:
+    - text: Accessing ID Token Claims
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#accessing-id-token-claims"
+    - text: Protect a Route
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#protecting-a-route"
+    - text: Handling errors
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#error-handling"
diff --git a/fr-ca/articles/quickstart/spa/vuejs/interactive.md b/fr-ca/articles/quickstart/spa/vuejs/interactive.md
new file mode 100644
index 0000000000..e79e07afdd
--- /dev/null
+++ b/fr-ca/articles/quickstart/spa/vuejs/interactive.md
@@ -0,0 +1,182 @@
+---
+title: Add Login to your Vue App
+description: "Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Vue application using the Auth0 Vue SDK."
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - login
+github:
+  path: 01-Login
+sample_download_required_data:
+  - client
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+---
+
+:::note
+Visit the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/) guide for a deep dive into implementing user authentication in Vue. This guide provides additional details on how to create a sign-up button, add route guards, and call a protected API from Vue.
+:::
+
+# Add Login to Your Vue Application
+
+Auth0 allows you to add authentication to almost any application type. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Vue application using the Auth0 Vue SDK.
+
+::: warning
+This quickstart is designed for using [Auth0 Vue](https://github.com/auth0/auth0-vue) with Vue 3 applications. If you are using Vue 2, please check out the [Vue 2 Tutorial with Auth0 SPA SDK](https://github.com/auth0/auth0-vue/blob/main/tutorial/vue2-login.md) instead or visit the [Vue.js Authentication 2 By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/v2-javascript) guide.
+:::
+
+To use this quickstart, you will need:
+- A free Auth0 account or log in to Auth0.
+- A working Vue project that you want to integrate with OR you can download a sample application after logging in.
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000',
+  returnTo: 'http://localhost:3000',
+  webOriginUrl: 'http://localhost:3000',
+  showWebOriginInfo: true
+}) %>
+
+## Install the Auth0 Vue SDK {{{ data-action=code data-code="index.js" }}}
+
+Auth0 provides a [Vue SDK](https://github.com/auth0/auth0-vue) to simplify the process of implementing Auth0 authentication and authorization in Vue 3 apps.
+
+Install the Auth0 Vue SDK by running the following commands in your terminal:
+
+```bash
+cd 
+npm install @auth0/auth0-vue
+```
+
+### Register the plugin
+
+For the SDK to function, you must register the plugin with your Vue application using the following properties:
+
+- `domain`: The domain of your Auth0 tenant. This value is in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- `authorizationParams.redirect_uri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. This value is in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error.
+
+The plugin will register the SDK using both `provide` and `app.config.globalProperties`. This enables both the [Composition API](https://vuejs.org/guide/introduction.html#composition-api) and [Options API](https://vuejs.org/guide/introduction.html#options-api).
+
+::::checkpoint
+
+:::checkpoint-default
+
+The plugin is now configured. Run your application to verify that:
+- the SDK is initializing correctly
+- your application is not throwing any errors related to Auth0
+
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify you selected the correct application
+* Save your changes after entering your URLs
+* Verify the domain and Client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="login.js" }}}
+
+Next, you will set up login for your project. You will use the SDK’s `loginWithRedirect` function exposed on the return value of `useAuth0`, which you can access in your component's setup function. It will redirect users to the Auth0 Universal Login page. and, after a user authenticates, redirect then back to the callback URL you set up earlier in this quickstart.
+
+### Using the Options API
+If you are using the Options API, you can use the same `loginWithRedirect` method from the global `$auth0` property through the `this` accessor.
+
+
+::::checkpoint
+
+:::checkpoint-default
+
+You should now be able to log in using Auth0 Universal Login.
+
+Click the login button and verify that:
+* your Vue application redirects you to the Auth0 Universal Login page
+* you can log in or sign up
+* Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` you used to configure the plugin.
+
+:::
+
+:::checkpoint-failure
+If you were not able to log in using Auth0 Universal Login:
+* Verify you configured the correct `authorizationParams.redirect_uri`
+* Verify the domain and Client ID are set correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout.js" }}}
+
+Users who log in to your project will also need a way to log out. When users log out, your application will redirect them to your [Auth0 logout](https://auth0.com/docs/api/authentication?javascript#logout) endpoint, which will then redirect them to the specified `logoutParams.returnTo` parameter.
+
+Use the `logout` function exposed on the return value of `useAuth0`, which you can access in your component's `setup` function, to log the user out of your application.
+
+:::note
+To log the user out of your application but not from Auth0, use `logout({ openUrl: false })`.
+:::
+
+### Using the Options API
+With the Options API, you can use the same `logout` method from the global `$auth0` property through the `this` accessor.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* your Vue application redirects you to the `logoutParams.returnTo` address
+* you are no longer logged in to your application
+
+:::
+
+:::checkpoint-failure
+If you are not able to logout:
+* Verify you specified a value for `logoutParams.returnTo` when calling `logout`
+* Verify the Allowed Logout URLs in your Application Settings contains the `returnTo` value.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show user profile information {{{ data-action=code data-code="profile.js" }}}
+
+Next, you will configure how to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+Once the user authenticates, the SDK extracts the user's profile information and stores it in memory. The application can access the user profile with the reactive `user` property. To access this property, review your component's `setup` function and find the `userAuth0` return value.
+
+The `user` property contains sensitive information related to the user's identity. It is only available based on the user's authentication status. To prevent render errors, you should always:
+- use the `isAuthenticated` property to determine whether Auth0 has authenticated the user before Vue renders any component that consumes the `user` property.
+
+- ensure that the SDK has finished loading by checking that `isLoading` is false before accessing the `isAuthenticated` property.
+
+### Using the Options API
+For the Options API, use the same reactive `user`, `isLoading`, and `isAuthenticated` properties from the global `$auth0` property through the `this` accessor.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Verify that:
+* you can display the `user` or any of the user properties within a component correctly after you have logged in
+
+:::
+
+:::checkpoint-failure
+If you are having issues with the `user` properties:
+* Verify you added the `isLoading` check before accessing the `isAuthenticated` property
+* Verify you added the `isAuthenticated` check before accessing the `user` property
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+
+::::
diff --git a/fr-ca/articles/quickstart/webapp/_callbackRegularWebApp.md b/fr-ca/articles/quickstart/webapp/_callbackRegularWebApp.md
new file mode 100644
index 0000000000..574fec99d9
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_callbackRegularWebApp.md
@@ -0,0 +1,10 @@
+

+<% if (account.callback) { %>
+
For security purposes, you must add the callback URL of your app to your Application Settings.

+
Your callback URL is currently set to:

+
<%= account.callback %>

+<% } else { %>
+
For security purposes, you must add the callback URL of your app to your Application Settings.

+<% } %>
+
+

diff --git a/fr-ca/articles/quickstart/webapp/_includes/_auth0_authorize.md b/fr-ca/articles/quickstart/webapp/_includes/_auth0_authorize.md
new file mode 100644
index 0000000000..9da2f5a327
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_auth0_authorize.md
@@ -0,0 +1,16 @@
+## Integrate auth0.js
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md b/fr-ca/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md
new file mode 100644
index 0000000000..202f5cacca
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md
@@ -0,0 +1,5 @@
+
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_callback-url-introduction.md b/fr-ca/articles/quickstart/webapp/_includes/_callback-url-introduction.md
new file mode 100644
index 0000000000..c8a0f44b89
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_callback-url-introduction.md
@@ -0,0 +1,3 @@
+Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and attaches some details to it including a token. Since callback URLs can be manipulated, you will need to add your application's URL in the app's `Allowed Callback URLs` for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful for the app instance.
+
+![Callback error](/media/articles/angularjs/callback_error.png)
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_create_and_assign_roles.md b/fr-ca/articles/quickstart/webapp/_includes/_create_and_assign_roles.md
new file mode 100644
index 0000000000..d9b7b50cf8
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_create_and_assign_roles.md
@@ -0,0 +1,44 @@
+## Create and Assign Roles
+
+Before you can add Role Based Access Control, you will need to ensure the required roles are created and assigned to the corresponding user(s).
+Follow the guidance explained in [assign-roles-to-users](/users/assign-roles-to-users) to ensure your user gets assigned the `admin` role.
+
+Once the role is created and assigned to the required user(s), you will need to create a [rule](/rules/current) that adds the role(s) to the Id Token so that it is available to your backend. To do so, go to the [new rule page](${manage_url}/#/rules/new) and create an empty rule. Then, use the following code for your rule:
+
+<% if (typeof(rolesClaimType) !== "undefined") { %>
+``` js
+function (user, context, callback) {
+  const assignedRoles = (context.authorization || {}).roles;
+  const idTokenClaims = context.idToken || {};
+
+  idTokenClaims['${rolesClaimType}'] = assignedRoles;
+
+  callback(null, user, context);
+}
+```
+<% } %>
+
+<% if (typeof(rolesClaimType) === "undefined") { %>
+``` js
+function (user, context, callback) {
+  const assignedRoles = (context.authorization || {}).roles;
+  const idTokenClaims = context.idToken || {};
+  
+  idTokenClaims['https://schemas.quickstarts.com/roles'] = assignedRoles;
+
+  callback(null, user, context);
+}
+```
+<% } %>
+
+<% if (typeof(rolesClaimType) !== "undefined") { %>
+The role information is expected to exist in the `${rolesClaimType}` claim, be sure to use that when adding the roles to the ID Token in the Auth0 rule.
+<% } %>
+
+<% if (typeof(rolesClaimType) === "undefined") { %>
+  This quickstart uses `https://schemas.quickstarts.com/roles` for the claim [namespace](/tokens/guides/create-namespaced-custom-claims), but it is suggested that you use a namespace related to your own Auth0 tenant for your claims, e.g. `https://schemas.YOUR_TENANT_NAME.com/roles`.
+<% } %>
+
+::: note
+For more information on custom claims, read [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_getting_started.md b/fr-ca/articles/quickstart/webapp/_includes/_getting_started.md
new file mode 100644
index 0000000000..d5ef61e425
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_getting_started.md
@@ -0,0 +1,13 @@
+
+
+::: note
+**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Regular Web Applications](/architecture-scenarios/web-app-sso) and which [protocol](/flows) it uses.
+:::
+
+<%= include('../../../_includes/_new_app', { showClientSecret: true, isPublicClient: false }) %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+::: note
+If you are following along with the sample project you downloaded from the top of this page, the callback URL you need to add to the **Allowed Callback URLs** field is `${callback}`.
+:::
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_install_auth0js.md b/fr-ca/articles/quickstart/webapp/_includes/_install_auth0js.md
new file mode 100644
index 0000000000..ddb3c65520
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_install_auth0js.md
@@ -0,0 +1,23 @@
+## Install auth0.js
+
+Integrating Auth0 in your application requires the **auth0.js** library. Install it using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save auth0-js
+
+# installation with yarn
+yarn add auth0-js
+```
+
+Once **auth0.js** is installed, add it to your build system or bring it in to your project with a script tag.
+
+```html
+
+```
+
+If you don't want to use a package manager, **auth0.js** can also be retrieved from Auth0's CDN.
+
+```html
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_mfa-enable.md b/fr-ca/articles/quickstart/webapp/_includes/_mfa-enable.md
new file mode 100644
index 0000000000..e0d57218a5
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_mfa-enable.md
@@ -0,0 +1,5 @@
+To enable the Auth0 MFA feature, open the [Multi-factor Auth With Guardian](${manage_url}/#/guardian) page and enable the __Push Notifications__ option as shown below:
+
+![dashboard MFA with push notification enabled](/media/articles/mfa/guardian-push-enabled.png)
+
+Click __Save__ and you are ready to test Multi-factor authentication in your application.
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_mfa-introduction.md b/fr-ca/articles/quickstart/webapp/_includes/_mfa-introduction.md
new file mode 100644
index 0000000000..2b9ca2db14
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_mfa-introduction.md
@@ -0,0 +1 @@
+Multi-factor authentication (MFA) is an important method for adding an extra layer of security to your authentication flow. With MFA enabled in your Auth0 account, the process to grant user access to your application will require an additional verification step. In addition to a username/password combination, a verification code generated by a mobile application or sent by SMS/Voice will be required. Currently, Auth0 supports several factors for MFA. For more details, see [Multi-factor Authentication](/mfa).
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_mfa-login.md b/fr-ca/articles/quickstart/webapp/_includes/_mfa-login.md
new file mode 100644
index 0000000000..e06881a255
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_mfa-login.md
@@ -0,0 +1,6 @@
+There is no need to update the code you created in the [Login](${loginlink}) step of this tutorial. As soon as a user initiates sign-in they will be prompted to install a second-factor authenticator application (Auth0 Guardian is the default).
+
+![guardian screen](/media/articles/mfa/choose-mfa.png)
+
+For detailed instructions on using Guardian to authenticate users, see [Guardian](/mfa/concepts/guardian).
+
diff --git a/fr-ca/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md b/fr-ca/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..07cd50cfe0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
@@ -0,0 +1 @@
+Auth0 allows you to store data related to each user that has not come from the identity provider. This is known as metadata. There are two kinds of metadata, **user_metadata** and **app_metadata**. You can read about both of these at [app_metadata and user_metadata](/api/v2/changes#app-_metadata-and-user-_metadata).
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/apache/01-login.md b/fr-ca/articles/quickstart/webapp/apache/01-login.md
new file mode 100644
index 0000000000..5abac44db3
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/01-login.md
@@ -0,0 +1,76 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to use the Auth0 Apache SDK to add authentication and authorization to your web app.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - apache
+  - login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel System Requirements
+This tutorial and seed project have been tested with the following:
+* Apache 2.4
+:::
+
+**Please follow the steps below to configure your application using Apache to work with Auth0 and Open ID Connect.**
+
+## Install and Enable `mod_auth_openidc` Module
+
+First, you need to install the `mod_auth_openidc` module for Apache.
+
+You can get the binaries from [Github](https://github.com/zmartzone/mod_auth_openidc/releases) and install them for your OS. If your OS isn't compatible with any of the binaries, you can still [build it from source](https://github.com/zmartzone/mod_auth_openidc/blob/master/INSTALL)
+
+Once you've installed it, you just need to enable it for Apache (If you are using Windows, you can use [this](https://github.com/enderandpeter/win-a2enmod#installation) to get `a2enmod` working on your system)
+
+${snippet(meta.snippets.dependencies)}
+
+## Configure the Module with Your Auth0 Account Information
+
+Now you should get a new configuration file under the `/etc/apache2/mods-available` folder, where Apache modules are normally installed (On Windows you need to use `/apache/conf/httpd.conf` file).
+
+In there, you must add the following configuration for the `mod_auth_openidc` module
+
+${snippet(meta.snippets.setup)}
+
+## Configuring Auth0 Settings
+
+In your application settings add a new allowed callback which is equal to `OIDCRedirectURI`.
+
+Now, go to OAuth section in advanced settings and change `JsonWebToken Token Signature Algorithm` to RS256.
+
+
+## Authorization
+
+You can configure Apache to protect a certain location based on an attribute of the user. Here is an example:
+
+${snippet(meta.snippets.use)}
+
+Then you can write a rule in Auth0 that would return the `folder` attribute:
+
+```js
+function(user, context, callback) {
+    if (somecondition()) {
+       user.folder = 'example2';
+    }
+
+   user.folder = 'example';
+}
+```
+
+Or you could even use an array of folders and the apache module will check if the array contains any of these values
+
+```js
+function(user, context, callback) {
+    user.folders = [];
+    if (somecondition()) {
+       user.folders.push('example2');
+    }
+
+   user.folders.push('example');
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/apache/index.yml b/fr-ca/articles/quickstart/webapp/apache/index.yml
new file mode 100644
index 0000000000..6484af0cac
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/index.yml
@@ -0,0 +1,18 @@
+title: Apache
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/apache.jpg
+logo: apache
+author:
+  community: true
+topics:
+  - quickstart
+snippets:
+  dependencies: server-platforms/apache/dependencies
+  setup: server-platforms/apache/setup
+  use: server-platforms/apache/use
+seo_alias: apache
+default_article: 01-login
+articles:
+  - 01-login
+contentType: tutorial
+useCase: quickstart
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md
new file mode 100644
index 0000000000..9768084bf7
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md
@@ -0,0 +1,160 @@
+---
+title: Add Login to your ASP.NET Core Blazor Server application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core Blazor Server application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - blazor-server
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../../../_includes/_new_app', { showClientSecret: false, isPublicClient: false }) %>
+
+
+
+### Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the SDK to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application in your [Application Settings](${manage_url}/#/applications), this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate Auth0
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, security, and the most complete array of features. This guide uses Universal Login to provide a way for your users to log in to your Blazor Server application.
+
+### Install dependencies
+
+To integrate Auth0 with Blazor Server you can use our SDK by installing the `Auth0.AspNetCore.Authentication` Nuget package to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Install and configure the SDK
+
+To enable authentication in your Blazor Server application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to configure the Auth0 ASP.NET Core SDK.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+```cs
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+var app = builder.Build();
+```
+
+Make sure you have enabled authentication and authorization in your Program.cs file:
+
+```csharp
+app.UseAuthentication();
+app.UseAuthorization();
+```
+
+## Login
+
+To allow users to login to your Blazor Server application, add a `LoginModel` to your `Pages` directory.
+
+Inside the `LoginModel`'s `OnGet` method, call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After successfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+```cs
+public class LoginModel : PageModel
+{
+    public async Task OnGet(string redirectUri)
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            .WithRedirectUri(redirectUri)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
+
+## Display User Profile
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and make them available through the `AuthenticationState`, which you can add as a `CascadingParameter`.
+
+You can create a custom user profile page for displaying the user's name, as well as additional claims (such as email and picture), by retrieving the corresponding information from the `AuthenticationState`'s `User` property and passing it to the view from inside Blazor code.
+
+
+```csharp
+@page "/Profile"
+@attribute [Authorize]
+
+Profile
+
+

+    

+        

+            
Profile

+            

+                
@Username

+            

+        

+    

+

+
+@code {
+    [CascadingParameter]
+    public Task AuthenticationStateTask { get; set; }
+    private string Username = "";
+
+    protected override async Task OnInitializedAsync()
+    {
+        var state = await AuthenticationStateTask;
+
+        Username = state.User.Identity.Name ?? string.Empty;
+
+        await base.OnInitializedAsync();
+    }
+}
+```
+
+## Logout
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside a `LogoutModel`'s `OnGet` method.
+
+Additionally, if you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `Redirect("/")` or any other appropriate redirect.
+:::
+
+```cs
+[Authorize]
+public class LogoutModel : PageModel
+{
+    public async Task OnGet()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            .WithRedirectUri("/")
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
+
+## What's next?
+
+We put together a few examples of how to use the SDK in more advanced use cases:
+
+- [Configuring Scopes](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#blazor-server)
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/download.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/download.md
new file mode 100644
index 0000000000..49f7a98084
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/download.md
@@ -0,0 +1,30 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [.NET Core](https://www.microsoft.com/net/download) is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md
new file mode 100644
index 0000000000..bb161024d6
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md
@@ -0,0 +1,13 @@
+---
+name: appsettings.json
+language: json
+---
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "ClientId": "${account.clientId}"
+  }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md
new file mode 100644
index 0000000000..c2f7bf7a8a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md
@@ -0,0 +1,18 @@
+---
+name: Login.cshtml.cs
+language: csharp
+---
+
+```csharp
+public class LoginModel : PageModel
+{
+    public async Task OnGet(string redirectUri)
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            .WithRedirectUri(redirectUri)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md
new file mode 100644
index 0000000000..8ba8d1d890
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md
@@ -0,0 +1,20 @@
+---
+name: Logout.cshtml.cs
+language: csharp
+---
+
+```csharp
+[Authorize]
+public class LogoutModel : PageModel
+{
+    public async Task OnGet()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            .WithRedirectUri("/")
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
new file mode 100644
index 0000000000..1c6e68f3d7
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
@@ -0,0 +1,37 @@
+---
+name: Profile.razor
+language: csharp
+---
+
+```csharp
+@page "/Profile"
+@attribute [Authorize]
+
+Profile
+
+

+    

+        

+            
Profile

+            

+                
@Username

+            

+        

+    

+

+
+@code {
+    [CascadingParameter]
+    public Task AuthenticationStateTask { get; set; }
+    private string Username = "";
+
+    protected override async Task OnInitializedAsync()
+    {
+        var state = await AuthenticationStateTask;
+
+        Username = state.User.Identity.Name ?? string.Empty;
+
+        await base.OnInitializedAsync();
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md
new file mode 100644
index 0000000000..1364a4d420
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: csharp
+---
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+builder.Services.AddControllersWithViews();
+
+var app = builder.Build();
+
+app.UseAuthentication();
+app.UseAuthorization();
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml
new file mode 100644
index 0000000000..96471ac09d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml
@@ -0,0 +1,39 @@
+title: ASP.NET Core Blazor Server
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet-platform
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+sdk:
+  name: auth0-aspnetcore-authentication
+  url: https://github.com/auth0/auth0-aspnetcore-authentication
+  logo: dotnet
+snippets:
+  dependencies: server-platforms/aspnet-core/dependencies
+alias:
+  - net-6
+  - net-7
+  - net-8
+seo_alias: aspnet-core-blazor-server
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnetcore-blazor-server-samples
+  branch: main
+requirements:
+  - .NET 6.0
+  - .NET 7.0
+  - .NET 8.0
+sample_download_required_data:
+  - client
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
new file mode 100644
index 0000000000..20a9e39710
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
@@ -0,0 +1,137 @@
+---
+title: Add Login to your ASP.NET Core Blazor Server application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core Blazor Server application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - blazor-server
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/login-model
+  - files/logout-model
+  - files/profile
+  - files/program
+---
+
+# Add Login to Your Blazor Server Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Blazor Server application using the **Auth0.AspNetCore.Authentication** SDK. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install and Configure the SDK {{{ data-action=code data-code="Program.cs" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with Blazor Server you can use our SDK by installing the `Auth0.AspNetCore.Authentication` [Nuget package](https://www.nuget.org/packages/Auth0.AspNetCore.Authentication/) to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Configure the middleware
+
+To enable authentication in your Blazor Server application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to register the SDK's middleware.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+Make sure you have enabled authentication and authorization in your `Program.cs` file.
+
+## Login {{{ data-action=code data-code="Login.cshtml.cs" }}}
+
+To allow users to login to your Blazor Server application, add a `LoginModel` to your `Pages` directory.
+
+Inside the `LoginModel`'s `OnGet` method, call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After successfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` page will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Display User Profile {{{ data-action=code data-code="Profile.razor" }}}
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and make them available through the `AuthenticationState`, which you can add as a `CascadingParameter`.
+
+You can create a custom user profile page for displaying the user's name, as well as additional claims (such as email and picture), by retrieving the corresponding information from the `AuthenticationState`'s `User` property and passing it to the view from inside Blazor code.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up to render the user's profile, run your application to verify that:
+* Navigating to the endpoint containing the profile after being successfully logged in shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Logout {{{ data-action=code data-code="Logout.cshtml.cs" }}}
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside a `LogoutModel`'s `OnGet` method.
+
+Additionally, if you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `Redirect("/")` or any other appropriate redirect.
+:::
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` page will ensure the user is logged out.
+* When also logging out from Auth0, you should be redirected to Auth0 and instantly redirected back to your own application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/01-login.md b/fr-ca/articles/quickstart/webapp/aspnet-core/01-login.md
new file mode 100644
index 0000000000..81a7c55af0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/01-login.md
@@ -0,0 +1,160 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an ASP.NET Core application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../../../_includes/_new_app', { showClientSecret: false, isPublicClient: false }) %>
+
+
+
+### Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the SDK to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application in your [Application Settings](${manage_url}/#/applications), this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate Auth0
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features. This guide will use it to provide a way for your users to log in to your ASP.NET Core application.
+
+### Install dependencies
+
+To integrate Auth0 with ASP.NET Core you can use our SDK by installing the `Auth0.AspNetCore.Authentication` Nuget package to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Install and configure the SDK
+
+To enable authentication in your ASP.NET Core application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to configure the Auth0 ASP.NET Core SDK.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+```cs
+var builder = WebApplication.CreateBuilder(args);
+// Cookie configuration for HTTP to support cookies with SameSite=None
+builder.Services.ConfigureSameSiteNoneCookies();
+
+// Cookie configuration for HTTPS
+//  builder.Services.Configure(options =>
+//  {
+//     options.MinimumSameSitePolicy = SameSiteMode.None;
+//  });
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+builder.Services.AddControllersWithViews();
+var app = builder.Build();
+```
+
+::: note
+The `ConfigureSameSiteNoneCookies` method used above was added as part of the [sample application](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/blob/master/Quickstart/Sample/Support/SameSiteServiceCollectionExtensions.cs) in order to ([make cookies with SameSite=None work over HTTP when using Chrome](https://blog.chromium.org/2019/10/developers-get-ready-for-new.html)). We recommend using HTTPS instead of HTTP, which removes the need for the `ConfigureSameSiteNoneCookies` method.
+:::
+
+Make sure you have enabled authentication and authorization in your Program.cs file:
+
+```csharp
+app.UseAuthentication();
+app.UseAuthorization();
+```
+
+## Login
+
+To add the `Login`, call `ChallengeAsync` and pass "Auth0" (`Auth0Constants.AuthenticationScheme`) as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally.
+
+After the OIDC middleware signs the user in, the user is also automatically signed in to the cookie middleware. This allows the user to be authenticated on subsequent requests.
+
+```cs
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+    public async Task Login(string returnUrl = "/")
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            // Indicate here where Auth0 should redirect the user after a login.
+            // Note that the resulting absolute Uri must be added to the
+            // **Allowed Callback URLs** settings for the app.
+            .WithRedirectUri(returnUrl)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
+
+## Display User Profile
+
+The SDK extracts the user's information from the ID Token and makes them available as the `User.Claims` property on the controller.
+
+You can create a custom user profile page for displaying a user's name, email address, and profile image, by passing the corresponding information to the view from inside your controller.
+
+```csharp
+public class AccountController : Controller
+{
+    [Authorize]
+    public IActionResult Profile()
+    {
+        return View(new
+        {
+            Name = User.Identity.Name,
+            EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
+            ProfileImage = User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value
+        });
+    }
+}
+```
+
+## Logout
+
+To add `Logout`, you need to sign the user out of both the Auth0 middleware as well as the cookie middleware.
+
+```cs
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+    [Authorize]
+    public async Task Logout()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            // Indicate here where Auth0 should redirect the user after a logout.
+            // Note that the resulting absolute Uri must be added to the
+            // **Allowed Logout URLs** settings for the app.
+            .WithRedirectUri(Url.Action("Index", "Home"))
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
+
+## What's next?
+
+We put together a few examples of how to use the SDK in more advanced use cases:
+
+- [Configuring Scopes](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#scopes)
+- [Obtain an Access Token for Calling an API](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#calling-an-api)
+- [Adding Role-based authorization](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#roles)
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/download.md b/fr-ca/articles/quickstart/webapp/aspnet-core/download.md
new file mode 100644
index 0000000000..49f7a98084
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/download.md
@@ -0,0 +1,30 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [.NET Core](https://www.microsoft.com/net/download) is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/files/account.controller.md b/fr-ca/articles/quickstart/webapp/aspnet-core/files/account.controller.md
new file mode 100644
index 0000000000..7e773fd254
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/files/account.controller.md
@@ -0,0 +1,62 @@
+---
+name: AccountController.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+  public async Task Login(string returnUrl = "/")
+  {
+    var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+      // Indicate here where Auth0 should redirect the user after a login.
+      // Note that the resulting absolute Uri must be added to the
+      // **Allowed Callback URLs** settings for the app.
+      .WithRedirectUri(returnUrl)
+      .Build();
+
+    await HttpContext.ChallengeAsync(
+      Auth0Constants.AuthenticationScheme,
+      authenticationProperties
+    );
+  }
+
+  [Authorize]
+  public IActionResult Profile()
+  {
+    return View(new
+    {
+      Name = User.Identity.Name,
+      EmailAddress = User.Claims
+        .FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
+      ProfileImage = User.Claims
+        .FirstOrDefault(c => c.Type == "picture")?.Value
+    });
+  }
+
+  [Authorize]
+  public async Task Logout()
+  {
+    var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+      // Indicate here where Auth0 should redirect the user after a logout.
+      // Note that the resulting absolute Uri must be added to the
+      // **Allowed Logout URLs** settings for the app.
+      .WithRedirectUri(Url.Action("Index", "Home"))
+      .Build();
+
+    // Logout from Auth0
+    await HttpContext.SignOutAsync(
+      Auth0Constants.AuthenticationScheme,
+      authenticationProperties
+    );
+    // Logout from the application
+    await HttpContext.SignOutAsync(
+      CookieAuthenticationDefaults.AuthenticationScheme
+    );
+  }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/files/appsettings.md b/fr-ca/articles/quickstart/webapp/aspnet-core/files/appsettings.md
new file mode 100644
index 0000000000..bb161024d6
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/files/appsettings.md
@@ -0,0 +1,13 @@
+---
+name: appsettings.json
+language: json
+---
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "ClientId": "${account.clientId}"
+  }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/files/program.md b/fr-ca/articles/quickstart/webapp/aspnet-core/files/program.md
new file mode 100644
index 0000000000..1364a4d420
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: csharp
+---
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+builder.Services.AddControllersWithViews();
+
+var app = builder.Build();
+
+app.UseAuthentication();
+app.UseAuthorization();
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/index.yml b/fr-ca/articles/quickstart/webapp/aspnet-core/index.yml
new file mode 100644
index 0000000000..3b3a20f345
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/index.yml
@@ -0,0 +1,39 @@
+title: ASP.NET Core MVC
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet-platform
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+sdk:
+  name: auth0-aspnetcore-authentication
+  url: https://github.com/auth0/auth0-aspnetcore-authentication
+  logo: dotnet
+snippets:
+  dependencies: server-platforms/aspnet-core/dependencies
+alias:
+  - net-6
+  - net-7
+  - net-8
+seo_alias: aspnet-core
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnetcore-mvc-samples
+  branch: master
+requirements:
+  - .NET 6.0
+  - .NET 7.0
+  - .NET 8.0
+sample_download_required_data:
+  - client
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-core/interactive.md b/fr-ca/articles/quickstart/webapp/aspnet-core/interactive.md
new file mode 100644
index 0000000000..54ebad8df2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-core/interactive.md
@@ -0,0 +1,134 @@
+---
+title: Add Login to your ASP.NET MVC application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/program
+  - files/appsettings
+  - files/account.controller
+---
+
+# Add Login to Your ASP.NET MVC Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET MVC application using the **Auth0.AspNetCore.Authentication** SDK. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install and Configure the SDK {{{ data-action=code data-code="Program.cs" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with ASP.NET Core you can use our SDK by installing the `Auth0.AspNetCore.Authentication` [Nuget package](https://www.nuget.org/packages/Auth0.AspNetCore.Authentication/) to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Configure the middleware
+
+To enable authentication in your ASP.NET Core application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to register the SDK's middleware.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+Make sure you have enabled authentication and authorization in your `Program.cs` file.
+## Login {{{ data-action=code data-code="AccountController.cs#7:20" }}}
+
+To allow users to login to your ASP.NET MVC application, add a `Login` action to your controller.
+
+Call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After succesfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` action will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Display User Profile {{{ data-action=code data-code="AccountController.cs#23:33" }}}
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and makes them available as the `User.Claims` property on the controller.
+
+You can create a custom user profile page for displaying a user's name, email address, and profile image, by retrieving the corresponding information from the `User` and pass it to the view from inside your controller.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up your action to render the user's profile, run your application to verify that:
+* Navigating to your `Profile` action after being succesfully logged in, shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Logout {{{ data-action=code data-code="AccountController.cs#36:52" }}}
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside your controller's action.
+
+Additionaly, If you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `RedirectToAction("Index", "Home")` or any other appropriate redirect.
+:::
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` action will ensure the user is logged out.
+* When also logging out from Auth0, you should be redirected to Auth0 and instantly redirected back to your own application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/01-login.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/01-login.md
new file mode 100644
index 0000000000..beb980dd2b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/01-login.md
@@ -0,0 +1,204 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an ASP.NET OWIN application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-owin
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+sample_download_required_data:
+  - client
+---
+<%= include('../../../_includes/_new_app', { showClientSecret: true, isPublicClient: false }) %>
+
+<%= include('_includes/_setup') %>
+
+## Install and configure the OpenID Connect middleware
+
+::: note
+  This quickstart uses OWIN middleware and as such, you need to use OWIN in your application. If your application is not currently using OWIN, please refer to Microsoft's OWIN documentation to enable it in your application.
+:::
+
+The easiest way to enable authentication with Auth0 in your ASP.NET MVC application is to use the OWIN OpenID Connect middleware, so install the `Microsoft.Owin.Security.OpenIdConnect` NuGet package first:
+
+```bash
+Install-Package Microsoft.Owin.Security.OpenIdConnect
+```
+
+You must also install the following middleware library to enable cookie authentication in your project:
+
+```bash
+Install-Package Microsoft.Owin.Security.Cookies
+```
+
+::: note
+There are issues when configuring the OWIN cookie middleware and System.Web cookies at the same time. Please read about the [System.Web cookie integration issues doc](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues) to learn about how to mitigate these problems
+:::
+
+Now go to the `Configuration` method of your `Startup` class and configure the cookie middleware as well as the Auth0 middleware.
+
+```cs
+// Startup.cs
+using Microsoft.IdentityModel.Protocols.OpenIdConnect;
+using Microsoft.IdentityModel.Tokens;
+using Microsoft.Owin;
+using Microsoft.Owin.Host.SystemWeb;
+using Microsoft.Owin.Security;
+using Microsoft.Owin.Security.Cookies;
+using Microsoft.Owin.Security.OpenIdConnect;
+using MvcApplication.Support;
+using Owin;
+
+public void Configuration(IAppBuilder app)
+{
+    // Configure Auth0 parameters
+    string auth0Domain = ConfigurationManager.AppSettings["auth0:Domain"];
+    string auth0ClientId = ConfigurationManager.AppSettings["auth0:ClientId"];
+    string auth0RedirectUri = ConfigurationManager.AppSettings["auth0:RedirectUri"];
+    string auth0PostLogoutRedirectUri = ConfigurationManager.AppSettings["auth0:PostLogoutRedirectUri"];
+
+    // Set Cookies as default authentication type
+    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
+    app.UseCookieAuthentication(new CookieAuthenticationOptions
+    {
+        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+        LoginPath = new PathString("/Account/Login"),
+
+        // Configure SameSite as needed for your app. Lax works well for most scenarios here but
+        // you may want to set SameSiteMode.None for HTTPS
+        CookieSameSite = SameSiteMode.Lax,
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())
+    });
+
+    // Configure Auth0 authentication
+    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+    {
+        AuthenticationType = "Auth0",
+
+        Authority = $"https://{auth0Domain}",
+
+        ClientId = auth0ClientId,
+
+        RedirectUri = auth0RedirectUri,
+        PostLogoutRedirectUri = auth0PostLogoutRedirectUri,
+        Scope = "openid profile email",
+        TokenValidationParameters = new TokenValidationParameters
+        {
+            NameClaimType = "name"
+        },
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://docs.microsoft.com/en-us/aspnet/samesite/owin-samesite
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()),
+
+        // Configure Auth0's Logout URL by hooking into the RedirectToIdentityProvider notification, 
+        // which is getting triggered before any redirect to Auth0 happens.
+        Notifications = new OpenIdConnectAuthenticationNotifications
+        {
+            RedirectToIdentityProvider = notification =>
+            {
+                // Only when the RequestType is OpenIdConnectRequestType.Logout should we configure the logout URL.
+                // Any other RequestType means a different kind of interaction with Auth0 that isn't logging out.
+                if (notification.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
+                {
+                    var logoutUri = $"https://{auth0Domain}/v2/logout?client_id={auth0ClientId}";
+
+                    var postLogoutUri = notification.ProtocolMessage.PostLogoutRedirectUri;
+                    if (!string.IsNullOrEmpty(postLogoutUri))
+                    {
+                        if (postLogoutUri.StartsWith("/"))
+                        {
+                            // transform to absolute
+                            var request = notification.Request;
+                            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
+                        }
+                        logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
+                    }
+
+                    notification.Response.Redirect(logoutUri);
+                    notification.HandleResponse();
+                }
+                return Task.FromResult(0);
+            }
+        }
+    });
+}
+```
+
+It is essential that you register both the cookie middleware and the OpenID Connect middleware, as they are required (in that order) for the authentication to work. The OpenID Connect middleware will handle the authentication with Auth0. Once the user has authenticated, their identity will be stored in the cookie middleware.
+
+In the code snippet above, note that the `AuthenticationType` is set to **Auth0**. This will be used in the next section to challenge the OpenID Connect middleware and start the authentication flow. Also note code in the `RedirectToIdentityProvider` notification event which constructs the correct [logout URL](/logout).
+
+
+
+
+## Add login to your ASP.NET OWIN application
+
+To allow users to login to your ASP.NET OWIN application, add a `Login` action to your controller.
+
+Call `HttpContext.GetOwinContext().Authentication.Challenge` and pass `"Auth0"` as the authentication scheme. This invokes the OIDC authentication handler that was registered earlier. Be sure to specify the corresponding `AuthenticationProperties`, including a `RedirectUri`.
+
+After successfully calling `HttpContext.GetOwinContext().Authentication.Challenge`, the user is redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow users to be authenticated on subsequent requests.
+
+```cs
+public class AccountController : Controller
+{
+    public ActionResult Login(string returnUrl)
+    {
+        HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties
+            {
+                RedirectUri = returnUrl ?? Url.Action("Index", "Home")
+            },
+            "Auth0");
+        return new HttpUnauthorizedResult();
+    }
+}
+```
+
+## Add logout to your ASP.NET OWIN application
+
+From your controller's action, call `HttpContext.GetOwinContext().Authentication.SignOut` with the `CookieAuthenticationDefaults.AuthenticationType` authentication scheme to log the user out of your application.
+
+Additionally, if you want to log the user out from Auth0 (this might also log them out of other applications that rely on Single Sign-On), call `HttpContext.GetOwinContext().Authentication.SignOut` with the `"Auth0"` authentication scheme.
+
+```cs
+public class AccountController : Controller
+{
+    [Authorize]
+    public void Logout()
+    {
+        HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
+        HttpContext.GetOwinContext().Authentication.SignOut("Auth0");
+    }
+}
+```
+
+## Display the user profile
+
+After the middleware successfully retrieves the tokens from Auth0, it extracts the user's information and claims from the ID token and makes them available as `ClaimsIdentity`. Access the extracted information by using the `User` property on the controller.
+
+To create a user profile, retrieve a user's name, email address, and profile image from `User.Identity` and pass it to the view from inside your controller.
+```csharp
+// Controllers/AccountController.cs
+
+[Authorize]
+public ActionResult UserProfile()
+{
+    var claimsIdentity = User.Identity as ClaimsIdentity;
+
+    return View(new
+    {
+        Name = claimsIdentity?.FindFirst(c => c.Type == claimsIdentity.NameClaimType)?.Value,
+        EmailAddress = claimsIdentity?.FindFirst(c => c.Type == ClaimTypes.Email)?.Value,
+        ProfileImage = claimsIdentity?.FindFirst(c => c.Type == "picture")?.Value
+    });
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
new file mode 100644
index 0000000000..5db5d77940
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
@@ -0,0 +1,9 @@
+## Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the OWIN OpenID Connect middleware to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application. The Callback URL for the seed project is `http://localhost:3000/callback`, so be sure to add this to the **Allowed Callback URLs** section of your application. Also, add `http://localhost:3000/` to the **Allowed Logout URLs**.
+
+If you deploy your application to a different URL you will also need to ensure to add that URL to the **Allowed Callback URLs** and **Allowed Logout URLs**. The `web.config` in the sample projects also contain two keys named `auth0:RedirectUri` and `auth0:PostLogoutRedirectUri` with these URLs. Be sure to change those as well.
+
+That's all you need to start working with Auth0!
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/download.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/download.md
new file mode 100644
index 0000000000..5c9fea1bc1
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/download.md
@@ -0,0 +1,15 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000
+```
+
+3) Open the project in [Visual Studio](https://visualstudio.microsoft.com/vs/).
+
+4) Click the `Start` button or select the menu option `Debug | Start Debugging` or use the keyboard shortcut `F5`.
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/files/account.controller.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/account.controller.md
new file mode 100644
index 0000000000..f3a44a134e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/account.controller.md
@@ -0,0 +1,46 @@
+---
+name: AccountController.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+
+public class AccountController : Controller
+{
+  public ActionResult Login(string returnUrl = "/")
+  {
+    HttpContext.GetOwinContext().Authentication.Challenge(
+      new AuthenticationProperties
+      {
+          RedirectUri = returnUrl ?? Url.Action("Index", "Home")
+      },
+      "Auth0"
+    );
+  }
+
+  [Authorize]
+  public ActionResult UserProfile()
+  {
+      var claimsIdentity = User.Identity as ClaimsIdentity;
+
+      return View(new UserProfileViewModel()
+      {
+          Name = claimsIdentity?
+            .FindFirst(c => c.Type == claimsIdentity.NameClaimType)?.Value,
+          EmailAddress = claimsIdentity?
+            .FindFirst(c => c.Type == ClaimTypes.Email)?.Value,
+          ProfileImage = claimsIdentity?
+            .FindFirst(c => c.Type == "picture")?.Value
+      });
+  }
+
+  [Authorize]
+  public void Logout()
+  {
+    HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
+    HttpContext.GetOwinContext().Authentication.SignOut("Auth0");
+  }
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/files/startup.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/startup.md
new file mode 100644
index 0000000000..1dcde454f0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/startup.md
@@ -0,0 +1,83 @@
+---
+name: Startup.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.IdentityModel.Protocols.OpenIdConnect;
+using Microsoft.IdentityModel.Tokens;
+using Microsoft.Owin;
+using Microsoft.Owin.Host.SystemWeb;
+using Microsoft.Owin.Security;
+using Microsoft.Owin.Security.Cookies;
+using Microsoft.Owin.Security.OpenIdConnect;
+using MvcApplication.Support;
+using Owin;
+
+public void Configuration(IAppBuilder app)
+{
+    string domain = ConfigurationManager.AppSettings["auth0:Domain"];
+    string clientId = ConfigurationManager.AppSettings["auth0:ClientId"];
+    string redirectUri = "http://localhost:3000/callback";
+    string postLogoutRedirectUri = "http://localhost:3000";
+
+    // Set Cookies as default authentication type
+    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
+    app.UseCookieAuthentication(new CookieAuthenticationOptions
+    {
+        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+        LoginPath = new PathString("/Account/Login"),
+
+        CookieSameSite = SameSiteMode.Lax,
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())
+    });
+
+    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+    {
+        AuthenticationType = "Auth0",
+        Authority = $"https://{domain}",
+        ClientId = clientId,
+        RedirectUri = redirectUri,
+        PostLogoutRedirectUri = postLogoutRedirectUri,
+        ResponseType = OpenIdConnectResponseType.CodeIdToken,
+        Scope = "openid profile email",
+        TokenValidationParameters = new TokenValidationParameters
+        {
+            NameClaimType = "name"
+        },
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://docs.microsoft.com/en-us/aspnet/samesite/owin-samesite
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()),
+        Notifications = new OpenIdConnectAuthenticationNotifications
+        {
+            RedirectToIdentityProvider = notification =>
+            {
+                if (notification.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
+                {
+                    var logoutUri = $"https://{domain}/v2/logout?client_id={clientId}";
+
+                    var postLogoutUri = notification.ProtocolMessage.PostLogoutRedirectUri;
+                    if (!string.IsNullOrEmpty(postLogoutUri))
+                    {
+                        if (postLogoutUri.StartsWith("/"))
+                        {
+                            // transform to absolute
+                            var request = notification.Request;
+                            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
+                        }
+                        logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
+                    }
+
+                    notification.Response.Redirect(logoutUri);
+                    notification.HandleResponse();
+                }
+                return Task.FromResult(0);
+            }
+        }
+    });
+}
+```
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/files/web.config.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/web.config.md
new file mode 100644
index 0000000000..02a8c6b911
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/files/web.config.md
@@ -0,0 +1,14 @@
+---
+name: Web.config
+language: xml
+---
+
+```xml
+
+
+  
+    
+    
+  
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/index.yml b/fr-ca/articles/quickstart/webapp/aspnet-owin/index.yml
new file mode 100644
index 0000000000..a14bac0006
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/index.yml
@@ -0,0 +1,48 @@
+title: ASP.NET (OWIN)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@okta.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-platforms/aspnet-owin/dependencies
+  setup: server-platforms/aspnet-owin/setup
+  use: server-platforms/aspnet-owin/use
+alias:
+  - aspnetowin
+  - owin
+seo_alias: aspnet-owin
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnet-owin-mvc-samples
+  branch: master
+requirements:
+  - Microsoft Visual Studio 2017
+  - Microsoft.Owin.Security.OpenIdConnect v4.1.0 and up
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/fr-ca/articles/quickstart/webapp/aspnet-owin/interactive.md b/fr-ca/articles/quickstart/webapp/aspnet-owin/interactive.md
new file mode 100644
index 0000000000..f54465e77b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/aspnet-owin/interactive.md
@@ -0,0 +1,141 @@
+---
+title: Add Login to your ASP.NET Owin application
+description: This tutorial demonstrates how to add user login to an ASP.NET Owin application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-owin
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/web.config
+  - files/startup
+  - files/account.controller
+---
+
+# Add login to your ASP.NET Owin application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET OWIN application using the `Microsoft.Owin.Security.OpenIdConnect` Nuget package. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Configure the project {{{ data-action=code data-code="Web.config#1:7" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with ASP.NET OWIN, you can use the `Microsoft.Owin.Security.OpenIdConnect` and `Microsoft.Owin.Security.Cookies` Nuget packages.
+
+```bash
+Install-Package Microsoft.Owin.Security.OpenIdConnect
+Install-Package Microsoft.Owin.Security.Cookies
+```
+
+:::note
+Issues occur when configuring the OWIN cookie middleware and System.Web cookies at the same time. To learn more, read [System.Web cookie integration issues doc](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues) to mitigate these problems.
+:::
+
+### Configure the credentials
+For the SDK to function properly, set the following properties in `Web.config`:
+- `auth0:Domain`: The domain of your Auth0 tenant. You can find this in the Auth0 Dashboard under your application's **Settings** in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- `auth0:ClientId`: The ID of the Auth0 application you created in Auth0 Dashboard. You can find this in the Auth0 Dashboard under your application's **Settings** in the Client ID field.
+
+## Configure the middleware {{{ data-action=code data-code="Startup.cs#9:13" }}}
+
+To enable authentication in your ASP.NET OWIN application, go to the `Configuration` method of your `Startup` class and configure the cookie and OIDC middleware.
+
+It is essential that you register both the cookie middleware and the OpenID Connect middleware as both are required (in that order) for authentication to work. The OpenID Connect middleware handles the authentication with Auth0. Once users have authenticated, their identity is stored in the cookie middleware.
+
+In the code snippet, `AuthenticationType` is set to **Auth0**. Use `AuthenticationType` in the next section to challenge the OpenID Connect middleware and start the authentication flow. `RedirectToIdentityProvider` notification event constructs the correct [logout URL](/logout).
+
+## Add login to your application {{{ data-action=code data-code="AccountController.cs#6:15" }}}
+
+To allow users to log in to your ASP.NET OWIN application, add a `Login` action to your controller.
+
+Call `HttpContext.GetOwinContext().Authentication.Challenge` and pass `"Auth0"` as the authentication scheme. This invokes the OIDC authentication handler that was registered earlier. Be sure to specify the corresponding `AuthenticationProperties`, including a `RedirectUri`.
+
+After successfully calling `HttpContext.GetOwinContext().Authentication.Challenge`, the user redirects to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` action will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple of things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Add logout to your application {{{ data-action=code data-code="AccountController.cs#34:39" }}}
+
+From your controller's action, call `HttpContext.GetOwinContext().Authentication.SignOut` with the `CookieAuthenticationDefaults.AuthenticationType` authentication scheme to log the user out of your application.
+
+Additionally, if you want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign-On), call `HttpContext.GetOwinContext().Authentication.SignOut` with the `"Auth0"` authentication scheme.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` action ensures the user is logged out.
+* During logout, you redirect to Auth0 and instantly redirect back to your application during log out.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple of things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show user profile information {{{ data-action=code data-code="AccountController.cs#18:32" }}}
+
+After the middleware successfully retrieves the tokens from Auth0, it extracts the user's information and claims from the ID token and makes them available as `ClaimsIdentity`. Access the extracted information by using the `User` property on the controller.
+
+To create a user profile, retrieve a user's name, email address, and profile image from the `User` and pass it to the view from inside your controller.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up your action to render the user's profile, run your application to verify that:
+* Navigating to your `Profile` action after being successfully logged in, shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* make sure the correct application is selected
+* make sure the domain and client ID are configured correctly
+* Did you set `openid profile email` as the scope?
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/fr-ca/articles/quickstart/webapp/config.yml b/fr-ca/articles/quickstart/webapp/config.yml
new file mode 100644
index 0000000000..51f64e8751
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - client
diff --git a/fr-ca/articles/quickstart/webapp/django/01-login.md b/fr-ca/articles/quickstart/webapp/django/01-login.md
new file mode 100644
index 0000000000..a137f3bf98
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/01-login.md
@@ -0,0 +1,272 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login to a Python web application built with the Django framework and Authlib OAuth library.
+budicon: 448
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - django
+github:
+    path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Python', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Create application
+
+For this guide we demonstrate how to integrate Auth0 with a Python application using the [Django framework](https://www.djangoproject.com/) and [Authlib](https://authlib.org/). Let's start by ensuring Django is installed on your system. From your shell, run the following command:
+
+```sh
+pip install django~=4.0
+```
+
+If you already have a Python application setup, you can skip to the next step. Otherwise, let's create our new application project. From your shell, run the following command, and switch to the new project folder:
+
+```sh
+django-admin startproject webappexample
+cd webappexample
+```
+
+## Install dependencies
+
+For this integration you'll need few library dependencies, such as Authlib. Go ahead and create a `requirements.txt` file in your project directory, and include the following:
+
+```python
+# 📁 requirements.txt -----
+
+authlib ~= 1.0
+django ~= 4.0
+python-dotenv ~= 0.19
+requests ~= 2.27
+```
+
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+```
+
+## Update `settings.py`
+
+You'll want to make some minor changes to your `webappexample/settings.py` file to read those `.env` values. At the top of the file, add these imports:
+
+```python
+# 📁 webappexample/settings.py -----
+
+import os
+from dotenv import load_dotenv, find_dotenv
+```
+
+Next, beneath the 'BASE_DIR' definition, add the following:
+
+```python
+# 📁 webappexample/settings.py -----
+
+# Add the following line after 'BASE_DIR = ...'
+TEMPLATE_DIR = os.path.join(BASE_DIR, "webappexample", "templates")
+```
+
+Next, find the `TEMPLATES` variable and update the `DIRS` value to add our `TEMPLATE_DIR` string. This tells Django where to look for our template files, once we create them. Keep any other content of this array the same.
+
+```python
+# 📁 webappexample/settings.py -----
+
+TEMPLATES = [
+    {
+        # Leave other lines as they are; we're just updating `DIRS`.
+        "DIRS": [TEMPLATE_DIR],
+    },
+]
+```
+
+Finally, at the end of this file, add the following:
+
+```python
+# 📁 webappexample/settings.py -----
+
+# Load environment definition file
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+
+
+# Load Auth0 application settings into memory
+AUTH0_DOMAIN = os.environ.get("AUTH0_DOMAIN")
+AUTH0_CLIENT_ID = os.environ.get("AUTH0_CLIENT_ID")
+AUTH0_CLIENT_SECRET = os.environ.get("AUTH0_CLIENT_SECRET")
+```
+
+## Setup your application
+
+Now you're ready to start writing your application. Open the `webappexample/views.py` file in your project director.
+
+Begin by importing all the libraries your application will be making use of:
+
+```python
+# 📁 webappexample/views.py -----
+
+import json
+from authlib.integrations.django_client import OAuth
+from django.conf import settings
+from django.shortcuts import redirect, render
+from django.urls import reverse
+from urllib.parse import quote_plus, urlencode
+```
+
+Now you can configure Authlib to handle your application's authentication with Auth0:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+oauth = OAuth()
+
+oauth.register(
+    "auth0",
+    client_id=settings.AUTH0_CLIENT_ID,
+    client_secret=settings.AUTH0_CLIENT_SECRET,
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f"https://{settings.AUTH0_DOMAIN}/.well-known/openid-configuration",
+)
+```
+
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your route handlers
+
+For this demonstration, we'll be adding 4 routes for your application: your login, callback, logout and index routes.
+
+### Triggering authentication with `/login`
+When visitors to your app visit the `/login` route, they'll be redirected to Auth0 to begin the authentication flow.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def login(request):
+    return oauth.auth0.authorize_redirect(
+        request, request.build_absolute_uri(reverse("callback"))
+    )
+```
+
+### Finalizing authentication with `/callback`
+After your users finish logging in with Auth0, they'll be returned to your application at the `/callback` route. This route is responsible for actually saving the session for the user, so when they visit again later, they won't have to sign back in all over again.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def callback(request):
+    token = oauth.auth0.authorize_access_token(request)
+    request.session["user"] = token
+    return redirect(request.build_absolute_uri(reverse("index")))
+```
+
+### Clearing a session with `/logout`
+As you might expect, this route handles signing a user out from your application. It will clear the user's session in your app, and briefly redirect to Auth0's logout endpoint to ensure their session is completely clear, before they are returned to your home route (covered next.)
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def logout(request):
+    request.session.clear()
+
+    return redirect(
+        f"https://{settings.AUTH0_DOMAIN}/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": request.build_absolute_uri(reverse("index")),
+                "client_id": settings.AUTH0_CLIENT_ID,
+            },
+            quote_via=quote_plus,
+        ),
+    )
+```
+
+### There's no place like `/home`
+Last but not least, your home route will serve as a place to either render an authenticated user's details, or offer to allow visitors to sign in.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def index(request):
+    return render(
+        request,
+        "index.html",
+        context={
+            "session": request.session.get("user"),
+            "pretty": json.dumps(request.session.get("user"), indent=4),
+        },
+    )
+```
+
+### Register your routes
+Finally, you'll need to tell Django how to connect these new routes. Replace the contents of your `webappexample/urls.py` file with the following:
+
+```python
+# 📁 webappexample/urls.py -----
+
+from django.urls import path
+
+from . import views
+
+urlpatterns = [
+    path("", views.index, name="index"),
+    path("login", views.login, name="login"),
+    path("logout", views.logout, name="logout"),
+    path("callback", views.callback, name="callback"),
+]
+
+```
+
+## Add templates
+
+Now we just need to create the simple template files used in the routes about (during `render()` calls).
+
+Create a new sub-directory within the `webappexample` folder named `templates`, and create a `index.html` file:
+
+```html
+# 📁 webappexample/templates/index.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+    
Welcome {{session.userinfo.name}}!

+    
Logout

+    
{{pretty}}

+    {% else %}
+    
Welcome Guest

+    
Login

+    {% endif %}
+  
+
+
+```
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 manage.py migrate
+python3 manage.py runserver 3000
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
diff --git a/fr-ca/articles/quickstart/webapp/django/download.md b/fr-ca/articles/quickstart/webapp/django/download.md
new file mode 100644
index 0000000000..7bc0b750da
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/download.md
@@ -0,0 +1,30 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Python](https://www.python.org/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+pip install -r requirements.txt
+python manage.py migrate 
+python manage.py runserver 3000
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/django/files/index.md b/fr-ca/articles/quickstart/webapp/django/files/index.md
new file mode 100644
index 0000000000..7daba88473
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/index.md
@@ -0,0 +1,26 @@
+---
+name: webappexample/templates/index.html
+language: html
+---
+
+
+
+```html
+
+
+  
+  Auth0 Example
+
+
+{% if session %}
+  
Welcome {{session.userinfo.name}}!

+  
Logout

+  
{{pretty}}

+{% else %}
+  
Welcome Guest

+  
Login

+{% endif %}
+
+
+
+```
diff --git a/fr-ca/articles/quickstart/webapp/django/files/settings.md b/fr-ca/articles/quickstart/webapp/django/files/settings.md
new file mode 100644
index 0000000000..a944c7f58d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/settings.md
@@ -0,0 +1,37 @@
+---
+name: webappexample/settings.py
+language: python
+---
+
+
+
+```python
+import os
+from pathlib import Path
+from dotenv import load_dotenv, find_dotenv
+
+# Build paths inside the project like this: BASE_DIR / 'subdir'.
+BASE_DIR = Path(__file__).resolve().parent.parent
+TEMPLATE_DIR = os.path.join(BASE_DIR, "webappexample", "templates")
+
+# ... other settings ...
+
+TEMPLATES = [
+    {
+        # Leave other lines as they are; we're just updating `DIRS`.
+        "DIRS": [TEMPLATE_DIR],
+    },
+]
+
+# ... other settings ...
+
+# Load environment definition file
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+
+# Load Auth0 application settings into memory
+AUTH0_DOMAIN = os.environ.get("AUTH0_DOMAIN")
+AUTH0_CLIENT_ID = os.environ.get("AUTH0_CLIENT_ID")
+AUTH0_CLIENT_SECRET = os.environ.get("AUTH0_CLIENT_SECRET")
+```
diff --git a/fr-ca/articles/quickstart/webapp/django/files/urls.md b/fr-ca/articles/quickstart/webapp/django/files/urls.md
new file mode 100644
index 0000000000..2f77e379a8
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/urls.md
@@ -0,0 +1,19 @@
+---
+name: webappexample/urls.py
+language: python
+---
+
+
+
+```python
+from django.urls import path
+
+from . import views
+
+urlpatterns = [
+    path("", views.index, name="index"),
+    path("login", views.login, name="login"),
+    path("logout", views.logout, name="logout"),
+    path("callback", views.callback, name="callback"),
+]
+```
diff --git a/fr-ca/articles/quickstart/webapp/django/files/views.md b/fr-ca/articles/quickstart/webapp/django/files/views.md
new file mode 100644
index 0000000000..19da7478fe
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/files/views.md
@@ -0,0 +1,61 @@
+---
+name: webappexample/views.py
+language: python
+---
+
+
+
+```python
+import json
+from authlib.integrations.django_client import OAuth
+from django.conf import settings
+from django.shortcuts import redirect, render, redirect
+from django.urls import reverse
+from urllib.parse import quote_plus, urlencode
+
+oauth = OAuth()
+
+oauth.register(
+    "auth0",
+    client_id=settings.AUTH0_CLIENT_ID,
+    client_secret=settings.AUTH0_CLIENT_SECRET,
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f"https://{settings.AUTH0_DOMAIN}/.well-known/openid-configuration",
+)
+
+def login(request):
+    return oauth.auth0.authorize_redirect(
+        request, request.build_absolute_uri(reverse("callback"))
+    )
+
+def callback(request):
+    token = oauth.auth0.authorize_access_token(request)
+    request.session["user"] = token
+    return redirect(request.build_absolute_uri(reverse("index")))
+
+def logout(request):
+    request.session.clear()
+
+    return redirect(
+        f"https://{settings.AUTH0_DOMAIN}/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": request.build_absolute_uri(reverse("index")),
+                "client_id": settings.AUTH0_CLIENT_ID,
+            },
+            quote_via=quote_plus,
+        ),
+    )
+
+def index(request):
+    return render(
+        request,
+        "index.html",
+        context={
+            "session": request.session.get("user"),
+            "pretty": json.dumps(request.session.get("user"), indent=4),
+        },
+    )
+```
diff --git a/fr-ca/articles/quickstart/webapp/django/index.yml b/fr-ca/articles/quickstart/webapp/django/index.yml
new file mode 100644
index 0000000000..a44e0e28d1
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/index.yml
@@ -0,0 +1,46 @@
+title: Django
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/python.png
+logo: python
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+snippets:
+  dependencies: server-platforms/django/dependencies
+  setup: server-platforms/django/setup
+  use: server-platforms/django/use
+seo_alias: django
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-django-web-app
+  branch: master
+requirements:
+  - Python 3
+  - Authlib 1.0
+  - Django 4.0
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/fr-ca/articles/quickstart/webapp/django/interactive.md b/fr-ca/articles/quickstart/webapp/django/interactive.md
new file mode 100644
index 0000000000..195f7cced0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/django/interactive.md
@@ -0,0 +1,147 @@
+---
+title: Add Login to your Django application
+description: This tutorial demonstrates how to add user login to a Django application.
+topics:
+  - quickstarts
+  - webapp
+  - django
+  - login
+github:
+  path: 01-Login
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/index
+  - files/settings
+  - files/urls
+  - files/views
+---
+
+
+
+# Add Login to Your Django Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with a Python [Django](https://www.djangoproject.com/) application using the [Authlib](https://authlib.org/) SDK.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies
+
+For this integration, you will add several library dependencies, such as Authlib. Create a `requirements.txt` file in your project directory, and include the following:
+
+```python
+# 📁 requirements.txt -----
+
+authlib ~= 1.0
+django ~= 4.0
+python-dotenv ~= 0.19
+requests ~= 2.27
+```
+
+Run the following command from your shell to make these dependencies available:
+
+```sh
+pip install -r requirements.txt
+```
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+```
+
+## Create an application
+
+If you already have a Django application setup, skip to the next step. For a new application project, run the following command:   
+
+```sh
+django-admin startproject webappexample
+```
+
+Change to the new project folder:
+
+```sh
+cd webappexample
+```
+
+## Update `settings.py` {{{ data-action=code data-code="webappexample/settings.py" }}}
+
+Open the `webappexample/settings.py` file to review the `.env` values.
+
+At the top of the file, add the `os` and `dotenv` imports.
+
+Next, beneath the `BASE_DIR` definition, add the `TEMPLATE_DIR` variable.
+
+Next, find the `TEMPLATES` variable and update the `DIRS` value to add our `TEMPLATE_DIR` string. This determines the path of the template files, which you will create in a future step.
+Keep any other content of this array the same.
+
+At the end of this file, add the code to load the Auth0 config.
+
+## Setup your application {{{ data-action=code data-code="webappexample/views.py#1:18" }}}
+
+To begin creating your application, open the `webappexample/views.py` file in your IDE.
+
+Import all the libraries your application needs.
+
+Now you can configure Authlib to handle your application's authentication with Auth0.
+
+Learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your route handlers {{{ data-action=code data-code="webappexample/views.py#21:57" }}}
+
+In this example, you will add four routes for your application: the login, callback, logout, and index routes.
+
+- `login` - When visitors to your app visit the `/login` route, they will reach Auth0 to begin the authentication flow.
+- `callback` - After your users finish logging in with Auth0, they will return to your application at the `/callback` route. This route saves the session for the user and bypasses the need for them to login again when they return.
+- `logout` - +The `/logout` route signs users out from your application. This route clears the user session in your app and redirects to the Auth0 logout endpoint to ensure the session is no longer saved. Then, the application redirects the user to your home route.
+- `index` - The home route will render an authenticated user's details or allow visitors to sign in.
+
+## Register your routes {{{ data-action=code data-code="webappexample/urls.py" }}}
+ 
+Replace the contents of your `webappexample/urls.py` file with the code on the right to connect to these new routes.
+
+This will route the `/login`, `/callback`, `/logout` and `/` routes to the correct handlers.
+
+## Add templates {{{ data-action=code data-code="webappexample/templates/index.html" }}}
+
+Next, you will create a template file used in the home page route.
+
+Create a new sub-directory within the `webappexample` folder named `templates`, and create a `index.html` file.
+
+The `index.html` file will contain template code to display the user's info if logged in or present them with a login button if logged out. 
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 manage.py migrate
+python3 manage.py runserver 3000
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
+
+::::checkpoint
+:::checkpoint-default
+Visit [http://localhost:3000](http://localhost:3000) to verify. You should find a login button routing to Auth0 for login, then back to your application to see your profile information.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify any errors in the console.
+* Verify the domain and Client ID imported correctly.
+* Verify your tenant configuration.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/fr-ca/articles/quickstart/webapp/express/01-login.md b/fr-ca/articles/quickstart/webapp/express/01-login.md
new file mode 100644
index 0000000000..931a1bc97c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/01-login.md
@@ -0,0 +1,117 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login, logout, and profile to a Node.js Express application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - user profile
+  - logout
+  - nodejs
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+
+
+## Configure Auth0
+
+You will need to register your application with Auth0 in order to start authenticating users. Go to the [Applications](${manage_url}/#/applications) screen in the Auth0 dashboard, create a new **Regular Web Application**, and follow the steps below.
+
+### 1. Configure Callback URL
+
+A callback URL is an application route where Auth0 redirects users after they have authenticated. This URL must be registered with Auth0 or else users will be unable to log in to the application and will get a "Callback URL mismatch" error.
+
+The callback URL for the application created in this quickstart is `http://localhost:3000/callback`. Paste that in the **Allowed Callback URLs** field for the application you just created.
+
+### 2. Configure Logout URL
+
+A logout URL is an application route that Auth0 can return users to after logging out. This URL must be registered with Auth0 or else users will be unable to log out of the application and will get a "misconfiguration" error.
+
+The logout URL for the application created in this quickstart is `http://localhost:3000`. Paste that in the **Allowed Logout URLs** field for the application you just created, then scroll down and click **Save Changes**.
+
+### 3. Get Your Application Keys
+
+Finally, copy the following fields for your application for use in step 7:
+
+* **Domain**
+* **Client ID**
+
+## Integrate Auth0
+### 4. Install Dependencies
+Your application will need the [`express-openid-connect`](https://github.com/auth0/express-openid-connect) package which is an Auth0-maintained OIDC-compliant library for Express.
+
+```sh
+npm install express express-openid-connect --save
+```
+
+### 5. Configure Router
+The Express OpenID Connect library provides the `auth` router in order to attach authentication routes to your application. You will need to configure the router with the following configuration keys:
+
+- `authRequired` - Controls whether authentication is required for all routes
+- `auth0Logout` - Uses Auth0 logout feature
+- `baseURL` - The URL where the application is served
+- `secret` - A long, random string used to encrypt the session cookie
+- `issuerBaseURL`  - The Domain as a secure URL found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+- `clientID` - The Client ID found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+Here is an example configuration using this router:
+
+```js
+const { auth } = require('express-openid-connect');
+
+const config = {
+  authRequired: false,
+  auth0Logout: true,
+  baseURL: 'http://localhost:3000',
+  clientID: '${account.clientId}',
+  issuerBaseURL: 'https://${account.namespace}',
+  secret: 'LONG_RANDOM_STRING'
+};
+
+// auth router attaches /login, /logout, and /callback routes to the baseURL
+app.use(auth(config));
+
+// req.isAuthenticated is provided from the auth router
+app.get('/', (req, res) => {
+  res.send(req.oidc.isAuthenticated() ? 'Logged in' : 'Logged out')
+});
+```
+
+For additional configuration options visit the [API documentation](https://auth0.github.io/express-openid-connect).
+
+:::note
+You can generate a suitable string for `LONG_RANDOM_STRING` using `openssl rand -hex 32` on the command line.
+:::
+
+## Login
+A user can now log into your application by visiting the `/login` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/login`](http://localhost:3000/login).
+
+## Display User Profile
+To display the user's profile, your application should provide a protected route.
+
+Add the `requiresAuth` middleware for routes that require authentication.  Any route using this middleware will check for a valid user session and, if one does not exist, it will redirect the user to log in.
+
+```js
+const { requiresAuth } = require('express-openid-connect');
+
+app.get('/profile', requiresAuth(), (req, res) => {
+  res.send(JSON.stringify(req.oidc.user));
+});
+```
+
+## Logout
+A user can log out of your application by visiting the `/logout` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/logout`](http://localhost:3000/logout).
+
+:::note
+For a deep dive into implementing user authentication in Express, visit the [Complete Guide to Node.js User Authentication with Auth0](https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/). This guide provides you with additional details, such as creating a signup button, protecting routes, and making secure calls to an API. 
+:::
+
+## What's next?
+We put together a few examples of how to use [Express OpenID Connect](https://github.com/auth0/express-openid-connect) in more advanced use cases:
+
+* [Route Customization](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#3-route-customization)
+* [Obtaining access tokens for external APIs](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#4-obtaining-access-tokens-to-call-external-apis)
+* [Require auth for specific routes](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#2-require-authentication-for-specific-routes)
diff --git a/fr-ca/articles/quickstart/webapp/express/download.md b/fr-ca/articles/quickstart/webapp/express/download.md
new file mode 100644
index 0000000000..306c9694cd
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+
+```bash
+npm install
+npm start
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/express/files/server.md b/fr-ca/articles/quickstart/webapp/express/files/server.md
new file mode 100644
index 0000000000..5c890e082f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/files/server.md
@@ -0,0 +1,41 @@
+---
+name: server.js
+language: javascript
+---
+
+
+
+```javascript
+const express = require('express');
+const { auth, requiresAuth } = require('express-openid-connect');
+const app = express();
+
+const config = {
+  authRequired: false,
+  auth0Logout: true,
+  baseURL: 'http://localhost:3000',
+  clientID: '${account.clientId}',
+  issuerBaseURL: 'https://${account.namespace}',
+  secret: 'LONG_RANDOM_STRING'
+};
+
+// The `auth` router attaches /login, /logout
+// and /callback routes to the baseURL
+app.use(auth(config));
+
+// req.oidc.isAuthenticated is provided from the auth router
+app.get('/', (req, res) => {
+  res.send(
+    req.oidc.isAuthenticated() ? 'Logged in' : 'Logged out'
+  )
+});
+
+// The /profile route will show the user profile as JSON
+app.get('/profile', requiresAuth(), (req, res) => {
+  res.send(JSON.stringify(req.oidc.user, null, 2));
+});
+
+app.listen(3000, function() {
+  console.log('Listening on http://localhost:3000');
+});
+```
diff --git a/fr-ca/articles/quickstart/webapp/express/index.yml b/fr-ca/articles/quickstart/webapp/express/index.yml
new file mode 100644
index 0000000000..9c819b80d0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/index.yml
@@ -0,0 +1,33 @@
+title: Express
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/node.png
+logo: javascript
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+alias:
+  - node
+  - express
+seo_alias: express
+logo_name: nodejs
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+github:
+  org: auth0-samples
+  repo: auth0-express-webapp-sample
+  branch: master
+sdk:
+  name: express-openid-connect
+  url: https://github.com/auth0/express-openid-connect
+  logo: javascript
+requirements:
+  - NodeJS 10.13+
+  - Express 4.17+
diff --git a/fr-ca/articles/quickstart/webapp/express/interactive.md b/fr-ca/articles/quickstart/webapp/express/interactive.md
new file mode 100644
index 0000000000..ea056cdc19
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,97 @@
+---
+title: Add Login to your Express App
+description: "Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add user login, logout, and profile to a Node.js Express application using the Express OpenID Connect SDK."
+interactive: true
+files:
+- files/server
+github:
+  path: 01-Login
+---
+
+
+
+# Add Login to Your Express Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add user login, logout, and profile to a Node.js Express application using the Express OpenID Connect SDK.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/callback.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/logout.
+:::
+
+## Install the Express OpenID Connect SDK {{{ data-action=code data-code="server.js#3:10" }}}
+
+Your application will need the [`express-openid-connect`](https://github.com/auth0/express-openid-connect) package which is an Auth0-maintained OIDC-compliant SDK for Express.
+
+Install the Express OpenID Connect SDK by running the following commands in your terminal:
+
+```bash
+cd 
+npm install express-openid-connect
+```
+
+### Configure Router
+The Express OpenID Connect library provides the `auth` router in order to attach authentication routes to your application. You will need to configure the router with the following configuration keys:
+
+- `authRequired` - Controls whether authentication is required for all routes
+- `auth0Logout` - Uses Auth0 logout feature
+- `baseURL` - The URL where the application is served
+- `secret` - A long, random string
+- `issuerBaseURL`  - The Domain as a secure URL found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+- `clientID` - The Client ID found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+For additional configuration options visit the [API documentation](https://auth0.github.io/express-openid-connect).
+
+:::note
+You can generate a suitable string for `LONG_RANDOM_STRING` using `openssl rand -hex 32` on the command line.
+:::
+
+::::checkpoint
+:::checkpoint-default
+A user can now log into your application by visiting the `/login` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/login`](http://localhost:3000/login).
+:::
+:::checkpoint-failure
+Sorry about that. You should check the error details on the Auth0 login page to make sure you have entered the callback URL correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Display User Profile {{{ data-action=code data-code="server.js#29:32" }}}
+To display the user's profile, your application should provide a protected route.
+
+Add the `requiresAuth` middleware for routes that require authentication.  Any route using this middleware will check for a valid user session and, if one does not exist, it will redirect the user to log in.
+
+::::checkpoint
+:::checkpoint-default
+A user can log out of your application by visiting the `/logout` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/logout`](http://localhost:3000/logout).
+:::
+:::checkpoint-failure
+Sorry about that. You should check that you configured the logout URL correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/fr-ca/articles/quickstart/webapp/golang/01-login.md b/fr-ca/articles/quickstart/webapp/golang/01-login.md
new file mode 100644
index 0000000000..b2600c857b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/01-login.md
@@ -0,0 +1,500 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Go web application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - golang
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Go', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Configure Go to Use Auth0
+
+### Download dependencies
+
+Start by adding a `go.mod` file to list all the dependencies to be used.
+
+```text
+// go.mod
+
+module 01-Login
+
+go 1.21
+
+require (
+	github.com/coreos/go-oidc/v3 v3.8.0
+	github.com/gin-contrib/sessions v0.0.5
+	github.com/gin-gonic/gin v1.9.1
+	github.com/joho/godotenv v1.5.1
+	golang.org/x/oauth2 v0.15.0
+)
+```
+
+We can now make the dependencies available for us by running the following shell command:
+
+```shell
+go mod download
+```
+
+::: note
+This example uses `gin` for routing, but you can use whichever router you want.
+:::
+
+
+### Configure your application
+
+Create a `.env` file within the root of your project directory to store the app configuration, and fill in the 
+environment variables:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# The Callback URL of our application.
+AUTH0_CALLBACK_URL='http://localhost:3000/callback'
+```
+
+### Configure OAuth2 and OpenID Connect packages
+
+Create a file called `auth.go` in the `platform/authenticator` folder. In this package you'll create a method to 
+configure and return [OAuth2](https://godoc.org/golang.org/x/oauth2) and 
+[oidc](https://godoc.org/github.com/coreos/go-oidc) clients, and another one to verify an ID Token.
+
+```go
+// platform/authenticator/auth.go
+
+package authenticator
+
+import (
+	"context"
+	"errors"
+	"os"
+
+	"github.com/coreos/go-oidc/v3/oidc"
+	"golang.org/x/oauth2"
+)
+
+// Authenticator is used to authenticate our users.
+type Authenticator struct {
+	*oidc.Provider
+	oauth2.Config
+}
+
+// New instantiates the *Authenticator.
+func New() (*Authenticator, error) {
+	provider, err := oidc.NewProvider(
+		context.Background(),
+		"https://"+os.Getenv("AUTH0_DOMAIN")+"/",
+	)
+	if err != nil {
+		return nil, err
+	}
+
+	conf := oauth2.Config{
+		ClientID:     os.Getenv("AUTH0_CLIENT_ID"),
+		ClientSecret: os.Getenv("AUTH0_CLIENT_SECRET"),
+		RedirectURL:  os.Getenv("AUTH0_CALLBACK_URL"),
+		Endpoint:     provider.Endpoint(),
+		Scopes:       []string{oidc.ScopeOpenID, "profile"},
+	}
+
+	return &Authenticator{
+		Provider: provider,
+		Config:   conf,
+	}, nil
+}
+
+// VerifyIDToken verifies that an *oauth2.Token is a valid *oidc.IDToken.
+func (a *Authenticator) VerifyIDToken(ctx context.Context, token *oauth2.Token) (*oidc.IDToken, error) {
+	rawIDToken, ok := token.Extra("id_token").(string)
+	if !ok {
+		return nil, errors.New("no id_token field in oauth2 token")
+	}
+
+	oidcConfig := &oidc.Config{
+		ClientID: a.ClientID,
+	}
+
+	return a.Verifier(oidcConfig).Verify(ctx, rawIDToken)
+}
+```
+
+### Setting up your application routes
+
+Create a file called `router.go` in the `platform/router` folder. In this package you'll create a method to configure
+and return our routes using [github.com/gin-gonic/gin](https://github.com/gin-gonic/gin). You will be passing an
+instance of `Authenticator` to the method, so it can be used within the `login` and `callback` handlers.
+
+```go
+// platform/router/router.go
+
+package router
+
+import (
+	"encoding/gob"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-contrib/sessions/cookie"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/middleware"
+	"01-Login/web/app/callback"
+	"01-Login/web/app/login"
+	"01-Login/web/app/logout"
+	"01-Login/web/app/user"
+)
+
+// New registers the routes and returns the router.
+func New(auth *authenticator.Authenticator) *gin.Engine {
+	router := gin.Default()
+
+	// To store custom types in our cookies,
+	// we must first register them using gob.Register
+	gob.Register(map[string]interface{}{})
+
+	store := cookie.NewStore([]byte("secret"))
+	router.Use(sessions.Sessions("auth-session", store))
+
+	router.Static("/public", "web/static")
+	router.LoadHTMLGlob("web/template/*")
+
+	router.GET("/", func(ctx *gin.Context) {
+		ctx.HTML(http.StatusOK, "home.html", nil)
+	})
+	router.GET("/login", login.Handler(auth))
+	router.GET("/callback", callback.Handler(auth))
+	router.GET("/user", user.Handler)
+	router.GET("/logout", logout.Handler)
+
+	return router
+}
+```
+
+::: note
+The router uses the [github.com/gin-contrib/sessions](https://github.com/gin-contrib/sessions) middleware to manage 
+our cookie based sessions.
+:::
+
+### Serving your application
+
+Next, let's create our application's entry point `main.go` and wire everything up together:
+
+```go
+// main.go
+
+package main
+
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/router"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Failed to load the env vars: %v", err)
+	}
+
+	auth, err := authenticator.New()
+	if err != nil {
+		log.Fatalf("Failed to initialize the authenticator: %v", err)
+	}
+
+	rtr := router.New(auth)
+
+	log.Print("Server listening on http://localhost:3000/")
+	if err := http.ListenAndServe("0.0.0.0:3000", rtr); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+```
+
+## Logging In
+
+Create a file called `login.go` in the `web/app/login` folder, and add a `Handler` function to handle the `/login`
+route.
+
+```go
+// web/app/login/login.go
+
+package login
+
+import (
+	"crypto/rand"
+	"encoding/base64"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our login.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		state, err := generateRandomState()
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Save the state inside the session.
+		session := sessions.Default(ctx)
+		session.Set("state", state)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		ctx.Redirect(http.StatusTemporaryRedirect, auth.AuthCodeURL(state))
+	}
+}
+
+func generateRandomState() (string, error) {
+	b := make([]byte, 32)
+	_, err := rand.Read(b)
+	if err != nil {
+		return "", err
+	}
+
+	state := base64.StdEncoding.EncodeToString(b)
+
+	return state, nil
+}
+```
+
+Add a link to `/login` route in the `home.html` template.
+
+```html
+
+
+

+    
Auth0 Example

+    
Zero friction identity infrastructure, built for developers

+    SignIn
+

+```
+
+## Handling Authentication Callback
+
+Once users have authenticated using Auth0's Universal Login Page, they'll return to the app at the `/callback`
+route that will be handled in the following `Handler` function:
+
+```go
+// web/app/callback/callback.go
+
+package callback
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our callback.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		session := sessions.Default(ctx)
+		if ctx.Query("state") != session.Get("state") {
+			ctx.String(http.StatusBadRequest, "Invalid state parameter.")
+			return
+		}
+
+		// Exchange an authorization code for a token.
+		token, err := auth.Exchange(ctx.Request.Context(), ctx.Query("code"))
+		if err != nil {
+			ctx.String(http.StatusUnauthorized, "Failed to exchange an authorization code for a token.")
+			return
+		}
+
+		idToken, err := auth.VerifyIDToken(ctx.Request.Context(), token)
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, "Failed to verify ID Token.")
+			return
+		}
+
+		var profile map[string]interface{}
+		if err := idToken.Claims(&profile); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		session.Set("access_token", token.AccessToken)
+		session.Set("profile", profile)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Redirect to logged in page.
+		ctx.Redirect(http.StatusTemporaryRedirect, "/user")
+	}
+}
+```
+
+## Displaying User Information
+
+You can access the user information via the `profile` you stored in the session previously.
+
+```go
+// web/app/user/user.go
+
+package user
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logged-in user page.
+func Handler(ctx *gin.Context) {
+	session := sessions.Default(ctx)
+	profile := session.Get("profile")
+
+	ctx.HTML(http.StatusOK, "user.html", profile)
+}
+```
+
+```html
+
+
+

+    
+    
Welcome {{.nickname}}

+

+```
+
+For information about the userinfo hash, see [User Profile](/users/concepts/overview-user-profile).
+
+## Logging Out
+
+To log the user out, clear the data from the session and redirect the user to the Auth0 logout endpoint. You can find
+more information about this in the [logout documentation](/logout).
+
+Create a file called `logout.go` in the folder `web/app/logout/logout.go`, and add the function `Handler` to redirect
+the user to Auth0's logout endpoint.
+
+```go
+// web/app/logout/logout.go
+
+package logout
+
+import (
+	"net/http"
+	"net/url"
+	"os"
+
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logout.
+func Handler(ctx *gin.Context) {
+	logoutUrl, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/v2/logout")
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	scheme := "http"
+	if ctx.Request.TLS != nil {
+		scheme = "https"
+	}
+
+	returnTo, err := url.Parse(scheme + "://" + ctx.Request.Host)
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	parameters := url.Values{}
+	parameters.Add("returnTo", returnTo.String())
+	parameters.Add("client_id", os.Getenv("AUTH0_CLIENT_ID"))
+	logoutUrl.RawQuery = parameters.Encode()
+
+	ctx.Redirect(http.StatusTemporaryRedirect, logoutUrl.String())
+}
+```
+
+::: note
+The redirect URL needs to be in the list of Allowed Logout URLs in the settings section of the application, For more information, see [Redirect Users After Logout](/logout/guides/redirect-users-after-logout).
+:::
+
+Create a file called `user.js` in the folder `web/static/js`, and add the code to remove the cookie from a logged-in
+user.
+
+```js
+$(document).ready(function () {
+    $('.btn-logout').click(function (e) {
+        Cookies.remove('auth-session');
+    });
+});
+```
+
+::: note
+This sample is using [js.cookie](https://github.com/js-cookie/js-cookie/tree/latest#readme) for cookie handling. 
+You need to add the `js.cookie.js` file to the `web/static/js` folder to use it.
+:::
+
+## Optional Steps
+
+### Checking if the user is authenticated
+
+Create a middleware that will check if the user is authenticated or not based on the `profile` session key:
+
+```go
+// platform/middleware/isAuthenticated.go
+
+package middleware
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// IsAuthenticated is a middleware that checks if
+// the user has already been authenticated previously.
+func IsAuthenticated(ctx *gin.Context) {
+	if sessions.Default(ctx).Get("profile") == nil {
+		ctx.Redirect(http.StatusSeeOther, "/")
+	} else {
+		ctx.Next()
+	}
+}
+```
+
+Finally, set up this middleware for any route that needs authentication by adding it to the router.
+
+```go
+// platform/router/router.go
+
+router.GET("/user", middleware.IsAuthenticated, user.Handler)
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/download.md b/fr-ca/articles/quickstart/webapp/golang/download.md
new file mode 100644
index 0000000000..fe4094c085
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Go](https://golang.org/dl/) is installed and execute the following commands in the sample's directory:
+
+```bash
+go mod vendor
+go run main.go
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/auth.md b/fr-ca/articles/quickstart/webapp/golang/files/auth.md
new file mode 100644
index 0000000000..023e58723d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/auth.md
@@ -0,0 +1,63 @@
+---
+name: auth.go
+language: go
+---
+
+```go
+// Save this file in ./platform/authenticator/auth.go
+
+package authenticator
+
+import (
+	"context"
+	"errors"
+	"os"
+
+	"github.com/coreos/go-oidc/v3/oidc"
+	"golang.org/x/oauth2"
+)
+
+// Authenticator is used to authenticate our users.
+type Authenticator struct {
+	*oidc.Provider
+	oauth2.Config
+}
+
+// New instantiates the *Authenticator.
+func New() (*Authenticator, error) {
+	provider, err := oidc.NewProvider(
+		context.Background(),
+		"https://"+os.Getenv("AUTH0_DOMAIN")+"/",
+	)
+	if err != nil {
+		return nil, err
+	}
+
+	conf := oauth2.Config{
+		ClientID:     os.Getenv("AUTH0_CLIENT_ID"),
+		ClientSecret: os.Getenv("AUTH0_CLIENT_SECRET"),
+		RedirectURL:  os.Getenv("AUTH0_CALLBACK_URL"),
+		Endpoint:     provider.Endpoint(),
+		Scopes:       []string{oidc.ScopeOpenID, "profile"},
+	}
+
+	return &Authenticator{
+		Provider: provider,
+		Config:   conf,
+	}, nil
+}
+
+// VerifyIDToken verifies that an *oauth2.Token is a valid *oidc.IDToken.
+func (a *Authenticator) VerifyIDToken(ctx context.Context, token *oauth2.Token) (*oidc.IDToken, error) {
+	rawIDToken, ok := token.Extra("id_token").(string)
+	if !ok {
+		return nil, errors.New("no id_token field in oauth2 token")
+	}
+
+	oidcConfig := &oidc.Config{
+		ClientID: a.ClientID,
+	}
+
+	return a.Verifier(oidcConfig).Verify(ctx, rawIDToken)
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/callback.md b/fr-ca/articles/quickstart/webapp/golang/files/callback.md
new file mode 100644
index 0000000000..8d8e0b2795
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/callback.md
@@ -0,0 +1,59 @@
+---
+name: callback.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/callback/callback.go
+
+package callback
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our callback.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		session := sessions.Default(ctx)
+		if ctx.Query("state") != session.Get("state") {
+			ctx.String(http.StatusBadRequest, "Invalid state parameter.")
+			return
+		}
+
+		// Exchange an authorization code for a token.
+		token, err := auth.Exchange(ctx.Request.Context(), ctx.Query("code"))
+		if err != nil {
+			ctx.String(http.StatusUnauthorized, "Failed to exchange an authorization code for a token.")
+			return
+		}
+
+		idToken, err := auth.VerifyIDToken(ctx.Request.Context(), token)
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, "Failed to verify ID Token.")
+			return
+		}
+
+		var profile map[string]interface{}
+		if err := idToken.Claims(&profile); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		session.Set("access_token", token.AccessToken)
+		session.Set("profile", profile)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Redirect to logged in page.
+		ctx.Redirect(http.StatusTemporaryRedirect, "/user")
+	}
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/env.md b/fr-ca/articles/quickstart/webapp/golang/files/env.md
new file mode 100644
index 0000000000..a7ef95a380
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/env.md
@@ -0,0 +1,21 @@
+---
+name: .env
+language: shell
+---
+
+```shell
+# Save this file in ./.env
+
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# The Callback URL of our application.
+AUTH0_CALLBACK_URL='http://localhost:3000/callback'
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/go-mod.md b/fr-ca/articles/quickstart/webapp/golang/files/go-mod.md
new file mode 100644
index 0000000000..636aa7c45f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/go-mod.md
@@ -0,0 +1,20 @@
+---
+name: go.mod
+language: go-mod
+---
+
+```go-mod
+// Save this file in ./go.mod
+
+module 01-Login
+
+go 1.21
+
+require (
+	github.com/coreos/go-oidc/v3 v3.8.0
+	github.com/gin-contrib/sessions v0.0.5
+	github.com/gin-gonic/gin v1.9.1
+	github.com/joho/godotenv v1.5.1
+	golang.org/x/oauth2 v0.15.0
+)
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/isAuthenticated.md b/fr-ca/articles/quickstart/webapp/golang/files/isAuthenticated.md
new file mode 100644
index 0000000000..810973aae3
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/isAuthenticated.md
@@ -0,0 +1,27 @@
+---
+name: isAuthenticated.go
+language: go
+---
+
+```go
+// Save this file in ./platform/middleware/isAuthenticated.go
+
+package middleware
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// IsAuthenticated is a middleware that checks if
+// the user has already been authenticated previously.
+func IsAuthenticated(ctx *gin.Context) {
+	if sessions.Default(ctx).Get("profile") == nil {
+		ctx.Redirect(http.StatusSeeOther, "/")
+	} else {
+		ctx.Next()
+	}
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/login.md b/fr-ca/articles/quickstart/webapp/golang/files/login.md
new file mode 100644
index 0000000000..06dee8ad5e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/login.md
@@ -0,0 +1,54 @@
+---
+name: login.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/login/login.go
+
+package login
+
+import (
+	"crypto/rand"
+	"encoding/base64"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our login.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		state, err := generateRandomState()
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Save the state inside the session.
+		session := sessions.Default(ctx)
+		session.Set("state", state)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		ctx.Redirect(http.StatusTemporaryRedirect, auth.AuthCodeURL(state))
+	}
+}
+
+func generateRandomState() (string, error) {
+	b := make([]byte, 32)
+	_, err := rand.Read(b)
+	if err != nil {
+		return "", err
+	}
+
+	state := base64.StdEncoding.EncodeToString(b)
+
+	return state, nil
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/logout.md b/fr-ca/articles/quickstart/webapp/golang/files/logout.md
new file mode 100644
index 0000000000..09d04f27ee
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/logout/logout.go
+
+package logout
+
+import (
+	"net/http"
+	"net/url"
+	"os"
+
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logout.
+func Handler(ctx *gin.Context) {
+	logoutUrl, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/v2/logout")
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	scheme := "http"
+	if ctx.Request.TLS != nil {
+		scheme = "https"
+	}
+
+	returnTo, err := url.Parse(scheme + "://" + ctx.Request.Host)
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	parameters := url.Values{}
+	parameters.Add("returnTo", returnTo.String())
+	parameters.Add("client_id", os.Getenv("AUTH0_CLIENT_ID"))
+	logoutUrl.RawQuery = parameters.Encode()
+
+	ctx.Redirect(http.StatusTemporaryRedirect, logoutUrl.String())
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/main.md b/fr-ca/articles/quickstart/webapp/golang/files/main.md
new file mode 100644
index 0000000000..ecce4e6b5d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/main.md
@@ -0,0 +1,38 @@
+---
+name: main.go
+language: go
+---
+
+```go
+// Save this file in ./main.go
+
+package main
+
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/router"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Failed to load the env vars: %v", err)
+	}
+
+	auth, err := authenticator.New()
+	if err != nil {
+		log.Fatalf("Failed to initialize the authenticator: %v", err)
+	}
+
+	rtr := router.New(auth)
+
+	log.Print("Server listening on http://localhost:3000/")
+	if err := http.ListenAndServe("0.0.0.0:3000", rtr); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/router.md b/fr-ca/articles/quickstart/webapp/golang/files/router.md
new file mode 100644
index 0000000000..2da2fa8e5b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/router.md
@@ -0,0 +1,51 @@
+---
+name: router.go
+language: go
+---
+
+```go
+// Save this file in ./platform/router/router.go
+
+package router
+
+import (
+	"encoding/gob"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-contrib/sessions/cookie"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/middleware"
+	"01-Login/web/app/callback"
+	"01-Login/web/app/login"
+	"01-Login/web/app/logout"
+	"01-Login/web/app/user"
+)
+
+// New registers the routes and returns the router.
+func New(auth *authenticator.Authenticator) *gin.Engine {
+	router := gin.Default()
+
+	// To store custom types in our cookies,
+	// we must first register them using gob.Register
+	gob.Register(map[string]interface{}{})
+
+	store := cookie.NewStore([]byte("secret"))
+	router.Use(sessions.Sessions("auth-session", store))
+
+	router.Static("/public", "web/static")
+	router.LoadHTMLGlob("web/template/*")
+
+	router.GET("/", func(ctx *gin.Context) {
+		ctx.HTML(http.StatusOK, "home.html", nil)
+	})
+	router.GET("/login", login.Handler(auth))
+	router.GET("/callback", callback.Handler(auth))
+	router.GET("/user", user.Handler)
+	router.GET("/logout", logout.Handler)
+
+	return router
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/files/user.md b/fr-ca/articles/quickstart/webapp/golang/files/user.md
new file mode 100644
index 0000000000..5bae0dcfa2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/files/user.md
@@ -0,0 +1,25 @@
+---
+name: user.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/user/user.go
+
+package user
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logged-in user page.
+func Handler(ctx *gin.Context) {
+	session := sessions.Default(ctx)
+	profile := session.Get("profile")
+
+	ctx.HTML(http.StatusOK, "user.html", profile)
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/golang/index.yml b/fr-ca/articles/quickstart/webapp/golang/index.yml
new file mode 100644
index 0000000000..38a4052a43
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/index.yml
@@ -0,0 +1,44 @@
+title: Go
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/golang.png
+logo: golang
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Sergiu Ghitea
+  email: sergiu.ghitea@auth0.com
+  community: false
+snippets:
+  dependencies: server-platforms/golang/dependencies
+  setup: server-platforms/golang/setup
+  use: server-platforms/golang/use
+seo_alias: golang
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-golang-web-app
+  branch: master
+requirements:
+  - Go 1.21+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/fr-ca/articles/quickstart/webapp/golang/interactive.md b/fr-ca/articles/quickstart/webapp/golang/interactive.md
new file mode 100644
index 0000000000..28a401da07
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,183 @@
+---
+title: Add Login to your Go web application
+description: This tutorial demonstrates how to add user login to a Go web application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - golang
+github:
+  path: 01-Login
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/auth
+  - files/callback
+  - files/env
+  - files/go-mod
+  - files/isAuthenticated
+  - files/login
+  - files/logout
+  - files/main
+  - files/router
+  - files/user
+---
+
+# Add Login to Your Go Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Go web application.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies {{{ data-action=code data-code="go.mod" }}}
+
+Create a `go.mod` file to list all the dependencies in your application. 
+
+To integrate Auth0 in a Go application, add the`coreos/go-oidc/v3` and `x/oauth2` packages. 
+
+In addition to the OIDC and OAuth2 packages, add`joho/godotenv`, `gin-gonic/gin` and `gin-contrib/sessions`.
+
+::: note
+This example uses `gin` for routing, but you can use whichever router you want.
+:::
+
+Save the `go.mod` file with the necessary dependencies and install them using the following command in your terminal:
+
+```shell
+go mod download
+```
+
+## Configure the environment variables {{{ data-action=code data-code=".env" }}}
+You must set the following environment variables in `.env` within the root of your project directory:
+
+- **AUTH0_DOMAIN**: The domain of your Auth0 tenant. Find your Auth0 Domain in the Auth0 Dashboard under your Application's Settings in the Domain field. For [custom domains](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- **AUTH0_CLIENT_ID**: The ID of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- **AUTH0_CLIENT_SECRET**: The Secret of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client Secret field.
+- **AUTH0_CALLBACK_URL**: The URL used by Auth0 to redirect the user after successful authentication.
+
+## Configure OAuth2 and OpenID Connect packages {{{ data-action=code data-code="auth.go" }}}
+
+Next, configure the OAuth2 and OpenID Connect packages.
+
+Create a file called `auth.go` in the `platform/authenticator` folder. In this package, create a method to 
+configure and return [OAuth2](https://godoc.org/golang.org/x/oauth2) and 
+[OIDC](https://godoc.org/github.com/coreos/go-oidc) clients, and another one to verify an ID Token.
+
+## Set up your application routes {{{ data-action=code data-code="router.go" }}}
+
+Create a file called `router.go` in the `platform/router` folder. In this package, create a method to configure
+and return our routes using [github.com/gin-gonic/gin](https://github.com/gin-gonic/gin). You will be passing an
+instance of `Authenticator` to the method, for use with the `login` and `callback` handlers.
+
+::: note
+The router uses the [github.com/gin-contrib/sessions](https://github.com/gin-contrib/sessions) middleware to manage our cookie-based sessions.
+:::
+
+## Add login to your application {{{ data-action=code data-code="login.go" }}}
+
+For the user to authenticate themselves, we need to create a handler function to handle the `/login` route.
+
+Create a file called `login.go` in the `web/app/login` folder, and add a `Handler` function. Upon executing the handler, the user will be redirected to Auth0 where they can enter their credentials.
+
+To call the `/login` route, add a link to `/login` in the `home.html` template located in the `web/template` directory.
+
+```html
+
+
+

+    
Auth0 Example

+    
Zero friction identity infrastructure, built for developers

+    SignIn
+

+```
+
+## Handle authentication callback {{{ data-action=code data-code="callback.go" }}}
+
+Once users have authenticated using Auth0's Universal Login Page, they will return to the app at the `/callback` route.
+
+Create a file called `callback.go` in the `web/app/callback` folder, and add a `Handler` function.
+
+This handler will take the `code` query string, provided by Auth0, and exchange it for an ID token and an access token.
+
+If the ID token is valid, it will store the profile information and access token in the session. The profile information is based on the claims contained in the ID token. Session storage allows the application to access that information as needed.
+
+## Display user profile information {{{ data-action=code data-code="user.go" }}}
+
+Now that your users can log in, you will likely want to be able to retrieve and use the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. 
+
+You can access that [profile information](/users/concepts/overview-user-profile), such as their nickname or profile picture, through the `profile` that was stored in the session previously.
+
+Create a handler for the `/user` endpoint in `web/app/user/user.go` and return the corresponding HTML file. As the `profile` is being passed to `ctx.HTML()`, you can access the profile information such as `picture` and `nickname` inside that same HTML file. 
+
+An example of such an HTML file could look like the example below, but you can retrieve any [profile information](/users/concepts/overview-user-profile), including custom claims.
+
+```html
+
+
+

+    
+    
Welcome {{.nickname}}

+

+```
+
+## Add logout to your application {{{ data-action=code data-code="logout.go" }}}
+
+To log the user out, clear the data from the session and redirect the user to the Auth0 logout endpoint. You can find more information about this in the [logout documentation](/logout).
+
+Create a file called `logout.go` in the folder `web/app/logout`, and add the function `Handler` to redirect the user to Auth0's logout endpoint.
+
+::: note
+The `returnTo` URL needs to be in the list of Allowed Logout URLs in the settings section of the application, For more information, see [Redirect Users After Logout](/logout/guides/redirect-users-after-logout).
+:::
+
+Create a file called `user.js` in the folder `web/static/js`, and add the code to remove the cookie from a logged-in
+user.
+
+```js
+// Save this within ./web/static/js/user.js
+
+$(document).ready(function () {
+    $('.btn-logout').click(function (e) {
+        Cookies.remove('auth-session');
+    });
+});
+```
+
+::: note
+This sample is using [js.cookie](https://github.com/js-cookie/js-cookie/tree/latest#readme) for cookie handling. 
+You need to add the `js.cookie.js` file to the `web/static/js` folder to use it.
+:::
+
+## Protect routes {{{ data-action=code data-code="isAuthenticated.go" }}}
+
+Recommended practice dictates certain routes are accessible only to authenticated users. When unauthenticated users try accessing protected routes, your application should redirect them.
+
+In this case, you will implement middleware to hook into the HTTP request. The middleware function determines if the request should route to the endpoint handler or block the request.
+
+Create a file called `isAuthenticated.go` in `platform/middleware` and add a function that checks if the user is authenticated or not based on the `profile` session key. If the user is not authenticated, the middleware will redirect the user to the root of the application.
+
+With the middleware created, we can set it up for any route that needs authentication by adding it to the router.
+
+```go
+// This goes within ./platform/router/router.go
+
+router.GET("/user", middleware.IsAuthenticated, user.Handler)
+```
+
+## Serve your application {{{ data-action=code data-code="main.go" }}}
+
+With both the authenticator and router configured, we can wire things up using our
+application's entry point. Inside `main.go`, create an instance of the authenticator and the router, which gets passed the authenticator instance.
+
+If you are using a `.env` file, you must call `godotenv.Load()` at the very beginning of the `main()` function.
+
+Serve your application by using the following command in your terminal:
+
+```shell
+go run main.go
+```
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/01-login.md b/fr-ca/articles/quickstart/webapp/java-ee/01-login.md
new file mode 100644
index 0000000000..c788d7b41a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/01-login.md
@@ -0,0 +1,21 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Java EE web application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java ee
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Java EE', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/' }) %>
+
+<%= include('_includes/_setup') %>
+
+<%= include('_includes/_login') %>
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/_includes/_login.md b/fr-ca/articles/quickstart/webapp/java-ee/_includes/_login.md
new file mode 100644
index 0000000000..f25ae2479c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/_includes/_login.md
@@ -0,0 +1,391 @@
+## Configure Java EE Security
+
+The Java EE 8 Security API introduced the `HttpAuthenticationMechanism` interface to enable applications to obtain a user's credentials. Default implementations exist for Basic and form-based authentication, and it provides an easy way to configure a custom authentication strategy.
+
+To authenticate with Auth0, provide custom implementations of the following interfaces:
+
+- `HttpAuthenticationMechanism`: Responsible for obtaining a user's credentials and notifying the container of successful (or not) login status ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/authentication/mechanism/http/HttpAuthenticationMechanism.html)).
+- `IdentityStore`: Responsible for validating the user's credentials ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/identitystore/IdentityStore.html)).
+- `CallerPrincipal`: Represents the caller principal of the current HTTP request ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/CallerPrincipal.html)).
+- `Credential`: Represents the credential the caller will use to authenticate ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/credential/Credential.html)).
+
+First, make your Auth0 settings available to the application by creating an `@ApplicationScoped` bean to retrieve the values from the web context and make them available via getters:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java
+
+@ApplicationScoped
+public class Auth0AuthenticationConfig {
+
+    private String domain;
+    private String clientId;
+    private String clientSecret;
+    private String scope;
+
+    @PostConstruct
+    public void init() {
+        // Get authentication config values from env-entries in web.xml
+        try {
+            Context env = (Context)new InitialContext().lookup("java:comp/env");
+
+            this.domain = (String) env.lookup("auth0.domain");
+            this.clientId = (String) env.lookup("auth0.clientId");
+            this.clientSecret = (String) env.lookup("auth0.clientSecret");
+            this.scope = (String) env.lookup("auth0.scope");
+        } catch (NamingException ne) {
+            throw new IllegalArgumentException("Unable to lookup auth0 configuration properties from web.xml", ne);
+        }
+
+        if (this.domain == null || this.clientId == null || this.clientSecret == null || this.scope == null) {
+            throw new IllegalArgumentException("domain, clientId, clientSecret, and scope must be set in web.xml");
+        }
+    }
+
+    public String getDomain() {
+         return domain;
+    }
+
+    public String getClientId() {
+         return clientId;
+    }
+
+    public String getClientSecret() {
+         return clientSecret;
+    }
+
+    public String getScope() {
+        return scope;
+    }
+}
+```
+
+Next, create a custom `CallerPrincipal` that represents the caller of the current request:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtPrincipal.java
+
+public class Auth0JwtPrincipal extends CallerPrincipal {
+    private final DecodedJWT idToken;
+
+    Auth0JwtPrincipal(DecodedJWT idToken) {
+        super(idToken.getClaim("name").asString());
+        this.idToken = idToken;
+    }
+
+    public DecodedJWT getIdToken() {
+        return this.idToken;
+    }
+}
+```
+
+You can now implement a custom `Credential` that will be used to represent the user's credentials. It will hold information about the principal:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtCredential.java
+
+class Auth0JwtCredential implements Credential {
+    private Auth0JwtPrincipal auth0JwtPrincipal;
+
+    Auth0JwtCredential(String token) {
+        DecodedJWT decodedJWT = JWT.decode(token);
+        this.auth0JwtPrincipal = new Auth0JwtPrincipal(decodedJWT);
+    }
+
+    Auth0JwtPrincipal getAuth0JwtPrincipal() {
+        return auth0JwtPrincipal;
+    }
+}
+```
+
+You now have defined the classes that represent a calling principal and credential. Next, create a custom implementation of `IdentityStore`. This class will be responsible for validating the user's credentials:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtIdentityStore.java
+
+@ApplicationScoped
+public class Auth0JwtIdentityStore implements IdentityStore {
+
+    @Override
+    public CredentialValidationResult validate(final Credential credential) {
+        CredentialValidationResult result = CredentialValidationResult.NOT_VALIDATED_RESULT;
+        if (credential instanceof Auth0JwtCredential) {
+            Auth0JwtCredential auth0JwtCredential = (Auth0JwtCredential) credential;
+            result = new CredentialValidationResult(auth0JwtCredential.getAuth0JwtPrincipal());
+        }
+        return result;
+    }
+}
+```
+
+If the `credential` is an `Auth0Credential`, the calling user is authenticated and valid, so a `CredentialValidationResult` created with the credential is returned to indicate success. If it is not an `Auth0Credential`, return `CredentialValidationResult.NOT_VALIDATED_RESULT`.
+
+Before implementing the `HttpAuthenticationMechanism` interface that will use all these collaborators, create a bean that will provide a configured instance of the `AuthenticationController` from the Auth0 Java MVC SDK. The `AuthenticationController` is used to build the authorization URL where users will login, and handle the token exchange to authenticate users.
+
+* If your Auth0 Application is configured to use the **RS256 signing algorithm** (the default when creating a new Auth0 Application), you need to configure a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options.
+* If your Auth0 Application is configured to use the **HS256 signing algorithm**, there is no need to configure the `JwkProvider`.
+
+::: note
+To learn more about the available signing algorithms, refer to the [documentation](https://auth0.com/docs/tokens/concepts/signing-algorithms).
+:::
+
+The sample below shows how to configure the `AuthenticationController` for use with the **RS256 signing algorithm**:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationProvider.java
+
+@ApplicationScoped
+public class Auth0AuthenticationProvider {
+
+    @Produces
+    public AuthenticationController authenticationController(Auth0AuthenticationConfig config) {
+        JwkProvider jwkProvider = new JwkProviderBuilder(config.getDomain()).build();
+        return AuthenticationController.newBuilder(config.getDomain(), config.getClientId(), config.getClientSecret())
+                .withJwkProvider(jwkProvider)
+                .build();
+    }
+}
+```
+
+Finally, implement a custom `HttpAuthenticationMechanism`
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationMechanism.java
+
+@ApplicationScoped
+@AutoApplySession
+public class Auth0AuthenticationMechanism implements HttpAuthenticationMechanism {
+    private final AuthenticationController authenticationController;
+    private final IdentityStoreHandler identityStoreHandler;
+
+    @Inject
+    Auth0AuthenticationMechanism(AuthenticationController authenticationController, IdentityStoreHandler identityStoreHandler) {
+        this.authenticationController = authenticationController;
+        this.identityStoreHandler = identityStoreHandler;
+    }
+
+    @Override
+    public AuthenticationStatus validateRequest(HttpServletRequest httpServletRequest,
+                                                HttpServletResponse httpServletResponse,
+                                                HttpMessageContext httpMessageContext) throws AuthenticationException {
+
+        // Exchange the code for the ID token, and notify container of result.
+        if (isCallbackRequest(httpServletRequest)) {
+            try {
+                Tokens tokens = authenticationController.handle(httpServletRequest, httpServletResponse);
+                Auth0JwtCredential auth0JwtCredential = new Auth0JwtCredential(tokens.getIdToken());
+                CredentialValidationResult result = identityStoreHandler.validate(auth0JwtCredential);
+                return httpMessageContext.notifyContainerAboutLogin(result);
+            } catch (IdentityVerificationException e) {
+                return httpMessageContext.responseUnauthorized();
+            }
+        }
+        return httpMessageContext.doNothing();
+    }
+
+    private boolean isCallbackRequest(HttpServletRequest request) {
+        return request.getRequestURI().equals("/callback") && request.getParameter("code") != null;
+    }
+}
+```
+
+The class overrides the `validateRequest` method, which is called on every request to our application, and is responsible for notifying the container of the authentication status.
+
+This sample uses the [Authorization Code Flow](https://auth0.com/docs/flows/concepts/auth-code) to exchange an Authorization Code for a token during the authentication flow. If this request is to the `/callback` endpoint and contains the `code` request parameter, it does a few important things:
+
+- Calls the `handle` method of the `AuthenticationController` to exchange the Authorization Code for an ID token and an access token.
+- Uses the ID token to create a new `Auth0Credential`.
+- Calls the `validate` method of the custom `IdentityStore` implementation to obtain the validation result.
+- Notifies the application container of the login status.
+
+If the requested resource is not `/callback`, return `httpMessageContext.doNothing()` to allow the request processing to continue. You will see shortly how to use the authentication information when triggering authentication and displaying web views.
+
+Finally, note that the `@AutoApplySession` annotation has been added to allow the container to create a session for the authenticated user.
+
+## Trigger authentication
+
+To enable a user to log in, create a Servlet that will handle requests to the `/login` path:
+
+```java
+// src/main/java/com/auth0/example/web/LoginServlet.java
+
+@WebServlet(urlPatterns = "/login")
+public class LoginServlet extends HttpServlet {
+    private final Auth0AuthenticationConfig config;
+    private final AuthenticationController authenticationController;
+
+    @Inject
+    LoginServlet(Auth0AuthenticationConfig config, AuthenticationController authenticationController) {
+        this.config = config;
+        this.authenticationController = authenticationController;
+    }
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
+        // URL where the application will receive the authorization code (e.g., http://localhost:3000/callback)
+        String callbackUrl = String.format(
+                "%s://%s:%s/callback",
+                request.getScheme(),
+                request.getServerName(),
+                request.getServerPort()
+        );
+
+        // Create the authorization URL to redirect the user to, to begin the authentication flow.
+        String authURL = authenticationController.buildAuthorizeUrl(request, response, callbackUrl)
+                .withScope(config.getScope())
+                .build();
+
+        response.sendRedirect(authURL);
+    }
+}
+```
+
+The `LoginController` is responsible for redirecting the request to the proper authorization URL, where the user can authenticate with Auth0. It uses the `AuthenticationController` from the Auth0 Java MVC SDK to build the correct authorization URL, using the configuration values injected via `Auth0AuthenticationConfig`. By default, this sample requests the `"openid profile email"` scopes, to allow the application to retrieve basic profile information from the authenticated user. You can read more about these scopes in the [OpenID Connect Scopes](https://auth0.com/docs/scopes/current/oidc-scopes) documentation.
+
+Once the user has entered their credentials and authorized the requested permissions, Auth0 will issue a request to the `callbackUrl`, and include a `code` query parameter which can be exchanged for an ID token and an access token. Recall that the `Auth0HttpAuthenticationMechanism` created above handles this exchange so that it can notify the application container of authentication status. This allows the Servlet that handles requests to the `/callback` path to simply forward the request on to the originally requested resource prior to logging in, or simply redirect to the home page:
+
+```java
+// src/main/com/auth0/example/web/CallbackServlet.java
+
+@WebServlet(urlPatterns = {"/callback"})
+public class CallbackServlet extends HttpServlet {
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
+        String referer = (String) request.getSession().getAttribute("Referer");
+        String redirectTo = referer != null ? referer : "/";
+
+        response.sendRedirect(redirectTo);
+    }
+}
+```
+
+## Display user information
+
+You can use the `Auth0JwtPrincipal` to get profile information for the authenticated user. The following code sample demonstrates how to use the claims on the [ID token](https://auth0.com/docs/tokens/id-token) to set profile data as a request attribute:
+
+```java
+// src/main/java/com/auth0/example/web/HomeServlet.java
+
+@WebServlet(urlPatterns = "")
+public class HomeServlet extends HttpServlet {
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
+        Principal principal = request.getUserPrincipal();
+
+        if (principal instanceof Auth0JwtPrincipal) {
+            Auth0JwtPrincipal auth0JwtPrincipal = (Auth0JwtPrincipal) principal;
+            request.setAttribute("profile", auth0JwtPrincipal.getIdToken().getClaims());
+        }
+        request.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(request, response);
+    }
+}
+```
+
+You can then use that profile information in your view to display information about the user:
+
+```html
+
+
+
+    ">
+        
  • 
+            
    
+                
+            
    
+        
    • 
+        
+    
+        
  • 
+            
+                
+                " alt="Profile picture"/>
+            
+            
    
+                
+                
    "<%= "${profile.get('name').asString()}" %>"
    
+                Profile
+                Log out
+            
    
+        
    • 
+        
+    
+```
+
+## Handle logout
+
+To log a user out, you should clear the application session and log the user out of Auth0. This is handled in the `LogoutServlet`.
+
+First, clear the session by calling `request.getSession().invalidate()`. Then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, redirect the response to the application's logout URL:
+
+```java
+// src/main/java/com/auth0/example/web/LogoutServlet.java
+
+@WebServlet(urlPatterns = "/logout")
+public class LogoutServlet extends HttpServlet {
+    private final Auth0AuthenticationConfig config;
+
+    @Inject
+    LogoutServlet(Auth0AuthenticationConfig config) {
+        this.config = config;
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+        clearSession(request);
+        response.sendRedirect(getLogoutUrl(request));
+    }
+
+    private void clearSession(HttpServletRequest request) {
+        if (request.getSession() != null) {
+            request.getSession().invalidate();
+        }
+    }
+
+    private String getLogoutUrl(HttpServletRequest request) {
+        String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+        int port = request.getServerPort();
+        String scheme = request.getScheme();
+
+        if (("http".equals(scheme) && port != 80) ||
+                ("https".equals(scheme) && port != 443)) {
+            returnUrl += ":" + port;
+        }
+
+        returnUrl += "/";
+
+        // Build logout URL like:
+        // https://{YOUR-DOMAIN}/v2/logout?client_id={YOUR-CLIENT-ID}&returnTo=http://localhost:3000/
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                config.getDomain(),
+                config.getClientId(),
+                returnUrl
+        );
+
+        return logoutUrl;
+    }
+}
+```
+
+## Run the sample
+
+To build and run the sample, execute the `wildfly:run` Maven goal to start an embedded WildFly application server with this application deployed to it. See the [WildFly Maven Plugin](https://docs.jboss.org/wildfly/plugins/maven/latest/) documentation for more information.
+
+If you are using Linux or MacOS:
+
+```bash
+./mvnw clean wildfly:run
+```
+
+Windows:
+
+```bash
+mvnw.cmd clean wildfly:run
+```
+
+Point your browser to [http://localhost:3000](http://localhost:3000). Follow the **Log In** link to log in or sign up to your Auth0 tenant. 
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+Upon successful login, you will see the user's profile picture and a drop-down menu where the Log In link was. You can then view the user's profile page by clicking the **Profile** link. You can log out by clicking the **Logout** link in the drop-down menu.
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/_includes/_setup.md b/fr-ca/articles/quickstart/webapp/java-ee/_includes/_setup.md
new file mode 100644
index 0000000000..e3a5870230
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/_includes/_setup.md
@@ -0,0 +1,83 @@
+## Configure Java EE to use Auth0
+
+### Set up dependencies
+
+To integrate your Java EE application with Auth0, add the following dependencies:
+
+- **javax.javaee-api**: The Java EE 8 API necessary to write applications using Java EE 8. The actual implementation is provided by the application container, so it does not need to be included in the WAR file.
+- **javax.security.enterprise**: The Java EE 8 Security API that enables handling security concerns in an EE application. Like the `javax.javaee-api` dependency, the implementation is provided by the application container, so is not included in the WAR file.
+- **auth0-java-mvc-commons**: The [Auth0 Java MVC SDK](https://github.com/auth0/auth0-java-mvc-common) allows you to use Auth0 with Java for server-side MVC web applications. It generates the Authorize URL that your application needs to call in order to authenticate a user using Auth0.
+
+If you are using Maven, add these dependencies to your `pom.xml`:
+
+```xml
+
+
+
+    com.auth0
+    mvc-auth-commons
+    [1.0, 2.0)
+
+
+    javax
+    javaee-api
+    8.0.1
+    provided
+
+
+    javax.security.enterprise
+    javax.security.enterprise-api
+    1.0
+    provided
+
+```
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+providedCompile 'javax:javaee-api:8.0.1'
+providedCompile 'javax.security.enterprise:javax.security.enterprise-api:1.0'
+implementation 'com.auth0:mvc-auth-commons:1.+'
+```
+
+### Configure your Java EE application
+
+::: note
+The sample that accompanies this tutorial is written using JSP and tested with the [WildFly](https://wildfly.org/) application server. You may need to adjust some of the steps if you working with a different application container or technologies.
+:::
+
+Your Java EE application needs some information in order to authenticate users with your Auth0 application. The deployment descriptor `web.xml` file can be used to store this information, though you could store them in a different secured location. The required information is:
+
+
+```xml
+
+
+
+    auth0.domain
+    java.lang.String
+    ${account.namespace}
+
+
+    auth0.clientId
+    java.lang.String
+    ${account.clientId}
+
+
+    auth0.clientSecret
+    java.lang.String
+    YOUR_CLIENT_SECRET
+
+
+    auth0.scope
+    java.lang.String
+    openid profile email
+
+```
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [README](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md) of the library.
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/download.md b/fr-ca/articles/quickstart/webapp/java-ee/download.md
new file mode 100644
index 0000000000..e7c987fe4e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./mvnw clean wildfly:run
+# In Windows
+mvnw.cmd clean wildfly:run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-ee/index.yml b/fr-ca/articles/quickstart/webapp/java-ee/index.yml
new file mode 100644
index 0000000000..1d31b7e94a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-ee/index.yml
@@ -0,0 +1,50 @@
+title: Java EE
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.
+logo_name: java
+image: /media/platforms/java.png
+logo: java
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+alias:
+  - java
+  - java-ee
+languages:
+  - Java
+framework:
+  - Java EE
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: java ee
+articles:
+  - 01-login
+default_article: 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-java-ee-sample
+  branch: master
+sdk:
+  name: auth0-java-mvc-common
+  url: https://github.com/auth0/auth0-java-mvc-common
+  logo: java
+requirements:
+  - Java 11
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/01-login.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/01-login.md
new file mode 100644
index 0000000000..de1c68cb74
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/01-login.md
@@ -0,0 +1,311 @@
+---
+title: Login
+description: The Okta Spring Boot Starter makes it easy to add login to your Spring Boot application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java-spring-boot
+github:
+    path: mvc-login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel Using Spring WebFlux?
+This tutorial uses [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html). If you are using [Spring WebFlux](https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#spring-web-reactive), the steps to add authentication are similar, but some of the implementation details are different. Refer to the [Spring Boot WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/webflux-login) to see how to integrate Auth0 with your Spring Boot WebFlux application.
+:::
+
+<%= include('../_includes/_getting_started', { library: 'Java Spring Security', callback: 'http://localhost:3000/login/oauth2/code/okta' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/' }) %>
+
+## Configure Spring Boot Application
+
+### Add dependencies
+
+To integrate your Spring Boot application with Auth0, include the [Okta Spring Boot Starter](https://github.com/okta/okta-spring-boot/) in your application's dependencies.
+
+:::note
+This guide uses [Thymeleaf](https://www.thymeleaf.org/) and the [Spring Security integration module](https://github.com/thymeleaf/thymeleaf-extras-springsecurity) for the view layer. If you are using a different view technology, the Spring Security configuration and components remain the same.
+:::
+
+If you're using Gradle, you can include these dependencies as shown below.
+
+```groovy
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.4'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+implementation 'org.springframework.boot:spring-boot-starter-web'
+implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
+implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'
+implementation 'nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect'
+```
+
+If you are using Maven:
+
+```xml
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.5
+    
+
+
+
+    
+        com.okta
+        okta-spring-boot-starter
+        3.0.5
+    
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        org.springframework.boot
+        spring-boot-starter-oauth2-client
+    
+    
+        org.springframework.boot
+        spring-boot-starter-thymeleaf
+    
+    
+        org.thymeleaf.extras
+        thymeleaf-extras-springsecurity6
+    
+    
+        nz.net.ultraq.thymeleaf
+        thymeleaf-layout-dialect
+    
+
+```
+
+### Configure Spring Security
+
+The Okta Spring Boot Starter makes it easy to configure your application with Auth0. The sample below uses an `application.yml` file, though you can also use properties files or any of the other [supported externalization mechanisms](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config).
+
+
+```yaml
+# src/main/resources/application.yml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+
+# The sample and instructions above for the callback and logout URL configuration use port 3000.
+# If you wish to use a different port, change this and be sure your callback and logout URLs are
+# configured with the correct port.
+server:
+  port: 3000
+```
+
+## Add Login to Your Application
+
+To enable user login with Auth0, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), and add the `@Configuration` annotation.
+
+```java
+package com.auth0.example;
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults());
+        return http.build();
+    }
+}
+```
+
+:::note
+You can further configure the [HttpSecurity](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html) instance to require authentication on all or certain paths. For example, to require authentication on all paths except the home page:
+
+```java
+ http
+    .authorizeHttpRequests(authorize -> authorize
+        .requestMatchers("/").permitAll()
+        .anyRequest().authenticated()
+    );
+```
+:::
+
+The Okta Spring Boot Starter will use the client configuration you defined earlier to handle login when a user visits the `/oauth2/authorization/okta` path of your application. You can use this to create a login link in your application.
+
+```html
+
+
+    
+        
    
+            Log In
+        
    
+        
    
+            
    You are logged in!
    
+        
    
+    
+
+```
+
+Be sure to create or update a controller to render your view.
+
+```java
+package com.auth0.example;
+
+import org.springframework.security.core.annotation.AuthenticationPrincipal;
+import org.springframework.security.oauth2.core.oidc.user.OidcUser;
+import org.springframework.stereotype.Controller;
+import org.springframework.ui.Model;
+import org.springframework.web.bind.annotation.GetMapping;
+
+/**
+ * Controller for the home page.
+ */
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        return "index";
+    }
+}
+```
+
+:::panel Checkpoint
+Add the login link to your application. When you click it, verify that your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you to your application and that you are logged in.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](https://auth0.com/docs/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](https://auth0.com/docs/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
+
+## Add Logout to Your Application
+
+Now that users can log into your application, they need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). By default, when logout is enabled, Spring Security will log the user out of your application and clear the session. To enable successful logout of Auth0, you can provide a `LogoutHandler` to redirect users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://${account.namespace}/v2/logout`) and then immediately redirect them to your application.
+
+In the `SecurityConfig` class, provide a `LogoutHandler` that redirects to the Auth0 logout endpoint, and configure the `HttpSecurity` to add the logout handler:
+
+```java
+package com.auth0.example;
+
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+import org.springframework.security.web.authentication.logout.LogoutHandler;
+import org.springframework.web.servlet.support.ServletUriComponentsBuilder;
+
+import java.io.IOException;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Value("<%= "${okta.oauth2.issuer}" %>")
+    private String issuer;
+    @Value("<%= "${okta.oauth2.client-id}" %>")
+    private String clientId;
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .requestMatchers("/", "/images/**").permitAll()
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults())
+
+            // configure logout with Auth0
+            .logout(logout -> logout
+                .addLogoutHandler(logoutHandler()));
+        return http.build();
+    }
+
+    private LogoutHandler logoutHandler() {
+        return (request, response, authentication) -> {
+            try {
+                String baseUrl = ServletUriComponentsBuilder.fromCurrentContextPath().build().toUriString();
+                response.sendRedirect(issuer + "v2/logout?client_id=" + clientId + "&returnTo=" + baseUrl);
+            } catch (IOException e) {
+                throw new RuntimeException(e);
+            }
+        };
+    }
+}
+```
+
+You can then update your view to POST to the `/logout` endpoint (Spring Security provides this by default) to enable users to log out.
+
+```html
+
    
+    
    You are logged in!
    
+    
    
+        
    
+```
+
+:::panel Checkpoint
+Add the logout link in the view of your application. When you click it, verify that your application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+You can retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users through the [OidcUser](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/oidc/user/OidcUser.html) class, which can be used with the [AuthenticationPrincipal annotation](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/core/annotation/AuthenticationPrincipal.html).
+
+In your controller, add the user's profile information to the model:
+
+```java
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        if (principal != null) {
+            model.addAttribute("profile", principal.getClaims());
+        }
+        return "index";
+    }
+}
+```
+
+You can then use this profile information in your view, as shown below.
+
+```html
+
    
+    " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+    
    ">
    
+    
    ">
    
+    Log Out
+
    
+```
+
+:::panel Checkpoint
+Verify that you can display the user name or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) after you have logged in.
+:::
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/download.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/download.md
new file mode 100644
index 0000000000..9b2aebcefc
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/login/oauth2/code/auth0
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./gradlew clean bootRun
+# In Windows
+gradlew clean bootRun
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/application.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/application.md
new file mode 100644
index 0000000000..093b036734
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/application.md
@@ -0,0 +1,11 @@
+---
+name: application.yml
+language: yaml
+---
+```yaml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/home-controller.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/home-controller.md
new file mode 100644
index 0000000000..ad510c0ccf
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/home-controller.md
@@ -0,0 +1,28 @@
+---
+name: HomeController.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.security.core.annotation.AuthenticationPrincipal;
+import org.springframework.security.oauth2.core.oidc.user.OidcUser;
+import org.springframework.stereotype.Controller;
+import org.springframework.ui.Model;
+import org.springframework.web.bind.annotation.GetMapping;
+
+/**
+ * Controller for the home page.
+ */
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        if (principal != null) {
+            model.addAttribute("profile", principal.getClaims());
+        }
+        return "index";
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/index.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/index.md
new file mode 100644
index 0000000000..453bffc798
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/index.md
@@ -0,0 +1,23 @@
+---
+name: index.html
+language: html
+---
+```html
+
+
+    
+        
    
+            Log In
+        
    
+        
    
+            
    You are logged in!
    
+            " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+            
    ">
    
+            
    ">
    
+            
    
+                
    
+    
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md
new file mode 100644
index 0000000000..2b60bcd070
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md
@@ -0,0 +1,55 @@
+---
+name: SecurityConfigWithLogout.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+import org.springframework.security.web.authentication.logout.LogoutHandler;
+import org.springframework.web.servlet.support.ServletUriComponentsBuilder;
+
+import java.io.IOException;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Value("<%= "${okta.oauth2.issuer}" %>")
+    private String issuer;
+    @Value("<%= "${okta.oauth2.client-id}" %>")
+    private String clientId;
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .requestMatchers("/", "/images/**").permitAll()
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults())
+            .logout(logout -> logout
+                .addLogoutHandler(logoutHandler()));
+        return http.build();
+    }
+
+    private LogoutHandler logoutHandler() {
+        return (request, response, authentication) -> {
+            try {
+                String baseUrl = ServletUriComponentsBuilder.fromCurrentContextPath().build().toUriString();
+                response.sendRedirect(issuer + "v2/logout?client_id=" + clientId + "&returnTo=" + baseUrl);
+            } catch (IOException e) {
+                throw new RuntimeException(e);
+            }
+        };
+    }
+}
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config.md
new file mode 100644
index 0000000000..6c68d3b916
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/files/security-config.md
@@ -0,0 +1,30 @@
+---
+name: SecurityConfig.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
+         http
+            .authorizeHttpRequests(authorize -> authorize
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults());
+        return http.build();
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/index.yml b/fr-ca/articles/quickstart/webapp/java-spring-boot/index.yml
new file mode 100644
index 0000000000..7674acadc2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/index.yml
@@ -0,0 +1,48 @@
+title: Java Spring Boot
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/spring.png
+logo_name: spring
+logo: spring
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+alias:
+  - spring boot
+  - spring-security
+seo_alias: java spring
+default_article: 01-login
+articles:
+  - 01-login
+show_steps: true
+hidden_articles:
+  - "interactive"
+sdk:
+  name: Okta Spring Boot Starter
+  url: https://github.com/okta/okta-spring-boot/
+  logo: spring
+github:
+  org: auth0-samples
+  repo: auth0-spring-boot-login-samples
+  branch: master
+requirements:
+  - Java 17
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java-spring-boot/interactive.md b/fr-ca/articles/quickstart/webapp/java-spring-boot/interactive.md
new file mode 100644
index 0000000000..a6aed541da
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,184 @@
+---
+title: Add login to your Spring Webapp
+description: The Okta Spring Boot Starter makes it easy to add login to your Spring Boot application.
+interactive: true
+files:
+  - files/application
+  - files/security-config
+  - files/index
+  - files/home-controller
+  - files/security-config-logout
+github:
+    path: mvc-login
+---
+
+# Add Login to Your Spring Web Application
+
+::: panel Using Spring WebFlux?
+This tutorial uses [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html). If you are using [Spring WebFlux](https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#spring-web-reactive), the steps to add authentication are similar, but some implementation details are different. Refer to the [Spring Boot WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/webflux-login) to see how to integrate Auth0 with your Spring Boot WebFlux application.
+:::
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/login/oauth2/code/okta',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Configure Spring Boot application
+
+### Add Spring dependencies
+
+To integrate your Spring Boot application with Auth0, include the [Okta Spring Boot Starter](https://github.com/okta/okta-spring-boot/) in your application's dependencies.
+
+:::note
+This guide uses [Thymeleaf](https://www.thymeleaf.org/) and the [Spring Security integration module](https://github.com/thymeleaf/thymeleaf-extras-springsecurity) for the view layer. If you are using a different view technology, the Spring Security configuration and components remain the same.
+:::
+
+If you're using Gradle, you can include these dependencies as shown below.
+
+```groovy
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.4'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+implementation 'org.springframework.boot:spring-boot-starter-web'
+implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
+implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'
+implementation 'nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect'
+```
+
+If you are using Maven:
+
+```xml
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.4
+    
+
+
+
+    
+        com.okta
+        okta-spring-boot-starter
+        3.0.5
+    
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        org.springframework.boot
+        spring-boot-starter-oauth2-client
+    
+    
+        org.springframework.boot
+        spring-boot-starter-thymeleaf
+    
+    
+        org.thymeleaf.extras
+        thymeleaf-extras-springsecurity6
+    
+    
+        nz.net.ultraq.thymeleaf
+        thymeleaf-layout-dialect
+    
+
+```
+
+## Configure Spring Security {{{ data-action=code data-code="application.yml#1:11" }}}
+
+The Okta Spring Boot Starter makes it easy to configure your application with Auth0. The sample below uses an `application.yml` file, though you can also use properties files or any of the other [supported externalization mechanisms](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config).
+
+
+```yaml
+# src/main/resources/application.yml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+
+# The sample and instructions above for the callback and logout URL configuration use port 3000.
+# If you wish to use a different port, change this and be sure your callback and logout URLs are
+# configured with the correct port.
+server:
+  port: 3000
+```
+
+## Add login to your application {{{ data-action=code data-code="SecurityConfig.java" }}}
+
+To enable user login with Auth0, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), and add the `@Configuration` annotation.
+
+
+:::note
+You can configure the [HttpSecurity](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html) instance to require authentication on all or certain paths. For example, to require authentication on all paths except the home page:
+
+```java
+ http
+    .authorizeHttpRequests(authorize -> authorize
+        .requestMatchers("/").permitAll()
+        .anyRequest().authenticated()
+    );
+```
+:::
+
+## Add front page {{{ data-action=code data-code="index.html" }}}
+
+The Okta Spring Boot Starter will use the client configuration you defined earlier to handle login when a user visits the `/oauth2/authorization/okta` path of your application. You can use this to create a login link in your application.
+
+This page returns the user attributes when the user authentications. You will use the `/logout` link in the template to implement the logout feature.
+
+## Add controller {{{ data-action=code data-code="HomeController.java" }}}
+
+Create a controller to handle the incoming request. This controller renders the `index.html` page. When the user authenticates, the application retrieves the users's profile information attributes to render the page.
+
+::::checkpoint
+
+:::checkpoint-default
+
+When you click the login link, verify the application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+:::
+
+:::checkpoint-failure
+If your application did not allow login or signup:
+* Verify you configured the correct Callback URL
+* Verify you added the login link to redirect to `/oauth2/authorization/okta`
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](https://auth0.com/docs/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](https://auth0.com/docs/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
+
+## Add logout to your application {{{ data-action=code data-code="SecurityConfigWithLogout.java" }}}
+
+Now that users can log into your application, they need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). By default, when logout is enabled, Spring Security will log the user out of your application and clear the session. To enable successful logout of Auth0, you can provide a `LogoutHandler` to redirect users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://${account.namespace}/v2/logout`) and then immediately redirect them to your application.
+
+In the `SecurityConfig` class, provide a `LogoutHandler` that redirects to the Auth0 logout endpoint, and configure the `HttpSecurity` to add the logout handler
+
+::::checkpoint
+
+:::checkpoint-default
+When you click logout link, the application should redirect you to the address you specified as one of the "Allowed Logout URLs" in the "Settings" and you are no longer logged in to your application.
+:::
+
+:::checkpoint-failure
+If your application did not allow logout:
+* Verify you configured the correct logout URL
+* Verify you added the logout link to POST to `/logout`
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/fr-ca/articles/quickstart/webapp/java/01-login.md b/fr-ca/articles/quickstart/webapp/java/01-login.md
new file mode 100644
index 0000000000..e8a096df04
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/01-login.md
@@ -0,0 +1,21 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Java Servlet application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Java Servlet', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/login' }) %>
+
+<%= include('_includes/_setup') %>
+
+<%= include('_includes/_login') %>
diff --git a/fr-ca/articles/quickstart/webapp/java/_includes/_login.md b/fr-ca/articles/quickstart/webapp/java/_includes/_login.md
new file mode 100644
index 0000000000..73f2db5b42
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/_includes/_login.md
@@ -0,0 +1,199 @@
+### Project Structure
+
+The Login project sample has the following structure:
+
+```text
+- src
+-- main
+---- java
+------ com
+-------- auth0
+---------- example
+------------ Auth0Filter.java
+------------ AuthenticationControllerProvider.java
+------------ HomeServlet.java
+------------ CallbackServlet.java
+------------ LoginServlet.java
+------------ LogoutServlet.java
+---- webapp
+------ WEB-INF
+-------- jsp
+---------- home.jsp
+-------- web.xml
+- build.gradle
+```
+
+The project contains a single JSP: the `home.jsp` which will display the tokens associated with the user after a successful login and provide the option to logout.
+
+The project contains a WebFilter: the `Auth0Filter.java` which will check for existing tokens before giving the user access to our protected `/portal/*` path. If the tokens don't exist, the request will be redirected to the `LoginServlet`.
+
+The project contains also four servlets:
+- `LoginServlet.java`: Invoked when the user attempts to log in. The servlet uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
+- `CallbackServlet.java`: The servlet captures requests to our Callback URL and processes the data to obtain the credentials. After a successful login, the credentials are then saved to the request's HttpSession.
+- `HomeServlet.java`: The servlet reads the previously saved tokens and shows them on the `home.jsp` resource.
+- `LogoutServlet.java`: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the login page, handled by the `LoginServlet`.
+- `AuthenticationControllerProvider`: Responsible to create and manage a single instance of the `AuthenticationController`
+
+## Create the AuthenticationController
+
+To enable users to authenticate, create an instance of the `AuthenticationController` provided by the `auth0-java-mvc-commons` SDK using the `domain`, `clientId`, and `clientSecret`.  The sample shows how to configure the component for use with tokens signed using the RS256 asymmetric signing algorithm, by specifying a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options. If you are using HS256, there is no need to configure the `JwkProvider`. 
+
+:::note
+The `AuthenticationController` does not store any context, and is inteded to be reused. Unneccessary creation may result in additonal resources being created which could impact performance.
+:::
+
+```java
+class AuthenticationControllerProvider {
+
+    private AuthenticationControllerProvider() {}
+
+    private static AuthenticationController INSTANCE;
+
+    // if multiple threads may call this, synchronize this method and consider double locking
+    static AuthenticationController getInstance(ServletConfig config) throws UnsupportedEncodingException {
+        if (INSTANCE == null) {
+            String domain = config.getServletContext().getInitParameter("com.auth0.domain");
+            String clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+            String clientSecret = config.getServletContext().getInitParameter("com.auth0.clientSecret");
+
+            if (domain == null || clientId == null || clientSecret == null) {
+                throw new IllegalArgumentException("Missing domain, clientId, or clientSecret. Did you update src/main/webapp/WEB-INF/web.xml?");
+            }
+
+            // JwkProvider required for RS256 tokens. If using HS256, do not use.
+            JwkProvider jwkProvider = new JwkProviderBuilder(domain).build();
+            INSTANCE = AuthenticationController.newBuilder(domain, clientId, clientSecret)
+                    .withJwkProvider(jwkProvider)
+                    .build();
+        }
+
+        return INSTANCE;
+    }
+```
+
+## Trigger Authentication
+
+To enable users to login, your application will redirect them to the [Universal Login](https://auth0.com/docs/universal-login) page. Using the `AuthenticationController` instance, you can generate the redirect URL by calling the `buildAuthorizeUrl(HttpServletRequest request, HttpServletResponse response, String redirectUrl)` method. The redirect URL must be the URL that was added to the **Allowed Callback URLs** of your Auth0 Application.
+
+```java
+// src/main/java/com/auth0/example/LoginServlet.java
+
+@Override
+protected void doGet(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
+    String redirectUri = req.getScheme() + "://" + req.getServerName();
+    if ((req.getScheme().equals("http") && req.getServerPort() != 80) || (req.getScheme().equals("https") && req.getServerPort() != 443)) {
+        redirectUri += ":" + req.getServerPort();
+    }
+    redirectUri += "/callback";
+
+    String authorizeUrl = authenticationController.buildAuthorizeUrl(req, res, redirectUri)
+            .build();
+    res.sendRedirect(authorizeUrl);
+}
+```
+
+After the user logs in, the result will be received in our `CallbackServlet` via either a GET or POST HTTP request. Because we are using the Authorization Code Flow (the default), a GET request will be sent. If you have configured the library for the Implicit Flow, a POST request will be sent instead.
+
+The request holds the call context that the library previously set by generating the Authorize URL with the `AuthenticationController`. When passed to the controller, you get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, you need to save the credentials somewhere to access them later. You can use the `HttpSession` of the request by using the `SessionsUtils` class included in the library.
+
+```java
+// src/main/java/com/auth0/example/CallbackServlet.java
+
+@Override
+public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+    handle(req, res);
+}
+
+@Override
+public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+    handle(req, res);
+}
+
+private void handle(HttpServletRequest req, HttpServletResponse res) throws IOException {
+    try {
+        // Parse the request
+        Tokens tokens = authenticationController.handle(req, res);
+        SessionUtils.set(req, "accessToken", tokens.getAccessToken());
+        SessionUtils.set(req, "idToken", tokens.getIdToken());
+        res.sendRedirect(redirectOnSuccess);
+    } catch (IdentityVerificationException e) {
+        e.printStackTrace();
+        res.sendRedirect(redirectOnFail);
+    }
+}
+```
+
+::: note
+It is recommended to store the time in which we requested the tokens and the received `expiresIn` value, so that the next time when we are going to use the token we can check if it has already expired or if it's still valid. For the sake of this sample, we will skip that validation.
+:::
+
+## Display the Home Page
+
+Now that the user is authenticated (the tokens exists), the `Auth0Filter` will allow them to access our protected resources. In the `HomeServlet` we obtain the tokens from the request's session and set them as the `userId` attribute so they can be used from the JSP code:
+
+```java
+// src/main/java/com/auth0/example/HomeServlet.java
+
+protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
+    final String accessToken = (String) SessionUtils.get(req, "accessToken");
+    final String idToken = (String) SessionUtils.get(req, "idToken");
+    if (accessToken != null) {
+        req.setAttribute("userId", accessToken);
+    } else if (idToken != null) {
+        req.setAttribute("userId", idToken);
+    }
+    req.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(req, res);
+}
+```
+
+## Handle Logout
+
+To properly handle logout, we need to clear the session and log the user out of Auth0. This is handled in the `LogoutServlet` of our sample application.
+
+First, we clear the session by calling `request.getSession().invalidate()`. We then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, we redirect the response to our logout URL.
+
+
+```java
+// src/main/java/com/auth0/example/LogoutServlet.java
+
+@Override
+protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+    if (request.getSession() != null) {
+        request.getSession().invalidate();
+    }
+
+    String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+    if ((request.getScheme().equals("http") && request.getServerPort() != 80) || (request.getScheme().equals("https") && request.getServerPort() != 443)) {
+        returnUrl += ":" + request.getServerPort();
+    }
+    returnUrl += "/login";
+
+    // Build logout URL like:
+    // https://{YOUR-DOMAIN}/v2/logout?client_id={YOUR-CLIENT-ID}&returnTo=http://localhost:3000/login
+    String logoutUrl = String.format(
+            "https://%s/v2/logout?client_id=%s&returnTo=%s",
+            domain,
+            clientId,
+            returnUrl
+    );
+    response.sendRedirect(logoutUrl);
+}
+```
+
+## Run the Sample
+
+To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
+
+```bash
+./gradlew clean appRun
+```
+
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource [http://localhost:3000/portal/home](http://localhost:3000/portal/home) and note how you're redirected by the `Auth0Filter` to the Auth0 Login Page. The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+After a successful authentication, you'll be able to see the home page contents.
+
+![Display Token](/media/articles/java/display-token.png)
+
+Log out by clicking the **Logout** button at the top right of the home page.
diff --git a/fr-ca/articles/quickstart/webapp/java/_includes/_setup.md b/fr-ca/articles/quickstart/webapp/java/_includes/_setup.md
new file mode 100644
index 0000000000..9d2775b755
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/_includes/_setup.md
@@ -0,0 +1,64 @@
+## Integrate Auth0 in your Application
+
+### Setup Dependencies
+
+To integrate your Java application with Auth0, add the following dependencies:
+
+- **javax.servlet-api**: is the library that allows you to create Java Servlets. You then need to add a Server dependency like Tomcat or Gretty, which one is up to you. Check our sample code for more information.
+- **auth0-java-mvc-commons**: is the [Java library](https://github.com/auth0/auth0-java-mvc-common) that allows you to use Auth0 with Java for server-side MVC web apps. It generates the Authorize URL that you need to call in order to authenticate and validates the result received on the way back to finally obtain the [Auth0 Tokens](/tokens) that identify the user.
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+compile 'com.auth0:mvc-auth-commons:1.+'
+```
+
+If you are using Maven, add them to your `pom.xml`:
+
+```xml
+
+
+
+  com.auth0
+  mvc-auth-commons
+  [1.0, 2.0)
+
+
+  javax.servlet
+  javax.servlet-api
+  3.1.0
+
+```
+
+### Configure your Java App
+
+Your Java App needs some information in order to authenticate against your Auth0 account. The samples read this information from the deployment descriptor file `src/main/webapp/WEB-INF/web.xml`, but you could store them anywhere else. The required information is:
+
+```xml
+
+
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    YOUR_CLIENT_SECRET
+
+```
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [library's documentation](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md).
+
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
diff --git a/fr-ca/articles/quickstart/webapp/java/download.md b/fr-ca/articles/quickstart/webapp/java/download.md
new file mode 100644
index 0000000000..12572623a2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/login
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./gradlew clean appRun
+# In Windows
+gradlew clean appRun
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/authentication-controller-provider.md b/fr-ca/articles/quickstart/webapp/java/files/authentication-controller-provider.md
new file mode 100644
index 0000000000..c722f0beef
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/authentication-controller-provider.md
@@ -0,0 +1,33 @@
+---
+name: AuthenticationControllerProvider.java
+language: java
+---
+```java
+class AuthenticationControllerProvider {
+
+    private AuthenticationControllerProvider() {}
+
+    private static AuthenticationController INSTANCE;
+
+    // if multiple threads may call this, synchronize this method and consider double locking
+    static AuthenticationController getInstance(ServletConfig config) throws UnsupportedEncodingException {
+        if (INSTANCE == null) {
+            String domain = config.getServletContext().getInitParameter("com.auth0.domain");
+            String clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+            String clientSecret = config.getServletContext().getInitParameter("com.auth0.clientSecret");
+
+            if (domain == null || clientId == null || clientSecret == null) {
+                throw new IllegalArgumentException("Missing domain, clientId, or clientSecret. Did you update src/main/webapp/WEB-INF/web.xml?");
+            }
+
+            // JwkProvider required for RS256 tokens. If using HS256, do not use.
+            JwkProvider jwkProvider = new JwkProviderBuilder(domain).build();
+            INSTANCE = AuthenticationController.newBuilder(domain, clientId, clientSecret)
+                    .withJwkProvider(jwkProvider)
+                    .build();
+        }
+
+        return INSTANCE;
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/callback-servlet.md b/fr-ca/articles/quickstart/webapp/java/files/callback-servlet.md
new file mode 100644
index 0000000000..1c60791bd7
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/callback-servlet.md
@@ -0,0 +1,44 @@
+---
+name: CallbackServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/callback"})
+public class CallbackServlet extends HttpServlet {
+
+    private String redirectOnSuccess;
+    private String redirectOnFail;
+    private AuthenticationController authenticationController;
+
+    @Override
+    public void init(ServletConfig config) throws ServletException {
+        super.init(config);
+        redirectOnSuccess = "/portal/home";
+        redirectOnFail = "/login";
+        authenticationController = AuthenticationControllerProvider.getInstance(config);
+    }
+
+    @Override
+    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+        handle(req, res);
+    }
+
+    @Override
+    public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+        handle(req, res);
+    }
+
+    private void handle(HttpServletRequest req, HttpServletResponse res) throws IOException {
+        try {
+            // Parse the request
+            Tokens tokens = authenticationController.handle(req, res);
+            SessionUtils.set(req, "accessToken", tokens.getAccessToken());
+            SessionUtils.set(req, "idToken", tokens.getIdToken());
+            res.sendRedirect(redirectOnSuccess);
+        } catch (IdentityVerificationException e) {
+            e.printStackTrace();
+            res.sendRedirect(redirectOnFail);
+        }
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/home-servlet.md b/fr-ca/articles/quickstart/webapp/java/files/home-servlet.md
new file mode 100644
index 0000000000..5013342a7b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/home-servlet.md
@@ -0,0 +1,21 @@
+---
+name: HomeServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/portal/home"})
+public class HomeServlet extends HttpServlet {
+
+    @Override
+    protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
+        final String accessToken = (String) SessionUtils.get(req, "accessToken");
+        final String idToken = (String) SessionUtils.get(req, "idToken");
+        if (accessToken != null) {
+            req.setAttribute("userId", accessToken);
+        } else if (idToken != null) {
+            req.setAttribute("userId", idToken);
+        }
+        req.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(req, res);
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/login-servlet.md b/fr-ca/articles/quickstart/webapp/java/files/login-servlet.md
new file mode 100644
index 0000000000..34af59e76e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/login-servlet.md
@@ -0,0 +1,31 @@
+---
+name: LoginServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/login"})
+public class LoginServlet extends HttpServlet {
+    private AuthenticationController authenticationController;
+    private String domain;
+
+    @Override
+    public void init(ServletConfig config) throws ServletException {
+        super.init(config);
+        domain = config.getServletContext().getInitParameter("com.auth0.domain");
+        authenticationController = AuthenticationControllerProvider.getInstance(config);
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
+        String redirectUri = req.getScheme() + "://" + req.getServerName();
+        if ((req.getScheme().equals("http") && req.getServerPort() != 80) || (req.getScheme().equals("https") && req.getServerPort() != 443)) {
+            redirectUri += ":" + req.getServerPort();
+        }
+        redirectUri += "/callback";
+
+        String authorizeUrl = authenticationController.buildAuthorizeUrl(req, res, redirectUri)
+                .build();
+        res.sendRedirect(authorizeUrl);
+    }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/logout-servlet.md b/fr-ca/articles/quickstart/webapp/java/files/logout-servlet.md
new file mode 100644
index 0000000000..50c36f2249
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/logout-servlet.md
@@ -0,0 +1,38 @@
+---
+name: LogoutServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/logout"})
+public class LogoutServlet extends HttpServlet {
+
+    private String domain;
+    private String clientId;
+
+    @Override
+    public void init(ServletConfig config) {
+        domain = config.getServletContext().getInitParameter("com.auth0.domain");
+        clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+        if (request.getSession() != null) {
+            request.getSession().invalidate();
+        }
+        String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+        if ((request.getScheme().equals("http") && request.getServerPort() != 80) || (request.getScheme().equals("https") && request.getServerPort() != 443)) {
+            returnUrl += ":" + request.getServerPort();
+        }
+        returnUrl += "/login";
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                domain,
+                clientId,
+                returnUrl
+        );
+        response.sendRedirect(logoutUrl);
+    }
+
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/files/web.md b/fr-ca/articles/quickstart/webapp/java/files/web.md
new file mode 100644
index 0000000000..df86d7ee74
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/files/web.md
@@ -0,0 +1,20 @@
+---
+name: web.xml
+language: xml
+---
+```xml
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    YOUR_CLIENT_SECRET
+
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/java/index.yml b/fr-ca/articles/quickstart/webapp/java/index.yml
new file mode 100644
index 0000000000..77afc30ff0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/index.yml
@@ -0,0 +1,47 @@
+title: Java
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/java.png
+logo: java
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+alias:
+  - java
+seo_alias: java
+default_article: 01-login
+articles:
+  - 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-servlet-sample
+  branch: master
+hidden_articles:
+  - "interactive"
+sdk:
+  name: auth0-java-mvc-common
+  url: https://github.com/auth0/auth0-java-mvc-common
+  logo: java
+requirements:
+  - Java 8
+  - Gradle 3.3 and up
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/fr-ca/articles/quickstart/webapp/java/interactive.md b/fr-ca/articles/quickstart/webapp/java/interactive.md
new file mode 100644
index 0000000000..5fb7532d8c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,160 @@
+---
+title: Add Login to your Java Servlet application
+description: This tutorial demonstrates how to add user login to a Java Servlet application.
+interactive: true
+files:
+  - files/web
+  - files/authentication-controller-provider
+  - files/login-servlet
+  - files/callback-servlet
+  - files/home-servlet
+  - files/logout-servlet
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java
+github:
+  path: 01-Login
+---
+
+# Add Login to Your Java Servlet Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Java Servlet application.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000/login'
+}) %>
+
+## Integrate Auth0 in your application
+
+### Setup dependencies
+
+To integrate your Java application with Auth0, add the following dependencies:
+
+- **javax.servlet-api**: is the library that allows you to create Java Servlets. You then need to add a Server dependency like Tomcat or Gretty, which one is up to you. Check our sample code for more information.
+- **auth0-java-mvc-commons**: is the [Java library](https://github.com/auth0/auth0-java-mvc-common) that allows you to use Auth0 with Java for server-side MVC web apps. It generates the Authorize URL that you need to call in order to authenticate and validates the result received on the way back to finally obtain the [Auth0 Tokens](/tokens) that identify the user.
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+compile 'com.auth0:mvc-auth-commons:1.+'
+```
+
+If you are using Maven, add them to your `pom.xml`:
+
+```xml
+
+
+
+  com.auth0
+  mvc-auth-commons
+  [1.0, 2.0)
+
+
+  javax.servlet
+  javax.servlet-api
+  3.1.0
+
+```
+
+## Configure your Java application {{{ data-action=code data-code="web.xml#6:14" }}}
+
+Your Java App needs some information in order to authenticate against your Auth0 account. The samples read this information from the deployment descriptor file `src/main/webapp/WEB-INF/web.xml`, but you could store them anywhere else.
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [library's documentation](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md).
+
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
+
+### Project structure
+
+The example project, which can be downloaded using the **Download Sample** button, has the following structure:
+
+```text
+- src
+-- main
+---- java
+------ com
+-------- auth0
+---------- example
+------------ Auth0Filter.java
+------------ AuthenticationControllerProvider.java
+------------ HomeServlet.java
+------------ CallbackServlet.java
+------------ LoginServlet.java
+------------ LogoutServlet.java
+---- webapp
+------ WEB-INF
+-------- jsp
+---------- home.jsp
+-------- web.xml
+- build.gradle
+```
+
+The project contains a single JSP: the `home.jsp` which will display the tokens associated with the user after a successful login and provide the option to logout.
+
+The project contains a WebFilter: the `Auth0Filter.java` which will check for existing tokens before giving the user access to our protected `/portal/*` path. If the tokens don't exist, the request will be redirected to the `LoginServlet`.
+
+The project contains also four servlets:
+- `LoginServlet.java`: Invoked when the user attempts to log in. The servlet uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
+- `CallbackServlet.java`: The servlet captures requests to our Callback URL and processes the data to obtain the credentials. After a successful login, the credentials are then saved to the request's HttpSession.
+- `HomeServlet.java`: The servlet reads the previously saved tokens and shows them on the `home.jsp` resource.
+- `LogoutServlet.java`: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the login page, handled by the `LoginServlet`.
+- `AuthenticationControllerProvider`: Responsible to create and manage a single instance of the `AuthenticationController`
+  
+## Create the AuthenticationController {{{ data-action=code data-code="AuthenticationControllerProvider.java#6-32 }}}
+
+To enable users to authenticate, create an instance of the `AuthenticationController` provided by the `auth0-java-mvc-commons` SDK using the `domain`, `clientId`, and `clientSecret`.  The sample shows how to configure the component for use with tokens signed using the RS256 asymmetric signing algorithm, by specifying a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options. If you are using HS256, there is no need to configure the `JwkProvider`. 
+
+:::note
+The `AuthenticationController` does not store any context, and is inteded to be reused. Unneccessary creation may result in additonal resources being created which could impact performance.
+:::
+
+## Login Redirection {{{ data-action=code data-code="LoginServlet.java#21:23" }}}
+
+To enable users to log in, your application will redirect them to the [Universal Login](https://auth0.com/docs/universal-login) page. Using the `AuthenticationController` instance, you can generate the redirect URL by calling the `buildAuthorizeUrl(HttpServletRequest request, HttpServletResponse response, String redirectUrl)` method. The redirect URL must be the URL that was added to the **Allowed Callback URLs** of your Auth0 application.
+
+## Handling the tokens {{{ data-action=code data-code="CallbackServlet.java#16:37" }}}
+
+After the user logs in, the result will be received in our `CallbackServlet` via either a GET or POST HTTP request. Because we are using the Authorization Code Flow (the default), a GET request will be sent. If you have configured the library for the Implicit Flow, a POST request will be sent instead.
+
+The request holds the call context that the library previously set by generating the Authorize URL with the `AuthenticationController`. When passed to the controller, you get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, you need to save the credentials somewhere to access them later. You can use the `HttpSession` of the request by using the `SessionsUtils` class included in the library.
+
+::: note
+It is recommended to store the time in which we requested the tokens and the received `expiresIn` value, so that the next time when we are going to use the token we can check if it has already expired or if it's still valid. For the sake of this sample, we will skip that validation.
+:::
+
+## Display the home page {{{ data-action=code data-code="HomeServlet.java#4:14" }}}
+
+Now that the user is authenticated (the tokens exists), the `Auth0Filter` will allow them to access our protected resources. In the `HomeServlet` we obtain the tokens from the request's session and set them as the `userId` attribute so they can be used from the JSP code.
+
+## Handle logout {{{ data-action=code data-code="LogoutServlet.java#13:30" }}}
+
+To properly handle logout, we need to clear the session and log the user out of Auth0. This is handled in the `LogoutServlet` of our sample application.
+
+First, we clear the session by calling `request.getSession().invalidate()`. We then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, we redirect the response to our logout URL.
+
+## Run the sample {{{ data-action=code data-code="LogoutServlet.java#13:30" }}}
+
+To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
+
+```bash
+./gradlew clean appRun
+```
+
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource [http://localhost:3000/portal/home](http://localhost:3000/portal/home) and note how you're redirected by the `Auth0Filter` to the Auth0 Login Page. The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+After a successful authentication, you'll be able to see the home page contents.
+
+![Display Token](/media/articles/java/display-token.png)
+
+Log out by clicking the **logout** button at the top right of the home page.
diff --git a/fr-ca/articles/quickstart/webapp/laravel/01-login.md b/fr-ca/articles/quickstart/webapp/laravel/01-login.md
new file mode 100644
index 0000000000..44ac2c72df
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/01-login.md
@@ -0,0 +1,217 @@
+---
+title: Add Login to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+topics:
+  - quickstart
+  - webapp
+  - laravel
+  - authentication
+  - login
+  - user profile
+  - logout
+  - php
+  - laravel
+contentType: tutorial
+useCase: quickstart
+github:
+  path: sample
+---
+
+
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-app
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Application" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Application's API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Login Routes
+
+The SDK automatically registers all the necessary routes for your application's users to authenticate.
+
+| Route       | Purpose                            |
+| ----------- | ---------------------------------- |
+| `/login`    | Initiates the authentication flow. |
+| `/logout`   | Logs the user out.                 |
+| `/callback` | Handles the callback from Auth0.   |
+
+If you require more control over these, or if they conflict with existing routes in your application, you can manually register the SDK's controllers instead. Please see [the SDK's README](https://github.com/auth0/laravel-auth0) for advanced integrations.
+
+## Access Control {{{ data-action=code data-code="routes/web.php#6:12" }}}
+
+Laravel's authentication facilities use "guards" to define how users are authenticated for each request. You can use the Auth0 SDK's authentication guard to restrict access to your application's routes.
+
+To require users to authenticate before accessing a route, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response('Welcome! You are logged in.');
+})->middleware('auth');
+```
+
+You can also require authenticated users to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response('You have the `read:messages` permissions, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+```
+
+## User Information {{{ data-action=code data-code="routes/web.php#14:24" }}}
+
+Information about the authenticated user is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});
+```
+
+## User Management{{{ data-action=code data-code="routes/web.php#26:43" }}}
+
+You can update user information using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/Management.md). All Management endpoints are accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, in which we will update a user's metadata and assign a random favorite color, you should grant the `read:users` and `update:users` scopes. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id());
+  $metadata = Auth0::json($metadata);
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
+
+A quick reference guide of all the SDK's Management API methods is [available here](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md).
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+### Checkpoint
+
+Open your web browser and try accessing the following routes:
+
+- [http://localhost:8000](http://localhost:8000) to see the public route.
+- [http://localhost:8000/private](http://localhost:8000/private) to be prompted to authenticate.
+- [http://localhost:8000](http://localhost:8000) to see the pubic route, now authenticated.
+- [http://localhost:8000/scope](http://localhost:8000/scope) to check if you have the `read:messages` [permission](https://auth0.com/docs/manage-users/access-control/rbac).
+- [http://localhost:8000/update](http://localhost:8000/update) to update the user's profile.
+- [http://localhost:8000/logout](http://localhost:8000/logout) to log out.
+
+If you have any issues, here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/fr-ca/articles/quickstart/webapp/laravel/download.md b/fr-ca/articles/quickstart/webapp/laravel/download.md
new file mode 100644
index 0000000000..e149badf02
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/download.md
@@ -0,0 +1,8 @@
+Open a shell to the downloaded project directory, and run the following command:
+
+```bash
+composer install
+php artisan migrate
+php artisan key:generate
+php artisan serve
+```
diff --git a/fr-ca/articles/quickstart/webapp/laravel/files/web.md b/fr-ca/articles/quickstart/webapp/laravel/files/web.md
new file mode 100644
index 0000000000..77344cc11d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/files/web.md
@@ -0,0 +1,54 @@
+---
+name: routes/web.php
+language: php
+---
+
+```php
+middleware('auth');
+
+Route::get('/scope', function () {
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id()); // Retrieve the user's metadata.
+  $metadata = Auth0::json($metadata); // Convert the JSON to a PHP array.
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
diff --git a/fr-ca/articles/quickstart/webapp/laravel/index.yml b/fr-ca/articles/quickstart/webapp/laravel/index.yml
new file mode 100644
index 0000000000..3379252e0f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/index.yml
@@ -0,0 +1,36 @@
+title: Laravel
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: laravel
+alias:
+  - laravel
+languages:
+  - PHP
+framework:
+  - Laravel
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+default_article: 01-login
+seo_alias: laravel
+github:
+  org: auth0-samples
+  repo: laravel
+  branch: 7.x
+sdk:
+  name: laravel-auth0
+  url: https://github.com/auth0/laravel-auth0
+  logo: laravel
+requirements:
+  - Laravel 9 / 10
+  - PHP 8.0+
+  - Composer
diff --git a/fr-ca/articles/quickstart/webapp/laravel/interactive.md b/fr-ca/articles/quickstart/webapp/laravel/interactive.md
new file mode 100644
index 0000000000..a61c8af6ae
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,229 @@
+---
+title: Add Login to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+budicon: 448
+topics:
+  - quickstart
+  - webapp
+  - laravel
+  - authentication
+  - login
+  - user profile
+  - logout
+  - php
+  - laravel
+github:
+  path: app
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/web
+---
+
+# Add Login to Your Laravel Application
+
+[Auth0's Laravel SDK](https://github.com/auth0/laravel-auth0) allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new (or existing) [Laravel 9 or 10](https://github.com/auth0/laravel-auth0#support-policy) application.
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-app
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Application" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Application's API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Login Routes
+
+The SDK automatically registers all the necessary routes for your application's users to authenticate.
+
+| Route       | Purpose                            |
+| ----------- | ---------------------------------- |
+| `/login`    | Initiates the authentication flow. |
+| `/logout`   | Logs the user out.                 |
+| `/callback` | Handles the callback from Auth0.   |
+
+If you require more control over these, or if they conflict with existing routes in your application, you can manually register the SDK's controllers instead. Please see [the SDK's README](https://github.com/auth0/laravel-auth0) for advanced integrations.
+
+## Access Control {{{ data-action=code data-code="routes/web.php#6:12" }}}
+
+Laravel's authentication facilities use "guards" to define how users are authenticated for each request. You can use the Auth0 SDK's authentication guard to restrict access to your application's routes.
+
+To require users to authenticate before accessing a route, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response('Welcome! You are logged in.');
+})->middleware('auth');
+```
+
+You can also require authenticated users to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+```
+
+## User Information {{{ data-action=code data-code="routes/web.php#14:24" }}}
+
+Information about the authenticated user is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});;
+```
+
+## User Management{{{ data-action=code data-code="routes/web.php#26:43" }}}
+
+You can update user information using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). All Management endpoints are accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, in which we will update a user's metadata and assign a random favorite color, you should grant the `read:users` and `update:users` scopes. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id());
+  $metadata = Auth0::json($metadata);
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
+
+A quick reference guide of all the SDK's Management API methods is [available here](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md).
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+::::checkpoint
+:::checkpoint-default
+Open your web browser and try accessing the following routes:
+
+- [http://localhost:8000](http://localhost:8000) to see the public route.
+- [http://localhost:8000/private](http://localhost:8000/private) to be prompted to authenticate.
+- [http://localhost:8000](http://localhost:8000) to see the public route, now authenticated.
+- [http://localhost:8000/scope](http://localhost:8000/scope) to check if you have the `read:messages` [permission](https://auth0.com/docs/manage-users/access-control/rbac).
+- [http://localhost:8000/update](http://localhost:8000/update) to update the user's profile.
+- [http://localhost:8000/logout](http://localhost:8000/logout) to log out.
+
+:::
+
+:::checkpoint-failure
+Here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+:::
+::::
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/01-login.md b/fr-ca/articles/quickstart/webapp/nextjs/01-login.md
new file mode 100644
index 0000000000..5695369845
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/01-login.md
@@ -0,0 +1,206 @@
+---
+title: Login
+description: "This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK."
+budicon: 448
+topics:
+  - quickstarts
+  - nextjs
+  - next.js
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+---
+
+
+<%= include('../_includes/_getting_started', { library: 'Next.js', callback: 'http://localhost:3000/api/auth/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install the Auth0 Next.js SDK
+
+Run the following command within your project directory to install the Auth0 Next.js SDK:
+
+```sh
+npm install @auth0/nextjs-auth0
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your Next.js application using [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers) on the backend and [React Context](https://reactjs.org/docs/context.html) with [React Hooks](https://reactjs.org/docs/hooks-overview.html) on the frontend.
+
+### Configure the SDK
+
+In the root directory of your project, add the file `.env.local` with the following [environment variables](https://nextjs.org/docs/basic-features/environment-variables):
+
+```sh
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+AUTH0_BASE_URL='http://localhost:3000'
+AUTH0_ISSUER_BASE_URL='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
+
+- `AUTH0_SECRET`: A long secret value used to encrypt the session cookie. You can generate a suitable string using `openssl rand -hex 32` on the command line.
+- `AUTH0_BASE_URL`: The base URL of your application.
+- `AUTH0_ISSUER_BASE_URL`: The URL of your Auth0 tenant domain. If you are using a [Custom Domain with Auth0](https://auth0.com/docs/custom-domains), set this to the value of your Custom Domain instead of the value reflected in the "Settings" tab.
+- `AUTH0_CLIENT_ID`: Your Auth0 application's Client ID.
+- `AUTH0_CLIENT_SECRET`: Your Auth0 application's Client Secret.
+
+The SDK will read these values from the Node.js process environment and automatically configure itself.
+
+### Add the dynamic API route handler
+
+Create a file at `app/api/auth/[auth0]/route.js`. This is your Route Handler file with a [Dynamic Route Segment](https://nextjs.org/docs/app/building-your-application/routing/route-handlers#dynamic-route-segments).
+
+Then, import the `handleAuth` method from the SDK and call it from the `GET` export.
+
+```javascript
+// app/api/auth/[auth0]/route.js
+import { handleAuth } from '@auth0/nextjs-auth0';
+
+export const GET = handleAuth();
+```
+
+This creates the following routes:
+
+- `/api/auth/login`: The route used to perform login with Auth0.
+- `/api/auth/logout`: The route used to log the user out.
+- `/api/auth/callback`: The route Auth0 will redirect the user to after a successful login.
+- `/api/auth/me`: The route to fetch the user profile from.
+
+::: note
+This QuickStart targets the Next.js [App Router](https://nextjs.org/docs/app). If you're using the [Pages Router](https://nextjs.org/docs/pages), check out the example in the SDK's [README](https://github.com/auth0/nextjs-auth0#page-router).
+:::
+
+### Add the `UserProvider` component
+
+On the frontend side, the SDK uses React Context to manage the authentication state of your users. To make that state available to all your pages, you need to override the [Root Layout component](https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#root-layout-required) and wrap the `` tag with a `UserProvider` in the file `app/layout.jsx`. 
+
+Create the file `app/layout.jsx` as follows:
+
+```jsx
+// app/layout.jsx
+import { UserProvider } from '@auth0/nextjs-auth0/client';
+
+export default function RootLayout({ children }) {
+  return (
+    
+    
+      {children}
+    
+    
+  );
+}
+```
+
+The authentication state exposed by `UserProvider` can be accessed in any Client Component using the `useUser()` hook.
+
+:::panel Checkpoint
+Now that you have added the dynamic route and `UserProvider`, run your application to verify that your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+Users can now log in to your application by visiting the `/api/auth/login` route provided by the SDK. Add a link that points to the login route using an **anchor tag**. Clicking it redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application.
+
+:::note
+Next linting rules might suggest using the `Link` component instead of an anchor tag. The `Link` component is meant to perform [client-side transitions between pages](https://nextjs.org/docs/api-reference/next/link). As the link points to an API route and not to a page, you should keep it as an anchor tag.
+:::
+
+```html
+Login
+```
+
+:::panel Checkpoint
+Add the login link to your application. When you click it, verify that your Next.js application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects back to your application.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application
+
+Now that you can log in to your Next.js application, you need [a way to log out](https://auth0.com/docs/logout/log-users-out-of-auth0). Add a link that points to the `/api/auth/logout` API route. Clicking it redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them back to your application.
+
+```html
+Logout
+```
+
+:::panel Checkpoint
+Add the logout link to your application. When you click it, verify that your Next.js application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings".
+:::
+
+## Show User Profile Information
+
+The Auth0 Next.js SDK helps you retrieve the [profile information](https://auth0.com/docs/users/user-profiles) associated with the logged-in user, such as their name or profile picture, to personalize the user interface.
+
+### From a Client Component
+
+The profile information is available through the `user` property exposed by the `useUser()` hook. Take this [Client Component](https://nextjs.org/docs/getting-started/react-essentials#client-components) as an example of how to use it:
+
+```jsx
+'use client';
+
+import { useUser } from '@auth0/nextjs-auth0/client';
+
+export default function ProfileClient() {
+  const { user, error, isLoading } = useUser();
+
+  if (isLoading) return 
    Loading...
    ;
+  if (error) return 
    {error.message}
    ;
+
+  return (
+    user && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+      
    
+    )
+  );
+}
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors:
+
+- Ensure that the SDK has completed loading before accessing the `user` property by checking that `isLoading` is `false`.
+- Ensure that the SDK has loaded successfully by checking that no `error` was produced.
+- Check the `user` property to ensure that Auth0 has authenticated the user before React renders any component that consumes it.
+
+### From a Server Component
+
+The profile information is available through the `user` property exposed by the `getSession` function. Take this [Server Component](https://nextjs.org/docs/getting-started/react-essentials#server-components) as an example of how to use it:
+
+```jsx
+import { getSession } from '@auth0/nextjs-auth0';
+
+export default async function ProfileServer() {
+  const { user } = await getSession();
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
+
+:::panel Checkpoint
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::                                              
+
+## What's next?
+
+We put together a few examples of how to use [nextjs-auth0](https://github.com/auth0/nextjs-auth0) in more advanced use cases:
+
+- [Protecting a Server Side Rendered (SSR) Page](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protecting-a-server-side-rendered-ssr-page)
+- [Protecting a Client Side Rendered (CSR) Page](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protecting-a-client-side-rendered-csr-page)
+- [Protect an API Route](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protect-an-api-route)
+- [Access an External API from an API Route](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#access-an-external-api-from-an-api-route)
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/download.md b/fr-ca/articles/quickstart/webapp/nextjs/download.md
new file mode 100644
index 0000000000..01e6c1689f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/download.md
@@ -0,0 +1,27 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000/api/auth/callback
+```
+
+2) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+
+3) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the root directory:
+```bash
+npm install && npm run dev
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/auth.md b/fr-ca/articles/quickstart/webapp/nextjs/files/auth.md
new file mode 100644
index 0000000000..4a7cc02805
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/auth.md
@@ -0,0 +1,12 @@
+---
+name: "app/api/auth/[auth0]/route.js"
+language: javascript
+---
+
+
+
+```javascript
+import { handleAuth } from '@auth0/nextjs-auth0';
+
+export const GET = handleAuth();
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/env.md b/fr-ca/articles/quickstart/webapp/nextjs/files/env.md
new file mode 100644
index 0000000000..22abaa809d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/env.md
@@ -0,0 +1,14 @@
+---
+name: .env.local
+language: sh
+---
+
+
+
+```sh
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+AUTH0_BASE_URL='http://localhost:3000'
+AUTH0_ISSUER_BASE_URL='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/layout.md b/fr-ca/articles/quickstart/webapp/nextjs/files/layout.md
new file mode 100644
index 0000000000..8567031642
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/layout.md
@@ -0,0 +1,20 @@
+---
+name: "app/layout.jsx"
+language: jsx
+---
+
+
+
+```jsx
+import { UserProvider } from '@auth0/nextjs-auth0/client';
+
+export default function RootLayout({ children }) {
+  return (
+    
+      
+        {children}
+      
+    
+  );
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/login.md b/fr-ca/articles/quickstart/webapp/nextjs/files/login.md
new file mode 100644
index 0000000000..e245a0cbbd
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/login.md
@@ -0,0 +1,12 @@
+---
+name: "app/login.jsx"
+language: jsx
+---
+
+
+
+```jsx
+export default function Login() {
+  return Login;
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/logout.md b/fr-ca/articles/quickstart/webapp/nextjs/files/logout.md
new file mode 100644
index 0000000000..60fa22031e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/logout.md
@@ -0,0 +1,12 @@
+---
+name: "app/logout.jsx"
+language: jsx
+---
+
+
+
+```jsx
+export default function Logout() {
+  return Logout;
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/profile-client.md b/fr-ca/articles/quickstart/webapp/nextjs/files/profile-client.md
new file mode 100644
index 0000000000..a4ae7102fe
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/profile-client.md
@@ -0,0 +1,29 @@
+---
+name: "app/profile-client/page.jsx"
+language: jsx
+---
+
+
+
+```jsx
+'use client';
+
+import { useUser } from '@auth0/nextjs-auth0/client';
+
+export default function ProfileClient() {
+  const { user, error, isLoading } = useUser();
+
+  if (isLoading) return 
    Loading...
    ;
+  if (error) return 
    {error.message}
    ;
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/files/profile-server.md b/fr-ca/articles/quickstart/webapp/nextjs/files/profile-server.md
new file mode 100644
index 0000000000..1f164c403a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/files/profile-server.md
@@ -0,0 +1,24 @@
+---
+name: "app/profile-server/page.jsx"
+language: jsx
+---
+
+
+
+```jsx
+import { getSession } from '@auth0/nextjs-auth0';
+
+export default async function ProfileServer() {
+  const { user } = await getSession();
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/index.yml b/fr-ca/articles/quickstart/webapp/nextjs/index.yml
new file mode 100644
index 0000000000..ad6a5b3b9a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/index.yml
@@ -0,0 +1,39 @@
+title: Next.js
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/nginx-plus.png
+logo: nextjs
+alias:
+  - next
+  - nextjs
+  - next.js
+language:
+  - Javascript
+framework:
+  - Next.js
+author:
+  name: Rita Zerrizuela
+  email: rita.zerrizuela@auth0.com
+  community: false
+
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: nextjs
+show_releases: true
+show_steps: true
+requirements:
+  - Next.js 13.4+
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+sdk:
+  name: nextjs-auth0
+  url: https://github.com/auth0/nextjs-auth0/
+  logo: nextjs
+github:
+  org: auth0-samples
+  repo: auth0-nextjs-samples
+  branch: main
diff --git a/fr-ca/articles/quickstart/webapp/nextjs/interactive.md b/fr-ca/articles/quickstart/webapp/nextjs/interactive.md
new file mode 100644
index 0000000000..360ae01269
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,172 @@
+---
+title: Add Login to your Next.js application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK.
+topics:
+  - quickstarts
+  - webapp
+  - nextjs
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+ - files/auth
+ - files/env
+ - files/layout
+ - files/login
+ - files/logout
+ - files/profile-client
+ - files/profile-server
+---
+
+
+
+# Add Login to Your Next.js Application
+
+This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK. We recommend that you log in to follow this quickstart with examples configured for your account.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/api/auth/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install the Auth0 Next.js SDK
+
+Run the following command within your project directory to install the Auth0 Next.js SDK:
+
+```sh
+npm install @auth0/nextjs-auth0
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your Next.js application using [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers) on the backend and [React Context](https://reactjs.org/docs/context.html) with [React Hooks](https://reactjs.org/docs/hooks-overview.html) on the frontend.
+
+## Configure the SDK {{{ data-action=code data-code=".env.local" }}}
+
+In the root directory of your project, add the file `.env.local` with the following [environment variables](https://nextjs.org/docs/basic-features/environment-variables):
+
+- `AUTH0_SECRET`: A long secret value used to encrypt the session cookie. You can generate a suitable string using `openssl rand -hex 32` on the command line.
+- `AUTH0_BASE_URL`: The base URL of your application.
+- `AUTH0_ISSUER_BASE_URL`: The URL of your Auth0 tenant domain. If you are using a [Custom Domain with Auth0](https://auth0.com/docs/custom-domains), set this to the value of your Custom Domain instead of the value reflected in the "Settings" tab.
+- `AUTH0_CLIENT_ID`: Your Auth0 application's Client ID.
+- `AUTH0_CLIENT_SECRET`: Your Auth0 application's Client Secret.
+
+The SDK will read these values from the Node.js process environment and automatically configure itself.
+
+## Add the dynamic Route Handler {{{ data-action=code data-code="app/api/auth/[auth0]/route.js" }}}
+
+::: note
+This QuickStart targets the Next.js [App Router](https://nextjs.org/docs/app). If you're using the [Pages Router](https://nextjs.org/docs/pages), check out the example in the SDK's [README](https://github.com/auth0/nextjs-auth0#page-router).
+:::
+
+Create a file at `app/api/auth/[auth0]/route.js`. This is your Route Handler file with a [Dynamic Route Segment](https://nextjs.org/docs/app/building-your-application/routing/route-handlers#dynamic-route-segments).
+
+Then, import the `handleAuth` method from the SDK and call it from the `GET` export. This creates the following routes:
+
+- `/api/auth/login`: The route used to perform login with Auth0.
+- `/api/auth/logout`: The route used to log the user out.
+- `/api/auth/callback`: The route Auth0 will redirect the user to after a successful login.
+- `/api/auth/me`: The route to fetch the user profile from.
+
+## Add the `UserProvider` component {{{ data-action=code data-code="app/layout.jsx" }}}
+
+On the frontend side, the SDK uses React Context to manage the authentication state of your users. To make that state available to all your pages, you need to override the [Root Layout component](https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#root-layout-required) and wrap the `` tag with a `UserProvider` in the file `app/layout.jsx`.
+
+The authentication state exposed by `UserProvider` can be accessed in any Client Component using the `useUser()` hook.
+
+::::checkpoint
+:::checkpoint-default
+Now that you have added the route handler and `UserProvider`, run your application to verify that your application is not throwing any errors related to Auth0.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* Are your environment variables populated correctly?
+* did you put the `app/api/auth/[auth0]/route.js` and `app/layout.jsx` files in the correct folder?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add Login to Your Application {{{ data-action=code data-code="app/login.jsx" }}}
+
+Users can now log in to your application by visiting the `/api/auth/login` route handler provided by the SDK. Add a link that points to the login route using an **anchor tag**. Clicking it redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application.
+
+:::note
+Next linting rules might suggest using the `Link` component instead of an anchor tag. The `Link` component is meant to perform [client-side transitions between pages](https://nextjs.org/docs/api-reference/next/link). As the link points to an API route and not to a page, you should keep it as an anchor tag.
+:::
+
+::::checkpoint
+:::checkpoint-default
+Add the login link to your application. 
+- When you click it, verify that your Next.js application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+- Once that's complete, verify that Auth0 redirects back to your application.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure that "Allowed Callback URLs" is configured correctly in your tenant
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application {{{ data-action=code data-code="app/logout.jsx" }}}
+
+Now that you can log in to your Next.js application, you need [a way to log out](https://auth0.com/docs/logout/log-users-out-of-auth0). Add a link that points to the `/api/auth/logout` API route. Clicking it redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them back to your application.
+
+::::checkpoint
+:::checkpoint-default
+Add the logout link to your application. When you click it, verify that your Next.js application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings".
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure that "Allowed Logout URLs" is configured correctly in your tenant
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show User Profile Information from a Client Component{{{ data-action=code data-code="app/profile-client/page.jsx" }}}
+
+The Auth0 Next.js SDK helps you retrieve the [profile information](https://auth0.com/docs/users/user-profiles) associated with the logged-in user, such as their name or profile picture, to personalize the user interface.
+
+The profile information is available through the `user` property exposed by the `useUser()` hook. Take this [Client Component](https://nextjs.org/docs/getting-started/react-essentials#client-components) `ProfileClient` as an example of how to use it.
+
+::::checkpoint
+:::checkpoint-default
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure the SDK has finished loading using the `loading` property
+* make sure there are no errors in the `error` property or the console
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show User Profile Information from a Server Component{{{ data-action=code data-code="app/profile-server/page.jsx" }}}
+
+The profile information is available through the `user` property exposed by the `getSession` function. Take this [Server Component](https://nextjs.org/docs/getting-started/react-essentials#server-components) `ProfileServer` as an example of how to use it.
+
+::::checkpoint
+:::checkpoint-default
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure you have successfully logged in through the `/api/auth/login` handler.
+* make sure there are no errors in the console
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/01-login.md b/fr-ca/articles/quickstart/webapp/nginx-plus/01-login.md
new file mode 100644
index 0000000000..7a72a42e7f
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/01-login.md
@@ -0,0 +1,79 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to use the `nginx-openid-connect` module to add authentication and authorization to your NGINX server.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - nginx
+  - nginx+
+  - nginx plus
+  - login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel System Requirements
+This tutorial and seed project have been tested with the following:
+* NGINX Plus R24
+:::
+
+**Please follow the steps below to configure your application using [NGINX Plus](https://www.nginx.com/products/nginx/) to work with Auth0 and Open ID Connect.**
+
+## Install and Enable `nginx-plus-module-njs` Module
+
+First, you need to install the nginx-plus-module-njs module for NGINX Plus. Follow the [dynamic module installation guide](https://www.nginx.com/products/nginx/dynamic-modules/) to install packages in your host OS. 
+For Linux distributions that use `yum` package manager install as follows:
+
+```bash
+sudo yum install nginx-plus-module-njs jq
+```
+
+Once you've installed it, you need to enable it for NGINX by adding the following line near the top of your `/etc/nginx/nginx.conf` file:
+
+${snippet(meta.snippets.module)}
+
+## Checkout `nginx-openid-connect` Template Repository
+Clone [`nginx-openid-connect` GitHub repository](https://github.com/nginxinc/nginx-openid-connect). This repository comes with a template configuration.
+
+```bash
+git clone https://github.com/nginxinc/nginx-openid-connect
+```
+
+## Configure with Your Auth0 Application Information
+Run the `configure.sh` script inside nginx-openid-connect folder to populate template configuration for your Auth0 application:
+
+${snippet(meta.snippets.setup)}
+
+Next, add your tenant’s logout URL to `openid_connect_configuration.conf` file
+
+${snippet(meta.snippets.logout)}
+
+## Set Accept-Encoding Type for Token and JWKS Endpoints
+
+Add `Accept-Encoding` header in `openid_connect.server_conf`
+
+${snippet(meta.snippets.token)}
+
+## Copy OpenID Connect Config Files to NGINX Server
+
+You need to copy four files to the config folder of NGINX server machine
+
+```bash
+sudo cp openid_connect.js \ 
+   frontend.conf \
+   openid_connect_configuration.conf \
+   openid_connect.server_conf /etc/nginx/conf.d
+```
+        
+## Configuring Auth0 Settings
+
+In your application settings add a new "Allowed Callback URLs" that is equal to `https://server-fqdn/_codexch`.
+
+Then, change "Token Endpoint Authentication Method" to "None" in Auth0 for your Application. This is required for PKCE authorisation code flow.
+
+## Passing Headers to Upstream Application
+Edit `/etc/nginx/conf.d/frontend.conf` and add additional headers from `id_token` to the upstream target:
+
+${snippet(meta.snippets.use)}
diff --git a/fr-ca/articles/quickstart/webapp/nginx-plus/index.yml b/fr-ca/articles/quickstart/webapp/nginx-plus/index.yml
new file mode 100644
index 0000000000..7431ea964a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/index.yml
@@ -0,0 +1,22 @@
+title: NGINX Plus
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/nginx-plus.png
+logo: nginx
+author:
+  name: Amin Abbaspour
+  email: amin.abbaspour@auth0.com
+  community: false
+topics:
+  - quickstart
+snippets:
+  module: server-platforms/nginx-plus/module
+  setup: server-platforms/nginx-plus/setup
+  logout: server-platforms/nginx-plus/logout
+  token: server-platforms/nginx-plus/token
+  use: server-platforms/nginx-plus/use
+seo_alias: nginx
+default_article: 01-login
+articles:
+  - 01-login
+contentType: tutorial
+useCase: quickstart
diff --git a/fr-ca/articles/quickstart/webapp/php/01-login.md b/fr-ca/articles/quickstart/webapp/php/01-login.md
new file mode 100644
index 0000000000..4017d55c00
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/01-login.md
@@ -0,0 +1,216 @@
+---
+title: Login
+default: true
+description: This guide demonstrates how to integrate Auth0 with a PHP application using the Auth0 PHP SDK.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - php
+contentType: tutorial
+useCase: quickstart
+github:
+  path: app
+---
+
+
+<%= include('../_includes/_getting_started', { library: 'PHP', callback: 'http://127.0.0.1:3000/' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://127.0.0.1:3000' }) %>
+
+## Integrate your PHP application
+
+Let's create a sample application that authenticates a user with a PHP application. We'll take a simple approach here, appropriate for the written format. Still, you should check out the accompanying [Quickstart app on GitHub](https://github.com/auth0-samples/auth0-php-web-app/) for a more robust example.
+
+### Installing HTTP Client and Messaging Factories
+
+The Auth0 PHP SDK supports many [PHP-FIG](https://www.php-fig.org) standards offering interoperability options with your architecture. Two of particular importance are [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/). These standards allow you to plug-in networking components of your choice to handle messaging and requests. You will need to install compatible libraries in your project for the SDK to use.
+
+The most prolific networking library for PHP is [Guzzle](https://guzzlephp.org), although many are available to pick from within the PHP community. Let's use Guzzle for this sample application. Once again, from your project directory, run the following shell command:
+
+```sh
+composer require guzzlehttp/guzzle guzzlehttp/psr7 http-interop/http-factory-guzzle
+```
+
+### Installing the PHP SDK
+
+${snippet(meta.snippets.install)}
+
+### Configuring the SDK
+
+To begin, let's create a `.env` file within the root of your project directory to store our sample application's configuration and fill in the environment variables:
+
+```sh
+# Your Auth0 application's Client ID
+AUTH0_CLIENT_ID=${account.clientId}
+
+# The URL of your Auth0 tenant domain
+AUTH0_DOMAIN=${account.namespace}
+
+# Your Auth0 application's Client Secret
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+# A long, secret value used to encrypt the session cookie.
+# This can be generated using `openssl rand -hex 32` from your shell.
+AUTH0_COOKIE_SECRET=
+
+# A url your application is accessible from. Update this as appropriate.
+AUTH0_BASE_URL=http://127.0.0.1:3000
+```
+
+As PHP isn't able to read our `.env` file by itself, we'll want to install a library to help with that. Although we'll be using a particular library for our sample application's purposes, in a real world application any 'dotenv' loader of preference will work. From our project directory, let's run the following shell command to install the library:
+
+```sh
+composer require vlucas/phpdotenv
+```
+
+Next, let's create the PHP source file we'll be using for these code samples, `index.php`, and let's configure an instance of the Auth0 PHP SDK for our sample application:
+
+```php
+load();
+
+// Now instantiate the Auth0 class with our configuration:
+$auth0 = new \Auth0\SDK\Auth0([
+    'domain' => $_ENV['AUTH0_DOMAIN'],
+    'clientId' => $_ENV['AUTH0_CLIENT_ID'],
+    'clientSecret' => $_ENV['AUTH0_CLIENT_SECRET'],
+    'cookieSecret' => $_ENV['AUTH0_COOKIE_SECRET']
+]);
+```
+
+### Setting up your application routes
+
+Modern PHP applications use a routing pattern to pass incoming HTTP requests to the code that handles them, determining what should happen when our users visit a particular "page" in our app. There is no single, correct way of implementing routing in your application, and there are many libraries to choose from to implement it. We'll be using one particular library for our sample application's purposes, but feel free to select your own in a real-world application.
+
+From our project directory, let's run the following shell command to install the routing library:
+
+```sh
+composer require steampixel/simple-php-router
+```
+
+Next, let's open our `index.php` back up and give our application life. Start by importing the routing library and defining our sample application's route's full URLs as named constants for convenience sake, as we'll need to reference them in a few places through our sample application:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// Import our router library:
+use Steampixel\Route;
+
+// Define route constants:
+define('ROUTE_URL_INDEX', rtrim($_ENV['AUTH0_BASE_URL'], '/'));
+define('ROUTE_URL_LOGIN', ROUTE_URL_INDEX . '/login');
+define('ROUTE_URL_CALLBACK', ROUTE_URL_INDEX . '/callback');
+define('ROUTE_URL_LOGOUT', ROUTE_URL_INDEX . '/logout');
+```
+
+Now we can move on to adding our application's route handling logic, and the SDK integrations:
+
+## Checking for a session
+
+The Auth0 PHP SDK has a convenient method for checking if our user has authenticated and returned their profile, `getCredentials()`. Let's install this on our index route to print the user profile if they're logged in or report that they need to login.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/', function() use ($auth0) {
+  $session = $auth0->getCredentials();
+
+  if ($session === null) {
+    // The user isn't logged in.
+    echo '
    Please log in.
    ';
+    return;
+  }
+
+  // The user is logged in.
+  echo '
    ';
+  print_r($session->user);
+  echo '
    ';
+
+  echo '
    You can now log out.
    ';
+});
+```
+
+We can access all the properties of our user's profile from the `user` property response, which is an array. So, for example, we can pull the user's nickname using `$session->user['nickname']`, or their email address from `$session->user['email']`. The structure is a [normalized user profile](https://auth0.com/docs/users/user-profile-structure), which you can learn more about [here](https://auth0.com/docs/users/normalized-user-profiles).
+
+It's important to note that the content of the user profile will vary depending on the social provider(s) you use, so you should never assume that a particular value will always be there within your application logic. Use PHP language constructs like `isset` or null coalescence to gracefully handle a value's presence, or lack thereof, for example:
+
+```PHP
+// ✋ We don't need to include this in our sample application, it's just an example.
+$name = $session->user['name'] ?? $session->user['nickname'] ?? $session->user['email'] ?? 'Unknown';
+```
+
+## Logging in
+
+Now let's create our /login route, which will use the Auth0 PHP SDK's `login()` method to set up the user session and return a customized URL to Auth0's Universal Login Page for this user to login.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/login', function() use ($auth0) {
+    // It's a good idea to reset user sessions each time they go to login to avoid "invalid state" errors, should they hit network issues or other problems that interrupt a previous login process:
+    $auth0->clear();
+
+    // Finally, set up the local application session, and redirect the user to the Auth0 Universal Login Page to authenticate.
+    header("Location: " . $auth0->login(ROUTE_URL_CALLBACK));
+    exit;
+});
+```
+
+## Handling authentication callback
+
+After our users return from authenticating with the Auth0's Universal Login Page, they'll return to our sample application at our callback route, `/callback` which we'll handle in this step.
+
+When Auth0 passes our users back to us, it includes a few essential parameters in the query of the HTTP request. The Auth0 PHP SDK's `exchange()` method handles working with those, so finishing our authentication flow is straightforward:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/callback', function() use ($auth0) {
+    // Have the SDK complete the authentication flow:
+    $auth0->exchange(ROUTE_URL_CALLBACK);
+
+    // Finally, redirect our end user back to the / index route, to display their user profile:
+    header("Location: " . ROUTE_URL_INDEX);
+    exit;
+});
+```
+
+## Logging out
+
+Last but not least, let's properly handle logging our users out. The `logout()` method of the Auth0 PHP SDK handles clearing our sample application's session cookies, redirecting the user to Auth0's [/logout endpoint](https://auth0.com/docs/logout) (which logs out Auth0 session layer and any identify provider session layers), and then return the user to our / index route.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/logout', function() use ($auth0) {
+    // Clear the user's local session with our app, then redirect them to the Auth0 logout endpoint to clear their Auth0 session.
+    header("Location: " . $auth0->logout(ROUTE_URL_INDEX));
+    exit;
+});
+```
+
+## Run your app!
+
+Last but not least, we need to tell our routing middleware to actually route requests:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// This tells our router that we've finished configuring our routes, and we're ready to begin routing incoming HTTP requests:
+Route::run('/');
+```
+
+That's it! You're ready to run your new application; once again, from your project directory, run the following shell command:
+
+```sh
+php -S 127.0.0.1:3000 index.php
+```
+
+Open your browser to http://127.0.0.1:3000 and try it out.
diff --git a/fr-ca/articles/quickstart/webapp/php/download.md b/fr-ca/articles/quickstart/webapp/php/download.md
new file mode 100644
index 0000000000..f7fe450755
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/download.md
@@ -0,0 +1,25 @@
+To run the sample follow these steps:
+
+1. Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://127.0.0.1:3000/callback
+```
+
+2. Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://127.0.0.1:3000/logout
+```
+
+3. Make sure [PHP](http://php.net/downloads.php) and [Composer](https://getcomposer.org/download/) are installed and execute the following commands in the sample's directory:
+
+```bash
+composer run app
+```
+
+You can also run it from [Docker](https://www.docker.com) with the following commands:
+
+```bash
+composer run docker
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/files/callback.md b/fr-ca/articles/quickstart/webapp/php/files/callback.md
new file mode 100644
index 0000000000..6d75868f9c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/files/callback.md
@@ -0,0 +1,39 @@
+---
+name: callback.php
+language: php
+---
+
+```php
+exchange();
+    } catch (\Throwable $th) {
+      printf('Unable to complete authentication: %s', $th->getMessage());
+      exit;
+    }
+  }
+
+  // When authentication was unsuccessful, the end user will be returned with an ?error in their request.
+  if ($hasAuthenticationFailure) {
+    printf('Authentication failure: %s', htmlspecialchars(strip_tags(filter_input(INPUT_GET, 'error'))));
+    exit;
+  }
+
+  // Nothing to do: redirect to index route.
+  header('Location: /');
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/files/index.md b/fr-ca/articles/quickstart/webapp/php/files/index.md
new file mode 100644
index 0000000000..f68135b6cd
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/files/index.md
@@ -0,0 +1,27 @@
+---
+name: index.php
+language: php
+---
+
+```php
+login()));
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/files/logout.md b/fr-ca/articles/quickstart/webapp/php/files/logout.md
new file mode 100644
index 0000000000..e497de4cf5
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/files/logout.md
@@ -0,0 +1,18 @@
+---
+name: logout.php
+language: php
+---
+
+```php
+logout()));
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/files/profile.md b/fr-ca/articles/quickstart/webapp/php/files/profile.md
new file mode 100644
index 0000000000..1b5c48b9c6
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/files/profile.md
@@ -0,0 +1,25 @@
+---
+name: profile.php
+language: php
+---
+
+```php
+getCredentials();
+  $authenticated = $session !== null;
+
+  $template = [
+    'name' => $authenticated ? $session->user['email'] : 'guest',
+    'picture' => $authenticated ? $session->user['picture'] : null,
+    'session' => $authenticated ? print_r($session, true) : '',
+    'auth:route' => $authenticated ? 'logout' : 'login',
+    'auth:text' => $authenticated ? 'out' : 'in',
+  ];
+
+  printf('
    Welcome, %s.
    ', $template['name']);
+  printf('
    %s
    ', $template['session']);
+  printf('
    Log %s
    ', $template['auth:route'], $template['auth:text']);
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/files/router.md b/fr-ca/articles/quickstart/webapp/php/files/router.md
new file mode 100644
index 0000000000..ca4bf82b9b
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/files/router.md
@@ -0,0 +1,34 @@
+---
+name: router.php
+language: php
+---
+
+```php
+This quickstart is configured to be run from http://localhost:3000.
    ');
+  }
+
+  Route::add('/', function() use ($sdk) {
+    require('profile.php');
+  });
+
+  Route::add('/login', function() use ($sdk) {
+    require('login.php');
+  });
+
+  Route::add('/callback', function() use ($sdk) {
+    require('callback.php');
+  });
+
+  Route::add('/logout', function() use ($sdk) {
+    require('logout.php');
+  });
+
+  Route::run();
+```
diff --git a/fr-ca/articles/quickstart/webapp/php/index.yml b/fr-ca/articles/quickstart/webapp/php/index.yml
new file mode 100644
index 0000000000..2613a515a4
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/index.yml
@@ -0,0 +1,53 @@
+title: PHP
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: php
+seo_alias: php
+alias:
+  - php
+languages:
+  - PHP
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  install: server-platforms/php/install
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - 'interactive'
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-php-web-app
+  branch: main
+sdk:
+  name: Auth0-PHP
+  url: https://github.com/auth0/auth0-php
+  logo: php
+requirements:
+  - PHP 7.4+ (8.0 recommended)
+  - Auth0-PHP 8.0
+  - Composer
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/fr-ca/articles/quickstart/webapp/php/interactive.md b/fr-ca/articles/quickstart/webapp/php/interactive.md
new file mode 100644
index 0000000000..c127953da3
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/php/interactive.md
@@ -0,0 +1,194 @@
+---
+title: Add Login to your PHP application
+description: "Auth0 allows you to add authentication to your PHP application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing PHP application using the Auth0 PHP SDK."
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+  - files/router
+  - files/callback
+github:
+  path: app
+---
+
+# Add Login to Your PHP Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any PHP application using the Auth0 PHP SDK.
+
+To use this quickstart, you’ll need to:
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working PHP project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/callback.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000.
+:::
+
+### Configure Allowed Web Origins
+
+An Allowed Web Origin is a URL that you want to be allowed to access to your authentication flow. This must contain the URL of your project. If not properly set, your project will be unable to silently refresh authentication tokens, so your users will be logged out the next time they visit your application or refresh a page.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000.
+:::
+
+## Install the Auth0 PHP SDK {{{ data-action=code data-code="index.php" }}}
+
+Auth0 provides a [PHP SDK](https://github.com/auth0/auth0-PHP) (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps.
+
+The Auth0 PHP SDK requires [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/) compatible HTTP libraries to be installed for managing network requests. If you don't have libraries available, you can install reliable choices by running the following commands in your terminal:
+
+```bash
+cd 
+composer require symfony/http-client nyholm/psr7
+```
+
+Now install the Auth0 PHP SDK by running the following command in your terminal:
+
+```bash
+composer require auth0/auth0-php
+```
+
+### Configure the Auth0 SDK
+
+Create a new file in your application called `index.php`, and copy in the code from the interactive panel to the right under the index.php tab.
+
+For the SDK to function properly, you must set the following properties in the Auth0 SDK during initialization:
+
+- `domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- `clientSecret`: The secret of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client Secret field.
+- `redirectUri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. You can also find this value in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error.
+- `cookieSecret`: A long secret value used to encrypt the session cookie. You can generate a suitable string by running `openssl rand -hex 32` in your terminal.
+
+::::checkpoint
+:::checkpoint-default
+
+Your Auth0 SDK should now be properly configured. Run your application to verify that:
+- The SDK is initializing correctly.
+- Your application is not throwing any errors related to Auth0.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* Make sure the correct application is selected.
+* Did you save after entering your URLs?
+* Make sure the domain and client ID imported correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Create routes {{{ data-action=code data-code="router.php" }}}
+
+Now install a routing library, to help direct incoming requests to your application. This isn't a required step, but simplifies our application structure for the purposes of this quickstart.
+
+```bash
+composer require steampixel/simple-php-router
+```
+
+Create a new file in your application called `router.php` to define our routes, and copy in the code from the interactive panel to the right.
+
+## Add login to your application {{{ data-action=code data-code="login.php" }}}
+
+Now that you have configured your Auth0 Application and the Auth0 PHP SDK, you need to set up login for your project. To do this, you will use the SDK’s `login()` method to create a login button that redirects users to the Auth0 Universal Login page. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+Create a new file in your application called `login.php` to handle logging process, and copy in the code from the interactive panel to the right, which contains the logic needed for login.
+
+::::checkpoint
+:::checkpoint-default
+
+You should now be able to log in or sign up using a username and password.
+
+Click the login link and verify that:
+* Your application redirects you to the Auth0 Universal Login page.
+* You can log in or sign up.
+* Auth0 redirects you back to your application using the value of the `redirectUri` you used to configure the SDK.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You configured the correct `redirectUri`.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout.php" }}}
+
+Users who log in to your project will also need a way to log out. We will handle a logout button using the SDK’s `logout()` method. When users log out, they will be redirected to your [Auth0 logout](https://auth0.com/docs/api/authentication?http#logout) endpoint, which will then immediately redirect them to the logout URL you set up earlier in this quickstart.
+
+Create a new file in your application called `logout.php` for handling the process, and copy in the code from the interactive panel, which contains the logic needed for logout. Then, update your `index.php` file to include the logout button.
+
+::::checkpoint
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* Your application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings.
+* You are no longer logged in to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You configured the correct Logout URL.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show User Profile Information {{{ data-action=code data-code="profile.php" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 PHP SDK provides user information through the `getCredentials()` method. Review the `profile.php` code in the interactive panel to see an example of how to use it.
+
+Because the method contains sensitive information related to the user's identity, its availability depends on the user's authentication status. To prevent render errors, you should always check if the `getCredentials()` method returns an `object` or `null` to determine whether Auth0 has authenticated the user before your application consumes the results.
+
+::::checkpoint
+:::checkpoint-default
+
+Verify that:
+* You can display the `nickname` or any other user property correctly after you have logged in.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You created the `profile.php` file and are logged in.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
diff --git a/fr-ca/articles/quickstart/webapp/python/01-login.md b/fr-ca/articles/quickstart/webapp/python/01-login.md
new file mode 100644
index 0000000000..0a570d856c
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/01-login.md
@@ -0,0 +1,219 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login to a Python web Application built with the Flask framework and Authlib OAuth library.
+budicon: 448
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - flask
+github:
+    path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Python', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install dependencies
+
+For the purposes of this example, we'll be using the [Authlib](https://authlib.org/) OAuth library and [Flask](https://flask.palletsprojects.com/en/2.0.x/).
+
+Begin by creating a `requirements.txt` file in your project directory:
+
+```python
+# 📁 requirements.txt -----
+
+flask>=2.0.3
+python-dotenv>=0.19.2
+authlib>=1.0
+requests>=2.27.1
+```
+
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+APP_SECRET_KEY=
+
+```
+
+- Generate a suitable string for `APP_SECRET_KEY` using `openssl rand -hex 32` from your shell.
+
+## Setup your application
+
+Now you're ready to start writing your application. Create a `server.py` file in your project directory - this file will hold all of your application logic.
+
+Begin by importing all the libraries your application will be making use of:
+
+```python
+# 📁 server.py -----
+
+import json
+from os import environ as env
+from urllib.parse import quote_plus, urlencode
+
+from authlib.integrations.flask_client import OAuth
+from dotenv import find_dotenv, load_dotenv
+from flask import Flask, redirect, render_template, session, url_for
+```
+
+Next, your application will need to load the configuration `.env` file you made in the previous step:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+```
+
+Now you can configure Flask for your application's needs:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+app = Flask(__name__)
+app.secret_key = env.get("APP_SECRET_KEY")
+```
+
+Finally, you can now configure Authlib to handle your application's authentication with Auth0:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+oauth = OAuth(app)
+
+oauth.register(
+    "auth0",
+    client_id=env.get("AUTH0_CLIENT_ID"),
+    client_secret=env.get("AUTH0_CLIENT_SECRET"),
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f'https://{env.get("AUTH0_DOMAIN")}/.well-known/openid-configuration'
+)
+```
+
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your routes
+
+For this demonstration, we'll be adding 4 routes for your application: your login, callback, logout and home routes.
+
+### Triggering authentication with `/login`
+When visitors to your app visit the `/login` route, they'll be redirected to Auth0 to begin the authentication flow.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/login")
+def login():
+    return oauth.auth0.authorize_redirect(
+        redirect_uri=url_for("callback", _external=True)
+    )
+```
+
+### Finalizing authentication with `/callback`
+After your users finish logging in with Auth0, they'll be returned to your application at the `/callback` route. This route is responsible for actually saving the session for the user, so when they visit again later, they won't have to sign back in all over again.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/callback", methods=["GET", "POST"])
+def callback():
+    token = oauth.auth0.authorize_access_token()
+    session["user"] = token
+    return redirect("/")
+```
+
+### Clearing a session with `/logout`
+As you might expect, this route handles signing a user out from your application. It will clear the user's session in your app, and briefly redirect to Auth0's logout endpoint to ensure their session is completely clear, before they are returned to your home route (covered next.)
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/logout")
+def logout():
+    session.clear()
+    return redirect(
+        "https://" + env.get("AUTH0_DOMAIN")
+        + "/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": url_for("home", _external=True),
+                "client_id": env.get("AUTH0_CLIENT_ID"),
+            },
+            quote_via=quote_plus,
+        )
+    )
+```
+
+### There's no place like `/home`
+Last but not least, your home route will serve as a place to either render an authenticated user's details, or offer to allow visitors to sign in.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/")
+def home():
+    return render_template("home.html", session=session.get('user'), pretty=json.dumps(session.get('user'), indent=4))
+```
+
+### Server instantiation
+Finally, you'll need to add some small boilerplate code for Flask to actually run your app and listen for connections.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+if __name__ == "__main__":
+    app.run(host="0.0.0.0", port=env.get("PORT", 3000))
+```
+
+## Add templates
+
+Now we just need to create the simple template files used in the routes about (during `render_template()` calls).
+
+Create a new sub-directory in your project folder named `templates`, and create two files within: `dashboard.html` and `home.html`. You can paste the content from the two fields below into those files, respectfully:
+
+```html
+# 📁 templates/home.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+        
    Welcome {{session.userinfo.name}}!
    
+        
    Logout
    
+        
    {{pretty}}
    
+    {% else %}
+        
    Welcome Guest
    
+        
    Login
    
+    {% endif %}
+  
+
+```
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 server.py
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
diff --git a/fr-ca/articles/quickstart/webapp/python/download.md b/fr-ca/articles/quickstart/webapp/python/download.md
new file mode 100644
index 0000000000..588081ac0e
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/download.md
@@ -0,0 +1,27 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000
+```
+
+3) Make sure [Python](https://www.python.org/downloads/) is installed and execute the following commands in the sample's directory:
+```bash
+pip install -r requirements.txt
+python3 server.py
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/fr-ca/articles/quickstart/webapp/python/files/home.md b/fr-ca/articles/quickstart/webapp/python/files/home.md
new file mode 100644
index 0000000000..8a0f7e8dc5
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/files/home.md
@@ -0,0 +1,25 @@
+---
+name: templates/home.html
+language: html
+---
+
+
+
+```html
+
+
+  
+  Auth0 Example
+
+
+  {% if session %}
+      
    Welcome {{session.userinfo.name}}!
    
+      
    Logout
    
+      
    {{pretty}}
    
+  {% else %}
+    
    Welcome Guest
    
+    
    Login
    
+  {% endif %}
+
+
+```
diff --git a/fr-ca/articles/quickstart/webapp/python/files/server.md b/fr-ca/articles/quickstart/webapp/python/files/server.md
new file mode 100644
index 0000000000..d0fd583839
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/files/server.md
@@ -0,0 +1,72 @@
+---
+name: server.py
+language: python
+---
+
+
+
+```python
+import json
+from os import environ as env
+from urllib.parse import quote_plus, urlencode
+
+from authlib.integrations.flask_client import OAuth
+from dotenv import find_dotenv, load_dotenv
+from flask import Flask, redirect, render_template, session, url_for
+
+
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+    
+app = Flask(__name__)
+app.secret_key = env.get("APP_SECRET_KEY")
+
+oauth = OAuth(app)
+
+oauth.register(
+    "auth0",
+    client_id=env.get("AUTH0_CLIENT_ID"),
+    client_secret=env.get("AUTH0_CLIENT_SECRET"),
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f'https://{env.get("AUTH0_DOMAIN")}/.well-known/openid-configuration'
+)
+
+
+@app.route("/login")
+def login():
+    return oauth.auth0.authorize_redirect(
+        redirect_uri=url_for("callback", _external=True)
+    )
+
+@app.route("/callback", methods=["GET", "POST"])
+def callback():
+    token = oauth.auth0.authorize_access_token()
+    session["user"] = token
+    return redirect("/")
+
+@app.route("/logout")
+def logout():
+    session.clear()
+    return redirect(
+        "https://" + env.get("AUTH0_DOMAIN")
+        + "/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": url_for("home", _external=True),
+                "client_id": env.get("AUTH0_CLIENT_ID"),
+            },
+            quote_via=quote_plus,
+        )
+    )
+
+@app.route("/")
+def home():
+    return render_template("home.html", session=session.get('user'), pretty=json.dumps(session.get('user'), indent=4))
+
+
+if __name__ == "__main__":
+    app.run(host="0.0.0.0", port=env.get("PORT", 3000))
+```
diff --git a/fr-ca/articles/quickstart/webapp/python/index.yml b/fr-ca/articles/quickstart/webapp/python/index.yml
new file mode 100644
index 0000000000..b94c1a9d6d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/index.yml
@@ -0,0 +1,50 @@
+title: Python
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/python.png
+logo: python
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-platforms/python/dependencies
+  setup: server-platforms/python/setup
+  use: server-platforms/python/use
+seo_alias: python
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-python-web-app
+  branch: master
+sdk:
+  name: auth0-python
+  url: https://github.com/auth0/auth0-python
+  logo: python
+requirements:
+  - Python 3
+  - Authlib 1.0
+  - Flask 2.0
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/fr-ca/articles/quickstart/webapp/python/interactive.md b/fr-ca/articles/quickstart/webapp/python/interactive.md
new file mode 100644
index 0000000000..50d2735b13
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/python/interactive.md
@@ -0,0 +1,114 @@
+---
+title: Add login to your Python Flask app
+description: This tutorial demonstrates how to add user login to a Python web application built with the Flask framework and Authlib OAuth library.
+interactive: true
+files:
+- files/server
+- files/home
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - flask
+github:
+  path: 01-Login
+---
+
+
+
+# Add Login to Your Python Flask Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with a Python [Flask](https://flask.palletsprojects.com) application using the [Authlib](https://authlib.org/) SDK.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies
+
+Create a `requirements.txt` file in your project directory:
+
+```python
+# 📁 requirements.txt -----
+
+flask>=2.0.3
+python-dotenv>=0.19.2
+authlib>=1.0
+requests>=2.27.1
+```
+
+Run the following command from your shell to enable these dependencies in your project:
+
+```sh
+pip install -r requirements.txt
+```
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+APP_SECRET_KEY=
+```
+
+- Generate a string for `APP_SECRET_KEY` using `openssl rand -hex 32` from your shell.
+
+## Setup your application {{{ data-action=code data-code="server.py#1:27" }}}
+
+Next, set up your application. Create a `server.py` file in your project directory - this file will contain your application logic.
+
+Import all the libraries your application needs.
+
+Load the configuration `.env` file you made in the previous step.
+
+Configure Authlib to handle your application's authentication with Auth0. To learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your routes {{{ data-action=code data-code="server.py#30:59" }}}
+
+In this example, you will add four routes to the application: login, callback, logout, and home.
+
+When visitors to your app visit the `/login` route, your application will route them to the Auth0 login page.
+
+After your users log in with Auth0, your application will route them to the `/callback` route. This route saves the session for the user and bypasses the need for them to login again when they return.
+
+The `/logout` route signs users out from your application. This route clears the user session in your app and redirects to the Auth0 logout endpoint to ensure the session is no longer saved. Then, the application redirects the user to your home route.
+
+Your `/ ` home route either renders an authenticated user's details or  allows visitors to sign in.
+
+## Add templates {{{ data-action=code data-code="templates/home.html" }}}
+
+Next, create the template file used in the home route (during `render_template()` calls).
+
+Create a new sub-directory in your project folder named `templates`, and create `home.html`  in the directory. Paste the content from the right into that file.
+
+## Run your application
+
+To run your application, navigate to the root of your project directory and open a terminal. Run the following command:
+
+```sh
+python3 server.py
+```
+
+::::checkpoint
+:::checkpoint-default
+Visit [http://localhost:3000](http://localhost:3000) to verify. You should find a login button routing to Auth0 for login, then back to your application to see your profile information.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify any errors in the console.
+* Verify the domain and Client ID imported correctly.
+* Verify your tenant configuration.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/fr-ca/articles/quickstart/webapp/rails/01-login.md b/fr-ca/articles/quickstart/webapp/rails/01-login.md
new file mode 100644
index 0000000000..ac61efa322
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/01-login.md
@@ -0,0 +1,197 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Ruby on Rails application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - rails
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_getting_started', { library: 'Rails', callback: 'http://localhost:3000/auth/auth0/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install the Auth0 SDK
+
+### Install Dependencies
+
+This tutorial uses `omniauth-auth0`, a custom [OmniAuth strategy](https://github.com/intridea/omniauth#omniauth-standardized-multi-provider-authentication), to handle the authentication flow.  Add the following dependencies to your `Gemfile`:
+
+```ruby
+gem 'omniauth-auth0', '~> 3.0'
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+```
+
+Once your gems are added, install the gems with `bundle install`:
+
+### Initialize Auth0 Configuration
+
+Create an Auth0 config file `./config/auth0.yml`
+
+```yaml
+# ./config/auth0.yml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: 
+```
+
+Create the following initializer file `./config/initializers/auth0.rb` and [configure](https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#send-additional-authentication-parameters) the **OmniAuth** middleware.
+
+```ruby
+# ./config/initializers/auth0.rb
+AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+Rails.application.config.middleware.use OmniAuth::Builder do
+  provider(
+    :auth0,
+    AUTH0_CONFIG['auth0_client_id'],
+    AUTH0_CONFIG['auth0_client_secret'],
+    AUTH0_CONFIG['auth0_domain'],
+    callback_path: '/auth/auth0/callback',
+    authorize_params: {
+      scope: 'openid profile'
+    }
+  )
+end
+```
+
+### Add an Auth0 controller
+Create an Auth0 controller for handling the authentication callback. Run the command `rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine`. 
+
+Inside of the callback method assign the hash of user information, returned as `request.env['omniauth.auth']`, to the active session.
+
+```ruby
+# ./app/controllers/auth0_controller.rb
+class Auth0Controller < ApplicationController
+  def callback
+    # OmniAuth stores the information returned from Auth0 and the IdP in request.env['omniauth.auth'].
+    # In this code, you will pull the raw_info supplied from the id_token and assign it to the session.
+    # Refer to https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#example-of-the-resulting-authentication-hash for complete information on 'omniauth.auth' contents.
+    auth_info = request.env['omniauth.auth']
+    session[:userinfo] = auth_info['extra']['raw_info']
+
+    # Redirect to the URL you want after successful auth
+    redirect_to '/dashboard'
+  end
+
+  def failure
+    # Handles failed authentication -- Show a failure page (you can also handle with a redirect)
+    @error_msg = request.params['message']
+  end
+
+  def logout
+    # you will finish this in a later step
+  end
+end
+```
+
+Add the following routes to your `./config/routes.rb` file:
+
+```ruby
+# ./config/routes.rb
+Rails.application.routes.draw do
+  # ..
+  get '/auth/auth0/callback' => 'auth0#callback'
+  get '/auth/failure' => 'auth0#failure'
+  get '/auth/logout' => 'auth0#logout'
+end
+```
+
+## Add Login to Your Application
+A user can now log into your application by visiting the `/auth/auth0` endpoint.
+
+::: warning
+To [prevent forged authentication requests](https://github.com/cookpad/omniauth-rails_csrf_protection), use the `link_to` or `button_to` helper methods with the `:post` method
+:::
+
+```erb
+  
+  ${"<%= button_to 'Login', '/auth/auth0', method: :post, data: \{ turbo: false \} %>"}
+```
+
+## Add Logout to Your Application
+Now that you can log in to your Rails application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Revisit the Auth0Controller you created earlier, and finish up the logout method added there.
+
+You will need to clear out your session and then redirect the user to the Auth0 logout endpoint.
+
+To clear out all the objects stored within the session, call the `reset_session` method within the `auth0_controller/logout` method. [Learn more about reset_session here](http://api.rubyonrails.org/classes/ActionController/Base.html#M000668).  Add the following code to `./app/controllers/auth0_controller.rb`:
+
+```ruby
+# ./app/controllers/auth0_controller.rb
+class Auth0Controller < ApplicationController
+  # ..
+  # ..Insert the code below
+  def logout
+    reset_session
+    redirect_to logout_url, allow_other_host: true
+  end
+
+  private
+
+  def logout_url
+    request_params = {
+      returnTo: root_url,
+      client_id: AUTH0_CONFIG['auth0_client_id']
+    }
+
+    URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: request_params.to_query).to_s
+  end
+end
+```
+
+::: note
+The final destination URL (the `returnTo` value) needs to be in the list of `Allowed Logout URLs` . See the [logout documentation](/logout/guides/redirect-users-after-logout) for more.
+:::
+
+The user will now be able to logout of your application by visiting the `/auth/logout` endpoint.
+
+```erb
+  
+  ${"<%= button_to 'Logout', 'auth/logout', method: :get, data: \{ turbo: false \} %>"}
+```
+
+## Show User Profile Information
+To display the user's profile, your application should provide a protected route. You can use a controller `concern` to control access to routes. Create the following file `./app/controllers/concerns/secured.rb`
+
+```ruby
+# ./app/controllers/concerns/secured.rb
+module Secured
+  extend ActiveSupport::Concern
+
+  included do
+    before_action :logged_in_using_omniauth?
+  end
+
+  def logged_in_using_omniauth?
+    redirect_to '/' unless session[:userinfo].present?
+  end
+end
+```
+
+After you have created the secured controller concern, include it in any controller that requires a logged in user. You can then access the user from the session `session[:userinfo]`.
+
+```ruby
+# ./app/controllers/dashboard_controller.rb
+class DashboardController < ApplicationController
+  include Secured
+
+  def show
+    # session[:userinfo] was saved earlier on Auth0Controller#callback
+    @user = session[:userinfo]
+  end
+end
+```
+
+Now that you have loaded the user from the session, you can use it to display information in your frontend.
+```erb
+
+
    
+  
    Normalized User Profile:${"<%= JSON.pretty_generate(@user[:info])%>"}
    
+  
    Full User Profile:${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}
    
+
    
+```
diff --git a/fr-ca/articles/quickstart/webapp/rails/02-troubleshooting.md b/fr-ca/articles/quickstart/webapp/rails/02-troubleshooting.md
new file mode 100644
index 0000000000..7300a3beae
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/02-troubleshooting.md
@@ -0,0 +1,118 @@
+---
+title: Troubleshooting
+description: Troubleshooting tips for using Rails with Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - rails
+contentType: tutorial
+useCase: quickstart
+---
+
+# Troubleshooting
+
+The following are troubleshooting topics that you might run into when using the Rails quickstart.
+
+## Using a reverse proxy
+
+The `redirect_uri` parameter that OmniAuth generates when redirecting to login is based on the `Host` header that is passed to Rails. This can cause incorrect callback URLs to be passed when using this strategy (and OmniAuth in general) with a reverse proxy. You can adjust the host used by OmniAuth with the following snippet:
+
+```ruby
+OmniAuth.config.full_host = lambda do |env|
+    scheme         = env['rack.url_scheme']
+    local_host     = env['HTTP_HOST']
+    forwarded_host = env['HTTP_X_FORWARDED_HOST']
+    forwarded_host.blank? ? "#{scheme}://#{local_host}" : "#{scheme}://#{forwarded_host}"
+end
+```
+
+[See this StackOverflow thread for more information](https://stackoverflow.com/a/7135029/728480). 
+
+## ActionController::InvalidAuthenticityToken
+
+This is likely caused by a missing CSRF token needed to POST the login request. If you inspect the login button in your browser, you should see something like this:
+
+```html
+Login
+```
+
+... and in the `` element for the page, you should have CSRF meta tags like these:
+
+```html
+
+
+```
+
+With those elements in place, Rails will convert the login link to POST the CSRF token to the backend to verify it before redirecting to login.
+
+## ActionDispatch::Cookies::CookieOverflow
+
+This error means that a cookie session is being used and because the whole profile is being stored, it overflows the max-size of 4 kb. If you are unable to access the user profile, or you get an error similar to `NoMethodError`, `undefined method '[]' for nil:NilClass`, try using In-Memory store for development.
+
+Go to `/config/initializers/session_store.rb` (or create it if it does not exist) and add the following:
+
+```ruby
+Rails.application.config.session_store :cache_store
+```
+
+Go to `/config/environments/development.rb` and add the following:
+
+```ruby
+config.cache_store = :memory_store
+```
+
+Restart your Rails server for these changes to take effect.
+
+:::note
+It is recommended that a memory store, such as MemCached, is being used for production applications.
+:::
+
+## SSL Issues
+
+Under some configurations, Ruby may not be able to find certification authority certificates (CA certs).
+
+Download the CA certs bundle to the project directory:
+
+```bash
+curl -L -o lib/ca-bundle.crt http://curl.haxx.se/ca/ca-bundle.crt
+```
+
+Add this initializer to `config/initializers/fix_ssl.rb`:
+
+```ruby
+# config/initializers/fix_ssl.rb
+
+require 'open-uri'
+require 'net/https'
+
+module Net
+  class HTTP
+    alias_method :original_use_ssl=, :use_ssl=
+
+    def use_ssl=(flag)
+      path = ( Rails.env == "development") ? "lib/ca-bundle.crt" : "/usr/lib/ssl/certs/ca-certificates.crt"
+      self.ca_file = Rails.root.join(path).to_s
+      self.verify_mode = OpenSSL::SSL::VERIFY_PEER
+      self.original_use_ssl = flag
+    end
+  end
+end
+```
+
+## "failure message=invalid_credentials"
+
+This issue doesn't occur when working locally but may happen in a staging or production environment. The error message may be displayed as:
+
+```
+omniauth: (auth0) Authentication failure! invalid_credentials: OAuth2::Error, server_error: The redirect URI is wrong. You send [wrong url], and we expected [callback url set in your app settings]
+```
+
+To solve this, add the following to `config/environments/staging.rb` or `production.rb`:
+
+```ruby
+OmniAuth.config.full_host = "http://www.example.com"
+```
+
+Substitute `http://www.example.com` with the actual URL you'll be using in your application.
diff --git a/fr-ca/articles/quickstart/webapp/rails/download.md b/fr-ca/articles/quickstart/webapp/rails/download.md
new file mode 100644
index 0000000000..df98776181
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/auth/auth0/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+ ```text
+http://localhost:3000
+```
+
+3) Make sure [Rails](http://installrails.com/) is installed and execute the following commands in the sample's directory:
+
+```bash
+bundle install
+rails s --port 3000
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/concern.md b/fr-ca/articles/quickstart/webapp/rails/files/concern.md
new file mode 100644
index 0000000000..a3782a7023
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/concern.md
@@ -0,0 +1,18 @@
+---
+name: secured.rb
+language: ruby
+---
+
+```ruby
+module Secured
+  extend ActiveSupport::Concern
+
+  included do
+    before_action :logged_in_using_omniauth?
+  end
+
+  def logged_in_using_omniauth?
+    redirect_to '/' unless session[:userinfo].present?
+  end
+end
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/config.md b/fr-ca/articles/quickstart/webapp/rails/files/config.md
new file mode 100644
index 0000000000..b838b819bf
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/config.md
@@ -0,0 +1,11 @@
+---
+name: config/auth0.yml
+language: yml
+---
+
+```yaml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: 
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/controller.md b/fr-ca/articles/quickstart/webapp/rails/files/controller.md
new file mode 100644
index 0000000000..610d4a7ab0
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/controller.md
@@ -0,0 +1,48 @@
+---
+name: auth0_controller.rb
+language: ruby
+---
+
+```ruby
+class Auth0Controller < ApplicationController
+  def callback
+    # OmniAuth stores the informatin returned from
+    # Auth0 and the IdP in request.env['omniauth.auth'].
+    # In this code, you will pull the raw_info supplied 
+    # from the id_token and assign it to the session.
+    # Refer to https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#example-of-the-resulting-authentication-hash 
+    # for complete information on 'omniauth.auth' contents.
+    auth_info = request.env['omniauth.auth']
+    session[:userinfo] = auth_info['extra']['raw_info']
+
+    # Redirect to the URL you want after successful auth
+    redirect_to '/dashboard'
+  end
+
+  def failure
+    # Handles failed authentication
+    @error_msg = request.params['message']
+  end
+
+  def logout
+    reset_session
+    redirect_to logout_url
+  end
+
+  private
+  AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+  def logout_url
+    request_params = {
+      returnTo: root_url,
+      client_id: AUTH0_CONFIG['auth0_client_id']
+    }
+
+    URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: to_query(request_params)).to_s
+  end
+
+  def to_query(hash)
+    hash.map { |k, v| "#{k}=#{CGI.escape(v)}" unless v.nil? }.reject(&:nil?).join('&')
+  end
+end
+```
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/initializer.md b/fr-ca/articles/quickstart/webapp/rails/files/initializer.md
new file mode 100644
index 0000000000..a1695fdefc
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/initializer.md
@@ -0,0 +1,21 @@
+---
+name: auth0.rb
+language: ruby
+---
+
+```ruby
+AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+Rails.application.config.middleware.use OmniAuth::Builder do
+  provider(
+    :auth0,
+    AUTH0_CONFIG['auth0_client_id'],
+    AUTH0_CONFIG['auth0_client_secret'],
+    AUTH0_CONFIG['auth0_domain'],
+    callback_path: '/auth/auth0/callback',
+    authorize_params: {
+      scope: 'openid profile'
+    }
+  )
+end
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/rails/files/routes.md b/fr-ca/articles/quickstart/webapp/rails/files/routes.md
new file mode 100644
index 0000000000..209615d89a
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/files/routes.md
@@ -0,0 +1,13 @@
+---
+name: routes.rb
+language: ruby
+---
+
+```ruby
+Rails.application.routes.draw do
+  # ..
+  get '/auth/auth0/callback' => 'auth0#callback'
+  get '/auth/failure' => 'auth0#failure'
+  get '/auth/logout' => 'auth0#logout'
+end
+```
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/webapp/rails/index.yml b/fr-ca/articles/quickstart/webapp/rails/index.yml
new file mode 100644
index 0000000000..35e85c2158
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/index.yml
@@ -0,0 +1,53 @@
+title: Ruby On Rails
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/rails.png
+logo: rails
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
+  - quickstart
+  - ruby
+  - rails
+  - ruby on rails
+contentType: tutorial
+useCase: quickstart
+alias:
+  - ruby-rails
+  - sinatra
+  - omniauth
+seo_alias: rails
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+  - 02-troubleshooting
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-rubyonrails-sample
+  branch: master
+  path: sample
+sdk:
+  name: omniauth-auth0
+  url: https://github.com/auth0/omniauth-auth0
+  logo: rails
+requirements:
+  - Ruby 2.5.0+ | Rails 6.0+ or Rails 5.0+ or Rails 4.2+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/fr-ca/articles/quickstart/webapp/rails/interactive.md b/fr-ca/articles/quickstart/webapp/rails/interactive.md
new file mode 100644
index 0000000000..4a3af555e2
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,161 @@
+---
+title: Add Login to Your Ruby on Rails Application
+description: This tutorial demonstrates how to add user login to a Ruby on Rails application using OmniAuth.
+interactive: true
+files:
+  - files/config
+  - files/initializer
+  - files/controller
+  - files/routes
+  - files/concern
+---
+
+# Add Login to Your Ruby on Rails Application
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/auth/auth0/callback',
+  returnTo: 'http://localhost:3000',
+  webOriginUrl: 'http://localhost:3000',
+  showWebOriginInfo: true
+}) %>
+
+## Add dependencies
+
+Use `omniauth-auth0`, a custom [OmniAuth strategy](https://github.com/intridea/omniauth#omniauth-standardized-multi-provider-authentication), to handle the authentication flow.
+
+Add the following dependencies to your `Gemfile`:
+
+```ruby
+gem 'omniauth-auth0', '~> 3.0'
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+```
+
+Once your gems are added, install the gems with `bundle install`.
+
+## Configure the SDK {{{ data-action=code data-code="auth0.yml" }}}
+
+Create a configuration file `./config/auth0.yml` to specify your Auth0 domain, client ID, and client secret values located in your Auth0 Dashboard under application **Settings**.
+
+## Configure OmniAuth middleware {{{ data-action=code data-code="auth0.rb" }}}
+
+Create the following initializer file `./config/initializers/auth0.rb` and [configure](https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#send-additional-authentication-parameters) the **OmniAuth** middleware with the configuration file you created in the previous step.
+
+Ensure that `callback_path` matches the value given in the "Allowed Callback URLs" setting in your Auth0 application.
+
+## Add an Auth0 controller {{{ data-action=code data-code="auth0_controller.rb" }}}
+
+Create an Auth0 controller to handle the authentication callback, `logout` action, and methods for constructing the logout URL.
+
+Run the command: `rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine`. 
+
+Inside the callback method, assign the hash of user information - returned as `request.env['omniauth.auth']` - to the active session.
+
+To configure logout, clear all the objects stored within the session by calling the `reset_session` method within the `logout` action. Then, redirect to the Auth0 logout endpoint. To learn more about `reset_session`, read[Ruby on Rails ActionController documentation](http://api.rubyonrails.org/classes/ActionController/Base.html#M000668).
+
+## Configure routes {{{ data-action=code data-code="routes.rb" }}}
+
+Add these routes to your `./config/routes.rb` file.
+
+Routes must be in place so Rails knows how to route the various Auth0 callback URLs to the Auth0 controller you created in the previous step.
+
+::::checkpoint
+::: checkpoint-default
+Run your application to verify it continues to work as intended and you aren't receive any errors relating to Auth0.
+:::
+
+::: checkpoint-failure
+Sorry about that. Please double-check that the previous steps completed without error.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application
+
+A user can now log into your application by visiting the `/auth/auth0` endpoint.
+
+::: warning
+To [prevent forged authentication requests](https://github.com/cookpad/omniauth-rails_csrf_protection), use the `link_to` or `button_to` helper methods with the `:post` method
+:::
+
+```erb
+
+${"<%= button_to 'Login', '/auth/auth0', method: :post %>"}
+```
+
+::::checkpoint
+::: checkpoint-default
+Add a button to your application that redirects the user to the `/auth/auth0` endpoint when selected. Observe that you redirect to Auth0 to log in, and then back to your app after successful authentication.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a couple of things you can check:
+
+- Ensure that the correct URLs have been set in your Auth0 application as per the first step in this quickstart
+- Check that all the required gems installed correctly
+- Check that the routes have been set up and the Auth0 configuration has been set up in your app
+- [Check the logs](https://manage.auth0.com/#/logs) for any other errors or messages that may have prevented login from working
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your application
+
+Now that you can log in to your Rails application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Log out a user by redirecting to the `auth/logout` action, which redirects them to the Auth0 logout endpoint.
+
+:::note
+To test this after the previous step, you may need to clear out your session and then redirect the user to the Auth0 logout endpoint.
+:::
+
+```erb
+
+${"<%= button_to 'Logout', 'auth/logout', method: :get %>"}
+```
+
+::::checkpoint
+::: checkpoint-default
+Add a button to your application that redirects the user to the `/auth/logout` endpoint when selected. Verify that you redirect to Auth0 and then quickly back to your application, and that you are no longer logged in.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a couple of things you can check:
+
+- Ensure that the correct URLs have been set in your Auth0 client as per the first step in this quickstart
+- Check that the routes have been set up and the Auth0 configuration has been set up in your app
+- [Check the logs](https://manage.auth0.com/#/logs) for any other errors or messages that may have prevented login from working
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information {{{ data-action=code data-code="secured.rb" }}}
+
+To display the user's profile, your application should provide a protected route. You can use a [Concern](https://guides.rubyonrails.org/getting_started.html#using-concerns) to control access to routes that can be shared across multiple controllers. The concern should automatically redirect to Auth0 when the user is unauthenticated. Otherwise, the concern should return the current user profile.
+
+Once you have a Concern, include it in any controller that requires a logged in user. You can then access the user from the session `session[:userinfo]` as in the following example:
+
+```ruby
+class DashboardController < ApplicationController
+  include Secured
+
+  def show
+    @user = session[:userinfo]
+  end
+end
+```
+
+Once the user loads from the session, use it to display information in your frontend:
+
+```erb
+
    
+  
    Normalized User Profile:${"<%= JSON.pretty_generate(@user[:info])%>"}
    
+  
    Full User Profile:${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}
    
+
    
+```
+
+::::checkpoint
+::: checkpoint-default
+Add the `Secured` concern to your app and then include it in the controller that requires an authenticated user to access it. Verify that an authenticated user has access to actions within that controller and that unauthenticated users are redirected to Auth0 for authentication.
+:::
+::::
diff --git a/fr-ca/articles/rules/_includes/_context-prop-authentication.md b/fr-ca/articles/rules/_includes/_context-prop-authentication.md
new file mode 100644
index 0000000000..3019eaff7f
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_context-prop-authentication.md
@@ -0,0 +1,28 @@
+An object containing information related to the authentication transaction with the following properties:
+
+- `methods`: an array of objects containing the authentication methods a user has completed during their session. For example, a user that has completed a password-based authentication followed by MFA may have the following methods:
+
+```json
+[
+  {
+    "name": "pwd",
+    "timestamp": 1434454643024
+  },
+  {
+    "name": "mfa",
+    "timestamp": 1534454643881
+  }
+]
+```
+
+The method objects will contain the following properties:
+
+- `name`: a string representing the name of the authentication method that has been completed. It can be one of the following values (additional values may be supported in the future):
+  - `federated`: a social or enterprise connection was used to authenticate the user
+  - `pwd`: a database connection was used to authenticate the user
+  - `sms`: a Passwordless SMS connection was used to authenticate the user
+  - `email`: a Passwordless Email connection was used to authenticate the user
+  - `mfa`: the user completed a multi-factor authentication
+- `timestamp`: an integer indicating the time in seconds at which the authentication method took place in Unix Epoch time
+
+You can see a sample use case of the `context.authentication.methods` property in the [Require MFA once per session Rule](https://github.com/auth0/rules/blob/master/src/rules/require-mfa-once-per-session.js).
diff --git a/fr-ca/articles/rules/_includes/_context-prop-authorization.md b/fr-ca/articles/rules/_includes/_context-prop-authorization.md
new file mode 100644
index 0000000000..5625777e2f
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_context-prop-authorization.md
@@ -0,0 +1,3 @@
+An object containing information related to the authorization transaction with the following properties:
+
+- `roles`: an array of strings containing the names of a user's assigned roles. You can see a sample use case using the `context.authorization.roles` property to add roles to tokens in [Sample Use Cases: Rules with Authorization](/authorization/concepts/sample-use-cases-rules#add-user-roles-to-tokens).
\ No newline at end of file
diff --git a/fr-ca/articles/rules/_includes/_context-prop-protocol.md b/fr-ca/articles/rules/_includes/_context-prop-protocol.md
new file mode 100644
index 0000000000..7a76ff8125
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_context-prop-protocol.md
@@ -0,0 +1,13 @@
+The authentication protocol. Possible values:
+- `oidc-basic-profile`: most used, web based login
+- `oidc-implicit-profile`: used on mobile devices and single-page apps
+- `oauth2-device-code`: transaction using the [Device Authorization Flow](/flows/concepts/device-auth)
+- `oauth2-resource-owner`: user/password login typically used on database connections
+- `oauth2-resource-owner-jwt-bearer`: login using a bearer JWT signed with user's private key
+- `oauth2-password`: login using the password exchange
+- `oauth2-refresh-token`: refreshing a token using the Refresh Token exchange
+- `samlp`: SAML protocol used on SaaS apps
+- `wsfed`: WS-Federation used on Microsoft products like Office365
+- `wstrust-usernamemixed`: WS-trust user/password login used on CRM and Office365
+- `delegation`: when calling the [Delegation endpoint](/api/authentication#delegation)
+- `redirect-callback`: when a redirect rule is resumed
diff --git a/fr-ca/articles/rules/_includes/_context-prop-request.md b/fr-ca/articles/rules/_includes/_context-prop-request.md
new file mode 100644
index 0000000000..7ebe99591c
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_context-prop-request.md
@@ -0,0 +1,15 @@
+An object containing useful information of the request. It has the following properties:
+- `userAgent`: the user-agent of the application that is trying to log in.
+- `ip`: the originating IP address of the user trying to log in.
+- `hostname`: the hostname that is being used for the authentication flow.
+- `query`: an object containing the querystring properties of the login transaction sent by the application. 
+- `body`: the body of the POST request on login transactions used on `oauth2-resource-owner`, `oauth2-resource-owner-jwt-bearer` or `wstrust-usernamemixed` protocols.
+- `geoip`: an object containing geographic IP information. It has the following properties:
+  - `country_code`: a two-character code for the country associated with the IP address
+  - `country_code3`: a three-character code for the country associated with the IP address
+  - `country_name`: the country name associated with the IP address
+  - `city_name`: the city or town name associated with the IP address
+  - `latitude`: the latitude associated with the IP address.
+  - `longitude`: the longitude associated with the IP address.
+  - `time_zone`: the timezone associated with the IP address.
+  - `continent_code`: a two-character code for the continent associated with the IP address.
diff --git a/fr-ca/articles/rules/_includes/_context-prop-sso.md b/fr-ca/articles/rules/_includes/_context-prop-sso.md
new file mode 100644
index 0000000000..834c9ce793
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_context-prop-sso.md
@@ -0,0 +1,4 @@
+This object will contain information about the Single Sign-on (SSO) transaction (if available)
+- `with_auth0`: when a user signs in with SSO to an application where the `Use Auth0 instead of the IdP to do Single Sign-On` setting is enabled (only for legacy tenants).
+- `with_dbconn`: an SSO login for a user that logged in through a database connection.
+- `current_clients`: client IDs using SSO.
diff --git a/fr-ca/articles/rules/_includes/_supported-modules.md b/fr-ca/articles/rules/_includes/_supported-modules.md
new file mode 100644
index 0000000000..0ae32fe785
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_supported-modules.md
@@ -0,0 +1 @@
+Rules run in a JavaScript sandbox. The sandbox supports the ECMAScript 6 language and a large number of Node.js (version 8+) modules. For a list of supported sandbox modules, check out [Can I require: Auth0 Extensibility](https://auth0-extensions.github.io/canirequire/).
\ No newline at end of file
diff --git a/fr-ca/articles/rules/_includes/_user-prop-identities.md b/fr-ca/articles/rules/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..4647b53706
--- /dev/null
+++ b/fr-ca/articles/rules/_includes/_user-prop-identities.md
@@ -0,0 +1,9 @@
+Contains info retrieved from the identity provider with which the user originally authenticates. Users may also [link their profile to multiple identity providers](/users/concepts/overview-user-account-linking); those identities will then also appear in this array. The contents of an individual identity provider object varies by provider, but it will typically include the following:
+
+- `connection` (text): Name of the Auth0 connection used to authenticate the user.
+- `isSocial` (boolean): Indicates whether the connection is a social one.
+- `provider` (text): Name of the entity that is authenticating the user, such as Facebook, Google, SAML, or your own provider.
+- `user_id` (text): User's unique identifier for this connection/provider.
+- `profileData` (object): User information associated with the connection. When profiles are linked, it is populated with the associated user info for secondary accounts.
+
+In some cases, it will also include an API Access Token to be used with the provider. 
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/automatically-generate-leads-shopify.md b/fr-ca/articles/rules/guides/automatically-generate-leads-shopify.md
new file mode 100644
index 0000000000..f01f3cdeb8
--- /dev/null
+++ b/fr-ca/articles/rules/guides/automatically-generate-leads-shopify.md
@@ -0,0 +1,54 @@
+---
+title: Automatically Generate Leads in Shopify
+description: Learn how to automatically generate leads in Shopify using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Automatically Generate Leads in Shopify
+
+To increase e-commerce sales, you may want to integrate with Shopify. With Auth0, you can not only [configure Shopify as a social identity provider](/connections/social/shopify) out-of-the-box, you can also automatically generate leads in Shopify using a specialized rule template.
+
+In this example, we will use a rule to automatically generate a lead with Shopify when a user authenticates.
+
+## Prerequisites
+
+Before connecting your Auth0 app to Shopify, you must [sign up for and configure your account with Shopify](https://www.shopify.com/).
+
+## Steps
+
+To connect your app to Shopify, you will:
+
+1. [Set up your app in Shopify](#set-up-your-app-in-shopify)
+2. [Get your Shopify credentials](#get-your-shopify-credentials)
+3. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Set up your app in Shopify
+
+Create an app in Shopify and generate credentials for it, using Shopify's [Authenticate a Private App with Shopify Admin](https://shopify.dev/tutorials/authenticate-a-private-app-with-shopify-admin). During this process, Shopify will generate an **API Key** and **API Password** for your application; make note of these.
+
+### Get your Shopify credentials
+
+You will also need to get your Shopify API URL. To learn about the structure of your Shopify API URL, see Shopify's [Make Your First Shopify API Request](https://shopify.dev/tutorials/make-your-first-shopify-api-request#making-your-first-request).
+
+Once you have retrieved your Shopify API URL, keep this value on hand because we will use it in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **shopify-leads-from-login** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| SHOPIFY_API_KEY | API Key for the application you previously set up in Shopify. |
+| SHOPIFY_API_PWD | API Password for the application you previously set up in Shopify. |
+| SHOPIFY_API_URL | Your Shopify API URL. |
+
+By default, your rule will be activated upon save.
diff --git a/fr-ca/articles/rules/guides/cache-resources.md b/fr-ca/articles/rules/guides/cache-resources.md
new file mode 100644
index 0000000000..38f2e6fb5e
--- /dev/null
+++ b/fr-ca/articles/rules/guides/cache-resources.md
@@ -0,0 +1,35 @@
+---
+description: How to cache expensive resources in your Rules code.
+topics:
+  - rules
+  - extensibility
+  - cache
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Cache Expensive Resources in Rules
+
+In Rules you can store expensive resources using the `global` object. The `global` object survives individual execution, so you can reuse things stored there instead of creating them every time a Rule is run. However, the Rules environment can be recycled at any time so your code __must__ always check that `global` contains what you expect.
+
+This example shows how to use the `global` object to keep a [MongoDB](https://www.mongodb.com/) connection:
+
+```js
+//If the db object is there, use it.
+if (global.db){
+  return query(global.db, callback);
+}
+
+//If not, get the db (mongodb in this case)
+mongo('mongodb://user:pass@mymongoserver.com/my-db',  function (db){
+  global.db = db;
+  return query(db, callback);
+});
+
+//Do the actual work
+function query(db, cb){
+  // Do something with db
+  ...
+  return cb(null, user, context);
+}
+```
diff --git a/fr-ca/articles/rules/guides/configuration.md b/fr-ca/articles/rules/guides/configuration.md
new file mode 100644
index 0000000000..bad1fd86d4
--- /dev/null
+++ b/fr-ca/articles/rules/guides/configuration.md
@@ -0,0 +1,60 @@
+---
+title: Store Configuration for Rules
+description: A list of the Node.js modules and libraries that are available when creating Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Store Configuration for Rules
+
+The global `configuration` object is available in Rules for storing commonly used values, such as URLs. Sensitive information, such as credentials or API keys, should be stored through the `configuration` object and kept out of your Rules code.
+
+## Configure values
+
+You can set configuration values in your [Rules Settings](${manage_url}/#/rules/) on the Dashboard.
+
+To edit or change a configuration key's value, remove the existing configuration setting and replace it with the updated value.
+
+![Rules Configuration](/media/articles/rules/rules-configuration.png)
+
+::: note
+You need to have created at least one Rule to see the configuration area, otherwise, the Rules demo shows instead.
+:::
+
+## Use the `configuration` object
+
+Any configuration values you set can be accessed through the `configuration` object by key in your Rules code.
+
+```js
+var MY_API_KEY = configuration.MY_API_KEY;
+```
+
+The following example is a Rule for sending a Slack message when a new user has signed up. The [Slack Webhook](https://api.slack.com/incoming-webhooks) is a `configuration` value set with the key `SLACK_HOOK_URL`.
+
+```js
+function (user, context, callback) {
+  // short-circuit if the user signed up already or is using a Refresh Token
+  if (context.stats.loginsCount > 1 || context.protocol === 'oauth2-refresh-token') {
+    return callback(null, user, context);
+  }
+
+  // get your slack's hook url from: https://slack.com/services/10525858050
+  const SLACK_HOOK = configuration.SLACK_HOOK_URL;
+
+  const slack = require('slack-notify')(SLACK_HOOK);
+  const message = 'New User: ' + (user.name || user.email) + ' (' + user.email + ')';
+  const channel = '#some_channel';
+
+  slack.success({
+    text: message,
+    channel: channel
+  });
+
+  // don’t wait for the Slack API call to finish, return right away (the request will continue on the sandbox)`
+  callback(null, user, context);
+}
+```
diff --git a/fr-ca/articles/rules/guides/debug.md b/fr-ca/articles/rules/guides/debug.md
new file mode 100644
index 0000000000..b269e370a5
--- /dev/null
+++ b/fr-ca/articles/rules/guides/debug.md
@@ -0,0 +1,47 @@
+---
+title: Debug Rules
+description: Learn how to debug your Auth0 rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - debug
+contentType: how-to
+useCase: extensibility-rules
+---
+# Debug Rules
+
+To debug any [Rule](/rules) you have created in Auth0, you can use `console.log` from within your rule code. You can see `console.log` output by using the [**Try this Rule** feature](#try-this-rule), viewing the logs available with the [Real-time Webtask Logs extension](#real-time-logs-extension), or for legacy clients, using the [Debug Rule CLI](#debug-rule-cli).
+
+## Try this Rule
+
+In the [Rules Editor](${manage_url}/#/rules/create), the **TRY THIS RULE** button lets you run a Rule in isolation with mock **user** and **context** objects. Clicking **TRY** will run the Rule with those two objects as input and will display any `console.log` output.
+
+![Try this Rule](/media/articles/rules/try-rule.png)
+
+::: note
+The **TRY THIS RULE** feature functions outside a specific client context. When using this feature, you may run into issues if your Rule depends on data that would be provided when called from an actual application.
+:::
+
+## Real-time logs extension
+
+The [Real-time Webtask Logs](/extensions/realtime-webtask-logs) extension displays all logs in real-time for all custom code in your account, which includes all `console.log` output and exceptions.
+
+## Debug Rule CLI
+
+<%= include('../../_includes/_webtask') %>
+
+In the [Rules Editor](${manage_url}/#/rules/create)], the **DEBUG RULE** button displays instructions for installing, configuring, and running the [webtask CLI](https://github.com/auth0/wt-cli) for debugging Rules. Paste these commands into a terminal to see the `console.log` output and any unhandled exceptions that occur during Rule execution.
+
+For example:
+
+```sh
+  ~  npm install -g wt-cli
+  ~  wt init --container "youraccount" --url "https://sandbox.it.auth0.com" --token "eyJhbGci...WMPGI" -p "youraccount-default-logs"
+  ~  wt logs -p "youraccount-default-logs"
+  [18:45:38.179Z]  INFO wt: connected to streaming logs (container=youraccount)
+  [18:47:37.954Z]  INFO wt: webtask container assigned
+  [18:47:38.167Z]  INFO wt: ---- checking email_verified for some-user@mail.com! ----
+```
+
+This debugging method works for Rules tried from the Dashboard and for those actually running during user authentication.
diff --git a/fr-ca/articles/rules/guides/integrate-efm-solutions.md b/fr-ca/articles/rules/guides/integrate-efm-solutions.md
new file mode 100644
index 0000000000..4c6d8539fd
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-efm-solutions.md
@@ -0,0 +1,48 @@
+---
+title: Integrate with Enterprise Fraud Management Solutions
+description: Learn how to integrate Enterprise Fraud Management solutions using rules. The given example uses Socure, but can be modified to use any EFM service. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with Enterprise Fraud Management Solutions
+
+To create trust with consumers, you may want to integrate with an Enterprise Fraud Management (EFM) service, such as Socure, Maxmind, or SAS. Although this example shows how to configure an integration with Socure, you may modify it to use any EFM service.
+
+In this example, we will use a rule to make a call to Socure to request that they return a user fraud score for the user who is authenticating, based on their email address and IP address. If a user has a high fraud score, you may choose to put them on a watch list or require them to provide additional information before they can make any transactions. 
+
+## Prerequisites
+
+Before connecting your Auth0 app to an EFM service, you must have configured an account with the chosen service. For this example, you will need to [sign up for and configure your account with Socure](https://developer.socure.com/guide/start).
+
+## Steps
+
+To connect your app to your EFM service, you will:
+
+1. [Get your EFM service's credentials](#get-your-efm-services-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your EFM service's credentials
+
+First, you will need to retrieve the URL of your EFM's API and your API Key. To learn how to do this for Socure, see [Socure's Developer docs](https://developer.socure.com/guide/overview). To access all content, you will need to log in to your Socure account.
+
+Once you have retrieved the EFM API's URL and your API Key, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Detect Fraud Users** template from the **Enrich Profile** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | URL of the EFM's API |
+| socurekey | Key for the EFM's API. You may use global variables to configure this in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first. |
+
+::: note
+Although in this example we configure a rule to integrate with Socure, you may modify this rule to use any EFM service.
+:::
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/integrate-erfm-solutions.md b/fr-ca/articles/rules/guides/integrate-erfm-solutions.md
new file mode 100644
index 0000000000..29597e769b
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-erfm-solutions.md
@@ -0,0 +1,53 @@
+---
+title: Integrate with eCommerce and Retail Fraud Management Solutions
+description: Learn how to integrate eCommerce and Retail Fraud Management solutions using rules. The given example uses Signifyd, but can be modified to use any ERFM service. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with eCommerce and Retail Fraud Management Solutions
+
+
+To more effectively contain fraud and counter fast-changing fraud patterns, you may want to integrate with an eCommerce and Retail Fraud Management (ERFM) service, such as Signifyd, Cybersource, or Forter. Although this example shows how to configure an integration with Signifyd, you may modify it to use any ERFM service.
+
+In this example, we will use a rule to make a call to Signifyd to detect whether or not the user who is authenticating is fraudulent, based on their transaction history.
+
+## Prerequisites
+
+Before connecting your Auth0 app to an ERFM service, you must have configured an account with the chosen service. For this example, you will need to [sign up for and configure your account with Signifyd](https://www.signifyd.com/).
+
+## Steps
+
+To connect your app to your ERFM service, you will:
+
+1. [Get your ERFM service's credentials](#get-your-erfm-services-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your ERFM service's credentials
+
+First, you will need to retrieve the URL of your ERFM's API and your API Key. To learn how to do this for Signifyd, see Signifyd's [API Reference: Get Case](https://developer.signifyd.com/api/#/reference/cases/get-case) and [Create a Team](https://www.signifyd.com/resources/faq/working-with-teams/how-do-i-create-a-team/) docs.
+
+Once you have retrieved the ERFM API's URL and your API Key, keep these values on hand because we will use them in the next step.
+
+::: note
+This rule template also passes the API a `caseId` that you should have already saved in the authenticating user's `app_metadata` profile field. To learn how to modify metadata in the Auth0 user profile, see [Metadata](/users/concepts/overview-user-metadata).
+:::
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Detect eCommerce Fraud Users** template from the **Enrich Profile** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | URL of the ERFM's API |
+| headers | Replace the example API Key with the API Key you retrieved in Step 1. |
+
+::: note
+Although in this example we configure a rule to integrate with Signifyd, you may modify this rule to use any ERFM service.
+:::
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/integrate-hubspot.md b/fr-ca/articles/rules/guides/integrate-hubspot.md
new file mode 100644
index 0000000000..f80a3ea207
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-hubspot.md
@@ -0,0 +1,53 @@
+---
+title: Integrate with HubSpot Marketing Software
+description: Learn how to integrate HubSpot Marketing Software using rules. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with HubSpot Marketing Software
+
+To help increase traffic and leads, you may want to integrate with HubSpot Marketing Software. You can do this using a specialized rule template.
+
+In this example, we will use a rule to add a new contact to a specified list in HubSpot.
+
+## Prerequisites
+
+Before connecting your Auth0 app to HubSpot, you must [sign up for and configure your account with HubSpot](https://www.hubspot.com/).
+
+## Steps
+
+To connect your app to HubSpot, you will:
+
+1. [Get your HubSpot credentials](#get-your-hubspot-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your HubSpot credentials
+
+First, you will need to retrieve your HubSpot API Key and the list ID of the HubSpot list to which you want to add a new member.
+
+To learn how to get your HubSpot API Key, see [HubSpot's Access your HubSpot API Key doc](https://knowledge.HubSpot.com/integrations/how-do-i-get-my-HubSpot-api-key).
+
+You can find the ID of any list in HubSpot by navigating to the list in your portal and inspecting the URL. The format of the URL is:
+`https://app.hubspot.com/contacts/{portal id}/lists/{list id}`
+
+Once you have retrieved your HubSpot API Key and HubSpot List ID, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Add New Contact to HubSpot for Marketing** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| HUBSPOT_API_KEY | Your HubSpot API Key. |
+| HUBSPOT_NEW_MEMBER_LIST_ID | ID of the HubSpot list to which you want to add a new member. |
+
+By default, your rule will be activated upon save. Upon authentication, users will now show up as Contacts and be added to the specified list in HubSpot.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/integrate-maxmind.md b/fr-ca/articles/rules/guides/integrate-maxmind.md
new file mode 100644
index 0000000000..4078db7c80
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-maxmind.md
@@ -0,0 +1,48 @@
+---
+title: Integrate with MaxMind minFraud
+description: Learn how to integrate MaxMind minFraud using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with MaxMind minFraud
+
+To assess the risk profile of a user before authenticating them, you may want to integrate with MaxMind minFraud services, a risk-based authentication solution. You can do this using a specialized rule template.
+
+In this example, we will use a rule to call MaxMind and determine whether or not the user is fraudulent based on their device fingerprint.
+
+## Prerequisites
+
+Before connecting your Auth0 app to MaxMind, you must [sign up for and configure your account with MaxMind](https://www.maxmind.com/en/solutions/minfraud-services).
+
+## Steps
+
+To connect your app to MaxMind, you will:
+
+1. [Get your MaxMind credentials](#get-your-maxmind-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your MaxMind credentials
+
+First, you will need to retrieve your MaxMind Account ID and generate a License Key. To locate your Account ID, see [MaxMind Support](https://support.maxmind.com/). To learn how to generate a License Key, see [MaxMind's Generating License Keys for Your Account](https://www.maxmind.com/en/accounts/current/license-key).
+
+Once you have retrieved your MaxMind Account ID and License Key, keep these values on hand because we will use them in the next step. In particular, keep track of your License Key because MaxMind will display it to you only once--at the time of generation.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Alternate Risk Score** template from the **Enrich Profile** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| MINFRAUD_ACCOUNT_ID | MaxMind minFraud Account ID. |
+| MINFRAUD_LICENSE_KEY | MaxMind minFraud License Key. |
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/integrate-mixpanel.md b/fr-ca/articles/rules/guides/integrate-mixpanel.md
new file mode 100644
index 0000000000..64681528b6
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-mixpanel.md
@@ -0,0 +1,44 @@
+---
+title: Integrate with MixPanel Product Analytics
+description: Learn how to integrate MixPanel Product Analytics using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with MixPanel Product Analytics
+
+To help convert, engage, and retain users, you may want to integrate with MixPanel Product Analytics. You can do this using a specialized rule template.
+
+In this example, we will use a rule to send a sign-in event to MixPanel and will include the application to which the user is logging in as a property.
+
+## Prerequisites
+
+Before connecting your Auth0 app to MixPanel, you must [sign up for and configure your account with MixPanel](https://mixpanel.com/).
+
+## Steps
+
+To connect your app to MixPanel, you will:
+
+1. [Get your MixPanel credentials](#get-your-mixpanel-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your MixPanel credentials
+
+First, you will need to retrieve the URL of MixPanel's API and your API Token. To learn how to do this, see [MixPanel's Ingestion API HTTP spec](https://developer.mixpanel.com/docs/http).
+
+Once you have retrieved the MixPanel API's URL and your API Token, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Tracks Logins in Mixpanel** template from the **Webhook** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | MixPanel API URL |
+| token | MixPanel API Token. You may use global variables to configure this in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first. |
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/integrate-salesforce.md b/fr-ca/articles/rules/guides/integrate-salesforce.md
new file mode 100644
index 0000000000..0199086e95
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-salesforce.md
@@ -0,0 +1,72 @@
+---
+title: Integrate with Salesforce
+description: Learn how to integrate Salesforce using rules. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with Salesforce
+
+To automate and manage your customer life cycle, you may want to integrate with Salesforce's customer relationship management solution. You can do this using a specialized rule template.
+
+In this example, we will use a rule to record a new Salesforce Lead when a new user first authenticates. The rule will also send a notification for the new Lead to a specified Slack channel.
+
+## Prerequisites
+
+Before connecting your Auth0 app to Salesforce, you must [sign up for and configure your account with Salesforce](https://www.salesforce.com/).
+
+## Steps
+
+To connect your app to Salesforce, you will:
+
+1. [Set up your app in Salesforce](#set-up-your-app-in-salesforce)
+2. [Get your Salesforce credentials](#get-your-salesforce-credentials)
+3. [Get your Slack channel hook URL](#get-your-slack-channel-hook-url)
+4. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Set up your app in Salesforce
+
+Create an app in Salesforce and generate credentials for it, using [Salesforce's Create a Connected App](https://help.salesforce.com/articleView?id=connected_app_create.htm&type=0) docs. During this process, Salesforce will generate a **Consumer Key** and **Consumer Secret** for your application; make note of these.
+
+While setting up your app, make sure you use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| App URL | `https://${account.namespace}` |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+<%= include('../../connections/_find-auth0-domain-redirects') %>
+
+### Get your Salesforce credentials
+
+You will also need to get your Salesforce username and password that you use to authenticate with the Salesforce API. This username will appear as the creator of the Lead.
+
+Once you have retrieved your Salesforce username and password, keep these values on hand because we will use them in a future step.
+
+### Get your Slack channel hook URL
+
+To send a notification for the new Lead to a specified Slack channel, you will need to get the Slack channel's hook URL from your [Slack Workspace's Integrations](https://slack.com/services/10525858050).
+
+Make note of the Slack channel's hook URL because we will use it in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Create a New Lead in Salesforce on First Login** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| SFCOM_CLIENT_ID | Consumer Key for the application you previously set up in Salesforce. |
+| SFCOM_CLIENT_SECRET | Consumer Secret for the application you previously set up in Salesforce. |
+| USERNAME | Username you use to authenticate with Salesforce's API. |
+| PASSWORD | Password you use to authenticate with Salesforce's API. |
+| MY_SLACK_WEBHOOK_URL | Hook URL for the Slack channel to which you want to send a notification of a new Salesforce Lead. |
+
+By default, your rule will be activated upon save.
diff --git a/fr-ca/articles/rules/guides/integrate-user-id-verification.md b/fr-ca/articles/rules/guides/integrate-user-id-verification.md
new file mode 100644
index 0000000000..fbfe64ed0b
--- /dev/null
+++ b/fr-ca/articles/rules/guides/integrate-user-id-verification.md
@@ -0,0 +1,56 @@
+---
+title: Integrate User ID Verification Services Using Rules
+description: Learn how to integrate third-party user identity verification services using rules.  
+topics:
+  - rules
+  - extensibility
+  - identity-providers
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Integrate User ID Verification Services Using Rules
+
+Auth0 allows integration with third-party vendors that offer identity verification. Such integration can be done by either connecting the third-party vendor as a federated identity provider using either a [custom OIDC Connection](/connections/enterprise/oidc) or the [SAML protocol](/saml), or by using [Auth0 Rules](/rules).
+
+In this example, you will integrate with OnFido, a third-party vendor providing Document ID and Facial Biometrics Verification, using a [redirect rule](/rules/guides/redirect) in Auth0.
+
+## Prerequisites
+
+Before connecting your Auth0 app to OnFido, you must [sign up for and configure your account with OnFido](https://onfido.com/us/).
+
+## User ID verification login experience
+
+The authentication flow contains the following steps:
+
+1. An app initiates an authentication request to Auth0.
+2. Auth0 routes the request to an Identity Provider through a configured connection.
+3. The user authenticates successfully.
+4. The [ID Token](/tokens/concepts/id-tokens) and/or Access Token is passed through the Rules pipeline, then sent to the app.
+
+The user will see the following screens when the third-party verification service is part of the authentication flow.
+
+The user chooses to login with Google. 
+
+![OnFido Verification Login Screen](/media/articles/rules/onfido-verification-login1.png)
+
+The login process then prompts the user to select a document to use to verify their identity.
+
+![OnFido Verify Identity](/media/articles/rules/onfido-verify-identity.png)
+
+After the user performs the steps to verify their identity, uploading documents and/or images, the verification service determines if the credentials are valid and then continues.
+
+![OnFido Verify Success](/media/articles/rules/onfido-verify-success.png)
+
+## Metadata example
+
+The information of the OnFido verification is then stored in a [user’s app metadata](/users/concepts/overview-user-metadata) within the Auth0 user profile.
+
+![OnFido Metadata Example](/media/articles/rules/onfido-metadata-example.png)
+
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
diff --git a/fr-ca/articles/rules/guides/management-api.md b/fr-ca/articles/rules/guides/management-api.md
new file mode 100644
index 0000000000..bc49ddd310
--- /dev/null
+++ b/fr-ca/articles/rules/guides/management-api.md
@@ -0,0 +1,49 @@
+---
+title: Use the Management API from within Rules
+description: Learn how to use the Management API from within rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - management-api
+contentType: how-to
+useCase: extensibility-rules
+---
+# Use the Management API from within Rules
+
+From within any [Rule](/rules) you write, you can update a user's `app_metadata` or `user_metadata` using the [`auth0` object](/best-practices/rules#auth0-object), which is a specially-restricted instance of `ManagementClient` (defined in the [node-auth0](https://github.com/auth0/node-auth0) Node.js client library) and provides limited access to the [Auth0 Management API](/api/management/v2). 
+
+To access additional Management API endpoints from inside Rules, you have to use another version of the library.
+
+::: note
+The Access Token for the Management API, which is available through `auth0.accessToken`, is limited to the `read:users` and `update:users` scopes. If you require a broader range of scopes, you can request a token using the Client Credentials grant. See [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production).
+:::
+
+## Access a newer version of the library
+
+You can load a newer version of the Auth0 Node.js client library by requiring the specific version of the library. For up-to-date version information, check the [repository](https://github.com/auth0/node-auth0).
+
+In this example, we load version `2.9.1` of the library, then query the list of users and logs the users to the console (to be inspected with the [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs)).
+
+:::warning
+[Searching for users](/best-practices/search-best-practices) from inside Rules may affect the performance of your logins; we advise against it. 
+:::
+
+```js
+function (user, context, callback) {
+  var ManagementClient = require('auth0@2.9.1').ManagementClient;
+  var management = new ManagementClient({
+    token: auth0.accessToken,
+    domain: auth0.domain
+  });
+
+  management.getUsers(function (err, users) {
+    console.log(users);
+    callback(null, user, context);
+  });
+}
+```
+
+::: note
+For a filtered list of available libraries that can be set as required, check the [available library versions](https://auth0-extensions.github.io/canirequire/#auth0).
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/rules/guides/metadata.md b/fr-ca/articles/rules/guides/metadata.md
new file mode 100644
index 0000000000..3a8247c063
--- /dev/null
+++ b/fr-ca/articles/rules/guides/metadata.md
@@ -0,0 +1,498 @@
+---
+description: Learn how to work with app metadata, user metadata, and client metadata in Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - metadata
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Use Metadata in Rules
+
+You can read, update, and delete [metadata](/metadata) using [Rules](/rules).
+
+::: panel-warning `app_metadata` field names
+Avoid using the same name for `app_metadata` fields and root profile fields. Within the rules scope, `app_metadata` is squashed into the root profile and may override root properties.
+
+For example, if a SAML identity provider returns a `groups` field and the user has an `app_metadata.groups` field, then `user.groups` will be equal to `app_metadata.groups` and not `user.groups`.
+:::
+
+In the following sections, we will refer to this example where the user and their information is represented by the following JSON snippet:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+## Read Metadata
+
+To read the available metadata, you will need to access the correct user property.
+
+### Read `app_metadata`
+
+Using rules, you can make a decision based on the user's roles:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  if (user.app_metadata.roles.indexOf('writer')){
+    // code to be executed
+  }
+  ...
+}
+```
+
+### Read `user_metadata`
+
+Similarly, you can base decisions on specific preferences, such as a color preference:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  if (user.user_metadata.preferences.color === 'black'){
+    // code to be executed
+  }
+  ...
+}
+```
+
+## Update metadata
+
+### Read `client_metadata`
+
+`clientMetadata` is an optional, top-level property of the context object. Existing applications will have no value for this property.
+
+```js
+function(user, context, callback){
+  context.clientMetadata = context.clientMetadata || {};
+  if (context.clientMetadata.usersuppliedkey1 === 'black'){
+    // this code would not be executed for the user
+  }
+  ...
+}
+```
+
+#### Read `client_metadata` with the Management API
+
+`client_metadata` is included in the response to the `GET /api/v2/clients` and `GET /api/v2/client/{id}` endpoints
+
+#### Create applications with `client_metadata` properties
+
+A `client_metadata` object can be included when creating a new application via the `POST /api/v2/` applications endpoint.
+
+#### Create `client_metadata` properties in the dashboard
+
+`client_metadata` key value pairs can also be added in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section, enter the key and value then click **CREATE**.
+
+![Create application metadata](/media/articles/rules/adv-settings-create.png)
+
+All rules include an `auth0` object (which is an instance of the [node-auth0 SDK](https://github.com/auth0/node-auth0)) that is capable of calling the [Auth0 Management API v2](/api/management/v2). The `auth0` object is preconfigured with the necessary permissions to update users.
+
+### Update `app_metadata`
+
+To add an administrative role to the user:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = user.app_metadata.roles || [];
+  user.app_metadata.roles.push('administrator');
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer", "administrator" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+### Update `user_metadata`
+
+To add the user's `fontSize` preference to the user profile:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  user.user_metadata.preferences.fontSize = 12;
+
+  // persist the user_metadata update
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue",
+      "fontSize": 12
+    }
+  }
+}
+```
+
+### Update `app_metadata` and `user_metadata` simultaneously
+
+To reduce the rule's processing time, you may update both the `app_metadata` and `user_metadata` in the same rule:
+
+```js
+function(user, context, callback){
+
+  var q = require('q');
+
+  user.app_metadata = user.app_metadata || {};
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  user.user_metadata.preferences.fontSize = 12;
+
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = user.app_metadata.roles || [];
+  user.app_metadata.roles.push('admin');
+
+  // persist the app_metadata update
+  var appMetadataPromise  = auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
+
+  // persist the user_metadata update
+  var userMetadataPromise = auth0.users.updateUserMetadata(user.user_id, user.user_metadata);
+
+  // using q library to wait for all promises to complete
+  q.all([userMetadataPromise, appMetadataPromise])
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer", "admin" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue",
+      "fontSize": 12
+    }
+  }
+}
+```
+
+## Manage `client_metadata`
+
+`client_metadata` is a multi-purpose key/value hash to store information about an application (i.e. a “client” in OIDC/OAuth2 lingo). You might store, for example, the URL for the application’s home page (a field that Auth0 doesn’t provide by default in the application settings).
+
+You get or set `client_metadata` either using the [clients API](/api/v2/clients/{client_id}) or in the Dashboard, in the application’s advanced settings. The `client_metadata` is stored as part of the application (client) properties.
+
+::: panel Where to store a secret to be returned in a JWT
+Where to store the secret depends on the scope of the secret:
+
+* Is it just one secret per application? Then `client_metadata` would be a good place. But if this is the case, you should consider storing the secret directly in the application instead, to avoid putting the secret in the ID token.
+* Is it the same secret for the whole system (i.e. for all application, or many)? Then the rule’s configuration values might be a better choice
+* Is it a different secret for each user? Then `app_metadata` might be better.
+:::
+
+`clientMetadata` is an optional, top-level property of the `context` object. Existing applications will have no value for this property.
+
+```js
+function(user, context, callback){
+  context.clientMetadata = context.clientMetadata || {};
+  if (context.clientMetadata.usersuppliedkey1 === 'black'){
+    // this code would not be executed for the user
+  }
+  ...
+}
+```
+
+::: warning
+Claims in the ID Token are not encrypted, so depending on the flow that you use the user might be able to get the token and inspect the contents. Auth0 does **not** recommend storing a secret in that way. 
+:::
+
+You can read and add to the `client_metadata` using either the Management API or the Dashboard. 
+
+* In the Management API, the `client_metadata` is included in the response to the `GET /api/v2/clients` and `GET /api/v2/client/{id}` endpoints. A `client_metadata` object can be included when creating a new application via the `POST /api/v2/` endpoint.
+
+* In the Dashboard, you can add the `client_metadata` key value pairs in [Applications](${manage_url}/#/applications). 
+  * Select the settings (the gear icon) of the application you wish to edit. 
+  * Scroll down and click the link **Show Advanced Settings**. 
+  * In the **Application Metadata** section, enter the key and value then click **CREATE**.
+
+![Create application metadata](/media/articles/rules/adv-settings-create.png)
+
+Application metadata can be updated using the [`PATCH /api/v2/clients/{id}`](/api/management/v2#!/Users/patch_users_by_id) endpoint, supplying an application object with the `client_metadata property`, whose value is an object containing the metadata you'd like to change.
+
+*Application Before*
+
+```
+{
+  ...
+  "name": "myclient",
+  "client_metadata": {
+    "mycolor": "red",
+    "myflavor": "grape"
+  }
+  ...
+}
+```
+
+Request: `PATCH /api/v2/client/myclientid123` with body:
+
+```
+{ "client_metadata": { "mycolor": "blue" } }
+```
+
+*Application After*
+
+```
+{
+  "name": "myclient",
+  "client_metadata": {
+    "mycolor": "blue",
+    "myflavor": "grape"
+  }
+  ...
+}
+```
+
+#### Update `client_metadata` in the dashboard
+
+Application metadata can also be updated in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section. For the key value, enter the name of the key you wish to edit. Then enter the new value that you want to update. 
+
+Click **UPDATE**. A popup window will appear to confirm your overwrite.
+
+![Confirm Update](/media/articles/rules/confirm-overwrite.png)
+
+## Delete Metadata
+
+### Delete `app_metadata` properties and values
+
+To delete a property, set the property's value to `null`.
+
+For example, to delete the user's roles:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = null;
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": { },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+To delete a single value of a property, remove that value specifically.
+
+For example, to remove the `writer` role from the user profile:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  user.app_metadata.roles = user.app_metadata.roles || [];
+
+  var index = user.app_metadata.roles.indexOf('writer');
+
+  if (index !== -1){
+    // update the app_metadata that will be part of the response
+    user.app_metadata.roles.splice(index, 1);
+  }
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "google-oauth2|1234",
+  "email": "john.doe@gmail.com",
+  "app_metadata": {
+    "roles": [ ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+Note that the `roles` property still exists but does not contain any value.
+
+### Delete `user_metadata` properties and values
+
+To delete the user's color preference:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  delete user.user_metadata.preferences.color;
+
+  // persist the user_metadata update
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+  });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": { }
+  }
+}
+```
+
+### Delete `client_metadata` properties and values
+
+`client_metadata` keys can be removed by issuing a PATCH, [as described above](#updating-application_metadata), but supplying a null for the key value. This behavior matches that of the `user_metadata` and `app_metadata` properties in the `PATCH` [/api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) endpoint.
+
+#### Delete `client_metadata` properties and values in the dashboard
+
+`client_metadata` keys can also be removed in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section, click the **REMOVE** button for the key/value pair you wish to delete.
+
+![Remove application metadata](/media/articles/rules/adv-settings-remove.png)
+
+## Considerations
+
+The metadata must be a valid JSON object and can not contain a dot in key field names in `user_metadata`, `app_metadata` or `client_metadata`.
+
+This is not allowed:
+
+```js
+{
+  "preference.color" : "pink"
+}
+```
+
+This, however, is accepted:
+
+```js
+{
+  "color" : "light.blue"
+}
+```
+
+If you use a key field name with a dot in it you will get an Internal Server (500) error.
+
+As a workaround, you can convert the first example to something like this.
+
+```js
+{
+  "preference" : {"color" : "pink" }
+}
+```
+
+Or you could use a different delimiter character besides `.` (dot) or `$` (dollar sign).
+
+`client_metadata` is an object, whose keys and values are strings, with a maximum length of 255 characters. Also `client_metadata` is restricted to having a maximum 10 keys.
+
+## Keep reading
+
+::: next-steps
+* [Use the Management API in rules](/rules/current/management-api)
+* [Properties of the Context Argument](/rules/current/context)
+:::
diff --git a/fr-ca/articles/rules/guides/redirect.md b/fr-ca/articles/rules/guides/redirect.md
new file mode 100644
index 0000000000..160a5dcf45
--- /dev/null
+++ b/fr-ca/articles/rules/guides/redirect.md
@@ -0,0 +1,248 @@
+---
+title: Redirect Users From Within Rules
+description: Learn how to customize authentication flows by redirecting users using rules. Example areas that can be customized include MFA, privacy policy acceptance, and gathering user data.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - redirection
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Redirect Users From Within Rules
+
+You can use [Rules](/rules) to redirect users before an authentication transaction is complete. This lets you implement custom authentication flows that require additional user interaction beyond the standard login form. Redirect rules can be used for:
+
+* [Custom Multi-factor Authentication (MFA)](/mfa/guides/customize-mfa-universal-login).
+* Custom privacy policy acceptance, terms of service, and data disclosure forms.
+* Securely performing a one-time collection of additional required profile data.
+* Allowing remote Active Directory users to change their password.
+* Requiring users to provide additional verification when logging in from unknown locations.
+* Gathering more information about your users than they provided at initial signup.
+
+::: note
+You can redirect a user **once** per authentication flow. If you have one rule that redirects a user, you **cannot** invoke a second rule to redirect the user at a later time.
+:::
+
+## Start redirect and resume authentication
+
+1. Set the `context.redirect` property as follows:
+
+    ```js
+    function (user, context, callback) {
+        context.redirect = {
+            url: "https://example.com/foo"
+        };
+        return callback(null, user, context);
+    }
+    ```
+
+    Once all rules have finished executing, Auth0 redirects the user to the URL specified in the `context.redirect.url` property. Auth0 also passes a `state` parameter in that URL. For example:
+
+    ```
+    https://example.com/foo?state=abc123
+    ```
+
+    Your redirect URL will need to extract the `state` parameter and send it back to Auth0 to resume the authentication transaction. State is an opaque value, used to prevent [Cross-Site Request Forgery (CSRF) attacks](/security/common-threats#cross-site-request-forgery).
+
+2. After the redirect, resume authentication by redirecting the user to the `/continue` endpoint and include the `state` parameter you received in the URL. 
+
+    ::: warning
+    If you do not send the original state back to the `/continue` endpoint, Auth0 will lose the context of the login transaction and the user will not be able to log in due to an `invalid_request` error.
+    :::
+
+    For example:
+
+    ```http
+    https://${account.namespace}/continue?state=THE_ORIGINAL_STATE
+    ```
+
+    If you're using a custom domain:
+
+    ```http
+    https://YOUR_AUTH0_CUSTOM_DOMAIN/continue?state=THE_ORIGINAL_STATE
+    ```
+
+    `THE_ORIGINAL_STATE` is the value that Auth0 generated and sent to the redirect URL. For example, if your rule redirected to `https://example.com/foo`, Auth0 would use a redirect URL similar to `https://example.com/foo?state=abc123`. So `abc123` would be the `THE_ORIGINAL_STATE`. To resume the authentication transaction, you would redirect to
+
+    ```http
+    https://${account.namespace}/continue?state=abc123
+    ```
+
+    When a user has been redirected to the `/continue` endpoint, **all rules will be run again**, however, the `context.redirect` will be ignored to allow authentication to continue.
+
+::: note
+When a user has been redirected from a rule to the `/continue` endpoint, the user object won't be refreshed. So any updates to user account information during the redirect will not be reflected in the user object. For example, metadata updates that occurred during redirect will not be available.
+:::
+
+## Validate resumed login
+
+To distinguish between user-initiated logins and resumed login flows, check the `context.protocol` property:
+
+```js
+function (user, context, callback) {
+    if (context.protocol === "redirect-callback") {
+        // User was redirected to the /continue endpoint
+    } else {
+        // User is logging in directly
+    }
+}
+```
+
+## Force password change example
+
+In some cases, you may want to force users to change their passwords under specific conditions. You can write a rule that has the following behavior:
+
+1. The user attempts to log in and needs to change their password.
+2. The user is redirected to an application-specific page with a JWT in the query string. This JWT ensures that only this user's password can be changed and **must be validated** by the application.
+3. The user changes their password in the application-specific page by having the application call the [Auth0 Management API](/api/v2#!/Users/patch_users_by_id)
+4. Once the user has successfully changed their password, the application extracts the `authorize_again` claim from the verified and decoded JWT, then proceeds to redirect the user to that URL allowing them to sign in with their new password.
+
+```js
+function(user, context, callback) {
+   /*
+   * Prerequisites:
+   * 1. Implement a `mustChangePassword` function
+   * 2. Set configuration variables for the following:
+   *    - CLIENT_ID
+   *    - CLIENT_SECRET
+   *    - ISSUER
+   */
+
+  const url = require('url@0.10.3');
+  const req = context.request;
+
+  function mustChangePassword() {
+    // TODO: implement function
+    return true;
+  }
+
+  if (mustChangePassword()) {
+    // User has initiated a login and is forced to change their password
+    // Send user's information and query params in a JWT to avoid tampering
+    function createToken(clientId, clientSecret, issuer, user) {
+      const options = {
+        expiresInMinutes: 5,
+        audience: clientId,
+        issuer: issuer
+      };
+      return jwt.sign(user, clientSecret, options);
+    }
+
+    const token = createToken(
+      configuration.CLIENT_ID,
+      configuration.CLIENT_SECRET,
+      configuration.ISSUER,
+      {
+        sub: user.user_id,
+        email: user.email,
+        authorize_again: url.format({
+          protocol: 'https',
+          hostname: auth0.domain,
+          pathname: '/authorize',
+          query: req.query
+        })
+      }
+    );
+
+    context.redirect = {
+      url: `<%= "https://example.com/change-pw?token=${token}"%>`
+    };
+  }
+
+  return callback(null, user, context);
+}
+```
+
+## Where to store data
+
+Beware of storing too much data in the Auth0 profile. This data is intended to be used for authentication and authorization purposes. The metadata and search capabilities of Auth0 are not designed for marketing research or anything else that requires heavy search or update frequency. Your system is likely to run into scalability and performance issues if you use Auth0 for this purpose. A better approach is to store data in an external system and store a pointer (the user ID) in Auth0 so that backend systems can fetch the data if needed. A simple rule to follow is to store only items that you plan to use in rules to add to tokens or make decisions.  
+
+## Security considerations
+
+Passing information back and forth in the front channel opens up surface area for bad actors to attack.  This should definitely be done only in conditions where you must take action in the rule (such as rejecting the authorization attempt with `UnauthorizedError`). 
+
+If, however, you need to communicate directly back to Auth0 and give it instructions for restricting access (you are implementing CAPTCHA checks or custom MFA), then you must have a way to securely tell Auth0 that the requirements of that operation were performed.  Likewise, if you need to hand information to the application that you are redirecting to, then you must have a secure way to ensure that the information transferred has not been tampered with.  
+
+### Ensure app is logging into the same user
+
+The application is going to redirect the user back to the Auth0 tenant, so any data related to the user can be gathered through the ID token that is returned to the application.  However, you may want to ensure that the application is logging into the same user that is being redirected from to ensure that there is no tampering of any sort in-between.  Therefore you will likely want to send a token along with the request.
+
+The token sent to the app should have the following requirements:
+
+| Token Element | Description |
+| -- | -- |
+| `sub` | The Auth0 `user_id` of the user. |
+| `iss` | An identifier that identifies the rule itself. |
+| `aud` | The application that is targeted for the redirect. |
+| `jti` | A randomly generated string that is stored for confirmation in the user object (in the rule code, set user.jti = uuid.v4(); and then add it as a jti to the token you create).  user.jti will still be set when rules run again when /continue is called.  This is inline with specifications. |
+| `exp` | Should be as short as possible to avoid re-use of the token. |
+| `other` | Any other custom claims information you need to pass. |
+| `signature` | Assuming that the application has a secure place to store a secret, you can use HS256 signed signatures.  This greatly reduces the complexity of the solution and since the token being passed back will have to be signed as well, this is a requirement of this solution.  You can use RS256, but it requires the creating of a certificate and updating that certificate when it expires.  If you are not passing any information directly back to the rules, then you could use an SPA for this intermediate app and then may prefer RS256 so that the application doesn't have to store the info.  It would require you to have a way to validate the token, either through an introspection endpoint or through a public JWKS endpoint. |
+
+::: warning
+This token should **not** be treated as a Bearer token!  It is a signed piece of information for use in the application.  The application should still redirect back to Auth0 to authenticate the user.
+:::
+
+### Pass information back to the rule
+
+In most scenarios, even if you want to pass information from the rule to the application.  The application will hopefully be able to safely store the information in whatever storage is necessary.  Even if the idea is to update the app or user metadata in Auth0, that can be done using the management API and the user information will be updated as long as it has been completed before redirecting the user back to the `/continue` endpoint.  Only if the rule itself must get information and that information is only relevant to this particular sign in session should you pass information back to the rule.
+
+When passing information back to the `/continue` endpoint, the token passed should have the following requirements:
+
+| Token Element | Description |
+| -- | -- |
+| `sub` | The Auth0 `user_id` of the user. |
+| `iss` | The application that is targeted for the redirect. |
+| `aud` | Some identifier that identifies the rule itself. |
+| `jti` | The same JTI that was stored in the token passed to the application (NOTE: it should match user.jti or fail). |
+| `exp` | Should be as short as possible to avoid reuse of the token. |
+| `other` | Any other custom claims information you need to pass. |
+| `signature` | Assuming that the application has a secure place to store a secret, you can use HS256 signed signatures.  This greatly reduces the complexity of the solution and since the token being passed back will have to be signed as well, this is a requirement of this solution.  You can use RS256, but it requires the creating of a certificate and updating that certificate when it expires. |
+
+It should be sent using POST and then fetched at `context.request.body.token` (or something similar) rather than passing it as a query parameter.  This is similar to the form-post method for authentication.
+
+If you are not passing information back to the `/continue` endpoint, you may want to blacklist the JTI unless your expiration times are short enough that replay attacks will be almost impossible. 
+
+## Restrictions and limitations
+
+Redirect Rules won't work with:
+- [Resource Owner endpoint](/api/authentication/reference#resource-owner)
+- [Password exchange](/api-auth/grant/password)
+- [Refresh Token exchange](/tokens/concepts/refresh-token#rules)
+
+You can detect the above cases by checking `context.protocol`:
+- For Password exchange: `context.protocol === 'oauth2-password'`
+- For Refresh Token exchange: `context.protocol === 'oauth2-refresh-token'`
+- For Resource Owner logins: `context.protocol === 'oauth2-resource-owner'`
+
+### Resource Owner endpoint
+
+It is impossible to use redirect rules in the context where you are calling /oauth/token directly for the Resource Owner Password Grant.  Since the user is not in a redirect flow to begin with, you can not redirect the user in a rule.  If you attempt to set context.redirect you will get a failed login attempt with the error interaction_required.
+
+### Flows where `prompt=none`
+
+Since the goal of `prompt=none` is to avoid any scenario where the user will be required to enter input, any redirection will result in an `error=interaction_required`.
+
+Since rules run after an authentication session is created, you cannot use `prompt=none` if you have a redirect rule that is attempting to block access to tokens under certain conditions (custom MFA, CAPTCHA with login, etc.).  
+
+You cannot create a redirect flow that blocks token access and bypasses the redirect rule if `prompt=none` because after a failed attempt, a user can simply call again with `prompt=none` and get tokens because their authentication session has been created even though rules failed the first time.
+
+### Refresh tokens
+
+Due to the fact that using a refresh token requires a backchannel call to `/oauth/token`, this will also fail if you set `context.redirect`.
+
+It is difficult to securely verify that any restrictions on login were carried out. There is not a consistent session ID in the context that could be used to collect information associated with the session such as *this user passed MFA challenges*. Therefore, you cannot use `prompt=none` at all. 
+
+Anytime `context.redirect` is set in a rule, if `prompt=none` was passed, then the authorization fails with `error=interaction_required`, but since the user's session is created even if rules fail, we can't trust that a user passed all `context.redirect` challenges and therefore can't use `prompt=none` as a way to get tokens.  
+
+In this specific case, we recommend that you use refresh tokens exclusively, because you can ensure that a user passed challenges if those challenges are required to generate a refresh token.
+
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Resume Authentication](/rules/guides/redirect#resume-authentication)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
diff --git a/fr-ca/articles/rules/index.md b/fr-ca/articles/rules/index.md
new file mode 100644
index 0000000000..87116867e7
--- /dev/null
+++ b/fr-ca/articles/rules/index.md
@@ -0,0 +1,76 @@
+---
+description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+  - concept
+  - index
+useCase: extensibility-rules
+---
+
+# Rules
+
+Rules are JavaScript functions that execute when a user authenticates to your application. They run once the authentication process is complete, and you can use them to customize and extend Auth0's capabilities. For security reasons, your Rules code executes isolated from the code of other Auth0 tenants in a sandbox.
+
+Please note that rules also run during the [token refresh](/tokens/concepts/refresh-tokens) flow.
+
+## Authentication transaction flow
+
+![Rule Flow](/media/articles/rules/flow.png)
+
+1. An app initiates an authentication request to Auth0.
+2. Auth0 routes the request to an Identity Provider through a configured connection.
+3. The user authenticates successfully.
+4. The [ID Token](/tokens/concepts/id-tokens) and/or Access Token is passed through the Rules pipeline, then sent to the app.
+
+## What can I use Rules for?
+
+Among many possibilities, rules can be used to:
+
+* __Enrich user profiles__: query for information on the user from a database/API, and add it to the user profile object.
+* Create __authorization rules__ based on complex logic (anything that can be written in JavaScript).
+* __Normalize attributes__ from different providers beyond what is provided by Auth0.
+* Reuse information from existing databases or APIs for migration scenarios.
+* Keep a __white-list of users__ and deny access based on email.
+* __Notify__ other systems through an API when a login happens in real-time.
+* Enable counters or persist other information. For information on storing user data, see: [Metadata in Rules](/rules/guides/metadata).
+* Modify tokens: Change the returned __scopes__ of the Access Token and/or add claims to it, and to the ID Token.
+
+There are [many uses for Rules](/rules/references/use-cases). In the Dashboard, you can find example templates to help you get started with Rules under [**Rules > Create Rule**](${manage_url}/#/rules/new). The examples help you with things like MFA, external webhooks, enriching profile information, altering the authentication process, and more. You can use these templates as a starting point, then customizing them to suit your specific needs.
+
+::: warning How to Handle Rate Limits when calling Auth0 APIs
+For rules that call Auth0 APIs, you should always handle rate limiting by checking the X-RateLimit-Remaining header and acting appropriately when the number returned nears 0. You should also add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 429 (Too Many Requests); in this case, if a re-try is needed, it is best to allow for a back-off to avoid going into an infinite re-try loop. For more information about rate limits, see [Rate Limit Policy For Auth0 APIs](/policies/rate-limits).
+:::
+
+## Syntax
+
+A Rule is a function with the following arguments:
+
+* `user`: the user object as it comes from the identity provider. See [User Object in Rules](/rules/references/user-object) for a list of the available user properties. (However, if you execute the rule in the context of a call made to the delegation endpoint, the `user` object will also include the original JSON Web Token (JWT) claims.)
+
+* `context`: an object containing contextual information of the current authentication transaction, such as the user's IP address, application, or location. Check out the [Context Object in Rules](/rules/references/context-object) page for a list of the available context properties.
+
+* `callback`: a function to send potentially modified tokens back to Auth0, or an error. Because of the async nature of Node.js, it is important to always call the `callback` function or else the script will timeout.
+
+## Execution order
+
+In general, rules execute in the order shown on the Auth0 Dashboard. If a rule depends on the execution of another rule, move the dependent rule lower in the list.
+
+::: note
+Remember that rules run at a specific point within the authentication transaction flow. After rules run, the Redirect, Multi-factor Authentication (MFA), and Consent features must still run (in that order and only if they are required).
+:::
+
+## Available modules
+
+<%= include('./_includes/_supported-modules.md') %> 
+
+## Keep reading
+
+* [Context Object in Rules](/rules/references/context-object)
+* [User Object in Rules](/rules/references/user-object)
+* [Node.js Modules Available in Rules](/rules/references/modules)
+* [Sample Rules](/rules/references/samples)
+* [Rules (Legacy)](/rules/references/legacy)
diff --git a/fr-ca/articles/rules/references/context-object.md b/fr-ca/articles/rules/references/context-object.md
new file mode 100644
index 0000000000..929edfcfb3
--- /dev/null
+++ b/fr-ca/articles/rules/references/context-object.md
@@ -0,0 +1,53 @@
+---
+title: Context Object in Rules
+description: Describes the properties of the context object in Rules that stores information about users' IP addresses, applications, and location. 
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Context Object in Rules
+
+The `context` object stores contextual information about the current authentication transaction, such as the user's IP address, application, or location.
+
+::: note
+If you change token content using the context object within a rule, your changes will be available in tokens after all rules have finished running. If your application also requires multifactor authentication or user consent, the user will be prompted before changes in the token are available.
+:::
+
+## Properties
+
+The following properties are available for the `context` object.
+
+| Property | Description |
+|-|-|
+| `context.tenant` | A string containing the name of the tenant |
+| `context.clientID` | The client id of the application the user is logging in to. |
+| `context.clientName` | The name of the application (as defined on the dashboard). |
+| `context.clientMetadata` | An object for holding other application properties. Its keys and values are strings. |
+| `context.connectionID` | A string containing the connection's unique identifier |
+| `context.connection` | The name of the connection used to authenticate the user (such as: `twitter` or `some-g-suite-domain`) |
+| `context.connectionStrategy` | The type of connection. For social connection `connectionStrategy` === `connection`. For enterprise connections, the strategy will be `waad` (Windows Azure AD), `ad` (Active Directory/LDAP), `auth0` (database connections), and so on. |
+| `context.connectionOptions` | An object representing the options defined on the connection. `connectionOptions.tenant_domain` is a string containing the domain being used for authentication when using an Enterprise connection. `connectionOptions.domain_aliases` is an array containing the optional domains registered as aliases in addition to the primary domain (specified in the `connectionOptions.tenant_domain` property). |
+| `context.connectionMetadata` | An object representing metadata defined on the connection. Its keys and values are strings. |
+| `context.samlConfiguration` | An object that controls the behavior of the SAML and WS-Fed endpoints. Useful for advanced claims mapping and token enrichment (only available for `samlp` and `wsfed` protocol). |
+| `context.protocol` | <%= include('../_includes/_context-prop-protocol.md') %> |
+| `context.stats` | An object containing specific user stats, like `stats.loginsCount`. Note that any of the counter variables returned as part of the `stats` object do not increase during [silent authentication](/api-auth/tutorials/silent-authentication) (as when `prompt=none`). There are also scenarios where the counter variables might increase yet a rule or set of rules do not execute, as in the case of a successful cross-origin authentication followed by a failed token request. |
+| `context.sso` | <%= include('../_includes/_context-prop-sso.md') %> |
+| `context.accessToken` | An object representing the options defined on the Access Token. You can use this object to [add custom namespaced claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) to the Access Token. `context.accessToken.scope` can be used to [change the Access Token's returned scopes](/rules/references/samples#modify-scope-of-access-token).  When provided, it is an array containing permissions in string format. Custom claims will be included in the Access Token after all rules have run. |
+| `context.idToken` | An object representing the options defined on the [ID Token](/tokens/concepts/id-tokens). Used to add custom [namespaced](/tokens/guides/create-namespaced-custom-claims) claims to the ID Token. Custom claims will be included in the ID Token after all rules have run. |
+| `context.original_protocol` | After a [redirect rule](/rules/current/redirect) has executed and the authentication transaction is resumed, this property will be populated with the original protocol used to initiate the transaction. |
+| `context.multifactor` | An object representing the multifactor settings used in [implementing contextual MFA](/mfa). |
+| `context.redirect` | The object used to [implement the redirection of a user from a rule](/rules/current/redirect#how-to-implement-a-redirect). |
+| `context.sessionID` | An internal identification for the authentication session. Value is kept only if `prompt=none` is used in the authorization request. Note that the session ID can change **after** rule execution on other flows, so the value available in `context.sessionID` might not match the new session ID that the user will receive. This makes this value only meaningful when `prompt=none` is used. |
+| `context.request` | <%= include('../_includes/_context-prop-request.md') %> |
+| `context.primaryUser` | The unique user id of the primary account for the user. Used to [link user accounts](/users/concepts/overview-user-account-linking#automatic-account-linking) from various identity providers. |
+| `context.authentication` | <%= include('../_includes/_context-prop-authentication.md') %> |
+| `context.authorization` | <%= include('../_includes/_context-prop-authorization.md') %> |
+
+## Read more
+
+* [Debug Rules](/rules/guides/debug)
+* [User Object](/rules/references/user-object)
+* [Sample Use Cases - Scopes and Claims: Add custom claims to a token](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
\ No newline at end of file
diff --git a/fr-ca/articles/rules/references/legacy.md b/fr-ca/articles/rules/references/legacy.md
new file mode 100644
index 0000000000..99cf62c5fb
--- /dev/null
+++ b/fr-ca/articles/rules/references/legacy.md
@@ -0,0 +1,287 @@
+---
+description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+useCase: extensibility-rules
+---
+
+# Rules (Legacy)
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline and the way rules can be used. We recommend you use the latest version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+**Rules** are functions written in JavaScript that are executed when a user authenticates to your application. They run once the authentication process is complete and you can use them to customize and extend Auth0's capabilities. They can be chained together for modular coding and can be turned on and off individually.
+
+![Rules Flow](/media/articles/rules/flow.png)
+
+1. An app initiates an authentication request to Auth0.
+1. Auth0 routes the request to an Identity Provider through a configured connection.
+1. The user authenticates successfully.
+1. The `user` object representing the logged in user is passed through the Rules pipeline, and returned to the app.
+
+Among many possibilities, Rules can be used to:
+
+* __Profile enrichment__: query for information on the user from a database/API, and add it to the user profile object.
+* Create __authorization rules__ based on complex logic (anything that can be written in JavaScript).
+* __Normalize attributes__ from different providers beyond what is provided by Auth0.
+* Reuse information from existing databases or APIs for migration scenarios.
+* Keep a __white-list of users__ and deny access based on email.
+* __Notify__ other systems through an API when a login happens in real-time.
+* Enable counters or persist other information. (For information on storing user data, see: [Metadata in Rules](/rules/metadata-in-rules).)
+* Enable __multifactor__ authentication, based on context (such as last login, IP address of the user, location, and so on).
+
+## Video: Using Rules
+
+Watch this video learn all about rules in just a few minutes.
+
+<%= include('../../_includes/_video', { id: 'g7dy1fpwc3' }) %>
+
+## Rule Syntax
+
+A Rule is a function with the following arguments:
+
+* `user`: the user object as it comes from the identity provider. For a complete list of the user properties, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes).
+
+* `context`: an object containing contextual information of the current authentication transaction, such as user's IP address, application, location. For a complete list of context properties, see [Context Argument Properties in Rules](/rules/references/context-object).
+
+::: note
+Due to the asynchronous nature of Node.js, you __must__ call the `callback` function. If not, this acts as a blocker and the next rule will not execute. The entire rules sequence must complete within __20 seconds__, otherwise the process times out.
+:::
+
+### Global Functions
+
+If you need to use a function in multiple Rules, you can place the shared function in its own Rule. Within this rule, assign the function to the global object so that you can later call the function in a separate rule.
+
+```js
+if (!global.foo) {
+  global.foo = function () { };
+}
+
+if (!global.bar) {
+  global.bar = function (baz) { };
+}
+```
+
+Rules containing shared functions should be placed at the top of the [Rules list in the Management Dashboard](${manage_url}/#/rules). If this is not the case, calling these functions results in an undefined function error when the Rules execute.
+
+## Examples
+
+To create a Rule, or try the examples below, go to [New Rule](${manage_url}/#/rules/create) in the Rule Editor on the dashboard.
+
+### *Hello World*
+
+This rule will add a `hello` attribute to all users authenticating through any provider.
+
+```js
+function (user, context, callback) {
+  user.hello = 'world';
+  console.log('===> set "hello" for ' + user.name);
+  callback(null, user, context);
+}
+```
+
+::: note
+You can add `console.log` lines for [debugging](#debugging) or use the [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs).
+:::
+
+
+### Add roles to a user
+
+In this example, all authenticated users will get a **guest** role, but `johnfoo@gmail.com` will also be an **admin**:
+
+```js
+function (user, context, callback) {
+  user.roles = [];
+  // only johnfoo is admin
+  if (user.email === 'johnfoo@gmail.com') {
+    user.roles.push('admin');
+  }
+
+  // all users are guest
+  user.roles.push('guest');
+
+  callback(null, user, context);
+}
+```
+
+At the beginning of the rules pipeline, John's `user` object will be:
+
+```js
+{
+  "email": "johnfoo@gmail.com",
+  "family_name": "Foo",
+  "user_id": "google-oauth2|103547991597142817347"
+  //... other properties ...
+}
+```
+
+The `context` object will be:
+
+```js
+{
+  "clientID": "...client_id_of_the_app...",
+  "clientName": "my app",
+  "clientMetadata": {
+    "myKey1": "myValue2",
+    "myKey2": "myValue2"
+  }
+  "connection": "google-oauth2"
+}
+```
+
+After the rule executes, the output that the application will receive is the following `user` object:
+
+```js
+{
+  "email": "johnfoo@gmail.com",
+  "family_name": "Foo",
+  "user_id": "google-oauth2|103547991597142817347",
+
+  //... other props ...
+
+  "roles": ["guest", "admin"]  // NEW PROPERTY ADDED BY THE RULE
+}
+```
+
+::: note
+Properties added in a rule are __not persisted__ in the Auth0 user store. Persisting properties requires calling the Auth0 Management API.
+:::
+
+### Deny access based on a condition
+
+In addition to adding and removing properties from the user object, you can return an *access denied* error.
+
+```js
+function (user, context, callback) {
+  if (user.roles.indexOf('admin') === -1) {
+    return callback(new UnauthorizedError('Only admins can use this'));
+  }
+
+  callback(null, user, context);
+}
+```
+
+This will cause a redirect to your callback URL with an `error` querystring parameter containing the message you set. (such as `https://yourapp.com/callback?error=unauthorized&error_description=Only%20admins%20can%20use%20this`). Make sure to call the callback with an instance of `UnauthorizedError` (not `Error`).
+
+::: note
+Error reporting to the app depends on the protocol. OpenID Connect (OIDC) apps will receive the error in the querystring. SAML apps will receive the error in a `SAMLResponse`.
+:::
+
+## Create Rules with the Management API
+
+Rules can also be created by creating a POST request to `/api/v2/rules` using the [Management APIv2](/api/management/v2#!/Rules/post_rules).
+
+This will creates a new rule according to the following input arguments:
+
+- ``name``: The name of the rule. It can only contain alphanumeric characters, spaces and '-', and cannot start nor end with '-' or spaces.
+
+- ``script`` : Τhe script that contains the rule's code. This is the same as what you would enter when creating a new rule using the [dashboard](${manage_url}/#/rules/create).
+
+- ``order``: This field is optional and contains a `number`. This number represents the rule's order in relation to other rules. A rule with a lower order than another rule executes first. If no order is provided it will automatically be one greater than the current maximum.
+
+- ``enabled``: This field can contain an optional `boolean`. If `true`, the rule will be enabled, if it's `false` it will be disabled.
+
+Example of a body schema:
+
+```
+{
+  "name": "my-rule",
+  "script": "function (user, context, callback) {\n  callback(null, user, context);\n}",
+  "order": 2,
+  "enabled": true
+}
+```
+Use this to create the POST request:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/rules",
+  "headers": [{
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"name\":\"my-rule\",\"script\":\"function (user, context, callback) {callback(null, user, context);}\",\"order\":2,\"enabled\":true}"
+  }
+}
+```
+
+
+## How to Debug Rules
+
+You can add `console.log` lines in the rule's code for debugging. The [Rule Editor](${manage_url}/#/rules/create)  provides two ways for seeing the output:
+
+![Rules Editor](/media/articles/rules/rule-editor.png)
+
+1. **TRY THIS RULE**: opens a pop-up where you can run a rule in isolation. The tool provides a mock **user** and **context** objects. Clicking **TRY** will result on the Rule being run with those two objects as input. `console.log` output will be displayed too.
+
+![Try this Rule](/media/articles/rules/try-rule.png)
+
+2. **REALTIME LOGS**: an [extension](${manage_url}/#/extensions) that displays all logs in real-time for all custom code in your account. This includes all `console.log` output, and exceptions.
+
+3. **DEBUG RULE**: similar to the above, displays instructions for installing, configuring and running the [webtask CLI](https://github.com/auth0/wt-cli) for debugging rules. Paste these commands into a terminal to see the `console.log` output and any unhandled exceptions that occur during Rule execution.
+
+<%= include('../../_includes/_webtask') %>
+
+  For example:
+
+  ```sh
+  ~  npm install -g wt-cli
+  ~  wt init --container "youraccount" --url "https://sandbox.it.auth0.com" --token "eyJhbGci...WMPGI" -p "youraccount-default-logs"
+  ~  wt logs -p "youraccount-default-logs"
+  [18:45:38.179Z]  INFO wt: connected to streaming logs (container=youraccount)
+  [18:47:37.954Z]  INFO wt: webtask container assigned
+  [18:47:38.167Z]  INFO wt: ---- checking email_verified for some-user@mail.com! ----
+  ```
+
+  This debugging method works for rules tried from the dashboard and those actually running during user authentication.
+
+## Cache expensive resources
+
+The code sandbox Rules run on allows storing _expensive_ resources that will survive individual execution.
+
+This example, shows how to use the `global` object to keep a mongodb connection:
+
+```js
+
+  ...
+
+  //If the db object is there, use it.
+  if (global.db){
+    return query(global.db, callback);
+  }
+
+  //If not, get the db (mongodb in this case)
+  mongo('mongodb://user:pass@mymongoserver.com/my-db',  function (db){
+    global.db = db;
+    return query(db, callback);
+  });
+
+  //Do the actual work
+  function query(db, cb){
+    //Do something with db
+    ...
+  });
+
+  ...
+
+```
+
+Notice that the code sandbox in which Rules run on, can be recycled at any time. So your code __must__ always check `global` to contain what you expect.
+
+## Available modules
+
+For security reasons, the Rules code runs in a JavaScript sandbox where you can use the full power of the ECMAScript 5 language.
+
+For a list of currently supported sandbox modules, see: [Modules Supported by the Sandbox](https://auth0-extensions.github.io/canirequire/).
+
+## Read more
+
+* [Redirecting users from within rules](/rules/redirect)
diff --git a/fr-ca/articles/rules/references/modules.md b/fr-ca/articles/rules/references/modules.md
new file mode 100644
index 0000000000..aee9a8c3b9
--- /dev/null
+++ b/fr-ca/articles/rules/references/modules.md
@@ -0,0 +1,13 @@
+---
+title: Node.js Modules Available in Rules
+description: A list of the Node.js modules and libraries that are available when creating Rules.
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Node.js Modules Available in Rules
+
+<%= include('../_includes/_supported-modules.md') %> 
diff --git a/fr-ca/articles/rules/references/samples.md b/fr-ca/articles/rules/references/samples.md
new file mode 100644
index 0000000000..e24de4191a
--- /dev/null
+++ b/fr-ca/articles/rules/references/samples.md
@@ -0,0 +1,154 @@
+---
+title: Rule Examples
+description: A collection of sample Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Rule Examples
+
+In this article you'll find a collection of sample Rules. For more examples, see our Github repo at [auth0/rules](https://github.com/auth0/rules).
+
+## Hello World
+
+This Rule will add a `hello` claim (with the value `world`) to the ID Token that will be afterwards sent to the application.
+
+```js
+function (user, context, callback) {
+  context.idToken["http://mynamespace/hello"] = "world";
+  console.log('===> set "hello" for ' + user.name);
+  callback(null, user, context);
+}
+```
+
+Note that the claim is [namespaced](/tokens/guides/create-namespaced-custom-claims): we named it `http://mynamespace/hello` instead of just `hello`. This is what you have to do in order to add arbitrary claims to an ID Token or Access Token.
+
+::: panel Namespace Identifiers
+Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. Exceptions are `webtask.io` and `webtask.run`, which are Auth0 domains and therefore cannot be used. The namespace URL does not have to point to an actual resource; it's only used as an identifier and will not be called by Auth0. For more information, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+:::
+
+## Add roles to a user
+
+In this example, all authenticated users will get a **guest** role, but `johnfoo@gmail.com` will also be an **admin**:
+
+```js
+function (user, context, callback) {
+  if (user.email === 'johnfoo@gmail.com') {
+    context.idToken["http://mynamespace/roles"] = ['admin', 'guest'];
+  }else{
+    context.idToken["http://mynamespace/roles"] = ['guest'];
+  }
+
+  callback(null, user, context);
+}
+```
+
+At the beginning of the Rules pipeline, John's `context` object will be:
+
+```json
+{
+  "clientID": "YOUR_CLIENT_ID",
+  "clientName": "YOUR_CLIENT_NAME",
+  "clientMetadata": {},
+  "connection": "YOUR_CONNECTION_NAME",
+  "connectionStrategy": "auth0",
+  "protocol": "oidc-implicit-profile",
+  "accessToken": {},
+  "idToken": {},
+  //... other properties ...
+}
+```
+
+After the Rule executes, the `context` object will have the added namespaced claim as part of the ID Token:
+
+```json
+{
+  "clientID": "YOUR_CLIENT_ID",
+  "clientName": "YOUR_CLIENT_NAME",
+  "clientMetadata": {},
+  "connection": "YOUR_CONNECTION_NAME",
+  "connectionStrategy": "auth0",
+  "protocol": "oidc-implicit-profile",
+  "accessToken": {},
+  "idToken": { "http://mynamespace/roles": [ "admin", "guest" ] },
+  //... other properties ...
+}
+```
+
+When your application receives the ID Token, it will verify and decode it in order to access this added custom claim. The payload of the decoded ID Token will be similar to the following sample:
+
+```json
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|USER_ID",
+  "aud": "YOUR_CLIENT_ID",
+  "exp": 1490226805,
+  "iat": 1490190805,
+  "nonce": "...",
+  "at_hash": "...",
+  "http://mynamespace/roles": [
+    "admin",
+    "guest"
+  ]
+}
+```
+
+For more information on the ID Token, refer to [ID Token](/tokens/concepts/id-tokens).
+
+::: note
+Properties added in a Rule are __not persisted__ in the Auth0 user store. Persisting properties requires calling the Auth0 Management API.
+:::
+
+## Deny access based on a condition
+
+In addition to adding claims to the ID Token, you can return an *access denied* error.
+
+```js
+function (user, context, callback) {
+  if (context.clientID === "BANNED_CLIENT_ID") {
+    return callback(new UnauthorizedError('Access to this application has been temporarily revoked'));
+  }
+
+  callback(null, user, context);
+}
+```
+
+This will cause a redirect to your callback URL with an `error` querystring parameter containing the message you set. (such as `https://yourapp.com/callback?error=unauthorized&error_description=Access%20to%20this%20application%20has%20been%20temporarily%20revoked`). Make sure to call the callback with an instance of `UnauthorizedError` (not `Error`).
+
+::: note
+Error reporting to the app depends on the protocol. OpenID Connect (OIDC) apps will receive the error in the querystring. SAML apps will receive the error in a `SAMLResponse`.
+:::
+
+## Copy user metadata to ID Token
+
+This will read the `favorite_color` user metadata, and add it as a namespaced claim at the ID Token.
+
+```js
+function(user, context, callback) {
+
+  // copy user metadata value in ID Token
+  context.idToken['http://fiz/favorite_color'] = user.user_metadata.favorite_color;
+
+  callback(null, user, context);
+}
+```
+
+## Add claims to Access Token
+
+This will add one custom namespaced claim at the Access Token.
+
+```js
+function(user, context, callback) {
+
+  // add custom claims to Access Token
+  context.accessToken['http://foo/bar'] = 'value';
+
+  callback(null, user, context);
+}
+```
+
+After this Rule executes, the Access Token will contain one additional namespaced claim: `http://foo/bar=value`.
\ No newline at end of file
diff --git a/fr-ca/articles/rules/references/use-cases.md b/fr-ca/articles/rules/references/use-cases.md
new file mode 100644
index 0000000000..0db47d8b72
--- /dev/null
+++ b/fr-ca/articles/rules/references/use-cases.md
@@ -0,0 +1,233 @@
+---
+description: Rules use cases for Auth0
+title: Rules Use Cases
+classes: topic-page
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+  - index
+useCase: extensibility-rules
+---
+
+
    
+  
    
+  
    Rules Use Cases
    
+  
    The following is a list of Rules for implementing a variety of functionality in Auth0.
    
+  
    Before proceeding, please review our best practice recommendations for working with Rules. See also our security bulletin regarding vulnerable patterns when working with custom rules code.
    
+
    
+
+
    API Authorization
    
+
+
+
+
    Authorization
    
+
+
+
+
    Compliance
    
+
+
+
+
    Connections
    
+
+
+
+
    Email
    
+
+
+
+
    Extensions
    
+
+
+
+
    Integrations
    
+
+
+
+
    Login
    
+
+
+
+
    Monitoring
    
+
+
+
+
    Monitoring
    
+
+
+
+
    Multi-Factor Authentication
    
+
+
+
+
    SAML
    
+
+
+
+
    Tokens
    
+
+
+
+
    User Management
    
+
+
diff --git a/fr-ca/articles/rules/references/user-object.md b/fr-ca/articles/rules/references/user-object.md
new file mode 100644
index 0000000000..9ceda737ca
--- /dev/null
+++ b/fr-ca/articles/rules/references/user-object.md
@@ -0,0 +1,45 @@
+---
+title: User Object in Rules
+description: Describes the properties of the user object that stores information about the logged in user, returned by the identity provider. 
+topics:
+  - rules
+  - extensibility
+  - identity-providers
+contentType: reference
+useCase: extensibility-rules
+---
+
+# User Object in Rules
+
+The `user` object stores information about the logged-in user, returned by the identity provider. It is generated when a user authenticates and before rules run. Because of the [order of events](/rules#authentication-transaction-flow) when a user authenticates, changes made to a user's profile from within a rule will only be available in the current user object if you also save the changes to the user object from within the same rule.
+
+## Properties
+
+The following properties are available for the `user` object.
+
+| Property | Data Type        | Description |
+|----------|------------------|-------------|
+| `user.app_metadata` | object | Custom fields that store info about a user that influences the user's access, such as support plan, security roles, or access control groups. For more info, see [Metadata](/metadata). |
+| `user.created_at` | date time | Timestamp indicating when the user profile was first created. |
+| `user.email` | text | (unique) The user's email address. |
+| `user.email_verified` | boolean | Indicates whether the user has verified their email address. |
+| `user.family_name` | text | The user's family name. |
+| `user.given_name` | text | The user's given name. |
+| `user.identities` | array (object) |  <%= include('../_includes/_user-prop-identities.md') %> |
+| `user.last_password_reset` | date time | Timestamp indicating the last time the user's password was reset/changed. At user creation, this field does not exist. This property is only available for Database connections. |
+| `user.multifactor` | array (text) | List of multi-factor authentication (MFA) providers with which the user is enrolled. This array is updated when the user logs in with MFA successfully for the first time, and is not updated when enrollment is completed or when an administrator resets a user's MFA. |
+| `user.name` | text | The user's full name. |
+| `user.nickname` | text | The user's nickname. |
+| `user.permissions` | text | The permissions assigned to the user's ID token |
+| `user.phone_number` | text  | The user's phone number. Only valid for users with SMS connections. |
+| `user.phone_verified` | boolean | Indicates whether the user has verified their phone number. Only valid for users with SMS connections. |
+| `user.picture` | text | URL pointing to [the user's profile picture](/user-profile/user-picture). |
+| `user.updated_at` | date time | Timestamp indicating when the user's profile was last updated/modified. Changes to `last_login` are considered updates, so most of the time, `updated_at` will match `last_login`. |
+| `user.user_id` | text | (unique) The user's unique identifier. |
+| `user.user_metadata` | object | Custom fields that store info about a user that does not impact what they can or cannot access, such as work address, home address, or user preferences. For more info, see [Metadata](/metadata). |
+| `user.username` | text | (unique) The user's username. |
+
+## Read more
+
+* [Debug Rules](/rules/guides/debug)
+* [Context Object](/rules/references/context-object)
\ No newline at end of file
diff --git a/fr-ca/articles/scopes/current/api-scopes.md b/fr-ca/articles/scopes/current/api-scopes.md
new file mode 100644
index 0000000000..dae3ed63a1
--- /dev/null
+++ b/fr-ca/articles/scopes/current/api-scopes.md
@@ -0,0 +1,76 @@
+---
+title: API Scopes
+description: Understand the principle of scopes and how it is used with APIs.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+useCase:
+  - development
+  - call-api
+  - secure-api
+---
+# API Scopes
+
+As an [API](/apis) developer, you need to:
+
+1. Decide which information you would like applications to be able to access on a user's behalf.
+2. Define these access levels as custom scopes.
+3. Identify these scopes so that calling applications can use them. 
+
+## Ways to use API scopes
+
+You can use API scopes in different ways:
+
+* In an API where the calling application is a third-party, or external, application. In this case, the calling application will request authorization from the user to access the requested scopes, and the user will approve or deny the request.
+* In an API where the calling application is a first-party application, or application that is registered under the same Auth0 domain as the API it is calling. In this case, by default, user consent is not requested, but you may configure consent to be required.
+* In an API where the calling application is a back-end service, whether third-party or first-party, and no user exists. In this case, user consent is never requested.
+
+::: note
+All of these examples use scopes to limit access through use of a token. If you so choose, your API may also use additional logic beyond the token to enforce more extensive access control.
+:::
+
+For an example showing how to request custom API access for your application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#request-custom-API-access).
+
+### Example: An API called by a third-party application
+
+Let's say you are building an API that provides bank account information to online payment applications. At various times, apps may need to read account balances or transfer funds. To do this, you create two scopes for your API: one that authorizes read access to an account balance (`read:balance`), one that authorizes fund transfers (`transfer:funds`). Your API is registered with Auth0.
+
+A calling application will request authorization from the user to access the requested scopes, and the user will approve or deny the request. The app may request read access to the user's balance by including the `read:balance` scope in its request, access to make fund transfers by including the `transfer:funds` scope in its request, or access to both read the user's balance and transfer funds by including both the `read:balance` and `transfer:funds` scopes in its request. 
+
+Now, when the app calls your API, it will include a token which verifies that the user has provided authorization to access their content and also indicates which scopes the user has approved. Your API should respect the approved scopes and only release information that was authorized by the user to the calling application. 
+
+### Example: An API called by a first-party application
+
+Let's say you are building an API that provides data to an events application, which you have also written. You implement [role-based access control (RBAC)](/authorization/concepts/rbac), creating a role of `organizer` and a role of `participant`. Users with a role of `organizer` need to create and update events, whereas users with a role of `participant` need to view events and register for events. To do this, you create four scopes for your API: one that authorizes create access for events(`create:events`), one that authorizes update access for events (`update:events`), one that authorizes read-only access for events (`view:events`), and one that authorizes registration access for events (`register:events`). Both your API and event application are registered with Auth0, and the **Allow Skipping User Consent** for first-party applications option is enabled for your API. You have installed the Authorization Extension and configured an `organizer` role and created the `create:events` and `update:events` scopes for it, and assigned it to User A. You have also configured a `participant` role and created the `view:events` and `register:events` scopes for it, and assigned it to User B.
+
+User A authenticates with the calling application, which requests the necessary scopes, but because it is a first-party application, user consent will not be requested. The app may request any combination of `create:events`, `update:events`, `view:events`, and `register:events` scopes, but User A is recognized as having the role of `organizer` and therefore is only granted the `create:events` and `update:events` scopes.
+
+Now, when the app calls your API, it will include a token which verifies that it has authorization for only the scopes associated with the role of the authenticated user.
+
+### Example: An API called by a back-end service
+
+Let's say you work for a hospital and have an API that produces large amounts of imaging data whenever a patient gets an MRI. You store the imaging data locally for six months, but the hospital needs the images to be stored long-term for the purpose of regulatory compliance. Because of this, the hospital has a service that copies imaging data to an offsite cold storage solution on a nightly basis and deletes all local medical data after six months of storage.
+
+To do this, you create two scopes for your API: one that authorizes read access to your imaging data (`read:images`) and one that authorizes delete access to your imaging data (`delete:images`). Your API and automated service are registered with Auth0, and you have authorized the automated service to request tokens for your API.
+
+The calling automated service will request the necessary scopes, but because there is no user, consent will not be requested. The service may request read access to your imaging data by including the `read:images` scope in its request, delete access by including the `delete:images` scope in its request, or both read and delete access by including the `read:images` and `delete:images` scopes in its request.
+
+Now, when the automated service calls your API, it will include a token which verifies that it has authorization for the requested scopes.
+
+## Limit API scopes
+
+An application can include any scope defined for an API in its request. Instead of allowing all available scopes to be requested, however, you can limit scopes for certain users. For example, a user of your application can be given a role so that requests on their behalf are limited to just the scopes assigned to that role. To do this, you can use the [Authorization Extension](/extensions/authorization-extension) and a custom [Rule](/rules).
+
+We discuss this approach in more depth in our [SPA+API Architecture Scenario](/architecture-scenarios/spa-api). Specifically, you can review the [Configure the Authorization Extension](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension) section to learn how to configure the Authorization Extension and create a custom Rule that will ensure scopes are granted based on a user's role.
+
+
+## Keep reading
+
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Add API Permissions (Scopes)](/dashboard/guides/apis/add-permissions-apis)
+- [How to Customize the Consent Prompt](/scopes/current/guides/customize-consent-prompt)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
diff --git a/fr-ca/articles/scopes/current/guides/customize-consent-prompt.md b/fr-ca/articles/scopes/current/guides/customize-consent-prompt.md
new file mode 100644
index 0000000000..437fdd21df
--- /dev/null
+++ b/fr-ca/articles/scopes/current/guides/customize-consent-prompt.md
@@ -0,0 +1,77 @@
+---
+title: Customize the Consent Prompt
+description: Learn how to customize the consent prompt presented to users during authorization.
+topics:
+  - scopes
+  - permissions
+  - authorization
+  - consent-prompt
+  - mgmt-api
+contentType:
+  - how-to
+useCase:
+  - development
+  - secure-api
+---
+# Customize the Consent Prompt
+
+When a third-party application requests scopes, users see a consent prompt. By default, this prompt uses the scope **name** to generate text and groups all scopes for a resource, displaying the resource's actions in a single line.
+
+<%= include('../../../_includes/_parental-consent') %>
+
+For example, let's say you have an Auth0-registered API with the following defined scopes:
+
+* `read:messages`: Be able to read your email messages
+* `write:messages`: Write messages
+
+The consent prompt will display: **Messages: read and write your messages**.
+
+Instead, you can use your defined scope **description** to generate this text. In this case, the consent dialog would display: **Be able to read your email messages**, **Write messages**.
+
+::: warning
+This change is made at the tenant level, so it will affect consent prompts for all APIs on the tenant.
+:::
+
+## Use scope descriptions to generate consent prompt text
+
+Set your tenant's **use_scope_descriptions_for_consent** flag to `true` by making the following API call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": true } }"
+  }
+}
+```
+
+## Use scope names to generate consent prompt text
+
+Set your tenant's **use_scope_descriptions_for_consent** flag to `false` by making the following API call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": false } }"
+  }
+}
+```
+
+## Keep reading
+
+- [How to Define Scopes for an API Using the Auth0 Dashboard](/scopes/current/guides/define-api-scopes-dashboard)
diff --git a/fr-ca/articles/scopes/current/index.md b/fr-ca/articles/scopes/current/index.md
new file mode 100644
index 0000000000..e510f4a386
--- /dev/null
+++ b/fr-ca/articles/scopes/current/index.md
@@ -0,0 +1,62 @@
+---
+url: /scopes/current
+section: articles
+classes: topic-page
+title: Scopes
+description: Understand the principle of scopes and explore general examples of their use.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+  - index
+useCase:
+  - development
+  - add-login
+  - secure-api
+  - call-api
+---
+# Scopes
+
+Different pieces of user information are often stored across a number of online resources. Users may upload and store photos with a service like Flickr, keep digital files on Dropbox, and store contacts and events in Google Calendar or on Facebook.
+
+Often, new applications will want to make use of the information that has already been created in an online resource. To do so, the application must ask for authorization to access this information on a user's behalf. _Scopes_ define the specific actions applications can be allowed to do on a user's behalf.
+
+## Ways to use scopes
+
+When an app requests permission to access a resource through an authorization server, it uses the `scope` parameter to specify what access it needs, and the authorization server uses the `scope` parameter to respond with the access that was actually granted (if the granted access was different from what was requested).
+
+Generally, you use scopes in three ways:
+
+* From an [application](/applications), to verify the identity of a user and get basic profile information about the user, such as their email or picture. In this scenario, the scopes available to you include those implemented by the OpenID Connect (OIDC) protocol. For details, see [OpenID Connect Scopes](/scopes/current/oidc-scopes).
+
+* In an [API](/apis), to implement access control. In this case, you need to define custom scopes for your API and then identify these scopes so that calling applications can use them. For details, see [API Scopes](/scopes/current/api-scopes).
+
+* From an application, to call an API that has implemented its own custom scopes. In this case, you need to know which custom scopes are defined for the API you are calling. For an example of calling a custom API from an application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#request-custom-API-access)
+
+## Best practices
+
+Understand your use case and choose the most restrictive scopes possible. 
+
+If you are requesting scopes, make sure you ask for enough access for your application to function, but only request what you absolutely need. Are you establishing a user's identity or asking the user to allow you to interact with their data? There's a big difference between importing a user's Facebook profile information and posting to their wall. By only requesting what you need, you are more likely to gain user consent when required since users are more likely to grant access for limited, clearly-specified scopes. 
+
+Similarly, when creating custom scopes for an API, consider what levels of granular access applications may need and design accordingly.
+
+## Requested scopes versus granted scopes
+
+In certain cases, users get to consent to the access being requested. While usually the scopes returned will be identical to those requested, users can edit granted scopes (both during initial consent and sometimes after, depending on the resource), thereby granting an app less access than it requested. 
+
+As an application developer, you should be aware of this possibility and handle these cases in your app. For example, your app could warn the user that they will see reduced functionality. It could also send the user back through the authorization flow to ask for additional permissions. But again, remember that when asked for consent, users can always say no.
+
+::: note
+By default, Auth0 skips user consent for first-party applications, which are applications that are registered under the same Auth0 domain as the API they are calling; however, you can configure your API in Auth0 to require user consent from first-party applications. Third-party applications, which are external applications, require user consent.
+:::
+
+## Keep reading
+
+- [OpenID Connect Scopes](/scopes/current/oidc-scopes)
+- [API Scopes](/scopes/current/api-scopes)
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
diff --git a/fr-ca/articles/scopes/current/oidc-scopes.md b/fr-ca/articles/scopes/current/oidc-scopes.md
new file mode 100644
index 0000000000..58c9fbe902
--- /dev/null
+++ b/fr-ca/articles/scopes/current/oidc-scopes.md
@@ -0,0 +1,59 @@
+---
+title: OpenID Connect Scopes
+description: Understand scopes and claims used with the OpenID Connect (OIDC) protocol.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+---
+# OpenID Connect Scopes
+
+:::note 
+This document discusses scopes included within the OpenID Connect (OIDC) authentication protocol. For more info about OIDC itself, see our docs on [OpenID Connect](/protocols/oidc).
+:::
+
+OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to a user's details, like name and picture. Each scope returns a set of user attributes, which are called _claims_. The scopes an application should request depend on which user attributes the application needs. Once the user authorizes the requested scopes, the claims are returned in an ID Token and are also available through the [/userinfo endpoint](/api/authentication#get-user-info).
+
+For example, let's say you have built a regular web application, registered it with Auth0, and have configured it to allow a user to log in using a username and password. Once a user logs in to your app, you want to auto-generate and send a personalized welcome email, including the user's name.
+
+1. A user clicks **Login** within your app.
+2. Your app redirects the user to the Auth0 Authorization Server (**/authorize** endpoint), including the following scopes: 
+* `openid` (required; to indicate that the application intends to use OIDC to verify the user's identity)
+* `profile` (so you can personalize the email with the user's name)
+* `email` (so you know where to send the welcome email)
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user authenticates and sees a consent page listing the scopes Auth0 will give to your app, which include access to their profile information and email address.
+5. The user accepts and authorizes your app to have this level of access to their information stored by Auth0.
+6. Your app now has access to the user's profile information and email address.
+
+## Standard claims
+
+Standard claims are intended to provide an application with user details, such as name, email, and picture, and are pre-defined for the OIDC protocol. These claims are returned in an ID Token and are also available through the [/userinfo endpoint](/api/authentication#get-user-info).
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a rule. 
+:::
+
+The basic (and required) scope for OIDC is `openid`, which indicates that an application intends to use the OIDC protocol to verify a user's identity. Beyond that, an application can ask for additional scopes by listing the requested scope names in the `scope` parameter, separated by spaces. 
+
+Standard claims included in the most commonly-used scopes are listed below, but for a full list of available standard claims, refer to the [OIDC specification: Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). For a full list of Scopes, see [OIDC specification: Requesting Claims Using Scope Values](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims).
+
+
+| Scope     | Claims          |
+|-----------|-----------------|
+| `openid`  | (required) Returns the `sub` claim, which uniquely identifies the user. In an ID Token, `iss`, `aud`, `exp`, `iat`, and `at_hash` claims will also be present. For more information about the ID Token claims, see [ID Tokens](/tokens/concepts/id-tokens#id-token-payload). |
+| `profile` | Returns claims that represent basic profile information, including `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `picture`, and `updated_at`. |
+| `email`   | Returns the `email` claim, which contains the user's email address, and `email_verified`, which is a boolean indicating whether the email address was verified by the user. |
+
+For an example showing how to request standard claims for your application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#authenticate-a-user-and-request-standard-claims).
+
+## Keep reading
+
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Scopes](/scopes)
+- [Custom Claims](/tokens/concepts/jwt-claims#custom-claims)
+- [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
diff --git a/fr-ca/articles/scopes/current/sample-use-cases.md b/fr-ca/articles/scopes/current/sample-use-cases.md
new file mode 100644
index 0000000000..fe4ea0d57c
--- /dev/null
+++ b/fr-ca/articles/scopes/current/sample-use-cases.md
@@ -0,0 +1,233 @@
+---
+title: Sample Use Cases - Scopes and Claims
+description: Learn how to use scopes and claims with applications and APIs.
+topics:
+  - scopes
+contentType:
+  - how-to
+useCase:
+  - development
+  - add-login
+  - call-api
+  - secure-api
+---
+# Sample Use Cases: Scopes and Claims
+
+In these examples, we use the [Authorization Code Flow](/flows/concepts/auth-code) to authenticate a user and request the necessary permissions (scopes) and tokens. For details on the request parameters or to learn how to fully implement this flow, refer to our tutorial: [Add Login to Regular Web Applications](/flows/guides/auth-code/add-login-auth-code).
+
+## Authenticate a user and request standard claims
+
+In this example, we want to authenticate a user and get user details that will allow us to personalize our UI. To do this, we want to get an ID Token that contains the user's name, nickname, profile picture, and email information.
+
+1. Initiate the authentication flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  scope=openid%20profile%20email&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example: 
+
+* the `response_type` parameter includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the ID Token we need for authentication.)
+* the `scope` parameter includes three values, the requested OIDC scopes: 
+  * `openid` (to indicate that the application intends to use OIDC to verify the user's identity)
+  * `profile` (to get `name`, `nickname`, and `picture`)
+  * `email` (to get `email` and `email_verified`)
+
+2. After the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the ID Token from the response and [decode it](/tokens/id-tokens#id-token-payload).
+
+You should see the following claims:
+
+```json
+{
+  "name": "John Doe",
+  "nickname": "john.doe",
+  "picture": "https://myawesomeavatar.com/avatar.png",
+  "updated_at": "2017-03-30T15:13:40.474Z",
+  "email": "john.doe@test.com",
+  "email_verified": false,
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|USER-ID",
+  "aud": "${account.clientId}",
+  "exp": 1490922820,
+  "iat": 1490886820,
+  "nonce": "crypto-value",
+  "at_hash": "IoS3ZGppJKUn3Bta_LgE2A"
+}
+```
+
+Your app now can retrieve the user attributes and use them to personalize your UI.
+
+
+## Request custom API access
+
+In this example, we request a custom scope for a calendar API that will authorize the calling application to read appointments for the user. To do this, we want to get an Access Token containing the proper scope to read appointments from the API. Note that requesting an Access Token is not dependent on requesting an ID Token.
+
+::: note
+Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and [define the scopes for your API using the Auth0 Dashboard](/scopes/current/guides/define-api-scope-dashboard). You can also use defined permissions to [customize the consent prompt](/scopes/current/guides/customize-consent-prompt) for your users.
+:::
+
+1. Initiate the authorization flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}& 
+  scope=read:appointments&
+  audience=YOUR_API_AUDIENCE&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example:
+
+* the `response_type` parameter still includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the Access Token that we can use to call our API.)
+* the `scope` parameter includes one value, the requested API scope: 
+  * `read:appointments` (to allow us to read the user's appointments from the API)
+* the `audience` parameter is new and includes one value:
+  * the unique identifier of the API from which we want to read the user's appointments
+
+2. As in the previous example, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the Access Token from the response, and call the API using the Access Token as credentials.
+
+
+## Authenticate a user and request standard claims and custom API access
+
+In this example, we combine our previous two examples to authenticate a user, request standard claims, and also request a custom scope for a calendar API that will allow the calling application to read appointments for the user. To do this, we want to get two tokens--an ID Token that contains the user's name, nickname, profile picture, and email information, and an Access Token containing the proper scope to read appointments from the API. Note that requesting an Access Token is not dependent on requesting an ID Token.
+
+::: note
+Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and [define the scopes for your API using the Auth0 Dashboard](/scopes/current/guides/define-api-scope-dashboard). You can also use defined permissions to [customize the consent prompt](/scopes/current/guides/customize-consent-prompt) for your users.
+:::
+
+1. Initiate the authentication flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}& 
+  scope=openid%20profile%20email%20read:appointments&
+  audience=YOUR_API_AUDIENCE&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example:
+
+* the `response_type` parameter still includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive both the ID Token we need for authentication and the Access Token that we can use to call our API.)
+* the `scope` parameter is used for both OIDC scopes and API scopes, so now includes four values: 
+  * `openid` (to indicate that the application intends to use OIDC to verify the user's identity)
+  * `profile` (to get `name`, `nickname`, and `picture`)
+  * `email` (to get `email` and `email_verified`)
+  * `read:appointments` (to allow us to read the user's appointments from the API)
+* the `audience` parameter includes one value:
+  * the unique identifier of the API from which we want to read the user's appointments
+
+2. As in the previous examples, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the ID Token from the response, [decode it](/tokens/id-tokens#id-token-payload), and retrieve the user attributes and use them to personalize your UI.
+
+4. Extract the Access Token from the response, and call the API using the Access Token as credentials.
+
+
+## Add custom claims to a token
+
+In this example, we add a user's favorite color and preferred contact method to the ID Token. To do this, we create a [rule](/rules) to customize the token by adding these claims using a [namespaced format](/tokens/guides/create-namespaced-custom-claims). Once added, we will also be able to obtain the custom claims when calling the `/userinfo` endpoint (though the rule will run only during the authentication process).
+
+<%= include('../../_includes/_enforce-claim-namespacing') %>
+
+Suppose that:
+
+* The user logged in using an identity provider that returned a `favorite_color` claim as part of their user profile.
+* At some point, the user selected a `preferred_contact` method of `email`, and we saved it as part of the [user's `user_metadata`](/users/concepts/overview-user-metadata).
+* We've used the Auth0 Management API to set application-specific information for this user.
+
+In this case, the Auth0-stored [normalized user profile](/users/normalized) is:
+
+```json
+{
+  "email": "jane@example.com",
+  "email_verified": true,
+  "user_id": "custom|123",
+  "favorite_color": "blue",
+  "user_metadata": {
+    "preferred_contact": "email"
+  }
+}
+```
+
+For this profile, Auth0 would normally return the following ID Token claims to your application:
+
+```json
+{
+  "email": "jane@example.com",
+  "email_verified": true,
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "custom|123",
+  "aud": "my_client_id",
+  "iat": 1311280970,
+  "exp": 1311281970
+}
+```
+
+Notice that in this example:
+
+ * the `sub` claim contains the value of the `user_id` property
+ * neither the `favorite_color` nor `user_metadata` properties are present because OpenID Connect (OIDC) does not define standard claims that represent `favorite_color` or `user_metadata`
+ 
+To receive the custom data, create a rule to customize the token with [namespaced](/tokens/guides/create-namespaced-custom-claims) [custom claims](/tokens/concepts/jwt-claims#custom-claims) that represent these properties from the user profile. Custom data will be available in the token after all rules have run.
+
+```js
+function(user, context, callback) {
+  const namespace = 'https://myapp.example.com/';
+  context.idToken[namespace + 'favorite_color'] = user.favorite_color;
+  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
+  callback(null, user, context);
+}
+```
+
+::: note
+This example shows custom claims being added to an ID Token, which uses the `context.idToken` property. To add to an Access Token, use the `context.accessToken` property instead. To learn more, see [Context Object in Rules](/rules/references/context-object).
+:::
+
+::: warning
+When creating your rule, make sure to set some logic that determines when to include additional claims. Injecting custom claims into every ID Token that is issued is not ideal.
+:::
+
+With this rule enabled, Auth0 will include the `favorite_color` and `preferred_contact` custom claims in the ID Token:
+
+```json
+{
+  "https://myapp.example.com/favorite_color": "blue",
+  "https://myapp.example.com/preferred_contact": "email",
+  "email": "jane@example.com",
+  "email_verified": true,
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "custom|123",
+  "aud": "my_client_id",
+  "iat": 1311280970,
+  "exp": 1311281970
+}
+```
+
+## Keep reading
+
+- [Scopes](/scopes)
+- [OpenID Connect (OIDC) Scopes](/scopes/current/oidc-scopes)
+- [Custom Claims](/tokens/concepts/jwt-claims#custom-claims)
+- [API Scopes](/scopes/current/api-scopes)
+- [Add API Permissions (Scopes)](/dashboard/guides/apis/add-permissions-apis)
+- [Customize the Consent Prompt](/scopes/current/guides/customize-consent-prompt)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
+
diff --git a/fr-ca/articles/scopes/index.yml b/fr-ca/articles/scopes/index.yml
new file mode 100644
index 0000000000..effcc8c22d
--- /dev/null
+++ b/fr-ca/articles/scopes/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: scopes
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/fr-ca/articles/scopes/legacy/index.md b/fr-ca/articles/scopes/legacy/index.md
new file mode 100644
index 0000000000..7fceba1b84
--- /dev/null
+++ b/fr-ca/articles/scopes/legacy/index.md
@@ -0,0 +1,79 @@
+---
+description: Overview of scopes with a client-side authorization transaction.
+topics:
+  - scopes
+contentType:
+  - reference
+  - concept
+  - index
+useCase:
+  - development
+---
+
+# Scopes
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline and the way scopes should be used. We recommend you use the latest version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+When initiating a client-side authorization transaction through the [`/authorize` endpoint](/api/authentication/reference#social), only an opaque Access Token will be returned by default. To also return a JWT that authenticates the user and contains their profile information, the `scope` parameter can be sent as part of the request.
+
+## Example (implicit flow)
+
+The following URL logs a user in using Google and requests a JWT that authenticates the user.
+
+```html
+
    +https://example.auth0.com/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=http://jwt.io&connection=google-oauth2
+  &scope=openid
+
    
+```
+
+After a successful transaction, the user would be redirected here:
+
+```html
+
+
    +http://jwt.io/
+  #access_token=s213Mvz1QW7XpjoX
+  &id_token=eyJ0...
+  &token_type=Bearer
+  &state=mep7BLYt1lAsLC94
+
    
+    
+```
+
+When decoded, this token contains the following claims:
+
+```json
+{
+  "iss": "https://example.auth0.com/",
+  "sub": "google-oauth2|112396309096036300109",
+  "aud": "jGMow0KO3WDJELW8XIxolqb1XIitjkYL",
+  "exp": 1437560381,
+  "iat": 1437510381
+}
+```
+
+## Requesting specific claims
+
+The attributes included in the issued token can be controlled with the `scope` parameter as follows:
+
+* `scope=openid`: will only return `iss`, `sub`, `aud`, `exp` and `iat` claims.
+* `scope=openid email nickname favorite_food`: will return claims for `openid` in addition to the `email`, `nickname` and `favorite_food` fields if they are available.
+* `scope=openid profile`: will return all the user attributes in the token. Beware when you use this option because if you have too many user attributes the ID Token will increase in size and might break the URL limits for some browsers.
+
+::: note
+The `scope` parameter can be used in the same way when calling the [Resource Owner endpoint](/api/authentication/reference#resource-owner).
+:::
+
+## Keep reading
+
+::: next-steps
+* [Sending a `scope` parameter with Lock](/libraries/lock/sending-authentication-parameters#scope-string-)
+* [Retrieving the full user profile with an Access Token](/api/authentication/reference#get-user-info)
+* [Validating a JWT and obtaining the full user profile](/api/authentication/reference#get-token-info)
+:::
diff --git a/fr-ca/articles/security/blacklisting-attributes.md b/fr-ca/articles/security/blacklisting-attributes.md
new file mode 100644
index 0000000000..32b85c318a
--- /dev/null
+++ b/fr-ca/articles/security/blacklisting-attributes.md
@@ -0,0 +1,78 @@
+---
+description: How to blacklist user attributes that you do not want to save in Auth0 databases
+toc: true
+crews: crew-2
+topics:
+  - security
+  - security-bulletins
+  - blacklisting
+  - users
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Blacklist User Attributes
+
+If there are user fields that should not be stored in Auth0 databases due to privacy reasons, you can blacklist them.
+
+## Use the Management API
+
+To blacklist attributes make a `PATCH` call to the [Update Connection](/api/management/v2#!/Connections/patch_connections_by_id) endpoint of the Management API.
+
+### Step 1. Get a token
+
+First, you need a valid Access Token to access that endpoint. The token must include the `update:connections` scope. 
+
+For detailed steps on how to get one, see [Access Tokens for the Management API](/api/management/v2/tokens).
+
+### Step 2. Call the API
+
+Once you have the token (and the list of attributes to be blacklisted), you are ready to call the API. 
+
+Here is a sample HTTP request that blacklists two attributes: `ethnicity` and `gender`.
+
+
+```js
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_TOKEN" }
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+  "queryString" : [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"options\": {\"non_persistent_attrs\": [\"ethnicity\", \"gender\"]}}"
+  },
+  "headersSize" : -1,
+  "bodySize" : -1,
+  "comment" : ""
+}
+```
+
+Where:
+
+- `YOUR_CONNECTION_ID` is the Id of the connection for which these attributes will be blacklisted
+- `YOUR_TOKEN` is the Access Token you got in the previous step
+- The `options.non_persistent_attrs` object holds an array of the attributes that will be blacklisted
+
+## Limitations
+
+- Only [root fields](/users/references/user-profile-structure#attributes) (such as `user.email` or `user.phone_number`) can be blacklisted
+  - If `user.name` or `user.nickname` are blacklisted they will not be included in tokens.
+  - If `user.email` is blacklisted the value cannot be mapped to a custom claim. For example, in a rule, `context.idToken[namespace + 'work_email'] = user.email` would not work.
+- When you blacklist attributes, they will be still be available via rules and outgoing tokens. However, if any of the following apply, the blacklist attributes will **not** be included in tokens:
+  - You have enabled multi-factor authentication (MFA)
+  - You have performed a redirect via rules
+  - Your app is using delegation (and you haven't set `scope = passthrough`)
+  - Your app is using impersonation
+  - You have enabled the **Use Auth0 instead of the IdP to do Single Sign-On** setting (legacy tenants only)
+- For SAMLP connections, if you enable Debug mode, your logs will contain information on the blacklisted attributes
+
+:::panel Working around the limitations
+If any of these limitations are unacceptable, you can write a [rule](/rules) to encrypt the data and have the data persist to the `user.app_metadata` object.
+:::
diff --git a/fr-ca/articles/security/bulletins/2019-01-10_rules.md b/fr-ca/articles/security/bulletins/2019-01-10_rules.md
new file mode 100644
index 0000000000..27fa3bdea6
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/2019-01-10_rules.md
@@ -0,0 +1,313 @@
+---
+title: Auth0 Security Bulletin for Vulnerable Patterns in Custom Rule Code
+description: Cases where improper custom rule code may create vulnerabilities in the authentication flow.
+topics:
+  - security
+  - security-bulletins
+  - rules
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Auth0 Security Bulletin for Rules
+
+**Published**: January 10, 2019
+
+## Overview
+
+This security bulletin covers several scenarios that customers should avoid in custom rule code, as they may create vulnerabilities in the authentication flow. A description of each issue and, where possible, an alternative way to write the same rule, is provided below.
+
+- Custom rule code containing conditional logic to enforce multi-factor authentication (MFA) may introduce the ability to bypass MFA altogether, especially when using silent authentication.
+- Custom rule code implementing authorization controls based on a specific substring without appropriate logic may result in elevated privileges.
+- Custom rule code sending diagnostic information to third party services, rather than using Auth0's built-in debugging features, may result in sensitive information disclosure.
+- Custom rule code triggering paid services may introduce the ability for an adversary to incur unwanted billing charges.
+- Custom rule code granting authorization based on unverified email addresses may allow adversaries to acquire those privileges through a secondary connection type.
+- Custom rule code containing hardcoded secrets, such as API keys, rather than using the global configuration object, increases the risk of exposing such secrets.
+
+## Table of Contents
+
+-   [Improper MFA rules](#improper-mfa-rules)
+    -   [Silent authentication](#silent-authentication)
+    -   [Silent authentication with redirection to custom MFA provider](#silent-authentication-with-redirection-to-custom-mfa-provider)
+    -   [Improper verification](#improper-verification)
+-   [Improper substring verification](#improper-substring-verification)
+-   [Debugging using external services](#debugging-using-external-services)
+-   [Rules using a paid service](#rules-using-a-paid-service)
+-   [Authorization based on unverified email address](#authorization-based-on-unverified-email-address)
+-   [Plaintext secrets within rule code](#plaintext-secrets-within-rule-code)
+
+## Improper MFA rules
+
+### Silent authentication
+Within a single-page application (SPA) using the implicit flow, silent authentication enables new access tokens to be issued without user interaction as long as the current session is valid against the authorization server.
+
+Auth0 offers silent authentication through a special parameter which is added to the authorization endpoint as follows:
+`/authorize?prompt=none`
+
+If MFA is added to the silent authentication process, however, then user interaction becomes necessary.
+
+Conditional logic based on silent authentication to bypass MFA should not be used as a workaround. Rules such as this allow complete MFA bypass and should not be utilized:
+
+```
+function (user, context, callback) {
+  if (context.request.query && context.request.query.prompt === 'none') {
+  // skip MFA for silent token requests
+  return callback(null, user, context);
+  }
+...
+}
+```
+
+### Silent authentication with redirection to custom MFA provider
+Rules that determine whether to redirect to custom multi-factor authentication based on silent authentication may allow MFA bypass in some unusual circumstances. For example, avoid the following:
+```
+function (user, context, callback) {
+  if (context.request.query && context.request.query.prompt === 'none') {
+  //redirect to custom MFA
+  context.redirect = {
+    url: "https://example.com/"
+  };
+...
+}
+```
+
+### Improper verification
+Utilizing rules to bypass multi-factor authentication given specific conditions may bypass MFA when the checks in place are inadequate for determining the veracity of a desired state.
+
+In these cases, the root of the issue is that rules can never determine whether MFA was successfully executed, as MFA happens after rule execution. Rules configured in this manner (see examples below) prematurely update the user record under the incorrect assumption that MFA will be successfully executed while relying on the same user record to skip MFA under given conditions.
+
+The examples below illustrate improper verification checks which can result in full multi-factor authentication bypass.
+
+#### Device fingerprint
+
+```
+function (user, context, callback) {
+
+  var crypto = require('crypto');
+
+  var deviceFingerPrint = getDeviceFingerPrint();
+  user.app_metadata = user.app_metadata || {};
+
+  // Inadequate verification check
+  if (user.app_metadata.lastLoginDeviceFingerPrint !== deviceFingerPrint) {
+    user.app_metadata.lastLoginDeviceFingerPrint = deviceFingerPrint;
+    context.multi-factor = {
+      ...
+    };
+    ...
+  }
+  function getDeviceFingerPrint() {
+    var shasum = crypto.createHash('sha1');
+    shasum.update(context.request.userAgent);
+    shasum.update(context.request.ip);
+    return shasum.digest('hex');
+  }
+}
+```
+
+#### Country code
+
+```
+function (user, context, callback) {
+  user.app_metadata = user.app_metadata || {};
+
+  // Inadequate verification check
+  if (user.app_metadata.last_location !== context.request.geoip.country_code) {
+    user.app_metadata.last_location = context.request.geoip.country_code;
+    context.multi-factor = {
+    ...
+    };
+  }
+```
+
+### Am I affected?
+If you utilize any of the previously illustrated rule logic, an adversary who has successfully logged in with the first authentication factor may be able to bypass MFA on your application.
+
+### Mitigation steps
+**If you are affected by the silent authentication scenario**, remove the conditional logic based on `prompt === 'none'`. This will trigger multi-factor authentication on each silent authentication call to check session status.
+
+**If you are affected by the silent authentication with redirection scenario**, remove the conditional logic based on `prompt === 'none'` and switch to an Auth0-supported multi-factor authentication provider.
+
+To avoid prompting the user for MFA too often, you can set the parameter `allowRememberBrowser` to true, which will enable end-users to check a box so they will only be prompted for multi-factor authentication every 30 days. For example:
+
+```
+  context.multi-factor = {
+    provider: 'guardian',
+    allowRememberBrowser: true
+  };
+```
+
+You may want to notify your end users about checking the box to avoid being prompted too frequently.
+
+**If you are affected by rules utilizing improper verification for skipping MFA**, ensure to use sound verification checks, discontinue MFA exceptions entirely, or use the `allowRememberBrowser` configuration option described above.
+
+### Will this update impact my users?
+Depending on how you adjust your rules or configuration, this update may impact your users by prompting them for MFA more than usual.
+
+## Improper substring verification
+If you have rule logic that requires access control based on an exact match of a particular string, such as an email domain, but you are only checking for a substring instead of an exact string match, your logic may not function as you intend. For example:
+
+```
+  if( _.findIndex(connection.options.domain_aliases,function(d){
+    return user.email.indexOf(d) >= 0;
+```
+
+The above logic would return true given emails such as these:
+- `user.domain.com@not-domain.com`
+- `"user@domain.com"@not-domain.com` (quotes included)
+
+### Am I affected?
+Only customers using conditional logic in rules as described above, are affected.
+
+### Mitigation steps
+Utilize logic such as:
+
+```
+  const emailSplit = user.email.split('@');
+  const userEmailDomain = emailSplit[emailSplit.length - 1].toLowerCase();
+```
+
+Please refer to the following rule template for more information:
+https://github.com/auth0/rules/blob/master/src/rules/check-domains-against-connection-aliases.js
+
+Alternatively, in the _Rules_ section of the Auth0 dashboard, view the rule template named "Check if user email domain matches configured domain".
+
+### Will this update impact my users?
+Possibly. The recommended change to rules with logic based on substring checks may impact end users, though you will be the best judge of the intent of your rules and whether any recommended changes are likely to impact your end users.
+
+## Debugging using external services
+If you have rule logic that sends the Auth0 context object to an external service, you are exposing items such as `id_token` or `access_token` associated with the request. For example:
+
+```
+  request.post({
+    url: 'http://requestbin.fullcontact.com/YourBinUrl',
+    json: {
+      user: user,
+      context: context,
+    },
+    timeout: 15000
+  }, function(err, response, body){
+    if (err) return callback(err);
+    return callback(null, user, context);
+  });
+```
+
+### Am I affected?
+Only customers with rule logic as described above are affected.
+
+### Mitigation steps
+You should modify your rule so it no longer sends the entire context object to _requestbin_, as this may expose any `id_token` or `access_token` associated with each request. Instead, you should send a subset of attributes from the context object that are less sensitive.
+The variables contained in the context object are detailed here: https://auth0.com/docs/rules/current/context
+
+Please refer to the following rule template for more information:
+https://github.com/auth0/rules/blob/master/src/rules/requestbin.js
+
+Alternatively, in the _Rules_ section of the Auth0 dashboard, view the rule template named "Dump rule variables to RequestBin".
+
+Auth0 also offers built-in methods for debugging rules without sending information to external services. Visit https://auth0.com/docs/rules/guides/debug for details.
+
+### Will this update impact my users?
+No. The impacted rule was typically used for debugging purposes. Modification should not impact end users.
+
+## Rules using a paid service
+If you have rule logic that involves a paid service, such as sending SMS messages via _Twilio_, as part of the authentication process, you may be vulnerable to increased costs because an adversary with a valid username and password may be able to trigger a call to the service and incur costs without having to complete the entire authentication process specified by rules. For example:
+
+```
+  //Sends user SMS via Twilio
+  function notifyUser(done) {
+    const request = require('request');
+    const twilioAccount = 'YOUR_TWILIO_ACCOUNT';
+    const twilioAuthToken = 'YOUR_TWILIO_AUTH_TOKEN';
+
+    request.post({
+      url: 'https://api.twilio.com/2010-04-01/Accounts/' + twilioAccount + '/Messages.json',
+      auth: {
+        'user': twilioAccount,
+        'pass': twilioAuthToken,
+      },
+      form: {
+        body: 'You\'ve logged in from a different device or location.',
+        to: user.phone,
+        from: '+18668888888'
+      }
+    }, function (error, response, body) {
+      if (error) return done(error);
+      if (response.statusCode !== 201) return done(new Error(response.statusCode));
+      return done(null);
+    });
+  }
+```
+
+### Am I affected?
+Only customers with rule logic as described above, and whose rule logic can be triggered by any untrusted user, are affected.
+
+### Mitigation steps
+To mitigate this risk, consider one or more of the following actions:
+
+- Disallow public sign-ups, if not needed, to reduce the numbers of users who can sign up and trigger calls to paid services.
+- Mitigate the risk of credential theft to avoid account takeover by hackers who might use hijacked accounts to trigger calls to paid services.
+- Ensure your users have strong passwords when using Database connections.
+- Ensure your users utilize multi-factor authentication.
+- Ensure that the rule only gets triggered for an authorized subset of users, or under other appropriate conditions. For example, you may wish to add logic that checks if a user has a particular email domain, role/group, or subscription level before triggering the call to the paid service.
+
+### Will this update impact my users?
+The impact to end users depends on which of the options described above you choose to mitigate the issue.
+
+## Authorization based on unverified email address
+If you have rule logic that requires access control based on a particular email or email domain, but you are failing to check whether that user has verified their email, an adversary could potentially gain additional privileges by using a second connection type. For example:
+
+```
+  var userHasAccess = allowList.some(function (email) {
+    return email === user.email;
+  });
+```
+
+The above logic would return **true** if an adversary could create an account using a different connection type (such as _social_) with an email address present in the allow-list. This happens because the same email can exist in different connection types.
+
+### Am I affected?
+Only customers using conditional logic in rules as described above, and allowing for multiple connection types, are affected.
+
+### Mitigation steps
+Whenever granting authorization based on email addresses, always start the rule with the following logic:
+
+```
+function (user, context, callback) {
+  // Access should only be granted to verified users.
+  if (!user.email || !user.email_verified) {
+    return callback(new UnauthorizedError('Access denied.'));
+  }
+```
+
+::: warning
+Sometimes even a verified email may not be an adequate check for the authorization you want to perform. To find out more about such cases, please read about the [Email Verified Usage](/users/guides/email-verified)
+:::
+
+### Will this update impact my users?
+This will only affect existing users if they have not verified their email addresses.
+
+## Plaintext secrets within rule code
+If you specify sensitive information, such as API keys, within rule code, you should configure those values in rule settings instead. For example:
+
+```
+  const myApiKey = 'abcdefghijklmnopqrstuvwxyz';
+```
+
+Such sensitive values, being present in the rule code, will remain unencrypted in our systems and suffer the risk of being exposed.
+
+### Am I affected?
+If your rules contain sensitive values within the rule code itself, you are affected.
+
+### Mitigation steps
+Place the sensitive values in the _Settings_ area of the main _Rules_ section of the Auth0 dashboard and then access them in your rule via the following:
+
+```
+  const myApiKey = configuration.myApiKey;
+```
+
+This will ensure that all sensitive values are encrypted within Auth0's systems, reducing the risk of exposure.
+
+### Will this update impact my users?
+This will not impact your users.
+
diff --git a/fr-ca/articles/security/bulletins/2019-09-05_scopes.md b/fr-ca/articles/security/bulletins/2019-09-05_scopes.md
new file mode 100644
index 0000000000..93bd59afda
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/2019-09-05_scopes.md
@@ -0,0 +1,35 @@
+---
+title: Auth0 Security Bulletin for Assigning Scopes Based on Email Address
+description: Cases where improper custom rule code may create vulnerabilities in the authentication flow.
+topics:
+  - security
+  - security-bulletins
+  - rules
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Auth0 Security Bulletin for Assigning Scopes Based on Email Address
+
+## Overview
+
+If you:
+
+* Use rules to assign scopes to users based on their email addresses **and**
+* Your application uses multiple connections
+
+There is a possibility that your scopes could be compromised.
+
+## How This Works
+
+Auth0 requires that email addresses are unique on a per-connection basis. However, there are no limitations on a per-application basis.
+
+Therefore, it is possible for user A to sign up for the application using one connection *and* user B to sign up for the application with the _same email address_ using a different connection.
+
+If your rules assign scopes to users based on email address, the second user has now been given the same scopes as the first user, despite being a different individual.
+
+## How do I fix this?
+
+The most straightforward mitigation is to require users to [verify their email address](/api/management/v2#!/Jobs/post_verification_email) after signing up and before being allowed to log in.
\ No newline at end of file
diff --git a/fr-ca/articles/security/bulletins/2020-03-31_wpauth0.md b/fr-ca/articles/security/bulletins/2020-03-31_wpauth0.md
new file mode 100644
index 0000000000..a5a6f4d6bc
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/2020-03-31_wpauth0.md
@@ -0,0 +1,47 @@
+---
+title: Security Update for WordPress Plugin for Auth0 
+description: Security Update for WordPress Plugin for Auth0 (CVE-2020-5391, CVE-2020-5392, CVE-2020-6753, CVE-2020-7948, CVE-2020-7947)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - wordpress
+  - wp-auth0
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Update for WordPress Plugin for Auth0
+
+**Published**: March 31, 2020
+
+**CVE numbers**: CVE-2020-5391, CVE-2020-5392, CVE-2020-6753, CVE-2020-7948, CVE-2020-7947
+
+**Credit**: Muhamad Visat
+
+## Overview
+
+Auth0 has released a new major version of the [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) to address several vulnerabilities.
+
+We recommend you review the following security advisories and upgrade to the new major version:
+
+- CSRF controls missing for domain field in Auth0 WP plugin: [CVE-2020-5391](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5391)
+- Stored XSS in Auth0 WP plugin (Settings page): [CVE-2020-5392](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5392)
+- Stored XSS in Auth0 WP plugin (multiple pages): [CVE-2020-6753](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6753)
+- CSV injection vulnerabilities in Auth0 WP plugin: [CVE-2020-7947](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7947)
+- Insecure direct object reference in Auth0 WP plugin: [CVE-2020-7948](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7948)
+
+## Am I affected?
+
+Customers using any version of the WordPress Plugin for Auth0 3.11.3 or earlier can be affected. 
+
+## How to fix that?
+
+Customers using [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) need to upgrade to version 4.0.0 or higher. 
+
+
+## Will this update impact my users?
+
+The [release notes](https://github.com/auth0/wp-auth0/blob/master/CHANGELOG.md) provide more in-depth information about the changes that were made, and the [migration instructions](https://github.com/auth0/wp-auth0/blob/master/MIGRATE-v3-TO-v4.md) provide more in-depth information about the upgrade path.
diff --git a/fr-ca/articles/security/bulletins/cve-2017-16897.md b/fr-ca/articles/security/bulletins/cve-2017-16897.md
new file mode 100644
index 0000000000..2dd3913dfc
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2017-16897.md
@@ -0,0 +1,68 @@
+---
+title: Auth0 Security Bulletin CVE 2017-16897
+description: Security Update for passport-wsfed-saml2 Passport strategy library (CVE 2017-16897)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - passport-wsfed-saml2
+  - passport
+  - wsfed
+  - saml
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for passport-wsfed-saml2 Passport Strategy Library
+
+**Published**: December 22, 2017
+
+**CVE number**: CVE 2017-16897
+
+**Credit**: Alan Bishop
+
+## Overview
+
+A vulnerability has been discovered in the [passport-wsfed-saml2 library](https://github.com/auth0/passport-wsfed-saml2) affecting versions < `3.0.5`.
+
+:::note
+**passport-wsfed-saml2** is a WS-Federation protocol and SAML2 tokens authentication provider for [Passport.js](http://passportjs.org/).
+:::
+
+This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider does not sign the full SAML response, but instead only signs the assertion within the response.
+
+An attacker who successfully exploits this vulnerability could use that response to craft a request with a different **NameIdentifier** in order to log in as a different user. A malicious actor could also perform a privilege escalation attack if authenticating as a specific user with administrative privileges. The attacker must have an existing account, or be able to intercept the encrypted traffic and modify the SAML response on the fly. 
+
+This update addresses the vulnerability by avoiding wrapping attacks for **Assertion** and **Response** elements, as well as providing some defensive changes in XPath expressions. An update has also been implemented to improve the method of logging information about the signing of the SAML response.
+
+Patching this vulnerability requires a library upgrade. 
+
+## Am I affected?
+
+This vulnerability affected cloud tenants utilizing the **SAMLP Identity Provider Connection** wherein the identity provider either:
+
+- signed SAML response and signed assertion
+- did not sign SAML response and signed assertion
+
+No action is required for Auth0 cloud tenants. 
+
+The vulnerability scope also extended to those using the [passport-wsfed-saml2 strategy with passport.js](https://github.com/auth0/passport-wsfed-saml2), which requires a library upgrade (see the next section).
+
+## How to fix that?
+
+Developers using the **passport-wsfed-saml2** library need to upgrade to the latest version: `3.0.5`.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "passport-wsfed-saml2": "^3.0.5"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/cve-2017-17068.md b/fr-ca/articles/security/bulletins/cve-2017-17068.md
new file mode 100644
index 0000000000..9721c1184b
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2017-17068.md
@@ -0,0 +1,56 @@
+---
+title: Auth0 Security Bulletin CVE 2017-17068
+description: Security Update for auth0.js Popup Callback Vulnerability (CVE 2017-17068)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+  - auth0js-popup
+  - callbacks
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for auth0.js Popup Callback Vulnerability
+
+**Published**: December 4, 2017
+
+**CVE number**: CVE 2017-17068
+
+**Credit**: [@AppCheckNG](https://twitter.com/AppCheckNG)
+
+## Overview
+
+A vulnerability has been identified in the [auth0.js JavaScript library](/libraries/auth0js), affecting versions < `8.12`.
+
+If your site or application uses a popup callback page with `auth0.popup.callback()` then an attacker can take advantage of unrestricted cross-origin post message requests and gain access to the tokens of logged-in users. A malicious website could then use any acquired Access Tokens to invoke services on behalf of the user.
+
+This update addresses the vulnerability by implementing origin verification so the message cannot be posted to a page that is not in a specified domain. If no domain is specified, only the domain where the callback page is hosted is allowed. An attacker would receive a cross-origin request error.
+
+Patching this vulnerability requires a library upgrade.
+
+## Am I affected?
+
+If the following apply you are affected by this vulnerability:
+- You use a version of auth0.js lower than `8.12`
+- You use a popup callback page with `auth0.popup.callback()` in your code
+
+## How to fix that?
+
+Developers using the auth0.js library need to upgrade to the latest version: `8.12`.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "auth0-js": "^8.12.0"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
\ No newline at end of file
diff --git a/fr-ca/articles/security/bulletins/cve-2018-11537.md b/fr-ca/articles/security/bulletins/cve-2018-11537.md
new file mode 100644
index 0000000000..8fb96b3033
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2018-11537.md
@@ -0,0 +1,56 @@
+---
+title: Auth0 Security Bulletin CVE 2018-11537
+description: Security Update for angular-jwt Whitelist Bypass (CVE 2018-11537)
+toc: true
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for angular-jwt Whitelist Bypass
+
+**Published**: June 5, 2018
+
+**CVE number**: CVE 2018-11537
+
+**Credit**: Stephan Hauser
+
+## Overview
+
+The [domain whitelisting](https://github.com/auth0/angular-jwt#whitelisting-domains) feature can be bypassed. For example, if the setting is initialized with 
+
+```js
+jwtInterceptorProvider.whiteListedDomains = ['whitelisted.Example.com'];
+```
+
+An attacker can set up a domain `whitelistedXexample.com` that will pass the whitelist filter. The root cause for this is that `angular-jwt` always treats `whiteListedDomains` entries as regular expressions and causes `.` separator to match any character.
+
+## Am I affected?
+
+If the following apply you are affected by this vulnerability:
+- You use a version of angular-jwt lower than `0.1.10`
+- You use domain whitelisting in your code
+
+## How to fix that?
+
+Developers using the angular-jwt library need to upgrade to the latest version: `0.1.10`.
+
+Updated package is available on [NPM](https://npmjs.com):
+
+```bash
+npm install angular-jwt@0.1.10
+```
+
+To make it easier to keep up with security updates in the future, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries:
+
+```json
+{
+  "dependencies": {
+    "angular-jwt": "^0.1.10"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/cve-2018-15121.md b/fr-ca/articles/security/bulletins/cve-2018-15121.md
new file mode 100644
index 0000000000..df5674586f
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2018-15121.md
@@ -0,0 +1,43 @@
+---
+title: Auth0 Security Bulletin CVE 2018-15121
+description: Security vulnerability in deprecated Auth0 middleware for ASP.NET
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - aspnet
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Vulnerability in auth0-aspnet and auth0-aspnet-owin
+
+**Published**: August 6, 2018
+
+**CVE number**: CVE 2018-15121
+
+**Credit**: Kévin Chalet
+
+## Overview
+
+All versions of the [auth0-aspnet](https://github.com/auth0/auth0-aspnet) and [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) packages have a security vulnerability that leave client applications vulnerable to a Cross-Site Request Forgery (CSRF) attack during authorization and authentication operations.
+
+The root cause of this vulnerability is lack of use and verification of the `state` parameter in OAuth 2.0 and OpenID Connect (OIDC) protocols that allows an attacker to inject their authorization code into victim's session.
+
+## Am I affected?
+
+If you use any version of `auth0-aspnet` or `auth0-aspnet-owin`, you are affected by this vulnerability.
+
+## How to fix that?
+
+Further development of the [auth0-aspnet](https://github.com/auth0/auth0-aspnet) and [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) packages has been discontinued. We strongly recommend moving to OWIN 4 and the official `Microsoft.Owin.Security.OpenIdConnect` package, which is not vulnerable.
+
+See the [migration guide](/quickstart/webapp/aspnet-owin/04-migrating) for more details.
+
+If your application is not currently making use of OWIN, please refer to Microsoft's [OWIN documentation](https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/) to enable it in your application.
+
+### Will this update impact my users?
+
+Current user states and sessions will be invalidated, as different libraries will handle authentication.
diff --git a/fr-ca/articles/security/bulletins/cve-2018-6873.md b/fr-ca/articles/security/bulletins/cve-2018-6873.md
new file mode 100644
index 0000000000..546d8d75b7
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2018-6873.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2018-6873
+description: Details about a security vulnerability identified in the Auth0 authentication service
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - tokens
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability in the Auth0 Authentication Service
+
+**Published**: April 4, 2018
+
+**CVE number**: CVE 2018-6873
+
+**Credit**: [Cinta Infinita](http://www.cintainfinita.com/)
+
+## Overview
+
+A vulnerability was identified in the Auth0 authentication service. It affected all Auth0 tenants, and was patched on October 15th, 2017 within four hours of report for all public cloud customers. This notice is informational and is intended to explain the vulnerability and the mitigation taken.
+
+As part of an user authentication flow employed by the Auth0 service, a JSON Web Token (JWT) is passed to the `/login/callback` endpoint identifying the user. This token contains a reference to which audience - an Auth0 tenant - it is intended for. A flaw in the Auth0 service did not properly validate this audience, and therefore allowed tokens intended for one tenant to be used at another. Further, the custom database functionality available to all Auth0 tenants allows for authenticated tokens to be generated with any desired identifier. Therefore, could an attacker learn the user identifier of an intended victim at a target tenant - which is generally considered public information - they could construct a token with that identifier. Due to the improper audience checking the target tenant would accept it, and establish a login session recognizing the attacker as the victim. This allowed for privilege escalation, among other possible attack vectors. 
+
+A specific concern was the potential use of this attack on the Auth0 management service. Auth0 tenants are managed by tenant administrators, who have accounts on an "authority tenant" with relevant permissions. If an attacker could learn the user identifier of a tenant administrator on the tenant authority (such as by social engineering), this allowed the attacker to login as the administrator by the described attack method. The attacker could then undertake administration actions and view all information at the tenant.
+
+The attack was never effective if the user had multifactor authentication enabled, which is recommended.
+
+## Am I affected?
+
+All Auth0 tenants were affected, but have been patched. Public cloud tenants were patched within four hours of the vulnerability report.
+
+The attack was never effective if the user had multifactor authentication enabled.
+
+## How to fix that?
+
+The vulnerability was fixed by Auth0, accomplished by adding proper validation of the audience parameter. No additional actions are required of our customers.
+
+### Will this update impact my users?
+
+The fix was invisible to all users.
diff --git a/fr-ca/articles/security/bulletins/cve-2018-6874.md b/fr-ca/articles/security/bulletins/cve-2018-6874.md
new file mode 100644
index 0000000000..c90b549af7
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2018-6874.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2018-6874
+description: Details about a security vulnerability identified in the Auth0 authentication service
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability in the Auth0 Authentication Service
+
+**Published**: April 4, 2018
+
+**CVE number**: CVE 2018-6874
+
+**Credit**: Internal
+
+## Overview
+
+A vulnerability has been identified in the Auth0 authentication service. Tenants of the service with the Legacy Lock API flag enabled in the service’s management dashboard are affected. If the flag is not visible, it is disabled. Disabling the flag may break applications employing the [auth0.js](/libraries/auth0js) library with version `< 9.0.0` or the [Lock](/libraries/lock) library with version `< 11.0.0` for crossdomain username/password based authentication - also known as [embedded login](/guides/login/universal-vs-embedded). Further, any cross-domain use of the `/usernamepassword/login` authentication api endpoint outside of those libraries may also be affected.
+
+After the verification of user credentials on `/usernamepassword/login`, an HTML form is rendered into the user’s browser and automatically executed. It POSTs a JSON Web Token (JWT) to the `/login/callback` endpoint. This authenticated token maintains state regarding the identity of the user; this cannot be done directly due to crossdomain session management restrictions maintained by most modern browsers. Due to the lack of session binding, this form post is susceptible to [CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)). An attacker with valid user credentials at an Auth0 tenant can use them to gain such a form, and then employ techniques such as social engineering or clickjacking to have a victim’s browser execute it. The victim will then have a login session at the Auth0 tenant under the attacker’s account - and therefore be recognized as the attacker by any downstream application in its federation. Should the user undertake any actions while maliciously logged in as such, those actions and any related information will be visible to the attacker.
+
+The attack does not allow any escalation of privileges on behalf of the attacker, and the victim’s actions visible to the attacker are restricted to whatever permissions have been granted to that attacker within the system. The victim will also be fully recognized as the attacker within the federation, and so may be shown account information or other context clues that reveal they are not operating within the auspices of their own account.
+
+## Am I affected?
+
+You are affected if you employ username/password authentication (with any database and/or connection) for your Auth0 tenant, and the Legacy Lock API flag in the Auth0 management dashboard is visible and flagged on.
+
+## How to fix that?
+
+To mitigate the vulnerability, toggle the flag to off. The `/usernamepassword/login` endpoint will still work for logins from the Universal Login page hosted on `/login`, however these - as same-domain logins - will be protected from CSRF. Otherwise, toggling the flag will disable cross-domain authentication on that endpoint.
+
+For applications employing [auth0.js](/libraries/auth0js) version `< 9.0.0` or [Lock](/libraries/lock) version `< 11.0.0`, this may break user logins. Upgrading to [auth0.js](/libraries/auth0js) version `> 9.0.0` or [Lock](/libraries/lock) version `> 11.0.0` will restore embedded username/password authentication using [cross-origin authentication](/cross-origin-authentication) (note the [limitations](/cross-origin-authentication#limitations)). Applications are also encouraged to [migrate to Universal Login](/guides/login/migration-embedded-universal).
+
+Private SaaS Appliances running versions `> 14591` with the Legacy Lock API flag set to off are not affected by this vulnerability.
+
+### Will this update impact my users?
+
+If the Legacy Lock API is disabled without applications having migrated, then all user logins employing the affected functionality will break. Auth0 intends to enforce disablement of the Legacy Lock API for all tenants on July 16th, 2018. The choice of migration may affect the specific user experience of logging into your service, however users, their information, and their sessions will not be otherwise impacted.
diff --git a/fr-ca/articles/security/bulletins/cve-2018-7307.md b/fr-ca/articles/security/bulletins/cve-2018-7307.md
new file mode 100644
index 0000000000..7887c5fd03
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2018-7307.md
@@ -0,0 +1,50 @@
+---
+title: Auth0 Security Bulletin CVE 2018-7307
+description: Details about a security vulnerability identified for auth0.js < 9.3
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability for auth0.js < 9.3
+
+**Published**: February 26, 2018
+
+**CVE number**: CVE 2018-7307
+
+**Credit**: Internal
+
+## Overview
+
+A vulnerability has been identified in the [auth0.js JavaScript library](/libraries/auth0js), affecting versions < `9.3`.
+
+This vulnerability allows an attacker to bypass the CSRF check from the [state parameter](/protocols/oauth2/oauth-state) if it's missing from the authorization response, leaving the client vulnerable to CSRF attacks.
+
+Patching this vulnerability requires a library upgrade.
+
+## Am I affected?
+
+If you use a version of auth0.js lower than `9.3` then you are affected by this vulnerability.
+
+## How to fix that?
+
+Developers using the auth0.js library need to upgrade to the version `9.3` or higher.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "auth0-js": "^9.3.0"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/cve-2019-13483.md b/fr-ca/articles/security/bulletins/cve-2019-13483.md
new file mode 100644
index 0000000000..c8cedc4767
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2019-13483.md
@@ -0,0 +1,39 @@
+---
+title: Auth0 Security Bulletin CVE-2019-13483
+description: Details about a security vulnerability in Passport-SharePoint 
+topics:
+ - security
+ - security-bulletins
+ - authentication
+ - passport
+contentType:
+ - reference
+useCase:
+ - development
+---
+
+# Security Vulnerability in Passport-SharePoint
+
+**Published**: 7/23/2019
+
+**CVE number**: CVE-2019-13483
+
+## Overview
+
+Versions of [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) prior to **0.4.0** do not validate the JWT signature of an Access Token before processing.
+
+This vulnerability allows attackers to forge tokens and bypass authentication and authorization mechanisms.
+
+## Am I affected?
+
+You are affected by this vulnerability if you use a [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) version earlier than 0.4.0.
+
+## How do I fix this?
+
+Developers using the [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) library must upgrade to version `0.4.0`.
+
+Please note that Auth0 has deprecated and will no longer maintain this library. Developers should plan to discontinue its use.
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but it will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/cve-2019-16929.md b/fr-ca/articles/security/bulletins/cve-2019-16929.md
new file mode 100644
index 0000000000..5922b85b6c
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2019-16929.md
@@ -0,0 +1,42 @@
+---
+title: Auth0 Security Bulletin CVE-2019-16929
+description: Security vulnerability in auth0.net 
+topics:
+ - security
+ - security-bulletins
+ - authentication
+contentType:
+ - reference
+useCase:
+ - development
+---
+
+# Security Vulnerability in auth0.net
+
+**Published**: 10/03/2019
+
+**CVE number**: CVE-2019-16929
+
+**Credit**: Dennis Detering (Spike Reply GmbH)
+
+## Overview
+
+Versions of [auth0.net](https://github.com/auth0/auth0.net) and associated NuGet Package [Auth0.AuthenticationAPI](https://www.nuget.org/packages/Auth0.AuthenticationApi/) from `5.8.0` to `6.5.3` inclusive include a class named `IdentityTokenValidator` with a public `ValidateAsync` method, that performs limited validation suitable only for auth0 issued tokens.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using the `IdentityTokenValidator` to validate untrusted ID tokens
+- You are using a version of Auth0.AuthenticationAPI between `5.8.0` and `6.5.3` inclusive
+
+## How to fix that?
+
+Developers should not use the `IdentityTokenValidator` class to validate untrusted ID tokens. See https://auth0.com/docs/tokens/guides/validate-id-tokens for our recommendations for validating ID tokens. https://jwt.io/ is a good resource on open source JWT validation libraries and their capabilities. Note that additional logic may be required based upon your use case.
+
+Developers using the [auth0.net](https://github.com/auth0/auth0.net) and associated NuGet Package [Auth0.AuthenticationAPI](https://www.nuget.org/packages/Auth0.AuthenticationApi/) between `5.8.0` and `6.5.3` inclusive should upgrade to the latest version `6.5.4` to prevent accidental usage of the `IdentityTokenValidator` class.
+
+### Will this update impact my users?
+
+No. This fix patches the client library that your application runs, but will not impact your users, their current state, or any existing sessions.
+
diff --git a/fr-ca/articles/security/bulletins/cve-2019-20173.md b/fr-ca/articles/security/bulletins/cve-2019-20173.md
new file mode 100644
index 0000000000..884f10df9d
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2019-20173.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2019-20173
+description: Security Update for WordPress Plugin for Auth0 (CVE 2019-20173)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - wordpress
+  - wp-auth0
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Update for WordPress Plugin for Auth0 [wp-auth0](https://github.com/auth0/wp-auth0)
+
+**Published**: January 31, 2020
+
+**CVE number**: CVE-2019-20173
+
+**Credit**: Muhamad Visat
+
+
+## Overview
+
+The WordPress Plugin for Auth0 versions 3.11.0, 3.11.1, and 3.11.2 do not properly sanitize the `wle` query parameter. This could allow an attacker to run a cross-site scripting (XSS) attack on the login page.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following apply:
+
+* You are using the WordPress Plugin for Auth0 versions 3.11.0, 3.11.1, or 3.11.2
+* The “Original Login Form on wp-login.php” setting under Basic settings is set to either of the two options:
+  * “Via a link under the Auth0 form” (default option)
+  * “When "wle" query parameter is present”
+
+## How to fix that?
+
+Developers using WordPress Plugin for Auth0 need to upgrade to version 3.11.3 or later.
+
+## Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/cve-2019-20174.md b/fr-ca/articles/security/bulletins/cve-2019-20174.md
new file mode 100644
index 0000000000..0c6c6a2cf0
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2019-20174.md
@@ -0,0 +1,71 @@
+---
+title: Auth0 Security Bulletin CVE 2019-20174
+description: Security Update for Auth0 Lock library (CVE 2019-20174)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for Auth0 Lock Library
+
+**Published**: January 30, 2020
+
+**CVE number**: CVE 2019-20174
+
+**Credit**: Muhamad Visat
+
+## Overview
+
+Auth0 Lock version 11.20.4 and earlier did not properly sanitize the generated HTML code. Customers using the `additionalSignUpFields` customization option to add a checkbox to the sign-up dialog who are passing a `placeholder` property obtained from an untrusted source (e.g., a query parameter) could allow cross-site scripting (XSS) on their sign-up pages.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using Auth0 Lock version 11.20.4 or earlier.
+- You pass `additionalSignUpFields` as an option when initializing Lock, and it includes a field of type `checkbox` with a `placeholder` value obtained from an untrusted source.
+
+An example of a vulnerable snippet is the following where the `placeholder` value is partially user-controlled by the `name` query parameter:
+
+```javascript
+
+```
+
+## How to fix that?
+
+Developers using Auth0’s Lock sign-in solution need to upgrade to version 11.21.0 or later. Version 11.21.0 introduces two changes:
+
+1. The existing `placeholder` property is now treated as plain text to mitigate the problem.
+2. A new `placeholderHTML` property is introduced that indicates the level of control it provides and that its value should be supplied only from trusted sources.
+
+## Will this update impact my users?
+
+This fix patches the Auth0 Lock widget and may require changes in application code, but it will not impact your users, their current state, or any existing sessions.
+
+Developers using the `placeholder` property with HTML content from a trusted source should start using the `placeholderHTML` property to continue providing the same user experience.
diff --git a/fr-ca/articles/security/bulletins/cve-2019-7644.md b/fr-ca/articles/security/bulletins/cve-2019-7644.md
new file mode 100644
index 0000000000..19a9e1eb95
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2019-7644.md
@@ -0,0 +1,54 @@
+---
+title: Auth0 Security Bulletin CVE-2019-7644
+description: Security vulnerability in Auth0-WCF-Service-JWT for ASP.NET
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - aspnet
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Vulnerability in Auth0-WCF-Service-JWT
+
+**Published**: February 15, 2019
+
+**CVE number**: CVE-2019-7644
+
+**Credit**: Conny Dahlgren, Security Researcher at DevilSec AB
+
+## Overview
+
+All versions of [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) NuGet package lower than 1.0.4 include sensitive information about the expected JWT signature in an error message emitted when JWT signature validation fails:
+
+```
+Invalid signature. Expected 8Qh5lJ5gSaQylkSdaCIDBoOqKzhoJ0Nutkkap8RgB1Y= got 8Qh5lJ5gSaQylkSdaCIDBoOqKzhoJ0Nutkkap8RgBOo=
+```
+
+This vulnerability allows attackers to use this error message to obtain a valid signature for arbitrary JWT tokens. This way attackers can forge tokens to bypass authentication and authorization mechanisms.
+
+## Am I affected?
+
+You are affected by this vulnerability if the following conditions apply:
+
+- You use a version of [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) NuGet package lower than 1.0.4
+- You show signature verification exception message in the user interface or make it otherwise available to the attacker (for example through logs or diagnostic messages)
+
+
+## How to fix that?
+
+Developers using the [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) library need to upgrade to the latest version 1.0.4.
+
+The updated package is available on [NuGet](https://www.nuget.org):
+
+```
+Install-Package Auth0-WCF-Service-JWT -Version 1.0.4
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
+
diff --git a/fr-ca/articles/security/bulletins/cve-2020-15084.md b/fr-ca/articles/security/bulletins/cve-2020-15084.md
new file mode 100644
index 0000000000..895eff253d
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2020-15084.md
@@ -0,0 +1,54 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15084
+description: Security Update for express-jwt library (CVE 2020-15084)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for express-jwt Library
+
+**Published**: June 30, 2020
+
+**CVE number**: CVE 2020-15084
+
+**Credit**: IST Group
+
+## Overview
+Versions before and including 5.3.3, we are not enforcing the **algorithms** entry to be specified in the configuration.
+When **algorithms** is not specified in the configuration, with the combination of jwks-rsa or potentially other asymmetric crypto libraries, it may lead to authorization bypass. 
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+You are using express-jwt
+AND 
+You do not have **algorithms**  configured in your express-jwt configuration.
+AND
+You are using libraries such as jwks-rsa as the **secret**. 
+
+## How to fix that?
+Specify **algorithms** in the express-jwt configuration. The following is an example of a proper configuration
+
+``` 
+const checkJwt = jwt({
+  secret: jwksRsa.expressJwtSecret({
+    rateLimit: true,
+    jwksRequestsPerMinute: 5,
+    jwksUri: `https://{DOMAIN}/.well-known/jwks.json`
+  }),
+  // Validate the audience and the issuer.
+  audience: process.env.AUDIENCE,
+  issuer: `https://{DOMAIN}/`,
+  // restrict allowed algorithms
+  algorithms: ['RS256']
+}); 
+```
+
+## Will this update impact my users?
+The fix provided in the patch will not affect your users if you specified the algorithms allowed. The patch now makes **algorithms** a required configuration. 
diff --git a/fr-ca/articles/security/bulletins/cve-2020-15119.md b/fr-ca/articles/security/bulletins/cve-2020-15119.md
new file mode 100644
index 0000000000..d86ffb1b10
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2020-15119.md
@@ -0,0 +1,42 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15119
+description: Security Update for Auth0 Lock Library (CVE 2020-15119)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for Auth0 Lock Library
+
+**Published**: August 16, 2020
+
+**CVE number**: CVE-2020-15119
+
+**Credit**: Muhamad Visat https://github.com/mvisat
+
+## Overview
+Versions before and including `11.25.1` are using `dangerouslySetInnerHTML` to display an informational message when used with a Passwordless or Enterprise connection.
+
+- For Passwordless connection, the value of the input (email or phone number) is displayed back to the user while waiting for verification code input.
+- For Enterprise connection, the value of the input (IdP Domain) from the Enterprise connection setup screen (Auth0 Dashboard) is displayed back to the user when the lock widget opens.
+
+When Passwordless or Enterprise connection is used, the application and its users might be exposed to cross-site scripting (XSS) attacks.
+
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using auth0-lock
+- You are using Passwordless or Enterprise connection mode
+
+
+## How to fix that?
+Upgrade to version `11.26.3`
+
+## Will this update impact my users?
+The fix provided in patch will not affect your users.
diff --git a/fr-ca/articles/security/bulletins/cve-2020-15125.md b/fr-ca/articles/security/bulletins/cve-2020-15125.md
new file mode 100644
index 0000000000..075fe0240e
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2020-15125.md
@@ -0,0 +1,37 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15125
+description: Security Update for node-auth0 library (CVE 2020-15125)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for node-auth0 Library
+
+**Published**: July 28, 2020
+
+**CVE number**: CVE-2020-15125
+
+**Credit**: Omar Diab http://github.com/osdiab
+
+## Overview
+Versions before and including `2.27.0` use a block list of specific keys that should be sanitized from the request object contained in the error object. When a request to Auth0 management API fails, the key for `Authorization` header is not sanitized and the `Authorization` header value can be logged exposing a bearer token.
+
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using auth0 npm package
+- You are using a Machine to Machine application authorized to use Auth0's management API https://auth0.com/docs/flows/concepts/client-credentials
+
+
+## How to fix that?
+Upgrade to version `2.27.1`
+
+## Will this update impact my users?
+The fix provided in patch will not affect your users.
diff --git a/fr-ca/articles/security/bulletins/cve-2020-5263.md b/fr-ca/articles/security/bulletins/cve-2020-5263.md
new file mode 100644
index 0000000000..a7a282b891
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/cve-2020-5263.md
@@ -0,0 +1,38 @@
+---
+title: Auth0 Security Bulletin CVE 2020-5263
+description: Security Update for auth0.js library (CVE 2020-5263)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for auth0.js Library
+
+**Published**: April 09, 2020
+
+**CVE number**: CVE-2020-5263
+
+**Credit**: Bogdan Vitoc (Spatial Systems Inc)
+
+## Overview
+Between versions 8.0.0 and  9.13.1 (inclusive), in the case of an (authentication) error, the error object returned by the library contains the original request of the user, which may include the plaintext password the user entered. 
+
+If the error object is exposed or logged without modification, the application risks password exposure.
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using Auth0.js version between 8.0.0 and 9.13.1 (inclusive).
+- You store or display error objects without filtering. 
+
+## How to fix that?
+Developers should upgrade auth0.js to version 9.13.2 or later where user inputted passwords are masked in errors. If upgrading is not possible, a temporary fix may include not storing the error object or displaying it publicly without modification.
+
+## Will this update impact my users?
+
+This fix patches the Auth0.js and may require changes in application code due to password no longer available in error object, but it will not impact your users, their current state, or any existing sessions.
diff --git a/fr-ca/articles/security/bulletins/index.md b/fr-ca/articles/security/bulletins/index.md
new file mode 100644
index 0000000000..63ad7bf6e1
--- /dev/null
+++ b/fr-ca/articles/security/bulletins/index.md
@@ -0,0 +1,48 @@
+---
+classes: topic-page
+title: Auth0 Security Bulletins
+description: List of bulletins addressing security vulnerabilities in Auth0 software, with info on how to fix them.
+topics:
+  - security
+  - security-bulletins
+contentType:
+  - index
+  - reference
+useCase:
+  - development
+---
+
    
+  
    
+  
    Auth0 Security Bulletins
    
+  
    
+    List of bulletins addressing security vulnerabilities in Auth0 software.
+  
    
+
    
+
+This page contains a list of all the published security vulnerabilities of Auth0 software.
+
+Each bulletin contains a description of the vulnerability, how to identify if you are affected, and what to do to fix it.
+
+## Bulletins
+
+| **Date** | **Bulletin number** | **Title** | **Affected software** |
+|-|-|-|-|
+| August 16, 2020 | [CVE-2020-15119](/security/bulletins/cve-2020-15119) | Security Update for Auth0 Lock <= 11.25.1 | [Auth0 Lock](https://github.com/auth0/lock) |
+| July 28, 2020 | [CVE-2020-15125](/security/bulletins/cve-2020-15125) | Auth0 Security Bulletin for node-auth0 <= 2.27.0 | [node-auth0](https://github.com/auth0/node-auth0) |
+| June 30, 2020 | [CVE 2020-15084](/security/bulletins/cve-2020-15084) | Auth0 Security Bulletin for express-jwt versions < 6.0.0 | [express-jwt](https://github.com/auth0/express-jwt) |
+| April 09, 2020 | [CVE 2020-5263](/security/bulletins/cve-2020-5263) | Auth0 Security Bulletin for auth0.js versions <= 9.13.1 | [Auth0.js](/libraries/auth0js) |
+| March 31, 2020 | [Auth0 Bulletin](/security/bulletins/2020-03-31_wpauth0) | Auth0 Security Bulletin for WordPress Plugin for Auth0 versions < 4.0.0 | [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) |
+| January 31, 2020 | [CVE 2019-20173](/security/bulletins/cve-2019-20173) | Auth0 Security Bulletin for WordPress Plugin for Auth0 versions 3.11.0, 3.11.1 and 3.11.2 | [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) |
+| January 30, 2020 | [CVE 2019-20174](/security/bulletins/cve-2019-20174) | Auth0 Security Bulletin for Auth0 Lock < 11.21.0 | [Auth0 Lock](https://github.com/auth0/lock) |
+| October 04, 2019 | [CVE 2019-16929](/security/bulletins/cve-2019-16929) | Auth0 Security Bulletin for auth0.net between versions 5.8.0 and 6.5.3 inclusive | [auth0.net](https://www.nuget.org/packages/Auth0.AuthenticationApi/) |
+| September 05, 2019 | [Auth0 bulletin](/security/bulletins/2019-09-05_scopes) | Auth0 Security Bulletin for assigning scopes based on email address | Custom code within Auth0 rules |
+| July 23, 2019 | [CVE 2019-13483](/security/bulletins/cve-2019-13483) | Security Bulletin for Passport-SharePoint < 0.4.0 | [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) |
+| February 15, 2019 | [CVE 2019-7644](/security/bulletins/cve-2019-7644) | Security Bulletin for Auth0-WCF-Service-JWT < 1.0.4 | [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) |
+| January 10, 2019 | [Auth0 bulletin](/security/bulletins/2019-01-10_rules) | Auth0 Security Bulletin for Vulnerable Patterns in Custom Rule Code | Custom code within Auth0 Rules |
+| August 6, 2018 | [CVE 2018-15121](/security/bulletins/cve-2018-15121) | Security vulnerability in deprecated Auth0 middleware for ASP.NET | [auth0-aspnet](https://github.com/auth0/auth0-aspnet), [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) |
+| June 5, 2018 | [CVE 2018-11537](/security/bulletins/cve-2018-11537) | Security update for angular-jwt whitelist bypass | [angular-jwt](https://github.com/auth0/angular-jwt) |
+| April 4, 2018 | [CVE 2018-6874](/security/bulletins/cve-2018-6874) | Security vulnerability for Auth0 authentication service | Auth0 Authentication Service |
+| April 4, 2018 | [CVE 2018-6873](/security/bulletins/cve-2018-6873) | Security vulnerability for Auth0 authentication service | Auth0 Authentication Service |
+| February 26, 2018 | [CVE 2018-7307](/security/bulletins/cve-2018-7307) | Security vulnerability for auth0.js < 9.3 | [Auth0.js](/libraries/auth0js) |
+| December 22, 2017 | [CVE 2017-16897](/security/bulletins/cve-2017-16897) | Security update for **passport-wsfed-saml2** Passport strategy library | **passport-wsfed-saml2** Passport strategy library |
+| December 4, 2017 | [CVE 2017-17068](/security/bulletins/cve-2017-17068) | Security update for auth0.js popup callback vulnerability | [Auth0.js](/libraries/auth0js) |
diff --git a/fr-ca/articles/security/common-threats.md b/fr-ca/articles/security/common-threats.md
new file mode 100644
index 0000000000..2da556c201
--- /dev/null
+++ b/fr-ca/articles/security/common-threats.md
@@ -0,0 +1,63 @@
+---
+description: Describes different types of cyber attacks and what steps can be taken to prevent them.
+topics:
+  - security
+  - security-bulletins
+  - prevention
+  - common-threats
+  - MitM
+  - CSRF
+  - XSRF
+  - replay
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Common Threats and How to Prevent Them
+
+## Man-in-the-Middle (MitM) attacks
+
+One type of threat is a Man-in-the-middle attack, sometimes called a bucket brigade attack. With this attack the attacker gets between two parties, where each party thinks they are interacting over a private connection, but it is actually being controlled by the third-party attacker. For this type of attack to succeed the attacker must create mutual authentication between both parties.
+
+Usually MitM attacks involve the attacker using a WiFi router to intercept a user's communication. The user connects to the attacker's router then visits a website and logs in with their confidential credentials. The attacker saves that user's login credentials for which they can then use to impersonate the user.
+
+Some MitM attacks can also modify the data transmitted between the application and the server. Attacks can occur from new PC trial and preinstalled software, software update tools, and other software vulnerabilities. In a worst case scenario this could result in remote code execution, backdooring the system, installing malware, and so on. This could also lead to the compromise of other network assets.
+
+### Preventing MitM attacks
+
+To help defend against this type of attack it is important to use strong encryption and authentication between the application and the server. Using encryption the server authenticates the application's request by presenting a digital certificate, and only then can the connection be established.  For example, HTTPS uses the secure sockets layer (SSL) capability of the browser to mask web traffic. To decrypt HTTPS, a man-in-the-middle attacker would have to obtain the keys used to encrypt the network traffic.
+
+With the configuration of TLS on your servers we suggest using the [Mozilla OpSec recommendations](https://wiki.mozilla.org/Security/Server_Side_TLS) which use TLSv1.2. Mozilla also provides an [SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/), to use this first choose which platform your server is running and then choose the most modern configuration based on what your application base can support. The more modern configurations provide stronger ciphers to help prevent attacks.
+
+## Replay attacks
+
+Replay attacks allow attackers to:
+
+* Gain access to a network and information which would not have been easily accessible 
+* Complete a duplicate transaction
+
+These are attacks on the security protocol using replays of data transmission from a different sender into the intended receiving system. The attacks fool the participants into believing they have successfully completed the data transmission. 
+
+A replay attack is also known as a playback attack.
+
+### Preventing Replay attacks
+
+Replay attacks can be avoided by using session tokens. However, if these credentials are stolen from local storage (like during an XSS attack), there are ways to prevent someone from holding on to a valid token forever:
+
+* Set a short expiration time for tokens
+* Provide a way to blacklist tokens that have been used (and possibly even the users)
+* Use one-time passwords
+
+The [JWT](/tokens/concepts/jwts) spec provides the `jti` field as a way to prevent replay attacks. Though Auth0 tokens currently don't return the `jti`, you can blacklist using the `jti` to prevent a token being used more than a specified number of times. In this way, you are implementing something similar to a nonce (think of the token's signature as the nonce). If a token gets stolen or it gets used more than the specified number of times, it should be blacklisted. This prevents a valid token from being used maliciously. Once the token expires, the attacker will no longer be able to impersonate the user.
+
+You can also avoid replay attacks by using one-time passwords. With Auth0, you can use [Passwordless Authentication](/passwordless), which relies on single-use codes and email links instead of traditional passwords. Auth0 also provides multi-factor authentication (MFA) which uses one-time passwords as a second-factor authentication which can be sent via push notifications and texts.
+
+## Cross-site Request Forgery
+
+A Cross-site Request Forgery (CSRF or XSRF) attack occurs when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate a type of action instead of getting user data because the attacker has no way to see the response of the forged request.
+
+### Preventing CSRF attacks
+
+One way to verify the requests that are being sent is to utilize the OAuth 2.0 protocol `state` parameter to authenticate the response. For more information, see [State Parameter](/protocols/oauth-state).
diff --git a/fr-ca/articles/security/index.md b/fr-ca/articles/security/index.md
new file mode 100644
index 0000000000..829e78deb8
--- /dev/null
+++ b/fr-ca/articles/security/index.md
@@ -0,0 +1,47 @@
+---
+url: /security
+classes: topic-page
+title: Auth0 Security
+description: Read about various security-related topics and keep up-to-date with released Auth0 security bulletins
+topics:
+  - security
+  - security-bulletins
+contentType:
+  - reference
+  - index
+useCase:
+  - development
+---
+
+
    
+  
    
+  
    Auth0 Security
    
+  
    
+    Read about various security-related topics and keep up-to-date with released Auth0 security bulletins
+  
    
+
    
+
+## Security bulletins
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/bulletins'
+] }) %>
+
+## Handling tokens
+
+<%= include('../_includes/_topic-links', { links: [
+  'tokens',
+  'tokens/concepts/token-storage'
+] }) %>
+
+## Preventing security attacks
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/common-threats'
+] }) %>
+
+## Data privacy
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/blacklisting-attributes'
+] }) %>
diff --git a/fr-ca/articles/services/_includes/_further-help.md b/fr-ca/articles/services/_includes/_further-help.md
new file mode 100644
index 0000000000..5aba279e75
--- /dev/null
+++ b/fr-ca/articles/services/_includes/_further-help.md
@@ -0,0 +1,3 @@
+::: note
+We provide continuous education and knowledge transfer throughout any engagement. If any part of your project requires more specialized attention and/or implementation assistance, or you would like some specialized training, then your Auth0 Solution Architect will be happy to help you understand how additional Professional Services can help you further to reach your goal.
+:::
diff --git a/fr-ca/articles/services/architectural-design.md b/fr-ca/articles/services/architectural-design.md
new file mode 100644
index 0000000000..8f842b97e7
--- /dev/null
+++ b/fr-ca/articles/services/architectural-design.md
@@ -0,0 +1,32 @@
+---
+description: Project to establish a foundational set up of Auth0 platform architecture.
+topics:
+  - professional services
+  - architecture
+  - solutions-architecture
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Architectural Design Sessions
+
+This is a fixed scope project designed to establish a foundational set up of Auth0 platform architecture: setup connectivity and configuration of your environment to meet your organization’s needs, and enable a technical solution for pre-defined business scenarios involving Auth0.
+
+## Estimated effort
+
+This is typically a 4-6 week part-time engagement effort with an Auth0 Solutions Architect and your development team.
+
+## Typical work-streams
+
+* **Working sessions:** architecture, design and implementation of a base identity services, and infrastructure in the customer's Auth0 subscription model. Provide knowledge transfer to customer staff to prepare them to operate the Solution and to expand Auth0 usage into other scenarios.
+* **Building a Prototype:** leading the development of a scoped down prototype that illustrates customer business scenarios being addressed, and the technical solution, including trade-offs.
+* **Pair-programming your scenario:** our engineers will join the customer's development team during the initial phases of development, under a pair-programming model, taking responsibilities for Auth0-related code.
+
+## Deliverables
+
+* Solution Design memo
+* First Integration Working Prototype
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/code-review.md b/fr-ca/articles/services/code-review.md
new file mode 100644
index 0000000000..03287053c2
--- /dev/null
+++ b/fr-ca/articles/services/code-review.md
@@ -0,0 +1,28 @@
+---
+description: Project to help customers analyze common design patterns.
+topics:
+  - professional services
+  - code-review
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Code Review
+
+An offering to analyze common design patterns and review customer's code flows and integrations. Goal is to detect potential pitfalls and problems, and provide guidance to address these.
+
+## Estimated effort
+
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and the customer's development team.
+
+## Typical work-streams
+
+* **Design Patterns review:** common authorization and authentication scenarios. Identification of anti-patterns. Guidance.
+
+## Deliverables
+
+* Technical document: code review findings, sample code and recommended configuration.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/custom-implementation.md b/fr-ca/articles/services/custom-implementation.md
new file mode 100644
index 0000000000..3046dec8f1
--- /dev/null
+++ b/fr-ca/articles/services/custom-implementation.md
@@ -0,0 +1,35 @@
+---
+title: Custom Implementation
+description: Learn how Professional Services can help you implement your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - custom
+    - implementation
+contentType: concept
+useCase:
+  - custom-implementation
+---
+# Custom Implementation
+
+In addition to enablement activities, Professional Services provides **custom implementation services** to help you accelerate your integration with Auth0. Auth0 is a unique service that offers developers unrivaled flexibility and extensibility, and our expert Professional Services team knows how to extend Auth0 in ways that are the most optimal for the platform and for your environment.
+
+Professional Services can provide a wide range of custom implementation to help you achieve the product functionality, service connectivity, operational readiness, and/or quality assurance you require to get to production. This includes: 
+
+* **Custom rules, hooks, DB scripts, login pages, and email templates:** Solve a user experience, 3rd-party service integration, or other logical problem within a customer’s Auth0 authentication and authorization workflow. These customizations happen in-product and do not require additional infrastructure to deploy.
+
+* **Custom endpoints and libraries:** Solve a service communication, user experience, or tenant management problem through the use of a custom web services endpoint or code library. Typically deployed on customer or third-party infrastructure.
+
+* **Custom utilities:** Solve a quality assurance or operations problem that is out-of-band from extending core product functionality, such as performance testing or deployment scripts.
+
+* **Custom code samples:** Demonstrate how a developer integrates with Auth0 using a specific language or technology stack. Used primarily for education.
+
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Solution Design](/services/solution-design)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+* [Gallery](/services/gallery)
+
diff --git a/fr-ca/articles/services/discover-and-design.md b/fr-ca/articles/services/discover-and-design.md
new file mode 100644
index 0000000000..8d1b6fcba7
--- /dev/null
+++ b/fr-ca/articles/services/discover-and-design.md
@@ -0,0 +1,31 @@
+---
+title: Discover & Design
+description: Learn how Professional Services can help you design and architect your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - design
+contentType: concept
+useCase:
+  - design
+  - solution-design
+---
+# Discover & Design
+
+The first stage in a successful implementation involves discovering, designing, and architecting your Identity and Access Management solution, and our Discover & Design services are here to help. We work together with your product and engineering teams to **architect an Identity solution** for your environment and build an **incremental Go-Live plan** that solves the most-pressing identity problems early. Auth0 Professional Services help your projects quickly reach success by addressing your business objectives in a pragmatic, step-by-step manner. 
+
+<%= include('./_includes/_further-help.md') %>
+
+## Architectural Discovery
+
+Focused on discovering the optimum design based on your requirements, Architectural Discovery services provide best practice guidance on topics such as requirements determination, Auth0 Tenant deployment strategies, your use cases, and integration with the software development process in your organization. Engaging with Auth0 Professional Services will help to provide you with a clear understanding of what you need to tackle, and when, in order to fulfill your particular needs. Delivered as part of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).
+
+## Scenario Guidance
+
+Guiding you through your use case scenarios, our Scenario Guidance services help you navigate the possible paths through your discovered use cases in a best practice manner. Covering topics such as OpenID Connect (OIDC) flows, Authorization server capabilities, session management, and Single Sign-On (SSO), engagement with the Auth0 Professional Services team provides visibility into the things you need to prepare you to address what's required. Delivered as part of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).
+
+## Keep reading
+
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
diff --git a/fr-ca/articles/services/implement.md b/fr-ca/articles/services/implement.md
new file mode 100644
index 0000000000..515db956b8
--- /dev/null
+++ b/fr-ca/articles/services/implement.md
@@ -0,0 +1,41 @@
+---
+title: Implement
+description: Learn how Professional Services can help you implement your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - implementation
+contentType: concept
+useCase:
+  - implementation
+---
+# Implement
+
+To help you accelerate your integration with Auth0, we provide a wide range of implementation services that you can leverage to achieve the product functionality, service connectivity, operational readiness, and/or quality assurance required to get you into production. Auth0 is a unique service that offers developers unrivaled flexibility and extensibility, and our expert Professional Services team knows how to integrate with Auth0 in ways that are the most optimal for the platform and for your environment.
+
+<%= include('./_includes/_further-help.md') %>
+
+## Programming Advisory
+
+Focused on accelerating your development team’s understanding of Auth0 SDKs, APIs, extensibility and integration points, our Programming Advisory services give you the opportunity to engage with our team to get best practice guidance on a wide range of topics. We can provide your development teams with code samples and programming guidance that will help you integrate with Auth0 faster and more effectively, whatever your chosen language or technology stack. Delivered through a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).    
+
+## Deployment Preparation
+
+Provides for validation on an implemented solution, typically prior to go-live. Our Deployment Preparation services primarily focus on review of integration—including usage of the Auth0 SDKs, APIs, and extensibility—as well as setup configuration of Auth0 and Auth0 Tenant. We can provide you with the peace of mind that the systems you deploy will be safe and secure. Delivered via a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages). 
+
+## Custom Implementation
+
+In addition, our Custom Implementation services—delivered as part of a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages)—provide a wide range of customized implementations to help you accelerate your integration with Auth0. Custom Implementation gives you the opportunity to leverage our implementation services in cases where you need more than the standard out-of-box functionality: 
+
+* **Custom rules, hooks, DB scripts, login pages, and email templates:** Solve user experience, 3rd-party service integration, or other logical problem within a customer’s Auth0 authentication and authorization workflow. These customizations happen in-product and do not require additional infrastructure to deploy.
+
+* **Custom APIs and libraries:** Solve service communication, user experience, or tenant management problem through the use of a custom web services endpoint or code library. Typically deployed on customer or third-party infrastructure.
+
+* **Custom utilities:** Solve quality assurance or operations problems that are out-of-band from extending core product functionality, such as performance testing or deployment scripts.
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+
diff --git a/fr-ca/articles/services/index.md b/fr-ca/articles/services/index.md
new file mode 100644
index 0000000000..4fbecde974
--- /dev/null
+++ b/fr-ca/articles/services/index.md
@@ -0,0 +1,72 @@
+---
+url: /services
+classes: topic-page
+title: Auth0 Professional Services
+description: Professional Services offered by Auth0.
+topics:
+  - professional services
+contentType:
+  - index
+useCase:
+  - development
+---
+
+
    
+  
    
+  
    Auth0 Professional Services
    
+  
    
+    The Auth0 Professional Services portfolio consists of innovative, specialized service offerings designed to optimize customers' investments in Auth0. Professional Services help customers deploy, implement, and maintain solutions based on proven practices, avoiding common pitfalls and reducing risk.
+  
    
+
    
+
+## How Professional Services can help with your project
+
+Customers buy software to solve a business problem. The longer it takes to integrate with that software, the longer the business problem remains unsolved. If integration stalls or fails, it’s a lost opportunity and a major additional cost both for you and for Auth0; at worst, it can become an even bigger security issue or legal nightmare. That's why it's of the utmost importance to plan, design, and implement your IAM solution securely, effectively, and expediently. This is where Auth0 Professional Services (PS) come in. 
+
+### Get to production faster
+
+
      
+
+We can help consolidate all the enablement activities leading to a successful adoption into three major milestones; the goal of a Professional Services engagement is to identify, document, and build consensus with you on these milestones as the path to successful Auth0 adoption: 
+
+* **Discovery and Design:** where our Solution Architects will work with your teams to identify the core goals, features, and functionality that constitute your successful IAM implementation. We'll also help you uncover any legacy architectural issues or design requirements that may need more careful consideration.
+
+* **Initial Go-Live:** designed to be impactful enough to make material differences in your overall Identity project. At the same time, it's limited enough that it can be reached quickly—ideally within 30 days of the project start—to keep the positive momentum. Initial Go-Live typically includes migration off a legacy IDP, must-have features, and possibly a subset of all your applications.
+
+* **Advanced Go-Live:** which can be easily broken into multiple sub-milestones—especially if you have multiple applications or development teams. This helps manage the complexity of a large project and is designed to help you achieve incremental and steady progress. 
+
+
    
+
+
      
+  
    • 
+    Services
+
+Designed to optimize our customers' investment in Auth0, our service offerings provide the proven best practice assistance required to help avoid common pitfalls and reduce risk when tackling the range of activities involved as part of integrating with Auth0:
+    
+  
      • 
+
    
+
+
      
+  
    • 
+    Packages
+
+Our packages provide our customers with the services they need, in a manner structured to help them engage with our experts in a way that best suits their requirements. [See a full list of the packages we offer](/services/packages) and discover which of them would be a good fit for you.
+  
      • 
+
    
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
diff --git a/fr-ca/articles/services/maintain-and-improve.md b/fr-ca/articles/services/maintain-and-improve.md
new file mode 100644
index 0000000000..6a65da44bb
--- /dev/null
+++ b/fr-ca/articles/services/maintain-and-improve.md
@@ -0,0 +1,28 @@
+---
+title: Maintain and Improve
+description: Learn how Professional Services can help you maintain and improve on your Auth0 investment.
+toc: true
+topics:
+    - ps
+    - maintain
+    - improvement
+contentType: concept
+useCase:
+  - maintain-and-improve
+---
+# Maintain and Improve
+
+Once complete, we can work with your teams to review your identity environment, optimize and improve your solution, advise on new features, and answer any questions; all of these services are designed to help you maintain and improve on your Auth0 investment. To support this, we recommend scheduling an annual HealthCheck engagement with Professional Services via one of our [Maintain and Improve packages](/services/packages#maintain-and-improve-packages).
+
+For our larger customers, we also provide our “Premier Success” post-implementation consulting service via our [Maintain and Improve packages](/services/packages#maintain-and-improve-packages). This assigns a dedicated Solutions Architect to meet with your team on a weekly, bi-weekly, or monthly basis to provide you with the ongoing assistance a demanding environment can often require.
+ 
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Solution Design](/services/solution-design)
+* [Custom Implementation](/services/custom-implementation)
+* [Packages](/services/packages)
+ 
+
+
diff --git a/fr-ca/articles/services/packages.md b/fr-ca/articles/services/packages.md
new file mode 100644
index 0000000000..79947158d6
--- /dev/null
+++ b/fr-ca/articles/services/packages.md
@@ -0,0 +1,131 @@
+---
+title: Professional Service Packages
+description: Learn how to get Auth0 Professional Services help through one of our many packaged offerings
+toc: true
+topics:
+    - ps
+    - packages
+contentType: 
+    - index
+    - concept
+useCase:
+  - packages
+---
+# Professional Service Packages
+
+Auth0 Professional Services provides packaged offerings designed to optimize our customers' investments in Auth0 by helping design, deploy, implement, and maintain solutions based on proven practices, which allows our customers to avoid common pitfalls and reduces risk. Packaged offerings generally fall into two main categories: Discover, Design, and Implement packages, and Maintain and Improve packages. To get more information and to order any of these service offerings, please contact your Auth0 Account Representative.
+
+## Discover, Design, and Implement packages
+
+
    
+	
+	
+		 Discovery Workshop
+
    
+
+* 2 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 90 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+
+
    
+	
+	
+		 Basic Package
+
    
+
+* 5 days of services
+* Remote only
+* Expires in 90 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+
+
    
+	
+	
+		 Standard Package
+
    
+
+* 12 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 180 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+  * Some [Custom Implementation](/services/implement#custom-implementation)
+
+
    
+	
+	
+		 Advanced Package
+
    
+
+* 25 days of services
+* On-site
+* Expires in 180 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+  * [Custom Implementation](/services/implement#custom-implementation)
+
+
    
+	
+	
+		 Custom Implementation Package
+
    
+
+* 15 or more days of services
+* Remote only
+* Expires in 180 days
+* Terms and Conditions apply
+* Full range of [Custom Implementation](/services/implement#custom-implementation) services, including:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery), 
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance) and 
+  * [Programming Advisory](/services/implement#programming-advisory)
+  
+## Maintain and Improve packages
+
+
    
+	
+	
+		 Implementation HealthCheck Package
+
    
+
+* 1 to 3 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 90 days
+* Terms and Conditions apply
+* Wide range of [maintain and improve](/services/maintain-and-improve) services
+ 
+
+
    
+	
+	
+		 Premier Success Package
+
    
+
+* 24 days of services
+* On-site
+* Expires in 365 days
+* Terms and Conditions apply
+* Full range of [maintain and improve](/services/maintain-and-improve) services
+
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
diff --git a/fr-ca/articles/services/pair-programming.md b/fr-ca/articles/services/pair-programming.md
new file mode 100644
index 0000000000..a2aff15193
--- /dev/null
+++ b/fr-ca/articles/services/pair-programming.md
@@ -0,0 +1,29 @@
+---
+description: Project to co-develop integration points with Auth0.
+topics:
+  - professional services
+  - pair-programming
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Pair Programming
+
+Auth0 engineers will join the customer development teams during initial phases of development, under a pair-programming mode, focusing on Auth0 related code and integration points. The goal is to speed-up development and mitigate risks.
+
+## Estimated effort
+
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and customer's development team.
+
+## Typical work-streams
+
+* **Pair-programming sessions:** co-implement with customer development teams, common authentication flows using Auth0.
+
+
+## Deliverables
+
+* Jointly developed code.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/performance-scalability.md b/fr-ca/articles/services/performance-scalability.md
new file mode 100644
index 0000000000..47ec47f31b
--- /dev/null
+++ b/fr-ca/articles/services/performance-scalability.md
@@ -0,0 +1,34 @@
+---
+description: Project to assist customers with common performance testing needs, including a correct planning, and test automation guidance.
+topics:
+  - professional services
+  - performance
+  - scalability
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Performance and Scalability
+
+An offering to assist customers with common performance testing needs, including a correct planning, and test automation guidance.
+
+## Estimated effort
+
+This is typically a 4-6 week part-time engagement effort with an Auth0 Managed Service Engineer and your infrastructure team.
+
+## Typical work-streams
+
+* **Planning:** gather customer requirements for setting benchmarks.
+* **Performance Lab Design:** lab environment for testing, including network topology, artifacts required, load generation tools, automation scripts.
+* **Test runs:** work with the customer on 3 testing and tuning iterations.
+* **Results Analysis:** documenting findings and recommendations.
+
+## Deliverables
+
+* Architecture document
+* Test execution document
+* Recommendations document
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/private-cloud-configuration.md b/fr-ca/articles/services/private-cloud-configuration.md
new file mode 100644
index 0000000000..023a05dd68
--- /dev/null
+++ b/fr-ca/articles/services/private-cloud-configuration.md
@@ -0,0 +1,34 @@
+---
+description: A project to assist with design and deployment of a Private Cloud Auth0 environment.
+topics:
+  - professional services
+  - private-cloud
+  - design
+  - deployment
+  - configuration
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Hours: Private Cloud reconfiguration
+
+A project to assist with the design, and deployment of a Private Cloud Auth0 environment; including HA and DR scenarios.
+
+## Estimated effort
+
+This is typically a 2-3 week part-time engagement effort with an Auth0 Managed Service Engineer and your infrastructure team.
+
+## Typical work-streams
+
+* **Requirements gathering:** understanding customer Private Cloud deployment requirements and constraints.
+* **Risk analysis:** reviewing and providing guidance for High Availability, and Disaster Recovery alternatives.
+
+## Deliverables
+
+* Technical documentation.
+* Deployment checklist.
+* Assist with deployment.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/private-cloud-management.md b/fr-ca/articles/services/private-cloud-management.md
new file mode 100644
index 0000000000..9670cf91b2
--- /dev/null
+++ b/fr-ca/articles/services/private-cloud-management.md
@@ -0,0 +1,29 @@
+---
+description: A workshop designed to provide IT organizations with core Auth0 Private Cloud management concepts.
+topics:
+  - professional services
+  - private-cloud
+  - management
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Training: Private Cloud Management Workshop
+
+A workshop designed to provide IT organizations with core concepts on availability, reliability, on-going operations and security in their Private Cloud Auth0 service.
+
+## Duration
+
+Two (2) working sessions with an Auth0 Managed Service Engineer.
+
+## Level
+
+**Level 300**, assumes in-depth understanding of Auth0's core features.
+
+## Topics covered
+
+Operations and Administration Tasks, Roles & Responsibilities, complete Dashboard review, review Support procedures, and operational best practices.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/scenario-guidance.md b/fr-ca/articles/services/scenario-guidance.md
new file mode 100644
index 0000000000..fc211feb9e
--- /dev/null
+++ b/fr-ca/articles/services/scenario-guidance.md
@@ -0,0 +1,33 @@
+---
+description: Project to help customers address specific requirements related to a current project that is expected to use Auth0.
+topics:
+  - professional services
+  - product-lifecycle
+  - solutions-architecture
+  - architecture
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Scenario guidance
+
+An offering to help customers address specific requirements related to a current project that is expected to use Auth0. This service is applicable in all phases of a product lifecycle, delivered remotely in a variety of ways (such as technology briefings, Q&A sessions, and so on).
+
+## Estimated effort
+
+Includes up to three (3) working sessions, where we will jointly draft a high-level solution to address the requirements of your scenario with an Auth0 Solutions Architect. We will provide a recommendations memo afterwards for your reference.
+
+Diagrams or information you deem relevant should be provided prior to this engagement so that we can optimize the time available.
+
+
+## Typical work-streams
+
+* **Working sessions:** review requirements, jointly discuss architecture solution. Document findings and agreements.
+
+## Deliverables
+
+* Technical document: infrastructure decisions, requirements, setup details, processes, simulation details.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/fr-ca/articles/services/solution-design.md b/fr-ca/articles/services/solution-design.md
new file mode 100644
index 0000000000..c693dd13f1
--- /dev/null
+++ b/fr-ca/articles/services/solution-design.md
@@ -0,0 +1,40 @@
+---
+title: Solution Design
+description: Learn how Professional Services can help you design and architect your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - solution
+    - design
+contentType: concept
+useCase:
+  - solution-design
+---
+# Solution Design
+
+The first step in a successful implementation is designing and architecting your Identity and Access Management solution, and our Solution Design services are here to help. We work together with your product and engineering teams to **architect an Identity solution** for your environment and build an **incremental Go-Live plan** that solves the most-pressing identity problems early. Auth0 Professional Services help your project reach success quickly and address your business objectives in a pragmatic, step-by-step manner. 
+
+PS Solutions Architects have decades of combined industry expertise and Auth0-specific training. We have delivered **thousands of successful IAM projects and integrations**. Let us help you steer clear of costly security pitfalls and build a solid foundation for your identity needs, all while reducing risk.
+
+## Get to production faster
+
+We can consolidate all the enablement activities leading to a successful adoption into three major milestones or phases; the goal of a Professional Services engagement is to identify, document, and build consensus with you on these milestones as the path to successful Auth0 adoption: 
+
+* Solution discovery and architectural design
+* Initial Go-Live
+* Advanced Go-Live
+
+In the discovery phase, our Solution Architects will work with your teams to identify the core goals, features, and functionality that constitute your successful IAM implementation. We will also uncover any legacy architectural issues or design requirements that may need more careful consideration.
+
+The initial Go-Live milestone is designed to be impactful enough to make material differences in the overall Identity project. At the same time, it is limited enough that it can be reached quickly—ideally within 30 days of the project start—to keep the positive momentum. The initial Go-Live typically includes migration off a legacy Identity Provider (IdP), must-have features, and possibly a subset of all applications.
+
+The last milestone, Advanced Go-Live, can be broken into multiple sub-milestones, especially if you have multiple applications or development teams. This helps manage the complexity of a large project and achieves incremental and steady progress. 
+
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Custom Implementation](/services/custom-implementation)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+* [Gallery](/services/gallery)
diff --git a/fr-ca/articles/sessions/concepts/cookie-attributes.md b/fr-ca/articles/sessions/concepts/cookie-attributes.md
new file mode 100644
index 0000000000..72a9db75de
--- /dev/null
+++ b/fr-ca/articles/sessions/concepts/cookie-attributes.md
@@ -0,0 +1,128 @@
+---
+description: Understand how browser changes, such as the samesite cookie attribute, affects your web applications that embed content from third-party domains. 
+topics:
+  - saml
+  - identity-providers
+  - oidc
+  - cookies
+  - samesite
+  - google-chrome
+  - microsoft-edge
+contentType:
+  - concept
+useCase:
+  - third-party-content
+  - use-samesite-cookie-attribute
+  - maintain-browser-compatiblity
+---
+# sameSite Cookie Attributes
+
+Cookies, which are used for authentication and the maintenance of sessions, can be secured by setting its attributes.
+
+Auth0 uses cookies for the following:
+
+* OIDC Enterprise with `form_post`
+* SAML HTTP-POST Binding
+* Web message (aka `checkSession`)
+
+## The `sameSite` attribute
+
+The `sameSite` cookie attribute restricts browser behavior. It may prevent the browser from sending the cookie's key-value pair based on the type of interaction that triggered the HTTP request.
+
+Accepted attribute values are as follows:
+
+| Attribute | Description |
+| -- | -- |
+| `strict` | Send the cookie if the user is navigating within the website origin bounds it came from |
+| `lax` | Send the cookie if the user is navigating within the website origin bounds it came from or if they're being redirected to it |
+| `none` | Send the cookie with requests crossing the website origin bounds. Unless other conditions are present (i.e., third-party cookies are blocked), do not send the cookie. |
+
+Some of the cookie attributes you may be familiar with include:
+
+| Attribute | Description |
+| - | - |
+| `httpOnly` | Allows a cookie to be sent only with HTTP requests; not readable using Javascript's `document.cookie` |
+| `secure` | Allows the browser to send the cookie only to a secure context; whether the context is considered secure or not is browser-dependent, but this typically requires the use of HTTPS |
+| `max-age / expires` | Controls whether the cookie is a **session** cookie (e.g., dropped when your browser terminates its session) or **persistent** (e.g., the cookie persists beyond the browser session) |
+
+Please note that these attributes can also be provided by the server using the `set-cookie` headers included with HTTP responses. The browser, upon receipt, parses the headers and updates its cookie jar accordingly.
+
+## Changes Auth0 is making
+
+Effective February 2020, Google Chrome v80 will change the way it handles cookies. To that end, Auth0 plans on implementing the following changes to how it handles cookies:
+
+* Cookies without the `samesite` attribute set will be set to `lax`
+* Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar
+
+The goal of these changes are to improve security and help mitigate CSRF attacks.
+
+These changes affect the following cookies:
+
+* `auth0` (handles user sessions)
+* `auth0-mf` (handles information relevant to multi-factor authentication)
+* `did` (the identifier for a device/user agent)
+
+For these cookies, Auth0 will:
+
+* Set the `sameSite` attribute to `none`, with the cookie requiring the use of HTTPS (regardless of environment).
+* Set fallback cookies in the event that a legacy browser does not support `sameSite` being set to `None`. These fallback cookies are `auth0_compat`, `auth0-mf_compat` and `did_compat`.
+
+## Changes you need to make
+
+To prepare for this change, you should:
+
+* Review the list of [unsupported browsers](https://www.chromium.org/updates/same-site/incompatible-clients).
+
+* Set your application to use `sameSite=none` if it uses `response_mode=form_post` when interacting with Auth0 (note that Chrome makes no exceptions, even for `localhost`)
+
+* Set your cookie as secure if its `sameSite` attribute equals `None`, otherwise it will be rejected by the browser. If you use HTTP for your Callback URLs, these will break if you use such cookies for binding the authorization request state/nonce. Therefore, you must either use HTTPS or set `sameSite=lax`.
+
+## How this works
+
+The diagram below shows what happens during a fresh interaction.
+
+The end user requests a page they have not visited before. The server wishes to change the way it renders when the visitor returns so it sets a *seen* cookie. The grey part of the `set-cookie` header is the actual cookie key-value, the red portion are the cookie attributes the browser stores in its cookie jar to decide later if it should include the cookie key+value pair in its requests.
+
+![Fresh Interaction](/media/articles/sessions/cookie-fresh-interaction.png)
+
+The following diagram shows what happens if you make the same request using the same browsing session.
+
+The request goes to the same server, and because the cookie attributes don't prohibit the *seen* cookie to be sent, it is automatically included as a cookie header in the request. The server will now respond differently based on the fact that it received this cookie.
+
+![Fresh Interaction](/media/articles/sessions/cookie-return-interaction.png)
+
+## Effect of the changes to the `sameSite` cookie attribute
+
+The table below shows how the `sameSite` attribute changes may affect your apps.
+
+| App Behavior | Affected by Change |
+| -- | -- |
+| Cookies set as `sameSite=none` while the website is not `https://` | Yes |
+| Cookies don't have explicit `sameSite` attribute value set and are required in a cross-origin context (such as HTTP Form Post, embedding an iframe) | Yes |
+| Native apps (everything not cookies + web based) | No (M2M) |
+| Already setting an explicit `sameSite` cookie attribute value | No |
+| Different subdomain on the same eTLD+1 (app is on the same eTLD+1 as the custom domain Auth0 tenant) | Potentially |
+
+If you are using a web app with sessions (e.g. for saving user preferences, shopping carts, etc.), and you allow users to sign in using identity providers such as Google, Apple or Auth0, then you rely on cookies to achieve that functionality. There are browser cookie behavior changes that may break your user experience. Google Chrome, for example, is going to be the first browser vendor to roll out a change that might not be compatible with your web application.
+
+You may notice that the Google Chrome and Microsoft Edge specs for setting `sameSite` to undefined has changed from `sameSite` defaulting to `none` to `lax` instead. 
+
+For example, let's say you are building a new UI and have several services that you proxy to via an Auth0 gateway. At this gateway, you create a cookie session. If you make a cross-origin request, you may see this warning in the Javascript console:
+
+``` text
+A cookie associated with a cross-site resource (URL) was set without the SameSite attribute. 
+A future release of Chrome will only deliver cookies with cross-site requests if they are 
+set with SameSite=None and Secure. You can review cookies in developer tools under 
+Application>Storage>Cookies and see more details at 
+https://www.chromestatus.com/feature/5088147346030592 and 
+https://www.chromestatus.com/feature/5633521622188032
+```
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Web Apps vs Web APIs/Cookies vs Tokens](/design/web-apps-vs-web-apis-cookies-vs-tokens)
+* [Cross-Origin Authentication](/cross-origin-authentication)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Security](/security)
diff --git a/fr-ca/articles/sessions/concepts/cookies.md b/fr-ca/articles/sessions/concepts/cookies.md
new file mode 100644
index 0000000000..cf6ce50b56
--- /dev/null
+++ b/fr-ca/articles/sessions/concepts/cookies.md
@@ -0,0 +1,65 @@
+---
+title: Cookies
+description: Understand what cookies are and how they can be used with sessions to track user authentication.
+toc: true
+topics:
+  - cookies
+  - sessions
+  - authentication
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Cookies
+
+Cookies are strings of data that a web server sends to the browser. When a browser sends a future request to the web server, it sends the same string to the web server along with its request.
+
+Websites typically use cookies to ensure that users are recognized when they move between pages, so they don't get asked to log in again every time. Websites also use cookies to remember information users have entered. For example, e-commerce sites use cookies to remember the items placed in a shopping cart. 
+
+Users can choose whether to accept cookies by changing the settings in their browser.
+
+## Use cookies with authentication
+
+When you build an application that requires authentication, you can use [sessions](/sessions) and cookies to determine if a user is authenticated each time a request is made. To do this, you can choose to use either stateful or stateless cookies.
+
+### Stateful cookies
+
+Stateful cookies contain a pointer to a database record that stores the session information.
+
+**Pros**:
+
+* Have no limitations on amount of session information stored.
+* Can easily clear a user's session--just remove the record from the database.
+
+**Cons**:
+
+* Requires a database to store the session data (but most web applications already have this).
+* Increases latency because you have to make database calls to read the session (and sometimes write it) for each HTTP request a user makes.
+* Can be challenging to scale when you have many users and therefore many reads/writes to your database.
+
+### Stateless cookies
+
+Stateless cookies are self-contained; they include all session information that you need (for authenticated users, the user ID) and reside on the client. To prevent external tampering, stateless cookies should be encrypted (or at least signed).
+
+**Pros**:
+
+* Can implement easily; doesn’t require a special backend.
+* Reduces latency because you don't have to call a database.
+* Easy to scale.
+
+**Cons**:
+
+* Must restrict stored session information because cookies are limited in size (max 4KB in most browsers). Although session information may be split between multiple cookies, we don't recommend it.
+* Makes it difficult to revoke a session, because there is no record in a database you can delete; you’ll need to find other methods to forcefully clear a session.
+* If using multiple web servers, must make sure all servers have the key to encrypt/decrypt or sign the cookie.
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
diff --git a/fr-ca/articles/sessions/concepts/session-layers.md b/fr-ca/articles/sessions/concepts/session-layers.md
new file mode 100644
index 0000000000..d013992e1a
--- /dev/null
+++ b/fr-ca/articles/sessions/concepts/session-layers.md
@@ -0,0 +1,64 @@
+---
+description: Understand the differences between application, Auth0, and identity provider sessions and how logout works in the different sessions. 
+toc: true
+topics:
+  - sessions
+  - sso-session
+  - auth0-session
+  - idp-session
+  - application-session
+  - federated logout
+contentType: concept
+useCase:
+  - sessions
+  - session-logout
+  - session-lifetime
+  - using-cookies
+---
+
+# Session Layers
+
+There are typically three session layers that can be created when your users log in: 
+
+* **Application Session Layer**: This layer is the session inside your application. Though your application uses Auth0 to authenticate users, your application also tracks that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a [cookie](/sessions/concepts/cookies). 
+
+* **Auth0 Session Layer**: Auth0 also maintains a session on the Authorization Server for the user and stores their user information inside a cookie. This layer is used so that the next time a user is redirected to Auth0 for login the user's information will be remembered. This session layer makes the [Single Sign-On (SSO)](/sso) experience possible for [inbound SSO implementations](/sso/current/inbound).
+
+* **Identity Provider Session Layer**: When users attempt to sign in using an identity providers such as Facebook or Google, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in though they may be asked to give permission to share their information with Auth0 and, in turn, your application. See [How to set up IdP-initiated SSO](/protocols/saml/idp-initiated-sso#how-to-set-up-idp-initiated-sso) for more information. 
+
+## Session logout
+
+
    
+
+Logout in the context of Auth0 implementations is the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. 
+
+Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
+
+* **Application Session Layer Logout**: Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination. This will require you to utilize whatever application session stack you are using to clear out any session related information. Note that some of the Auth0 SDKs do provide some support for application sessions; please check the documentation to see if there is any local SDK session removal that needs to be done.
+
+* **Auth0 Session Layer Logout**: You can log users out of the Auth0 session layer by redirecting them to the Auth0 logout endpoint so Auth0 can clear the [Single Sign-on (SSO)](/sso) cookie.
+
+* **Identity Provider Session Layer Logout**: It is not necessary to log the users out of this session layer, but you can use Auth0 to force the logout if required. 
+
+### Redirect URLs
+
+Logging out of your Auth0 Session Layer will require you to redirect the user to `https:///v2/logout` - typically performed via use of the appropriate method in the Auth0 SDK for your technology stack. This will clear your Auth0 session. You will also want to add a query parameter for that request called `returnTo` - this parameter should contain a URL that has been pre-registered and protects you against open redirect attacks. For more information, see [Authentication API: Logout](/api/authentication?javascript#logout).
+
+Auth0 only redirects to whitelisted URLs after logout and there are two places you can configure these. The first place you can set this is at your Auth0 tenant level where you can put the set of logout URLs that are shared between all applications. The second place is in the application settings: if you need different redirects for each application, you can whitelist the URLs in your application settings. This allows you to set logout URLs in an application-specific context. 
+
+### Session lifetime and session timeout
+
+You can also set the behavior in cases where a user doesn’t explicitly logout of your application. Auth0 provides for [session lifetime limits](/sessions/concepts/session-lifetime) to deal with Auth0 session termination in this scenario. 
+
+### Federated logout
+
+Alternatively you may desire to also [log the users out of the Identity Provider Session Layer](/logout/guides/logout-idps). While this is not recommended, for many providers, Auth0 will give you this behavior by simply having you add the `federated` query parameter to the redirect to `/v2/logout`. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
+* [Auth0 Ruby on Rails SDK Quickstarts: Session Handling](/quickstart/webapp/rails/02-session-handling)
+* [Auth0 Android SDK Quickstarts: Session Handling](/quickstart/native/android/03-session-handling)
diff --git a/fr-ca/articles/sessions/concepts/session-lifetime.md b/fr-ca/articles/sessions/concepts/session-lifetime.md
new file mode 100644
index 0000000000..2ae61eecaa
--- /dev/null
+++ b/fr-ca/articles/sessions/concepts/session-lifetime.md
@@ -0,0 +1,71 @@
+---
+title: Session Lifetime
+description: Understand what session lifetimes are and learn about the relevant settings.
+topics:
+  - sessions
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Session Lifetime
+
+Session lifetime limits determine how long the system should retain a login session.  In Auth0, two settings can be configured for session lifetime:
+
+* **Inactivity timeout**: Timeframe after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 3 days for self-service plans or 100 days for enterprise plans.
+
+* **Require log in after**: Timeframe after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 30 days for self-service plans or 365 days for enterprise plans.
+
+These settings are configured on the [tenant](/getting-started/the-basics#account-and-tenants); you can [configure them](/dashboard/guides/tenants/configure-session-lifetime-settings) using either the Auth0 Dashboard or the Management API.
+
+## Application-specific logout URLs
+
+There are two important things to consider when you use application-specific logout URLs:
+
+* You **must** send `client_id` as a query parameter when calling the `/v2/logout` endpoint and the `returnTo` URL must be in the application’s list of allowed logout URLs.
+
+* This will end the Auth0 Session for the entire tenant - i.e. for all defined applications, not just the one that matches the `client_id` supplied. Passing the `client_id` tells the `logout` endpoint where to look for the logout URL white-list.
+
+After the user logout occurs Auth0 will only redirect to a URL that is defined in this list. 
+
+::: warning
+If you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out - and, if desired, you can also warn them that they may still be logged into their identity provider.
+:::
+
+In the case a user has not taken any actions that would cause the Auth0 session to be updated it is recommended that warning be raised to the user to choose to explicitly continue their session.
+
+The intent of this approach allows the session to go inactive if the user is no longer present, but otherwise provides a means to trigger the silent token refresh so that they can continue their session without the need to be prompted again for credentials.
+
+* **Inactivity Timer**: A rolling timer should be added to the React SDK wrapper that aligns with the maximum idle lifetime of the Auth0 session.  Each time a token is returned to the application the timer should be reset.
+
+* **Timeout Modal**: When the timer hits 60 seconds from expiration a timeout modal should render requesting the user to logout or continue their session. 
+
+    * **Continue the session**: In the case the user chooses to continue their session the getTokenSilently() method can be used to request a new token without needing to redirect the user from the page they are currently interacting with.
+
+    * **Logging out**: In the case the user chooses to logout the logout() method should be called to assure the Auth0 session is ended as well.
+
+    * **Idle Timeout**: In the case that the idle timeout is reached no immediate action is necessary.  To handle the fact that the user may still be active in another tab, the behavior **should not** be to log the user out. 
+
+    Other options might include updating the modal with a login button, using the window.onfocus event to trigger `getTokenSilently()`, or redirecting the user to landing page.
+
+## Examples: Session lifetime limits
+
+Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session. Let's look at an example.
+
+1. You set the **Inactivity timeout** limit to 3 days and the **Require log in after** limit to 30 days.
+2. A user logs in and your entered values are set for their session. 
+  * If the user is active within the three-day **Inactivity timeout** timeframe, the session lifetime is extended for another three days. As long as the user is active within the next three days, their session lifetime will be extended for another three days, until the **Require log in after** limit is reached. At this point, the user will be required to log in again.
+  * If the user is inactive for three days, they will automatically be logged out. 
+3. While the user is logged in, you extend the existing session lifetime limits. The new settings will not take effect until the existing session ends, and the user logs in again.
+4. While the user is logged in, you reduce the existing lifetime limits. The new settings will take effect immediately upon the user's next activity. This allows you to shorten session lifetimes for security purposes.
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
+* [Auth0 Ruby on Rails SDK Quickstarts: Session Handling](/quickstart/webapp/rails/02-session-handling)
+* [Auth0 Android SDK Quickstarts: Session Handling](/quickstart/native/android/03-session-handling)
diff --git a/fr-ca/articles/sessions/index.md b/fr-ca/articles/sessions/index.md
new file mode 100644
index 0000000000..d653876353
--- /dev/null
+++ b/fr-ca/articles/sessions/index.md
@@ -0,0 +1,25 @@
+---
+title: Sessions
+classes: topic-page
+description: Understand what sessions are and how to implement them.
+topics:
+  - sessions
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Sessions
+
+A session is a group of interactions between a user and an application that take place within a given timeframe. A single session can contain multiple activities (such as page views, events, social interactions, and e-commerce transactions), all of which the session stores temporarily while the user is connected.
+
+By default, when a user leaves a website or closes their browser, their session ends. To keep users from having to log in every time they return, applications can extend sessions by storing session information in a cookie. Sessions end when a user logs out or when session lifetime limits are reached. Password resets cause Auth0 sessions to expire. 
+
+<%= include('../_includes/_topic-links', { links: [
+  'sessions/concepts/session-layers',
+  'sessions/concepts/session-lifetime',
+  'sessions/concepts/cookies',
+  'sessions/concepts/cookie-attributes',
+  'logout',
+  'sessions/references/sample-use-cases-sessions',
+  'sessions/references/example-short-lived-session-mgmt'
+ ] }) %>
diff --git a/fr-ca/articles/sessions/references/example-short-lived-session-mgmt.md b/fr-ca/articles/sessions/references/example-short-lived-session-mgmt.md
new file mode 100644
index 0000000000..4ad8a94cf1
--- /dev/null
+++ b/fr-ca/articles/sessions/references/example-short-lived-session-mgmt.md
@@ -0,0 +1,99 @@
+---
+description: Example workflow shows how the auth0-spa-js SDK should be implemented to support multi-site session management.
+toc: true
+topics:
+  - sessions
+  - sso-session
+  - auth0-session
+  - application-session
+contentType: concept
+useCase:
+  - application-session-workflow
+---
+
+# Example: Application Sessions and SSO Sessions Workflow
+
+This workflow shows how the `auth0-spa-js` SDK should be implemented to support multi-site session management.  In this scenario, it is assumed that the tenant SSO Inactivity Timeout is set to 300 seconds, and the ID Token Expiration of each SPA application is set to 150 seconds. This is considered a "short-lived" session. 
+
+::: panel Support for Long-Lived Sessions
+Auth0 supports long-lived sessions for enterprise Auth0 customers. With long-lived sessions, you can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout). If you have quarterly, monthly, or other timelines, this allows you to reduce friction for end-users and provide access to low-risk content and capabilities. In addition, media companies can leverage long-lived sessions for improving user experiences through seamless access to content. You can also make the choices between long-lived sessions and password validation based on your requirements around user experience and security. 
+
+Workflow details would change in the case of a long-lived session where the application session would most likely be shorter than the [Single Sign-on (SSO)](/sso) session.
+
+You can also see [Configure Session Lifetime Limits](/sso/current/configure-session-lifetime-limits) and [Update Access Token Lifetime](/dashboard/guides/apis/update-token-lifetime) for more information.
+:::
+
+## SDK features
+
+### PKCE flow
+
+For all methods of retrieving an ID Token or Access Token, the SDK manages all the intricacies of the Proof Key for Code Exchange workflow. No additional effort or configuration is needed for this to work.
+
+### Deep linking
+
+To improve the user experience the SDK includes an `appState` parameter for the `loginWithRedirect()` method. Details about the current app are packaged as part of the request to the Auth server that will be returned upon successful authentication. Allowing a seamless continuation of the user journey. 
+
+In the Quickstart, the `PrivateRoute` component sets a state parameter of `targetUrl` and the `onRedirectCallback` function of `index.js` unpacks this value to redirect the user when authentication is complete.
+
+### Token storage
+
+To keep the returned tokens stored in the safest manner possible all tokens are placed into a local cache. The ID and Access Tokens are stored as pairs with the audience and scope values being used to retrieve the tokens as needed.
+
+Additionally the cache tokens are removed once either the ID Token or Access Token expires so that if a token is in the cache it can be assumed to stil be valid.
+
+### Calling APIs
+
+The `getTokenSilently()` method is used to leverage the token cache first, and if none exists, will launch an invisible iframe to retrieve a new token.  For this purpose all requests to APIs can use this method to construct the bearer token header without the need for additional logic to handle for expired tokens.
+
+In the Quickstart, the `ExternalService` view makes a request to the express API using this feature.
+
+### Warn users to continue their sessions
+
+In the case where a user has not taken any actions that would cause the Auth0 session to be updated, Auth0 recommends that you raise a warning to the user to choose to explicitly continue their session.
+
+The intent of this approach allows the session to go inactive if the user is no longer present, but otherwise provides a means to trigger the silent token refresh so that the can continue their session without the need to be prompted again for credentials. 
+
+See [Application-specific logout URLs](/sessions/concepts/session-lifetime#application-specific-logout-urls) for more information about inactivity timers and timeout modals. 
+
+## Example workflow
+
+1. [Initial Authentication](#initial-authentication)
+2. [Maintaining Auth0 Session](#maintaining-auth0-session)
+3. [Seamless SSO](#seamless-sso)
+4. [Prompting user to extend session](#prompting-user-to-extend-session)
+5. [User explicitly logs out of application](#user-explicitly-logs-out-of-application)
+6. [User returns to initial app after logging out](#user-returns-to-initial-app-after-logging-out)
+
+### Initial authentication
+
+![Initial Authentication](/media/articles/sessions/initial-authentication.png)
+
+### Maintaining Auth0 session
+
+![Maintain Auth0 Session](/media/articles/sessions/maintain-auth0-session.png)
+
+### Seamless SSO
+
+![Seamless SSO](/media/articles/sessions/seamless-sso.png)
+
+### Prompting user to extend session
+
+![Prompting User to Extend Session](/media/articles/sessions/prompt-user-extend-session.png)
+
+### User explicitly logs out of application
+
+![User Explicitly Logs Out of Application](/media/articles/sessions/user-explicitly-logs-out-of-app.png)
+
+### User returns to initial application after logging out
+
+![User Returns to Initial Application After Logging Out](/media/articles/sessions/user-returns-to-initial-app.png)
+
+## Keep reading
+
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Cookies](/sessions/concepts/cookies)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
diff --git a/fr-ca/articles/sessions/references/sample-use-cases-sessions.md b/fr-ca/articles/sessions/references/sample-use-cases-sessions.md
new file mode 100644
index 0000000000..d6757b2d36
--- /dev/null
+++ b/fr-ca/articles/sessions/references/sample-use-cases-sessions.md
@@ -0,0 +1,103 @@
+---
+description: Explore sample use cases to understand how sessions work with authentication in Auth0.
+topics:
+  - sessions
+  - sample-use-case
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Session Use Cases
+
+## For SPAs using Authorization Code grant
+
+Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session.
+
+When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. These examples are for SPAs that have a lightweight backend and are using the Authorization Code grant (also, native apps and regular web apps. 
+
+Let's say you've built an OIDC-compliant e-commerce website called Storezero.io. 
+
+![View Sample Web Site: Storezero.io](/media/articles/sessions/use-case-storezero.png)
+
+When checking out, a user can optionally log in to the site, but to view the "My Account" pages, the user _must_ log in.
+
+Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
+
+### User logs in with username and password
+
+1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session, then redirects the user to the login and authorization prompt.
+3. The user authenticates using their username and password and may see a consent page listing the permissions Auth0 will give to the application.
+4. Your Auth0 Authorization Server updates the previously-created session to indicate that the user is logged in.
+5. Your Auth0 Authorization Server redirects the user back to the application, along with either an ID Token or code (depending on which flow that you use).
+6. The application authenticates the user and creates a local session.
+
+Two sessions are created:
+
+* The local session (storezero.io): Allows the application to know if a user is authenticated.
+
+* The session on the Authorization Server (storezero.auth0.com): Allows the Authorization Server to know if a user is authenticated and optionally, tracks other information. For example, the Authorization Server can track whether a user has authenticated using [Multi-factor Authentication (MFA)](/mfa). If so, the next time the user arrives at the Authorization Server, they won't need to see a login page or be prompted to use MFA again.
+
+### User logs in with identity provider
+
+Let's say that instead of using their username and password, the user decides to log in with Facebook. 
+
+1. Auth0's SDK creates a local session and redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session.
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user chooses to log in with Facebook. 
+5. Your Auth0 Authorization Server redirects the user to Facebook's server.
+6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.
+7. Facebook redirects the user back to the Authorization Server, where the Authorization Server updates its session to indicate that the user is logged in.
+8. The Authorization Server redirects the user back to the application, along with either an ID Token or code (depending on which flow you use).
+9. The application authenticates the user and updates it's local session to indicate that the user is logged in.
+
+In addition to the two sessions created in the previous example, a third session is created:
+
+* The session on Facebook's server (facebook.com): Allows Facebook to know if the user is authenticated and if so, provides a [Single Sign-on (SSO)](/sso) experience for the user. Since there’s a high probability that the user is already logged in to Facebook, if they choose to log in to storezero.io using Facebook, they will likely not be prompted to enter their credentials.
+
+## For SPAs with no backend using the Implicit grant
+
+When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. This example is accurate for SPAs that have no backend and are using the Implicit grant. 
+
+Let's say you've built an OIDC-compliant e-commerce website called Storezero.io. 
+
+![View Sample Web Site: Storezero.io](/media/articles/sessions/use-case-storezero.png)
+
+When checking out, a user can optionally log in to the site, but to view the "My Account" pages, the user _must_ log in.
+
+Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
+
+### User logs in with identity provider
+
+Let's say that the user decides to log in with Facebook. 
+
+1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session.
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user chooses to log in with Facebook. 
+5. Your Auth0 Authorization Server redirects the user to Facebook's server.
+6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.
+7. Facebook redirects the user back to the Authorization Server, where the Authorization Server updates its session to indicate that the user is logged in.
+8. The Authorization Server redirects the user back to the application, passing an ID Token and Access Token.
+9. The application authenticates the user.
+
+Since we are using the Implicit Grant, the client (storezero.io) can consume the ID Token to authenticate the user and can use the Access Token to interact with the API (until it expires). So no local session is created to keep the user logged in.
+
+### Keep the user logged in without a local session
+
+Since we have no local session to keep the user logged in, we can use the session on the Authorization Server to determine whether to force the user to reauthenticate. We do this through [Silent Authentication](/api-auth/tutorials/silent-authentication).
+
+We create a hidden iframe that redirects to the Authorization Server adding the `prompt=none` parameter, which tells the server not to prompt the user for any input. If the session on the Authorization Server has not expired, the transaction continues seamlessly, and the client gets a new Access Token through WMRM (Web Message Response Mode), which leverages postMessage.
+
+If the session on the Authorization Server has expired or the user logs out, the redirect in the iframe will return an error, indicating that the application needs to redirect the user to the Authorization Server to reauthenticate.
+
+## Keep reading
+
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Cookies](/sessions/concepts/cookies)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [Logout](/logout)
+* [Example: Application Sessions and SSO Sessions Workflow](/sessions/references/example-short-lived-session-mgmt)
diff --git a/fr-ca/articles/sso/current/inbound.md b/fr-ca/articles/sso/current/inbound.md
new file mode 100644
index 0000000000..3533e94697
--- /dev/null
+++ b/fr-ca/articles/sso/current/inbound.md
@@ -0,0 +1,49 @@
+---
+title: Inbound Single Sign-On
+description: Overview of Inbound Single Sign-on (SSO).
+toc: true
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Inbound Single Sign-On
+
+For inbound Single Sign-On (SSO) implementations, Auth0 is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application presents the user with one or more external identity providers.
+2. The user selects an identity provider to authenticate with and logs in.
+3. Upon successful authentication, the user is returned to the application with an active session.
+
+Inbound SSO in Auth0 is handled by [connections](/connections).
+
+## Auth0 SSO sessions vs. Application sessions
+
+When users log in, various [session layers](/sessions/concepts/session-layers) can be created. For inbound SSO implementations, it's important to understand that the SSO experience is made possible by the Auth0 Session Layer, which is stored centrally on the Authorization Server. Leveraging this session layer, users can easily authenticate to different applications, each of which may have its own application session to track whether the user is logged into it specifically. 
+
+For an example of session usage with SSO, see [Example: Application Sessions and SSO Sessions Workflow](/sessions/references/example-short-lived-session-mgmt).
+
+## Build-Your-Own Implementations
+
+## OIDC/OAuth
+
+* [Social Identity Providers](/connections#social)
+* [Add a generic OAuth2 Authorization Server to Auth0](/connections/social/oauth2)
+* [Custom Social Connections Extension](/extensions/custom-social-extensions)
+
+## SAML
+
+* [SAML Identity Providers](/protocols/saml/identity-providers)
+* [Auth0 as Service Provider](/protocols/saml/saml-sp-generic)
+* [IdP-Initiated Single Sign-On](/protocols/saml/idp-initiated-sso)
+
+## Limitations
+
+* Native applications can only use [Universal Login](/universal-login).
+* [OpenID Connect (OIDC)](/protocols/oidc) does not support identity provider-initiated SSO.
\ No newline at end of file
diff --git a/fr-ca/articles/sso/current/index.md b/fr-ca/articles/sso/current/index.md
new file mode 100644
index 0000000000..5ca58fe4e8
--- /dev/null
+++ b/fr-ca/articles/sso/current/index.md
@@ -0,0 +1,115 @@
+---
+title: Single Sign-On
+description: Overview of what Single Sign-on (SSO) is and how it works.
+toc: true
+topics:
+  - sso
+  - authentication
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Single Sign-On
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on).
+
+For example, if you login to a Google service such as Gmail, you are automatically authenticated to YouTube, AdSense, Google Analytics, and other Google apps. Likewise, if you log out of your Gmail or other Google apps, you are automatically logged out of all the apps; this is known as Single Logout.
+
+## Benefits
+
+SSO provides a seamless experience for users when using your applications and services. Instead of having to remember separate sets of credentials for each application or service, users can simply login once and access your full suite of applications.
+
+## User experience
+
+Whenever users go to a domain that requires authentication, they are redirected to the authentication domain where they may be asked to log in. If the user is already logged in at the authentication domain, they can be immediately redirected to the original domain without signing in again.
+
+## How it works
+
+Single Sign-on and Single Logout are possible through the use of [sessions](/sessions). There may be up to three different sessions for a user with SSO:
+
+* Local session maintained by the application
+* Authorization Server session, if SSO is enabled
+* Identity Provider session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)
+
+With SSO, a central domain performs authentication and then shares the session with other domains. The way a session is shared may differ between SSO protocols, but the general concept is the same.
+
+For example, the authentication domain may generate a signed [JSON Web Token (JWT)](/tokens/concepts/jwts) (encrypted using JSON Web Encryption (JWE)), which contains all the information needed to identify the user for any other domain requiring authentication. This token is passed to the client, but because it is signed, it cannot be modified in any way by the client. The token can be passed to the original domain by a redirect and used by the authentication domain and any other domains to identify the user.
+
+## Protocols
+
+### Security Assertion Markup Language & Web Services Federation
+
+[Security Assertion Markup Language (SAML)](/protocols/saml) and [Web Services Federation (WS-Fed)](/protocols/ws-fed) are both protocols that are widely used in SSO implementations. Both SAML and WS-Fed exchange authorization and authentication data in XML format; the main parts of this exchange are the user, the identity provider, and the service provider.
+
+With SAML or WS-Fed:
+
+1. A user requests a resource from the service provider.
+2. The service provider checks with the identity provider to see if the user should have access to the resource. 
+3. The identity provider verifies the user's identity, and if valid, asserts back to the service provider that the user should have access.
+
+### OpenID Connect
+
+[OpenID Connect (OIDC)](/protocols/oidc) is an authentication protocol commonly used in consumer-facing SSO implementations. The OIDC protocol handles authentication through [JSON Web Tokens](/tokens/concepts/jwts) and a central identity provider.
+
+With OIDC:
+
+1. A user requests access to an application.
+2. The application redirects the user to the identity provider for authentication.
+3. The identity provider verifies the user, and if successful, prompts the user to grant data access to the application.
+4. If access is granted, the identity provider generates an ID Token, which contains user identity information that the application can consume. 
+5. The identity provider returns the user to the application.
+
+### Lightweight Directory Access Protocol + Active Directory
+
+[Lightweight Directory Access Protocol (LDAP)](/protocols/ldap) is an application protocol used to access a directory of credentials that can be shared by multiple applications; it is commonly used by intranets. When paired with Active Directory (AD), LDAP provides a centralized location for user identity, so the application makes an authentication request to the LDAP/AD server. The LDAP protocol exchanges information in LDAP Data Interchange Format (LDIF).
+
+## Inbound SSO
+
+For [inbound SSO](/sso/current/inbound), Auth0 is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application presents the user with one or more external identity providers.
+2. The user selects an identity provider to authenticate with and logs in.
+3. Upon successful authentication, the user is returned to the application.
+
+Inbound SSO in Auth0 is handled by [connections](/connections).
+
+## Outbound SSO
+
+For [outbound SSO](/sso/current/outbound), a third-party identity provider is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application redirects the user to an identity provider.
+2. The third-party identity provider performs authentication and authorization.
+3. Upon successful authentication, the user is returned to the application.
+
+### Auth0's SSO Dashboard Extension
+
+When planning an outbound SSO implementation, you may choose to use Auth0's [SSO Dashboard Extension](/extensions/sso-dashboard), which allows you to create a dashboard that lists multiple enterprise applications that can be enabled for SSO. This dashboard is then presented to your users to log in.
+
+## Use Cases
+
+For examples and implementation guides, check out our [Architecture Scenarios](/architecture-scenarios).
+
+### Business to Business
+
+For Business to Business (B2B) scenarios, SSO can simplify packaging your application for enterprise consumption. With Auth0 your applications can support common enterprise federation scenarios such as Active Directory, Lightweight Directory Access Protocol (LDAP), Ping, or Security Assertion Markup Language (SAML). This allows your partners and enterprise customers to login with their preferred enterprise identity technologies.
+
+* [Case Study: Safari](https://auth0.com/learn/safari-case-study/)
+
+### Business to Consumer / Customer Identity Access Management
+
+For Business to Consumer (B2C) or Customer Identity Access Management (CIAM) scenarios, SSO can provide frictionless access to your applications or services. You can let customers authenticate through popular social identity providers such as Google, Facebook, LinkedIn, Twitter, and Microsoft instead of requiring them to make another account.
+
+* [Case Study: Giving Compass](https://auth0.com/learn/giving-compass-case-study/)
+
+### Business to Employees
+
+For Business to Employees (B2E) scenarios, SSO can simplify the provisioning and management of employee credentials. Instead of keeping track of credentials for each and every service, employees can login once and gain access to everything they need. And if an employee leaves, deprovisioning a single account is much easier.
+
+* [Case Study: Schneider Electric](https://auth0.com/learn/schneider-electric-case-study/)
\ No newline at end of file
diff --git a/fr-ca/articles/sso/current/index_old.md b/fr-ca/articles/sso/current/index_old.md
new file mode 100644
index 0000000000..065b76fe02
--- /dev/null
+++ b/fr-ca/articles/sso/current/index_old.md
@@ -0,0 +1,43 @@
+---
+title: Single Sign-On and Single Logout
+description: Learn about Single Sign-on (SSO) and Single Logout
+classes: topic-page
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Single Sign-On and Single Logout
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on).
+
+Similarly, Single Logout occurs when you terminate the session of each application or service where a user is logged in. For more info, see [Logout](/logout).
+
+Single Sign-on and Single Logout are possible through the use of [sessions](/sessions). There may be up to three different layers of sessions for a user with SSO:
+
+* Local session maintained by the application
+* Authorization Server session, if SSO is enabled
+* Identity Provider session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)
+
+## Single Sign-on and Single Logout Example
+
+Google's implementation of login for their products, such as Gmail, YouTube, and Google Analytics, is an example of SSO. Any user that logs in to one of Google's products is automatically logged in to their other products as well.
+
+SSO usually makes use of a **Central Service** to orchestrate the single sign-on between multiple applications. For Google, this central service is [Google Accounts](https://accounts.google.com). When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services:
+
+1. The user accesses the first Google product, which redirects them to Google Accounts, where the user logs in and receives a Google Accounts-generated cookie.
+2. The user navigates to another Google product, which again redirects them to Google Accounts.
+3. Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product without requiring reauthentication.
+
+When the user logs out from one Google product, they are automatially also logged out from all other Google products.
+
+## Keep reading
+
+- [Understand how Single Sign-On works with Auth0](/sso/current/sso-auth0)
+- Learn how to [enable SSO in Auth0](/dashboard/guides/tenants/enable-sso-tenant)
+- [Understand session lifetime](/sessions/concepts/session-lifetime)
+- Learn how to [configure session lifetime settings](/dashboard/guides/tenants/configure-session-lifetime-settings)
+- Learn how to [log users out](/logout)
\ No newline at end of file
diff --git a/fr-ca/articles/sso/current/outbound.md b/fr-ca/articles/sso/current/outbound.md
new file mode 100644
index 0000000000..e2b83c2d38
--- /dev/null
+++ b/fr-ca/articles/sso/current/outbound.md
@@ -0,0 +1,55 @@
+---
+title: Outbound Single Sign-On
+description: Overview of Outbound Single Sign-on (SSO).
+toc: true
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Outbound Single Sign-On
+
+For outbound [Single Sign-On (SSO)](/sso), a third-party [Identity Provider (IdP)](/identityproviders) is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application redirects the user to an identity provider.
+2. The third-party identity provider performs authentication and authorization.
+3. Upon successful authentication, the user is returned to the application.
+
+## Pre-Defined Integrations
+
+Auth0 provides outbound [SSO Integrations](/integrations/sso) for the following services:
+
+- [Active Directory RMS](/integrations/sso/ad-rms)
+- [Box](/integrations/sso/box)
+- [CloudBees](/integrations/sso/cloudbees)
+- [Concur](/integrations/sso/concur)
+- [Disqus](/integrations/sso/disqus)
+- [Dropbox](/integrations/sso/dropbox)
+- [Microsoft Dynamics CRM](/integrations/sso/dynamics-crm)
+- [Adobe Echosign](/integrations/sso/echosign)
+- [Egnyte](/integrations/sso/egnyte)
+- [New Relic](/integrations/sso/new-relic)
+- [Office 365](/integrations/sso/office-365)
+- [Salesforce](/integrations/sso/salesforce)
+- [SharePoint](/integrations/sso/sharepoint)
+- [Slack](/integrations/sso/slack)
+- [SpringCM](/integrations/sso/springcm)
+- [Zendesk](/integrations/sso/zendesk)
+- [Zoom](/integrations/sso/zoom)
+
+## Build-Your-Own Implementations
+
+## SAML
+
+* [SAML Identity Provider Configuration](/protocols/saml/samlp)
+
+## OIDC
+
+* [Configure Okta as an OpenID Connect Identity Provider](/protocols/oidc/identity-providers/okta)
+
diff --git a/fr-ca/articles/sso/current/relevant-api-endpoints.md b/fr-ca/articles/sso/current/relevant-api-endpoints.md
new file mode 100644
index 0000000000..fb6e10f24f
--- /dev/null
+++ b/fr-ca/articles/sso/current/relevant-api-endpoints.md
@@ -0,0 +1,67 @@
+---
+title: Relevant API Endpoints for Single Sign-On
+description: Learn about Auth0 Authentication API and Management API endpoints that are relevant when implementing Single Sign-on (SSO).
+topics:
+    - sso
+    - api
+contentType: reference
+useCase: sso
+---
+# Relevant API Endpoints for Single Sign-On
+
+When implementing [Single Sign-on (SS0)](/sso) and configuring its settings, the following API endpoints will be helpful to you.
+
+## Authentication API
+
+### POST /login/callback
+
+For SSO flows initiated by an [Identity Provider (IdP)](/identityproviders), the [POST /login/callback](/api/authentication#idp-initiated-single-sign-on-sso-flow) endpoint can accept a sign-on SAML request from the IdP.
+
+## Management API
+
+The Management API features several endpoints designed to help you manage SSO.
+
+To call any of the Management API endpoints, you will need to [obtain an Access Token](/api/management/v2/tokens).
+
+### Clients
+
+All of your client applications/SSO integrations feature information relevant to your SSO implementation. You can retrieve or change this information by calling one of the Clients endpoints. 
+
+Of-interest parameters for each client include:
+
+* `sso`: Flag applicable only for clients created via SSO integrations. If `true`, Auth0 handles SSO; if `false`, the IdP handles SSO.
+
+* `sso_disabled`: Flag used to enable/disable SSO. If `true`, then SSO is disabled; if `false`, SSO is enabled. This option can only be set via the Management API.
+
+* `app_type`: Application type. If the client was created using one of Auth0's built-in SSO integrations, the name of the SSO integration would be listed (e.g., `box` or `concur` instead of `native` or `spa`)
+
+#### Get all clients
+
+The [GET /api/v2/clients](/api/management/v2#!/Clients/get_clients) endpoint can be used to return information about the client applications you have configured for your tenant.
+
+#### Create a client
+
+The [POST /api/v2/clients](/api/management/v2#!/Clients/post_clients) endpoint can be used to create a new client application.
+
+#### Get a client
+
+The [GET /api/v2/clients/{id}](/api/management/v2#!/Clients/get_clients_by_id) endpoint can be used to return information about a specific client you have configured for your tenant.
+
+#### Update a client
+
+The [PATCH /api/v2/clients/{id}](/api/management/v2#!/Clients/patch_clients_by_id) endpoint can be used to update a specific client, including its SSO-related parameters.
+
+### Tenants
+
+Auth0 allows you to control the following tenant-level parameters that may affect your SSO implementation:
+
+* `session_lifetime`: Length of time for which the user's Auth0 session will stay valid.
+* `idle_session_lifetime`: Amount of time that may elapse before the user must sign in again due to inactivity.
+
+### Get tenant settings
+
+The [GET /api/v2/tenants/settings](/api/management/v2#!/Tenants/get_settings) endpoint retrieves the settings for your tenant.
+
+### Update tenant settings
+
+The [POST /api/v2/connections](/api/management/v2#!/Tenants/patch_settings) endpoint allows you to update your tenant settings.
\ No newline at end of file
diff --git a/fr-ca/articles/sso/current/sso-auth0.md b/fr-ca/articles/sso/current/sso-auth0.md
new file mode 100644
index 0000000000..fa8aef4898
--- /dev/null
+++ b/fr-ca/articles/sso/current/sso-auth0.md
@@ -0,0 +1,50 @@
+---
+title: Single Sign-On with Auth0
+description: Learn how Single Sign-on (SSO) works with Auth0.
+toc: true
+topics:
+  - sso
+contentType:
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Single Sign-On with Auth0
+
+The easiest and most secure way to implement Single Sign-on (SSO) with Auth0 is by using [Universal Login](/universal-login) for authentication. In fact, currently SSO is only possible with native platforms (like iOS or Android) if the application uses Universal Login. The [Swift](/quickstart/native/ios-swift/00-login) and [Android](/quickstart/native/android/00-login) quickstarts provide some examples of using Universal Login.
+
+If you cannot use Universal Login with your application, review the following for additional info on embedded authentication:
+
+* [Lock](/libraries/lock)
+* [Auth0.js](/libraries/auth0js)
+
+## SSO on first login
+
+For SSO with Auth0, the **Central Service** is the Auth0 Authorization Server.
+
+Let's look at an example of the SSO flow when a user logs in for the first time:
+
+1. Your application redirects the user to the login page.
+2. Auth0 checks to see whether there is an existing SSO cookie.
+3. Because this is the first time the user is visiting the login page and no SSO cookie is present, the user will be asked to log in using one of the [connections](/connections) you have configured.
+
+![](/media/articles/sso/single-sign-on/lock-no-sso-cookie.png)
+
+4. Once the user has logged in, Auth0 will set an SSO cookie and redirect the user to your application, returning an ID Token that contains identity information for the user.
+
+## SSO on subsequent logins
+
+Let's look at an example of the SSO flow when a user returns to your website for a subsequent visit:
+
+1. Your application redirects the user to the login page.
+2. Auth0 checks to see whether there is an existing SSO cookie.
+3. Auth0 finds the SSO cookie, and if necessary, updates it. No login screen is shown.
+4. Auth0 redirects the user to your application, returning an ID Token that contains identity information for the user.
+
+## Check a user's SSO status 
+
+You can check a user's SSO status from an application by calling the `checkSession` method of the `auth0.js` SDK, which will attempt to [silently authenticate](/api-auth/tutorials/silent-authentication) the user within an iframe. Whether the authentication is successful or not indicates whether the user has an active SSO [cookie](/sessions/concepts/cookies).
+
+## Keep reading
+
+- Learn how to [enable SSO in Auth0](/dashboard/guides/tenants/enable-sso-tenant).
\ No newline at end of file
diff --git a/fr-ca/articles/sso/index.yml b/fr-ca/articles/sso/index.yml
new file mode 100644
index 0000000000..3fc1f73b02
--- /dev/null
+++ b/fr-ca/articles/sso/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: sso
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/fr-ca/articles/sso/legacy/index.md b/fr-ca/articles/sso/legacy/index.md
new file mode 100644
index 0000000000..8283021d59
--- /dev/null
+++ b/fr-ca/articles/sso/legacy/index.md
@@ -0,0 +1,107 @@
+---
+toc: true
+description: Introduction to Single Sign-on (SSO) with Auth0.
+topics:
+  - sso
+contentType:
+  - index
+useCase:
+  - integrate-saas-sso
+---
+# What is Single Sign-On?
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time hence the naming of the feature (Single Sign-on).
+
+Google's implementation of login for their products, such as Gmail, YouTube, Google Analytics, and so on, is an example of SSO. Any user that is logged in to one of Google's products are automatically logged in to their other products as well.
+
+SSO usually makes use of a *Central Service* which orchestrates the single sign-on between multiple applications. In the example of Google, this central service is [Google Accounts](https://accounts.google.com). When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services. The process flow is as follows:
+
+1. The user accesses the first Google product.
+2. The user receives a Google Accounts-generated cookie.
+3. The user navigates to another Google product.
+4. The user is redirected again to Google Accounts.
+5. Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
+
+## An overview of how SSO works with Auth0
+
+In the case of SSO with Auth0, the *Central Service* is the Auth0 Authorization Server.
+
+Let's look at how the SSO flow looks when using Auth0 and a user visits your application for the first time:
+
+1. Your application will redirect the user to the Auth0 Hosted Lock page where they can log in.
+2. Auth0 will check to see whether there is an existing SSO cookie.
+3. Because this is the first time the user visits this Hosted Lock page, and no SSO cookie is present, they may be presented with username and password fields and also possibly some Social Identity Providers such as LinkedIn, GitHub, and so on (The exact layout of the Lock screen will depend on the [Identity Providers](/identityproviders) you have configured.
+
+    ![](/media/articles/sso/single-sign-on/lock-no-sso-cookie.png)
+
+4. Once the user has logged in, Auth0 will set an SSO cookie
+5. Auth0 will also redirect back to your web application and will return an ID Token containing the identity of the user.
+
+Now let's look at flow when the user returns to your website for a subsequent visit:
+
+1. Your application will redirect the user to the Auth0 Hosted Lock page where they can sign in.
+2. Auth0 will check to see whether there is an existing SSO cookie.
+3. This time Auth0 finds an SSO cookie and instead of displaying the normal Lock screen with the username and password fields, it will display a Lock screen which indicates that we know you the user is, as they have already logged in before. They can simply confirm that they want to log in with that same account.
+
+    ![](/media/articles/sso/single-sign-on/lock-sso-cookie.png)
+
+4. Auth0 will update the SSO cookie if required
+5. Auth0 will also redirect back to your web application and will return an ID Token containing the identity of the user.
+
+If an SSO cookie is present you can also sign the user in silently, that is, without even displaying Lock so they can enter their credentials. This is covered in more detail in the next section.
+
+## How to Implement SSO with Auth0
+
+::: note
+Prior to enabling SSO for a given Application, you must first [configure the Identity Provider(s)](/identityproviders) you want to use.
+:::
+
+To configure SSO for one of your Applications (recall that each Application is independent of one another), navigate to the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications). Click on **Settings** (represented by the gear icon) for the Application with which you want to use SSO.
+
+![](/media/articles/sso/single-sign-on/clients-dashboard.png)
+
+Near the bottom of the *Settings* page, toggle **Use Auth0 instead of the IdP to do Single Sign-on**.
+
+![](/media/articles/sso/single-sign-on/sso-flag.png)
+
+Alternatively you can also set the Application's SSO flag using the [Auth0 Management API](/api/management/v2#!/Clients/patch_clients_by_id).
+
+Once you have set the SSO flag for your Application in the Auth0 Dashboard, you must add logic to your application to check the user's SSO status. Checking the user's SSO status can only be done via JavaScript by making use of the [`getSSOData`](/libraries/auth0js#sso) function in the [auth0.js library](/libraries/auth0js).
+
+The result of this function will indicate whether an SSO cookie is present, and if so it will return the SSO data of the user which can then subsequently be used to log the user in silently without even displaying Lock.
+
+For more detailed information on how to implement this, please refer to the following documents:
+
+* [Client-Side SSO (Single-Page Apps)](/sso/legacy/single-page-apps-sso)
+* [Server-Side SSO (Regular Web Apps)](/sso/legacy/regular-web-apps-sso)
+
+::: note
+Please see the [Auth0 SSO Sample](https://github.com/auth0/auth0-sso-sample) repo for an example of SSO with both Single-Page Apps and Regular Web Apps.
+:::
+
+### Length of SSO Sessions
+
+If the SSO flag is set for an application, Auth0 will maintain an SSO session for any user authenticating via that Application. If the user remains active, the session will last no more than **7 days**, but if not, the session will terminate after **3 days**. To be considered active, the user must access the Application that created the session within the given timeframe.
+
+## What is Single Logout?
+
+Single Logout is the process where you terminate the session of each application or service where the user is logged in. To continue with the Google example, if you logout from Gmail, you get logged out also from YouTube, Google Analytics, and so on.
+
+There may be up to three different layers of sessions for a user with SSO.
+
+* A session from an Identity Provider such as Google, Facebook or an enterprise SAML Identity Provider
+* A session from Auth0 if the above SSO flag is turned on
+* A session maintained by an application
+
+See the [Logout URL docs](/logout) for information on terminating the first two sessions listed above.
+
+## Using Social Identity Providers
+
+SSO works with Social Identity Providers given the following conditions:
+
+1. You need to enable "Use Auth0 instead of the IdP to do Single Sign-on" when configuring the Application
+2. Your social connection can not be using the developer keys. You will need to register an app in the relevant social provider and then use that Client ID and Client Secret when configuring the connection. You can read more about the [caveats of using the Auth0 developer keys](/connections/social/devkeys#caveats).
diff --git a/fr-ca/articles/sso/legacy/regular-web-apps-sso.md b/fr-ca/articles/sso/legacy/regular-web-apps-sso.md
new file mode 100644
index 0000000000..3f8fc043fc
--- /dev/null
+++ b/fr-ca/articles/sso/legacy/regular-web-apps-sso.md
@@ -0,0 +1,123 @@
+---
+toc: true
+description: Server-side Single Sign-on (SSO) with regular web applications.
+topics:
+  - sso
+  - web-apps
+contentType:
+  - how-to
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Server-side Single Sign-On (Regular Web Apps)
+
+To log a user in silently (that is, without displaying the Lock screen) the following conditions need to be met:
+
+1. The Application needs to be configured to **Use Auth0 instead of the IdP to do Single Sign-on** in the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications)
+2. A Single Sign-on (SSO) cookie must exist for the tenant's domain. In other words the user must have signed in previously, and the SSO cookie which was saved is still valid.
+3. When calling the Auth0 authentication endpoint, the connection name is passed along for which the user must be signed in. This connection name is the same as the one specified in the SSO cookie. You can pass the connection name along either as a parameter when calling the `signin` function of the [**auth0.js** Library](https://auth0.com/docs/libraries/auth0js), or by passing the `connection` query string parameter when calling the `/authorize` endpoint of the [Authentication API](/api/authentication)
+
+## The SSO scenario
+
+In our SSO scenario, let's say we have 3 applications
+
+* App 1: app1.com (Single-Page App)
+* App 2: app2.com (Single-Page App)
+* App 3: app3.com (Regular Web app)
+
+If a user logs in to any of these applications, and then subsequently navigates from this application to any of the other applications, we would want the user to be logged in automatically.
+
+In this document we will be looking specifically how to achieve this in a Regular Web Application
+
+## Case 1: The user is already logged in and clicks on a link that redirects to a specific URL app3.com
+
+The user logs in on one of the Single-Page Applications and click on a link that should take them to a particular URL on app3.com. In this case, you can create an endpoint on the target application (app3) that will redirect to the URL the user wanted to go after SSO. For example:
+
+```text
+https://app3.com/sso?targetUrl=/foo/bar&connection=CONNECTION_NAME
+```
+
+This endpoint would check if the user is already logged in to this app. If they are, then redirect to the target URL. If the user is not logged in to the application, then redirect to Auth0 for SSO, passing along the name of the connection to use:
+
+```text
+handle("/sso")
+  if (user is already logged in)
+    redirect to targetUrl
+  else
+    redirect to "https://${account.namespace}/authorize?client_id=${account.clientId}&connection=CONNECTION_NAME&redirect_uri=${account.callback}&response_type=code&state=' + targetUrl
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/sso', function(req,res, next) {
+  if (req.isAuthenticated()) {
+    if (/^http/.test(req.query.targetUrl)) return res.send(400, "url must be relative");
+    // Here we'd redirect to req.query.targetUrl like following
+    // res.redirect(req.query.targetUrl);
+    // But in this case we'll go to User anyway
+    res.redirect('/user?targetUrl=' + req.query.targetUrl);
+  } else {
+    console.log("Authenticating with Auth0 for SSO");
+    passport.authenticate('auth0', {
+      state: req.query.targetUrl,
+      connection: req.query.connection
+    })(req, res, next);
+  }
+});
+```
+
+When the user comes back from Auth0 you should check for the `state` parameter and redirect to the original target URL.
+
+```js
+handle("/callback")
+  // process login with SDK
+  if (state) redirect to url on state parameter
+  else redirect to base logged in URL
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/callback',
+    passport.authenticate('auth0'),
+    function(req, res) {
+      if (req.query.state) {
+        res.redirect(req.query.state);
+      } else {
+        res.redirect("/user");
+      }
+    });
+```
+
+## Case 2: The user is already logged in and goes to app3.com
+
+The user is logged in on app1.com and opens a new tab and goes to app3.com. You would expect the user to be automatically signed in. To do that, you need to redirect the user to the following URL in a filter or a middleware:
+
+```text
+https://${account.namespace}/authorize?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/',
+    // This redirects to https://YOURS.auth0.com....
+    passport.authenticate('auth0', {}),
+    function(req, res) {
+      // Once user is logged in, redirect to the user page
+      res.redirect('/user');
+    });
+```
+
+If the user was already logged in before, then Auth0 will automatically redirect back to the application with a new token. If not, then it will show the Auth0 Login Page.
+
+## Case 3: The user has never logged in
+
+The user has never logged in to any app. In this case, the filter or middleware mentioned in the previous point checks if the user is authenticated or not, and in the case they're not, redirects the user to the following URL:
+
+```text
+https://${account.namespace}/authorize?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}
+```
diff --git a/fr-ca/articles/sso/legacy/single-page-apps.md b/fr-ca/articles/sso/legacy/single-page-apps.md
new file mode 100644
index 0000000000..e726c4d78a
--- /dev/null
+++ b/fr-ca/articles/sso/legacy/single-page-apps.md
@@ -0,0 +1,189 @@
+---
+description: Client-side Single Sign-on (SSO) with single-page applications.
+toc: true
+topics:
+  - sso
+  - spas
+contentType:
+  - how-to
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Client-side Single Sign-On (Single-Page Apps)
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+To log a user in silently (that is, without displaying the Lock screen) the following conditions need to be met:
+
+1. The Application needs to be configured to **Use Auth0 instead of the IdP to do Single Sign-on** in the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications)
+2. A Single Sign-on (SSO) cookie must exist for the tenant's domain. In other words the user must have signed in previously, and the SSO cookie which was saved is still valid.
+3. When calling the Auth0 authentication endpoint, the connection name is passed along for which the user must be signed in. This connection name is the same as the one specified in the SSO cookie. You can pass the connection name along either as a parameter when calling the `signin` function of the [**auth0.js** Library](/libraries/auth0js), or by passing the `connection` query string parameter when calling the `/authorize` endpoint of the [Authentication API](/api/authentication)
+
+## The SSO scenario
+
+In our SSO scenario, let's say we have 3 applications
+
+* App 1: app1.com (Single-Page App)
+* App 2: app2.com (Single-Page App)
+* App 3: app3.com (Regular Web app)
+
+If a user logs in to any of these applications, and then subsequently navigates from this application to any of the other applications, we would want the user to be logged in automatically.
+
+In this document we will be looking specifically how to achieve this in a Single-Page (JavaScript) Application
+
+## Obtaining the SSO cookie information  
+
+If a users logs in to any of the applications and then subsequently tries to log in to any of the other applications, you can check to see whether an SSO session is active for that user by making use of the `getSSOData` function in the [auth0.js library](/libraries/auth0js#sso).
+
+```js
+auth0.getSSOData(function (err, ssoData) {
+  if (err) return console.log(err.message);
+  expect(ssoData.sso).to.exist;
+});
+```
+
+This function will return an `ssoData` object which will indicate whether an active SSO session exist. The `ssoData` object will contain the fields as per the following example:
+
+```json
+{
+  sso: true,
+  sessionClients: [
+    "jGMow0KO3WDJELW8XIxolqb1XIitjkYL"
+  ],
+  lastUsedClientID: "jGMow0KO3WDJELW8XIxolqb1XIitjkYL",
+  lastUsedUsername: "alice@example.com",
+  lastUsedConnection: {
+    name: "Username-Password-Authentication",
+    strategy: "auth0"
+  }
+}
+```
+
+## Passing the Connection Name when logging the user in
+
+You can then use this information to call the `signin` function to log the user in. When you call the `signin` function you pass along the name of the connection used in the active SSO session as the `connection` parameter. Auth0 will determine that an SSO cookie is saved for that connection, and will log the user directly without displaying the Lock user interface.
+
+
+```js
+auth0.getSSOData(function (err, ssoData) {
+  if (!err && ssoData.sso) {
+    auth0.signin({
+      connection: ssoData.lastUsedConnection.name,
+      scope: 'openid name picture',
+      state: getQueryParameter('targetUrl')
+    });
+  } else {
+    // Display regular login option, such as a Login button which will invoke Lock
+  }
+});
+```
+
+## Full SSO Sample Code
+
+Below is an expanded code sample of how you can implement this in a SPA application using jQuery to either show or hide the Login button or user information depending on whether a user is logged in or not.
+
+The full code sample for both the SPA applications as well as the normal web application can be found in [this github repository](https://github.com/auth0/auth0-sso-sample/tree/master/app1.com)
+
+```html
+
+
+
+
+  
+
+```
+
+## Single Logout
+
+If the user logged out from app1.com, then we want to clean up the token on app2.com (and app3.com). Read more about [Single Logout](/logout).
+
+To do that, you have to check every X amount of time whether the SSO session is still alive in Auth0. If it is not, then remove the token from Local Storage for the application. This will ensure that the user's local session is cleared.
+
+```js
+setInterval(function() {
+  // if the token is not in local storage, there is nothing to check (that is, the user is already logged out)
+  if (!localStorage.getItem('userToken')) return;
+
+  auth0.getSSOData(function (err, data) {
+    // if there is still a session, do nothing
+    if (err || (data && data.sso)) return;
+
+    // if we get here, it means there is no session on Auth0,
+    // then remove the token and redirect to #login
+    localStorage.removeItem('userToken');
+    window.location.href = '#login'
+
+  });
+}, 5000)
+```
diff --git a/fr-ca/articles/support/_delete-tenant.md b/fr-ca/articles/support/_delete-tenant.md
new file mode 100644
index 0000000000..339c60adc2
--- /dev/null
+++ b/fr-ca/articles/support/_delete-tenant.md
@@ -0,0 +1,21 @@
+## Delete tenants
+
+This process deletes only one tenant. If you have other tenants that need to be removed, you will need to repeat these steps for each tenant. If you are an [enterprise customer](#for-enterprise-customers) or have a [paid subscription](#for-paid-subscription-customers), please review our caveats before proceeding.
+
+::: warning
+You **cannot** restore a deleted tenant and you cannot reuse a tenant name when creating new tenants.
+:::
+
+1. Log in to the [Dashboard](${manage_url}).
+2. Click on your username in the top right corner to display the dropdown box.
+3. Select **Settings** to open the **Tenant Settings** page.
+4. On the **Tenant Settings** page, select the **Advanced** tab.
+5. Scroll down to the **Danger Zone** at the bottom of the page, and click **Delete**.
+
+### For enterprise customers
+
+If you are an Enterprise customer, you may have multiple child tenants as part of your Auth0 contract. While it is not possible to delete the main tenant from the dashboard (you will need to contact support for that), the child tenants can be deleted at any time. Rest assured that if you choose to delete a child tenant, this will have no impact on your agreement with Auth0. We recommend speaking with your Technical Account Manager if you have any concerns about your Enterprise agreement.
+
+### For paid subscription customers
+
+If you have a paid subscription with one or more child tenants, deleting the main subscription is not possible from the Dashboard. Please contact support for that. It is possible to delete child tenants from the Dashboard, and deleting such tenants should have no impact on your subscription plan. This is because activity and usage on child tenants counts toward the main tenant's activity and usage limitations.
diff --git a/fr-ca/articles/support/_reset-tenant.md b/fr-ca/articles/support/_reset-tenant.md
new file mode 100644
index 0000000000..f055220c71
--- /dev/null
+++ b/fr-ca/articles/support/_reset-tenant.md
@@ -0,0 +1,11 @@
+## Reset tenants
+
+To reset your tenant to its initial state, you can use the [Deploy CLI Tool](/extensions/deploy-cli). This creates a "clean" environment for development or test purposes and removes unwanted items.
+
+1. Install the tool `a0deploy` by running the following in your command-line interface: `npm i -g auth0-deploy-cli`
+
+2. Get a snapshot of the state you would like to preserve: `a0deploy export --config_file config.json --format yaml --output_folder ./`
+
+3. [Update the configuration file](/extensions/deploy-cli/guides/import-export-yaml-file#import-tenant-configuration) used for the import.
+
+4. Update your tenant with its stored state: `a0deploy import --config_file config.json --format yaml --input_file ./tenant.yaml`
\ No newline at end of file
diff --git a/fr-ca/articles/support/cancel-paid-subscriptions.md b/fr-ca/articles/support/cancel-paid-subscriptions.md
new file mode 100644
index 0000000000..df35bb82d8
--- /dev/null
+++ b/fr-ca/articles/support/cancel-paid-subscriptions.md
@@ -0,0 +1,40 @@
+---
+description: To cancel your Auth0 subscription, you can downgrade to a free subscription or delete your tenant.
+crews: crew-2
+topics:
+    - support
+    - subscriptions
+    - cancellation
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Cancel Your Auth0 Subscription
+
+If you wish to cancel your Auth0 subscription, you should:
+
+1. [Downgrade](#downgrade-a-paid-subscription-to-a-free-subscription) a paid subscription to a free subscription
+2. [Delete](#delete-your-auth0-tenant) your Auth0 tenant
+
+## Downgrade to a free subscription
+
+1. Log in to the [dashboard](${manage_url}).
+2. Click on your tenant name in the top right corner to display the  dropdown box.
+
+![](/media/articles/subscriptions/dashboard.png)
+
+3. Select **Settings** to open the **Tenant Settings** page.
+4. On the **Tenant Settings** page, click on the **Subscription** tab.
+
+![](/media/articles/subscriptions/subscription.png)
+
+5. On the **Subscription** tab, scroll down to the box associated with the **Free** plan and click **Checkout**.
+
+![](/media/articles/subscriptions/free-subscription.png)
+
+6. To confirm your subscription change, click **Subscribe Now**.
+
+<%= include('./_delete-tenant') %>
diff --git a/fr-ca/articles/support/delete-reset-tenant.md b/fr-ca/articles/support/delete-reset-tenant.md
new file mode 100644
index 0000000000..5b89c4de31
--- /dev/null
+++ b/fr-ca/articles/support/delete-reset-tenant.md
@@ -0,0 +1,35 @@
+---
+description: How to delete or reset your tenant
+topics:
+    - support
+    - delete-tenant
+    - reset-tenant
+    - tenants
+contentType:
+  - how-to
+useCase:
+  - support
+---
+
+# Delete or Reset Tenants
+
+::: warning
+If you are using custom domains, when deleting a tenant, first delete the custom domain. If you delete the tenant before removing the custom domain, you will not be able to reuse your custom domain elsewhere.
+:::
+
+If you want to completely remove an unwanted tenant, we recommend deleting it. This option is useful if you have created a test or demo tenant that you won't be using again, so you don't care about keeping your tenant name.
+
+If you want to keep using your tenant name, we recommend resetting your tenant by using the **Deploy CLI Tool** to remove any unwanted items. This will return your tenant to its initial state and retain your tenant name.
+
+<%= include('./_delete-tenant') %>
+
+<%= include('./_reset-tenant') %>
+
+## Keep reading
+
+* If you've deleted your tenant, and you require the use of a particular domain name, we recommend configuring a [custom domain name](/custom-domains) for your new tenant.
+* [Cancel Your Auth0 Subscription](/support/cancel-paid-subscriptions) to downgrade to a free account.
+* [Change or Upgrade Your Auth0 Subscription](/support/subscription)
+* [Update a Tenant Admin](/dashboard/manage-dashboard-admins#update-admin) to change ownership of the tenant.
+* [Export Data Out of Auth0](/support/removing-auth0-exporting-data)
+* [Reset Your Auth0 Account Password](/support/reset-account-password)
diff --git a/fr-ca/articles/support/how-auth0-versions-software.md b/fr-ca/articles/support/how-auth0-versions-software.md
new file mode 100644
index 0000000000..0d3109b493
--- /dev/null
+++ b/fr-ca/articles/support/how-auth0-versions-software.md
@@ -0,0 +1,50 @@
+---
+title: How Auth0 versioning works
+description: Understand how Auth0 versioning works.
+topics:
+    - support
+    - auth0-versioning
+    - versioning
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Versioning
+
+We believe versioning is a crucial part of our offering. By providing a consistent versioning scheme for our products we are able to help our users manage and predict how our changes will impact usage.
+
+## Semantic versioning
+
+::: note
+This scheme is used in Auth0 Lock, [Auth0 AD Connector](https://github.com/auth0/ad-ldap-connector), [Auth0.js](https://github.com/auth0/auth0.js) and SDKs.
+:::
+
+[Semantic versioning](http://semver.org) (also known as semver) is a versioning strategy whose main feature is making breaking changes discoverable. A version is composed of 3 numbers separated by dots: `{major}.{minor}.{patch}`. For instance, `2.12.5`, `0.1.0` and `10.5.35` are valid semver numbers. 
+
+- The first number represents a **major change**: **the library API has changed in a non-backwards compatible way**. When the major part of a version is bumped, the public API of that library has changed. For example, code and functionality previously marked as deprecated is removed from the code base.
+- The second number represents a **minor change**: **the library API has new functionality added or marked as deprecated while keeping backward compatibility**. The new minor version is expected to be safe for use and we encourage customers to update. However, as it is impossible to know every way customers use a component, there is always a chance that changes might have impact on the current usage of the component. Therefore, we recommend verifying and testing before performing an update.
+- The third number, represents **a patch change**: **A bug has been fixed and should not have any impact on the user facing API**. This should be safe to update but testing is always encouraged.
+
+More information about this versioning scheme can be found at [semver](http://semver.org)
+
+### Production usage
+
+Auth0 provides links to our [Content Delivery Network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) where we serve some of our libraries. The way you reference a component in your code will impact whether and when you automatically pick up changes.  For instance, if you link to the major release from within a script, and there is a new minor, you will get the update as soon as it is released. We encourage this practice for development environments and experimenting with Auth0. Here are examples of embedding the source files:
+
+```js
+
+
+
+
+
+
+
+
+```
+
+**When Auth0 components are deployed to production, we encourage our users to anchor to a full version and thoroughly test using that version**. Although adding new features in a backwards compatible way shouldn’t break your code, the interactions with the component outcome could be hard to predict.  Even trivial bug fixes may introduce changes in the assumptions you were making about the component which may no longer be true.
+
+::: note
+Each Auth0 open source component that follows semver will have a tag matching a released version in its git repository. As some of the projects use [npm](https://npmjs.com) tooling to release versions the tags will have a `v` letter as a prefix. For instance, version `5.2.3` tag will be `v5.2.3`.
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/support/index.md b/fr-ca/articles/support/index.md
new file mode 100644
index 0000000000..d579b97fee
--- /dev/null
+++ b/fr-ca/articles/support/index.md
@@ -0,0 +1,208 @@
+---
+url: /support
+toc: true
+description: Explains the different types of support options provided by Auth0.
+topics:
+    - support
+contentType:
+  - index
+useCase:
+  - support
+---
+# Support Options
+
+The following page contains information about the Auth0 support program.
+
+## Support Options Overview
+
+Auth0 offers the following support plans:
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Community SupportCustomers with Auth0's free subscription plan can seek support through the Auth0 Community.
    Standard SupportFor customers with a paid (non-Enterprise) subscription plan or those in the initial trial period.
    Enterprise SupportFor customers with an Enterprise subscription plan.
    Premier SupportFor customers with an Enterprise subscription plan that have added the Premier Support option.
    Preferred SupportFor customers with an Enterprise subscription plan that have added the Preferred Support option. This offering is no longer for sale.
    
+
+### Community Support
+
+Customers with Auth0's free community subscription plan can seek support through the [Auth0 Community](${auth0_community}). Response times may vary and are not guaranteed.
+
+If you have a free account and your account has been compromised, please post in Community and reach out to us via DM on [Twitter](https://twitter.com/auth0community).
+
+:::panel Trial Subscriptions
+New Auth0 customers receive Standard Support during the 22-day trial period (customers may check on how many trial days they have left by logging into the [Dashboard](${manage_url})).
+
+At the end of the trial period, customers who have not opted to purchase a paid subscription can use the [Auth0 Community](${auth0_community}) for assistance. They will no longer be able to access or open tickets in the [Support Center](https://support.auth0.com/).
+:::
+
+### Standard Support
+
+Customers with a paid Auth0 subscription plan receive Standard Support, which offers access to the following channels:
+
+* Auth0 Community;
+* Auth0 Support Center.
+
+The Auth0 Support Center offers ticketed support, where support specialists are available to provide assistance.
+
+### Enterprise Support (with or without Premier Support)
+
+Customers with an Enterprise Subscription Plan receive extended support hours for outages, quicker response times, and access to the Customer Success Team.
+
+## Support Channels
+
+Auth0 offers the following support channels.
+
+### Auth0 Community
+
+Auth0's public [question and answer community](${auth0_community}) offers support for __all__ subscribers. All customers, even those on free tenants, can search through existing questions and post a new question if theirs hasn't been answered. There are no guaranteed response times for questions posted.
+
+### Support Center
+
+In addition to the Auth0 Community, paid subscribers can create a private ticket via [Support Center](${env.DOMAIN_URL_SUPPORT}). All tenant administrators will be able to view and add comments to Support Center tickets. Support Center can be accessed by clicking on the **Get Support** link on the [dashboard](${manage_url}).
+
+[Learn more about creating tickets with Support Center](/support/tickets)
+
+Critical Production issues should always be reported via the [Support Center](https://support.auth0.com/) for fastest response.
+
+#### Add Support-Only Users
+
+You can add support-only users to your Auth0 tenant. This will allow them to open, view, and comment on [Support Center](${env.DOMAIN_URL_SUPPORT}) tickets, receive relevant notifications, and see service details.  They do not, however, have full administration access to the [Auth0 Dashboard](${manage_url}).
+
+To add one or more support-only users, go to [Support Center](${env.DOMAIN_URL_SUPPORT}). Click on your name in the top right, and click **Invite Users to Support Center**. Note that only tenant administrators with `All Applications` access can add Support-Only users.
+
+![](/media/articles/support/support-center-users.png)
+
+If this is the first time you've used this feature or there are no support-only users, you'll be redirected immediately to a screen that allows you to invite users.
+
+![](/media/articles/support/invite-users.png)
+
+Provide the user's email address, select the Auth0 service to which they should have support access, and click **Send Invitation**. Auth0 will then send the user an email inviting them to register for and log into the Support Center.
+
+Administrative accounts will be able to see details about support-only accounts.
+
+![](/media/articles/support/manage-users.png)
+
+Using this page, you can:
+
+* Search for users;
+* See the account details for users;
+* Revoke privileges.
+
+## Program Features
+
+Your Sales Order will indicate whether you are subscribed to the **Standard** Support Program, **Enterprise** Support Program, or **Premier** Support Program.
+
+The following features are provided with **every** support plan:
+
+- Answer questions concerning usage issues related to Auth0 Platform specific features, options and configurations
+- Provide initial and high-level suggestions regarding the appropriate usage, features, or solution configurations for the particular type of reporting, analysis, or functionality
+- Isolate, document, and find alternative solutions for reported Defects
+- Work with Auth0 Operations, Product, Software Development, and QA staff to submit Change Requests, Enhancement Requests, and provide Fixes for the Auth0 Platform as necessary
+- Address your concerns with online or printed documentation, providing additional examples or explanation for concepts requiring clarification
+- Access to online release notes for Updates
+- Access to Auth0’s online library of Support webinars and knowledgebase
+- Access to Auth0’s Customer Community forums to collaborate with fellow Auth0 customers
+
+The following table describes feature differences of each Auth0 support plan:
+
+| Support Feature | Standard | Enterprise | Preferred | Premier |
+| - | - | - | - | - |
+| Enhanced Response Times | No | Yes | Yes | Yes |
+| Enhanced Hours of Support | No | Yes | Yes | Yes |
+| Ticket Review | No | No | Yes | Yes |
+| Phone Support | No | No | No | Yes |
+| Designated team of Developer Support Engineers | No | No | No | Yes |
+
+## Defect Resolution Procedures
+
+Auth0 will assign all Defects one of four response priorities, dependent upon the problems caused by the Defect. Auth0 may re-assign prioritization levels assigned by you in Auth0’s trouble ticketing system, to reflect the problem descriptions below. Auth0’s assignment will be consistent with the problem descriptions described below. Priority categories are as follows:
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Severity LevelDescription
    1 (Urgent)Emergency Issue. Defect resulting in full or partial system outage or a condition that makes the Auth0 Platform unusable or unavailable in production for all of your Users.
    2 (High)Significant Business Impact. Defect resulting in a condition where major functionality is impacted or significant performance degradation is experienced; issue is persistent and affects many Users and/or major functionality.
    3 (Normal)Minor Feature / Function Issue / General Question. Defect results in a component of the Auth0 Platform not performing as expected or documented or an inquiry by your representatives regarding general technical issues/questions
    4 (Low)Minor Problem / Enhancement Request. Information requested on Auth0 Platform capabilities, navigation, installation, or configuration; enhancement request.
    
+
+### Defect Responses
+
+The priority of a Defect will dictate the timing and nature of the response as specified in the table below:
+
+| Defect Severity Level & Business Impact | Standard Target Response Time | Enterprise Target Response Time | Preferred Target Response Time (no longer for sale) | Premier Target Response Time | Solution Definition (one or more of the following) |
+| --- | --- | --- | --- | --- | -- |
+| **1 (Urgent)**
    Emergency Issue | 1 business hour
    24x7x365 | 30 minutes
    24x7x365 | 30 minutes
    24x7x365 | 30 minutes
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix is provided.
      •  
    • Fix incorporated into future release.
     |
+| **2 (High)**
    Significant Business Impact | 4 business hours
    6AM to 6PM, Mon to Fri (local time) | 2 hours
    24 hours a day, Mon to Fri (local time) | 1 hour
    24 hours a day, Mon to Fri (local time) | 1 hour
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix is provided.
      •  
    • Fix incorporated into future release.
     |
+| **3 (Normal)**
    Minor Feature / Function Issue, General Question | 1 business day
    6AM to 6PM, Mon to Fri (local time) | 12 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix incorporated into future release.
      •  
    • Answer to question is provided.
     |
+| **4 (Low)**
    Minor Problem, Enhancement Request | 2 business days
    6AM to 6PM, Mon to Fri (local time) | 24 hours
    24 hours a day, Mon to Fri (local time) | 12 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24x7x365 | 
    • Answer to question is provided.
      •  
    • Enhancement request logged.
     |
+
+## Program Hours
+
+Auth0 will provide support for Severity Level 1 Defects on a 24x7x365 basis.
+
+For all other defects, Auth0 will provide support during the hours specified below:
+
+| Standard | Enterprise/Preferred | Premier |
+| - | - | - |
+| 6AM to 6PM (your local time) Monday to Friday | 24 hours a day, Monday to Friday (your local time) | 24 hours a day, 7 days a week, 365 days a year |
+
+## Support Languages
+
+We provide all technical support in English, but we will make an effort to accommodate other languages if possible.
+
+## Upgrades
+
+During the Subscription Term, Auth0 will provide or install Updates if and when they are made generally commercially available by Auth0 to its customers, at no additional cost to you.
+
+## Pricing
+
+For pricing information on Auth0's subscription plans, please see [Pricing Page](https://auth0.com/pricing) or your [Tenant Settings](${manage_url}/#/tenant/billing/subscription).
+
+## Auth0 Status
+The [Auth0 status page](https://status.auth0.com) contains information on current production status and will be updated during an outage.  After an outage, a root-cause analysis is performed and made available via the page.
+
+Please check the [status page](https://status.auth0.com) before filing a ticket.  If the status page contains a notification about an outage, our team will already be working on restoring service as quickly as possible.  Once the issue is resolved, the status page will be updated to reflect that.  There is a button on the page to subscribe to notifications of any changes.  A root-cause analysis will be published to the status page once an investigation has been done.
+
+## Whitehat Support Tickets
+
+All customers, even those with free subscription plans, may report security concerns via [Auth0 Whitehat](https://auth0.com/whitehat).
+
+[Additional Details](https://auth0.com/legal)
diff --git a/fr-ca/articles/support/matrix.md b/fr-ca/articles/support/matrix.md
new file mode 100644
index 0000000000..1d8783c5bc
--- /dev/null
+++ b/fr-ca/articles/support/matrix.md
@@ -0,0 +1,518 @@
+---
+title: Auth0 Product Support Matrix
+description: This doc covers what features, platforms, and software configurations Auth0 supports.
+toc: true
+classes: support-matrix-page
+topics:
+    - support
+    - support-matrix
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Auth0 Product Support Matrix
+
+For customers with valid [subscriptions](${manage_url}/#/account/billing/subscription), this article covers the features, platforms, and software configurations that are eligible for Auth0 support.
+
+Auth0 provides support in alignment with the [Terms of Service](https://auth0.com/terms) and Pricing and Support plans.
+
+## Auth0 Support Coverage
+
+Official support provided by Auth0 is limited to the languages, platforms, versions, and technologies specifically listed as such on this page. Anything that is **not** listed, or is listed as **community-supported**, is ineligible for Auth0 support.
+
+If you have questions about unsupported items, you can post your question on the [Auth0 public forum](https://community.auth0.com/).
+
+For community-supported items, you can ask for help by contacting the developers responsible for those items (such as submitting issues on the GitHub repositories for the specific libraries or software development kits (SDKs)).
+
+::: note
+Auth0 support is limited to the most recent version of the technologies listed (unless otherwise specified). If you are using an older version, you will be required to upgrade prior to seeking support.
+:::
+
+### Definitions
+
+Throughout this article, we will use the following terms to indicate the varying levels of support Auth0 will provide.
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    LabelDescription
    Supported
    		Auth0 has formally tested, will support, and provide both new features and bug fixes (if applicable) for these items.
    Sustained
    		Auth0 will support and may provide bug fixes (if applicable) for these items.
    Bug fixes
    		May receive bug fixes
    Community
    		Auth0 does not support these items, and all assistance regarding these items will come from the general community.
    
+
+## Browsers
+
+This section covers the browsers that Auth0 will support when using the Auth0 Dashboard or Lock Library, or executing authentication transactions.
+
+### Auth0 Dashboard
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    BrowserLevel of Support
    Google Chrome (Latest version)
    Supported
    Apple Safari (Latest version)
    Sustained
    Microsoft Edge (Latest version)
    Sustained
    Mozilla Firefox (Latest version)
    Sustained
    
+
+::: note
+At this time, Auth0 only supports use of the Dashboard with desktop browsers.
+:::
+
+### Auth0 Lock and Authentication
+
+#### Desktop Browsers
+
+
+  
+    
+      
+      
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    BrowserLevel of Support
+    
    Google Chrome (Latest version)
    Supported
    Apple Safari (Latest version)
    Sustained
    Microsoft Internet Explorer 10/11
    Sustained
    Microsoft Edge (Latest version)
    Sustained
    Mozilla Firefox (Latest version)
    Sustained
    
+
+#### Mobile Browsers
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Mobile browserLevel of Support
    Apple Safari for iOS 9 (or later)
    Supported
    Google Chrome for Android KitKat (4.4) or later
    Supported
    
+
+## Operating Systems
+
+This section covers the operating systems (OS) that Auth0 will support when using the Auth0 Dashboard, Lock Library or executing authentication transactions.
+
+::: note
+Auth0 support is limited to the most recent version of the OS listed (unless otherwise specified). If you are using an older version, please upgrade prior to seeking support.
+:::
+
+### Auth0 Dashboard
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    OSLevel of Support
    Apple MacOS (when using Google Chrome as your browser)
    Supported
    Apple MacOS (when using any browser besides Google Chrome)
    Sustained
    Linux (Ubuntu)
    Sustained
    Microsoft Windows
    Sustained
    
+
+### Auth0 Lock and Authentication
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    OSLevel of Support
    Apple iOS 9 (or later)
    Supported
    Google Android KitKat (4.4) or later
    Supported
    
+
+## SDKs and Libraries
+
+### Auth0 Lock Widgets
+
+<%= include('../_includes/_libraries_support_lock') %>
+
+### Auth0 SDKs
+
+<%= include('../_includes/_libraries_support_sdks') %>
+
+### Framework and Platform Integration SDKs
+
+<%= include('../_includes/_libraries_support_frameworks') %>
+
+### Auth0 Analytics SDK
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+  
+
    LibraryVersionLevel of Support
    auth0-analytics.jsv1
    Supported
    
+
+### Content Management Systems Plugins
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    CMSLevel of Support
    WordPress
    Supported
    Drupal
    Community
    Joomla
    Community
    
+
+## Quickstarts and Samples
+
+### Mobile/Native Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    Android
    Supported
    Cordova
    Supported
    Device Authorization Flow
    Supported
    Ionic 4
    Supported
    iOS - Swift
    Supported
    React Native
    Supported
    Windows Universal App C#
    Supported
    WPF/Winforms
    Supported
    Xamarin
    Supported
    
+
+### Single-Page Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    Angular
    Supported
    JavaScript
    Supported
    React
    Supported
    Vue.js
    Supported
    
+
+### Regular Web Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    ASP.NET (OWIN)
    Supported
    ASP.NET Core v2.1
    Supported
    ASP.NET Core v3.1
    Supported
    Go
    Supported
    Java
    Supported
    Java Spring Boot
    Supported
    Node.js
    Supported
    PHP
    Supported
    PHP (Laravel)
    Supported
    Python
    Supported
    Ruby on Rails
    Supported
    
+
+### Backends/APIs
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    ASP.NET Core Web API
    Supported
    ASP.NET Web API (OWIN)
    Supported
    Go
    Supported
    Java Spring Security
    Supported
    Node.js (Express)
    Supported
    PHP
    Supported
    Laravel
    Supported
    Python
    Supported
    Ruby on Rails
    Supported
    
+
+## Extensions
+
+::: note
+Auth0 does not provide support for custom extensions.
+:::
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+  
+
    ExtensionsLevel of Support
    Extensions created by Auth0 and published to the Management Dashboard
    Sustained
    
+
+Feature requests should be requested at the GitHub repository of each extension. Please note there is no commitment from Auth0 to implement requests.
+
+
diff --git a/fr-ca/articles/support/removing-auth0-exporting-data.md b/fr-ca/articles/support/removing-auth0-exporting-data.md
new file mode 100644
index 0000000000..c9cc3013e5
--- /dev/null
+++ b/fr-ca/articles/support/removing-auth0-exporting-data.md
@@ -0,0 +1,47 @@
+---
+description: How to export data out of Auth0.
+topics:
+    - support
+    - data
+    - data-export
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Export Data Out of Auth0
+
+All data in your Auth0 tenant is always under your control and is [available through the management API](/api/v2) at any time.
+The only information which is not available through the API (for security reasons) are the password hashes of your [Auth0-hosted database users](/connections/database) and private keys.
+You can request the password hashes by opening a [support ticket](${env.DOMAIN_URL_SUPPORT}). Please note that this operation is not available for our Free subscription tier, and we are unable to accept or guarantee requests for exports at a specific time and date.
+
+## Keep user credentials on your infrastructure
+
+If you want to store user passwords on your database, you can set up a [custom database connection](/connections/database/mysql) which Auth0 will query each time a user logs in.
+In this case Auth0 will never store any password hashes, unless you choose to [progressively migrate users to Auth0](/connections/database/migrating).
+
+## If you don't want to use proprietary Auth0 components
+
+Auth0 primarily uses OpenID Connect (OIDC) as its authentication protocol, so you should be able to implement an integration to your application using standard libraries. The same situation applies when [integrating Auth0 through SAML](/saml-configuration).
+
+All of Auth0's SDKs, libraries, and samples [are published on GitHub as free software](https://github.com/auth0/).
+
+## Social identity providers
+
+If you choose not to use Auth0 but keep using the same OAuth client IDs and secrets for your social identity providers, you will retain access to user information without needing to display new consent dialogs.
+
+## Custom code
+
+All of Auth0's custom code features (rules, custom database scripts, custom OAuth connections, and so on) run on a Node.js sandbox service.
+
+All libraries available on the sandbox service are also available on npm for use with standard Node.js code.
+
+## Keep reading
+
+::: next-steps
+* [Auth0 privacy policy](https://auth0.com/privacy)
+* [Availability and trust](https://auth0.com/availability-trust)
+* [Data security and confidentiality policies](https://auth0.com/security)
+:::
diff --git a/fr-ca/articles/support/reset-account-password.md b/fr-ca/articles/support/reset-account-password.md
new file mode 100644
index 0000000000..05c72bd204
--- /dev/null
+++ b/fr-ca/articles/support/reset-account-password.md
@@ -0,0 +1,32 @@
+---
+description: Learn how to reset your Auth0 account password.
+crews: crew-2
+topics:
+    - support
+    - passwords
+    - password-reset
+contentType: how-to
+useCase:
+  - support
+  - reset-passwrod
+---
+
+# Reset Auth0 Account Password
+
+If you need to change your password or you have forgotten the password to your Auth0 account, in most cases, you can set a new password from the Auth0 Dashboard. Password resets cause Auth0 sessions to expire. 
+
+1. On the Auth0 account login screen, click **Don't remember your password?**
+
+2. Provide your email address, and click the **right arrow** to submit. You will receive an email that provides further instructions on resetting your password.
+
+3. If your request was successfully received, you'll be directed back to the login screen with a message that says, "We've just sent you an email to reset your password."
+
+## Special password reset circumstances
+
+- If you've enabled multi-factor authentication (MFA) and need an MFA reset for your admin account, you will need to contact [Auth0 Support](https://auth0.com/docs/support).
+- If you're using a social or enterprise account to log in to Auth0, you will need to reset your password with the appropriate identity provider.
+- If you are an administrator trying to reset a *user's* password, see [Change Users' Passwords](/connections/database/password-change).
+
+## Keep reading
+
+* [Customize Hosted Password Reset Page](/universal-login/password-reset)
diff --git a/fr-ca/articles/support/sld.md b/fr-ca/articles/support/sld.md
new file mode 100644
index 0000000000..ac13357746
--- /dev/null
+++ b/fr-ca/articles/support/sld.md
@@ -0,0 +1,32 @@
+---
+title: Auth0 Service Level Description
+description: Details on the Auth0 Service Level Description
+topics:
+    - sld
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+# Auth0 Service Level Description
+
+::: warning
+This document summarizes the key elements of Auth0’s Service Level Agreement. For full details, please see the **Support Program and Service Levels** in [Auth0 Legal](https://auth0.com/legal).
+:::
+
+The average availability of the Auth0 Platform in each month will be at least 99.90%.
+
+## Availability Credits
+
+If Auth0 fails to meet its availability service level  during any given month and you request a service level credit, then Auth0 will provide you with a credit as described in the table below. If any credits are unutilized upon expiration of your subscription, then we will apply such credits to any other fees or expenses you owe us. If there are no such other fees or expenses, then we will pay you the credit amount.
+
+| Auth0 Platform Availability Level | Service Level Credit |
+| - | - |
+| < 99.9% - >= 99.0% | 10.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+| < 99.0% - >= 95.0% | 20.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+| < 95% | 50.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+
+Auth0 publishes [status](https://status.auth0.com) and [uptime](http://uptime.auth0.com) monthly reports.
+
+If you require a higher availability commitment or a dedicated instance of Auth0 in your own IT environment, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales) for additional information.
diff --git a/fr-ca/articles/support/subscription.md b/fr-ca/articles/support/subscription.md
new file mode 100644
index 0000000000..bda497694e
--- /dev/null
+++ b/fr-ca/articles/support/subscription.md
@@ -0,0 +1,52 @@
+---
+title: Change or Upgrade Your Auth0 Subscription
+description: How to upgrade or change your Auth0 subscription.
+topics:
+    - support
+    - subscriptions
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+# Change or Upgrade Your Auth0 Subscription
+
+You can make changes to your Auth0 subscription plan via the [Auth0 Management Dashboard](${manage_url}).
+
+1. Log in to the Auth0 [Management Dashboard](${manage_url}).
+2. Click on your tenant name in the top right corner to bring up the associated dropdown box.
+
+  ![](/media/articles/support/subscriptions/account-dropdown.png)
+
+3.  Select **Settings** to open the [Tenant Settings](${manage_url}/#/tenant/) page.
+4. On the **Tenant Settings** page, click on the **Subscription** tab. Note that you have the option of paying for your plan on a **monthly** or **yearly** basis.
+
+  ![](/media/articles/support/subscriptions/subscription.png)
+
+## Upgrade a subscription
+
+You can use the [Management Dashboard](${manage_url}) to upgrade your subscription from:
+
+* The Free plan to the Developer or Developer Pro plan;
+* The Developer plan to the Developer Pro plan.
+
+::: note
+If you would like to upgrade to an Enterprise plan, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales).
+:::
+
+On the **Subscription** tab, scroll down to the panels describing the plan options available to you.
+
+  ![](/media/articles/support/subscriptions/upgrades.png)
+
+To select a new plan, click **Checkout** in the associated box to upgrade. If you do not have your billing information stored with Auth0, you'll need to provide it at this point.
+
+  ![](/media/articles/support/subscriptions/billing.png)
+
+Click **Subscribe Now** to confirm your information and activate your new subscription.
+
+## Downgrade to a free subscription
+
+On the **Subscription** tab, scroll down to the box associated with the **Free** plan and click **Checkout**.
+
+To confirm your subscription change, click **Subscribe Now**.
diff --git a/fr-ca/articles/support/testing.md b/fr-ca/articles/support/testing.md
new file mode 100644
index 0000000000..cf2c67b86a
--- /dev/null
+++ b/fr-ca/articles/support/testing.md
@@ -0,0 +1,55 @@
+---
+title: Testing Your Auth0 Implementation
+description: Guidelines for testing your Auth0 implementation prior to deployment to Production environments
+topics:
+    - support
+    - testing
+    - pre-deployment-testing
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Testing Your Auth0 Implementation
+
+You should run unit and integration tests before implementing Auth0 on a live application or service.
+
+Performing tests against Auth0 APIs may lead to your account being rate limited, so we recommend creating mock Auth0 APIs during testing. Depending on your development environment, your test tools may also provide mock API functionality. There are also numerous API mocking tools available, such as [MockServer](http://www.mock-server.com/) or [JSON Server](https://github.com/typicode/json-server), that enable you to quickly create fake APIs for testing. You can also [use Postman to set up a mock server](https://www.getpostman.com/docs/postman/mock_servers/setting_up_mock).
+
+::: note
+Enterprise customers may [request load testing against Auth0](/policies/load-testing).
+:::
+
+## Performance Testing
+
+When conducting performance testing, you may encounter issues with your implementation. The following are steps you can take to begin the troubleshooting process and identify where there might be issues of concern.
+
+### The Auth0 Dashboard
+
+The [Logs section of the Auth0 Dashboard](${manage_url}/#/logs) stores data on:
+
+* Actions taken in the Dashboard by administrators
+* Authentications made by your users
+
+There are also [extensions](/extensions) that you can use for logging purposes, including [exporting logs to third-party tools](/extensions#export-auth0-logs-to-an-external-service) and [gathering information on the use of custom code in your account](/extensions#access-to-real-time-webtask-logs).
+
+### Third-Party Testing Tools
+
+There are a number of third-party testing tools that you can use for performance testing against RESTful APIs. Here are some options you might consider (note that Auth0 does not endorse any particular product or tool):
+
+* [Apache JMeter](http://jmeter.apache.org/)
+* [Artillery](https://artillery.io/)
+* [Micro Focus LoadRunner](https://www.radview.com/)
+* [Loader](https://loader.io/)
+* [RadView Webload](https://www.radview.com/)
+* [SmartBear LoadUI](https://smartbear.com/)
+* [Vegeta](https://github.com/tsenart/vegeta)
+* [Wrk](https://github.com/wg/wrk)
+
+These tools should provide activity logs that help you identify anything that is concerning. If you need assistance with deciphering your log or identifying the potential issue, please contact Support.
+
+### HAR Files
+
+If you discover an issue that you can reproduce, you can [create a HAR file](/tutorials/troubleshooting-with-har-files) and send it to our Support team for additional assistance.
\ No newline at end of file
diff --git a/fr-ca/articles/support/tickets.md b/fr-ca/articles/support/tickets.md
new file mode 100644
index 0000000000..f2a7253f40
--- /dev/null
+++ b/fr-ca/articles/support/tickets.md
@@ -0,0 +1,66 @@
+---
+description: How to open and manage tickets with Support Center.
+topics:
+    - support
+    - support-tickets
+    - tickets
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Open and Manage Support Tickets
+
+With [Support Center](${env.DOMAIN_URL_SUPPORT}), you can create tickets for questions or issues you are experiencing. You can access Support Center if you are a full administrator of an Auth0 account, or have received an invitation to Support Center from an administrator. 
+
+If you are an existing Private Cloud customer, you will need to create an Auth0 cloud-based account to log in to the Support Center. This account can also be used for Dev/Test purposes at no additional cost. Please contact your Technical Account Manager or Sales Executive to associate your cloud-based account to your existing Private Cloud subscription.
+
+## Open a new ticket
+
+1. From [Support Center](${env.DOMAIN_URL_SUPPORT}), click on the **Open Ticket** button. If you don't see this button, then you do not have access to support (only paying and trial customers have access to Support). In this case you can use our [Community](https://community.auth0.com/) instead (click **Ask our Community**).
+![Support Center](/media/articles/support/open-ticket.png)
+1. Choose **Affected Tenant** from the dropdown menu.
+1. Under **Issue Type** select the type of issue that best fits your case.
+![Issue types](/media/articles/support/issue-types.png)
+    * **I have a question or issue regarding Auth0** or **I have a question or issue regarding Auth0 or my Private Cloud instance(s)** - (the second option is only available to Private Cloud customers)
+        * If you are not a Trial Tenant customer, you will be asked to select a severity:
+            * **Low: Product Question** - You have questions about how things work, whether we support something
+            * **Normal: General Support Question** - You are in development and have a question about how to configure something or how to resolve an error
+            * **High: Production Application Issue** - Your Production application is experiencing a minor outage impacting some users/feature(s)
+            * **Urgent: Production Application Offline** - Your Production application is experiencing a critical outage impacting all users
+        *  Depending on the issue type you chose, after you select the severity you may need to answer the **What can we help you with?** question. Choose the answer that best matches your issue. 
+![Customer Reason](/media/articles/support/customer-reason.png)
+        * After you make your selection, you can choose to answer some follow-up questions to further refine your request. You can also choose to skip this step by clicking the toggle. 
+![Follow-up questions](/media/articles/support/follow-up.png)
+    * **I would like something new or changed in Auth0** - You would like to suggested product improvements or enhancement requests
+    * **I have a question regarding billing or my recent payments** - You are experiencing issues such as incorrect billing, charges to the incorrect account, and so on
+    * **I have a Compliance or legal question** - You would like to report security vulnerabilities or legal questions
+    * **I have a question regarding my Auth0 account** - You need operational assistance with your account or tenant, or would like to file a request for testing according to our Load and Penetration Testing policies
+::: note
+Selection of severity is not available to Trial Tenant customers or those who have selected any of the following issue types: **I would like something new or changed in Auth0**, **I have a question regarding billing or my recent payments**, **I have a Compliance or legal question**.
+:::
+1. Next, provide a clear summary of the question/issue in the **Subject** field.
+1. In the **Description** box, provide as much detail as possible about the issue. When writing in this box, you can style your text with [Markdown](https://guides.github.com/features/mastering-markdown) and preview what you have written by clicking on **Preview**.
+    When writing your description, please try to include the following information (if applicable):
+    * What were you trying to do?
+    * What did you expect to happen?
+    * Where did things go wrong?
+    * Were there any error messages or screen shots showing the problem? If so, please include them.
+    * Has this worked before, or are you trying a new configuration?
+    * Does the problem occur for all users or just a few?
+    * What troubleshooting steps have you tried?
+1. When you have completed all the fields, click on the **SUBMIT** button.
+
+## Update an existing ticket
+
+1. You can view the existing tickets you have filed by going to the [Support Center](${env.DOMAIN_URL_SUPPORT}) page and clicking on the **Home** link. Select the ticket that you want to update by clicking on its subject.
+![Select ticket](/media/articles/support/select-ticket.png)
+
+1. Enter any additional details into the text box and then click the **REPLY** button. If you are the ticket requester and the ticket is assigned to an agent, but is not solved or closed, you have the option to change the status of your ticket to **Solved** by checking the **Submit as solved** box next to the **REPLY** button.
+![Update ticket](/media/articles/support/update-ticket.png)
+
+### Closed tickets
+
+If your ticket has been closed, but you'd like to continue working with Auth0 on the issue, please create a new [Support Center ticket](${env.DOMAIN_URL_SUPPORT}). Be sure to include the reference number for the original ticket(s).
diff --git a/fr-ca/articles/tokens/_includes/_rtr_enabled.md b/fr-ca/articles/tokens/_includes/_rtr_enabled.md
new file mode 100644
index 0000000000..3b92633b1c
--- /dev/null
+++ b/fr-ca/articles/tokens/_includes/_rtr_enabled.md
@@ -0,0 +1,3 @@
+::: note
+In compliance with the OAuth2 specifications, when a browser requests a Refresh Token from the `/token` endpoint, Auth0 will only return a Refresh Token if [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) is enabled for that client.
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/_includes/_validate-id-token.md b/fr-ca/articles/tokens/_includes/_validate-id-token.md
new file mode 100644
index 0000000000..92aa63be6b
--- /dev/null
+++ b/fr-ca/articles/tokens/_includes/_validate-id-token.md
@@ -0,0 +1,3 @@
+::: warning
+Be sure to [validate an ID Token](/tokens/guides/validate-id-tokens) before using the information it contains! You can use a [library](https://jwt.io/#libraries-io) to help with this task.
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/concepts/access-tokens.md b/fr-ca/articles/tokens/concepts/access-tokens.md
new file mode 100644
index 0000000000..9b5a68de41
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/access-tokens.md
@@ -0,0 +1,56 @@
+---
+title: Access Tokens
+description: Understand how Access Tokens are used in token-based authentication to allow an application to access an API after a user successfully authenticates and authorizes access.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+# Access Tokens
+
+Access Tokens are used in token-based authentication to allow an application to access an API. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target API. The passed token informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the [**scope**](/scopes) that was granted during authorization.
+
+In addition, if you have chosen to allow users to log in through an [Identity Provider (IdP)](/identityproviders), such as Facebook, the IdP will issue its own Access Token to allow your application to call the IDP's API. For example, if your user authenticates using Facebook, the Access Token issued by Facebook can be used to call the Facebook Graph API. These tokens are controlled by the IdP and can be issued in any format. To learn more, see [Identity Provider Access Tokens](/tokens/concepts/idp-access-tokens). 
+
+## Opaque Access Tokens
+
+Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token needs to call the server that issued the token.
+
+Opaque Access Tokens are tokens whose format you cannot access. Opaque Access Tokens issued by Auth0 can be used with the [`/userinfo` endpoint](/api/authentication#get-user-info) to return a user's profile. 
+
+## JSON Web Token Access Tokens
+
+JSON Web Token (JWT) Access Tokens conform to the [JSON Web Token standard](https://tools.ietf.org/html/rfc7519) and contain information about an entity in the form of claims. They are self-contained in that it is not necessary for the recipient to call a server to validate the token.
+
+Access Tokens issued for the [Auth0 Management API](/api/info) and Access Tokens issued for any custom API that you have registered with Auth0 will follow the [JSON Web Token (JWT)](/tokens/concepts/jwts) standard, which means that their basic structure conforms to the typical [JWT Structure](/tokens/references/jwt-structure), and they contain standard [JWT Claims](/tokens/concepts/jwt-claims) asserted about the token itself.
+
+## Access Token security
+
+You should follow [token best practices](/best-practices/token-best-practices) when using Access Tokens, and for [JWTs](/tokens/concepts/jwts#security), make sure that you [validate an Access Token](/tokens/guides/validate-access-tokens) before assuming that its contents can be trusted.
+
+## Access Token lifetime
+
+### Custom APIs
+
+By default, an Access Token for a custom API is valid for 86400 seconds (24 hours). We recommend that you set the validity period of your token based on the security requirements of your API. For example, an Access Token that accesses a banking API should expire more quickly than one that accesses a to-do API.  
+
+To learn how to change the Access Token expiration time, see [Update Access Token Lifetime](/dashboard/guides/apis/update-token-lifetime).
+
+### /userinfo endpoint
+
+Access Tokens issued strictly for the purpose of accessing the OpenID Connect (OIDC) [`/userinfo` endpoint](/api/authentication#get-user-info) have a default lifetime and can't be changed. The length of lifetime depends on the flow used to obtain the token:
+
+| Flow | Lifetime |
+| ---- | -------- |
+| Implicit | 7200 seconds (2 hours) |
+| Authorization Code/Hybrid | 86400 seconds (24 hours) |
+
+## Keep reading
+
+* [Get Access Tokens](/tokens/guides/get-access-tokens)
+* [Use Access Tokens](/tokens/guides/use-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
diff --git a/fr-ca/articles/tokens/concepts/delegation-tokens.md b/fr-ca/articles/tokens/concepts/delegation-tokens.md
new file mode 100644
index 0000000000..19057c78fb
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/delegation-tokens.md
@@ -0,0 +1,44 @@
+---
+description: Understand how Auth0 delegation tokens work in Auth0.
+topics:
+  - tokens
+  - delegation
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+
+# Delegation Tokens
+
+<%= include('../../_includes/_uses-delegation') %>
+
+A delegation token should be obtained and used when an application needs to call the API of an Application Add-on, such as Firebase or SAP, registered and configured in Auth0, in the same tenant as the calling program.
+
+Given an existing token, this endpoint will generate a new token signed with the `target` application's secret. This is used to flow the identity of the user from the application to an API.
+
+The type of the delegation token varies depending on the provider. For example, if it is issued for Azure Blob Storage, it will be an SAS (Shared Access Signature). If it is for the Firebase Add-on, it will be a JWT.
+
+The ID Token for an authenticated user can be used with the [Delegation endpoint](/api/authentication#delegation) to request a delegation token for a particular target. The target can be an application Add-on configured in Auth0. The Add-ons for which this can be done are those that are not SAML or WS-Fed Add-ons. The Add-on must be configured in Auth0 with secrets obtained from the Add-on service, such as Firebase. Instructions for setting up the secrets are available from the Add-on configuration page for each Add-on. The secrets are used to sign the delegation token so that the Add-on API can validate and trust the token.
+
+The delegation endpoint allows you to set several parameters which govern the contents of the delegation token including the `target`, the `scope`, the API to be called (`api_type`), and an additional free-form area for additional parameters.
+
+See the [Delegation endpoint](/api/authentication#delegation) for more information.
+
+## Auth0.js example
+
+For an example on how to get a new token for an Add-on that you have activated, using __Auth0.js__, refer to [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request). Note that this example is for **version 7** of the __Auth0.js__ library; delegation is **not supported** in version 8 of __Auth0.js__.
+
+## Validity period and termination
+
+The validity period and the ability to revoke a delegation token, varies by individual Add-on. The documentation available from the provider of any Add-on API should be consulted for further information.
+
+## Use Delegation Tokens with public applications
+
+There is an important caveat to note when using the delegation endpoint with [Public Applications](/applications/concepts/app-types-confidential-public#public-applications).
+
+If you call the [Token endpoint](/api/authentication#get-token) from a Public Application, the ID Token will be forcibly signed using `RS256`, even if the _JsonWebToken Signature Algorithm_ in the Application settings is configured as `HS256`.
+
+If you then subsequently call the delegation endpoint with that ID Token, it will fail if the Application's _JsonWebToken Signature Algorithm_ was configured as `HS256`. This is because delegation performs validation according to the Application's settings, but the ID Token was issued with a different algorithm because of the forced algorithm change.
+
+It is therefore important that if you intend to use delegation with a Public Application, that you configure the _JsonWebToken Signature Algorithm_ of your application as `RS256`.
diff --git a/fr-ca/articles/tokens/concepts/id-tokens.md b/fr-ca/articles/tokens/concepts/id-tokens.md
new file mode 100644
index 0000000000..3dce442869
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/id-tokens.md
@@ -0,0 +1,41 @@
+---
+title: ID Tokens
+description: Understand how ID Tokens are used in token-based authentication to cache user profile information and provide it to a client application.  
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - concept
+useCase:
+  - add-login
+  - authentication
+---
+# ID Tokens
+
+ID Tokens are used in token-based authentication to cache user profile information and provide it to a client application, thereby providing better performance and experience. The application receives an ID Token after a user successfully authenticates, then consumes the ID Token and extracts user information from it, which it can then use to personalize the user's experience.
+
+For example, let's say you have built a [regular web application](/applications), [registered it with Auth0](/dashboard/guides/applications/register-app-regular-web), and have [configured it to allow a user to log in using Google](/connections/social/google). Once a user logs in to your app, you can use the ID Token to gather information, such as name and email address, which you can then use to auto-generate and send a personalized welcome email.
+
+## ID Token security
+
+As with any other [JWTs](/tokens/concepts/jwts#security), you should follow [token best practices](/best-practices/token-best-practices) when using ID Tokens.
+
+<%= include('../_includes/_validate-id-token') %>
+
+## ID Token lifetime
+
+By default, an ID Token is valid for 36000 seconds (10 hours). If there are security concerns, you can shorten the time period before the token expires, keeping in mind that one of the purposes of the token is to improve user experience by caching user information. 
+
+To learn how to change the ID Token expiration time, see [Update ID Token Lifetime](/dashboard/guides/applications/update-token-lifetime).
+
+## Keep reading
+
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [Invalid Token Errors](/troubleshoot/references/invalid-token)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [ID Token Structure](/tokens/references/id-token-structure)
+* [Scopes](/scopes)
+* [Get Tokens Using Lock](/libraries/lock#implementing-lock)
diff --git a/fr-ca/articles/tokens/concepts/idp-access-tokens.md b/fr-ca/articles/tokens/concepts/idp-access-tokens.md
new file mode 100644
index 0000000000..8e8effd1f9
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/idp-access-tokens.md
@@ -0,0 +1,49 @@
+---
+title: Identity Provider Access Tokens
+description: Understand third-party Access Tokens issued by identity providers after user authentication and how to use them to call the third-party APIs. 
+topics:
+  - tokens
+  - idp
+  - access-tokens
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+
+# Identity Provider Access Tokens
+
+Third-party Access Tokens are issued by [Identity Providers](/identityproviders) after a user authenticates with that provider. Use the Access Tokens to call the API of the third-party provider that issued them. For example, an Access Token issued after authentication to Facebook could be used to call the Facebook Graph API.
+
+The user authenticates with the IdP by making an HTTP `GET` call to [the /api/v2/user/{user-id} endpoint](/api/management/v2#!/Users/get_users_by_id). To call this endpoint you need an [Access Token for the Management API](/api/management/v2/tokens) that includes the `read:user_idp_tokens` scope. The Access Token for the IdP will be available in the `identities` array, under the element for the particular connection. For information on how to call an IdP API, see [Call an Identity Provider API](/connections/calling-an-external-idp-api).
+
+::: warning
+The contents of third-party Access Tokens will vary depending on the issuing identity provider. Because tokens are created and managed by a third-party (such as Facebook, GitHub, etc.), **the validity period for third-party tokens will vary by the issuing IdP**. If you believe these tokens have been compromised, you will need to revoke or reset them with the third-party that issued them.
+:::
+
+## Renew tokens
+
+There is no standard way to renew IdP Access Tokens through Auth0. The mechanism for renewing IdP Access Tokens varies for each provider.
+
+For certain identity providers, Auth0 can store a [Refresh Token](/tokens/concepts/refresh-token), which you can use to obtain a new Access Token for the IdP. Here is a list of some of the identity providers:
+
+* BitBucket
+* Google OAuth 2.0 (pass the parameter `access_type=offline`, as well the `connection_scope` parameter with required scopes, when calling the Auth0 `/authorize` endpoint)
+* Any other OAuth 2.0 IdP
+* SharePoint
+* Azure AD
+
+Get the IdP Refresh Tokens in the same way as Access Tokens, using [the /api/v2/user/{user-id} endpoint](/api/management/v2#!/Users/get_users_by_id). The Refresh Tokens will be available in the `identities` array, under the element for the particular connection.
+
+## Validate tokens
+
+If you have received an Access Token from an [Identity Provider (IdP)](/identityproviders), in general, you don't need to validate it. You can pass it to the issuing IdP, and the IdP takes care of the rest.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Identity Providers Supported by Auth0](/identityproviders)
+* [Access Tokens for the Management API](/api/management/v2/tokens)
+* [Scopes](/scopes)
+* [Call an Identity Provider API](/connections/calling-an-external-idp-api)
+* [Add Scopes/Permissions to Call Identity Provider's APIs](/connections/adding-scopes-for-an-external-idp)
diff --git a/fr-ca/articles/tokens/concepts/jwks.md b/fr-ca/articles/tokens/concepts/jwks.md
new file mode 100644
index 0000000000..38ef6ab6f1
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/jwks.md
@@ -0,0 +1,39 @@
+---
+title: JSON Web Key Set
+description: A JSON Web Key set is a JSON object which represents a set of JSON Web Keys (a JSON object that represents a cryptographic key).
+topics:
+  - tokens
+  - jwks
+  - jwt
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# JSON Web Key Set
+
+The JSON Web Key Set (JWKS) is a set of keys which contains the public keys used to verify any JSON Web Token (JWT) issued by the authorization server and signed using the RS256 [signing algorithm](/tokens/concepts/signing-algorithms). 
+
+When creating applications and APIs in Auth0, two algorithms are supported for signing JWTs: **RS256** and **HS256**. RS256 generates an asymmetric signature, which means a private key must be used to sign the JWT and a different public key must be used to verify the signature.
+
+Auth0 uses the [JSON Web Key (JWK) specification](https://tools.ietf.org/html/rfc7517) to represent the cryptographic keys used for signing RS256 tokens. This specification defines two high-level data structures: **JSON Web Key (JWK)** and **JSON Web Key Set (JWKS)**. Here are the definitions from the specification:
+
+| Item | Description |
+| - | - |
+| **JSON Web Key (JWK)** | A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value. |
+| **JSON Web Key Set (JWKS)** | A JSON object that represents a set of JWKs. The JSON object MUST have a `keys` member, which is an array of JWKs. |
+
+Auth0 exposes a JWKS endpoint for each tenant, which is found at `https://${account.namespace}/.well-known/jwks.json`. This endpoint will contain the JWK used to sign all Auth0-issued JWTs for this tenant.
+
+::: note
+Currently, Auth0 signs with only one JWK at a time; however, it is important to assume this endpoint could contain multiple JWKs. As an example, multiple keys can be found in the JWKS when [rotating application signing keys](/tokens/guides/manage-signing-keys).
+:::
+
+## Keep reading
+
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Key Sets](/tokens/guides/locate-jwks)
+* [Backend/API Quickstarts](/quickstart/backend)
diff --git a/fr-ca/articles/tokens/concepts/jwt-claims.md b/fr-ca/articles/tokens/concepts/jwt-claims.md
new file mode 100644
index 0000000000..867a5efe32
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/jwt-claims.md
@@ -0,0 +1,89 @@
+---
+title: JSON Web Token Claims
+description: Learn about JSON Web Token (JWT) claims and how they are used in Auth0.
+toc: false
+topics:
+  - tokens
+  - jwt
+  - claims
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+  - invoke-api
+  - secure-api
+---
+# JSON Web Token Claims
+
+::: note
+This page describes the standard types of claims available when using the JSON Web Token (JWT) standard. To learn about OpenID Connect (OIDC) standard claims, see [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims) and [OpenID Connect Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
+:::
+
+[JSON Web Token (JWT)](/tokens/concepts/jwts) claims are pieces of information asserted about a subject. For example, an [ID Token](/tokens/concepts/id-tokens) (which is always a JWT) may contain a claim called `name` that asserts that the name of the user authenticating is "John Doe".
+
+In a JWT, a claim appears as a name/value pair where the name is always a string and the value can be any JSON value. Generally, when we talk about a claim in the context of a JWT, we are referring to the name (or *key*). For example, the following JSON object contains three claims (`sub`, `name`, `admin`):
+
+```
+{
+    "sub": "1234567890",
+    "name": "John Doe",
+    "admin": true
+}
+```
+
+## JWT claim types
+
+There are two types of JSON Web Token (JWT) claims:
+
+* **[Reserved](#reserved-claims)**: Claims defined by the [JWT specification](https://tools.ietf.org/html/rfc7519) to ensure interoperability with third-party, or external, applications. [OpenID Connect (OIDC) standard claims](/scopes/current/oidc-scopes#standard-claims) are reserved claims.
+* **[Custom](#custom-claims)**: Claims that you define yourself. Name these claims carefully, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires), to avoid collision with reserved claims or other custom claims. It can be challenging to deal with two claims of the same name that contain differing information.
+
+### Reserved claims
+
+The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with [third-party applications](/applications/guides/enable-third-party-apps). These are:
+
+* iss (issuer): Issuer of the JWT
+* sub (subject): Subject of the JWT (the user)
+* aud (audience): Recipient for which the JWT is intended
+* exp (expiration time): Time after which the JWT expires
+* nbf (not before time): Time before which the JWT must not be accepted for processing
+* iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
+* jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)
+
+You can see a full list of reserved claims at the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims). 
+
+Note that [OpenID Connect (OIDC) standard claims](/scopes/current/oidc-scopes#standard-claims) returned in [ID Tokens](/tokens/concepts/id-tokens) are reserved claims. For an example showing how to add OIDC standard claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#authenticate-a-user-and-request-standard-claims).
+
+### Custom claims
+
+For your specific use case, you can define your own custom claims, which you control and can add to a token using a [rule](/rules). For example, you may want to add a user's email address to an Access Token and use that to uniquely identify the user, or you may want to add custom information stored in an Auth0 user profile to an ID Token. As long as your rule is in place, the custom claims it adds will appear in new tokens issued when using a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+You can name a custom claim anything that is not already listed in the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims), and you should use collision-resistant names, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires).
+
+For an example showing how to add custom claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+#### Public claims
+
+You can create custom claims for public consumption, which might contain generic information like "name" and "email". If you create public claims, you *must* either register them or use collision-resistant names through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires) and take reasonable precautions to make sure you are in control of the namespace you use.
+
+In the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims), you can see some examples of public claims registered by OpenID Connect (OIDC): 
+
+* auth_time
+* acr
+* nonce
+
+#### Private claims
+
+You can create private custom claims to share information specific to your application. For example, while a public claim might contain generic information like "name" and "email", private claims would be more specific, such as "employee ID" and "department name".
+
+According to the JWT standard, you *should* name private claims cautiously to avoid collision, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 still requires). Private claims should not share names with reserved or public claims.
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims)
+* [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
diff --git a/fr-ca/articles/tokens/concepts/jwts.md b/fr-ca/articles/tokens/concepts/jwts.md
new file mode 100644
index 0000000000..8a8c3aeb7a
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/jwts.md
@@ -0,0 +1,58 @@
+---
+title: JSON Web Tokens
+description: Understand what a JWT is and how it is used.
+topics:
+  - tokens
+  - jwt
+  - id-token
+  - access-token
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+  - invoke-api
+  - secure-api
+---
+# JSON Web Tokens
+
+JSON Web Token (JWT), pronounced "jot", is an open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. Because of its relatively small size, a JWT can be sent through a URL, through a POST parameter, or inside an HTTP header, and it is transmitted quickly. A JWT contains all the required information about an entity to avoid querying a database more than once. The recipient of a JWT also does not need to call a server to validate the token.
+
+Let's talk about the benefits of JWT when compared to Simple Web Token (SWT) and Security Assertion Markup Language (SAML) tokens.
+
+* **More compact**: JSON is less verbose than XML, so when it is encoded, a JWT is smaller than a SAML token. This makes JWT a good choice to be passed in HTML and HTTP environments.
+
+  ![Comparing the length of an encoded JWT and an encoded SAML](/media/articles/jwt/comparing-jwt-vs-saml2.png)
+  _Comparison of the length of an encoded JWT and an encoded SAML_
+
+* **More secure**: JWTs can use a public/private key pair in the form of an X.509 certificate for signing. A JWT can also be symmetrically signed by a shared secret using the HMAC algorithm. And while SAML tokens can use public/private key pairs like JWT, signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON. 
+
+* **More common**: JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn't have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.
+
+* **Easier to process**: JWT is used at internet scale. This means that it is easier to process on user's devices, especially mobile.
+
+JWT is a standard, which means that **all JWTs are tokens, but not all tokens are JWTs**. JWTs can be used in various ways:
+
+- **Authentication**: When a user successfully logs in using their credentials, an [ID Token](/tokens/concepts/id-tokens) is returned. According to the [OpenID Connect (OIDC) specs](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), an ID Token is always a JWT. 
+
+- **Authorization**: Once a user is successfully logged in, an application may request to access routes, services, or resources (e.g., APIs) on behalf of that user. To do so, in every request, it must pass an Access Token, which *may* be in the form of a JWT. Single Sign-on (SSO) widely uses JWT because of the small overhead of the format, and its ability to easily be used across different domains. 
+
+- **Information Exchange**: JWTs are a good way of securely transmitting information between parties because they can be signed, which means you can be sure that the senders are who they say they are. Additionally, the structure of a JWT allows you to verify that the content hasn't been tampered with.
+
+## Security
+
+The information contained within the JSON object can be verified and trusted because it is digitally signed. Although JWTs can also be encrypted to provide secrecy between parties, Auth0-issued JWTs are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, we will focus on *signed* tokens, which can *verify the integrity* of the claims contained within them, while encrypted tokens *hide* those claims from other parties.
+
+In general, JWTs can be signed using a secret (with the **HMAC** algorithm) or a public/private key pair using **RSA** or **ECDSA** (although Auth0 supports only HMAC and RSA). When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
+
+Before a received JWT is used, it should be [properly validated using its signature](/tokens/guides/validate-jwts#check-the-signature). Note that a successfully validated token only means that the information contained within the token has not been modified by anyone else. This doesn't mean that others weren't able to see the content, which is stored in plain text. Because of this, you should never store sensitive information inside a JWT and should take other steps to ensure that JWTs are not intercepted, such as by sending JWTs only over HTTPS, following [best practices](/best-practices/token-best-practices), and using only secure and up-to-date libraries.
+
+## Keep reading
+
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Key Sets](/tokens/guides/locate-jwks)
+* [Tokens Best Practices](/best-practices/token-best-practices)
+* [Web Apps vs. Web APIs / Cookies vs Tokens](/design/web-apps-vs-web-apis-cookies-vs-tokens)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/fr-ca/articles/tokens/concepts/refresh-token-rotation.md b/fr-ca/articles/tokens/concepts/refresh-token-rotation.md
new file mode 100644
index 0000000000..4f48c8014b
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/refresh-token-rotation.md
@@ -0,0 +1,79 @@
+---
+description: Understand how Refresh Token rotation provides greater security by issuing a new Refresh Token with each request made to Auth0 for a new Access Token by a client using Refresh Tokens.
+topics:
+  - tokens
+  - refresh-token-rotation
+contentType: concept
+useCase:
+  - refresh-token-rotation
+  - silent-authentication
+---
+# Refresh Token Rotation
+
+Refresh Token Rotation is a technique for getting new Access Tokens using Refresh Tokens that goes beyond silent authentication. Refresh Tokens are typically longer lived and can be used to request new Access Tokens after the shorter-lived Access Tokens expire. Refresh Tokens are often used in native applications on mobile devices in conjunction with short-lived Access Tokens to provide seamless UX without having to issue long-lived Access Tokens. 
+
+With Refresh Token Rotation enabled on the Auth0 Dashboard, every time a client exchanges a Refresh Token to get a new Access Token, a new Refresh Token is also returned. Therefore, you no longer have a long-lived Refresh Token that, if compromised, could provide illegitimate access to resources. As Refresh Tokens are continually exchanged and invalidated, the threat is reduced. 
+
+The way Refresh Token rotation works in Auth0 conforms with the [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) and works with the following flows:
+* [Authorization Code Flow](/flows/concepts/auth-code)
+* [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+* [Device Authorization Flow](/flows/concepts/device-auth)
+* [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password)
+
+## Maintaining user sessions in SPAs
+
+Until very recently, SPAs maintained the user’s session by using the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) in conjunction with [Silent Authentication](/api-auth/tutorials/silent-authentication). Recent developments in browser privacy technology, such as Intelligent Tracking Prevention (ITP) prevent access to the Auth0 session cookie, thereby requiring users to reauthenticate. 
+
+![Refresh Token and Access Tokens](/media/articles/tokens/rt-and-at.png)
+
+Unfortunately, long-lived Refresh Tokens are not suitable for SPAs because there is no persistent storage mechanism in a browser that can assure access by the intended application only. As there are vulnerabilities that can be exploited to obtain these high-value artifacts and grant malicious actors access to protected resources, using Refresh Tokens in SPAs has been strongly discouraged. 
+
+Refresh Token Rotation offers a remediation to end-user sessions being lost due to side-effects of browser privacy mechanisms. Because Refresh Token Rotation does not rely on access to the Auth0 session cookie, it is not affected by ITP or similar mechanisms.
+
+The following state diagram illustrates how Refresh Token Rotation is used in conjunction with the Authorization Code Flow with PKCE, but the general principle of getting a new refresh token with each exchange applies to all supported flows.
+
+![Refresh Token Rotation State Diagram](/media/articles/tokens/rtr-state-diagram.png)
+
+This means you can safely use Refresh Tokens to mitigate the adverse effects of browser privacy tools and provide continuous access to end-users without disrupting the user experience.
+
+## Automatic reuse detection
+
+When a client needs a new Access Token, it sends the Refresh Token with the request to Auth0 to get a new token pair. As soon as the new pair is issued by Auth0, the Refresh Token used in the request is invalidated. This safeguards your app from replay attacks resulting from compromised tokens.
+
+Without enforcing sender-constraint, it’s impossible for the authorization server to know which actor is legitimate or malicious in the event of a replay attack. So it’s important that the most recently issued Refresh Token is also immediately invalidated when a previously-used Refresh Token (already invalidated) is sent to the authorization server. This prevents any Refresh Tokens in the same token family (all Refresh Tokens descending from the original Refresh Token issued for the client) from being used to get new Access Tokens.
+
+For example, consider the following scenario: 
+
+![Reuse Detection](/media/articles/tokens/reuse-detection1.png)
+
+1. Legitimate Client has **Refresh Token 1**, and it is leaked to or stolen by Malicious Client. 
+2. Legitimate Client uses **Refresh Token 1** to get a new Refresh Token/Access Token pair.
+3. Auth0 returns **Refresh Token 2/Access Token 2**.
+4. Malicious Client then attempts to use **Refresh Token 1** to get an Access Token. Auth0 recognizes that Refresh Token 1 is being reused, and immediately invalidates the Refresh Token family, including **Refresh Token 2**.
+5. Auth0 returns an **Access Denied** response to Malicious Client.
+6. **Access Token 2** expires and Legitimate Client attempts to use **Refresh Token 2** to request a new token pair. Auth0 returns an **Access Denied** response to Legitimate Client.
+7. Re-authentication is required.
+
+This protection mechanism works regardless of whether the legitimate client or the malicious client is able to exchange **Refresh Token 1** for a new token pair before the other. As soon as reuse is detected, all subsequent requests will be denied until the user re-authenticates. When reuse is detected, Auth0 captures detected reuse events (such as `ferrt` indicating a failed exchange) in logs. This can be especially useful in conjunction with Auth0’s log streaming capabilities.
+
+Another example is where the malicious client steals Refresh Token 1 and successfully uses it to acquire an Access Token before the legitimate client attempts to use Refresh Token 1. In this case, the malicious client’s access would be short-lived because Refresh Token 2 (or any subsequently issued RTs) is automatically revoked when the legitimate client tries to use Refresh Token 1, as shown in the following diagram:
+
+![Reuse Detection](/media/articles/tokens/reuse-detection2.png)
+
+## SDK support
+
+The following SDKs include support for Refresh Token Rotation and automatic reuse detection. 
+
+* [Auth0 SPA SDK](/libraries/auth0-spa-js)
+* [Auth0 Swift (iOS) SDK](/libraries/auth0-swift)
+* [Auth0 Android SDK](/libraries/auth0-android)
+
+You can opt-in to storing tokens in either local storage or browser memory, the default being in browser memory. See [Token Storage](/tokens/concepts/token-storage) for details.
+
+## Keep reading
+
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+* [Use Refresh Token Rotation](/tokens/guides/use-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12)
diff --git a/fr-ca/articles/tokens/concepts/refresh-tokens.md b/fr-ca/articles/tokens/concepts/refresh-tokens.md
new file mode 100644
index 0000000000..8879806c8c
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/refresh-tokens.md
@@ -0,0 +1,82 @@
+---
+description: Understand how refresh tokens work to allow the application to ask Auth0 to issue a new Access Token or ID Token without having to re-authenticate the user.
+topics:
+  - tokens
+  - refresh-tokens
+contentType: concept
+useCase:
+  - invoke-api
+---
+# Refresh Tokens
+
+Auth0 issues an [Access Token](/tokens/concepts/access-tokens) or an [ID Token](/tokens/concepts/id-tokens) in response to an [authentication request](/api-auth). You can use Access Tokens to make authenticated calls to a secured API, while the ID Token contains user profile attributes represented in the form of *claims*. Both are [JWTs](/tokens/concepts/jwts) and therefore have expiration dates indicated using the `exp` claim, as well as security measures, like signatures. Typically, a user needs a new Access Token when gaining access to a resource for the first time, or after the previous Access Token granted to them expires.
+
+A Refresh Token is a special kind of token used to obtain a renewed Access Token. You can request new Access Tokens until the Refresh Token is blacklisted. Applications must [store Refresh Tokens securely](/tokens/concepts/token-storage) because they essentially allow a user to remain authenticated forever.
+
+For native applications, refresh tokens improve the authentication experience significantly. The user has to authenticate only once, through the web authentication process. Subsequent re-authentication can take place without user interaction, using the Refresh Token.
+
+You can increase security by using [Refresh Token rotation](/tokens/concepts/refresh-token-rotation) which issues a new Refresh Token and invalidates the predecessor token with each request made to Auth0 for a new Access Token. Rotating the Refresh Token reduces the risk of a compromised Refresh Token. 
+
+::: panel OIDC-Conformant Apps
+The Refresh Token behavior is applicable to [OIDC-conformant applications](/api-auth/tutorials/adoption/oidc-conformant). You can configure an application to be OIDC-conformant in one of the following two ways:
+
+1. Enabling the **OIDC Conformant** flag for an app.
+2. Passing an `audience` to the `/authorize` endpoint of the Authentication API.
+
+For more information on our authentication pipeline, see [Introducing OIDC-Conformant Authentication](/api-auth/intro).
+:::
+
+## SDK support
+
+### Web apps
+
+Auth0 SDKs support Refresh Tokens including: 
+
+- [Node.js](/quickstart/webapp/nodejs)
+- [ASP.NET Core](/quickstart/webapp/aspnet-core)
+- [PHP](/quickstart/webapp/php)
+- [Java](/dev-centers/java)
+
+For a complete listing, see [Quickstarts](/quickstart/webapp).
+
+### Single-page apps
+
+Providing secure authentication in SPAs has a number of challenges based on your application’s use case. New browser privacy controls like Intelligent Tracking Prevention (ITP) adversely impact the user experience in SPAs by preventing access to third-party cookies.
+
+Auth0 recommends using [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) which provides a secure method for using Refresh Tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
+
+Auth0’s former guidance was to use the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) in conjuntion with [Silent Authentication](/api-auth/tutorials/silent-authentication) in SPAs. This is more secure solution than the Implicit Flow but not as secure as the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) with Refresh Token Rotation. 
+
+### Native/Mobile apps
+
+For information on using Refresh Tokens with our mobile SDKs, see:
+
+* [Mobile / Native Quickstarts](/quickstart/native)
+* [Lock Android: Refreshing JWT Tokens](/libraries/lock-android/refresh-jwt-tokens)
+* [Lock iOS: Saving and Refreshing JWT Tokens](/libraries/lock-ios/v2)
+
+## Restrictions and limitations
+
+* You can only get a Refresh Token if you are implementing the following flows:
+  - [Authorization Code Flow](/flows/concepts/auth-code)
+  - [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+  - [Resource Owner Password Grant](/api-auth/grant/password)
+  - [Device Authorization Flow](/flows/concepts/device-auth)
+
+* If you limit offline access to your API, a safeguard configured via the **Allow Offline Access** switch on the [API Settings](${manage_url}/#/apis), Auth0 will not return a Refresh Token for the API (even if you include the `offline_access` scope in your request).
+
+* Rules will run for the [Refresh Token Exchange](/tokens/guides/use-refresh-tokens). To execute special logic, you can look at the `context.protocol` property in your rule. If the value is `oauth2-refresh-token`, then the rule is running during the exchange.
+
+  ::: warning
+  If you try to do a redirect with context.redirect, the authentication flow will return an error.
+  :::
+
+* If you have added custom claims to your tokens using a rule, the custom claims will appear in new tokens issued when using a Refresh Token for as long as your rule is in place. Although new tokens do not automatically inherit custom claims, rules run during the Refresh Token flow, so the same code will be executed. This allows you to add or change custom claims in newly-issued tokens without forcing previously-authorized applications to obtain a new Refresh Token.
+
+## Keep reading
+
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation)
+* [Token Storage](/tokens/concepts/token-storage)
diff --git a/fr-ca/articles/tokens/concepts/signing-algorithms.md b/fr-ca/articles/tokens/concepts/signing-algorithms.md
new file mode 100644
index 0000000000..5a47dcd750
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/signing-algorithms.md
@@ -0,0 +1,46 @@
+---
+title: Signing Algorithms
+description: Learn the basics of signing algorithms and recommendations for configuring them in the Auth0 Dashboard.
+topics:
+  - api-authentication
+  - oidc
+  - apis
+  - applications
+  - signing-algorithms
+  - RS256
+  - HS256
+contentType: concept
+useCase:
+  - add-login
+  - secure-api
+  - call-api
+---
+# Signing Algorithms
+
+The algorithm used to sign tokens issued for your application or API. A [signature](/tokens/references/jwt-structure#signature) is part of a [JSON Web Token (JWT)](/tokens/concepts/jwts) and is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way.
+
+You can select from the following signing algorithms:
+
+- **RS256** (RSA Signature with SHA-256): An [asymmetric algorithm](https://en.wikipedia.org/wiki/Public-key_cryptography), which means that there are two keys: one public key and one private key that must be kept secret. Auth0 has the private key used to generate the signature, and the consumer of the JWT retrieves a public key from the metadata endpoints provided by Auth0 and uses it to [validate the JWT signature](/tokens/guides/validate-jwts).
+
+- **HS256** (HMAC with SHA-256): A [symmetric algorithm](https://en.wikipedia.org/wiki/Symmetric-key_algorithm), which means that there is only one private key that must be kept secret, and it is shared between the two parties. Since the same key is used both to generate the signature and to validate it, care must be taken to ensure that the key is not compromised. This private key (or secret) is created when you [register your Application](/getting-started/set-up-app) (**Client Secret**) or [API](/getting-started/set-up-api) (**Signing Secret**) and choose the HS256 signing algorithm.
+
+## Our recommendation
+
+The most secure practice, and our recommendation, is to use **RS256** because:
+
+- With RS256, you are sure that only the holder of the private key (Auth0) can sign tokens, while anyone can check if the token is valid using the public key.
+
+- With RS256, you can request a token that is valid for multiple audiences.
+
+- With RS256, if the private key is compromised, you can implement key rotation without having to re-deploy your application or API with the new secret (which you would have to do if using HS256).
+
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JSON Web Key Set](/tokens/concepts/jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/fr-ca/articles/tokens/concepts/token-storage.md b/fr-ca/articles/tokens/concepts/token-storage.md
new file mode 100644
index 0000000000..c880df666c
--- /dev/null
+++ b/fr-ca/articles/tokens/concepts/token-storage.md
@@ -0,0 +1,108 @@
+---
+description: Understand how and where to store tokens used in token-based authentication.
+toc: true 
+topics:
+  - security
+  - tokens
+  - token storage
+contentType:
+  - concept
+useCase:
+  - store-tokens
+---
+
+# Token Storage
+
+Securing single page apps (SPAs) that make API calls come with their own set of concerns. You'll need to ensure that tokens and other sensitive data are not vulnerable to [cross-site scripting](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) and can't be read by malicious JavaScript.
+
+## Next.js static site scenarios
+
+When you're building a Next.js application, authentication might be needed in the following cases:
+
+1. When accessing a page
+2. When accessing an API route
+3. When your application calls an API hosted outside of your Next.js application on behalf of the user
+
+Where a server is available, your app can handle the interaction with Auth0 and create a session, but in this model, we don't have a backend. All of the work happens on the frontend:
+
+1. The user is redirected to Auth0.
+2. When the user is successfully signed in, they will be redirected back to the application.
+3. The client-side will complete the code exchange with Auth0 and retrieve the user's `id_token` and `access_token` which will be stored in memory.
+
+![In-Memory Token Storage](/media/articles/tokens/in-memory-token-storage.png)
+
+## Traditional web app scenarios
+
+If your app is using a sign in scenario that doesn't require API calls, only an ID Token is required. There is no need to store it. You can validate it and get the data from it that you required. 
+
+If your app needs to call APIs on behalf of the user, Access Tokens and (optionally) Refresh Tokens are needed. These can be stored server-side or in a session cookie. The cookie needs to be encrypted and have a maximum size of 4 KB. If the data to be stored is large, storing tokens in the session cookie is not a viable option. 
+
+Use the following flow types in these scenarios: 
+
+- [Authorization Code Flow](/flows/concepts/auth-code)
+- [Regular Web App Quickstarts](/quickstart/webapp)
+
+## Native/Mobile app scenarios
+
+Store tokens in a secure storage that the OS offers and limit access to that storage. For example, leverage KeyStore for Android and KeyChain for iOS.
+
+Use the following flow types in these scenarios:
+
+- [Authorization Code Flow with Proof Key for Code Exchange](/flows/concepts/auth-code-pkce)
+- [Saving and Renewing Tokens for Android](/libraries/auth0-android/save-and-refresh-tokens)
+- [Saving and Renewing Tokens for Swift](/libraries/auth0-swift/save-and-refresh-jwt-tokens)
+- [Native/Mobile Apps Quickstarts](/quickstart/native)
+
+## Single-page app scenarios
+
+We recommend using the [Auth0 SPA SDK](/libraries/auth0-spa-js) to handle token storage, session management, and other details for you.
+
+When the SPA calls only an API that is served from a domain that can share cookies with the domain of the SPA, no tokens are needed. OAuth adds additional attack vectors without providing any additional value and should be avoided in favor of a traditional cookie-based approach. For an overview of this approach and an example implementation, see [SPA  Authentication Using Cookies](/login/spa/authenticate-with-cookies).
+
+When the SPA calls multiple APIs that reside in a different domain, access and optionally refresh tokens are needed.
+
+-  If the SPA backend can handle the API calls, handle tokens server-side using:
+    - [Authorization Code Flow](/flows/concepts/auth-code)
+    - [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+
+- If the SPA backend cannot handle the API calls, the tokens should be stored in the SPA backend but the SPA needs to fetch the tokens from the backend to perform requests to the API. A protocol needs to be established between the backend and the SPA to allow the secure transfer of the token from the backend to the SPA.
+
+- If you have a SPA with **no** corresponding backend server, your SPA should request new tokens on login and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.
+
+<%= include('../_includes/_rtr_enabled') %>
+
+### Browser in-memory scenarios
+
+Auth0 recommends storing tokens in browser memory as the most secure option. Using [Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) to handle the transmission and storage of tokens is the best way to protect the tokens, as Web Workers run in a separate global scope than the rest of the application. Use [Auth0 SPA SDK](/libraries/auth0-spa-js) whose default storage option is in-memory storage leveraging Web Workers.
+
+If you cannot use Web Workers, Auth0 recommends as an alternative that you use [JavaScript closures](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Emulating_private_methods_with_closures) to emulate private methods.
+
+ Use [Auth0 SPA SDK](/libraries/auth0-spa-js) whose default storage option is in-memory storage to leverage both Web Workers and JavaScript closures depending on the type of token.
+
+::: warning
+The in-memory method for browser storage **does not** provide persistence across page refreshes and browser tabs. 
+:::
+
+### Browser local storage scenarios
+
+Using browser local storage can be viable alternative to mechanisms that require retrieving the Access Token from an iframe and to cookie-based authentication across domains when these are not possible due to browser restrictions (e.g. ITP2).
+
+::: warning
+Storing tokens in browser local storage provides persistence across page refreshes and browser tabs, however if an attacker can achieve running JavaScript in the SPA using a cross-site scripting (XSS) attack, they can retrieve the tokens stored in local storage. A vulnerability leading to a successful XSS attack can be either in the SPA source code or in any third-party JavaScript code (such as bootstrap, jQuery, or Google Analytics) included in the SPA.
+:::
+
+::: panel Reduce Security Risks with Local Storage
+If the SPA is using Implicit (although it is recommended that authorization code with PKCE is used) or Hybrid Flows, the absolute token expiration time can be reduced. This will reduce the impact of a reflected XSS (but not of a persistent one). To do so, go to **Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds)**.
+
+Reduce the amount of third party JavaScript code included from a source outside your domain to the minimum needed (such as links to jQuery, Bootstrap, Google Analytics etc.) Reducing third-party JS code reduces the possibility of an XSS vulnerability. Performing [Subresource Integrity (SRI)](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) checking in third-party scripts (where possible) to verify that the resources fetched are delivered without unexpected manipulation is also more secure.
+:::
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Auth0 SPA SDK](https://github.com/auth0/auth0-spa-js)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
+* [Using Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers)
diff --git a/fr-ca/articles/tokens/guides/configure-refresh-token-rotation.md b/fr-ca/articles/tokens/guides/configure-refresh-token-rotation.md
new file mode 100644
index 0000000000..835ee5a4bb
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/configure-refresh-token-rotation.md
@@ -0,0 +1,94 @@
+---
+description: Learn how to configure Refresh Token rotation.
+topics:
+  - tokens
+  - refresh-tokens
+  - refresh-token-rotation
+contentType: how-to
+useCase:
+  - enable-refresh-token-rotation
+  - configure-refresh-token-rotation
+---
+# Configure Refresh Token Rotation
+
+Configure Refresh Token Rotation for each application using the Dashboard or the auth-spa-js SDK. When Refresh Token Rotation is enabled, the transition for the end-user is seamless. The application uses the previous non-rotating Refresh Token which has expired and swaps it for a rotating Refresh Token. 
+
+Migration scenarios accommodate automatic token revocation when migrating from a non-rotating Refresh Token to a rotating Refresh Token and vice-versa.
+
+- Exchanging a non-rotating Refresh Token when Refresh Token Rotation is enabled deletes all the non-rotating tokens issued for the same `client_id`, resource server, and user and tenant.
+- Exchanging a rotating Refresh Token when Refresh Token Rotation is disabled issues a non-rotating Refresh Token and revokes the Rotating Refresh Token family.
+
+## Using the Dashboard
+
+1. Go to [Dashboard > Application Settings](${manage_url}/#/applications). Scroll to the **Application Tokens** section. Set **Refresh Token Behavior** to **Rotating**. 
+
+    ![Application Token Settings - Rotating Refresh Tokens](/media/articles/tokens/rotating-tokens.png)
+
+2. Set **Refresh Token Lifetime (Absolute)** for when a Refresh Token will expire in seconds. 
+
+    The Refresh Token lifetime is the *absolute* lifetime that Refresh Tokens can be used to get new Access Tokens, after which time, the user has to re-authenticate. The default Refresh Token expiration period is 30 days (2592000 seconds). You can configure up to 90 days (7776000 seconds). *The lifetime does not extend when tokens are rotated.* 
+
+3. Set **Refresh Token Reuse Interval** to allow a reuse interval for a Refresh Token to account for lag between request and response time due to the end-user's network, device, and/or location (in seconds). 
+
+4. Click **Save Changes**.
+
+::: note
+Refresh Token Rotation is only supported for OIDC-conformant applications having the Refresh Token grant type enabled.
+:::
+
+## Using the Auth0 SPA SDK
+
+You can also use the Auth0 SPA SDK to enable Refresh Token rotation:
+
+1. Install the latest version of the `auth0-spa-js` SDK.
+
+    ```text
+    npm install @auth0/auth0-spa-js
+    ```
+
+2. Enable the feature on the SDK by setting `useRefreshTokens: true` to start sending the `offline_access` scope.
+
+    ```js
+    const auth0 = await createAuth0Client({
+      domain: '',
+      client_id: '',
+      audience: '',
+      useRefreshTokens: true
+    });
+    ```
+
+3. Configure the Refresh Token rotation settings. For example:  
+
+    ```js
+    PATCH /api/v2/clients/{client_id}
+    {
+      "refresh_token": {
+        "rotation_type": "rotating",
+        "expiration_type": "expiring",
+        "token_lifetime": "2592000",
+        "leeway": 3
+      }
+    }
+    ```
+
+    | Attribute | Description |
+    | -- | -- |
+    | `rotation_type` | Text string: "rotating" or "non-rotating" |
+    | `expiration_type` | Text string: "expiring" or "non-expiring" |
+    | `token_lifetime` | The default Refresh Token expiration period, when Refresh Token Rotation is enabled, is 30 days (2592000 seconds). You can configure up to 90 days (7776000 seconds). **The lifetime does not extend when tokens are rotated.** |
+    | `leeway` | Allow the same Refresh Token to be used within the time period to account for potential network concurrency issues that would otherwise invalidate the token should the client attempt to retry using the same Refresh Token. By default leeway is disabled. Configurable in seconds. |
+
+    ::: panel What is *leeway*?
+    The concept of *leeway* is to avoid concurrency issues when exchanging the Rotating Refresh Token multiple times within a given timeframe. During the leeway window which is configurable on a per second basis, the breach detection features don't apply and therefore a new rotating Refresh Token is issued. Only the previous token can be reused, meaning if the second to last one is exchanged, the breach detection will apply. 
+    :::
+
+## Refresh Tokens and reuse detection
+
+If a previously invalidated token is used, the entire set of Refresh Tokens issued since that invalidated token was issued will immediately be revoked along with the grant, requiring the end-user to re-authenticate. See [Automatic Reuse Detection](/tokens/concepts/refresh-token-rotation#automatic-reuse-detection) for an example. 
+
+## Keep reading
+
+* [Use Refresh Token Rotation](/tokens/guides/use-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [Token Storage](/tokens/concepts/token-storage)
diff --git a/fr-ca/articles/tokens/guides/create-namespaced-custom-claims.md b/fr-ca/articles/tokens/guides/create-namespaced-custom-claims.md
new file mode 100644
index 0000000000..fa954ad2aa
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/create-namespaced-custom-claims.md
@@ -0,0 +1,49 @@
+---
+title: Create Namespaced Custom Claims
+description: Learn about creating collision-resistant names for custom claims by using namespacing.
+toc: false
+topics:
+  - tokens
+  - jwt
+  - claims
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - secure-api
+---
+# Create Namespaced Custom Claims
+
+To keep your custom claims from colliding with any [reserved claims](/tokens/concepts/jwt-claims#reserved-claims) or claims from other resources, you must give them a globally unique name using a namespaced format.
+
+<%= include('../../_includes/_enforce-claim-namespacing') %>
+
+Namespaces are arbitrary identifiers, so technically you can call your namespace anything you want. However, using the URI of a resource you control is conventional (following the way XML namespaces are defined).
+
+Example namespace:
+`http://www.myexample.com/`
+
+Because a URI must be unique and because this URI is under your control, you can generally avoid the risk that someone else is using the same namespace. You can also optionally store the definition of your namespace at the URI, making your namespace self-documenting.
+
+## Guidelines
+
+* Any non-Auth0 `HTTP` or `HTTPS` URL can be used as a namespace identifier. Auth0 domains, which cannot be used as namespace identifiers, include: `auth0.com`, `webtask.io`, and `webtask.run`.
+
+* Although ideally you will use a URI that you control, the namespace URI does not have to point to an actual resource. It is only being used as an identifier; it will not be called.
+
+* You can use any number of namespaces.
+
+## Add a namespace to a claim
+
+Once you have chosen your namespace, you append the claim to it to create a namespaced claim, which can be added to a token.
+
+Example namespaced claim:
+`http://www.myexample.com/favorite_color`
+
+For an example showing how to add custom claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+## Read more
+
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims)
+* [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/guides/disable-refresh-token-rotation.md b/fr-ca/articles/tokens/guides/disable-refresh-token-rotation.md
new file mode 100644
index 0000000000..44e2c223ad
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/disable-refresh-token-rotation.md
@@ -0,0 +1,51 @@
+---
+description: Learn how to disable Refresh Token rotation.
+topics:
+  - tokens
+  - refresh-tokens
+  - refresh-token-rotation
+contentType: how-to
+useCase:
+  - disable-refresh-token-rotation
+  - configure-refresh-token-rotation
+---
+# Disable Refresh Token Rotation
+
+You can disable Refresh Token Rotation for each application using Dashboard or the Management API.
+
+## Using the Dashboard
+
+1. Go to [Dashboard > Application Settings](${manage_url}/#/applications). Scroll to the **Application Tokens** section. Next to **Refresh Token Behavior** select **Non-Rotating**.  
+
+    ![Application Token Settings - Non-Rotating Refresh Tokens](/media/articles/tokens/non-rotating-tokens.png)
+
+2. Click **Save Changes**.
+
+## Using the Management API
+
+2. Disable Refresh Token Rotation for each application using the Management API: 
+
+    ```js
+    const auth0 = await createAuth0Client({
+      domain: '',
+      client_id: '',
+      audience: '',
+      useRefreshTokens: false
+    });
+    ```
+
+2. Configure the non-rotating Refresh Token settings as follows:
+
+    ```js
+    PATCH /api/v2/clients/{client_id}
+    {
+      "refresh_token": {
+        "rotation_type": "non-rotating",
+        "expiration_type": "non-expiring"
+      }
+    }
+    ```
+
+## Keep reading
+
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
diff --git a/fr-ca/articles/tokens/guides/get-access-tokens.md b/fr-ca/articles/tokens/guides/get-access-tokens.md
new file mode 100644
index 0000000000..fc658579f4
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/get-access-tokens.md
@@ -0,0 +1,60 @@
+---
+title: Get Access Tokens
+description: Learn how to request Access Tokens using the Authorize endpoint when authenticating users and include the target audience and scope of access requested by the app and granted by the user.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+---
+# Get Access Tokens
+
+To get an [Access Token](/tokens/concepts/access-tokens), you need to request one when [authenticating](/application-auth) a user.
+
+Auth0 makes it easy for your app to authenticate users using:
+
+* [Quickstarts](/quickstarts): The easiest way to implement authentication, which can show you how to use [Universal Login](/universal-login), the [Lock widget](/lock), and Auth0's language and framework-specific [SDKs](/libraries#sdks). Our [Lock documentation](/libraries/lock) and [Auth0.js documentation](/libraries/auth0js) both provide specifics about retrieving an Access Token after authentication.
+* [Authentication API](/api/authentication): If you prefer to roll your own, you can call our API directly. First, you need to know [which flow to use](/api-auth/which-oauth-flow-to-use) before following the appropriate [flow tutorial](/flows).
+
+## Control Access Token audience 
+
+When a user authenticates, you request an Access Token and include the target audience and scope of access in your request. This access is both requested by the application and granted by the user during authentication using the [Authorize endpoint](/api/authentication#authorize-application).
+
+You may configure your tenant to always include a [default audience](/dashboard/reference/settings-tenant#api-authorization-settings).
+
+| Token Use | Format | Requested Audience | Requested Scope |
+|-----------|--------|--------------------|-------|
+| [/userinfo endpoint](/api/authentication#get-user-info) | [Opaque](/tokens/concepts/access-tokens#opaque-access-tokens) | tenant name (`${account.namespace}`), no value for `audience` parameter, no `audience` parameter passed | `openid` |
+| Auth0 Management API | [JWT](/tokens/concepts/jwts) | Management API v2 identifier (`https://{tenant}.auth0.com/api/v2/`) |  |
+| Your own custom API | [JWT](/tokens/concepts/jwts) | The API Identifier for your custom API registered in the Auth0 Dashboard |  |
+
+::: panel Multiple Audiences
+In only one specific instance, Access Tokens can have multiple target audiences. This requires that your custom API's [signing algorithm](/tokens/concepts/signing-algorithms) is set to **RS256**. 
+
+If you specify an `audience` of your custom API identifier and a `scope` of `openid`, then the resulting Access Token's `aud` claim will be an array rather than a string, and the Access Token will be valid for both your custom API and for the `/userinfo` endpoint. Other than in the use case of a single custom API as well as Auth0's `/userinfo` endpoint, your Access Tokens will be unable to have two or more audiences.
+:::
+
+::: panel Custom Domains and the Management API
+Auth0 issues tokens with an issuer (`iss` claim) of whichever domain you used when requesting the token. [Custom domain](/custom-domains) users may use either their custom domain or their Auth0 domain. For example, say you have a custom domain of **https://login.northwind.com**. If you request an Access Token from **https://login.northwind.com/authorize**, your token's `iss` claim will be **https://login.northwind.com/**. However, if you request an Access Token from **https://northwind.auth0.com/authorize**, your token's `iss` claim will be **https://northwind.auth0.com/**. 
+
+For an Access Token with the target audience of the [Auth0 Management API](/api/management/v2), if you have requested an Access Token from your custom domain, then you **must** call the Management API from your custom domain or else your Access Token will be considered invalid.
+:::
+
+## Renew Access Tokens
+
+By default, an Access Token for a Custom API is valid for 86400 seconds (24 hours). If there are security concerns, you can [shorten the time period before the token expires](/dashboard/guides/apis/update-token-lifetime). 
+
+After an Access Token has expired, you may want to renew your Access Token. To renew the Access Token, you can either reauthenticate the user using Auth0 or use a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Use Access Tokens](/tokens/guides/use-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Token](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/fr-ca/articles/tokens/guides/get-id-tokens.md b/fr-ca/articles/tokens/guides/get-id-tokens.md
new file mode 100644
index 0000000000..edaec2e697
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/get-id-tokens.md
@@ -0,0 +1,47 @@
+---
+title: Get ID Tokens
+description: Learn how to request an ID Token when authenticating users that includes claims about the user by including OIDC scopes.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Get ID Tokens
+
+To get an [ID Token](/tokens/concepts/id-tokens), you need to request one when [authenticating](/application-auth) a user. Auth0 makes it easy for your app to authenticate users using:
+
+* [Quickstarts](/quickstarts): The easiest way to implement authentication, which can show you how to use [Universal Login](/universal-login), the [Lock widget](/lock), and Auth0's language and framework-specific [SDKs](/libraries#sdks). Our [Lock documentation](/libraries/lock) and [Auth0.js documentation](/libraries/auth0js) both provide specifics about retrieving an ID Token after authentication.
+* [Authentication API](/api/authentication): If you prefer to roll your own, you can call our API directly. First, you need to know [which flow to use](/api-auth/which-oauth-flow-to-use) before following the appropriate [flow tutorial](/flows).
+
+## Control ID Token contents
+
+You control which claims about the authenticated user are included in the ID Token consumed by your application by including specific [OpenID Connect Scopes](/scopes/current/oidc-scopes) in the `scope` parameter when you request tokens while authenticating users.
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a rule. 
+:::
+
+As with any other [JWTs](/tokens/concepts/jwts#security), you should follow [token best practices](/best-practices/token-best-practices) when using ID Tokens and [validate an ID Token](/tokens/guides/validate-id-tokens) before assuming that its contents can be trusted.
+
+## Renew ID Tokens
+
+By default, an ID Token is valid for 36000 seconds (10 hours). If there are security concerns, you can [shorten the time period before the token expires](/dashboard/guides/applications/update-token-lifetime), but remember that one of the purposes of this token is to improve performance by caching user information. 
+
+After an ID Token has expired, you may want to renew your ID Token. To renew the ID Token, you can either reauthenticate the user using Auth0, or use a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [OpenID Connect Scopes](/scopes/oidc-scopes)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/fr-ca/articles/tokens/guides/get-refresh-tokens.md b/fr-ca/articles/tokens/guides/get-refresh-tokens.md
new file mode 100644
index 0000000000..a302814794
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/get-refresh-tokens.md
@@ -0,0 +1,99 @@
+---
+title: Get Refresh Tokens
+description: Learn how to get a Refresh Token when you initiate a request using the Authorize endpoint.
+topics:
+  - access-tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Get Refresh Tokens
+
+To get a Refresh Token, you must include the `offline_access` [scope](/scopes) when you initiate an authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint.
+
+For example, if you are using the [Authorization Code Flow](/flows/concepts/auth-code), the authentication request would look like the following:
+
+```text
+https://${account.namespace}/authorize?
+    audience={API_AUDIENCE}&
+    scope=offline_access&
+    response_type=code&
+    client_id=${account.clientId}&
+    redirect_uri=${account.callback}&
+    state={OPAQUE_VALUE}
+```
+
+The Refresh Token is stored in session. Then, when a session needs to be refreshed (for example, a preconfigured timeframe has passed or the user tries to perform a sensitive operation), the app uses the Refresh Token on the backend to obtain a new ID Token, using the `/oauth/token` endpoint with `grant_type=refresh_token`.
+
+Once the user authenticates successfully, the application will be redirected to the `redirect_uri`, with a `code` as part of the URL: `${account.callback}?code=BPPLN3Z4qCTvSNOy`. You can exchange this code with an Access Token using the `/oauth/token` endpoint.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+The response should contain an Access Token and a Refresh Token.
+
+```text
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "refresh_token": "GEbRxBN...edjnXbL",
+  "token_type": "Bearer"
+}
+```
+
+If you are requesting a Refresh Token for a mobile app using the corresponding Native Client (which is public), then you don't need to send the `client_secret` in the request since it's only required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications).
+
+::: warning
+Refresh Tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever.
+:::
+
+For more information on how to implement this using the Authorization Code Flow, refer to our tutorial, [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code). For other grants, see [API Authorization](/api-auth).
+
+::: note
+If the response did not include a Refresh Token, check that you comply with the [Restrictions](#restrictions-on-refresh-token-usage) listed in this document.
+:::
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Revoke Refresh Tokens](tokens/guides/revoke-refresh-tokens)
diff --git a/fr-ca/articles/tokens/guides/locate-jwks.md b/fr-ca/articles/tokens/guides/locate-jwks.md
new file mode 100644
index 0000000000..9f990231aa
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/locate-jwks.md
@@ -0,0 +1,45 @@
+---
+title: Locate JSON Web Key Sets
+description: Learn how to use the JSON Web Keys (JWKs) discovered using the JSON Web Key Set (JWKS) endpoint to verify a JWT signature.
+topics:
+  - tokens
+  - jwks
+  - jwt
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# Locate JSON Web Key Sets
+
+Auth0 exposes a discovery endpoint, which exists at `https://${account.namespace}/.well-known/openid-configuration`. You can use this endpoint to configure your application or API to automatically locate the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) endpoint (`jwks_uri`), which contains the JWKS used to sign all Auth0-issued JSON Web Tokens (JWTs) signed with the RS256 [signing algorithm](/tokens/concepts/signing-algorithms).
+
+When [validating a JWT](/tokens/guides/validate-jwts) using a JWKS, you will need to:
+
+1. Retrieve the JWKS from the Auth0 discovery endpoint, and filter for potential signing keys (e.g., any keys missing a public key or with a `kid` property).
+2. Grab the `kid` property from the Header of the decoded JWT.
+3. Search your filtered JWKS for the key with the matching `kid` property.
+4. Build a certificate using the corresponding `x5c` property in your JWKS.
+5. Use the certificate to verify the JWT's signature.
+
+For an example that uses JWKS to verify a JWT's signature, check out our [Backend/API Quickstarts](/quickstart/backend).
+
+For more info about the structure of a JWT, see [JSON Web Token Structure](/tokens/references/jwt-structure).
+
+::: note
+It's good practice to assume that multiple signing keys could be present in your JWKS. This may seem unnecessary since the Auth0 JWKS endpoint typically contains a single signing key; however, multiple keys can be found in the JWKS when rotating signing certificates.
+:::
+
+::: panel Best Practice
+You can cache your signing keys to improve application performance and avoid running into [rate limits](/policies/rate-limits), but you will want to make sure that if decoding a token fails, you invalidate the cache and retrieve new signing keys before trying **only one** more time.
+:::
+
+## Keep reading
+
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [Validate a JSON Web Token](/tokens/guides/validate-jwt)
+* [Backend/API Quickstarts](/quickstart/backend)
diff --git a/fr-ca/articles/tokens/guides/manage-signing-keys.md b/fr-ca/articles/tokens/guides/manage-signing-keys.md
new file mode 100644
index 0000000000..a15dd9ebb5
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/manage-signing-keys.md
@@ -0,0 +1,92 @@
+---
+description: Learn how to manage your tenant's application signing key, which is used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions that are sent to your application.
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+  - assertions
+  - SAML
+- signing-keys
+  - certificates
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - add-login
+  - secure-api
+---
+
+# Manage Signing Keys
+
+When you select our recommended [signing algorithm](/tokens/concepts/signing-algorithms) (RS256), Auth0 uses public-key cryptography to establish trust with your applications. In more general terms, we use a signing key that consists of a public and private key pair.
+
+When a user signs in to your application, we create a token that contains information about the user and sign the token using its private key before we send it back to your application. Auth0 secures the private key, which is unique per tenant.
+
+To verify that the token is valid and originated from Auth0, your application validates the token’s signature using the public key that we expose in the following ways:
+
+* your [tenant settings](/dashboard/reference/settings-tenant) in the Auth0 Dashboard
+* your tenant's [OpenID Connect discovery document](/tokens/guides/locate-jwks)
+
+For security purposes, you may manually rotate your signing key on a periodic basis.
+
+::: note
+We use the application signing key to sign assertions that are sent to applications. These assertions may include ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions that are sent to your application. Note that these keys are different from those used to sign interactions with connections, including signing SAML Requests to IdPs and encrypting responses from IdPs.
+
+By default, SAML assertions for IdP connections are signed, which we recommend. To get public keys you can use to configure the IdP, see [SAML Identity Provider Configuration: Signed Assertions](/protocols/saml/samlp#signed-assertions). 
+:::
+
+## Transition your application gracefully
+
+We have designed the rotation and revocation process to both support your personal preferences and promote a graceful transition for your application. If you prefer to update your application first, then rotate and revoke your key, you may do that. Alternatively, if you prefer to rotate your key, and then update your application and revoke your old key, you may also do that.
+
+For this reason, available keys include:
+
+* **Currently used**: Key that is currently being used to sign all new assertions.
+* **Previously used**: Key that was previously used, but has been rotated out. Assertions that were generated with this key will still work.
+* **Next in queue**: Key that is queued and will replace the current key when the application signing key is next rotated.
+
+::: warning
+Regardless of the method you use, you should always test on a development tenant before rotating application signing keys in production.
+:::
+
+## Rotate your signing key
+
+Auth0 allows you to manually rotate your application signing key on a periodic basis. So, for security purposes, any application that integrates with Auth0 should be prepared to handle key rotation regardless of how infrequently it may occur. If your application does not handle signing key rotation and attempts to use an expired signing key to verify a token, the authentication request will fail.
+
+Although Auth0 signs with only one signing key at a time, your tenant's [OpenID Connect discovery document](/tokens/guides/locate-jwks) always contains multiple keys. Specifically, it will always include both the current key and the next key, but it may also include the previous key if the previous key has not yet been revoked. To provide a seamless experience in case of emergency, your application should be able to use any of the keys specified in the document.
+
+You can rotate your application signing key using either the Auth0 Dashboard or Management API. To learn more, see [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys).
+
+::: warning
+All tokens signed with the previous key will still be valid until the previous key is revoked.
+
+Make sure you have updated your application with the new key before you revoke the previous key.
+:::
+
+## Manage your signing keys
+
+We provide other application security key management capabilities through both our Dashboard and Management API. Through the Management API and Dashboard, you can:
+
+* [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys)
+* [Revoke Signing Keys](/dashboard/guides/tenants/revoke-signing-keys)
+* [View Signing Keys](/dashboard/guides/tenants/view-signing-keys)
+
+In addition, the Dashboard allows you to view, copy, and download the signing certificates for your application signing keys. Additional application signing certificates links are as follows:
+
+* [CER](https://${account.namespace}/cer)
+* [PEM](https://${account.namespace}/pem)
+* [raw PEM](https://${account.namespace}/rawpem)
+* [PB7](https://${account.namespace}/pb7)
+* [Fingerprint](https://${account.namespace}/fingerprint)
+
+### Limitations
+
+* Rotating your signing key will be subject to a smaller rate limit than other API endpoints. To learn more, see [Rate Limits: Management API v2](/policies/rate-limits#management-api-v2).
+
+## Keep reading
+
+* [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys)
+* [Revoke Signing Keys](/dashboard/guides/tenants/revoke-signing-keys)
+* [View Signing Keys](/dashboard/guides/tenants/view-signing-keys)
+* [Locate JSON Web Key Sets (JWKS)](/tokens/guides/locate-jwks)
+* [Signing Algorithms](/tokens/concepts/signing-algorithms)
diff --git a/fr-ca/articles/tokens/guides/revoke-refresh-tokens.md b/fr-ca/articles/tokens/guides/revoke-refresh-tokens.md
new file mode 100644
index 0000000000..479b53b56b
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/revoke-refresh-tokens.md
@@ -0,0 +1,159 @@
+---
+title: Revoke Refresh Tokens
+description: Learn how to revoke a Refresh Token if it gets compromised using the Authentication API, the Management API, or the Auth0 Dashboard. 
+topics:
+  - access-tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Revoke Refresh Tokens
+
+Since Refresh Tokens never expire, it is essential to be able to revoke them in case they get compromised.
+
+For the Device Authorization Flow, the only way to force a device to reauthorize is to revoke the Refresh Token assigned to the device. To learn how, see [Unlink Devices from Users](/dashboard/guides/users/unlink-user-devices). Note that the device will not be forced to reauthorize until the current Access Token expires and the application tries to use the revoked Refresh Token.
+
+Auth0 handles token revocation as though the token has been potentially exposed to malicious adversaries. Therefore, each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant. This means that **all Refresh Tokens that have been issued for the same user, application, and audience will be revoked**.
+
+You can revoke a Refresh Token by:
+
+* Posting a request to [the Authentication API's /oauth/revoke endpoint](/api/authentication#revoke-refresh-token)
+* Posting a request to [the Management API's /api/v2/device-credentials endpoint](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) 
+* Using the [dashboard](${manage_url}).
+
+## Use the Authentication API
+
+To revoke a Refresh Token, you can send a `POST` request to `https://${account.namespace}/oauth/revoke`.
+
+Use the `/api/v2/device-credentials` endpoint to revoke Refresh Tokens. 
+
+::: note
+The `/oauth/revoke` endpoint revokes the entire grant not just a specific token.
+:::
+
+The API first validates the application credentials and then verifies whether the token was issued to the application making the revocation request.  If this validation fails, the request is refused, and the application is informed of the error. Next, the API invalidates the token. The invalidation takes place immediately, and the token cannot be used again after the revocation. Each revocation request invalidates all the tokens that have been issued for the same authorization grant.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/revoke",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData" : {
+      "mimeType": "application/json",
+      "text" : "{ \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"token\": \"YOUR_REFRESH_TOKEN\" }"
+    },
+    "headersSize" : 150,
+    "bodySize" : 0,
+    "comment" : ""
+}
+```
+
+Where:
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Your application's Client ID. The application should match the one the Refresh Token was issued for. |
+| `client_secret` | Your application's Client Secret. Required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications). |
+| `token` 
    Required | The Refresh Token you want to revoke. |
+
+The application should match the one for which the Refresh Token was issued.
+
+::: panel Revoke a token without the Client Secret
+For applications that cannot keep the Client Secret safe (e.g., native apps), the [Revoke endpoint](/api/authentication#revoke-refresh-token) supports access without the Client Secret. However, the application itself must have the property `tokenEndpointAuthMethod` set to `none`. You can change the `tokenEndpointAuthMethod` value, either from the UI ([Dashboard > Clients > Application Settings](${manage_url}/#/applications/${account.clientId}/settings)), or using the [Management API](/api/management/v2#!/Clients/patch_clients_by_id).
+:::
+
+If the request is valid, the Refresh Token is revoked, and the response is `HTTP 200`, with an empty response body. Otherwise, the response body contains the error code and description.
+
+```json
+{
+  "error": "invalid_request|invalid_client",
+  "error_description": "Description of the error"
+}
+```
+
+The possible responses are:
+
+| HTTP Status | Description |
+| --- | --- |
+| 200 | The Refresh Token is revoked, does not exist, or was not issued to the application making the revocation request. The response body is empty. |
+| 400 | The required parameters were not sent in the request (`"error": "invalid_request"`). |
+| 401 | The request is not authorized (`"error": "invalid_client"`). Check that the application credentials (`client_id` and `client_secret`) are present in the request and hold valid values. |
+
+## Use the Management API
+
+To revoke a Refresh Token using the Auth0 Management API, you need the `id` of the Refresh Token you wish to revoke. To obtain a list of existing Refresh Tokens, call the [List device credentials](/api/management/v2#!/Device_Credentials/get_device_credentials) endpoint, specifying `type=refresh_token` and `user_id` with an Access Token containing `read:device_credentials` scope. To narrow the results, you can also specify the `client_id` associated with the token (if known).
+
+```text
+GET https://${account.namespace}/api/v2/device-credentials?
+  type=refresh_token
+  &client_id=
+  &user_id=
+
+{
+  "Authorization":   "Bearer {your_access_token}"
+}
+```
+
+Response body:
+
+```text
+[
+  {
+    "id": "dcr_dFJiaAxbEroQ5xxx",
+    "device_name": "my-device" // the value of 'device' provided in the /authorize call when creating the token
+  }
+]
+```
+
+To revoke a __Refresh Token__, call the [Delete a device credential](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) endpoint with an Access Token containing `delete:device_credentials` scope and the value of `id` obtained above:
+
+```text
+DELETE https://${account.namespace}/api/v2/device-credentials/{id}
+
+{
+  "Authorization":   "Bearer {your_access_token}"
+}
+
+```
+
+The response will be an **HTTP 204**: The credential no longer exists.
+
+::: note
+When using Refresh Token rotation, If a previously invalidated token is used, the entire set of Refresh Tokens issued since that invalidated token was issued will immediately be revoked, requiring the end-user to re-authenticate.
+
+- Use the `/oauth/revoke` endpoint to revoke a Refresh Token. This endpoint revokes the entire grant not just a specific token.
+
+- Use the `/api/v2/device-credentials` endpoint to revoke Refresh Tokens configured for rotation.
+:::
+
+## Use the Dashboard
+
+Strictly speaking, the following process shows you how to revoke a user's authorized access to the application that issued the token. This renders the Refresh Token invalid, which is functionally identical to revoking the token itself.
+
+To do this, go to the [Users section](${manage_url}/#/users) of the [dashboard](${manage_url}). Click the name of the user to view their *Details* page.
+
+Select the *Authorized Applications* tab. This page lists all the applications to which the user has authorized access. Revoking an authorized application also revokes its associated Refresh Tokens.
+
+To revoke the user's access to an authorized application, and hence invalidate the Refresh Token, click **Revoke**.
+
+![Revoke a Refresh Token using the dashboard](/media/articles/tokens/dashboard-revoke-refresh-token.png)
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Refresh Tokens and Reuse Detection](/tokens/guides/configure-refresh-token-rotation#refresh-tokens-and-reuse-detection)
diff --git a/fr-ca/articles/tokens/guides/revoke-tokens.md b/fr-ca/articles/tokens/guides/revoke-tokens.md
new file mode 100644
index 0000000000..b6d495869f
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/revoke-tokens.md
@@ -0,0 +1,25 @@
+---
+description: Learn to use tokens to control user access.
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - add-login
+  - secure-api
+---
+
+# Revoke Tokens
+
+Once issued, Access Tokens and ID Tokens cannot be revoked in the same way as cookies with session ids for server-side sessions. 
+
+As a result, tokens should be issued for relatively short periods, and then [refreshed](/tokens/concepts/refresh-tokens) periodically if the user remains active.
+
+## Keep reading
+
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
+
diff --git a/fr-ca/articles/tokens/guides/use-access-tokens.md b/fr-ca/articles/tokens/guides/use-access-tokens.md
new file mode 100644
index 0000000000..decece8005
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/use-access-tokens.md
@@ -0,0 +1,65 @@
+---
+title: Use Access Tokens
+description: Learn how to use Access Tokens to call APIs.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+---
+
+# Use Access Tokens
+
+Access Tokens are used in token-based authentication to allow an application to access an API. For example, a Calendar application needs access to a Calendar API in the cloud so that it can read the user's scheduled events and create new events.
+
+Once an application has received an Access Token, it will include that token as a credential when making API requests. To do so, it should transmit the Access Token to the API as a **Bearer** credential in an HTTP **Authorization** header.
+
+For example:
+
+```text
+GET /calendar/v1/events
+Host​: api.example.com
+
+Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuYXV0aDAuY29tLyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1YiI6InVzcl8xMjMiLCJpYXQiOjE0NTg3ODU3OTYsImV4cCI6MTQ1ODg3MjE5Nn0.CA7eaHjIHz5NxeIJoFK9krqaeZrPLwmMmgI_XiQiIkQ
+```
+
+In this example, the Access Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) that decodes to the following [claims](/tokens/concepts/jwt-claims):
+
+```json
+{
+  "alg": "RS256",
+  "typ": "JWT"
+}
+.
+{
+  "iss": "https://example.auth0.com/",
+  "aud": "https://api.example.com/calendar/v1/",
+  "sub": "usr_123",
+  "scope": "read write",
+  "iat": 1458785796,
+  "exp": 1458872196
+}
+```
+
+Before permitting access to the API using this token, the API must [validate the Access Token](/tokens/guides/validate-access-tokens).
+
+Once the Access Token has been successfully validated, the API can be sure that:
+
+* The token was issued by Auth0.
+* The token was issued to an application being used by a user with an identifier of `usr_123`.
+* The user granted the application access to read from and write to their calendar.
+
+The API can now process the request, allowing the application to read from and write to user `usr_123`'s calendar.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Get Access Tokens](/tokens/guides/get-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/fr-ca/articles/tokens/guides/use-refresh-token-rotation.md b/fr-ca/articles/tokens/guides/use-refresh-token-rotation.md
new file mode 100644
index 0000000000..2a954f8834
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/use-refresh-token-rotation.md
@@ -0,0 +1,67 @@
+---
+title: Use Refresh Token Rotation
+description: Learn how to use Refresh Token rotation for you received during authorization.
+topics:
+  - refresh-tokens
+  - refresh-token-rotation
+contentType:
+  - how-to
+useCase:
+  - use-refresh-token-rotation
+---
+# Use Refresh Token Rotation
+
+To use Refresh Token rotation, you will use the [Auth0 Single Page App SDK](/libraries/auth0-spa-js). The Auth0 SPA SDK handles token storage, session management, and other details for you.
+
+## Prerequisite
+
+[Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+
+## Enable useRefreshTokens
+
+<%= include('../_includes/_rtr_enabled') %>
+
+Use the option `useRefreshTokens` on `createAuth0Client` which defaults to `false`. With this option set to `false`, when `getTokenSilently()` is invoked and a new Access Token is required, the SDK attempts to acquire a new Access Token using a hidden iframe and `prompt=none`.
+
+If you set to this option to `true`, the `offline_access` scope is automatically requested when using `loginWithRedirect(), loginWithPopup()` and `getTokenSilently()`. When `getTokenSilently()` is invoked and the Access Token has expired, the SDK attempts to renew the ID and Access Tokens by calling the `/token` endpoint using the `refresh_token` grant type along with the Refresh Token from the cache.
+
+Silent re-authentication is achieved by sending a `prompt=none` parameter upon the authentication request and using a hidden iframe, provided that there is an active user session on the authorization server. The SDK uses the iframe method if you have set `useRefreshTokens` to `true` but no Refresh Token is available in the cache. This helps users to silently migrate to using Refresh Tokens without making them log in again.
+
+::: note
+If the exchange fails because `useRefreshTokens` is `true` but there isn't a Refresh Token in the cache, then it falls back to the iframe method (which could also fail if third-party cookies are blocked).
+:::
+
+For more details and examples, see [Use rotating Refresh Tokens](/libraries/auth0-spa-js#use-rotating-refresh-tokens). 
+
+## Token storage
+
+With SPAs, ID and Access Tokens are obtained from the authorization server and typically cached in memory. Token renewal (due to refreshing the browser, memory cache eviction budgets, or expiration) is handled by the SDK. See [Token Storage](/tokens/concepts/token-storage) for details. 
+
+## Example
+
+The following example shows how to configure the SDK to use both local storage and refresh tokens:
+
+```js
+const auth0 = await createAuth0Client({
+    domain: '',
+    client_id: '',
+    cacheLocation: 'localstorage',
+    useRefreshTokens: true
+});
+
+// Logging-in will automatically request the offline_access scope
+// and store the resulting refresh token
+auth0.loginWithRedirect();
+
+// Silently refreshing the access token will use the /token endpoint
+// with ‘refresh_token’ grant and the refresh token from the cache
+await auth0.getTokenSilently();
+```
+
+## Keep reading
+
+* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation)
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Token Storage](/tokens/concepts/token-storage)
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/guides/use-refresh-tokens.md b/fr-ca/articles/tokens/guides/use-refresh-tokens.md
new file mode 100644
index 0000000000..7a43aacab0
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/use-refresh-tokens.md
@@ -0,0 +1,75 @@
+---
+title: Use Refresh Tokens
+description: Learn how to use a Refresh Token you received during authorization.
+topics:
+  - refresh-tokens
+contentType:
+  - how-to
+useCase:
+  - use-refresh-tokens
+---
+# Use Refresh Tokens
+
+To exchange the Refresh Token you received during authorization for a new Access Token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/token",
+    "headers": [
+      { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+    ],
+    "postData" : {
+      "mimeType": "application/x-www-form-urlencoded",
+      "params": [
+        {
+          "name": "grant_type",
+          "value": "refresh_token"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        },
+        {
+          "name": "refresh_token",
+          "value": "YOUR_REFRESH_TOKEN"
+        }
+      ]
+    }
+}
+```
+
+| Attriburte | Description |
+| - | - |
+| `grant_type` | The type of grant to execute (the `/token` endpoint is used for various grants, for more information refer to the [Authentication API](/api/authentication#get-token)). To refresh a token, use `refresh_token` |
+| `client_id` | Your application's Client ID |
+| `client_secret` | Optional. Your application's Client Secret. Only required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications) |
+| `refresh_token` | The Refresh Token to use |
+
+The response will include a new Access Token, its type, its lifetime (in seconds), and the granted scopes. If the scope of the initial token included `openid`, then a new ID Token will be in the response as well.
+
+```json
+{
+  "access_token": "eyJ...MoQ",
+  "expires_in": 86400,
+  "scope": "openid offline_access",
+  "id_token": "eyJ...0NE",
+  "token_type": "Bearer"
+}
+```
+
+::: panel Rate limits
+You should only ask for a new token if the Access Token has expired or you want to refresh the claims contained in the ID Token. For example, it's a bad practice to call the endpoint to get a new Access Token every time you call an API. There are rate limits in Auth0 that will throttle the number of requests to this endpoint that can be executed using the same token from the same IP.
+:::
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/guides/validate-access-tokens.md b/fr-ca/articles/tokens/guides/validate-access-tokens.md
new file mode 100644
index 0000000000..baf23003a7
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/validate-access-tokens.md
@@ -0,0 +1,93 @@
+---
+title: Validate Access Token
+description: Learn how to validate an Access Token.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - access-tokens
+  - authorization
+contentType: 
+  - tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Validate Access Tokens
+
+::: note
+This document discusses validation of Access Tokens issued by Auth0. If you have received an Access Token from an [Identity Provider (IdP)](/identityproviders), in general, you don't need to validate it. You can pass it to the issuing IdP, and the IdP takes care of the rest.
+:::
+
+An Access Token is a credential that can be used by an application to access an API. Before you can validate an [Access Token](/tokens/concepts/access-tokens), you first need to know the format of the token. Auth0 issues Access Tokens in two formats: opaque and [JSON Web Token (JWT)](/tokens/concepts/jwts).
+
+::: warning
+Remember that an Access Token is meant for an API and should be validated only by the API for which it was intended. Client applications should not depend on the Access Token to be any specific format, and instead treat it as if it is opaque (regardless of whether it actually is).
+:::
+
+## Opaque Access Tokens
+
+Opaque Access Tokens can be used with the [`/userinfo` endpoint](/api/authentication#get-user-info) to return a user's profile. If you receive an opaque Access Token, you don't need to validate it. You can use it with the `/userinfo` endpoint, and Auth0 takes care of the rest. 
+
+To learn more about getting an opaque Access Token for the `userinfo` endpoint, see [Get Access Tokens](/tokens/guides/get-access-tokens#opaque-access-tokens).
+
+## JWT Access Tokens
+
+Access Tokens issued for the Auth0 Management API and Access Tokens issued for any custom API that you have registered with Auth0 will always be [JSON Web Tokens](/tokens/concepts/jwts).
+
+### Auth0 Management API Access Tokens
+
+An Access Token issued for the Auth0 Management API should be treated as opaque (regardless of whether it actually is), so you don't need to validate it. You can use it with the Auth0 Management API, and Auth0 takes care of the rest. 
+
+To learn more about getting an Access Token for the Auth0 Management API, see [Auth0 Management API Tokens](/api/management/v2/tokens).
+
+### Custom API Access Tokens
+
+::: warning
+If validation of your Custom API Access Token fails, make sure it was issued with your custom API as the `audience`. To learn more about getting an Access Token for your Custom API, see [Get an Access Token: Control Access Token Audience](/tokens/guides/get-access-tokens#control-access-token-audience).
+:::
+
+To validate a JWT issued for a custom API that you have registered with Auth0, you will need to:
+
+1. Perform standard JWT validation
+2. Check additional standard claims
+3. Check permissions (scopes)
+
+If any of these checks fail, the token is considered invalid, and the request must be rejected.
+
+#### Perform standard JWT validation
+
+Because the Access Token is a JWT, you will first need to perform the standard JWT validation steps. To learn about JWT validation, see [Validate JSON Web Tokens](/tokens/guides/validate-jwts).
+
+#### Check additional standard claims
+
+If you've performed the standard JWT validation, you have already decoded the [JWT's Payload](/tokens/references/jwt-structure#payload) and looked at its standard claims. Some additional claims to verify for Access Tokens include:
+
+* **Token audience** (`aud`, array of strings): Depending on the initial token request, the `aud` field could contain both an audience corresponding to your custom API and an audience corresponding to the `userinfo`endpoint. At least one of the audience values for the token must match the unique identifier of the target API as defined in your [API's Settings](${manage_url}/#/apis) in the **Identifier** field. To learn more about getting Access Tokens with multiple audiences, see [Get an Access Token](/tokens/guides/get-access-tokens).
+
+If this check fails, the token is considered invalid, and the request must be rejected.
+
+#### Check permissions
+
+The final step is to verify that the Application has been granted the permissions required to access your API. To do so, you will need to check an additional claim in the decoded JWT's Payload:
+
+* **Scopes** (`scope`, space-separated list of strings): Should match the permissions required for the endpoint being accessed.
+
+For example, say your custom API provides three endpoints to read, create, or delete a user record: `/create`, `/read`, and `/delete`. When you [registered your API with Auth0](/getting-started/set-up-api), you created three corresponding permissions:
+
+- `create:users` provides access to the `/create` endpoint
+- `read:users` provides access to the `/read` endpoint
+- `delete:users` provides access to the `/delete` endpoint
+
+In this case, if an Application requests to access the `/create` endpoint, but the Access Token's `scope` claim does not include the value `create:users`, then the API should reject the request with `403 Forbidden`.
+
+For an example using a simple timesheet API in Node.js, see [Architecture Scenarios: Server Client + API - Node.js API Implementation](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-client-permissions), an implementation of a Client Credentials grant for a hypothetical scenario. To see the complete solution, visit [Architecture Scenarios: Server Client + API](/architecture-scenarios/application/server-api).
+
+## Keep reading
+
+- [RFC 7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519)
+- [JSON Web Tokens](/tokens/concepts/jwts)
+- [APIs in Auth0](/apis)
+- [Tokens](/tokens)
+- [Architecture Scenarios: Server Client + API - Node.js API Implementation](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-application-permissions)
+- [How to implement API authentication and authorization scenarios](/api-auth)
diff --git a/fr-ca/articles/tokens/guides/validate-id-tokens.md b/fr-ca/articles/tokens/guides/validate-id-tokens.md
new file mode 100644
index 0000000000..0d743a1c98
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/validate-id-tokens.md
@@ -0,0 +1,34 @@
+---
+title: Validate ID Tokens
+description: Learn how to validate an ID Token.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Validate ID Tokens 
+
+An [ID Token](/tokens/concepts/id-tokens), which contains user profile attributes, is consumed by an app and is typically used for user interface display. Auth0 issues all ID Tokens in [JSON Web Token (JWT)](/tokens/concepts/jwts) format.
+
+::: warning
+If any of these checks fail, the token is considered invalid, and the request must be rejected.
+:::
+
+1. [Validate the JSON Web Token](/tokens/guides/validate-jwts). 
+
+2. Check additional standard claims. If you've performed the standard JWT validation, you have already decoded the [JWT's Payload](/tokens/references/jwt-structure#payload) and looked at its standard claims. Additional claims to verify for ID Tokens include:
+
+    * **Token audience** (`aud`, string): The audience value for the token must match the client ID of the application as defined in your [Application's Settings](${manage_url}/#/applications) in the **Client ID** field.
+    * **Nonce** (`nonce`, string): Passing a nonce in the token request is recommended (required for the [Implicit Flow](/flows/concepts/implicit)) to help prevent replay attacks. The nonce value in the token must exactly match the original nonce sent in the request. To learn more how to use nonces in token requests, see [Mitigate Replay Attacks](/api-auth/tutorials/nonce).
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Invalid Token Errors](/troubleshoot/references/invalid-token)
diff --git a/fr-ca/articles/tokens/guides/validate-jwts.md b/fr-ca/articles/tokens/guides/validate-jwts.md
new file mode 100644
index 0000000000..2099af5dce
--- /dev/null
+++ b/fr-ca/articles/tokens/guides/validate-jwts.md
@@ -0,0 +1,122 @@
+---
+title: Validate JSON Web Tokens
+description: Learn how to parse and validate a JSON Web Token (JWT).
+topics:
+  - jwt
+  - tokens
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# Validate JSON Web Tokens
+
+::: note
+This document is intended for developers implementing a regular web, native, or SPA application. All of our [backend API quickstarts](/quickstart/backend) use SDKs that perform JWT validation and parsing for you.
+
+If you'd like to visually inspect a JWT, visit [JWT.io](https://jwt.io/) or use the [JWT Debugger Chrome Extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd?hl=en)).
+:::
+
+To parse and validate a JSON Web Token (JWT), you can:
+
+* Use any existing [middleware](#middleware) for your web framework.
+* Choose a [third-party library](#third-party-libraries) from [JWT.io](https://jwt.io/#libraries-io).
+* [Manually implement the checks](#manually-implement-the-checks) described in [specification RFC 7519 > 7.2 Validating a JWT](https://tools.ietf.org/html/rfc7519#section-7.2).
+
+::: warning
+We strongly recommend that you use middleware or one of the existing open source third-party libraries to parse and validate JWTs. At [JWT.io](https://jwt.io/#libraries-io), you can find libraries for various platforms and languages, such as .NET, Python, Java, Ruby, Objective-C, Swift, and PHP.
+:::
+
+## Middleware
+
+Many web frameworks, such as [ASP.NET Core](/quickstart/backend/aspnet-core-webapi), include JWT middleware that handles JWT validation. Typically, this is the best route to take because the middleware integrates well with the framework's overall authentication mechanisms.
+
+## Third-party libraries
+
+If you choose a third-party library, remember to pick a library that supports the [signing algorithm](/tokens/concepts/signing-algorithms) you selected when you registered your application or API with Auth0. Also, be aware that not all libraries validate all JWT claims. At [JWT.io](https://jwt.io/), you can see which validations each library supports (look for the green check marks).
+
+Most third-party libraries will implement one method to verify a JWT and build in various arguments to allow you to customize the verification.
+
+For example, if you are using Node.js and the [node-jsonwebtoken library](https://github.com/auth0/node-jsonwebtoken), then you would call the [jwt.verify()](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback) method. This method supports an `algorithms` argument to allow you to customize your allowed algorithms (make sure you disallow `none`), a `secretOrPublicKey` argument that you populate with either the secret or the RSA public key (depending on selected signing algorithm), and other input arguments that allow you to customize claim validation. If parsing fails, then the library returns a [JsonWebTokenError error](https://github.com/auth0/node-jsonwebtoken#jsonwebtokenerror) with the message `jwt malformed`, after which you **must** reject the associated request.
+
+## Manually implement the checks
+
+::: note
+All Auth0-issued JSON Web Tokens (JWTs) are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, this section describes validation for JWSs. If you need to validate a JSON Web Encryption (JWE), see [RFC 7519](https://tools.ietf.org/html/rfc7519#section-7.2) for instructions specific to that type of JWT.
+:::
+
+To validate a JWT, your application needs to:
+
+1. Check that the JWT is well formed.
+2. Check the signature.
+3. Check the standard claims.
+
+If any of these steps fail, then the associated request must be rejected.
+
+::: note
+Most JWT libraries take care of JWT validation for you, so be sure to visit [JWT.io](https://jwt.io/#libraries-io) to find a JWT library for your platform and programming language.
+:::
+
+## Check that the JWT is well-formed
+
+Ensure that the JWT conforms to the [structure of a JWT](/tokens/references/jwt-structure). If this fails, the token is considered invalid, and the request must be rejected.
+
+1. Verify that the JWT contains three segments, separated by two period ('.') characters.
+2. Parse the JWT to extract its three components. The first segment is the Header, the second is the Payload, and the third is the Signature. Each segment is base64url encoded.
+3. Base64url-decode the Header, ensuring that no line breaks, whitespace, or other additional characters have been used, and verify that the decoded Header is a valid JSON object.
+4. Base64url-decode the Payload, ensuring that no line breaks, whitespace, or other additional characters have been used, and verify that the decoded Payload is a valid JSON object.
+
+## Check the signature
+
+The last segment of a JWT is the Signature, which is used to verify that the token was signed by the sender and not altered in any way. The Signature is created using the Header and Payload segments, a [signing algorithm](/tokens/concepts/signing-algorithms), and a secret or public key (depending on the chosen signing algorithm).
+
+To verify the signature, you will need to:
+
+1. Check the signing algorithm.
+
+    1. Retrieve the `alg` property from the decoded Header.
+    2. Ensure that it is an allowed algorithm. Specifically, to avoid certain attacks, make sure you disallow `none`.
+    3. Check that it matches the algorithm you selected when you [registered your Application](/getting-started/set-up-app) or [API](/getting-started/set-up-api) with Auth0.
+2. Confirm that the token is correctly signed using the proper key.
+
+    To verify that the signature is correct, you need to generate a new Base64url-encoded signature using the public key (RS256) or secret (HS256) and verify that it matches the original Signature included with the JWT:
+
+    1. Take the original Base64url-encoded Header and original Base64url-encoded Payload segments (Base64url-encoded Header + "." + Base64url-encoded Payload), and hash them with SHA-256.
+    2. Encrypt using either HMAC or RSA (depending on your selected signing algorithm) and the appropriate key.
+    3. Base64url-encode the result.
+
+    ::: panel Locate Public Key
+
+    For RS256:
+    Retrieve the public key from the [JWKS](/tokens/concepts/jwks) located by using your [Auth0 discovery endpoint](/tokens/guides/locate-jwks).
+
+    For debugging purposes, you can visually inspect your token at [jwt.io](jwt.io); for this purpose, you can also locate your public key in the Auth0 Dashboard. Look in **Applications**>**Settings**>**Advanced Settings**>**Certificates** and locate the **Signing Certificate** field.
+
+    For HS256:
+    Retrieve the `client_secret` from Auth0's Management API using the [Get a Client endpoint](/api/management/v2/#!/Clients/get_clients_by_id). 
+
+    For debugging purposes, you can visually inspect your token at [jwt.io](jwt.io); for this purpose, you can also locate your secret in the Auth0 Dashboard. For applications, look in **Settings** and locate the **Client Secret** field. For APIs, look in **Settings** and locate the **Signing Secret** field. (Note that this field is only displayed for APIs using the HS256 [signing algorithm](/tokens/concepts/signing-algorithms).)
+    :::
+
+    If the generated signature does not match the original Signature included with the JWT, the token is considered invalid, and the request must be rejected.
+
+## Check standard claims
+
+Before using the token, you should retrieve the following standard claims from the decoded Payload and perform the following checks:
+
+* **Token expiration** (`exp`, Unix timestamp): The expiration date/time must be after the current date/time.
+* **Token issuer** (`iss`, string): The issuing authority inside the token must match the issuing authority (`issuer`) identified in your Auth0 tenant's discovery document, which exists at `https://${account.namespace}/.well-known/openid-configuration`.
+
+Additional checks are required depending on whether the JWT you are validating is an ID Token or an Access Token. To learn about the additional requirements, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) or [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JSON Web Key Set](/tokens/concepts/jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/fr-ca/articles/tokens/index.md b/fr-ca/articles/tokens/index.md
new file mode 100644
index 0000000000..b8eefdde25
--- /dev/null
+++ b/fr-ca/articles/tokens/index.md
@@ -0,0 +1,92 @@
+---
+title: Tokens
+description: Learn about the types of tokens related to identity and authentication and how they are used by Auth0.
+classes: topic-page
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+  - idp-access-tokens
+  - managment-api-tokens
+contentType:
+  - index
+useCase:
+  - tokens
+---
+# Tokens
+
+There are basically two main types of tokens that are related to identity: ID Tokens and Access Tokens. 
+
+## ID Tokens
+
+[ID Tokens](/tokens/concepts/id-tokens) are [JSON Web Tokens (JWTs)](/tokens/concepts/jwts) meant for use by the application only. For example, if there's an app that uses Google to log in users and to sync their calendars, Google sends an ID Token to the app that includes information about the user. The app then parses the [token's contents](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and uses the information (including details like name and profile picture) to customize the user experience.
+
+<%= include('./_includes/_validate-id-token') %>
+
+ID Tokens should *not* be used to gain access to an API. Each token contains information for the intended audience (which is usually the recipient). Per the OpenID Connect specification, the audience of the ID Token (indicated by the **aud** claim) must be the **client ID** of the application making the authentication request. If this is not the case, you should not trust the token. Conversely, an API expects a token with the **aud** value to equal the API's unique identifier. Therefore, unless you maintain control over both the application and the API, sending an ID Token to an API will generally not work. Since the ID Token is not signed by the API, the API would have no way of knowing if the application had modified the token (e.g., adding more scopes) if it were to accept the ID Token. See the [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook) for more information.
+
+## Access Tokens
+
+[Access Tokens](/tokens/concepts/access-tokens) (which aren't always JWTs) are used to inform an API that the bearer of the token has been authorized to access the API and perform a predetermined set of actions (specified by the **scopes** granted). 
+
+In the Google example above, Google sends an Access Token to the app after the user logs in and provides consent for the app to read or write to their Google Calendar. Whenever the app wants to write to Google Calendar, it sends a request to the Google Calendar API, including the Access Token in the HTTP **Authorization** header.
+
+Access Tokens must *never* be used for authentication. Access Tokens cannot tell if the user has authenticated. The only user information the Access Token possesses is the user ID, located in the **sub** claim.
+
+Your applications should treat Access Tokens as *opaque strings* since they are meant for APIs. Your application should *not* attempt to decode them or expect to receive tokens in a particular format.
+
+## Token examples
+
+To better clarify the concepts we covered above, let's look at the contents of some sample ID and Access Tokens.
+
+The decoded contents of a sample ID Token looks like the following:
+
+```json
+{
+  "iss": "http://${account.namespace}/",
+  "sub": "auth0|123456",
+  "aud": "${account.clientId}",
+  "exp": 1311281970,
+  "iat": 1311280970,
+  "name": "Jane Doe",
+  "given_name": "Jane",
+  "family_name": "Doe",
+  "gender": "female",
+  "birthdate": "0000-10-31",
+  "email": "janedoe@example.com",
+  "picture": "http://example.com/janedoe/me.jpg"
+}
+```
+
+This token **authenticates the user to the application**. The audience (the **aud** claim) of the token is set to the application's identifier, which means that only this specific application should consume this token.
+
+For comparison, let's look at the contents of an Access Token:
+
+```json
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|123456",
+  "aud": [
+    "my-api-identifier",
+    "https://${account.namespace}/userinfo"
+  ],
+  "azp": "${account.clientId}",
+  "exp": 1489179954,
+  "iat": 1489143954,
+  "scope": "openid profile email address phone read:appointments"
+}
+```
+
+Note that the token does not contain any information about the user itself besides their ID (**sub** claim). It only contains authorization information about which actions the application is allowed to perform at the API (**scope** claim). This is what makes it useful for securing an API, but not for authenticating a user.
+
+In many cases, you might find it useful to retrieve additional user information at the API, so the Access Token is also valid for calling [the /userinfo API](/api/authentication#user-profile), which returns the user's profile information. The intended audience (indicated by the **aud** claim) for this token is both your custom API as specified by its identifier (such as `https://my-api-identifier`) and the **/userinfo** endpoint (such as `https://${account.namespace}/userinfo`).
+
+## Other specialized tokens used by Auth0
+
+There are three specialized tokens used in Auth0's token-based authentication scenarios:
+
+<%= include('../_includes/_topic-links', { links: [
+  'tokens/concepts/idp-access-tokens',
+  'tokens/concepts/refresh-tokens',
+  'api/management/v2/tokens'
+] }) %>
diff --git a/fr-ca/articles/tokens/references/id-token-structure.md b/fr-ca/articles/tokens/references/id-token-structure.md
new file mode 100644
index 0000000000..c8808ea8ad
--- /dev/null
+++ b/fr-ca/articles/tokens/references/id-token-structure.md
@@ -0,0 +1,39 @@
+---
+title: ID Token Structure
+description: Describes how ID Tokens conform to the JWT standard and contain JWT claims asserted about the token itself, standard OIDC claims about the authenticated user, and custom claims that you define, control, and add to a token using a rule.
+topics:
+  - tokens
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# ID Token Structure
+
+ID Tokens follow the [JSON Web Token (JWT)](/tokens/concepts/jwts) standard, which means that their basic structure conforms to the typical [JWT Structure](/tokens/references/jwt-structure), and they contain standard [JWT Claims](/tokens/concepts/jwt-claims) asserted about the token itself.
+
+However, beyond what is required for JWT, ID Tokens also contain claims asserted about the authenticated user, which are pre-defined by the [OpenID Connect (OIDC)](/protocols/oidc) protocol, and are thus known as standard OIDC claims. Some standard OIDC claims include:
+
+* `name`
+* `nickname`
+* `picture`
+* `email`
+* `email_verified`
+
+For a full list of standard OIDC claims, see [OIDC specification: Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
+
+You control which OIDC claims are included in the ID Token consumed by your application by including specific [OpenID Connect Scopes](/scopes/oidc-scopes) in a parameter when you request tokens while authenticating users. To learn how to request an ID Token, see [Get ID Tokens](/tokens/guides/get-id-tokens).
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a [rule](/rules). 
+:::
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Token Storage](/tokens/concepts/token-storage)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [Revoke Tokens](/tokens/guides/revoke-tokens)
diff --git a/fr-ca/articles/tokens/references/jwks-properties.md b/fr-ca/articles/tokens/references/jwks-properties.md
new file mode 100644
index 0000000000..ea229c7aff
--- /dev/null
+++ b/fr-ca/articles/tokens/references/jwks-properties.md
@@ -0,0 +1,62 @@
+---
+title: JSON Web Key Set Properties
+description: Describes the properties available in a JSON Web Key Set (JWKS).
+toc: false
+topics:
+  - tokens
+  - jwks
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+---
+# JSON Web Key Set Properties
+
+Here is an example of the JSON Web Key Set (JWKS) used by a sample tenant, containing a single JSON Web Key (JWK):
+
+```json
+{
+"keys": [
+  {
+    "alg": "RS256",
+    "kty": "RSA",
+    "use": "sig",
+    "x5c": [
+      "MIIC+DCCAeCgAwIBAgIJBIGjYW6hFpn2MA0GCSqGSIb3DQEBBQUAMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTAeFw0xNjExMjIyMjIyMDVaFw0zMDA4MDEyMjIyMDVaMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnjZc5bm/eGIHq09N9HKHahM7Y31P0ul+A2wwP4lSpIwFrWHzxw88/7Dwk9QMc+orGXX95R6av4GF+Es/nG3uK45ooMVMa/hYCh0Mtx3gnSuoTavQEkLzCvSwTqVwzZ+5noukWVqJuMKNwjL77GNcPLY7Xy2/skMCT5bR8UoWaufooQvYq6SyPcRAU4BtdquZRiBT4U5f+4pwNTxSvey7ki50yc1tG49Per/0zA4O6Tlpv8x7Red6m1bCNHt7+Z5nSl3RX/QYyAEUX1a28VcYmR41Osy+o2OUCXYdUAphDaHo4/8rbKTJhlu8jEcc1KoMXAKjgaVZtG/v5ltx6AXY0CAwEAAaMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUQxFG602h1cG+pnyvJoy9pGJJoCswDQYJKoZIhvcNAQEFBQADggEBAGvtCbzGNBUJPLICth3mLsX0Z4z8T8iu4tyoiuAshP/Ry/ZBnFnXmhD8vwgMZ2lTgUWwlrvlgN+fAtYKnwFO2G3BOCFw96Nm8So9sjTda9CCZ3dhoH57F/hVMBB0K6xhklAc0b5ZxUpCIN92v/w+xZoz1XQBHe8ZbRHaP1HpRM4M7DJk2G5cgUCyu3UBvYS41sHvzrxQ3z7vIePRA4WF4bEkfX12gvny0RsPkrbVMXX1Rj9t6V7QXrbPYBAO+43JvDGYawxYVvLhz+BJ45x50GFQmHszfY3BR9TPK8xmMmQwtIvLu1PMttNCs7niCYkSiUv2sc2mlq1i3IashGkkgmo="
+    ],
+    "n": "yeNlzlub94YgerT030codqEztjfU_S6X4DbDA_iVKkjAWtYfPHDzz_sPCT1Axz6isZdf3lHpq_gYX4Sz-cbe4rjmigxUxr-FgKHQy3HeCdK6hNq9ASQvMK9LBOpXDNn7mei6RZWom4wo3CMvvsY1w8tjtfLb-yQwJPltHxShZq5-ihC9irpLI9xEBTgG12q5lGIFPhTl_7inA1PFK97LuSLnTJzW0bj096v_TMDg7pOWm_zHtF53qbVsI0e3v5nmdKXdFf9BjIARRfVrbxVxiZHjU6zL6jY5QJdh1QCmENoejj_ytspMmGW7yMRxzUqgxcAqOBpVm0b-_mW3HoBdjQ",
+    "e": "AQAB",
+    "kid": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg",
+    "x5t": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg"
+  }
+]}
+```
+
+Each property in the key is defined by the JWK specification [RFC 7517 Section 4](https://tools.ietf.org/html/rfc7517#section-4) or, for algorithm-specific properties, in [RFC 7518](https://tools.ietf.org/html/rfc7518)].
+
+| Property name | Description                |
+|---------------|----------------------------|
+| `alg`         | The specific cryptographic algorithm used with the key. |
+| `kty`         | The family of cryptographic algorithms used with the key. |
+| `use`         | How the key was meant to be used; `sig` represents the signature. |
+| `x5c`         | The x.509 certificate chain. The first entry in the array is the certificate to use for token verification; the other certificates can be used to verify this first certificate.|
+| `n`           | The modulus for the [RSA public key](https://tools.ietf.org/html/rfc7518#page-30). |
+| `e`           | The exponent for the [RSA public key](https://tools.ietf.org/html/rfc7518#page-30). |
+| `kid`         | The unique identifier for the key. |
+| `x5t`         | The thumbprint of the x.509 cert (SHA-1 thumbprint). |
+
+::: note
+Auth0 only supports HMAC and RSA; it does not currently support Elliptic Curve encryption (ECDSA).
+:::
+
+For an example that uses JWKS to verify a JWT's signature, check out our [Backend/API Quickstarts](/quickstart/backend).
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Token Key Sets](/tokens/guides/locate-jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
\ No newline at end of file
diff --git a/fr-ca/articles/tokens/references/jwt-structure.md b/fr-ca/articles/tokens/references/jwt-structure.md
new file mode 100644
index 0000000000..a1d3af35dd
--- /dev/null
+++ b/fr-ca/articles/tokens/references/jwt-structure.md
@@ -0,0 +1,100 @@
+---
+title: JSON Web Token Structure
+description: Understand how JSON Web Tokens (JWTs) are structured.
+toc: true
+topics:
+  - tokens
+  - jwt
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+
+# JSON Web Token Structure
+
+::: note
+All Auth0-issued JSON Web Tokens (JWTs) are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, this document describes the JWS structure of a JWT.
+:::
+
+A well-formed JSON Web Token (JWT) consists of three concatenated Base64url-encoded strings, separated by dots (`.`): 
+
+- **Header**: contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+- **Payload** (set of [claims](/tokens/concepts/jwt-claims)): contains verifiable security statements, such as the identity of the user and the permissions they are allowed.
+- **Signature**: used to validate that the token is trustworthy and has not been tampered with. You must [verify this signature](/tokens/guides/validate-id-tokens#verify-the-signature) before storing and using a JWT.
+
+A JWT typically looks like this:
+![Encoded JWT](/media/articles/jwt/encoded-jwt3.png)
+
+To see for yourself what is inside a JWT, use the [JWT.io Debugger](http://jwt.io). It will allow you to quickly check that a JWT is well formed and manually inspect the values of the various claims.
+
+![JWT.IO Debugger](/media/articles/jwt/legacy-app-auth-5.png)
+
+::: panel Where can I find my secret or public key?
+
+For RS256:
+1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view.
+2. Scroll to the bottom of the page, click **Advanced Settings**, and click the **Certificates** tab. You will find the Public Key in the **Signing Certificate** field.
+
+For HS256:
+1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. You will find your Secret in the **Client Secret** field.
+:::
+
+## Header
+
+The header *typically* consists of two parts: the hashing algorithm being used (e.g., HMAC SHA256 or RSA) and the type of the token (JWT).
+
+```
+{
+  "alg": "HS256",
+  "typ": "JWT"
+}
+```
+
+
+## Payload
+
+The payload contains statements about the entity (typically, the user) and additional entity attributes, which are called [claims](/tokens/concepts/jwt-claims). In this example, our entity is a user.
+
+```
+{
+  "sub": "1234567890",
+  "name": "John Doe",
+  "admin": true
+}
+```
+
+::: note
+When working with [JWT claims](https://tools.ietf.org/html/rfc7519#section-4), you should be aware of the different [claim types and naming rules](/tokens/concepts/jwt-claims). 
+:::
+
+
+## Signature
+
+The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
+
+To create the signature, the Base64-encoded header and payload are taken, along with a secret, and signed with the algorithm specified in the header.
+
+For example, if you are creating a signature for a token using the HMAC SHA256 algorithm, you would do the following:
+
+```
+HMACSHA256(
+  base64UrlEncode(header) + "." +
+  base64UrlEncode(payload),
+  secret)
+```
+
+::: warning
+How ever you use a JWT, you must [check its signature](/tokens/guides/validate-jwts) before storing and using it.
+:::
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Token Key Sets](/tokens/guides/locate-jwks)
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/fr-ca/articles/topics/guides/index.md b/fr-ca/articles/topics/guides/index.md
new file mode 100644
index 0000000000..ee6731da0f
--- /dev/null
+++ b/fr-ca/articles/topics/guides/index.md
@@ -0,0 +1,34 @@
+---
+classes: topic-page
+title: Guides
+description: Helpful docs for implementing Auth0
+topics:
+  - architecture
+  - tokens
+  - user-management
+  - users
+  - mfa
+  - email
+  - guides
+contentType: index
+useCase: development
+---
+
+
    
+  
    
+  
    Guides
    
+  
    
+    In addition to the docs featured on the documentation homepage, there are other materials many find useful. The following is a list of commonly-used docs, guides, and tutorials you may find helpful as you implement Auth0.
+  
    
+
    
+
+<%= include('../../_includes/_topic-links', { links: [
+  'architecture-scenarios',
+  'tokens',
+  'users',
+  'mfa',
+  'integrations',
+  'flows',
+  'product-lifecycle',
+  'best-practices'
+] }) %>
diff --git a/fr-ca/articles/troubleshoot/_includes/_log_events_link.md b/fr-ca/articles/troubleshoot/_includes/_log_events_link.md
new file mode 100644
index 0000000000..36c5fa4a28
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/_includes/_log_events_link.md
@@ -0,0 +1,3 @@
+::: panel Log Events
+See [Log Events](/monitoring#log-events) for more details on each of the log events that can help you troubleshoot issues. 
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/concepts/auth-issues.md b/fr-ca/articles/troubleshoot/concepts/auth-issues.md
new file mode 100644
index 0000000000..a9e9c62cf8
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/concepts/auth-issues.md
@@ -0,0 +1,24 @@
+---
+title: Troubleshoot Authentication Issues
+description: Learn where to look for steps to troubleshoot authentication and authorization issues such as API calls, login, logout, user profiles, MFA and SAML. 
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot Authentication Issues
+
+<%= include('../../_includes/_topic-links', { links: [
+  'troubleshoot/guides/check-api-calls',
+  'troubleshoot/guides/check-login-logout-issues',
+  'troubleshoot/guides/check-user-profiles',
+  'authorization/concepts/troubleshooting',
+  'mfa/references/troubleshoot-mfa',
+  'protocols/saml/saml-configuration/troubleshoot',
+  'extensions/authorization-extension/v2/troubleshooting'
+] }) %>
diff --git a/fr-ca/articles/troubleshoot/concepts/basics.md b/fr-ca/articles/troubleshoot/concepts/basics.md
new file mode 100644
index 0000000000..8d268cbffe
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/concepts/basics.md
@@ -0,0 +1,23 @@
+---
+title: Basic Troubleshooting
+description: Learn where to look for basic troubleshooting steps to eliminate common problems such as Auth0 status, platform, connections, rules, domains, and how to generate HAR files and validate JWTs. 
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Basic Troubleshooting
+
+<%= include('../../_includes/_topic-links', { links: [
+  'troubleshoot/guides/verify-platform',
+  'troubleshoot/guides/verify-connections',
+  'troubleshoot/guides/verify-domain',
+  'troubleshoot/guides/verify-rules',
+  'troubleshoot/guides/check-error-messages',
+  'monitoring/guides/monitor-applications'
+  ] }) %>
diff --git a/fr-ca/articles/troubleshoot/concepts/integration-extensibility-issues.md b/fr-ca/articles/troubleshoot/concepts/integration-extensibility-issues.md
new file mode 100644
index 0000000000..64a8588f0d
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/concepts/integration-extensibility-issues.md
@@ -0,0 +1,25 @@
+---
+title: Troubleshoot Integration and Extensibility
+description: Learn where to look for steps to troubleshoot integration and extensibility issues such as partner connections, Sign in With Apple, custom databases and domains, Deploy CLI, and extensions.   
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot Integration and Extensibility
+
+<%= include('../../_includes/_topic-links', { links: [
+  'connections/how-to-test-partner-connection',
+  'connections/apple-siwa/troubleshooting',
+  'connections/database/custom-db/error-handling',
+  'custom-domains/troubleshoot',
+  'connector/troubleshooting',
+  'extensions/troubleshoot',
+  'extensions/deploy-cli/references/troubleshooting', 
+  'libraries/auth0-php/troubleshooting'
+] }) %>
diff --git a/fr-ca/articles/troubleshoot/guides/check-api-calls.md b/fr-ca/articles/troubleshoot/guides/check-api-calls.md
new file mode 100644
index 0000000000..d1c28f4542
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/check-api-calls.md
@@ -0,0 +1,45 @@
+---
+title: Check API Calls
+description: Learn how to check API calls to troubleshoot issues. 
+topics:
+  - management-api-calls
+  - api-calls
+  - access-tokens
+contentType: how-to
+useCase: troubleshooting
+---
+# Check API Calls
+
+## Check Management API calls
+
+* Do you have a [Management API Access Token](/api/management/v2/tokens)?
+* Did the Access Token expire?
+* Did the Access Token contain the scopes needed for the call you made?
+* If a rule adjusts the scopes in the Access Token or checks whether specific users are allowed to have the scopes, have you checked the rule to make sure it is executing correctly?  
+* Get the Access Token from a [HAR file](/troubleshoot/guides/generate-har-files) and test it in the [Auth0 Management API Explorer](/api/management/v2/) to see if it works there.
+* If you are calling the Auth0 Management API from an application that authenticates with [Client Credentials flow](/flows/guides/client-credentials/call-api-client-credentials), note that rules are not executed in this context. The Client Credentials Exchange Hook can be used in this context instead, for functionality similar to a rule.
+
+## Check other API calls
+
+* Check in the [HAR file](/troubleshoot/guides/generate-har-files) if the Access Token contains correct scopes to call the API.
+* Check if the response to the `/authorize` endpoint call contains a scopes object. If so, check if the returned scopes are different from the requested scopes.
+* Make sure your API can [validate the Access Token](/tokens/guides/validate-access-tokens).  It should validate the audience, issuer, client (if any), signature algorithm, signature, claims and permissions.
+* If you experience errors with Access Token expiration, they could be caused by [clock skew differences manifested across different systems](/connector/troubleshooting#clock-skew) or even different language libraries, such as Java and Node.js.  This can be handled by running NTP on servers and configuring a clock skew tolerance in libraries used to validate tokens such as [jwt.verify](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback).
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Learn Identity Video: Calling an API](/videos/learn-identity/04-calling-an-api)
+* [Best Practices: Minimize API requests](/best-practices/performance#minimize-api-requests)
+* [Best Practices: Consider use of explicit timeouts when making API calls](/best-practices/performance#consider-use-of-explicit-timeouts-when-making-api-calls)
+* [Call APIs Using the Implicit Flow](/flows/guides/implicit/call-api-implicit)
+* [Call APIs Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+* [Call APIs Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code)
+* [Call APIs Using Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce)
+* [Call APIs Using Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth)
+* [Call Identity Provider APIs](/connections/calling-an-external-idp-api)
+* [Call APIs with Auth0 Tokens](/api-auth/tutorials/adoption/api-tokens)
+* [Call APIs from Highly Trusted Applications](/api-auth/grant/password)
+* [Call APIs from Machine-to-Machine Applications](/microsites/call-api/call-api-m2m-app)
+* [Call AWS APIs and Resources Securely with Tokens](/integrations/aws/tokens)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/guides/check-deprecation-errors.md b/fr-ca/articles/troubleshoot/guides/check-deprecation-errors.md
new file mode 100644
index 0000000000..e8e70e3298
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/check-deprecation-errors.md
@@ -0,0 +1,76 @@
+---
+title: Check Deprecation Errors
+description: Learn how to search logs for deprecation errors. 
+topics:
+    - errors
+    - deprecation
+contentType: how-to
+useCase: error-management
+---
+# Check Deprecation Errors
+
+There are two different ways to search for warning messages showing usage of deprecated features: The Dashboard or the Management API. Note that in either case, the [log retention period](/logs#how-long-is-log-file-data-available-) is governed by the subscription level of your account.
+
+## Search logs using the Dashboard
+
+If your application uses a deprecated feature, a Deprecation Notice message will show up in the Logs section of the [Dashboard](${manage_url}/#/).
+
+::: note
+So the logs aren't full of repetitive messages, they only show deprecation notes once per hour the first time it occurs within that hour.
+:::
+
+1. Navigate to the **Logs** screen in the Dashboard. 
+
+2. Enter `type:depnote` in the query box. 
+
+    A list of deprecation related warning messages from your logs will be shown, if any exist. The **Description** field provides information on the particular deprecated feature used. 
+
+2. Click the link in the **Event** column for each item to show additional information such as the client id which identifies the client application using the deprecated feature.
+
+3. Click each item and select **Context Data** for details about the item.
+
+## Search logs using the Management API
+
+Use the Management API to search through logs for deprecation messages by looking for  "Type" = "depnote".
+
+1. Go to the [Management API](/api/management/v2) console.
+
+2. If you have not already done so, [get and get an API token](/api/management/v2/tokens).
+
+3. On the left, navigate to **Logs > Search log events** and then scroll down to **Parameters**.
+
+4. In the **q** field enter `type:"depnote"`.
+
+5. Click on the **TRY** button. If successful, you should see a screen similar to the one below.
+
+![Management API - Logs - Results](/media/articles/errors/libraries/management-api-logs-results.png)
+
+    * The results will match one of the messages + descriptions below.
+    * The **Client ID** field in the results will indicate which application (client) on your tenant is using the deprecated feature.
+
+## Deprecation log messages 
+
+### Legacy Lock API
+
+**Log entry**: `up-idp-initiated`
+
+**Error Message:** "Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application."
+
+| Cause | Resolution |
+| --- | --- |
+| You are using a legacy version of embedded Lock or Auth0.js SDK. | Migrate away from the deprecated library versions as soon as possible. |
+| Calling the /usernamepassword/login endpoint directly. | Use the Lock or Auth0.js libraries instead. |
+| Automatic monitoring tools making requests to login page | If you have an automatic monitoring tool making requests to the login page, the tool will likely not preserve state correctly and will cause the Legacy Lock API error to occur in your logs. Use of the tool should either be discontinued, or accounted for when considering causes of the log notices. |
+| Coding errors in a customized [Universal Login Page](/universal-login) | Make sure the `state` and `_csrf` fields are passed to Lock or Auth0.js in your customized login page. They are by default included in the `config.internalOptions` object, but if this is removed during customization, the error occurs. |
+
+Tenant log entries regarding the Legacy Lock API may include the referrer and information about the SDK used. This information can be used to see if any of your applications use outdated libraries.
+
+### SSOdata endpoint
+
+**Log entry**: `ssodata`
+
+**Error Message:** "SSOdata endpoint: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application."
+
+**Cause**: Either calling the `/ssodata` endpoint directly or using old versions of embedded Lock or Auth0.js SDK to call a function which called the `/ssodata` endpoint. 
+
+**Resolution**: [Migrate to Universal Login](/guides/login/migration-embedded-universal) or [migrate to Lock v11 or Auth0.js v9](/migrations#introducing-lock-v11-and-auth0-js-v9).
diff --git a/fr-ca/articles/troubleshoot/guides/check-error-messages.md b/fr-ca/articles/troubleshoot/guides/check-error-messages.md
new file mode 100644
index 0000000000..7fde71b5d5
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/check-error-messages.md
@@ -0,0 +1,113 @@
+---
+title: Check Error Messages
+description: Learn how to check for error message to troublshoot issues. 
+topics:
+  - error-messages
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check Error Messages
+
+Check for error messages displayed in any of the following locations:
+
+* Browsers and HTML page responses
+* Developer tools network and console tabs
+* Authorization Server responses
+* Deprecation errors
+
+## Check browser errors
+
+A HAR file is a JSON formatted log of a web browser's interactions with a web server. If authentication isn't working as expected, you can [generate and analyze HAR files](/troubleshoot/guides/generate-har-files) to find issues.
+
+## Check login screen
+
+The Lock login widget shows error messages for certain types of issues, such as an incorrect username or password. Check the **More Information** link if you're using Auth0's standard error page.
+
+## Check logs
+
+Auth0 stores [log data](/logs) including Dashboard administrator actions, successful and failed user authentications, and password change requests. You can view the logs in the [Dashboard](${manage_url}/#/logs).
+
+::: note
+Some types of errors do not appear in the logs. For example, if an error occurs at a remote Identity Provider, where authentication doesn’t complete and the user is never returned to Auth0, there won’t be any entry in logs. 
+:::
+
+You can export [Auth0 logs](/logs) and either store them yourself or automatically push them to external log services. This functionality can help you with data retention requirements, as well as log analysis requirements. You can install and configure an Auth0 Extension to export logs automatically to another provider like Sumo Logic or Loggly. For a list of available providers and detailed steps to configure each, see [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service).
+
+<%= include('../_includes/_log_events_link') %>
+
+You can also use the Management API to export logs and store them. There are the two available endpoints, each providing slightly different information.
+
+### Search all logs `/get_logs` endpoint
+
+The [Search log events endpoint](/api/management/v2#!/Logs/get_logs) retrieves log entries that match the search criteria you provided. If you do not provide any search criteria, you will get a list of all available entries. 
+
+You can provide search criteria using the **q** parameter and retrieve specific fields using the **fields** parameter. 
+
+To access the API, you need a [Management APIv2 token](/api/management/v2/tokens).
+
+This sample request retrieves all logs for successful logins (the event acronym for successful login is `s`). The list of fields we will retrieve per log entry is: **date**, **description**, **client_id**, and **log_id**.
+
+```har
+{
+"method": "GET",
+"url": "https://${account.namespace}/api/v2/logs",
+"httpVersion": "HTTP/1.1",
+"headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+}],
+"queryString":  [
+    {
+      "name": "fields",
+      "value": "date,description,client_id,log_id"
+    },
+    {
+      "name": "type",
+      "value": "s"
+    }
+]
+}
+```
+
+For details on the search criteria you can use and a list with the event acronyms, see the [Search log events endpoint](/api/management/v2#!/Logs/get_logs).
+
+### Get a single log entry `/get_logs_by_id` endpoint
+
+The [Get a log event by ID endpoint](/api/management/v2#!/Logs/get_logs_by_id) retrieves the log entry associated with the provided ID.
+
+This sample request retrieves a single log entry with the ID `90020180129170850881585554625888895190928456277777449010`.
+
+```har
+{
+"method": "GET",
+"url": "https://${account.namespace}/api/v2/logs/90020180129170850881585554625888895190928456277777449010",
+"httpVersion": "HTTP/1.1",
+"headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+}]
+}
+```
+
+## Check logs for deprecation errors
+
+When Auth0 features are deprecated, there may be errors or notices in the tenant logs that show up to indicate that your applications are using the deprecated features. You can [search the logs for specific deprecation entries](/troubleshoot/guides/check-deprecation-errors) that may indicate that a feature has been deprecated. 
+
+## Rate limits and other errors
+
+Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You should set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you will find it helpful to scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)).
+
+::: panel Best Practice
+Calling the Management API to retrieve user profile information from within a Rule is a common cause of rate limit errors because such API calls can execute for every login as well as periodic session checks.
+:::
+
+## Check real-time webtask logs error console
+
+You can put `console.log()` statements into Rules, Hooks, Custom DB scripts, and Webtasks. The output from those statements is viewable in the Realtime Web Log. If you install the Real-time Webtask Logs extension, you can initiate a view of this log console from the **Debug** buttons underneath the Rules, Hooks, and custom DB script editor windows, or from the webtask console for webtasks.
+
+## Keep reading
+
+* [Standard Error Responses](/api/authentication#standard-error-responses)
+* [Auth0.js Error Codes and Descriptions](/libraries/auth0js/v9#error-codes-and-descriptions)
+* [Errors with Code `invalid_token`](/troubleshoot/references/invalid-token)
diff --git a/fr-ca/articles/troubleshoot/guides/check-login-logout-issues.md b/fr-ca/articles/troubleshoot/guides/check-login-logout-issues.md
new file mode 100644
index 0000000000..067b5c888b
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/check-login-logout-issues.md
@@ -0,0 +1,85 @@
+---
+title: Check Login and Logout Issues
+description: Learn how to check login and logout to troubleshoot issues. 
+topics:
+  - login-issues
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check Login and Logout Issues
+
+Here are things to check to help you narrow down when issues occur during login and logout.
+
+## Login Issues
+
+### Is the user prompted for login credentials?
+
+* Does the HAR file show a call to the authorization server (`/authorize` endpoint)?
+* Is the connection enabled for the application?
+* Is the remote authorization service available? 
+* If using the [Auth0 Universal Login Page](/universal-login), try turning off customization and see if authentication works. If login works without your customizations, review your Universal Login Page customization code.
+
+### Is an error message shown after entering credentials?
+
+* Can you test login another way to ensure credentials are correct?
+* If password expiration is a possibility, check if password has expired.
+* Check your browser's developer tools or web inspector console for errors in the flow before returning to Auth0.
+* Check the HAR file - does it show a return to Auth0 (`/login/callback`endpoint)?
+    - If not, check that the identity provider has the correct callback URL for Auth0.
+
+### Is a login session established for the user at the authorization server?
+
+* To test this, open a second tab in the same browser and go to the same URL. Are you prompted to log in again?
+    - If you're not prompted to log in, a session is there.
+
+### Is a log entry created in your Auth0 Logs?
+
+* If no log entry was created the authentication transaction did not complete or return to Auth0.
+* Check the response from the authorization server for error messages.
+* Check authorization server logs (if possible) for errors.
+
+### Is an entry created in Auth0 user’s screen with all correct profile info?
+
+* If not, check the response from authorization server in the HAR file. It may not be returning information about the user
+* If you're using rules, check your rules scripts for issues.
+* If you're using a custom database connection, check your database action scripts for issues.
+* If you're using LDAP, check the profile mapper script (`profileMapper.js`) for issues.
+* Check your social connection configurations for what profile information is requested.
+
+### Does the HAR file show a token or assertion returned to application?
+
+* Look in the [HAR file](/troubleshoot/guides/generate-har-files) for the call to your application callback URL.
+* Find the ID Token (`id_token`) and check if it has the information needed by the application.
+
+### If you decode the token or assertion does it have information you expect?
+
+* View JWTs with [JWT.io](http://jwt.io).
+* View SAML assertions with [SAMLTool.io](http://samltool.io).
+
+### If the logged in user cannot access another application with Single Sign-on
+
+1. Is the user trying to login to the second application from the same browser as their initial login?
+2. Go to your [Tenant Settings > Advanced Settings](${manage_url}/#/tenant/advanced) and check the **Log In Session Management** settings. Was the second login attempt within the timeout periods?
+3. Check the value passed as the `prompt` parameter in `/authorize` call.
+4. Is the connection used to log in to the first application enabled for the second application?
+5. Did the second application receive all the necessary user profile information?
+6. If using a mobile device, you'll need to use a browser-based flow. For more information, see [Browser-Based vs. Native Login Flows on Mobile Devices](/design/browser-based-vs-native-experience-on-mobile).
+
+### Check application logs
+
+* Do your application logs show any errors?
+* Did the application receive all the information it needs, such as groups or user profile attributes?
+
+## Logout issues
+
+* Did you whitelist your logout redirect URLs? If you are using a redirect URL in a logout call it must be registered in either the tenant or application settings.
+* If you need federated logout, did you append the `?federated` parameter to the logout call?
+* Make sure that the logout redirect URL is different from the login callback URL.
+* Make the logout redirect URL an anonymous page (not protected by login) so that redirects to the logout redirect URL do not immediately trigger a login, which may confuse users.
+
+## Keep reading
+
+* [Common Auth0 Library Authentication Errors](/libraries/error-messages)
+* [Troubleshoot Passwordless Authentication](/connections/passwordless/troubleshoot)
+* [Troubleshoot WordPress Plugin](/cms/wordpress/troubleshoot)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/guides/check-user-profiles.md b/fr-ca/articles/troubleshoot/guides/check-user-profiles.md
new file mode 100644
index 0000000000..7b551af860
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/check-user-profiles.md
@@ -0,0 +1,26 @@
+---
+title: Check User Profiles
+description: Learn how to check user profiles to troubleshoot issues. 
+topics:
+  - login-issues
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check User Profiles
+
+1. Is user profile information correct at the source (authorization server)?
+2. Generate and check the [HAR file](/troubleshoot/guides/generate-har-files), look for an `id_token`.
+3. Decode the `id_token` at [JWT.io](https://jwt.io) to see if it has the correct information.
+4. Check any custom database scripts or rule logic.
+5. Check if you called `/tokeninfo` endpoint and have a custom domain configured within Auth0. If so, you need to use `/userinfo` endpoint instead
+6. Check if you called `/userinfo` endpoint properly. You should pass an access token. You should call this endpoint with the default Auth0 domain even if the tenant has a custom domain enabled.  
+7. Check if you specified the correct [scope](/scopes) to get an Access Token.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [User Profiles Overview](/users/concepts/overview-user-profile)
+* [Normalized User Profiles](/users/normalized/auth0)
+* [User Profile Structure](/users/references/user-profile-structure)
diff --git a/fr-ca/articles/troubleshoot/guides/generate-har-files.md b/fr-ca/articles/troubleshoot/guides/generate-har-files.md
new file mode 100644
index 0000000000..b073f99123
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/generate-har-files.md
@@ -0,0 +1,78 @@
+---
+title: Generate and Analyze HAR Files
+description: Learn how to troubleshoot with HAR files and steps to generate a HAR file.
+topics:
+  - troubleshoot
+  - har-files
+  - http-archive
+contentType: how-to
+useCase: troubleshoot
+---
+
+# Generate and Analyze HAR Files
+
+A [HAR](https://en.wikipedia.org/wiki/.har) (HTTP Archive) file shows the sequence of redirects that happen during a login transaction. It's an excellent tool for debugging authentication issues, as it can identify where things get stuck. A HAR file is a JSON formatted log of a web browser's interactions with a web server. If authentication isn't working as expected, you can generate and analyze HAR files to find issues. Including a HAR file in your [support requests](${env.DOMAIN_URL_SUPPORT}) can help speed up the troubleshooting process.
+
+::: warning
+Before sending the HAR file to Auth0, ensure that you remove or obfuscate any sensitive information (such as passwords and client secrets) using a text editor. 
+:::
+
+## Generate HAR files with browsers
+
+### Google Chrome
+
+1. Close all __incognito__ windows in Google Chrome.
+2. Open a __new incognito__ window in Google Chrome.
+3. Go to **View > Developer > Developers Tools**.
+4. In the Developer Tools pane, choose the **Network** tab. 
+5. Check the __Preserve Log__ checkbox to record all interactions.
+6. Visit the page and complete the steps that trigger the issue.
+7. Choose the __Network__ tab.
+8. Click the down arrow to export the HAR file.
+9. Save the HAR file. 
+
+### Safari
+
+1. Ensure that **Show Develop menu in menu bar** checkbox is checked under **Safari > Preferences > Advanced**.
+2. Choose **File > Open New Private Window**.
+3. Visit the web page where the issue occurs. 
+4. Choose **Develop > Show Web Inspector**. The Web Inspector window appears.
+5. Complete the steps on the page that trigger the issue.
+6. Select the **Network** tab.
+7. Click **Export** on the upper right side of the pane. 
+8. Save the HAR file. 
+
+### Firefox
+
+1. Close all __private__ windows in Firefox.
+2. Open a __new private__ window in Firefox.
+3. Go to __Tools > Developer > Network__ or **ctrl-shift-E**.
+4. Visit the page and complete the steps that trigger the issue.
+5. Choose the __Network__ tab and right click and then select **Save All As Har**.
+6. Save the HAR file.
+
+
+### Internet Explorer
+
+1. Close all __InPrivate__ windows in Internet Explorer.
+2. Open a __new InPrivate__ window in Internet Explorer (**ctrl-shift-P**.)
+3. Go to __Tools > F12 Developer Options > Network__.
+4. Ensure **Clear entries on navigate** is switched off.
+5. Visit the page and complete the steps that trigger the issue.
+6. Choose the __Network__ tab and select **Export as HAR (Ctrl+S)**.
+7. Save the HAR file.
+
+## Analyze HAR files
+
+1. To view the HAR file, use a tool such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). 
+2. Analyze the list of web requests captured in the HAR file. In particular, check the sequence of redirects to see how far you get in the authentication process. This helps identify where the issue is happening. 
+3. Compare the sequence of redirects to the expected sequence for your authentication flow.
+
+    For example:
+
+    * There should be a call to the `/authorize` endpoint to start the authentication flow.
+    * There may be redirects to remote identity providers to prompt the user to log in.
+    * Then there should be a redirect back to Auth0 `/login/callback` (`https://login.auth0.com/login/callback`).
+    * Then there should be a redirect back to your application’s callback URL.
+
+<%= include('../_includes/_log_events_link') %>
diff --git a/fr-ca/articles/troubleshoot/guides/verify-connections.md b/fr-ca/articles/troubleshoot/guides/verify-connections.md
new file mode 100644
index 0000000000..8c001cfeda
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/verify-connections.md
@@ -0,0 +1,37 @@
+---
+title: Verify Connections
+description: Learn how to verify connection transactions and external service dependencies to troubleshoot issues. 
+topics:
+  - connections
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Connections
+
+An authentication transaction often has several parts. Auth0 provides methods so you can try individual parts of the transaction to help you find the possible source of the problem.
+
+Most identity provider connections have a **TRY** button to see if the connection is working. If that fails, you can debug the connection without involving the rest of the application. If the connection works, then you can start debugging the application.
+
+1. Use the **TRY** button on a connection to test just the connection.  
+2. If the test with the **TRY** button fails, you know it is not an issue with your application but rather something with the connection configuration or the connection provider.
+3. Check the response from the test with the **TRY** button to see if the response contains a useful error message or other information.
+4. Try logging into the same service through a different path.
+5. If the same issue occurs you’ll know it’s some sort of issue with the account
+6. If a test with the **TRY** button fails for a custom DB connection, it is frequently caused by an issue in the custom DB scripts. Putting console.log statements into them and viewing output in the Console Log can help debug them.
+
+## Verify external service dependencies
+
+1. If your authentication uses external services, like social identity providers, and it suddenly stops working, [check external services status](/monitoring/guides/check-external-services).
+2. If a connection is not working, even with the **TRY** button, check the connection.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Verify Rules](/troubleshoot/verify/rules)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/guides/verify-domain.md b/fr-ca/articles/troubleshoot/guides/verify-domain.md
new file mode 100644
index 0000000000..76ea9bba52
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/verify-domain.md
@@ -0,0 +1,26 @@
+---
+title: Verify Domain
+description: Learn how to verify your domain to troubleshoot issues.
+topics:
+  - domains
+  - custom-domains
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Domain
+
+* Ensure that the domain is the same as that used during authentication.
+* If using an Auth0 [Custom Domain](/custom-domains), it is important to use the same domain as used in the application to invoke authentication. See [Troubleshoot Custom Domains](/custom-domains/troubleshoot) for details. 
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Rules](/troubleshoot/guides/verify-rules)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/guides/verify-platform.md b/fr-ca/articles/troubleshoot/guides/verify-platform.md
new file mode 100644
index 0000000000..a131ec5578
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/verify-platform.md
@@ -0,0 +1,90 @@
+---
+title: Verify Platform
+description: Learn how to verify your platform to troubleshoot issues.
+topics:
+  - platform
+  - language
+  - browser
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Platform
+
+Ensure that you are on current versions of your technology stack. If you're using an older version of a programming language or library consider updating to the current version.
+
+* Check the [Auth0 support matrix](/support/matrix) to see if the language or library versions you're using is supported.
+* If there's a problem in one environment (such as development) but not another (such as production), compare the versions of the technology stack across the two environments.
+* If not, upgrade your technology stack and browser to the latest versions and test again before creating a support request.
+
+## Check the scope of the issue
+
+Testing on different browsers, platforms, locations, and users can help narrow down the source of a problem when it occurs. Perform the following tests and review the [logs in your Auth0 dashboard](${manage_url}/#/logs) after each test for more information.
+
+<%= include('../_includes/_log_events_link') %>
+
+### Test with different browsers
+
+* Does the issue happen with all browsers or just some?
+* Test in a new incognito or private browser session (no previous state).
+* Upgrade to the latest browser version and re-test.
+* Turn off browser plugins and re-test to see if a plug-in contributes to the issue.
+
+### Test with different users
+
+* Does the issue occur for all users or just some?  
+* If some, is there a pattern? Such as location, connection, or role?
+
+### Test with different connections (if possible)
+
+* Does the issue happen with all connections or just one?
+
+### Test with different client applications (if you have more than one)
+
+* Does the issue happen with all clients or just one?
+
+### Test across different environments
+
+* Try the development, staging, and production environments of your application(s).
+* Try across different Auth0 tenants to see if any differences.
+
+## Check if the issue is consistent or intermittent
+
+* If the issue is consistent, note the steps to reliably duplicate the issue.
+* If the issue intermittent, note any pattern that might cause it.
+* Is this an issue with a new setup, or did it work before and is now broken?  
+    - If it just broke, what changes were made? 
+    - Does undoing the changes fix the issue?
+
+## Issues that affect only one or a few users
+
+* [Check the user's profile](/troubleshoot/guides/verify-user-profiles), browser, or device for any issues.
+* Check to see if it happens in all browsers for the affected users (indicating a data issue) or just certain types of browsers (indicating a browser-specific issue).
+* Check to see if the browser has enabled JavaScript and cookies.
+* Check that the caps lock key is disabled.
+* If the user is using a mobile device, check to see if there's any software that might impact authentication and/or authorization (such as not running some type of required software).
+* Check to see if the user can access some of the application's key URLs, such as the identity provider's Single Sign-on (SSO) URL (indicating a network connectivity issue).
+
+## Issues that occur after go-live (worked before, then stopped working)
+
+* Check if any recent changes to your application or any APIs you call?
+* Check if any recent network changes (load balancer, firewall, proxy config changes).
+* Check if any recent infrastructure changes (e.g. credentials for LDAP or DB servers?)
+* Check for any patches or updates to applications, infrastructure, or technology stacks.
+* Check that all your servers are running NTP and have accurate time sync
+* Check if any of your certificates have expired.
+* Check with owners of any remote identity providers if anything changed.
+    - Check network connectivity to any remote identity providers.
+* Check notifications in Auth0 dashboard/migrations - any changes you overlooked?
+* Check Auth0 change log - any recent configuration changes related to your issue?
+* Check if any component in the technology stack has been updated or patched recently?
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Verify Rules](/troubleshoot/guides/verify-rules)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/guides/verify-rules.md b/fr-ca/articles/troubleshoot/guides/verify-rules.md
new file mode 100644
index 0000000000..acaf441314
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/guides/verify-rules.md
@@ -0,0 +1,31 @@
+---
+title: Verify Rules
+description: Learn how to verify rules to troubleshoot issues. 
+topics:
+  - rules
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Rules
+
+Failures in a rule can often cause authentication issues. Perform the following checks to see if rules could be behind your issue.
+
+* Turn rules off and see if the issue still occurs.
+* Check that your rules catch all possible errors that might be returned. Uncaught errors could cause failures.
+* Check that your rules are calling the `callback` function only once for each logical branch in your code.
+* Add `console.log()` statements to your rules to debug and check state. For example: `console.log(“output = “ + some_variable);`.
+* Click **Debug Rule** in the Dashboard to view the output from your `console.log` statements.
+* View the output in the Real-time Webtask Logs to get more information about your rules’ execution.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/index.md b/fr-ca/articles/troubleshoot/index.md
new file mode 100644
index 0000000000..eaa75352cd
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/index.md
@@ -0,0 +1,49 @@
+---
+title: Troubleshoot
+description: Running into an issue? Here are the things you should check to troubleshoot and solve common issues in Auth0.
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot
+
+::: note
+Follow [@auth0status](https://twitter.com/auth0status) on Twitter to get the latest status updates. 
+:::
+
+Before submitting a ticket to Auth0 [Support Center](https://support.auth0.com/), review the following troubleshooting guides to identify and possibly fix the issue. If you still cannot address the issue, you can create a support ticket. 
+
+## Basic areas to check and verify first
+
+There are a few [basic](/troubleshoot/concepts/basics) areas to check and verify before you submit a support ticket. These areas include platform, connections, domain, rules, and deprecations.  
+
+## Authentication & authorization issues
+
+We provide checklists and guidelines for checking [authentication and authorization](/troubleshoot/concepts/auth-issues) issues with API calls, login, user profiles, MFA, and SAML. 
+
+## Integration & extensibility issues
+
+We provide troubleshooting tips for issues you may have pertaining to [integrations and extensibility](/troubleshoot/concepts/integration-extensibility-issues) such as partner connections, custom databases, and custom domains. 
+
+## Tools
+
+Here are some helpful tools to help you troubleshoot issues:
+
+* [Auth0 Logs](/logs)
+* [HAR files](/troubleshoot/guides/generate-har-files)
+* [JWT Inspector](https://jwt.io/)
+* [Authentication API Debugger](/extensions/authorization-extension/v2/troubleshooting)
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Supported versions](/support/matrix)
+* [Support Plans and Service Level Agreements](/support#defect-responses)
+* [Operational Policies](/policies)
+* [Open and Manage Support Tickets](/support/tickets)  
+* [Professional Services](/services)
diff --git a/fr-ca/articles/troubleshoot/references/invalid-token.md b/fr-ca/articles/troubleshoot/references/invalid-token.md
new file mode 100644
index 0000000000..d858c6bfec
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/invalid-token.md
@@ -0,0 +1,46 @@
+---
+title: Invalid Token Errors
+description: Describes how to troubleshoot invalid token errors. 
+topics:
+  - errors
+  - tokens
+contentType:
+  - reference
+useCase: error-management
+---
+
+# Invalid Token Errors
+
+## Parsing an HS256-Signed ID Token Without an Access Token
+
+**Error Message**: The ID Token cannot be validated because it was signed using the HS256 algorithm and public applications (such as a browser) can’t store secrets. Please read the associated doc for ways to fix this.
+
+### Why this error occurred
+
+Beginning with **auth0.js version 9** and **Lock version 11**, when ID Tokens are signed with HS256, they are discarded and a call to **/userinfo** is made to retrieve user information. 
+
+Calling **/userinfo** requires an Access Token. If you don't ask for an Access Token when authenticating, you will receive the following error:
+
+```
+The id_token cannot be validated because it was signed with the HS256 algorithm
+and public applications (like a browser) can’t store secrets.
+Please read the associated doc for possible ways to fix this.
+```
+
+### Ways to fix this error
+
+There are two ways to fix the error:
+
+1. **(RECOMMENDED)** Change the application signature algorithm to RS256 instead of HS256.
+2. Change the value of your **responseType** parameter to **token id_token** (instead of the default), so that you receive an Access Token in the response.
+
+To change the application signature algorithm to RS256 instead of HS256:
+
+    1. Go to [Dashboard > Applications]({$manage_url}/#/applications).
+    1. Select your application.
+    1. Scroll to the bottom of the **Settings** tab, and click **Show Advanced Settings**.
+    1. Open up the **OAuth** tab. Change the value of **JsonWebToken Signature Algorithm** to **RS256**.
+    1. Scroll to the bottom of the page and click **Save Changes**.
+
+    If you proceed with this option and you are using the ID Token to call your APIs, be sure to change your server code so that it validates tokens using the RS256 algorithm instead of HS256. Note that using ID Tokens to call APIs [is not recommended](/tokens).
+
diff --git a/fr-ca/articles/troubleshoot/references/mgmtv2-errors.md b/fr-ca/articles/troubleshoot/references/mgmtv2-errors.md
new file mode 100644
index 0000000000..3c98b12c0b
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/mgmtv2-errors.md
@@ -0,0 +1,12 @@
+---
+public: false
+topics:
+  - errors
+  - dashboard
+  - api
+contentType:
+  - reference
+useCase: error-management
+---
+
+# Management API Errors
\ No newline at end of file
diff --git a/fr-ca/articles/troubleshoot/references/oauth-errors.md b/fr-ca/articles/troubleshoot/references/oauth-errors.md
new file mode 100644
index 0000000000..4c0642b44d
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/oauth-errors.md
@@ -0,0 +1,15 @@
+---
+public: false
+topics:
+  - errors
+  - oauth1
+  - oauth2
+contentType:
+  - reference
+useCase: error-management
+---
+
+# OAuth Errors
+
+<%= include('../../_includes/_co_authenticate_errors', { library : 'Lock v11'}) %>
+
diff --git a/fr-ca/articles/troubleshoot/references/saml-errors.md b/fr-ca/articles/troubleshoot/references/saml-errors.md
new file mode 100644
index 0000000000..64b586983c
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/saml-errors.md
@@ -0,0 +1,99 @@
+---
+public: false
+topics:
+  - errors
+  - saml
+contentType:
+  - reference
+useCase: error-management
+---
+
+# SAML Errors
+
+## Invalid request - connection disabled
+
+```json
+{
+  "error": "invalid_request",
+  "error_description": "the connection was disabled"
+}
+```
+
+### Cause
+
+This message indicates that the Application doesn't have an active Connection associated.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *Applications* tab.
+4. Enable at least one Application (if you don't see any in the list, you will need to [create an application](/applications) before proceeding).
+
+## IdP-Initiated Default App Not Configured
+
+```json
+{
+  "invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter."
+}
+```
+
+### Cause
+
+This error appears if you haven't provided the necessary information to support IdP-initiated login flows.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Select the **Default Application** and the **Response Protocol** used by that Application, and (optionally) specify any additional parameters you want passed to the Application.
+
+::: panel SP-Initiated Login
+If you see this error when using a SP-initiated flow, one of the following is missing or empty:
+
+* The `RelayState` parameter
+* The `InResponseTo` attribute in the SAML response
+
+If these are missing or empty, Auth0 treats the login as IdP-initiated. You can fix this error by checking your configuration to ensure that both fields are populated and returned appropriately.
+:::
+
+## Missing RelayState parameter
+
+### Cause
+
+This error occurs when the identity provider doesn't return the `RelayState` parameter along with its response.
+
+### Solution
+
+Work with the identity provider to ensure that it returns the `RelayState` parameter.
+
+## Audience is Invalid
+
+This error occurs if the value of the `audience` element from the identity provider's SAML response doesn't match the value expected by Auth0. Auth0 expects the value to be the Entity ID for the Connection.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). Find your Connection, and click on **Setup Instructions**.
+2. Under the *Common Settings* section, your **Entity ID** is the second parameter provided.
+
+Make sure that the identity provider sends the correct `audience` value in the SAML response.
+
+## Incorrect protocol specified
+
+There is an incorrect response protocol on the **IdP-Initiated** tab. The response protocol is the one used between Auth0 and the Application (not the remote identity provider). For example, if you set this value to **SAML** when your Application expects **OpenID Connect** or **WS-Fed** results in errors due to the incorrect configuration.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Check the value you have set in the **Response Protocol** field.
+
+## User isn't logged out from the IdP
+
+When ADFS is configured as SAML IdP, if the ADFS is relaying party trust `Name ID` attribute isn't mapped the logout flow fails. For example, with the federated parameter `v2/logout?federated&...` user isn't redirected to the ADFS SAML logout endpoint but redirects back to application callback URL directly. As a consequence, the user isn't logged out from the IdP in that case.
+
+### Solution
+
+Add the `Name ID` attribute as a rule on the SAML Relaying Party Trust. 
diff --git a/fr-ca/articles/troubleshoot/references/self_change_password.md b/fr-ca/articles/troubleshoot/references/self_change_password.md
new file mode 100644
index 0000000000..739ba41d28
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/self_change_password.md
@@ -0,0 +1,40 @@
+---
+description: Error messages for the self change password API.
+public: false
+topics:
+  - errors
+  - passwords
+contentType: reference
+useCase: error-management
+---
+# Self Change Password Errors
+
+Below you will find the errors codes and possible solutions to various errors that can occur with the self change password api.
+
+## Error Format
+
+Error messages are returned in the standard format:
+
+```json
+{
+  "error": "error_code",
+  "error_description": "the description of the error.",
+  "error_uri": "https://auth0.com/docs/troubleshoot/references/errors/self_change_password"
+}
+```
+
+## Error Codes
+
+### `invalid_request`
+
+This error results when you supply invalid parameters. Error messages will describe the issue such as a required parameter or invalid format.
+
+
+### `invalid_user_password`
+
+This error results from a bad `username`/`email` and `old_password` combination being sent. Retry the request with the correct username and `old_password`.
+
+
+### `change_password_error`
+
+This error results from various conditions with the underlying identity provider. Generally, this happens when you are using a custom database and have not implemented the change password script.
diff --git a/fr-ca/articles/troubleshoot/references/wsfed-errors.md b/fr-ca/articles/troubleshoot/references/wsfed-errors.md
new file mode 100644
index 0000000000..d5da13e030
--- /dev/null
+++ b/fr-ca/articles/troubleshoot/references/wsfed-errors.md
@@ -0,0 +1,11 @@
+---
+public: false
+topics:
+  - errors
+  - ws-fed
+contentType:
+  - reference
+useCase: error-management
+---
+
+# WS-Fed Errors
\ No newline at end of file
diff --git a/fr-ca/articles/universal-login/_implement_universal_login.md b/fr-ca/articles/universal-login/_implement_universal_login.md
new file mode 100644
index 0000000000..bb54d23afc
--- /dev/null
+++ b/fr-ca/articles/universal-login/_implement_universal_login.md
@@ -0,0 +1 @@
+For detailed instructions on setting up your application to use Universal Login, check out our [Quickstart guides](/quickstarts) and choose the one that best fits your chosen technologies. The Quickstart guides will walk you through all of the implementation steps.
\ No newline at end of file
diff --git a/fr-ca/articles/universal-login/classic.md b/fr-ca/articles/universal-login/classic.md
new file mode 100644
index 0000000000..25d02460bc
--- /dev/null
+++ b/fr-ca/articles/universal-login/classic.md
@@ -0,0 +1,20 @@
+---
+description: Classic Universal Login Experience
+topics:
+  - login
+  - universal-login
+contentType: index
+---
+# Classic Universal Login Experience
+
+Auth0's Classic Universal Login experience is built on top of Auth0's JavaScript libraries ([Lock.js](/libraries/lock), [auth0.js](/libraries/auth0js), MFA Widget, Password Reset). Compared to the New Universal Login experience, it currently offers a more complete feature set.
+
+When you [customize the HTML in the Dashboard](${manage_url}/#/login_page) for Universal Login pages, the default templates will also use the same JavaScript libraries, so from a UX and functional perspective, the transition between the default user interface and a custom one is more natural.
+
+The Classic Experience has extensive [customization options](/universal-login/customization-classic) available. After choosing one of the templates, you can modify them to meet your needs. The Lock widget, if used, has a variety of both appearance and behavior options that can be changed. The Auth0.js based templates have even more flexibility, as the UI is entirely custom made and can be modified to match your application's styles if you wish to do so.
+
+Given that it is being used by a significant percentage of Auth0 customers, the Classic Universal Login Experience will be maintained for the foreseeable future. However, the majority of significant new feature development will be done on the [New Universal Login Experience](/universal-login/new).
+
+## Implement Universal Login
+
+<%= include('./_implement_universal_login') %>
diff --git a/fr-ca/articles/universal-login/custom-error-pages.md b/fr-ca/articles/universal-login/custom-error-pages.md
new file mode 100644
index 0000000000..2ff0888a57
--- /dev/null
+++ b/fr-ca/articles/universal-login/custom-error-pages.md
@@ -0,0 +1,112 @@
+---
+title: Custom Error Pages
+description: How to setup a custom error page for authorization error events.
+toc: true
+crews: crew-2
+topics:
+  - custom-error-pages
+  - hosted-pages
+contentType:
+    - how-to
+useCase: customize-hosted-pages
+---
+# Custom Error Pages
+
+In the event of an authorization error, you may choose to display to your users either [the default Auth0 error page](/universal-login/error-pages) or a customized error page.
+
+This article will show you how to use a customized error page. For details on the default Auth0 error page see [Error Pages](/universal-login/error-pages).
+
+## How to customize the error page
+
+If you choose to display a custom error page, you have two options:
+
+-  [Redirect the user to a custom error page](#redirect-users-to-a-custom-error-page)
+-  [Configure Auth0 to render a custom error page on your behalf](#render-a-custom-error-page). This feature is only available via the Management API.
+
+### Redirect users to a custom error page
+
+You can configure Auth0 to redirect users to a custom error page, using the Dashboard or the Management API.
+
+If you use the Dashboard, follow these steps:
+
+1. Log in to the [Dashboard](${manage_url}).
+1. Click on your tenant name in the top right corner to bring up the associated dropdown box.
+1. Select **Settings** to open the [Tenant Settings](${manage_url}/#/tenant/) page.
+1. Scroll down to the Error Pages section.
+1. Select the option **Redirect users to your own error page**.
+1. Provide the URL of the error page you would like your users to see.
+
+## Customize error pages via the Management API
+
+Instead of using the Management Portal, you may configure your error pages by making the appropriate `PATCH /api/v2/tenants/settings` call to the Management API.
+
+### Redirect users to a custom error page
+
+To redirect users to a custom error page, update the `url` field of your JSON body to point to the location of the error page.
+
+![Error Page Redirect Option](/media/articles/error-pages/redirect-error-page.png)
+
+If you use the API instead, use the `PATCH /api/v2/tenants/settings` endpoint. Update the `url` field of your JSON body to point to the location of the error page.
+
+```har
+{
+    "method": "PATCH",
+    "url": "https://${account.namespace}/api/v2/tenants/settings",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Authorization", "value": "Bearer YOUR_TOKEN"},
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData": {
+        "mimeType": "application/json",
+        "text": "{\"error_page\": {\"html\": \"\", \"show_log_link\":false, \"url\": \"http://www.example.com\"}}"
+    },
+    "headersSize" : -1,
+    "bodySize" : -1,
+    "comment" : ""
+}
+```
+The following parameters are appended to the `url` as query string to include the error information. Note that the parameters presented in the `url` vary depending on the error type.
+* `client_id`
+* `connection`
+* `lang`
+* `error`
+* `error_description`
+* `tracking`
+
+### Render a custom error page
+
+You can render your custom error page with Liquid syntax using the following variables:
+
+* `{client_id}`
+* `{connection}`
+* `{lang}`
+* `{error}`
+* `{error_description}`
+* `{tracking}`
+* `{log_url}`
+
+To provide the appropriate HTML, pass in a string containing the appropriate Liquid syntax to the `html` element:
+
+```har
+{
+    "method": "PATCH",
+    "url": "https://login.auth0.com/api/v2/tenants/settings",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Authorization", "value": "Bearer YOUR_TOKEN"},
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData": {
+        "mimeType": "application/json",
+    "text": "{\"error_page\": {\"html\": \"
    {{error | escape }} {{error_description | escape }} This error was generated {{'now' | date: '%Y %h'}}.
    \", \"show_log_link\": false, \"url\": \"\"}}"
+    },
+    "headersSize" : -1,
+    "bodySize" : -1,
+    "comment" : ""
+}
+```
diff --git a/fr-ca/articles/universal-login/customization-classic.md b/fr-ca/articles/universal-login/customization-classic.md
new file mode 100644
index 0000000000..6f26ed7249
--- /dev/null
+++ b/fr-ca/articles/universal-login/customization-classic.md
@@ -0,0 +1,79 @@
+---
+description: Overview of advanced customization of the login page for the Universal Login classic experience.
+topics:
+  - login
+  - universal-login
+  - customization
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Classic Universal Login UI Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+These settings, once changed, will take effect on all your Universal Login pages if you have not enabled customization of the pages' code. The settings will also work if you have enabled customization but are using the predefined templates and have not changed those options in the code.
+
+## Advanced Customization
+
+In addition to the basic settings described above, you can alter the actual code of the Universal Login flow. You can customize the HTML code for Login, Password Reset and MFA pages.
+
+![Login Page](/media/articles/universal-login/login.png)
+
+::: panel-warning Responsibility for Updates
+When the customization toggle is flipped on, you then become responsible for updates and maintenance of the pages, as it can no longer be automatically updated by Auth0. This includes updating the version numbers for any included Auth0 SDK or widget.
+
+You should also exercise caution regarding the use of third-party JavaScript on your Login Page, since sensitive security-related information often flows through the page and the introduction of cross-site scripting ([XSS](/security/common-threats#cross-site-request-forgery)) vulnerabilities is of particular concern.
+
+If you have enabled customization to inspect the page code, and then decide **not** to customize your login page, you should make sure to disable the **Customize Login Page** toggle, so Auth0 will render the default pages.
+:::
+
+
+## Login
+
+### Choose a template to begin
+
+If you intend to perform advanced customization to the content of the login page, you'll first want to choose the template that you would like to start from. You will find these templates in a dropdown just above the code editor for the login page, if you have toggled customization on. 
+
+The templates use the libraries linked below to provide the login experience for the end-user. Feel free to read the documentation for each library below, to better understand how they can be customized for your needs. 
+
+::: note
+These libraries can be used within the Universal Login page, but they can also be embedded directly into an application. While in this case we are discussing using them as part of the Universal Login flow, if you read their documentation, you will notice both use cases being explained.
+:::
+
+- [Lock](/libraries/lock) - Lock is a pre-built, customizable login widget that will allow your users to quickly and easily login to your application.
+- [Lock (Passwordless Mode)](/libraries/lock/v11#passwordless) - Lock in Passwordless Mode uses the same Lock interface, but rather than offering identity providers as login options, will simply ask the user to enter an email or SMS number to begin a passwordless authentication transaction.
+- [Auth0.js](/libraries/auth0js) - Auth0.js is the SDK used for interacting with the Auth0 [authentication API](/api/authentication). Primarily, you would use the SDK if you need to build your own custom login UI, or implement more complex functionality than simply allowing your users to login. 
+
+
+
+### Modify the code of the login page
+
+If you are using the default login page and just wish to modify it a bit further than the Simple Customization options allow, you may want to modify the behavior of the Lock widget used on the Universal Login page. The Lock widget can be configured to behave or appear in many ways, including the following:
+
+- Show the user the signup page by default instead of the login page
+- Have different colors, text, or languages shown by default on the login widget
+- Show specific connections only
+
+To learn more about how to do these, and many other customizations, take a look at the [Lock Configuration Guide](/libraries/lock/v11/configuration) for help configuring the Lock widget which is used in the page.
+
+If you intend to significantly change the page's appearance, you may wish to use the Custom Login Form template instead of the Lock template. You can use the example in the Custom Login Form template as a guideline that shows you how to get the values and information you need into the login page and how to use the Auth0.js SDK to do so, then do the styling and layout in whatever manner you wish. You may perform whatever CSS customizations that you like, as long as they are included in this one file, as there is no option to host a separate CSS file on your Auth0 tenant.
+
+## Other facets of Universal Login
+
+Auth0 offers you the ability to customize and display several other pages containing Auth0-related functionality and to which Auth0 redirects your users during the authorization process, beyond just the login page described above. You can modify the following types of pages from your [Dashboard](${manage_url}):
+
+* [Customize Hosted Password Reset Page](/universal-login/password-reset)
+* [Multi-factor Authentication Page](/universal-login/multifactor-authentication)
+* [Error Pages](/universal-login/error-pages)
+
+While Auth0 hosts these custom pages, you can still manage your pages using the [version control system of your choice](https://auth0.com/docs/universal-login/version-control).
\ No newline at end of file
diff --git a/fr-ca/articles/universal-login/customization-new.md b/fr-ca/articles/universal-login/customization-new.md
new file mode 100644
index 0000000000..256be1d688
--- /dev/null
+++ b/fr-ca/articles/universal-login/customization-new.md
@@ -0,0 +1,43 @@
+---
+description: New Universal Login UI Customization
+topics:
+  - login
+  - universal-login
+  - customization
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# New Universal Login UI Customization
+
+## Simple Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+You can also configure the favicon URL and a custom font URL using [the Branding API](/api/management/v2#!/Branding). 
+
+## Page Templates
+
+You can further the New Universal Login pages by providing a Page Template using the [Liquid template language](https://shopify.github.io/liquid/). Learn more in the [Page Template documentation](/universal-login/page-templates).
+
+## Combining New Universal Login and Classic Universal Login
+
+Given the Classic Universal Login experience is still more flexible than the New Universal Login experience, you could want to combine pages from both flows. 
+
+For example, if you want to implement Passwordless with MFA, you can use the 'Classic' login page for Passwordless and the 'New' MFA page for MFA, you can do so as follows:
+
+1. Enable the New Universal Login Experience.
+1. Customize the HTML page of the Login page with whatever content you want, for example, the `Auth0LockPasswordless` widget. 
+
+In this case, users will get a customized Classic behavior login page that allows them to log in via a passwordless connection, but will get the MFA page that looks like the New Universal Login page.
+
+Check the [Classic Universal Login customization documentation](/universal-login/customization-classic) to learn more.
diff --git a/fr-ca/articles/universal-login/default-login-url.md b/fr-ca/articles/universal-login/default-login-url.md
new file mode 100644
index 0000000000..f63742f5c8
--- /dev/null
+++ b/fr-ca/articles/universal-login/default-login-url.md
@@ -0,0 +1,77 @@
+---
+title: Tenant's and Application’s Default Login Route
+description: How to configure your tenant's and application's default login route.
+toc: true
+topics:
+  - applications
+contentType: how-to
+---
+# Configure Default Login Routes
+
+In certain cases (described below), Auth0 could need to redirect back to the application's login initiation endpoint, using [OIDC Third Party Initiated Login](https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin).
+
+You can configure these URIs in [Application Settings](/dashboard/reference/settings-application) or [Tenant Advanced Settings](/dashboard/reference/settings-tenant).
+
+You can also do this using the Management API:
+
+**Application level**
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/clients/${account.clientId}",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text": "{\"initiate_login_uri\": \"\"}"
+  }
+}
+```
+
+**Tenant level**
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text": "{\"default_redirection_uri\": \"\"}"
+  }
+}
+```
+
+The `login_url` should point to a route in the application that ends up redirecting to Auth0's `/authorize` endpoint, e.g. `https://mycompany.org/login`. Note that it requires `https` and it cannot point to `localhost`.
+
+## Scenarios for redirecting to the default login route
+
+### Users bookmarking the login page
+
+When an application initiates the login process, it navigates to `https://${account.namespace}/authorize` with a set of [required parameters](/api/authentication#login). Auth0 then redirects end-users to a `https://${account.namespace}/login` page, with a URL that looks like:
+
+`https://${account.namespace}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&...`
+
+The `state` parameter points to a record in an internal database where we track the status of the authorization transaction. Whenever the transaction completes, or after X time passes, the record is deleted from the internal database.
+
+Sometimes users bookmark the login page, and when they navigate to the bookmarked `/login` URL, the transaction record is no longer there and Auth0 cannot continue with the login flow. In that case, Auth0 will redirect to the default client URL if configured, or the tenant level URL if not. If no default login URL is set, Auth0 will render an error page.
+
+### Completing the password reset flow
+
+When the password reset flow is completed and the default URI for the application or tenant is configured, users will see a button that will let them navigate back to the login page.
+
+This behavior only happens when the [New Universal Login Experience](/universal-login/new) is enabled. In Classic mode, you will need to [configure the Redirect URL in the Password Reset Email Template](/email/templates#configuring-the-redirect-to-url).
+
+### Completing the email verification flow
+
+As part of the signup process, users get an email to verify their email address. If they click on the link, they will land on a page that says that the email was verified, with a button to go back to the application. When clicked, users will be redirected to the login page, and if they already have a valid session, they'll end up being redirected to the application.
+
+This behavior only happens when the [New Universal Login Experience](/universal-login/new) is enabled. In Classic mode, you will need to [configure the Redirect URL in the Verification Email Template](/email/templates#configuring-the-redirect-to-url).
diff --git a/fr-ca/articles/universal-login/error-pages.md b/fr-ca/articles/universal-login/error-pages.md
new file mode 100644
index 0000000000..d7ea9a8325
--- /dev/null
+++ b/fr-ca/articles/universal-login/error-pages.md
@@ -0,0 +1,51 @@
+---
+description: Guide on how to use the hosted error pages for authorization error events
+crews: crew-2
+topics:
+  - error-pages
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+
+# Error Pages
+
+## Generic Error Page
+
+Throughout the authentication process, your users may encounter errors. Auth0 provides you the option of using [custom error pages](/hosted-pages/custom-error-pages), but you may also choose to use the generic error page that Auth0 provides by default.
+
+To find the default page name for the generic error page, see [How to Use Version Control to Manage Your Universal Login Pages](/universal-login/version-control).
+
+If you configure the following fields in your [Tenant Settings](${manage_url}/#/tenant/), the provided information will be included in the generic error page:
+
+* **Friendly Name**: the name of your company
+* **Logo URL**: the URL of your company logo
+* **Support Email**: the email address of your company's support team
+* **Support URL**: the URL for your company's support page
+
+``` note
+Auth0 will display the **Tenant** information exactly as entered on the Tenant Settings page.
+```
+
+In addition to these fields, the error page returns some contextual information to assist you in troubleshooting the source of an error. The following fields will be returned based on the request which resulted in the error:
+
+* **Client ID**: the identifier for the Auth0 application
+* **Connection**: the connection used at the time of error
+* **Language**: the language set to be used at the time of error
+* **Error**: the status code corresponding to the error
+* **Error Description**: a description of the error
+* **Show Log URL**: a link to the error in your tenant logs
+* **Title**: the friendly name of the tenant
+* **Tenant**: the tenant information (friendly name, logo URL, support email, and support URL)
+
+::: note
+The error page can only return information that was available in the request. If, for example, the request which resulted in an error did not contain a `client_id`, no client ID will be returned by the error page.
+:::
+
+Fields returned by the error page will be appended as query string parameters to the page's URL.
+
+## Custom Error Pages
+
+In the event of an authorization error, you may choose to display to your users either the default Auth0 error page or a customized error page. If you choose to use a customized error page, you may do so by either redirecting users to your own error page or by updating the generic error page to display customized HTML.
+
+See [Custom Error Pages](/universal-login/custom-error-pages) for details on how to configure your own custom error page for use with Auth0.
diff --git a/fr-ca/articles/universal-login/i18n.md b/fr-ca/articles/universal-login/i18n.md
new file mode 100644
index 0000000000..2500143f81
--- /dev/null
+++ b/fr-ca/articles/universal-login/i18n.md
@@ -0,0 +1,86 @@
+---
+description: Internationalization in Universal Login
+topics:
+  - universal-login
+  - internationalization
+toc: true
+---
+# Universal Login Internationalization
+
+## Internationalization in the New Universal Login Experience
+
+The New Universal Login Experience is currently localized to the languages below, with more languages to be added over time:
+
+| Code   | Language  |
+|--------|-----------|
+| cs     | Czech     |
+| da     | Danish    |
+| de     | German    |
+| en     | English   |
+| es     | Spanish   |
+| fi     | Finnish   |
+| fr-FR  | French    |
+| fr-CA  | French (Canada) |
+| hi     | Hindi     |
+| hu     | Hungarian |
+| it     | Italian   |
+| ja     | Japanese  |
+| ko     | Korean    |
+| nb     | Norwegian |
+| nl     | Dutch     |
+| po     | Polish    |
+| pt-BR  | Portuguese (Brazilian)|
+| pt-PT  | Portuguese (Portugal) |
+| ro     | Romanian  |
+| ru     | Russian   |
+| sk     | Slovak    |
+| sv     | Swedish   |
+| zh-CN  | Chinese (Simplified)  |
+| zh-TW  | Chinese (Traditional) |
+
+### Language Selection
+
+The language to render the pages will be selected based on:
+
+- The languages supported by Auth0, which are listed above.
+- The list of languages configured in Tenant Settings, where you can select the languages your tenant supports and select a default one. By default, the list has only English, so if you want to support other languages you first need to update the list.
+- The value of the `ui_locales` parameter sent to the [authorization request endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), which can be used to constrain the language list for an application or session.
+- The `Accept-Language` HTTP header sent by the browser. The pages will be rendered in this language if it is allowed by the settings above. If not, pages will be rendered in the default language.
+
+### Setting the tenant supported languages
+
+You can set the supported and default languages in the Dashboard's [Tenant Settings](${manage_url}/#/tenant) section.
+
+![](/media/articles/universal-login/languages.png)
+
+You can also specify the enabled languages for the tenant via the Management API using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings). The first language in the list will be the default one.
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"enabled_locales\" : [ \"en\", \"es\"]}"
+  }
+}
+```
+
+### Current Limitations
+
+- It is not possible for you to add additional languages (although Auth0 will be adding more over time).
+- The `ui_locales` parameter can only be used in OAuth flows, as it’s not available in SAML or WS-Federation.
+- The `ui_locales` parameter is not forwarded to upstream IdPs.
+- It is not possible to localize the scopes in the Consent page.
+
+## Internationalization in the Classic Universal Login Experience
+
+In the Classic Universal Login experience, localization is done using our JavaScript widgets for [login](/libraries/lock/v11/i18n), the [password reset page](/universal-login/password-reset) and [password policies](/i18n/password-options). 
+
+The [MFA page](/universal-login/multifactor-authentication) by default uses the Auth0 MFA Widget, which cannot be localized. You can create localized versions by using [guardian.js](https://github.com/auth0/auth0-guardian.js).
+
+It is not possible to localize the Consent page.
diff --git a/fr-ca/articles/universal-login/index.md b/fr-ca/articles/universal-login/index.md
new file mode 100644
index 0000000000..1753159969
--- /dev/null
+++ b/fr-ca/articles/universal-login/index.md
@@ -0,0 +1,93 @@
+---
+description: Overview of Universal Login with Auth0
+topics:
+  - login
+  - universal-login
+  - password-reset
+  - mfa
+  - error-pages
+  - hosted-pages
+contentType: index
+toc: true
+useCase: customize-hosted-pages
+---
+# Auth0 Universal Login
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. Each time a user needs to prove their identity, your applications redirect to Universal Login and Auth0 will do what is needed to guarantee the user's identity. 
+
+By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. You can start off using a simple username and password. With a simple toggle switch, you can add new features such as social login and multi-factor authentication (MFA). All of this is dynamic, and adjustable in real-time without requiring application-level changes, since all functionality is driven dynamically by the web pages served by the centralized Authentication Server. Your application will benefit from all improvements Auth0 does in the login flow without you changing a single line of code. 
+
+The login page appearance and behavior is customizable right from the [Dashboard](${manage_url}). The logo and colors of the login pages can be changed, and in more advanced use cases, the code of each page itself can be modified.
+
+For information on the differences between Universal Login and traditional embedded login within your application, see [our comparison guide](/guides/login/universal-vs-embedded).
+
+## Choosing an experience
+
+There are two available experiences in Universal Login. The Classic Universal Login Experience uses JavaScript controls for each page. The New Universal Login experience does not _require_ JavaScript to work, and it offers a simpler and faster experience for end-users.
+
+In the Dashboard, the dialog shown below lets you select which Experience will be used for default, non-customized pages:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+**Choose an experience to learn more about:**
+
+* [Classic Universal Login Experience](/universal-login/classic)
+* [New Universal Login Experience](/universal-login/new) (and its [current limitations](/universal-login/new-experience-limitations))
+
+## Customizing Universal Login
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+You can further customize login pages:
+
+- Customizing the [Classic Universal Login Experience](/universal-login/customization-classic)
+- Customizing the [New Universal Login Experience](/universal-login/customization-new)
+
+## Implement Universal Login
+
+In addition to configuring Universal Login for your tenant's applications, you will also need to complete a few other steps:
+
+1. Set up a connection(s) in the [Dashboard](${manage_url}) (Choose **Connections** in the Dashboard's sidebar, then choose a type and pick one to configure, such as a database or a social login provider). 
+1. Set up your application in the [Dashboard](${manage_url}/#/applications). 
+1. Configure your application's code to call Auth0's [`/authorize`](/api/authentication#login) endpoint in order to trigger Universal Login, and then to deal with the response. You can either do this directly, or use one of our SDKs to make the process easier.
+
+### Navigating to the login page
+
+You can navigate to the login page from any browser:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  state=STATE
+```
+
+You can (optionally) specify a connection, but you must [specify a state](/protocols/oauth2/oauth-state) and choose whether you want a `code` or `token` response (the choice you make depends on your app type and the flow you are using). Finally, make sure to fill in the domain, client ID, and redirect URI if they haven't been pre-filled.
+
+### Using the SPA SDK
+
+If you are already using Auth0's [Single-Page App SDK](/libraries/auth0-spa-js), using the `auth0.loginWithRedirect()` or `auth0.loginWithPopup()` methods will bring you to the authorize endpoint.
+
+```html
+
+```
+
+```js
+$('#login').click(async () => {
+  await auth0.loginWithRedirect();
+});
+```
+
+### Further instructions
+
+<%= include('./_implement_universal_login') %>
diff --git a/fr-ca/articles/universal-login/multifactor-authentication.md b/fr-ca/articles/universal-login/multifactor-authentication.md
new file mode 100644
index 0000000000..f8df08134a
--- /dev/null
+++ b/fr-ca/articles/universal-login/multifactor-authentication.md
@@ -0,0 +1,63 @@
+---
+description: Learn how to customize the MFA page.
+topics:
+  - mfa
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+# Multi-factor Authentication with Classic Universal Login
+
+You can enable [Multi-factor authentication](/mfa) from the [Dashboard > Multifactor Auth](${manage_url}/#/mfa) section.
+
+![Universal Login MFA Page](/media/articles/mfa/mfa-dashboard.png)
+
+You can customize the MFA pages using the Universal Login's [basic customization features](/universal-login#simple-customization). 
+
+If you need further customizations, you can provide your own HTML for the MFA page. 
+
+::: note
+When using your own HTML, it uses the Auth0 MFA Widget, which has the following limitations:
+- It does not support MFA with Email.
+- If users enrolled more than one factor, they cannot select which one to use, the MFA widget will ask them to login with the most secure factor.
+- It does not use Universal Login's [internationalization](/universal-login/i18n) features
+::: 
+
+## Customize the HTML for the MFA page
+
+To customize the MFA page, go to [Dashboard > Universal Login > Guardian Multi-factor](${manage_url}/#/mfa_page) and enable the __Customize Guardian Page__ switch.
+
+Once you do that, you'll be able to use the text editor built into the Auth0 Dashboard to change your HTML, style your page using CSS, and alter the JavaScript used to retrieve custom variables. Once you've made your changes, and make sure to click __Save__.
+
+If you'd like to revert to an earlier design, you have two options:
+
+* Reverting to the last saved template by clicking **Reset to Last**;
+* Reverting to the default template provided by Auth0 by clicking **Reset to Default**.
+
+Please note that MFA page works without customization (Auth0 will also update the included scripts as required). However, once you toggle the customization to **on**, you are responsible for the updating and maintaining the script (including changing version numbers, such as that for the MFA widget), since Auth0 can no longer update it automatically.
+
+For information about how to override the text for many areas of the MFA process on Universal Login Classic Experience, see [MFA Configuration Options](/mfa/references/language-dictionary).
+
+For information about the MFA Widget Theme options, see [MFA Widget Theme Options](/mfa/references/mfa-widget-reference).
+
+## Render "Invited Enrollments" vs. Standard Scenarios
+
+There are two different possible scenarios in which the page is rendered. If a user has been directed to this page specifically for enrollment (for instance, from an email with an enrollment link) then the property **ticket** will be available. Otherwise, the property **requestToken** will be available.
+
+## HTML + Liquid syntax
+
+The hosted page uses [Liquid](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) syntax for templating.
+The following parameters are available to assist in rendering your page:
+
+* `userData.email` 
+* `userData.friendlyUserId`
+* `userData.tenant`
+* `userData.tenantFriendlyName`
+* `iconUrl`
+
+Most of the parameters that are used in the MFA Widget need to be passed to Guardian as shown in the default template provided in the customization area.
+If you need a higher level of customization you could use [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js/tree/master/example).
+
+::: note
+For information about customizing MFA with the New Universal Login Experience, see [Customize Multi-factor Authentication](/mfa/guides/customize-mfa-universal-login).
+:::
diff --git a/fr-ca/articles/universal-login/new-experience-limitations.md b/fr-ca/articles/universal-login/new-experience-limitations.md
new file mode 100644
index 0000000000..1d8ef31edf
--- /dev/null
+++ b/fr-ca/articles/universal-login/new-experience-limitations.md
@@ -0,0 +1,31 @@
+---
+description: New Universal Login Limitations
+topics:
+  - login
+  - universal-login
+contentType: index
+toc: true
+---
+# New Universal Login Experience Limitations
+
+The New Universal Login Experience currently has these limitations:
+
+- You can create [Page Templates](/universal-login/page-templates) to customize the universal login flow UI, but you can't create a completely custom UI. If you want to do that, you need to customize the HTML pages for each prompt (Login / Password Reset / MFA), where by default you will get pages that behave like the Classic Experience. 
+
+- [Identifier-First login](/universal-login/identifier-first) is not available. This would allow users to login with their corporate email addresses and be redirected to their enterprise's login pages. The current implementation will add a button for each enterprise connection. This makes it not suitable for this scenario which is very common for B2B customers.
+
+- [Kerberos](/connector/kerberos) for AD/LDAP connections is not supported. Users will still be able to type their credentials to log in using an AD/LDAP connection, but only if:
+  - the username is in email format.
+  - there are no other database connections enabled.
+
+- The Signup page only lets users enter username / email / password, and does not offer the ability to prompt users to accept terms of service.
+
+- You cannot specify additional fields to have the user fill out in the signup page. Users can only sign up with username, email and password. If you need to capture additional data, you will need to do it after signup, from within your application (such as with [progressive profiling](/users/concepts/overview-progressive-profiling)).
+
+- In order to be able to use [DUO](/mfa/guides/configure-cisco-duo) as an MFA factor, it needs to be the only factor enabled. It will render the same pages as in the Classic Experience.
+
+- [Passwordless login](/connections/passwordless) is not supported.
+
+- [MFA Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket) will keep using the Classic Experience even when the New Experience is enabled.
+
+- When starting password reset by a call to the Management API password change endpoint, the password reset UI doesn't grant the user the option to click a button to redirect after the password change is complete (when using the New Universal Login Experience).
diff --git a/fr-ca/articles/universal-login/new.md b/fr-ca/articles/universal-login/new.md
new file mode 100644
index 0000000000..a49d7e6c84
--- /dev/null
+++ b/fr-ca/articles/universal-login/new.md
@@ -0,0 +1,99 @@
+---
+description: New Universal Login Experience
+topics:
+  - login
+  - universal-login
+contentType: index
+toc: true
+---
+# New Universal Login Experience
+
+Auth0's New Universal Login Experience provides a reimagined login flow, with a fresh UX design and lightweight pages. When you pick this new experience, Auth0 will use it for all pages that haven't been customized. You can enable it from the [Universal Login Settings](${manage_url}/#/login_settings) dashboard section:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+The key structural difference from the [Classic Experience](/universal-login/classic) is that the former uses Javascript widgets in all the pages, while the New Experience is rendered on the server and does not require Javascript. 
+
+From a functional perspective, the New Experience has much better support for [Localization](/universal-login/i18n), consistent UI customization with [Page Templates](/universal-login/page-templates), a better MFA experience, and several improvements across all pages. 
+
+The New Experience is being actively developed, so new features are regularly added. However, there is still a [feature gap](/universal-login/new-experience-limitations) with the Classic Experience, and some pages in the New Experience have certain differences detailed below.
+
+## User Interface Customization
+
+Learn how to [customize](/universal-login/customization-new) the New Universal Login user interface.
+
+## Internationalization
+
+The New Experience provides a consistent approach for [Internationalization](/universal-login/i18n). 
+
+## Text Customization
+
+You can override any text in the New Experience by using the [Text Customization API](/universal-login/text-customization). 
+
+## Login
+
+- If you are using Development Keys for Social Providers:
+
+    - Single Sign-on (SSO) and Silent Authentication will work properly, which does not happen in the Classic Experience.
+
+    - Users will see a warning in the login page mentioning that the tenant is configured with [Development Keys](/connections/social/devkeys).
+
+- A button will be rendered for each social and enterprise connection. 
+
+- A 'show password' icon will be displayed next to the password field.
+
+- If you redirect users to the `/login` page directly, they will get an error unless they have configured the [default login route](/universal-login/default-login-url). You should always redirect users to the proper authorization request endpoint (e.g., `/authorize` if you are using OpenID Connect).
+
+- You can specify the `login_hint` when redirecting to Auth0, and it will be used to populate the username/email field for the login or signup page.
+
+## Signup
+
+- You can make users land directly on the Signup page instead of the Login page by specifying the `screen_hint=signup` parameter when redirecting to `/authorize`. Note that this can be combined with `prompt=login`, which indicates whether you want to always show the authentication page or you want to skip if there's an existing session. 
+
+|`/authorize` parameters | No existing session  | Existing session |
+|--|--|--|
+|no extra parameters   | Shows the login page  | Redirects to the callback url |
+|`screen_hint=signup`  | Shows the signup page | Redirects to the callback url |
+|`prompt=login`        | Shows the login page  | Shows the login page          |
+|`prompt=login&screen_hint=signup`| Shows the signup page | Shows the signup page |
+
+## Multi-Factor Authentication
+
+- If users have more than one multi-factor authentication (MFA) factor enrolled (e.g., SMS and Push notifications), the new MFA page will let the user select which one they want to use.
+
+- You can use [Email as an MFA factor](/mfa/concepts/mfa-factors#email-notifications).
+
+- You can use [Voice as an MFA factor](/mfa/concepts/mfa-factors#voice-notifications).
+
+- If you are using the Guardian SDK to create your own native application to handle Push Notifications, you can configure the name of the application and the URLs to download them in the "Push via Auth0 Guardian" option in the MFA [Dashboard > MFA](${manage_url}/#/mfa) section.
+
+- If you have a rule that sets the MFA provider to `google-authenticator` you need to enable the OTP factor in the [Dashboard > MFA](${manage_url}/#/mfa) section.
+
+## Password Reset
+
+- In the Classic Experience, you can [configure a url](/email/templates#redirect-to-results-for-the-change-password-email-template) to redirect users after completing the password reset. The URL will receive a success indicator and a message. The New Experience will redirect the users to the [default login route](/universal-login/default-login-url) when it succeeds and will handle the error cases as part of the Universal Login flow. The Redirect URL in the email template will be ignored.  
+
+Please note that you must provide an **Application Login URI** under [Application Settings](/dashboard/reference/settings-application) for the redirect URLs to work.
+
+- A 'show password' icon will be displayed next to the password fields.
+
+- If the Database Connection is set to ['Require Username'](/connections/database/require-username), the password reset flow will ask the user for the username and send a password reset email to the associated email address.
+
+## Email Verification
+
+- After a user clicks the email verification link, they'll be redirected to a page that will confirm that their email is verified. If the [default login route](/universal-login/default-login-url) is configured, users will be able to click a button and get redirected to it.
+
+## Consent
+
+- The logo and colors selected in the dashboard configuration section will be properly applied. (Recommended logo size is 150 x 150 pixels.)
+
+## Custom DB Connections
+
+When using [Custom DB Connections](/connections/database/custom-db):
+
+- The password reset flow will function properly even if you return errors from the change password script.
+- The [errors](/connections/database/custom-db/error-handling) returned in `ValidationErrors` or `WrongUsernameOrPasswordError` will be displayed in the corresponding pages.
+
+## Implement Universal Login
+
+<%= include('./_implement_universal_login') %>
diff --git a/fr-ca/articles/universal-login/page-templates.md b/fr-ca/articles/universal-login/page-templates.md
new file mode 100644
index 0000000000..f04413f65a
--- /dev/null
+++ b/fr-ca/articles/universal-login/page-templates.md
@@ -0,0 +1,253 @@
+---
+description: Customizing the New Universal Login Page with Page Templates
+topics:
+  - universal-login
+  - internationalization
+toc: true
+beta: true
+---
+# Customizing the New Universal Login Pages with Pages Templates
+
+You can customize the New Universal Login pages by providing a Page Template using the [Liquid template language](https://shopify.github.io/liquid/). 
+
+::: warning
+This capability can only be used if the tenant has [Custom Domains](/custom-domains) enabled.
+:::
+
+Page Templates let you define the content that is displayed around the Universal Login widgets (e.g. the Login box, the MFA box). The same template is used for all pages, which helps you to implement a consistent login with minimum effort.
+
+The simplest template you can write is:
+
+```html
+
+
+  
+    {%- auth0:head -%}
+  
+  
+    {%- auth0:widget -%}
+  
+
+```
+
+The following tags need to be present in the template:
+
+|||
+|:-----------------|:------------|
+|`auth0:widget`| Includes the HTML for the widget that is displayed in every page (Login, Reset Password, etc.) |
+|`auth0:head`| Includes tags that are required to render the widget |
+
+## Page Templates Variables
+
+The Page Templates have a set of context variables that can be used to impact how the page is rendered. This allows you to implement scenarios like:
+
+* Render different content depending on the Application (for example, you own two brands that need a different page design).
+* Render different content depending on the Prompt (for example, in the Login page you want to add content explaining what the application does, but in the MFA flow, you prefer to only have the MFA box).
+* Add a footer with links to the tenant's support page or email.
+
+### Available Variables
+
+The available variables are:
+
+* The login page [application's settings](/dashboard/reference/settings-application#basic-settings):
+    * application.id
+    * application.name
+    * application.logo_uri
+    * application.metadata
+
+* Universal Login [branding settings](${manage_url}/#/login_settings):
+    * branding.logo_url
+    * branding.colors.primary
+    * branding.colors.page_background
+
+* Tenant's [settings](/dashboard/reference/settings-tenant#basic-settings):
+    * tenant.friendly_name
+    * tenant.support_email
+    * tenant.support_url
+
+* Information about the current universal login screen.
+    * locale: Locale used to render the login pages, matching one of the [supported tenant languages](/universal-login/i18n)
+    * prompt.name: The name of the Universal Login prompt being rendered 
+    * prompt.screen.name: The name of the Universal Login screen being rendered.
+    * prompt.screen.texts: All the [localized texts](/universal-login/text-customization) needed in the screen being rendered.
+  
+  <%= include('text-customization-prompts/_prompt_definition') %>
+
+
+* Information about the current user, for pages rendered after the user authenticates:
+    * user.user_id
+    * user.picture
+    * user.email
+    * user.email_verified
+    * user.app_metadata
+    * user.user_metadata
+    * user.family_name
+    * user.given_name
+    * user.name
+    * user.nickname
+    * user.username
+
+## CSS Customization
+
+Given you can edit the HTML for the Universal Login page, you could also override the CSS classes that are used in the Universal Login widgets. **This is not supported yet**. 
+
+If you override the CSS for our built-in classes, your login page **will break** whenever we change the CSS used in the page. However, certain level of CSS customization will be supported in the future.
+
+## Examples
+
+### Login Box + Image Layout
+
+The following template will show the login box to the left, and an image to the right only for the login / signup pages. The rest of the pages will look like the default ones.
+
+```html
+
+
+  
+    {%- auth0:head -%}
+    
+    {{ prompt.screen.texts.pageTitle }}
+  
+  
+    {% if prompt.name == "login" or prompt.name == "signup" %} 
+        
    
+        {%- auth0:widget -%}
+        
    
+    {% else %}
+        {%- auth0:widget -%}
+    {% endif %}
+  
+
+```
+![Page Templates Layout](/media/articles/universal-login/page-templates-layout.png)
+
+### Page Footers
+
+The example below adds a gray footer with links to Privacy Policy and Terms of Services:
+
+```html
+
+
+  
+    {%- auth0:head -%}
+    
+     {{ prompt.screen.texts.pageTitle }}
+  
+  
+    {%- auth0:widget -%}
+    
+  
+
+```
+
+![Page Templates Footer](/media/articles/universal-login/page-templates-footer.png)
+## Page Templates API
+
+To set the Page Template you need to use the Management API. You first need to get a Management API token with the `update:branding`,`read:branding`, `delete:branding` scopes. If you are using the 'API Explorer Application' to generate tokens, make sure those scopes are enabled for the 'Auth0 Management API'.
+
+To set the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "PUT",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Content-Type", "value": "text/html" }
+  ],
+  "postData": {
+    "mimeType": "text/html",
+    "text": "{%- auth0:head -%}{%- auth0:widget -%}"
+  }
+}
+```
+
+To retrieve the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+  ]
+}
+```
+
+To delete the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "DELETE",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+  ]
+}
+```
+
+:::note
+The maximum size for the Page Template is 100KB. If that is not big enough, consider moving images/css files outside of the Page Template code.
+:::
+
+## Troubleshooting
+
+If the template is not being applied, check that you are navigating to `/authorize`. When you navigate to `${account.namespace}/authorize` Auth0 will not render the page template.
diff --git a/fr-ca/articles/universal-login/password-reset.md b/fr-ca/articles/universal-login/password-reset.md
new file mode 100644
index 0000000000..965874977c
--- /dev/null
+++ b/fr-ca/articles/universal-login/password-reset.md
@@ -0,0 +1,136 @@
+---
+description: Learn how to customize a hosted password reset page.
+topics:
+  - password-reset
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Customize Hosted Password Reset Page
+
+::: note
+If you are:
+
+* An administrator trying to reset a user's password, see [Change Users' Passwords](/connections/database/password-change)
+* A user trying to reset your own password, see [Reset Auth0 Account Password](/support/reset-account-password)
+:::
+
+The Password Reset Page provides your applications' users with a way to change their passwords if they can't log in.
+
+With the Password Reset Page, Auth0 handles all required functionality, including:
+
+* Hosting the page itself
+* Redirecting the user wanting to reset their password as necessary (there is no URL to which the user can point their browsers)
+* Ensuring that the user's password meets your stated requirements and is updated accordingly
+* Automatically redirecting the user after they reset their password
+
+The Password Reset Page includes use of the Password Reset Widget. You can, however, [customize the page](/universal-login/customization-classic) to display the personalized information you deem appropriate and to maintain consistency in the appearance of your Auth0 pages (e.g., Login, Password Reset, and MFA).
+
+## Enable Customization of the Password Reset Page
+
+By default, the Password Reset Page is enabled for all Auth0 users. The Password Reset Page **works as is *without* customization**. However, if you want to change the page to match your other pages and present your branding, you can enable customization of the Password Reset Page.
+
+To do so, log in to the [Dashboard](${manage_url}/#/password_reset). Go to **Universal Login** > **Password Reset**. Toggle **Customize Password Reset Page** to enable customization. 
+
+![Hosted Password Reset Page](/media/articles/universal-login/password-reset.png)
+
+## Edit the Password Reset Page
+
+Once you've enabled the customization toggle for the Password Reset Page, you can use the built-in text editor to change its HTML, style the page using CSS, and change the JavaScript used to retrieve and display custom variables. Be sure to **Save** any changes you make.
+
+### Display custom information on the Password Reset Page
+
+You can display personalized information on the Password Reset Page. This is done by editing the embedded JavaScript using the Password Reset Page Editor:
+
+```js
+  
+```
+
+For example, the sample template snippet below shows the variable `tenant.picture_url`. This variable returns the **Logo URL** value defined in [Tenant Settings](${manage_url}/#/tenant).
+
+```js
+  
+```
+
+Auth0 retrieves the logo at the URL and displays it on the Password Reset Widget. If Auth0 can't resolve the URL, it'll display that the default image.
+
+#### Custom variables
+
+The following custom variables can be used to display personalized information on the Password Reset Page:
+
+| Variable | Description |
+| - | - |
+| `email` | The email address of the user requesting the password change | 
+| `ticket` | The ticket representing the given password reset request | 
+| `csrf_token` | Token used to prevent CSRF activity | 
+| `tenant.name` | The name associated with your Auth0 tenant | 
+| `tenant.friendly_name` | The name displayed for your Auth0 tenant | 
+| `tenant.picture_url` | The URL leading to the logo representing you in Auth0 | 
+| `tenant.support_email` | The support email address for your company displayed to your Auth0 users |
+| `tenant.support_url` | The support URL for your company displayed to your Auth0 users | 
+| `lang` | The user's language | 
+| `password_policy` | The active connection's security policy. You can see what this is using `${manage_url}/#/connections/database/con_YOUR-CONNECTION-ID/security`. Be sure to provide your connection ID in the URL.) |
+| `password_complexity_options` | Object containing settings for the password complexity requirements |
+| `min_length` | The minimum length required for newly-created passwords. Can range from 1 to 128 characters in length | 
+
+**Notes:**
+
+* You can set/check the values for your `tenant` variables in the **Settings** area in [Tenant Settings](${manage_url}/#/tenant)
+* You cannot conditionalize customizations based on the Application ID (`client_id`).
+
+## Update the Password Reset Widget
+
+ If you **do not enable customization of the Password Reset Page**, Auth0 will handle updates necessary for the script, including changes to the version number of the included Password Reset Widget.
+
+**Once you have enabled customization of the Password Reset Page, it is your responsibility to update and maintain the script**. This includes updating the version number for the Password Reset Widget. With customization enabled, Auth0 cannot update your script automatically without potentially interfering with changes you've made. 
+
+## Revert your changes
+
+If you'd like to revert the Password Reset Page to an earlier design, you have two options:
+
+* Reverting to the last saved template by clicking **Reset to Last**;
+* Reverting to the default template provided by Auth0 by clicking **Reset to Default**.
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/_prompt_definition.md b/fr-ca/articles/universal-login/text-customization-prompts/_prompt_definition.md
new file mode 100644
index 0000000000..6deafd6d70
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/_prompt_definition.md
@@ -0,0 +1,3 @@
+The term `prompt` is used to refer to a specific step in the login flow. Each `prompt` can have one or more screens. Below is the list of available prompts, and you can find all the screens for each one by following the links:
+
+<%= include('_prompts') %>
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/_prompts.md b/fr-ca/articles/universal-login/text-customization-prompts/_prompts.md
new file mode 100644
index 0000000000..2cb6ef964e
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/_prompts.md
@@ -0,0 +1,24 @@
+- [consent](/universal-login/text-customization-prompts/consent)
+- [device-flow](/universal-login/text-customization-prompts/device-flow)
+- [email-otp-challenge](/universal-login/text-customization-prompts/email-otp-challenge)
+- [email-verification](/universal-login/text-customization-prompts/email-verification)
+- [invitation](/universal-login/text-customization-prompts/invitation)
+- [login](/universal-login/text-customization-prompts/login)
+- [login-email-verification](/universal-login/text-customization-prompts/login-email-verification)
+- [login-id](/universal-login/text-customization-prompts/login-id)
+- [login-password](/universal-login/text-customization-prompts/login-password)
+- [logout](/universal-login/text-customization-prompts/logout)
+- [mfa](/universal-login/text-customization-prompts/mfa)
+- [mfa-email](/universal-login/text-customization-prompts/mfa-email)
+- [mfa-otp](/universal-login/text-customization-prompts/mfa-otp)
+- [mfa-phone](/universal-login/text-customization-prompts/mfa-phone)
+- [mfa-push](/universal-login/text-customization-prompts/mfa-push)
+- [mfa-recovery-code](/universal-login/text-customization-prompts/mfa-recovery-code)
+- [mfa-sms](/universal-login/text-customization-prompts/mfa-sms)
+- [mfa-voice](/universal-login/text-customization-prompts/mfa-voice)
+- [mfa-webauthn](/universal-login/text-customization-prompts/mfa-webauthn)
+- [organizations](/universal-login/text-customization-prompts/organizations)
+- [reset-password](/universal-login/text-customization-prompts/reset-password)
+- [signup](/universal-login/text-customization-prompts/signup)
+- [signup-id](/universal-login/text-customization-prompts/signup-id)
+- [signup-password](/universal-login/text-customization-prompts/signup-password)
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/common.md b/fr-ca/articles/universal-login/text-customization-prompts/common.md
new file mode 100755
index 0000000000..986a88477d
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/common.md
@@ -0,0 +1,13 @@
+# Prompt: common
+
+## Screen: redeem-ticket
+
+
    
+  redeem-ticket reference screenshot
+
    
+
+|Key|Value|
+|----------|----------|
+|pageTitle|Loading...|
+|description|Javascript is not enabled on your browser, please click button to continue.|
+|buttonText|Continue|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/consent.md b/fr-ca/articles/universal-login/text-customization-prompts/consent.md
new file mode 100644
index 0000000000..dd8686c924
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/consent.md
@@ -0,0 +1,22 @@
+# Prompt: consent
+
+## Screen: consent
+
+
    
+  consent reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Authorize <%= "${clientName}" %>|`pageTitle`|
+|Authorize App|`title`|
+|Hi <%= "${userName}" %>,|`pickerTitle`|
+|Tenant and Audience selector|`audiencePickerAltText`|
+|<%= "${clientName}" %> is requesting access to your account.|`messageMultipleTenants`|
+|<%= "${clientName}" %> is requesting access to your <%= "${companyName}" %> account.|`messageSingleTenant`|
+|Accept|`acceptButtonText`|
+|Decline|`declineButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Invalid action|`invalid-action`|
+|Audience is required|`invalid-audience`|
+|Invalid scope, must be an array|`invalid-scope`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/device-flow.md b/fr-ca/articles/universal-login/text-customization-prompts/device-flow.md
new file mode 100644
index 0000000000..47c986c704
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/device-flow.md
@@ -0,0 +1,60 @@
+# Prompt: device-flow
+
+## Screen: device-code-activation
+
+
    
+  device-code-activation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your device code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|Enter the code displayed on your device|`description`|
+|Enter your one-time code|`placeholder`|
+|Device Activation|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Please enter the code displayed on your device|`no-code`|
+|The code you entered is invalid|`invalid-code`|
+
+## Screen: device-code-activation-allowed
+
+
    
+  device-code-activation-allowed reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Login successful | <%= "${clientName}" %>|`pageTitle`|
+|Your device is now connected.|`description`|
+|Congratulations, you're all set!|`eventTitle`|
+
+## Screen: device-code-activation-denied
+
+
    
+  device-code-activation-denied reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Login error | <%= "${clientName}" %>|`pageTitle`|
+|We are not able to activate your device.|`description`|
+|Activation Denied|`eventTitle`|
+
+## Screen: device-code-confirmation
+
+
    
+  device-code-confirmation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Confirm your device code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Please confirm this is the code displayed on your <%= "${clientName}" %>:|`description`|
+|Secure code|`inputCodeLabel`|
+|Device Confirmation|`title`|
+|Confirm|`confirmButtonText`|
+|Cancel|`cancelButtonText`|
+|If you did not initiate this action or you do not recognize this device select cancel.|`confirmationText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/email-otp-challenge.md b/fr-ca/articles/universal-login/text-customization-prompts/email-otp-challenge.md
new file mode 100644
index 0000000000..eed23ea0a6
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/email-otp-challenge.md
@@ -0,0 +1,22 @@
+# Prompt: email-otp-challenge
+
+## Screen: email-otp-challenge
+
+
    
+  email-otp-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|We've sent an email with your code to <%= "${email}" %>|`description`|
+|Enter the code|`placeholder`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Identity|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/email-verification.md b/fr-ca/articles/universal-login/text-customization-prompts/email-verification.md
new file mode 100644
index 0000000000..5be91db924
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/email-verification.md
@@ -0,0 +1,22 @@
+# Prompt: email-verification
+
+## Screen: email-verification-result
+
+
    
+  email-verification-result reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Email verification status | <%= "${clientName}" %>|`pageTitle`|
+|Email Verified|`verifiedTitle`|
+|Error|`errorTitle`|
+|Your email address was successfully verified.|`verifiedDescription`|
+|This account is already verified.|`alreadyVerifiedDescription`|
+|User account does not exist or the verification code is invalid.|`invalidAccountOrCodeDescription`|
+|Your email address could not be verified.|`unknownErrorDescription`|
+|Back to <%= "${clientName}" %>|`buttonText`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/invitation.md b/fr-ca/articles/universal-login/text-customization-prompts/invitation.md
new file mode 100644
index 0000000000..c7f8e2c459
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/invitation.md
@@ -0,0 +1,15 @@
+# Prompt: invitation
+
+## Screen: accept-invitation
+
+
    
+  accept-invitation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Accept your invitation to sign up | <%= "${clientName}" %>|`pageTitle`|
+|You've Been Invited!|`title`|
+|<%= "${inviterName}" %> has invited you (<%= "${email}" %>) to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`description`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/login-email-verification.md b/fr-ca/articles/universal-login/text-customization-prompts/login-email-verification.md
new file mode 100644
index 0000000000..9df537aa48
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/login-email-verification.md
@@ -0,0 +1,23 @@
+# Prompt: login-email-verification
+
+## Screen: login-email-verification
+
+
    
+  login-email-verification reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|We've sent an email with your code to <%= "${email}" %>|`description`|
+|Enter the code|`placeholder`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Email|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/login-id.md b/fr-ca/articles/universal-login/text-customization-prompts/login-id.md
new file mode 100644
index 0000000000..3b6adb518f
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/login-id.md
@@ -0,0 +1,44 @@
+# Prompt: login-id
+
+## Screen: login-id
+
+
    
+  login-id reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Phone number|`phonePlaceholder`|
+|Edit|`editEmailText`|
+|Alerts|`alertListTitle`|
+|Enter a valid phone number|`error-invalid-phone-number`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|Email does not match any enterprise directory|`no-hrd-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/login-password.md b/fr-ca/articles/universal-login/text-customization-prompts/login-password.md
new file mode 100644
index 0000000000..0f0f999b43
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/login-password.md
@@ -0,0 +1,48 @@
+# Prompt: login-password
+
+## Screen: login-password
+
+
    
+  login-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your password to log in | <%= "${clientName}" %>|`pageTitle`|
+|Enter Your Password|`title`|
+|Enter your password for <%= "${companyName}" %> to continue to <%= "${clientName}" %>|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Forgot password?|`forgotPasswordText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Edit email address|`editLinkScreenReadableText`|
+|Alerts|`alertListTitle`|
+|You've Been Invited!|`invitationTitle`|
+|Log in to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use Fingerprint or Face Recognition|`useBiometricsText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/login.md b/fr-ca/articles/universal-login/text-customization-prompts/login.md
new file mode 100644
index 0000000000..24366e6e9c
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/login.md
@@ -0,0 +1,46 @@
+# Prompt: login
+
+## Screen: login
+
+
    
+  login reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Forgot password?|`forgotPasswordText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Alerts|`alertListTitle`|
+|You've Been Invited!|`invitationTitle`|
+|Log in to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/logout.md b/fr-ca/articles/universal-login/text-customization-prompts/logout.md
new file mode 100644
index 0000000000..462232eba0
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/logout.md
@@ -0,0 +1,17 @@
+# Prompt: logout
+
+## Screen: logout
+
+
    
+  logout reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Logout | <%= "${clientName}" %>|`pageTitle`|
+|Logout|`title`|
+|Hi <%= "${userName}" %>,|`userSalute`|
+|Are you sure you want to log out from <%= "${clientName}" %>?|`description`|
+|Yes|`acceptButtonText`|
+|No|`declineButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-email.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-email.md
new file mode 100644
index 0000000000..99b440c987
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-email.md
@@ -0,0 +1,40 @@
+# Prompt: mfa-email
+
+## Screen: mfa-email-challenge
+
+
    
+  mfa-email-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Go Back|`backText`|
+|Continue|`buttonText`|
+|We've sent an email with your code to|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Identity|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|We couldn't send the email. Please try again later.|`mfa-email-challenge-authenticator-error`|
+
+## Screen: mfa-email-list
+
+
    
+  mfa-email-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available email addresses | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Enrolled Email Addresses|`title`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-otp.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-otp.md
new file mode 100644
index 0000000000..737b738045
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-otp.md
@@ -0,0 +1,66 @@
+# Prompt: mfa-otp
+
+## Screen: mfa-otp-enrollment-qr
+
+
    
+  mfa-otp-enrollment-qr reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Scan the code to log in using a one-time password | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Scan the QR Code below using your preferred authenticator app and then enter the provided one-time code below.|`description`|
+|Continue|`buttonText`|
+|Trouble Scanning?|`codeEnrollmentText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Then|`separatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|You are already enrolled on MFA.|`user-already-enrolled`|
+
+## Screen: mfa-otp-enrollment-code
+
+
    
+  mfa-otp-enrollment-code reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Copy the code to log in using a one-time password | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Continue|`buttonText`|
+|Secure code to copy|`altText`|
+|Copy code|`copyCodeButtonText`|
+|Manually enter the following code into your preferred authenticator app and then enter the provided one-time code below.|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Secure Your Account|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+
+## Screen: mfa-otp-challenge
+
+
    
+  mfa-otp-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your one-time password to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Check your preferred one-time password application for a code.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use password|`usePasswordText`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-phone.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-phone.md
new file mode 100644
index 0000000000..43373360ab
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-phone.md
@@ -0,0 +1,57 @@
+# Prompt: mfa-phone
+
+## Screen: mfa-phone-challenge
+
+
    
+  mfa-phone-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use your phone number to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We will send a 6-digit code to the following phone number:|`description`|
+|Continue|`continueButtonText`|
+|Choose another phone number.|`changePhoneText`|
+|Text message|`smsButtonText`|
+|Voice call|`voiceButtonText`|
+|How do you want to receive the code?|`chooseMessageTypeText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|There was a problem making the voice call|`send-voice-failed`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|It seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-phone-enrollment
+
+
    
+  mfa-phone-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a phone code | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your country code and phone number to which we can send a 6-digit code:|`description`|
+|Continue|`continueButtonText`|
+|Text message|`smsButtonText`|
+|Voice call|`voiceButtonText`|
+|How do you want to receive the code?|`chooseMessageTypeText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|There was a problem making the voice call|`send-voice-failed`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|It seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-push.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-push.md
new file mode 100644
index 0000000000..ae05b309d5
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-push.md
@@ -0,0 +1,74 @@
+# Prompt: mfa-push
+
+## Screen: mfa-push-welcome
+
+
    
+  mfa-push-welcome reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Install the application | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|In order to continue, install the <%= "${appName}" %> app via the app store from your mobile device.|`description`|
+|Google Play|`androidButtonText`|
+|Continue|`buttonText`|
+|App Store|`iosButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+
+## Screen: mfa-push-enrollment-qr
+
+
    
+  mfa-push-enrollment-qr reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Scan the code to log in using a push notification | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Scan the QR Code below using the <%= "${appName}" %> app on your mobile device.|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|You must scan the QR code with the <%= "${appName}" %> app on your mobile device.|`enrollment-transaction-pending`|
+
+## Screen: mfa-push-challenge-push
+
+
    
+  mfa-push-challenge-push reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Accept the push notification to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We’ve sent a notification to the following device via the <%= "${appName}" %> app:|`description`|
+|I've responded on my device|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive a notification?|`resendText`|
+|Manually Enter Code|`enterOtpCode`|
+|OR|`separatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|You must accept the notification via the <%= "${appName}" %> app on your mobile device.|`challenge-transaction-pending`|
+|We have not received a confirmation, please slow down.|`polling-interval-exceeded`|
+|We have received too many notification requests. Wait a few minutes and try again.|`too-many-push`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|We have not received a confirmation, please try scanning the code again.|`mfa-push-verify-transaction-pending`|
+|We couldn't verify the enrollment. Please try again later.|`mfa-push-verify-authenticator-error`|
+|We couldn't send the notification. Please try again later.|`mfa-push-challenge-authenticator-error`|
+|Notification rejected|`transaction-rejected`|
+
+## Screen: mfa-push-list
+
+
    
+  mfa-push-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available devices | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Registered Devices|`title`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-recovery-code.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-recovery-code.md
new file mode 100644
index 0000000000..48cd305483
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-recovery-code.md
@@ -0,0 +1,41 @@
+# Prompt: mfa-recovery-code
+
+## Screen: mfa-recovery-code-enrollment
+
+
    
+  mfa-recovery-code-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Copy your recovery code for safe keeping | <%= "${clientName}" %>|`pageTitle`|
+|Almost There!|`title`|
+|Copy this recovery code and keep it somewhere safe. You’ll need it if you ever need to log in without your device.|`description`|
+|Secure code to copy|`altText`|
+|Continue|`buttonText`|
+|I have safely recorded this code|`checkboxText`|
+|Copy code|`copyCodeButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Please confirm you have recorded the code|`no-confirmation`|
+
+## Screen: mfa-recovery-code-challenge
+
+
    
+  mfa-recovery-code-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your recovery code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Enter the recovery code you were provided during your initial enrollment.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your recovery code|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The code you entered is invalid|`invalid-code`|
+|Recovery code must have 24 alphanumeric characters|`invalid-code-format`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Please confirm you have recorded the code|`no-confirmation`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-sms.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-sms.md
new file mode 100644
index 0000000000..a5aa3222dd
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-sms.md
@@ -0,0 +1,80 @@
+# Prompt: mfa-sms
+
+## Screen: mfa-country-codes
+
+
    
+  mfa-country-codes reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Select your country code | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Select a Country Code|`title`|
+
+## Screen: mfa-sms-enrollment
+
+
    
+  mfa-sms-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a text message | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your phone number below. An SMS will be sent to that number with a code to enter on the next screen.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|Seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-sms-challenge
+
+
    
+  mfa-sms-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We've sent a text message to:|`description`|
+|Continue|`buttonText`|
+|Edit|`editText`|
+|Edit phone number|`editLinkScreenReadableText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the 6-digit code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive a code?|`resendText`|
+|or|`resendVoiceActionSeparatorTextBefore`|
+|get a call|`resendVoiceActionText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+
+## Screen: mfa-sms-list
+
+
    
+  mfa-sms-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available phone numbers | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Enrolled Phone Numbers|`title`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-voice.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-voice.md
new file mode 100644
index 0000000000..4917d756dc
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-voice.md
@@ -0,0 +1,56 @@
+# Prompt: mfa-voice
+
+## Screen: mfa-voice-enrollment
+
+
    
+  mfa-voice-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a phone code | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your phone number below. A voice call will be placed on that number with a code to enter on the next screen.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|Seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-voice-challenge
+
+
    
+  mfa-voice-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We've sent a 6-digit code via voice phone call to the following phone number:|`description`|
+|Continue|`buttonText`|
+|Edit|`editText`|
+|Edit phone number|`editLinkScreenReadableText`|
+|Choose another phone number.|`changePhoneText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the 6-digit code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Call again|`resendActionText`|
+|Didn't receive a call?|`resendText`|
+|or|`resendSmsActionSeparatorTextBefore`|
+|send a text|`resendSmsActionText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|There was a problem making the voice call|`send-voice-failed`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|We couldn't make the voice call. Please try again later.|`voice-authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa-webauthn.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa-webauthn.md
new file mode 100644
index 0000000000..d1a5be36e1
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa-webauthn.md
@@ -0,0 +1,153 @@
+# Prompt: mfa-webauthn
+
+## Screen: mfa-webauthn-platform-enrollment
+
+
    
+  mfa-webauthn-platform-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in faster on this device | <%= "${clientName}" %>|`pageTitle`|
+|Log In Faster on This Device|`title`|
+|Trust this device? You can quickly and securely log in the next time using this device's fingerprint or face recognition.|`description`|
+|Awaiting device confirmation|`awaitingConfirmation`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Continue|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remind me later|`snoozeEnrollmentButtonText`|
+|Not on this device|`refuseAddingDeviceText`|
+|Not now|`skipAddingDeviceText`|
+|We could not start the device enrollment. Please try again later.|`webauthn-platform-associate-error`|
+
+## Screen: mfa-webauthn-roaming-enrollment
+
+
    
+  mfa-webauthn-roaming-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Register your security key | <%= "${clientName}" %>|`pageTitle`|
+|Adding Your Security Key|`title`|
+|Security Keys can be used as an additional authentication factor.|`description`|
+|Awaiting Security Key|`awaitingConfirmation`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use security key|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Connect your Security Key and continue.|`instructions1`|
+|Follow the steps on the browser.|`instructions2`|
+|Name your Security Key to easily identify it later.|`instructions3`|
+|We could not start the security key enrollment. Please try again later.|`webauthn-associate-error`|
+
+## Screen: mfa-webauthn-platform-challenge
+
+
    
+  mfa-webauthn-platform-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use fingerprint or face recognition to login | <%= "${clientName}" %>|`title`|
+|Press the button below and follow your browser's steps to log in.|`description`|
+|Awaiting device confirmation|`awaitingConfirmation`|
+|Too many failed authentication attempts. Please try again later.|`too-many-webauthn-challenge-attempts-error`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Continue|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Use password|`usePasswordText`|
+|Remember this device for 30 days|`rememberMeText`|
+|We could not start the device verification. Please try again later.|`webauthn-platform-challenge-error`|
+
+## Screen: mfa-webauthn-roaming-challenge
+
+
    
+  mfa-webauthn-roaming-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use your security key to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Make sure your Security Key is nearby. Once you continue, you will be prompted to use it.|`description`|
+|Awaiting Security Key|`awaitingConfirmation`|
+|Too many failed authentication attempts. Please try again later.|`too-many-webauthn-challenge-attempts-error`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use security key|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remember this device for 30 days|`rememberMeText`|
+|We could not start the security key verification. Please try again later.|`webauthn-challenge-error`|
+
+## Screen: mfa-webauthn-change-key-nickname
+
+
    
+  mfa-webauthn-change-key-nickname reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Name your security key | <%= "${clientName}" %>|`title`|
+|If you own multiple keys, this alias will help you identify the right one.|`description`|
+|<%= "${userName}" %>'s key|`nickname`|
+|Security key name|`nicknamePlaceholder`|
+|Name your device | <%= "${clientName}" %>|`titlePlatform`|
+|If you own multiple devices, this alias will help you identify the right one.|`descriptionPlatform`|
+|<%= "${userName}" %>'s <%= "${deviceName}" %>|`nicknamePlatform`|
+|Device name|`nicknamePlaceholderPlatform`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|We could not update your key's name. Please try again.|`webauthn-patch-nickname-error`|
+|We could not update your Device's name. Please try again.|`webauthn-platform-patch-nickname-error`|
+|Name is required|`no-nickname`|
+|Name is too short|`nickname-too-short`|
+|Name is too long|`nickname-too-long`|
+|An error occurred while retrieving your information. Please try again.|`error-while-retrieving-authenticator`|
+|An error occurred while trying to save the name . Please try again.|`error-while-patching`|
+
+## Screen: mfa-webauthn-enrollment-success
+
+
    
+  mfa-webauthn-enrollment-success reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Security key successful | <%= "${clientName}" %>|`title`|
+|Device registration successful | <%= "${clientName}" %>|`titlePlatform`|
+|You have successfully registered your Security Key.|`description`|
+|You have successfully registered your device.|`descriptionPlatform`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+
+## Screen: mfa-webauthn-error
+
+
    
+  mfa-webauthn-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Try again|`tryAgainLinkText`|
+|Try another method|`pickAuthenticatorText`|
+|Security key registration error | <%= "${clientName}" %>|`errorTitle`|
+|Security Key Verification Failed|`errorTitleChallenge`|
+|Device registration error | <%= "${clientName}" %>|`errorTitlePlatform`|
+|Something Went Wrong|`errorTitlePlatformChallenge`|
+|Something went wrong. Please try again or try using another method.|`description`|
+|If you already registered this device, please try again. If not, try using another method.|`descriptionPlatform`|
+|No Thanks|`refuseAddingAuthenticatorText`|
+|Use password|`usePasswordText`|
+
+## Screen: mfa-webauthn-not-available-error
+
+
    
+  mfa-webauthn-not-available-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Security keys are not supported | <%= "${clientName}" %>|`pageTitle`|
+|Security Keys Are Not Supported|`errorTitle`|
+|We are sorry but your browser or device does not support Security Keys. Try using another browser or log in from another device.|`errorDescription`|
+|Try another method|`pickAuthenticatorText`|
+|Use password|`usePasswordText`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/mfa.md b/fr-ca/articles/universal-login/text-customization-prompts/mfa.md
new file mode 100644
index 0000000000..283fa545a0
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/mfa.md
@@ -0,0 +1,80 @@
+# Prompt: mfa
+
+## Screen: mfa-detect-browser-capabilities
+
+
    
+  mfa-detect-browser-capabilities reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Try another method|`pickAuthenticatorText`|
+|Reload|`reloadButtonText`|
+|JavaScript Required|`noJSErrorTitle`|
+|Your browser does not have JavaScript enabled. Please enable and press the Reload page button.|`noJSErrorDescription`|
+
+## Screen: mfa-enroll-result
+
+
    
+  mfa-enroll-result reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|MFA enrollment status|`pageTitle`|
+|You're All Set!|`enrolledTitle`|
+|You have successfully added a new authentication factor.|`enrolledDescription`|
+|Invalid Link|`invalidTicketTitle`|
+|This link is invalid or expired.|`invalidTicketDescription`|
+|Expired Link|`expiredTicketTitle`|
+|This link is expired.|`expiredTicketDescription`|
+|Already used|`alreadyUsedTitle`|
+|This link has already been used. Please get a new link to enroll with Multi-factor Authentication.|`alreadyUsedDescription`|
+|Two-factor Verification has Already Been Enabled.|`alreadyEnrolledDescription`|
+|Something Went Wrong|`genericError`|
+
+## Screen: mfa-login-options
+
+
    
+  mfa-login-options reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of other login methods | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Other Methods|`title`|
+|SMS|`authenticatorNamesSMS`|
+|Phone|`authenticatorNamesVoice`|
+|Phone|`authenticatorNamesPhone`|
+|Notification via <%= "${appName}" %> app|`authenticatorNamesPushNotification`|
+|Google Authenticator or similar|`authenticatorNamesOTP`|
+|Email|`authenticatorNamesEmail`|
+|Recovery code|`authenticatorNamesRecoveryCode`|
+|Notification via DUO app|`authenticatorNamesDUO`|
+|Security Key|`authenticatorNamesWebauthnRoaming`|
+|Fingerprint or Face Recognition|`authenticatorNamesWebauthnPlatform`|
+
+## Screen: mfa-begin-enroll-options
+
+
    
+  mfa-begin-enroll-options reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Add another authentication method | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Keep Your Account Safe|`title`|
+|Add another authentication method.|`description`|
+|<%= "${companyName}" %>|`logoAltText`|
+|SMS|`authenticatorNamesSMS`|
+|Phone|`authenticatorNamesVoice`|
+|Phone|`authenticatorNamesPhone`|
+|Notification via <%= "${appName}" %> app|`authenticatorNamesPushNotification`|
+|Google Authenticator or similar|`authenticatorNamesOTP`|
+|Email|`authenticatorNamesEmail`|
+|Recovery code|`authenticatorNamesRecoveryCode`|
+|Notification via DUO app|`authenticatorNamesDUO`|
+|Security Key|`authenticatorNamesWebauthnRoaming`|
+|Fingerprint or Face Recognition|`authenticatorNamesWebauthnPlatform`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/organizations.md b/fr-ca/articles/universal-login/text-customization-prompts/organizations.md
new file mode 100644
index 0000000000..0cf5837020
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/organizations.md
@@ -0,0 +1,17 @@
+# Prompt: organizations
+
+## Screen: organization-selection
+
+
    
+  organization-selection reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your organization | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|Enter your <%= "${companyName}" %> Organization Name to continue|`description`|
+|Enter your Organization Name|`placeholder`|
+|Enter Organization|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The organization you entered is invalid|`invalid-organization`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/reset-password.md b/fr-ca/articles/universal-login/text-customization-prompts/reset-password.md
new file mode 100644
index 0000000000..dcb8debd5c
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/reset-password.md
@@ -0,0 +1,103 @@
+# Prompt: reset-password
+
+## Screen: reset-password-request
+
+
    
+  reset-password-request reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Reset your password | <%= "${clientName}" %>|`pageTitle`|
+|Forgot Your Password?|`title`|
+|Back to <%= "${clientName}" %>|`backToLoginLinkText`|
+|Continue|`buttonText`|
+|Enter your email address and we will send you instructions to reset your password.|`descriptionEmail`|
+|Enter your username and we will send you instructions to reset your password.|`descriptionUsername`|
+|Email address|`placeholderEmail`|
+|Username|`placeholderUsername`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Email is not valid.|`invalid-email-format`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We had a problem sending the email, please try again later.|`reset-password-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-requests`|
+|Please enter an email address|`no-email`|
+|Username is required|`no-username`|
+
+## Screen: reset-password-email
+
+
    
+  reset-password-email reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Check your email | <%= "${clientName}" %>|`pageTitle`|
+|Check Your Email|`title`|
+|Please check the email address <%= "${email}" %> for instructions to reset your password.|`emailDescription`|
+|Resend email|`resendLinkText`|
+|Please check the email address associated with the username <%= "${email}" %> for instructions to reset your password.|`usernameDescription`|
+
+## Screen: reset-password
+
+
    
+  reset-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Reset your password | <%= "${clientName}" %>|`pageTitle`|
+|Change Your Password|`title`|
+|Enter a new password below to change your password.|`description`|
+|Reset password|`buttonText`|
+|New password|`passwordPlaceholder`|
+|Re-enter new password|`reEnterpasswordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Password contains user information|`password-contains-user-information`|
+
+## Screen: reset-password-success
+
+
    
+  reset-password-success reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Password reset successful | <%= "${clientName}" %>|`pageTitle`|
+|Password Changed!|`eventTitle`|
+|Your password has been changed successfully.|`description`|
+|Back to <%= "${clientName}" %>|`buttonText`|
+
+## Screen: reset-password-error
+
+
    
+  reset-password-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Password reset error | <%= "${clientName}" %>|`pageTitle`|
+|Back to <%= "${clientName}" %>|`backToLoginLinkText`|
+|To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionExpired`|
+|To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionGeneric`|
+|This link has already been used. To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionUsed`|
+|Link Expired|`eventTitleExpired`|
+|Invalid Link|`eventTitleGeneric`|
+|Invalid Link|`eventTitleUsed`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We had a problem sending the email, please try again later.|`reset-password-error`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/signup-id.md b/fr-ca/articles/universal-login/text-customization-prompts/signup-id.md
new file mode 100644
index 0000000000..e7d89bd0c8
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/signup-id.md
@@ -0,0 +1,49 @@
+# Prompt: signup-id
+
+## Screen: signup-id
+
+
    
+  signup-id reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Sign up | <%= "${clientName}" %>|`pageTitle`|
+|Create Your Account|`title`|
+|Sign Up to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Phone number|`phonePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|Enter a valid phone number|`error-invalid-phone-number`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Email does not match any enterprise directory|`no-hrd-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/signup-password.md b/fr-ca/articles/universal-login/text-customization-prompts/signup-password.md
new file mode 100644
index 0000000000..50e26d2102
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/signup-password.md
@@ -0,0 +1,54 @@
+# Prompt: signup-password
+
+## Screen: signup-password
+
+
    
+  signup-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Create a password to sign up | <%= "${clientName}" %>|`pageTitle`|
+|Create Your Account|`title`|
+|Set your password for <%= "${companyName}" %> to continue to <%= "${clientName}" %>|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Edit email address|`editLinkScreenReadableText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|Accept your invitation to sign up | <%= "${clientName}" %>|`invitationTitle`|
+|Sign Up to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Password contains user information|`password-contains-user-information`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
+|This combination of credentials was detected in a public data breach on another website. Before your account is created, please use a different password to keep it secure.|`password-breached`|
diff --git a/fr-ca/articles/universal-login/text-customization-prompts/signup.md b/fr-ca/articles/universal-login/text-customization-prompts/signup.md
new file mode 100644
index 0000000000..137e38141f
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization-prompts/signup.md
@@ -0,0 +1,50 @@
+# Prompt: signup
+
+## Screen: signup
+
+
    
+  signup reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Sign up | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Sign Up to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Email address|`emailPlaceholder`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Password contains user information|`password-contains-user-information`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
+|This combination of credentials was detected in a public data breach on another website. Before your account is created, please use a different password to keep it secure.|`password-breached`|
diff --git a/fr-ca/articles/universal-login/text-customization.md b/fr-ca/articles/universal-login/text-customization.md
new file mode 100644
index 0000000000..eddd3e613f
--- /dev/null
+++ b/fr-ca/articles/universal-login/text-customization.md
@@ -0,0 +1,107 @@
+---
+description: Text Customization for the New Universal Login Experience
+topics:
+  - universal-login
+  - localization
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Text Customization for the New Universal Login Experience
+
+The New Universal Login Experience consists of a set of pages that perform several account-related actions such as logging in, enrolling multi-factor authentication factors, or changing their password. The text displayed on those pages is provided by Auth0 in several languages. 
+
+In some cases you might wish to modify the wording on these pages to better match your application's tone or specific needs.
+
+Auth0 provides an API that you can use to customize all the text displayed in the [New Universal Login Experience](/universal-login/new) for every [supported language](/universal-login/i18n).
+
+The API is defined with the following structure:
+
+```
+PUT '/api/v2/prompts/PROMPT/custom-text/LANGUAGE',
+{
+ "SCREEN1": {
+   "TEXT1_ID": "text1 in language"
+ },
+ "SCREEN2": {
+   "TEXT2_ID": "text2 in language"
+ }
+}
+ ```
+ 
+You need to provide the proper values to the `prompt`, `language`, `screen`, `text id` fields.
+
+You can find the list of available languages on the [Universal Login Internationalization page](/universal-login/i18n).
+
+<%= include('text-customization-prompts/_prompt_definition') %>
+
+Each screen has a set of `text id`s, which are listed in the documentation for each prompt linked above.
+
+## Available variables 
+
+Some screens have variables in the text that are replaced in runtime based on context information. The available variables are different per-screen, so it is not guaranteed that they will work anywhere other than the screens they originally appear in. 
+
+| Variable | Description |
+| ------------- |-------------| 
+| <%= "${clientName}" %>| Auth0 Application Name | 
+| <%= "${connectionName}" %> | Connection Name (e.g. 'Google')
+| <%= "${companyName}" %>| Auth0 Tenant name| 
+| <%= "${userName}" %>| Name of the logged user| 
+| <%= "${email}" %> | Email of the logged user| 
+| <%= "${appName}" %>| Name of the custom Guardian Push application | 
+
+## Calling the API
+
+You can use the GET and PUT HTTP verbs when calling the API. Note that PUT will replace all customizations for specific prompts with the new ones. If you customized one screen and then want to customize another one, you will need to send both when updating the prompt's text.
+
+To call the API you need an Access Token that has the `read:prompts` and `update:prompts` scopes. If you are using the API Explorer Machine to Machine application, make sure the scopes are selected.
+
+### Examples
+
+If you want to change the **description** field for the `login` prompt so that it does not say "Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>" you can do it with the following  API call:
+
+```har
+{
+	"method": "PUT",
+	"url": "https://${account.namespace}/api/v2/prompts/login/custom-text/en",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": 
+	[
+	    { "name": "Content-Type", "value": "application/json" },
+		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	],
+	"queryString": [],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"login\": { \"description\": \"Login to ACME's Website\" } }"
+	},
+	"headersSize": -1,
+	"bodySize": -1,
+	"comment": ""
+}
+```
+
+If you want to delete all custom text for the `login` prompt you can send an empty array:
+
+```har
+{
+	"method": "PUT",
+	"url": "https://${account.namespace}/api/v2/prompts/login/custom-text/en",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": 
+	[
+	    { "name": "Content-Type", "value": "application/json" },
+		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	],
+	"queryString": [],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ }"
+	},
+	"headersSize": -1,
+	"bodySize": -1,
+	"comment": ""
+}
+```
diff --git a/fr-ca/articles/universal-login/version-control.md b/fr-ca/articles/universal-login/version-control.md
new file mode 100644
index 0000000000..571f0310dc
--- /dev/null
+++ b/fr-ca/articles/universal-login/version-control.md
@@ -0,0 +1,38 @@
+---
+description: Learn how to back up your Universal Login pages using the Auth0 version control extensions
+topics:
+  - version-control
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+# How to Use Version Control to Manage Your Universal Login Pages
+
+You can use version control software to manage the source code of your pages.
+To do so, you can use the Auth0-provided extension that works with the version control system you're using:
+
+* [GitLab Extension](/extensions/gitlab-deploy#deploy-hosted-pages)
+* [GitHub Extension](/extensions/github-deploy#deploy-hosted-pages)
+* [BitBucket Extension](/extensions/bitbucket-deploy#deploy-hosted-pages)
+* [Visual Studio Team Services Extension](/extensions/visual-studio-team-services-deploy#deploy-hosted-pages)
+
+While the specific documentation pages contain detailed information for the extensions, the general deploying process requires just the following steps:
+
+1. Create a folder in your version control repository with the appropriate name (`pages`).
+2. Create an HTML page (`login.html`, `password_reset.html`, `guardian_multifactor.html`, or `error_page.html`) within your folder.
+3. Create a JSON file with the same name as your HTML page for each hosted page that you wish to source control. To enable the page, the JSON file needs to contain the following:
+
+```json
+{
+  "enabled": true
+}
+```
+
+
+### File Naming Example
+
+
+```text
+your-repo/pages/error_page.html
+your-repo/pages/error_page.json
+```
diff --git a/fr-ca/articles/users/_includes/_account-linking-id-tokens.md b/fr-ca/articles/users/_includes/_account-linking-id-tokens.md
new file mode 100644
index 0000000000..a0f35dedb5
--- /dev/null
+++ b/fr-ca/articles/users/_includes/_account-linking-id-tokens.md
@@ -0,0 +1,3 @@
+::: panel Account Linking ID Token Usage Deprecated
+Previously, in some cases, you could use [ID Tokens](/tokens/concepts/id-tokens) to link and unlink user accounts. This functionality is being deprecated. You will have to use Access Tokens in all cases. The change in the unlinking of accounts is that you can no longer use an ID Token in the `Authorization` header. An Access Token must be used instead. The functionality is still available but not recommended and affected users are encouraged to migrate. See [Migration Guide: Account Linking with Access Tokens vs. ID Tokens](/migrations/guides/account-linking) for details.
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/users/_includes/_connection-synch-note.md b/fr-ca/articles/users/_includes/_connection-synch-note.md
new file mode 100644
index 0000000000..a9f14724eb
--- /dev/null
+++ b/fr-ca/articles/users/_includes/_connection-synch-note.md
@@ -0,0 +1,3 @@
+::: note
+Rather than storing profile-related information in `user_metadata`, you can edit these user attributes on the normalized user profile. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+:::
\ No newline at end of file
diff --git a/fr-ca/articles/users/_includes/_password-encoding-description.md b/fr-ca/articles/users/_includes/_password-encoding-description.md
new file mode 100644
index 0000000000..0031b41049
--- /dev/null
+++ b/fr-ca/articles/users/_includes/_password-encoding-description.md
@@ -0,0 +1,20 @@
+The encoding of the password used to generate the hash. Must be one of:
+
+* `ascii`
+* `utf8`
+* `utf16le`
+* `ucs2`
+* `latin1`
+* `binary`
+
+On login, the user-provided password will be transcoded from `password.encoding` before being checked against the provided hash.
+
+For example; if your hash was generated from a `ucs2` encoded string, then you would set:
+
+```json
+{
+  "password": {
+    "encoding": "ucs2"
+  }
+}
+```
\ No newline at end of file
diff --git a/fr-ca/articles/users/_includes/_user-prop-identities.md b/fr-ca/articles/users/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..cbd83244dd
--- /dev/null
+++ b/fr-ca/articles/users/_includes/_user-prop-identities.md
@@ -0,0 +1,9 @@
+Contains info retrieved from the identity provider with which the user originally authenticates. Users may also [link their profile to multiple identity providers](/users/concepts/overview-user-account-linking); those identities will then also appear in this array. The contents of an individual identity provider object varies by provider, but it will typically include the following:
+
+- `connection` (text): Name of the Auth0 connection used to authenticate the user.
+- `isSocial` (boolean): Indicates whether the connection is a social one.
+- `provider` (text): Name of the entity that is authenticating the user, such as Facebook, Google, SAML, or your own provider.
+- `user_id` (text): User's unique identifier for this connection/provider.
+- `profileData` (object): User info associated with the connection. When profiles are linked, it is populated with the associated user info for secondary accounts.
+
+In some cases, it will also include an API Access Token to be used with the provider. 
\ No newline at end of file
diff --git a/fr-ca/articles/users/concepts/overview-progressive-profiling.md b/fr-ca/articles/users/concepts/overview-progressive-profiling.md
new file mode 100644
index 0000000000..b6595ba26b
--- /dev/null
+++ b/fr-ca/articles/users/concepts/overview-progressive-profiling.md
@@ -0,0 +1,55 @@
+---
+description: Understand how progressive profiling can gather more information about your users over time as they engage with your website or application thereby enhancing their experience by not asking them too many questions up front.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - progressive-profiling
+contentType: concept
+useCase: manage-users
+v2: true
+---
+# Progressive Profiling
+
+Progressive profiling is the act of collecting more information about your users over time as they engage with your website or application. This way, you can gather just the right amount of information at just the right time and enhance your users' experience by not asking them too many questions at signup. For example, you might collect just the user's name, email, and password on initial signup. At the next login, you might ask for the name of their company and their title or their birth date. When asking users for additional information, avoid asking for information that you may already have. For example, if a user signs up using a social network you may already have some of the information you need. 
+
+Progressive profiling provides the following benefits:
+
+* Shorter registration forms
+* Higher conversion rates
+* Collecting more relevant information about your users
+* Enhancing the user experience by avoiding repetitious questions
+
+::: note
+Users logging in with social networks will typically **consent** to disclose their information.
+:::
+
+## How progressive profiling works with Auth0
+
+Every time a user authenticates through Auth0, Auth0 updates their user profile and with data that can come from different sources:
+
+* Properties supplied by the identity provider (such as LinkedIn, Facebook, or any [connection](/identityproviders)).
+* Attributes that are dynamically created in [Auth0 Rules](/rules) .
+* Attributes obtained by calling APIs such as [FullContact](https://www.fullcontact.com/) and [Clearbit](https://clearbit.com/).
+* Application-specific attributes that developers can collect in their apps and save. In Auth0, this information is called **user metadata**.
+
+![Progressive Profiling](/media/articles/user-profile/progressive-profiling.png)
+
+The first source is generally not directly related to **progressive profiling** however it can supply some user information. 
+
+You can use redirect Rules to collect more information than was given at initial signup like the user's birthday. For an example of how to create rules to implement progressive profiling, see [Progressive Profiling example](/rules/guides/redirect#progressive-profiling-example).
+
+You can use the Auth0 [Users API](/api/v2#!/Users/patch_users_by_id) to augment the profile of any authenticated user with any information. Auth0 metadata objects can contain any serializable data structure. Auth0 provides two [metadata](/users/concepts/overview-user-metadata) attributes: **user metadata** and **app metadata**. You can update the contents of your metadata fields with the [Management APIv2](/api/management/v2). It is up to you what information to collect, when to collect it, and how to collect it. Each application implements progressive profiling differently. Your application may already do so, in fact. 
+
+The use of progressive profiling within your application makes it very easy to control what information gets collected and when. As this happens, you can enrich the user profile with the data you've collected:
+
+![Progressive profiling example](/media/articles/user-profile/progressive-profiling-example.png)
+
+In the example above, the application collects **last name** and **first name** on signup. It then collects the user's **title** and **company** at a later point. Finally, in the context of an article that might interest the user, the app adds information to the **subscribed** property. 
+
+## Keep reading
+
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users From Within Rules](/rules/guides/redirect)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
+
diff --git a/fr-ca/articles/users/concepts/overview-user-account-linking.md b/fr-ca/articles/users/concepts/overview-user-account-linking.md
new file mode 100644
index 0000000000..d872887ad9
--- /dev/null
+++ b/fr-ca/articles/users/concepts/overview-user-account-linking.md
@@ -0,0 +1,204 @@
+---
+title: User Account Linking
+description: Understand how user accounts can be linked in Auth0 from various identity providers.
+crews: crew-2
+toc: true
+topics:
+  - account-linking
+contentType:
+  - concept
+useCase:
+  - manage-accounts
+---
+# User Account Linking
+
+Auth0 supports the linking of user accounts from various identity providers. This allows a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. This feature requires a paid subscription to the **Developer**, **Developer Pro** or **Enterprise** plan (see [Pricing](https://auth0.com/pricing)).
+
+Auth0 treats all identities as separate by default. For example, if a user logs in first against the Auth0 database and then via Google or Facebook, these two attempts would appear to Auth0 as two separate users. You can implement functionality to enable a user to explicitly link accounts. In this scenario, the user would log in with an initial provider, perhaps Google. Your application would provide a link or button to enable them to link another account to the first one.  The user would click on this link/button and your application would make a call so that when the user logs in with the second provider, the second account is linked with the first.
+
+## Advantages of linking accounts
+
+* Allows users to log in with any identity provider without creating a separate profile for each
+* Allows registered users to use a new social or passwordless login but continue using their existing profile
+* Allows users that registered using a passwordless login to link to an account with a more complete profile
+* Allows your apps to retrieve user profile data stored in various connections
+
+## How it works
+
+The process of linking accounts merges two existing user profiles into a single one. When linking accounts, a **primary account** and a **secondary account** must be specified.
+
+In the example below you can see how the resulting linked profile will be for the sample primary and secondary accounts.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        {
+  "email": "your0@email.com",
+  "email_verified": true,
+  "name": "John Doe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "picture": "https://lh3.googleusercontent..../photo.jpg",
+  "gender": "male",
+  "locale": "en",
+  "user_id": "google-oauth2|115015401343387192604",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "115015401343387192604",
+      "connection": "google-oauth2",
+      "isSocial": true
+    }
+  ],
+  "user_metadata": {
+    "color": "red"
+  },
+  "app_metadata": {
+    "roles": [
+      "Admin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+    
    
+      
    +        {
+  "phone_number": "+14258831929",
+  "phone_verified": true,
+  "name": "+14258831929",
+  "updated_at": "2015-10-08T18:35:18.102Z",
+  "user_id": "sms|560ebaeef609ee1adaa7c551",
+  "identities": [
+    {
+      "user_id": "560ebaeef609ee1adaa7c551",
+      "provider": "sms",
+      "connection": "sms",
+      "isSocial": false
+    }
+  ],
+  "user_metadata": {
+    "color": "blue"
+  },
+  "app_metadata": {
+    "roles": [
+      "AppAdmin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+    
    
+      
    +        {
+  "email": "your0@email.com",
+  "email_verified": true,
+  "name": "John Doe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "picture": "https://lh3.googleusercontent..../photo.jpg",
+  "gender": "male",
+  "locale": "en",
+  "user_id": "google-oauth2|115015401343387192604",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "115015401343387192604",
+      "connection": "google-oauth2",
+      "isSocial": true
+    },
+    {
+      "profileData": {
+        "phone_number": "+14258831929",
+        "phone_verified": true,
+        "name": "+14258831929"
+      },
+      "user_id": "560ebaeef609ee1adaa7c551",
+      "provider": "sms",
+      "connection": "sms",
+      "isSocial": false
+    }
+  ],
+  "user_metadata": {
+    "color": "red"
+  },
+  "app_metadata": {
+    "roles": [
+      "Admin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+  
    
+
    
+
+Note that:
+
+* The `user_id` and all other main profile properties continue to be those of the primary identity
+* The secondary account is now embedded in the `identities` array of the primary profile
+* The attributes of the secondary account are placed inside the `profileData` field of the corresponding identity inside the array
+* The `user_metadata` and `app_metadata` of the primary account have not changed
+* The `user_metadata` and `app_metadata` of the secondary account are discarded
+* There is no automatic merging of user profiles with associated identities
+* The secondary account is removed from the users list
+
+### Metadata merge
+
+[Metadata](/users/concepts/overview-user-metadata) are not automatically merged during account linking. If you want to merge them you have to do it manually, using the [Auth0 APIv2 Update User endpoint](/api/v2#!/Users/patch_users_by_id).
+
+The [Auth0 Node.js SDK for APIv2](https://github.com/auth0/node-auth0/tree/v2) is also available. 
+
+## Scenarios
+
+There are two different ways of implementing account linking:
+
+* [User-initiated account linking](#user-initiated-account-linking): allow your users to link their accounts using an admin screen in your app.
+* [Suggested account linking](#suggested-account-linking): identify accounts with the same email address and prompt the user in your app to link them.
+
+### User-initiated account linking
+
+Typically, account linking will be initiated by an authenticated user. Your app must provide the UI, such as a **Link accounts** button on the user's profile page.
+
+![Sample user profile page](/media/articles/link-accounts/spa-user-settings.png)
+
+You can read more about how to implement user-initiated account linking in a Single Page Application in the [Client-Side Account Linking](/users/references/link-accounts-client-side-scenario) article.
+
+### Suggested account linking
+
+You can find accounts with the same email, and prompt the users to link them. For example, a user can create an account with Google with the user@gmail.com, and then log in with Facebook, with an account linked to the same email. 
+
+If that occurs, you can show users the list of available accounts so they can link them, by first authenticating with the account they will be linking to.
+
+You can also use the [Account Link Extension](/extensions/account-link) to achieve the same outcome. 
+
+![Suggested Account Linking](/media/articles/link-accounts/account-linking-webapp-small.png)
+
+You can read more about how to implement user-initiated account linking in a Regular Web Application in the [Server-Side Account Linking](/users/references/link-accounts-server-side-scenario) article.
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/fr-ca/articles/users/concepts/overview-user-metadata.md b/fr-ca/articles/users/concepts/overview-user-metadata.md
new file mode 100644
index 0000000000..44fed097d4
--- /dev/null
+++ b/fr-ca/articles/users/concepts/overview-user-metadata.md
@@ -0,0 +1,61 @@
+---
+description: Understand how user metadata and app metadata can be used to store information that does not originate from an identity provider.
+topics: 
+   - metadata
+   - rules
+   - endpoints
+contentType: concept
+useCase: manage-users
+---
+
+# Metadata
+
+In addition to the [Normalized User Profile](/users/normalized) information, you can use metadata to store information that does not originate from an identity provider, or that overrides what an identity provider supplies.
+
+There are three types of data typically stored in the `app_metadata` field:
+
+* **Permissions**: privileges granted to certain users allowing them rights within the application that others do not have.
+* **Plan information**: settings that cannot be changed by the user without confirmation from someone with the appropriate authority.
+* **External IDs**: identifying information used to associate users with external accounts. 
+
+Auth0 distinguishes between two types of metadata used to store specific kinds of information:
+
+* **User metadata**: stores user attributes such as preferences that do *not* impact a user's core functionality. Logged in users can edit their data stored in `user_metadata` if you build a form for them using the Management API [`PATCH` endpoint](/api/management/v2#!/Users/patch_users_by_id) with the scope `update:current_user_metadata`. 
+* **App metadata**: stores information (such as, support plan subscriptions, security roles, or access control groups) that can impact a user's core functionality, such as how an application functions or what the user can access. Data stored in `app_metadata` cannot be edited by users. See [App metadata restrictions](/best-practices/metadata-best-practices#app-metadata-restrictions) for what cannot be stored in this field. 
+
+::: note
+Data unrelated to user authentication should always be stored in an external database and not in the user profile metadata. 
+:::
+
+In the following example, the user `jane.doe@example.com` has the following metadata stored with their profile. 
+
+```json
+{
+    "emails": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+In the above example metadata, within a [Rule](/rules) or via a [call to the Management API](/users/guides/read-metadata), you could reference specific items from the data set as follows:
+
+```js
+console.log(user.email); // "jane.doe@example.com"
+console.log(user.user_metadata.hobby); // "surfing"
+console.log(user.app_metadata.plan); // "full"
+```
+
+<%= include('../_includes/_connection-synch-note.md') %>
+
+## Keep reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [User Metadata in Rules](/rules/current/metadata-in-rules)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Metadata Best Practices](/best-practices/metadata-best-practices)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
diff --git a/fr-ca/articles/users/concepts/overview-user-migration.md b/fr-ca/articles/users/concepts/overview-user-migration.md
new file mode 100644
index 0000000000..7f516fafdc
--- /dev/null
+++ b/fr-ca/articles/users/concepts/overview-user-migration.md
@@ -0,0 +1,69 @@
+---
+description: Overview of importing users from external applications into Auth0.
+topics:
+  - users
+  - user-management
+  - migrations
+contentType:
+  - concept
+useCase:
+  - manage-users
+  - migrate
+---
+# Import and Export Users
+
+Auth0 supports importing users from external applications using custom database connections, the Auth0 Management API, or the User Import/Export Extension.
+
+## Automatic migrations
+
+Auth0 supports automatic migration of users from a [custom database connection](/connections/database/custom-db) to Auth0. By activating this feature, your users are:
+
+* Moved to Auth0 the first time they log in after you set up the integration. 
+* Not asked to reset their password as a result of the migration.
+
+::: panel Feature availability
+- Only **Developer**, **Developer Pro**, and **Enterprise** subscription plans include the database migration feature.
+- Only **Enterprise** subscription plans include the ability to connect to an existing store or database via JavaScript running on Auth0's servers for every authentication request.
+
+For more information refer to [Auth0 pricing plans](https://auth0.com/pricing).
+:::
+
+When a user authenticates via a custom database connection marked for import to Auth0, the following process takes place:
+
+![Migration Diagram](/media/articles/connections/database/migrating-diagram.png)
+
+* Auth0 authenticates migrated users against the Auth0 database. 
+* If the user has not been migrated, Auth0 executes your custom login script and, upon successfully log in, adds the user to the Auth0 database. 
+* Subsequent logins result in the user's credentials retrieved from Auth0, **NOT** your custom database.
+* New users are automatically added to the Auth0 database.
+
+::: note
+Auth0 can only assist users in the Auth0 database with password reset.
+:::
+
+## Bulk user imports with the Management API
+
+If you already have a user database, you can use our [`/post_users_imports`](/api/management/v2#!/Jobs/post_users_imports) Management API endpoint to populate a database connection with this information. 
+
+## Migrate users with the User Import/Export Extension
+
+The User Import/Export Extension allows you to:
+
+* Bulk import your existing database users into Auth0.
+* Search for and export some (or all) of your Auth0 database users.
+
+::: note
+You must be a Dashboard Admin to use this extension.
+:::
+
+You can import and export user data using the User Import/Export Extension available on the [Extensions](${manage_url}/#/extensions) section of the Dashboard. Select the **User Import / Export** extension and install it. For more information, see [User Import/Export Extension](/extensions/user-import-export).
+
+## Keep reading
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Example](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
+* [Migrate a User Database to Auth0](https://auth0.com/learn/migrate-user-database-auth0/)
diff --git a/fr-ca/articles/users/concepts/overview-user-profile.md b/fr-ca/articles/users/concepts/overview-user-profile.md
new file mode 100644
index 0000000000..71e68414a4
--- /dev/null
+++ b/fr-ca/articles/users/concepts/overview-user-profile.md
@@ -0,0 +1,119 @@
+---
+description: Explains the basics of Auth0 user profiles.
+toc: true
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: concept
+useCase: manage-users
+v2: true
+---
+# User Profiles
+
+Auth0 stores user information for your tenant in a hosted cloud database. Those users have access to applications connected to that tenant. User profiles contain information about your users such as name and contact information. Auth0 provides a variety of tools to help you manage user profiles such as the Dashboard and the Management API. You can create, search, view, and delete users.  
+
+## Data sources
+
+User information is stored in a *user profile* and can come from a variety of sources such as [identity providers](/identityproviders), your own databases, and enterprise connections (Active Directory, SAML, etc.). You can normalize user data that comes from a variety of data sources.
+
+The user profile attributes can also include information from the authenticating services (such as Facebook or LinkedIn). The authentication service might be an enterprise provider, such as Active Directory, or a SAML-compliant authentication service operated by a business or other organization. For example, attributes can be a person's contacts and their profile picture, or in the case of Enterprise users, an employee number or the name of the department to which an employee belongs.
+
+Attributes can also come from custom databases and web services. Auth0 refers to all attribute sources as **connections** because Auth0 connects to them to authenticate the user.
+
+## Data normalization
+
+Auth0 supports a wide variety of connections. Each connection may return a different set of attributes about the user, and each provider may use different names for the same attribute, such as *surname*, *last name* and *family name*. To handle the increased complexity this presents, Auth0 provides a [Normalized User Profile](/users/normalized). Auth0 returns a basic set of information using specific attribute names so programs can rely on using those same names to retrieve information such as `user_id`, `name`, `nickname`, and `picture`. If available, additional attributes such as `given_name` and `family_name` are also included in the Normalized User Profile.
+
+## Caching user profiles
+
+Auth0 caches the user profile received from a connection prior to passing it on to the calling application. This cache is stored in the Auth0 database. The information in the cache that originates from a connection is refreshed each time the user authenticates. See [Update User Profile Using Your Database](/users/guides/update-user-profiles-using-your-database#user-profile-cache)
+
+## Data structure
+
+There are several components to the User Profile data structure in Auth0. This structure can be viewed by clicking on the [Users tab](${manage_url}/#/users) in the Auth0 Dashboard and then on a particular user. See [User Profile Structure](/users/references/user-profile-structure).
+
+## Custom user profile data 
+
+Auth0 allows you to store **metadata**, which is data related to each user that has not come from the identity provider. 
+You can use `user_metadata` to store custom attributes such as the user's favorite color or hobby. See [Metadata](/users/concepts/overview-user-metadata).
+
+Auth0 provides a [JS widget](https://github.com/auth0/auth0-editprofile-widget) that allows the user to update their own profile information. 
+
+## User profile application access
+
+The User Profile will be provided to an application once authentication is complete and control is returned to the app. At a low level, this can be accomplished using one of the [application protocols](/protocols) supported by Auth0. However, most developers prefer to leverage the Auth0 SDKs that are available as [Quickstarts](/quickstarts).
+
+One SDK is the Auth0 Lock widget, which provides a user login interface:
+
+* [Web interface](/libraries/lock)
+* [Lock for iOS and OSX](/libraries/lock-ios)
+* [Lock for Android](/libraries/lock-android)
+
+Alternatively, if you'd like your web app to have a custom login UI, you can use [auth0.js](/libraries/auth0js), a headless JavaScript library for Auth0, which invokes authentication flow (as well as other tasks) and receives a User Profile object in return.
+
+## User profile Management API access
+
+Auth0 provides a REST API that allows applications and services to access and manipulate the User Profile object.
+
+The [API Explorer](/api/v2) allows users to interactively explore the Management API, view the API calls available, the information required for each call, and the information returned by each call. The explorer allows users to try out each endpoint in the explorer UI or via a CuRL command on the command line. To try out one of the Management API commands, select the access required under **Scopes** within that command, such as `update:users`, and then click on "TRY".
+
+Finally, there is the Authentication API specifically used for authentication flows. See [Authentication API Explorer](/api/authentication) for more information. Typically, most of these endpoints are used by the various Auth0 SDKs, not your own code.
+
+## User profile vs. tokens
+
+In the authentication flows described above, Auth0 returns a set of tokens in lieu of a full User Profile.
+
+One of the returned tokens is the ID Token, which is a [JSON Web Token](/tokens/concepts/jwts) (or JWT) that contains user profile attributes represented in the form of *claims*. These claims are statements about the user, which can be trusted if the consumer of the token can verify its signature, which is generated with the Auth0 app's Client Secret in the case of `HS256`. In case the application uses `RS256` encryption then the ID Token will be signed with a private key and verified with a public key. The app can then decode the JWT and get the user information contained in its payload, like the user's name, email, and so forth, typically used for UI display.
+
+The claims within a JWT generally contain a subset of the information available on the user profile in order to minimize the overall size. For further information on controlling the claims returned in a JWT, see the [Scopes](#scopes) section below.
+
+There are three other types of tokens that can be returned during authentication:
+
+* Auth0 Access Token
+* Third-party provider Access Token
+* Refresh Token
+
+For more information on tokens and claims see [Tokens](/tokens).
+
+## User profile data modification
+
+The information contained in a user profile and in an ID Token can be modified in a number of ways.
+
+* [**Scopes**](/scopes): The authentication flows supported by Auth0 includes an optional parameter that allows you to specify a scope. This controls the user profile information (claims) included in the ID Token (JWT). 
+
+* [**Management Dashboard**](/users/guides/manage-users-using-the-dashboard): The dashboard allows administrators to manually edit portions of the user profile for a particular user. This mechanism can be used to alter the `user_metadata` and `app_metadata` portions of the user profile.
+
+* [**Management API**](/users/guides/manage-users-using-the-management-api): Provides access to read, update, and delete user profiles stored in the Auth0 database.
+
+* [**Custom database scripts**](/connections/database/custom-db/templates): If a custom database is used as the connection, you can write scripts to implement lifecycle events such as create, login, verify, delete and change password. Auth0 provides templates for these scripts that you can modify for the particular database and schema.
+
+* [**Rules**](/rules/metadata-in-rules): Rules execute after a user has been authenticated. Use Rules to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. 
+
+## User profile attribute mapping
+
+### AD/LDAP connector
+
+For Active Directory or any other LDAP connections that use the Auth0 AD/LDAP connector, there is a mechanism for mapping User Profile attributes in the directory service to the Auth0 User Profile. This mapping takes place when a user authenticates via such a Connection and attributes specified in this mapping are reflected in the Auth0 User Profile.
+
+This mapping is implemented in a file called `profileMapper.js` located in the installation directory of the AD/LDAP connector.
+
+### SAML assertions
+
+If the SAML protocol is used between Auth0 and the application, there are two places where user attribute mapping can occur.
+
+If Auth0 is serving as a SAML Service Provider, the "Mappings" tab for a SAML connection is used to map attributes coming from an IDP to attributes in the Auth0 User Profile.
+
+`Connections -> Enterprise -> SAMLP -> {Name of Connection} -> Settings -> Mappings`
+
+If Auth0 is serving as a SAML Identity Provider, the Settings tab of Application AddOns is used to map attributes from the Auth0 User Profile to attributes in the SAML Assertion sent back to the Service Provider: **[Dashboard](${manage_url}) > Applications > name of your app > Addons > SAML2 Web App > Settings**.
+
+## Account linking
+
+Users can log into an application initially via one connection (such as a database), then log in via another connection (such as Facebook). In this case, the `user_id` for the second authentication will be different from that for the first authentication. 
+
+Auth0 provides a mechanism to [link](/users/concepts/overview-user-account-linking) the two accounts. If this is done, the `identities` array portion of the user profile will have multiple elements, one for each provider for which account linking has been done.
+
+::: note
+The user profile attributes from multiple providers are not merged. The core user profile attributes are sourced from the first provider used.
+:::
diff --git a/fr-ca/articles/users/guides/azure-access-control.md b/fr-ca/articles/users/guides/azure-access-control.md
new file mode 100644
index 0000000000..29e9fd4940
--- /dev/null
+++ b/fr-ca/articles/users/guides/azure-access-control.md
@@ -0,0 +1,78 @@
+---
+title: Migrate from Azure Access Control Service to Auth0
+description: How to migrate from Azure Access Control Service to Auth0.
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - azure
+contentType:
+  - concept
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Migrate from Azure Access Control Service to Auth0
+
+::: note
+Azure Access Control Service will be [retired in November 2018](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-acs-migration).
+:::
+
+In this article, you'll learn how to migrate from Azure Access Control (ACS) to Auth0, and connect to a [WS-Federation](/protocols/ws-fed) identity provider such as Azure Active Directory, Active Directory Federation Services, or IdentityServer.
+
+## Before you start
+
+* WS-Federation identity provider connections in Auth0 return tokens in SAML2 format. If your ACS configuration uses WS-Federation protocol with JWT tokens, you'll need to update your applications when migrating to Auth0.
+* Auth0 offers both [cloud and on-premises deployments](/getting-started/deployment-models).
+* Review the [Getting Started](/getting-started) documentation for an overview of Auth0.
+
+## Set up your account
+
+Start by [signing up for Auth0](https://auth0.com/signup). After creating your account, you'll be prompted to create a new [tenant](/getting-started/the-basics#account-and-tenants). Tenants in Auth0 are like namespaces in ACS: `${account.namespace}`.
+
+## Create an application
+
+In order for an application to use Auth0 it must be registered as a [application](/applications). Create a new application on the [Dashboard](https://manage.auth0.com/#/applications).
+
+![Create Application window](/media/articles/applications/create-client-popup.png)
+
+## Add Auth0 to your identity provider
+
+Next add Auth0 as a relying party to your identity provider using the following information:
+
+* Realm Identifier: `urn:auth0:${account.tenant}`
+* Return URL: `https://${account.namespace}/login/callback`
+
+## Create a WS-Federation connection
+
+To create a connection between Auth0 and your identity provider, navigate to [Dashboard > Connections > Enterprise](${manage_url}/#/connections/enterprise). For WS-Federation identity providers, create a new **ADFS** connection and provide the following information:
+
+* __Connection Name__: A descriptive name for the connection.
+* __Email Domains__: (Optional) A comma-separated list of valid domains. Only needed if you want to use the [Lock login widget](/libraries/lock).
+
+Next, either enter your WS-Federation server URL in the __ADFS URL__ field or upload a Federation Metadata file. 
+
+If you set a WS-Federation server URL, Auth0 will retrieve the Federation Metadata endpoint and import the required parameters, certificates, and URLs. You must make sure that the URL is publicly accessible and the SSL certificate on your ADFS installation is valid.
+
+![New Connection](/media/articles/connections/enterprise/ws-fed/new.png)
+
+After saving the new connection you'll see a list of your registered [applications](${manage_url}/#/applications). Enable the connection for your application.
+
+## Update your application
+
+Depending on your application and use case, you'll have to update your application to use Auth0 for authentication instead of ACS. There are several ways to integrate Auth0 with your application:
+
+- Configure the [Lock](/libraries#lock) authentication widget.
+- Use [Auth0 SDKs](/libraries#auth0-sdks) such as [Auth0.NET](https://github.com/auth0/Auth0.net).
+- Connect to the [Authentication API](/api/authentication).
+
+## Next Steps
+
+::: next-steps
+* [Add Rules to customize user authentication](/rules/current)
+* [Set up the Universal Login Page](/universal-login)
+* [Manage user access with groups, roles, and permissions](/extensions/authorization-extension)
+:::
diff --git a/fr-ca/articles/users/guides/block-and-unblock-users.md b/fr-ca/articles/users/guides/block-and-unblock-users.md
new file mode 100644
index 0000000000..45e57f08d9
--- /dev/null
+++ b/fr-ca/articles/users/guides/block-and-unblock-users.md
@@ -0,0 +1,46 @@
+---
+description: Describes how to block and unblock users. 
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Block and Unblock Users
+
+You can use the Dashboard to restrict a specific user's access to your application.
+
+## Block a user
+
+To disable a user's access to your apps, you can block the user in the Dashboard:
+
+1. Go to the [Users](${manage_url}/#/users) page in the Dashboard
+2. Click the name of the user you want to block
+3. When the User Details page opens, click the **Actions** button.
+4. Select **Block User** from the dropdown menu.
+
+![Block a User](/media/articles/user-profile/user4.png)
+
+If a blocked user tries to access an application, they will be redirected to the application with the error message `user is blocked` in the URL.
+
+::: note
+Blocking does not expire. You must unblock the user to allow the user to have access to your apps. 
+:::
+
+## Unblock a user
+
+To reinstate a user's access to your apps, you can unblock the user in the Dashboard:
+
+1. Go to the [Users](${manage_url}/#/users) page in the Dashboard. 
+2. Click the name of the user you want to unblock. 
+3. When the User Details page opens, click the **Actions** button. 
+4. Select **Unblock User** from the dropdown menu.
+
+![Unblock a User](/media/articles/user-profile/user4.png)
+
+## Keep reading
+
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/bulk-user-exports.md b/fr-ca/articles/users/guides/bulk-user-exports.md
new file mode 100644
index 0000000000..3eb1aada24
--- /dev/null
+++ b/fr-ca/articles/users/guides/bulk-user-exports.md
@@ -0,0 +1,243 @@
+---
+title: Bulk User Exports
+description: Learn how to export lists of users and user metadata.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Bulk User Exports
+
+You can use the [`POST /api/v2/jobs/users-exports`](/api/management/v2#!/Jobs/post_users_exports) endpoint to create a job that exports all users associated with a [connection](/identityproviders).
+
+For a list of user profile fields that can be exported, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes).
+
+When you create your job, you'll need to provide:
+
+* ID for the connection whose users you want exported
+* Format of the export file (CSV or JSON-compatible)
+* Maximum number of user records to be exported (optional, will export all records if omitted)
+* User-related fields (such as user ID or name) that you want included in the export
+
+<%= include('../search/v3/_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+    "queryString": [],
+    "postData": {
+        "mimeType": "application/json",
+        "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"csv\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, { \"name\": \"identities[0].connection\", \"export_as\": \"provider\" }]}" 
+    },
+    "headersSize": -1,
+    "bodySize": -1,
+    "comment": ""
+}
+```
+
+### Sample results
+
+```json
+{
+  "type": "users_export",
+  "status": "pending",
+  "connection_id": "con_0000000000000001",
+  "format": "csv",
+  "limit": 5,
+  "fields": [
+    {
+      "name": "user_id"
+    },
+    {
+      "name": "name"
+    },
+    {
+      "name": "email"
+    },
+    {
+      "name": "identities[0].connection",
+      "export_as": "provider"
+    }
+  ],
+  "connection": "Username-Password-Authentication",
+  "created_at": "2017-11-02T23:34:03.803Z",
+  "id": "job_coRQCC3MHztpuTlo"
+}
+```
+
+## Include user metadata
+
+### CSV format
+
+If you export user data in CSV format and want to include metadata information, specify each metadata field that you want to include. 
+
+For example, for metadata structured like this:
+
+```json
+{
+  "consent": {
+      "given": true,
+      "date": "01/23/2019",
+      "text_details": "some-url"
+  }
+}
+```
+
+The export request (for all three fields) will looks like this:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"csv\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, {\"name\": \"user_metadata.consent.given\"}, {\"name\": \"user_metadata.consent.date\"}, {\"name\": \"user_metadata.consent.text_details\"}]}" 
+    },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+::: note
+Auth0 allows you to export the entirety of the `app_metadata` or `user_metadata` in one field. For example, if you want the full `app_metadata` field exported, your mapping should be `"app_metadata": "app_metadata"`. You do not need to specify each parameter individually to return the entire metadata field.
+:::
+
+### JSON-compatible format
+
+If you export the data in JSON-compatible format, you only need to provide the root property; you do not need to name each individual inner property since they will be included automatically.
+
+::: note
+Auth0's export files use the [ndjson](http://ndjson.org/) format due to the large size of the export files, while the import functionality expects a JSON file.
+
+Before you can import users using an export generated by Auth0, you'll need to convert the file from **ndjson** to **json** using the library of your choice (such as [jq](https://stedolan.github.io/jq/)).
+:::
+
+In this case, for the same example we used before, the request will look like this:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"json\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, {\"name\": \"user_metadata.consent\"}]}" 
+    },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+## Check export status
+
+Once you've created your job to export your users, you can check on its status using the [Get a Job endpoint](/api/management/v2#!/Jobs/get_jobs_by_id). 
+
+Provide the ID of the job (which you received in the response when creating the job). If you're using the sample request below, replace the placeholder `YOUR_JOB_ID` with the value of the ID.
+
+*Require Scopes*: `create:users`, `read:users`, `create:passwords_checking_job`
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/YOUR_JOB_ID",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  }]
+}
+```
+
+### Sample results
+
+```json
+{
+  "type": "users_export",
+  "status": "completed",
+  "connection_id": "con_lCvO...a",
+  "format": "csv",
+  "limit": 5,
+  "fields": [
+    {
+      "name": "user_id"
+    },
+    {
+      "name": "name"
+    },
+    {
+      "name": "email"
+    },
+    {
+      "name": "identities[0].connection",
+      "export_as": "provider"
+    }
+  ],
+  "location": "https://user-exports.auth0.com/job_coRQCC3MHztpuTlo/auth0docs2.csv.gz?Expires=1509725589&Key-Pair-Id=APKAJPL62IJALBDMSSCA&Signature=l2JaFXP~BATnfagb64PK-qbX9QaZREDYNW0q5QeHuV-MaDpZjpABDXfHHLh2SsCMQz~UO-QsCSfI81l0lvCKzZPZL6cZHK7f~ixlZOK~MHKJuvMqsUZMbNluNAwhFmgb2fZ86yrB1c-l2--H3lMELAk7hKUwwSrNBlsfbMgQ-i41nMNnsYdy3AVlNVQkwZyx~w-IEHfJDHsqyjia-jfDbIOLQvr8~D9PwZ-xOzROxDwgxrt3undtz80bkgP5hRKOAbHC7Y-iKWa2bzNZYHqzowTrlh7Ta60cblJR46NfF9cNqn9jqRGVv-lsvUD9FxnImCCk~DL6npJnzNLjHvn4-CaWq6KdQnwWgCnZ3LZkxXDVWLLIQQaoc6i~xbuGnnbtKRePFSnpqbt2mAUYasdxTOWuUVK8wHhtfZmRYtCpwZcElXFO9Qs~PTroYZEiS~UHH5byMLt2x4ChkHnTG7pIhLAHN~bCOLk8BN2lOkDBUASEVtuJ-1i6cKCDqI2Ro9YaKZcCYzeQvKwziX6cgnMchmaZW77~RMOGloi2EffYE31OJHKiSVRK7RGTykaYN5S2Sg7W0ZOlLPKBtCGRvGb8rJ6n3oPUiOC3lSp7v0~dkx1rm-jO8mKWZwVtC0~4DVaXsn8KXNbj0LB4mjKaDHwXs16uH1-aCfFnMK7sZC2VyCU_",
+  "connection": "Username-Password-Authentication",
+  "created_at": "2017-11-02T23:34:03.803Z",
+  "id": "job_coRQCC3MHztpuTlo"
+}
+```
+
+## Find export data
+
+You can access your export files using the URL provided as the value for the **location** parameter. The name of your tenant is also the name of your file. For example, if your tenant name is `auth0docs`, then your file will be `auth0docs.csv` or `auth0docs.json`. When you navigate to the URL, you will automatically begin downloading the file. 
+
+::: note
+The download link is valid for 60 seconds. If this time period expires, you will need to initiate a new job.
+:::
+
+![Exported user data](/media/articles/users/data.png)
+
+## Job timeouts
+All user export jobs timeout after **eight (8) hours**. If your job does not complete within this time frame, it is marked as failed.
+Furthermore, all of your job-related data is automatically deleted after 24 hours and cannot be accessed afterward. As such, **we strongly recommend storing the job results using the storage mechanism of your choice**.
+
+## Keep reading
+
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/fr-ca/articles/users/guides/bulk-user-imports.md b/fr-ca/articles/users/guides/bulk-user-imports.md
new file mode 100644
index 0000000000..3545080a49
--- /dev/null
+++ b/fr-ca/articles/users/guides/bulk-user-imports.md
@@ -0,0 +1,288 @@
+---
+title: Bulk User Imports
+description: Learn how to perform bulk user imports with the Management API.
+crews: crew-2
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - bulk-imports
+contentType:
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Bulk User Imports
+
+This tutorial shows you how to bulk import user data into Auth0 using the [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint. Bulk imports are useful for migrating users from an existing database or service to Auth0.
+
+## Before you start
+
+Before you launch the import users job:
+
+* [Configure a database connection](/connections/database) to import the users into and enable it for at least one application.
+* If you are importing passwords, make sure the passwords are hashed using one of the [supported algorithms](/users/references/bulk-import-database-schema-examples#supported-hash-algorithms). Users with passwords hashed by unsupported algorithms will need to reset their password when they log in for the first time after the bulk import.
+* If you are importing MFA enrollments, make sure they are a [supported type](/users/references/bulk-import-database-schema-examples#mfa-factors): `email`, `phone`, or `totp`. 
+* Get a [Management API Token](/api/management/v2/tokens) for job endpoint requests.
+
+## Create users JSON file
+
+First you'll need to create a JSON file with the user data you want to import into Auth0. How you export user data to a JSON file will vary depending on your existing user database. To see the JSON file schema and examples, visit [Bulk Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples).
+
+The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
+
+## Request bulk user import
+
+To start a bulk user import job, make a `POST` request encoded as type `multipart/form-data` to the [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN`, `USERS_IMPORT_FILE.json`, `CONNECTION_ID`, and `EXTERNAL_ID` placeholder values with your Management API Access Token, users JSON file, database connection ID, and external ID, respectively.
+
+```har
+{ 
+  "method":"POST",
+  "url":"https://${account.namespace}/api/v2/jobs/users-imports",
+  "headers":[ 
+    { 
+      "name":"Content-Type",
+      "value":"multipart/form-data"
+    },
+    { 
+      "name":"Authorization",
+      "value":"Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ],
+  "postData":{ 
+    "mimeType":"multipart/form-data",
+    "params":[ 
+      { 
+        "name":"users",
+        "fileName":"USERS_IMPORT_FILE.json",
+        "contentType":"application/json"
+      },
+      { 
+        "name":"connection_id",
+        "value":"CONNECTION_ID"
+      },
+      { 
+        "name":"external_id",
+        "value":"EXTERNAL_ID"
+      }
+    ]
+  }
+}
+```
+
+| Parameter | Description |
+|-----------|-------------|
+| `users` | [File in JSON format](/users/references/bulk-import-database-schema-examples#examples) that contains the users to import. |
+| `connection_id` | ID of the connection to which users will be inserted. You can retrieve the ID using the [GET /api/v2/connections](/api/management/v2#!/Connections/get_connections) endpoint. |
+| `upsert` | Boolean value; `false` by default. When set to `false`, pre-existing users that match on email address, user ID, or username will fail. When set to `true`, pre-existing users that match on any of these fields will be updated, but only with upsertable attributes. For a list of user profile fields that can be upserted during import, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes). |
+| `external_id` | Optional user-defined string that can be used to correlate multiple jobs. Returned as part of the job status response. |
+| `send_completion_email` | Boolean value; `true` by default. When set to `true`, sends a completion email to all tenant owners when the import job is finished. If you do *not* want emails sent, you must explicitly set this parameter to `false`. |
+
+If the request is successful, you'll receive a response similar to the following:
+
+```json
+{
+  "status": "pending",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "upsert": false,
+  "external_id": "EXTERNAL_ID",
+  "send_completion_email": true
+}
+```
+
+The returned entity represents the import job.
+
+When the user import job finishes and if `send_completion_email` was set to `true`, the tenant administrator(s) will get an email notifying them that job either failed or succeeded. An email for a job that failed might notify the administrator(s) that it failed to parse the users JSON file when importing users.
+
+### Concurrent import jobs
+
+The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of two concurrent import jobs. Requesting additional jobs while there are two pending returns a `429 Too Many Requests` response:
+
+```json
+{
+  "statusCode": 429,
+  "error": "Too Many Requests",
+  "message": "There are 2 active import users jobs, please wait until some of them are finished and try again
+}
+```
+
+## Check job status
+
+To check a job's status, make a `GET` request to the [get a job](/api/management/v2#!/Jobs/get_jobs_by_id) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN` and `JOB_ID` placeholder values with your Management API Access Token and user import job ID.
+
+```har
+{ 
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/JOB_ID",
+  "headers": [ 
+    { 
+      "name": "Content-Type",
+      "value": "application/json"
+    },
+    { 
+      "name": "Authorization",
+      "value": "Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ]
+}
+```
+
+Depending on the status of the user import job, you'll receive a response similar to one of the following:
+
+### Pending
+
+```json
+{
+  "status": "pending",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID"
+}
+```
+
+### Processing
+
+```json
+{
+  "status": "processing",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "percentage_done": 0,
+  "time_left_seconds": 0
+}
+```
+
+### Completed
+
+If a job is completed, the job status response will include totals of successful, failed, inserted, and updated records.
+
+```json
+{
+  "status": "completed",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "location": "https://${account.namespace}/EXAMPLE",
+  "summary": {
+    "failed": 0,
+    "updated": 0,
+    "inserted": 1,
+    "total": 1
+  }
+}
+```
+
+## Failed
+
+If there is an error in the job, it will return as failed. However, note that invalid user information, such as an invalid email, will not make the entire job fail.
+
+```json
+{
+  "status": "failed",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "summary": {
+    "failed": 1,
+    "updated": 0,
+    "inserted": 0,
+    "total": 1
+  }
+}
+```
+
+To learn how to get details for failed entries, see [Retrieve failed entries](#retrieve-failed-entries). 
+
+### Expired
+
+Expired jobs are completed jobs that were created more than 2 hours ago.
+
+```json
+{
+  "status": "expired",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID"
+}
+```
+
+Additionally, the job status is added to [Tenant Logs](${manage_url}/#/logs), which allows for a custom WebHook to be triggered using the [WebHook Logs Extension](/extensions/management-api-webhooks).
+
+## Job timeouts
+
+All user import jobs timeout after two (2) hours. If your job does not complete within this time frame, it is marked as failed.
+
+## Retrieve failed entries
+
+::: warning
+All of the job-related data is automatically deleted after 24 hours and cannot be accessed thereafter. Because of this, we strongly recommend storing the job results using the storage mechanism of your choice.
+:::
+
+If there were errors in the user import job, you can get the error details by making a `GET` request to the [get job error details](/api/management/v2#!/Jobs/get_errors) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN` and `JOB_ID` placeholder values with your Management API Access Token and user import job ID.
+
+```har
+{ 
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/JOB_ID/errors",
+  "headers": [ 
+    { 
+      "name": "Content-Type",
+      "value": "application/json"
+    },
+    { 
+      "name": "Authorization",
+      "value": "Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ]
+}
+```
+
+If the request is successful, you'll receive a response similar to the following. Sensitive fields such as `hash.value` will be redacted in the response.
+
+```json
+[
+    {
+        "user": {
+            "email": "test@test.io",
+            "user_id": "7af4c65cb0ac6e162f081822422a9dde",
+            "custom_password_hash": {
+                "algorithm": "ldap",
+                "hash": {
+                    "value": "*****"
+                }
+            }
+        },
+        "errors": [
+            {
+                "code": "...",
+                "message": "...",
+                "path": "..."
+            }
+        ]
+    }
+]
+```
+
+## Related pages
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
diff --git a/fr-ca/articles/users/guides/change-user-pictures.md b/fr-ca/articles/users/guides/change-user-pictures.md
new file mode 100644
index 0000000000..44585a59aa
--- /dev/null
+++ b/fr-ca/articles/users/guides/change-user-pictures.md
@@ -0,0 +1,86 @@
+---
+description: How to use the user_metadata to change a user's picture field and how to change the default picture for all users.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - user-picture
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Change User Pictures
+
+Auth0 [normalizes](/users/normalized) common profile properties in the User Profile, this includes the `name` and `picture` field and more. The picture field is populated by either the social provider profile picture or the Gravatar image associated with the user's email address. By default, all database users will have a placeholder image with their initials. When you authenticate the user, this picture field is referred by as `user.picture`.
+
+![User Picture](/media/articles/user-profile/user-picture.png)
+
+1. By default, the `user.picture` attribute is not directly editable when provided by identity providers other than Auth0 (such as Google, Facebook, Twitter). If you want to be able to edit this attribute, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+
+Alternatively, you can use the [Metadata](/users/concepts/overview-user-metadata) to store the picture attribute for users, but this is not recommended for scalability.
+
+For example, if your app provides a way to upload profile pictures, once the picture is uploaded, you can set the URL to the picture in `user.user_metadata.picture`:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/USER_ID",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"picture\": \"https://example.com/some-image.png\"}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+2. To ensure that the picture from the `user_metadata` is returned in the ID Token, you need to create a [Rule](/rules) to check whether the `user.user_metadata.picture` attribute is present, and if so replace the `user.picture` attribute with that value. This will ensure that the picture from the `user_metadata` is returned in the `picture` claim of the ID Token.
+
+Here is an example of the code you can use in your Rule:
+
+```js
+function (user, context, callback) {
+  if (user.user_metadata.picture)
+    user.picture = user.user_metadata.picture;
+
+  callback(null, user, context);
+}
+```
+
+## Change the default picture for all users
+
+To change the default picture of all users who do not have a profile picture set, you can use a rule to do this.
+
+Example:
+
+```js
+
+function (user, context, callback) {
+  if (user.picture.indexOf('cdn.auth0.com') > -1) {
+    const url = require('url');
+    const u = url.parse(user.picture, true);
+    u.query.d = 'URL_TO_YOUR_DEFAULT_PICTURE_HERE';
+    delete u.search;
+    user.picture = url.format(u);
+  }
+  callback(null, user, context);
+}
+
+```
+
+## Keep reading
+
+- [User Profile Structure](/users/references/user-profile-structure)
+- [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/configure-automatic-migration.md b/fr-ca/articles/users/guides/configure-automatic-migration.md
new file mode 100644
index 0000000000..bf8c2b6c20
--- /dev/null
+++ b/fr-ca/articles/users/guides/configure-automatic-migration.md
@@ -0,0 +1,114 @@
+---
+title: Configure Automatic Migration from Your Database
+description: Learn how to enable automatic user migration with your custom database. 
+topics:
+  - users
+  - user-management
+  - migrations
+  - automatic-user-migration
+  - custom-db
+contentType: how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Configure Automatic Migration from Your Database
+
+After you create a database connection in the Dashboard, you enable user migration from that database and create custom scripts to determine how the migration happens. 
+
+These custom scripts are Node.js code that run in the tenant's sandbox. Auth0 provides templates for most common databases, such as: **ASP.NET Membership Provider**, **MongoDB**, **MySQL**, **PostgreSQL**, **SQLServer**, **Windows Azure SQL Database**, and for a web service accessed by **Basic Auth**. For more information on implementing these scripts, see [Authenticate Users using a Custom Database](/connections/database/mysql).
+
+1. Navigate to the [Connections > Database](${manage_url}/#/connections/database) page in the [Auth0 Dashboard](${manage_url}/), and click **Create DB Connection**.
+
+![Dashboard: Database Connection List](/media/articles/dashboard/connections/database/dashboard-connections-database-list.png)
+
+2. Click the **Custom Database** tab, and enable the **Use my own database** option:
+
+![Dashboard: Enable Use My Own Database Option](/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png)
+
+3. Click the **Settings** tab, and enable the **Import Users to Auth0** option:
+
+![Dashboard: Enable Import Users Option](/media/articles/dashboard/connections/database/connections-db-settings-main-2.png)
+
+## Configure the scripts 
+
+1. Click the **Custom Database** tab, and locate **Database Action Scripts** to see the scripts you need to configure.
+
+![Dashboard: Configure Database Action Scripts](/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png)
+
+- **Login**: Executes each time a user that is not found in the Auth0 database attempts to log in. Verifies that the user exists in the legacy database without re-prompting the user for their password.
+
+- **Get User**: Executes following any of these actions:
+    * user attempts to *sign-up*.
+    * user clicks on valid [password change confirmation](/libraries/lock/customization#rememberlastlogin-boolean-) link.
+    * Management API receives a call to the [update a user's email or username](/api/v2#!/Users/patch_users_by_id) endpoint.
+
+:::panel-warning Passwords for Un-Migrated Users
+If an un-migrated user confirms a password change, their user profile will be created in Auth0 with the new password. This user profile will contain all the information returned in the **Get User** script. All subsequent logins of this user will be performed in Auth0 directly.
+
+You may see unexpected behavior if you return differing user profiles in the `login` and `get_user` scripts.
+:::
+
+## Verify the migration
+
+After you've enabled migration, you can verify the users that have migrated by doing one or both of the following tasks:
+
+1. Use the [List or search users](/api/v2#!/Users/get_users) Management API endpoint.
+
+2. Navigate to the [Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and review the list of users.
+
+![View Users](/media/articles/dashboard/users-roles/users-list.png)
+
+## Convert the database 
+
+Once all your users are in the Auth0 database, you are ready to convert the database so that it uses only users stored in Auth0.
+
+1. Go to your custom database connection on the [Dashboard](${manage_url}/#/connections/database).
+
+2. Update the **Login** Database Action Script to the following:
+
+```
+function login (email, password, callback) {
+  return callback(null, null);
+}
+```
+
+3. Update the **Get User** Database Action Script to the following:
+
+```
+function getByEmail (email, callback) {
+  return callback(null, null);
+}
+```
+
+By doing this, you are changing the **Login** and **Get User** [Database Action Scripts](/connections/database/mysql#3-provide-action-scripts) to NO-OP functions, essentially making it behave as a non-custom database connection.
+
+:::panel-warning Leave Import Users to Auth0 turned on
+Make sure to leave the **Import Users to Auth0** option turned on. If you turn this option off Auth0 will only use the scripts to authenticate and perform other user actions instead of using the users that were imported locally.
+:::
+
+## Disconnect the legacy database
+
+1. After you have verified the migration, you can disconnect your legacy database (**not** the Auth0 database). If you modified the scripts as instructed above, Auth0 will not try to connect to your legacy database.
+
+2. Keep **Import Users to Auth0** (on the **Settings** page) enabled. This, combined with the NO-OP script changes, will ensure that only the Auth0 users database is used. 
+
+3. Configure [rules](/rules) to execute other functions when a user authenticates to your application.
+
+## Troubleshoot migration errors
+
+The most common error message that you may encounter when importing users from a legacy database to an Auth0 custom database is "The user already exists." 
+
+When a user is imported, a partial user state is first created on the Auth0 end to make this migration possible. If you delete this user from the Auth0 connection then later recreate the user, you may receive this error. In addition, the **Get User** script is called on user creation. If you attempt to create a new user in the Auth0 custom database connection and the user already exists in your external database, you will receive this error.
+
+If you encounter a "user already exists" error message, use the Management API's [endpoint to delete a connection user](/api/management/v2#!/Connections/delete_users_by_email) to delete the user. Confirm that the user does not exist in your legacy database, then recreate the user. 
+
+## Keep reading
+
+* [User Migration Overview](/users/concepts/overview-user-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Example](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
diff --git a/fr-ca/articles/users/guides/create-users.md b/fr-ca/articles/users/guides/create-users.md
new file mode 100644
index 0000000000..92470960c1
--- /dev/null
+++ b/fr-ca/articles/users/guides/create-users.md
@@ -0,0 +1,55 @@
+---
+description: How to create users in the Auth0 Dashboard.
+crews: crew-2
+topics:
+  - dashboard
+  - users
+contentType: how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Create Users Using the Dashboard
+
+You can manually create users via the [Dashboard](${manage_url}).
+
+1. Log in and open up the Dashboard. Navigate to the _Users_ tab.
+
+![](/media/articles/users/dashboard.png)
+
+2. Click on the __Create User__ button near the top right-hand side of the screen.
+
+![](/media/articles/users/users-tab.png)
+
+3. Provide the following information for the new user:
+    * **Email**: The user's email address. The maximum length is 64 characters for the user/local part and 256 characters for the domain part.
+    * **Password**: The user's password. There is no maximum limit for password length. For more information, refer to [Password Strength in Auth0 Database Connections](/connections/database/password-strength). 
+    * **Repeat Password**: Confirm password.
+    * **Connection**: The database connection to use to authenticate the user. The dropdown lists all the configured database connections in your tenant. The connection you use must be associated with an application. 
+
+4. When finished, click __Save__ to create the new user.
+
+::: note
+The connection you use must be associated with an application, otherwise you will receive an error message that says, The connection is disabled. You can enable connections for Applications from the Dashboard, in  Application Settings > Connections, or from the Connection Settings > Applications.
+:::
+
+![](/media/articles/users/create-user.png)
+
+At this point, the user is created, and you will be directed to the newly-created user's profile.
+
+![](/media/articles/users/user-profile.png)
+
+::: panel Pending Users
+The User Details page will show `pending` when a user is first created until they have logged in for the first time.
+:::
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [Manage Users Using the Dashboard](/users/guides/manage-users-using-the-dashboard)
+* [View Users](/users/guides/view-users)
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
+* [User Search](/users/search)
diff --git a/fr-ca/articles/users/guides/delete-users.md b/fr-ca/articles/users/guides/delete-users.md
new file mode 100644
index 0000000000..b18a00679d
--- /dev/null
+++ b/fr-ca/articles/users/guides/delete-users.md
@@ -0,0 +1,32 @@
+---
+description: Describes how to delete users.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Delete Users
+
+1. To permanently delete a user, navigate to the [Users](${manage_url}/#/users) page in the Dashboard. 
+
+2. Click the name of the user you want to delete. 
+
+3. When the User Details page opens, click the **Actions** button. 
+
+4. Select **Delete User** from the dropdown menu.
+
+![Delete a User](/media/articles/user-profile/user4.png)
+
+A popup will warn you that the action cannot be undone and prompt you to confirm that you want to delete the user. 
+
+5. Click the **Yes, Delete It** button to confirm. This will permanently delete the user.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/email-verified.md b/fr-ca/articles/users/guides/email-verified.md
new file mode 100644
index 0000000000..02fc5a021d
--- /dev/null
+++ b/fr-ca/articles/users/guides/email-verified.md
@@ -0,0 +1,71 @@
+---
+title: Email Verified Usage
+description: Outlines proper usage of the email_verified field in a user profile.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType:
+    - how-to
+    - reference
+useCase: manage-users
+---
+# Verified Email Usage
+
+The `email_verified` field of a user profile indicates whether the user has verified their email address. Email verification is optional, but valid email addresses are required for certain actions, such as sending email communications, password reset/recovery links, and passwordless magic links to users.
+
+An email is usually verified immediately after the user account is created or when the user logs in to the application for the first time. It's a good way to know that the person signing up actually owns the email at that moment. 
+
+Since email verification happens once at that specific moment, we can't ensure that a person who logs in with the user account at a later time still owns the email address that was verified. 
+
+In case of federated identity providers, they sometimes report if the user has a verified email, and based on that, Auth0 sets the `email_verified` field in the user profile. This, however, transfers the responsibility to the identity provider to do it properly - something we can't ensure. We also don't know if the verified email from that provider is still owned by the user.
+ 
+For all of these reasons, we need to be careful on what we can assume based on a verified email.
+
+## When does Auth0 sets emails as verified?
+
+When users signup with email and password, they will get a [verification email](/email/templates#verification-email) with a link. When they click the link, their email will be verified. 
+
+When users authenticate with a federated identity provider (e.g. a social or enterprise connection), the value of the `email_verified` field will match what the identity provider returns in the user profile. If they identity provider does not return any value, it will be set to `false`.
+
+## Verified Emails and Account Linking
+
+When you want to [link two user accounts](/articles/users/concept/overview-user-account-linking), you need to make sure that the user still has access to both accounts. The only way to achieve that is to have users authenticate with both accounts before linking them. 
+
+You **should not automatically link accounts based on the user's emails**. Always prompt users to authenticate again before doing that. This will prevent scenarios like:
+
+- John Doe, an employee of Travel0, signs up to a site using his corporate email `john.doe@travel0.com` and a password. Months later, John Doe leaves Travel0, and a new John Doe is hired, with the same email account. That person goes to the same website, and authenticates with his corporate identity provider (e.g. GSuite), and gets the account automatically linked to the other user.
+
+- Federated identity providers can make mistakes on how they handle email verification, and can report that users own an email they do not. 
+
+On the other hand, we recommend you to still check for the `email_verified` field *before* performing account linking, to mitigate scenarios like:
+
+- An attacker creates a Google account 'attacker@gmail.com'
+- Attacker creates a new database users with the victim's email (e.g. 'victim@hotmail.com').
+- Attacker links both accounts.
+- Attacker sends a phishing attack to victim.
+- The victim tries to sign-up, they are told the user already exists, and get offered to reset the password.
+- The user enters their password, and logs into the attacker's account, which now has access to whatever data the victim enters in the application.
+
+## Verified Emails and Authorization Decisions
+
+In the same way you can't fully trust the email, you can't fully trust the email domain. 
+
+If your application needs to restrict access based on the user's employer, the fact that a user is logged in with an email from a specific corporate domain does not guarantee that it should be granted access.
+
+For example:
+
+- If your application allows customers to sign up for new accounts, and employees from different companies authenticate using their corporate credentials, a user that signs up with a user@acme.com account shouldn't be granted access to the same feature set that a user authenticating with acme.com's corporate directory.
+
+- If your application supports authenticating with Azure AD, and the directory supports guests users, you can get users from any domain logging-in from that Azure AD tenant. You should not give guest users the same access level as the rest of the users authenticating with that tenant.
+
+As a general recommendation, **you should not use the email's domain to make authorization decisions**. If you need to check if the user belongs to a specific organization, it's better to rely on the connection they used to authenticate, or in connection-specific attributes like the Azure AD's tenant id.
+
+## Keep reading
+
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [Email Verification for Azure AD and ADFS connections](/connections/azuread-adfs-email-verification)
diff --git a/fr-ca/articles/users/guides/get-user-information-with-unbounce-landing-pages.md b/fr-ca/articles/users/guides/get-user-information-with-unbounce-landing-pages.md
new file mode 100644
index 0000000000..78dc41b345
--- /dev/null
+++ b/fr-ca/articles/users/guides/get-user-information-with-unbounce-landing-pages.md
@@ -0,0 +1,74 @@
+---
+description: How to get user information with one-click social authentication on Unbounce landing pages.
+topics:
+  - users
+  - user-management
+  - search
+  - unbounce
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Get User Information on Unbounce Landing Pages
+
+## Auth0 Configuration
+
+1. Create an Auth0 account and navigate to the [dashboard](${manage_url}).
+1. Go to [Applications](${manage_url}/#/applications) and click **+ Create Application**. Pick the `Single-Page Application` option and go to **Settings**. Note the **Client ID** and **Domain**. Also, add the `callback URL` in both **Allowed Callback URLs** and **Allowed Origins (CORS)** (it should be your Unbounce page URL. For example:`http://unbouncepages.com/changeit`).
+1. Go to **Connections > Social** and enable the social providers you want to support.
+
+![Social Connections](/media/articles/scenarios/unbounce/social-connections.png)
+
+## Unbounce Configuration
+
+* Add a button (or whatever UI element you consider) that will trigger the login with the provider. Take note of the button ID under **Properties > Element Metadata**.
+* Add a new JavaScript to your Unbounce landing page, select `Before Body End Tag` under `Placement` and add this code. Also make sure to check jQuery as a dependency.
+
+```html
+
+
+```
+
+::: note
+You should use the clientID and Domain of the application you just configured.
+:::
+
+* You need a way to pass the information coming from the social providers to Unbounce. The way you do that is by creating a Form and adding `Hidden fields` for each field. In the following example we are using the fields `name` and `email`.
+  ![](/media/articles/scenarios/unbounce/custom-fields.png)
+* Finally, go back to the JavaScript editor at Unbounce and add a click handler for each button to trigger the social authentication. Here, you must replace the button ID you took note of previously and the connection name, which can be seen in the [dashboard](${manage_url}) under under **Connections > Social** and expanding the provider. For example, for Google you would use `google-oauth2` and for LinkedIn, `linkedin`. Also, make sure that you replace the IDs properly, so instead of `#name` and `#email` you should put the ID of the form fields in question (you can see them while editing the form, under `Field Name and ID`).
+
+```js
+$('#REPLACE_WITH_BUTTON_ID').bind('click', function() { 
+  webAuth.authorize({
+    connection: 'YOUR CONNECTION NAME'
+  });
+});
+
+// After authentication occurs, the parseHash method parses a URL hash fragment to extract the result of an Auth0 authentication response.
+
+webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) { 
+  if (err) { 
+    return console.log(err); 
+  }
+
+  if (authResult != null && authResult.accessToken != null) {
+    webAuth.client.userInfo(authResult.accessToken, function(err, user) {
+      $('#name').val(user.name); 
+      $('#email').val(user.email); 
+    }); 
+  } 
+
+});
+```
+
+Now you will be able to see the information provided by the IdP in the `Leads` section of your Unbounce Admin Panel, after the user submits the form.
diff --git a/fr-ca/articles/users/guides/impersonate-users-using-the-dashboard.md b/fr-ca/articles/users/guides/impersonate-users-using-the-dashboard.md
new file mode 100644
index 0000000000..7eaac0e5a9
--- /dev/null
+++ b/fr-ca/articles/users/guides/impersonate-users-using-the-dashboard.md
@@ -0,0 +1,114 @@
+---
+description: Learn how to impersonate users using the Dashboard to view their information as they would see it. 
+sitemap: false
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Impersonate Users Using the Dashboard
+
+<%= include('../../_includes/_deprecate-impersonation') %>
+
+You may need to impersonate other users for testing or troubleshooting purposes. You can:
+
+* Log in to an app as a specific user.
+* See everything exactly as that user sees it.
+* Do everything exactly as that user does it.
+
+Auth0 provides a __Sign in As__ feature for user impersonation, and provides the following features and information:
+
+* Detailed auditing of who impersonated when.
+* Restrictions on impersonation which allows you to reject an impersonated authentication transaction based on, for instance, corporate policies around privacy and sensitive data.
+* Unlimited customization on who can impersonate who, when, depending on whatever context, using our [Rules](/rules) engine. In a Rule, you have access to `user.impersonated` (the impersonated login) and `user.impersonator` (the impersonating login) and you can write arbitrary Javascript to define how it works.
+
+::: note
+Any [Rules](/rules) that you have implemented will run when you impersonate a user, including any actions that update the user.
+:::
+
+::: panel Impersonation does not work with Authorization API
+Impersonation **does not work** with the [API Authorization](/api-auth) features. This means that the `audience` parameter will be ignored, and the [Access Token](/tokens/concepts/overview-access-tokens) returned to applications when using this flow is only valid for requests to [the /userinfo endpoint](/api/authentication#get-user-info). 
+:::
+
+## Impersonation and Login CSRF attacks
+
+To avoid [Login CSRF attacks](/protocols/oauth2/mitigate-csrf-attacks), the OAuth 2.0 specification recommends that applications use the **state** parameter to make sure that the response they receive matches the authentication request and originates from the same session.
+
+However, applications that check for a valid **state** parameter will *not* work with Impersonation, since Impersonation works by sending authenticated responses to applications that never requested authentication. If you are building a single-page application where the authentication results are processed by Lock or Auth0.js, you can disable checking of **state** to allow Impersonation.
+
+::: warning
+Impersonation leaves your application vulnerable to CSRF attacks, since the flag allows the bypassing of the CSRF check from the [state parameter](/protocols/oauth2/oauth-state) if this parameter is missing from the authorization response. By using impersonation, you acknowledge that you understand and accept these risks.
+:::
+
+If you are using [Auth0.js](/libraries/auth0js), you have to update the **webAuth.parseHash** of the [library](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) and set the flag **__enableIdPInitiatedLogin** to `true`.
+
+```javascript
+var data = webAuth.parseHash(
+  {
+    ...
+    __enableIdPInitiatedLogin: true
+    ...
+  }
+```
+
+If you're using [Lock](/lock), you can include the flag using the options parameter sent to the constructor.
+
+```javascript
+const lock = new Auth0Lock(clientID, domain, options)
+```
+
+Here's the flag itself:
+
+```javascript
+var options = {
+    _enableIdPInitiatedLogin: true
+};
+```
+
+Note that the **enableIdPInitiatedLogin** flag is preceded by **one** underscore when used with Lock and **two** underscores when used with the auth0.js library.
+
+## Impersonate users using the Dashboard
+1. Use the Dashboard to log in to your app as a user.
+
+2. Navigate to the [Users](${manage_url}/#/users) page in the Auth0 Dashboard and select the user you want to log in as. Click on the __Sign in as User__ and select the application you want to log in to using the dropdown menu.
+
+![Impersonate a User](/media/articles/user-profile/user2.png)
+
+::: panel I can't see the button
+Can't see the button? The following conditions are required for the button display:
+- The applications registered in the tenant must have at least one callback URL listed.
+- The applications must have the connections that the impersonated user belongs to turned on.
+:::
+
+A popup displays the URL to be used in order to impersonate the user. You can choose either to copy the URL into the clipboard (white button) or open it in a separate browser tab/window (blue button).
+
+3. Copy the URL into the clipboard (white button) or open the URL in a separate browser tab/window (blue button).
+
+![Impersonate a User](/media/articles/user-profile/user3.png)
+
+::: panel Acquiring a token
+Impersonating a user using the [Dashboard](${manage_url}) will not return an [ID Token](/tokens/concepts/id-tokens) to your application by default. There are two ways to achieve this. You can alter the **Response Type** setting in the impersonation menu's [Advanced Settings](#advanced-settings) from `Code` to `Token` (**Sign in as user** -> **Show Advanced Settings**). Alternatively, you can add `additionalParameters.scope: "openid"` to the request body while calling the [impersonation endpoint](/api/authentication/reference#impersonation) manually.
+:::
+
+### Advanced settings
+
+When impersonating a user in Dashboard, after clicking **Sign in as User** you will see a link to expand "Advanced Settings."
+
+![Advanced Settings](/media/articles/user-profile/impersonation-adv.png)
+
+This reveals fields to make it easier to [Impersonate a User Using the Impersonation API](/users/guides/impersonate-users-using-the-impersonation-api):
+
+- **Response mode**: `GET` or `POST`. This is only for server side apps, client side apps default to `GET`.
+- **Response type**: `Code` or `Token`. This is only for server side apps, client side apps default to `Token`.
+- **Scope**: This field will have `openid` in it is as default, [other scopes](/scopes) can be added as a list using whitespace as separator.
+- **State**: The `state` is a required parameter and leaving it blank may lead to errors like `Impersonation - Bad mac`. For more information, see [State Parameter](/protocols/oauth2/oauth-state).
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/impersonate-users-using-the-impersonation-api.md b/fr-ca/articles/users/guides/impersonate-users-using-the-impersonation-api.md
new file mode 100644
index 0000000000..f7b7edc0b7
--- /dev/null
+++ b/fr-ca/articles/users/guides/impersonate-users-using-the-impersonation-api.md
@@ -0,0 +1,190 @@
+---
+description: Learn how to impersonate a user using the Impersonation API.
+sitemap: false
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Impersonate Users Using the Impersonation API
+
+<%= include('../../_includes/_deprecate-impersonation') %>
+
+Use the [Impersonation API](/api/authentication/reference#impersonation) to generate a link that can be used **only once** to log in as a specific user. To distinguish between real logins and impersonation logins, the profile of the impersonated user will also contain additional `impersonated` and `impersonator` properties. 
+
+The following steps assume that you have two apps, `app1` and `app2`, and you want to impersonate the users of `app2`. You will need to locate the `user_id` of the user you wish to impersonate, either via the Dashboard or the Management API. Next, you will need to obtain an authorization code via the impersonation endpoint. Finally, you will need to exchange your code for a valid Access Token, and your impersonation process will be complete. You can walk through the steps below which use the example `app1` and `app2`.
+
+1. Use one of two methods to locate the `user_id` of a given user that you want to impersonate. You can either use the Management API v2 to retrieve it, or you can use the Dashboard.
+
+   - **Option A: Use the Management API**
+     First, you will need an APIv2 token, if you want to retrieve the `user_id` via the Management API. You can get one by making a `POST` request to the [Token endpoint](/api/authentication#client-credentials). For details on how to do that see [Access Tokens for the Management API](/api/management/v2/concepts/tokens).
+
+     The Management APIv2 Token will be valid for 24 hours, so you should ask for a token every time you make a request to the API, or be prepared to handle a high volume of  `401` responses.
+
+     After you have a token, you will have to use the token to retrieve the user id of the user that you want to impersonate (in this example, a user of `app2`). You can retrieve this information with the [Management API /api/v2/users](/api/management/v2#!/Users/get_users) endpoint.
+
+     ```har
+     {
+        "method": "GET",
+        "url": "https://${account.namespace}/api/v2/users",
+        "headers": [
+          { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+        ]
+     }
+     ```
+
+     Replace `YOUR_ACCESS_TOKEN` with the Management APIv2 token you got in the previous step.
+
+   - **Option B: Use the Dashboard**
+     Alternatively, you can retrieve the `user_id` information from the Dashboard. Go to the [Users](${manage_url}/#/users) section and look at the user's profile. The `user_id` is displayed under the **Identity Provider Attributes** section.
+
+2. Get an Authorization Code. Before calling the call the [Impersonation API](/api/authentication/reference#impersonation) you will need to generate a Bearer token. You can generate it with the [Management API V1 /oauth/token endpoint](/api/management/v1#authentication) with your **Global Client ID** and **Global Client Secret** which both can be found in the Dashboard under [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced).
+
+![Global Client Information](/media/articles/user-profile/global-client-info.png)
+
+3. You can now send a request to the [impersonation endpoint](/api/authentication/reference#impersonation) by sending an `Authorization` header with `Bearer `.
+
+   The data part of the request includes the following parameters:
+
+   - `protocol`: The protocol to use against the identity provider. It could be `oauth2` again or something else. (for example, Office 365 uses WS-Federation, G Suite uses OAuth2, AD will use LDAP or Kerberos).
+
+   - `impersonator_id`: The `user_id` of the impersonator, the user from `app1` that wants to impersonate a user from `app2`.
+
+   - `client_id`: The `client_id` of the app that is generating the impersonation link, in this example `app1`.
+
+   - `additionalParameters`: This is a JSON object. For a regular web app, you should set the `response_type` to be `code`, the `callback_url` to be the callback url to which Auth0 will redirect with the authorization code, and the `scope` to be the JWT claims that you want included in the JWT. For example:
+  
+     ```json
+     {
+       "response_type": "code",
+       "state": "",
+       "callback_url" : "http://localhost:3001/register",
+       "scope" : "openid email name user_metadata"
+     }
+     ```
+
+   - `state`: is an optional parameter, but we strongly recommend you use it to [mitigate CSRF attacks](/protocols/oauth2/mitigate-csrf-attacks).
+
+   - `callback_url`: Must match what is defined in your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+   - `scope`: There are various possible values for `scope`:
+
+     - `scope: 'openid'`: _(default)_ Returns an opaque Access Token **and** an [ID Token](/tokens/concepts/id-tokens), which is a JSON Web Token ([JWT](/tokens/concepts/jwts)). The JWT will only contain the user ID (`sub` claim).
+     - `scope: 'openid {attr1} {attr2} {attrN}'`: Returns only specific user's attributes to be part of the [ID Token](/tokens/concepts/id-tokens) (for example, `scope: 'openid name email picture'`).
+
+     For more information, see [Scopes documentation](/scopes).
+
+     ::: note
+     Impersonation cannot be used to return [Access Tokens](/tokens/concepts/overview-access-tokens) to your APIs.
+     :::
+
+     Your request should look like the following:
+
+     ```har
+     {
+       "method": "POST",
+       "url": "https://${account.namespace}/users/USER_ID/impersonate",
+       "headers": [
+         { "name": "Content-Type", "value": "application/json" },
+         { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+       ],
+       "postData": {
+         "mimeType": "application/json",
+         "text": "{\"protocol\": \"PROTOCOL_TO_USE\",\"impersonator_id\": \"IMPERSONATOR_ID\",\"client_id\": \"${account.clientId}\",\"additionalParameters\":{\"response_type\": \"code\",\"state\": \"\"}}"
+       }
+     }
+     ```
+
+4. Replace the required values as follows:
+
+   - `YOUR_USER_ID`: The `user_id` you retrieved at the second step (the user to impersonate)
+   - `YOUR_ACCESS_TOKEN`: The token already retrieved at the first step
+   - `PROTOCOL_TO_USE`: The protocol to use against the identity provider, for example `oauth2`
+   - `IMPERSONATOR_ID`: The `user_id` of the impersonator
+
+   A successful response returns a URL which can be used to authenticate as the user. The URL should look like the following:
+
+   ```text
+   https://${account.namespace}/users/IMPERSONATOR_ID/impersonate?&abc=XYZ123
+   ```
+
+5. Perform a GET request on the URL you received to get a new URL with a `code` and `state` value. The response should look like the following:
+
+   ```text
+   ${account.callback}/?code=AUTHORIZATION_CODE&state=STATE_VALUE
+   ```
+
+   - `${account.callback}` is the URL you specified as `callback_url` (and configured in your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings))
+   - `state` should match the `state` value you sent with your request
+   - `code` is the authorization code you need
+
+   ::: panel Single-Page Apps
+   The process described applies to regular web apps. In case yours is a single-page app (SPA) you should use `"response_type":"token"` when invoking the [Impersonation API](/api/authentication/reference#impersonation). Auth0 will redirect to your SPA _Callback URL_ with Access Token and ID Token in the `#` params. You can read more on the OAuth 2.0 Implicit flow [here](/protocols/oauth2/oauth-implicit-protocol).
+   :::
+
+6. Exchange the authorization code you received for a token. 
+
+   ::: note
+   This should already be implemented if you have a regular web app and are using the OAuth Server Side flow for authenticating normal users. If not, you should send a `POST` request to the [Token endpoint in Auth0](/api/authentication#authorization-code). You will need to send the authorization code obtained before along with your Client ID and Client Secret.
+   :::
+
+   ```har
+   {
+     "method": "POST",
+     "url": "https://${account.namespace}/oauth/token",
+     "headers": [
+       { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+     ],
+     "postData": {
+        "mimeType": "application/x-www-form-urlencoded",
+        "params": [
+          {
+            "name": "grant_type",
+            "value": "authorization_code"
+          },
+          {
+            "name": "client_id",
+            "value": "${account.clientId}"
+          },
+          {
+            "name": "client_secret",
+            "value": "YOUR_CLIENT_SECRET"
+          },
+          {
+            "name": "code",
+            "value": "YOUR_AUTHORIZATION_CODE"
+          },
+          {
+            "name": "redirect_uri",
+            "value": "${account.callback}"
+          }
+        ]
+     }
+   }
+   ```
+
+7. Replace the `AUTHORIZATION_CODE` with the `code` you received previously. Also, replace `${account.callback}` with your application's callback URL. 
+
+   If the request is successful, you will get a JSON object with an Access Token. You can use this token to call the Auth0 APIs and get additional information such as the user profile.
+
+   ```json
+   HTTP/1.1 200 OK
+   Content-Type: application/json
+   {
+     "access_token":"eyJz93a...k4laUWw",
+     "id_token":"eyJ0XAi...4faeEoQ",
+     "token_type":"Bearer",
+     "expires_in":86400
+   }
+   ```
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/link-user-accounts-auth-api.md b/fr-ca/articles/users/guides/link-user-accounts-auth-api.md
new file mode 100644
index 0000000000..6de0c67af4
--- /dev/null
+++ b/fr-ca/articles/users/guides/link-user-accounts-auth-api.md
@@ -0,0 +1,129 @@
+---
+description: How to link accounts using the Authentication API (Deprecated)
+public: false
+topics:
+  - authentication-api
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+
+# Link Accounts using Authentication API (Deprecated)
+
+::: warning
+This method of linking accounts using the linking endpoint of the [Authentication API](/api/authentication#link), either through **Lock** or by manually calling the API, is **deprecated** and should no longer be used. The [POST /api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) should be used instead. For more information refer to the [Migration Notice](/migrations/past-migrations#account-linking-removal).
+:::
+
+## Link through Auth0 Login Widget
+
+```js
+
+
+
+Add account
+```
+
+::: note
+Notice the `access_token` fragment of the URL that is normally not present. Auth0 generates this `access_token` when a user logs in and uses it to uniquely identify the user.
+:::
+
+## Manual initiation
+
+The following example will manually initiate the authentication transaction:
+
+`https://${account.namespace}/authorize?response_type=code&scope=openid`
+`&client_id=${account.clientId}`
+`&redirect_uri=${account.callback}`
+`&access_token=...LOGGED_IN_USER_ACCESS_TOKEN...`
+
+## Obtain an authenticated user's *access_token*
+
+The SDK for your platform should make the `access_token` available in simplest way for your platform. For example:
+
+* If you are using Lock in [Popup Mode](/libraries/lock/v10/popup-mode) in a SPA, the `access_token` is available as a callback parameter:
+
+  ```js
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+
+  lock.show(function(err, profile, id_token, access_token) {
+    //save access_token here for linking other accounts
+  })
+  ```
+
+* If you are using [passport-auth0](https://github.com/auth0/passport-auth0) in a regular Node.js web app, the `access_token` is available in the `strategy` callback and can be saved to the session for later use:
+
+  ```js
+  var Auth0Strategy = require('passport-auth0'),
+      passport = require('passport');
+
+  var strategy = new Auth0Strategy({
+     domain:       '${account.namespace}',
+     clientID:     '${account.clientId}',
+     clientSecret: 'YOUR_CLIENT_SECRET',
+     callbackURL:  '${account.callback}',
+     passReqToCallback: true //need this to save the accessToken to session
+    },
+    function(req, accessToken, refreshToken, extraParams, profile, done) {
+      // save accessToken to session to be able to link accounts later
+      req.session.accessToken = accessToken;
+      // profile has all the information from the user
+      return done(null, profile);
+    }
+  );
+
+  passport.use(strategy);
+  ```
+
+* If you are using ASP.NET, the `access_token` is available as a claim:
+
+  ```
+  ${'<%= ClaimsPrincipal.Current.FindFirst("access_token").Value %>'}
+  ```
+
+* If you are building your own implementation, the `access_token` will be available through the standard OAuth2 flow:
+
+  1. User logs in and returns to the app with a `code`
+  2. The app exchanges the `code` for the `access_token`
+
+  The details of these exchanges are available at [Identity Protocols supported by Auth0](/protocols).
+
+## Unlinking Accounts
+
+To unlink a specific account, POST request to the following url:
+
+`https://${account.namespace}/unlink`
+
+The body should be:
+
+```
+{
+    access_token: "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity access_token
+    user_id: "LINKED_USER_ID" // (provider|id)
+}
+```
+
+## Keep reading
+
+* [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/fr-ca/articles/users/guides/link-user-accounts.md b/fr-ca/articles/users/guides/link-user-accounts.md
new file mode 100644
index 0000000000..8de250860c
--- /dev/null
+++ b/fr-ca/articles/users/guides/link-user-accounts.md
@@ -0,0 +1,188 @@
+---
+title: Link User Accounts
+description: Learn how to link user accounts from various identity providers, so your users can authenticate from any of their accounts and still be recognized by your app and associated with the same user profile.
+topics:
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+# Link User Accounts
+
+Link user accounts together to form a primary and secondary relationship. On successful linking, the endpoint returns the new array of the primary account identities. 
+
+Auth0 supports the linking of user accounts from various identity providers. This allows a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. This feature requires a paid subscription to the **Developer**, **Developer Pro** or **Enterprise** plan (see [Pricing](https://auth0.com/pricing)).
+
+::: note
+Auth0 treats all identities as separate by default. For example, if a user logs in first against the Auth0 database and then via Google or Facebook, these two attempts would appear to Auth0 as two separate users.
+:::
+
+There are three ways to link accounts:
+
+* Use the Account Link extension
+* Use the Management API 
+* Use Auth0.js 
+
+Use the tabs below to see the details for each option.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+
+## Account Link extension
+
+Install and configure the [Account Link Extension](/extensions/account-link) extension in the Dashboard to prompt users that may have created a second account to link the new account with their old one on their first login. The user can choose to either link the two accounts or keep them separate if it was intentional.
+    
    
+    
    
+
+## Management API endpoint
+
+The Auth0 Management API provides the [Link a user account](/api/v2#!/Users/post_identities) endpoint, which can be invoked in two ways:
+
+* User initiated account linking using Access Tokens with the `update:current_user_identities` scope
+* Server-side account linking using Access Token that contains the `update:users` scope
+
+### User initiated client-side account linking 
+
+For user initiated account linking from client-side code, use an Access Token that contains the following items in the payload:
+- `update:current_user_identites` scope
+- `user_id` of the primary account as part of the URL
+- ID Token of the secondary account must be signed with `RS256` and an `aud` claim identifying the client that matches the value of the requesting Access Token's `azp` claim. 
+
+An Access Token that contains the `update:current_user_identities` scope can **only** be used to update the information of the currently logged-in user. Therefore, this method is suitable for scenarios where the user initiates the linking process.
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+### Server-side account linking 
+
+For server-side account linking, use an Access Token that contains the following items in the payload:
+- `update:users` scope
+- `user_id` of the primary account as part of the URL
+- `user_id` of the secondary account 
+- ID Token of the secondary account must be signed with `RS256` and an `aud` claim identifying the client that matches the value of the requesting Access Token's `azp` claim. 
+
+Access Tokens that contain the `update:users` scope can be used to update the information of **any** user. Therefore, this method is intended for use in server-side code only.
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"provider\":\"SECONDARY_ACCOUNT_PROVIDER\", \"user_id\": \"SECONDARY_ACCOUNT_USER_ID\"}"
+  }
+}
+```
+
+The `SECONDARY_ACCOUNT_USER_ID` and `SECONDARY_ACCOUNT_PROVIDER` can be deduced by the unique ID of the user. For example, if the user ID is `google-oauth2|108091299999329986433`, set the `google-oauth2` part as the `provider`, and the `108091299999329986433` part as the `user_id` at your request.
+
+Instead of the `provider` and `user_id`, you can send the secondary account's ID Token as part of the payload:
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+  
    
+  
    
+
+## Auth0.js library
+
+You can use the [Auth0.js](/libraries/auth0js) library.
+
+First, you must get an Access Token that can be used to call the Management API. You can do it by specifying the `https://${account.namespace}/api/v2/` audience when initializing Auth0.js. You will get the Access Token as part of the authentication flow. Alternatively, you can use the `checkSession` method.
+
+Once you have the Access Token, you can create a new `auth0.Management` instance by passing it the account's Auth0 domain, and the Access Token.
+
+For more information and sample scripts, see [Auth0.js > User management](/libraries/auth0js/v9#user-management).
+    
    
+  
    
+
    
+
+## Add missing information with Rules
+
+When a user logs in, apps receive user information from the **primary identity**. Auth0 does not attempt to automatically complete missing profile fields with information from the secondary identities. For example, if the primary identity comes from a database connection and is missing the `given_name` and `family_name` properties, and the secondary identity comes from a Google social connection that includes the first and last name of the user, then the application will **not** receive data contained in the second identity.
+
+To add missing information to primary identities with information from secondary identities, you can write a [rule](/rules) like the following example:
+
+```js
+function(user, context, callback) {
+  
+  const propertiesToComplete = ["given_name", "family_name", "name"];
+
+  // go over each property and try to get missing
+  // information from secondary identities
+  for(var property of propertiesToComplete) {
+    if (!user[property]) {
+      for(var identity of user.identities) {
+        if (identity.profileData && identity.profileData[property]) {
+          user[property] = identity.profileData[property];
+          break;
+        }
+      }
+    }
+  }
+  
+  callback(null, user, context);
+}
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/fr-ca/articles/users/guides/manage-user-access-to-applications.md b/fr-ca/articles/users/guides/manage-user-access-to-applications.md
new file mode 100644
index 0000000000..f16c8845b8
--- /dev/null
+++ b/fr-ca/articles/users/guides/manage-user-access-to-applications.md
@@ -0,0 +1,30 @@
+---
+description: Explains the basics of a user profile, how to create a user and view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+---
+# Manage User Access to Applications
+
+All users associated with a single Auth0 tenant are shared between the tenant's applications (and therefore have access to the applications). To keep users separate and restrict their access, we recommend creating an additional tenant:
+
+1. Click on tenant name on top right of the dashboard and select **+ Create Tenant** . If you have multiple tenants, you can easily switch between them from the tenants menu.
+
+2. To restrict some users' access to certain applications, you can use [rules](/rules). Inside a rule, the `context.clientName` and `context.clientID` variables are available to check which application the user is using for login. See [this rule for an example](https://github.com/auth0/rules/blob/aeaf93bc058408e260192d0941a688963449d6be/src/rules/simple-user-whitelist-for-app.js).
+
+3. To restrict users from applications by configuring a new connection and only giving access to a specific application. 
+
+   * Go to the the **Settings** section for a connection.
+   * Click on the **Applications** tab and enable/disable any application.
+
+4. To disable users' access to your applications, you can [block and unblock users](/users/guides/block-and-unblock-users) in the Dashboard.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [Update Users Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/fr-ca/articles/users/guides/manage-user-metadata.md b/fr-ca/articles/users/guides/manage-user-metadata.md
new file mode 100644
index 0000000000..79b85743c9
--- /dev/null
+++ b/fr-ca/articles/users/guides/manage-user-metadata.md
@@ -0,0 +1,70 @@
+---
+description: How to create and update metadata using the Auth0 APIs and Lock and how to work with custom databases.
+toc: true
+crews: crew-2
+topics:
+  - metadata
+  - apis
+  - management-api
+contentType: how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Manage User Metadata
+
+You can create and update metadata using [Rules](/rules/current/metadata-in-rules), the [Authentication API](/api/authentication), the [Management API](/api/management/v2), and the [Lock](/libraries/lock) library.
+
+## Rules
+
+[Rules](/rules) are JavaScript functions executed as part of the Auth0 authentication process (prior to authorization). Using rules, you can read, create, or update user metadata and have such changes affect the results of the authorization process. 
+
+For more information and examples, see [User Metadata in Rules](/rules/current/metadata-in-rules).
+
+## Authentication API
+
+If you have a [custom database connection](/connections/database#using-your-own-user-store), you can use the [Authentication API](/api/authentication) [Signup](/api/authentication?shell#signup) endpoint to set the `user_metadata` for a user. For an example of working with metadata during a custom signup process, see [Custom Signup > Using the API](/libraries/custom-signup#using-the-api).
+
+<%= include('../../_includes/_metadata_on_signup_warning') %>
+
+You can also use the [GET /userinfo endpoint](/api/authentication#get-user-info) to get a user's `user_metadata`, however you must first [write a Rule](/rules/guides/metadata) to copy `user_metadata` properties to the ID Token.
+
+## Management API
+
+Use the following [Management API](/api/management/v2) endpoints to view, create, update, and delete the `user_metadata` and `app_metadata` fields.
+
+| **Task** | **Endpoint** | **Scope** | 
+| -- | -- | -- |
+| View | [`GET /api/v2/user/{id}`](/api/management/v2#!/Users/get_users_by_id) | `read:current_user_metadata` | 
+| Create | [`PATCH /api/v2/users/{id}`](/api/management/v2#!/Users/post_users) | `create:current_user_metadata` |
+| Update | [`PATCH /api/v2/users/{id}`](/api/management/v2#!/Users/patch_users_by_id) | `update:current_user_metadata` | 
+| Delete | [`DELETE /api/v2/users/{id}/multifactor/{provider}`](/api/management/v2#!/Users/delete_multifactor_by_provider) | `delete:current_user_metadata` | 
+
+::: note
+The Auth0 Management APIv2 token is required to call the Auth0 Management API. Learn more about [Access Tokens for the Management API](/api/management/v2/tokens) and [Get Management API Tokens for SPAs](/api/management/v2/get-access-tokens-for-spas).
+:::
+
+## Lock library
+
+You can define, add, read, and update the `user_metadata` using Auth0's [Lock](/libraries/lock) library. For information on adding `user_metadata` on signup, see [Additional Signup Fields](/libraries/lock/v10/customization#additionalsignupfields-array-).
+
+When using Lock, you can read the user's `user_metadata` properties the same way you would for any other user profile property. For example, the following code snippet retrieves the value associated with `user_metadata.hobby` and assigns it to an element on the page:
+
+```js
+// Use the accessToken acquired upon authentication to call getUserInfo
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    document.getElementById('hobby').textContent = profile.user_metadata.hobby;
+  }
+});
+```
+
+## Keep reading
+
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Metadata Best Practices](/best-practices/metadata-best-practices)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
diff --git a/fr-ca/articles/users/guides/manage-users-using-the-dashboard.md b/fr-ca/articles/users/guides/manage-users-using-the-dashboard.md
new file mode 100644
index 0000000000..865cef7e1b
--- /dev/null
+++ b/fr-ca/articles/users/guides/manage-users-using-the-dashboard.md
@@ -0,0 +1,34 @@
+---
+description: Describes how to manage users in the Auth0 Dashboard.
+crews: crew-2
+topics:
+  - dashboard
+  - users
+contentType: how-to
+useCase:
+  - manage-users
+v2: True
+---
+
+# Manage Users Using the Dashboard
+
+You can use the Dashboard to manage your users. To begin, go to [Dashboard > Users](${manage_url}/#/users). This is where you'll go to create, view, modify, or delete users.
+
+::: note
+User Management is included as part of the **Developer** subscription plan. You may need to [upgrade your plan](${manage_url}/#/tenant/billing/subscription) to access these features.
+:::
+
+::: warning
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+:::
+
+![User Profile Dashboard](/media/articles/user-profile/user1.png)
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [View Users](/users/guides/view-users)
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
+* [User Search](/users/search)
diff --git a/fr-ca/articles/users/guides/manage-users-using-the-management-api.md b/fr-ca/articles/users/guides/manage-users-using-the-management-api.md
new file mode 100644
index 0000000000..c1ede2f52b
--- /dev/null
+++ b/fr-ca/articles/users/guides/manage-users-using-the-management-api.md
@@ -0,0 +1,48 @@
+---
+description: Explains the basics of a user profile, how to create a user and view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Manage Users Using the Management API
+
+In addition to using the Dashboard, you can retrieve, create, update or delete users using our [Management API](/api/management/v2#!/Users/get_users).
+
+## How to manage users
+
+If you want to call the Management API directly, you will first need to generate the appropriate Access Token. For information on how to do that refer to [Access Tokens for the Management API](/api/management/v2/tokens).
+
+Alternatively, you can use an SDK to implement the functionality you need to call the Management API from your application. For a list of available SDKs, refer to [the SDKs section of our Support Matrix](/support/matrix#sdks).
+
+::: note
+You can setup Access Control List (ACL)/Roles functionality using our [Role-based Access Control (RBAC)](/authorization/concepts/rbac).
+:::
+
+## Limitations
+
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+
+### Set passwords
+
+The password can be set via the `create` or `update` calls, but for security purposes, it cannot be viewed via the `get` or `list user` commands. The right side of the API explorer provides hints on the user profile attributes which can be viewed or modified for any given call.
+
+## Endpoints
+
+* You can use the [`/users`](/api/v2#!/Users/get_users) endpoint to retrieve information about all users. You can also include search criteria to find specific users.
+
+* Use the [`/user_id`](/api/v2#!/Users/get_users_by_id) to retrieve information about one user based on the `user_id`. The `user_id` is an internal identifier that consists of a connection name and a unique identifier for the user. The `user_id` is different from the ID Token.
+
+* The [`/userinfo`](/api/authentication/reference#get-user-info) endpoint takes as input the Auth0 Access Token and returns user profile information. This endpoint will include the results of any rules that may have altered the user profile during the authentication transaction, but the resulting user profile will not be filtered by any [Scoping](#scopes).
+
+* The [`/tokeninfo`](/api/authentication/reference#get-token-info) endpoint takes as input the Auth0 ID Token and returns User Profile information. This endpoint will return a result that does not include the results of any rules that alter the User Profile.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/read-metadata.md b/fr-ca/articles/users/guides/read-metadata.md
new file mode 100644
index 0000000000..6392c91e8c
--- /dev/null
+++ b/fr-ca/articles/users/guides/read-metadata.md
@@ -0,0 +1,75 @@
+---
+description: Retrieve metadata using the Management API or Lock.
+topics: 
+   - metadata
+   - rules
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Read Metadata
+
+You can read metadata using rules with the Management API and with Lock. You can also search for profile-related information in `user_metadata`, such as:
+
+- `name`
+- `nickname`
+- `given_name`
+- `family_name`
+
+<%= include('../_includes/_connection-synch-note.md') %>
+
+::: note 
+When using the deprecated [Search v2](/users/search/v2), beginning **1 September 2017** new tenants cannot search any of the  `app_metadata` fields. Only tenants associated with paid subscriptions that were created on/before **31 August 2017** can search the `app_metadata` fields.
+This limitation does not apply to [Search v3](/users/search/v3).
+:::
+
+As an example, assume the following metadata is stored for a user with the email address `jane.doe@example.com`:
+
+```json
+{
+    "emails": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+## Read metadata with the Management API
+
+Using the example metadata above, you can refer to specific items from the dataset in [Rules](/rules) or via a call to the [Management API](/users/guides/manage-user-metadata) as follows:
+
+```js
+console.log(user.email); // "jane.doe@example.com"
+console.log(user.user_metadata.hobby); // "surfing"
+console.log(user.app_metadata.plan); // "full"
+```
+Any valid JSON snippet can be used as metadata.
+
+::: note
+In Management APIv1, all metadata is stored in the `metadata` field. Data stored in this field is **now** available from the Management APIv2 as `app_metadata`.
+:::
+
+## Read metadata with Lock
+
+Using the Lock library, you can read the user's `user_metadata` properties the same way you would read any other user profile property. This example retrieves the value associated with `user_metadata.hobby` using the example user metadata listed above:
+
+```js
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    document.getElementById('hobby').textContent = profile.user_metadata.hobby;
+  }
+});
+```
+
+For details on how to initialize `lock` refer to [Auth0Lock(clientID, domain, options)](https://github.com/auth0/lock#new-auth0lockclientid-domain-options).
+
+## Keep Reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
diff --git a/fr-ca/articles/users/guides/redirect-users-after-login.md b/fr-ca/articles/users/guides/redirect-users-after-login.md
new file mode 100644
index 0000000000..72258e9615
--- /dev/null
+++ b/fr-ca/articles/users/guides/redirect-users-after-login.md
@@ -0,0 +1,64 @@
+---
+description: How to redirect users to URLs that have not been whitelisted
+topics:
+  - users
+  - user-management
+  - redirection
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Redirect Users After Login Authentication
+
+You can return users to specific pages (URLs) within your application after validating their ID Tokens (authentication). To see an example of how this works, try the [React: Login Quickstart](/quickstart/spa/react). 
+
+## Redirect users to whitelisted callback URLs
+
+Because callback URLs can be manipulated by unauthorized parties, Auth0 recognizes only whitelisted URLs set in the **Allowed Callback URLs** field of an [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings) as valid. To return users to whitelisted callback URLs, it is necessary for your application to know how to continue the user on their journey. 
+
+There are two methods for doing this:
+
+* Using cookies and browser sessions
+* Using `state` parameters
+
+During a user's authentication, the `redirect_uri` request parameter is used as a callback URL. This is where your application receives and processes the response from Auth0, and is often the URL to which users are redirected once the authentication is complete. For more information on how the `redirect_uri` works, see [OAuth 2.0](/protocols/oauth2).
+
+### Use cookies or browser sessions
+
+You can use a cookie or the browser session to store a return URL value. This is a simple solution to implement, however it can cause issues in cases where a cookie does not persist. There are two separate user sessions initiated in this situation. Each serves a separate purpose and requires some consideration to achieve the desired user experience.
+
+* **Auth0-provided OIDC SSO Session**: Auth0 provides a session for enabling [OIDC Single Sign On (SSO)](/api-auth/tutorials/adoption/single-sign-on) to allow your user to maintain an authentication session without being prompted for credentials more than once. This session is maintained by Auth0 and referenced as a cookie bound to your tenant domain (or `CNAME`). There are two [tenant settings](/sso/current/configure-session-lifetime-limits) that determine the length of the Auth0 Session:
+  - The `idle_session_lifetime` is how long the session will remain alive without interaction.  
+  - The `session_lifetime` is the maximum duration that the session is allowed to remain alive. 
+  
+  These settings apply to all applications within your tenant and should be configured to align with the security model that matches your use case.  
+
+* **Application Session**: Your application must also maintain a concept of session.  Throughout the user session, your application may need to request additional tokens or renew expired ones. You should store these tokens in your application and reference them using an identifier passed back to the browser using a secure cookie. 
+
+Once your user has authenticated with Auth0 it is up to your application to determine how long it persists this session.
+
+### Use `state` parameters
+
+As an alternative method, you can create a [deep link using the `state` parameter](/protocols/oauth2/redirect-users) which your callback would interpret to determine a forwarding path. This solution takes a little more work to implement but guarantees that the application has the information it needs once the redirect is complete. 
+
+In essence, you send a random value when starting an authentication request and validate the received value when processing the response (this implies you store something on the client application side, in session or other medium, that allows you to perform the validation). If you receive a response with a state that does not match, you were likely the target of an attack because this is either a response for an unsolicited request or someone trying to forge a response.
+
+Your application type determines the best place to keep the data that allows your app to validate the response. For example, assuming a pregressive web app is leveraging a SPA framework then it could store this in local storage while a traditional web app framework would store it in server-side session.
+
+## Redirect users to other URLs
+
+Sometimes, the callback URL is not necessarily where you want users redirected after authentication. For example, if a user intends to access a protected page in your application, and that action triggers the request to authenticate, you can store that URL to redirect the user back to their intended page after the authentication finishes. Store the desired URL using the following methods:
+
+* [Redirect users with state parameters](/protocols/oauth2/redirect-users)
+* [Redirect users from within rules](/rules/current/redirect)
+
+Choose the option that works best for your application type and the type of [flow](/api-auth/which-oauth-flow-to-use) that you are using. Create the necessary logic in your application to retrieve the stored URL and redirect your users where you want them to go. The [Auth0 SDKs](/libraries/auth0js/v9#available-parameters) also include support for redirect URLs.
+  
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [API Authorization](/api-auth)
diff --git a/fr-ca/articles/users/guides/set-metadata-properties-on-creation.md b/fr-ca/articles/users/guides/set-metadata-properties-on-creation.md
new file mode 100644
index 0000000000..4568835620
--- /dev/null
+++ b/fr-ca/articles/users/guides/set-metadata-properties-on-creation.md
@@ -0,0 +1,60 @@
+---
+description: Describes how to set metadata properties on creation using the Management API.
+topics: metadata
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Set Metadata Properties on Creation
+
+To create a user with the following profile details:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+Make the following `POST` call to the [Create User endpoint of the Management API](/api/management/v2#!/Users/post_users), to create the user and set the property values:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"email\": \"jane.doe@example.com\", \"user_metadata\": {\"hobby\": \"surfing\"}, \"app_metadata\": {\"plan\": \"full\"}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+::: panel Define User Metadata on Signup
+For information on adding `user_metadata` on signup, see the section on Lock [Additional Signup Fields](/libraries/lock/v10/customization#additionalsignupfields-array-)
+:::
+
+## Keep Reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Update Metadata with the Management API](users/guides/update-metadata-properties-with-management-api)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
\ No newline at end of file
diff --git a/fr-ca/articles/users/guides/unlink-user-accounts.md b/fr-ca/articles/users/guides/unlink-user-accounts.md
new file mode 100644
index 0000000000..1604457605
--- /dev/null
+++ b/fr-ca/articles/users/guides/unlink-user-accounts.md
@@ -0,0 +1,182 @@
+---
+title: Unlink User Accounts
+description: Learn how to use the Management API Unlink a User Account endpoint to unlink an identity from the target user account making it a separate user account again.
+topics:
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+# Unlink User Accounts
+
+Use the Auth0 Management API [Unlink a user account](/api/management/v2#!/Users/delete_user_identity_by_user_id) endpoint or the Auth0.js library to unlink an identity from the target user account making it a separate user account again. 
+
+The result of the unlinking process is the following:
+* The secondary account is removed from the identities array of the primary account.
+* A new secondary user account is created.
+* The secondary account will have no metadata.
+
+::: note
+If your goal is to delete the secondary identity entirely, you must first unlink the accounts, and then [delete the newly created secondary account](/users/guides/delete-users).
+:::
+
+Depending on from where you call the endpoint, use one of these two scopes:
+
+* `update:current_user_identities` from [client-side code](/users/references/link-accounts-client-side-scenario)
+* `update:users` from [server-side code](/users/references/link-accounts-server-side-scenario)
+
+The endpoint uses the following parameters:
+
+| Parameter | Type | Description |
+| -- | -- | -- | 
+| `id` | `string` | ID of the primary user account (required) |
+| `provider` | `string` | identity provider name of the secondary linked account (e.g. `google-oauth2`) |
+| `user_id` | `string` | ID of the secondary linked account (e.g. `123456789081523216417` part after the `|` in `google-oauth2|123456789081523216417`) |
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Response example
+
+```js
+[
+  {
+    "connection": "Initial-Connection",
+    "user_id": "5457edea1b8f22891a000004",
+    "provider": "auth0",
+    "isSocial": false,
+    "access_token": "",
+    "profileData": {
+      "email": "",
+      "email_verified": false,
+      "name": "",
+      "username": "johndoe",
+      "given_name": "",
+      "phone_number": "",
+      "phone_verified": false,
+      "family_name": ""
+    }
+  }
+]
+```
+
+## Use JWT from the primary account
+
+To unlink accounts, call the Management API [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using the JWT from the primary account for authorization:
+
+```js
+function unlinkAccount(secondaryProvider, secondaryUserId){
+  var primaryUserId = localStorage.getItem('user_id');
+  var primaryJWT = localStorage.getItem('id_token');
+  $.ajax({
+    type: 'DELETE',
+    url: 'https://' + '${account.namespace}' + '/api/v2/users/' + primaryUserId +
+         '/identities/' + secondaryProvider + '/' + secondaryUserId,
+    headers: {
+      'Authorization': 'Bearer ' + primaryJWT
+    }
+  }).then(function(identities){
+    alert('unlinked!');
+    showLinkedAccounts(identities);
+  }).fail(function(jqXHR){
+    alert('Error unlinking Accounts: ' + jqXHR.status + ' ' + jqXHR.responseText);
+  });
+}
+```
+
+## Use Access Token with the `update:users` scope
+
+If you need to unlink two or more user accounts, call the Management API [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using an [Management API Access Token](/api/v2/tokens) with the `update:users` scope.
+
+```js
+function unlinkAccount(secondaryProvider, secondaryUserId) {
+  var primaryUserId = localStorage.getItem('user_id');
+  var primaryAccessToken = localStorage.getItem('access_token');
+
+  // Uses the Access Token of the primary user as a bearer token to identify the account
+  // which will have the account unlinked to, and the user id of the secondary user, to identify
+  // the user that will be unlinked from the primary account.
+
+  $.ajax({
+    type: 'DELETE',
+    url: 'https://' + AUTH0_DOMAIN +'/api/v2/users/' + primaryUserId +
+         '/identities/' + secondaryProvider + '/' + secondaryUserId,
+    headers: {
+      'Authorization': 'Bearer ' + primaryAccessToken
+    }
+  }).then(function(identities){
+    alert('unlinked!');
+    showLinkedAccounts(identities);
+  }).fail(function(jqXHR){
+    alert('Error unlinking Accounts: ' + jqXHR.status + ' ' + jqXHR.responseText);
+  });
+}
+```
+
+## Unlink accounts from server-side code
+
+1. Update the user in session with the new array of identities (each of which represent a separate user account).
+
+    ```js
+    const ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn();
+    const Auth0Client = require('../Auth0Client');
+    const express = require('express');
+    const router = express.Router();
+    ...
+    router.post('/unlink-accounts/:targetUserProvider/:targetUserId',ensureLoggedIn, (req,res,next) => {
+      Auth0Client.unlinkAccounts(req.user.id, req.params.targetUserProvider, req.params.targetUserId)
+      .then( identities => {
+        req.user.identities = req.user._json.identities = identities;
+        res.send(identities);
+      })
+      .catch( err => {
+        console.log('Error unlinking accounts!',err);
+        next(err);
+      });
+    });
+    ```
+
+2. Call the Management API v2 [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using an [Management API Access Token](/api/v2/tokens) with the `update:users` scope.
+
+    ```js
+    const request = require('request');
+
+    class Auth0Client {
+      ...
+      unlinkAccounts(rootUserId, targetUserProvider, targetUserId){
+        return new Promise((resolve,reject) => {
+          var reqOpts = {
+            method: 'DELETE',
+            url: 'https://${account.namespace}/api/v2/users/' + rootUserId +
+                '/identities/' + targetUserProvider + '/' + targetUserId,
+            headers: {
+              'Authorization': 'Bearer ' + process.env.AUTH0_APIV2_TOKEN
+            }
+          };
+          request(reqOpts,(error, response, body) => {
+            if (error) {
+              return reject(error);
+            } else if (response.statusCode !== 200) {
+              return reject('Error unlinking accounts. Status: '+ response.statusCode + ' ' + JSON.stringify(body));
+            } else {
+              resolve(JSON.parse(body));
+            }
+          });
+        });
+      }
+    }
+
+    module.exports = new Auth0Client();
+    ```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
+
+* [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
diff --git a/fr-ca/articles/users/guides/update-metadata-properties-with-management-api.md b/fr-ca/articles/users/guides/update-metadata-properties-with-management-api.md
new file mode 100644
index 0000000000..766b76747c
--- /dev/null
+++ b/fr-ca/articles/users/guides/update-metadata-properties-with-management-api.md
@@ -0,0 +1,153 @@
+---
+description: Learn how to update user metadata with the Management API.
+crews: crew-2
+topics:
+  - metadata
+  - lock
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Update Metadata with the Management API
+
+You can update a user's metadata by making a `PATCH` call to the [Update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint.
+
+Assuming you created a user with the following metadata values:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+To update `user_metadata` and add the user's home address as a second-level property:
+
+```json
+{
+    "addresses": {
+        "home": "123 Main Street, Anytown, ST 12345"
+    }
+}
+```
+
+You would make the following `PATCH` call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"addresses\": {\"home\": \"123 Main Street, Anytown, ST 12345\"}}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+The user's profile will now appear as follows:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing",
+        "addresses": {
+            "home": "123 Main Street, Anytown, ST 12345"
+        }
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+::: warning
+When you send a `PATCH` call in which you have set a property's value to `null` (for example, `{user_metadata: {color: null}}`), Auth0 **deletes** the property/value from the database. Also, patching the metadata itself with an empty object removes the metadata completely (see [Deleting](#deleting)).
+:::
+
+## Merge properties
+
+Only properties at the root level are merged into the object. All lower-level properties will be replaced.
+
+For example, to add a user's work address as an additional inner property, you would have to include the complete contents of the `addresses` property. Since the `addresses` object is a root-level property, it will be merged into the final JSON object representing the user, but its sub-properties will not.
+
+```json
+{
+  "user_metadata": {
+    "addresses": {
+      "home": "123 Main Street, Anytown, ST 12345",
+      "work": "100 Industrial Way, Anytown, ST 12345"
+    }
+  }
+}
+```
+
+Therefore, the corresponding `PATCH` call to the API would be:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://YOURACCOUNT.auth0.com/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"addresses\": {\"home\": \"123 Main Street, Anytown, ST 12345\", \"work\": \"100 Industrial Way, Anytown, ST 12345\"}}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+## Delete properties
+
+Patching the metadata with an empty object removes the metadata completely. For example, sending this body removes everything in `app_metadata`:
+
+```json
+{
+  "app_metadata": {}
+}
+```
+
+Similarly, this clears out `user_metadata`:
+
+```json
+{
+  "user_metadata": {}
+}
+```
+
+## Keep reading
+
+* [Access Tokens for the Management API](/api/management/v2/concepts/tokens)
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
diff --git a/fr-ca/articles/users/guides/update-user-profiles-using-your-database.md b/fr-ca/articles/users/guides/update-user-profiles-using-your-database.md
new file mode 100644
index 0000000000..2bd4d91c41
--- /dev/null
+++ b/fr-ca/articles/users/guides/update-user-profiles-using-your-database.md
@@ -0,0 +1,70 @@
+---
+description: Learn how to update user profiles when using your own database as an identity provider.
+topics:
+    - updating-users
+    - user-management
+    - users
+    - custom-database
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Update User Profiles Using Your Database
+
+Update user profiles when using [your own database as an identity provider](/connections/database/custom-db) by doing the following tasks:
+
+* Use the [Management API](/api/management/v2#!/Users/patch_users_by_id).
+* Update the user in your database.
+* [Configure user migration](/users/guides/configure-automatic-migration) from your database to Auth0.
+
+## Update users with the Management API
+
+When using your own database for authentication, you can use the [Management API](/api/management/v2) to update the following fields:
+
+* `app_metadata`
+* `user_metadata`
+* `blocked`
+
+If you need to update other user fields, you will need to do it directly in your database.
+
+## Update users in your database
+
+You can update user profiles in your database as you normally do, and Auth0 will update its cached user profile the next time that user logs in.
+
+The user profile in the custom database can be implemented with any user profile structure, but you need to map it in the Login call to the Auth0 normalized user profile attributes as shown in the "Login" custom database template. 
+
+Access the custom database templates are accessed via
+*Connections* -> *Database* -> *Custom Database*. Be sure to turn on the "Use my own database" toggle to enable editing the scripts.
+
+See the [User profile cache](#user-profile-cache) section below for a brief overview of how Auth0 caches user profiles.
+
+## Update users through migration
+
+If you have [enabled user migration](/connections/database/migrating), and a user has already been migrated to the Auth0 database, then Auth0 will not query your database again for the user profile. Therefore, all changes made in the custom database for that user will never reflect in Auth0.
+
+Once a user has been migrated, you will also be able to update fields, such as `name`, `nickname`, `given_name`, `family_name`, `picture`, `email`, and `email_verified` via the Management API.
+
+However, rules for updating other user fields will still apply as described in the [Normalized User Profile](/users/normalized).
+
+## User profile cache
+
+Auth0 caches the user profile received from a [database connection](/connections/database) before sending it to the client application. This cache is stored in the Auth0 database and is refreshed each time the user authenticates.
+
+The cached values for the [Normalized User Profile](/users/normalized/auth0/normalized-user-profile-schema) fields are based on the values returned from the Login Script of your custom database connection.
+
+The User Profile is cached for several reasons. First, caching allows you the option of implementing [Single Sign-on (SSO)](/sso) at the Auth0 layer to avoid going to the Connection for every request. Additionally, this provides resilience if a Connection is temporarily unavailable.
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Manage Users Using the Management API](users/guides/manage-users-using-the-management-api)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Read Metadata](/users/guides/read-metadata)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
+* [View Users](/users/guides/view-users)
diff --git a/fr-ca/articles/users/guides/view-users.md b/fr-ca/articles/users/guides/view-users.md
new file mode 100644
index 0000000000..733afddc62
--- /dev/null
+++ b/fr-ca/articles/users/guides/view-users.md
@@ -0,0 +1,63 @@
+---
+description: How to view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+---
+# View Users
+
+The [Users](${manage_url}/#/users) page lists the users who are associated with your apps. To open a particular user, click the user profile picture or name in the "Name" column. The User Details page will open and display information for that user.
+
+The User Details page has links for five tabs:
+
+1. Details
+2. Devices
+3. History
+4. Locations
+5. Raw JSON
+
+## User Details: Details Tab
+
+The Details tab contains three sections that provide a high-level overview of the information in the user's profile:
+
+* **User Identity** provides at-a-glance details about the user, including their email address, associated Connections, and access rights.
+* **Metadata** displays the `app_metadata` and `user_metadata` information. You can edit these values.
+* **Identity Provider Attributes** displays the information retrieved from the authentication provider. Note that identity provider attributes are read-only.
+
+## User Details: Devices Tab
+
+The Devices tab lists the devices with which the user has requested authentication. Requesting authorization on a device links the device to the user's account.
+
+Login details for the user are associated with the Refresh Token assigned to that device. To revoke the Refresh Token, click **Unlink** next to the device.
+
+## User Details: History Tab
+
+The History tab displays a log of the user's account activity for the past 2 days.
+
+The logs include information about:
+
+* Events that have occurred
+* When the events occurred
+* The apps associated with the events
+* The identity provider used for authentication
+* The originating IP addresses for the events
+* Where the events originated
+
+## User Details: Locations Tab
+
+The Locations tab displays a map with pins indicating the user's location(s) when they logged in to the apps.
+
+## User Details: Raw JSON Tab
+
+The Raw JSON tab displays all of the information contained on the user's profile in JSON format so you can quickly view all of the available information about the user.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
+* [Update Users Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/fr-ca/articles/users/index.md b/fr-ca/articles/users/index.md
new file mode 100644
index 0000000000..2b8b93b77d
--- /dev/null
+++ b/fr-ca/articles/users/index.md
@@ -0,0 +1,30 @@
+---
+url: /users
+title: Manage Users
+description: Learn about working with users, user profiles, and user metadata in Auth0.
+classes: topic-page
+topics:
+  - users
+  - user-management
+contentType:
+  - index
+useCase:
+  - manage-users
+v2: true
+---
+# Manage Users
+
+Auth0's hosted cloud database stores a variety of information on your users that is accessible to you. This information is available to you via a *user profile*, and your users are grouped by tenant. The user information itself can come from a variety of sources, including identity providers, your own databases, and enterprise connections (Active Directory, SAML).
+
+<%= include('../_includes/_topic-links', { links: [
+  'users/concepts/overview-user-profile',
+  'users/concepts/overview-user-metadata',
+  'sessions',
+  'users/guides/manage-users-using-the-dashboard',
+  'users/guides/manage-users-using-the-management-api',
+  'users/guides/email-verified',
+  'extensions/account-link',
+  'security/blacklisting-attributes',
+  'users/concepts/overview-user-migration',
+  'users/search/v3'
+] }) %>
\ No newline at end of file
diff --git a/fr-ca/articles/users/normalized/auth0/identify-users.md b/fr-ca/articles/users/normalized/auth0/identify-users.md
new file mode 100644
index 0000000000..4fab34f775
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/identify-users.md
@@ -0,0 +1,42 @@
+---
+description: Learn how to uniquely identify users.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+# Identify Users
+
+There are two recommended options to uniquely identify your users:
+
+1. By the `user_id` property. This is guaranteed to be unique (within a tenant) per user (such as `{identity provider id}|{unique id in the provider}`, or `facebook|1234567890`). A user may have the same `user_id` property across multiple Auth0 tenants, but consistency is not guaranteed.
+2. By a *natural* key, like the `email` property. In this case, it is recommended that you enable email verification and only use this option with providers that require that users verify their emails.
+
+If you use [custom databases](/connections/database/mysql), you must return a unique `user_id` property. If you have multiple custom databases and expect possible collisions between ids from different connections, you should use a prefix identifying the connection. For example:
+
+```javascript
+function login (email, password, callback) {
+  var user = getUserFromDB(email);
+  var profile = {
+    user_id: 'MyConnection1|' + user.id,
+    email: user.email,
+    [...]
+  };
+  callback(null, profile);
+}
+```
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/fr-ca/articles/users/normalized/auth0/index.md b/fr-ca/articles/users/normalized/auth0/index.md
new file mode 100644
index 0000000000..5593c4d5da
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/index.md
@@ -0,0 +1,37 @@
+---
+description: Understand how Auth0 normalizes common user properties in the user profile.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - index
+  - concept
+useCase:
+  - manage-users
+v2: true
+---
+
+# Normalized User Profiles
+
+::: warning
+This version describes the user profile as normalized by Auth0. Use the dropdown to locate the user profile structure that conforms with the OIDC specification and includes only the standard claims.
+:::
+
+The Normalized User Profile is an Auth0-specific way of standardizing and storing user-related information. Because every [Identity Provider](/connections) (IdP) provides a different set of information about a user, Auth0 normalizes common profile properties into a protocol-agnostic representation of the user when storing user-related claims. For example, `family_name` in the normalized user profile contains details that may be returned to an IdP as `surname` or `last_name`.
+
+As such, the Auth0 claims included in the normalized user profile differ from the standard set of claims that can be returned in ID Tokens from the [Authentication API's `oauth/token` endpoint](/api/authentication#get-token) or in the response from the [/userinfo](/api/authentication#user-profile) endpoint (both of which follow the requirements detailed in the OIDC specification). 
+
+To learn about the attributes included in the Normalized User Profile and understand how you can work with them, visit [User Profile Structure](/users/references/user-profile-structure).
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Retrieve User Profiles](/users/search)
+* [Update User Profile Root Attributes](/users/normalized/auth0/update-root-attributes)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/fr-ca/articles/users/normalized/auth0/normalized-user-profile-schema.md b/fr-ca/articles/users/normalized/auth0/normalized-user-profile-schema.md
new file mode 100644
index 0000000000..63c43e0532
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/normalized-user-profile-schema.md
@@ -0,0 +1,67 @@
+---
+description: Normalized User Profile schema reference. 
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - reference
+useCase:
+  - manage-users
+v2: true
+---
+# Normalized User Profile Schema
+
+The attributes that Auth0 maps to a common schema are listed below.
+
+Fields that are always generated:
+
+* **`name`**: the user's full name.
+* **`nickname`**: the user's username if available, else the local-part of the user's email.
+* **`picture`**: the URL of the [user's picture](/users/guides/change-user-pictures). If unavailable, Auth0 uses the Gravatar image associated with the user's email address.
+* **`user_id`**: the user's unique identifier. This is unique per Connection, but the same for all apps that authenticate via that Connection.
+
+By default, a user's `name`, `nickname`, and `picture` attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable since they are updated from the identity provider each time a user logs in. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+
+Fields that are generated when the details are available:
+
+* **`email`**: the user's email address.
+* **`email_verified`**: a boolean indicating if the user's email address has been verified.
+* **`given_name`**: the user's first name.
+* **`family_name`**: the user's last name.
+
+::: note
+When creating a user with the [create a User Management API endpoint](/api/management/v2#!/Users/post_users) you can submit the `given_name` and `family_name`. By default, a user's `given_name` and `family_name` attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable since they are updated from the identity provider each time a user logs in. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API
+:::
+
+::: panel Custom Databases
+If you are writing a login script for a [custom database](/connections/database/mysql) you are responsible for returning the information in the user profile. A unique and immutable `user_id` property is mandatory to correctly identify the user (see [Uniquely Identify Users](/users/normalized/auth0/identify-users)).
+:::
+
+## Additional Attributes
+
+The User Profile includes an array of identities. In the most common case (logging in with a single provider), the array contains only one element. If the user has multiple accounts linked, the array will have an element for each associated account. See [User Account Linking](/users/concepts/overview-user-account-linking) for more information. 
+:::
+
+The `identities` array contains the following attributes:
+
+* `connection`: the name of the connection.
+* `isSocial`: indicates if the provider is a Social provider.
+* `provider`: the provider of the connection.
+* `user_id`: the unique identifier of the user for this connection.
+
+::: note
+Auth0 will pass to your app all other properties supplied by the identity provider, even if those that are not mapped to the standard attributes listed above.
+:::
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Update User Profile Root Attributes](/users/normalized/auth0/update-root-attributes)
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/fr-ca/articles/users/normalized/auth0/sample-user-profiles.md b/fr-ca/articles/users/normalized/auth0/sample-user-profiles.md
new file mode 100644
index 0000000000..1a12d81ad6
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/sample-user-profiles.md
@@ -0,0 +1,132 @@
+---
+description: Examples of user profiles.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - reference
+useCase:
+  - manage-users
+v2: true
+---
+# Sample User Profiles
+
+## Google User Profile
+
+This is a sample user profile from a user that logged in through **Google**:
+
+```json
+{
+  "email": "johnfoo@gmail.com",
+  "email_verified": true,
+  "family_name": "Foo",
+  "gender": "male",
+  "given_name": "John",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "103547991597142817347",
+      "connection": "google-oauth2",
+      "isSocial": true
+    }
+  ],
+  "locale": "en",
+  "name": "John Foo",
+  "nickname": "FooJon",
+  "picture": "https://lh4.googleusercontent.com/-OdsbOXom9qE/AAAAAAAAAAI/AAAAAAAAADU/_j8SzYTOJ4I/photo.jpg",
+  "user_id": "google-oauth2|103547991597142817347"
+}
+```
+
+## Microsoft Account User Profile
+
+This is a sample profile from **Microsoft Account**:
+
+```json
+{
+  "email": "bobdoe@outlook.com",
+  "email_verified": true,
+  "emails": [
+    "bobdoe@outlook.com",
+    "bobdoe@outlook.com"
+  ],
+  "family_name": "Doe",
+  "given_name": "Bob",
+  "identities": [
+    {
+      "provider": "windowslive",
+      "user_id": "4cf0a30169d55031",
+      "connection": "windowslive",
+      "isSocial": true
+    }
+  ],
+  "locale": "en_US",
+  "name": "Bob Doe",
+  "nickname": "doebob@outlook.com",
+  "picture": "https://secure.gravatar.com/avatar/c89b2bb92df91508e14172097a5e17da?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "user_id": "windowslive|4cf0a30169d55031"
+}
+```
+
+## Office 365 User Profile
+
+This is a sample profile from **Office 365 (Microsoft Azure Active Directory)**:
+
+```json
+{
+  "email": "jeff@foo.onmicrosoft.com",
+  "family_name": "Jeff",
+  "given_name": "Beth",
+  "identities": [
+    {
+      "user_id": "10030000838D23AF@MicrosoftOnline.com",
+      "provider": "office365",
+      "connection": "foo-onmicrosoft",
+      "isSocial": false
+    }
+  ],
+  "name": "Jeff Beth",
+  "nickname": "jeff@auth0.onmicrosoft.com",
+  "picture": "https://secure.gravatar.com/avatar/a7f86ddd090d5a4cb833b97baab2aca1?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "tenantid": "75696069-df44-4310-9bcf-08b45e3007c9",
+  "upn": "jeff@foo.onmicrosoft.com",
+  "user_id": "office365|10030000838D23AF@MicrosoftOnline.com"
+}
+```
+
+## ADFS User Profile
+
+This is a sample profile from **ADFS (Active Directory Federation Services)**:
+
+```json
+{
+  "email": "john@fabrikam.com",
+  "family_name": "Fabrikam",
+  "email_verified": false,
+  "given_name": "John",
+  "identities": [
+    {
+      "user_id": "john@fabrikam.com",
+      "provider": "adfs",
+      "connection": "auth10.com",
+      "isSocial": false
+    }
+  ],
+  "issuer": "https://adfs.fabrikam.com",
+  "name": "John Fabrikam",
+  "nickname": "john",
+  "picture": "https://secure.gravatar.com/avatar/5426f6b9d63ad92d60e6fe9fdf83aa21?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "user_id": "adfs|john@fabrikam.com"
+}
+```
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/fr-ca/articles/users/normalized/auth0/store-user-data.md b/fr-ca/articles/users/normalized/auth0/store-user-data.md
new file mode 100644
index 0000000000..d6bc8a02b9
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/store-user-data.md
@@ -0,0 +1,29 @@
+---
+description: Learn how to store user data in tables.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+# Store User Data
+
+When outsourcing user authentication, there is usually no need to maintain your own users/passwords table. Even so, you may still want to associate application data to authenticated users.
+
+For example, you could have a *Users table* that lists each user authenticated by Auth0. Every time a users logs in, you could search the table for that user. If the user does not exist, you would create a new record. If they do exist, you would update all fields, essentially keeping a local copy of all user data.
+
+Alternatively, you could store the user identifier in each table/collection that has user-associated data. This is a simpler implementation suited to smaller applications.
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Retrieve User Profiles](/users/search)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/fr-ca/articles/users/normalized/auth0/update-root-attributes.md b/fr-ca/articles/users/normalized/auth0/update-root-attributes.md
new file mode 100644
index 0000000000..222a954535
--- /dev/null
+++ b/fr-ca/articles/users/normalized/auth0/update-root-attributes.md
@@ -0,0 +1,54 @@
+---
+title: Updating User Profile Root Attributes
+description: Learn about root attributes available for the Auth0 normalized user profile and methods of updating them.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Updating User Profile Root Attributes
+
+Auth0's normalized user profile contains a number of root attributes (attributes stored at the first, or root, level of the object), some of which may be updated. [Learn more about the user profile structure and its attributes.](/users/references/user-profile-structure) 
+
+Methods for updating root attributes vary depending on connection type.
+
+## Auth0 as the Identity Provider
+
+When Auth0 is the Identity Provider (IdP), subscribers may: 
+
+* Set root attributes [on user sign-up](/api/management/guides/users/set-root-attributes-user-signup) (via the Management API or via public signup)
+or [on import](/api/management/guides/users/set-root-attributes-user-import)
+* [Update root attributes individually](/api/management/guides/users/update-root-attributes-users) via the Management API
+
+Auth0 is the IdP for the following connection types:
+
+* [regular database connections](/connections/database)
+* [custom database connections](/connections/database/custom-db) with import mode
+* [passwordless connections](/connections/passwordless)
+
+## Upstream Identity Providers
+
+When an upstream IdP (like Google or Facebook) is used, subscribers have two options:
+
+* The upstream IdP sets the root attributes when users are first created and then
+automatically updates them with each subsequent login. This is the default behavior.
+* The upstream IdP sets the root attributes on user creation only and does not
+update them on subsequent logins, thereby allowing subscribers to [update root attributes individually](/api/management/guides/users/update-root-attributes-users) via the Management API. To enable this, you will need to [configure your connection sync with Auth0](/api/management/guides/connections/configure-connection-sync).
+
+Upstream Identity Providers handle the following connection types:
+
+* [social connections](/connections#social)
+* [enterprise connections](/connections#enterprise)
+* [legal identity connections](/connections#legal-identities)
+
+## Keep reading
+
+* [Set Root Attributes During User Sign-Up](/api/management/guides/users/set-root-attributes-user-signup)
+* [Set Root Attributes During User Import](/api/management/guides/users/set-root-attributes-user-import)
+* [Update Root Attributes](/api/management/guides/users/update-root-attributes-users)
+* [Configure Connection Sync with Auth0](/api/management/guides/connections/configure-connection-sync)
\ No newline at end of file
diff --git a/fr-ca/articles/users/normalized/index.yml b/fr-ca/articles/users/normalized/index.yml
new file mode 100644
index 0000000000..b833aeb219
--- /dev/null
+++ b/fr-ca/articles/users/normalized/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: users/normalized
+  current: auth0
+  versions:
+    - auth0
+    - oidc
+  defaultArticles:
+    auth0: index
+    oidc: index
\ No newline at end of file
diff --git a/fr-ca/articles/users/normalized/oidc/index.md b/fr-ca/articles/users/normalized/oidc/index.md
new file mode 100644
index 0000000000..d63f0591db
--- /dev/null
+++ b/fr-ca/articles/users/normalized/oidc/index.md
@@ -0,0 +1,97 @@
+---
+description: Claims for a user profile returned via an OIDC-Compliant authorization flow
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - oidc-user-profiles
+contentType:
+  - index
+  - concept
+  - reference
+useCase:
+  - manage-users
+---
+# User Profiles Returned from OIDC-Compliant Pipelines
+
+::: version-warning
+This article describes the user profile that includes only the [OpenID Connect (OIDC) standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Use the toggle for information on the Auth0 normalized profile, which might contain information from many identity providers.
+:::
+
+When you're using an OIDC-conformant authentication flow, the user profile you receive in return may differ slightly from the [Auth0 Normalized User Profile](/users/normalized/auth0).
+
+The following is a [non-normative example of such a response](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims):
+
+```json
+  {
+   "sub": "248289761001",
+   "name": "Jane Doe",
+   "given_name": "Jane",
+   "family_name": "Doe",
+   "middle_name": "",
+   "nickname": "",
+   "preferred_username": "j.doe",
+   "profile": "",
+   "picture": "http://example.com/janedoe/me.jpg",
+   "website": "http://example.com",
+   "email": "janedoe@example.com",
+   "email_verified": true,
+   "gender": "female",
+   "birthdate": "",
+   "zoneinfo": "",
+   "locale": "",
+   "phone_number": "",
+   "phone_number_verified": false,
+   "address": {
+      "street_address": "",
+      "locality": "",
+      "region": "",
+      "postal_code": "",
+      "country": ""
+   },
+   "updated_at": "",
+  }
+```
+
+## Retrieve User Profiles using ID Tokens
+
+You can retrieve the user profile by retrieving an ID Token using the Authentication API's [`oauth/token` endpoint](/api/authentication#get-token) or the [`/userinfo` endpoint](/api/authentication#get-user-info). Auth0's [Lock](https://auth0.com/docs/libraries#lock-login-signup-widgets) widget and the [Auth0 client-side SDKs](/libraries#auth0-client-side-sdks) also return the OIDC-compliant user profile.
+
+Additionally, the User Profile section of our [Quickstarts](/quickstarts) return user profiles compliant with the OIDC specification. Some of our more popular Quickstarts are:
+
+- [ASP.NET Core](/quickstart/webapp/aspnet-core/04-user-profile)
+- [Android](/quickstart/native/android/04-user-profile)
+- [Angular 2](/quickstart/spa/angular2/03-user-profile)
+- [Node.js](/quickstart/webapp/nodejs)
+- [React](/quickstart/spa/react/02-user-profile)
+
+## Claims
+
+| Parameter | Definition |
+| --------- | ---------- |
+| `sub` | unique identifier for the user |
+| `name` | name of the user |
+| `given_name` | the first/given name of the user |
+| `family_name` | the surname/last name of the user |
+| `middle_name` | the middle name of the user |
+| `nickname` | casual name of the user that may/may not be the same as the `given_name` |
+| `preferred_username` | identifier by which the user wishes to be referred to |
+| `profile` | URL of the user's profile page |
+| `picture` | URL of the user's profile picture |
+| `website` | URL of the user's website/blog |
+| `email` | preferred email address of the user |
+| `email_verified` 
    Boolean | `true` if user's email address is verified; else, `false` |
+| `gender` | gender of the user |
+| `birthdate` | birthday of the user |
+| `zoneinfo` | time zone in which the user is located |
+| `locale` | two-part code representing the end user's language and location (e.g., `fr-CA` for a user located in Canada and working in French) |
+| `phone_number` | preferred telephone number for the user |
+| `phone_number_verified` 
    Boolean | `true` if user's phone number is verified; else, `false` |
+| `address` 
    JSON Object | preferred postal address of the user |
+| `updated_at` 
    Number | time when the user's profile was last updated |
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [OIDC Conformant Authentication Adoption Guide](/api-auth/tutorials/adoption)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/fr-ca/articles/users/references/bulk-import-database-schema-examples.md b/fr-ca/articles/users/references/bulk-import-database-schema-examples.md
new file mode 100644
index 0000000000..241bef14dc
--- /dev/null
+++ b/fr-ca/articles/users/references/bulk-import-database-schema-examples.md
@@ -0,0 +1,612 @@
+---
+title: Bulk User Import Database Schema and Examples
+description: How to perform bulk user imports with the Management API.
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - bulk-imports
+contentType:
+  - reference
+useCase:
+  - manage-users
+  - migrate
+---
+# Bulk User Import Database Schema and Examples
+
+The users file must have an array with the users' information in JSON format.
+
+## User JSON schema
+
+The following [JSON schema](http://json-schema.org) describes valid users:
+
+```json
+{
+    "type": "object",
+    "properties": {
+        "email": {
+            "type": "string",
+            "description": "The user's email address.",
+            "format": "email"
+        },
+        "email_verified": {
+            "type": "boolean",
+            "default": false,
+            "description": "Indicates whether the user has verified their email address."
+        },
+        "user_id": {
+            "type": "string",
+            "description": "The user's unique identifier. This will be prepended by the connection strategy."
+        },
+        "username": {
+            "type": "string",
+            "description": "The user's username."
+        },
+        "given_name": {
+            "type": "string",
+            "description": "The user's given name."
+        },
+        "family_name": {
+            "type": "string",
+            "description": "The user's family name."
+        },
+        "name": {
+            "type": "string",
+            "description": "The user's full name."
+        },
+        "nickname": {
+            "type": "string",
+            "description": "The user's nickname."
+        },
+        "picture": {
+          "type": "string",
+          "description": "URL pointing to the user's profile picture."
+        },
+        "blocked": {
+            "type": "boolean",
+            "description": "Indicates whether the user has been blocked."
+        },
+        "password_hash": {
+            "type": "string",
+            "description":"Hashed password for the user. Passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds."
+        },
+        "custom_password_hash": {
+            "type": "object",
+            "description": "A more generic way to provide the users password hash. This can be used in lieu of the password_hash field when the users password hash was created with an alternate algorithm. Note that this field and password_hash are mutually exclusive.",
+            "properties": {
+                "algorithm": {
+                    "type": "string",
+                    "enum": ["argon2", "bcrypt", "hmac", "ldap", "md4", "md5", "sha1", "sha256", "sha512", "pbkdf2"],
+                    "description": "The algorithm that was used to hash the password."
+                },
+                "hash": {
+                    "type": "object",
+                    "properties": {
+                        "value": {
+                            "type": "string",
+                            "description": "The password hash."
+                        },
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["base64", "hex", "utf8"],
+                            "description": "The encoding of the provided hash. Note that both upper and lower case hex variants are supported, as well as url-encoded base64."
+                        },
+                        "digest": {
+                            "type": "string",
+                            "description": "The algorithm that was used to generate the HMAC hash",
+                            "enum": ["md4", "md5", "ripemd160", "sha1", "sha224", "sha256", "sha384", "sha512", "whirlpool"]
+                        },
+                        "key": {
+                            "type": "object",
+                            "description": "The key that was used to generate the HMAC hash",
+                            "required": ["value"],
+                            "properties": {
+                                "value": {
+                                    "type": "string",
+                                    "description": "The key value"
+                                },
+                                "encoding": {
+                                    "type": "string",
+                                    "enum": ["base64", "hex", "utf8"],
+                                    "default": "utf8",
+                                    "description": "The key encoding"
+                                }
+                            }
+                        }
+                    }
+                },
+                "salt": {
+                    "type": "object",
+                    "properties": {
+                        "value": {
+                            "type": "string",
+                            "description": "The salt value used to generate the hash."
+                        },
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["base64", "hex", "utf8"],
+                            "default": "utf8",
+                            "description": "The encoding of the provided salt. Note that both upper and lower case hex variants are supported, as well as url-encoded base64."
+                        },
+                        "position": {
+                            "type": "string",
+                            "enum": ["prefix", "suffix"],
+                            "description": "The position of the salt when the hash was calculated. For example; MD5('salt' + 'password') = '67A1E09BB1F83F5007DC119C14D663AA' would have \"position\":\"prefix\"."
+                        }
+                    },
+                    "required": ["value", "position"]
+                },
+                "password": {
+                    "type": "object",
+                    "properties": {
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["ascii", "utf8", "utf16le", "ucs2", "latin1", "binary"],
+                            "default": "utf8",
+                            "description": "The encoding of the password used to generate the hash. On login, the user-provided password will be transcoded from utf8 before being checked against the provided hash. For example; if your hash was generated from a ucs2 encoded string, then you would supply \"encoding\":\"ucs2\"."
+                        }
+                    }
+                }
+            },
+            "required": ["algorithm", "hash"],
+            "additionalProperties": false
+        },
+        "app_metadata": {
+            "type": "object",
+            "description": "Data related to the user that does affect the application's core functionality."
+        },
+        "user_metadata": {
+            "type": "object",
+            "description": "Data related to the user that does not affect the application's core functionality."
+        },
+        "mfa_factors": {
+            "type": "array",
+            "items": {
+                "type": "object",
+                "properties": {
+                    "totp": {
+                        "type": "object",
+                        "properties": {
+                        "secret": {
+                            "type": "string",
+                                "pattern": "^[A-Z2-7]+$",
+                                "description": "The OTP secret is used with authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass). It must be supplied in un-padded Base32 encoding, such as: JBTWY3DPEHPK3PNP"
+                            },
+                        },
+                        "additionalProperties": false,
+                        "required": ["secret"],
+                    },
+                    "phone": {
+                        "type": "object",
+                        "properties": {
+                        "value": {
+                            "type": "string",
+                            "pattern": "^\\+[0-9]{1,15}$",
+                            "description": "The phone number for SMS or Voice MFA. The phone number should include a country code and begin with +, such as: +12125550001"
+                        },
+                        },
+                        "additionalProperties": false,
+                        "required": ["value"],
+                    },
+                    "email": {
+                        "type": "object",
+                        "properties": {
+                            "value": {
+                                "type": "string",
+                                "format": "email",
+                                "description": "The email address for MFA"
+                            },
+                        },
+                        "additionalProperties": false,
+                        "required": ["value"],
+                    },
+                },
+                "maxProperties": 1,
+                "additionalProperties": false,
+            },
+            "minItems": 1,
+            "maxItems": 10
+        }
+    },
+    "required": ["email"],
+    "additionalProperties": false
+}
+```
+
+## Properties
+
+You can import users with the following properties:
+
+| Property | Type | Description | Upsert During Import? |
+|----------|------|-------------|-----------------------|
+| `app_metadata` | object | Data that can affect the application's core functionality or what the user can access. Data stored in `app_metadata` cannot be edited by users. This may include things such as support plans, roles or access groups. | Yes |
+| `blocked` | boolean | Indicates whether the user has been blocked. | No |
+| `email` | string | The user's email address. | No |
+| `email_verified` | boolean | Indicates whether the user has verified their email address. | Yes |
+| `family_name` | string | The user's family name. | Yes |
+| `given_name` | string | The user's given name. | Yes |
+| `name` | string | The user's full name. | Yes |
+| `nickname` | string | The user's nickname. | Yes |
+| `picture` | string | URL pointing to the user's profile picture. | Yes |
+| `user_id` | string | The user's unique identifier. This will be prepended by the connection strategy. | No |
+| `user_metadata` | object | Data that does not impact what users can or cannot access, such as work address, home address, or user preferences. | Yes |
+| `username` | string | The user's username. | No |
+| `password_hash` | string | Hashed password for the user's connection. When users are created, Auth0 uses `bcrypt` to secure the password. Importing hashed passwords lets users keep their passwords for a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds. This property can only be provided when the user is first imported and cannot be updated later. | No |
+| `custom_password_hash` | object | A more generic way to provide the user's password hash. This can be used instead of the `password_hash` field when the user's password hash was created with an alternate algorithm. This property can only be provided when the user is first imported and cannot be updated later. | Yes |
+| `password_set_date` | datetime | Timestamp indicating when the password for the user's connection was set. At user creation, this field exists, and `last_password_reset` does not. If the user has reset their password, this field and `last_password_reset` are identical. | No |
+| `mfa_factors` | array | The MFA factors that can be used to authenticate this user | Yes |
+
+For more information on `app_metadata` and `user_metadata`, check out the [Metadata Overview](/users/concepts/overview-user-metadata).
+
+## App metadata
+
+The `user.app_metadata` object must **not** contain any of these properties:
+
+* `__tenant`
+* `_id`
+* `blocked`
+* `clientID`
+* `created_at`
+* `email_verified`
+* `email`
+* `globalClientID`
+* `global_client_id`
+* `identities`
+* `lastIP`
+* `lastLogin`
+* `loginsCount`
+* `metadata`
+* `multifactor_last_modified`
+* `multifactor`
+* `updated_at`
+* `user_id`
+
+## Custom password hash
+
+The `user.custom_password_hash` object can be used instead of the `user.password_hash` property when the user's password hash was created with an alternate algorithm. Note this field and `password_hash` are mutually exclusive.
+
+The `user.custom_password_hash` object has the following properties:
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `algorithm` | string | The algorithm used to hash the password. Must be one of: 
    • `argon2`
    • `bcrypt`
    • `hmac`
    • `ldap`
    • `md4`
    • `md5`
    • `sha1`
    • `sha256`
    • `sha512`
    • `pbkdf2`
     |
+| `hash` | object |   |
+| `hash.value` | string | The password hash. |
+| `hash.encoding` | string | The encoding of the provided hash. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
    Upper and lower case hex variants are supported, as well as url-encoded base64. |
+| `hash.digest` | string | The algorithm used to generate the HMAC hash. Must be one of: 
    • `md4`
    • `md5`
    • `ripemd160`
    • `sha1`
    • `sha224`
    • `sha256`
    • `sha384`
    • `sha512`
    • `whirlpool`
     |
+| `hash.key` | object | The key used to generate the HMAC hash. |
+| `hash.key.value` | string | The key value. |
+| `hash.key.encoding` | string | The key encoding. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
    By default, `hash.key.encoding` is `utf8`. |
+| `hash.salt` | object |   |
+| `hash.salt.value` | string | The salt value used to generate the hash. |
+| `hash.salt.encoding` | string | The encoding of the provided salt. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
     Upper and lower case hex variants are supported, as well as url-encoded base64. By default, `hash.salt.encoding` is `utf8`. |
+| `hash.salt.position` | string | The position of the salt when the hash was calculated. |
+| `password.encoding` | string | <%= include('../_includes/_password-encoding-description.md') %> |
+
+### Supported hash algorithms
+
+Auth0 currently supports imports of user passwords hashed by:
+
+* [Argon2](https://github.com/p-h-c/phc-winner-argon2)
+* [bcrypt](https://www.npmjs.com/package/bcrypt)
+* [LDAP](https://tools.ietf.org/html/rfc2307#section-5.3) (`RFC-2307 "userPassword"`)
+* [HMAC](https://tools.ietf.org/html/rfc2104)
+* [MD4](https://tools.ietf.org/html/rfc1320)
+* [MD5](https://tools.ietf.org/html/rfc1321)
+* [SHA1](https://tools.ietf.org/html/rfc3174)
+* [SHA256 and SHA512](https://tools.ietf.org/html/rfc4634)
+* [PBKDF2](https://tools.ietf.org/html/rfc2898#section-5.2)
+
+Please consider the following sections when providing a `custom_password_hash`.
+
+#### Argon2
+
+When the `algorithm` is set to `argon2`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` should be in [PHC string format](https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md) and conform to [these requirements](https://github.com/auth0/magic#magicpasswordhash--magicverifypassword).
+- `hash.value` must include the base64 encoded salt (as specified in the `PHC` documentation).
+
+#### bcrypt
+
+When the `algorithm` is set to `bcrypt`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` must be prefixed with either `$2a$` or `$2b$`. Other prefixes such as `$2$`, `$sha1$`, `$2x$`, etc. are not supported at this time. For instance, `$2b$10$nFguVi9LsCAcvTZFKQlRKeLVydo8ETv483lkNsSFI/Wl1Rz1Ypo1K` was generated from the string `hello` using with a cost parameter of 10.
+
+#### HMAC
+
+When the `algorithm` is set to `hmac`:
+
+- `hash.encoding` must be either `hex` or `base64`.
+- `hash.digest` is required and must be one of these:
+  - `md4`
+  - `md5`
+  - `ripemd160`
+  - `sha1`
+  - `sha224`
+  - `sha256`
+  - `sha384`
+  - `sha512`
+  - `whirlpool`
+- `hash.key.value` is required.
+- `hash.key.encoding` must be either `base64` or `hex` or `utf8`.
+
+#### LDAP
+
+When the `algorithm` is set to `ldap`:
+
+- `hash.encoding` must be `utf8`.
+- `salt` is not allowed.
+- `hash.value` must adhere to the format outlined in [RFC-2307 section-5.3](https://tools.ietf.org/html/rfc2307#section-5.3).
+- The scheme should be one of `md5|smd5|sha*|ssha*` see [here](https://www.openldap.org/faq/data/cache/347.html) for more info.
+- Note that the [crypt](https://www.openldap.org/faq/data/cache/344.html) scheme is **not supported** due to system/implementation dependent behavior. For more information, check out [Open LDAP Admin Guide - 14.4.2. CRYPT password storage scheme](https://www.openldap.org/doc/admin24/guide.html#CRYPT%20password%20storage%20scheme).
+
+#### MD* or SHA*
+
+When the `algorithm` is set to `md4`, `md5`, `sha1`, `sha256`, or `sha512`:
+
+- `hash.encoding` must be either `hex` or `base64`.
+
+#### PBKDF2
+
+When the `algorithm` is set to `pbkdf2`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` should be in [PHC string format](https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md).
+- `hash.value` must include the B64 encoded salt (base64 omitting padding characters `=`, as specified in the `PHC` documentation).
+- `hash.value` should include `i` (iterations) and `l` (keylen) parameters. If these parameters are omitted, they will default to `i=100000` and `l=64`.
+- The `id` should be in a `pbkdf2-` format (`pbkdf2-sha512`, `pbkdf2-md5`, etc). The supported digests are:
+    - `RSA-MD4`
+    - `RSA-MD5`
+    - `RSA-MDC2`
+    - `RSA-RIPEMD160`
+    - `RSA-SHA1`
+    - `RSA-SHA1-2`
+    - `RSA-SHA224`
+    - `RSA-SHA256`
+    - `RSA-SHA384`
+    - `RSA-SHA512`
+    - `md4`
+    - `md4WithRSAEncryption`
+    - `md5`
+    - `md5WithRSAEncryption`
+    - `mdc2`
+    - `mdc2WithRSA`
+    - `ripemd`
+    - `ripemd160`
+    - `ripemd160WithRSA`
+    - `rmd160`
+    - `sha1`
+    - `sha1WithRSAEncryption`
+    - `sha224`
+    - `sha224WithRSAEncryption`
+    - `sha256`
+    - `sha256WithRSAEncryption`
+    - `sha384`
+    - `sha384WithRSAEncryption`
+    - `sha512`
+    - `sha512WithRSAEncryption`
+    - `ssl3-md5`
+    - `ssl3-sha1`
+    - `whirlpool`
+
+### MFA factors
+
+The `user.mfa_factors` array contains [MFA enrollments](/mfa) for the user. Importing enrollments prevents the need for users to re-enroll in MFA after they're imported. The supported enrollment types are:
+
+| Property | Type | Description |
+|---------|------|-------------|
+| `email` | object |   |
+| `email.value` | string | The email address for MFA. |
+| `phone` | object |   |
+| `phone.value` | string | The phone number for SMS or Voice MFA. Must have a country code and begin with `+`, such as: `"+12125550001"` |
+| `totp` | object |   |
+| `totp.secret` | string | The OTP secret for MFA authentication with authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass). Must be in un-padded Base32 encoding, for example: `"JBTWY3DPEHPK3PNP"` |
+
+## Examples
+
+### Basic
+
+A file with the following contents is valid:
+
+```json
+[
+  {
+    "email": "john.doe@contoso.com",
+    "email_verified": false,
+    "app_metadata": {
+        "roles": ["admin"],
+        "plan": "premium"
+    },
+    "user_metadata": {
+        "theme": "light"
+    }
+  }
+]
+```
+
+### Custom Password Hash
+
+Some example users with hashes provided:
+
+```json
+[
+    {
+        "email": "antoinette@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "md4",
+            "hash": {
+                "value": "AbuUujgF0pPPkJPSFRTpmA==",
+                "encoding": "base64"
+            }
+        }
+    },
+    {
+        "email": "mary@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "sha256",
+            "hash": {
+                "value": "d24e794fce503c3ddb1cd1ba1dd5d9b250cf9917336a0316fefd87fecf79200f",
+                "encoding": "hex"
+            },
+            "salt": {
+                "value": "abc123",
+                "position": "prefix"
+            }
+        }
+    },
+    {
+        "email": "velma@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "bcrypt",
+            "hash": {
+                "value": "$2b$10$C9hB01.YxRSTcn/ZOOo4j.TW7xCKKFKBSF.C7E0xiUwumqIDqWUXG"
+            }
+        }
+    },
+    {
+        "email": "edward@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "argon2",
+            "hash": {
+                "value": "$argon2id$v=19$m=65536,t=2,p=1$J6Q/82PCyaNpYKRELJyTZg$m04qUAB8rexWDR4+/0f+SFB+4XMFxt7YAvAq2UycYos"
+            }
+        }
+    },
+    {
+        "email": "terrell@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "pbkdf2",
+            "hash": {
+                "value": "$pbkdf2-md4$i=100000,l=64$+N375B8q0Fw$fp2R9KAM4hK/votGHC5Fu+jhqbxUD8+Nic/EMSGvNC3UP/k7wSHI0uXluHRSkZfl/BOheYqNOemayG90ZaSSQw",
+                "encoding": "utf8"
+            }
+        }
+    },
+    {
+        "email": "cecil@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "pbkdf2",
+            "hash": {
+                "value": "$pbkdf2-sha512$i=100000,l=64$KNyFsA2rWoE$I2CQGI9H0JxdDf3kERRI97kPCGxh0KWBIV3MxyaS191gDGfzVBGyS4BibhgqWQ0/ails8mHuU9ckASxHOOq58w"
+            }
+        }
+    },
+    {
+        "email": "sean@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "ldap",
+            "hash": {
+                "value": "{SSHA384}/cgEjdoZh85DhurDeOQEMO1rMlAur93SVPbYe5XSD4lF7nNuvrBju5hUeg9A6agRemgSXGl5YuE=",
+                "encoding": "utf8"
+            }
+        }
+    },
+    {
+        "email": "peter@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "hmac",
+            "hash": {
+                "value": "cg7f42jH39/2EaAU4wNd4s2lKIk=",
+                "encoding": "base64",
+                "digest": "sha1",
+                "key": {
+                    "value": "736868",
+                    "encoding": "hex"
+                }
+            }
+        }
+    }
+]
+```
+
+### MFA Factors
+
+As you might expect, the `user.mfa_factors` array allows you to provide the user's [MFA enrollments](/mfa). The supported enrollment types are:
+
+* Phone: Used for sms or voice-based verification.
+* TOTP: OTP secret for use with MFA type apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass).
+* Email: Used for email-based verification.
+
+Some examples of users with MFA factors:
+
+```json
+[
+    {
+        "email": "antoinette@contoso.com",
+        "mfa_factors": [
+            {
+                "totp": {
+                    "secret": "2PRXZWZAYYDAWCD"
+                }
+            },
+            {
+                "phone": {
+                    "value": "+15551112233"
+                }
+            },
+            {
+                "email": {
+                    "value": "antoinette@antoinette.biz"
+                }
+            }
+        ]
+    },
+    {
+        "email": "mary@contoso.com",
+        "mfa_factors": [
+            {
+                "totp": {
+                    "secret": "JTF18P5973P1KCZN"
+                }
+            }
+        ]
+    },
+    {
+        "email": "velma@contoso.com",
+        "mfa_factors": [
+            {
+                "phone": {
+                    "value": "+15551234567"
+                }
+            },
+        ]
+    },
+    {
+        "email": "edward@contoso.com",
+        "mfa_factors": [
+            {
+                "email": {
+                    "value": "edward@edward.biz"
+                }
+            }
+        ]
+    }
+]
+```
+
+::: note
+The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
+:::
+
+## Keep reading
+
+* [User Migration Overview](/users/concepts/overview-user-migration)
+* [Configure Automatic Migration](/users/guides/configure-automatic-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
+
diff --git a/fr-ca/articles/users/references/link-accounts-client-side-scenario.md b/fr-ca/articles/users/references/link-accounts-client-side-scenario.md
new file mode 100644
index 0000000000..82b00b0e95
--- /dev/null
+++ b/fr-ca/articles/users/references/link-accounts-client-side-scenario.md
@@ -0,0 +1,82 @@
+---
+title: User Initiated Account Linking - Client-Side Implementation
+description: Learn how to provide a client-side UI that allows users to authenticate to their other accounts and link these to their primary account using a SPA.
+crews: crew-2
+topics:
+  - account-linking
+  - client-side
+contentType:
+  - reference
+useCase:
+  - manage-accounts
+---
+
+# User Initiated Account Linking - Client-Side Implementation
+
+Auth0 supports the linking of user accounts from various identity providers. One way to implement this functionality is to enable the user to explicitly link accounts. In this scenario, the user authenticates through the UI of your Single Page Application (SPA) and can later use a link or button to link another account to the first one. When the user clicks on this link/button, your application makes a call so that when the user logs in with the second provider, the second account is linked with the first.
+
+When you initiate account linking, you can select which identity to use as the primary account and which to use as the secondary. This choice depends on which set of attributes you want to retain in the primary profile, as you will only retain the attributes from the primary account.
+
+You can find the full source of this sample application [on GitHub](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/SPA).
+
+1. Log the user in to your application. 
+
+    The user authenticates to your SPA using using [Universal Login](/universal-login), requesting an [Access Token for the Management API](/api/management/v2/get-access-tokens-for-spas).
+
+    In the typical SPA login, the callback is handled client-side by the same page, and a JWT is received after successful authentication. For details, see the [Single-Page App Quickstarts](/quickstart/spa).
+
+2. The user initiates account linking. Your SPA must provide a UI for the user to initiate a link to their other accounts. For example, your SPA could contain a user's settings page:
+
+    ![SPA User Settings Example](/media/articles/link-accounts/account-linking-spa.png)
+
+    When the user clicks on the **Link Account** button, your app redirects the user to the Universal Login page, when they log in with the connection they want to link to. After successful authentication, use the obtained token to link the accounts.
+
+    You could also add a button for each connection (e.g. 'Link Facebook Account', 'Link Google Account') and redirect the user to `/authorize` with the `connection` parameter set (e.g. `/authorize?connection=facebook`).
+
+3. Link accounts by calling the Auth0 Management API's [Link a User Account endpoint](/api/v2#!/Users/post_identities).
+
+    ::: warning
+    To retain and merge the `user_metadata` from the secondary account, you must retrieve and merge it into the metadata for the primary account before calling the API endpoint. After the accounts are linked, the metadata for the secondary account is discarded. 
+    
+    When you initiate account linking, you can select which identity will be used as the primary account and which as the secondary. This choice will depend on which set of attributes you want to retain in the primary profile.
+    :::
+
+    In the `linkAccount` function, call the Management API. Authenticate with the API using the primary JWT, which is the Access Token, and link using the primary user's ID and the secondary JWT, which is the secondary user's ID Token.
+
+```
+  const linkAccount = async () => {
+  const accessToken = await auth0.getTokenSilently();
+  const { sub } = await auth0.getUser();
+  const {
+    __raw: targetUserIdToken,
+    email_verified,
+    email,
+  } = await authenticateUser();
+
+  if (!email_verified) {
+    throw new Error(
+      `Account linking is only allowed to a verified account. Please verify your email <%= "${email}" %>.`
+    );
+  }
+
+  await fetch(`https://${account.namespace}/api/v2/users/<%= "${sub}" %>/identities`, {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      Authorization: `Bearer <%= "${accessToken}" %>`,
+    },
+    body: JSON.stringify({
+      link_with: targetUserIdToken,
+    }),
+  });
+};
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
diff --git a/fr-ca/articles/users/references/link-accounts-server-side-scenario.md b/fr-ca/articles/users/references/link-accounts-server-side-scenario.md
new file mode 100644
index 0000000000..5650982f28
--- /dev/null
+++ b/fr-ca/articles/users/references/link-accounts-server-side-scenario.md
@@ -0,0 +1,204 @@
+---
+title: Suggested Account Linking - Server-Side Implementation
+description: Describes how to link user accounts with a regular web app using server-side code using a sample scenario.
+crews: crew-2
+topics:
+  - account-linking
+  - server-side
+contentType:
+  - reference
+useCase:
+  - manage-accounts
+---
+
+# Suggested Account Linking - Server-Side Implementation
+
+Auth0 supports the linking of user accounts from various identity providers. You can use server-side code to link accounts on a regular web application, engaging the user and asking them for permission before proceeding. Your code will authenticate users and search for and identify users using their email addresses. Your application will then prompt the user to link their accounts by authenticating with the target account's credentials, and later link the accounts.
+
+You can find the full source of this sample application [on GitHub](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/RegularWebApp).
+
+1. Log the user in to your application.
+
+    The user authenticates to your application using [Universal Login](/universal-login). For details, see the [Regular Web App Quickstarts](/quickstart/webapp), asking for a token for the Auth0 Management API audience (audience=`https://${account.namespace}/api/v2/`).
+
+2. Search for users with identical email addresses.
+
+    In the `/user` route implementation, we'll get the user profile and the list of users with the same verified email/
+
+```js
+router.get("/", async (req, res) => {
+  const { sub, email_verified } = req.openid.user;
+  //fetch user profile containing the user_metadata and app_metadata properties
+  try {
+    let getUsersWithSameVerifiedEmail = [];
+    const getUserProfile = auth0Client.getUser(sub);
+    if (email_verified)
+      // account linking is only offered verified email
+      getUsersWithSameVerifiedEmail = auth0Client.getUsersWithSameVerifiedEmail(
+        req.openid.user
+      );
+
+    const [user, suggestedUsers] = await Promise.all([
+      getUserProfile,
+      getUsersWithSameVerifiedEmail,
+    ]);
+
+    const flashError = clear(req);
+    res.render("user", {
+      user,
+      suggestedUsers,
+      wrongAccountError: flashError && flashError === Errors.WrongAccount,
+    });
+  } catch (err) {
+    debug("GET /user[s] failed: %o", err);
+    res.render("error", err);
+  }
+});
+```
+
+  To get a list of all of the user records with the same email address, your application calls the Auth0 Management API's [Get Users By Email endpoint](/api/v2#!/users-by-email/) using a [Management API Access Token](/api/management/v2/tokens) with the `read:users` scope.
+
+  ```js
+  const request = require('request');
+  class Auth0Client {
+    ...
+    async getUsersWithSameVerifiedEmail({ sub, email }) {
+      return await this.request({
+        url: `${process.env.ISSUER_BASE_URL}/api/v2/users`,
+        qs: {
+          search_engine: "v3",
+          q: `email:"<%= "${email}" %>" AND email_verified:true -user_id:"<%= "${sub}" %>"`,
+      } ,
+    });
+  }
+  ```
+
+3. Prompt the user to link accounts. 
+
+    If Auth0 returns one or more records with matching email addresses, the user will see the list along with the following message prompting them to link the accounts.
+
+    If the user wants to link a given account, they can click **Link** next to the appropriate account.
+
+![WebApp User Settings Example](/media/articles/link-accounts/account-linking-webapp-small.png)
+
+4. When the user clicks **Link**, your application will ask the user to authenticate with the target account, and then perform account linking. 
+
+    ::: warning
+    To retain and merge the `user_metadata` from the secondary account, you must retrieve and merge it into the metadata for the primary account before calling the API endpoint. After the accounts are linked, the metadata for the secondary account is discarded. 
+    
+    When calling account linking, you can select which identity will be used as the primary account and which as the secondary. This choice will depend on which set of attributes you want to retain in the primary profile.
+    :::
+
+    The following code snippet shows how to verify and merge metadata:
+
+  ```js
+  async function accountLink(req, res, next) {
+    const {
+      linking: { targetUserId },
+    } = req.appSession;
+    const { sub: authenticatedTargetUserId } = req.openidTokens.claims();
+    if (authenticatedTargetUserId !== targetUserId) {
+      debug(
+        "Skipping account linking as the authenticated user(%s)  is different than target linking user (%s)",
+        authenticatedTargetUserId,
+        targetUserId
+      );
+      set(req, Errors.WrongAccount);
+      return next();
+    }
+
+    debug(
+      "User %s succesfully authenticated. Account linking with %s... ",
+      authenticatedTargetUserId,
+      targetUserId
+    );
+    const { id_token: targetIdToken } = req.openidTokens;
+    const { sub: primaryUserId } = req.appSession.claims;
+
+    try {
+      await mergeMetadata(primaryUserId, authenticatedTargetUserId);
+      await auth0Client.linkAccounts(primaryUserId, targetIdToken);
+      debug("Accounts linked.");
+    } catch (err) {
+      debug("Linking failed %o", err);
+    } finally {
+      next();
+    }
+  }
+  ```
+
+5. Your application calls the Auth0 Management API's [Link a User Account endpoint](/api/v2#!/Users/post_identities) using a [Management API Access Token](/api/management/v2/tokens) with the `update:users` scope.
+
+```js
+async function accountLink(req, res, next) {
+  const {
+    linking: { targetUserId },
+  } = req.appSession;
+  const { sub: authenticatedTargetUserId } = req.openidTokens.claims();
+  if (authenticatedTargetUserId !== targetUserId) {
+    set(req, Errors.WrongAccount);
+    return next();
+  }
+
+  const { id_token: targetIdToken } = req.openidTokens;
+  const { sub: primaryUserId } = req.appSession.claims;
+
+  try {
+    await mergeMetadata(primaryUserId, authenticatedTargetUserId);
+    await auth0Client.linkAccounts(primaryUserId, targetIdToken);
+  } catch (err) {
+    debug("Linking failed %o", err);
+  } finally {
+    next();
+  }
+}
+```
+
+## Metadata merge example
+
+The following example shows explicitly how the `user_metadata` and `app_metadata` from the secondary account gets merged into the primary account using the [Node.js Auth0 SDK for API V2](https://github.com/auth0/node-auth0/tree/v2).
+
+```js
+/*
+ * Recursively merges user_metadata and app_metadata from secondary into primary user.
+ * Data of primary user takes preponderance.
+ * Array fields are joined.
+ */
+async function mergeMetadata(primaryUserId, secondaryUserId) {
+  // load both users with metedata.
+  const [primaryUser, secondaryUser] = await Promise.all(
+    [primaryUserId, secondaryUserId].map((uid) => auth0Client.getUser(uid))
+  );
+
+  const customizerCallback = function (objectValue, sourceValue) {
+    if (_.isArray(objectValue)) {
+      return sourceValue.concat(objectValue);
+    }
+  };
+  const mergedUserMetadata = _.merge(
+    {},
+    secondaryUser.user_metadata,
+    primaryUser.user_metadata,
+    customizerCallback
+  );
+  const mergedAppMetadata = _.merge(
+    {},
+    secondaryUser.app_metadata,
+    primaryUser.app_metadata,
+    customizerCallback
+  );
+  await auth0Client.updateUser(primaryUserId, {
+    user_metadata: mergedUserMetadata,
+    app_metadata: mergedAppMetadata,
+  });
+}
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/fr-ca/articles/users/references/user-data-storage-scenario.md b/fr-ca/articles/users/references/user-data-storage-scenario.md
new file mode 100644
index 0000000000..ee6a0624e3
--- /dev/null
+++ b/fr-ca/articles/users/references/user-data-storage-scenario.md
@@ -0,0 +1,277 @@
+---
+title: User Data Storage Scenario
+description: Recommendations for using Auth0 storage mechanisms.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - data-storage
+    - swift
+    - ios
+    - nodejs
+    - api
+contentType: reference
+useCase: manage-users
+---
+# User Data Storage Scenario
+
+Auth0 provides a sample app, a mobile music application, that reflects the end-to-end user experience when using Auth0 with an custom external database. The sample app is an iOS app created using the [Auth0 iOS seed project](/quickstart/native/ios-swift). The backend uses the [Node.js API](/quickstart/backend/nodejs). 
+
+For a visualization of the application's overall structure, see the [Mobile + API architecture scenario](/architecture-scenarios/application/mobile-api).
+
+## Metadata
+
+### App metadata
+
+The following data points from our mobile music application are appropriate to store in `app_metadata`:
+
+* User's subscription plan
+* User's right (or lack thereof) to edit featured playlists
+
+These two data points should be stored in `app_metadata` instead of `user_metadata` because they should not be directly changeable by the user.
+
+### User metadata
+
+The following data points from our mobile music application are appropriate to store in `user_metadata`:
+
+* Application preferences;
+* Any details chosen by the user to alter their experience of the app upon login.
+
+Note that, unlike the data points for `app_metadata`, the user can easily and readily change those stored in `user_metadata`.
+
+We can let the user change their `displayName`, which is the name the user sees upon logging in and is displayed to other users of the app.
+
+To display the user's chosen identifier whenever they log in, we use a rule to get the `user.user_metadata` value.
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  user.user_metadata.displayName = user.user_metadata.displayName || "user";
+
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+Here's a look at the screen the user would use to change their `displayName`:
+
+![](/media/articles/tutorials/data-scenarios/4-settings.png)
+
+To save the changes to the database, the application makes a call to the [Get a User](/api/management/v2#!/Users/get_users_by_id) endpoint of the [Management API](/api/management/v2) to identify the appropriate user:
+
+```har
+{
+	"method": "GET",
+	"url": "https://YOURACCOUNT.auth0.com/api/v2/users/user_id",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer YOUR_ID_TOKEN_HERE"
+	}]
+}
+```
+
+This is followed by a call to the [Update a User](/api/management/v2#!/Users/patch_users_by_id) endpoint to update the `user_metadata` field:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_ACCESS_TOKEN"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"displayName\": \"J-vald3z\"}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+You must replace `YOUR_ACCESS_TOKEN` with a [Management API Access Token](/api/management/v2/concepts/tokens).
+
+## User data permission rules
+
+Use [rules](/rules) to implement permissions on whether a user can edit featured playlists or not.
+
+### Assign Playlist Editor role
+
+The first rule sends a request to our Node API, which then queries the database connected to Heroku to check how many plays the user’s playlist has. If the number is 100 or greater, we assign `playlist_editor` as a value in the `roles` array in `app_metadata`.
+
+```js
+function (user, context, callback) {
+
+  var request = require('request');
+
+  user.app_metadata = user.app_metadata || {};
+  user.app_metadata.roles = user.roles || [];
+
+  var CLIENT_SECRET = configuration.AUTH0_CLIENT_SECRET;
+  var CLIENT_ID = configuration.AUTH0_CLIENT_ID;
+
+  var scope = {
+    user_id: user.user_id,
+    email: user.email,
+    name: user.name
+  };
+
+  var options = {
+    subject: user.user_id,
+    expiresInMinutes: 600,
+    audience: CLIENT_ID,
+    issuer: 'https://example.auth0.com'
+  };
+
+  var id_token = jwt.sign(scope, CLIENT_SECRET, options);
+
+  var auth = 'Bearer ' + id_token;
+
+  request.get({
+    url: 'https://example.com/playlists/getPlays',
+    headers: {
+       'Authorization': auth,
+      'Content-Type': 'text/html'
+    },
+    timeout: 15000
+  }, function(err, response, body){
+    if (err)
+      return callback(new Error(err));
+    var plays = parseInt(body, 10);
+
+    if (plays >= 100 && user.roles.indexOf('playlist_editor') < 0){
+      user.app_metadata.roles.push('playlist_editor');
+      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+        .then(function(){
+          callback(null, user, context);
+        })
+        .catch(callback);
+    }
+
+    else if (plays < 100 && user.roles.indexOf('playlist_editor') >= 0){
+      user.app_metadata.roles = [];
+      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+        .then(function(){
+          callback(null, user, context);
+        })
+        .catch(callback);
+    }
+    else{
+      callback(null, user, context);
+    }
+
+  });
+
+}
+```
+
+### Scope parameter specifies role 
+
+The second rule gets the `app_metadata` field and assigns the `roles` array to a field in the user object so it can be accessed without calling `app_metadata` on the application. The `scope` parameter can then specify `roles` upon the user logging in without including everything in `app_metadata` in the user object:
+
+```js
+function(user, context, callback) {
+   if (user.app_metadata) {
+      user.roles = user.app_metadata.roles;
+   }
+   user.roles = user.roles || [];
+   callback(null, user, context);
+}
+```
+
+After we've implemented these two rules, the app recognizes whether the user is a playlist editor or not and changes the welcome screen accordingly. If `playlist_editor` is in the `roles` array stored in the user's `app_metadata`, the user will be welcomed as an **EDITOR** after signing in:
+
+![](/media/articles/tutorials/data-scenarios/3-home.png)
+
+### Associate a user's music with the user
+
+We need to associate a user's music with that user, but this information is not required for authentication. Here's how to store this information in a separate database that is integrated with the backend of the application.
+
+The user's unique identifier is their [user_id](/users/normalized#storing-user-data). Here is a sample row from the `songs` table in our database:
+
+| song_id   | songname           | user_id                    |
+| --------- | ------------------ | -------------------------- |
+| 1         | Number One Hit     | google-oauth2|xxxyyy123    |
+
+The Node.js backend authenticates requests to the URI associated with getting the user’s personal data from the database by validating a JSON Web Token.
+
+::: note
+[Learn about token-based authentication and how to implement JWT in your Applications.](/tokens/concepts/jwts)
+:::
+
+Here is the code implementing JWT validation from the [Node.js seed project](/quickstart/backend/nodejs):
+
+```js
+var genres = require('./routes/genres');
+var songs = require('./routes/songs');
+var playlists = require('./routes/playlists');
+var displayName = require('./routes/displayName');
+
+var authenticate = jwt({
+  secret: process.env.AUTH0_CLIENT_SECRET,
+  audience: process.env.AUTH0_CLIENT_ID,
+  algorithms: ['RS256']
+});
+
+app.use('/genres', authenticate, genres);
+app.use('/songs', authenticate, songs);
+app.use('/playlists', authenticate, playlists);
+app.use('/displayName', authenticate, displayName);
+```
+
+We can add functionality to handle different data requests from our Application. For example, if we receive a `GET` request to `/secured/getFavGenre`, the API calls the `queryGenre()` function, which queries the database for and responds with the user’s favorite genre.
+
+```swift
+@IBAction func getGenre(sender: AnyObject) {
+        let request = buildAPIRequest("/genres/getFav", type:"GET")
+        let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {[unowned self](data, response, error) in
+            let genre = NSString(data: data!, encoding: NSUTF8StringEncoding)
+            dispatch_async(dispatch_get_main_queue(), {
+                self.favGenre.text = "Favorite Genre:  \(genre!)"
+            })
+        }
+        task.resume()
+    }
+```
+
+::: note
+The function `buildAPIRequest()` takes the path and HTTP method of the request as parameters and builds a request using the base URL of our Node.js API that's hosted on Heroku.
+:::
+
+In the Application, the `getGenre()` function makes a request to the API and changes the app's interface to display the request response to `/genres/getFav`. The backend retrieves the required data for this action using the `queryGenre()` function and returns the results to the Application:
+
+```js
+function queryGenre(user_id, res){
+
+  db.connect(process.env.DATABASE_URL, function(err, client) {
+  if (err) throw err;
+
+  client
+    .query('SELECT fav_genre as value FROM user_data WHERE user_id = $1', [user_id], function(err, result) {
+
+      if(err) {
+        return console.error('error running query', err);
+      }
+      res.send(result.rows[0].value);
+    });
+  });
+
+};
+```
+
+## Keep reading
+
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [Rules](/rules)
diff --git a/fr-ca/articles/users/references/user-migration-scenarios.md b/fr-ca/articles/users/references/user-migration-scenarios.md
new file mode 100644
index 0000000000..fa834ca472
--- /dev/null
+++ b/fr-ca/articles/users/references/user-migration-scenarios.md
@@ -0,0 +1,314 @@
+---
+title: User Migration Scenarios
+description: User migrations scenarios from various platforms using multiple methods.
+toc: true 
+topics:
+  - users
+  - user-management
+  - migrations
+  - gigya
+  - okta
+  - stormpath
+contentType:
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+# User Migration Scenarios
+
+Here are some sample scenarios for migrating users from Gigya, Okta, and Stormpath to Auth0. Each of these scenarios assumes that you have accounts on those platforms.
+
+## Prerequisites
+
+Configure the custom database connection.
+
+1. Create a new database connection in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard. 
+   
+![Create a new DB Connection](/media/articles/users/migrations/create-database-connection.png)
+
+2. Connect the database to the application. Navigate to the **Applications** tab of your database settings, under the **Applications Using This Connection** heading you can enable the database connection for each application.
+   
+![Database Connection Applications](/media/articles/users/migrations/enable-clients.png)
+
+## Scenario 1: Migrate Users from Gigya to Auth0
+
+1. Export Gigya users. Use [Gigya's IdentitySync](https://developers.gigya.com/display/GD/IdentitySync) to transform and export user data to match a target schema. For more details on this process, see [Gigya IdentitySync: Using IdentitySync](https://developers.gigya.com/display/GD/IdentitySync#IdentitySync-apiUsingIdentitySync).
+
+   Follow the instructions to transform your Gigya database's user data to the correct [schema](/users/references/bulk-import-database-schema-examples) and export the transformed data to JSON format.
+
+2. Import your Gigya users into Auth0 with the User Import/Export Extension or the Management API.
+   - Go to the [Extensions](${manage_url}/#/extensions) section of the Dashboard. Select the **User Import / Export** extension and install it. Once the extension is installed, you can click it to open an import/export interface that looks like this:
+
+     ![User Import/Export Extension](/media/articles/extensions/user-import-export/import.png)
+
+     Drag your exported Gigya users JSON file into the designated upload area and select the database you created earlier. Click the **Start Importing Users** button to begin your import. For more information, see [User Import/Export Extension](//extensions/user-import-export).
+   
+   - Alternatively, you can use the Management API. [Create a job](/api/management/v2#!/Jobs/post_users_imports) to import your users to Auth0. For detailed instructions, see [Bulk User Imports](/users/guides/bulk-user-imports).
+
+## Scenario 2: Migrate Users from Okta to Auth0
+
+1. Navigate to the  **Settings** page for your database connection, and enable the **Import Users to Auth0** option:
+
+![Enable Import Users](/media/articles/dashboard/connectionsdatabase/connections-db-settings-main-2.png)
+
+2. Create the [Login script](/connections/database/custom-db/templates/login). The **Login** script is executed when a user attempts to log in, but their account is not found in the Auth0 database. You will need to create a script which will call the Okta [Primary Authentication](https://developer.okta.com/docs/api/resources/authn.html#primary-authentication) endpoint, passing the email and password as the `username` and `password` parameters.
+
+On successful authentication, Okta will return an [Authentication Transaction object](https://developer.okta.com/docs/api/resources/authn.html#authentication-transaction-model), containing the [user's profile](https://developer.okta.com/docs/api/resources/authn.html#user-profile-object) in the [embedded resources](https://developer.okta.com/docs/api/resources/authn.html#embedded-resources). You can then simply extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function login (email, password, callback) {
+  // Replace YOUR-OKTA-DOMAIN with your own Okta domain
+  var url = 'https:/YOUR-OKTA-DOMAIN/api/v1/authn';
+
+  // Make the POST request to authenticate a user
+  request({
+    url: url,
+    method: 'POST',
+    headers: {
+      'Content-Type': 'application/json',
+      'Accept': 'application/json'
+    },
+    body: {
+      username: email,
+      password: password,
+      options: {
+        multiOptionalFactorEnroll: false,
+        warnBeforePasswordExpired: false
+      }
+    },
+    json: true
+  }, function (error, response, body) {
+    // Ensure we have a successful response
+    if (response.statusCode !== 200) return callback();
+    
+    // Get the user from the response body
+    var user = body._embedded.user;
+    
+    // Set the data we want to store in Auth0 and migrate the user
+    return callback(null, {
+        user_id : user.id,
+        username: user.profile.login,
+        email: user.profile.login,
+        // We set the users email_verified to true as we assume if they were a valid
+        // user in Okta, they have already verified their email
+        // If this field is not set, the user will get an email asking them to verify
+        // their account
+        email_verified: true,
+        name: user.profile.firstName + ' ' + user.profile.lastName
+      });
+  });
+}
+```
+
+You can click the **Try** button above the script to test and see whether the script works.
+
+3. Create the Get User Script. The **Get User** script is executed when the user attempts to do a password reset but their account is not found in the Auth0 database. You will need to create a script which will call the Okta [Get User with Login](https://developer.okta.com/docs/api/resources/users.html#get-user-with-login) endpoint, passing the user's email as the `login` parameter.
+
+You will also need to [Create an API token](https://developer.okta.com/docs/api/getting_started/getting_a_token.html) which must be passed to this endpoint in the `Authorization` header.
+
+If successful, Okta will return a [User object](https://developer.okta.com/docs/api/resources/users.html#user-model) with the user's information. Once again, you can extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function getByEmail(email, callback) {
+  // Replace YOUR-OKTA-DOMAIN with your own Okta domain
+  var url = 'https://YOUR-OKTA-DOMAIN/api/v1/users/' + encodeURIComponent(email);
+
+  // Make a GET request to find a user by email
+  // Replace YOUR-OKTA-API-TOKEN with an Okta API Token 
+  // (see https://developer.okta.com/docs/api/getting_started/getting_a_token.html) 
+  request({
+    url: url,
+    method: 'GET',
+    headers: {
+      'Content-Type': 'application/json',
+      'Accept': 'application/json',
+      'Authorization': 'SSWS ' + 'YOUR-OKTA-API-TOKEN'
+    },
+    json: true
+  }, function (error, response, body) {
+    // Ensure we have a successful response
+    if (response.statusCode !== 200) return callback();
+
+    // Set the data we want to store in Auth0 and migrate the user
+    return callback(null, {
+      user_id: body.id,
+      username: body.profile.login,
+      email: body.profile.login,
+      email_verified: true,
+      name: body.profile.firstName + ' ' + body.profile.lastName
+    });
+  });
+}
+```
+
+Click the **Try** button above the script to test and see whether the script works.
+
+4. Test the custom database connection to ensure that it works.
+
+   - Click on **Try connection**:
+
+      ![Try Connection](/media/articles/connections/database/okta/try-connection.png)
+
+      The Auth0 Lock widget will appear. Enter the email address and password for the Okta user, and click on **Log In**:
+
+      ![Try Connection - Lock](/media/articles/connections/database/okta/try-connection-lock.png)
+
+      You should see a web page indicating that the connection works, with information about the user:
+
+      ![Try Connection - Success](/media/articles/connections/database/okta/try-connection-success.png)
+
+   - Navigate to the [Users](${manage_url}/#/users) section in the Auth0 Dashboard to see the newly imported users listed:
+
+     ![Imported User](/media/articles/connections/database/okta/user-imported.png)
+
+## Scenario 3: Migrate users from Stormpath to Auth0
+
+1. Navigate to the **Settings** page for your database connection, and enable the **Import Users to Auth0** option:
+
+   ![Enable Import Users](/media/articles/dashboard/connectionsdatabase/connections-db-settings-main-2.png)
+
+2. Navigate to the **Applications** tab of your database connection. Here you can choose the applications which will use the database connection.
+
+   ![Database Connection Applications](/media/articles/users/migrations/enable-clients.png)
+
+3. Create the Login Script. The **Login** script is executed when a user attempts to log in, but their account is not found in the Auth0 database. You will need to create a script that calls Stormpath's API to authenticate the user, passing the user credentials as the `username` and `password` parameters.
+
+   On successful authentication, the response from Stormpath will include the user account URL. Perform a second request to the account URL to retrieve the user's information. You can then extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function login(username, password, callback) {
+  // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
+  var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/loginAttempts';
+
+  // Stormpath requires the user credentials be passed in as a base64 encoded message
+  var message = username + ':' + password;
+  var pass = new Buffer(message).toString('base64');
+
+  // Here we are making the POST request to authenticate a user
+  request({
+    url: url,
+    method: 'POST',
+    auth: {
+      // Your API Client ID
+      user: '{STORMPATH-CLIENT-ID}',
+      // YOUR API Client Secret
+      password: '{STORMPATH-CLIENT-SECRET}'
+    },
+    headers: {
+      'Content-Type': 'application/json'
+    },
+    json: {
+      type: 'basic',
+      // Passing in the base64 encoded credentials
+      value: pass
+    }
+  }, function (error, response, body) {
+    // If response is successful we'll continue
+    if (response.statusCode !== 200) return callback();
+    // A successful response will return a URL to get the user information
+    var accountUrl = body.account.href;
+
+    // We'll make a second request to get the user info. This time it will be a GET request
+    request({
+      url: accountUrl,
+      method: 'GET',
+      auth: {
+        // Your API Client ID
+        user: '{STORMPATH-CLIENT-ID}',
+        // YOUR API Client Secret
+        password: '{STORMPATH-CLIENT-SECRET}'
+      }
+    }, function (errorUserInfo, responseUserInfo, bodyUserInfo) {
+      // If we get a successful response, we'll process it
+      if (responseUserInfo.statusCode !== 200) return callback();
+
+      var parsedBody = JSON.parse(bodyUserInfo);
+      // To get the user identifier, we'll strip out the Stormpath API
+      var id = parsedBody.href.replace('https://api.stormpath.com/v1/accounts/', '');
+
+      // Finally, we'll set the data we want to store in Auth0 and migrate the user
+      return callback(null, {
+        user_id : id,
+        username: parsedBody.username,
+        email: parsedBody.email,
+        // We set the users email_verified to true as we assume if they were a valid
+        // user in Stormpath, they have already verified their email
+        // If this field is not set, the user will get an email asking them to verify
+        // their account
+        email_verified: true,
+        // Add any additional fields you would like to carry over from Stormpath
+      });
+    });
+  });
+}
+```
+
+Click the **Try** button above the script to test and see whether the script works.
+
+4. Create the Get User Script. The **Get User** script is executed when the user attempts to do a password reset but their account is not found in the Auth0 database. You will need to create a script which will call the `/accounts` endpoint of the Stormpath API, passing the user's email as the `email` parameter.
+
+   If successful, Stormpath will return a the user's information. You can extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function getByEmail(email, callback) {
+  // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
+  var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/accounts';
+
+  request({
+    url: url,
+    method: 'GET',
+    auth: {
+      // Your API Client ID
+      user: '{STORMPATH-CLIENT-ID}',
+      // YOUR API Client Secret
+      password: '{STORMPATH-CLIENT-SECRET}'
+    },
+    qs: { q: email }
+  }, function (error, response, body) {
+    if (response.statusCode !== 200) return callback();
+
+    var parsedBody = JSON.parse(body);
+    var user = parsedBody.items[0];
+
+    if (!user) return callback();
+
+    var id = user.href.replace('https://api.stormpath.com/v1/accounts/', '');
+
+    return callback(null, {
+      user_id: id,
+      username: user.username,
+      email: user.email,
+      email_verified: true,
+      // Add any additional fields you would like to carry over from Stormpath
+    });
+  });
+}
+```
+
+   Click the **Try** button above the script to test and see whether the script works.
+
+5. Test the custom database connection to ensure that it works.
+
+   - Click on **Try connection**:
+
+     ![Try Connection](/media/articles/users/migrations/try-connection.png)
+
+     The Auth0 Lock widget will appear. Enter the email address and password for the Stormpath user, and click on **Log In**:
+
+     ![Try Connection - Lock](/media/articles/users/migrations/try-connection-lock.png)
+
+     You should see a web page indicating that the connection works, with information about the user:
+
+     ![Try Connection - Success](/media/articles/users/migrations/try-connection-success.png)
+
+   - Navigate to the [Users](${manage_url}/#/users) section in the Auth0 Dashboard, you will see the newly imported user listed:
+
+     ![Imported User](/media/articles/users/migrations/user-imported.png)
+
+## Keep reading
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [Login Script Templates](/connections/database/custom-db/templates/login)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [User Import/Export Extension](/extensions/user-import-export)
diff --git a/fr-ca/articles/users/references/user-profile-structure.md b/fr-ca/articles/users/references/user-profile-structure.md
new file mode 100644
index 0000000000..3dddca16be
--- /dev/null
+++ b/fr-ca/articles/users/references/user-profile-structure.md
@@ -0,0 +1,75 @@
+---
+description: Lists the attributes that are available on the Auth0 user profile
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - user-profile-structure
+contentType: reference
+useCase: manage-users
+v2: true
+---
+
+# User Profile Structure
+
+Auth0's normalized user profile consists of a few different components: 
+
+* **Details**: Core User Profile object, which contains basic info, such as name, email, and timestamp of the user's latest login, in pre-defined attributes. This object may also contain info from a user's source [connection](/connections). Most of the user attributes are root attributes (attributes stored at the first, or root, level of the `user` object), and some of these are editable.
+
+* **Metadata**: Two sub-objects that operate as secondary storage to store additional user info in customizable attributes: `user_metadata` and `app_metadata`. See [Metadata](/users/concepts/overview-user-metadata) for more information, including when to use `app_metadata` and `user_metadata`.
+
+## User profile attributes
+
+The following attributes are available on the user profile. Many are root attributes (attributes stored at the first, or root, level of the `user` object), and some may be updated, imported, and exported, as noted below.
+
+::: panel Blacklist user attributes
+If there are user fields that should not be stored by Auth0 due to privacy reasons, you can blacklist the attributes you do not want persisting in Auth0 databases. For details, see [Blacklist User Attributes](/security/blacklisting-attributes).
+:::
+
+::: warning
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+:::
+
+| Name             | Type | Description | [Search?](/users/search) | [Update?](/api/management/guides/users/update-root-attributes-users) | [Import?](/users/guides/bulk-user-imports) | [Upsert during import?](/users/guides/bulk-user-imports#request-bulk-import) | [Export?](/users/guides/bulk-user-exports) |
+|-|-|-|-|-|-|-|-|-|
+| `app_metadata`   | object | Custom fields that store info about a user that influences the user's access, such as support plan, security roles (if not using the Authorization Core feature set), or access control groups. For more info, see [Metadata Overview](/users/concepts/overview-user-metadata). | Y | Y | Y | Y | Y |
+| `blocked`        | boolean | Indicates whether the user has been blocked. Importing enables subscribers to ensure that users remain blocked when migrating to Auth0. | Y | Y | Y | N | Y |
+| `created_at`     | date time | Timestamp indicating when the user profile was first created. | Y | N | N | N | Y |
+| `email`          | text | (unique) The user's email address. | Y | Y | Y | N | Y |
+| `email_verified` | boolean | Indicates whether the user has verified their email address. | Y | Y | Y | Y | Y |
+| `family_name` | text | The user's family name. | Y | Y | Y | Y | Y |
+| `given_name` | text | The user's given name. | Y | Y | Y | Y | Y |
+| `identities`     | array (object) | <%= include('../_includes/_user-prop-identities.md') %> |  Y | N | N | N | Y |
+| `last_ip`       | text | IP address associated with the user's last login. | Y | N | N | N | Y |
+| `last_login`    | date time | Timestamp indicating when the user last logged in. If a user is blocked and logs in, the blocked session updates `last_login`. If you are using this property from inside a [Rule](/rules) using the `user` object, its value will be associated with the login that triggered the rule; this is because rules execute after login. | Y | N | N | N | Y |
+| `last_password_reset` | date time | Timestamp indicating the last time the user's password was reset/changed. At user creation, this field does not exist. This property is only available for Database connections. | N | N | N | N | N |
+| `logins_count` | integer | Number of times the user has logged in. If a user is blocked and logs in, the blocked session is counted in `logins_count`. | Y | N | N | N | Y |
+| `multifactor`   | text | List of multi-factor providers with which the user is enrolled. | N | N | N | N | Y |
+| `name`          | text | The user's full name. | Y | Y | Y | Y | Y |
+| `nickname`      | text | The user's nickname. | Y | Y | Y | Y | Y |
+| `phone_number` | text | The user's phone number. Only valid for users with SMS connections. | Y | Y | N | N | Y |
+| `phone_verified` | boolean | Indicates whether the user has been verified their phone number. Only valid for users with SMS connections. | Y | Y | N | N | Y |
+| `picture` | text | URL pointing to [the user's profile picture](/users/guides/change-user-pictures). | N | Y | Y | Y | Y |
+| `updated_at` | date time | Timestamp indicating when the user's profile was last updated/modified. Changes to `last_login` are considered updates, so most of the time, `updated_at` will match `last_login`. | Y | N | N | N | Y |
+| `user_id` | text | (unique) The user's identifier. Importing allows user records to be synchronized across multiple systems without using mapping tables. | Y | N | Y | N | Y |
+| `user_metadata` | object | Custom fields that store info about a user that does not impact what they can or cannot access, such as work address, home address, or user preferences. For more info, see [Metadata Overview](/users/concepts/overview-user-metadata). | Y | Y | Y | Y | Y |
+| `username` | text | (unique) The user's username. | Y | Y | Y | N | Y |
+
+::: note
+Three other fields are not technically part of the user profile, but may be of interest when importing users:
+
+* `password_hash` (text): Hashed password for the user's connection. When users are created, Auth0 uses [bcrypt](https://www.npmjs.com/package/bcrypt) to secure the password. Importing compatible hashed passwords allows users to retain their passwords, thereby providing a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds. Note that this field can only be provided when the user is first imported — it can not be updated later.
+* `custom_password_hash` (object): A more generic way to provide the users password hash. This can be used in lieu of the password_hash field when the users password hash was created with an alternate algorithm. Note that this field can only be provided when the user is first imported — it can not be updated later.
+* `password_set_date` (date time): Timestamp indicating when the password for the user's connection was set. At user creation, this field exists, and `last_password_reset` does not. If the user has reset their password, this field and `last_password_reset` are identical.
+:::
+
+## View user profile
+
+To view the user profile, navigate to [Users](${manage_url}/#/users) in the [Auth0 Dashboard](${manage_url}), and then click a user you want to view.
+
+## Keep reading
+
+* [Normalized User Profiles](/users/normalized)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/fr-ca/articles/users/search/index.yml b/fr-ca/articles/users/search/index.yml
new file mode 100644
index 0000000000..1a8c5c46c4
--- /dev/null
+++ b/fr-ca/articles/users/search/index.yml
@@ -0,0 +1,8 @@
+versioning:
+  baseUrl: users/search
+  current: v3
+  versions:
+    - v2
+    - v3
+  defaultArticles:
+    v3: index
\ No newline at end of file
diff --git a/fr-ca/articles/users/search/v2/index.md b/fr-ca/articles/users/search/v2/index.md
new file mode 100644
index 0000000000..df2b8516b9
--- /dev/null
+++ b/fr-ca/articles/users/search/v2/index.md
@@ -0,0 +1,141 @@
+---
+description: This page lists several examples of user search queries using query string syntax.
+crews: crew-2
+toc: true
+topics:
+  - users
+  - user-management
+  - search
+contentType:
+  - reference
+  - how-to
+  - index
+useCase:
+  - manage-users
+---
+# User Search
+
+::: version-warning
+For all deployment models except Private Cloud, user search v2 has reached its end of life as of **June 30, 2019**. For information on migrating from user search v2 to v3, see [Migrate from search engine v2 to v3](/users/search/v3/migrate-search-v2-v3).
+:::
+
+Auth0 allows you, as an administrator, to search for users using [Lucene Query Syntax](http://www.lucenetutorial.com/lucene-query-syntax.html).
+
+This document provides sample queries and demonstrates how you can search for users. We also suggest that you refer to [Query String Syntax](/api/management/v2/query-string-syntax) for more examples of query string syntax.
+
+::: warning
+The user search endpoint allows you to return a maximum of **10,000** users. For additional results, please use either the [User Export Job endpoint](/api/management/v2#!/Jobs/post_users_exports) or the [User Export Extension](/extensions/user-import-export).
+:::
+
+## Search for users using the Management API
+
+You can also search for users using the [Management API](/api/v2). Two of the easiest ways to do this is by either making use of the **API Explorer** or by using **Postman**. These two techniques are discussed briefly below, but please note that the Auth0 Management API is a REST API, so you can make API calls using anything that can make HTTP requests, or by using one of the [Auth0 SDKs](/support/matrix#sdks).
+
+In order to make requests to the Management API, you will need a token. Please refer to [Access Tokens for the Management API](/api/management/v2/tokens) for more information.
+
+### Search using the API Explorer
+
+To search users using the [Management API Explorer](/api/management/v2#!/Users/get_users), go to the **Users** section and then select **List or search users**. Scroll down to the `q` parameter. You can use any query string which uses the [query string syntax](/api/management/v2/query-string-syntax) in this field.
+
+![Searching users in API Explorer](/media/articles/api/search-users-api.png)
+
+### Search using Postman
+
+You can also search users using the Postman Collection for the Management API. Make sure you read [Using the Auth0 API with our Postman Collections](/api/postman) for more information on how to install the collection and also configure your Postman environment correctly.
+
+Once you have downloaded the collection, and configured your environment, select the **Management API** collection. Navigate to the **Users** folder and select **List or search users**. You can enter your query in the `q` parameter of the URL:
+
+![Searching users in Postman](/media/articles/api/postman/get-users-postman.png)
+
+::: note
+For general information on making Postman request, please refer to the [Postman documentation](https://www.getpostman.com/docs/requests).
+:::
+
+## Sorting search results 
+
+To sort the list of users returned from the Management API, you can make use of the `sort` parameter.  Use the format `field:order` for the value of the `sort` field, where `field` is the name of the field you want to sort by, and `order` can be `1` for ascending and `-1` for descending. For example, to sort users in ascending order by the `created_at` field you can pass the value of `created_at:1` for the `sort` parameter. Sorting by `app_metadata` or `user_metadata` is not supported.
+
+For more information on the `sort` and other parameters, please refer to the [Management API Explorer documentation](/api/v2#!/Users/get_users).
+
+::: note
+If there is no default sort field specified, some users that have never logged in, may not appear. No default sort field may also result in duplicate records returned and the order of list of users may appear random.
+:::
+
+## Exact matching and tokenization
+
+Because of the manner in which ElasticSearch handles tokenization on `+` and `-`, unexpected results can occur when searching by some fields. For example, when searching for a user whose `name` is `jane` (`name:"jane"`), the results will be both for `jane` and `jane-doe`, because both of these _contain_ the exact search term that you used. The difference may not affect some searches, but it will affect others, and provide unanticipated results.
+
+You can solve this problem either by using structured JSON in your metadata, or by using the raw subfield.
+
+## Using the `raw` subfield
+
+If you wish to avoid the potential pitfalls of analyzed data and search for an exact match to your term - an exact string comparison - then for some fields you can use the `raw` subfield, which will be `not_analyzed`.
+
+So, in the example `name.raw:"jane"`, the user data for `jane` would match, but `jane-doe` would not.
+
+The fields that support `raw` subfield queries are:
+
+* `identities.connection⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`identities.provider⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`identities.user_id⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`email⁠`
+* ⁠⁠⁠⁠`phone_number⁠⁠`
+* ⁠⁠⁠⁠`family_name⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`given_name⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`username⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`name⁠⁠`
+* ⁠⁠⁠⁠`nickname`
+
+## Example queries
+
+Below are some example queries to illustrate the kinds of queries that are possible using the Management API V2.
+
+Use Case | Query
+---------|----------
+Search for all users whose name _contains_ "john" | `name:"john"`
+Search all users whose name _is_ exactly "john" | `name.raw:"john"`
+Search for all user names starting with "john" | `name:john*`
+Search for user names that start with "john" and end with "smith" | `name:john*smith`
+Search for all users whose email _is_ exactly "john@contoso\.com" | `email.raw:"john@contoso.com"`
+Search for all users whose email is exactly "john@contoso\.com" or "mary@contoso\.com" using `OR` | `email.raw:("john@contoso.com" OR "mary@contoso.com")`
+Search for users without verified email | `email_verified:false OR NOT _exists_:email_verified`
+Search for users who have the `user_metadata` field named `name` with the value of "John Doe" | `user_metadata.name:"John Doe"`
+Search for users from a specific connection or provider | `identities.provider:"google-oauth2"`
+Search for all users that have never logged in | `(NOT _exists_:logins_count OR logins_count:0)` 
+Search for all users who logged in before 2015 | `last_login:[* TO 2014-12-31]`
+Fuzziness: Search for terms that are similar to, but not exactly like, `jhn` | `name:jhn~`
+All users with more than 100 logins | `logins_count:>100`
+Logins count >= 100 and <= 200 | `logins_count:[100 TO 200]`
+Logins count >= 100 | `logins_count:[100 TO *]`
+Logins count > 100 and < 200 | `logins_count:{100 TO 200}`
+
+### Example request
+
+Below is an example request for searching all users whose email is exactly "john@contoso.com".
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/users",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" }
+  ],
+  "queryString": [
+    {
+      "name": "q",
+      "value": "email.raw:\"john@contoso.com\"",
+      "comment": "Query in Lucene query string syntax"
+    },
+    {
+      "name": "search_engine",
+      "value": "v2",
+      "comment": "Use 'v2' if you want to try our new search engine"
+    }
+  ]
+}
+```
+
+## Keep reading
+
+* [Query Syntax](/users/search/v2/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
diff --git a/fr-ca/articles/users/search/v2/query-syntax.md b/fr-ca/articles/users/search/v2/query-syntax.md
new file mode 100644
index 0000000000..69e99dbdf0
--- /dev/null
+++ b/fr-ca/articles/users/search/v2/query-syntax.md
@@ -0,0 +1,197 @@
+---
+toc: true
+description: This page explains query string syntax, which you can use to construct custom queries when searching using Auth0's Management API.
+crews: crew-2
+topics:
+  - users
+  - user-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-users
+---
+
+# User Search Query Syntax
+
+::: version-warning
+This document covers a previous version of user search. We recommend you use [user search v3](/users/search/v3).
+:::
+
+This page explains query string syntax, the mini-language used by the Query String Query.
+
+When searching using Auth0's [List or search users](/api/v2/#!/Users/get_users) endpoint, you can construct custom queries using this syntax for the value of the `q` field.
+
+The query string is parsed into a series of *terms* and *operators*. A term can be a single word  (`john` or `smith`) or a phrase surrounded by double quotes (`"john smith"`) which will match all the words in the phrase in the same order.
+
+## Searchable fields
+
+You can search for users using the following fields:
+
+* All the [normalized user profile](/users/normalized/auth0/normalized-user-profile-schema) fields
+
+* __Only__ the profile information under the `user_metadata` object:
+  - `name`
+  - `nickname`
+  - `given_name`
+  - `family_name`
+
+::: warning
+New tenants, starting September 1st 2017, cannot search any of the `app_metadata` fields. Paid tenants (that is, tenants that have a credit card associated in the [Dashboard](${manage_url}/#/tenant/billing/payment)) that were created up to August 31st 2017, can search using the `app_metadata` fields.
+Note that [Search v3](/users/search/v3/query-syntax) does not have this restriction.
+:::
+For more information, see the [Metadata Overview](/users/concepts/overview-user-metadata).
+
+### Field name examples
+
+Some examples of query string syntax are:
+
+* Where the `created_at` field contains `2016`: `created_at:2016`
+
+* Where the `user_name` field contains `john` or `smith`. If you omit the OR operator the default operator will be used.
+
+    `user_name: (john OR smith)`
+    `user_name: (john smith)`
+
+* Where the `user_name` field contains the exact phrase `"john smith"`: `user_name: "john smith"`
+
+* Where the field `nickname` has no value or is missing: `NOT _exists_: nickname`
+
+* Where the field `nickname` has any non-null value: `_exists_: nickname`
+
+* Your query can search across more than one field by using the `AND` & `OR` condition. Where the username field is exactly `"john"` AND the field `nickname` has any non-null value: `username: "john" AND _exists_: nickname`
+
+## Wildcards
+
+Wildcard searches can be run on individual terms, using `?` to replace a single character, and `*` to replace zero or more characters: `2016-0?-*`
+
+Note that certain wildcard queries will require an enormous amount of memory and perform poorly. (For example, imagine how many terms need to be queried to match the query string `"a* b* c*"`.)
+
+## Regular expressions
+
+Regular expression patterns can be embedded in the query string by wrapping them in forward-slashes ("/"): `name:/joh?n(ath[oa]n)/`
+
+::: note
+A detailed explanation of the supported regular expression syntax is explained on the Elastic's site at [Regular Expression Syntax](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html#regexp-syntax).
+:::
+
+## Fuzziness
+
+You can search for terms that are similar to, but not exactly like, your search terms using the `~` as a "fuzzy" operator: `oauth~`
+
+This is useful for commonly misspelled fields.
+
+## Proximity searches
+
+While a phrase query (eg `"john smith"`) matches all of the terms in  the exact same order, a proximity query allows the specified words to be further apart or in a different order. In the same way that a fuzzy query can specify a maximum edit distance between characters in a word, a proximity search allows you to specify a maximum distance between words in a phrase: `"fox quick"~5`
+
+The closer the text in a field is to the original order specified in the query string, the more relevant that result is ranked. When compared to the above example query, the phrase `"quick fox"` would be considered more relevant than `"quick brown fox"`.
+
+## Ranges
+
+Inclusive ranges are specified with square brackets: `[min TO max]` and exclusive ranges with curly brackets: `{min TO max}`. Curly and square brackets can be combined in the same range expression: `logins_count:[100 TO 200}`.
+
+Ranges can be specified for date, numeric or string fields.
+
+Some examples of range queries are:
+
+* Last login date of 2015:
+
+    `last_login:[2015-01-01 TO 2015-12-31]`
+
+* Users who have logged in between 1-5 times:
+
+    `logins_count:[1 TO 5]`
+
+* Last login between two dates, excluding the first and last day:
+
+    `last_login:{2012-01-01 TO 2012-12-31}`
+
+* Users that have logged on over 10 times:
+
+    `logins_count:[10 TO *]`
+
+* Logins before 2015:
+
+    `last_login{* TO 2015-01-01}`
+
+Curly and square brackets can be combined in the same range expression:
+
+* Logins count > 100 and < 200:
+
+    `logins_count:[100 TO 200}`
+
+For ranges with one side unbounded, you can use the following syntax:
+
+`logins_count:>10`
+`logins_count:>=10`
+`logins_count:<10`
+`logins_count:<=10`
+
+To combine an upper and lower bound with the simplified syntax, you need to join two clauses with an `AND` operator:
+
+`logins_count:(>=10 AND <20)`
+`logins_count:(+>=10 +<20)`
+
+The parsing of ranges in query strings can be complex and error prone. It is more reliable to use an explicit [range query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html).
+
+## Boosting
+
+Use the boost operator ^ to make one term more relevant than another. For instance, if you want to find all documents about foxes, but are especially interested in quick foxes:
+
+`quick^2 fox`
+
+The default *boost* value is 1, but it can be any positive floating-point number. Boost values between 0 and 1 reduce relevance of the matching result.
+
+Boosts can also be applied to phrases or groups:
+
+`"john smith"^2   (foo bar)^4`
+
+## Boolean operators
+
+By default, all terms are optional as long as one term matches. A search for `foo bar baz` will find any document that contains one or more of `foo` or `bar` or `baz`.
+
+Use of the `default_operator`, which allows you to force all terms to be required, is [discussed above](#field-name-examples). However, there are Boolean operators that can be used in the query string itself for more control.
+
+The preferred operators are `+` (this term *must* be present) and `-` (this term *must not* be present). All other terms are optional. For example, this query:
+
+`quick brown +fox -news`
+
+states that:
+
+* `fox` must be present
+* `news` must not be present
+* `quick` and `brown` are optional but their presence will increase the relevance of the result.
+
+The familiar operators `AND`,` OR` and `NOT `(also written `&&`,`||` and `!`) are also supported. However, the effects of these operators can be more complicated than is obvious at first. `NOT` takes precedence over `AND`, which takes precedence over `OR`. While the `+` and `-` only affect the term to the right of the operator, `AND` and `OR` can affect both the terms to the left and to the right.
+
+## Grouping
+
+Multiple terms or clauses can be grouped together with parentheses to form sub-queries:
+
+`(quick OR brown) AND fox`
+
+Groups can be used to target a particular field, or to boost the result of a sub-query:
+
+`status:(active OR pending) title:(full text search)^2`
+
+## Reserved characters
+
+If you need to use any of the characters which function as operators in the query itself as literal text (not as operators), then you must escape them with a leading backslash. For instance, to search for "(1+1)=2", you would need to write your query as `\(1\+1\)\=2`.
+
+The reserved characters are: `+ - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /`
+
+Failing to escape these special characters correctly could lead to a syntax error which will prevent your query from executing correctly.
+
+## Empty query
+
+If the query string is empty or contains only whitespaces, the query will yield an empty result set.
+
+## Additional Information
+
+For example queries for searching users, see [Users Search](/api/v2/user-search).
+
+::: note
+The preceding information is adapted from Elastic's [Elasticsearch Reference](http://elastic.co).
+:::
diff --git a/fr-ca/articles/users/search/v3/_valid-access-token.md b/fr-ca/articles/users/search/v3/_valid-access-token.md
new file mode 100644
index 0000000000..5093842c08
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/_valid-access-token.md
@@ -0,0 +1,3 @@
+## Prerequisite
+
+To use the user search endpoints, you'll need to obtain a valid [Access Token](/api/management/v2/tokens) and provide it in the header of your call (replace the `YOUR_MGMT_API_ACCESS_TOKEN` placeholder value).
diff --git a/fr-ca/articles/users/search/v3/get-users-by-email-endpoint.md b/fr-ca/articles/users/search/v3/get-users-by-email-endpoint.md
new file mode 100644
index 0000000000..ca3b478de6
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/get-users-by-email-endpoint.md
@@ -0,0 +1,85 @@
+---
+title: Retrieve Users with the Get Users by Email Endpoint 
+description: Learn how to retrieve lists of users using the get-users-by-email endpoint. 
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users by Email Endpoint 
+
+The [`GET /api/v2/users-by-email` endpoint](/api/management/v2#!/Users_By_Email/get_users_by_email) allows you to search for users using their email addresses. The search looks for an exact match to the provided email address and is case-sensitive.
+
+This endpoint is **immediately consistent**, and as such, we recommend that you use this endpoint for:
+
+* User searches run during the authentication process. 
+* User searches run as part of the account linking process.
+
+<%= include('./_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users-by-email?email=USER_EMAIL_ADDRESS",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }]
+}
+```
+
+### Sample results 
+
+```json
+[
+  {
+    "email": "john.doe@gmail.com",
+    "email_verified": false,
+    "username": "johndoe",
+    "phone_number": "+199999999999999",
+    "phone_verified": false,
+    "user_id": "usr_5457edea1b8f33391a000004",
+    "created_at": "",
+    "updated_at": "",
+    "identities": [
+      {
+        "connection": "Initial-Connection",
+        "user_id": "5457edea1b8f22891a000004",
+        "provider": "auth0",
+        "isSocial": false
+      }
+    ],
+    "app_metadata": {},
+    "user_metadata": {},
+    "picture": "",
+    "name": "",
+    "nickname": "",
+    "multifactor": [
+      ""
+    ],
+    "last_ip": "",
+    "last_login": "",
+    "logins_count": 0,
+    "blocked": false,
+    "given_name": "",
+    "family_name": ""
+  }
+]
+```
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/fr-ca/articles/users/search/v3/get-users-by-id-endpoint.md b/fr-ca/articles/users/search/v3/get-users-by-id-endpoint.md
new file mode 100644
index 0000000000..e5df676ad3
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/get-users-by-id-endpoint.md
@@ -0,0 +1,87 @@
+---
+title: Retrieve Users with the Get Users by ID Endpoint 
+description: Learn how to retrieve lists of users using the get-users-by-id endpoint.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users by ID Endpoint 
+
+The [`GET /api/v2/users/{id}` endpoint](/api/management/v2#!/Users/get_users_by_id) allows you to retrieve a specific user using their Auth0 user ID.
+
+This endpoint is **immediately consistent**, and as such, we recommend that you use this endpoint for:
+
+* User searches run during the authentication process. 
+* User searches run as part of the account linking process.
+
+::: note
+The user ID should be URL encoded since it may contain characters that do not work well in a URL.
+:::
+
+<%= include('./_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users/USER_ID",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }]
+}
+```
+
+### Sample results
+
+```json
+{
+  "email": "john.doe@gmail.com",
+  "email_verified": false,
+  "username": "johndoe",
+  "phone_number": "+199999999999999",
+  "phone_verified": false,
+  "user_id": "usr_5457edea1b8f33391a000004",
+  "created_at": "",
+  "updated_at": "",
+  "identities": [
+    {
+      "connection": "Initial-Connection",
+      "user_id": "5457edea1b8f22891a000004",
+      "provider": "auth0",
+      "isSocial": false
+    }
+  ],
+  "app_metadata": {},
+  "user_metadata": {},
+  "picture": "",
+  "name": "",
+  "nickname": "",
+  "multifactor": [
+    ""
+  ],
+  "last_ip": "",
+  "last_login": "",
+  "logins_count": 0,
+  "blocked": false,
+  "given_name": "",
+  "family_name": ""
+}
+```
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/fr-ca/articles/users/search/v3/get-users-endpoint.md b/fr-ca/articles/users/search/v3/get-users-endpoint.md
new file mode 100644
index 0000000000..034a45a562
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/get-users-endpoint.md
@@ -0,0 +1,141 @@
+---
+title: Retrieve Users with the Get Users Endpoint
+description: Learn how to retrieve lists of users using the get_users endpoint.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users Endpoint 
+
+The [`GET /api/v2/users` endpoint](/api/management/v2#!/Users/get_users) allows you to retrieve a list of users. Using this endpoint, you can:
+
+* Search based on a variety of criteria
+* Select the fields to be returned
+* Sort the returned results
+
+This endpoint is **eventually consistent**, and as such, we recommend that you use this endpoint for back office processes such as changing the display name of an existing user.
+
+<%= include('./_valid-access-token') %>
+
+## Search for users
+
+To search for users, make a `GET` request to the [/api/v2/users endpoint](/api/management/v2#!/Users/get_users). Pass your search query to the `q` parameter and set the `search_engine` parameter to `v3`.
+
+### Example request
+
+For example, to search for a user whose email is exactly `jane@exampleco.com`, use `q=email:"jane@exampleco.com"`:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "email:\"jane@exampleco.com\""
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+For more information on other available parameters, check out the [Management API Explorer documentation](/api/management/v2#!/Users/get_users).
+
+### Sample queries
+
+Below are some examples to show the kinds of queries you can make with the Management API.
+
+Use case | Query
+---------|------
+Search for all users whose name contains "john" | `name:*john*`
+Search all users whose name is exactly "jane" | `name:"jane"`
+Search for all user names starting with "john" | `name:john*`
+Search for user names that start with "jane" and end with "smith" | `name:jane*smith`
+Search for all users whose email is exactly "john@exampleco.com" | `email:"john@exampleco.com"`
+Search for all users whose email is exactly "john@exampleco.com" or "jane@exampleco.com" using `OR` | `email:("john@exampleco.com" OR "jane@exampleco.com")`
+Search for users without verified email | `email_verified:false OR NOT _exists_:email_verified`
+Search for users who have the `user_metadata` field named `full_name` with the value of "John Smith" | `user_metadata.full_name:"John Smith"`
+Search for users from a specific connection | `identities.connection:"google-oauth2"`
+Search for all users that have never logged in | `(NOT _exists_:logins_count OR logins_count:0)`
+Search for all users who logged in before 2018 | `last_login:[* TO 2017-12-31]`
+Search for all users whose last login was in December 2017 | `last_login:{2017-11 TO 2017-12]`, `last_login:[2017-12-01 TO 2017-12-31]`
+Search for all users with logins count >= 100 and <= 200 | `logins_count:[100 TO 200]`
+Search for all users with logins count >= 100 | `logins_count:[100 TO *]`
+Search for all users with logins count > 100 and < 200 | `logins_count:{100 TO 200}`
+Search for all users whose email domain is "exampleco.com" | `email.domain:"exampleco.com"`
+
+### Sample results
+
+Successful calls to the endpoint return a JSON object similar to the following:
+
+```json
+[
+  {
+    "email": "john.doe@gmail.com",
+    "email_verified": false,
+    "username": "johndoe",
+    "phone_number": "+199999999999999",
+    "phone_verified": false,
+    "user_id": "usr_5457edea1b8f33391a000004",
+    "created_at": "",
+    "updated_at": "",
+    "identities": [
+      {
+        "connection": "Initial-Connection",
+        "user_id": "5457edea1b8f22891a000004",
+        "provider": "auth0",
+        "isSocial": false
+      }
+    ],
+    "app_metadata": {},
+    "user_metadata": {},
+    "picture": "",
+    "name": "",
+    "nickname": "",
+    "multifactor": [
+      ""
+    ],
+    "last_ip": "",
+    "last_login": "",
+    "logins_count": 0,
+    "blocked": false,
+    "given_name": "",
+    "family_name": ""
+  }
+]
+```
+
+## Limitations
+
+This endpoint allows you to retrieve a maximum of 1000 users (if the `page` parameter is set; if not set, we return a maximum of 50 users). If your results exceed this threshold, redefine your search. If you need a complete export of all of your users, instead use the [export job](/api/management/v2#!/Jobs/post_users_exports) or the [User Import / Export](/extensions/user-import-export) extension.
+
+If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+
+We do **not** recommend that you use this endpoint for:
+
+* Operations that require immediate consistency. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint) or the [Get Users by ID endpoint](/users/search/v3/get-users-by-id-endpoint).
+* User exports. Instead, use the [User Export endpoint](/users/guides/bulk-user-exports).
+* Operations that require user search as part of authentication processes. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint) or the [Get Users by ID endpoint](/users/search/v3/get-users-by-id-endpoint).
+* Searching for Users for [Account Linking](/users/concepts/overview-user-account-linking) by Email. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint).
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/fr-ca/articles/users/search/v3/index.md b/fr-ca/articles/users/search/v3/index.md
new file mode 100644
index 0000000000..fe39072f3a
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/index.md
@@ -0,0 +1,56 @@
+---
+title: User Search
+description: Understand how the Auth0 Management API search endpoints allow you to search for and retrieve user profiles.
+topics:
+  - users
+  - user-management
+  - user-profile
+  - normalized-user-profile
+  - auth0-user-profiles
+  - search
+contentType:
+  - index
+  - concept
+useCase:
+  - manage-users
+---
+# User Search
+
+User search allows you to retrieve user profile details using Auth0's [Management API](/api/management/v2). Search results can be [viewed](/users/search/v3/view-search-results-by-page), [sorted](/users/search/v3/sort-search-results), and [exported](/users/guides/bulk-user-exports).
+
+::: note
+Most user profile fields are not returned as part of an [ID Token](/tokens/concepts/id-tokens), nor are they included in the response from the [/userinfo endpoint](/api/authentication#get-user-info) of the Authentication API. 
+:::
+
+When searching for users in Auth0, you can use multiple endpoints to search for ID, email, or other criteria:
+
+| Requirement | Endpoint to Use |
+| - | - |
+| Searches involving user attributes | [Get Users](/users/search/v3/get-users-endpoint) |
+| Searches returning multiple users | [Get Users](/users/search/v3/get-users-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Operations requiring [immediate consistency](#search-result-terminology) | [Get Users by ID](/users/search/v3/get-users-by-id-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Actions requiring user search as part of authentication processes | [Get Users by ID](/users/search/v3/get-users-by-id-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Searching for users for account linking by email | [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+
+## Search Result Terminology
+
+We use the following terms to describe the user search results:
+
+* **Eventually consistent**: Search results may not reflect a recently-completed write operation. However, if you repeat your request after a short period of time, the response will return up-to-date data.
+
+* **Immediately consistent**: Search results will reflect the results of all successful write operations, including those that occurred shortly prior to your request.
+
+## Search Best Practices
+
+For info on best practices, see [User Search Best Practices](/best-practices/search-best-practices).
+
+## Keep reading
+
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+
diff --git a/fr-ca/articles/users/search/v3/migrate-search-v2-v3.md b/fr-ca/articles/users/search/v3/migrate-search-v2-v3.md
new file mode 100644
index 0000000000..7496f010a4
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/migrate-search-v2-v3.md
@@ -0,0 +1,87 @@
+---
+title: Migrate from Search v2 to v3
+description: Learn how to migrate from Auth0 Search v2 to v3.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Migrate from Search v2 to v3
+
+User search v2 has reached its end of life as of **June 30, 2019**. We highly recommend migrating user search functionality to search engine v3 (`search_engine=v3`) as soon as possible.
+
+## Migration considerations
+
+Before you start migrating, there are a few things you should know:
+
+* To ensure that your queries are using search engine v3 prior to v2 becoming unavailable, you must update all your calls to the `GET /api/v2/users` endpoint to include the `search_engine=v3` parameter. This will enable you to see whether any queries need to be updated, so that you will not experience downtime when v2 becomes unavailable.
+* If you are performing user search operations through any of the [impacted SDKs](#impacted-sdks), you must also pass the `search_engine=v3` parameter as outlined above.
+* Search values for the normalized user fields (`email`, `name`, `given_name`, `family_name`, and `nickname`) are case insensitive. All other fields (including all `app_metadata`/`user_metadata` fields) are case sensitive.
+* v3 limits the number of users you can retrieve to 1000. If you are reaching this limit, we recommend that you redefine your search query to obtain more granular results. If you need a list of more than 1000 users at a given time, we recommend that you use the [export job](/api/management/v2#!/Jobs/post_users_exports) API endpoint or [User Import / Export extension](/extensions/user-import-export) instead.
+* Range and wildcard searches are not available on `app_metadata`/`user_metadata` fields. See [searchable fields](/users/search/v3/query-syntax#searchable-fields).
+* User fields are not tokenized like in v2, so `user_id:auth0` will not match a `user_id` with value `auth0|12345`, instead, use `user_id:auth0*`. See [wildcards](/users/search/v3/query-syntax#wildcards) and [exact matching](/users/search/v3/query-syntax#exact-match).
+* Wildcards can be used for prefix matching, for example `name:j*`. For other uses of wildcards (e.g. suffix matching), literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+* The `.raw` field extension is no longer supported and must be removed. In v3, fields match the whole value that is provided and are not tokenized as they were in v2 without the `.raw` suffix.
+* The `connection` field is not supported in v3. You should use its alias `identities.connection` instead. 
+
+## Queries to migrate
+
+Use case | v2 | v3
+---------|----|---
+Search by date | `updated_at:>=2018-01-15` | `updated_at:[2018-01-15 TO *]`
+Search by date | `updated_at:>2018-01-15` | `updated_at:{2018-01-15 TO *]`
+Search by date | `updated_at:<=2018-01-15` | `updated_at:[* TO 2018-01-15]`
+Search by date | `updated_at:<2018-01-15` | `updated_at:[* TO 2018-01-15}`
+Search by date | `last_login:<=2017-12` | `last_login:[* TO 2017-12]`
+String exact match | `name.raw:"john richard doe"` | `name:"john richard doe"`
+Phrase contains a word | `name:"richard"`, `name:richard` | `name:*richard*`
+Phrase contains a word (with less than 3 characters) | `name:*ri`,`name:*a`, `name:*ab*` | _(not supported)_
+
+## Impacted SDKs
+
+The following SDKs make use of the User Search engine. If you are using them, make sure you are using the versions listed below (or a later version), and pass the `search_engine=v3` parameter when performing user search operations.
+
+SDK | Version with support for v3 | Impacted methods | Considerations
+----|-----------------------------|------------------|---------------
+[Auth0 Java](https://github.com/auth0/auth0-java) | 1.8.0 | com.auth0.client.mgmt.UsersEntity.list | Provide a `UserFilter` with `withSearchEngine("v3")`
+[Auth0 Python](https://github.com/auth0/auth0-python) | 3.0.0 | management.Users.list | Provide the parameter `search_engine='v3'`
+[Auth0 Node](https://github.com/auth0/node-auth0) | 2.0.0 | UsersManager.getAll, ManagementClient.getUsers | Provide the parameter `search_engine:'v3'`
+[Auth0 .NET](https://github.com/auth0/auth0.net) | 3.0.0 or 4.0.0 | Auth0.ManagementApi.IUsersClient.GetAllAsync | Provide a `GetUsersRequest` object with `SearchEngine` = `"v3"`
+[Auth0 PHP](https://github.com/auth0/auth0-php) | 5.2.0 | Auth0.SDK.API.Management.Users.getAll | Provide the parameter `'search_engine' => 'v3'`
+[Auth0 Ruby](https://github.com/auth0/ruby-auth0) | 4.5.0 | Auth0.Api.V2.Users.users | Provide the parameter `search_engine: 'v3'`
+
+## Impacted Extensions
+
+The following Extensions make use of the User Search engine. If you have them installed, make sure you are using the versions listed below (or a later version).
+
+Extension | Version with support for v3 | Considerations
+----------|-----------------------------|---------------
+[Authorization Extension](/extensions/authorization-extension/v2) | 2.5.0 | If you are using an earlier version, you need to manually update the extension from the [Extensions](https://manage.auth0.com/#/extensions) page.
+[Delegated Administration](/extensions/delegated-admin/v3) | 3.1 | If you are using an earlier version, you need to manually update the extension from the [Extensions](https://manage.auth0.com/#/extensions) page. The `SEARCH_ENGINE` configuration setting no longer exists in 3.1, because only User Search v3 is available.
+
+## Leverage your tenant logs to find usage of User Search v2
+
+You can leverage the [logs](/logs) in the [Dashboard](${manage_url}/#/logs) to find calls to the `/api/v2/users` endpoint that use the User Search v2 engine, including calls performed by SDKs. Those logs will help you identify where code changes might be needed in your applications.
+
+Use the following query to retrieve all the logs related to User Search v2: `type:w AND description:*search_engine*`. The logs will provide additional information in the description field, in the following cases:
+
+- Queries that might produce different results in v3
+- Queries with syntax incompatible with v3
+- Queries that do not meet the paging requirements of v3
+
+If no additional details are specified in the log entries, it's likely that your queries are compatible with v3. Our recommendation, however, is still that you test the queries before deploying your changes to production.
+
+::: note
+Please note that only one log of the same type will be generated within 60 minutes. This means that even though you may be doing multiple calls to the User Search endpoint, you will only see one log of each type per hour.
+:::
+
+## Keep reading
+
+* [User Search Overview](/users/search)
+* [Authorization Extension](/extensions/authorization-extension/v2)
+* [Delegated Administration](/extensions/delegated-admin/v3)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/fr-ca/articles/users/search/v3/query-syntax.md b/fr-ca/articles/users/search/v3/query-syntax.md
new file mode 100644
index 0000000000..ce0d124d4b
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/query-syntax.md
@@ -0,0 +1,166 @@
+---
+title: User Search Query Syntax
+description: Describes Auth0's user search query string syntax.
+toc: true
+topics:
+  - users
+  - user-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-users
+---
+
+# User Search Query Syntax
+
+When searching for users, you can create queries using [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) to refine your search.
+
+The query string is parsed into a series of terms and operators:
+
+* A term can be a single word such as `jane` or `smith`.
+* A term can be a phrase surrounded by double quotes (`"green apple"`), which will match all words in the phrase in the same order.
+* A term without a field name will not match text in the [user metadata](/users/concepts/overview-user-metadata) fields.
+* Multiple terms can be grouped together with parentheses to form sub-queries.
+* Search values for the normalized user fields (`email`, `name`, `given_name`, `family_name`, and `nickname`) are case insensitive. All other fields (including all `app_metadata`/`user_metadata` fields) are case sensitive.
+* Operators (`AND`, `OR`, `NOT`) work on all normalized user fields and root metadata fields.
+
+## Searchable fields
+
+You can search for users using all the [normalized user profile fields](/users/normalized/auth0/normalized-user-profile-schema) and the fields below:
+
+Search Field | Data Type | Description
+------|------|-----
+`phone_number` | text | The user's phone number. Only valid for users with SMS connections.
+`phone_verified` | boolean | The `true/false` value indicating whether the user's phone number has been verified. Only valid for users with SMS connections.
+`logins_count` | integer | The number of times the user has logged in. If a user is blocked and logs in, the blocked session is counted in `logins_count` and updates the `last_login` value.
+`created_at` | date time | The timestamp of when the user profile was first created.
+`updated_at` | date time | The timestamp of when the user's profile was last updated/modified.
+`last_login` | date time | The timestamp of when the user last logged in. In case you are this property from inside a [Rule](/rules) using the `user` object, its value will be the one associated with the login that triggered the rule (since rules execute after the actual login).
+`last_ip` | text (valid IP address) | The IP address associated with the user's last login.
+`blocked` | boolean | The `true` or `false` value indicating if the user has been blocked. Note: `true` *only* brings back users who are blocked via the Admin Dashboard and Management API; it does not bring back users blocked by brute force anomaly detection.
+`email.domain` | text | The domain part of the user's email.
+
+[Metadata](/users/concepts/overview-user-metadata) fields may be used with:
+    
+* Boolean
+* Numeric: (integer or double)
+* Text
+* Objects: In order to search a scalar value nested in another object, use the path to the field. For example, `app_metadata.subscription.plan:"gold"`
+* Arrays: In order to search fields in objects nested arrays, use the path to the field and ignore the array level. For example, `user_metadata.addresses.city:"Paris"`
+
+Range and wildcard searches are not available on user metadata fields.
+
+## Exact match
+
+To find exact matches, use double quotes: `name:"jane smith"`.
+
+For example, to find users with the name `jane smith`, use `q=name:"jane smith"`:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "name:\"jane smith\""
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Wildcards
+
+Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters. 
+
+Here are some examples: 
+
+* `name:john*` returns all users with `john` at the beginning of their names. 
+
+* `name:j*` returns all users with `j` at the beginning of their names.
+
+* `q=name:john*` returns all users whose names start with `john`.
+
+* For suffix matching, literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+
+### Sample query with wildcards
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "name:john*"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Ranges
+
+You can use ranges in your user search queries. 
+
+* For inclusive ranges use square brackets: `[min TO max]`.
+
+* For exclusive ranges use curly brackets: `{min TO max}`.
+
+* Curly and square brackets can be combined in the same range expression: `logins_count:[100 TO 200}`. 
+
+* Use ranges in combination with wildcards. For example, to find all users with more than 100 logins, use `q=logins_count:{100 TO *]`.
+
+### Sample query with ranges
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:{100 TO *]"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Limitation
+
+Range and wildcard searches are not available on user metadata fields.
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Search Best Practices](/best-practices/search-best-practices)
diff --git a/fr-ca/articles/users/search/v3/sort-search-results.md b/fr-ca/articles/users/search/v3/sort-search-results.md
new file mode 100644
index 0000000000..b62fd85aeb
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/sort-search-results.md
@@ -0,0 +1,52 @@
+---
+title: Sort Search Results
+description: Learn how to sort search results by passing a field:order value to the sort parameter.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Sort Search Results
+
+To sort user search results, pass a `field:order` value to the `sort` parameter when making your request. The `field` is the name of the field to sort by, while order can be set to `1` for ascending order and `-1` for descending. 
+
+::: note
+Sorting by `app_metadata` or `user_metadata` is not supported.
+:::
+
+## Sample request
+
+For example, to sort users in ascending order by the `created_at` field you can pass the value `created_at:1` to the `sort` parameter:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:[100 TO 200]"
+        },
+        {
+          "name": "sort",
+          "value": "created_at:1"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Keep reading
+
+For more information on `sort` and other parameters, see the [Management API Explorer](/api/management/v2#!/Users/get_users) documentation.
diff --git a/fr-ca/articles/users/search/v3/view-search-results-by-page.md b/fr-ca/articles/users/search/v3/view-search-results-by-page.md
new file mode 100644
index 0000000000..a097227034
--- /dev/null
+++ b/fr-ca/articles/users/search/v3/view-search-results-by-page.md
@@ -0,0 +1,89 @@
+---
+title: View Search Results by Page
+description: Learn how to view search results page by page and include totals.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# View Search Results by Page
+
+To page the user search results, use the `page`, `per_page`, and `include_totals` parameters at your request.
+
+Parameter | Description
+----------|------------
+`page` | The page number, zero based. When this is not set, we return a maximum of 50 records, regardless of how many records exist.
+`per_page` | The amount of users per page.
+`include_totals` | Set to `true` to include a query summary as part of the result.
+
+## Sample request
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:[100 TO 200]"
+        },
+        {
+          "name": "page",
+          "value": "2"
+        },
+        {
+          "name": "per_page",
+          "value": "10"
+        },
+        {
+          "name": "include_totals",
+          "value": "true"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Sample response
+
+A sample response body for the values set in the above sample request is as follows:
+
+```json
+{
+    "start": 20,
+    "limit": 10,
+    "length": 10,
+    "users": [
+        {
+            ...
+        }
+    ],
+    "total": 79
+}
+```
+
+Parameter | Description
+----------|------------
+`start`   | Record position from which the page starts.
+`limit`   | Maximum number of records that can be shown on the page.
+`length`  | Number of records shown on the page.
+`total`   | Total number of records found.
+
+## Limitation
+
+Auth0 limits the total number of users you can retrieve to 1000 (for example, 100 users per page for 10 pages). When the `page` parameter is not set, we return a maximum of 50 records, regardless of how many records exist.
+
+## Keep reading
+
+For more information on the `page`, `per_page` and other parameters, see the [Management API Explorer](/api/management/v2#!/Users/get_users) documentation.
diff --git a/fr-ca/articles/videos/get-started/01-architecture-your-tenant.md b/fr-ca/articles/videos/get-started/01-architecture-your-tenant.md
new file mode 100644
index 0000000000..a7b9bbcbab
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/01-architecture-your-tenant.md
@@ -0,0 +1,161 @@
+---
+description: What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
+classes: video-page
+public: false 
+---
+
+# Architect: Your Tenant
+
+Learn what an Auth0 tenant is and how to configure it in the Auth0 Dashboard. Understand why you may want more than one tenant if you have different user communities, and also how you can use more than one tenant to support your Software Development Life Cycle (SDLC). Understand the importance of tenant naming and custom domain usage best practices. Also learn how to set up additional tenant administrators and how to associate tenants with your Auth0 account.
+
+
    
+
+## Transcript
+  
+
    
+  Introduction
+  
+  In this video, we will talk about what an Auth0 tenant is, and show you how to configure it in the Auth0 Dashboard. We will also briefly explain why you may want to use more than one tenant if you have different user communities, and also how you can use more than one tenant in support of your Software Development Life Cycle. We’ll also describe the importance of tenant naming, use of custom domains, provisioning additional tenant admins, and how to associate tenants with your Auth0 account. 
+
+  Once you create your account in Auth0, you will be asked to create a Tenant. This is a logical isolation unit. The term tenant is borrowed from the phrase "software multi-tenancy" and refers to an architecture where a single instance of the software serves multiple tenants. No tenant can access the instance of another tenant, even though the software might be running on the same machine (hence the logical isolation).
+
+  When it comes to figuring out how to define your Auth0 tenants and accounts as part of your application integration, the value of investing time in the architectural “landscape” up front will pay dividends in the long run, and there are a number of things you’ll want to consider. 
+
+  It’s important to understand how your applications need to function within your infrastructure, and this will help you understand how to configure your tenants to accomplish your goals. How your Auth0 tenants are configured—the architecture of your Auth0 deployment—will form the basis for the grouping of your Auth0 assets to leverage features such as Single Sign On, centralized user profile management, and consolidated billing capabilities. 
+
+  The number of tenants you create can grow quickly, especially if you have different user communities and different phases for development, testing, and production. So, for ease of maintenance and simple organization, it is really important to consider exactly what you will need. 
+
+  For example, it’s not uncommon for companies to have identity requirements that address multiple user communities such as customers, partners, and employees. There may also be other groups within your organization that are working with Auth0; it’s not uncommon for our customers to have disparate departments that serve different user communities. Identifying these early will potentially influence your choices, and doing so could mitigate decisions that might prove costly later on.
+
+  So you will need to decide how many different production tenants you will require. Most companies only need a single production tenant, but if you have a set of applications for just employees, you may want a separate tenant for that. In some situations, you may also need different production tenants for different customer user communities. 
+
+  Another reason you would want to create multiple tenants is to support your Software Development Life Cycle. Auth0 can fit into your process by allowing you to have a separate tenant for each phase—such as one for development, one for testing, and one for production. Even if you don’t use an SDLC methodology, you will most likely want to create at least two tenants: one for development and one for production. 
+
+  You may want to name one tenant “company-dev” to serve as a shared environment where your development work occurs, and name another tenant “company-qa” for testing your Auth0 integration. You can then name a third tenant “company-prod” to serve as your production tenant. 
+
+  You can also create tenants to serve as sandboxes to test potential changes, like different deployment scripts, without compromising your environment. Auth0 lets you create as many free tenants as you like, but you may be limited for the number of tenants where all paid features are enabled. You can have up to three tenants where all features are available.
+
+  It’s also important to consider exactly what you will name your tenants. The ultimate goal is to end up with one or more production tenants that are branded exactly the way you want them to appear to your users. Tenant naming patterns are very important, so it’s good to plan the tenant names in advance because you won’t be able to change them once you create them, or use them again if you delete them.
+
    
+
+
    
+  Configure your tenant
+
+  Now let’s see how easy it is to configure your tenants. Everything you need to configure your Auth0 tenant is available via the Auth0 Dashboard. Here you’ll determine how you’ll use Auth0 features and where assets like applications, connections, and user profiles will be stored. 
+
+  We’ll talk about these in other videos, but for now, we’re going to concentrate on Tenant Settings, accessible via the drop-down menu by going to the upper-right corner of the Dashboard and clicking on your tenant name. From this menu, you can also create additional tenants at any time by clicking on Create Tenant.
+
    
+
+
    
+  General settings
+
+   Starting with the General settings tab, you can specify your company name, a path to your company logo, and your company’s support email address and support URL. This is the information that is shown in the default error page that appears to your users, so they can contact your support if they have an issue. You may also want to consider creating a custom error page and configure Auth0 to use that instead. 
+
+  Out-of-the-box, client-facing URLs are Auth0 branded; however, we recommend using the Auth0 custom domain capability to provide a consistent corporate identity and to also address potential user confidence concerns before they arise. Your company name as part of the URL, for example, will support your brand and should tell your users that they can trust that they are in the right place to enter their identity information. It’s also harder to phish your domain if you have a Custom Domain (a.k.a. vanity) URL because the phisher also has to create one to mimic yours. A centralized domain for authentication across multiple product or service brands so users see a consistent interface is also important. And keep in mind that some browsers make it harder to communicate in an iFrame if you don’t have a shared domain.
+
+  Having more than one Auth0 Dashboard administrator is a good idea, and periodically reviewing the list of Auth0 Dashboard administrators to see that the right people have access to your Auth0 tenants will help you make sure that each person has a legitimate need for admin access. You should make sure that former employees no longer have access. We also recommend that you enable multi-factor authentication for all your admins for added security. Having more than one admin can alleviate the burden of Auth0 tenant administration, but if you only have one admin they may get locked out if they lose their phone. If you have more than one admin, however, another can temporarily disable MFA for the admin who lost their phone.
+
    
+
+
    
+  Advanced settings
+ 
+  There are also some advanced tenant settings that you can configure for your tenant. There are a couple of things you need to consider when you configure these items. 
+
+  Logout is the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. This is usually achieved via the provision of some “logout” option on the UI. There are multiple types of sessions that could be created when a user logs in. For example, a local application session, Auth0 session, and/or a third-party Identity Provider session. You’ll need to determine which should be terminated when the user clicks on any “logout” option. You can configure the application to have a logout redirect URL.
+
+  Session timeout settings allow you to specify when the SSO cookie times out. The value you set is the login session lifetime which is how long the session will stay valid, measured in minutes. The default setting is set for 10,080 minutes or 7 days. 
+
+  Your contractual agreement with Auth0 should cover all the tenants you want to use. Make sure all your tenants are associated with your company account. If you have developers who want to create their own sandboxes for testing, make sure the tenants are associated with your account so they have the same permissions and Auth0 features available too. 
+
+  If you need to add a tenant to your account, contact the Auth0 Support Center at  Specify your production tenant so you can get higher rate limits than non-production tenants. Only one tenant per subscription can be set as the production tenant. 
+
    
+
+
    
+  Summary
+  
+  So, to summarize, we described what an Auth0 tenant is, how to configure it, and why you may need more than one tenant. We also described the importance of tenant naming, and how to associate tenants with your Auth0 accounts to save money and leverage Auth0 features across your organization.
+
+  In the next video, we’ll talk about provisioning your users and configuring user stores, and in a future video, we’ll talk more about Custom Domains too.
+
    
+
+## Up next
+
+
      
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them.  
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0.  
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
diff --git a/fr-ca/articles/videos/get-started/02-provision-user-stores.md b/fr-ca/articles/videos/get-started/02-provision-user-stores.md
new file mode 100644
index 0000000000..71769b3b55
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/02-provision-user-stores.md
@@ -0,0 +1,192 @@
+---
+description: How user profiles are provisioned within an Auth0 tenant.
+classes: video-page
+public: false
+---
+
+# Provision: User Stores
+
+Learn how user profiles are provisioned within an Auth0 tenant. Users can come from a multitude of places: directly through creating an account using self sign-up, indirectly through using their favorite trusted social media platform, or collectively through a trusted enterprise directory. Auth0 makes it simple to quickly connect your tenant to multiple types of user stores. We group these users stores into three categories: database, social, and enterprise.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, we will show you how user profiles are provisioned within an Auth0 tenant. Users can come from a multitude of places: directly through creating an account using self sign up, indirectly through using their favorite trusted social media platform, or collectively through a trusted enterprise directory.
+
+  Auth0 makes it simple to quickly connect your tenant to multiple types of user stores. We group these users stores into three categories: database, social, and enterprise.
+
+  * Database connections solve many traditional username and password based scenarios. By default, Auth0 offers identity storage out of the box that can be leveraged to manage the burden of storing user credentials safely and securely. Auth0 is also capable of providing proxies to existing legacy identity stores.
+
+  * Social connections give users a simplified registration and login experience by using an existing authentication from a social network provider like Facebook, Twitter, or Google. Not only are popular social networks supported but close to 40 business, professional and industry-based connections are available. In fact, any OAuth2-conformant identity provider can be configured as a user store.
+
+  * Finally, Enterprise connections allow business customers or partners to manage their own users within an Auth0 tenant. This is a very powerful feature that allows any set of businesses to collaborate in a secure way. 
+
    
+
+
    
+  User store connections in the Dashboard
+
+  Auth0 can be configured for any number and combination of connections to provide user identity for applications. Auth0 sits between the applications and their sources of users, which adds a level of abstraction so the application is isolated from any changes to and idiosyncrasies of each source's implementation.
+
+  Now let’s dive a little deeper and discover how to establish each type of user store connection directly in the Auth0 Dashboard. This can be accomplished independently of any modifications or implementation within an application.
+
+  First, let’s take a look at how to jump right in and authenticate users via username and password using infrastructure provided by Auth0. Out-of-the-box, each Auth0 tenant is preconfigured with an authentication database connection. This connection provides the best performance for the authentication process since all data is stored in Auth0.
+
+  The Auth0-hosted database is highly secure. Passwords are never stored or logged in plain text but are hashed with bcrypt. Varying levels of password security requirements can also be enforced.
+
+  The default database can be found on the Auth0 Dashboard for your tenant. From the Dashboard, click the **Connections** link in the left-hand navigation menu which will expand a list of the available connection types. Click **Database** and a list of all database connections will be displayed.
+
+  As you can see, a database connection named **Username-Password-Authentication** is already available. By clicking the name of the connection we are taken to the configuration section for this database.
+
+  The database configuration is split into a series of tabs: **Settings**, **Password Policy**, **Custom Database**, **Applications**, and **Try Connection**.
+
+  By default, database connections authenticate users using their email and password. If you require the use of usernames, it can be enabled on the settings tab as well as setting minimum and maximum lengths for the username.
+
+  There is also the ability to disable new user sign ups. This prevents new accounts from being created in the database by user-facing dialogs. Users can still be created using the Management API or directly in the Dashboard. 
+
+  There is also a way to completely delete this database. Be careful though, as is mentioned, this is a destructive operation that is not reversible.
+
    
+
+
    
+  Passwords
+
+  Finally, we see an option to import users to Auth0. I will cover how this is used in a future video on migrations.
+
+  On the password policy tab are several settings that allow you to align this database with your company password policy. Even if you do not have a password policy currently, it is worth considering each of the options available on this tab.
+
+  By default, Auth0 has configured the password strength to a quality of Good which at a minimum requires a length of 8 characters containing both upper and lower case letters, numbers and special characters. For convenience, a tester is available that allows you to test the user experience of these settings.
+
+  The password history policy, when enabled, will prevent users from reusing passwords they have previously used. Up to 24 previous passwords can be saved in the history.
+
+  Enabling the password dictionary prevents the use of 10,000 of the most common passwords. There is even an option to add custom values to this list that might not be obvious like company names or a list of conference rooms in your building.
+
+  The personal data option ensures that no data contained in the user's profile is used in the password as well.
+
    
+
+
    
+  Custom Database
+
+  The **Custom Database** tab allows you to configure this database connection to connect to an external database that is not managed by Auth0. This is useful for organizations who have data retention policies that do not allow external storage of data. For information on configuring a custom database connection, see the documentation linked below.
+
+  I will talk more about custom database connections in a future video.
+
    
+
+
    
+  Applications
+
+  The **Applications** tab show us a list of applications that are currently using this database connection. Enabling or disabling an apps ability to use this connection is as simple a flipping a switch.
+
    
+
+
    
+  Try connection
+
+  Finally, the **Try Connection** tab will allow us to try out the database connection in a special test application configured just for this connection.
+
+  Using this test application, we can verify all of our settings work as expected. Successfully authenticating will take us to a success page showing the user profile data that will be provided to applications using this database connection.
+
+  Of course, from the database list, we can easily create a new database connection. You are free to create as many database connections as you need to support all of your applications and users.
+
    
+
+
    
+  Summary
+
+  In a future video, I will show you two powerful ways to add your existing users using either bulk imports or a more gradual migration using custom database connections.
+
+  Next, let’s look at how to connect applications to social login providers. Auth0 offers simple integrations with dozens of popular social login providers. Additionally, you can add any OAuth2 Authorization Server you need.
+
+  Social logins bring single sign-on semantics to end users. Using existing login information from a social network provider like Facebook, Twitter, or Google, the user can sign into an application instead of creating a new account specifically for that application. This simplifies registrations and logins for end users.
+
+  Social login connections can be found on the Auth0 Dashboard. From the Dashboard, click the **Connections** link in the left-hand navigation menu which will expand a list of the available connection types. Click **Social** and a list of all available social connections will be displayed.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous video
+
+
      
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+   
      • 
+
+
    
+
diff --git a/fr-ca/articles/videos/get-started/03-provision-import-users.md b/fr-ca/articles/videos/get-started/03-provision-import-users.md
new file mode 100644
index 0000000000..f81cf4b4a5
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/03-provision-import-users.md
@@ -0,0 +1,200 @@
+---
+description: How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
+classes: video-page
+public: false
+---
+
+# Provision: Import Users
+
+Learn how Auth0 allows you to move your existing users to an Auth0 user store and why you may want to use a combination of both automatic and bulk migration methods. Learn why it's a good idea to have an API between the cloud and your legacy database and how custom database scripts work.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  Customers building new systems can easily take advantage of various types of user stores Auth0 supports to authenticate users. Now we will take a look at how Auth0 helps you import your existing users two ways: Automatic Migration and Bulk Migration. In this video we will show you the advantages to using both methods together and how to get the results you want.
+
+  We’ve found that most customers don’t want to force their users to reset their passwords just because they chose to implement Auth0, so we’ve provided tools to help you move your users to a custom database as they authenticate over time or, depending on the algorithm you have used to hash the user’s passwords, you can bulk import the password hashes with the users. 
+
+  Automatic migrations give your users a seamless migration experience that doesn’t require them to reset their passwords. You also benefit from only migrating active users, helping you to clean up your user data in the process. 
+
+  Bulk migrations have the advantage of getting the migration done at the beginning in one effort and allow you to turn off your legacy system and remove legacy code sooner. If you are using a particular hashing algorithm and technique, you can even bulk migrate the passwords and not require a password reset.
+
    
+
+
    
+  Auth0 Database Connections in the Dashboard
+
+  Both Automatic and Bulk migration are supported using Auth0 Database Connections. After you create a database connection in the Dashboard, you enable user migration from that legacy database and create custom scripts to determine how the migration happens.
+
+  First, you need to set up a custom database connection. Create a new database connection in the **Connections > Database** section of the Dashboard.
+
+  Connect the database to the application. Navigate to the **Applications** tab of your database settings, under the **Applications Using This Connection** heading you can enable the database connection for each application.
+
+  On the **Custom Database** page, enable the **Use my own database** option.
+
+  On the **Settings** page for your database, enable the **Import Users to Auth0** option.
+
    
+
+
    
+  Create API Front End to Your Database 
+
+  Next, if you don’t have an API already, we recommend that you create a simple API in front of your legacy database instead of allowing access directly from Auth0.
+
+  Unless you have a private instance or enterprise cloud deployment, you probably don’t want to expose your entire database interface to the Auth0 IPs because those are shared IP addresses. Though you can whitelist Auth0 IPs, those IPs are shared in the cloud environment. 
+
+  In compliance with the principle of least privilege, Auth0 recommends that you protect your database from too many actors directly talking directly to it. The easiest way to do that is to create a simple API endpoint that each script within Auth0 can call. Protect the API using an access token.  This access token can be created using the client-credentials grant. This grant type is for us in machine-to-machine contexts, like this one, where you don’t have the context of a particular user. 
+
    
+
+
    
+  Custom Database Script Templates
+
+  Next, we’ll show you how to use Auth0’s custom database script templates to perform certain actions on the user data stored in the database. 
+
+  The script templates are pre-populated in the Dashboard script editor. The scripts cover Get User and Login.
+
+  Here are some best practices that we’ve found work for most customers:
+
+  * Set a `user_id` on the returned user profile that is consistent for the same user every time. This is important because if you set a random `user_id` in the `get_user` script, then call forgot password and change the password, the user will get duplicated every time they log in. In the non-migration scenario, if you set a random `user_id` you can end up with duplicate users for every login.
+
+  * If using a username, ensure that you aren't returning the same email address for two different users in the `get_user` or `login` script. Auth0 will produce an error if you do this, but it is better to catch it in the script itself.
+
+  * If setting `app_metadata`, call it `metadata` in the script. To support backwards compatibility, `app_metadata` is called `metadata` in `custom DB` scripts. If you don't use `metadata` in the script, you will get an error where `app_metadata` will work but if you use the API to merge `app_metadata` with a user, it will appear as if all of your metadata was lost. NOTE: `user_metadata` is not affected by this and can simply be called `user_metadata`.
+
+  * Ensure you restrict access to that audience with a rule. As with any API that you create, if you create it solely for client credentials, then you will want to restrict access to the API in a rule. By default, Auth0 gives you a token for any API if you authenticate successfully and include the audience. Someone could intercept the redirect to authorize and add the audience to your legacy database API. If you don’t block this in a rule, they could get an access token.  You will also want to update the API to expect the subject claim of the token to end in `@clients`.
+
+  * Make sure the `login` script and the `get_user` script both return the same user profile. Because of the two different flows (logging in, or using forgot password), if the `get_user` and `login` scripts return different user profiles, then depending on how a user migrates (either by logging in directly, or using the forgot password flow) they will end up with different profile information in Auth0.
+
+  * If setting `app_metadata` or `user_metadata`, use a rule to fetch the metadata if it is missing. The metadata is not migrated until `https://YOUR_TENANT.auth0.com/login/callback` is called. However, the user credentials are migrated during the post to `https://YOUR_TENANT.auth0.com/usernamepassword/login`. 
+
+    This means that if the flow is interrupted after the username password/login, but before login/callback, then they will have a user in the Auth0 database, but their app and user metadata are lost. It is really important, therefore, to create a rule that looks a lot like your `get_user` script to fetch the profile if app and user metadata are blank. This should only execute once per user at most and usually never.
+
+  * Use a rule to mark users as migrated. This is not a hard requirement, but it does protect against one scenario in which a user changes their email address, then changes it back to the original email address. A rule should call out to the legacy database to mark the user as being migrated in the original database so that `get_user` can return false.
+
    
+
+
    
+  Bulk Importing Users
+
+  Next, let’s look at bulk importing users directly into the Auth0 database. It’s important to note that when you use Bulk Migration, you *can* migrate the user’s password if it was hashed using bcrypt with 10 salt rounds, otherwise you will have to force your users to reset their passwords.
+
+  Before you launch the import users job, a database to which the users will be imported must already exist and it must be enabled for at least one application in your tenant. 
+
+  You can then import a file containing your user data with our Management API. The file must have an array with the users' information in JSON format. You can use the `POST /api/v2/jobs/users/post_users_importsendpoint` to populate a database connection with the user information in the file. 
+
+  The users import endpoint requires that your POST request use the `multipart/form-data` encoding type. See our documentation for a list of the parameters that must be part of the request. 
+
+  There are some rate and file size limitations for bulk imports: 
+
+  * Calls to the Management API are subject to rate limiting. The rate limits for this API differ depending on whether your tenant is free or paid, production or not. 
+    * For all free and non-production tenants, you can have up to 2 requests per second and bursts up to 10 requests.
+    * For paid tenants, you can have up to 15 requests per second and bursts up to 50 requests. 
+    * The rate limits include calls made via Auth0 Rules. Note, that the limit is set by tenant and not by endpoint. For additional information about these endpoints, please consult the Management API explorer.
+  * There is also an import JSON file size limitation of 500 kilobytes.  If your user database would result in a file larger than this, you will need to break the users up into chunks that keep each file smaller than 500 KB.
+
+  Auth0 does provide an User Import/Export Extension however, we recommend that you use the Management API Bulk Migration for all but the most simple cases.
+
+  After you’ve migrated your users to the Auth0 database, you can use the **List** or **Search** Management API endpoint to make sure the users are there. You can also view the users list in the Dashboard.
+
+  We’ve found that customers often opt for a two-phased approach to user migration, employing Automatic Migration first in order to migrate as many active users as possible, and then turning off Automatic Migration and performing Bulk Migration for the users that remain.
+
    
+
+
    
+  Summary
+  
+  After you have verified the migration of the final set of users, you can set the `login` and `get_user` scripts to simply `“return callback()”` in the Dashboard. Keep **Import Users to Auth0** enabled on the Settings page so that your users will be directed to the new database workflow.
+
+  This gives your active users a nice experience by not forcing them to reset their passwords, even if your hashing algorithm is not compatible with bulk import, while still allowing you to decommission the legacy identity store.
+
+  In the next video, we will take a look at user authentication.
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/04_01-authenticate-how-it-works.md b/fr-ca/articles/videos/get-started/04_01-authenticate-how-it-works.md
new file mode 100644
index 0000000000..8aa2ee856c
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/04_01-authenticate-how-it-works.md
@@ -0,0 +1,161 @@
+---
+description: How user authentication works and various ways to accomplish it with Auth0.
+classes: video-page
+public: false
+---
+
+# Authenticate: How It Works
+
+Learn about the difference between authentication, authorization, and access control. Understand when and why you might use each type of authentication method: first factors, second factors, and multi-factor. Learn about the OpenID Connect (OIDC) authentication protocol.   
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  Before you can provide services to your users through your applications, you need to identify who they are, and that process is called *user authentication*. 
+
+  In this video, we will show you a few ways to go about this. For example, you can authenticate users via their social media accounts or with their usernames and passwords. You can add an additional level of certainty about their identities with a second authentication factor; this is called *Multi-factor Authentication* (MFA).
+
+  Before you start, think about security and user experience, if you want to offer multiple primary authentication methods, and if you want to add multi-factor authentication. Planning how you want the authentication process to work before you do the steps required to implement the actual authentication is critical because it will determine how you configure your application integration.
+
+  One way to make sure you’ve considered all your authentication requirements is to adopt an iterative release style. For example, you may have three or four applications you need to integrate and, instead of tackling them all at once, you can make a series of iterations, tackling one application at a time. This way your teams can benefit from the experience, and you can leverage this approach to help increase velocity with each iteration.
+
    
+
+
    
+  Authentication, authorization, and access control
+
+  It’s important to distinguish between Authentication, Authorization, and Access Control. Your Auth0 tenant, the Authorization Server, is responsible for Authentication and some or all of Authorization. Access Control is the responsibility of the API or Application itself because access control is almost always contextual.
+
+  So, to summarize:  
+  * **Authentication** is the process of determining if the user is who they say they are
+  * **Authorization** is declaring what that user is allowed to do in the system
+  * **Access Control** is limiting a user to only perform actions they are allowed to do based on a combination of their identity, their authorization information, and their consent.
+
+  In this video, we are only going to focus on authentication, we will address the other options such as MFA in a separate video. There are different types of connections you can make in the Dashboard that will enable authentication. 
+
    
+
+
    
+  Social connections
+
+  You can choose from among many social connections including the most commonly used ones like Google and Facebook. Choose connections that your users will most frequently have accounts with. 
+
+  If you have more than one application, you will almost certainly want to have Single Sign-On between those applications. This is one of the easiest ways to give your users a good user experience without compromising on security.
+
+  As you may already know, the OpenID Connect specification—or OIDC—is the most widely used industry-standard authentication specification when it comes to customer-facing applications. It is intended as a way to provide SSO between applications. OIDC is based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens—or JWT—that you obtain using flows conforming to the OAuth 2.0 specifications. When a user signs in using their Google account, then they’ve used OIDC.
+
+  We’ve made it easy to enable this type of authentication with Universal Login. The way this works is you delegate the authentication of a user by redirecting them to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application.
+
+  If each of your applications does this then Auth0 remembers whether the user has already logged in and sends them back to the new application without requiring them to re-enter their credentials. This is how we accomplish Single Sign On.
+
+  The next step is to figure out how to do this in your application. To help you out we’ve provided some guides to help you get started.
+
    
+
+
    
+  Auth0 Quickstarts
+
+  Before figuring out which quickstart to use, it is important to figure out which one most closely represents your application. You answer two questions to make this determination:
+
+  1. What type of application do you have? Do you have a traditional web application, a single page application, or a native mobile application?
+
+    * A traditional web application is generally an application written in PHP, Java, or C#.  It is an application where the browser opens a page, the page is rendered on the server side and then the HTML is sent to the browser.  When someone performs an action it refreshes the page. There is a frontend, the code on the browser, which may include some javascript, and a backend, the code that executes on the server side.  The backend can maintain the state of the application on the server.  Most applications fall into this category.
+
+    * A single page application is an application that renders once on the server and then the rest of the execution happens on the users’ browser.  The application must call API’s to perform actions that happen server side, but those APIs don’t maintain any state for the session.  You must give the API the information it needs.  Note that there is non-session state that can be stored in a database, but the API doesn’t know which instance of the application is calling it, so there is not sessions associated with your browser instance.
+
+    * A native and/or mobile application is an application that is installed on a mobile device or desktop OS.  It must call an API to perform actions on the server side as well.
+
+  2. Are you going to need an access token to call a separate API? If your application needs to call a separate API, then you will need to do some extra work after the quickstart to enable your SDK to get you an access token. You can learn more about that in the video that discusses Authorization.
+
+  In the next video, we are going to show you how to use a quickstart guide to integrate a javascript single-page app and a backend. 
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+
    
\ No newline at end of file
diff --git a/fr-ca/articles/videos/get-started/04_02-authenticate-spa-example.md b/fr-ca/articles/videos/get-started/04_02-authenticate-spa-example.md
new file mode 100644
index 0000000000..8e588388c4
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/04_02-authenticate-spa-example.md
@@ -0,0 +1,160 @@
+---
+description: An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login.
+classes: video-page
+public: false
+---
+
+# Authenticate: SPA Example
+
+See an example using the Auth0 Quickstart for a single-page application (SPA) implementation and learn how Auth0's Universal Login feature does most of the authentication work for you. Understand how security and user experience work with the authentication process to determine how to plan your application integration to Auth0. See how Single-Sign On (SSO) works between applications when you use Universal Login. 
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In part 1, we described a few of the ways that you can provide services to your users through your applications using user authentication. You can authenticate users via their social media accounts or with their usernames and passwords. You can add an additional level of certainty about their identities with Multi-factor Authentication (MFA).
+
+  In this video, we will look at how the Quickstart single page application or SPA implementation uses Universal Login—which is the preferred method for authentication workflow in Auth0. 
+
    
+
+
    
+  Quickstart: SPA with Backend
+
+  You can find the quickstarts at https://auth0.com/docs/quickstarts. It is a good idea to login to a specific tenant. Here I am using the **product-training** tenant. This will make the user experience better later on.
+
+  Next, we need to select the type of application we want to use. We can start with single page application. Then select the vanilla javascript quickstart.
+
+  Here we are offered two options; the first is a detailed step-by-step guide to implementing authentication in an existing javascript application, and the second is to download a fully functional sample application.
+
+  Let’s download the sample application. Because we are authenticated, the quickstart download gives us an option to select an existing application from our tenant. The downloaded sample application will be configured to use this applications credentials for authentication.
+
+  We are also instructed to add our localhost development url to the **Callback URL** and **Allowed Web Origins** lists.
+
+  Finally, assuming that `node.js` is installed we can install our dependences and start the application.
+
+  Now we can test the authentication by clicking the **Login** button.
+
    
+
+
    
+  Universal Login
+
+  Now that we have an application connected, let’s take a look at Universal Login. You can choose from Classic or New to create your own login pages that will authenticate your users. Later in another video, we will show you how to provide more extensive branding for these pages and more. 
+
+  The buttons that appear on the login page depend on a number of factors including the connections that have been enabled and the current state of a session the user may already have. These settings are dynamic and adjustable in real-time—no coding changes are required—since the functionality is driven by the web pages served by the Auth0 Authentication Server.
+ 
+  If you have **Enable seamless SSO** enabled or if you have a new tenant, where this option is enabled by default and can’t be turned off, Auth0 will show the login UI only if the user doesn’t have a session. There may or may not be other prompts as well like MFA or consent, but if no user interaction is required then the application will get the results immediately. Therefore, in most cases, applications don’t really check if the user is logged in into the identity provider: they just request an authentication.
+
+  Universal Login works by effectively delegating the authentication of a user; the user is redirected to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application. In most cases, when your application needs to authenticate the user, it will request authentication from the OIDC provider, Auth0, via an `/authorize` request. As you can see from the quickstart, the best approach to implementing this is to use one of the language-specific Auth0 SDKs or some third-party middleware applicable to your technology stack. How to actually do this depends on the SDK and application type used.
+
+  Once authenticated, and when using an OIDC authentication workflow, Auth0 will redirect the user back to your callback URL with an ID token or a code to fetch the ID token.
+
+  For OIDC, Auth0 returns profile information in the ID token in a structured claim format as defined by the OIDC specification. This means that custom claims added to ID Tokens must conform to a namespaced format to avoid possible collisions with standard OIDC claims. For example, if you choose the namespace `https://foo.com/` and you want to add a custom claim named myclaim, you would name the claim `https://foo.com/myclaim`, instead of `myclaim`.
+
+  By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. You can start off using a simple username and password, and with a simple toggle switch, you can add new features such as social login and multi-factor authentication. 
+
    
+
+
    
+  Integrate a second application
+
+  Next, we’ll see how easy it is to integrate Auth0 in your second application. If you run another quickstart, for example, to integrate a web application, you don’t have to do anything else. Running the second quickstart against the same tenant will configure SSO between your applications automatically. 
+
+  Let’s download another quickstart and see this in action.
+
+  This time around, I will select the Regular Web App application type and `asp.net core` sample. `Asp.net core` is a typical enterprise server side rendered web application framework.
+
+  The steps are the same as before: Select the application, set local development urls, download and run the sample.
+
+  After authenticating the user and redirecting them to an identity provider, you can check for active SSO sessions.
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+
    
diff --git a/fr-ca/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md b/fr-ca/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md
new file mode 100644
index 0000000000..9550161f31
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md
@@ -0,0 +1,141 @@
+---
+description: What ID Tokens are and how you can add custom claims to customize them and make access control decisions for your users.
+classes: video-page
+public: false
+---
+
+# Authorize: ID Tokens and Access Control
+
+Learn about Auth0 authorization via the use of ID Tokens. Understand what an ID Token is, and learn how to add custom claims to customize tokens and make access control decisions for your users.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, you will see how to use custom ID Token claims to support specific authorization requirements in your application. 
+
+  As a refresher, if you’ve just seen the Authentication video, then you know that it’s important to correctly distinguish between Authentication, Authorization, and Access Control. Your Auth0 tenant is your Authorization Server and responsible for Authentication and some or all of Authorization, and sometimes some coarse-grained access control. In contrast, your application or API is responsible for most Access Control because most access control is contextual and too fine-grained for a central service to manage effectively.
+
    
+
+
    
+  Access restrictions
+
+  Auth0 allows you to apply coarse-grained access restrictions to certain applications or APIs using Rule extensibility or provide authorization information to an application through custom claims. For example: 
+
+  * You can return an `UnauthorizedError` from a Rule, allowing Auth0 to provide coarse-grained denial of access to an application if the user doesn’t have the right claim or claims in their user profile metadata.
+  * You can return an `UnauthorizedError` from a Rule, allowing Auth0 to provide coarse-grained denial of access to an API if a call is coming from a restricted application or location. 
+  * You can add additional or custom claims to an OIDC-compliant ID Token via  Auth0 Rule extensibility. That information will appear in the body or payload of the returned ID Token and can be used by your application, in combination with application specific data, for fine-grained access control. 
+
    
+
+
    
+  Apply different access restriction levels
+
+  We’ll talk about API level integration in a future video, but for now, we’ll concentrate on how Auth0 can be leveraged to provide for both coarse-grained and fine-grained application-level authorization.
+
+  First, you should decide if you require coarse-grained or fine-grained control. With coarse-grained control, you can use Auth0 extensibility to prevent allocation of an ID Token, thus denying access to the application overall. If you require fine-grained control, then you will need to decide what information your application requires in order to make access control decisions (for example the user may have a role associated with them or specific permissions associated with their profile). In this case, you can use Auth0 extensibility to add this information as custom claims to an ID Token, which can then be verified and used by the application, in combination with application specific data, to apply any access control restrictions. We recommend that you add this information to the user profile metadata, that way you don’t have to call an external API to fetch the information which could negatively impact the performance and scalability of the login sequence. 
+
+
    
+
+
    
+  Role Based Access Control
+
+  Additionally, Auth0 has out-of-box support for Role Based Access Control or RBAC. RBAC refers to assigning permissions to users based on their role within an organization. Use RBAC for simpler, fine-grained access control that is often less prone to error.
+
+  Be wary of adding too fine-grained detail to the user profile. Application specific access control data should live with the application, and not in the user profile. Trying to put all access control information in the user profile can quickly grow into a complicated system to maintain. Limit the authorization information stored against the user to apply to attributes about the user themselves, but not about individual items they can access. For example: if a user has access to a document repository, you could store the fact that the user is an administrator of the document repository application in the user’s app_metadata, but you wouldn’t want to store the specific documents the user has access to.
+
+  In the next video, we'll dig into some of the details on how authorization works with Auth0.
+
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+
    
+
diff --git a/fr-ca/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md b/fr-ca/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md
new file mode 100644
index 0000000000..bc933daba7
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md
@@ -0,0 +1,183 @@
+---
+description: How to get and validate ID Tokens before storing and using them.
+classes: video-page
+public: false
+---
+
+# Authorize: Get and Validate ID Tokens
+
+Learn how to get and validate an ID Token in JSON Web Token (JWT) format.
+
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, we'll take a closer look at how authorization works, in Auth0, and we'll start by digging into ID Tokens. 
+
+  The ID Token contains user profile information, such as the user's name and email, represented in the form of claims. These claims are statements about the user, which can be trusted if you can verify its signature. 
+
+  You can get an ID Token for a user after they successfully authenticate and you must validate it before storing and using it. 
+
    
+
+
    
+  Obtain an ID Token
+
+  The first step is to obtain the ID token by authenticating the user. The previous video on authentication demonstrates how to do this. The best approach is to use your language specific SDK to redirect the user to your Auth0 tenant to authenticate the user. Then Auth0 will redirect the user back to your callback URL with the ID token (or a code to fetch the ID token).
+
+  You can then add custom claims to the token using Auth0 Rules as we mentioned. The claim name must conform to a namespaced format something similar to the following: 
+
+  `http://MY_NAMESPACE/CLAIM_NAME`
+  
+  Where `MY_NAMESPACE` is any domain except `auth0.com`, `webtask.io`, or `webtask.run`.  `CLAIM_NAME` can be anything you want. Some examples: `http://example.com/role` or `https://example.com/claims/locale`.
+
+  The ID Token acts as a *cache* for user information and by default, the token is valid for 36,000 seconds—or 10 hours. You can shorten this lifetime limit if you have security concerns. Remember, that the ID Token helps ensure optimal performance by reducing the need to contact the Identity Provider every time the user performs an action.
+
    
+
+
    
+  ID Token format
+
+  Auth0 generates the ID Token in JSON Web Token, or *JWT* format. A JWT is an open, industry standard RFC 7519 method for representing claims securely between two parties. At Auth0, ID Tokens are always returned in JWT format, and Access Tokens can be either JWT format or opaque strings depending on the context. 
+
+  A correctly formatted JWT consists of three concatenated base64url-encoded strings, separated by dots.
+
+  * The first string is the **Header** which contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+  * The second string is the **Body**, also called the *payload*, which contains identity claims about a user. Here’s where you will see any custom claims that you’ve added. Note that in cases where the JWT is returned via a URL, you need to make sure to limit the custom claims to keep the JWT within browser size limitations for URLs. The ID Token payload can contain some or all of the following items: name, email, picture, sub, issuer, audience, and expiration. 
+  * The third string contains the **Signature** which is used to validate that the token is trustworthy and has not been tampered with.
+
    
+
+
    
+  Check the ID Token
+
+  Next, we are going to walk through the three things your application will need to check for in the returned JWT. 
+
+  1. The JWT format is correct.
+  2. The contents contain the right claims
+  3. The signature is trustworthy. 
+
+  To check that the JWT format is correct, your application should parse the ID Token to make sure it conforms to the established structure of a JWT.  Your language specific SDK should have a method for validating the JWT.  Make sure this method actually checks the `aud`, `iss`, `exp`, and `nonce` (where applicable) claims, and validates the signature.
+
+  You can decode well-formed JWTs at using the [jwt.io](https://jwt.io) debugger to view the claims. 
+
    
+
+
    
+  Validate the ID Token claims
+
+  Next, you need to verify that the standard claims and any custom claims you’ve added are in the payload. Remember it should contain some or all of the following items (depending on which openid scopes you requested): `name`, `email`, `picture`, `nonce`, `sub`, `iss`, `aud`, and `exp`.
+
+  * Make sure the token expiration, named `exp`, which is a Unix timestamp, is set to be after the current date and time and matches what you require for token lifetime. 
+
+  * Make sure the token issuer, named `iss`, matches the issuing authority identified in your Auth0 tenant’s discovery document which you can find at `https://YOUR_DOMAIN/.well-known/openid-configuration`. 
+
+  * Make sure that the token audience, named `aud`, is the correct recipient for which the token is intended. The value must match the client ID of your Auth0 application.
+  
+  * The nonce claim is recommended (required for implicit flow) to pass in a single unique identifier when redirecting to Auth0 to authenticate, and helps in the prevention of replay attack scenarios.
+
+  * There are also other claims which are used in specific use case scenarios.
+
    
+
+
    
+  Verify the ID Token signature
+
+  To verify the ID Token’s signature, you will need to base64url-decode the signature. You can check the signing algorithm and confirm that the token is correctly signed using the proper key.  We recommend you use an SDK to validate the signature, and [jwt.io](https://jwt.io) provides a list of SDKs that can be used for this purpose.
+
    
+
+
    
+  Summary
+
+  Now that you have validated that the token is legitimate, you can use the custom claims you added to the token combined with your application data to perform fine-grained access control. 
+
+  We will go into more depth about API integration in a separate video, and in our next video, we’ll talk about how to manage user profiles. 
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/06-user-profiles.md b/fr-ca/articles/videos/get-started/06-user-profiles.md
new file mode 100644
index 0000000000..5556638b13
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/06-user-profiles.md
@@ -0,0 +1,211 @@
+---
+description: What user profiles are, what they contain, and how you can use them to manage users.
+classes: video-page
+title: Explore User Profiles
+public: false
+---
+
+# Explore User Profiles
+
+Learn what Auth0 User Profiles are used for and what they contain. Understand how Auth0 normalizes user profile data from various identity providers and uses metadata and root attributes. You can manage user profiles with the Auth0 Dashboard.  
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+Auth0 creates user profiles to contain information about your users such as name, email address, and last login. A user profile in Auth0 is essentially the cache of information obtained from an identity provider; together with any Auth0 specific information for a user—such as user metadata—the profile is stored in a user account record contained in the user account storage associated with an Auth0 tenant,
+
+Depending on which connections you choose, there will most likely be data formatting differences between various identity providers. It is also likely that there will be different information provided too. To compensate for this, Auth0 provides standardized user profile claims in what is referred to as the Normalized User Profile.
+
+Auth0 also provides a variety of tools in the Dashboard to help you manage certain aspects of a users’ profile. You can also use the Auth0 Management API to manage user profiles. You can use these tools to create, search, view, and delete users, and you can also define, manage, and store custom metadata too—unique profile attributes, which can hold information like favorite color, language preference, contact information, location, internal IDs, or access information.
+
    
+
+
    
+  How Auth0 uses user profiles, metadata, and root attributes
+
+Let’s now look at how Auth0 makes use of these user profiles.
+
+When a user logs in, Auth0 populates or updates the User Profile with data supplied by the identity provider. By default, there is one user profile created for each user identity.
+
+As discussed, Auth0 can store associated metadata with a user’s profile, that contains information such as language preferences or accessibility preferences that you can use to enhance your users’ experience with your application. There are two types of metadata available in Auth0: user metadata and app metadata. 
+
+* User Metadata is information that can be stored against a user profile and that a user can read/update as part of any self-service profile management. Metadata of this nature may be something like salutation for a user, or perhaps a user’s preferred language—used to customize the emails sent by Auth0. Any information that will be used to customize Auth0 emails—such as information used to determine the language for an email—should be stored in Metadata, and preferably user_metadata if the user is allowed to change it.
+
+* App Metadata is information that can be stored against a user profile but which can only be read or updated with appropriate authorization; app_metadata is not directly accessible to a user. Metadata of this nature might be something like a flag to indicate the last set of valid terms and conditions accepted by the user, and perhaps a date to indicate when the user accepted them.
+
+There are also user profile attributes that are updatable called *root attributes*. 
+
    
+
+
    
+  Use the Dashboard to manage user profile information
+
+You can use the Auth0 Dashboard to manage aspects of a user’s profile—such as metadata and root attributes—during your development process, but we recommend you don’t use the Dashboard to make changes in a production environment. Instead, you can use the Auth0 Management API to build your own management tool or integrate with any already built UI for Profile Management. Managing a user’s profile using the Dashboard is more of an administrative provision, however, it can be extremely useful during design and development, as it provides a simple way to manipulate user profiles while you make adjustments to how your application uses the data.
+
+Now we’ll show you a few of the management actions you can take with the user profile data and in what circumstances you can perform them.
+
    
+
+
    
+  Create a user
+
+First, let’s create a user to see how it works. 
+
+You can see that we’ve created a user called John Doe. Clicking on the user’s name (by default his/her email address) will allow us to view the user’s profile details. 
+
+In the main section, you’ll find essential data such as the user's email and login access information.
+
    
+
+
    
+  Metadata
+
+The next three sections on this page in the Dashboard are related to MFA, metadata, and identity provider attributes. Note that we’ll be covering MFA in a separate video. 
+
+In the **Metadata** section, you can see parts of the metadata you can modify. You can see fields for the two types of metadata: *user metadata* and *app metadata*.
+
+If you’re an Auth0 hosted subscriber, you can update selected root attributes which are name, given_name, family_name, nickname, and picture. Methods for updating root attributes vary depending on your connection type. 
+
+* If you are using Auth0 as the identity provider, you can set root attributes on user sign-up using the Management API, through public signup, or on import. Auth0 is the identity provider for regular database connections, custom database connections with import mode, and for passwordless connections.
+
+* If you are using an upstream identity provider such as Google or Facebook, the identity provider sets the root attributes when users are first created and then automatically updates them with each subsequent login. This is the default behavior. You can opt to have the identity provider set the root attributes on user creation only and not update them on subsequent logins, thereby allowing you to update them individually using the Management API. To enable this, you need to configure your connection sync with Auth0 in the dashboard. 
+
+Let’s walk through how to do this. Go to the Dashboard and click **Connections**. Let’s choose **Social** and choose **Google** for this example. 
+
+Click the name of the connection to see its settings.
+Toggle the **Sync user profile attributes at each login** to the setting you want and click **Save**. 
+
    
+
+
    
+  Root attributes
+
+Because user profile root attributes are a new feature in Auth0, we’ve made it easy for you to transition from using `user_metadata` in the old way. We built a Rule in the **Enrich Profile** rule category named **Move user_metadata attributes to profile root attributes**. When you use this, the rule moves the attribute from your old metadata to the appropriately named root attribute and removes it from the user_metadata. 
+
+Let’s look at this new Rule.
+
+Note that this rule will be executed on each login event. For signup scenarios, you should only consider using this rule if you currently use a custom signup form or Authentication Signup API, as these signup methods do not support setting the root attributes.
+
    
+
+
    
+  Other tabs in the Dashboard
+
+Now, let’s go back to our new user and walk through the other information you can view in the Dashboard.
+
+In the **Identity Provider Attributes** section you’ll find all the information retrieved from each identity provider.
+
+The **Devices** tab lists the devices with which the user has requested authentication. Authenticating via a device links the device to the user's account; login details for the user are associated with any Refresh Token assigned to that device. To revoke the Refresh Token, click Unlink next to the device.
+
+The History tab displays a log of the user's account activity for the past 2 days. The logs include information about:
+
+* Events that have occurred
+* When the events occurred
+* The apps associated with the events
+* The identity provider used for authentication
+* The originating IP addresses for the events
+* Where the events originated
+
+The **Raw JSON** tab displays all of the information contained on the user's profile in JSON format so you can quickly view all of the available information about the user.
+
+The **Authorized Applications** tab displays the applications that the user has been given permission to use. All users associated with a single Auth0 tenant are shared between the tenant's applications, and therefore have access to the applications. If you need to keep users separate and restrict their access to groups of applications, we recommend creating an additional tenant.
+
+The **Permissions** tab lists the permissions assigned to the user. You can assign permissions here.
+
    
+
+
    
+  Roles
+
+The **Roles** tab lists the roles assigned to the users. You create roles on another page and assign them here. The roles you create appear in the drop-down on this tab. 
+
+In the upper right corner of the User Details page, click the **Actions** button to see the list of actions you can perform. You can block or delete the user, send them a verification email, change their email address, and change their password. Note that you should never change a user’s password unless you have a system set up to force them to change it themselves the next time they log in, except in development or test environments. 
+
+In the next video, we’ll talk about how to brand your sign up, login, and password reset pages.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/07_01-brand-how-it-works.md b/fr-ca/articles/videos/get-started/07_01-brand-how-it-works.md
new file mode 100644
index 0000000000..64c99d14ab
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/07_01-brand-how-it-works.md
@@ -0,0 +1,150 @@
+---
+description: Why your branding is important for your users and how it works with Auth0.
+classes: video-page
+public: false
+---
+
+# Brand: How It Works
+
+Learn how branding works with Auth0. Add your company name and logo, and choose colors for your pages.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+The way your sign up and login pages look to your users makes a difference in their overall experience. If those pages have your company branding and URL, your customers will have peace of mind that your application can be trusted and is secure. 
+
+In this video, we’ll start by explaining what Auth0 Universal Login is and what it does for you, and then show you how easy it is to set up your branded pages.
+
    
+
+
    
+  How Universal Login works
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. Each time a user needs to prove their identity, your application redirects to your Auth0 tenant and Auth0 will do what's needed to verify the user's identity which often includes redirecting the user to the Universal Login Page to collect their credentials and/or provide them other options for login, such as social or enterprise identity providers.
+
+By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. When you customize the login page, the customizations you make will persist, even when you add new features such as social logins, and multi-factor authentication.
+
+You also benefit from all improvements Auth0 does in the login flow without you changing a single line of code in your application. 
+
    
+
+
    
+  Use the Dashboard to customize your pages
+
+The login page appearance and behavior is customizable right from the Dashboard. You can change the logo and colors of the login pages, and in more advanced use cases, you can modify the HTML code of each page. You can also customize the look of the URL used to navigate to the Universal Login page. Creating this *vanity URL* not only aligns with the idea of a consistent user experience, but also offers you complete control over the certificate management process, if you need it—so for example, you can use Extra Validation (EV) SSL certificates or similar to provide the visual, browser-based cues that offer your visitors additional peace of mind.
+
+Let’s see how this is done.
+
+First, we'll add a meaningful name to your application. Next, we'll configure the universal login settings, adding your company logo, then we'll specify a custom primary and background color. 
+
+Now we'll configure the tenant settings, specifying a friendly name, a logo, a support email and a support url.
+
+Next, we'll configure your custom vanity URL, by click on **Custom Domains** tab.
+
+Go back to the **Tenant Settings page** and click the **Custom Domains** tab. 
+
+1. Type in your custom domain URL—such as `accounts.acme.com`.
+2. Select **Auth0-managed certificates** and click **Add Domain**.
+3. Now you need to verify that you own that domain so you need to add the CNAME verification record listed in the Dashboard to your domain’s DNS record. Then click **Verify**. 
+
+The steps may vary by domain provider but it’s easy to verify your domain.
+
    
+
+
    
+  Summary
+
+There may be additional steps you have to complete depending on which Auth0 features you are using. For example, if you are using Auth0.js or one of the other SDKs, or if you are using G Suite connections, there are some additional domain name related steps you will need to take. We provide documentation on the Auth0/docs website to help you. 
+
+In the next video, we'll look at how to set up Universal Login.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/07_02-brand-signup-login-pages.md b/fr-ca/articles/videos/get-started/07_02-brand-signup-login-pages.md
new file mode 100644
index 0000000000..ed2a4cd9c8
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/07_02-brand-signup-login-pages.md
@@ -0,0 +1,140 @@
+---
+description: How to use Universal Login to customize your sign up and login pages. 
+classes: video-page
+public: false
+---
+
+# Brand: Sign Up and Login Pages
+
+Learn how to use Auth0’s Universal Login feature to customize your sign up and login pages to include your brand.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+In this video, we'll look at how you can setup Universal Login.
+
+In the Dashboard, you can see the settings for your login page by navigating to **Universal Login** and looking at the **Settings** tab.
+
    
+
+
    
+  Settings
+
+The settings available here are **Logo**, **Primary Color**, and **Background Color**. These settings once changed, will take effect on all pages where you have not enabled customization of the pages' code. Note that the settings will also work if you have enabled customization but assume you are using predefined templates and have not changed those options in the code.
+
+1. Add the URL to your logo image.
+2. Select a primary color.
+3. Select a background color.  
+
    
+
+
    
+  Customize login pages
+
+Now we’ll move to the **Login** tab and enable the login page customization. 
+
+Click the **Login** tab and toggle **Customize Login Page**.
+
+Note that when the customization toggle is flipped on, irrespective of the page you are customizing, you then become responsible for updates and maintenance of that page; it can no longer be automatically updated by Auth0. This includes updating the version numbers for any included Auth0 SDK or widget.
+
+If you have enabled customization to inspect the page code, and then decide not to customize your login page, you should make sure to disable the customize page—in this case the **Customize Login Page**—toggle, so Auth0 will render the default page. You can also use version control software to manage the source code of your pages. To do so, you can use an Auth0-provided extension that works with the version control system you're using, like GitHub for example. 
+
+You should also exercise caution regarding the use of third-party JavaScript on your pages—particularly the Login Page—since sensitive security-related information often flows through pages and the introduction of cross-site scripting or XSS vulnerabilities can be a concern.
+
    
+
+
    
+  Summary
+
+In the next video, we’ll talk about how to customize emails and error pages, and in a future video, we’ll talk about customizing the Guardian multi-factor authentication page too.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+
    
diff --git a/fr-ca/articles/videos/get-started/08-brand-emails-error-pages.md b/fr-ca/articles/videos/get-started/08-brand-emails-error-pages.md
new file mode 100644
index 0000000000..81f7840e35
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/08-brand-emails-error-pages.md
@@ -0,0 +1,179 @@
+---
+description: How to use email templates and customize error pages. 
+classes: video-page
+public: false
+---
+
+# Brand: Emails and Error Pages
+
+Learn how to use Auth0 email templates and make changes to the reply email address, subject, redirect URL, and URL lifetime. You can configure your email provider and customize how verify emails look. Learn how to use your own error pages.
+
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+In the previous video we showed you how to add branding to your login pages using the universal login  Settings in the Auth0 Dashboard. In this video, we are going to show how easy it is to brand the rest of the things that your users might see, such as emails, and error pages.
+
    
+
+
    
+  Email templates
+
+First let’s take a look at email templates. 
+
+We’ll start by choosing a template to customize. In this example, we’ll work on the **Change Password** template. This is the email that will be sent whenever a user requests a password change; the password will not be changed until the user follows the link in the email. 
+
+Note that we enabled **Customize Password Reset Page** in the **Universal Login Password Reset** tab in the last video. If you haven’t done that yet, go ahead and do that now.
+
+Enter all the information into the fields to determine the reply email address, subject, redirect URL, and URL lifetime. Email templates in Auth0 support [Liquid syntax](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers), and allow you to include a number of Auth0 provided common variables 
+
+1. For the Reply Email Address, you can include any of the common variables like {{ application.name }}. For example: `{{ application.name }} `.  For this field, however, you can not use liquid syntax as part of the email address itself.
+
+2. For the Subject line, you can include any of the common variables like `{{ application.name }}` and `{{ user.email }}`. For example: Welcome to `{{ application.name }}!`.
+
+3. For the Redirect URL, enter the URL that you want the user to be redirected to after the action finishes. You can use the `{{ application.name }}` and `{{ application.callback_domain }}` variables. 
+
+4. The URL Lifetime default is set to 432,000 seconds which is 5 days. After that time has passed, the URL link will expire.
+
+5. Click Save.
+
+At the bottom, you can see the HTML code of message body. You can edit the HTML directly. You can also use common variables in the email message body. You can use liquid syntax in the body of the email to do everything—from just changing some of the text to be user specific, to using if/then statements to provide localization of the text. 
+
    
+
+
    
+  Custom email providers
+
+Now we will show you how easy it is to configure a custom email provider to use. In order to use a custom email template you will need to setup one of the out of box third-party email provider services, or provide credentials from any SMTP service that supports basic authentication. 
+
+You can use an external email provider to manage, monitor, and troubleshoot your email communications. It’s as simple as opening the right ports and whitelisting inbound connections from specific IP addresses. Auth0 currently supports the following providers:
+
+* Mandrill
+* Amazon SES
+* SendGrid
+* SparkPost
+* Or any Other SMTP provider (e.g., Gmail, Yahoo)
+
+Note that you can only configure one email provider, which will be used for all emails.
+
+You can also use your own SMTP server to send emails. This works well for testing your email templates without spamming your users. There are three requirements for the SMTP server:
+
+* It must support LOGIN authentication.
+* It must support TLS 1.0 or higher.
+* And It must use a certificate signed by a public certificate authority (CA).
+
+1. Open the **Custom Email Provider** page on the Auth0 Dashboard.
+2. Click on **Use my own Email Provider**.
+3. Click the **SMTP** logo.
+4. Enter your SMTP server Host, Port, Username and Password in the appropriate fields.
+5. Click **Save**.
+
+Common SMTP ports include 25 and 587. Port 25 is generally reserved for unencrypted traffic and so should not be used; this is particularly important for emails from Auth0 since they often contain sensitive information. 
+
+Now you can send a test email using the **SEND TEST EMAIL** button on the **Custom Email Provider** page of the Auth0 Dashboard. If you don't receive an email after a few minutes, check your dashboard logs for any failures.
+
    
+
+
    
+  Custom error pages
+
+Now we’re going to look at customizing error pages. 
+
+By default, if your users encounter any problems at sign up or log in, Auth0 provides generic error pages, that includes the support URL and support email address, that's entered right here.
+
+Down near the bottom of the page, under the **Error Pages** heading, you can select **Redirect users to your own error page** if desired
+
+Using your own error pages allows you to add your branding (not Auth0’s) and provide user information about what your users should do next. To do this, you simply enter the URL for your error page.  When Auth0 redirects users to your own error pages, additional query parameters will be included in your URL, which provides additional information about the error that was encountered.
+
+In the next video, we'll look at the user logout process.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/10-logout.md b/fr-ca/articles/videos/get-started/10-logout.md
new file mode 100644
index 0000000000..ea9301a1de
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/10-logout.md
@@ -0,0 +1,177 @@
+---
+description: How to configure different kinds of user logout behavior using callback URLs.
+classes: video-page
+public: false
+---
+
+# Logout
+
+Learn about different kinds of logout behavior and different session layers. Learn how to configure callback URLs in the application and tenant settings in the Dashboard.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+When we talk about logout in the context of Auth0 implementations, we are talking about the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. 
+
+Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
+
    
+
+
    
+  Session layers
+
+There are typically three session layers that can be created when you login and the logout behavior you choose for your applications should make it clear to users which have terminated—ideally displaying a visual confirmation of this. 
+
+The first layer is the session inside your application or the *Application Session Layer*. Though your application uses Auth0 to authenticate users, you'll still need to track that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a cookie. 
+
+Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination. This will require you to utilize whatever application session stack you are using to clear out any session related information. Note that some of the Auth0 SDKs do provide some support for application sessions; please check the documentation to see if there is any local SDK session removal that needs to be done.
+
+Auth0 also maintains a session for the user and stores their information inside a cookie, this is the *Auth0 Session Layer*. This layer is used so that the next time a user is redirected to Auth0 for login the user's information will be remembered. You can log users out of the Auth0 session layer by redirecting them to the Auth0 logout endpoint so Auth0 can clear the (single sign-on; SSO) cookie.
+
+The last session layer is the *Identity Provider Session Layer*, for example, Facebook, Google or an Enterprise SAML provider. When users attempt to sign in using any of these providers, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in—though they may be asked to give permission to share their information with Auth0 and, in turn, your application. It is not necessary to log the users out of this session layer, but you can use Auth0 to force the logout if required. 
+
+Logging out of your Auth0 Session Layer will require you to redirect the user to `https:///v2/logout`—typically performed via use of the appropriate method in the Auth0 SDK for your technology stack. This will clear your Auth0 session. You will also want to add a query parameter for that request called `returnTo`—this parameter should contain a URL that has been pre-registered and protects you against open redirect attacks.  
+
    
+
+
    
+  Set whitelisted URLs
+
+Auth0 only redirects to whitelisted URLs after logout and there are two places you can configure these. 
+
+The first place you can set this is at the tenant level—this is where you can put the set of logout URLs that are common to (that is shared between) all applications. 
+
+The second place would be in the application settings: if you need different redirects for each application, you can whitelist the URLs in your application settings. This allows you to set logout URLs in an application-specific context. 
+
    
+
+
    
+  Session timeouts
+
+You can also set the behavior in cases where a user doesn’t explicitly logout of your application. Auth0 provides for session timeout to deal with Auth0 session termination in this scenario. We’ll cover the topic of session timeout in more detail in a future video.
+
    
+
+
    
+  Application-specific logout URLs
+There are two important things to consider when you use application-specific logout URLs:
+
+1. You MUST send client_id as a query parameter when calling the /v2/logout endpoint. and the returnTo URL must be in the application’s list of allowed logout URLs.
+
+2. This will end the Auth0 Session for the entire tenant, i.e. for all defined applications, not just the one that matches the client_id supplied!  Passing the client_id just tells the logout endpoint where to look for the logout URL white-list.
+
+In either place, under **Allowed LogoutURLs**, specify the logout URLs; you must include the protocol—either `http://` or, as we would recommend, `https://`—otherwise the call will fail. Https should always be used for production environments. The URLs provided in the Allowed Logout URLs list are also case-sensitive, so the URL used for logout must match the case of the logout URLs configured on the dashboard. However, do note that the scheme and host parts are case insensitive. For example, if your URL is `http://www.Example.Com/FooHoo.html`, the `http://www.Example.Com` portion is case insensitive, while the `FooHoo.html` portion is case sensitive.
+
+After the user logout occurs Auth0 will only redirect to a URL that is defined in this list. 
+
+Note that if you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out and, if desired, you can also warn them that they may still be logged into their identity provider.
+
    
+
+
    
+  Identity provider session layer logout
+
+Alternatively you may desire to also log the users out of the Identity Provider Session Layer; for many providers, Auth0 will give you this behavior by simply having you add the federated query parameter to the redirect to /v2/logout. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+There are a few limitations with logout to keep in mind:
+ 
+* No validation is performed on any URL provided as a value to the `returnTo` parameter, nor any querystring or hash information provided as part of the URL.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the `returnTo` parameter differently and for some, it will not work. Please check your social provider's settings to determine how it will behave.
+
+* If you are working with social identity providers such as Google or Facebook, you must set your Client ID and Secret for these providers in the Dashboard for the logout to function properly.
+
+* If you are an Auth0 Enterprise user, you will typically have SSO enabled for multiple applications, for example, SharePoint, a few .NET applications, a few Java applications, Zendesk, etc. In this case, it's very common that when users sign out, this needs to happen for all of their applications.  
+
+  However, redirecting users to the Auth0 log out endpoint does not currently cover all scenarios where users need to be signed out of all of the applications they use. Other than when Auth0 is using SAML, Auth0 does not natively support Single Logout. Single Logout can be achieved by having each application check the active session after their tokens expire, or you can force log out by terminating your application sessions at the application level. 
+
+  You can configure Single Logout URLs for SAML that can log out of all SAML sessions, although Auth0 supports front-channel SAML SLO only, Auth0 does not support back-channel SLO.
+
    
+
+
    
+  Summary
+
+Auth0 provides quickstart guides that show you how to implement logout functionality in your specific type of application and provides sample code. These quickstarts support native/mobile apps, single-page apps, and web apps. 
+
    
+
+## Previous videos
+
+
diff --git a/fr-ca/articles/videos/get-started/index.md b/fr-ca/articles/videos/get-started/index.md
new file mode 100644
index 0000000000..ae0f8f4e28
--- /dev/null
+++ b/fr-ca/articles/videos/get-started/index.md
@@ -0,0 +1,112 @@
+---
+description: Learn how to get started implementing Auth0 features with your applications.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/videos/get-started/get-started.png
+topics: 
+   - tenant architecture
+   - tenants
+   - provisioning
+   - user stores
+   - import users
+   - authorization
+   - authentication
+   - branding
+   - emails
+   - error pages
+   - logout
+   - user profiles
+public: false
+---
+# Get Started with Auth0 Video Series
+
+## Introduction
+
+
    
+
+
     
    
+
+
      
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What ID Tokens are and how you can add custom claims to customize them and make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/index.md b/fr-ca/articles/videos/index.md
new file mode 100644
index 0000000000..7d5ef5c972
--- /dev/null
+++ b/fr-ca/articles/videos/index.md
@@ -0,0 +1,32 @@
+---
+description: Learn about digital identity including OAuth2, OpenID Connect, calling APIs, and get started with your Auth0 Implementation.
+classes: video-page
+public: false
+---
+# Auth0 Videos
+
+## Learn Identity Series
+
+[Learn about digital identity](/videos/learn-identity) including OAuth2, OpenID Connect, calling APIs, and more! In this video series, we cover:
+
+* The history of modern identity and some of the foundational concepts and terminology
+* Protocols, open standards, SSO, JWTs, OAuth2, and OpenID Connect
+* Web application authentication
+* How to call an API with a web application
+* Native applications, including those for mobile, desktop, and command line use
+* Single-page applications
+
+## Get Started Series
+
+Check out the [Get Started](/videos/get-started) series of videos to learn the basics of implementing Auth0 features with your applications. In this video series, you can learn the following:
+
+* What an Auth0 tenant is
+* How Auth0 manages user information
+* How to move your existing users to an Auth0 user store  
+* The difference between authentication, authorization, and access control, and when and why you use each one
+* How Auth0's Universal Login feature works
+* How Auth0 authorization works using ID tokens
+* How to get and validate an ID token
+* How to manage users
+* How branding works with Auth0 for signup, login, emails, and error pages
+* How to configure how your users logout
diff --git a/fr-ca/articles/videos/learn-identity/01-introduction-to-identity.md b/fr-ca/articles/videos/learn-identity/01-introduction-to-identity.md
new file mode 100644
index 0000000000..4718aee76b
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/01-introduction-to-identity.md
@@ -0,0 +1,115 @@
+---
+description: A whirlwind tour of identity history, concepts, and terminology - protocols, open standards, SSO, OAuth2, OpenID Connect and more.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Introduction to Identity
+
+A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
+
+
    
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/02-oidc-and-oauth.md b/fr-ca/articles/videos/learn-identity/02-oidc-and-oauth.md
new file mode 100644
index 0000000000..9684482b63
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/02-oidc-and-oauth.md
@@ -0,0 +1,90 @@
+---
+description: OpenID Connect and OAuth specifications, roles, and grants.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# OpenID Connect and OAuth2
+
+OpenID Connect and OAuth specifications, roles and grants.
+
+
    
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/03-web-sign-in.md b/fr-ca/articles/videos/learn-identity/03-web-sign-in.md
new file mode 100644
index 0000000000..2a4385a506
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/03-web-sign-in.md
@@ -0,0 +1,123 @@
+---
+description: Authentication for web applications using OpenID Connect.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Web Sign-In
+
+Authentication for web applications using OpenID Connect.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 1: Web Sign-On](/identity-labs/01-web-sign-in)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/04-calling-an-api.md b/fr-ca/articles/videos/learn-identity/04-calling-an-api.md
new file mode 100644
index 0000000000..2b4de9ae1b
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/04-calling-an-api.md
@@ -0,0 +1,136 @@
+---
+description: How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Calling an API
+
+How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 2: Calling an API](/identity-labs/02-calling-an-api)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/05-desktop-and-mobile-apps.md b/fr-ca/articles/videos/learn-identity/05-desktop-and-mobile-apps.md
new file mode 100644
index 0000000000..7994284e33
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/05-desktop-and-mobile-apps.md
@@ -0,0 +1,129 @@
+---
+description: Authentication and delegated authorization for desktop and mobile applications and a public client overview.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Desktop and Mobile Apps
+
+Authentication and delegated authorization for desktop and mobile applications and a public client overview.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 3: Mobile Applications](/identity-labs/03-mobile-native-app)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
    
+  
+
    
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/06-single-page-apps.md b/fr-ca/articles/videos/learn-identity/06-single-page-apps.md
new file mode 100644
index 0000000000..b873dee324
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/06-single-page-apps.md
@@ -0,0 +1,117 @@
+---
+description: Authentication and delegated authorization for single page applications.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Single Page Apps
+
+Authentication and delegated authorization for single page applications.
+
+
    
+
+[ Lab 4: Single-Page Applications](/identity-labs/04-single-page-app)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
    
diff --git a/fr-ca/articles/videos/learn-identity/index.md b/fr-ca/articles/videos/learn-identity/index.md
new file mode 100644
index 0000000000..a8a9a172d0
--- /dev/null
+++ b/fr-ca/articles/videos/learn-identity/index.md
@@ -0,0 +1,55 @@
+---
+description: Learn about digital identity including OAuth2, OpenID Connect, calling APIs, and more!
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+# Learn Identity
+
+[![Learn Identity with Auth0](/media/articles/learn-identity/learn-identity-intro.jpg)](/videos/learn-identity/01-introduction-to-identity)
+
+
     
    
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/_includes/_api-auth-customize-tokens.md b/ja-jp/articles/_includes/_api-auth-customize-tokens.md
new file mode 100644
index 0000000000..0c5ca2a2e3
--- /dev/null
+++ b/ja-jp/articles/_includes/_api-auth-customize-tokens.md
@@ -0,0 +1,19 @@
+You can use [Rules](/rules) to change the returned scopes of the Access Token and/or add claims to it (and the ID Token) with a script like this:
+
+```javascript
+function(user, context, callback) {
+
+  // add custom claims to Access Token and ID Token
+  context.accessToken['http://foo/bar'] = 'value';
+  context.idToken['http://fiz/baz'] = 'some other value';
+
+  // change scope
+  context.accessToken.scope = ['array', 'of', 'strings'];
+
+  callback(null, user, context);
+}
+```
+
+::: panel-warning Namespacing Custom Claims
+Auth0 returns profile information in a [structured claim format as defined by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims. You can [add namespaced claims using Rules](#optional-customize-the-tokens).
+:::
diff --git a/ja-jp/articles/_includes/_api_auth_intro.md b/ja-jp/articles/_includes/_api_auth_intro.md
new file mode 100644
index 0000000000..aab96af74d
--- /dev/null
+++ b/ja-jp/articles/_includes/_api_auth_intro.md
@@ -0,0 +1,3 @@
+::: note
+**New to Auth0?** Learn [how Auth0 works](/overview) and read about [implementing API authentication and authorization ](/api-auth) using the OAuth 2.0 framework.
+:::
diff --git a/ja-jp/articles/_includes/_boxed.html b/ja-jp/articles/_includes/_boxed.html
new file mode 100644
index 0000000000..e54755dc57
--- /dev/null
+++ b/ja-jp/articles/_includes/_boxed.html
@@ -0,0 +1,17 @@
+
    
+  
    
+    
+      Logs
+    
+  
    
+  
      
+    
      
+      
    • Review the logged data of both actions taken in the dashboard by the administrators, as well as authentications made by your users.
      • 
+      
    • Facilitate diagnosis and resolution of authentication issues.
      • 
+    
      
+    
      
+      
    • Longer Storage of log data for your apps.
      • 
+    
      
+  
    
+  
    Your current subscription allows to keep your logs for the last 30 days.
    
+
    
diff --git a/ja-jp/articles/_includes/_callback_url.md b/ja-jp/articles/_includes/_callback_url.md
new file mode 100644
index 0000000000..bd1ad7a23c
--- /dev/null
+++ b/ja-jp/articles/_includes/_callback_url.md
@@ -0,0 +1,5 @@
+
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application where Auth0 redirects the user after they have authenticated. The callback URL for your app must be added to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications). If this field is not set, users will be unable to log in to the application and will get an error.
diff --git a/ja-jp/articles/_includes/_calling_apis.md b/ja-jp/articles/_includes/_calling_apis.md
new file mode 100644
index 0000000000..ba355371bf
--- /dev/null
+++ b/ja-jp/articles/_includes/_calling_apis.md
@@ -0,0 +1 @@
+A common need for any client-side application is to access resources from a data API. Some of these data resources will likely need to be protected such that only the user who is authenticated in the client-side app can access them. This can be achieved by protecting your API's endpoints with your Auth0 secret key and sending the user's JWT as an `Authorization` header when calling the API. For more detail on how to secure your API, see the [server API documentation](/quickstart/backend).
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_checksession_polling.md b/ja-jp/articles/_includes/_checksession_polling.md
new file mode 100644
index 0000000000..9030fb5770
--- /dev/null
+++ b/ja-jp/articles/_includes/_checksession_polling.md
@@ -0,0 +1,3 @@
+In some multi-application scenarios, where Single Logout is desired (a user logging out of one application needs to be logged out of other applications), an application can be set up to periodically poll Auth0 using `checkSession()` to see if a session exists. If the session does not exist, you can then log the user out of the application. The same polling method can be used to implement silent authentication for a Single Sign-on (SSO) scenario.
+
+The poll interval between checks to `checkSession()` should be at least 15 minutes between calls to avoid any issues in the future with rate limiting of this call.
diff --git a/ja-jp/articles/_includes/_co_authenticate_errors.md b/ja-jp/articles/_includes/_co_authenticate_errors.md
new file mode 100644
index 0000000000..af87d27465
--- /dev/null
+++ b/ja-jp/articles/_includes/_co_authenticate_errors.md
@@ -0,0 +1,26 @@
+## Error Codes and Descriptions 
+
+When ${library} is used for embedded login, it employs the /co/authenticate endpoint, which has the following errors.
+
+::: warning
+The error description is human readable. It **should not be parsed by any code** and it subject to change at any time.
+:::
+
+| Status | Code | Description |
+| --- | --- | --- | --- | 
+| 400 | invalid_request | Invalid request body. All and only of client_id, credential_type, username, otp, realm are required. |
+| 401 | unauthorized_client | Cross origin login not allowed. |
+| 400 | unsupported_credential_type | Unknown credential type parameter. |
+| 400 | invalid_request | Unknown realm non-existent-connection. |
+| 403 | access_denied | Wrong email or password. |
+| 403 | access_denied | Authentication error |
+| 403 | blocked_user | Blocked user |
+| 401 | password_leaked | This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application). |
+| 429 | too_many_attempts | Your account has been blocked after multiple consecutive login attempts. We’ve sent you an email with instructions on how to unblock it. |
+| 429 | too_many_attempts | We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator. |
+
+In addition, you can also get a generic 403 error without an `error` or `error_description` property. The response body would just include something similar to the following:
+
+```text
+Origin https://test.app is not allowed.
+```
diff --git a/ja-jp/articles/_includes/_compat_warning.md b/ja-jp/articles/_includes/_compat_warning.md
new file mode 100644
index 0000000000..2209899342
--- /dev/null
+++ b/ja-jp/articles/_includes/_compat_warning.md
@@ -0,0 +1,3 @@
+::: panel-warning Compatibility Warning
+With the new OAuth 2.0 API Authorization features in Auth0, not everything is fully backwards compatible, including 3rd party hosted Lock. This quickstart tutorial uses Auth0 hosted Lock instead.
+:::
diff --git a/ja-jp/articles/_includes/_contact-sales.md b/ja-jp/articles/_includes/_contact-sales.md
new file mode 100644
index 0000000000..b5a08e1e82
--- /dev/null
+++ b/ja-jp/articles/_includes/_contact-sales.md
@@ -0,0 +1,3 @@
+## More Information
+
+If you have specific support requirements or need more information about the Professional Services we offer, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales).
diff --git a/ja-jp/articles/_includes/_create_resource_server.md b/ja-jp/articles/_includes/_create_resource_server.md
new file mode 100644
index 0000000000..e879837b6a
--- /dev/null
+++ b/ja-jp/articles/_includes/_create_resource_server.md
@@ -0,0 +1,50 @@
+## Create the API
+
+Your resource server (API) needs to be configured to verify the Access Token and any claims contained within it. When you create a resource server in your Auth0 dashboard, it utilizes the RS256 signature method by default, meaning that Access Tokens are signed using Auth0's private key for your account. Verification is done using the corresponding public key. You can read more about the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) standard and also view the [public key(s)](https://${account.namespace}/.well-known/jwks.json) for your Auth0 account (https://${account.namespace}/.well-known/jwks.json). You can also learn how to [manage your signing keys](/tokens/guides/manage-signing-keys).
+
+You can use any [recommended JWT library](https://jwt.io) to validate the standard claims returned in the token. The following example will demonstrate how to create a resource server API with Node. You can find more information about resource server implementations in the [Access Token documentation](https://auth0.com/docs/api-auth/config/asking-for-access-tokens).
+
+The Access Token for your API must be verified against your JSON Web Key Set (JWKS) endpoint. This can be done easily with the **jwks-rsa** library available on npm.
+
+Install the dependencies.
+
+```bash
+npm install express express-jwt jwks-rsa
+```
+
+Create a middleware which uses **express-jwt** and **jwks-rsa** to verify the Access Token against your JWKS endpoint.
+
+```js
+const express = require('express');
+const app = express();
+const jwt = require('express-jwt');
+const jwksRsa = require('jwks-rsa');
+
+const authenticate = jwt({
+  // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint.
+  secret: jwksRsa.expressJwtSecret({
+    cache: true,
+    rateLimit: true,
+    jwksRequestsPerMinute: 5,
+    jwksUri: 'https://${account.namespace}/.well-known/jwks.json'
+  }),
+
+  // Validate the audience and the issuer.
+  audience: '{API IDENTIFIER}',
+  issuer: 'https://${account.namespace}/',
+  algorithms: ['RS256']
+});
+
+app.get('/api/public', function(req, res) {
+  res.json({ message: "Hello from a public endpoint! You don't need to be authenticated to see this." });
+});
+
+app.get('/api/private', authenticate, function(req, res) {
+  res.json({ message: "Hello from a private endpoint! You DO need to be authenticated to see this." });
+});
+
+app.listen(3001);
+console.log('Listening on http://localhost:3001');
+```
+
+Note that you **must** provide the `audience` for your API. This is the identifier you set for it when you create an API in your Auth0 dashboard.
diff --git a/ja-jp/articles/_includes/_deprecate-delegation.md b/ja-jp/articles/_includes/_deprecate-delegation.md
new file mode 100644
index 0000000000..7317d51f14
--- /dev/null
+++ b/ja-jp/articles/_includes/_deprecate-delegation.md
@@ -0,0 +1,3 @@
+::: warning
+By default, delegation is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_deprecate-impersonation.md b/ja-jp/articles/_includes/_deprecate-impersonation.md
new file mode 100644
index 0000000000..4f58b1bb31
--- /dev/null
+++ b/ja-jp/articles/_includes/_deprecate-impersonation.md
@@ -0,0 +1,3 @@
+::: warning
+Impersonation has been deprecated and will not be enabled for new customers. The functionality will continue to work for existing customers who currently have it enabled. If at some point the impersonation feature is changed or removed from service, customers who currently use it will be notified beforehand and given ample time to migrate.
+:::
diff --git a/ja-jp/articles/_includes/_email-domain-blacklist.md b/ja-jp/articles/_includes/_email-domain-blacklist.md
new file mode 100644
index 0000000000..1fdcdd1fc2
--- /dev/null
+++ b/ja-jp/articles/_includes/_email-domain-blacklist.md
@@ -0,0 +1,3 @@
+::: warning
+Auth0 blacklists certain "false" domains commonly used during testing. Use real email addresses to avoid disruption or `domain is blacklisted` errors.
+:::
diff --git a/ja-jp/articles/_includes/_embedded_login_warning.md b/ja-jp/articles/_includes/_embedded_login_warning.md
new file mode 100644
index 0000000000..f37d242c2d
--- /dev/null
+++ b/ja-jp/articles/_includes/_embedded_login_warning.md
@@ -0,0 +1,3 @@
+::: warning
+Embedded login for web uses Cross Origin Authentication. In some browsers [this can be unreliable](/cross-origin-authentication#limitations) if you do not set up a [Custom Domain](/custom-domains) **and host your app on the same domain**. Using Custom Domains with Auth0 is a paid feature. If you cannot use Custom Domains, consider [migrating to Universal Login](/guides/login/migration-embedded-universal).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_enable-third-party-apps-info.md b/ja-jp/articles/_includes/_enable-third-party-apps-info.md
new file mode 100644
index 0000000000..e540021871
--- /dev/null
+++ b/ja-jp/articles/_includes/_enable-third-party-apps-info.md
@@ -0,0 +1,3 @@
+::: note 
+To use this feature, you must [enable third-party applications for your Auth0 tenant](/applications/guides/enable-third-party-apps).
+:::
diff --git a/ja-jp/articles/_includes/_enforce-claim-namespacing.md b/ja-jp/articles/_includes/_enforce-claim-namespacing.md
new file mode 100644
index 0000000000..3b593d6ccf
--- /dev/null
+++ b/ja-jp/articles/_includes/_enforce-claim-namespacing.md
@@ -0,0 +1,5 @@
+::: warning
+By default, Auth0 always enforces namespacing; any custom claims with non-namespaced identifiers will be silently excluded from tokens.
+
+We do allow non-OIDC claims without a namespace for legacy tenants using a non-OIDC-conformant pipeline with the **Legacy User Profile** enabled, but we strongly recommend that legacy tenants migrate to an OIDC-conformant flow.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_http-method.html b/ja-jp/articles/_includes/_http-method.html
new file mode 100644
index 0000000000..cacd38d8f0
--- /dev/null
+++ b/ja-jp/articles/_includes/_http-method.html
@@ -0,0 +1,4 @@
+
    
+  ${http_method}
+  ${path}
+
    
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_ip_whitelist.md b/ja-jp/articles/_includes/_ip_whitelist.md
new file mode 100644
index 0000000000..a3d9ad21b8
--- /dev/null
+++ b/ja-jp/articles/_includes/_ip_whitelist.md
@@ -0,0 +1,3 @@
+::: note Network Firewall
+If you are behind a firewall, this feature may require [whitelisting of the appropriate Auth0 IP addresses](/guides/ip-whitelist) to work properly.
+:::
diff --git a/ja-jp/articles/_includes/_java_new_app.html b/ja-jp/articles/_includes/_java_new_app.html
new file mode 100644
index 0000000000..ddfef608da
--- /dev/null
+++ b/ja-jp/articles/_includes/_java_new_app.html
@@ -0,0 +1,7 @@
+<% if (account.userName) { %>
+  
    Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store them somewhere safe. You will need them while configuring your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.
    
+<% } else { %>
+  
    Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start by downloading the sample after you login as it is configured with your Default App credentials
    
+<% } %>
+
     Make sure that your Auth0 Application has one or more connections configured, for example, Google Social Connection, or username-password DB connection.
+
    
diff --git a/ja-jp/articles/_includes/_libraries_support_frameworks.html b/ja-jp/articles/_includes/_libraries_support_frameworks.html
new file mode 100644
index 0000000000..b14527fae5
--- /dev/null
+++ b/ja-jp/articles/_includes/_libraries_support_frameworks.html
@@ -0,0 +1,41 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    SDKVersionLevel of Support
    Angular Auth0v2
    Supported
    Angular Lockv2
    Supported
    Auth0 Servletv3
    Supported
    Auth0 Java MVC Commonv1
    Supported
    OIDC Client for .NET Desktop and Mobile applicationsv1
    Supported
    JWT Auth Bundlev3
    Supported
    
diff --git a/ja-jp/articles/_includes/_libraries_support_lock.html b/ja-jp/articles/_includes/_libraries_support_lock.html
new file mode 100644
index 0000000000..b23b2b155f
--- /dev/null
+++ b/ja-jp/articles/_includes/_libraries_support_lock.html
@@ -0,0 +1,36 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    LibraryVersionLevel of Support
    Lock.jsv11
    Supported
    Lock.Androidv2
    Supported
    Lock.Androidv1
    Bug fixes
    Lock for iOS v2v2
    Supported
    Lock for iOS v1v1
    Bug fixes
    
diff --git a/ja-jp/articles/_includes/_libraries_support_sdks.html b/ja-jp/articles/_includes/_libraries_support_sdks.html
new file mode 100644
index 0000000000..9fae1bad76
--- /dev/null
+++ b/ja-jp/articles/_includes/_libraries_support_sdks.html
@@ -0,0 +1,61 @@
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    SDKVersionLevel of Support
    Auth0 Single Page Application SDKv1
    Supported
    Auth0 React SDKv1
    Supported
    Auth0.jsv9
    Supported
    Auth0 Androidv1
    Supported
    Auth0 Swiftv1
    Supported
    Auth0 .NETv4
    Supported
    Auth0 Javav1
    Supported
    Auth0 Nodev2
    Supported
    Auth0 Pythonv2
    Supported
    Auth0 PHPv7.3
    Supported
    
diff --git a/ja-jp/articles/_includes/_linking_accounts.md b/ja-jp/articles/_includes/_linking_accounts.md
new file mode 100644
index 0000000000..547909a2a2
--- /dev/null
+++ b/ja-jp/articles/_includes/_linking_accounts.md
@@ -0,0 +1,11 @@
+There may be situations when your users want to log in with multiple accounts that they own. In these cases, you may want to link these accounts together so that they are all reflected in the user's Auth0 profile. For example, if a user has signed up with an email and password (which provides very little information about them), you can ask them to link their account to an OAuth provider like Facebook or Google to gain access to their social profile. See [User Account Linking](/users/concepts/overview-user-account-linking) for details.
+
+## Linking Accounts
+
+To link accounts, call the [link a user account](/api/management/v2#!/Users/post_identities) endpoint. You will need the ID Token and `user_id` of the primary account and the ID Token of the secondary account.
+
+To differentiate the login from the linking login, you will need to create a second instance of `Auth0Lock` to obtain the ID Token of the secondary account.
+
+Since all instances of `Auth0Lock` will receive the `authenticated` event, you will need a way to determine if authentication came from the primary login or the linking login.
+
+You can use the `auth.params` property of the [options object](https://github.com/auth0/lock#authentication-options) of `Auth0Lock` to add a `state` property with the value `'linking'`.
diff --git a/ja-jp/articles/_includes/_lock-sdk.html b/ja-jp/articles/_includes/_lock-sdk.html
new file mode 100644
index 0000000000..d056c8d2da
--- /dev/null
+++ b/ja-jp/articles/_includes/_lock-sdk.html
@@ -0,0 +1,176 @@
+
+<% if (meta.path !== "articles/libraries/lock/v11") { %>
+  
    For more information on using Lock v11 see the documentation.
    
+<% } %>
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    <script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    auth: {
+      redirectUrl: '${account.callback}',
+      responseType: 'code',
+      params: {
+        scope: 'openid email' // Learn about scopes: https://auth0.com/docs/scopes
+      }
+    }
+  });
+</script>
+<button onclick="lock.show();">Login</button>
    
+    
    
+    
    
+      
    <div id="root" style="width: 320px; margin: 40px auto; padding: 10px; border-style: dashed; border-width: 1px; box-sizing: border-box;">
+    embedded area
+</div>
+<script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    container: 'root',
+    auth: {
+      redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+      responseType: 'token id_token',
+      params: {
+        scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+      }
+    }
+  });
+  lock.show();
+</script>
    
+    
    
+    
    
+      
    <script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}', {
+        allowedConnections: ['sms'],             // Should match the SMS connection name  
+        responseType: 'token id_token',
+        auth: {
+          redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+          params: {
+            scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+          }          
+        }
+      }
+  );
+
+  function open() {
+    lock.show();
+  };
+
+</script>
+<button onclick="window.open();">SMS</button>
    
+    
    
+    
+    
    
+      
    <script src="${lock_url}"></script>
+<script>
+  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}', {
+    allowedConnections: ['email'],           // Should match the Email connection name, it defaults to 'email'     
+    passwordlessMethod: 'code',              // If not specified, defaults to 'code'
+    responseType: 'token id_token',
+    auth: {
+      redirectUrl: '${account.callback}',    // If not specified, defaults to the current page 
+      params: {
+        scope: 'openid email'                // Learn about scopes: https://auth0.com/docs/scopes
+      }          
+    }
+  });
+
+  function open() {
+    lock.show();
+  }
+</script>
+<button onclick="window.open();">Email Code</button>
    
+    
    
+    
    
+      
    <button class="signin-google">Sign in with Google (redirect)</button><br>
+<button class="signin-google-popup">Sign in with Google (popup)</button><br>
+<br><p>--- or ---</p>
+<label>Email</label><input type="text" id="email"><br>
+<label>Password</label><input type="password" id="password"><br>
+<button class="signin-db">Sign in with Email/Password</button>
+
+<script src="${auth0js_url}"></script>
+<script src="http://code.jquery.com/jquery.js"></script>
+<script>
+  var webAuth = new auth0.WebAuth({
+    domain:         '${account.namespace}',
+    clientID:       '${account.clientId}',
+    redirectUri:    '${account.callback}'
+  });
+  // sign-in with social provider with plain redirect
+  $('.signin-google').on('click', function() {
+    webAuth.authorize({
+      connection: 'google-oauth2' // use connection identifier
+    });
+  });
+  // sign-in with social provider using a popup (window.open)
+  $('.signin-google-popup').on('click', function() {
+    webAuth.popup.authorize({
+      connection: 'google-oauth2'
+    });
+  });
+
+  $('.signin-db').on('click', function() {
+    webAuth.login({
+      realm: 'tests',
+      username: 'testuser',
+      password: 'testpass',
+    });
+  });
+  // Parse the authentication result
+  webAuth.parseHash((err, authResult) => {
+    if (authResult) {
+      // Save the tokens from the authResult in local storage or a cookie
+      localStorage.setItem('access_token', authResult.accessToken);
+      localStorage.setItem('id_token', authResult.idToken);
+    } else if (err) {
+      // Handle errors
+      console.log(err);
+    }
+  });
+</script>
    
+    
    
+    
+  
    
+
    
diff --git a/ja-jp/articles/_includes/_lock_auth0js_deprecations_notice.md b/ja-jp/articles/_includes/_lock_auth0js_deprecations_notice.md
new file mode 100644
index 0000000000..9e03f9bb98
--- /dev/null
+++ b/ja-jp/articles/_includes/_lock_auth0js_deprecations_notice.md
@@ -0,0 +1,3 @@
+::: panel-warning Lock and Auth0.js Deprecations
+The Lock v8, v9, and v10 widgets as well as the Auth0.js v6, v7, and v8 SDKs are deprecated and should be migrated away from prior to their removal from service on July 16, 2018. 
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_login_auth0_hosted_login_page.md b/ja-jp/articles/_includes/_login_auth0_hosted_login_page.md
new file mode 100644
index 0000000000..78c16d5875
--- /dev/null
+++ b/ja-jp/articles/_includes/_login_auth0_hosted_login_page.md
@@ -0,0 +1 @@
+Auth0's [Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. 
diff --git a/ja-jp/articles/_includes/_logout_url.md b/ja-jp/articles/_includes/_logout_url.md
new file mode 100644
index 0000000000..15197d6bc0
--- /dev/null
+++ b/ja-jp/articles/_includes/_logout_url.md
@@ -0,0 +1,11 @@
+
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that Auth0 can return to after the user has been logged out of the authorization server. This is specified in the `returnTo` query parameter. The logout URL for your app must be added to the **Allowed Logout URLs** field in your [Application Settings](${manage_url}/#/applications). If this field is not set, users will be unable to log out from the application and will get an error.
+
+<% if (typeof(returnTo) !== "undefined") { %>
+  ::: note
+  If you are following along with the sample project you downloaded from the top of this page, the logout URL you need to add to the **Allowed Logout URLs** field is `${returnTo}`.
+  :::
+<% } %>
diff --git a/ja-jp/articles/_includes/_metadata_on_signup_warning.md b/ja-jp/articles/_includes/_metadata_on_signup_warning.md
new file mode 100644
index 0000000000..1af9aab000
--- /dev/null
+++ b/ja-jp/articles/_includes/_metadata_on_signup_warning.md
@@ -0,0 +1,3 @@
+::: note
+When setting the `user_metadata` field using the Authentication API's [Signup endpoint](/api/authentication?javascript#signup), you are limited to a maximum of 10 `String` fields and 500 characters.
+:::
diff --git a/ja-jp/articles/_includes/_native_passwordless_warning.md b/ja-jp/articles/_includes/_native_passwordless_warning.md
new file mode 100644
index 0000000000..04eaae8300
--- /dev/null
+++ b/ja-jp/articles/_includes/_native_passwordless_warning.md
@@ -0,0 +1,3 @@
+::: warning
+This functionality has been deprecated in native. After June 2017, tenants cannot use the native passwordless flow. The functionality will continue to work for tenants that currently have it enabled. If at some point the passwordless mode feature is changed or removed from service, customers who currently use it will be notified beforehand and given ample time to migrate. 
+:::
diff --git a/ja-jp/articles/_includes/_new_api.html b/ja-jp/articles/_includes/_new_api.html
new file mode 100644
index 0000000000..924a36341f
--- /dev/null
+++ b/ja-jp/articles/_includes/_new_api.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
    In the APIs section in dashboard, click the Create API button. Provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
    
+<% } else { %>
+  
    Create an Auth0 account (or login) navigate to the APIs section in Dashboard. Click the Create API button and provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
    
+<% } %>
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_new_app.md b/ja-jp/articles/_includes/_new_app.md
new file mode 100644
index 0000000000..8a8429f0cf
--- /dev/null
+++ b/ja-jp/articles/_includes/_new_app.md
@@ -0,0 +1,28 @@
+## Configure Auth0
+### Get Your Application Keys
+
+When you signed up for Auth0, a new application was created for you, or you could have created a new one. You will need some details about that application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications) section in the Auth0 dashboard.
+
+<% if(typeof hideDashboardScreenshot === 'undefined' || hideDashboardScreenshot !== true) { %>
+![App Dashboard](/media/articles/dashboard/client_settings.png)
+<% } %>
+
+<% if(typeof isPublicClient === 'undefined' || isPublicClient === true) { %>
+::: note
+When using the Default App with a Native or Single Page Application, ensure to update the **Token Endpoint Authentication Method** to `None` and set the **Application Type** to either `SPA` or `Native`. 
+:::
+<% } %>
+
+You need the following information:
+
+* **Domain**
+* **Client ID**
+<% if(typeof showClientSecret !== 'undefined' && showClientSecret === true) { %>
+* **Client Secret**
+<% } %>
+
+<% if(typeof hideDownloadSample === 'undefined' || hideDownloadSample !== true) { %>
+::: note
+If you download the sample from the top of this page, these details are filled out for you.
+:::
+<% } %>
diff --git a/ja-jp/articles/_includes/_new_app_no_sample.html b/ja-jp/articles/_includes/_new_app_no_sample.html
new file mode 100644
index 0000000000..9697d9891d
--- /dev/null
+++ b/ja-jp/articles/_includes/_new_app_no_sample.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
    Get the client ID and domain for your application from the dashboard. 
+<% } else { %>
+  
    Create an Auth0 account (or login) and add an authentication application from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). 
+<% } %>
diff --git a/ja-jp/articles/_includes/_package.html b/ja-jp/articles/_includes/_package.html
new file mode 100644
index 0000000000..b75f53f111
--- /dev/null
+++ b/ja-jp/articles/_includes/_package.html
@@ -0,0 +1,41 @@
+
    
+  
    
+    
    
+      
    Sample Project
    
+      <% if (account.userName) { %>
+      
    
+        Download a sample project specific to this tutorial configured with your Auth0 API Keys.
+      
    
+      <% } else { %>
+      
    
+        Download a sample project specific to this tutorial to get started.
+        
    
+        
+      
    
+      <% } %>
+    
    
+    
    
+      <% if (typeof branch !== 'undefined') { %>
+      Download
+      Fork on Github
+      <% } else { %>
+      Download
+      Fork on Github
+      <% } %>
+    
    
+  
    
+  <% if (typeof requirements !== 'undefined') { %>
+  
    
+    
    System Requirements
    
+    
      
+      <% requirements.forEach(req => { %>
+      
    • ${req}
      • 
+      <% }); %>
+    
    
+  
    
+  
    
+    Show requirements
+    
+  
    
+  <% } %>
+
    
diff --git a/ja-jp/articles/_includes/_parental-consent.md b/ja-jp/articles/_includes/_parental-consent.md
new file mode 100644
index 0000000000..eaa0337c61
--- /dev/null
+++ b/ja-jp/articles/_includes/_parental-consent.md
@@ -0,0 +1,3 @@
+::: note
+If you require a specialized consent prompt, for example a parental consent, you need to build your own custom consent form. Be aware that laws vary according to country.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_pipeline2.md b/ja-jp/articles/_includes/_pipeline2.md
new file mode 100644
index 0000000000..0bd9cbb5c8
--- /dev/null
+++ b/ja-jp/articles/_includes/_pipeline2.md
@@ -0,0 +1,3 @@
+::: note
+Heads up! As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. For an overview of these changes, and details on how you adopt them, refer to Introducing OIDC Conformant Authentication.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_rbac_methods.md b/ja-jp/articles/_includes/_rbac_methods.md
new file mode 100644
index 0000000000..57feb5baa3
--- /dev/null
+++ b/ja-jp/articles/_includes/_rbac_methods.md
@@ -0,0 +1,8 @@
+Currently, we provide two ways of implementing [role-based access control (RBAC)](/authorization/concepts/rbac), which you can use in place of or in combination with your API's own internal access control system:
+
+* [Authorization Core](/authorization/guides/how-to)
+* [Authorization Extension](/extensions/authorization-extension)
+
+We are expanding our Authorization Core feature set to match the functionality of the Authorization Extension. Our new core RBAC implementation improves performance and scalability and will eventually provide a more flexible RBAC system than the Authorization Extension.
+
+For now, both implement the key features of RBAC and allow you to restrict the custom scopes defined for an API to those that have been assigned to the user as permissions. For a comparison, see [Authorization Core vs. Authorization Extension](/authorization/concepts/core-vs-extension).
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_rbac_vs_extensions.md b/ja-jp/articles/_includes/_rbac_vs_extensions.md
new file mode 100644
index 0000000000..58e7c0af76
--- /dev/null
+++ b/ja-jp/articles/_includes/_rbac_vs_extensions.md
@@ -0,0 +1,5 @@
+::: warning
+The [Authorization Core](/authorization/guides/how-to) feature set and [Authorization Extension](/extensions/authorization-extension) are completely separate features. To manage groups, roles, or permissions, you will need to use the feature they were originally created in.
+
+Although the [Delegated Administration Extension](/extensions/delegated-admin) and the [Authorization Core](/authorization/guides/how-to) feature set are completely separate features, you can use the Authorization Core feature set to create and manage roles for the DAE if you use a rule. To learn how, see [Sample Use Cases: Rules with Authorization](/authorization/concepts/sample-use-cases-rules#manage-delegated-administration-extension-roles-using-the-authorization-core-feature-set).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_refresh_token_rotation_panel.md b/ja-jp/articles/_includes/_refresh_token_rotation_panel.md
new file mode 100644
index 0000000000..bb3221d0ff
--- /dev/null
+++ b/ja-jp/articles/_includes/_refresh_token_rotation_panel.md
@@ -0,0 +1,3 @@
+::: note
+If you have [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) enabled, a new Refresh Token is generated with each request and issued along with the Access Token. When a Refresh Token is exchanged, the previous Refresh Token is invalidated but information about the relationship is retained by the authorization server.
+:::
diff --git a/ja-jp/articles/_includes/_refresh_token_rotation_recommended.md b/ja-jp/articles/_includes/_refresh_token_rotation_recommended.md
new file mode 100644
index 0000000000..5f52feeac1
--- /dev/null
+++ b/ja-jp/articles/_includes/_refresh_token_rotation_recommended.md
@@ -0,0 +1,3 @@
+::: panel Refresh Token Rotation
+Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies. Auth0 recommends using [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation), which provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
+:::
diff --git a/ja-jp/articles/_includes/_samesite_none.md b/ja-jp/articles/_includes/_samesite_none.md
new file mode 100644
index 0000000000..9449a343c0
--- /dev/null
+++ b/ja-jp/articles/_includes/_samesite_none.md
@@ -0,0 +1,10 @@
+::: note
+Previously in Auth0, the [`samesite` cookie attribute](/sessions/concepts/cookie-attributes) options were `true`, `false`, `strict` or `lax`. If you didn't set the attribute manually, Auth0 would use the default value of `false`.
+
+Effective February 2020, Google Chrome v80 will change the way it handles cookies. To that end, Auth0 plans on implementing the following changes to how it handles cookies:
+
+* Cookies without the `samesite` attribute set will be set to `lax`
+* Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar
+
+The goal of these changes are to improve security and help mitigate CSRF attacks.
+:::
diff --git a/ja-jp/articles/_includes/_test-this-endpoint.md b/ja-jp/articles/_includes/_test-this-endpoint.md
new file mode 100644
index 0000000000..e2d873ea5d
--- /dev/null
+++ b/ja-jp/articles/_includes/_test-this-endpoint.md
@@ -0,0 +1,16 @@
+
+Click on **Install Debugger** to go to the article that explains how (you only have to do this once).
+
+<%
+  var urlUS = 'https://' + account.tenant + '.us.webtask.io/auth0-authentication-api-debugger';
+  var urlEU = 'https://' + account.tenant + '.eu.webtask.io/auth0-authentication-api-debugger';
+  var urlAU = 'https://' + account.tenant + '.au.webtask.io/auth0-authentication-api-debugger';
+%>
+
+
    
+  Install Debugger
+
    
+
+**If you have already installed the extension, skip to the Authentication API Debugger.**
+
+The link varies according to your tenant's region: US West, Europe Central or Australia.
diff --git a/ja-jp/articles/_includes/_test-with-postman.md b/ja-jp/articles/_includes/_test-with-postman.md
new file mode 100644
index 0000000000..559987c872
--- /dev/null
+++ b/ja-jp/articles/_includes/_test-with-postman.md
@@ -0,0 +1,7 @@
+You can test this endpoint using [Postman](https://www.getpostman.com/). We have a preconfigured collection that you can download and use. Simply click the button below. For more info refer to [Using the Auth0 API with our Postman Collections](/api/postman).
+
+
    
+  
+    Run in Postman
+  
+
    
diff --git a/ja-jp/articles/_includes/_token_signature.md b/ja-jp/articles/_includes/_token_signature.md
new file mode 100644
index 0000000000..6af09f7685
--- /dev/null
+++ b/ja-jp/articles/_includes/_token_signature.md
@@ -0,0 +1,9 @@
+
+
+### Verify JWT Token Signature setting
+
+JSON Web Tokens (JWTs) should be signed using the RS256 signing algorithm where possible, as it provides [enhanced security over HS256](https://auth0.com/docs/tokens/concepts/signing-algorithms#our-recommendation).
+
+RS256 is the default, but if you are [running into errors](https://auth0.com/docs/errors/libraries/auth0-js/invalid-token#parsing-an-hs256-signed-id-token-without-an-access-token) you can verify your settings by clicking on **Show Advanced Settings** at the bottom of your Auth0 Application settings screen in the dashboard. Click the **OAuth** tab to show the signature algorithm configuration. **JsonWebToken Signature Algorithm** should be set to **RS256**, and the **OIDC Conformant** setting should be enabled.
+
+![Token Signature Algorithm configuration](/media/articles/applications/token-signature-algorithm.png)
diff --git a/ja-jp/articles/_includes/_topic-links.md b/ja-jp/articles/_includes/_topic-links.md
new file mode 100644
index 0000000000..e330d77284
--- /dev/null
+++ b/ja-jp/articles/_includes/_topic-links.md
@@ -0,0 +1,18 @@
+
      
+<% _.forEach(links, function(path) {
+  var article = cache.get('articles/' + path);
+  %>
+  
    • 
+    ${article.title}
+    
      
+      ${article.description}
+      <% if (article.img) { %>
+				${article.title}
+      <% } %>
+      <% if (article.mobileimg) { %>
+        
      ${article.title}
      
+      <% } %>
+    
      
+  
      • 
+<% }) %>
+
    
diff --git a/ja-jp/articles/_includes/_users_update_normalized_profile_attributes.md b/ja-jp/articles/_includes/_users_update_normalized_profile_attributes.md
new file mode 100644
index 0000000000..822a2e3d50
--- /dev/null
+++ b/ja-jp/articles/_includes/_users_update_normalized_profile_attributes.md
@@ -0,0 +1,3 @@
+By default, user profile attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable because they are updated from the identity provider each time the user logs in.
+
+To be able to edit the `name`, `nickname`, `given_name`, `family_name`, or `picture` root attributes on the normalized user profile, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. These root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/set-root-attributes-user-import) using the Management API.
diff --git a/ja-jp/articles/_includes/_uses-delegation.md b/ja-jp/articles/_includes/_uses-delegation.md
new file mode 100644
index 0000000000..2a157656f4
--- /dev/null
+++ b/ja-jp/articles/_includes/_uses-delegation.md
@@ -0,0 +1,3 @@
+::: warning
+This feature uses delegation. By default, delegation is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate. In addition, note that delegation does not support the use of custom domains so any features depending on it may not be fully functional alongside a custom domain.
+:::
diff --git a/ja-jp/articles/_includes/_version_warning_api.md b/ja-jp/articles/_includes/_version_warning_api.md
new file mode 100644
index 0000000000..bf86f5773c
--- /dev/null
+++ b/ja-jp/articles/_includes/_version_warning_api.md
@@ -0,0 +1,3 @@
+::: warning
+This version of the Management API has been deprecated. We recommend that you use the [new version](/api/management/v2) instead. Please refer to the [Migration Guide](/migrations/guides/management-api-v1-v2) for more information.
+:::
diff --git a/ja-jp/articles/_includes/_version_warning_auth0js.md b/ja-jp/articles/_includes/_version_warning_auth0js.md
new file mode 100644
index 0000000000..3c6104e535
--- /dev/null
+++ b/ja-jp/articles/_includes/_version_warning_auth0js.md
@@ -0,0 +1,3 @@
+::: version-warning
+This document covers a deprecated version of Auth0.js which uses endpoints that have been removed from service. It will no longer function as expected. We recommend that you [migrate to Auth0.js v9](/libraries/auth0js/v9/migration-guide) as soon as possible.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_version_warning_lock.md b/ja-jp/articles/_includes/_version_warning_lock.md
new file mode 100644
index 0000000000..707490b682
--- /dev/null
+++ b/ja-jp/articles/_includes/_version_warning_lock.md
@@ -0,0 +1,3 @@
+::: version-warning
+This document covers a deprecated version of Lock which uses endpoints that have been removed from service. It will no longer function as expected. We recommend that you migrate to Lock v11 as soon as possible.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/_includes/_video.md b/ja-jp/articles/_includes/_video.md
new file mode 100644
index 0000000000..7eed662b37
--- /dev/null
+++ b/ja-jp/articles/_includes/_video.md
@@ -0,0 +1,3 @@
+
+
diff --git a/ja-jp/articles/_includes/_web_origins.md b/ja-jp/articles/_includes/_web_origins.md
new file mode 100644
index 0000000000..57364906f5
--- /dev/null
+++ b/ja-jp/articles/_includes/_web_origins.md
@@ -0,0 +1,5 @@
+
+
+### Configure Allowed Web Origins
+
+You need to add the URL for your app to the **Allowed Web Origins** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). If you don't register your application URL here, the application will be unable to silently refresh the authentication tokens and your users will be logged out the next time they visit the application, or refresh the page.
diff --git a/ja-jp/articles/_includes/_webtask.md b/ja-jp/articles/_includes/_webtask.md
new file mode 100644
index 0000000000..71356fc124
--- /dev/null
+++ b/ja-jp/articles/_includes/_webtask.md
@@ -0,0 +1,3 @@
+::: warning
+Only tenants created prior to 17 July 2018 have access to Webtask.io and the Webtask CLI. If you are an enterprise customer with a newer tenant, please contact your account representative to request access. Other requests can be made through the [Auth0 Contact Form](https://auth0.com/get-started?place=documentation%20post&type=link&text=auth0%20contact%20form) and will be evaluated on a case-by-case basis.
+:::
diff --git a/ja-jp/articles/addons/azure-blob-storage.md b/ja-jp/articles/addons/azure-blob-storage.md
new file mode 100644
index 0000000000..fa945a5c8b
--- /dev/null
+++ b/ja-jp/articles/addons/azure-blob-storage.md
@@ -0,0 +1,58 @@
+---
+addon: Azure Blob Storage
+title: Azure Blob Storage Add-on
+thirdParty: true
+public: false
+url: /addons/azure-blob-storage
+alias:
+  - azure blob storage
+  - azblob
+image: /media/platforms/azure.png
+topics:
+  - quickstart
+  - azure
+  - addons
+articles:
+  - authenticate
+contentType: how-to
+description: Learn how to use Auth0 to authenticate and authorize Azure Blob Storage.
+useCase: integrate-third-party-apps
+---
+
+# Azure Blob Storage Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+Here's a sample call to the delegation endpoint to get the Shared Access Signature (SAS):
+
+```text
+POST https://${account.namespace}/delegation
+Content-Type: 'application/json'
+{
+  "client_id":   "${account.clientId}",
+  "grant_type":  "urn:ietf:params:oauth:grant-type:jwt-bearer",
+  "id_token":    "YOUR_ID_TOKEN",
+  "target":      "${account.clientId}",
+  "api_type":    "azure_blob",
+  "scope":       "openid"
+}
+```
+
+* The `client_id` value identifies the requesting app (such as your website) and `YOUR_ID_TOKEN` identifies the user you are requesting this on behalf-of. (Notice that the `id_token` is signed with the `client_id` corresponding `clientSecret`).
+* The `target` parameter identifies this API endpoint in Auth0 (often the same as `${account.clientId}`. This is the `client_id` of the app where this add-on has been enabled.
+* `api_type` must be `azure_blob`.
+* `scope` must be `openid`.
+
+The result of calling the delegation endpoint will be something like:
+
+```json
+{
+  "azure_blob_sas": "st=2015-01-08T18%3A45%3A14Z&se=2015-01-08T18%3A50%3A14Z&sp=r&sv=2014-02-14&sr=b&sig=13ABC456..."
+}
+```
+
+You can use the blob SAS token either by appending it to a URL directly or by passing it to one of the Azure Storage SDKs.
+
+```text
+GET https://{STORAGEACCOUNT}.blob.core.windows.net/mycontainer/myblob.txt?st=2015-01-08T18%3A45%3A14Z&se=2015-01-08T18%3A50%3A14Z&sp=r&sv=2014-02-14&sr=b&sig=13ABC456...
+```
diff --git a/ja-jp/articles/addons/azure-mobile-services.md b/ja-jp/articles/addons/azure-mobile-services.md
new file mode 100644
index 0000000000..2d88dd226a
--- /dev/null
+++ b/ja-jp/articles/addons/azure-mobile-services.md
@@ -0,0 +1,80 @@
+---
+addon: Windows Azure Mobile Services
+title: Windows Azure Mobile Services Add-on
+thirdParty: true
+public: false
+url: /addons/azure-mobile-services
+image: /media/platforms/azure.png
+snippets:
+  use: server-apis/azure-mobile-services/use
+alias:
+  - windows-azure
+  - microsoft-azure
+  - windows-azure-websites
+  - windows-azure-vm
+  - azure-websites
+  - azure-vm
+topics:
+  - azure
+  - mobile
+  - addons
+contentType: how-to
+useCase: integrate-third-party-apps
+description: Learn how to use Auth0 to authenticate and authorize Windows Azure Mobile Services (WAMS).
+---
+
+# Windows Azure Mobile Services Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+## 1. Create an application
+
+Windows Azure Mobile Services (WAMS) endpoints can be used from anywhere. To configure an app that interacts with WAMS, you can use any of the following tutorials:
+
+- [Android](/quickstart/native/android)
+- [iOS](/quickstart/native/ios-objc)
+- [Windows UWP C#](/quickstart/native/windows-uwp-csharp)
+- [JavaScript](/quickstart/spa/vanillajs)
+- [Windows Phone](/quickstart/native/wpf-winforms)
+
+The samples that you can download from the Azure Portal are a good starting point.
+
+![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-4.png)
+
+## 2. Modify the sample to use Auth0
+
+If you follow the Windows UWP sample (C#), you will end up with an `AuthenticateAsync` method that adds one of the standard WAMS authentication mechanisms.
+
+To modify the sample to use Auth0, include this code:
+
+${snippet(meta.snippets.use)}
+
+The important aspects of these lines are:
+
+1. The `Auth0Client` class takes 2 parameters: your `namespace` and the `clientId` of the application.
+2. There are various overloads for the  `LoginAsync` method. In the example above, all options will be presented to the user. You can use other versions of `LoginAsync` to direct login to a specific provider. For example: `LoginAsync("github")` will have users login exclusively with GitHub.
+3. The `GetDelegationToken` call exchanges the application token (received in step #2) for another token to be used with WAMS.
+4. The input for the `GetDelegationToken` method is the `clientID` of your WAMS enabled app.
+5. A new `MobileServiceUser` object is created with the new information.
+
+The `GetDelegationToken` call allows your app to interact with multiple WAMS APIs (or even other APIs). In Auth0, you can control which applications can call which API.
+
+For example, you can login a user with GitHub, then connect them to WAMS and also interact with an AWS hosted endpoint. The delegation call allows you to flow the identity of the user securely across multiple environments.
+
+## 3. Use the user identity in the WAMS backend
+
+The final step is to use the information in the token in the server code. Most likely you will have to do the following two things:
+
+1. Change permissions on the table for each operation:
+
+  ![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-5.png)
+
+2. Use the `user` object to change the behavior of the operation.
+
+This example inserts the `userId` on new rows:
+
+![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-6.png)
+
+Then, when querying, it filters out rows for the logged in user:
+
+![](/media/articles/server-apis/azure-mobile-services/wams-tutorial-7.png)
diff --git a/ja-jp/articles/addons/azure-sb.md b/ja-jp/articles/addons/azure-sb.md
new file mode 100644
index 0000000000..da89208289
--- /dev/null
+++ b/ja-jp/articles/addons/azure-sb.md
@@ -0,0 +1,51 @@
+---
+addon: Azure Service Bus
+title: Azure Service Bus Add-on
+thirdParty: true
+public: false
+url: /addons/azure-sb
+alias:
+  - Azure Service Bus
+image: /media/platforms/azure.png
+topics:
+  - quickstart
+  - azure
+  - addons
+articles:
+  - authenticate
+contentType: how-to
+useCase: integrate-third-party-apps
+description: Learn how to use Auth0 to authenticate and authorize Azure Service Bus.
+---
+
+# Azure Service Bus Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+Here's a sample call to the delegation endpoint to get the Shared Access Signature (SAS):
+
+```text
+POST https://${account.namespace}/delegation
+Content-Type: 'application/json'
+{
+  "client_id":   "${account.clientId}",
+  "grant_type":  "urn:ietf:params:oauth:grant-type:jwt-bearer",
+  "id_token":    "{YOUR_ID_TOKEN}",
+  "target":      "${account.clientId}",
+  "api_type":    "azure_sb",
+  "scope":       "openid"
+}
+```
+
+* The `client_id` value identifies the requesting app (such as your website) and `{YOUR_ID_TOKEN}` identifies the user you are requesting this on behalf-of. (Notice that the `id_token` is signed with the `client_id` corresponding `clientSecret`).
+* The `target` parameter identifies this API endpoint in Auth0 (often the same as `{CLIENT ID}`. This is the `client_id` of the app where this add-on has been enabled.
+* `api_type` must be `azure_sb`.
+* `scope` must be `openid`.
+
+The result of calling the delegation endpoint will be something like:
+
+```json
+{
+  "azure_sb_sas": "SharedAccessSignature sig=k8bNfT81R8L...LztXvY%3D&se=14098336&skn=PolicyName&sr=http%3A%2F%2Fnamespace.servicebus.windows.net%2Fmy_queue"
+}
+```
diff --git a/ja-jp/articles/addons/index.md b/ja-jp/articles/addons/index.md
new file mode 100644
index 0000000000..bd86928457
--- /dev/null
+++ b/ja-jp/articles/addons/index.md
@@ -0,0 +1,48 @@
+---
+url: /addons
+title: Add-ons
+description: Learn about add-ons and how they are related to Auth0-registered Applications.
+public: false
+topics:
+  - applications
+  - add-ons
+contentType:
+  - concept
+  - index
+useCase:
+  - build-an-app
+  - integrate-third-party-apps
+---
+
+# Add-ons
+
+<%= include('../_includes/_uses-delegation') %>
+
+Add-ons are plugins associated with an application registered with Auth0. Usually, they are third-party APIs used by application(s) for which Auth0 generates Access Tokens (e.g., Salesforce, Azure Service Bus, Windows Azure Mobile Services, SAP).
+
+Some typical scenarios for using add-ons include:
+
+* **Accessing External APIs**: Using the Delegation endpoint, you can exchange your application's Access Token for a third-party service's (e.g., Salesforce, Amazon) Access Token.
+
+* **Integrating with Applications using SAML2/WS-Federation**: Since Add-ons allow you to configure every aspect of the SAML2/WS-Federation integration, they allow you to integrate with any custom or Single Sign-on (SSO) integration that does not currently enjoy built-in Auth0 support.
+
+![Addons Example Diagram](/media/articles/applications/applications-addon-types.png)
+
+## Available Add-ons
+
+- Amazon Web Services
+- Firebase
+- Layer
+- Salesforce
+- Salesforce (Sandbox)
+- SAP
+- Azure Mobile Services
+- Azure Service Bus
+- Azure Blob Storage
+- SAML2
+- WS-Fed
+
+## Keep reading
+
+- [View Add-ons](/dashboard/guides/applications/view-addons)
+- [Set Up Add-Ons](/dashboard/guides/applications/set-up-addons)
\ No newline at end of file
diff --git a/ja-jp/articles/addons/salesforce-sandbox.md b/ja-jp/articles/addons/salesforce-sandbox.md
new file mode 100644
index 0000000000..79bd815fe1
--- /dev/null
+++ b/ja-jp/articles/addons/salesforce-sandbox.md
@@ -0,0 +1,28 @@
+---
+addon: Salesforce (sandbox)
+title: Salesforce (Sandbox) Add-on
+thirdParty: true
+public: false
+url: /addons/salesforce-sandbox
+alias:
+  - salesforce
+image: /media/addons/salesforce_sandbox_api.svg
+description: Learn how to use Auth0 to authenticate and authorize your Salesforce (Sandbox) services.
+topics:
+  - salesforce
+  - addons
+useCase: integrate-third-party-apps
+contentType: how-to
+---
+
+# Salesforce (Sandbox) Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+Auth0 supports both the __production__ connection to Salesforce and the __Sandbox__, the only difference being the endpoints hosted by Salesforce: `https://login.salesforce.com` and `https://test.salesforce.com`, respectively.
+
+::: note
+  Under the hood, Auth0 uses OAuth 2.0 JWT Bearer Token Flow to obtain an Access Token. All details of construction of the right JWT are taken care of by Auth0.
+:::
+
+![](/media/articles/server-apis/salesforce-data-flow.png)
diff --git a/ja-jp/articles/addons/salesforce.md b/ja-jp/articles/addons/salesforce.md
new file mode 100644
index 0000000000..54aa6bb93e
--- /dev/null
+++ b/ja-jp/articles/addons/salesforce.md
@@ -0,0 +1,38 @@
+---
+addon: Salesforce
+title: Salesforce Add-on
+alias:
+  - salesforce
+url: addons/salesforce  
+thirdParty: true
+public: false
+image: /media/addons/salesforce.svg
+description: Learn how to use Auth0 to authenticate and authorize your Salesforce services.
+topics:
+  - salesforce
+  - addons
+useCase: integrate-third-party-apps
+contentType: how-to
+---
+
+# Salesforce Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+Auth0 supports both the __production__ connection to Salesforce and the __Sandbox__, the only difference being the endpoints hosted by Salesforce: `https://login.salesforce.com` and `https://test.salesforce.com`, respectively.
+
+The integration also supports getting tokens for __Salesforce Community Sites__. For this to work, you need to pass two additional parameters:
+
+```
+...
+community_name: 'mycommunity',
+community_url_section: 'members'
+...
+
+```
+
+::: note
+  Under the hood, Auth0 uses OAuth 2.0 JWT Bearer Token Flow to obtain an Access Token. All details of construction of the right JWT are taken care of by Auth0.
+:::
+
+![Salesforce data flow](/media/articles/server-apis/salesforce-data-flow.png)
diff --git a/ja-jp/articles/addons/sap-odata.md b/ja-jp/articles/addons/sap-odata.md
new file mode 100644
index 0000000000..4c5db1bcce
--- /dev/null
+++ b/ja-jp/articles/addons/sap-odata.md
@@ -0,0 +1,30 @@
+---
+addon: SAP OData
+title: SAP OData Add-on
+alias:
+  - sap
+url: /addons/sap-odata
+image: /media/addons/sap_api.svg
+description: Learn how to use Auth0 to authenticate and authorize your SAP OData services.
+public: false
+topics:
+  - sap
+  - addons
+  - odata
+useCase: integrate-third-party-apps
+contentType: how-to
+---
+
+# SAP OData Add-on
+
+<%= include('../_includes/_uses-delegation') %>
+
+::: warning
+This integration is in experimental mode. Contact us if you have questions.
+:::
+
+::: note
+  Under the hood, Auth0 uses SAML 2.0 Bearer Assertion Flow for OAuth 2.0 to obtain an Access Token. All details of construction of the right SAML token are taken care of by Auth0.
+:::
+
+![](/media/articles/server-apis/sap-data-flow.png)
diff --git a/ja-jp/articles/analytics/_includes/_install.md b/ja-jp/articles/analytics/_includes/_install.md
new file mode 100755
index 0000000000..4e86feb323
--- /dev/null
+++ b/ja-jp/articles/analytics/_includes/_install.md
@@ -0,0 +1,20 @@
+## Install
+
+To add the <%- name %> integration to your app, include a reference to the `Auth0 Analytics.js` script on any pages with Auth0 Lock. Include the script reference **after**** Lock *and* set the configuration options before the script reference.
+
+```
+
+
+
+```
+
+::: note
+The script version above uses a placeholder version `X.Y.Z`. For example, to reference release, 1.3.1 use `https://cdn.auth0.com/js/analytics/1.3.1/analytics.min.js`. You can [find the latest release's version number](https://github.com/auth0/auth0-analytics.js/releases/) on GitHub.
+:::
diff --git a/ja-jp/articles/analytics/_includes/_usage.md b/ja-jp/articles/analytics/_includes/_usage.md
new file mode 100755
index 0000000000..9d4a7485c2
--- /dev/null
+++ b/ja-jp/articles/analytics/_includes/_usage.md
@@ -0,0 +1,20 @@
+## Usage
+
+After installation on your site, you will start collecting data. Auth0 Analytics will immediately begin sending events to <%- name %>.
+
+You will see the following events being logged:
+
+* Auth0 Lock show
+* Auth0 Lock hide
+* Auth0 Lock unrecoverable_error
+* Auth0 Lock authenticated
+* Auth0 Lock authorization_error
+* Auth0 Lock forgot_password ready
+* Auth0 Lock forgot_password submit
+* Auth0 Lock signin submit
+* Auth0 Lock signup submit
+* Auth0 Lock federated login
+
+Note that some events that Lock emits like `hash_parsed` are not used for analytics purposes. Also, be aware that some events are only available in newer versions of Lock. If you are using an older version of Lock you will only see some of these events. We suggest upgrading to the latest version of Lock to get the most of the Auth0 Analytics integration.
+
+For more information on the events that are sent see the [Lock API documentation](/libraries/lock/v11/api#on-).
diff --git a/ja-jp/articles/analytics/guides/facebook-analytics.md b/ja-jp/articles/analytics/guides/facebook-analytics.md
new file mode 100644
index 0000000000..bc4093476f
--- /dev/null
+++ b/ja-jp/articles/analytics/guides/facebook-analytics.md
@@ -0,0 +1,69 @@
+---
+description: Learn how to install and configure the Facebook Analytics for Auth0 integration.
+topics:
+  - facebook
+  - analytics
+public: false
+contentType: how-to
+useCase:
+  - manage-analytics
+  - analyze-external-analytics
+---
+# Integrate Facebook Analytics with Auth0
+
+Install and configure the **Facebook Analytics for Auth0** integration on your own page that is using [Lock](/libraries/lock) or the [hosted Lock pages](/universal-login). You can configure funnels and reports inside of Facebook Analytics to get the most out of this integration.
+
+<%= include('../_includes/_install', { name: "Facebook Analytics" }) %>
+
+## Setup
+
+If you already have either the Facebook Tracking Pixel or the Facebook Javascript SDK referenced on your site, configure Auth0 Analytics with the `preload` option as shown below. If you don't have either script loaded you need to set your Facebook Analytics App ID using the Facebook Javascript SDK configuration below.
+
+We recommend [creating funnels](https://www.facebook.com/help/analytics/935921203105136) to measure the success of your acquisition and registration flows using these new events.
+
+### Configure Facebook Javascript SDK (Recommended)
+
+The simplest configuration is to let the Analytics script load the Facebook Javascript SDK. You can do this by providing your Facebook Analytics App ID to the analytics options as shown below.
+
+```
+
+```
+
+If you have already loaded the Facebook Javascript SDK on your site, configure Auth0 Analytics to not load it again as shown below.
+
+```
+
+```
+
+### Configure Facebook Pixel
+
+If you already have the Facebook Pixel installed on your site you can use that configuration mode. Note that with the Facebook Pixel, certain features of Facebook Analytics are not available. The configuration for using the pixel is shown below.
+
+```
+
+```
+
+<%= include('../_includes/_usage', { name: "Facebook Analytics" }) %>
+
+## Keep reading
+
+[Facebook Analytics documentation](https://www.facebook.com/help/analytics/1710582659188030)
+
diff --git a/ja-jp/articles/analytics/guides/google-analytics.md b/ja-jp/articles/analytics/guides/google-analytics.md
new file mode 100644
index 0000000000..4367921202
--- /dev/null
+++ b/ja-jp/articles/analytics/guides/google-analytics.md
@@ -0,0 +1,46 @@
+---
+description: Learn how to install and configure the Google Analytics for Auth0 integration.
+topics:
+  - google
+  - analytics
+public: false
+contentType: how-to
+useCase:
+  - manage-analytics
+  - analyze-external-analytics
+---
+# Integrate Google Analytics with Auth0
+
+This article explains how to install and configure the **Google Analytics for Auth0** integration. You can use this integration on your own page that is using Lock. You can configure funnels and reports inside of Google Analytics to get the most out of this integration.
+
+## Setup
+
+1. Set analytics configuration options *before* you include the references to the Lock and Auth0 Analytics libraries.
+
+    ```javascript
+    
+    ```
+
+2. Include the script reference to the `auth0-analytics.js`. This needs to be included *after* the call to Lock.
+
+    ```javascript
+    
+    
+    ```
+
+::: note
+The script version above uses a placeholder version `X.Y.Z`. For example, to reference release 1.3.1 use `https://cdn.auth0.com/js/analytics/1.3.1/analytics.min.js`. You can [find the latest release's version number](https://github.com/auth0/auth0-analytics.js/releases/) on GitHub.
+:::
+
+<%= include('../_includes/_usage', { name: "Google Analytics" }) %>
+
+## Keep reading
+
+[Google Analytics documentation](https://support.google.com/analytics)
diff --git a/ja-jp/articles/analytics/index.md b/ja-jp/articles/analytics/index.md
new file mode 100755
index 0000000000..b40e0508b0
--- /dev/null
+++ b/ja-jp/articles/analytics/index.md
@@ -0,0 +1,38 @@
+---
+url: /analytics
+section: articles
+classes: topic-page
+title: Analytics Integrations
+topics:
+  - analytics
+public: false
+contentType: index
+useCase:
+  - manage-analytics
+  - analyze-external-analytics
+---
+
+
    
+  
    
+  
    Analytics Integrations
    
+  
    
+    Setup and configure analytics integrations with Auth0.
+  
    
+
    
+
+Analytics tools help you track users on your site or application. Integrating third-party analytics tools with Auth0 enables you to capture and measure identity specific events. You can use this data to create funnels, measure user retention, and improve your sign up flow.
+
+
diff --git a/ja-jp/articles/anomaly-detection/concepts/breached-passwords.md b/ja-jp/articles/anomaly-detection/concepts/breached-passwords.md
new file mode 100644
index 0000000000..92f077dc01
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/concepts/breached-passwords.md
@@ -0,0 +1,64 @@
+---
+title: Breached Password Security
+description: Understand why a user receives a breached password email and general web security tips.
+topics:
+    - security
+    - passwords
+contentType: concept
+useCase: customize-anomaly-detection
+v2: true
+---
+
+# Breached Password Security
+
+When a user receives an email requesting that they change their password immediately, it is because their account could be the victim of a security breach. This may be the result of a compromise by a third-party application that experienced a security breach. The breach may not have happened to this account, but based on available data, the user's credentials may have been released. Since many people reuse passwords, the request to change passwords is a precaution to make sure the user stays protected. 
+
+Users may also want to change their password at any other sites where they suspect they used a shared password. 
+
+## General security tips
+
+Users can't usually prevent certain sites from experiencing security breaches, but there are some things they can do to help keep their accounts safe.
+
+### Check emails carefully
+
+Check where an email is coming from and the links that they provide. Often phishing emails do not include a user's name but something generic such as "Dear Customer."  
+
+### Reset passwords directly from sites
+
+Always do a password reset through the actual site itself not via potentially false links in emails. Also note that secure website URL always starts with `https`.
+
+Here are some links for password resets on commonly used sites:
+* [Google](https://www.google.com/accounts/recovery/)
+* [Facebook](https://www.facebook.com/settings)
+* [Twitter](https://twitter.com/settings/password)
+
+### Never enter personal or financial information in email
+
+Emails in general are not very secure and are not a good way to communicate sensitive information. A trusted company/application would not ask for  information in this way. Make sure not to enter confidential information through false links in emails. 
+
+### Never download files from unreliable sources
+
+Most web browsers detect suspicious sites. An alert should appear when you try to access a malicious site. Never download files from suspicious emails or websites.
+
+### Do not reuse passwords
+
+When one site has a breach of user data, if a user uses the same credentials elsewhere, information in other sites can also be accessed. The only way to prevent this is by not reusing passwords for multiple sites. The problem is that remembering countless passwords is frustrating and often impossible. One solution to this problem is the use of a password manager. There are many password managers available which can help users to use separate and secure passwords for each account, but at the same time not be responsible for remembering all of them. 
+
+### Use strong passwords
+
+The longer a password is, the harder it becomes to be guessed via brute force methods. Many sites allow the use of pass-phrases (a phrase or sentence instead of just a complicate word.) Try to make passwords long and use a mix of special characters, numbers, and upper- and lowercase letters.
+
+### Keep software current
+
+Applications release patches and updates when they find security vulnerabilities in their systems. Keeping applications, web browsers, and operating systems up to date can help prevent security breaches.
+
+### Check the security of your email inbox
+
+If you use Gmail, Google offers the [Security Checkup](https://myaccount.google.com/security-checkup) tool to let you know if there are any security issues related to your inbox.
+
+You can also use third-party tools, such as websites like [HaveIBeenPwned](https://haveibeenpwned.com/PwnedWebsites) to see if there might be security issues associated with your email address.
+
+## Keep reading
+
+* [Anomaly Detection](/anomaly-detection)
+* [Customize Blocked Account Emails](/anomaly-detection/guides/customize-blocked-account-emails)
diff --git a/ja-jp/articles/anomaly-detection/guides/customize-blocked-account-emails.md b/ja-jp/articles/anomaly-detection/guides/customize-blocked-account-emails.md
new file mode 100644
index 0000000000..1347250973
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/guides/customize-blocked-account-emails.md
@@ -0,0 +1,30 @@
+---
+title: Customize Blocked Account Emails
+description: Learn how to customize blocked account emails.
+topics:
+    - security
+    - anomaly-detection
+    - brute-force-protection
+    - breached-password-detection
+contentType: how-to
+useCase: customize-anomaly-detection
+v2: true
+---
+# Customize Blocked Account Emails
+
+When Auth0 sends an email to a user to notify them of the [breached password block action](/anomaly-detection/references/breached-password-detection-triggers-actions), the message contains a link to re-enable the origin of the request.
+
+::: note
+Auth0 never blocks the user itself, just the attempts from the suspicious origin.
+:::
+
+The email sent to the user looks like this:
+
+![Email Example](/media/articles/brute-force-protection/bfp-2015-12-29_1832.png)
+
+You can customize the template used for this message on the [Dashboard](${manage_url}/#/emails) under __Emails > Templates > Blocked Account Email__.
+
+## Keep reading
+
+* Learn more about [email templates](/email/templates).
+* Understand [why a user receives a breached password email](/anomaly-detection/concepts/breached-passwords) and general web security tips.
diff --git a/ja-jp/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md b/ja-jp/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md
new file mode 100644
index 0000000000..e40844c3be
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/guides/enable-disable-brute-force-protection.md
@@ -0,0 +1,29 @@
+---
+title: Enable and Disable Brute-Force Protection
+description: Learn how to disable and enable brute-force protection.
+topics:
+    - security
+    - anomaly-detection
+    - brute-force-protection
+contentType: how-to
+useCase: customize-anomaly-detection
+v2: true
+---
+# Enable and Disable Brute-Force Protection
+
+Brute-force protection is enabled by default for all connections.
+
+![Brute-Force Protection Shield](/media/articles/anomaly-detection/anomaly-detection-overview.png)
+
+::: warning
+Auth0 strongly recommends that you **do not** set the `brute_force_protection` flag to `false` (effectively disabling brute-force protection for the connection), however if you do, you can change it back in the [Dashboard](${manage_url}/#/anomaly).
+::: 
+
+Once enabled, you can [customize](/anomaly-detection/guides/set-anomaly-detection-preferences#brute-force-protection-preferences) your brute-force protection settings.
+
+![Brute-Force Protection Shield](/media/articles/anomaly-detection/brute-force-shield.png)
+
+## Keep reading
+
+* [Brute-Force Protection Triggers and Actions](/anomaly-detection/references/brute-force-protection-triggers-actions)
+* [Set Anomaly Detection Preferences](/anomaly-detection/guides/set-anomaly-detection-preferences)
\ No newline at end of file
diff --git a/ja-jp/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md b/ja-jp/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md
new file mode 100644
index 0000000000..c4d5d0b291
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/guides/prevent-credential-stuffing-attacks.md
@@ -0,0 +1,91 @@
+---
+title: Prevent Credential Stuffing Attacks
+description: Learn how to prevent credential stuffing attacks on your system. 
+beta: true
+topics:
+    - anomaly-detection
+    - credential-stuffing
+contentType: how-to
+useCase:
+  - prevent-credential-stuffing
+---
+# Prevent Credential Stuffing Attacks
+
+Credential stuffing attacks (also known as *list validation attacks*) occur when bad actors automate the process of trying username and password combinations (usually stolen from another site) for many accounts in a short period of time.  According to recent statistics, as many as 71% of accounts use the same password across multiple sites so a credential stuffing attack has the potential to successfully log into your system.  
+
+Consider, for example, the number of errors caused by an incorrect email or username (identified in the logs as type `fu`) for a particular tenant, which suggests an attack occurred November 20, with some abuse patterns afterwards:
+
+![Credential Stuffing Attack Example](/media/articles/anomaly-detection/credential-stuffing-attack.png)
+
+Auth0 provides a number of tools to combat credential stuffing attacks:  
+
+* [Brute Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection) blocks login attempts after a number of consecutive failed logins. 
+
+* [Breached Password Protection](/anomaly-detection/concepts/breached-passwords) identifies credentials that are known to be stolen.
+
+* [Multi-factor Authentication](/mfa) can be effective in preventing unauthorized logins, but it adds friction to the user experience. 
+
+If you do not want to turn on additional features such as MFA, you can add **Automated Credential Stuffing Attack Protection** to provide a standard level of protection against credential stuffing attacks that does not add any friction to legitimate users. 
+
+## How it works
+
+Auth0 uses a large amount of data to identify patterns that signal that a credential stuffing attack is taking place. Auth0 uses sophisticated algorithms to determine when bursts of traffic are likely to be from a bot or script. Users attempting to sign in from IPs which are determined to have a high likelihood of being a credential stuffing attack will see a Captcha step. The algorithms are designed so that this only happens for bad traffic; the objective is to not show any friction to legitimate users.
+
+![Captcha Login Screen Example](/media/articles/anomaly-detection/captcha-login-screen.png)
+
+## Enable automated credential stuffing attack protection
+
+### Prerequisites
+
+* Please read Auth0’s [Beta Service Terms](https://cdn.auth0.com/website/legal/terms/beta-service-terms-11-18-19.pdf) and acknowledge you have read and agreed to the terms by emailing **Antonio Fuentes** at **antonio.fuentes@auth0.com**.
+
+* Determine which type of login experience you have configured: 
+
+    - Go to [Dashboard](${manage_url}/#). 
+    - Navigate to **Universal Login**. 
+    - Determine which login experience is selected (Classic or New).
+    
+### If you are using New Universal Login
+
+No further configuration is required. If you are part of the Beta program, the Early Access features will work for your tenant immediately.
+
+### If you are using Classic Universal Login
+
+Determine if your page is customized. 
+
+1. Select the **Login** tab. 
+
+2. Verify the status of the toggle **Customize Login Page**. 
+
+3. If it is on, you have a customized login page. 
+
+### If you are using customized Classic Universal Login
+
+Upgrade your version of Lock.
+
+1. Navigate to the **Universal Login** section in the Dashboard. 
+
+2. Select the **Login** tab. 
+
+3. Update your version of Auth0’s Lock to version v11.20 by replacing the script tag with the tag for version v11.20. 
+
+For example, replace this tag:
+```html
+
+```
+
+With the following:
+```html
+
+```
+
+## Performance impact
+
+This feature is intended to reduce the number of login attempts associated with automated or scripted credential stuffing attacks. It is not expected to cause a degradation in the latency or performance of the login flows. Auth0 monitors the impact on these metrics and will share them with you.  
+
+In addition, you can look at the [tenant logs](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection). Events that indicate a credential stuffing attack is happening.
+
+- `f`: failed login
+- `fu`: failed login due to invalid email/username
+
+If you have questions, you can contact Auth0 through your TAM or contact **antonio.fuentes@auth0.com**.
diff --git a/ja-jp/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md b/ja-jp/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md
new file mode 100644
index 0000000000..7096901ab2
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/guides/set-anomaly-detection-preferences.md
@@ -0,0 +1,70 @@
+---
+title: Set Anomaly Detection Preferences
+description: Learn how to set anomaly detection preferences in the Dashboard.
+topics:
+    - security
+    - anomaly-detection
+    - brute-force-protection
+    - breached-password-detection
+contentType: how-to
+useCase: customize-anomaly-detection
+v2: true
+---
+# Set Anomaly Detection Preferences
+
+Customize the actions that occur after the triggers in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly).
+
+::: warning
+Auth0 recommends that you **do not** make changes to your anomaly detection features with the Management API.
+:::
+
+![Anomaly Detection Dashboard](/media/articles/anomaly-detection/anomaly-detection-overview.png)
+
+## Brute-force protection preferences
+
+Brute-force protection is enabled by default for all connections. For more information, see [Enable and Disable Brute-Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection).
+
+::: warning
+Auth0 strongly recommends that you **do not** set the `brute_force_protection` flag to `false` (effectively disabling brute-force protection for the connection), however if you do, you can change it back in the [Dashboard](${manage_url}/#/anomaly). 
+::: 
+
+Limit the amount of signups and failed logins from a suspicious IP address. For more information, see [Brute-Force Protection Triggers and Actions](/anomaly-detection/references/brute-force-protection-triggers-actions).
+
+1. Click on the **Brute-force Protection** shield. 
+
+![Brute-Force Protection Shield](/media/articles/anomaly-detection/brute-force-shield.png)
+
+2. Use the toggles to enable or disable actions for single or multiple user accounts. 
+
+3. Add any IP addresses to the **Whitelist** field to avoid erroneously triggering the protection action.
+
+4. Click **Save** when you are finished.
+
+## Breached password detection preferences
+
+Set preferences for breached password detection actions. For more information, see [Breached Password Detection Triggers and Actions](/anomaly-detection/references/breached-password-detection-triggers-actions).
+
+1. Click on the **Breached-password Detection** shield.
+
+![Breached Password Detection Shield](/media/articles/anomaly-detection/breached-password-shield.png)
+
+2. Use the toggles to enable or disable actions when login security breaches are detected. 
+
+3. Determine how administrators are notified.
+
+4. Click **Save** when you are finished.
+
+## Restrictions and limitations
+
+Both brute-force protection and breached password detection depend on the IP address of the user. Because of this, the following use cases are *not* supported:
+
+* **Using the [Resource Owner](/api/authentication#resource-owner) from the backend of the application.** Using this call does not get the IP address of the user. See point 2 below as an alternative.
+
+* **Using [Resource Owner Password Grant](/api-auth/grant/password) from the backend of the application.** Using this call does not get the IP address of the user, however, you can [configure your application and send the IP address of the user as part of the request](/api-auth/tutorials/using-resource-owner-password-from-server-side) to make brute-force protection work correctly.
+
+* **Authenticating many users from the same IP address.** For example, users that are behind a proxy are more likely to reach these limits and trigger the associated protection. It is possible to configure a whitelist for the proxy's IP and CIDR range and avoid erroneously triggering the protection.
+
+## Keep reading
+
+* [Anomaly Detection](/anomaly-detection)
+* [Breached Password Security](/anomaly-detection/concepts/breached-passwords)
\ No newline at end of file
diff --git a/ja-jp/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md b/ja-jp/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md
new file mode 100644
index 0000000000..fd88341413
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/guides/use-tenant-data-for-anomaly-detection.md
@@ -0,0 +1,57 @@
+---
+description: Learn how to use tenant traffic log data to view anomaly detection events. 
+topics:
+    - security
+    - anomaly-detection
+contentType: how-to
+useCase: tenant-logs
+---
+
+# View Anomaly Detection Events
+
+The tenant logs contain useful data that you can use to build charts to look at the profile of the traffic going through your tenant. This is helpful when evaluating anomaly detection activity. 
+
+## Authentication failure events
+
+You can use the log data `event` field to view the tenant traffic data. We recommend building a daily histogram of failure events of the following types:
+
+| Event Code | Event |
+| -- | -- |
+| `f` | Failed login |
+| `fcoa` | Failed cross-origin authentication |
+| `feccft` | Failed exchange |
+| `fepft` | Failed exchange |
+| `fsa` | Failed silent authentication |
+| `fu` | Failed login (invalid email/username) |
+| `sepft` | Success exchange |
+
+These failure events depend on the flow you have set up with Auth0. 
+
+The following example shows a credential stuffing attack on 11/20, with a large surge of events of type `fu` which is a failed username (typical of a credential stuffing attack).
+
+![Traffic Failure Trends](/media/articles/anomaly-detection/traffic-failure-trends.png)
+
+## Authenticaton failure events from distinct IPs 
+
+You can use the `ip` event to see the number of distinct IPs that your failure traffic is coming from, in this case, the number of distinct IPs that correspond to your `fu` event traffic.
+
+## Anomaly detection events
+
+You can perform the same type of analysis with the events corresponding to anomaly detection events to see how many times they are triggered. Use the following log events which correspond to brute force detection with many accounts, one account, and breached password detection:
+
+| Event Code | Event |
+| -- | -- |
+| `limit_mu` | Blocked IP address |
+| `limit_wc` | Blocked account |
+| `pwd_leak` | Breached password |
+
+Here's an example of what that data might look like.
+
+![Anomaly Detection Data](/media/articles/anomaly-detection/anomaly-detection-features.png)
+
+## Keep reading
+
+* [Log Event Data](/logs/references/log-events-data)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Export Log Data to External Services](/extensions#Monitor)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
diff --git a/ja-jp/articles/anomaly-detection/index.md b/ja-jp/articles/anomaly-detection/index.md
new file mode 100644
index 0000000000..9dc98e5ece
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/index.md
@@ -0,0 +1,73 @@
+---
+title: Anomaly Detection
+description: Understand how Auth0 detects anomalies to stop malicious attempts to access your application, alert you and your users of suspicious activity, and block further login attempts. 
+toc: true 
+topics:
+    - security
+    - anomaly-detection
+    - brute-force-protection
+    - breached-password-detection
+contentType: concept
+useCase: customize-anomaly-detection
+v2: true
+---
+# Anomaly Detection
+
+Auth0 can detect anomalies and stop malicious attempts to access your application. Anomaly detection can alert you and your users of suspicious activity, as well as block further login attempts. You can [set preferences](/anomaly-detection/guides/set-anomaly-detection-preferences) for notifications and decide whether to block a suspicious IP address or not. 
+
+Auth0 has two types of **shields** to handle anomalies and attacks.  
+
+* [Brute-force protection](#brute-force-protection)
+* [Breached password detection](#breached-password-detection)
+
+A **shield** specifies the **action** you wish to take given a specific **trigger**. A **trigger** is a suspicious event that is detected when someone is trying to login to your system, or there may have been a breached password with another third party service.
+
+Customize the actions in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly).
+
+::: note
+Auth0 recommends that you [create reports using tenant traffic data to see anomaly detection events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection).
+:::
+
+## Brute-force protection
+
+Brute-force protection is [enabled by default](/anomaly-detection/guides/enable-disable-brute-force-protection) for all connections. There are two different [triggers](/anomaly-detection/references/brute-force-protection-triggers-actions) for the brute-force protection shield, for two slightly different attack scenarios.
+
+* 10 consecutive failed login attempts for the same user and from the same IP address
+* 100 failed login attempts from the same IP address in 24 hours *or* 50 sign up attempts per minute from the same IP address
+
+For example, if a user with *user_id1* signs in from *IP1* and fails to login consecutively for 10 attempts, their log in attempt from this *IP1* will be blocked. Another user, *user_id2*, signing in from *IP1* will not be blocked. 
+
+## Breached password detection
+
+Every day, malicious hackers penetrate websites and applications, exposing thousands of email and passwords. Because it's common for users to use the same password to login to multiples sites, this poses a problem, not only for the hacked system, but to any application that shares those [breached passwords](/anomaly-detection/concepts/breached-passwords).
+
+Auth0 tracks large security breaches that are happening on major third party sites to help keep your users and system secure. By [enabling breached password detection](/anomaly-detection/guides/set-anomaly-detection-preferences), when a [trigger](/anomaly-detection/references/breached-password-detection-triggers-actions) occurs, your users can be notified and/or blocked from logging in if we suspect their credentials were part of a published security breach. You can [customize blocked account emails](/anomaly-detection/guides/customize-blocked-account-emails).
+
+## Frequently asked questions
+
+* **Is the user notified at every login?**
+We send one email every hour, regardless of the number of logins. For example, if a user tries to log in 200 times in 1 hour and 30 minutes, we will send 2 emails.
+
+* **Is there a limit to the number of times a user will be notified?**
+Users will only be notified once per hour.
+
+* **How often does Auth0 email administrators when traffic is blocked using Brute Force Protection for multiple accounts?**
+In the event of an ongoing attack, traffic can be blocked from thousands of IP addresses at a time.  Auth0 will send a single email to each administrator every hour that traffic is blocked, regardless of the number of IPs involved in the attack.
+
+* **For how long is the reset password link, included in the breached password email, valid?**
+Password reset links are valid for 5 days.
+
+* **Is there a test dataset of breached passwords?**
+You can test with **leak-test@example.com** as the email and **Paaf213XXYYZZ** as the password. 
+
+* **Does the breached password detection work when logging in using the Resource Owner password grant?**
+Yes.
+
+* **Does the breached password detection feature work with a custom database?**
+Yes.
+
+* **What Redirect URL applies to the *Change password* link included in the breached password notification email?**
+The **RedirectTo** URL is the URL listed in the Dashboard in [Emails > Templates > Change Password Template](${manage_url}/#/emails).
+
+* **Is there a way to configure the Redirect URL and the length of time that the change password link is valid?**
+You can configure the **URL Lifetime** and **Redirect To** values in the Dashboard by going to [Emails > Templates > Change Password Template](${manage_url}/#/emails).
\ No newline at end of file
diff --git a/ja-jp/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md b/ja-jp/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md
new file mode 100644
index 0000000000..c7e0e93b8b
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/references/breached-password-detection-triggers-actions.md
@@ -0,0 +1,35 @@
+---
+title: Breached Password Detection Triggers and Actions
+description: Breached password detection triggers and actions taken upon anomaly detection and how blocks are cleared.
+topics:
+    - security
+    - anomaly-detection
+    - breached-password-detection
+contentType: reference
+useCase: customize-anomaly-detection
+v2: true
+---
+# Breached Password Detection Triggers and Actions
+
+## Trigger
+
+A trigger occurs when Auth0 suspects that a specific user's credentials were included in a major public security breach.
+
+::: panel Video Tutorial
+Watch our [Breached Password Detection 101 video tutorial](https://auth0.com/resources/videos/learn-about-breached-password-detection).
+:::
+
+## Actions
+
+* Send an email to the affected user.
+* Send an email to dashboard owners immediately, and/or have a daily/weekly/monthly summary.
+* Block login attempts for suspected user accounts using that username and password combination.
+
+## Remove block
+
+This block remains in place until the user changes their password.
+
+## Keep reading
+
+* [Anomaly Detection](/anomaly-detection)
+* [Breached Password Security](/anomaly-detection/concepts/breached-passwords)
\ No newline at end of file
diff --git a/ja-jp/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md b/ja-jp/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md
new file mode 100644
index 0000000000..3342464d8f
--- /dev/null
+++ b/ja-jp/articles/anomaly-detection/references/brute-force-protection-triggers-actions.md
@@ -0,0 +1,64 @@
+---
+title: Brute-Force Protection Triggers and Actions
+description: Brute-force protection triggers and actions taken upon anomaly detection and how blocks are cleared.
+topics:
+    - security
+    - anomaly-detection
+    - brute-force-protection
+contentType: reference
+useCase: customize-anomaly-detection
+v2: true
+---
+# Brute-Force Protection Triggers and Actions
+
+## 10 failed login attempts
+
+### Trigger
+
+This trigger occurs when there are 10 failed login attempts into a single account from the same IP address.
+
+::: note
+The default trigger amount of 10 cannot be changed.
+:::
+
+### Actions
+
+* Send an email to the affected user.  (You can [customize the email](/anomaly-detection/guides/customize-blocked-account-emails).)
+* Block the suspicious IP address for that user.
+
+### Remove block
+
+If this block is triggered, it can be cleared the following ways:
+
+* An administrator removes the block via the [Dashboard](${manage_url}) (by clicking **unblock for all IPs** under the **ACTIONS** button when viewing the user's details) or by using the [Management API](/api/management/v2#!/User_Blocks/delete_user_blocks).
+* The user clicks on the **unblock** link provided in the email sent when the block went into effect.
+* The user changes their password.
+
+## 100 failed login attempts *or* 50 sign up attempts
+
+### Triggers
+
+A trigger occurs when there are 100 failed login attempts from one IP address using different usernames with incorrect passwords in 24 hours. 
+
+Another trigger occurs if there are 50 sign up attempts per minute from the same IP address.
+
+### Actions
+
+* Notify dashboard administrator(s).
+* Block suspicious addresses for 15 minutes.
+
+If this block is triggered, additional access attempts are released one-at-a-time over the course of 24 hours until 100 attempts are allocated. This results in approximately 1 additional attempt every 15 minutes.
+
+### Remove block
+
+Auth0 emails the dashboard administrator(s) when this block is triggered. The email contains a link that the owner can click to navigate to tenant logs to examine which IPs have been blocked. Recent blocks can be found using this query:
+```
+type:limit_mu
+```
+Blocks can then be removed using the [Management API](/api/management/v2#!/Anomaly/delete_ips_by_id).
+
+## Keep reading
+
+* [Anomaly Detection](/anomaly-detection)
+* [Set Anomaly Detection Preferences](/anomaly-detection/guides/set-anomaly-detection-preferences)
+* [Enable and Disable Brute-Force Protection](/anomaly-detection/guides/enable-disable-brute-force-protection)
diff --git a/ja-jp/articles/api-auth/_includes/_ropg-warning.md b/ja-jp/articles/api-auth/_includes/_ropg-warning.md
new file mode 100644
index 0000000000..c19c5320ac
--- /dev/null
+++ b/ja-jp/articles/api-auth/_includes/_ropg-warning.md
@@ -0,0 +1,9 @@
+::: warning
+Since the Resource Owner Password Grant (ROPG) flow involves the client handling the user's password, it **must not be used by third-party clients**. In this flow, the user's username and password are exchanged directly for an Access Token.
+
+Only consider using it when there is a high degree of trust between the user and the application and when other authorization flows (such as redirect-based flows) are not available.
+
+Instead, Auth0 recommends: 
+* For confidential clients, like Regular Web Applications, use the [Authorization Code Flow](/flows/concepts/auth-code).
+* For public clients, like Native/Mobile Apps and Single-Page Applications, use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce).
+:::
diff --git a/ja-jp/articles/api-auth/apis.md b/ja-jp/articles/api-auth/apis.md
new file mode 100644
index 0000000000..da33b407f4
--- /dev/null
+++ b/ja-jp/articles/api-auth/apis.md
@@ -0,0 +1,85 @@
+---
+url: /apis
+toc: true
+title: APIs Overview
+description: Learn the basics of APIs, their role in OAuth and how to configure an API in Auth0 Dashboard.
+crews: crew-2
+topics:
+  - api-authentication
+  - oidc
+  - apis
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# APIs
+
+An API is an entity that represents an external resource, capable of accepting and responding to protected resource requests made by applications. At the [OAuth2 spec](https://tools.ietf.org/html/rfc6749) an API maps to the **Resource Server**.
+
+When an application wants to access an API's protected resources it must provide an Access Token. The same Access Token can be used to access the API's resources without having to authenticate again, until it expires.
+
+Each API has a set of defined permissions. Applications can request a subset of those defined permissions when they execute the authorization flow, and include them in the Access Token as part of the **scope** request parameter.
+
+For example, an API that holds a user's appointments, may accept two different levels of authorization: read only (scope `read:appointments`) or write (scope `write:appointments`). When an application asks the API to list a user's appointments, then the Access Token should contain the `read:appointments` scope. In order to edit an existing appointment or create a new one, the Access Token should contain the `write:appointments` scope. See [Tokens](/tokens) for more information. 
+
+## How to configure an API in Auth0
+
+Click on the [APIs menu option](${manage_url}/#/apis) on the left.
+
+::: note
+The API tab will already have one API created automatically, the **Auth0 Management API**. For more details on the features of the Management API and its available endpoints, refer to: [Management API](/api/management/v2).
+:::
+
+Click the **+ Create API** button.
+
+![Create a new API](/media/articles/api/overview/create-api.png)
+
+You need to provide the following information for your API:
+
+- **Name**: a friendly name for the API. Does not affect any functionality.
+
+- **Identifier**: a unique identifier for the API. Auth0 recommends using a URL. Auth0 does differentiate between URLs that include the last forward slash. For example, https://example.com and https://example.com/ are two different identifiers. The URL does not have to be a publicly available URL. Auth0 will not call your API. This value **cannot** be modified afterwards. 
+
+- **Signing Algorithm**: the algorithm to sign the tokens with. The available values are `HS256` and `RS256`. When selecting `RS256` the token will be signed with the tenant's private key. To learn more about signing algorithms, see [Signing Algorithms paragraph](/tokens/concepts/signing-algorithms).
+
+Fill in the required information and click the **Create** button.
+
+Once you do so you will be navigated to the *Quick Start* of your API. Here you can find details on the implementation changes you have to do to your API, which basically consists of choosing a JWT library from a predefined list and configuring this library to validate the Access Tokens in your API.
+
+![API Quick Starts](/media/articles/api/overview/quickstarts-view.png)
+
+
+The other available views for your API are:
+
+- **Settings**: lists the settings for your API. Some are editable. Here you can change the token expiration time and enable offline access (this way Auth0 will allow your applications to ask for Refresh Tokens for this API). For details refer to the [API Settings paragraph](#api-settings).
+
+- **Scopes**: here you can define the scopes for this API, by setting a name and a description.
+
+- **Machine to Machine Applications**: lists all applications for which the **Client Credentials** grant is **enabled**. By default, this grant is **enabled** for [Regular Web Applications and Machine to Machine Applications](/applications). You can authorize any of these applications to request Access Tokens for your API. Optionally, you can select a subset of the defined scopes to limit your authorized application's access. 
+
+- **Test**: from this view, you can execute a sample Client Credentials flow with any of your authorized applications to check that everything is working as expected.
+
+### API Settings
+
+Click on the *Settings* tab of your [API](${manage_url}/#/apis) to review the available settings:
+
+- **Id**: A unique alphanumeric string generated by Auth0. The information is read only and you will only need it if you will be working directly with [Auth0's Management API Resource Servers endpoints](/api/management/v2#!/Resource_Servers/get_resource_servers_by_id).
+
+- **Name**: A friendly name for the API. Does not affect any functionality. The following characters are not allowed: `< >`.
+
+- **Identifier**: A unique identifier for your API. This value is set upon API creation and cannot be modified afterwards. We recommend using a URL but note that this doesn't have to be a publicly available URL, Auth0 will not call your API at all.
+
+- **Token Expiration (Seconds)**: The amount of time (in seconds) before the Auth0 Access Token expires. The default value is 86400 seconds (24 hours). The maximum value you can set is 2592000 seconds (30 days).
+
+- **Allow Skipping User Consent**: When a first party application requests authorized access against an API with the *Allow Skipping User Consent* flag set, the User Consent dialog will not be shown to the final user. Note that if the hostname of your application's **callback URL** is `localhost` or `127.0.0.1` the consent dialog will always be displayed.
+
+- **Allow Offline Access**: If this setting is enabled, Auth0 will allow applications to ask for Refresh Tokens for this API.
+
+- **Signing Algorithm**: The algorithm to sign the tokens with. The available values are `HS256` and `RS256`. When selecting `RS256` (recommended) the token will be signed with the tenant's private key. This value is set upon API creation and cannot be modified afterwards. To learn more about signing algorithms, see [Signing Algorithms](/tokens/concepts/signing-algorithms).
+
+## Keep reading
+
+- [API Authorization landing page](/api-auth)
+- [Identify the proper OAuth 2.0 flow for your use case](/api-auth/which-oauth-flow-to-use)
+- [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/blacklists-vs-grants.md b/ja-jp/articles/api-auth/blacklists-vs-grants.md
new file mode 100644
index 0000000000..8a8fbedf29
--- /dev/null
+++ b/ja-jp/articles/api-auth/blacklists-vs-grants.md
@@ -0,0 +1,78 @@
+---
+description: Understand blacklists vs. grants when it comes handling tokens.
+topics:
+  - api-authentication
+  - oidc
+  - security
+  - blacklists
+  - application-grants
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Blacklists and Application Grants
+
+Let's say that you're using a machine to machine [application](/application) to access your API. You have a partner that calls your API, and at the end of your existing contract, you and your partner decide not to renew your partnership. As such, you now want to remove your partner's access to your API. The issue, however, is that you've given your partner an Access Token that lasts for a month.
+
+* What can you do in this situation?
+* How might you configure your Auth0 environment to make such situations easier to handle in the future?
+
+In this article, we'll cover two methods for revoking access to the protected resource:
+
+* [Blacklisting the Access Token](#blacklists)
+* [Revoking the application grant](#application-grants)
+
+We will then compare the two methods and provide our recommendations.
+
+## Blacklists
+
+Let's say that you grant access to your API to anyone in possession of the appropriate Access Token. One method of revoking access to a user is to blacklist their token so that it can no longer be used.
+
+Auth0-issued tokens are [JWTs](/tokens/concepts/jwts), so you can set the JWT ID, or `jti`, for the token by including it in the token payload's `jwtid` field. With the `jti` in hand, you can make the appropriate `POST` call to the Management API's [blacklist a token endpoint](/api/management/v2#!/Blacklists/post_tokens). You'll need to provide the JWT's `aud` and `jti` claims. 
+
+::: panel Add a JWT ID
+You can add `jti` via a [rule](/rules). Here's a simple example using UUID:
+
+```js
+function (user, context, callback) {
+  user.jti = require('uuid').v4();
+  callback(null, user, context);
+}
+```
+:::
+
+Your call might look something like this:
+
+```text
+curl -H "Authorization: Bearer {JWT_API_KEY}"
+-X POST
+-H "Content-Type: application/json"
+-d '{"aud":"u6nnAxGVjbBd8etXjj554YKGAG5HuVrp","jti":"test-token"}'
+https://login.auth0.com/api/v2/blacklists/tokens
+```
+
+## Application Grants
+
+The main issue in this scenario is the length of time for which the API Access Token is valid: one month. 
+
+By default, Auth0 issues Access Tokens that last for 24 hours. Setting the token's lifetime to 24 hours means that your partner must repeat the client credentials exchange (or whichever grant you've implemented) to obtain a new Access Token every 24 hours. To deny access to your partner due to the expiration of your contract, you can simply delete the application grant so that when their existing token expires, they cannot request a new one.
+
+You can change the lifetime of a token by setting the `token_lifetime` option. The specific lifetime appropriate to your use case will vary, but we recommend setting this value to be as short as possible. A good starting point for determining this value would be the window you consider allowable for the delay between deleting the grant and final use of the API.
+
+### Delete an Application Grant
+
+To delete an application grant, make the appropriate `DELETE` call to the Management API's [Delete an Application Grant endpoint](/api/management/v2#!/Client_Grants/delete_client_grants_by_id). 
+
+::: note
+For additional information, please see our docs on [APIs](/apis).
+:::
+
+As part of the call, you'll need to specify the ID of the application grant you want to delete, which you can obtain via the Management API's [Get all Application Grants endpoint](/api/management/v2#!/Client_Grants/get_client_grants) or the Management Dashboard by going to *APIs > Machine to Machine Applications* and expanding the hidden information for the specific machine to machine application in question.
+
+## Blacklists vs. Application Grants
+
+For you to blacklist Access Tokens to revoke access, you'll need to identify and blacklist **every** token you've ever assigned to the company whom you no longer want accessing the API. This is because the Auth0 API asks for the tokens' `jti` values to compile the blacklist. As the number of tokens issued grows larger and larger, this method gets more and more difficult to implement and execute correctly.
+
+On the other hand, configuring your application grant so that the tokens you issue last for only a short period means that when it comes time for you to revoke access to a protected resource, you can simply delete the grant. At this point, the party with the Access Token only has a limited period between when you delete the grant and the token's expiration to make additional API requests. Because this is the easier (and safer) option to implement, we recommend you deny access to your APIs and other protected resources by revoking application grants.
diff --git a/ja-jp/articles/api-auth/config/using-the-auth0-dashboard.md b/ja-jp/articles/api-auth/config/using-the-auth0-dashboard.md
new file mode 100644
index 0000000000..dde2b216f6
--- /dev/null
+++ b/ja-jp/articles/api-auth/config/using-the-auth0-dashboard.md
@@ -0,0 +1,33 @@
+---
+description: How to set up a Client Grant using the Auth0 Dashboard
+crews: crew-2
+topics:
+  - client-credentials
+  - api-authorization
+contentType: how-to
+useCase: secure-api
+---
+
+# Set Up Client Credentials Grants Using the Dashboard
+
+Auth0 lets you authorize applications that have the **Client Credentials** grant type enabled to call APIs using the [Client Credentials Flow](/flows/concepts/client-credentials). 
+
+By default, the **Client Credentials** grant is enabled for all Machine-to-Machine Applications and Regular Web Applications, but they are _not yet_ authorized to call any API.
+
+To authorize the applications to call an API:
+
+1. Open the Auth0 Management Dashboard and browse to the [API section](${manage_url}/#/apis).
+
+2. Select the API you want to invoke using the **Client Credentials** Grant.
+
+3. Under the **Authorized Application** tab, look for the application you want to authorize, click the Authorize button, and optionally, select the list of scopes that will be granted in the Access Token. This will create a 'client grant' in Auth0, which will allow the application to call the API.
+
+![Authorize the Application](/media/articles/api-auth/apis-authorize-client-tab.png)
+
+4. In the Test tab, you can select the application to which you granted access, and see the Access Tokens that will be generated for it.
+
+## Keep reading
+
+* [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+* [Use Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks)
+* [Add Custom Claims Tokens Using Rules](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
diff --git a/ja-jp/articles/api-auth/config/using-the-management-api.md b/ja-jp/articles/api-auth/config/using-the-management-api.md
new file mode 100644
index 0000000000..fc9e75f35a
--- /dev/null
+++ b/ja-jp/articles/api-auth/config/using-the-management-api.md
@@ -0,0 +1,69 @@
+---
+description: Learn how to set up a Client Credentials Grant using the Management API.
+crews: crew-2
+topics:
+  - client-credentials
+  - api-authorization
+contentType: how-to
+useCase: secure-api
+---
+
+# Set Up Client Credentials Grants Using the Management API
+
+Auth0 lets you authorize applications that have the Client Credentials grant type enabled to call APIs using the [Client Credentials Flow](/flows/concepts/client-credentials). 
+
+By default, all Machine-to-Machine Applications and Regular Web Applications have the 'Client Credentials' grant enabled, but they are not authorized to call any API.
+
+If you want to call an API from these applications, you first need to authorize the application to call the API and specify the scopes that will be granted. You can do that [using the Dashboard](/api-auth/config/using-the-auth0-dashboard), or follow the steps below to use the API.
+
+You will need the following:
+
+- A Management API Access Token with the `create:client_grants` scopes. For details on how to get one, refer to [Access Tokens for the Management API](/api/management/v2/tokens).
+
+- The application information (`Client_Id` and `Client_Secret`) for the application you want to authorize [Auth0 dashboard](${manage_url}/#/applications).
+
+- The API identifier for the API you want to invoke (${manage_url}/#/apis).
+
+##  Authorize the Application
+
+To authorize your Application, send a `POST` request to the [/client-grants endpoint of the Management APIv2](/api/management/v2#!/Client_Grants/post_client_grants) with the Management API Access Token.
+
+The following example authorizes the application with Id `${account.clientId}`, to access the API with Identifier `https://my-api-urn`, while granting the scope `sample-scope`.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/client-grants",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "authorization", "value": "Bearer Auth0_MGMT_API_ACCESS_TOKEN" }
+  ],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"client_id\": \"${account.clientId}\",\"audience\": \"https://my-api-urn\",\"scope\":[\"sample-scope\"]}"
+  }
+}
+```
+
+Sample response:
+
+```json
+{
+    "id": "cgr_JGa6ZckLjnt60rWe",
+    "client_id": "${account.clientId}",
+    "audience": "https://test-api",
+    "scope": [
+        "sample-scope"
+    ]
+}
+```
+
+That's it, you are done! Now that all the elements are in place, you can request Access Tokens for your API from Auth0 using the Client Credentials Flow.
+
+## Keep reading
+
+:::next-steps
+* [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+* [How to change the scopes and add custom claims to a token using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+* [How to add custom claims to a token using Rules](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
+:::
diff --git a/ja-jp/articles/api-auth/dynamic-client-registration.md b/ja-jp/articles/api-auth/dynamic-client-registration.md
new file mode 100644
index 0000000000..6bac759f08
--- /dev/null
+++ b/ja-jp/articles/api-auth/dynamic-client-registration.md
@@ -0,0 +1,148 @@
+---
+description: Learn how to dynamically register applications with Auth0 using the Management API.
+crews: crew-2
+toc: true
+topics:
+  - applications
+contentType: how-to
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Dynamic Client Registration
+
+Dynamic Client Registration enables you to register [third-party applications](/applications/guides/enable-third-party-apps) dynamically.
+
+This feature is based on the [OpenID Connect Dynamic Client Registration specification](https://openid.net/specs/openid-connect-registration-1_0.html) and in this article we will see how you can enable and use it.
+
+## Enable dynamic registration
+
+::: warning
+Auth0 supports **Open Dynamic Registration**, which means that if you enable this feature, **anyone** will be able to create applications in your tenant without a token.
+:::
+
+By default, the feature is disabled for all tenants. To change this, you have to set the `enable_dynamic_client_registration` flag to `true` in your tenant's settings.
+
+This can be done by enabling the **OIDC Dynamic Application Registration** toggle on your tenant's [Advanced Settings page](${manage_url}/#/tenant/advanced).
+
+Alternatively, you can update this flag using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings).
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"enable_dynamic_client_registration\": true } }"
+  }
+}
+```
+
+You need to update the `API2_ACCESS_TOKEN` with a valid token with the scope `update:tenant_settings`. See [Access Tokens for the Management API](/api/management/v2/tokens) for details on how to do so.
+
+## Use dynamic registration
+
+In this section we will see how you can dynamically register and configure an application.
+
+### Register your application
+
+To dynamically register an application with Auth0, you need to send an HTTP `POST` message to the Application Registration endpoint: `https://${account.namespace}/oidc/register`. Note that Auth0 supports **Open Dynamic Registration**, which means that the endpoint will accept a registration request without an Access Token.
+
+To create an application with the name `My Dynamic application` and the callback URLs `https://application.example.com/callback` and `https://application.example.com/callback2`, use the following snippet.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oidc/register",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"client_name\":\"My Dynamic Application\",\"redirect_uris\": [\"https://application.example.com/callback\", \"https://application.example.com/callback2\"]}"
+  }
+}
+```
+
+Where:
+- **client_name**: The name of the Dynamic Application to be created
+- **redirect_uris** (required): An array of URLs that Auth0 will deem valid to call at the end of an authentication flow
+
+Optionally, you can set a value for `token_endpoint_auth_method`, which can be `none` or `client_secret_post` (default value). Use `token_endpoint_auth_method: none` in the request payload if creating a SPA.
+
+The response includes the basic application information.
+
+```json
+HTTP/1.1 201 Created
+Content-Type: application/json
+{
+  "client_name": "My Dynamic Application",
+  "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2",
+  "client_secret": "Q5O...33P",
+  "redirect_uris": [
+    "https://application.example.com/callback",
+    "https://application.example.com/callback2"
+  ],
+  "client_secret_expires_at": 0
+}
+```
+
+Where:
+- **client_id**: Unique client identifier. This is the ID you will use while configuring your apps to use Auth0. It is generated by the system and it cannot be modified.
+- **client_secret**: Alphanumeric 64-bit client secret. This value is used by applications to authenticate to the [token endpoint](/api/authentication#get-token) and for signing and validating [ID Tokens](/tokens/concepts/id-tokens).
+- **client_secret_expires_at**: Time at which the `client_secret` will expire. For Auth0 this value will always be zero (`0`) which means that the application never expires.
+
+Make a note of the Client ID and Secret, as these are the most important pieces for executing [authentication](/application-auth) and [authorization](/api-auth) flows.
+
+Also, keep in mind that third-party developers are not allowed to modify the application settings. In case this is necessary, they need to contact the tenant owner with their request.
+
+### Configure your application
+
+Now that you have a Client ID and Secret, you can configure your application to authenticate users with Auth0.
+
+We will go through a simple example, that shows how to call an API from a client-side web app, using the [Implicit Flow](/flows/guides/implicit/call-api-implicit). For a list of tutorials on how to authenticate and authorize users, based on your application type, see the [API Authorization](/api-auth) page.
+
+First, you need to configure your application to send the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  audience={API_AUDIENCE}&
+  scope={SCOPE}&
+  response_type={RESPONSE_TYPE}&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  nonce={NONCE}
+  state={OPAQUE_VALUE}
+```
+
+Where:
+- **audience** (optional): The target API for which the Application is requesting access on behalf of the user. Set this parameter if you need API access.
+- **scope** (optional): The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must conform to a namespaced format (see panel below for more info), or any scopes supported by the target API (for example, `read:contacts`). Set this parameter if you need API access.
+
+  ::: panel Custom claims namespaced format
+  In order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/api-auth/tutorials/adoption/scope-custom-claims) to avoid possible collisions with standard OpenID Connect claims. For example, if you choose the namespace `https://foo.com/` and you want to add a custom claim named `myclaim`, you would name the claim `https://foo.com/myclaim`, instead of `myclaim`.
+  :::
+
+- **response_type**: The response type. For Implicit Grant you can either use `token` or `id_token token`. This will specify the type of token you will receive at the end of the flow. Use `token` to get only an Access Token, or `id_token token` to get both an ID Token and an Access Token.
+- **client_id**: Your application's Client ID.
+- **redirect_uri**: The URL to which the Authorization Server (Auth0) will redirect the User Agent (Browser) after authorization has been granted by the User. The Access Token (and optionally an ID Token) will be available in the hash fragment of this URL. This URL must be specified as a valid callback URL under the Application Settings of your application.
+- **state**: An opaque value the applications add to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks.
+- **nonce**: A string value which will be included in the ID Token response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`.
+
+For example:
+
+```html
+
+  Sign In
+
+```
+
+This call will redirect the user to Auth0, and upon successful authentication, back to your application (specifically to the **redirect_uri**).
+
+If you need API access, then following the authentication, you need to extract the Access Token from the hash fragment of the URL, and use it to make calls to the API, by passing it as a `Bearer` token in the `Authorization` header of the HTTP request.
diff --git a/ja-jp/articles/api-auth/faq.md b/ja-jp/articles/api-auth/faq.md
new file mode 100644
index 0000000000..d5fea1d7e6
--- /dev/null
+++ b/ja-jp/articles/api-auth/faq.md
@@ -0,0 +1,30 @@
+---
+description: API Authentication and Authorization FAQ
+topics:
+  - api-authentication
+  - oidc
+  - user-consent
+  - resource-servers
+  - applications
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# API Authentication and Authorization FAQ
+
+## I have an Application that needs to talk to different Resource Servers
+
+If a single Application needs Access Tokens for different resource servers, then multiple calls to `/authorize` (that is, multiple executions of the same or different Authorization Flow) needs to be performed. Each authorization will use a different value for `audience`, which will result in a different Access Token at the end of the flow.
+
+For more information, see the [OAuth 2.0: Audience Information Specification](https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3).
+
+## Can I try the endpoints before I implement my application?
+
+Sure! You have two options:
+- [Download our Postman collection](https://app.getpostman.com/run-collection/2a9bc47495ab00cda178). For more information on how to use our Postman collection refer to [Using the Auth0 API with our Postman Collections](/api/postman).
+
+- Use our [Authentication API Debugger Extension](/extensions/authentication-api-debugger). You can find detailed instructions per endpoint/grant at our [Authentication API Reference](/api/authentication).
+  - For the Authorize endpoint, go to [Authorize Application](/api/authentication#authorize-application) and read the _Test this endpoint_ paragraph for the grant you want to test.
+  - For the Token endpoint, go to [Get Token](/api/authentication#get-token) and read the _Test this endpoint_ paragraph for the grant you want to test.
diff --git a/ja-jp/articles/api-auth/grant/authorization-code-pkce.md b/ja-jp/articles/api-auth/grant/authorization-code-pkce.md
new file mode 100644
index 0000000000..fb575ab2c1
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/authorization-code-pkce.md
@@ -0,0 +1,61 @@
+---
+description: Describes the call APIs from mobile apps using the Authentication Code Grant (PKCE).
+topics:
+  - authorization-code
+  - pkce
+  - api-authorization
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs from Mobile Apps
+
+To access an API from a [mobile app](/quickstart/native), you need to implement the **Authorization Code using Proof Key for Code Exchange (PKCE)** OAuth 2.0 grant. In this document, we will see how this flow works.
+
+::: note
+If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article.
+:::
+
+## Overview of the flow
+
+The [Authorization Code Grant](/api-auth/grant/authorization-code) has some security issues when implemented on native applications. For instance, a malicious attacker can intercept the `authorization_code` returned by Auth0 and exchange it for an Access Token (and possibly a Refresh Token).
+
+The **Proof Key for Code Exchange (PKCE)** (defined in [RFC 7636](https://tools.ietf.org/html/rfc7636)) is a technique used to mitigate this authorization code interception attack.
+
+With PKCE, the application creates, for every authorization request, a cryptographically random key called `code_verifier` and its transformed value called `code_challenge`, which is sent to Auth0 to get the `authorization_code`. When the application receives the `authorization_code`, it will send the code and the `code_verifier` to Auth0's token endpoint to exchange them for the requested tokens.
+
+![Authorization Code Grant using PKCE](/media/articles/api-auth/authorization-code-grant-pkce.png)
+
+ 1. The native application initiates the flow and redirects the user to Auth0 (specifically to the [/authorize endpoint](/api/authentication#authorization-code-grant-pkce-)), sending the `code_challenge` and `code_challenge_method` parameters.
+
+ 2. Auth0 redirects the user to the native application with an `authorization_code` in the querystring.
+
+ 3. The native application sends the `authorization_code` and `code_verifier` together with the `redirect_uri` and the `client_id` to Auth0. This is done using the [/oauth/token endpoint](/api/authentication?http#authorization-code-pkce-).
+
+ 4. Auth0 validates this information and returns an Access Token (and optionally a Refresh Token).
+
+ 5. The native application can use the Access Token to call the API on behalf of the user.
+
+::: note
+In OAuth 2.0 terms, the native application is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.
+:::
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce).
+
+## Rules
+
+[Rules](/rules) will run for the Authorization Code (PKCE) grant. If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant.
+
+For details on how to implement this, refer to [Execute an Authorization Code Grant Flow with PKCE: Customize the Tokens](/api-auth/tutorials/authorization-code-grant-pkce#optional-customize-the-tokens).
+
+## Keep reading
+
+::: next-steps
+- [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce)
+- [How to configure an API in Auth0](/apis)
+- [Tokens](/tokens)
+- [Application Authentication for Mobile & Desktop Apps](/application-auth/mobile-desktop)
+:::
diff --git a/ja-jp/articles/api-auth/grant/authorization-code.md b/ja-jp/articles/api-auth/grant/authorization-code.md
new file mode 100644
index 0000000000..45412c6e0b
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/authorization-code.md
@@ -0,0 +1,59 @@
+---
+description: Describes how to call APIs from regular web apps using the Authentication Code Grant.
+topics:
+  - authorization-code
+  - api-authorization
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs from Server-side Web Apps
+
+In order to access an API from a [regular web app](/quickstart/webapp), you need to implement the **Authorization Code** OAuth 2.0 grant. In this document we will see how this flow works.
+
+::: note
+If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article.
+:::
+
+## Overview of the flow
+
+The **Authorization Code Grant** (defined in [RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.1)) is a flow where the browser receives an Authorization Code from Auth0 and sends this to the web app. The web app will then interact with Auth0 and exchange the Authorization Code for an [Access Token](/tokens/concepts/access-tokens), and optionally an [ID Token](/tokens/concepts/id-tokens) and a Refresh Token. The web app can now use this Access Token to call the API on behalf of the user.
+
+![Authorization Code Grant](/media/articles/api-auth/authorization-code-grant.png)
+
+1. The web app initiates the flow and redirects the browser to Auth0 (specifically to the [/authorize endpoint](/api/authentication#authorization-code-grant)), so the user can authenticate.
+
+1. Auth0 authenticates the user (via the browser). The first time the user goes through this flow a consent page will be shown where the permissions are listed that will be given to the application (for example: post messages, list contacts, and so forth).
+
+1. Auth0 redirects the user to the web app (specifically to the `redirect_uri`, as specified in the [/authorize request](/api/authentication#authorization-code-grant)) with an Authorization Code in the querystring (`code`).
+
+1. The web app sends the Authorization Code to Auth0 and asks to exchange it with an Access Token (and optionally an ID Token and a Refresh Token). This is done using the [/oauth/token endpoint](/api/authentication?http#authorization-code). When making this request, the web app authenticates with Auth0, using the Client Id and Client Secret.
+
+1. Auth0 authenticates the web app, validates the Authorization Code and responds back with the token.
+
+1. The web app can use the Access Token to call the API on behalf of the user.
+
+::: note
+In OAuth 2.0 terms, the web app is the application, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.
+:::
+
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, refer to [Executing an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant).
+
+## Rules
+
+[Rules](/rules) will run for the Authorization Code grant. If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant.
+
+For details on how to implement this, refer to [Execute an Authorization Code Grant Flow: Customize the Tokens](/api-auth/tutorials/authorization-code-grant#optional-customize-the-tokens).
+
+## Keep reading
+
+::: next-steps
+- [How to implement an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant)
+- [How to configure an API in Auth0](/apis)
+- [Tokens](/tokens)
+- [Application Authentication for Server-side Web Apps](/application-auth/server-side-web)
+:::
diff --git a/ja-jp/articles/api-auth/grant/client-credentials.md b/ja-jp/articles/api-auth/grant/client-credentials.md
new file mode 100644
index 0000000000..8fa8cd26d3
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/client-credentials.md
@@ -0,0 +1,42 @@
+---
+description: Describes how to call APIs from server processes using the Client Credentials Grant.
+topics:
+  - client-credentials
+  - api-authorization
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Client Credentials Grant
+
+The **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) allows an application to request an Access Token using its __Client Id__ and __Client Secret__. It is used for non interactive applications (a CLI, a daemon, or a Service running on your backend) where the token is issued to the application itself, instead of an end user.
+
+In order to be able to perform the Client Credentials Grant, the Application needs to have the [Client Credentials grant type](/applications/concepts/application-grant-types) enabled. Machine to Machine Applications and Regular Web Applications have it enabled by default. 
+
+## Client Credentials Grant Flow
+
+![Client Credentials Grant Flow](/media/articles/api-auth/client-credentials-grant.png)
+
+1. The application authenticates with Auth0 using its __Client Id__ and __Client Secret__.
+
+1. Auth0 validates this information and returns an Access Token.
+
+1. The application can use the Access Token to call the API on behalf of itself.
+
+::: note
+In OAuth 2.0 terms, the application is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.
+:::
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, refer to [Execute a Client Credentials Grant](/api-auth/tutorials/client-credentials).
+
+## Keep reading
+
+::: next-steps
+- [How to implement a Client Credentials flow](/api-auth/tutorials/client-credentials)
+- [How to configure an API in Auth0](/apis)
+- [Tokens](/tokens)
+- [How to change the scopes and add custom claims to the tokens using Hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+:::
diff --git a/ja-jp/articles/api-auth/grant/hybrid.md b/ja-jp/articles/api-auth/grant/hybrid.md
new file mode 100644
index 0000000000..496e658d8b
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/hybrid.md
@@ -0,0 +1,66 @@
+---
+description: Describes how to call APIs from applications using the Hybrid Flow
+public: false
+topics:
+  - authorization-code
+  - api-authorization
+  - implicit
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs Using the Hybrid Flow
+
+The Hybrid Flow is an OpenID Connect (OIDC) flow that draws from the following:
+
+1. [Authorization Code Flow](/flows/concepts/auth-code)
+2. [Implicit Flow](/flows/concepts/implicit)
+
+The Hybrid Flow enables use cases where your application can immediately use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token (therefore gaining access to protected resources for an extended period of time).
+
+## Background
+
+With the [Authorization Code Flow](/flows/concepts/auth-code), Auth0 sends you an authorization code, which your app then sends in to retrieve tokens. Your application authenticates itself with a Client ID and Client Secret stored securely on your server.
+
+On the other hand, the [Implicit Flow](/flows/concepts/implicit) allows you to request Access Tokens without needing to authenticate your application. Auth0 verifies your app's identity based on the provided redirect URI. Because of this, you shouldn't utilize long-lived Access Tokens, and you cannot use Refresh Tokens.
+
+## The Hybrid Flow
+
+The Hybrid Flow allows you to take advantage of aspects of both the Authorization Code and Implicit Grants. For each interaction with Auth0, you will receive two (sometimes three) items in response:
+
+1. An authorization code and an Access Token
+1. An authorization code and an ID Token
+1. An authorization code, an Access Token, and an ID Token
+
+In this article, we will take a closer look at how this flow works.
+
+## Overview of the flow
+
+1. The web application initiates the authorization flow and redirects the browser to Auth0 (specifically, the [Authorization Endpoint](/api/authentication#authorization-code-grant)) so that the user can authenticate.
+
+1. Auth0 authenticates the user via the browser. If this is the first time the user does this, they will see a consent page listing the permissions that Auth0 will give to the application.
+
+1. Auth0 redirects the user to the app with an [Access Token](/tokens/access-token) and (optionally) an [ID Token](/tokens/concepts/id-tokens) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment.
+
+1. The application parses out the Authorization Code, sends it to Auth0's [token endpoint](/api/authentication?http#authorization-code), and requests that Auth0 return (in exchange) the Access Token. The application identifies itself during this request using its assigned Client ID and Client Secret.
+
+1. If the request sent to the token endpoint is valid, Auth0 responds to the application's request with an ID Token, as well as an Access Token (and possibly a Refresh Token).
+
+1. The application can now validate the ID Token and retrieve the end user's information. The application can also use the Access Token to call desired APIs.
+
+  If the application received an ID Token from the Authorization endpoint already, it should have validated the token's signature, `c_hash`, and any other claims as defined. You must validate such tokens [the way you would for an Implicit Flow](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation).
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, refer to [Execute the Hybrid Flow](/api-auth/tutorials/hybrid-flow).
+
+## Keep reading
+
+::: next-steps
+- [Execute the Hybrid Flow](/api-auth/tutorials/hybrid-flow)
+- [How to configure an API in Auth0](/apis)
+- [Tokens](/tokens)
+- [Application authentication for regular web apps](/flows/concepts/auth-code)
+- [Application authentication for single-page apps](/flows/concepts/implicit)
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/api-auth/grant/implicit.md b/ja-jp/articles/api-auth/grant/implicit.md
new file mode 100644
index 0000000000..bf1a08f84c
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/implicit.md
@@ -0,0 +1,65 @@
+---
+title: Call APIs from Client-side Web Apps
+description: Learn how to call APIs from client-side web apps using the OAuth 2.0 Implicit Grant.
+toc: true
+topics:
+  - implicit
+  - api-authorization
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs from Client-side Web Apps
+
+In order to access an API from a [client-side app](/quickstart/spa) (typically a Single-Page Application or a Mobile Application), you need to implement the OAuth 2.0 **Implicit Grant**. In this document we will see how this flow works.
+
+::: note
+If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article.
+:::
+
+## Overview
+
+The **Implicit Grant** (defined in [RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.2)) is similar to the [Authorization Code Grant](/api-auth/grant/authorization-code), but the main difference is that the application receives an [Access Token](/tokens/concepts/access-tokens) directly, without the need for an `authorization_code`. This happens because the application, which is typically a JavaScript app running within a browser, is less trusted than a web app running on the server, hence cannot be trusted with the `client_secret` (which is required in the [Authorization Code Grant](/api-auth/grant/authorization-code)). Also, in the Implicit Grant, no Refresh Tokens are returned for the same reason (for an alternative refer to [Silent authentication for SPAs](/api-auth/tutorials/silent-authentication)).
+
+Once the user authenticates, the application receives the Access Token in the hash fragment of the URI. The application can now use this Access Token to call the API on behalf of the user.
+
+![Implicit Grant](/media/articles/api-auth/implicit-grant.png)
+
+ 1. The app initiates the flow and redirects the browser to Auth0 (specifically to the [/authorize endpoint](/api/authentication#implicit-grant)), so the user can authenticate.
+
+ 1. Auth0 authenticates the user. The first time the user goes through this flow a consent page will be shown where the permissions, that will be given to the Application, are listed (for example: post messages, list contacts, and so forth).
+
+ 1. Auth0 redirects the user to the app with an [Access Token](/tokens/concepts/access-tokens) (and optionally an [ID Token](/tokens/concepts/id-tokens)) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment. In a Single-Page Application (SPA) this would be done using Javascript and in a Mobile Application this is typically handled by interacting with a Web View.
+
+ 1. The app can use the Access Token to call the API on behalf of the user.
+
+::: note
+In OAuth 2.0 terms, the web app is the Application, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.
+:::
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, refer to [Execute an Implicit Grant](/api-auth/tutorials/implicit-grant).
+
+## Rules
+
+[Rules](/rules) will run for the Implicit grant. If you wish to execute special logic unique to the Implicit grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-implicit-profile`, then the rule is running during the Implicit grant.
+
+For details on how to implement this, refer to [How to implement the Implicit Grant: Customize the Tokens](/api-auth/tutorials/implicit-grant#optional-customize-the-tokens).
+
+## Silent Authentication
+
+If you need to authenticate your users without a login page (for example, when the user is already logged in via [Single Sign-on (SSO)](/sso) scenario) or get a new Access Token (thus simulate refreshing an expired token), you can use Silent Authentication.
+
+For details on how to implement this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication).
+
+## Keep reading
+
+::: next-steps
+* [How to implement the Implicit Grant](/api-auth/tutorials/implicit-grant)
+* [How to protect your SPA against replay attacks](/api-auth/tutorials/nonce)
+* [How to configure an API in Auth0](/apis)
+* [Tokens](/tokens)
+* [Application Authentication for Client-side Web Apps](/application-auth/client-side-web)
+:::
diff --git a/ja-jp/articles/api-auth/grant/password.md b/ja-jp/articles/api-auth/grant/password.md
new file mode 100644
index 0000000000..3da4c9a514
--- /dev/null
+++ b/ja-jp/articles/api-auth/grant/password.md
@@ -0,0 +1,67 @@
+---
+title: Call APIs from Highly Trusted Applications
+description: Describes how to call APIs from highly trusted applications using the Resource Owner Password Grant.
+topics:
+  - implicit
+  - api-authorization
+  - resource-owner-password
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs from Highly Trusted Applications
+
+<%= include('../_includes/_ropg-warning') %>
+
+You can use the ROPG flow for your highly trusted applications to access APIs. In this flow the end-user is asked to fill in credentials (username/password), typically using an interactive form. This information is sent to the backend and from there to Auth0. 
+
+ROPG (defined in [RFC 6749, section 4.3](https://tools.ietf.org/html/rfc6749#section-4.3)) can be used directly as an authorization grant to store the user credentials for future use, by exchanging the credentials for an Access Token, and optionally a Refresh Token. 
+
+![Resource Owner Password Grant](/media/articles/api-auth/password-grant.png)
+
+ 1. The end user enters the credentials into the application.
+ 1. The application forwards the credentials to Auth0.
+ 1. Auth0 validates the information and returns an Access Token, and optionally a Refresh Token.
+ 1. The application can use the Access Token to call the API on behalf of the end user.
+
+::: note
+In OAuth 2.0 terms, the web app is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.
+:::
+
+## How to implement the flow
+
+For details on how to implement this using Auth0, see [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant).
+
+## Realm support
+
+A extension grant that offers similar functionality with the **Resource Owner Password Grant**, including the ability to indicate a specific realm, is the `http://auth0.com/oauth/grant-type/password-realm`.
+
+Realms allow you to keep separate user directories and specify which one to use to the token endpoint. For example, you may have an application where both employees and customers can log in but their credentials are kept in separate user directories. You can present a user interface with a dropdown containing `Employees` or `Customers` as realms (which would be connections in [Auth0 dashboard](${manage_url})). The realm value, along with the username and password credentials, will be submitted to the token endpoint. Auth0 will use the realm value to determine which directory (connection) to use when verifying the password.
+
+For more information on how to implement this extension grant refer to [Executing a Resource Owner Password Grant > Realm Support](/api-auth/tutorials/password-grant#realm-support).
+
+## Scopes
+
+Due to the implied trust in these grants (a user providing his or her password to an application), the Access Token returned will include all of the available scopes defined for the audience API. An application can request a restricted set of scopes by using the `scope` parameter, or you can restrict the returned scopes by using a [rule](#customize-the-returned-token).
+
+## Rules
+
+[Rules](/rules) will run for the Password Exchange (including the Password Realm extension grant). There are two key differences in the behavior of rules in these flows:
+
+- Redirect rules won't work. If you try to do a [redirect](/rules/redirect) by specifying `context.redirect` in your rule, the authentication flow will return an error.
+
+If you wish to execute special logic unique to the Password exchange, you can look at the `context.protocol` property in your rule. If the value is `oauth2-password`, then the rule is running during the password exchange.
+
+For details on how to implement this, see [Customize the Tokens](/api-auth/tutorials/password-grant#optional-customize-the-tokens).
+
+## MFA support and anomaly detection
+
+For details on how to implement multi-factor authentication (MFA), refer to [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password).
+
+When using this flow from server-side applications, some anomaly detection features might fail because of the particularities of this scenario. For details on how to implement this, while avoiding some common issues, refer to [Using Resource Owner Password from Server side](/api-auth/tutorials/using-resource-owner-password-from-server-side).
+
+## Keep reading
+
+* [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant)
+* [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/index.md b/ja-jp/articles/api-auth/index.md
new file mode 100644
index 0000000000..2c2bdf84b6
--- /dev/null
+++ b/ja-jp/articles/api-auth/index.md
@@ -0,0 +1,178 @@
+---
+url: /api-auth
+section: articles
+classes: topic-page
+title: API Authorization
+topics:
+  - api-authentication
+  - oidc
+contentType: index
+useCase:
+  - secure-api
+  - call-api
+---
+
+
    
+  
    
+  
    API Authorization
    
+  
    
+    How to implement API authentication and authorization using the OAuth 2.0 authorization framework.
+  
    
+
    
+
+At some point, your custom APIs will need to allow limited access to users, servers, or servers on behalf of users. With Auth0 you can manage the authorization requirements for server-to-server and application-to-server applications.
+
+By using the OAuth 2.0 authorization framework, you can give your own applications or third-party applications limited access to your APIs on behalf of the application itself. With Auth0, you can easily support different flows in your own APIs without worrying about the OAuth 2.0/OpenID Connect (OIDC) specification, or the many other technical aspects of API authorization.
+
+In this page you can find a list of resources that can help you secure your APIs and access them in a secure manner.
+
+
diff --git a/ja-jp/articles/api-auth/intro.md b/ja-jp/articles/api-auth/intro.md
new file mode 100644
index 0000000000..77aa80441c
--- /dev/null
+++ b/ja-jp/articles/api-auth/intro.md
@@ -0,0 +1,327 @@
+---
+description: An overview of the OIDC Conformant authentication flows, why these changes were made and how you can adopt them.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# OIDC-Conformant Authentication Overview
+
+**Released Date**: May 10, 2017
+
+As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. This document presents an overview of these changes, explains why they were made and points you to other detailed tutorials to help you adopt these changes.
+
+We will start by reviewing the [new features](#what-s-new), and then continue with [what changed](#what-is-changing) and how you can [distinguish which authentication flow is used](#how-to-use-the-new-flows) (the latest or the legacy). Towards the end of this doc, you can find a [summarizing table](#legacy-vs-new) and [links for further reading](#keep-reading).
+
+## What should I read?
+
+If you are new to Auth0, go through the [What’s New](#what-s-new) section of this doc. There you can find all the cool new features we introduced, like the ability to create APIs, call them from services, or enable external parties or partners to access protected resources at your API in a secure way. Then head off to the [How to use the new flows](#how-to-use-the-new-flows) section and make sure that your new implementation follows our latest, and more secure, authentication pipeline.
+
+If you are already using Auth0 in your app, you should read the complete doc. We have taken great care to make sure that we do not break our existing customers with this new OIDC conformant implementation. However, you should be aware of all changes and new features, and how you can use them (or avoid doing so). It goes without saying that we strongly encourage you to adopt this authentication pipeline, to improve your app’s security.
+
+If you are using Auth0 as a [SAML or WS-Federation identity provider](/protocols/saml/saml-idp-generic) for your application (that is, you're not using OIDC/OAuth), then you do not need to make any changes.
+
+## What's New
+
+### APIs Section in the Dashboard
+
+You can now define your resource server APIs as entities separate from applications using our new APIs dashboard area.
+
+![APIs Dashboard](/media/articles/api-auth/api-dashboard.png)
+
+This lets you decouple your resource server APIs from the applications that consume them and also lets you define third-party applications that you might not control or even fully trust (keep reading for more info).
+
+::: note
+For more information on APIs, their role in OAuth and how to configure an API in Auth0 Dashboard, refer to [APIs Overview](/apis).
+:::
+
+### Third-Party Applications
+
+Up until recently we were treating every application as first-party application. This means that all applications were considered trusted. Now you have the option to define an application as either first-party or third-party.
+
+Third-party applications are applications that are controlled by different people or organizations who most likely should not have administrative access to your Auth0 domain. They enable external parties or partners to access protected resources at your API in a secure way. A practical application of third-party applications is the creation of "developer centers", which allow users to obtain credentials in order to integrate their applications with your API. Similar functionality is provided by well-known APIs such as Facebook, Twitter, Github, and many others.
+
+So far, third-party applications cannot be created from the dashboard. They must be created through the management API. We have also implemented [Dynamic Client Registration](/api-auth/dynamic-client-registration) functionality. All applications registered through that will be third-party applications.
+
+::: note
+For more information, refer to [User consent and third-party applications](/api-auth/user-consent).
+:::
+
+### Calling APIs from a Service (machine to machine)
+
+We implemented the OAuth 2.0 Client Credentials grant which allows applications to authenticate as themselves (that is, not on behalf of any user), in order to programmatically and securely obtain access to an API.
+
+::: note
+For more information on the Client Credentials grant, refer to [How to Implement the Client Credentials Grant](/flows/guides/client-credentials/call-api-client-credentials).
+:::
+
+## What is Changing
+
+### Calling APIs with Access Tokens
+
+Historically, protecting resources on your API has been accomplished using ID Tokens issued to your users after they authenticate in your applications. From now on, you should only use Access Tokens when calling APIs. ID Tokens should only be used by the application to verify that the user is authenticated and get basic user information. The main reason behind this change is security. For details, refer to [Tokens](/tokens).
+
+::: note
+For more information, refer to [Calling your APIs with Auth0 tokens](/api-auth/tutorials/adoption/api-tokens).
+:::
+
+### User Profile Claims and Scope
+
+Historically, you were able to define and request arbitrary application-specific claims. From now on, your application can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), as [defined by the OIDC Specification](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims), or any scopes supported by your [API](/apis).
+
+In order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims.
+
+To customize the tokens, use Hooks for the Client Credentials Flow, and Rules for the rest of the flows:
+- __Client Credentials Flow__: [Customize Tokens using Hooks](/flows/guides/client-credentials/call-api-client-credentials#customize-tokens)
+- __Trusted App Flow__: [Customize Tokens using Rules](/api-auth/grant/password#customizing-the-returned-tokens)
+- __Single-Page Flow__: [Customize Tokens using Rules](/flows/guides/implicit/call-api-auth-code-pkce#customize-tokens)
+- __Regular Web App Flow__: [Customize Tokens using Rules](/flows/guides/auth-code/call-api-auth-code#customize-tokens)
+- __Native/Mobile Flow__: [Customize Tokens using Rules](/flows/guides/auth-code-pkce/call-api-auth-code-pkce#customize-tokens)
+
+::: note
+For more information, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+:::
+
+### Single Sign-on (SSO)
+
+Initiating an Single Sign-on (SSO) session must now happen __only__ from an Auth0-hosted page and not from applications. This means that for SSO to work, you must be using Universal Login. Users must be redirected to the login page and then redirected to your application once authentication is complete.
+
+::: note
+Support for SSO from applications is planned for a future release.
+:::
+
+Not all [OAuth 2.0 grants](/protocols/oauth2#authorization-grant-types) support SSO at the moment:
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    OAuth 2.0 GrantSupports SSO?
    Authorization CodeYes
    Authorization Code (PKCE)Yes
    ImplicitYes
    Resource Owner PasswordNo
    
+
+::: note
+For more information, refer to [OIDC Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on).
+:::
+
+### Authorization Code Grant
+
+Some changes were introduced in the implementation of Authorization Code grant:
+
+- The `device` request parameter has been removed.
+- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued.
+- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter.
+- A Refresh Token will be returned only if the `offline_access` scope was granted.
+
+::: note
+For more information, refer to [Authorization Code grant](/api-auth/tutorials/adoption/authorization-code).
+:::
+
+### Implicit Grant
+
+Some changes were introduced in the implementation of Implicit grant:
+
+- The `device` request parameter has been removed.
+- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued.
+- The `response_type` request parameter indicates whether we want to receive both an Access Token and ID Token. If using `response_type=id_token`, we will return only an ID Token.
+- Refresh Tokens are not allowed. [Use `prompt=none` instead](/api-auth/tutorials/silent-authentication).
+- The `nonce` request parameter must be a [cryptographically-secure random string](/api-auth/tutorials/nonce). After validating the ID Token, the application must [validate the nonce to mitigate replay attacks](/api-auth/tutorials/nonce). Requests made without a `nonce` parameter will be rejected.
+- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter.
+- ID Tokens will be signed asymmetrically using `RS256`.
+
+::: note
+For more information, refer to [Implicit grant](/api-auth/tutorials/adoption/implicit).
+:::
+
+### Resource Owner Password Grant
+
+Some changes were introduced in the implementation of Resource Owner Password grant:
+
+- The `device` request parameter has been removed.
+- The `audience` request parameter has been introduced. This denotes the target API for which the token should be issued.
+- The endpoint to execute token exchanges is [/oauth/token](/api/authentication#resource-owner-password).
+- [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (`realm`). The [standard OIDC password grant](/api-auth/tutorials/password-grant) is also supported, but it does not accept Auth0-specific parameters such as `realm`.
+- The returned Access Token is a [JWT](/tokens/concepts/jwts), valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) and the API specified by the `audience` parameter.
+- The ID Token will be forcibly signed using `RS256` if requested by a [public application](/applications/concepts/app-types-confidential-public#public-applications).
+- A Refresh Token will be returned only if the `offline_access` scope was granted.
+
+::: note
+For more information, refer to [Resource Owner Password Credentials exchange](/api-auth/tutorials/adoption/password).
+:::
+
+### Delegation
+
+<%= include('../_includes/_deprecate-delegation') %>
+
+[Delegation](/api/authentication#delegation) is used for many operations:
+- Exchanging an ID Token issued to one application for a new one issued to a different application
+- Using a Refresh Token to obtain a fresh ID Token
+- Exchanging an ID Token for a third-party API token, such as Firebase or AWS.
+
+Given that [ID Tokens should no longer be used as API tokens](/api-auth/tutorials/adoption/api-tokens) and that [Refresh Tokens should be used only at the token endpoint](/api-auth/tutorials/adoption/refresh-tokens), this endpoint is now considered deprecated.
+
+### Passwordless
+
+Our new implementation only supports an [OIDC-conformant](/api-auth/tutorials/adoption) passwordless authentication mechanism when using web applications (with Lock.js or auth0.js).
+
+Native applications need to use Universal Login (with an Auth0-hosted login page). Customers can use the Lock (Passwordless) template in the [Dashboard](${manage_url}/#/login_settings) under **Universal Login -> Login -> Default Templates**, or customize it to fit specific requirements.
+
+### Other Authentication API endpoints
+
+- [/tokeninfo](/api/authentication#get-token-info): With the new implementation, this endpoint is disabled.
+
+- [/userinfo](/api/authentication#get-user-info): Responses will conform to the OIDC specification, similar to the contents of ID Tokens.
+
+- [/oauth/access_token](/api/authentication#social-with-provider-s-access-token): The [/oauth/access_token](/api/authentication#social-with-provider-s-access-token) endpoint, used on native social authentication on mobile devices (for example, use the Facebook SDK and then this endpoint to create the user in Auth0), is now disabled. The alternative is to open the browser to do social authentication, which is what [Google and Facebook are recommending](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html) since last year.
+
+- [/oauth/ro](/api/authentication#resource-owner): This endpoint will soon be deprecated. Use the password grant instead. Note that the password grant should be used only by highly trusted applications, with the current exception of native apps (not with SPAs). This grant's best use is to be called from the server-side of a regular web app or perhaps the backend API of a SPA. For more information on this grant refer to [Call APIs from Highly Trusted Applications](/api-auth/grant/password).
+
+## How to use the new flows
+
+To use the new pipeline, at least one of the following should apply:
+
+- The application is flagged as __OIDC Conformant__, or
+- The `audience` parameter is set in the [/authorize](/api/authentication#authorize-application) or [/token](/api/authentication#get-token) endpoints
+
+If none of these applies, then the legacy flows will be used.
+
+To mark your application as OIDC Conformant: go to [Dashboard](${manage_url}) > click [Applications](${manage_url}/#/applications) > select your application > go to _Settings_ > click the _Show advanced settings_ link at the end > click _OAuth_ > toggle the __OIDC Conformant__ flag.
+
+![OIDC Conformant flag](/media/articles/api-auth/oidc-conformant-flag.png)
+
+To use the `audience` parameter instead, configure your app to send it when initiating an authorization request.
+
+## Legacy vs New
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    LegacyOIDC
    Define APIs in the DashboardNot SupportedSupported
    Third-party ApplicationsNot SupportedSupported
    Client Credentials GrantThis grant does not exist in the legacy pipeline, but the Resource Owner Password Credentials exchange can be used to simulate it by creating a "service user". We strongly discourage the latter approach in favor of using Client Credentials, since it allows defining fine-grained permissions for each API application.Supported
    Token used to call an APIID TokenAccess Token
    Add arbitrary claims in TokensSupportedSupported. The namespaced format has to be used.
    SSOSupportedNot supported for Resource Owner grant. For the rest, Universal Login must be employed and users redirected to the login page.
+    
    Access Token formatOpaque stringJWT for customer APIs, opaque string for /userinfo only
    Authenticate users from a specific connection (realm)Supported (using /oauth/ro)New password-realm extension grant
    PasswordlessSupportedNot supported at the moment, will be in future releases
    /tokeninfo endpointSupportedDisabled
    /delegation endpointSupportedShould only be used to obtain third-party API tokens. A new mechanism will be provided  in future releases.
    /oauth/access_token endpointSupportedDisabled, an alternative will be added in future releases
    /userinfo endpointSupportedSupported. Responses will conform to the OIDC specification, similar to the contents of ID Tokens.
    Refresh Tokens with Implicit GrantSupportedDeprecated. Silent authentication should be used instead.
    /ssodata endpoint and getSSOData() method from auth0.js
+        Supported (up to auth0.js v8)Deprecated. Silent authentication should be used instead.
    Implicit Grant requests without nonce parameter setSupportedWill be rejected.
    device parameter (used to obtain Refresh Tokens)SupportedNot supported. /oauth/token
+should be used instead with "grant_type": "refresh_token"
    /oauth/ro endpointSupportedReplaced with Password Grant
    
+
+## Keep reading
+
+* [API Authorization index](/api-auth)
+* [Tokens](/tokens)
+
diff --git a/ja-jp/articles/api-auth/passwordless.md b/ja-jp/articles/api-auth/passwordless.md
new file mode 100644
index 0000000000..cc007bfeb4
--- /dev/null
+++ b/ja-jp/articles/api-auth/passwordless.md
@@ -0,0 +1,27 @@
+---
+title: Passwordless authentication (OIDC-conformant)
+topics:
+  - api-authentication
+  - oidc
+  - passwordless
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# OIDC Conformant Passwordless Authentication
+
+<%= include('./tutorials/adoption/_about.md') %>
+
+Passwordless connections allow users to login without the need to remember a password.
+
+This improves the user experience, especially on mobile applications, since users will only need to remember an email address or phone number to authenticate with your application.
+
+Without passwords, your application will not need to implement a password-reset procedure, and users avoid the insecure practice of using the same password for many purposes.
+
+## OIDC Conformant Passwordless
+
+Auth0 currently supports [OIDC-conformant](/api-auth/tutorials/adoption) passwordless authentication using Universal Login as well as in embedded web authentication scenarios using the newest [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js) libraries.
+
+Native applications need to use Universal Login. Customers can use the Lock (Passwordless) template for the login page in the [Dashboard](${manage_url}) under **Universal Login > Login > Default Templates**, or customize the page to fit specific requirements.
diff --git a/ja-jp/articles/api-auth/restrict-access-api.md b/ja-jp/articles/api-auth/restrict-access-api.md
new file mode 100644
index 0000000000..ae857bd87b
--- /dev/null
+++ b/ja-jp/articles/api-auth/restrict-access-api.md
@@ -0,0 +1,83 @@
+---
+  title: Restrict Access to APIs
+  description: Learn how to write rules that will restrict user/application access to an API.
+  topics:
+  - api-authentication
+  - oidc
+  - scopes
+  - permissions
+contentType: how-to
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Restrict Access to APIs
+
+Sometimes you may not want to allow an application or user to access an API. For example, you may want to restrict access to an API based on the calling application or a user's role or location. To do so, we use [rules](/rules).
+
+## Example: Deny access to anyone calling the API
+
+In this example, we want to deny access to all users who are calling the API. To do this, we create a [rule](/rules) to deny access depending on the `audience` parameter. In this case, the `audience` value for our API is `http:://todoapi2.api`, so this is the audience we will refuse.
+
+::: note
+The value of an API's `audience` is displayed in the **API Audience** field in the [APIs section of the Auth0 Dashboard](${manage_url}/#/apis).
+:::
+
+When a restricted user attempts to access the API, they will receive an `HTTP 401` response.
+
+```js
+function (user, context, callback) {
+
+  /*
+   *  Denies access to user-based flows based on audience
+   */
+
+  var audience = '';
+
+  audience = audience
+              || (context.request && context.request.query && context.request.query.audience)
+              || (context.request && context.request.body && context.request.body.audience);
+
+  if (audience === 'http://todoapi2.api' || !audience) {
+    return callback(new UnauthorizedError('end_users_not_allowed'));
+  }
+
+  return callback(null, user, context);
+}
+```
+
+## Example: Deny access to users from a specific calling application
+
+In this example, we want to deny access to all users who are accessing the API from a specific calling application. To do this, we create a [rule](/rules) to deny access depending on the `client_id` parameter. This is equivalent to disabling all connections for an application.
+
+::: note
+The value of an application's `client_id` is displayed in the **Client ID** field in the [Applications section of the Auth0 Dashboard](${manage_url}/#/applications).
+:::
+
+When a restricted user attempts to access the API, they will receive an `HTTP 401` response.
+
+```js
+function (user, context, callback) {
+
+  /*
+   *  Denies access to user-based flows based on client ID
+   */
+
+  var client_id = '';
+  client_id = context.clientID;
+
+  if (client_id === 'CLIENT_ID') {
+    return callback(new UnauthorizedError('end_users_not_allowed'));
+  }
+
+  return callback(null, user, context);
+}
+```
+## Example: Deny access to users based on a role
+
+By default, any user associated with an [Auth0 application](/applications) can request any [custom API scopes](/scopes/current/api-scopes) that have been created. Sometimes you may not want to allow a user to request certain scopes, though.
+
+To limit a user's scopes, you can assign them a role so that requests on their behalf are limited to just the scopes assigned to that role. To do this, you can use the [Authorization Extension](/extensions/authorization-extension) and a custom [Rule](/rules).
+
+We discuss this approach in more depth in our [SPA+API Architecture Scenario](/architecture-scenarios/spa-api). Specifically, you can review the [Configure the Authorization Extension](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension) section to learn how to configure the Authorization Extension and create a custom Rule that will ensure scopes are granted based on a user's role.
diff --git a/ja-jp/articles/api-auth/token-renewal-in-safari.md b/ja-jp/articles/api-auth/token-renewal-in-safari.md
new file mode 100644
index 0000000000..88742f553a
--- /dev/null
+++ b/ja-jp/articles/api-auth/token-renewal-in-safari.md
@@ -0,0 +1,56 @@
+---
+description: Issues with token renewal in Safari when ITP is enabled.
+topics:
+    - safari
+    - tokens
+    - token-renewal
+    - custom-domains
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Renew Tokens When Using Safari
+
+Renewing tokens with the `checkSession()` function does not work correctly with the latest version of the Safari browser.
+
+Recent versions of the Safari browser introduced a new featured called [Intelligent Tracking Prevention (ITP)](https://webkit.org/blog/category/privacy/). ITP is designed to prevent websites from tracking user activity across multiple websites.
+
+By default, ITP is active. You can determine if the Safari version you are using has ITP by going to **Preferences > Privacy** tab and seeing if the **Prevent cross-site tracking** option is checked.
+
+![Safari privacy preferences pane](/media/articles/api-auth/safari-privacy-preferences.png)
+
+## ITP and browser behavior
+
+Enabling ITP causes the browser to behave as if you had disabled third-party cookies in the browser: **checkSession()** is unable to access the current user's session, which makes it impossible to obtain a new token without displaying anything to the user.
+
+This is akin to the way OpenID Connect (OIDC) uses iframes for handling [sessions](/sessions) in SPAs.
+
+## Workarounds
+
+Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies. You can use [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) as an alternative that provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
+
+Alternatively, you can work around the issues posed by ITP by using Auth0's [custom domains](/custom-domains) functionality, particularly if the custom domain lives on a *subdomain* of the application's website domain. For example, if your application is hosted on **example.com**, the custom domain would need to be of the format **subdomain.example.com**.
+
+## ITP debug mode
+
+[Safari Technology Preview](https://developer.apple.com/safari/technology-preview/) offers an "Intelligent Tracking Prevention Debug Mode" that you can use to troubleshoot ITP issues. You can find instructions on how to debug ITP on [this blog post from WebKit](https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62/).
+
+**NOTE**: The instructions mention how to permanently classify a custom domain as having tracking abilities for testing purposes. In later versions of Safari Technology Preview, though, the domain to store the User Defaults for this setting changed from `com.apple.SafariTechnologyPreview` to `com.apple.WebKit.Networking`. If you are having trouble with the commands mentioned in the instructions, try these:
+
+* Classify a site as having tracking abilities:
+```
+defaults write com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource example.com
+```
+
+* Inspect the setting:
+```
+defaults read com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource
+```
+
+* Delete the setting:
+```
+defaults delete com.apple.WebKit.Networking ResourceLoadStatisticsManualPrevalentResource
+```
+
+You will need to restart Safari Technology Preview every time you make changes for the settings to take effect.
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/_about.md b/ja-jp/articles/api-auth/tutorials/adoption/_about.md
new file mode 100644
index 0000000000..e2f174b015
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/_about.md
@@ -0,0 +1,4 @@
+:::panel Adoption Guide
+This document is part of the adoption guide for OIDC-conformant authentication.
+If you haven't already, we strongly suggest [reading the introduction](/api-auth/tutorials/adoption) before reading this document.
+:::
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/_index.md b/ja-jp/articles/api-auth/tutorials/adoption/_index.md
new file mode 100644
index 0000000000..40760b5d79
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/_index.md
@@ -0,0 +1,13 @@
+* [Call APIs with Auth0 Tokens](/api-auth/tutorials/adoption/api-tokens)
+* [User Consent and Third-Party Applications](/api-auth/user-consent)
+* [User Profile Claims and the `scope` Parameter](/api-auth/tutorials/adoption/scope-custom-claims)
+* [Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on)
+* Initiating authentication flows:
+  - [Authorization Code Grant](/api-auth/tutorials/adoption/authorization-code)
+  - [Implicit Grant](/api-auth/tutorials/adoption/implicit)
+    * [Silent Authentication](/api-auth/tutorials/silent-authentication) (replaces Refresh Tokens for single-page applications)
+  - [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password)
+  - [Client Credentials Exchange](/api-auth/tutorials/adoption/client-credentials) (only available in new pipeline)
+* [Refresh Tokens](/api-auth/tutorials/adoption/refresh-tokens)
+* [Passwordless Authentication](/api-auth/passwordless)
+* [OIDC-Conformant Applications](/api-auth/tutorials/adoption/oidc-conformant)
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/api-tokens.md b/ja-jp/articles/api-auth/tutorials/adoption/api-tokens.md
new file mode 100644
index 0000000000..8c310789ec
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/api-tokens.md
@@ -0,0 +1,112 @@
+---
+title: Call APIs with Auth0 Tokens
+description: The OIDC-conformant pipeline and how this affects your use of Auth0 tokens with external APIs
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+  - scopes
+  - api-authentication
+  - oidc
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Call APIs with Auth0 Tokens
+
+<%= include('./_about.md') %>
+
+With the OIDC-conformant pipeline, all APIs should be secured with Access Tokens, not ID Tokens. In this article, we discuss what this means and what you need to do if you're using Auth0 tokens with your APIs.
+
+## OIDC-conformant pipeline and tokens
+
+In the OIDC-conformant pipeline, **ID Tokens should never be used as API tokens**.
+
+Instead, applications and APIs (resource services) should be defined as separate Auth0 entities. This allows you to obtain Access Tokens for your APIs.
+
+You get simpler API integration since your APIs are no longer tied to the applications that make calls to it. You're also enabling [machine-to-machine integration scenarios](/flows/concepts/client-credentials), since applications
+can authenticate as themselves (that is, they are not acting on behalf of any user) to programmatically and securely obtain an API token.
+
+For example, [the Auth0 Management API is already defined as a resource server on your
+Auth0 domain](${manage_url}/#/apis/management/settings). You can then authorize applications seeking access to obtain API tokens with specific scopes in a secure way.
+
+### Access vs. ID Tokens
+
+One way to understand how Access and ID Tokens differ in their behavior is to look at the contents of the tokens themselves.
+
+**The ID Token**
+
+```json
+{
+  "iss": "http://my-domain.auth0.com",
+  "sub": "auth0|123456",
+  "aud": "my_client_id",
+  "exp": 1311281970,
+  "iat": 1311280970,
+  "name": "Jane Doe",
+  "given_name": "Jane",
+  "family_name": "Doe",
+  "gender": "female",
+  "birthdate": "0000-10-31",
+  "email": "janedoe@example.com",
+  "picture": "http://example.com/janedoe/me.jpg"
+}
+```
+
+The sample above shows the contents of an ID Token. ID Tokens are meant only for **authenticating** the users to the **application**.
+
+Note that the audience value (located in the **aud** claim) of the token is set to the application's identifier. This means that only this specific application should consume the token.
+
+You can think of the ID Token as a performance optimization that allows applications to obtain user profile information without making additional requests after the completion of the authentication process. ID Tokens should never be used to obtain direct access to resources or to make authorization decisions.
+
+**The Access Token**
+
+Let's now take a look at the contents of an Access Token:
+
+```json
+{
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "auth0|123456",
+  "aud": [
+    "https://example.com/health-api",
+    "https://my-domain.auth0.com/userinfo"
+  ],
+  "azp": "my_client_id",
+  "exp": 1311281970,
+  "iat": 1311280970,
+  "scope": "openid profile read:patients read:admin"
+}
+```
+
+The Access Token is meant to **authorize** the user to the **API (resource server)**. As such, the token is **Completely opaque to applications** -- applications should not care about the contents of the token.
+
+The token does not contain any information about the user except for the user ID (located in the **sub** claim). The token only contains authorization information about the actions that application is allowed to perform at the API (such permissions are referred to as **scopes**).
+
+In many cases, you may find it useful to retrieve additional user information. You can do this by calling the [/userinfo API endpoint](/api/authentication#get-user-info) with the Access Token. Be sure that the API for which the Access Token is issued uses the **RS256** [signing algorithm](/tokens/concepts/signing-algorithms).
+
+## Scopes
+
+With the OIDC-conformant pipeline, the **scope** parameter [behaves differently](/api-auth/tutorials/adoption/scope-custom-claims) from the **scope** parameter associated with the legacy pipeline.
+
+The scope parameter in the OIDC-conformant pipeline determines:
+
+* The permissions that an authorized application should have for a given resource server
+* Which standard profile claims should be included in the ID Token (if the user consents to provide this information to the application)
+
+If you have multiple apps calling an API under a single client ID, you should represent each application with a single Auth0 application, each of which can interact with the resource server representing the API on which these apps depend.
+
+Similarly, if you use delegation to exchange tokens obtained by one application for tokens for a different application, you should also be using a multi-application solution, each authenticating to the same resource server.
+
+If your applications do not depend on external APIs and you just need to authenticate users, you do not need to define a resource server/API as long as the ID Tokens are:
+
+* Processed only by the application
+* Not sent to any external services
+
+::: note
+For more information on API authentication and authorization refer to API Authorization.
+:::
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/authorization-code.md b/ja-jp/articles/api-auth/tutorials/adoption/authorization-code.md
new file mode 100644
index 0000000000..073cef649a
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/authorization-code.md
@@ -0,0 +1,235 @@
+---
+description: OIDC-conformant Authorization Code grant
+topics:
+  - api-authentication
+  - oidc
+  - authorization-code
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Authorization Code Grant
+
+<%= include('./_about.md') %>
+
+The [Authorization Code Grant](/flows/concepts/auth-code) is used by server-side applications that are capable of securely storing secrets, or by [native applications through PKCE](/flows/concepts/auth-code-pkce).
+This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines.
+
+## Authentication request
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    GET /authorize?
+    response_type=code
+    &scope=openid email favorite_color offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com/callback
+    &device=my-device-name
    
+    
+    
    
+    
    
+      
    GET /authorize?
+    response_type=code
+    &scope=openid email offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com/callback
+    &audience=https://api.example.com 
    
+    
      
+        
    • favorite_color is no longer a valid scope value.
      • 
+        
    • The device parameter is removed.
      • 
+        
    • The audience parameter is optional.
      • 
+    
    
+    
    
+  
    
+
    
+
+## Authentication response
+
+The response from Auth0 is identical in both pipelines:
+
+```text
+HTTP/1.1 302 Found
+Location: https://app.example.com/callback?
+    code=SplxlOBeZQQYbYS6WxSbIA
+    &state=af0ifjsldkj
+```
+
+
+## Code exchange request
+
+An authorization code can be exchanged in the same way in both pipelines:
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/token",
+    "headers": [
+      { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+    ],
+    "postData" : {
+      "mimeType": "application/x-www-form-urlencoded",
+      "params": [
+        {
+          "name": "grant_type",
+          "value": "authorization_code"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        },
+        {
+          "name": "code",
+          "value": "YOUR_AUTHORIZATION_CODE"
+        },
+        {
+          "name": "redirect_uri",
+          "value": "${account.callback}"
+        }
+      ]
+    }
+}
+```
+
+## Code exchange response
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "SlAV32hkKG",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
    
+    
      
+        
    • The returned Access Token is only valid for calling the /userinfo endpoint.
      • 
+        
    • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
      • 
+    
    
+    
    
+    
    
+      
    HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "eyJ...",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
    
+        
      
+            
    • The returned Access Token is valid for optionally calling the API specified in the audience parameter and the /userinfo endpoint (provided that the API uses RS256 as the signing algorithm and openid is used as a scope parameter). If you are not implementing your own Resource Server (API), then you can use https://{$account.namespace}/userinfo as the audience parameter, which will return an opaque Access Token.
      • 
+            
    • A Refresh Token will be returned only if the offline_access scope was granted.
      • 
+        
    
+    
    
+  
    
+
    
+
+## ID Token structure
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue"
+}
    
+        
      
+            
    • The favorite_color claim must be namespaced and added through a rule.
      • 
+        
    
+    
    
+  
    
+
    
+
+## Access Token structure (optional)
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    SlAV32hkKG
    
+      
      
+        
    • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
      • 
+      
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
    
+        
      
+            
    • The returned Access Token is valid for optionally calling the API specified in the audience parameter and the /userinfo endpoint (provided that the API uses RS256 as the signing algorithm and openid is used as a scope parameter). If you are not implementing your own Resource Server (API), then you can use https://{$account.namespace}/userinfo as the audience parameter, which will return an opaque Access Token.
      • 
+        
    
+    
    
+  
    
+
    
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/client-credentials.md b/ja-jp/articles/api-auth/tutorials/adoption/client-credentials.md
new file mode 100644
index 0000000000..bc6189bcf3
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/client-credentials.md
@@ -0,0 +1,29 @@
+---
+title: Client Credentials exchange
+topics:
+  - api-authentication
+  - oidc
+  - client-credentials
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Client Credentials Exchange
+
+<%= include('./_about.md') %>
+
+The [Client Credentials exchange](/flows/concepts/client-credentials) allows apps to authenticate as themselves (that is, not on behalf of any user) to programmatically and securely obtain access to an API.
+
+This exchange does not exist in the legacy pipeline, but the [Resource Owner Password Credentials exchange](/api-auth/tutorials/adoption/password) can be used to simulate it by creating a "service user".
+
+We strongly discourage the latter approach in favor of using Client Credentials, since it allows defining fine-grained permissions for each API app.
+
+::: note
+  For more information on how to execute a Client Credentials exchange, refer to Call API Using the Client Credentials Flow.
+:::
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/delegation.md b/ja-jp/articles/api-auth/tutorials/adoption/delegation.md
new file mode 100644
index 0000000000..8fea9b651a
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/delegation.md
@@ -0,0 +1,37 @@
+---
+title: Delegation and the OIDC-conformant pipeline
+topics:
+  - api-authentication
+  - oidc
+  - delegation
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Delegation and the OIDC-Conformant Pipeline
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+<%= include('./_about.md') %>
+
+[Delegation](/api/authentication#delegation) is used for many operations, depending on your particular use case:
+
+* Exchanging an ID Token issued to one application for a new one issued to a different application
+* Using a Refresh Token to obtain a fresh ID Token
+* Exchanging an ID Token for a third-party API token, such as Firebase or AWS.
+
+Given that [ID Tokens should no longer be used as API tokens](/api-auth/tutorials/adoption/api-tokens) and that [Refresh Tokens should be used only at the token endpoint](/api-auth/tutorials/adoption/refresh-tokens), this endpoint is now considered deprecated.
+
+Applications marked as [OIDC-conformant](/api-auth/tutorials/adoption/oidc-conformant) cannot be the source or target of Auth0-to-Auth0 delegation requests.
+
+## Third-party APIs (such as Firebase or AWS)
+
+At the moment there is no OIDC-compliant mechanism to obtain third-party API tokens.
+In order to facilitate a gradual migration to the new authentication pipeline, delegation can still be used to obtain third-party API tokens.
+This will be deprecated in future releases.
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/implicit.md b/ja-jp/articles/api-auth/tutorials/adoption/implicit.md
new file mode 100644
index 0000000000..451729f8b3
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/implicit.md
@@ -0,0 +1,185 @@
+---
+description: Understand how the implicit grant is used by apps that are incapable of securely storing secrets such as SPA JS apps.
+topics:
+  - api-authentication
+  - oidc
+  - implicit
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Implicit Grant
+
+<%= include('./_about.md') %>
+
+The [Implicit grant](/flows/concepts/implicit) is used by applications that are incapable of securely storing secrets, such as single-page JavaScript applications.
+This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines.
+
+## Authentication request
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    GET /authorize?
+    response_type=token
+    &scope=openid email favorite_color offline_access
+    &client_id=123
+    &state=af0ifjsldkj
+    &redirect_uri=https://app.example.com
+    &device=my-device-name
    
+    
+    
    
+    
    
+      
    GET /authorize?
+    response_type=token id_token
+    &scope=openid email
+    &client_id=123
+    &state=af0ifjsldkj
+    &nonce=jxdlsjfi0fa
+    &redirect_uri=https://app.example.com
+    &audience=https://api.example.com 
    
+    
      
+        
    • This response_type parameter indicates that we want to receive both an Access Token and ID Token.
      • 
+        
    • Refresh Tokens are not allowed in the implicit grant. Use prompt=none instead.
      • 
+        
    • favorite_color is no longer a valid scope.
      • 
+        
    • The audience parameter is optional.
      • 
+        
    • The nonce parameter must be a cryptographically-secure random string.
      • 
+    
    
+    
    
+  
    
+
    
+
+## Authentication response
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    HTTP/1.1 302 Found
+Location: https://app.example.com/#
+    access_token=SlAV32hkKG
+    &expires_in=86400
+    &state=af0ifjsldk
+    &id_token=eyJ...
+    &refresh_token=8xLOxBtZp8
+    &token_type=Bearer
    
+    
      
+        
    • The returned Access Token is valid for calling the /userinfo endpoint.
      • 
+        
    • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
      • 
+    
    
+    
    
+    
    
+      
    HTTP/1.1 302 Found
+Location: https://app.example.com/#
+    access_token=eyJ...
+    &expires_in=86400
+    &state=af0ifjsldk
+    &id_token=eyJ...
+    &token_type=Bearer
    
+    
      
+        
    • The returned Access Token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
      • 
+        
    • If using response_type=id_token, Auth0 will only return an ID Token.
      • 
+        
    • Refresh Tokens are not allowed in the implicit grant. Use prompt=none instead.
      • 
+    
    
+    
    
+  
    
+
    
+
+
+## ID Token structure
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue",
+    "nonce": "jxdlsjfi0fa"
+}
    
+        
+    
    
+  
    
+
    
+
+## Access Token structure (optional)
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    SlAV32hkKG
    
+      
      
+        
    • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
      • 
+      
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
    
+        
      
+            
    • The returned Access Token is a JWT valid for calling the /userinfo endpoint(provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
      • 
+            
    • Note that an opaque Access Token could still be returned if /userinfo is the only specified audience.
      • 
+        
    
+    
    
+  
    
+
    
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/index.md b/ja-jp/articles/api-auth/tutorials/adoption/index.md
new file mode 100644
index 0000000000..eb7827dc97
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/index.md
@@ -0,0 +1,57 @@
+---
+url: /api-auth/tutorials/adoption
+title: OIDC Conformant Authentication Adoption Guide
+topics:
+  - api-authentication
+  - oidc
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# OIDC Conformant Authentication Adoption Guide
+
+Auth0 is a [certified OpenID Connect (OIDC) provider](http://openid.net/certification/), but not all Auth0 documentation and features conform to the [OIDC specification](http://openid.net/specs/openid-connect-core-1_0.html).
+
+As part of our efforts to improve security and standards-based interoperability, we are rolling out new features exclusively on authentication flows that strictly conform to specifications. The first of these features is [API Authentication and Authorization](/api-auth), which is available today.
+
+This guide details all the upcoming changes, **some of which will be breaking**, and provides suggestions on how to adapt your existing applications.
+
+## Who is this guide for?
+
+This guide is meant for developers and IT admins who manage Auth0 integrations in their applications. If you are not familiar with how OAuth works at a basic level, [we suggest reading our protocol overview](/protocols/oauth2).
+
+If you are integrating Auth0 as a [SAML or WS-Federation **identity provider**](/saml-idp-generic) for your application (that is, not through OIDC/OAuth), then you do not need to make any changes.
+
+To make this guide accessible to everyone, any authentication flows will be described only through HTTP requests instead of in the context of any particular language or library's implementation. This is the similar to the descriptions and examples provided by the [official OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html).
+
+## Terminology
+
+All of the changes described in this guide apply to the **OIDC Conformant Authentication Pipeline**. This pipeline will be used if **any** of the following are true:
+
+-   An [authentication request](/api/authentication#social) was initiated with an `audience` parameter.
+
+-   The application being used is flagged as **OIDC Conformant** (available at _Dashboard > Applications > Settings > Show advanced settings > OAuth > OIDC Conformant flag_).
+
+If none of these conditions are met, the **legacy authentication pipeline** will be used, and everything will keep working as usual.
+
+## My application works just fine, why should I update?
+
+Any new Auth0 features, examples and documentation moving forward will target only the OIDC-conformant pipeline. All Auth0 SDK versions that depend on the legacy pipeline are deprecated and will not receive updates for new features or non-critical security issues, and will eventually be discontinued.
+
+The new features provided by the OIDC-conformant pipeline include:
+
+* [Create third-party applications for your APIs and display consent dialogs for authorization](/api-auth/user-consent)
+* Restrict the user profile information provided to applications upon authentication
+* [OIDC Dynamic Client Registration](/api-auth/dynamic-client-registration)
+
+## Is there a deadline to adopt these new features?
+
+We understand that making changes to the core authentication logic of your application is not something that you want to do every day, and that any changes need to be thoroughly tested. Because of this, we are not setting a deadline to make changes at this time. Instead, both authentication pipelines (OIDC-conformant and legacy) will be usable until further notice.
+
+All Auth0 documentation, SDKs, libraries and samples will eventually apply only to the OIDC-conformant pipeline. Because of this, we strongly recommend adoption even if you do not need to leverage any new features or functionality in the near future.
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/oidc-conformant.md b/ja-jp/articles/api-auth/tutorials/adoption/oidc-conformant.md
new file mode 100644
index 0000000000..a8a601f4ad
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/oidc-conformant.md
@@ -0,0 +1,57 @@
+---
+description: List of breaking changes for OIDC-conformant applications
+topics:
+  - api-authentication
+  - oidc
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# OIDC-Conformant Applications
+
+<%= include('./_about.md') %>
+
+In order to make the transition to the [OIDC-conformant authentication pipeline](/api-auth/tutorials/adoption) more predictable, applications now include an option called "OIDC Conformant", available under **Advanced Settings > OAuth**:
+
+![OIDC-conformant application setting](/media/articles/dashboard/oidc_conformant.png)
+
+The objective of this flag is to disable as many legacy features as possible, so you can run into the OIDC-conformant pipeline's breaking changes at configuration time rather than run time.
+Enabling this flag on an application will have the following effects:
+
+* The following features are deprecated:
+    - Refresh Tokens on authentication with the [implicit grant](/api-auth/tutorials/adoption/implicit)
+    - /ssodata endpoint and `getSSOData()` method from Lock/auth0.js
+* [Single Sign-on (SSO)](/api-auth/tutorials/adoption/single-sign-on) can only be performed from Auth0 login pages.
+* Using `response_type=token` will only return an Access Token, not an ID Token. Use `response_type=id_token` or `response_type=token id_token` instead.
+* ID Tokens obtained with the implicit grant will be signed asymmetrically using RS256.
+* The /tokeninfo endpoint is disabled.
+* Responses from /userinfo will [conform to the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse), similar to the [contents of ID Tokens](/api-auth/tutorials/adoption/scope-custom-claims)
+* Implicit grant authentication requests made without a [`nonce` parameter](/api-auth/tutorials/nonce) will be rejected.
+* [Refresh Tokens must be used at the token endpoint]() instead of /delegation.
+* The `device` parameter, originally used to obtain Refresh Tokens, is now considered invalid.
+* The legacy [resource owner endpoint](/api/authentication#database-ad-ldap-active-) is disabled.
+    - Passwordless authentication for embedded login is implemented at this endpoint, so it will be disabled as well. 
+* The [/oauth/access_token endpoint](/api/authentication#post-oauth-access_token), used for social authentication from native mobile applications, is disabled.
+  An OIDC-conformant alternative will be added in future releases.
+* The [`scope` parameter of authentication requests](/api-auth/tutorials/adoption/scope-custom-claims) will comply to the OIDC specification:
+    - Custom claims must be [namespaced](/tokens/guides/create-namespaced-custom-claims) and added to ID Tokens or Access Tokens via rules.
+    - The namespace identifiers for custom claims must be **HTTP** or **HTTPS** URIs.
+    - Custom scope values can be defined by a [resource server (API)](/api-auth/tutorials/adoption/api-tokens).
+* OIDC-conformant applications cannot be the source or target application of a [delegation request](/api-auth/tutorials/adoption/delegation).
+
+## I don't want to make all these changes at once!
+
+The "OIDC Conformant" flag will force all of these changes at the same time for a given application, but it's not the only option to gradually transition to the OIDC-conformant authentication pipeline.
+Any authentication requests made with an `audience` parameter will use the new pipeline, and all other requests will continue to work as usual.
+
+If your application doesn't need a resource server but you want opt-in to the new pipeline on a per-request basis, you can use the following `audience` parameter:
+
+```
+https://${account.namespace}/userinfo
+```
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/password.md b/ja-jp/articles/api-auth/tutorials/adoption/password.md
new file mode 100644
index 0000000000..15834e8bba
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/password.md
@@ -0,0 +1,198 @@
+---
+description: Understand how the Resource Owner Password Grant (ROPG) is used by highly-trusted apps to provide active authentication. 
+topics:
+  - api-authentication
+  - oidc
+  - resource-owner-password
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+# Resource Owner Password Credentials Exchange
+
+<%= include('../../_includes/_ropg-warning.md') %>
+
+<%= include('./_about.md') %>
+
+The [Resource Owner Password Credentials exchange](/api-auth/grant/password) is used by highly-trusted applications to provide active authentication. Unlike the authorization code and implicit grants, this authentication mechanism does not redirect users to Auth0. It authenticates users with a single request, exchanging their password credentials for a token.
+
+This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines.
+
+## Authentication request
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    POST /oauth/ro HTTP 1.1
+Content-Type: application/json
+{
+  "grant_type": "password",
+  "client_id": "123",
+  "username": "alice",
+  "password": "A3ddj3w",
+  "connection": "my-database-connection",
+  "scope": "openid email favorite_color offline_access",
+  "device": "my-device-name"
+}
    
+    
+    
    
+    
    
+      
    POST /oauth/token HTTP 1.1
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fpassword-realm&client_id=123&username=alice&password=A3ddj3w&realm=my-database-connection&scope=openid+email+offline_access&audience=https%3A%2F%2Fapi.example.com
+
    
+    
      
+        
    • The endpoint to execute token exchanges is /oauth/token.
      • 
+        
    • Auth0's own grant type is used to authenticate users from a specific connection (realm). The standard OIDC password grant is also supported, but it does not accept Auth0-specific parameters such as realm.
      • 
+        
    • favorite_color is no longer a valid scope.
      • 
+        
    • The device parameter is removed.
      • 
+        
    • The audience parameter is optional.
      • 
+    
    
+    
    
+  
    
+
    
+
+## Authentication response
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "SlAV32hkKG",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
    
+    
      
+        
    • The returned Access Token is only valid for calling the /userinfo endpoint.
      • 
+        
    • A Refresh Token will be returned only if a device parameter was passed and the offline_access scope was requested.
      • 
+    
    
+    
    
+    
    
+      
    HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+{
+    "access_token": "eyJ...",
+    "token_type": "Bearer",
+    "refresh_token": "8xLOxBtZp8",
+    "expires_in": 3600,
+    "id_token": "eyJ..."
+}
    
+    
      
+        
    • The returned Access Token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
      • 
+        
    • The ID Token will be forcibly signed using RS256 if requested by a public application.
      • 
+        
    • A Refresh Token will be returned only if the offline_access scope was granted.
      • 
+    
    
+    
    
+  
    
+
    
+
+
+## ID Token structure
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "favorite_color": "blue"
+}
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": "123",
+    "exp": 1482809609,
+    "iat": 1482773609,
+    "email": "alice@example.com",
+    "email_verified": true,
+    "https://app.example.com/favorite_color": "blue"
+}
    
+        
      
+            
    • The ID Token will be forcibly signed using RS256 if requested by a public application.
      • 
+            
    • The favorite_color claim must be namespaced and added through a rule.
      • 
+        
    
+    
    
+  
    
+
    
+
+## Access Token structure (optional)
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    SlAV32hkKG
    
+      
      
+        
    • The returned Access Token is opaque and only valid for calling the /userinfo endpoint.
      • 
+      
    
+    
    
+    
    
+      
    {
+    "sub": "auth0|alice",
+    "iss": "https://${account.namespace}/",
+    "aud": [
+        "https://api.example.com",
+        "https://${account.namespace}/userinfo"
+    ],
+    "azp": "123",
+    "exp": 1482816809,
+    "iat": 1482809609,
+    "scope": "openid email"
+}
    
+        
      
+            
    • The returned Access Token is a JWT valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
      • 
+            
    • Note that an opaque Access Token could still be returned if /userinfo is the only specified audience.
      • 
+        
    
+    
    
+  
    
+
    
+
+## Standard password grant requests
+
+The Auth0 password realm grant is not defined by standard OIDC, but it is suggested as an alternative to the legacy resource owner endpoint because it supports the Auth0-specific `realm` parameter. The [standard OIDC grant is also supported](/api-auth/tutorials/password-grant) when using OIDC authentication.
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/refresh-tokens.md b/ja-jp/articles/api-auth/tutorials/adoption/refresh-tokens.md
new file mode 100644
index 0000000000..fa8d7447b6
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/refresh-tokens.md
@@ -0,0 +1,58 @@
+---
+description: Understand how refresh tokens are used in an OIDC-conformant authentication pipeline.
+topics:
+  - api-authentication
+  - oidc
+  - tokens
+  - refresh tokens
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# OIDC-Conformant Refresh Tokens
+
+<%= include('./_about.md') %>
+
+There are some changes to how Refresh Tokens are used in the OIDC-conformant authentication pipeline:
+
+* Using the [implicit grant](/api-auth/tutorials/adoption/implicit) for authentication will no longer return Refresh Tokens.
+* Refresh Tokens should only be used by [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications). However, they can also be used by Native (public) applications to obtain Refresh Tokens for mobile apps. 
+* The `/delegation` endpoint is deprecated. To obtain new tokens from a Refresh Token, the `/oauth/token` endpoint should be used instead:
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    POST /delegation
+Content-Type: 'application/json'
+{
+  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
+  "client_id": "...",
+  "refresh_token": "...",
+  "scope": "openid profile"
+}
+
    
+   
    
+    
    
+      
    POST /oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=refresh_token&refresh_token=123&client_id=123&client_secret=123&scope=openid+profile&audience=https%3A%2F%2Fapi.example.com
+
    
+
    • The audience and client_secret parameters are optional. The client_secret is not needed when requesting a refresh_token for a mobile app.
    
+   
    
+  
    
+
    
+
+Please note that Refresh Tokens must be kept confidential in transit and storage, and they should be shared only among the authorization server and the client to whom the Refresh Tokens were issued.
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/scope-custom-claims.md b/ja-jp/articles/api-auth/tutorials/adoption/scope-custom-claims.md
new file mode 100644
index 0000000000..10b72653ed
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/scope-custom-claims.md
@@ -0,0 +1,101 @@
+---
+description: Apps can request any standard OIDC scopes such as profile and email as well as any scopes supported by the API they want to access.
+topics:
+  - api-authentication
+  - oidc
+  - scopes
+  - user-profiles
+  - claims
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# User Profile Claims and the `scope` Parameter
+
+<%= include('./_about.md') %>
+
+The behavior of the `scope` parameter has been changed to conform to the [OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims).
+
+Instead of requesting arbitrary application-specific claims, applications can request any of the standard OIDC scopes such as `profile` and `email`, as well as any [scopes supported by the API they want to access](/api-auth/tutorials/adoption/api-tokens).
+
+## Standard claims
+
+The OIDC specification defines a [set of standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users that can be returned in ID Tokens or in the response from /userinfo.
+
+## Custom claims
+
+To improve compatibility for applications, Auth0 now returns profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). You can still add custom claims, but they must conform to a namespaced format to avoid possible collisions with standard OIDC claims. Otherwise, it is no longer possible to add arbitrary claims to ID Tokens or Access Tokens. 
+
+For example, suppose an identity provider returns a `favorite_color` claim as part of the user’s profile, and that we’ve used the Auth0 management API to set application-specific information for this user.
+
+This would be the profile stored by Auth0:
+
+```json
+{
+  "email": "jane@example.com",
+  "email_verified": true,
+  "user_id": "custom|123",
+  "favorite_color": "blue",
+  "user_metadata": {
+    "preferred_contact": "email"
+  }
+}
+```
+
+This is a [*normalized user profile*](/users/normalized), which is a protocol-agnostic representation of this user as defined by Auth0. When performing an OIDC conformant login, Auth0 would return the following ID Token claims to the application:
+
+```json
+{
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "custom|123",
+  "aud": "my_client_id",
+  "exp": 1311281970,
+  "iat": 1311280970,
+  "email": "jane@example.com",
+  "email_verified": true
+}
+```
+
+Note that the `user_id` property is sent as `sub` in the ID Token, and that `favorite_color` and `user_metadata` are not present in the OIDC response from Auth0. This is because OIDC does not define standard claims to represent all the information in this user’s profile. We can, however, define a non-standard claim by namespacing it through a [rule](/rules):
+
+```js
+function (user, context, callback) {
+  const namespace = 'https://myapp.example.com/';
+  context.idToken[namespace + 'favorite_color'] = user.favorite_color;
+  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
+  callback(null, user, context);
+}
+```
+
+::: note 
+If you need to add custom claims to the Access Token, you can use the code sample above with the following change: use `context.accessToken` in place of `context.idToken`.
+
+Please note that adding custom claims to tokens through this method will also let you obtain them when calling the `/userinfo` endpoint. However, rules run when the user is authenticating, not when `/userinfo` is called.
+:::
+
+Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. The namespace URL does not have to point to an actual resource, it’s only used as an identifier and will not be called by Auth0. 
+
+::: warning
+`auth0.com`, `webtask.io` and `webtask.run` are Auth0 domains and therefore cannot be used as a namespace identifier.
+:::
+
+This follows a [recommendation from the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims) stating that custom claim identifiers should be collision-resistant. While this is not mandatory according to the specification, Auth0 will always enforce namespacing when performing OIDC-conformant login flows, meaning that any custom claims without HTTP/HTTPS namespaces will be silently excluded from tokens.
+
+::: note
+Auth0 will allow non-OIDC claims without a namespace (the "legacy" user profile, from which we strongly recommend moving away) if:
+
+* You are using the non-OIDC conformant pipeline (i.e., you are not using the `audience` parameter in the `/authorize` or token request and the application does not have the [**OIDC-Conformant** toggle](https://auth0.com/docs/api-auth/tutorials/adoption/oidc-conformant) enabled).
+* You have the **Legacy User Profile** toggle turned on in the [tenant Advanced Settings](https://manage.auth0.com/#/tenant/advanced), under the **Migrations** section. This setting is only enabled for old tenants, but newly created tenants can't see or enable the **Legacy User Profile**. 
+
+We strongly recommend moving away from the Legacy User Profile.
+:::
+
+## Token refresh flow and custom claims
+
+When an application requests new tokens using a Refresh Token, the new tokens will not automatically inherit any custom claims previously added. But since rules run on a token refresh flow as well, the same claim customization code will be executed in these cases. This gives the flexibility of adding or changing claims in newly issued tokens without forcing applications to obtain a new refresh token.
+
+## Keep reading
+
+<%= include('./_index.md') %>
diff --git a/ja-jp/articles/api-auth/tutorials/adoption/single-sign-on.md b/ja-jp/articles/api-auth/tutorials/adoption/single-sign-on.md
new file mode 100644
index 0000000000..f421306e27
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/adoption/single-sign-on.md
@@ -0,0 +1,62 @@
+---
+description: Understand how OIDC Single Sign-On occurs when a user logs into one app and is then signed into other apps automatically. 
+topics:
+  - api-authentication
+  - oidc
+  - sso
+contentType: concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# OIDC Single Sign-On
+
+<%= include('./_about.md') %>
+
+Single Sign-on (SSO) occurs when a user logs into one application and is then signed into other applications automatically.
+
+In the context of the OIDC-conformant authentication pipeline, SSO must happen at the authorization server (i.e. Auth0) and not applications.
+
+This means that for SSO to happen, you must employ Universal Login and redirect users to the login page.
+
+## How it works
+
+At a general level, this is what happens when performing SSO:
+
+1. If the user is not logged in locally, redirect them to Auth0 for authentication. This is done using the [Authorization Code Flow](/flows/concepts/auth-code) or [Implicit Flow](/flows/concepts/implicit), depending on the type of application.
+2. If the user was logged in through SSO, Auth0 will immediately authenticate them without needing to re-enter credentials.
+
+An application that does not use SSO might decide to use embedded login to authenticate users instead of redirecting to Auth0 for authentication.
+
+## Determining if users are logged in via SSO
+
+An application can easily determine if a user is logged in locally by checking the validity of a local ID Token or session cookie.
+However, in some cases your application might need to determine if the user has a valid SSO session at Auth0.
+In the legacy authentication pipeline, this could be achieved by using the `/ssodata` endpoint, which would return information about the user's SSO session.
+OIDC-conformant applications must use [silent authentication](/api-auth/tutorials/silent-authentication), which either re-authenticates a user if they are already logged in, or returns an error if they need to authenticate.
+
+## Authentication flows without SSO
+
+SSO [sessions](/sessions) are managed by Auth0 setting a cookie on your Auth0 domain.
+Since cross-origin requests cannot set cookies, this means that SSO sessions must be established by redirecting users to your Auth0 login page (`/authorize`).
+
+The following flows are redirect-based and are capable of SSO:
+
+* [Authorization Code Flow](/flows/concepts/auth-code)
+* [Implicit Flow](/flows/concepts/implicit)
+
+The following flows are request-based and are currently not capable of SSO:
+
+* [Password credentials and realm grants](/api-auth/grant/password)
+
+## Custom domains
+
+When using Universal Login, the login page is by default hosted at an Auth0 domain, so any SSO will be performed at an Auth0 domain instead of your organization's domain.
+
+This is only an aesthetic limitation and does not impact the security or functionality of SSO logins in any way.
+
+## Keep reading
+
+* [Custom Domains](/custom-domains)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
diff --git a/ja-jp/articles/api-auth/tutorials/authorization-code-grant-pkce.md b/ja-jp/articles/api-auth/tutorials/authorization-code-grant-pkce.md
new file mode 100644
index 0000000000..e93cd3913b
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/authorization-code-grant-pkce.md
@@ -0,0 +1,289 @@
+---
+description: How to execute an Authorization Code Grant flow with PKCE for a Mobile Application
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - authorization-code
+  - pkce
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Execute an Authorization Code Grant Flow with PKCE
+
+::: note
+This tutorial will help you implement the Authorization Code (PKCE) grant. If you are looking for some theory on the flow refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
+:::
+
+The __Authorization Code with PKCE__ is the OAuth 2.0 grant that [native apps](/quickstart/native) use in order to access an API. In this document we will work through the steps needed in order to implement this: create a code verifier and a code challenge, get the user's authorization, get a token and access the API using the token.
+
+Before beginning this tutorial, please:
+
+* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately
+* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0
+
+## 1. Create a Code Verifier
+
+First, you need to generate and store a `code_verifier`.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +function base64URLEncode(str) {
+    return str.toString('base64')
+        .replace(/\+/g, '-')
+        .replace(/\//g, '_')
+        .replace(/=/g, '');
+}
+
+var verifier = base64URLEncode(crypto.randomBytes(32));
    
+    
    
+    
    
+      
    +SecureRandom sr = new SecureRandom();
+byte[] code = new byte[32];
+sr.nextBytes(code);
+String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);
    
+    
    
+    
    
+      
    +var buffer = [UInt8](repeating: 0, count: 32)
+_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
+let verifier = Data(bytes: buffer).base64EncodedString()
+    .replacingOccurrences(of: "+", with: "-")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
+    .trimmingCharacters(in: .whitespaces)
    
+    
    
+    
    
+      
    +NSMutableData *data = [NSMutableData dataWithLength:32];
+int result __attribute__((unused)) = SecRandomCopyBytes(kSecRandomDefault, 32, data.mutableBytes);
+NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
+                        stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
+                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
+                             stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];
    
+    
    
+  
    
+
    
+
+## 2. Create a Code Challenge
+
+Using the `code_verifier`, generate a `code_challenge` that will be sent in the authorization request.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +function sha256(buffer) {
+    return crypto.createHash('sha256').update(buffer).digest();
+}
+
+var challenge = base64URLEncode(sha256(verifier));
    
+    
    
+    
    
+      
    +byte[] bytes = verifier.getBytes("US-ASCII");
+MessageDigest md = MessageDigest.getInstance("SHA-256");
+md.update(bytes, 0, bytes.length);
+byte[] digest = md.digest();
+//Use Apache "Commons Codec" dependency. Import the Base64 class
+//import org.apache.commons.codec.binary.Base64;
+String challenge = Base64.encodeBase64URLSafeString(digest);
    
+    
    
+    
    
+      
    + // You need to import CommonCrypto
+guard let data = verifier.data(using: .utf8) else { return nil }
+var buffer = [UInt8](repeating: 0,  count: Int(CC_SHA256_DIGEST_LENGTH))
+data.withUnsafeBytes {
+    _ = CC_SHA256($0, CC_LONG(data.count), &buffer)
+}
+let hash = Data(bytes: buffer)
+let challenge = hash.base64EncodedString()
+    .replacingOccurrences(of: "+", with: "-")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
+    .trimmingCharacters(in: .whitespaces)
    
+    
    
+    
    
+      
    + // You need to import CommonCrypto
+u_int8_t buffer[CC_SHA256_DIGEST_LENGTH * sizeof(u_int8_t)];
+memset(buffer, 0x0, CC_SHA256_DIGEST_LENGTH);
+NSData *data = [verifier dataUsingEncoding:NSUTF8StringEncoding];
+CC_SHA256([data bytes], (CC_LONG)[data length], buffer);
+NSData *hash = [NSData dataWithBytes:buffer length:CC_SHA256_DIGEST_LENGTH];
+NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
+                         stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
+                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
+                       stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];
    
+    
    
+  
    
+
    
+
+## 3. Get the User's Authorization
+
+To begin an Authorization Code Grant flow, your native application should first send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-) including the `code_challenge` and the method used to generate it.
+
+```text
+https://${account.namespace}/authorize?
+    audience=API_AUDIENCE&
+    scope=SCOPE&
+    response_type=code&
+    client_id=${account.clientId}&
+    code_challenge=CODE_CHALLENGE&
+    code_challenge_method=S256&
+    redirect_uri=${account.callback}
+```
+
+Where:
+
+* `audience`: The unique identifier of the API the native app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+
+* `scope`: The scopes that you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)).
+
+* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code`.
+
+* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/Applications/${account.clientId}/settings).
+
+* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/Applications/${account.clientId}/settings).
+
+* `code_challenge`: Generated challenge from the `code_verifier`.
+
+* `code_challenge_method`: Method used to generate the challenge.
+
+::: panel PKCE methods
+The PKCE spec defines two methods, `S256` and `plain`, the former is used in this example and is the **only** one supported by Auth0 since the latter is discouraged.
+:::
+
+For example:
+
+```html
+
+  Sign In
+
+```
+
+## 4. Exchange the Authorization Code for an Access Token
+
+Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (`code`) from the previous step, you will need to `POST` to the [Token URL](/api/authentication#authorization-code-pkce-) sending also the `code_verifier`:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "code_verifier",
+        "value": "YOUR_GENERATED_CODE_VERIFIER"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+Where:
+
+* `grant_type`: This must be `authorization_code`.
+* `client_id`: Your application's Client ID.
+* `code_verifier`: Cryptographically random key that was used to generate the `code_challenge` passed to `/authorize`.
+* `code`: The Authorization Code received from the initial `authorize` call.
+* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`.
+
+The response contains `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example:
+
+```js
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "refresh_token": "GEbRxBN...edjnXbL",
+  "id_token": "eyJ0XAi...4faeEoQ",
+  "token_type": "Bearer"
+}
+```
+
+Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information.
+
+::: warning
+The Authorization Code flow with PKCE can only be used for Applications whose type is `Native` or `Single Page Application` in the Dashboard.
+:::
+
+## 5. Call the API
+
+Once you have the Access Token, you can use it to make calls to the API, by passing it as a Bearer Token in the `Authorization` header of the HTTP request:
+
+```har
+{
+  "method": "GET",
+  "url": "https://someapi.com/api",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" }
+  ]
+}
+```
+
+## 6. Verify the Token
+
+Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Optional: Customize the Tokens
+
+<%= include('../../_includes/_api-auth-customize-tokens') %>
+
+If you wish to execute special logic unique to the Authorization Code (PKCE) grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code (PKCE) grant.
+
+## Sample application
+
+For an example implementation see the [Mobile + API](/architecture-scenarios/application/mobile-api) architecture scenario.
+
+This is a series of tutorials that describe a scenario for a fictitious company. The company wants to implement a mobile app that the employees can use to send their timesheets to the company's Timesheets API using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets).
+
+## Keep reading
+
+- [Tokens](/tokens)
+- [Application Authentication for Mobile & Desktop Apps](/Application-auth/mobile-desktop)
+- [The OAuth 2.0 protocol](/protocols/oauth2)
+- [The OpenID Connect protocol](/protocols/oidc)
diff --git a/ja-jp/articles/api-auth/tutorials/authorization-code-grant.md b/ja-jp/articles/api-auth/tutorials/authorization-code-grant.md
new file mode 100644
index 0000000000..5ecd2127c1
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/authorization-code-grant.md
@@ -0,0 +1,162 @@
+---
+description: How to execute an Authorization Code Grant flow from a Regular Web application
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - authorization-code
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Execute an Authorization Code Grant Flow
+
+::: note
+This tutorial will help you implement the Authorization Code grant. If you are looking for some theory on the flow refer to [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code).
+:::
+
+The __Authorization Code__ is an OAuth 2.0 grant that [regular web apps](/quickstart/webapp) use in order to access an API. In this document we will work through the steps needed in order to implement this: get the user's authorization, get a token and access the API using the token.
+
+Before beginning this tutorial, please:
+
+* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately
+* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0
+
+## 1. Get the User's Authorization
+
+To begin an Authorization Code flow, your web application should first send the user to the [authorization URL](/api/authentication#authorization-code-grant):
+
+```text
+https://${account.namespace}/authorize?
+    audience=YOUR_API_AUDIENCE&
+    scope=YOUR_SCOPE&
+    response_type=code&
+    client_id=${account.clientId}&
+    redirect_uri=${account.callback}&
+    state=YOUR_OPAQUE_VALUE
+```
+
+Where:
+
+* `audience`: The unique identifier of the API the web app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+
+* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)).
+
+* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code`.
+
+* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state).
+
+* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+For example:
+
+```html
+
+  Sign In
+
+```
+
+The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) to do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given.
+
+Note that if you alter the value in `scope`, Auth0 will require consent to be given again.
+
+## 2. Exchange the Authorization Code for an Access Token
+
+Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (`code`) from the previous step, you will need to `POST` to the [Token URL](/api/authentication?http#authorization-code):
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+Where:
+
+* `grant_type`: This must be `authorization_code`.
+* `client_id`: Your application's Client ID.
+* `client_secret`: Your application's Client Secret.
+* `code`: The Authorization Code received from the initial `authorize` call.
+* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`.
+
+The response contains the `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example:
+
+```js
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "refresh_token": "GEbRxBN...edjnXbL",
+  "id_token": "eyJ0XAi...4faeEoQ",
+  "token_type": "Bearer"
+}
+```
+
+Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information.
+
+::: panel-warning Security Warning
+It is important to understand that the Authorization Code flow should only be used in cases such as a Regular Web Application where the Client Secret can be safely stored. In cases such as a Single-Page Application, the Client Secret is available to the application (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the [Authorization Code Flow with PKCE ](/flows/concepts/auth-code-pkce) is more appropriate in that case.
+:::
+
+## 3. Call the API
+
+Once the Access Token has been obtained it can be used to make calls to the API by passing it as a Bearer Token in the `Authorization` header of the HTTP request:
+
+```har
+{
+  "method": "GET",
+  "url": "https://someapi.com/api",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" }
+  ]
+}
+```
+
+## 4. Verify the Token
+
+Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Optional: Customize the Tokens
+
+<%= include('../../_includes/_api-auth-customize-tokens') %>
+
+If you wish to execute special logic unique to the Authorization Code grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-basic-profile`, then the rule is running during the Authorization Code grant.
+
+## Keep Reading
+
+- [Refresh Tokens](/tokens/concepts/refresh-token)
+- [How to configure an API in Auth0](/apis)
+- [Application Authentication for Server-side Web Apps](/application-auth/server-side-web)
+- [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/tutorials/client-credentials.md b/ja-jp/articles/api-auth/tutorials/client-credentials.md
new file mode 100644
index 0000000000..567e903447
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/client-credentials.md
@@ -0,0 +1,113 @@
+---
+description: Learn how to call an API from a server process using OAuth 2.0 and the Client Credentials grant.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - client-credentials
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Implement the Client Credentials Grant
+
+The **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) allows an application to request an Access Token using its __Client Id__ and __Client Secret__. It is used for non interactive applications (a CLI, a daemon, or a Service running on your backend) where the token is issued to the application itself, instead of an end user.
+
+Before beginning this tutorial, please:
+
+* Make sure you that your application has the `Client Credentials` [grant type enabled](/dashboard/guides/applications/update-grant-types). Regular web applications and machine to machine applications have it enabled by default.
+
+* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0 with the required scopes.
+
+* Authorize the application to call the API by creating a Client Grant either [using the Dashboard](/api-auth/config/using-the-auth0-dashboard) or [using the Management API](/api-auth/config/using-the-management-api).
+
+## Ask for a token
+
+To ask Auth0 for tokens for any of your authorized applications, perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint with a payload in the following format:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "client_credentials"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "audience",
+        "value": "YOUR_API_IDENTIFIER"
+      }
+    ]
+  }
+}
+```
+
+Where:
+
+* `grant_type`: This must be `client_credentials`.
+* `client_id`: Your application's Client ID. You can find this value at the [application's settings tab](${manage_url}/#/applications).
+* `client_secret`: Your application's Client Secret. You can find this value at the [application's settings tab](${manage_url}/#/applications).
+* `audience`: The **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+
+The response contains a signed JSON Web Token (JWT), the token's type (which is `Bearer`), and in how much time it expires in [Unix time](https://en.wikipedia.org/wiki/Unix_time) (86400 seconds, which means 24 hours).
+
+```json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+If you [decode the `access_token`](https://jwt.io/#debugger-io) you will see that it contains the following claims:
+
+```json
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "YOUR_MACHINE_TO_MACHINE_APPLICATION_CLIENT_ID@clients",
+  "aud": "YOUR_API_IDENTIFIER",
+  "exp": 1489715431, // unix timestamp of the token's expiration date,
+  "iat": 1489679431, // unix timestamp of the token's creation date,
+  "scope": ""
+}
+```
+
+## Modify scopes and claims
+
+You can change the scopes and add custom claims to the Access Token you got, using [Hooks](/hooks).
+
+Hooks allow you to customize the behavior of Auth0 using Node.js code. They are secure, self-contained functions associated with specific extensibility points of the Auth0 platform (like the Client Credentials grant). Auth0 invokes the Hooks at runtime to execute your custom logic.
+
+For more information and details on how to do that refer to [Using Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks).
+
+## Verify the token
+
+Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens). You can find examples on how to do it in different platforms in the [Quickstarts for backend applications](/quickstart/backend).
+
+## Sample application
+
+For an example implementation see the [Server Client + API](/architecture-scenarios/application/server-api) architecture scenario.
+
+This is a series of tutorials that describe a scenario for a fictitious company that wants to implement a Timesheets API and send timesheets entries from a server process using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets).
+
+## Keep reading
+
+- [Use Hooks with Client Credentials Grant](/api-auth/tutorials/client-credentials/customize-with-hooks)
+- [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md b/ja-jp/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md
new file mode 100644
index 0000000000..e8c5f642f2
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md
@@ -0,0 +1,212 @@
+---
+description: How to use Hooks to change the scopes and add custom claims to the tokens you got using Client Credentials Grant.
+crews: crew-2
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - client-credentials
+  - hooks
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+  - extensibility-hooks
+---
+
+# Use Hooks with Client Credentials Grant
+
+You can now add [Hooks](/hooks) into your [client credentials](/api-auth/grant/client-credentials) flow. This way you can change the scopes and add custom claims to the tokens issued by Auth0.
+
+Hooks allow you to customize the behavior of Auth0 using Node.js code. They are secure, self-contained functions associated with specific extensibility points of the Auth0 platform (like the Client Credentials grant). Auth0 invokes the Hooks at runtime to execute your custom logic.
+
+You can manage Hooks using the Auth0 Dashboard or the Management API. 
+
+## Before you start
+
+Create the following:
+
+- [API defined with the appropriate scopes](${manage_url}/#/apis)
+- [Machine-to-machine application](/applications) authorized to use the API
+
+For details on how to set up the API and the machine-to-machine app, see:
+- Set up a Client Grant:
+  - [Using the Dashboard](/api-auth/config/using-the-auth0-dashboard)
+  - [Using the Management API](/api-auth/config/using-the-management-api)
+- [Execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens)
+
+## Use the Dashboard
+
+1. Go to [the Hooks page of the Dashboard](${manage_url}/#/hooks).
+
+  ![Dashboard Hooks](/media/articles/api-auth/hooks/dashboard-hooks.png)
+
+2. Click the __+ Create New Hook__ button. On the _New Hook_ pop-up window, set the __Hook__ dropdown to `Client Credentials Exchange` and set a __Name__ for your hook. Click __Create__.
+
+  ![New Client Credentials Hook](/media/articles/api-auth/hooks/new-cc-hook.png)
+
+  At this point, you will see your newly-created Hook listed under the _Client Credentials Exchange_.
+
+::: note
+You can create more than one hooks per extensibility point but __only one__ can be enabled. The enabled hook will then be executed for __all__ applications and APIs.
+:::
+
+3. Click the __Pencil and Paper__ icon to the right of the Hook to open the Hook Editor.
+
+  ![Edit Client Credentials Hook](/media/articles/api-auth/hooks/edit-cc-hook.png)
+
+4. Using the Hook Editor, write your Node.js code. As an example, we will add an extra scope. The claim's name will be `https://foo.com/claim` and its value `bar`. Copy the sample code below and paste it in the Editor.
+
+  ```js
+  module.exports = function(client, scope, audience, context, cb) {
+    var access_token = {};
+    access_token['https://foo.com/claim'] = 'bar';
+    access_token.scope = scope;
+    access_token.scope.push('extra');
+    cb(null, access_token);
+  };
+  ```
+
+  This sample hook will:
+  - add an arbitrary claim (`https://foo.com/claim`) to the Access Token
+  - add an `extra` scope to the default scopes configured on your [API](${manage_url}/#/apis).
+
+  ::: panel Custom claims namespaced format
+  In order to improve compatibility for applications, Auth0 now returns profile information in a [structured claim format as defined by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID Tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims.
+  :::
+
+  ![Hook Editor](/media/articles/api-auth/hooks/cc-webtask-editor.png)
+
+  Click __Save__ (or hit Ctrl+S/Cmd+S) and close the Editor.
+
+5. That's it! Now you only need to test your hook. You can find detailed instructions at the [Test your Hook](#test-your-hook) paragraph.
+
+## Test your Hook
+
+To test the hook you just created you need to run a Client Credentials exchange, get the Access Token, decode it and review its contents.
+
+To get a token, make a `POST` request at the `https://${account.namespace}/oauth/token` API endpoint, with a payload in the following format.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "client_credentials"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "audience",
+        "value": "YOUR_API_IDENTIFIER"
+      }
+    ]
+  }
+}
+```
+
+::: note
+If you don't know where to find the Client Id, Client Secret, or API Identifier information, refer to Where to Find the IDs.
+:::
+
+A successful response will include:
+- an `access_token`,
+- its expiration time in seconds (`expires_in`),
+- the token's type set as `Bearer` (`token_type`), and
+- an `extra` scope (`scope`) (this scope was added by your hook)
+
+```text
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5ESTFNa05DTVRGQlJrVTRORVF6UXpFMk1qZEVNVVEzT1VORk5ESTVSVU5GUXpnM1FrRTFNdyJ9.eyJpc3MiOiJodHRwczovL2RlbW8tYWNjb3VudC5hdXRoMC3jb20vIiwic3ViIjoic0FRSlFpQmYxREw0c2lqSVZCb2pFRUZvcmRoa0o4WUNAY2xpZW50cyIsImF1ZCI6ImRlbW8tYWNjb3VudC5hcGkiLCJleHAiOjE0ODc3NjU8NjYsImlhdCI6MTQ4NzY3OTI2Niwic2NvcGUiOiJyZWFkOmRhdGEgZXh0cmEiLCJodHRwczovL2Zvby5jb20vY2xhaW0iOiKoPXIifQ.da-48mHY_7esfLZpvHWWL8sIH1j_2mUYAB49c-B472lCdsNFvpaLoq6OKQyhnqk9_aW_Xhfkusos3FECTrLFvf-qwQK70QtwbkbVye_IuPSTAYdQ2T-XTzGDm9Nmmy5Iwl9rNYLxVs2OoCdfpVMyda0OaI0AfHBgEdKWluTP67OOnV_dF3KpuwtK3dPKWTCo2j9VCa7X1I4h0CNuM79DHhY2wO7sL8WBej7BSNA3N2TUsp_YTWWfrvsr_vVhJf-32G7w_12ms_PNFUwj2C30ZZIPWc-uEkDztyMLdI-lu9q9TLrLdr0dOhfrtfkdeJx4pUSiHdJHf42kg7UAVK6JcA",
+  "expires_in": 86400,
+  "scope": "extra",
+  "token_type": "Bearer"
+}
+```
+
+Copy the Access Token.
+
+The easiest way to decode it and review its contents is to use the [JWT.io Debugger](https://jwt.io/#debugger-io).
+
+Paste your Access Token at the left-hand editor. Automatically the JWT is decoded and its contents are displayed on the right-hand editor.
+
+![Decode Token with JWT.io](/media/articles/api-auth/hooks/cc-decode-token.png)
+
+Look into the last two items of the __Payload__. Both have been set by our hook:
+- `"scope": "extra"`
+- `"https://foo.com/claim": "bar"`
+
+## Manage your Hooks
+
+You can disable, enable, delete or edit hooks using either the Auth0 CLI or the [dashboard](${manage_url}/#/hooks). You can also review your logs using the Auth0 CLI. For details, refer to the articles below.
+
+Use the Dashboard to:
+- [Delete Hooks](/auth0-hooks/dashboard/create-delete)
+- [Edit Hooks](/auth0-hooks/dashboard/edit)
+- [Enable or disable Hooks](/auth0-hooks/dashboard/enable-disable)
+
+Use the Auth0 CLI to:
+- [Delete Hooks](/auth0-hooks/cli/create-delete)
+- [Edit Hooks](/auth0-hooks/cli/edit)
+- [Enable or disable Hooks](/auth0-hooks/cli/enable-disable)
+- [Review Logs](/auth0-hooks/cli/logs)
+
+## Input Parameters
+
+The hook takes five input parameters. You can use these values for your custom logic.
+
+Let's see what each one contains.
+
+- __client__ (object): Information on the application asking for the token, including the `client` metadata (a key-value pair that can be set by application). Sample snippet:
+
+    ```json
+    {
+      "tenant":  "tenant_name",
+      "id": "tenant_id",
+      "name": "test_client",
+      "metadata": {
+        "some_metadata": "value"
+      }
+    }
+    ```
+
+- __scope__ (`string array`): The scopes available on the API that you have defined.
+
+- __audience__ (`string`): The API identifier available via the API settings page.
+
+- __context__ (`object`): The contextual information about the request. Sample snippet:
+
+    ```json
+    {
+      "ip": "123.123.123.123",
+      "userAgent": "...",
+      "webtask": {
+        "secrets": { "FOO": "bar" }
+      }
+    }
+    ```
+
+- __cb__: The callback. In our example we returned the token (`cb(null, access_token)`). If you decide, however, not to issue a token, you can return `Error (cb(new Error('access denied')))`.
+
+## Keep reading
+
+* [What are Hooks and how you can work with them](/hooks)
+* [Overview of the Client Credentials Grant](/api-auth/grant/client-credentials)
+* [How to set up a Client Grant using the Dashboard](/api-auth/config/using-the-auth0-dashboard)
+* [How to set up a Client Grant using the Management API](/api-auth/config/using-the-management-api)
+* [How to execute a Client Credentials Grant](/api-auth/config/asking-for-access-tokens)
diff --git a/ja-jp/articles/api-auth/tutorials/hybrid-flow.md b/ja-jp/articles/api-auth/tutorials/hybrid-flow.md
new file mode 100644
index 0000000000..c00ef7443e
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/hybrid-flow.md
@@ -0,0 +1,208 @@
+---
+description: Learn how to execute the Hybrid Flow so your app can use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token. 
+toc: true
+public: false
+topics:
+  - api-authentication
+  - oidc
+  - hybrid
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Implement the Hybrid Flow
+
+The [Hybrid Flow](/api-auth/grant/hybrid) is an OpenID Connect (OIDC) grant that enables use cases where your application can immediately use an ID token to access information about the user while obtaining an authorization code that can be exchanged for an Access Token (therefore gaining access to protected resources for an extended period of time).
+
+In this article, we will show you how you can use the Hybrid Flow in Auth0.
+
+## Prerequisites
+
+Before you begin this tutorial, please:
+
+* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately
+* [Register your API](/apis#how-to-configure-an-api-in-auth0) with Auth0
+
+## 1. Get the User's Authorization
+
+The first step is to get the user's consent for authentication (and possibly authorization). You can initiate the flow by sending the user to the [authorization URL](/api/authentication#authorization-code-grant)
+
+```text
+https://${account.namespace}/authorize?
+    audience=YOUR_API_AUDIENCE&
+    scope=YOUR_SCOPE&
+    response_type=YOUR_RESPONSE_TYPE&
+    client_id=${account.clientId}&
+    redirect_uri=${account.callback}&
+    state=YOUR_OPAQUE_VALUE
+    nonce=NONCE
+```
+
+Where:
+
+* `audience`: The unique identifier of the API the web app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+
+* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token (make sure that the __Allow Offline Access__ field is enabled in the [API Settings](${manage_url}/#/apis)).
+
+* `response_type`: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be `code id_token`, `code token`, or `code id_token token`. More specifically, `token` returns an Access Token, `id_token` returns an ID Token, and `code` returns the Authorization Code.
+
+* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state).
+
+* `redirect_uri`: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the `code` URL parameter. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+  ::: warning
+  Per the [OAuth 2.0 Specification](https://tools.ietf.org/html/rfc6749#section-3.1.2), Auth0 removes everything after the hash and does *not* honor any fragments.
+  :::
+
+* `nonce`: A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`.
+
+For example:
+
+```html
+
+  Sign In
+
+```
+
+The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) to do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given.
+
+Note that if you alter the value in `scope`, Auth0 will require consent to be given again.
+
+## 2. Parsing the Response
+
+If your call to the `/authorize` endpoint is successful, Auth0 redirects you to a URL similar to the following:
+
+```text
+https://YOUR_REDIRECT_URI
+  /#access_token=ey...MhPw
+  &expires_in=7200
+  &token_type=Bearer
+  &code=AUTHORIZATION_CODE
+  &id_token=ey...qk
+```
+
+The URL contains the following components:
+
+* The redirect URI you provided for this application
+* The Authorization Code provided by Auth0
+* The ID Token
+* The Access Token
+
+If you've returned an Access Token, you'll also receive `expires_in` and `token_type` values.
+
+More specifically, here's what you will get back (depending on the value provided in `response_type`):
+
+| Response Type | Components |
+| - | - |
+| code id_token | Authorization Code, ID Token |
+| code token | Authorization Code, Access Token |
+| code id_token token | Authorization Code, ID Token, Access Token |
+
+### Access Tokens
+
+There are two ways to get Access Tokens in the Hybrid Flow.
+
+First, all calls include the `code` value in the `response_type` parameter (e.g., `code id_token`, `code token`, or `code id_token token`). As such, you'll receive an Authorization Code from Auth0 that you can then exchange for an Access Token.
+
+Second, you can explicitly request an Access Token directly by setting the `response_type` parameter to `code token` or `code id_token token`.
+
+You can therefore receive two Access Tokens for a given transaction. However, it is important to keep the two separate -- we do not recommend that an Access Token obtained when `response_type=code token` or `code token` or `code id_token token` be used to call APIs.
+
+## 3. Exchange the Authorization Code for an Access Token
+
+You can exchange the Authorization Code for an Access Token that will allow you to call the API specified in your initial authorization call. 
+
+Using the Authorization Code (`code`) from the first step, you will need to `POST` to the [Token URL](/api/authentication?http#authorization-code):
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+Where:
+
+* `grant_type`: This must be `authorization_code`.
+* `client_id`: Your application's Client ID.
+* `client_secret`: Your application's Client Secret.
+* `code`: The Authorization Code received from the initial `authorize` call.
+* `redirect_uri`: The URL must match exactly the `redirect_uri` passed to `/authorize`.
+
+The response contains the `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example:
+
+```js
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "refresh_token": "GEbRxBN...edjnXbL",
+  "id_token": "eyJ0XAi...4faeEoQ",
+  "token_type": "Bearer"
+}
+```
+
+Note that `refresh_token` will only be present in the response if you included the `offline_access` scope AND enabled __Allow Offline Access__ for your API in the Dashboard. See [Refresh Tokens](/tokens/concepts/refresh-tokens) for more information.
+
+::: panel-warning Security Warning
+It is important to understand that the Authorization Code flow should only be used in cases such as a Regular Web Application where the Client Secret can be safely stored. In cases such as a Single-Page Application, the Client Secret is available to the application (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the [Implicit Flow](/flows/concepts/implicit) is more appropriate in that case.
+:::
+
+## 4. Call the API
+
+Once the Access Token has been obtained it can be used to make calls to the API by passing it as a Bearer Token in the `Authorization` header of the HTTP request:
+
+```har
+{
+  "method": "GET",
+  "url": "https://someapi.com/api",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" }
+  ]
+}
+```
+
+## 5. Verify the Token
+
+Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Keep reading
+
+- [Tokens](/tokens)
+- [Refresh Tokens](/tokens/concepts/refresh-token)
+- [Configure an API in Auth0](/apis)
+- [Authorization Code Flow](/flows/concepts/auth-code)
+- [Implicit Flow](/flows/concepts/implicit)
+
diff --git a/ja-jp/articles/api-auth/tutorials/implicit-grant.md b/ja-jp/articles/api-auth/tutorials/implicit-grant.md
new file mode 100644
index 0000000000..07c8ccc2c5
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/implicit-grant.md
@@ -0,0 +1,154 @@
+---
+description: Learn how to execute an Implicit Grant flow from a SPA Client application.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - implicit
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Implement the Implicit Grant
+
+::: note
+This tutorial will help you implement the Implicit Grant. If you are looking for some theory on the flow refer to [Call APIs from Client-side Web Apps](/api-auth/grant/implicit).
+:::
+
+The __Implicit Grant__ is an OAuth 2.0 flow that [client-side apps](/quickstart/spa) use in order to access an API. In this document we will work through the steps needed in order to implement this: get the user's authorization, get a token and access an API using the token.
+
+Before you begin this tutorial, do the following:
+
+* Check that your Application's [Grant Type property](/applications/concepts/application-grant-types) is set appropriately
+* [Register your API](/apis#how-to-configure-an-api-in-auth0) with Auth0
+
+## 1. Get the User's Authorization
+
+First, your app should get consent from the user to invoke the API on their behalf. Auth0 will authenticate the user and obtain consent, unless consent has been previously given.
+
+To initiate the flow, send the user to the [authorization URL](/api/authentication#implicit):
+
+```text
+https://${account.namespace}/authorize?
+  audience=YOUR_API_AUDIENCE&
+  scope=YOUR_SCOPE&
+  response_type=YOUR_RESPONSE_TYPE&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  nonce=YOUR_CRYPTOGRAPHIC_NONCE&
+  state=YOUR_OPAQUE_VALUE
+```
+
+Where:
+
+* `audience`: The unique identifier of the API the app wants to access. Use the **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+
+* `scope`: The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Note that user's consent will be requested, every time the `scope` value changes.
+
+* `response_type`: Indicates the type of credentials returned in the response. For this flow you can either use `token` to get only an Access Token, `id_token` to get only an ID Token (if you don't plan on accessing an API), or `id_token token` to get both an ID Token and an Access Token.
+
+* `client_id`: Your application's Client ID. You can find this value at your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+* `redirect_uri`: The URL to which the Auth0 will redirect the user's browser after authorization has been granted by the user. The Access Token (and optionally an ID Token) will be available in the hash fragment of this URL. This URL must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+  ::: warning
+  Per the [OAuth 2.0 Specification](https://tools.ietf.org/html/rfc6749#section-3.1.2), Auth0 removes everything after the hash and does *not* honor any fragments.
+  :::
+
+* `state`: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see [State Parameter](/protocols/oauth-state).
+
+* `nonce`: A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`.
+
+For example:
+
+```html
+
+  Sign In
+
+```
+
+## 2. Extract the Access Token
+
+After Auth0 has redirected back to the app, the hash fragment of the URL contains the following parameters:
+- `id_token`: contains an [ID Token](/tokens/concepts/id-tokens) and is present if the request parameter `response_type` included the value `id_token`, or the `scope` request parameter the value `openid`
+- `access_token`: contains an [Access Token](/tokens/concepts/access-tokens) and is present if the request parameter `response_type` included the value `token`
+- `token_type`: denotes the type of the [Access Token](/tokens/concepts/access-tokens)
+- `expires_in`: the lifetime in seconds of the Access Token. For example, the value `3600` denotes that the [Access Token](/tokens/concepts/access-tokens) will expire in one hour from the time the response was generated
+- `state`: present in the response if the `state` parameter was present in the request. Holds the exact value received from the client in the request.
+
+You can extract the `access_token`, and other parameters, from the hash fragment of the URL:
+
+```js
+function getParameterByName(name) {
+  var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash);
+  return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
+}
+
+function getAccessToken() {
+  return getParameterByName('access_token');
+}
+
+function getIdToken() {
+  return getParameterByName('id_token');
+}
+
+$(function () {
+  var access_token = getAccessToken();
+
+  // Optional: an ID Token will be returned by Auth0
+  // if your response_type argument contained id_token
+  var id_token = getIdToken();
+
+  // Use the Access Token to make API calls
+  // ...
+});
+```
+
+## 3. Call the API
+
+Once you have the `access_token` you can use it to make calls to the API, by passing it as a Bearer Token in the `Authorization` header of the HTTP request:
+
+``` js
+// Use the Access Token to make API calls
+$('#get-appointments').click(function(e) {
+  e.preventDefault();
+
+  $.ajax({
+    cache: false,
+    url: "http://localhost:7001/api/appointments",
+    headers: { "Authorization": "Bearer " + access_token }
+  });
+});
+```
+
+## 4. Verify the Token
+
+Once your API receives a request with a Bearer `access_token`, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Optional: Customize the Tokens
+
+<%= include('../../_includes/_api-auth-customize-tokens') %>
+
+If you wish to execute special logic unique to the Implicit grant, you can look at the `context.protocol` property in your rule. If the value is `oidc-implicit-profile`, then the rule is running during the Implicit grant.
+
+## Optional: Silent Authentication
+
+If you need to authenticate your users without a login page (for example, when the user is already logged in via [Single Sign-on (SSO)](/sso) scenario) or get a new `access_token` (thus simulate refreshing an expired token), you can use Silent Authentication.
+
+For details on how to implement this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication).
+
+## Sample application
+
+For an example implementation see the [SPA + API](/architecture-scenarios/application/spa-api) architecture scenario.
+
+This is a series of tutorials that describe a scenario for a fictitious company. The company wants to implement a single-page web app that the employees can use to send their timesheets to the company's Timesheets API using OAuth 2.0. The tutorials are accompanied by a sample that you can access in [GitHub](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets).
+
+## Keep reading
+
+- [How to protect your SPA against replay attacks](/api-auth/tutorials/nonce)
+- [How to configure an API in Auth0](/apis)
+- [Application Authentication for Client-side Web Apps](/application-auth/client-side-web)
+- [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/tutorials/nonce.md b/ja-jp/articles/api-auth/tutorials/nonce.md
new file mode 100644
index 0000000000..c83e542ae8
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/nonce.md
@@ -0,0 +1,79 @@
+---
+description: How to securely generate and validate a cryptographic nonce for use with the Implicit Grant.
+topics:
+  - api-authentication
+  - oidc
+  - implicit
+  - nonce
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Mitigate Replay Attacks When Using the Implicit Flow
+
+To mitigate replay attacks when using the [Implicit Flow](/flows/concepts/implicit), a nonce must be sent on authentication requests [as required by the OpenID Connect (OIDC) specification](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest).
+
+The nonce is generated by the application, sent as a `nonce` query string parameter in the authentication request, and included in the ID Token response from Auth0. This allows applications to correlate the ID Token response from Auth0 with the initial authentication request.
+
+For more information on where to include the nonce, see [Call API Using the Implicit Flow](/flows/guides/implicit/call-api-implicit).
+
+::: note
+[Auth0.js](/libraries/auth0js) manages `state` and `nonce` parameters for you when using cross-origin authentication.
+:::
+
+## Generate a cryptographically random nonce
+
+One way to generate a cryptographically random nonce is to use a tool like [Nano ID](https://github.com/ai/nanoid) or similar. This does require you to bundle the tool with your JavaScript code, however. If that's not possible, you can take advantage of the fact that [modern browsers](http://caniuse.com/#feat=cryptography) can use the [Web Crypto API](https://www.w3.org/TR/WebCryptoAPI/) to generate cryptographically secure random strings for use as nonces.
+
+```js
+function randomString(length) {
+    var charset = '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZabcdefghijklmnopqrstuvwxyz-._'
+    result = ''
+
+    while (length > 0) {
+        var bytes = new Uint8Array(16);
+        var random = window.crypto.getRandomValues(bytes);
+
+        random.forEach(function(c) {
+            if (length == 0) {
+                return;
+            }
+            if (c < charset.length) {
+                result += charset[c];
+                length--;
+            }
+        });
+    }
+    return result;
+}
+```
+
+## Persist nonces across requests
+
+The generated nonce must be persisted in your web application using any of the following methods:
+
+* `HttpOnly` session cookie
+* HTML5 local storage value
+
+For example:
+
+```js
+window.localStorage.setItem('nonce', randomString(16));
+```
+
+## Validate the ID Token
+
+Once Auth0 responds with an ID Token, this token must be validated and decoded as usual.
+Its `nonce` claim must contain the exact same value that was sent in the request.
+If not, authentication should be rejected by the application.
+
+```js
+var jwt = '...'; // validated and decoded ID Token body
+if (jwt.nonce === window.localStorage.getItem('nonce')) {
+    // Nonce is OK
+} else {
+    // Nonce is not OK! Token replay attack might be underway
+}
+```
diff --git a/ja-jp/articles/api-auth/tutorials/password-grant.md b/ja-jp/articles/api-auth/tutorials/password-grant.md
new file mode 100644
index 0000000000..f8ef39ba44
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/password-grant.md
@@ -0,0 +1,219 @@
+---
+description: Learn how to implement the OAuth 2.0 Resource Owner Password Grant
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - resource-owner-password
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Implement the Resource Owner Password Grant
+
+<%= include('../_includes/_ropg-warning') %>
+
+In this tutorial, we will go through the steps required to implement the Resource Owner Password Grant flow.
+
+## Before you start
+
+* Check that your application's grant type is set to "Password". To set an application's grant type:
+  1. Go to the [Dashboard](${manage_url}) and select **Applications**
+  2. Choose your application from the list
+  3. On the **Settings** page scroll down to **Advanced Settings**
+  4. Select the **Grant Types** tab
+  5. Enable the "Password" grant
+* [Register the API](/apis#how-to-configure-an-api-in-auth0) with Auth0.
+* Update or disable any [rules](/rules) so they only impact specific connections. If you get an `'access_denied'` error when testing the Password Grant, this could be due to an access control rule.
+
+## Configure your tenant
+
+The Password Grant relies on a connection capable of authenticating users via username and password. In order to indicate which connection the Password Grant should use you need to set the value of the `default_directory` tenant setting.
+
+1. Open the [Dashboard](${manage_url}) and browse to your [Tenant Settings](${manage_url}/#/tenant).
+1. Scroll down to the __Settings__ section and locate the __Default Directory__ setting.
+1. Enter the name of the connection you would like to use. Keep in mind that only connections capable of authenticating users via username and password can be used (such as database connections, AD, LDAP, Windows Azure AD, ADFS)
+
+![Update Default Directory](/media/articles/api-auth/default-directory-setting.png)
+
+## Ask for a Token
+
+In order to execute the flow the application needs to acquire the Resource Owner's credentials, usually this will be through the use of an interactive form. Once the application has the credentials it needs to forward them to Auth0 with a `POST` to the [/oauth/token endpoint of Auth0's Authentication API](/api/authentication#resource-owner-password).
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+        {
+          "name": "grant_type",
+          "value": "password"
+        },
+        {
+          "name": "username",
+          "value": "user@example.com"
+        },
+        {
+          "name": "password",
+          "value": "pwd"
+        },
+        {
+          "name": "audience",
+          "value": "YOUR_API_IDENTIFIER"
+        },
+        {
+          "name": "scope",
+          "value": "read:sample"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        }
+    ]
+  }
+}
+```
+
+Where:
+
+* `grant_type`: This must be `password`.
+* `username`: The end user's identifier.
+* `password`: The end user's password.
+* `audience`: The **Identifier** value on the [Settings](${manage_url}/#/apis) tab for the API you created as part of the prerequisites for this tutorial.
+* `client_id`: Your application's Client ID. You can find this value at the [Settings tab of the Machine to Machine Application](${manage_url}/#/applications).
+* `client_secret`: Your application's Client Secret. You can find this value at the [Settings tab of the Machine to Machine Application](${manage_url}/#/applications). This is required when the **Token Endpoint Authentication Method** field at your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) is `Post` or `Basic`. Do not set this parameter if your application is not highly trusted (for example, SPA).
+* `scope`: String value of the different scopes the application is asking for. Multiple scopes are separated with whitespace.
+
+The response contains a signed JSON Web Token (JWT), the token's type (which is `Bearer`), and in how much time it expires in [Unix time](https://en.wikipedia.org/wiki/Unix_time).
+
+```js
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "token_type": "Bearer",
+  "expires_in": 36000
+}
+```
+
+In case the scopes issued to the application differ from the scopes requested, a `scope` parameter will be included in the response JSON, listing the issued scopes.
+
+::: panel Password grant and standard scopes
+If **no** API scopes (such as `read:notes`) are included in the request, all API scopes (such as `read:notes`, `create:notes`, and so on.) are included in the Access Token.
+If only the `openid` scope is included in the request, all `openid` standard scopes will be returned, such as `openid profile email address phone`.
+In these cases, the `scope` parameter will be included in the response, listing the issued scopes. This happens because a password is equal to full access and hence any password-based exchange gives access to all scopes.
+:::
+
+::: panel How to get the user's claims
+If you need the user's claims you can include the scope `openid` to your request. If the API uses `RS256` as the [signing algorithm](/tokens/concepts/signing-algorithms), the Access Token will now also include `/userinfo` as a valid audience. You can use this Access Token to invoke the [/userinfo endpoint](/api/authentication#get-user-info) and retrieve the user's claims.
+:::
+
+### Realm support
+
+An extension grant that offers similar functionality to ROPG, including the ability to indicate a specific realm, is the `http://auth0.com/oauth/grant-type/password-realm`.
+
+Realms allow you to keep separate user directories and specify which one to use to the token endpoint.
+
+To use this variation you will have to change the following request parameters:
+* Set the `grant_type` to `http://auth0.com/oauth/grant-type/password-realm`.
+* Set the new request parameter `realm` to the realm the user belongs. This maps to a connection in Auth0. For example, if you have configured a database connection for your internal employees and you have named the connection `employees`, then use this value.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+        {
+          "name": "grant_type",
+          "value": "http://auth0.com/oauth/grant-type/password-realm"
+        },
+        {
+          "name": "username",
+          "value": "user@example.com"
+        },
+        {
+          "name": "password",
+          "value": "pwd"
+        },
+        {
+          "name": "audience",
+          "value": "YOUR_API_IDENTIFIER"
+        },
+        {
+          "name": "scope",
+          "value": "read:sample"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        },
+        {
+          "name": "realm",
+          "value": "employees"
+        }
+    ]
+  }
+}
+```
+
+::: panel Auth0 Connections as Realms
+You can configure Auth0 Connections as realms, as long as they support active authentication. This includes [Database](/connections/database), [Passwordless](/connections/passwordless), [Active Directory/LDAP](/connections/enterprise/active-directory-ldap), [Windows Azure AD](/connections/enterprise/azure-active-directory) and [ADFS](/connections/enterprise/adfs) connections.
+:::
+
+## Use the token
+
+Once the Access Token has been obtained it can be used to make calls to the Resource Server by passing it as a Bearer Token in the `Authorization` header of the HTTP request:
+
+```har
+{
+  "method": "GET",
+  "url": "https://someapi.com/api",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer {ACCESS_TOKEN}" }
+  ]
+}
+```
+
+## Verify the token
+
+Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request _must_ be rejected.
+
+For details on the validations that should be performed by the API, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Optional: Customize the Tokens
+
+<%= include('../../_includes/_api-auth-customize-tokens') %>
+
+If you wish to execute special logic unique to the Password exchange, you can look at the `context.protocol` property in your rule. If the value is `oauth2-password`, then the rule is running during the password exchange.
+
+## Optional: Configure MFA
+
+In case you need stronger authentication, than username and password, you can configure multi-factor authentication (MFA) using the Resource Owner Password Grant. For details on how to implement this refer to [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password).
+
+## Optional: Configure Anomaly Detection
+
+When using this flow from server-side applications, some anomaly detection features might fail because of the particularities of this scenario. For details on how to implement this, while avoiding some common issues, refer to [Using Resource Owner Password from Server side](/api-auth/tutorials/using-resource-owner-password-from-server-side).
+
+## Keep reading
+
+* [Call APIs from Highly Trusted Applications](/api-auth/grant/password)
+* [How to configure an API in Auth0](/apis)
+* [Tokens](/tokens)
diff --git a/ja-jp/articles/api-auth/tutorials/represent-multiple-apis.md b/ja-jp/articles/api-auth/tutorials/represent-multiple-apis.md
new file mode 100644
index 0000000000..5eaf10b709
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/represent-multiple-apis.md
@@ -0,0 +1,169 @@
+---
+
+description: Learn how to use a single logical API in Auth0 to represent and control access to multiple APIs.
+topics:
+  - api-authentication
+  - oidc
+  - apis
+  - scopes
+  - permissions
+contentType: how-to
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Represent Multiple APIs Using a Single Logical API
+
+If you have multiple distinct API implementations that are all logically a part of the same API, you can simplify your authorization process by representing them with a single logical [API](/apis) in the Auth0 Dashboard. Doing this allows you to implement just one authorization flow, while still controlling access to the individual APIs by assigning the appropriate scopes.
+
+This tutorial explains how to use and represent multiple APIs as a single Resource Server in Auth0. As a learning tool, we provide a sample application that you can follow along with as you read.
+
+## The Sample Application
+
+The sample application uses a microservices architecture and contains:
+
+* 1 Single-Page Application (SPA)
+* 2 APIs (services), called `contacts` and `calendar`
+
+We will represent the two APIs using just one Auth0 API called `Organizer Service`. We will then create two scopes to demonstrate how you can use the [Implicit Flow](/flows/concepts/implicit) to access the `calendar` and `contacts` APIs from the SPA.
+
+## Prerequisites
+
+Before beginning this tutorial:
+
+* [Register your Application with Auth0](/dashboard/guides/applications/register-app-spa)
+  * Select an **Application Type** of **Single-Page App**.
+  * Add **Allowed Callback URLs** of `http://localhost:3000` and `http://localhost:3000/callback.html`.
+* [Download the sample application](https://github.com/auth0-samples/auth0-api-auth-implicit-sample), so you can follow along as you read. Please see the `README` for additional information on setting up the sample on your local environment.
+
+## Steps
+
+1. [Enable a Connection for your Application](#enable-a-connection-for-your-application): Configure a source of users for your new application.
+2. [Create a test user](#create-a-test-user): Associate a test user with your new connection.
+3. [Register a logical API in Auth0](#register-a-logical-api-in-auth0): Register a single logical API to represent your multiple APIs.
+4. [Configure scopes for the logical API](#configure-scopes-for-the-logical-API): Create the scopes that will allow the logical API to represent your multiple APIs.
+5. [Grant access to the logical API](#grant-access-to-the-logical-api): Configure the login link in your sample application, initiate the authorization flow, and extract the Access Token to be used to call your multiple APIs.
+Optional: [Implement Single Logout (SLO) or Single Sign-on (SSO)](#implement-single-log-out-slo-or-single-sign-on-sso)
+
+## Enable a connection for your Application
+
+You will need a source of users for your newly-registered application, so you will need to configure a [Connection](/identityproviders). For the purpose of this sample, we'll create a simple [Database Connection](/connections/database) that asks only for the user's email address and a password.
+
+1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [Connections > Database](${manage_url}/#/connections/database) in the left-hand nav. Click **Create DB Connection**.
+2. The **Create DB Connection** window will open. Provide a **Name** for your Connection, and click **Create** to proceed.
+3. Click the **Applications** tab, and enable the Connection.
+
+## Create a test user
+
+Since you're working with a newly-created Connection, there won't be any users associated with it. Before we can test the sample application's login process, we'll need to create and associate a user with the Connection.
+
+1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [Users](${manage_url}/#/users) in the left-hand nav. Click **Create User**.
+2. Provide the requested information about the new user (**email address** and **password**), and select your newly-created **Connection**.
+3. Click **Save**.
+
+## Register a logical API in Auth0
+
+Register a single logical [API](/apis) that you will use to represent the multiple APIs contained within the sample application.
+
+1. Navigate to the [Auth0 Dashboard](${manage_url}), and click on [APIs](${manage_url}/#/apis) in the left-hand nav. Click **Create API**.
+
+![](/media/articles/api-auth/tutorials/represent-multiple-apis/dashboard-apis.png)
+
+2. When prompted, provide a **name** and **identifier** for the new API, and choose the **signing algorithm** for the tokens obtained for this API.
+
+For the purpose of this sample, we'll call our API `Organizer Service` and set its unique identifier to `organize`. By default, the [signing algorithm](/tokens/concepts/signing-algorithms) for the tokens obtained for this API is **RS256**, which we will leave as is.
+
+When finished, click **Create**.
+
+![](/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png)
+
+## Configure scopes for the logical API
+
+To allow the logical API to represent the APIs included within the sample application, you will need to create the proper scopes.
+
+Scopes allow you to define which API actions will be accessible to calling applications. One scope will represent one API/action combination. 
+
+For example, if you want calling applications to be able to `read` and/or `delete` from one API called `samples` and another one called `examples`, you would need to create the following permissions:
+
+* `read:samples`
+* `delete:samples`
+* `read:examples`
+* `delete:examples`
+
+You can think of each one as a microservice.
+
+1. In your newly-created logical API, click the **Scopes** (or **Permissions**) tab. 
+
+![](/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png)
+
+2. Add two scopes:
+
+* `read:calendar`
+* `read:contacts`
+
+**Save** your changes.
+
+![](/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png)
+
+## Grant access to the logical API
+
+You are now ready to provide access to your APIs by allowing the logical API to obtain Access Tokens. By including the necessary scopes, you can control an application's access to the APIs represented by the logical API.
+
+:::panel Authorization Flows
+
+The rest of this article covers use of the [Implicit Flow](/flows/concepts/implicit) to reflect the sample. However, you can use whichever flow best suits your needs. For example:
+
+* If you have a **Machine-to-Machine Application**, you can authorize it to request Access Tokens for your API by executing a [Client Credentials Flow](/flows/concepts/client-credentials).
+* If you are building a **Native App**, you can implement the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
+
+For a full list of available Authorization flows, see [API Authorization](/api-auth).
+:::
+
+1. The user clicks Login within the SPA, and the app redirects the user to the Auth0 Authorization Server (`/authorize` endpoint).
+
+```text
+https://YOUR_AUTH0_DOMAIN/authorize?
+scope=read:contacts%20read:calendar&
+audience=organize&
+response_type=id_token%20token&
+client_id=YOUR_CLIENT_ID&
+redirect_uri=http://localhost:3000&
+nonce=NONCE
+```
+
+::: note
+For additional information on the call's parameters, refer to our tutorial, [Call Your API Using the Implicit Flow](/flows/guides/implicit/call-api-implicit#authorize-the-user).
+:::
+
+![SPA Home before Login](/media/articles/api-auth/tutorials/represent-multiple-apis/home.png)
+
+2. Your Auth0 Authorization Server redirects the user to the login page, where the user authenticates using one of the configured login options.
+
+![SPA Login](/media/articles/api-auth/tutorials/represent-multiple-apis/lock.png)
+
+3. If this is the first time the user has been through this flow, they see a consent prompt listing the permissions Auth0 will give to the SPA. In this case, the user is asked to consent to the app reading their contacts and calendar.
+
+![Consent Screen](/media/articles/api-auth/tutorials/represent-multiple-apis/consent-screen.png)
+
+4. If the user consents, Auth0 redirects the user back to the SPA with tokens in the hash fragment of the URI. The SPA can now extract the tokens from the hash fragment using JavaScript and use the Access Token to call your APIs on behalf of the user.
+
+```js
+function getParameterByName(name) {
+  var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash);
+  return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
+}
+
+function getAccessToken() {
+  return getParameterByName('access_token');
+}
+```
+
+In our sample, after you successfully log in, you will see buttons that allow you to call either of your APIs using the Access Token obtained from the logical API.
+
+![SPA Home after Login](/media/articles/api-auth/tutorials/represent-multiple-apis/apis.png)
+
+
+## Implement Single Logout (SLO) or Single Sign-on (SSO)
+
+<%= include('../../_includes/_checksession_polling') %>
diff --git a/ja-jp/articles/api-auth/tutorials/silent-authentication.md b/ja-jp/articles/api-auth/tutorials/silent-authentication.md
new file mode 100644
index 0000000000..cb23a93b46
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/silent-authentication.md
@@ -0,0 +1,143 @@
+---
+description: Learn how to keep users logged in to your application using silent authentication.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - silent-authentication
+contentType: how-to
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Configure Silent Authentication
+
+The OpenID Connect protocol supports a `prompt=none` parameter on the authentication request that allows applications to indicate that the authorization server must not display any user interaction (such as authentication, consent or MFA). Auth0 will either return the requested response back to the application or return an error if the user is not already authenticated, or that some type of consent or prompt is required before proceeding.
+
+Use of the [Implicit Flow](/flows/concepts/implicit) in SPAs presents security challenges requiring explicit mitigation strategies. You can use the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) in conjunction with Silent Authentication to renew sessions in SPAs.
+
+<%= include('../../_includes/_refresh_token_rotation_recommended.md') %>
+
+## Initiate Silent Authentication requests
+
+To initiate a silent authentication request, add the `prompt=none` parameter when you redirect a user to the [`/authorize` endpoint of Auth0's authentication API](/api/authentication#authorize-application). (The individual parameters on the authentication request will vary depending on the specific needs of your app.
+)
+
+For example:
+
+```text
+GET https://${account.namespace}/authorize
+    ?response_type=id_token token&
+    client_id=...&
+    redirect_uri=...&
+    state=...&
+    scope=openid...&
+    nonce=...&
+    audience=...&
+    response_mode=...&
+    prompt=none
+```
+
+The `prompt=none` parameter causes Auth0 to immediately send a result to the specified `redirect_uri` (callback URL) using the specified `response_mode` with one of two possible responses: success or error. 
+
+::: note
+Any applicable [rules](/rules) will be executed as part of the silent authentication process.
+:::
+
+### Successful authentication responses
+
+If the user was already logged in to Auth0 and no other interactive prompts are required, Auth0 will respond exactly as if the user had authenticated manually through the login page.
+
+For example, when using the Implicit Flow, (`response_type=id_token token`, used for single-page applications), Auth0 will respond with the requested tokens:
+
+```text
+GET ${account.callback}
+    #id_token=...&
+    access_token=...&
+    state=...&
+    expires_in=...
+```
+
+This response is indistinguishable from a login performed directly without the `prompt=none` parameter.
+
+### Error responses
+
+If the user was not logged in via Single Sign-on (SSO) or their SSO session had expired, Auth0 will redirect to the specified `redirect_uri` (callback URL) with an error:
+
+```
+GET https://your_callback_url/
+    #error=ERROR_CODE&
+    error_description=ERROR_DESCRIPTION&
+    state=...
+```
+
+The possible values for `ERROR_CODE` are defined by the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthError):
+
+| Response | Description |
+| -- | -- |
+| `login_required` | The user was not logged in at Auth0, so silent authentication is not possible. This error can occur based on the way the tenant-level **Log In Session Management** settings are configured; specifically, it can occur after the time period set in the **Require log in after** setting. See [Configure Session Lifetime Settings](/dashboard/guides/tenants/configure-session-lifetime-settings) for details. |
+| `consent_required` | The user was logged in at Auth0, but needs to give consent to authorize the application. |
+| `interaction_required` | The user was logged in at Auth0 and has authorized the application, but needs to be redirected elsewhere before authentication can be completed; for example, when using a [redirect rule](/rules/redirect). |
+
+If any of these errors are returned, the user must be redirected to the Auth0 login page without the `prompt=none` parameter to authenticate.
+
+## Renew expired tokens
+
+You can make a silent authentication request to get new tokens as long as the user still has a valid session at Auth0. The [`checkSession` method from auth0.js](/libraries/auth0js#using-checksession-to-acquire-new-tokens) uses a silent token request in combination with `response_mode=web_message` for SPAs so that the request happens in a hidden iframe. With SPAs, Auth0.js handles the result processing (either the token or the error code) and passes the information through a callback function provided by the application. This results in no UX disruption (no page refresh or lost state).
+
+::: note
+See [Renew Tokens When Using Safari](/api-auth/token-renewal-in-safari) for other important limitations and workarounds with the Safari browser. 
+:::
+
+### Access Token expiration
+
+Access Tokens are opaque to applications. This means that applications are unable to inspect the contents of Access Tokens to determine their expiration date.
+
+There are two options to determine when an Access Token expires:
+
+* Read the `expires_in` response parameter returned by Auth0.
+* Ignore expiration dates altogether. Instead, renew the Access Token if your API rejects a request from the application (such as with a 401).
+
+In the case of the [Implicit Flow](/flows/concepts/implicit), the `expires_in` parameter is returned by Auth0 as a hash parameter following a successful authentication. In the [Authorization Code Flow](/flows/concepts/auth-code), it is returned to the backend server when performing the authorization code exchange.
+
+The `expires_in` parameter indicates how many seconds the Access Token will be valid for, and can be used to anticipate expiration of the Access Token.
+
+### Error response
+
+You may receive the `timeout` error response which indicates that timeout during executing `web_message` communication has occurred. This error is typically associated with fallback to cross-origin authentication. To resolve, make sure to add all of the URLs from which you want to perform silent authentication in the **Allowed Web Origins** field for your Application using the Auth0 Dashboard.
+
+## Poll with `checkSession()`
+
+<%= include('../../_includes/_checksession_polling') %>
+
+## Silent authentication with MFA
+
+In some scenarios, you may want to avoid prompting the user for MFA each time they log in from the same browser. To do this, set up a rule so that MFA occurs only once per session. This is useful when performing silent authentication (`prompt=none`) to renew short-lived Access Tokens in a SPA during the duration of a user's session without having to rely on setting `allowRememberBrowser` to `true`.
+
+```js
+function (user, context, callback) {
+  const completedMfa = !!context.authentication.methods.find(
+    (method) => method.name === 'mfa'
+  );
+ 
+  if (completedMfa) {
+    return callback(null, user, context);
+  }
+ 
+  context.multifactor = {
+    provider: 'any',
+    allowRememberBrowser: false
+  };
+ 
+  callback(null, user, context);
+}
+```
+
+See [Change Authentication Request Frequency](/mfa/guides/customize-mfa-universal-login#change-authentication-request-frequency) for details.
+
+## Keep reading
+
+* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation)
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+
diff --git a/ja-jp/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md b/ja-jp/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md
new file mode 100644
index 0000000000..e6a60b46de
--- /dev/null
+++ b/ja-jp/articles/api-auth/tutorials/using-resource-owner-password-from-server-side.md
@@ -0,0 +1,128 @@
+---
+description: Learn how to use Resource Owner Password Grant (ROPG) from the server side together with anomaly detection.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - resource-owner-password
+  - anomaly-detection
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Use Resource Owner Password Grant From the Server Side
+
+<%= include('../_includes/_ropg-warning') %>
+
+Server-side applications can use the [Resource Owner Password Grant](/api-auth/grant/password) to access an API. The flow typically involves prompting the user for username and password as credentials which your server will submit to Auth0 to get an Access Token. When using this flow from server side, some anomaly detection features might fail because of the particularities of this scenario. This document details how to use [Resource Owner Password Grant](/api-auth/grant/password) flow from server side preventing some common issues.
+
+## Prerequisites
+
+Before you continue, make sure to have [brute force protection](/anomaly-detection/guides/enable-disable-brute-force-protection) enabled from your dashboard.
+
+## How it works
+
+1. Your server prompts the user for credentials (such as username and password). This could be achieved in many different ways, for example via a browser UI or providing an API.
+
+2. The user enters credentials and the client-side application submits them to a backend server under your control.
+
+3. Your server submits the credentials to Auth0 using the [Resource Owner Password Grant](/api-auth/grant/password) flow.
+
+4. Auth0 validates the credentials and returns an Access Token. As part of the validation process Auth0 might also execute [anomaly-detection verifications](/anomaly-detection) and perform appropriate actions if an anomaly is detected.
+
+## Brute-force protection and server-side APIs
+
+Brute-force protection relies on having the original user's IP. When calling the API from your server, Auth0 treats the IP of your server as the IP of the end user, and uses it as input for the anomaly-detection functionality, in particular, for brute-force protection. This situation could potentially trigger false positives into the brute-force protection shields, causing it to block users or trigger warnings for legitimate requests.
+
+To prevent this, you may send the end-user's IP address to Auth0 along with the credentials and configure the application to trust the provided IP. Because of security considerations, this configuration is only possible for Authenticated applications (such as those with authentication based on a client secret).
+
+::: warning
+Authenticated applications must only be used from protected resources, typically server-side. Do not use them from native applications or SPAs, as they are not capable of storing secrets.
+:::
+
+### Configure the Auth0 Application to receive and trust the IP sent by your server
+
+1. Navigate to your [dashboard](${manage_url}) and [configure a regular web application or machine-to-machine application](/applications).
+
+2. Choose a __Token Endpoint Authentication Method__ other than `None` under the [Settings](/dashboard/reference/settings-application) section.
+
+    ![Token Endpoint Authentication Method](/media/articles/api-auth/client-auth-method.png)
+
+3. Scroll to the bottom and click _Show Advanced Settings_.
+
+    ::: warning
+    Due to security considerations, the configuration stated on Step 3 will not be available for Non-Authenticated applications.
+    :::
+
+4. Enable __Trust Token Endpoint IP Header__ under the _OAuth_ tab to configure the application to trust the IP sent from your server.
+
+    ![Enabling Auth0-Forwarded-For](/media/articles/api-auth/enabling-auth0-forwarded-for.png)
+
+### Send the end-user IP from your server
+
+If your application is configured to send the `auth0-forwarded-for` header and it authenticates (sends `client_secret` in the request):
+
+- Only the IP in the `auth0-forwarded-for` header is checked against the brute-force protection whitelist.
+- The corollary to the above is the proxy IP is ignored by brute-force protection.  Don't add the proxy IP to the whitelist (if you did it would have no effect).
+- If specific clients that use the proxy should be whitelisted, add them to the whitelist and they will not be subject to brute-force protection.  
+
+If the application is **not** configured to use the `auth0-forwarded-for` header *or* if it does not authenticate (send `client_secret` in the request):
+
+- The originating IP of each request is checked against the brute-force protection whitelist.
+- Whitelisting the IP proxy exempts **all** traffic passing through the proxy from brute-force protection (this is probably not what you want).
+
+1. To send the end-user IP from your server, include a `auth0-forwarded-for` header with the value of the end-user IP address. 
+
+    If the `auth0-forwarded-for` header is marked as trusted, as explained above, Auth0 will use it as the source IP for [brute-force protection](/anomaly-detection). It is important to make sure the provided IP address really belongs to your end user. 
+
+2. When using the resource owner password grant from your webserver with brute-force protection enabled, specify a whitelist of IPs that will not be considered when triggering brute-force protection. Both the `auth0-forwarded-for` IP address and the IP address of the proxy server will be taken into account for IP address whitelists. 
+
+::: warning
+Trusting headers like the `x-forwarded-for` (or, in general, data from application) as source for the end user IP can be a big risk. This should not be done unless you know you can trust that header, since it is easy to spoof and makes possible to bypass the anomaly detection validation.
+:::
+
+### Example
+
+```javascript
+var request = require("request");
+
+app.post('/api/auth', function(req, res, next) {
+  var options = {
+    method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: {
+      'content-type': 'application/x-www-form-urlencoded',
+      'auth0-forwarded-for': req.ip // End user ip
+    },
+    form: {
+      grant_type: 'password',
+      username: 'USERNAME',
+      password: 'PASSWORD',
+      audience: 'YOUR_API_IDENTIFIER',
+      scope: 'SCOPE',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated
+    }
+  };
+
+  request(options, function (error, response, body) {
+    if (error) return next(error);
+
+    // ...
+  });
+});
+```
+
+### Validate with logs
+
+If your settings are working correctly, you will see the following in the logs:
+
+```text
+type:  sepft
+...
+ip:  
+client_ip:  
+...
+```
\ No newline at end of file
diff --git a/ja-jp/articles/api-auth/user-consent.md b/ja-jp/articles/api-auth/user-consent.md
new file mode 100644
index 0000000000..75c4329390
--- /dev/null
+++ b/ja-jp/articles/api-auth/user-consent.md
@@ -0,0 +1,134 @@
+---
+description: Learn how to decouple APIs from applications that consume them and define third-party apps that you don't control or may not trust. 
+topics:
+  - api-authentication
+  - oidc
+  - user-consent
+contentType: how-to
+useCase:
+  - secure-api
+  - call-api
+---
+
+# User Consent and Third-Party Applications
+
+The [OIDC-conformant authentication pipeline](/api-auth/tutorials/adoption) supports defining [resource servers (such as APIs) as entities separate from applications](/api-auth/tutorials/adoption/api-tokens). This lets you decouple APIs from the applications that consume them, and also lets you define third-party applications that you might not control or even fully trust.
+
+All applications created from the [Dashboard](${manage_url}/#/applications) are assumed to be first-party by default.
+
+Third-party applications cannot be created from the Dashboard. They must be created through the Management API, by setting `is_first_party: false`.
+
+All applications created through [Dynamic Client Registration](/api-auth/dynamic-client-registration) will be third-party.
+
+## Consent dialog
+
+If a user is authenticating through a third-party application and is requesting authorization to access the user's information or perform some action at an API on their behalf, they will see a consent dialog.
+
+For example:
+
+
+  
+    
+        
+        
+    
+  
+
    
+
    GET /authorize?
+client_id=some_third_party_client
+&redirect_uri=https://fabrikam.com/contoso_social
+&response_type=token id_token
+&scope=openid profile email read:posts write:posts
+&audience=https://social.contoso.com
+&nonce=...
+&state=...
+
    
+            		
+        Auth0 consent dialog - Fabrikam Application for Contoso is requesting access to your account
+        
    
+
+If the user allows the application, this creates a *user grant* which represents the user's consent to this combination of application, resource server, and scopes. 
+
+The application then receives a successful authentication response from Auth0 as usual. Once consent has been given, the user won't see the consent dialog during subsequent logins until consent is revoked explicitly.
+
+## Scope descriptions 
+
+By default, the consent page will use the scopes' names to prompt for the user's consent. As shown below, you should define scopes using the **action:resource_name** format.
+
+![API Scopes](/media/articles/api-auth/consent-scopes.png)
+
+The consent page groups scopes for the same resource and displays all actions for that resource in a single line. For example, the configuration above would result in **Posts: read and write your posts**.
+
+If you would like to display the **Description** field instead, you can do so by setting the tenant's **use_scope_descriptions_for_consent** to **true**. This will affect consent prompts for all of the APIs on that tenant.
+
+To set the **use_scope_descriptions_for_consent** flag, you will need to make the appropriate call to the API:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": true } }"
+  }
+}
+```
+
+## Handle rejected permissions
+
+If a user decides to reject consent to the application, they will be redirected to the `redirect_uri` specified in the request with an `access_denied` error:
+
+```
+HTTP/1.1 302 Found
+Location: https://fabrikam.com/contoso_social#
+    error=access_denied
+    &state=...
+```
+
+## Skip consent for first-party applications
+
+Only first-party applications can skip the consent dialog, assuming the resource server they are trying to access on behalf of the user has the "Allow Skipping User Consent" option enabled.
+
+::: panel Consent can't be skipped on localhost
+Note that this option only allows __verifiable__ first-party applications to skip consent at the moment. As `localhost` is never a verifiable first-party (because any malicious application may run on `localhost` for a user), Auth0 will always display the consent dialog for applications running on `localhost` regardless of whether they are marked as first-party applications. During development, you can work around this by modifying your `/etc/hosts` file to add an entry such as the following:
+
+```text
+127.0.0.1       myapp.example
+```
+
+Similarly, you **cannot** skip consent (even for first-party applications) if `localhost` appears in any domain in the **Allowed Callback URLs** setting (found in [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings)). Make sure to update **Allowed Callback URLs**, and the callback URL you configured in your application, to match the updated domain-mapping.
+:::
+
+Since third-party applications are assumed to be untrusted, they are not able to skip consent dialogs.
+
+## Revoke Consent
+
+If a user has provided consent, but you would like to revoke it, you can do so via [Dashboard > Users](${manage_url}/#/users). Select the user in which you are interested, and switch over to the **Authorized Applications** tab.
+
+Click **Revoke** next to the appropriate application.
+
+## Password-based flows
+
+When performing a [Resource Owner Password Credentials exchange](/api-auth/grant/password), there is no consent dialog involved.
+During a password exchange, the user provides their password to the application directly, which is equivalent to granting the application full access to the user's account.
+
+### Force users to provide consent
+
+When redirecting to /authorize, the `prompt=consent` parameter will force users to provide consent, even if they have an existing user grant for that application and requested scopes.
+
+### Customize the consent dialog
+
+The consent dialog UI cannot be customized or set to a custom domain.
+
+## Keep reading
+
+* [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party)
+* [View Application Ownership](/api/management/guides/applications/view-ownership)
+* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public)
+* [Enable Third-Party Applications](/applications/guides/enable-third-party-apps)
+* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping)
diff --git a/ja-jp/articles/api-auth/which-oauth-flow-to-use.md b/ja-jp/articles/api-auth/which-oauth-flow-to-use.md
new file mode 100644
index 0000000000..3c2fe7f418
--- /dev/null
+++ b/ja-jp/articles/api-auth/which-oauth-flow-to-use.md
@@ -0,0 +1,69 @@
+---
+title: Which OAuth 2.0 Flow Should I Use?
+toc: true
+description: Learn how to identify the proper OAuth 2.0 grant for your use case.
+topics:
+  - api-authentication
+  - oidc
+  - application-grants
+  - flows
+contentType:
+  - concept
+useCase:
+  - secure-api
+  - call-api
+---
+
+# Which OAuth 2.0 Flow Should I Use?
+
+[OAuth 2.0](https://tools.ietf.org/html/rfc6749) supports several different **grants**. Grants are ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Client's type, but other parameters weigh in as well, like the level of trust for the Client, or the experience you want your users to have.
+
+## OAuth 2.0 terminology
+
+- **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user.
+- **Client**: an application requesting access to a protected resource on behalf of the Resource Owner.
+- **Resource Server**: the server hosting the protected resources. This is the API you want to access.
+- **Authorization Server**: the server that authenticates the Resource Owner and issues Access Tokens after getting proper authorization. In this case, Auth0.
+- **User Agent**: the agent used by the Resource Owner to interact with the Client, for example a browser or a native application.
+
+## Is the Client the Resource Owner?
+
+The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed. An example is a cron job that uses an API to import information to a database. In this example, the cron job is the Client and the Resource Owner since it holds the Client ID and Client Secret and uses them to get an Access Token from the Authorization Server.
+
+If this case matches your needs, then for more information on how this flow works and how to implement it, refer to [Client Credentials Flow (Client Credentials Grant)](/flows/concepts/client-credentials).
+
+## Is the Client a web app executing on the server?
+
+If the Client is a regular web app executing on a server, then the **Authorization Code Flow (Authorization Code grant)** is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token. It's considered the safest choice since the Access Token is passed directly to the web server hosting the Client, without going through the user's web browser and risk exposure.
+
+If this case matches your needs, then for more information on how this flow works and how to implement it, refer to [Authorization Code Flow](/flows/concepts/auth-code).
+
+## Is the Client absolutely trusted with user credentials?
+
+This decision point may result in the **Resource Owner Password Credentials Grant**. In this flow, the end-user is asked to fill in credentials (username/password), typically using an interactive form. This information is sent to the backend and from there to Auth0. It is therefore imperative that the Client is absolutely trusted with this information.
+
+This grant should **only** be used when redirect-based flows (like the [Authorization Code Flow](/flows/concepts/auth-code)) are not possible. If this is your case, then for more information on how this flow works and how to implement it, refer to [Call APIs from Highly Trusted Applications](/api-auth/grant/password).
+
+## Is the Client a Single Page App?
+
+If the Client is a Single Page App, an application running in a browser using a scripting language like JavaScript, there are two grant options: the **Authorization Code Grant using Proof Key for Code Exchange (PKCE)** and the **Implicit Grant**. For most cases, we recommend using the Authorization Code Grant with PKCE.
+
+### Authorization Code Grant with PKCE
+
+This grant adds the concept of a `code_verifier` to the Authorization Code Grant. When the Client asks for an **Authorization Code** it generates a `code_verifier` and its transformed value called `code_challenge`. The `code_challenge` and a `code_challenge_method` are sent along with the request. When the Client wants to exchange the Authorization Code for an Access Token, it also sends along the `code_verifier`. The Authorization Server transforms this and if it matches the originally sent `code_challenge`, it returns an Access Token.
+
+The [Auth0 Single Page App SDK](/libraries/auth0-spa-js) provides high-level API for implementing Authorization Code Grant with PKCE in single page applications.
+
+For more information on how this flow works and how to implement it, refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
+
+### Implicit Grant
+
+In this case, instead of getting an authorization code that needs to be exchanged for an Access Token, the Application directly retrieves an Access Token. On the plus side, this is more efficient since it reduces the number of round trips required to get an Access Token. However, a security consideration is that **the Access Token is exposed on the client side**. Also, note that this flow does not return a Refresh Token because the browser cannot keep it private. 
+
+For more information on how this flow works and how to implement it, refer to [Implicit Flow](/flows/concepts/implicit).
+
+## Is the Client a Native/Mobile App?
+
+If the Application is a native app, then the **Authorization Code Flow with PKCE (Authorization Code Grant using Proof Key for Code Exchange)** should be used.
+
+For more information on how this flow works and how to implement it, refer to [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
diff --git a/ja-jp/articles/api/authentication/_application-reg.md b/ja-jp/articles/api/authentication/_application-reg.md
new file mode 100644
index 0000000000..21471c3821
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_application-reg.md
@@ -0,0 +1,50 @@
+# Dynamic Application (Client) Registration
+
+```http
+POST https://${account.namespace}/oidc/register
+Content-Type: application/json
+{
+  "client_name": "YOUR-NEW-CLIENT-NAME",
+  "redirect_uris": [],
+  "token_endpoint_auth_method": "client_secret_post"
+}
+```
+
+```shell
+curl --request POST \
+  --url https://${account.namespace}/oidc/register \
+  --header 'content-type: application/json' \
+  --data '{"client_name": "YOUR-NEW-CLIENT-NAME","redirect_uris": [], "token_endpoint_auth_method": "client_secret_post"}'
+```
+
+> RESPONSE SAMPLE:
+
+```json
+{
+  "client_name": "My Dynamic Client",
+  "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2",
+  "client_secret": "Q5O...33P",
+  "redirect_uris": [
+    "https://client.example.com/callback",
+    "https://client.example.com/callback2"
+  ],
+  "client_secret_expires_at": 0
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/oidc/register",
+  "link": "#dynamic-application-client-registration"
+}) %>
+
+With a name and the necessary callback URL, you can dynamically register a client with Auth0. No token is needed for this request.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_name` | The name of the Dynamic Client to be created. It is recommended to provide a value but if it is omitted, the default name "My App" will be used. |
+| `redirect_uris`
    Required | An array of URLs that Auth0 will deem valid to call at the end of an Authentication flow. |
+| `token_endpoint_auth_method` | Default value is `client_secret_post`. Use `token_endpoint_auth_method: none` in the request payload if creating a SPA.|
diff --git a/ja-jp/articles/api/authentication/_change-password.md b/ja-jp/articles/api/authentication/_change-password.md
new file mode 100644
index 0000000000..00e44b2854
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_change-password.md
@@ -0,0 +1,87 @@
+# Change Password
+
+```http
+POST https://${account.namespace}/dbconnections/change_password
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "email": "EMAIL",
+  "connection": "CONNECTION",
+  "organization": "ORGANIZATION_ID"
+}
+```
+
+```shell
+curl --request POST \
+  --url https://${account.namespace}/dbconnections/change_password \
+  --header 'content-type: application/json' \
+  --data '{"client_id": "${account.clientId}","email": "EMAIL", "connection": "CONNECTION", "organization": "ORGANIZATION_ID"}'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/dbconnections/change_password",
+  "link": "#change-password"
+}) %>
+
+> RESPONSE SAMPLE:
+
+```JSON
+"We've just sent you an email to reset your password."
+```
+
+Send a change password email to the user's provided email address and `connection`.
+
+Optionally, you may provide an Organization ID to support Organization-specific variables in [customized email templates](/customize/email/email-templates#common-variables) and to include the `organization_id` and `organization_name` parameters in the **Redirect To** URL.
+
+Note: This endpoint only works for database connections.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` | The `client_id` of your client. |
+| `email` 
    Required | The user's email address. |
+| `connection` 
    Required | The name of the database connection configured to your client. |
+| `organization` | The `organization_id` of the Organization associated with the user. |
+
+
+### Remarks
+
+- When the user clicks on the password change link they will be redirected to a page asking them for a new password.
+- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits:
+  * `X-RateLimit-Limit`: Number of requests allowed per minute.
+  * `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time.
+  * `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time).
+
+
+### Learn More
+
+- [Changing a User's Password](/connections/database/password-change)
+- [Password Strength in Auth0 Database Connections](/connections/database/password-strength)
+- [Password Options in Auth0 Database Connections](/connections/database/password-options)
+- [Auth0 API Rate Limit Policy](/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)
diff --git a/ja-jp/articles/api/authentication/_introduction.md b/ja-jp/articles/api/authentication/_introduction.md
new file mode 100644
index 0000000000..0df041af98
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_introduction.md
@@ -0,0 +1,145 @@
+# Introduction
+
+The Authentication API enables you to manage all aspects of user identity when you use Auth0. It offers endpoints so your users can log in, sign up, log out, access APIs, and more. 
+
+The API supports various identity protocols, like [OpenID Connect](/protocols/oidc),  [OAuth 2.0](/protocols/oauth2), [FAPI](/secure/highly-regulated-identity#advanced-security-with-openid-connect-fapi-) and [SAML](/protocols/saml).
+
+:::note
+This API is designed for people who feel comfortable integrating with RESTful APIs. If you prefer a more guided approach check out our [Quickstarts](/quickstarts) or our [Libraries](/libraries).
+:::
+
+## Base URL
+
+The Authentication API is served over HTTPS. All URLs referenced in the documentation have the following base: `https://${account.namespace}`
+
+## Authentication methods
+
+You have five options for authenticating with this API:
+- OAuth2 Access Token
+- Client ID and Client Assertion (confidential applications)
+- Client ID and Client Secret (confidential applications)
+- Client ID (public applications)
+- mTLS Authentication (confidential applications)
+
+### OAuth2 Access Token
+
+Send a valid Access Token in the `Authorization` header, using the `Bearer` authentication scheme.
+
+An example is the [Get User Info endpoint](#get-user-info). In this scenario, you get an Access Token when you authenticate a user, and then you can make a request to the [Get User Info endpoint](#get-user-info), using that token in the `Authorization` header, in order to retrieve the user's profile.
+
+### Client ID and Client Assertion
+Generate a [client assertion](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) containing a signed JSON Web Token (JWT) to authenticate. In the body of the request, include your Client ID, a `client_assertion_type` parameter with the value `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`, and a `client_assertion` parameter with your signed assertion. Review [Private Key JWT]( https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) for examples.
+
+### Client ID and Client Secret
+
+Send the Client ID and Client Secret. The method you can use to send this data is determined by the [Token Endpoint Authentication Method](/get-started/applications/confidential-and-public-applications/view-application-type) configured for your application.
+
+If you are using **Post**, you must send this data in the JSON body of your request.
+
+If you are using **Basic**, you must send this data in the `Authorization` header, using the `Basic` authentication scheme. To generate your credential value, concatenate your Client ID and Client Secret, separated by a colon (`:`), and encode it in Base64.
+
+An example is the [Revoke Refresh Token endpoint](#revoke-refresh-token). This option is available only for confidential applications (such as applications that are able to hold credentials in a secure way without exposing them to unauthorized parties).
+
+### Client ID
+
+Send the Client ID. For public applications (applications that cannot hold credentials securely, such as SPAs or mobile apps), we offer some endpoints that can be accessed using only the Client ID.
+
+An example is the [Implicit Grant](#implicit-flow).
+
+### mTLS Authentication
+
+Generate a certificate, either [self-signed](/get-started/applications/configure-mtls/configure-mtls-for-a-client#self-signed-certificates) or [certificate authority signed](/get-started/applications/configure-mtls/configure-mtls-for-a-client#certificate-authority-signed-certificates). Then, [set up the customer edge network](/get-started/applications/configure-mtls/set-up-the-customer-edge) that performs the mTLS handshake. 
+
+Once your edge network verifies the certificate, forward the request to the Auth0 edge network with the following headers:
+
+- The Custom Domain API key as the `cname-api-key` header.
+- The client certificate as the `client-certificate` header.
+- The client certificate CA verification status as the `client-certificate-ca-verified` header. For more information, see [Forward the Request](/get-started/applications/configure-mtls/set-up-the-customer-edge#forward-the-request-).
+
+To learn more, read [Authenticate with mTLS](/get-started/authentication-and-authorization-flow/authenticate-with-mtls). 
+
+## Parameters
+
+For GET requests, any parameters not specified as a segment in the path can be passed as an HTTP query string parameter:
+
+`GET https://${account.namespace}/some-endpoint?param=value¶m=value`
+
+For POST requests, parameters not included in the URL should be encoded as JSON with a Content-Type of `application/json`:
+
+`curl --request POST --url 'https://${account.namespace}/some-endpoint' --header 'content-type: application/json' --data '{"param": "value", "param": "value"}'`
+
+::: note
+An exception to that is the [SAML IdP-Initiated Single Sign-on (SSO) Flow](#idp-initiated-sso-flow), which uses both a query string parameter and a `x-www-form-urlencoded` value.
+:::
+
+## Code samples
+
+For each endpoint, you will find sample snippets you can use, in three available formats:
+- HTTP request
+- Curl command
+- JavaScript: depending on the endpoint each snippet may use the [Auth0.js library](/libraries/auth0js), Node.js code or simple JavaScript
+
+Each request should be sent with a Content-Type of `application/json`.
+
+## Testing
+
+You can test the endpoints using the [Authentication API Debugger](/extensions/authentication-api-debugger).
+
+### Authentication API Debugger
+
+The [Authentication API Debugger](/extensions/authentication-api-debugger) is an Auth0 extension you can use to test several endpoints of the Authentication API. 
+
+<%= include('../../_includes/_test-this-endpoint') %>
+
+### Configure Connections
+
+1. On the *Configuration* tab, set the fields **Application** (select the application you want to use for the test) and **Connection** (the name of the social connection to use).
+
+1. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Application Settings](${manage_url}/#/applications).
+
+1. At the *OAuth2 / OIDC* tab, select **OAuth2 / OIDC Login**.
+
+### Endpoint options
+Configure other endpoints with the following options:
+
+- Passwordless: On the *OAuth2 / OIDC* tab, set **Username** to the user's phone number if `connection=sms`, or the user's email if `connection=email`, and **Password** to the user's verification code. Click **Resource Owner Endpoint**.
+- SAML SSO:  On the *Other Flows* tab, select **SAML**.
+- WS-Federation: On the *Other Flows* tab, select **WS-Federation**.
+- Logout: On the *Other Flows* tab, select **Logout**, or **Logout (Federated)** to log the user out of the identity provider as well.
+- Legacy Login: On the *OAuth2 / OIDC* tab, set the fields **ID Token**, **Refresh Token** and **Target Client ID**. Click **Delegation**.
+- Legacy Delegation: On the *OAuth2 / OIDC* tab, set **Username** and **Password**. Click **Resource Owner Endpoint**.
+- Legacy Resource Owner:  On the *OAuth2 / OIDC* tab, set the **Username** and **Password**, then select **Resource Owner Endpoint**.
+
+### Authentications flows
+
+Configure authentication flows with the following options:
+- Authorization Code Flow: On the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](/get-started/authentication-and-authorization-flow/authorization-code-flow), and the **Code Verifier** to the key. Click **OAuth2 Code Exchange**.
+- Authorization Code Flow + PKCE: On the *OAuth2 / OIDC* tab, set the field **Authorization Code** to the code you retrieved from [Authorization Code Grant](/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce), and the **Code Verifier** to the key. Click **OAuth2 Code Exchange**.
+- Client Credential Flow:  On the *OAuth2 / OIDC* tab, select **OAuth2 Client Credentials**.
+
+
+## Errors
+
+When an error occurs, you will receive an error object. Most of these error objects contain an error code and an error description so that your applications can more efficiently identify the problem.
+
+If you get an `4xx` HTTP response code, then you can assume that there is a bad request from your end. In this case, check the [Standard Error Responses](#standard-error-responses) for more context. 
+
+`5xx` errors suggest a problem on Auth0's end, so in this case, check [Auth0 Status Page](https://status.auth0.com/) and [@auth0status on Twitter](https://twitter.com/auth0status) to see how our systems are doing.
+
+In any other case you can use [our support options](#support).
+
+## Rate limiting
+
+The Authentication API is subject to rate limiting. The limits differ per endpoint.
+
+If you exceed the provided rate limit for a given endpoint, you will receive the `429 Too Many Requests` response with the following message: `Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.`
+
+For details on rate limiting, refer to [Auth0 API Rate Limit Policy](/policies/rate-limits).
+
+Note that for database connections Auth0 limits certain types of repeat login attempts depending on the user account and IP address. For details, refer to [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits).
+
+## Support
+
+If you have problems or need help with your case, you can always reach out to our [Support](${env.DOMAIN_URL_SUPPORT}).
+
+Note that if you have a free subscription plan, and you are not in your 22-day trial period, you will not be able to access or open tickets in the [Support Center](${env.DOMAIN_URL_SUPPORT}). In this case, you can seek support through the [Auth0 Community](https://community.auth0.com/). For more info on our support program, refer to [Support Options](/support).
diff --git a/ja-jp/articles/api/authentication/_login.md b/ja-jp/articles/api/authentication/_login.md
new file mode 100644
index 0000000000..291091ada0
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_login.md
@@ -0,0 +1,373 @@
+
+# Login
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#social"
+}) %>
+
+## Social
+
+```http
+GET https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  state=STATE&
+  ADDITIONAL_PARAMETERS
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+You can connect your Auth0 service to a social identity provider and allow your users to log in to your application via Facebook, Google, Apple, or other supported providers. To learn more about supported providers, visit [Marketplace](https://marketplace.auth0.com/features/social-connections). 
+
+To authenticate users with a social provider, make a `GET` call to the `/authorize` endpoint. It will return a `302` redirect to the social provider specified in the `connection` parameter.
+
+::: note
+Social connections only support browser-based (passive) authentication because most social providers don't allow a username and password to be entered into applications that they don't own. Therefore, the user will be redirected to the provider's sign in page.
+:::
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `response_type` 
    Required | Specifies the token type. Use `code` for server side flows and `token` for application side flows |
+| `client_id` 
    Required | The `client_id` of your application |
+| `connection`     | The name of a social identity provider configured to your application, for example `google-oauth2` or `facebook`. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget. |
+| `redirect_uri` 
    Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).|
+| `state` 
    Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. |
+| `ADDITIONAL_PARAMETERS` | Append any additional parameter to the end of your request, and it will be sent to the provider. For example, `access_type=offline` (for Google Refresh Tokens) , `display=popup` (for Windows Live popup mode). |
+
+### Remarks
+
+- If `response_type=token`, after the user authenticates on the provider, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs.
+
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Learn More
+
+- [Supported Social Identity Providers](https://marketplace.auth0.com/features/social-connections)
+- [Custom Social Connections](/connections/social/oauth2)
+- [State Parameter](/secure/attack-protection/state-parameters)
+- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-)
+
+## Database/AD/LDAP (Passive)
+
+```http
+GET https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  scope=openid%20profile%20email&
+  state=STATE
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+Use the Auth0 user store or your own database to store and manage username and password credentials. If you have your own user database, you can use it as an identity provider in Auth0 to authenticate users. When you make a `GET` call to the `/authorize` endpoint for browser based (passive) authentication. It returns a `302` redirect to the [Auth0 Login Page](https://${account.namespace}/login) that will show the Login Widget where the user can log in with email and password.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `response_type` 
    Required | Specifies the token type. Use `code` for server side flows and `token` for application side flows. |
+| `client_id` 
    Required | The `client_id` of your application. |
+| `connection`     | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. |
+| `redirect_uri` 
    Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).|
+| `scope` 
    Recommended | OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a Refresh Token.|
+| `state` 
    Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. |
+
+### Remarks
+
+- If `response_type=token`, after the user authenticates, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs.
+- The main difference between passive and active authentication is that the former happens in the browser through the [Auth0 Login Page](https://${account.namespace}/login) and the latter can be invoked from anywhere (a script, server to server, and so forth).
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Learn More
+
+- [Database Identity Providers](/connections/database)
+- [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits)
+- [Active Directory/LDAP Connector](/connector)
+- [State Parameter](/protocols/oauth2/oauth-state)
+- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-)
+
+## Enterprise (SAML and Others)
+
+```http
+GET https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  state=STATE
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+You can connect your Auth0 service to an enterprise identity provider and allow your users to log in to your application via Microsoft Azure Active Directory, Google Workspace, Okta Workforce, or other supported providers. To learn more about supported providers, visit [Auth0 Marketplace](https://marketplace.auth0.com/features/enterprise-connections). 
+
+Make a `GET` call to the `/authorize` endpoint for passive authentication. It returns a `302` redirect to the SAML Provider (or Windows Azure AD and the rest, as specified in the `connection`) to enter their credentials.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `response_type` 
    Required | Specifies the token type. Use `code` for server side flows, `token` for application side flows. |
+| `client_id` 
    Required | The `client_id` of your application. |
+| `connection` | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. |
+| `redirect_uri` 
    Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).|
+| `state` 
    Recommended | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. |
+
+### Remarks
+
+- If no `connection` is specified, it will redirect to the [Login Page](https://${account.namespace}/login) and show the Login Widget.
+- If `response_type=token`, after the user authenticates, it will redirect to your application `callback URL` passing the Access Token and ID Token in the address `location.hash`. This is used for Single-Page Apps and also on Native Mobile SDKs.
+- Additional parameters can be sent that will be passed to the provider.
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Learn More
+
+- [SAML](/protocols/saml)
+- [Obtain a Client Id and Client Secret for Microsoft Azure Active Directory](/connections/enterprise/azure-active-directory)
+- [State Parameter](/protocols/oauth2/oauth-state)
+- [Auth0.js /authorize Method Reference](/libraries/auth0js#webauth-authorize-)
+
+## Back-Channel Login
+
+:::note
+This feature is currently in Early Access. To request access, contact your Technical Account Manager.
+:::
+
+The Back-Channel Login endpoint enables applications to send an authentication request to a user’s phone, or the authentication device, provided they have an app installed and are enrolled for [push notifications using the Guardian SDK](/secure/multi-factor-authentication/auth0-guardian#enroll-in-push-notifications).
+
+Use the Back-Channel Login endpoint to authenticate users for the following use cases:
+
+- Users are not in front of the application that requires authentication, such as when they're telephoning a call center.
+- The consumption device, or the device that helps the user consume a service, is insecure for sensitive operations e.g. web browser for financial transactions.
+- The consumption device has limited interactive capability e.g. e-bicycles or e-scooters.
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/bc-authorize",
+  "link": "#back-channel-login"
+}) %>
+
+```http
+curl --location 'https://[TENANT_DOMAIN]/bc-authorize' \
+--header 'Content-Type: application/x-www-form-urlencoded' \
+--data-urlencode 'client_id=[CLIENT ID]' \
+--data-urlencode 'client_secret=[CLIENT SECRET]' \
+--data-urlencode 'binding_message=[YOUR BINDING MESSAGE]' \
+--data-urlencode 'login_hint={ "format": "iss_sub", "iss":
+"https://[TENANT].auth0.com/", "sub": "auth0|[USER ID]" }' \
+--data-urlencode 'scope=openid'
+```
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Client ID of your application. |
+| `binding_message` 
    Required | Human-readable string displayed on both the device calling `/bc-authorize` and the user’s authentication device (e.g. phone) to ensure the user is approves the correct request. For example: `ABC-123-XYZ`. |
+| `login_hint` 
    Required | String containing information about the user to contact for authentication. It uses the [IETF9493 standard for Subject Identifiers for Security Event Tokens](https://datatracker.ietf.org/doc/html/rfc9493). Auth0 only supports the [Issuer and Identifier format](https://datatracker.ietf.org/doc/html/rfc9493#name-issuer-and-subject-identifi). For an example login hint, review the [Remarks](#remarks). |
+| `scope` 
    Required | Space-separated list of OIDC and custom API scopes. For example: `openid read:timesheets edit:timesheets`. Include `offline_access` to get a refresh token. At a minimum, you must include the scope `openid`. |
+| `audience` 
    Optional | Unique identifier of the audience for an issued token. If you require an access token for an API, pass the unique identifier of the target API you want to access. |
+| `request_expiry` 
    Optional | To configure a custom expiry time in seconds for this request, pass a number between 1 and 300. If not provided, expiry defaults to 300 seconds. |
+
+### Response Body
+
+If the request is successful, you should receive a response like the following:
+
+```http
+{
+  "auth_req_id": "eyJh...",
+  "expires_in": 300,
+  "interval": 5
+}
+```
+
+The `auth_req_id` value should be kept as it is used later in the flow to identify the authentication request.
+
+The `expires_in` value tells you how many seconds you have until the authentication request expires. 
+
+The `interval` value tells you how many seconds you must wait between poll requests.
+
+The request should be approved or rejected on the user’s authentication device using the Guardian SDK.
+
+### Remarks
+
+The following code sample is an example login hint: 
+
+  ```http
+  { 
+    "format": "iss_sub", 
+    "iss": "https://[TENANT_DOMAIN]/", 
+    "sub": "auth0|[USER ID]" 
+  }
+  ```
+
+White space is not significant. Replace the `[TENANT_DOMAIN]` with your tenant domain or custom domain. Replace the `[USER ID]` with a valid `user_id` for the authorizing user returned from the [User Search APIs](https://auth0.com/docs/manage-users/user-search).
+
+Include an optional parameter for application authentication in the request:
+
+- Client Secret with HTTP Basic auth, in which case no parameters are required. The `client_id` and `client_secret` are passed in a header.
+- Client Secret Post, in which case the `client_id` and `client_secret` are required.
+- Private Key JWT, where the `client_id`, `client_assertion` and `client_assertion` type are required.
+- mTLS, where the `client_id` parameter is required and the `client-certificate` and `client-certificate-ca-verified` headers are required.
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#post-token"
+}) %>
+
+```http
+curl --location 'https://[TENANT_DOMAIN]/oauth/token' \
+--header 'Content-Type: application/x-www-form-urlencoded' \
+--data-urlencode 'client_id=[CLIENT ID]' \
+--data-urlencode 'client_secret=[CLIENT SECRET]' \
+--data-urlencode 'auth_req_id=[FROM THE BC-AUTHORIZE RESPONSE]' \
+--data-urlencode 'grant_type=urn:openid:params:grant-type:ciba'
+```
+
+To check on the status of a Back-Channel Login flow, poll the `/oauth/token` endpoint at regular intervals by passing the following:
+
+- `auth_req_id` returned from the call to `/bc-authorize`
+- `urn:openid:params:grant-type:ciba` grant type 
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Client ID of your application |
+| `auth_req_id` 
    Required | Used to reference the authentication request. Returned from the call to `/bc-authorize` | 
+| `grant_type` 
    Required | Must be set to `urn:openid:params:grant-type:ciba` | 
+
+### Response Body
+
+If the authorizing user has not yet approved or rejected the request, you should receive a response like the following: 
+
+```http
+{ 
+  "error": "authorization_pending", 
+  "error_description": "The end-user authorization is pending"
+}
+```
+
+If the authorizing user rejects the request, you should receive a response like the following:
+
+```http
+{
+  "error": "access_denied",
+  "error_description": "The end-user denied the authorization request or it
+has been expired"
+}
+```
+
+If you are polling too quickly (faster than the interval value returned from `/bc-authorize`), you should receive a response like the following:
+
+```http
+{
+  "error": "slow_down",
+  "error_description": "You are polling faster than allowed. Try again in 10 seconds."
+}
+```
+
+In addition, Auth0 will add the the [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) header to the response indicating how many seconds to wait before attempting to poll again. If you consistently poll too frequently, the number of seconds you must wait increases.
+
+If the authorizing user has approved the push notification, the call returns the ID token and access token (and potentially a refresh token):
+
+```http
+{
+  "access_token": "eyJh...",
+  "id_token": "eyJh...",
+  "expires_in": 86400,
+  "scope": "openid"
+}
+```
+
+Once you have exchanged an `auth_req_id` for an ID or access token, it is no longer usable.
+
+### Remarks
+
+Include an optional parameter for application authentication in the request:
+
+- Client Secret with HTTP Basic auth, in which case no parameters are required. The `client_id` and `client_secret` are passed in a header.
+- Client Secret Post, in which case the `client_id` and `client_secret` are required.
+- Private Key JWT, where the `client_id`, `client_assertion` and `client_assertion` type are required.
+- mTLS, where the `client_id` parameter is required and the `client-certificate` and `client-certificate-ca-verified` headers are required.
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/_logout.md b/ja-jp/articles/api/authentication/_logout.md
new file mode 100644
index 0000000000..751cd42692
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_logout.md
@@ -0,0 +1,176 @@
+# Logout
+## Auth0 Logout
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/v2/logout",
+  "link": "#logout"
+}) %>
+
+```http
+GET https://${account.namespace}/v2/logout?
+  client_id=${account.clientId}&
+  returnTo=LOGOUT_URL
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/v2/logout' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "returnTo":"LOGOUT_URL"}'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+Use this endpoint to logout a user. If you want to navigate the user to a specific URL after the logout, set that URL at the `returnTo` parameter. The URL should be included in any the appropriate `Allowed Logout URLs` list:
+- If the `client_id` parameter is included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the application level. To learn more, read [Log Users Out of Applications](/authenticate/login/logout/log-users-out-of-applications).
+- If the `client_id` parameter is NOT included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the tenant level. To learn more, read [Log Users Out of Auth0](/authenticate/login/logout/log-users-out-of-auth0).
+- If the `client_id` parameter is included and the `returnTo` URL is NOT set, the server returns the user to the first Allowed Logout URLs set in the Dashboard. To learn more, read [Log Users Out of Applications](/authenticate/login/logout/log-users-out-of-applications).
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `returnTo`      | URL to redirect the user after the logout. |
+| `client_id`      | The `client_id` of your application. |
+| `federated`      | Add this query string parameter to the logout URL, to log the user out of their identity provider, as well: `https://${account.namespace}/v2/logout?federated`. |
+
+### Remarks
+
+- Logging the user out of their identity provider is not common practice, so think about the user experience before you use the `federated` query string parameter.
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Learn More
+
+- [Logout](/logout)
+
+## OIDC Logout
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/oidc/logout",
+  "link": "#logout"
+}) %>
+
+```http
+GET https://${account.namespace}/oidc/logout?
+  post_logout_redirect_uri=LOGOUT_URL&
+  id_token_hint=ID_TOKEN_HINT
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/oidc/logout' \
+  --header 'content-type: application/json' \
+  --data-raw '
+  { 
+    "client_id":"${account.clientId}", 
+    "post_logout_redirect_uri":"LOGOUT_URL", 
+    "id_token_hint":"ID_TOKEN_HINT"
+  }'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+Use this endpoint to logout a user. If you want to navigate the user to a specific URL after the logout, set that URL at the `post_logout_redirect_uri` parameter. The URL should be included in the appropriate `Allowed Logout URLs` list:
+
+- If the `id_token_hint` parameter is included:
+  - When the `client_id` parameter is included, the server uses the URL from the `aud` claim in the `id_token_hint` to select which of the `Allowed Logout URLs` to use from the application specified by the `client_id`.
+  - When the `client_id` parameter is NOT included, the server uses the URL from the `aud` claim in the `id_token_hint` to select which of the `Allowed Logout URLs` at the tenant level to use.
+- If the `id_token_hint` parameter is not included:
+  - If the `client_id` parameter is included, the `post_logout_redirect_uri` URL must be listed in the `Allowed Logout URLs` set at the application level.
+  - If the `client_id` parameter is NOT included, the `post_logout_redirect_uri` URL must be listed in the `Allowed Logout URLs` set at the tenant level.
+  - If the `client_id` parameter is included and the `post_logout_redirect_uri` URL is NOT set, the server returns the user to the first `Allowed Logout URLs` set in Auth0 Dashboard.
+
+  To learn more, read [Log Users Out of Auth0 with OIDC Endpoint](/authenticate/login/logout/log-users-out-of-auth0).
+
+
+### Request Parameters
+
+| Parameter                             | Description                                                                                                                                                     |
+| :------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id_token_hint` (Recommended)         | Previously issued ID Token for the user. This is used to indicate which user to log out.                                                                         |
+| `logout_hint` (Optional)              | Optional `sid` (session ID) value to indicate which user to log out. Should be provided when `id_token_hint` is not available.                                                                       |
+| `post_logout_redirect_uri` (Optional) | URL to redirect the user after the logout.                                                                                                                      |
+| `client_id` (Optional)                | The `client_id` of your application.                                                                                                                            |
+| `federated` (Optional)                | Add this query string parameter to log the user out of their identity provider: `https://YOUR_DOMAIN/oidc/logout?federated`.        |
+| `state` (Optional)                    | An opaque value the applications adds to the initial request that the authorization server includes when redirecting the back to the`post_logout_redirect_uri`. |
+| `ui_locales` (Optional)               | Space-delimited list of locales used to constrain the language list for the request. The first locale on the list must match the enabled locale in your tenant  |
+
+### Remarks
+
+- Logging the user out of their social identity provider is not common practice, so think about the user experience before you use the `federated` query string parameter with social identity providers.
+- If providing both `id_token_hint` and `logout_hint`, the `logout_hint` value must match the `sid` claim from the id_token_hint.
+- If providing both `id_token_hint` and `client_id`, the `client_id` value must match the `aud` claim from the `id_token_hint`.
+- If `id_token_hint` is not provided, then the user will be prompted for consent unless a `logout_hint` that matches the user's session ID is provided.
+- The `POST` HTTP method is also supported for this request. When using `POST`, the request parameters should be provided in the request body as form parameters instead of the query string. The federated parameter requires a value of `true` or `false`.
+- This conforms to the [OIDC RP-initiated Logout Specification](https://openid.net/specs/openid-connect-rpinitiated-1_0.html).
+
+### Learn More
+
+- [Logout](/logout)
+- [Use the OIDC Endpoint to Log Users Out of Auth0](/logout/log-users-out-of-auth0)
+- [OIDC RP-initiated Logout Specification](https://openid.net/specs/openid-connect-rpinitiated-1_0.html)
+
+## SAML Logout
+
+```http
+POST https://${account.namespace}/samlp/CLIENT_ID/logout
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/samlp/CLIENT_ID/logout' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data '{SAML_LOGOUT_REQUEST}'
+```
+
+Use this endpoint to log out a user from an Auth0 tenant configured as a SAML identity provider (IdP).
+
+Logout behavior is determined by the configuration of the SAML2 Web App addon for the application on the Auth0 tenant acting as the SAML IdP. To learn more, read [Log Users Out of SAML Identity Providers](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps#configure-slo-when-auth0-is-the-saml-idp).
+
+### Request Parameters
+
+| Parameter | Description |
+|:--|:--|
+| `CLIENT_ID` | Client ID of your application configured with the [SAML2 Web App addon](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/enable-saml2-web-app-addon). |
+| `SAML_LOGOUT_REQUEST` | SAML `` message. |
+
+### Remarks
+- The POST body must contain a valid SAML `` message. To learn more, read [Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 on Oasis](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
+
+### Learn More
+- [Logout](/logout)
+- [Log Users Out of SAML Identity Providers](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps)
diff --git a/ja-jp/articles/api/authentication/_multifactor-authentication.md b/ja-jp/articles/api/authentication/_multifactor-authentication.md
new file mode 100644
index 0000000000..32c6a59802
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_multifactor-authentication.md
@@ -0,0 +1,662 @@
+# Multi-factor Authentication
+
+The Multi-factor Authentication (MFA) API endpoints allow you to enforce MFA when users interact with [the Token endpoints](#get-token), as well as enroll and manage user authenticators.
+
+First, request a challenge based on the challenge types supported by the application and user. If you know that one-time password (OTP) is supported, you can skip the challenge request.
+
+Next, verify the multi-factor authentication using the `/oauth/token` endpoint and the specified challenge type: a one-time password (OTP), a recovery code, or an out-of-band (OOB) challenge.
+
+To learn more, read:
+
+- [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password)
+- [Multi-factor Authentication API](/mfa/concepts/mfa-api)
+- [Multi-factor Authentication in Auth0](/mfa)
+
+## Challenge Request
+
+```http
+POST https://${account.namespace}/mfa/challenge
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+  "mfa_token": "MFA_TOKEN",
+  "challenge_type": "oob|otp"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/mfa/challenge' \
+  --header 'content-type: application/json' \
+  --data '{"mfa_token":"MFA_TOKEN", "challenge_type":"oob otp", "client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET"}'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/mfa/challenge',
+  headers: { 'content-type': 'application/json' },
+  body:
+   { mfa_token: 'MFA_TOKEN',
+     challenge_type: 'oob otp',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' },
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE FOR OTP:
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "challenge_type":"otp",
+}
+```
+
+> RESPONSE SAMPLE FOR OOB WITHOUT BINDING METHOD:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "challenge_type":"oob",
+  "oob_code": "abcde...dasg"
+}
+```
+
+> RESPONSE SAMPLE FOR OOB WITH BINDING METHOD:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "challenge_type":"oob",
+  "binding_method":"prompt",
+  "oob_code": "abcde...dasg"
+}
+```
+
+Request a challenge for multi-factor authentication (MFA) based on the challenge types supported by the application and user.
+
+The `challenge_type` is how the user will get the challenge and prove possession. Supported challenge types include:
+
+- `otp`: for one-time password (OTP)
+- `oob`: for SMS/Voice messages or out-of-band (OOB)
+
+If OTP is supported by the user and you don't want to request a different factor, you can skip the challenge request and [verify the multi-factor authentication with a one-time password](#verify-with-one-time-password-otp-).
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `mfa_token` 
    Required | The token received from `mfa_required` error. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `challenge_type` | A whitespace-separated list of the challenges types accepted by your application. Accepted challenge types are `oob` or `otp`. Excluding this parameter means that your client application accepts all supported challenge types. |
+| `authenticator_id` | The ID of the authenticator to challenge. You can get the ID by querying the list of available authenticators for the user as explained on [List authenticators](#list-authenticators) below. |
+
+### Remarks
+
+- This endpoint does not support enrollment; the user must be enrolled with the preferred method before requesting a challenge.
+- Auth0 chooses the challenge type based on the application's supported types and types the user is enrolled with.
+- An `unsupported_challenge_type` error is returned if your application does not support any of the challenge types the user has enrolled with.
+- An `unsupported_challenge_type` error is returned if the user is not enrolled.
+- If the user is not enrolled, you will get a `association_required` error, indicating the user needs to enroll to use MFA. Read [Add an authenticator](#add-an-authenticator) below on how to proceed.
+
+### Learn More
+
+* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate)
+* [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage)
+
+## Verify with One-Time Password (OTP)
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-otp&otp=OTP_CODE
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'mfa_token=MFA_TOKEN&otp=OTP_CODE&grant_type=http://auth0.com/oauth/grant-type/mfa-otp&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { mfa_token: 'MFA_TOKEN',
+     otp: 'OTP_CODE',
+     grant_type: 'http://auth0.com/oauth/grant-type/mfa-otp',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE FOR OTP:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#multifactor-authentication"
+}) %>
+
+Verifies multi-factor authentication (MFA) using a one-time password (OTP).
+
+To verify MFA with an OTP, prompt the user to get the OTP code, then make a request to the `/oauth/token` endpoint. The request must have the OTP code, the `mfa_token` you received (from the `mfa_required` error), and the `grant_type` set to `http://auth0.com/oauth/grant-type/mfa-otp`.
+
+The response is the same as responses for `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types.
+
+### Request parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For OTP MFA use  `http://auth0.com/oauth/grant-type/mfa-otp`. |
+| `client_id` | Your application's Client ID. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method. |
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `mfa_token` 
    Required | The `mfa_token` you received from `mfa_required` error. |
+| `otp` 
    Required | OTP Code provided by the user. |
+
+### Learn More
+
+- [Associate OTP Authenticators](/mfa/guides/mfa-api/otp)
+
+## Verify with Out-of-Band (OOB)
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-oob&oob_code=OOB_CODE&binding_code=BINDING_CODE
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http://auth0.com/oauth/grant-type/mfa-oob&oob_code=OOB_CODE&binding_code=BINDING_CODE'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { mfa_token: 'MFA_TOKEN',
+     oob_code: "OOB_CODE",
+     binding_code: "BINDING_CODE"
+     grant_type: 'http://auth0.com/oauth/grant-type/mfa-oob',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE FOR PENDING CHALLENGE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "error":"authorization_pending",
+  "error_description":"Authorization pending: please repeat the request in a few seconds."
+}
+```
+
+> RESPONSE SAMPLE FOR VERIFIED CHALLENGE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+> RESPONSE SAMPLE FOR REJECTED CHALLENGE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "error":"invalid_grant",
+  "error_description":"MFA Authorization rejected."
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#multifactor-authentication"
+}) %>
+
+Verifies multi-factor authentication (MFA) using an out-of-band (OOB) challenge (either Push notification, SMS, or Voice).
+
+To verify MFA using an OOB challenge, your application must make a request to `/oauth/token` with `grant_type=http://auth0.com/oauth/grant-type/mfa-oob`. Include the `oob_code` you received from the challenge response, as well as the `mfa_token` you received as part of `mfa_required` error.
+
+The response to this request depends on the status of the underlying challenge verification:
+- If the challenge has been accepted and verified, it will be the same as `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types.
+- If the challenge has been rejected, you will get an `invalid_grant` error, meaning that the challenge was rejected by the user. At this point you should stop polling, as this response is final.
+- If the challenge verification is still pending (meaning it has not been accepted nor rejected), you will get an `authorization_pending` error, meaning that you must retry the same request a few seconds later. If you request too frequently, you will get a `slow_down` error.
+
+When the challenge response includes a `binding_method: prompt`, your app needs to prompt the user for the `binding_code` and send it as part of the request. The `binding_code` is usually a 6-digit number (similar to an OTP) included as part of the challenge.  No `binding_code` is necessary if the challenge response did not include a `binding_method`. In this scenario, the response will be immediate; you will receive an `invalid_grant` or an `access_token` as response.
+
+### Request parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For OTP MFA, use  `http://auth0.com/oauth/grant-type/mfa-oob`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `mfa_token` 
    Required | The `mfa_token` you received from `mfa_required` error. |
+| `oob_code` 
    Required | The oob code received from the challenge request. |
+| `binding_code`| A code used to bind the side channel (used to deliver the challenge) with the main channel you are using to authenticate. This is usually an OTP-like code delivered as part of the challenge message. |
+
+### Learn More
+
+- [Associate Out-of-Band Authenticators](/mfa/guides/mfa-api/oob)
+
+## Verify with Recovery Code
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fmfa-recovery-code&recovery_code=RECOVERY_CODE
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&mfa_token=MFA_TOKEN&grant_type=http://auth0.com/oauth/grant-type/mfa-recovery-code&recovery_code=RECOVERY_CODE'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { mfa_token: 'MFA_TOKEN',
+     recovery_code: 'RECOVERY_CODE',
+     grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE FOR OTP:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400,
+  "recovery_code": "abcdefg"
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#multifactor-authentication"
+}) %>
+
+Verifies multi-factor authentication (MFA) using a recovery code.
+
+Some multi-factor authentication (MFA) providers (such as Guardian) support using a recovery code to login. Use this method to authenticate when the user's enrolled device is unavailable, or the user cannot receive the challenge or accept it due to connectivity issues.
+
+To verify MFA using a recovery code your app must prompt the user for the recovery code, and then make a request to `oauth/token` with `grant_type=http://auth0.com/oauth/grant-type/mfa-recovery-code`. Include the collected recovery code and the `mfa_token` from the `mfa_required` error. If the recovery code is accepted, the response will be the same as for `password` or `http://auth0.com/oauth/grant-type/password-realm` grant types. It might also include a `recovery_code` field, which the application must display to the end-user to be stored securely for future use.
+
+### Request parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For recovery code use `http://auth0.com/oauth/grant-type/mfa-recovery-code`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `mfa_token` 
    Required | The `mfa_token` you received from `mfa_required` error. |
+| `recovery_code` 
    Required | Recovery code provided by the end-user.
+
+## Add an Authenticator
+
+```http
+POST https://${account.namespace}/mfa/associate
+Content-Type: application/json
+Authorization: Bearer ACCESS_TOKEN or MFA_TOKEN
+{
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+  "authenticator_types": ["oob"],
+  "oob_channels": "sms",
+  "phone_number": "+1 555 123456"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/mfa/associate' \
+  --header 'authorization: Bearer ACCESS_TOKEN or MFA_TOKEN' \
+  --header 'content-type: application/json' \
+  --data '{"client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET", "authenticator_types":["oob"], "oob_channels":"sms", "phone_number": "+1 555 123456"}'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/mfa/associate',
+  headers: {
+    'authorization': 'Bearer TOKEN',
+    'content-type': 'application/json'
+  },
+  body:
+   { client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET',
+     authenticator_types: ["oob"],
+     oob_channels: "sms",
+     phone_number: "+1 555 123456" },
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE FOR OOB (SMS channel):
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "oob_code": "Fe26.2**da6....",
+  "binding_method":"prompt",
+  "authenticator_type":"oob",
+  "oob_channels":"sms",
+  "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"],
+}
+```
+
+> RESPONSE SAMPLE FOR OOB (Auth0 channel):
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "oob_code": "Fe26.2**da6....",
+  "barcode_uri":"otpauth://...",
+  "authenticator_type":"oob",
+  "oob_channels":"auth0",
+  "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"],
+}
+```
+
+> RESPONSE SAMPLE FOR OTP:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "secret": "ABCDEFGMK5CE6WTZKRTTQRKUJVFXOVRF",
+  "barcode_uri":"otpauth://...",
+  "authenticator_type":"otp",
+  "recovery_codes":["ABCDEFGDRFK75ABYR7PH8TJA"],
+}
+```
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/mfa/associate",
+  "link": "#multifactor-authentication"
+}) %>
+
+Associates or adds a new authenticator for multi-factor authentication (MFA).
+
+If the user has active authenticators, an Access Token with the `enroll` scope and the `audience` set to `https://${account.namespace}/mfa/` is required to use this endpoint.
+
+If the user has no active authenticators, you can use the `mfa_token` from the `mfa_required` error in place of an Access Token for this request.
+
+After an authenticator is added, it must be verified. To verify the authenticator, use the response values from the `/mfa/associate` request in place of the values returned from the `/mfa/challenge` endpoint and continue with the verification flow.
+
+A `recovery_codes` field is included in the response the first time an authenticator is added. You can use `recovery_codes` to pass multi-factor authentication as shown on [Verify with recovery code](#verify-with-recovery-code) above.
+
+To access this endpoint, you must set an Access Token at the Authorization header, with the following claims:
+- `scope`: `enroll`
+- `audience`: `https://${account.namespace}/mfa/`
+
+### Request parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field in your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `authenticator_types` 
    Required | The type of authenticators supported by the client. Value is an array with values `"otp"` or `"oob"`. |
+| `oob_channels` | The type of OOB channels supported by the client. An array with values `"auth0"`, `"sms"`, `"voice"`. Required if `authenticator_types` include `oob`. |
+| `phone_number` | The phone number to use for SMS or Voice. Required if `oob_channels` includes `sms` or `voice`. |
+
+### Learn More
+
+- [Multi-factor Authentication API](/mfa/concepts/mfa-api)
+
+## List Authenticators
+
+```http
+GET https://${account.namespace}/mfa/authenticators
+Content-Type: application/json
+Authorization: Bearer ACCESS_TOKEN
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/mfa/authenticators' \
+  --header 'authorization: Bearer ACCESS_TOKEN' \
+  --header 'content-type: application/json'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'GET',
+  url: 'https://${account.namespace}/mfa/authenticators',
+  headers: {
+    'authorization': 'Bearer ACCESS_TOKEN',
+    'content-type': 'application/json'
+  },
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+[
+  {
+    "id":"recovery-code|dev_DsvzGfZw2Fg5N3rI",
+    "authenticator_type":"recovery-code",
+    "active":true
+  },
+  {
+    "id":"sms|dev_gB342kcL2K22S4yB",
+    "authenticator_type":"oob",
+    "oob_channels":"sms",
+    "name":"+X XXXX1234",
+    "active":true
+  },
+  {
+    "id":"sms|dev_gB342kcL2K22S4yB",
+    "authenticator_type":"oob",
+    "oob_channels":"sms",
+    "name":"+X XXXX1234",
+    "active":false
+  },
+  {
+    "id":"push|dev_433sJ7Mcwj9P794y",
+    "authenticator_type":"oob",
+    "oob_channels":"auth0",
+    "name":"John's Device",
+    "active":true
+  },
+    {
+    "id":"totp|dev_LJaKaN5O3tjRFOw2",
+    "authenticator_type":"otp",
+    "active":true
+  }
+]
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/mfa/authenticators",
+  "link": "#multifactor-authentication"
+}) %>
+
+Returns a list of authenticators associated with your application.
+
+To access this endpoint you must set an Access Token at the Authorization header, with the following claims:
+- `scope`: `read:authenticators`
+- `audience`: `https://${account.namespace}/mfa/`
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `ACCESS_TOKEN` 
    Required | The Access Token obtained during login. |
+
+
+#### Learn More
+
+- [Manage Authenticators](/mfa/guides/mfa-api/manage)
+
+## Delete an Authenticator
+
+```http
+DELETE https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID
+Authorization: Bearer ACCESS_TOKEN
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID' \
+  --header 'authorization: Bearer ACCESS_TOKEN' \
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'DELETE',
+  url: 'https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID',
+  headers: {
+    'authorization': 'Bearer ACCESS_TOKEN',
+    'content-type': 'application/json'
+  },
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 204 OK
+```
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "DELETE",
+  "path": "/mfa/authenticators",
+  "link": "#multifactor-authentication"
+}) %>
+
+Deletes an associated authenticator using its ID.
+
+You can get authenticator IDs by [listing the authenticators](#list-authenticators).
+
+To access this endpoint, you must set an Access Token at the Authorization header, with the following claims:
+- `scope`: `remove:authenticators`
+- `audience`: `https://${account.namespace}/mfa/`
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `ACCESS_TOKEN` 
    Required | The Access Token obtained during login. |
+| `AUTHENTICATOR_ID` 
    Required | The ID of the authenticator to delete.
+
+### Learn More
+
+- [Manage Authenticators](/mfa/guides/mfa-api/manage)
diff --git a/ja-jp/articles/api/authentication/_passwordless.md b/ja-jp/articles/api/authentication/_passwordless.md
new file mode 100644
index 0000000000..4cb6994684
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_passwordless.md
@@ -0,0 +1,256 @@
+
+
+# Passwordless
+
+Passwordless connections do not require the user to remember a password. Instead, another mechanism is used to prove identity, such as a one-time code sent through email or SMS, every time the user logs in.
+
+## Get Code or Link
+
+```http
+POST https://${account.namespace}/passwordless/start
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET", // for web applications
+  "connection": "email|sms",
+  "email": "USER_EMAIL", //set for connection=email
+  "phone_number": "USER_PHONE_NUMBER", //set for connection=sms
+  "send": "link|code", //if left null defaults to link
+  "authParams": { // any authentication parameters that you would like to add
+    "scope": "openid",
+    "state": "YOUR_STATE"
+  }
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/passwordless/start' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "connection":"email|sms", "email":"USER_EMAIL", "phone_number":"USER_PHONE_NUMBER", "send":"link|code", "authParams":{"scope": "openid","state": "YOUR_STATE"}}'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/passwordless/start",
+  "link": "#get-code-or-link"
+}) %>
+
+You have three options for [passwordless authentication](/connections/passwordless):
+
+- Send a verification code using email.
+- Send a link using email.
+- Send a verification code using SMS.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+| `client_assertion` 
    | A JWT containing containing a signed assertion with your applications credentials. Required when Private Key JWT is your application authentication method. |
+|`client_assertion_type`| Use the value `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | The `client_secret` of your application. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. Specifically required for Regular Web Applications **only**. |
+| `connection` 
    Required | How to send the code/link to the user. Use `email` to send the code/link using email, or `sms` to use SMS. |
+| `email` | Set this to the user's email address, when `connection=email`. |
+| `phone_number` | Set this to the user's phone number, when `connection=sms`. |
+| `send` | Use `link` to send a link or `code` to send a verification code. If null, a link will be sent. |
+| `authParams` | Use this to append or override the link parameters (like `scope`, `redirect_uri`, `protocol`, `response_type`), when you send a link using email. |
+
+
+### Remarks
+
+- If you sent a verification code, using either email or SMS, after you get the code, you have to authenticate the user using the [/passwordless/verify endpoint](#authenticate-user), using `email` or `phone_number` as the `username`, and the verification code as the `password`.
+- This endpoint is designed to be called from the client-side, and is subject to [rate limits](/policies/rate-limit-policy/authentication-api-endpoint-rate-limits).
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Error Codes
+
+For the complete error code reference for this endpoint refer to [Errors > POST /passwordless/start](#post-passwordless-start).
+
+### Learn More
+
+- [Passwordless Authentication](/connections/passwordless)
+- [Passwordless Best Practices](/connections/passwordless/best-practices)
+
+## Authenticate User
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/json
+{
+  "grant_type" : "http://auth0.com/oauth/grant-type/passwordless/otp",
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET", // for web applications
+  "otp": "CODE",
+  "realm": "email|sms" //email or sms
+  "username":"USER_EMAIL|USER_PHONE_NUMBER", // depends on which realm you chose
+  "audience" : "API_IDENTIFIER", // in case you need an access token for a specific API
+  "scope": "SCOPE",
+  "redirect_uri": "REDIRECT_URI"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/json' \
+  --data '{"grant_type":"http://auth0.com/oauth/grant-type/passwordless/otp", "client_id":"${account.clientId}", "client_secret":"CLIENT_SECRET", "otp":"CODE", "realm":"email|sms", "username":"USER_EMAIL|USER_PHONE_NUMBER", "audience":"API_IDENTIFIER", "scope":"SCOPE", "redirect_uri": "REDIRECT_URI"}'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#authenticate-user"
+}) %>
+
+
+Once you have a verification code, use this endpoint to login the user with their phone number/email and verification code.
+
+### Request Parameters
+
+| Parameter        |Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | It should be `http://auth0.com/oauth/grant-type/passwordless/otp`. |
+| `client_id` 
    Required | The `client_id` of your application. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | The `client_secret` of your application. Required** when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`.  Specifically required for Regular Web Applications **only**. |
+| `username` 
    Required | The user's phone number if `realm=sms`, or the user's email if `realm=email`. |
+| `realm` 
    Required | Use `sms` or `email` (should be the same as [POST /passwordless/start](#get-code-or-link)) |
+| `otp` 
    Required | The user's verification code.  |
+| `audience` | API Identifier of the API for which you want to get an Access Token. |
+| `scope` | Use `openid` to get an ID Token, or `openid profile email` to also include user profile information in the ID Token. |
+| `redirect_uri` 
    Required | A callback URL that has been registered with your application's **Allowed Callback URLs**. |
+
+### Error Codes
+
+For the complete error code reference for this endpoint refer to [Standard Error Responses](#standard-error-responses). 
+
+### Learn More
+
+- [Passwordless Authentication](/connections/passwordless)
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/passwordless/verify",
+  "link": "#authenticate-user-legacy"
+}) %>
+
+::: warning
+This feature is disabled by default for new tenants as of 8 June 2017. Please see [Application Grant Types](/applications/concepts/application-grant-types) for more information.
+:::
+
+Once you have a verification code, use this endpoint to login the user with their phone number/email and verification code. This is active authentication, so the user must enter the code in your app.
+
+### Request Parameters
+
+| Parameter        |Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+| `connection` 
    Required | Use `sms` or `email` (should be the same as [POST /passwordless/start](#get-code-or-link)) |
+| `grant_type` 
    Required | Use `password` |
+| `username` 
    Required | The user's phone number if `connection=sms`, or the user's email if `connection=email`. |
+| `password` 
    Required | The user's verification code.  |
+| `scope` | Use `openid` to get an ID Token, or `openid profile email` to include also user profile information in the ID Token. |
+
+### Remarks
+
+- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`.
+- The `email` scope value requests access to the `email` and `email_verified` Claims.
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+### Error Codes
+
+For the complete error code reference for this endpoint refer to [Errors > POST /passwordless/verify](#post-passwordless-verify).
+
+### Learn More
+
+- [Passwordless Best Practices](/connections/passwordless/best-practices)
+
diff --git a/ja-jp/articles/api/authentication/_saml-sso.md b/ja-jp/articles/api/authentication/_saml-sso.md
new file mode 100644
index 0000000000..0769a51318
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_saml-sso.md
@@ -0,0 +1,120 @@
+# SAML
+
+The SAML protocol is used mostly for third-party SaaS applications, like Salesforce and Box. Auth0 supports Service Provider (SP) and Identity Provider (IDP) initiated Sign On. To learn more, see [SAML](/protocols/saml).
+
+## Accept Request
+
+```http
+GET https://${account.namespace}/samlp/${account.clientId}?
+  connection=CONNECTION
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/samlp/${account.clientId}' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data '"connection"="CONNECTION"'
+```
+
+<% var acceptReqPath = '/samlp/YOUR_CLIENT_ID'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": acceptReqPath,
+  "link": "#accept-request"
+}) %>
+
+Use this endpoint to accept a SAML request to initiate a login.
+
+Optionally, you can include a `connection` parameter to log in with a specific provider. If no connection is specified, the [Auth0 Login Page](/authenticate/login/auth0-universal-login) will be shown.
+
+Optionally, SP-initiated login requests can include an `organization` parameter to authenticate users in the context of an organization. To learn more, see [Organizations](/organizations).
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Client ID of your application. |
+| `connection`     | Connection to use during login. |
+| `organization`   | Organization ID, if authenticating in the context of an organization. |
+
+
+### Remarks
+
+- All the parameters of the SAML response can be modified with [Rules](/rules).
+- The SAML request `AssertionConsumerServiceURL` will be used to `POST` back the assertion. It must match one of the application's `callback_URLs`.
+
+### Learn More
+- [SAML](/protocols/saml)
+
+## Get Metadata
+
+```http
+GET https://${account.namespace}/samlp/metadata/${account.clientId}
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/samlp/metadata/${account.clientId}'
+```
+
+<% var getMetadataPath = '/samlp/metadata/YOUR_CLIENT_ID'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": getMetadataPath,
+  "link": "#get-metadata"
+}) %>
+
+This endpoint returns the SAML 2.0 metadata.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+
+
+### Learn More
+- [SAML](/protocols/saml)
+
+
+## IdP-Initiated Single Sign-On (SSO) Flow
+
+```http
+POST https://${account.namespace}/login/callback?connection=CONNECTION
+Content-Type: 'application/x-www-form-urlencoded'
+  SAMLResponse=SAML_RESPONSE
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/login/callback' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data '"connection":"CONNECTION", "SAMLResponse":"SAML_RESPONSE"'
+```
+
+<% var idpInitPath = '/login/callback'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": idpInitPath,
+  "link": "#idp-initiated-sso-flow"
+}) %>
+
+This endpoint accepts an IdP-Initiated Sign On SAMLResponse from a SAML Identity Provider. The connection corresponding to the identity provider is specified in the query string. The user will be redirected to the application that is specified in the SAML Provider IdP-Initiated Sign On section.
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `connection` 
    Required | The name of an identity provider configured to your application. |
+| `SAMLResponse` 
    Required | An IdP-Initiated Sign On SAML Response. |
+
+### Learn More
+- [SAML](/protocols/saml)
diff --git a/ja-jp/articles/api/authentication/_sign-up.md b/ja-jp/articles/api/authentication/_sign-up.md
new file mode 100644
index 0000000000..46e637c7bd
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_sign-up.md
@@ -0,0 +1,111 @@
+# Signup
+
+
+```http
+POST https://${account.namespace}/dbconnections/signup
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "email": "EMAIL",
+  "password": "PASSWORD",
+  "connection": "CONNECTION",
+  "username": "johndoe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "name": "John Doe",
+  "nickname": "johnny",
+  "picture": "http://example.org/jdoe.png"
+  "user_metadata": { plan: 'silver', team_id: 'a111' }
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/dbconnections/signup' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "email":"test.account@signup.com", "password":"PASSWORD", "connection":"CONNECTION", "username": "johndoe", "given_name": "John", "family_name": "Doe", "name": "John Doe", "nickname": "johnny", "picture": "http://example.org/jdoe.png", "user_metadata":{ "plan": "silver", "team_id": "a111" }}'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+> RESPONSE SAMPLE:
+
+```json
+{
+  "_id": "58457fe6b27...",
+  "email_verified": false,
+  "email": "test.account@signup.com",
+  "username": "johndoe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "name": "John Doe",
+  "nickname": "johnny",
+  "picture": "http://example.org/jdoe.png"
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/dbconnections/signup",
+  "link": "#signup"
+}) %>
+
+Given a user's credentials and a `connection`, this endpoint creates a new user.
+
+This endpoint only works for database connections. 
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` | The `client_id` of your client. |
+| `email` 
    Required | The user's email address. |
+| `password` 
    Required | The user's desired password. |
+| `connection` 
    Required | The name of the database configured to your client. |
+| `username` | The user's username. Only valid if the connection requires a username. |
+| `given_name` | The user's given name(s). |
+| `family_name` | The user's family name(s). |
+| `name` | The user's full name. |
+| `nickname` | The user's nickname. |
+| `picture` | A URI pointing to the user's picture. |
+| `user_metadata` | The [user metadata](/users/concepts/overview-user-metadata) to be associated with the user. If set, the field must be an object containing no more than ten properties. Property names can have a maximum of 100 characters, and property values must be strings of no more than 500 characters. |
+
+
+### Remarks
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+
+### Learn More
+
+- [Password Strength in Auth0 Database Connections](/connections/database/password-strength)
+- [Password Options in Auth0 Database Connections](/connections/database/password-options)
+- [Adding Username for Database Connections](/connections/database/require-username)
+- [Metadata Overview](/users/concepts/overview-user-metadata)
diff --git a/ja-jp/articles/api/authentication/_userinfo.md b/ja-jp/articles/api/authentication/_userinfo.md
new file mode 100644
index 0000000000..f21daa73ff
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_userinfo.md
@@ -0,0 +1,106 @@
+# User Profile
+## Get User Info
+
+```http
+GET https://${account.namespace}/userinfo
+Authorization: 'Bearer {ACCESS_TOKEN}'
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/userinfo' \
+  --header 'Authorization: Bearer {ACCESS_TOKEN}' \
+  --header 'Content-Type: application/json'
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+> RESPONSE SAMPLE:
+
+```json
+{
+  "sub": "248289761001",
+  "name": "Jane Josephine Doe",
+  "given_name": "Jane",
+  "family_name": "Doe",
+  "middle_name": "Josephine",
+  "nickname": "JJ",
+  "preferred_username": "j.doe",
+  "profile": "http://exampleco.com/janedoe",
+  "picture": "http://exampleco.com/janedoe/me.jpg",
+  "website": "http://exampleco.com",
+  "email": "janedoe@exampleco.com",
+  "email_verified": true,
+  "gender": "female",
+  "birthdate": "1972-03-31",
+  "zoneinfo": "America/Los_Angeles",
+  "locale": "en-US",
+  "phone_number": "+1 (111) 222-3434",
+  "phone_number_verified": false,
+  "address": {
+    "country": "us"
+  },
+  "updated_at": "1556845729"
+}
+```
+
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/userinfo",
+  "link": "#get-user-info"
+}) %>
+
+Given the Auth0 Access Token obtained during login, this endpoint returns a user's profile.
+
+This endpoint will work only if `openid` was granted as a scope for the Access Token. The user profile information included in the response depends on the scopes requested. For example, a scope of just `openid` may return less information than a scope of `openid profile email`.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `access_token` 
    Required | The Auth0 Access Token obtained during login. |
+
+
+### Remarks
+
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+- The auth0.js `parseHash` method, requires that your tokens are signed with `RS256`, rather than `HS256`.
+- To return `user_metadata` or other custom information from this endpoint, add a custom claim to the ID token with an [Action](/secure/tokens/json-web-tokens/create-custom-claims#create-custom-claims). For more information refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits:
+  - `X-RateLimit-Limit`: Number of requests allowed per minute.
+  - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time.
+  - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time).
+- The `Email` claim returns a snapshot of the email at the time of login
+- Standard claims (other than `email`) return the latest value (unless the value comes from an external IdP)
+- Custom claims always returns the latest value of the claim
+- To access the most up-to-date values for the `email` or custom claims, you must get new tokens. You can log in using silent authentication (where the `prompt` parameter for your call to the [`authorize` endpoint](/api/authentication#authorization-code-grant) equals `none`)
+- To access the most up-to-date values for standard claims that were changed using an external IdP (for example, the user changed their email address in Facebook)., you must get new tokens. Log in again using the external IdP, but *not* with silent authentication.
+
+### Learn More
+
+- [Auth0.js v8 Reference: Extract the authResult and get user info](/libraries/auth0js#extract-the-authresult-and-get-user-info)
+
+- [Auth0 API Rate Limit Policy](/policies/rate-limits)
diff --git a/ja-jp/articles/api/authentication/_wsfed-req.md b/ja-jp/articles/api/authentication/_wsfed-req.md
new file mode 100644
index 0000000000..c8e94025b2
--- /dev/null
+++ b/ja-jp/articles/api/authentication/_wsfed-req.md
@@ -0,0 +1,68 @@
+# WS-Federation
+## Accept Request
+
+```http
+GET https://${account.namespace}/wsfed/${account.clientId}
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/wsfed/${account.clientId}'
+```
+
+<% var acceptWSReqPath = '/wsfed/YOUR_CLIENT_ID'; %>
+<%= include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": acceptWSReqPath,
+  "link": "#accept-request20"
+}) %>
+
+This endpoint accepts a WS-Federation request to initiate a login.
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client-id`      | The `client-id` of your application. |
+| `wtrealm`        | Can be used in place of `client-id`. |
+| `whr`            | The name of the connection (used to skip the login page). |
+| `wctx`           | Your application's state. |
+| `wreply`         | The callback URL. |
+
+### Remarks
+
+- The `wtrealm` parameter must be in one of these formats:
+  - `urn:clientID` (for example, urn:${account.clientId})
+  - If this parameter does not begin with a urn, the `client.clientAliases` array is used for look-up. This can only be set with the [/api/v2/clients](/api/management/v2#!/Clients/get_clients) Management API.
+- The `whr` parameter is mapped to the connection like this: `urn:CONNECTION_NAME`. For example, `urn:google-oauth2` indicates login with Google. If there is no `whr` parameter included, the user will be directed to the [Auth0 Login Page](/login_page).
+
+### Learn More
+- [WS-Federation](/protocols/ws-fed)
+
+## Get Metadata
+
+```http
+GET https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml
+```
+
+```shell
+curl --request GET \
+  --url 'https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml'
+```
+
+<% var getMetadataPath = '/wsfed/FederationMetadata/2007-06/FederationMetadata.xml'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": getMetadataPath,
+  "link": "#get-metadata21"
+}) %>
+
+This endpoint returns the WS-Federation metadata.
+
+### Learn More
+
+- [WS-Federation](/protocols/ws-fed)
diff --git a/ja-jp/articles/api/authentication/api-authz/_auth-code-flow.md b/ja-jp/articles/api/authentication/api-authz/_auth-code-flow.md
new file mode 100644
index 0000000000..2a3e3d4f27
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_auth-code-flow.md
@@ -0,0 +1,120 @@
+# Authorization Code Flow
+## Authorize
+
+```http
+GET https://${account.namespace}/authorize?
+  audience=API_IDENTIFIER&
+  scope=SCOPE&
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  state=STATE
+```
+
+> RESPONSE SAMPLE
+
+```text
+HTTP/1.1 302 Found
+Location: ${account.callback}?code=AUTHORIZATION_CODE&state=STATE
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#authorization-code-grant"
+}) %>
+
+This is the OAuth 2.0 grant that regular web apps utilize in order to access an API.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `audience` 
     | The unique identifier of the target API you want to access. |
+| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. |
+| `response_type` 
    Required | Indicates to Auth0 which OAuth 2.0 flow you want to use. Use `code` for Authorization Code Grant Flow. |
+| `client_id` 
    Required | Your application's ID. |
+| `state` 
    Recommended | An opaque value the application adds to the initial request that Auth0 includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. |
+| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. |
+| `connection` | The name of the connection configured to your application. |
+| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). |
+| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. |
+| `invitation` | 	Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. |
+
+## Get Token
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=authorization_code&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'grant_type=authorization_code&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'authorization_code',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET',
+     code: 'AUTHORIZATION_CODE',
+     redirect_uri: '${account.callback}' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "refresh_token":"GEbRxBN...edjnXbL",
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#authorization-code"
+}) %>
+
+This is the flow that regular web apps use to access an API. Use this endpoint to exchange an Authorization Code for a token.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For Authorization Code, use `authorization_code`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_secret` 
    Required | Your application's Client Secret. |
+| `code` 
    Required | The Authorization Code received from the initial `/authorize` call. |
+| `redirect_uri`| This is required only if it was set at the [GET /authorize](#authorization-code-grant) endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. |
+
+### Learn More
+
+- [Authorization Code Flow](/flows/concepts/auth-code)
+- [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code)
+- [State Parameter](/protocols/oauth2/oauth-state)
+- [Silent Authentication](/api-auth/tutorials/silent-authentication)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_auth-code-pkce.md b/ja-jp/articles/api/authentication/api-authz/_auth-code-pkce.md
new file mode 100644
index 0000000000..23edc9a190
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_auth-code-pkce.md
@@ -0,0 +1,126 @@
+# Authorization Code Flow with PKCE
+## Authorize
+
+```http
+GET https://${account.namespace}/authorize?
+  audience=API_IDENTIFIER&
+  scope=SCOPE&
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  code_challenge=CODE_CHALLENGE&
+  code_challenge_method=S256
+```
+
+> RESPONSE SAMPLE
+
+```text
+HTTP/1.1 302 Found
+Location: ${account.callback}?code=AUTHORIZATION_CODE
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#authorization-code-grant-pkce-"
+}) %>
+
+This is the OAuth 2.0 grant that mobile apps utilize in order to access an API. Before starting with this flow, you need to generate and store a `code_verifier`, and using that, generate a `code_challenge` that will be sent in the authorization request.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `audience` 
     | The unique identifier of the target API you want to access. |
+| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. |
+| `response_type` 
    Required | Indicates to Auth0 which OAuth 2.0 Flow you want to perform. Use `code` for Authorization Code Grant (PKCE) Flow. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `state` 
    Recommended | An opaque value the client adds to the initial request that Auth0 includes when redirecting back to the client. This value must be used by the client to prevent CSRF attacks. |
+| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. |
+| `code_challenge_method` 
    Required | Method used to generate the challenge. The PKCE spec defines two methods, `S256` and `plain`, however, Auth0 supports only `S256` since the latter is discouraged. |
+| `code_challenge` 
    Required | Generated challenge from the `code_verifier`. |
+| `connection` | The name of the connection configured to your application. |
+| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). |
+| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. |
+| `invitation` | Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. |
+
+## Get Token
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=authorization_code&client_id=${account.clientId}&code_verifier=CODE_VERIFIER&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'grant_type=authorization_code&client_id=${account.clientId}&code_verifier=CODE_VERIFIER&code=AUTHORIZATION_CODE&redirect_uri=${account.callback}'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form: {
+    grant_type:"authorization_code",
+    client_id: "${account.clientId}",
+    code_verifier: "CODE_VERIFIER",
+    code: "AUTHORIZATION_CODE",
+    redirect_uri: "${account.callback}", } };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "refresh_token":"GEbRxBN...edjnXbL",
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#authorization-code-pkce-"
+}) %>
+
+This is the flow that mobile apps use to access an API. Use this endpoint to exchange an Authorization Code for a token.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For Authorization Code (PKCE) use  `authorization_code`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `code` 
    Required | The Authorization Code received from the initial `/authorize` call. |
+| `code_verifier` 
    Required | Cryptographically random key that was used to generate the `code_challenge` passed to `/authorize`. |
+| `redirect_uri` | This is required only if it was set at the [GET /authorize](#authorization-code-grant-pkce-) endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. |
+
+### Remarks
+
+- In order to improve compatibility for applications, Auth0 will now return profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID tokens or access tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims.
+- Include `offline_access` to the `scope` request parameter to get a refresh token from [POST /oauth/token](#authorization-code-pkce-). Make sure that the **Allow Offline Access** field is enabled in the [API Settings](${manage_url}/#/apis).
+- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications).
+- Silent authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. When an Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's Single Sign-on (SSO) session has not expired.
+
+### Learn More
+- [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+- [Call API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce)
+- [Silent Authentication](/api-auth/tutorials/silent-authentication)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_authz-client.md b/ja-jp/articles/api/authentication/api-authz/_authz-client.md
new file mode 100644
index 0000000000..4979eff892
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_authz-client.md
@@ -0,0 +1,25 @@
+# Authorize Application
+
+To begin an OAuth 2.0 Authorization flow, your application should first send the user to the authorization URL.
+
+## Authorize endpoint
+The purpose of this call is to obtain consent from the user to invoke the API (specified in `audience`) and do certain things (specified in `scope`) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given. If you alter the value in `scope`, Auth0 will require consent to be given again.
+
+The OAuth 2.0 flows that require user authorization are:
+- [Authorization Code Flow](/flows/concepts/auth-code)
+- [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+- [Implicit Flow](/flows/concepts/implicit)
+
+The [Resource Owner Password Grant](/api-auth/grant/password) and [Client Credentials Flow](/flows/concepts/client-credentials) do not use this endpoint since there is no user authorization involved. Instead, they directly invoke the `POST /oauth/token` endpoint to retrieve an Access Token.
+
+Based on the OAuth 2.0 flow you are implementing, the parameters slightly change. To determine which flow is best suited for your case, refer to: [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use).
+
+## Get Token
+For token-based authentication, use the `oauth/token` endpoint to get an access token for your application to make authenticated calls to a secure API. Optionally, you can also retrieve an ID Token and a Refresh Token. ID Tokens contains user information in the form of scopes you application can extract to provide a better user experience. Refresh Tokens allow your application to request a new access token once the current token expires without interruping the user experience.  To learn more, read [ID Tokens](https://auth0.com/docs/secure/tokens/id-tokens) and [Refresh Tokens](https://auth0.com/docs/secure/tokens/refresh-tokens).
+
+Note that the only OAuth 2.0 flows that can retrieve a Refresh Token are:
+- [Authorization Code Flow (Authorization Code)](/flows/concepts/auth-code)
+- [Authorization Code Flow with PKCE (Authorization Code with PKCE)](/flows/concepts/auth-code-pkce)
+- [Resource Owner Password](/api-auth/grant/password)
+- [Device Authorization Flow](/flows/concepts/device-auth)
+- Token Exchange\*
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_client-credential.md b/ja-jp/articles/api/authentication/api-authz/_client-credential.md
new file mode 100644
index 0000000000..99de17f1d3
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_client-credential.md
@@ -0,0 +1,73 @@
+# Client Credential Flow
+## Get Token
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+audience=API_IDENTIFIER&grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'audience=API_IDENTIFIER&grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET',
+     audience: 'API_IDENTIFIER',
+     grant_type: 'client_credentials' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#client-credentials"
+}) %>
+
+This is the OAuth 2.0 grant that server processes use to access an API. Use this endpoint to directly request an access token by using the application's credentials (a Client ID and a Client Secret).
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For Client Credentials use `client_credentials`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_secret` 
    Required | Your application's Client Secret. |
+| `audience` 
    Required | The unique identifier of the target API you want to access. |
+
+### Learn More
+
+- [Client Credentials Flow](/flows/concepts/client-credentials)
+- [Call API using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+- [Setting up a Client Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard)
+- [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_device-code.md b/ja-jp/articles/api/authentication/api-authz/_device-code.md
new file mode 100644
index 0000000000..11a26b9470
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_device-code.md
@@ -0,0 +1,186 @@
+# Device Authorization Flow
+## Authorize
+
+```http
+POST https://${account.namespace}/oauth/device/code
+Content-Type: application/x-www-form-urlencoded
+
+client_id=${account.clientId}&scope=SCOPE&audience=API_IDENTIFIER
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/device/code' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'client_id=${account.clientId}&scope=SCOPE&audience=API_IDENTIFIER'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/device/code',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { client_id: '${account.clientId}',
+     scope: 'SCOPE',
+     audience: 'API_IDENTIFIER' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "device_code":"GmRh...k9eS",
+  "user_code":"WDJB-MJHT",
+  "verification_uri":"https://${account.namespace}/device",
+  "verification_uri_complete":"https://${account.namespace}/device?user_code=WDJB-MJHT",
+  "expires_in":900, //in seconds
+  "interval":5
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/oauth/device/code",
+  "link": "#device-code"
+}) %>
+
+This is the flow that input-constrained devices use to access an API. Use this endpoint to get a device code. To begin the [Device Authorization Flow](/flows/concepts/device-auth), your application should first request a device code.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `audience` 
     | The unique identifier of the target API you want to access. |
+| `scope` | The scopes for which you want to request authorization. These must be separated by a space. You can request any of the [standard OIDC scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. |
+| `client_id` 
    Required | Your application's ID. |
+
+### Response Values
+
+| Value                        | Description |
+|:-----------------------------|:------------|
+| `device_code` | The unique code for the device. When the user visits the `verification_uri` in their browser-based device, this code will be bound to their session. |
+| `user_code` | The code that the user should input at the `verification_uri` to authorize the device. |
+| `verification_uri` | The URL the user should visit to authorize the device. |
+| `verification_uri_complete` | The complete URL the user should visit to authorize the device. Your app can use this value to embed the `user_code` in the URL, if you so choose. |
+| `expires_in` | The lifetime (in seconds) of the `device_code` and `user_code`. |
+| `interval` | The interval (in seconds) at which the app should poll the token URL to request a token. |
+
+### Remarks
+
+- Include `offline_access` to the `scope` request parameter to get a Refresh Token from [POST /oauth/token](#device-auth). Make sure that the **Allow Offline Access** field is enabled in the [API Settings](${manage_url}/#/apis).
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+client_id=${account.clientId}&device_code=YOUR_DEVICE_CODE&grant_type=urn:ietf:params:oauth:grant-type:device_code
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'client_id=${account.clientId}&device_code=YOUR_DEVICE_CODE&grant_type=urn:ietf:params:oauth:grant-type:device_code'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { client_id: '${account.clientId}',
+     device_code: 'YOUR_DEVICE_CODE',
+     grant_type: 'urn:ietf:params:oauth:grant-type:device_code' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+   "access_token": "eyJz93a...k4laUWw",
+   "id_token": "eyJ...0NE",
+   "refresh_token": "eyJ...MoQ",
+   "scope": "...",
+   "expires_in": 86400,
+   "token_type": "Bearer"
+}
+```
+
+```JSON
+HTTP/1.1 403 Forbidden
+Content-Type: application/json
+ { 
+  // Can be retried
+  "error": "authorization_pending",
+  "error_description": "User has yet to authorize device code."
+ }
+```
+
+```JSON
+HTTP/1.1 429 Too Many Requests
+Content-Type: application/json
+ { 
+  // Can be retried
+  "error": "slow_down",
+  "error_description": "You are polling faster than the specified interval of 5 seconds."
+ }
+```
+
+```JSON
+HTTP/1.1 403 Forbidden
+Content-Type: application/json
+ { 
+    // Cannot be retried; transaction failed
+    "error": "access_denied|invalid_grant|...",
+    "error_description": "Failure: User cancelled the confirmation prompt or consent page; the code expired; there was an error."
+ }
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#device-auth"
+}) %>
+
+This is the OAuth 2.0 grant that input-constrained devices use to access an API. Poll this endpoint using the interval returned with your [device code](/api/authentication#get-device-code) to directly request an access token using the application's credentials (a Client ID) and a device code.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For Device Authorization, use `urn:ietf:params:oauth:grant-type:device_code`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `device_code` 
    Required | The device code previously returned from the [/oauth/device/code endpoint](/api/authentication#device-authorization-flow). |
+
+### Remarks
+- Because you will be polling this endpoint (using the `interval` from the initial response to determine frequency) while waiting for the user to go to the verification URL and enter their user code, you will likely receive at least one failure before receiving a successful response. See sample responses for possible responses.
+
+### Learn More
+
+- [Device Authorization Flow](/flows/concepts/device-auth)
+- [Call API using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth)
+- [Setting up a Device Code Grant using the Management Dashboard](/api-auth/config/using-the-auth0-dashboard)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_highly-regulated.md b/ja-jp/articles/api/authentication/api-authz/_highly-regulated.md
new file mode 100644
index 0000000000..0181295d99
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_highly-regulated.md
@@ -0,0 +1,233 @@
+
+# Authorization Code Flow with Enhanced Privacy Protection
+
+## Push Authorization Requests (PAR)
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/oauth/par",
+  "link": "##push-authorization-requests-par-"
+}) %>
+
+```http
+POST ${account.namespace}/oauth/par
+Content-Type: 'application/x-www-form-urlencoded'
+  audience={https://yourApi/}&
+  response_type=code|code id_token&
+  client_id={yourClientId}&
+  redirect_uri={https://yourApp/callback}&
+  state=STATE&
+  scope=openid|profile|email&
+  code_challenge=CODE_CHALLENGE&
+  code_challenge_method=S256&
+  nonce=NONCE&
+  connection=CONNECTION&
+  prompt=login|consent|none&
+  organisation=ORGANIZATION
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://{yourDomain}/oauth/par,
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form: {
+    audience: '{https://yourApi/}',
+    response_type: 'code|code id_token',
+    client_id: '{yourClientId}',
+    redirect_uri: '{https://yourApp/callback}',
+    state: 'STATE',
+    scope: 'openid|profile|email',
+    authorization_details: JSON.stringify([{ type: 'my_type' }]),
+    code_challenge: 'CODE_CHALLENGE',
+    code_challenge_method: 'S256',
+    nonce: 'NONCE',
+    connection: 'CONNECTION',
+    prompt: 'login|consent|none'
+    organisation: 'ORGANIZATION'
+    }
+};
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+
+```
+
+```shell
+curl --request POST \
+  --url 'https://{yourDomain}/oauth/par' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+--data 'audience={https://yourApi/}response_type=code|code id_token&client_id={yourClientId}&redirect_uri={https://yourApp/callback}&state=STATE&scope=openid|profile|email&authorization_details='[{"type":"my_type"}]'
+&code_challenge=CODE_CHALLENGE&code_challenge_method=S256&nonce=NONCE&connection=CONNECTION&prompt=login|consent|none&organisation=ORGANIZATION'
+
+```
+
+> RESPONSE SAMPLE:
+
+``` json
+/**
+If the request is successful, `/oauth/par` responds with a `JSON` object containing the `request_uri` property, which can be used at the authorization endpoint, and the `expires_in` value, which indicates the number of seconds the `request_uri` is valid. 
+*/
+
+HTTP/1.1 201 Created
+Content-Type: application/json
+
+{
+  "request_uri":
+    "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
+  "expires_in": 30
+}
+```
+
+::: note
+To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to [Auth0 Pricing](https://auth0.com/pricing) for details. 
+:::
+
+Authorization Code Flow with [Pushed Authorization Requests (PAR)](/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par) uses the `/oauth/par` endpoint to allow applications to send the authorization parameters usually sent in a `GET` request to `/authorize`. PAR uses a POST method from the backend to keep parameter values secure. The `/oauth/par` endpoint accepts all authorization parameters which can be proivided to `/authorize`. Assuming the call to the `/oauth/par` endpoint is valid, Auth0 will respond with a `redirect_uri` value that can be used as a parameter for the `/authorize` endpoint.
+
+Assuming the call to the `/oauth/par` endpoint is valid, Auth0 will respond with a `redirect_uri` value also used as a parameter for the `/authorize` endpoint. To learn more about configuring PAR, read [Configure Pushed Authorization Requests (PAR)](/get-started/applications/configure-par).
+
+### Request Parameters
+| Parameter        | Description |
+|:-----------------|:------------|
+|`authorization_details`| Requested permissions for each resource. Similar to scopes. To learn more, read [RAR reference documention](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar). |
+|`audience`| The unique identifier of the target API you want to access. |
+| `response_type` 
    Required | Specifies the token type. We recommend you use `code` to request an authorization code, or code `id_token` to receive an authorization code and a [detached signature](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature). |
+| `client_id` 
    Required | The `client_id` of your application. |
+| `redirect_uri` 
    Required | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. Specify the `redirect_uri` under your [Application's Settings](${manage_url}/#/applications).|
+| `state` 
    Recommended | An opaque value the application adds to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks. |
+| `scope` 
    Recommended| OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a refresh token.|
+| `code_challenge` 
    Recommended | OIDC scopes and custom API scopes. For example: `openid read:timesheets`. Include `offline_access` to get a refresh token. |
+| `code_challenge_method` 
    Recommended | Method used to generate the challenge. The PKCE specification defines two methods, `S256` and plain, however, Auth0 supports only S256 since the latter is discouraged. [Authorization Code Flow with Proof Key for Code Exchange (PKCE)] (/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).|
+| `nonce` 
    Recommended | A string value which will be included in the ID token response from Auth0, used to prevent token replay attacks. It is required for `response_type=id_token` token. |
+| `connection` | The name of the connection configured to your application. If null, it will redirect to the [Auth0 Login Page](https://${account.namespace}/login) and show the Login Widget using the first database connection. |
+| `prompt` | Can be used to force a particular prompt to display, e.g. `prompt=consent` will always display the consent prompt.|
+| `organization` | ID of the organization to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. |
+
+### Remarks
+- To make a call to the PAR endpoint, you must:
+  - Set the request content type as `application/x-www-form-urlencoded`
+  - Use `strings` for all passed parameters
+  - Include an additional parameter for application authentication in the request (e.g. `client_secret`, or `client_assertion` and `client_assertion_type` for JSON Web Token Client Authentication, or pass a `client-certificate` and `client-certificate-ca-verified` header when using Mutual TLS).
+- Use the `authorization_details` parameter to request permission for each resource. For example, you can specify an array of JSON objects to convey fine-grained information on the authorization. Each JSON object must contain a `type` attribute. The rest is up to you to define.
+
+## Authorize
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#redirect-from-par-to-authorize"
+}) %>
+
+```http
+GET https://{yourDomain}/authorize
+  request_uri={yourRequestUri}&
+  client_id={yourClientId}
+```
+
+After calling the `/oauth/par` endpoint, redirect the end user to the `/authorize` endpoint using a `GET` call.
+
+:::note
+The `/authorize` endpoint will respond based on the parameters passed to the `/oauth/par` endpoint. If you request a `response_type`, you should receive an authorization code to use at the `/oauth/token` endpoint.
+:::
+
+### Request Parameters
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+| `request_uri` 
    Required | The `request_uri` value that was received from the `/oauth/par` endpoint. |
+ 
+## Exchange an Authorization Code for a Token
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#exchange-an-authorization-code-for-a-token"
+}) %>
+
+```http
+POST https://{yourDomain}/oauth/par
+Content-Type: 'application/x-www-form-urlencoded'
+  grant_type=code|code id_token&
+  client_id={yourClientId}&
+  code=CODE&
+ redirect_uri={https://yourApp/callback}&
+ code_verifier=CODE_VERIFIER
+```
+
+```javascript
+curl --request POST \
+  --url 'https://{yourDomain}/oauth/par' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+--data 'grant_type=authorization_code& client_id={yourClientId}& code=CODE&redirect_uri={https://yourApp/callback}&code_verifier=CODE_VERIFIER'
+```
+
+```shell
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://{yourDomain}/oauth/token,
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form: { 
+    grant_type: 'authorization_code',
+    client_id: '{yourClientId}',
+    code: 'CODE',
+    redirect_uri: '{https://yourApp/callback}',
+    code_verifier: 'CODE_VERIFIER'
+    }
+};
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+``` json
+/**
+The `/oauth/token` endpoint will respond with a JSON object containing an `id_token` property, and potentially also a `refresh_token` if one was requested.
+*/
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+   "refresh_token":"GEbRxBN...edjnXbL",
+    "access_token":"eybRxBN...edjnXZQ",  
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400,
+  "authrorization_details":[
+    {
+      "type":"my_type",
+      "other_attributes_of_my_type":"value"}
+  ]
+},
+  
+  
+```
+
+When users are redirected back to your callback, you need to make a `POST` call to the `oauth/token` endpoint to exchange an authorization code for an access and/or an ID token.
+
+### Request Parameters
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow. Assuming you have an authorization code from the `/authorize` endpoint, use `authorization_code`. |
+| `code` | The authorization code from the initial `/authorize` call. |
+| `client_id` 
    Required | The `client_id` of your application. |
+| `request_uri` 
    Required | This is required only if it was set at the `GET` `/oauth/par` endpoint. The values from `/authorize` must match the value you set at `/oauth/token`. |
+| `code_verifier` 
    Recommended | Cryptographically random key used to generate the `code_challenge` passed to `/oauth/par`. If the `code_challenge` parameter is passed in the call to `/oauth/par`, this is required. |
+
+### Remarks
+
+To make a call to `/oauth/token` endpoint, you must:
+- Set the request content type as `application/x-www-form-urlencoded`
+- Use `strings` for all passed parameters
+- Include an additional parameter for application authentication in the request (e.g. `client_secret`, or `client_assertion` and `client_assertion_type` for JSON Web Token Client Authentication, or pass a `client-certificate` and `client-certificate-ca-verified` header when using Mutual TLS).
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_implicit.md b/ja-jp/articles/api/authentication/api-authz/_implicit.md
new file mode 100644
index 0000000000..a6bf10fdb7
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_implicit.md
@@ -0,0 +1,60 @@
+# Implicit Flow
+## Authorize
+
+```http
+GET https://${account.namespace}/authorize?
+  audience=API_IDENTIFIER&
+  scope=SCOPE&
+  response_type=token|id_token|id_token token&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  state=STATE&
+  nonce=NONCE
+```
+
+> RESPONSE SAMPLE
+
+```text
+HTTP/1.1 302 Found
+Location: ${account.callback}#access_token=TOKEN&state=STATE&token_type=TYPE&expires_in=SECONDS
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#implicit-grant"
+}) %>
+
+This is the OAuth 2.0 grant that web apps utilize in order to access an API.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `audience` 
     | The unique identifier of the target API you want to access. |
+| `scope` | The scopes which you want to request authorization for. These must be separated by a space. You can request any of the [standard OpenID Connect (OIDC) scopes](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) about users, such as `profile` and `email`. Custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). |
+| `response_type` 
    Required | This will specify the type of token you will receive at the end of the flow. Use `token` to get only an Access Token, `id_token` to get only an ID token (if you don't plan on accessing an API), or `id_token token` to get both an ID token and an Access Token. |
+| `client_id` 
    Required | Your application's ID. |
+| `state` 
    Recommended | An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. |
+| `redirect_uri` | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. |
+| `nonce` 
    Recommended | A string value which will be included in the ID token response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. |
+| `connection` | The name of the connection configured for your application. |
+| `prompt` | To initiate a [silent authentication](/api-auth/tutorials/silent-authentication) request, use `prompt=none` (To learn more, read the Remarks). |
+| `organization` | ID of the [organization](/organizations) to use when authenticating a user. When not provided, if your application is configured to **Display Organization Prompt**, the user will be able to enter the organization name when authenticating. |
+| `invitation` | Ticket ID of the organization invitation. When [inviting a member to an Organization](/organizations/invite-members), your application should handle invitation acceptance by forwarding the invitation and organization key-value pairs when the user accepts the invitation. |
+
+### Remarks
+
+- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications).
+- If `response_type=token`, after the user authenticates with the provider, this will redirect them to your application callback URL while passing the `access_token` in the address `location.hash`. This is used for Single-Page Apps and on Native Mobile SDKs.
+- The Implicit Grant does not support the issuance of Refresh Tokens. Use [Silent Authentication](/api-auth/tutorials/silent-authentication) instead.
+- In order to improve compatibility for applications, Auth0 will now return profile information in a [structured claim format as defined by the OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). This means that in order to add custom claims to ID tokens or Access Tokens, they must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims) to avoid possible collisions with standard OIDC claims.
+- Silent Authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page. When an Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's Single Sign-on (SSO) session has not expired.
+
+### Learn More
+
+- [Implicit Flow](/flows/concepts/implicit)
+- [State Parameter](/protocols/oauth2/oauth-state)
+- [Mitigate replay attacks when using the Implicit Grant](/api-auth/tutorials/nonce)
+- [Silent Authentication](/api-auth/tutorials/silent-authentication)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_refresh-token.md b/ja-jp/articles/api/authentication/api-authz/_refresh-token.md
new file mode 100644
index 0000000000..ebd8bbdba7
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_refresh-token.md
@@ -0,0 +1,72 @@
+# Refresh Token
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=refresh_token&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&refresh_token=YOUR_REFRESH_TOKEN
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'grant_type=refresh_token&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&refresh_token=YOUR_REFRESH_TOKEN'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'refresh_token',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET',
+     refresh_token: 'YOUR_REFRESH_TOKEN'}
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token": "eyJ...MoQ",
+  "expires_in": 86400,
+  "scope": "openid offline_access",
+  "id_token": "eyJ...0NE",
+  "token_type": "Bearer"
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#refresh-token"
+}) %>
+
+Use this endpoint to refresh an Access Token using the Refresh Token you got during authorization.
+
+## Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. To refresh a token, use  `refresh_token`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_secret` | Your application's Client Secret. Required when the **Token Endpoint Authentication Method** field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `refresh_token` 
    Required | The refresh token to use. |
+| `scope` | A space-delimited list of requested scope permissions. If not sent, the original scopes will be used; otherwise you can request a reduced set of scopes. Note that this must be URL encoded. |
+
+## Learn More
+
+- [Refresh Tokens](/tokens/concepts/refresh-tokens)
diff --git a/ja-jp/articles/api/authentication/api-authz/_resource-owner.md b/ja-jp/articles/api/authentication/api-authz/_resource-owner.md
new file mode 100644
index 0000000000..c8ce53f4ab
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_resource-owner.md
@@ -0,0 +1,96 @@
+# Resource Owner Password Flow
+## Get Token
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=password&username=USERNAME&password=PASSWORD&audience=API_IDENTIFIER&scope=SCOPE&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'grant_type=password&username=USERNAME&password=PASSWORD&audience=API_IDENTIFIER&scope=SCOPE&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'password',
+     username: 'USERNAME',
+     password: 'PASSWORD',
+     audience: 'API_IDENTIFIER',
+     scope: 'SCOPE',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#resource-owner-password"
+}) %>
+
+:::warning
+This flow should only be used from highly-trusted applications that **cannot do redirects**. If you can use redirect-based flows from your app, we recommend using the [Authorization Code Flow](#regular-web-app-login-flow) instead.
+:::
+
+This is the OAuth 2.0 grant that highly-trusted apps use to access an API. In this flow, the end-user is asked to fill in credentials (username/password), typically using an interactive form in the user-agent (browser). This information is sent to the backend and from there to Auth0. It is therefore imperative that the application is absolutely trusted with this information. For [single-page applications and native/mobile apps](/flows/concepts/auth-code-pkce), we recommend using web flows instead.
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `grant_type` 
    Required | Denotes the flow you are using. For Resource Owner Password use  `password`. To add realm support use `http://auth0.com/oauth/grant-type/password-realm`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `client_secret` | Your application's Client Secret. Required when the Token Endpoint Authentication Method field at your [Application Settings](${manage_url}/#/applications) is `Post` or `Basic`. |
+| `audience` | The unique identifier of the target API you want to access. |
+| `username` 
    Required | Resource Owner's identifier, such as a username or email address. |
+| `password` 
    Required | Resource Owner's secret. |
+| `scope` | String value of the different scopes the application is asking for. Multiple scopes are separated with whitespace. |
+| `realm` | String value of the realm the user belongs. Set this if you want to add realm support at this grant. For more information on what realms are refer to [Realm Support](/api-auth/grant/password#realm-support). |
+
+### Request headers
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `auth0-forwarded-for` | End-user IP as a string value. Set this if you want brute-force protection to work in server-side scenarios. For more information on how and when to use this header, refer to [Using resource owner password from server-side](/api-auth/tutorials/using-resource-owner-password-from-server-side). |
+
+### Remarks
+
+- The scopes issued to the application may differ from the scopes requested. In this case, a `scope` parameter will be included in the response JSON.
+- If you don't request specific scopes, all scopes defined for the audience will be returned due to the implied trust to the application in this grant. You can customize the scopes returned in a rule. For more information, refer to [Calling APIs from Highly Trusted Applications](/api-auth/grant/password).
+- To add realm support set the `grant_type` to `http://auth0.com/oauth/grant-type/password-realm`, and the `realm` to the realm the user belongs. This maps to a connection in Auth0. For example, if you have configured a database connection for your internal employees and you have named the connection `employees`, then use this value. For more information on how to implement this refer to: [Realm Support](/api-auth/tutorials/password-grant#realm-support).
+- In addition to username and password, Auth0 may also require the end-user to provide an additional factor as proof of identity before issuing the requested scopes. In this case, the request described above will return an `mfa_required` error along with an `mfa_token`. You can use these tokens to request a challenge for the possession factor and validate it accordingly. For details refer to [Resource Owner Password and MFA](#resource-owner-password-and-mfa).
+
+### Learn More
+- [Calling APIs from Highly-Trusted Applications](/api-auth/grant/password)
+- [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant)
+- [Multi-factor Authentication and Resource Owner Password](/mfa/guides/mfa-api/multifactor-resource-owner-password)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_revoke-refresh-token.md b/ja-jp/articles/api/authentication/api-authz/_revoke-refresh-token.md
new file mode 100644
index 0000000000..5f44c585e2
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_revoke-refresh-token.md
@@ -0,0 +1,79 @@
+# Revoke Refresh Token
+
+```http
+POST https://${account.namespace}/oauth/revoke
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+  "token": "YOUR_REFRESH_TOKEN",
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/revoke' \
+  --header 'content-type: application/json' \
+  --data '{ "client_id": "${account.clientId}", "client_secret": "YOUR_CLIENT_SECRET", "token": "YOUR_REFRESH_TOKEN" }'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/revoke',
+  headers: { 'content-type': 'application/json' },
+  body: 
+   { client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET',
+     token: 'YOUR_REFRESH_TOKEN' },
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+(empty-response-body)
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/revoke",
+  "link": "#revoke-refresh-token"
+}) %>
+
+Use this endpoint to invalidate a Refresh Token if it has been compromised.
+
+The behaviour of this endpoint depends on the state of the [Refresh Token Revocation Deletes Grant](https://auth0.com/docs/tokens/refresh-tokens/revoke-refresh-tokens#refresh-tokens-and-grants) toggle.
+If this toggle is enabled, then each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant. This means that **all Refresh Tokens that have been issued for the same user, application, and audience will be revoked**.
+If this toggle is disabled, then only the refresh token is revoked, while the grant is left intact.
+
+## Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+| `client_assertion`| A JWT containing a signed assertion with your application credentials. Required when Private Key JWT is the application authentication method.|
+| `client_assertion_type`| The value is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.  Required when Private Key JWT is the application authentication method.|
+| `client_secret` | The `client_secret` of your application. Required when Client Secret Basic or Client Secret Post is the application authentication method. Specifically required for Regular Web Applications **only**. |
+| `token` 
    Required | The Refresh Token you want to revoke. |
+
+## Remarks
+
+- For non-confidential applications that cannot keep the Client Secret safe (for example, native apps), the endpoint supports passing no Client Secret but the application itself must have the property `tokenEndpointAuthMethod` set to `none`. You can do this either from the UI ([Dashboard > Applications > Application Settings](${manage_url}/#/applications)) or using the [Management API](/api/management/v2#!/Applications/patch_applications_by_id).
+
+## Error Codes
+
+For the complete error code reference for this endpoint, refer to [Errors > POST /oauth/revoke](#post-oauth-revoke).
+
+## Learn More
+
+- [Refresh Tokens](/tokens/concepts/refresh-tokens)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/api-authz/_token-exchange-native-social.md b/ja-jp/articles/api/authentication/api-authz/_token-exchange-native-social.md
new file mode 100644
index 0000000000..e234380215
--- /dev/null
+++ b/ja-jp/articles/api/authentication/api-authz/_token-exchange-native-social.md
@@ -0,0 +1,89 @@
+# Token Exchange for Native Social
+
+```http
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=SUBJECT_TOKEN&subject_token_type=SUBJECT_TOKEN_TYPE&client_id=${account.clientId}&audience=API_IDENTIFIER&scope=SCOPE
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/token' \
+  --header 'content-type: application/x-www-form-urlencoded' \
+  --data 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=SUBJECT_TOKEN&subject_token_type=SUBJECT_TOKEN_TYPE&client_id=${account.clientId}&audience=API_IDENTIFIER&scope=SCOPE'
+ }'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange',
+     subject_token: 'SUBJECT_TOKEN',
+     subject_token_type: 'SUBJECT_TOKEN_TYPE',
+     client_id: '${account.clientId}',
+     audience: 'API_IDENTIFIER',
+     scope: 'SCOPE',
+   };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+HTTP/1.1 200 OK
+Content-Type: application/json
+{ 
+  "access_token": "eyJz93a...k4laUWw",
+  "id_token": "eyJ...0NE",
+  "refresh_token": "eyJ...MoQ",
+  "expires_in":86400,
+  "token_type":"Bearer"
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/token",
+  "link": "#token-exchange-native-social"
+}) %>
+
+:::warning
+This flow is intended for use with native social interactions **only**. Use of this flow outside of a native social setting is highly discouraged.
+:::
+
+When a non-browser-based solution (such as a mobile platform's SDK) authenticates the user, the authentication will commonly result in artifacts being returned to application code. In such situations, this grant type allows for the Auth0 platform to accept artifacts from trusted sources and issue tokens in response. In this way, apps making use of non-browser-based authentication mechanisms (as are common in native apps) can still retrieve Auth0 tokens without asking for further user interaction.
+
+Artifacts returned by this flow (and the contents thereof) will be determined by the `subject_token_type` and the tenant's configuration settings.
+
+## Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `auth0-forwarded-for` | End user IP as a string value. Set this if you want brute-force protection to work in server-side scenarios. To learn more about how and when to use this header, read [Using resource owner password from server-side](/api-auth/tutorials/using-resource-owner-password-from-server-side). |
+| `grant_type` 
    Required | Denotes the flow you are using. For Token Exchange for Native Social, use `urn:ietf:params:oauth:grant-type:token-exchange`. |
+| `subject_token` 
    Required | Externally-issued identity artifact representing the user. |
+| `subject_token_type` 
    Required | Identifier that indicates the type of `subject_token`. |
+| `client_id` 
    Required | Your application's Client ID. |
+| `audience` | The unique identifier of the target API you want to access. |
+| `scope` | String value of the different scopes the application is requesting. Multiple scopes are separated with whitespace. |
+| `user_profile` 
    Only For `apple-authz-code`  | Optional element used for native iOS interactions for which profile updates can occur.  Expected parameter value will be JSON in the form of: `{ name: { firstName: 'John', lastName: 'Smith }}` |
+
+## Remarks
+
+- The scopes issued to the application may differ from the requested scopes. In this case, a `scope` parameter will be included in the response JSON.
+- If you don't request specific scopes, all scopes defined for the audience will be returned due to the implied trust to the application in this grant. You can customize the scopes returned in a rule. To learn more, read [Calling APIs from Highly Trusted Applications](/api-auth/grant/password).
+
+## Learn More
+- [Add Sign In with Apple to Native iOS Apps](/connections/apple-siwa/add-siwa-to-native-app)
+- [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_errors.md b/ja-jp/articles/api/authentication/errors/_errors.md
new file mode 100644
index 0000000000..3b9163d8ae
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_errors.md
@@ -0,0 +1,21 @@
+# Standard Error Responses
+
+The Authentication API may return the following HTTP Status Codes:
+| Status            | JSON Response |
+| :---------------- | :------------ |
+| 400 Bad Request|`{"error": "invalid_request", "error_description": "..."}`|
+| 400 Bad Request| `{"error": "invalid_request", "error_description": "..."}`|
+| 400 Bad Request| `{"error": "invalid_scope", "error_description": "Scope must be an array or a string"}`|
+| 401 Unauthorized| `{"error": "invalid_client", "error_description": "..."}`|
+| 401 Unauthorized| `{"error": "requires_validation", "error_description": "Suspicious request requires verification"}`|
+| 403 Forbidden| `{"error": "unauthorized_client", "error_description": "..."}`|
+| 403 Forbidden| `{"error": "access_denied", "error_description": "..."}`|
+| 403 Forbidden| `{"error": "access_denied", "error_description": "Unknown or invalid refresh token"}`|
+| 403 Forbidden| `{"error": "invalid_grant", "error_description": "..."}`|
+| 404 Not Found| `{"error": "endpoint_disabled", "error_description": "..."}`|
+| 405 Method Not Allowed| `{"error": "method_not_allowed", "error_description": "..."}`|
+| 429 Too Many Requests| `{"error": "too_many_requests", "error_description": "..."}`|
+| 500 Internal Server Error |  |
+| 501 Not Implemented| `{"error": "unsupported_response_type", "error_description": "..."}`|
+| 501 Not Implemented| `{"error": "unsupported_grant_type", "error_description": "..."}`|
+| 503 Service Unavailable| `{"error": "temporarily_unavailable", "error_description": "..."}`|
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_oauth-access_token.md b/ja-jp/articles/api/authentication/errors/_oauth-access_token.md
new file mode 100644
index 0000000000..44b0f7541e
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_oauth-access_token.md
@@ -0,0 +1,10 @@
+# POST /oauth/access_token
+
+| Status           | JSON Response |
+| :--------------- |:------------- |
+| 400 Bad Request | `{"error": "invalid_request", "error_description": "the connection was disabled"}`
     The connection is not active or not enabled for your `client_id`.|
+| 400 Bad Request | `{"error": "invalid_request", "error_description": "the connection was not found"}` |
+| 400 Bad Request | `{"error": "invalid_request", "error_description": "missing client_id parameter"}` |
+| 400 Bad Request | `{"error": "invalid_request", "error_description": "missing access_token parameter"}` |
+| 401 Unauthorized | `{"error": "invalid_request", "error_description": "invalid access_token: invalid_token"}` 
     The `access_token` is invalid or does not contain the set `scope`|
+| 403 Forbidden | `{"error": "unauthorized_client", "error_description": "invalid client"}` |
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_oauth-revoke.md b/ja-jp/articles/api/authentication/errors/_oauth-revoke.md
new file mode 100644
index 0000000000..cbca1e2779
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_oauth-revoke.md
@@ -0,0 +1,7 @@
+# POST /oauth/revoke
+
+| Status           | JSON Response |
+| :--------------- | :------------ |
+|200 Success | `{"error": "invalid_request", "error_description": "..."}`
     The Refresh Token is revoked, does not exist, or was not issued to the client making the revocation request|
+|400 Bad Request | `{"error": "invalid_request", "error_description": "..."}` The required parameters were not sent in the request.|
+|401 Unauthorized  | `{"error": "invalid_client", "error_description": "..."}`
     The request is not authorized. Check that the client credentials `client_id` and client_secret` are present in the request and hold valid values. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_oauth-ro.md b/ja-jp/articles/api/authentication/errors/_oauth-ro.md
new file mode 100644
index 0000000000..e552af873a
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_oauth-ro.md
@@ -0,0 +1,34 @@
+# POST /oauth/ro
+
+## Grant type: jwt-bearer
+
+| Status           | JSON Response |
+| :----------------| :------------ |
+|400 Bad Request|`{"error": "invalid_request", "error_description": "missing device parameter"}` 
    You need to provide a device name for the caller device (like a browser, app, and so on) |
+|400 Bad Request|`{"error": "invalid_request", "error_description": "missing id_token parameter"}`
    For this grant type you need to provide a JWT ID Token |
+|400 Bad Request|`{"error": "invalid_grant", "error_description": "..."}` 
    Errors related to an invalid ID Token or user |
+
+## Grant type: password
+
+| Status           | JSON Response |
+| :----------------| :------------ |
+| 400 Bad Request|`{"error": "invalid_request", "error_description": "scope parameter must be a string"}`
     Incorrect scope formatting; each scope must be separated by whitespace|
+| 400 Bad Request|`{"error": "invalid_request", "error_description": "specified strategy does not support requested operation"}`
    The connection/provider does not implement username/password authentication |
+| 401 Unauthorized|`{"error": "invalid_user_password", "error_description": "Wrong email or password."}`|
+| 401 Unauthorized|`{"error": "unauthorized", "error_description": "user is blocked"}`|
+| 401 Unauthorized|`{ "error": "password_leaked", "error_description": "This login has been blocked because your password has been leaked in another website. We’ve sent you an email with instructions on how to unblock it."}`|
+| 401 Unauthorized|`{ "error": "requires_verification", "error_description": "Suspicious request requires verification" }`|
+| 429 Too Many Requests|`{"error": "too_many_attempts", "error_description": "..."}` 
    Some attack protection features will return this error|
+| 429 Too Many Requests|`{"error": "too_many_logins", "error_description": "..."}` 
    Some attack protection features will return this error|
+
+## All grant types
+
+| Status           | JSON Response |
+| :--------------- | :----------- |
+| 400 Bad Request |`{"error": "invalid_request", "error_description": "missing client_id parameter"}<`|
+| 400 Bad Request |`{"error": "invalid_request", "error_description": "the connection was disabled"}`
    Check the connection in the dashboard, you may have turned it off for the provided `client_id` |
+| 400 Bad Request |`{"error": "invalid_request", "error_description": "The connection is not yet configured..."}` 
    The connection is not properly configured with custom scripts|
+| 400 Bad Request |`{"error": "invalid_request", "error_description": "the connection was not found for tenant..."}`
    The connection does not belong to the tenant; check your base url |
+| 400 Bad Request |`{"error": "invalid_request", "error_description": "Fields with "." are not allowed, please remove all dotted fields..."}`
    If you are using rules, some field name contains dots |
+| 403 Forbidden |`{"error": "unauthorized_client", "error_description": "invalid client"}`
    The provided `client_id` is not valid |
+| 403 Forbidden |`{"error": "access_denied", "error_description": "..."}`
    Validation of specific points raised an access issue |
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_passwordless-start.md b/ja-jp/articles/api/authentication/errors/_passwordless-start.md
new file mode 100644
index 0000000000..348b707a16
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_passwordless-start.md
@@ -0,0 +1,25 @@
+
+# POST /passwordless/start
+
+| Status           | JSON Response |
+| :----------------| :------------ |
+|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - tenant validation failed: invalid_tenant"}`|
+|400 Bad Request|`{"error": "bad.client_id", "error_description": "Missing required property: client_id"}`|
+|400 Bad Request|`{"error": "bad.connection", "error_description": "Missing required property: connection"}`|
+|400 Bad Request|`{"error": "bad.connection", "error_description": "Connection does not exist"}`|
+|400 Bad Request|`{"error": "bad.connection", "error_description": "Connection is disabled"}`|
+|400 Bad Request|`{"error": "bad.connection", "error_description": "Invalid connection strategy. It must either be a passwordless connection"}`|
+|400 Bad Request|`{"error": "bad.authParams", "error_description": "error in authParams - invalid type: string (expected object)"}`|
+|400 Bad Request|`{"error": "bad.request", "error_description": "the following properties are not allowed: "}`|
+|400 Bad Request|`{"error": "bad.phone_number", "error_description": "Missing required property: phone_number"}`|
+|400 Bad Request|`{"error": "bad.phone_number", "error_description": "String does not match pattern: ^\\+[0-9]{1,15}$"}`|
+|400 Bad Request|`{"error": "sms_provider_error", "error_description": " (Code: )"}`|
+|400 Bad Request|`{"error": "invalid_request","error_description": "Expected `auth0-forwarded-for` header to be a valid IP address."}`|
+|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - could not find tenant in params"}`|
+|400 Bad Request|`{"error": "server_error","error_description": "error resolving client"}`|
+|400 Bad Request|`{"error": "invalid_request","error_description": "The client_id in the authentication header does not match the client_id in the payload"}`|
+|400 Bad Request|`{"error": "bad.connection","error_description": "Public signup is disabled"}`|
+|400 Bad Request|`{"error": "bad.connection","error_description": "Unknown error"}`|
+|401 Unauthorized|`{"error": "server_error","error_description": "user is blocked"}`|
+|403 Forbidden|`{"error": "unauthorized_client","error_description": "Client authentication is required"}`|
+|500 Internal Server Error|`{"error": "server_error","error_description": "IdP Error"}`|
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/errors/_passwordless-verify.md b/ja-jp/articles/api/authentication/errors/_passwordless-verify.md
new file mode 100644
index 0000000000..1ea71461b4
--- /dev/null
+++ b/ja-jp/articles/api/authentication/errors/_passwordless-verify.md
@@ -0,0 +1,22 @@
+# POST /passwordless/verify
+
+| Status           | JSON Response |
+| :----------------| :------------ |
+|400 Bad Request|`{"error": "invalid_request", "error_description": "missing username parameter"}`|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "scope parameter must be a string"}`
    Incorrect scope formatting; each scope must be separated by whitespace|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "missing client_id parameter"}`|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was not found"}`|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was disabled"}` 
    Check the connection in the dashboard, you may have turned it off for the provided `client_id`|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "the connection was not found for tenant..."}` 
    The connection does not belong to the tenant; check your base url|
+|400 Bad Request|`{"error": "invalid_request", "error_description": "Fields with "." are not allowed, please remove all dotted fields..."}`
    If you are using rules, some field name contains dots|
+|400 Bad Request|`"error": "bad.tenant","error_description": "error in tenant - could not find tenant in params"`|
+|400 Bad Request|`{"error": "bad.tenant","error_description": "error in tenant - tenant validation failed: "}`|
+|400 Bad Request|`{"error": "bad.connection","error_description": "Connection does not exist"}`|
+|400 Bad Request|`{"error": "bad.connection","error_description": "Invalid connection strategy. It must either be a passwordless connection"}`|
+|400 Bad Request|`{"error": "bad.connection","error_description": "The connection is disabled"}`|
+|401 Unauthorized|`{"error": "invalid_user_password", "error_description": "Wrong email or password."}`|
+|401 Unauthorized|`{"error": "unauthorized", "error_description": "user is blocked"}`|
+|403 Forbidden|`{"error": "unauthorized_client", "error_description": "invalid client"}`
    The provided `client_id` is not valid|
+|403 Forbidden|`{"error": "access_denied", "error_description": "..."}`
    Validation of specific points raised an access issue|
+|429 Too Many Requests|`{"error": "too_many_attempts", "error_description": "..."}` 
    Some attack protection features will return this error|
+|500 Bad Request|`{"error": "server_error","error_description": "..."}`|
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/index.md b/ja-jp/articles/api/authentication/index.md
new file mode 100644
index 0000000000..3edd4a539a
--- /dev/null
+++ b/ja-jp/articles/api/authentication/index.md
@@ -0,0 +1,128 @@
+---
+title: Authentication API Explorer
+fullWidth: true
+contentType: 
+    - index
+    - reference
+---
+
+
    
+  <%= include('./_introduction') %>
+
    
+
+
    
+  <%= include('./_login') %>
+
    
+
+
    
+  <%= include('./_logout') %>
+
    
+
+
    
+  <%= include('./_passwordless') %>
+
    
+
+
    
+  <%= include('./_sign-up') %>
+
    
+
+
    
+  <%= include('./_change-password') %>
+
    
+
+
    
+  <%= include('./_userinfo') %>
+
    
+
+
    
+  <%= include('./_multifactor-authentication') %>
+
    
+
+
    
+  <%= include('./_saml-sso') %>
+
    
+
+
    
+  <%= include('./_wsfed-req') %>
+
    
+
+
    
+  <%= include('./_application-reg') %>
+
    
+
+API Authorization
+
    
+  <%= include('./api-authz/_authz-client') %>
+
    
+
    
+  <%= include('./api-authz/_auth-code-flow') %>
+
    
+
    
+  <%= include('./api-authz/_auth-code-pkce') %>>
+
    
+
    
+  <%= include('./api-authz/_highly-regulated') %>>
+
    
+
    
+  <%= include('./api-authz/_client-credential') %>>
+
    
+
    
+  <%= include('./api-authz/_implicit') %>>
+
    
+
    
+  <%= include('./api-authz/_resource-owner.md') %>>
+
    
+
    
+  <%= include('./api-authz/_device-code') %>
+
    
+
    
+  <%= include('./api-authz/_refresh-token') %>
+
    
+
    
+<%= include('./api-authz/_revoke-refresh-token') %>
+
    
+
    
+<%= include('./api-authz/_token-exchange-native-social') %>
+
    
+
+Legacy
+
    
+  <%= include('./legacy/_login') %>
+
    
+
    
+  <%= include('./legacy/_userinfo') %>
+
    
+
    
+  <%= include('./legacy/_linking') %>
+
    
+
    
+  <%= include('./legacy/_delegation') %>
+
    
+
    
+  <%= include('./legacy/_impersonation') %>
+
    
+
    
+  <%= include('./legacy/_resource-owner') %>
+
    
+
+Errors
+
    
+ <%= include('./errors/_errors') %>
+
    
+
    
+ <%= include('./errors/_oauth-revoke') %>
+
    
+
    
+ <%= include('./errors/_oauth-access_token') %>
+
    
+
    
+<%= include('./errors/_oauth-ro') %>
+
    
+
    
+ <%= include('./errors/_passwordless-start') %>
+
    
+
    
+ <%= include('./errors/_passwordless-verify') %>
+
    
+
+
diff --git a/ja-jp/articles/api/authentication/legacy/_delegation.md b/ja-jp/articles/api/authentication/legacy/_delegation.md
new file mode 100644
index 0000000000..a173755d24
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_delegation.md
@@ -0,0 +1,73 @@
+# Delegation
+
+```http
+POST https://${account.namespace}/delegation
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
+  "id_token" or "refresh_token" : "TOKEN",
+  "target": "TARGET_CLIENT_ID",
+  "scope": "openid",
+  "api_type": "API_TYPE"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/delegation' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "grant_type":"urn:ietf:params:oauth:grant-type:jwt-bearer", "id_token|refresh_token":"TOKEN", "target":"TARGET_CLIENT_ID", "scope":"openid", "api_type":"API_TYPE"}'
+```
+
+```javascript
+// Delegation is not supported in version 8 of auth0.js.
+// For a version 7 sample refer to: https://auth0.com/docs/libraries/auth0js/v7#delegation-token-request
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/delegation",
+  "link": "#delegation"
+}) %>
+
+::: warning
+By default, this feature is disabled for tenants without an add-on in use as of 8 June 2017. Legacy tenants who currently use an add-on that requires delegation may continue to use this feature. If delegation functionality is changed or removed from service at some point, customers who currently use it will be notified beforehand and given ample time to migrate.
+:::
+
+A delegation token can be obtained and used when an application needs to call the API of an Application Addon, such as Firebase or SAP, registered and configured in Auth0, in the same tenant as the calling program.
+
+Given an existing token, this endpoint will generate a new token signed with the `target` app' secret. This is used to flow the identity of the user from the application to an API.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Τhe `client_id` of your app |
+| `grant_type` 
    Required | Use `urn:ietf:params:oauth:grant-type:jwt-bearer`|
+| `id_token` or `refresh_token` 
    Required | The existing token of the user. |
+| `target`        | The target `client_id` |
+| `scope`         | Use `openid` or `openid profile email` |
+| `api_type`       | The API to be called. |
+
+### Remarks
+
+- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`.
+
+- The `email` scope value requests access to the `email` and `email_verified` Claims.
+
+- Delegation is __not supported__ in version 8 of [auth0.js](/libraries/auth0js). For a sample in version 7 of the library, refer to [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request).
+
+- This endpoint limits up to 10 requests per minute from the same IP address with the same `user_id`.
+
+- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits:
+  - `X-RateLimit-Limit`: Number of requests allowed per minute.
+  - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time.
+  - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time).
+
+
+### Learn More
+
+- [Delegation Tokens](/tokens/delegation)
+- [Auth0 API Rate Limit Policy](/policies/rate-limits)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/legacy/_impersonation.md b/ja-jp/articles/api/authentication/legacy/_impersonation.md
new file mode 100644
index 0000000000..6fd286a04f
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_impersonation.md
@@ -0,0 +1,81 @@
+# Impersonation
+
+```http
+POST https://${account.namespace}/users/{user_id}/impersonate
+Content-Type:   application/json
+Authorization:  'Bearer {ACCESS_TOKEN}'
+{
+  protocol: "PROTOCOL",
+  impersonator_id: "IMPERSONATOR_ID",
+  client_id: "${account.clientId}",
+  additionalParameters: [
+    "response_type": "code",
+    "state": "STATE"
+  ]
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/users/{user_id}/impersonate' \
+  --header 'Authorization: Bearer {ACCESS_TOKEN}' \
+  --header 'content-type: application/x-www-form-urlencoded; charset=UTF-8' \
+  --data '{"protocol":"PROTOCOL", "impersonator_id":"IMPERSONATOR_ID", "client_id":"${account.clientId}", "additionalParameters": {"response_type": "code", "state": "STATE"}}'
+```
+
+```javascript
+var url = 'https://' + ${account.namespace} + '/users/' + localStorage.getItem('user_id') + '/impersonate';
+var params = 'protocol=PROTOCOL&impersonator_id=IMPERSONATOR_ID&client_id=${account.clientId}';
+
+var xhr = new XMLHttpRequest();
+
+xhr.open('POST', url);
+xhr.setRequestHeader('Content-Type', 'application/json');
+xhr.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('access_token'));
+
+xhr.onload = function() {
+  if (xhr.status == 200) {
+    fetchProfile();
+  } else {
+    alert("Request failed: " + xhr.statusText);
+  }
+};
+
+xhr.send(params);
+```
+
+> RESPONSE SAMPLE:
+
+```text
+https:/YOUR_DOMAIN/users/IMPERSONATOR_ID/impersonate?&bewit=WFh0MUtm...
+```
+
+<% var path = '/users/{user_id}/impersonate'; %>
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": path,
+  "link": "#impersonation"
+}) %>
+
+<%= include('../../../_includes/_deprecate-impersonation.md') %>
+
+Use this endpoint to obtain an impersonation URL to login as another user. Useful for troubleshooting.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `protocol` 
    Required | The protocol to use against the identity provider: `oauth2`, `samlp`, `wsfed`, `wsfed-rms`. |
+| `impersonator_id` 
    Required | The `user_id` of the impersonator. |
+| `client_id` 
    Required | The  `client_id` of the client that is generating the impersonation link.|
+| `additionalParameters` | This is a JSON object. You can use this to set additional parameters, like `response_type`, `scope` and `state`. |
+
+### Remarks
+
+- This endpoint can only be used with **Global Client** credentials.
+
+- To distinguish between real logins and impersonation logins, the profile of the impersonated user will contain additional impersonated and impersonator properties. For example: `"impersonated": true, "impersonator": {"user_id": "auth0|...", "email": "admin@example.com"}`.
+
+- For a regular web app, you should set the `additionalParameters`: set the `response_type` to be `code`, the `callback_url` to be the callback URL to which Auth0 will redirect with the authorization code, and the `scope` to be the JWT claims that you want included in the JWT.
diff --git a/ja-jp/articles/api/authentication/legacy/_linking.md b/ja-jp/articles/api/authentication/legacy/_linking.md
new file mode 100644
index 0000000000..0e4b6657ce
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_linking.md
@@ -0,0 +1,113 @@
+# Account Linking
+## Link
+
+::: warning
+This endpoint is **deprecated** for account linking. The [POST /api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) should be used instead. For more information refer to the [Migration Notice](/migrations/past-migrations#account-linking-removal).
+:::
+
+```http
+GET https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  access_token=LOGGED_IN_USER_ACCESS_TOKEN
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": "/authorize",
+  "link": "#link"
+}) %>
+
+Call this endpoint when a user wants to link a second authentication method (for example, a user/password database connection, with Facebook).
+
+This endpoint will trigger the login flow to link an existing account with a new one. This will return a 302 redirect to the `connection` that the current user wants to add. The user is identified by the Access Token that was returned on login success.
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `response_type`
    Required  | Use `code` for server side flows, `token` for client side flows |
+| `client_id`
    Required      | The `client_id` of your application |
+| `connection`     | The name of the connection configured to your application. If null, it will redirect to [Auth0 Login Page](https://auth0.com/#/login_page) and show the Login Widget using the first database connection. |
+| `redirect_uri`
    Required   | The URL to which Auth0 will redirect the browser after authorization has been granted by the user. |
+| `access_token`
    Required   | The logged-in user's Access Token |
+
+
+### Remarks
+
+- The `redirect_uri` value must be specified as a valid callback URL under your [Application's Settings](${manage_url}/#/applications).
+
+
+### Learn More
+
+- [Link User Accounts](/users/guides/link-user-accounts)
+- [Link User Accounts Initiated by Users Scenario](/users/references/link-accounts-user-initiated-scenario)
+- [Link User Accounts Server-Side Scenario](/users/references/link-accounts-server-side-scenario)
+
+
+## Unlink
+
+```http
+POST https://${account.namespace}/login/unlink
+Content-Type: application/json
+{
+  "access_token": "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity Access Token
+  "user_id": "LINKED_USER_ID" // (provider|id)
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/login/unlink' \
+  --header 'content-type: application/json' \
+  --data '{"access_token": "LOGGED_IN_USER_ACCESS_TOKEN", "user_id": "LINKED_USER_ID"}'
+```
+
+```javascript
+var url = 'https://' + ${account.namespace} + '/login/unlink';
+var params = 'access_token=LOGGED_IN_USER_ACCESS_TOKEN&user_id=' + localStorage.getItem('user_id');
+
+var xhr = new XMLHttpRequest();
+xhr.open('POST', url);
+xhr.setRequestHeader('Content-Type', 'application/json');
+
+xhr.onload = function() {
+  if (xhr.status == 200) {
+    fetchProfile();
+  } else {
+    alert("Request failed: " + xhr.statusText);
+  }
+};
+
+xhr.send(params);
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/login/unlink",
+  "link": "#unlink"
+}) %>
+
+::: warning
+This endpoint is **deprecated**. The [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) should be used instead.
+:::
+
+Given a logged-in user's `access_token` and `user_id`, this endpoint will unlink a user's account from the identity provider.
+
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `access_token`
    Required   | The logged-in user's Access Token |
+| `user_id`
    Required        | The logged-in user's `user_id` |
+
+
+### Learn More
+
+- [Unlink User Accounts](/users/guides/unlink-user-accounts)
diff --git a/ja-jp/articles/api/authentication/legacy/_login.md b/ja-jp/articles/api/authentication/legacy/_login.md
new file mode 100644
index 0000000000..4c197080e9
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_login.md
@@ -0,0 +1,197 @@
+
+# Login
+## Social with Provider's Access Token
+
+```http
+POST https://${account.namespace}/oauth/access_token
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "access_token": "ACCESS_TOKEN",
+  "connection": "CONNECTION",
+  "scope": "SCOPE"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/access_token' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "access_token":"ACCESS_TOKEN", "connection":"CONNECTION", "scope":"SCOPE"}'
+```
+
+```javascript
+var url = 'https://' + ${account.namespace} + '/oauth/access_token';
+var params = 'client_id=${account.clientId}&access_token={ACCESS_TOKEN}&connection={CONNECTION}&scope={SCOPE}';
+
+var xhr = new XMLHttpRequest();
+
+xhr.open('POST', url);
+xhr.setRequestHeader('Content-Type', 'application/json');
+
+xhr.onload = function() {
+  if (xhr.status == 200) {
+    fetchProfile();
+  } else {
+    alert("Request failed: " + xhr.statusText);
+  }
+};
+
+xhr.send(params);
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+{
+  "id_token": "eyJ0eXAiOiJKV1Qi...",
+  "access_token": "A9CvPwFojaBI...",
+  "token_type": "bearer"
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/access_token",
+  "link": "#social-with-provider-s-access-token"
+}) %>
+
+::: warning
+This endpoint is part of the legacy authentication pipeline. We recommend that you open the browser to do social authentication instead, which is what [Google and Facebook are recommending](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+
+This feature is disabled by default for new tenants as of 8 June 2017. Please see [Application Grant Types](/applications/concepts/application-grant-types) for more information.
+
+:::
+
+Given the social provider's Access Token and the `connection`, this endpoint will authenticate the user with the provider and return a JSON with the Access Token and, optionally, an ID Token. This endpoint only works for Facebook, Google, Twitter, and Weibo.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application. |
+| `access_token` 
    Required | The social provider's Access Token. |
+| `connection` 
    Required | The name of an identity provider configured to your app. |
+| `scope` | Use `openid` to get an ID Token, or `openid profile email` to include user information in the ID Token. If null, only an Access Token will be returned. |
+
+
+### Remarks
+
+- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`.
+
+- The `email` scope value requests access to the `email` and `email_verified` Claims.
+
+### Error Codes
+
+For the complete error code reference for this endpoint refer to [Errors > POST /oauth/access_token](#post-oauth-access_token).
+
+### Learn More
+
+- [Call an Identity Provider API](/tutorials/calling-an-external-idp-api)
+- [Identity Provider Access Tokens](/tokens/overview-idp-access-tokens)
+- [Add scopes/permissions to call Identity Provider's APIs](/connections/adding-scopes-for-an-external-idp)
+
+## Database/AD/LDAP (Active)
+
+```http
+POST https://${account.namespace}/oauth/ro
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "connection": "CONNECTION",
+  "scope": "openid"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/ro' \
+  --header 'content-type: application/json' \
+  --data '{"client_id":"${account.clientId}", "username":"USERNAME", "password":"PASSWORD", "connection":"CONNECTION", "scope":"openid"}'
+
+```
+
+```javascript
+// Script uses auth0.js. See Remarks for details.
+
+
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/ro",
+  "link": "#database-ad-ldap-active-"
+}) %>
+
+::: warning
+This endpoint is part of the legacy authentication pipeline and has been replaced in favor of the [Password Grant](#resource-owner-password). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+Use this endpoint for API-based (active) authentication. Given the user credentials and the `connection` specified, it will do the authentication on the provider and return a JSON with the Access Token and ID Token.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | The `client_id` of your application |
+| `username` 
    Required | Username/email of the user to login |
+| `password` 
    Required | Password of the user to login |
+| `connection` 
    Required | The name of the connection to use for login |
+| `scope` | Set to `openid` to retrieve also an ID Token, leave null to get only an Access Token |
+| `grant_type` 
    Required | Set to `password` to authenticate using username/password or `urn:ietf:params:oauth:grant-type:jwt-bearer` to authenticate using an ID Token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. |
+| `device` | String value. Required when `grant_type` is `urn:ietf:params:oauth:grant-type:jwt-bearer` |
+| `id_token` | Used to authenticate using a token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. Required when `grant_type` is `urn:ietf:params:oauth:grant-type:jwt-bearer` |
+
+### Remarks
+
+- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS.
+
+- The main difference between passive and active authentication is that the former happens in the browser through the [Auth0 Login Page](https://${account.namespace}/login) and the latter can be invoked from anywhere (a script, server to server, and so forth).
+
+- The sample auth0.js script uses the library version 8. If you are using auth0.js version 7, please see this [reference guide](/libraries/auth0js/v7).
+
+
+### Error Codes
+
+For the complete error code reference for this endpoint, refer to [Errors > POST /oauth/ro](#post-oauth-ro).
+
+### Learn More
+
+- [Database Identity Providers](/connections/database)
+- [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits)
+- [Active Directory/LDAP Connector](/connector)
\ No newline at end of file
diff --git a/ja-jp/articles/api/authentication/legacy/_resource-owner.md b/ja-jp/articles/api/authentication/legacy/_resource-owner.md
new file mode 100644
index 0000000000..d191536587
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_resource-owner.md
@@ -0,0 +1,100 @@
+# Resource Owner
+
+```http
+POST https://${account.namespace}/oauth/ro
+Content-Type: application/json
+{
+  "client_id": "${account.clientId}",
+  "connection": "CONNECTION",
+  "grant_type": "password",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "scope": "SCOPE",
+  "id_token": "ID_TOKEN",
+  "device": "DEVICE"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/oauth/ro' \
+  --header 'accept: application/json' \
+  --header 'content-type: application/json' \
+  --data '{ "client_id": "${account.clientId}", "connection": "CONNECTION", "grant_type": "password", "username": "USERNAME", "password": "PASSWORD", "scope": "SCOPE", "id_token": "ID_TOKEN", "device": "DEVICE" }'
+```
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/ro',
+  headers: { 'content-type': 'application/json', 'accept': 'application/json' },
+  body:
+   { connection: 'CONNECTION',
+     grant_type: 'PASSWORD',
+     username: 'USERNAME',
+     client_id: '${account.clientId}',
+     password: 'PASSWORD',
+     scope: 'SCOPE',
+     id_token: 'ID_TOKEN',
+     device: 'DEVICE'},
+  json: true };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  console.log(body);
+});
+```
+
+> RESPONSE SAMPLE:
+
+```JSON
+{
+  "access_token": "eyJz93a...",
+  "id_token": "eyJ0XAi...",
+  "token_type": "Bearer"
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/oauth/ro",
+  "link": "#resource-owner"
+}) %>
+
+::: warning
+This endpoint is part of the legacy authentication pipeline and has been replaced in favor of the [Password Grant](#resource-owner-password-flow). For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+Given the user's credentials, this endpoint will authenticate the user with the provider and return a JSON object with the Access Token and an ID Token.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Your application's Application ID. |
+| `connection` 
    Required | The name of the connection configured to your application |
+| `grant_type` 
    Required | Use the value `password` |
+| `username` 
    Required | The user's username |
+| `password` 
    Required | The user's password |
+| `scope` | Use `openid` to get an ID Token, `openid profile email` to get an ID Token and the user profile, or `openid offline_access` to get an ID Token and a Refresh Token. |
+| `id_token` | Used to authenticate using a token instead of username/password, in [Touch ID](/libraries/lock-ios/touchid-authentication) scenarios. |
+| `device` | You should set this to a string, if you are requesting a Refresh Token (`scope=offline_access`). |
+
+### Remarks
+
+- This endpoint only works for database connections, passwordless connections, Active Directory/LDAP, Windows Azure AD and ADFS.
+
+- The `profile` scope value requests access to the End-User's default profile Claims, which are: `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, and `updated_at`.
+
+- The `email` scope value requests access to the `email` and `email_verified` Claims.
+
+### Error Codes
+
+For the complete error code reference for this endpoint refer to [Errors > POST /oauth/ro](#post-oauth-ro).
+
+### Learn More
+
+- [Calling APIs from Highly Trusted Applications](/api-auth/grant/password)
diff --git a/ja-jp/articles/api/authentication/legacy/_userinfo.md b/ja-jp/articles/api/authentication/legacy/_userinfo.md
new file mode 100644
index 0000000000..d35e12a99e
--- /dev/null
+++ b/ja-jp/articles/api/authentication/legacy/_userinfo.md
@@ -0,0 +1,97 @@
+
+
+# User Profile
+## Get Token Info
+
+```http
+POST https://${account.namespace}/tokeninfo
+Content-Type: application/json
+{
+  "id_token": "ID_TOKEN"
+}
+```
+
+```shell
+curl --request POST \
+  --url 'https://${account.namespace}/tokeninfo' \
+  --header 'content-type: application/json' \
+  --data '{"id_token":""}'
+```
+
+```javascript
+
+
+
+webAuth.parseHash(window.location.hash, function(err, authResult) {
+  if (err) {
+    return console.log(err);
+  }
+
+  webAuth.client.userInfo(authResult.accessToken, function(err, user) {
+    // Now you have the user's information
+  });
+});
+```
+
+> RESPONSE SAMPLE:
+
+```json
+{
+  "email_verified": false,
+  "email": "foo@bar.com",
+  "clientID": "q2hnj2iug0...",
+  "updated_at": "2016-12-08T14:26:59.923Z",
+  "name": "foo@bar.com",
+  "picture": "https://s.gravatar.com/avatar/foobar.png",
+  "user_id": "auth0|58454...",
+  "nickname": "foo.bar",
+  "identities": [
+    {
+      "user_id": "58454...",
+      "provider": "auth0",
+      "connection": "Username-Password-Authentication",
+      "isSocial": false
+    }
+  ],
+  "created_at": "2016-12-05T11:16:59.640Z",
+  "global_client_id": "dfas76s..."
+}
+```
+
+<%= include('../../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/tokeninfo",
+  "link": "#get-token-info"
+}) %>
+
+::: warning
+This endpoint is part of the legacy authentication pipeline and will be disabled for those who use our latest, OIDC conformant, pipeline. We encourage using the [/userinfo endpoint](#get-user-info) instead. For more information on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+This endpoint validates a JSON Web Token (JWT) (signature and expiration) and returns the user information associated with the user id `sub` property of the token.
+
+### Request Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `id_token` 
    Required | The ID Token to use. |
+
+
+### Remarks
+
+- This endpoint will return three HTTP Response Headers, that provide relevant data on its rate limits:
+  - `X-RateLimit-Limit`: Number of requests allowed per minute.
+  - `X-RateLimit-Remaining`: Number of requests available. Each new request reduces this number by 1. For each minute that passes, requests are added back, so this number increases by 1 each time.
+  - `X-RateLimit-Reset`: Remaining time until the rate limit (`X-RateLimit-Limit`) resets. The value is in [UTC epoch seconds](https://en.wikipedia.org/wiki/Unix_time).
+
+### Learn More
+
+- [User Profile Struture](/users/references/user-profile-structure)
+
+- [Auth0 API Rate Limit Policy](/policies/rate-limits)
diff --git a/ja-jp/articles/api/authorization-extension/_groups.md b/ja-jp/articles/api/authorization-extension/_groups.md
new file mode 100644
index 0000000000..17bc41355c
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/_groups.md
@@ -0,0 +1,1038 @@
+# Groups
+
+Groups are collections of users. The groups that you will create are dependent on the needs of your business process. For example, you might have a group for your users in Finance, a group for your users in IT, and so on.
+
+For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#groups).
+
+## Get all Groups
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups
+Authorization:  'Bearer {access_token}'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "groups":[
+      {
+         "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+         "name":"Test",
+         "description":"Test",
+         "members":[
+            "auth0|59396da1b3c34a15589c780d"
+         ],
+         "mappings":[
+
+         ]
+      },
+      {
+         "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace",
+         "name":"Google",
+         "description":"Google",
+         "mappings":[
+            {
+               "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2",
+               "groupName":"Google",
+               "connectionName":"google-oauth2"
+            }
+         ],
+         "members":[
+            "auth0|59396da1b3c34a15589c780d",
+            "google-oauth2|113108011846505476166"
+         ],
+         "nested":[
+            "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f"
+         ],
+         "roles":[
+            "9b814aac-87ba-4d84-8de6-3bcd0afee761"
+         ]
+      }
+   ],
+   "total":2
+}
+```
+
+<% var path = '/groups'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-groups"
+}) %>
+
+Use this endpoint to retrieve all groups.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+
+## Get a single Group
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+  "_id": "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+  "name": "Test",
+  "description": "Test"
+}
+```
+
+<% var path = '/groups/{group_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-single-group"
+}) %>
+
+Use this endpoint to get a single group based on its unique identifier. Add "?expand" to also load all roles and permissions for this group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to retrieve. |
+
+## Create Group
+
+
    Examples
    
+
+```http
+```
+
+```shell
+curl --request POST \
+  --url 'https://{extension_url}/groups' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'content-type: application/json' \
+  --data '{"name": "My name", "description": "My description"}'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+  "name":"My name",
+  "description":"My description",
+  "_id":"3ea7dc85-3e50-4ba8-ae5a-4956ed6b26d5"
+}
+```
+
+<% var path = '/groups'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": path,
+  "link": "#create-group"
+}) %>
+
+Use this endpoint to create a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+create:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `name` 
    Required | The name of the new group |
+| `description` | A description of the new group |
+
+## Delete Group
+
+
    Examples
    
+
+```http
+POST https://{extension_url}/groups/{group_id}
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+```
+
+```shell
+curl --request POST \
+  --url 'https://{extension_url}/groups/{group_id}' \
+  --header 'Authorization: Bearer {access_token}' \
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-group"
+}) %>
+
+Use this endpoint to delete a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+delete:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to delete |
+
+## Update Group
+
+
    Examples
    
+
+```http
+PUT https://{extension_url}/groups/{group_id}
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+{
+  name: "New name",
+  description: "New description"
+}
+```
+
+```shell
+curl --request PUT \
+  --url 'https://{extension_url}/groups/{group_id}' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '{ "name": "New name", "description": "New description" }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+  "_id": "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+  "name": "New name",
+  "description": "New description",
+  "members": [
+    "auth0|59396da1b3c34a15589c780d"
+  ]
+}
+```
+
+
    
+  PUT
+  /groups/{group_id}
+
    
+
+Use this endpoint to update the name or the description of a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to update |
+| `name` 
    Required | The updated group name |
+| `description` 
    Required | The updated group description |
+
+## Get Group Mappings
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/mappings
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+  "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2",
+  "groupName":"Google",
+  "connectionName":"google-oauth2 (google-oauth2)"
+}
+```
+
+<% var path = '/groups/{group_id}/mappings'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-group-mappings"
+}) %>
+
+Use this endpoint to retrieve the mappings of a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group whose mappings you want to retrieve |
+
+## Create Group Mappings
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/groups/{group_id}/mappings
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+{
+  groupName: "Test",
+  connectionName: "google-oauth2"
+}
+```
+
+```shell
+curl -v -X PATCH \
+  --url 'https://{extension_url}/api/groups/{group_id}/mappings' \
+  --header 'Content-Type: application/json' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '[{"groupName": "Test", "connectionName": "google-oauth2"}]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+
    
+  PATCH
+  /groups/{group_id}/mappings
+
    
+
+Use this endpoint to create one or more mappings in a group.
+
+Group Mappings allow you to dynamically "add" users to different Groups based on the users' Connections. Essentially, using the Connection and the Groups information provided by the Identity Provider, you can dynamically make the user a member of the group in which you've created the appropriate mapping. For more information, refer to [Group Mappings](/extensions/authorization-extension/v2/implementation/setup#group-mappings). 
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group whose mappings you want to retrieve |
+| `groupName` 
    Required | Group to add the users to |
+| `connectionName` 
    Required | Connection for the mapping |
+
+## Delete Group Mappings
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/groups/{group_id}/mappings
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+{
+  _id: [
+    "7b57312c-579a-4798-bd91-9647563e1b8a"
+  ],
+}
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/groups/{group_id}/mappings' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '{"_id": ["7b57312c-579a-4798-bd91-9647563e1b8a"]}'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/mappings'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-group-mappings"
+}) %>
+
+Use this endpoint to delete one or more group mappings from a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more information on how to implement this, refer to our [machine-to-machine flow implementation guide](/flows/guides/client-credentials/call-api-client-credentials) |
+| `{group_id}` 
    Required | The id of the group whose mappings you want to delete |
+
+## Get Group Members
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/members
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "total":1,
+   "users":[
+      {
+         "email":"richard.dowinton@auth0.com",
+         "email_verified":true,
+         "user_id":"auth0|59396da1b3c34a15589c780d",
+         "picture":"https://s.gravatar.com/avatar/3e8ce75cfe7c53f13715df274f63e129?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fri.png",
+         "nickname":"richard.dowinton",
+         "identities":[
+            {
+               "user_id":"59396da1b3c34a15589c780d",
+               "provider":"auth0",
+               "connection":"Username-Password-Authentication",
+               "isSocial":false
+            }
+         ],
+         "updated_at":"2017-06-25T07:28:54.719Z",
+         "created_at":"2017-06-08T15:30:41.237Z",
+         "name":"richard.dowinton@auth0.com",
+         "app_metadata":{
+            "authorization":{
+               "roles":[
+
+               ],
+               "permissions":[
+
+               ]
+            }
+         },
+         "last_ip":"83.208.22.80",
+         "last_login":"2017-06-25T07:28:54.719Z",
+         "logins_count":12
+      }
+   ]
+}
+```
+
+<% var path = '/groups/{group_id}/members'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-group-members"
+}) %>
+
+Use this endpoint to get the members for a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group whose members you want to retrieve |
+| `{page}` | The page number. One-based. |
+| `{per_page}` | The amount of entries per page. Default: `25`. Max value: `25`. |
+
+
+## Add Group Members
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/groups/{group_id}/members
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "google-oauth2|113108011846505476166" ]
+```
+
+```shell
+curl --request PATCH \
+  --url 'https://{extension_url}/groups/{group_id}/members' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '[ "{user_id}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/members'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "PATCH",
+  "path": path,
+  "link": "#add-group-members"
+}) %>
+
+Use this endpoint to add one or more members in a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to which you want to add members |
+| `{user_id}` | Id of the user to add in a group |
+
+## Delete Group Members
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/groups/{group_id}/members
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+["7b57312c-579a-4798-bd91-9647563e1b8a"]
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/groups/{group_id}/members' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '["7b57312c-579a-4798-bd91-9647563e1b8a"]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/members'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-group-members"
+}) %>
+
+Use this endpoint to remove one or more members from a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which you want to remove members |
+
+## Get Nested Group Members
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/members/nested
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "total":1,
+   "nested":[
+      {
+         "user":{
+            "user_id":"auth0|59396da1b3c34a15589c780d",
+            "name":"richard.dowinton@auth0.com",
+            "nickname":"richard.dowinton",
+            "email":"richard.dowinton@auth0.com"
+         },
+         "group":{
+            "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+            "name":"New name",
+            "description":"New description"
+         }
+      }
+   ]
+}
+```
+
+<% var path = '/groups/{group_id}/members/nested'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-nested-group-members"
+}) %>
+
+Use this endpoint to get the nested members for a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which the nested members will be retrieved |
+| `{page}` | The page number. One-based. |
+| `{per_page}` | The amount of entries per page. Default: `25`. Max value: `25`. |
+
+## Get Nested Groups
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/nested
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+      "name":"Test",
+      "description":"Test",
+      "members":[
+         "auth0|59396da1b3c34a15589c780d"
+      ]
+   }
+]
+```
+
+<% var path = '/groups/{group_id}/nested'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-nested-groups"
+}) %>
+
+Use this endpoint to get the nested groups for a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which the nested members will be retrieved |
+
+## Add Nested Groups
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/groups/{group_id}/nested
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "{group_id_to_add}" ]
+```
+
+```shell
+curl --request PATCH \
+  --url 'https://{extension_url}/groups/{group_id}/nested' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'Content-Type: application/json' \
+  --data '[ "{group_id_to_add}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/nested'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "PATCH",
+  "path": path,
+  "link": "#add-nested-groups"
+}) %>
+
+Use this endpoint to add nested groups.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to which you want to add members |
+| `{group_id_to_add}` | List of group IDs that you want to add in the group |
+
+## Delete Nested Groups
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/groups/{group_id}/nested
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+["{NESTED_GROUP_ID}"]
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/groups/{group_id}/nested' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '["{NESTED_GROUP_ID}"]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/nested'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-nested-group"
+}) %>
+
+Use this endpoint to remove one or more nested groups.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which you want to remove other group members |
+| `{NESTED_GROUP_ID}` 
    Required | The id of the group to remove |
+
+## Get Group Roles
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/roles
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "applicationType":"client",
+      "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+      "description":"Test",
+      "name":"Test",
+      "permissions":[
+
+      ],
+      "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761"
+   }
+]
+```
+
+<% var path = '/groups/{group_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-group-roles"
+}) %>
+
+Use this endpoint to get the roles for a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which the nested members will be retrieved |
+
+## Add Group Roles
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/groups/{group_id}/roles
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "google-oauth2|113108011846505476166" ]
+```
+
+```shell
+curl --request PATCH \
+  --url 'https://{extension_url}/groups/{group_id}/roles' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '[ "{role_id}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "PATCH",
+  "path": path,
+  "link": "#add-group-roles"
+}) %>
+
+Use this endpoint to add roles to a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group to which you want to add members |
+| `{role_id}` | List of role IDs to add in the group |
+
+## Delete Group Roles
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/groups/{group_id}/roles
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+["{GROUP_ROLES_ID}"]
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/groups/{group_id}/roles' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '["{role_id}"]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/groups/{group_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-group-roles"
+}) %>
+
+Use this endpoint to remove one or more groups roles.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which you want to remove members |
+| `{role_id}` 
    Required | The IDs of the roles to be removed from the group |
+
+## Get Nested Group Roles
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/groups/{group_id}/roles/nested
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "role":{
+         "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761",
+         "applicationType":"client",
+         "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+         "description":"Test",
+         "name":"Test",
+         "permissions":[
+
+         ],
+         "users":[
+            "auth0|59396da1b3c34a15589c780d"
+         ]
+      },
+      "group":{
+         "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace",
+         "name":"Google",
+         "description":"Google",
+         "mappings":[
+            {
+               "_id":"529e053f-285b-4f7f-b73c-c8c37b0ae4f2",
+               "groupName":"Google",
+               "connectionName":"google-oauth2"
+            }
+         ],
+         "members":[
+            "auth0|59396da1b3c34a15589c780d",
+            "google-oauth2|113108011846505476166"
+         ],
+         "nested":[
+            "2a1e2b9f-3435-4954-8c5d-56e8e9ce763f"
+         ],
+         "roles":[
+            "9b814aac-87ba-4d84-8de6-3bcd0afee761"
+         ]
+      }
+   }
+]
+```
+
+<% var path = '/groups/{group_id}/roles/nested'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-nested-roles"
+}) %>
+
+Use this endpoint to get the nested roles for a group.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your application retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{group_id}` 
    Required | The id of the group from which the nested members will be retrieved |
diff --git a/ja-jp/articles/api/authorization-extension/_introduction.md b/ja-jp/articles/api/authorization-extension/_introduction.md
new file mode 100644
index 0000000000..973481dac2
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/_introduction.md
@@ -0,0 +1,51 @@
+# Introduction
+
+The Authorization Extension API enables you to:
+
+- automate provisioning for your users, roles, groups, and permissions
+- query the authorization context of your users in real time
+
+In order to use it, you first have to [enable API access](/extensions/authorization-extension/v2#enable-api-access) from your Authorization Dashboard.
+
+For more information on the Authorization Extension and how to configure it, refer to [Auth0 Authorization Extension](/extensions/authorization-extension).
+
+For each endpoint in this explorer, you will find sample snippets you can use, in three available formats:
+
+- HTTP request
+- Curl command
+- JavaScript: depending on the endpoint each snippet may use Node.js or simple JavaScript
+
+Each request should be sent with a Content-Type of `application/json`.
+
+## Find your extension URL
+
+All endpoints in this explorer start with `https://{extension_url}`. This is the URL of your Authorization Dashboard. It differs based on you tenant's region:
+
+<%
+  var urlUS = 'https://' + account.tenant + '.us.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api';
+  var urlEU = 'https://' + account.tenant + '.eu.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api';
+  var urlAU = 'https://' + account.tenant + '.au.webtask.io/adf6e2f2b84784b57522e3b19dfc9201/api';
+%>
+
+| Region | Extension URL |
+|--------|---------------|
+| US West | `${urlUS}` |
+| Europe | `${urlEU}` |
+| Australia | `${urlAU}` |
+
+## Get an Access Token
+
+When you [enabled API access for your tenant](/extensions/authorization-extension/v2#enable-api-access), an API was created at your [dashboard](${manage_url}), which you can use to access the Authorization Extension API.
+
+To do so you will have to configure a machine to machine application which will have access to this API and which you will use to get an Access Token.
+
+Follow these steps to set up your application (you will have to do this only once):
+
+1. Go to [Dashboard > Applications](${manage_url}/#/applications) and create a new application of type `Machine to Machine`.
+2. Go to the [Dashboard > APIs](${manage_url}/#/apis) and select the `auth0-authorization-extension-api`.
+3. Go to the `Machine to Machine Applications` tab, find the application you created at the first step, and toggle the `Unauthorized` to `Authorized`.
+4. Select the [scopes](/scopes/current/api-scopes) that should be granted to your application, based on the endpoints you want to access. For example, `read:users` to [get all users](#get-all-users).
+
+To get an Access Token, you need to `POST` to the `/oauth/token` endpoint. You can find detailed instructions [here](/flows/guides/client-credentials/call-api-client-credentials#request-token).
+
+Use this Access Token to access the Authorization Extension API.
diff --git a/ja-jp/articles/api/authorization-extension/_permissions.md b/ja-jp/articles/api/authorization-extension/_permissions.md
new file mode 100644
index 0000000000..8c1c151fcf
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/_permissions.md
@@ -0,0 +1,256 @@
+# Permissions
+
+Permissions are actions or functions that a user, or group of user, is allowed to do. For example, let's say that you have an application that allows employees to enter in company expenses. You want all employees to be able to submit expenses, but want certain Finance users to have more admin type of actions such as being able to approve or delete expenses. These actions can be mapped to [permissions](/extensions/authorization-extension#permissions) (which later on can be grouped in [roles](/extensions/authorization-extension#roles)):
+
+For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#permissions).
+
+## Get all Permissions
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/permissions
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "permissions":[
+      {
+         "applicationType":"client",
+         "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+         "description":"Example permission",
+         "name":"Example",
+         "_id":"deeb552d-2d98-4efb-bb84-0c8babe5f431"
+      }
+   ],
+   "total":1
+}
+```
+
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": '/permissions',
+  "link": "#get-permissions"
+}) %>
+
+Use this endpoint to retrieve all permissions.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:permissions
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+
+## Get a single Permission
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/permissions/{permission_id}
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "_id":"deeb552d-2d98-4efb-bb84-0c8babe5f431",
+   "name":"Example",
+   "description":"Example permission"
+}
+```
+
+<% var path = '/permissions/{permission_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-single-permission"
+}) %>
+
+Use this endpoint to get a single permission based on its unique identifier.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:permissions
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{permission_id}` 
    Required | The id of the permission to retrieve. |
+
+## Create Permission
+
+
    Examples
    
+
+```http
+```
+
+```shell
+curl --request POST \
+  --url 'https://{extension_url}/permissions' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'content-type: application/json' \
+  --data '{ "name":"Example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "name":"Example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+   "_id":"4dcdbcbb-e598-4b8f-abc1-7feb57dc54fe"
+}
+```
+
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/permissions",
+  "link": "#create-permission"
+}) %>
+
+Use this endpoint to create a permission.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+create:permissions
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `name` | The new permission's name |
+| `description` | The new permission's description |
+| `applicationType` | The new permission's application type |
+| `applicationId` | The new permission's application Id |
+
+## Update Permission
+
+
    Examples
    
+
+```http
+PUT https://{extension_url}/permissions/{permission_id}
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+{
+   "name":"New example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa"
+}
+```
+
+```shell
+curl --request PUT \
+  --url 'https://{extension_url}/permissions/{permission_id}' \
+  --header 'Authorization: Bearer {access_token}' \
+  --data '{ "name":"New example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa" }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "_id":"bc6945e0-393a-4405-99d9-96903eaec4a1",
+   "name":"New example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa"
+}
+```
+
+
    
+  PUT
+  /permissions/{permission_id}
+
    
+
+Use this endpoint to update the details of a permission.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:permissions
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{permission_id}` 
    Required | The id of the permission to update |
+| `name` | The updated permission name |
+| `description` | The updated permission description |
+| `applicationType` | The updated application type |
+| `applicationId` | The updated application Id |
+
+## Delete Permission
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/permissions/{permission_id}
+Authorization:  'Bearer {access_token}'
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/permissions/{permission_id}' \
+  --header 'Authorization: Bearer {access_token}'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/permissions/{permission_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-permission"
+}) %>
+
+Use this endpoint to remove a permission.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+delete:permissions
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{permission_id}` 
    Required | The id of the permission to delete |
\ No newline at end of file
diff --git a/ja-jp/articles/api/authorization-extension/_roles.md b/ja-jp/articles/api/authorization-extension/_roles.md
new file mode 100644
index 0000000000..45ca6b2d8c
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/_roles.md
@@ -0,0 +1,281 @@
+# Roles
+
+Roles are collections of permissions. For example, let's say that you have an application that allows employees to enter in company expenses. You want all employees to be able to submit expenses, but want certain Finance users to have more admin type of actions such as being able to approve or delete expenses. These actions can be mapped to [Permissions](/extensions/authorization-extension#permissions) and then assigned to a certain role.
+
+For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension#roles).
+
+## Get all Roles
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/roles
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "roles":[
+      {
+         "applicationType":"client",
+         "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+         "description":"Test",
+         "name":"Test",
+         "permissions":[
+
+         ],
+         "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761"
+      },
+      {
+         "applicationType":"client",
+         "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+         "description":"Example",
+         "name":"Example 2",
+         "permissions":[
+
+         ],
+         "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692"
+      }
+   ],
+   "total":2
+}
+```
+
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": '/roles',
+  "link": "#get-roles"
+}) %>
+
+Use this endpoint to retrieve all roles.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+
+## Get a single Role
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/roles/{role_id}
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761",
+   "name":"Test",
+   "description":"Test"
+}
+```
+
+<% var path = '/roles/{role_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-single-role"
+}) %>
+
+Use this endpoint to get a single role based on its unique identifier.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{role_id}` 
    Required | The id of the role to retrieve. |
+
+## Create Role
+
+
    Examples
    
+
+```http
+```
+
+```shell
+curl --request POST \
+  --url 'https://{extension_url}/roles' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'content-type: application/json' \
+  --data '{ "name":"My new example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", "permissions":["{permission_id}"] }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "name":"Example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+   "permissions":[
+      "bc6945e0-393a-4405-99d9-96903eaec4a1"
+   ],
+   "_id":"22787849-f39c-4165-814f-6996ad8e72a0"
+}
+```
+
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": "/roles",
+  "link": "#create-role"
+}) %>
+
+Use this endpoint to create a role.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+create:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `name` | The new role's name |
+| `description` | The new role's description |
+| `applicationType` | The new role's application type |
+| `applicationId` | The new role's application Id |
+| `permissions` | A comma separated list of permissions (`{permission_id}`) for the new role |
+
+## Update Role
+
+
    Examples
    
+
+```http
+PUT https://{extension_url}/roles/{role_id}
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+{
+   "name":"My new example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+   "permissions":[
+      "{permission_id}"
+   ]
+}
+```
+
+```shell
+curl --request PUT \
+  --url 'https://{extension_url}/roles/{role_id}' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'Content-Type: application/json' \
+  --data '{ "name":"My new example name", "description":"Example description", "applicationType":"client", "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa", "permissions":["{permission_id}"] }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "_id":"22787849-f39c-4165-814f-6996ad8e72a0",
+   "name":"My new example name",
+   "description":"Example description",
+   "applicationType":"client",
+   "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+   "permissions":[
+      "deeb552d-2d98-4efb-bb84-0c8babe5f431"
+   ]
+}
+```
+
+
    
+  PUT
+  /roles/{role_id}
+
    
+
+Use this endpoint to update the details of a role.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{role_id}` 
    Required | The id of the role to update |
+| `name` | The updated role name |
+| `description` | The updated role description |
+| `applicationType` | The updated application type |
+| `applicationId` | The updated application Id |
+| `permissions` | The updated list of permissions |
+
+## Delete Role
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/roles/{role_id}
+Authorization:  'Bearer {access_token}'
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/roles/{role_id}' \
+  --header 'Authorization: Bearer {access_token}'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/roles/{role_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#delete-role"
+}) %>
+
+Use this endpoint to remove a role.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+delete:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{role_id}` 
    Required | The id of the role to delete |
\ No newline at end of file
diff --git a/ja-jp/articles/api/authorization-extension/_users.md b/ja-jp/articles/api/authorization-extension/_users.md
new file mode 100644
index 0000000000..a2337dd9f2
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/_users.md
@@ -0,0 +1,555 @@
+# Users
+
+These endpoints enable you to manage all the current users of your applications. You can retrieve their profile and edit or view their groups and their roles.
+
+For more information, refer to [Auth0 Authorization Extension](/extensions/authorization-extension/v2#users).
+
+## Get all Users
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "start":0,
+   "limit":100,
+   "length":5,
+   "users":[
+      {
+         "logins_count":12,
+         "identities":[
+            {
+               "isSocial":false,
+               "user_id":"59091da1b3c34a15589c780d",
+               "provider":"auth0",
+               "connection":"Username-Password-Authentication"
+            }
+         ],
+         "user_id":"auth0|59091da1b3c34a15589c780d",
+         "last_login":"2017-06-25T07:28:54.719Z",
+         "name":"placeholder.user@example.com",
+         "picture":"https://s.gravatar.com/avatar/your-gravatar.png",
+         "email":"richard.dowinton@auth0.com"
+      }
+   ],
+   "total":1
+}
+```
+
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": '/users',
+  "link": "#get-users"
+}) %>
+
+Use this endpoint to retrieve all users.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{page}` | The page number. One-based. |
+| `{per_page}` | The amount of entries per page. Default: `100`. Max value: `200`. |
+
+## Get a single User
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users/{user_id}
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "email":"placeholder.user@example.com",
+   "email_verified":true,
+   "user_id":"auth0|59091da1b3c34a15589c780d",
+   "picture":"https://s.gravatar.com/avatar/your-gravatar.png",
+   "nickname":"placeholder.user",
+   "identities":[
+      {
+         "user_id":"59091da1b3c34a15589c780d",
+         "provider":"auth0",
+         "connection":"Username-Password-Authentication",
+         "isSocial":false
+      }
+   ],
+   "updated_at":"2017-06-25T07:28:54.719Z",
+   "created_at":"2017-06-08T15:30:41.237Z",
+   "name":"placeholder.user@example.com",
+   "app_metadata":{
+      "authorization":{
+         "roles":[
+
+         ],
+         "permissions":[
+
+         ]
+      }
+   },
+   "last_ip":"83.208.22.80",
+   "last_login":"2017-06-25T07:28:54.719Z",
+   "logins_count":12
+}
+```
+
+<% var path = '/users/{user_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-single-user"
+}) %>
+
+Use this endpoint to get a single user based on its unique identifier.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user to retrieve. |
+
+## Get User Groups
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users/{user_id}/groups
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+      "name":"Test",
+      "description":"Test"
+   },
+   {
+      "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace",
+      "name":"Google",
+      "description":"Google"
+   }
+]
+```
+
+<% var path = '/users/{user_id}/groups'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-user-groups"
+}) %>
+
+Use this endpoint to get the groups of a single user, based on its unique identifier. Add "?expand" to also load all roles and permissions for these groups.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user to retrieve. |
+
+## Add User to Groups
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/users/{user_id}/groups
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "{group_id}" ]
+```
+
+```shell
+curl --request PATCH \
+  --url 'https://{extension_url}/users/{user_id}/groups' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'Content-Type: application/json' \
+  --data '[ "{group_id}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/users/{user_id}/groups'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "PATCH",
+  "path": path,
+  "link": "#add-user-to-groups"
+}) %>
+
+Use this endpoint to add a user to one or more groups.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user that you want to add to groups |
+| `{group_id}` 
    Required | The id of the group to which you want to add users |
+
+## Calculate Group Memberships
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users/{user_id}/groups/calculate
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "_id":"2a1e2b9f-3435-4954-8c5d-56e8e9ce763f",
+      "name":"Test",
+      "description":"Test"
+   },
+   {
+      "_id":"81097bea-f7a3-48b6-a3fc-e2c3eb6c1ace",
+      "name":"Google",
+      "description":"Google"
+   }
+]
+```
+
+<% var path = '/users/{user_id}/groups/calculate'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#calculate-group-memberships"
+}) %>
+
+Use this endpoint to calculate the group memberships for a user (including nested groups).
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:groups
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user for whom you want to calculate the group memberships |
+
+## Get User Roles
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users/{user_id}/roles
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761",
+      "name":"Test",
+      "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+      "description":"Test"
+   },
+   {
+      "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692",
+      "name":"Example 2",
+      "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+      "description":"Example"
+   }
+]
+```
+
+<% var path = '/users/{user_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#get-user-roles"
+}) %>
+
+Use this endpoint to get the roles of a single user, based on its unique identifier.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user for whom you want to retrieve the roles |
+
+## Add User to Roles
+
+
    Examples
    
+
+```http
+PATCH https://{extension_url}/users/{user_id}/roles
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "{role_id}" ]
+```
+
+```shell
+curl --request PATCH \
+  --url 'https://{extension_url}/users/{user_id}/roles' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'Content-Type: application/json' \
+  --data '[ "{role_id}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/users/{user_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-warning",
+  "http_method": "PATCH",
+  "path": path,
+  "link": "#add-user-to-roles"
+}) %>
+
+Use this endpoint to assign a role to a user.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user that you want to assign to roles |
+| `{role_id}` 
    Required | The id of the role to which you want to assign users |
+
+## Remove User from Roles
+
+
    Examples
    
+
+```http
+DELETE https://{extension_url}/users/{user_id}/roles
+Content-Type:   'application/json'
+Authorization:  'Bearer {access_token}'
+[ "{role_id}" ]
+```
+
+```shell
+curl --request DELETE \
+  --url 'https://{extension_url}/users/{user_id}/roles' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'Content-Type: application/json' \
+  --data '[ "{role_id}" ]'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+(empty response body)
+```
+
+<% var path = '/users/{user_id}/roles'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-danger",
+  "http_method": "DELETE",
+  "path": path,
+  "link": "#remove-user-from-role"
+}) %>
+
+Use this endpoint to remove one or more user from a role.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+update:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user you want to remove from roles |
+| `body` 
    Required | The id of the role(s) you want to remove users from (i.e. `[ "{role_id}" ]`) |
+
+## Calculate Roles
+
+
    Examples
    
+
+```http
+GET https://{extension_url}/users/{user_id}/roles/calculate
+```
+
+> RESPONSE SAMPLE:
+
+```text
+[
+   {
+      "_id":"9b814aac-87ba-4d84-8de6-3bcd0afee761",
+      "name":"Test",
+      "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+      "description":"Test"
+   },
+   {
+      "_id":"7f3d03a7-b44e-4605-ad68-c2d94912a692",
+      "name":"Example 2",
+      "applicationId":"LcGQZRtjVPPtZfq33I8vtKxldPKPRwBa",
+      "description":"Example"
+   }
+]
+```
+
+<% var path = '/users/{user_id}/roles/calculate'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-primary",
+  "http_method": "GET",
+  "path": path,
+  "link": "#calculate-roles"
+}) %>
+
+Use this endpoint to calculate the roles assigned to the user (including through group memberships).
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:roles
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 in order to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required | The id of the user for whom you want to calculate the roles |
+
+## Execute Authorization Policy
+
+
    Examples
    
+
+```http
+```
+
+```shell
+curl --request POST \
+  --url 'https://{extension_url}/users/{user_id}/policy/{client_id}' \
+  --header 'Authorization: Bearer {access_token}' \
+  --header 'content-type: application/json' \
+  --data '{ "connectionName": "Username-Password-Database", "groups": [{group_id}] }'
+```
+
+> RESPONSE SAMPLE:
+
+```text
+{
+   "groups":[
+      "New name",
+      "Google",
+      "My name"
+   ],
+   "permissions":[
+
+   ],
+   "roles":[
+      "Test",
+      "Example 2"
+   ]
+}
+```
+
+<% var path = '/users/{user_id}/policy/{client_id}'; %>
+<%=
+include('../../_includes/_http-method', {
+  "http_badge": "badge-success",
+  "http_method": "POST",
+  "path": path,
+  "link": "#execute-authz-policy"
+}) %>
+
+Use this endpoint to execute the authorization policy for a user in the context of a client. This will return the user's groups but also roles and permissions that apply to the current client.
+
+### Scopes
+
+The [Access Token](#get-an-access-token) should have the following scopes:
+
+read:users
+
+### Parameters
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `{extension_url}` 
    Required | The URL of your Authorization Extension. For more info, see [Find your extension URL](#find-your-extension-url) |
+| `{access_token}` 
    Required | The token your client retrieved from Auth0 to access the API. For more info, see [Get an Access Token](#get-an-access-token) |
+| `{user_id}` 
    Required |  |
+| `{client_id}` 
    Required |  |
+| `connectionName` 
    Required | The name of the connection with which the user logged in |
+| `groups` | List of group names received from the IdP (AD, ADFS, and so on) |
diff --git a/ja-jp/articles/api/authorization-extension/index.md b/ja-jp/articles/api/authorization-extension/index.md
new file mode 100644
index 0000000000..cc27f2407b
--- /dev/null
+++ b/ja-jp/articles/api/authorization-extension/index.md
@@ -0,0 +1,32 @@
+---
+title: Authorization Extension API Explorer
+fullWidth: true
+topics:
+    - authorization
+    - apis
+    - api-authorization
+contentType:
+    - reference
+    - index
+useCase: invoke-api
+---
+
+
    
+  <%= include('./_introduction') %>
+
    
+
+
    
+  <%= include('./_groups') %>
+
    
+
+
    
+  <%= include('./_roles') %>
+
    
+
+
    
+  <%= include('./_permissions') %>
+
    
+
+
    
+  <%= include('./_users') %>
+
    
diff --git a/ja-jp/articles/api/info.md b/ja-jp/articles/api/info.md
new file mode 100644
index 0000000000..44920523b6
--- /dev/null
+++ b/ja-jp/articles/api/info.md
@@ -0,0 +1,99 @@
+---
+title: Auth0 APIs
+description: Learn about Auth0's Management and Authentication APIs.
+section: apis
+crews: crew-2
+topics:
+    - management-api
+    - authorization-api
+    - apis
+contentType: reference
+useCase: invoke-api
+---
+# Auth0 APIs
+
+Auth0 exposes the following APIs for developers to consume in their applications.
+
+## Authentication API
+
+The Authentication API exposes identity functionality for Auth0 and supported identity protocols (including OpenID Connect, OAuth, and SAML). 
+
+Typically, you should consume this API through one of the Auth0 SDKs, such as [Auth0.js](/libraries/auth0js), or a library like [Lock](/libraries/lock). However, if you are building your authentication UI manually, you will need to call the Authentication API directly.
+
+Some example tasks include:
+
+* Get [tokens](/tokens) during authentication
+* Request a user's profile using an [Access Token](/tokens/concepts/access-tokens)
+* Exchange [Refresh Tokens](/tokens/concepts/refresh-tokens) for new Access Tokens
+* Request a challenge for [multi-factor authentication (MFA)](/mfa)
+
+
    
+  
    
+    
    
+      
    
+        
    
+          
    
+            
+            
    API Explorer
    
+            
    Explore the requests and responses for Auth0 Authentication API endpoints in your browser.
    
+            
    Open API Explorer
    
+          
    
+        
    
+        
    
+          
    
+            
+            
    Postman
    
+            
    Try the Auth0 Authentication API in Postman.
    
+            
    Run in Postman
    
+            
    How to use our Postman Collections
    
+          
    
+        
    
+      
    
+    
    
+  
    
+
    
+
+## Management API 
+
+The Management API allows you to manage your Auth0 account programmatically, so you can automate configuration of your environment. Most of the tasks you can perform in the Auth0 Management Dashboard can also be performed programmatically by using this API.
+
+Some example tasks include:
+
+* Register your applications and APIs with Auth0
+* Set up [connections](/connections) with which your users can authenticate
+* [Manage users](/users)
+* [Link user accounts](/users/guides/link-user-accounts)
+
+
    
+  
    
+    
    
+      
    
+        
    
+          
    
+            
+            
    API Explorer
    
+            
    Learn about and use the Auth0 Management API in the browser.
    
+            
    Open API Explorer
    
+          
    
+        
    
+        
    
+          
    
+            
+            
    Postman
    
+            
    Try the Auth0 Management API in Postman.
    
+            
    Run in Postman
    
+            
    How to use our Postman Collections
    
+          
    
+        
    
+      
    
+    
    
+  
    
+
    
+
+### Management API v1 has been deprecated
+
+The Management API v1 is deprecated and should not be used for new projects. 
+
+Management API v1 will reach its End of Life on **July 13, 2020**. You may be required to take action before that date to ensure no interruption to your service. See [Migrate from Management API v1 to v2](/migrations/guides/management-api-v1-v2) for details. Notifications have been and will continue to be sent to customers that need to complete this migration.
+
+If your existing application still uses Management API v1, see [Management API v1](/api/management/v1) noting that some endpoints may have limited functionality.
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/apis/enable-rbac.md b/ja-jp/articles/api/management/guides/apis/enable-rbac.md
new file mode 100644
index 0000000000..3c9258dbe9
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/apis/enable-rbac.md
@@ -0,0 +1,58 @@
+---
+title: Enable Role-Based Access Control for APIs
+description: Learn how to enable role-based access control (RBAC) for an API using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - roles
+  - rbac
+  - apis
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Enable Role-Based Access Control for APIs
+
+This guide will show you how to enable [role-based access control (RBAC)](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/apis/enable-rbac). This effectively enables the API Authorization Core feature set.
+
+1. Make a `PATCH` call to the [Update Resource Server endpoint](/api/management/v2#!/resource_servers/patch_resource_server). Be sure to replace `API_ID`, `MGMT_API_ACCESS_TOKEN`, `PERMISSION_NAME`, and `PERMISSION_DESC` placeholder values with your API ID, Management API Access Token, permission name(s), and permission description(s), respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/resource-servers/API_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"enforce_policies\": \"true\", \"token_dialect\": \"TOKEN_DIALECT\" }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `API_ID` | Τhe ID of the API for which you want to enable RBAC. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:resource_servers`. |
+| `TOKEN_DIALECT` | Dialect of the Access Token for the specified API.|
+
+## Token Dialect Options
+
+Available options include:
+
+| Value | Description |
+|-------|-------------|
+|  `access_token` | In the `scope` claim of the Access Token, includes an intersection of the requested permissions and the permissions assigned to the user. No `permissions` claim is passed. |
+| `access_token_authz` | In the `scope` claim of the Access Token, includes an intersection of the requested permissions and the permissions assigned to the user. In the `permissions` claim of the Access Token, includes all permissions assigned to the user. Allows you to make minimal calls to retrieve permissions, but increases token size. |
+
+When RBAC is _disabled_, default behavior is observed; an application can request any permission defined for the API, and the `scope` claim will include all requested permissions.
+
+::: warning
+Remember that any configured [rules](/authorization/concepts/authz-rules) run _after_ the RBAC-based authorization decisions are made, so they may override default behavior.
+:::
diff --git a/ja-jp/articles/api/management/guides/apis/update-permissions-apis.md b/ja-jp/articles/api/management/guides/apis/update-permissions-apis.md
new file mode 100644
index 0000000000..7d39e4ca0c
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/apis/update-permissions-apis.md
@@ -0,0 +1,52 @@
+---
+title: Update API Permissions
+description: Learn how to update permissions for APIs using the Auth0 Management API.
+topics:
+  - authorization
+  - mgmt-api
+  - RBAC
+  - scopes
+  - permissions
+contentType:
+  - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Update API Permissions
+
+This guide will show you how to update permissions for an API using Auth0's Management API. This task can also be performed using the Dashboard, but first you will need to [delete the permission](/dashboard/guides/apis/delete-permissions-apis) and then [add the permission](/dashboard/guides/roles/apis/add-permissions-apis) again.
+
+::: warning
+By default, any user of any application can ask for any permission defined here. You can implement access policies to limit this behavior via [Rules](/rules).
+:::
+
+::: note
+Patching the permissions with an empty object removes the permissions completely.
+:::
+
+1. Make a `PATCH` call to the [Update Resource Server endpoint](/api/management/v2#!/resource_servers/patch_resource_server). Be sure to replace `API_ID`, `MGMT_API_ACCESS_TOKEN`, `PERMISSION_NAME`, and `PERMISSION_DESC` placeholder values with your API ID, Management API Access Token, permission name(s), and permission description(s), respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/resource-servers/API_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"scopes\": [ { \"value\": \"PERMISSION_NAME\", \"description\": \"PERMISSION_DESC\" }, { \"value\": \"PERMISSION_NAME\", \"description\": \"PERMISSION_DESC\" } ] }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `API_ID` | Τhe ID of the API for which you want to add permissions. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:resource_servers`. |
+| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to add for the specified API. | 
+| `PERMISSION_DESC` | User-friendly description(s) of the permission(s) you would like to add for the specified API. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/applications/remove-app.md b/ja-jp/articles/api/management/guides/applications/remove-app.md
new file mode 100644
index 0000000000..9e10014666
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/applications/remove-app.md
@@ -0,0 +1,34 @@
+---
+title: Remove Application
+description: Learn how to remove an Auth0-registered application using the Auth0 Management API.
+toc: false
+topics:
+  - applications
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - add-login
+  - call-api
+---
+# Remove Application
+
+This guide will show you how to remove an application using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/remove-app).
+
+1. Make a `DELETE` call to the [Delete a Client endpoint](/api/management/v2#!/Clients/delete_clients_by_id). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| Value | Description |
+| - | - |
+| `YOUR_CLIENT_ID` | Τhe ID of the application to be deleted. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `delete:clients`. |
diff --git a/ja-jp/articles/api/management/guides/applications/rotate-client-secret.md b/ja-jp/articles/api/management/guides/applications/rotate-client-secret.md
new file mode 100644
index 0000000000..464308df41
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/applications/rotate-client-secret.md
@@ -0,0 +1,42 @@
+---
+title: Rotate Client Secret
+description: Learn how to change your application's client secret using the Auth0 Management API.
+topics:
+  - applications
+	- client-secrets
+	- mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+---
+# Rotate Client Secret
+
+This guide will show you how to change your application's client secret using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/rotate-client-secret).
+
+::: warning 
+New secrets may be delayed while rotating. To minimize downtime, we suggest you store the new client secret in your application's code as a fallback to the previous secret. This way, if the connection doesn't work with the old secret, your app will use the new secret.
+
+Secrets can be stored in a list (or similar structure) until they're no longer needed. Once you're sure that an old secret is obsolete, you can remove its value from your app's code.
+:::
+
+1. Make a `POST` call to the [Rotate a Client Secret endpoint](/api/management/v2#!/Clients/post_rotate_secret). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID/rotate-secret",
+	"headers": [
+   	   { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| Value | Description |
+| - | - |
+| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:client_keys`. |
+
+2. Update authorized applications
+
+When you rotate a client secret, you must update any authorized applications with the new value. 
diff --git a/ja-jp/articles/api/management/guides/applications/update-grant-types.md b/ja-jp/articles/api/management/guides/applications/update-grant-types.md
new file mode 100644
index 0000000000..febf502d5a
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/applications/update-grant-types.md
@@ -0,0 +1,51 @@
+---
+title: Update Grant Types
+description: Learn how to update an application's grant types using Auth0's Management API.
+topics:
+  - applications
+  - grant-types
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+---
+# Update Grant Types
+
+This guide will show you how to change your application's grant types using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/applications/update-grant-types).
+
+::: warning
+As of 8 June 2017, new Auth0 customers **cannot** add legacy grant types to their Applications. Customers as of 8 June 2017 can add legacy grant types to only their existing Applications.
+:::
+
+::: warning
+Attempting to use a flow with an Application lacking the appropriate `grant_types` for that flow (or with the field empty) will result in the following error:
+
+```text
+Grant type `grant_type` not allowed for the client.
+```
+:::
+
+1. Make a `PATCH` call to the [Update a Client endpoint](/api/management/v2#!/Clients/patch_clients_by_id). Be sure to replace `YOUR_CLIENT_ID`, `MGMT_API_ACCESS_TOKEN`, and `GRANT_TYPE` placeholder values with your client ID, Management API Access Token, and desired grant type, respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID",
+	"headers": [
+    	{ "name": "Content-Type", "value": "application/json" },
+   		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    	{ "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+      	"mimeType": "application/json",
+      	"text" : "{ \"grant_types\": \"GRANT_TYPES\" }"
+	}
+}
+```
+
+| Value | Description |
+| - | - |
+| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:clients`. |
+| `GRANT_TYPES` | The grant types you would like to enable for the specified application. |
diff --git a/ja-jp/articles/api/management/guides/applications/update-ownership.md b/ja-jp/articles/api/management/guides/applications/update-ownership.md
new file mode 100644
index 0000000000..bbe9d019bf
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/applications/update-ownership.md
@@ -0,0 +1,40 @@
+---
+title: Update Application Ownership
+description: Learn how to update application ownership using the Auth0 Management API. This will let you specify whether an application is registered with Auth0 as a first-party or third-party application.
+toc: true
+topics:
+  - applications
+  - application-types
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+---
+# Update Application Ownership
+
+This guide will show you how to use Auth0's Management API to update application ownership, which allows you to specify whether an application is registered with Auth0 as a first-party or third-party application.
+
+Make a `PATCH` call to the [Update a Client endpoint](/api/management/v2#!/Clients/patch_clients_by_id). Be sure to replace `YOUR_CLIENT_ID`,`MGMT_API_ACCESS_TOKEN`, and `OWNERSHIP_BOOLEAN` placeholder values with your client ID, Management API Access Token, and boolean representing the application's ownership, respectively.
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"is_first_party\": \"OWNERSHIP_BOOLEAN\" }"
+  }
+}
+```
+
+| Value | Description |
+| - | - |
+| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `update:clients`. |
+| `OWNERSHIP_BOOLEAN` | The ownership you would like to specify for the application. If the application is first-party, `is_first_party` should have a value of `true`. If the application is third-party, `is_first_party` should have a value of `false`. |
diff --git a/ja-jp/articles/api/management/guides/applications/view-ownership.md b/ja-jp/articles/api/management/guides/applications/view-ownership.md
new file mode 100644
index 0000000000..58d736a93a
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/applications/view-ownership.md
@@ -0,0 +1,35 @@
+---
+title: View Application Ownership
+description: Learn how to check whether an application is registered with Auth0 as a first-party or third-party app using the Auth0 Management API.
+toc: true
+topics:
+  - applications
+  - application-types
+  - mgmt-api
+contentType: 
+	- how-to
+useCase:
+  - build-an-app
+---
+# View Application Ownership
+
+This guide will show you how to use Auth0's Management API to check whether an application is registered with Auth0 as a first-party or third-party application.
+
+1. Make a `GET` call to the [Get a Client endpoint](/api/management/v2#!/Clients/get_clients_by_id). Be sure to replace `YOUR_CLIENT_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your client ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/clients/YOUR_CLIENT_ID?fields=is_first_party&include_fields=true",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| Value | Description |
+| - | - |
+| `YOUR_CLIENT_ID` | Τhe ID of the application to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Tokens for the Management API](/api/management/v2/tokens) with the scope `read:clients`. |
+
+If the application is first-party, the `is_first_party` field will have a value of `true`. If the application is third-party, the `is_first_party` field will have a value of `false`.
diff --git a/ja-jp/articles/api/management/guides/connections/configure-connection-sync.md b/ja-jp/articles/api/management/guides/connections/configure-connection-sync.md
new file mode 100644
index 0000000000..c3343c830c
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/connections/configure-connection-sync.md
@@ -0,0 +1,46 @@
+---
+title: Configure Connection Sync with Auth0
+description: Learn how to update connection preferences for an upstream identity provider to control when updates to user profile root attributes will be allowed using the Auth0 Management API.
+topics:
+  - connections
+  - identity-providers
+  - user-profile
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - customize-connections
+  - manage-users
+---
+# Configure Connection Sync with Auth0
+
+This guide will show you how to update connection preferences for an upstream [Identity Provider](/connections) to control when updates to user profile root attributes will be allowed using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/connections/configure-connection-sync).
+
+::: warning
+Before completing this step, you should first [retrieve the existing values of the connection's `options` object](/api/management/guides/connections/retrieve-connection-options) to avoid overriding the current values. If you do not, any missing parameters from the original object will be lost after you update.
+:::
+
+1. Make a `PATCH` call to the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). Make sure you include the original options values in the call to avoid overriding the current values. Also, be sure to replace `CONNECTION_ID`, `MGMT_API_ACCESS_TOKEN`, and `ATTRIBUTE_UPDATE_VALUE` placeholder values with your connection ID, Management API Access Token, and attribute update value, respectively.
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"options\":{\"set_user_root_attributes\": \"ATTRIBUTE_UPDATE_VALUE\"}}"
+  }
+}
+```
+
+| Value | Description |
+| - | - |
+| `CONNECTION_ID` | ID of the connection for which you want to allow updates to root attributes. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:connections`. |
+| `ATTRIBUTE_UPDATE_VALUE` | Indicates when you want to allow updates to user profile root attributes. Valid values are `on_first_login` and `on_each_login`. Defaults to `on_each_login` for new connections. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/connections/promote-connection-domain-level.md b/ja-jp/articles/api/management/guides/connections/promote-connection-domain-level.md
new file mode 100644
index 0000000000..50c1c6f4bc
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/connections/promote-connection-domain-level.md
@@ -0,0 +1,39 @@
+---
+title: Promote Connection to Domain Level
+description: Learn how to promote a connection to domain level using the Auth0 Management API.
+topics:
+  - connections
+  - third-party-app
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - customize-connections
+---
+# Promote Connection to Domain Level
+
+This guide will show you how to promote connections to domain level using Auth0's Management API. 
+
+1. Make a `PATCH` call to the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). Be sure to replace `CONNECTION_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your connection ID and Management API Access Token, respectively.
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"is_domain_connection\": true }"
+  }
+}
+```
+
+| Value | Description |
+| - | - |
+| `CONNECTION_ID` | Τhe ID of the connection to be promoted. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:connections`. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/connections/retrieve-connection-options.md b/ja-jp/articles/api/management/guides/connections/retrieve-connection-options.md
new file mode 100644
index 0000000000..1d62b08e31
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/connections/retrieve-connection-options.md
@@ -0,0 +1,32 @@
+---
+title: Retrieve Connection Options
+description: Learn how to retrieve the options object for a connection using the Auth0 Management API.
+topics:
+  - connections
+  - mgmt-api
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - customize-connections
+---
+# Retrieve Connection Options
+
+This guide will show you how to retrieve the options object for a [connection](/connections) using Auth0's Management API. 
+
+1. Make a `GET` call to the [Get Connection endpoint](/api/management/v2#!/Connections/get_connections_by_id). Be sure to replace `CONNECTION_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your connection ID and Management API Access Token, respectively.
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/connections/CONNECTION-ID?fields=options",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+  ]
+}
+```
+
+| Value | Description |
+| - | - |
+| `CONNECTION_ID` | Τhe ID of the connection for which you want to retrieve the `options` object. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:connections`. |
diff --git a/ja-jp/articles/api/management/guides/roles/add-permissions-roles.md b/ja-jp/articles/api/management/guides/roles/add-permissions-roles.md
new file mode 100644
index 0000000000..5c9ce675be
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/add-permissions-roles.md
@@ -0,0 +1,45 @@
+---
+title: Add Permissions to Roles
+description: Learn how to add permissions to roles for Auth0's API Authorization Core feature using the Auth0 Management API.
+topics:
+  - authorization
+  - mgmt-api
+  - roles
+  - permissions
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Add Permissions to Roles
+
+This guide will show you how to add permissions to [roles](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/add-permissions-roles). The roles and their permissions can be used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `POST` call to the [Add Role Permissions endpoint](/api/management/v2#!/Roles/post_role_permission_assignment). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `API_IDENTIFIER`, and `PERMISSION_NAME` placeholder values with your role ID, Management API Access Token, API identifier (audience), and permission name(s), respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" } ] }"
+  }
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role for which you want to add permissions. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. |
+| `API_IDENTIFIER` | This is the identifier of the API associated with the permission(s) you would like to add for the specified role, otherwise known as the audience. This is not the API ID. |
+| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to add for the specified role. |
diff --git a/ja-jp/articles/api/management/guides/roles/create-roles.md b/ja-jp/articles/api/management/guides/roles/create-roles.md
new file mode 100644
index 0000000000..3208506c22
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/create-roles.md
@@ -0,0 +1,44 @@
+---
+title: Create Roles
+description: Learn how to create a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - roles
+  - rbac
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Create Roles
+
+This guide will show you how to create [roles](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/create-roles). The roles can be used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `POST` call to the [Create Role endpoint](/api/management/v2#!/Roles/post_roles). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `ROLE_NAME`, and `ROLE_DESC` placeholder values with your Management API Access Token, role name, and role description, respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/roles",
+  "headers": [
+  	{ "name": "Content-Type", "value": "application/json" },
+  	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+  	{ "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"name\": \"ROLE_NAME\", \"description\": \"ROLE_DESC\" }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:roles`. |
+| `ROLE_NAME` | Name of the role you would like to create. |
+| `ROLE_DESC` | User-friendly description of the role. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/roles/delete-roles.md b/ja-jp/articles/api/management/guides/roles/delete-roles.md
new file mode 100644
index 0000000000..28396f3025
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/delete-roles.md
@@ -0,0 +1,37 @@
+---
+title: Delete Roles
+description: Learn how to delete a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Delete Roles
+
+This guide will show you how to delete a [role](/authorization/concepts/rbac) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/delete-roles). Roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `DELETE` call to the [Delete Role endpoint](/api/management/v2#!/Roles/delete_roles_by_id). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role you want to delete. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `delete:roles`. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/roles/edit-role-definitions.md b/ja-jp/articles/api/management/guides/roles/edit-role-definitions.md
new file mode 100644
index 0000000000..676490c389
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/edit-role-definitions.md
@@ -0,0 +1,45 @@
+---
+title: Edit Role Definitions
+description: Learn how to edit a role definition using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Edit Role Definitions
+
+This guide will show you how to edit a [role](/authorization/concepts/rbac) definition using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/edit-role-definitions). Roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `PATCH` call to the [Update Role endpoint](/api/management/v2#!/Roles/patch_roles_by_id). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `ROLE_NAME`, and `ROLE_DESC` placeholder values with your role ID, Management API Access Token, role name, and role description, respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"name\": \"ROLE_NAME\", \"description\": \"ROLE_DESC\" }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role for which you want to edit the definition. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. |
+| `ROLE_NAME` | Name of the role. |
+| `ROLE_DESC` | User-friendly description of the role. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/roles/remove-role-permissions.md b/ja-jp/articles/api/management/guides/roles/remove-role-permissions.md
new file mode 100644
index 0000000000..1bb761e434
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/remove-role-permissions.md
@@ -0,0 +1,45 @@
+---
+title: Remove Permissions from Roles
+description: Learn how to remove permissions added to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Remove Permissions from Roles
+
+This guide will show you how to remove the [permissions](/authorization/concepts/rbac) assigned to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/remove-role-permissions). The assigned permissions and roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `DELETE` call to the [Delete Role Permissions endpoint](/api/management/v2#!/Roles/delete_role_permission_assignment). Be sure to replace `ROLE_ID`, `MGMT_API_ACCESS_TOKEN`, `API_ID`, and `PERMISSION_NAME` placeholder values with your role ID, Management API Access Token, API ID(s), and permission name(s), respectively.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" } ] }"
+  }
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role for which you want to remove permissions. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:roles`. |
+| `API_ID` | ID(s) of the API(s) associated with the permission(s) you would like to remove for the specified role. |
+| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to remove for the specified role. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/roles/view-role-permissions.md b/ja-jp/articles/api/management/guides/roles/view-role-permissions.md
new file mode 100644
index 0000000000..86a3aec456
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/view-role-permissions.md
@@ -0,0 +1,37 @@
+---
+Title: View Role Permissions
+description: Learn how to view permissions added to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# View Role Permissions
+
+This guide will show you how to view the [permissions](/authorization/concepts/rbac) added to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/view-role-permissions). The added permissions and roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `GET` call to the [Get Role Permissions endpoint](/api/management/v2#!/Roles/get_role_permission). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID/permissions",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role for which you want to get permissions. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:roles`. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/roles/view-role-users.md b/ja-jp/articles/api/management/guides/roles/view-role-users.md
new file mode 100644
index 0000000000..8c68a6c5e4
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/roles/view-role-users.md
@@ -0,0 +1,38 @@
+---
+title: View Role Users
+description: Learn how to view users assigned to a role using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - dashboard
+  - permissions
+  - roles
+  - users
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# View Role Users
+
+This guide will show you how to view the users assigned to a role using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/roles/view-role-users). Roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `GET` call to the [Get Role Users endpoint](/api/management/v2#!/Roles/get_role_user). Be sure to replace `ROLE_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your role ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/roles/ROLE_ID/users",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `ROLE_ID` | Τhe ID of the role for which you want to get users. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:users` and `read:roles`. |
diff --git a/ja-jp/articles/api/management/guides/rules/create-rules.md b/ja-jp/articles/api/management/guides/rules/create-rules.md
new file mode 100644
index 0000000000..0e102f32c0
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/rules/create-rules.md
@@ -0,0 +1,43 @@
+---
+title: Create Rules
+description: Learn how to create a rule using the Auth0 Management API. You can use rules to customize and extend Auth0's capabilities.
+topics:
+  - mgmt-api
+  - rules
+  - extensibility
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Create Rules
+
+This guide will show you how to create [rules](/rules) using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/rules/create-rules).
+
+1. Make a `POST` call to the [Create Rule endpoint](/api/management/v2#!/Rules/post_rules). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `RULE_NAME`, `RULE_SCRIPT`, `RULE_ORDER`, and `RULE_ENABLED` placeholder values with your Management API Access Token, rule name, rule script, rule order number, and rule enabled value, respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/rules",
+  "headers": [
+  	{ "name": "Content-Type", "value": "application/json" },
+  	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+  	{ "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"name\": \"RULE_NAME\", \"script\": \"RULE_SCRIPT\" }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:rules`. |
+| `RULE_NAME` | Name of the rule you would like to create. The rule name can only contain alphanumeric characters, spaces, and hyphens; it may not start or end with spaces or hyphens. |
+| `RULE_SCRIPT` | Script that contains the code for the rule. Should match what you would enter if you were [creating a new rule using the Dashboard](/dashboard/guides/rules/create-rules). |
+| `RULE_ORDER` (optional) | Integer that represents the order in which the rule should be executed in relation to other rules. Rules with lower numbers are executed before rules with higher numbers. If no order number is provided, the rule will execute last.
+| `RULE_ENABLED` (optional) | Boolean that represents whether the rules is enabled (`true`) or disabled (`false`). |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/tenants/configure-session-lifetime-settings.md b/ja-jp/articles/api/management/guides/tenants/configure-session-lifetime-settings.md
new file mode 100644
index 0000000000..2e4421e585
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/tenants/configure-session-lifetime-settings.md
@@ -0,0 +1,42 @@
+---
+title: Configure Session Lifetime Settings
+description: Learn how to configure session lengths and limits for a tenant using the Auth0 Management API.
+topics:
+  - idle-timeout
+  - absolute-timeout
+  - session-lifetime-limits
+  - dashboard
+contentType:
+  - how-to
+useCase:
+  - integrate-saas-sso
+  - configure-sso
+  - build-an-app
+---
+# Configure Session Lifetime Settings
+
+This guide will show you how to configure session settings for your tenant using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/tenants/configure-session-lifetime-settings).
+
+1. Make a `PATCH` call to the [Tenant Settings endpoint](/api/management/v2#!/tenants/patch_settings). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `SESSION_LIFETIME`, and `IDLE_SESSION_LIFETIME` placeholder values with your Management API Access Token, session lifetime value, and idle session lifetime value, respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+  	{ "name": "Content-Type", "value": "application/json" },
+  	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+  	{ "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"session_lifetime\": SESSION_LIFETIME_VALUE, \"idle_session_lifetime\": IDLE_SESSION_LIFETIME_VALUE }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:tenant_settings`. |
+| `IDLE_SESSION_LIFETIME_VALUE` | Timeframe (in hours) after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 72 hours (3 days) for Developer or Developer Pro or 2,400 hours (100 days) for enterprise plans. |
+| `SESSION_LIFETIME_VALUE` | Timeframe (in hours) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 720 hours (30 days) for Developer or Developer Pro or 8,760 hours (365 days) for enterprise plans. |
diff --git a/ja-jp/articles/api/management/guides/users/assign-permissions-users.md b/ja-jp/articles/api/management/guides/users/assign-permissions-users.md
new file mode 100644
index 0000000000..1bca553a35
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/assign-permissions-users.md
@@ -0,0 +1,50 @@
+---
+title: Assign Permissions to Users
+description: Learn how to assign permissions to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - users
+  - user-profile
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Assign Permissions to Users
+
+This guide will show you how to assign [permissions](/authorization/concepts/rbac) to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/assign-permissions-users). The assigned permissions can be used with the API Authorization Core feature set.
+
+::: note
+Adding permissions directly to a user circumvents the benefits of [role-based access control (RBAC)](/authorization/concepts/rbac) and is not typically recommended.
+:::
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `POST` call to the [Assign User Permissions endpoint](/api/management/v2#!/Users/post_permissions). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `API_IDENTIFIER`, and `PERMISSION_NAME` placeholder values with your user ID, Management API Access Token, API Identifier(s), and permission name(s), respectively.
+
+```har
+{
+  "method": "POST",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/permissions",
+    "headers": [
+    	{ "name": "Content-Type", "value": "application/json" },
+   		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    	{ "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_IDENTIFIER\", \"permission_name\": \"PERMISSION_NAME\" } ] }"
+  }
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user for whom you want to assign permissions. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. |
+| `API_IDENTIFIER` | Identifier(s) of the API(s) associated with the permission(s) you would like to assign for the specified user. |
+| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to assign for the specified user. |
diff --git a/ja-jp/articles/api/management/guides/users/assign-roles-users.md b/ja-jp/articles/api/management/guides/users/assign-roles-users.md
new file mode 100644
index 0000000000..12b652a0d7
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/assign-roles-users.md
@@ -0,0 +1,45 @@
+---
+title: Assign Roles to Users
+description: Learn how to assign roles to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - roles
+  - users
+  - user-profile
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Assign Roles to Users
+
+This guide will show you how to assign [roles](/authorization/concepts/rbac) to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/assign-roles-users). The assigned roles can be used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `POST` call to the [Assign User Roles endpoint](/api/management/v2#!/Users/post_user_roles). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, and `ROLE_ID` placeholder values with your user ID, Management API Access Token, and role ID(s), respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/roles",
+	"headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"roles\": [ \"ROLE_ID\", \"ROLE_ID\" ] }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:roles` and `update:users`. |
+| `ROLE_ID` | ID(s) of the role(s) you would like to add for the specified user. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/users/remove-user-permissions.md b/ja-jp/articles/api/management/guides/users/remove-user-permissions.md
new file mode 100644
index 0000000000..1cdf1f4c6d
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/remove-user-permissions.md
@@ -0,0 +1,46 @@
+---
+title: Remove Permissions from Users
+description: Learn how to remove permissions directly assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - users
+  - user-profile
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Remove Permissions from Users
+
+This guide will show you how to remove the [permissions](/authorization/concepts/rbac) directly assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/remove-user-permissions). The assigned permissions are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `DELETE` call to the [Delete User Permissions endpoint](/api/management/v2#!/Users/delete_permissions). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `API_ID`, and `PERMISSION_NAME` placeholder values with your user ID, Management API Access Token, API ID(s), and permission name(s), respectively.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/permissions",
+	"headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text": "{ \"permissions\": [ { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" }, { \"resource_server_identifier\": \"API_ID\", \"permission_name\": \"PERMISSION_NAME\" } ] }"
+  }
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user to be updated. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. |
+| `API_ID` | ID(s) of the API(s) associated with the permission(s) you would like to remove for the specified user. |
+| `PERMISSION_NAME` | Name(s) of the permission(s) you would like to remove for the specified user. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/users/remove-user-roles.md b/ja-jp/articles/api/management/guides/users/remove-user-roles.md
new file mode 100644
index 0000000000..10e60f99fe
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/remove-user-roles.md
@@ -0,0 +1,45 @@
+---
+title: Remove Roles from Users
+description: Learn how to remove the roles assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+  - users
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# Remove Roles from Users
+
+This guide will show you how to remove the [roles](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed using the Dashboard by either [removing users from a role](/dashboard/guides/users/remove-role-users) or [removing roles from a user](/dashboard/guides/users/remove-user-roles). Roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `DELETE` call to the [Delete User Roles endpoint](/api/management/v2#!/Users/delete_user_roles). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, and `ROLE_ID` placeholder values with your user ID, Management API Access Token, and role ID(s), respectively.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/roles",
+	"headers": [
+    { "name": "Content-Type", "value": "application/json" },
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+    "mimeType": "application/json",
+    "text" : "{ \"roles\": [ \"ROLE_ID\", \"ROLE_ID\" ] }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user to be updated. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. |
+| `ROLE_ID` | ID(s) of the role(s) you would like to remove for the specified user. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/users/set-root-attributes-user-import.md b/ja-jp/articles/api/management/guides/users/set-root-attributes-user-import.md
new file mode 100644
index 0000000000..ac6df80bdd
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/set-root-attributes-user-import.md
@@ -0,0 +1,40 @@
+---
+title: Set Root Attributes During User Import
+description: Learn how to set root attributes for users during import using the Auth0 Management API.
+topics:
+  - mgmt-api
+  - root-attributes
+  - users
+  - user-profile
+  - user-import
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Set Root Attributes During User Import
+
+This guide will show you how to set root attributes for a user during import using Auth0's Management API. This allows you to minimize the number of API calls required to set root attributes when importing users. To see which attributes you can import, visit [Normalized User Profile Structure](/users/references/user-profile-structure).
+
+1. Make a `POST` call to the [Create Job to Import Users endpoint](/api/management/v2#!/Jobs/post_users_imports). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CONNECTION_ID`, and `JSON_USER_FILE_PATH` placeholder values with your Management API Access Token, connection ID, and users filename, respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/jobs/usersimports",
+    "headers": [
+  	    { "name": "Content-Type", "value": "multipart/form-data " },
+  	    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	],
+	"postData": {
+        "mimetype": "multipart/form-data",
+        "text": "{ \"connection_id\": \"CONNECTION_ID\", \"users\": \"JSON_USER_FILE_PATH\" }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:users`. |
+| `CONNECTION_ID` | ID of the connection to which the users will be inserted. You can retrieve this info using the [Get All Connections endpoint](/api/management/v2#!/Connections/get_connections). |
+| `JSON_USER_FILE_PATH` | Filename of the file that contains the users to be imported. File should be in JSON format and include root attributes for users. For a list of available attributes, see [User Profile Attributes](/users/references/user-profile-structure#attributes). For an example of the file format, see [Bulk User Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples). |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/users/set-root-attributes-user-signup.md b/ja-jp/articles/api/management/guides/users/set-root-attributes-user-signup.md
new file mode 100644
index 0000000000..7eebeb41e9
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/set-root-attributes-user-signup.md
@@ -0,0 +1,53 @@
+---
+title: Set Root Attributes During User Sign-Up
+description: Learn how to set root attributes for users during sign-up using the Auth0 Management API.
+topics:
+  - mgmt-api
+  - root-attributes
+  - users
+  - user-profile
+  - user-signup
+contentType:
+  - how-to
+useCase:
+  - build-an-app
+  - add-login
+  - manage-users
+---
+# Set Root Attributes During User Sign-Up
+
+This guide will show you how to set root attributes for a user during sign-up using Auth0's Management API. This allows you to minimize the number of API calls required to set root attributes when creating users.
+
+1. Make a `POST` call to the [Create a User endpoint](/api/management/v2#!/Users/post_users). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CONNECTION_NAME`, `EMAIL_VALUE`, `PASSWORD_VALUE`, `GIVEN_NAME_VALUE`, `FAMILY_NAME_VALUE`, `NAME_VALUE`, `NICKNAME_VALUE`, and `PICTURE` placeholder values with your Management API Access Token, initial connection name, email address, password, given name, family name, name, nickname, and picture URL, respectively.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/api/v2/users",
+    "headers": [
+  	    { "name": "Content-Type", "value": "application/json" },
+  	    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+  	    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+        "mimeType": "application/json",
+        "text": "{ \"connection\": CONNECTION_NAME, \"email\": EMAIL_VALUE, \"password\": PASSWORD_VALUE, \"given_name\": GIVEN_NAME_VALUE, \"family_name\": FAMILY_NAME_VALUE,\"name\": NAME_VALUE, \"nickname\": NICKNAME_VALUE,\"picture\": PICTURE_VALUE }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:users`. |
+| `CONNECTION_NAME` | Name of the connection through which the initial user information was received. |
+| `EMAIL_VALUE` | Email address of the user to be created. |
+| `PASSWORD_VALUE` | Password of the user to be created. |
+| `GIVEN_NAME_VALUE` | Given name of the user to be created. |
+| `FAMILY_NAME_VALUE` | Family name of the user to be created. |
+| `NAME_VALUE` | Full name of the user to be created. |
+| `NICKNAME_VALUE` | Nickname of the user to be created. |
+| `PICTURE_VALUE` | URL of the picture for the user to be created. |
+
+::: note
+If you are using Lock or the [public signup endpoint](/api/authentication#signup) for user sign-up, you can set root attributes using the same method.
+:::
diff --git a/ja-jp/articles/api/management/guides/users/update-root-attributes-users.md b/ja-jp/articles/api/management/guides/users/update-root-attributes-users.md
new file mode 100644
index 0000000000..97be3eabfd
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/update-root-attributes-users.md
@@ -0,0 +1,52 @@
+---
+title: Update Root Attributes for Users
+description: Learn how to update root attributes in existing user profiles using the Auth0 Management API.
+topics:
+  - mgmt-api
+  - root-attributes
+  - users
+  - user-profile
+contentType:
+  - how-to
+useCase:
+  - build-an-app
+  - add-login
+  - manage-users
+---
+# Update Root Attributes for Users
+
+This guide will show you how to update root attributes for an existing user profile using Auth0's Management API. 
+
+Auth0's [Normalized User Profile](/users/references/user-profile-structure) features [root attributes](/users/references/user-profile-structure#user-profile-attributes) that you can update. The specific root attributes that you can update depend on the [connection](/identityproviders) type you're using. For details relevant to the connection you are using, see [Updating User Profile Root Attributes](/users/normalized/auth0/update-root-attributes).
+
+1. Make a `PATCH` call to the [Update a User endpoint](/api/management/v2#!/Users/patch_users_by_id). Be sure to replace `USER_ID`, `MGMT_API_ACCESS_TOKEN`, `GIVEN_NAME_VALUE`, `FAMILY_NAME_VALUE`, `NAME_VALUE`, `NICKNAME_VALUE`, and `PICTURE` placeholder values with your user ID, Management API Access Token, given name, family name, name, nickname, and picture URL, respectively.
+
+```har
+{
+	"method": "PATCH",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID",
+    "headers": [
+  	    { "name": "Content-Type", "value": "application/json" },
+  	    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+  	    { "name": "Cache-Control", "value": "no-cache" }
+	],
+	"postData": {
+        "mimeType": "application/json",
+        "text" : "{ \"given_name\": GIVEN_NAME_VALUE, \"family_name\": FAMILY_NAME_VALUE,\"name\": NAME_VALUE, \"nickname\": NICKNAME_VALUE,\"picture\": PICTURE_VALUE }"
+	}
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user to be updated. |
+| `MGMT_API_ACCESS_TOKEN`  | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:users`. |
+| `GIVEN_NAME_VALUE` | Given name of the user to be updated. |
+| `FAMILY_NAME_VALUE` | Family name of the user to be updated. |
+| `NAME_VALUE` | Full name of the user to be updated. |
+| `NICKNAME_VALUE` | Nickname of the user to be updated. |
+| `PICTURE_VALUE` | URL of the picture for the user to be updated. |
+
+## Removing attributes
+
+Setting any value to `null` will remove the attribute for the user.
diff --git a/ja-jp/articles/api/management/guides/users/view-user-permissions.md b/ja-jp/articles/api/management/guides/users/view-user-permissions.md
new file mode 100644
index 0000000000..f24b5c02d7
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/view-user-permissions.md
@@ -0,0 +1,38 @@
+---
+title: View Permissions Assigned to Users
+description: Learn how to view permissions assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - users
+  - user-profile
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# View Permissions Assigned to Users
+
+This guide will show you how to view the [permissions](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/view-user-permissions). The assigned permissions are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `GET` call to the [Get User Permissions endpoint](/api/management/v2#!/Users/get_permissions). Be sure to replace `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your user ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/permissions",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user for whom you want to get permissions. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:users`. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/guides/users/view-user-roles.md b/ja-jp/articles/api/management/guides/users/view-user-roles.md
new file mode 100644
index 0000000000..af6fb61d60
--- /dev/null
+++ b/ja-jp/articles/api/management/guides/users/view-user-roles.md
@@ -0,0 +1,39 @@
+---
+title: View Roles Assigned to Users
+description: Learn how to view roles assigned to a user using the Auth0 Management API. For use with Auth0's API Authorization Core feature set.
+topics:
+  - authorization
+  - mgmt-api
+  - permissions
+  - roles
+  - users
+  - user-profile
+contentType: 
+    - how-to
+useCase:
+  - build-an-app
+  - call-api
+  - secure-api
+---
+# View Roles Assigned to Users
+
+This guide will show you how to view the [roles](/authorization/concepts/rbac) assigned to a user using Auth0's Management API. This task can also be performed [using the Dashboard](/dashboard/guides/users/view-user-roles). The assigned roles are used with the API Authorization Core feature set.
+
+<%= include('../../../../authorization/_includes/_enable-authz-core') %>
+
+1. Make a `GET` call to the [Get User Roles endpoint](/api/management/v2#!/Users/get_user_roles). Be sure to replace `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your user ID and Management API Access Token, respectively.
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/roles",
+	"headers": [
+   	{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	]
+}
+```
+
+| **Value** | **Description** |
+| - | - |
+| `USER_ID` | Τhe ID of the user for whom you want to get roles. |
+| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scopes `read:users` and `read:roles`. |
\ No newline at end of file
diff --git a/ja-jp/articles/api/management/v1/index.md b/ja-jp/articles/api/management/v1/index.md
new file mode 100644
index 0000000000..e0673851e7
--- /dev/null
+++ b/ja-jp/articles/api/management/v1/index.md
@@ -0,0 +1,909 @@
+---
+description: An overview of the Auth0 Management API v1 which has been deprecated.
+topics:
+  - apis
+  - management-api
+contentType: 
+    - reference
+    - index
+useCase: invoke-api
+---
+
+# Management API v1 (deprecated)
+
+<%= include('../../../_includes/_version_warning_api') %>
+
+## Authentication
+
+
    
+  
    POST /oauth/token
    
+  
    Obtain a token to call the API
    
+
    
+
+Auth0 API requires an Access Token. You can get one by authenticating with your `client_id` and `client_secret` (It will be valid for 24 hours). To obtain the global client ID and global client secret see the **Advanced** tab under [Tenant Settings](${manage_url}/#/tenant/advanced) in the Auth0 dashboard.
+
+```text
+POST /oauth/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=client_credentials&client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET
+```
+
+Once authenticated, the Access Token can be included in the request as part of the query string ( `?access_token=...`) or in an HTTP header (`Authorization: Bearer ...access_token...`).
+
+
+## Users
+
    
+  
    GET /api/users
    
+  
    Gets all users who have logged in
    
+
    
+
+Gets all users who have logged in through any of your connections.
+
+```text
+GET /api/users
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/users?search={query}
    
+  
    Search users
    
+
    
+
+Performs a 'starts with' search by name or email. Or search by field, for example: email_verified:true; loginsCount:1; family_name:"johnson"
+
+```text
+GET /api/users?search={query}
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/users/{user_id}
    
+  
    Gets an user by id
    
+
    
+
+Gets a user who has logged in through any of your connections that has a given id.
+
+```text
+GET /api/users/{user_id}
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/connections/{connection}/users
    
+  
    Gets all users from an enterprise directory
    
+
    
+
+Head ups! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection.
+
+```text
+GET /api/connections/{connection}/users
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/connections/{connection}/users?search={criteria}
    
+  
    Search users from an enterprise directories
    
+
    
+
+**Search** remarks: Depending on the connection's type the search will be done in different fields:
+*   Active Directory/LDAP: by default uses ambiguous name resolution ([ANR](http://technet.microsoft.com/en-us/library/cc755809(v=ws.10).aspx)) which expands to givenName (first name), sn (surname, or last name), displayName, RDN, legacyExchangeDN, physicalDeliveryOfficeName (for example, Building A, Suite 1234), proxyAddresses (the collection of email addresses over all email address spaces that the Exchange server knows about).
+*   Database Connections (not custom): Name/Email case insensitive.
+*   G Suite: Email/username case insensitive.
+*   WAAD/WAAD2: Name/Email case insensitive.
+*   Windows Azure Active Directory or Office365: name/email case insensitive
+Heads up! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection.
+
+```text
+GET /api/connections/{connection}/users?search={query}&per_page={count}
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/enterpriseconnections/users?search={criteria}
    
+  
    Search users from all enterprise directories
    
+
    
+
+Search users from all enterprise directories based on the specified `criteria`. The parameter is mandatory.
+**Search** remarks: Depending on the connection's type the search will be done in different fields:
+*   Active Directory/LDAP: by default uses ambiguous name resolution ([ANR](http://technet.microsoft.com/en-us/library/cc755809(v=ws.10).aspx)) which expands to givenName (first name), sn (surname, or last name), displayName, RDN, legacyExchangeDN, physicalDeliveryOfficeName (for example, Building A, Suite 1234), proxyAddresses (the collection of email addresses over all email address spaces that the Exchange server knows about).
+*   Database Connections (not custom): Name/Email case insensitive.
+*   G Suite: Email/username case insensitive.
+*   WAAD/WAAD2: Name/Email case insensitive.
+*   Windows Azure Active Directory or Office365: name/email case insensitive
+Heads up! If the connection does not support querying for users (for instance ADFS, SAMLP), it will return the users who have logged in through that connection.
+
+```text
+GET /api/enterpriseconnections/users?search=&per_page=
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/socialconnections/users?search={criteria}
    
+  
    Gets all users who have logged in with social connections that match the search criteria
    
+
    
+
+
+Gets all users who have logged in through social connections that match the specified search `criteria`.
+Performs a 'starts with' search by name or email. Or searches by field, for example: email_verified:true; loginsCount:1; family_name:"johnson"
+
+```text
+GET /api/socialconnections/users?search=&per_page=
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/clients/{client-id}/users
    
+  
    Gets all users from a specific application
    
+
    
+
+Gets all users who have logged in with a specific application
+
+```text
+GET /api/clients/users
+Authorization: Bearer {token}
+```
+
+
    
+  
    POST /api/users
    
+  
    Creates a user
    
+
    
+
+Creates a user. The body of the request must include the `email`, the `password`, and the `connection` of the user. Also it can include the user's `email_verified` parameter and the `extra attributes` that you want to add.
+
+```text
+POST /api/users/
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "email":          "",
+  "password":       "",
+  "connection":     "", // only database or passwordless connections
+  "email_verified": falsetrue, // if true, it won't send an email for confirmation
+  "vip": true,
+  "birthdate": "1980-12-23T03:00:00.000Z"
+}
+```
+
+
    
+  
    POST /api/users/{user_id}/send_verification_email
    
+  
    Resends verification account email
    
+
    
+Resends verification account email.
+
+```text
+POST /api/users//`send_verification_email`
+Authorization: Bearer {token}
+```
+
+
    
+  
    POST /api/users/{user_id}/change_password_ticket
    
+  
    Generates change password ticket
    
+
    
+
+Generates change password ticket. The body of the request must include the `newPassword` of the user. Optionally, you can include the `resultUrl` (post verification url).
+
+```text
+POST /api/users/{user_id}/change_password_ticket
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "newPassword":    "",
+  "resultUrl":      "" // optional
+}
+```
+
    
+  
    POST /api/users/{user_id}/verification_ticket
    
+  
    Generates verification account ticket
    
+
    
+
+Generates verification account ticket. Optionally, you can include the `resultUrl` (post verification url) in the body of the request.
+
+```text
+POST /api/users/{user_id}/verification_ticket
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "resultUrl":      "" // optional
+}
+```
+
+
    
+  
    POST /api/users/{user_id}/publickey
    
+  
    Saves user public key for specified device
    
+
    
+
+Saves user public key for specified device.
+
+```text
+POST /api/users//publickey
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "device":     "",
+  "public_key": ""
+}
+```
+
+
    
+  
    PUT /api/users/{user_id}/email
    
+  
    Updates user email
    
+
    
+
+Update user email. The body of the request must include the new `email`.
+
+```text
+PUT /api/users/{user_id}/email
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "email":   "",
+  "verify":  truefalse // if false, it won't send an email for verification
+}
+```
+
+
    
+  
    PUT /api/users/{user_id}/metadata
    
+  
    Updates user metadata
    
+
    
+
+Update user metadata. The body of the request must include a `json` object with metadata `attributes`.
+
+```text
+PUT /api/users/{user_id}/metadata
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "Policy": "1238907654",
+  "Customer Id": "1234"
+}
+```
+
+
    
+  
    PUT /api/users/{user_id}/password
    
+  
    Updates user password
    
+
    
+
+Update user password. The body of the request must include the new `password`.
+
+```text
+PUT /api/users/{user_id}/password
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "password":   "",
+  "verify":     truefalse, // if false, it won't send an email for confirmation
+}
+```
+
+
    
+  
    PUT /api/users/{email}/password
    
+  
    Updates user password
    
+
    
+
+Update user password. The body of the request must include the `email`, `connection` and the new `password`.
+
+```text
+PUT /api/users/{email}/password
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "email":      "",
+  "password":   "",
+  "connection": "
+  ", // only database connections
+  "verify":     truefalse, // if false, it won't send an email for confirmation
+}
+```
+
+
    
+  
    PATCH /api/users/{user_id}/metadata
    
+  
    Patch user metadata
    
+
    
+
+Patch user metadata. The body of the request must include a `json` object with metadata `attributes`. It will not override metadata not specified attributes.
+
+```text
+PATCH /api/users/{user_id}/metadata
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "Policy": "1238907654",
+  "Customer Id": "1234"
+}
+```
+
+
    
+  
    DELETE /api/users/{user_id}
    
+  
    Deletes a user
    
+
    
+
+Deletes a user identified by `user_id`
+
+```text
+DELETE /api/users/{user_id}
+Authorization: Bearer {token}
+```
+
+
    
+  
    DELETE /api/users/{user_id}/refresh_tokens/{refresh_token}
    
+  
    Revokes a Refresh Token
    
+
    
+
+Revokes a user's Refresh Token
+
+```text
+DELETE /api/users/{user_id}/refresh_tokens/{refresh_token}
+Authorization: Bearer {token}
+```
+
+
+
    
+  
    DELETE /api/users/{user_id}/publickey?device={device}
    
+  
    Revokes a public key
    
+
    
+
+Revokes a user's public key for specified device
+
+```
+DELETE /api/users/{user_id}/publickey?device={device}
+Authorization: Bearer {token}
+```
+
+## Connections
+
+
    
+  
    GET /api/connections
    
+  
    Gets all connections
    
+
    
+
+Gets a list of all the connections (enterprise and social) and all its `options`
+
+```text
+GET /api/connections
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/connections/{connection-name}
    
+  
    Gets one connection by name
    
+
    
+
+Gets a connection by name (enterprise and social) and all its `options`
+
+```text
+GET /api/connections/{connection-name}
+Authorization: Bearer {token}
+```
+
+
    
+  
    DELETE /api/connections/{connection-name}
    
+  
    Removes a connection
    
+
    
+
+Deletes a connection identified by `connectionName`
+
+```text
+DELETE /api/connections/{connection-name}
+Authorization: Bearer {token}
+```
+
+
    
+  
    POST /api/connections
    
+  
    Creates a connection
    
+
    
+
+Creates a connection. The body of the request must include the `name`, the authentication `strategy` to use, and an `options` object with the connection parameters.
+
+```text
+POST /api/connections
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "name":     ""
+  "strategy": "waad|g-suite|adfs|PingFederate|samlp|auth0",
+  "options":   {
+    "tenant_domain":
+    "domain_aliases":
+    "tenant_domain":
+    "domain_aliases":
+    "tenant_domain": ,
+    "domain_aliases": ,
+    "adfs_server":
+    "domain_aliases": ,
+    "PingFederate Base URL": ,
+    "Signing Cert":   "",
+    "signInEndpoint":   "",
+    "signingCert":   "",
+    "tenant_domain": "",
+    "domain_aliases": ,
+    "signOutEndpoint":  "",
+  }
+}
+```
+
+
    
+  
    PUT /api/connections/{connection-name}
    
+  
    Updates a connection
    
+
    
+
+Updates a connection. The body of the request must include the `options` object with the connection parameters and the `status`.
+The request's body depends on the strategy that was used to create the connection. Select a strategy: waad g-suite adfs PingFederate samlp auth0
+
+```text
+PUT /api/connections/{connection-name}
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "options":   {
+    "tenant_domain":
+    "tenant_domain":
+    "tenant_domain": ,
+    "adfs_server":
+    "PingFederate Base URL": ,
+    "Signing Cert":   "",
+    "signInEndpoint":   "",
+    "signingCert":   "",
+    "tenant_domain": "",
+    "signOutEndpoint":  "",
+  }
+  "status": true|false
+}
+```
+
+## Applications (Clients)
+
+
    
+  
    GET /api/clients
    
+  
    Gets all applications/APIs
    
+
    
+
+Gets a list of all the applications/APIs (aka clients) and all its `options`
+
+```text
+GET /api/clients
+Authorization: Bearer {token}
+```
+
+
    
+  
    POST /api/clients
    
+  
    Creates a new applications/APIs
    
+
    
+
+Create an application. The body of the request can include the `name` and `callbacks` parameters.
+
+```text
+POST /api/clients
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "name":      "",
+  "callbacks": "" // You can specify multiple valid URLs by comma-separating them.
+}
+```
+
+
    
+  
    PATCH /api/clients/{client-id}
    
+  
    Updates an applications/APIs
    
+
    
+
+Update an application. The body of the request must include the `name` and `callbacks` parameters. Does not overwrite the entire application, only the provided values.
+Additionally the `signingKey` can be overwritten using this method (not provided for trial for safety reasons). Possible formats are:
+*   `"signingKey": { cert: "%CERT_STRING%" } // using a cert`
+*   `"signingKey": { key: "%KEY_STRING%" } // using a private key`
+*   `"signingKey": { pkcs7: "%PKCS7_STRING%" } // using a pkcs7`
+*
+WARNING! Changing the `signingKey` for the globalClient will change it for all applications.
+
+```text
+PATCH /api/clients/{client-id}
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "name":      "",
+  "callbacks": "" // You can specify multiple valid URLs by comma-separating them.
+}
+```
+
+## Rules
+
+
    
+  
    GET /api/rules
    
+  
    Gets all rules
    
+
    
+
+Gets a list of all the rules
+
+```text
+GET /api/rules
+Authorization: Bearer {token}
+```
+
+
    
+  
    POST /api/rules
    
+  
    Creates a new applications/APIs
    
+
    
+
+Create a rule. The body of the request must include the `name`, `status` and `script` parameters.
+
+```text
+POST /api/rules/
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "name":     "",
+  "status":   true|false,
+  "script":   "function (user, context, callback) { user.foo = 'bar'; callback(null, user, context);}"
+               // new lines should be encoded as \n
+  "order": 1 // optional
+}
+```
+
+
    
+  
    PUT /api/rules/{rule-name}
    
+  
    Updates a rule
    
+
    
+
+Update a rule. The body of the request must include the `status` and `script` parameters.
+
+```text
+PUT /api/rules/{rule-name}
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "status":   true|false,
+  "script":   "function (user, context, callback) { user.foo = 'bar'; callback(null, user, context);}"
+               // new lines should be encoded as \n
+  "order": 1 // optional
+}
+```
+
+
    
+  
    DELETE /api/rules/{rule-name}
    
+  
    Deletes a rules
    
+
    
+
+
+Deletes a rule identified by `rule-name` (url-encoded)
+
+```text
+DELETE /api/rules/{rule-name}
+Authorization: Bearer {token}
+```
+
+## Email Templates
+
+
    
+  
    GET /api/emails/{email-template-name}
    
+  
    Gets an email template by name
    
+
    
+
+Gets an email template by name
+
+```text
+GET /api/emails/{email-template-name}
+Authorization: Bearer {token}
+```
+
+Template Names:
+* `verify_email`
+* `welcome_email`
+* `reset_email`
+* `blocked_account`
+
+
    
+  
    POST /api/emails
    
+  
    Creates an email template
    
+
    
+
+
+Creates an email template. The body of the request must include the `template` name and the `tenant`.
+
+```text
+POST /api/emails/
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "template": "template_name",
+  "disabled": true|false,
+  "from": "",
+  "subject": "",
+  "body": "",
+  "urlLifetimeInSeconds": "",
+  "resultUrl": "",
+  "syntax": "liquid"
+}
+```
+
+Template Names:
+* `verify_email`
+* `welcome_email`
+* `reset_email`
+* `blocked_account`
+
+
    
+  
    PUT /api/emails/{email-template-name}
    
+  
    Updates an email template
    
+
    
+
+Updates an email template.
+
+```text
+PUT /api/emails/{email-template-name}
+Authorization: Bearer {token}
+Content-Type: application/json
+{
+  "disabled": true|false,
+  "from": "",
+  "subject": "",
+  "body": "",
+  "urlLifetimeInSeconds": "",
+  "resultUrl": "",
+  "syntax": "liquid"
+}
+```
+
+Template Names:
+* `verify_email`
+* `welcome_email`
+* `reset_email`
+* `blocked_account`
+
+## Logs
+
+
    
+  
    GET /api/logs/{_id}
    
+  
    Gets a log entry
    
+
    
+
+
+Retrieves the data related to the log entry identified by `_id`.
+
+```text
+GET /api/logs/{_id}
+Authorization: Bearer {token}
+```
+
+
    
+  
    GET /api/users/{user_id}/logs?page={number}&per_page={items}
    
+  
    Gets the logs for a particular user
    
+
    
+
+Retrieves the log entries related to the user identified by `user_id`. Log entries are split into pages of a particular size to avoid returning all data at once:
+*   `page`: The page number. Zero based.
+*   `items`: The amount of entries per page.
+
+```text
+GET /api/users/{user_id}/logs?page={number}&per_page={items}
+Authorization: Bearer {token}
+```
+
+#### Response fields
+The following is a description of the values returned by the request:
+*   `start`: The absolute number (considering all log entries) of the first entry in the page.
+*   `length`: The amount of entries in the page (can only be different than `limit` in the last page).
+*   `total`: The amount of entries in the page.
+*   `limit`: The maximum amount of items in a page.
+*   `logs`: A collection of log entries.
+    *   `date`: The moment when the event occurred.
+    *   `connection`: The connection related to the event.
+    *   `client_id`: The id of the application related to the event.
+    *   `client_name`: The name of the application related to the event.
+    *   `ip`: The IP address from where the request that caused the log entry originated.
+    *   `user_id`: The user id related to the event.
+    *   `user_name`: The user name related to the event.
+    *   `description`: The event's description.
+    *   `user_agent`: The user agent that was used to cause the creation of the log entry.
+    *   `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning.
+    *   `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type.
+##### Event acronym mappings
+The following is the meaning of the event acronyms:
+*   `s`:Success Login
+*   `f`:Failed Login
+*   `fu`:Failed Login (invalid email/username)
+*   `fp`:Failed Login (wrong password)
+*   `fc`:Failed by Connector
+*   `fco`:Failed by CORS
+*   `con`:Connector Online
+*   `coff`:Connector Offline
+*   `ss`:Success Signup
+*   `fs`:Failed Signup
+*   `sv`:Success Verification Email
+*   `fv`:Failed Verification Email
+*   `scp`:Success Change Password
+*   `fcp`:Failed Change Password
+*   `sce`:Success Change Email
+*   `fce`:Failed Change Email
+*   `svr`:Success Verification Email Request
+*   `fvr`:Failed Verification Email Request
+*   `scpr`:Success Change Password Request
+*   `fcpr`:Failed Change Password Request
+*   `fn`:Failed Sending Notification
+
+
    
+  
    GET /api/logs?page={number}&per_page={items}&sort={field}:{-1|1}&fields={fields}&exclude_fields{true|false}
    
+  
    Gets log entries
    
+
    
+
+Retrieves data about log entries based on the specified parameters. Log entries are split into pages of a particular size to avoid returning all data at once:
+*   `page`: The page number. Zero based.
+*   `items`: The amount of entries per page.
+*   `field`: The field to use for sorting. `1` == ascending and `-1` == descending.
+*   `fields`: Can be used to either include or exclude the specified fields by providing a comma (,) separated list of fields, for example `at,c,cn,un`. If no list is provided all fields are included in the response.
+*   `exclude_fields`: To exclude the fields `exclude_fields=true` must be used (if not specified it defaults to false).
+Possible values for `field` are:
+*   `date`: The moment when the event occurred.
+*   `connection`: The connection related to the event.
+*   `client_name`: The name of the application related to the event.
+*   `user_name`: The user name related to the event.
+
+```text
+GET /api/logs?page={number}&per_page={items}&sort={field}:{-1|1}&fields={fields}&exclude_fields{true|false}
+Authorization: Bearer {token}
+```
+
+#### Response fields
+The following is a description of the values returned by the request:
+*   `start`: The absolute number (considering all log entries) of the first entry in the page.
+*   `length`: The amount of entries in the page (can only be different than `limit` in the last page).
+*   `total`: The amount of entries in the page.
+*   `limit`: The maximum amount of items in a page.
+*   `logs`: A collection of log entries.
+    *   `date`: The moment when the event occurred.
+    *   `connection`: The connection related to the event.
+    *   `client_id`: The id of the application related to the event.
+    *   `client_name`: The name of the application related to the event.
+    *   `ip`: The IP address from where the request that caused the log entry originated.
+    *   `user_id`: The user id related to the event.
+    *   `user_name`: The user name related to the event.
+    *   `description`: The event's description.
+    *   `user_agent`: The user agent that was used to cause the creation of the log entry.
+    *   `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning.
+    *   `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type.
+##### Event acronym mappings
+The following is the meaning of the event acronyms:
+*   `s`:Success Login
+*   `f`:Failed Login
+*   `fu`:Failed Login (invalid email/username)
+*   `fp`:Failed Login (wrong password)
+*   `fc`:Failed by Connector
+*   `fco`:Failed by CORS
+*   `con`:Connector Online
+*   `coff`:Connector Offline
+*   `ss`:Success Signup
+*   `fs`:Failed Signup
+*   `sv`:Success Verification Email
+*   `fv`:Failed Verification Email
+*   `scp`:Success Change Password
+*   `fcp`:Failed Change Password
+*   `sce`:Success Change Email
+*   `fce`:Failed Change Email
+*   `svr`:Success Verification Email Request
+*   `fvr`:Failed Verification Email Request
+*   `scpr`:Success Change Password Request
+*   `fcpr`:Failed Change Password Request
+*   `fn`:Failed Sending Notification
+
+
    
+  
    GET /api/logs?search={criteria}
    
+  
    Gets log entries
    
+
    
+
+Retrieves logs that match the specified search `criteria`. This parameter can be combined with all the others in the `/api/logs` endpoint but is specified separately for clarity.
+If no fields are provided a case insensitive 'starts with' search is performed on all of the following fields:
+*   `client_name`
+*   `connection`
+*   `user_name`
+
+Otherwise, you can specify multiple fields and specify the search using the `%field%:%search%`, for example: `application:node user:"John@contoso.com"`.
+Values specified without quotes are matched using a case insensitive 'starts with' search. If quotes are used a case insensitive exact search is used. If multiple fields are used, the AND operator is used to join the clauses.
+
+##### Available Fields
+*   `application`: Maps to the `client_name` field.
+*   `connection`: Maps to the `connection` field.
+*   `user`: Maps to the `user_name` field.
+
+```text
+GET /api/logs?search={criteria}
+Authorization: Bearer {token}
+```
+
+#### Response fields
+The following is a description of the values returned by the request:
+*   `start`: The absolute number (considering all log entries) of the first entry in the page.
+*   `length`: The amount of entries in the page (can only be different than `limit` in the last page).
+*   `total`: The amount of entries in the page.
+*   `limit`: The maximum amount of items in a page.
+*   `logs`: A collection of log entries.
+    *   `date`: The moment when the event occurred.
+    *   `connection`: The connection related to the event.
+    *   `client_id`: The id of the application related to the event.
+    *   `client_name`: The name of the application related to the event.
+    *   `ip`: The IP address from where the request that caused the log entry originated.
+    *   `user_id`: The user id related to the event.
+    *   `user_name`: The user name related to the event.
+    *   `description`: The event's description.
+    *   `user_agent`: The user agent that was used to cause the creation of the log entry.
+    *   `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning.
+    *   `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type.
+
+##### Event acronym mappings
+The following is the meaning of the event acronyms:
+*   `s`:Success Login
+*   `f`:Failed Login
+*   `fu`:Failed Login (invalid email/username)
+*   `fp`:Failed Login (wrong password)
+*   `fc`:Failed by Connector
+*   `fco`:Failed by CORS
+*   `con`:Connector Online
+*   `coff`:Connector Offline
+*   `ss`:Success Signup
+*   `fs`:Failed Signup
+*   `sv`:Success Verification Email
+*   `fv`:Failed Verification Email
+*   `scp`:Success Change Password
+*   `fcp`:Failed Change Password
+*   `sce`:Success Change Email
+*   `fce`:Failed Change Email
+*   `svr`:Success Verification Email Request
+*   `fvr`:Failed Verification Email Request
+*   `scpr`:Success Change Password Request
+*   `fcpr`:Failed Change Password Request
+*   `fn`:Failed Sending Notification
+
+
    
+  
    GET /api/logs?from={checkpointId}&take={count}
    
+  
    Gets log entries from a checkpoint
    
+
    
+
+Retrieves `count` log entries that were logged after `checkpointId`.
+*   If `checkpointId` is not provided it will start retrieving from the first log entry.
+*   If `count` is not provided the default value is 200 (also the max value).
+
+```text
+GET /api/logs?from={checkpointId}&take={count}
+Authorization: Bearer {token}
+```
+
+#### Response fields
+The following is a description of the values returned by the request:
+*   `start`: The absolute number (considering all log entries) of the first entry in the page.
+*   `length`: The amount of entries in the page (can only be different than `limit` in the last page).
+*   `total`: The amount of entries in the page.
+*   `limit`: The maximum amount of items in a page.
+*   `logs`: A collection of log entries.
+    *   `date`: The moment when the event occurred.
+    *   `connection`: The connection related to the event.
+    *   `client_id`: The id of the application related to the event.
+    *   `client_name`: The name of the application related to the event.
+    *   `ip`: The IP address from where the request that caused the log entry originated.
+    *   `user_id`: The user id related to the event.
+    *   `user_name`: The user name related to the event.
+    *   `description`: The event's description.
+    *   `user_agent`: The user agent that was used to cause the creation of the log entry.
+    *   `type`: An abbreviation of the event type. Refer to the event acronym mappings below for the mapping between abbreviations and their meaning.
+    *   `details`: Additional (and very useful) details about the event. They don't have a specific schema as they vary based on event type.
+
+##### Event acronym mappings
+The following is the meaning of the event acronyms:
+*   `s`:Success Login
+*   `f`:Failed Login
+*   `fu`:Failed Login (invalid email/username)
+*   `fp`:Failed Login (wrong password)
+*   `fc`:Failed by Connector
+*   `fco`:Failed by CORS
+*   `con`:Connector Online
+*   `coff`:Connector Offline
+*   `ss`:Success Signup
+*   `fs`:Failed Signup
+*   `sv`:Success Verification Email
+*   `fv`:Failed Verification Email
+*   `scp`:Success Change Password
+*   `fcp`:Failed Change Password
+*   `sce`:Success Change Email
+*   `fce`:Failed Change Email
+*   `svr`:Success Verification Email Request
+*   `fvr`:Failed Verification Email Request
+*   `scpr`:Success Change Password Request
+*   `fcpr`:Failed Change Password Request
+*   `fn`:Failed Sending Notification
diff --git a/ja-jp/articles/api/management/v1/reference.md b/ja-jp/articles/api/management/v1/reference.md
new file mode 100644
index 0000000000..3d0af562df
--- /dev/null
+++ b/ja-jp/articles/api/management/v1/reference.md
@@ -0,0 +1,386 @@
+---
+description: Management API V1 reference page.
+section: apis
+toc: true
+topics:
+  - apis
+  - management-api
+contentType: reference
+useCase: invoke-api
+---
+
+# Auth0 Management API Reference
+
+<%= include('../../../_includes/_version_warning_api') %>
+
+### API endpoint
+
+```text
+https://${account.namespace}/api
+```
+
+### Authentication
+Each API request must include an Access Token, either inside the query string:
+
+```text
+https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN}
+```
+
+or in an ```Authorization``` header:
+
+```text
+GET https://${account.namespace}/api/connections
+Authorization: bearer {ACCESS-TOKEN}
+```
+
+A token is obtained using the POST method:
+
+```text
+POST https://${account.namespace}/oauth/token
+Content-type: application/x-www-form-urlencoded
+client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&type=web_server&grant_type=client_credentials
+```
+
+The response body of this POST is a JSON object:
+
+```text
+{
+  'access_token': TOKEN
+  'token_type':'bearer'
+}
+```
+
+Here is a simple example using cURL:
+
+```text
+curl https://${account.namespace}/oauth/token --data "client_id=${account.clientId}&client_secret=YOUR_CLIENT_SECRET&type=web_server&grant_type=client_credentials"
+```
+
+### Headers
+The `Authorization` header is the only accepted header and is used in place of the query string to send the Access Token. All content is  returned in JSON. The `Accept` header is ignored for now.
+
+```text
+Authorization: bearer {ACCESS-TOKEN}
+```
+
+## Connections
+
+### Connection Methods
+| Verb | URL |
+|:-----|:----|
+|`GET` | https://${account.namespace}/api/connections |
+|`GET` | https://${account.namespace}/api/connections/{connectionName} |
+|`POST` | https://${account.namespace}/api/connections |
+|`DELETE`| https://${account.namespace}/api/connections/{connectionName} |
+|`PUT` | https://${account.namespace}/api/connections/{connectionName} |
+
+#### List all Connections
+
+To return a list of all defined connections in Auth0, use this syntax:
+
+```text
+GET https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN}
+```
+
+The body of the response is a `connection` object formatted as follows:
+
+```text
+{
+  "client_id": "${account.clientId}",
+  "name": YOUR-CONNECTION-NAME,
+  "options":
+  {
+    ...
+  },
+  "status": 0,
+  "strategy": STRATEGY
+}
+```
+
+#### Parameters
+| Parameter  | Description |
+|:-----------|:------------|
+| `client_id`| Your client_id (${account.clientId}), used to obtain the authentication token.           |
+| `name` | The unique name you gave to the connection.                                |
+| `status` | Defines whether the connection is active `1` or not `0`. |
+| `strategy` | The type of identity provider associated with this connection. See below for supported strategies.|
+| `options` | An object with properties that are dependent on the strategy selected. |
+
+
+#### Strategies
+
+| Strategy | For Customers Using |
+|:---------|:--------------------|
+| `adfs` | On Premises Active Directory or any WS-Federation server |
+| `g-suite` | G Suite |
+| `google-oauth2` |Google (through the OAuth2 protocol) |
+| `office365` | Office 365 and Microsoft Azure Active Directory |
+| `windowslive` | Microsoft Account (formerly LiveID) |
+
+When implementing the `office365`, `g-suite` or `adfs` strategies, the following properties are added to the connection object:
+
+```text
+provisioning_ticket: TICKET
+provisioning_ticket_url: PROVISIONING-URL
+```
+
+The `provisioning_ticket_url` is sent to the identity provider administrator and contains information on how to complete the configuration on their side.
+
+A GET on `connections` with a specified `{connectionName}` in the path will return the matching connection object only.
+
+###### The cURL sample scripts
+
+This script returns a specific connection:
+
+```text
+curl https://${account.namespace}/api/connections/?access_token={YOUR ACCESS TOKEN}
+```
+
+This script returns all connections:
+
+```text
+curl https://${account.namespace}/api/connections/{YOUR-CONNECTION-NAME}?access_token={YOUR ACCESS TOKEN}
+```
+
+##### Options
+
+The `options` object returned in the `connection` will be different for each strategy and will typically contain the same information that was entered on the [connections](${manage_url}/#/connections) screen.
+
+###### ADFS Strategy
+
+```text
+{
+  tenant_domain: A-DOMAIN,
+  adfs_server: YOUR-FEDERATION-METADATA-ENDPOINT,
+  thumbprints: [ '9b250aad7e4950604072ffaa60cde7795f23b52a',
+    'f97702a42c893a0fb1bc6dad21c79fb720473a85',
+    '9b250aad7e4955604072faca60cde7795f23b52a',
+    'f97702a42c893a0fb1bc6dad21c79fb720473a85',
+    '9b250aad7e4956704072ffaa60cde7795f23b52a',
+    'f97702a42c893a0fb1b546dad21c79fb720473a85',
+    '9b250aad7e4959804072ffaa60cde7795f23b52a' ],
+  signInEndpoint: ADFS-LOGIN-PAGE
+}
+```
+
+| Parameter | Description |
+|:----------|:------------|
+| `tenant_domain` | The domain name of the company (If the user's email is _john @mycompany.com_, then _mycompany.com_ is the domain). |
+| `adfs_server` | (for example: `the-adfs-server.domain.com/FederationMetadata/2007-06/FederationMetadata.xml`). |
+| `signInEndpoint`| The URL of the ADFS server where Auth0 will redirect users for login. (for example: `the-adfs-server.company.com/adfs/ls`). |
+
+###### G Suite Strategy
+
+```text
+{
+  client_id: GOOG-CLIENT-ID,
+  client_secret: GOOG-CLIENT-SECRET,
+  tenant_domain: 'company.com',
+  email: true/false,
+  profile: true/false,
+  ext_groups: true/false,
+  ext_is_admin: true/false,
+  ext_is_suspended: true/false,
+  ext_agreed_terms: true/false,
+  api_enable_users: true/false,
+  scope: [ 'https://www.googleapis.com/auth/userinfo.email',
+       'https://www.googleapis.com/auth/userinfo.profile' ]
+}
+```
+
+To obtain the `client_id` and `client_secret` for G Suite connections, see [Google connections](/connections/social/google).
+
+###### Google OAuth2 Strategy
+
+```text
+{
+  client_id: 'GOOG-CLIENT-ID',
+  client_secret: 'GOOG-CLIENT-SECRET',
+  email: true/false,
+  profile: true/false,
+  contacts: true/false,
+  blogger: true/false,
+  calendar: true/false,
+  gmail: true/false,
+  google_plus: true/false,
+  orkut: true/false,
+  picasa_web: true/false,
+  tasks: true/false,
+  youtube: true/false,
+  adsense_management: true/false,
+  google_affiliate_network: true/false,
+  analytics: true/false,
+  google_books: true/false,
+  google_cloud_storage: true/false,
+  content_api_for_shopping: true/false,
+  chrome_web_store: true/false,
+  document_list: true/false,
+  google_drive: true/false,
+  google_drive_files: true/false,
+  latitude_best: true/false,
+  latitude_city: true/false,
+  moderator: true/false,
+  sites: true/false,
+  spreadsheets: true/false,
+  url_shortener: true/false,
+  webmaster_tools: true/false,
+  scope: []
+}
+```
+
+###### Office 365 Strategy
+
+```text
+{
+  client_id: 'OFFICE-365-CLIENT-ID',
+  client_secret: 'OFFICE-365-CLIENT-SECRET',
+  tenant_domain: 'CONNECTION-DOMAIN-ON-OFFICE-365',
+  basic_profile: true/false,
+  ext_profile: true/false,
+  ext_groups: true/false,
+  ext_assigned_plans: true/false,
+  api_enable_users: true/false,
+  app_domain: '${account.namespace}',
+  thumbprints: []
+}
+```
+
+To obtain `client_id` and `client_secret` for Office 365 connections, see [o365-clientid](/o365-clientid).
+
+
+###### Microsoft Account Strategy
+
+```text
+{
+  client_id: 'MSFT-ACCOUNT-CLIENT-ID',
+  client_secret: 'MSFT-ACCOUNT-CLIENT-SECRET',
+  signin: true/false,
+  emails: true/false,
+  postal_addresses: true/false,
+  birthday: true/false,
+  work_profile: true/false,
+  basic: true/false,
+  offline_access: true/false,
+  calendars: true/false,
+  calendars_update: true/false,
+  contacts_birthday: true/false,
+  contacts_create: true/false,
+  contacts_calendar: true/false,
+  contacts_photos: true/false,
+  contacts_skydrive: true/false,
+  events_create: true/false,
+  messenger: true/false,
+  phone_numbers: true/false,
+  photos: true/false,
+  share: true/false,
+  skydrive: true/false,
+  skydrive_update: true/false,
+  applications: true/false,
+  applications_create: true/false,
+  scope: []
+}
+```
+
+To obtain `client_id` and `client_secret` for Microsoft Accounts, see [Microsoft Account Client ID](/ms-account-clientid).
+
+#### Get a specific Connection
+
+```text
+GET https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=...
+```
+
+#### Delete a connection
+
+A Delete operation on the `connections` object will eliminate the connection definition permanently. The parameter for this operation is the name of the connection to delete.
+
+```text
+DELETE https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=...
+```
+
+If successful, the response body will contain a confirmation object:
+```text
+{
+  "removed": {id}
+}
+```
+
+::: note
+Batch operations are not yet supported.
+:::
+
+#### Create a new Connection
+
+To create a new connection, POST a connection object to the `connections` resource:
+
+```text
+POST https://${account.namespace}/connections
+Content-Type: application/json
+```
+
+The body of the request is formatted as a `connection` object. For example, the following will create a new connection to G Suite, initially inactive (`status=0`):
+
+```text
+{
+  "name": A-NAME-FOR-THIS-CONNECTION
+  "status": 0,
+  "options":
+  {
+  "client_id": GOOG-APPS-CLIENT-ID,
+  "client_secret": GOOG-APPS-CLIENT-SECRET,
+  "tenant_domain": GOOG-APP-DOMAIN,
+  "ext_groups":true //Optional
+  },
+  "strategy": "g-suite"
+};
+```
+
+Once again, the `options` object is dependent on the strategy specified.
+
+If successful, the response body will contain a complete `connection` object. This will include additional fields (such as the entity `id`, and so on).
+
+#### Updating a Connection
+
+For updates, use the PUT method. A PUT works on a specific `connection`, therefore the connection `name` must be specified. All object parameters must be included, not only those which have changed.
+
+### Users
+| Verb | URL | Description |
+|:-----|:----|:------------|
+|`GET` |https://${account.namespace}/api/users |Gets all users who have logged in through any of your connections. |
+|`GET` |https://${account.namespace}/api/connections/{connection}/users|Gets all users from an enterprise directory like Office365 / Microsoft Azure Active Directory or a G Suite domain.|
+|`GET` |https://${account.namespace}/api/socialconnections/users |Gets all users who have logged in through any of the enabled social connections. |
+
+::: note
+If the connection does not support querying for users (for instance: ADFS), the `GET https://${account.namespace}/api/connections/{connection}/users` will return users who have logged in through that connection.
+:::
+
+#### The User Object
+
+```text
+{
+  _id: '7eb1ae32568910b0f46e981aa99b56556',
+  email: 'john@fabrikam.com',
+  family_name: 'Fabrikam',
+  given_name: 'John',
+  identities: [],
+  issuer: 'https://the-adfs-server.fabrikam.com',
+  lastLogin: '2013-01-15T01:54:30.578Z',
+  loginsCount: 13,
+  name: 'John Fabrikam',
+  nickname: 'john',
+  picture: 'https://secure.gravatar.com/avatar/5426f6b9d63ad92d60e6fe9fdf83aa21?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png',
+  user_id: 'adfs|john@fabrikam.com'
+}
+```
+
+Most attributes in the `user` object are self-explanatory. Some comments are below:
+
+|Parameter | Description |
+|:---------|:------------|
+|`issuer` | The name of the authentication server. In the example above it is the URL of Fabrikam's ADFS server used.|
+|`user_id` | (for example: _the-adfs-server.domain.com/FederationMetadata/2007-06/FederationMetadata.xml_). |
+|`picture` | The URL of the user's gravatar, if available. |
+|`user_id` | A "friendly" unique identifier composed of the strategy plus a unique identifier from the `issuer` (for example: email, and so on). |
+
+#### Other resources
+
+* [Auth0 node module](/node-auth0client). A simple client library for Node.js apps.
diff --git a/ja-jp/articles/api/management/v2/changes.md b/ja-jp/articles/api/management/v2/changes.md
new file mode 100644
index 0000000000..b81792b5c1
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/changes.md
@@ -0,0 +1,245 @@
+---
+description: Describes the major differences between Auth0's Management API v1 and Management API v2, and details the reasons for each change.
+section: apis
+crews: crew-2
+toc: true
+topics:
+    - management-api
+    - apis
+contentType: reference
+useCase: invoke-api
+---
+# Management API v1 vs v2
+
+This document describes the major differences between Auth0's Management API v1 and the new Management API v2, and details the reasons for each change.
+
+## tl;dr
+
+* v2 uses JWTs instead of opaque tokens.
+* v2 includes `user_metadata` for trivial data about users and `app_metadata` for data that affects how your application functions. Unlike `metadata` in API v1, these fields are not merged into the root `user` object.
+* Fewer endpoints on existing features make development easier.
+* All endpoints work with ids. Strings (such as `connection_name`) are no longer used.
+* New formats for `user_id` (available as `v2_id` with the "usr\_" prefix) and `clientID` (with the "cli\_" prefix) recognize the entity type based on its id.
+* Improved input validation and error messages.
+* Only one connection is exposed per tenant, instead of one per application. To enable/disable a connection for an application, use the `enabled_clients` property.
+* When updating field values, v2 removes fields with `null` values, instead of storing them with the value `null`
+
+### User endpoints
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /api/users](/api/v1#!#get--api-users) | None. | [GET /api/v2/users](/api/v2#!/Users/get_users) |
+| [GET /api/users?search={criteria}](/api/v1#!#get--api-users-search--criteria-) | Changed parameter and syntax. | See the [get_users](/api/v2#!/Users/get_users) documentation. |
+| [GET /api/users/{user\_id}](/api/v1#!#get--api-users--user_id-) | None. | [GET /api/v2/users/{id}](/api/v2#!/Users/get_users_by_id) also accepts `v2\_id` |
+| [GET /api/connections/{connection}/users](/api/v1#!#get--api-connections--connection--users) | Changed to use search. | Available using `q=identities.connection:"{connection}"` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. |
+| [GET /api/connections/{connection}/users?search={criteria}](/api/v1#!#get--api-connections--connection--users-search--criteria-) | Changed to use search. | Available using `q=identities.connection:"{connection}"` and `search_engine=v3` in the query string. Other conditions and criteria may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. **For enterprise connections**, only supports searching users that have previously logged in; **external user search is no longer supported.** |
+| [GET /api/enterpriseconnections/users?search={criteria}](/api/v1#!#get--api-enterpriseconnections-users-search--criteria-) | Changed to use search. | Available using `q=identities.isSocial:false AND NOT identities.provider:auth0` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. Only supports searching users that have previously logged in; **external user search is no longer supported.** |
+| [GET /api/socialconnections/users?search={criteria}](/api/v1#!#get--api-socialconnections-users-search--criteria-) |  Changed to use search. | Available using `q=identities.isSocial:true` and `search_engine=v3` in the query string. Other conditions may be added to the search. See the [get_users](/api/v2#!/Users/get_users) documentation. |
+| [GET /api/clients/{client-id}/users](/api/v1#!#get--api-socialconnections-users-search--criteria-) | Removed. | Removed. |
+| [POST /api/users](/api/v1#!#post--api-users) | None. | [POST /api/v2/users](/api/v2#!/Users/post_users) |
+| [POST /api/users/{user\_id}/change\_password\_ticket](/api/v1#!#post--api-users--user_id--change_password_ticket) | None. | [POST /api/v2/tickets/password-change](/api/v2#!/tickets/post_password_change) |
+| [POST /api/users/{user\_id}/verification\_ticket](/api/v1#!#post--api-users--user_id--verification_ticket) | None. | [POST /api/v2/tickets/email-verification](/api/v2#!/tickets/post_email_verification) |
+| [POST /api/users/{user\_id}/publickey](/api/v1#!#post--api-users--user_id--publickey) | Keys are created per device, not per user. | [POST /api/v2/device-credentials](/api/v2#!/Device_Credentials/post_device_credentials) |
+| [PUT /api/users/{user\_id}/email](/api/v1#!#put--api-users--user_id--email) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id`. |
+| [PUT /api/users/{user\_id}/metadata](/api/v1#!#put--api-users--user_id--metadata) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` |
+| [PUT /api/users/{user\_id}/password](/api/v1#!#put--api-users--user_id--password) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` |
+| [PUT /api/users/{email}/password](/api/v1#!#put--api-users--email--password) | Removed. | Endpoints only accept ids, not strings. |
+| [PATCH /api/users/{user\_id}/metadata](/api/v1#!#patch--api-users--user_id--metadata) | Removed. | [PATCH /api/v2/users/{id}](/api/v2#!/Users/patch_users_by_id) also accepts `v2_id` |
+| [DELETE /api/users](/api/v1#!#delete--api-users) | None. | [DELETE /api/v2/users](/api/v2#!/Users/delete_users) |
+| [DELETE /api/users/{user\_id}](/api/v1#!#delete--api-users--user_id-) | None. | [DELETE /api/v2/users/{id}](/api/v2#!/Users/delete_users_by_id) also accepts `v2_id` |
+| [DELETE /api/users/{user\_id}/refresh_tokens/{refresh\_token}](/api/v1#!#delete--api-users--user_id--refresh_tokens--refresh_token-) | Tokens and public keys are device credentials. | [DELETE /api/v2/device-credentials/{id}](/api/v2#!/Device_Credentials/delete_device_credentials_by_id) |
+| [DELETE /api/users/{user\_id}/publickey?device={device}](/api/v1#!#delete--api-users--user_id--publickey-device--device-) | Tokens and public keys are device credentials. | [DELETE /api/v2/device-credentials/{id}](/api/v2#!/Device_Credentials/delete_device_credentials_by_id) |
+| [POST /api/users/{user_id}/send_verification_email](/api/v1#!#post--api-users--user_id--send_verification_email) | None. | [POST /api/v2/jobs/verification-email](/api/v2#!/Jobs/post_verification_email)
+
+
+### Application endpoints
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /api/clients](/api/v1#!#get--api-clients) | None. | [GET /api/v2/clients](/api/v2#!/Clients/get_clients) |
+| [POST /api/clients](/api/v1#!#post--api-clients) | None. | [POST /api/v2/clients](/api/v2#!/Clients/post_clients) |
+| [PUT /api/clients/{client-id}](/api/v1#!#put--api-clients--client-id-) | Removed. | [PUT /api/v2/clients/{id}](/api/v2#!/Clients/patch_clients_by_id) |
+| [PATCH /api/clients/{client-id}](/api/v1#!#patch--api-clients--client-id-) | None. | [PATCH /api/v2/clients/{id}](/api/v2#!/Clients/patch_clients_by_id) |
+| [DELETE /api/clients/{client-id}](/api/v1#!#delete--api-clients--client-id-) | None. | [DELETE /api/v2/clients/{id}](/api/v2#!/Clients/delete_clients_by_id) |
+
+### Connection endpoints
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /api/connections](/api/v1#!#get--api-connections) | None. | [GET /api/v2/connections](/api/v2#!/Connections/get_connections) |
+| [GET /api/connections/{connection-name}](/api/v1#!#get--api-connections--connection-name-) |  Use `id` instead of `connection-name`. | [GET /api/connections/{id}](/api/v2#!/Connections/get_connections_by_id) |
+| [POST /api/connections](/api/v1#!#post--api-connections) | Added `enabled_clients` property. | [POST /api/v2/connections](/api/v2#!/Connections/post_connections) |
+| [PUT /api/connections/{connection-name}](/api/v1#!#put--api-connections--connection-name-) | Removed; use `id` instead of `connection-name`. | [PATCH /api/v2/connections/{id}](/api/v2#!/Connections/patch_connections_by_id) |
+| [DELETE /api/connections/{connection-name}](/api/v1#!#delete--api-connections--connection-name-) | Use `id` instead of `connection-name`. | [DELETE /api/v2/clients/{id}](/api/v2#!/Connections/delete_connections_by_id) |
+| [GET /api/connections/{connection}/users](/api/v1) | None. | [GET /api/v2/users](/api/v2#!/Users/get_users) (see note) |
+| [GET /api/connections/{connection}/socket](/api/v1) | None. | [GET /api/v2/connections/{id}/status](/api/v2#!/Connections/get_status) |
+
+::: note
+For Private Cloud (search_engine:v2), use `q=identities.connection:"connection_name"`
+:::
+
+### Rules endpoints
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /api/rules](/api/v1#!#get--api-rules-) | None. | [GET /api/v2/rules](/api/v2#!/Rules/get_rules) |
+| [POST /api/rules](/api/v1#!#post--api-rules) | None. | [POST /api/v2/rules](/api/v2#!/Rules/post_rules-) |
+| [PUT /api/rules/{rule-name}](/api/v1#!#put--api-rules--rule-name-) | Removed; use `id` instead of `rule-name`. | [PATCH /api/v2/rules/{id}](/api/v2#!/Rules/patch_rules_by_id) |
+| [DELETE /api/rules/{rule-name}](/api/v1#!#delete--api-rules--rule-name-) | Use `id` instead of `rule-name`. | [DELETE /api/v2/rules/{id}](/api/v2#!/Rules/delete_rules_by_id) |
+| [GET /api/rules-configs](/api/v1) | None. | [GET /api/v2/rules-configs](/api/v2#!/Rules_Configs/get_rules_configs) |
+| [POST /api/rules-configs](/api/v1) | Removed; perform one call per variable to update. | [PUT /api/v2/rules-configs/{key}](/api/v2#!/Rules_Configs/put_rules_configs_by_key) |
+
+### Logs endpoints
+
+Logs endpoints in Management API v2 are described at [Search Log Events](https://auth0.com/docs/api/management/v2#!/Logs/get_logs)
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /logs](/api/v1#logs) | Syntax Changes, described at [Breaking Changes](https://auth0.com/docs/logs/query-syntax#search-engine-v3-breaking-changes) | [GET /api/v2/logs](/api/v2#!/Logs/get_logs) |
+| [GET /logs/{id}](/api/v1#logs) | None. | [GET /api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id) |
+
+### Email Templates endpoints
+
+| v1 Endpoint | Change | v2 Endpoint |
+| ----------- | ------ | ----------- |
+| [GET /api/emails/{email-template-name}](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [GET	/api/v2/email-templates/{templateName}](/api/v2#!/Email_Templates/get_email_templates_by_templateName) |
+| [POST /api/emails](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [POST	/api/v2/email-templates](https://auth0.com/docs/api/management/v2#!/Email_Templates/post_email_templates) |
+| [PUT /api/emails/{email-template-name}](/api/v1#email-templates) | `disabled` renamed to `enabled`. | [PUT	/api/v2/email-templates/{templateName}](https://auth0.com/docs/api/management/v2#!/Email_Templates/put_email_templates_by_templateName) |
+
+## Authentication mechanism
+
+Auth0's API v1 requires sending an Access Token obtained by performing a [`POST /oauth/token`](/api/v1#!#post--oauth-token) request along with the `clientId` and `clientSecret`. All subsequent requests must include the Access Token in the `Authorization` header: `Authorization: Bearer {access_token}`.
+
+Auth0's API v2 requires sending an Access Token with specific scope(s). To perform requests with API v2, use the `Authorization` header: `Authorization: Bearer YOUR_ACCESS_TOKEN`.
+
+To use an endpoint, at least one of its available scopes (as listed in [Management API v2 explorer](/api/v2)) must be specified for the JWT. The actions available on an endpoint depend on the JWT scope. For example, if a JWT has the `update:users_app_metadata` scope, the [PATCH users `app_metadata`](/api/v2#!/Users/patch_users_by_id) action is available, but not other properties.
+
+There is a subset of scopes that your application can use in order to perform a subset of operations on behalf of the currently logged-in user. These are:
+
+* `read:current_user`
+* `update:current_user_identities`
+* `create:current_user_metadata`
+* `update:current_user_metadata`
+* `delete:current_user_metadata`
+* `create:current_user_device_credentials`
+* `delete:current_user_device_credentials`
+
+So, for example, if the Access Token contains the scope `update:current_user_metadata` then it can be used to update the metadata of the currently logged-in user. If, on the other hand, it contains the scope `update:users_app_metadata` it can be used to update the metadata of any user.
+
+## User metadata
+
+In the Management API v1, [`user.metadata`](/api/v1#!#patch--api-users--user_id--metadata) provides additional user information that is not part of the default user claims. When working with rules and other API endpoints, `metadata` is merged into the root user. For example, if the following data is stored for a user with `email` "jane.doe@gmail.com":
+
+```javascript
+{
+  metadata: {
+    hobby: 'surf'
+  }
+}
+```
+
+when working with rules or retrieving the user from the API, you would get:
+
+```javascript
+console.log(user.email); // "jane.doe@gmail.com"
+console.log(user.hobby); // "surf"
+```
+
+Note that `user.metadata.hobby` is not being used.
+
+This automatic merging caused confusion for our customers. Also, having a single bucket for all metadata did not work well with our new permissions model for the following reasons:
+
+* You may want to store information in `metadata` that was core to your application's functionality.
+* You may want to allow your users to update their own metadata.
+
+### app\_metadata and user\_metadata
+
+In API v2 the concept of `metadata` is divided into:
+
+* `app_metadata`: Data related to the user that affects the application's core functionality.
+* `user_metadata`: Data related to the user that does not affect the application's core functionality.
+
+Neither of these two properties are merged into the root `user` object. If you stored:
+
+```javascript
+{
+  user_metadata: {
+    hobby: 'surf'
+  },
+  app_metadata: {
+    plan: 'full'
+  }
+}
+```
+
+when working in rules or retrieving users from the API you would get:
+
+```javascript
+console.log(user.email); // "jane.doe@gmail.com"
+console.log(user.user_metadata.hobby); // "surf"
+console.log(user.app_metadata.plan); // "full"
+```
+
+::: note
+User data previously stored under `metadata` will be available under `app_metadata`.
+:::
+
+## Connections
+
+For every tenant-created, named connection, Management API v1 exposes an individual connection for each of the tenant's applications.
+
+However, given a named connection, Management API v2 exposes only one connection per tenant. Management of connection-enabled applications is performed using the `enabled_clients` property.
+
+For example, to create a connection that is enabled for applications `AaiyAPdpYddboKnqNS8HJqRn4T5ti3BQ` and `DaM8bokEXBWrTUFZiXjWn50jei6ardyV`:
+
+```text
+curl -H "Authorization: Bearer {API_TOKEN}" -X POST -H "Content-Type: application/json"
+-d '{"name":"new-connection","strategy":"auth0","enabled_clients":["AaiyAPdpYddboKnqNS8HJqRn4T5ti3BQ","DaM8bokEXBWrTUFZiXjWn50jei6ardyV"]}'
+https://{YOUR_TENANT}.auth0.com/api/v2/connections
+```
+
+Connection names cannot be used to manage connections. Instead use the new `id` property. For example, to retrieve the connection with id `'con_UITxoKznrqb1oxIU'`:
+
+```text
+curl -H "Authorization: Bearer {API_TOKEN}"
+https://{YOUR_TENANT}.auth0.com/api/v2/connections/con_UITxoKznrqb1oxIU
+```
+
+## Endpoints
+
+Some of the changes to endpoints are detailed below.
+
+### Consolidation
+
+In Management API v1, different endpoints are used to update the various user properties. For example, changing the following user properties requires using these separate endpoints:
+
+* [`PUT /api/users/{user_id}/email`](/api/v1#!#put--api-users--user_id--email)
+* [`PUT /api/users/{user_id}/metadata`](/api/v1#!#put--api-users--user_id--metadata)
+* [`PUT /api/users/{user_id}/password`](/api/v1#!#put--api-users--user_id--password)
+
+In API v2, these are simplified into the single endpoint [`PATCH /api/v2/users/{id}`](/api/v2#!/Users/patch_users_by_id) which allows you to modify these (and other) user properties.
+
+### All endpoints require ids
+
+All endpoints receive an id. This change affects **Rules** and **Connections** particularly.
+
+Some endpoints, such as [`PUT /api/users/{email}/password`](/api/v1#!#put--api-users--email--password), are no longer available.
+
+### Improved input validation and error messages
+
+In Management API v2, all endpoints use [JSON schemas](http://json-schema.org) to validate input. Also, descriptive error messages are returned when a schema's constraints are not met.
+
+For an example, see the methods in our [Management API v2 explorer](/api/v2).
+
+## PATCH with null values
+
+In API v1, when updating field values, if the field is `null`, it will be saved as `null` in the database. In API v2, a `null` field will result in the field being deleted from the database.
+
+Example: `{metadata: {color: null}}`
+
+Will be stored as follows:
+
+* When using API v1: `{metadata: {color: null}}`
+* When using API v2: `{user_metadata: {}}`
+
+So, in API v1, the field's value is stored as `null`, but in API v2, the field is simply removed.
diff --git a/ja-jp/articles/api/management/v2/create-m2m-app.md b/ja-jp/articles/api/management/v2/create-m2m-app.md
new file mode 100644
index 0000000000..ef3cf0d79c
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/create-m2m-app.md
@@ -0,0 +1,44 @@
+---
+description: How to create and authorize a machine-to-machine application for calling Management API endpoints using Access Tokens.
+section: apis
+toc: true
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - how-to
+useCase: invoke-api
+---
+
+# Create and Authorize a Machine-to-Machine Application
+
+The first time you get a token for the Management API is when you complete the configuration in the Auth0 [Dashboard](${manage_url}). You won't have to do this again unless you create a new tenant. We recommend that you create a token exclusively for authorizing access to the Management API instead of reusing another one you might have.
+
+To create and authorize a Machine-to-Machine Application for the Management API:
+
+1. Go to [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer)
+2. Click the button __Create & Authorize a Test Application__. A new application has been created and it's authorized to access the Management API.
+
+![Create and Authorize Application](/media/articles/api/tokens/create-authorize-client.png)
+
+The application created in the steps above has been granted __all__ the Management API scopes. This means that it can access all endpoints.
+
+::: panel How can I find out which scopes/permissions are required?
+Each machine-to-machine application that accesses an API must be granted a set of scopes. Scopes are permissions that should be granted by the owner. Each [Auth0 Management API v2](/api/management/v2) endpoint requires specific scopes. To see the required scopes/permissions for each endpoint, go to the [Management API Explorer](/api/management/v2#!) and find the endpoint you want to call. Each endpoint has a section called **Scopes** listing all the scopes that the endpoint requires. For example, the [Get all clients](/api/management/v2#!/Clients/get_clients) endpoint requires the scopes `read:clients` and `read:client_keys`.
+:::
+
+## Example: Get All Clients Endpoint
+
+The [Get all clients](/api/management/v2#!/Clients/get_clients) endpoint requires the scopes `read:clients` and `read:client_keys`, while the [Create an application](/api/management/v2#!/Clients/post_clients) endpoint requires the scope `create:clients`. From that we can deduce that if we need to read _and_ create applications, then our token should include three scopes: `read:clients`, `read:client_keys` and `create:clients`.
+
+If you have multiple applications that should access the Management API, and you need different sets of scopes per app, we recommend creating a new machine-to-machine application for each one. For example, if one application is to read and create users (`create:users`, `read:users`) and another to read and create applications (`create:clients`, `read:clients`) create two applications (one for user scopes, one for applications) instead of one.
+
+## Keep reading
+
+* [Get Access Tokens for Testing](/api/management/v2/get-access-tokens-for-test)
+* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production)
+* [Get Management API Tokens for Single-page Applications](/api/management/v2/get-access-tokens-for-spas)
+* [Applications](/applications)
+* [Management API Explorer](/api/management/v2#!)
+* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens)
diff --git a/ja-jp/articles/api/management/v2/faq-management-api-access-tokens.md b/ja-jp/articles/api/management/v2/faq-management-api-access-tokens.md
new file mode 100644
index 0000000000..28600870ec
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/faq-management-api-access-tokens.md
@@ -0,0 +1,33 @@
+---
+description: FAQs for Management API Access Tokens
+section: apis
+toc: true
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - reference
+useCase: invoke-api
+---
+
+# Management API Access Token FAQs
+
+__How long is the token valid for?__
    
+The Management API token has by default a validity of __24 hours__. After that the token will expire and you will have to get a new one. If you get one manually from [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer) though, you can change the expiration time. However, having non-expiring tokens is not secure.
+
+__The old way of generating tokens was better, since the token never expired. Why was this changed?__
    
+The old way of generating tokens was insecure since the tokens had an infinite lifespan. The new implementation allows tokens to be generated with specific scopes and expirations. We decided to move to the most secure implementation because your security, and that of your users, is priority number one for us.
+
+__Can I change my token's validity period?__
    
+You cannot change the default validity period, which is set to 24 hours. However, if you get a token manually from [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer) you can change the expiration time for the specific token. Note though, that your applications should use short-lived tokens to minimize security risks.
+
+__Can I refresh my token?__
    
+You cannot renew a Management API token. A [new token](#2-get-the-token) should be created when the old one expires.
+
+__My token was compromised! Can I revoke it?__
    
+You cannot directly revoke a Management API token, thus we recommend a short validity period.
+Note that deleting the application grant will prevent *new tokens* from being issued to the application. You can do this either by [using our API](/api/management/v2#!/Client_Grants/delete_client_grants_by_id), or manually [deauthorize the API application using the dashboard](${manage_url}/#/apis/management/authorized-applications).
+
+__My Client Secret was compromised! What should I do?__
    
+You need to change the secret immediately. Go to your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings) and click the __Rotate__ icon , or use the [Rotate a client secret](/api/management/v2#!/Clients/post_rotate_secret) endpoint. Note that previously issued tokens will continue to be valid until their expiration time.
diff --git a/ja-jp/articles/api/management/v2/get-access-tokens-for-production.md b/ja-jp/articles/api/management/v2/get-access-tokens-for-production.md
new file mode 100644
index 0000000000..fdb44e1706
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/get-access-tokens-for-production.md
@@ -0,0 +1,180 @@
+---
+description: How to get Access Tokens to make scheduled frequent calls to the Management API.
+section: apis
+toc: true
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - how-to
+useCase: invoke-api
+---
+
+# Get Access Tokens for Production
+
+To make scheduled frequent calls for a production environment, you have to build a process at your backend that will provide you with a token automatically (and thus simulate a non-expiring token).
+
+## Prerequisite
+
+* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app). 
+
+## Get Access Tokens
+
+To ask Auth0 for a Management API v2 token, perform a `POST` operation to the `https://${account.namespace}/oauth/token` endpoint, using the credentials of the Machine-to-Machine Application you created in the prerequisite step.
+
+The payload should be in the following format:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+        {
+          "name": "grant_type",
+          "value": "client_credentials"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        },
+        {
+          "name": "audience",
+          "value": "https://${account.namespace}/api/v2/"
+        }
+    ]
+  }
+}
+```
+
+The request parameters are:
+
+| __Request Parameter__ | __Description__ |
+| ------ | ----------- |
+| __grant_type__ | Denotes which [OAuth 2.0 flow](/protocols/oauth2#authorization-grant-types) you want to run. For machine to machine communication use the value `client_credentials`. |
+| __client_id__ | This is the value of the __Client ID__ field of the Machine-to-Machine Application you created. You can find it on the [Settings tab of your Application](${manage_url}/#/applications/${account.clientId}/settings). |
+| __client_secret__ | This is the value of the __Client Secret__ field of the Machine-to-Machine Application you created. You can find it at the [Settings tab of your Application](${manage_url}/#/applications/${account.clientId}/settings). |
+| __audience__ | This is the value of the __Identifier__ field of the `Auth0 Management API`. You can find it at the [Settings tab of the API](${manage_url}/#/apis). |
+
+The response will contain a [signed JWT](/tokens/concepts/jwts), when it expires, the scopes granted, and the token type.
+
+```json
+{
+  "access_token": "eyJ...Ggg",
+  "expires_in": 86400,
+  "scope": "read:clients create:clients read:client_keys",
+  "token_type": "Bearer"
+}
+```
+
+From the above we can see that our Access Token is a [Bearer Access Token](https://tools.ietf.org/html/rfc6750), it will expire in 24 hours (86400 seconds), and it has been authorized to read and create applications.
+
+### Use Auth0's Node.js Client Library
+
+As an alternative to making HTTP calls, you can use the [node-auth0](https://www.npmjs.com/package/auth0) library to automatically [obtain tokens for the Management API](https://www.npmjs.com/package/auth0#user-content-management-api-client).
+
+## Use Access Tokens
+
+To use this token, include it in the `Authorization` header of your request.
+
+```har
+{
+  "method": "POST",
+  "url": "http://PATH_TO_THE_ENDPOINT/",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN"}
+  ]
+}
+```
+
+For example, in order to [Get all applications](/api/management/v2#!/Clients/get_clients) use the following:
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/clients",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5ESTFNa05DTVRGQlJrVTRORVF6UXpFMk1qZEVNVVEzT1VORk5ESTVSVU5GUXpnM1FrRTFNdyJ9.eyJpc3MiOiJodHRwczovL2RlbW8tYWNjb3VudC5hdXRoMC5jb20vIiwic3ViIjoib9O7eVBnMmd4VGdMNjkxTnNXY2RUOEJ1SmMwS2NZSEVAY2xpZW50cyIsImF1ZCI6Imh0dHBzOi8vZGVtby1hY2NvdW50LmF1dGgwLmNvbS9hcGkvdjIvIiwiZXhwIjoxNDg3MDg2Mjg5LCJpYXQiOjE5ODY5OTk4ODksInNjb3BlIjoicmVhZDpjbGllbnRzIGNyZWF0ZTpjbGllbnRzIHJlYWQ6Y2xpZW50X2tleXMifQ.oKTT_cEA_U6hVzNYPCl_4-SnEXXvFSOMJbZyFydQDPml2KqBxVw_UPAXhjgtW8Kifc_b2HQ4jFh7nH0KC_j1XjfEJPvwFZgqfI_ILzO3DPfpEIK_n_aX-Tz4okbZe6nj2aT_qLpHimLxK50jOGaMuzp4a1djHJTj5q-NbIiPW8AJowS2-gveP4T3dyyegUsZkmTNwrreqppPApmpWWE-wVsxnVsI_FZFrHnq0rn7lmY_Iz6vyiZjaKrd2C3hFm0zFGTn8FslBfHUldTcDNzOKOpCq7HFMeU0urXBXDetrzkW1afxIqED3G2C51JEV-4nTRYUinnWgXJfLJ87G3ge_A"}
+  ]
+}
+```
+
+::: note
+You can get the curl command for each endpoint from the Management API v2 Explorer. Go to the endpoint you want to call, and click the __get curl command__ link at the __Test this endpoint__ section.
+:::
+
+## Example: Python Implementation
+
+This python script gets a Management API v2 Access Token, uses it to call the [Get all applications](/api/management/v2#!/Clients/get_clients) endpoint, and prints the response in the console.
+
+Before you run it make sure that the following variables hold valid values:
+- `audience`: The __Identifier__ of the `Auth0 Management API`. You can find it at the [Settings tab of the API](${manage_url}/#/apis).
+- `domain`: The __Domain__ of the Machine-to-Machine Application you created.
+- `client_id`: The __Client ID__ of the Machine to Machine Application you created.
+- `client_secret`: The __Client Secret__ of the Machine-to-Machine Application you created.
+
+```python
+def main():
+  import json, requests
+  from requests.exceptions import RequestException, HTTPError, URLRequired
+  
+  # Configuration Values
+  audience = f"https://${account.namespace}/api/v2/"
+  domain = "${account.namespace}"
+  client_id = "${account.clientId}"
+  client_secret = "YOUR_CLIENT_SECRET"
+  grant_type = "client_credentials" # OAuth 2.0 flow to use
+
+  # Get an Access Token from Auth0
+  base_url = f"https://{domain}"
+  payload =  {'grant_type': 'client_credentials',
+               'client_id': client_id,
+               'client_secret': client_secret,
+               'audience': audience}
+  res = requests.get(base_url, data=payload)
+  oauth = json.loads(response.json())
+  access_token = oauth.get('access_token')
+
+  # Get all Applications using the token
+  res = requests.get(base_url + "/api/v2/clients")
+  header = {
+    'Authorization', 'Bearer ' + access_token,
+    'Content-Type', 'application/json'
+    }
+
+  try:
+    res = request.get(req, header = header)
+    output = json.loads(res.json())
+    print(output)
+  except HTTPError as e:
+    print('HTTPError = ' + str(e.code) + ' ' + str(e.reason))
+  except URLRequired as e:
+    print(f'URLRequired = str(e.reason)')
+  except RequestException as e:
+    print('RequestException: {e}')
+  except Exception as e:
+    print(f'Generic Exception: {e}')
+
+# Standard boilerplate to call the main() function.
+if __name__ == '__main__':
+  main()
+```
+
+## Keep reading
+
+- [Applications](/applications)
+* [Management API Explorer](/api/management/v2#!)
+* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens)
+
+
diff --git a/ja-jp/articles/api/management/v2/get-access-tokens-for-spas.md b/ja-jp/articles/api/management/v2/get-access-tokens-for-spas.md
new file mode 100644
index 0000000000..49f58e6168
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/get-access-tokens-for-spas.md
@@ -0,0 +1,60 @@
+---
+description: Describes available scopes and endpoints for Management API tokens for Single-page Applications (SPAs).
+section: apis
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - how-to
+useCase: invoke-api
+---
+
+# Get Management API Tokens for Single-page Applications
+
+In certain cases, you may want to use Auth0's [Management API](/api/management/v2#!) to manage your applications and APIs rather than the Auth0 Management Dashboard. 
+
+To call any Management API endpoints, you must authenticate using a specialized [Access Token](/tokens/overview-access-tokens) called the Management API Token. Management API Tokens are [JSON Web Tokens (JWTs)](/tokens/concepts/jwts) that contain specific granted permissions (also known as scopes) for the Management API endpoints you want to call. 
+
+## Limitations
+
+Since single-page applications (SPAs) are public clients and cannot securely store sensitive information (such as a **Client Secret**), they must retrieve Management API Tokens from the frontend, unlike other [application types](/applications). This means that Management API Tokens for SPAs have certain limitations. Specifically, they are issued in the context of the user who is currently signed in to Auth0 which limits updates to only the logged-in user's data. Although this restricts use of the Management API, it can still be used to perform actions related to updating the logged-in user's user profile.
+
+::: warning
+Auth0 does not recommend putting Management API Tokens on the frontend that allow users to change user metadata. This can allow users to manipulate their own metadata in a way that could be detrimental to the functioning of the applications. It also allows a customer to do a DoS attack against someone's management API by just spamming it and hitting rate limits.
+:::
+
+## Available scopes and endpoints
+
+With a Management API Token issued for a SPA, you can access the following scopes (and hence endpoints). 
+
+::: note
+Password changes through the [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) endpoint are **not possible** with a Management API Token issued for a SPA.
+:::
+
+| **Scope for Current User** | **Endpoint** |
+| -------------------------- | ------------ |
+| `read:current_user` | [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id) 
     [GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) |
+| `update:current_user_identities` | [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) 
     [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) |
+| `update:current_user_metadata` | [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) |
+| `create:current_user_metadata` | [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) |
+| `delete:current_user_metadata` | [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) |
+| `create:current_user_device_credentials` | [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) |
+| `delete:current_user_device_credentials` | [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) |
+
+::: note
+The above scopes and endpoints are subject to [rate limits](/policies/rate-limits#access-tokens-for-spas).
+:::
+
+## Use Management API Token to call Management API from a SPA
+
+You can retrieve a Management API Token from a SPA and use the token to call the Management API to retrieve the full user profile of the currently logged-in user.
+
+1. Retrieve a Management API token. Authenticate the user by redirecting them to the Authorization endpoint, which is where users are directed upon login or sign-up. When you receive the Management API Token, it will be in [JSON Web Token format](/tokens/references/jwt-structure). Decode it and review its contents.
+
+2. Call the Management API to retrieve the logged-in user's user profile from the [Get User by ID](/api/management/v2#!/Users/get_users_by_id) endpoint. To call the endpoint, include the encoded Management API Token you retrieved in the `Authorization` header of the request. Be sure to replace the `USER_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with the logged-in user's user ID (`sub` value from the decoded Management API Token) and the Management API Access Token, respectively.
+
+## Keep reading
+
+* [Management API Explorer](/api/management/v2#!)
+* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens)
diff --git a/ja-jp/articles/api/management/v2/get-access-tokens-for-test.md b/ja-jp/articles/api/management/v2/get-access-tokens-for-test.md
new file mode 100644
index 0000000000..ad6a3e6b1b
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/get-access-tokens-for-test.md
@@ -0,0 +1,58 @@
+---
+description: How to get an Access Token manually for testing purposes.
+section: apis
+toc: true
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - How-to
+useCase: invoke-api
+---
+
+# Get Access Tokens for Testing
+
+::: warning
+This method for obtaining Access Tokens is **only for test purposes**. Do not get manually long-lived tokens and use them in your applications, because that nullifies the security advantages that tokens offer. 
+:::
+
+## Prerequisite
+
+* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app). 
+
+## Get Access Tokens Manually
+
+1. Go to [the API Explorer tab of your Auth0 Management API](${manage_url}/#/apis/management/explorer). 
+A token is automatically generated and displayed there. 
+
+2. Click __Copy Token__. 
+You can now make authorized calls to the [Management API](/api/management/v2) using this token.
+
+![Test Application](/media/articles/api/tokens/copy-token.png)
+
+3. Set expiration time.
+This token has, by default, an expiration time of __24 hours__ (86400 seconds). After that period, the token expires and you will need to get a new one. To change the expiration time, update the __Token Expiration (Seconds)__ field and click __Update & Regenerate Token__.
+
+:::warning
+These tokens **cannot be revoked** so long expiration times are not recommended. Instead we recommend that you use short expiration times and issue a new one every time you need it.
+:::
+
+## Use Access Tokens for Testing
+
+To use the Access Token you just created for testing purposes, use the [Management API v2 explorer page](/api/management/v2) to manually call an endpoint with the token.
+
+1. Go to the [Management API v2 explorer page](/api/management/v2#!).
+1. Click the __Set API Token__ button at the top left.
+1. Set the __API Token__ field, and click __Set Token__.
+1. Under the __Set API Token__ button at the top left, some new information is now displayed: the domain and token set, and the scopes that have been granted to this application.
+1. Go to the endpoint you want to call, fill any parameters that might be required and click __Try__.
+
+![Set the Token](/media/articles/api/tokens/set-token.png)
+
+## Keep reading
+
+* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production)
+- [Applications](/applications)
+* [Management API Explorer](/api/management/v2#!)
+* [Management API Access Tokens FAQs](/api/management/v2/faq-management-api-access-tokens)
diff --git a/ja-jp/articles/api/management/v2/tokens-flows.md b/ja-jp/articles/api/management/v2/tokens-flows.md
new file mode 100644
index 0000000000..18ddec7612
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/tokens-flows.md
@@ -0,0 +1,49 @@
+---
+description: Describes what changed in the flow for generating Auth0 Management APIv2 tokens and why.
+section: apis
+crews: crew-2
+toc: true
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: concept
+useCase: invoke-api
+---
+# Changes in Auth0 Management APIv2 Tokens
+
+Some time ago, we changed the process of getting a Management APIv2 Token. This article explains what changed, why this was done, and how you can work around it (not recommended).
+
+## What changed and why
+
+### The User Experience
+
+Until recently, you could generate a Management APIv2 Token directly from the Management API explorer. You selected the scopes, according to the endpoint you wanted to invoke, and got a token from that same page.
+
+That way was very easy but it was also __very insecure__. So we changed it.
+
+The new way uses the [Client Credentials Flow](/flows/concepts/client-credentials).
+
+::: note
+For details on how to follow this new process, see [Access Tokens for the Management API](/api/management/v2/tokens).
+:::
+
+#### Why this changed
+
+To generate the token, the Management API required access to your __Global Client Secret__ (used to sign the token). This is information that should __not__ be exposed to web browsers.
+
+Furthermore, the API Explorer has no way to do authorization. This means that if a user could login and access the API explorer, they could generate a token with __any__ scope, even if they were not allowed to have that scope.
+
+The new OAuth 2.0 Client Credentials grant implementation does not pose such risks. Once you do the initial configuration, you can get a token either by visiting the dashboard, or by making a simple `POST` request to [the `/oauth/token` endpoint of our Authentication API](/api/authentication#client-credentials).
+
+However, with regards to the manual process, we do understand that changing screens is not always the best user experience, so we are looking into ways to make the new flow more intuitive.
+
+### The Validity Period
+
+With the previous flow, the tokens never expired. With the new flow, all Management APIv2 Tokens __expire by default after 24 hours__.
+
+#### Why this changed
+
+Having a token that never expires can be very risky, in case an attacker gets hold of it. If the token expires within a few hours the attacker has only a small window to access your protected resources.
+
+To get a token, you should follow only the process described in [Access Tokens for the Management API](/api/management/v2/tokens).
diff --git a/ja-jp/articles/api/management/v2/tokens.md b/ja-jp/articles/api/management/v2/tokens.md
new file mode 100644
index 0000000000..4d99886e40
--- /dev/null
+++ b/ja-jp/articles/api/management/v2/tokens.md
@@ -0,0 +1,38 @@
+---
+description: Overview of how Auth0 Management APIv2 Access Tokens work and how to use them.
+section: apis
+topics:
+  - apis
+  - management-api
+  - tokens
+contentType: 
+    - concept
+useCase: invoke-api
+---
+
+# Access Tokens for the Management API
+
+To call the [Auth0 Management API v2](/api/management/v2) endpoints, you need to authenticate with a token called the __Auth0 Management API Token__. This token is a JSON Web Token (JWT) and it contains specific granted permissions (known as __scopes__).
+
+To call an endpoint for test purposes, you can get a token manually using the Dashboard. For production however, the recommended best practice is to get short-lived tokens programmatically. 
+
+To call endpoints, you will need to do the following:
+
+* [Create and Authorize a Machine-to-Machine Application](/api/management/v2/create-m2m-app)
+* [Get Access Tokens for Testing](/api/management/v2/get-access-tokens-for-test)
+* [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production)
+
+::: note
+For single-page applications (SPAs), there are some limitations. See [Get Management API Tokens for SPAs](/api/management/v2/get-access-tokens-for-spas) for more information.
+:::
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Management API Access Token FAQs](/api/management/v2/faq-management-api-access-tokens)
+* [Changes in Auth0 Management API Tokens](/api/management/v2/tokens-flows)
+* [Client Credentials Flow](/flows/concepts/client-credentials)
+* [Ask for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens)
+* [User Search](/users/search)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+
diff --git a/ja-jp/articles/api/postman.md b/ja-jp/articles/api/postman.md
new file mode 100644
index 0000000000..7bdcb17983
--- /dev/null
+++ b/ja-jp/articles/api/postman.md
@@ -0,0 +1,61 @@
+---
+description: Learn how to use Postman Collections to access Auth0 APIs.
+section: apis
+topics:
+  - management-api
+  - authorization-api
+  - apis
+contentType: how-to
+useCase: invoke-api
+---
+
+# Use Auth0 APIs with Postman Collections
+
+## Install Postman Collections
+
+To install the Postman Collection, you must first install the Postman App for Windows, Mac, or Chrome. You can download any of these from[Postman Apps](https://www.getpostman.com/apps).
+
+Next, visit [Auth0 APIs](/api/info) and install the Collection you want to use by clicking on the relevant **Run in Postman** button.
+
+![Auth0 API Postman Button](/media/articles/api/postman/auth0-api-landing.png)
+
+Postman will prompt whether you want to open the Collection in Postman for Chrome or Postman for Windows/Mac. Select the application you installed.
+
+Once you make a selection, the selected Postman application will open and the collection will be imported.
+
+Our API Collections are organized into folders that categorize the various API calls according to category. For example, you will find all the Users methods under the **Users** folder in the Management API.
+
+## Configure Postman Environment
+
+The Auth0 Postman Collections make use of environment variables to customize the requests that are sent. To learn more about managing Postman environments, see [Setting up an environment with variables](https://learning.postman.com/docs/postman/variables-and-environments/variables/).
+
+You must create an environment and configure the following variables:
+
+| Variable | Description |
+| -- | -- |
+| `auth0_domain` | Should contain the domain for your Auth0 tenant, such as `jerrie.auth0.com`. |
+| `auth0_token` | Should contain the token needed to make calls to the Management API. Is only required when using the Management API collection. To learn more, see [How to Get an Access Token for the Management API](/api/management/v2/tokens). |
+
+In the screenshot below, you can see a Postman environment configured with both the `auth0_domain` and `auth0_token` variables defined:
+
+![Environment Configured](/media/articles/api/postman/environment-configured.png)
+
+## Execute requests
+
+Once the environment is configured, you can follow these steps to execute an Auth0 API method:
+
+1. Select the environment with which you want to work.
+2. Select the relevant API method in the collection folder.
+3. Click the **Send** button.
+
+![Execute API Method](/media/articles/api/postman/execute-api-method.png)
+
+You may also have to configure query parameters or the JSON method body, depending on the API call. To learn more, see [Sending Requests](https://learning.getpostman.com/docs/postman/sending-api-requests/requests/).
+
+::: warning
+Storing tokens in Postman as environment variables could pose a security risk. If you are signed in to the Postman application, it will automatically try to [synchronize entities such as Collections and Environments with the Postman servers](https://www.getpostman.com/docs/sync_overview). This means that a token, which could allow someone else to gain access to your Management API, is leaving the privacy of your computer and being uploaded to Postman's servers.
+
+That said, Postman has taken measures to ensure that tokens are encrypted and encourages users to store them in Environment Variables. You can read more at [Postman Security](https://www.getpostman.com/security).
+
+If you feel that this still poses too much of a risk, then you will need to sign out of Postman to ensure that environment variables are not synchronized.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/appliance/admin/backing-up-the-appliance-instances.md b/ja-jp/articles/appliance/admin/backing-up-the-appliance-instances.md
new file mode 100644
index 0000000000..a8a8111de9
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/backing-up-the-appliance-instances.md
@@ -0,0 +1,20 @@
+---
+section: appliance
+description: Recommendations on when to back up PSaaS Appliance instances
+topics:
+    - appliance
+    - backups
+contentType: concept
+useCase: appliance
+applianceId: appliance1
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Appliance Backups
+
+If the PSaaS Appliance is used in a stateless way (such as authentication, SSO), Auth0 recommends that you take **weekly** backups of all nodes using virtual machine snapshots.
+
+If the PSaaS Appliance is only used to store data (such as database connections, user metadata), Auth0 recommends that you take **daily** backups of all nodes using virtual machine snapshots.
+
+## For More Information:
+-  [How to Back Up the PSaaS Appliance Using the CLI](/appliance/cli/backing-up-the-appliance)
diff --git a/ja-jp/articles/appliance/admin/disabling-sign-ups.md b/ja-jp/articles/appliance/admin/disabling-sign-ups.md
new file mode 100644
index 0000000000..219fc4f573
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/disabling-sign-ups.md
@@ -0,0 +1,41 @@
+---
+description: Auth0 suggests that you disable sign-ups for the `Initial-Connection` database connection prior to going live in your production environments.
+section: appliance
+topics:
+    - appliance
+    - signups
+contentType: how-to
+useCase: appliance
+applianceId: appliance3
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Disabling Sign-Ups
+
+The PSaaS Appliance, when running in multi-tenancy mode, behaves just like the Auth0 cloud environment. Users will be able to sign up and create new accounts in the cluster, and this ability is *not* limited to internal users. For this reason, Auth0 suggests that you disable sign-ups for the `Initial-Connection` database connection prior to going live in your production environments.
+
+::: panel-warning Connections for the Auth0 Application
+The **Auth0** application in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this application is the built-in Database Connection (the default Connection for this application is a Database Connection called *Initial-Connection*) or an enterprise connection like the AD-LDAP Connector. You should **never** enable a Social Connection for the **Auth0** application.
+
+Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** application.
+:::
+
+Disabling signups will prevent users from signing up for an account in your PSaaS Appliance. Therefore, if you want to [invite co-administrators](/appliance/admin/inviting-coadmins) to a specific tenant, you will need to do the following:
+
+* create the user manually using the Dashboard;
+* send the newly-created user's credentials to your co-administrator;
+* invite the user to the appropriate account.
+
+## How to Disable Signups for a Connection
+
+Log in to the Auth0 Management Dashboard.
+
+![Auth0 Management Dashboard Landing Page](/media/articles/appliance/admin/mgmt-dashboard.png)
+
+Using the left-hand navigation menu, go to **Connections > Database**.
+
+![Database Connections Page](/media/articles/appliance/admin/connections.png)
+
+Click the row corresponding to **Initial-Connection** (or the connection for which you are disabling sign-ups). You will be directed to the *Settings* page. Scroll to the bottom, and enable the slider corresponding to the row that reads **Disable Sign Ups**.
+
+![Connections Settings Page](/media/articles/appliance/admin/disable-sign-ups.png)
diff --git a/ja-jp/articles/appliance/admin/federated-access-to-manage.md b/ja-jp/articles/appliance/admin/federated-access-to-manage.md
new file mode 100644
index 0000000000..a5633b68fd
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/federated-access-to-manage.md
@@ -0,0 +1,65 @@
+---
+description: How to set up federated login to the Manage Dashboard
+section: appliance
+topics:
+    - appliance
+    - admin
+    - signups
+contentType: how-to
+useCase: appliance
+applianceId: appliance76
+sitemap: false
+---
+# Set Up Federated Login to the Manage Dashboard
+
+If you use an Identity Provider (IdP) to handle your staff logins, you can use the IdP with your root tenant authority (otherwise known as the RTA or your config tenant) to provide federated access to your Dashboard.
+
+By using your IdP, this eliminates the need for you to:
+
+* *For customer-hosted PSaaS Appliance:* Manually create users in the root tenant authority (RTA)
+* *For Auth0-hosted PSaaS Appliance:* Open a support case requesting the addition of a Dashboard administrator.
+
+::: note
+If you have an Auth0-hosted PSaaS Appliance, but you do not have access to the root tenant, please submit a [Support Ticket](${env.DOMAIN_URL_SUPPORT}) and the Appliance Services staff will help you set this up.
+:::
+
+## Setting Up Federated Access
+
+The Auth0 root tenant acts as an identity provider (IdP) for the Manage Dashboard. As such, you will need to add a Service Provider (SP) to your existing IdP to federate access to the Manage Dashboard. 
+
+This process requires the following three steps:
+
+1. Set up the Auth0 Service Provider (SP)
+    *For customers with Auth0-hosted PSaaS Appliance: Auth0 will create the Connection for you after you provide the necessary setup information.*
+2. Provide your Service Provider metadata to the Identity Provider (IdP)
+3. Test the Identity Provider
+
+Please note that how you complete the three steps above differ slightly based on whether you're working with a customer-hosted PSaaS Appliance or an Auth0-hosted PSaaS Appliance.
+
+### Customer-hosted PSaaS Appliance
+
+[Configure Auth0 as the Service Provider (SP)](/protocols/saml/saml-configuration/auth0-as-service-provider) and use both the root tenant authority and the new Service Provider Connection to access Auth0.
+
+### Auth0-hosted PSaaS Appliance
+
+[Configure Auth0 as the Service Provider (SP)](/protocols/saml/saml-configuration/auth0-as-service-provider). Follow the tutorial up through the section where you identify the Identity Provider (IdP) and Connection protocol (you will be stopping at the section where you're shown how to Configure Auth0).
+
+Please be sure to configure your mappings between Auth0 (as the SP) and your IdP in the form of Assertions. You can do so in the Dashboard by going to **Connections** > **Enterprise** > **SAMLP Identity Provider**. Find your connection, and click the cog icon to launch the **Settings** tab. Switch to the **Mappings** view, and provide mappings for **name**, the **name format** (optional), and **value**. The specifics will vary based on the IdP you're using, so please contact Auth0 if you have any questions.
+
+At this point, send Auth0 the information you've collected in a [Support Ticket](${env.DOMAIN_URL_SUPPORT}) and request that you be granted federated access to the config tenant/RTA.
+
+In your Support ticket, you should include:
+
+* The **email domain(s)** that will be redirected to your Identity Provider
+* The Identity Provider's **single sign-on URL**
+* The Identity Provider's **public key** (encoded in PEM or CER format)
+* The **sign out URL** (optional)
+
+You can find most of this information in the XML metadata file provided by your Identity Provider. If you'd prefer, you can send Auth0 this file, along with the email domains that you will be redirecting to the IdP.
+
+Once Auth0 receives all of the information we need, we will:
+
+* Create a Connection in your root tenant
+* Provide you with the metadata link containing the information you need to provide to your Identity Provider
+
+Once you provide this information (as well as the callback URL and the Entity ID) to your IdP, you will be able to test your federated Login to the Dashboard.
\ No newline at end of file
diff --git a/ja-jp/articles/appliance/admin/importance-of-updates.md b/ja-jp/articles/appliance/admin/importance-of-updates.md
new file mode 100644
index 0000000000..c38ad249b4
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/importance-of-updates.md
@@ -0,0 +1,35 @@
+---
+section: appliance
+description: Why it is important to regularly update the PSaaS Appliance
+topics:
+    - appliance
+    - updates
+    - security
+contentType: concept
+useCase: appliance
+applianceId: appliance75
+sitemap: false
+---
+# Why You Should Update the PSaaS Appliance Regularly
+
+Though the Auth0 engineering team releases updates to the PSaaS Appliance on a monthly basis, we understand that such frequent updates to your environment (though ideal) are not always possible. Regardless, we recommend updating your PSaaS Appliance on a bi-monthly or quarterly basis at the very least.
+
+In this article, we will cover why it is essential to update your PSaaS Appliance regularly.
+
+## Benefits to updating the PSaaS Appliance
+
+First, each major release contains all of the new features and improvements to existing features that we have made since the prior version.
+
+However, even if you are happy with your existing feature set, there are also benefits to updating the PSaaS Appliance that extend beyond technological improvements and feature updates. 
+
+More specifically, each major release for the PSaaS Appliance includes fixes for all of the known issues discovered during normal usage of Auth0. We aim to provide as smooth an experience as possible for all of our customers, but an issue-free release is not possible. As such, we ship updates that correct any issues that might become apparent.
+
+## Problems that may arise due to delayed or skipped updates
+
+By upgrading routinely, you can be assured that you are working with a version of the PSaaS Appliance that is fully-functional and secure. Conversely, if you do not upgrade, your environment becomes, over time, unsupported and less secure.
+
+Furthermore, lack of updates to the PSaaS Appliance over time makes it difficult when you do get to the point where you want to update. Because updates are cumulative, skipping updates means that you will have more changes that need to be tested. By updating at each possible opportunity, you are making smaller, incremental changes to your environment.
+
+## Testing in the Development Environment to ensure smooth updates
+
+Auth0 provides a Development environment at no cost to you. The purpose of this environment is to test future upgrades to identify any issues before updating your Production environment. Auth0 works with you to resolve any problems identified during your testing, and only when both parties are comfortable should the upgrade proceed to Production. 
diff --git a/ja-jp/articles/appliance/admin/index.md b/ja-jp/articles/appliance/admin/index.md
new file mode 100644
index 0000000000..cdde2ec3c8
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/index.md
@@ -0,0 +1,26 @@
+---
+url: /appliance/admin
+section: appliance
+description: >
+  This document covers factors PSaaS Appliance administrators should be aware of when working with production PSaaS Appliance.
+topics:
+    - appliance
+    - administration
+contentType: index
+useCase: appliance
+applianceId: appliance4
+sitemap: false
+---
+
+# PSaaS Appliance: Administrator's Manual
+
+This document covers factors PSaaS Appliance administrators should be aware of when working with production PSaaS Appliance instances.
+
+* [Managing the Dashboard](/appliance/admin/managing-the-dashboard)
+* [Disabling Sign-ups](/appliance/admin/disabling-sign-ups)
+* [Inviting/Adding Co-Administrators](/appliance/admin/inviting-coadmins)
+* [Backing up the PSaaS Appliance](/appliance/admin/backing-up-the-appliance-instances)
+* [Monitoring & Performing Health Checks on Load Balancers](/appliance/admin/monitoring)
+* [Updating the PSaaS Appliance](/appliance/admin/updating-the-appliance)
+  * [Why You Should Update the PSaaS Appliance Regularly](/appliance/admin/importance-of-updates)
+* [Configuring Custom Error Pages](/universal-login/custom-error-pages)
diff --git a/ja-jp/articles/appliance/admin/inviting-coadmins.md b/ja-jp/articles/appliance/admin/inviting-coadmins.md
new file mode 100644
index 0000000000..a5f17a2222
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/inviting-coadmins.md
@@ -0,0 +1,42 @@
+---
+section: appliance
+description: How to invite additional administrators to your PSaaS Appliance
+topics:
+    - appliance
+    - coadmins
+contentType: how-to
+useCase: appliance
+applianceId: appliance5
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Inviting Co-Administrators
+
+::: panel-warning PSaaS Appliance in the Dedicated Cloud Service
+If you have a PSaaS Appliance in the Dedicated Cloud Service, you do not have access to the RTA tenant, since Auth0 manages this on your behalf. To add new administrators, you'll need to [contact Support](${env.DOMAIN_URL_SUPPORT}) (be sure to mention that you have a PSaaS Appliance in the Dedicated Cloud Service). 
+
+If you're an existing tenant administrator, you can simply forward the tenant administrator invitation link to new administrators.
+:::
+
+You may invite additional users to become co-administrators of your PSaaS Appliance. This is done via the PSaaS Appliance configuration area of the Management Dashboard.
+
+::: panel Root Tenant Authority
+Administrators for the PSaaS Appliance are authenticated with the root tenant authority (RTA, the primary tenant, sometimes called the **config** tenant). The Dashboard is represented by the **"Auth0"** app/client in the RTA account. By default the RTA has a DB connection enabled, **"Initial-Connection"**, that is used to authenticate Dashboard users.
+Since that connection has signups disabled, users will be have to be created beforehand.
+:::
+
+[![](/media/articles/appliance/admin/invite-co-admins.png)](https://auth0-1.wistia.com/medias/2t8n98qc5j)
+
+1. In the RTA tenant (usually named **rta** or **config**) add a new user in the **Initial-Connection** connection with the email of the administrator you will invite, and choose a password. Please see the section on [adding users via the Management Dashboard](/creating-users) for additional information.
+
+2. Switch over to the App Tenant so that you will have access to the PSaaS Appliance configuration options.
+
+3. Open up the Account Settings page.
+
+4. Navigate to the Dashboard Admins tab.
+
+5. Click "Add" to add the user as an administrator. You will be asked to provide the user's email address and to set the Applications over which they will have administrative rights. When finished, click "Send Invite".
+
+At this point, if you have SMTP configured on the PSaaS Appliance, the user will receive an email inviting them to log in as an administrator. They will need to use the email and password used in step 1.
+
+If you do not have SMTP configured, hover over the "pending" link next to the user's name, copy the link, and forward it, along with the new username/password, to the user. The user will be able to use the link and credentials to log in as an administrator.
diff --git a/ja-jp/articles/appliance/admin/limiting-ssh-access.md b/ja-jp/articles/appliance/admin/limiting-ssh-access.md
new file mode 100644
index 0000000000..4d0b93b513
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/limiting-ssh-access.md
@@ -0,0 +1,18 @@
+---
+section: appliance
+description: When and why you should grant SSH access to the PSaaS Appliance
+topics:
+    - appliance
+    - ssh
+    - security
+contentType: concept
+useCase: appliance
+applianceId: appliance6
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Limiting SSH Access
+
+Auth0 requires SSH access in order to connect to the PSaaS Appliance to perform updates or troubleshooting/accessing required logs. These are the only instances where SSH (by default, port 22) should be exposed on the nodes.
+
+In all other instances, Auth0 recommends restricting SSH access to the PSaaS Appliance. For Appliance deployments in the cloud, you would *not* enable the SSH endpoint for your virtual machines. For on-premise PSaaS Appliance deployments, you would deny SSH to the virtual machines in your corporate firewall.
diff --git a/ja-jp/articles/appliance/admin/managing-the-dashboard.md b/ja-jp/articles/appliance/admin/managing-the-dashboard.md
new file mode 100644
index 0000000000..5ad7477bc3
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/managing-the-dashboard.md
@@ -0,0 +1,61 @@
+---
+section: appliance
+description: How to access and restrict access to the PSaaS Appliance Management Dashboard
+topics:
+    - appliance
+    - dashboard
+contentType: how-to
+useCase: appliance
+applianceId: appliance7
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Manage the Dashboard
+
+## Access the Dashboard
+
+::: panel-warning Connections for the Auth0 Application
+The **Auth0** application in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this application is the built-in Database Connection (the default Connection for this application is a Database Connection called *Initial-Connection*) or an enterprise connection like the AD-LDAP Connector. You should **never** enable a Social Connection for the **Auth0** application.
+
+Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** application.
+:::
+
+
+The [Auth0 Dashboard](/appliance/dashboard) uses the PSaaS Appliance to authenticate its users.
+
+Within the list of applications, you will see the Auth0 Application, which represents the Dashboard itself. It uses a connection called `Initial-Connection`, which stores the credentials of the administrators that have access to the Dashboard.
+
+::: note
+Changes to the Auth0 Application or `Initial-Connection` may result in unexpected Dashboard behavior. Please makes changes with caution.
+:::
+
+Because the Dashboard uses the PSaaS Appliance for authentication, any configured rules will run whenever a user accesses the Dashboard. Because errors in one or more of your rules may result in you losing access to the Dashboard, Auth0 suggests writing rules that exclude the Auth0 application:
+
+```js
+
+function (user, context, callback) {
+    if (context.clientName === 'Auth0') {
+      return callback(null, user, context);
+    }
+
+    // Your code.
+
+    callback(null, user, context);
+}
+
+```
+
+::: note
+The default user `root@auth0.com` has access to the PSaaS Appliance and its configuration area. To prevent unauthorized access with this account, you should block this user via the Auth0 Dashboard.
+:::
+
+To block the user, click *Actions*. Then, in the drop-down menu that appears, click *Block User*.
+
+## Restrict Access to the Dashboard
+
+Because the Dashboard uses the PSaaS Appliance to authenticate users, the Dashboard is using Connections, [Rules](/rules), and so on, just like any other application you might add in the future.
+
+As a result, you have several options for restricting access to the dashboard, including, but not limited to:
+
+* Writing rules to allow users only from a specific IP address;
+* Writing rules to allow only co-administrators of the PSaaS Appliance to authenticate using their Active Directory (via either ADFS or AD Connector).
diff --git a/ja-jp/articles/appliance/admin/monitoring.md b/ja-jp/articles/appliance/admin/monitoring.md
new file mode 100644
index 0000000000..751be898b9
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/monitoring.md
@@ -0,0 +1,25 @@
+---
+section: appliance
+description: How to monitor the PSaaS Appliance
+topics:
+    - appliance
+    - monitoring
+contentType: how-to
+useCase: appliance
+applianceId: appliance8
+sitemap: false
+---
+
+# PSaaS Appliance Administration: Monitoring
+
+While your existing monitoring platform may already collect data (such as metrics on CPU, disk size, and so on.) at the virtual machine level, it may exclude information regarding the nodes in the cluster.
+
+Because of this, Auth0 provides [tools for monitoring your individual cluster nodes](/appliance/monitoring).
+
+For information about general Auth0 Monitoring, please see [this page](monitoring).
+
+## Performing Health Checks on Load Balancers
+
+When running the PSaaS Appliance in a High Availability setup, the load balancers will distribute the load over all nodes in the cluster. Most load balancers perform their own health checks on all of the servers to which they distribute the load, allowing them to remove non-responsive servers out of rotation.
+
+Once source of information for the load balancer can be obtained by running the HTTP health checks to each node in the cluster using the [`testall`](/appliance/monitoring/testall) endpoint.
diff --git a/ja-jp/articles/appliance/admin/rate-limiting.md b/ja-jp/articles/appliance/admin/rate-limiting.md
new file mode 100644
index 0000000000..5e276a2e64
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/rate-limiting.md
@@ -0,0 +1,74 @@
+---
+title: Rate Limiting in the PSaaS Appliance
+description: How to enable, configure, and test for rate limiting in the Appliance
+topics:
+    - appliance
+    - rate-limiting
+contentType: how-to
+useCase: appliance
+applianceId: appliance9
+sitemap: false
+---
+# PSaaS Appliance: Rate Limiting
+
+Rate limits for API endpoints can be enabled and configured in the Dashboard. Rate limiting in the PSaaS Appliance is done using [limitd](https://github.com/limitd/limitd#buckets).
+
+## Enable and Configure Rate Limiting
+
+In the PSaaS Appliance Dashboard, go to **Rate Limiting**.
+
+![](/media/articles/appliance/admin/rate-limiting-1.png)
+
+Click the checkbox next to **Enable** to enable rate limiting.
+
+![](/media/articles/appliance/admin/rate-limiting-2.png)
+
+By default, **Configuration of buckets** is empty, which means that limitd's default configuration will be used. Your Customer Success Engineer may advise you to adjust this value if appropriate.
+
+Click **Save** and wait for the updates to the configuration to complete.
+
+![](/media/articles/appliance/admin/rate-limiting-3.png)
+
+## Test Rate Limiting Functionality
+
+When you've enabled rate limiting, the HTTP response includes the following headers:
+
+* X-RateLimit-Limit: Request limit
+* X-RateLimit-Remaining: Requests available for the current time frame
+* X-RateLimit-Reset: Time until the rate limit resets (in UTC [epoch seconds](https://en.wikipedia.org/wiki/Unix_time))
+
+To verify that rate limiting is working, you can send a call to any [rate-limited API endpoint](/policies/rate-limits#endpoints-with-rate-limits), such as the [Get All Connections endpoint](/api/management/v2#!/Connections/get_connections):
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/api/v2/connections",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MGMT_API_ACCESS_TOKEN"
+	}]
+}
+```
+
+Your expected response looks something like this:
+
+```text
+HTTP/1.1 200 OK
+Date: Wed, 01 Nov 2017 19:52:28 GMT
+Content-Type: application/json; charset=utf-8
+Content-Length: 366
+Connection: keep-alive
+Keep-Alive: timeout=100
+x-ratelimit-limit: 50
+x-ratelimit-remaining: 49
+x-ratelimit-reset: 1509565949
+vary: origin,accept-encoding
+cache-control: no-cache
+accept-ranges: bytes
+Strict-Transport-Security: max-age=15724800
+X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
+
+[{"id":"con_sw...O","options":{"mfa":{"active":true,"return_enroll_settings":true},"disable_signup":true,"brute_force_protection":true,"strategy_version":2},"strategy":"auth0","name":"Initial-Connection","enabled_clients":["aCb...C","ef7...Z"],"is_domain_connection":false,"realms":["Initial-Connection"]}]
+```
diff --git a/ja-jp/articles/appliance/admin/updating-the-appliance.md b/ja-jp/articles/appliance/admin/updating-the-appliance.md
new file mode 100644
index 0000000000..bfec4751aa
--- /dev/null
+++ b/ja-jp/articles/appliance/admin/updating-the-appliance.md
@@ -0,0 +1,119 @@
+---
+section: appliance
+description: How to update the PSaaS Appliance
+toc: true
+topics:
+    - appliance
+    - updates
+contentType: how-to
+useCase: appliance
+applianceId: appliance10
+sitemap: false
+---
+# Updating the PSaaS Appliance
+
+To [ensure that your PSaaS Appliance has the latest functionality, security, and bug fixes](/appliance/admin/importance-of-updates), Auth0 requires you to perform regular updates. While the Auth0 engineering team releases updates on a monthly basis, you should plan updates on a monthly, bi-monthly, and quarterly basis.
+
+Appliances must be updated using a **major release** at least once every **90 days**.
+
+## Releases
+
+For more information about PSaaS Appliance Releases, please see the [Change Log](https://auth0.com/changelog/appliance).
+
+## Types of updates
+
+There are two types of updates: **major** and **minor** releases.
+
+### Major releases
+
+**Major releases** can be identified by changes in the PSaaS Appliance version number (i.e. from **14591.X** to **15838.X**). These updates include new features and/or changes in existing functionality.
+
+### Minor releases
+
+**Minor releases** (or patch releases) can be identified by changes in the *decimal* value of the version number (i.e. **15838.35** is a minor update to **15838.31**).
+
+Patches are cumulative; that is, patch **15838.85** includes changes included in all prior patches (**15838.75**, **15838.43**, **15838.36**, **15838.35**, and **15838.31**).
+
+You do *not* need to install all released patches, but we recommend doing so since patches typically include things like bug and security fixes.
+
+## The update process
+
+The update process will vary slightly depending on whether you have an **Auth0-hosted PSaaS Appliance** or a **self-hosted PSaaS Appliance**.
+
+### Auth0-hosted PSaaS Appliance
+
+When you are ready to update, submit a Support ticket indicating:
+
+* That you are ready to update your Development environment
+* When you would like Auth0 to perform the upgrade
+* What version you would like to upgrade to
+
+We will contact you to determine the specific time frame during which the update occurs.
+
+Once we have updated your Development environment, we recommend you spend one week testing. If, at that point, everything is working, we will schedule a time frame for updates to the Production environment(s).
+
+### Self-hosted PSaaS Appliance
+
+You can apply **minor** updates without coordination with Auth0. However, we recommend updating your Development nodes and testing prior to applying the changes to your Production environment.
+
+For **major** updates, please submit a Support ticket and Auth0 will reach out to confirm if manual intervention on the part of Auth0 is required.
+
+To ensure the update process goes as smoothly as possible, we recommend following the best practices detailed below.
+
+#### Prior to the Update
+
+* Take a VM snapshot of each node you're updating.
+* Ensure that you've enabled access to your nodes for the Auth0 Customer Success Engineer who will be assisting you with the update.
+* Complete the pre-check test **one hour** prior the start of the update.
+  * Please be sure that your infrastructure engineer has administrative access to the Dashboard (specifically the Root Tenant Authority).
+  * Ensure that all [Health Checks](/appliance/dashboard/troubleshoot#health-check) are okay.
+* For multi-node clusters, check the **Enable Sequential Updates** box if you want to reduce downtime during the update.
+
+::: note
+For additional information on gathering testing information, please see [PSaaS Appliance Monitoring](/appliance/monitoring).
+:::
+
+* Update the Development/Test environment prior to upgrading Production. This allows you to test the new version to identify any issues before you apply it to Production. We recommend performing this test for a one-week period.
+* Ensure that the PSaaS Appliance is able to access the internet during the update process, as well as the outbound IP addresses listed in the ["Updates" column](/appliance/infrastructure/ip-domain-port-list#external-connectivity). The update is [triggered via the Management Dashboard](/appliance/dashboard/updates) and requires the downloading of the application itself, as well as any operating system updates.
+
+#### After the update
+
+::: note
+For additional information on gathering testing information, please see [PSaaS Appliance Monitoring](/appliance/monitoring).
+:::
+
+* Perform the post-test check:
+  * Check to see if all instances list the same update count and that they're currently running the latest version.
+  * Check that all Health Checks are okay.
+
+* Run smoke tests to ensure that there are no issues with the update.
+
+    The specifics of what constitutes a complete smoke check for your PSaaS Appliance varies, since the appropriate tests vary based on your implementation and usage of Auth0. Furthermore, each organization prefers different levels of detail when it comes to testing -- some prefer more thorough testing than others. Regardless, we recommend testing at the very least:
+
+        1. All application functionality that involves authentication flows or user identity changes
+        2. Basic access to the Auth0 Management Dashboard
+
+    Some of the areas and processes that you might consider including in your smoke tests include:
+
+        * Registration
+        * Login (including those involving Social or other identity providers)
+        * Logout
+        * Password reset
+        * Single sign-on (SSO)
+        * Passwordless/SMS login
+        * User metadata updates
+        * Machine-to-machine interactions
+        * SDK usage
+        * Mobile and desktop usage
+        * Login and use of the Auth0 Management Dashboard
+        * Extensions (make sure that the ones you've installed are functioning as expected
+
+Please remember that you are responsible for testing and ensuring that all of your applications work as expected.
+
+## Downtime
+
+During an upgrade, we expect there to be some downtime. For single-node clusters, we expect there to be 3-5 minutes of downtime. For multi-node clusters, we can perform updates sequentially, where users may see up to 30 seconds of downtime.
+
+Downtime occurs when we restart services. Because of this, we are willing to schedule updates to Production clusters during non-business hours. Please let us know your preferences in the Support Ticket.
+
+If you require your Production update during non-business hours, we ask that you confirm the day prior during normal business hours.
diff --git a/ja-jp/articles/appliance/appliance-overview.md b/ja-jp/articles/appliance/appliance-overview.md
new file mode 100644
index 0000000000..ed9bfb70b7
--- /dev/null
+++ b/ja-jp/articles/appliance/appliance-overview.md
@@ -0,0 +1,113 @@
+---
+section: appliance
+description: The PSaaS Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service.
+topics:
+    - appliance
+contentType: concept
+useCase: appliance
+applianceId: appliance52
+sitemap: false
+---
+
+# PSaaS Appliance Overview
+
+The PSaaS Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. The PSaaS Appliance can be deployed in one of three places:
+
+* a dedicated cloud environment hosted by Auth0 (you may opt for a shared cloud environment or an environment where resources are allocated only to your company).
+* your cloud environment using **Amazon AWS**
+
+## Infrastructure
+
+If you opt to use a dedicated cloud environment hosted by Auth0, Auth0 is responsible for installation, maintenance, patching and updates.
+
+If you choose to deploy to your own cloud environment or data center, you supply and monitor the infrastructure Auth0 runs on. This includes the VM host, storage, network resources (such as the load balancer, internet access, and so on), and other required dependencies (such as the SMTP, NTP, and so on).
+
+## Deployment
+
+You may deploy the PSaaS Appliance in several different configurations and use several different deployment models. The configurations support different levels of scale and high availability, and they are available in any of the PSaaS Appliance deployment models. The following table shows the configuration options:
+
+PSaaS Appliance HA Options
+
+
+
+
+    
+        
+        
+        
+        
+    
+
+
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+
+
    Single NodeHigh AvailabilityHigh Capacity
    DescriptionIntended for development and testing environments.
    • Three-node redundant cluster
      •  
    • Tolerates a single-node outage
      •  
    • Recommended for most Production environments
      •  
    • Includes a single node for Dev/QA
    • Highly scalable capacity for the most demanding applications
      •  
    • Tolerates multi-node outages
      •  
    • Recommended for large-scale Production environments
      •  
    • Includes a single node for Dev/QA
    Geo HANot Available
    • Multiple data center with active-passive clustering and automated failover
      •  
    • Auth0 continues to operate if a data center becomes unavailable
      •  
    • If the primary data center fails, traffic can quickly be routed to the secondary cluster
      •  
    • Cluster topology is replicated in each environment. Requires a global load balancing solution like AWS Route 53 or F5 Global Traffic Manager.
    Backup and Recovery
    • Virtual Machine Snapshot
    • Data backup with cluster restore
    • Virtual Machine Snapshot
    • Virtual Machine shipping with scripted restore (if using VMWare)
    • Data backup with cluster restore
    
+
+
+[Auth0 Deployment Models](/overview/deployment-models) provides additional details and explains the differences between each of the PSaaS Appliance deployment models and the standard multi-tenant cloud deployment.
+
+## Maintenance and Connectivity
+
+As a managed service, Auth0 performs:
+
+* initial setup and configuration;
+*  ongoing maintenance operations (security patching, troubleshooting, and updating).
+
+Auth0 will closely coordinate access to your PSaaS Appliance instances with your operations team, since these activities will often run on your infrastructure (such as your network, servers, and so on). Depending on the time it takes to prepare the required infrastructure and the deployment complexity, the PSaaS Appliance implementation project typically takes between 1-5 weeks.
+
+If Auth0 is managing a dedicated environment for you, Auth0 will obtain your consent prior to applying any updates or configuration changes. Auth0 will not access any PSaaS Appliance, nor will any information be transferred off of the PSaaS Appliance without your consent.
+
+### Connectivity
+
+During maintenance operations, the PSaaS Appliance instances contact external Auth0 endpoints for updating under your consent and supervision. After maintenance completes, you can [continue to operate with limited internet access](/appliance/infrastructure/internet-restricted-deployment).
+
+For normal maintenance, Auth0 will access the Management Dashboard (either over a temporary SSH connection or through remote control software) to apply the update. Auth0 will also need SSH access in the event that updates to the PSaaS Appliance are necessary. If you expose API endpoints to be used for monitoring, Auth0 will collect this information to proactively monitor PSaaS Appliance behavior for you.
+
+Depending on which features are implemented, you may need to permit access to certain websites on the Internet from each PSaaS Appliance instance. For example, if Facebook logins are needed, you must open connectivity from the Auth0 servers to `facebook.com`. If users will be logging in from the Internet (and not through a VPN), you must publish the authentication endpoints.
+
+### Update Cycle
+
+The typical update cycle is once per month. You can control and which version is applied. Occasionally, lower-level actions may be performed on the nodes. You will be notified in advance on the nature of activities to be performed, and will be provided instructions on any actions you may need to execute on your side.
+
+The diagram below details a few of these dependencies:
+
+Appliance Overview
+
+## Monitoring and Support
+
+You are responsible for monitoring all the dependencies the Auth0 Service relies on within your environment, such as the network load balancer, VM hosts, SMTP gateways, and so on.
+
+If you provide access to the appropriate monitoring endpoints, Auth0 will monitor the nodes' health and notify you of any conditions that require action.
+
+If Auth0 hosts the PSaaS Appliance for you, then Auth0 will monitor the related services.
+
+### Monitoring Endpoints
+Auth0 provides specific monitoring endpoints that you can attach to your own monitoring tools (such as Microsoft System Center, IBM Tivoli, HP OpenView, and so on) for auditing, load balancing, and performance monitoring, such as in cases where the transaction under test includes application specific functionality (for example, a [rule](/rules) that integrates Auth0 with your own CRM).
+
+You may find detailed guidance at [Monitoring Auth0](/monitoring).
+
+In addition, the PSaaS Appliance has authenticated monitoring endpoints for metrics like CPU, memory, and disk space that you can query for more detailed information.
+
+If the PSaaS Appliance does not perform as expected, you can contact your Auth0 Customer Success Engineer. Auth0 provides an incident escalation procedure during the onboarding process that explains the steps to be followed when an incident occurs. Auth0 has a 24 x 7, around-the-clock support staff.
+
+## Server Requirements
+
+You will be asked to set up a Dev/Test (non-Production) environment, as well as a Production environment.
+
+For the Production environment, the number of virtual machines required to host the PSaaS Appliance depends on the expected traffic and the desired availability. For a highly-available configuration, the Production environment requires a minimum of three network load-balanced PSaaS Appliance instances and one for the Dev/Test (non-Production) environment (which also does *not* required any special load balancing logic/sticky sessions).
diff --git a/ja-jp/articles/appliance/cli/adding-node-to-backup-role.md b/ja-jp/articles/appliance/cli/adding-node-to-backup-role.md
new file mode 100644
index 0000000000..fad2cdabe9
--- /dev/null
+++ b/ja-jp/articles/appliance/cli/adding-node-to-backup-role.md
@@ -0,0 +1,35 @@
+---
+section: appliance
+description: How to add an PSaaS Appliance node in the backup node
+topics:
+    - appliance
+    - backups
+    - cli
+    - nodes
+contentType: how-to
+useCase: appliance
+applianceId: appliance11
+sitemap: false
+---
+
+# PSaaS Appliance: Adding a Node to the Backup Role
+
+## Prerequisites
+
+* Backup can be configured on single or multiple-node setups. In multi-node setups, the backup must be placed on a non-primary device.
+* **A separate, dedicated backup device** with sufficient space to store the backups on the node that you are assigning to the `backup` role.
+
+## Adding a Node to the Backup Role
+
+To add a node to the `backup` role, execute the `set-as-backup` command using the PSaaS Appliance's Command-Line Interface. When issuing this command, you will need to specify the device on the target node to be used to store backups.
+
+`$a0cli -t  set-as-backup  [force]`
+
+::: note
+  If you have already created a backup folder on the node, the command will fail unless you set the `force` argument to `true`.
+:::
+
+## Additional Reading
+
+* [Configuring and Using the PSaaS Appliance Command Line Interface](/appliance/cli/configure-cli)
+* [How to Back Up the PSaaS Appliance Using the CLI](/appliance/cli/backing-up-the-appliance)
diff --git a/ja-jp/articles/appliance/cli/backing-up-the-appliance.md b/ja-jp/articles/appliance/cli/backing-up-the-appliance.md
new file mode 100644
index 0000000000..f382361fb5
--- /dev/null
+++ b/ja-jp/articles/appliance/cli/backing-up-the-appliance.md
@@ -0,0 +1,126 @@
+---
+section: appliance
+description: How to back up the PSaaS Appliance using its CLI
+toc: true
+topics:
+    - appliance
+    - cli
+    - backups
+contentType: how-to
+useCase: appliance
+applianceId: appliance12
+sitemap: false
+---
+
+# How to Back Up the PSaaS Appliance Using the CLI
+
+You may use the PSaaS Appliance CLI to perform a Mongo backup on a specific node.
+
+Beginning with version `11638`, the backup doesn't include sensitive configuration information such as encryption keys.
+
+## Prior to Beginning the Backup
+
+Please ensure that:
+* You have configured the [Command Line Interface](/appliance/cli/configure-cli) on your PSaaS Appliance instances;
+* The node has disk space equal to or greater than twice the amount of Auth0 data present.
+
+::: note
+Beginning with PSaaS Appliance version `6868`, you may only back up nodes [added to the `backup` role](/appliance/cli/adding-node-to-backup-role).
+:::
+
+Please be aware that we use the following sample values throughout this document:
+
+* IP address of the node on the replica set to be backed up: `192.168.1.186`. Generically, the node may also be referred to as ``.
+* Password used for encryption: `Passw0rd`.
+* The replica set connection string: `a0/a0-1:27017,a0-2:27017,a0-3:27017`.
+
+## Generate a New Backup
+
+To initiate a backup, run the following command in your local command-line interface:
+
+```bash
+a0cli -t  backup 
+```
+
+For example, if you were to run the above command using the provided sample values, you would run:
+
+```bash
+a0cli -t 192.168.1.186 backup --password Passw0rd
+```
+
+If the command successfully begins the backup process, you will see the message, "Backup in progress."
+
+![](/media/articles/appliance/cli/backup-in-progress.png)
+
+The backup will be encrypted using the `aes-256-crt` algorithm.
+
+::: note
+Only one backup may performed and stored at any given time. Prior to generating a new backup of a node, you must [delete the existing backup](#deleting-the-backup).
+:::
+
+## Back up Sensitive Configuration Info
+
+Beginning with PSaaS Appliance version `11638`, the `backup` command does **not** save sensitive configuration information such as encryption keys. You need to manually back up these keys (and any other sensitive information) if you want to fully recover an PSaaS Appliance installation using a backup copy.
+
+To do this, you can use the `backup-sensitive` command, which works the same way as `backup`. You must run the command on a node where you previously ran `set-as-backup`.
+
+The full instructions (along with the commands you'll need to run) are as follows:
+
+1. Request a backup: `a0cli -t node_IP_address backup-sensitive --password 0therPassw0rd`;
+2. Check the status of a backup: `a0cli -t node_IP_address backup-sensitive-status`;
+3. Retrieve backup of sensitive information: `a0cli -t node_IP_address backup-sensitive-retrieve`;
+4. Delete the sensitive backup from the node: `a0cli -t node_IP_address backup-sensitive-delete`.
+
+## Check the Status of the Backup
+
+You can check on the status of a backup (or whether a backup exists) by running the following command in your local command-line instance:
+
+```bash
+a0cli -t  backup-status
+```
+
+If a backup is available, you will see a message similar to the following:
+
+```json
+{
+    "message": "Backup found",
+    "arguments": {
+        "name": "file-name.tar.gz"
+        "md5": ""
+    }
+}
+```
+
+![](/media/articles/appliance/cli/backup-available.png)
+
+### Retrieve an Existing Backup
+
+Before retrieving a backup, we recommend [checking to see if there is one](#checking-the-status-of-the-backup) first.
+
+To retrieve an existing backup, you will use the "backup-retrieve" message in your local command-line instance:
+
+```bash
+a0cli -t  backup-retrieve
+```
+
+This will download the backup inside of a file called `backup-retrieve.tar.gz.enc`.
+
+Auth0 recommends checking the md5sum of the retrieved file against that received as part of the back-up status message.
+
+```bash
+md5 backup.tar.gz.enc
+```
+
+Please remember that the files are encrypted using the `aes-256-crt` algorithm.
+
+## Delete a Backup
+
+To delete an existing backup, you will use the "backup-delete" message in your local command-line instance:
+
+```bash
+a0cli -t  backup-delete
+```
+
+## Restore a Backup
+
+To restore a backup, please open up a ticket requesting assistance via the [Auth0 Support Center](https://support.auth0.com/).
diff --git a/ja-jp/articles/appliance/cli/configure-cli.md b/ja-jp/articles/appliance/cli/configure-cli.md
new file mode 100644
index 0000000000..90b57df34f
--- /dev/null
+++ b/ja-jp/articles/appliance/cli/configure-cli.md
@@ -0,0 +1,123 @@
+---
+section: appliance
+description: How to configure the PSaaS Appliance CLI
+topics:
+    - appliance
+    - cli
+contentType: how-to
+useCase: appliance
+applianceId: appliance13
+sitemap: false
+---
+
+# Configuring and Using the Auth0 Appliance Command Line Interface
+
+The PSaaS Appliance Command Line Interface (CLI) allows you to perform operations on your PSaaS Appliance instances via authorized workstations.
+
+## Downloading the CLI Setup Files
+
+To download the files required to set up the CLI, submit a [support ticket](https://support.auth0.com/tickets) for your custom download link.
+
+## Installing and Using the CLI
+
+Once you have downloaded and unzipped the `a0cli-v.1.x.x` file, you will select the version that is appropriate for the operating system you are using. Auth0 provides installers for Windows, Macintosh, and Linux systems, and the installer will guide you through the installation process.
+
+Once this process is complete, you will be able to run the `a0cli` program from your local command-line instance.
+
+```text
+Usage: a0cli [options] 
+
+
+ Commands:
+
+   create-key           Creates private/public keys pair on current path.
+   show-key             Shows public key on current path.
+   delete-key           Deletes keys pair from current path.
+   update-commands      Retrieve available commands from the specified node.
+
+ Options:
+
+   -h, --help           output usage information
+   -V, --version        output the version number
+   -t, --target     Host name or IP address of appliance instance.
+   -p, --port   Port number of appliance instance. Default port: 10121
+```
+
+However, if you have keys defined and you've run `update-commands`, you will see an extended list of commands:
+
+```text
+Usage: a0cli [options] 
+
+
+  Commands:
+
+    create-key                       Creates private/public keys pair on current path.
+    show-key                         Shows public key on current path.
+    delete-key                       Deletes keys pair from current path.
+    update-commands                  Retrieve available commands from the specified node.
+    backup                 Creates a new backup.
+    backup-delete                    Deletes the current sensitive backup
+    backup-retrieve                  retrieves the current backup.
+    backup-sensitive       Creates a new backup of sensitive configuration.
+    backup-sensitive-delete          Deletes the current backup
+    backup-sensitive-retrieve        retrieves the current sensitive backup.
+    backup-sensitive-status          Retrieves the status of the node backup.
+    backup-status                    Retrieves the status of the node backup.
+    nslookup                   Performs an nslookup to the specified  from the target node.
+    ping                             Sends a PING message to verify if the target node is up.
+    re-ip                     Updates the host entries for instances in the database cluster. Example a0-1:10.1.0.21,a0-2:10.1.0.22
+    set-as-backup  [force]   Add the backup role to the target node.
+    test-port            Verifies if the target ip can listen  on .
+    user-export    Exports user to a file.
+    user-export-delete               Deletes the current user-export
+    user-export-retrieve             retrieves the current user-export file.
+    user-export-status               Retrieves the status of the user-export.
+
+  Options:
+
+    -h, --help           output usage information
+    -V, --version        output the version number
+    -t, --target     Host name or IP address of appliance instance.
+    -p, --port   Port number of appliance instance. Default port: 10121
+
+```
+
+::: note
+  Because the CLI sends commands to the server running on each PSaaS Appliance's node, please ensure that the server is both available and can accept inbound and outbound connections to port `10121`.
+:::
+
+## Granting Access Rights to Users
+
+Only workstations that you have authorized may perform operations on the PSaaS Appliance.
+
+To authorize a new workstation for use with the CLI:
+
+1. Generate a key pair by running, in your local command-line tool, `a0cli create-key`. This outputs a public key, which is now associated with that particular workstation. You will also need to copy for this key to complete the next step.
+
+    ![](/media/articles/appliance/cli/cli-create-key.png)
+
+2. Navigate to the CLI page of the PSaaS Appliance configuration area, and add the key to your configuration. For additional information on how to do this, please see the [configuration instructions for PSaaS Appliance CLIs](/appliance/dashboard/cli).
+
+    ![](/media/articles/appliance/cli/cli-config-with-key.png)
+
+::: note
+Please note that any user on the workstation with access to the location where the key is stored locally will have access rights to perform operations on the PSaaS Appliance.
+:::
+
+## Updating Command Lists
+
+To send commands to the PSaaS Appliance's node, you will need to update the command list the node accepts by running the following command:
+
+`a0cli -t  update-commands`
+
+You may test this process by sending a `ping` message:
+
+`a0cli -t  ping`
+
+If the test was successful, you will see the following response:
+
+`{"message": "PONG"}`
+
+::: note
+  To get a list of available commands, run `a0cli` (omitting all parameters).
+:::
diff --git a/ja-jp/articles/appliance/cli/index.md b/ja-jp/articles/appliance/cli/index.md
new file mode 100644
index 0000000000..8f2d5a346f
--- /dev/null
+++ b/ja-jp/articles/appliance/cli/index.md
@@ -0,0 +1,22 @@
+---
+url: /appliance/cli
+section: appliance
+description: How to use the PSaaS Appliance CLI
+topics:
+    - appliance
+    - cli
+    - backups
+contentType: how-to
+useCase: appliance
+applianceId: appliance14
+sitemap: false
+---
+
+# Private SaaS (PSaaS) Appliance Command Line Interface
+
+The PSaaS Appliance Command Line Interface (CLI) allows you to perform operations on your PSaaS Appliance instances via authorized workstations.
+
+* [How to Configure the Command Line Interface for User with PSaaS Appliance Instances](/appliance/cli/configure-cli)
+* [Backing up PSaaS Appliance Instances with the CLI](/appliance/cli/backing-up-the-appliance)
+    * [Adding PSaaS Appliance Nodes to the Backup Role](/appliance/cli/adding-node-to-backup-role)
+* [How to Reconfigure IP Addresses Using the Command Line Interface](/appliance/cli/reconfiguring-ip)
diff --git a/ja-jp/articles/appliance/cli/reconfiguring-ip.md b/ja-jp/articles/appliance/cli/reconfiguring-ip.md
new file mode 100644
index 0000000000..8ec85afb75
--- /dev/null
+++ b/ja-jp/articles/appliance/cli/reconfiguring-ip.md
@@ -0,0 +1,18 @@
+---
+section: appliance
+description: How to reconfigure PSaaS Appliance IP Addresses using the CLI
+topics:
+    - appliance
+    - cli
+    - ip-addresses
+contentType: how-to
+useCase: appliance
+applianceId: appliance15
+sitemap: false
+---
+
+# How to Reconfigure IP Addresses Using the Command Line Interface
+
+When running in a cluster, the PSaaS Appliance nodes need to know the IP addresses of the other nodes within the same cluster (they do not automatically detect each other). Whenever you move the network of the cluster, the IP addresses of the individual nodes need to be re-set to match the original node names.
+
+Beginning with PSaaS Appliance build **14591**, reconfiguring of IP addresses using the PSaaS Appliance's Command Line Interface (CLI) is no longer possible. Please open a support ticket when you're ready to reconfigure your VMs' IP addresses, as this operation will be carried out by an Auth0 MSE.
diff --git a/ja-jp/articles/appliance/clock.md b/ja-jp/articles/appliance/clock.md
new file mode 100644
index 0000000000..5674a7c5b0
--- /dev/null
+++ b/ja-jp/articles/appliance/clock.md
@@ -0,0 +1,48 @@
+---
+section: appliance
+description: How to manage the time on PSaaS Appliance
+topics:
+    - appliance
+    - time-sync
+contentType: how-to
+useCase: appliance
+applianceId: appliance53
+sitemap: false
+---
+# Time Synchronization
+
+Auth0 uses several cryptographic functions that depend on the system clock.
+
+If you are running Auth0 on an IaaS (Infrastructure as a Service) provider (such as AWS, Microsoft Azure, and so on), time synchronization is managed automatically and you can skip these instructions.
+
+If you are running Auth0 on your own hardware or a VM host, the PSaaS Appliance must have NTP configured correctly. In most cases, the NTP server is your Domain Controller. Contact your IT administrator for details.
+
+The NTP server address can be changed in the configuration section of the Dashboard:
+
+![NTP server address](/media/articles/appliance/clock/ss-2014-12-15T11-34-37.png)
+
+Enter either the IP address or the DNS name of the NTP server.
+
+### Configuration options
+
+Auth0 uses __ntpd__ for internal time synchronization. As described in the [ntpd documentation](http://doc.ntp.org/4.1.1/confopt.htm), to change the various configuration parameters from the default settings, enter these on the same line after the NTP server address.
+
+For example, the following settings will increase the frequency of updates:
+
+![Increase the frequency of updates](/media/articles/appliance/clock/ss-2014-12-15T11-36-53.png)
+
+```text
+1.south-america.pool.ntp.org burst iburst minpoll 3 maxpoll 5
+```
+
+::: note
+These options specify the minimum and maximum poll intervals for NTP messages in seconds to the power of two. The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h). The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 4 (16 s).
+:::
+
+::: note
+Fine tuning is only available to Auth0's engineers.
+:::
+
+If the virtual-machine hosting software, such as VMware, has an option for the host operating system (OS) to update the guest OS, this must be turned off so that the host will not interfere with the NTP time synchronization of the guest PSaaS Appliance.
+
+For example, in VMware Tools, the "sync guest time with host" checkbox must be unchecked (off) for the Auth0 guest virtual machine.
diff --git a/ja-jp/articles/appliance/critical-issue.md b/ja-jp/articles/appliance/critical-issue.md
new file mode 100644
index 0000000000..d7b7d47801
--- /dev/null
+++ b/ja-jp/articles/appliance/critical-issue.md
@@ -0,0 +1,73 @@
+---
+sitemap: false
+section: appliance
+description: Outlines additional support procedure information for enterprise subscription customers with an Auth0 PSaaS Appliance.
+topics:
+    - appliance
+    - support
+contentType: 
+    - how-to
+    - concept
+useCase: appliance
+applianceId: appliance54
+sitemap: false
+---
+
+# Critical Support Issue Guidance for Appliance Customers
+
+This document outlines additional support procedure information for enterprise subscription customers with an PSaaS Appliance and should be read in conjunction with the general [Enterprise Support Guidance document](/onboarding/enterprise-support).
+
+PSaaS Appliance customers must have [Enterprise Support](/onboarding/enterprise-support#premium-enterprise-support) as a minimum. Refer to your subscription agreement to confirm if other custom support or SLA coverage has been included.
+
+Below are special procedures PSaaS Appliance customers should follow for Critical Support Issues.  All other information as outlined in the [Enterprise Support Guidance document](/onboarding/enterprise-support) is still valid and should be followed.
+
+## What is a Critical Issue
+
+A Critical Issue is defined as an Auth0 issue severely impacting your live or in-production systems where:
+
+- major business processes and functions are severely impaired or stopped;
+- the majority of users are adversely impacted;
+- there is no workaround
+
+::: note
+Please do *not* submit an Urgent ticket for non-production environments. Urgent (critical) tickets are reserved for production environments.
+:::
+
+## Special procedures for critical issues impacting production applications for PSaaS Appliance customers
+
+PSaaS Appliance customers should use the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) as a primary method of logging a critical support issue. As part of the onboarding procedure a cloud account should be created that gives administrators the possibility to log in to Support Center and create new tickets. Set the ticket severity to **Urgent** if you need an immediate response.
+
+::: note
+Using Support Center requires a cloud account setup. If you are unsure about this, please try logging in at the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) or check with your Auth0 Technical Account Manager.
+:::
+
+As a secondary point of escalation, PSaaS Appliance customers can also send an email to `productionoutage@auth0.com` to log a critical support issue. *Note that this should only be a secondary escalation point, as a ticket created in Support Center provides a more reliable way to identify the customer having the problem and interact with the user.*
+
+### To log a critical support issue in Support Center
+
+1. Go to the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) and log in with your credentials.
+2. Click on the [Open Ticket](${env.DOMAIN_URL_SUPPORT}/tickets/new) button.
+3. Select your **Associated Support Cloud Tenant**, **Affected Root Tenant Authority** (optional), and **Affected Tenant** (optional).
+4. For **What can we help you with?** select **Appliance Support Incident**.
+5. For **Severity** select **Urgent**.
+  ::: note
+  If you don't select **Urgent**, the issue will not be treated as critical. You will not be able to change the severity of the ticket once it is created so if, for example, you set Severity to `High` but later realize that the situation is critical, you need to create a new ticket with `Severity` set to Urgent.
+  :::
+6. Provide an appropriate **Subject** title.
+7. Describe the problem as completely as possible. *The more information you can provide about the issue you are having, the better we can provide quick and valuable support.*
+
+### Information to provide when logging an issue by email
+
+To speed resolution, please provide the following when logging an issue via email (in addition to other information listed in the [Enterprise Support Guidance document](/onboarding/enterprise-support)):
+
+* Your Company Name and specific project name (some customers have more than one instance of Auth0)
+* Your contact details and the contact details of relevant colleagues such as IT operations staff, including email address and phone numbers with relevant country and area codes.
+
+### What to expect
+
+When an issue has been logged correctly:
+
+* It will be acknowledged immediately by email and assigned a ticket ID number. Additional information may be requested.
+* A responding Auth0 support staff member may contact you via email and/or direct you to join a private Slack channel and/or a Zoom web conference to facilitate faster communications.  However, it’s important to remember you should not initiate requests for help via a Slack channel - only via the methods outlined above. Slack channels may not be actively monitored.
+* In addition to communications over a web conference or Slack, to preserve a record of an issue, any critical information, such as log files, symptoms, and so on should be sent as updates to the ticket via support center.  Any conclusions or next steps should be added to the ticket as well.
+* Upon resolution of the issue, an Auth0 support staff member will ask the customer for confirmation the issue has been resolved to their satisfaction and the ticket will be closed only when customer has responded and confirmed issue is resolved.
diff --git a/ja-jp/articles/appliance/custom-domains/index.md b/ja-jp/articles/appliance/custom-domains/index.md
new file mode 100644
index 0000000000..cb3728aba9
--- /dev/null
+++ b/ja-jp/articles/appliance/custom-domains/index.md
@@ -0,0 +1,83 @@
+---
+url: /appliance/custom-domains
+section: appliance
+description: How to set up custom domains for your PSaaS Appliance
+topics:
+    - appliance
+    - custom-domains
+contentType: 
+    - index
+useCase: appliance
+applianceId: appliance16
+sitemap: false
+---
+
+# Private SaaS (PSaaS) Appliance: Custom Domains
+
+::: warning
+Private SaaS Deployments (beginning with release 1905) must use the Auth0 [Custom Domains](/custom-domains) feature instead of the PSaas Custom Domains feature when creating new Custom Domains (regardless of whether they have existing Custom Domains using the PSaaS Custom Domains feature or not). **The PSaaS Custom Domains feature is deprecated.** Please contact your Auth0 MSE if you have any questions.
+:::
+
+If you are using **PSaaS Appliance Build 5XXX** or later, you may configure custom domains using the Management Dashboard.
+
+Custom domains allow you to expose one arbitrary DNS name for a tenant. Conventionally, the PSaaS Appliance uses a three-part domain name for access, and it is the first portion of the domain name that varies depending on the tenant.
+
+The root tenant authority (RTA) is a special domain that is configured when the PSaaS Appliance cluster(s) are first set up. It is a privileged tenant from which certain manage operations for the cluster are available. The RTA is sometimes called the configuration domain, and all users that have access to the Management Dashboard belong to an application in the RTA.
+
+::: note
+  All tenant domain names derive from the root tenant authority, and any changes to this will result in the deletion of all tenants.
+:::
+
+## Custom Domains Features
+
+The follow is a list of custom domain features that differ in behavior from their implementation in the Auth0 Public Cloud or have yet to be released to PSaaS Appliance implementations.
+
+| Feature | Currently Supported in the PSaaS Appliance? |
+| - | - |
+| Use of custom domain in emails | No |
+| Custom domain protection via API keys | No |
+| Custom domain registration | Yes; accessible via PSaaS Appliance Dashboard |
+| Token issuer used as custom domain | No |
+| Auth0-managed certificates | No |
+
+
+## Use Example
+
+Suppose that your RTA is `config.example.com`. From this point on, all of your new tenants' domain names must derive from the base name, `example.com`:
+
+```text
+site1.example.com
+site2.example.com
+```
+
+However, you might want to expose other domain names to your end users, such as:
+
+* `auth.site2.com`
+* `auth.site1.com`
+* `auth.site1.example.com`
+
+You may do so by utilizing the PSaaS Appliance's custom domains feature, which sets the domain used for authentication endpoints.
+
+## Certificates Required for Custom Domains
+
+Custom domains map one external DNS to a tenant that follows the standard naming convention.
+
+Suppose that we have a tenant with the following domain:
+
+`auth.example.com`
+
+Suppose that we want the following domain to map to `auth.example.com`:
+
+```text
+auth.site2.com
+```
+
+The custom domain has its own certificate, which is stored separately.
+
+## Configuring Custom Domains
+
+You may configure custom domains for your tenants via the [custom domains set-up area](/appliance/dashboard/tenants#custom-domains) of the [tenants page in the PSaaS Appliance configuration area](/appliance/dashboard/tenants).
+
+## Custom Domains for PSaaS Appliance's Hosted in Auth0’s Private Cloud
+
+If your PSaaS Appliance is hosted in Auth0’s private cloud, your domains will end in *auth0.com*. If you want to use a custom domain with your customer-facing applications, see [Information Requirements for Setting Up the PSaaS Appliance in Auth0's Private Cloud](/appliance/private-cloud-requirements).
diff --git a/ja-jp/articles/appliance/dashboard/activity.md b/ja-jp/articles/appliance/dashboard/activity.md
new file mode 100644
index 0000000000..d73389b069
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/activity.md
@@ -0,0 +1,27 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Activity page
+topics:
+    - appliance
+    - dashboard
+contentType: concept
+useCase: appliance
+applianceId: appliance17
+sitemap: false
+---
+
+# PSaaS Appliance Dashboard: Activity
+
+::: note
+For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#psaas-appliance-controls).
+:::
+
+After you begin an update or make a change to the configuration, Auth0 displays progress and logs for those actions on this page in case you need the information for troubleshooting purposes.
+
+![](/media/articles/appliance/dashboard/activity.png)
+
+On the Activity page, you will see the Configuration Logs displayed, with individual activities organized by the affected nodes. You will also see the status of that given node at the current moment in time.
+
+To see the Debug Logs, click on the "Show Debug Logs" button to see any applicable logs for the nodes associated with your PSaaS Appliance.
+
+![](/media/articles/appliance/dashboard/debug-logs.png)
diff --git a/ja-jp/articles/appliance/dashboard/cli.md b/ja-jp/articles/appliance/dashboard/cli.md
new file mode 100644
index 0000000000..f817659fb8
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/cli.md
@@ -0,0 +1,33 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard CLI page
+topics:
+    - appliance
+    - dashboard
+    - cli
+contentType: concept
+useCase: appliance
+applianceId: appliance18
+sitemap: false
+---
+
+# PSaaS Appliance Dashboard: CLI
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+If your PSaaS Appliance instances requires integration with the PSaaS Appliance Command Line Interface (CLI), you may add the required access keys to this page.
+
+![](/media/articles/appliance/dashboard/cli-keys.png)
+
+Please see your vendor for instructions on generating the public access keys. Once you are in possession of the required key(s), you may associate them with your PSaaS Appliance instance by clicking on "Add Key". You will then be asked for the following pieces of information:
+
+* **Name**: the name that identifies your key;
+* **Key**: the public key string.
+
+![](/media/articles/appliance/dashboard/cli-keys-add.png)
+
+Once you have entered this information, click "Add" to persist your changes.
+
+All of your keys are listed in a tabular format on the CLI page. If, at a later point, you would like to remove a given key from your account, you may do so by clicking on the red "X" located at the end of that key's specific row.
diff --git a/ja-jp/articles/appliance/dashboard/index.md b/ja-jp/articles/appliance/dashboard/index.md
new file mode 100644
index 0000000000..e77472478b
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/index.md
@@ -0,0 +1,47 @@
+---
+section: appliance
+description: >
+  Learn how to use the Management Dashboard to configure things like your Applications, Connections, Users, and Rules.
+url: /appliance/dashboard
+topics:
+    - appliance
+    - dashboard
+contentType: 
+    - reference
+    - concept
+useCase: appliance
+applianceId: appliance19
+sitemap: false
+---
+
+# Private SaaS (PSaaS) Appliance Management Dashboard
+
+Regardless of where you're hosting your PSaaS Appliance, you can use the Management Dashboard to configure things like your Applications, Connections, Users, and Rules.
+
+## PSaaS Appliance Controls
+
+There are certain settings that are managed by Auth0 when you use the cloud service or when Auth0 is managing your private deployment. As such, these controls will not be exposed to you directly, though in the latter instance, you would work with Auth0 engineers when changing settings and applying updates.
+
+These controls, however, are exposed to you if you are managing your PSaaS Appliance instances and are logged in to what is referred to as the **root tenant authority**. If so, you will see a link in the top right corner called **Configuration**. Selecting this link brings you to the PSaaS Appliance configuration area, which contains settings and displays information about your clusters.
+
+![](/media/articles/appliance/dashboard/primary-dashboard.png)
+
+For additional information about the pages contained in the PSaaS Appliance configuration area, please refer to the following documents:
+
+[Nodes](/appliance/dashboard/nodes)
+
+[Settings](/appliance/dashboard/settings)
+
+[Tenants](/appliance/dashboard/tenants)
+
+[Troubleshoot](/appliance/dashboard/troubleshoot)
+
+[Updates](/appliance/dashboard/updates)
+
+[Activity](/appliance/dashboard/activity)
+
+[Rate Limiting](/appliance/dashboard/rate-limiting)
+
+[CLI](/appliance/dashboard/cli)
+
+[OSS Components](/appliance/dashboard/oss-components)
diff --git a/ja-jp/articles/appliance/dashboard/nodes.md b/ja-jp/articles/appliance/dashboard/nodes.md
new file mode 100644
index 0000000000..f406e27741
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/nodes.md
@@ -0,0 +1,38 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Nodes page
+topics:
+    - appliance
+    - dashboard
+    - nodes
+contentType: concept
+useCase: appliance
+applianceId: appliance21
+sitemap: false
+---
+
+# Auth0 Appliance Dashboard: Nodes
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+The Nodes page located under the PSaaS Appliance configuration area provides a high-level overview of the nodes you have running as part of your PSaaS Appliance setup. Each instance that you have with your web service provider is considered a node and is listed individually on this page.
+
+![](/media/articles/appliance/dashboard/nodes.png)
+
+The Nodes page displays the following pieces of information for each of your nodes:
+
+* **Hostname**: the name of the node;
+* **IP**: the IP address used to reach that particular node;
+* **Memory**: the amount of memory allocated to that node;
+* **CPUs**: the number of CPUs allocated to that node;
+* **App Update**: the number of times the node has been updated with application-related updates;
+* **Setting Update**: the number of times the node's settings have been updated;
+* **Heartbeat**: the amount of time elapsed since the Dashboard received communication from the node;
+* **Uptime**: the amount of time the node has been continuously running.
+
+At the end of each row detailing a Node instance are two buttons:
+
+* **Reboot**: if clicked, Auth0 reboots the node;
+* **Remove**: if clicked, Auth0 removes the node from the status list. If the node is still running, the configuration area will publish a new status.
diff --git a/ja-jp/articles/appliance/dashboard/oss-components.md b/ja-jp/articles/appliance/dashboard/oss-components.md
new file mode 100644
index 0000000000..76c680a20e
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/oss-components.md
@@ -0,0 +1,27 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard OSS Components page
+topics:
+    - appliance
+    - dashboard
+    - oss
+contentType: concept
+useCase: appliance
+applianceId: appliance22
+sitemap: false
+---
+
+# OSS Components
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+Auth0 makes use of best-in-class open source software (OSS) components to deliver the Auth0 cloud service. On this page, you will find a comprehensive list of the OSS components that are utilized to deliver Auth0, along with the text of their licenses.
+
+* [Elasticsearch](https://www.elastic.co/)
+* [Puppet](https://puppet.com/)
+* [Node.js](https://nodejs.org/en/)
+* [NGINX](http://nginx.org/)
+* [MongoDB](https://www.mongodb.com/)
+* [Ubuntu Linux](http://www.ubuntu.com/)
diff --git a/ja-jp/articles/appliance/dashboard/rate-limiting.md b/ja-jp/articles/appliance/dashboard/rate-limiting.md
new file mode 100644
index 0000000000..ac92f8c95c
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/rate-limiting.md
@@ -0,0 +1,27 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Rate Limiting page
+topics:
+    - appliance
+    - dashboard
+    - rate-limiting
+conceptType: concept
+useCase: appliance
+applianceId: appliance23
+sitemap: false
+---
+
+# Auth0 Appliance Dashboard: Rate Limiting
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+While the Auth0-managed cloud instances automatically includes rate limiting to ensure quality service, you must manually enable rate limiting if you are using Auth0 PSaaS Appliance instances.
+
+![](/media/articles/appliance/dashboard/rate-limiting.png)
+
+## Settings
+
+* **Enabled**: to enable rate limiting, check this box. Auth0 will then limit requests to services like API and logins to help mitigate malicious attacks;
+* **Configuration of Buckets**: if you have enabled rate limiting, you will be presented with the various "buckets" that set the limits on calls to the API and logins. You may adjust these as necessary.
diff --git a/ja-jp/articles/appliance/dashboard/settings.md b/ja-jp/articles/appliance/dashboard/settings.md
new file mode 100644
index 0000000000..842e959bdc
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/settings.md
@@ -0,0 +1,113 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Settings page
+topics:
+    - appliance
+    - dashboard
+    - settings
+contentType: reference
+useCase: appliance
+applianceId: appliance24
+sitemap: false
+---
+
+# Auth0 Appliance Dashboard: Settings
+
+::: note
+  For additional information on navigating to and using the Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+The Settings page is where you will make most of the changes that pertain to your PSaaS Appliance configuration.
+
+![](/media/articles/appliance/dashboard/settings.png)
+
+The Settings page is broken down into the following sections:
+
+* [General](#general)
+* [Dashboard](#dashboard)
+* [HTTPS Configuration](#https-configuration)
+* [SMTP Server](#smtp-server)
+* [Session](#session)
+* [Update Settings](#update-settings)
+* [Monitoring](#monitoring)
+* [API Keys](#api-keys)
+* [Advanced Settings](#advanced-settings)
+* [Deprecated](#deprecated)
+
+## General
+
+* **Company Handle**: the internal identifier for your company. Use only lowercase characters (no spaces or special characters);
+* **NTP Servers**: the IP address of an internal NTP server (such as *10.4.2.39*) or a public NTP server (such as *1.north-america.pool.ntp.org burst iburst minpoll 3 maxpoll 5*). This setting is particularly important, since it assists in time synchronization among the various pieces of your infrastructure;
+* **Enable GeoIP**: if enabled, Auth0 will update the geo-coding database for mapping IP addresses to locations (you **MUST** permit access to www.maxmind.com through your firewall);
+* **Enforce Logout URLs**: if enabled, Auth0 requires the Logout URL used to be included in the list indicated under Allowed Logout URLs.
+
+## Dashboard
+
+* **Enable "New Account" in Dashboard**: if enabled, you may create new isolated accounts (called tenants) in the PSaaS Appliance;
+* **Federated Logout**: if enabled, signing out of the Dashboard also signs you out from the ldP (such as when using enterprise connections with the Dashboard).
+
+## HTTPS Configuration
+
+* **SSL Certificate Format**: indicates whether the certificate is either *PFX/PKCS12* or *Standard PEM*;
+
+    *If you are using a PFX/PKCS12 certificate:*
+* **SSL PFX Cert**: the password used to authenticate your PFX Certificate;
+* **PFX Certificate**: clicking this button enables you to upload a copy of your PFX Certificate;
+
+    *If you are using a Standard PEM certificate:*
+* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key;
+* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key;
+
+* **Disable TLSv1**: disables TLSv1, which reduces compatibility with technologies like .NET 4.0;
+* **Disable TLSv1.1**: disables TLSv1.1, which reduces compatibility with older browsers like IE 11.
+
+## SMTP Server
+
+* **Send Mails From**: *Deprecated.* The email address used in the "From" field typically comes from that provided on your [custom email template](${manage_url}/#/emails);
+* **SMTP Server**: the name of your SMTP server;
+* **SMTP Port**: the port through which you access your SMTP server;
+* **SMTP User**: the username to log in to your SMTP server;
+* **SMTP Password**: the password to log in to your SMTP server.
+
+## Session
+
+* **Dashboard Session Timeout (min)**: the amount of idle time allowed prior to the Dashboard session getting logged out. Use 0 to avoid expiration;
+* **SSO Session Absolute Timeout**: the absolute time window for which the user can have an SSO session. After this period of time elapses, the user will be required to log in again;
+* **SSO Session Inactive Timeout**: the maximum time window for which the user can have an SSO session without logging in again or calling the "ssodata" endpoint. If the user logs in again or calls the "ssodata" endpoint, the time window will be extended again;
+* **SSO Session Ephemeral Cookie**: if enabled, the SSO session cookie will not persist and users will lose their SSO session in Auth0 after closing their browsers;
+* **MFA Session Absolute Timeout**: the absolute time window for which the user can have an MFA session. After this period of time elapses, the user will be prompted again for MFA;
+* **MFA Session Inactive Timeout**: the maximum time window for which the user can have an MFA session without logging in again. If the user logs in prior to the expiration of this time period, the window will be extended.
+
+### Units of time
+
+When providing time values to Auth0, please use the following abbreviations to ensure the correct units are used:
+
+| Abbreviation | Description |
+| - | - |
+| w | weeks |
+| d | days |
+| h | hours |
+| m | minutes |
+| s | seconds |
+| ms | milliseconds |
+
+## Update Settings
+
+* **Update Proxy**: unless your specific configuration is set up for offline updates, please leave this field blank.
+
+## API Keys
+
+* **Health service**: generates a key that authenticates your API calls for status information regarding your PSaaS Appliance instances;
+
+    ![](/media/articles/appliance/dashboard/health-keys-api-service.png)
+
+    **Please be sure to save the Settings page to persist the newly-generated key.**
+
+## Advanced Settings
+
+* **Enable Large Cookie Size**: if enabled, cookies larger than 4kb will be permitted (this might be required for protocols such as SAML and WS-Federation).
+* **Max Custom Database Timeout**: the maximum time allowed in seconds to make a query to your database (in seconds) for a custom database connection.
+
+## Deprecated
+
+* **Updated URL**: unless your specific configuration is set up for offline updates, please update via [Auth0's hosted mirror site](http://apt-mirror.it.auth0.com).
diff --git a/ja-jp/articles/appliance/dashboard/tenants.md b/ja-jp/articles/appliance/dashboard/tenants.md
new file mode 100644
index 0000000000..120e7b9073
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/tenants.md
@@ -0,0 +1,74 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Tenants page
+topics:
+    - appliance
+    - dashboard
+    - tenants
+contentType: reference
+useCase: appliance
+applianceId: appliance25
+sitemap: false
+---
+
+# PSaaS Appliance Dashboard: Tenants
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+The Tenants page of the PSaaS Appliance Dashboard lists all tenants associated with your PSaaS Appliance instance.
+
+![](/media/articles/appliance/dashboard/tenants.png)
+
+For each associated tenant, you will see the following pieces of information:
+
+* **Name**: the name of the tenant;
+* **Applications**: the number of applications associated with the tenant;
+* **Connections**: the number of Connections enabled for the tenant;
+* **Total Users**: the total number of users associated with the tenant;
+* **Total Logins**: the total number of logins by users associated with the tenant.
+
+## Custom Domains
+
+![](/media/articles/appliance/dashboard/tenant-custom-domain.png)
+
+The name column of the Tenants page is a hyperlink. Clicking on this brings up the page where you can set up custom domains for this particular tenant, as well overview information for any currently-existing custom domains.
+
+### Adding a Custom Domain (legacy PSaaS customers only)
+
+::: note
+The following steps are only required for legacy PSaaS customers. All new customers can use the Custom Domains feature as implemented in the public cloud version. 
+:::
+
+To add a custom domain, click on the "Add Domain" button. You will be prompted for the following information:
+
+
+![](/media/articles/appliance/dashboard/tenant-add-custom-domain.png)
+
+* **Domain**: the custom domain for your tenant;
+* **SSL Available**: the SSL certificate format (either *PFX/PKCS12* or *Standard PEM*);
+
+    *If you are using a PFX/PKCS12 certificate:*
+* **SSL PFX Cert**: the password associated with your PFX/PKCS12 certificate;
+* **PFX Certificate**: clicking this button enables you to upload a copy of your PFX Certificate;
+
+    *If you are using a Standard PEM certificate:*
+* **Upload Public Key...**: clicking this button enables you to upload the file containing your public key;
+* **Upload Private Key...**: clicking this button enables you to upload the file containing your private key.
+
+    ::: note
+      The private key cannot be password protected
+    :::
+
+Once you have provided the required information and uploaded your certificate, click the "Add" button to save your changes and add the custom domain. You will then see a green banner appear on the Custom Domain page that says:
+
+`Updating configuration... check Activity section for progress.`
+
+Once the change has been implemented and you have refreshed the custom domains page, you will see the following overview information about your newly-created domain:
+
+* **Domain**: the custom domain URL;
+* **SSL Available**: indicates successful application of the SSL certificate;
+* **Certificate Subject**: the subject of the certificate, or the target of the certificate (such as what is being secured);
+* **Certificate Expiration**: the date and time when the certificate expires;
+* **Remove Domain**: clicking the "X" button removes this domain from the tenant.
diff --git a/ja-jp/articles/appliance/dashboard/troubleshoot.md b/ja-jp/articles/appliance/dashboard/troubleshoot.md
new file mode 100644
index 0000000000..7af19b48fc
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/troubleshoot.md
@@ -0,0 +1,62 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Troubleshoot page
+topics:
+    - appliance
+    - dashboard
+    - troubleshooting
+contentType: reference
+useCase: appliance
+applianceId: appliance26
+sitemap: false
+---
+
+# PSaaS Appliance Dashboard: Troubleshoot
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+The Troubleshoot page of the PSaaS Appliance Dashboard provides you with tools to help diagnose any issues that might occur.
+
+![](/media/articles/appliance/dashboard/troubleshoot.png)
+
+## Diagnostics Package
+
+You may create a diagnostic package containing detailed information about your PSaaS Appliance instance(s) by clicking on the "Generate New Package" button.
+
+Once you've clicked "Generate New Package", you will see a notification message that indicates that your package is being generated. Once your package is ready, the message will disappear and a link to download the package related to a particular node instance will appear in the last column of your Nodes table.
+
+### Contents of the Diagnostics Package
+
+Upon downloaded your package, you'll notice that the file name formatted as follows: `appliance-logs-[name of node]`. Within this file are the following sub-folders, each containing a series of logs:
+
+* auth0
+* mongodb
+* nginx
+* rabbitmq
+* ssh-auth
+
+## Health Check
+
+The Health Check offers a quick overview of the status of your PSaaS Appliance instances. Data is available for the past hour through the past twenty-nine (29) days.
+
+To obtain data for a specific period of time, change the `Day` and/or `Hour` field to correspond to the time period whose data you want to analyze. Click "Get" to return the specified data.
+
+You can refresh the listed data by clicking on the "refresh" button located on the right hand side.
+
+The following bits of data are available at a glance:
+
+* **Status**: in the column headed by a picture of weather clouds are status symbols reflecting the state of a given node. If all is well, the column appears with a green sunshine icon. If there is something that is attention-worthy, the column appears with a red rain/lightening icon;
+* **Time**: the time at which the data was retrieved;
+* ** All Nodes/IP Addresses: by changing the column heading from "All Nodes" to the IP address of a specific node (and vice versa), you can choose to display data from ALL nodes or just data from a specific node;
+* **Host**: the name of the node in question;
+* **Avail Memory**: the amount of memory available to the node at the time of the Health Check;
+* **CPU**: CPU usage (as a percent) on the node at the time of the Health Check;
+* **Email**: indicates status of email services;
+* **Disk**: indicates status of disk resources;
+* **Network**: indicates status of network availability;
+* **Services**: indicates status of services;
+* **DB**: indicates status of database availability.
+
+By clicking on an individual row listed under the Health Check section, you may view additional information about the resources that are currently running.
diff --git a/ja-jp/articles/appliance/dashboard/updates.md b/ja-jp/articles/appliance/dashboard/updates.md
new file mode 100644
index 0000000000..a78879ad02
--- /dev/null
+++ b/ja-jp/articles/appliance/dashboard/updates.md
@@ -0,0 +1,39 @@
+---
+section: appliance
+description: Overview of the PSaaS Appliance Dashboard Updates page
+topics:
+    - appliance
+    - dashboard
+    - updates
+contentType: reference
+useCase: appliance
+applianceId: appliance27
+sitemap: false
+---
+
+# PSaaS Appliance Dashboard: Updates
+
+::: note
+  For additional information on navigating to and using the PSaaS Appliance Dashboard, please see the section on [PSaaS Appliance Controls](/appliance/dashboard#appliance-controls).
+:::
+
+The Updates page of the PSaaS Appliance configuration area allows you to make the required/selected updates to your PSaaS Appliance instance.
+
+Auth0 recommends taking VM snapshots and backups prior to beginning an upgrade. If there are issues with you upgrade, it might be possible to roll back the PSaaS Appliance to the version used immediately prior to the upgrade (this is the preferred option, since there would not be any data loss).
+
+However, if the option of rolling back to the existing version is not possible, Auth0 will need to restore your environment using the VM snapshots created prior to the update (there will be some data loss in this instance).
+
+![](/media/articles/appliance/dashboard/updates.png)
+
+## Online Update
+The Online Update section allows you to download and install updates from the Auth0 mirror site. This is the recommended way of updating.
+
+You will be asked to provide the *build number* you would like to apply in the **Update To** field. You may select a provided version, or you may provide a custom *build number*.
+
+Once you have selected the appropriate build, any **release notes** applicable will display on the screen.
+
+To begin the update, click on "Update from Internet." You will be prompted once more to confirm to ensure that the appropriate backups have been made, since PSaaS Appliance updates cannot be undone.
+
+::: note
+You should schedule Production updates with your Auth0 Technical Account Manager so that there is an Auth0 Customer Success Engineer available in case any patches need to be manually applied. For more information on updates, see [Updating the PSaaS Appliance](/appliance/admin/updating-the-appliance).
+:::
diff --git a/ja-jp/articles/appliance/disaster-recovery-raci.md b/ja-jp/articles/appliance/disaster-recovery-raci.md
new file mode 100644
index 0000000000..4a9e440e7b
--- /dev/null
+++ b/ja-jp/articles/appliance/disaster-recovery-raci.md
@@ -0,0 +1,174 @@
+---
+description: An in-depth summary of the roles and responsibilities allocated between Auth0 and the subscriber
+section: appliance
+topics:
+    - appliance
+    - disaster-recovery
+    - raci
+contentType: reference
+useCase: appliance
+applianceId: appliance55
+sitemap: false
+---
+
+
+
+# Disaster Recovery: Detailed Division of Responsibility
+
+The following RACI Matrix provides an in-depth summary of the roles and responsibilities allocated between Auth0 and the subscriber.
+
+## Definitions
+
+RACI refers to the following list of definitions:
+
+* **Responsible**: the assigned party who is responsible for implementing the task as required;
+* **Accountable**: the assigned party who is accountable for the task being completed as required;
+* **Consulted**: the party (or parties) whose opinions are requested and with whom there is two-way communication;
+* **Informed**: the party (or parties) who are kept up-to-date with regards to progress and with whom there is one-way communication
+
+## Database Backup
+
+::: note
+Please see [Database Backup](/appliance/disaster-recovery#database-backups) for more information.
+:::
+
+The following table details the task division for configuring, creating, and monitoring the data backup process.
+
+
+
+    
+        
+            
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+    
+
    PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
    Provision Additional Backup DiskIR, AThe subscriber will need to provision an additional drive for backup purposes.
    Download PSaaS Appliance CLI toolCR, AThe subscriber will need to contact their Auth0 Technical Account Manager for the custom download link.
    Install PSaaS Appliance CLI ToolIR, AThe subscriber will need to install the CLI tool.
    Configure Appliance CLI ToolIR, AThe subscriber will need to add a node to the backup role.
    Perform Data Backup via CLI ToolIR, AThe subscriber will need to initiate a backup action via the CLI, as well as check periodically on the status of the backup.
    Beginning with version 11638, a separate Sensitive Configuration Backup needs to performed as well.
    Store Data Backup at a Secondary SiteIR, AThe subscriber will need to retrieve an existing backup and store it in a safe location outside the PSaaS Appliance.
    Delete Data BackupsIR, AOnly one backup should be stored in the backup device. If there exists a backup on the device, the subscriber will be asked to delete it prior to creating a new one.
    
+
+
+## Restore Data Backup
+
+
+
+    
+        
+            
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+    
+
    PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
    Have Data Backup AvailableCR, AThe data backup files should be available and ready to be copied to the Auth0 VMs.
    Provide Backup PasswordIR, AThe subscriber will provide the password used to create and encrypt the backup file. Without this password, the backup file cannot be decrypted and used to restore the environment.
    Create New Virtual Machines from Auth0 ImagesI, CR, AThe subscriber will be responsible for creating the new virtual machines (where the environment will be restored from the backup) using images provided by Auth0.
    Restore the Data BackupR, CIPlease open a ticket in the Auth0 Support Center to request assistance with restoring a backup. Auth0 Customer Success Engineers will review your request, and if necessary, partner with the subscriber's infrastructure engineers to restore the environment. Please note that, in certain cases, a Professional Services fee may apply.
    
+
+
+## Virtual Machine Snapshots
+
+
+
+    
+        
+            
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+    
+
    PSaaS Appliance-Related Tasks or Actions Auth0SubscriberNotes
    Configure / Create VM SnapshotsIR, AThe subscriber is responsible for configuring and create snapshots on a scheduled basis.
    Restore VM SnapshotsIR, AThe subscriber is responsible for restoring a VM Snapshot..
    Recover Auth0 EnvironmentRI, AAuth0 is responsible for recovering the authentication environment.
    
+
+
+## Backup Cadence Recommendations
+
+Auth0 recommends backing up your data on a daily basis (usually overnight to lessen impact on performance). However, if you need greater assurance of up-to-date data or have concerns about a logical data corruption, you might choose to backup more frequently. If this is the case, please contact your Auth0 Technical Account Manager to schedule a discussion, since the backup process puts a substantial load on the backup node and may impact your Production environment.
+
+Auth0 recommends taking **weekly** Virtual Machine Snapshots.
diff --git a/ja-jp/articles/appliance/disaster-recovery.md b/ja-jp/articles/appliance/disaster-recovery.md
new file mode 100644
index 0000000000..a2296865d2
--- /dev/null
+++ b/ja-jp/articles/appliance/disaster-recovery.md
@@ -0,0 +1,93 @@
+---
+description: High-level overview of disaster recovery options for the PSaaS Appliance
+section: appliance
+topics:
+    - appliance
+    - disaster-recovery
+contentType: concept
+useCase: appliance
+applianceId: appliance56
+sitemap: false
+---
+
+# PSaaS Appliance: Disaster Recovery
+
+When preparing for the possibility of issues with your PSaaS Appliance instances, your options depend on your tolerance for downtime. Below, you will find information on the advantages and disadvantages associated with the various disaster recovery (DR) options available.
+
+Additionally, there is a difference between PSaaS Appliance availability and data availability/recovery. For example, the standard three-node cluster deployment has high availability and can survive a single-node failing. However, in cases of a data center failure or a logical data corruption, you would need a disaster recovery solution to help recover from that.
+
+In cases where the data centers have very low latency, you can run individual PSaaS Appliance instances using three different data centers. For example, if you are using AWS, you can run each of your nodes in a different availability zone (though this may incur a higher service cost).
+
+## Geographic High-Availability PSaaS Appliance Implementation
+
+If your requirements demand regional resilience with little downtime, we recommend a [Geographic High-Availability PSaaS Appliance](/appliance/geo-ha) implementation. This is the only implementation that has failover between regions.
+
+Issue detection and failover typically occur at the database level in 30 seconds or less. However, switching over and rerouting traffic from one data center to another is an expensive operation, so we've configured the infrastructure to detect false positives and *not* switch over if one occurs. This secondary detection process reroutes client traffic through failure detection time-out mechanisms that result in an *effective* failover time of approximately ten minutes.
+
+**Advantages**:
+
+Geo-HA is a PSaaS Appliance implementation that provides:
+* Data center redundancy;
+* Rapid failure response;
+* The highest form of PSaaS Appliance availability offered by Auth0.
+
+**Disadvantages**:
+
+Geo-HA involves:
+* A higher cost due to increased complexity;
+* Additional PSaaS Appliance Virtual Machines (VM) that need maintenance;
+* An additional layer in front of the load balancer for GEO failover, such as F5 Global Traffic Manager or AWS Route 53;
+* Additional configuration to handle logical corruption.
+
+For more information, please see:
+* [Geo HA](/appliance/geo-ha)
+* [Disaster Recovery](/appliance/geo-ha/disaster-recovery)
+
+## VM Snapshots
+If you have some tolerance for downtime (either in terms of minutes or hours), you can consider using the Virtual Machine (VM) snapshot approach. A VM snapshot contains everything needed to rebuild a PSaaS Appliance. You would be responsible for regularly taking VM snapshots and either storing them either offsite or replicating them to other regions in the cloud.
+
+**Advantages**:
+* Recovery via VM snapshots is quicker than using database backups (though the process is slower than GEO-HA).
+
+**Disadvantages**:
+* You will need manual intervention from an Auth0 Managed Services Engineer (MSE) to restore your cluster.
+* VM snapshots can become very large (snapshots are not compressed, and you would need a snapshot of each VM/drive), which makes storage tricky.
+* The backup and recovery process requires manual intervention.
+
+### Basic Steps for Recovering with VM Snapshots
+
+The following outlines the basic steps required for restoring PSaaS Appliance instances using VM snapshots:
+
+1. Ensure that you have a snapshot of your VM(s) and that it is stored at a secondary site. In the event of a disaster, your primary site may not be accessible.
+2. Restore your VM(s) using your snapshots at your secondary site.
+3. Contact a Managed Services Engineer via support ticket to complete the recovery of your environment
+
+::: panel VMWare's Site Recovery Manager
+Site Recovery Manager is not supported on current versions of Auth0 PSaaS Appliance. If you rely on this VMWare feature, please contact your Technical Account Manager for guidance.
+:::
+
+## Database Backups
+
+Restoring your PSaaS Appliance with database backups requires you to provision new Virtual Machines (VMs). You will then need assistance from an Auth0 Customer Success Engineer (CSE) to configure the PSaaS Appliance and bring it back online with your restored data.
+
+Database backups are not the same as a snapshot of the whole VM. They are compressed backups created by the [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli). You can then download them from the PSaaS Appliance and store them at a secondary site for recovery in the event you need to implement a recovery scenario.
+
+If you choose to use database backups as your DR strategy, please note that this process may take up to **24 hours**.
+
+**Advantages**:
+* Database backups are smaller and easier to move offsite than VM snapshots.
+
+**Disadvantage**:
+* You will need manual intervention from an Auth0 MSE to restore your PSaaS Appliance.
+* Recovering with a database backup requires the greatest amount of time.
+
+For more information, please see:
+* [Backing Up PSaaS Appliance Instances](/appliance/admin/backing-up-the-appliance-instances)
+* [Using the CLI to Backup PSaaS Appliance Instances](/appliance/cli/backing-up-the-appliance)
+* [Adding an PSaaS Appliance Node to the Backup Role](/appliance/cli/adding-node-to-backup-role)
+
+## Combining VM Snapshots and Database Backups
+
+A middle ground between using VM snapshots and database backups is to take weekly VM snapshots while scheduling nightly database backups.
+
+The recovery process still requires the assistance of an Auth0 CSE, but because the VMs can be automatically restored, only the database needs manual intervention/assistance. This eliminates some of the downtime resulting from using just database backups.
diff --git a/ja-jp/articles/appliance/extensions.md b/ja-jp/articles/appliance/extensions.md
new file mode 100644
index 0000000000..b98480d9b1
--- /dev/null
+++ b/ja-jp/articles/appliance/extensions.md
@@ -0,0 +1,48 @@
+---
+url: /appliance/extensions
+section: appliance
+description: Explains implementation details for Extensions specific to the PSaaS Appliance.
+topics:
+    - appliance
+    - extensions
+contentType: 
+    - concept
+    - how-to
+useCase: appliance
+applianceId: appliance58
+sitemap: false
+---
+
+# PSaaS Appliance: Extensions
+
+While using [Extensions](/extensions) in the PSaaS Appliance is very similar to using Extensions in the multi-tenant installation of Auth0, there are some differences.
+
+You may receive updates to Extensions at any time without prior notice.
+
+## Set up and enable Webtasks
+
+You must set up and enable Webtasks before you can use Extensions.
+
+To [set up and enable your Webtasks](/appliance/infrastructure/extensions#requirements-for-enabling-webtasks), go to the [Webtasks page under Tenant Settings](${manage_url}/#/tenant/webtasks) in the Management Dashboard.
+
+## Configure Extensions
+
+When you activate a Webtask in the PSaaS Appliance, you get a URL specific to that instance of the Webtask service. By default, this URL is structured as follows:
+
+`webtask.`
+
+In order for you to configure Extensions, you will need to add this URL to the **Allowed Origins (CORS)** section under the [Auth0 Dashboard's Application Settings page](${manage_url}/#/applications).
+
+![Allowed Origins Section of Application Settings](/media/articles/appliance/allowed-origins.png)
+
+At this point, you can enable any of the available Extensions [in the dashboard](${manage_url}/#/extensions) and use them just as you would if your Auth0 installation were running in the cloud.
+
+## Delegated Administration Extension
+
+The [Delegated Administration](/extensions/delegated-admin) extension is available beginning with version 10755 when User search is enabled.
+
+## Dedicated Domains
+
+Beginning with PSaaS Appliance version `13451`, you may now configure Webtask on a [dedicated domain](/appliance/webtasks/dedicated-domains). This enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service).
+
+If you are planning on using Extensions, you **must** implement Webtask dedicated domains.
diff --git a/ja-jp/articles/appliance/geo-ha/disaster-recovery.md b/ja-jp/articles/appliance/geo-ha/disaster-recovery.md
new file mode 100644
index 0000000000..8750ac5517
--- /dev/null
+++ b/ja-jp/articles/appliance/geo-ha/disaster-recovery.md
@@ -0,0 +1,126 @@
+---
+section: appliance
+description: Descriptions of PSaaS Appliance Geo HA Failure Scenarios and Testing
+topics:
+    - appliance
+    - geo-ha
+contentType: reference
+useCase: appliance
+applianceId: appliance28
+sitemap: false
+---
+
+
+
+# Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing
+
+The following table details some of the ways in which the Geographic High-Availability PSaaS Appliance may fail and what the implications of such a failure are.
+
+
+    
+        
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+    
+
    EventOutcomePerformance Impact
    Service and Data are available for Primary Site Nodes 1, 2, 3The primary site continues to serve all traffic.None.
    Data Unavailable for Node 1Node 2 or Node 3 becomes the primary data node.None.
    Service Unavailable for Node 1Node 1 is pulled from the primary site load balancer and no longer serves requests.Overall handling capacity may be reduced by up to a third.
    Service and Data Unavailable for Node 1Node 2 or Node 3 becomes the primary data node. Node 1 is pulled from the primary site load balancer and no longer serves requests.Overall handling capacity may be reduced by up to a third.
    Data Unavailable for Nodes 1 and 2Node 3 becomes the primary data node.None.
    Service Unavailable for Nodes 1 and 2All requests from the primary load balancer are routed to Node 3.Overall handling capacity is significantly reduced. Possibility of manual failover to a secondary site.
    Service and Data Unavailable for Nodes 1 and 2All requests from the primary load balancer are routed to Node 3, which is also the primary data node.Overall handling capacity is significantly reduced. Possibility of manual failover to a secondary site.
    Data Unavailable for Nodes 1, 2, and 3The Arbiter elects Node 4, 5, or 6 to become the primary data node.Some performance degradation due to cross-geography data requests while the load balancer continues to service requests from the primary site. Possibility of manual failover to secondary site.
    Service Unavailable for Nodes 1, 2, and 3The Global Load Balancer will route traffic to the secondary application servers (Nodes 4-6). These servers will request data from the primary data server, which is still in the primary data center.Some performance degradation due to cross-geography data requests while the load balancer continues to service requests from the primary site. Possibility of manual failover to secondary site.
    Data and Service Unavailable for Nodes 1, 2, and 3The PSaaS Appliance instances associated with the secondary site are now serving requests.None.
    Connection between the Global Load Balancer and the Primary Site UnavailableAll requests are routed to the secondary site, but the secondary nodes continue to use data on the primary site.Some performance degradation due to cross-geography data requests.
    Arbiter is UnavailableIf the primary and secondary sites are still available, there will be no impact to the end user.None.
    After failover, some (not all) of the nodes resume operationIf some of the nodes are again available in the primary site, the Global Load Balancer will automatically switch to routing requests to the primary site. The Arbiter sees the higher priority data node and sets it as the primary (once it has been fully synced).Possible transient period of unavailability as the load balancer switches the routing of requests.
    All nodes are available again after a failover eventIf the nodes are again available in the primary site, the Global Load Balancer will automatically switch to routing requests to the primary site. The Arbiter sees the higher priority data node and sets it as the primary (once it has been fully synced).None.
    
+
+## Geographic High-Availability PSaaS Appliance Testing
+
+To test the Geographic High-Availability PSaaS Appliance (GEO HA) failover/failback procedure, you should:
+
+1. Take all nodes in the primary data center offline;
+2. Run tests against the global load balancer to ensure that traffic gets rerouted to the secondary site.
+
+GEO HA does not support having both the primary and secondary sites disconnected and active at the same time. Because the data layer is arranged in one stretched cluster, the cluster only permits one data node to act as primary.
+
+The Arbiter, located in a third site, determines which site stays active in the case of severed connectivity between the two data centers, and during this period, it would continue to elect a node in the primary site to serve as the primary data node. As such, it is **not possible** to have two primary data nodes (one in the primary site and one in the secondary site) within a single cluster.
+
+The application layer is always active on all nodes. For performance reasons, only the site containing the primary data node typically serves traffic. This is managed by the global load balancer.
+
+## Backing Up the Geographic High-Availability PSaaS Appliance
+
+As a customer, it is your responsibility to perform regular backups on your Geographic High-Availability PSaaS Appliance (GEO HA). Auth0 recommends a single backup, since the GEO HA is a single cluster stretched over a distance.
+
+Typically, Auth0 recommends performing a daily backup. However, if you have concerns about a logical data corruption, or you need greater assurance of up-to-date data, you might choose to backup more frequently.
+
+Because the backup process puts a substantial load on the backup node, please contact your Auth0 Technical Account Manager to schedule a discussion about performance impact if backups are performed more frequently/during peak usage times.
+
+## Further Reading
+
+* [How to Configure the Command Line Interface for Use with PSaaS Appliance Instances](/appliance/cli/adding-node-to-backup-role)
+* [Backing Up PSaaS Appliance Instances with the Command Line Interface](/appliance/cli/backing-up-the-appliance)
+* [Adding PSaaS Appliance Nodes to the Backup Role](/appliance/cli/configure-cli)
diff --git a/ja-jp/articles/appliance/geo-ha/dr-overview.md b/ja-jp/articles/appliance/geo-ha/dr-overview.md
new file mode 100644
index 0000000000..32051a5492
--- /dev/null
+++ b/ja-jp/articles/appliance/geo-ha/dr-overview.md
@@ -0,0 +1,78 @@
+---
+section: appliance
+description: Descriptions of PSaaS Appliance Geo HA Failure and Disaster Recovery
+topics:
+    - appliance
+    - geo-ha
+    - disaster-recovery
+contentType: reference
+useCase: appliance
+applianceId: appliance29
+sitemap: false
+---
+
+
+
+# Geographic High-Availability PSaaS Appliance Failure & Disaster Recovery
+
+One key aspect of the Geographic High-Availability (GEO HA) PSaaS Appliance is the data center redundancy and failure handling that ensures the highest form of PSaaS Appliance uptime offered by Auth0.
+
+## Standard Configuration
+
+The standard configuration of a GEO HA PSaaS Appliance is a stretched cluster that consists of the following pieces:
+
+* One geographically-aware global load balancer/DNS failover configuration;
+* One primary data center with three PSaaS Appliance instances;
+* One secondary data center with three PSaaS Appliance instances;
+* One arbiter, a seventh instance that is located in its own data center.
+
+## Failure Scenarios and Handling
+
+The following table summarizes what might happen and its possible performance impact in the event that any portion of the standard configuration encounters an error.
+
+
+  
+    
+        
+        
+        
+    
+  
+  
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+  
+
    EventOutcomePerformance Impact
    Data unavailable for one or more (but not all) of the primary data center's node(s)Data for one of the remaining nodes becomes the primaryNone
    Service unavailable for one or more (but not all) of the primary data center's node(s)The unavailable nodes are removed from the primary site load balancer and no longer serves requestsReduction in overall handling capacity
    Data unavailable for all nodes in the primary data centerArbiter elects one of the secondary site's nodes to become the primary data nodePerformance degradation due to cross-geography data requests
    Service unavailable for all nodes in the primary data centerGlobal load balancer redirects all requests to the secondary data center's nodes (but still serves data from the primary data center)Performance degradation due to cross-geography data requests
    Neither data nor service for the primary data center is availableGlobal load balancer redirects all requests to the secondary data centerNone
    Connection failure between global load balancer and primary data centerGlobal load balancer redirects all requests to the secondary data center's nodes (but still serves data from the primary data center)Performance degradation due to cross-geography data requests
    Arbiter is unavailableNo impact to the end user if both the primary and secondary data centers are still availableNone
    
diff --git a/ja-jp/articles/appliance/geo-ha/index.md b/ja-jp/articles/appliance/geo-ha/index.md
new file mode 100644
index 0000000000..16329c8635
--- /dev/null
+++ b/ja-jp/articles/appliance/geo-ha/index.md
@@ -0,0 +1,86 @@
+---
+url: /appliance/geo-ha
+section: appliance
+description: Descriptions of Appliance Geo HA
+topics:
+    - appliance
+    - geo-ha
+    - disaster-recovery
+contentType: 
+    - index
+    - reference
+useCase: appliance
+applianceId: appliance30
+sitemap: false
+---
+
+# Private SaaS (PSaaS) Appliance: High Availability Geo Cluster (Geo HA)
+
+The high availability geo cluster is a PSaaS Appliance implementation that provides regional data center redundancy and rapid failure response. This is the highest form of PSaaS Appliance availability offered by Auth0.
+
+## Overview
+
+Auth0 adds to the single data center high availability solution by extending the cluster with a geographically distributed data center where the recommended **maximum round-trip latency should not exceed 100 ms**. The result is the high availability geo cluster, which is an active hot standby configuration with automated failure handling that can survive a regional outage.
+
+## Standard Configuration
+
+![](/media/articles/appliance/geo-ha.png)
+
+The standard configuration is a stretched cluster that consists of the following pieces:
+
+* One global load balancer/DNS failover configuration;
+* One primary data center with three PSaaS Appliance instances;
+* One standby data center with three PSaaS Appliance instances;
+* One arbiter, a seventh instance that is located in its own data center.
+
+The standby data center instances possess the same PSaaS Appliance configuration as the primary data center instances, and continuous synchronization ensure that the data on the primary and standby data centers mirror each other. The GEOHA stretched cluster should be in the same provider (all nodes in AWS or all nodes in Azure or all nodes on-prem).
+
+::: note
+  Ports 27017 and 7777 must be open between all instances in the cluster.
+:::
+
+### Arbiter
+
+The Arbiter node acts as an independent witness to the primary and secondary data centers.
+
+The Arbiter does not store data or execute application logic, but acts as a witness between the primary and standby data centers. By independently verifying if a data center is down or not, it prevents both from becoming active (such a scenario is known as the "split-brain" condition).
+
+Since the Arbiter isn’t storing data and doesn’t run any services, it can be a small instance with two cores and 4GB of memory.
+
+You must enable outbound [internet connectivity](/appliance/infrastructure/network#internet-connectivity) from the Arbiter for system updates.
+
+### Global Load Balancer/DNS Failover Configuration
+
+You will need to deploy a global load balancer that supports an active/standby configuration. This will be configured to begin using the secondary site if the primary site load balancer is unavailable.
+
+Two examples of products that support this configuration are the F5 Global Traffic Manager and the AWS Route 53 DNS service. The global load balancer is typically positioned in front of the local load balancers in each data center.
+
+### Application Tier
+
+Auth0 requires the use of a load balancer or DNS failover solution that prefers to serve application requests using the primary data center, despite the fact that the PSaaS Appliance instances in the hot standby data center are active and able to serve the requests.
+
+The application tier remains unaware of the locality of the primary data node, whereas the data layer resolves the location of the primary node (the only node that receives application queries). The primary node serves all read and write activities. For example, if the data centers for the geo cluster are in State A and State B and the ones in State B are active, any request serviced by the State A nodes at the application level requires data to then be written to a node in State B. This generally results in poorer performance due to the requests (and resulting round-trips) required to obtain the necessary data. Using a global load balancer or DNS failover solution to prefer the primary location, unless it is not healthy, mitigates this performance issue.
+
+### Data Tier
+
+The data tier operates independently of the application tier as a single cluster stretched across two geographically distributed data centers. Within each data center are three nodes, each provided local data redundancy and failover.
+
+Only one of the two data centers is designated as primary, and the instances within that data center are weighted such that those are always preferred for incoming requests. All read and write activities then pass through the single, active primary node.
+
+As long as all instances are visible to each other, the primary data center will always be elected. If the data center fails (that is, the instances are *not* visible to the witness and PSaaS Appliance in the standby data center), then a node in the secondary data center will be elected to become primary.
+
+If the primary data center becomes available again and its instances are visible to those of the arbiter and the secondary data center, the primary data center will again take precedence over the standby data center when handling incoming requests.
+
+## Failover Handling
+
+1. **The primary data center fails.** The nodes in the standby data center and the arbiter can no longer communicate with the nodes in the primary data center.
+2. **The standby data center becomes the primary data center.** Because the standby data center instances and the arbiter form a majority, they will elect the standby data center instances to become the primary instances.
+3. **The PSaaS Appliance associated with the primary data center begin failing.** Because the primary data center instances cannot communicate with the instances in the standby data center, the associated PSaaS Appliance instances begin to fail.
+4. **The global load balancer/DNS failover configuration detects via health checking that the nodes in the primary data center aren't serving.** It will then switch over to sending requests to the instances of the standby data center.
+5. **The PSaaS Appliance associated with the standby data center are now serving requests** and acting as the primary data node due to its election in step 2.
+
+### Keep reading
+
+::: next-steps
+* [Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing](/appliance/geo-ha/disaster-recovery)
+:::
diff --git a/ja-jp/articles/appliance/index.html b/ja-jp/articles/appliance/index.html
new file mode 100644
index 0000000000..56af4b1bc2
--- /dev/null
+++ b/ja-jp/articles/appliance/index.html
@@ -0,0 +1,145 @@
+---
+url: /appliance
+section: appliance
+classes: topic-page
+title: PSaaS Appliance
+topics:
+    - appliance
+useCase: appliance
+applianceId: appliance59
+sitemap: false
+---
+
+
    
+  
    
+  
    Private SaaS (PSaaS) Appliance
    
+  
    
+    An Auth0 deployment that exists in a dedicated area of Auth0's cloud or your AWS cloud.
+  
    
+
    
+
+
    What is PSaaS Appliance?
    
+
    
+  PSaaS Appliance is a managed service that is typically used if your organization's compliance or policy requirements prevent you from using a multi-tenant cloud service.
+
    
+
    
+  Auth0 is responsible for installation, maintenance, patching and updates. You are responsible for supplying and monitoring the infrastructure on which Auth0 runs (including, but not limited to, the VM host, storage, network resources, and other required dependencies).
+
    
+
+
    PSaaS Appliance Planning
    
+
+
+
+
    PSaaS Appliance Administration
    
+
+
diff --git a/ja-jp/articles/appliance/infrastructure/dns.md b/ja-jp/articles/appliance/infrastructure/dns.md
new file mode 100644
index 0000000000..2466fa2ca1
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/dns.md
@@ -0,0 +1,191 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about DNS
+topics:
+    - appliance
+    - infrastructure
+    - dns
+contentType: reference
+useCase: appliance
+applianceId: appliance31
+sitemap: false
+---
+
+
+
+# DNS
+
+The following document details the requirements of DNS records used for PSaaS Appliance instances.
+
+::: note
+DNS records must be finalized for all of the tenants prior to PSaaS Appliance deployment. They cannot be changed afterwards.
+:::
+
+You’ll need one certificate per environment (such as if you have a Dev/Test environment and a Prod environment, you’ll need two certs).
+
+If you’d like to use a [Webtask Dedicated Domain](/appliance/webtasks/dedicated-domains), you’ll need an additional DNS zone and certificate for each environment. If you have a Dev/Test environment and a Prod environment, you’ll need a two total of two certificates per environment.
+
+Dedicated and non-dedicated host names must be unique.
+
+## Sample DNS Naming Scheme
+
+
+  
+    
+        
+        
+    
+    
+        
+        
+    
+    
+        
+        
+    
+    
+        
+        
+    
+  
+
    Management Dashboardmanage.yourdomain.com
    Configurationconfig.yourdomain.com
    Webtaskwebtask.yourdomain.com
    App Tenant(s)identity.yourdomain.com (for example); 
     app-project.yourdomain.com (if you want more than 1 App tenant) 
    ...and so on
    
+
+For a dev/test non-production PSaaS Appliance a common practice is to include "dev” in the domain name:
+
+
+  
+    
+        
+        
+    
+    
+        
+        
+    
+    
+        
+        
+    
+    
+        
+        
+    
+  
+
    Management Dashboard (Dev)manage.dev.yourdomain.com
    Configuration (Dev)config.dev.yourdomain.com
    Webtask (Dev)webtask.dev.yourdomain.com
    App Tenant(s) (Dev)identity.dev.yourdomain.com (for example); 
     app-name.dev.yourdomain.com (if you want more than 1 App tenant)
    ...and so on
    
+
+### Definitions of Terms Used in the DNS Naming Scheme
+
+* **Configuration**: highly-privileged tenant used to do the PSaaS Appliance baseline configuration and for managing the security of other tenants;
+* **App**: the name of your application;
+* **yourdomain.com**: your organization's domain name.
+
+![](/media/articles/appliance/infrastructure/appliance-dns.png)
+
+## Multi-Tenancy
+
+The Auth0 PSaaS Appliance is capable of supporting multi-tenancy (that is, each tenant may have one or more associated apps). Auth0 may recommend this deployment model when multiple groups within your company share the PSaaS Appliance for different projects. If a customer decides to create multiple app tenants, each app tenant must have its own DNS entry.
+
+## DNS Configuration Requirements
+
+In a standard multi-node cluster deployment, the DNS records will point to the IP address of the [load balancer in front of the cluster](/appliance/infrastructure/infrastructure-overview).
+
+### IP Addresses and DNS Records
+
+For a single-node PSaaS Appliance instance, the DNS record(s) will point to the IP address of the virtual machine itself (this is often the case for the development/test node).
+
+::: note
+  Auth0 does not recommend using the same wildcard certificate(s) for Production **and** non-Production (Test/Development) environments **or** mapping the DNS for both environments to the same servers.
+:::
+
+### Hostnames
+
+The hostname (such as **manage-project**.yourdomain.com) must be at least three characters long and must **not** contain any underscores(_).
+
+The following are reserved tenant names and **may not** be used for the **app** tenant.
+
+
+  
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+  
+
    loginadminappmanageblog
    ftpmailpoppop3imap
    smtpstagestatsstatusdev
    logswwwdocssdkci
    dockerstyleguideaskitcdn
    apireleasesreleasespffeedback
    helpsupportintauth
    
+
+::: warning
+Please note that the [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance) from **auth0** to the supplied name *must be greater than two*. This means that tenant names like **auth** or **authy** (and other similar names) cannot be used.
+
+To see if your tenant name meets this requirement, you can validate your selections using a [Levenshtein Distance calculator](http://www.unit-conversion.info/texttools/levenshtein-distance/).
+:::
+
+The Management Dashboard, Configuration Tenant, and App Tenant(s) must all be a part of the same parent domain (such as yourdomain.com).
+
+Three- or four-part domain names are supported (such as manage.project.yourdomain.com).
+
+### Custom Domains
+
+In the PSaaS Appliance, you may map any arbitrary domain name to a tenant using the Custom Domains feature. You may also map multiple custom domains to a single tenant.
+
+Suppose these were your standard domains:
+
+
+  
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+  
+
    Root Tenant AuthoritySample TenantCustom Domain for the Sample Tenant
    config.example.comauth.example.comnew-name.not-example.com
    
+
+Please note that all tenant names are derived from the base Configuration Tenant. However, you may set your custom domain to point toward any of your tenants (in the example above, `new-name.not-example.com` maps to `auth.example.com`, and the latter may be used by your applications).
diff --git a/ja-jp/articles/appliance/infrastructure/extensions.md b/ja-jp/articles/appliance/infrastructure/extensions.md
new file mode 100644
index 0000000000..f2a2e22e74
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/extensions.md
@@ -0,0 +1,76 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about enabling Webtasks and Extensions
+topics:
+    - appliance
+    - infrastructure
+    - extensions
+contentType: 
+    - Reference
+useCase: appliance
+applianceId: appliance32
+sitemap: false
+---
+# Enable Webtasks, Extensions, and User Search
+
+The PSaaS Appliance supports:
+
+* Extensions
+* [Webtasks](appliance/webtasks)
+* User search using Elasticsearch
+
+## Extensions
+
+You can find a list of extensions available to you [in the Dashboard](${manage_url}/#/extensions).
+
+Some of the [Extensions available to users of the Auth0 public cloud](/extensions) are unavailable in the PSaaS Appliance. As such, these do not appear as options in the PSaaS Appliance's Dashboard.
+
+## Webtasks Requirements 
+
+Your Development and Production environments must meet the following requirements before you can enable Webtasks:
+
+* All nodes in the cluster have outbound access using **Port 443** to:
+  * `docker.it.auth0.com` (or `52.9.124.234`)
+  * `cdn.auth0.com`
+* All nodes can communicate with other nodes in the same cluster using ports **8721** and **8701**.
+* All [SSL certificates](/appliance/infrastructure/security#ssl-certificates) have the appropriate Webtask DNS entry. Examples:
+  * `webtask..com`
+  * `webtask-dev..com`
+
+## Enable Webtasks
+
+Once you have met the requirements for enabling Webtasks, submit a Support ticket to request that Auth0 configure Webtasks on your behalf.
+
+## Dedicated Domains
+
+You may configure Webtasks on a [dedicated domain](/appliance/webtasks/dedicated-domains). Using dedicated domains enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service).
+
+If you are planning on using Extensions, you **must** implement Webtask dedicated domains.
+
+## User search
+
+The PSaaS Appliance supports User Search using Elasticsearch. This allows you to use extensions that require user search functionality, including the [Delegated Administration extension](/extensions/delegated-admin).
+
+### Requirements for enabling user search
+
+To enable User Search, you must increase the amount of storage available in your Development and Production environments.
+
+* If you have a *single non-Production/Development node*, you need an additional **50 GB** drive;
+* If you have a *three-node Production cluster*, you need an extra **100 GB** drive on *each* of your three Virtual Machines;
+* If you have a *Geographic High-Availability implementation*, you need an additional **100 GB** drive on *each* of your data nodes in the primary and secondary data centers.
+
+For all other configuration types, please consult with your Customer Success Engineer.
+
+## Enabling User Search
+
+Once you have added the additional drive(s), submit a Support ticket to request that Auth0 enable User Search.
+
+## Keep reading
+
+::: next-steps
+* [IP Address and Port Requirements](/appliance/infrastructure/ip-domain-port-list)
+* [Extensions](/extensions)
+* [Delegated Administration extension](/extensions/delegated-admin)
+* [Webtasks](/appliance/webtasks)
+* [Version Change Logs](https://auth0.com/changelog/appliance)
+:::
diff --git a/ja-jp/articles/appliance/infrastructure/faq.md b/ja-jp/articles/appliance/infrastructure/faq.md
new file mode 100644
index 0000000000..e9dc9fc33e
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/faq.md
@@ -0,0 +1,101 @@
+---
+description: This page answers several common questions regarding the PSaaS Appliance infrastructure.
+section: appliance
+topics:
+    - appliance
+    - infrastructure
+contentType: reference
+useCase: appliance
+applianceId: appliance33
+sitemap: false
+---
+
+# PSaaS Appliance Infrastructure Requirements: Frequently Asked Questions
+
+#### Are there any functional differences between the Auth0 Cloud and the Auth0 PSaaS Appliance?
+If you have been developing applications with Auth0 in the cloud environment, please review the [differences between the two environments](/deployment).  Please speak to your Auth0 pre-sales engineer or customer success engineer if you’re unsure as to how this may impact your project.
+
+#### Can I configure an HTTP proxy for outbound Internet access in the PSaaS Appliance?
+While proxies are currently unsupported, please speak to your Auth0 Customer Success Engineer if your needs require the user of a transparent proxy or NAT.
+
+#### Can I have SSH access to the machines?
+No, the PSaaS Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the PSaaS Appliance. Auth0 will manage the PSaaS Appliance internals.
+
+#### Can I install a monitoring agent in the PSaaS Appliance?
+No, the PSaaS Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the PSaaS Appliance. Auth0 will manage the PSaaS Appliance internals. The PSaaS Appliance [exposes monitoring information](/appliance/monitoring) in the Dashboard for common metrics (CPU/memory/and so on) or through the API, which can be used by your operations team and monitoring tools to determine how the PSaaS Appliance is performing.
+
+[Testall](/appliance/monitoring/testall) is an unauthenticated endpoint that can be used by load balancers. There are also additional authenticated endpoints that provide detailed information.
+
+#### Can I install anti-virus software on the PSaaS Appliance?
+While this is currently not supported, preinstalled anti-virus software may be included in future updates.
+
+#### Will Auth0 provide me with a CSR file for my SSL Certificate?
+No. The details of generating certificates, such as a CSR, vary among public certificate providers. Please work with your public certificate authority for these requirements.
+
+If Auth0 hosts the PSaaS Appliance, Auth0 will provide the required `*.auth0.com` SSL certificates.
+
+#### Why do both the DEV (non-prod) node and PROD cluster require unique certificates signed by a public Certificate Authority?
+Webtasks and web extensions require this due to Node.js security requirements.
+
+#### Can I whitelist specific IP addresses on my firewall to the Internet sites the PSaaS Appliance requires outbound access to?
+
+For Auth0 PSaaS Appliance updates, we can provide you with specific addresses that are required.
+
+For certain protocols, [Internet connectivity is required during operation](/appliance/infrastructure/internet-restricted-deployment) (such as social connections or emails).
+
+Your server also needs to be able to access **cdn.auth0.com** if you run web extensions. The browsers used by your admins will also need to access the CDN if they navigate to the Management Dashboard.
+
+#### Can I use Lock with my PSaaS Appliance implementation?
+
+Yes, you can use Lock with your PSaaS Appliance implementation.
+
+However, if you choose to operate your applications connected to the [PSaaS Appliance in an Internet-restricted environment](/appliance/infrastructure/internet-restricted-deployment), you will need to copy the library files to your network (you won't be able to access the CDN that hosts Lock).
+
+If you choose this option, you are responsible for ensuring that your copy of the Lock source code stays up-to-date.
+
+#### How is the Auth0 software installed? 
+
+The PSaaS Appliance is a managed service that is deployed as [virtual machines](/appliance/infrastructure/virtual-machines) and runs on your network, so there is no traditional software installation involved.
+
+Deployment of each PSaaS Appliance node is a manual process that must be performed by Auth0 Managed Service Engineers.
+
+#### Can the PSaaS Appliance deployment be automated through Chef scripts?
+
+Deployment of each PSaaS Appliance node is a manual process that must be performed by Auth0 Managed Service Engineers. 
+
+While the images could be deployed via automation, configuration of the Appliance requires the services of an Auth0 Managed Service Engineer.
+
+#### Can we deploy the PSaaS Appliance using Docker?
+
+No, the Auth0 services cannot be deployed using Docker containers.
+
+#### Does the PSaaS Appliance environment autoscale (that is, does it automatically spin up new nodes or remove nodes as load and demand requires)?
+
+While the PSaaS Appliance can scale out its service layer, it is not currently designed to automatically scale up (or down) from the number of initial nodes deployed. 
+
+Auth0 will work with you during the Sales/Onboarding process to ensure you are deploying the appropriate PSaaS Appliance architecture for your use case.
+
+Our Professional Services team offers [Performance and Scalability](https://auth0.com/docs/services/performance-scalability) engagements to performance test and subsequently tune the PSaaS Appliance to your specific requirements.
+
+#### How does Auth0 access customer-hosted PSaaS Appliance VMs?
+
+Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS Appliance instances to configure, perform updates, perform maintenance, or troubleshoot. The remote access options are:
+
+1. Jumphost + Firewall Whitelist
+2. Two Jumphosts
+
+We do not support other methods, such as VDI or Screen Sharing mechanisms.
+
+#### We occasionally tear-down and rebuild environments, and we maintain our data by backing it up first. Is this a problem?
+
+The Auth0 Appliance is not designed to be torn down and rebuilt easily, and such actions always requires Auth0 involvement. We therefore ask that you not tear down the environment on purpose.
+
+To assist in the rebuilding of the environment, we would need to have an active Professional Services engagement in place with you, unless there has been a disaster situation.
+
+#### What are the legal terms of the Private SaaS Appliance?
+
+You can read the PSaaS Appliance terms [here](https://auth0.com/legal/baseline/PSaaS).
+
+#### Does the PSaaS Appliance require internet access?
+
+Please refer to [our documentation on the internet-related requirements](/appliance/infrastructure/internet-restricted-deployment) for the PSaaS Appliance.
diff --git a/ja-jp/articles/appliance/infrastructure/index.md b/ja-jp/articles/appliance/infrastructure/index.md
new file mode 100644
index 0000000000..6f2919f464
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/index.md
@@ -0,0 +1,30 @@
+---
+title: PSaaS Appliance Infrastructure Requirements
+url: /appliance/infrastructure
+section: appliance
+description: This document contains information about the PSaaS Appliance and its infrastructure requirements.
+topics:
+    - appliance
+    - infrastructure
+contentType: 
+    - index
+    - reference
+useCase: appliance
+applianceId: appliance34
+sitemap: false
+---
+
+# Private SaaS (PSaaS) Appliance Infrastructure Requirements
+
+This document contains the following information about the PSaaS Appliance and its infrastructure requirements:
+
+* [installation process](/appliance/infrastructure/installation);
+* [infrastructure overview](/appliance/infrastructure/infrastructure-overview);
+* infrastructure requirements, including details for:
+    * [Virtual Machines](/appliance/infrastructure/virtual-machines);
+    * [Network](/appliance/infrastructure/network);
+    * [IP/Domain and Port List](/appliance/infrastructure/ip-domain-port-list)
+    * [Security and Access](/appliance/infrastructure/security).
+* [Webtasks and Web Extensions](/appliance/infrastructure/extensions)
+
+Please consult the [FAQ](/appliance/infrastructure/faq) for further information about the PSaaS Appliance.
diff --git a/ja-jp/articles/appliance/infrastructure/infrastructure-overview.md b/ja-jp/articles/appliance/infrastructure/infrastructure-overview.md
new file mode 100644
index 0000000000..b9e92e633a
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/infrastructure-overview.md
@@ -0,0 +1,16 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure overview
+topics:
+    - appliance
+    - infrastructure
+contentType: concept
+useCase: appliance
+applianceId: appliance35
+sitemap: false
+---
+# PSaaS Appliance Deployment Architecture
+
+The typical Auth0 PSaaS Appliance production deployment is a three-node clusters that allows for high availability. The following diagram outlines the typical architecture.
+
+
\ No newline at end of file
diff --git a/ja-jp/articles/appliance/infrastructure/installation.md b/ja-jp/articles/appliance/infrastructure/installation.md
new file mode 100644
index 0000000000..4197c25fc8
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/installation.md
@@ -0,0 +1,66 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about installation
+topics:
+    - appliance
+    - infrastructure
+    - installation
+contentType: 
+    - concept
+    - how-to
+useCase: appliance
+applianceId: appliance36
+sitemap: false
+---
+
+
+
+# PSaaS Appliance Infrastructure Overview
+
+## Project Coordination and Execution
+
+Auth0 provides a project plan methodology to help customers get up and running with the PSaaS Appliance as efficiently as possible. This requires significant cooperation and coordination across a number of your internal teams. Below is a list of teams commonly required to be involved in the PSaaS Appliance project and tasks they may be required to complete. In our experience, early exposure of the teams to the project and the tasks they'll have results in a more effective execution of the project plan.
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+        
+            
+            
+        
+    
+
    TeamSample Tasks
    IT InfrastructureProvision Virtual Machines
    IT SecurityGenerate SSL certificates; approve Internet access/ports
    IT NetworkingConfigure firewall; deploy/configure load balancer
    IT OperationsBackup and monitor PSaaS Appliance infrastructure
    
+
+## Overview of Required Steps
+
+The following basic steps are required to get the infrastructure up and running and the PSaaS Appliance deployed:
+
+1. Understand the PSaaS Appliance infrastructure requirements as detailed in this document.
+2. Set up the infrastructure after the Appliance Project Manager has shared the required AMI file with you.
+3. Complete and submit the [PSaaS Appliance Install Checklist](https://docs.google.com/forms/d/e/1FAIpQLSckWRi2MWpzhBkUXoqjaEzMPGUsyL4ICbOetcGvSnn64dSM-A/viewform?c=0&w=1) to notify Auth0 that you have the required infrastructure in place and that Auth0 can begin configuring the PSaaS Appliance.
+4. Meet with Auth0 to deploy the DEV and PROD environments (the Appliance Project Manager will set up this meeting).
+
+## Development/Test/Production Lifecycle
+
+::: note
+Production and non-Production (test/development) must be on completely isolated networks.
+:::
+
+All PSaaS Appliance multi-node cluster subscription agreements require the deployment of a single-node Development/Test (non-Production) instance. This node is used to verify that the PSaaS Appliance is working as expected with your applications prior to deployment to Production. It also allows for a thorough PSaaS Appliance update and testing cadence. Lastly, this improves any possible support experiences, since Auth0 engineers prefer testing or reviewing planned changes/fixes to your implementation in a non-Production environment.
diff --git a/ja-jp/articles/appliance/infrastructure/internet-restricted-deployment.md b/ja-jp/articles/appliance/infrastructure/internet-restricted-deployment.md
new file mode 100644
index 0000000000..352e6b0e36
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/internet-restricted-deployment.md
@@ -0,0 +1,66 @@
+---
+title: Internet-Restricted PSaaS Appliance Deployments
+description: Operating the PSaaS Appliance in an Internet-Restricted Environment
+contentType: reference
+useCase: appliance
+applianceId: appliance37
+sitemap: false
+---
+# PSaaS Appliance Deployments with Limited Internet Connectivity
+
+The Auth0 PSaaS Appliance is delivered as a managed service that can run in:
+
+* A data center that you own
+* A cloud-based environment that you own
+* Auth0's private cloud
+
+The PSaaS Appliance is designed to mirror the solutions offered via the Auth0 Public Cloud as closely as possible to ensure that features *and* issue fixes can be readily applied to PSaaS Appliance. Though there are differences between the Public Cloud product and the PSaaS Appliance, these are primarily due to technical limitations posed by the PSaaS Appliance environments.
+
+## Internet-Restricted Environments
+
+While we make an effort to create PSaaS Appliances that are encapsulated for normal operation, there are several features that require access to external resources for normal functionality. These resources are primarily located on the Auth0 Content Delivery Network (CDN), which is accessed via **cdn.auth0.com**.
+
+::: warning
+The PSaaS Appliance **must** have access to the internet during [update periods](https://auth0.com/docs/appliance/infrastructure/ip-domain-port-list#external-connectivity).
+:::
+
+Operating the PSaaS Appliance in an internet-restricted environment results in the loss of the following features/functionality:
+
+* Analytics (including usage statistics)
+* Authentication API Explorer
+* [Extensions](/extensions)
+* [Hooks](/hooks)
+* Lock
+* Management API Explorer
+* Management Dashboard
+* Quickstarts
+* Social Connections
+
+### Management Dashboard
+
+The browser that you are using to manage your PSaaS Appliance requires Internet access to navigate to the Management Dashboard (located at **manage.your-domain**). 
+
+You may, however, restrict server-side access to the Management Dashboard.
+
+To properly render the Dashboard, it accesses the following sites:
+
+* **cdn.auth0.com**: resources loaded from this CDN are well-known and include CSS, JavaScript, and images.
+* **fonts.googleapis.com**: resources loaded include CSS and font files.
+* **s.gravatar.com** and **i2.wp.com**: resources include user profile images loaded from WordPress' Gravatar service.
+* **fast.fonts.net**: resources include CSS files for font support.
+
+### Multi-factor Authentication (MFA)
+
+When using multi-factor authentication (MFA), you will need Internet access for Push notifications, SMS, and Voice.
+
+For limited connectivity options, you may choose from:
+
+* One-time password with Google Authenticator, Authy or similar apps
+* A custom MFA implementation using redirect rules
+* Duo (on-premise versions only)
+
+## Summary
+
+The PSaaS Appliance requires access to specific external resources for normal functionality, and we do not recommend restricting access to these resources for optimal function. These resources are primarily located on the Auth0 CDN.
+
+Currently, there are no plans to reduce the reliance of the PSaaS Appliance on the Auth0 CDN.
diff --git a/ja-jp/articles/appliance/infrastructure/ip-domain-port-list.md b/ja-jp/articles/appliance/infrastructure/ip-domain-port-list.md
new file mode 100644
index 0000000000..d81d3d2a2f
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/ip-domain-port-list.md
@@ -0,0 +1,211 @@
+---
+description: PSaaS Appliance infrastructure information about IP/Domain and Port Usage
+section: appliance
+topics:
+    - appliance
+    - infrastructure
+    - ip-addresses
+    - domains
+    - ports
+contentType: reference
+useCase: appliance
+applianceId: appliance38
+sitemap: false
+---
+
+
+
+# PSaaS Appliance Infrastructure Requirements: IP/Domain and Port List
+
+The PSaaS Appliance requires certain ports within the cluster to be open and able to access each other, as well as selected external sites.
+
+## Between Cluster Nodes
+
+When possible, instances within a cluster should have full connectivity to each other so that you do not need to introduce new firewall rules if Auth0 adds new features. However, since this isn't possible in every environment, the following table lists the ports that are required to be open and accessible to other PSaaS Appliance instances in the same cluster:
+
+
+  
+  
+    
+    
+    
+    
+  
+  
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+   
+   
+    
+    
+    
+    
+    
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+
    PortUseRequired?Notes
    27017DatabaseYes
    7777ControlYes
    9001Rate LimitingYesRequired if rate limiting is used
    8721Webtask Logging/ControlYesRequired for logging and debugging
    8701Webtask Logging/ControlYesRequired for logging and debugging
    9200, 9300-9400Elastic SearchYesRequired for Elastic Search
    3000Grafana instrumentationNoRequired if you are using Grafana instrumentation
    22MaintenanceNoEnables maintenance tasks to be done between nodes
    ICMPHealthcheckNoAllows healthchecks between nodes
    
+
+## External Connectivity
+
+Auth0 strives to keep these IP addresses stable, though this is not a given. From time to time, Auth0 may add IP addresses or additional servers. During updates and metrics, you must allow your PSaaS Appliance instances to connect to these addresses.
+
+
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+
    UseDirectionIP/DNSPortNotesRequired?
    AllInboundYour load balancer IP address (often on internal network)80/(443 or 4443)For clusters with more than one node, a load balancer is required for resiliency and performanceYes
    WebtaskOutboundYour load balancer IP address (often on internal network)443Allows rules, webtasks, and extensions to call back to Auth0 endpointsYes
    Command Line InterfaceInbound and OutboundCLI Applications (often on the internal network)10121Allows use of the PSaaS Appliance Command Line InterfaceNo
    UpdatesOutboundapt-mirror.it.auth0.com (52.8.153.197)443Provides update packages for PSaaS Appliance instancesYes
    UpdatesOutbounddocker.it.auth0.com (52.9.124.234)443Provides updates for PSaaS Appliance Docker PackagesYes
    Web extensions, Hooks, and Management DashboardOutboundcdn.auth0.com443Required to run web extensions and Hooks; also required for admins to browse to the Management DashboardYes
    ExamplesOutboundgithub.com443Source to download and repackage example applicationsNo
    Usage & TelemetryOutboundapp-gateway.it.auth0.com (52.40.103.203)443Provides usage and telemetry statisticsYes
    MaintenanceInboundJump Host22Allows access to PSaaS Appliance instances for support purposesNo
    Healthcheck  InboundMonitoring Endpoint9110Allows access to Healthcheck endpointsNo
    DNSInbound and OutboundLocal domain servers53Required by the PSaaS Appliance to resolve host names internal and external to your environmentYes
    SMTPOutboundSMTP Server(s)25/587Allows sending of emails from the ApplianceNo
    
+
+## Notes
+
+* If you are using social providers for logins, the cluster must be able to connect to the social providers' endpoints.
+* The Jump Host IP is stable and provided at the time of setup.
diff --git a/ja-jp/articles/appliance/infrastructure/network.md b/ja-jp/articles/appliance/infrastructure/network.md
new file mode 100644
index 0000000000..d197ad2191
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/network.md
@@ -0,0 +1,98 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about Networks
+topics:
+    - appliance
+    - infrastructure
+    - networks
+contentType: reference
+useCase: appliance
+applianceId: appliance39
+sitemap: false
+---
+
+# PSaaS Appliance Infrastructure Requirements: Network
+
+This document details the requirements for the network on which the PSaaS Appliance runs.
+
+::: note
+Auth0 PSaaS Appliance can only be deployed in 1 NIC.
+:::
+
+In on-premise environment, all virtual machines should be in the same LAN in order for database replication to work properly. No other PSaaS Appliance cluster (Dev/Test) should be running on this subnet.
+
+In AWS Cloud environment, Auth0 supports and recommends cross-LAN availability zones.
+
+## IP Addresses
+
+Each PSaaS Appliance virtual machine (VM) must have its own private static IP address and outbound access. This can be accomplished through:
+
+* a public IP address;
+* NAT or transparent proxy.
+
+For **multi-node** clusters, all virtual machines must be:
+* on the same segment of the internal network;
+* able to communicate between each other via ports `7777`, `27017`, `8721`, and `8701`.
+* able to reach the load balancer via port `443`.
+
+::: note
+  Production and non-Production (test/development) must be on completely isolated networks.
+:::
+
+For a full list of IP addresses, domains, and ports used by the PSaaS Appliance clusters, as well as what they are used for, please see [Appliance Infrastructure: IP/Domain and Port List](/appliance/infrastructure/ip-domain-port-list).
+
+
+## Internet Connectivity
+
+Each PSaaS Appliance VM needs connectivity to the Internet. At a minimum, the VM needs access during Appliance configuration, maintenance windows, and troubleshooting. For implementations requiring integration with social providers and/or third-party API calls, the VM will need Internet access at all times.
+
+Since the PSaaS Appliance is delivered as a subscription-based managed service, Auth0 will need access to specified endpoints to provide proactive monitoring.
+
+Your server also needs to be able to access **cdn.auth0.com** if you run web extensions. The browsers used by your admins will also need to access the CDN if they navigate to the Management Dashboard.
+
+## DNS Records
+
+DNS records are required for all PSaaS Appliance instances (development/test *and* production). A standard single-node or cluster deployment requires four DNS entries for the following:
+
+* **Management Dashboard**: the Management Dashboard is the web interface that acts as an application for the configuration and application tenants on the PSaaS Appliance;
+* **Root Tenant Authority**: the tenant on the PSaaS Appliance that controls PSaaS Appliance settings, configuration, and local Dashboard Admin users;
+* **webtask**: webtask DNS is used for web extensions and to use Webtasks externally;
+* **App Tenant**: the tenant on the PSaaS Appliance created for your apps. It manages settings for your apps, user profiles, rules, and so on. This is the tenant you will interact with primarily through the Management Dashboard and the API.
+
+Each additional DNS zone requires an additional certificate. Please refer to the [DNS page](/appliance/infrastructure/dns) for specific requirements.
+
+## Load Balancers (for Multi-Node Clusters only)
+
+You must include a round-robin load balancer in your infrastructure when implementing a multi-node cluster PSaaS Appliance with high-availability.
+
+We recommend a layer 7/application layer load balancer that supports:
+
+* HTTP health monitoring. The [testall](/appliance/monitoring/testall) endpoint is an unauthenticated endpoint that will be used for monitoring by load balancers;
+* Awareness of websockets (this is required if using the Auth0 AD/LDAP Connector);
+* TCP/IP:
+    * If your deployment requires geo-location data for users authenticating with Auth0, support for `proxy_protocols` (which append the remote UP address when opening a connection to the backend) will be exposed to the nodes. If `proxy_protocols` is not supported, the IP address information captured for individual logins will always appear as the Load Balancer IP address;
+* HTTPS:
+    * If your deployment requires geo-location data for users authenticating with Auth0, you must support SSL offloading (or HTTP/1.1 with UPGRADE if you require websockets). It should support both the "Connection: Upgrade" and the "X-Forwarded-For" header. These are required to capture accurate IP address information.
+
+::: note
+  For AWS deployments, you must use TCP/IP.
+:::
+
+### Software Load Balancers
+
+You may use NGINX or HA Proxy as a software load balancer in front of the PSaaS Appliance. The reverse proxy must be configured with:
+
+* TCP mode with Proxy Protocol or HTTPS mode (SSL offloading)
+* the incoming hostname forwarded to the PSaaS Appliance nodes
+
+::: note
+  The Auth0 AD/LDAP Connector does not work in HTTPS mode.
+:::
+
+In addition to load balancing, you may use this for **IP address whitelisting** and **endpoint filtering** (only authentication endpoints are publicly available).
+
+#### SSL Offloading
+
+The PSaaS Appliance supports the use of SSL offloading at the load balancer if your IT standards require the use of HTTP within the local network. The load balancer must add a `X-Forwarded-Proto` header with the value `https`.
+
+Please note that the use of SSL offloading is not required to achieve high throughput.
diff --git a/ja-jp/articles/appliance/infrastructure/security.md b/ja-jp/articles/appliance/infrastructure/security.md
new file mode 100644
index 0000000000..adc6c39577
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/security.md
@@ -0,0 +1,99 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about security
+topics:
+    - appliance
+    - infrastructure
+    - security
+contentType: reference
+useCase: appliance
+applianceId: appliance40
+sitemap: false
+---
+
+# PSaaS Appliance Infrastructure Requirements: Security and Access
+
+ This document details the security and access requirements for your PSaaS Appliance instances.
+
+ ## SSL Certificates
+
+When using the PSaaS Appliance, you will need to provide several SSL certificates. You must create and install a unique SSL certificate for:
+
+* Each PSaaS Appliance (e.g., your production cluster, your development node, your QA environment)
+* [Extensions](/appliance/extensions)
+* [Custom Domains](/appliance/custom-domains)
+* [Webtasks](/appliance/webtasks) (with or without [Dedicated Domains](/appliance/webtasks/dedicated-domains))
+
+ ::: note
+   If you are unsure of where to get SSL Certificates, please contact your network security team. They are usually the ones familiar with the required processes and working with the appropriate certificate authorities (CA) to generate new certificates.
+ :::
+
+The SSL Certificate:
+
+* must be created by a public certificate authority. They cannot be self-signed;
+* can be a wildcard *or* a multi-domain (SAN) certificate;
+* must contain all required DNS/domain names, including those for the:
+    * Management Dashboard;
+    * Configuration Tenant;
+    * webtask;
+    * App Tenant(s) (current *and* future) specific to that particular PSaaS Appliance instance.
+
+Auth0 accepts the following certificate format:
+
+* PFX/PKCS12
+
+If you are using CER / PEM format, you should [convert to PFX format](http://stackoverflow.com/questions/2957742/how-to-convert-pkcs8-formatted-pem-private-key-to-the-traditional-format).
+
+::: note
+  The PFX certificate must contain the full chain (all intermediate certificates must be included in the public key).
+:::
+
+```text
+-----BEGIN CERTIFICATE-----
+MY-PUBLIC-KEY
+-----END CERTIFICATE-----
+-----BEGIN CERTIFICATE-----
+PARENT
+-----END CERTIFICATE-----
+```
+
+If you're uploading the public and private keys separately, convert the private key to RSA as follows:
+
+```text
+-----BEGIN RSA PRIVATE KEY-----
+PRIVATE-KEY
+-----END RSA PRIVATE KEY-----
+```
+
+## Transparent Proxies
+
+If you are behind a transparent proxy, you will need to:
+
+* obtain certificate(s) for your proxy created by a public certificate authority.
+* add an exception so that the PSaaS Appliance instance(s) may get through the proxy unauthenticated.
+
+## HTTPS or TLS
+
+Users must connect to the PSaaS Appliance using secure protocols (HTTPS or TLS). Depending on your network design, you could terminate the Secure Channel at the load balancer or the PSaaS Appliance. In both cases, your SSL/TLS certificate must be locally installed on the PSaaS Appliance.
+
+## SMTP
+
+You must configure an SMTP server for the PSaaS Appliance to send emails. The PSaaS Appliance requires an authentication SMTP server that has been configured with SMTP PLAIN authentication.
+
+**AWS SES Users**: If your domain is not validated, you will not be able to send email with AWS SES.
+
+Optionally, you may use a Transactional Email Provider (such as SendGrid, Amazon SES, Mandrill).
+
+The PSaaS Appliance supports STARTTLS, but it is not required.
+
+## Auth0 Remote Access
+
+Auth0 requires [remote access](/appliance/remote-access-options) to your PSaaS Appliance instances to perform updates, maintenance, or troubleshooting.
+
+### Initial Configuration
+
+Auth0's remote access method for initial configuration requires SSH access via Jumphost. After the initial setup, please feel free to disable this connection. 
+
+### Updates, Maintenance, and Troubleshooting
+
+Typically, updates are performed via the Auth0 Dashboard. If Auth0 needs to remote in to identify and troubleshoot issues, an Auth0 Customer Success Engineer will need access to the PSaaS Appliance through SSH access via Jumphost. This connection can be enabled for and disabled after the agreed-upon time frames for work.
diff --git a/ja-jp/articles/appliance/infrastructure/virtual-machines.md b/ja-jp/articles/appliance/infrastructure/virtual-machines.md
new file mode 100644
index 0000000000..45851327f6
--- /dev/null
+++ b/ja-jp/articles/appliance/infrastructure/virtual-machines.md
@@ -0,0 +1,48 @@
+---
+section: appliance
+description: PSaaS Appliance infrastructure information about virtual machines
+topics:
+    - appliance
+    - infrastructure
+    - virtual-machines
+contentType: reference
+useCase: appliance
+applianceId: appliance41
+sitemap: false
+---
+
+# PSaaS Appliance Infrastructure Requirements: Virtual Machines
+
+You may deploy the PSaaS Appliance on your premises using your own infrastructure or the infrastructure of a cloud provider. Currently, Auth0 supports PSaaS Appliance usage on Amazon Web Services (AWS).
+
+## Virtual Machine Templates
+
+Auth0 provides the PSaaS Appliance via a Virtual Machine Template for you to provision on to your infrastructure. The template differs depending on the platform you are using for virtualization. For example, if you are using AWS, Auth0 will provide you with an [Amazon Machine Image](http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/AMIs.html) (AMI) or a [CloudFormation](https://aws.amazon.com/cloudformation/aws-cloudformation-templates/) template.
+
+## Virtual Machine Infrastructure Requirements
+
+When provisioning the PSaaS Appliance from the templates, Auth0 recommends the following specifications for the Virtual Machine infrastructure. For multi-node clusters, each node requires a separate VM that meet the specifications.
+
+* **Memory**: 32 GB RAM (minimum);
+* **CPU**: 8 vCPU (minimum);
+* **Storage**:
+    * *For Non-Production Nodes*: 4 drives: 60 GB for system/operating system storage, 50 GB for data storage, 50 GB for User Search, and 50 GB for backup purposes (if you want to test the backup process).
+    * *For three-node, high availability Production clusters*:
+        * Two of the virtual machines with 3 drives: 60 GB for system/operating system storage, 100 GB for data storage, and 100 GB for User Search;
+        * One virtual machine with 4 drives: 60 GB for system/operating system storage, 100 GB for data storage, 100 GB for User Search, and 100 GB for backup purposes.
+        * If you anticipate more than 10 million users, please let us know for additional storage requirements and considerations.
+        * Drives should be thick provisioned.
+
+::: note
+  Large installations will require higher IO performance. Auth0 will work with you to determine the required storage performance levels.
+:::
+
+For multi-node clusters, Auth0 recommends deploying the PSaaS Appliance virtual machines across more than one physical host server/blade.
+
+## For AWS Users
+
+* The *recommended* [instance type](https://aws.amazon.com/ec2/instance-types/) is **m5.2xlarge** (minimum).
+* Auth0 will need the following pieces of information to share the AMI with you:
+    * AWS account number;
+    * AWS region name. The region should have at least three [availability zones](https://aws.amazon.com/about-aws/global-infrastructure) for your Production cluster.
+* If your production and development/test environments are within separate AWS accounts/regions, Auth0 will require the account number for both environments.
diff --git a/ja-jp/articles/appliance/instrumentation.md b/ja-jp/articles/appliance/instrumentation.md
new file mode 100644
index 0000000000..1aea21eb0a
--- /dev/null
+++ b/ja-jp/articles/appliance/instrumentation.md
@@ -0,0 +1,61 @@
+---
+section: appliance
+description: This document covers why and how to enable instrumentation in the PSaaS Appliance.
+topics:
+    - appliance
+    - instrumentation
+contentType: 
+    - how-to
+useCase: appliance
+applianceId: appliance45
+sitemap: false
+---
+# PSaaS Appliance Monitoring: Instrumentation
+
+The PSaaS Appliance allows you to collect time series data about individual processes and the overall cluster.
+
+To collect and analyze time series data, you must:
+
+* Have instrumentation enabled (please contact Auth0 for assistance with this)
+* Export the data collected to DataDog
+
+If you've chosen to host the PSaaS Appliance in your on-premise data center or in a cloud data center to which you've subscribed (e.g. AWS or Azure), you must use the instrumentation feature to monitor your PSaaS Appliance.
+
+If Auth0 hosts the PSaaS Appliance on your behalf, you do not have access to this feature – Auth0's Managed Service Engineering (MSE) team will use instrumentation to monitor the PSaaS Appliance for you.
+
+## Alerts
+
+The PSaaS Appliance does not come with any built-in tool for sending alerts. To remedy this, we rely on DataDog and Telegraf to help implement robust monitoring and alerting strategies for the PSaaS Appliance.
+
+### Signals to Monitor
+
+These are the signals that the PSaaS Appliance makes available to DataDog via the Telegraf agent. The Telegraf agent defines these signals automatically.
+
+* [CPU](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/CPU_README.md)
+* [Disk](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/DISK_README.md)
+* [Disk IO](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/DISK_README.md)
+* [Memory](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/MEM_README.md)
+* [Processes](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/PROCESSES_README.md)
+* [Swap](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/MEM_README.md)
+* [System](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/SYSTEM_README.md)
+* [MongoDB](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/mongodb/README.md)
+* [Net](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/system/net.go)
+* [NGINX](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/nginx/README.md)
+* [RabbitMQ](https://github.com/influxdata/telegraf/tree/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/rabbitmq)
+* [Procstat](https://github.com/influxdata/telegraf/blob/34b7a4c3611d1ede908ef275401544c34a4a3ba3/plugins/inputs/procstat/README.md)
+* [X509](https://github.com/influxdata/telegraf/blob/release-1.11/plugins/inputs/x509_cert/README.md)
+
+### Auth0 Signals to Monitor
+
+Please note that Auth0 exposes many internal metrics that will be visible in your DataDog console. The names of these metrics typically begin with `auth0_`.
+
+The internal metrics may change at any point, so in most cases, we do not recommend that you build monitoring strategies based on these signals (you can safely ignore these metrics, if you'd like). However, there are a few that you **should** monitor. We list the exceptions in the table below.
+
+| Signal | Description |
+| - | - |
+| auth0_http_requests_received | The total number of requests received by the PSaaS Appliance. |
+| auth0_http_requests_replied | The total number of requests replied to by the PSaaS Appliance. |
+| auth0_http_response_time.count | The number of responses issued by the PSaaS Appliance. This metric corresponds to `auth0_http_requests_replied`. |
+| auth0_http_response_time.lower | The shortest amount of time it took for the PSaaS Appliance to respond to a request. |
+| auth0_http_response_time.mean | The average time it took for the PSaaS Appliance to respond to a request. |
+| auth0_http_response_time.upper | The longest amount of time it took for the PSaaS Appliance to respond to a request. |
diff --git a/ja-jp/articles/appliance/modules.md b/ja-jp/articles/appliance/modules.md
new file mode 100644
index 0000000000..494289c92f
--- /dev/null
+++ b/ja-jp/articles/appliance/modules.md
@@ -0,0 +1,49 @@
+---
+section: appliance
+description: For security reasons, rules and custom database connections for PSaaS Appliance run in a JavaScript sandbox. You can use the full power of the ECMAScript 5 language and a few selected libraries.
+topics:
+    - appliance
+    - js-modules
+    - sandbox
+contentType: reference
+useCase: appliance
+applianceId: appliance60
+sitemap: false
+---
+
+# Node.js Modules Available in Rules and Custom Database Connections
+
+For security reasons, you must execute rules and custom database logic for PSaaS Appliance using [the Webtask stage/sandbox](/appliance/webtasks). The sandbox offers you a performant environment running ECMAScript 6 and provides isolation for the code you've written.
+
+The current sandbox supports:
+
+| Module | Version (If Applicable) | Notes |
+| - | - | - |
+| [async](https://github.com/caolan/async) | ~2.1.2 |  |
+| [auth0](https://github.com/auth0/node-auth0) | 2.13.0 | 2.13.0 |
+| [bcrypt](https://github.com/ncb000gt/node.bcrypt.js) | ~3.0.0 |  |
+| [Buffer](http://nodejs.org/docs/v0.10.24/api/buffer.html) |  |  |
+| [cql](https://github.com/jorgebay/node-cassandra-cql) |  ~0.4.4 |  |
+| [crypto](http://nodejs.org/docs/v0.10.24/api/crypto.html) |  |  |
+| [ip](https://github.com/keverw/range_check) | 0.3.2 |  |
+| [jsonwebtoken](https://github.com/auth0/node-jsonwebtoken) | ~7.1.9 |  |
+| [knex](http://knexjs.org) | ~0.8.6 | The function returned by `require('knex')` is available as `Knex`. |
+| [lodash](https://github.com/lodash/lodash) | ~4.17.10 |  |
+| [node-mongodb-native](https://github.com/mongodb/node-mongodb-native) | ~2.0.33 |  |
+| [node-mongodb-native - BSON](http://mongodb.github.io/node-mongodb-native/api-bson-generated/bson.html) | 0.3.2 |  |
+| [node-mongodb-native - Double](http://mongodb.github.io/node-mongodb-native/api-bson-generated/double.html) |  |  |
+| [node-mongodb-native - Long](http://mongodb.github.io/node-mongodb-native/api-bson-generated/long.html) |  |  |
+| [node-mongodb-native - ObjectID](http://mongodb.github.io/node-mongodb-native/api-bson-generated/objectid.html) |  |  |
+| [node-mongodb-native - Timestamp](http://mongodb.github.io/node-mongodb-native/api-bson-generated/timestamp.html) |  |  |
+| [mysql](https://github.com/felixge/node-mysql) | ~2.15.0 |  |
+| [pbkdf2](https://github.com/davidmurdoch/easy-pbkdf2) | 0.0.2 |  |
+| [pg](https://github.com/brianc/node-postgres) | 6.1.2 |  |
+| [pubnub](https://github.com/pubnub) | 3.7.11 |  |
+| [q](https://github.com/kriskowal/q) | ~1.4.1 |  |
+| [querystring](http://nodejs.org/api/querystring.html) | 0.2.0 |  |
+| [request](https://github.com/mikeal/request) | ~2.81.0 |  |
+| [uuid](https://github.com/kelektiv/node-uuid) | ~3.3.2 |  |
+| [xml2js](https://github.com/Leonidas-from-XIV/node-xml2js) | ~0.11.2 |  |
+| [xmldom](https://github.com/jindw/xmldom) | ~0.1.13 |  |
+| [xpath](https://github.com/goto100/xpath) | 0.0.9 |  |
+| [xtend](https://github.com/Raynos/xtend) | ~4.0.0 |  |
diff --git a/ja-jp/articles/appliance/monitoring/authenticated-endpoints.md b/ja-jp/articles/appliance/monitoring/authenticated-endpoints.md
new file mode 100644
index 0000000000..50fa8bc069
--- /dev/null
+++ b/ja-jp/articles/appliance/monitoring/authenticated-endpoints.md
@@ -0,0 +1,171 @@
+---
+section: appliance
+description: Overview of using the authenticated endpoint with the PSaaS Appliance
+topics:
+    - appliance
+    - monitoring
+    - testing
+contentType: how-to
+useCase: appliance
+applianceId: appliance47
+sitemap: false
+---
+
+# PSaaS Appliance: Authenticated Testing Endpoints
+
+Auth0 offers endpoints that allow you to check the system health of a specific resource. In this article, we will cover the authenticated endpoints, which are available to those who submit requests whose header contains the appropriate credentials.
+
+The authenticated endpoints are similar to the Test All endpoints in that both return positive or negative status information about system resources.
+
+Authenticated endpoints do not provide detailed information about the system's resource utilization. Instead, they return an HTTP status reflecting the status of a given resource. Using the third-party tools of your choice, you can set up alerts that activate based on the status codes returned by Auth0's endpoints.
+
+## How to generate an API key
+
+To send requests to the authenticated endpoints, you will need to generate and include an API key in the header of your request.
+
+Begin by navigating to the [Settings](/appliance/dashboard/settings) page of your PSaaS Appliance Dashboard. Scroll down to the [API Keys section](/appliance/dashboard/settings#api-keys).
+
+If this is the first time you are doing this, you'll see that there is no key. You can generate your first key by clicking the **Generate** button to the right.
+
+![](/media/articles/appliance/api-keys/no-key.png)
+
+You will be prompted to confirm the new key generation.
+
+Once confirmed, you will see that the key now populates the previously-blank field.
+
+![](/media/articles/appliance/api-keys/key.png)
+
+Scroll to the bottom of the page, and click Save to apply the new API Key value.
+
+At this point, Auth0 does a reconfiguration and restarts the health service. Once this process completes, you will be able to use your new API key.
+
+:::panel-warning Changing Your API Key
+You may only use one API key at a time. If you generate a new key, be sure to provide the new key to your existing applications and services; otherwise, they will fail.
+:::
+
+## Authenticated API Endpoints
+
+The API exposes a number of endpoints that you can use to test the status of the service.
+
+**Each node comes with its own set of endpoints, so you will need to make multiple calls if you are monitoring a multi-node PSaaS Appliance implementation.** The exception is the `GET /status/replicaset` endpoint, which reports on multiple nodes.
+
+There are two ways you can call a specific API endpoint:
+
+* Submit your request to the node directly
+* Issue your request through the load balancer using the manage domain
+
+If you're checking the status of a specific node, it's best to submit your request to the node directly:
+
+```text
+curl -v https://{node-ip}/health/status/cpu --user api_keys_health:YOUR_API_KEY
+```
+
+Otherwise, you can issue your request through the load balancer using the **manage** domain:
+
+```text
+curl -v https://{manage-dashboard-domain}/health/status/cpu --user api_keys_health:YOUR_API_KEY
+```
+
+### Response Codes
+
+Each endpoint will return one of three status codes to communicate the status of the resource in question:
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | OK |
+| 429 | Too many requests |
+| 520 | Warning |
+
+Additionally, each status code conveys additional information depending on the endpoint being queried. You'll find more information on this in the following sections that cover the specific endpoints available to you.
+
+None of the responses will include a body.
+
+#### GET /status/cpu
+
+This endpoint returns information about the overall available CPU capacity in the last minute on the PSaaS Appliance. Overall CPU capacity means that all CPU time is aggregated and compared with the time that any core was not idle. For example, if a four-core PSaaS Appliance node had two cores completely utilized and two cores completely idle, the CPU capacity calculated will be 50%.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The system had more than 20% of the total CPU capacity available in the last minute. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The system had 20% of the total CPU capacity (or less) available in the last minute. |
+
+#### GET /status/memory
+
+This endpoint returns information on the amount of memory available on the PSaaS Appliance.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The system has more than 10% of its memory available. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The system has 10% (or less) of its memory available. |
+
+#### GET /status/disk
+
+This endpoint returns information on disk utilization. Each node has a set number of volumes; if there is at least one volume that's utilizing more than 90% of the allocated disk space, the endpoint returns a warning.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | No volume on the node exceeds 90% utilization. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | One or more disk(s) on the node has exceeded 90% utilization. |
+
+#### GET /status/services
+
+This endpoint checks to see if any of the node's core Auth0 services are down.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | Every core service is running on the node. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | At least one of the core services on the node is not running. |
+
+#### GET /status/network
+
+This endpoint reports the status of the network for the node. The node issues a PING command to each node in the cluster, and if it fails to PING any node, the endpoint will return an error code.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The node was able to successfully ping every other node in the cluster. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The node was not able to ping at least one node in the cluster, indicating there's a network problem. |
+
+#### GET /status/internet
+
+This endpoint tests outbound internet connectivity on the node over port 443. This endpoint issues a `HEAD` request to `https://apt-mirror.it.auth0.com`. If the request returns anything other than a 200 status code, this endpoint will return an HTTP code indicating failure.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The node was able to successful issue a `HEAD` request to `https://apt-mirror.it.auth0.com`. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The was unable to issue a `HEAD` request, or the node received an error message after sending a `HEAD` request to `https://apt-mirror.it.auth0.com`. |
+
+#### GET /status/email
+
+This endpoint tests the SMTP connection using the provided configuration settings.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The node was able to use the provided configuration settings to connect to the SMTP server. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The node was unable to connect to the SMTP server. |
+
+#### GET /status/db
+
+This endpoint checks to see if the node can run database queries and receive the results.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | The node was able to successfully query the database. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | The node was not able to connect and run a query against the database. |
+
+#### GET /status/replicaset
+
+This endpoint checks to see if the replica set is healthy. If there is at least one node that is down, the endpoint will return an HTTP code indicating failure.
+
+| Response Code | Response |
+| ------------- | -------- |
+| 204 | All nodes in the replica set are up. |
+| 429 | The status endpoint has been called too many times (limit: 10 requests per second). Please wait and try again. |
+| 520 | At least one node in the replica set is down. |
diff --git a/ja-jp/articles/appliance/monitoring/index.md b/ja-jp/articles/appliance/monitoring/index.md
new file mode 100644
index 0000000000..a7f8f588d9
--- /dev/null
+++ b/ja-jp/articles/appliance/monitoring/index.md
@@ -0,0 +1,77 @@
+---
+url: /appliance/monitoring
+section: appliance
+description: Ways to monitor the PSaaS Appliance
+topics:
+    - appliance
+    - monitoring
+contentType:
+- index
+- concept
+useCase: appliance
+applianceId: appliance48
+sitemap: false
+---
+
+# Monitoring the Private SaaS (PSaaS) Appliance
+
+The PSaaS Appliance is a managed service, which means that Auth0 is responsible for:
+
+* Installation
+* Updates
+* General maintenance tasks
+
+However, the deployment option you choose affects the scope of what Auth0 can do when it comes to *monitoring* the PSaaS Appliance. Currently, Auth0 supports the following deployment options:
+
+* The subscriber's Amazon Web Services cloud environment
+* An Auth0-controlled data center
+
+If you choose to deploy the PSaaS Appliance to an Auth0-controlled data center, we have control over every aspect involved (DNS, certificates, infrastructure, Auth0 software stack). This level of control allows us to assist you in monitoring the health of the PSaaS Appliance and acting to prevent or remediate issues.
+
+However, if you choose to deploy the PSaaS Appliance to AWS, **you are responsible for monitoring the deployment. Auth0 is unable to monitor such environments.**
+
+::: note
+Please review [PSaaS Appliance: Roles and Responsibilities](https://auth0.com/docs/appliance/raci) for information on who is responsible for various activities related to managing and monitoring the PSaaS Appliance.
+:::
+
+## Features Aiding Monitoring
+
+The PSaaS Appliance offers a number of tools to help you monitor the software that is running, as well as the infrastructure on which it runs. You can find additional information on these monitoring tools in the chart that follows:
+
+| Tool | Description |
+| - | - |
+| Service Status Check | The [`/testall` endpoint](/appliance/monitoring/testall) reports the overall status of core Auth0 services. You can call this endpoint from the load balancer or from an individual node. If called from the load balancer, you can determine if there's a system-wide service outage. If called from a specific node, you'll receive information on the status of core services running on that node alone. |
+| System Health Checks | The [authenticated endpoints](/appliance/monitoring/authenticated-endpoints) provide a more granular health check than the `/testall` endpoint, allowing you to see the status of lower level system resources. With these endpoints, you can monitor the status of the PSaaS Appliance as it relates to memory, disk, network, internet, email, database, replica set, services, and the cluster. 
     
     The authenticated endpoints return status codes indicating whether the system resource in question is healthy or not. |
+| [Instrumentation](/appliance/instrumentation) | The PSaaS Appliance offers instrumentation data, which is a vital component of monitoring and detecting anomalies or problems *before* they occur. To review your PSaaS Appliance instrumentation data, you can send it to DataDog. With DataDog,  you can set up robust monitoring and alerts strategies to review the health of your PSaaS Appliance. |
+| Dashboards | The PSaaS Appliance's [Troubleshooting](/appliance/dashboard/troubleshoot) dashboard allows you to view [Health Check](/appliance/dashboard/troubleshoot#health-check) results for the past 29 days. Please note that this dashboard does not provide any alerts functionality and should not be used as your only monitoring strategy. |
+| Audit and Tenant Events | The [Tenant Logs](https://auth0.com/docs/logs) track processed transactions and provide an overview of application activity in your tenant. |
+| Synthetic Transactions | You can use any third-party service that supports synthetic transaction to monitor PSaaS Appliance service availability. |
+
+## Recommended Monitoring Strategy
+
+Because each subscriber's implementation is different, the monitoring strategy you employ should match the needs of your use case.
+
+With that said, Auth0 suggests the following as a starting point for monitoring the PSaaS Appliance. The signals mentioned are indicators that there might be an unhealthy scenario occurring and provide information on the appropriate action for you to take:
+
+| Signal | Trigger | Action |
+| - | - | - |
+| [/testall at load balancer level](/appliance/monitoring/testall) | Does not return 200 with body OK | [Submit a support ticket](/support/tickets) with a severity of **Urgent** |
+| [/testall at node level](/appliance/monitoring/testall#monitoring-individual-nodes) | Does not return 200 with body OK | [Submit a support ticket](/support/tickets) with a severity of **High** |
+| [GET /status/memory](/appliance/monitoring/authenticated-endpoints#get-status-memory) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/disk](/appliance/monitoring/authenticated-endpoints#get-status-disk) at node level  | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/network](/appliance/monitoring/authenticated-endpoints#get-status-network) at node level	| Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/internet](/appliance/monitoring/authenticated-endpoints#get-status-internet) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/email](/appliance/monitoring/authenticated-endpoints#get-status-email) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/db](/appliance/monitoring/authenticated-endpoints#get-status-db) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| [GET /status/replicaset](/appliance/monitoring/authenticated-endpoints#get-status-replicaset) at node level | Returns a 520 status code | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+| Synthetic Transaction: Login | Synthetic login failed | [Submit a support ticket](/support/tickets) with a severity of **Normal** |
+
+When building your monitoring strategy for a PSaaS Appliance implementation hosted on an environment you own or control, remember that you are responsible for using the instrumentation and tenant log data to watch for anomalies.
+
+## Your Responsibilities in Monitoring the Auth0-Hosted PSaaS Appliance
+
+If Auth0 hosts your PSaaS Appliance, you won't have access to instrumentation data. However, you are still expected to monitor your tenant logs for anomalies, since this provides you information on the health of your PSaaS Appliance-dependent applications.
+
+If Auth0 hosts your PSaaS Appliance implementation, Auth0's Managed Service Engineering (MSE) team is responsible for monitoring. However, the MSE team is focused on the health of the PSaaS Appliance – you are responsible for tracking the health of your applications, as well as its usage of Auth0.
+
+If you provide Auth0 with the appropriate email addresses, Auth0 can send a daily uptime report of your hosted PSaaS Appliance service to those email addresses. You can also specify one or more email addresses to which Auth0 will send alerts in the event that there is an issue.
diff --git a/ja-jp/articles/appliance/monitoring/testall.md b/ja-jp/articles/appliance/monitoring/testall.md
new file mode 100644
index 0000000000..442f42ee39
--- /dev/null
+++ b/ja-jp/articles/appliance/monitoring/testall.md
@@ -0,0 +1,48 @@
+---
+section: appliance
+description: Overview of using the testall endpoint with the PSaaS Appliance
+topics:
+    - appliance
+    - monitoring
+    - testing
+contentType: how-to
+useCase: appliance
+applianceId: appliance49
+sitemap: false
+---
+
+# Using the `testall` Endpoint
+
+The `testall` endpoint can be accessed via http or https:
+
+```text
+GET https://{your_auth0_server}/testall
+```
+
+The `/testall` endpoint checks the availability of the core Auth0 Authentication Service, as well as other services such as the Management Dashboard and Documentation pages. If all is well, the endpoint returns a response code of `200`.
+
+```text
+200
+content-type: text/plain
+OK
+```
+
+Alternatively, if there are any issues, `/testall` returns a `5xx` response code.
+
+## Monitoring Individual Nodes
+
+Typically, the above endpoint will reach the load balancer, but since a typical, highly-available deployment will have at least three nodes, Auth0 recommends monitoring those endpoints as well:
+
+* `http://{IP Address Node 1}/testall`
+* `http://{IP Address Node 2}/testall`
+* `http://{IP Address Node 3}/testall`
+
+Be sure to use the `http` *not* `https` in your URLs.
+
+### Non-Responsive Nodes
+
+The load balancer may remove nodes that are not responding or time out **without affecting service**, because all nodes of a cluster can serve requests from applications. All configuration information is continuously replicated across nodes.
+
+::: note
+  These endpoints are typically used by the Load Balancer to decide whether or not a node should be removed from the cluster. If a node stops responding, and the Load Balancer removes it, please contact [Auth0 Support](${env.DOMAIN_URL_SUPPORT}) for additional assistance.
+:::
diff --git a/ja-jp/articles/appliance/private-cloud-requirements.md b/ja-jp/articles/appliance/private-cloud-requirements.md
new file mode 100644
index 0000000000..58a4f080df
--- /dev/null
+++ b/ja-jp/articles/appliance/private-cloud-requirements.md
@@ -0,0 +1,130 @@
+---
+section: appliance
+description: This document details the requirements for the Auth0 Dedicated Cloud Service.
+toc: true
+topics:
+    - appliance
+    - private-cloud
+    - requirements
+contentType: reference
+useCase: appliance
+applianceId: appliance61
+sitemap: false
+---
+# Requirements for the Auth0 Dedicated Cloud Service
+
+If your subscription agreement includes a Private SaaS (PSaaS) Appliance that is hosted in a dedicated area of Auth0's cloud, Auth0 will set up the PSaaS Appliance on your behalf.
+
+## Support
+
+Auth0 will provide you with an account to access the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}), where you can obtain information about your Auth0 environment and open support tickets. This account will be linked to your PSaaS Appliance and current [Support](/support) plan.
+
+In general, the tenant name you'll use for support is formatted as follows: **customer_name**-support
+
+You will also be asked to provide a list of tenant admins. Note that tenant admins can invite other support users.
+
+## Preferred AWS Regions
+
+You'll be asked for your preferred AWS regions, such as `AWS US-WEST-2`, `AWS US-East-1`, `AWS EU-Central-1`, and so on. You'll need to select:
+
+* One region for your Development node
+* One region (with at least three [availability zones](https://aws.amazon.com/about-aws/global-infrastructure)) for your Production cluster
+
+## DNS Records
+
+::: warning
+Please finalize  DNS names prior to PSaaS Appliance deployment.
+:::
+
+Auth0 provides the domain names needed for your DNS zones/certificates. If you have Development and Production environments, your domain names will typically be formatted as follows:
+
+| Environment | Sample Domain Name          |
+| ----------- | --------------------------- |
+| Development | **company**-dev.auth0.com |
+| Production  | **company**.auth0.com     |
+
+You will also need names for the Management Dashboard, Webtask endpoints, Webtask dedicated domain, and App Tenant.
+
+|   | Description |
+| - | ----------- |
+| Management Dashboard | The Management Dashboard is your web application's management interface. You'll typically choose the name **manage**, but you can use something else if needed |
+| Webtask Endpoints | The Webtask DNS is used for web extensions and external use of Webtasks. You'll typically use the name **webtask**, but you can use something else if needed |
+| Webtask Dedicated Domain | Beginning with Appliance version 13451, Webtask may now be configured on a dedicated domain. This enables safely using extensions in multi-tenant environments in the same manner as the Auth0 Public Cloud Service. Auth0 will set up a DNS zone to host the name entries for each tenant. Auth0 recommends `*.wt..auth0.com`. |
+| App Tenant | The App Tenant is the initial tenant where your applications reside. The is the tenant your users will interact with primarily, and you'll manage this using the Management Dashboard and API.
+
+### Sample Domain Name Sets
+
+The following is a sample set of domain names for a typical Development and Production environment setup where the App Tenant's name is **identity**.
+
+**Development**
+
+* **manage**.mycompany-dev.auth0.com
+* **webtask**.mycompany-dev.auth0.com
+* *.wt.mycompany-dev.auth0.com
+* **identity**.mycompany-dev.auth0.com
+
+**Production**
+
+* **manage**.mycompany.auth0.com
+* **webtask**.mycompany.auth0.com
+* *.wt.mycompany.auth0.com
+* **identity**.mycompany.auth0.com
+
+### Domain Name Patterns
+
+Each domain name will end in `auth0.com`.
+
+The Management Dashboard, Webtask, and App Tenant(s) **must** be a part of the same parent domain (such as `yourdomain.auth0.com`).
+
+The hostname (such as **manage-project**.yourdomain.auth0.com) must be at least three characters long and must **not** contain any underscores(_).
+
+The word `login` is reserved and **cannot** be used. Please also refer to the [full list of reserved words](/appliance/infrastructure/dns#hostnames).
+
+The domain name you use for tenants hosted in the Dedicated Cloud Service **cannot** be the same as any you're using for tenants hosted in the Public Cloud Service. 
+
+**If you want to use your domain name in use on the Public Cloud Service in the Dedicated Cloud Service, we will need to delete your Public Cloud Service account.**
+
+## Administrator Email Addresses
+
+We will need the email addresses for the administrators of the **Manage** and **App** tenants in both the Development and Production environments
+
+### Group Email Address
+
+Auth0 will provide a daily uptime report of your PSaaS Appliance service, which is sent to an email address (with a group alias) specified by you.
+
+In the event that there is an issue, you can specify a group alias to receive alerts.
+
+### SMTP Settings
+
+::: note
+This information is not required until the required environments are ready. Auth0 will work with you to update your settings. See the [SMTP section](/appliance/infrastructure/security#smtp) of the PSaaS Appliance infrastructure manual.
+:::
+
+We will need the following SMTP-related values:
+
+* Host name
+* Port number
+* Username
+* Password
+
+## Custom Domain
+
+::: note
+A custom domain is optional, and Auth0 SLAs do **not** cover this portion of the PSaaS Appliance infrastructure.
+:::
+
+You can configure a single custom domain name for your app tenants' domains. 
+
+If you choose to use a custom domain, you'll need to manage the DNS name record, [SSL Certificate](/appliance/infrastructure/security#ssl-certificates), and add the appropriate DNS entry that alias the Auth0 identity.
+
+For example, you'll need to map `identity..auth0.com` to `identity..com`.
+
+::: warning
+Webtask does not support custom domains.
+:::
+
+### Keep Reading
+
+::: next-steps
+* [Custom Domains on the PSaaS Appliance](/appliance/custom-domains)
+:::
diff --git a/ja-jp/articles/appliance/raci.md b/ja-jp/articles/appliance/raci.md
new file mode 100644
index 0000000000..4d86c2fe93
--- /dev/null
+++ b/ja-jp/articles/appliance/raci.md
@@ -0,0 +1,64 @@
+---
+section: appliance
+description: This document details who is responsible for what aspects of a given PSaaS Appliance installation.
+topics:
+    - appliance
+    - raci
+contentType: reference
+useCase: appliance
+applianceId: appliance62
+sitemap: false
+---
+
+# PSaaS Appliance: Roles and Responsibilities
+
+The PSaaS Appliance is a managed service that is used if your organization's compliance and/or policy requirements prevent you from utilizing a multi-tenant cloud service. The PSaaS Appliance provides the packaging and services required to run the Auth0 code base in a third-party environment.
+
+## General Division of Responsibilities
+
+**Auth0** is responsible for:
+
+* Initial installation;
+* General maintenance;
+* Installation of patches/updates.
+
+The **subscriber** is responsible for supplying and monitoring the infrastructure on which the PSaaS Appliance runs. This includes, but is not limited to:
+
+* The Virtual Machine host;
+* Storage;
+* Network resources;
+* Required dependencies.
+
+## Detailed Division of Responsibilities
+
+The following RACI Matrix provides a more in-depth summary of the roles and responsibilities that will be allocated between Auth0 and the subscriber.
+
+### RACI
+
+* **Responsible**: the assigned party who is responsible for implementing the task as required;
+* **Accountable**: the assigned party who is accountable for the task being completed as required;
+* **Consulted**: the party (or parties) whose opinions are requested and with whom there is two-way communication;
+* **Informed**: the party (or parties) who are kept up-to-date with regards to progress and with whom there is one-way communication
+
+|PSaaS Appliance-Related Tasks or Deliverables|Auth0|Subscriber|Notes|
+|---|---|---|---|
+|Preparing VM Infrastructure, including: memory, storage, processors, load balances, networks, SSL certificates, DNS records, SMTP servers, enabling Auth0 access via Jumphost/VPN|C|R, A (subscriber's infrastructure engineer)|The subscriber will submit the PSaaS Appliance Infrastructure Checklist when the VMs are ready and the [infrastructure requirements](/appliance/infrastructure) are met.|
+|Deployment to Development and Production environments|R, A - Auth0 Managed Service Engineer (MSE)|I|The Auth0 Managed Service Engineer will SSH into the VMs and deploy the Appliance.|
+|Configuration of Development and Production environments|C|R|The Auth0 MSE will show the subscriber's infrastructure engineer [how to upload the SSL certificates, enter the SMTP credentials, and add administrators](/appliance/dashboard).|
+|Operations Handover|R|C|Auth0 Managed Service Engineers will provide a 90-minute Operations Handover meeting to review information regarding PSaaS Appliance monitoring, backup, and updates, as well as answer questions.|
+|Monitoring|I|R, A|The subscriber is responsible for [monitoring the PSaaS Appliance](/appliance/monitoring).|
+|Backing Up|I (in the event that there are issues)|R, A|The subscriber is responsible for [backing up the PSaaS Appliance](/appliance/disaster-recovery) using the [Command-Line Tools](/appliance/cli).|
+|Code Integration into Applications|C, I (in the event that there are issues)|R, A|The subscriber is responsible for Auth0 code integration.|
+|User Migration (if required)|C, I (in the event that there are issues)|R, A|The subscriber is responsible for migrating users where appropriate.|
+|Updates|R|R, A|Auth0 Managed Service Engineers will partner with the subscriber's infrastructure engineers to update the PSaaS Appliance on an agreed-upon basis. The subscriber is responsible for: taking VM snapshot(s) prior to the update, providing access to the PSaaS Appliance, being present as the PSaaS Appliance updates. Auth0 is responsible for: running manual scripts (if required), informing the subscriber on the status of the upgrade.|
+|Testing Updates|C, I (in the event that there are questions/issues)|R, A|The subscriber will test the PSaaS Appliance after the Development node has been updated and inform Auth0 about any issues.|
+|Issue Identification and Support Ticket Submission|C|R, A|The subscriber is responsible for submitting issues via the [Support Center](/onboarding/enterprise-support).|
+|Issue Resolution|R|C|Auth0 will provide support for issues within the *core* of the PSaaS Appliance. Auth0 will *consult* on issues pertaining to integration between Auth0 APIs and Dashboards.|
+
+### Keep Reading
+
+* [Overview](/appliance/appliance-overview )
+* [Infrastructure](/appliance/infrastructure)
+* [Disaster Recovery](/appliance/disaster-recovery)
+* [Enterprise Support](/onboarding/enterprise-support)
+* [Critical Support Issues Guidance](/appliance/critical-issue)
diff --git a/ja-jp/articles/appliance/remote-access-options.md b/ja-jp/articles/appliance/remote-access-options.md
new file mode 100644
index 0000000000..586fd59a1f
--- /dev/null
+++ b/ja-jp/articles/appliance/remote-access-options.md
@@ -0,0 +1,56 @@
+---
+title: PSaaS Appliance Remote Access Options
+description: Remote Access Options Available for those with PSaaS Appliance
+topics:
+    - appliance
+    - remote-access
+contentType: reference
+useCase: appliance
+applianceId: appliance63
+sitemap: false
+---
+# PSaaS Appliance Remote Access Options
+
+The Auth0 Private SaaS (Software as a Service) Appliance, or PSaaS Appliance, is an Auth0 deployment that exists in a dedicated area of Auth0's cloud, a cloud under your control, or your own data center. This article covers the remote options available to you if you opt for the PSaaS Appliance.
+
+## Customer Choices
+
+When the PSaaS Appliance is hosted in your cloud environment or datacenter, it requires regular access by our managed service engineering team to keep it up to date, fix problems, and optimize security and performance. There is a trade-off between maintaining strict isolation behind the customer’s firewall and the service level that we can offer. The options presented below offer the best balance between a high degree of isolation and support. Note that all options provide end-to-end SSH encryption of PSaaS Appliance management traffic and allow the customer to disable Auth0 access if needed.
+
+::: panel Jumphost
+A Jumphost is a security-hardened virtual machine with the ability to act as a secure communication relay through SSH to the Auth0 PSaaS Appliance VMs. Jumphost initiates the connection from a whitelisted IP address provided by Auth0. You would open/close access to Jumphost on demand in situations where we require access, such as maintenance or support events. These connections originate from a VPN-secured network using public key access to your Jumphost, so that only authorized Auth0 managed service engineers can access your environment from a secure connection within Auth0.
+:::
+
+### Option 1: Jumphost + Firewall Whitelist
+
+In this configuration, an external Auth0-managed Jumphost is permitted sole SSH management access to the PSaaS Appliance.
+
+![](/media/articles/appliance/remote-access/jumpshot-fw.png)
+
+*Pros*: 
+
+* Jumphost provides a single point of access and auditing
+* Audit, session recording, VPN access to Jumphost, and Identity Management done by Auth0
+* Access could be disabled via Firewall rules or Security Groups.
+
+### Option 2: Two Jumphosts
+
+Similar to option 1, this configuration permits an external Auth0 Jumphost to connect via firewall whitelist to an internal, customer-managed Jumphost. This second Jumphost then provides actual access to the PSaaS Appliance nodes.
+
+![](/media/articles/appliance/remote-access/jumpshot-fw-csjs.png)
+
+*Pros*: 
+
+* Jumphost provides a single point of access and auditing
+* Audit, session recording, VPN access to Jumphost, and Identity Management is done by Auth0
+* Disabling Auth0 access is as simple as shutting down a server
+* Could be installed in DMZ if needed
+
+*Cons*: 
+
+* Additional virtual Jumphost required in customer infrastructure
+
+
+### Unsupported Configurations
+
+We do not support other methods, such as VDI or Screen Sharing mechanisms. They introduce compliance concerns, including (but not limited to) Auth0’s inability to internally audit connections and SSH sessions, enforce identity management on Auth0 employee accounts, exposure to untrusted systems on customer’s end running non-standard software (from where the connections are generated to Auth0 VMs), and inability to verify the identity of participants on the other end.
diff --git a/ja-jp/articles/appliance/webtasks/dedicated-domains.md b/ja-jp/articles/appliance/webtasks/dedicated-domains.md
new file mode 100644
index 0000000000..11bbe60ff3
--- /dev/null
+++ b/ja-jp/articles/appliance/webtasks/dedicated-domains.md
@@ -0,0 +1,97 @@
+---
+section: appliance
+title: Configure Webtask with Dedicated Domains
+description: How to use dedicated domains with your PSaaS Appliance Webtask
+toc: true
+topics:
+    - appliance
+    - webtask
+    - domains
+contentType: 
+    - concept
+    - reference
+    - how-to
+useCase: appliance
+applianceId: appliance50
+sitemap: false
+---
+# PSaaS Appliance: Webtask with Dedicated Domains
+
+In order to use extensions, such as the [Authorization Extension](/extensions/authorization-extension/v2), you will need to configure Webtasks on a dedicated domain in PSaaS Appliance environments. This enables you to safely use extensions in multi-tenant environments (the behavior is akin to that of the Auth0 Public Cloud Service).
+
+::: note
+If you are planning on using [Extensions](/appliance/extensions), you must implement Webtask dedicated domains.
+:::
+
+## Background
+
+Auth0 Extensions provide extra functionality to the core Auth0 services (Auth0 Platform) using the Webtask extensibility platform. By running these extensions in Webtask, we ensure that the extensions do not impact the regular operations of the Auth0 tenant. 
+
+The PSaaS Appliance is a multi-tenant platform, which means that you can host and run multiple tenants in the same environment. Each of your tenants has full functionality of the Auth0 Platform, including use of the different extensions provided by Auth0.
+
+We found that extension developers needed what we call the **Full Trust mode** to improve the usability and functionality of the extensions they created. By enabling Full Trust mode, Webtask and extensions can create cookies and get increased control over the response sent to the browser.
+
+However, Full Trust mode raises security-related implications. More specifically, we want to ensure that enabling Full Trust mode did not overstep the boundaries established by individual tenants when it came to Webtask and extensions. As such, we ask that customers create a new root domain for Webtask that allows each tenant to have a dedicated domain.
+
+Essentially, this allows tenants to use extensions without providing access to cookies in the authentication domain.
+
+## Requirements
+
+For each environment (such as Development, Testing, or Production), you will need:
+
+* A certificate for your Webtask dedicated domain
+    * Dedicated and non-dedicated host names must be unique.
+* A DNS zone for each domain to manage the name records of your tenants
+
+### Sample Architecture
+
+To clarify the requirements, let's look at a sample setup.
+
+The following are applicable to your environment as it current exists:
+
+* Your Production environment is accessible via `example.com`
+* Your primary Auth0 tenant is `identity.example.com`
+* Your current certificate is `identity.example.com` (or similar)
+
+You plan to implement the following change:
+
+* You want a Webtask dedicated domain configured to be `wt.example.com`
+
+To implement your change, you'll need:
+
+* A DNS zone for `wt.example.com`
+* A certificate with the names of all your tenants *or* a wildcard certificate for `*.wt.example.com`
+
+Once complete, you'll be able to use the following for all containers under your primary tenant:
+
+```text
+identity.wt.example.com/your-container-name
+```
+
+## Configuration
+
+To configure Webtask on a dedicated domain, you will need to set up a DNS zone to host the name entries for *each* tenant. As with the authentication domain, the Webtask dedicated domain requires a valid certificate issued by a public certificate authority (CA). If you're not certain how many tenants you'll be hosting, we recommend using a wildcard certificate such as `*.your-webtask-dedicated-domain`.
+
+This will give to each container a URL of the form:
+
+```text
+tenant-name.webtask-dedicated-domain/container-name
+```
+
+For example, let's say that your tenant name is `acme` and your Webtask dedicated domain is `wt.example.com`. If you create a container named `hello`, your Webtask URL will be `acme.wt.example.com/hello`.
+
+Note that you can still use the original Webtask URL (for example, `webtask.example.com/api/run/acme/hello`). The primary difference is that, during runtime, the Webtask will remove any headers bearing cookies from the request.
+
+## Frequently Asked Questions
+
+**Can I use the same root domain for Auth0 and Webtask?**
+
+No. Because the tenant name is used in the first part of the domains for the Auth0 tenant and Webtask tenants, the *root* domain must differ.
+
+**Do I have to enable Webtask Dedicated Domains?**
+
+Yes, if you are planning on using Extensions, you must implement Webtask dedicated domains.
+
+**Can the Webtask tenant names differ from the one used by the Auth0 tenant?**
+
+No. The Webtask tenant name has to be the same as the Auth0 tenant name.
diff --git a/ja-jp/articles/appliance/webtasks/index.md b/ja-jp/articles/appliance/webtasks/index.md
new file mode 100644
index 0000000000..c390c9c027
--- /dev/null
+++ b/ja-jp/articles/appliance/webtasks/index.md
@@ -0,0 +1,122 @@
+---
+section: appliance
+description: How to use Webtasks on the PSaaS Appliance
+topics:
+    - appliance
+    - webtask
+contentType: 
+    - concept
+    - index
+useCase: appliance
+applianceId: appliance51
+sitemap: false
+---
+
+# PSaaS Appliance: Webtasks
+
+Beginning with Build 7247, you may use the PSaaS Appliance's version of [Webtasks](http://webtask.io/) to execute your rules and custom database logic.
+
+::: panel Prerequisites
+Prior to working with Webtasks, please ensure that you have configured the:
+
+* [PSaaS Appliance Command Line Interface (CLI)](/appliance/cli/configure-cli);
+* [Webtask Command Line Interface (`wt-cli`)](https://webtask.io/docs/101)
+:::
+
+Auth0 provides `auth0-sandbox`, a stage (sometimes referred to as a *sandbox*) on which you may run your rules and custom database logic.
+
+## Working with Webtasks
+
+You may use Webtasks by calling its endpoints directly. This can be done using the Webtask Command Line Interface (`wt-cli`) and specifying the ``--url "https://webtask..com"`` parameter (where `a0url` is the address of the PSaaS Appliance node). For additional information on setting up the `wt-cli`, please see [Getting Started with Webtasks](https://webtask.io/docs/101).
+
+### Node.js Modules
+
+Currently, not all of the [Node.js modules available for the Auth0 Cloud Environment](https://auth0-extensions.github.io/canirequire/) are available for the PSaaS Appliance.
+
+To see which modules are available for Webtasks running on PSaaS Appliance instances, execute the [`List Modules` Webtask](https://github.com/auth0-extensions/canirequire/blob/gh-pages/tasks/list_modules.js) on your PSaaS Appliance instance.
+
+#### Set up the List Modules Webtask
+
+First, copy locally the [`List Modules` Webtask](https://github.com/auth0-extensions/canirequire/blob/gh-pages/tasks/list_modules.js), either by downloading the file from GitHub or by copying this code:
+
+```js
+'use npm';
+const Fs = require('fs');
+const Verquire = require('verquire');
+const _ = require('lodash@4.8.2');
+
+const abcsort = function (a, b) {
+  if (a.name < b.name) {
+      return -1;
+  }
+
+  if (a.name > b.name) {
+      return 1;
+  }
+
+  return 0;
+};
+
+
+const natives = Object.keys(process.binding("natives"))
+    .filter(nativeDep => nativeDep[0] !== '_')
+    .map(dep => ({name: dep, version: 'native'}))
+    .sort(abcsort);
+
+
+const modules = _.flatMap(Verquire.modules, (versions, module_name) => {
+   return versions.map((version) => {
+       const moduleObj = {
+         name: module_name,
+         version: version
+       };
+
+       return moduleObj;
+   });
+}).sort(abcsort);
+
+module.exports = cb => {
+    cb(null, {
+        node_version: process.version,
+        modules: natives.concat(modules)
+    });
+};
+```
+
+Next, create a Webtask profile using `wt-cli` (if you don't already have one):
+
+```bash
+wt init --container "YOUR_TENANT_NAME" --url "WEBTASK_URL" --token "eyJhbGci..." -p "a``YOUR_TENANT_NAME-default"
+```
+
+Finally, you are ready to register your Webtask using the `wt create` command. This command receives as input a path or URL of the ebtask's code and provides as output the URL where the Webtask is available.
+
+If you saved the file under a `my-webtasks` directory as `list_modules.js` you would use the following:
+
+```bash
+wt create ./my-webtasks/list_modules.js
+```
+
+You should get a message that the Webtask was created, alongside with the URL to access it. The response is a JSON object.
+
+```json
+{
+  "node_version":"v4.4.5",
+  "modules":[
+    {"name":"assert","version":"native"},
+    {"name":"buffer","version":"native"},
+    {"name":"child_process","version":"native"},
+    {"name":"assert-plus","version":"0.1.5"},
+    ...
+  ]
+}
+```
+
+## Keep reading
+
+::: next-steps
+* [Getting Started with Webtasks](https://webtask.io/docs/101)
+* [Using Webtasks as Code Sandboxes](https://webtask.io/docs/sample_multitenant)
+* [HTTP API: Executing Webtasks](https://webtask.io/docs/api_run)
+* [Webtasks with Dedicated Domains](/appliance/webtasks/dedicated-domains)
+:::
diff --git a/ja-jp/articles/application-auth/current/client-side-web.md b/ja-jp/articles/application-auth/current/client-side-web.md
new file mode 100644
index 0000000000..8d504faa5c
--- /dev/null
+++ b/ja-jp/articles/application-auth/current/client-side-web.md
@@ -0,0 +1,305 @@
+---
+title: Authentication for Client-side Web Apps
+description: Explains how to authenticate users in a Client-side Web application.
+toc: true
+topics:
+  - spa
+  - authentication
+  - oauth2
+  - implicit
+contentType: 
+    - concept
+    - how-to
+useCase:
+  - add-login
+---
+
+# Authentication for Client-side Web Apps
+
+You can use the Auth0 Authentication API to create client-side web applications that use [OpenID Connect](/protocols/oidc) and [OAuth 2.0](/protocols/oauth2) to authenticate users and get their authorization to access protected resources.
+
+## Overview
+
+Auth0 exposes endpoints that you can use to authenticate users and get their authorization. You can redirect the user from your JavaScript application to these endpoints in the web browser. Auth0 will handle the authentication of the user, get their authorization for the resources your app wants to access, and then redirect the user back to a pre-configured callback URL, returning an [ID Token](/tokens/concepts/id-tokens) and [Access Token](/tokens/concepts/access-tokens) in the hash fragment of the request.
+
+## The Authentication Flow
+
+The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Client-side Web applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2).
+
+The Implicit Grant flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders).
+
+After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along the [ID Token](/tokens/concepts/id-tokens) as parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier). The [ID Token](/tokens/concepts/id-tokens) is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes (referred to as Claims) regarding the user, such as the user's name, email address, profile picture and so on.
+
+The [ID Token](/tokens/concepts/id-tokens) can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example.
+
+::: note
+You can potentially also receive an Access Token which can be used to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or your own APIs.
+
+For more information on calling APIs from Client-side Web Apps, please see [Call APIs from Client-side Web Apps](/api-auth/grant/implicit)
+:::
+
+![](/media/articles/client-auth/client-side-web/client-side-web-flow.png)
+
+1. The Applications initiates the flow and redirects the user to the Authorization Server
+2. The user authenticates
+3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment
+4. The Applications can now extract the token from the hash fragment.  
+
+## Register your Applications
+
+The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication.
+
+Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Applications** button.
+
+The **Create Applications** window will open, allowing you to enter the name of your new application. Choose **Single-Page Web Applications** as the **Applications Type** and click on the **Create** button to create the new applications.
+
+![](/media/articles/client-auth/client-side-web/create-client.png)
+
+Once the application has been created you can navigate to the **Settings** tab of the applications and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `https://YOUR_APP/callback`.
+
+This URL must be part of your application, as your application will need to extract the ID Token from the hash fragment of this URL.
+
+![](/media/articles/client-auth/client-side-web/allowed-callback-url.png)
+
+Next, click on **Show Advanced Settings**. Go to the **OAuth** tab and ensure that you have enabled the **OIDC Conformant** switch:
+
+![](/media/articles/client-auth/client-side-web/oidc-conformant.png)
+
+Save the Settings.
+
+## Call the Authorization URL
+
+The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) session is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication.
+
+This endpoint supports the following query string parameters:
+
+| Parameter | Description |
+|:------------------|:---------|
+| response_type | The response type specifies the Grant Type you want to use. For client-side web applications using the Implicit Grant Flow, this should be `id_token`. (If you also want to receive an Access Token it should be set to `token id_token`.) |
+| client_id | The Client ID of the Applications you registered in Auth0. This can be found on the **Settings** tab of your Applications in the Auth0 Dashboard |
+| scope | Specifies the claims (or attributes) of the user you want the be returned in the [ID Token](/tokens/concepts/id-tokens). To obtain an [ID Token](/tokens/concepts/id-tokens) you need to specify at least a scope of `openid`. If you want to return the user's full profile information, you can request `openid profile`.

    You can read up more about [scopes](/scopes). |
+| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `https://YOUR_APP/callback`|
+| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

     If this parameter is not specified, the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your applications.  |
+| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) |
+| nonce | A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). **This is required.** |
+
+::: note
+  Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Applications inside the [Auth0 Dashboard](${manage_url}).
+:::
+
+## Handle the callback
+
+After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the [ID Token](/tokens/concepts/id-tokens) in the hash fragment of the URL, such as
+
+```text
+https://YOUR_APP/callback#id_token=eyJ0...
+```
+
+The [ID Token](/tokens/concepts/id-tokens) will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can access the hash fragment using the `window.location.hash` property and then use basic JavaScript string manipulation to access the ID Token.
+
+You will need to decode the [ID Token](/tokens/concepts/id-tokens) in order to read the claims (or attributes) of the user. 
+
+Once the JWT is decoded, you can extract the information about the user from the payload of the [ID Token](/tokens/concepts/id-tokens). This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata.
+
+The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you in decoding the JWT by calling the `parseHash` function, and then access the ID Token values from the `idTokenPayload` property:
+
+```html
+
+
+
+  
+  Document
+
+
+
+  
+  
+  
+  
+
+
+```
+
+### The ID Token payload
+
+An example payload for an [ID Token](/tokens/concepts/id-tokens) may look something like this:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "email": "jerrie@j...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129,
+  "nonce": "..."
+}
+```
+
+The payload above contains the following claims:
+
+| Parameter | Description |
+|:------------------|:---------|
+| name | The name of the user which is returned from the Identity Provider. |
+| email | The email address of the user which is returned from the Identity Provider. |
+| picture | The profile picture of the user which is returned from the Identity Provider. |
+| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. |
+| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued [ID Token](/tokens/concepts/id-tokens), this will be **the URL of your Auth0 tenant**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued [ID Token](/tokens/concepts/id-tokens), this will be the **Client ID of your Auth0 Applications**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| nonce | A string value which was sent with the request to the `/authorize` endpoint. This is used to [prevent token replay attacks](/api-auth/tutorials/nonce). |
+
+The exact claims contained in the [ID Token](/tokens/concepts/id-tokens) will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an [ID Token](/tokens/concepts/id-tokens) issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned.
+
+::: note
+The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token.
+:::
+
+### Keep the user logged in
+
+Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use `localStorage` to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the [ID Token](/tokens/concepts/id-tokens).
+
+You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience.
+
+## Examples
+
+### A Basic Authentication Request
+
+The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &nonce=abc
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+```
+
+And this is an example of the decoded payload of the [ID Token](/tokens/concepts/id-tokens) which will be returned:
+
+```json
+{
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt9...",
+  "exp": 1478112929,
+  "iat": 1478076929,
+  "nonce": "abc"
+}
+```
+
+### Request the Name and Profile Picture
+
+You can request a user's profile attributes, such as name and profile picture, by requesting the `profile` scope.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20profile
+  &nonce=abc
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+```
+
+The name and profile picture will be available in the `name` and `picture` claims of the returned [ID Token](/tokens/concepts/id-tokens):
+
+```json
+{
+  "name": "jerrie@...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129,
+  "nonce": "abc"
+}
+```
+
+### Request a User Log In With GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid` and `profile` scopes:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20profile
+  &connection=github
+  &nonce=abc
+```
+
+::: panel Log in with other social providers
+You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info:
+- [Identity Providers Supported by Auth0](/identityproviders)
+- [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` passed as parameter in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+```
+
+The user's name and profile attributes, such as the name, nickname and picture will be available in the `name`, `nickname` and `picture` claims of the returned [ID Token](/tokens/concepts/id-tokens). You will also notice that the `sub` claim contains the User's unique ID returned from GitHub:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "nickname": "jerriep",
+  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
diff --git a/ja-jp/articles/application-auth/current/index.md b/ja-jp/articles/application-auth/current/index.md
new file mode 100644
index 0000000000..685c9b3586
--- /dev/null
+++ b/ja-jp/articles/application-auth/current/index.md
@@ -0,0 +1,35 @@
+---
+classes: topic-page
+title: Application Authentication
+description: Introduction to authentication and the various application authentication flows.
+topics:
+  - authentication
+  - oauth2
+contentType: index
+useCase:
+  - add-login
+---
+
+# Authentication
+
+Authentication refers to the process of confirming identity. While often used interchangeably with [authorization](/authorization), authentication represents a fundamentally different function. 
+
+In authentication, a user or application proves they are who they say they are by providing valid credentials for verification. Authentication is often proved through a username and password, sometimes combined with other elements called _factors_, which fall into three categories: what you know, what you have, or what you are.
+
+* **Single-Factor Authentication** relies on a password. Example: a school website that only requires validating a password against a username. 
+* **Two-Factor Authentication** relies on a piece of confidential information in addition to a username and password. Example: a banking website that validates a password against a username and then requires the user to enter a PIN known to only the user.
+* **Multi-Factor Authentication (MFA)** uses two or more security factors from independent categories. Example: a hospital system that requires a username and password, a security code received on the user's smartphone, and fingerprint.
+
+For a comparison of authentication and authorization, see [Authentication vs. Authorization](/authorization/concepts/authz-and-authn).
+
+# Application Authentication Flows
+
+Auth0 uses [OpenID Connect](/protocols/oidc) and [OAuth 2.0](/protocols/oauth2) to authenticate users and verify their identity. 
+
+We support scenarios for mobile, desktop, server-side, or client-side applications. You can get more details on implementing these flows by exploring:
+
+<%= include('../../_includes/_topic-links', { links: [
+  'flows/guides/auth-code-pkce/add-login-auth-code-pkce',
+  'flows/guides/implicit/add-login-implicit',
+  'flows/guides/auth-code/add-login-auth-code'
+] }) %>
diff --git a/ja-jp/articles/application-auth/current/mobile-desktop.md b/ja-jp/articles/application-auth/current/mobile-desktop.md
new file mode 100644
index 0000000000..183b936bb5
--- /dev/null
+++ b/ja-jp/articles/application-auth/current/mobile-desktop.md
@@ -0,0 +1,389 @@
+---
+title: Authentication for Mobile & Desktop Apps
+description: Explains how to authenticate users in a mobile or desktop application.
+toc: true
+topics:
+  - authentication
+  - oauth2
+  - mobile-apps
+  - desktop-apps
+contentType: 
+    - concept
+    - how-to
+useCase:
+  - add-login
+---
+# Authentication for Mobile & Desktop Apps
+
+You can authenticate users of your mobile/desktop applications by:
+
+* Using [Lock](/libraries/lock), a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface;
+* Using one of the [Auth0 SDKs](/libraries), which are client-side libraries that **do not** include a user interface but allow for expanded customization of the authentication behavior and appearance of the login screen;
+* Calling the Auth0 [Authentication API](/api/authentication) endpoints, which allows you to integrate with Auth0 without requiring the user of Auth0's libraries.
+
+This article will cover how to call the Auth0 [Authentication API](/api/authentication) endpoints using [Proof Key for Code Exchange (PKCE)](/api-auth/grant/authorization-code-pkce) during the authentication and authorization process.
+
+If you would like to implement this functionality using either Lock or one of the Auth0 SDKs, please refer to the following resources:
+
+* Lock
+  * [Lock for Web](/libraries/lock)
+  * [Lock for iOS](/libraries/lock-ios)
+  * [Lock for Android](/libraries/lock-android)
+* Auth0 SDK
+  * [Auth0 SDK for Web](/libraries/auth0js)
+  * [Auth0 SDK for iOS](/libraries/auth0-swift)
+  * [Auth0 SDK for Android](/libraries/auth0-android)
+
+## Overview
+
+Auth0 exposes endpoints that you can use to authenticate users and get their authorization. 
+
+You can call these endpoints through an embedded browser in your **native** application. After authentication completes, you can return an [ID Token](/tokens/concepts/id-tokens) (which contains information about the identity of the user) and an [Access Token](/tokens/concepts/access-tokens).
+
+::: note
+Instead of following this tutorial, you can use any of Auth0's client libraries. They encapsulate all the logic required and make it easier for your to implement authentication. Please refer to our [Native Quickstarts](/quickstart/native) to get started.
+:::
+
+## Register your application
+
+If you haven't already created a new [application](/applications) in Auth0, you'll need to do so before implementing your authentication flow. The Auth0 Application maps to your application and allows your application to use Auth0 for authentication purposes.
+
+Go to the [Auth0 Dashboard](${manage_url}) and click on [Applications](${manage_url}/#/applications) in the left-hand navigation bar. Click **Create Application**.
+
+The **Create Application** window will open, allowing you to enter the name of your new Application. Choose **Native** as the **Application Type**. When done, click on **Create** to proceed.
+
+::: warning
+The Authorization Code flow with PKCE can only be used for Native Applications.
+:::
+
+![](/media/articles/client-auth/mobile-desktop/create-client.png)
+
+Once Auth0 creates the Application, navigate to the Application's **Settings** tab to:
+
+* Add the following URL to the **Allowed Callback URLs** field: `https://${account.namespace}/mobile`;
+* Enable the **OIDC Conformant** Flag under the *OAuth* area of *Advanced Settings*.
+
+Scroll to the bottom of the page and click **Save**.
+
+![](/media/articles/client-auth/mobile-desktop/allowed-callback-url.png)
+
+## Implement Authentication
+
+For our mobile app, we will implement the [OAuth 2.0 Authorization Code Grant Flow using Proof Key for Code Exchange](/api-auth/grant/authorization-code-pkce).
+
+### Step 1: Create a Random Key and the Code Challenge
+
+First, you will need to generate and store a `code_verifier`, which is a cryptographically random key that, along with its transformed value (called the `code_challenge`), will be sent to Auth0 for an `authorization_code`.
+
+For sample scripts, to generate a `code_verifier` and a `code_challenge`, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#1-create-a-code-verifier).
+
+### Step 2: Authorize the User
+
+Once you've created the `code_verifier` and the `code_challenge`, you'll need to get the user's authorization. This is technically the beginning of the authorization flow, and this step may include one or more of the following processes:
+
+* Authenticating the user;
+* Redirecting the user to an Identity Provider to handle authentication;
+* Checking for active Single Sign-on (SSO) [sessions](/sessions).
+
+To authorize the user, your application must send the user to the [authorization URL](/api/authentication#authorization-code-grant-pkce-) (which includes the `code_challenge` you generated in the previous step, as well as the method you used to generate the `code_challenge`). Your URL should follow this format:
+
+```text
+https://${account.namespace}/authorize?
+    scope=SCOPE&
+    response_type=code&
+    client_id=${account.clientId}&
+    code_challenge=CODE_CHALLENGE&
+    code_challenge_method=S256&
+    redirect_uri=${account.namespace}/mobile
+```
+
+Note that the sample Authorization URL doesn't include an `audience` parameter. In this scenario, your app needs to authenticate only the user, not access an API, so we omit `audience`.
+
+For details on the request parameters, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#3-get-the-user-s-authorization).
+
+As an example, your HTML snippet for your authorization URL might look like the following:
+
+```html
+
+  Sign In
+
+```
+
+If all goes well, you'll receive an `HTTP 302` response:
+
+```text
+HTTP/1.1 302 Found
+Location: https://${account.namespace}/mobile?code=AUTHORIZATION_CODE
+```
+
+Note the authorization code included at the end of the included URL.
+
+### Step 3: Obtain an ID Token
+
+Using the authorization code obtained in step 2, you can obtain the ID Token by making the appropriate `POST` call to the [tokens endpoint](api/authentication#authorization-code-pkce-).
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "code_verifier",
+        "value": "YOUR_GENERATED_CODE_VERIFIER"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "https://${account.namespace}/mobile"
+      }
+    ]
+  }
+}
+```
+
+For details on the request parameters, refer to [Execute an Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce#4-exchange-the-authorization-code-for-an-access-token).
+
+If all goes well, you'll receive an HTTP 200 response with the following payload:
+
+```json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "refresh_token":"GEbRxBN...edjnXbL",
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+::: note
+You can use the Access Token to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info).
+:::
+
+## The ID Token
+
+Once you've decoded the ID Token, you can extract user information from it. The JSON payload contains the user claims (attributes), as well as metadata, and it will look something like this:
+
+```json
+{
+  "name": "John Smith",
+  "email": "jsmith@example.com",
+  "picture": "https://example.com/profile-pic.png",
+  "iss": "https://auth0user.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+For additional details, please see our docs [on the ID Token and its claims](/tokens/id-tokens#id-token-payload).
+
+::: note
+For a list of libraries you can use to verify and decode tokens refer to [JWT.io](https://jwt.io/#libraries-io).
+:::
+
+## Example Use Cases
+
+This section covers use cases that illustrate the authentication process using PKCE.
+
+### Request the User's Name and Profile Picture
+
+In addition to the usual authentication, this example shows how you can request additional user details.
+
+We assume that your app is capable of generating the appropriate `code_verifier` and `code_challenge`.
+
+To return the user's `name` and `picture`, add the appropriate scopes to your call to the `/authorize` endpoint. Therefore, the initial authorization URL is as follows:
+
+```text
+https://${account.namespace}/authorize?
+    scope=openid%20name%20picture&
+    response_type=code&
+    client_id=${account.clientId}&
+    code_challenge=CODE_CHALLENGE&
+    code_challenge_method=S256&
+    redirect_uri=${account.namespace}/mobile
+```
+
+After the user submits the request, the app receives an `TTP 302` response with a URL containing the authorization code at the end: `https://${account.namespace}/callback?code=AUTHORIZATION_CODE`
+
+Using the authorization code, you can obtain the ID Token by making a `POST` call to the [tokens](/api/authentication#authorization-code-pkce-) endpoint.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "code_verifier",
+        "value": "YOUR_GENERATED_CODE_VERIFIER"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "https://${account.namespace}/mobile"
+      }
+    ]
+  }
+}
+```
+
+If all goes well, you'll receive an HTTP 200 response with the following payload:
+
+```json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "refresh_token":"GEbRxBN...edjnXbL",
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+By extracting the ID Token, which now contains the additional `name` and `picture` claims you requested, you'll see something similar to the following once you've decoded the payload:
+
+```json
+{
+  "name": "auth0user@...",
+  "picture": "https://example.com/profile-pic.png",
+  "iss": "https://auth0user.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+### Request a User Log In with GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the `connection` parameter and setting its value to `github`.
+
+:::panel Logins with Social Providers
+While this example shows how to log in users via GitHub, you can just as easily request that a user log in with other Social providers, such as Google or Facebook.
+
+To do this, configure the appropriate Connection in the [Auth0 Dashboard](${manage_url}/#/connections/social) and change the `connection` value of the call to `/authorize` to the name of the Connection (`google-oauth2` for Google, `facebook` for Facebook, and so on). You can get the Connection's name from the *Settings* tab of the [Connections](${manage_url}/#/connections/social) page.
+
+Read more:
+
+* [Identity Providers Supported by Auth0](/identityproviders)
+* [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+```text
+https://${account.namespace}/authorize?
+    scope=openid%20name%20picture&
+    response_type=code&
+    client_id=${account.clientId}&
+    code_challenge=CODE_CHALLENGE&
+    code_challenge_method=S256&
+    redirect_uri=https://${account.namespace}/mobile&
+    connection=github
+```
+
+After the user submits the request, the app receives an `HTTP 302` response with a URL containing the authorization code at the end: `https://${account.namespace}/callback?code=AUTHORIZATION_CODE`
+
+Using the authorization code, you can obtain the ID Token by making a `POST` call to the [tokens](/api/authentication#authorization-code-pkce-) endpoint.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "code_verifier",
+        "value": "YOUR_GENERATED_CODE_VERIFIER"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "https://${account.namespace}/mobile"
+      }
+    ]
+  }
+}
+```
+
+If all goes well, you'll receive an `HTTP 200` response with the following payload:
+
+```json
+{
+  "access_token":"eyJz93a...k4laUWw",
+  "refresh_token":"GEbRxBN...edjnXbL",
+  "id_token":"eyJ0XAi...4faeEoQ",
+  "token_type":"Bearer",
+  "expires_in":86400
+}
+```
+
+You can pull the user's name, profile picture, and email address from the `name`, `picture`, and `email` claims of the returned ID Token. Note that the `sub` claim contains the user's unique ID as returned from GitHub:
+
+```json
+{
+  "name": "John Smith",
+  "picture": "https://avatars.example.com",
+  "email": "jsmith@...",
+  "email_verified": true,
+  "iss": "https://auth0user.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
+
+## How to implement
+
+For most common types of applications, we have SDKs available which handle the PKCE protocol for you. The exact implementation will be different based on the technology being used. Please refer to our [Mobile / Native App Quickstarts](/quickstart/native), select the appropriate Quickstart based on your application, and follow the code samples provided.
diff --git a/ja-jp/articles/application-auth/current/server-side-web.md b/ja-jp/articles/application-auth/current/server-side-web.md
new file mode 100644
index 0000000000..026aa3dab9
--- /dev/null
+++ b/ja-jp/articles/application-auth/current/server-side-web.md
@@ -0,0 +1,295 @@
+---
+title: Authentication for Server-side Web Apps
+description: Explains how to authenticate users in a Server-side Web application.
+toc: true
+topics:
+  - oauth2
+  - authentication
+  - server-side-apps
+contentType: 
+    - concept
+    - how-to
+useCase:
+  - add-login
+---
+
+# Authentication for Server-side Web Apps
+
+You can use the Auth0 Authentication API to create server-side web applications that uses OAuth 2.0 and OpenID Connect (OIDC) to authenticate users and get their authorization to access protected resources.
+
+## Overview
+
+Auth0 exposes endpoints that you can use to authenticate users and get their authorization. 
+
+You can redirect the user from your web application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to a pre-configured callback URL, returning an authorization code in the query string parameters of the callback URL. This code can then be exchanged for an [ID Token](/tokens/concepts/id-tokens) (which contains information about the identity of the user) and an [Access Token](/tokens/concepts/access-tokens).
+
+## The Authentication Flow
+
+The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Server-side Web applications is known as the [Authorization Code flow](https://tools.ietf.org/html/rfc6749#section-1.3.1).
+
+The Authorization Code flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders).
+
+After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along a `code` parameter in the query string of the Callback URL. This `code` can then be exchanged for an [ID Token](/tokens/concepts/id-tokens) by making a request to the `/oauth/token` endpoint.
+
+The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes regarding the user, such as the user's name, email address, profile picture and so on. These attributes are referred to as **Claims** and they can be extracted from the ID Token and used in your application (for example, to display a user's name and profile image).
+
+::: note
+You will also receive an [Access Token](/tokens/concepts/access-tokens) which you can use to call the [Authentication API's `/userinfo` endpoint](/api/authentication#get-user-info) or your own APIs. For more information on calling APIs web apps running on the server, see [Calling APIs from Server-side Web Apps](/api-auth/grant/authorization-code)
+:::
+
+![Authentication flow for server-side web apps](/media/articles/client-auth/server-side-web/server-side-web-flow.png)
+
+1. The Application initiates the flow and redirects the user to the Authorization Server.
+2. The user authenticates.
+3. The Authorization Server redirects to the `redirect_uri` with a `code` in the query string.
+4. The Application sends the `code` together with the Client ID, Client Secret and `redirect_uri` to the Authorization Server.
+5. The Authorization Server validates this information and returns an ID Token.
+
+## Register your Application
+
+The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication.
+
+Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button.
+
+The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Regular Web Applications** as the **Application Type** and click on the **Create** button to create the new application.
+
+![](/media/articles/client-auth/server-side-web/create-client.png)
+
+Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `${account.callback}`.
+
+This URL must be part of your application, as your application will need to retrieve the `code` and exchange it for the ID Token.
+
+![](/media/articles/client-auth/server-side-web/allowed-callback-url.png)
+
+Next, click on **Show Advanced Settings**. Go to the **OAuth** tab and ensure that you have enabled the **OIDC Conformant** switch:
+
+![](/media/articles/client-auth/server-side-web/oidc-conformant.png)
+
+Save the Settings.
+
+## Call the Authorization URL
+
+The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication.
+
+This endpoint supports the following query string parameters:
+
+| Parameter | Description |
+|:------------------|:---------|
+| response_type | The response type specifies the Grant Type you want to use. For server-side web applications using the Authorization Code Flow this **must be set** to `code` |
+| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard |
+| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To get an ID Token in the response, you need to specify at least the scope of `openid` in the request. If you want to return the user's full profile information, you can request `openid profile`.

    You can read the [scopes documentation](/scopes) for more information. |
+| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`|
+| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

     If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application.  |
+
+::: note
+  Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}).
+:::
+
+## Exchange the code for an ID Token
+
+After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along a `code` as a query string parameter of the URL, such as
+
+```text
+${account.callback}?code=tQPUv...
+```
+
+You application will need to handle the request to this callback URL, extract the `code` query string parameter and call the `/oauth/token` endpoint of the Auth0 Authentication API in order to exchange the `code` for the ID Token:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "https://${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+The response from `/oauth/token` contains `access_token`, `expires_in`, `id_token` and `token_type` values (and also potentially a `refresh_token`), for example:
+
+```json
+{
+  "access_token": "subBe48...",
+  "expires_in": 86400,
+  "id_token": "eyJ0eXAi...",
+  "token_type": "Bearer"
+}
+```
+
+The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You will need to decode the ID Token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT.
+
+You can refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token.
+
+Once the JWT is decoded, you can extract the information about the user from the payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata.
+
+### The ID Token payload
+
+An example payload for an ID Token may look something like this:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "email": "jerrie@j...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+The payload above contains the following claims:
+
+
+| Parameter | Description |
+|:------------------|:---------|
+| name | The name of the user which is returned from the Identity Provider. |
+| email | The email address of the user which is returned from the Identity Provider. |
+| picture | The profile picture of the user which is returned from the Identity Provider. |
+| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. |
+| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+
+The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned.
+
+::: note
+The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token.
+:::
+
+### Keep the user logged in
+
+Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use a cookie or other session storage to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token.
+
+You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience.
+
+## Examples
+
+### A Basic Authentication Request
+
+The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `code` for an ID Token. This is an example of the decoded payload of the ID Token which will be returned:
+
+```json
+{
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt9...",
+  "exp": 1478112929,
+  "iat": 1478076929
+}
+```
+
+### Request the Name and Profile Picture
+
+You can request a user's profile information, for example their name and profile picture, by requesting the `profile` scope in addition to the `openid` scope:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20profile
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `code` for an ID Token. The profile attributes of the user, such as the name and profile picture will be available in the `name` and `picture` claims of the returned ID Token:
+
+```json
+{
+  "name": "jerrie@...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+### Request a User Log In With GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20profile
+  &connection=github
+```
+
+::: note
+You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info:
+- [Identity Providers Supported by Auth0](/identityproviders)
+- [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with a `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `code` for an ID Token. Since we also requested the `profile` scope, the user's Github profile attributes will also be available. In the example below you will notice the `name`, `nickname` and `picture` attributes are returned with the values from GitHub. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "nickname": "jerriep",
+  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
diff --git a/ja-jp/articles/application-auth/index.yml b/ja-jp/articles/application-auth/index.yml
new file mode 100644
index 0000000000..2132d215a0
--- /dev/null
+++ b/ja-jp/articles/application-auth/index.yml
@@ -0,0 +1,9 @@
+versioning:
+    baseUrl: application-auth
+    current: current
+    versions:
+      - legacy
+      - current
+    defaultArticles:
+      legacy: index
+      current: index
diff --git a/ja-jp/articles/application-auth/legacy/client-side-web.md b/ja-jp/articles/application-auth/legacy/client-side-web.md
new file mode 100644
index 0000000000..da677b5d3a
--- /dev/null
+++ b/ja-jp/articles/application-auth/legacy/client-side-web.md
@@ -0,0 +1,271 @@
+---
+description: Explains how to authenticate users in a Client-side Web application.
+toc: true
+topics:
+  - spa
+  - authentication
+  - oauth2
+  - implicit
+contentType: 
+    - concept
+    - how-to
+useCase:
+  - add-login  
+---
+# Authentication for Client-side Web Apps
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+The Auth0 OAuth 2.0 authentication endpoints support Client-side Web Applications. These applications are also referred to as JavaScript or Single-Page Applications.
+
+## Overview
+
+Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can redirect the user from your JavaScript application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to the Callback URL, returning the ID Token in the hash fragment of the request.
+
+## The Authentication Flow
+
+The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Client-side Web applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2).
+
+The Implicit Grant flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders).
+
+After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along an `id_token` parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier). The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on.
+
+The ID Token can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example.
+
+![](/media/articles/client-auth/client-side-web/client-side-web-flow.png)
+
+1. The Application initiates the flow and redirects the user to the Authorization Server
+2. The user authenticates
+3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment
+4. The Application can now extract the token from the hash fragment.  
+
+## Register your Application
+
+The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication.
+
+Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button.
+
+The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Single-Page Web Applications** as the **Application Type** and click on the **Create** button to create the new application.
+
+![](/media/articles/client-auth/client-side-web/create-client.png)
+
+Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `https://YOUR_APP/callback`.
+
+This URL must be part of your application, as your application will need to extract the ID Token from the hash fragment of this URL. Save the Settings.
+
+![](/media/articles/client-auth/client-side-web/allowed-callback-url.png)
+
+## Call the Authorization URL
+
+The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication.
+
+This endpoint supports the following query string parameters:
+
+| Parameter | Description |
+|:------------------|:---------|
+| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For client-side web applications using the Implicit Grant Flow this **must be set** to `token` |
+| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard |
+| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

    You can read up more about [scopes](/scopes). |
+| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`.|
+| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

     If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application.  |
+| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) |
+| nonce | A string value which will be included in the response from Auth0, [used to prevent token replay attacks](/api-auth/tutorials/nonce). It is required for `response_type=id_token token`. |
+
+::: note
+  Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}).
+:::
+
+## Handle the callback
+
+After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the ID Token and the `token_type` in the hash fragment of the URL, such as
+
+```text
+https://YOUR_APP/callback#id_token=eyJ0...&token_type=Bearer
+```
+
+The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can access the hash fragment using the `window.location.hash` property and then use basic JavaScript string manipulation to access the ID Token.
+
+As mentioned, the ID Token is a JWT and you will need to decode this token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT.
+
+Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata.
+
+The [Auth0.js library](https://auth0.com/docs/libraries/auth0js) can assist you in decoding the JWT by calling the `parseHash` function, and then access the ID Token values from the `idTokenPayload` property:
+
+```
+
+  
+    
+    Document
+  
+  
+    
+    
+    
+  
+
+```
+
+### The ID Token Payload
+
+An example payload for an ID Token may look something like this:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "email": "jerrie@j...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+The payload above contains the following claims:
+
+| Parameter | Description |
+|:------------------|:---------|
+| name | The name of the user which is returned from the Identity Provider. |
+| email | The email address of the user which is returned from the Identity Provider. |
+| picture | The profile picture of the user which is returned from the Identity Provider. |
+| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. |
+| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+
+The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned.
+
+::: note
+The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token.
+:::
+
+### Keep the user logged in
+
+Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use `localStorage` to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token.
+
+You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience.
+
+## Examples
+
+### A Basic Authentication Request
+
+The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+And this is an example of the decoded payload of the ID Token which will be returned:
+
+```json
+{
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt9...",
+  "exp": 1478112929,
+  "iat": 1478076929
+}
+```
+
+### Request the Name and Profile Picture
+
+You can request a user's name and profile picture by requesting the `name` and `picture` scopes.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20name%20picture
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token:
+
+```json
+{
+  "name": "jerrie@...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+### Request a User Log In With GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20name%20picture%20email
+  &connection=github
+```
+
+::: panel Log in with other social providers
+You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info:
+- [Identity Providers Supported by Auth0](/identityproviders)
+- [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment:
+
+```text
+${account.callback}
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
+  "email": "jerrie@...",
+  "email_verified": true,
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
diff --git a/ja-jp/articles/application-auth/legacy/index.md b/ja-jp/articles/application-auth/legacy/index.md
new file mode 100644
index 0000000000..56a74c0a5b
--- /dev/null
+++ b/ja-jp/articles/application-auth/legacy/index.md
@@ -0,0 +1,23 @@
+---
+classes: topic-page
+title: Application Authentication
+description: Introduction to the various application authentication flows.
+topics:
+  - authentication
+  - oauth2
+contentType: index
+useCase:
+  - add-login
+---
+
+# Application Authentication
+
+Auth0 uses the OAuth 2.0 protocol for authentication and authorization. We support common OAuth 2.0 scenarios for Mobile Applications, Desktop Applications, Server-side web applications or Client-side Web Applications.
+
+You can get more details on implementing these flows by following one of the following links:
+
+<%= include('../../_includes/_topic-links', { links: [
+  'application-auth/legacy/mobile-desktop',
+  'application-auth/legacy/server-side-web',
+  'application-auth/legacy/client-side-web'
+] }) %>
diff --git a/ja-jp/articles/application-auth/legacy/mobile-desktop.md b/ja-jp/articles/application-auth/legacy/mobile-desktop.md
new file mode 100644
index 0000000000..04b9497aee
--- /dev/null
+++ b/ja-jp/articles/application-auth/legacy/mobile-desktop.md
@@ -0,0 +1,245 @@
+---
+description: Explains how to authenticate users in a mobile or desktop application.
+toc: true
+topics:
+  - authentication
+  - oauth2
+  - mobile-apps
+  - desktop-apps
+contentType: 
+    - concept
+    - how-to
+useCase:
+  - add-login
+---
+# Authentication for Mobile & Desktop Apps
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+You can easily authenticate users in your mobile and desktop applications by using either the Lock application libraries, or by calling the Auth0 OAuth 2.0 endpoints yourself.
+
+## Overview
+
+Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can call these endpoints through an embedded browser in your application, and then intercept the request to the callback URL to extract the ID Token which contains the user's profile information.
+
+We also make a set of application libraries available which encapsulates all the logic for you and makes it much easier to implement authentication in all the popular mobile and desktop platforms. Please refer to our [Native Quickstarts](/quickstart/native) to get started with any of these.
+
+## The Authentication Flow
+
+The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for mobile applications is known as the [Implicit Grant flow](https://tools.ietf.org/html/rfc6749#section-1.3.2).
+
+The Implicit Grant flow is initiated by redirecting the user in an embedded web browser inside of your application to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders).
+
+After the user has authenticated, Auth0 will redirect the browser back to the `redirect_uri` (also known as the **Callback URL**), passing along an `id_token` parameter in the [hash fragment](https://en.wikipedia.org/wiki/Fragment_identifier) or the URL. The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on.
+
+The ID Token can be decoded to extract the claims and you can use these inside of your application, to display a user's name and profile image for example.
+
+![](/media/articles/client-auth/mobile-desktop/mobile-desktop-flow.png)
+
+1. The Application initiates the flow and redirects the user to the Authorization Server
+2. The user authenticates
+3. The Authorization Server redirects the user to the `redirect_uri` with an ID Token in the hash fragment
+4. The Application can now extract the token from the hash fragment.  
+
+## Register your Application
+
+The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication.
+
+Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button.
+
+The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Native** as the **Application Type** and click on the **Create** button to create the new application.
+
+![](/media/articles/client-auth/mobile-desktop/create-client.png)
+
+Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add the URL `https://${account.namespace}/mobile`. Save the Settings.
+
+![](/media/articles/client-auth/mobile-desktop/allowed-callback-url.png)
+
+## Call the Authorization URL
+
+The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication.
+
+This endpoint supports the following query string parameters:
+
+| Parameter | Description |
+|:------------------|:---------|
+| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For mobile applications using the Implicit Grant Flow this **must be set** to `token` |
+| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard |
+| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

    You can read up more about [scopes](/scopes). |
+| redirect_uri | The URL where the user will be redirected to after they have authenticated. For mobile applications you should specify this as `https://${account.namespace}/mobile`|
+| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `google-oauth2` to send the user directly to Google to log in with their Google account.

     If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application.  |
+| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) |
+
+::: note
+  Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}).
+:::
+
+## Handle the callback
+
+After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along the `id_token` and the `token_type` in the hash fragment of the URL, such as
+
+```text
+https://${account.namespace}/mobile#id_token=eyJ0...&token_type=Bearer
+```
+
+The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You can extract both of these values from the URL using basic string manipulation techniques in whatever programming language you are using.
+
+As mentioned, the ID Token is a JWT and you will need to decode this token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT.
+
+You can also refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token.
+
+Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata.
+
+### The ID Token Payload
+
+An example payload for an ID Token may look something like this:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "email": "jerrie@j...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+The payload above contains the following claims:
+
+| Parameter | Description |
+|:------------------|:---------|
+| name | The name of the user which is returned from the Identity Provider. |
+| email | The email address of the user which is returned from the Identity Provider. |
+| picture | The profile picture of the user which is returned from the Identity Provider. |
+| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. |
+| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+
+The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned.
+
+::: panel Debugging a JWT
+The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token.
+:::
+
+### Keep the user logged in
+
+Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can keep a global variable or a singleton object inside your application which will keep track of whether the user has logged in.
+
+You can also use this object to store information about the user (such as name, profile image, and so on.) and then use those inside of your application to display the user's information or otherwise personalize the user's experience.
+
+## Examples
+
+### A Basic Authentication Request
+
+The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=https://${account.namespace}/mobile
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment:
+
+```text
+https://${account.namespace}/mobile
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+And this is an example of the decoded payload of the ID Token which will be returned:
+
+```json
+{
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt9...",
+  "exp": 1478112929,
+  "iat": 1478076929
+}
+```
+
+### Request the Name and Profile Picture
+
+You can request a user's name and profile picture by requesting the `name` and `picture` scopes.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=https://${account.namespace}/mobile
+  &scope=openid%20name%20picture
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment:
+
+```text
+https://${account.namespace}/mobile
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token:
+
+```json
+{
+  "name": "jerrie@...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+### Request a User Log In With GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=https://${account.namespace}/mobile
+  &scope=openid%20name%20picture%20email
+  &connection=github
+```
+
+::: panel Log in with other social providers
+You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info:
+- [Identity Providers Supported by Auth0](/identityproviders)
+- [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `id_token` and `token_type` passed as parameters in the hash fragment:
+
+```text
+https://${account.namespace}/mobile
+  #id_token=eyJ0...
+  &token_type=Bearer
+```
+
+The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
+  "email": "jerrie@...",
+  "email_verified": true,
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
diff --git a/ja-jp/articles/application-auth/legacy/server-side-web.md b/ja-jp/articles/application-auth/legacy/server-side-web.md
new file mode 100644
index 0000000000..5cb0b0ac58
--- /dev/null
+++ b/ja-jp/articles/application-auth/legacy/server-side-web.md
@@ -0,0 +1,287 @@
+---
+title: Authentication for Server-side Web Apps
+description: Explains how to authenticate users in a Server-side Web application.
+toc: true
+topics:
+  - oauth2
+  - authentication
+  - server-side-apps
+contentType:
+    - concept
+    - how-to
+useCase:
+  - add-login
+---
+# Authentication for Server-side Web Apps
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version, using the dropdown. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+You can use the Auth0 Authentication API to create server-side web applications that uses OAuth 2.0 authorization to authenticate users.
+
+## Overview
+
+Auth0 exposes OAuth 2.0 endpoints for authenticating any user. You can redirect the user from your web application to these endpoints in the web browser. Auth0 will handle the authentication of the user, and then redirect the user back to the `redirect_uri` (also referred to as the Callback URL), returning an `authorization_code` in the query string parameters of the Callback URL. This `authorization_code` can then be exchanged for an ID Token which contains the identity of the user.
+
+## The Authentication Flow
+
+The OAuth 2.0 Authorization Framework allows for different kinds of authorization flows (called [Grant Types](https://tools.ietf.org/html/rfc6749#section-1.3)) depending on the type of application. The flow used for Server-side Web applications is known as the [Authorization Code flow](https://tools.ietf.org/html/rfc6749#section-1.3.1).
+
+The Authorization Code flow is initiated by redirecting the user in the web browser to the Auth0 `/authorize` endpoint. Auth0 will then display the Auth0 Lock dialog, allowing the user to enter their credentials or alternatively sign in with any other configured [Identity Provider](/identityproviders).
+
+After the user has authenticated, Auth0 will redirect the browser back to the **Redirect URI** (also called **Callback URL**), passing along an `authorization_code` parameter in the query string of the Callback URL. This code can then be exchanged for an ID Token by making a request to the `/oauth/token` endpoint.
+
+The ID Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) and contains various attributes - referred to as _Claims_ - regarding the user, such as the user's name, email address, profile picture and so on.. The ID Token can be decoded to extract the claims and you are free to use these inside of your application, to display a user's name and profile image for example.
+
+![](/media/articles/client-auth/server-side-web/server-side-web-flow.png)
+
+1. The Application initiates the flow and redirects the user to the Authorization Server.
+2. The user authenticates.
+3. The Authorization Server redirects to the `redirect_uri` with an `authorization_code` in the query string.
+4. The Application sends the `authorization_code` together with the `redirect_uri` and the Client Id/Client Secret to the Authorization Server.
+5. The Authorization Server validates this information and returns an ID Token.
+
+## Register your Application
+
+The first thing you need to do is to create a new application in Auth0. An Auth0 application maps to your application and allows it to use Auth0 for authentication.
+
+Navigate to the [Auth0 Dashboard](${manage_url}) and click on the [Applications](${manage_url}/#/applications) menu option on the left. Create a new Application by clicking on the **Create Application** button.
+
+The **Create Application** window will open, allowing you to enter the name of your new application. Choose **Regular Web Applications** as the **Application Type** and click on the **Create** button to create the new application.
+
+![](/media/articles/client-auth/server-side-web/create-client.png)
+
+Once the application has been created you can navigate to the **Settings** tab of the application and in the **Allowed Callback URLs** field add a URL where Auth0 must redirect to after the user has authenticated, such as `${account.callback}`.
+
+This URL must be part of your application, as your application will need to retrieve the `code` and exchange it for the ID Token.
+
+![](/media/articles/client-auth/server-side-web/allowed-callback-url.png)
+
+## Call the Authorization URL
+
+The URL used when authenticating a user is `https://${account.namespace}/authorize`. This is the initial endpoint to which a user must be redirected. This will handle checking whether any Single Sign-on (SSO) [session](/sessions) is active, authenticating the user and also potentially redirect the user directly to any Identity Provider to handle authentication.
+
+This endpoint supports the following query string parameters:
+
+| Parameter | Description |
+|:------------------|:---------|
+| response_type | The response type specifies the Grant Type you want to use. This can be either `code` or `token`. For server-side web applications using the Authorization Code Flow this **must be set** to `code` |
+| client_id | The Client ID of the Application you registered in Auth0. This can be found on the **Settings** tab of your Application in the Auth0 Dashboard |
+| scope | Specifies the claims (or attributes) of the user you want the be returned in the ID Token. To obtain an ID Token you need to specify at least a scope of `openid` (if no scope is specified then `openid` is implied). You can also request other scopes, so for example to return the user's name and profile picture you can request a scope of `openid name picture`.

    You can read up more about [scopes](/scopes). |
+| redirect_uri | The URL in your application where the user will be redirected to after they have authenticated, such as `${account.callback}`|
+| connection | This is an optional parameter which allows you to force the user to sign in with a specific connection. You can for example pass a value of `github` to send the user directly to GitHub to log in with their GitHub account.

     If this parameter is not specified the user will be presented with the normal Auth0 Lock screen from where they can sign in with any of the available connections. You can see the list of configured connections on the **Connections** tab of your application.  |
+| state | The state parameter will be sent back should be used for CSRF and contextual information (like a return url) |
+
+::: note
+  Be sure to add the **redirect_uri** URL to the list of **Allowed Callback URLs** in the **Settings** tab of your Application inside the [Auth0 Dashboard](${manage_url}).
+:::
+
+## Exchange the `access_code` for an ID Token
+
+After the user has authenticated, Auth0 will call back to the URL specified in the `redirect_uri` query string parameter which was passed to the `/authorize` endpoint. When calling back to this URL, Auth0 will pass along an `access_token` in the `code` query string parameter of the URL, such as
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You application will need to handle the request to this callback URL, extract the `access_code` from the `code` query string parameter and call the `/oauth/token` endpoint of the Auth0 Authentication API in order to exchange the `access_code` for the ID Token:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "https://${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+The response from `/oauth/token` contains an `access_token`, `id_token` and `token_type` values (and also potentially a `refresh_token`), for example:
+
+```json
+{
+  "access_token": "AP16...",
+  "id_token": "eyJ0...",
+  "token_type": "Bearer"
+}
+```
+
+The `token_type` will be set to **Bearer** and the `id_token` will be a [JSON Web Token (JWT)](/tokens/concepts/jwts) containing information about the user. You will need to decode the ID Token in order to read the claims (or attributes) of the user. The [JWT section of our website](/tokens/concepts/jwts) contains more information about the structure of a JWT.
+
+You can refer to the [libraries section on the JWT.io website](https://jwt.io/#libraries-io) in order to obtain a library for your programming language of choice which will assist you in decoding the ID Token.
+
+Once the JWT is decoded, you can extract the information about the user from the Payload of the ID Token. This is a JSON structure and will contain the claims (attributes) about the user as well as some other metadata.
+
+### The ID Token Payload
+
+An example payload for an ID Token may look something like this:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "email": "jerrie@j...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+The payload above contains the following claims:
+
+| Parameter | Description |
+|:------------------|:---------|
+| name | The name of the user which is returned from the Identity Provider. |
+| email | The email address of the user which is returned from the Identity Provider. |
+| picture | The profile picture of the user which is returned from the Identity Provider. |
+| sub | The unique identifier of the user. This is guaranteed to be unique per user and will be in the format (identity provider)|(unique id in the provider), such as github|1234567890. |
+| iss | The _issuer_. A case-sensitive string or URI that uniquely identifies the party that issued the JWT. For an Auth0 issued ID Token, this will be **the URL of your Auth0 tenant**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| aud | The _audience_. Either a single case-sensitive string or URI or an array of such values that uniquely identify the intended recipients of this JWT. For an Auth0 issued ID Token, this will be the **Client ID of your Auth0 Application**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| exp | The _expiration time_. A number representing a specific date and time in the format “seconds since epoch” as [defined by POSIX6](https://en.wikipedia.org/wiki/Unix_time). This claim sets the exact moment from which this **JWT is considered invalid**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+| iat | The _issued at time_. A number representing a specific date and time (in the same format as `exp`) at which this **JWT was issued**.

    **This is a [registered claim](https://tools.ietf.org/html/rfc7519#section-4.1) according to the JWT Specification** |
+
+The exact claims contained in the ID Token will depend on the `scope` parameter you sent to the `/authorize` endpoint. In an ID Token issued by Auth0, the **registered claims** and the `sub` claim will always be present, but the other claims depends on the `scope`. You can refer to the [examples below](#examples) to see examples of how the scope influences the claims being returned.
+
+::: note
+The [JWT.io website](https://jwt.io) has a handy debugger which will allow you to debug any JSON Web Token. This is useful is you quickly want to decode a JWT to see the information contained in the token.
+:::
+
+### Keep the user logged in
+
+Auth0 will assist you in authenticating a user, but it is up to you to keep track in your application of whether or not a user is logged in. You can use a cookie or other session storage to keep track of whether a user is logged in or not, and also to store the claims of the user which was extracted from the ID Token.
+
+You can then use those claims inside of your application to display the user's information or otherwise personalize the user's experience.
+
+## Examples
+
+### A Basic Authentication Request
+
+The following is the most basic request you can make to the `/authorize` endpoint. It will display the Lock screen and allow a user to sign in with any of the configured connections.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `access_code` for an ID Token. This is an example of the decoded payload of the ID Token which will be returned:
+
+```json
+{
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt9...",
+  "exp": 1478112929,
+  "iat": 1478076929
+}
+```
+
+### Request the Name and Profile Picture
+
+You can request a user's name and profile picture by requesting the `name` and `picture` scopes.
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20name%20picture
+```
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `access_code` for an ID Token. The name and profile picture will be available in the `name` and `picture` claims of the returned ID Token:
+
+```json
+{
+  "name": "jerrie@...",
+  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "auth0|581...",
+  "aud": "xvt...",
+  "exp": 1478113129,
+  "iat": 1478077129
+}
+```
+
+### Request a User Log In With GitHub
+
+You can send a user directly to the GitHub authentication screen by passing the value of **github** to the `connection` parameter. Note that we also request the `openid`, `name`, `picture` and `email` scopes:
+
+```text
+https://${account.namespace}/authorize
+  ?response_type=code
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &scope=openid%20name%20picture%20email
+  &connection=github
+```
+
+::: panel Log in with other social providers
+You can just as easily request a user log in with other social providers, like Google or Facebook. All you have to do is configure the corresponding connection in the [dashboard](${manage_url}/#/connections/social) and change the `connection` value of this call to `/authorize` with the name of the connection to use (`google-oauth2` for Google, `facebook` for Facebook, and so forth). You can get the connection's name from the _Settings_ of the connection in the [dashboard](${manage_url}/#/connections/social). For more info:
+- [Identity Providers Supported by Auth0](/identityproviders)
+- [Social Login using the Authentication API](/api/authentication#social)
+:::
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the ID Token and `token_type` passed as parameters in the hash fragment:
+
+After the user has authenticated, they will be redirected back to the `redirect_uri` with the `access_code` in the `code` query string parameter:
+
+```text
+${account.callback}?code=2OKj...
+```
+
+You can then exchange the `access_code` for an ID Token. The user's name and profile picture and email address will be available in the `name`, `picture` and `email` claims of the returned ID Token. You will also notice that the `sub` claim contains the User's unique ID returned from GitHub:
+
+```json
+{
+  "name": "Jerrie Pelser",
+  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
+  "email": "jerrie@...",
+  "email_verified": true,
+  "iss": "https://auth0pnp.auth0.com/",
+  "sub": "github|100...",
+  "aud": "xvt...",
+  "exp": 1478114742,
+  "iat": 1478078742
+}
+```
diff --git a/ja-jp/articles/applications/application-settings/_adv-settings-mobile.md b/ja-jp/articles/applications/application-settings/_adv-settings-mobile.md
new file mode 100644
index 0000000000..fb14954545
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_adv-settings-mobile.md
@@ -0,0 +1,8 @@
+
+#### Device Settings
+
+If you're developing a mobile application, you can provide the necessary iOS/Android parameters here.
+
+When developing iOS apps, you'll provide your **Team ID** and **App Bundle Identifier**.
+
+When developing Android apps, you'll provide your **App Package Name** and your **Key Hashes**.
diff --git a/ja-jp/articles/applications/application-settings/_adv-settings.md b/ja-jp/articles/applications/application-settings/_adv-settings.md
new file mode 100644
index 0000000000..f86aa43c4a
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_adv-settings.md
@@ -0,0 +1,25 @@
+
+
+The **Advanced Settings** section allows you to:
+
+* Manage or add Application Metadata, Mobile, OAuth, and WS-Federation settings 
+* Obtain certificates and token endpoint information
+* Set the grant type(s) for the Application
+
+![Advanced Application Settings Page](/media/articles/applications/advanced-settings.png)
+
+#### Application Metadata
+
+Application metadata are custom string keys and values (each of which has a character maximum of 255), set on a per application basis. Metadata is exposed in the Application object as client_metadata, and in Rules as context.clientMetadata
+
+You can create up to 10 sets of metadata.
+
+#### OAuth
+
+Set the OAuth-related settings on this tab:
+
+* By default, all apps/APIs can make a delegation request, but if you want to explicitly grant permissions to selected apps/APIs, you can do so in **Allowed Apps/APIs**.
+
+* Set the algorithm used (**HS256** or **RS256**) for signing your JSON Web Tokens.
+
+* Toggle the switch to indicate if your application is OIDC Conformant or not.
\ No newline at end of file
diff --git a/ja-jp/articles/applications/application-settings/_settings-pt2.md b/ja-jp/articles/applications/application-settings/_settings-pt2.md
new file mode 100644
index 0000000000..cbd497d7b3
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_settings-pt2.md
@@ -0,0 +1,17 @@
+::: note
+You can provide up to 100 URLs in the **Allowed Callback URLs**, **Allowed Web Origins**, **Allowed Logout URLs**, **Allowed Origins (CORS)** fields.
+:::
+
+- **Allowed Callback URLs**: Set of URLs to which Auth0 is allowed to redirect the users after they authenticate. You can specify multiple valid URLs by comma-separating them (typically to handle different environments like QA or testing). For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Make sure to specify the protocol, `http://` or `https://`, otherwise the callback may fail in some cases.
+
+- **Allowed Web Origins**: List of URLs from where an authorization request, using [`web_message` as the response mode](/protocols/oauth2#how-response-mode-works), can originate from. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost.
+
+- **Allowed Logout URLs**: After a user logs out from Auth0 you can redirect them with the `returnTo` query parameter. The URL that you use in `returnTo` must be listed here. You can specify multiple valid URLs by comma-separating them.  For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Notice that querystrings and hash information are not taken into account when validating these URLs. Read more about this at: [Logout](/logout).
+
+- **Allowed Origins (CORS)**: Set of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS). This prevents same-origin policy errors when using Auth0 from within a web browser. By default, all your callback URLs will be allowed. This field allows you to enter other origins if you need to. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (`*.google.com`). Notice that paths, querystrings and hash information are not taken into account when validating these URLs (and may, in fact, cause the match to fail).
+
+- **ID Token Expiration (seconds)**: The amount of time (in seconds) before the Auth0 ID Token expires. The default value is `36000` seconds which is 10 hours.
+
+- **Use Auth0 instead of the IdP to do Single Sign-on**: If enabled, this setting prevents Auth0 from redirecting authenticated users with valid [sessions](/sessions) to the identity provider (such as Facebook, ADFS, and so on). **Legacy tenants only.**
+
+![Application Settings Page](/media/articles/applications/settings.png)
diff --git a/ja-jp/articles/applications/application-settings/_settings.md b/ja-jp/articles/applications/application-settings/_settings.md
new file mode 100644
index 0000000000..7a276d13d1
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_settings.md
@@ -0,0 +1,17 @@
+
+
+- **Name**: The name of your application. This information is editable and you will see in the portal, emails, logs, and so on.
+
+- **Domain**: Your Auth0 tenant name. Note that the domain name is chosen when you create a new Auth0 tenant and cannot be changed. If you need a different one you have to register for a new tenant by selecting **+ Create Tenant** in the top right menu.
+
+- **Client ID**: The unique identifier for your application. This is the ID you will use with when configuring authentication with Auth0. It is generated by the system when you create a new application and it cannot be modified.
+
+- **Client Secret**: A string used to sign and validate ID Tokens for authentication flows and to gain access to select Auth0 API endpoints. By default, the value is hidden, so check the **Reveal Client Secret** box to see this value.
+
+  ::: warning
+  While the Client ID is considered public information, the Client Secret **must be kept confidential**. If anyone can access your Client Secret they can issue  tokens and access resources they shouldn't.
+  :::
+
+- **Description**: A free-text description of the Application's purpose with a maximum of 140 characters.
+
+- **Application Logo**: The URL to a logo (recommended size: 150x150 pixels) to be displayed for the application. This will appear in several areas, including the list of applications in the Dashboard, as well as things like customized consent forms.
diff --git a/ja-jp/articles/applications/application-settings/_token-endpoint-auth-method.md b/ja-jp/articles/applications/application-settings/_token-endpoint-auth-method.md
new file mode 100644
index 0000000000..be1b5f2d98
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_token-endpoint-auth-method.md
@@ -0,0 +1,3 @@
+
+
+- **Token Endpoint Authentication Method**: Defines the requested authentication method for the token endpoint. Possible values are `None` (public client without a client secret), `Post` (client uses HTTP POST parameters) or `Basic` (client uses HTTP Basic).
\ No newline at end of file
diff --git a/ja-jp/articles/applications/application-settings/_trust-token-endpoint-ip-header.md b/ja-jp/articles/applications/application-settings/_trust-token-endpoint-ip-header.md
new file mode 100644
index 0000000000..9f1da28c81
--- /dev/null
+++ b/ja-jp/articles/applications/application-settings/_trust-token-endpoint-ip-header.md
@@ -0,0 +1,3 @@
+
+
+* Toggle the **Trust Token Endpoint IP Header** setting; if this is enabled, the `auth0-forwarded-for` is set as trusted and used as a source of end user IP information for protection against brute-force attacks on the token endpoint.
diff --git a/ja-jp/articles/applications/concepts/app-types-confidential-public.md b/ja-jp/articles/applications/concepts/app-types-confidential-public.md
new file mode 100644
index 0000000000..8a5e97d787
--- /dev/null
+++ b/ja-jp/articles/applications/concepts/app-types-confidential-public.md
@@ -0,0 +1,63 @@
+---
+description: Understand the difference between confidential and public application types.
+toc: true
+topics:
+  - applications
+  - application-types
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Confidential and Public Applications
+
+According to the [OAuth 2.0 spec](https://tools.ietf.org/html/rfc6749#section-2.1), applications can be classified as either confidential or public. The main difference relates to whether or not the application is able to hold credentials (such as a client ID and secret) securely.
+
+When you create an application using the Dashboard, Auth0 will ask you what [Auth0 application type](/applications) you want to assign to the new application and use that information to determine whether the application is confidential or public. 
+
+To check whether your application is confidential or public, see [View Application Type: Confidential or Public](/dashboard/guides/applications/view-app-type-confidential-public).
+
+## Confidential applications
+
+Confidential applications can hold credentials in a secure way without exposing them to unauthorized parties. They require a trusted backend server to store the secret(s).
+
+### Grant types
+
+Because they use a trusted backend server, confidential applications can use grant types that require them to authenticate by specifying their client ID and secret when calling the token endpoint.
+
+The following are considered to be confidential applications:
+
+* A web application with a secure backend that uses the [Authorization Code Flow](/flows/concepts/auth-code), [Password grant](/api-auth/grant/password), or [Password grant with Realm support](/api-auth/tutorials/password-grant#realm-support)
+* A machine-to-machine (M2M) application that uses the [Client Credentials Flow](/flows/concepts/client-credentials)
+
+### ID Tokens
+
+Because confidential applications are capable of holding secrets, you can have ID Tokens issued to them that have been signed in one of two ways:
+
+* Symmetrically, using their client secret (`HS256`)
+* Asymmetrically, using a private key (`RS256`)
+
+## Public applications
+
+Public applications **cannot** hold credentials securely.
+
+### Grant types
+
+Public applications can only use grant types that do not require the use of their client secret. 
+
+The following are public applications:
+
+* A native desktop or mobile application that uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce)
+* A JavaScript-based client-side web application (such as a single-page app) that uses the [Implicit Flow](/flows/concepts/implicit) grant
+
+### ID Tokens
+
+Because public applications are unable to hold secrets, [ID Tokens](/tokens/concepts/id-tokens) issued to them must be:
+
+* Signed asymmetrically using a private key (`RS256`)
+* Verified using the public key corresponding to the private key used to sign the token
+
+## Keep reading
+
+* [View Application Type](/dashboard/guides/applications/view-app-type-confidential-public)
+* [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party)
+* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping)
diff --git a/ja-jp/articles/applications/concepts/app-types-first-third-party.md b/ja-jp/articles/applications/concepts/app-types-first-third-party.md
new file mode 100644
index 0000000000..1412c22625
--- /dev/null
+++ b/ja-jp/articles/applications/concepts/app-types-first-third-party.md
@@ -0,0 +1,43 @@
+---
+description: Understand the difference between confidential and public application types.
+topics:
+  - applications
+  - application-types
+contentType: concept
+useCase:
+  - build-an-app
+---
+# First-Party and Third-Party Applications
+
+Applications can be classified as either first-party or third-party, which refers to the ownership of the application. The main difference relates to who has administrative access to your Auth0 domain.
+
+## First-party applications
+
+First-party applications are those controlled by the same organization or person who owns the Auth0 domain. For example, let's say you created both a Contoso API and an application that logs into `contoso.com` and consumes the Contoso API. You would register both the API and application under the same Auth0 domain, and the application would be a first-party application. By default, all applications created via the [Auth0 Dashboard](${manage_url}/#/applications) are first-party applications.
+
+## Third-party applications
+
+Third-party applications are controlled by someone who most likely should *not* have administrative access to your Auth0 domain. Third-party applications enable external parties or partners to securely access protected resources behind your API. An example of this is with Facebook, let's say you created an application to get a client ID and secret to integrate with your service. That application is considered third-party because it is not owned by Facebook but a third-party that wants to integrate with Facebook APIs and services. 
+
+::: note
+All applications created through [Dynamic Client Registration](/api-auth/dynamic-client-registration) will be third-party.
+
+Third-party applications cannot be created using the Dashboard, but must be created through the [Auth0 Management API](/api/management/v2#!/Clients/post_clients) by setting `is_first_party` to `false`.
+:::
+
+Third-party applications have the following unique characteristics:
+
+- **User Consent**: You must require user consent when consuming APIs because anyone can create an application. Requiring the user to provide consent improves security.
+
+- **ID Tokens**: [ID Tokens](/tokens/concepts/id-tokens) generated for third-party applications hold only minimum user profile information.
+
+- **Connections**: You can only use tenant-level connections or *domain connections*. For more informations, see [Enable Third-party Applications](/applications/guides/enable-third-party-apps).
+
+## Keep reading
+
+* [View Application Ownership](/api/management/guides/applications/view-ownership)
+* [Applications](/applications)
+* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public)
+* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping)
+* [User consent and third-party applications](/api-auth/user-consent)
+ 
\ No newline at end of file
diff --git a/ja-jp/articles/applications/concepts/application-grant-types.md b/ja-jp/articles/applications/concepts/application-grant-types.md
new file mode 100644
index 0000000000..76ced1103e
--- /dev/null
+++ b/ja-jp/articles/applications/concepts/application-grant-types.md
@@ -0,0 +1,32 @@
+---
+title: Application Grant Types
+description: Learn about the concept of grant types and how they relate to applications.
+topics:
+  - applications
+  - grant-types
+contentType: 
+  - concept
+useCase:
+  - build-an-app
+---
+# Application Grant Types
+
+Application grant types (or _flows_) are methods through which applications can gain [Access Tokens](/tokens/concepts/access-tokens) and by which you grant limited access to your resources to another entity without exposing credentials. The [OAuth 2.0 protocol](/protocols/oauth2) supports several types of grants, which allow different types of access.
+
+Based on the needs of your application, some grant types are more appropriate than others. Auth0 provides many different authentication and authorization flows and allows you to indicate which grant types are appropriate based on the `grant_types` property of your Auth0-registered Application.
+
+For example, let's say you are securing a mobile app. In this case, you'd use the [Authorization Code using Proof Key for Code Exchange (PKCE) Grant](/flows/concepts/auth-code-pkce).
+
+Alternatively, if you were securing a client-side app (such as a single-page app), you'd use the [Implicit Grant](/flows/concepts/implicit).
+
+::: note
+Not sure which grant type is appropriate for your use case? Refer to [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use) for help.
+:::
+
+## Keep Reading
+
+* [Available Grant Types](/applications/reference/grant-types-available)
+* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping)
+* [Update Grant Types Using the Dashboard](/dashboard/guides/applications/update-grant-types)
+* [Update Grant Types Using the Management API](/api/management/guides/applications/update-grant-types)
+* [Legacy Grant Types](/applications/concepts/grant-types-legacy)
diff --git a/ja-jp/articles/applications/concepts/client-secret.md b/ja-jp/articles/applications/concepts/client-secret.md
new file mode 100644
index 0000000000..3c97f7efa3
--- /dev/null
+++ b/ja-jp/articles/applications/concepts/client-secret.md
@@ -0,0 +1,17 @@
+---
+title: Client Secret
+description: Learn about client secrets.
+topics:
+  - applications
+  - client-secrets
+contentType: 
+  - concept
+useCase:
+  - build-an-app
+---
+
+# Client Secret
+
+A client secret is a secret known only to your application and the authorization server. It protects your resources by only granting [tokens](/tokens) to authorized requestors. 
+
+Protect your client secrets and never include them in mobile or browser-based apps. If your client secret is ever compromised, you should [rotate to a new one](/dashboard/guides/applications/rotate-client-secret) and update all authorized apps with the new client secret.
\ No newline at end of file
diff --git a/ja-jp/articles/applications/concepts/grant-types-legacy.md b/ja-jp/articles/applications/concepts/grant-types-legacy.md
new file mode 100644
index 0000000000..795ad11152
--- /dev/null
+++ b/ja-jp/articles/applications/concepts/grant-types-legacy.md
@@ -0,0 +1,36 @@
+---
+title: Legacy Grant Types
+description: Learn about legacy grant types and more secure alternatives.
+topics:
+  - applications
+  - client-secrets
+contentType: concept
+useCase:
+  - build-an-app
+---
+
+# Legacy Grant Types
+
+Legacy grant types are traditional grant types supported for legacy customers only. If you are a legacy customer, we highly recommend moving to a more secure alternative.
+
+::: warning 
+As of 8 June 2017, all Auth0 Applications were given a `grant_types` property that **must** be populated. To avoid changes in functionality for Auth0 customers at that time, we populated the `grant_types` property for all existing Applications with **all** Auth0 legacy, Auth0 extension, and specification-conforming grant types.
+
+At this time, new Auth0 customers were no longer able to add legacy grant types to their applications. Legacy grant types are only available for previous customers while they migrate to new flows, to avoid breaking changes. If you were a customer prior to 8 June 2017, you can [use the Dashboard](/dashboard/guides/applications/update-grant-types) or [use the Management API](/api/management/guides/applications/update-grant-types) to enable a legacy grant type.
+:::
+
+## Secure Alternatives
+
+If you're currently using a legacy grant type, refer to the chart below to see which of the secure alternatives you should use instead.
+
+| Legacy Grant Type | Alternative |
+|:-----|:----|
+|`http://auth0.com/oauth/legacy/grant-type/ro` | Use the [/oauth/token](/api/authentication#authorization-code) endpoint with a grant type of `password`. See [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password) and [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant) for additional information. |
+| `http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer` | This feature is disabled by default. If you would like this feature enabled, please [contact support](https://support.auth0.com/) to discuss your use case and prevent the possibility of introducing security vulnerabilities. |
+| `http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token` | Use the `oauth/token` endpoint to obtain Refresh Tokens. See [OIDC-conformant Refresh Tokens](/api-auth/tutorials/adoption/refresh-tokens) for more info. |
+| `http://auth0.com/oauth/legacy/grant-type/delegation/id_token` | This feature is disabled by default. If you would like this feature enabled, please [contact support](https://support.auth0.com/) to discuss your use case and prevent the possibility of introducing security vulnerabilities. |
+| `http://auth0.com/oauth/legacy/grant-type/access_token` | Use browser-based social authentication. |
+
+::: note
+Those implementing Passwordless Authentication should use [Universal Login](/universal-login) instead of the `oauth/ro` endpoint.
+:::
diff --git a/ja-jp/articles/applications/guides/enable-third-party-apps.md b/ja-jp/articles/applications/guides/enable-third-party-apps.md
new file mode 100644
index 0000000000..bcd3c1712c
--- /dev/null
+++ b/ja-jp/articles/applications/guides/enable-third-party-apps.md
@@ -0,0 +1,91 @@
+---
+title: Enable Third-Party Applications
+description: Learn how to enable third-party applications for your tenant.
+topics:
+  - applications
+  - application-types
+  - third-party-applications
+contentType: 
+  - how-to
+useCase:
+  - build-an-app
+---
+# Enable Third-Party Applications
+  
+You can enable third-party applications for your tenant. See [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) for details on the differences between the two types of applications. 
+
+1. [Update your application's ownership to third-party](/api/management/guides/applications/update-ownership) in Auth0.
+
+    By default, applications registered in Auth0 are first-party applications. If you want your application to be a third-party application, you must update its ownership.
+
+2. [Promote the connections you will use with third-party applications to domain level](/api/management/guides/connections/promote-connection-domain-level) in Auth0.
+
+    Third-party applications can only authenticate users from [connections](/connections) flagged as domain-level connections. Domain-level connections can be enabled for selected first-party applications while also being open to all third-party application users for authentication.
+    
+3. Update your application's login page. If you use [Lock](/libraries/lock/v11) in the [Universal Login Page](/universal-login/classic), you must also:
+
+  - Upgrade to Lock version 11 or later
+  - Set the `__useTenantInfo: config.isThirdPartyClient` flag when instantiating Lock
+  - *For [Private Cloud](/private-cloud) users only*: Set the [`configurationBaseUrl` option](https://auth0.com/docs/libraries/lock/v11/configuration#configurationbaseurl-string-) to `https://{config.auth0Domain}/` when instantiating Lock
+
+## Access Token `current_user_*` scopes 
+
+Neither first- nor third-party applications can use [ID Tokens](/tokens/concepts/id-tokens) to invoke [Management API](/api/management/v2) endpoints. Instead, they should get [Access Tokens](/api/management/v2/tokens) with the following `current_user_*` scopes required by each endpoint:
+
+| Scope | Endpoint |
+| - | - |
+| `read:current_user` | [List or search users](/api/management/v2#!/Users/get_users) |
+|  | [Get a user](/api/management/v2#!/Users/get_users_by_id) |
+|  | [Get user MFA enrollments](/api/management/v2#!/Users/get_enrollments) |
+| `update:current_user_metadata` | [Update a user](/api/management/v2#!/Users/patch_users_by_id) |
+|  | [Delete a user's multi-factor provider](/api/management/v2#!/Users/delete_multifactor_by_provider) |
+| `create:current_user_device_credentials` | [Create a device public key](/api/management/v2#!/Device_Credentials/post_device_credentials) |
+| `delete:current_user_device_credentials` | [Delete a device credential](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) |
+| `update:current_user_identities` | [Link a user account](/api/management/v2#!/Users/post_identities) |
+|  | [Unlink a user identity](/api/management/v2#!/Users/delete_user_identity_by_user_id) |
+
+## Sample script
+
+```html
+ 
+...
+
+```
+
+## Keep reading
+* [View Application Ownership](/api/management/guides/applications/view-ownership)
+* [Applications](/applications)
+* [Confidential and Public Applications](/applications/concepts/app-types-confidential-public)
+* [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping)
+* [User consent and third-party applications](/api-auth/user-consent)
diff --git a/ja-jp/articles/applications/index.md b/ja-jp/articles/applications/index.md
new file mode 100644
index 0000000000..2f3bf9a89a
--- /dev/null
+++ b/ja-jp/articles/applications/index.md
@@ -0,0 +1,52 @@
+---
+description: Understand the basics of creating and using Auth0 Applications.
+topics:
+  - applications
+contentType: 
+    - concept
+useCase:
+  - build-an-app
+---
+# Applications in Auth0
+
+The term *application* or *app* in Auth0 does not imply any particular implementation characteristics. For example, it could be a native app that executes on a mobile device, a single-page app that executes on a browser, or a regular web app that executes on a server.
+
+Auth0 categorizes apps based on these characteristics:
+
+* **What type of app is it?**: To add authentication to your app, you must register it in the Auth0 Dashboard and select from one of the following app types: 
+  - [Regular web app](/dashboard/guides/applications/register-app-regular-web): Traditional web apps that perform most of their application logic on the server (such as Express.js or ASP.NET).
+  - [Single-page app (SPA)](/dashboard/guides/applications/register-app-spa): JavaScript apps that perform most of their user interface logic in a web browser, communicating with a web server primarily using APIs (such as AngularJS + Node.js or React).
+  - [Native app](/dashboard/guides/applications/register-app-native): Mobile or Desktop apps that run natively in a device (such as iOS or Android).
+  - [Machine-to-machine (M2M) app](/dashboard/guides/applications/register-app-m2m): Non-interactive apps, such as command-line tools, daemons, IoT devices, or services running on your back-end. Typically, you use this option if you have a service that requires access to an API.
+
+* **Can the app securely hold credentials?**: According to the [OAuth 2.0 spec](https://tools.ietf.org/html/rfc6749#section-2.1), apps can be classified as either *public* or *confidential*; confidential apps can hold credentials securely, while public apps cannot. See [Confidential and Public Applications](/applications/concepts/app-types-confidential-public) for details.
+
+* **Who owns the app?**: Whether an app is classified as first- or third-party depends on the app ownership and control. First-party apps are controlled by the same organization or person that owns the Auth0 domain. Third-party apps enable external parties or partners to securely access protected resources behind your API. See [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party) for details.
+
+## Manage app settings
+
+You register apps on the [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings) page. See [Application Settings](/dashboard/reference/settings-application) for details.
+
+In addition to setting up apps in the Dashboard, you can also set up apps programmatically as described in the [OpenID Connect (OIDC) Dynamic Client Registration 1.0 ](https://openid.net/specs/openid-connect-registration-1_0.html) specification. See [Dynamic Client Registration](/api-auth/dynamic-client-registration) for details.
+
+::: panel Multi-Tenancy
+You can set up up a more complex configuration that allows users to log in differently for different apps. See [Using Auth0 to Secure Your Multi-Tenant Applications](/design/using-auth0-with-multi-tenant-apps) and [Create Multiple Tenants](/dashboard/guides/tenants/create-multiple-tenants).
+:::
+
+By default, Auth0 enables all connections associated with your tenant when you create a new application. To change this, [update application connections](/dashboard/guides/applications/update-app-connections) in the Application Settings in the Dashboard.
+
+## Monitor apps
+
+You can [monitor apps](/monitoring/guides/monitor-applications) and perform end-to-end testing using your own tests. Auth0 stores [log data](/logs) including Dashboard administrator actions, successful and failed user authentications, and password change requests. You can use Auth0 [Extensions](/extensions) to export your log data and use tools like Sumo Logic, Splunk, or Loggly to analyze and store your log data. 
+
+## Remove apps
+
+You can [remove an application using the Auth0 Dashboard](/dashboard/guides/applications/remove-app) or the [Management API](/api/management/guides/applications/remove-app).
+
+## Manage client secrets
+
+You can [rotate an app's Client Secret](/dashboard/guides/applications/rotate-client-secret) using the Auth0 Dashboard or the [Management API](/api/management/guides/applications/rotate-client-secret).
+
+## Grant types
+
+Auth0 provides many different authentication and authorization grant types or *flows* and allows you to indicate which grant types are appropriate based on the `grant_types` property of your Auth0-registered app. See [Application Grant Types](/applications/concepts/application-grant-types) for more details.
diff --git a/ja-jp/articles/applications/reference/grant-types-auth0-mapping.md b/ja-jp/articles/applications/reference/grant-types-auth0-mapping.md
new file mode 100644
index 0000000000..d0808c59d3
--- /dev/null
+++ b/ja-jp/articles/applications/reference/grant-types-auth0-mapping.md
@@ -0,0 +1,61 @@
+---
+title: Auth0 Grant Types Mapping
+description: Learn which grant types are available to which application types with Auth0.
+toc: true
+topics:
+  - applications
+  - application-types
+  - grant-types
+contentType: reference
+useCase:
+  - build-an-app
+---
+
+# Auth0 Grant Types Mapping
+
+When registered, Auth0 Applications have access to different grant types based on [application](/applications) type. The biggest deciding factor is whether the application is [confidential or public](/applications/concepts/app-types-confidential-public).
+
+Additionally, trusted first-party applications have access to additional grant types.
+
+## Public applications
+
+When a **Native App** or **Single-Page App** is registered in the Dashboard, it is automatically flagged as a public application, which is indicated by a `token_endpoint_auth_method` flag set to `none`.
+
+By default, Auth0 creates public applications with the following `grant_types` enabled:
+
+* `implicit`
+* `authorization_code`
+* `refresh_token`
+
+**Native Apps** can also use the `device_code` grant type.
+
+::: note
+Public applications **cannot** use the `client_credentials` grant type. To use this grant type, you must indicate that the application is confidential rather than public. Use the [Management API](/api/management/v2#!/Clients/patch_clients_by_id) to set the **token_endpoint_auth_method** to `client_secret_post` or `client_secret_basic`.
+:::
+
+## Confidential applications
+
+When a **Regular Web App** or **Machine-to-Machine (M2M) App** is registered in the Dashboard, it is automatically flagged as a confidential application, which is indicated by a `token_endpoint_auth_method` flag set to anything *except* `none`. 
+
+By default, Auth0 creates confidential applications with the following `grant_types` enabled:
+
+* `implicit`
+* `authorization_code`
+* `refresh_token`
+* `client_credentials`
+
+## Trusted first-party applications
+
+Trusted first-party applications have the same `grant_types` enabled as confidential applications, plus the following:
+
+* `password`
+* `http://auth0.com/oauth/grant-type/password-realm`
+* `http://auth0.com/oauth/grant-type/mfa-oob`
+* `http://auth0.com/oauth/grant-type/mfa-otp`
+* `http://auth0.com/oauth/grant-type/mfa-recovery-code`
+
+::: note
+If you are using the [Dashboard](${manage_url}) to enable or disable these grant types, be aware that all the Password and MFA grant types are enabled when you add the `Password` or `MFA` grant type to your Application. You cannot select them individually.
+:::
+
+For more info about first-party and third-party applications, see [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party).
diff --git a/ja-jp/articles/applications/reference/grant-types-available.md b/ja-jp/articles/applications/reference/grant-types-available.md
new file mode 100644
index 0000000000..f4f2946b74
--- /dev/null
+++ b/ja-jp/articles/applications/reference/grant-types-available.md
@@ -0,0 +1,55 @@
+---
+title: Available Grant Types
+description: Learn which grant types are available with Auth0.
+toc: true
+topics:
+  - applications
+  - grant-types
+contentType: reference
+useCase:
+  - build-an-app
+---
+# Available Grant Types
+
+Various grant types are valid when registering Auth0 Applications. These can be divided into the following categories:
+ 
+* **[Spec-conforming grants](#spec-conforming-grants)**: Grants defined by and conforming to external specifications (such as OpenID Connect (OIDC)).
+* **[Auth0 extension grants](#auth0-extension-grants)**: Auth0-specific grants that conform to the [OAuth extension mechanism](https://tools.ietf.org/html/rfc6749#section-4.5) to support additional clients or to provide a bridge between OAuth and other trust frameworks.
+* **[Auth0 legacy grants](#auth0-legacy-grants)**: Traditional grant types supported for legacy customers only. If you are a legacy customer, we highly recommend moving to a more secure alternative. For info on working with legacy grant types and their alternatives, see [Legacy Grant Types](/applications/concepts/grant-types-legacy).
+
+## Spec-conforming grants
+
+| `grant_type` | More info |
+|:-----|:----|
+| `implicit` | [Implicit Grant](/flows/concepts/implicit) |
+| `authorization_code` | [Authorization Code Grant](/flows/concepts/auth-code) |
+| `client_credentials` | [Client Credentials Grant](/flows/concepts/client-credentials) |
+| `password` | [Resource Owner Password Grant](/api-auth/grant/password) |
+| `refresh_token` | [Use Refresh Tokens](/tokens/guides/use-refresh-tokens) |
+|  `urn:ietf:params:oauth:grant-type:device_code` | [Device Authorization Grant](/flows/concepts/device-auth) |
+
+## Auth0 extension grants
+
+| `grant_type` | More info |
+|:-----|:----|
+| `http://auth0.com/oauth/grant-type/password-realm` | [Use an extension grant similar to the Resource Owner Password Grant that includes the ability to indicate a specific realm](/api-auth/grant/password#realm-support) |
+| `http://auth0.com/oauth/grant-type/mfa-oob` | [Multi-factor Authentication OOB Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-oob-grant-request) |
+| `http://auth0.com/oauth/grant-type/mfa-otp` | [Multi-factor Authentication OTP Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-otp-grant-request) |
+| `http://auth0.com/oauth/grant-type/mfa-recovery-code` | [Multi-factor Authentication Recovery Grant Request](/mfa/guides/mfa-api/multifactor-resource-owner-password#mfa-recovery-grant-request) |
+| `http://auth0.com/oauth/grant-type/passwordless/otp` | [Embedded Passwordless Login Grant Request](/connections/passwordless#implementing-login) |
+
+## Auth0 legacy grants
+
+Legacy grants include:
+
+* `http://auth0.com/oauth/legacy/grant-type/ro`
+* `http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer`
+* `http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token`
+* `http://auth0.com/oauth/legacy/grant-type/delegation/id_token`
+* `http://auth0.com/oauth/legacy/grant-type/access_token`
+
+For info on working with legacy grant types and their alternatives, see [Legacy Grant Types](/applications/concepts/grant-types-legacy).
+
+## Keep reading
+
+* To learn which grant types are enabled for different application types, see [Auth0 Grant Types Mapping](/applications/reference/grant-types-auth0-mapping).
diff --git a/ja-jp/articles/applications/reference/wildcard-subdomains.md b/ja-jp/articles/applications/reference/wildcard-subdomains.md
new file mode 100644
index 0000000000..74f968b6d1
--- /dev/null
+++ b/ja-jp/articles/applications/reference/wildcard-subdomains.md
@@ -0,0 +1,35 @@
+---
+title: Wildcards for Subdomains
+description: Describes wildcards for subdomains function in application configuration.
+toc: true
+topics:
+  - applications
+contentType: reference
+useCase:
+  - build-an-app
+---
+# Wildcards for Subdomains
+
+You can use wildcards for subdomain URL registration in your application configuration in the Dashboard with these fields:
+
+* **Allowed Callback URLs**: Set of URLs to which Auth0 is allowed to redirect users after they authenticate.
+* **Allowed Logout URLs**: List of URLs to which you can redirect users after they log out from Auth0.
+* **Allowed Origins (CORS)**: Set of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS).
+
+::: warning
+Avoid using wildcards for subdomains in application callbacks and allowed origins as it can make your application vulnerable to attacks. See [Application Settings Best Practices](/best-practices/application-settings) for this and other recommended settings.
+:::
+
+You can use the star symbol (`*`) as a wildcard for subdomains, but it must be used in accordance with the following rules in order to properly function:
+
+* The protocol of the URL **must** be `http:` or `https:`. `com.example.app://*.example.com` will not work.
+
+* The wildcard **must** be located in a subdomain within the hostname component. `https://*.com` will not work.
+
+* The wildcard **must** be located in the subdomain furthest from the root domain. `https://sub.*.example.com` will not work.
+
+* The URL **must not** contain more than one wildcard. `https://*.*.example.com` will not work.
+
+* A wildcard **may** be prefixed and/or suffixed with additional valid hostname characters. `https://prefix-*-suffix.example.com` will work.
+
+* A URL with a valid wildcard **will not** match a URL more than one subdomain level in place of the wildcard. `https://*.example.com` will not work with `https://sub1.sub2.example.com`.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md b/ja-jp/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md
new file mode 100644
index 0000000000..7c95f9b91b
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_api-authentication-and-authorization.md
@@ -0,0 +1,44 @@
+## API Authentication and Authorization
+
+An API is a way to expose functionality of your application to other applications. An application can make a request by sending a message to an endpoint on an API and receive information as a response.
+
+An API endpoint can be secured or not. In our case, since the timesheets are sensitive information that affect reviews and payments, it is important to ensure that only authorized users and applications can call the endpoints on our API. When a client application wants to access protected endpoints on an API, it needs to present an Access Token as proof that it has the required permissions for making the call to the endpoint.
+
+An Access Token is obtained by authenticating the user with an Authorization Server and the user can then, in turn, authorize the application to access the API on their behalf.
+
+::: panel What is an Access Token?
+An Access Token (also referred to as `access_token`) is an opaque string representing an authorization issued to the application. It may denote an identifier used to retrieve the authorization information or may self-contain the authorization information (for example, the user's identity, permissions, and so forth) in a verifiable manner.
+
+It is quite common for Access Tokens to be implemented as [JSON Web Tokens](/tokens/concepts/jwts).
+
+For more information on Auth0 Access Tokens refer to [Access Token](/tokens/concepts/access-tokens).
+:::
+
+An API can enforce fine-grained control over who can access the various endpoints exposed by the API. These permissions are expressed as scopes.
+
+When a user authorizes a client application, the application can also indicate which permissions it requires. The user is then allowed to review and grant these permissions. These permissions are then included in the Access Token as part of the `scope` claim.
+
+Subsequently, when the client passes along the Access Token when making requests to the API, the API can inspect the `scope` claim to ensure that the required permissions were granted in order to call the particular API endpoint.
+
+::: panel What are Scopes?
+Each Access Token may include a list of the permissions that have been granted to the client. When a client authenticates with Auth0, it will specify the list of scopes (or permissions) it is requesting. If those scopes are authorized, then the Access Token will contain a list of authorized scopes.
+
+For example, the timesheet API may accept four different levels of authorization: reading timesheets (scope `read:timesheets`), creating timesheets (scope `create:timesheets`), deleting timesheets (scope `delete:timesheets`) and approving timesheets (scope `approve:timesheets`).
+
+When a client asks the API to create a new timesheet entry, then the Access Token should contain the `create:timesheets` scope. In a similar fashion, in order to delete existing timesheets, the Access Token should contain the `delete:timesheets` scope.
+
+For more information on scopes refer to [Scopes](/scopes).
+:::
+
+By using the OAuth 2.0 authorization framework, you can give your own applications or third-party applications limited access to your APIs on behalf of the application itself. Using Auth0, you can easily support different flows in your own APIs without worrying about the OAuth 2.0/OpenID Connect (OIDC) specification, or the many other technical aspects of API authorization.
+
+::: panel OAuth Roles
+In any OAuth 2.0 flow we can identify the following roles:
+
+- __Resource Owner__: the entity that can grant access to a protected resource. Typically this is the end-user.
+- __Resource Server__: the server hosting the protected resources. This is the API you want to access.
+- __Client__: an application requesting access to a protected resource on behalf of the Resource Owner.
+- __Authorization Server__: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
+
+Using [different grants types (or flows)](/api-auth/which-oauth-flow-to-use), these participants will interact to grant to the client apps limited access to the APIs you are building. As a result, the client app will obtain an Access Token that can be used to call the API on behalf of the user.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_api-configure-scopes.md b/ja-jp/articles/architecture-scenarios/_includes/_api-configure-scopes.md
new file mode 100644
index 0000000000..148a374c9a
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_api-configure-scopes.md
@@ -0,0 +1,7 @@
+### Configure the Permissions
+
+Once the application has been created you will need to configure the Permissions which applications can request during authorization.
+
+In the settings for your API, go to the **Permissions** tab. In this section you can add all four of the scopes which were discussed before, namely `read:timesheets`, `create:timesheets`, `delete:timesheets`, `approve:timesheets`.
+
+![Add Scopes](/media/articles/architecture-scenarios/mobile-api/add-permissions.png)
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_api-implement.md b/ja-jp/articles/architecture-scenarios/_includes/_api-implement.md
new file mode 100644
index 0000000000..3a217a0af4
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_api-implement.md
@@ -0,0 +1,67 @@
+In this section we will see how we can implement an API for our scenario.
+
+::: note
+For simplicity reasons we will keep our implementation solely focused on the authentication and authorization part. As you will see in the samples the input timesheet entry will be hard-coded and the API will not persist the timesheet entry, simply echo back some of the info.
+:::
+
+## Define the API endpoints
+
+First we need to define the endpoints of our API.
+
+::: panel What is an API endpoint?
+An **API endpoint** is a unique URL that represents an object. In order to interact with this object you need to point your application towards that URL. For example, if you had an API that could return either order or customers, you might configure two endpoints: `/orders` and `/customers`. Your client would interact with these endpoints using different HTTP methods, for example `POST /orders` to create a new order, or `GET /orders` to retrieve the dataset of one or more orders.
+:::
+
+For this implementation we will only define two endpoints; one for retrieving a list of all timesheets for an employee, and another which will allow an employee to create a new timesheet entry.
+
+An `HTTP GET` request to the `/timesheets` endpoint will allow a user to retrieve their timesheets, and an `HTTP POST` request to the `/timesheets` endpoint will allow a user to add a new timesheet.
+
+::: note
+See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#1-define-the-api-endpoints)
+:::
+
+### Secure the Endpoints
+
+When an API receives a request with a bearer Access Token as part of the header, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request must be rejected with a `Missing or invalid token` error message to the calling app.
+
+The validations that the API should perform are:
+
+- Check that the JWT is well formed
+- Check the signature
+- Validate the standard claims
+
+::: note
+[JWT.io](https://jwt.io/) provides a list of libraries that can do most of the work for you: parse the JWT, verify the signature and the claims.
+:::
+
+Part of the validation process is to also check the Client permissions (scopes), but we will address this separately in the next paragraph of this document.
+
+For more information on validating Access Tokens, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+::: note
+See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#2-secure-the-api-endpoints)
+:::
+
+### Check the Client's Permissions
+
+By now we have verified that the JWT is valid. The last step is to verify that the client has the permissions required to access the protected resources.
+
+To do so, the API needs to check the [scopes](/scopes) of the decoded JWT. This claim is part of the payload and it is a space-separated list of strings.
+
+::: note
+See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#3-check-the-client-permissions)
+:::
+
+### Determine user identity
+
+For both endpoints (retrieving the list of timesheets, and adding a new timesheet) we will need to determine the identity of the user.
+
+For retrieving the list of timesheets this is to ensure that we only return the timesheets belonging to the user making the request, and for adding a new timesheet this is to ensure that the timesheet is associated with the user making the request.
+
+One of the standard JWT claims is the `sub` claim which identifies the principal that is the subject to the claim. In the case of the Implicit Grant flow this claim will contain the user's identity, which will be the unique identifier for the Auth0 user. You can use this to associate any information in external systems with a particular user.
+
+You can also use a custom claim to add another attribute of the user - such as their email address - to the Access Token and use that to uniquely identify the user.
+
+::: note
+See the implementation in [Node.js](/architecture-scenarios/application/mobile-api/api-implementation-nodejs#4-determine-the-user-identity)
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_api-overview-of-solution.md b/ja-jp/articles/architecture-scenarios/_includes/_api-overview-of-solution.md
new file mode 100644
index 0000000000..0ba99615fc
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_api-overview-of-solution.md
@@ -0,0 +1 @@
+In order to ensure that only authorized users and applications are allowed access to the Timesheets API, ExampleCo has decided to make use of the [OAuth 2.0 authorization framework](https://tools.ietf.org/html/rfc6749). The framework provides the flexibility the company wants since the different grants can allow them to easily authorize the various types of applications which need to communicate with the Timesheets API.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_api-signing-algorithms.md b/ja-jp/articles/architecture-scenarios/_includes/_api-signing-algorithms.md
new file mode 100644
index 0000000000..26c06a5eaf
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_api-signing-algorithms.md
@@ -0,0 +1,19 @@
+#### Signing Algorithms
+
+When you create an API you have to select the algorithm your tokens will be signed with. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
+
+::: note
+The signature is part of a JWT. If you are not familiar with the JWT structure please refer to: [JSON Web Token Structure](/tokens/references/jwt-structure).
+:::
+
+To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. That algorithm, which is part of the JWT header, is the one you select for your API: `HS256` or `RS256`.
+
+- __RS256__ is an [asymmetric algorithm](https://en.wikipedia.org/wiki/Public-key_cryptography) which means that there are two keys: one public and one private (secret). Auth0 has the secret key, which is used to generate the signature, and the consumer of the JWT has the public key, which is used to validate the signature.
+- __HS256__ is a [symmetric algorithm](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) which means that there is only one secret key, shared between the two parties. The same key is used both to generate the signature and to validate it. Special care should be taken in order for the key to remain confidential.
+
+The most secure practice, and our recommendation, is to use __RS256__. Some of the reasons are:
+
+- With RS256 you are sure that only the holder of the private key (Auth0) can sign tokens, while anyone can check if the token is valid using the public key.
+- Under HS256, If the private key is compromised you would have to re-deploy the API with the new secret. With RS256 you can request a token that is valid for multiple audiences.
+- With RS256 you can implement key rotation without having to re-deploy the API with the new secret.
+
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md
new file mode 100644
index 0000000000..0f2d1ea2a4
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_custom-domains.md
@@ -0,0 +1,16 @@
+When you setup your Auth0 tenant, the URL for accessing that tenant will be of the form  `https://${account.tenant}.auth0.com`. Providing a [Custom Domain](/custom-domains) (also known as a vanity URL), for your Auth0 tenant is not only an important factor for supporting your Branding requirements, but more importantly will also provide you with security benefits too:
+
+* Some browsers will, by default, make it [difficult to communicate in an iFrame if you don't have a shared domain](/api-auth/token-renewal-in-safari).
+* A vanity URL makes phishing more difficult as the phisher must also create a vanity URL to mimic yours. For example, with a custom domain you can use your own certificate to get an "Extended Validation", making phishing even harder.
+
+::: note
+You are allowed only one custom domain per Auth0 Tenant. This is because a tenant in Auth0 is intended to represent a “domain” of users. If you need more than one vanity URL, then you likely have more than one domain of users and should be using multiple tenants.
+:::
+
+Your custom domain name should also give the user confidence that this is the appropriate place to enter their credentials, and we recommend that you create your custom domain in all environments early on to ensure that you are testing consistently between environments. **It's extremely important to train your users to to look for suspicious URLs when entering their credentials!**
+
+::: panel Best Practice
+Create a custom domain (a.k.a. `CNAME`) for your Auth0 tenant, and also create one in development too so you can ensure you have managed the `CNAME` correctly. For example, you could create a `CNAME` which maps `login.mycompany.com` to `mycompany-prod.auth0.com`.
+:::
+
+In almost all cases, customers have been most successful when adopting a strategy of a centralised domain for authentication across multiple product or service brands. This strategy provides users with a consistent UX, and also mitigates the complexity of deploying and maintaining multiple Auth0 tenants in a production environment. If you are considering having multiple domains for different brands, please refer to the [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) guidance before you begin implementing.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_architecture/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_introduction.md
new file mode 100644
index 0000000000..ab22539da6
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_introduction.md
@@ -0,0 +1,37 @@
+Understanding your application is key to understanding how Auth0 can be leveraged to meet your needs. From experience, our most successful customers start with a visualization of their proposed - or in many cases existing - architecture and use this as a basis for reference as they progress. Understanding where your application fits within your organization is also important; Auth0 [Accounts and Tenants](/getting-started/the-basics#account-and-tenants) form the basis for the grouping and structuring of Auth0 assets, and it may be that you’ll need to leverage an existing Auth0 deployment in order to integrate with [Single Sign-on (SSO)](/sso/current/introduction), centralized user [Profile Management](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt), consolidated billing, or the like.
+
+::: panel Best Practice
+If you do have multiple applications, and you need to leverage SSO, then we recommend you check out our [How to Implement Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) training guidance before continuing.
+:::
+
+The value of investing time on the landscape of the architecture up-front is something that we have found pays dividends in the long run, and there are a number of things you will want to consider when looking at functionality and workflow:
+
+* What should the URL look like when Auth0 needs to present a web page to a user?
+* How can Auth0 be structured to support your SDLC (Software Development Lifecycle)?
+* How can you ensure that your Auth0 tenants are appropriately associated with your contract?
+* What do you need to consider if there are other projects in your organization integrating with Auth0? Particularly projects that target their own, or a different domain of users (for example, applications that only employees will use)? 
+<% if (platform === "b2b") { %>
+* How can you align the structure and domain of your customers’ organization with your Auth0 deployment?
+<%  } %>
+
+Organizations often service more than one domain of user - customers, employees, and affiliates being the most frequently encountered, with typically little to no cross-over: employees, say, don’t use the same applications as customers and vice-versa. In some cases there can also be a need to partition further within a domain - separate groups of customers, say, who use different and unconnected products. Auth0 provides a way to segregate your users and the associated collateral, and [tenant provision](#tenant-provision) covers this in more detail. If you need to provision an independent tenant then you’ll also want to [associate this with your existing Auth0 account](#tenant-association), so that you can take full advantage of the benefits provided at your organization’s contracted subscription level.
+
+::: panel Best Practice
+It’s not uncommon for companies to have identity requirements that address multiple user communities: customers, partners, employees, etc. So be sure to consider other projects or future requirements when designing your architecture.
+:::
+
+In addition, you’ll undoubtedly have an established set of processes and procedures as part of your Software Development Lifecycle (SDLC). So you’ll want to check out our [SDLC support](#sdlc-support) guidance regarding Auth0 Tenant provision in support of that too. 
+
+For customer-facing applications, we typically see [OpenID Connect (OIDC)](/protocols/oidc) as being the most frequently used protocol. OIDC makes use of web based workflows with browser URLs that are presented to the user. Out-of-the-box, client facing URLs as part of Auth0 OIDC support are Auth0 branded, however we recommend using the Auth0 [custom domain](#custom-domains) capability to provide for consistent corporate identity and to also address potential user confidence concerns before they arise. 
+
+::: panel Best Practice
+Other groups within your organization may also be working with Auth0; it’s not uncommon for our customers to have disparate departments that serve different user communities. Identifying these will potentially influence your design choices, and doing so early could mitigate decisions that might prove costly later on.
+:::
+
+<% if (platform === "b2b") { %>
+If your customers' organizations support the use of multiple IdPs, then we recommend that you can create separate Auth0 tenants for that organization; see [Tenant provision for complex organizations](#tenant-provision-for-complex-organizations) for further details. This allows you to keep the rest of your setup much simpler by maintaining a one-to-one connection relationship between your organization and all your customer organizations within your main tenant. 
+<%  } %>
+
+::: panel Get Started with Auth0 Video
+Watch this short video [Architecture: Your Tenant](/videos/get-started/01-architecture-your-tenant) to learn what an Auth0 tenant is and how to configure it in the Auth0 Dashboard. Understand why you may want more than one tenant if you have different user communities, and also how you can use more than one tenant to support your Software Development Life Cycle (SDLC). Understand the importance of tenant naming and custom domain usage best practices. Also learn how to set up additional tenant administrators and how to associate tenants with your Auth0 account.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md
new file mode 100644
index 0000000000..bddb0fea0d
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_sdlc-support.md
@@ -0,0 +1,17 @@
+Every company has some form of Software Development Life Cycle (SDLC), and throughout the development process you will want to align with that strategy. For instance, you need to be able to test your integration with Auth0 in a similar fashion as you test the applications themselves. It is therefore important to [structure Auth0 tenants to support your SDLC](/dev-lifecycle/setting-up-env), and there is a consistent pattern which our customers typically follow when it comes to the best practices associated with tenant layout for doing so:
+
+| Environment | Sample Tenant Name | Description |
+| - | - | - |
+| Development | **company-dev** | A shared environment where most of your development work occurs |
+| QA/Testing | **company-qa** or **company-uat** | An environment for formal testing of the changes you've made |
+| Production | **company-prod** | The production tenant |
+
+In some cases you may also want to create one or more sandboxes (e.g., **company-sandbox1**, **company-sandbox2**) so that you can test changes without compromising your development environment. This might be where you test deployment scripts and the like.
+
+::: panel Best Practice
+You can also take advantage of our [Implementation Checklists](/architecture-scenarios/checklists) that you can download and customize to meet your implementation project needs.
+:::
+
+::: warning
+Though Auth0 allows you to create as many free tenants as you'd like, you may be limited for the number of tenants where all paid features are enabled. If elegible, you can be provided with up to **three** tenants where all features are shared.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md
new file mode 100644
index 0000000000..dc2739a4cf
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-association.md
@@ -0,0 +1 @@
+To ensure that your [tenants are all associated with your Auth0 contractual agreement](/dev-lifecycle/child-tenants) and have the same features, ensure all your tenants are associated with your company account. If you have individual developers that want to create their own sandboxes for testing, make sure they get associated with your account so they have the same permissions too. To do this you should contact your Auth0 representative or the Auth0 Support Center at ${env.DOMAIN_URL_SUPPORT}.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md
new file mode 100644
index 0000000000..f502ca08a7
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_architecture/_tenant-provision.md
@@ -0,0 +1,7 @@
+Everything starts with an Auth0 tenant. This is where you will be configuring your use of Auth0, and the where Auth0 assets - such as [Applications](/applications), [Connections](/connections) and [user profiles](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt) are defined, managed and stored. Access to an Auth0 tenant is performed via the Auth0 [Dashboard](/dashboard), and via the Dashboard you can also create additional, associated tenants; you’re allowed to create more than one Auth0 tenant so that you can structure your tenants in a way that will isolate different domains of users and also support your [Software Development Life Cycle](#sdlc-support) (SDLC).
+
+::: warning
+Tenant names cannot be changed, nor reused once deleted. So, make sure you're happy with your name(s) before you create your Auth0 tenants.
+:::
+
+Determining the level of isolation you require when it comes to your user domains is an important step, and together with your branding requirements will subsequently help you determine the number of Auth0 tenants that will be required in your production environment. As we recommend you create a full suite of [SDLC supporting tenants](#sdlc-support) for every Auth0 tenant you will run in a production environment, the number of Auth0 tenants you will need to manage can quickly grow. Therefore you should consider carefully before creating multiple Auth0 tenants for production, and should consult our guidance on [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) before making your final decision. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_application-integration.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_application-integration.md
new file mode 100644
index 0000000000..8580bb8809
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_application-integration.md
@@ -0,0 +1,60 @@
+Once you've figured out how you want to authenticate your users, the next step is to determine how you will initiate that authentication. Each application will typically have its own starting point.
+
+::: warning
+Native mobile applications (and desktop applications) should use the system browser for authentication, or they open themselves up to additional security risks. See [Native vs. Browser Login on Mobile](/design/browser-based-vs-native-experience-on-mobile) for more information. 
+:::
+
+As discussed, we've found that most of our customers use [OpenID Connect (OIDC)](/protocols/oidc) as the industry-standard protocol when it comes to their customer-facing applications. Figuring out which [OIDC flow](/api-auth/intro) to use is your first task, and you will want to start by reviewing the our [grant mapping](/applications/reference/grant-types-auth0-mapping) guidance in the first instance.  
+
+If you want to allow anonymous users access to any part of our application then you need to determine if you will be redirecting right away or prompting your users to redirect only when required (or perhaps some combination of both; see [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login) for further discussion). If users can [deep link](#deep-linking-to-protected-endpoints) to a protected version (or area) of your site then you will need to determine the links to your application that will result in an automatic redirect to Auth0. 
+
+### Anonymous access
+
+It is important to consider the user experience when someone first comes to your application. If your application supports anonymous user access (quite common for eCommerce applications) there are different scenarios to consider:
+
+* Are they returning to the application after having already logged in, or
+* If this is the first time they are accessing the application:
+  * Have they already accessed a different application that uses the same Auth0 tenant,
+  * Have they ever (or perhaps not in a long time) authenticated on this device or browser.
+
+When an anonymous user accesses your application, it can often be desirable for the application to discover if the user has already logged into a different application in the same family, or to remember this user even if the application is a [SPA](/quickstart/spa) with no state. For example, if you can determine that the user is already logged in, you might decide to have the UI header in the application skip displaying a login button and instead have an account or profile menu for the user. To accomplish this you will want to utilize "[silent authentication](/api-auth/tutorials/silent-authentication)". Silent authentication will allow you to check to see if the user is logged in without prompting them to log in if they are not. Then the application can present a login button if necessary. If the user is logged in already, however, then you will receive tokens and will not have to present the user with a login button again.
+
+::: warning
+Checking for a login session by redirecting to Auth0 can be really helpful for your application, but if this will result in a lot of requests it is important to employ some sort of throttling mechanism to avoid latency and/or rate limiting. <%= include('../../_includes/_rate-limit-policy.md') %>
+:::
+
+### Deep linking to protected endpoints
+
+There are a variety of reasons why someone might link directly to a particular page within your application that is only accessible by authenticated users. If this is possible for your application you should automatically redirect your user to Auth0 if they are not authenticated. Once they authenticate and the authorization server returns them to your application, you can [redirect them](/users/guides/redirect-users-after-login) to where they intended to go in the first place.
+
+::: panel Best Practice
+Most modern authentication frameworks support middleware for redirecting to an authorization server such as Auth0. Ensure yours:
+
+* Is configurable
+* Can check expirations
+* Supports Refresh Tokens (for confidential clients)
+:::
+
+### Authenticating the user
+
+Authentication is the process of determining user identity. The result of authentication in an OIDC context is an ID Token. This token contains information about the user and should only be able to be obtained if the user authenticates using one or more factors as defined by the authorization server (the most common form being [user ID and password](#username-and-password-authentication)). There are a few things you may also need to consider in addition to obtaining an ID Token:
+
+* Do we also need an [Access Token](/tokens/concepts/access-tokens) in order to call a shared API?
+* Is your application a single-page application and only requires an [ID Token](/tokens/concepts/id-tokens)? See [Implicit Grant](/api-auth/tutorials/implicit-grant) for more information. 
+* Is your application a native application (mobile or desktop) and/or do you need a [Refresh Token](/tokens/concepts/refresh-tokens)? See [Authorization Code Grant with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) for more information. 
+
+::: warning
+Before you go live, you should ensure that **only** the grants that you are using for each application are enabled in your [configuration for your Application](/dashboard/guides/applications/update-grant-types).
+:::
+
+### Implicit grant
+
+If all your application needs is the ID Token and the application is browser-based, then you can always use the [implicit grant](/api-auth/tutorials/implicit-grant) to get your ID Token. This is a simple authentication flow and should be supported by your SDK (depending on the language you are developing in).
+
+::: warning
+If you need a [Refresh Token](/tokens/concepts/refresh-tokens) so that you can obtain a new Access Token or ID Token without having to re-authenticate the user, then you must use the [authorization code grant](/api-auth/tutorials/authorization-code-grant).
+:::
+
+### Authorization code grant (with or without PKCE)
+
+If your SDK only supports the Authorization Code grant, or you need an Access Token or Refresh Token, then Authorization Code grant (with or without [PKCE](/flows/concepts/auth-code-pkce)) can also be used to retrieve an ID Token.  The Authorization Code grant includes an additional API call to exchange the code for a token which can result in additional unnecessary latency if all you need is the ID Token. In many cases the [hybrid flow](/api-auth/tutorials/hybrid-flow) is implemented to provide optimum access to the ID Token while still leveraging Authorization Code grant workflow for the secure and safe retrieval of Access and Refresh Tokens.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md
new file mode 100644
index 0000000000..42aeb1a83b
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_attack-protection.md
@@ -0,0 +1,5 @@
+The reason that authentication systems are important is to prevent bad actors from accessing applications and user data that they should not. We want to place as many barriers as possible between those bad actors and access to our systems. One of the easiest ways to do this is to ensure that your [attack protection](/attack-protection) with Auth0 is configured correctly, so take a moment to read the guidance on this subject and ensure that it's working correctly for you.
+
+::: panel Best Practice
+Attack protection is handled behind the scenes by Auth0 and provides a great security feature for your product. If you're going to utilize it, ensure that you have set up your [Email Provider](/architecture-scenarios/implementation/${platform}/${platform}-operations#email-provider-setup) and configured your [Email Templates](/architecture-scenarios/implementation/${platform}/${platform}-branding#email-template-customization) before turning on email delivery to your users.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_introduction.md
new file mode 100644
index 0000000000..1921e46883
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_introduction.md
@@ -0,0 +1,46 @@
+In order to provide services to your users, you must be able to identify who those users are. This process is called User  Authentication. There are a number of ways to perform authentication of a user - via social media accounts, username and password, passwordless - and it's often recommended that you go beyond a first factor for authenticating the user by enabling multi-factor authentication (MFA).
+
+::: panel Best Practice
+It's important to consider both security and user experience when designing how you will authenticate your users. Providing for multiple primary factors, and/or enforcing more than one factor during authentication, are ways that you can provide both.
+:::
+
+There are a number of things you will want to consider when looking at functionality and workflow:
+
+* Where will users enter their credentials?
+* How will you keep user credentials safe?
+* How will you maintain your authentication system?
+* How can you provide password authentication for your users?
+* How can you prevent hackers from trying to log in as your users?
+* How will you implement authentication in different kinds of applications?
+* How can you make login easy for your users when they come from different language backgrounds?
+* How will you provide a good user experience as you migrate away from any legacy authentication system?
+* What should you consider when integrating applications with Auth0?
+<% if (platform === "b2c") { %>
+* Can users log in using their existing social (e.g., Facebook or Google) accounts?
+<%  } %>
+* Do you need to provide multi-factor authentication?
+* What do you do if you have a service that doesn't have a way for the user to log in ahead of time?
+* Can you pass the same user access token from one API to another?
+<% if (platform === "b2b") { %>
+* What do you do if you need to isolate users by organization?
+* How will you handle identifying which organization users belong to?
+* What’s the benefit of providing enterprise connections for your organizations?
+<%  } %>
+
+Auth0 [Universal Login](#universal-login) provides users with a safe and secure experience - no matter whether you choose to provide for user ID/password credentials sign in, or allow the so-called Bring Your Own Identity scenarios provided via [Social Login](https://auth0.com/learn/social-login/). There are also brand recognition benefits to centralizing the login experience with Universal Login, even if you feel you will also have product-specific [branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) requirements. The Auth0 UI widgets typically used with Universal Login also provide out-of-the-box support with regards to [internationalization](/libraries/lock/v11/i18n) for users with different language requirements, and out-of-the-box support for Auth0 features such as [MFA](#multi-factor-authentication-mfa-) and [attack protection](#attack-protection) allow you to put barriers in place in order to prevent hackers attempting to access users' accounts. 
+
+Allowing users to sign in via user ID/password credentials means that you're not reliant on the status of third-party identity providers for your users to access your system. You also have the means require the credentials used to align with your corporate policies. Auth0 assists with this by providing you with multiple options in support of user ID/password logins, and the [guidance provided](#username-and-password-authentication) will help you understand you can leverage these options. Adding [social](#social-authentication) support at some stage, as an additional primary authentication factor, gives you added flexibility and can help you better understand your users without the need to question them further by leveraging the information already stored by the various social login [providers](/connections/identity-providers-social).
+
+If you have an existing legacy identity store, you’ll also want to see [User Migration](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#user-migration). This section discusses the advantages of migrating to Auth0’s managed identity storage in terms of safety and security.
+
+For customer facing applications, OpenID Connect ([OIDC](/protocols/oidc)) is the most frequently used industry standard protocol, and OIDC has first-class citizen support in Auth0. Auth0 provides support for various different approaches for integrating various different applications, so you'll want to see the section on [application integration](#application-integration) for the information you'll need to make an informed choice. 
+
+When calling one API from another API, or from any situation where there is no authenticated user context - such as one or more cron jobs, report generators, or continuous integration/delivery systems - you will need a way to authorize the _application_ instead of a _user_. This is a one step process where the application is authenticated (using a client ID and secret) and then authorized in one call. You can learn more about this in our authorization workstream under [machine-to-machine (m2m) authorization](/architecture-scenarios/implementation/${platform}/${platform}-authorization#machine-to-machine-m2m-authorization).
+
+<% if (platform === "b2b") { %>
+Often companies need to segregate their users by organization and sometimes users can have access to more than one organization.  Knowing which of these scenarios is relevant to your company will help define how to determine in which connection a user exists: whether you need to do it, when you need to do it, and how to accomplish it.  See [Home Realm Discovery](#home-realm-discovery) to determine if this is something relevant to your company.
+<%  } %>
+
+::: panel Get Started with Auth0 Videos
+Watch these two short videos [Authenticate: How It Works](/videos/get-started/04_01-authenticate-how-it-works) and [Authenticate: SPA Example](/videos/get-started/04_01-authenticate-spa-example) to learn about the differences between authentication, authorization, and access control. Understand when and why you might use each type of authentication method: first factors, second factors, and multi-factor. Learn about the OpenID Connect (OIDC) authentication protocol. See an example using the Auth0 Quickstart for a single-page application (SPA) implementation.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_mfa.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_mfa.md
new file mode 100644
index 0000000000..ec67e73549
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_mfa.md
@@ -0,0 +1,16 @@
+In an era where misuse of user credentials is at an all-time high, protecting _your_ systems when it’s so common for hackers to steal users identity information in general is a challenge. One of the most effective ways though is to provide users with the ability to configure a second factor for protecting their account. More commonly referred to as [Multi-Factor Authentication](/mfa). This will ensure that only a valid user can access their account, even if they use a username and password that may have been compromised from a different application.
+
+::: panel Best Practice
+It's quite common for customer facing applications to provide users with an _option_ for adding a second factor rather than _forcing_ them to use a second factor. For more information regarding this, see [providing your users with an option to add MFA](https://auth0.com/learn/multifactor-authentication-customers/).
+:::
+
+Auth0 supports a number of different options when it comes to enabling MFA for protecting user account access, and there are several practices to ensure that you will truly be providing a flexible second factor barrier to access:
+
+* Auth0 [Guardian](https://auth0.com/multifactor-authentication): a service that provides both _Push_ notification generation and an application for allowing or denying requests. _Push_ sends notification to a user’s pre-registered device - typically a mobile or tablet - from which a user can immediately allow or deny account access via the simple press of a button.
+* Time-based One-Time Password (TOTP): allows you to register a device - such as Google Authenticator - that will generate a one-time password which changes over time and which can be entered as the second factor to validate a user’s account.
+* SMS: for sending a one-time code over SMS which the user is then prompted to enter before they can finish authenticating.
+* Voice: for delivering a one-time code through a phone call which the user is then prompted to enter before they can finish authenticating.
+* Duo: allows you to use your Duo account for multi-factor authentication.
+* Email: allows you to use your email account for multi-factor authentication.
+
+Whilst MFA workflow using technologies such as Guardian or Google Authenticator is typically provided via a separate application that runs on a mobile or tablet device, if you don’t want your customers to have to download a separate application Auth0 also provides you with an SDK that you can use to build second factor workflow right in your existing mobile device application(s).
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md
new file mode 100644
index 0000000000..262ba3477c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_social-authentication.md
@@ -0,0 +1,13 @@
+The “bring your own identity” scenario offered by Facebook, Google, etc., is a valuable way of simplifying the user authentication experience without compromising security, and using [Universal Login](#universal-login) makes it easy to start adding support for [Social Connections](/connections/identity-providers-social) with minimal disruption. 
+
+::: warning
+Auth0 provides a simple way to test social connections using [pre-configured developer keys](/connections/social/devkeys). However, these have [limitations](/connections/social/devkeys#limitations-of-developer-keys), and before going into production, you’ll need to set up your own application-specific keys by following the [instructions](/connections/identity-providers-social) for your chosen social provider(s).
+:::
+
+With [social](https://auth0.com/learn/social-login/) support, user identities and credentials are managed by the social provider, as are certain identity claims—which Auth0 will use to populate the user [profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt). Auth0 can also provide access to Social Identity Providers' (Social IdPs') [Access Tokens](/tokens/overview-idp-access-tokens), so that your application can also call 3rd-party Social IdP APIs on behalf of the user.  
+
+::: panel Best Practice
+Social is a great feature to provide, but when you offer more than one way to sign in, you need to consider the possibility that your customers will actually use more than one way to sign in. By default, every user identity in Auth0 has its own user profile, so you’ll probably want to consider Auth0's capability to [link user accounts](/users/concepts/overview-user-account-linking) to provide an effective way of associating one user profile with multiple identities.
+:::
+
+Auth0 [Custom Social Connections](/connections/social/oauth2) extend social authentication even further by allowing you to connect with any OAuth2 identity provider not supported out-of-box. For example, support for the government-issued-identity provider [SwissID](https://www.swissid.ch/) can be configured in Auth0 by using a Custom Social Connection. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md
new file mode 100644
index 0000000000..58df288183
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_sso-legacy.md
@@ -0,0 +1,10 @@
+In a large scale re-structure it's not always possible—or practical—to update all your applications at once. In fact, our recommended best practice is to plan for an iterative-style approach when it comes to integrating with Auth0. If your applications already participate in Single Sign-on (SSO), and your legacy identity system supports protocols such as OIDC or SAML, then you have a couple of options available if you want to continue to provide SSO as you integrate with Auth0:  
+
+* Update your existing identity provider in your legacy SSO system to redirect to Auth0 for login (e.g., using [SAML](/protocols/saml/saml-configuration/auth0-as-identity-provider)), or
+* Have Auth0 redirect to your legacy SSO system to login. This requires configuring your legacy system as an IdP in Auth0 (i.e., either using [SAML](/protocols/saml/saml-configuration/auth0-as-service-provider) or [OIDC](/connections/social/oauth2)).
+
+::: panel Best Practice
+Supporting an SSO experience with your legacy system can add complexity, but may be worth it to generate a more seamless user experience as you integrate with Auth0. If you intend to go down this path, planning for it early can help ensure that it is possible to achieve. If you don't already have SSO at a centralized service, then the complexity to add it will unlikely be worth the benefits.
+:::
+
+This is a complex topic that will likely need some additional investigation depending on your current legacy architecture, and we recommend you only look into this if you currently have SSO support in your legacy system. Note: if you are currently redirecting from your applications to a centralized system to authenticate your users and that system only asks for credentials if you don’t already have a session with the centralized system, then you have a legacy SSO implementation.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_universal-login.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_universal-login.md
new file mode 100644
index 0000000000..57dc6a92d7
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_universal-login.md
@@ -0,0 +1,11 @@
+Do you have, or will you have, more than one application in your system? If the answer to this question is yes, then you will want a centralized sign in experience. To achieve a seamless Single Sign-on (SSO) experience between multiple applications, it is critical to have a centralized location to redirect your users for authentication. This allows you a way to provide your users with a consistent experience if you add social authentication in the future, add third party applications to your system, or add multi-factor authentication as an option (or requirement) for your users - and also allow you to take advantage of new features for improving your users’ experience with little, if any, added development effort.
+
+::: panel Best Practice
+If you have more than one application, the best practice is to redirect to a [centralized location](/universal-login) to authenticate the user. With Auth0, this means taking advantage of [Universal Login](/universal-login), which provides many security and user experience benefits out-of-the-box, including [SSO](/sso/current).
+:::
+
+Auth0 Universal Login makes authenticating users a short, easy process which can be accomplished in three easy steps (all of our Quickstarts demonstrate this and our SDKs hide the complexity for you too):
+
+1. Determine how and when you want to [redirect from your application](#application-integration).
+2. Set up the appropriate [branding](/architecture-scenarios/implementation/${platform}/${platform}-branding) and/or customized HTML in your Auth0 configuration.
+3. Set up your application to [receive and handle the response](#application-integration) from the Authorization Server.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md
new file mode 100644
index 0000000000..6668a0c76d
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authentication/_username-and-password-authentication.md
@@ -0,0 +1,9 @@
+Nearly every B2C application provides the ability for their customers to create a new set of credentials. This is a common form of authentication that all users are familiar with.
+
+Username password authentication comes in multiple flavors at Auth0. If your application is a green-field application with no existing user base, then a simple Auth0 out-of-the-box [Database Connection](/connections/database) will give you everything you need to start authenticating your users. However, if you have a legacy user store (such as your own database of users or an existing LDAP system) you have a couple of different options for migrating your users as discussed in our guidance on [User migration](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#user-migration).
+
+However you end up provisioning the users for your database connection, the authentication of those users is quite similar. It requires you to present users with a form to enter their username and password. As mentioned in the guidance concerning [Universal Login](#universal-login), the simplest and safest way to authenticate users with a username and password is to redirect them to a centralized login page and collect their username and password there. This allows Auth0 to determine whether they have already authenticated and skip the login form entirely when it's not needed.
+
+::: panel Best Practice
+Collecting credentials only at the centralized login page will reduce the surface area for potential leak of user secrets. It will also reduce the need to collect credentials unnecessarily. See [Universal Login](#universal-login) for more information.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authorization/_api-integration.md b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_api-integration.md
new file mode 100644
index 0000000000..879f473836
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_api-integration.md
@@ -0,0 +1,37 @@
+In this scenario your Auth0 tenant can provide an OAuth2 [Access Token](/tokens/concepts/access-tokens), typically expressed as a [JWT](/tokens/concepts/jwts), which [can be used by your API to restrict access to certain parties](/api-auth). In addition, Auth0 provides support for what is notionally described as both [First-Party and Third-Party Applications](/applications/concepts/app-types-first-third-party).
+
+Acting as the authorization server, and with the consent of the user (the resource owner), your Auth0 tenant can be used to provide an Access Token - typically expressed as a [JWT](/tokens/concepts/jwts) - to an application (client) so that it can access a protected resources hosted by a resource server on behalf of the resource owner. The issued Access Token is typically passed as the Bearer token in the HTTP Authorization header sent to an API.
+
+Whether you have a single API, or perhaps a suite of logically related [microservice APIs](/api-auth/tutorials/represent-multiple-apis), you can leverage the Access Tokens that Auth0 provides in order to secure access to your service(s). Though relatively easy to set this up in the [Auth0 Dashboard](/apis) or through the [Auth0 Management API](/api/management/v2#!/Resource_Servers/post_resource_servers), it's important to review the different application scenarios and API layouts to determine the best architecture for your system.
+
+::: note
+OAuth2 Access Tokens are primarily designed for use in securing public facing APIs; when expressed as a JWT, an Access Token is a self contained entity which can be verfied without the need to make any additional 3rd party API call. If your APIs do not fall into this category - i.e they are part of an application itself (as in only called by that application) or are sat behing your firewall - then protecting them with tokens may well be overkill, and your existing cookie based (et al) workflow may well suffice.
+:::
+
+OAuth2 was designed specifically with third-party access in mind, For example, a scenario might be that a user (resource owner) wants to use an application (a client) that does not belong to the same organization as the service that provides the user's data (the reseource server). In this case, when the application needs to access data that the user owns, it redirects to the organization where the user’s data resides, which in turn authenticates the user and then prompts the user to give the application permission to access their data. This prompting for permission is referred to as providing *[consent](/api-auth/user-consent)* and is a large part of what providing support for [third party applications](/scopes/current/api-scopes#example-an-api-called-by-a-third-party-application) entails. If you are planning to integrate third-party applications, then it's important you [mark them as third-party](/api-auth/user-consent) early on so that Auth0 will handle prompting for user consent.
+
+On the other hand, if your organization *owns* the application(s), the user data itself and the API(s) through which that data is accessed, then consent is not typically required as the interactions are all [first-party](/scopes/current/api-scopes#example-an-api-called-by-a-first-party-application). If you're only creating first-party applications, then you can ensure that you are not presenting your users with any unnecessary consent screen(s) by [allowing user consent to be skipped](/apis#api-settings) as part of any resource service definition.
+
+::: warning
+Though you can configure your applications to be first-party and subsequently configure your APIs to allow first-party clients to ignore consent, if you are using `localhost` then Auth0 cannot verify that the application is truly a first-party app so your users will be prompted for consent anyway. To work around this constraint, when testing on your local machine during development, create a [fake local hostname and use that instead](https://community.auth0.com/t/how-do-i-skip-the-consent-page-for-my-api-authorization-flow/6035).
+:::
+
+Alternatively, you may have data relating to a user for which additional [functionality is provided](/scopes/current/api-scopes#example-an-api-called-by-a-back-end-service) and for which explicit user consent cannot be obtained (i.e. there is no authenticated user who can provide it). In this scenario, a [list of applications for which Client Credentials grant is enabled](/flows/concepts/client-credentials) can be defined. 
+
+### Access Token claims
+
+As is the case with ID Tokens, you can [add custom claims to Access Tokens](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) using Auth0 Rule extensibility. Once added, your API can then verify an Access Token for the necessary claims and either allow or prevent access to certain functionality as required. 
+
+::: panel Best Practice
+When you are considering adding custom claims, we recommend that you store any access control data you may need to include within claims as part of the user's [`app_metadata`](/users/concepts/overview-user-metadata). Firstly, this prevents you from needing to call an external API to fetch the data, which can negatively impact performance and scalability. Secondly `app_metadata` **cannot** be modified by a user - so the user cannot directly circumvent any access control restrictions by modifying their own metadata. Also remember to check out our [metadata best practices](architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt#metadata) guidance too.
+:::
+
+### Access Token scopes
+
+[OAuth2 Scopes](/scopes/current/api-scopes) are typically used as the mechanism by which an API can determine what actions can be performed on behalf of a user. Scopes can be added on a per API basis to [define specific access permissions](/dashboard/guides/apis/add-permissions-apis) in the Auth0 Dashboard or through the Auth0 Management API). Scopes can also be manipulated via Auth0 extensibility (e.g. via a Rule, as in this [example](/architecture-scenarios/spa-api/part-2#create-a-rule-to-validate-token-scopes)). The scopes an application requests for accessing an API should depend on what functionality the application needs the user to give permission for the application to use. Once the requested scopes are authorized, they will be returned in the Access Token which can be subsequently verified by said [API](/tokens/guides/validate-access-tokens). A good example of this is when you log in to an application that is using a social provider for login: the social provider API requires that the application specifies whether the user will want the application to post items on your behalf. This allows the user to accept or deny this request. This example demonstrates how the user is delegating permission to the application - which is different than the API restricting access based on a user's role, and should be handled differently.
+
+::: panel Best Practice
+Even though you have the ability to fully manipulate Access Token Scopes via Auth0 extensibility, as a security best practice you should only remove scopes which are not authorized and refrain from adding scopes that were not requested.
+:::
+
+Though scopes are often used as a way to enforce access permissions for a user, there are situations where it can become tricky when you use them in this manner. We therefore recommend that you use scopes for their intended purpose (i.e. delegating permission to an application) and use [custom claims](#access-token-claims) for your role-based or other access control scenarios.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authorization/_application-integration.md b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_application-integration.md
new file mode 100644
index 0000000000..bf785f09e1
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_application-integration.md
@@ -0,0 +1,17 @@
+In this scenario, your Auth0 tenant provides a token as an indicator of authorized access to an application. For applications utilizing [OpenID Connect (OIDC)](/protocols/oidc), the industry-standard protocol we typically find most utilized when it comes to customer facing applications, this would be an ID Token expressed as a [JWT](/tokens/concepts/jwts).
+
+### ID Token claims 
+
+Using Rule extensibility, Auth0 allows you to easily [add custom claims to an ID Token](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) based on, for example, a user’s [Metadata](/users/concepts/overview-user-metadata) content. Your application can then verify the ID Token for the necessary claims, and either allow or prevent access to certain functionality as required. Note that though the process of adding custom claims via Rule is streamlined, the Rule engine is flexible and allows you to write custom code that may have negative effects. Therefore it’s important to follow our [rules best practice](/best-practices/rules) guidance anytime you use this extensibility feature.  
+
+::: panel Best Practice
+When you are considering adding custom claims, we recommend that you store any access control data you may need to include within claims as part of the user's [`app_metadata`](/users/concepts/overview-user-metadata). Firstly, this prevents you from needing to call an external API to fetch the data, which can negatively impact the performance and scalability of the login sequence. Secondly `app_metadata` **cannot** be modified by a user - so the user cannot directly circumvent any access control restrictions by modifying their own metadata. Also remember to check out our [metadata best practices](architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt#metadata) guidance too.
+:::
+
+<% if (platform === "b2b") { %>
+If you are creating different instances of your application for your customer organizations, a common practice is to create a custom claim in your ID token to represent the user's organization. For example, `context.idToken["http://yourdomain.com/claims/organization"]= "organization A";`
+<%  } %>
+
+### ID Token scopes
+
+[OIDC Scopes](/scopes/current/oidc-scopes) are typically used by an application to obtain consent for authorized access to a user's details during authentication. Each of the pre-defined scopes returns the set of [standard claims](/scopes/current/oidc-scopes#standard-claims) where defined, and as described in the [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). The scopes an application requests depend on which user attributes the application needs. Once the requested scopes are authorized by the user, the claims are returned in the ID Token and are also made available via the [/userinfo](https://auth0.com/docs/api/authentication#get-user-info) endpoint.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authorization/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_introduction.md
new file mode 100644
index 0000000000..b1720ae98f
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_introduction.md
@@ -0,0 +1,47 @@
+Let's start by taking a step back and talking about Access Control. There isn't one clear cut definition of Access Control in the industry, but if you spend some time searching and reading you'll see that most authoritative sources agree that it is the umbrella concept that puts all of Authentication, Authorization, Consent, and Policy Enforcement together to ensure that only the right people and services have access to your applications and APIs.  Next, let's look more closely into the distinctions between Authentication, Authorization, Consent, and Policy Enforcement. Your Auth0 tenant (your Authorization Server) is typically responsible for Authentication and Consent, and some or all of Authorization and Policy Enforcement. Additionally, an Application or API itself almost always is the primary enforcer of policies, especially where contextual access is required:
+
+* **Authentication**: the process of determining if a principal (a user or application) is who or what they say they are.
+* **Authorization**: the process of determining what is allowed, based on the principal, what permissions they have been given, and/or the set of contextually specific access criteria.
+* **Consent**: what permissions the user (Resource Owner) has given permission to an application to do on its behalf. This is generally a requirement of delegated authorization.  The user has to give permission to the Client to access the user's data in a different system.
+* **Policy Enforcement**: The act of enforcing the policies of the application or API, rejecting or allowing access based on a user's authentication and/or authorization information.
+
+In general we typically group different types of access control into three distinct categories so that it's easier to understand a) which actor is responsible for storing the information, b) which actor is responsible for making decisions, and c) which is responsible for enforcing the restrictions.
+
+* The first category is where access is either granted or denied to an application or an API in its entirety. Both the data required to enforce this and the enforcement process is typically defined in the context of the Authorization Server For example, by using [`app_metadata`](/users/concepts/overview-user-metadata) associated with a user and a [Rule](/rules) defined in your Auth0 tenant.
+
+* The second category is where access is either granted or denied to a specific subset of application or API functionality. The data required to enforce this is typically stored in the Authorization Server For example, by using [`app_metadata`](/users/concepts/overview-user-metadata) on a user in your Auth0 tenant with the enforcement process performed in the application or API itself. In this scenario, the data is typically communicated as one or more custom claims in an [`id`](/tokens/concepts/id-tokens) or [`access`](/tokens/concepts/access-tokens) token.
+
+* The third category is where access is either granted or denied depending on what the principal (subject) can operate on within the context of an application or API. Both the data required to enforce this, and the enforcement process is typically defined in the context of the application or API. In this scenario, the data communicated as one or more custom claims in an [`id`](/tokens/concepts/id-tokens) or [`access`](/tokens/concepts/access-tokens) token may be consumed with or without data from an external source that is not Auth0.
+
+In addition, Role-based Access Control (RBAC) and Attribute-based Access Control (ABAC) mechanisms can be applied in any of the Access Control categories described above. Whatever your use case then, there are a number of things you will want to consider when looking at the functionality and workflow you require:
+
+* Are there scenarios where access to an entire application or API should be rejected?
+* Will you be providing APIs that can be accessed by third-party applications?
+* Will your APIs also be accessed by your own (first-party) applications?
+* Will your application be calling a third-party API?
+* Should your applications and/or APIs be enforcing access control based on user claims?
+<% if (platform === "b2b") { %>
+* What if I need to know which organization an access token or id token is associated with?
+<%  } %>
+
+Auth0 supports access restriction for either applications or APIs based on certain conditions. In certain scenarios, you may want to create a [Rule](/rules) that returns an `UnauthorizedError` when, for example, a user attempts access to an application or an API at an incorrect time (as described in this [example](/authorization/concepts/sample-use-cases-rules#allow-access-only-on-weekdays-for-a-specific-application)) - or if the user doesn’t have the right claim(s) contained in their [`app_metadata`](/users/concepts/overview-user-metadata). For an _application_ using [OpenID Connect (OIDC)](/protocols/oidc), this would prevent the allocation of the [ID Token](/tokens/concepts/id-tokens) used to authorize access. Similarly, for an _API_, allocation of any OAuth2 [Access Token](/tokens/concepts/access-tokens) (used when calling the API), could be prevented as described in this [example](/api-auth/restrict-access-api#example-deny-access-to-anyone-calling-the-api).
+
+::: panel Best Practice
+In the main, we have found that [OIDC](/protocols/oidc) is the most commonly used industry-standard protocol used by Auth0 customers when it comes to authentication in their applications. We have also found that, even though [OAuth2](protocols/oauth2) was created as a delegation protocol, it is commonly used within first party applications when there is an API that does not have a shared session with the application.
+:::
+
+Auth0 also can provide the information needed so that an application can enforce restrictions. For [application level integration](#application-integration), Auth0 allows you to add [custom claims](#id-token-claims) to an ID Token, which your application can then verify and subsequently use to perform policy enforcement. In this case you will need to decide what information you require for your application to make enforcement decisions.  If you need to make decisions at an API instead of in your application, you will likely need to use an Access Token instead of an ID token.  Continue reading for more information.
+
+::: warning
+When deciding what data to include in your ID token and/or access token, consider token size, especially if you are passing the token in the URL. Even if you are not passing tokens in the URL, you will also need to consider the potential of exposing sensitive PII (Personally Identifiable Information). Token information is not encrypted, so although it isn't generally a security issue for an ID token to be leaked, it can become a privacy issue depending on the data that is included in the token.
+:::
+
+For [API level integration](#api-integration), Auth0 supports both [custom claims](#access-token-claims) as well as [scope](#access-token-scopes) re-configuration, both within the context of an Access Token. Again, you will need to decide what information will be required in order for your API to make access decisions, and your API will need to enforce that by validating the contents of the Access Token.
+
+::: panel Best Practice
+When deciding whether you should use permissions through custom claims or scopes, you should make sure you understand the nature and purpose of scopes.
+:::
+
+<% if (platform === "b2b") { %>
+For multi-organization scenarios, it can often be important to know which organization an access token (or even an ID token) applies to. Taking care to follow the [best practices](#organization-data-in-an-access-token) can save you time and effort. 
+<% } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authorization/_m2m.md b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_m2m.md
new file mode 100644
index 0000000000..f22d07cc27
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_m2m.md
@@ -0,0 +1,13 @@
+There are many scenarios that require an application _without_ any user-interactive session to obtain an access token in order to call an API. In such scenarios you must authenticate the client instead of the user, and OAuth 2 provides the [client credentials](/flows/concepts/client-credentials) grant type to make this easy to achieve. Some common examples of where this is required include:
+* A cron job or other service that needs to communicate with your API (e.g. where a daily report needs to be generated and emailed it to an administrator).
+* A separate API the supports privileged access (e.g. the API is not exposed to users directly, but instead to a backend only).
+* In certain microservice architectures, where some API layers need to communicate to other API layers without a user involvement, or after a user token has expired.
+* A privileged API that may need to be called before a user has authenticated (i.e. from a rule or custom DB script in your Auth0 tenant)
+
+::: panel best practice
+Traditionally, a special "service account" would have been created in order to cater for these scenarios: a user with a username and password that was configured for services which supported non-interactive use cases. That is no longer a recommended approach for many reasons, and the current best practice is to use [OAuth 2.0 Client Credentials Grant](/flows/concepts/client-credentials) in these situations.
+:::
+
+::: warning
+Though the [Client Credentials Exchange Hook](/hooks/extensibility-points/client-credentials-exchange) in Auth0 can be used to add custom claims, it's important to consider the purpose for which a token was requested and to avoid extending use of the token beyond its intended purpose. Doing otherwise can result in the creation of unintended attack vectors for attackers to exploit.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_authorization/_rbac.md b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_rbac.md
new file mode 100644
index 0000000000..68df646d59
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_authorization/_rbac.md
@@ -0,0 +1 @@
+Auth0 has out-of-box support for Role Based Access Control ([RBAC](/authorization/concepts/rbac)). RBAC refers to assigning permissions to users based on their _role_ within an organization, and provides for simpler access control by offering a more manageable approach that is less prone to error. 
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_base-intro.md b/ja-jp/articles/architecture-scenarios/_includes/_base-intro.md
new file mode 100644
index 0000000000..2dfc169d6e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_base-intro.md
@@ -0,0 +1,5 @@
+Customers using Auth0 for <% if (platform === "b2c") { %>Business-to-Consumer (B2C)<% } else { %>Business-to-Business (B2B)<% } %> projects typically share a common set of goals and objectives, and in the sections that follow we'll focus on our real-world customer implementation experiences to help you deliver your solution efficiently.
+
+::: panel Best Practice
+Auth0 provides recommendations and best practice suggestions in an *ad hoc* way throughout this guide in panels like this one. You can also obtain detailed guidance regarding specific functionality by speaking with your account representative or a member of our Auth0 [Professional Services](/services) team.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md b/ja-jp/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md
new file mode 100644
index 0000000000..7089399c48
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_base-ways-to-integrate.md
@@ -0,0 +1 @@
+There are many different ways Auth0 can be integrated into the <% if (platform === "b2c") { %>CIAM<% } else { %>B2B IAM<% } %> project architecture. Auth0's flexibility comprehensively supports many different use cases however your project may not require all of the capabilities provided by Auth0. Knowing what, when, and how best to implement something will help you focus on completing the necessary tasks at the right time. 
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md
new file mode 100644
index 0000000000..ae02a82b67
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_custom-domain-naming.md
@@ -0,0 +1,15 @@
+By default, the URL associated with your tenant will include its name and possibly a region-specific identifier. For example, tenants based in the US have the a URL similar to `https://example.auth0.com` while those based in Europe have something that is of the fashion `https://example.eu.auth0.com`. A [Custom Domain](/custom-domains) offers a way of providing your users with a consistent experience by using a name that’s consistent with your organization's brand.
+
+::: warning
+Only one custom Domain Name can be applied per Auth0 Tenant, so if you absolutely must have independent domain name branding then you will require an [architecture](/architecture-scenarios/implementation/${platform}/${platform}-architecture) where multiple Auth0 Tenants are deployed to production.
+:::
+
+In addition, Custom Domain functionality offers you complete control over the [certificate management](/custom-domains#certificate-management) process. By default, Auth0 provides standard SSL certificates, but if you configure a custom domain, you can use Extended Validation (EV) SSL certificates or similar to provide the visual, browser-based cues that offer your visitors additional peace of mind.
+
+In general, we see customers having the most success when they use a centralized domain for authentication - this is especially the case if the company offers multiple products or service brands. By using a centralized domain, you can provide end users with a consistent user experience while also minimizing the need to maintain multiple production tenants in Auth0.
+
+<% if (platform === "b2b") { %>
+::: warning
+If your customer organizations will be isolated from each other, and you require that users are presented a login page for each organization via a custom domain URL, then your only option is to create a [separate tenant for each organization](/architecture-scenarios/${platform}/${platform}-architecture#tenant-provision-for-complex-organizations).
+:::
+<%  } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_email-templates.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_email-templates.md
new file mode 100644
index 0000000000..3b3dccdf63
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_email-templates.md
@@ -0,0 +1,9 @@
+Auth0 makes extensive use of email to provide both user notifications and to drive the functionality needed for secure identity management (for example, email verification, account recovery, and brute force protections), and Auth0 provides a number of templates for these.
+
+::: note
+Before customizing email templates, please set up your [Email Provider](/architecture-scenarios/implementation/${platform}/${platform}-operations#email-provider-setup).
+:::
+
+Out of the box, the email templates used contain standard verbiage and Auth0 branding. However, you can configure almost every aspect of these templates to reflect the verbiage and user experience you want and make changes to things like the preferred language, accessibility options, and so forth.
+
+Email templates are customized using [Liquid syntax](/email/liquid-syntax). If you are interested in customizing your templates based on user preferences, you will also have access to the [metadata](/users/concepts/overview-user-metadata) located in users' profiles, as well as any specific application metadata too. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_error-page.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_error-page.md
new file mode 100644
index 0000000000..4f74e4757a
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_error-page.md
@@ -0,0 +1,5 @@
+If there are issues encountered during user interactive workflow (e.g. user sign up or login), Auth0 provides error messages that indicate what the problem is under the hood. The default messages are somewhat cryptic, especially to the end user, since they will likely be missing context that only you can supply. As such, we recommend [customizing your error pages](/universal-login/custom-error-pages) to provide the missing context-specific information directly to your users. Furthermore, customizing your error pages allows you to display your branding, not Auth0's, as well as provide useful information to your users as to what should be done next. This information might include a link to a FAQ or how to get in touch with your company's support team or help desk.
+
+::: panel Best Practice
+Out-of-the-box there is no user interface for customizing Auth0 provided error pages, but you can use the [Tenant Settings endpoint of the Management API](/api/management/v2#!/Tenants/patch_settings) to configure them. Alternatively, if you can create and host your own error page, then you can have Auth0 direct users to that page instead of using the Auth0-hosted option. 
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_guardian.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_guardian.md
new file mode 100644
index 0000000000..99b6009f56
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_guardian.md
@@ -0,0 +1,3 @@
+The Multi-factor Authentication pages can be customized by adjusting the Universal Login branding options in the [Universal Login Settings](${manage_url}/#/login_settings) section.
+
+If you need further customization, you can also customize [the full HTML content](/universal-login/multifactor-authentication#customizing-the-html-for-the-mfa-page) to reflect your organization's particular UX requirements. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_introduction.md
new file mode 100644
index 0000000000..387c2dc354
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_introduction.md
@@ -0,0 +1,35 @@
+Auth0 can be customized with a look and feel that aligns with your organization's brand requirements and user expectations. Branding Auth0 collateral provides a consistent user experience for your customers, and gives them peace of mind that they’re using a product from a trusted and secure provider.
+
+Auth0 provides support for [internationalization (I18N)](/i18n) and localization (L10N), both of which are important if you work on branding for an international clientele. Out-of-box collateral, such as the Auth0 Lock UI widget, comes ready enabled for multiple language support, with built-in extensibility for adding more languages if what you require [doesn’t already exist](/libraries/lock/v11/i18n).
+ 
+::: panel Best Practice
+Almost all applications need Internationalization and/or Localization in one form or another. Auth0 makes it easy to add, but you need to account for it up front: retro-fitting localization, for example, can be a painful process if left too late.
+:::
+
+When considering the items you want to brand, as well as how best to brand them, there are a number of things you'll want to review:
+
+* Do you need to brand your login page?
+* Do you need to localize your login page?
+<% if (platform === "b2b") { %>
+* If you are sharing an Auth0 tenant across customer organizations, should you add organization-specific branding to their login experience?
+<%  } %>
+* How can you customize emails so that they're not just branded, but vary based on user preference?
+* How will users know that they're still on your domain when they see your login page?
+* What do you need to do to provide additional browser security (e.g., implement Extended Validation)?
+* Where do you want to direct users in the event of errors?
+
+Auth0 provides tremendous flexibility when it comes to customizing and configuring Auth0 pages such as [Universal Login](#universal-login-and-login-pages) and [Password Reset](#password-reset-page-customization). So you can pretty much set up whatever UX look and feel you require. For many, the out-of-the-box experience - with perhaps a little alteration - is all that's required. However, for others the value of their brand and brand awareness requires more extensive customization. This flexibility extends to not only Auth0 pages, but via extensibility can also be applied to the [email templates](/architecture-scenarios/implementation/${platform}/${platform}-branding#email-template-customization). Auth0 [Custom Domain](/architecture-scenarios/implementation/${platform}/${platform}-branding#custom-domain-naming) functionality further enhances consumer awareness by providing users with the confidence and peace of mind when it comes to safety and security. 
+
+<% if (platform === "b2b") { %>
+If you are sharing an Auth0 tenant across multiple customer organizations, providing each organization with their own domain of users and managing their credentials, you will need to consider how each user will know which credentials they should use and how they will trust that they are entering them somewhere safe and secure. See [Branding login by organization](#branding-login-by-organization) for details. 
+<%  } %>
+
+While Auth0 provides for default information when it comes to error situations, out-of-the-box information can be somewhat cryptic as the context that can only be provided by you is missing. Auth0 [error page customization](/architecture-scenarios/implementation/${platform}/${platform}-branding#error-page-customization) guidance can however help mitigate that by allowing you to provide information of a more context-specific nature via your own support organization. 
+
+::: panel Best Practice
+To provide helpful resources for users who experience problems, you should also configure a friendly name and a logo, as well as provide the support email address and URL for your organization. To learn how, see [Dashboard Tenant Settings](/dashboard/reference/settings-tenant#settings).
+:::
+
+::: panel Get Started with Auth0 Videos
+Watch three short videos—[Brand: How It Works](/videos/get-started/07_01-brand-how-it-works), [Brand: Signup and Login Pages](/videos/get-started/07_02-brand-signup-login-pages), and [Brand: Emails and Error Pages](/videos/get-started/08-brand-emails-error-pages)—to learn how branding works with Auth0, how to use Auth0’s Universal Login feature to customize your sign up and login pages, and how to use Auth0 email templates and make changes to the reply email address, subject, redirect URL, and URL lifetime.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_password-reset.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_password-reset.md
new file mode 100644
index 0000000000..c3b0785c61
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_password-reset.md
@@ -0,0 +1,8 @@
+The [Password Reset](/universal-login/password-reset) page is used whenever a user takes advantage of password change functionality and, as with the login page, you can [customize it](/universal-login/password-reset#edit-the-password-reset-page) to reflect your organization's particular branding requirements. 
+
+<% if (platform === "b2b") { %>
+If your organization users will all be isolated from each other (i.e, each organization gets its own Auth0 [database connection](/connections/database)), and you are branding the [Universal Login](#universal-login-and-login-pages) pages by organization, then it's also important to brand things like the [password reset](/universal-login/password-reset) page so users know for which organization the password change is occurring. This can be done in a couple of ways:
+
+* Create JavaScript on the Password Reset page that can pull resources from a CDN based on the connection parameter that indicates from which organization the user is coming.
+* Create a separate tenant for an organization and use Universal Login to customize what is required for that organization.
+<%  } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_branding/_universal-login.md b/ja-jp/articles/architecture-scenarios/_includes/_branding/_universal-login.md
new file mode 100644
index 0000000000..69e2691da7
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_branding/_universal-login.md
@@ -0,0 +1,5 @@
+[Universal Login](/universal-login) is the recommended method for authenticating users, and it centers around use of the Login page. You can customize the Login page to support your organization's [branding requirements](/universal-login#customizing-universal-login).
+
+::: panel Best Practice	
+If you choose to customize the Universal Login page script, we strongly recommend that you make use of version control. To do this, you should deploy the script to your Auth0 tenant via [deployment automation](/architecture-scenarios/implementation/${platform}/${platform}-deployment) or via one of the [alternative strategies](/universal-login/version-control).	
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_deployment/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_deployment/_introduction.md
new file mode 100644
index 0000000000..c301f040e3
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_deployment/_introduction.md
@@ -0,0 +1,31 @@
+In addition to adopting best practices for change management and [QA](/architecture-scenarios/implementation/${platform}/${platform}-qa), successful customers will also integrate Auth0 collateral management as part of some automated deployment process. As discussed in the Architecture section under [SDLC support](/architecture-scenarios/implementation/${platform}/${platform}-architecture#sdlc-support), you will want to ensure you configure separate Auth0 tenants for development, testing, and production environments, and you will want that configuration to be almost identical for the tenant in each environment. Using deployment automation helps ensure this, so that each environment tenant is configured the same, and you will be less likely to see bugs show up as a result of mismatched configurations between environments.
+
+::: panel Best Practice
+However you configure deployment automation, we’d recommend you unit test your rules, custom DB scripts, and hooks prior to deployment, and run some integration tests against your tenant post-deployment too. For more details regarding this, see the [Quality Assurance](/architecture-scenarios/implementation/${platform}/${platform}-qa) guidance provided.
+:::
+
+Auth0 provides support for a couple of different options when it comes to the deployment automation approaches you can use, and each can be used in conjunction with the other if desired:
+
+* The [Auth0 Deploy CLI tooling](/extensions/deploy-cli) provides you with an easy-to-use script that can help you integrate with your existing Continuous Integration/Continuous Deployment (CI/CD) pipeline.
+* If you can’t integrate directly with, or for some reason you don’t have a CI/CD pipeline, then the Auth0 [Source Control Extensions](/extensions#deploy-hosted-pages-rules-and-database-connections-scripts-from-external-repositories) can provide an easy-to-set-up basic automation process with very low maintenance.
+
+::: warning
+Note that both the Deploy CLI Tool and source control extensions can cause destructive changes; manual changes made directly in the dashboard between automated deployments could be lost! For this reason, if either is used, then **all** changes should be deployed from the source control subsystem referenced via the tooling and not made manually.
+:::
+
+Each environment may also need some environment-specific configuration--Application Client ID’s and Client Secrets will be different between the Auth0 tenants, for example--so you’re going to want some way of being able to dynamically reference this rather than having hard-coded values. Auth0 provides support for handling environment-specific configuration information through one of the following two approaches:
+
+* Use [Tenant Specific Variables](#tenant-specific-variables)
+* Use [keyword replacement](extensions/deploy-cli/references/environment-variables-keyword-mappings) if using the Auth0 Deploy CLI tool
+
+## Tenant specific variables
+
+Auth0 allows you to configure variables that are available from within custom [extensibility](/topics/extensibility); these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:
+
+* For use of variables in Rules, see how to [configure values](/rules/guides/configuration#configure-values)
+* For use of variables in Hooks, see how to configure [secrets](/hooks/secrets) in the editor
+* For use of variables in Custom DB Scripts, see the [configuration parameters](/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters) 
+
+::: panel Best Practice
+It’s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub/Gitlab/Bitbucket/VSTS, then using a tenant-specific variable avoids exposure of sensitive values via your repository.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_implementation-checklists.md b/ja-jp/articles/architecture-scenarios/_includes/_implementation-checklists.md
new file mode 100644
index 0000000000..c4624b459c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_implementation-checklists.md
@@ -0,0 +1,13 @@
+Use the links below to download a spreadsheet that includes tasks for each phase of an Software Development Lifecycle (SDLC) project.
+
+Analyze Checklist
+
+Design Checklist
+
+Build Checklist
+
+Test Checklist
+
+Deploy Checklist
+
+Monitor Checklist
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_keep-reading.md b/ja-jp/articles/architecture-scenarios/_includes/_keep-reading.md
new file mode 100644
index 0000000000..9697768911
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_keep-reading.md
@@ -0,0 +1,37 @@
+
+<% if (self !== "architecture") { %>
+* [Architecture](/architecture-scenarios/implementation/${platform}/${platform}-architecture)
+<% } %>
+<% if (self !== "provisioning") { %>
+* [Provisioning](/architecture-scenarios/implementation/${platform}/${platform}-provisioning)
+<% } %>
+<% if (self !== "authentication") { %>
+* [Authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication)
+<% } %>
+<% if (self !== "branding") { %>
+* [Branding](/architecture-scenarios/implementation/${platform}/${platform}-branding)
+<% } %>
+<% if (self !== "deployment") { %>
+* [Deployment Automation](/architecture-scenarios/implementation/${platform}/${platform}-deployment)
+<% } %>
+<% if (self !== "qa") { %>
+* [Quality Assurance](/architecture-scenarios/implementation/${platform}/${platform}-qa)
+<% } %>
+<% if (self !== "profile-mgmt") { %>
+* [Profile Management](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt)
+<% } %>
+<% if (self !== "authorization") { %>
+* [Authorization](/architecture-scenarios/implementation/${platform}/${platform}-authorization)
+<% } %>
+<% if (self !== "operations") { %>
+* [Operations](/architecture-scenarios/implementation/${platform}/${platform}-operations)
+<% } %>
+<% if (self !== "logout") { %>
+* [Logout](/architecture-scenarios/implementation/${platform}/${platform}-logout)
+<% } %>
+<% if (self !== "operations") { %>
+* [Operations](/architecture-scenarios/implementation/${platform}/${platform}-operations)
+<% } %>
+<% if (self !== "launch") { %>
+* [Launch Preparation](/architecture-scenarios/implementation/${platform}/${platform}-launch)
+<% } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_compliance.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_compliance.md
new file mode 100644
index 0000000000..8538d072c5
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_compliance.md
@@ -0,0 +1,37 @@
+There are several requirements related to privacy and compliance. Auth0 cannot provide legal guidance on your privacy or other regulatory obligations, but we can provide a curated list of privacy requirements below for which Auth0 offers features that may help you meet your obligations. Prior to launch, you should check that you’ve met all your privacy obligations and review the features outlined below to ensure you’re leveraging all the available Auth0 features to help you meet your privacy and compliance requirements. 
+
+## Publish privacy policy and obtain user consent 
+
+If you collect or process personal data about users, you should have published a privacy policy and have established procedures to ensure your operations abide by the contents of the policy. You also need to obtain a user’s consent for the collection and processing of information. Auth0 provides options for [displaying a link to your privacy policy storing user consent](/compliance/gdpr/features-aiding-compliance#conditions-for-consent).
+
+## Provide access to view, correct and erase data
+
+Privacy legislation often requires that users have the right to view and correct any data held about them. If you are a data controller, you should  provide a mechanism for this. Auth0 customers can [build a self-service feature to access and correct data via the management API](/compliance/gdpr/features-aiding-compliance#right-to-access-correct-and-erase-data).
+
+## Provide access to data portability
+
+If you are a data controller, you may be obligated to provide users a means to export their data from your system in a transportable format. Auth0 provides [user data portability mechanisms](/compliance/gdpr/features-aiding-compliance#data-portability) to help you satisfy this obligation via both manual export capabilities and the Management API which enables you to implement a self-service feature for users.
+
+## Take steps to minimize personal data
+
+You should have reviewed the personal data you collect about users to ensure it is legitimately required for the purposes of the processing covered in the privacy policy and consent. You should also confirm you have [minimized the data you collect](/compliance/gdpr/features-aiding-compliance#data-minimization), and established a data retention policy. You can optionally elect to encrypt data you store in user metadata for additional protection. 
+
+## Data retention policy enforcement automated
+
+You should have a published data retention policy and automate the enforcement of it. The Auth0 management API or the Auth0 dashboard can be used to facilitate [erasure of user accounts](/compliance/gdpr/features-aiding-compliance/right-to-access-data).
+
+## Protect personal data
+
+Regardless of whether you are a data controller or a data processor, you have obligations to protect the personal data you hold about users. This includes use of encryption where possible, and implementing reasonable security measures to protect user accounts. Prior to launch, you should check if you are using all the security features available from Auth0 to help with this such as Brute Force Detection, Multi-Factor Authentication (for both users and administrators), and a strong password policy if using passwords. You should also ensure you have a process ready to respond to [Brute Force attacks](/compliance/gdpr/features-aiding-compliance#protect-and-secure-user-data).
+
+## Supplier evaluation 
+
+Another common compliance obligation is to perform due diligence review of the security of any third-party suppliers to which you expose personal data. For Auth0, you will find information to facilitate this task on the Auth0 [security and certifications](https://auth0.com/security/) page where you can view the security certifications Auth0 has obtained.
+
+## Additional resources
+
+Additional resurces that may be useful for your compliance requirements include:
+* [Auth0 Privacy Policy](https://auth0.com/privacy)
+* [Security and Compliance](https://auth0.com/security/)
+* [GDPR and Compliance Frameworks](/compliance)
+* [Auth0 support for customer requirements](/compliance/gdpr/features-aiding-compliance)
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_introduction.md
new file mode 100644
index 0000000000..4909da3507
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_introduction.md
@@ -0,0 +1 @@
+Use this guide as you prepare for the launch of your application. We’ve included reminders about some content you may have viewed earlier during your planning or development phases as well as some new content unique to the launch phase. The sections below are useful to developers and project owners to ensure that you have everything lined up for a smooth launch. There are several things to check so it may help to assign ownership of different sections to different members of your team.
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_launch.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_launch.md
new file mode 100644
index 0000000000..c0c5526d56
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_launch.md
@@ -0,0 +1,112 @@
+## Notifications / announcements
+
+It helps a launch go smoothly if all stakeholders are aware of the impending launch and understand the launch plan as well as their role and responsibilities. In addition to notifying teams that will be actively involved, it can help to notify teams that might be needed if anything goes wrong. Having someone on standby during a launch can help expedite response. Be sure to identify and notify any team that might need to answer questions from customers, including on social media.
+
+### Parties to notify
+
+* Customers
+* Business parters, if applicable
+* Application team(s) impacted by launch
+* Support teams
+* Network teams (network changes, on standby, in case of issues)
+* Security teams (on standby, in case of issues)
+* Marketing teams (ready for announcements, response to issues)
+* Social media teams (ready to monitor social media, respond)
+* Sales teams (prepared to answer questions from customers)
+* Customer success teams (prepared to answer questions from customers)
+
+## Notification plan
+
+Your notification plan should include elements such as the target audience, the key takeaways for the audience, the message content, the plans for distributing the notification and how to test the messaging.
+
+A list of elements to include in the plan are:
+
+* Target audience (consider both internal & external audiences)
+* Message
+* Timing
+* Dependencies
+* Responsible parties (who will send it)
+* Mechanism (how it will be communicated)
+* Test message and delivery (if applicable - test to ensure notifications sent)
+
+## Notification distribution
+
+A common tactic is to release notifications in batches to spread out the initial onslaught of load and reduce the scope of confusion if there are any unforeseen glitches. It’s easier to correct issues with a small group than during a big-bang launch. 
+
+* One approach is to start with a relatively small batch of notifications, and if no issues are identified, increase the size of the batches over time. 
+* You can also send out batches on a rolling schedule around the globe to spread out load hitting the system at once and have notifications arrive at an optimal time within each timezone to increase the likelihood of the messages being read. 
+* You can do a soft-launch to a portion of users, such as individual customers, regions or some other grouping that makes sense for your application.
+
+## Outage windows (if needed)
+
+Some organizations require a formal request for an outage window if any outages or downtime is required for a launch. If your organization requires this, be sure to identify if any downtime is required for the cutover or launch (or other dependent systems) and file the necessary outage or change requests in advance of any lead-time requirements.
+
+## Cutover plan (if needed)
+
+Some launches involve cutover from a previous solution to a new solution. If your project fits this scenario, you should be sure to identify everything that needs to happen as well as any dependencies, the responsible party for each task, and necessary timing. You may wish to plan alternates for all important roles or in each region in case anyone is unexpectedly sick or otherwise unavailable. A checklist of items to consider for the cutover plan is:
+
+* Have you documented the cutover plan and rollback plan if needed?
+* Are backups needed of anything prior to change?
+* Are any preparatory data changes required?
+* Any DNS records to be changed?
+* Any Firewall changes?
+* Any new monitoring targets?
+* Any software to be deployed?
+
+## Go / no-go criteria
+
+In your overall launch plan, it is helpful to have go/no-go criteria and to have discussed in advance the types of issues which could occur and which could be worked through vs would require reverting. A launch plan can specify periodic check-in timeframes with criteria of what to assess at each checkpoint and how long to allow an issue to continue unresolved.
+
+For each stage of the launch, it helps to have success criteria defined, that indicate the launch is proceeding as planned and can continue. Some example criteria could be:
+
+* User signups growing with minimal errors
+* User logins at expected rate, minimal errors
+* Reported support issues below a certain threshold
+* No issues identified that could lead to corrupted data
+
+It’s also helpful to have identified criteria which could trigger a “no-go” decision to halt the launch. The risk tolerance for each environment varies, but a few example criteria might include:
+
+* High percent of user signup or login resulting in errors that cannot be resolved quickly
+* High number of support issues that cannot be resolved quickly
+* Condition identified that could lead to data corruption
+* High severity security issue discovered
+
+## Rollback
+
+It is always wise to have a plan for how to rollback or revert a launch, just in case something unforeseeable occurs which cannot be resolved. Reviewing the launch plan for every step which involves a change can help identify the tasks or changes requires to revert a launch or cutover.
+
+The rollback plan should include the steps to take, the sequence, how long each is likely to take and the responsible party. Understanding the cumulative time required to roll back can help to determine the timing of the final go/no-go decision to fit within any required outage window.
+
+If any data is migrated or changed for the launch, the plan should include how to revert it, if needed. Reverting may require running scripts to undo operational changes or restoring a data store from a backup taken before the launch process began. 
+
+It is also necessary to plan for the case where some data is entered into a new system before it has to be reverted. Will such data / transactions need to be abandoned with the rollback or will you have a way to capture and apply them elsewhere so they aren’t lost?
+
+If the resolution of issues or process to revert could potentially take longer than one shift, you’ll want to ensure you have a primary and perhaps a secondary person available and prepared to handle things during each work shift. If an issue results in the need for prolonged response, significantly beyond one shift, there are limits for how long people can realistically function without a break. It can help to be prepared with resources for a follow-the-sun issue response effort if needed.
+
+## Standby contacts
+
+As the launch day approaches, it’s a good idea to identify all contacts who might be needed for troubleshooting or resolving issues and request them to be on standby and ready to help if needed. The launch leader should have contact information for each person on the standby list to expedite communications.
+
+If there is a physical or virtual "launch room", the people on standby should know where it is and be ready to join if needed. Having a central room or video conference prepared can expedite communications and troubleshooting across all parties if an issue occurs.
+
+## Success Criteria
+
+A lot of planning goes into a launch in order to be successful, but will you know how to evaluate the launch? If you define success criteria before the launch, you can determine what to monitor and if any additional monitoring or checks need to be in place to evaluate the launch.
+For example - if one element of the success criteria is the number of sign-ups or logins - do you have a way of monitoring that and has it been tested to ensure it is accurate?
+
+You’ll want statistics to be able to trumpet the success of your launch. You don’t want to find out after the launch that you didn’t capture any data to quantify all the hard work your team put into the launch.
+
+## Risks & mitigations plan
+
+It’s no fun to think of things that could go wrong, but if anything happens, you’ll be glad you did as having a plan can expedite response. A few examples to plan for include:
+
+* Software application bug
+* Application incompatibility with user browser settings
+* Network failure/outage
+* DoS attack
+* Hosting environment failure
+* Load / capacity issues
+* Data / corruption issues
+* Security vulnerability discovered
+
+If you had a beta period, it may help to review the results of the beta to identify additional possible failure scenarios.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_operations.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_operations.md
new file mode 100644
index 0000000000..22a43ad85d
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_operations.md
@@ -0,0 +1,96 @@
+## Status
+
+You should ensure your operations staff knows how to monitor Auth0 service status and has set up a means to subscribe to updates on Auth0 status.
+
+<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2b' }) %>
+
+## Email provider setup
+
+You should double check that you have set up your own email provider to support production volumes of emails that might be sent to customers for signup, email validation, account recovery and the like.
+
+<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2b' }) %>
+
+## Infrastructure
+
+<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2b' }) %>
+
+## NTP
+
+If this is not handled automatically by your hosting environment, you should have scripts which will automatically restart NTP (Network Time Protocol) if it fails and alerts that will notify someone if NTP is not running.  Authentication transactions rely on accurate system time because security tokens may be evaluated as expired when received if there are time discrepancies between sending and receiving systems.
+
+## LoadBalancer timeouts checked 
+
+If you use the AD/LDAP connector, you should check the load balancer settings in your environment to see if they terminate long running connections that are inactive. If they do, you can modify the [Auth0 AD/LDAP Connection settings](/connector/modify#configuration-file) to use the `LDAP_HEARTBEAT_SECONDS` setting to send periodic heartbeat messages to keep the connection open.
+
+## LoadBalancer configuration
+
+If your application maintains server state such that it depends on sticky load balancing to route users to a particular server, it can be beneficial to double check that all load balancer configurations are correct.  One load balancer in a pool that is out of sync can cause intermittent errors that are hard to troubleshoot.  A quick check of load balancer configuration can avoid such issues in the first place.
+
+## Logs 
+
+You should check that you have set up the ability to capture log data, that logs are covered by your data retention policy and you have mechanisms to enforce logs data retention limits. You should also make sure that your development, support, and security teams know how to access logs data for troubleshooting and forensics purposes. Exporting log files to services that provide comprehensive analytics can help you identify patterns such as usage trends and errors.
+
+<%= include('../../_includes/_operations/_logging.md', { platform: 'b2b' }) %>
+
+## Monitoring
+
+Be sure to set up proactive monitoring of the Auth0 service as well as end-to-end authentication through your application. 
+
+<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2b' }) %>
+
+## Auth0 Notifications
+
+You should ensure your team is monitoring all of the following communication channels from Auth0 to stay abreast of important announcements and changes.
+
+<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2b' }) %>
+
+In addition, you should periodically check the [Auth0 migrations page](/product-lifecycle/migrations) for news about upcoming deprecations that might require your team to make changes.
+
+## Automated Deployment, version control
+
+While not required, it is highly recommended that you have deployment automation set up. You can respond more efficiently if you need to make any changes after launch if you have automated the ability to deploy and revert changes to dev, test and production environments.
+
+<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2b' }) %>
+
+## Backup / Restore
+
+You should have a plan and mechanism in place to support any backup/restore capability needed for your project. This can be done using the Auth0 Management API for data as well as the Automated Deployment capabilities described in the automated deployment section for Auth0 configuration.
+
+As noted in the Auth0 [Data Tenant Restore policy](policies/restore-deleted-tenant) and [Data Transfer policy](policies/data-transfer), Auth0 does not restore deleted tenants or move data between tenants.  Auth0 provides the Auth0 Management API to provide customers a completely flexible capability to backup, restore and move data as needed. Customers can write scripts to retrieve data from Auth0 for backup purposes, and similarly write scripts for use with the Automated Deployment capability to restore any aspect of their Auth0 configuration.
+
+## Versions Up to Date
+
+You should double check that all technologies in your application stack, as well as browser versions used by your users are on current, up-to-date versions as this will impact Auth0’s ability to provide support if issues arise.
+* Check you are using the latest supported version of node.js in [Auth0 dashboard settings](/dashboard/dashboard-tenant-settings#extensibility).
+* Check you are using a version of SDK/Libraries supported by Auth0 per the [Auth0 Support Matrix](/support/matrix).
+
+## Certificate rollover plan
+
+Certificates may be used in identity deployments. To ensure a certificate expiration does not catch you by surprise, you should have a list of certificates in your environment along with the expiration dates, how you will be notified when expiration draws near and how the certificate rollover process works.
+
+### SAML connections
+
+For SAML connections, you obtain a certificate from the IdP and upload it to a SAML connection for the IdP in your Auth0 dashboard. When one of these certificates is about to expire, Auth0 will send email to dashboard administrators warning of the upcoming expiration. You can obtain the new certificate and upload it using the connection configuration screen.
+
+### WS-Fed connections
+
+For WS-Fed connections, if you configure them by specifying an ADFS URL, any changes will be picked up by a daily update. You can trigger an update manually by visiting the connection configuration page in the Auth0 dashboard and doing a Save. If a certificate is changed at the remote IdP, Auth0 can be updated by those mechanisms or by uploading a new metadata file in the same connection configuration screen.
+
+## Disaster Recovery / Business Continuity Plan in place
+
+While not an absolute requirement prior to launch, it is useful to have a disaster recovery plan in place to ensure business continuity in the face of different types of disasters, including system outages and natural disasters hitting a region where critical staff is located.
+
+## Processes documented
+
+Another item which is not an absolute requirement, but also recommended is to ensure all processes related to Auth0 are documented. This can include the following:
+
+* Change management for configuration
+* Deployment of new changes and any automatic deployment mechanisms used, how to revert to previous version if issues found
+* Certificate rollover processes, if any
+* Adding or removing new Identity Providers, if applicable
+* Changes to user profile structure in Auth0 or in directories Auth0 pulls from
+* Adding or removing applications or APIs
+* Capturing and exporting logs
+* Backup/restore process you have implemented
+* User management (forgotten password, lost phone)
+* Root cause analysis after an incident
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_support.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_support.md
new file mode 100644
index 0000000000..3eea47b43a
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_support.md
@@ -0,0 +1,61 @@
+## Review Auth0 Policies
+
+When starting to prepare for your launch, be sure to read through [Auth0 Policies](/policies) and prepare your production operations accordingly for any required lead times or responsibilities on your part, according to the policies. 
+
+## Review your Support plan, SLAs, Severity definitions and Support center documentation
+
+You should review the specifics of the [support plan](/support#support-center) you’ve purchased and the [Service Level Agreements](/support#defect-responses) associated with it, to ensure it is adequate for your needs. If you haven’t already done so, explore the [support center](https://support.auth0.com/) and familiarize yourself with support features such as viewing suggested solutions to common issues and [filing tickets](/support/tickets) and viewing your quota usage. It will be helpful to review the [severity level definitions](/support#defect-resolution-procedures) for support tickets so that you file tickets with the correct severity. One important note is that it is not possible today in the Support Center to increase the severity of a support ticket. If you file a ticket for a medium-grade issue which later becomes a high severity issue, you should file a new urgent, high severity ticket that explains anything new that triggers the urgency and references the original ticket for details.
+
+You should also ensure your development and support teams are familiar with the [Auth0 community forum](https://community.auth0.com/), discussed further below. Customers can often find answers there right away to common issues, avoiding the need to file a ticket, so it should be your first stop for technical questions.
+
+## Review the Auth0 community forum
+
+The [Auth0 community forum](https://community.auth0.com/) contains a wealth of information. If you have a question, chances are someone else has already asked the question on the forum. Answers are contributed by both Auth0 staff and the larger community of Auth0 users. 
+
+Important notices are posted to the community forum to help you stay abreast of important news. Be sure to check out the “Community” and “FAQ” categories. The Community category contains pro-active posts on product announcements, roadmap information, How-To videos as well as important information about any upcoming feature deprecations. 
+
+It’s a good idea to check out the Auth0 Community on a regular basis, not just when you have questions. While you are there, if you see a question you’ve already solved, please contribute your wisdom to help others!
+
+## Gather Auth0 troubleshooting information needed for support tickets
+
+We recommend your support team become familiar with our [troubleshooting guides](/troubleshoot) specific to identity protocols and Auth0. This includes the questions to research and information to collect before posting a question on the Auth0 forum or filing a support ticket. Authentication transactions often span multiple systems so there are some specialized troubleshooting techniques that are helpful to learn.
+
+## Have troubleshooting tools ready
+
+Your team will doubtless have already done some troubleshooting during the development of your application, but we recommend making sure your support team is also familiar with any tools below relevant to your project. If you need to file a ticket, the Auth0 support team may ask for a HAR (HTTP Archive) file to help analyze the issue so it’s helpful for your support staff to be familiar with how to do this.
+
+### Capture HAR file
+
+A [HAR file](/troubleshoot/guides/generate-har-files) captures a sequence of browser interactions and is a commonly used tool when debugging authentication issues. The process of authenticating a user often involves redirecting the user’s browser from an application to Auth0, and possibly to another remote Identity Provider, depending on the type of connection used.  You can capture the redirection and the responses and analyze it to find clues about the cause of an issue.
+
+### Analyze HAR file 
+
+Analyze the [HAR file](/troubleshoot/guides/generate-har-files#analyze-har-files) to obtain valuable troubleshooting information. It shows the sequence of browser redirects involved in an authentication transaction, along with the parameters used. The HAR file also shows if the authentication process stopped mid-stream and if so where, which helps to pinpoint the location of the issue. The HAR file contains tokens returned to the application front-end, and these can be pasted into appropriate viewers to see if they contain the expected contents.
+
+### View JWT
+
+The [jwt.io](https://jwt.io) tool was written by Auth0 and allows you to view the contents of a JWT-formatted token. Applications that delegate authentication to Auth0 via OIDC will receive an ID Token from Auth0. Depending on your type of application, the ID Token may be captured in a HAR file. The ID Token is in JWT format and can be pasted into jwt.io to view the contents of the ID Token.
+
+### View SAML request/response
+
+There are many SAML decoders available. The [samltool.io](https://samltool.io) decoder was written by Auth0 and allows you to view the contents of a SAML Request or Response. Applications that delegate authentication to Auth0 via SAML or use a SAML type of connection in Auth0 will use SAML Requests and Responses. These SAML Requests and Responses may be captured in a HAR file. The requests and responses can be pasted into samltool.io or other SAML decoders to view the contents of the SAML Request or Response.
+
+## Review Auth0 support matrix
+
+One potential cause of issues is using out of date versions of SDKs or libraries. We strongly recommend your team check your software stack, browsers, SDKs and libraries against the [Auth0 support matrix](/support/matrix) to ensure you are running on up-to-date, supported versions. In the event of an issue, the Auth0 support team may ask you to upgrade to a supported version. To avoid slowing down progress on issue resolution, be sure you are on up-to-date versions.
+
+## Use Auth0 feedback portal
+
+Auth0 welcomes feedback and ideas from Auth0 customers. If you have a suggestion for our product team, you can submit product feedback directly on the [Product Feedback portal](https://auth0.com/feedback). 
+
+## Prepare real-time webtask log extension 
+
+For debugging and supporting custom code in Auth0, including Rules, Hooks, Custom DB Scripts, and Custom OAuth Connections, knowledge of the [Realtime Webtask Log](/extensions/realtime-webtask-logs) is essential. This enables you to view output from your custom code, including output from console.log statements. 
+
+::: panel Best Practice 
+We recommend installing the real-time webtask log extension and getting familiar with using it to view log output from your custom code as a debugging and support tool. 
+:::
+
+## Troubleshooting
+
+You should prepare to [troubleshoot issues](/troubleshoot/basics) both during your development as well as after your application or API goes live.  Make sure your development and support teams are prepared with knowledge of troubleshooting tools, and the list of common issues to check when troubleshooting an issue.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_tenant-check.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_tenant-check.md
new file mode 100644
index 0000000000..2f9f2ce0d5
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_tenant-check.md
@@ -0,0 +1,112 @@
+## Tenant Check
+
+This section covers a list of configurations to check in your tenant. This should be done periodically during development and sufficiently before launch so you have time to fix anything amiss.
+
+### General tenant check
+
+#### Tenant preparation check
+
+Check to ensure you have [set up tenant environments](/dev-lifecycle/setting-up-env) to support your SDLC lifecycle and that Dev, Test and Prod tenants are cleanly separated so that ongoing development work after launch doesn’t negatively impact your production environment.
+
+<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2c' }) %>
+
+#### Tenant association check
+
+<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2c' }) %>
+
+#### Specify production tenant
+
+To ensure Auth0 recognizes your production tenant, be sure to [set your production tenant](/dev-lifecycle/setting-up-env#set-the-environment
+) with the “production” flag in the Support Center.
+
+#### Tenant production Check
+
+Auth0 provides a [Production Check](/pre-deployment) facility to detect many common errors. You should ensure this has been run and any findings from the report mitigated before launch.
+
+In addition, you should check the [best practice configurations advice](/pre-deployment/tests/best-practice), for which checking cannot be automated.
+
+#### Tenant Settings Check
+
+##### Tenant Settings
+
+Make sure to follow the [Auth0 tenant settings best practices](/best-practices/tenant-settings#set-up-branding-configuration) in configuring your logo as well as your support email and support URL so user's know how to get help if an issue occurs. You'll want to check your SSO Session Timeout settings and the list of dashboard admins with access to your production tenant as well. For further information on tenant setting, see the Auth0 dashboard [tenant settings documentation](/dashboard/dashboard-tenant-settings#settings).
+
+##### Error Page Customization
+
+<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2c' }) %>
+
+##### Legacy feature flags off
+
+If you have an older tenant, you may have various legacy feature flags enabled in your [tenant settings advanced tab](/dashboard/dashboard-tenant-settings#advanced). If you have any toggles on in the “Migrations” section of this tab, you should review your usage and make plans to migrate off the legacy feature. 
+
+##### Delegated admin extension
+
+While you are checking the list of users with access to your production tenant, don't forget to check any users specified in the [Delegated Admin Extension](/extensions/delegated-admin/v3).
+
+#### Custom Domain Naming set up
+
+<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2c' }) %>
+
+### Application  and Connection settings check
+
+Each of your application configurations in Auth0 should be checked against the [application configuration best practices](/best-practices/application-settings).
+
+Each of your connection settings should be reviewed against the [connection configuration best practices](/best-practices/connection-settings).
+
+In addition, you should review that all connections are appropriate and that no experimental connections are left in your production tenant as they could enable unauthorized access.  
+
+If you use SAML connections, it is a best practice to configure the connections to sign SAML requests.
+
+### Page customization check
+
+If you use the Auth0 universal login page, password reset page, or Guardian multi-factor authentication, you should check that you have adequately customized the pages displayed to the end user.
+
+#### Universal Login Page
+
+<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2c' }) %>
+
+#### Password Reset Page customization
+
+<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2c' }) %>
+
+#### Guardian
+
+<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2c' }) %>
+
+### Authorization check
+
+If you are using Auth0’s [authorization feature](https://auth0.com/docs/authorization), be sure to double check all privileges granted to ensure authorizations are appropriate for your production environment.
+
+### API configuration check
+
+#### Access token expiration
+
+You should double check the [API access token expiration settings](/dashboard/reference/settings-api) to ensure they are appropriate for each API in your production environment.
+
+#### API offline access
+
+If your application does not request refresh tokens, this should be off.
+
+#### Access token signing algorithm
+
+It is recommended that the [API access token signing algorithm](/getting-started/set-up-api#signing-algorithms) be set to RS256 rather than HS256 to minimize exposure of the signing key. 
+
+#### API Access token validation
+
+If you have any custom APIs, be sure to check that they are adequately [validating the access tokens](/api-auth/tutorials/verify-access-token) they receive before using the information in them.
+
+### API Scopes
+
+If you have applications making machine-to-machine calls to any of your APIs, you should review the scopes specified for the API to ensure they are all appropriate for your production environment. For further information see the documentation on [client credentials grant](/api-auth/config/using-the-auth0-dashboard).
+
+### Rules/Hooks check
+
+You should also have aligned your rules with Auth0 [rules best practices](/best-practices/rules).
+
+### Email templates customized
+
+<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2b' }) %>
+
+### Attack protection configured
+
+<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2b' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_launch/_testing.md b/ja-jp/articles/architecture-scenarios/_includes/_launch/_testing.md
new file mode 100644
index 0000000000..7ceb804ac1
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_launch/_testing.md
@@ -0,0 +1,25 @@
+Prior to launch, you should have completed all the testing that applies to your environment. 
+
+<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2c' }) %>
+
+### Unit testing
+
+<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2c' }) %>
+
+### Integration testing
+
+<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2c' }) %>
+
+### Mock Testing
+
+<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2c' }) %>
+
+### Pen testing (optional)
+
+If you will be conducting penetration tests, you should be aware of Auth0’s [penetration testing policy](/policies/penetration-testing) and abide by it. Penetration tests require advance notice to Auth0 so that your tests are not mistaken for malicious activity and shut down.
+
+### Load testing (optional)
+
+If you will be conducting load tests, you should be aware of Auth0’s [load testing policy](/policies/load-testing) and abide by it. Load tests require advance notice to Auth0. In planning your load testing, you will also need to be aware of Auth0’s [API rate limits](/policies/rate-limits).
+
+<%= include('../../_includes/_qa/_load-testing.md', { platform: 'b2c' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_logout/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_logout/_introduction.md
new file mode 100644
index 0000000000..08510e5ea8
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_logout/_introduction.md
@@ -0,0 +1,47 @@
+[Logout](/logout) is the act of terminating an authenticated session when it's no longer needed, thus minimizing the likelihood that unauthorized parties can "take over" the session. This is typically achieved by provisioning a logout option on the user interface you provide to your users. Multiple types of sessions can be created when a user logs in (e.g., local application sessions, Auth0 session, third-party Identity Provider sessions), and you will need to determine which of these sessions need to be terminated when the user clicks any **Logout** option.
+
+::: panel Best Practice
+Your logout behavior should make it clear to a user which session(s) are being terminated, and ideally, will display a visual confirmation of logout afterward.
+:::
+
+When configuring logout behavior, you'll need to consider:
+
+* Which sessions should be terminated when the user initiates logout?
+* What information should you provide to users as confirmation of the sessions terminated?
+* Where should users be redirected to after logout completes?
+* How long do you want sessions to last in the event that users do not trigger the logout process?
+<% if (platform === "b2b") { %>
+* Should the End User be logged out of all of their application sessions when they log out of one?
+* Should the session with an organization's IDP also be terminated at logout?
+<% } %>
+
+Given the varying types of sessions that can be created whenever a user logs in, there are several types of logout possible. Local application logout ends the session with the application, whereas Auth0 logout [terminates the Auth0 session](/logout/guides/logout-auth0). If you have organizations that are using their own IDP, you may want to consider a [Federated Logout](#federated-logout) strategy and implement accordingly. Global, or [Single Logout](/logout/guides/logout-applications) (SLO), ends the Auth0 session and also sends a logout request/notice to applications relying on the Auth0 session.
+
+The functionality provided by your application, as well as your use of features like [Single Sign-on (SSO)](/sso), will inform your decision as to what type of logout is required and what visual confirmation you'll need to provide to your users. Regardless of which option you choose, the logout process you implement should make it clear to the user which sessions are being terminated, and also when the logout process has completed.
+
+::: warning
+If the logout feature in one application terminates an Auth0 SSO session that is used by other applications, the user may lose work if they have uncommitted transactions. Be sure to add the functionality needed to handle such conditions to minimize the likelihood of lost work.
+:::
+
+<% if (platform === "b2b") { %>
+In some situations, a user may be expected to logout of all associated applications when they log out of any one of the applications you provide. This is something that can add complexity. However if you have concerns that users could leave themselves vulnerable (perhaps due to data sensitivity or the like), then you will likely need to review [Single Logout](#single-logout) and implement accordingly.
+
+<%  } %>
+
+## Where to send users after logout
+
+Once your user logs out, they will be redirected to a specific location of your choosing. This location is specified as the **logout redirect URL**, and you can [define this as a parameter](/logout/guides/redirect-users-after-logout) via the Auth0 Dashboard.
+
+The URL(s) you use to redirect users after logging out must be [whitelisted in the Dashboard](/logout#redirect-users-after-logout) to mitigate open-redirect security vulnerabilities. You can whitelist them at the tenant or application levels.
+
+::: note
+If the user logs out and you redirect them back to the application, and the application redirects to an Identity Provider that still has a valid session for the user, the user will be logged in silently to the application. This may appear to the user as if the logout process didn't function properly.
+:::
+
+## Automatic termination of sessions
+
+Not all users will trigger the logout process manually, so Auth0 also provides **session timeout** to prevent overly long-lived sessions. This setting is [available and configurable via the Auth0 Dashboard](/dashboard/reference/settings-tenant#login-session-management).
+
+::: panel Get Started with Auth0 Video
+Watch this short video [Logout](/videos/get-started/10-logout) to learn about different kinds of logout behavior and different session layers. Learn how to configure callback URLs in the application and tenant settings in the Dashboard.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_multitenancy.md b/ja-jp/articles/architecture-scenarios/_includes/_multitenancy.md
new file mode 100644
index 0000000000..50c06de00b
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_multitenancy.md
@@ -0,0 +1,3 @@
+Many B2B platforms implement some form of isolation and/or branding for their customers' organization, and this can add complexity to any Identity and Access Management (IAM) system.  If this applies to you, then we recommend you take some time to read through our guidance and best practice advice concerning this type of environment. 
+
+Multiple Organization Architecture (Multitenancy) Overview
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_email-provider.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_email-provider.md
new file mode 100644
index 0000000000..8f83e0bece
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_email-provider.md
@@ -0,0 +1,5 @@
+Auth0 sends [emails](/email) to users for events such as signup welcome, email validation, breached password, and password reset events. You can customize the email templates for each type of event, and advanced customization of email handling is also possible. Auth0 provides a test email provider with limited capacity for basic testing, but you must set up your own email provider for production use, and customization of email templates will not work until you have established your own provider. 
+
+::: panel Best Practice
+The default Auth0 email provider does not support sending production volumes of email or customization of email templates. You should therefore configure your own email provider before deploying to production.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_infrastructure.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_infrastructure.md
new file mode 100644
index 0000000000..540e16cd72
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_infrastructure.md
@@ -0,0 +1,3 @@
+### Firewalls
+
+If custom code executing in Auth0 (such as in a Rule, Hook, or Custom DB scripts) will call a service inside your network, or if you configure an on-premise SMTP provider in Auth0, then you may need to configure your firewall to allow [inbound traffic from Auth0](/guides/ip-whitelist#inbound-calls). The IP addresses to allow through the firewall are specific to each region and are listed on the Rules, Hooks, Custom DB scripts, and email provider configuration screens in your Auth0 dashboard (as described in [Whitelist IP Addresses](/guides/ip-whitelist)).
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_introduction.md
new file mode 100644
index 0000000000..33fb73bae3
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_introduction.md
@@ -0,0 +1,29 @@
+Operationalization requires configuring or setting up infrastructure to support the scalable, measurable, and quantifiable operation that’s necessary for business continuity. In Auth0, this includes configuring supporting services (such as email providers), monitoring services for your deployment, detecting anomalous situations, and making preparations to recover quickly and smoothly when something goes wrong in a production environment.
+
+Establishing effective operational behaviors is something that successful customers have found pays dividends, and there are a number of things you will want to consider when looking at your workflow:
+
+*	What should you do to proactively detect failures?
+*	How can you obtain data on Auth0’s operational status?
+*	What should you do about Auth0 security bulletins related to the Auth0 service?
+*	Does Auth0 provide information regarding impending changes in the Auth0 service?
+*   How can you check for important notices from Auth0?
+*	What should you do with Auth0 log data so that you can analyze it and keep it for longer than Auth0’s limited data retention period?
+*	How can you scan Auth0 logs to determine if peak loads in your application trigger any rate limits or other errors?
+*	What email services should you use to support production volumes of email messages to users? Can I use Auth0's out-of-box email provider in my production environment?
+*	Do you need to configure your firewall and what firewall ports will you need to open for internal services that need to receive communications from Auth0 (such as custom databases, web services, and email servers)?
+<% if (platform === "b2b") { %>
+* How will you provision new organizations?
+* Do you need to provide self-service provisioning for your customer so that they can configure their own organizational IdPs?
+<%  } %>
+
+Auth0 supports functionality for [monitoring](#monitoring) Auth0 service operation as well as providing information regarding Auth0 [service status](#service-status). In addition, Auth0 makes security-related bulletins as well as information regarding upcoming changes to the Auth0 service available via various [notifications](#notifications). Auth0 [logging](#logging) services also provide extensive functionality for tracing and identifying operational anomalies, including restrictions encountered due to rate limiting and/or excessive loading.
+
+Out-of-box, Auth0 provides email delivery services to help you accelerate your integration. These services, however, are not meant for scale-of-use in production environments, and do not provide for any specific service level or guarantee when it comes to email delivery. Our best practice recommendation, which customers typically follow, involves configuring your own [email service provider](#email-provider-setup).
+
+You may also need to make changes to [infrastructure](#infrastructure) configuration in order to support integration with Auth0 and to support use of Auth0 extensibility. For example, if you need to provide callbacks to your internal or even external infrastructure (e.g., if you need to make external API calls in Rules or Hooks, or via custom database scripts if you need to leverage existing legacy identity storage), then you may need to configure your Firewall settings.
+
+<% if (platform === "b2b") { %>
+Once you know how you want organizations to be represented in your system, you will want too consider how you are going to provision the organization itself.  See [Provisioning organizations](#provisioning-organizations) for more information.
+
+In addition, many of our customers have developed one or more self-service portals for use by their customers' organization admins to provide self-service capabilities for configuring their own [IdPs](#self-service-idp-provisioning).
+<%  } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_logging.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_logging.md
new file mode 100644
index 0000000000..41ce91d599
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_logging.md
@@ -0,0 +1,15 @@
+Auth0 provides extensive capability when it comes to the logging of events, and also in the scanning of logs in order to identify event anomalies (see [logs documentation](/logs) for further details). Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services will allow you to retain logs outside of this, and will also provide for log aggregation across your organization.
+
+::: panel Best Practice
+You should leverage one of the Auth0 logs extensions to send log data to an external log analytics service. This will enable keeping data for longer periods of time and provide advanced analytics on the log data.
+:::
+
+You should review the log data [retention period](/logs/references/log-data-retention) for your subscription level, and implement a log data export extension to send log data to an external log analytics service. Development teams can use log files for troubleshooting and detecting intermittent errors that may be hard to find via QA tests. Security teams will probably want log data in case forensic data is ever needed. Exporting log files to services that provide comprehensive analytics can help you see patterns such as usage trends and attack protection triggers. 
+
+### Rate limits and other errors
+
+Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You should set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you will find it helpful to scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)).
+
+::: panel Best Practice
+Calling the Management API to retrieve user profile information from within a Rule is a common cause of rate limit errors because such API calls can execute for every login as well as periodic session checks.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_monitoring.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_monitoring.md
new file mode 100644
index 0000000000..d64277752e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_monitoring.md
@@ -0,0 +1,5 @@
+You should establish mechanisms for [monitoring Auth0 implementations](/monitoring), so your support or operations team receives the timely information needed to proactively handle service outages. Auth0 provides monitoring endpoints that can be incorporated into your monitoring infrastructure. These endpoints are designed to provide a response suitable for consumption by monitoring services. It should be noted that they only provide data on Auth0. For complete end-to-end monitoring, which is essential for checking the ability of users to log in, we recommend that you set up synthetic transaction monitoring. This will provide greater granularity for your monitoring and enable you to detect outages unrelated to Auth0 as well as degradation of performance, so you can respond more proactively.
+
+::: panel Best Practice
+You should set up the ability to send synthetic login transactions to facilitate end-to-end monitoring of authentication. You can do this with a simple application that uses the [Resource Owner Password Grant](/api-auth/tutorials/password-grant) in combination with a test user that has no privileges, and don’t forget about [Auth0 rate limiting policies](/policies/rate-limits) too. 
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_notifications.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_notifications.md
new file mode 100644
index 0000000000..57dd93c1f9
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_notifications.md
@@ -0,0 +1,21 @@
+There are several different types of notifications from Auth0 that you should watch for as they contain important information that could impact your tenant(s) and project.
+
+::: note
+Proactive security notifications and other operational announcements are sent by Auth0 to dashboard administrators. You should ensure that the people who need to receive such messages are dashboard administrators.
+:::
+
+### Dashboard notifications
+
+From time to time, Auth0 may send an important announcement related to your tenant. These announcements about your service will be sent to your Auth0 dashboard and depending on the severity of the announcement, via email to the registered Auth0 dashboard administrators. You should make a regular practice of logging in to the dashboard and checking the bell icon at the top for any important notices. In addition, you should review emails from Auth0 in a timely fashion as they may convey important information about changes or actions you need to take.
+
+### Auth0 security bulletins
+
+Auth0 regularly conducts a number of security-related tests, and if any issues are found, will proactively identify and notify customers who need to make security-related changes. Due to the extensible nature of the Auth0 product, however, it may not be possible for Auth0 to identify every impacted customer, so you should regularly check Auth0 [security bulletins](/security/bulletins). You should make sure a security contact for your organization is listed in Support Center.
+
+::: panel Best Practice
+It is a best practice to check the Auth0 [Security Bulletins](/security/bulletins) page periodically and take the recommended action if you are impacted by any security bulletins.
+:::
+
+### Change log
+
+Auth0 provides information on changes to the service in the Auth0 [change log](https://auth0.com/changelog). You should make a regular practice of reviewing Auth0 change logs to be aware of changes. Support teams researching an issue may find it useful to review the change log to determine if recent changes might be related, especially if these are [breaking changes](/migrations). Development teams will also want to review the change logs to identify new features that may be beneficial.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_operations/_service-status.md b/ja-jp/articles/architecture-scenarios/_includes/_operations/_service-status.md
new file mode 100644
index 0000000000..a42bdbd948
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_operations/_service-status.md
@@ -0,0 +1,7 @@
+The Auth0 [status dashboard](https://status.auth0.com/) together with the Auth0 [uptime dashboard](http://uptime.auth0.com/) shows current and past status of the Auth0 service in a human-readable format. If any monitoring alerts are triggered, and as a first step in troubleshooting, your operations staff should check the status dashboard to see if there is a current outage. The public cloud status page also provides a facility for subscribing to outage notifications, and we also recommend that you check the status of any 3rd party, [external services](/monitoring/guides/check-external-services) you depend on - such as Social Providers. Having this information handy can help quickly eliminate possible causes when troubleshooting an issue and should be at the top of a troubleshooting checklist for developers as well as the helpdesk staff.
+
+::: panel Best Practice
+Information on how to check the status of Auth0 as well as any dependent services (such as Social Providers) should be at the top of a troubleshooting checklist for both developers and helpdesk staff, and we recommend you subscribe via the Auth0 status page to set up notification of any status updates. 
+:::
+
+In the event of an outage to the public cloud service, Auth0 performs a Root Cause Analysis (RCA) and publishes the results on the [Auth0 status page](/support#auth0-status). Auth0 performs a thorough investigation after an outage--including a determination of root cause, as well as contributing factors and how to prevent the issue from occurring again--and as a result, an RCA document can take a few weeks to be published.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_planning.md b/ja-jp/articles/architecture-scenarios/_includes/_planning.md
new file mode 100644
index 0000000000..8ad9191355
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_planning.md
@@ -0,0 +1,9 @@
+We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies. 
+
+<% if (platform === "b2b") { %>
+B2B IAM Project Planning Guide
+<%  } %>
+
+<% if (platform === "b2c") { %>
+B2C IAM Project Planning Guide
+<%  } %>
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md
new file mode 100644
index 0000000000..0306b71049
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_account-verification.md
@@ -0,0 +1,3 @@
+You’ll also need to work with a verified user account at all times and make use of the mechanisms Auth0 provides. You should also consider regulatory compliance like [GDPR](https://eugdpr.org/) which has very specific requirements for protecting EU citizens from privacy and data breaches.  
+
+Auth0 provides out-of-box functionality for sending a [verification email](/email/custom#verification-email) to a user's email address to verify their account. By default, Auth0 automatically sends verification emails for any [Database Connection](/connections/database) identity created as part of [self sign-up](/architecture-scenarios/implementation/${platform}/${platform}-provisioning#self-sign-up). However, Auth0 also provides a [Management API endpoint](/api/v2#!/Tickets/post_email_verification) that you can use to send verification emails in cases where email address validation is not performed by a Social Provider upon user registration. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md
new file mode 100644
index 0000000000..d66954e4a6
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_blocking-users.md
@@ -0,0 +1,3 @@
+[Blocking user access](/users/guides/block-and-unblock-users) in Auth0 provides a way to prevent user login to applications under certain conditions. By default, the Auth0 Dashboard provides an out-of-the-box mechanism to give administrators the ability to both block and unblock user access to all applications, and you can implement this functionality via use of the [Auth0 Management API](/api/management/v2#!/Users/patch_users_by_id). You can also use Auth0 extensibility to [disable user access to certain applications](/users/guides/manage-user-access-to-applications) as well as provide more fine-grained [access control](/architecture-scenarios/implementation/${platform}/${platform}-authorization).
+
+In addition, the Auth0 Management API provides you with the ability to [unblock](/api/management/v2#!/User_Blocks/delete_user_blocks_by_id) users disabled due to excessive use of incorrect credentials.  
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md
new file mode 100644
index 0000000000..cfbccfab6c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_de-provisioning.md
@@ -0,0 +1,7 @@
+Your application may need to support a user’s request to remove their account (for example, you might need to meet [GDPR](https://eugdpr.org/) requirements). You can implement such a feature, along with a number of other profile-related functions, using the [Management API](/api/management/v2#!/Users). The Management API allows you to retrieve information stored about a user and update it as required.
+
+Auth0 is capable of supporting various privacy-related requirements including the display of links to consent notices on signup and data protection to support the rights of users to view and correct data you’ve collected about them.
+
+::: note
+[GDPR](https://eugdpr.org/) and other privacy directives require that users have the right to view and correct data held about them. They also have the right to be “forgotten.” You can use the Management API to address these requirements and meet your legislative obligations.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md
new file mode 100644
index 0000000000..d0098b386d
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_introduction.md
@@ -0,0 +1,49 @@
+At some point, you may need to change the information stored in a user’s [profile](/users/concepts/overview-user-profile). A user’s profile (also known as the user’s account) is stored in Auth0, and changes to the information it contains may need to happen for a number of different reasons:
+
+* Self-served information updates
+* Mandatory updates concerning your organizations T's & C’s
+* Changes due to regulatory compliance
+
+::: warning
+You cannot directly access a user profile across multiple Auth0 tenants. If you’re deploying multiple Auth0 tenants to production then this is something you need to be aware of.
+:::
+
+An [Identity Provider](/identityproviders) populates a user’s profile using data supplied during the login process, and this is referred to as the [Normalized User Profile](/users/normalized/auth0).
+
+::: note
+The Normalized User Profile is updated from the identity provider during login, and you can change the limited set of the information it contains through the Auth0 Management API. You can also use Auth0 extensibility, such as [Rules](/rules), as an alternative to override information in the Normalized User Profile. See [User Profile Data Modification](/users/concepts/overview-user-profile#user-profile-data-modification) for more information.
+:::
+
+By default, there is one user profile created for each user identity, and there are a number of things to consider:
+
+* What should you do if you need to store information to help customize a user’s experience?
+* What if you need to store user information that didn’t originate from an identity provider?
+* Why would you need to store user-related information that a user cannot modify?
+* What do you do if you need to store user-related information that a user cannot modify?
+* What happens if a user forgets their password?
+* What should a user do if they want to change their password?
+<% if (platform === "b2b") { %>
+* How do you provide an administrator from a third-party organization with the ability to manage their users?
+<%  } %>
+
+Auth0 provides for the storage of [Metadata](#metadata) against a user’s profile, which allows for the capture of additional information, such as preference for language and/or accessibility in order to enhance the user experience. Metadata can be used to store both information that a user can change, and also information they can’t; the latter giving you the capability of associating, for example, a user profile with records in your existing systems without modifying existing implementation.
+
+For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism (or self-service mechanism you have planned), you can leverage Auth0-provided [Password Reset](#password-reset) functionality. This can be integrated with your existing implementation and comes already incorporated with any out-of-box Auth0 UI widgets including [Universal Login](/universal-login).
+
+You’ll also want to make sure that you are working with a [verified user account](#account-verification) at all times. Auth0 provides out-of-box mechanisms for doing that too. You should also consider [regulatory compliance](/compliance) such as ([GDPR](https://eugdpr.org/) which has very specific requirements when it comes to protecting EU citizens from privacy and data breaches.
+
+Though Auth0 doesn’t currently provide a centralized profile management portal out-of-the-box, for the purpose of self-serviced profile management, you can use the Auth0 Management API to build your own or utilize an already built UI. See our Auth0 [community guidance](https://community.auth0.com/t/how-to-allow-the-end-user-to-update-their-own-profile-information/6228)which describes the Management API endpoint. All calls to the Management API will require use of an [Access Token](/tokens/concepts/access-tokens).
+
+::: warning
+Self-service profile management can raise security as well as data privacy concerns. For example, you may want to allow a user to change their email address, however, doing so without following best practice security guidance could result in a user locking themselves out of their account, leaking Personally Identifiable Information (PII), or worse, opening up a potential breach in security.
+:::
+
+Alternatively, you can use the Auth0 Dashboard to [manage aspects of a user’s profile](users/guides/manage-users-using-the-dashboard). Managing a user’s profile via the Auth0 Dashboard is more of an administrative provision and **should not** be used for self-serviced profile management in a production environment. However, the interface provided by the Dashboard can be extremely useful during development as it provides a quick and simple way of manipulating a user’s profile information.
+
+<% if (platform === "b2b") { %>
+If you need to provide a way for your customers to have an administrator manage their own users when they are storing those credentials in your system, you can either build something yourself or use an Auth0 Extension. See [Admin Portal](#admin-portal) for more information.
+<%  } %>
+
+::: panel Get Started with Auth0 Video
+Watch this video [User Profiles](/videos/get-started/06-user-profiles) to learn what Auth0 User Profiles are used for and what they contain. Understand how Auth0 normalizes user profile data from various identity providers and uses metadata and root attributes. You can manage user profiles with the Auth0 Dashboard.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md
new file mode 100644
index 0000000000..572f16a38e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_linking-accounts.md
@@ -0,0 +1,9 @@
+By default, there is one [user profile](/users/concepts/overview-user-profile) (user account) for each user identity. If you enable login from multiple identity providers - via Facebook or Google [social authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#social-authentication) as well as via Auth0 [username and password authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#username-and-password-authentication) - then each will have a separate user profile. You can use Auth0’s functionality for [linking user accounts](/users/concepts/overview-user-account-linking) to create one profile for a user as an aggregate of all their associated identities. 
+
+The process of linking accounts merges user profiles in pairs: a primary account and a secondary account must be specified in the linking process. The number of accounts that can be linked, however, extends beyond a single pair. For example, you can use an account which already has multiple accounts merged with it as the primary, and link an additional secondary account to it. This means that one user account can have multiple identities associated with it, which provides a number of advantages: 
+
+* Users can log in using multiple identities without creating a separate profile for each one.
+* Registered users can use new login identities, but continue using their existing profile.
+* Users can carry their profile around, irrespective of which identity they use for login.
+* Users can link to an account with more identity information in order to provide a more complete profile.
+* Your applications can retrieve connection-specific user profile data.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md
new file mode 100644
index 0000000000..8fe125d585
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_metadata.md
@@ -0,0 +1,23 @@
+In addition to the Normalized User Profile information, [Metadata](/users/concepts/overview-user-metadata) can be stored in an Auth0 user profile. Metadata provides a way to store information that did not originate from an identity provider, or a way to store information that overrides what an identity provider supplies. 
+
+::: panel Best Practice
+Use of Metadata should follow Auth0 [user data storage best practices](/best-practices/user-data-storage-best-practices#metadata). Metadata storage is not designed to be a general purpose data store, and you should still use your own external storage facility when possible. Metadata size and complexity should also be kept to a minimum, and the Auth0 Management API has a strict set of guidance when it comes to updating and/or deleting metadata associated with a user.
+:::
+
+You can manipulate metadata via both the Auth0 Management API and the Auth0 Authentication API. See [Manage User Metadata](/users/guides/manage-user-metadata) for more information. As is the case when managing the Normalized User Profile, calls to the Management API for manipulating Metadata requires use of an [Access Token](api/management/v2/tokens).
+
+::: warning
+<%= include('../../_includes/_rate-limit-policy.md') %>
+:::
+
+### User metadata
+
+User metadata (also referred to as `user_metadata`) is information that can be stored against a user profile and that a user can read and update as part of any self-service profile management. Metadata of this nature may be something like salutation for a user, or a user’s preferred language which could be used to [customize the emails](/email/templates#common-variables) sent by Auth0.
+
+::: panel Best Practice
+Store any information that you want use to customize Auth0 emails in metadata and preferably `user_metadata` if the user is allowed to change it, such as information used to determine the language for an email.   
+:::
+
+### App metadata
+
+App metadata (also referred to as `app_metadata`) is, on the other hand, information that can be stored with a user profile but can **only be read or updated with appropriate authorization**; `app_metadata` is not directly accessible to a user. This type of metadata could be something like a flag to indicate that the last set of valid terms and conditions was accepted by the user, and a date to indicate when the user accepted them.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md
new file mode 100644
index 0000000000..0407264659
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_profile-mgmt/_password-reset.md
@@ -0,0 +1,9 @@
+For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism, Auth0 provides [Password Reset](/connections/database/password-change) functionality. You can integrate this with your existing implementation and comes already incorporated with out-of-the-box Auth0 UI widgets included as part of [Universal Login](/universal-login). 
+
+::: warning
+Password change and password reset is only supported for Auth0 [Database Connection](/connections/database) types. 
+:::
+
+Auth0 Universal Login provides built-in UX support for password reset using Auth0 Authentication API functionality. Alternatively, you can use the [Auth0 Authentication API](/connections/database/password-change#use-the-authentication-api), through one of the Auth0 SDKs appropriate to your development environment. Email templates used during password reset workflow can also be fully customized, whether you use Auth0 out-of-box UI widgets or customized Universal Login.  
+
+You can use the Auth0 Management API, on the other hand, to [directly change the password](/connections/database/password-change#directly-set-the-new-password) for a user identity defined using a Database Connection type. You can use the Auth0 Management API as part of any self-service profile management implementation, and also as part of any [Change Password page customization](/architecture-scenarios/implementation/${platform}/${platform}-branding#change-password-page-customization). 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md
new file mode 100644
index 0000000000..5571357acc
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_deprovisioning.md
@@ -0,0 +1 @@
+Auth0 will *not* communicate with the upstream IdP if there is an active SSO session with Auth0, unless you force it with a `prompt=login`. If one of your customer organizations can not manage logout for those users, they may still have access after they’ve been decommissioned. Depending on the IdP, if Auth0 gets a token for their API, you can request information about the user from the IdP in a [rule](/rules) to poll whether that user should still have access or not. If you don’t have this ability, you will have to provide your customer organizations a way to trigger a block or decommission of users in your system either through an API call or a UI.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_introduction.md
new file mode 100644
index 0000000000..4a6ec7c089
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_introduction.md
@@ -0,0 +1,33 @@
+Determining how users get signed up is important to address early, and the decisions you make here will influence many of the decisions you will need to make going forward. We’ve found there are a typical set of patterns for how users will get added to your system, and things to take note of when considering workflow design too.
+
+::: panel Best Practice
+Whilst Auth0 supports numerous workflows, web based workflows using Auth0 [Universal Login](/universal-login) for sign up are considered both industry and Auth0 best practice as they provide for optimal functionality and the best security.
+:::
+
+Auth0 supports user sign up via a number of different [identity providers](/identityproviders). During sign up, Auth0 provisions the [user profile](/users/concepts/overview-user-profile) so that it contains the user’s account information. There are a number of things to consider when looking at functionality and workflow:
+
+<% if (platform==="b2b") { %>
+* Does a user get added to your company's domain or do they belong to or remain in their organization's domain?
+* If the user stays in their own domain, do they belong to a single organization or can they belong to multiple organizations?
+* How do you provision the organization itself in your system?
+<% } %>
+* Should you use Auth0 as an identity store?
+* Can you use your own (legacy) identity store with Auth0?
+* How do you migrate user identities from your identity store to Auth0?
+<% if (platform==="b2c") { %>
+* Can your users sign up using their existing social accounts such as Google and Facebook?
+<% } %>
+<% if (platform==="b2b") { %>
+* Can your users sign up using their organization's identity provider?
+* Can your users be invited or self register?
+
+One of the first determinations to make when providing your service(s) to other businesses is identifying to which domain users belong. Based on the answer to that question, there are a couple of different approaches you can take to provision those users. See [Provisioning organization users](#provisioning-organization-users) for more information.  Once you know how you want organizations to be represented in your system, you will want too consider how you are going to provision the organization itself.  See [Provisioning organizations](#provisioning-organizations) for more information.
+<% } %>
+
+Auth0 provides out-of-the-box identity storage that can be leveraged to store user credentials safely and securely. See [Self Sign Up](#self-sign-up) for more information. If you already have a legacy identity store and you want to offload the management of it, then the [User Migration](#user-migration) capabilities provide you with a number of options to do so.
+
+Alternatively, if you have to maintain your legacy identity store - perhaps because you’ve got applications which you aren’t ready to migrate or which can’t be migrated - then you can use the [identity store proxy](#identity-store-proxy) capability. Allowing your customers to use “bring their own identity” is also an attractive proposition and though we find our customers don’t initially do so, you can use the [Social Sign Up](#social-sign-up) capability to provide it. 
+
+::: panel Get Started with Auth0 Videos
+Watch these two short videos [Provision: Users Stores](/videos/get-started/02-provision-user-stores) and [Provision: Import Users](/videos/get-started/03-provision-import-users) to learn how user profiles are provisioned within an Auth0 tenant and how Auth0 allows you to move your existing users to an Auth0 user store.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_organizations.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_organizations.md
new file mode 100644
index 0000000000..7dd959ad2c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_organizations.md
@@ -0,0 +1,30 @@
+::: panel best practice
+What you need to do when provisioning an organization will depend on how organizations are represented in your system. This can take some time to step back and consider how users of those organizations will be interacting with your applications. See [Multiple Organization Architecture](/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf) to determine how to configure organizations for your IAM system.
+:::
+
+When provisioning organizations you need to consider the following:
+
+* You will need to add the organization to your own application configuration and/or database
+* You will need to make changes to your Auth0 configuration.  This will include doing some or all of the following:
+    * Create a unique tenant
+    * Add a database connection (if you have isolated users per organization)
+    * Add an enterprise connection for this organization
+        * This will include working with the organization to either update their existing configuration or add configuration for your Auth0 tenant if they are not a legacy organization.
+    * Provision an administrator for the organization
+* To avoid mistakes, you may want to create an [Organization Admin Portal](#organization-admin-portal) to make it easier to provision new organizations.
+
+### Organization Admin Portal
+An organization admin portal is a portal that allows your administrators to create, modify, and remove organizations. There are multiple activities that need to be done both in your own system and your Auth0 tenant.  This portal will likely need to exist in your own system so it has access to your datastores and configuration.  However, Auth0 provides the [**Auth0 Management API**](/api/management/v2) so that you can incorporate changes to your Auth0 tenant at the same time that you create the changes in your own system.
+
+There are two main approaches that can be taken for creating a new organization.  The one you choose depends highly on your tolerance for how long it would take to deploy a new organization.
+* **Live Updates to your Auth0 Tenant**: If you want to be able to create new organizations in real-time, then you will likely want to make the changes directly to your Auth0 tenant using the Auth0 Management API.  This allows the changes to take place in real-time and allow the addition of a new organization to take effect immediately.
+
+::: warning
+  Live Updates do come with some things to consider.  There are certain operations that must be done in serial to avoid issues.  Enabling clients on a connection, adding callback URL's to an Application are two examples.  Any operation in the Management API where you must retrieve an entire list and re-submit the entire list with the new value added to it are operations that must be done in serial to avoid two parallel operations overwriting one of the values.
+:::
+
+* **Change the Repository and Re-deploy**: If you are taking advantage of the Deploy CLI (or a custom CLI) as part of your [CI/CD pipeline]( /architecture-scenarios/implementation/${platform}/${platform}-deployment), you may prefer to push your changes directly to your repository and then kickoff a new deployment instead.  This can take a little more time, but it has benefits associated with version history and the ability to backout a change by re-deploying the previous version.
+
+::: panel Best Practice
+You may want to have a separate repository just for the items that the organizations need so that you don't have to re-deploy other common components and risk making an error.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md
new file mode 100644
index 0000000000..6799c34345
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_self-signup.md
@@ -0,0 +1,5 @@
+Self sign up leverages Auth0 [Database Connections](/connections/database) to store the user ID, password, and (optional) username identity information collected from new users during the sign up process. Database connection policies governing things such as minimum [username length](connections/database/require-username#username-length) or [password strength and complexity](/connections/database/password-options) can be configured via the Auth0 Dashboard. 
+
+::: panel Best Practice
+Auth0 [Universal Login](/universal-login) as well Auth0 widgets such as [Lock](https://auth0.com/lock) integrate with Database Connections to provide comprehensive user interface functionality for sign up out-of-the-box. These UI artifacts are fully reactive, and with feature rich configuration and comprehensive customization, you can deploy functionality for user self sign up as well as login.
+:::
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md
new file mode 100644
index 0000000000..c581a3e097
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_social-signup.md
@@ -0,0 +1 @@
+Social signup is synonymous with sign in via [social authentication](/architecture-scenarios/implementation/${platform}/${platform}-authentication#social-authentication) - there’s no distinction here *per se*, as user [profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt) creation happens automatically upon first social login.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md
new file mode 100644
index 0000000000..fea6aca40e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_provisioning/_user-migration.md
@@ -0,0 +1,17 @@
+In addition to hosting the [User Profile](/architecture-scenarios/implementation/${platform}/${platform}-profile-mgmt), Auth0 also has the capability to both [proxy](#identity-store-proxy) your own legacy identity store and provide a secure Auth0 hosted replacement. Both of these capabilities are supported via the use of Auth0 [Database Connections](/identityproviders#database-and-custom-connections). If you decide to use Auth0 as a replacement for your legacy identity store then you can migrate users either all at once with [Bulk Migration](users/concepts/overview-user-migration#bulk-user-imports-with-the-management-api), or progressively with [Automatic Migration](users/concepts/overview-user-migration#automatic-migrations).  
+
+::: panel Best Practice
+Customers often opt for a two-stage approach to user migration, using Automatic Migration first to migrate as many users as possible, then using Bulk Migration for the users that remain. See [User Migration Scenarios](users/references/user-migration-scenarios) for more information. 
+:::
+
+Automatic Migration is preferred as it allows users to be migrated individually and also allows them to retain their existing password in almost all situations. For Bulk Migration, we recommend using the [Management API](api/management/v2#!/Jobs/post_users_imports) over the [User Import/Export extension](/users/concepts/overview-user-migration#migrate-users-with-the-user-import-export-extension) in all but the most simple cases, as the Management API provides for greater flexibility and control.
+
+With Bulk Migration users typically need to **reset their password once migration is complete**, _unless_ passwords are stored hashed in your legacy identity store using bcrypt (or you can generate them in bcrypt form). In this case, you _may_ be able to use bulk migration and **preserve user passwords** as part of the process, depending on the bcrypt algorithm and the number of salt rounds used. See [Bulk Import Database Schema Examples](/users/references/bulk-import-database-schema-examples) for more information. 
+
+::: panel Best Practice
+<%= include('../../_includes/_rate-limit-policy.md') %>
+:::
+
+### Identity store proxy
+
+Auth0 Database Connection types can also be configured to proxy an existing (legacy) identity store. If you need to keep user identities defined in your own legacy store - for example, if you have one or more business critical applications that you can’t migrate to Auth0, but which still need access to these identities - then you can easily integrate with Auth0. See [Authenticate Users Using Your Database](/connections/database/custom-db) for more information.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_qa/_integration-testing.md b/ja-jp/articles/architecture-scenarios/_includes/_qa/_integration-testing.md
new file mode 100644
index 0000000000..629c1f9d99
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_qa/_integration-testing.md
@@ -0,0 +1,13 @@
+It is a recommended best practice that you set up different tenants for development, testing, and production as discussed in Architecture guidance for [SDLC support](architecture-scenarios/implementation/${platform}/${platform}-architecture#sdlc-support). Auth0 allows you to configure variables that are available from within custom [extensibility](/topics/extensibility); these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:
+
+* For use of variables in Rules, see how to [configure values](/rules/guides/configuration#configure-values)
+* For use of variables in Hooks, see how to configure [secrets](/hooks/secrets) in the editor
+* For use of variables in Custom DB Scripts, see the [configuration parameters](/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters) 
+
+::: panel Best Practice
+It’s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub, then using a tenant-specific variable avoids exposure of sensitive values via your GitHub repository.
+:::
+
+### Test automation
+
+You can automate your overall build process by incorporating deployment automation as well as test automation. This can be used to deploy new versions of configuration and/or custom code to Auth0 and execute automated tests. If the tests uncover any failures, the deployment automation capabilities can be used to revert to the last working version. For further information, see the [deployment automation guidance](/architecture-scenarios/implementation/${platform}/${platform}-deployment) provided.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_qa/_introduction.md b/ja-jp/articles/architecture-scenarios/_includes/_qa/_introduction.md
new file mode 100644
index 0000000000..9f423218bc
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_qa/_introduction.md
@@ -0,0 +1,11 @@
+Quality Assurance is important in identifying issues before they impact your customers and, depending on the nature of your project, there are several different types of quality assurance testing that you’re going to want to consider as part of your integration with Auth0:
+
+* Is your application easy to understand and use, even by those with a disability?
+* Does your application need to work across various different browsers and devices?
+* Does your application need to work in multinational and/or international environments?
+* How will your application perform when subjected to unexpected production loads?
+* How can you ensure your application is safe from security-related vulnerabilities?
+
+Auth0 [Universal Login](/universal-login) and associated UI widgets (such as [Lock](/libraries/lock)) have already been designed and built following usability and accessibility best practices, and provide tested out-of-box support for a whole host of [browsers and devices](/support/matrix#browsers). Support for [internationalization](/i18n) (I18N) is also provided out-of-box, with built-in extensibility designed for custom multi-language and localization (L10N) situations.
+
+To ensure functional requirements are met and unexpected events are handled correctly, guidance is provided for testing the [integration](#integration-testing) between your application(s) and Auth0, and for [unit testing](#unit-testing) individual extensibility modules (such as [Rules](/rules/guides/debug#try-this-rule), [Hooks](/hooks/update), and Custom Database scripts). Guidance is also provided regarding Auth0's [penetration testing policy](/policies/penetration-testing) to help when testing for security vulnerability, and also how [Mock](#mock-testing) testing can be leveraged in conjunction with our [load testing policy](/policies/load-testing) to help ensure your application(s) perform under unexpected load.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_qa/_load-testing.md b/ja-jp/articles/architecture-scenarios/_includes/_qa/_load-testing.md
new file mode 100644
index 0000000000..1761e56882
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_qa/_load-testing.md
@@ -0,0 +1,15 @@
+Load tests require prior approval from Auth0, as explained in the Auth0 [load test policy](/policies/load-testing). Be sure to note the lead time for a request to be reviewed and allow enough time for review as well as conducting the tests. If your load test request has been approved, the following guidance can help avoid errors and faulty test results.
+
+* Run an HTTP trace on a test execution of your application to identify all the calls your application or intended test needs to make, and make sure your test includes them so it is representative of what will happen in production.
+* Design your test to be mindful of Auth0 API rate limits.
+* Use of any custom code in Auth0 (Rules, Custom DB scripts, Hooks, Custom OAuth connections) will invoke the Auth0 custom code sandbox and this may cost more in terms of performance.  Turn off Rules unless they are essential to the test.  If they are off you will have higher throughput than if they are on.
+* Estimate the expected overall load for your production environment and percent of calls to each endpoint and structure your performance test accordingly so it gives you a realistic test result.  Different endpoints have different performance costs.  Failure to design a representative test will result in misleading results.
+* Don’t make calls that depend on the results of earlier calls without checking that pre-requisite calls or responses have completed.  Simply building in a delay may not be adequate.  
+* Be sure to implement adequate error handling.  A frequent cause of issues during tests is errors in custom code (rules, hooks, Custom db scripts, Custom OAuth connection scripts) caused by unhandled exceptions in the custom code.
+* Load tests should be written to start at a low level and increase the load gradually, capturing data at each level, to get the most useful results.  Starting at a high level and immediately failing gives less information about what the system can sustain.
+* It is normal to need to run a performance test multiple times, possibly adjusting the code under test or the test harness/configuration.  Be sure to start your testing early to allow enough time for more than one iteration.
+* Use your own mail provider account and make sure to arrange ahead of time for enough mail-sending quota or you may be rate-limited by the mail provider.  Turn off mail sending if you do not use it.
+* Be sure to use your own account credentials for all social connections rather than Auth0 dev keys.  In the Auth0 dashboard, go to Connections -> Social -> {name of connection} - to see instructions for how to add your own social provider account credentials into the connection.
+Note: some social providers do not allow load testing. Check your provider(s) for their policy
+* In order to avoid rate limiting, and more accurately simulate real load, your tests will need to send requests for different users, not all requests for the same user. If you use only one or a few users, caching may reduce the effective load and not provide realistic results.
+* Be sure to stay within the agreed-upon parameters for the test and the Auth0 [load test policy](/policies/load-testing).  Auth0 reserves the right to terminate any performance/load testing which does not stay within the bounds of agreed-upon parameters or which extends beyond the scheduled test window.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_qa/_mock-testing.md b/ja-jp/articles/architecture-scenarios/_includes/_qa/_mock-testing.md
new file mode 100644
index 0000000000..786ee3b346
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_qa/_mock-testing.md
@@ -0,0 +1 @@
+In a balance between Auth0’s [load testing policy](/policies/load-testing) and the desire to load test, it is common practice among Auth0’s customers to mock out Auth0’s endpoints. This is a valuable practice in order to ensure that your application works with your expected interfaces without having to restrict your testing, and tools such as [MockServer](http://www.mock-server.com/), [JSON Server](https://github.com/typicode/json-server) or even [Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/) can be used to assist. 
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_qa/_unit-testing.md b/ja-jp/articles/architecture-scenarios/_includes/_qa/_unit-testing.md
new file mode 100644
index 0000000000..a8ebd23233
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_qa/_unit-testing.md
@@ -0,0 +1 @@
+The objective of unit testing is to test individual units of code. If you create custom code within Auth0 in the form of Rules, Hooks, and/or Custom DB scripts, you should consider use a testing framework (such as [Mocha](https://mochajs.org/)) to test your code. Companies who have been most successful with Auth0 have found it useful to execute these unit tests prior to [automatically deploying](/architecture-scenarios/implementation/${platform}/${platform}-deployment) Auth0 tenant configuration and collateral.
diff --git a/ja-jp/articles/architecture-scenarios/_includes/_rate-limit-policy.md b/ja-jp/articles/architecture-scenarios/_includes/_rate-limit-policy.md
new file mode 100644
index 0000000000..ce743cf61d
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/_includes/_rate-limit-policy.md
@@ -0,0 +1 @@
+Calls to the Management API are subject to [Auth0 Rate Limiting policy](/policies/rate-limits). You must take this into consideration, and to assist, Auth0 generally recommends use of the appropriate [Auth0 SDK](/libraries) for your development environment rather than calling our APIs directly. 
diff --git a/ja-jp/articles/architecture-scenarios/b2b-b2e.md b/ja-jp/articles/architecture-scenarios/b2b-b2e.md
new file mode 100644
index 0000000000..590a1cea72
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/b2b-b2e.md
@@ -0,0 +1,44 @@
+---
+order: 07
+title: Business to Business + Employees Identity Scenarios
+image: /media/articles/architecture-scenarios/b2b-b2e.png
+extract: This is essentially a hybrid between B2B and B2E where you have a larger SAAS application, like Zendesk for example, where users are grouped into companies.
+description: Explains the architecture scenario of a hybrid between B2B and B2E where you have a larger SAAS application.
+beta: true
+topics:
+    - b2b
+    - b2e
+    - architecture
+    - lockjs
+    - saml
+    - active-directory
+    - social-connections
+contentType: concept
+useCase:
+  - invoke-api
+  - secure-an-api
+  - build-an-app
+---
+
+# Business to Business + Employees Identity Scenarios
+
+::: note
+This architecture scenario is under construction and will be updated soon.
+:::
+
+![](/media/articles/architecture-scenarios/b2b-b2e.png)
+
+This is essentially a hybrid between B2B and B2E for larger SAAS applications (such as Zendesk). In a situation like this, users would primarily be grouped into companies, but you may also have internal users (employees) who log into perform support or administrative tasks. Those internal users will typically use federated identity to authenticate.
+
+## Read More
+
+The following is a list of articles on this website which will help you to implement this scenario:
+
+* [Lock](https://auth0.com/lock)
+* [Protocols supported by Auth0](/protocols)
+* [Connect Active Directory with Auth0](/connections/enterprise/active-directory-ldap)
+* [SAML](/saml-configuration)
+* [Using Auth0 in SaaS, multi-tenant Apps](/saas-apps)
+* [Identity Providers supported by Auth0](/identityproviders)
+* [Social Login](https://auth0.com/learn/social-login/)
+* [Auth0 SSO Dashboard (sample)](https://github.com/auth0-samples/auth0-sso-dashboard)
diff --git a/ja-jp/articles/architecture-scenarios/b2b.md b/ja-jp/articles/architecture-scenarios/b2b.md
new file mode 100644
index 0000000000..ec33e404f6
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/b2b.md
@@ -0,0 +1,52 @@
+---
+url: /architecture-scenarios/b2b
+classes: topic-page
+title: Business to Business Identity and Access Management
+description: Explains the architecture scenario B2B IAM with a SAAS application.
+topics:
+    - b2b
+    - b2biam
+    - SDLC
+contentType: index
+useCase:
+  - implementation
+---
+
+
    
+  
    
+  
    Business to Business Identity and Access Management
    
+  
    
+  This guidance is relevant to all project stakeholders. We recommend reading it in its entirety at least once, even if you've already started your journey with Auth0. We provide a Project Planning Guide in PDF format, details about how to get started with each phase of the implementation process, and checklists to help you manage the tasks in each phase.
+  
    
+
    
+
+<%= include('./_includes/_base-ways-to-integrate.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('./_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('./_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Get started
+
+<%= include('./_includes/_base-intro.md', { platform: 'b2b' }) %>
+
+<%= include('../_includes/_topic-links', { links: [
+  'architecture-scenarios/implementation/b2b/b2b-architecture',
+  'architecture-scenarios/implementation/b2b/b2b-provisioning',
+  'architecture-scenarios/implementation/b2b/b2b-authentication',
+  'architecture-scenarios/implementation/b2b/b2b-branding',
+  'architecture-scenarios/implementation/b2b/b2b-deployment',
+  'architecture-scenarios/implementation/b2b/b2b-qa',
+  'architecture-scenarios/implementation/b2b/b2b-profile-mgmt',
+  'architecture-scenarios/implementation/b2b/b2b-authorization',
+  'architecture-scenarios/implementation/b2b/b2b-logout',
+  'architecture-scenarios/implementation/b2b/b2b-operations'
+] }) %>
+
+## Implementation planning checklists
+
+<%= include('./_includes/_implementation-checklists.md') %>
diff --git a/ja-jp/articles/architecture-scenarios/b2c.md b/ja-jp/articles/architecture-scenarios/b2c.md
new file mode 100644
index 0000000000..f9e43afa16
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/b2c.md
@@ -0,0 +1,49 @@
+---
+url: /architecture-scenarios/b2c
+classes: topic-page
+title: Business to Consumer Identity and Access Management
+description: Explains the architecture scenario B2C IAM with an eCommerce or SAAS application.
+topics:
+    - b2c
+    - CIAM
+    - SDLC
+contentType: concept
+useCase:
+  - implementation
+---
+
+
    
+  
    
+  
    Business to Consumer Identity and Access Management
    
+  
    
+  This guidance is relevant to all project stakeholders. We recommend reading it in its entirety at least once, even if you've already started your journey with Auth0. We provide a Project Planning Guide in PDF format, details about how to get started with each phase of the implementation process, and checklists to help you manage the tasks in each phase.
+  
    
+
    
+
+<%= include('./_includes/_base-ways-to-integrate.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('./_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Get started
+
+<%= include('./_includes/_base-intro.md', { platform: 'b2c' }) %>
+
+<%= include('../_includes/_topic-links', { links: [
+  'architecture-scenarios/implementation/b2c/b2c-architecture',
+  'architecture-scenarios/implementation/b2c/b2c-provisioning',
+  'architecture-scenarios/implementation/b2c/b2c-authentication',
+  'architecture-scenarios/implementation/b2c/b2c-branding',
+  'architecture-scenarios/implementation/b2c/b2c-deployment',
+  'architecture-scenarios/implementation/b2c/b2c-qa',
+  'architecture-scenarios/implementation/b2c/b2c-profile-mgmt',
+  'architecture-scenarios/implementation/b2c/b2c-authorization',
+  'architecture-scenarios/implementation/b2c/b2c-logout',
+  'architecture-scenarios/implementation/b2c/b2c-operations',
+  'architecture-scenarios/implementation/b2c/b2c-launch'
+] }) %>
+
+## Implementation planning checklists
+
+<%= include('./_includes/_implementation-checklists.md') %>
diff --git a/ja-jp/articles/architecture-scenarios/b2e.md b/ja-jp/articles/architecture-scenarios/b2e.md
new file mode 100644
index 0000000000..a35f10a932
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/b2e.md
@@ -0,0 +1,114 @@
+---
+order: 06
+title: Business to Employees Identity Scenarios
+image: /media/articles/architecture-scenarios/b2e.png
+extract: Large organization who wants to federate their existing enterprise directory service to allow employees to log in to applications using their existing enterprise credentials.
+description: Explains the architecture scenario of B2E with a large organization that wants to extend their existing enterprise directory service.
+topics:
+    - b2e
+    - architecture
+    - lockjs
+    - active-directory
+    - saml
+    - sso
+contentType: concept
+useCase:
+  - invoke-api
+  - secure-an-api
+  - build-an-app
+---
+
+# Business to Employees Identity Scenarios
+
+The B2E (Business to Employees) scenario involves applications that are used by employee users.  These are applications that are targeted toward users who are typically acting on behalf of an organization such as an employer, a university, or a group in which they are a member, as opposed to acting on their own behalf.  
+
+Such applications that are custom written by the organization may use the OIDC/OAuth protocol to externalize authentication whereas those that have been purchased will often use the SAML protocol. In either case, the enterprise will typically want to use some form of Enterprise connection, such as a SAML Identity Provider, ADFS, G Suite, Azure AD or a directory service such as AD or OpenLDAP, and less frequently, a custom DB, for authentication of enterprise users.
+
+For a business that is creating or integrating applications with Auth0 for a B2E environment,  there are several requirements that are common for this scenario.  This guide will summarize the most common requirements for B2E applications and explain the Auth0 features which help meet each need.  
+ 
+## Enterprise providers
+
+Most businesses already have a corporate identity repository which has information on all the employee users and user profile information.  It may also contain information on partners and contractors. A common requirement for the B2E scenario therefore, is to allow such users to log in via [Auth0 Enterprise connections](/connections/identity-providers-enterprise) such as SAML2 providers, ADFS, G Suite, Azure AD or an on-premise corporate directory service.  This is attractive to users because it allows them to avoid creating yet another username and password for each application and instead leverage the same login credential across all their enterprise applications.  
+
+This is especially attractive to security interests within the company because user credentials are only exposed to the identity stack instead of to each application.  Furthermore, this architecture allows the business to retain control over access to applications because the enterprise identity provider provides a single shutoff point.  If a user leaves the organization, administrators can simply disable the user’s account in the corporate identity provider and the user can no longer log in to any of the applications using that identity provider.  
+
+Auth0 makes it easy to enable login via a wide variety of enterprise providers with just a few simple configuration steps.
+
+## Groups and roles
+
+With a lot of users, you may set up groups and roles to manage access and privileges. Often, these are stored and administered in a directory service.
+
+Auth0 can get user attributes, like groups and roles, from a directory service or enterprise identity provider during authentication. You can then make the attributes available through tokens returned to the application or with the Auth0 Management API.
+
+## Profile translation
+
+Sometimes a directory or identity provider returns attributes in one format, but your application uses another format. Using Auth0's [Rules](/rules/current/metadata-in-rules), you can [map and translate user profile attributes](https://auth0.com/rules/saml-attribute-mapping). You can even translate between OIDC/OAuth, SAML, WS-Fed, and LDAP.
+
+For example, you retrieve attributes in SAML assertion format from a SAML Identity Provider. With a rule you can then translate the attributes to custom claims in an ID Token for an OIDC/OAuth application.
+
+You can also map SAML attributes to the Auth0 user profile from the dashboard. To do this, go to [Connections > Enterprise > SAMLP Identity Provider](${manage_url}/#/connections/enterprise), select your SAML connection, and set your attribute mappings in the **Mappings** tab.
+
+## Extensibility with augmented user profiles
+
+You may want to enrich user profiles with attributes or data retrieved from other services. For example, you might receive an address or phone number and wish to translate that into a geographic region. [Auth0 Rules](/rules) enable you to write small snippets of code that execute during the authentication transaction. This lets you execute logic or call other services for user information, then add [user metadata](/users/concepts/overview-user-metadata) to the Auth0 user profile and optionally the resulting tokens sent to your applications.
+
+## Single Sign-on
+
+If you have several internal applications, you can set up [Single Sign-on (SSO)](/sso) across them so users only have to log in once.
+
+Auth0 supports integration with applications that externalize authentication using industry standard identity protocols:
+
+* OIDC/OAuth
+* SAML2
+* WS-Fed
+
+After some configuration, all your applications can leverage your enterprise identity provider. In this setup, Auth0 is the broker between your applications and enterprise identity providers.
+
+Now when a user signs in to one application, they can access other applications integrated with Auth0 without having to log in again. This will be true until their SSO session expires. You should configure the SSO session length within Auth0 to meet security policies.
+
+## Single Sign-on integrations
+
+You can also integrate purchased applications with Auth0 for Single Sign-on (SSO). Auth0 provides [pre-built integrations](/integrations/sso) for applications such as:
+
+* Salesforce
+* Zendesk
+* Slack
+* New Relic
+
+## Branding
+
+Branding is an important part of any application. Your logo, colors and styles should be consistent in all parts of the application. You can [customize](/libraries/custom-signup) the login, signup, and error pages displayed by Auth0 so it matches your application. Add your own logo, text, and colors. There's also I18N/L10N support for global rollouts. [Emails for verification or password resets](/email/templates) are customizable too. 
+
+[Login screens](/libraries/lock/v11/ui-customization) should appear to come from your application’s branded domain name. To maintain consistency, you can define a [custom domain name](/custom-domains) for the login screen displayed by Auth0.
+
+## Multi-factor authentication
+
+Internal or employee applications often deal with sensitive content. [Multi-factor authentication (MFA)](/mfa) helps protect your data and applications. Auth0 provides a variety of ways to implement MFA. And for more flexibility, you can use Rules to turn it on only for the applications or user groups that need it.
+
+## Logs export
+
+Need to analyze logs or store them long-term? Auth0 provides extensions to [export logs to external tools](/logs) for analysis and retention. You can also retrieve log data with the Management API.
+
+## Audit
+
+Companies have many uses for logs data, one of which is audit reports. Auth0 captures a variety of data in log files, which may be useful for your audit reporting. The logs have information on authenticated users, the identity provider used, and when significant administrative changes are made in the Auth0 dashboard.
+
+Log events each have an event type. You can use event types as filters when querying log data with the Management API, or when exporting logs to log analysis tools.
+
+## Monitoring
+
+Monitoring the infrastructure and services that your applications depend on is critical. Auth0 provides an [Auth0 Status](https://status.auth0.com) page you can subscribe to.
+
+Auth0 makes every effort to minimize outages, but if there is any disruption to service, it will appear on the status page. To support requirements for root cause analysis documentation after a disruption, Auth0 conducts internal analysis and publishes the results on the disruption notice when the analysis is completed.
+
+## Anomaly Detection
+
+An unfortunate part of modern life on the internet is hackers. Hackers are constantly trying to find a way into applications. For example, they may try to log in using common passwords. Or they may use credentials stolen from elsewhere, hoping that users re-used the same passwords at other sites.
+
+Auth0's [Attack Protection](/attack-protection) detects these situations for Auth0 Database connections and provides options for how to respond. Turn on Attack Protection and configure the response options so you can respond appropriately if such an event occurs.
+
+## Github Deployment
+
+Do you manage a lot of your application code in Github? You can deploy code for rules, hooks, or custom database access from there with Auth0's [Github Deployment extension](/extensions/github-deploy).
+
+If you have a full continuous integration/continuous deployment pipeline, use the [Auth0 Deploy CLI tool](https://github.com/auth0/auth0-deploy-cli) for greater flexibility.
diff --git a/ja-jp/articles/architecture-scenarios/checklists.md b/ja-jp/articles/architecture-scenarios/checklists.md
new file mode 100644
index 0000000000..16712907ca
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/checklists.md
@@ -0,0 +1,72 @@
+---
+title: Implementation Planning Checklists
+description: Links to checklists for your implementation. 
+topics:
+    - SDLC
+    - checklists
+    - best practices
+    - implementation checklist
+contentType: reference
+useCase:
+    - implementation
+---
+# Implementation Planning Checklists
+
+Click the links below to download a checklist that corresponds to a phase in the SDLC (Software Development Lifecycle). You can open the checklist in any spreadsheet application and customize them to suit your needs. 
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Analyze Checklist
+
+Analyze Checklist Download
+
+In the Analyze phase, analyze end-user business requirements and determine project goals as part of the high-level plan for the project. Convert the requirements and goals into system functions that the organization intends to develop. Activities include:
+
+* Gathering business requirements
+* Creating process diagrams
+* Performing detailed analysis
+* Alignment to project plan
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Design Checklist
+
+Design Checklist Download
+
+In the Design phase, describe the desired features and operations of the system, including business rules, pseudo-code, screen layouts, and other necessary documentation. Activities include:
+
+* Infrastructure design
+* System model design
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Build Checklist
+
+Build Checklist Download
+
+In the Build phase, develop the actual system through implementation of infrastructure and code. Activities include:
+
+* Infrastructure implementation
+* Code implementation
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Test Checklist
+
+Test Checklist Download
+
+In the Test phase, integrate and deploy all implemented code in the testing environment infrastructure. Testing then follows Software Testing Life Cycle activities to check the system for errors, bugs, and defects to verify that system features work as expected (or not). Activities include:
+
+* Write test cases
+* Execute test cases
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Deploy Checklist
+
+Deploy Checklist Download
+
+In the Deploy phase, deploy the system to either a staging or production environment, where actual users begin to operate and interact with it. 
+
+Eventually, you deploy all components of the system to the production environment when you make a live release.
+
+## ![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) Monitor Checklist
+
+Monitor Checklist Download
+
+In the Monitor phase, make enhancements, corrections, and changes to ensure the system continues to work and stays updated to meet the business objectives and support the needs of the users. Activities include: 
+
+* Monitoring
+* Maintenance
+* Changes and adjustments
+* Upgrade and adapt to future needs 
diff --git a/ja-jp/articles/architecture-scenarios/implementation-resources.md b/ja-jp/articles/architecture-scenarios/implementation-resources.md
new file mode 100644
index 0000000000..b4c4f6a955
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation-resources.md
@@ -0,0 +1,115 @@
+---
+title: Implementation Resources
+description: Learn about all the resources Auth0 provides to help you with your Auth0 implementation.
+toc: true
+topics:
+    - architecture
+    - api-auth
+    - sample-code
+    - sdks
+    - documentation
+    - guides
+    - quickstarts
+contentType: concept
+useCase:
+  - get-started
+  - implementation
+  - learning
+  - testing
+  - run-sample-code
+  - get-help
+  - enter-support-ticket
+---
+# Implementation Resources
+
+Auth0 provides a wealth of resources to help you effectively engage with our product and community. This list provides links to the resources available, by category.  
+
+## Get started
+
+Resources designed to help you learn the basics of Auth0 include:
+
+* [**Getting Started documentation**](/getting-started): Explore the Auth0 Dashboard and common terms used for components of the Auth0 service. Gain a broad understanding of Auth0 and learn the terminology you might hear when working with Auth0 staff or reading our docs.
+
+* [**Get Started with Auth0 Video Series**](/videos/get-started): In these short videos, we cover how easy it is to complete the basic steps to use Auth0 with your applications. Watch the series before you start your project so you can get the benefit of our knowledge and experience with other customers. We cover tenant configuration, provisioning user stores and importing users, authentication, authorization, and branding and customization of everything shown to your users. 
+
+* [**Architecture scenarios**](/architecture-scenarios): Review common architecture scenarios and learn how to implement them with Auth0. Scenarios include tutorials for common architecture patterns, such as a Single-Page Application (SPA) calling an API. High-level descriptions are useful for architects, while tutorials will help development teams.
+
+* [**Implementation guides**](/topics/guides): Learn how to implement commonly-used features, such as user management and multi-factor authentication (MFA). This information is useful for both architects and developers.
+
+## Learn
+
+Auth0 provides numerous tutorials, guides, white papers, and blog posts that focus on both learning and providing quick reference checks. 
+
+* [**Docs site**](https://auth0.com/docs/): Browse through our docs to explore a wealth of available topics, or use our search to quickly find content related to a topic or term.
+
+* [**Feature descriptions and white papers**](https://auth0.com/learn/): Investigate short descriptions of features, industry case studies, and reference white papers. The Auth0 Learn site provides a quick overview of Auth0 features and their business value; it is helpful for project owners as well as architects and developers.
+
+* [**Blog posts**](https://auth0.com/blog/): Read blog posts written by experts on a variety of topics--from time-honored advice to breaking news in the identity space. Many blog posts are oriented toward architects and developers. 
+
+## Run sample code
+
+Once your development team is ready to build, Auth0 provides sample programs, SDKs, and libraries to speed your project along.
+
+* [**Quickstarts**](/quickstarts): Investigate a rich array of small sample programs that demonstrate how to implement the key features you’ll want to include in your program, such as authentication, session management, profile updates, and logout. Quickstarts will give developers a head start on understanding how to integrate applications with Auth0.
+
+* [**Libraries and SDKs**](/libraries): Simplify your custom application development by using our extensive set of libraries and SDKs, which abstract many of the details of identity protocols for you. Auth0 SDKs support numerous languages and frameworks to simplify your integration with Auth0. We also provide a library for Lock, a login widget, that you can use across several platforms, including iOS and Android.
+
+* [**Management API**](/api/management/v2): Explore and manipulate objects, configurations, and settings within Auth0. The Management API Explorer allows you to quickly manipulate individual objects and settings on an *ad-hoc* basis and test API calls before coding them into your applications.
+
+* [**Authentication API**](/api/authentication): Authenticate and authorize users via the OIDC, OAuth, and SAML protocols. The Authentication API Explorer allows you to experiment with authentication and authorization flows, and test API calls before coding them into your applications.
+
+## Try out features and API calls
+
+While building, Auth0 allows you to experiment with and test out various product features.
+
+* **TRY buttons/links**: Quickly try out Auth0 product features. **TRY** buttons are located throughout Auth0 and allow you to experiment with connections, rules, hooks, and email templates.
+
+* [**Authentication API Explorer**](/api/authentication#introduction): Experiment with authentication and authorization flows, and test API calls before coding them into your applications. 
+
+* [**Management API Explorer**](/api/management/v2): Quickly manipulate individual objects and settings on an *ad-hoc* basis and test API calls before coding them into your applications.
+
+* [**Postman Collections**](/api/postman): Easily dissect our APIs' calls using Postman by importing our Postman Collections.
+
+## Get help
+
+Auth0 resources that help you troubleshoot your implementation include:
+
+* [**Auth0 Community forum**](https://community.auth0.com/): Connect with the world of Auth0 via Auth0 posts, FAQs, and community Q&As. Architects and developers find this a valuable source of information for learning and connecting with others as well as getting help on issues.
+
+* [**Support Center**](https://support.auth0.com/): View and manage your subscription and tenants, file and view support requests, run automated production checks on a tenant, and view compliance information. Paid subscribers will find the support center a valuable resource if an issue or question cannot be solved by documentation or by searching the forum.
+
+  * [**Create support cases**](/support/tickets): Create and file a support case if you need help.
+  
+  * [**Support Plans and Service Level Agreements**](/support#defect-responses): Learn about multiple levels of support available for purchase.
+
+  * [**Troubleshooting tips**](/onboarding/enterprise-support#what-to-check-before-logging-an-issue) and [**Information to include in your support case**](/onboarding/enterprise-support#information-to-provide-when-logging-an-issue): Get advice to help your development and support teams analyze issues.
+
+* [**Supported versions**](/support/matrix): Understand which versions of SDKs, browsers, and languages are supported. Architects and developers should review this to ensure your project employs languages, libraries, and SDKs that will allow your implementation to work with Auth0.
+
+* [**Feedback Portal**](https://auth0.com/feedback): Make product suggestions. (You can also do this via the Support Center if you want better visibility into what you’ve filed over time.) Architects and developers can use this site to provide feedback on the Auth0 product for consideration as enhancements in the future.
+
+* [**Professional Services**](/services): Engage our world-wide professional services team to help speed your project to success. Project owners will find this useful for learning how Auth0 identity experts can help accelerate your project or fill in any temporary skill gaps.
+
+## Setup and monitor operations
+
+When you're ready to plan your launch, Auth0 provides the following resources:
+
+* [**Pre-launch advice**](/pre-deployment) and [**Production check**](/pre-deployment/how-to-run-test): Get tips and tools to help you plan your launch. Project managers and development and operations teams should explore these tips to leverage advice for a smooth launch.
+
+* [**Operational policies**](/policies): Familiarize yourself with Auth0's policies, so you know lead times for operational requests. Policies are useful for an entire team, but project owners and operations teams in particular should be aware of Auth0's operational policies.
+
+* [**Status Dashboard**](https://status.auth0.com): Quickly determine the availability of Auth0 services and subscribe to status updates. Although service interruptions are rare, when one occurs Auth0 conducts a root cause analysis and publishes the results on this site. Operations and support teams should be familiar with how to check Auth0 status.
+
+* [**Monitor endpoints**](/monitoring): Learn how to integrate our monitoring endpoints into your monitoring infrastructure. This information is of particular use to operations teams and project owners.
+
+* [**Log data**](/logs): Learn about the types of logs Auth0 provides, log data retention, and tools you can use to export log data to external analytical tools for analysis and long-term data storage. This information is useful for developers and operations teams, as well as compliance teams interested in data retention.
+
+* [**Dashboard notices**](/architecture-scenarios/implementation/b2c/b2c-operations#notifications): Stay informed about important announcements from Auth0. From time to time, Auth0 notifies you of important information via your Auth0 Dashboard and (depending on the severity of the information) via email to your registered Auth0 Dashboard Admins. You should regularly log in to the Dashboard and check the bell icon at the top for any important notices.
+
+## Satisfy privacy, security, and compliance needs
+
+View info on Auth0’s privacy policy, security policy, compliance certifications, and how Auth0 can help you with your compliance needs. This information is useful for project owners as well as security, privacy teams, and procurement teams.
+
+* [Privacy and Cookie Policy](https://auth0.com/privacy)
+* [Security, Privacy and Compliance](https://auth0.com/security/)
+* [Compliance Frameworks and Certifications](/compliance)
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md
new file mode 100644
index 0000000000..b38753d752
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-architecture.md
@@ -0,0 +1,56 @@
+---
+title: Architecture
+description: How you configure your Auth0 tenant architecture affects your B2B IAM implementation.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - architecture
+contentType: concept
+useCase:
+    - tenant-architecture
+---
+# Architecture
+
+<%= include('../../_includes/_architecture/_introduction.md', { platform: 'b2b' }) %>
+
+## Tenant provision
+
+<%= include('../../_includes/_architecture/_tenant-provision.md', { platform: 'b2b' }) %>
+
+### Tenant provision for complex organizations
+
+In most cases, provisioning separate Auth0 tenants for your customer's organizations is not necessary. However, in certain circumstances this can be something that is valuable for reducing the complexity of your setup. For instance, we recommend provisioning a separate Auth0 tenant for your customers' organization as a best practice if:
+
+* Your customers' organizations have isolated users that aren't shared with other organizations.
+* You have some customer organizations that support more than one IdP. For example, your customer has their own IdP but also has some users that aren't in their IdP and whose credentials you will need to store. Or, your customer wants to provide for one or more social connections in addition to their enterprise IdP.
+
+If both of these situations are the case, then we recommend that you create separate Auth0 tenants for each customer that needs it. This allows you to have a separate custom domain for them and to easily customize their login experience, including [Home Realm Discovery](/architecture-scenarios/implementation/b2b/b2b-authentication#home-real-discovery) on their login page.
+
+::: warning
+Maintaining multiple Auth0 tenants can add complexity to your system and should not be done unless absolutely necessary.
+:::
+
+## Tenant association
+
+<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2b' }) %>
+
+## Custom domains
+
+<%= include('../../_includes/_architecture/_custom-domains.md', { platform: 'b2b' }) %>
+
+## SDLC support
+
+<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'architecture' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md
new file mode 100644
index 0000000000..4414be9c8f
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authentication.md
@@ -0,0 +1,127 @@
+---
+title: Authentication
+description: How authentication works in your B2B IAM implementation.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - authentication
+    - universal-login
+contentType: concept
+useCase:
+    - authentication
+---
+# Authentication
+
+<%= include('../../_includes/_authentication/_introduction.md', { platform: 'b2b' }) %>
+
+## Universal Login
+
+<%= include('../../_includes/_authentication/_universal-login.md', { platform: 'b2b' }) %>
+
+## Home realm discovery
+
+Home realm discovery (HRD) is the process of identifying which identity provider (or which connection in Auth0) the user belongs to *before* authenticating them. There are two ways HRD can occur:
+
+* Provide a way for the decision to be made at the application
+* Have Home Realm Discovery happen on the Universal Login page
+
+Your system may need to do either or both methods so it is important to understand all approaches to HRD so that you can apply the one(s) that make the most sense to your applications.
+
+::: panel Best practice
+If you don’t need to know ahead of time (for example, all of your users are in a shared user pool), then you don’t need to do HRD. You can allow users to authenticate first and then determine which organization they belong to using app metadata.  HRD is really only needed if you have multiple connections within your Auth0 tenant.
+:::
+
+### Application driven HRD
+
+A common and effective way for determining which realm a user belongs to is when an application is branded for each organization.  The organization has its own instance of the application.  This copy or instance can be physically isolated (running on a separate set of servers) or virtually isolated (running on shared servers, but presented as if it could be isolated), and is generally denoted through either a custom hostname (`companyA.application1.yourcompany.com`) or path (`application1.yourcompany.com/companyA`).
+
+::: warning
+This method will only work if you are not sharing users between organizations.  If you are sharing users within organizations, then you must support [Home Realm Discovery on the Universal Login Page](#hrd-through-universal-login)
+:::
+
+::: panel Best practice
+If your application already knows what connection (IdP) the user needs, then pass that along when you redirect the user to `/authorize` using the connection query parameter.
+:::
+
+If this is the case for your application(s) then home realm discovery is a simple matter of storing the Auth0 connection name with the organization specific application configuration and sending that connection name as a parameter when redirecting the user for Universal Login. Sending the connection parameter can be achieved by adding it as a query parameter when you redirect them to the authorize endpoint. For more information see the [Authentication API docs](/api/authentication#authorization-code-flow); however, you will generally accomplish this using the SDK for whichever language your application is written in.
+
+::: panel Best practice
+If an organization needs more than one IdP, then you will have to do a second round of Home Realm Discovery once identifying their organization.  This can be achieved with Auth0 through creating a dedicated Auth0 tenant for that organization and creating an enterprise connection to that tenant.
+:::
+
+### HRD through Universal Login
+
+There are three main approaches to Home Realm Discovery through Universal Login:
+
+* Discover the realm through the user’s email subdomain.
+* Discover the realm by looking up a user identifier in some sort of map of identifier to realm map.
+* Allow the user to choose or enter their realm (or organization).
+
+In both of the first two approaches, you may consider doing “Identifier First Login”. This means that you present only the ability to enter an identifier first.  After which you collect the user’s identifier, and then based on the identifier you either automatically redirect the user or present a way for the user to enter their password if redirection is unnecessary.
+
+::: warning
+Though it is possible to implement Identifier First Login or allow a user to select their organization at the application instead of on the Universal Login Page, this can add complexity with respect to single sign on as well as complexity associated with replicating that behavior in all of your applications.  Instead Auth0 recommends implementing some form of HRD through Universal Login.
+:::
+
+#### HRD through Universal Login using the email subdomain
+
+The simplest way to implement home realm discovery on the universal login page is to utilize the email subdomain of the user’s identifier to map that to their Identity Provider. This, of course, only works in situations where the email subdomain will be a 1:1 mapping to an organization or at least to an Identity Provider.  Auth0’s Lock widget can do this for you if you are using the domain map in an enterprise connection, however if you want to build this yourself, you can, but it requires you to build a mapping of email subdomain to connection.
+
+#### HRD through Universal Login using the Identifier to Realm Map
+
+A second, more complex alternative is to store a map of identifier’s to IdP and provide a public endpoint to access that information.  Then on the Universal Login page you can find the connection and redirect back to /authorize with the connection.  The main drawbacks to this approach are latency, and more importantly security when it comes to identifier discovery: if you’re using email addresses, this makes it much easier for someone to discover whether a particular email address is a user of yours.
+
+::: panel Best practice
+Any public endpoint should have rate limiting applied to it to prevent hackers from using it to discover information and to prevent denial of service attacks.
+:::
+
+#### HRD through Universal Login using user choice
+
+The other simple option is to allow your users to choose from a list, if you don’t mind making public the list of organizations who use your product, or by allowing the user to enter their organization name explicitly.  Once the user tells you which organization they belong to, you can redirect back to Auth0 with the connection for that organization specified, or simply prompt them for their username and password if the connection is a database connection.
+
+## Username and password authentication
+
+<%= include('../../_includes/_authentication/_username-and-password-authentication.md', { platform: 'b2b' }) %>
+
+## Application integration
+
+<%= include('../../_includes/_authentication/_application-integration.md', { platform: 'b2b' }) %>
+
+## Anomaly detection
+
+<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2b' }) %>
+
+## SSO with legacy systems
+
+<%= include('../../_includes/_authentication/_sso-legacy.md', { platform: 'b2b' }) %>
+
+## Enterprise Login
+
+The “bring your own identity” scenario has become a must-have for almost all B2B applications.  Most enterprise companies expect to be able to integrate their IdP into your application so their employees don't need to store another set of credentials.  This is a valuable way of simplifying the user authentication experience without compromising security, and using [Universal Login](#universal-login) makes it easy to start adding support for [Enterprise Connections](/connections/identity-providers-enterprise) with minimal disruption.
+
+::: panel Best Practice
+Once you start supporting enterprise connections for users, you must do some form of [Home Realm Discovery](#home-realm-discovery) so that you can determine which connection to send the user to for authentication.
+:::
+
+With enterprise connection support, user identities and credentials are managed by the identity provider of your customers' organization, as well as certain identity claims - which Auth0 will use to populate the user [profile](/architecture-scenarios/implementation/b2b/b2b-profile-mgmt).
+
+::: panel Best Practice
+"Bring your own identity" is a great feature to provide, but if you don't support this from day one, and sometimes even if you do, you may have an organization that wants to switch to their own IdP after already having used the application for a while.  You will need a way to [link user accounts](/users/concepts/overview-user-account-linking) to provide an effective way of associating the new identity with the old database identity.
+:::
+
+## Multi-factor authentication (MFA)
+
+<%= include('../../_includes/_authentication/_mfa.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'authentication' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md
new file mode 100644
index 0000000000..5d0ca8d405
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-authorization.md
@@ -0,0 +1,61 @@
+---
+title: Authorization
+description: User authorization and related planning considerations for your B2B IAM implementation.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - user-authorization
+contentType: concept
+useCase:
+  - user-authorization
+---
+# Authorization
+
+<%= include('../../_includes/_authorization/_introduction.md', { platform: 'b2b' }) %>
+
+## Application integration
+
+<%= include('../../_includes/_authorization/_application-integration.md', { platform: 'b2b' }) %>
+
+## API integration
+
+<%= include('../../_includes/_authorization/_api-integration.md', { platform: 'b2b' }) %>
+
+## Role Based Access Control (RBAC)
+
+<%= include('../../_includes/_authorization/_rbac.md', { platform: 'b2b' }) %>
+
+The core RBAC feature can be used in many multi-organization scenarios.  See [Organization Data in an Access Tokens](#organization-data-in-an-access-token) for more information on how to ensure your setup can support your RBAC needs.
+
+## Machine-to-Machine (M2M) authorization
+
+<%= include('../../_includes/_authorization/_m2m.md', { platform: 'b2b' }) %>
+
+## Organization Data in an Access Token
+
+If you have a separate API from your application in your system that supports your multi-organization application, it is important to restrict operations to only the organization that the token was generated for.  This requires that there is some sort of information in the access token to tell the API which organization the access token was issued for.  This can be done in a couple of different ways depending on the answers to a couple of simple questions:
+
+1. Will the End Users in this organization potentially have more than one organization, or is each End User isolated to a specific organization?
+2. Will you be allowing any Machine-to-Machine (M2M) access to your API?
+3. If you are allowing Machine-to-Machine (M2M) access to your API, Will you have any developers who need a single client ID and secret to access multiple organizations (but not *all* organizations)?
+4. Will you be allowing the creating of third-party apps that require consent?
+
+If End Users are isolated to a single organization **and** you will either not be allowing M2M access to your API or you will have a separate client ID/secret for each organization that needs access **and** you will *not* be allowing third-party apps that require consent, then the simplest approach is to just create a custom claim in the access token [using rules for the user based tokens](#access-token-claims) and [using the client credentials hook for M2M calls](#machine-to-machine-m2m-authorization).  You can store organization name in client metadata and extract it from rules or hooks to include in access_token as a custom claim.  RBAC will work out of the box for this approach as well as long as each End User can only belong to one organization.
+
+If End Users have more than one organization they can belong to or you might give a single developer a client ID and secret for M2M calls to more than one organization, then you will be best served by creating a separate audience (a separate API instance in your Auth0 tenant) for each organization.  This gives you a few nice abilities:
+1.  First, it allows you to pass the audience as a first-class parameter to Auth0 without having to create a custom parameter.  The benefit of this is that Auth0 will help enforce the existence of the audience, and it will pass it to your rules.  It will also ensure that an issued refresh token will only work for the specific audience it was originally issued to.
+2.  It allows you to restrict client grants to only specific organizations out of the box.  The alternative is to create a more complicated client credentials hook to attempt to retrieve the restrictions from somewhere else and also require a much more complex and potentially troublesome way to tell the client credentials call which organization to issue the access token for.
+3.  This also allows you to use the core RBAC feature with Auth0 and ensure that the End Users who have access to more than one organization can have a potentially different role for each organization.
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'authorization' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-branding.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-branding.md
new file mode 100644
index 0000000000..b2da74226e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-branding.md
@@ -0,0 +1,65 @@
+---
+title: Branding
+description: How to configure Auth0 items to reflect your brand and desired user experience.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - branding
+    - universal-login
+    - login-pages
+    - password-reset-pages
+    - custom-domains
+    - error-pages
+contentType: concept
+useCase:
+    - user-logout
+---
+# Branding
+
+<%= include('../../_includes/_branding/_introduction.md', { platform: 'b2b' }) %>
+
+## Universal login and login pages
+
+<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2b' }) %>
+
+## Branding login by organization
+
+Whether or not you need to do special customization on the Universal Login page is determined by how you plan to manage your customers’ organization.  Before reading through this section, make sure you have read through the [Universal Login section](#universal-login-and-login-pages) and know how you are approaching organizations by reviewing [Multiple Organization Architecture](https://drive.google.com/a/auth0.com/file/d/1y2G8RNHTBujcCrnMRhp6_phQiRAkZzfF/view?usp=sharing).
+
+If your organization users will all be isolated from each other, than it’s important to make it clear on the Universal Login page which organization the login page is for.  This can be done in a couple of ways:
+
+* Create JavaScript on the Universal Login Page that can pull resources from a CDN based on the organization presented to it.
+* Create a separate tenant for the organization and use the Universal Login page to customize as desired for that organization.
+
+## Custom domain naming
+
+<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2b' }) %>
+
+## Email template customization
+
+<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2b' }) %>
+
+## Password reset page customization
+
+<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2b' }) %>
+
+## Error page customization
+
+<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2b' }) %>
+
+## Guardian multi-factor page customization
+
+<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'branding' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md
new file mode 100644
index 0000000000..8f0c437182
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-deployment.md
@@ -0,0 +1,28 @@
+---
+title: Deployment Automation
+description: How Auth0 tooling helps to automate tenant deployment.
+topics:
+    - b2b
+    - b2biam
+    - tenants
+    - deployment
+contentType: concept
+useCase:
+  - tenant-deployment
+---
+
+# Deployment Automation
+
+<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'deployment' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch.md
new file mode 100644
index 0000000000..358e53464e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch.md
@@ -0,0 +1,30 @@
+---
+classes: topic-page
+title: Launch Preparation
+description: Launch preparation considerations for your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+contentType: concept
+useCase:
+    - launch
+---
+# Launch Preparation
+
+<%= include('../../_includes/_launch/_introduction.md', { platform: 'b2b' }) %>
+<%= include('../../../_includes/_topic-links', { links: [ 
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck',
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing',
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations',
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance',
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support',
+  'architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch'
+ ] }) %>
+
+## Project Planning Guide
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'launch' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md
new file mode 100644
index 0000000000..01a2a4ce91
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-compliance.md
@@ -0,0 +1,24 @@
+---
+title: Compliance Readiness
+description: Compliance checks to perform before launch of your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+    - compliance
+contentType: concept
+useCase:
+    - launch
+---
+
+# Compliance
+
+<%= include('../../../_includes/_launch/_compliance.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md
new file mode 100644
index 0000000000..835be1391e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-launch.md
@@ -0,0 +1,23 @@
+---
+title: Launch Day Preparation
+description: Launch preparation considerations for your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+contentType: concept
+useCase:
+    - launch
+---
+
+# Launch Day Readiness
+
+<%= include('../../../_includes/_launch/_launch.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md
new file mode 100644
index 0000000000..e4742e5f13
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-operations.md
@@ -0,0 +1,24 @@
+---
+title: Operations Readiness
+description: Operations checks to perform before launch of your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+    - operations
+contentType: concept
+useCase:
+    - launch
+---
+
+# Operational Readiness
+
+<%= include('../../../_includes/_launch/_operations.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md
new file mode 100644
index 0000000000..818c04db04
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-support.md
@@ -0,0 +1,23 @@
+---
+title: Support Readiness 
+description: Support readiness for the launch of your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+    - support
+contentType: concept
+useCase:
+    - launch
+---
+
+# Support Readiness
+
+<%= include('../../../_includes/_launch/_support.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md
new file mode 100644
index 0000000000..bbe597465c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-tenantcheck.md
@@ -0,0 +1,24 @@
+---
+title: Tenant Check
+description: Tenant Checks to perform before launch of your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+    - configuration
+contentType: concept
+useCase:
+    - launch
+---
+
+# Tenant configuration check
+
+<%= include('../../../_includes/_launch/_tenant-check.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md
new file mode 100644
index 0000000000..e3c2314ffe
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-launch/b2b-launch-testing.md
@@ -0,0 +1,24 @@
+---
+title: Testing Complete
+description: Testing preparation for the launch of your B2B IAM implementation.
+topics:
+    - b2b
+    - ciam
+    - launch
+    - testing
+contentType: concept
+useCase:
+    - launch
+---
+
+# Testing
+
+<%= include('../../../_includes/_launch/_testing.md', { platform: 'b2b' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2b', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-logout.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-logout.md
new file mode 100644
index 0000000000..f818eb1ceb
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-logout.md
@@ -0,0 +1,58 @@
+---
+title: Logout
+description: User logout planning considerations for your B2B IAM implementation.
+topics:
+    - b2b
+    - b2biam
+    - logout
+    - sessions
+contentType: concept
+useCase:
+    - user-logout
+---
+# Logout
+
+<%= include('../../_includes/_logout/_introduction.md', { platform: 'b2b' }) %>
+
+## Single Logout
+
+If you are doing [Federated Logout](#federated-logout) you will likely also want to do Single Logout (SLO), and there are two main approaches you can take.
+
+::: warning
+SLO can add complexity to your system, so you need to ensure that you really need it before adding the extra development and maintenance time to your system.
+:::
+
+### Short-lived tokens
+
+::: panel Best Practice
+You want to avoid making too many calls to your Auth0 tenant to avoid rate limiting and poor performance.  A best practice is to only request new tokens if tokens have expired and a user takes an action.  This will avoid applications that are simply open, but not in use, from continually polling for new tokens.
+:::
+
+This is by far the simplest approach to Single Logout. Each application enforces a short time within which a user can use the system, say, 5-10 minutes. On each action a user performs, if the time has expired then either a redirect to Auth0 (for regular web apps), or [Silent Authentication](https://auth0.com/docs/api-auth/tutorials/silent-authentication) for client side Single Page Applications will be used to obtain new tokens. Ordinarily new tokens will be issued silently due to the Single Sign On (SSO) session. However, after logout, all applications will fail to get new tokens silently because the SSO session will have been removed, and the user will need to re-enter their credentials.
+
+::: warning
+If you are automatically forwarding the user directly to their own IdP as part of an enterprise connection using the connection parameter, this can break this technique unless you are also doing [Federated Logout](#federated-logout)
+:::
+
+### Build a logout service
+
+Another technique you can use is to build a logout service that can track and destroy application sessions. Each application would notify the logout service when it creates and removes a session. The (logout) service would either have direct access to all application's server side sessions and destroy them directly, or it will have the ability to make a back-channel call to each application to tell the application that it must remove its session.
+
+This technique can be quite effective as there is low-latency between when a user calls logout, and when they are then logged out of all applications. However it can add complexity and also additional development time for implementation. It will also require some way to ensure that new applications added to the system are added to this service.
+
+## Federated Logout
+
+[Federated User Logout](/logout/guides/logout-idps) may be something that you need to consider for your application.  If you or your customers will be using a third-party IdP (i.e., something other than a [Database Identity Provider](/connections/database)) then the question of whether you need to log the user out of the IdP when they log out of your application is something you will need to answer. The answer depends on what your users would expect. If the application and/or IdP you use is tied closely to a customer organization and a central part of day-to-day operations, then it may be frustrating for users to get logged out of their IdP when they log out of your application. If not, then being logged out of the IdP may be expected, or in some cases even desired. In most B2B scenarios, our customers find that it is preferable *not* to perform federated logout for a user.
+
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'logout' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-operations.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-operations.md
new file mode 100644
index 0000000000..7efd77e295
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-operations.md
@@ -0,0 +1,62 @@
+---
+title: Operations
+description: How to operationalize your Auth0 tenant environments.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - tenants
+    - operations
+contentType: concept
+useCase:
+  - tenant-operations
+---
+
+# Operations
+
+<%= include('../../_includes/_operations/_introduction.md', { platform: 'b2b' }) %>
+
+## Service status
+
+<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2b' }) %>
+
+## Email provider setup
+
+<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2b' }) %>
+
+## Infrastructure
+
+<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2b' }) %>
+
+## Logging
+
+<%= include('../../_includes/_operations/_logging.md', { platform: 'b2b' }) %>
+
+## Monitoring
+
+<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2b' }) %>
+
+## Notifications
+
+<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2b' }) %>
+
+## Provisioning organizations
+
+<%= include('../../_includes/_provisioning/_organizations.md', { platform: 'b2b' }) %>
+
+## Self-Service IdP provisioning
+
+While Auth0 [connections](/identityproviders) make it easy to configure IdPs, it can be a time-consuming process to onboard customer organization IdPs especially if you are selling to new customer organizations on a regular basis or existing organizations have changing IdP requirements. As a result, many of our customers have found it worthwhile to build a self-service portal for their customers' organization admins so that they can configure their own IdPs. This cuts down on your IT department's workload. The [Auth0 Management API](/api/management/v2) provides all necessary [connection](/api/management/v2#!/Connections/get_connections) management functionality to achieve this.
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'operations' }) %>
+
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md
new file mode 100644
index 0000000000..bdc3ed3749
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-profile-mgmt.md
@@ -0,0 +1,57 @@
+---
+title: Profile Management
+description: User profile management planning considerations for your B2B IAM implementation.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - user-profiles
+contentType: concept
+useCase:
+  - profile-management
+  - manage-user-profiles
+---
+# Profile Management
+
+<%= include('../../_includes/_profile-mgmt/_introduction.md', { platform: 'b2b' }) %>
+
+## Metadata
+
+<%= include('../../_includes/_profile-mgmt/_metadata.md', { platform: 'b2b' }) %>
+
+## Password reset
+
+<%= include('../../_includes/_profile-mgmt/_password-reset.md', { platform: 'b2b' }) %>
+
+## Account verification
+
+<%= include('../../_includes/_profile-mgmt/_account-verification.md', { platform: 'b2b' }) %>
+
+## Blocking users
+
+<%= include('../../_includes/_profile-mgmt/_blocking-users.md', { platform: 'b2b' }) %>
+
+## Admin portal
+
+An admin portal is an application where you can create new users, edit a user’s profile, see activity about a user, etc.  This application should be accessible by administrators only.  Though Auth0 provides its management dashboard, it is not advised to give access to the management dashboard to many people as there are a lot of ways someone can unintentionally break your Auth0 tenant.  Instead, Auth0 provides two other options:
+
+* [**Auth0 Management API**](/api/management/v2): With the Management API you can easily construct an application that provides administrators the ability to manage users.  You can either incorporate this into an existing application that already exists for your administrators, or create a new one with a UI that matches your current applications.
+
+* [**Auth0 Delegated Administration Extension**](/extensions/delegated-admin/v3): This powerful and flexible extension allows you to customize a user administration experience.  You can tailor this extension so that you can allow your customer admins to log in and allow them to only see and manage users within their organization.
+
+::: panel Best practice
+If you are providing your own way for an administrator to manage users, you should only allow administrators to send users a change password link through email rather than allowing administrators to set passwords directly. If you must go against this recommendation and allow your administrators to set someone’s password, you should force the user to change their password at their next login so that only they know the password (and not an administrator as well).
+:::
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'profile-mgmt' }) %>
+
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md
new file mode 100644
index 0000000000..8f2fe1e387
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-provisioning.md
@@ -0,0 +1,117 @@
+---
+title: Provisioning
+description: User provisioning functionality and considerations for your B2B IAM implementation.
+toc: true
+topics:
+    - b2b
+    - b2biam
+    - user-migration
+    - custom-db
+    - universal-login
+    - user-profiles
+contentType: concept
+useCase:
+  - user-provisioning
+  - store-user-data
+---
+# Provisioning
+
+<%= include('../../_includes/_provisioning/_introduction.md', { platform: 'b2b' }) %>
+
+## Provisioning organizations
+
+<%= include('../../_includes/_provisioning/_organizations.md', { platform: 'b2b' }) %>
+
+## User migration
+
+<%= include('../../_includes/_provisioning/_user-migration.md', { platform: 'b2b' }) %>
+
+## Provisioning organization users
+
+An organization should map directly to one of your business customers/partners. Each business/partner that you are working with has users who will be logging in. We call those end users *organization users*.
+There are two different approaches to how to store your organization users:
+
+* **Isolated to the organization**: Every user *belongs* to exactly one organization. It would not make sense for that user to be a part of more than one organization, and even if they were, it would make sense for them to have a separate “identity” for that other organization. For example, a retail employee that works part time at two different stores has two different logins for each of those stores even if the stores both use the SaaS application. To learn more, see [Provisioning users isolated to the organization](#provisioning-users-isolated-to-the-organization).
+* **Shared between organizations**: In a case like this, users either create credentials in your company, or they can access other organizations instances of your application using credentials from their own organization. A simple way to look at this is that one user may be authorized to access more than one organization’s instance of the application. A user would understand that they can use the same credentials to access both instances of an application. For example, some doctors contract with multiple clinics and may need to be able to sign into each separate clinic with their same credentials. To learn more, see [Provisioning users shared between organizations](#provisioning-users-shared-between-organizations). 
+
+### Provisioning users isolated to the organization
+
+Isolating users to the organization can provide a nice clean barrier between organizations. If no users ever need to access more than one organization (or you would rather force them to create multiple accounts), then this is an attractive approach.
+
+You need to provision those users at the IdP level. Each of the organizations will have its own IdP for accomplishing this.  This IdP will come in one of three flavors:
+
+* **Your Auth0 Tenant is the IdP**: A Database Connection in your main tenant dedicated to this organization.
+* **Organizations bring their own IdP**: You set up an Enterprise Connection for them.
+* **Organizations with more than one IdP**: This situation is a little more tricky becasue you have multiple options for approaching this situation. In descending order of complexity, these include:
+    * You convince them to create (or find that they already have) one main IdP that can route to their individual IdPs.
+    * You create separate organizations (e.g. customerorg-department1 and customerorg-department2) in your applications.
+    * You set up a new Auth0 tenant just for them and add as many IdPs as they need (which may include a database in Auth0) to that tenant, along with their own custom domain and branding.
+    * You make your existing tenant and login page more complex to handle [Home Realm Discovery](/architecture-scenarios/implementation/b2b/b2b-authentication#home-real-discovery) just for organizations that have more than one IdP.
+
+We recommend using Auth0 as an IdP as a starting point because it’s simple to implement a user invite workflow: an administrator creates a user; a randomly-generated password is created for that user, but never stored or shown to anyone; and then the user receives a welcome email with a link to set their password. Compared to other invite flows, the only thing special about this is that the person who is creating the user will have to either select the organization ahead of time, or the system will force the organization to match that of the user doing the inviting (in situations where there is an organization administrator who belongs to that organization only). To learn more, see [User invite](#user-invite).
+
+::: panel Best Practice
+If you can keep a main Auth0 tenant with a one-to-one mapping between organization and connection, it will greatly simplify your login system, making it more maintainable and extendable for the future. See [Multiple Organization Architecture documents: isolated users by organization](https://drive.google.com/a/auth0.com/file/d/1fzWWu7CUWaPpmaSO01gEhVYmkSXvV28l/view?usp=sharing) for a more in-depth view.
+:::
+
+### Provisioning users shared between organizations
+
+When sharing users between organizations, you will need a way to authorize access. Because you won’t know where a user might belong when authenticating, we typically recommend storing your users in a single domain and then figuring out which organizations they can access by using user app metadata. Because of this, provisioning will often be done by starting with a User Invite workflow for the single database connection, and then app metadata will be used to authorize access. User app metadata allows information to be stored in a user’s profile that can impact a user's capabilities but which a user cannot change. Let’s say I’m a doctor and I belong to Clinic A and Clinic B. I might have an organizations object in my app metadata that looks like: `{ “organizations”: [“clinicA”,”clinicB”] }`, and then when attempting to log into the app for Clinic B, a rule can check that Clinic B is in the `organizations` array.
+
+::: panel Best Practice
+Because users are shared, you won’t be able to determine who has access by isolating them to their own connection, therefore you will need to use their app metadata to make the determination. When provisioning, you will need a way to set the organizations they have access to or add a new organization to an already existing user.
+:::
+
+### Deprovisioning limitations
+
+<%= include('../../_includes/_provisioning/_deprovisioning.md', { platform: 'b2b' }) %>
+
+## User invite
+
+In most B2B scenarios, only particular individuals are allowed access to the application. As a result, it is often simpler to have an administrator provision user accounts rather than having users sign up and then have an administrator approve them. Provisioning can often be done in an automated fashion when users are added to a centralized system as well.
+
+There are three different personas who might be [inviting users](/design/creating-invite-only-applications):
+
+* An administrator at your company may create the users for each organization.
+* An administrator from each organization may be assigned to creating users.
+* Another system responsible for creating users mahy exist, and that system may then create a user in Auth0.
+Regardless of the audience, the technique can be similar, with the exception of the third option which would require the use of the management API and could not be done using the Delegated Administration Extension. The rest is a matter of using the right authorization model for the application.
+
+User invite can be accomplished in a few ways:
+
+* Using the [Delegated Administration Extension](/extensions/delegated-admin/v3)
+* Updating a pre-existing user administration system that you’ve already created to use the [Management API](/api/management/v2)
+* Creating a new application to do this using the Management API.
+
+::: panel Best Practice
+Whether you are using the Management API or the Delegated Administration Extension, it is important to create each user with a random temporary password and *not* store that password anywhere! Then, use the Management API to send an email to the user with a link to set their password. This ensures that the only person who knows the password is the user themselves.
+:::
+
+::: warning
+One of the main principles of OIDC is that no one except the user themselves ever knows their password. If you are doing an invite flow, have your backend system randomly generate a password and then discard it and have your user reset their password before ever logging in.  Do not create a temporary password and give it to them to log in the first time.
+:::
+
+## Enterprise sign up
+
+Enterprise sign up is synonymous with sign in via [enterprise login](/architecture-scenarios/implementation/b2b/b2b-authentication#enterprise-login)—there’s no distinction here *per se*, as user [profile](/architecture-scenarios/implementation/b2b/b2b-profile-mgmt) creation happens automatically upon first enterprise login.
+
+::: panel best practice
+A nice advantage of allowing your customers to use their own IdP is that they can administer their users and assign roles and access in their own IdP setup instead of forcing you to build administration for them. Working out the mapping for those customers will make this much easier.
+:::
+
+::: warning
+  If mapping isn't enough and you must put some metadata in your system, keep in mind that Auth0 will not create the user until they log in to the system the first time. Therefore, you will need to use rule extensibility to pull the initial information from somewhere else, or force users to log in the first time before you can add the metadata.
+:::
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'provisioning' }) %>
+
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-qa.md b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-qa.md
new file mode 100644
index 0000000000..2aa5556410
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2b/b2b-qa.md
@@ -0,0 +1,41 @@
+---
+title: Quality Assurance
+description: Quality Assurance considerations for your B2B IAM implementation.
+toc: true
+topics:
+    - qa
+    - b2b
+    - b2biam
+    - quality
+contentType: concept
+useCase:
+  - quality-assurance
+---
+# Quality Assurance
+
+<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2b' }) %>
+
+## Unit testing
+
+<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2b' }) %>
+
+## Integration testing
+
+<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2b' }) %>
+
+## Mock testing
+
+<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2b' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2b' }) %>
+
+## Multiple Organization Architecture (Multitenancy)
+
+<%= include('../../_includes/_multitenancy.md', { platform: 'b2b' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2b', self: 'qa' }) %>
+
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md
new file mode 100644
index 0000000000..9d01f715a0
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-architecture.md
@@ -0,0 +1,40 @@
+---
+title: Architecture
+description: How you configure your Auth0 tenant architecture affects your B2C IAM implementation.
+toc: true
+topics:
+    - b2c
+    - ciam
+    - tenants
+contentType: concept
+useCase:
+  - tenant-architecture
+---
+
+# Architecture
+
+<%= include('../../_includes/_architecture/_introduction.md', { platform: 'b2c' }) %>
+
+## Tenant provision
+
+<%= include('../../_includes/_architecture/_tenant-provision.md', { platform: 'b2c' }) %>
+
+## Tenant association
+
+<%= include('../../_includes/_architecture/_tenant-association.md', { platform: 'b2c' }) %>
+
+## Custom domains
+
+<%= include('../../_includes/_architecture/_custom-domains.md', { platform: 'b2c' }) %>
+
+## SDLC support
+
+<%= include('../../_includes/_architecture/_sdlc-support.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'architecture' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md
new file mode 100644
index 0000000000..daffa7e833
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authentication.md
@@ -0,0 +1,52 @@
+---
+title: Authentication
+description: How authentication works in your B2C IAM implementation.
+toc: true
+topics:
+    - b2c
+    - ciam
+    - authentication
+    - universal-login
+contentType: concept
+useCase:
+    - authentication
+---
+# Authentication
+
+<%= include('../../_includes/_authentication/_introduction.md', { platform: 'b2c' }) %>
+
+## Universal Login
+
+<%= include('../../_includes/_authentication/_universal-login.md', { platform: 'b2c' }) %>
+
+## Username and password authentication
+
+<%= include('../../_includes/_authentication/_username-and-password-authentication.md', { platform: 'b2c' }) %>
+
+## Application integration
+
+<%= include('../../_includes/_authentication/_application-integration.md', { platform: 'b2c' }) %>
+
+## Anomaly detection
+
+<%= include('../../_includes/_authentication/_attack-protection.md', { platform: 'b2c' }) %>
+
+## SSO with legacy systems
+
+<%= include('../../_includes/_authentication/_sso-legacy.md', { platform: 'b2c' }) %>
+
+## Social authentication
+
+<%= include('../../_includes/_authentication/_social-authentication.md', { platform: 'b2c' }) %>
+
+## Multi-factor authentication (MFA)
+
+<%= include('../../_includes/_authentication/_mfa.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'authentication' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md
new file mode 100644
index 0000000000..4394f0b496
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-authorization.md
@@ -0,0 +1,39 @@
+---
+title: Authorization
+description: User authorization and related planning considerations for your B2C IAM implementation.
+toc: true
+topics:
+    - b2c
+    - ciam
+    - user-authorization
+contentType: concept
+useCase:
+  - user-authorization
+---
+# Authorization
+
+<%= include('../../_includes/_authorization/_introduction.md', { platform: 'b2c' }) %>
+
+## Application integration
+
+<%= include('../../_includes/_authorization/_application-integration.md', { platform: 'b2c' }) %>
+
+## API integration
+
+<%= include('../../_includes/_authorization/_api-integration.md', { platform: 'b2c' }) %>
+
+## Role Based Access Control (RBAC)
+
+<%= include('../../_includes/_authorization/_rbac.md', { platform: 'b2c' }) %>
+
+## Machine-to-Machine (M2M) Authorization
+
+<%= include('../../_includes/_authorization/_m2m.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'authorization' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-branding.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-branding.md
new file mode 100644
index 0000000000..cba76c1648
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-branding.md
@@ -0,0 +1,52 @@
+---
+title: Branding
+description: How to configure Auth0 items to reflect your brand and desired user experience.
+toc: true
+topics:
+    - b2c
+    - ciam
+    - branding
+    - universal-login
+    - login-pages
+    - password-reset-pages
+    - custom-domains
+    - error-pages
+contentType: concept
+useCase:
+    - user-logout
+---
+# Branding
+
+<%= include('../../_includes/_branding/_introduction.md', { platform: 'b2c' }) %>
+
+## Universal login and login pages
+
+<%= include('../../_includes/_branding/_universal-login.md', { platform: 'b2c' }) %>
+
+## Custom domain naming
+
+<%= include('../../_includes/_branding/_custom-domain-naming.md', { platform: 'b2c' }) %>
+
+## Email template customization
+
+<%= include('../../_includes/_branding/_email-templates.md', { platform: 'b2c' }) %>
+
+## Password reset page customization
+
+<%= include('../../_includes/_branding/_password-reset.md', { platform: 'b2c' }) %>
+
+## Error page customization
+
+<%= include('../../_includes/_branding/_error-page.md', { platform: 'b2c' }) %>
+
+## Guardian multi-factor page customization
+
+<%= include('../../_includes/_branding/_guardian.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'branding' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md
new file mode 100644
index 0000000000..896280664b
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-deployment.md
@@ -0,0 +1,24 @@
+---
+title: Deployment Automation
+description: How Auth0 tooling helps to automate tenant deployment.
+topics:
+    - b2c
+    - ciam
+    - tenants
+    - deployment
+contentType: concept
+useCase:
+  - tenant-deployment
+---
+
+# Deployment Automation
+
+<%= include('../../_includes/_deployment/_introduction.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'deployment' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch.md
new file mode 100644
index 0000000000..8eed687f5e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch.md
@@ -0,0 +1,30 @@
+---
+classes: topic-page
+title: Launch Preparation
+description: Launch preparation considerations for your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+contentType: concept
+useCase:
+    - launch
+---
+# Launch Preparation
+
+<%= include('../../_includes/_launch/_introduction.md', { platform: 'b2c' }) %>
+<%= include('../../../_includes/_topic-links', { links: [ 
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck',
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing',
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations',
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance',
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support',
+  'architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch'
+ ] }) %>
+
+## Project Planning Guide
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'launch' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md
new file mode 100644
index 0000000000..1712d77cc6
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-compliance.md
@@ -0,0 +1,24 @@
+---
+title: Compliance Readiness
+description: Compliance checks to perform before launch of your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+    - compliance
+contentType: concept
+useCase:
+    - launch
+---
+
+# Compliance
+
+<%= include('../../../_includes/_launch/_compliance.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md
new file mode 100644
index 0000000000..3459fb54f8
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-launch.md
@@ -0,0 +1,23 @@
+---
+title: Launch Day Preparation
+description: Launch preparation considerations for your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+contentType: concept
+useCase:
+    - launch
+---
+
+# Launch Day Readiness
+
+<%= include('../../../_includes/_launch/_launch.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md
new file mode 100644
index 0000000000..eb2a8942e8
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-operations.md
@@ -0,0 +1,24 @@
+---
+title: Operations Readiness
+description: Operations checks to perform before launch of your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+    - operations
+contentType: concept
+useCase:
+    - launch
+---
+
+# Operational Readiness
+
+<%= include('../../../_includes/_launch/_operations.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md
new file mode 100644
index 0000000000..188827213e
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-support.md
@@ -0,0 +1,23 @@
+---
+title: Support Readiness 
+description: Support readiness for the launch of your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+    - support
+contentType: concept
+useCase:
+    - launch
+---
+
+# Support Readiness
+
+<%= include('../../../_includes/_launch/_support.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md
new file mode 100644
index 0000000000..dc54e51cb3
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-tenantcheck.md
@@ -0,0 +1,24 @@
+---
+title: Tenant Check
+description: Tenant Checks to perform before launch of your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+    - configuration
+contentType: concept
+useCase:
+    - launch
+---
+
+# Tenant configuration check
+
+<%= include('../../../_includes/_launch/_tenant-check.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md
new file mode 100644
index 0000000000..6e313784cb
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-launch/b2c-launch-testing.md
@@ -0,0 +1,24 @@
+---
+title: Testing Complete
+description: Testing preparation for the launch of your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - launch
+    - testing
+contentType: concept
+useCase:
+    - launch
+---
+
+# Testing
+
+<%= include('../../../_includes/_launch/_testing.md', { platform: 'b2c' }) %>
+
+# Project Planning Guide
+
+<%= include('../../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+# Keep reading
+
+<%= include('../../../_includes/_keep-reading.md', { platform: 'b2c', self: '*ignore*' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-logout.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-logout.md
new file mode 100644
index 0000000000..79659c64c7
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-logout.md
@@ -0,0 +1,23 @@
+---
+title: Logout
+description: User logout planning considerations for your B2C IAM implementation.
+topics:
+    - b2c
+    - ciam
+    - logout
+    - sessions
+contentType: concept
+useCase:
+    - user-logout
+---
+# Logout
+
+<%= include('../../_includes/_logout/_introduction.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'logout' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-operations.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-operations.md
new file mode 100644
index 0000000000..b10ab32dcc
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-operations.md
@@ -0,0 +1,49 @@
+---
+title: Operations
+description: How to operationalize your Auth0 tenant environments.
+toc: true
+topics:
+    - b2c
+    - ciam
+    - tenants
+    - operations
+contentType: concept
+useCase:
+  - tenant-operations
+---
+
+# Operations
+
+<%= include('../../_includes/_operations/_introduction.md', { platform: 'b2c' }) %>
+
+## Service status
+
+<%= include('../../_includes/_operations/_service-status.md', { platform: 'b2c' }) %>
+
+## Email provider setup
+
+<%= include('../../_includes/_operations/_email-provider.md', { platform: 'b2c' }) %>
+
+## Infrastructure
+
+<%= include('../../_includes/_operations/_infrastructure.md', { platform: 'b2c' }) %>
+
+## Logging
+
+<%= include('../../_includes/_operations/_logging.md', { platform: 'b2c' }) %>
+
+## Monitoring
+
+<%= include('../../_includes/_operations/_monitoring.md', { platform: 'b2c' }) %>
+
+## Notifications
+
+<%= include('../../_includes/_operations/_notifications.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'operations' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md
new file mode 100644
index 0000000000..5065318caf
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-profile-mgmt.md
@@ -0,0 +1,48 @@
+---
+title: Profile Management
+description: User profile management planning considerations for your B2C IAM implementation. 
+toc: true
+topics:
+    - b2c
+    - ciam
+    - user-profiles
+contentType: concept
+useCase:
+  - profile-management
+  - manage-user-profiles
+---
+# Profile Management
+
+<%= include('../../_includes/_profile-mgmt/_introduction.md', { platform: 'b2c' }) %>
+
+## Metadata
+
+<%= include('../../_includes/_profile-mgmt/_metadata.md', { platform: 'b2c' }) %>
+
+## Password reset
+
+<%= include('../../_includes/_profile-mgmt/_password-reset.md', { platform: 'b2c' }) %>
+
+## Account verification
+
+<%= include('../../_includes/_profile-mgmt/_account-verification.md', { platform: 'b2c' }) %>
+
+## Blocking users 
+
+<%= include('../../_includes/_profile-mgmt/_blocking-users.md', { platform: 'b2c' }) %>
+
+## Linking user accounts 
+
+<%= include('../../_includes/_profile-mgmt/_linking-accounts.md', { platform: 'b2c' }) %>
+
+## De-provisioning
+
+<%= include('../../_includes/_profile-mgmt/_de-provisioning.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'profile-mgmt' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md
new file mode 100644
index 0000000000..df2c065de1
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-provisioning.md
@@ -0,0 +1,39 @@
+---
+title: Provisioning
+description: User provisioning functionality and considerations for your B2C IAM  implementation. 
+toc: true
+topics:
+    - b2c
+    - ciam
+    - user-migration
+    - custom-db
+    - universal-login
+    - user-profiles
+contentType: concept
+useCase:
+  - user-provisioning
+  - store-user-data
+---
+# Provisioning
+
+<%= include('../../_includes/_provisioning/_introduction.md', { platform: 'b2c' }) %>
+
+## User migration
+
+<%= include('../../_includes/_provisioning/_user-migration.md', { platform: 'b2c' }) %>
+
+## Self sign up
+
+<%= include('../../_includes/_provisioning/_self-signup.md', { platform: 'b2c' }) %>
+
+## Social sign up
+
+<%= include('../../_includes/_provisioning/_social-signup.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'provisioning' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-qa.md b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-qa.md
new file mode 100644
index 0000000000..e27135e1cf
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/implementation/b2c/b2c-qa.md
@@ -0,0 +1,36 @@
+---
+title: Quality Assurance
+description: Quality Assurance considerations for your B2C IAM implementation.
+toc: true
+topics:
+    - qa
+    - b2c
+    - ciam
+    - quality
+contentType: concept
+useCase:
+  - quality-assurance
+---
+# Quality Assurance
+
+<%= include('../../_includes/_qa/_introduction.md', { platform: 'b2c' }) %>
+
+## Unit testing
+
+<%= include('../../_includes/_qa/_unit-testing.md', { platform: 'b2c' }) %>
+
+## Integration testing 
+
+<%= include('../../_includes/_qa/_integration-testing.md', { platform: 'b2c' }) %>
+
+## Mock testing 
+
+<%= include('../../_includes/_qa/_mock-testing.md', { platform: 'b2c' }) %>
+
+## Project Planning Guide
+
+<%= include('../../_includes/_planning.md', { platform: 'b2c' }) %>
+
+## Keep reading
+
+<%= include('../../_includes/_keep-reading.md', { platform: 'b2c', self: 'qa' }) %>
diff --git a/ja-jp/articles/architecture-scenarios/index.md b/ja-jp/articles/architecture-scenarios/index.md
new file mode 100644
index 0000000000..5f1cf6d905
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/index.md
@@ -0,0 +1,78 @@
+---
+url: /architecture-scenarios
+classes: topic-page
+title: Architecture Scenarios
+description: Learn about the common architecture scenarios that you will use to solve the authorization and authentication needs of your application.
+topics:
+    - architecture
+    - api-auth
+    - authorization-code
+    - b2c
+    - b2b
+    - ciam
+contentType: index
+useCase:
+  - invoke-api
+  - secure-an-api
+  - build-an-app
+  - implementation
+---
+
+
    
+  
    
+  
    Architecture Scenarios
    
+  
    
+  This page describes the typical architecture scenarios we have identified when working with customers on implementing Auth0. 
+  
    
+
    
+
+## Application configurations
+
+These scenarios describe the different type of technology architectures your application may use, and how Auth0 can help for each of those. 
+
+The goal of these scenarios is to walk you through the implementation process from beginning to end.
+
+
      
+  
    • 
+    Business to Business Identity and Access Management
+    
      SaaS applications with users associated with third-party companies registered as tenants of the SaaS app.
      
+  
      • 
+  
    • 
+    Business to Consumer Identity and Access Management
+    
      SaaS/eCommerce apps with customers as end users using the OpenID Connect protocol.
      
+  
      • 
+  
    • 
+    Business to Employee Identity Scenarios
+    
      Enterprise directory services using federation to allow employees to log in to applications using their existing enterprise credentials.
      
+  
      • 
+  
    • 
+    Single Sign-On for Regular Web Apps
+    
      Traditional web application which needs to authenticate users using OpenID Connect (OIDC).
      
+  
      • 
+  
    • 
+    Server Application + API
+    
      Server to server communication where a server needs to make secure calls to an API.
      
+  
      • 
+  
    • 
+    SPA + API
+    
      Single-Page Web Application which talks to an API. The application will use OpenID Connect with the Implicit Grant Flow to authenticate users with Auth0.
      
+  
      • 
+  
    • 
+    Mobile + API
+    
      Mobile Application which talks to an API. The application will use OpenID Connect with the Authorization Code Grant using Proof Key for Code Exchange (PKCE) to authenticate users.
      
+  
      • 
+
    
+
+## Implementation checklists
+
+<%= include('./_includes/_implementation-checklists.md') %>
+
+## Implementation resources
+
+Auth0 provides many [resources](/architecture-scenarios/implementation-resources) to help you learn about Auth0, get started quickly, test sample code, and try out APIs.
+
+The Auth0 [Community](https://community.auth0.com) forum and [Blog](https://auth0.com/blog) connect you with the world of Auth0, while our [Support Center](https://support.auth0.com) helps you report issues and manage your subscription. Additionally, you can submit suggested product enhancements through our feedback portal.
+
+We've also made it easy to use our [Status Dashboard](https://status.auth0.com), monitor endpoints, and log data. Notifications keep you up-to-date with Auth0 announcements, and we provide a variety of methods to stay informed about privacy, security, and compliance.
+
+In addition, our [Professional Services](/services) team is available to help you with any architecture needs, including pre-launch advice, production checklists, and operational policies.
diff --git a/ja-jp/articles/architecture-scenarios/mobile-api/_stepnav.html b/ja-jp/articles/architecture-scenarios/mobile-api/_stepnav.html
new file mode 100644
index 0000000000..8e021cac76
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/mobile-api/_stepnav.html
@@ -0,0 +1,14 @@
+
    
+  <% if (typeof prev !== 'undefined') { %>
+  
    
+    
    Previous Tutorial
    
+     ${prev[0]}
+  
    
+  <% } %>
+  <% if (typeof next !== 'undefined') { %>
+  
    
+    
    Next Tutorial
    
+    ${next[0]} 
+  
    
+  <% } %>
+
    
diff --git a/ja-jp/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md b/ja-jp/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md
new file mode 100644
index 0000000000..7f02afc324
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md
@@ -0,0 +1,256 @@
+---
+description: The Node.js implementation of the API for the Mobile + API architecture scenario
+toc: true
+topics:
+  - mobile-apps
+  - api-auth
+  - nodejs
+  - architecture
+  - authorization-code
+  - pkce
+contentType: tutorial
+useCase:
+  - invoke-api
+  - secure-an-api
+  - enable-mobile-auth
+  - build-an-app
+---
+
+# Mobile + API: Node.js Implementation for the API
+
+This document is part of the [Mobile + API Architecture Scenario](/architecture-scenarios/application/mobile-api) and it explains how to implement the API in Node.js. Please refer to the scenario for information on the implemented solution.
+
+::: note
+The full source code for the Node.js API implementation can be found in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-api/node).
+:::
+
+## 1. Define the API endpoints
+
+We will use the [Express web application framework](http://expressjs.com/) to build our Node.js API.
+
+### Create a package.json File
+
+Create a folder for your API, navigate into it and run `npm init`. This will setup your `package.json` file.
+
+You can leave the default settings or change them as you see fit.
+
+Our sample's `package.json` looks like the following:
+
+```json
+{
+  "name": "timesheets-api",
+  "version": "1.0.0",
+  "description": "API used to add timesheet entries for employees and contractors",
+  "main": "index.js",
+  "scripts": {
+    "test": "echo \"Error: no test specified\" && exit 1"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/auth0-samples/auth0-pnp-timesheets.git"
+  },
+  "author": "Auth0",
+  "license": "MIT",
+  "bugs": {
+    "url": "https://github.com/auth0-samples/auth0-pnp-timesheets/issues"
+  },
+  "homepage": "https://github.com/auth0-samples/auth0-pnp-timesheets#readme"
+}
+```
+
+### Install the Dependencies
+
+Next, we need to set our dependencies. We will use the following modules:
+
+- **express**: This module adds the [Express web application framework](https://expressjs.com/).
+
+- **cors**: This module adds support for enabling [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) which is required since the API will be called from a Single-Page Application running on a different domain inside a web browser.
+
+- **jwks-rsa**: This library retrieves RSA signing keys from a **JWKS** (JSON Web Key Set) endpoint. Using `expressJwtSecret` we can generate a secret provider that will provide the right signing key to `express-jwt` based on the `kid` in the JWT header. For more information refer to the [node-jwks-rsa GitHub repository](https://github.com/auth0/node-jwks-rsa).
+
+- **express-jwt**: This module lets you authenticate HTTP requests using JWT tokens in your Node.js applications. It provides several functions that make working with JWTs easier. For more information refer to the [express-jwt GitHub repository](https://github.com/auth0/express-jwt).
+
+- **body-parser**: This is a Node.js body parsing middleware. It extracts the entire body portion of an incoming request stream and exposes it on `req.body` as something easier to interface with.For more information and several alternatives refer to the body-parser GitHub repository.
+
+To install these dependencies run the following:
+
+```bash
+npm install express cors express-jwt jwks-rsa body-parser express-jwt-authz --save
+```
+
+### Implement the Endpoints
+
+Navigate to your API directory and create a `server.js` file. Your code needs to:
+
+- Get the dependencies.
+- Implement the endpoint(s).
+- Launch the API server.
+
+This is our sample implementation:
+
+```js
+const express = require('express');
+const app = express();
+const jwt = require('express-jwt');
+const jwksRsa = require('jwks-rsa');
+const cors = require('cors');
+const bodyParser = require('body-parser');
+
+// Enable CORS
+app.use(cors());
+
+// Enable the use of request body parsing middleware
+app.use(bodyParser.json());
+app.use(bodyParser.urlencoded({
+  extended: true
+}));
+
+// Create timesheets API endpoint
+app.post('/timesheets', function(req, res){
+  res.status(201).send({message: "This is the POST /timesheets endpoint"});
+})
+
+// Launch the API Server at localhost:8080
+app.listen(8080);
+```
+
+Launch your API server using `node server` and make an HTTP POST request to `localhost:8080/timesheets`. You should see a JSON response with the message `This is the POST /timesheets endpoint`.
+
+So now we have our endpoint but anyone can call it. Continue to the next paragraph to see how we can fix this.
+
+## 2. Secure the API endpoints
+
+In order to validate our token we will use the `jwt` function, provided by the [express-jwt middleware](https://github.com/auth0/express-jwt#usage), and the `jwks-rsa` to retrieve our secret. The libraries do the following:
+
+1. `express-jwt` will decode the token and pass the request, the header and the payload to `jwksRsa.expressJwtSecret`.
+
+1. `jwks-rsa` will then download all signing keys from the JWKS endpoint and see if a one of the signing keys matches the `kid` in the header of the JWT. If none of the signing keys match the incoming `kid`, an error will be thrown. If we have a match, we will pass the right signing key to `express-jwt`.
+
+1. `express-jwt` will the continue its own logic to validate the signature of the token, the expiration, `audience` and the `issuer`.
+
+The steps we will follow in our code are:
+
+- Create the middleware function to validate the Access Token.
+- Enable the use of the middleware in our routes.
+
+You can also write some code to actually save the timesheet to a database. This is our sample implementation (some code is omitted for brevity):
+
+```js
+// set dependencies - code omitted
+
+// Enable CORS - code omitted
+
+// Create middleware for checking the JWT
+const checkJwt = jwt({
+  // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint
+  secret: jwksRsa.expressJwtSecret({
+    cache: true,
+    rateLimit: true,
+    jwksRequestsPerMinute: 5,
+    jwksUri: `https://${account.namespace}/.well-known/jwks.json`
+  }),
+
+  // Validate the audience and the issuer
+  audience: '{YOUR_API_IDENTIFIER}', //replace with your API's audience, available at Dashboard > APIs
+  issuer: 'https://${account.namespace}/',
+  algorithms: [ 'RS256' ]
+});
+
+// Enable the use of request body parsing middleware - code omitted
+
+// create timesheets API endpoint - code omitted
+app.post('/timesheets', checkJwt, function(req, res){
+  var timesheet = req.body;
+
+  // Save the timesheet to the database...
+
+  //send the response
+  res.status(201).send(timesheet);
+});
+// launch the API Server at localhost:8080 - code omitted
+```
+
+If we launch our server now and do an HTTP POST to `localhost:8080/timesheets` we should get the error message `Missing or invalid token` (which is perfectly fine since we didn’t send an Access Token in our request).
+
+In order to test the working scenario as well we need to:
+
+- Get an Access Token. For details on how to do so refer to: [Get an Access Token](/architecture-scenarios/application/server-api#get-an-access-token).
+- Invoke the API while adding an `Authorization` header to our request with the value `Bearer ACCESS_TOKEN` (where *ACCESS_TOKEN* is the value of the token we retrieved in the first step).
+
+## 3. Check the application permissions
+
+In this step we will add to our implementation the ability to check if the application has permissions (or `scope`) to use our endpoint in order to create a timesheet. In particular we want to ensure that the token has the correct scope, which is `batch:upload`.
+
+In order to do this we will make use of the `express-jwt-authz` Node.js package, so go ahead and add that to your project:
+
+```bash
+npm install express-jwt-authz --save
+```
+
+Now it is as simple as adding a call to `jwtAuthz(...)` to your middleware to ensure that the JWT contain a particular scope in order to execute a particular endpoint.
+
+We will add an additional dependency. The **express-jwt-authz** library, which is used in conjunction with express-jwt, validates the [JWT](/tokens/concepts/jwts) and ensures it bears the correct permissions to call the desired endpoint. For more information refer to the [express-jwt-authz GitHub repository](https://github.com/auth0/express-jwt-authz).
+
+This is our sample implementation (some code is omitted for brevity):
+
+```js
+// set dependencies - some code omitted
+const jwtAuthz = require('express-jwt-authz');
+
+// Enable CORS - code omitted
+
+// Create middleware for checking the JWT - code omitted
+
+// Enable the use of request body parsing middleware - code omitted
+
+// create timesheets API endpoint
+app.post('/timesheets', checkJwt, jwtAuthz(['create:timesheets']), function(req, res){
+  var timesheet = req.body;
+
+  // Save the timesheet to the database...
+
+  //send the response
+  res.status(201).send(timesheet);
+})
+
+// launch the API Server at localhost:8080 - code omitted
+```
+
+If we invoke our API with a token that does not include this scope we should get the error message Forbidden with the HTTP status code `403`. You can test this by removing this scope from your API.
+
+## 4. Determine the User Identity
+
+The `express-jwt` middleware which is used to validate the JWT, also sets the `req.user` with the information contained in the JWT. If you want to use the `sub` claim to identify the user uniquely, you can simply use `req.user.sub`.
+
+In the case of the timesheets application however, we want to use the email address of the user as the unique identifier.
+
+The first thing we need to do is to write a rule which will add the email address of the user to the Access Token. Go to the [Rules section](${manage_url}/#/rules}) of the Dashboard and click on the __Create Rule__ button.
+
+You can give the rule a descriptive name, for example `Add email to Access Token`, and then use the following code for the rule:
+
+```js
+function (user, context, callback) {
+  const namespace = 'https://api.exampleco.com/';
+  context.accessToken[namespace + 'email'] = user.email;
+  callback(null, user, context);
+}
+```
+
+The `namespace` is used to ensure the claim has a unique name and does not clash with the names of any of the standard OIDC claims. For more info on namespaced claims, see [Namespacing Claims](/tokens/guides/create-namespaced-custom-claims).
+
+Next, inside your API, you can retrieve the value of the claim from `req.user`, and use that as the unique user identity which you can associate with timesheet entries.
+
+```js
+app.get('/timesheets', checkJwt, jwtAuthz(['read:timesheets']), function(req, res) {
+  var timesheet = req.body;
+
+  // Associate the timesheet entry with the current user
+  var userId = req.user['https://api.exampleco.com/email'];
+  timesheet.user_id = userId;
+
+  // Save the timesheet to the database...
+
+  //send the response
+  res.status(201).send(timesheet);
+});
+```
diff --git a/ja-jp/articles/architecture-scenarios/mobile-api/index.md b/ja-jp/articles/architecture-scenarios/mobile-api/index.md
new file mode 100644
index 0000000000..c96949af52
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/mobile-api/index.md
@@ -0,0 +1,60 @@
+---
+order: 04
+title: Mobile + API
+image: /media/articles/architecture-scenarios/mobile-api.png
+extract: Mobile application which talks to an API. The application will use OpenID Connect (OIDC) with the Authorization Code Grant using Proof Key for Code Exchange (PKCE) to authenticate users.
+description: Explains the architecture scenario with a mobile application communicating with an API.
+toc: true
+topics:
+    - architecture
+    - mobile-apps
+    - api-auth
+    - authorization-code
+    - pkce
+contentType: 
+    - index
+    - tutorial
+useCase:
+  - invoke-api
+  - secure-an-api
+  - enable-mobile-auth
+  - build-an-app
+---
+
+# Mobile + API
+
+In this scenario we will build a Timesheet API for a fictitious company named ExampleCo. The API will allow management of timesheet entries for an employee or a contractor.
+
+We will also be building a mobile application which will be used to view and log timesheet entries in the centralized timesheet database using the API.
+
+
+::: panel TL;DR
+* Auth0 provides API Authentication and Authorization as a means to secure access to API endpoints (see [API Authentication and Authorization](/architecture-scenarios/mobile-api/part-1#api-authentication-and-authorization))
+* For authorizing a mobile app user and granting access to the API, Auth0 supports the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) (see [Proof Key for Code Exchange](/architecture-scenarios/mobile-api/part-1#proof-key-for-code-exchange-pkce-))
+* Both the mobile app and the API must be configured in the Auth0 Dashboard (see [Auth0 Configuration](/architecture-scenarios/mobile-api/part-2))
+* User Permissions can be enforced using the Authorization Extension (see [Configure the Authorization Extension](/architecture-scenarios/mobile-api/part-2#configure-the-authorization-extension))
+* The API is secured by ensuring that a valid [Access Token](/tokens/concepts/access-tokens) is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/architecture-scenarios/mobile-api/part-3#secure-the-endpoints))
+* The Auth0.Android SDK can be used to authorize the user of the mobile app and obtain a valid Access Token which can be used to call the API (see [Authorize the User](/architecture-scenarios/mobile-api/part-3#authorize-the-user))
+* The mobile app can retrieve the user's profile information by decoding the ID Token (see [Get the User Profile](/architecture-scenarios/mobile-api/part-3#get-the-user-profile))
+* UI Elements can be displayed conditionally based on the scope that was granted to the user (see [Display UI Elements Conditionally Based on Scope](/architecture-scenarios/mobile-api/part-3#display-ui-elements-conditionally-based-on-scope))
+* The mobile app provides the Access Token in the HTTP Authorization header when making calls to the API (see [Call the API](/architecture-scenarios/mobile-api/part-3#call-the-api))
+* The mobile app user's Access Token can be renewed to ensure the user does not have to log in again during a session (see [Renew the Token](/architecture-scenarios/mobile-api/part-3#renew-the-token))
+:::
+
+## The Premise
+
+ExampleCo is a consulting startup company. Currently they have approximately 100 employees and they also outsource several activities to external contractors. All employees and external contractors are required to fill in their timesheets every week. 
+
+The company has built a timesheets application, a scenario we covered in [Single Sign-On for Regular Web Apps](/architecture-scenarios/application/web-app-sso). The internal employees use this web app to fill in their timesheets, but the company wants a mobile application for employees and contractors to use while not on the premises. The app will be used to log timesheet entries and send the data to the centralized timesheet database using the API. The app will also allow managers to approve timesheet entries.
+
+### Goals & Requirements
+
+ExampleCo wants to build a flexible solution. There are potential multiple employees and contractors who should be able to log timesheet entries, as well as batch processes which may upload timesheet entries from other, external systems.
+
+Hence the company has decided to develop a single Timesheets API which will be used to log time not only by this mobile app, but by all other apps as well. They want to put in place a security architecture that is flexible enough to accommodate this. ExampleCo wants to ensure that a large part of the code and business logic for the application can be shared across the different applications.
+
+It is required that only authorized users and applications are allowed access to the Timesheets API.
+
+<%= include('./_stepnav', {
+ next: ["1. Solution Overview", "/architecture-scenarios/mobile-api/part-1"]
+}) %>
diff --git a/ja-jp/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md b/ja-jp/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md
new file mode 100644
index 0000000000..13dabfaf1c
--- /dev/null
+++ b/ja-jp/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md
@@ -0,0 +1,1418 @@
+---
+description: The Android implementation of the API for the Mobile + API architecture scenario
+toc: true
+topics:
+  - mobile-apps
+  - api-auth
+  - android
+  - architecture
+  - authorization-code
+  - pkce
+contentType: tutorial
+useCase:
+  - invoke-api
+  - secure-an-api
+  - enable-mobile-auth
+  - build-an-app
+---
+
+# Mobile + API: Android Implementation for the Mobile App
+
+This document is part of the [Mobile + API Architecture Scenario](/architecture-scenarios/application/mobile-api) and it explains how to implement the mobile application in Android. Please refer to the scenario for information on the implemented solution.
+
+## 1. Set Up the Application
+
+<%= include('../../_includes/_package', {
+  org: 'auth0-samples',
+  repo: 'auth0-pnp-exampleco-timesheets',
+  path: 'timesheets-mobile/android',
+  requirements: [
+    'Android Studio 2.3',
+    'Android SDK 25',
+    'Emulator - Nexus 5X - Android 6.0'
+  ]
+}) %>
+
+### Set the Dependencies
+
+For this implementation, we will use the following dependencies within the app’s `build.gradle` file:
+
+- [Auth0.Android](https://github.com/auth0/Auth0.Android): this package enables integration with Auth0 to authenticate users.
+- [OkHttp](http://square.github.io/okhttp/): this package provides an HTTP application to make requests to the Node.JS API.
+- [JWTDecode.Android](https://github.com/auth0/JWTDecode.Android): this package will assist with decoding JWTs.
+- AppCompat: this package lets us use the toolbar widget for navigation in our activities.
+
+```gradle
+dependencies {
+    compile 'com.squareup.okhttp:okhttp:2.7.5'
+    compile 'com.auth0.android:auth0:1.10.0'
+    compile 'com.auth0.android:jwtdecode:1.1.1'
+    compile 'com.android.support:appcompat-v7:25.3.1'
+    testCompile 'junit:junit:4.12'
+}
+```
+
+### Update the Manifest
+
+Open the application's `AndroidManifest.xml` and add the internet permission:
+
+```xml
+
+```
+
+We’ll also update the application details to utilize the Toolbar widget:
+
+```xml
+    
+    
+```
+
+### Set Configuration Values
+
+Set your Auth0 Client ID, Auth0 Domain, and API’s url in the `strings.xml` resource located in `/res/values/strings.xml`:
+
+```xml
+
+    ExampleCo Timesheets
+    Log in
+    ...
+    ...
+    http://10.0.2.2:8080/timesheets
+
+```
+
+### Create Package Structure
+
+For this implementation, create directories for activities, models, and utils in the application package.
+
+- `activities/`: this package will contain the `LoginActivity.java`, `TimeSheetActivity.java`, `FormActivity.java`, and `UserActivity.java`.
+- `models/`: this package will contain the `TimeSheet.java` and `User.java` data models.
+- `utils/`: this package will contain the `UserProfileManager.java`, `TimeSheetAdapter.java`, and `ImageTask.java`
+
+## 2. Authorize the User
+
+### Update the Manifest
+
+Open the app's `AndroidManifest.xml` and add the `LoginActivity`:
+
+```xml
+
+
+            
+                
+                
+            
+
+            
+                
+
+                
+                
+
+                
+            
+
+```
+
+### Create the Login Activity Layout
+
+Next create `login_activity.xml`, the layout for the `LoginActivity`:
+
+```xml
+
+
+
+    
+
+    
+```
+
+After copying the changes to your S3 bucket, attempt to remove a pet while logged in as a social user.
+
+##### Update the Home Controller Logic to Allow Social Users to Purchase Pets
+
+In `home.js`, modify the `buyPet` function to enable pet purchases:
+
+```js
+function buyPet(user, id) {
+    var apigClient = getSecureApiClient();
+
+    apigClient.petsPurchasePost({},{userName:user, petId:id})
+      .then(function(response) {
+        console.log(response);
+        $scope.pets = response.data;
+        $scope.$apply();
+      }).catch(function (response) {
+        alert('buy pets failed');
+        showError(response);
+    });
+}
+…
+```
+
+Copy the code to your S3 bucket, log out, and then log back in in as a social user by clicking on the Amazon icon in the Lock login dialog. You may need to click **SHOW ALL** if your previous login persists in the Lock pane.
+
+![Login using AWS](/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png)
+
+Note that, as an Amazon user, you can buy a pet, but not add or remove pets. However, if you log in with a user associated with a Database Connection, you are able to add and remove pets, but not buy pets.
+
+### Enforce Role Assignment with Auth0 Rules
+
+In some cases, you might determine the appropriate role using the Application (as shown here), but for security reasons (you might want to prevent the user from assuming a more privileged role than necessary), you might want to determine user privileges on the server-side.
+
+With Auth0, this is done via [rules](/rules), which are service logic statements you define that are then run during the Auth0 authentication process. For example, you could create rules to:
+
+* Eliminate the passing of role information from the browser to the Application;
+* Insert role information into the delegation request based on the authentication source.
+
+#### Enforce Role Assignment
+
+You will add a rule that will check to see if the role requested by the user is allowed, depending on its association with a Social or Database Connection.
+
+Go to the [Auth0 Management Dashboard](${manage_url}), and click on **Rules** in the left-hand menu.
+
+Click the **+ Create Rule** button near the top left of the screen.
+
+![Dashboard Rules Screen](/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png)
+
+At this point, you will be asked to pick a rule template. Select the one for **empty rule**.
+
+![Choose Rules Template](/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png)
+
+You will now edit the empty rule. First, name the rule *AWS Pets Rule* (or something similar). Then, populate the body of the rule with the following JavaScript code:
+
+```js
+function (user, context, callback) {
+  if(context.clientID === '${account.clientId}') {
+    var socialRoleInfo = {
+      role:"arn:aws:iam:::role/auth0-api-social-role",
+      principal: "arn:aws:iam::your account>:saml-provider/auth0"
+    };
+
+    var adminRoleInfo = {
+      role:"arn:aws:iam:::role/auth0-api-role",
+      principal: "arn:aws:iam:::saml-provider/auth0"
+    };
+
+    var requestRole = context.request.body.role;
+    var requestPrincipal = context.request.body.principal;
+    var allowedRole = null;
+
+    if(user.identities[0].isSocial === false) {
+      allowedRole = adminRoleInfo;
+    } else {
+      allowedRole = socialRoleInfo;
+    }
+
+    if((requestRole && requestRole !== allowedRole.role) ||
+       (requestPrincipal && requestPrincipal !== allowedRole.principal)) {
+        console.log('mismatch in requested role:',requestRole, ':', requestPrincipal);
+        console.log('overridding');
+    } else {
+      console.log('valid or no role requested for delegation');
+    }
+
+    context.addonConfiguration = context.addonConfiguration || {};
+    context.addonConfiguration.aws = context.addonConfiguration.aws || {};
+    context.addonConfiguration.aws.role = allowedRole.role;
+    context.addonConfiguration.aws.principal = allowedRole.principal;
+    callback(null, user, context);
+
+  } else {
+    callback(null, user, context);
+  }
+}
+```
+
+Be sure to adjust the above code with the correct values for your integration. The fields are:
+
+* `Princial` ARN:
+* `Role` ARN;
+* Client Secret
+
+**Save** your changes.
+
+#### Caveats
+
+* Rules run at a global scope for every authentication. You should only run the logic on authentication requests associated with a given application (which is why the script used asks for the *clientID*. Without this information, the logic runs for every authentication request associated with your Auth0 account.
+* Information is passed into the rule with the *context* and the *user*.
+* You can extend the objects passed in to the rule. In the code above, the rule checks the body of the request for the role information. The role is set into the context *addonConfiguration* of the allowed role, which always overrides settings in the request body.
+
+#### Debug Your Rule
+
+At this point, you are ready to debug your rule(s). Click **Try This Rule**, and you will be presented with a script that tries the rule's logic.
+
+![Try Rule Script](/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png)
+
+At the bottom of the screen, click **Try**.
+
+![Try Rule Button](/media/articles/integrations/aws-api-gateway/part-4/try-button.png)
+
+You will then be presented with the output of running your rule.
+
+![Output from Trying Rules](/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png)
+
+<%= include('./_stepnav', {
+ prev: ["3. Building the Application", "/integrations/aws-api-gateway/delegation/part-3"],
+ next: ["5. Using Identity Tokens", "/integrations/aws-api-gateway/delegation/part-5"]
+}) %>
diff --git a/ja-jp/articles/integrations/aws-api-gateway/delegation/part-5.md b/ja-jp/articles/integrations/aws-api-gateway/delegation/part-5.md
new file mode 100644
index 0000000000..0b8697e298
--- /dev/null
+++ b/ja-jp/articles/integrations/aws-api-gateway/delegation/part-5.md
@@ -0,0 +1,177 @@
+---
+title: Amazon API Gateway Tutorial - Flowing Identity
+description: Step 5 of Amazon API Gateway Tutorial
+topics:
+  - integrations
+  - aws
+  - api-gateway
+contentType: tutorial
+useCase:
+  - secure-an-api
+---
+# AWS API Gateway Tutorial
+
+<%= include('./_delegation-version-warning') %>
+
+## Step 5 - Use Identity Tokens to Flow Identity
+
+In this final step, you will:
+
+* Flow identity to the service by passing your OpenID JSON Web Token (JWT);
+* Validate the token;
+* Extract profile information to assign a buyer for a pet.
+
+## Use an Identity Token
+
+You can use your Lambda function to process and obtain information about the user. For example, during a purchasing transaction, you retrieved the username from the profile returned with the identity token. However, you can also choose to have the user's information embedded with the identity itself, which is a JSON Web Token (JWT).
+
+The advantages of using JWTs is that you can:
+
+1. Verify the authenticity of the JWT;
+2. Be sure that the calling user is authenticated (instead of relying on a plain-text parameter that could have been tampered with).
+
+In addition, you can use the JWT for authorization, which allows you to bypass the IAM integration with Amazon API Gateway. Please note, however, that using the API Gateway for authorization allows you to halt the API call prior to invocation of your Lambda function.
+
+![AWS Identity Flow](/media/articles/integrations/aws-api-gateway/identity-flow.png)
+
+### Add Information to the JWT
+
+There are several ways of adding a user's information to the JWT. The following example adds the user's email address to the JWT, but the concepts are same for other user datapoints.
+
+#### Use Rules
+
+One way to add a user's email address to the JWT is to use a [rule](/rules). This is a good approach if you want to make sure that this value is always available in the JWT for an authenticating user.
+
+In `login.js`, you can see this scope specified in the parameters passed to `auth.signin`:
+
+```js
+$scope.login = function() {
+    var params = {
+        authParams: {
+          scope: 'openid email'
+        }
+      };
+
+    auth.signin(params, function(profile, token) {
+      ...
+    }
+  }
+```
+
+While you can include the full profile of the user within the JWT, you will want to include only what is necessary since the JWT is typically passed with *every* request.
+
+## Validate the JWT Token
+
+Because the AWS Lambda console has access to a limited number of Node modules that can be used when you enter your Node.js code using the browser console, you'll need to include additional modules and upload the Lambda function as a package to process the identity token.
+
+::: note
+For additional details, see [Creating Deployment Packages using Node.js](http://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-deployment-pkg.html) and [Uploading Deployment Packages and Testing](http://docs.aws.amazon.com/lambda/latest/dg/walkthrough-s3-events-adminuser-create-test-function-upload-zip-test.html).
+:::
+
+The following seed project contains the code you'll need for your updated AWS Lambda function.
+
+<%= include('../../../_includes/_package', {
+  org: 'auth0',
+  repo: 'auth0-aws',
+  path: 'examples/api-gateway/lambda'
+}) %>
+
+You'll see two custom JavaScript files within the seed project:
+
+* `index.js`: contains your main code;
+* `auth0-variables`: contains the code you need to update.
+
+In addition to the custom files, there is a standard Node.js `package.json` file.
+
+The code adds functionality to extract information from and validate the JWT. By default, Auth0 uses a symmetric key for signing the JWT, though you may opt to use asymmetric keys (if you need to allow third-party validation of your token, you should use an asymmetric key and share only your public key).
+
+>For more information about token verification, see [Identity Protocols Supported by Auth0](/protocols).
+
+Update `auth0-variables.js` with your secret key, which can be found on the *Settings* tab of your Application in the Auth0 Dashboard:
+
+```js
+var env={};
+env.AUTH0_SECRET='ADD-YOUR-SECRET';
+module.exports = env;
+```
+
+Run **npm install** from the directory where your files are, zip up the contents (`index.js` must be at the root of the zip), and upload it for use by the `PurchasePet` Lambda function. If you test this, you should see an authorization failure, since the JWT is not in the message body.
+
+Take a look at the logic in `index.js`. You will see logic around line 60 that validates the token and extracts the decoded information that contains the identity information used for the purchase logic:
+
+```js
+ if(event.authToken) {
+     jwt.verify(event.authToken, secret, function(err, decoded) {
+         if(err) {
+           console.log('failed jwt verify: ', err, 'auth: ', event.authToken);
+           context.done('authorization failure', null);
+         } else if(!decoded.email)
+         {
+           console.log('err, email missing in jwt', 'jwt: ', decoded);
+           context.done('authorization failure', null);
+         } else {
+           userEmail = decoded.email;
+           console.log('authorized, petId', petId, 'userEmail:', userEmail);
+           dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, readcb);
+         }
+     });
+  } else {
+     console.log('invalid authorization token', event.authToken);
+     context.done('authorization failure', null);
+  }
+    ...
+```
+
+### Extract Profile Information to Assign a Buyer
+
+The final step is to pass the JWT to the method used by the browser client.
+
+The standard method comes with an `Authorization` header as a *bearer* token, and you can use this method by turning off IAM authorization and relying solely on the OpenID Token for authorization (you will also need to map the Authorization header into the event data passed to the AWS Lambda function).
+
+If, however, you are using IAM, then the AWS API Gateway uses the `Authorization` header to contain the signature of the message, and you will break the authentication by inserting the JWT into this header. To do this, you can either:
+
+* Add a custom header for the JWT;
+* Put the custom header into the body of the message.
+
+If you choose to use a custom header, you'll also need to do some mapping for the *Integration Request* of the *POST* method for `pets/purchase`.
+
+To keep the validation process simple, pass the JWT in the body of the post to the AWS Lambda function. To do this, update the `buyPet` method in `home.js` by removing the `userName` from the body, and adding `authToken` as follows:
+
+```js
+function buyPet(user, id) {
+    var apigClient = getSecureApiClient();
+    var body = {
+      petId:id,
+      authToken: store.get('token')
+    };
+
+    apigClient.petsPurchasePost({}, body)
+      .then(function(response) {
+        console.log(response);
+        $scope.pets = response.data;
+        $scope.$apply();
+      }).catch(function (response) {
+        alert('buy pets failed');
+        showError(response);
+    });
+}
+```
+
+Upload your code to your S3 bucket and try to purchase a pet. You will see the email of the purchaser in the resulting message.
+
+If you have any errors, double check that you have properly set your secret key. One useful tool for checking issues with your token decoding is [jwt.io](http://jwt.io/).
+
+## Summary
+
+In this tutorial, you have:
+
+* Created an API using AWS API Gateway that includes methods using AWS Lamdba functions;
+* Secured access to your API using IAM roles;
+* Integrated a SAML identity provider with IAM to tie access to the API to your user base;
+* Provided different levels of access based on whether a user authenticated from the Database or Social Connection;
+* Used an Auth0 rule to enforce role assignment;
+* Used a JWT to provide further authorization context and pass identity information into the appropriate Lambda function.
+
+<%= include('./_stepnav', {
+ prev: ["4. Using Multiple Roles", "/integrations/aws-api-gateway/delegation/part-4"]
+}) %>
diff --git a/ja-jp/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md b/ja-jp/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md
new file mode 100644
index 0000000000..09bdb2005f
--- /dev/null
+++ b/ja-jp/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md
@@ -0,0 +1,59 @@
+---
+title: Amazon API Gateway Tutorial - Secure AWS API Gateway Using Cognito
+description: How to secure the API Gateway Tutorial using Cognito instead of IAM roles and policies.
+topics:
+  - integrations
+  - aws
+  - api-gateway
+  - cognito
+contentType: tutorial
+useCase:
+  - secure-an-api
+---
+
+# Secure AWS API Gateway Using Cognito
+
+Instead of using IAM roles and policies to secure your API, you can do so using user pools in Amazon Cognito.
+
+::: note
+Please [create the appropriate Amazon Cognito User Pools](http://docs.aws.amazon.com/cognito/latest/developerguide/setting-up-cognito-user-identity-pools.html) prior to beginning this tutorial.
+:::
+
+## Integrate the Cognito User Pool with the API Gateway API
+
+Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway). Using the left-hand navigation bar, select the **SecurePets** API.
+
+Then, select **Authorizers** for the **SecurePets** API.
+
+![API nav area to select authorizers](/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png)
+
+On the *Authorizers* column near the center of the screen, choose **Create** and indicate that you are creating a **Cognito User Pool Authorizer**.
+
+![API config page for authorizers](/media/articles/integrations/aws-api-gateway/config-authorizer.png)
+
+To configure your authorizer:
+
+1. Choose the **Cognito region** in which you created your User Pool.
+2. Customize the **Authorizer name** field, if desired (it will be automatically populated with the name of the chosen User Pool, so you can opt to leave it as is)
+3. Customize the **Identity token source** field. By default, this field is set to `method.request.header.Authorization`, which sets the name of the incoming request header containing the API caller's identity token to `Authorization`.
+4. If desired, add a regular expression to the **App client ID regex** field to validate client IDs associated with the User Pool.
+
+When you've finished configuring your authorizer, click **Create** to integrate the User Pool with your API.
+
+## Enable the User Pool Authorizer on Methods
+
+For each method that you want the User Pool to act as an authorizer, you must enable the User Pool to do so for that particular method.
+
+To enable the User Pool authorizer on the `GET` method:
+
+1. After selecting the *SecurePets* API, select the `GET` method listed under `/pets`.
+
+  ![enabling authorizer for API method](/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png)
+
+2. Click on **Method Request**.
+3. Under *Authorization Settings*, click on the **edit icon** next to the *Authorization* field.
+4. Choose the appropriate Cognito User Pool authorizer from the list. Click the **checkmark icon** to save your selection.
+
+  ![selecting authorizer for a given API method](/media/articles/integrations/aws-api-gateway/set-authorizer.png)
+
+Repeat this process for any additional methods for which you want the Cognito User Pool to act as an authorizer (`GET` and `PURCHASE` for `/pets`, as well as `POST` for `/purchase`).
diff --git a/ja-jp/articles/integrations/aws-api-gateway/index.yml b/ja-jp/articles/integrations/aws-api-gateway/index.yml
new file mode 100644
index 0000000000..0ed4f10449
--- /dev/null
+++ b/ja-jp/articles/integrations/aws-api-gateway/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: integrations/aws-api-gateway
+  current: custom-authorizers
+  versions:
+    - custom-authorizers
+    - delegation
+  defaultArticles:
+    custom-authorizers: index
+    delegation: index
diff --git a/ja-jp/articles/integrations/aws/aws-api-setup.md b/ja-jp/articles/integrations/aws/aws-api-setup.md
new file mode 100644
index 0000000000..4612c92ce4
--- /dev/null
+++ b/ja-jp/articles/integrations/aws/aws-api-setup.md
@@ -0,0 +1,130 @@
+---
+description: How to Set Up AWS for Delegated Authentication
+url: /aws-api-setup
+toc: true
+topics:
+  - integrations
+  - aws
+contentType: how-to
+useCase: secure-an-api
+---
+# How to Set Up AWS for Delegated Authentication
+
+This doc will walk you through setting up AWS for delegated authentication. You'll need to perform these steps any time you want to use Auth0 with AWS. Note that this tutorial does not walk you through a full integration. See the [Configure Single Sign-on (SSO) with the AWS Console](/integrations/aws/sso) or [API Gateway](/integrations/aws-api-gateway) tutorials for complete examples.
+
+## Step 1: Create a SAML Provider in AWS
+
+Log in to AWS, and navigate to the [IAM console](https://console.aws.amazon.com/iam). Using the left-hand navigation menu, select **Identity Providers**. Click **Create Provider**. 
+
+![](/media/articles/integrations/aws/create-provider.png)
+
+Set the following parameters:
+
+| Parameter | Description and Sample Value |
+| - | - |
+| Provider Type | The type of provider. Set as `SAML` |
+| Provider Name | A descriptive name for the provider, such as `auth0SamlProvider` |
+| Metadata Document | Upload the file containing the Auth0 metadata, found in **Dashboard > Applications > Application Settings > Advanced Settings > Endpoints > SAML Metadata URL** |
+
+![](/media/articles/integrations/aws/aws-configure-provider.png)
+
+Click **Next Step**. Verify your settings and click **Create** if everything is correct.
+
+![](/media/articles/integrations/aws/create-provider-confirm.png)
+
+## Step 2: Create a Role for Your SAML Provider
+
+To use the provider, you must create an IAM role using the provider in the role's trust policy. 
+
+In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home#/roles). Click **Create role**.
+
+![](/media/articles/tutorials/aws/roles1.png)
+
+You'll be redirected to the **Trust** page. Indicate **Saml 2.0 federation** under **Select type of trusted entity**. 
+
+![](/media/articles/tutorials/aws/roles3.png)
+
+Provide the following values:
+
+| Parameter | Value |
+| - | - |
+| SAML Provider | The name for your new role |
+| Attribute | `SAML:iss` |
+| Value | `urn:${account.namespace}` |
+
+![](/media/articles/tutorials/aws/roles4.png)
+
+Click **Next: Permissions** to proceed.
+
+You will need to attach permissions policies to your new role. You'll attach a custom policy. To create one, click **Create Policy**.
+
+![](/media/articles/tutorials/aws/roles5.png)
+
+In the **Create policy** editor that launches, switch over to the **JSON** tab. 
+
+![](/media/articles/tutorials/aws/roles6.png)
+
+Provide a custom policy. 
+
+```text
+{
+  "Version": "2012-10-17",
+  "Statement": [{
+      "Effect": "Allow",
+      "Action": [
+        "*"
+      ],
+      "Resource": [
+      "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>",
+      "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>/*"]
+  }]
+}
+```
+
+This defines the permissions that users granted this role will have with AWS. Click **Review policy**.
+
+![](/media/articles/tutorials/aws/roles7.png)
+
+Review the policy that you've created. Be sure to provide a **Name** for your policy and (optionally) a **Description**.
+
+Click **Create policy** when done.
+
+![](/media/articles/tutorials/aws/roles8.png)
+
+If successful, you'll see the following message confirming the creation of your new policy.
+
+![](/media/articles/tutorials/aws/roles9.png)
+
+Returning to the role creation wizard (you should be on step **2 - Permissions**), find the new policy you just create and click its checkbox to attach the policy to your role. We recommend using the **Customer managed** filter to find your policy.
+
+Click **Next: Review** to proceed.
+
+![](/media/articles/tutorials/aws/roles11.png)
+
+Review the information about your role, provide a **Role name** and (optionally) a **Role description**. You'll see the policy you attached as well. If everything looks correct, click **Create role** to proceed.
+
+![](/media/articles/tutorials/aws/roles12.png)
+
+Once created, you can find your roles located on the primary **Roles** page.
+
+![](/media/articles/tutorials/aws/roles13.png)
+
+## Copy the ARN Values
+
+The following instructions will show you where you can find the Provider and Role ARN values.
+
+### Provider ARN
+
+In the IAM console, navigate to [Identity providers](https://console.aws.amazon.com/iam/home#/providers). Select the role in which you're interested to open up its summary page. Copy the **Provider ARN** value, which is listed first under **Summary**.
+
+![](/media/articles/tutorials/aws/provider-summary.png)
+
+### Role ARN
+
+In the IAM console, navigate to [Roles](https://console.aws.amazon.com/iam/home#/roles). Select the role in which you're interested to open up its summary page. Copy the **Role ARN** value, which is listed first under **Summary**.
+
+![](/media/articles/tutorials/aws/role-summary2.png)
+
+### Next Steps
+
+* [AWS Services Supported by IAM](http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html).
diff --git a/ja-jp/articles/integrations/aws/index.md b/ja-jp/articles/integrations/aws/index.md
new file mode 100644
index 0000000000..e61b193cd1
--- /dev/null
+++ b/ja-jp/articles/integrations/aws/index.md
@@ -0,0 +1,41 @@
+---
+classes: topic-page
+title: Amazon Web Services (AWS)
+url: /integrations/aws
+topics:
+  - integrations
+  - aws
+contentType: index
+useCase:
+  - secure-an-api
+  - integrate-third-party-apps
+---
+
+
    
+  
    
+  
    Integrate Auth0 with Amazon Web Services (AWS)
    
+  
    
+    Auth0 supports integration with AWS' Identity and Access Management (IAM) service.
+  
    
+
    
+
+
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/aws/session-tags.md b/ja-jp/articles/integrations/aws/session-tags.md
new file mode 100644
index 0000000000..d147362eae
--- /dev/null
+++ b/ja-jp/articles/integrations/aws/session-tags.md
@@ -0,0 +1,152 @@
+---
+title: Use AWS Session Tags with AWS APIs and Resources
+description: Learn how to use AWS Session Tags to implement role-based access control (RBAC) for AWS APIs and Resources.
+toc: true
+topics:
+  - integrations
+  - aws
+  - session-tags
+  - rbac
+contentType: how-to
+useCase:
+  - secure-an-api
+  - integrate-third-party-apps
+  - integrate-saas-sso
+---
+# Use AWS Session Tags with AWS APIs and Resources
+
+With AWS Session Tags, you can tag resources and assign users key/value pairs, which allows you to implement role-based access control (RBAC) for AWS APIs and Resources.
+
+In the example included in this guide, we will tag our AWS resources with AWS Session Tags, then create a policy for an AWS IAM role that will allow users with this role and the appropriate tags to perform specific actions on our AWS resources. We will then create a rule in Auth0 that will attach our AWS IAM role and appropriate AWS Session Tags to an Auth0 user and pass them through SAML assertions in the token. This example builds on the example provided in our [Configure Single-Sign-on (SSO) with the AWS Console](/integrations/aws/sso) guide.
+
+## Prerequisites
+
+::: panel Amazon Web Services (AWS) Account
+Before proceeding, you will need a valid [Amazon Web Services (AWS) account](https://portal.aws.amazon.com/billing/signup#/start) for which you are an administrator.
+:::
+
+**Before beginning this guide:**
+
+* [Configure Single Sign-on (SSO) with the AWS Console](/integrations/aws/sso)
+* [Set up some AWS VM Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance). For the example in this guide, we use three separate instances.
+
+## Steps
+
+To use AWS Session Tags with AWS APIs and Resources, you must:
+
+1. [Tag AWS instances](#tag-aws-instances)
+2. [Create a specialized AWS IAM role](#create-a-specialized-AWS-IAM-role)
+3. [Create an Auth0 rule](#create-an-auth0-rule)
+4. [Test your setup](#test-your-setup)
+
+### Tag AWS instances
+
+First, you'll need to add tags to your AWS resources. To learn how to do so, follow instructions in [Amazon Elastic Compute Cloud User Guide for Linux Instances: Adding and Deleting Tags on an Individual Resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
+
+For the example in this guide, you should have created three instances. Add the following tags:
+
+| Instance | Tags |
+| -------- | ---- |
+| 1        | Key: `CostCenter`, Value: `marketing`.
    Key: `Project`, Value: `website`. |
+| 2        | Key: `CostCenter`, Value: `engineering`.
    Key: `Project`, Value: `management_dashboard`. |
+| 3        | Key: `CostCenter`, Value: `marketing`.
    Key: `Project`, Value: `community_site`. |
+
+### Create a specialized AWS IAM role
+
+Now, create an IAM role using the AWS SAML identity provider you set up during the [prerequisites for this guide](#prerequisites). 
+
+To learn how to set up an IAM user role with AWS, follow [AWS Identity and Access Management User Guide: Creating a Role for SAML 2.0 Federation (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html).
+
+While setting up your role, make sure you use the following parameters:
+
+| Parameter | Description and Sample Value |
+| --------- | ---------------------------- |
+| SAML Provider | Name of the identity provider you created in the prerequisites, such as `auth0SamlProvider`. Select **Allow programmatic and AWS Management Console access**. |
+
+When asked to **Attach permissions policies**, create a policy with the following JSON and name it `VirtualMachineAccessByCostCenter`.
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": [
+                "ec2:DescribeInstances"
+            ],
+            "Resource": "*"
+        },
+        {
+            "Effect": "Allow",
+            "Action": [
+                "ec2:StartInstances",
+                "ec2:StopInstances"
+            ],
+            "Resource": "*",
+            "Condition": {
+                "StringEquals": {
+                    "ec2:ResourceTag/CostCenter": "<%= "${aws:PrincipalTag/CostCenter}" %>"
+                }
+            }
+        }
+    ]
+}
+```
+
+Once the policy has been created, refresh the policy list for the role, then filter and select the new policy.
+
+When reviewing your settings, make sure you use the following parameters:
+
+| Parameter | Description | 
+| --------- | ----------- |
+| Role name | Descriptive name for your role, such as `AccessByCostCenter`. |
+| Role description | Description of the purpose for which your role is used. |
+
+### Create an Auth0 rule
+
+To map the AWS role and tags to a user, you'll need to create a [rule](/rules) in Auth0. These values will then be passed through the SAML assertions in the token. 
+
+For the example in this guide, [create the following rule](/dashboard/guides/rules/create-rules): 
+
+::: note
+Notice that you'll need to replace the `awsAccount` variable value with your own account number.
+:::
+
+```js
+function(user, context, callback) {
+  var awsAccount = '013823792818';
+  var rolePrefix = `arn:aws:iam::` + awsAccount; 
+  var samlIdP = rolePrefix + `:saml-provider/auth0SamlProvider`;
+
+  user.awsRole = rolePrefix + `:role/AccessByCostCenter,` + samlIdP;
+  user.awsRoleSession = user.email;
+  user.awsTagKeys = ['CostCenter', 'Project'];
+  user.CostCenter = 'marketing';
+  user.Project = 'website';
+
+  context.samlConfiguration.mappings = {
+    'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',
+    'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession',
+    'https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter': 'CostCenter',
+    'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project': 'Project'
+  };
+
+  callback(null, user, context);
+}
+```
+
+### Test your setup
+
+You should now be able to log in to the AWS Console using an Auth0 user and test your implementation. 
+
+To log in, you will need the SSO login for the AWS Console. To find it:
+
+1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view.
+
+2. Click **Add-ons**, then the **SAML2 Web App** add-on.
+
+3. Click the **Usage** tab, and locate **Identity Provider Login URL**. Navigate to the indicated URL.
+
+Once you have signed in, from **EC2**, select **Instances**. Click one of the instances tagged with a `CostCenter` of `marketing`, and click **Actions** > **Instance State** > **Stop**. Notice that the action completes successfully.
+
+Next, click the instance tagged with a `CostCenter` of `engineering`, and click **Actions** > **Instance State** > **Stop**. Notice that the action fails with an error.
diff --git a/ja-jp/articles/integrations/aws/sso.md b/ja-jp/articles/integrations/aws/sso.md
new file mode 100644
index 0000000000..cd4f6d2506
--- /dev/null
+++ b/ja-jp/articles/integrations/aws/sso.md
@@ -0,0 +1,211 @@
+---
+description: Learn how to use Single Sign-on (SSO) with AWS using the SAML2 Web App addon.
+toc: true
+topics:
+  - integrations
+  - aws
+  - sso
+contentType: how-to
+useCase:
+  - secure-an-api
+  - integrate-third-party-apps
+  - integrate-saas-sso
+---
+
+# Configure Single Sign-On with the AWS Console
+
+By integrating Auth0 with AWS, you'll allow your users to log in to AWS using any supported [identity provider](/identityproviders). 
+
+## Configure external Identity Provider in AWS
+
+Set up an external identity provider in AWS using AWS's [Connect to your External Identity Provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) doc--with one slight change. Rather than downloading the AWS metadata file, click **Show Individual Metadata Values**, and copy the **AWS SSO issuer URL** and **AWS SSO ACS URL**. You will use these in the next section.
+
+Leave this page open in your browser, as you'll need to complete configuration in a future section.
+
+## Configure Auth0
+
+1. Log in to the [Auth0 Dashboard](${manage_url}/#/applications), and create a new [Application](/application) (you can also use an existing Application if you'd like). On the **Addons** tab, enable the **SAML2 Web App** addon.
+
+    ![Applications](/media/articles/dashboard/guides/app-list.png)
+
+2. When the configuration pop-up appears, on the **Settings** tab, populate **Application Callback URL** with `https://signin.aws.amazon.com/saml`.
+
+  ![SAML2 Web App Settings](/media/articles/integrations/aws/configure.png)
+
+Then paste the following SAML configuration code into **Settings**. Be sure to replace the AWS_SSO_ISSUER_URL and AWS_SSO_ACS_URL placeholders with the values you copied from AWS in the previous section.
+
+```js
+{
+  "audience": "AWS_SSO_ISSUER_URL",
+  "destination": "AWS_SSO_ACS_URL",
+  "mappings": {
+    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+  },
+  "createUpnClaim": false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities": false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+3. Scroll to the bottom, and click **Enable**.
+
+4. Click over to the **Usage** tab. You'll need to complete your AWS configuration of Auth0 as the external identity provider (IdP) in the next section, which requires you to provide the appropriate metadata to AWS. To download a file containing this information, click **Identity Provider Metadata**.
+
+  ![SAML2 Web App Usage](/media/articles/integrations/aws/idp-download.png)
+
+## Complete external Identity Provider configuration in AWS
+
+Return to the AWS SSO page you left open during the first section, and upload the metadata file you downloaded and saved in the previous section. Review and Confirm that you are changing the identity source.
+
+## Create an AWS IAM Role
+
+To use the provider, you must create an IAM role using the provider in the role's trust policy.  
+
+1. In the sidebar, under **Access Management**, navigate to **[Roles](https://console.aws.amazon.com/iam/home#/roles)**. Click **Create Role**.
+
+2. On the next page, you will be asked to select the type of trusted entity. Select **SAML 2.0 Federation**. 
+
+3. When prompted, set the provider you created above as the **SAML provider**. Select **Allow programmatic and AWS Management Console access**. Click **Next** to proceed.
+
+4. On the **Attach Permission Policies** page, select the appropriate policies to attach to the role. These define the permissions that users granted this role will have with AWS. For example, to grant your users read-only access to IAM, filter for and select the `IAMReadOnlyAccess` policy. Once you are done, click **Next Step**.
+
+5. The third **Create Role** screen is **Add Tags**. You can use tags to organize the roles you create if you will be creating a significant number of them.
+
+6. On the **Review** page, set the **Role Name** and review your settings. Provide values for the following parameters:
+
+  | Parameter | Definition | 
+  | - | - |
+  | Role name | A descriptive name for your role |
+  | Role description | A description of what your role is used for |
+
+7. Review the **Trusted entities** and **Policies** information, then click **Create Role**. At this point, you'll have created the necessary role to associate with your provider.
+
+## Map the AWS Role to a User
+
+::: note
+For an example of defining a server-side rule that assigns a role in an advanced use case, see the [Amazon API Gateway tutorial](/integrations/aws-api-gateway).
+:::
+
+The **AWS roles** specified will be associated with an **IAM policy** that enforces the type of access allowed to a resource, including the AWS Consoles. To learn more about roles and policies, see [Creating IAM Roles](http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-creatingrole.html).
+
+To map an AWS role to a user, you'll need to create a [rule](/rules):
+
+```js
+function (user, context, callback) {
+
+  user.awsRole = 'arn:aws:iam::951887872838:role/TestSAML,arn:aws:iam::951887872838:saml-provider/MyAuth0';
+  user.awsRoleSession = user.name;
+
+  context.samlConfiguration.mappings = {
+    'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',
+    'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession'
+  };
+
+  callback(null, user, context);
+
+}
+```
+
+In the code snippet above, `user.awsRole` identifies the AWS role and the IdP. The AWS role identifier comes before the comma, and the IdP identifier comes after the comma.
+
+Your rule can obtain these two values in multiple ways. You can get these values from the IAM Console by selecting the items you created in AWS in the previous steps from the left sidebar. Both the Identity Provider and the Role you created have an ARN available to copy if you select them in the Console.
+
+In the example above, both of these values are hard-coded into the rule. Alternatively, you might also store these values in the [user profile](/users/concepts/overview-user-profile) or derive them using other attributes. For example, if you're using Active Directory, you can map properties associated with users, such as group to the appropriate AWS role:
+
+```js
+var awsRoles = {
+  'DomainUser': 'arn:aws:iam::951887872838:role/TestSAML,arn:aws:iam::95123456838:saml-provider/MyAuth0',
+  'DomainAdmins': 'arn:aws:iam::957483571234:role/SysAdmins,arn:aws:iam::95123456838:saml-provider/MyAuth0'
+};
+user.awsRole = awsRoles[user.group];
+user.awsRoleSession = user.email;
+
+context.samlConfiguration.mappings = {
+  'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',
+  'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession',
+};
+```
+
+### Map Multiple Roles
+
+You can also assign an array to the role mapping (so you'd have `awsRoles = [ role1, role2 ]` instead of `awsRoles: role1`)
+
+For example, let's say that you have Active Directory Groups with the following structure:
+
+```text
+ var user = {
+   app_metadata: {
+     ad_groups: {
+       "admins": "some info not aws related",
+       "aws_dev_Admin": "arn:aws:iam::123456789111:role/Admin,arn:aws:iam::123456789111:saml-provider / Auth0",
+       "aws_prod_ReadOnly": "arn:aws:iam::123456789999:role/ReadOnly,arn:aws:iam::123456789999:saml-provider / Auth0"
+     }
+   }
+ };
+```
+
+Your rule might therefore looking something like this:
+
+```js
+function (user, context, callback) {
+
+  var userGroups = user.app_metadata.ad_groups;
+
+  function awsFilter(group) {
+    return group.startsWith('aws_');
+  }
+
+  function mapGroupToRole(awsGroup) {
+    return userGroups[awsGroup];
+  }
+
+  user.awsRole = Object.keys(userGroups).filter(awsFilter).map(mapGroupToRole);
+  user.awsRoleSession = 'myawsuser'; // unique per user http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
+
+  context.samlConfiguration.mappings = {
+    'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',
+    'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession'
+  };
+
+  callback(null, user, context);
+
+}
+```
+
+## Configure Session Expiration
+
+If you want to extend the amount of time allowed to elapse before the AWS session expires (which is, by default, **3600 seconds**), you can do so using a custom [rule](/rules). Your rule sets the [**SessionDuration** attribute](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html) that changes the duration of the session.
+
+```js
+function (user, context, callback) {
+    if(context.clientID !== 'YOUR_CLIENT_ID_HERE'){
+      return callback(null, user, context);
+    }
+
+  user.awsRole = 'YOUR_ARN_HERE';
+  user.awsRoleSession = 'YOUR_ROLE_SESSION_HERE';
+  user.time = 1000; // time until expiration in seconds
+
+  context.samlConfiguration.mappings = {
+    'https://aws.amazon.com/SAML/Attributes/Role': 'YOUR-AWS-ROLE-NAME',
+    'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'YOUR-AWS-ROLE-SESSION-NAME',
+    'https://aws.amazon.com/SAML/Attributes/SessionDuration': 'time'   };
+
+  callback(null, user, context);
+}
+```
+
+## Test setup
+
+You are now set up for Single Sign-on (SSO) to AWS and can test your setup.
+
+1. Go to [Auth0 Dashboard > Application](${manage_url}/#/applications), and click the name of your application.
+2. Click the **Addons** tab, and select the **SAML2 Web App** add-on.
+3. Click the **Usage** tab.
+4. Navigate to the **Identity Provider Login URL**. You should be redirected to the Auth0 login page. If you successfully sign in, you'll be redirected again--this time to AWS.
diff --git a/ja-jp/articles/integrations/aws/tokens.md b/ja-jp/articles/integrations/aws/tokens.md
new file mode 100644
index 0000000000..cd984901df
--- /dev/null
+++ b/ja-jp/articles/integrations/aws/tokens.md
@@ -0,0 +1,204 @@
+---
+description: How to call AWS APIs and Resources Using Tokens
+toc: true
+topics:
+  - integrations
+  - aws
+  - tokens
+contentType: tutorial
+useCase:
+  - secure-an-api
+  - integrate-third-party-apps
+  - integrate-saas-sso
+---
+# Call AWS APIs and Resources Securely with Tokens
+
+<%= include('../../_includes/_uses-delegation') %>
+
+Auth0 integrates with the AWS Security Token Service (STS) to obtain an limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). These credentials can then be used to call the AWS API of any Auth0-supported [identity provider](/identityproviders).
+
+## Sample Configuration
+
+![](/media/articles/integrations/aws/aws-sts.png)
+
+1. The web app authenticates its users via Social providers, such as [Facebook](/connections/social/facebook), [LinkedIn](/connections/social/linkedin), or [Twitter](/connections/social/twitter), or corporate credentials, such as [Active Directory](/connections/social/active-directory), [Azure Active Directory](/connections/enterprise/azure-active-directory), or [Salesforce](connections/social/salesforce).
+2. The app calls Auth0's **delegation** endpoint to request a token for use with AWS.
+3. Auth0 obtains the token from AWS on behalf of the app.
+4. The app uses the newly-obtained token to connect with any AWS API.
+
+### Set Up Delegation
+
+::: note
+For detailed instructions on configuring delegation, see [How to Set Up AWS for Delegated Authentication](/aws-api-setup).
+:::
+
+Log in to Auth0's Management Dashboard, navigate to the [Applications](${manage_url}/#/applications) area, and find the [application](/applications) associated with your app. Click on **Settings** and click over to the **Addons** tab. Enable the **Amazon Web Services** addon.
+
+![](/media/articles/integrations/aws/aws-addon.png)
+
+::: panel Username Length with AWS
+Users of Auth0's database or a custom database should note that [AWS usernames must be between 2-64 characters in length](http://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html#troubleshoot_saml_invalid-rolesessionname). If you're using an Auth0 database, you can enforce this by setting your [username length settings](/connections/database/require-username#length) accordingly. If you're using a custom database, you can implement a similar policy within your application.
+:::
+
+#### IAM policy
+
+The following is a sample AWS IAM policy:
+
+```text
+{
+  "Version": "2012-10-17",
+  "Statement": [
+      {
+          "Action": [
+              "s3:DelObject",
+              "s3:GetObject",
+              "s3:PutObject",
+              "s3:PutObjectAcl"
+          ],
+          "Resource": [
+              "arn:aws:s3:::YOUR_BUCKET_NAME/<%= "${saml:sub}" %>/*"
+          ],
+          "Effect": "Allow"
+      }
+  ]
+}
+```
+
+The IAM policy is a dynamic policy that gives access to a folder in a bucket. The folder name is set based on an attribute of the digitally-signed SAML token that Auth0 exchanges with AWS on your behalf.
+
+The `<%= "${saml:sub}" %>` will be automatically mapped from the authenticated user (`sub` means `subject` and is equal to the user identifier), which allows the *original* identity of the user to be used throughout your app and AWS.
+
+### Get the AWS Token for an Authenticated User
+
+When a user successfully authenticates, Auth0 returns an ID Token, which is a [JWT](/tokens/concepts/jwts)). This ID Token is then used to request an Auth0 and AWS token using the delegation endpoint.
+
+Here is a sample request on the delegation endpoint:
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/delegation",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": [],
+	"queryString": [],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"${account.clientId}\", \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\", \"id_token\": \"YOUR_ID_TOKEN\", \"target\": \"${account.clientId}\", \"api_type\": \"aws\" }"
+	},
+	"headersSize": -1,
+	"bodySize": -1,
+	"comment": ""
+}
+```
+
+| Parameters | Description |
+| - | - |
+| `client_id` | The ID of your Auth0 application |
+| `grant_type` | Set as `urn:ietf:params:oauth:grant-type:jwt-bearer` |
+| `id_token` | The existing ID Token for the user requesting access |
+| `target` | The target application's ID |
+| `api_type` | The API the user wants to call (this must be `aws`) |
+
+AWS also requires the **role** and **principal** ARN values. You can set these values using [rules](/rules). The following is a sample rule that you can use. [Copy the provider  (for use as the principle ARN) and role ARN values](/aws-api-setup#copy-the-arn-values), and paste them into the sample where it currently says `[omitted]`:
+
+```js
+function (user, context, callback) {
+  if (context.clientID === 'CLIENT_ID' &&
+      context.protocol === 'delegation') {
+    // set AWS settings
+    context.addonConfiguration = context.addonConfiguration || {};
+    context.addonConfiguration.aws = context.addonConfiguration.aws || {};
+    context.addonConfiguration.aws.principal = 'arn:aws:iam::[omitted]:saml-provider/auth0-provider';
+    context.addonConfiguration.aws.role = 'arn:aws:iam::[omitted]:role/auth0-role';
+  }
+
+  callback(null, user, context);
+}
+```
+
+Optionally, you can set `context.addonConfiguration.aws.region` to target a specific AWS region. For example, `region: 'cn-north-1'` will direct requests to the Chinese north region. Temporary credentials from AWS GovCloud (US) and China (Beijing) can be used only in the region from which they originated.
+
+The `context.addonConfiguration.aws.mappings` variable allows you to specify parameters that are sent to AWS to assume a Role. By default, Auth0 will use these mappings:
+
+```text
+    mappings: {
+          'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'name',
+          'https://aws.amazon.com/SAML/Attributes/Role':                          'awsrole',
+          'https://aws.amazon.com/SAML/Attributes/RoleSessionName':               'rolesessionname'
+    }
+```
+
+[Other mappings are available in AWS](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html), so if you wanted to use the `eduPersonAffiliation` AWS Context Key, you can set this mapping in a rule as follows:
+
+```js
+function(user, context, callback){
+
+    context.addonConfiguration.aws.mappings: {
+          'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'name',
+          'https://aws.amazon.com/SAML/Attributes/Role':                          'awsrole',
+          'https://aws.amazon.com/SAML/Attributes/RoleSessionName':               'rolesessionname',
+          'urn:oid:1.3.6.1.4.1.5923.1.1.1.1':                                     'awsGroup'
+    };
+
+    callback(null,user,context);
+}
+```
+
+The example above assumes the `user` object contains an `awsGroup` property with the expected value.
+
+The result of calling the delegation endpoint will contain the AWS token in the `Credentials` field:
+
+```js
+{
+  "ResponseMetadata":{
+    "RequestId":"ec4cb90f-8a17-11e5-84bf-a9c4083f50c5"
+  },
+  "Credentials":{
+    "AccessKeyId":"ASIAIJGOICAGFNVWAENA",
+    "SecretAccessKey":"mRXhJySQHYZVg8...iCh+JeyBQ==",
+    "Expiration":"2015-11-13T16:05:05.000Z"
+  },
+  "AssumedRoleUser":{
+    "AssumedRoleId":"AROAID6UVEPILQXDCMMWK:johndoe",
+    "Arn":"arn:aws:sts::010616021751:assumed-role/access-to-s3-per-user/johndoe"
+  },
+  "Subject":"google-oauth2|113015401123457192604",
+  "SubjectType":"persistent",
+  "Issuer":"urn:matugit.auth0.com",
+  "Audience":"https://signin.aws.amazon.com/saml",
+  "NameQualifier":"z32keR+u/IrT0MrUVEfqYUGiqvE="
+}
+```
+
+:::panel Auth0 Libraries
+The [Auth0 application libraries](/libraries) simplify the process of calling these endpoints. See an example for client-side JavaScript at [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request). Please note that this example is for **version 7** of the `auth0js` library; delegation is *not* supported in version 8 of `auth0js`.
+
+Additionally, AWS requires two additional parameters: **role** and **principal**. To modify the `role` and `principal` strings, specify the appropriate ARN values where the sample currently says `[omitted]` via [Rules](${manage_url}/#/rules). If you do not have these values, please see [Copy the ARN Values](/aws-api-setup#copy-the-arn-values) section of the AWS setup doc.
+:::
+
+Here is an example of client-side code used to obtain the token:
+
+```html
+
+
+```
diff --git a/ja-jp/articles/integrations/azure-api-management/_stepnav.html b/ja-jp/articles/integrations/azure-api-management/_stepnav.html
new file mode 100644
index 0000000000..f679e60997
--- /dev/null
+++ b/ja-jp/articles/integrations/azure-api-management/_stepnav.html
@@ -0,0 +1,14 @@
+
    
+  <% if (typeof prev !== 'undefined') { %>
+  
    
+    
    Previous
    
+     ${prev[0]}
+  
    
+  <% } %>
+  <% if (typeof next !== 'undefined') { %>
+  
    
+    
    Next
    
+    ${next[0]} 
+  
    
+  <% } %>
+
    
diff --git a/ja-jp/articles/integrations/azure-api-management/configure-auth0.md b/ja-jp/articles/integrations/azure-api-management/configure-auth0.md
new file mode 100644
index 0000000000..d8eb7151d5
--- /dev/null
+++ b/ja-jp/articles/integrations/azure-api-management/configure-auth0.md
@@ -0,0 +1,89 @@
+---
+description: Configure Auth0 for use as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service
+toc: true
+topics:
+    - integrations
+    - azure
+    - api-management
+contentType: tutorial
+useCase:
+  - secure-an-api
+---
+# Configure Auth0
+
+To use Auth0 as an [OAuth 2.0 authorization server](/protocols/oauth2#oauth-roles), you'll need to execute the following setup steps:
+
+1. Create an Auth0 API and Machine to Machine Application.
+2. Create a Connection to store your users.
+3. Create a user so that you can test your integration when you've finished setting it up.
+
+## Step 1: Create an API and Machine to Machine Application
+
+An API is an entity that represents an external resource that's capable of accepting and responding to requests made by applications. You'll need to create an [Auth0 API](/apis) using the Management Dashboard to represent the API managed by Azure's API Management Service that you want secured by Auth0.
+
+You'll also need a [Machine to Machine Application](/applications), which represents your application and allows use of Auth0 for authentication. When you create an API, Auth0 automatically creates an associated Machine to Machine Application by default.
+
+To begin, you'll need to log into the Auth0 Management Dashboard. Go the [APIs](${manage_url}/#/apis) and click **Create API**.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/apis.png)
+
+Set the following parameters to create your new API:
+
+| Parameter | Description |
+| --------- | ----------- |
+| Name | A descriptive name for your API. In this example, we'll use `Basic Calculator` |
+| Identifier | A logical and unique identifier for your API. We recommend using a URL, but it doesn't have to be a publicly-available URL since Auth0 doesn't call your API. You cannot modify this value at a later point. We'll use `basic-calculator`. |
+| Signing Algorithm | The method used to sign the tokens issued by Auth0. Choose from `HS256` and `RS256` (we'll use the latter for this example). If you choose `RS256`, Auth0 signs your tokens with your private key. To learn more, see [Signing Algorithms](/tokens/concepts/signing-algorithms). |
+
+When complete, click **Create**.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/api-config.png)
+
+When your API is ready, you'll be shown the **Quick Start** page for the API. Switch over to the **Machine to Machine Applications** tab. You'll see that Auth0 has also created and enabled a [Machine to Machine Application](/applications) for use with your API.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/api-nic.png)
+
+## Step 2: Create a Connection
+
+
+::: note
+If you already have a set of users, you may [import them](/extensions/user-import-export) or create a [custom database connection](https://auth0.com/docs/connections/database/mysql).
+:::
+
+Go to the Management Dashboard. Navigate to [**Connections** > **Database Connections**](${manage_url}/#/connections/database), and click **Create DB Connection**.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/db-connections.png)
+
+The only thing you'll need to provide at this time is a descriptive **Name** for your connection. We suggest choosing a name that reflects the source of users (such as `Facebook` for a Connection that contains users using their Facebook credentials or `site-sign-ups` for a database connection where users sign up on your site).
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/new-db-connection-config.png)
+
+Click **Create** to proceed.
+
+### Enable the Connection for Your Application
+
+Once Auth0 has created your Connection, you'll be redirected to your Connection's **Settings** page. Switch over to the **Applications** tab, where you'll see a full list of all the Applications you have with this account. You'll need to enable the Connection for use with the Machine to Machine Application that you're using with your API.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/connection-application.png)
+
+## Step 3: Create a User
+
+Finally, we'll create a user that we use later on to test the integration.
+
+Go to the [Users section](${manage_url}/#/users) of the Management Dashboard. Click **Create User**.
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/user.png)
+
+Provide an **email** and **password** for your new user. Be sure to indicate that this user should use **BasicCalculator** in the **Connection** field.
+
+Set `Connection` to the connection you created earlier (which, if you're following along with our example, is `BasicCalculator`).
+
+![](/media/articles/integrations/azure-api-mgmt/auth0/create-user.png)
+
+Click **Save** to proceed.
+
+At this point, you've set up Auth0 for use as an OAuth 2.0 authorization server. You will now configure the Azure API Management Service and import an API for use with the service.
+
+<%= include('./_stepnav', {
+ prev: ["Integrate Azure API Management Service with Auth0", "/integrations/azure-api-management"], next: ["2. Configure Azure API Management", "/integrations/azure-api-management/configure-azure"]
+}) %>
diff --git a/ja-jp/articles/integrations/azure-api-management/configure-azure.md b/ja-jp/articles/integrations/azure-api-management/configure-azure.md
new file mode 100644
index 0000000000..fd8219189b
--- /dev/null
+++ b/ja-jp/articles/integrations/azure-api-management/configure-azure.md
@@ -0,0 +1,143 @@
+---
+description: Configure Azure to accept Auth0 for use as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service
+toc: true
+topics:
+    - integrations
+    - azure
+    - api-management
+contentType: tutorial
+useCase:
+  - secure-an-api
+---
+# Configure Azure
+
+::: warning
+To complete this tutorial you will need to have an account that grants you access to Microsoft's [Azure Portal](https://portal.azure.com).
+:::
+
+In this section, you'll:
+
+* Create an API management instance
+* Import the Basic Calculator API
+* Configure an OAuth 2.0 Server
+* Set Auth0 as the OAuth 2.0 Server handling authentication requests to the API
+* Test the Auth0-Azure API integration
+
+## Step 1: Create Your API Management Instance
+
+To create a new API management service, click **Create a resource** in the left-hand navigation bar. Once redirected, click **Web** > **API Management**.
+
+You'll be asked to provide the following configuration variables:
+
+| Parameter | Description |
+| --------- | ----------- |
+| Name | The name for your service (which will also be used to create the URL you need to access the service) |
+| Subscription | The Azure subscription plan with which you'll use with the service |
+| Resource group | The collection of [resources](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-portal) sharing a lifecycle, permissions, and policies. You can use an existing resource group or you can create a new one (you'll need to provide a name for the group if you create a new one) |
+| Location | Choose the location that services your API instance |
+| Organization name | The name of your organization |
+| Administrator email | The email address of the person who will be administering this instance |
+| Pricing tier | The pricing tier you want, which determines the number of calls you can make to your API, as well as the maximum amount of data transfer allowed. You must opt for the [Developer plan](https://azure.microsoft.com/en-us/pricing/details/api-management/) or higher; the Consumption plan does not offer sufficient functionality for this integration to work. |
+
+You can also choose to **Enable Application Insights**. If you do, select the **Application Insights instance** you would like to use.
+
+Click **Create** to begin provisioning your service.
+
+## Step 2: Import Your API
+
+For this tutorial, we will be importing and using the Calculator API provided by Microsoft. You can, however, create your own API instead of using the Calculator API.
+
+For detailed instructions on how to do so, see [Import and Publish Your First API](https://docs.microsoft.com/en-us/azure/api-management/import-and-publish#go-to-your-api-management-instance)
+
+When done, click **Create** to import your API. You'll be redirected to the summary page for your API when it's fully imported.
+
+## Step 3: Configure Your OAuth 2.0 Authorization Server
+
+To use Auth0 to secure your API, you'll need to register Auth0 as an OAuth 2.0 Authorization Server. You can do so using the Azure Publisher Portal.
+
+Find the **Security** area of your API Management service instance's near left navigation bar, and click **OAuth 2.0**.
+
+Click on **Add**. You'll see the **Add OAuth2 service** configuration screen that lets you provide details about your Auth0 tenant.
+
+For the purposes of this example, we'll use the **Authorization Code grant type**, but you're free to use whichever grant type is most appropriate for your use case. Azure currently supports the following grant types: [Authorization Code](/flows/concepts/auth-code), [Implicit](/flows/concepts/implicit), [Resource Owner Password](/api-auth/grant/password), [Client Credentials](/flows/concepts/client-credentials).
+
+Set the following parameters:
+
+| Parameter | Description |
+| --------- | ----------- |
+| Display name | A descriptive name for your authorization server, such as `Auth0` |
+| Id | The identifying name for this Azure resource -- this field should auto-populate based on the display name you provide |
+| Description | A description for your authorization server, such as `Auth0 API Authentication` |
+| Client registration page URL | The page where users can create or manage their accounts; for the purposes of this example, we'll use `https://placeholder.contoso.com` as the placeholder |
+| Authorization code grant types | The grant type used for authorization. Select `authorization code` |
+| Authorization endpoint URL | The URL Azure uses to make the authorization request. See the [Auth0 docs on generating the URL](/flows/guides/auth-code/call-api-auth-code#authorize-the-user) |
+| Authorization request method | The HTTP method used by Azure to make the authorization request. By default, this is `GET` |
+| Token endpoint URL | The endpoint used to exchange authorization grants for Access Tokens; Auth0's can be reached at `https://auth0user.auth0.com/oauth/token` |
+| Client authentication methods | Method used to authenticate the application; Auth0's is `BASIC` |
+| Access Token sending method | The location of the Access Token in the sending method (typically the **Authorization header**) |
+| Default scope | Specify a default scope (if necessary) |
+
+Because we're using the **authorization code** grant, we'll need to provide the **client ID** and **client secret** for the [Auth0 Application we previously registered](/integrations/azure-api-management/configure-auth0#step-1-create-an-api-and-machine-to-machine-application). You can find both values in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+Once you've provided both the client ID and client secret, you'll see an auto-generated **redirect URI**. Copy this URL, since you'll need to provide this URI in your Auth0 Application Settings page in the Allowed Callback URLs section.
+
+::: note
+If you're using the [resource owner password](/api-auth/grant/password) flow, you'll need to provide the **resource owner username** and **resource owner password** instead of the client ID and secret.
+:::
+
+When complete, click **Create** to persist your changes.
+
+### Set the Allowed Callback URL
+
+You'll need to provide the **redirect URI** that was auto-generated during the OAuth 2.0 authorization server setup process to Auth0. Log into the Management Dashboard, and navigate to **Applications**. Select your Application, and click **Settings**. Paste the URL into the **Allowed Callback URLs** field.
+
+![](/media/articles/integrations/azure-api-mgmt/azure/set-callback-url.png)
+
+Click **Save**.
+
+## Step 4: Authorize Auth0 for Use with Your API
+
+Before you can use Auth0 to secure your API, you'll need to set your API to use Auth0.
+
+In the near-left navigation column, click **APIs**. Select the Basic Calculator API; this redirects you to the **Design** tab.
+
+Click over to the **Settings** tab.
+
+Scroll to the **Security** section, and under **User Authorization**, select **OAuth 2.0**. In the **Authorization Server** field that appears, select the server you configured in the previous step.
+
+Click **Save**.
+
+## Step 5: Test Your Integration
+
+While logged in to the Azure Portal, open up your instance of the API Management Service. Click **Developer Console** to launch the developer-facing side of your APIs.
+
+Go to APIs > Basic Calculator (or the API you've created for this tutorial). This opens up to the page where you can make a `GET` call that allows you to add two integers.
+
+Click **Try It**. This will bring up the page where you can provide the parameters for your call.
+
+Scroll down to the **Authorization** section. Next to the **Auth0** field, select **Authorization Code**.
+
+At this point, you'll see the Auth0 login widget in a popup window (if you don't, disable your popup blocker). Provide the credentials for the Auth0 user you created earlier in the tutorial, and sign in.
+
+If you were able to successfully sign in, you'll see a message appear with the expiration date of the Access Token you need to call the API.
+
+Scroll to the bottom, and click **Send** to send your request. If successful, you'll see a message containing the `HTTP 200` response at the bottom of the page.
+
+## Configure a JWT validation policy for Access Tokens
+
+In the previous step, the user is prompted to sign in when they try to make a call from the Developer Console. The Developer Console attempts to obtain an Access Token on behalf of the user to be included in the API request. All Access Tokens will be passed to the API via the `Authorization` header.
+
+If you want to validate the Access Token included with each request, you can do so by using the [Validate JWT](https://docs.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT) policy. Please refer to Microsoft's documentation on [setting an API Management policy](https://docs.microsoft.com/en-us/azure/api-management/set-edit-policies).
+
+## Summary
+
+In this tutorial, you:
+
+1. Configured your Auth0 tenant to act as an OAuth 2.0 server.
+2. Set up an API Management Service in Azure.
+3. Imported an API that's managed by Azure's API Management Service.
+4. Secured your API using Auth0 and (optionally) verified the Access Token.
+
+<%= include('./_stepnav', {
+ prev: ["1. Configure Auth0", "/integrations/azure-api-management/configure-auth0"]
+}) %>
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/azure-api-management/index.md b/ja-jp/articles/integrations/azure-api-management/index.md
new file mode 100644
index 0000000000..f3419f00af
--- /dev/null
+++ b/ja-jp/articles/integrations/azure-api-management/index.md
@@ -0,0 +1,30 @@
+---
+description: Using Auth0 as an OAuth 2.0 server to authenticate users wanting access to an API managed by the Azure API Management service
+topics:
+    - integrations
+    - azure
+    - api-management
+contentType: tutorial
+useCase:
+  - secure-an-api
+---
+
+# Integrate Azure API Management Service with Auth0
+
+If you have an API that you want published and secured, you can do so using Azure API Management in conjunction with Auth0. 
+
+Azure's API Management Service allows you to create new APIs or import existing API definitions and publish them for use by the approved audiences. Auth0 makes authorizing users of your API (using OAuth 2.0 standards) easy.
+
+In this tutorial, we will show you how to [create a representation of your API in Auth0](/integrations/azure-api-management/configure-auth0), set up the [Azure API Management service, import an existing API, and secure it using Auth0](/integrations/azure-api-management/configure-azure). More specifically, we will:
+
+1. Set up Auth0 by creating an API and Machine to Machine Application, Connection, and User
+2. Create an API Management Service on the Azure Portal
+3. Import a Basic Calculator API (this sample API is provided by Microsoft)
+4. Set up Auth0 for use as an OAuth 2.0 Server in Azure
+5. Secure access to your Basic Calculator API using Auth0
+
+We will also test the integration. You'll see that, whenever a user attempts to make a call to the Basic Calculator API, they are asked to provide credentials to an Auth0-provided login screen. Only by providing valid credentials is the user allowed to make a call to the API.
+
+<%= include('./_stepnav', {
+ next: ["1. Configure Auth0", "/integrations/azure-api-management/configure-auth0"]
+}) %>
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/azure-tutorial.md b/ja-jp/articles/integrations/azure-tutorial.md
new file mode 100644
index 0000000000..e3f8078c28
--- /dev/null
+++ b/ja-jp/articles/integrations/azure-tutorial.md
@@ -0,0 +1,71 @@
+---
+description: How to use Auth0 with Microsoft Azure.
+url: /azure-tutorial
+topics:
+  - integrations
+  - microsoft
+  - azure
+contentType:
+- how-to
+- index
+useCase: integrate-saas-sso
+---
+# Using Auth0 with Microsoft Azure
+
+Auth0 is as simple to integrate in an application deployed on [Microsoft Azure](https://azure.microsoft.com) as it is for any other environment. To get started, please see:
+
+* [ASP.NET application](/quickstart/backend/aspnet-core-webapi-v1_1) 
    
+Simple non-intrusive integration with any version of ASP.NET.
+
+* [Node.js application](/quickstart/backend/nodejs) 
    
+Integration using [passport](http://passportjs.org/).
+
+---
+
+### Tip: change Auth0 configuration when deploying to Microsoft Azure
+
+You'll need to make some configuration changes when deploying to Microsoft Azure. Auth0 recommends creating one application per environment (e.g. Development, Test, Production). This is because each environment should have and use a different `Client Id` and `Client Secret`, as well as the appropriate `Callback URL`.
+
+For ASP.NET applications, we recommend utilizing [Web.config transformations](http://msdn.microsoft.com/en-us/library/dd465326.aspx) to make configuration changes targeted for each environment. Application settings that appear in the transformed `web.config` will depend on the build target name used at compilation and deployment.
+
+The following is an example of how you can compile and deploy your application. The example focuses on deploying to Production, but you can use it to create builds in your ASP.NET application targeting your other environments.
+
+
+This is the base configuration in `Web.config`:
+
+```xml
+
+
+
+```
+
+The following snippet, `Web.Release.config`, contains the necessary transformations. We want to utilize the `Release` build and are targeting Production.
+
+```xml
+
+  
+    
+    
+    
+  
+
+```
+
+If you need to refer to the `Client Id`, `Client Secret` or `Callback URL`, you can do so using the [`ConfigurationManager`](https://docs.microsoft.com/en-us/dotnet/api/system.configuration.configurationmanager?view=netframework-4.7.2) class. Below is an example of using the `ConfigurationManager` within an ASP.NET MVC Razor view.
+
+```html
+
+
+```
+
+Running  `web.config` transformations are helpful whether deploying to a [Microsoft Azure App Service](https://azure.microsoft.com/en-us/services/app-service/) or a [Microsoft Azure Cloud Service](https://azure.microsoft.com/en-us/services/cloud-services/).
+
+::: note
+Use the [Web.config Transformation Tester](http://webconfigtransformationtester.apphb.com/) to verify the results of any `web.config` transformations.
+:::
diff --git a/ja-jp/articles/integrations/configure-wsfed-application.md b/ja-jp/articles/integrations/configure-wsfed-application.md
new file mode 100644
index 0000000000..d6629e86c7
--- /dev/null
+++ b/ja-jp/articles/integrations/configure-wsfed-application.md
@@ -0,0 +1,25 @@
+---
+description: How to configure a WS-Fed application to use Auth0 as an identity provider.
+topics:
+  - integrations
+  - ws-fed
+contentType: how-to
+useCase: integrate-saas-sso
+---
+
+# How to configure a WS-Fed application
+
+If a WS-Fed application (Service Provider) is to use Auth0 as an Identity Provider, this is configured in one of two places.
+
+Some commonly used WS-Fed applications are pre-configured in Auth0 and available via `Single Sign-On Integrations`.
+
+If a WS-Fed application is not listed in `Single Sign-On Integrations`, the generic WS-Fed application configuration can be accessed via:
+
+1. In the Auth0 Dashboard, click on `Applications`, `+ CREATE APP`, enter a name and press Save.
+2. Then click on the `Addons` tab -> `WS-Fed Web App`.
+3. Enter the `Application Callback URL` - this is the your callback URL in the WS-Fed application to which the WS-Fed response will be posted.  It may also called the `ACS` or `Assertion Consumer Service URL` in some applications. 
+4. Enter the `Realm` - this is an identifier sent by the WS-Fed application and is used to identify the application in the response.
+
+::: note
+If you want to use your WS-Fed applications with the [custom domains](/custom-domains) feature and with Auth0 as the IDP, you must update your Service Provider with new Identity Provider metadata from Auth0. You can obtain the metadata reflecting the custom domain from: `https:///wsfed/FederationMetadata/2007-06/FederationMetadata.xml`.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/google-cloud-platform.md b/ja-jp/articles/integrations/google-cloud-platform.md
new file mode 100644
index 0000000000..5b8581ee99
--- /dev/null
+++ b/ja-jp/articles/integrations/google-cloud-platform.md
@@ -0,0 +1,217 @@
+---
+title: Securing Google Cloud Endpoints with Auth0
+description: How to secure a Google Cloud Endpoints API with Auth0.
+toc: true
+topics:
+  - integrations
+  - google-cloud
+contentType: how-to
+useCase: integrate-saas-sso
+---
+
+# Securing Google Cloud Endpoints with Auth0
+
+[Google Cloud Endpoints (GCE)](https://cloud.google.com/endpoints/) is an API management system providing features to help you create, maintain, and secure your APIs. GCE uses [OpenAPI](https://www.openapis.org/) to define your API's endpoints, input and output, errors, and security description.
+
+::: note
+For more information on the OpenAPI spec, see the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification) repository on GitHub.
+:::
+
+This tutorial will cover how to secure Google Cloud Endpoints with Auth0.
+
+## Prerequisites
+
+Before you begin you'll need a deployed GCE API. If you haven't already created an API, complete the [Cloud Endpoints Quickstart](https://cloud.google.com/endpoints/docs/quickstart-endpoints).
+
+The quickstart will walk you through creating a simple GCE API with a single endpoint, `/airportName`, that returns the name of an airport from its three-letter [IATA code](https://en.wikipedia.org/wiki/IATA_airport_code).
+
+```har
+{
+    "method": "GET",
+    "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName",
+    "headers": [],
+    "queryString" : [
+      {
+        "name": "iataCode",
+        "value": "SFO"
+      }
+    ]
+}
+```
+
+## Define the API in Auth0
+
+Open [Dashboard > APIs](${manage_url}/#/apis) and create a new API.
+
+![Create API](/media/articles/tutorials/gce-create-api.png)
+
+Make note of the **API Audience** identifier (`http://google_api` in the screenshot above) to use in the following step.
+
+## Update the API Configuration
+
+Next, we'll update the OpenAPI configuration file for the GCE API. For the sample API created during the quickstart this file is `openapi.yaml`.
+
+### Add Security Definitions
+
+Open the configuration file and add a new `securityDefinitions` section. In this section, add a new definition (`auth0_jwt`) with the following fields:
+
+Field | Description
+------|------------
+`authorizationUrl` | The authorization URL, should be set to `"https://${account.namespace}/authorize"`
+`flow` | The flow used by the OAuth2 security scheme. Valid values are `"implicit"`, `"password"`, `"application"` or `"accessCode"`.
+`type` | The type of the security scheme. Valid values are `"basic"`, `"apiKey"` or `"oauth2"`
+`x-google-issuer` | The issuer of a credential, should be set to `"https://${account.namespace}/"`
+`x-google-jwks_uri` | The URI of the public key set to validate the JSON Web Token (JWT) signature. Set this to `"https://${account.namespace}/.well-known/jwks.json"`
+`x-google-audiences` | The API's identifier, make sure this value matches what you defined on the Auth0 dashboard for the API.
+
+
+```yaml
+securityDefinitions:
+  auth0_jwt:
+    authorizationUrl: "https://${account.namespace}/authorize"
+    flow: "implicit"
+    type: "oauth2"
+    x-google-issuer: "https://${account.namespace}/"
+    x-google-jwks_uri: "https://${account.namespace}/.well-known/jwks.json"
+    x-google-audiences: "{YOUR_API_IDENTIFIER}"
+```
+
+### Update the Endpoint
+
+Now, update the endpoint by adding a `security` field with the `securityDefinition` we created in the previous step.
+
+```yaml
+paths:
+  "/airportName":
+    get:
+      description: "Get the airport name for a given IATA code."
+      operationId: "airportName"
+      parameters:
+        -
+          name: iataCode
+          in: query
+          required: true
+          type: string
+      responses:
+        200:
+          description: "Success."
+          schema:
+            type: string
+        400:
+          description: "The IATA code is invalid or missing."
+      security:
+       - auth0_jwt: []
+```
+
+In the above example, the `security` field tells the GCE proxy that our `/airportName` path expects to be secured with the `auth0-jwt` definition.
+
+After updating the OpenAPI configuration, it should look something like this:
+
+```yaml
+---
+swagger: "2.0"
+info:
+  title: "Airport Codes"
+  description: "Get the name of an airport from its three-letter IATA code."
+  version: "1.0.0"
+host: "YOUR_GCE_PROJECT.appspot.com"
+schemes:
+  - "https"
+paths:
+  "/airportName":
+    get:
+      description: "Get the airport name for a given IATA code."
+      operationId: "airportName"
+      parameters:
+        -
+          name: iataCode
+          in: query
+          required: true
+          type: string
+      responses:
+        200:
+          description: "Success."
+          schema:
+            type: string
+        400:
+          description: "The IATA code is invalid or missing."
+      security:
+       - auth0_jwt: []
+securityDefinitions:
+  auth0_jwt:
+    authorizationUrl: "https://${account.namespace}/authorize"
+    flow: "implicit"
+    type: "oauth2"
+    x-google-issuer: "https://${account.namespace}/"
+    x-google-jwks_uri: "https://${account.namespace}/.well-known/jwks.json"
+    x-google-audiences: "{YOUR_API_IDENTIFIER}"
+```
+
+### Redeploy the API
+
+Next, redeploy your GCE API to apply the configuration changes. If you followed along with the [Cloud Endpoints Quickstart](https://cloud.google.com/endpoints/docs/quickstart-endpoints) you can redeploy by entering the following in Google's Cloud Shell:
+
+```bash
+cd endpoints-quickstart/scripts
+./deploy_api.sh
+```
+
+## Test the API
+
+Once you've redeployed, call the API again with no security.
+
+```har
+{
+    "method": "GET",
+    "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName",
+    "headers": [],
+    "queryString" : [
+      {
+        "name": "iataCode",
+        "value": "SFO"
+      }
+    ]
+}
+```
+
+You'll get the following response:
+
+```json
+{
+ "code": 16,
+ "message": "JWT validation failed: Missing or invalid credentials",
+ "details": [
+  {
+   "@type": "type.googleapis.com/google.rpc.DebugInfo",
+   "stackEntries": [],
+   "detail": "auth"
+  }
+ ]
+}
+```
+
+Which is exactly what we want!
+
+Now go to the **Test** page of your Google Endpoints API definition on the [Auth0 Dashboard](${manage_url}/#/apis), and copy the Access Token:
+
+![Copy Token](/media/articles/tutorials/gce-copy-token.png)
+
+Perform a `GET` request to your API with an Authorization Header of `Bearer {ACCESS_TOKEN}` to obtain authorized access:
+
+```har
+{
+    "method": "GET",
+    "url": "https://YOUR_GCE_PROJECT.appspot.com/airportName",
+    "headers": [
+      { "name": "Authorization", "value": "Bearer {ACCESS_TOKEN}" }
+    ],
+    "queryString" : [
+      {
+        "name": "iataCode",
+        "value": "SFO"
+      }
+    ]
+}
+```
+
+And that's it!
diff --git a/ja-jp/articles/integrations/index.md b/ja-jp/articles/integrations/index.md
new file mode 100644
index 0000000000..c73d303ef5
--- /dev/null
+++ b/ja-jp/articles/integrations/index.md
@@ -0,0 +1,217 @@
+---
+classes: topic-page
+title: Auth0 Integrations
+description: Learn how to integrate Auth0 with other applications and services.
+topics:
+  - integrations
+contentType: index
+useCase:
+  - integrate-third-party-apps
+  - integrate-analytics
+  - integrate-marketing
+  - integrate-saas-sso
+---
+
+
    
+  
    
+  
    Auth0 Integrations
    
+  
    Tailor your identity flows with custom code and integrate with third-party systems.
+  
    
+
    
+
+
diff --git a/ja-jp/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md b/ja-jp/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md
new file mode 100644
index 0000000000..77803499d1
--- /dev/null
+++ b/ja-jp/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md
@@ -0,0 +1,114 @@
+---
+description: How to integrate Auth0 with Amazon Cognito using an OpenID Connect (OIDC) Provider.
+topics:
+  - integrations
+  - amazon
+  - cognito
+  - oidc
+contentType: how-to
+useCase: integrate-saas-sso
+---
+# Integrate Auth0 with Amazon Cognito
+
+**Amazon Cognito** is a backend as a service that lets you focus on writing a fantastic user experience for your application (native or web).
+
+This document will explain how you can integrate your app with two solutions: Auth0 to get authentication with either [Social Providers](/connections/identity-providers-social) (Facebook, Twitter, and so on), [Enterprise providers](/connections/identity-providers-enterprise) or regular Username and Password, and [Amazon Cognito](http://aws.amazon.com/cognito/), to get a backend for your app without writing a line of code.
+
+## Configure Amazon Web Services
+
+### Create a new OpenID Connect Provider
+
+The first step is to create an OpenID Connect (OIDC) Provider pointing to your Auth0 account. Please take a note of your Auth0 **domain** (`${account.namespace}`) and your **applicationId** these values can be found in the [Settings of your chosen Application](${manage_url}/#/clients/). These values will be used to create the Identity Pool in the [IAM Console](https://console.aws.amazon.com/iam/home).
+
+1. In the [IAM Console](https://console.aws.amazon.com/iam/home) click on the **Identity Providers** link in the left sidebar. Click the **Create Provider** button.
+
+    ![Create Provider](/media/articles/scenarios/amazon-cognito/create-provider.png)
+
+1. Next you will choose the provider type, select **OpenID Connect** from the dropdown. For the **Provider URL** enter: `https://YOUR_ACCOUNT_NAME.auth0.com` and for **Audience** enter your **ClientId** ([find your ClientID](${manage_url}#/applications/)).
+
+    ![Configure Provider](/media/articles/scenarios/amazon-cognito/configure-provider.png)
+
+1. This will bring you to the **Verify Provider Information** screen, click the **Create** button.
+
+    ![Verify Provider](/media/articles/scenarios/amazon-cognito/verify-provider.png)
+
+1. Then you will be able to click on your newly created provider to find the **Provider ARN** which will be used in a later step.
+
+1. Use the Thumbprint to verify the server certificate of your IdP. To learn how, see [Obtaining the Thumbprint for an OpenID Connect Identity Provider](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html). 
+
+::: note
+It's not necessary to set up an IAM role after creating the identity provider. If you don't have one already, Cognito will create a default IAM role in the next step.
+:::
+
+To obtain the Auth0 Dashboard's Thumbprint value:
+
+1. [Retrieve your Auth0 Domain's certificate chain.](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html?icmpid=docs_iam_console)
+2. Once you've obtained the certificate chain, isolate the last certificate in the chain.
+3. Using the last certificate in the chain, [compute the fingerprint](https://www.samltool.com/fingerprint.php).
+4. Convert the fingerprint to a thumbprint by removing all of the `:` characters.
+5. Use the computed thumbprint when calling the `aws iam create-open-id-connect-provider` command.
+
+### Create a Cognito Identity Pool
+
+Now, you need to create an Identity Pool in the [Cognito Console](https://console.aws.amazon.com/cognito/home). This will be used to log in to Amazon Cognito using the Auth0 Identity Provider that you created in the previous step.
+
+1. Sign in to the [Cognito Console.](https://console.aws.amazon.com/cognito/home)
+
+1. Click **Manage Federated Identities** to start creating a new identity pool.
+
+1. For **Identity Pool Name**, specify a name for the pool e.g. `Auth0`. Under **Authentication Providers**, click the **OpenID** tab and select the name of the provider you created in the previous steps. Click **Create Pool**.
+
+    ![Create Identity Pool](/media/articles/scenarios/amazon-cognito/identity-pool.png)
+
+1. This will bring up a confirmation page for allowing access to your resources. By default, Amazon Cognito creates a new role with limited permissions - end users only have access to Cognito Sync and Mobile Analytics. You can modify the roles if your application needs access to other AWS resources, such as S3 or DynamoDB. Click **Allow** to finish creating the new identity pool.
+
+    ![Confirmation page](/media/articles/scenarios/amazon-cognito/allow-role.png)
+
+1. Click **Edit Identity Pool** to view the Identity Pool ID.
+
+    ![View the Identity Pool ID](/media/articles/scenarios/amazon-cognito/pool-id.png)
+
+1. Finally, grab the ARN of the role that was automatically created in the previous step from the [IAM console](https://console.aws.amazon.com/iam/home) this value will be used when sending credentials to Cognito.
+
+    ![Role ARN](/media/articles/scenarios/amazon-cognito/role-arn.png)
+
+## Auth0 Configuration
+
+Amazon will use the public signing key from the [OpenID Provider Metadata](https://subscription.auth0.com/.well-known/jwks.json) to validate the signature of the JSON Web Token (JWT).
+
+By default Auth0 will use the HS256 signature algorithm which is not supported in this scenario (this will result in "Invalid login token" errors). Go to your application in the [dashboard](${manage_url}/#/applications), click the **Show Advanced Settings** link and then **OAuth** and change the algorithm to **RS256**.
+
+![Change to RS256](/media/articles/scenarios/amazon-cognito/jwt-algorithm.png)
+
+## Implementation
+
+You can use Auth0 Lock to log the user in. You can read detailed instructions on how to implement Lock in [the libraries documentation](/libraries#lock-login-signup-widgets).
+
+Once the user is successfully logged in with Auth0, the next step is to send their credentials to Amazon Cognito [see the Cognito docs](http://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html) to see how to implement this with depending on the platform.
+
+Cognito takes the ID Token that you obtain from the OIDC identity provider and uses it to manufacture unique Cognito IDs for each person who uses your app. When the user is logged in to Cognito through Auth0 you can store information in Cognito that only this user will be able to access. 
+
+For example (with Swift):
+
+```swift
+let cognitoSync = AWSCognito.defaultCognito()
+let dataset = cognitoSync.openOrCreateDataset("MainDataset")
+// Get an existing value
+dataset.synchronize().continueWithBlock { (task) -> AnyObject! in
+    dispatch_async(dispatch_get_main_queue(), { () -> Void in
+        self.textValue.text = dataset.stringForKey("value")
+    })
+    return nil
+}
+
+// Set a new value
+dataset.setString(self.textValue.text, forKey: "value")
+dataset.synchronize()
+```
+
+## Keep reading
+
+::: next-steps
+* [Amazon Cognito: OpenID Connect Providers](http://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html)
+* [Amazon IAM: Creating OpenID Connect (OIDC) Identity Providers](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html)
+:::
diff --git a/ja-jp/articles/integrations/marketing/adobe-campaign/index.md b/ja-jp/articles/integrations/marketing/adobe-campaign/index.md
new file mode 100644
index 0000000000..9e1dcd8e58
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/adobe-campaign/index.md
@@ -0,0 +1,66 @@
+---
+title: Export User Data To Adobe Campaign
+description: Learn how to export your Auth0 user data and import it into Adobe Campaign.
+toc: true
+topics:
+    - marketing
+    - adobe
+    - adobe-campaign
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Adobe Campaign
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Adobe Campaign with the [Adobe Campaign Import Wizard](https://docs.campaign.adobe.com/doc/AC/en/PTF_Importing_and_exporting_data_Importing_data.html).
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Adobe Campaign accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Adobe Campaign Documentation: Importing Data](https://docs.adobe.com/content/help/en/campaign-classic/using/getting-started/importing-and-exporting-data/importing-data.html)
+:::
+
+Log in to your Adobe Campaign client dashboard and navigate to **Profiles and Targets > Jobs**. Create a new import job by clicking the **Create** button and selecting **New Import**.
+
+A new **Import Wizard** window should open. On the **Template Selection** step you can set your import parameters.
+
+Parameter | Description
+----------|------------
+Import template (leave as default) | The job template, set to `New text import` by default.
+Label | A label for the job, for example: `Importing Auth0 users`.
+Description | A brief description of the job.
+Import type | Set to `Simple import` for single file imports and `Multiple import` for multiple file imports.
+Folder | Select the folder to save the import file to.
+
+Once you've configured your import parameters, click the **Next** button to continue.
+
+On the **File to Import** step upload the user data CSV file you exported from Auth0 in the previous section. Click the **Next** button to proceed to **Field Mapping**.
+
+Next, map the export file schema to your Adobe Campaign database schema. Check that the field names and field types are correct, then click the **Next** button.
+
+Complete the remaining configuration steps by defining your data reconciliation mode and selecting a folder, list, or service for the users being imported.
+
+Finally, begin the import by clicking the **Start** button on the **Data Import Execution** window.
+
+That's it! You successfully imported your Auth0 users into Adobe Campaign.
diff --git a/ja-jp/articles/integrations/marketing/alterian/index.md b/ja-jp/articles/integrations/marketing/alterian/index.md
new file mode 100644
index 0000000000..5f39fbdff9
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/alterian/index.md
@@ -0,0 +1,61 @@
+---
+title: Export User Data To Alterian
+description: Learn how to export your Auth0 user data and import it into Alterian.
+toc: true
+topics:
+    - marketing
+    - alterian
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Alterian
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Alterian with the campaign manager's data import tool.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Alterian accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Alterian Campaign Manager: Data Import](http://cm.help.alterian.com/CM404/Default.htm#Customer_Analytics/Import_Export/Data_Import.htm)
+:::
+
+To import your CSV file into Alterian, follow these steps:
+
+1. Open your Alterian Campaign Manager and click **Documents**.
+
+2. Choose the directory to import the file to.
+
+3. Click **Upload Files** and select your CSV file.
+
+4. Click **Upload**.
+
+5. Once the upload is complete, open the **Data Import** tool.
+
+6. Configure your import settings using the provided fields on the **New Imports data** window.
+    
+    ![Data Import: New Imports](/media/articles/integrations/marketing/alterian/new-data-imports.png)
+
+7. After you've reviewed your settings, click **Run Processes**.
+
+That's it! You successfully imported your Auth0 users into Alterian.
diff --git a/ja-jp/articles/integrations/marketing/constant-contact/index.md b/ja-jp/articles/integrations/marketing/constant-contact/index.md
new file mode 100644
index 0000000000..55048e1ca4
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/constant-contact/index.md
@@ -0,0 +1,57 @@
+---
+title: Export User Data To Constant Contact
+description: Learn how to export your Auth0 user data and import it into Constant Contact.
+toc: true
+topics:
+    - marketing
+    - constant-contact
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Constant Contact
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Constant Contact dashboard.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Constant Contact accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Constant Contact Knowledge Base: Import or Upload a File of Contact Email Addresses](https://knowledgebase.constantcontact.com/articles/KnowledgeBase/5296-import-or-upload-a-file-of-contact-email-addresses)
+:::
+
+To import your CSV file into Constant Contact, follow these steps:
+
+1. [Log in to Constant Contact](https://login.constantcontact.com) and navigate to **Contacts**.
+
+2. From the **Contacts** page, click **Add Contacts > Upload from file**.
+
+3. Provide you CSV file on the **Upload from file** page then click **Continue**.
+
+4. Review the columns and match them with your Constant Contact fields. Once you're finished click **Continue**.
+
+5. On the **Select lists** page, choose the list or lists to add your contacts to.
+
+6. Click **Upload**.
+
+That's it! You successfully imported your Auth0 users into Constant Contact.
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/marketing/eloqua/index.md b/ja-jp/articles/integrations/marketing/eloqua/index.md
new file mode 100644
index 0000000000..7b3e3bad71
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/eloqua/index.md
@@ -0,0 +1,58 @@
+---
+title: Export User Data To Oracle Eloqua
+description: Learn how to export your Auth0 user data and import it into Oracle Eloqua.
+toc: true
+topics:
+    - marketing
+    - eloqua
+    - oracle
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Oracle Eloqua
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Eloqua with the contact upload wizard.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Eloqua accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Oracle Eloqua Help Center: Uploading Contacts](https://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/index.html#Help/Contacts/Tasks/UploadingContacts.htm)
+:::
+
+To import your CSV file into Eloqua, follow these steps:
+
+1. Log in to Eloqua and navigate to **Audience > Contacts > Upload** to open the **Contact Upload Wizard**.
+
+2. Configure the import using the provided fields on the **Pick Data Source** tab.
+
+3. Click the **Cloud** button and select the file to upload.
+
+4. After you've verified the file contents on the **Review** tab, click **Next Step**.
+
+5. Under the **Map Fields** tab, enter the field mapping settings to match your CSV file data to contact fields. Click **Next Step** to continue.
+
+6. Complete the final step of the wizard and click **Finish**.
+
+That's it! You successfully imported your Auth0 users into Eloqua.
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/marketing/index.md b/ja-jp/articles/integrations/marketing/index.md
new file mode 100644
index 0000000000..b562fe8e1b
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/index.md
@@ -0,0 +1,30 @@
+---
+classes: topic-page
+title: Export User Data To Marketing Tools
+description: Learn how to export Auth0 user data to marketing applications and services.
+topics:
+    - marketing
+contentType: index
+useCase: export-users-marketing
+---
+
+
    
+  
    
+  
    Export User Data To Marketing Tools
    
+  
    
+    The better the data, the better the marketing campaign. With Auth0 you can provide user data for your marketing tools to personalize marketing and increase user engagement. Take a look below for tutorials to get started!
+  
    
+
    
+
+<%= include('../../_includes/_topic-links', { links: [
+  'integrations/marketing/adobe-campaign',
+  'integrations/marketing/alterian',
+  'integrations/marketing/constant-contact',
+  'integrations/marketing/eloqua',
+  'integrations/marketing/mailchimp',
+  'integrations/marketing/marketo',
+  'integrations/marketing/sailthru',
+  'integrations/marketing/salesforce',
+  'integrations/marketing/salesforce-marketing-cloud',
+  'integrations/marketing/watson-campaign-automation'
+] }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/marketing/mailchimp/index.md b/ja-jp/articles/integrations/marketing/mailchimp/index.md
new file mode 100644
index 0000000000..6b9c68dafc
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/mailchimp/index.md
@@ -0,0 +1,65 @@
+---
+title: Export User Data To MailChimp
+description: Learn how to export your Auth0 user data and import it into MailChimp.
+toc: true
+topics:
+    - marketing
+    - mailchimp
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To MailChimp
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the [MailChimp dashboard](https://login.mailchimp.com/).
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. MailChimp accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For MailChimp, an email field with the column name `Email Address` is required, so make sure to include it. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+::: note
+[MailChimp Knowledge Base: Format Guidelines for Your Import File](https://kb.mailchimp.com/lists/growth/format-guidelines-for-your-import-file)
+:::
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[MailChimp Knowledge Base: Import Subscribers to a List](https://kb.mailchimp.com/lists/growth/import-subscribers-to-a-list)
+:::
+
+Log in to your MailChimp account and go to the **Lists** page. Select a list to import your Auth0 users into ([or create a new list](https://kb.mailchimp.com/lists/growth/create-a-new-list)). On your MailChimp List page, click on **Import Contacts** from the **Add Contacts** menu.
+
+![MailChimp List: Import Contacts](/media/articles/integrations/marketing/mailchimp/import-contacts.png)
+
+On the next page, select the `CSV or tab-delimited text file` option to import contacts from.
+
+![MailChimp List Import Source](/media/articles/integrations/marketing/mailchimp/import-source.png)
+
+Next, upload the user data CSV file you exported from Auth0 in the previous section. MailChimp will interpret your user data on the following page.
+
+![MailChimp Import Column Match](/media/articles/integrations/marketing/mailchimp/import-column-match.png)
+
+Check that the column names and field types are correct, when you're ready to proceed click the **Next** button.
+
+![MailChimp Start Import](/media/articles/integrations/marketing/mailchimp/import-start.png)
+
+After reviewing your selections and setting the import category, click on the **Import** button to start the user import.
+
+That's it! You successfully imported your Auth0 users into MailChimp.
diff --git a/ja-jp/articles/integrations/marketing/marketo/index.md b/ja-jp/articles/integrations/marketing/marketo/index.md
new file mode 100644
index 0000000000..4df61e62c9
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/marketo/index.md
@@ -0,0 +1,119 @@
+---
+title: Export User Data To Marketo
+description: Learn how to export your Auth0 user data and import it into Marketo.
+toc: true
+topics:
+    - marketing
+    - marketo
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Marketo
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Marketo using the [Bulk Leads endpoint](http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#/Bulk_Leads) of the Marketo REST API.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Marketo accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+### Import a user data file
+
+::: note
+[Marketo Documentation: Bulk Lead Import](http://developers.marketo.com/rest-api/bulk-import/bulk-lead-import/)
+:::
+
+To import the user data file to Marketo, perform a POST request to the [Bulk Leads endpoint](http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#/Bulk_Leads). Set the content-type header of the request to `multipart/form-data` and include a `file` parameter with your exported CSV file as well as format parameter set to `csv`. For example:
+
+```har
+{
+    "method": "POST",
+    "url": "https://MARKETO_REST_API_BASE_URL/bulk/v1/leads.json",
+    "headers": [
+        {
+            "name": "Authorization",
+            "value": "Bearer {MARKETO_ACCESS_TOKEN}"
+        }
+    ],
+    "postData": {
+        "mimeType": "multipart/form-data",
+        "params": [
+            {
+                "name": "file",
+                "fileName": "auth0_users.csv",
+                "contentType": "text/csv"
+            },
+            {
+                "name": "format",
+                "value": "csv",
+                "contentType": "text/plan"
+            }
+        ]
+    }
+}
+```
+
+The response should look something like this:
+
+```json
+{
+    "requestId": "e42b#14272d07d78",
+    "success": true,
+    "result": [{
+        "batchId": 1234,
+        "status": "Importing"
+    }]
+}
+```
+
+You can check the status of your import using the [Get Import Lead Status API]() and your import job's `batchId`. For example:
+
+```har
+{
+    "method": "GET",
+    "url": "https://MARKETO_REST_API_BASE_URL/bulk/v1/leads/batch/BATCH_ID.json",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Authorization", "value": "Bearer {MARKETO_ACCESS_TOKEN}" }
+    ],
+    "headersSize" : 150,
+    "bodySize" : 0,
+    "comment" : ""
+}
+```
+
+And the response:
+
+```json
+{
+    "requestId": "8136#146daebc2ed",
+    "success": true,
+    "result": [{
+        "batchId": 1234,
+        "status": "Complete",
+        "numOfLeadsProcessed": 123,
+        "numOfRowsFailed": 0,
+        "numOfRowsWithWarning": 0
+    }]
+}
+```
+
+That's it! You successfully imported your Auth0 users into Marketo.
diff --git a/ja-jp/articles/integrations/marketing/sailthru/index.md b/ja-jp/articles/integrations/marketing/sailthru/index.md
new file mode 100644
index 0000000000..c4eaeb32a1
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/sailthru/index.md
@@ -0,0 +1,55 @@
+---
+title: Export User Data To Sailthru
+description: Learn how to export your Auth0 user data and import it into Sailthru.
+toc: true
+topics:
+    - marketing
+    - sailthru
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Sailthru
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Sailthru dashboard.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Sailthru accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+### Import a user data file
+
+::: note
+[Sailthru Documentation: Adding Users to Sailthru and Sailthru Lists](https://getstarted.sailthru.com/audience/managing-users/add-users-to-sailthru-and-lists/#List_File_Upload)
+:::
+
+To import your CSV file into Sailthru, follow these steps:
+
+1. Log in to Sailthru and navigate to [Lists](https://my.sailthru.com/lists).
+
+2. Choose a list, then click **Upload List** and select your CSV file.
+
+3. Select **Add To List** for the **Action**.
+
+4. Set your **Replace Vars** option and enter an email to receive notifications if desired.
+
+5. Review your settings and click **Submit** to upload the file.
+
+That's it! You successfully imported your Auth0 users into Sailthru.
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/marketing/salesforce-marketing-cloud/index.md b/ja-jp/articles/integrations/marketing/salesforce-marketing-cloud/index.md
new file mode 100644
index 0000000000..95a203e3a0
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/salesforce-marketing-cloud/index.md
@@ -0,0 +1,61 @@
+---
+title: Export User Data To Salesforce Marketing Cloud
+description: Learn how to export your Auth0 user data and import it into Salesforce Marketing Cloud.
+toc: true
+topics:
+    - marketing
+    - salesforce
+    - marketing-cloud
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Salesforce Marketing Cloud
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Salesforce Marketing Cloud using [Email Studio](https://help.salesforce.com/articleView?id=mc_es_get_started_with_email_studio.htm&type=5).
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Salesforce Marketing Cloud accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Email Studio: Import Subscribers](https://help.marketingcloud.com/en/documentation/exacttarget/subscribers/subscribers_for_interactive_marketing_hub/imports/importing_subscribers/)
+:::
+
+Before you begin, make sure your Salesforce account has the required [user permissions](https://help.salesforce.com/articleView?id=faq_import_general_permissions.htm) to import records.
+
+To import your CSV file into Salesforce Marketing Cloud, follow these steps:
+
+1. Log in to Salesforce Marketing Cloud and open **Email Studio**.
+
+2. Navigate to **Subscribers > Lists**.
+
+3. Choose the list to import to and select the **Import** action.
+
+4. After the import wizard's introduction, select your CSV file as the **Upload Source** and select CSV as the **Data Format**. Enter the remaining settings and click **Next**.
+
+5. In the **Map Attributes** dialog, map your CSV file's data fields to the correct data fields. When you've finished your mappings click **Next**.
+
+6. After you've verified your mappings in the **Confirmed Mappings** dialog, click **Begin** to start the import.
+
+That's it! You successfully imported your Auth0 users into Salesforce Marketing Cloud.
+
diff --git a/ja-jp/articles/integrations/marketing/salesforce/index.md b/ja-jp/articles/integrations/marketing/salesforce/index.md
new file mode 100644
index 0000000000..586964c0f1
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/salesforce/index.md
@@ -0,0 +1,68 @@
+---
+title: Export User Data To Salesforce
+description: Learn how to export your Auth0 user data and import it into Salesforce.
+toc: true
+topics:
+    - marketing
+    - salesforce
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Salesforce
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into Salesforce using the [Data Import Wizard](https://help.salesforce.com/articleView?id=data_import_wizard.htm).
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Salesforce accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+::: note
+[Salesforce: Prepare Your Data for Import](https://help.salesforce.com/articleView?id=import_prepare.htm)
+:::
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Salesforce: Import Data with the Data Import Wizard](https://help.salesforce.com/articleView?id=import_with_data_import_wizard.htm)
+:::
+
+Before you begin, make sure your Salesforce account has the required [user permissions](https://help.salesforce.com/articleView?id=faq_import_general_permissions.htm) to import records.
+
+To import your CSV file into Salesforce, follow these steps:
+
+1. Login to [Salesforce](https://login.salesforce.com/).
+
+2. Navigate to **Setup** and open the **Data Import Wizard**.
+
+4. Click **Launch Wizard**.
+
+5. Configure the import and select your CSV file to upload using the fields provided.
+
+6. Click **Next**.
+
+7. On the **Edit Field Mapping** page, map your CSV file's data fields to Salesforce data fields. Click **Next** to proceed.
+
+8. After you've verified the information on the **Review** page, click **Start Import**.
+
+9. Check out the **Recent Import Jobs** tab on the **Data Import Wizard** home page for updates on the status of your import.
+
+That's it! You successfully imported your Auth0 users into Salesforce.
+
diff --git a/ja-jp/articles/integrations/marketing/watson-campaign-automation/index.md b/ja-jp/articles/integrations/marketing/watson-campaign-automation/index.md
new file mode 100644
index 0000000000..5f65f357ce
--- /dev/null
+++ b/ja-jp/articles/integrations/marketing/watson-campaign-automation/index.md
@@ -0,0 +1,69 @@
+---
+title: Export User Data To Watson Campaign Automation
+description: Learn how to export your Auth0 user data and import it into Watson Campaign Automation.
+toc: true
+topics:
+    - marketing
+    - watson-campaign
+contentType: how-to
+useCase: export-users-marketing
+---
+
+# Export User Data To Watson Campaign Automation
+
+In this article, you’ll learn how to export user data in Auth0 to a CSV file then import it into the Watson Campaign Automation dashboard.
+
+## Create a user data file
+
+Start by navigating to the [Extensions](${manage_url}/#/extensions) section of the Dashboard and open the **User Import / Export Extension**. On the extension page, select **Export** from the menu.
+
+Next, set the **Export Format** to the required file format. Watson Campaign Automation accepts file imports in CSV format so choose the `Tab Separated Value file (*.csv)` option.
+
+![User Import/Export Extension Format](/media/articles/integrations/marketing/import-export-set-format.png)
+
+At the top in the **Fields** section, provide a **User Field** and **Column Name** for each user attribute to include in the export. For example:
+
+User Field | Column Name
+-----------|------------
+`email` | Email Address
+`created_at` | Created At
+`given_name` | First Name
+`family_name` | Last Name
+
+![User Import/Export Extension Fields](/media/articles/integrations/marketing/import-export-fields.png)
+
+::: note
+[Watson Campaign Automation: Considerations for importing databases](https://www.ibm.com/support/knowledgecenter/en/SSWU4L/Data/imc_Data/import_details.html)
+:::
+
+After adding the user fields, click on the **Export Users** button to start the export. Once the export is complete, download the CSV file to use in the following section.
+
+## Import a user data file
+
+::: note
+[Watson Campaign Automation: About importing a database](https://www.ibm.com/support/knowledgecenter/en/SSWU4L/Data/imc_Data/Import_a_Database.html)
+:::
+
+To import your CSV file into Watson Campaign Automation, follow these steps:
+
+1. Log in to Watson Campaign Automation and navigate to **Data > Import New**.
+
+2. On the **Select File** step, enter the new database's settings in the provided fields.
+
+3. Select the option to upload a file from a local hard drive, then click **Browse** to select the file.
+
+4. Set the file type to CSV (comma-separated values).
+
+5. Click **Next** to proceed to the **Define Data Format** step.
+
+6. Make sure your data was processed correctly, then click **Next**.
+
+7. On the **Map Fields** step, choose which fields to include in the import as well as their types.
+
+8. Click **Next** to proceed to the **Edit Field Settings** step.
+
+9. Edit the settings on default or new fields as needed.
+
+10. To start the import click **Next**.
+
+That's it! You successfully imported your Auth0 users into Watson Campaign Automation.
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/office-365-custom-provisioning.md b/ja-jp/articles/integrations/office-365-custom-provisioning.md
new file mode 100644
index 0000000000..cddf7399d4
--- /dev/null
+++ b/ja-jp/articles/integrations/office-365-custom-provisioning.md
@@ -0,0 +1,287 @@
+---
+description: How to setup Microsoft Office 365 custom provisioning.
+topics:
+  - integrations
+  - microsoft
+  - office-365
+contentType:
+  - how-to
+  - concept
+useCase: integrate-saas-sso
+---
+
+# Office 365 Custom Provisioning
+
+The default Office 365 setup will include Active Directory and DirSync/Azure AD Sync Services to synchronize and provision your AD users in Azure AD for SSO. Auth0 will then be configured to be an identity provider which is providing Single Sign-on (SSO) for these users.
+
+All of this is fine when you want SSO for your own users living in your AD. But for scenarios where you want to allow contractors, partners or even customers to access your Office 365 environment (eg: SharePoint) this approach is not optimal since these users would need to be created in your own AD environment. This is why Auth0 allows custom provisioning of Azure AD users from our rules. This would allow you to create users in Azure AD (and effectively Office 365) just as they login from any connection available in Auth0 (in that case your rule will take over DirSync's task for any type of connection where DirSync would not work). This will allow you to offer Facebook, LinkedIn, G Suite, ... logins to your Office 365 environment.
+
+## Configuring Office 365
+
+The [Office 365 tutorial](/integrations/office-365) explains how to register a custom domain and how to configure Office 365 as a third party application in Auth0. This step is required before custom provisioning can be configured.
+
+## Configuring Azure AD
+
+Custom provisioning uses the Azure AD Graph API to provision new users in Azure AD. In order to access the Azure AD Graph API an application must be created within the Azure AD Directory that has been linked to the Office 365 subscription.
+
+1. Log into the [Azure Portal](https://portal.azure.com).
+2. Choose [Azure Active Directory in the left navigation](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview).
+3. Select **App registrations** in the new menu.
+4. Click on **New application registration**.
+5. Fill the form:
+    1. Input a name for the application (such as `Auth0 Provisioning`)
+    2. Select **Web app / API** as the **Application type**.
+    3. Insert a sign-on URL. Any valid url as this won't be really used.
+5. The recently created app will appear in the **App registrations** list. Select it.
+6. In the **Settings** blade (Microsoft call these sections as blade), choose **Keys**.
+7. Input a **Description** (like `Auth0 Provision`) and choose a **Duration** for the new key. If you choose to issue non-permanent key, take note of the expiration date and create a reminder to replace the key with a new one before it expires.
+8. Click on save the key and copy the **App Key**. This key will be shown only once and it's needed for the Auth0 rule.
+![Creating a key on Azure AD apps registration](/media/articles/integrations/office-365/office-365-app-key.png)
+9. Choose **Required permissions** and click **Add** in the new blade.
+10. Select the **Microsoft Graph** API and then check `Read and write directory data` under **Application Permissions**.
+11. Back in the **Required permissions**, click on the **Grant Permissions** button and then click **Yes** to grant the requested permissions.
+
+## Azure AD Provisioning Rule
+
+The following rule shows the provisioning process:
+
+ 1. If the user comes from the AD connection, skip the provisioning process (because this will be handled by DirSync)
+ 2. If the user was already provisioned in Azure AD, just continue with the login transaction.
+ 3. Get an Access Token of the Graph API using the Azure AD Client ID and Key
+ 4. Create a user in Azure AD
+ 5. Assign a license to the user.
+ 6. Continue with the login transaction.
+
+The username is generated with the `createAzureADUser` function, which by default generates a username in the format `auth0-c3fb6eec-3afd-4d52-8e0a-d9f357dd19ab@fabrikamcorp.be`. You can change this to whatever you like, just make sure this value is unique for all your users.
+
+Make sure you set the correct values for the `AUTH0_OFFICE365_CLIENT_ID`, `AAD_CUSTOM_DOMAIN`, `AAD_DOMAIN`, `AAD_APPLICATION_ID` and `AAD_APPLICATION_API_KEY` values in your [configuration object](/rules/current#use-the-configuration-object) to make the values available in your rule code.
+
+In the code you'll also see that the rule will wait about 15 seconds after the user is provisioned. This is because it takes a few seconds before the provisioned user is available for Office 365.
+
+```js
+function (user, context, callback) {
+  // Require the Node.js packages that we are going to use.
+  // Check this website for a complete list of the packages available:
+  // https://auth0-extensions.github.io/canirequire/
+  var rp = require('request-promise');
+  var uuidv4 = require('uuid');
+
+  // The name of your Active Directory connection (if using one)
+  var AUTH0_AD_CONNECTION = 'FabrikamAD';
+  // The client_id of your Office 365 SSO integration
+  // You can get it from the URL when editing the SSO integration,
+  // it will look like
+  // https://manage.auth0.com/#/externalapps/{the_client_id}/settings
+  var AUTH0_OFFICE365_CLIENT_ID = configuration.AUTH0_OFFICE365_CLIENT_ID;
+  // The main domain of our company.
+  var YOUR_COMPANY_DOMAIN = 'mycompanyurl.com';
+  // Your Azure AD domain.
+  var AAD_DOMAIN = configuration.AAD_DOMAIN;
+  // The Application ID generated while creating the Azure AD app.
+  var AAD_APPLICATION_ID = configuration.AAD_APPLICATION_ID;
+  // The generated API key for the Azure AD app.
+  var AAD_APPLICATION_API_KEY = configuration.AAD_APPLICATION_API_KEY;
+  // The location of the users that are going to access Microsoft products.
+  var AAD_USAGE_LOCATION = 'US';
+  // Azure AD doesn't recognize the user instantly, it needs a few seconds
+  var AAD_USER_CREATE_DELAY = 15000;
+  // The key that represents the license that we want to give the new user.
+  // Take a look in the following URL for a list of the existing licenses:
+  // https://gist.github.com/Lillecarl/3c4727e6dcd1334467e0
+  var OFFICE365_KEY = 'O365_BUSINESS';
+
+  // Only execute this rule for the Office 365 SSO integration.
+  if (context.clientID !== AUTH0_OFFICE365_CLIENT_ID) {
+    return callback(null, user, context);
+  }
+
+  // Skip custom provisioning for AD users.
+  if (context.connection === AUTH0_AD_CONNECTION) {
+    return callback(null, user, context);
+  }
+
+  // If the user is already provisioned on Microsoft AD, we skip
+  // the rest of this rule
+  user.app_metadata = user.app_metadata || {};
+  if (user.app_metadata.office365Provisioned) {
+    return connectWithUser();
+  }
+
+  // Global variables that we will use in the different steps while
+  // provisioning a new user.
+  var token;
+  var userPrincipalName;
+  var mailNickname = user.email.split('@')[0];
+  var uuid = uuidv4.v4();
+  var immutableId = new Buffer(uuid).toString('base64');
+  var userId;
+
+  // All the steps performed to provision new Microsoft AD users.
+  // The definition of each function are below.
+  getAzureADToken()
+    .then(createAzureADUser)
+    .then(getAvailableLicenses)
+    .then(assignOffice365License)
+    .then(saveUserMetadata)
+    .then(waitCreateDelay)
+    .then(connectWithUser)
+    .catch(callback);
+
+  // Requests an Access Token to interact with Windows Graph API.
+  function getAzureADToken() {
+    var options = {
+      method: 'POST',
+      url: 'https://login.windows.net/' + AAD_DOMAIN + '/oauth2/token?api-version=1.5',
+      headers: {
+        'Content-type': 'application/json',
+        },
+      json: true,
+      form: {
+        client_id: AAD_APPLICATION_ID,
+        client_secret: AAD_APPLICATION_API_KEY,
+        grant_type: 'client_credentials',
+        resource: 'https://graph.windows.net'
+      },
+    };
+
+    return rp(options);
+  }
+
+  // Gets the Access Token requested above and assembles a new request
+  // to provision the new Microsoft AD user.
+  function createAzureADUser(response) {
+    token = response.access_token;
+    userPrincipalName = 'auth0-' + uuid + '@' + YOUR_COMPANY_DOMAIN;
+
+    var options = {
+      url: 'https://graph.windows.net/' + AAD_DOMAIN + '/users?api-version=1.6',
+      headers: {
+        'Content-type': 'application/json',
+        'Authorization': 'Bearer ' + token
+      },
+      json: true,
+      body: {
+        accountEnabled: true,
+        displayName: user.nickname,
+        mailNickname: mailNickname,
+        userPrincipalName: userPrincipalName,
+        passwordProfile: {
+          password: immutableId,
+          forceChangePasswordNextLogin: false
+        },
+        immutableId: immutableId,
+        usageLocation: AAD_USAGE_LOCATION
+      },
+    };
+
+    return rp(options);
+  }
+
+  // After provisioning the user, we issue a request to get the list
+  // of available Microsoft products licenses.
+  function getAvailableLicenses(response) {
+    userId = response.objectId;
+    var options = {
+      url: 'https://graph.windows.net/' + AAD_DOMAIN + '/subscribedSkus?api-version=1.6',
+      json: true,
+      headers: {
+        'Content-type': 'application/json',
+        'Authorization': 'Bearer ' + token
+      }
+    };
+    return rp(options);
+  }
+
+  // With the licenses list, we iterate over it to get the id (skuId) of the
+  // license that we want to give to the new user (office 365 in this case).
+  // We also issue a new request to the Graph API to tie the user and the
+  // license together.
+  function assignOffice365License(response) {
+    var office365License;
+
+    for (var i = 0; i < response.value.length; i++) {
+      if (response.value[i].skuPartNumber === OFFICE365_KEY) {
+        office365License = response.value[i].skuId;
+        break;
+      }
+    }
+
+    var options = {
+      url: ' https://graph.windows.net/' + AAD_DOMAIN + '/users/' + userId + '/assignLicense?api-version=1.6',
+      headers: {
+        'Content-type': 'application/json',
+        'Authorization': 'Bearer ' + token
+      },
+      json: true,
+      body: {
+        'addLicenses': [
+          {
+            'disabledPlans': [],
+            'skuId': office365License
+          }
+        ],
+        'removeLicenses': []
+      }
+    };
+    return rp(options);
+  }
+
+  // After provisioning the user and giving a license to them, we record
+  // (on Auth) that this G Suite user has already been provisioned. We
+  // also record the user's principal username and immutableId to properly
+  // redirect them on future logins.
+  function saveUserMetadata() {
+    user.app_metadata = user.app_metadata || {};
+
+    user.app_metadata.office365Provisioned = true;
+    user.app_metadata.office365UPN = userPrincipalName;
+    user.app_metadata.office365ImmutableId = immutableId;
+
+    return auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
+  }
+
+  // As mentioned, Windows Graph API needs around 10 seconds to finish
+  // provisioning new users (even though it returns ok straight away)
+  function waitCreateDelay() {
+    return new Promise(function (resolve) {
+      setTimeout(function() {
+        resolve();
+      }, AAD_USER_CREATE_DELAY);
+    });
+  }
+
+  // Adds the principal username and immutableId to the user object and ends
+  // the rule.
+  function connectWithUser() {
+    user.upn = user.app_metadata.office365UPN;
+    user.inmutableid = user.app_metadata.office365ImmutableId;
+      return callback(null, user, context);
+  }
+}
+```
+
+::: note
+This code shows the provisioning process of a new user, but you can also adapt the code to synchronize metadata of existing users.
+:::
+
+## End-user Experience
+
+The easiest way for your external users to authenticate is by using IdP initiated login: [Using smart links or IdP initiated authentication with Office 365](https://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365).
+
+You will basically need to redirect your users to the following URL (eg: using a "smart link" like `https://office.fabrikamcorp.com`):
+
+```
+https://${account.namespace}/login?client=AUTH0_OFFICE365_CLIENT_ID&protocol=wsfed&state=&redirect_uri=&
+```
+
+::: panel AUTH0_OFFICE365_CLIENT_ID
+The `AUTH0_OFFICE365_CLIENT_ID` value can be obtained from the URL when working with the Dashboard. When viewing or editing the settings for the Office 365 SSO Integration in Auth0, you will see a URL in the form of `${manage_url}/#/externalapps/${account.clientId}/settings`. The `${account.clientId}` is the value you need here.
+:::
+
+This will show them the Auth0 login page after which they'll be redirected to Office 365. It will be important to explain external users that this is the only way they can authenticate, since the Office 365 login page does not support Home Realm Discover for these external users. This also means that, when they try to open a link, they'll need to visit the smart link first before the can access the link they tried to open.
+
+![Different connections enabled for Office 365](/media/articles/integrations/office-365/office-365-different-connections.png)
+
+In this example Fabrikam enabled a few social accounts and a database connection for their Office 365 Third Party application in Auth0.
+
+<%= include('./_office-365-deep-linking') %>
diff --git a/ja-jp/articles/integrations/office-365.md b/ja-jp/articles/integrations/office-365.md
new file mode 100644
index 0000000000..03c17657ba
--- /dev/null
+++ b/ja-jp/articles/integrations/office-365.md
@@ -0,0 +1,204 @@
+---
+description: Overview of Microsoft Office 365 Integration with Auth0.
+toc: true
+topics:
+  - integrations
+  - microsoft
+  - office-365
+contentType: how-to
+useCase: integrate-saas-sso
+---
+# Office 365 Integration
+
+Auth0 can help radically simplify the authentication process for Office 365. In this tutorial, you'll learn how to add Single Sign-on (SSO) to Office 365 using Auth0.
+
+## Why use Auth0 for Office 365
+
+Your users will be able to log in using their existing Active Directory credentials, with support for Integrated Windows Authentication (Kerberos) if they're on a domain-joined machine in the corporate network.
+
+This would typically require you to setup [an advanced ADFS infrastructure](https://msdn.microsoft.com/en-us/library/azure/dn151324.aspx) with Federation Servers in the corporate network and Web Application Proxies exposed in the DMZ. But with Auth0 as an identity provider for Office 365 all of this is handled by the [AD Connector](/connector/overview) which doesn't require you to expose any of your servers to the outside world.
+
+In addition to that users can also setup SSO with custom apps or integrations like Salesforce, Dropbox, and SharePoint Server.
+
+## High-level Overview
+
+Office 365 is a service that consists of a number of products and services. Users are added to an Office 365 subscription after which licenses can be assigned to them (such as Lync Online, Exchange Online).
+
+![Office 365 Users](/media/articles/integrations/office-365/office-365-users-overview.png)
+
+Office 365 uses Azure AD as an identity store which supports different account management and authentication models:
+
+1. **Cloud Identity**: Users are created in the cloud (Office 365/Azure AD) with no relation to an on-premises directory. Authentication happens with Azure AD.
+2. **Synchronized Identity**: Users are synchronized from an on-premises LDAP directory (like Active Directory) to Azure AD. This means the user management can happen on-premises but authentication will always happen in the cloud using Azure AD.
+3. **Federated Identity**: Users are synchronized from an on-premises LDAP directory (like Active Directory) to Azure AD. In this case Azure AD will act as the user store, but authentication will happen with a SAML 2.0 identity provider configured by the customer. This can be an ADFS server, Shibboleth, or in our case, Auth0. With this third model you can add SSO support to Office 365.
+
+This means that even if you use Auth0 for SSO support in Office 365, you will always need to synchronize your on-premises users to Office 365/Azure AD because it will be used as a user store (for user information, assigning licenses to those users, and so on.).
+
+![Office 365 High-level Overview](/media/articles/integrations/office-365/office-365-high-level-overview.png)
+
+When authentication is handed over to Auth0 it will use the AD Connector to authenticate the user. The link between the Auth0 user and the user in Azure AD is made using the `User Principal Name`. When Jack is synchronized to Azure AD his UPN will be `jack@fabrikamcorp.be` and when Jack authenticates using Auth0 the same UPN will be included in the SAML assertion to identify the authenticated user to the user stored in Azure AD.
+
+::: note
+If you're interested in providing SSO to Office 365 using other connections (like Database Connections or traditional AD) you can [write a rule with custom provisioning logic](/integrations/office-365-custom-provisioning)
+:::
+
+## Configure Synchronization With Office 365 / Azure AD
+
+The synchronization with your local LDAP directory can be configured in Office 365 or Azure AD (if you have an Azure Subscription).
+
+Before setting up the actual synchronization we'll need to add a custom domain for which federation can be enabled (this does not work with the default `tenant.onmicrosoft.com` domain).
+
+![Office 365 Domain](/media/articles/integrations/office-365/office-365-domain.png)
+
+The domain can be configured under the **Domains** menu of the Admin Center where you'll need to validate it (using a TXT or MX record).
+
+Once the domain is validated you can [Activate Active Directory synchronization](https://portal.office.com/Default.aspx#@/DirSync/DirectorySynchronization.aspx), run the IdFix tool (to fix common errors in Active Directory) and finally install and configure **Azure AD Sync Services**.
+
+![AAD Sync](/media/articles/integrations/office-365/office-365-aad-sync.png)
+
+After installing and configuring the tool you'll be able to start the synchronization and your AD users will start showing up in the Admin Center user overview.
+
+## Configure SSO With Auth0
+
+Everything in terms of synchronization has been configured and we can now proceed to the SSO configuration with Auth0. We will start by adding Office 365 as a SSO Integration in the dashboard.
+
+![](/media/articles/integrations/office-365/office-365-SSO.png)
+
+On the **Settings** tab we'll need to enter our custom domain name (eg: `fabrikamcorp.be`) and choose the Active Directory connection we want to use.
+
+![Settings Page](/media/articles/integrations/office-365/office-365-settings-page.png)
+
+The **Tutorial** page will now be updated to match the settings and we'll need to run the few lines of PowerShell in the [Azure Active Directory Module for Windows PowerShell](https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx).
+
+Here's the script Fabrikam Corporation will be running to configure their Office 365 subscription:
+
+```powershell
+$cred = Get-Credential
+Connect-MsolService –Credential $cred
+
+Set-MsolDomainAuthentication
+    -DomainName "fabrikamcorp.be"
+    -FederationBrandName "fabrikamcorp.be"
+    -Authentication Federated
+    -PassiveLogOnUri "https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi"
+    -ActiveLogonUri "https://fabrikam.auth0.com/yNqQMENaYIONxAaQmrct341tZ9joEjTi/trust/usernamemixed?connection=FabrikamAD"
+    -MetadataExchangeUri "https://fabrikam.auth0.com/wsfed/FederationMetadata/2007-06/FederationMetadata.xml?connection=FabrikamAD"
+    -SigningCertificate "MIID..."
+    -IssuerUri "urn:fabrikam"
+    -LogOffUri "https://fabrikam.auth0.com/logout"
+    -PreferredAuthenticationProtocol WsFed
+```
+
+## End-user Experience
+
+Depending on which device the user is connecting from and the user's location (within the corporate network or not) the end-user experience will be different.
+
+### With Kerberos
+
+If Kerberos has been configured for the Active Directory connection and the users are on a domain-joined machine in the corporate network they'll be able to authenticate using Integrated Windows Authentication (Kerberos) without having to enter their credentials.
+
+To skip the Auth0 page with the **windows authentication** button you can append `?whr={name-of-the-ad-connection}` to the `PassiveLogOnUri` parameter of the PowerShell script.
+
+```
+-PassiveLogOnUri "https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi?whr=FabrikamAD"
+```
+
+### Without Kerberos
+
+When authentication with Kerberos is not possible (eg: not enabled for the connection, not a domain-joined machine, not in the corporate network, and so on.) the users will see the username/password login page instead.
+
+![Login Page](/media/articles/integrations/office-365/office-365-login-page.png)
+
+This is where they'll enter their Active Directory credentials after which they'll be signed in to Office 365.
+
+## Log in Users without the Azure AD Portal
+
+When users navigate to [https://portal.office.com](https://portal.office.com) they will always see the Azure AD login page which will redirect the users to the configured identity provider after entering their username. Using the IdP initiated login flow we can skip this step.
+
+Auth0 exposes an endpoint that can immediately start the login without showing the Azure AD login page. The format is as follows:
+
+`https://{tenant}.auth0.com/wsfed/{client-id}?whr={AD-connection-name}`
+
+For Fabrikam's SSO Integration the URL will look like this:
+
+`https://fabrikam.auth0.com/wsfed/yNqQMENaYIONxAaQmrct341tZ9joEjTi?whr=FabrikamAD`
+
+Fabrikam can now host a simple website, like `http://office.fabrikamcorp.com` which contains a redirect to this url to trigger the automatic login flow.
+
+```
+    
+        
+    Fabrikam Office      
+        
+  
+  
+```
+
+For users without Kerberos this will immediately show the login page. Users on a domain-joined machine will immediately be signed in to Office 365.
+
+<%= include('./_office-365-deep-linking') %>
+
+## Handling multiple domains
+
+If you have multiple domains associated to your Microsoft account, you will have to run the PowerShell script once for each domain, choosing a different `IssuerUri` for each domain. The `IssuerUri` is an arbitrary value, but it makes sense to make it match the domain and at least have a consistent naming convention. Here's the script that Fabrikam would use for its `contoso.com` domain:
+
+```powershell
+$cred = Get-Credential
+Connect-MsolService –Credential $cred
+
+Set-MsolDomainAuthentication
+    -DomainName "contoso.com"
+    -FederationBrandName "contoso.com"
+    -IssuerUri "urn:contoso.com"
+    [...other options remain the same for all domains...]
+```
+
+### Multiple domains and products using Legacy Authentication
+
+Office products support [Modern Authentication](https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517) ("ADAL") and/or "Legacy" authentication (depending on product and version number). Every response sent by Auth0 to Office 365 includes a fixed "Issuer" attribute that is `urn:{your Auth0 account}`. If your setup requires that one or more Office products use legacy authentication, you will have to create a rule that changes the `Issuer` dynamically depending on the domain. To do this:
+
+1. Go to your Office 365 SSO Integration settings in Auth0, and copy the client ID from the URL. The URL will look like this:
+```
+${manage_url}/#/externalapps/YOUR_CLIENT_ID/settings
+```
+You will need the `YOUR_CLIENT_ID` part of the segment.
+
+2. Go to the **Rules** section and create a new rule. Start from the **Empty** template, name it `Set Issuer for Office 365 SSO Integration` and write code similar to this to set the issuer according to the domain of the user's email:
+
+```js
+function (user, context, callback) {
+  // retrieve values from the configuration object
+  const office365ClientId = configuration.OFFICE365_CLIENT_ID; // put the right client id
+  const primaryDomain = configuration.PRIMARY_DOMAIN; // for example, exampleco.com
+  const secondaryDomain = configuration.SECONDARY_DOMAIN;
+
+  if (context.clientID !== office365ClientId)
+      return callback(null, user, context);
+
+  var getIssuerURI = function(domain) {
+    // write code that returns the right issuer URI
+    // for each domain
+    if (domain === primaryDomain) {
+      return 'urn:' + primaryDomain;
+    } else if (domain === secondaryDomain) {
+      return 'urn:' + secondaryDomain;
+    }
+    return null;
+  }
+
+  var domain = (user.userPrincipalName || user.email).split('@')[1];
+
+  // set the issuer according to the domain from
+  // the user's email address
+  var issuer = getIssuerURI(domain);
+
+  if (issuer) {
+    context.samlConfiguration = context.samlConfiguration || {};
+    context.samlConfiguration.issuer = issuer;
+  }
+
+  callback(null, user, context);
+}
+```
+
+Remember to set the right `office365ClientId` and adjust the mapping logic according to the IssuerURIs selected for each domain.
diff --git a/ja-jp/articles/integrations/office365-connection-deprecation-guide.md b/ja-jp/articles/integrations/office365-connection-deprecation-guide.md
new file mode 100644
index 0000000000..28a608c5ca
--- /dev/null
+++ b/ja-jp/articles/integrations/office365-connection-deprecation-guide.md
@@ -0,0 +1,30 @@
+---
+description: Details migrating Office365 connections to Windows Azure AD.
+topics:
+  - integrations
+  - microsoft
+  - office-365
+  - windows
+  - azure-ad
+  - active-directory
+contentType: how-to
+useCase: integrate-saas-sso
+---
+
+# Migrate Office365 Connections to Windows Azure AD
+
+::: warning
+Office365 has been deprecated. You should migrate your Office365 Connections to Windows Azure AD Connections.
+:::
+
+Since early days, we supported authenticating users with Office365. Office365 has always used Windows Azure AD behind the scenes, but there wasn't a good UI to create an "application" in Windows Azure AD. That's why you had to create it in the Seller Dashboard. Moving forward Microsoft wants you to use Windows Azure AD and you can now easily create a directory associated with your Office365 account and the application.
+
+## How to migrate to Azure
+
+1. Create a Windows Azure AD subscription (free)
+
+2. Create a Directory (that will be associated with your Office365 account) and an application as explained [here](/waad-clientid).
+
+::: warning
+If you were using the `user_id` in your application, notice that it will change from `office365|....some-guid....` to `waad|...email....`.
+:::
diff --git a/ja-jp/articles/integrations/sharepoint-apps.md b/ja-jp/articles/integrations/sharepoint-apps.md
new file mode 100644
index 0000000000..54666c43c3
--- /dev/null
+++ b/ja-jp/articles/integrations/sharepoint-apps.md
@@ -0,0 +1,91 @@
+---
+description: How to connect provider hosted apps to SharePoint Online.
+topics:
+  - integrations
+  - sharepoint
+contentType: how-to
+useCase: integrate-saas-sso
+---
+# Connecting Provider Hosted Apps to SharePoint Online
+
+Auth0 can help radically simplify the authentication process for SharePoint Apps. Auth0 will negotiate an Access Token you can the use to call SharePoint APIs.
+
+You won't need any special libraries. You can use any of the SDKs supported by Auth0.
+
+## 1. Register your application in Auth0
+
+Just register a new application in Auth0 as you would normally do: __Applications > NEW__. Pick up any of the SDKs available for detailed instructions. Keep the `client_id` handy, as you will need it in the next step.
+
+## 2. Create a package for your application
+
+You need to obtain a __Client ID__ and a __Client Secret__ for your application. There are many ways of registering your application depending on the expected usage.
+
+::: note
+[This article](http://msdn.microsoft.com/en-us/library/office/jj687469(v=office.15).aspx) explains all different ways of registering your application in SharePoint. This step in the tutorial will use the simplest form: using self-registration in a specific tenant (yours).
+:::
+
+### Open SharePoint Online
+
+The URL for the dashboard is `https://{your Office365 tenant}.sharepoint.com/_layouts/15/appregnew.aspx`
+
+### Generate a __Client_Id__ and __ClientSecret__:
+
+![](/media/articles/integrations/sharepoint-apps/90SvG.png)
+
+### Complete the information in the form:
+
+Since Auth0 is in between your app and the Office 365 infrastructure, you need to use this URL for the app:
+
+**App Domain**:
+
+  ${account.namespace}
+
+**Redirect URI**:
+
+  https://${account.namespace}/login/callback?SP_APP_TOKEN&connection=CONNECTION&client_id=${account.clientId}&redirect_uri=${account.callback}
+
+* `connection` is just the name you will use in Auth0's connections (such as "sharepoint").
+* `client_id` identifies your app in Auth0 (created in steps 1).
+* `redirect_uri` is the location in your actual app, where your users will land eventually after all negotiations complete. If you don't specify it, it will always be the app's callback URL defined in Auth0 (it could be localhost)
+
+### Package the app and upload to SharePoint:
+
+Complete the information in your app manifest in Visual Studio:
+
+![](/media/articles/integrations/sharepoint-apps/90SEc.png)
+
+Notice the `Query string` will be exactly like the `Redirect URI` you completed before. Then right-click on the project and select `Publish`:
+
+![](/media/articles/integrations/sharepoint-apps/90SUB.png)
+
+Create a __Publishing Profile__ (you will have to enter the same __Client Id__ & __Client Secret__ obtained in the SharePoint dashboard).
+
+Click on __Package__ and upload the resulting file to SharePoint.
+
+
+## 3. Create the Connection in Auth0
+
+The last step in the integration is to add a SharePoint connection in Auth0:
+
+![](/media/articles/integrations/sharepoint-apps/8XoVl.png)
+
+You will need:
+
+* `Connection Name`. This is an arbitrary name. It has to match with what you entered in step 2.
+* `Client Id` & `Client Secret`. Also need to match what you entered in step 2.
+* `Test SharePoint Site Url`. This is the SP site URL used to test the connection. (such as when pressing the 'Try' button on the dashboard). This is never used at runtime because users will always follow the link to your site from within SharePoint.
+
+
+Users will install your app from the Office Marketplace. When they click on the link, they will be directed to Auth0, which will negotiate the Access Token for you, and finally to your app. Your app will receive a `User Profile` that will look like this:
+
+![](/media/articles/integrations/sharepoint-apps/8Xp6x.png)
+
+::: note
+Notice that the following properties will be included: `cacheKey`, `refresh_token`, `host`, and `site`. These will allow you to call back SharePoint APIs (such as lists).
+:::
+
+```text
+  GET https://yoursite.sharepoint.com/_api/web/lists
+  Accept: application/json;odata=verbose
+  Authorization: Bearer THE_ACCESS_TOKEN
+```
diff --git a/ja-jp/articles/integrations/sharepoint.md b/ja-jp/articles/integrations/sharepoint.md
new file mode 100644
index 0000000000..4870a916cb
--- /dev/null
+++ b/ja-jp/articles/integrations/sharepoint.md
@@ -0,0 +1,289 @@
+---
+description: How to integrate with SharePoint 2010/2013, including setup, troubleshooting, accessing logs and next steps.
+topics:
+  - integrations
+  - sharepoint
+contentType: how-to
+useCase: integrate-saas-sso
+---
+
+# SharePoint 2010/2013 Integration
+
+Auth0 can help to radically simplify the authentication process for SharePoint. In this tutorial, you'll learn how to add Single Sign-on (SSO) to Sharepoint using Auth0. Your users will be able to log in using any of our [Social Identity Providers](/identityproviders) (Facebook, Twitter, Github, and so on), [Enterprise Providers](/identityproviders) (LDAP, Active Directory, ADFS, and so on) or with a username and password.
+
+## Setup
+
+### 1. Adding the Integration to your account
+
+The first thing you need to do is go to the [SSO Integrations](${manage_url}/#/externalapps/create) section in the Dashboard and choose **SharePoint** from the list of apps.
+
+![Create a new SSO Integration](/media/articles/integrations/sharepoint/sharepoint-new-sso.png)
+
+### 2. Follow the Live Documentation
+
+::: note
+If your SharePoint server does not have Internet access, you will need to download the installation files to a SharePoint server manually ([Learn more about offline installation](https://github.com/auth0/auth0-sharepoint/tree/master/auth0-authentication-provider#offline-installation)).
+:::
+
+On the **Settings** tab you'll need to enter the URL of the SharePoint Web Application and the external URL (typically the internet endpoint in your Alternate Access Mappings).
+
+![Tutorial](/media/articles/integrations/sharepoint/sharepoint-app-tutorial.png)
+
+The Live Documentation will first start with the installation of the Auth0 CmdLets for SharePoint:
+
+![Auth0 CmdLets for SharePoint](/media/articles/integrations/sharepoint/sharepoint-cmdlets-installation.png)
+
+Once these have been installed you'll be able to enable/disable Auth0 and the Claims Provider for the different Web Applications. You will need to enable authentication with Auth0:
+
+![Auth0 Authentication for SharePoint](/media/articles/integrations/sharepoint/sharepoint-auth-installation.png)
+
+And then install the Claims Provider, to make sure that the People Picker and permissions work correctly:
+
+![Claims Provider for SharePoint](/media/articles/integrations/sharepoint/sharepoint-cp-installation.png)
+
+Once these scripts have been executed you'll complete the configuration in Central Administration:
+
+![Central Administration](/media/articles/integrations/sharepoint/sharepoint-central-admin.png)
+
+Note that the call to `Enable-Auth0` can be adapted to:
+
+ - Change the unique identifier for users (such as email or a user id)
+ - Allow additional claims to be passed through to SharePoint
+ - Enable or disable the default Windows Authentication
+
+The following example also adds the Role claim to the claims mapping and allows Windows Authentication:
+
+```
+Enable-Auth0
+  -auth0Domain:"fabrikam.auth0.com"
+  -clientId:"bOFty3tWgpijnwMcltysNFqHgO1ziz1I"
+  -webAppUrl:"http://fabrikam-sp/"
+  -identifierClaimType:"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  -claims:@(
+    "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "Client ID|http://schemas.auth0.com/clientID",
+    "Given Name|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+    "Surname|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "Picture|http://schemas.auth0.com/picture")
+  -allowWindowsAuth
+```
+
+### 3. You now have Sharepoint configured
+
+You have configured SharePoint to use Auth0 as the SSO broker. When your users visit your site they'll be presented with a login page showing all the connections enabled for that application.
+
+![SharePoint Login Page](/media/articles/integrations/sharepoint/sharepoint-login-page.png)
+
+Depending on which claims have been mapped when installing the claims provider this additional information will also be available in the user's personal settings page:
+
+![SharePoint User Info](/media/articles/integrations/sharepoint/sharepoint-user-info.png)
+
+## Customizing the Login Page
+
+You can customize the login page by following the instructions in the [documentation on customizing the login page](/universal-login#simple-customization).
+
+You might wish to provide a way to let users authenticate with Sharepoint using Windows Authentication, bypassing Auth0. You can do that by customizing the login page, adding a link to the Windows Authentication endpoint (usually similar to `https://yoursharepointserver/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx`).
+
+On way of doing it is by using jQuery to modify the Lock widget and add a link to the Windows Authentication endpoint.
+
+You need to add a reference to jQuery at the top of the `` section of the customized login page.
+
+```js
+
+```
+
+Before calling `lock.show()`, add code to modify the HTML DOM that adds the link.
+
+```js
+// construct Lock
+// var lock = ...
+[...]
+// One or more SharePoint client IDs here for which you want
+// a Windows Auth button
+var sharepointClientIDs = ['your_sharepoint_client_id'];
+
+if (sharepointClientIDs.indexOf(config.clientID) >= 0) {
+  lock.on('signin ready', function() { 
+    var getParameterByName = function(name) {
+      name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
+      var regexS = "[\\?&]" + name + "=([^&#]*)";
+      var regex = new RegExp(regexS);
+      var results = regex.exec(window.location.search);
+      if (results == null) return null;
+      else return results[1];
+    };
+    // get the host from the callback URL
+    var parser = document.createElement('a');
+    parser.href = config.callbackURL;
+    var host = parser.host;
+    var windowsAuthURL = "https://" + host + "/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx";
+    var wctx = getParameterByName("wctx");
+    if (wctx) {
+      windowsAuthURL += "&Source=" + wctx;
+    }
+
+    $('.auth0-lock-tabs-container') 
+    .after('').attr('href','https://nowhere');
+  });
+}
+
+lock.show();
+```
+
+![SharePoint Login Page Windows Auth](/media/articles/integrations/sharepoint/sharepoint-login-page-windows-auth.png)
+
+## Troubleshooting
+
+When working with additional claims and authorization it can always be useful to view the claims for the current user. [Liam Clearly](https://www.helloitsliam.com)'s [Claims Viewer Web Part](https://sharepointobservations.wordpress.com/2013/08/21/sharepoint-2013-and-adfs-2-0-test-with-claims-viewer-web-part/) can be used to troubleshoot any issues with the user's claims:
+
+![Claims Webpart](/media/articles/integrations/sharepoint/sharepoint-claims-webpart.png)
+
+### Logs in SP2010
+
+Errors and warnings are logged to SharePoint's Unified Logging Service and tools like the [ULS Viewer](http://www.microsoft.com/en-us/download/details.aspx?id=44020) can be used to troubleshoot any issues you might have when using the Claims Provider.
+
+![ULS](/media/articles/integrations/sharepoint/sharepoint-uls-logs.png)
+
+### Logs in SP2013
+
+For SharePoint 2013 we no longer use the Unified Logging Service for our logs, but we've moved to Event Tracing for Windows instead. This delivers more performance and gives you multiple ways of capturing all the logged events.
+
+To view the logs in real-time you can download [the Logs Processor](https://github.com/auth0/auth0-sharepoint/releases). Run this tool on your SharePoint Server(s) to see every call SharePoint is making to the Claims Provider:
+
+![ETW](/media/articles/integrations/sharepoint/sharepoint-logs-real-time.png)
+
+## Next Steps
+
+### Authorization
+
+The claims being passed through from Auth0 can also be used for authorization in SharePoint. For example, a user with the Role claim containing **Fabrikam HR** should have access or be a Contributor on a specific site.
+
+Let's take Azure AD as an example. In this Cloud Directory users can be part of groups and David is part of Fabrikam HR.
+
+![Azure AD Group Member](/media/articles/integrations/sharepoint/sharepoint-group-member.png)
+
+When David logs in using his Azure AD account (and the Security Groups attribute is enabled for that connection) the group memberships will be stored in the `groups` attribute of the user's profile.
+
+![User Groups](/media/articles/integrations/sharepoint/sharepoint-profile-groups.png)
+
+If we want to make these groups available as Roles in SharePoint we'll need to write a [Rule](${manage_url}/#/rules) that adds this to the SAML configuration. This rule will only run for the application named **Fabrikam Intranet (SharePoint)**.
+
+```
+function (user, context, callback) {
+  if (context.clientName === 'Fabrikam Intranet (SharePoint)') {
+    context.samlConfiguration.mappings = {
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'user_id',
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress': 'email',
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name': 'name',
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname': 'given_name',
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname': 'family_name',
+        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn': 'upn',
+        'http://schemas.microsoft.com/ws/2008/06/identity/claims/role': 'groups'
+    };
+  }
+
+  callback(null, user, context);
+}
+```
+
+This will add an additional outgoing claim `http://schemas.microsoft.com/ws/2008/06/identity/claims/role` containing the `groups` and which will be used by SharePoint for authorization.
+
+When installing the Claims Provider we need to allow the Role claim to be passed through to SharePoint, by adding it to the claims mapping list:
+
+```
+Enable-Auth0
+  -auth0Domain:"fabrikam.auth0.com"
+  ...
+  -claims:@(
+    "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
+    ...)
+  ...
+  -Verbose
+```
+
+By default a user won't have access to the site:
+
+![Access Denied](/media/articles/integrations/sharepoint/sharepoint-no-access.png)
+
+Now instead of adding that specific user to a SharePoint Group (eg: Contributors) we can now add a **Role** to a SharePoint Group. Here's a sample PowerShell script that shows how to add "Fabrikam HR" members to the Contributors group:
+
+```
+$webName = "http://fabrikam-sp"
+$groupName = "Contributors"
+$roleClaim = "Fabrikam HR"
+
+$sts = Get-SPTrustedIdentityTokenIssuer "Auth0"
+$claimPrincipal = New-SPClaimsPrincipal -ClaimValue $roleClaim -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts
+
+$web = Get-SPWeb $webName
+$user = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web
+
+$group = $web.SiteGroups[$groupName]
+$group.AddUser($user)
+```
+
+After adding this claim value to the Contributors group David will be able to access the site and edit its contents.
+
+### User Profile Synchronization
+
+By default SharePoint is able to synchronize user profile information originating from Active Directory. Now with Auth0 users can come from different types of connections (from social to enterprise) which will require a different approach to synchronize user profiles.
+
+A first approach would be to create a timer job that runs every few hours, queries the Auth0 Users Endpoint and synchronizes the profile information for those users.
+
+```cs
+using System;
+
+using Microsoft.SharePoint;
+using Microsoft.SharePoint.Administration;
+
+using Microsoft.Office.Server;
+using Microsoft.Office.Server.UserProfiles;
+
+namespace UserProfileSync
+{
+    class Program
+    {
+        static void Main(string[] args)
+        {
+            // Call the Auth0 Management API - https://docs.auth0.com/api/v2
+
+            using (var site = new SPSite("http://servername"))
+            {
+                var context = SPServiceContext.GetContext(site);
+                var profileManager = new UserProfileManager(context);
+
+                var accountName = "i:05.t|auth0|john@example.org";
+                var userProfile = profileManager.GetUserProfile(accountName);
+                userProfile[PropertyConstants.HomePhone].Value = "+1 594 9392";
+                userProfile.Commit();
+            }
+        }
+    }
+}
+```
+
+Alternatively this logic could also be implemented as an HttpModule which runs each time the user logs in:
+
+```cs
+public class PersistUserClaimsHttpModule : IHttpModule
+{
+    private SPFederationAuthenticationModule FederationModule
+    {
+        get { return HttpContext.Current.ApplicationInstance.Modules["FederatedAuthentication"] as SPFederationAuthenticationModule; }   
+    }
+
+    public void Init(HttpApplication context)
+    {
+        FederationModule.SecurityTokenValidated += OnFederationSecurityTokenValidated;
+    }
+
+    private void OnFederationSecurityTokenValidated(object sender, SecurityTokenValidatedEventArgs e)
+    {
+        // Use e.ClaimsPrincipal
+    }
+}
+```
diff --git a/ja-jp/articles/integrations/sso/_template.md b/ja-jp/articles/integrations/sso/_template.md
new file mode 100644
index 0000000000..3cf0d599a6
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/_template.md
@@ -0,0 +1,174 @@
+# Configure SSO Integration for ${service}
+
+This guide will show you how to configure an SSO integration.
+
+<% if (service === "Active Directory RMS") { %>
+::: warning
+The steps in this guide are valid for Active Directory Rights Management Services 2008 and earlier.
+:::
+<% } %>
+
+The ${service} [Single Sign-on (SSO)](/sso) Integration lets you create a client application that uses Auth0 for authentication and provides SSO capabilities. Your users log in to ${service} with Auth0 [identity providers](/identityproviders), which means they perform the identity credentials verification.
+
+## Create an SSO Integration
+
+To create a new SSO Integration, navigate to [Dashboard > SSO Integrations](https://manage.auth0.com/#/externalapps) and click **+ Create SSO Integration**.
+
+![](/media/articles/sso/integrations/new.png)
+
+Next, select a provider.
+
+![](/media/articles/sso/integrations/options.png)
+
+Set the name for your SSO Integration. Click **Create**.
+
+![](/media/articles/sso/integrations/name.png)
+
+You will be brought to the **Tutorial** page for the provider, which contains instructions on how you can complete the integration with the external services provider so that it works with Auth0 for authentication. 
+
+![](/media/articles/sso/integrations/${img}.png)
+
+Once you're done configuring your integration, note that there are two additional tabs with additional options for you to manage:
+
+1. **Settings**, which will allow you to change the integration's settings
+2. **Connections**, which will allow you to enable/disable the integration for the connections associated with your tenant
+
+### Settings
+
+On the **Settings** page, configure the following values:
+
+
+    
+        
+            
+            
+        
+    
+    
+        
+            
+            
+        
+        <% if (service === "Active Directory RMS") { %>
+        
+           
+            
+        
+        <% } %>
+        <% if (service === "EchoSign") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Egnyte") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "New Relic") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Microsoft Dynamics CRM") { %>
+        
+            
+            
+        
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Office 365") { %>
+        
+            
+            
+        
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Sentry") { %>
+        
+            
+            
+        
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Slack") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Salesforce") { %>
+        
+            
+            
+        
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "SharePoint") { %>
+        
+            
+            
+        
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "SpringCM") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Zendesk") { %>
+        
+            
+            
+        
+        <% } %>
+        <% if (service === "Zoom") { %>
+        
+            
+            
+        
+        <% } %>
+        
+            
+            
+        
+    
+
    SettingDescription
    NameThe name for your SSO integration (if you would like to change the value you provided when you first set up the integration).
    Rights Management Services URLThe URL of your Active Directory Rights Management Server.
    EchoSign Custom DomainThe domain of your EchoSign URL ( https://{domain}.echosign.com).
    Egnyte DomainThe domain of your Egnyte URL ( https://{domain}.egnyte.com).
    New Relic Account NumberYour account number for New Relic, can be found in the url after the /account/ path.
    Server URLThe URL for your Microsoft Dynamics CRM server.
    X.509 Encryption CertificateThe certificate (DER encoded binary X.509) used to encrypt tokens sent to Microsoft Dynamics CRM by Auth0.
    DomainYour Office 365 domain.
    Auth0 ConnectionThe connection to use with this integration, typically an Active Directory connection.
    Organization SlugThe generated slug for your Sentry organization found in your URL (i.e., the slug for `https://sentry.acme.com/acme-org/` would `acme-org`.
    Sentry URL PrefixYour URL prefix if you're using Sentry Community Edition; otherwise, leave blank.
    Team NameThe name of your Slack team.
    Salesforce DomainYour Salesforce Domain.
    Entity IDThe arbitrary URL that identifies the Saleforce resource.
    SharePoint URLThe internal URL for the SharePoint application.
    External URLs (optional)A comma-separated list of URLs, only required if the SharePoint application is exposed to the internet.
    SpringCM ACS URLThe ACS URL for your SpringCM.
    Zendesk Account NameYour Zendesk account name.
    Zoom Account NameYour Zoom account name.
    Use Auth0 instead of the IdP to do Single Sign-on (SSO). **Legacy tenants only.**If enabled, Auth0 will handle SSO instead of ${service}.
    
+
+Click **Save**.
+
+### Enable Connections
+
+<% if (service === "Zendesk") { %>
+::: warning
+Zendesk **requires** that all users have an email address. When enabling Enterprise or Social connections, make sure that they will provide an email address
+that can be sent to Zendesk.
+:::
+
+<% } %>
+The **Connections** tab features a list of user sources available to your tenant. Your connections are organized by type (e.g., Database, Social, Enterprise, Passwordless).
+
+You can choose the connections that you want used with your newly-created SSO integration; this allows the users in those connections to log in to ${service}.
+
+## Complete Set Up
+
+Once you've followed the configuration instructions in the tutorial, modified your settings (if necessary), and enabled your connection(s), you're done with setting up an SSO integration between ${service} and Auth0.
diff --git a/ja-jp/articles/integrations/sso/ad-rms.md b/ja-jp/articles/integrations/sso/ad-rms.md
new file mode 100644
index 0000000000..c54065deb4
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/ad-rms.md
@@ -0,0 +1,21 @@
+---
+title: Active Directory RMS Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Active Directory RMS and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - microsoft
+  - active-directory-rms
+  - windows
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/ad-rms/0') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/1') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/2') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/3') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/4') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/5') %> 
+<%= include('../../../snippets/sso-integrations/ad-rms/6') %>
+<%= include('../../../snippets/sso-integrations/ad-rms/7') %>
diff --git a/ja-jp/articles/integrations/sso/adobe-sign.md b/ja-jp/articles/integrations/sso/adobe-sign.md
new file mode 100644
index 0000000000..ade392a1f9
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/adobe-sign.md
@@ -0,0 +1,21 @@
+---
+title: Adobe Sign Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Adobe Sign and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - adobe
+  - sign
+  - echosign
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/adobe-sign/0') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/1') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/2') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/3') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/4') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/5') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/6') %> 
+<%= include('../../../snippets/sso-integrations/adobe-sign/7') %>
diff --git a/ja-jp/articles/integrations/sso/box.md b/ja-jp/articles/integrations/sso/box.md
new file mode 100644
index 0000000000..808a65ec41
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/box.md
@@ -0,0 +1,19 @@
+---
+title: Box Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Box and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - box
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/box/0') %> 
+<%= include('../../../snippets/sso-integrations/box/1') %> 
+<%= include('../../../snippets/sso-integrations/box/2') %> 
+<%= include('../../../snippets/sso-integrations/box/3') %> 
+<%= include('../../../snippets/sso-integrations/box/4') %> 
+<%= include('../../../snippets/sso-integrations/box/5') %> 
+<%= include('../../../snippets/sso-integrations/box/6') %>
+<%= include('../../../snippets/sso-integrations/box/7') %>
\ No newline at end of file
diff --git a/ja-jp/articles/integrations/sso/cisco-webex.md b/ja-jp/articles/integrations/sso/cisco-webex.md
new file mode 100644
index 0000000000..2619fcdd71
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/cisco-webex.md
@@ -0,0 +1,19 @@
+---
+title: Cisco WebEx Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Cisco WebEx and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - cisco-webex
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/cisco-webex/0') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/1') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/2') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/3') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/4') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/5') %> 
+<%= include('../../../snippets/sso-integrations/cisco-webex/6') %>
+<%= include('../../../snippets/sso-integrations/cisco-webex/7') %>
diff --git a/ja-jp/articles/integrations/sso/cloudbees.md b/ja-jp/articles/integrations/sso/cloudbees.md
new file mode 100644
index 0000000000..912c641323
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/cloudbees.md
@@ -0,0 +1,19 @@
+---
+title: CloudBees Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with CloudBees and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - cloudbees
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/cloudbees/0') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/1') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/2') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/3') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/4') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/5') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/6') %> 
+<%= include('../../../snippets/sso-integrations/cloudbees/7') %>
diff --git a/ja-jp/articles/integrations/sso/concur.md b/ja-jp/articles/integrations/sso/concur.md
new file mode 100644
index 0000000000..96a7527cca
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/concur.md
@@ -0,0 +1,19 @@
+---
+title: Concur Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Concur and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - concur
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/concur/0') %> 
+<%= include('../../../snippets/sso-integrations/concur/1') %> 
+<%= include('../../../snippets/sso-integrations/concur/2') %> 
+<%= include('../../../snippets/sso-integrations/concur/3') %> 
+<%= include('../../../snippets/sso-integrations/concur/4') %> 
+<%= include('../../../snippets/sso-integrations/concur/5') %> 
+<%= include('../../../snippets/sso-integrations/concur/6') %>
+<%= include('../../../snippets/sso-integrations/concur/7') %>
diff --git a/ja-jp/articles/integrations/sso/datadog.md b/ja-jp/articles/integrations/sso/datadog.md
new file mode 100644
index 0000000000..3cf7f55a83
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/datadog.md
@@ -0,0 +1,19 @@
+---
+title: Datadog Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Datadog and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - dropxbox
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/datadog/0') %> 
+<%= include('../../../snippets/sso-integrations/datadog/1') %> 
+<%= include('../../../snippets/sso-integrations/datadog/2') %> 
+<%= include('../../../snippets/sso-integrations/datadog/3') %> 
+<%= include('../../../snippets/sso-integrations/datadog/4') %> 
+<%= include('../../../snippets/sso-integrations/datadog/5') %> 
+<%= include('../../../snippets/sso-integrations/datadog/6') %> 
+<%= include('../../../snippets/sso-integrations/datadog/7') %>
diff --git a/ja-jp/articles/integrations/sso/disqus.md b/ja-jp/articles/integrations/sso/disqus.md
new file mode 100644
index 0000000000..def0e7328a
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/disqus.md
@@ -0,0 +1,169 @@
+---
+title: Disqus Single Sign-On Integration
+description: Learn how to set up Single Sign-on (SSO) integration with Disqus and Auth0.
+toc: true
+public: false
+topics:
+  - sso
+  - disqus
+contentType: how-to
+useCase: integrate-saas-sso
+---
+
+# Disqus Single Sign-On Integration
+
+Disqus allows you to embed a discussion section onto your site where your users can enter comments and interact with you and your other visitors. By implementing a Single Sign-on (SSO) integration between Disqus and Auth0, users that have signed in and authenticated via Auth0 can leave comments as themselves in your Disqus discussion section.
+
+## Install and Configure Disqus
+
+1. If you don't already have an account with Disqus, create one. If you do, log in.
+2. Select the **I want to install Disqus on my site** box.
+
+  ![](/media/articles/integrations/disqus/disqus-on-site.png)
+
+3. You will be directed to the *Create a new site* page. Provide your **Website Name** and your website's **Category**. When you've provided the requested information, click **Create Site** to continue.
+
+  ::: note
+  You **Website Name** will become your unique Disqus URL. Make note of this URL, since it is required to configure your Auth0 Application.
+  :::
+
+  ![](/media/articles/integrations/disqus/create-new-site.png)
+
+4. Select your site's platform to receive customized instructions on installing Disqus and embedding its UI onto your site. If the platform you're using isn't listed, select **I don't see my platform, install manually with Universal Code** at the bottom of the page.
+
+  ![](/media/articles/integrations/disqus/platforms.png)
+
+  When you have finished the installation process, click **Configure** to move on to the next step.
+
+5. Configure your Disqus installation by providing the requested information about your website. When done (or if you want to complete this at a later time using the *Settings* page), click **Complete Setup**.
+
+## Enable and Configure Single Sign-on with Disqus
+
+Once you have installed and configured your Disqus instance, you need to enable SSO.
+
+::: warning
+A Disqus Pro level subscription is required to use the [Disqus Single Sign-on (SSO) add-on](https://help.disqus.com/customer/portal/articles/236206-integrating-single-sign-on).
+:::
+
+1. Navigate to the [Applications section of the Disqus API](https://disqus.com/api/applications/) to register your application.
+
+  ![](/media/articles/integrations/disqus/register-api-app.png)
+
+2. Provide the requested details about your application. When complete, click **Register my application**.
+
+  ![](/media/articles/integrations/disqus/register.png)
+
+3. You will now see your Auth0 application listed in the Disqus Applications panel.
+
+  ![](/media/articles/integrations/disqus/register-api-app.png)
+
+4. Click on the [Single Sign-On](https://disqus.com/api/sso/) tab to go to the SSO management area where you will configure your remote domain and test the payload you create. Provide the following for your integration:
+
+  * **Name**: the name used to identify your domain
+  * **Slug**: the prefixed value for your account
+
+  **Notes**:
+
+  * Refrain from using any non-alphanumeric characters to prevent conflicts from happening. * The name assigned to your remote domain is permanent and non-transferable.
+  * You can have only one remote domain per user account, and you should use a single remote domain per site (created using the moderator account).
+
+  Click **Save Changes** when you're done.
+
+  ![](/media/articles/integrations/disqus/sso-config.png)
+
+5. Return to the *Settings* page of the *Applications* tab.
+6. Scroll to the *Settings* section and provide the following information:
+
+  * **Domains**: the domain(s) of the site in which you've embedded Disqus;
+  * **SSO Domain**: the Disqus account for which you have SSO enabled.
+
+  Under the *Authentication* section, provide the following information:
+
+  * **Default Access**: Set to *Read and Write*.
+
+  ![](/media/articles/integrations/disqus/disqus-app-settings.png)
+
+  When done, click **Save Changes**.
+
+6. At this point, SSO is fully configured for your Disqus account. You will now need to [finish configuring the integration](https://help.disqus.com/customer/portal/articles/236206-single-sign-on) from the Auth0 side.
+
+  ![](/media/articles/integrations/disqus/sso-config.png)
+
+## Integrate Disqus with Auth0
+
+At this point, you will embed code onto your site that will generate a secured message that is passed to Disqus.
+
+When you are signed in to Auth0, you have user information including (but not limited to):
+
+* `user_id`;
+* `username`;
+* `displayName`.
+
+You can host [server-side code](https://github.com/disqus/DISQUS-API-Recipes/tree/master/sso) that generates the secure authentication message to pass the user's data to Disqus. This message contains three parts, each of which is separated with a single whitespace character:
+
+* The message body in a JSON-serialized form;
+* The HMA-SHA1 signature;
+* The timestamp of the message.
+
+You can host this code server-side as a Node service that's protected by Auth0 so that only authorized entities can access it.
+
+```js
+var JSON = require('json3');
+var CryptoJS = require("crypto-js");
+var DISQUS_SECRET = "disqus_secret";
+var DISQUS_PUBLIC = "disqus_public";
+var data = disqusSignon();
+
+
+function disqusSignon() {
+  var disqusData = {
+    id: "auth0|577d19a858dd4da46509080'",
+    username: "test1234@gmail.com",
+    email: "test1234@gmail.com"
+  };
+
+  var disqusStr = JSON.stringify(disqusData);
+
+  var timestamp = Math.round(+new Date() / 1000);
+
+  var message = new Buffer(disqusStr).toString('base64');
+
+  /*
+   * CryptoJS (included in the directory) is required for hashing
+   * https://code.google.com/p/crypto-js/
+   */
+
+  var result = CryptoJS.HmacSHA1(message + " " + timestamp, DISQUS_SECRET);
+  var hexsig = CryptoJS.enc.Hex.stringify(result);
+
+  return {
+    pubKey: DISQUS_PUBLIC,
+    auth: message + " " + hexsig + " " + timestamp
+  };
+}
+```
+
+To complete the integration and pass the authentication data to Disqus, you'll need to add user-related entries to the `disqus_config` variable in your app's code.
+
+```js
+var disqus_config = function() {
+  // Replace PAGE_URL with your page's canonical URL variable
+  this.page.url = 'http://PAGE_URL.disqus.com';
+  this.page.identifier = '1234567';
+  this.page.title = 'Landing Page'
+
+  //Call the Node.js service to get auth data for user
+
+  /*
+  var user = {
+    pubKey : 'PUBLIC_KEY',
+    auth : message + " " + hexsig + " " + timestamp
+  }
+  */
+
+  this.page.remote_auth_s3 = user.auth;
+  this.page.api_key = user.pubKey;
+};
+```
+
+At this point, you will see the option to SSO using Disqus when authenticating in to your app.
diff --git a/ja-jp/articles/integrations/sso/dropbox.md b/ja-jp/articles/integrations/sso/dropbox.md
new file mode 100644
index 0000000000..8e4f2b3105
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/dropbox.md
@@ -0,0 +1,19 @@
+---
+title: Dropbox Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Dropbox and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - dropxbox
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/dropbox/0') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/1') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/2') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/3') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/4') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/5') %> 
+<%= include('../../../snippets/sso-integrations/dropbox/6') %>
+<%= include('../../../snippets/sso-integrations/dropbox/7') %>
diff --git a/ja-jp/articles/integrations/sso/dynamics-crm.md b/ja-jp/articles/integrations/sso/dynamics-crm.md
new file mode 100644
index 0000000000..70382fd3bc
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/dynamics-crm.md
@@ -0,0 +1,20 @@
+---
+title: Microsoft Dynamics CRM Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Microsoft Dynamics CRM and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - microsoft
+  - dynamics-crm
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/dynamics-crm/0') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/1') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/2') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/3') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/4') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/5') %> 
+<%= include('../../../snippets/sso-integrations/dynamics-crm/6') %>
+<%= include('../../../snippets/sso-integrations/dynamics-crm/7') %>
diff --git a/ja-jp/articles/integrations/sso/egencia.md b/ja-jp/articles/integrations/sso/egencia.md
new file mode 100644
index 0000000000..032d4f2031
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/egencia.md
@@ -0,0 +1,19 @@
+---
+title: Egencia Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Egencia and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - egencia
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/egencia/0') %> 
+<%= include('../../../snippets/sso-integrations/egencia/1') %> 
+<%= include('../../../snippets/sso-integrations/egencia/2') %> 
+<%= include('../../../snippets/sso-integrations/egencia/3') %> 
+<%= include('../../../snippets/sso-integrations/egencia/4') %> 
+<%= include('../../../snippets/sso-integrations/egencia/5') %> 
+<%= include('../../../snippets/sso-integrations/egencia/6') %>
+<%= include('../../../snippets/sso-integrations/egencia/7') %>
diff --git a/ja-jp/articles/integrations/sso/egnyte.md b/ja-jp/articles/integrations/sso/egnyte.md
new file mode 100644
index 0000000000..fd5395bcac
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/egnyte.md
@@ -0,0 +1,19 @@
+---
+title: Egnyte Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Egnyte and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - egnyte
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/egnyte/0') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/1') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/2') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/3') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/4') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/5') %> 
+<%= include('../../../snippets/sso-integrations/egnyte/6') %>
+<%= include('../../../snippets/sso-integrations/egnyte/7') %>
diff --git a/ja-jp/articles/integrations/sso/eloqua.md b/ja-jp/articles/integrations/sso/eloqua.md
new file mode 100644
index 0000000000..3c1fe2c7e2
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/eloqua.md
@@ -0,0 +1,19 @@
+---
+title: Eloqua Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Eloqua and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - eloqua
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/eloqua/0') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/1') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/2') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/3') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/4') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/5') %> 
+<%= include('../../../snippets/sso-integrations/eloqua/6') %>
+<%= include('../../../snippets/sso-integrations/eloqua/7') %>
diff --git a/ja-jp/articles/integrations/sso/freshdesk.md b/ja-jp/articles/integrations/sso/freshdesk.md
new file mode 100644
index 0000000000..46018221fe
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/freshdesk.md
@@ -0,0 +1,19 @@
+---
+title: Freshdesk Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Freshdesk and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - freshdesk
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/freshdesk/0') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/1') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/2') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/3') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/4') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/5') %> 
+<%= include('../../../snippets/sso-integrations/freshdesk/6') %>
+<%= include('../../../snippets/sso-integrations/freshdesk/7') %>
diff --git a/ja-jp/articles/integrations/sso/github-enterprise-cloud.md b/ja-jp/articles/integrations/sso/github-enterprise-cloud.md
new file mode 100644
index 0000000000..8ad8b8220d
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/github-enterprise-cloud.md
@@ -0,0 +1,19 @@
+---
+title: GitHub Enterprise Cloud Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with GitHub Enterprise Cloud and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - github-enterprise-cloud
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/0') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/1') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/2') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/3') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/4') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/5') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/6') %>
+<%= include('../../../snippets/sso-integrations/github-enterprise-cloud/7') %>
diff --git a/ja-jp/articles/integrations/sso/github-enterprise-server.md b/ja-jp/articles/integrations/sso/github-enterprise-server.md
new file mode 100644
index 0000000000..3a49e22ce5
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/github-enterprise-server.md
@@ -0,0 +1,19 @@
+---
+title: GitHub Enterprise Server Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with GitHub Enterprise Server and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - github-enterprise-server
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/0') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/1') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/2') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/3') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/4') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/5') %> 
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/6') %>
+<%= include('../../../snippets/sso-integrations/github-enterprise-server/7') %>
diff --git a/ja-jp/articles/integrations/sso/google-workspace.md b/ja-jp/articles/integrations/sso/google-workspace.md
new file mode 100644
index 0000000000..b9abad69f3
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/google-workspace.md
@@ -0,0 +1,19 @@
+---
+title: Google Workspace Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Google Workspace and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - Google Workspace
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/google-workspace/0') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/1') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/2') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/3') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/4') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/5') %> 
+<%= include('../../../snippets/sso-integrations/google-workspace/6') %>
+<%= include('../../../snippets/sso-integrations/google-workspace/7') %>
diff --git a/ja-jp/articles/integrations/sso/heroku.md b/ja-jp/articles/integrations/sso/heroku.md
new file mode 100644
index 0000000000..9ad96804fb
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/heroku.md
@@ -0,0 +1,19 @@
+---
+title: Heroku Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Heroku and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - heroku
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/heroku/0') %> 
+<%= include('../../../snippets/sso-integrations/heroku/1') %> 
+<%= include('../../../snippets/sso-integrations/heroku/2') %> 
+<%= include('../../../snippets/sso-integrations/heroku/3') %> 
+<%= include('../../../snippets/sso-integrations/heroku/4') %> 
+<%= include('../../../snippets/sso-integrations/heroku/5') %> 
+<%= include('../../../snippets/sso-integrations/heroku/6') %>
+<%= include('../../../snippets/sso-integrations/heroku/7') %>
diff --git a/ja-jp/articles/integrations/sso/hosted-graphite.md b/ja-jp/articles/integrations/sso/hosted-graphite.md
new file mode 100644
index 0000000000..e72168fcc7
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/hosted-graphite.md
@@ -0,0 +1,19 @@
+---
+title: Hosted Graphite Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Hosted Graphite and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - hosted-graphite
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/hosted-graphite/0') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/1') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/2') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/3') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/4') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/5') %> 
+<%= include('../../../snippets/sso-integrations/hosted-graphite/6') %>
+<%= include('../../../snippets/sso-integrations/hosted-graphite/7') %>
diff --git a/ja-jp/articles/integrations/sso/index.md b/ja-jp/articles/integrations/sso/index.md
new file mode 100644
index 0000000000..afe2efda39
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/index.md
@@ -0,0 +1,48 @@
+---
+title: Single Sign-On Integrations
+description: Learn about Auth0 Single Sign-on (SSO) Integrations.
+topics:
+  - sso
+contentType:
+  - index
+useCase: integrate-saas-sso
+---
+# Single Sign-On Integrations
+
+Single Sign-on (SSO) Integrations are client applications that enable the use of external services (e.g., Dropbox, Slack, or Zoom) for SSO. The integration allows your users to log in using Auth0's [identity providers](/identityproviders).
+
+Auth0 provides SSO Integrations for the following services:
+
+- [Active Directory RMS](/integrations/sso/ad-rms)
+- [Adobe Sign](/integrations/sso/adobe-sign)
+- [Box](/integrations/sso/box)
+- [Cisco WebEx](/integrations/sso/cisco-webex)
+- [CloudBees](/integrations/sso/cloudbees)
+- [Concur](/integrations/sso/concur)
+- [Datadog](/integrations/sso/datadog)
+- [Dropbox](/integrations/sso/dropbox)
+- [Dynamics CRM](/integrations/sso/dynamics-crm)
+- [Egencia](/integrations/sso/egencia)
+- [Egnyte](/integrations/sso/egnyte)
+- [Eloqua](/integrations/sso/eloqua)
+- [Freshdesk](/integrations/sso/freshdesk)
+- [Google Workspace](/integrations/sso/google-workspace)
+- [GitHub Enterprise Cloud](/integrations/sso/github-enterprise-cloud)
+- [GitHub Enterprise Server](/integrations/sso/github-enterprise-server)
+- [Heroku](/integrations/sso/heroku)
+- [Hosted Graphite](/integrations/sso/hosted-graphite)
+- [Litmos](/integrations/sso/litmos)
+- [New Relic](/integrations/sso/new-relic)
+- [Office 365](/integrations/sso/office-365)
+- [Pluralsight](/integrations/sso/pluralsight)
+- [Salesforce](/integrations/sso/salesforce)
+- [Sentry](/integrations/sso/sentry)
+- [Slack](/integrations/sso/slack)
+- [SpringCM](/integrations/sso/springcm)
+- [Sprout Video](/integrations/sso/sprout-video)
+- [Tableau Online](/integrations/sso/tableau-online)
+- [Tableau Server](/integrations/sso/tableau-server)
+- [Workday](/integrations/sso/workday)
+- [Workpath](/integrations/sso/workpath)
+- [Zendesk](/integrations/sso/zendesk)
+- [Zoom](/integrations/sso/zoom)
diff --git a/ja-jp/articles/integrations/sso/litmos.md b/ja-jp/articles/integrations/sso/litmos.md
new file mode 100644
index 0000000000..d29d7ccc42
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/litmos.md
@@ -0,0 +1,19 @@
+---
+title: Litmos Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Litmos and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - litmos
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/litmos/0') %> 
+<%= include('../../../snippets/sso-integrations/litmos/1') %> 
+<%= include('../../../snippets/sso-integrations/litmos/2') %> 
+<%= include('../../../snippets/sso-integrations/litmos/3') %> 
+<%= include('../../../snippets/sso-integrations/litmos/4') %> 
+<%= include('../../../snippets/sso-integrations/litmos/5') %> 
+<%= include('../../../snippets/sso-integrations/litmos/6') %>
+<%= include('../../../snippets/sso-integrations/litmos/7') %>
diff --git a/ja-jp/articles/integrations/sso/new-relic.md b/ja-jp/articles/integrations/sso/new-relic.md
new file mode 100644
index 0000000000..68fbf8906b
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/new-relic.md
@@ -0,0 +1,20 @@
+---
+title: New Relic Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with New Relic and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - new-relic
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/new-relic/0') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/1') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/2') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/3') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/4') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/5') %> 
+<%= include('../../../snippets/sso-integrations/new-relic/6') %>
+<%= include('../../../snippets/sso-integrations/new-relic/7') %>
+
diff --git a/ja-jp/articles/integrations/sso/office-365.md b/ja-jp/articles/integrations/sso/office-365.md
new file mode 100644
index 0000000000..155d016fdd
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/office-365.md
@@ -0,0 +1,19 @@
+---
+title: Office 365 Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Office 365 and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - office-365
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/office-365/0') %> 
+<%= include('../../../snippets/sso-integrations/office-365/1') %> 
+<%= include('../../../snippets/sso-integrations/office-365/2') %> 
+<%= include('../../../snippets/sso-integrations/office-365/3') %> 
+<%= include('../../../snippets/sso-integrations/office-365/4') %> 
+<%= include('../../../snippets/sso-integrations/office-365/5') %> 
+<%= include('../../../snippets/sso-integrations/office-365/6') %>
+<%= include('../../../snippets/sso-integrations/office-365/7') %>
diff --git a/ja-jp/articles/integrations/sso/pluralsight.md b/ja-jp/articles/integrations/sso/pluralsight.md
new file mode 100644
index 0000000000..48c55cfa21
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/pluralsight.md
@@ -0,0 +1,19 @@
+---
+title: Pluralsight Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Pluralsight and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - dropxbox
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/pluralsight/0') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/1') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/2') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/3') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/4') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/5') %> 
+<%= include('../../../snippets/sso-integrations/pluralsight/6') %>
+<%= include('../../../snippets/sso-integrations/pluralsight/7') %>
diff --git a/ja-jp/articles/integrations/sso/salesforce.md b/ja-jp/articles/integrations/sso/salesforce.md
new file mode 100644
index 0000000000..2946044f0f
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/salesforce.md
@@ -0,0 +1,19 @@
+---
+title: Salesforce Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Salesforce and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - salesforce
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/salesforce/0') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/1') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/2') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/3') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/4') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/5') %> 
+<%= include('../../../snippets/sso-integrations/salesforce/6') %>
+<%= include('../../../snippets/sso-integrations/salesforce/7') %>
diff --git a/ja-jp/articles/integrations/sso/sentry.md b/ja-jp/articles/integrations/sso/sentry.md
new file mode 100644
index 0000000000..5bf371deb2
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/sentry.md
@@ -0,0 +1,19 @@
+---
+title: Sentry Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Sentry and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - sentry
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/sentry/0') %> 
+<%= include('../../../snippets/sso-integrations/sentry/1') %> 
+<%= include('../../../snippets/sso-integrations/sentry/2') %> 
+<%= include('../../../snippets/sso-integrations/sentry/3') %> 
+<%= include('../../../snippets/sso-integrations/sentry/4') %> 
+<%= include('../../../snippets/sso-integrations/sentry/5') %> 
+<%= include('../../../snippets/sso-integrations/sentry/6') %>
+<%= include('../../../snippets/sso-integrations/sentry/7') %>
diff --git a/ja-jp/articles/integrations/sso/sharepoint.md b/ja-jp/articles/integrations/sso/sharepoint.md
new file mode 100644
index 0000000000..8fde6b36df
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/sharepoint.md
@@ -0,0 +1,19 @@
+---
+title: SharePoint Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with SharePoint and Auth0.
+toc: true
+public: false
+topics:
+  - sso
+  - sharepoint
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/sharepoint/0') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/1') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/2') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/3') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/4') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/5') %> 
+<%= include('../../../snippets/sso-integrations/sharepoint/6') %>
+<%= include('../../../snippets/sso-integrations/sharepoint/7') %>
diff --git a/ja-jp/articles/integrations/sso/slack.md b/ja-jp/articles/integrations/sso/slack.md
new file mode 100644
index 0000000000..7fff98bb76
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/slack.md
@@ -0,0 +1,23 @@
+---
+title: Slack Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Slack and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - slack
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/slack/0') %> 
+<%= include('../../../snippets/sso-integrations/slack/1') %> 
+<%= include('../../../snippets/sso-integrations/slack/2') %> 
+<%= include('../../../snippets/sso-integrations/slack/3') %> 
+<%= include('../../../snippets/sso-integrations/slack/4') %> 
+<%= include('../../../snippets/sso-integrations/slack/5') %> 
+<%= include('../../../snippets/sso-integrations/slack/6') %>
+<%= include('../../../snippets/sso-integrations/slack/7') %>
+
+::: note
+For more information, check out Slack's article on [enabling SAML-based Single Sign-on (SSO)](https://get.slack.help/hc/en-us/articles/203772216-Enabling-SAML-based-single-sign-on).
+:::
diff --git a/ja-jp/articles/integrations/sso/springcm.md b/ja-jp/articles/integrations/sso/springcm.md
new file mode 100644
index 0000000000..ca7ea7e521
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/springcm.md
@@ -0,0 +1,19 @@
+---
+title: SpringCM Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with SpringCM and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - springcm
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/springcm/0') %> 
+<%= include('../../../snippets/sso-integrations/springcm/1') %> 
+<%= include('../../../snippets/sso-integrations/springcm/2') %> 
+<%= include('../../../snippets/sso-integrations/springcm/3') %> 
+<%= include('../../../snippets/sso-integrations/springcm/4') %> 
+<%= include('../../../snippets/sso-integrations/springcm/5') %> 
+<%= include('../../../snippets/sso-integrations/springcm/6') %>
+<%= include('../../../snippets/sso-integrations/springcm/7') %>
diff --git a/ja-jp/articles/integrations/sso/sprout-video.md b/ja-jp/articles/integrations/sso/sprout-video.md
new file mode 100644
index 0000000000..9299a866ec
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/sprout-video.md
@@ -0,0 +1,19 @@
+---
+title: Sprout Video Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Sprout Video and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - sprout-video
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/sprout-video/0') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/1') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/2') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/3') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/4') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/5') %> 
+<%= include('../../../snippets/sso-integrations/sprout-video/6') %>
+<%= include('../../../snippets/sso-integrations/sprout-video/7') %>
diff --git a/ja-jp/articles/integrations/sso/tableau-online.md b/ja-jp/articles/integrations/sso/tableau-online.md
new file mode 100644
index 0000000000..89848db4c2
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/tableau-online.md
@@ -0,0 +1,19 @@
+---
+title: Tableau Online Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Tableau Online and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - tableau-online
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/tableau-online/0') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/1') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/2') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/3') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/4') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/5') %> 
+<%= include('../../../snippets/sso-integrations/tableau-online/6') %>
+<%= include('../../../snippets/sso-integrations/tableau-online/7') %>
diff --git a/ja-jp/articles/integrations/sso/tableau-server.md b/ja-jp/articles/integrations/sso/tableau-server.md
new file mode 100644
index 0000000000..648e77c4ab
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/tableau-server.md
@@ -0,0 +1,19 @@
+---
+title: Tableau Server Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Tableau Server and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - tableau-server
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/tableau-server/0') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/1') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/2') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/3') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/4') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/5') %> 
+<%= include('../../../snippets/sso-integrations/tableau-server/6') %>
+<%= include('../../../snippets/sso-integrations/tableau-server/7') %>
diff --git a/ja-jp/articles/integrations/sso/workday.md b/ja-jp/articles/integrations/sso/workday.md
new file mode 100644
index 0000000000..d77f02f586
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/workday.md
@@ -0,0 +1,19 @@
+---
+title: Workday Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Workday and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - workday
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/workday/0') %> 
+<%= include('../../../snippets/sso-integrations/workday/1') %> 
+<%= include('../../../snippets/sso-integrations/workday/2') %> 
+<%= include('../../../snippets/sso-integrations/workday/3') %> 
+<%= include('../../../snippets/sso-integrations/workday/4') %> 
+<%= include('../../../snippets/sso-integrations/workday/5') %> 
+<%= include('../../../snippets/sso-integrations/workday/6') %>
+<%= include('../../../snippets/sso-integrations/workday/7') %>
diff --git a/ja-jp/articles/integrations/sso/workpath.md b/ja-jp/articles/integrations/sso/workpath.md
new file mode 100644
index 0000000000..6857d56b43
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/workpath.md
@@ -0,0 +1,19 @@
+---
+title: Workpath Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Workpath and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - workpath
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/workpath/0') %> 
+<%= include('../../../snippets/sso-integrations/workpath/1') %> 
+<%= include('../../../snippets/sso-integrations/workpath/2') %> 
+<%= include('../../../snippets/sso-integrations/workpath/3') %> 
+<%= include('../../../snippets/sso-integrations/workpath/4') %> 
+<%= include('../../../snippets/sso-integrations/workpath/5') %> 
+<%= include('../../../snippets/sso-integrations/workpath/6') %>
+<%= include('../../../snippets/sso-integrations/workpath/7') %>
diff --git a/ja-jp/articles/integrations/sso/zendesk.md b/ja-jp/articles/integrations/sso/zendesk.md
new file mode 100644
index 0000000000..f4409ec17d
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/zendesk.md
@@ -0,0 +1,19 @@
+---
+title: Zendesk Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Zendesk and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - zendesk
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/zendesk/0') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/1') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/2') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/3') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/4') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/5') %> 
+<%= include('../../../snippets/sso-integrations/zendesk/6') %>
+<%= include('../../../snippets/sso-integrations/zendesk/7') %>
diff --git a/ja-jp/articles/integrations/sso/zoom.md b/ja-jp/articles/integrations/sso/zoom.md
new file mode 100644
index 0000000000..c987b3d838
--- /dev/null
+++ b/ja-jp/articles/integrations/sso/zoom.md
@@ -0,0 +1,19 @@
+---
+title: Zoom Single Sign-On Integration
+description: Learn how to set up a Single Sign-on (SSO) integration with Zoom and Auth0.
+toc: true
+public: true
+topics:
+  - sso
+  - zoom
+contentType: how-to
+useCase: integrate-saas-sso
+---
+<%= include('../../../snippets/sso-integrations/zoom/0') %> 
+<%= include('../../../snippets/sso-integrations/zoom/1') %> 
+<%= include('../../../snippets/sso-integrations/zoom/2') %> 
+<%= include('../../../snippets/sso-integrations/zoom/3') %> 
+<%= include('../../../snippets/sso-integrations/zoom/4') %> 
+<%= include('../../../snippets/sso-integrations/zoom/5') %> 
+<%= include('../../../snippets/sso-integrations/zoom/6') %>
+<%= include('../../../snippets/sso-integrations/zoom/7') %>
diff --git a/ja-jp/articles/integrations/using-auth0-to-secure-a-cli.md b/ja-jp/articles/integrations/using-auth0-to-secure-a-cli.md
new file mode 100644
index 0000000000..deacfe2ad6
--- /dev/null
+++ b/ja-jp/articles/integrations/using-auth0-to-secure-a-cli.md
@@ -0,0 +1,44 @@
+---
+title: Secure a CLI with Auth0
+description: How to use Auth0 to secure a CLI.
+topics:
+  - integrations
+  - cli
+contentType: how-to
+useCase: 
+  - integrate-saas-sso
+  - cli-authentication
+  - 
+---
+
+# Secure a CLI with Auth0
+
+There are three ways to secure a CLI with Auth0 in order of most secure to least secure:
+
+* [Device Authorization Flow](#device-authorization-flow)
+* [Client Credentials Grant Flow](#client-credentials-grant-flow)
+* [Resource Owner Password Grant Flow](#resource-owner-password-grant-flow) (not recommended)
+
+The first two options are for user-based authentication, whereas the third option is only when you're attempting to authenticate the CLI client itself, which is a very rare situation.
+
+## Device Authorization Flow
+
+With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device. This avoids a poor user experience for devices that do not have an easy way to enter text. To do this, device apps use the Device Authorization Flow (drafted in [OAuth 2.0](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15)), in which they pass along their Client ID to initiate the authorization process and get a token.
+
+The easiest way to implement the [Device Authorization Flow](/flows/concepts/device-auth) is to follow the steps in [Call API Using Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth).
+
+## Client Credentials Grant Flow
+
+Use the Client Credentials Grant (CCG) flow when users and downstream identity providers aren't involved and you want to authenticate based on distinct machines or devices.
+
+If your identity provider supports sending credentials, then you should use the [Client Credentials Flow](/flows/concepts/client-credentials). For details on how to implement this, refer to [Call API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials).
+
+## Resource Owner Password Grant Flow
+
+We do not recommend using the Resource Owner Password Grant (ROPG) flow for native applications. In the [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252) from the Internet Engineering Task Force (IETF), it is recommended that “OAuth 2.0 authorization request from native apps should ONLY be made through external user-agents, primarily the user’s browser”. For details, see [RFC 8252 Embedded User-Agents](https://tools.ietf.org/html/rfc8252#section-8.12).
+
+Using Resource Owner Password Grant (ROPG) are less secure than the redirect-based options described above. ROPG is only for legacy. In the context of CLIs, it only makes sense for things like connection strings where you need to support legacy programs.
+
+::: note
+If you must use ROPG in your native app instead of Device Flow as we recommend, then you can use our [OIDC compliant ROPG endpoint](/api/authentication#resource-owner-password).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/_includes/_change_get_profile.md b/ja-jp/articles/libraries/_includes/_change_get_profile.md
new file mode 100644
index 0000000000..96838117ae
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_change_get_profile.md
@@ -0,0 +1,5 @@
+### Change calls to getProfile()
+
+The deprecated `getProfile()` function was reimplemented in Lock 11. The previous implementation received an [ID Token](/tokens/concepts/id-tokens) as a parameter and returned the user profile. 
+
+The new implementation requires an Access Token parameter instead.
diff --git a/ja-jp/articles/libraries/_includes/_configure_custom_domain.md b/ja-jp/articles/libraries/_includes/_configure_custom_domain.md
new file mode 100644
index 0000000000..5a98890df2
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_configure_custom_domain.md
@@ -0,0 +1,29 @@
+### Configure your custom domain
+
+1. Ensure that your application updates are made prior to setting up custom domains in your application, as the older versions of ${library} will not work when configured with a custom domain.
+
+2. Set up your [custom domain](/custom-domains) in the Auth0 [Dashboard](${manage_url}/#/tenant).
+
+3. Use the custom domain when instantiating Lock.
+
+```
+var lock = new Auth0Lock('${account.clientId}', 'login.your-domain.com', options);
+```
+
+4. Set the `configurationBaseUrl` option to `https://cdn.us.auth0.com`.
+
+```
+var options = {
+  configurationBaseUrl: 'https://cdn.us.auth0.com'
+};
+```
+
+::: note
+The CDN URL varies by region. Tenants created before 11 June 2020 should use `https://cdn.auth0.com` if the region is the United States, or add `eu` or `au` for Europe or Australia. If your tenant was created after 11 June 2020, use `https://cdn.us.auth0.com` if the region is the United States. 
+:::
+
+#### Management Application
+
+If you intend to use the Auth0.js `auth0.Management` to get user information or perform account linking operations, you will need to instantiate a new Auth0 object with the Auth0 domain rather than your custom domain. The Management API only accepts Auth0 domains. 
+
+See the Auth0.js documentation on [user management](/libraries/auth0js/v9#user-management) for more information on using the Management API in Auth0.js.
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/_includes/_configure_embedded_login.md b/ja-jp/articles/libraries/_includes/_configure_embedded_login.md
new file mode 100644
index 0000000000..3585ca28f0
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_configure_embedded_login.md
@@ -0,0 +1,7 @@
+### Configure your Auth0 application for embedded login
+
+When implementing embedded login, ${library} will use cross-origin calls inside hidden iframes to perform authentication. To make sure this can be done securely, Auth0 needs to know the domains where you will be hosting your applications.
+
+Add the domain to the **Allowed Web Origins** field. You can find this field in the [Application Settings](${manage_url}/#/application/${account.clientId}/settings) area of your Dashboard.
+
+![Allowed Web Origins](/media/articles/libraries/lock/allowed-origins.png)
diff --git a/ja-jp/articles/libraries/_includes/_default_values.md b/ja-jp/articles/libraries/_includes/_default_values.md
new file mode 100644
index 0000000000..48b1b9eff4
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_default_values.md
@@ -0,0 +1,11 @@
+### Default values
+
+Auth0.js v9 will default the value of the scope parameter to `openid profile email`.
+
+If you are running your website from `http://localhost` or `http://127.0.0.1` and you do not specify the `openid profile email` scope when initializing auth0.js, calling the `getSSOData()` method will result in the following error in the browser console:
+
+```text
+Consent required. When using `getSSOData`, the user has to be authenticated with the following scope: `openid profile email`
+```
+
+This will not happen when you run your application in production, or if you specify the required [scope](/scopes). You can read more about this scenario in the documentation on [skipping consent for first-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications).
diff --git a/ja-jp/articles/libraries/_includes/_default_values_lock.md b/ja-jp/articles/libraries/_includes/_default_values_lock.md
new file mode 100644
index 0000000000..b66229d099
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_default_values_lock.md
@@ -0,0 +1,11 @@
+### Default values
+
+Lock 11 will default the scope parameter to `'openid profile email'`. This is to make the **Last time you logged in with** window work correctly.
+
+If you are running your website from `http://localhost` or `http://127.0.0.1` and you do not specify the `openid profile email` scope when initializing Lock, you may get the following error in the browser console:
+
+```text
+Consent required. When using `getSSOData`, the user has to be authenticated with the following scope: `openid profile email`
+```
+
+This will not happen when you run your application in production, or if you specify the required [scope](/scopes). You can read more about this scenario in the documentation on [skipping consent for first-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications).
diff --git a/ja-jp/articles/libraries/_includes/_embedded_sso.md b/ja-jp/articles/libraries/_includes/_embedded_sso.md
new file mode 100644
index 0000000000..bd379358ae
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_embedded_sso.md
@@ -0,0 +1,10 @@
+### Single Sign-On with embedded authentication
+
+Apps with embedded login must meet two criteria in order to have Single Sign-on (SSO).
+
+1. Both of the applications attempting SSO must be first-party applications. SSO with third-party applications will not work.
+1. They need to make use of [custom domains](/custom-domains) and have both the applications which intend to have SSO as well as the Auth0 tenant on the same domain. Traditionally, Auth0 domains are in the format `foo.auth0.com`, but custom domains allow you to use the same domain for each of the applications in question as well as your Auth0 tenant, preventing the risk of CSRF attacks.
+
+::: note
+Our recommendation is to use Universal Login instead of setting up SSO in embedded login scenarios. Universal Login is the most reliable and stable way to perform SSO, and is the only way to do so if you must use multiple domains for your applications, or use [third-party applications](/applications/guides/enable-third-party-apps).
+:::
diff --git a/ja-jp/articles/libraries/_includes/_get_auth0_js_latest_version.md b/ja-jp/articles/libraries/_includes/_get_auth0_js_latest_version.md
new file mode 100644
index 0000000000..c372c1c25b
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_get_auth0_js_latest_version.md
@@ -0,0 +1,23 @@
+### Update auth0.js
+
+Update the Auth0.js library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save auth0-js
+
+# installation with yarn
+yarn add auth0-js
+```
+
+Once updated, you can add it to your build system or bring it in to your project with a script tag.
+
+```html
+
+```
+
+If you do not want to use a package manager, you can retrieve Auth0.js from Auth0's CDN.
+
+```html
+
+```
diff --git a/ja-jp/articles/libraries/_includes/_get_lock_latest_version.md b/ja-jp/articles/libraries/_includes/_get_lock_latest_version.md
new file mode 100644
index 0000000000..8f775a2240
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_get_lock_latest_version.md
@@ -0,0 +1,23 @@
+### Update Lock
+
+Update the Lock library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save auth0-lock
+
+# installation with yarn
+yarn add auth0-lock
+```
+
+Once updated, you can add it to your build system or bring it in to your project with a script tag.
+
+```html
+
+```
+
+If you do not want to use a package manager, you can retrieve Lock from Auth0's CDN.
+
+```html
+
+```
diff --git a/ja-jp/articles/libraries/_includes/_ip_ranges.md b/ja-jp/articles/libraries/_includes/_ip_ranges.md
new file mode 100644
index 0000000000..b3813c37ce
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_ip_ranges.md
@@ -0,0 +1,7 @@
+### Single sign-on using IP ranges
+
+In earlier versions of Lock, you could configure an IP range in an Active Directory/LDAP connection. You could then use that range to allow integrated Windows Authentication if the user's IP was within the range. When this was true, Lock would display a button that users could click and get redirected to the integrated authentication dialog.
+
+![SSO With Lock 10 and Windows IP Ranges](/media/articles/libraries/lock/lock-11-windows-authentication.png)
+
+This functionality has been removed from embedded login using Lock 11. There is no IP detection, and the user will need to type user and password in Lock. It is still available when using Universal Login.
diff --git a/ja-jp/articles/libraries/_includes/_last_logged_in_window.md b/ja-jp/articles/libraries/_includes/_last_logged_in_window.md
new file mode 100644
index 0000000000..696166ebfb
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_last_logged_in_window.md
@@ -0,0 +1,9 @@
+### Last time you logged in with window with authorization code flow
+
+Lock 11 will never show the **Last time you logged in with** window when using the [Authorization Code Flow](/flows/concepts/auth-code) (that is, when specifying `response_type='code'`). It will always prompt for credentials.
+
+### Last time you logged in with window and redirects
+
+The **Last time you logged in with** window will never do a redirect, even when the `redirect` option is set to `true`. Lock11 still emits the `authenticated` event and you should subscribe to that event to [get the authentication result](/libraries/lock/v11#2-authenticating-and-getting-user-info).
+
+If you want to avoid showing the Lock dialog when there's an existing session in the server, you can use Auth0.js's [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) function.
diff --git a/ja-jp/articles/libraries/_includes/_legacy_flows.md b/ja-jp/articles/libraries/_includes/_legacy_flows.md
new file mode 100644
index 0000000000..b6793b4966
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_legacy_flows.md
@@ -0,0 +1,5 @@
+### Migrating from legacy authentication flows
+
+The OIDC conformant flows disallow certain practices that were common when developing applications with older versions of the library, like using Refresh Tokens, using [ID Tokens](/tokens/concepts/id-tokens) to call APIs, and [accessing non-standard claims in the user profile](/api-auth/tutorials/adoption/scope-custom-claims).
+
+Follow the steps in the [Migration from Legacy Authentication Flows](guides/migration-legacy-flows) to learn what changes you need to make in your application.
diff --git a/ja-jp/articles/libraries/_includes/_migrate_universal.md b/ja-jp/articles/libraries/_includes/_migrate_universal.md
new file mode 100644
index 0000000000..c43bcae9f8
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_migrate_universal.md
@@ -0,0 +1,3 @@
+::: note
+If you do not have the ability to use [custom domains](/custom-domains) or prefer not to use them, and your application currently uses embedded login, the best migration path is to [migrate to Universal Login](/guides/login/migration-embedded-universal).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/_includes/_oidc_conformant.md b/ja-jp/articles/libraries/_includes/_oidc_conformant.md
new file mode 100644
index 0000000000..ec12a82cf5
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_oidc_conformant.md
@@ -0,0 +1,5 @@
+### Remove the oidcConformant parameter
+
+When the `oidcConformant` flag was set to true, Lock 10 used [Cross Origin Authentication](/cross-origin-authentication), and did not use the '/usernamepassword/login' and '/ssodata' endpoints.
+
+Given Lock 11 always uses Cross Origin Authentication and does not use the '/ssodata' endpoint, this flag is not longer needed. If specified, it will be ignored.
diff --git a/ja-jp/articles/libraries/_includes/_popup_mode.md b/ja-jp/articles/libraries/_includes/_popup_mode.md
new file mode 100644
index 0000000000..6de2c95a77
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_popup_mode.md
@@ -0,0 +1,3 @@
+### Usage in popup mode
+
+When using [popup mode](libraries/lock/authentication-modes#popup-mode) in previous versions of Lock, a new browser window was opened and immediately closed in order to complete the authentication transaction. In Lock 11, that window is opened on a hidden iframe, providing a better user experience. 
diff --git a/ja-jp/articles/libraries/_includes/_review_get_ssodata.md b/ja-jp/articles/libraries/_includes/_review_get_ssodata.md
new file mode 100644
index 0000000000..509974a67a
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_review_get_ssodata.md
@@ -0,0 +1,26 @@
+### Review calls to getSSOData()
+
+The deprecated `getSSOData()` function was reimplemented in Auth0.js v9 to simplify migration from older versions, but the behavior is not exactly the same. 
+
+The function will not work as expected when you use it in Web Applications that use the [Authorization Code Flow](/flows/concepts/auth-code) (such as when you specify `response_type='code'`). It will always return that there is not a current session.
+
+If you want to avoid showing the Lock dialog when there is an existing session in the server, you can use the [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) function in Auth0.js.
+
+We recommend that you do not use `getSSOData()` and use [checkSession()](/libraries/auth0js#using-checksession-to-acquire-new-tokens) instead. Note that in order for `checkSession()` to work properly, it requires that you set the **Allowed Web Origins** field in the dashboard.
+
+::: note
+Note that `checkSession()` triggers any [rules](/rules) you may have set up, whereas `getSSOData()` does not. It is possible that this could cause unintended behavior depending on what rules you have set up (if any) so you should check on your rules in the [Dashboard](${manage_url}/#/rules) prior to switching methods.
+:::
+
+If you are going to keep using `getSSOData()`, take into account the changes in the return values described in the table below. In most applications, the only value that was actually used was the `sso` property, which still has the same semantics. 
+
+| **Property** | **Old Value** | **New Value** |
+| --- | --- | --- |
+| sso | `true` if user has an existing session, `false` if not | The same |
+| sessionClients | List of applications ids the user has active sessions with | List with a single element with the client id configured in auth0.js |
+| lastUsedClientId | The client id for the last active connection | The last application used when authenticating from the current browsers |
+| lastUsedUserId | The user id for the current session | The same  |
+| lastUsedUsername | User's email or name | The same (requires `scope=’openid profile email’)` |
+| lastUsedConnection | Last used connection and strategy. | Last connection used when authenticated from the current browser. It will be `null` if the user authenticated via Universal Login. It will not return `strategy`, only `name` |
+
+For the function to work properly, you need to ask for `scope='openid profile email'` when you initialize Auth0.js.
diff --git a/ja-jp/articles/libraries/_includes/_spa_js_faq.md b/ja-jp/articles/libraries/_includes/_spa_js_faq.md
new file mode 100644
index 0000000000..0595e4e5fb
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_spa_js_faq.md
@@ -0,0 +1,5 @@
+
+
+::: note
+If you encounter some problems or errors when using the new JavaScript SDK, please [check out the FAQ](https://github.com/auth0/auth0-spa-js/blob/master/FAQ.md) to see if your issue is covered there.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/_includes/_verifying_migration.md b/ja-jp/articles/libraries/_includes/_verifying_migration.md
new file mode 100644
index 0000000000..a4edd88b3c
--- /dev/null
+++ b/ja-jp/articles/libraries/_includes/_verifying_migration.md
@@ -0,0 +1,12 @@
+### Verifying your migration
+
+Once you have migrated your codebase, you should no longer see [deprecation notes in your logs](/troubleshoot/guides/check-deprecation-errors).
+
+If you would like to be sure that your applications are no longer calling the legacy endpoints, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy Lock API switch. Turning off this switch will disable the deprecated Lock / Auth0.js endpoints for your tenant, preventing them from being used at all.
+
+![Legacy Lock API](/media/articles/libraries/lock/migration-toggles.png)
+
+After disabling this switch, if the Legacy Lock API errors in your logs do not clear up or if turning it off results in failed logins, this is a sign that you have yet to completely remove all instances of legacy code from your applications.
+
+Once migrations have been successfully performed in production environments, the switch can be toggled off and left off, to ensure that the deprecated features can no longer be used.
+
diff --git a/ja-jp/articles/libraries/auth0-android/configuration.md b/ja-jp/articles/libraries/auth0-android/configuration.md
new file mode 100644
index 0000000000..08e87aef3f
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/configuration.md
@@ -0,0 +1,116 @@
+---
+section: libraries
+toc: true
+description: How to configure Auth0.Android to meet your application's needs
+topics:
+  - libraries
+  - android
+contentType: how-to
+useCase: enable-mobile-auth
+---
+# Auth0.Android Configuration Options
+
+Auth0.Android can be configured with a variety of options, listed below.
+
+## withConnection
+
+The `withConnection` option allows you to specify a connection that you wish to authenticate with.
+
+```java
+WebAuthProvider.login(account)
+                .withConnection("twitter")
+                .start(this, authCallback);
+```
+
+## useCodeGrant
+
+Code grant is the default mode, and will always be used unless calling `useCodeGrant` with `false`, or unless the device doesn't support the signing/hashing algorithms.
+
+Before you can use `Code Grant` in Android, make sure to go to your [Dashboard](${manage_url}/#/applications) and check in the application's settings that `Application Type` is `Native`.
+
+```java
+WebAuthProvider.login(account)
+                .useCodeGrant(true)
+                .start(this, authCallback);
+```
+
+## withScope
+
+Using scopes can allow you to return specific claims for specific fields in your request. Adding parameters to `withScope` will allow you to add more scopes. You should read our [documentation on scopes](/scopes) for further details about them.
+
+```java
+WebAuthProvider.login(account)
+                .withScope("openid email profile")
+                .start(this, authCallback);
+```
+
+::: panel Scope
+Note that the default scope used is `openid`
+:::
+
+## withConnectionScope
+
+There may be times when you need to authenticate with particular connection scopes, or permissions, from the Authentication Provider in question. Auth0 has [documentation on setting up connection scopes for external Authentication Providers](/connections/adding-scopes-for-an-external-idp). However, if you need specific access for a particular situation in your app you can do so by passing parameters to `withConnectionScope`. A full listing of available parameters can be found in that connection's settings in your [Dashboard](${manage_url}), or from the Authentication Providers's documentation. The scope requested here is added on top of the ones specified in the connection's settings in the Dashboard.
+
+```java
+WebAuthProvider.login(account)
+                .withConnectionScope("email", "profile", "calendar:read")
+                .start(this, authCallback);
+```
+
+## withParameters
+
+To send additional parameters on the authentication, use `withParameters`:
+
+```java
+Map parameters = new HashMap<>();
+//Add entries
+WebAuthProvider.login(account)
+                .withParameters(parameters)
+                .start(this, authCallback);
+```
+
+## withScheme
+
+If you are not using Android "App Links" or you want to use a different scheme for the redirect URI, then use `withScheme`. Note that you'll need to update the `auth0Scheme` Manifest Placeholder in the `app/build.gradle` file and the whitelisted **Allowed Callback URLs** on the [Dashboard](${manage_url}) in the Application's settings to match the chosen scheme.
+
+```java
+WebAuthProvider.login(account)
+                .withScheme("myapp")
+                .start(this, authCallback);
+```
+
+::: note
+Scheme must be lowercase!
+:::
+
+## withAudience
+
+To provide an audience, use `withAudience`.
+
+```java
+WebAuthProvider.login(account)
+                .withScope("openid")
+                .withAudience("https://${account.namespace}/userinfo")
+                .start(this, authCallback);
+```
+
+## withState
+
+By default a random [state](/protocols/oauth2/oauth-state) is always generated and sent. If you need to use a custom value instead, use `withState`:
+
+```java
+WebAuthProvider.login(account)
+                .withState("my-custom-state")
+                .start(this, authCallback);
+```
+
+## withNonce
+
+By default a random nonce is generated and sent when the response type includes `id_token`. If you need to use a custom value instead, use `withNonce`:
+
+```java
+WebAuthProvider.login(account)
+                .withNonce("my-custom-nonce")
+                .start(this, authCallback);
+```
diff --git a/ja-jp/articles/libraries/auth0-android/database-authentication.md b/ja-jp/articles/libraries/auth0-android/database-authentication.md
new file mode 100644
index 0000000000..430ed70c91
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/database-authentication.md
@@ -0,0 +1,64 @@
+---
+section: libraries
+toc: true
+description: How to use Auth0.Android with database connections
+topics:
+  - libraries
+  - android
+  - db-connections
+contentType: how-to
+useCase: enable-mobile-auth
+---
+# Auth0.Android Database Authentication
+
+::: panel-warning Database authentication on Native Platforms
+Username/Email & Password authentication from native applications is disabled by default for new tenants as of 8 June 2017. Users are encouraged to use Universal Login and perform Web Authentication instead. If you still want to proceed you'll need to enable the Password Grant Type on your dashboard first. See [Application Grant Types](/applications/concepts/application-grant-types) for more information.
+:::
+
+## Log in with a database connection
+
+To log in with a database connection, call `login` with the user's **email**, **password**, and the **connection** you wish to authenticate with. The response will be a Credentials object. 
+
+Additionally, specifying the **audience** will yield an OIDC-conformant response during authentication.
+
+```java
+authentication
+    .login("info@auth0.com", "a secret password", "my-database-connection")
+    .setAudience("https://${account.namespace}/userinfo")
+    .start(new BaseCallback() {
+        @Override
+        public void onSuccess(Credentials payload) {
+            //Logged in!
+        }
+
+        @Override
+        public void onFailure(AuthenticationException error) {
+            //Error!
+        }
+    });
+```
+
+::: note
+The default scope used is `openid`.
+:::
+
+## Sign up with database connection
+
+To sign up with a database connection you have to call the `signUp` method, passing the user's email, password, and connection name.
+
+```java
+authentication
+    .signUp("info@auth0.com", "a secret password", "my-database-connection")
+    .setAudience("https://${account.namespace}/userinfo")
+    .start(new BaseCallback() {
+        @Override
+        public void onSuccess(Credentials payload) {
+            //Signed Up & Logged in!
+        }
+
+        @Override
+        public void onFailure(AuthenticationException error) {
+            //Error!
+        }
+    });
+```
diff --git a/ja-jp/articles/libraries/auth0-android/index.md b/ja-jp/articles/libraries/auth0-android/index.md
new file mode 100644
index 0000000000..adfdcc3f4d
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/index.md
@@ -0,0 +1,219 @@
+---
+section: libraries
+toc: true
+description: How to install, initialize and use Auth0.Android
+url: /libraries/auth0-android
+topics:
+  - libraries
+  - android
+contentType:
+    - how-to
+    - index
+useCase: enable-mobile-auth
+---
+# Auth0.Android
+
+Auth0.Android is a client-side library you can use with your Android app to authenticate users and access [Auth0 APIs](/api/info).
+
+::: note
+Check out the [Auth0.Android repository](https://github.com/auth0/Auth0.Android) on GitHub.
+:::
+
+## Requirements
+
+Android API version 15 or newer is required.
+
+## Installation
+
+<%= include('../../quickstart/native/android/_includes/_gradle.md') %>
+
+## Permissions
+
+Open your app's `AndroidManifest.xml` file and add the following permission.
+
+```xml
+
+```
+
+## Initialize Auth0
+
+Save your application information in the `strings.xml` file using the following names:
+
+```xml
+
+    ${account.clientId}
+    ${account.namespace}
+
+
+```
+
+And then create your new Auth0 instance by passing an Android Context:
+
+```java
+Auth0 account = new Auth0(context);
+```
+
+## OIDC Conformant Mode
+
+It is strongly encouraged that this SDK be used in [OIDC Conformant mode](/api-auth/intro). When this mode is enabled, it will force the SDK to use Auth0's current authentication methods and will prevent it from reaching legacy endpoints. By default is `false`.
+
+```java
+Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
+//Configure the account in OIDC conformant mode
+account.setOIDCConformant(true);
+//Use the account in the API applications
+```
+
+## Authentication via Universal Login
+
+First, go to the [Dashboard](${manage_url}/#/applications) and go to your application's settings. Make sure you have in **Allowed Callback URLs** a URL with the following format:
+
+```
+https://${account.namespace}/android/{YOUR_APP_PACKAGE_NAME}/callback
+```
+
+::: note
+Replace `{YOUR_APP_PACKAGE_NAME}` with your actual application's package name, available in your `app/build.gradle` file as the `applicationId` value.
+:::
+
+Then in your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI.
+
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    compileSdkVersion 25
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 15
+        targetSdkVersion 25
+        //...
+
+        //---> Add the next line
+        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"]
+        //<---
+    }
+    //...
+}
+```
+
+::: note
+It's a good practice to define reusable resources like `@string/com_auth0_domain` (as done in a previous step with `strings.xml`) rather than just hard-coding them.
+:::
+
+Alternatively, you can declare the `RedirectActivity` in the `AndroidManifest.xml` file with your own **intent-filter** so it overrides the library's default. If you do this then the Manifest Placeholders don't need to be set as long as the activity declaration contains the `tools:node="replace"` attribute:
+
+```xml
+
+    
+
+        
+
+        
+            
+                
+                
+                
+                /callback"
+                    android:scheme="https" />
+            
+        
+
+        
+
+    
+
+```
+
+Finally, don't forget to add the internet permission:
+
+```xml
+
+```
+
+::: note
+In versions 1.8.0 or lower of Auth0.Android you had to define the **intent-filter** inside your activity to capture the authentication result in the `onNewIntent` method and then call `WebAuthProvider.resume()` with the received data. The intent-filter declaration and resume call are no longer required for versions greater than 1.8.0, as it's now done internally by the library for you.
+:::
+
+Now, let's authenticate a user by presenting the universal [login page](/universal-login):
+
+```java
+WebAuthProvider.login(account)
+                .withAudience("https://${account.namespace}/userinfo")
+                .start(this, authCallback);
+```
+
+The authentication result will be delivered to the callback.
+
+To ensure a response that complies with OpenID Connect (OIDC), you must either set an `audience` using [withAudience](/libraries/auth0-android/configuration#withAudience) or enable the **OIDC Conformant** switch in your Auth0 dashboard under **Dashboard > Settings > Advanced > OAuth**. You can read more about this in the documentation page on [how to use new flows](/api-auth/intro#how-to-use-the-new-flows).
+
+## Using the Authentication API
+
+The Authentication Application provides methods to accomplish authentication and related tasks. Create a new instance by passing in the Auth0 object created in the previous step.
+
+```java
+AuthenticationAPIClient authentication = new AuthenticationAPIClient(account);
+```
+
+### Get user information
+
+To get the information associated with a given user's Access Token, you can call the `userInfo` endpoint, passing the token.
+
+```java
+authentication
+  .userInfo("Access Token")
+  .start(new BaseCallback() {
+      @Override
+      public void onSuccess(UserProfile information) {
+          //user information received
+      }
+
+      @Override
+      public void onFailure(AuthenticationException error) {
+          //user information request failed
+      }
+  });
+```
+
+### Password Resets
+
+To initiate a password reset for a user, call `resetPassword` with the user's email address and the database connection name as parameters.
+
+```java
+String connectionName = "Username-Password-Authentication";
+authentication
+  .resetPassword("foo@bar.com", connectionName)
+  .start(new AuthenticationCallback() {
+    @Override
+    public void onSuccess(Void payload) {
+      //Password Reset requested
+    }
+
+    @Override
+    public void onFailure(AuthenticationException error) {
+      //Request failed
+    }
+  });
+```
+
+::: note
+Password reset requests will fail on network related errors, but will not fail if the designated email does not exist in the database (for security reasons).
+:::
+
+## Next Steps
+
+Take a look at the following resources to see how the Auth0.Android SDK can be customized for your needs:
+
+::: next-steps
+* [Auth0.Android Configuration Options](/libraries/auth0-android/configuration)
+* [Auth0.Android Database Authentication](/libraries/auth0-android/database-authentication)
+* [Auth0.Android Passwordless Authentication](/libraries/auth0-android/passwordless)
+* [Auth0.Android Refresh Tokens](/libraries/auth0-android/save-and-refresh-tokens)
+* [Auth0.Android User Management](/libraries/auth0-android/user-management)
+:::
diff --git a/ja-jp/articles/libraries/auth0-android/passwordless.md b/ja-jp/articles/libraries/auth0-android/passwordless.md
new file mode 100644
index 0000000000..166610f555
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/passwordless.md
@@ -0,0 +1,81 @@
+---
+section: libraries
+toc: true
+description: How to use Auth0.Android with passwordless connections
+topics:
+  - libraries
+  - android
+  - passwordless
+contentType: how-to
+useCase: enable-mobile-auth
+---
+# Auth0.Android Passwordless Authentication
+
+Passwordless can be done via email or via SMS, and either by sending the user a code, or sending them a link which contains a code. All of these methods of Passwordless authentication will require two steps - requesting the code, and then inputting the code for verification. 
+
+## Configure Auth0 and the Android SDK
+
+### Enable the Passwordless OTP Grant for the Application
+
+In order to be able to use the Passwordless API from a Native client, you first need to enable the Passwordless OTP grant for your application in **Dashboard > Applications > (YOUR APPLICATION) > Settings > Advanced Settings > Grant Types**.
+
+### Initialize the Android SDK 
+
+Using the Passwordless API requires setting using the Auth0 Android SDK version 1.20 or higher, configured to work in OIDC conformant mode. This can be achieved by setting the `OIDCConformant` property to `true`:
+
+```java
+Auth0 account = new Auth0("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}");
+//Configure the account in OIDC conformant mode
+account.setOIDCConformant(true);
+//Use the account in the API clients
+```
+
+## Implement Passwordless Authentication Steps
+
+## Request the code
+
+In this example, requesting the code is done by calling `passwordlessWithEmail` with the user's email, `PasswordlessType.CODE`, and the name of the connection as parameters. On success, you may wish to display a notice to the user that their code is on the way, and perhaps route them to the view where they will input that code.
+
+```java
+authentication
+    .passwordlessWithEmail("info@auth0.com", PasswordlessType.CODE, "my-passwordless-connection")
+    .start(new BaseCallback() {
+        @Override
+        public void onSuccess(Void payload) {
+            //Code sent!
+        }
+
+        @Override
+        public void onFailure(AuthenticationException error) {
+            //Error!
+        }
+    });
+```
+
+You can use the `passwordlessWithSms` method to send the code using SMS. 
+
+## Input the code
+
+Once the user has a code, they can input it. Call the `loginWithEmail` method, and pass in the user's email, the code they received, and the name of the connection in question. Upon success, you will receive a Credentials object in the response.
+
+```java
+authentication
+    .loginWithEmail("info@auth0.com", "123456", "my-passwordless-connection")
+    .start(new BaseCallback() {
+        @Override
+        public void onSuccess(Credentials payload) {
+            //Logged in!
+        }
+
+        @Override
+        public void onFailure(AuthenticationException error) {
+            //Error!
+        }
+    });
+```
+
+You can use the `loginWithSms` method to send the code received by SMS and authenticate the user.
+
+::: note
+The default scope used is `openid`.
+:::
diff --git a/ja-jp/articles/libraries/auth0-android/save-and-refresh-tokens.md b/ja-jp/articles/libraries/auth0-android/save-and-refresh-tokens.md
new file mode 100644
index 0000000000..c70ab2403e
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/save-and-refresh-tokens.md
@@ -0,0 +1,135 @@
+---
+section: libraries
+description: Keeping your user logged in with Auth0.Android
+toc: true
+topics:
+  - libraries
+  - android
+  - tokens
+contentType: how-to
+useCase: enable-mobile-auth
+---
+# Auth0.Android Saving and Renewing Tokens
+
+When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new user token, without forcing the user to perform authentication again.
+
+## Credentials Manager
+
+[Auth0.Android](https://github.com/auth0/Auth0.Android) provides a utility class to streamline the process of storing and renewing credentials. You can access the `accessToken` or `idToken` properties from the [Credentials](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/result/Credentials.java) instance. This is the preferred method to manage user credentials.
+
+Credential Managers are included as part of the Auth0.Android SDK. If this is not part of your dependencies yet, make sure to [check the documentation](/libraries/auth0-android).
+
+Next, decide which class to use depending on your Android SDK target version.
+
+### API less than 21
+
+If you require APIs lower than 21 (Lollipop) create a new instance of `CredentialsManager`. This class makes use of the `Context.MODE_PRIVATE` to store the credentials in a key-value preferences file, accessible only to your app. The data is stored in plaintext.
+
+### API equal to or greater than 21
+
+If you require APIs equal or greater than 21 (Lollipop) create a new instance of `SecureCredentialsManager`. This class has the same methods as the one above, but encrypts the data before storing it using a combination of _RSA_ and _AES_ algorithms along with the use of [Android KeyStore](https://developer.android.com/reference/java/security/KeyStore.html).
+
+## Using the CredentialsManager class
+
+### Setup the CredentialsManager
+
+Create a new instance by passing an `AuthenticationAPIClient` and a `Storage` implementation.
+
+```java
+Auth0 auth0 = new Auth0(this);
+AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0);
+CredentialsManager manager = new CredentialsManager(apiClient, new SharedPreferencesStorage(this));
+```
+
+### Current State of the Authentication
+
+Stored credentials are considered valid if they have not expired or can be refreshed. Check if a user has already logged in:
+
+```java
+boolean loggedIn = manager.hasValidCredentials();
+```
+
+When you want to log the user out of your app, remove the stored credentials and direct them to the login screen.
+
+```java
+manager.clearCredentials();
+//Show login screen
+```
+
+### Retrieving Credentials
+
+Because the credentials may need to be refreshed against Auth0 Servers, this method is asynchronous. Pass a callback implementation where you'd like to receive the credentials. Credentials returned by this method upon success are always valid.
+
+```java
+manager.getCredentials(new BaseCallback() {
+    @Override
+    public void onSuccess(Credentials credentials) {
+        //Use credentials
+    }
+
+    @Override
+    public void onFailure(CredentialsManagerException error) {
+        //No credentials were previously saved or they couldn't be refreshed
+    }
+});
+```
+
+::: note
+If the `accessToken` has expired, the manager will automatically use the `refreshToken` and renew the credentials for you. New credentials will be stored for future access.
+:::
+
+### Save new Credentials
+
+You can save the credentials obtained during authentication in the manager.
+
+```java
+manager.saveCredentials(credentials);
+```
+
+## Using the SecureCredentialsManager class
+
+### Setup the SecureCredentialsManager
+
+Setup is a little different to the CredentialsManager class. Create a new instance by passing a valid android `Context`, an `AuthenticationAPIClient` and a `Storage` implementation.
+
+```java
+Auth0 auth0 = new Auth0(this);
+AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0);
+SecureCredentialsManager manager = new SecureCredentialsManager(this, apiClient, new SharedPreferencesStorage(this));
+```
+
+The methods to obtain, save, check for existence and clearing the credentials are the ones explained before.
+
+### Pre-Authenticate the User
+
+This class provides optional functionality for additional authentication using the device's configured Lock Screen. If the Lock Screen Security is set to something different than PIN, Pattern, Password or Fingerprint, this feature won't be available. You need to call the method below to enable the authentication. Pass a valid `Activity` context, a request code, and 2 optional Strings to use as title and description for the Lock Screen.
+
+```java
+private static final int RC_UNLOCK_AUTHENTICATION = 123;
+
+//Called from an Activity
+boolean available = manager.requireAuthentication(this, RC_UNLOCK_AUTHENTICATION, getString(R.string.unlock_authentication_title), getString(R.string.unlock_authentication_description));
+```
+
+If the feature was enabled, the manager will prompt the user to authenticate using the configured Lock Screen. The result of this call will be obtained in the `onActivityResult` method of the activity passed before as first parameter. If the feature was not enabled, Lock Screen authentication will be skipped.
+
+After checking that the received request code matches the one used in the configuration step, redirect the received parameters to the manager to finish the authentication. The credentials will be yield to the original callback.
+
+```java
+@Override
+protected void onActivityResult(int requestCode, int resultCode, Intent data) {
+    if (requestCode == RC_UNLOCK_AUTHENTICATION && manager.checkAuthenticationResult(requestCode, resultCode)) {
+        return;
+    }
+    super.onActivityResult(requestCode, resultCode, data);
+}
+```
+
+### Handling usage exceptions
+
+In the event that something happened while trying to save or retrieve the Credentials, a `CredentialsManagerException` will be thrown. These are some of the failure scenarios you can expect:
+
+- The Credentials to be stored are invalid, e.g. some of the following fields are not defined: access_token, id_token or expires_at.
+- The stored Credentials have expired but there is no refresh_token available to renew them automatically.
+- Device's Lock Screen security settings have changed (e.g. the security PIN code was changed). Even when `hasCredentials` returns _true_, the encryption keys will be deemed invalid and until `saveCredentials` is called again it won't be possible to decrypt any previously existing content, since they keys used back then are not the same as the new ones.
+- Device is not compatible with some of the cryptography algorithms required by the `SecureCredentialsManager` class. This is considered a _catastrophic event_ and is the only exception that will prevent you from using this implementation. This scenario happens when the OEM has modified the Android ROM of the device removing some of the algorithms officially included in every Android distribution. Nevertheless, you can check if this is the case in the exception instance itself by calling the `isDeviceIncompatible` method. By doing so you can decide the fallback implementation for storing the Credentials, such as using the regular `CredentialsManager` class.
diff --git a/ja-jp/articles/libraries/auth0-android/user-management.md b/ja-jp/articles/libraries/auth0-android/user-management.md
new file mode 100644
index 0000000000..51c085825e
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-android/user-management.md
@@ -0,0 +1,97 @@
+---
+section: libraries
+toc: true
+description: How to use Auth0.Android to manage users
+topics:
+  - libraries
+  - android
+  - users
+contentType: how-to
+useCase: enable-mobile-auth
+---
+# Use Auth0.Android to Manage Users
+
+The Management API provides functionality that you can use to manage users of your application, including tasks such as the following.
+
+* Link separate user accounts from different providers, tying them to a single profile (See [User Account Linking](/users/concepts/overview-user-account-linking) for details.)
+* Unlink user accounts, returning them to separate identities
+* Update [user metadata](/users/concepts/overview-user-metadata)
+
+## Initialize the UsersAPIClient
+
+To get started, create a new `UsersAPIClient` instance by passing it the `account` and the token for the primary identity. In the case of linking users, this primary identity is the user profile that you want to "keep" the data for, and which you plan to link other identities to.
+
+```java
+Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
+UsersAPIClient users = new UsersAPIClient(account, "token");
+```
+
+## Link users
+
+Linking user accounts will allow a user to authenticate from any of their accounts and no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish a user's accounts to refer to the same profile, you must perform account linking.
+
+The `link` method accepts two parameters, the primary user id and the secondary user token (the token obtained after login with this identity). The user id in question is the unique identifier for this user account. If the id is in the format `facebook|1234567890`, the id required is the portion after the delimiting pipe.
+
+```java
+users
+    .link("primary user id", "secondary user token")
+    .start(new BaseCallback, ManagementException>() {
+        @Override
+        public void onSuccess(List payload) {
+            //Got the updated identities! Accounts linked.
+        }
+
+        @Override
+        public void onFailure(ManagementException error) {
+            //Error!
+        }
+    });
+```
+
+## Unlink users
+
+Unlinking users is a similar process to the linking of users. The `unlink` method takes three parameters, though: the primary user id, the secondary user id, and the secondary provider (of the secondary user).
+
+```java
+users
+    .unlink("primary user id", "secondary user id", "secondary provider")
+    .start(new BaseCallback, ManagementException>() {
+        @Override
+        public void onSuccess(List payload) {
+            //Got the updated identities! Accounts linked.
+        }
+
+        @Override
+        public void onFailure(ManagementException error) {
+            //Error!
+        }
+    });
+```
+
+::: note
+When accounts are linked, the secondary account's metadata is **not** merged with the primary account's metadata. Similarly, when unlinking two accounts, the secondary account does not retain the primary account's metadata when it becomes separate again.
+:::
+
+## Updating user metadata
+
+When updating user metadata, you will create a `metadata` object, and then call the `updateMetadata` method, passing it the user id and the `metadata` object. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata.
+
+```java
+Map metadata = new HashMap<>();
+metadata.put("name", Arrays.asList("My", "Name", "Is"));
+metadata.put("phoneNumber", "1234567890");
+
+users
+    .updateMetadata("user id", metadata)
+    .start(new BaseCallback() {
+        @Override
+        public void onSuccess(UserProfile payload) {
+            //Metadata updated
+        }
+
+        @Override
+        public void onFailure(ManagementException error) {
+            //Error!
+        }
+    });
+```
diff --git a/ja-jp/articles/libraries/auth0-php/authentication-api.md b/ja-jp/articles/libraries/auth0-php/authentication-api.md
new file mode 100644
index 0000000000..570ccc6e83
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/authentication-api.md
@@ -0,0 +1,205 @@
+---
+section: libraries
+toc: true
+description: Using Auth0's Authentication API with your PHP applications.
+topics:
+  - libraries
+  - php
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# PHP: Using the Authentication API
+
+The Auth0 PHP SDK provides a `Auth0\SDK\API\Authentication` class, which houses the methods you can use to access the [Authentication API](/api/authentication) directly. Please note that this interface is intended for more advanced applications and in general does provide a means of keeping track of user sessions. For most use cases, you'll want to work with the [Auth0 base class](/libraries/auth0-php/basic-use).
+
+In this article, you'll find examples of common authentication operations.
+
+## Prerequisites
+
+The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there.
+
+## Authorization Code Flow
+
+An [Authorization Code grant](/api-auth/tutorials/authorization-code-grant) is the basic way to grant users access to your application. This flow is the same one used on the [Basic Use page](/libraries/auth0-php/basic-use#login). If you need more granular control over the login or callback process, this section walks through how to use the Authentication API directly.
+
+Users must authenticate with Auth0 to generate the authorization code. This is done by redirecting to the `/authorize` endpoint for your tenant domain. The following code would appear on a page that requires authentication:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there.
+
+// Setup a PHP session, which we'll use as a custom session store for the authenticated user.
+session_start();
+
+// $user will be null if no session is available; otherwise it will contain user data.
+$user = $_SESSION['user'] ?? null;
+
+// Has the user authenticated with us yet?
+if ($user === null) {
+    // Generates cryptographically secure pseudo-random bytes to use as a CSRF mitigating value.
+    // Store this for retrieval after authentication.
+    $_SESSION['state'] = bin2hex(random_bytes(16));
+
+    // Generate the authorize URL, and redirect the user to it.
+    header('Location: ' . $auth0->authentication()->getLoginLink($_SESSION['state']));
+    exit;
+}
+
+echo '
    Sensitive data!
    ';
+```
+
+The process above does the following:
+
+1. We check if there is an authenticated user state stored in our custom session handler. Your application might handle user sessions differently.
+2. If there is no session, then we need to log the user in by redirecting them to the Universal Login Page.
+3. We set a state value with the login request and then verify that value when the code is returned on the callback URL. We're storing this in our PHP session under the 'state' key.
+4. The `getLoginLink()` call builds the correct `/authorize` link with the correct response type (`code` in this case), redirect URI (wherein the application we will handle the response, explained below), and state (from above).
+5. We then redirect to this URL and wait for the user to be redirected back to us.
+
+After authentication, the user is redirected back to our application at the callback URL, which is handled with the following:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there.
+
+// Ensure we have our PHP session open so we can retrieve our stored state for comparison.
+session_start();
+
+// Extract `code` and `state` parameters from the request query, if present.
+$code = filter_var($_GET['code'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE);
+$state = filter_var($_GET['state'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE);
+
+// Check if a code is present in the request query.
+if ($code === null) {
+    die('No authorization code found.');
+}
+
+// Check if a state is present, and compare it with the one we generated and stored before redirecting the user.
+if ($state === null || $state !== $_SESSION['state']) {
+    die('Invalid state.');
+}
+
+// We have compared states, we should discard this stored value now.
+unset($_SESSION['state']);
+
+// Attempt to get an access_token with the code returned and original redirect URI. (This returns a PSR-7 ResponseInterface.)
+$response = $auth0->authentication()->codeExchange($code);
+
+// Does the status code of the response indicate failure?
+if ($response->getStatusCode() !== 200) {
+    die("Code exchange failed.");
+}
+
+// Decode the JSON response into a PHP array:
+$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR);
+
+// Create an array to store our session information in.
+$session = [
+    'id_token' => $response['id_token'] ?? null,
+    'access_token' => $response['access_token'] ?? null,
+    'scope' => $response['scope'] ?? null,
+    'refresh_token' => $response['refresh_token'] ?? null,
+    'expires_in' => $response['expires_in'] ?? null,
+    'user' => null
+];
+
+// We retrieved an ID token; let's process it!
+if ($session['id_token'] !== null) {
+    // The Auth0 SDK includes a helpful token processing utility we'll leverage for this:
+    $token = new \Auth0\SDK\Token($auth0->configuration(), $session['id_token'], \Auth0\SDK\Token::TYPE_ID_TOKEN);
+
+    // Verify the token, and validate it's claims. These will throw an \Auth0\SDK\Exception\InvalidTokenException if a check fails.
+    $token->verify();
+    $token->validate();
+
+    $session['user'] => $token->toArray();
+}
+
+// Store our authenticated session state.
+$_SESSION['user'] = $session;
+
+// Let's echo the user claims/identity as a demo of a successful authentication flow:
+print_r($session['user']);
+```
+
+Walking through the process in detail:
+
+1. We look for a `code` parameter in a request query. If it's missing, we abort authentication.
+2. We check to make sure we have a `state` value and make sure it matches the same one we generated. This is important to avoid CSRF attacks ([more information](/protocols/oauth2/mitigate-csrf-attacks).)
+3. We attempt a code exchange with the `codeExchange()` call, making sure to pass in the `code` Auth0 gave our application when it returned the authenticating user back to us.
+4. If this succeeds, we know the exchange was successful, and we have an ID Token and an Access Token among other potential values.
+5. We validate the ID Token and use the claims for the user identity.
+6. If this last step succeeds, we store the user and redirect back to our sensitive data.
+
+## Client Credentials Flow
+
+A [Client Credentials grant](/api-auth/tutorials/client-credentials) gives an application access to a specific API based on the scopes set in the Auth0 Dashboard. This is how applications can, for example, make calls to the Management API. Successful authentication will result in an Access Token being issued for the API requested.
+
+First, turn on the **Client Credentials** grant on then **Advanced settings > Grant Types** tab on the Application settings page.
+
+Next, authorize the Application for the API being used on the **Machine to Machine Applications** tab on the API's **Settings** page. Make sure all necessary scopes are selected (but no more) and **Update**. Switch back to the **Settings** tab and copy the **Identifier** value. This needs to be added to a `AUTH0_MANAGEMENT_AUDIENCE` key in your `.env` file.
+
+Request an Access Token for the API using the example below:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above.
+
+// Begin a client credentials exchange:
+$response = $auth0->authentication()->clientCredentials([
+    'audience' => $env['AUTH0_MANAGEMENT_AUDIENCE']
+]);
+
+// Does the status code of the response indicate failure?
+if ($response->getStatusCode() !== 200) {
+    die("Code exchange failed.");
+}
+
+// Decode the JSON response into a PHP array:
+$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR);
+
+// Echo the response to the browser
+print_r($response, true);
+```
+
+If the grant was successful, you should see something like the following:
+
+```
+Array
+(
+    [access_token] => eyJ0eXAi...eyJpc3Mi...QoB2c24w
+    [scope] => read:users read:clients ...
+    [expires_in] => 86400
+    [token_type] => Bearer
+)
+```
+
+See the [Management API page](/libraries/auth0-php/management-api) for more information on how to use this Access Token.
+
+## Single Sign-on Logout
+
+While destroying the local session with a `session_destroy()` would be sufficient in deauthenticating a user from your application, you should close your end user's session with Auth0 as well. This ensures that the next time the user sees an Auth0 login form, they will be required to provide their credentials to log in.
+
+First, determine where the user should end up after the logout has completed. Save this in the Auth0 Application settings in the "Allowed Logout URLs" field. Also, add an `AUTH0_LOGOUT_RETURN_URL` key with this URL as the value in your `.env` file.
+
+Add the following to your application logout code:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above.
+
+// Deauthenticate the user's local session in your application.
+session_destroy();
+
+// Redirect to Auth0's logout URL to end their Auth0 session:
+header("Location: " . $auth0->authentication()->getLogoutLink($env['AUTH0_LOGOUT_RETURN_URL']);
+```
+
+### Read more
+
+::: next-steps
+* [PHP Getting Started](/libraries/auth0-php)
+* [PHP Basic Use](/libraries/auth0-php/basic-use)
+* [PHP Management API](/libraries/auth0-php/management-api)
+* [PHP JWT Validation](/libraries/auth0-php/jwt-validation)
+* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting)
+:::
diff --git a/ja-jp/articles/libraries/auth0-php/basic-use.md b/ja-jp/articles/libraries/auth0-php/basic-use.md
new file mode 100644
index 0000000000..758fd798ad
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/basic-use.md
@@ -0,0 +1,110 @@
+---
+section: libraries
+toc: true
+description: Integrate a frictionless login and signup experience for your PHP applications.
+topics:
+  - libraries
+  - php
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# PHP: Basic Usage
+
+The Auth0 PHP SDK bundles three core classes: `Auth0\SDK\Auth0`, `Auth0\SDK\API\Authentication` and `Auth0\SDK\API\Management`, each offering interfaces for different functionality across Auth0's APIs. If you're building a stateful web application that needs to keep track of users' sessions, the base `Auth0` class is what you'll be working with the most. It provides methods for handling common authentication and session handling tasks such as logging in and out, retrieving user credentials, checking of an available session, and callback handling. These tasks are explained below.
+
+## Prerequisites
+
+The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there.
+
+## Logging In
+
+The default login process in the PHP SDK uses an [Authentication Code grant](/api-auth/tutorials/authorization-code-grant) combined with Auth0's Universal Login Page. In short, that process is:
+
+1. A user requesting access is redirected to the Universal Login Page.
+2. The user authenticates using one of [many possible connections](https://auth0.com/docs/identityproviders): social (Google, Twitter, Facebook), database (email and password), passwordless (email, SMS), or enterprise (ActiveDirectory, ADFS, Office 365).
+3. The user is redirected or posted back to your application's callback URL with `code` and `state` values if successful or an `error` and `error_description` if not.
+4. If the authentication was successful, the `state` value is validated.
+5. If the `state` is valid, the `code` value is exchanged with Auth0 for an ID Token and/or an Access Token.
+6. The identity from the ID token can be used to create an account, to start an application-specific session, or to persist as the user session.
+
+Auth0-PHP handles most of these steps automatically for you. Your application will need to:
+
+1. Call `Auth0\SDK\Auth0::login()` when users need to login (for example: click a link, visit walled content, etc.)
+2. Call `Auth0\SDK\Auth0::exchange()` when users are redirected to your callback URL.
+3. Call `Auth0\SDK\Auth0::getCredentials()` when you need to check if a user is logged in and retrieve user information.
+
+A simple implementation of these steps looks like this:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there.
+
+// getExchangeParameters() can be used on your callback URL to verify all the necessary parameters are present for post-authentication code exchange.
+if ($auth0->getExchangeParameters()) {
+    // If they're present, we should perform the code exchange.
+    $auth0->exchange();
+}
+
+// Check if the user is logged in already
+$session = $auth0->getCredentials();
+
+if ($session === null) {
+    // User is not logged in!
+    // Redirect to the Universal Login Page for authentication.
+    header("Location: " . $auth0->login());
+    exit;
+}
+
+// 🎉 At this point we have an authenticated user session accessible from $session; your application logic can continue from here!
+echo "Authenticated!";
+```
+
+Finally, you'll need to add you're application's URL to your Auth0 Application's "Allowed Callback URLs" field on the settings page. After that, loading your scripted page should:
+
+1. Immediately redirect you to an Auth0 login page for your tenant.
+2. After successfully logging in using any connection, redirect you back to your app.
+3. Display a simple page showing 'Authenticated!'.
+
+## Profile
+
+Now that we have authenticated a user, we can work with their persisted session data to do things like display user profiles.
+
+```php
+// 👆 We're continuing from code above. Append this to the index.php file.
+
+printf(
+    '
    Hi %s!
    
+    
    
+    
    Last update: %s
    
+    
    Contact: %s %s
    
+    
    Logout
    ',
+    isset($session->user['nickname']) ? strip_tags($session->user['nickname']) : '[unknown]',
+    isset($session->user['picture']) ? filter_var($session->user['picture'], FILTER_SANITIZE_URL) : 'https://gravatar.com/avatar/',
+    isset($session->user['updated_at']) ? date('j/m/Y', strtotime($session->user['updated_at'])) : '[unknown]',
+    isset($session->user['email']) ? filter_var($session->user['email'], FILTER_SANITIZE_EMAIL) : '[unknown]',
+    ! empty($session->user['email_verified']) ? '✓' : '✗'
+);
+```
+
+## Logout
+
+In addition to logging in, we also want users to be able to log out. When users log out, they must invalidate their session for the application. For this SDK, that means destroying their persistent user and token data:
+
+```php
+// Log out of the application.
+header("Location: $auth0->logout());
+```
+
+If you're using Single Sign-on (SSO) and also want to end their Auth0 session, see the [SSO Logout section here](/libraries/auth0-php/authentication-api#sso-logout). More information about logging out, in general, can be found [here](/logout).
+
+### Read more
+
+::: next-steps
+* [PHP Getting Started](/libraries/auth0-php)
+* [PHP Authentication API](/libraries/auth0-php/authentication-api)
+* [PHP Management API](/libraries/auth0-php/management-api)
+* [PHP JWT Validation](/libraries/auth0-php/jwt-validation)
+* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting)
+:::
diff --git a/ja-jp/articles/libraries/auth0-php/index.md b/ja-jp/articles/libraries/auth0-php/index.md
new file mode 100644
index 0000000000..666ad55e32
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/index.md
@@ -0,0 +1,113 @@
+---
+section: libraries
+toc: true
+description: Integrate a frictionless login and signup experience for your PHP applications.
+url: /libraries/auth0-php
+topics:
+  - libraries
+  - php
+contentType:
+  - how-to
+  - index
+  - reference
+useCase:
+  - add-login
+---
+# PHP: Getting Started
+
+The Auth0-PHP SDK can integrate into your PHP applications to provide a straightforward way to log your users in and to sign them up in your app. It provides support for social identity providers such as Facebook, Google, or Twitter, as well as enterprise providers such as Active Directory. The SDK provides convenient methods for accessing Auth0's Authentication and Management endpoints.
+
+The Auth0-PHP repository is open source and [hosted on GitHub](https://github.com/auth0/auth0-PHP). We appreciate all contributions, including bug reports, enhancement proposals, and pull requests.
+
+## Requirements
+
+- PHP 7.4+ (8.0+ recommended)
+- [Composer](https://getcomposer.org/doc/00-intro.md) 2
+
+## Installation
+
+Installing the Auth0 PHP SDK requires [Composer](https://getcomposer.org/doc/00-intro.md#installation-linux-unix-macos), the standard dependency management utility for PHP. Composer allows you to declare the dependent libraries your project needs and installs them for you. Please ensure Composer is installed and accessible from your shell before continuing.
+
+Next, run the following shell command within your project directory to install the SDK:
+
+```sh
+composer require auth0/auth0-php
+```
+
+This will create a `vendor` folder within your project and download all the dependencies needed to use the PHP SDK. This will also create a `vendor/autoload.php` file necessary for the SDK to work with your application, which we'll import later.
+
+## Getting Started
+
+To use the Auth0 Authentication and Management APIs, you'll need a free Auth0 account and an Application:
+
+1. Go to [auth0.com/signup](https://auth0.com/signup) and create an account.
+2. From your dashboard, go to **Applications**, then **Create Application**.
+3. Give your Application a name, select **Regular Web Application**, then **Create**
+4. Click the **Settings** tab for the required credentials used below. More information about these settings is [here](/dashboard/reference/settings-application).
+
+### Configure the SDK
+
+You should use [environment variables](https://secure.php.net/manual/en/reserved.variables.environment.php) to store and load sensitive Auth0 credentials. This eliminates the need for hardcoding them into your application. Let's create an `.env` file within the root of our project directory to store our application's credentials:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If we're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='https://${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# A long secret value we'll use to encrypt session cookies. This can be generated using `openssl rand -hex 32` from our shell.
+AUTH0_COOKIE_SECRET='SEE COMMENT ABOVE'
+
+# The base URL of our application.
+AUTH0_BASE_URL='http://127.0.0.1:3000'
+```
+
+You should never commit this file to version control or share it in an unsecure manner. The contents should be handled with care and treated like a password.
+
+As PHP is unable to read our `.env` file natively, you'll need to install a PHP library to do so. For the purposes of this documentation we'll be using `vlucas/phpdotenv`, but any 'dotenv' library you prefer will work. From our project directory, run the following shell command to install the library:
+
+```sh
+composer require vlucas/phpdotenv
+```
+
+### Initialize the SDK
+
+We're ready to configure and initialize an instance of the SDK within our new PHP application. Let's start by creating the PHP source file we'll be working with for this demonstration, `index.php`, and use the following snippet to get started:
+
+```php
+load();
+
+// Now instantiate the Auth0 class with our configuration:
+$auth0 = new \Auth0\SDK\Auth0([
+    'domain' => $env['AUTH0_DOMAIN'],
+    'clientId' => $env['AUTH0_CLIENT_ID'],
+    'clientSecret' => $env['AUTH0_CLIENT_SECRET'],
+    'cookieSecret' => $env['AUTH0_COOKIE_SECRET']
+]);
+```
+
+Congratulations, your application is now setup and ready to use with Auth0! You can now move on to building an example application using one of our PHP quickstarts. Choose the type of application you're looking to build to follow along with a quickstart suited for your needs:
+
+* [PHP Web Application](/quickstart/webapp/php/)
+* [PHP Backend API](/quickstart/backend/php/)
+
+## Next Steps
+
+::: next-steps
+* [PHP Basic Usage](/libraries/auth0-php/basic-use)
+* [PHP Authentication API](/libraries/auth0-php/authentication-api)
+* [PHP Management API](/libraries/auth0-php/management-api)
+* [PHP JWT Validation](/libraries/auth0-php/jwt-validation)
+* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting)
+:::
diff --git a/ja-jp/articles/libraries/auth0-php/jwt-validation.md b/ja-jp/articles/libraries/auth0-php/jwt-validation.md
new file mode 100644
index 0000000000..3c98d21c19
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/jwt-validation.md
@@ -0,0 +1,75 @@
+---
+section: libraries
+toc: true
+description: Validating JSON Web Tokens (JWTs) with your PHP applications.
+topics:
+  - libraries
+  - php
+contentType:
+  - how-to
+  - reference
+---
+# PHP: Validating JWTs
+
+The Auth0 PHP SDK provides a `Auth0\SDK\Token` class used for processing JSON Web Tokens (JWT). It enables you to decode, validate and verify tokens for use by your application. More information on JWTs and how to build and decode them can be found [jwt.io](https://jwt.io/).
+
+The class can process both HS256 and RS256 tokens. Both types require the algorithm and valid audiences to be configured with the SDK before processing. HS256 tokens require the client secret to be configured. RS256 tokens require an authorized issuer, which is used to fetch a JWKs file during the decoding process.
+
+## Prerequisites
+
+The documentation below assumes that you followed the steps in the [PHP getting started guide](/libraries/auth0-php), and continue off from the code provided there.
+
+## Example Usage
+
+The following is an example of a small, URL-based JSON Web Token processor based on the SDK's `Token` class.
+
+```php
+load();
+
+$token = filter_var($_GET['token'] ?? null, FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE);
+$algorithm = filter_var($_GET['algorithm'] ?? 'HS256', FILTER_UNSAFE_RAW, FILTER_NULL_ON_FAILURE);
+
+if ($token === null) {
+    die('No `token` request parameter.');
+}
+
+if (! in_array($algorithm, ['HS256', 'RS256'])) {
+    die('Invalid `algorithm` supplied.');
+}
+
+// The Auth0 SDK includes a helpful token processing utility we'll leverage for this:
+$token = new \Auth0\SDK\Token([
+    'domain' => $env['AUTH0_DOMAIN'],
+    'clientId' => $env['AUTH0_CLIENT_ID'],
+    'clientSecret' => $env['AUTH0_CLIENT_SECRET'],
+    'tokenAlgorithm' => $algorithm
+], $token, \Auth0\SDK\Token::TYPE_ID_TOKEN);
+
+// Verify the token: (This will throw an \Auth0\SDK\Exception\InvalidTokenException if verification fails.)
+$token->verify();
+
+// Validate the token claims: (This will throw an \Auth0\SDK\Exception\InvalidTokenException if validation fails.)
+$token->validate();
+
+echo '
    ';
+print_r($token->toArray(), true);
+echo '
    ';
+```
+
+Both `verify()` and `validate()` offer a number of options arguments that can be used to customize their behavior, including validating nonce claims, restricting maximum time since a token's `auth_time`, `leeway` clock tolerance for time checks, and more. These methods are fully commented for review of these options either via the source code or your IDE of choice.
+
+### Read more
+
+::: next-steps
+* [PHP Getting Started](/libraries/auth0-php)
+* [PHP Basic Use](/libraries/auth0-php/basic-use)
+* [PHP Authentication API](/libraries/auth0-php/authentication-api)
+* [PHP Management API](/libraries/auth0-php/management-api)
+* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting)
+:::
diff --git a/ja-jp/articles/libraries/auth0-php/management-api.md b/ja-jp/articles/libraries/auth0-php/management-api.md
new file mode 100644
index 0000000000..2fbae10fe9
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/management-api.md
@@ -0,0 +1,123 @@
+---
+section: libraries
+toc: true
+description: Using Auth0's Management API with your PHP applications.
+topics:
+  - libraries
+  - php
+contentType:
+  - how-to
+  - reference
+---
+# PHP: Using the Management API
+
+The Auth0 PHP SDK provides a `Auth0\SDK\API\Management` class, which houses the methods you can use to access the [Management API](/api/management/v2) and perform operations on your Auth0 tenant. Using this interface, you can easily:
+
+- Search for and create users
+- Create and update Applications
+- Retrieve log entries
+- Manage rules
+
+... and much more. See our [APi reference](/api/management/v2) for information on what's possible!
+
+## Authentication
+
+To use the Management API, you must authenticate one of two ways:
+
+- For temporary access or testing, you can [manually generate an API token](/api/management/v2/tokens#get-a-token-manually) and save it in your `.env` file.
+- For extended access, you must create and execute and Client Credentials grant when access is required. This process is detailed on the [Authentication API page](/libraries/auth0-php/authentication-api#regular-web-app-login-flow).
+
+Regardless of the method, the token generated must have the scopes required for the operations your app wants to execute. Consult the [API documentation](/api/management/v2) for the scopes required for the specific endpoint you're trying to access.
+
+To grant the scopes needed:
+
+1. Go to [APIs](https://manage.auth0.com/#/apis) > Auth0 Management API > **Machine to Machine Applications** tab.
+2. Find your Application and authorize it.
+3. Click the arrow to expand the row and select the scopes required.
+
+Now you can authenticate one of the two ways above and use that token to perform operations:
+
+```php
+// 👆 We're continuing from the "getting started" guide linked in "Prerequisites" above. Append this to the index.php file you created there.
+
+if (isset($env['AUTH0_MANAGEMENT_API_TOKEN'])) {
+    $auth0->configuration()->setManagementToken($env['AUTH0_MANAGEMENT_API_TOKEN']);
+}
+
+// Create a configured instance of the `Auth0\SDK\API\Management` class, based on the configuration we setup the SDK ($auth0) using.
+// If no AUTH0_MANAGEMENT_API_TOKEN is configured, this will automatically perform a client credentials exchange to generate one for you, so long as a client secret is configured.
+$management = $auth0->management();
+```
+
+The `Management` class stores access to endpoints as factory methods of its instances, for example `$management->users()` returns an instance of `Auth0\SDK\API\Management\Users` that you can use to interact with the /users Management API endpoints.
+
+### Example: Search Users
+
+This endpoint is documented [here](/api/management/v2#!/Users/get_users).
+
+```php
+// 👆 We're continuing from the code above. Append this to your source code file.
+
+$response = $management->users()->getAll(['q' => 'josh']);
+
+// Does the status code of the response indicate failure?
+if ($response->getStatusCode() !== 200) {
+    die("API request failed.");
+}
+
+// Decode the JSON response into a PHP array:
+$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR);
+
+if (! empty($response)) {
+    echo '
    User Results
    ';
+
+    foreach ($response as $result) {
+        printf(
+            '
    %s <%s> - %s
    ',
+            !empty($result['nickname']) ? $result['nickname'] : 'No nickname',
+            !empty($result['email']) ? $result['email'] : 'No email',
+            $result['user_id']
+        );
+    }
+}
+```
+
+### Example: Get All Clients
+
+This endpoint is documented [here](/api/management/v2#!/Clients/get_clients).
+
+```php
+// 👆 We're continuing from the code above. Append this to your source code file.
+
+$response = $management->clients()->getAll(['q' => 'josh']);
+
+// Does the status code of the response indicate failure?
+if ($response->getStatusCode() !== 200) {
+    die("API request failed.");
+}
+
+// Decode the JSON response into a PHP array:
+$response = json_decode(response->getBody()->__toString(), true, 512, JSON_THROW_ON_ERROR);
+
+if (! empty($response)) {
+    echo '
    Get All Clients
    ';
+
+    foreach ($response as $result) {
+        printf(
+            '
    %s - %s
    ',
+            $result['name'],
+            $result['client_id']
+        );
+    }
+}
+```
+
+### Read more
+
+::: next-steps
+* [PHP Introduction](/libraries/auth0-php)
+* [PHP Basic Use](/libraries/auth0-php/basic-use)
+* [PHP Authentication API](/libraries/auth0-php/authentication-api)
+* [PHP JWT Validation](/libraries/auth0-php/jwt-validation)
+* [PHP Troubleshooting](/libraries/auth0-php/troubleshooting)
+:::
diff --git a/ja-jp/articles/libraries/auth0-php/troubleshooting.md b/ja-jp/articles/libraries/auth0-php/troubleshooting.md
new file mode 100644
index 0000000000..cbd531246b
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-php/troubleshooting.md
@@ -0,0 +1,40 @@
+---
+section: libraries
+toc: true
+description: Troubleshooting commons issues with your PHP applications.
+topics:
+  - libraries
+  - php
+contentType:
+  - reference
+---
+# PHP: Troubleshooting the SDK
+
+The following is a list of issues you might see when using the Auth0 PHP library and how you might troubleshoot these issues.
+
+### I'm getting an "Invalid State" exception when trying to log in.
+
+[State validation](https://auth0.com/docs/protocols/oauth2/oauth-state) was added in 5.1.0 for improved security. By default, this uses session storage and will happen automatically if you are using a combination of `Auth0::login()` and any method which calls `Auth0::exchange()` in your callback.
+
+If your users encounter this error:
+- Ensure your application is not accidentally invoking `Auth0::login()` more than once, which could invalidate the state stored on the end user's device.
+- The end user is using a modern browser on their device and not blocking cookies.
+
+### I am getting `curl error 60: SSL certificate problem: self-signed certificate in certificate chain` on Windows
+
+This is a common issue with the latest PHP versions under **Windows OS** (it is related to an incompatibility between Windows and OpenSSL CA's database).
+
+1. Download this CA database `https://curl.haxx.se/ca/cacert.pem` to `c:/cacert.pem`.
+2. Edit your php.ini and add `openssl.cafile=c:/cacert.pem`. (It should point to the file you downloaded.)
+
+### My host does not allow using Composer
+
+The PHP SDK requires Composer for maintaining dependencies (external PHP libraries). If Composer is now allowed to be installed globally on your host, you can still install it locally to run on your user shell account. Instructions for this can be found on the Composer website: https://getcomposer.org/doc/00-intro.md#locally
+
+## Keep reading
+
+* [PHP Introduction](/libraries/auth0-php)
+* [PHP Basic Use](/libraries/auth0-php/basic-use)
+* [PHP Authentication API](/libraries/auth0-php/authentication-api)
+* [PHP Management API](/libraries/auth0-php/management-api)
+* [PHP JWT Validation](/libraries/auth0-php/jwt-validation)
diff --git a/ja-jp/articles/libraries/auth0-react/index.md b/ja-jp/articles/libraries/auth0-react/index.md
new file mode 100644
index 0000000000..c490c1e05e
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-react/index.md
@@ -0,0 +1,232 @@
+---
+section: libraries
+toc: true
+title: Auth0 React SDK
+description: Auth0 SDK for React Single Page Applications.
+topics:
+  - libraries
+  - auth0-react
+contentType:
+  - index
+---
+
+
+
+# Auth0 React SDK
+
+
+The Auth0 React SDK is a JavaScript library for implementing authentication & authorization in React apps with Auth0. It provides a custom React hook and other Higher Order Components so you can secure React apps using best practices while writing less code.
+
+The Auth0 React SDK handles grant and protocol details, token expiration and renewal, as well as token storage and caching. Under the hood, it implements [Universal Login](/universal-login) and the [Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce).
+
+The library is [hosted on GitHub](https://github.com/auth0/auth0-react) where you can [read more about the API](https://auth0.github.io/auth0-react/).
+
+## Installation
+
+Using [npm](https://npmjs.org):
+
+```sh
+npm install @auth0/auth0-react
+```
+
+Using [yarn](https://yarnpkg.com):
+
+```sh
+yarn add @auth0/auth0-react
+```
+
+## Getting Started
+
+First, you'll need to wrap your application in a single `Auth0Provider` component. This will provide the React Context to components that are placed inside your application.
+
+```jsx
+import React from 'react';
+import ReactDOM from 'react-dom';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+ReactDOM.render(
+  
+    
+  ,
+  document.getElementById('app')
+);
+```
+
+Use the `useAuth0` hook in your components to access the React Context's authentication state (`isLoading`, `isAuthenticated` and `user`) and authentication methods (`loginWithRedirect` and `logout`).
+
+### isLoading and error
+
+Wait for the SDK to initialise and handle any errors with the `isLoading` and `error` states.
+
+```jsx
+import React from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+function Wrapper({ children }) {
+  const {
+    isLoading,
+    error,
+  } = useAuth0();
+
+  if (isLoading) {
+    return 
    Loading...
    ;
+  }
+  if (error) {
+    return 
    Oops... {error.message}
    ;
+  }
+  return <>{children};
+}
+
+export default Wrapper;
+```
+
+### Login
+
+Use `loginWithRedirect` or `loginWithPopup` to log your users in.
+
+```jsx
+import React from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+function LoginButton() {
+  const {
+    isAuthenticated,
+    loginWithRedirect,
+  } = useAuth0();
+
+  return !isAuthenticated && (
+    
+  );
+}
+
+export default LoginButton;
+```
+
+### Logout
+
+Use `logout` to log your users out. Make sure `returnTo` is specified in "Allowed Logout URLs" in your Auth0 Dashboard.
+
+```jsx
+import React from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+function LogoutButton() {
+  const {
+    isAuthenticated,
+    logout,
+  } = useAuth0();
+
+  return isAuthenticated && (
+    
+  );
+}
+
+export default Logout;
+```
+
+### User
+
+Access user profile information with the `user` value. 
+
+```jsx
+import React from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+function Profile() {
+  const { user } = useAuth0();
+
+  return 
    Hello {user.name}
    ;
+}
+
+export default Profile;
+```
+
+### Use with a class component
+
+Use the `withAuth0` Higher Order Component to add the `auth0` property to class components instead of using the hook.
+
+```jsx
+import React, { Component } from 'react';
+import { withAuth0 } from '@auth0/auth0-react';
+
+class Profile extends Component {
+  render() {
+    const { user } = this.props.auth0;
+    return 
    Hello {user.name}
    ;
+  }
+}
+
+export default withAuth0(Profile);
+```
+
+### Protect a route
+
+Protect a route component using the `withAuthenticationRequired` higher order component. Visits to this route when unauthenticated will redirect the user to the login page and back to this page after login.
+
+```jsx
+import React from 'react';
+import { withAuthenticationRequired } from '@auth0/auth0-react';
+
+const PrivateRoute = () => (
    Private
    );
+
+export default withAuthenticationRequired(PrivateRoute, {
+  // Show a message while the user waits to be redirected to the login page.
+  onRedirecting: () => (
    Redirecting you to the login page...
    )
+});
+```
+
+**Note** If you are using a custom router, you will need to supply the `Auth0Provider` with a custom `onRedirectCallback` method to perform the action that returns the user to the protected page. See examples for [react-router](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-react-router-dom-v6-app), [Gatsby](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-gatsby-app) and [Next.js](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#protecting-a-route-in-a-nextjs-app-in-spa-mode).
+
+### Call an API
+
+To call a protected API with an Access Token, be sure to specify the `audience` and `scope` of your access token, either in `Auth0Provider` or `getAccessTokenSilently`. Then use it to call a protected API by passing it in the `Authorization` header of your request.
+
+```jsx
+import React, { useEffect, useState } from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+const Posts = () => {
+  const { getAccessTokenSilently } = useAuth0();
+  const [posts, setPosts] = useState(null);
+
+  useEffect(() => {
+    (async () => {
+      try {
+        const token = await getAccessTokenSilently({
+          audience: 'https://api.example.com/',
+          scope: 'read:posts',
+        });
+        const response = await fetch('https://api.example.com/posts', {
+          headers: {
+            Authorization: `Bearer <%= "${token}" %>`,
+          },
+        });
+        setPosts(await response.json());
+      } catch (e) {
+        console.error(e);
+      }
+    })();
+  }, [getAccessTokenSilently]);
+
+  if (!posts) {
+    return 
    Loading...
    ;
+  }
+
+  return (
+    
      
+      {posts.map((post, index) => {
+        return 
    • {post}
      • ;
+      })}
+    
    
+  );
+};
+
+export default Posts;
+```
diff --git a/ja-jp/articles/libraries/auth0-spa-js/index.md b/ja-jp/articles/libraries/auth0-spa-js/index.md
new file mode 100644
index 0000000000..0055131f0e
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-spa-js/index.md
@@ -0,0 +1,340 @@
+---
+section: libraries
+toc: true
+title: Auth0 Single Page App SDK
+description: Auth0 SDK for single page applications using Authorization Code Grant Flow with PKCE.
+topics:
+  - libraries
+  - auth0-spa-js
+contentType:
+  - index
+---
+
+
+
+# Auth0 Single Page App SDK
+
+The Auth0 Single Page App SDK is a new JavaScript library for implementing authentication & authorization in single page apps (SPA) with Auth0. It provides a high-level API and handles a lot of the details so you can secure SPAs using best practices while writing less code.
+
+The Auth0 SPA SDK handles grant and protocol details, token expiration and renewal, as well as token storage and cacheing. Under the hood, it implements [Universal Login](/universal-login) and the [Authorization Code Grant Flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce).
+
+The library is [hosted on GitHub](https://github.com/auth0/auth0-spa-js) and you can find the API documentation [here](https://auth0.github.io/auth0-spa-js/).
+
+If your SPA is based on React, check out the [Auth0 React SDK](/libraries/auth0-react).
+
+<%= include('../_includes/_spa_js_faq.md') %>
+
+## Installation
+
+You have a few options for using auth0-spa-js in your project:
+
+From the CDN:
+
+```html
+
+```
+
+Using [npm](https://npmjs.org):
+
+```sh
+npm install @auth0/auth0-spa-js
+```
+
+Using [yarn](https://yarnpkg.com):
+
+```sh
+yarn add @auth0/auth0-spa-js
+```
+
+## Getting Started
+
+### Create the client
+
+First, you'll need to create a new instance of `Auth0Client` client object. Create the `Auth0Client` instance before rendering or initializing your application. You can do this using either the async/await method, or with promises. You should only create one instance of the client.
+
+```js
+import createAuth0Client from '@auth0/auth0-spa-js';
+
+// either with async/await
+const auth0 = await createAuth0Client({
+  domain: '${account.namespace}',
+  client_id: '${account.clientId}'
+});
+```
+
+```js
+// or with promises
+createAuth0Client({
+  domain: '${account.namespace}',
+  client_id: '${account.clientId}'
+}).then(auth0 => {
+  //...
+});
+```
+
+Using `createAuth0Client` does a couple of things automatically:
+
+* It creates an instance of `Auth0Client`.
+* It calls `getTokenSilently` to refresh the user session.
+* It suppresses all errors from `getTokenSilently`, except `login_required`.
+
+You can also create the client directly using the `Auth0Client` constructor. This can be useful if:
+
+* You wish to bypass the call to `getTokenSilently` on initialization.
+* You wish to do custom error handling.
+* You wish to initialize the SDK in a synchronous way.
+
+```js
+import { Auth0Client } from '@auth0/auth0-spa-js';
+
+const auth0 = new Auth0Client({
+  domain: '${account.namespace}',
+  client_id: '${account.clientId}'
+});
+```
+
+### Login and get user info
+
+Next, create a button users can click to start logging in.
+
+```html
+
+```
+
+Listen for click events on the button you created. When the event occurs, use the desired login method to authenticate the user (`loginWithRedirect()` in this example). After the user is authenticated, you can retrieve the user profile with the `getUser()` method.
+
+```js
+// either with async/await
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.loginWithRedirect({
+    redirect_uri: 'http://localhost:3000/'
+  });
+  //logged in. you can get the user profile like this:
+  const user = await auth0.getUser();
+  console.log(user);
+});
+```
+
+```js
+// or with promises
+document.getElementById('login').addEventListener('click', () => {
+  auth0.loginWithRedirect({
+    redirect_uri: 'http://localhost:3000/'
+  }).then(token => {
+    //logged in. you can get the user profile like this:
+    auth0.getUser().then(user => {
+      console.log(user);
+    });
+  });
+});
+```
+
+### Call an API
+
+To call your API, start by getting the user's Access Token. Then use the Access Token in your request. In this example the `getTokenSilently` method is used to retrieve the Access Token.
+
+```html
+
+```
+
+```js
+// either with async/await
+document.getElementById('callApi').addEventListener('click', async () => {
+  const accessToken = await auth0.getTokenSilently();
+  const result = await fetch('https://exampleco.com/api', {
+    method: 'GET',
+    headers: {
+      Authorization: 'Bearer ' + accessToken
+    }
+  });
+  const data = await result.json();
+  console.log(data);
+});
+```
+
+```js
+// or with promises
+document.getElementById('callApi').addEventListener('click', () => {
+  auth0
+    .getTokenSilently()
+    .then(accessToken =>
+      fetch('https://exampleco.com/api', {
+        method: 'GET',
+        headers: {
+          Authorization: 'Bearer ' + accessToken
+        }
+      })
+    )
+    .then(result => result.json())
+    .then(data => {
+      console.log(data);
+    });
+});
+```
+
+### Logout
+
+Add a button users can click to logout.
+
+```html
+
+```
+
+```js
+document.getElementById('logout').addEventListener('click', () => {
+  auth0.logout();
+});
+```
+
+### Change storage options
+
+The Auth0 SPA SDK stores tokens in memory by default. However, this does not provide persistence across page refreshes and browser tabs. Instead, you can opt-in to store tokens in local storage by setting the `cacheLocation` property to `localstorage` when initializing the SDK. This can help to mitigate some of the effects of browser privacy technology that prevents access to the Auth0 session cookie by storing Access Tokens for longer.
+
+::: warning
+Storing tokens in browser local storage provides persistence across page refreshes and browser tabs. However, if an attacker can achieve running JavaScript in the SPA using a cross-site scripting (XSS) attack, they can retrieve the tokens stored in local storage. A vulnerability leading to a successful XSS attack can be either in the SPA source code or in any third-party JavaScript code (such as bootstrap, jQuery, or Google Analytics) included in the SPA.
+
+Read more about [token storage](/tokens/concepts/token-storage#single-page-app-scenarios).
+:::
+
+```js
+const auth0 = await createAuth0Client({
+  domain: '${account.namespace}',
+  client_id: '${account.clientId}',
+  cacheLocation: 'localstorage'
+});
+```
+
+### Use rotating Refresh Tokens
+
+The Auth0 SPA SDK can be configured to use [rotating Refresh Tokens](/tokens/concepts/refresh-token-rotation) to get new access tokens silently. These can be used to bypass browser privacy technology that prevents access to the Auth0 session cookie when authenticating silently, as well as providing [built-in reuse detection](/tokens/concepts/refresh-token-rotation#automatic-reuse-detection).
+
+Configure the SDK to do this by setting `useRefreshTokens` to `true` on initialization:
+
+```js
+const auth0 = await createAuth0Client({
+  domain: '${account.namespace}',
+  client_id: '${account.clientId}',
+  useRefreshTokens: true
+});
+
+// Request a new access token using a refresh token
+const token = await auth0.getTokenSilently();
+```
+
+Refresh Tokens will also need to be [configured for your tenant](/tokens/guides/configure-refresh-token-rotation) before they can be used in your SPA.
+
+Once configured, the SDK will request the `offline_access` scope during the authorization step. Furthermore, `getTokenSilently` will then call the `/oauth/token` endpoint directly to exchange refresh tokens for access tokens.
+
+:::note
+The SDK will obey the storage configuration when storing refresh tokens. If the SDK has been configured using the default in-memory storage mechanism, refresh tokens will be lost when refreshing the page.
+:::
+
+## Usage 
+
+Below are examples of usage for various methods in the SDK. Note that jQuery is used in these examples.
+
+### Login with popup
+
+```js
+$('#loginPopup').click(async () => {
+  await auth0.loginWithPopup();
+});
+```
+
+### Login with redirect
+
+```js
+$('#loginRedirect').click(async () => {
+  await auth0.loginWithRedirect({
+    redirect_uri: 'http://localhost:3000/'
+  });
+});
+```
+
+Redirect to the `/authorize` endpoint at Auth0, starting the [Universal Login](/universal-login) flow.
+
+### Login with redirect callback
+
+```js
+$('#loginRedirectCallback').click(async () => {
+  await auth0.handleRedirectCallback();
+});
+```
+
+### Get Access Token with no interaction
+
+Get a new Access Token silently using either a hidden iframe and `prompt=none`, or by using a rotating Refresh Token. Refresh Tokens are used when `useRefreshTokens` is set to `true` when configuring the SDK.
+
+If in-memory storage (the default) and refresh tokens are used, new tokens are retrieved using a web worker on supported browsers.
+
+```js
+$('#getToken').click(async () => {
+  const token = await auth0.getTokenSilently();
+});
+```
+
+The `getTokenSilently()` method requires you to have **Allow Skipping User Consent** enabled in your [API Settings in the Dashboard](${manage_url}/#/apis). Additionally, user consent [cannot be skipped on 'localhost'](/api-auth/user-consent#skipping-consent-for-first-party-applications).
+
+### Get Access Token with popup
+
+```js
+$('#getTokenPopup').click(async () => {
+  const token = await auth0.getTokenWithPopup({
+    audience: 'https://mydomain/api/',
+    scope: 'read:rules'
+  });
+});
+```
+
+### Get Access Token for a different audience
+
+```js
+$('#getToken_audience').click(async () => {
+  const differentAudienceOptions = {
+    audience: 'https://mydomain/another-api/',
+    scope: 'read:rules',
+    redirect_uri: 'http://localhost:3000/callback.html'
+  };
+  const token = await auth0.getTokenSilently(differentAudienceOptions);
+});
+```
+
+### Get user
+
+```js
+$('#getUser').click(async () => {
+  const user = await auth0.getUser();
+});
+```
+
+### Get ID Token claims
+
+```js
+$('#getIdTokenClaims').click(async () => {
+  const claims = await auth0.getIdTokenClaims();
+  // if you need the raw id_token, you can access it
+  // using the __raw property
+  const id_token = claims.__raw;
+});
+```
+
+### Logout (default)
+
+```js
+$('#logout').click(async () => {
+  auth0.logout({
+    returnTo: 'http://localhost:3000/'
+  });
+});
+```
+
+### Logout with no client ID
+
+```js
+$('#logoutNoClientId').click(async () => {
+  auth0.logout({
+    client_id: null,
+    returnTo: 'http://localhost:3000/'
+  });
+});
+```
diff --git a/ja-jp/articles/libraries/auth0-spa-js/migrate-from-auth0js.md b/ja-jp/articles/libraries/auth0-spa-js/migrate-from-auth0js.md
new file mode 100644
index 0000000000..40ce0aa180
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-spa-js/migrate-from-auth0js.md
@@ -0,0 +1,244 @@
+---
+section: libraries
+title: Migrate from Auth0.js to the Auth0 Single Page App SDK
+description: How to migrate single page applications from Auth0.js to Auth0 Single Page App SDK
+public: false
+topics:
+  - libraries
+  - auth0-spa-js
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - migrate
+---
+
+# Migrate from Auth0.js to the Auth0 Single Page App SDK
+
+In this article, you’ll see how to migrate your single page app (SPA) from [auth0.js](/libraries/auth0js) to [auth0-spa-js](/libraries/auth0-spa-js). Listed below are scenarios using auth0.js and the equivalent auth0-spa-js code.
+
+## Functionality that cannot be migrated
+
+Not all auth0.js functionality can be directly migrated to auth0-spa-js. Scenarios that cannot be directly migrated include:
+
+- embedded [login with username/password](https://auth0.github.io/auth0.js/global.html#login) as well as embedded [passwordless login](https://auth0.github.io/auth0.js/global.html#passwordlessLogin)
+- user [signup](https://auth0.github.io/auth0.js/global.html#signup)
+- [get a user profile from /userinfo endpoint](https://auth0.github.io/auth0.js/global.html#userInfo)
+- [request an email to change the user's password](https://auth0.github.io/auth0.js/global.html#changePassword)
+- [link users with the Management API](https://auth0.github.io/auth0.js/global.html#linkUser)
+- [get user with the Management API](https://auth0.github.io/auth0.js/global.html#getUser)
+- [update user attributes with the Management API](https://auth0.github.io/auth0.js/global.html#patchUserAttributes)
+- [update user metadata with the Management API](https://auth0.github.io/auth0.js/global.html#patchUserMetadata)
+- There are also some options that are configurable in Auth0.js that do not have a counterpart in the auth0-spa-js. An example of this is `responseType`. There is a reason that there is not a direct 1:1 mapping for each option. In this case, `responseType` is unnecessary, because the SDK is only for use in SPAs, and so one would not need to change the response type.
+
+## Authentication Parameters are not modified anymore
+
+Auth0.js converts custom parameters you set from `camelCase` to `snake_case` internally. For example, if you set `deviceType: 'offline'`, auth0.js actually sends `device_type: 'offline'` to the server.
+
+When using auth0-spa-js, custom parameters **are not converted** from `camelCase` to `snake_case`. It will relay whatever parameter you send to the authorization server.
+
+## Create the client
+
+### auth0.js
+
+* [WebAuth](https://auth0.github.io/auth0.js/WebAuth.html)
+
+```js
+import { WebAuth } from 'auth0.js';
+
+window.addEventListener('load', () => {
+  var auth0 = new WebAuth({
+    domain: '${account.namespace}',
+    clientID: '${account.clientId}',
+    redirectUri: '${account.callback}'
+  });
+});
+```
+
+### auth0-spa-js
+
+* [createAuth0Client()](https://auth0.github.io/auth0-spa-js/globals.html#createauth0client)
+* [Auth0ClientOptions](https://auth0.github.io/auth0-spa-js/interfaces/auth0clientoptions.html)
+
+```js
+import createAuth0Client from '@auth0/auth0-spa-js';
+
+window.addEventListener('load', () => {
+  const auth0 = await createAuth0Client({
+    domain: '${account.namespace}',
+    client_id: '${account.clientId}',
+    redirect_uri: '${account.callback}'
+  });
+});
+```
+
+## Redirect to the Universal Login Page
+
+### auth0.js
+
+* [authorize()](https://auth0.github.io/auth0.js/global.html#authorize)
+
+```js
+document.getElementById('login').addEventListener('click', () => {
+  auth0.authorize();
+});
+```
+
+### auth0-spa-js
+
+* [Auth0Client.loginWithRedirect()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#loginwithredirect)
+* [RedirectLoginOptions](https://auth0.github.io/auth0-spa-js/interfaces/redirectloginoptions.html)
+
+```js
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.loginWithRedirect();
+});
+```
+
+## Parse the hash after the redirect
+
+### auth0.js
+
+* [parseHash()](https://auth0.github.io/auth0.js/global.html#parseHash)
+
+```js
+window.addEventListener('load', () => {
+  auth0.parseHash({ hash: window.location.hash }, function(err, authResult) {
+    if (err) {
+      return console.log(err);
+    }
+    console.log(authResult);
+  });
+});
+```
+
+### auth0-spa-js
+
+* [Auth0Client.handleRedirectCallback()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#handleredirectcallback)
+
+```js
+window.addEventListener('load', async () => {
+  await auth0.handleRedirectCallback();
+});
+```
+
+## Get the user information
+
+### auth0.js
+
+The `userInfo()` function makes a call to the [/userinfo endpoint](https://auth0.com/docs/api/authentication#user-profile) and returns the user profile.
+
+* [userInfo()](https://auth0.github.io/auth0.js/global.html#userInfo)
+
+```js
+window.addEventListener('load', () => {
+  auth0.client.userInfo(accessToken, function(err, user) {
+    console.log(user)
+  });
+});
+```
+
+### auth0-spa-js
+
+Unlike auth0.js, the Auth0 SPA SDK does not call to the [/userinfo endpoint](https://auth0.com/docs/api/authentication#user-profile) for the user profile. Instead `Auth0Client.getUser()` returns user information from the decoded `id_token`.
+
+* [Auth0Client.getUser()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#getuser)
+* [GetUserOptions](https://auth0.github.io/auth0-spa-js/interfaces/getuseroptions.html)
+
+```js
+window.addEventListener('load', async () => {
+  const user = await auth0.getUser();
+  console.log(user);
+});
+```
+
+## Open the Universal Login Page in a popup
+
+### auth0.js
+
+```js
+document.getElementById('login').addEventListener('click', () => {
+  auth0.popup.authorize();
+});
+```
+
+### auth0-spa-js
+
+* [Auth0Client.loginWithPopup()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#loginwithpopup)
+* [PopupLoginOptions](https://auth0.github.io/auth0-spa-js/interfaces/popuploginoptions.html)
+
+```js
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.loginWithPopup();
+});
+```
+
+## Refresh tokens
+
+### auth0.js
+
+* [checkSession()](https://auth0.github.io/auth0.js/global.html#checkSession)
+
+```js
+document.getElementById('login').addEventListener('click', () => {
+  auth0.checkSession({}, function(err, authResult) {
+    // Authentication tokens or error
+  });
+});
+```
+
+### auth0-spa-js
+
+The Auth0 SPA SDK handles Access Token refresh for you. Every time you call `getTokenSilently`, you'll either get a valid Access Token or an error if there's no session at Auth0.
+
+* [Auth0Client.getTokenSilently()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokensilently)
+
+```js
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.getTokenSilently();
+});
+```
+
+## Get a token for a different audience or with more scopes
+
+### auth0.js
+
+* [checkSession()](https://auth0.github.io/auth0.js/global.html#checkSession)
+
+```js
+document.getElementById('login').addEventListener('click', () => {
+  auth0.checkSession({
+    audience: 'https://mydomain/another-api/',
+    scope: 'read:messages'
+  }, function(err, authResult) {
+    // Authentication tokens or error
+  });
+});
+```
+
+### auth0-spa-js
+
+The Auth0 SPA SDK handles Access Token refresh for you. Every time you call `getTokenSilently`, you'll either get a valid Access Token or an error if there's no session at Auth0.
+
+* [Auth0Client.getTokenSilently()](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokensilently)
+* [GetTokenSilentlyOptions](https://auth0.github.io/auth0-spa-js/interfaces/gettokensilentlyoptions.html)
+
+```js
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.getTokenSilently({
+    audience: 'https://mydomain/another-api/',
+    scope: 'read:messages'
+  });
+});
+```
+
+Use [getTokenWithPopup](https://auth0.github.io/auth0-spa-js/classes/auth0client.html#gettokenwithpopup) to open a popup and allow the user to consent to the new API:
+
+```js
+document.getElementById('login').addEventListener('click', async () => {
+  await auth0.getTokenWithPopup({
+    audience: 'https://mydomain/another-api/',
+    scope: 'read:messages'
+  });
+});
+```
diff --git a/ja-jp/articles/libraries/auth0-swift/database-authentication.md b/ja-jp/articles/libraries/auth0-swift/database-authentication.md
new file mode 100644
index 0000000000..039f9467b1
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/database-authentication.md
@@ -0,0 +1,64 @@
+---
+section: libraries
+toc: true
+description: Using database connections with Auth0.Swift
+topics:
+  - libraries
+  - swift
+  - db-connections
+contentType: how-to
+useCase: enable-mobile-auth
+---
+
+# Using Database Connections with Auth0.Swift
+
+::: panel-warning Database authentication on Native Platforms
+Username/Email & Password authentication from native applications is disabled by default for new tenants as of 8 June 2017. Users are encouraged to use Universal Login and perform Web Authentication instead. If you still want to proceed you'll need to enable the Password Grant Type on your dashboard first. See [Application Grant Types](/applications/concepts/application-grant-types) for more information.
+:::
+
+The Authentication API provides methods to authenticate and sign up database users.
+
+## Signing up with a database connection
+
+Signing up requires calling the  `createUser` method, passing the user's given `email`, `password`, and the `connection` name to initiate the signup process. You can also specify additional user metadata to store.
+
+```swift
+Auth0
+    .authentication()
+    .createUser(
+        email: "support@auth0.com",
+        password: "secret-password",
+        connection: "Username-Password-Authentication",
+        userMetadata: ["first_name": "First",
+                       "last_name": "Last"])
+    .start { result in
+        switch result {
+        case .success(let user):
+            print("User: \(user)")
+        case .failure(let error):
+            print("Failed with \(error)")
+        }
+    }
+```
+
+## Login with a database connection
+
+Logging in with a database connection requires calling `login` with the user's username/email, password, and the name of the connection (such as `Username-Password-Authentication`) you wish to authenticate with. The response will be a Credentials object.
+
+```swift
+Auth0
+    .authentication()
+    .login(
+        usernameOrEmail: "support@auth0.com",
+        password: "secret-password",
+        realm: "Username-Password-Authentication",
+        scope: "openid")
+     .start { result in
+         switch result {
+         case .success(let credentials):
+            print("Credentials: \(credentials)")
+         case .failure(let error):
+            print("Failed with \(error)")
+         }
+     }
+```
diff --git a/ja-jp/articles/libraries/auth0-swift/index.md b/ja-jp/articles/libraries/auth0-swift/index.md
new file mode 100644
index 0000000000..bc88fd539e
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/index.md
@@ -0,0 +1,243 @@
+---
+section: libraries
+toc: true
+description: How to install, initialize and use Auth0.Swift
+url: /libraries/auth0-swift
+topics:
+  - libraries
+  - swift
+contentType:
+    - how-to
+    - index
+useCase: enable-mobile-auth
+---
+
+# Auth0.swift
+
+Auth0.swift is a client-side library for Auth0.
+
+::: note
+Check out the [Auth0.swift repository](https://github.com/auth0/Auth0.swift) on GitHub.
+:::
+
+## Requirements
+
+- iOS 9+ / macOS 10.11+ / tvOS 9.0+ / watchOS 2.0+
+- Xcode 11.4+ / 12.x
+- Swift 4.x / 5.x
+
+## Installation
+
+### Cocoapods
+
+If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 1.0'
+```
+
+Then run `pod install`.
+
+::: note
+For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Carthage
+
+If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`:
+
+```ruby
+github "auth0/Auth0.swift" ~> 1.0
+```
+
+Then run `carthage bootstrap`.
+
+::: note
+For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+:::
+
+### SPM
+
+If you are using the Swift Package Manager, open the following menu item in Xcode:
+
+**File > Swift Packages > Add Package Dependency...**
+
+In the **Choose Package Repository** prompt add this url: 
+
+```text
+https://github.com/auth0/Auth0.swift.git
+```
+
+Then press **Next** and complete the remaining steps.
+
+::: note
+For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app).
+:::
+
+## Adding Auth0 Credentials
+
+You will need to add an `Auth0.plist` file, containing your Auth0 client id and domain, to your main bundle. Here is an example of the file contents:
+
+```xml
+
+
+
+
+   ClientId
+   ${account.clientId}
+   Domain
+   ${account.namespace}
+
+
+```
+
+### Web-based Auth (iOS / macOS 10.15+)
+
+First go to [Auth0 Dashboard](${manage_url}/#/applications) and go to application's settings. Make sure you have in **Allowed Callback URLs** a URL with the following format:
+
+```text
+{YOUR_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{YOUR_BUNDLE_IDENTIFIER}/callback
+```
+
+In your application's `Info.plist` file register your iOS Bundle Identifier as a custom scheme like this:
+
+```xml
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        auth0
+        CFBundleURLSchemes
+        
+            {YOUR_BUNDLE_IDENTIFIER}
+        
+    
+
+```
+
+::: note
+If your `Info.plist` is not shown in this format, you can **Right Click** on `Info.plist` in Xcode and then select **Open As / Source Code**.
+:::
+
+::: note
+Auth0.swift will only handle URLs with your Auth0 domain as host, for example `com.auth0.MyApp://samples.auth0.com/ios/com.auth0.MyApp/callback`
+:::
+
+Allow Auth0 to handle authentication callbacks. In your `AppDelegate.swift`, add the following:
+
+##### iOS
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any]) -> Bool {
+    return Auth0.resumeAuth(url)
+}
+```
+
+##### macOS
+
+```swift
+func application(_ application: NSApplication, open urls: [URL]) {
+    Auth0.resumeAuth(urls)
+}
+```
+
+#### Authenticate with Universal Login
+
+The first step in adding authentication to your application is to provide a way for your users to log in. The fastest, most secure, and most feature-rich way to do this with Auth0 is to use Universal Login.
+
+::: note
+For more information on the two types of login flows, please refer to [Browser-Based vs. Native Login Flows on Mobile Devices](/design/browser-based-vs-native-experience-on-mobile)
+:::
+
+```swift
+Auth0
+    .webAuth()
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result { // Auth0.Result
+        case .success(let credentials):
+            print("Credentials: \(credentials)")
+        case .failure(let error):
+            print(error)
+        }
+    }
+```
+
+::: warning
+If you're using **Swift 5+**, `Auth0.Result` may shadow Swift's `Result` type. To prevent that, replace it with `Swift.Result` whenever you want to refer to Swift's built-in type. This will be fixed in the next major version of Auth0.swift.
+:::
+
+::: note
+To ensure a response that complies with OpenID Connect (OIDC), you must either request an `audience` or enable the **OIDC Conformant** switch in your [Auth0 dashboard](${manage_url}), under **Application > Settings > Show Advanced Settings > OAuth**. For more information, refer to [How to use the new flows](/api-auth/tutorials/adoption#how-to-use-the-new-flows).
+:::
+
+#### Authenticate with a specific Auth0 connection
+
+The `connection` option allows you to specify a connection that you wish to authenticate with. If no connection is specified here, the browser will show the login page, with all of the connections which are enabled for this application.
+
+```swift
+Auth0
+    .webAuth()
+    .connection("facebook")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        case .success(let credentials):
+            print("Credentials: \(credentials)")
+        case .failure(let error):
+            print(error)
+        }
+    }
+```
+
+#### Authenticate using a specific scope
+
+Using scopes can allow you to return specific claims for specific fields in your request. Adding parameters to `scope` will allow you to add more scopes. The default scope is `openid`, and you should read our [documentation on scopes](/scopes/current) for further details about them.
+
+```swift
+Auth0
+    .webAuth()
+    .scope("openid email")
+    .connection("google-oauth2")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        case .success(let credentials):
+            print("Credentials: \(credentials)")
+        case .failure(let error):
+            print(error)
+        }
+    }
+```
+
+### Getting user information
+
+In order to retrieve a user's profile, you call the `userInfo` method and pass it the user's `accessToken`.  Although the call returns a [UserInfo](https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift) instance, this is a basic OIDC conformant profile and the only guaranteed claim is the `sub`, which contains the user's ID. Depending on the requested scope, the claims returned may vary.  You can also use the `sub` value to call the [Management API](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) and return a full user profile.
+
+```swift
+Auth0
+   .authentication()
+   .userInfo(withAccessToken: accessToken)
+   .start { result in
+       switch result {
+       case .success(let profile):
+           print("User Profile: \(profile)")
+       case .failure(let error):
+           print("Failed with \(error)")
+       }
+   }
+```
+
+## Next Steps
+
+Take a look at the following resources to see how the Auth0.swift SDK can be customized for your needs:
+
+::: next-steps
+* [Auth0.Swift Database Authentication](/libraries/auth0-swift/database-authentication)
+* [Auth0.Swift Passwordless Authentication](/libraries/auth0-swift/passwordless)
+* [Auth0.Swift Refresh Tokens](/libraries/auth0-swift/save-and-refresh-jwt-tokens)
+* [Auth0.Swift User Management](/libraries/auth0-swift/user-management)
+* [Auth0.Swift Touch ID / Face ID Authentication](/libraries/auth0-swift/touchid-authentication)
+:::
diff --git a/ja-jp/articles/libraries/auth0-swift/passwordless.md b/ja-jp/articles/libraries/auth0-swift/passwordless.md
new file mode 100644
index 0000000000..664f8e8d7f
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/passwordless.md
@@ -0,0 +1,109 @@
+---
+section: libraries
+toc: true
+description: Using Auth0.Swift in passwordless mode
+topics:
+  - libraries
+  - swift
+  - passwordless
+contentType: how-to
+useCase: enable-mobile-auth
+---
+
+# Passwordless Authentication with Auth0.Swift
+
+Passwordless authentication allows users to login using only an email address or phone number, reducing the friction that occurs when a user must remember a password. Passwordless authentication can be done via email or via SMS, and either by sending the user a code, or sending them a link which contains a code.
+
+To use Passwordless Authentication you need Auth0.Swift version `1.20.0` or greater.
+
+## How Passwordless works
+
+Passwordless requires two steps:
+
+1. Request the code
+2. Input the code
+
+When using links, the same thing happens, but in a slightly different way, because the user does not have to input a code themselves. The code is included in the URL.
+
+### Step 1: Request the code
+
+In this example, requesting the code is done by calling `startPasswordless` with the user's email, and the type of connection. The `type` parameter will default to `Code`. On success, you'll probably display a notice to the user that their code is on the way, and perhaps route them to a view to input that code.
+
+```swift
+Auth0
+   .authentication()
+   .startPasswordless(email: "support@auth0.com")
+   .start { result in
+       switch result {
+       case .success:
+           print("Sent OTP to support@auth0.com!")
+       case .failure(let error):
+           print(error)
+       }
+   }
+```
+
+### Step 2: Input the code
+
+Once the user has a code, they can input it. Call the `login` method, and pass in the user's email, the code they received, and the name of the connection in question. Upon success, you will receive a Credentials object in the response.
+
+```swift
+Auth0
+   .authentication()
+   .login(
+       email: "support@auth0.com", 
+       code: "123456", 
+       audience: "https://myapi.com/api",
+       scope: "openid email")
+   .start { result in
+       switch result {
+       case .success(let credentials):
+           print("Access Token: \(credentials.accessToken)")
+       case .failure(let error):
+           print(error)
+       }
+   }
+```
+
+If you used SMS, the call would be like:
+
+```swift
+Auth0
+   .authentication()
+   .login(
+       phoneNumber: "+4591131761367", 
+       code: "123456", 
+       audience: "https://myapi.com/api",
+       scope: "openid email")
+   .start { result in
+       switch result {
+       case .success(let credentials):
+           print("Access Token: \(credentials.accessToken)")
+       case .failure(let error):
+           print(error)
+       }
+   }
+```
+
+## Passwordless parameters
+
+Passwordless authentication can be started with a variety of different parameters.
+
+For example:
+
+```swift
+.startPasswordless(email: String, type: String, connection: String)
+```
+
+or
+
+```swift
+.startPasswordless(phoneNumber: String, type: String, connection: String)
+```
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `email` | required | (String) Either `email` or `phoneNumber` is required (not both), depending on which will be used. |
+| `phoneNumber` | required | (String) Either `email` or `phoneNumber` is required (not both), depending on which will be used. |
+| `type` | optional | (String)  The type of Passwordless transaction to use, either `.Code` or `.iOSLink`. Defaults to `.Code`. |
+| `connection` | optional | (String)  The name of the connection to use for the Passwordless authentication. Defaults to `sms` for the SMS overload or to `email` for the email overload |
diff --git a/ja-jp/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md b/ja-jp/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md
new file mode 100644
index 0000000000..c633a9c650
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md
@@ -0,0 +1,135 @@
+---
+section: libraries
+description: Keeping your user logged in with Auth0.swift
+topics:
+  - libraries
+  - swift
+  - tokens
+contentType: how-to
+useCase: enable-mobile-auth
+---
+
+# Auth0.swift Saving and Renewing Tokens
+
+When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new token without asking for credentials again.
+
+## Credentials Manager
+
+[Auth0.swift](https://github.com/auth0/Auth0.swift) provides a utility class to streamline the process of storing and renewing credentials. You can access the `accessToken` or `idToken` properties from the [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) instance. This is the preferred method to manage user credentials.
+
+First import the `Auth0` module:
+
+```swift
+import Auth0
+```
+
+Next present the Universal Login page:
+
+```swift
+let credentialsManager = CredentialsManager(authentication: Auth0.authentication())
+
+Auth0
+    .webAuth()
+    .scope("openid profile offline_access")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        case .failure(let error):
+            // Handle error
+        case .success(let credentials):
+            // Pass the credentials over to the Credentials Manager
+            credentialsManager.store(credentials: credentials)
+        }
+}
+```
+
+::: warning
+The Keychain items do not get deleted after your app is uninstalled. We recommend to always clear all of your app's Keychain items on first launch.
+:::
+
+### Credentials Check
+
+It can be useful to perform a quick sanity check to ensure that you have valid credentials stored in the manager. If not, the user can then be directed to authenticate.
+
+```swift
+guard credentialsManager.hasValid() else {
+    // Present login screen
+}
+```
+
+### Retrieving User Credentials
+
+You can retrieve the user's credentials as follows:
+
+```swift
+credentialsManager.credentials { error, credentials in
+    guard error == nil, let credentials = credentials else {
+        // Handle error, present login page
+    }
+    // Valid credentials; you can access token properties such as `idToken`, `accessToken`.
+}
+```
+
+::: note
+Renewing a user's credentials works exactly the same way if the token has expired. The Credentials Manager will automatically renew the credentials, store the renewed credentials to the Keychain, then return them in the closure.
+:::
+
+## Alternative Method - SimpleKeychain
+
+If you are familiar with Lock v1, you may already be using the [SimpleKeychain](https://github.com/auth0/SimpleKeychain) SDK to handle iOS Keychain read/write access. This section is for developers who would prefer to keep using the SimpleKeychain and not upgrade to the preferred Credentials Manager.
+
+The first thing you will do is store the tokens you need. In this case, you will store the `access_token` and `refresh_token` in the Keychain after a successful authentication.
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+
+Auth0
+    .webAuth()
+    .scope("openid profile offline_access")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        case .failure(let error):
+            // Handle error
+        case .success(let credentials):
+            guard let accessToken = credentials.accessToken, 
+              let refreshToken = credentials.refreshToken else { 
+                // Handle error 
+                return
+            }
+            keychain.setString(accessToken, forKey: "access_token")
+            keychain.setString(refreshToken, forKey: "refresh_token")
+            // You might want to route to a user profile screen at this point
+        }
+}
+```
+
+Once you have those stored, you can at any point request a fresh [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Credentials.swift) instance.
+
+### Renewing User Credentials
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+
+Auth0
+    .authentication()
+    .renew(withRefreshToken: refreshToken)
+    .start { result in
+        switch(result) {
+        case .success(let credentials):
+            // If you have Refresh Token Rotation enabled, you get a new Refresh Token
+            // Otherwise you only get a new Access Token
+            guard let accessToken = credentials.accessToken, 
+              let refreshToken = credentials.refreshToken else { 
+                // Handle error 
+                return
+            }
+            // Store the new tokens
+            keychain.setString(accessToken, forKey: "access_token")
+            keychain.setString(refreshToken, forKey: "refresh_token")
+        case .failure(let error):
+            keychain.clearAll()
+            // Handle error
+        }
+}
+```
diff --git a/ja-jp/articles/libraries/auth0-swift/touchid-authentication.md b/ja-jp/articles/libraries/auth0-swift/touchid-authentication.md
new file mode 100644
index 0000000000..e86bcad058
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/touchid-authentication.md
@@ -0,0 +1,85 @@
+---
+section: libraries
+description: How to implement Touch ID / Face ID authentication with Auth0.swift.
+topics:
+  - libraries
+  - swift
+  - touch-id
+  - face-id
+contentType: how-to
+useCase: enable-mobile-auth
+---
+
+# Auth0.swift Touch ID / Face ID Authentication
+
+Here's the scenario: After user authentication, you want to store the user's credentials and use them as long as they are valid. Once they expire, you would want to renew them using the `refreshToken` in order to avoid presenting the login page again. Rather than doing this automatically, you require the user to validate with their fingerprint or face.
+
+You will be using the [Credentials Manager](https://github.com/auth0/Auth0.swift/blob/master/Auth0/CredentialsManager.swift) utility in [Auth0.swift](https://github.com/auth0/Auth0.swift/) to streamline the management of user credentials and perform biometric authentication.
+
+## Getting Started
+
+First, import the `Auth0` module:
+
+```swift
+import Auth0
+```
+
+### Credentials Manager
+
+Before retrieving credentials, you can also engage the biometric authentication (Face ID or Touch ID) supported by your iOS device.
+
+Begin by setting up the Credentials Manager. Then enable biometrics. You can also pass in a title to show in the prompt.
+
+```swift
+var credentialsManager = CredentialsManager(authentication: Auth0.authentication())
+credentialsManager.enableBiometrics(withTitle: "Touch ID / Face ID Login")
+```
+
+We strongly recommend that you add the [NSFaceIDUsageDescription](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW75) setting to your project's `Info.plist` to display a reason for using Face ID. In some cases, if you do not provide a description string and the user attempts Face ID authentication, the user's attempt may fail.
+
+```xml
+...
+NSFaceIDUsageDescription
+Reason why we use Face ID here
+...
+```
+
+### Login
+
+Present the Universal Login page and, upon successful authentication, pass the credentials to the Credentials Manager.
+
+```swift
+Auth0
+    .webAuth()
+    .scope("openid profile offline_access")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        case .failure(let error):
+            // Handle error
+        case .success(let credentials):
+            // Store credentials securely with the Credentials Manager
+            credentialsManager.store(credentials: credentials)
+        }
+}
+```
+
+### Renew User Credentials
+
+When you need to renew the user's credentials, you can call the `credentials` method from the Credentials Manager.
+
+```swift
+credentialsManager.credentials { error, credentials in
+    guard error == nil, let credentials = credentials else {
+        // Handle error
+        // Fallback to login screen
+    }
+    // Continue routing the user as authentication was successful
+}
+```
+
+There is no need manually store the new credentials as this is handled by the Credentials Manager during the renewal.
+
+## Next Steps
+
+You can download a sample project and follow the instructions in the iOS quickstart section on [Touch ID / Face ID in iOS](/quickstart/native/ios-swift/08-touch-id-authentication).
diff --git a/ja-jp/articles/libraries/auth0-swift/user-management.md b/ja-jp/articles/libraries/auth0-swift/user-management.md
new file mode 100644
index 0000000000..c2ad08deab
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0-swift/user-management.md
@@ -0,0 +1,92 @@
+---
+section: libraries
+toc: true
+description: User Management with Auth0.Swift
+topics:
+  - libraries
+  - swift
+  - users
+contentType: how-to
+useCase: enable-mobile-auth
+---
+
+# User Management with Auth0.Swift
+
+The Management API provides [User Account Linking](/users/concepts/overview-user-account-linking), which allows you to link and unlink separate user accounts from different providers, tying them to a single profile. It also allows you to update user metadata and other profile information.
+
+## Link users
+
+Linking user accounts will allow a user to authenticate from any of their accounts and, no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish for a user's accounts to be linked, this is the way to go.
+
+The `link` method accepts two parameters: the primary profile's user ID and the secondary profile's Access Token (the token obtained after login with this identity). The user ID in question is the unique identifier for this user account. If the ID is in the format `facebook|1234567890`, the ID required is the portion after the delimiting pipe (in this case, `1234567890`).
+
+```swift
+Auth0
+   .users(token: "user-scoped access token")
+   .link(userId, withOtherUserToken: "another user token")
+   .start { result in
+      switch result {
+      case .success(let userInfo):
+        print("User: \(userInfo)")
+      case .failure(let error):
+        print(error)
+      }
+   }
+```
+
+## Unlink users
+
+Unlinking users is a similar process to linking users. The `unlink` method takes three parameters: the secondary profile's user ID, the secondary profile's provider (the connection's identity provider), and the primary profile's user ID.
+The parameters read, essentially: "Unlink this **secondary user** (with this **provider**) from this **primary user**".
+
+```swift
+Auth0
+   .users(token: "user-scoped access token")
+   .unlink(identityId: identifier, provider: provider, fromUserId:userId)
+   .start { result in
+      switch result {
+      case .success(let userInfo):
+        print("User: \(userInfo)")
+      case .failure(let error):
+        print(error)
+      }
+   }
+```
+
+::: note
+Note that when accounts are linked, the metadata from the secondary account's profile is not merged with the metadata from the primary account's profile. Similarly, when unlinking accounts, the secondary account's profile does not retain metadata from the primary account's profile.
+:::
+
+## Retrieve user metadata
+
+```swift
+Auth0
+    .users(token: "user-scoped access token")
+    .get(userId, fields: ["user_metadata"], include: true)
+    .start { result in
+        switch result {
+        case .success(let userInfo):
+            print("User: \(userInfo)")
+        case .failure(let error):
+            print(error)
+        }
+    }
+```
+
+## Update user metadata
+
+When updating user metadata, you will create a `userMetadata` object and then call the `patch` method, passing it the user ID and the `userMetadata` object. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata.
+
+```swift
+Auth0
+    .users(token: "user-scoped access token")
+    .patch("user identifier", userMetadata: ["first_name": "John", "last_name": "Doe"])
+    .start { result in
+        switch result {
+        case .success(let userInfo):
+          print("User: \(userInfo)")
+        case .failure(let error):
+          print(error)
+        }
+    }
+```
diff --git a/ja-jp/articles/libraries/auth0js/index.yml b/ja-jp/articles/libraries/auth0js/index.yml
new file mode 100644
index 0000000000..44a74ecb88
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/index.yml
@@ -0,0 +1,7 @@
+versioning:
+  baseUrl: libraries/auth0js
+  current: v9
+  versions:
+    - v9
+  defaultArticles:
+    v9: index
diff --git a/ja-jp/articles/libraries/auth0js/v9/index.md b/ja-jp/articles/libraries/auth0js/v9/index.md
new file mode 100644
index 0000000000..4366c9d400
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/index.md
@@ -0,0 +1,580 @@
+---
+section: libraries
+toc: true
+title: auth0.js v9 Reference
+description: How to install, initialize and use auth0.js v9
+topics:
+  - libraries
+  - auth0js
+contentType:
+  - index
+  - how-to
+useCase: add-login
+---
+# auth0.js v9 Reference
+
+auth0.js is a client-side library for Auth0. It is recommended for use in single-page apps, preferably in conjunction with [Universal Login](/universal-login), which should be used whenever possible. Using auth0.js in your SPA makes it easier to do authentication and authorization with Auth0.
+
+The full API documentation for the library is [here](https://auth0.github.io/auth0.js/index.html).
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Ready-to-go example
+
+The [example directory](https://github.com/auth0/auth0.js/tree/master/example) of the auth0.js library is a ready-to-go app that can help you to quickly and easily try out auth0.js. In order to run it, follow these quick steps:
+
+1. If you don't have [node](http://nodejs.org/) installed, do that now
+1. Download dependencies by running `npm install` from the root of this project
+1. Finally, execute `npm start` from the root of this project, and then browse to your app running on the node server, presumably at `http://localhost:3000/example`.
+
+## Setup and initialization
+
+Now, let's get started integrating auth0.js into your project. We'll cover [methods of installation](#installation-options), [how to initialize auth0.js](#initialization), [signup](#signup), [login](#login), [logout](#logout), and more!
+
+<%= include('../../_includes/_configure_embedded_login', { library: 'Auth0.js v9' }) %>
+
+
+### Installation options
+
+You have a few options for using auth0.js in your project. Pick one of the below depending on your needs:
+
+Install via [npm](https://npmjs.org) or [yarn](https://yarnpkg.com):
+
+```sh
+npm install auth0-js
+
+yarn add auth0-js
+```
+
+Include via our CDN:
+
+```html
+
+```
+
+If you are using a bundler, you will want to install with `npm i auth0-js --production --save`.
+
+### Initialization
+
+Initialize a new instance of the Auth0 application as follows:
+
+```html
+
+```
+
+#### Available parameters
+
+There are two required parameters that must be passed in the `options` object when instantiating `webAuth`, and more that are optional.
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `domain` | required | (String) Your Auth0 account domain (ex. myaccount.auth0.com) |
+| `clientID` | required | (String) Your Auth0 client ID |
+| `redirectUri` | optional* | (String)  The default `redirectUri` used. Defaults to an empty string (none). **If you do not provide a global `redirectUri` value here, you will need to provide a redirectUri value for *each* method you use.** |
+| `scope` | optional | (String)  The default scope(s) used by the application. Using scopes can allow you to return specific claims for specific fields in your request. You should read our [documentation on scopes](/scopes) for further details. |
+| `audience` | optional | (String)  The default audience to be used for requesting API access. |
+| `responseType` | optional* | (String)  The default `responseType` used. It can be any space separated list of the values `code`, `token`, `id_token`. It defaults to `'token'`, unless a `redirectUri` is provided, then it defaults to `'code'`. **If you do not provide a global `responseType` value, you will need to provide a `responseType` value for *each* method you use.** |
+| `responseMode` | optional | (String)  This option is omitted by default. Can be set to `'form_post'` in order to send the token or code to the `'redirectUri'` via POST. Supported values are `query`, `fragment` and `form_post`. |
+| `leeway` | optional | (Integer) A value in seconds; leeway to allow for clock skew with regard to ID Token expiration times. |
+| `_disableDeprecationWarnings` | optional | (Boolean)  Disables the deprecation warnings, defaults to `false`. |
+
+::: note
+Because of clock skew issues, you may occasionally encounter the error `The token was issued in the future`. The `leeway` parameter can be used to allow a few seconds of leeway to ID Token expiration times, to prevent that from occurring.
+:::
+
+##### Scope
+
+The default `scope` value in auth0.js v9 is `openid profile email`.
+
+::: panel Running auth0.js Locally
+If you don't specify at least the above scope when initializing auth0.js, and you are running your website from `http://localhost` or `http://127.0.0.1`, calling the `getSSOData()` method will result in the following error in the browser console:
+
+`Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email`
+
+That will not happen when you run your application in production or if you specify the `openid profile email` scope. You can read more about this in the [User consent and third-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications) document.
+:::
+
+## Login
+
+You can choose a method for login based on the type of auth you need in your application.
+
+### webAuth.authorize()
+
+The `authorize()` method can be used for logging in users via Universal Login, or via social connections, as exhibited in the examples below. This method invokes the [/authorize endpoint](/api/authentication?javascript#social) of the Authentication API, and can take a variety of parameters via the `options` object.
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `audience` | optional | (String)  The default audience to be used for requesting API access. |
+| `connection` | optional | (String) Specifies the connection to use rather than presenting all connections available to the application. |
+| `scope` | optional | (String) The scopes which you want to request authorization for. These must be separated by a space. You can request any of the standard OIDC scopes about users, such as `profile` and `email`, custom claims that must [conform to a namespaced format](/tokens/guides/create-namespaced-custom-claims), or any scopes supported by the target API (for example, `read:contacts`). Include `offline_access` to get a Refresh Token. |
+| `responseType` | optional | (String) It can be any space separated list of the values `code`, `token`, `id_token`.  It defaults to `'token'`, unless a `redirectUri` is provided, then it defaults to `'code'`. |
+| `clientID` | optional | (String)  Your Auth0 client ID. |
+| `redirectUri` | optional | (String) The URL to which Auth0 will redirect the browser after authorization has been granted for the user. |
+| `state` | optional | (String)  An arbitrary value that should be maintained across redirects. It is useful to mitigate CSRF attacks and for any contextual information (for example, a return URL) that you might need after the authentication process is finished. For more information, see [State Parameter](/protocols/oauth2/oauth-state). auth0.js, when used in single-page applications, handles the state generation and validation automatically if not specified. |
+| `prompt` | optional | (String) A value of `login` will force the login page to show regardless of current session. A value of `none` will attempt to bypass the login prompts if a session already exists (see the [silent authentication](/sso/current/single-page-apps#silent-authentication) documentation for more details). |
+
+For hosted login, one must call the `authorize()` method.
+
+```js
+webAuth.authorize({
+  //Any additional options can go here
+});
+```
+
+For social logins, the `connection` parameter will need to be specified:
+
+```js
+webAuth.authorize({
+  connection: 'twitter'
+});
+```
+
+### webAuth.popup.authorize()
+
+For popup authentication the `popup.authorize` method can be used.
+
+Hosted login with popup:
+
+```js
+webAuth.popup.authorize({
+  redirectUri: 'https://YOUR_APP/popup_response_handler.html'
+  //Any additional options can go here
+}, function(err, authResult) {
+  //do something
+});
+```
+
+And for social login with popup using `authorize`:
+
+```js
+webAuth.popup.authorize({
+  redirectUri: 'https://YOUR_APP/popup_response_handler.html',
+  connection: 'twitter'
+}, function(err, authResult) {
+  //do something
+});
+```
+
+#### Handling popup authentication results
+
+When using popup authentication, you'll have to provide a `redirectUri` where the destination page communicates the authorization results back to the callback by using the `webAuth.popup.callback` method. A simple implementation would be something like this:
+
+```HTML
+
+
+  
+    
+    
+  
+
+```
+
+An ideal handler would contain just this minimal functionality (i.e. avoid reloading the whole application just to handle the response). 
+You will need to add the `redirectUri` to the application's **Allowed Callback URLs** list in the application configuration page on the Dashboard.
+
+### webAuth.login()
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+The `login` method allows for [cross-origin authentication](/cross-origin-authentication) for database connections, using `/co/authenticate`.
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `username` | optional | (String) The username to present for authentication. **Either** `username` or `email` must be present. |
+| `email` | optional | (String) The email to present for authentication. **Either** `username` or `email` must be present.|
+| `password` | required | (String) The password to present for authentication. |
+| `realm` | required | (String) The name of the database connection against which to authenticate. See [realm documentation](/api-auth/tutorials/password-grant#realm-support) for more information |
+
+```js
+webAuth.login({
+  realm: 'tests',
+  username: 'testuser',
+  password: 'testpass',
+});
+```
+
+### webAuth.crossOriginVerification()
+
+The `crossOriginVerification()` method can be used to help provide cross-origin authentication to customers who have third-party cookies disabled in their browsers. Further details about its usage can be read in the [cross-origin authentication](/cross-origin-authentication#create-a-cross-origin-fallback-page) document.
+
+### buildAuthorizeUrl(options)
+
+The `buildAuthorizeUrl` method can be used to build the `/authorize` URL, in order to initialize a new transaction. Use this method if you want to implement browser based (passive) authentication.
+
+```js
+// Calculate URL to redirect to
+var url = webAuth.client.buildAuthorizeUrl({
+  clientID: '${account.clientId}', // string
+  responseType: 'token id_token', // code
+  redirectUri: '${account.callback}',
+  state: 'YOUR_STATE',
+  nonce: 'YOUR_NONCE'
+});
+
+// Redirect to url
+// ...
+```
+
+::: note
+The `state` parameter is an opaque value that Auth0 will send back to you. This method helps prevent CSRF attacks, and it needs to be specified if you redirect to the URL yourself instead of calling `webAuth.authorize()`. For more information, see [State Parameter](/protocols/oauth2/oauth-state).
+:::
+
+<%= include('../../_includes/_embedded_sso') %>
+
+## Passwordless login
+
+Passwordless authentication allows users to log in by receiving a one-time password via email or text message. The process will require you to start the Passwordless process, generating and dispatching a code to the user, (or a code within a link), followed by accepting their credentials via the verification method. That could happen in the form of a login screen which asks for their (email or phone number) and the code you just sent them. It could also be implemented in the form of a Passwordless link instead of a code sent to the user. They would simply click the link in their email or text and it would hit your endpoint and verify this data automatically using the same verification method (just without manual entry of a code by the user).
+
+In order to use Passwordless, you will want to initialize auth0.js with a `redirectUri` and to set the `responseType: 'token'`.
+
+```js
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: 'http://example.com',
+  responseType: 'token id_token'
+});
+```
+
+### Start passwordless
+
+The first step in Passwordless authentication with auth0.js is the `passwordlessStart` method, which has several parameters which can be passed within its `options` object:
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `connection` | required | (String) Specifies how to send the code/link to the user. Value must be either `email` or `sms`. |
+| `send` | required | (String) Value must be either `code` or `link`. If `null`, a link will be sent. |
+| `phoneNumber` | optional | (String) The user's phone number for delivery of a code or link via SMS. |
+| `email` | optional | (String) The user's email for delivery of a code or link via email. |
+
+Note that exactly _one_ of the optional `phoneNumber` and `email` parameters must be sent in order to start the Passwordless transaction.
+
+```js
+webAuth.passwordlessStart({
+    connection: 'email',
+    send: 'code',
+    email: 'foo@bar.com'
+  }, function (err,res) {
+    // handle errors or continue
+  }
+);
+```
+
+### Passwordless Login
+
+If sending a code, you will then need to prompt the user to enter that code. You will process the code, and authenticate the user, with the `passwordlessLogin` method, which has several parameters which can be sent in its `options` object:
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `connection` | required | (String) Specifies how to send the code/link to the user. Value must be either `email` or `sms` and the same as the value passed to `passwordlessStart`. |
+| `verificationCode` | required | (String) The code sent to the user, either as a code or embedded in a link. |
+| `phoneNumber` | optional | (String) The user's phone number to which the code or link was delivered via SMS. |
+| `email` | optional | (String) The user's email to which the code or link was delivered via email. |
+
+As with `passwordlessStart`, exactly _one_ of the optional `phoneNumber` and `email` parameters must be sent in order to verify the Passwordless transaction.
+
+::: note
+In order to use `passwordlessLogin`, the options `redirectUri` and `responseType` must be specified when first initializing WebAuth.
+:::
+
+```js
+webAuth.passwordlessLogin({
+    connection: 'email',
+    email: 'foo@bar.com',
+    verificationCode: '389945'
+  }, function (err,res) {
+    // handle errors or continue
+  }
+);
+```
+
+## Extract the authResult and get user info
+
+After authentication occurs, you can use the `parseHash` method to parse a URL hash fragment when the user is redirected back to your application in order to extract the result of an Auth0 authentication response. You may choose to handle this in a callback page that will then redirect to your main application, or in-page, as the situation dictates.
+
+The `parseHash` method takes an `options` object that contains the following parameters:
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `state` | optional | (String) An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value is used by auth0.js to prevent CSRF attacks. |
+| `nonce` | optional | (String) Used to verify the ID Token
+| `hash` | optional | (String) The URL hash (if not provided, `window.location.hash` will be used by default) |
+
+The contents of the authResult object returned by `parseHash` depend upon which authentication parameters were used. It can include:
+
+| **Item** | **Description** |
+| --- | --- |
+| `accessToken` | An Access Token for the API, specified by the `audience` |
+| `expiresIn` |  A string containing the expiration time (in seconds) of the `accessToken` |
+| `idToken` |  An ID Token JWT containing user profile information |
+
+```js
+webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) {
+  if (err) {
+    return console.log(err);
+  }
+
+  webAuth.client.userInfo(authResult.accessToken, function(err, user) {
+    // Now you have the user's information
+  });
+});
+```
+
+As shown above, the `client.userInfo` method can be called passing the returned `accessToken`. It will make a request to the `/userinfo` endpoint and return the `user` object, which contains the user's information, formatted similarly to the below example.
+
+```json
+{
+    "sub": "auth0|123456789012345678901234",
+    "nickname": "johnfoo",
+    "name": "johnfoo@gmail.com",
+    "picture": "https://gravatar.com/avatar/example.png",
+    "updated_at": "2018-05-07T14:16:52.013Z",
+    "email": "johnfoo@gmail.com",
+    "email_verified": "false"
+}
+```
+
+You can now do something else with this information as your application needs, such as acquire the user's entire set of profile information with the Management API, as described below.
+
+## Using nonces
+
+By default (and if `responseType` contains `id_token`), `auth0.js` will generate a random `nonce` when you call `webAuth.authorize`, store it in local storage, and pull it out in `webAuth.parseHash`. The default behavior should work in most cases, but some use cases may require a developer to control the `nonce`.
+If you want to use a developer generated `nonce`, then you must provide it as an option to both `webAuth.authorize` and `webAuth.parseHash`.
+
+```js
+webAuth.authorize({nonce: '1234', responseType: 'token id_token'});
+webAuth.parseHash({nonce: '1234'}, callback);
+```
+
+If you're calling `webAuth.checkSession` instead of `webAuth.authorize`, then you only have to specify your custom `nonce` as an option to `checkSession`:
+
+```js
+webAuth.checkSession({
+  nonce: '1234',
+}, function (err, authResult) {
+    ...
+});
+```
+
+The `webAuth.checkSession` method will automatically verify that the returned ID Token's `nonce` claim is the same as the option.
+
+<%= include('../../../_includes/_co_authenticate_errors', { library : 'Auth0.js v9'}) %>
+
+## Logout
+
+To log out a user, use the `logout` method. This method accepts an options object, which can include the following parameters.
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `returnTo` | optional | (String) URL to redirect the user to after the logout. |
+| `clientID` | optional | (String) Your Auth0 client ID |
+| `federated` | optional | (Querystring parameter) Add this querystring parameter to the logout URL, to log the user out of their identity provider, as well: `https://${account.namespace}/v2/logout?federated`. |
+
+::: panel returnTo parameter
+Note that if the `clientID` parameter is included, the `returnTo` URL that is provided must be listed in the Application's **Allowed Logout URLs** in the [Auth0 dashboard](${manage_url}). However, if the `clientID` parameter _is not_ included, the `returnTo` URL must be listed in the **Allowed Logout URLs** at the *account level* in the [Auth0 dashboard](${manage_url}).
+:::
+
+```js
+webAuth.logout({
+  returnTo: 'some url here',
+  clientID: 'some client ID here'
+});
+```
+
+## Signup
+
+To sign up a user, use the `signup` method. This method accepts an options object, which can include the following parameters.
+
+| **Parameter** | **Required** | **Description** |
+| --- | --- | --- |
+| `email` | required | (String) User's email address |
+| `password` | required | (String) User's desired password |
+| `username` | required\* | (String) User's desired username. 
    \*Required if you use a database connection and you have enabled **Requires Username** |
+| `connection` | required | (String) The database connection name on your application upon which to attempt user account creation |
+| `user_metadata` | optional | (JSON object) Additional attributes used for user information. Will be stored in [user_metadata](/users/concepts/overview-user-metadata) |
+
+Signups should be for database connections. Here is an example of the `signup` method and some sample code for a form.
+
+```html
+
    Signup Database Connection
    
+
+
+
+
+```
+
+## Using checkSession to acquire new tokens
+
+The `checkSession` method allows you to acquire a new token from Auth0 for a user who is already authenticated against Auth0 for your domain. The method accepts any valid OAuth2 parameters that would normally be sent to `authorize`. If you omit them, it will use the ones provided when initializing Auth0.
+
+The call to `checkSession` can be used to get a new token for the API that was specified as the audience when `webAuth` was initialized:
+
+```js
+webAuth.checkSession({}, function (err, authResult) {
+  // err if automatic parseHash fails
+  ...
+});
+```
+
+See [Extract the AuthResult and Get User Info](#extract-the-authresult-and-get-user-info) for the format of `authResult`.
+
+Or, the token can be acquired for a different API than the one used when initializing `webAuth` by specifying an `audience` and `scope`:
+
+```js
+webAuth.checkSession(
+  {
+    audience: `https://mydomain/another-api/˜`,
+    scope: 'read:messages'
+  }, function (err, authResult) {
+  // err if automatic parseHash fails
+  ...
+});
+```
+
+::: note
+Note that `checkSession()` triggers any [rules](/rules) you may have set up, so you should check on your rules in the [Dashboard](${manage_url}/#/rules) prior to using it.
+:::
+
+The actual redirect to `/authorize` happens inside an iframe, so it will not reload your application or redirect away from it.
+
+However, the browser **must** have third-party cookies enabled. Otherwise, **checkSession()** is unable to access the current user's session (making it impossible to obtain a new token without displaying anything to the user). The same will happen if users have [Safari's ITP enabled](/api-auth/token-renewal-in-safari).
+
+Remember to add the URL where the authorization request originates from, to the **Allowed Web Origins** list of your Auth0 application in the [Dashboard](${manage_url}) under your application's **Settings**.
+
+::: warning
+If the connection is a social connection and you are using Auth0 dev keys, the `checkSession` call will always return `login_required`.
+:::
+
+### Polling with checkSession()
+
+<%= include('../../../_includes/_checksession_polling') %>
+
+## Password reset requests
+
+If attempting to set up a password reset functionality, you'll use the `changePassword` method and pass in an "options" object, with a "connection" parameter and an "email" parameter.
+
+```js
+  $('.change_password').click(function () {
+    webAuth.changePassword({
+      connection: 'db-conn',
+      email:   'foo@bar.com'
+    }, function (err, resp) {
+      if(err){
+        console.log(err.message);
+      }else{
+        console.log(resp);
+      }
+    });
+  });
+```
+
+The user will then receive an email which will contain a link that they can follow to reset their password.
+
+## User management
+
+The Management API provides functionality that allows you to link and unlink separate user accounts from different providers, tying them to a single profile (See [User Account Linking](/users/concepts/overview-user-account-linking) for details.) It also allows you to update user metadata.
+
+To get started, you first need to obtain a an Access Token that can be used to call the Management API. You can do it by specifying the `https://${account.namespace}/api/v2/` audience when initializing auth0.js, in which case you will get the Access Token as part of the authentication flow.
+
+::: note
+If you use [custom domains](/custom-domains), you will need to instantiate a new copy of `webAuth` using your Auth0 domain rather than your custom one, for use with the Management API calls, as it only works with Auth0 domains.
+:::
+
+```js
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: 'http://example.com',
+  audience: `https://${account.namespace}/api/v2/`,
+  scope: 'read:current_user',
+  responseType: 'token id_token'
+});
+```
+
+You can also do so by using `checkSession()`:
+
+```
+webAuth.checkSession(
+  {
+    audience: `https://${account.namespace}/api/v2/`,
+    scope: 'read:current_user'
+  }, function(err, result) {
+     // use result.accessToken
+  }
+);
+```
+
+You must specify the specific scopes you need. You can ask for the following scopes:
+
+* `read:current_user`
+* `update:current_user_identities`
+* `create:current_user_metadata`
+* `update:current_user_metadata`
+* `delete:current_user_metadata`
+* `create:current_user_device_credentials`
+* `delete:current_user_device_credentials`
+
+Once you have the Access Token, you can create a new `auth0.Management` instance by passing it the account's Auth0 domain, and the Access Token.
+
+```js
+var auth0Manage = new auth0.Management({
+  domain: '${account.namespace}',
+  token: 'ACCESS_TOKEN'
+});
+```
+
+### Getting the user profile
+
+In order to get the user profile data, use the `getUser()` method, with the `userId` and a callback as parameters. The method returns the user profile. Note that the `userID` required here will be the same one fetched from the `client.userInfo` method.
+
+```js
+auth0Manage.getUser(userId, cb);
+```
+
+### Updating the user profile
+
+When updating user metadata, you will need to first create a `userMetadata` object, and then call the `patchUserMetadata` method, passing it the user id and the `userMetadata` object you created. The values in this object will overwrite existing values with the same key, or add new ones for those that don't yet exist in the user metadata. See the [Metadata](/users/concepts/overview-user-metadata) documentation for more details on user metadata.
+
+```js
+auth0Manage.patchUserMetadata(userId, userMetadata, cb);
+```
+
+### Linking users
+
+Linking user accounts will allow a user to authenticate from any of their accounts and no matter which one they use, still pull up the same profile upon login. Auth0 treats all of these accounts as separate profiles by default, so if you wish a user's accounts to be linked, this is the way to go.
+
+The `linkUser` method accepts two parameters, the primary `userId` and the secondary user's ID Token (the token obtained after login with this identity). The user ID in question is the unique identifier for the primary user account. The ID should be passed with the provider prefix, e.g., `auth0|1234567890` or `facebook|1234567890`, when using this method. See [User Account Linking](/users/concepts/overview-user-account-linking) for details.
+
+```js
+auth0Manage.linkUser(userId, secondaryUserToken, cb);
+```
+
+After linking the accounts, the second account will no longer exist as a separate entry in the user database, and will only be accessible as part of the primary one.
+
+::: note
+Note that when accounts are linked, the secondary account's metadata is **not** merged with the primary account's metadata, and if they are ever unlinked, the secondary account will likewise not retain the primary account's metadata when it becomes separate again.
+:::
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-angular.md b/ja-jp/articles/libraries/auth0js/v9/migration-angular.md
new file mode 100644
index 0000000000..ee64ca6012
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-angular.md
@@ -0,0 +1,21 @@
+---
+section: libraries
+title: Migrating Angular applications to Auth0.js v9
+description: How to migrate Angular applications to Auth0.js v9
+public: false
+topics:
+  - libraries
+  - auth0js
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 2+ Applications to Auth0.js v9
+
+Angular 2+ applications can use auth0.js directly without any kind of wrapper library.
+
+All Angular 2+ applications will be using auth0.js v8, so you can follow the [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9) guide.
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v6.md b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v6.md
new file mode 100644
index 0000000000..b87b3568e6
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v6.md
@@ -0,0 +1,22 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications From auth0.js v6 to v9
+description: How to migrate Angular 1.x Applications From auth0.js v6 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x applications from Auth0.js v6 to v9
+
+The [auth0.js](/libraries/auth0js) v6 API is the same as the v7 one. 
+
+You can use the [Migrating Angular 1.x Applications from Auth0.js v7 to v9](/libraries/auth0js/v9/migration-angular-v7) to understand how your application code needs to be adjusted.
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v7.md b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v7.md
new file mode 100644
index 0000000000..6020f63d6c
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v7.md
@@ -0,0 +1,51 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications From auth0.js v7 to v9
+description: How to migrate Angular 1.x Applications From auth0.js v7 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x applications from Auth0.js v7 to v9
+
+This guide includes all the information you need to update auth0.js from v7 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide).
+
+## Migration Steps
+
+### Update angular-auth0
+
+Angular 1.x applications usually use the [angular-auth0 package](https://www.npmjs.com/package/angular-auth0)when authenticating with Auth0. If you are using auth0.js v7, you should be using the v1 of that package. To use auth0.js v9 you need to update to the latest version (3.x).
+
+You can update the angular-auth0 library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save angular-auth0
+ 
+# installation with yarn
+yarn add angular-auth0
+```
+
+The script files need to be added to your build system, or added to the project with a script tag.
+
+```html
+
+```
+
+<%= include('../../_includes/_get_auth0_js_latest_version') %>
+
+### Next steps
+
+The angular-auth0 library is just a thin wrapper over auth0.js, so you will need to adjust your code in the same way you do it when migrating a non-Angular project.
+
+You can find instructions on how to do it in the [How to migrate from Auth0.js v7 to v9](/libraries/auth0js/v9/migration-v7-v9).
+
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v8.md b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v8.md
new file mode 100644
index 0000000000..edea9b70ee
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-angularjs-v8.md
@@ -0,0 +1,51 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications From auth0.js v8 to v9
+description: How to migrate Angular 1.x Applications From auth0.js v8 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x applications from Auth0.js v8 to v9
+
+This guide includes all the information you need to update auth0.js from v8 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide).
+
+## Migration steps
+
+### Update angular-auth0
+
+Angular 1.x applications usually use the [angular-auth0 package](https://www.npmjs.com/package/angular-auth0)when authenticating with Auth0. To use auth0.js v9 you need to update to the latest version (3.x).
+
+You can update the angular-auth0 library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save angular-auth0
+ 
+# installation with yarn
+yarn add angular-auth0
+```
+
+The script files need to be added to your build system, or added to the project with a script tag.
+
+```html
+
+```
+
+<%= include('../../_includes/_get_auth0_js_latest_version') %>
+<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %>
+<%= include('../../_includes/_change_get_profile') %> 
+<%= include('../../_includes/_review_get_ssodata') %>
+
+## Behavioral changes
+
+<%= include('../../_includes/_default_values') %>
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-guide.md b/ja-jp/articles/libraries/auth0js/v9/migration-guide.md
new file mode 100644
index 0000000000..51c3f7a950
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-guide.md
@@ -0,0 +1,55 @@
+---
+section: libraries
+title: Migrating to Auth0.js v9
+description: How to migrate to Auth0.js v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating to Auth0.js v9
+
+[Auth0.js v9](/libraries/auth0js) has been improved to operate with enhanced security and removes dependencies that have been deprecated as per Auth0's roadmap. In some cases, these security enhancements may impact application behavior when upgrading from an earlier versions of auth0.js. 
+
+## Should I migrate to v9?
+
+Everyone should migrate to v9. All previous versions are deprecated, and the deprecated endpoints used by them were removed from service on August 6, 2018. For applications that use Auth0.js within an Auth0 login page, this migration is recommended; for applications with Auth0.js embedded within them, this migration is mandatory.
+
+## Migration Instructions
+
+The documents below describe all the changes that you should be aware of when migrating from different versions of Auth0.js to v9. Make sure you go through the relevant guide(s) before upgrading.
+
+* [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9)
+    * [Recommendations for migrating from Auth0.js v8 when Single Sign-on (SSO) is required](/guides/login/migration-sso)
+* [Migrating from Auth0.js v7](/libraries/auth0js/v9/migration-v7-v9)
+* [Migrating from Auth0.js v6](/libraries/auth0js/v9/migration-v6-v9)
+* [Migrating from Auth0.js v8 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v8)
+* [Migrating from Auth0.js v7 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v7)
+* [Migrating from Auth0.js v6 in Angular 1.x Applications](/libraries/auth0js/v9/migration-angularjs-v6)
+* [Migrating from Auth0.js v8 in Angular 2.x Applications](/libraries/auth0js/v9/migration-angular)
+* [Migrating from Auth0.js v8 in React.js Applications](/libraries/auth0js/v9/migration-react)
+
+If you have any questions or concerns, you can discuss them in the [Auth0 Community](https://community.auth0.com/), submit them using the [Support Center](${env.DOMAIN_URL_SUPPORT}), or directly through your account representative, if applicable. 
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Troubleshooting
+
+### I upgraded but I still get deprecation warnings in the logs
+
+You have already migrated to Auth0.js 9 but you still see this error in your logs:
+
+```text
+Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application.
+```
+
+These deprecation notices most likely originate from a user visiting the Universal Login [page](/universal-login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. After August 6, 2018, these users will not be able to log in. 
+
+See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors.
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-react.md b/ja-jp/articles/libraries/auth0js/v9/migration-react.md
new file mode 100644
index 0000000000..633c543fbb
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-react.md
@@ -0,0 +1,23 @@
+---
+section: libraries
+title: Migrating React Applications to Auth0.js v9
+description: How to migrate React applications to Auth0.js v9
+public: false
+topics:
+  - libraries
+  - auth0js
+  - migrations
+  - react
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating React Applications to Auth0.js v9
+
+React applications use auth0.js directly without any kind of wrapper library.
+
+Most React applications will be using auth0.js v8, so you can follow the [Migrating from Auth0.js v8](/libraries/auth0js/v9/migration-v8-v9) guide.
+
+If you were an early React and Auth0 adopter, and are using auth0.js v7, you can follow the [Migrating from Auth0.js v7](/libraries/auth0js/v9/migration-v7-v9) guide.
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-v6-v9.md b/ja-jp/articles/libraries/auth0js/v9/migration-v6-v9.md
new file mode 100644
index 0000000000..99375af3f5
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-v6-v9.md
@@ -0,0 +1,19 @@
+---
+section: libraries
+title: Migrating from Auth0.js v6 to v9
+description: How to migrate from Auth0.js v6 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Auth0.js v6 to v9
+
+The [auth0.js](/libraries/auth0js) v6 API is the same as the v7 one. You can use the [Migrating from Auth0.js v7 to v9 guide](/libraries/auth0js/v9/migration-v7-v9) to understand how your application code needs to be adjusted.
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-v7-v9.md b/ja-jp/articles/libraries/auth0js/v9/migration-v7-v9.md
new file mode 100644
index 0000000000..7a1c5bb666
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-v7-v9.md
@@ -0,0 +1,304 @@
+---
+section: libraries
+title: Migrating from Auth0.js v7 to v9
+description: How to migrate from Auth0.js v7 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Auth0.js v7 to v9
+
+This guide includes all the information you need to update [Auth0.js](/libraries/auth0js) from v7 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide).
+
+The [Auth0.js v7 to v8 Migration Guide](/libraries/auth0js/v8/migration-guide) has detailed information on how to migrate from v7 to v8, and that information is still valid, v7 is very similar to v9. This document will go over some common usage patterns, and focus on things that changed after that guide was created.
+
+## Migration Steps
+
+<%= include('../../_includes/_get_auth0_js_latest_version') %>
+
+## Using Auth0.js to Log In Users
+
+### Using Auth0.js v7
+
+```js
+var auth0 = new Auth0({
+  domain:'${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// With Universal Login
+auth0.login({});
+
+// With a social or enterprise connection
+auth0.login({
+  connection: 'twitter'
+});
+
+// With username and password
+auth0.login({
+  connection: 'my-db-connection',
+  username: 'the-username',
+  password: 'the-password'
+});
+```
+
+### Using Auth0.js v9
+
+```js
+var webAuth = new auth0.WebAuth({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token id_token'
+});
+
+// with Universal Login
+webAuth.authorize({});
+
+// with a social or enterprise connection
+webAuth.authorize({
+  connection: 'twitter'
+});
+
+// with username and password
+webAuth.login({
+  realm: 'my-db-connection',
+  username: 'the-username',
+  //email: 'the@email.com',
+  password: 'the-password'
+});
+```
+## Using Auth0.js to log in users in 'popup mode'
+
+### Using Auth0.js v7
+
+```js
+var auth0 = new Auth0({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// With Universal Login
+auth0.login({
+  popup: true
+});
+
+//with a social or enterprise connection
+auth0.login({
+  popup: true,
+  connection: 'twitter'
+});
+
+//with username and password
+auth0.login({
+  popup: true,
+  connection: 'my-db-connection',
+  username: 'the-username',
+  password: 'the-password'
+});
+```
+
+### Using Auth0.js v9
+
+```js
+var webAuth = new auth0.WebAuth({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// with Universal Login
+webAuth.popup.authorize({});
+
+// with a social or enterprise connection
+webAuth.popup.authorize({
+  connection: 'twitter'
+});
+
+// with username and password
+webAuth.popup.loginWithCredentials({
+  connection: 'my-db-connection',
+  username: 'the-username',
+  //email: 'the@email.com',
+  password: 'the-password'
+});
+```
+## Using Auth0.js to sign up users
+
+### Using Auth0.js v7
+
+```js
+var auth0 = new Auth0({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// signup only
+auth0.signup({
+  connection: 'my-db-connection',
+  username: 'the-username',
+  password: 'the-password',
+  auto_login: false
+}, function (err) {
+  if (err) return alert('Something went wrong: ' + err.message);
+  alert('success signup without login!')
+});
+
+// signup and login
+auth0.signup({
+  connection: 'my-db-connection',
+  username: 'the-username',
+  password: 'the-password',
+  auto_login: true
+}, function (err) {
+  if (err) alert('Something went wrong: ' + err.message);
+});
+```
+
+### Using Auth0.js v9
+
+```js 
+var webAuth = new auth0.WebAuth({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// signup only
+
+webAuth.signup({
+  connection: 'my-db-connection',
+  email: 'the-email',
+  password: 'the-password',
+  user_metadata: { plan: 'silver', team_id: 'a111' }
+}, function (err) {
+  if (err) return alert('Something went wrong: ' + err.message);
+  alert('success signup without login!')
+});
+
+// signup and login
+webAuth.redirect.signupAndLogin({
+  connection: 'my-db-connection',
+  email: 'the-email',
+  password: 'the-password',
+  user_metadata: { plan: 'silver', team_id: 'a111' }
+}, function(err) {
+  if (err) alert('Something went wrong: ' + err.message);
+});
+```
+
+## Using Auth0.js to log in users using passwordless
+
+### Using Auth0.js v7
+
+```js
+var auth0 = new Auth0({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  responseType: 'token'
+});
+
+// with a magic link sent via email
+auth0.requestMagicLink(
+  {
+    email: 'the@email.com'
+  },
+  function(err) {}
+);
+
+// with a code sent via email
+auth0.requestEmailCode(
+  {
+    email: 'the@email.com'
+  },
+  function(err) {}
+);
+
+// verifying the email code
+auth0.verifyEmailCode(
+  {
+    email: 'the@email.com',
+    code: 'the-code'
+  },
+  function(err, result) {}
+);
+
+// with a code sent via sms
+auth0.requestSMSCode(
+  {
+    phoneNumber: '+the_phone_number'
+  },
+  function(err) {}
+);
+
+// verifying the sms code
+auth0.verifySMSCode(
+  {
+    phoneNumber: '+the_phone_number',
+    code: 'the-code'
+  },
+  function(err, result) {}
+);
+```
+
+### Using Auth0.js v9
+
+```js
+var webAuth = new auth0.WebAuth({
+  domain: ''${account.namespace}'',
+  clientID: ''${account.clientId}'',
+  responseType: 'token'
+});
+
+// with a magic link sent via email
+webAuth.passwordlessStart({
+  send: 'link',
+  email: 'the@email.com',
+  connection: 'email'
+});
+
+// with a code sent via email
+webAuth.passwordlessStart({
+  send: 'code',
+  email: 'the@email.com',
+  connection: 'email'
+});
+
+// verifying the email code
+webAuth.passwordlessLogin({
+  email: 'the@email.com',
+  verificationCode: 'the-code',
+  connection: 'email'
+});
+
+// with a code sent via sms
+webAuth.passwordlessStart({
+  phoneNumber: '+the_phone_number',
+  connection: 'sms'
+});
+
+// verifying the sms code
+webAuth.passwordlessLogin({
+  phoneNumber: '+the_phone_number',
+  verificationCode: 'the-code',
+  connection: 'sms'
+});
+```
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %>
+<%= include('../../_includes/_review_get_ssodata') %>
+<%= include('../../_includes/_legacy_flows') %>
+
+## Behavioral Changes
+
+<%= include('../../_includes/_default_values') %>
diff --git a/ja-jp/articles/libraries/auth0js/v9/migration-v8-v9.md b/ja-jp/articles/libraries/auth0js/v9/migration-v8-v9.md
new file mode 100644
index 0000000000..2a40de08b2
--- /dev/null
+++ b/ja-jp/articles/libraries/auth0js/v9/migration-v8-v9.md
@@ -0,0 +1,44 @@
+---
+section: libraries
+title: Migrating to from Auth0.js v8 to v9
+description: How to migrate from Auth0.js v8 to v9
+public: false
+toc: true
+topics:
+  - libraries
+  - auth0js
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Auth0.js v8 to v9
+
+This guide includes all the information you need to update [Auth0.js](/libraries/auth0js) from v8 to v9. Find out if you should upgrade or not by reading [Migrating to Auth0.js v9](/libraries/auth0js/v9/migration-guide).
+
+## Migration demo
+
+
     
    
+
+## Migration steps
+
+<%= include('../../_includes/_migrate_universal') %>
+<%= include('../../_includes/_get_auth0_js_latest_version') %>
+<%= include('../../_includes/_configure_embedded_login', { library : 'Auth0.js v9'}) %>
+<%= include('../../_includes/_review_get_ssodata') %>
+
+#### Migration with getSSOData demo
+
+
     
    
+
+<%= include('../../_includes/_configure_custom_domain', { library : 'Auth0.js v9'}) %>
+
+<%= include('../../_includes/_legacy_flows') %>
+
+<%= include('../../_includes/_verifying_migration') %>
+
+## Behavioral Changes
+
+<%= include('../../_includes/_default_values') %>
diff --git a/ja-jp/articles/libraries/custom-signup.md b/ja-jp/articles/libraries/custom-signup.md
new file mode 100644
index 0000000000..fe0c3841bf
--- /dev/null
+++ b/ja-jp/articles/libraries/custom-signup.md
@@ -0,0 +1,183 @@
+---
+section: libraries
+description: How to customize the user signup form with additional fields using Lock or the Auth0 API.
+toc: true
+topics:
+  - libraries
+  - lock
+  - custom-signups
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Custom Signup
+
+You can customize the user signup form with more fields in addition to email and password when using Lock or the Auth0 API. 
+
+There are many factors to consider before you choose [Lock vs. Custom UI](/libraries/when-to-use-lock). For example, using Lock, you can redirect to another page to capture data or use progressive profiling. When using the Auth0 API, you can capture custom fields and store them in a database. There are certain limitations to the customization that should be considered when choosing the method that best suits your purpose. Some typical customizations include adding a username and verifying password strength.
+
+:::panel Universal Login
+Auth0 offers a Universal Login option that you can use instead of designing your own custom signup page. If you want to offer signup and login options, and you only need to customize the application name, logo and background color, then Universal Login via an Auth0 login page might be an easier option to implement. 
+:::
+
+## Using Lock
+
+Lock supports [custom fields signup](/libraries/lock/customization#additionalsignupfields-array-).
+
+![custom signup fields](/media/articles/libraries/lock/v10/signupcustom.png)
+
+Lock's `additionalSignUpFields` option will only work with database signups. For signups using social identity providers, collecting these fields in the same manner is not possible with Lock, but there are two other options to allow social IDP signups with Lock while still collecting additional custom fields.
+
+### Redirect to another page
+
+One way to use social provider signups with Lock and collect custom fields is to use [redirect rules](/rules/guides/redirect) to redirect the user to another page where you ask for extra information, and then redirect back to finish the authentication transaction.
+
+### Progressive profiling
+
+Another way to collect custom field data when signing users up with social providers is via [progressive profiling](/users/concepts/overview-progressive-profiling) whereby you can slowly build up user profile data over time. You collect the bare minimum details upon signup, but when a user later interacts with your app, you collect a small amount of data (perhaps one question) each time until their profile is complete. This allows you to collect the desired information but with less friction, since the goal of using a social IDP for signup is making it more effortless and streamlined for the user.
+
+## Using the API
+
+### Create a signup form to capture custom fields
+
+```html
+
    
+  
    
+    Sign up
+    
    
+      
+    
    
+    
    
+      
+    
    
+    
    
+      
+    
    
+    
    
+      
+    
    
+    
+  
    
+
    
+```
+
+The `name` is a user profile attribute and `color` is a custom field.
+
+::: note
+There is currently no way to validate user-supplied custom fields when signing up. Validation must be done from an Auth0 [Rule](/rules) at login, or with custom, **server-side** logic in your application.
+:::
+
+### Send the form data
+
+Send a POST request to the [/dbconnections/signup](/api/authentication/reference#signup) endpoint in Auth0. 
+
+You will need to send:
+- Your application's `client_id`
+- The `email` and `password` of the user being signed up
+- The name of the database `connection` to store your user's data
+- Any user profile attribute you want to update for the user, which can include `given_name`, `family_name`, `name`, `nickname`, and `picture`.
+- Any custom fields as part of `user_metadata`
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/dbconnections/signup",
+  "headers": [{
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"client_id\": \"${account.clientId}\",\"email\": \"$('#signup-email').val()\",\"password\": \"$('#signup-password').val()\",\"connection\": \"YOUR_CONNECTION_NAME\",\"name\": \"$('#name').val()\",\"user_metadata\": {\"color\": \"red\"}}"
+  }
+}
+```
+
+## Custom fields limitations
+
+When your users sign up, the custom fields are sent as part of `user_metadata`. The limitations of this field are:
+
+* `user_metadata` must contain no more than 10 fields
+* `user_metadata.field` must be a string
+* `user_metadata.field.value.length` must be fewer than 500 characters
+* `user_metadata.field.length` must be fewer than 100 characters
+* The current size limit for `user_metadata` is **16 MB**
+
+## Redirect mode
+
+After a successful login, Auth0 will redirect the user to your configured callback URL with a JWT (`id_token`) in the query string.
+
+::: note
+To learn more about the differences between popup and redirect modes, please refer to [this document](/libraries/lock/v10/popup-mode).
+:::
+
+```js
+window.auth0 = new Auth0({
+  domain: '${account.namespace}',
+  clientID: '${account.clientId}',
+  // Callback made to your server's callback endpoint
+  callbackURL: '${account.callback}',
+});
+```
+
+Your server will then need to call APIv2 to add the necessary custom fields to the user's profile.
+
+## Add username to the signup form
+
+One common signup customization is to add a username to the signup.
+
+To enable this feature, turn on the **Requires Username** setting on the [Connections > Database](${manage_url}/#/connections/database/) section of the dashboard under the **Settings** tab for the connection you wish to edit.
+
+Capture the `username` field in your custom form, and add the `username` to your request body.
+
+```html
+
    
+  
    
+    Sign up
+    
    
+      
+    
    
+    
    
+      
+    
    
+    
    
+      
+    
    
+    
+  
    
+
    
+```
+
+```js
+var settings = {
+  "async": true,
+  "crossDomain": true,
+  "url": "https://${account.namespace}/dbconnections/signup",
+  "method": "POST",
+  "headers": {
+    "content-type": "application/x-www-form-urlencoded"
+  },
+  "data": {
+    "client_id": "${account.clientId}",
+    "email": $('#signup-email').val(),
+    "password": $('#signup-password').val(),
+    "connection": "YOUR_CONNECTION_NAME",
+    "username": $('#username').val()
+  }
+}
+
+$.ajax(settings).done(function (response) {
+  console.log(response);
+});
+```
+
+## Optional: Verify password strength
+
+Password policies for database connections can be configured in the dashboard. For more information, see: [Password Strength in Auth0 Database Connections](/connections/database/password-strength).
+
+If required for implementation of custom signup forms, the configured password policies, along with other connection information, can be retrieved from the [Management v2 API](/api/management/v2#!/Connections/get_connections_by_id). The result can be parsed client-side, and will contain information about the current password policy (or policies) configured in the dashboard for that connection.
diff --git a/ja-jp/articles/libraries/error-messages.md b/ja-jp/articles/libraries/error-messages.md
new file mode 100644
index 0000000000..a6c1e29606
--- /dev/null
+++ b/ja-jp/articles/libraries/error-messages.md
@@ -0,0 +1,49 @@
+---
+section: libraries
+description: Describes common sign up and login errors that you might see when you authenticate users using Auth0 libraries.
+topics:
+  - libraries
+  - lock
+  - auth0js
+  - error-messages
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Common Auth0 Library Authentication Errors
+
+The actions or input data of your users, during the sign up or the log in processes, might trigger errors. Here is a list of the most common errors that you might get if you use any of the Auth0 libraries for authentication.
+
+## Sign up
+
+In the case of a failed signup, the most common errors are:
+
+| **Error** | **Description** |
+|-|-|
+| **invalid_password** | If the password used doesn't comply with the password policy for the connection |
+| **invalid_signup** | The user your are attempting to sign up is invalid |
+| **password_dictionary_error** | The chosen password is too common |
+| **password_no_user_info_error** | The chosen password is based on user information |
+| **password_strength_error** | The chosen [password is too weak](/connections/database/password-strength) |
+| **unauthorized** | If you cannot sign up for this application. May have to do with the violation of a specific rule |
+| **user_exists** | The user you are attempting to sign up has already signed up |
+| **username_exists** | The username you are attempting to sign up with is already in use |
+
+## Log in
+
+In the case of a failed login, the most common errors are:
+
+| **Error** | **Description** |
+|-|-|
+| **access_denied** | When using web-based authentication, the resource server denies access per OAuth2 specifications |
+| **invalid_user_password** | The username and/or password used for authentication are invalid |
+| **mfa_invalid_code** | The multi-factor authentication (MFA) code provided by the user is invalid/expired |
+| **mfa_registration_required** | The administrator has required [multi-factor authentication](/mfa), but the user has not enrolled |
+| **mfa_required** | The user must provide the [multi-factor authentication](/mfa) code to authenticate |
+| **password_leaked** | If the password has been leaked and a different one needs to be used |
+| **PasswordHistoryError** | The password provided for sign up/update has already been used (reported when [password history](/connections/database/password-options#password-history) feature is enabled) |
+| **PasswordStrengthError** | The password provided does not match the connection's [strength requirements](/connections/database/password-strength) |
+| **too_many_attempts** | The account is blocked due to too many attempts to sign in |
+| **unauthorized** | The user you are attempting to sign in with is blocked |
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/index.md b/ja-jp/articles/libraries/index.md
new file mode 100644
index 0000000000..cb41e46b6c
--- /dev/null
+++ b/ja-jp/articles/libraries/index.md
@@ -0,0 +1,79 @@
+---
+section: libraries
+classes: topic-page
+title: Auth0 Libraries
+description: Auth0 Libraries and SDKs overview
+topics:
+  - libraries
+  - lock
+  - auth0js
+contentType:
+    - index
+    - concept
+---
+
+
    
+
    
+
    Auth0 Libraries
    
+
      
+  Auth0 offers widgets and SDKs to provide a simple and frictionless experience for you when using Auth0. Take a look at the options listed to find documentation and links to repositories for the tools you need to get started.
+
    
+
    
+
+<%= include('../_includes/_embedded_login_warning') %>
+
+## Lock
+
+
+
+### Lock repositories and support status
+
+<%= include('../_includes/_libraries_support_lock') %>
+
+## SDKs
+
+
+
+### SDK repositories and support status
+
+<%= include('../_includes/_libraries_support_sdks') %>
+
+### Platform integration repositories and support status
+
+<%= include('../_includes/_libraries_support_frameworks') %>
+
+::: note
+Auth0 reserves the right to downgrade an SDK from **Supported** to **Community-Supported** at any time.
+:::
diff --git a/ja-jp/articles/libraries/lock-android/_includes/_lock-version.md b/ja-jp/articles/libraries/lock-android/_includes/_lock-version.md
new file mode 100644
index 0000000000..4c92f0862e
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/_includes/_lock-version.md
@@ -0,0 +1,3 @@
+::: version-warning
+This document covers an outdated version of Lock for Android. We recommend you to upgrade to v2.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/lock-android/_includes/_next-steps.md b/ja-jp/articles/libraries/lock-android/_includes/_next-steps.md
new file mode 100644
index 0000000000..98cf862b59
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/_includes/_next-steps.md
@@ -0,0 +1,11 @@
+## Lock for Android v1 Resources
+
+* [Lock v1 Configuration](/libraries/lock-android/v1/configuration)
+* [Lock v1 Use Your Own UI](/libraries/lock-android/v1/use-your-own-ui)
+* [Auth0 Error Messages](/libraries/error-messages)
+* [Lock v1 Native Social Authentication](/libraries/lock-android/v1/native-social-authentication)
+* [Lock v1 Magic Links](/libraries/lock-android/v1/passwordless-magic-link)
+* [Lock v1 Refresh Tokens](/libraries/lock-android/v1/refresh-jwt-tokens)
+* [Lock v1 Sending Authentication Params](/libraries/lock-android/v1/sending-authentication-parameters)
+* [Lock v1 Installation and Setup](/libraries/lock-android/v1)
+* [Logging out Users](/logout)
diff --git a/ja-jp/articles/libraries/lock-android/index.yml b/ja-jp/articles/libraries/lock-android/index.yml
new file mode 100644
index 0000000000..f8c9d39302
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: libraries/lock-android
+  current: v2
+  versions:
+    - v1
+    - v2
+  defaultArticles:
+    v1: index
+    v2: index
diff --git a/ja-jp/articles/libraries/lock-android/v1/configuration.md b/ja-jp/articles/libraries/lock-android/v1/configuration.md
new file mode 100644
index 0000000000..918f0e31ed
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/configuration.md
@@ -0,0 +1,248 @@
+---
+toc: true
+title: Lock for Android v1 Configuration
+description: Configuration options and methods for Lock for Android v1
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Configuration
+
+<%= include('../_includes/_lock-version') %>
+
+These are options that can be used to configure Lock for Android v1 to your project's needs.
+
+## Lock
+
+### Lock Constants
+
+```java
+public static final String AUTHENTICATION_ACTION;
+```
+
+Action sent in `LocalBroadcastManager` when a user authenticates. It will include an instance of `UserProfile` and `Token`.
+
+```java
+public static final String AUTHENTICATION_ACTION_PROFILE_PARAMETER;
+```
+
+Name of the parameter that will include user's profile
+
+```java
+public static final String AUTHENTICATION_ACTION_TOKEN_PARAMETER;
+```
+
+Name of the parameter that will include user's token information
+
+```java
+public static final String CANCEL_ACTION;
+```
+
+Action sent when the user navigates back closing `LockActivity` or `LockSMSActivity`
+
+```java
+public static final String CANCEL_ACTION;
+```
+
+Action sent when the user change its password
+
+### Lock Properties
+
+```java
+public boolean shouldUseWebView();
+public void setUseWebView(boolean useWebView);
+```
+
+Forces Lock to use an embedded `android.webkit.WebView` and by default is `false`.
+
+```java
+public boolean shouldLoginAfterSignUp();
+public boolean setLoginAfterSignUp(boolean loginAfterSignUp);
+```
+
+Lock will login the user after a successful sign up. By default is `true`
+
+```java
+public boolean isClosable();
+public boolean setClosable(boolean closable);
+```
+
+Allows Lock activities to be closed by pressing back button. Default is `false`
+
+```java
+public boolean shouldUseEmail();
+public void setUseEmail(boolean useEmail);
+```
+
+Lock will ask for the user's email instead of a username. By default is `true`.
+
+```java
+public Map getAuthenticationParameters();
+public void setAuthenticationParameters(Map authenticationParameters);
+```
+
+Map with parameters that will be sent on every authentication request with Auth0 API.
+
+```java
+public List getConnections();
+public void setConnections(List connections);
+```
+
+Tells Lock to use the connections whose name is included in the list. By default the list is null or empty which means that all enabled connections in your application will be used.
+
+```java
+public String getDefaultDatabaseConnection();
+public void setDefaultDatabaseConnection(String defaultDatabaseConnection);
+```
+
+Lock will use the Database Connection whose name matches the one provided. By default its null, which means it will pick the first of the list.
+
+```java
+public void setFullscreen(boolean fullscreen);
+public boolean isFullscreen();
+```
+
+If Lock's activities should be displayed in Fullscreen. Default is `false`
+
+### Lock Methods
+
+```java
+public void setProvider(String serviceName, IdentityProvider provider);
+```
+
+Change the default identity provider handler for Social and Enterprise connections. By default all social/enterprise authentication are done using Web flow with a Browser.
+
+```java
+public void resetAllProviders();
+```
+
+Removes all session information the Identity Provider handlers might have.
+
+## Lock.Builder
+
+A simple builder to help you create and configure Lock in your application.
+
+### Lock.Builder Constants
+
+```java
+public static final String CLIENT_ID_KEY = "com.auth0.lock.client-id";
+```
+
+Key value used by Lock to search in your application's meta-data for the ClientID.
+
+```java
+public static final String TENANT_KEY = "com.auth0.lock.tenant";
+```
+
+Key value used by Lock to search in your application's meta-data for tenant name.
+
+```java
+public static final String DOMAIN_URL_KEY = "com.auth0.lock.domain-url";
+```
+
+Key value used by Lock to search in your application's meta-data for domain Url.
+
+```java
+public static final String CONFIGURATION_URL_KEY = "com.auth0.lock.configuration-url";
+```
+
+Key value used by Lock to search in your application's meta-data for configuration Url.
+
+### Lock.Builder Methods
+
+```java
+public Builder clientId(String clientId);
+```
+
+Set the clientId of your application in Auth0. This value is mandatory.
+
+```java
+public Builder tenant(String tenant);
+```
+
+Set the tenant name of your application. This value is optional if you supply a domain url.
+
+```java
+public Builder domainUrl(String domain);
+```
+
+Set the domain Url for Auth0's API. This value is optional if you provide a tenant name, it will default to Auth0 cloud API `https://tenant_name.auth0.com`.
+
+```java
+public Builder configurationUrl(String configuration);
+```
+
+Set the Url where Lock fetches the App configuration. By default it asks Auth0 for this info.
+
+```java
+public Builder useWebView(boolean useWebView);
+```
+
+Make Lock use an embedded WebView for Social+Enterprise authentications.
+
+```java
+public Builder closable(boolean closable);
+```
+
+Allow the user to close Lock's activity by pressing back button.
+
+```java
+public Builder loginAfterSignUp(boolean loginAfterSignUp);
+```
+
+After a successful sign up of a user, sign him/her in too.
+
+```java
+public Builder authenticationParameters(Map parameters);
+```
+
+Extra parameters sent to Auth0 Auth API during authentication. By default it has `scope` defined as `openid offline_access` and a device name stored in `device` parameter key.  For more information check out our [documentation on sending authentication parameters](/libraries/lock-android/v1/sending-authentication-parameters)
+
+```java
+public Builder useEmail(boolean useEmail);
+```
+
+Lock will ask for an email for authentication, otherwise it will ask for a username. By default is `true`.
+
+```java
+public Builder useConnections(String ...connectionNames);
+```
+
+Make Lock pick these connections for authentication from all the enabled connections in your app.
+
+```java
+public Builder defaultDatabaseConnection(String name);
+```
+
+Make Lock use the Database Connection whose name matches the one provided.
+
+```java
+public Builder loadFromApplication(Application application);
+```
+
+Load ClientID, Tenant name, Domain and configuration URLs from the Android app's metadata (if available).
+These are the values that can be defined and it's keys:
+
+* __com.auth0.lock.client-id__: Application's clientId in Auth0.
+* __com.auth0.lock.tenant__: Application's owner tenant name. (Optional if you supply Domain and Configuration URLs)
+* __com.auth0.lock.domain-url__: URL where the Auth0 API is available. (Optional if you supply ClientID/Tenant and you use Auth0 in the cloud)
+* __com.auth0.lock.configuration-url__: URL where Auth0 apps information is available. (Optional if you supply ClientID/Tenant and you use Auth0 in the cloud)
+
+```java
+public Builder fullscreen(boolean fullscreen);
+```
+
+Make Lock's activities fullscreen. Default is `false`
+
+```java
+public Lock build();
+```
+
+Creates a new instance of `Lock` and configure it with the values passed to the builder.
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/lock-android/v1/delegation-api.md b/ja-jp/articles/libraries/lock-android/v1/delegation-api.md
new file mode 100644
index 0000000000..f868a9de45
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/delegation-api.md
@@ -0,0 +1,64 @@
+---
+toc: true
+title: Lock for Android v1 Delegation
+description: Integrate with third-party apps with the delegation API.
+public: false
+topics:
+  - libraries
+  - lock
+  - delegation
+  - android
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Delegation API
+
+<%= include('../_includes/_lock-version') %>
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/auth-api#!#post--delegation) using a valid JWT.
+
+Here's an example
+
+```java
+Lock lock = LockContext.getLock(this);
+AuthenticationAPIClient client = lock.getAuthenticationAPIClient();
+String apiType = "firebase";
+String token = .... //Your Auth0 ID Token of the logged in User
+Map parameters = ParameterBuilder.newEmptyBuilder()
+        .set("id_token", token)
+        .set("api_type", apiType)
+        .asDictionary();
+client
+    .delegation()
+    .addParameters(parameters).start(new BaseCallback>() {
+        @Override
+        public void onSuccess(Map payload) {
+            //Your Firebase token will be in payload
+        }
+
+        @Override
+        public void onFailure(Throwable error) {
+            //Delegation call failed
+        }
+    });
+```
+
+::: note
+The delegation response is a generic Map since the structure of it will depend of the `api_type` used for delegation
+:::
+
+The only two parameters required are `id_token` and `api_type`, the former is the token returned by Auth0 after a successful authentication, the latter specifies the API credentials we want to retrieve, and these are its supported values:
+
+* app: Your Auth0 application. This will get a new JWT token.
+* aws: Amazon Web Services API.
+* azure_sb: Windows Azure Service Bus.
+* firebase: Firebase API.
+* salesforce_api: Salesforce API.
+* salesforce_sandbox_api: Salesforce Sandbox API.
+* sap_api: SAP OData.
+* wams: Windows Azure Mobile Services.
diff --git a/ja-jp/articles/libraries/lock-android/v1/index.md b/ja-jp/articles/libraries/lock-android/v1/index.md
new file mode 100644
index 0000000000..9c2bdbf318
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/index.md
@@ -0,0 +1,208 @@
+---
+section: libraries
+toc: true
+title: Lock for Android v1
+description: A widget that provides a frictionless login and signup experience for your native Android apps.
+public: false
+mobileimg: media/articles/libraries/lock-android.png
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - index
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Getting Started
+
+<%= include('../_includes/_lock-version') %>
+
+::: note
+Check out the [Lock.Android repository](https://github.com/auth0/Lock.Android/tree/v1) on GitHub.
+:::
+
+## Requirements
+
+Android API level 15+ is required in order to use Lock's UI.
+If you'll create your own API and just call Auth0 API via the `com.auth0.android:core:1.+`, the minimum required API level is 9.
+
+## Install
+
+Lock is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To start using *Lock* add these lines to your `build.gradle` dependencies file:
+
+```gradle
+compile 'com.auth0.android:lock:1.+'
+```
+
+Once it's installed, you'll need to configure LockActivity in your`AndroidManifest.xml`, inside the `application` tag:
+
+```xml
+
+
+  
+    
+    
+    
+    
+  
+
+
+
+
+```
+
+::: note
+The value `@string/auth0_client_id` is your application's clientID and `@string/auth0_domain` is your tenant's domain in Auth0, both values can be found in your app's settings.
+:::
+
+::: note
+The final value of `android:scheme` must be in lowercase.
+:::
+
+Also, you'll need to add *Internet* permission to your application:
+
+```xml
+
+```
+
+Finally, make your Application class (The one that extends from `android.app.Application`) implement the interface `com.auth0.lock.LockProvider` and add the following code:
+
+```java
+public class MyApplication extends Application implements LockProvider {
+
+  private Lock lock;
+
+  public void onCreate() {
+    super.onCreate();
+    lock = new Lock.Builder()
+      .loadFromApplication(this)
+      /** Other configuration goes here */
+      .closable(true)
+      .build();
+  }
+
+  @Override
+  public Lock getLock() {
+    return lock;
+  }
+}
+```
+
+::: note
+You can check [here](#lock-builder) for more configuration options
+:::
+
+You should also add your Application class to the `AndroidManifest.xml`.
+
+```xml
+
+        
+
+
+```
+
+And include the following code in your `build.gradle` file.
+
+```gradle
+android {
+  //...
+  packagingOptions {
+      exclude 'META-INF/NOTICE'
+      exclude 'META-INF/LICENSE'
+  }
+}
+```
+
+## Authentication with Lock
+
+`LockActivity` will handle Email/Password, Enterprise & Social authentication based on your Application's connections enabled in your Auth0's Dashboard.
+
+When a user authenticates successfully, LockActivity will send an Action using LocalBroadcastManager and then finish itself (by calling finish()). The activity that is interested in receiving this Action (In this case the one that will show Lock) needs to register a listener in the LocalBroadcastManager:
+
+```java
+// This activity will show Lock
+public class HomeActivity extends Activity {
+
+  private LocalBroadcastManager broadcastManager;
+
+  private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() {
+    @Override
+    public void onReceive(Context context, Intent intent) {
+      UserProfile profile = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_PROFILE_PARAMETER);
+      Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER);
+      Log.i(TAG, "User " + profile.getName() + " logged in");
+    }
+  };
+
+  @Override
+  protected void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+    //Customize your activity
+
+    broadcastManager = LocalBroadcastManager.getInstance(this);
+    broadcastManager.registerReceiver(authenticationReceiver, new IntentFilter(Lock.AUTHENTICATION_ACTION));
+  }
+
+  @Override
+  protected void onDestroy() {
+    super.onDestroy();
+    broadcastManager.unregisterReceiver(authenticationReceiver);
+  }
+}
+```
+
+Then just start `LockActivity`
+
+```java
+Intent lockIntent = new Intent(this, LockActivity.class);
+startActivity(lockIntent);
+```
+
+And you'll see our native login screen
+
+![Lock Screenshot](/media/articles/libraries/lock-android/Lock-Widget-Android-Screenshot.png)
+
+::: note
+By default all social authentication will be done using an external browser, if you want native integration please check this [wiki page](/libraries/lock-android/native-social-authentication).
+:::
+
+## Proguard
+
+In the [proguard directory](https://github.com/auth0/Lock.Android/tree/master/proguard) you can find the *Proguard* configuration for Lock and its dependencies.
+By default you should at least use the following files:
+
+* `proguard-square-okhttp.pro`
+* `proguard-jackson-2.pro`
+* `proguard-square-otto.pro`
+* `proguard-lock.pro`
+
+and if you use Facebook or Google+ native integration, you'll need `proguard-facebook.pro` and `proguard-google-play-services.pro` respectively.
+
+You specify several files in you application's `build.gradle` like this:
+
+```gradle
+buildTypes {
+  release {
+    minifyEnabled true
+    proguardFile '../proguard/proguard-facebook.pro' //facebook native auth
+    proguardFile '../proguard/proguard-google-play-services.pro' //G+ native auth
+    proguardFile '../proguard/proguard-square-okhttp.pro' //Auth0 core
+    proguardFile '../proguard/proguard-jackson-2.pro' //Auth0 core
+    proguardFile '../proguard/proguard-square-otto.pro' //Lock
+    proguardFile '../proguard/proguard-lock.pro' //Lock
+    //Add your app's specific proguard rules
+  }
+}
+```
+
+<%= include('../_includes/_next-steps') %>
diff --git a/ja-jp/articles/libraries/lock-android/v1/internationalization.md b/ja-jp/articles/libraries/lock-android/v1/internationalization.md
new file mode 100644
index 0000000000..141c75ae56
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/internationalization.md
@@ -0,0 +1,47 @@
+---
+section: libraries
+title: Lock Android v1 Internationalization
+description: Internationalization support in Lock for Android
+public: false
+topics:
+  - libraries
+  - lock
+  - i18n
+  - android
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Internationalization
+
+<%= include('../_includes/_lock-version') %>
+
+By default, **Lock.Android** displays all text in English. If you wish to display text in another language, you may provide a `strings.xml` file and define values to be used for the various text items that Lock might display.
+
+Android asks the device what _locale_ was configured by the user and tries to fetch the list of localized texts for that language. For this to work, the developer needs to add each translation file into the app by using a special folder naming convention as per Android standards. More information can be found in the [Android developer docs](https://developer.android.com/training/basics/supporting-devices/languages.html).
+
+Some of the default values provided by Lock include:
+
+```html
+
+  Login SMS
+  Login not found
+  ...
+
+```
+
+By providing your own `strings.xml` file, these values can be adjusted as such:
+
+```html
+
+  Login with SMS
+  This user was not found!
+  ...
+
+```
+
+## Lock String Values
+
+For a full list of the names used by Lock, see the [default strings.xml file](https://github.com/auth0/Lock.Android/blob/v1/app/src/main/res/values/strings.xml) in the Lock.Android repository.
diff --git a/ja-jp/articles/libraries/lock-android/v1/native-social-authentication.md b/ja-jp/articles/libraries/lock-android/v1/native-social-authentication.md
new file mode 100644
index 0000000000..295964224c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/native-social-authentication.md
@@ -0,0 +1,97 @@
+---
+title: Lock Android v1 Native Social Authentication
+description: How to implement native social authentication with Lock Android
+public: false
+topics:
+  - libraries
+  - lock
+  - native
+  - social-connections
+  - android
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Native Social Authentication
+
+<%= include('../_includes/_lock-version') %>
+
+::: warning
+This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature.
+We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login).
+:::
+
+**Lock** by default handles all social authentication with a Browser installed in your Android device, but for some social connections you can take advantage of our native integration.
+We implemented native integration with Facebook and Google+ and bundled each of them in a separate Android Library (*aar* file), to start using them just add these lines in your `build.gradle`:
+
+```gradle
+compile 'com.auth0.android:lock-facebook:2.3.+'
+compile 'com.auth0.android:lock-googleplus:2.3.+'
+```
+
+## Configuration
+
+### Facebook
+
+Lock uses Facebook Android SDK to obtain the user's credentials and use them to login with your Auth0 application.
+
+To get started, in your `AndroidManifest.xml` you need to add the following:
+
+```xml
+
+
+```
+
+Where `@string/facebook_app_id` is your Facebook Application ID that you can get from [Facebook Dev Site](https://developers.facebook.com/apps).
+
+::: note
+For more information please check [Facebook Getting Started Guide](https://developers.facebook.com/docs/android/getting-started).
+:::
+
+Finally, you need to register Auth0 Facebook Provider with Lock so it can do all Facebook authentication. This can be done in your Application object `onCreate` method right after you initialise Lock:
+
+```java
+@Override
+public void onCreate() {
+    super.onCreate();
+    lock = new Lock.Builder()
+            .loadFromApplication(this)
+            .withIdentityProvider(Strategies.Facebook, new FacebookIdentityProvider(this))
+            .build();
+}
+```
+
+### Google
+
+For Google login we use Google Signin library that is part of Google Play Services.
+
+Before we start, you'll need to register your application in Google Developers and create a OAuth 2.0 client, to do that follow this [wizard](https://developers.google.com/mobile/add?platform=android)
+
+The next step is to configure your Google connection in Auth0 Dashboard with the newly created OAuth 2.0 client information. Just go to [Social Connections](${manage_url}/#/connections/social), select **Google** and in the field named `Allowed Mobile Client IDs` add the ID of the OAuth 2.0 client.
+
+Then in your `AndroidManifest.xml` add these permissions and meta-data value for Google Play Services:
+
+```xml
+
+
+
+```
+
+And finally register Google Identity Provider with Lock in your Application object `onCreate`:
+
+```java
+@Override
+public void onCreate() {
+    super.onCreate();
+    lock = new LockBuilder()
+            .loadFromApplication(this)
+            .withIdentityProvider(Strategies.GooglePlus, new GooglePlusIdentityProvider(this))
+            .build();
+}
+```
diff --git a/ja-jp/articles/libraries/lock-android/v1/passwordless-magic-link.md b/ja-jp/articles/libraries/lock-android/v1/passwordless-magic-link.md
new file mode 100644
index 0000000000..a318f4fb5f
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/passwordless-magic-link.md
@@ -0,0 +1,195 @@
+---
+title: Lock Android v1 Passwordless with Magic Link
+description: Passwordless with Magic Link with Lock Android
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+  - passwordless
+  - magic-link
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Passwordless Magic link
+
+<%= include('../_includes/_lock-version') %>
+
+::: warning
+Passwordless on native platforms is disabled by default for new tenants as of 8 June 2017. If you would like this feature enabled, please contact support to discuss your use case. See [Application Grant Types](/applications/concepts/application-grant-types) for more information. Alternatively, you can use Lock Passwordless with Auth0's Universal Login.
+:::
+
+## Passwordless Authentication with Magic Link
+
+In order to avoid asking the user to input the one-time password sent for passwordless authentication in Android apps, we introduced the ability to send a link that the user can tap to login without any code input involved.
+
+These links include the same code that would be used in the traditional passwordless flow, but with the correct configuration they will be handled automatically by the Android system and our application will log in the users effortlessly by relying on **Android App Links**.
+
+With App Links, in Android 6.0 (API level 23) and higher, Android allows an app to designate itself as the default handler of a given type of link, without asking the user whether to use the browser or the app to open the link.
+
+Automatic handling of links requires the cooperation of our app and website (our Auth0 authentication server). The app must declare the association with the website and request that the system verify it. The website must, in turn, provide that verification by publishing a [Digital Asset Links](https://developers.google.com/digital-asset-links/) file.
+
+This feature works as long as the user has not already chosen a default app to handle that URI pattern.
+
+You could find more information about App Links in the [Android docs](http://developer.android.com/training/app-links/index.html).
+
+::: note
+The links will work in all versions of Android, but the dialog asking the user whether to use the browser or the app to open the link will be displayed (whether the verification passed or not) in versions of Android prior to 6.0, at least until the user chooses to always open the links with the app.
+:::
+
+In this article we'll show how Auth0 helps you set up your app to use app links to log in.
+
+### Auth0 account configuration
+
+Auth0 will generate the [Digital Asset Links](https://developers.google.com/digital-asset-links/) file automatically, all you need to do is configure the required parameters, some via API and others in your [dashboard](${manage_url}/#/connections/passwordless). We'll show you how to do it.
+
+### Application configuration
+
+We'll have to configure/add some field to our Auth0 application. The fields we need to configure are:
+
+- **app\_package\_name**: This is the package name, as declared in the app's manifest. An example would be *com.example.android.myapp*
+- **sha256\_cert\_fingerprints**: This is an array of the SHA256 fingerprints of our android app’s signing certificates. This is an arbitrary length array, it can include all the fingerprints we want, so for example we could add both our release and debug fingerprints.
+
+#### Getting your signing certificates fingerprint
+
+You can use the following command to generate the fingerprint via the Java keytool:
+
+```bash
+keytool -list -v -keystore my-release-key.keystore
+```
+
+or to obtain the default debug key:
+
+```bash
+keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
+```
+
+#### Configure Auth0 via API
+
+Once we have the package name and the SHA256 fingerprint, we'll update our Auth0 application via API with [patch\_clients\_by\_id](/api/v2#!/Clients/patch_clients_by_id) (they aren't yet available in the dashboard).
+
+In the *id* field we must introduce the *client_id* of our Auth0 App, and the *body* should look like this:
+
+```json
+{
+  "mobile": {
+    "android": {
+      "app_package_name": "",
+      "sha256_cert_fingerprints": ["", ""]
+    }
+  }
+}
+```
+
+::: warning
+Don't forget to change the body to use your package name and keystore fingerprint!
+:::
+
+### Connection Configuration
+
+Next we'll have to configure either the SMS or Email connection. This is available from the dashboard, so we'll show how to do it from there.
+
+#### SMS
+
+In case we'll use a passwordless connection via SMS, we'll need to update the SMS message template from the [dashboard](${manage_url}/#/connections/passwordless).
+
+All you need to do is choose **Liquid** as the SMS Syntax and make sure the message contains something like this:
+
+```liquid
+{% if send == 'link_ios' or send == 'link_android' %}
+Your verification link is: {{ link }}
+{% else %}
+Your verification code is: {{ code }}
+{% endif %}
+```
+
+::: note
+We assume that you have the SMS connection correctly configured, including the Twilio account. If you haven't, please do so.
+:::
+
+#### Email
+
+Otherwise, if we'll use a passwordless connection via Email, we'll need to make sure the template is **HTML + Liquid** and that the email body contains *somewhere* a conditional like this:
+
+```liquid
+{% if send == 'link' or send == 'link_ios' or send == 'link_android' %}
+Your verification link is: {{ link }}
+{% elsif send == 'code' %}
+Your verification code is: {{ code }}
+{% endif %}
+```
+
+### Application configuration
+
+Now that we have the Auth0 application configured, before we start with the Android configuration we must follow the instructions and set up Lock.Android and LockPasswordlessActivity as seen in the [passwordless docs](/libraries/lock-android#passwordless).
+
+Now, in order to use App Links, there is an additional configuration step we must follow. We must declare an intent filter in the `AndroidManifest.xml`, inside the `LockPasswordlessActivity` activity tag. This filter will allow the app lo handle the links we'll send by Email or SMS.
+
+```xml
+
+
+    
+        
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+        
+    
+
+
+
+```
+
+The value `@string/auth0_domain` is your tenant's domain in Auth0, which can be found in your app's settings.
+
+In `android:pathPrefix` you must replace the package name of the application, as configured in the Auth0 account.
+
+As can be seen, it's a regular *intent-filter*, with the exception of the `android:autoVerify="true"` field. This is used since Android API 23 (Android 6.0) to indicate that we would like to verify the link association. **This is extremely important to avoid the dialog asking the user which application to use.**
+
+Also notice that in case we'll only use one passwordless method (SMS or Email) you could delete the other intent filter (see the last segment of the pathPrefix: `/email` or `/sms`).
+
+### Usage
+
+As you should already know, `LockPasswordlessActivity` authenticates users by sending them an Email or SMS, in this case we'll send them a link instead of a code. The only difference w.r.t. the regular passwordless is that we now explicitly indicate that we will use magic/app links. This is accomplished using the appropriate mode.
+
+If we would like to send app links by **Email**, just start `LockPasswordlessActivity` specifying the passwordless mode `MODE_EMAIL_MAGIC_LINK`:
+
+```java
+LockPasswordlessActivity.showFrom(MyActivity.this,
+        LockPasswordlessActivity.MODE_EMAIL_MAGIC_LINK);
+```
+
+and we'll see the **Email** login screen
+
+![Email](/media/articles/libraries/lock-android/passwordless-magic-link/lock-android-pwdless-email.png)
+
+or for **SMS** the mode `MODE_SMS_MAGIC_LINK`:
+
+```java
+LockPasswordlessActivity.showFrom(MyActivity.this,
+        LockPasswordlessActivity.MODE_SMS_MAGIC_LINK);
+```
+
+and we'll see the **SMS** login screen
+
+![SMS](/media/articles/libraries/lock-android/passwordless-magic-link/lock-android-pwdless-sms.png)
+
+After requesting the magic link from Auth0, via SMS or Email, the next screen will indicate that in order to log in, the user should tap it. We also offer a backup option to enter the code manually, just in case the links don't work.
diff --git a/ja-jp/articles/libraries/lock-android/v1/passwordless.md b/ja-jp/articles/libraries/lock-android/v1/passwordless.md
new file mode 100644
index 0000000000..473c2ee94a
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/passwordless.md
@@ -0,0 +1,115 @@
+---
+section: libraries
+title: Lock Android v1 Passwordless
+description: Guide on implementing Passwordless authentication with Lock for Android
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+  - passwordless
+  - tokens
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Passwordless
+
+<%= include('../_includes/_lock-version') %>
+
+Lock Passwordless authenticates users by sending them an Email or SMS with a one-time password that the user must enter and confirm to be able to log in, similar to how WhatsApp authenticates you. This article will explain how to send a **CODE** using the `Lock.Android` library.
+
+::: note
+You can achieve a similar result by sending a **LINK** that the user can click to finish the passwordless authentication automatically, but a few more configuration steps are involved. You can check that article [here](/libraries/lock-android/v1/passwordless-magic-link).
+:::
+
+In order to be able to authenticate the user, your application must have the Email/SMS connection enabled and configured in your [Auth0 Dashboard](${manage_url}/#/connections/passwordless).
+
+Note that Passwordless Lock *cannot be used* with the [OIDC Conformant Mode](/libraries/lock-android/index#oidc-conformant-mode) set to `true`. For more information, please see the [OIDC adoption guide](https://auth0.com/docs/api-auth/tutorials/adoption).
+
+## Passwordless Authentication
+
+`LockPasswordlessActivity` authenticates users by sending them an Email or SMS (similar to how WhatsApp authenticates you). In order to be able to authenticate the user, your application must have the SMS/Email connection enabled and configured in your [dashboard](${manage_url}/#/connections/passwordless).
+
+`LockPasswordlessActivity` is not included in `com.auth0:lock:aar` as it's part of the library `lock-passwordless`, but you can add it with this line in your `build.gradle`:
+
+```gradle
+compile 'com.auth0.android:lock-passwordless:1.+'
+```
+
+Then in your `AndroidManifest.xml` register the following activities:
+
+```xml
+    
+    
+
+    
+
+```
+
+Just like `LockActivity`, when a user authenticates successfully, `LockPasswordlessActivity` will send an `Action` using `LocalBroadcastManager` and then finish itself (by calling `finish()`). The activity that is interested in receiving this `Action` (in this case the one that will show Lock) needs to register a listener in the `LocalBroadcastManager`:
+
+```java
+// This activity will show Lock
+public class HomeActivity extends Activity {
+  private LocalBroadcastManager broadcastManager;
+
+  private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() {
+    @Override
+    public void onReceive(Context context, Intent intent) {
+      UserProfile profile = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_PROFILE_PARAMETER);
+      Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER);
+      Log.i(TAG, "User " + profile.getName() + " logged in");
+    }
+  };
+
+  @Override
+  protected void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+    //Customize your activity
+
+    broadcastManager = LocalBroadcastManager.getInstance(this);
+    broadcastManager.registerReceiver(authenticationReceiver, new IntentFilter(Lock.AUTHENTICATION_ACTION));
+  }
+
+  @Override
+  protected void onDestroy() {
+    super.onDestroy();
+    broadcastManager.unregisterReceiver(authenticationReceiver);
+  }
+}
+```
+
+Then just start `LockPasswordlessActivity` specifying the Passwordless type you want to use, so for **Email**
+
+```java
+LockPasswordlessActivity.showFrom(MyActivity.this, LockPasswordlessActivity.MODE_EMAIL_CODE);
+```
+
+or just for **SMS**
+
+```java
+LockPasswordlessActivity.showFrom(MyActivity.this, LockPasswordlessActivity.MODE_SMS_CODE);
+```
+
+and you'll see the **SMS** login screen
+
+![Lock Screenshot](/media/articles/libraries/lock-android/Lock-SMS-Android-Screenshot.png)
+
+Passworless scenarios and types:
+
+| Channel \ Mode  | Code  | Magic Link      |
+| :-----: |:---------------:| :--------------: |
+| SMS   | `LockPasswordlessActivity.MODE_SMS_CODE`   | `LockPasswordlessActivity.MODE_SMS_LINK`   |
+| Email | `LockPasswordlessActivity.MODE_EMAIL_CODE` | `LockPasswordlessActivity.MODE_EMAIL_LINK` |
+
+You can find more information about Magic Links [here](/libraries/lock-android/v1/passwordless-magic-link).
diff --git a/ja-jp/articles/libraries/lock-android/v1/refresh-jwt-tokens.md b/ja-jp/articles/libraries/lock-android/v1/refresh-jwt-tokens.md
new file mode 100644
index 0000000000..6460b9756c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/refresh-jwt-tokens.md
@@ -0,0 +1,82 @@
+---
+title: Lock Android v1 Refreshing JWT Tokens
+description: Keeping your user logged in
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+  - passwordless
+  - tokens
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Refreshing JWT Tokens
+
+<%= include('../_includes/_lock-version') %>
+
+<%= include('../../../_includes/_uses-delegation') %>
+
+When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new JWT token and avoid asking the user for their credentials again.
+
+::: note
+Lock.Android will include the `offline_scope` scope by default.
+:::
+
+Before we start, we have to retrieve the ID Token or Refresh Token from the token when the user logs in.
+
+```java
+private BroadcastReceiver authenticationReceiver = new BroadcastReceiver() {
+    @Override
+    public void onReceive(Context context, Intent intent) {
+        Token token = intent.getParcelableExtra(Lock.AUTHENTICATION_ACTION_TOKEN_PARAMETER);
+        String idToken = token.getIdToken();
+        String refreshToken = token.getRefreshToken();
+        // Store ID Token or Refresh Token in secure storage
+    }
+};
+```
+
+Then, we need to store the ID Token or Refresh Token in secure storage after the user is authenticated by Auth0. And finally, we can request a new ID Token using either of them by calling Auth0`s **delegation** endpoint.
+
+## Using a non-expired ID Token
+
+```java
+String idToken = // Retrieve ID Token from secure storage
+Lock lock = LockContext.getLock(this);
+AuthenticationAPIClient client = lock.getAuthenticationAPIClient();
+client.delegationWithIdToken(idToken).start(new RefreshIdTokenCallback() {
+    @Override
+    public void onSuccess(String idToken, String tokenType, int expiresIn) {
+        //SUCCESS
+    }
+
+    @Override
+    public void onFailure(Throwable error) {
+        //FAILURE
+    }
+});
+```
+
+## Using Refresh Token
+
+```java
+String refreshToken = // Retrieve Refresh Token from secure storage
+Lock lock = LockContext.getLock(this);
+AuthenticationAPIClient client = lock.getAuthenticationAPIClient();
+client.delegationWithRefreshToken(refreshToken).start(new RefreshIdTokenCallback() {
+    @Override
+    public void onSuccess(String idToken, String tokenType, int expiresIn) {
+        //SUCCESS
+    }
+
+    @Override
+    public void onFailure(Throwable error) {
+        //FAILURE
+    }
+});
+```
diff --git a/ja-jp/articles/libraries/lock-android/v1/sending-authentication-parameters.md b/ja-jp/articles/libraries/lock-android/v1/sending-authentication-parameters.md
new file mode 100644
index 0000000000..9ebaa1ad4e
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/sending-authentication-parameters.md
@@ -0,0 +1,76 @@
+---
+title: Lock Android v1 Sending Authentication Parameters
+description: Sending Authentication parameters with Lock Android
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Sending Authentication Parameters
+
+<%= include('../_includes/_lock-version') %>
+
+You can specify additional authentication parameters, before starting `LockActivity` or when calling any API method using `APIClient`, by using `ParameterBuilder` object to build the parameter dictionary. By default `ParameterBuilder` has the parameter `scope` with `openid offline_access` and `device` with the name obtained from
+
+```java
+android.os.Build.MODEL
+```
+
+The following example adds a `scope` parameter with the value `login`.
+
+```java
+ParameterBuilder builder = ParameterBuilder.newBuilder();
+Map parameters = builder.setScope("login").asDictionary();
+```
+
+The following parameters are supported:
+
+* `access_token`
+* `scope`
+* `protocol`
+* `device`
+* `connection_scopes`
+* `nonce`
+* `offline_mode`
+* `state`.
+
+There are other extra parameters that will depend on the provider. For example, Google allows you to get back a Refresh Token only if you explicitly ask for `access_type=offline`.
+
+We support sending arbitrary parameters like this:
+
+```java
+ParameterBuilder builder = ParameterBuilder.newBuilder();
+Map parameters = builder
+    .set("access_type", "offline")
+    .set("my_arbitrary_param", "foo")
+    .asDictionary();
+```
+
+## Supported Parameters
+
+### scope:`String`
+
+There are different values supported for scope:
+
+* `'openid'`: It will return, not only the Access Token, but also an ID Token which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim). You can use constant `ParameterBuilder.SCOPE_OPENID`.
+* `'openid profile'`: (not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (such as when using response_type=token) and will likely create an unnecessarily large token (especially with Azure AD which returns a fairly long JWT). Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible.
+* `'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the ID Token (for example: `scope: 'openid name email picture'`).
+
+Also when you need to keep the ID Token alive, you can request a Refresh Token adding to the scope the value `offline_access` (Or use the constant `ParameterBuilder.SCOPE_OFFLINE_ACCESS`).
+
+By default in Lock for Android, the scope is set to `openid offline_access`.
+
+### device:`String`
+
+This value is only required when one of the scopes is `offline_access`. By default it has the name of the device obtained from calling the following method:
+
+```java
+android.os.Build.MODEL
+```
diff --git a/ja-jp/articles/libraries/lock-android/v1/use-your-own-ui.md b/ja-jp/articles/libraries/lock-android/v1/use-your-own-ui.md
new file mode 100644
index 0000000000..5ab6f8899c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v1/use-your-own-ui.md
@@ -0,0 +1,324 @@
+---
+title: Lock Android v1 Customize Your UI
+description: Customize the UI of Lock in your App
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+  - lock-ui
+contentType:
+  - how-to
+  - concept
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Customize Your UI
+
+<%= include('../_includes/_lock-version') %>
+
+:::note
+We are going to use the library [EventBus](https://github.com/greenrobot/EventBus) in order to post authentication related events like **authentication done** and **Authentication failed**
+:::
+
+Add the following dependencies to your project:
+
+```gradle
+compile 'com.auth0.android:core:1.+'
+compile 'de.greenrobot:eventbus:2.4.+'
+```
+
+Create a new resource file named `auth0.xml` under `values` and add the following content, replacing the values with your Auth0 ClientId and Domain
+
+```xml
+
+
+    ${account.clientId}
+    ${account.namespace}
+
+```
+
+Create two classes `AuthenticationEvent` and `ErrorEvent` that will represent a successful authentication or a failed one
+
+```java
+public class AuthenticationEvent {
+    private final UserProfile profile;
+    private final Token token;
+
+    public AuthenticationEvent(UserProfile profile, Token token) {
+        this.profile = profile;
+        this.token = token;
+    }
+
+    public Token getToken() { return token; }
+
+    public UserProfile getProfile() { return profile; }
+}
+
+public class ErrorEvent {
+    private Dialog dialog;
+    private int title;
+    private int message;
+    private Throwable throwable;
+
+    public ErrorEvent(Dialog dialog) {
+        this.dialog = dialog;
+    }
+
+    public ErrorEvent(int title, int message, Throwable throwable) {
+        this.title = title;
+        this.message = message;
+        this.throwable = throwable;
+    }
+}
+```
+
+Then in your Login *Activity* add the following fields
+
+```java
+private AuthenticationAPIClient client;
+private EventBus eventBus;
+```
+
+In the same *Activity* `onCreate` method add the following lines to initialize **Auth0** and the fields we added earlier
+
+```java
+Auth0 auth0 = new Auth0(getString(R.string.auth0_client_id), getString(R.string.auth0_domain_name));
+this.client = auth0.newAuthenticationAPIClient();
+this.eventBus = new EventBus();
+```
+
+When you need to login your user with email/password credentials, just paste the following code
+
+```java
+String email = ... // Get email
+String password = ... // Get password
+//add your DB connection name, since you are using email / pwd login
+//will throw a 400 error if not set
+ParameterBuilder parameterBuilder = ParameterBuilder.newBuilder();
+Map authenticationParameters = parameterBuilder
+          .setConnection("YOUR_DB_CONNECTION_NAME")
+          .asDictionary();
+client.login(email, password)
+    .addParameters(authenticationParameters)
+    .start(new AuthenticationCallback() {
+        @Override
+        public void onSuccess(UserProfile userProfile, Token token) {
+            eventBus.post(new AuthenticationEvent(userProfile, token));
+        }
+
+        @Override
+        public void onFailure(Throwable throwable) {
+            eventBus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable));
+        }
+    });
+```
+
+::: note
+For more details about the parameters you can check [this wiki page](/libraries/lock-android/sending-authentication-parameters).
+:::
+
+Finally handle both `AuthenticationEvent` and `ErrorEvent`
+
+```java
+@Override
+protected void onStart() {
+    super.onStart();
+    eventBus.register(this);
+}
+
+@Override
+protected void onStop() {
+    super.onStop();
+    eventBus.unregister(this);
+}
+
+public void onEvent(ErrorEvent event) {
+  //Handle Error
+}
+
+public void onEvent(AuthenticationEvent event) {
+  //Handle authentication
+}
+```
+
+## Social Authentication
+
+::: warning
+This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature.
+We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login).
+:::
+
+Include the following libraries in your `build.gradle`:
+
+```gradle
+compile 'com.auth0.android:identity-core:1.+'
+compile 'com.auth0.android:lock-facebook:2.4.+'
+compile 'com.auth0.android:lock-googleplus:2.4.+'
+```
+
+In your `auth0.xml` file add the following entry
+
+```xml
+a0${account.clientId.toLowerCase()}
+```
+
+Configure your Login *Activity* adding the following intent filters in your `AndroidManifest.xml` file
+
+```xml
+
+    
+    
+    
+    
+
+```
+
+Create a new class that implements `IdentityProviderCallback`, that will handle social authentication (via native integration or using web browser) and post a new event either on success or failure
+
+```java
+public class MyIdentityProviderCallback implements IdentityProviderCallback {
+    private final EventBus bus;
+    private final AuthenticationAPIClient client;
+
+    public MyIdentityProviderCallback(EventBus bus, AuthenticationAPIClient client) {
+        this.bus = bus;
+        this.client = client;
+    }
+
+    @Override
+    public void onFailure(Dialog dialog) {
+        //Authentication failed and a Error dialog is provided
+        bus.post(new ErrorEvent(dialog));
+    }
+
+    @Override
+    public void onFailure(int title, int message, Throwable throwable) {
+        //Authentication failed and a title & message resource are provided.
+        //The throwable parameter will include the reason (if any)
+        bus.post(new ErrorEvent(title, message, throwable));
+    }
+
+    @Override
+    public void onSuccess(String serviceName, String accessToken) {
+        //Authenticate with Auth0 using the IdP token obtained from a native integration like Facebook
+        client.loginWithOAuthAccessToken(accessToken, serviceName)
+          .start(new AuthenticationCallback() {
+              @Override
+              public void onSuccess(UserProfile userProfile, Token token) {
+                  bus.post(new AuthenticationEvent(userProfile, token));
+              }
+
+              @Override
+              public void onFailure(Throwable throwable) {
+                  bus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable));
+              }
+          });
+    }
+
+    @Override
+    public void onSuccess(final Token token) {
+        //Already authenticated with Auth0 using Web Browser (when no native integration is available), then we just fetch the user's profile
+        client.tokenInfo(token.getIdToken())
+          .start(new BaseCallback() {
+              @Override
+              public void onSuccess(UserProfile profile) {
+                  bus.post(new AuthenticationEvent(profile, token));
+              }
+
+              @Override
+              public void onFailure(Throwable throwable) {
+                  bus.post(new ErrorEvent(R.string.login_failed_title, R.string.login_failed_message, throwable));
+              }
+          });
+    }
+}
+```
+
+In your Login *Activity* add the following fields
+
+```java
+private WebIdentityProvider webProvider;
+private IdentityProvider identity;
+private GooglePlusIdentityProvider googleplus;
+private FacebookIdentityProvider facebook;
+```
+
+And implement the following methods
+
+```java
+@Override
+protected void onStop() {
+    webProvider.stop();
+}
+
+@Override
+protected void onNewIntent(Intent intent) {
+    super.onNewIntent(intent);
+    Log.v(TAG, "Received new Intent with URI " + intent.getData());
+    if (identity != null) {
+        identity.authorize(this, IdentityProvider.WEBVIEW_AUTH_REQUEST_CODE, RESULT_OK, intent);
+    }
+}
+
+@Override
+protected void onActivityResult(int requestCode, int resultCode, Intent data) {
+    super.onActivityResult(requestCode, resultCode, data);
+    if (identity != null) {
+        identity.authorize(this, requestCode, resultCode, data);
+    }
+}
+```
+
+In the method `onCreate` initialize Auth0 web provider and store it in a field
+
+```java
+final MyIdentityProviderCallback callback = new MyIdentityProviderCallback(eventBus, client);
+this.webProvider = new WebIdentityProvider(new CallbackParser(), auth0.getClientId(), auth0.getAuthorizeUrl());
+this.webProvider.setCallback(callback);
+```
+
+Configure Facebook Native integration
+
+```java
+this.facebook = new FacebookIdentityProvider(this);
+this.facebook.setCallback(callback);
+```
+
+:::note
+You need to [configure](https://developers.facebook.com/docs/android/getting-started#app_id) your Android app for Facebook
+:::
+
+Configure Google+ Native integrationApplication class)
+
+```java
+this.googleplus = new GooglePlusIdentityProvider(this);
+this.googleplus.setCallback(callback);
+```
+
+:::note
+Before using Google+, you need to register your Application with Google as explained in this [guide](https://developers.google.com/+/mobile/android/getting-started)
+:::
+
+To trigger Facebook authentication just add the following code:
+
+```java
+identity = facebook;
+identity.start(this, Strategies.Facebook.getName());
+```
+
+To trigger Google+ authentication just add the following code:
+
+```java
+identity = googleplus;
+identity.start(this, Strategies.GooglePlus.getName());
+```
+
+To trigger authentication with any IdP without native integration just add the following code:
+
+```java
+identity = webProvider;
+identity.start(this, Strategies.Twitter.getName());
+```
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/lock-android/v2/configuration.md b/ja-jp/articles/libraries/lock-android/v2/configuration.md
new file mode 100644
index 0000000000..0a6bc8c3f2
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/configuration.md
@@ -0,0 +1,72 @@
+---
+section: libraries
+title: Lock for Android v2 Configuration
+description: Altering the appearance and behavior of Lock for Android
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Configuration
+
+These are options that can be used to configure Lock for Android to your project's needs. **Note that if you are a user of Lock v1 who is now migrating to Lock v2**, you'll want to take note first of those [options that have been renamed or whose behavior have changed](/libraries/lock-android/migration-guide), and then look over the new list below, which contains quite a few options new to v2.
+
+Configurations options are added to the Lock Builder using the following format:
+
+```java
+ lock = Lock.newBuilder(auth0, callback)
+    // Configuration options
+    .closable(true)
+    .allowSignUp(false)
+    .setPrivacyURL('http://example.com/privacy')
+    .setTermsURL('http://example.com/terms')
+    // End configuration options
+    .build(this);
+```
+
+## UI options
+
+- **closable(boolean)**: Defines if the LockActivity can be closed. By default it's not closable.
+- **allowedConnections(List)**: Filters the allowed connections from the list configured in the Dashboard. By default if this value is empty, all the connections defined in the dashboard will be available.
+
+## Authentication options
+
+- **withAuthenticationParameters(Map)**: Defines extra authentication parameters to be sent on each log in and sign up call. The default `scope` used on authentication calls is `openid`. If you want to specify a different one, use `withAuthenticationParameters` and add a different value for the `scope` key.
+- **withScope(String)**: Changes the scope requested when performing an authentication request.
+
+## Database options
+
+- **withUsernameStyle(int)**: Defines if it should ask for email only, username only, or both of them. The accepted values are `USERNAME` and `EMAIL`. By default it will respect the Dashboard configuration of the parameter `requires_username`.
+- **loginAfterSignUp(boolean)**: Whether after a `SignUp` event the user should be logged in automatically. Defaults to `true`.
+- **initialScreen(int)**: Allows to customize which form will first appear when launching Lock. The accepted values are `LOG_IN`, `SIGN_UP`, and `FORGOT_PASSWORD`. By default `LOG_IN` is the initial screen.
+- **allowSignUp(boolean)**: Shows the Sign Up form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`.
+- **allowLogIn(boolean)**: Shows the Log In form if a Database connection is configured. Defaults to `true`.
+- **allowForgotPassword(boolean)**: Shows the Forgot Password form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`.
+- **allowShowPassword(boolean)**: Shows a button to toggle the input visibility of a Password field. Defaults to `true`.
+- **setDefaultDatabaseConnection(String)**: Defines which will be the default Database connection. This is useful if your application has many Database connections configured.
+- **withSignUpFields(List)**: Shows a second screen with extra fields for the user to complete after the username/email and password were completed in the sign up screen. Values submitted this way can be stored in the user profile using either a root attribute or the `user_metadata` attribute. For more info, see [Lock Android: Custom Fields at Signup](/libraries/lock-android/custom-fields).
+- **setPrivacyURL(String)**: Allows to customize the Privacy Policy URL. Defaults to `https://auth0.com/privacy`.
+- **setTermsURL(String)**: Allows to customize the Terms of Service URL. Defaults to `https://auth0.com/terms`.
+- **setSupportURL(String)**: Allows to set a Support URL that will be displayed in case that a non-recoverable error raises on Lock.
+- **setMustAcceptTerms(boolean)**: Forces the user to accept the Terms&Policy before signing up. Defaults to `false`.
+- **useLabeledSubmitButton(boolean)**: If set to `true`, it will display a label of the current mode (sign up/ log in) in the submit button instead of an icon. Defaults to `true`. If the `hideMainScreenTitle` option is set to true this setting is ignored and a label will be used anyways.
+- **hideMainScreenTitle(boolean)**: If set to `true`, the header on the main screen won't display the title.
+
+## OAuth options
+
+- **withAuthStyle(String, int)**: Customize the look and feel of a given connection (name) with a specific style. See [this document on custom oauth connections](/libraries/lock-android/v2/custom-theming#custom-oauth-connection-buttons) for more information.
+- **withAuthHandlers(AuthHandler...)**: Customize the authentication process by passing an array of AuthHandlers. See [this document on custom authentication parameters](/libraries/lock-android/custom-authentication-providers) for more information.
+- **withConnectionScope(String, String...)**: Allows to specify additional scopes for a given Connection name, which will be request along with the ones defined in the connection settings in the [Auth0 Dashboard](${manage_url}). The scopes are not validated in any way and need to be recognized by the given authentication provider. For a list, check in the [Auth0 Dashboard](${manage_url}) under the settings for the connection in question.
+- **withScheme(String)**: Allows to change the scheme of the `redirect_uri` sent on the authorize call. By default, the scheme is `https`. When changing this setting, the intent-filter on the `AndroidManifest.xml` file and the Allowed Callbacks URLs on the application dashboard must be updated too.
+
+## Passwordless options
+
+- **useCode()**: Send a code instead of a link via email/SMS for Passwordless authentication.
+- **useLink()**: Send a link instead of a code via email/SMS for Passwordless authentication.
+- **rememberLastLogin(boolean)**: Whether the email or phone used in the last successful authentication will be saved to auto-login the next time a Passwordless authentication is requested.
diff --git a/ja-jp/articles/libraries/lock-android/v2/custom-authentication-providers.md b/ja-jp/articles/libraries/lock-android/v2/custom-authentication-providers.md
new file mode 100644
index 0000000000..44e93d8d40
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/custom-authentication-providers.md
@@ -0,0 +1,77 @@
+---
+section: libraries
+title: Lock Android v2 Custom Authentication Providers
+description: Implementing custom authentication providers
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Custom Authentication Providers
+
+**Auth0.Android** includes the `WebAuthProvider` class to handle the authorize flow using the Browser. But what if you want to use your own implementation or a Native version of an `AuthProvider`?
+
+## The AuthProvider class
+
+Create a class that implements the `AuthProvider` interface and override its methods.
+
+You can also use any **Native** implementation already provided by Auth0. The [native social authentication](/libraries/lock-android/v2/native-social-authentication) providers currently available are Google and Facebook.
+
+::: warning
+The native social providers rely on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. We recommend using browser-based flows, as explained in [Authentication via Universal Login](/libraries/auth0-android#authentication-via-universal-login).
+:::
+
+## The AuthHandler class
+
+**Auth0.Android** includes an interface for you to implement and define which provider to use given a Strategy and Connection name. It has a single method that returns an `AuthProvider` for a given strategy/connection name. If no provider can handle those values, it should return `null`. On **Lock** side, when no provider is returned it will default to `WebAuthProvider`.
+
+```java
+public interface AuthHandler {
+ //Will return a nullable AuthProvider to handle that strategy/connection.
+ @Nullable
+ AuthProvider providerFor(@Nullable String strategy, @NonNull String connection);
+}
+```
+
+### Usage Example
+
+```java
+public class MyAuthHandler implements AuthHandler {
+
+  @Nullable
+  @Override
+  public AuthProvider providerFor(@Nullable String strategy, @NonNull String connection){
+    AuthProvider provider = null;
+    if ("linkedin".equals(strategy)) {
+      provider = new MyLinkedInProvider();
+    } else if ("twitter".equals(strategy)) {
+      if (connection.equals("twitter-dev")) {
+        provider = new TwitterDevProvider();
+      } else {
+        provider = new TwitterProvider();
+      }
+    }
+    return provider;
+  }
+}
+```
+
+Finally, on the `Lock.Builder` class you need to set the AuthHandlers to use on that **Lock** instance.
+
+```java
+builder.withAuthHandlers(Arrays.asList(new MyAuthHandler()));
+```
+
+This way when **Lock** needs to authenticate a user with OAuth, it will ask the handlers **respecting the given order**, which of them can handle a given connection/strategy name. If the first one can handle it, the second won't be called. If no handlers can match the request (Lock received `null`), Lock will internally default to use `WebAuthProvider`. Also note that `strategy` can be null.
+
+::: note
+In this example we used `MyLinkedInProvider`, `TwitterDevProvider` and `TwitterProvider` classes **not** included in **Lock**.
+:::
+
+Our Google and Facebook [native social providers](/libraries/lock-android/v2/native-social-authentication) will provide `AuthHandler`s for you to use directly with **Lock**.
diff --git a/ja-jp/articles/libraries/lock-android/v2/custom-fields.md b/ja-jp/articles/libraries/lock-android/v2/custom-fields.md
new file mode 100644
index 0000000000..f68d7cf54b
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/custom-fields.md
@@ -0,0 +1,84 @@
+---
+section: libraries
+title: Lock Android v2 Custom Fields at Signup
+description: Adding additional fields to signups with Lock for Android
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Custom Fields at Signup
+
+**Lock.Android** allows you to specify additional fields that the user must complete before creating a new account. The extra fields will be shown on a second screen after the user completes the basic fields (email, username, password).
+
+## Create the Custom Fields
+
+Create a new `CustomField` object passing all these 4 mandatory parameters.
+
+1. Icon: The `int` that points to the resource you want to use as Icon (keep it small).
+1. Type: The `FieldType` to use in this field. The type defines the keyboard layout and sometimes the input validation.
+1. Key: The `String` that identifies this value in the result JSON. It shouldn't be repeated! Repeated field keys will result in the second field getting removed from the list.
+1. Hint: The `@StringRes` of the text to show as hint in the field.
+
+In addition, you can specify where the field is going to be stored on the user's profile. See the [Storage](#storage) section below for details.
+
+```java
+List customFields = new ArrayList<>();
+
+CustomField fieldName = new CustomField(R.drawable.ic_field_person, FieldType.TYPE_TEXT_NAME, "firstName", R.string.hint_first_name);
+customFields.add(fieldName);
+```
+
+Repeat the above steps as many times as fields you need.
+
+## Use the Custom Fields
+
+Create a new `List` to store the fields. Pass the list to the `Lock.Builder` before you build it, using the method `withSignUpFields()`.
+
+```java
+Lock lock = Lock.newBuilder(auth0, callback)
+              .withSignUpFields(customFields)
+              //...
+              .build(this);
+```
+
+That's it! If you have enabled users Sign Up in the Application's Dashboard, after they complete the basic fields (email/username, password) and hit Submit, they will be prompted to fill the remaining fields.
+
+::: note
+The user must fill all of the custom fields before being able to complete signup.
+:::
+
+When requesting a user Sign Up or Sign In, the extra fields will be attached to the `user_metadata` attribute in the request body. You can access them by querying the user profile at any time, even from the Dashboard in the User's section.
+
+## Field Types
+
+Each custom field can only have one `FieldType` associated.
+
+* TYPE_NAME
+* TYPE_NUMBER
+* TYPE_PHONE_NUMBER
+* TYPE_EMAIL
+
+## Storage
+
+Each custom field can only have one `Storage` associated. You can choose to store it right at the root level in a root attribute or inside the `user_metadata` attribute. To specify the storage location, use the five-parameter constructor and pass the `Storage` parameter of your choice (see below). By default, fields will be stored inside the `user_metadata` attribute.
+
+Available choices:
+
+* PROFILE_ROOT
+* USER_METADATA (default)
+
+```java
+CustomField fieldName = new CustomField(R.drawable.ic_field_person, FieldType.TYPE_TEXT_NAME, "firstName", R.string.hint_first_name, Storage.PROFILE_ROOT);
+```
+
+::: note
+For the fields to be saved at the root level of the user's profile, their keys must match the ones listed in the [endpoint documentation](/api/authentication#signup).
+:::
+
diff --git a/ja-jp/articles/libraries/lock-android/v2/custom-theming.md b/ja-jp/articles/libraries/lock-android/v2/custom-theming.md
new file mode 100644
index 0000000000..9ed6a02d3f
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/custom-theming.md
@@ -0,0 +1,107 @@
+---
+section: libraries
+title: Lock Android v2 Custom Theming
+description: Customizing the Lock for Android UI
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Custom Theming
+
+The **Lock.Android** UI is very customizable. Various items such as the header logo and title, some colors, buttons, and other items can be altered.
+
+## Supported attributes list
+
+| Name | Type | Description |
+| :--- | :---: | :--- |
+|Auth0.HeaderLogo | drawable - reference | Logo drawable to display inside the header. |
+|Auth0.HeaderTitle | string - reference | Text to display as Title inside the header. |
+|Auth0.HeaderTitleColor | color - reference | Color for the Title text. |
+|Auth0.HeaderBackground | color - reference | Used as background color in the header. |
+|Auth0.PrimaryColor | color - reference | Used as _normal_ state in widgets like the Submit button. Also used as _accent_ color. |
+|Auth0.DarkPrimaryColor | color - reference | Used as _pressed_ state in widgets like the Submit button. |
+
+## Create a New Resource File
+
+First you need to create a new `Theme` that extends from `Lock.Theme`, and override the attributes you want to customize.
+
+styles.xml
+
+```xml
+
+  
+
+```
+
+::: note
+Those attributes not overridden by the user will default to the ones defined in `Lock.Theme`.
+:::
+
+Then, you need to tell the Manifest that you want to use the new `MyTheme` in the `Activity`. This is **very important**!!
+
+```xml
+
+    
+        
+        
+    
+
+```
+
+## Pay Attention to the Manifest
+
+Please note that if you define your own Theme in a style resource file and forget to specify that the Theme's parent is `Lock.Theme`, or you forget to tell the Manifest which will be the Theme for the Activity, you will end up with a really bad looking UI. This may also happen if the values you specify in your custom Theme are invalid.
+
+## Custom OAuth Connection Buttons
+
+::: note
+In order to customize OAuth connection styles, first you must create a new connection by using the `Custom Social Connections` [extension](${manage_url}/#/extensions), filling in every required field before saving the changes.
+:::
+
+To customize OAuth connection styles in Lock you can call the builder passing both the `connectionName` and the `style` to use.
+
+First create a custom style extending `Lock.Theme.AuthStyle` and define the logo, background color and name of the connection.
+
+```xml
+
+```
+
+Now in the builder's setup add the `AuthStyle` for the connection name that you want to override.
+
+```java
+builder.withAuthStyle("facebook", R.style.Style_Facebook)
+        .build(...);
+```
+
+When **Lock** needs to display that connection in a **SocialButton**, it will first search for user-overridden styles, and if none are found, it will default to the Lock social defaults. This means that for `facebook` in particular it would use Facebook background color, Facebook logo and `FACEBOOK` as name.
+
+As the builder method receives the `connectionName` you can then customize `oauth2` strategy type connections. The default values for this strategy (if none are provided) are the Auth0 logo, Auth0 background color, and `OAUTH2` as the name.
diff --git a/ja-jp/articles/libraries/lock-android/v2/delegation-api.md b/ja-jp/articles/libraries/lock-android/v2/delegation-api.md
new file mode 100644
index 0000000000..98291b7eb8
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/delegation-api.md
@@ -0,0 +1,57 @@
+---
+section: libraries
+title: Lock for Android v2 Delegation API
+description: Integrate with third-party apps with the delegation API.
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Delegation API
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/api/authentication/reference#delegation) using a valid JWT.
+
+Here's an example
+
+```java
+Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+auth0.setOIDCConformant(true);
+AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
+String apiType = "firebase";
+String token = //Your Auth0 ID Token of the logged in User
+client.delegationWithIdToken(token, apiType)
+  .start(new BaseCallback, AuthenticationException>() {
+        @Override
+        public void onSuccess(Map payload) {
+            //Your Firebase token will be in payload
+        }
+
+        @Override
+        public void onFailure(AuthenticationException error) {
+            //Delegation call failed
+        }
+    });
+```
+
+::: note
+The delegation response is a generic Map since the structure of it will depend of the `api_type` used for delegation
+:::
+
+The only two parameters required are `id_token` and `api_type`, the former is the token returned by Auth0 after a successful authentication, the latter specifies the API credentials we want to retrieve, and these are its supported values:
+
+* app: Your Auth0 application. This will get a new JWT token.
+* aws: Amazon Web Services API.
+* azure_sb: Windows Azure Service Bus.
+* firebase: Firebase API.
+* salesforce_api: Salesforce API.
+* salesforce_sandbox_api: Salesforce Sandbox API.
+* sap_api: SAP OData.
+* wams: Windows Azure Mobile Services.
diff --git a/ja-jp/articles/libraries/lock-android/v2/index.md b/ja-jp/articles/libraries/lock-android/v2/index.md
new file mode 100644
index 0000000000..1eb9d180a9
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/index.md
@@ -0,0 +1,297 @@
+---
+section: libraries
+toc: true
+title: Lock for Android v2
+description: A widget that provides a frictionless login and signup experience for your native Android apps.
+mobileimg: media/articles/libraries/lock-android.png
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - index
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Getting Started
+
+::: warning
+Auth0 encourages the use of [web authentication via Universal Login](/guides/login/universal-vs-embedded) rather than native username/password authentication whenever possible.
+:::
+
+Lock for Android can integrate into your native Android apps to provide a beautiful way to log your users in and to sign them up in your app. It provides support for social identity providers such as Facebook, Google, or Twitter, as well as enterprise providers such as Active Directory.
+
+Get started using Lock for Android below, or if you're looking for a specific document beyond basic setup of Lock, try the listing of [next steps](#next-steps) for working with Lock for Android.
+
+::: note
+Check out the [Lock.Android repository](https://github.com/auth0/Lock.Android) on GitHub.
+:::
+
+## Requirements
+
+To use Lock's UI or your own UI via the [Auth0.Android library](https://github.com/auth0/Auth0.Android) the minimum required Android API level is 15+.
+
+## Installation
+
+Lock is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To start using *Lock* add these lines to your `build.gradle` dependencies file:
+
+```gradle
+compile 'com.auth0.android:lock:2.+'
+```
+
+::: note
+You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock).
+:::
+
+After adding your Gradle dependency, make sure to remember to sync your project with Gradle files.
+
+## Dashboard settings
+
+You need to fill in a few settings in your [Auth0 Dashboard](${manage_url}) before you get started.
+
+### Callback URL
+
+Head over to your Auth0 Dashboard and go to the application's settings. Add the following URL to the application's "Allowed Callback URLs"
+
+```text
+https://${account.namespace}/android/{YOUR_APP_PACKAGE_NAME}/callback
+```
+
+::: note
+Replace `{YOUR_APP_PACKAGE_NAME}` with your actual application's package name, available in your `app/build.gradle` file as the `applicationId` value.
+:::
+
+### Keystores and key hashes
+
+You will need a [Keystore](https://developer.android.com/studio/publish/app-signing.html) for signing your Android app. If you already have one, you can continue and skip the instructions about acquiring one.
+
+During development, you can use the default "android debug keystore" to sign your application. For instructions on how to generate the key hashes using this keystore, use our [Android Keystores and Key Hashes Guide](/libraries/lock-android/v2/keystore).
+
+For a release keystore, replace the file, alias, store password and key password with your own values.
+
+## Implementing Lock (Social, Database, Enterprise)
+
+The following instructions discuss implementing Lock for Android. If you specifically are looking to implement Passwordless Lock for Android, read the [Passwordless Authentication with Lock for Android](/libraries/lock-android/v2/passwordless) page.
+
+### Configuring the SDK
+
+In your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI.
+
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    compileSdkVersion 25
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 15
+        targetSdkVersion 25
+        //...
+
+        //---> Add the next line
+        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"]
+        //<---
+    }
+    //...
+}
+```
+
+It's a good practice to define reusable resources like `@string/com_auth0_domain` but you can also hard code the value to `${account.namespace}` in the file.
+
+Next, modify the `AndroidManifest.xml` file. Add the `android.permission.INTERNET` permission to allow Lock to make requests to the Auth0 API.
+
+```xml
+
+```
+
+Add the `LockActivity`.
+
+```xml
+
+```
+
+::: note
+In versions 2.5.0 or lower of Lock.Android you had to define an **intent-filter** inside the `LockActivity` to make possible to the library to capture the authentication result. This intent-filter declaration is no longer required for versions greater than 2.5.0, as it's now done internally by the library for you.
+:::
+
+In case you are using an older version of Lock the **intent-filter** must be added to the `LockActivity` by you:
+
+```xml
+
+    
+        
+        
+        
+        /callback"
+            android:scheme="https" />
+    
+
+```
+
+#### Some restrictions
+
+* Make sure the `LockActivity` launchMode is declared as `singleTask` or the result won't come back after the authentication.
+* Also note that for the time being, `LockActivity` can't be launched by calling `startActivityForResult`.
+
+### Auth0
+
+Create an `Auth0` instance to hold your account details, which are the `AUTH0_CLIENT_ID` and the `AUTH0_DOMAIN`.
+
+```java
+Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+```
+
+### OIDC Conformant Mode
+
+It is strongly encouraged that Lock be used in OIDC Conformant mode. When this mode is enabled, it will force Lock to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. By default is `false`.
+
+```java
+Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
+//Configure the account in OIDC conformant mode
+account.setOIDCConformant(true);
+//Use the account to launch Lock
+```
+
+For more information, please see the [OIDC adoption guide](/api-auth/tutorials/adoption).
+
+### Authentication callback
+
+You'll also need a `LockCallback` implementation. Here is an example which will notify you about Authentication events (logins).
+
+```java
+private LockCallback callback = new AuthenticationCallback() {
+     @Override
+     public void onAuthentication(Credentials credentials) {
+        //Authenticated
+     }
+
+     @Override
+     public void onCanceled() {
+        //User pressed back
+     }
+
+     @Override
+     public void onError(LockException error)
+        //Exception occurred
+     }
+ };
+```
+
+::: note
+The results of the AuthenticationCallback are in a `credentials` object. This object contains the tokens that you will require for authentication related operations in your app; see [Tokens](/tokens) for more specifics.
+:::
+
+### Lock.Builder
+
+To create a new `Lock` instance and configure it, use the `Lock.Builder` class. Call the static method `Lock.newBuilder(Auth0, LockCallback)`, passing the account details and the callback implementation, and start configuring the Options as you need. After you're done, build the Lock instance and use it to start the `LockActivity`.
+
+To ensure a response that complies with OpenID Connect (OIDC), you must either request an `audience` or enable the **OIDC Conformant** switch in your Auth0 dashboard under `Application / Settings / Advanced OAuth`. You can read more about this [here](/api-auth/intro#how-to-use-the-new-flows).
+
+This is an example of what your `Activity` should look:
+
+```java
+public class MainActivity extends Activity {
+  private Lock lock;
+
+  @Override
+  protected void onCreate(@Nullable Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+    // Your own Activity code
+    Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+    auth0.setOIDCConformant(true);
+    lock = Lock.newBuilder(auth0, callback)
+      .withAudience("https://${account.namespace}/userinfo")
+      // ... Options
+      .build(this);
+  }
+
+  @Override
+  public void onDestroy() {
+    super.onDestroy();
+    // Your own Activity code
+    lock.onDestroy(this);
+    lock = null;
+  }
+
+  private LockCallback callback = new AuthenticationCallback() {
+       @Override
+       public void onAuthentication(Credentials credentials) {
+          //Authenticated
+       }
+
+       @Override
+       public void onCanceled() {
+          //User pressed back
+       }
+
+       @Override
+       public void onError(LockException error) {
+          //Exception occurred
+       }
+   };
+}
+```
+
+Remember to notify Lock's instance when your activity calls the `OnDestroy` method, as it helps to keep the state.
+
+Then, start `Lock` from inside your activity.
+
+```java
+startActivity(lock.newIntent(this));
+```
+
+That's it! Lock will handle the rest for you.
+
+### Android App Links - Custom Scheme
+
+The callback URI scheme used in this article is `https`. This works best for Android Marshmallow (API 23) or newer if you're using [Android App Links](https://developer.android.com/training/app-links/index.html), but in previous Android versions this may show the intent chooser dialog prompting the user to chose either your application or the browser to resolve the intent. You can change this behavior by using a custom unique scheme so that the OS opens the link directly with your app.
+Do so by updating the `app/build.gradle` file and changing the `auth0Scheme` value. Then go to your application's dashboard and update the "Allowed callback URL" value to match the new scheme. Now call `withScheme()` in the Lock.Builder and pass the custom value so that Lock requests the correct redirect URI.
+
+## Implementing Passwordless authentication with Lock for Android
+
+For instructions on how to implement Passwordless authentication with Lock for Android, please see the [Passwordless Guide](/libraries/lock-android/v2/passwordless).
+
+## Proguard
+
+The proguard rules should be applied automatically if your application is using `minifyEnabled = true`. If you want to include them manually check the [proguard directory](https://github.com/auth0/Lock.Android/tree/master/proguard). By default you should at least use the following files:
+
+By default you should at least use the following files:
+
+* `proguard-gson.pro`
+* `proguard-otto.pro`
+* `proguard-lock-2.pro`
+
+As this library depends on `Auth0.Android`, you should keep the files up to date with the proguard rules defined in that [repository](https://github.com/auth0/Lock.Android).
+
+## Lock configuration
+
+For a full list of Lock's configuration options, check out the [Lock for Android Configuration Reference](/libraries/lock-android/v2/configuration).
+
+## Error messages
+
+For descriptions of common error messages, check out the [Error Messages](/libraries/error-messages) page. Also, if your callback receives an `AuthenticationException` you can check [source](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/authentication/AuthenticationException.java) to learn how to identify each error scenario.
+
+## Next Steps
+
+::: next-steps
+* [Customizing the Style of Lock](/libraries/lock-android/custom-theming)
+* [Customizing the Behavior of Lock](/libraries/lock-android/configuration)
+* [Adding Custom Signup Fields to Lock](/libraries/lock-android/custom-fields)
+* [Lock Internationalization](/libraries/lock-android/internationalization)
+* [Logging out Users](/logout)
+:::
diff --git a/ja-jp/articles/libraries/lock-android/v2/internationalization.md b/ja-jp/articles/libraries/lock-android/v2/internationalization.md
new file mode 100644
index 0000000000..f2dc13d979
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/internationalization.md
@@ -0,0 +1,44 @@
+---
+section: libraries
+title: Lock Android v2 Internationalization
+description: Internationalization support in Lock for Android
+topics:
+  - libraries
+  - lock
+  - android
+  - i18n
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Internationalization
+
+By default, **Lock.Android** displays all text in English. If you wish to display text in another language, you may provide a `strings.xml` file and define values to be used for the various text items that Lock might display.
+
+Android asks the device what _locale_ was configured by the user and tries to fetch the list of localized texts for that language. For this to work, the developer needs to add each translation file into the app by using a special folder naming convention as per Android standards. More information can be found in the [Android developer docs](https://developer.android.com/training/basics/supporting-devices/languages.html).
+
+Some of the default values provided by Lock include:
+
+```html
+
+  Error parsing Authentication data
+  There was an error during authentication
+  ...
+
+```
+
+By providing your own `strings.xml` file, these values can be adjusted as such:
+
+```html
+
+  There was an authentication error!
+  Social login error!!
+  ...
+
+```
+
+## Lock String Values
+
+For a full list of the names used by Lock, see the [default strings.xml file](https://github.com/auth0/Lock.Android/blob/master/lib/src/main/res/values/strings.xml) in the Lock.Android repository.
diff --git a/ja-jp/articles/libraries/lock-android/v2/keystore.md b/ja-jp/articles/libraries/lock-android/v2/keystore.md
new file mode 100644
index 0000000000..7b31c26d29
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/keystore.md
@@ -0,0 +1,64 @@
+---
+section: libraries
+title: Android Development Keystores and Key Hashes
+description: Instructions on acquiring development keystores/key hashes during Android app development.
+topics:
+  - libraries
+  - lock
+  - android
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Android Development Keystores and Key Hashes
+
+When creating a new OAuth Credential for many connections you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's configuration in the [Auth0 Dashboard](${manage_url}) you will also need to provide the SHA-256 value.
+
+Locate the certificate you're using to sign your application. If you don't have one you can generate it. For production applications, you should do this.
+
+During development, you can sign your application with the default `android.keystore` certificate that was generated automatically for you when you installed the SDK. In this example we're going to use this default keystore. To generate the key hashes using this keystore follow the examples below.
+
+## Generating your key hashes
+
+**On Windows:**
+
+```bash
+keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android
+```
+
+**On Linux / macOS:**
+
+```bash
+keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
+```
+
+**Sample output:**
+
+```text
+Alias name: androiddebugkey
+Creation date: Jan 01, 2013
+Entry type: PrivateKeyEntry
+Certificate chain length: 1
+Certificate[1]:
+Owner: CN=Android Debug, O=Android, C=US
+Issuer: CN=Android Debug, O=Android, C=US
+Serial number: 4aa9b300
+Valid from: Mon Jan 01 08:04:04 UTC 2013 until: Mon Jan 01 18:04:04 PST 2033
+Certificate fingerprints:
+     MD5:  AE:9F:95:D0:A6:86:89:BC:A8:70:BA:34:FF:6A:AC:F9
+     SHA1: BB:0D:AC:74:D3:21:E1:43:07:71:9B:62:90:AF:A1:66:6E:44:5D:75
+     SHA256: 15:B9:F9:33:9F:E4:E3:68:C2:10:49:17:5D:A8:77:12:7C:8E:57:E9:FF:B7:23:EA:CC:DD:56:08:06:C9:5E:33
+     Signature algorithm name: SHA256withRSA
+     Version: 3
+```
+
+## Using your key hashes
+
+Once you have your key hashes output, copy the resulting SHA256 value and go to your application's settings in the [Auth0 Dashboard](${manage_url}/#/applications). Click "Show Advanced Settings", and in the "Device Settings" tab, under "Android", fill the "App Package Name" with your application's package name, and the "Key Hashes" field with the SHA256 value you copied. Don't forget to save the changes.
+
+::: warning
+If you don't add the Callback URL to the application settings nor the Key Hashes to the application's device settings, the Auth0 server won't return the call result to your application.
+:::
diff --git a/ja-jp/articles/libraries/lock-android/v2/migration-guide.md b/ja-jp/articles/libraries/lock-android/v2/migration-guide.md
new file mode 100644
index 0000000000..7fcc499bb9
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/migration-guide.md
@@ -0,0 +1,67 @@
+---
+section: libraries
+title: Lock Android v2 Migration Guide
+description: A reference for changed option names and behaviors in Lock for Android v2
+public: false
+topics:
+  - libraries
+  - lock
+  - android
+  - migrations
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+  - migrate
+---
+# Lock Android: Migration Guide
+
+## Application Class and Initializing Lock
+
+In v1 of Lock for Android, you were asked to create a custom `Application` class and initialize the `Lock.Context` there. **Now this is no longer needed**. In v2, to create a new `Lock` instance and configure it, you will just use the `Lock.Builder` class. The configurable options in v2 have been expanded, allowing more configuration while making the implementation and customization process easier than in v1.
+
+## Obtaining the User's Profile
+
+In v1, when an authentication was successful, you could obtain the UserProfile from the received Intent. As of v2, the only received value is a `Credentials` object. You can get the Access Token and request the information associated to that user, by making a request to Auth0.
+
+1. Create a new `AuthenticationAPIClient` instance by passing an instance of the `Auth0` object. It can be the same instance used to launch Lock in the first place.
+1. Call the `userInfo` method on the API application passing the previously obtained Access Token.
+1. A `UserProfile` instance is returned
+
+```java
+Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+auth0.setOIDCConformant(true);
+String accessToken = credentials.getAccessToken();
+AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0);
+
+apiClient.userInfo(accessToken)
+  .start(new BaseCallback() {
+      @Override
+      public void onSuccess(final UserProfile information) {
+          //user information received
+      }
+
+      @Override
+      public void onFailure(AuthenticationException error) {
+          //user information request failed
+      }
+  });
+```
+
+## Changed Configuration Options
+
+As in the previous version, Lock for Android v2 can be configured with extra options. Check below if the behavior for the option has changed, or if they only got renamed.
+
+* `shouldUseWebView`: This option was renamed to `useBrowser`, but is now entirely **deprecated** and should not be used.
+* `shouldUseEmail`: Renamed to `withUsernameStyle`. Defines if it should ask for email only, username only, or both of them. By default it'll respect the Dashboard configuration of the parameter `requires_username`.
+* `isClosable`: Renamed to `closable`. Defines if the `LockActivity` can be closed. By default it's not closable.
+* `shouldLoginAfterSignUp`: Renamed to `loginAfterSignUp`. Determines whether after a signup the user should be logged in automatically. Defaults to `true`.
+* `disableSignupAction`: Renamed to `allowSignUp`. Shows the Sign Up form if a Database connection is configured. Defaults to `true`.
+* `disableResetAction`: Renamed to `allowForgotPassword`. Shows a link to the Forgot Password form if a Database connection is configured and it's allowed from the Dashboard. Defaults to `true`.
+* `defaultUserPasswordConnection`: Renamed to `setDefaultDatabaseConnection`. Defines which will be the default Database connection. This is useful if your application has many Database connections configured.
+* `setConnections`: Renamed to `allowedConnections`. Filters the allowed connections from the list configured in the Dashboard. If this value is empty, all the connections defined in the dashboard will be available. This is also the default behavior.
+* `setAuthenticationParameters`: Renamed to `withAuthenticationParameters`. Defines extra authentication parameters to be sent on sign up and log in/sign in. The default `scope` used on authentication calls is `openid`. This is changed from v1, which also included the `offline_access` scope.
+
+Lock for Android v2 also features a bunch of new options. Check the [configuration options page](/libraries/lock-android/configuration) for a complete list of them.
diff --git a/ja-jp/articles/libraries/lock-android/v2/native-social-authentication.md b/ja-jp/articles/libraries/lock-android/v2/native-social-authentication.md
new file mode 100644
index 0000000000..94576b4705
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/native-social-authentication.md
@@ -0,0 +1,405 @@
+---
+section: libraries
+title: Lock Android v2 Native Social Authentication
+description: Lock for Android - Native Social Authentication
+topics:
+  - libraries
+  - lock
+  - android
+  - native
+  - social-connections
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Native Social Authentication
+
+::: warning
+This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature. 
+We recommend using browser-based flows, as explained in [Authentication via Auth0 Universal Login](/libraries/auth0-android#authentication-via-universal-login).
+:::
+
+## Native Provider - Google
+
+You can use Google AuthProvider to log in with or without **Lock**. Make sure to follow the instructions in the [setup](#setup) section.
+
+[Lock-Google.Android](https://github.com/auth0/Lock-Google.Android)
+ requires Android API 15 or later & Google Play Services 10.+
+
+### Latest version of Lock-Google
+
+The Lock-Google is available through [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To install it, simply add the following line to your `build.gradle`:
+
+```gradle
+compile 'com.auth0.android:lock-google:1.+'
+```
+
+::: note
+You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock-Google.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock-google%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock-google).
+:::
+
+### Lock-Google Setup
+
+#### Google Developers Console
+
+1. Go to the [Google Developers Console](https://console.developers.google.com/) and create a new Project.
+2. Complete the [OAuth Consent Screen](https://console.developers.google.com/apis/credentials/consent) by at least providing a valid Email Address and Name.
+3. On the left side you have the navigation drawer, click [Credentials](https://console.developers.google.com/apis/credentials).
+4. Create a new credential by clicking the [Create Credentials](https://console.developers.google.com/apis/credentials/oauthclient) button and choosing **OAuth client ID**. Next, choose **Web Application** and give it a name like "Auth0 Server Google-OAuth". Complete the **Authorized redirect URIs** by filling the field with your callback URL, which should look like `https://${account.namespace}/login/callback`. Make sure to press ENTER before leaving the field and then click the Create button. Take note of the `CLIENT ID` and `CLIENT SECRET` values as we're going to use them later.
+5. Create a new credential by clicking the [Create Credentials](https://console.developers.google.com/apis/credentials/oauthclient) button and choosing **OAuth client ID**. Next, choose **Android** and give it a name like "Auth0 Android Google-OAuth". Obtain the **SHA-1** of the certificate you're using to sign your application and complete the first field with it. If you need help obtaining the SHA-1 check [this](#certificate-fingerprints) section. Finally, complete the last field with your android application **Package Name** and then click the Create button. Take note of the `CLIENT ID` value as we're going to use it later.
+
+#### Auth0 Dashboard
+
+1. Go to the Auth0 Dashboard and click [Social Connections](${manage_url}/#/connections/social).
+2. Click **Google** and a dialog will prompt.
+3. Complete the "Client ID" field with the `CLIENT ID` value obtained in the step 4 of the **Google Developers Console** section above.
+4. Complete the "Client Secret" field with the `CLIENT SECRET` value obtained in the step 4 of the **Google Developers Console** section above.
+5. Complete the "Allowed Mobile Client IDs" field with the `CLIENT ID` obtained in the step 5 of the **Google Developers Console** section above.
+6. Click the Save button.
+7. Go to the Auth0 Dashboard and click [Applications](${manage_url}/#/applications). If you haven't created yet one, do that first and get into your application configuration page.
+8. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Device Settings" tab.
+9. In the Android section, complete the **Package Name** with your application's package name. Finally, complete the **Key Hashes** field with the SHA-256 of the certificate you're using to sign your application. If you need help obtaining the SHA-256 check [this](#certificate-fingerprints) section. Click the "Save Changes" button.
+
+#### Android application
+
+1. In your android application, create a new String resource in the `res/strings.xml` file. Name it `google_server_client_id` and set as value the `CLIENT_ID` obtained in the step 5 of the **Google Developers Console** setup section above.
+2. Add the Google Play Services version MetaData to the `AndroidManifest.xml` file, inside the Application tag.
+
+```xml
+
+```
+
+3. Add the Internet Android permission to your `AndroidManifest.xml` file.
+
+```xml
+
+```
+
+4. When creating a new instance of the `GoogleAuthProvider` pass the `google_server_client_id` value obtained previously as the first parameter:
+
+```java
+public class MainActivity extends AppCompatActivity {
+  private GoogleAuthProvider provider;
+  // ...
+
+  @Override
+  protected void onCreate(Bundle savedInstanceState) {
+    Auth0 auth0 = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+    auth0.setOIDCConformant(true);
+    AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
+    provider = new GoogleAuthProvider(getString(R.string.google_server_client_id), client);
+  }
+
+  // ...
+}
+```
+
+::: note
+If you need further help with the Google SDK setup, please check Google's [Sign-In for Android Guide](https://developers.google.com/identity/sign-in/android).
+:::
+
+### Usage with Lock
+
+If you plan to use this provider with **Lock**, pass the instance of the provider to the `GoogleAuthHandler` class and add it to Lock's Builder when you create the Lock instance.
+
+```java
+GoogleAuthHandler handler = new GoogleAuthHandler(provider);
+lock = Lock.newBuilder(auth0, authCallback)
+        .withAuthHandlers(handler)
+        //...
+        .build(this);
+```
+
+### Usage without Lock
+
+If you plan to use this provider without **Lock**, make sure you override the `onActivityResult()` method and redirect the call to the provider instance. Finally, call start to begin the authentication process.
+
+```java
+// Define your own request codes
+private static final int RC_PERMISSIONS = 101;
+private static final int RC_AUTHENTICATION = 102;
+
+@Override
+protected void onActivityResult(int requestCode, int resultCode, Intent data) {
+    if (provider.authorize(requestCode, resultCode, data)) {
+        return;
+    }
+    super.onActivityResult(requestCode, resultCode, data);
+}
+
+private void beginAuthentication(){
+  provider.start(this, callback, RC_PERMISSIONS, RC_AUTHENTICATION);
+}
+```
+
+That's it, you're ready to run the application and log in using Google native provider!!
+
+### Additional Options
+
+#### Using a custom connection name
+
+To use a custom social connection name to authorize against Auth0, create the GoogleAuthProvider instance using the second constructor:
+
+```java
+GoogleAuthProvider provider = new GoogleAuthProvider("my-connection", "google-server-client-id", client);
+```
+
+#### Send additional authentication parameters
+
+To send additional parameters on the authentication call `setParameters`.
+
+```java
+Map parameters = new HashMap<>();
+//Add entries
+provider.setParameters(parameters);
+```
+
+#### Requesting a custom Google scope
+
+By default, the scope `Scopes.PLUS_LOGIN` is requested. You can customize the Scopes by calling `setScopes` with the list of Scopes. Each Google API (Auth, Drive, Plus..) specify its own list of Google Scopes.
+
+```java
+provider.setScopes(Arrays.asList(new Scope(Scopes.PLUS_ME), new Scope(Scopes.PLUS_LOGIN)));
+```
+
+#### Requesting custom Android runtime permissions
+
+This provider doesn't require any special _Android Manifest Permissions_ to authenticate the user. But if your use case requires them, you can let the AuthProvider handle them for you. Use the `setRequiredPermissions` method.
+
+```java
+provider.setRequiredPermissions(new String[]{"android.permission.GET_ACCOUNTS"});
+```
+
+If you're not using Lock then you'll have to handle the permission request result yourself. To do so, make your activity implement the `ActivityCompat.OnRequestPermissionsResultCallback` interface. When the `onRequestPermissionsResult` method gets called pass the result to the provider by calling `provider.onRequestPermissionsResult`.
+
+#### Log out / clear account.
+
+To log out the user so that the next time they are prompted to input their credentials call `clearSession`. After you do this the provider state will be invalid and you will need to call `start` again before trying to `authorize` a result. Calling `stop` has the same effect.
+
+```java
+provider.clearSession();
+```
+
+#### Remember the last login
+
+By default this provider will remember the last account used to log in. If you want to change this behavior, use the following method.
+
+```java
+provider.rememberLastLogin(false);
+```
+
+#### Certificate fingerprints
+
+When creating a new OAuth Credential in the Google Developers Console you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's Configuration in the Auth0 Dashboard you will also need to provide the SHA-256 value. Here is an example of the terminal command to acquire the value, and a sample result.
+
+Command:
+
+```sh
+keytool -exportcert -alias androiddebugkey -keystore  -storepass android | openssl sha1 -binary | openssl base64
+```
+
+Sample output:
+
+```text
+no71633JAC3qgzQYCbskprUr55k=
+```
+
+If you need assistance, you can follow this [Keystores Guide](/libraries/lock-android/keystore) to acquire those values.
+
+
+## Native Provider - Facebook
+
+You can use Facebook AuthProvider to log in with or without **Lock**. Make sure to follow the instructions in the [setup](#setup) section.
+
+[Lock-Facebook](https://github.com/auth0/Lock-Facebook.Android) requires Android API 15 or later & Facebook Android SDK 4.+
+
+## Latest version
+
+The Lock-Facebook is available through [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). To install it, simply add the following line to your `build.gradle`:
+
+```gradle
+compile 'com.auth0.android:lock-facebook:3.+'
+```
+
+_You can check for the latest version on the repository [Readme](https://github.com/auth0/Lock-Facebook.Android#install), in [Maven](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22lock-facebook%22%20g%3A%22com.auth0.android%22), or in [JCenter](https://bintray.com/auth0/android/lock-facebook)._
+
+### Lock-Facebook Setup
+
+#### Facebook Developers Console
+
+1. Go to the [Facebook Developers Console](https://developers.facebook.com/) and create a new App: Choose "Android" and give it a valid name. Click "Create new Facebook App ID".
+2. Add your application's **Package Name** and the name of the **Activity class** where you're using the provider and click the Next button.
+3. Add the **SHA-1** Base64 encoded Key Hashes of the certificates you're using to sign your application and click the Next button. If you need help obtaining the SHA-1 check [this](#certificate-fingerprints) section.
+4. Finally, scroll to the top of the page and click the Skip Quickstart button to go to your Facebook app's page.
+5. On the top of the page, you will find the `APP ID` and `APP SECRET` values. Save them as you're going to need them later.
+6. On the left side you have the navigation drawer. Click Settings and then Basic. Turn ON the **Single Sign-On** switch and click the Save button.
+7. Click Settings and then Advanced. Turn ON the **Native or desktop app?** switch.
+
+#### Auth0 dashboard
+
+1. Go to the Auth0 Dashboard and click [Social Connections](${manage_url}/#/connections/social).
+2. Click **Facebook** and a dialog will prompt.
+3. Complete the "App ID" field with the `APP ID` value obtained in the step 5 of the **Facebook Developers Console** section above.
+4. Complete the "App Secret" field with the `APP SECRET` value obtained in the step 5 of the **Facebook Developers Console** section above.
+5. Click the Save button.
+6. Go to the Auth0 Dashboard and click [Applications](${manage_url}/#/applications). If you haven't created yet one, do that first and get into your application configuration page.
+7. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Device Settings" tab.
+8. In the Android section, complete the **Package Name** with your application's package name. Finally, complete the **Key Hashes** field with the SHA-256 of the certificate you're using to sign your application. If you need help obtaining the SHA-256 check [this](#certificate-fingerprints) section. Click the "Save Changes" button.
+
+#### Android application
+
+1. In your android application, create a new String resource in the `res/strings.xml` file. Name it `facebook_app_id` and set as value the `APP ID` obtained in the step 5 of the **Facebook Developers Console** setup section above.
+2. Add the `FacebookActivity` and `facebook_app_id` MetaData to the `AndroidManifest.xml` file, inside the Application tag.
+
+```xml
+
+
+```
+
+3. Add the Internet Android permission to your `AndroidManifest.xml` file.
+
+```xml
+
+```
+
+4. Create a new instance of the `FacebookAuthProvider`.
+
+```java
+public class MainActivity extends AppCompatActivity {
+  private FacebookAuthProvider provider;
+  // ...
+
+  @Override
+  protected void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+    Auth0 auth0 = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain));
+    auth0.setOIDCConformant(true);
+    AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
+    provider = new FacebookAuthProvider(client);
+  }
+
+  // ...
+}
+```
+
+::: note
+If you need further help with the Facebook SDK setup, please check Facebook's [Getting Started Guide](https://developers.facebook.com/docs/android/getting-started).
+:::
+
+### Usage with Lock
+
+If you plan to use this provider with **Lock**, pass the instance of the provider to the `FacebookAuthHandler` class and add it to Lock's Builder when you create the instance.
+
+```java
+FacebookAuthHandler handler = new FacebookAuthHandler(provider);
+lock = Lock.newBuilder(auth0, authCallback)
+        .withAuthHandlers(handler)
+        //...
+        .build(this);
+```
+
+### Usage without Lock
+
+If you plan to use this provider without **Lock**, make sure you override the `onActivityResult()` method of your activity and redirect the call to the provider instance. Finally, call start to begin the authentication process.
+
+```java
+// Define your own request codes
+private static final int RC_PERMISSIONS = 101;
+private static final int RC_AUTHENTICATION = 102;
+
+@Override
+protected void onActivityResult(int requestCode, int resultCode, Intent data) {
+    if (provider.authorize(requestCode, resultCode, data)) {
+        return;
+    }
+    super.onActivityResult(requestCode, resultCode, data);
+}
+
+private void beginAuthentication(){
+  provider.start(this, callback, RC_PERMISSIONS, RC_AUTHENTICATION);
+}
+```
+
+That's it, you're ready to run the application and log in using Facebook native provider!!
+
+### Additional options
+
+#### Using a custom connection name
+
+To use a custom social connection name to authorize against Auth0, call `setConnection` with your new connection name.
+
+```java
+FacebookAuthProvider provider = new FacebookAuthProvider("my_connection_name", client);
+```
+
+#### Send additional authentication parameters
+
+To send additional parameters on the authentication call `setParameters`.
+
+```java
+Map parameters = new HashMap<>();
+//Add entries
+provider.setParameters(parameters);
+```
+
+#### Requesting custom Facebook permissions
+
+By default, the permission `public_profile` is requested. You can customize them by calling `setPermissions` with the list of Facebook Permissions.
+
+```java
+provider.setPermissions(Arrays.asList("public_profile", "user_photos"));
+```
+
+#### Requesting custom Android runtime permissions
+
+This provider doesn't require any special _Android Manifest Permissions_ to authenticate the user. But if your use case requires them, you can let the AuthProvider handle them for you. Use the `setRequiredPermissions` method to specify them.
+
+```java
+provider.setRequiredPermissions(new String[]{"android.permission.GET_ACCOUNTS"});
+```
+
+If you're not using Lock then you'll have to handle the permission request result yourself. To do so, make your activity implement the `ActivityCompat.OnRequestPermissionsResultCallback` interface. When the `onRequestPermissionsResult` method gets called pass the result to the provider by calling `provider.onRequestPermissionsResult`.
+
+#### Log out / clear account.
+
+To log out the user so that the next time they are prompted to input their credentials call `clearSession`. After you do this the provider state will be invalid and you will need to call `start` again before trying to `authorize` a result. Calling `stop` has the same effect.
+
+```java
+provider.clearSession();
+```
+
+#### Remember the last Login
+
+By default this provider will remember the last account used to log in. If you want to change this behavior, use the following method.
+
+```java
+provider.rememberLastLogin(false);
+```
+
+### Certificate fingerprints
+
+When creating a new OAuth Credential in the Facebook Developers Console you will need to provide the SHA-1 of the certificate you're using to sign your application. When completing your Application's Configuration in the Auth0 Dashboard you will also need to provide the SHA-256 value. Here is an example of the terminal command to acquire the value, and a sample result.
+
+Command:
+
+```sh
+keytool -exportcert -alias androiddebugkey -keystore  -storepass android | openssl sha1 -binary | openssl base64
+```
+
+Sample output:
+
+```text
+SHA1: BB:0D:AC:74:D3:21:E1:43:07:71:9B:62:90:AF:A1:66:6E:44:5D:75
+SHA256: 15:B9:F9:33:9F:E4:E3:68:C2:10:49:17:5D:A8:77:12:7C:8E:57:E9:FF:B7:23:EA:CC:DD:56:08:06:C9:5E:33
+```
+
+If you need assistance, you can follow this [Keystores Guide](/libraries/lock-android/keystore) to acquire those values.
diff --git a/ja-jp/articles/libraries/lock-android/v2/passwordless-magic-link.md b/ja-jp/articles/libraries/lock-android/v2/passwordless-magic-link.md
new file mode 100644
index 0000000000..b2479a7542
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/passwordless-magic-link.md
@@ -0,0 +1,167 @@
+---
+section: libraries
+title: Lock Android v2 Passwordless with Magic Link
+description: Passwordless with Magic Link with Lock Android
+topics:
+  - libraries
+  - lock
+  - android
+  - passwordless
+  - magic-link
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Passwordless with Magic Link
+
+In order to avoid asking the user to input the one-time password sent for passwordless authentication in Android apps, we introduced the ability to send a link that the user can tap to login without any manual input involved.
+
+These links include the same code that would be used in the traditional passwordless flow, but with the correct configuration they will be handled automatically by the Android system and delivered to our application.
+
+## Auth0 Dashboard Configuration
+
+Go to your [application settings](${manage_url}/#/applications/${account.clientId}/settings) and click "Show Advanced Settings" at the bottom of the page. Then in the "Mobile Settings" tab you will need to provide both the Application's **Package Name** and certificate **Key Hash**.
+
+- **App Package Name**: This is the package name, as declared in the app's manifest. It's also available in the `app/build.gradle` file as the `applicationId` attribute. An example would be `com.example.android.myapp`
+- **Key Hashes**: This is an array of the SHA256 fingerprints of our android app’s signing certificates. This is an arbitrary length array, it can include all the fingerprints we want, so for example we could add both our release and debug fingerprints. An example would be `DE:1A:5B:75:27:AA:48:D5:A6:72:2F:76:43:95:9B:79:C6:86:1A:5B:75:27:AA:48:D5:A6:73:FE`.
+
+After you set the values make sure to click the "Save Changes" button. Next we'll have to configure either the Email connection.
+
+### Getting your Signing Certificates Fingerprint
+
+You can use the following command to generate the fingerprint via the Java keytool:
+
+```bash
+keytool -list -v -keystore my-release-key.keystore
+```
+
+or to obtain the default debug key:
+
+```bash
+keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
+```
+
+The value required by the dashboard is the one listed as **SHA256**.
+
+### Using Email Connection
+
+To use a passwordless connection via Email, we'll need to make sure the template is **HTML + Liquid** and that the email body contains *somewhere* a conditional like this:
+
+```liquid
+{% if send == 'link' or send == 'link_ios' or send == 'link_android' %}
+Your verification link is: {{ link }}
+{% elsif send == 'code' %}
+Your verification code is: {{ code }}
+{% endif %}
+```
+
+## Application Configuration
+
+Now that we have the Auth0 application configured, before we start with the android configuration we must follow the instructions and set up PasswordlessLock with `Lock.Android` as seen in the [passwordless docs](/libraries/lock-android/v2/passwordless). The only difference is that we'll add **Intent-Filters** that will capture the link click and redirect the user back to our app.
+
+In the `AndroidManifest.xml` file add the intent-filters inside the `PasswordlessLockActivity` activity tag. Depending on the chosen passwordless connection, the `pathPrefix` of the filter changes.
+
+```xml
+
+    
+    
+        
+        
+        
+        /email"
+          android:scheme="https" />
+    
+    
+
+```
+
+Make sure the Activity's `launchMode` is declared as `singleTask` or the result won't come back after the authentication.
+
+## Usage
+
+Lock Passwordless authenticates users by sending them an Email with a one-time password, which in this case will be a **LINK** instead of a CODE. We'll indicate this by calling the `useLink()` method.
+
+```java
+public class MyActivity extends AppCompatActivity {
+  private PasswordlessLock lock;
+
+  @Override
+  @SuppressWarnings("ConstantConditions")
+  protected void onCreate(@Nullable Bundle savedInstanceState) {
+      super.onCreate(savedInstanceState);
+      // Your own Activity code
+      Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+      auth0.setOIDCConformant(true);
+      lock = PasswordlessLock.newBuilder(auth0, callback)
+            .useLink()
+            .build(this);
+  }
+
+  @Override
+  public void onDestroy() {
+      super.onDestroy();
+      // Your own Activity code
+      lock.onDestroy(this);
+      lock = null;
+  }
+
+  private LockCallback callback = new AuthenticationCallback() {
+      @Override
+      public void onAuthentication(Credentials credentials) {
+          //Authenticated
+      }
+
+      @Override
+      public void onCanceled() {
+          //User pressed back
+      }
+
+      @Override
+      public void onError(LockException error) {
+          //Exception occurred
+      }
+  };
+}
+```
+
+Finally, just start `PasswordlessLock` from inside your activity and perform the login.
+
+```java
+startActivity(lock.newIntent(this));
+```
+
+After requesting the magic link from Auth0, the next screen will indicate that in order to log in, the user should tap it. We also offer a backup option to enter the code manually, just in case the links don't work.
+
+## Optional: Use Android App Links
+
+With App Links, in Android 6.0 (API level 23) and higher, Android allows an app to designate itself as the default handler of a given type of link, without asking the user whether to use the Browser or our app to open the link.
+Automatic handling of links requires the cooperation of our app and website (our Auth0 Authentication Server). The app must declare the association with the website and request that the system verify it. The website must, in turn, provide that verification by publishing a [Digital Asset Links](https://developers.google.com/digital-asset-links/) file.
+This feature works as long as the user has not already chosen a default app to handle that URI pattern in the Android settings.
+
+Auth0 will generate the [Digital Asset Links](https://developers.google.com/digital-asset-links/) file automatically for you after you've configured the **App Package Name** and **Key Hash** as shown before. If you've followed all the steps on this article, the only change you need to do is add an attribute to the **Intent-Filter** declaration in order to ask the OS to verify the link at install time. Go to the `AndroidManifest.xml` file where you have declared the Intent-Filter and add the `android:autoVerify="true"` attribute indicating use of an email connection:
+
+```xml
+
+   
+    
+    
+    
+    /email"
+      android:scheme="https" />
+
+```
+
+This attribute is used since Android API 23 (Android 6.0) to indicate that we would like to verify the link association. **This is extremely important to avoid the dialog asking the user which application to use.** Although links will work on all versions of Android, the dialog asking the user whether to use the Browser or our app to open the link will be displayed (whether the verification passed or not) in versions of Android prior to 6.0, at least until the user chooses to always open the links with our app.
+
+You could find more information about App Links in the [Android docs](http://developer.android.com/training/app-links/index.html).
diff --git a/ja-jp/articles/libraries/lock-android/v2/passwordless.md b/ja-jp/articles/libraries/lock-android/v2/passwordless.md
new file mode 100644
index 0000000000..c5bbd7d967
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/passwordless.md
@@ -0,0 +1,176 @@
+---
+section: libraries
+title: Lock Android v2 Passwordless
+description: Guide on implementing Passwordless authentication with Lock for Android
+topics:
+  - libraries
+  - lock
+  - android
+  - passwordless
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Passwordless
+
+Lock Passwordless authenticates users by sending them an Email or SMS with a one-time password that the user must enter and confirm to be able to log in, similar to how WhatsApp authenticates you. This article will explain how to send a **CODE** using the `Lock.Android` library.
+
+::: note
+You can achieve a similar result by sending a **LINK** that the user can click to finish the passwordless authentication automatically, but a few more configuration steps are involved. You can check that article [here](/libraries/lock-android/v2/passwordless-magic-link).
+:::
+
+In order to be able to authenticate the user, your application must have the Email/SMS connection enabled and configured in your [Auth0 Dashboard](${manage_url}/#/connections/passwordless).
+
+To use Passwordless Authentication with Lock, you need to use Lock Android v2.17 or greater, and it needs to be configured with [OIDC Conformant Mode](/libraries/lock-android#oidc-conformant-mode) set to `true`. 
+
+## Implementing CODE Passwordless
+
+In your `app/build.gradle` file add the [Manifest Placeholders](https://developer.android.com/studio/build/manifest-build-variables.html) for the Auth0 Domain and the Auth0 Scheme properties which are going to be used internally by the library to register an intent-filter that captures the callback URI.
+
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    compileSdkVersion 25
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 15
+        targetSdkVersion 25
+        //...
+
+        //---> Add the next line
+        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"]
+        //<---
+    }
+    //...
+}
+```
+
+It's a good practice to define reusable resources like `@string/com_auth0_domain` but you can also hard code the value to `${account.namespace}` in the file.
+
+Next, modify the `AndroidManifest.xml` file. Add the `android.permission.INTERNET` permission to allow Lock to make requests to the Auth0 API.
+
+```xml
+
+```
+
+Add the `PasswordlessLockActivity`. Depending on which passwordless connection you need to handle, the `data` attribute of the **intent-filter** will differ:
+
+```xml
+
+    
+        
+        
+        
+        /email"
+            android:scheme="https" />
+    
+
+```
+
+The `data` attribute of the intent-filter defines which syntax of "Callback URI" your app is going to capture. In the above case it's going to capture calls from `email` passwordless connections. In case you're using the `sms` passwordless connection, the `pathPrefix` would end in `sms`.
+
+::: note
+In versions 2.5.0 or lower of Lock.Android you had to define an **intent-filter** inside the `PasswordlessLockActivity` to make possible to the library to capture a **Social** provider's authentication result. This intent-filter declaration is no longer required for versions greater than 2.5.0 , as it's now done internally by the library for you.
+:::
+
+In case you are using an older version of Lock for Social Authentication, the **data** attribute that captures the "/callback" redirect URI inside the intent-filter must be added to the `PasswordlessLockActivity` by you.
+
+```xml
+
+    
+        
+        
+        
+
+        /email"
+            android:scheme="https" />
+
+        /callback"
+            android:scheme="demo" />
+    
+
+```
+
+Make sure the Activity's `launchMode` is declared as `singleTask` or the result won't come back in the authentication.
+
+When the Passwordless connection is SMS you must also add the `CountryCodeActivity` to allow the user to change the **Country Code** prefix of the phone number.
+
+```xml
+
+```
+
+## Usage
+
+In any of your activities, you need to initialize `PasswordlessLock` and tell it to send a **CODE**. We'll indicate this by calling the `useCode()` method.
+
+```java
+public class MainActivity extends Activity {
+
+  private PasswordlessLock lock;
+
+  protected void onCreate(Bundle savedInstanceState) {
+    super.onCreate(savedInstanceState);
+    // Your own Activity code
+    Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}");
+    auth0.setOIDCConformant(true);
+
+    lock = PasswordlessLock.newBuilder(auth0, callback)
+      .useCode()
+      .build(this);
+  }
+
+  @Override
+  protected void onDestroy() {
+    super.onDestroy();
+    // Your own Activity code
+    lock.onDestroy(this);
+    lock = null;
+  }
+
+  private LockCallback callback = new AuthenticationCallback() {
+     @Override
+     public void onAuthentication(Credentials credentials) {
+        //Authenticated
+     }
+
+     @Override
+     public void onCanceled() {
+        //User pressed back
+     }
+
+     @Override
+     public void onError(LockException error) {
+        //Exception occurred
+     }
+  };
+}
+```
+
+Finally, just start `PasswordlessLock` from inside your activity and perform the login.
+
+```java
+startActivity(lock.newIntent(this));
+```
+
+Depending on which passwordless connections are enabled, Lock will send the CODE in an Email or SMS. The 'email' connection is selected first if available. Then the user must input the CODE in the confirmation step. If the value equals to the one the server is expecting, the authentication will be successful.
diff --git a/ja-jp/articles/libraries/lock-android/v2/refresh-jwt-tokens.md b/ja-jp/articles/libraries/lock-android/v2/refresh-jwt-tokens.md
new file mode 100644
index 0000000000..3f039ce2c3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-android/v2/refresh-jwt-tokens.md
@@ -0,0 +1,70 @@
+---
+section: libraries
+title: Lock Android v2 Refreshing JWTs
+description: Keeping your user logged in
+topics:
+  - libraries
+  - lock
+  - android
+  - tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Android: Refreshing JWT Tokens
+
+<%= include('../../../_includes/_uses-delegation') %>
+
+When an authentication is performed with the `offline_access` scope included, the returned Credentials will contain a Refresh Token and an ID Token. Both tokens can be used to request a new Access Token and avoid asking the user their credentials again.
+
+We need to store the tokens in a secure storage after a successful authentication. Keep in mind that Refresh Tokens **never expire**. To request a new token you'll need to use `auth0.android`'s `AuthenticationAPIClient`. Don't forget to request the same scope used in the first login call.
+
+## Using Refresh Token
+
+```java
+String refreshToken = // Retrieve Refresh Token from secure storage
+Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
+auth0.setOIDCConformant(true);
+
+AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
+client.renewAuth(refreshToken)
+  .addParameter("scope", "openid email")
+  .start(new BaseCallback() {
+    @Override
+    public void onSuccess(Credentials credentials) {
+      //SUCCESS
+      String accessToken = credentials.getAccessToken();
+    }
+
+    @Override
+    public void onFailure(AuthenticationException error) {
+        //FAILURE
+    }
+});
+```
+
+## Using a non-expired ID Token
+
+```java
+String idToken = // Retrieve ID Token from the secure storage
+Auth0 account = new Auth0("${account.clientId}", "${account.namespace}");
+auth0.setOIDCConformant(true);
+
+AuthenticationAPIClient client = new AuthenticationAPIClient(auth0);
+client.delegationWithIdToken(idToken)
+  .setScope("openid email")
+  .start(new BaseCallback() {
+    @Override
+    public void onSuccess(Delegation delegation) {
+        //SUCCESS
+        String idToken = delegation.getIdtoken();
+    }
+
+    @Override
+    public void onFailure(AuthenticationException error) {
+        //FAILURE
+    }
+  });
+```
diff --git a/ja-jp/articles/libraries/lock-ios/_includes/_dependencies.md b/ja-jp/articles/libraries/lock-ios/_includes/_dependencies.md
new file mode 100644
index 0000000000..f0b8babdc6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/_includes/_dependencies.md
@@ -0,0 +1,47 @@
+## Install
+
+### Cocoapods
+
+If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`:
+
+```ruby
+pod 'Lock', '~> 2.0'
+```
+
+Then run `pod install`.
+
+::: note
+For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Carthage
+
+If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`:
+
+```ruby
+github "auth0/Lock.swift" ~> 2.0
+```
+
+Then run `carthage bootstrap`.
+
+::: note
+For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+:::
+
+### SPM
+
+If you are using the Swift Package Manager, open the following menu item in Xcode:
+
+**File > Swift Packages > Add Package Dependency...**
+
+In the **Choose Package Repository** prompt add this url: 
+
+```text
+https://github.com/auth0/Lock.swift.git
+```
+
+Then press **Next** and complete the remaining steps.
+
+::: note
+For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app).
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/_includes/_lock-version-1.md b/ja-jp/articles/libraries/lock-ios/_includes/_lock-version-1.md
new file mode 100644
index 0000000000..fb21b112e4
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/_includes/_lock-version-1.md
@@ -0,0 +1,3 @@
+::: version-warning
+This document covers an outdated version of Lock for iOS. We recommend that you upgrade to v2.
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/_includes/_lock-version.md b/ja-jp/articles/libraries/lock-ios/_includes/_lock-version.md
new file mode 100644
index 0000000000..2596ef64e6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/_includes/_lock-version.md
@@ -0,0 +1,3 @@
+::: note
+This document uses the latest version of Lock for iOS - version 2. We recommend using this version, but if you are already using version 1, you can access it using the dropdown at the top of this document.
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md b/ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/ja-jp/articles/libraries/lock-ios/index.yml b/ja-jp/articles/libraries/lock-ios/index.yml
new file mode 100644
index 0000000000..4e65cc67bb
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: libraries/lock-ios
+  current: v2
+  versions:
+    - v1
+    - v2
+  defaultArticles:
+    v1: index
+    v2: index
diff --git a/ja-jp/articles/libraries/lock-ios/v1/customization.md b/ja-jp/articles/libraries/lock-ios/v1/customization.md
new file mode 100644
index 0000000000..ed76e46250
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/customization.md
@@ -0,0 +1,111 @@
+---
+section: libraries
+title: Customization
+description: Learn how to customize the look and feel of Lock
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Customization
+
+<%= include('../_includes/_lock-version-1') %>
+
+Lock UI can be customized by creating your own `A0Theme` and overriding the default one before displaying `A0LockViewController`:
+
+```objc
+A0Theme *myAwesomeTheme = [[A0Theme alloc] init];
+//Customize your theme
+[[A0Theme sharedInstance] registerTheme:myAwesomeTheme];
+```
+```swift
+let myAwesomeTheme = A0Theme()
+//Customize your theme
+A0Theme.sharedInstance().register(myAwesomeTheme)
+```
+
+## How to configure your Theme
+
+**Lock**'s UI is composed of several parts that can be customized
+
+Here is a list of the available values that can be customized:
+
+![](/media/articles/libraries/lock-ios/customization/Lock-UI-Parts.png)
+
+You can either configure some type of properties which are:
+
+* Color: `UIColor` instance.
+* Image: `NSString` with image name.
+* Font: `UIFont` instance.
+
+Example Usage
+
+```
+myAwesomeTheme.registerColorForKey(UIColor.redColor(), "A0ThemePrimaryButtonNormalColor");
+```
+
+This is the list of properties that can be customized:
+
+### Primary Button
+
+* A0ThemePrimaryButtonNormalColor
+* A0ThemePrimaryButtonHighlightedColor
+* A0ThemePrimaryButtonNormalImageName
+* A0ThemePrimaryButtonHighlightedImageName
+* A0ThemePrimaryButtonFont
+* A0ThemePrimaryButtonTextColor
+
+### Secondary Button
+
+* A0ThemeSecondaryButtonBackgroundColor
+* A0ThemeSecondaryButtonNormalImageName
+* A0ThemeSecondaryButtonHighlightedImageName
+* A0ThemeSecondaryButtonFont
+* A0ThemeSecondaryButtonTextColor
+
+### TextField
+
+* A0ThemeTextFieldFont
+* A0ThemeTextFieldTextColor
+* A0ThemeTextFieldPlaceholderTextColor
+* A0ThemeTextFieldIconColor
+
+### Title
+
+* A0ThemeTitleFont
+* A0ThemeTitleTextColor
+
+### Icon
+
+* A0ThemeIconBackgroundColor
+* A0ThemeIconImageName
+
+### Background
+
+* A0ThemeScreenBackgroundColor
+* A0ThemeScreenBackgroundImageName
+
+### Message & Description
+
+* A0ThemeDescriptionFont
+* A0ThemeDescriptionTextColor
+* A0ThemeSeparatorTextFont
+* A0ThemeSeparatorTextColor
+
+### CredentialBox
+
+* A0ThemeCredentialBoxBorderColor
+* A0ThemeCredentialBoxSeparatorColor
+* A0ThemeCredentialBoxBackgroundColor
+
+### Close Button
+
+* A0ThemeCloseButtonTintColor
diff --git a/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md b/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md
new file mode 100644
index 0000000000..81be9f0cf1
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md
@@ -0,0 +1,70 @@
+---
+section: libraries
+title: Delegation API
+description: Integrate with third-party apps with the delegation API.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - delegation
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Delegation API
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/api/authentication/reference#delegation) using a valid JWT.
+
+Here's an example
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+NSString *token = ...; // Auth0's ID Token obtained on login
+A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{
+                                                                     @"id_token": token,
+                                                                     A0ParameterAPIType: @"firebase",
+                                                                     }];
+[[lock apiClient] fetchDelegationTokenWithParameters:parameters success:^(NSDictionary *delegationToken) {
+    // delegationToken will have your firebase token
+} failure:^(NSError *error) {
+    // Something went wrong
+}];
+```
+
+```swift
+let client = A0Lock.shared().apiClient()
+let token = // Auth0's ID Token obtained on login
+let parameters = A0AuthParameters.new(with: [
+    "id_token": token,
+    A0ParameterAPIType: "firebase"
+    ])
+client.fetchDelegationToken(with: parameters,
+    success: { payload in
+        // payload will have your firebase token
+    },
+    failure: { error in
+        // Something went wrong
+    })
+```
+
+The only two parameters required are `id_token` and the `api_type` (the value of `A0ParameterAPIType` constant).
+
+`api_type` specifies the API credentials we want to retrieve, and the API supported are:
+
+* app: Your Auth0 application. This will get a new JWT token.
+* aws: Amazon Web Services API.
+* azure_sb: Windows Azure Service Bus.
+* firebase: Firebase API.
+* salesforce_api: Salesforce API.
+* salesforce_sandbox_api: Salesforce Sandbox API.
+* sap_api: SAP OData.
+* wams: Windows Azure Mobile Services.
diff --git a/ja-jp/articles/libraries/lock-ios/v1/index.md b/ja-jp/articles/libraries/lock-ios/v1/index.md
new file mode 100644
index 0000000000..57b47e6a6c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/index.md
@@ -0,0 +1,430 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v1
+title: Lock v1 for iOS and macOS
+snippets:
+  dependencies: native-platforms/ios-objc/dependencies
+description: A widget that provides a frictionless login and signup experience for your native iOS and macOS apps.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - index
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v1 for iOS and macOS
+
+<%= include('../_includes/_lock-version-1') %>
+
+Auth0 is an authentication broker that supports social identity providers as well as enterprise identity providers such as Active Directory, LDAP, G Suite and Salesforce.
+
+## Key features
+
+* **Integrates** your iOS app with **Auth0** (OS X coming soon).
+* Provides a elegant **native UI** to log in your users.
+* Provides support for **Social Providers** (Facebook, Twitter, and so on), **Enterprise Providers** (AD, LDAP, and so on) and **Username & Password** authentication.
+* Provides the ability to do **Single Sign-on (SSO)** with 2 or more mobile apps, similar to Facebook and Messenger apps.
+* [1Password](https://agilebits.com/onepassword) integration using the **iOS 8** [Extension](https://github.com/AgileBits/onepassword-app-extension).
+
+::: note
+Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift/tree/v1) on GitHub.
+:::
+
+## Requirements
+
+iOS 7+. If you need to use our SDK with an earlier version, use the previous SDK pod `Auth0Client`, or see the [old-sdk](https://github.com/auth0/Lock.iOS-OSX/tree/old-sdk) branch of the Lock.iOS-OSX repo.
+
+## Installation
+
+Lock is available through [CocoaPods](http://cocoapods.org). To install it, simply add the following line to your Podfile:
+
+${snippet(meta.snippets.dependencies)}
+
+Then, in your project's `Info.plist` file, add the following string entries:
+
+* __Auth0ClientId__: The client ID of your Auth0 application.
+* __Auth0Domain__: Your Auth0 account domain.
+
+For example:
+![plist](/media/articles/libraries/lock-ios/plist.png)
+
+::: note
+You can find these values in your [Application Settings](${manage_url}/#/applications) in the Auth0 dashboard.
+:::
+
+You will also need to register a **Custom URL** type with a custom scheme in the following format:
+
+`a0{Your Client ID}`
+
+For example, if your Client ID is `Exe6ccNagokLH7mBmzFejP`, the custom scheme would be `a0Exe6ccNagokLH7mBmzFejP`.
+
+Before you can begin using Lock, you will need to import Lock into your codebase.
+
+If you are working in Objective-C, import this header when you need to use Lock's classes:
+
+```objc
+#import 
+```
+
+The same applies if you are working in Swift and Lock is included as a static library. In this case, the header must also be included in your _Objective-C Bridging Header_.
+
+::: note
+If you need help creating the Objective-C Bridging Header, see: [Swift and Objective-C in the Same Project](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html).
+:::
+
+If you are working in Swift with Lock included as an framework, just include the module in your Swift files like this:
+
+```swift
+import Lock
+```
+
+Now you can initialize `A0Lock` (which handles authentication) and keep it in your `AppDelegate` as a **strong** property.
+
+::: note
+You can store `A0Lock` in a different location as long as you keep it alive as long as it is needed.
+:::
+
+This examples creates `A0Lock` inside `-application:didFinishLaunchingWithOptions:`
+
+**Objective C**:
+
+```objc
+self.lock = [A0Lock newLock];
+```
+
+**Swift**:
+
+```swift
+self.lock = A0Lock()
+```
+
+Then call this method:
+
+**Objective C**:
+
+```objc
+[self.lock applicationLaunchedWithOptions:launchOptions];
+```
+
+**Swift**:
+
+```swift
+lock.applicationLaunched(options: launchOptions)
+```
+
+Lastly, you will need to handle the already registered custom scheme in your `AppDelegate`. To do so, override the `-application:openURL:options:` method and add the following line:
+
+**Objective C**:
+
+```objc
+- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url
+            options:(NSDictionary *)options {
+    return [self.lock handleURL:url sourceApplication:app];
+}
+```
+
+**Swift**:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+    return self.lock.handle(url, sourceApplication: app)
+}
+```
+
+This call is required to be able to return to your application when authenticating with Safari, or with native integration with Facebook or Twitter. This call checks the URL and handles those that have the custom scheme.
+
+## Usage
+
+### Email/password, enterprise, and social provider authentication
+
+`A0LockViewController` will handle email/password, enterprise, and social provider authentication based on the connections enabled on your application in the [Auth0 Dashboard](${manage_url}/#/connections/social).
+
+First, instantiate `A0LockViewController` and register the authentication callback that will receive the authenticated user's credentials. Then present it as a modal view controller:
+
+#### Objective C
+
+```objc
+A0Lock *lock = ... //Fetch Lock from where its stored
+A0LockViewController *controller = [lock newLockViewController];
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let lock = ... // Fetch Lock from where its stored
+let controller: A0LockViewController = lock.newLockViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.present(controller, from: self)
+```
+
+You will see the Lock native login screen:
+
+
    Lock-iOS
    
+
+::: note
+By default, all social authentication will be done using Safari. If you want native integration, see: [Lock iOS: Native Social Authentication](/libraries/lock-ios/native-social-authentication).
+:::
+
+### Close Lock UI
+
+You can add a **Close** button to Lock UI. For this to function, you will need to set the `closable` property to allow the `A0AuthenticationViewController` to be dismissed. The default value is `NO`.
+
+If you want to handle the closing event, you will need to add the `onUserDismissBlock` block which will be called when the user dismisses the Login screen only if the `closable` property is set to `YES`.
+
+#### Objective C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockViewController *controller = [lock newLockViewController];
+controller.closable = YES;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+
+controller.onUserDismissBlock = ^(){
+  NSLog(@"User closed Lock UI");
+};
+
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+controller.closable = true
+
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+
+controller.onUserDismissBlock = { _ in
+    print("User closed Lock UI")
+}
+
+self.present(controller, animated: true, completion: nil)
+```
+
+### Sign-up
+
+There are different approaches to implement Sign-up functionality:
+
+1. You can add or hide the **Sign Up** button in Lock UI by setting the `disableSignUp` property which will hide the **Sign Up** button when set to `YES`. The default value  is `NO`.
+
+2. Another approach is to use the `A0LockSignUpViewController` directly:
+
+#### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockSignUpViewController *controller = [lock newSignUpViewController];
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newSignUpViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+
+self.present(controller, animated: true, completion: nil)
+```
+
+
+3. A third option is to create your own sign up `viewController` to implement the sign-up logic with one of the `A0APIClient` methods:
+
+```
+- (NSURLSessionDataTask *)signUpWithEmail:(NSString *)email
+                                 username:(nullable NSString *)username
+                                 password:(NSString *)password
+                           loginOnSuccess:(BOOL)loginOnSuccess
+                               parameters:(nullable A0AuthParameters *)parameters
+                                  success:(A0APIClientSignUpSuccess)success
+                                  failure:(A0APIClientError)failure;
+```
+
+Your `viewController` should also implement the `A0LockEventDelegate` methods:
+
+```
+- (void)backToLock; - Dismisses all custom UIViewControllers pushed inside Lock and shows the main UI.
+- (void)dismissLock; - Dismisses A0LockViewController, like clicking the Close button if `closable` is true
+- (void)userAuthenticatedWithToken:(A0Token *)token profile:(A0UserProfile *)profile; - Calls `onAuthenticationBlock` of `A0LockViewController` with token and profile
+```
+
+After implementing your `viewController`, you will need to return it in a `customSignUp` block of `A0LockViewController`. The default value for this block is `nil`.
+
+**Objective-C**:
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+
+A0LockViewController *controller = [lock newLockViewController];
+controller.closable = YES;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+
+//Create custom SignUp view controller
+controller.customSignUp = ^ UIViewController *(A0Lock *lock, A0LockEventDelegate *delegate) {
+
+  YourCustomSignUpVC *signUpVC = …//your viewController;
+  signUpVC.delegate = delegate;
+  signUpVC.lock = lock;
+
+  return signUpVC;
+};
+
+UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller];
+
+if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
+  navController.modalPresentationStyle = UIModalPresentationFormSheet;
+}
+
+[self presentViewController:navController animated:YES completion:nil];
+```
+
+**Swift**:
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+
+controller.onAuthenticationBlock = { (profile, token) in
+    self.dismiss(animated: true, completion: nil)
+}
+
+// Create custom SignUp view controller
+controller.customSignUp = { (lock, delegate) in
+    let YourCustomSignUpVC = // Your viewController;
+    signUpVC.lock = lock
+    signUpVC.delegate = delegate
+
+    return signUpVC
+}
+
+let navController:UINavigationController = UINavigationController.init(rootViewController: controller)
+
+if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiom.pad) {
+    navController.modalPresentationStyle = UIModalPresentationStyle.formSheet
+
+}
+self.present(navController, animated: true, completion: nil)
+```
+
+### Automatic login after sign-up
+
+After a successful sign-up, the user can be logged in automatically using the `loginAfterSignUp` property. If `loginAfterSignUp` is set to `YES`, `A0AuthenticationViewController` will attempt to log in the user . Otherwise, it will call `onAuthenticationBlock` with both parameters set to `nil`. The default value of `loginAfterSignUp` is `YES`.
+
+### Disclaimer View
+
+If you want to show a disclaimer for your app, you will need to set `signUpDisclaimerView`. This view will appear at the bottom of the sign-up screen.
+
+## Logout
+
+To log out a user, call `clearSessions` for `A0Lock`. This method removes all stored sessions of any IdP in your application.
+
+:::note
+* If the user has logged in using Safari, their sessions will not be cleared.
+* If you stored the credentials in the keychain, you need to clear them there as well.
+:::
+
+### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+[lock clearSessions];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:];
+[keychain clearAll];
+//redirect the user to Login Page
+```
+
+### Swift
+
+```swift
+A0Lock.shared().clearSessions()
+let keychain = A0SimpleKeychain(service: )
+keychain.clearAll()
+//redirect the user to Login Page
+```
+
+## WebView
+
+When authenticating with a social connection, you can choose between using Safari or the embedded webView. To use embedded webView, set the `useWebView` property to `YES`. The default value is `YES`.
+
+### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockViewController *controller = [lock newLockViewController];
+controller.useWebView = NO;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+controller.onUserDismissBlock = ^(){
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+controller.useWebView = false
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+self.present(controller, animated: true, completion: nil)
+```
+
+## Additional Information
+
+See the [Swift](https://github.com/auth0-samples/auth0-ios-swift-sample) and [Objective-C](https://github.com/auth0-samples/auth0-ios-objc-sample) example apps.
+
+For more information on how to use Lock with Swift, see: [Lock iOS: Using Swift](/libraries/lock-ios/swift).
+
+For more information on Lock for CocoaPods, see the [Lock documentation in CocoaDocs](http://cocoadocs.org/docsets/Lock).
+
+## Further reading
+
+::: next-steps
+- [Customization of the Look and Feel of Lock iOS](/libraries/lock-ios/v1/customization)
+- [Lock iOS API](/libraries/lock-ios/v1/lock-ios-api)
+- [Native Social Authentication](/libraries/lock-ios/v1/native-social-authentication)
+- [Passwordless](/libraries/lock-ios/v1/passwordless)
+- [Sending Authentication Parameters](/libraries/lock-ios/v1/sending-authentication-parameters)
+- [Using Swift with Lock iOS v1](/libraries/lock-ios/v1/swift)
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md b/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md
new file mode 100644
index 0000000000..660eb5dbe3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md
@@ -0,0 +1,245 @@
+---
+section: libraries
+title: Lock Objective-C API
+description: Description of the Lock Objective-C API
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - objective-c
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock Objective-C API
+
+<%= include('../_includes/_lock-version-1') %>
+
+## A0Lock
+
+### A0Lock#newLock
+
+```objc
++ (instancetype)newLock;
+```
+
+Creates a new `A0Lock` instance using account information from Info.plist file.
+
+```objc
+A0Lock *lock = [A0Lock newLock];
+```
+
+#### A0Lock#newLockWithClientId:domain:
+
+```objc
++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain;
+```
+
+Creates a new `A0Lock` instance with Auth0 clientId and domain.
+
+```objc
+A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN"];
+```
+
+#### A0Lock#newLockWithClientId:domain:configurationDomain:
+
+```objc
++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain configurationDomain:(NSString *)configurationDomain;
+```
+
+Creates a new `A0Lock` instance with Auth0 clientId, domain and configurationDomain.
+
+```objc
+A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN" configurationDomain:@"YOUR_CONFIG_DOMAIN"];
+```
+
+#### A0Lock#apiClient
+
+```objc
+- (A0APIClient *)apiClient;
+```
+
+Returns an instance of the API application for Authentication API configured for your application.
+
+```objc
+A0APIClient *client = [lock apiClient];
+```
+
+#### A0Lock#newUserAPIClientWithIdToken
+
+```objc
+- (A0UserAPIClient *)newUserAPIClientWithIdToken:(NSString *)idToken;
+```
+
+Returns a new instance of the API client for Auth0 API with the credentials of a authenticated user obtained from the **ID Token**
+
+```objc
+A0UserAPIClient *client = [lock newUserAPIClientWithIdToken:@"AN ID TOKEN"];
+```
+
+#### A0Lock#handleURL:sourceApplication:
+
+```objc
+- (BOOL)handleURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication;
+```
+
+Handle URL received from AppDelegate when application is called from a third party at the end of an authentication flow.
+
+```objc
+[lock handleURL:URL sourceApplication:sourceApplication];
+```
+
+#### A0Lock#registerAuthenticators
+
+```objc
+- (void)registerAuthenticators:(NSArray *)authenticators;
+```
+
+Register IdP authenticators that will be used for Social & Enterprise connections. By default all Social & Enterprise authentications are performed by using the web flow with Safari but you can plug your own authenticator for a connection (for example, you can register `A0FacebookAuthenticator` in order to login with FB native SDK).
+
+```objc
+[lock registerAuthenticators:@[facebook, twitter]];
+```
+
+#### A0Lock#applicationLaunchedWithOptions
+
+```objc
+- (void)applicationLaunchedWithOptions:(NSDictionary *)launchOptions;
+```
+
+Handle application launched event.
+
+```objc
+[lock applicationLaunchedWithOptions:launchOptions];
+```
+
+#### A0Lock#clearSessions
+
+```objc
+- (void)clearSessions;
+```
+
+Remove all stored sessions of any IdP in your application. If the user logged in using Safari, those sessions will not be cleaned.
+
+```objc
+[lock clearSessions];
+```
+
+### A0LockViewController
+
+#### A0LockViewController#init
+
+```objc
+- (instancetype)initWithLock:(A0Lock *)lock;
+```
+
+Initialise 'A0LockViewController' using a `A0Lock` instance.
+
+```objc
+A0LockViewController *controller = [[A0LockViewController alloc] initWithLock:lock];
+```
+
+#### A0LockViewController#onAuthenticationBlock
+
+```objc
+@property (copy, nonatomic) void(^onAuthenticationBlock)(A0UserProfile *profile, A0Token *token);
+```
+
+Block that is called on successful authentication. It has two parameters profile and token, which will be non-nil unless login is disabled after signup.
+
+```objc
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  NSLog(@"Auth successful: profile %@, token %@", profile, token);
+};
+```
+
+#### A0LockViewController#onUserDismissBlock
+
+```objc
+@property (copy, nonatomic) void(^onUserDismissBlock)();
+```
+
+Block that is called on when the user dismisses the Login screen. Only when `closable` property is `YES`.
+
+```objc
+controller.onUserDismissBlock = ^() {
+  NSLog(@"User dismissed login screen.");
+};
+```
+
+#### A0LockViewController#usesEmail
+
+```objc
+@property (assign, nonatomic) BOOL usesEmail;
+```
+
+Enable the username to be treated as an email (and validated as one too) in all Auth0 screens. Default is `YES`
+
+```objc
+controller.usesEmail = NO;
+```
+
+#### A0LockViewController#closable
+
+```objc
+@property (assign, nonatomic) BOOL closable;
+```
+
+Allows the `A0LockViewController` to be dismissed by adding a button. Default is `NO`
+
+```objc
+controller.closable = YES;
+```
+
+#### A0LockViewController#loginAfterSignup
+
+```objc
+@property (assign, nonatomic) BOOL loginAfterSignUp;
+```
+
+After a successful Signup, `A0LockViewController` will attempt to login the user if this property is `YES` otherwise will call `onAuthenticationBlock` with both parameters nil. Default value is `YES`
+
+```objc
+controller.loginAfterSignup = NO;
+```
+
+#### A0LockViewController#authenticationParameters
+
+```objc
+@property (assign, nonatomic) A0AuthParameters *authenticationParameters;
+```
+
+List of optional parameters that will be used for every authentication request with Auth0 API. By default it only has  'openid' and 'offline_access' scope values. For more information check out our [Wiki](/libraries/lock-ios/sending-authentication-parameters)
+
+```objc
+controller.authenticationParameters.scopes = @[A0ScopeOfflineAccess, A0ScopeProfile];
+```
+
+### A0LockViewController#signupDisclaimerView
+
+```objc
+@property (strong, nonatomic) UIView *signUpDisclaimerView;
+```
+
+View that will appear in the bottom of Signup screen. It should be used to show Terms & Conditions of your app.
+
+```objc
+UIView *view = //..
+controller.signupDisclaimerView = view;
+```
+
+#### A0LockViewController#useWebView
+
+```objc
+@property (assign, nonatomic) BOOL useWebView;
+```
+
+When the authentication requires to open a web login, for example Linkedin, it will use an embedded UIWebView instead of Safari if it's `YES`. We recommend using Safari for Authentication since it will always save the User session. This means that if the user is already signed in, for example in Linkedin, and they click on the Linkedin button, it will just work. Default values is `NO`
+
+```objc
+controller.useWebView = YES
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/logging.md b/ja-jp/articles/libraries/lock-ios/v1/logging.md
new file mode 100644
index 0000000000..f33ff75ea7
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/logging.md
@@ -0,0 +1,72 @@
+---
+section: libraries
+title: Logging
+description: Learn how to debug Lock by enabling logging.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Logging
+
+<%= include('../_includes/_lock-version-1') %>
+
+Lock logs several pieces of useful debugging information using [CocoaLumberjack](https://github.com/CocoaLumberjack/CocoaLumberjack).
+
+
+::: note
+If you are using a Lock version older than `1.10.0` please check [here](#lock-versions-1-10-0)
+:::
+
+By default all log messages are disabled but you can enable them in your `AppDelegate.m` (or `AppDelegate.swift`), for example if you want __Lock__'s error messages just add this line:
+
+```objc
+[A0LockLogger logError];
+```
+```swift
+A0LockLogger.logError()
+```
+
+Or if you want to all debug messages:
+
+```objc
+[A0LockLogger logAll];
+```
+```swift
+A0LockLogger.logAll()
+```
+
+::: note
+If you are already using `CocoaLumberjack`, you need to enable __Lock__'s log after you register CocoaLumberjack's loggers.
+:::
+
+## Lock versions < 1.10.0
+Go to `A0Logging.h` and change the `auth0LogLevel` variable with the Log Level you'll want to see. for example:
+```objc
+static const int auth0LogLevel = LOG_LEVEL_ALL;
+```
+
+And then you'll need to configure CocoaLumberjack (if you haven't done it for your app). You need to do it once so we recommend doing it in your `AppDelegate`:
+
+```objc
+#import 
+#import 
+#import 
+
+@implementation A0AppDelegate
+
+- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
+    [DDLog addLogger:[DDASLLogger sharedInstance]];
+    [DDLog addLogger:[DDTTYLogger sharedInstance]];
+    return YES;
+}
+
+@end
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md b/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md
new file mode 100644
index 0000000000..56a08f5617
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md
@@ -0,0 +1,97 @@
+---
+section: libraries
+title: Native Social Authentication
+description: How to enable native login for some the supported social social connections.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - native
+  - social-connections
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Native Social Authentication
+
+<%= include('../_includes/_lock-version-1') %>
+
+::: warning
+This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature.
+We recommend using browser-based flows, as explained in [Web-based auth](/libraries/auth0-swift#web-based-auth-ios-only-).
+:::
+
+**Lock** by default handles all social authentication with Safari (Web Login), but you can enable native login for some social connections. Currently we only provide integration with Facebook, Google & Twitter that can be included like this in your `Podfile`
+```ruby
+pod 'Lock-Facebook'
+pod 'Lock-Twitter'
+pod 'Lock-Google'
+```
+
+::: note
+We recommend to at least fix the major version instead of always obtaining the latest version, e.g `pod 'Lock-Facebook', '~> 2.0`
+:::
+
+## Configuration
+
+::: note
+Before following these steps, please check our [documentation](/libraries/lock-ios)
+:::
+
+### Facebook
+
+Lock uses Facebook iOS SDK to obtain user's Access Token so you'll need to configure it using your Facebook App info:
+
+First, add the following entries to the `Info.plist`:
+* _FacebookAppID_: `YOUR_FACEBOOK_APP_ID`
+* _FacebookDisplayName_: `YOUR_FACEBOOK_DISPLAY_NAME`
+
+Then register a custom URL Type with the format `fb`. For more information please check [Facebook Getting Started Guide](https://developers.facebook.com/docs/ios/getting-started).
+
+Here's an example of how the entries should look like in your `Info.plist` file:
+
+![FB plist](/media/articles/libraries/lock-ios/fb-plist.png)
+
+Finally, you need to register `A0FacebookAuthenticator` with your instance of `A0Lock`:
+
+```objc
+A0Lock *lock = ...//Get your Lock instance
+A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticationWithDefaultPermissions];
+[lock registerAuthenticators:@[facebook]];
+```
+
+### Twitter
+
+Twitter authentication is done using [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth) in order to obtain a valid Access Token that can be sent to Auth0 Server and validate the user. By default we use iOS Twitter Integration but we support OAuth Web Flow (with Safari) as a fallback mechanism in case a user has no accounts configured in his/her Apple Device.
+
+To support Twitter authentication you need to register `A0TwitterAuthenticator` with your instance of `A0Lock`:
+
+```objc
+A0Lock *lock = ...//Get your Lock instance
+NSString *twitterApiKey = ... //Remember to obfuscate your api key
+NSString *twitterApiSecret = ... //Remember to obfuscate your api secret
+A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticatorWithKey:twitterApiKey                                                                            andSecret:twitterApiSecret];
+[lock registerAuthenticators:@[twitter]];
+```
+
+We need your twitter app's key & secret in order to sign the reverse auth request. For more info please read the Twitter documentation related to [Authorizing Requests](https://dev.twitter.com/docs/auth/authorizing-request) and [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth).
+
+### Google
+
+Google authentication uses [Google Sign-In](https://developers.google.com/identity/sign-in/ios/) iOS library, so you'll need to register your iOS application in [Google Developer Console](https://console.developers.google.com/project) and get your clientId.
+
+We recommend following [this wizard](https://developers.google.com/mobile/add?platform=ios) instead and download the file `GoogleServices-Info.plist` that is generated at the end.
+
+Then add that file to your application's target and the last step is to register two custom URL for your application.
+
+The first URL should have a scheme equal to your application Bundle Identifier, the other one should be your Google clientId reversed, so if your clientID is `CLIENTID.apps.googleusercontent.com` the scheme will be `com.googleusercontent.apps.CLIENTID`.
+
+::: note
+This last value can be found in `GoogleServices-Info.plist` under the key `REVERSED_CLIENT_ID`. For more information please check Google's [documentation](https://developers.google.com/identity/sign-in/ios/).
+:::
+
+And finally with your Mobile clientID from Google, go to [Social Connections](${manage_url}/#/connections/social), select **Google** and add the clientID to the field named `Allowed Mobile Client IDs`
diff --git a/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md b/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md
new file mode 100644
index 0000000000..9d7462f62f
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md
@@ -0,0 +1,66 @@
+---
+section: libraries
+title: Password Reset
+description: All you need to know about password reset with Lock for iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwords
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock iOS: Password Reset
+
+<%= include('../_includes/_lock-version-1') %>
+
+You can allow the user to reset their password for any database connections.
+
+If you use Lock UI, you can hide or show a **Reset password** button by setting the `disableResetPassword` property, which will default to `false`.
+
+If you implement a custom UI, you need to send a password reset email to the user using `A0APIClient`.
+
+::: note
+Please see [Password Strength in Auth0 Database Connections](/connections/database/password-strength) before implementing password reset.
+:::
+
+## Important considerations
+
+Passwords can only be changed for users signing in using database connections. If a user is signing in with a social or enterprise connection, their password would need to be reset in those platforms.
+
+## Example: Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0APIClient *client = [lock apiClient];
+A0AuthParameters *params = [A0AuthParameters newDefaultParams];
+params[A0ParameterConnection] = @"Username-Password-Authentication";
+                                // Or your configured DB connection
+
+[client requestChangePasswordForUsername:
+                              parameters:params
+                                 success:^{
+                                     NSLog(@"Please check your email!");
+                                 } failure:^(NSError * _Nonnull error) {
+                                     NSLog(@"Oops something went wrong: %@", error);
+                                 }];
+```
+
+## Example: Swift
+
+```swift
+let client = A0Lock.shared().apiClient()
+let params = A0AuthParameters.newDefaultParams();
+params[A0ParameterConnection] = "Username-Password-Authentication";
+// Or your configured DB connection
+client.requestChangePassword(forUsername: "", parameters: params,
+success: { _ in
+    print("Please check your email!")
+}, failure: { error in
+    print("Oops something went wrong: \(error)")
+})
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/passwordless.md b/ja-jp/articles/libraries/lock-ios/v1/passwordless.md
new file mode 100644
index 0000000000..6296f23b3c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/passwordless.md
@@ -0,0 +1,119 @@
+---
+section: libraries
+title: Passwordless in Lock iOS v1
+description: How to implement Passwordless authentication in Lock v1
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwordless
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Passwordless in Lock iOS v1
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_native_passwordless_warning') %>
+
+## Passwordless with SMS
+
+`A0SMSLockViewController` authenticates without using a password with SMS. In order to be able to authenticate the user, your application must have the SMS connection enabled and configured in your [dashboard](${manage_url}/#/connections/passwordless).
+
+First instantiate `A0SMSLockViewController` and register the authentication callback that will receive the authenticated user's credentials.
+
+The next step is register a block to return an API Token used to register the  phone number and send the login code with SMS. This token can be generated in  [Auth0 API v2 page](/api/v2), just select the scope `create:users` and copy the generated API Token.
+
+Finally present it to the user:
+```objc
+A0Lock *lock = ... //Fetch Lock from where its stored
+A0SMSLockViewController *controller = [lock newSMSViewController];
+controller.auth0APIToken = ^{
+    return @"Copy API v2 token here";
+};
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+[lock presentSMSController:controller fromController:self];
+```
+
+```swift
+let lock = ... // Fetch Lock from where its stored
+let controller: A0SMSLockViewController = lock.newSMSViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+   // Do something with token & profile (such as save them).
+   // Lock will not save the Token and the profile for you.
+   // And dismiss the UIViewController.
+   self.dismiss(animated: true, completion: nil)
+}
+lock.presentSMSController(controller, from: self)
+```
+And you'll see SMS login screen
+
+![Lock SMS Screenshot](/media/articles/libraries/lock-ios/Lock-SMS-Screenshot.png)
+
+## Passwordless with Touch ID
+
+Lock provides passwordless authentication with Touch ID for your Auth0 DB connection. To start authenticating your users with Touch ID please follow those steps:
+
+1. Add `TouchID` subspec module of **Lock** to your `Podfile`
+  ```ruby
+  pod 'Lock/TouchID'
+  ```
+
+1. Import **Lock**'s umbrella header
+  ```objc
+  #import 
+  ```
+  ::: note
+  If your are coding in Swift, you need to import the header in your app's [Bridging Header](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html).
+  :::
+
+1. Instantiate `A0TouchIDLockViewController` and register authentication callback
+  ```objc
+  A0TouchIDLockViewController *controller = [[A0TouchIDLockViewController alloc] init];
+  controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+      //Store token & profile. For example in the keychain using SimpleKeychain.
+      [self dismissViewControllerAnimated:YES completion:nil];
+  };
+  ```
+  ```swift
+  let lock = A0Lock.shared()
+  let controller: A0TouchIDLockViewController = lock.newTouchIDViewController()
+  controller.onAuthenticationBlock = { (profile, token) in
+      // Do something with token & profile (such as save them).
+      // Lock will not save the Token and the profile for you.
+      // And dismiss the UIViewController.
+      self.dismiss(animated: true, completion: nil)
+  }
+  ```
+
+1. Present `A0TouchIDLockViewController` as the root controller of a `UINavigationController`
+  ```objc
+  UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller];
+  if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
+      navController.modalPresentationStyle = UIModalPresentationFormSheet;
+  }
+  [self presentViewController:navController animated:YES completion:nil];
+  ```
+  ```swift
+  let navController = UINavigationController(rootViewController: controller)
+  if UIDevice.current.userInterfaceIdiom == .pad {
+      navController.modalPresentationStyle = .FormSheet
+  }
+  self.presentViewController(navController, animated: true, completion:nil)
+  ```
+  ::: note
+  It's mandatory to present `A0TouchIDLockViewController` embedded in a `UINavigationController`.
+  :::
+
+And you'll see TouchID login screen.
+
+![Lock Screenshot](/media/articles/libraries/lock-ios/Lock-TouchID-Screenshot.png)
diff --git a/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md b/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md
new file mode 100644
index 0000000000..69be180f58
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md
@@ -0,0 +1,146 @@
+---
+section: libraries
+title: Saving and Refreshing JWT Tokens
+description: Keeping your user logged in
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Saving and Refreshing JWT Tokens
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_uses-delegation') %>
+
+When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new JWT token and avoid asking the user his/her
+credentials again.
+
+::: note
+We are using [SimpleKeychain](https://github.com/auth0/SimpleKeychain) to handle iOS Keychain access.
+:::
+
+First thing we need to do is store the ID Token and Refresh Token in the iOS Keychain after a successful authentication.
+
+```objc
+A0LockViewController *controller = ...;
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+    [keychain setString:token.idToken forKey:@"id_token"];
+    [keychain setString:token.refreshToken forKey:@"refresh_token"];
+    [keychain setData:[NSKeyedArchiver archivedDataWithRootObject:profile] forKey:@"profile"];
+    // Other stuff. Don't forget to dismiss lock
+};
+```
+
+```swift
+let controller: A0LockViewController = ...
+controller.onAuthenticationBlock = { (profile, token) in
+    guard let profile = profile, let token = token else {
+        return //it's a sign up
+    }
+    let keychain = A0SimpleKeychain(service: "Auth0")
+    keychain.setString(token.idToken, forKey: "id_token")
+    if let refreshToken = token.refreshToken {
+        keychain.setString(refreshToken, forKey: "refresh_token")
+    }
+    keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile")
+    // Other stuff. Don't forget to dismiss lock
+}
+```
+Once you have those stored, you can at any point request a new ID Token using either of by calling to Auth0`s **delegation** endpoint.
+
+## Using a non-expired ID Token
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+NSString* token = [keychain stringForKey:@"id_token"];
+A0APIClient *client = [lock apiClient];
+[client fetchNewIdTokenWithIdToken:token parameters:nil success:^(A0Token *token) {
+    [keychain setString:token.idToken forKey:@"id_token"];
+    //Just got a new ID Token!
+} failure:^(NSError *error) {
+    [keychain clearAll]; //Cleaning stored values since they are no longer valid
+    //ID Token is no longer valid.
+    //You should ask the user to login again!.
+}];
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let token = keychain.stringForKey("id_token") {
+    let client = A0Lock.sharedLock().apiClient()
+    client.fetchNewIdTokenWithIdToken(token,
+        parameters: nil,
+        success: { token in
+            keychain.setString(token.idToken, forKey: "id_token")
+            //Just got a new ID Token!
+        }, failure: { error in
+            keychain.clearAll() //Cleaning stored values since they are no longer valid
+            //ID Token is no longer valid.
+            //You should ask the user to login again!.
+    })
+}
+```
+
+## Using Refresh Token
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+NSString* refreshToken = [keychain stringForKey:@"refresh_token"];
+A0APIClient *client = [lock apiClient];
+[client fetchNewIdTokenWithRefreshToken:refreshToken parameters:nil success:^(A0Token *token) {
+    [keychain setString:token.idToken forKey:@"id_token"];
+    //Just got a new ID Token!
+} failure:^(NSError *error) {
+    [keychain clearAll]; //Cleaning stored values since they are no longer valid
+    //Refresh Token is no longer valid.
+    //You should ask the user to login again!.
+}];
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let token = keychain.stringForKey("refresh_token") {
+    let client = A0Lock.sharedLock().apiClient()
+    client.fetchNewIdTokenWithRefreshToken(token,
+        parameters: nil,
+        success: { token in
+            keychain.setString(token.idToken, forKey: "id_token")
+            //Just got a new ID Token!
+        }, failure: { error in
+            keychain.clearAll() //Cleaning stored values since they are no longer valid
+            //Refresh Token is no longer valid.
+            //You should ask the user to login again!.
+    })
+}
+```
+
+## Retrieving the user profile from Keychain
+
+If you need to show profile information in your application, just retrieve the saved profile and pick what you need. For example:
+
+```objc
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+A0UserProfile *profile = [NSKeyedUnarchiver unarchiveObjectWithData:[keychain dataForKey:@"profile"]];
+self.nameLabel.text = profile.name;
+self.emailLabel.text = profile.email;
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let data = keychain.dataForKey("profile"), let profile = NSKeyedUnarchiver.unarchiveObjectWithData(data) {
+  self.nameLabel.text = profile.name
+  self.emailLabel.text = profile.email
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md b/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md
new file mode 100644
index 0000000000..325e52750d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md
@@ -0,0 +1,89 @@
+---
+section: libraries
+title: Sending Authentication Parameters
+description: How to send authentication parameters, and what parameters are supported when using Lock iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Sending Authentication Parameters
+
+<%= include('../_includes/_lock-version-1') %>
+
+You can send parameters, before displaying `A0AuthenticationViewController` or when calling any API method using `A0APIClient`, by adding them to a `A0AuthParameters` object. By default `A0AuthParameters` has the parameter `scope` with `openid offline_access` and `device` with the name obtained from calling
+```objc
+[[UIDevice currentDevice] name];
+```
+The following example adds a `scope` parameter with the value `login`.
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+parameters.scope = @"login";
+```
+
+The following parameters are supported:
+* `access_token`
+* `scope`
+* `protocol`
+* `device`
+* `connection_scopes`
+* `nonce`
+* `offline_mode`
+* `state`.
+
+There are other extra parameters that will depend on the provider. For example, Google allows you to get back a `refresh_token` only if you explicitly ask for `access_type=offline`.
+
+We support sending arbitrary parameters like this:
+
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+[parameters setValue:@"offline" forKey:@"access_type"];
+[parameters setValue:@"foo" forKey:@"my_arbitrary_param"];
+```
+
+## Supported parameters
+### scope:`NSString`
+
+There are different values supported for scope:
+
+* `'openid'`: It will return, not only the Access Token, but also an ID Token, which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim). You can use objc constant `A0ScopeOpenId`.
+* `'openid profile'`:(not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (for example, when using response_type=token) and will likely create an unnecessarily large token(especially with Azure AD which returns a fairly long JWT). Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. You can use objc constant `A0ScopeProfile`.
+* `'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the ID Token (for example: `scope: 'openid name email picture'`).
+
+Also, when you need to keep the ID Token alive, you can request a Refresh Token adding to the scope the value `offline_access` (Or use the constant `A0ScopeOfflineAccess`).
+
+By default in Auth0.iOS, the scope is set to `openid offline_access`.
+
+### device:`NSString`
+
+This value is only required when one of the scopes is `offline_access`. By default it has the name of the device obtained from calling the following method:
+
+```objc
+[[UIDevice currentDevice] name];
+```
+
+### connection_scopes:`NSDictionary`
+
+The `connection_scopes` parameter allows for dynamically specifying scopes on any connection. This is useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request the user for extra permissions or attributes.
+
+The object keys must be the names of the connections and the values must be arrays containing the scopes to request to append to the dashboard specified scopes. An example is shown below:
+
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+parameter.connectionScopes = @{
+  @"facebook": [@"public_profile", @"user_friends"],
+  @"google-oauth2": [@"https://www.googleapis.com/auth/orkut"],
+  // none for twitter
+};
+```
+
+::: note
+The values for each scope are not transformed in any way. They must match exactly the values recognized by each identity provider.
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v1/swift.md b/ja-jp/articles/libraries/lock-ios/v1/swift.md
new file mode 100644
index 0000000000..de468cce8c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/swift.md
@@ -0,0 +1,58 @@
+---
+section: libraries
+title: Using Lock with Swift
+description: How to use Swift with Lock iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - swift
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Using Swift
+
+<%= include('../_includes/_lock-version-1') %>
+
+**Lock** was written in Objective-C but it can be used from a pure Swift project or a Hybrid project (Swift & Objective-C).
+
+## Create Objective-C Bridging Header
+In order to use **Lock** classes in any Swift file, you need to add a Objective-C Bridging Header to your project. The easiest way is to create a dummy Objective-C file in your Swift project (or Swift file in a Objective-C project), this will make Xcode prompt to create the bridging header, just press _"YES"_. After that you can delete the dummy file from your project and open the bridging header file which is called `-Bridging-Header.h`.
+
+::: note
+For more information, please check [this guide](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html) from Apple.
+:::
+
+## Use Lock
+In `-Bridging-Header.h` just add the following line
+```objc
+#import 
+```
+
+And **Lock** classes will be available in all your Swift codebase. So to show `A0LockViewController` just use the following snippet:
+
+```swift
+let authController: A0LockViewController = A0Lock.shared().newLockViewController()
+authController.onAuthenticationBlock = { (profile, token) in
+    guard let profile = profile, let token = token else {
+        return //it's a sign up
+    }
+
+    let keychain = A0SimpleKeychain(service: "Auth0")
+    keychain.setString(token.idToken, forKey: "id_token")
+    if let refreshToken = token.refreshToken {
+        keychain.setString(refreshToken, forKey: "refresh_token")
+    }
+    keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile")
+
+    // Other stuff
+
+    self.dismiss(animated: true, completion: nil)
+}
+self.present(authController, animated: true, completion: nil)
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md b/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md
new file mode 100644
index 0000000000..e7cd769663
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md
@@ -0,0 +1,163 @@
+---
+section: libraries
+title: Build your own UI
+description: Customize the UI of Lock in your App
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - custom-ui
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Build your own UI
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_package', {
+  org: 'auth0',
+  repo: 'native-mobile-samples',
+  path: 'iOS/custom-ui-sample-swift'
+}) %>
+
+**Otherwise, if you already have an existing application, please follow the steps below.**
+
+1.  Add the following dependencies to your project using Cocoapods:
+  ```ruby
+  pod "Lock/Core", "~> 1.16"
+  pod "Lock-Facebook", "~> 2.0" #If you need FB native integration
+  pod "Lock-Twitter", "~> 1.1" #If you need Twitter native integration
+  ```
+
+2. Open your app's `Info.plist` file and add two new entries `Auth0ClientId` and `Auth0Domain` with the following values `${account.clientId}` and `${account.namespace}`
+
+3. Create a new instantiate of `A0Lock` and store it where is easily accessible:
+  ```objc
+  self.lock = [A0Lock newLock];
+  ```
+  ```swift
+  self.lock = A0Lock()
+  ```
+
+4. When you need to login your user with email/password credentials, just paste the following code
+  ```objc
+  NSString *email = ... // User's email
+  NSString *password = ... // User's password
+  A0Lock *lock = ... // Get your Lock instance
+  A0APIClient *client = [lock apiClient];
+  A0APIClientAuthenticationSuccess success = ^(A0UserProfile *profile, A0Token *token) {
+    NSLog(@"We did it!. Logged in with Auth0.");
+  };
+  A0APIClientError failure = ^(NSError *error){
+    NSLog(@"Oops something went wrong: %@", error);
+  };
+  A0AuthParameters *params = [A0AuthParameters newDefaultParams];
+  params[A0ParameterConnection] = @"Username-Password-Authentication"; // Or your configured DB connection
+  [client loginWithUsername:email
+                   password:password
+                 parameters:params
+                    success:success
+                    failure:error];
+  ```
+
+  ```swift
+  let email = ... // User's email
+  let password = ... // User's password
+  let lock = ... // Get your Lock instance
+  let client = lock.apiClient()
+  let parameters = A0AuthParameters(dictionary: [A0ParameterConnection : "Username-Password-Authentication"])
+  client.login(withUsername: email, password: password, parameters: parameters, success: { profile, token in
+      print("We did it!. Logged in with Auth0.")
+  }, failure: { error in
+      print("Oops something went wrong: \(error)")
+  })
+  ```
+::: note
+More details about the parameters you can use check [this wiki page](/libraries/lock-ios/sending-authentication-parameters).
+:::
+
+After that, you may want to save the user's token to be able to use them later, you can find how to do it [here](/libraries/lock-ios/save-and-refresh-jwt-tokens).
+
+## Social Authentication
+
+1. In your `AppDelegate` method named `application:didFinishLaunchingWithOptions` add the following line:
+  ```objc
+  A0Lock *lock = ... //Get your Lock instance
+  [lock applicationLaunchedWithOptions:launchOptions];
+  ```
+  ```swift
+  let lock = ... // Get your Lock instance
+  lock.applicationLaunched(options: launchOptions)
+  ```
+
+2. Also add the following lines to your `AppDelegate` too
+  ```objc
+- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
+    A0Lock *lock = ... // Get your Lock instance
+    return [lock handleURL:url sourceApplication:app];
+  }
+  ```
+  ```swift
+  func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+    let lock = ... // Get your Lock instance
+    return lock.handle(url, sourceApplication: app)
+  }
+  ```
+
+3. Configure Facebook Native Integration
+  ```objc
+  A0Lock *lock = ... //Get your Lock instance
+  A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticatorWithDefaultPermissions];
+  [lock registerAuthenticators:@[facebook]];
+  ```
+  ```swift
+  let lock = ... //Get your Lock instance
+  let facebook = A0FacebookAuthenticator.newAuthenticatorWithDefaultPermissions()
+  lock.registerAuthenticators([facebook])
+  ```
+  ::: note
+  You need to configure your iOS App for Facebook, please check [this guide](/libraries/lock-ios/native-social-authentication#facebook) for more information.
+  :::
+
+4. Configure Twitter Native Integration
+  ```objc
+  NSString *twitterApiKey = ... //Remember to obfuscate your api key
+  NSString *twitterApiSecret = ... //Remember to obfuscate your api secret
+  A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticationWithKey:twitterApiKey andSecret:twitterApiSecret];
+  A0Lock *lock = ... //Get your Lock instance
+  [lock registerAuthenticators:@[twitter]];
+  ```
+  ```swift
+  let twitterApiKey = ... //Remember to obfuscate your api key
+  let twitterApiSecret = ... //Remember to obfuscate your api key
+  let twitter = A0TwitterAuthenticator.newAuthenticationWithKey(twitterApiKey, andSecret:twitterApiSecret)
+  let lock = ... //Get your Lock instance
+  lock.registerAuthenticators([twitter])
+  ```
+
+5. Authenticate with a social connection
+  ```objc
+  void(^success)(A0UserProfile *, A0Token *) = ^(A0UserProfile *profile, A0Token *token) {
+    NSLog(@"We did it!. Logged in with Auth0.");
+  };
+  void(^error)(NSError *) = ^(NSError *error) {
+    NSLog(@"Oops something went wrong: %@", error);
+  };
+  A0Lock *lock = ... //Get your Lock instance
+  [[lock identityProviderAuthenticator] authenticateWithConnectionName:@"facebook" parameters:nil success:success failure:failure];
+  ```
+  ```swift
+  let success = { (profile: A0UserProfile, token: A0Token) in
+    println("We did it!. Logged in with Auth0.")
+  }
+  let failure = { (error: NSError) in
+    println("Oops something went wrong: \(error)")
+  }
+  let lock = ... //Get your Lock instance
+  lock.identityProviderAuthenticator().authenticateWithConnectionName("facebook", parameters: nil, success: success, failure: failure)
+  ```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/configuration.md b/ja-jp/articles/libraries/lock-ios/v2/configuration.md
new file mode 100644
index 0000000000..20831500fb
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/configuration.md
@@ -0,0 +1,248 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/configuration
+title: Lock for iOS v2 Configuration Options
+description: Behavior configuration options available with Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Configuration Options
+
+There are numerous options to configure Lock's behavior listed below. In addition, there are also quite a few options available to alter Lock's appearance and style in the [Style Customization Options](/libraries/lock-ios/v2/customization) page.
+
+## Configuring Lock's behavior
+
+Configuration options can be added to your Lock initialization using `withOptions`.
+
+```swift
+Lock
+  .classic()
+  .withOptions {
+    $0.closable = true
+    $0.usernameStyle = [.Username]
+    $0.allow = [.Login, .ResetPassword]
+  }
+  .present(from: self)
+```
+
+## Behavior Options
+
+### closable
+
+Allows Lock to be dismissed by the user. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.closable = true
+}
+```
+
+### scope
+
+Scope used for authentication. By default is `openid`. It will return not only the **Access Token**, but also an **ID Token** which is a JSON Web Token (JWT) containing user information. See the documentation on [Scopes](/scopes) for more information about authentication scopes.
+
+```swift
+.withOptions {
+  $0.scope = "openid name email picture"
+}
+```
+
+#### Refresh Tokens
+
+Specifying the `offline_access` scope in your Lock options will allow a [Refresh Token](/tokens/concepts/refresh-tokens) to be returned along with the access\_token and the id\_token. Refresh Tokens can be saved and used to acquire a new Access Token when the old one expires. For more information about using Refresh Tokens for Auth0 authentication, take a look at the reference documentation for the [Auth0.Swift SDK](/libraries/auth0-swift), which you would use to implement Refresh Tokens, or at the [Swift Quickstart Guide](/quickstart/native/ios-swift/03-user-sessions), which provides a comprehensive example of use of Auth0 in Swift development, including the management of Refresh Tokens.
+
+### termsOfService
+
+By default Lock will use Auth0's [Terms of Service](https://auth0.com/terms) and [Privacy Policy](https://auth0.com/privacy), but other URLs can be filled in to link to other terms and policies.
+
+```swift
+.withOptions {
+  $0.termsOfService = "https://mycompany.com/terms"
+  $0.privacyPolicy = "https://mycompany.com/privacy"
+}
+```
+
+### Show Terms of Service
+
+Database connections display the Terms of Service dialog. Default is `true`. Note that the Terms of Service will always be shown if the `mustAcceptTerms` flag is enabled.
+
+```swift
+.withOptions {
+    $0.showTerms = true
+}
+```
+
+### Require users to accept the Terms of Service
+
+Database connection require explicit acceptance of the Terms of Service.
+
+```swift
+.withOptions {
+    $0.mustAcceptTerms = true
+}
+```
+
+## Web Authentication Options
+
+### leeway
+
+Clock skew used for ID token validation. It expands the time window in which the ID token will still be considered valid, to account for the difference between server time and client time. By default is **60000 milliseconds** (60 seconds).
+
+```swift
+.withOptions {
+  $0.leeway = 30000 // 30 seconds
+}
+```
+
+### maxAge
+
+Allowable elapsed time (in milliseconds) since the user last authenticated. Used for ID token validation. If set, the ID token will contain an `auth_time` claim with the authentication timestamp. Defaults to `nil`.
+
+```swift
+.withOptions {
+  $0.maxAge = 86400000 // 1 day
+}
+```
+
+## Database options
+
+### allow
+
+Which database screens will be accessible, the default is enable all screens such as `.Login, .Signup, .ResetPassword`.
+
+```swift
+.withOptions {
+  $0.allow = [.Login, .ResetPassword]
+}
+```
+
+### initialScreen
+
+The first screen to present to the user. The default is `.Login`, other options include `.Signup` and `ResetPassword`.
+
+```swift
+.withOptions {
+  $0.initialScreen = .login
+}
+```
+
+### usernameStyle
+
+Specify the type of identifier the login will require.  The default is either: `[.Username, .Email]`, but it can also accept `[.Username]` or `[.Email]`. However it's important to note that this option is only active if you have set the `requires_username` flag to `true` in your [Auth0 Dashboard](${manage_url}/#/)
+
+```swift
+.withOptions {
+  $0.usernameStyle = [.Username]
+}
+```
+
+#### Custom Signup Fields
+
+When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata). Note that you must specify the icon to use with your custom text field.
+
+```swift
+.withOptions {
+  $0.customSignupFields = [
+    CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)),
+    CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle))
+  ]
+}
+```
+
+::: note
+You can also specify icons from other bundles, such as in the following example:
+CustomTextField(name: "slack_handle", placeholder: "Slack Handle", icon: LazyImage(name: "ic_slack", bundle: Bundle(identifier: "CustomBundle")))
+:::
+
+## Enterprise Options
+
+There are also configuration options specific to Enterprise connections:
+
+### enterpriseConnectionUsingActiveAuth
+
+By default Enterprise connections will use Web Authentication. However, you can specify which connections will alternatively use credential authentication and prompt for a username and password.
+
+```swift
+.withOptions {
+  $0.enterpriseConnectionUsingActiveAuth = ["enterprisedomain.com"]
+}
+```
+
+### activeDirectoryEmailAsUsername
+
+When in credential authentication mode, should the user require their email as an identifier?  The default is `false`, and instead requires a username.
+
+```swift
+.withOptions {
+  $0.activeDirectoryEmailAsUsername = true
+}
+```
+
+## Logging Options
+
+Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings.
+
+### logLevel
+
+By default this is `.off`, *Syslog* logging levels are supported.
+
+```swift
+.withOptions {
+  $0.logLevel = .all
+}
+```
+
+### logHttpRequest
+
+Whether or not to log Auth0.swift API requests. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.logHttpRequest = true
+}
+```
+
+### loggerOutput
+
+Specify logger output handler, by default this uses the `print` statement.
+
+```swift
+.withOptions {
+  $0.loggerOutput = CleanroomLockLogger()
+}
+```
+
+In the code above, the *loggerOutput* has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the *loggerOutput* protocol.  You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger.
+
+```swift
+class CleanroomLockLogger: LoggerOutput {
+  func message(_ message: String, level: LoggerLevel, filename: String, line: Int) {
+    let channel: LogChannel?
+    switch level {
+    case .debug:
+        channel = Log.debug
+    case .error:
+        channel = Log.error
+    case .info:
+        channel = Log.info
+    case .verbose:
+        channel = Log.verbose
+    case .warn:
+        channel = Log.warning
+    default:
+        channel = nil
+    }
+    channel?.message(message, filePath: filename, fileLine: line)
+  }
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md b/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md
new file mode 100644
index 0000000000..3ce74320cf
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md
@@ -0,0 +1,44 @@
+---
+section: libraries
+title: Custom Fields at Signup
+description: Adding additional fields to signups with Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Custom Fields at Signup
+
+**Lock v2 for iOS** allows you to specify additional fields that the user must complete before creating a new account. The extra fields will be shown after the basic fields (email, username, password).
+
+## Adding custom fields
+
+When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata).
+
+```swift
+.withOptions {
+  $0.customSignupFields = [
+    CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)),
+    CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle))
+  ]
+}
+```
+
+::: note
+You must specify the icon to use with your custom text field.
+:::
+
+That's it! If you have enabled users Sign Up in the Application's Dashboard, after they complete the basic fields (email/username, password) and hit Submit, they will be prompted to fill the remaining fields.
+
+::: note
+Note that the user must fill all of the custom fields before being able to complete signup.
+:::
+
+When requesting a user Sign Up or Sign In, the extra fields will be attached to the `user_metadata` attribute in the request body. You can access them by querying the user profile at any time, even from the Dashboard in the User's section.
diff --git a/ja-jp/articles/libraries/lock-ios/v2/customization.md b/ja-jp/articles/libraries/lock-ios/v2/customization.md
new file mode 100644
index 0000000000..438a224801
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/customization.md
@@ -0,0 +1,371 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/customization
+title: Lock for iOS v2 Style Customization Options
+description: Styling and customization options for the style of Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Style Customization Options 
+
+There are numerous options to configure Lock's style and appearance listed below. In addition, there are also quite a few options available to alter Lock's behavior and functionality in the [Behavior Configuration Options](/libraries/lock-ios/v2/configuration) page.
+
+## Customizing Lock's appearance
+
+Style customization options can be added to your Lock initialization using `withStyle`.
+
+```swift
+Lock
+  .classic()
+  .withStyle {
+	  $0.title = "Company LLC"
+	  $0.logo = LazyImage(name: "company_logo")
+	  $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0)
+	}
+  .present(from: self)
+```
+
+## Header Style Options
+
+### headerBlur 
+
+Blur effect style used. It can be any value defined in `UIBlurEffectStyle`.
+
+```swift
+.withStyle {
+  $0.headerBlur = .extraLight
+}
+```	
+
+### headerColor
+
+Color used as the header background color. By default it has no color, just a blur.
+
+```swift
+.withStyle {
+  $0.headerColor = UIColor? = nil
+}
+```	
+
+### logo
+
+Header logo image
+
+```swift
+.withStyle {
+  $0.logo = LazyImage(name: "company_logo")
+}
+``` 
+
+### headerCloseIcon
+
+The "close" icon in the header can be altered.
+
+```swift
+.withStyle {
+  $0.headerCloseIcon = LazyImage(name: "ic_close")
+}
+``` 
+
+### headerBackIcon
+
+The "back" icon in the header can be altered.
+
+```swift
+.withStyle {
+  $0.headerBackIcon = LazyImage(name: "ic_close")
+}
+``` 
+
+## Title Style Options
+
+### hideTitle
+
+Hide header title and show only the logo. By default this option is false.
+
+```swift
+.withStyle {
+  $0.hideTitle = false
+}
+```	
+
+### title
+
+Title text used in the header
+
+```swift
+.withStyle {
+  $0.title = "Company LLC"
+}
+```
+
+### titleColor
+
+Color used as the header title color.
+
+```swift
+.withStyle {
+  $0.titleColor = UIColor.black
+}
+```	
+
+## Button and Component Style Options
+
+### buttonTintColor
+
+Color used as the primary button tint color.
+
+```swift
+.withStyle {
+  $0.buttonTintColor = UIColor.white
+}
+```	
+
+### disabledColor
+
+Color used as the Lock disabled component color.
+
+```swift
+.withStyle {
+  $0.disabledColor = UIColor(red: 0.8902, green: 0.898, blue: 0.9059, alpha: 1.0)
+}
+```
+
+### disabledTextColor
+
+Color used as the Lock disabled component text color.
+
+```swift
+.withStyle {
+  $0.disabledTextColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0)
+}
+```	
+
+### hideButtonTitle
+
+Hide primary button title and show only the icon. By default this option is false.
+
+```swift
+.withStyle {
+  $0.hideButtonTitle = false
+}
+```	
+
+### primaryColor
+
+Color used as the Lock primary color.
+
+```swift
+.withStyle {
+  $0.primaryColor = UIColor.orange
+}
+```
+
+## Input Field Styles
+
+### inputTextColor
+
+The color of input field text.
+
+```swift
+.withStyle {
+  $0.inputTextColor = UIColor.black
+}
+```
+
+### inputPlaceholderTextColor
+
+The color of the placeholder text in input fields.
+
+```swift
+.withStyle {
+  $0.inputPlaceholderTextColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00)
+}
+```
+
+### inputBorderColor
+
+The color of the border of input fields.
+
+```swift
+.withStyle {
+  $0.inputBorderColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00)
+}
+```
+
+### inputBorderColorError
+
+The color of the border of input fields which have invalid values.
+
+```swift
+.withStyle {
+  $0.inputBorderColorError = UIColor.red
+}
+```
+
+### inputBackgroundColor
+
+The color of the background of input fields.
+
+```swift
+.withStyle {
+  $0.inputBackgroundColor = UIColor.white
+}
+```
+
+### inputIconBackgroundColor
+
+The color of the background of input field icons.
+
+```swift
+.withStyle {
+  $0.inputIconBackgroundColor = UIColor(red: 0.9333, green: 0.9333, blue: 0.9333, alpha: 1.0)
+}
+```
+
+### inputIconColor
+
+The color of the input field icons.
+
+```swift
+.withStyle {
+  $0.inputIconColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0)
+}
+```
+
+## Status Bar Styles
+
+### UIStatusBarAnimation
+
+The Lock Controller Status Bar update animation.
+
+```swift
+.withStyle {
+  $0.UIStatusBarAnimation = .none
+}
+```
+
+### statusBarHidden
+
+The Lock Controller Status Bar's visibility.
+
+```swift
+.withStyle {
+  $0.statusBarHidden = false
+}
+```
+
+### UIStatusBarStyle
+
+The Lock Controller Status Bar style.
+
+```swift
+.withStyle {
+  $0.UIStatusBarStyle = .default
+}
+```
+
+### UISearchBarStyle
+
+The Lock Passwordless Search Bar style.
+
+```swift
+.withStyle {
+  $0.UISearchBarStyle = .default
+}
+```
+
+## Other Style Options
+
+### textColor
+
+The color for the text in the body.
+
+```swift
+.withStyle {
+  $0.textColor = UIColor.black
+}
+```
+
+### backgroundColor
+
+Color used as the Lock background color.
+
+```swift
+.withStyle {
+  $0.backgroundColor = UIColor.white
+}
+```
+
+### backgroundImage
+
+Image used as the Lock background
+
+```swift
+.withStyle {
+  $0.backgroundImage = LazyImage(name: "company_logo")
+}
+```
+
+### oauth2
+
+Any non-db OAuth2 connection can have styles customized by mapping a connection name with an `AuthStyle`
+
+```swift
+.withStyle {
+  $0.oauth2["slack"] = AuthStyle(
+    name: "Slack",
+    color: UIColor(red: 0.4118, green: 0.8078, blue: 0.6588, alpha: 1.0),
+    withImage: LazyImage(name: "ic_slack")
+  )
+}
+```
+
+### seperatorTextColor
+
+Social separator label color.
+
+```swift
+.withStyle {
+  $0.seperatorTextColor = UIColor(red: 0.0, green: 0.0, blue: 0.0, alpha: 0.54)
+}
+```
+
+### secondaryButtonColor
+
+The color of secondary buttons.
+
+```swift
+.withStyle {
+  $0.secondaryButtonColor = UIColor.black
+}
+```
+
+### tabTextColor
+
+The color of the text on the database login tab.
+
+```swift
+.withStyle {
+  $0.tabTextColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6)
+}
+```
+
+### tabTintColor
+
+The color of the tinting on the database login tab.
+
+```swift
+.withStyle {
+  $0.tabTintColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6)
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/index.md b/ja-jp/articles/libraries/lock-ios/v2/index.md
new file mode 100644
index 0000000000..ccde6a136d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/index.md
@@ -0,0 +1,228 @@
+---
+section: libraries
+toc: true
+title: Lock v2 for iOS
+description: A widget that provides a frictionless login and signup experience for your native iOS apps.
+mobileimg: media/articles/libraries/lock-ios.png
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+  - index
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock v2 for iOS
+
+::: warning
+Auth0 encourages the use of [web authentication via Universal Login](/guides/login/universal-vs-embedded) rather than native username/password authentication whenever possible.
+:::
+
+This reference guide will show you how to implement the Lock user interface, and give you the details on configuring and customizing Lock in order to use it as the UI for your authentication needs. However, if you'd like to learn how to do more with Auth0 and Swift, such as how to save, call and refresh Access Tokens, get user profile info, and more, check out the [Auth0.swift SDK](/libraries/auth0-swift). Or, take a look at the [Swift Quickstart](/quickstart/native/ios-swift) to walk through complete examples and see options, both for using Lock as the interface, and for using a custom interface. 
+
+::: note
+Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift) on GitHub.
+:::
+
+## Requirements
+
+- iOS 9+
+- Xcode 10+
+- Swift 4+
+
+<%= include('../_includes/_dependencies') %>
+
+## Setup
+
+### Integrate with your Application
+
+Lock needs to be notified when the application is asked to open a URL. You can do this in the `AppDelegate` file.
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
+  return Lock.resumeAuth(url, options: options)
+}
+```
+
+### Import Lock
+
+Import **Lock** wherever you'll need it
+
+```swift
+import Lock
+```
+
+### Auth0 Credentials
+
+In order to use Lock you need to provide your Auth0 Client Id and Domain, which can be found in your [Auth0 Dashboard](${manage_url}), under your Application's settings.
+
+In your application bundle you can add a `plist` file named `Auth0.plist` that will include your credentials with the following format.
+
+```xml
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+## Implementation of Lock Classic
+
+Lock Classic handles authentication using Database, Social, and Enterprise connections.
+
+### OIDC Conformant Mode
+
+It is strongly encouraged that this SDK be used in OIDC Conformant mode. When this mode is enabled, it will force the SDK to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. By default this is `false`
+
+```swift
+.withOptions {
+    $0.oidcConformant = true
+}
+```
+
+::: note
+For more information, please see our [Introduction to OIDC Conformant Authentication](/api-auth/intro) and the [OIDC adoption guide](/api-auth/tutorials/adoption).
+:::
+
+To show Lock, add the following snippet in your `UIViewController`.
+
+```swift
+Lock
+    .classic()
+    // withConnections, withOptions, withStyle, and so on
+    .withOptions {
+      $0.oidcConformant = true
+      $0.scope = "openid profile"
+    }
+    .onAuth { credentials in
+      // Let's save our credentials.accessToken value
+    }
+    .present(from: self)
+```
+
+## Use Auth0.Swift Library to access user profile
+
+To access user profile information, you will need to use the `Auth0.Swift` library:
+
+```swift
+guard let accessToken = credentials.accessToken else { return }
+Auth0
+    .authentication()
+    .userInfo(withAccessToken: accessToken)
+    .start { result in
+        switch result {
+        case .success(let profile):
+            // You've got a UserProfile object
+        case .failure(let error):
+            // You've got an error
+        }
+}
+```
+
+Check out the [Auth0.Swift Library Documentation](/libraries/auth0-swift) for more information about its uses.
+
+## Specify Connections
+
+Lock will automatically load the connections configured for your application. If you wish to override the default behavior, you can manually specify which connections it should display to users as authentication options. This can be done by calling the method and supplying a closure that can specify the connection(s).
+
+Adding a database connection:
+
+```swift
+.withConnections {
+    $0.database(name: "Username-Password-Authentication", requiresUsername: true)
+}
+```
+
+Adding multiple social connections:
+
+```swift
+.withConnections {
+    $0.social(name: "facebook", style: .Facebook)
+    $0.social(name: "google-oauth2", style: .Google)
+}
+```
+
+## Styling and Customization
+
+Lock provides many styling options to help you apply your own brand identity to Lock using `withStyle`. For example, changing the primary color and header text of your Lock widget:
+
+### Customize your title, logo, and primary color
+
+```swift
+.withStyle {
+  $0.title = "Company LLC"
+  $0.logo = LazyImage(named: "company_logo")
+  $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0)
+}
+```
+
+::: note
+You can see the complete set of styling options to alter the appearance of Lock for your app in the [Customization Guide](/libraries/lock-ios/v2/customization).
+:::
+
+## Configuration Options
+
+There are numerous options to configure Lock's behavior. Below is an example of Lock configured to allow it to be closable, to limit it to only usernames (and not emails), and to only show the Login and Reset Password screens.
+
+```swift
+Lock
+  .classic()
+  .withOptions {
+    $0.closable = true
+    $0.usernameStyle = [.Username]
+    $0.allow = [.Login, .ResetPassword]
+  }
+```
+
+::: note
+You can see the complete set of behavior configuration options to alter the way Lock works for your app in the [Configuration Guide](/libraries/lock-ios/v2/configuration).
+:::
+
+## Password Manager Support
+
+By default, password manager support using [1Password](https://1password.com/) is enabled for database connections. 1Password support will still require the user to have the 1Password app installed for the option to be visible in the login and signup screens. You can disable 1Password support using the enabled property of the passwordManager.
+
+```swift
+.withOptions {
+    $0.passwordManager.enabled = false
+}
+```
+
+By default the `appIdentifier` will be set to the app's bundle identifier and the `displayName` will be set to the app's display name. You can customize these as follows:
+
+```swift
+.withOptions {
+    $0.passwordManager.appIdentifier = "www.myapp.com"
+    $0.passwordManager.displayName = "My App"
+}
+```
+
+You will need to add the following to your app's `info.plist`:
+
+```
+LSApplicationQueriesSchemes
+
+    org-appextension-feature-password-management
+
+```
+
+<%= include('../_includes/_roadmap') %>
+
+## Next Steps
+
+::: next-steps
+- [Customizing the Style of Lock](/libraries/lock-ios/v2/customization)
+- [Customizing the Behavior of Lock](/libraries/lock-ios/v2/configuration)
+- [Adding Custom Signup Fields to Lock](/libraries/lock-ios/v2/custom-fields)
+- [Lock Internationalization](/libraries/lock-ios/v2/internationalization)
+- [Logging out Users](/logout)
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v2/internationalization.md b/ja-jp/articles/libraries/lock-ios/v2/internationalization.md
new file mode 100644
index 0000000000..cda2d77a2b
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/internationalization.md
@@ -0,0 +1,70 @@
+---
+section: libraries
+title: Internationalization in Lock v2 for iOS
+description: Internationalization support in Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+  - i18n
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Internationalization
+
+By default, **Lock v2 for iOS** displays all text in English. If you wish to display text in another language, or you wish to alter the text values for your application, you may provide a `Lock.strings` file and define values to be used for the various text items that Lock might display.
+
+More information about how to handle languages can be found in the official Apple documentation on [Internationalization and Localization](https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/Introduction/Introduction.html#//apple_ref/doc/uid/10000171i-CH1-SW1)
+
+## Lock String Values
+
+For a full list of the terms used by Lock, see the base [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file in the Lock.swift repository.
+
+### Providing alternative English strings
+
+If you want to change some or all of the existing terms, you can do this by downloading and adding the [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file to your project.
+
+Select the **Lock.strings** file and in the `File inspector` click on `Localize...`
+
+![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize.png)
+
+Then select `English`:
+
+![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize_english.png)
+
+Now lets take a couple of terms in **Lock.strings** and update them with alternative text:
+
+```text
+// Forgot password
+"com.auth0.lock.database.button.forgot_password" = "Did you forget your password?";
+// tos & privacy
+"com.auth0.lock.database.button.tos" = "Signing up is an indication of your agreement to our terms of\n service and privacy policy";
+```
+
+### Supporting other languages
+
+To add another language you first of all need to add the new language under `Project/Info`
+
+![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language.png)
+
+Add the new language and ensure that **Lock.strings** is selected
+
+![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language_step_2.png)
+
+You will notice under **Lock.strings** a new file has been created for your specified language, based upon the **Reference Language** selection.
+
+Now you are ready to translate to your desired language.
+
+### Notes
+
+Some terms use parameters and it's important to note their placement in your translation.  In particular multiple parameter terms such as:
+
+```text
+// No more than %@{count} identical characters in a row (such as, \"%@{identical sample}\" not allowed)
+"com.auth0.lock.error.password.no_more_identical" = "No more than %1$d identical characters in a row (such as, \"%2$@\" not allowed)";
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/logging.md b/ja-jp/articles/libraries/lock-ios/v2/logging.md
new file mode 100644
index 0000000000..821a5dae26
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/logging.md
@@ -0,0 +1,73 @@
+---
+section: libraries
+title: Logging in Lock for iOS v2
+description: Logging in Lock for iOS v2
+topics:
+  - libraries
+  - lock
+  - ios
+  - logs
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Logging in Lock for iOS v2
+
+Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings.
+
+## logLevel
+
+By default this is `.off`, *Syslog* logging levels are supported.
+
+```swift
+.withOptions {
+  $0.logLevel = .all
+}
+```
+
+## logHttpRequest
+
+This option allows you to choose whether or not to log Auth0.swift API requests. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.logHttpRequest = true
+}
+```
+
+## loggerOutput
+
+You can specify a logger output handler, by default this uses the `print` statement.
+
+```swift
+.withOptions {
+  $0.loggerOutput = CleanroomLockLogger()
+}
+```
+
+In the code above, the `loggerOutput` has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the `loggerOutput` protocol.  You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger.
+
+```swift
+class CleanroomLockLogger: LoggerOutput {
+  func message(_ message: String, level: LoggerLevel, filename: String, line: Int) {
+    let channel: LogChannel?
+    switch level {
+    case .debug:
+        channel = Log.debug
+    case .error:
+        channel = Log.error
+    case .info:
+        channel = Log.info
+    case .verbose:
+        channel = Log.verbose
+    case .warn:
+        channel = Log.warning
+    default:
+        channel = nil
+    }
+    channel?.message(message, filePath: filename, fileLine: line)
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/lock-ios/v2/migration.md b/ja-jp/articles/libraries/lock-ios/v2/migration.md
new file mode 100644
index 0000000000..274c9bd896
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/migration.md
@@ -0,0 +1,292 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/migration
+title: Migrating from v1 to v2 of Lock for iOS
+description: A migration guide to assist with migration from Lock v1 (Swift) to Lock v2 (Swift).
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - migrations
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+  - migrate
+---
+# Migrating from Lock iOS v1 to v2
+
+Lock 2.0 is the latest major release of Lock iOS-OSX. This guide is provided in order to ease the transition of existing applications using Lock 1.x to the latest APIs.
+
+## Requirements
+
+- iOS 9.0+
+- Xcode 8.0+
+- Swift 3.0+
+
+### Objective-C support
+
+Lock v2 cannot be used from Objective-C, since its public API relies on Swift features and that makes them unavailable in ObjC codebases.
+
+If you are willing to have some Swift code in your existing application, you can follow this [guide](https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html) on how to mix Objective-C and Swift and then use Lock v2 from the Swift files.
+
+If that's not an option, we recommend sticking with Lock v1 or using [Auth0.swift](/libraries/auth0-swift) to build your own interface for user logins and signups.
+
+## Benefits of upgrading
+
+- **Complete Swift 3 Compatibility:** The new version includes the adoption of the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/).
+- **Improved UI:** having a professional looking login box that displays well on any device.
+- **Extensive configuration:** Lock provides improved configuration options to help customize the experience to your users needs.
+- **Safari controller for web-based Auth:** Following Google's recent ban of WebView based auth, Lock (and Auth0.swift) will always use `SFSafariViewController` when web auth is needed.
+- **API Authorization support:** Adds support for Auth0 [API Authorization](https://auth0.com/docs/api-auth)
+
+## Changes from v1
+
+Lock 2.0 has adopted to all of the new Swift 3 changes and conventions, including the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). Because of this, almost every API in Lock has been modified in some way. This guide will attempt to identify the most common usages and how they have changed, to help you get started with Lock 2.0. For yet more information on Lock 2.0, you can also see the [Lock 2.0 Reference](libraries/lock-ios) documentation.
+
+### Integration with your Application
+
+Lock needs to be notified for some of your application state changes and some events/notifications your application receives from the OS. You can do all these things in the `AppDelegate`
+
+#### Application finished launching
+
+In Lock v1 you'd add the following:
+
+```swift
+func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
+  A0Lock.sharedLock().applicationLaunchedWithOptions(launchOptions)
+  //Your code
+  return true
+}
+```
+
+In Lock v2, this is no longer required.
+
+#### Application is asked to open URL
+
+In Lock v1 you'd add the following:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+  return A0Lock.shared().handle(url, sourceApplication: app)
+}
+```
+
+In Lock v2 you need to instead use the following:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+  return Lock.resumeAuth(url, options: options)
+}
+```
+
+#### Application is asked to continue a User Activity
+
+If you are using Lock passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`:
+
+```swift
+func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
+    return Lock.continueAuth(using: userActivity)
+}
+```
+
+### Usage
+
+`Lock` by default will handle Email/Password, Enterprise & Social authentication based on your application's connections enabled in your [Auth0 Dashboard](${manage_url}) under "Connections" in your application settings.
+
+#### Auth0 credentials
+
+Like in v1, in your application bundle you can add a `plist` file named `Auth0.plist` with the following format:
+
+```xml
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+This will load your Auth0 credentials.
+
+#### Classic mode (Database, Enterprise & Social authentication)
+
+In v1 to show Lock from a `UIViewController` you'd add the following code:
+
+```swift
+let lock = A0Lock.shared()
+let controller = lock.newLockViewController()
+controller.onAuthenticationBlock = {(profile, token) in
+  // Do something with token & profile, such as save them.
+  // Lock will not save the Token and the profile for you.
+  // And dismiss the UIViewController.
+  self.dismissViewController(animated: true, completion: nil)
+}
+lock.present(controller, from: self)
+```
+
+In v2, to show Lock, the following code will be necessary:
+
+```swift
+Lock
+  .classic()
+  .onAuth { credentials in
+    print("Authenticated!")
+  }
+  .present(from: self)
+```
+
+So, in the `onAuth` callback, you'd only receive the credentials of the user when the authentication is successful.
+
+::: note
+In contrast with Lock v1, in v2, Lock will dismiss itself so there is no need to call `dismissViewController(animated:, completion:)` in any of the callbacks.
+:::
+
+In the case you need to know about the errors or signup, there are the corresponding `onError` and `onSignUp` callbacks that can be employed.
+
+```swift
+Lock
+  .classic()
+  .onAuth { credentials in
+    print("Authenticated!")
+  }
+  .onSignUp { email, attributes in
+    print("New user with email \(email)!")
+  }
+  .onError { error in
+    print("Failed with error \(error.localizedString)")
+  }
+  .present(from: self)
+```
+
+::: note
+The callback `onSignUp` is only called when the "login after signup" is disabled.
+:::
+
+#### Passwordless mode (Email & SMS connections)
+
+In v1 to show Lock Passwordless from a `UIViewController` you'd need to use either:
+
+Email:
+
+```swift
+let lock = A0Lock.shared()
+let controller: A0EmailLockViewController = lock.newEmailViewController()
+controller.useMagicLink = true
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile, such as save them.
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.presentEmailController(controller, from: self)
+```
+
+or SMS:
+
+```swift
+let lock = A0Lock.shared()
+let controller: A0SMSLockViewController = lock.newSMSViewController()
+controller.useMagicLink = true
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile, such as save them.
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.presentSMSController(controller, from: self)
+```
+
+In V2 both email and sms now use the same method:
+
+```swift
+Lock
+    .passwordless()
+    .onAuth { credentials in
+      print("Authenticated!")
+    }
+    .present(from: self)
+```
+
+**Notes:**
+
+- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS.
+- The `audience` option is not available in Passwordless.
+
+#### Configuration options
+
+If you needed to tweak Lock behaviour using its options in v1, you would use the following format:
+
+```swift
+let controller = A0Lock.shared().newLockViewController()
+controller?.closable = true
+controller?.connections = ["facebook", "github", "my-database"]
+```
+
+In Lock v2 you can do it all before presenting Lock by using this format:
+
+```swift
+Lock
+  .withOptions { options in
+    options.closable = true
+    options.allowedConnections = ["facebook", "github", "my-database"]
+  }
+  // continue configuring and then present Lock
+```
+
+#### UI customizations
+
+In v1 all UI customizations were performed using the `A0Theme` object in this format:
+
+```swift
+let theme = A0Theme()
+theme.register(.blue, forKey: A0ThemeTitleTextColor)
+A0Theme.sharedInstance().register(theme)
+```
+
+In Lock v2, the UI customization is done using the `withStyle` function:
+
+```swift
+Lock
+  .classic()
+  .withStyle { style in
+    style.titleColor = .blue
+  }
+  // other customizations
+  .present(from: self)
+```
+
+## Use Auth0.Swift Library to access user profile
+
+Lock can no longer directly access user profile information. To do so, you will now need to use the [Auth0.Swift library](/libraries/auth0-swift). Below is an example of accessing `userInfo` with `Auth0.Swift`:
+
+```swift
+guard let accessToken = credentials.accessToken else { return }
+Auth0
+    .authentication()
+    .userInfo(token: accessToken)
+    .start { result in
+        switch result {
+        case .success(let profile):
+            // You've got a UserProfile object
+        case .failure(let error):
+            // You've got an error
+        }
+}
+```
+
+### Delegation
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+Delegation is not available through Lock. It can be implemented via a legacy method in [Auth0.Swift](/libraries/auth0-swift) for tenants which existed prior to June 2017.
+
+<%= include('../_includes/_roadmap') %>
diff --git a/ja-jp/articles/libraries/lock-ios/v2/passwordless.md b/ja-jp/articles/libraries/lock-ios/v2/passwordless.md
new file mode 100644
index 0000000000..5f9478eca3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/passwordless.md
@@ -0,0 +1,59 @@
+---
+section: libraries
+title: Lock Passwordless for iOS
+description: Using Passwordless authentication with Lock for iOS v2
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwordless
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Passwordless for iOS
+
+Lock Passwordless handles passwordless authentication using email and sms connections.
+
+To use Passwordless Authentication you need Lock.Swift version 2.14.0 or greater.
+
+To show Lock, add the following snippet in your `UIViewController`.
+
+```swift
+Lock
+    .passwordless()
+    .withOptions {
+         $0.oidcConformant = true
+    }
+    // withConnections, withOptions, withStyle, and so on.
+    .onAuth { credentials in
+      // Save the Credentials object
+    }
+    .present(from: self)
+```
+
+**Notes:**
+
+- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS.
+
+### Passwordless Method
+
+When using Lock Passwordless the default `passwordlessMethod` is `.code` which sends the user a one time passcode to login. If you want to use [Universal Links](/dashboard/guides/applications/enable-universal-links) you can add the following:
+
+```swift
+.withOptions {
+    $0.passwordlessMethod = .magicLink
+}
+```
+
+### Activity callback
+
+If you are using Lock Passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`:
+
+```swift
+func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
+    return Lock.continueAuth(using: userActivity)
+}
+```
diff --git a/ja-jp/articles/libraries/lock/index.yml b/ja-jp/articles/libraries/lock/index.yml
new file mode 100644
index 0000000000..a120986e44
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/index.yml
@@ -0,0 +1,7 @@
+versioning:
+  baseUrl: libraries/lock
+  current: v11
+  versions:
+    - v11
+  defaultArticles:
+    v11: index
diff --git a/ja-jp/articles/libraries/lock/v11/api.md b/ja-jp/articles/libraries/lock/v11/api.md
new file mode 100644
index 0000000000..58949c9ed4
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/api.md
@@ -0,0 +1,308 @@
+---
+section: libraries
+toc: true
+description: Details on the Lock v11 API.
+topics:
+  - libraries
+  - lock
+contentType:
+  - reference
+useCase:
+  - add-login
+---
+# Lock API Reference
+
+Lock has many methods, features, and configurable options. This reference is designed to direct you to the ones that you need, and discuss how to use them. Click below to go straight the method you're looking for, or just browse! If you're looking for information about events emitted by Lock, they're listed under the [on()](#on-) method section!
+
+- [new Auth0Lock](#auth0lock) - Instantiating Lock
+- [getUserInfo()](#getuserinfo-) - Obtaining the profile of a logged in user
+- [show()](#show-) - Showing the Lock widget
+- [on()](#on-) - Listening for events
+- [resumeAuth()](#resumeauth-) - Use to complete authentication flow when `autoParseHash` is false
+- [checkSession()](#checksession-) - Get a new token from Auth0 for an authenticated user
+- [logout()](#logout-) - Log out the user
+
+## Auth0Lock
+
+```js
+new Auth0Lock(clientID, domain, options)
+```
+
+Initializes a new instance of `Auth0Lock` configured with your application's `clientID` and your account's `domain` from your [Auth0](${manage_url}/) management dashboard. The third and optional parameter is an `options` object used to configure Lock for your application's needs. You can find this information at your [application settings](${manage_url}/#/applications).
+
+- **clientId {String}**: Required parameter. Your application's _clientId_ in Auth0.
+- **domain {String}**: Required parameter. Your Auth0 _domain_. Usually _your-account.auth0.com_.
+- **options {Object}**: Optional parameter. Allows for the configuration of Lock's appearance and behavior. See [the configuration options page](/libraries/lock/v11/configuration) for details.
+
+**Example:**
+
+```js
+var Auth = (function() {
+
+  var privateStore = {};
+
+  function Auth() {
+    // Instantiate Lock - without custom options
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+  }
+
+  Auth.prototype.getProfile = function() {
+    return privateStore.profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event and get profile
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+
+        //save Access Token only if necessary
+        privateStore.accessToken = accessToken;
+        privateStore.profile = profile;
+
+        // Update DOM
+      });
+    });
+  };
+  return Auth;
+}());
+```
+
+## getUserInfo()
+
+```js
+getUserInfo(accessToken, callback)
+```
+
+Once the user has logged in and you are in possession of a token, you can use that token to obtain the user's profile with `getUserInfo`. This method replaces the deprecated `getProfile()`.
+
+- **accessToken {String}**: User token.
+- **callback {Function}**: Will be invoked after the user profile been retrieved.
+
+**Example:**
+
+```js
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    alert("hello " + profile.name);
+  }
+});
+```
+
+## show()
+
+```js
+show(options)
+```
+
+The `show` method displays the widget. Beginning with Lock version 10.2.0, the `show` method can now accept an `options` object as a parameter. Note that this parameter is meant to be used as a way to _override_ your Lock's `options` for this particular displaying of the widget - options should be _set_ when instantiating Lock, and _overridden_, only if needed for your specific use case, here.
+
+The following subset of `options` to be overridden from the values they were given (or their defaults) when Lock was instantiated:
+
+- [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-)
+- [auth.params](/libraries/lock/v11/configuration#params-object-)
+- [allowLogin](/libraries/lock/v11/configuration#allowlogin-boolean-)
+- [allowSignUp](/libraries/lock/v11/configuration#allowsignup-boolean-)
+- [allowForgotPassword](/libraries/lock/v11/configuration#allowforgotpassword-boolean-)
+- [initialScreen](/libraries/lock/v11/configuration#initialscreen-string-)
+- [rememberLastLogin](/libraries/lock/v11/configuration#rememberlastlogin-boolean-)
+
+For more detail on the entire list of configurable options that can be chosen when instantiating Lock, as opposed to the limited subset above that can be overridden in the `show` method, please see the [user configurable options page](/libraries/lock/v11/configuration).
+
+Options override examples:
+
+```js
+// Show the Lock widget, without overriding any options
+lock.show();
+```
+
+```js
+// Show the Lock widget, overriding some options
+lock.show({
+  allowedConnections: ["twitter", "facebook"],
+  allowSignUp: false
+});
+```
+
+::: panel When to set your configuration options
+Options should be set when first instantiating Lock `var lock = new Auth0Lock(clientId, domain, options);`. Options should only be passed to `show` in order to override your previously set options while displaying the widget at this particular time and place.
+
+Previous users of Lock 9 should note that this is a different behavior from `options` in Lock 9, where all options were set as parameters of `show` and not at instantiation.
+:::
+
+There is an additional option that can be set in the `show` method called `flashMessage`.
+
+### flashMessage
+
+This object is _only_ available as an option for the `show` method, not for use in the normal `options` object when instantiating Lock. The `flashMessage` object shows an error or success flash message when Lock is shown. It has the following parameters:
+
+- **type** {String}: The message type, it should be either `error` or `success`.
+- **text** {String}: The text to show.
+
+An example of usage:
+
+```js
+lock.show({
+  flashMessage:{
+    type: 'success',
+    text: 'Amazing Success!!'
+  }
+});
+```
+
+![Lock - Flash Message](/media/articles/libraries/lock/v10/flashMessage.png)
+
+A practical application of the `flashMessage` option is to handle authorization errors. The `flashMessage` can be populated with error description text.
+
+```js
+lock.on('authorization_error', function(error) {
+  lock.show({
+    flashMessage: {
+      type: 'error',
+      text: error.errorDescription
+    }
+  });
+});
+```
+
+So, if `tester@example.com` were now to try to sign in, being a user who is blocked, the user will be shown Lock again, and receive the following error message:
+
+![Lock - Flash Message](/media/articles/libraries/lock/v10/flashmessage2.png)
+
+Rather than simply failing to login, and Lock closing.
+
+## hide()
+
+```js
+hide()
+```
+
+The `hide` method closes the widget if it is currently open. The widget closes itself under most circumstances, so this method would primarily be invoked in specific use cases only. For instance, one might wish to listen for the `unrecoverable_error` event and then `hide` the Lock and redirect to their own custom error page. Another example is users who are implementing [popup mode](/libraries/lock/v11/popup-mode), and might need to manually `hide` the widget after the `authenticated` event fires.
+
+Example usage to hide (close) the Lock widget in popup mode:
+
+```js
+// Listen for authenticated event and hide Lock
+lock.on("authenticated", function() {
+  lock.hide();
+
+  // Whatever else you'd like to do on authenticated event
+
+});
+```
+
+## on()
+
+```js
+on(event, callback)
+```
+
+Lock will emit events during its lifecycle. The `on` method can be used to listen for particular events and react to them.
+
+- `show`: emitted when Lock is shown. Has no arguments.
+- `hide`: emitted when Lock is hidden. Has no arguments.
+- `unrecoverable_error`: emitted when there is an unrecoverable error, for instance when no connection is available. Has the error as the only argument.
+- `authenticated`: emitted after a successful authentication. Has the authentication result as the only argument. The authentication result contains the token which can be used to get the user's profile or stored to log them in on subsequent checks. 
+- `authorization_error`: emitted when authorization fails. Has error as the only argument.
+- `hash_parsed`: every time a new Auth0Lock object is initialized in redirect mode (the default), it will attempt to parse the hash part of the url looking for the result of a login attempt. This is a low level event for advanced use cases and `authenticated` and `authorization_error` should be preferred when possible. After that this event will be emitted with `null` if it couldn't find anything in the hash. It will be emitted with the same argument as the `authenticated` event after a successful login or with the same argument as `authorization_error` if something went wrong. This event won't be emitted in [popup mode](/libraries/lock/v11/authentication-modes) because there is no need to parse the url's hash part.
+- `forgot_password ready`: emitted when the "Forgot password" screen is shown. (Only in Version >`10.18`)
+- `forgot_password submit`: emitted when the user clicks on the submit button of the "Forgot password" screen. (Only in Version >`10.14`)
+- `signin ready`: emitted when the "Sign in" screen is shown.
+- `signup ready`: emitted when the "Sign up" screen is shown.
+- `signin submit`: emitted when the user clicks on the submit button of the "Login" screen. (Only in Version >`10.18`)
+- `signup submit`: emitted when the user clicks on the submit button of the "Sign Up" screen. (Only in Version >`10.18`)
+- `federated login`: emitted when the user clicks on a social connection button. Has the connection name and the strategy as arguments. (Only in Version >`10.18`)
+- `socialOrPhoneNumber ready`: emitted when the Passwordless screen with Social + Phone Number is shown
+- `socialOrPhoneNumber submit`: emitted when the Passwordless screen with Social + Phone Number is submitted
+- `socialOrEmail ready`: emitted when the Passwordless screen with Social + Email is shown
+- `socialOrEmail submit`: emitted when the Passwordless screen with Social + Email is submitted
+- `vcode ready`: emitted when the Passwordless screen with the one-time-password is shown
+- `vcode submit`: emitted when the Passwordless screen with the one-time-password is submitted
+
+The `authenticated` event listener has a single argument, an `authResult` object. This object contains the following properties: `accessToken`, `idToken`, `state`, `refreshToken` and `idTokenPayload`.
+
+An example use of the `authenticated` event:
+
+```js
+var Auth = (function() {
+
+  var privateStore = {};
+
+  function Auth() {
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+  }
+
+  Auth.prototype.getProfile = function() {
+    return privateStore.profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+        
+        privateStore.profile = profile;
+      
+      });
+    });
+  };
+  return Auth;
+}());
+```
+
+## resumeAuth()
+
+This method can only be used when you set the [auth.autoParseHash](/libraries/lock/v11/configuration#autoparsehash-boolean-) option to `false`. You'll need to call `resumeAuth` to complete the authentication flow. This method is useful when you're using a client-side router that uses a `#` to handle urls (angular2 with `useHash`, or react-router with `hashHistory`).
+
+- **hash** {String}: The hash fragment received from the redirect.
+- **callback** {Function}: Will be invoked after the parse is done. Has an error (if any) as the first argument and the authentication result as the second one. If there is no hash available, both arguments will be `null`.
+
+```js
+lock.resumeAuth(hash, function(error, authResult) {
+  if (error) {
+    alert("Could not parse hash");
+  }
+  //This is just an example; you should not log Access Tokens in production.
+  console.log(authResult.accessToken);
+});
+```
+
+## checkSession()
+
+The `checkSession` method allows you to acquire a new token from Auth0 for a user who is already authenticated against Auth0 for your domain. It takes the following parameters:
+
+- **options** {Object}: Optional. Accepts any valid OAuth2 parameters that would normally be sent to `/authorize`. If you omit them, it will use the ones provided when initializing Auth0.
+- **callback** {Function}: Will be invoked with the token renewal result. Has an error (if any) as the first argument and the authentication result as the second one.
+
+```js
+lock.checkSession({}, function(err, authResult) {
+  // handle error or new tokens
+});
+```
+
+## logout()
+
+Logs out the user.
+
+- **options** {Object}: This is optional and follows the same rules as [auth0.js logout](/libraries/auth0js#logout)
+
+```js
+lock.logout({
+  returnTo: 'https://myapp.com/bye-bye'
+});
+```
diff --git a/ja-jp/articles/libraries/lock/v11/authentication-modes.md b/ja-jp/articles/libraries/lock/v11/authentication-modes.md
new file mode 100644
index 0000000000..b11a8d6310
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/authentication-modes.md
@@ -0,0 +1,62 @@
+---
+section: libraries
+description: Details about Authentication Modes with Lock v11.
+toc: true
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+---
+# Lock Authentication Modes
+
+Lock can function in two different modes. The default mode is **redirect mode**. In this mode, your user is redirected to be authenticated, and then is returned to the application. In the second mode, **popup mode**, a popup window allows the user to authenticate with the identity provider without leaving the application.
+
+## Redirect Mode
+
+When you click the IdP button (For example, Facebook) with redirect mode, you are redirected to Facebook momentarily. Redirect mode is the default with Lock v11, and is the recommended mode for almost all use cases. Once you successfully login (to Facebook, in this example), Facebook will redirect you back to your app (through Auth0). The majority of examples or samples in the reference documentation employ redirect mode.
+
+## Popup Mode
+
+If after you click on the IdP button (Facebook for example), a popup (new tab or window) is opened, it means you are using popup mode. In that popup, you'll see that Facebook page is displayed. Once you successfully login to Facebook, the popup will be closed and your web app will recognize that the user has been authenticated. The web app has **never been redirected to any other page**.
+
+Implementing Lock with Popup Mode is again a simple change of the `redirect` option from its default.
+
+```js
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  {
+    auth: {
+      redirect: false
+    }
+  }
+);
+```
+
+::: note
+Multi-factor authentication (MFA) is not supported when Lock is in popup mode and embedded in your application.
+:::
+
+::: note
+Popup mode does not work with Universal Login.
+:::
+
+Some Auth0 features such as [Single Sign-out (SSO)](/sso/current/sso-auth0) between multiple applications depend on users being redirected to Auth0 to set a cookie on `'${account.namespace}'`.
+
+When using popup mode, a popup window will be displayed in order to set this cookie. If prompts are unnecessary, this popup window will be blank and be in a hidden iframe to minimize disruption. The reason for this is that cross-origin requests sent from your application to Auth0 are not be able to set cookies.
+
+If you do not want to display a popup window and do not need SSO between multiple applications, you can set `sso: false` when using Lock or auth0.js.
+
+For example:
+
+```js
+var options = {
+  auth: {
+    sso: false
+  }
+}
+```
diff --git a/ja-jp/articles/libraries/lock/v11/configuration.md b/ja-jp/articles/libraries/lock/v11/configuration.md
new file mode 100644
index 0000000000..d5c1e9492c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/configuration.md
@@ -0,0 +1,973 @@
+---
+section: libraries
+toc: true
+description: Lock v11 has many configurable options that allow you to change the behavior, appearance, and connectivity of the Lock widget - this resource provides the details on those options for you!
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock Configuration Options
+
+The **Auth0Lock** can be configured through the `options` parameter sent to the constructor. These options can alter the way that the Lock widget behaves, how it deals with connections, additional signup fields that you require for your project, the language and text values, colors, and images on the widget, and many more. Take a look at the index below if you know what you are looking for, or browse the options for more details.
+
+```js
+var lock = new Auth0Lock('clientID', 'account.auth0.com', options);
+```
+
+## UI
+
+| Option | Description |
+| --- | --- |
+| [allowAutocomplete](#allowautocomplete-boolean-) | Enable or disable autocompletion on the email or username inputs |
+| [allowPasswordAutocomplete](#allowpasswordautocomplete-boolean-) | Enable or disable autocompletion on password input |
+| [allowShowPassword](#allowshowpassword-boolean-) | Specifies if the user can choose to show password while typing it |
+| [allowedConnections](#allowedconnections-array-) | List of connections that will be available to perform authentication |
+| [autoclose](#autoclose-boolean-) | Specifies if Lock closes after a login |
+| [autofocus](#autofocus-boolean-) | Specifies if focus is set on the first input field |
+| [avatar](#avatar-object-) | Specifies if an avatar and a username should be displayed on the Lock's header once an email or username has been entered and how to obtain it |
+| [closable](#closable-boolean-) | Determines whether or not Lock can be closed |
+| [container](#container-string-) | The HTML element where Lock will be rendered. This causes Lock to appear inline instead of in a modal window |
+| [flashMessage](#) | Shows an `error` or `success` flash message when Lock is shown |
+| [language](#language-string-) | Specifies the language of the widget |
+| [languageDictionary](#languagedictionary-object-) | Change text in particular sections of Lock |
+| [popupOptions](#popupoptions-object-) | Customize the location of the popup in the screen |
+| [rememberLastLogin](#rememberlastlogin-boolean-) | Whether or not to show a screen that allows you to quickly log in with the account you used the last time |
+| [scrollGlobalMessagesIntoView](#scrollglobalmessagesintoview-boolean-) | Specify if a globalMessage should be scrolled into the user's viewport |
+
+## Theme
+
+Theme options are grouped in the `theme` property of the `options` object.
+
+| Option | Description |
+| --- | --- |
+| [authButtons](#authbuttons-object-) | Customize the appearance of specific connection buttons |
+| [labeledSubmitButton](#labeledsubmitbutton-boolean-) | whether or not the submit button has text |
+| [logo](#logo-string-) | What logo should be used |
+| [primaryColor](#primarycolor-string-) | Color of the primary button on the widget |
+
+## Authentication
+
+Authentication options are grouped in the `auth` property of the `options` object.
+
+| Option | Description |
+| --- | --- |
+| [audience](#audience-string-) | The API which will be consuming your Access Token |
+| [autoParseHash](#autoparsehash-boolean-) | Whether or not to automatically parse hash and continue |
+| [connectionScopes](#connectionscopes-object-) | Specify connection scopes |
+| [params](#params-object-) | Option to send parameters at login |
+| [redirect](#redirect-boolean-) | Whether or not to use redirect mode |
+| [redirectUrl](#redirecturl-string-) | The URL to redirect to after auth |
+| [responseMode](#responsemode-string-) | Option to send response as POST |
+| [responseType](#responsetype-string-) | Response as a code or token |
+| [sso](#sso-boolean-) | Determines whether Single Sign-On is enabled or not in Lock |
+
+### Database
+
+| Option | Description |
+| --- | --- |
+| [additionalSignUpFields](#additionalsignupfields-array-) | Additional fields collected at signup |
+| [allowLogin](#allowlogin-boolean-) | Whether or not to allow login on widget |
+| [allowForgotPassword](#allowforgotpassword-boolean-) | Whether or not to allow forgot password on widget |
+| [allowSignUp](#allowsignup-boolean-) | Whether or not to allow signup on widget |
+| [defaultDatabaseConnection](#defaultdatabaseconnection-string-) | Default shown DB connection |
+| [initialScreen](#initialscreen-string-) | Which screen to show when the widget is opened |
+| [loginAfterSignUp](#loginaftersignup-boolean-) | After signup, whether or not to auto login |
+| [forgotPasswordLink](#forgotpasswordlink-string-) | Link to a custom forgot password page |
+| [showTerms](#showterms-boolean-) | Specify if signup terms should be display |
+| [mustAcceptTerms](#mustacceptterms-boolean-) | Whether or not terms must be accepted (checkbox) |
+| [prefill](#prefill-object-) | Prefill values for email/username fields |
+| [signUpLink](#signuplink-string-) | Set a custom url to fire when clicking "sign up" |
+| [usernameStyle](#usernamestyle-string-) | Limit username field to accept only "username" values or only "email" values |
+| [signUpFieldsStrictValidation](#signUpFieldsStrictValidation-boolean-) | Strict format validation for username and email fields at signup |
+
+## Enterprise
+
+| Option | Description |
+| --- | --- |
+| [defaultEnterpriseConnection](#defaultenterpriseconnection-string-) | Specifies a connection if more than one present |
+
+## Passwordless
+
+| Option | Description |
+| --- | --- |
+| [passwordlessMethod](#passwordlessmethod-string-) | When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user |
+
+### Other
+
+| Option | Description |
+| --- | --- |
+| [configurationBaseUrl](#configurationbaseurl-string-) | Override your application's base URL |
+| [languageBaseUrl](#languagebaseurl-string-) | Override your language file base URL |
+| [hashCleanup](#hashcleanup-boolean-) | Override the default removal of the hash from the URL |
+| [connectionResolver](#connectionresolver-function-) | Optional callback function for choosing a connection based on the username information |
+
+---
+
+## UI Options
+
+### allowAutocomplete {Boolean}
+
+Determines whether or not the email or username fields will allow autocomplete (``). Defaults to `false`.
+
+```js
+var options = {
+  allowAutocomplete: true
+};
+```
+
+### allowPasswordAutocomplete {Boolean}
+
+Determines whether or not the password field will allow autocomplete (``). Defaults to `false`.
+
+Set `allowPasswordAutocomplete` to `true` for password manager support and to avoid other cases of adverse behavior.
+
+```js
+var options = {
+  allowPasswordAutocomplete: true
+};
+```
+
+### allowShowPassword {Boolean}
+
+This option determines whether or not to add a checkbox to the UI which, when selected, will allow the user to show their password when typing it. The option defaults to `false`.
+
+```js
+var options = {
+  allowShowPassword: true
+};
+```
+
+Lock with `allowShowPassword` set to `true` and toggled to show the password:
+
+![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png)
+
+### allowedConnections {Array}
+
+Array of connections that will be used for the `signin|signup|reset` actions. Defaults to all enabled connections.
+
+```js
+// The following will only display
+// username and password sign in form
+var options = {
+  allowedConnections: ['Username-Password-Authentication']
+};
+
+// ... social connections only
+var options = {
+  allowedConnections: ['twitter', 'facebook', 'linkedin']
+};
+
+// ... enterprise connections only
+var options = {
+  allowedConnections: ['qraftlabs.com']
+};
+```
+
+Examples of `allowedConnections`:
+
+![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png)
+
+![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png)
+
+### autoclose {Boolean}
+
+Determines whether or not the Lock will be closed automatically after a successful sign in. Defaults to false.
+
+::: note
+If the Lock is not `closable` it won't be closed, even if this option is set to true.
+:::
+
+```js
+var options = {
+  autoclose: true
+};
+```
+
+### autofocus {Boolean}
+
+If true, the focus is set to the first field on the widget. Defaults to `false` when being rendered on a mobile device, or if a `container` option is provided; defaults to `true` in all other cases.
+
+```js
+var options = {
+  autofocus: false
+};
+```
+
+### avatar {Object}
+
+By default, Gravatar is used to fetch the user avatar and display name, but you can obtain them from anywhere with the `avatar` option.
+
+```js
+var options = {
+  avatar: {
+    url: function(email, cb) {
+      // Obtain the avatar url for the email input by the user, Lock
+      // will preload the image before displaying it.
+      // Note that in case of an error you call cb with the error in
+      // the first arg instead of `null`.
+      var url = obtainAvatarUrl(email);
+      cb(null, url);
+    },
+    displayName: function(email, cb) {
+      // Obtain the display name for the email input by the user.
+      // Note that in case of an error you call cb with the error in
+      // the first arg instead of `null`.
+      var displayName = obtainDisplayName(email);
+      cb(null, displayName);
+    }
+  }
+};
+```
+
+Or, if you want to display no avatar at all, simply pass in `null`.
+
+```js
+var options = {
+  avatar: null
+};
+```
+
+Default behavior with Gravatar:
+
+![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-avatar.png)
+
+### closable {Boolean}
+
+Determines whether or not the Lock can be closed. When a `container` option is provided its value is always `false`, otherwise it defaults to `true`.
+
+```js
+var options = {
+  closable: false
+};
+```
+
+![Lock - Closable](/media/articles/libraries/lock/v11/customization/lock-closable.png)
+
+### container {String}
+
+The `id` of the html element where the widget will be shown.
+
+This makes the widget appear inline within your `div` instead of in a modal pop-out window.
+
+```html
+
    
+
+
+```
+
+![Lock - Container](/media/articles/libraries/lock/v11/customization/lock-container.png)
+
+### flashMessage {Object}
+
+Shows an `error` or `success` flash message when Lock is shown. This object has the following properties:
+
+- type {String}: The message type, supported types are `error`, `info`, and `success`
+- text {String}: The text to show.
+
+```js
+var options = {
+  flashMessage: {
+    type: 'success',
+    text: 'Welcome!'
+  }
+};
+```
+
+### language {String}
+
+Specifies the language of the widget. Defaults to "en". See the [internationalization directory](https://github.com/auth0/lock/blob/master/src/i18n/) for a current list of provided languages.
+
+```js
+// select a supported language
+var options = {
+  language: 'es'
+};
+```
+
+![Lock - Language](/media/articles/libraries/lock/v11/customization/lock-language.png)
+
+### languageDictionary {Object}
+
+Allows customization of every piece of text displayed in the Lock. Defaults to {}. See English language [Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) for the full list of `languageDictionary` values able to be altered with this object.
+
+```js
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+```
+
+![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png)
+
+Additionally, check out the [Customizing Error Messages](/libraries/lock/v11/customizing-error-messages) page or the [Internationalization](/libraries/lock/v11/i18n) page for more information about the use of the `languageDictionary` option.
+
+### popupOptions {Object}
+
+Allows the customization the location of the popup in the screen. Any position and size feature allowed by window.open is accepted. Defaults to {}.
+
+Options for the `window.open` [position and size][windowopen-link] features. This only applies if `redirect` is set to `false`.
+
+```js
+var options = {
+  auth: {
+      redirect: false
+  },
+  popupOptions: { width: 300, height: 400, left: 200, top: 300 }
+};
+```
+
+### rememberLastLogin {Boolean}
+
+Determines whether or not to show a screen that allows you to quickly log in with the account you used the last time.
+Requests Single Sign-on (SSO) data and enables a **Last time you signed in with[...]** message. Defaults to `true`. This information comes from the user's Auth0 session, so this ability will last as long as their Auth0 session would (which is [configurable](/dashboard/reference/settings-tenant#login-session-management).
+
+```js
+var options = {
+  rememberLastLogin: false
+};
+```
+::: note
+New tenants [automatically have Seamless SSO enabled](https://auth0.com/docs/dashboard/guides/tenants/enable-sso-tenant). With this enabled, the `rememberLastLogin` option will not be relevant because if there is a session in place then the hosted login page will not be displayed at all. Using Seamless SSO is highly recommended because it provides a seamless authentication experience: users log in once and won’t have to enter credentials again when they navigate either through the applications you have built, or third party apps. If the user is not logged in they will be redirected to the login screen, as expected.
+:::
+
+::: note
+The **Last time you signed in with [...]** message will not be available under the following circumstances:
+
+- You used Lock in a [Hosted Login Page](/universal-login) with the session established using [Passwordless authentication](/connections/passwordless).
+- You used Lock in an [embedded login scenario](/guides/login/universal-vs-embedded#embedded-login-with-auth0) where `responseType: code` (indicating the [Authorization Code Flow](/flows/concepts/auth-code), which is used for Regular Web Apps).
+:::
+
+### scrollGlobalMessagesIntoView {Boolean}
+
+Determines whether or not a `globalMessage` should be scrolled into the user's viewport. Defaults to `true`.
+
+## Theme Options
+
+Theme options are grouped in the `theme` property of the `options` object.
+
+```js
+var options = {
+  theme: {
+    labeledSubmitButton: false,
+    logo: "https://example.com/assets/logo.png",
+    primaryColor: "green",
+    authButtons: {
+      connectionName: {
+        displayName: "...",
+        primaryColor: "...",
+        foregroundColor: "...",
+        icon: "https://.../logo.png"
+      }
+    }
+  }
+};
+```
+
+### authButtons {Object}
+
+Allows the customization of buttons in Lock with custom OAuth2 connections. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below:
+
+- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login).
+- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`.
+- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`.
+- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`.
+
+```js
+var options = {
+  theme: {
+    authButtons: {
+      "testConnection": {
+        displayName: "Test Conn",
+        primaryColor: "#b7b7b7",
+        foregroundColor: "#000000",
+        icon: "http://example.com/icon.png"
+      },
+      "testConnection2": {
+        primaryColor: "#000000",
+        foregroundColor: "#ffffff",
+      }
+    }
+  }
+};
+```
+
+### labeledSubmitButton {Boolean}
+
+This option indicates whether or not the submit button should have a label, and defaults to `true`. When set to `false`, an icon will be shown instead.
+
+```js
+var options = {
+  theme: {
+    labeledSubmitButton: false
+  }
+};
+```
+
+![Lock - Labeled Submit Button](/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png)
+
+If the label is set to true, which is the default, the label's text can be customized through the [languageDictionary](#languagedictionary-object-) option.
+
+### logo {String}
+
+The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png'
+  }
+};
+```
+
+![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png)
+
+### primaryColor {String}
+
+The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png',
+    primaryColor: '#31324F'
+  }
+};
+```
+
+![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png)
+
+## Authentication Options
+
+Authentication options are grouped in the `auth` property of the `options` object.
+
+The default scope used by Lock is `openid profile email`.
+
+```js
+var options = {
+  auth: {
+   params: {
+    param1: "value1",
+    scope: "openid profile email"
+   },
+   autoParseHash: true,
+   redirect: true,
+   redirectUrl: "some url",
+   responseMode: "form_post",
+   responseType: "token",
+   sso: true,
+   connectionScopes: {
+    connectionName: [ 'scope1', 'scope2' ]
+   }
+  }
+};
+```
+
+### audience {String}
+
+The `audience` option indicates the API which will be consuming the Access Token that is received after authentication.
+
+```js
+var options = {
+  auth: {
+    audience: 'https://${account.namespace}/userinfo',
+  }
+}
+```
+
+### autoParseHash {Boolean}
+
+When `autoParseHash` is set to `true`, Lock will parse the `window.location.hash` string when instantiated. If set to `false`, you'll have to manually resume authentication using the [resumeAuth](/libraries/lock/v11/api#resumeauth-) method.
+
+```js
+var options = {
+  auth: {
+    autoParseHash: false
+  }
+};
+```
+
+### connectionScopes {Object}
+
+This option allows you to set scopes to be sent to the oauth2/social connection for authentication.
+
+```js
+var options = {
+  auth: {
+    connectionScopes: {
+      'facebook': ['scope1', 'scope2']
+    }
+  }
+};
+```
+
+A listing of particular scopes for your social connections can be acquired from the provider in question. For example, [Facebook for Developers](https://developers.facebook.com/docs/facebook-login/permissions/) reference has a listing of separate permissions that can be requested for your connection.
+
+### params {Object}
+
+You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `foo` and also adds a `scope` parameter (which includes the scope, and then the requested attributes). [Read here][authparams-link] to learn more about what `authParams` can be set.
+
+```js
+var options = {
+  auth: {
+    params: {
+      state: 'foo',
+      scope: 'openid email user_metadata app_metadata picture'
+    }
+  }
+};
+```
+
+::: note
+For more details about supported parameters check the [Authentication Parameters][authparams-link] documentation page.
+:::
+
+### redirect {Boolean}
+
+Defaults to true. When set to true, redirect mode will be used. If set to false, [popup mode](/libraries/lock/v11/authentication-modes#popup-mode) is chosen.
+
+```js
+var options = {
+  auth: {
+    redirect: false
+  }
+};
+```
+
+### redirectUrl {String}
+
+The URL Auth0 will redirect back to after authentication. Defaults to the empty string "" (no redirect URL).
+
+```js
+var options = {
+  auth: {
+    redirectUrl: 'http://testurl.com'
+  }
+};
+```
+
+::: note
+When the `redirectUrl` is provided (set to non blank value) the `responseType` option will be defaulted to `code` if not manually set.
+:::
+
+### responseMode {String}
+
+Should be set to `"form_post"` if you want the code or the token to be transmitted via an HTTP POST request to the `redirectUrl`, instead of being included in its query or fragment parts.
+
+Otherwise, this option should be omitted, and is omitted by default.
+
+```js
+var options = {
+  auth: {
+    responseMode: 'form_post'
+  }
+};
+```
+
+### responseType {String}
+
+The value of `responseType` should be set to "token" for Single-Page Applications, and "code" otherwise. Defaults to "code" when redirectUrl is provided, and to "token" otherwise.
+
+```js
+var options = {
+  auth: {
+    responseType: 'token'
+  }
+};
+```
+
+::: note
+When the `responseType` is set to `code`, Lock will never show the **Last time you logged in with** message, and will always prompt the user for credentials.
+:::
+
+## Database Options
+
+### additionalSignUpFields {Array}
+
+Extra input fields can be added to the sign up screen with the `additionalSignUpFields` option. Each option added in this manner will then be added to that user's `user_metadata`. See [Metadata](/users/concepts/overview-user-metadata) for more information. Every input must have a `name` and a `placeholder`, and an `icon` URL can also be provided. Also, the initial value can be provided with the `prefill` option, which can be a string with the value or a function that obtains it. Other options depend on the type of the field, which is defined via the type option and defaults to "text".
+
+::: panel Intended for use with database signup only
+`additionalSignUpFields` are intended for use with database signups only. If you have social sign ups too, you can ask for the additional information after the users sign up (see this [page about custom signup](/libraries/custom-signup) for more details). You can use the `databaseAlternativeSignupInstructions` i18n key to display these instructions.
+:::
+
+The new fields are rendered below the regular sign up input fields in the order they are provided.
+
+#### Text Fields
+
+Text fields are the default type of additional signup field. Note that a `validator` function can also be provided.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "address",
+    placeholder: "enter your address",
+    // The following properties are optional
+    icon: "https://example.com/assests/address_icon.png",
+    prefill: "street 123",
+    validator: function(address) {
+      return {
+         valid: address.length >= 10,
+         hint: "Must have 10 or more chars" // optional
+      };
+    }
+  },
+  {
+    name: "full_name",
+    placeholder: "Enter your full name"
+  }]
+}
+```
+
+If you don't specify a `validator` the text field will be **required**. If you want to make the text field optional, use a validator that always returns `true` like this:
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "favorite_color",
+    placeholder: "Enter your favorite color (optional)",
+    validator: function() { 
+      return true;
+    }
+  }]
+}
+```
+
+If you want to save the value of the attribute in the root of your profile, use `storage: 'root'`. Only a subset of values can be stored this way. The list of attributes that can be added to your root profile is [here](/api/management/v2#!/Users/patch_users_by_id). By default, every additional sign up field is stored inside the user_metadata object.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "name",
+    storage: "root"
+  }]
+};
+```
+
+![Lock - Additional Signup Fields](/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png)
+
+#### Select Field
+
+The signup field `type: "select"` will allow you to use select elements for the user to choose a value from.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "select",
+    name: "location",
+    placeholder: "choose your location",
+    options: [
+      {value: "us", label: "United States"},
+      {value: "fr", label: "France"},
+      {value: "ar", label: "Argentina"}
+    ],
+    // The following properties are optional
+    icon: "https://example.com/assests/location_icon.png",
+    prefill: "us"
+  }]
+}
+```
+
+The `options` array items for `select` fields must adhere to the following format:
+`{label: “non empty string”, value: “non empty string”}`, and at least one option must be defined.
+
+The `options` and `prefill` values can be provided through a function:
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "select",
+    name: "location",
+    placeholder: "choose your location",
+    options: function(cb) {
+      // obtain options, in case of error you call cb with the error in the
+      // first arg instead of null
+      cb(null, options);
+    },
+    icon: "https://example.com/assests/location_icon.png",
+    prefill: function(cb) {
+      // obtain prefill, in case of error you call cb with the error in the
+      // first arg instead of null
+      cb(null, prefill);
+    }
+  }]
+}
+```
+
+#### Checkbox Field
+
+The third type of custom signup field is the `type: "checkbox"`. The `prefill` value can determine the default state of the checkbox (`true` or `false`), and it is required.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "checkbox",
+    name: "newsletter",
+    prefill: "true",
+    placeholder: "I hereby agree that I want to receive marketing emails from your company"
+  }]
+}
+```
+
+#### Hidden field
+
+The signup field `type: "hidden"` will allow you to use a hidden input with a fixed value.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "hidden",
+    name: "signup_code",
+    value: "abc123"
+  }]
+}
+```
+
+::: note
+Some use cases may be able to use `additionalSignUpFields` data for email templates, such as an option for language preferences, the value of which could then be used to set the language of templated email communications.
+:::
+
+### allowLogin {Boolean}
+
+When set to `false` the widget won't display the login screen. This is useful if you want to use the widget just for signups (the login and signup tabs in the signup screen will be hidden) or to reset passwords (the back button in the forgot password screen will be hidden). In such cases you may also need to specify the `initialScreen`, `allowForgotPassword` and `allowSignUp` options. It defaults to `true`.
+
+```js
+//
+var options = {
+  allowLogin: false
+};
+```
+
+![Lock - Allow Login](/media/articles/libraries/lock/v11/customization/lock-allowlogin.png)
+
+### allowForgotPassword {Boolean}
+
+When set to false, `allowForgotPassword` hides the "Don't remember your password?" link in the Login screen, making the Forgot Password screen unreachable. Defaults to true.
+
+::: note
+Keep in mind that if you are using a database connection with a custom database which doesn't have a change password script the Forgot Password screen won't be available.
+:::
+
+```js
+//
+var options = {
+  allowForgotPassword: false
+};
+```
+
+![Lock - Allow Forgot Password](/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png)
+
+### allowSignUp {Boolean}
+
+When set to `false`, hides the login and sign up tabs in the login screen, making the sign up screen unreachable. Defaults to `true`. Keep in mind that if the database connection has sign ups disabled or you are using a custom database which doesn't have a create script, then the sign up screen won't be available.
+
+Also bear in mind that this option **only** controls client-side appearance, and does not completely stop new sign ups from determined anonymous visitors. If you are looking to fully prevent new users from signing up, you must use the **Disable Sign Ups** option in the dashboard, in the connection settings.
+
+```js
+var options = {
+  allowSignUp: false
+};
+```
+
+![Lock - Social Button Style](/media/articles/libraries/lock/v11/customization/lock-allowsignup.png)
+
+### defaultDatabaseConnection {String}
+
+Specifies the database connection that will be used when there is more than one available.
+
+```js
+var options = {
+  defaultDatabaseConnection: 'test-database'
+};
+```
+
+### initialScreen {String}
+
+The name of the screen that will be shown when the widget is opened. Valid values are `login`, `signUp`, and `forgotPassword`. If this option is left unspecified, the widget will default to the first screen that is available from that list.
+
+```js
+var options = {
+  initialScreen: 'forgotPassword'
+};
+```
+
+### loginAfterSignUp {Boolean}
+
+Determines whether or not the user will be automatically signed in after a successful sign up. Defaults to `true`.
+
+```js
+var options = {
+  loginAfterSignUp: false
+};
+```
+
+### forgotPasswordLink {String}
+
+Set the URL for a page that allows the user to reset their password. When set to a non-empty string, the user will be sent to the provided URL when clicking the "Don't remember your password?" link in the login screen.
+
+```js
+var options = {
+  forgotPasswordLink: 'https://yoursite.com/reset-password'
+};
+```
+
+### showTerms {Boolean}
+
+When set to `true` displays the `languageDictionary.signUpTerms` string. Defaults to `true`.
+
+### mustAcceptTerms {Boolean}
+
+When set to `true` displays a checkbox input alongside the terms and conditions that must be checked before signing up. The terms and conditions can be specified via the `languageDictionary` option. This option will only take effect for users signing up with database connections. Defaults to `false`.
+
+```js
+var options = {
+  mustAcceptTerms: true
+};
+```
+
+### prefill {Object}
+
+Allows to set the initial value for the email and/or username inputs. When omitted, no initial value will be provided.
+
+```js
+var options = {
+  prefill: {
+    email: "someone@auth0.com",
+    username: "someone",
+    phoneNumber: "+1234567890"
+  }
+};
+```
+
+### signUpLink {String}
+
+Set the URL to be requested when clicking on the Signup button.
+
+::: panel Side effects
+When set to a non empty string, this option forces `allowSignUp` to `true`.
+:::
+
+```js
+var options = {
+  signUpLink: 'https://yoursite.com/signup'
+};
+```
+
+### usernameStyle {String}
+
+Determines what will be used to identify the user for a Database connection that has the `requires_username` flag set (if it is not set, `usernameStyle` option will be ignored). Possible values are `"username"` and `"email"`. By default both `username` and `email` are allowed; setting this option will limit logins to use one or the other.
+
+```js
+var options = {
+  // Limits logins to usernames only, not emails
+  usernameStyle: 'username'
+};
+```
+
+### signUpFieldsStrictValidation {Boolean}
+
+This option enables strict format validation for username and email fields at the signup screen. This ensures presenting validation errors instead of the generic "We're sorry, something went wrong when attempting to sign up." message. Defaults to `false`.
+
+```js
+var options = {
+  signUpFieldsStrictValidation: true
+};
+```
+
+## Enterprise Options
+
+### defaultEnterpriseConnection {String}
+
+Specifies the enterprise connection which allows to login using a username and a password that will be used when there is more than one available or there is a database connection. If a `defaultDatabaseConnection` is provided the database connection will be used and this option will be ignored.
+
+```js
+var options = {
+  defaultEnterpriseConnection: 'test-database'
+};
+```
+
+### defaultADUsernameFromEmailPrefix {Boolean}
+
+Resolve the AD placeholder username from the email's prefix. Defaults to `true`.
+
+```js
+var options = {
+  defaultADUsernameFromEmailPrefix: false
+};
+```
+
+## Passwordless Options
+
+### passwordlessMethod {String}
+
+When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user. Available values for email connections are `code` and `link`. Defaults to `code`. SMS passwordless connections will always use `code`.
+
+## Other Options
+
+### configurationBaseUrl {String}
+
+This option can provide a URL to override the application settings base URL. By default, it uses Auth0's CDN URL when the domain has the format `*.auth0.com`. For example, if your URL is `contoso.eu.auth0.com`, then by default, the `clientBaseUrl` is `cdn.eu.auth0.com`. If the `clientBaseUrl` option is set to something else instead, it uses the provided domain. This would only be necessary if your specific use case dictates that your application not use the default behavior.
+
+```js
+var options = {
+  clientBaseUrl: "https://www.example.com"
+};
+```
+
+### languageBaseUrl {String}
+
+Overrides the language source url for Auth0's provided translations. By default, this option uses Auth0's CDN URL `https://cdn.auth0.com` since this is where all of the provided translations are stored. By providing another value, you can use another source for the language translations if needed.
+
+```js
+var options = {
+  languageBaseUrl: "https://www.example.com"
+};
+```
+
+### hashCleanup {Boolean}
+
+When the `hashCleanup` option is enabled, it will remove the hash part of the callback URL after the user authentication. It defaults to true.
+
+```js
+var options = {
+  hashCleanup: false
+};
+```
+
+### connectionResolver {Function}
+
+When in use, provides an extensibility point to make it possible to choose which connection to use based on the username information.
+
+Has `username`, `context`, and `callback` as parameters. The callback expects an object like: `{type: 'database', name: 'connection name'}`. **This only works for database connections.** Keep in mind that this resolver will run in the form's `onSubmit` event, so keep it simple and fast.
+
+This is a beta feature. If you find a bug, please open a GitHub [issue](https://github.com/auth0/lock/issues/new).
+
+### leeway {Integer}
+
+The `leeway` option can be set to an integer - a value in seconds - which can be used to account for clock skew in ID Token expirations. Typically the value is no more than a minute or two at maximum.
+
+```js
+var options = {
+  leeway: 30
+};
+```
+
+
+
+[authparams-link]: /libraries/lock/v11/sending-authentication-parameters
+[windowopen-link]: https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Position_and_size_features
diff --git a/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md b/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md
new file mode 100644
index 0000000000..1d06250ce5
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md
@@ -0,0 +1,50 @@
+---
+section: libraries
+description: Customizing error messages with Lock v11
+topics:
+  - libraries
+  - lock
+  - error-messages
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Customizing Lock Error Messages
+
+You can customize the error messages that will be displayed in certain situations by providing a [languageDictionary option](/libraries/lock/v11/configuration#languagedictionary-object-). A full listing of available `languageDictionary` fields to customize can be found in the GitHub repository's [English Dictionary file for Lock v11](https://github.com/auth0/lock/blob/master/src/i18n/en.js). Below is an example of some customized error messages:
+
+```js
+// Examples of customized error messages in the languageDictionary option
+var options = {
+  languageDictionary: {
+    error: {
+      login: {
+        "lock.invalid_email_password": "Custom message about invalid credentials",
+        "lock.network": "Custom message indicating a network error and suggesting the user check connection",
+        "lock.unauthorized": "Custom message about a failure of permissions",
+        "too_many_attempts": "Custom message indicating the user has failed to login too many times."
+      },
+      signUp: {
+        "invalid_password": "Custom message indicating a password was invalid",
+        "user_exists": "Custom message indicating that a user already exists"
+      }
+    }
+  }
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+## Custom errors in Rules
+
+If you are returning custom error codes from a [rule](/rules) or a [custom database script](/connections/database/custom-db#error-handling), you can handle custom errors:
+
+* In your application's redirect URL by reading the `error` and `error_mesage` query string parameters.
+* By redirecting the user back to your hosted pages with a custom error message and displaying the message with a [flash message](/libraries/lock/v11/api#flashmessage).
diff --git a/ja-jp/articles/libraries/lock/v11/i18n.md b/ja-jp/articles/libraries/lock/v11/i18n.md
new file mode 100644
index 0000000000..cdd35c7c3e
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/i18n.md
@@ -0,0 +1,116 @@
+---
+section: libraries
+description: Lock v11 supports multiple languages, and allows for the addition of other custom language files, as well as for customizing the values of specific pieces of text that are displayed in the Lock widget.
+topics:
+  - libraries
+  - lock
+  - i18n
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+---
+# Lock Internationalization
+
+You can change the language of Lock by using the `language` configuration option. This will pull the corresponding language file from the `i18n` directory in Lock.
+
+## Provided languages
+
+Take a look at the [i18n directory](https://github.com/auth0/lock/blob/master/src/i18n/) for language files.
+
+| Language | Code | Source |
+|----------|------|--------|
+| Afrikaans | `'af'` | [af.js](https://github.com/auth0/lock/blob/master/src/i18n/af.js) |
+| Catalan | `'ca'` | [ca.js](https://github.com/auth0/lock/blob/master/src/i18n/ca.js) |
+| Chinese | `'zh'` | [zh.js](https://github.com/auth0/lock/blob/master/src/i18n/zh.js) |
+| Chinese (Taiwan) | `'zh-tw'` | [zh-tw.js](https://github.com/auth0/lock/blob/master/src/i18n/zh-tw.js) |
+| Croatian | `'hr'` | [hr.js](https://github.com/auth0/lock/blob/master/src/i18n/hr.js) |
+| Czech | `'cs'` | [cs.js](https://github.com/auth0/lock/blob/master/src/i18n/cs.js) |
+| Danish | `'da'` | [da.js](https://github.com/auth0/lock/blob/master/src/i18n/da.js) |
+| Dutch | `'nl'` | [nl.js](https://github.com/auth0/lock/blob/master/src/i18n/nl.js) |
+| English | `'en'` | [en.js](https://github.com/auth0/lock/blob/master/src/i18n/en.js) |
+| Estonian | `'et'` | [et.js](https://github.com/auth0/lock/blob/master/src/i18n/et.js) |
+| Farsi (Persian) | `'fa'` | [fa.js](https://github.com/auth0/lock/blob/master/src/i18n/fa.js) |
+| Finnish | `'fi'` | [fi.js](https://github.com/auth0/lock/blob/master/src/i18n/fi.js) |
+| French | `'fr'` | [fr.js](https://github.com/auth0/lock/blob/master/src/i18n/fr.js) |
+| German | `'de'` | [de.js](https://github.com/auth0/lock/blob/master/src/i18n/de.js) |
+| Greek | `'el` | [el.js](https://github.com/auth0/lock/blob/master/src/i18n/el.js) |
+| Hebrew | `'he'` | [he.js](https://github.com/auth0/lock/blob/master/src/i18n/he.js) |
+| Hungarian | `'hu'` | [hu.js](https://github.com/auth0/lock/blob/master/src/i18n/hu.js) |
+| Italian | `'it'` | [it.js](https://github.com/auth0/lock/blob/master/src/i18n/it.js) |
+| Japanese | `'ja'` | [ja.js](https://github.com/auth0/lock/blob/master/src/i18n/ja.js) |
+| Korean | `'ko'` | [ko.js](https://github.com/auth0/lock/blob/master/src/i18n/ko.js) |
+| Lithuanian | `'lt'` | [lt.js](https://github.com/auth0/lock/blob/master/src/i18n/lt.js) |
+| Norwegian | `'no'` | [no.js](https://github.com/auth0/lock/blob/master/src/i18n/no.js) |
+| Norwegian (Bokmål) | `'nb'` | [nb.js](https://github.com/auth0/lock/blob/master/src/i18n/nb.js) |
+| Norwegian (Nynorsk) | `'nn'` | [nn.js](https://github.com/auth0/lock/blob/master/src/i18n/nn.js) |
+| Polish | `'pl'` | [pl.js](https://github.com/auth0/lock/blob/master/src/i18n/pl.js) |
+| Portuguese (Brazil) | `'pt-br'` | [pt-br.js](https://github.com/auth0/lock/blob/master/src/i18n/pt-br.js) |
+| Romanian | `'ro'` | [ro.js](https://github.com/auth0/lock/blob/master/src/i18n/ro.js) |
+| Russian | `'ru'` | [ru.js](https://github.com/auth0/lock/blob/master/src/i18n/ru.js) |
+| Slovak | `'sk'` | [sk.js](https://github.com/auth0/lock/blob/master/src/i18n/sk.js) |
+| Slovenian | `'sl'` | [sl.js](https://github.com/auth0/lock/blob/master/src/i18n/sl.js) |
+| Spanish | `'es'` | [es.js](https://github.com/auth0/lock/blob/master/src/i18n/es.js) |
+| Swedish | `'sv'` | [sv.js](https://github.com/auth0/lock/blob/master/src/i18n/sv.js) |
+| Turkish | `'tr'` | [tr.js](https://github.com/auth0/lock/blob/master/src/i18n/tr.js) |
+| Ukrainian | `'ua'` | [ua.js](https://github.com/auth0/lock/blob/master/src/i18n/uk.js) |
+| Vietnamese | `'vi'` | [vi.js](https://github.com/auth0/lock/blob/master/src/i18n/vi.js) |
+
+## Set language option
+
+To use the following examples, you'll need to first include Lock in your page:
+
+```html
+
+
+```
+
+Next define your `options` object and include the `language` option. The `language` option needs to be a string matching the name of the corresponding file in the `i18n` directory [within Lock](https://github.com/auth0/lock/tree/master/src/i18n). Then instantiate Lock.
+
+For example,
+
+```js
+// Select a supported language
+var options = {
+  language: 'es'
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+::: panel Missing translation values
+Translation data for Lock comes from language files which have key-value pairs representing various translations. For some languages, certain values may be missing, in which case you will see a warning: `language does not have property `. We encourage you to submit a [pull request](https://github.com/auth0/lock/tree/master/src/i18n) to add these missing values. Alternatively, you may define the missing values in your Lock `options` (see below).
+:::
+
+## Replace dictionary terms
+
+You can also customize your own specific dictionary items using the `languageDictionary` option. This is useful if you are using one of the supported languages, but change the specific wording of a few items. For example, you might re-word the `title` or change the way other labels display to the user while leaving the remaining text on the widget intact.
+
+```js
+// Customize some languageDictionary attributes
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+::: note
+For an example of available `languageDictionary` property names and how to structure a `language` file, see the [English dictionary file for Lock](https://github.com/auth0/lock/blob/master/src/i18n/en.js).
+:::
+
+The `languageBaseUrl` option, which takes a string value (a URL), overrides the language source URL for Auth0's provided translations. By default, it uses the Auth0's CDN URL `https://cdn.auth0.com` because that is where the provided language translations are stored. By providing another value, you can use your own source for the language translations as needed for your applications. Your language source should be a JavaScript file.
diff --git a/ja-jp/articles/libraries/lock/v11/index.md b/ja-jp/articles/libraries/lock/v11/index.md
new file mode 100644
index 0000000000..babcef08a8
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/index.md
@@ -0,0 +1,250 @@
+---
+section: libraries
+toc: true
+title: Lock v11 for Web
+description: A widget that provides a frictionless login and signup experience for your web apps.
+img: media/articles/libraries/lock-web.png
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - index
+useCase:
+  - add-login
+---
+# Lock v11 for Web
+
+Lock is an embeddable login form that can be [configured to your needs](/libraries/lock/v11/configuration) and is recommended for use in single-page apps, preferably in conjunction with [Universal Login](/universal-login), which should be used whenever possible. Lock enables you to easily add social identity providers, so that your users can log in seamlessly using any desired provider.
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Lock Installation
+
+You can install Lock v11 via several methods. Select any of the following installation sources that best suit your environment and application.
+
+### Installation Sources
+
+Install via [npm](https://npmjs.org):
+
+```sh
+npm install auth0-lock
+```
+
+Install via [bower](http://bower.io):
+
+```sh
+bower install auth0-lock
+```
+
+Include via our CDN (Replace `.x` and `.y` with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock/releases):
+
+```html
+
+
+
+
+
+```
+
+::: panel Updating patch versions
+It is recommended that production applications use a specific patch version, or at the very least a specific minor version. Regardless of the method by which Lock is included, the recommendation is that the version should be locked down and only manually updated, to ensure that those updates do not adversely affect your implementation. Check the [GitHub repository](https://github.com/auth0/lock/releases) for a current list of releases.
+:::
+
+### Mobile
+
+If you are targeting mobile audiences, Auth0 recommends that you add the following meta tag to your application's `head`:
+
+```html
+
+```
+
+### Bundling Dependencies
+
+If you are using browserify or webpack to build your project and bundle its dependencies, after installing the `auth0-lock` module, you will need to bundle it with all its dependencies. Examples are available for [Browserify](https://github.com/auth0/lock/tree/master/examples/bundling/browserify) and [webpack](https://github.com/auth0/lock/tree/master/examples/bundling/webpack).
+
+### Cross-Origin Authentication
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+Embedding Lock within your application requires [cross-origin authentication](/cross-origin-authentication) to be properly configured. Specifically, you need to set the **Allowed Web Origins** property to the domain making the request. You can find this field in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+![Allowed Web Origins](/media/articles/libraries/lock/allowed-origins.png)
+
+Make sure you read about the [limitations of cross-origin authentication](/cross-origin-authentication#limitations) before implementing Lock. 
+
+## Usage
+
+### 1. Initializing Lock
+
+First, you'll need to initialize a new `Auth0Lock` object, and provide it with your Auth0 client ID (the unique client ID for each Auth0 application, which you can get from the [management dashboard](${manage_url})) and your Auth0 domain (for example, `yourname.auth0.com`).
+
+```js
+// Initializing our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}'
+);
+```
+
+### 2. Authenticating and Getting User Info
+
+Next, listen using the `on` method for the `authenticated` event. When the event occurs, use the `accessToken` which was received to call the `getUserInfo` method and acquire the user's profile information (as needed).
+
+```js
+var Auth = (function() {
+
+  var wm = new WeakMap();
+  var privateStore = {};
+  var lock;
+
+  function Auth() {
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+    wm.set(privateStore, {
+      appName: "example"
+    });
+  }
+
+  Auth.prototype.getProfile = function() {
+    return wm.get(privateStore).profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+
+        //we recommend not storing Access Tokens unless absolutely necessary
+        wm.set(privateStore, {
+          accessToken: authResult.accessToken
+        });
+
+        wm.set(privateStore, {
+          profile: profile
+        });
+
+      });
+    });
+  };
+  return Auth;
+}());
+
+```
+
+You can then manipulate page content and display profile information to the user (for example, displaying their name in a welcome message).
+
+```html
+ 
    Welcome 
    
+```
+
+::: note
+Note that if you are storing the user profile, you will want to `JSON.stringify` the profile object and then, when using it later, `JSON.parse` it, because it will need to be stored in `localStorage` as a string rather than a JSON object.
+:::
+
+### 3. Showing Lock
+
+Here you're showing the Lock widget after the user clicks a login button; you can just as easily show Lock automatically when arriving at a page by just using `lock.show();` on page load.
+
+This will show the Lock widget, and paired with the above, you're now ready to handle logins!
+
+```js
+document.getElementById('btn-login').addEventListener('click', function() {
+  lock.show();
+});
+```
+
+## Passwordless
+
+::: note
+Lock's Passwordless Mode is only available in Lock v11.2.0 and later. Please use the [latest release of Lock](https://github.com/auth0/lock/releases) for this feature!
+:::
+
+You can use Lock's Passwordless Mode to allow users to authenticate using just an email or mobile number. They will receive the code and then return to input it, or click the link, and they can be authenticated without remembering a password.
+
+In Lock v11, in order to implement Passwordless Mode, you initialize Lock in a slightly different manner, with `Auth0LockPasswordless` rather than with `Auth0Lock`:
+
+```js
+var lockPasswordless = new Auth0LockPasswordless(
+ '${account.clientId}',
+ '${account.namespace}'
+);
+```
+
+### Passwordless options
+
+Additionally, Lock's Passwordless Mode has a couple of configuration options that are unique to it.
+
+In order to indicate which connection type you would like, you initialize Lock with the `allowedConnections` option with either `email` or `sms` as the value:
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['sms']
+}
+```
+
+::: note
+Remember to enable the passwordless connection of your choice in the [Dashboard](${manage_url}) under **Connections -> Passwordless**, and then to enable it for your application, that way when Lock tries to use it, it is already set up and linked to the application.
+:::
+
+If you choose to use `email`, you have one more option to select - whether you wish your users to receive a code to input, or a "magic link" to use. This is done via the `passwordlessMethod` option, which takes values of `code` or `link`.
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['email'],
+  passwordlessMethod: 'code'
+}
+```
+
+### Passwordless example
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['email'],
+  passwordlessMethod: 'code',
+  auth: {
+    redirectUrl: 'http://localhost:3000/callback',   
+    responseType: 'token id_token',
+    params: {
+      scope: 'openid email'               
+    }          
+  }
+}
+
+var lockPasswordless = new Auth0LockPasswordless(
+ '${account.clientId}',
+ '${account.namespace}',
+ passwordlessOptions
+);
+```
+
+<%= include('../../_includes/_embedded_sso') %>
+
+<%= include('../../../_includes/_co_authenticate_errors', { library : 'Lock v11'}) %>
+
+## Browser Compatibility
+
+Browser compatibility is ensured for **Chrome**, **Safari**, **Firefox** and **IE >= 10**. Auth0 currently uses [zuul](https://github.com/defunctzombie/zuul) along with [Saucelabs](https://saucelabs.com) to run integration tests on each push.
+
+## More Examples
+
+The below widget displays brief examples of implementing Auth0 in several ways: Lock as a modal "popup" widget, Lock embedded inline in a div, Lock Passwordless, a custom UI with [Auth0.js](/libraries/auth0js), and a simple link using the API.
+
+<%= include('../../../_includes/_lock-sdk') %>
+
+## Next Steps
+
+This document has shown how to use Lock 11 within a Single-Page Application (SPA). Take a look at the following resources to see how Lock can be used with other kinds of web apps, or how it can be customized for your needs:
+
+::: next-steps
+* [Lock v11 API Reference](/libraries/lock/v11/api)
+* [Lock Configuration Options](/libraries/lock/v11/configuration)
+* [Lock UI Customization](/libraries/lock/v11/ui-customization)
+:::
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angular.md b/ja-jp/articles/libraries/lock/v11/migration-angular.md
new file mode 100644
index 0000000000..1eb1e5647d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angular.md
@@ -0,0 +1,21 @@
+---
+section: libraries
+title: Migrating Angular applications to Lock v11
+description: How to migrate Angular applications to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular Applications to Lock v11
+
+Angular applications can use Lock directly without any kind of wrapper library.
+
+All Angular applications will be using Lock 10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md
new file mode 100644
index 0000000000..621be6bea3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md
@@ -0,0 +1,53 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v10 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v10 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x applications from Lock v10 to v11
+
+## Migration steps
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+### Update angular-lock
+
+AngularJS (a.k.a. Angular 1.x) applications usually use the [angular-lock package](https://www.npmjs.com/package/angular-lock). To use Lock v11 you need to update to the latest version (3.x).
+
+You can update the angular-lock library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save angular-lock
+ 
+# installation with yarn
+yarn add angular-lock
+```
+
+The script files need to be added to your build system, or added to the project with a script tag.
+
+```html
+
+```
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+<%= include('../../_includes/_oidc_conformant') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md
new file mode 100644
index 0000000000..8152ec0ef0
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md
@@ -0,0 +1,22 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v8 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v8 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x Applications from Lock v8 to v11
+
+Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint. 
+
+You can follow the instructions on [how to migrate Angular 1.x applications from Lock v9 to v11]((/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock 8.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md
new file mode 100644
index 0000000000..6217541cf6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md
@@ -0,0 +1,207 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v9 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v9 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x Applications from Lock v9 to v11
+
+This guide will help you migrating your Angular 1.x application from Lock 9 to Lock v11. 
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+## Add the angular-lock library
+
+Most Angular 1.x apps used the [auth0-angular](https://www.npmjs.com/package/auth0-angular) which is currently deprecated. This guide will use [auth0-lock](https://www.npmjs.com/package/auth0-lock) 3.0 to simplify using Lock v11.
+
+Use npm to uninstall the old library and install the new one.
+
+```
+npm uninstall auth0-angular --save
+npm install angular-lock --save
+```
+
+Then include it in your `index.html` file:
+
+```html
+
+
+```
+
+## Update the app.js file
+
+In your `app.js` file:
+
+* Add `auth0.lock` to your Angular module
+* Inject `lockProvider` in your configuration
+* Initialize a Lock instance in `config()`
+* Inject your authentication service in `run()` and call the method that listens for authentication events (we will implement changes in the authentication service next)
+
+```js
+// app.js
+(function() {
+  'use strict';
+
+  angular
+    .module('app', ['ngRoute', 
+//   'auth0' 
+     'auth0.lock']) // Add auth0.lock
+      .config(config)
+      .run(run);
+
+  config.$inject = [
+    '$locationProvider',
+    '$routeProvider',
+ // 'authProvider',
+    'lockProvider' // Inject lockProvider
+  ];
+
+  function config(
+    $locationProvider,
+    $routeProvider,
+//  authProvider
+    lockProvider // Provide lockProvider
+  ) {
+    $routeProvider
+      .when('/', {
+        controller: 'HomeController',
+        templateUrl: 'app/home/home.html',
+        controllerAs: 'vm'
+      })
+      .otherwise({
+        redirectTo: '/'
+  });
+
+  $locationProvider.hashPrefix('');
+  $locationProvider.html5Mode(true);
+
+  // Configure Auth0 Lock instance
+  // Read more about configuration here:
+  // https://auth0.com/docs/libraries/lock/v11
+  lockProvider.init({
+     domain: '${account.namespace}'),
+     clientID: '${account.clientId}',
+     options: {
+       autoclose: true,
+       auth: {
+         responseType: 'token id_token',
+         audience: 'https://' + '${account.namespace}' + '/userinfo',
+         params: {
+           scope: 'openid profile email'
+         }
+       }
+     }
+   });
+  }
+
+  // Inject authentication service and
+  // run method to handle authentication
+  run.$inject = ['authService'];
+
+  function run(authService) {
+    authService.handleAuthentication();
+  }
+
+}());
+```
+
+## Update the authentication service
+
+If you are using an authentication service, you will need to make a few minor changes there as well. Lock v11 provides events so you can execute functionality when the user is authenticated, when there is an authentication error, and so on. You can read more at the [Lock v11 documentation](/libraries/lock/v11).
+
+```js
+// auth.service.js
+(function() {
+  'use strict';
+
+  angular.module('app').service('authService', authService);
+
+  // Inject 'lock'
+  authService.$inject = ['lock', '$location'];
+
+  function authService(lock, $location) {
+ 
+    function login() {
+      // Display the Lock widget using the
+      // instance initialized in the app.js config
+      lock.show();
+    }
+
+    function logout() {
+      // Remove tokens and expiry time from localStorage
+      localStorage.removeItem('access_token');
+      localStorage.removeItem('id_token');
+      localStorage.removeItem('expires_at');
+      $location.path('/');
+    }
+
+    function handleAuthentication() {
+      // Uncomment if you are not using HTML5Mode
+      // lock.interceptHash();
+
+      lock.on('authenticated', function(authResult) {
+        if (authResult && authResult.accessToken && authResult.idToken) {
+          console.log('Authenticated!', authResult);
+          _setSession(authResult);
+        }
+      });
+      lock.on('authorization_error', function(err) {
+        console.log(err);
+        alert(
+          'Error: ' + err.error + '. Check the console for further details.'
+        );
+      });
+    }
+
+    function _setSession(authResult) {
+      // Set the time that the Access Token will expire
+      var expiresAt = JSON.stringify(
+        authResult.expiresIn * 1000 + new Date().getTime()
+      );
+      // Save tokens and expiration to localStorage
+      localStorage.setItem('access_token', authResult.accessToken);
+      localStorage.setItem('id_token', authResult.idToken);
+      localStorage.setItem('expires_at', expiresAt);
+    }
+
+    function isAuthenticated() {
+      // Check whether the current time is
+      // past the Access Token's expiry time
+      var expiresAt = JSON.parse(localStorage.getItem('expires_at'));
+        return new Date().getTime() < expiresAt;
+    }
+
+    return {
+      login: login,
+      logout: logout,
+      handleAuthentication: handleAuthentication,
+      isAuthenticated: isAuthenticated
+    };
+  }
+})();
+```
+
+::: note
+If you are not using a service, you can implement the `handleAuthentication()` method's functionality in your app's `run()` method, and implement the `login()`, `logout()`, and `_setSession()` functionality in the controller where your login is located.
+:::
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-cordova.md b/ja-jp/articles/libraries/lock/v11/migration-cordova.md
new file mode 100644
index 0000000000..ce7a0e9ef2
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-cordova.md
@@ -0,0 +1,21 @@
+---
+title: Migration from Lock 10 in Cordova Apps
+description: Learn how to migrate from Lock 10 in your Cordova app.
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - cordova
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Migration from Lock in Cordova Applications
+
+For Cordova applications, the only migration path forward at this time is to [migrate to Universal Login](/guides/login/migration-embedded-universal). Embedded Lock will not be supported in Cordova apps going forward, as part of an effort to align Auth0's Cordova support with more stringent standards and security policies.
+
+Instead of updating embedded Lock versions, Cordova apps using Auth0 should instead use the [auth0-cordova](https://github.com/auth0/auth0-cordova) library to initiate Universal Login in Cordova apps. See the [Cordova Quickstart](/quickstart/native/cordova/01-login) for an example of setting this up.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-guide.md b/ja-jp/articles/libraries/lock/v11/migration-guide.md
new file mode 100644
index 0000000000..a815c11a66
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-guide.md
@@ -0,0 +1,68 @@
+---
+section: libraries
+title: Migrating to Lock v11
+description: How to migrate to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+  - reference
+  - concept
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating to Lock v11
+
+[Lock v11](/libraries/lock) operates with enhanced security and removes dependencies that have been deprecated as per Auth0's roadmap. In some cases, these security enhancements may impact application behavior when upgrading from an earlier version of Lock. 
+
+## Should I migrate to v11?
+
+Everyone should migrate to v11. All previous versions are deprecated, and the Legacy Lock API was removed from service on August 6, 2018. For applications that use Lock within an Auth0 login page, this migration is recommended; for applications with Lock embedded within them, this migration is mandatory.
+
+## Migration instructions
+
+The documents below describe all the changes that you should be aware of when migrating from different versions of Lock. Make sure you go through the relevant guide(s) before upgrading.
+
+* [Migrating from the lock-passwordless widget](/libraries/lock/v11/migration-lock-passwordless)
+* [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11)
+* [Recommendations for migrating from Lock v10 when Single Sign-on (SSO) is required](/guides/login/migration-sso)
+* [Migrating from Lock v10 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v10)
+* [Migrating from Lock v10 in Angular 2+ Applications](/libraries/lock/v11/migration-angular)
+* [Migrating from Lock v10 in React Applications](/libraries/lock/v11/migration-react)
+* [Migrating from Lock v10 in Cordova Applications](/libraries/lock/v11/migration-cordova)
+* [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11)
+* [Migrating from Lock v9 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v9)
+* [Migrating from Lock v8](/libraries/lock/v11/migration-v8-v11)
+* [Migrating from Lock v8 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v8)
+
+If you have any questions or concerns, you can discuss them in the [Auth0 Community](https://community.auth0.com/), submit them using the [Support Center](${env.DOMAIN_URL_SUPPORT}), or directly through your account representative, if applicable. 
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Troubleshooting
+
+### Lock takes too long to display the login options
+
+If Lock takes a lot of time to display the login options, it could be because the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property is not correctly set.
+
+To verify that this is a problem check your logs at [Dashboard > Logs](${manage_url}/#/logs). If you see an entry with the following error description, set the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property and try again.
+
+```text
+The specified redirect_uri 'https://YOUR_APP_URL' does not have a registered domain.
+```
+
+### I upgraded but I still get deprecation warnings in the logs
+
+You have already migrated to Lock 11 but you still see this error in your logs:
+
+```text
+Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application.
+```
+
+These deprecation notices most likely originate from a user visiting the Universal Login [page](/universal-login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. After August 6, 2018, these users will not be able to log in.
+
+See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md b/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md
new file mode 100644
index 0000000000..3108edcae5
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md
@@ -0,0 +1,208 @@
+---
+section: libraries
+toc: true
+description: Migration Guide from lock-passwordless to Lock v11 with Passwordless Mode
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - passwordless
+contentType:
+  - how-to
+  - reference
+  - concept
+useCase:
+  - add-login
+  - migrate
+---
+# Migration Guide for lock-passwordless to Lock v11 with Passwordless Mode
+
+The following instructions assume you are migrating from the **lock-passwordless** widget to Lock v11.2+ using **Passwordless Mode**.
+
+The [lock-passwordless](https://github.com/auth0/lock-passwordless) widget was previously a standalone library, separate from [Lock](/libraries/lock). Now, you can migrate your apps to use the Passwordless Mode which is integrated directly into Lock v11. Lock v11 with Passwordless Mode is the latest method by which to deploy a login widget for passwordless authentication in your apps.
+
+To get started, you will need to remove **lock-passwordless** from your project, and instead include the [latest release version of Lock v11](https://github.com/auth0/lock/releases). 
+
+::: note
+To use Passwordless Mode, you must use Lock v11.2 or above.
+:::
+
+Beyond that, you will then need to take a careful look at each of the sections in this migration guide in order to find out which changes you will need to make to your implementation. Of particular importance will be the following:
+
+* The initialization of `Auth0LockPasswordless`
+* Your calls to Lock methods (now the same methods as used in Lock v11)
+* Your previously implemented customization options, which will need inspected and changed to use the corresponding options for Lock v11.
+
+## General changes and additions
+
+### Importing Auth0LockPasswordless
+
+You can import Auth0LockPasswordless in the same ways as you would normally import Lock; using the CDN or via NPM.
+
+#### Using the CDN
+
+If you're loading from the CDN, you can still use `Auth0LockPasswordless`. The difference is that you'll provide your options in the constructor, like we do with `Auth0Lock`:
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+    
    
+    <script src="http://cdn.auth0.com/js/lock-passwordless-2.2.3.min.js"></script>
+    <script>
+      var lock = new Auth0LockPasswordless(clientID, domain);
+    </script>
+    
    
+    
    
+    
    
+    
    
+    <script src="${lock_url}"></script>
+    <script>
+      // example use of options
+      var options = {
+        closable: false
+      }
+      var lock = new Auth0LockPasswordless(clientID, domain, options);
+    </script>
+    
    
+    
    
+  
    
+
    
+
+#### Using npm + module bundler
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+    
    
+    import Auth0LockPasswordless from 'auth0-lock-passwordless';
+    var lock = new Auth0LockPasswordless(clientID, domain);
+    
    
+    
    
+    
    
+    
    
+    import {Auth0LockPasswordless} from 'auth0-lock';
+    var options = {
+      closable: false
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
    
+    
    
+  
    
+
    
+
+### Initialization options
+
+`Auth0LockPasswordless` has the same [options available](/libraries/lock/v11/configuration) as `Auth0Lock` in addition to a single new option that determines if you want to use a Magic Link or a Email Code when using an email passwordless connection. For this property, `passwordlessMethod`, only two values are accepted:
+
+- `code` if you want to use an Email Code
+- `link` if you want to use a Magic Link
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+    
    
+    var options = {
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
    
+    
    
+    
+  
    
+
    
+
+### Choose between SMS or email
+
+We recommend that you setup which passwordless connections you want enabled in [the dashboard](${manage_url}/#/connections/passwordless), but if you want to have more than one passwordless connection enabled in the dashboard, you can restrict `Auth0LockPasswordless` to use only one of them using the [allowedConnections](/libraries/lock/v11/customization#allowedconnections-array-) option.
+If you have both `sms` and `email` passwordless connections enabled in the dashboard, `Auth0LockPasswordless` will use `email` by default.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+    
    
+    var options = {
+      allowedConnections: ['sms']
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
    
+    
    
+    
    
+    
    
+    var options = {
+      allowedConnections: ['email'],
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
    
+    
    
+  
    
+
    
+
+### Show the widget
+
+In the old `lock-passwordless`, you could call the passwordless method directly (sms, socialOrMagiclink, socialOrSms etc). In Lock v11, you'll have to use [the show method](/libraries/lock/v11/api#show-) in order to display the widget.
+
+```js
+var lock = new Auth0LockPasswordless(clientID, domain);
+lock.show();
+```
+
+### Subscribe to events
+
+Lock exposes a few events that you can subscribe to in order to be notified when the user is authenticated or an error occurs. So, instead of callbacks from `lock-passwordless`, you have to subscribe to events that you want to know about. To read more about Lock events, see [here](/libraries/lock/v11/api#on-).
+
+```js
+var lock = new Auth0LockPasswordless(clientID, domain);
+lock.on("authenticated", function(authResult) {
+  alert(authResult.accessToken);
+});
+```
+
+### Customization options
+
+Some options have to be renamed.
+
+* `dict` is now [languageDictionary](/libraries/lock/v11/configuration#languagedictionary-object-)
+* `connections` is now [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-)
+* `socialBigButtons` is no longer available as an option and all the social connection buttons will be shown with a "big" style.
+* all the authentication options were moved into an [auth object](/libraries/lock/v11/configuration#auth-object-)
+
+## Further Reading
+
+::: next-steps
+- [Lock 11 Reference - an overview on how Lock works](/libraries/lock/v11)
+- [Lock 11 Configuration - details on the available configuration options for Lock](/libraries/lock/v11/configuration)
+:::
diff --git a/ja-jp/articles/libraries/lock/v11/migration-react.md b/ja-jp/articles/libraries/lock/v11/migration-react.md
new file mode 100644
index 0000000000..fbac6ae04c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-react.md
@@ -0,0 +1,23 @@
+---
+section: libraries
+title: Migrating React applications to Lock v11
+description: How to migrate React applications to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - react
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating React Applications to Lock v11
+
+React applications use Lock directly without any kind of wrapper library.
+
+Most React applications will be using Lock v10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide.
+
+If you were an early React and Auth0 adopter, and are using Lock v9, you can follow the [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11) guide.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md
new file mode 100644
index 0000000000..16e9b75071
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md
@@ -0,0 +1,41 @@
+---
+section: libraries
+title: Migrating from Lock v10 to v11
+description: How to migrate from Lock v10 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrate from Lock v10 to v11
+
+This guide includes all the information you need to update your Lock v10 application to [Lock v11](/libraries/lock).
+
+## Migration demo
+
+
     
    
+
+## Migration steps
+
+<%= include('../../_includes/_migrate_universal') %>
+<%= include('../../_includes/_get_lock_latest_version') %>
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+<%= include('../../_includes/_oidc_conformant') %>
+<%= include('../../_includes/_configure_custom_domain', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_verifying_migration') %>
+
+## Behavioral changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
+<%= include('../../_includes/_embedded_sso') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md
new file mode 100644
index 0000000000..2f2e3e53c6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md
@@ -0,0 +1,22 @@
+---
+section: libraries
+title: Migrating from Lock v8 to v11
+description: How to migrate from Lock v8 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Lock v8 to v11
+
+Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint.
+
+You can follow the instructions on [how to migrate from Lock v9 to Lock v11](/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock v8.
+
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md
new file mode 100644
index 0000000000..cb56f72034
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md
@@ -0,0 +1,201 @@
+---
+section: libraries
+title: Migrating from Lock v9 to v11
+description: How to migrate from Lock v9 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Lock v9 to v11
+
+This guide includes all the information you need to update your Lock v9 applications to [Lock v11](/libraries/lock).
+
+## Migration Steps
+
+Given that Lock v10 is very similar to Lock v11 you can read the [Lock v9 to Lock v10 migration guide](/libraries/lock/v10/migration-guide).
+
+Building Single-Page Applications with Lock v9 has some key differences with the way they should be built in Lock v11. Lock v11 uses OIDC conformant APIs that are more secure, and some of the coding patterns with Lock v9 need to be changed.
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+### Using Lock in SPAs with Popup Mode
+
+In Lock v9 the code to use `popup mode` looked similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+function login()
+{
+    lock.show({
+            responseType : "token",
+            authParams: {
+                scope: 'openid email offline_access'
+            }
+        },
+        function (err, profile, id_token, access_token, state, refresh_token) {
+            if (!err) {
+                setSession(profile, id_token, access_token, refresh_token);
+                lock.getProfile(hash.id_token, function(err, userInfo) {
+                    if (!err) {
+                        /// use the userInfo
+                    }
+                });
+            }
+        }
+    })
+}
+```
+
+In Lock v11, the code would instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+        {
+            popup: true,
+            auth: {
+                responseType: 'token id_token',
+                audience: 'https://' + '${account.namespace}' + '/userinfo',
+                params: {
+                    scope: 'openid email profile'
+                }
+            }
+        }
+    );
+
+lock.on('authenticated', function(authResult) {
+    if (authResult && authResult.accessToken && authResult.idToken) {
+        setSession(authResult);
+
+        lock.getUserInfo(authResult.accessToken, function(err, userInfo) {
+             if (!err) {
+                // use the userInfo
+            }
+        });
+    }
+});
+function login()
+{
+    lock.show()
+}
+```
+
+Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that the callback specified in `show()` is replaced by an `authenticated` event handler. 
+
+### Using Lock in SPAs with Redirect Mode
+
+In Lock v9 the code to use `redirect mode` looked similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+var hash = lock.parseHash();
+
+if (hash) {
+    if (!hash.error) {
+        setSession(hash.profile, hash.id_token, hash.access_token, hash.refresh_token);
+
+        lock.getProfile(hash.id_token, function(err, userInfo) {
+            if (!err) {
+                // use the userInfo
+            }
+        });
+    } 
+}
+
+function login() {
+    lock.show({
+        callbackURL: '${account.callback}',
+        responseType : "token",
+        authParams: {
+            scope: 'openid email offline_access'
+        }
+    });
+}
+```
+
+In Lock v11, the code should instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+        {
+            auth: {
+                redirectUrl: '${account.callback}',
+                responseType: 'token id_token',
+                params: {
+                    scope: 'openid email profile'
+                }
+            }
+        }
+    );
+
+lock.on('authenticated', function(authResult) {
+    if (authResult && authResult.accessToken && authResult.idToken) {
+        setSession(authResult);
+        // use authResult.idTokenPayload for profile information
+    }
+});
+
+function login() {
+    lock.show()
+}
+```
+
+Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that instead of calling `parseHash()`, you need to write an `authenticated` event handler.
+
+### Using Lock in Web Applications
+
+When using Lock v9 for Web Applications, the code would be similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+
+function login() {
+    lock.show({
+     auth: {
+      redirectUrl: '${account.callback}',
+      responseType: 'code',
+      params: {
+        scope: 'openid profile email' 
+      }
+    }
+  }
+```
+
+In Lock v11, the code should instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    {
+        auth: {
+            redirectUrl: '${account.callback}',
+            responseType: 'code',
+            params: {
+                scope: 'openid email profile'
+            }
+        }
+    }
+);
+
+function login() {
+    lock.show()
+}
+```
+
+Note that, once more, the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11.
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_legacy_flows') %>
+<%= include('../../_includes/_change_get_profile') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_default_values_lock') %>
+<%= include('../../_includes/_ip_ranges') %>
diff --git a/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md b/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md
new file mode 100644
index 0000000000..928c694dac
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md
@@ -0,0 +1,139 @@
+---
+section: libraries
+description: How to select different connection types for multiple login options with Lock V11.
+topics:
+  - libraries
+  - lock
+  - connections
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - customize-connections
+---
+# Selecting from Multiple Connection Options
+
+With Auth0 you can offer users multiple methods of authenticating. This is important with SaaS or multi-tenant apps, where many organization use a single app. Each organization might use different systems such as LDAP, Active Directory, G Suite, or username/password stores.
+
+In Auth0, you can associate different *connections* (methods of authentication) to specific applications, or directly to a tenant (as [domain connections](/api/management/guides/connections/promote-connection-domain-level)). When a user logs in, one of these connections will need to be selected as the one to use.
+
+![](/media/articles/hrd/sd4h-6wlwOsQA1PCQKLAmtQ.png)
+
+::: note
+Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery".
+:::
+
+If you use at most one database connection and zero or more social connections the selection process is straightforward. The user will either:
+
+* Click on one of the social identity providers buttons (e.g. "Log in with Google")
+* Enter their email and password (meaning "I will use the database connection").
+
+But if the application or tenant have other connection types enabled (like enterprise connections or multiple databases) the selection process might be more involved. How do you indicate that a user wants to use a specific database connection if more than one is enabled? What if a user wants to use an enterprise connection to log in using Single Sign-on (SSO)?
+
+If you implement [a custom login UI](/libraries/when-to-use-lock#when-to-implement-lock-vs-a-custom-ui) you have full control over the authentication flow. You can choose the connection based on context (like the given email address) or by asking the user, then provide the `connection` parameter to one of Auth0.js' [login methods](/libraries/auth0js/v9#login).
+
+## Lock and multiple connections
+
+Lock has built in functionality for identity provider selection. For social connections, it shows logos for all those enabled in a particular app. It also provides username/email and password fields if a database connection or Active Directory connection are enabled. 
+
+## Using email domains with enterprise connections
+
+An additional feature in Lock is the use of email domains as a way of routing authentication requests. Enterprise connections in Auth0 can be mapped to `domains`. For example, when configuring an ADFS or a SAML-P identity provider:
+
+![](/media/articles/libraries/lock/enterprise-connection.png)
+
+If a connection has domains mapped to it, then the password input field gets disabled automatically when a user enters an email with a mapped domain.
+
+![Lock using HRD/SSO](/media/articles/libraries/lock/hrd-sso.png)
+
+In the example above the domain `auth0.com` has been mapped to an enterprise connection.
+
+Notice that you can associate multiple domains to a single connection.
+
+## Selecting among multiple database connections
+
+If your application has multiple database connections enabled, Lock needs to know which one to use. You can provide a [`connectionResolver` option](https://github.com/auth0/lock#other-options), which takes a function that decides the connection to use based on the user input and context. In this example an alternative database connection is used if the email domain is "auth0.com":
+
+```
+var options = {
+  connectionResolver: function (username, context, cb) {
+    var domain = username.indexOf('@') !== -1 && username.split('@')[1];
+    if (domain && domain ==='auth0.com') {
+      // If the username is test@auth0.com, the connection used will be the `auth0-users` connection.
+      cb({ type: 'database', name: 'auth0-users' });
+    } else {
+      // Use the default approach to figure it out the connection
+      cb(null);
+    }
+  }
+}
+```
+
+You can use the [`defaultDatabaseConnection` option](/libraries/lock/v11/configuration#defaultdatabaseconnection-string-) to specify the database connection that will be used by default.
+
+## Filtering available connections programmatically
+
+The [`allowedConnections` option](/libraries/lock/v11/configuration#allowedconnections-array-) in Lock lets you indicate which of the available connections should be presented as an option to the user.
+
+This lets you tailor the experience based on additional input or context (e.g. "Click here to log in as a student, or here to log in as a faculty member").
+
+
+```js
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  {
+    allowedConnections: ['YOUR CONNECTION HERE'];
+  }
+);
+```
+
+::: note
+Note that you can also provide the `allowedConnections` option to the `lock.show()` method if providing it at instantiation is not ideal for your use case. Please refer to the [API documentation](/libraries/lock/v11/api#show-) for the `show` method for more information.
+:::
+
+# Sending realm information from the application
+
+Sometimes the application requesting an authentication can know, in advance, the realm intented to be used by the user. E.g. a multi-tenant application might use URLs in the form of: `https://{customer}.yoursite.com` or `https://www.yoursite.com/{customer}`. When a user arrives at your application with the vanity URL, you can pick up that `tenant` value and pass it as the `login_hint` in the `authorize` request:
+
+```
+https://{YOUR_AUTH0_DOMAIN}/authorize?client_id=[...]&login_hint={customer}
+```
+
+`login_hint` is a hint to the authorization server (Auth0) to indicate what the user might use to log in. In this case, based on the URL where the user landed, we treat the "customer" as the realm.
+
+The default hosted login page code uses it to pre-fill the email field in Lock, but we can modify the code to alter the default database connection to be used if a realm is provided instead of an actual email address:
+
+```js
+// from the default Hosted Login Page template
+var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
+[...]
+
+var loginHint = config.extraParams.login_hint;
+var realmHint;
+
+// if the login hint is not an email address, we treat it as a realm hint
+if (loginHint && loginHint.indexOf('@') < 0) {
+  realmHint = loginHint;
+  loginHint = null;
+}
+
+// now we map the realm into an actual database
+var defaultDatabaseConnection;
+if (realmHint === 'acme') {
+  defaultDatabaseConnection = 'acme-users';
+} else if (realmHint === 'auth0') {
+  defaultDatabaseConnection = 'auth0-DB';
+}
+    
+// When configuring Lock, we provide the values obtained before
+var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
+  [...] // other options
+  prefill: loginHint ? { email: loginHint, username: loginHint } : null,
+  defaultDatabaseConnection: defaultDatabaseConnection
+}
+```
+
+The above code is, of course, just a sample. You could expand this logic to filter out social connections, or to set a default connection to be used even if an email address is provided as a `login_hint`. 
+
+Mapping the "customer" as a realm is an arbitrary design decision for this example. But it is generally a good idea to isolate applications from the actual "connection" concept used within Auth0 and use the more abstract "realm" concept instead, possibly doing a realm-to-connection mapping within the hosted login page (where it's easier to make changes if necessary).
diff --git a/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md b/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md
new file mode 100644
index 0000000000..fa5e7055ff
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md
@@ -0,0 +1,85 @@
+---
+section: libraries
+description: Lock v11 documentation on setting authentication parameters.
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock Authentication Parameters
+
+You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `'foo'`.
+
+```js
+var options = {
+  auth: {
+    params: {state: 'foo'},
+  }
+};
+```
+
+The following parameters are supported: `scope`, `device`, `nonce` and `state`.
+
+::: note
+This would be analogous to triggering the login with `https://${account.namespace}/authorize?state=foo&...`.
+:::
+
+## Supported parameters
+
+### scope {string}
+
+```js
+var options = {
+  auth: {
+    params: {scope: 'openid email user_metadata app_metadata picture'},
+  }
+};
+```
+
+There are different values supported for scope. Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible.
+
+The default `scope` value in Lock v11 is `openid profile email`. This minimum scope value is required to make the **Last time you logged in with** feature work correctly.
+
+::: panel Running Lock Locally
+If you don't specify at least the above scope when initializing Lock, and you are running your website from `http://localhost` or `http://127.0.0.1`, you will get the following error in the browser console:
+
+`Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email`
+
+That will not happen when you run your application in production or if you specify the `openid profile email` scope. You can read more about this in the [User consent and third-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications) document.
+:::
+
+For more information about scopes, see the [scopes documentation page](/scopes).
+
+#### Example: retrieve a token
+
+In Lock v11, if you wish to receive a token with the ability to fetch the user's profile data, you should add the `scope` parameter.
+
+```js
+var options = {
+  auth: {
+    params: {
+        scope: 'openid profile'
+    }
+  }
+};
+```
+
+::: note
+There is also a `connectionScopes` configuration option for Lock v11, which allows you to specify scopes on any specific connection. This will be useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request additional permissions or attributes from a specific connection. Read more about it on the [Lock Configuration Options](/libraries/lock/v11/configuration#connectionscopes-object-) page.
+:::
+
+### state {string}
+
+The `state` parameter is an arbitrary state value that will be maintained across redirects. It is useful to mitigate [XSRF attacks](http://en.wikipedia.org/wiki/Cross-site_request_forgery) and for any contextual information, [such as a return url](/protocols/oauth2/redirect-users) that you might need after the authentication process is finished. If a custom state parameter is not provided, Lock will automatically generate one. For more information, see [State Parameter](/protocols/oauth-state).
+
+### nonce {string}
+
+The `nonce` parameter is used to help prevent replay attacks, and will be automatically generated by Lock if a custom value is not provided.
+
+### device {string}
+
+The `device` parameter sets the name of the device or browser requesting authentication.
diff --git a/ja-jp/articles/libraries/lock/v11/ui-customization.md b/ja-jp/articles/libraries/lock/v11/ui-customization.md
new file mode 100644
index 0000000000..6bbb747ae9
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/ui-customization.md
@@ -0,0 +1,129 @@
+---
+section: libraries
+description: Customizing the appearance of your Lock widget can be important for branding and a cohesive UI, and this resource highlights the ways in which you can do so while implementing Lock in your project.
+topics:
+  - libraries
+  - lock
+  - lock-ui
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock UI Customization
+
+You can customize the appearance of your Lock widget in a few different ways. The best and safest way to do so is with the provided JavaScript options.
+
+## JavaScript Options
+
+You can set up a variety of customizations to your Lock via the `options` parameter when you instantiate your Lock. Some of them allow you to customize your UI. The UI customization options are a work in progress - we expect to be adding more as we go.
+
+First, you'll define the `options` object, containing whichever options you're wanting to customize. Then you'll need to include that options object as the third parameter when you instantiate Lock; more on that below.
+
+### Theming Options
+
+There are a couple of theming options currently available, namespaced under the `theme` property.
+
+#### logo {String}
+
+![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png)
+
+The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png'
+  }
+};
+```
+
+#### primaryColor {String}
+
+![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png)
+
+The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png',
+    primaryColor: '#31324F'
+  }
+};
+```
+
+#### authButtons {Object}
+
+Allows the customization of buttons in Lock. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below:
+
+- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login).
+- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`.
+- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`.
+- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`.
+
+```js
+var options = {
+  theme: {
+    authButtons: {
+      "testConnection": {
+        displayName: "Test Conn",
+        primaryColor: "#b7b7b7",
+        foregroundColor: "#000000",
+        icon: "http://example.com/icon.png"
+      },
+      "testConnection2": {
+        primaryColor: "#000000",
+        foregroundColor: "#ffffff",
+      }
+    }
+  }
+};
+```
+
+### Customizing Text
+
+The `languageDictionary` option allows customization of every piece of text displayed in the Lock. Defaults to {}. See below for an example.
+
+```js
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+```
+
+![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png)
+
+::: note
+For a complete list of the items able to be customized using `languageDictionary`, see the [English Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) in the repository.
+:::
+
+### Instantiating Lock
+
+Finally, you'll want to go ahead and instantiate your Lock, with the `options` object that you've defined with your custom options in it.
+
+```js
+// Initiating our Auth0Lock
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', options);
+```
+
+## Overriding CSS
+
+Customizing your Lock by overriding its CSS isn't recommended. The issue is that with new releases of Lock, some styling may change, leading to unintended problems if you are overriding the CSS. Additionally, it's possible to simply overlook use of styles in other places and while the change may look fine in one view, it might not in another.
+
+If you still intend to override CSS to further style your Lock, we recommend that you use a specific patch version of Lock rather than a major or minor version, so that you limit the amount of unexpected results that may occur when you alter the styles, and then another patch is deployed that might cause unexpected behavior in your UI due to the changes. This can be done by ensuring that you specify that patch version (`x.y.z`) when including Lock, or downloading it.
+
+Additionally, we of course recommend that you test your CSS changes exhaustively, to ensure that the experience is the one you intend it to be for your customers.
+
+::: panel-warning Regarding Lock CSS Themes
+At this time, Auth0 doesn't offer any alternative pre-made CSS themes for Lock v11, and the ones that existed for earlier versions of Lock will not work with Lock v11.
+:::
+
+## Further Information
+
+If you're looking for more detailed information while working to customize Lock for your application, check out the [configuration options](/libraries/lock/v11/configuration) page or the [Lock API](/libraries/lock/v11/api) page!
+
+If you have specific theming options that you would like to see added, let us know. We are working on improving the customization options that are available through JavaScript, and this list will be updated as new options are added.
diff --git a/ja-jp/articles/libraries/secure-local-development.md b/ja-jp/articles/libraries/secure-local-development.md
new file mode 100644
index 0000000000..577adafce8
--- /dev/null
+++ b/ja-jp/articles/libraries/secure-local-development.md
@@ -0,0 +1,143 @@
+---
+section: libraries
+description: Securing local development servers to work with samesite cookies
+topics:
+  - libraries
+  - samesite
+contentType:
+  - guide
+---
+
+# Secure Local Development
+Local development environments typically run on non-secure channels (ie: `http://localhost`) out of the box.  This guide will discuss when you should run a secure local server and how to setup `https` on localhost.
+
+## When to use a secure local server
+Testing over non-secure channels `http` is generally safe for local servers that don't communicate with external services, like Auth0.  However, when your local server is communicating with external services, we recommend running your local server on `https` for the following reasons:
+
+- Communication between an external service and your localhost should be encrypted to protect any sensitive information.
+- It tests a very critical part of the development stack if you run your server on secure channels in production.
+- Cookies using a Secure attribute or SameSite attribute set to `None` will not be sent across insecure channels, disrupting authentication and other functionality.
+
+## How to set up a secure local server
+When you visit a secure web page (served over https), your browser will verify the SSL certificate supplied by the server with a Certificate Authority. When loading a secure web page from a local server, you can create an authority just for your machine and generate certificates that only your browser will trust.
+
+The process to do this is:
+
+1. Create and install a local Certificate Authority
+2. Generate an SSL certificate for the domain being used (ie. localhost) using this new Authority.
+3. Serve the SSL certificate from your web application
+
+### 1. Install Mkcert Utility
+To get started, download [mkcert](https://github.com/FiloSottile/mkcert) and follow the [installation instructions](https://github.com/FiloSottile/mkcert#installation) for your specific operating system.
+
+### 2. Install local Certificate Authority
+The Certificate Authority is a trusted entity that the web browser uses to verify the certificate supplied by a webserver.  Installing a local Certificate Authority will allow you to generate your own SSL Certificates to be used locally.
+
+```powershell
+> mkcert -install
+# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨
+# The local CA is now installed in the system trust store! 👍
+# The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
+```
+
+### 3. Generate an SSL Certificate
+The next step is to generate the SSL certificate. This example will assume you are running your local server on `https://localhost:{port}`.
+
+```powershell
+> mkcert localhost
+# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨
+
+# Created a new certificate valid for the following names 📜
+#  - "localhost"
+
+# The certificate is at "./localhost.pem" and the key at "./localhost-key.pem" ✅
+```
+
+:::note
+The utility saves the certificate `localhost.pem` and a key file `localhost-key.pem` in the folder where the command was executed.
+:::
+
+### 4. Serve the SSL certificate
+Now that you have generated an SSL certificate and key, you need to load them when starting your server. The way certificates are loaded depends on the technology used to serve the application. Please see below for examples.
+
+#### Node.js with Express
+
+```js
+// app.js
+
+const express = require('express');
+const https = require('https');
+const fs = require('fs');
+
+const key = fs.readFileSync('./localhost-key.pem');
+const cert = fs.readFileSync('./localhost.pem');
+
+https.createServer({key, cert}, express()).listen('3000', () => {
+  console.log('Listening on https://localhost:3000');
+});
+```
+
+#### webpack DevServer
+
+```js
+// webpack.config.js
+
+module.exports = {
+  //...
+  devServer: {
+    https: {
+      key: fs.readFileSync('./localhost-key.pem'),
+      cert: fs.readFileSync('./localhost.pem'),
+    }
+  }
+};
+```
+
+#### Apache (including PHP, Python, Ruby)
+
+The actual path of the files mentioned below will differ depending on the OS and install method. The paths below are from Homebrew-installed Apache on macOS.
+
+```
+# /usr/local/etc/httpd/httpd.conf
+# Find and uncomment the lines below
+
+LoadModule socache_shmcb_module lib/httpd/modules/mod_socache_shmcb.so
+# ...
+LoadModule ssl_module lib/httpd/modules/mod_ssl.so
+# ...
+Include /usr/local/etc/httpd/extra/httpd-ssl.conf
+```
+
+```
+# /usr/local/etc/httpd/extra/httpd-ssl.conf
+
+# Listen 8443
+Listen 443
+# ...
+
+# Change the line below and comment out the two lines referenced below
+# 
+
+# ...
+# DocumentRoot "/usr/local/var/www"
+# ServerName www.example.com:8443
+```
+
+```
+# /usr/local/etc/httpd/extra/httpd-vhosts.conf
+
+
+    # Make sure this path points to your local application.
+    DocumentRoot "/path/to/application/root"
+    ServerName localhost
+    SSLEngine on
+    SSLCertificateFile "/usr/local/etc/httpd/localhost.pem"
+    SSLCertificateKeyFile "/usr/local/etc/httpd/localhost-key.pem"
+
+```
+
+#### Nginx (for PHP)
+
+#### WordPress
+
+The WordPress documentation has some [specific considerations for running WordPress over HTTPS](https://make.wordpress.org/support/user-manual/web-publishing/https-for-wordpress/). Please see the Apache or nginx sections above for specifics on loading the certificates.
diff --git a/ja-jp/articles/libraries/when-to-use-lock.md b/ja-jp/articles/libraries/when-to-use-lock.md
new file mode 100644
index 0000000000..fba0c02d30
--- /dev/null
+++ b/ja-jp/articles/libraries/when-to-use-lock.md
@@ -0,0 +1,167 @@
+---
+section: libraries
+description: When customizing the Classic Universal Login page what tools should you use? Lock (Auth0's drop-in authentication widget) or a custom UI built on top of an Auth0 SDK? This guide will help you decide.
+topics:
+  - libraries
+  - lock
+  - custom-ui
+contentType:
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Universal Login Page Customization
+
+When adding Auth0 to your web apps, the best solution is to use Auth0's Universal Login. If you plan to use the [New Experience](/universal-login/new), you won't even need to choose an Auth0 library to use inside of the login page, and can stop here. If you are using the [Classic Experience](/universal-login/classic), this guide will help you choose a technology to power your login page.
+
+Universal Login is less complex than embedding the authentication process within your app. It also prevents the dangers of cross-origin authentication.
+
+The Classic login page uses the Lock Widget by default for user authentication. It also has templates for Lock in Passwordless Mode and for a custom UI built with the Auth0.js SDK. 
+
+* [Lock for Web](/libraries/lock), Auth0's drop-in login and signup widget
+* The [Auth0 SDK for Web](/libraries/auth0js) with your custom designed interface
+* Or, a custom user interface that you have created which directly ties into the [Authentication API](/auth-api).
+
+::: note
+Passwordless authentication from native mobile apps currently must use Universal Login - there is no native passwordless option at this time.
+:::
+
+## When to Implement Lock vs. a Custom UI
+
+**Lock** is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface.  
+
+**Auth0 SDKs** are client-side libraries that **do not** come with a user interface but allow for expanded customization of the behavior and appearance of the login page.
+
+The **Authentication API** provides integration without requiring the use of Auth0 SDKs. The best option to choose will depend on the needs of your app.
+
+Below is a quick overview of reasons you might want to use Lock, versus using an Auth0 SDK or the authentication API. There are details about each option (Lock, Auth0 SDKs, Authentication API) below the table, to assist you in finding the right way to implement Auth0 in your application!
+
+
+    
+        
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+    
+
    Desired UI Attributes:LockCustom UI
    Has a simple design that fits in with most modern websites with just a few tweaks to its options.YesNo
    Adapts to your configuration and only show the allowable options in the appropriate situationsYesNo
    Chooses the correct connection automaticallyYesNo
    Remembers the last used connection for a given userYesNo
    Automatically accommodates internationalizationYesNo
    Automatically provides password policy checking at signupYesNo
    Provide secure authentication via Auth0YesYes
    Potential to provide auth without having to create custom code to deal directly with Auth0's APIYesYes
    Follows strict appearance requirements as set by your companyNoYes
    Allows you to retain your existing UI for authenticationNoYes
    Allows for expert usage of HTML, CSS, and JavaScript for customizationNoYes
    Handles multiple databases or Active Directory connectionsNoYes
    
+
+## Lock
+
+**Lock** is a login form that makes it easy for your users to authenticate using a selected connection. **Lock** will automatically handle most of the details involved in creating and authenticating users. [Lock](/libraries/lock) is provided as a drop-in solution for the Classic Universal Login experience.
+
+![](/media/articles/libraries/lock/lock-default.png)
+
+With **Lock**, you will be implementing a UI that:
+
+* Is robust and provides an excellent user experience on any device with any resolution
+* Has a simple design that fits in with most websites with just a few tweaks to its custom color
+* Adapts to your configuration, displaying the appropriate form controls for each available connection and only those which are allowed (such as sign up or password reset)
+* Selects the correct connection automatically. You may specify a desired default behavior for ambiguous cases
+* Remembers the last used connection for a given user
+* Automatically accommodates internationalization
+* Provides instant password policy checking at sign up
+
+Although you cannot alter Lock's behavior significantly, you can configure several [basic options](/libraries/lock/customization) to make Lock look and behave differently.
+
+![](/media/articles/libraries/lock/lock-phantom.png)
+
+### When to use Lock
+
+Consider using **Lock** if:
+
+* You like the structure, look, and feel of **Lock**
+* You prefer a quicker and easier implementation of Auth0 and a ready-made responsive UI
+* Your process includes many of the use cases that **Lock** handles out of the box:
+  * Enterprise logins
+  * Databases with password policies
+  * User signup and password reset
+  * Authentication using social providers
+  * Avatars
+
+## Custom User Interface
+
+If the requirements of your app cannot be met by the standardized behavior of **Lock**, or if you have a complex custom authentication process, a custom user interface is needed. You also might prefer this option if you already have a user interface which you would prefer to keep.
+
+With Auth0's library for [Web](/libraries/auth0js), you can customize the behavior and flow of the process used to trigger signup and authentication. You can also directly use the [Authentication API](/auth-api), without any wrapper at all, if you so choose.
+
+![](/media/articles/libraries/lock-vs-customui/customui.png)
+
+Unlike with **Lock**, neither of these options includes a user interface. You will have complete control over the user experience for signup and authentication flow, and for the UI aspects of layout, look and feel, branding, internationalization, RTL support, and more.
+
+### When to use a custom user interface
+
+Consider implementing a custom user interface in conjunction with an Auth0 library or the Authentication API for your app if:
+
+* You have strict requirements for the appearance of the user interface
+* You have strict requirements for file sizes - the Auth0 libraries are significantly smaller than Lock, and if you instead choose to deal with the API directly, that would not require any additional weight.
+* You are comfortable with HTML, CSS, and JavaScript - you'll be creating your own UI
+* You only need to handle username/password and social provider authentication
+* You have multiple database or Active Directory Connections
+
+## See Also
+
+You can also see specific examples of the usage of both Lock and Auth0 SDKs for a wide variety of programming languages and platforms in our [Quickstarts](/quickstart). These guides may further assist you in your decision about which to use for your specific app needs.
diff --git a/ja-jp/articles/login/embedded/index.md b/ja-jp/articles/login/embedded/index.md
new file mode 100644
index 0000000000..a2f469081e
--- /dev/null
+++ b/ja-jp/articles/login/embedded/index.md
@@ -0,0 +1,15 @@
+---
+description: A brief overview of Embedded Login with Auth0
+topics:
+  - login
+  - embedded-login
+  - hosted-pages
+contentType: index
+useCase: customize-hosted-pages
+---
+
+# Embedded Login
+
+Embedded Login is the scenario in which users login directly in your application, and credentials are transmitted to the Auth0 server. There are security concerns with this approach, particularly if you do not use the [Custom Domains](/custom-domains) feature at Auth0, as this potentially opens your application up to [cross-origin authentication](/cross-origin-authentication) issues.
+
+If you need to implement embedded login, you need to have a custom domain set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication).
diff --git a/ja-jp/articles/login/index.md b/ja-jp/articles/login/index.md
new file mode 100644
index 0000000000..ec29764282
--- /dev/null
+++ b/ja-jp/articles/login/index.md
@@ -0,0 +1,74 @@
+---
+description: Overview of Universal Login with Auth0
+topics:
+  - login
+  - universal-login
+  - password-reset
+  - mfa
+  - error-pages
+  - hosted-pages
+contentType: index
+toc: true
+useCase: customize-hosted-pages
+---
+# Login with Auth0
+
+Auth0 provides two ways to implement authentication for your applications: 
+
+* Universal Login: users log in to your application through a page hosted by Auth0.
+* Embedded Login: users log in to your application through a page you host.
+
+For the vast majority use cases, we recommend Universal Login. It's safe and easy to implement. Check out [our comparison guide](/guides/login/universal-vs-embedded) for more on the differences between Universal Login and Embedded Login within your application.
+
+## Universal Login
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. With Universal Login, users are redirected from your application to a login page hosted by Auth0. Auth0 then authenticates the user and returns them to your application. Since login and authentication take place on the same domain, credentials are not sent across origins, increasing security and protecting against attacks such as phishing and man-in-the-middle.
+
+Universal Login functionality and features are driven from web pages served by Auth0, so you can adjust the login experience in real-time without changing your application code. Universal Login page appearance and behavior is customizable right from the [Dashboard](${manage_url}).
+
+### Classic or New?
+
+There are two versions of Universal Login:
+
+* Classic Universal Login: Auth0-hosted pages built with [Lock.js](/libraries/lock) and other Javascript widgets, or with a library like [Auth0.js](/libraries/auth0js). HTML and CSS can also be customized.
+* New Universal Login: Auth0-hosted pages, rendered server-side, that do not use [Lock.js](/libraries/lock) or other Javascript widgets and libraries. Can only be customized based on the configuration available. HTML, CSS, and JS cannot be customized.
+
+In the [Dashboard](${manage_url}), the dialog shown below lets you select which Experience will be used for default, non-customized pages:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+To learn more about each experience and their differences, check out the following articles:
+
+* [Classic Universal Login Experience](/universal-login/classic) 
+* [New Universal Login Experience](/universal-login/new)
+* [New Universal Login Limitations](/universal-login/new-experience-limitations)
+
+### Implementing Universal Login
+
+In addition to configuring Universal Login for your tenant's applications, you will also need to complete a few other steps:
+
+1. Set up a connection(s) in the [Dashboard](${manage_url}) (Choose **Connections** in the Dashboard's sidebar, then choose a type and pick one to configure, such as a database or a social login provider). 
+1. Set up your application in the [Dashboard](${manage_url}/#/applications). 
+1. Configure your application's code to call Auth0's [`/authorize`](/api/authentication#login) endpoint in order to trigger Universal Login, and then to deal with the response. You can either do this directly or use one of our SDKs to make the process easier.
+
+For step by step instructions on setting up your application to use Universal Login, check out our [Quickstart guides](/quickstarts).
+
+### Simple Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo
+* Primary Color
+* Background Color
+
+These settings, once changed, will take effect on all your Universal Login pages if you have not enabled customization of the pages' code. The settings will also work if you have enabled customization but are using the predefined templates and have not changed those options in the code.
+
+If you select the New Universal Login Experience, you can also configure the favicon URL and a custom font URL using [the Branding API](/api/management/v2#!/Branding).
+
+## Embedded Login
+
+Embedded Login refers to implementations where users log in on a page hosted by your application, and credentials are sent to Auth0. There are security concerns with this approach since login and authentication take place on the different domains. If you need to implement Embedded Login, you need to have a [custom domain](/custom-domains) set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication).
diff --git a/ja-jp/articles/login/spa/authenticate-with-cookies.md b/ja-jp/articles/login/spa/authenticate-with-cookies.md
new file mode 100644
index 0000000000..aa00106d1a
--- /dev/null
+++ b/ja-jp/articles/login/spa/authenticate-with-cookies.md
@@ -0,0 +1,221 @@
+---
+title: Single-Page App Authentication Using Cookies
+description: Use your backend server to authenticate a single page app with cookies
+topics:
+  - login
+  - spa
+contentType: how-to
+toc: true
+useCase: spa-cookies
+---
+
+# Single-Page App Authentication Using Cookies
+
+Securing a single-page application (SPA) can be a challenge. However, if your SPA:
+
+* is served to the client using your own backend
+* has the same domain as your backend
+* makes API calls that require authentication to your backend
+
+Then you can simplify your implementation by using cookies to authenticate your SPA. In the following guide you'll find an overview of this approach as well as a sample implementation using [Node.js](https://nodejs.org/en/).
+
+## How it works
+
+The steps below show how tokens are retrieved and used. In this approach, the [Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) is used instead of a traditional [Authorization Code flow](/flows/concepts/auth-code). This is because Form Post Response Mode is a simpler way to implement login when it’s your own resource you are requesting access to.
+
+![SPA Cookie Authentication](/media/articles/login/spa/image1.png)
+
+1. The user accesses a protected route using the browser, or performs some action that requires an authentication step to be initiated (such as clicking on a Login button)
+2. The browser client redirects to a `/login` route on the backend, or to the protected route depending on what the user did
+3. The backend constructs a request to the authorization server’s `/authorize` endpoint and redirects the browser client there
+4. The user is prompted to authenticate themselves using whatever method the authorization server presents
+5. The authorization server POSTs the tokens to the redirect URI as a URL-encoded form post. The backend is able to retrieve those tokens by parsing the body data.
+
+At this point, the user is authenticated and the backend has the required tokens. A cookie can now be created to represent this state on the client. The client browser is then redirected to a route that serves the SPA and also receives the authentication cookie.
+
+From now on, this cookie is traded between the client and backend when API calls are made using an AJAX call. On each request, the backend verifies if the cookie is still valid and if so, allows the request to continue.
+
+![Cookie Exchange Between Client & Backend](/media/articles/login/spa/image2.png)
+
+### Dealing with invalid or missing cookies
+
+When implementing this approach you'll need to handle cases where the authentication cookie is invalid or missing. The API call to the backend from the client happens in the background, so the client has to deal with any response from the server indicating the user should reauthenticate.
+
+In the following sample application, this case is handled in a naive way by prompting the user to reauthenticate if the API call results in a 302 Redirect result. The 302 occurs because, upon unsuccessful validation of the cookie, the server tries to redirect to the authorization endpoint of the authorization server and sends this response to the client.
+
+## Example: Authenticating a SPA using cookies
+
+The example application uses Node.js and Express to demonstrate the concepts covered above.
+
+### Prerequisites
+
+To follow along, make sure you have the [latest version of Node](https://nodejs.org/en/download/) installed.
+
+Once Node is installed, [download or clone the source code](https://github.com/auth0-blog/spa-cookie-demo/) and open the project folder inside a terminal window.
+
+```bash
+// Clone the tutorial respository using SSH
+git clone git@github.com:auth0-blog/spa-cookie-demo
+// ... or if you use HTTPS:
+git clone https://github.com/auth0-blog/spa-cookie-demo.git
+// Move into the project directory
+cd spa-cookie-demo
+```
+The `master` branch represents the state of the application before any authentication is added. If you would like to refer to the final version of the application, `checkout` the `with-oidc` branch:
+```bash
+git checkout with-oidc
+```
+### Initialize the Node.js application
+Install the application dependencies by running `npm install` from your terminal window. To run the application, use `npm run dev`. This starts the Express server. Go to [http://localhost:3000](http://localhost:3000) in your browser to view the application.
+::: note
+The development server uses [`nodemon`](https://www.npmjs.com/package/nodemon), which automatically restarts whenever it detects any file changes.
+:::
+### Explore the application
+With the application open at [http://localhost:3000](http://localhost:3000), click the **Call API** button. You should see a message displayed on the screen.
+![Call API Message](/media/articles/login/spa/image3.png)
+Note that you were able to make the API call without being logged in. Let's fix that by adding authentication some middleware that requires the user to authenticate before the API call can be made.
+### Adding authentication middleware
+Inside the terminal, run the following command to install the additional libraries:
+```bash
+npm install express-session express-openid-connect
+```
+- [`express-openid-connect`](https://www.npmjs.com/package/express-openid-connect) — OpenID Connect middleware for Express. Creates authentication sessions and protects application routes
+- [`express-session`](https://www.npmjs.com/package/express-session) — session middleware for Express; required by `express-openid-connect`
+Next, open `server/index.js` and add in the middleware libraries underneath the existing `require` statements at the top of the file:
+```js
+// server/index.js
+// Other 'require' statements...
+// NEW - bring in our new middleware libraries
+const { auth } = require("express-openid-connect")
+const session = require("express-session")
+```
+The  `express-session` middleware can now be configured by adding the following code above the existing configuration for `body-parser` further down the file:
+```js
+// server/index.js
+// Existing config for morgan
+app.use(morgan("dev", {
+  stream: {
+    write: m => debug(m)
+  }
+}))
+// NEW - add this configuration for express-session
+app.use(
+  session({
+    secret: process.env.APP_SECRET || "keyboard cat",
+    resave: false,
+    saveUninitialized: true,
+    cookie: {
+      secure: process.env.NODE_ENV === "production",
+      httpOnly: true
+    }
+  })
+)
+// Existing config for body-parser
+app.use(bodyParser.urlencoded({
+  extended: false
+}))
+```
+Finally, add in the configuration for the `express-openid-connect` middleware. The location of this is important; it should be inserted _after_ the configuration for the static file server, but _before_ the definition of the API routes. This ensures the static files can be served without requiring authentication, but the API routes are secured:
+```js
+// server/index.js
+// Existing config for the static file server
+app.use(express.static(join(__dirname, "..", "public")))
+// NEW - Configure the OpenID Connect middleware
+app.use(
+  auth({
+    required: req => req.originalUrl !== "/"
+  })
+)
+// Existing config for the API routes
+app.use("/api", require("./api"))
+```
+Note that in this case, the authentication step is only applied if the request is for something other than the homepage. This lets us show some kind of UI even if the user is not logged in. We can display a "log in" button if they have not yet authenticated, or some other UI if they have.
+After these changes, your server script should more-or-less look like this:
+```js
+require("dotenv").config()
+const express = require("express")
+const helmet = require("helmet")
+const morgan = require("morgan")
+const debug = require("debug")("app:server")
+const session = require("express-session")
+const bodyParser = require("body-parser")
+const {
+  auth
+} = require("express-openid-connect")
+const {
+  join
+} = require("path")
+const app = express()
+app.use(helmet())
+app.use(morgan("dev", {
+  stream: {
+    write: m => debug(m)
+  }
+}))
+// Set up express-session (required by express-openid-connect)
+app.use(
+  session({
+    secret: process.env.APP_SECRET || "keyboard cat",
+    resave: false,
+    saveUninitialized: true,
+    cookie: {
+      secure: process.env.NODE_ENV === "production",
+      httpOnly: true
+    }
+  })
+)
+app.use(bodyParser.urlencoded({
+  extended: false
+}))
+app.use(express.static(join(__dirname, "..", "public")))
+// Set up authentication middleware, only strictly required if
+// the request isn't for the home page
+app.use(
+  auth({
+    required: req => req.originalUrl !== "/"
+  })
+)
+app.use("/api", require("./api"))
+app.get("/*", (req, res) => {
+  res.sendFile(join(__dirname, "..", "public", "index.html"))
+})
+const port = process.env.PORT || 3000
+app.listen(port, () => debug("Application listening on port " + port))
+```
+### Setting up the environment
+In order for the application to work with authentication, `express-openid-connect` requires some environment variables to be present. For this application, these variables can be specified in a `.env` file.
+Create a `.env` file in the root of the project directory and populate it with the following:
+```bash
+ISSUER_BASE_URL=
+CLIENT_ID=
+BASE_URL=http://localhost:3000
+```
+### Setting up an Auth0 app
+If you don't already have an Auth0 account, you can [sign up for a free Auth0 account here](https://auth0.com/signup).
+Next, set up an Auth0 Client and API so Auth0 can interface with your app and API.
+![Create App Dashboard](/media/articles/login/spa/image4.png)
+1. Go to your [Auth0 Dashboard](${manage_url}) and click the [Create Application](https://manage.auth0.com/#/applications/create) button.
+2. Name your new app, select **Regular Web Applications** and click the **Create** button.
+3. In the **Settings** for your new Auth0 app, add `http://localhost:3000/callback` to the **Allowed Callback URLs**.
+4. Add `http://localhost:3000` to the **Allowed Logout URLs**.
+5. Click the **Save Changes** button.
+6. If you'd like, you can [set up some social connections](${manage_url}/#/connections/social). You can then enable them for your app in the **Application** options under the **Connections** tab. The example shown in the screenshot above utilizes username/password database, Facebook, Google, and Twitter.
+On the **Settings** screen, note the domain and client ID settings at the top.
+![Application Settings](/media/articles/login/spa/image5.png)
+These are the two values that need to be configured as part of the application. Reopen the `.env` file and set these values:
+```
+ISSUER_BASE_URL=${account.namespace}
+CLIENT_ID=${account.clientId}
+BASE_URL=http://localhost:3000
+```
+### Running the application
+With the server and environment configuration done, find your browser window that has the application open. If you've closed the browser and stopped the server, run the following from the terminal to restart the application
+```bash
+npm run dev
+```
+Then open [http://localhost:3000](http://localhost:3000) in the browser. From a user interface perspective, the application should look the same. However, this time when the **Call API** button is clicked, you should receive a warning that the user is not logged in. Also note that you do not see the "Hello, World" message as before, since the call to the API has been rejected.
+![User Is Not Logged In](/media/articles/login/spa/image6.png)
+Click the "Log in now" to login. Once you have been authenticated, you'll return to the application and see an updated UI that reflects your newly-logged in state. You should be able to press the **Call API** button once more to invoke an API call to the server, and it now works!
+![User Is Logged In](/media/articles/login/spa/image7.png)
+You can click the "Profile" link at the top of the page to show user information retrieved from the ID token.
+![User Profile](/media/articles/login/spa/image8.png)
\ No newline at end of file
diff --git a/ja-jp/articles/logout/_includes/_logout-endpoint.md b/ja-jp/articles/logout/_includes/_logout-endpoint.md
new file mode 100644
index 0000000000..e1ee68dda9
--- /dev/null
+++ b/ja-jp/articles/logout/_includes/_logout-endpoint.md
@@ -0,0 +1,4 @@
+The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways:
+
+- Clears the Single Sign-on (SSO) cookie in Auth0.
+- Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google).
diff --git a/ja-jp/articles/logout/guides/logout-applications.md b/ja-jp/articles/logout/guides/logout-applications.md
new file mode 100644
index 0000000000..2368fd165f
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-applications.md
@@ -0,0 +1,27 @@
+---
+title: Log Users Out of Applications
+description: Learn how to force a user to log out of applications using the Auth0 logout endpoint. 
+topics:
+  - logout
+contentType: 
+  - how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of Applications
+
+Enterprise users typically have Single Sign-on (SSO) enabled for multiple applications (e.g., SharePoint, a few .NET applications, a few Java applications, Zendesk). In this case, when users sign out, often they must be signed out for all of their applications.
+
+<%= include('../_includes/_logout-endpoint') %>
+
+Redirecting users to the logout endpoint **does not** cover the scenario where users need to be signed out of all of the applications they used. If you need to provide this functionality you will have to handle this in one of two ways:
+*  Have short timeouts on your local session and redirect to Auth0 at short intervals to re-authenticate. NOTE: this can be done by calling `checkSession` from the client which does this redirect in a hidden iFrame.  If you take the hidden iFrame approach you need to be aware of rate limits and third-party cookie issues.
+* Handle this entirely at the application level by providing your applications a way to notify all other applications when a logout occurs.
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/logout-auth0.md b/ja-jp/articles/logout/guides/logout-auth0.md
new file mode 100644
index 0000000000..638f134afd
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-auth0.md
@@ -0,0 +1,30 @@
+---
+title: Log Users Out of Auth0
+description: Learn how to force a user to log out of Auth0 using the Auth0 logout endpoint. 
+topics:
+  - logout
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of Auth0
+
+The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways:
+
+1. **Clears the Single Sign-on (SSO) cookie in Auth0.** To force a logout, redirect the user to the following URL:
+
+```text
+https://${account.namespace}/v2/logout
+```
+
+2. **Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google).** To [log the user out of both Auth0 *and* the IdP](/logout/guides/logout-idps), you must include the `federated` querystring parameter with your call to the logout endpoint.
+
+Redirecting the user to this URL clears all Single Sign-on (SSO) cookies set by Auth0 for the user.
+
+## Keep reading
+
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/logout-idps.md b/ja-jp/articles/logout/guides/logout-idps.md
new file mode 100644
index 0000000000..c62112ac76
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-idps.md
@@ -0,0 +1,73 @@
+---
+title: Log Users Out of Identity Providers
+description: Learn how to force a user to log out of their identity provider. 
+topics:
+  - logout
+  - federated-logout
+contentType: how-to
+useCase:
+  - manage-logout
+---
+# Log Users Out of Identity Providers
+
+Although this is not common practice, you can force the user to log out of their identity provider. 
+
+For many providers, Auth0 will give you this behavior by simply having you add the `federated` query parameter to the redirect to `/v2/logout`. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+To do this, add a `federated` querystring parameter to the logout URL:
+
+```text
+https://${account.namespace}/v2/logout?federated
+```
+
+## Limitations
+
+There are a few limitations to federated logout to keep in mind:
+ 
+* No validation is performed on any URL provided as a value to the returnTo parameter, nor any querystring or hash information provided as part of the URL.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the returnTo parameter differently and for some, it will not work. Please check your social provider's settings to determine how it will behave.
+
+* If you are working with social identity providers such as Google or Facebook, you must set your Client ID and Secret for these providers in the Dashboard for the logout to function properly.
+
+* If you are an Auth0 Enterprise user, you will typically have SSO enabled for multiple applications, for example, SharePoint, a few .NET applications, a few Java applications, Zendesk, etc. In this case, it's very common that when users sign out, this needs to happen for all of their applications.  
+
+::: panel-warning Single logout
+Redirecting users to the Auth0 `logout` endpoint does not cover all scenarios where users need to be signed out of all of the applications they use. Other than when Auth0 is using SAML, Auth0 does not natively support Single Logout. Single Logout can be achieved by having each application check the active session after their tokens expire, or you can force log out by terminating your application sessions at the application level. 
+
+You can configure Single Logout URLs for SAML that can log out of all SAML sessions, although Auth0 supports front-channel SAML SLO only, Auth0 does not support back-channel SLO.
+Auth0 provides quickstart guides that show you how to implement logout functionality in your specific type of application and provides sample code. These quickstarts support native/mobile apps, single-page apps, and web apps. 
+:::
+
+## Federated logout support
+
+The following identity providers support federated logout:
+
+* Evernote
+* Facebook
+* Fitbit
+* GitHub
+* Google
+  * Apps
+  * OAuth 2.0
+* Microsoft
+  * Active Directory Federation Services
+  * Office 365
+  * Windows Azure Active Directory
+  * Windows Live
+* Salesforce/Salesforce Sandbox
+* Twitter
+* Yahoo
+* Yammer
+
+::: panel-warning Clear your application session
+The Auth0 [logout endpoint](/api/authentication?javascript#logout) logs you out from Auth0 and, optionally, from your identity provider. It does *not* log you out of your application! This is something that you must implement on your side. You need to log out the user from your application by clearing their session. 
+:::
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
+* [Sessions](/sessions)
diff --git a/ja-jp/articles/logout/guides/logout-saml-idps.md b/ja-jp/articles/logout/guides/logout-saml-idps.md
new file mode 100644
index 0000000000..a2bf39e8c8
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-saml-idps.md
@@ -0,0 +1,44 @@
+---
+title: Log Users Out of SAML Identity Providers
+description: Learn how to log users out of an external SAML identity provider. 
+topics:
+  - logout
+  - SAML-logout
+  - identity-providers
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of SAML Identity Providers
+
+To logout users from an external SAML identity provider, you must configure a [SAML logout URL](/saml-sp-generic#1-obtain-information-from-idp) in the SAML connection settings. If you don't configure a logout URL, Auth0 will use the __SAML login URL__.
+
+Auth0 will initiate a logout by sending a SAML logout request to the external identity provider if the `federated` query string parameter is included when redirecting the user to the [logout endpoint](/api/authentication?javascript#logout).
+
+The external SAML identity provider will need to know where to send SAML logout requests (if initiating the logout) and responses. The __SingleLogout service URL__ that will consume this SAML messages is the following:
+
+```text
+https://${account.namespace}/logout
+```
+
+When viewing the logout metadata for your Auth0 Connection, you will notice two `SingleLogoutService` bindings with the above URL.
+
+* **SAML Request Binding** (also known as the **Protocol Binding**): Used for the transaction from Auth0 to the IdP. If the IdP provides a choice, select `HTTP-Redirect`.
+   
+* **SAML Response Binding**: Used for transactions from the IdP to Auth0. It indicates to Auth0 what protocol the IdP will use to respond. If the IdP provides a choice, indicate that `HTTP-POST` should be used for Authentication Assertions.
+
+::: panel Unable to Logout Using a SAML Identity Provider
+When logging in (with Auth0 as the SAML Service Provider), the SAML identity provider uniquely identifies the user's session with a `SessionIndex` attribute in the `AuthnStatement` element of the SAML assertion. The `SessionIndex` value must be used again when the user logs out.
+
+Occasionally, the `SessionIndex` value may not be present in the initial login assertion. When the user logs out, the request to the SAML identity provider will fail due to the missing value.
+
+In these cases, Auth0 may not be able to complete a logout request to the SAML identity provider even if the logout URL has been configured correctly.
+:::
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/redirect-users-after-logout.md b/ja-jp/articles/logout/guides/redirect-users-after-logout.md
new file mode 100644
index 0000000000..1d7fc0ad91
--- /dev/null
+++ b/ja-jp/articles/logout/guides/redirect-users-after-logout.md
@@ -0,0 +1,85 @@
+---
+title: Redirect Users After Logout
+description: Learn how to redirect users after logout. 
+topics:
+  - logout
+  - redirect
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Redirect Users After Logout
+
+You can redirect users to a specific URL after they logout. You will need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings.
+
+1. Add a `returnTo` querystring parameter with the target URL as the value. Encode the target URL being passed in. For example, to redirect the user to `http://www.example.com` after logout, make the following request:
+
+   ```text
+   https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com
+   ```
+
+2. Add the non-encoded `returnTo` URL (for these examples, it is `http://www.example.com`) as an **Allowed Logout URLs** in one of two places:
+
+   - **Tenant Settings**: For logout requests that do not include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the [Advanced tab of your Tenant Settings](${manage_url}/#/tenant/advanced). For example:
+
+     ```text
+     https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com
+     ```
+
+     To add a list of URLs that the user may be redirected to after logging out at the tenant level, go to the [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced) of the Auth0 Dashboard.
+
+     ![Tenant level logout screen](/media/articles/logout/tenant-level-logout.png)
+
+   - **Auth0 Application Settings**: For logout requests that include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 app that is associated with the specified `CLIENT_ID`. For example:
+
+     ```text
+     https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com&client_id=CLIENT_ID
+     ```
+    
+     To redirect the user after they log out from a specific application, you must add the URL used in the `returnTo` parameter of the redirect URL to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 application that is associated with the `CLIENT_ID` parameter.
+
+    ![Application level logout screen](/media/articles/logout/client-level-logout.png)
+
+   When providing the URL list, you can:
+
+   * Specify multiple, valid, comma-separated URLs.
+   * Use `*` as a [wildcard for subdomains](/applications/reference/wildcard-subdomains) (such as `http://*.example.com`).
+
+::: warning
+If the `client_id` parameter is included and the `returnTo` URL is NOT set, the server returns the user to the first Allowed Logout URLs set in the Dashboard.
+:::
+
+::: note
+In order to avoid validation errors, make sure that you include the protocol part of the URL. For example, setting the value to `*.example.com` will result in a validation error, so you should use `http://*.example.com` instead.
+:::
+
+## Limitations
+
+* The validation of URLs provided as values to the `returnTo` parameter, the querystring, and hash information provided as part of the URL are not taken into account.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the `returnTo` parameter differently and for some it will not work. Please check your social provider's settings to ensure that they will accept the `returnTo` parameter and how it will behave.
+
+* The URLs provided in the **Allowed Logout URLs** list are case-sensitive, so the URL used for logouts must match the case of the logout URL configured on the dashboard. However, do note that the scheme and host parts are case insensitive. For example, if your URL is `http://www.Example.Com/FooHoo.html`, the `http://www.Example.Com` portion is case insensitive, while the `FooHoo.html` portion is case sensitive.
+
+::: note
+If you are working with social identity providers such as Google or Facebook, you must set your `Client ID` and `Secret` for these providers in the [Dashboard](${manage_url}) for the logout to function properly.
+:::
+
+## Additional requirements for Facebook
+
+If you are using Facebook, you will also need to encode the `returnTo` parameter. For example:
+
+```text
+https://${account.namespace}/v2/logout?federated&
+      returnTo=https%3A%2F%2F${account.namespace}%2Flogout%3FreturnTo%3Dhttp%3A%2F%2Fwww.example.com
+      &access_token=[facebook access_token]
+```
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/index.md b/ja-jp/articles/logout/index.md
new file mode 100644
index 0000000000..55c25449b5
--- /dev/null
+++ b/ja-jp/articles/logout/index.md
@@ -0,0 +1,64 @@
+---
+description: Understand how logout works with Auth0. 
+topics:
+  - logout
+contentType: index
+useCase:
+  - manage-logout
+---
+
+# Logout
+
+You can log a user out of the Auth0 session and (optionally) from the identity provider (IdP) session. When you're implementing the logout functionality, there are typically three session layers you need to consider:
+
+1. **Application Session Layer**: The first layer is the session inside your application. Though your application uses Auth0 to authenticate users, you'll still need to track that the user has logged in to your application. In a regular web application, you achieve this by storing information inside a cookie. [Log users out of your applications](/logout/guides/logout-applications) by clearing their session. You should handle the application session in your application.
+
+2. **Auth0 Session Layer**: Auth0 also maintains a session for the user and stores their information inside a cookie. The next time a user is redirected to the Auth0 Lock screen, the user's information will be remembered. [Log users out of Auth0](/logout/guides/logout-auth0) by clearing the Single Sign-on (SSO) cookie.
+
+3. **Identity Provider Session Layer**: The last session layer is the identity provider layer (for example, Facebook or Google). When users attempt to sign in with any of these providers and they are already signed into the provider, they will not be prompted again to sign in. The users may be asked to give permission to share their information with Auth0 and, in turn, your application. It is not necessary to log the users out of this session layer, but you can force the logout. (For more information, see [Log Users Out of Identity Providers](/logout/guides/logout-idps) and [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps).)
+
+## Quickstarts for logout functionality
+
+For guidance on how to implement logout functionality in your specific type of application and sample code, refer to our [Quickstarts](/quickstarts) for the following types of applications:
+
+### Native/Mobile Apps
+
+* [Android](/quickstart/native/android/03-session-handling#log-out)
+* [Chrome Extension](/quickstart/native/chrome)
+* [Cordova](/quickstart/native/cordova)
+* [Ionic 3+](/quickstart/native/ionic3)
+* [iOS Objective-C](/quickstart/native/ios-objc/03-user-sessions#on-logout-clear-the-keychain)
+* [iOS Swift](/quickstart/native/ios-swift/03-user-sessions#on-logout-clear-the-keychain)
+
+### Single-Page Apps
+
+* [Angular 2+](/quickstart/spa/angular2)
+* [JavaScript](/quickstart/spa/vanillajs)
+* [React](/quickstart/spa/react)
+* [Vue](/quickstart/spa/vuejs)
+
+### Web Apps
+
+* [ASP.NET (OWIN)](/quickstart/webapp/aspnet-owin/01-login#add-login-and-logout-methods)
+* [ASP.NET Core](/quickstart/webapp/aspnet-core/01-login#add-login-and-logout-methods)
+* [Java](/quickstart/webapp/java)
+* [Java Spring MVC](/quickstart/webapp/java-spring-mvc)
+* [Java Spring Security](/quickstart/webapp/java-spring-security-mvc)
+* [NancyFX](/quickstart/webapp/nancyfx)
+* [Node.js](/quickstart/webapp/nodejs)
+* [PHP (Laravel)](/quickstart/webapp/laravel)
+* [PHP (Symfony)](/quickstart/webapp/symfony)
+* [Python](/quickstart/webapp/python#6-logout)
+* [Ruby on Rails](/quickstart/webapp/rails/02-session-handling#logout-action)
+
+## Redirect users after logout
+
+After users log out, you can [redirect users](/logout/guides/redirect-users-after-logout) to a specific URL. You need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings.
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logs/concepts/logs-admins-devs.md b/ja-jp/articles/logs/concepts/logs-admins-devs.md
new file mode 100644
index 0000000000..802913210f
--- /dev/null
+++ b/ja-jp/articles/logs/concepts/logs-admins-devs.md
@@ -0,0 +1,37 @@
+---
+description: Examples of how logs are used if you are an administrator or a developer. 
+topics:
+  - logs
+contentType: concept
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# Administrator and Developer Log Usage Examples
+
+## Administrator
+
+If you are an administrator, there are many helpful metrics and bits of information you can gather from the Logs. If a customer has raised a support ticket that they are unable to sign in to your service or application, you can verify in the logs that they have indeed tried, and are attempting in the manner they say they are. They may think it's a password issue, but you may discover they never completed setting up their multi-factor authentication (MFA). Additionally, Logs can help expose some business metrics you may not have had available before. These could include:
+
+- Finding prime times of usage for different regions
+- Identifying a target audience
+- Detecting patterns in user behavior that can be optimized
+- Identifying problematic actors by IP address
+- Calculating frequency and type of Anomaly Detection triggers
+
+ The deeper the analysis, the more you can learn about your customers and your business.
+
+## Developer
+
+When debugging an issue, or setting up an integrations, logs are as good as gold. You can utilize the logs as a history of events to see where a flow may be broken, or where customers are getting confused. You can also detect nefarious behavior, or verify that Auth0 anomaly detection is being triggered during questionable behavior. We support searching the logs for specific events using our Dashboard or Management API directly, but also support exporting logs to your existing log processing systems, like Splunk or Sumo Logic, for deeper analysis over time. See [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) for more information. 
+
+## Keep reading
+
+* [Log Data Retention](/logs/references/log-data-retention)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md b/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md
new file mode 100644
index 0000000000..8c803ae79c
--- /dev/null
+++ b/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md
@@ -0,0 +1,79 @@
+---
+title: Migrate from Logs Search v2 to v3
+description: Learn how to migrate from Auth0 Logs Search v2 to v3.
+topics:
+  - logs
+  - search
+contentType: how-to 
+useCase:
+  - logs
+---
+
+# Migrate from Logs Search v2 to v3
+
+To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3.
+Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt-in for v3 during the provided grace period.
+
+## Am I affected by the migration?
+
+Affected customers are those who meet all of the following criteria:
+* With tenants created before or on May 21st, 2019
+* With tenants hosted in Auth0's public cloud in the AU or EU regions
+* Who use the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or the [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoint with the parameter `include_totals=true` or the `q` parameter.
+* Who paginate through more than 1000 results
+* Who use the Delegated Admin Extension
+  * Older versions of the extension will continue to work after your Tenant is migrated to Logs Search Engine v3, however you might notice pagination totals being incorrect when viewing logs. Updating to v3.7 of the extension will address this.
+
+The following tenants are NOT affected:
+* Cloud customers in the US region. The US region has been fully migrated and is already using Search Engine v3.
+* Private Cloud customers (Migration for Private Cloud customers will begin at a later date).
+* Cloud tenants in the EU and AU regions that:
+  * are not using the `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` endpoints of Management API at all.
+  * are consuming the logs from the Dashboard Logs section only.
+  * are using the `GET /api/v2/logs endpoint` with the by checkpoint method (using `from` parameter).
+  * are consuming logs using any of the [Auth0 Logs to External Service Dashboard extensions](/extensions#export-auth0-logs-to-an-external-service) (which use the by checkpoint method).
+  
+## How can I check to see if I've migrated all my queries?
+
+You can search your tenant logs with the following to look for queries that would throw errors after you migrate to v3:
+
+```
+type:depnote AND description:*logs*
+```
+
+These log entries include a `description` field that specifies the deprecated behavior you're using. You can also check the `details.request.path` and `client_name` fields to see what application is calling either `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs`.
+
+::: note
+Auth0 generates only one log of the same **type** and **description** every 60 minutes. No matter how many calls you make using deprecated features to the impacted endpoints, you will still see a single log for *each* deprecated feature each hour.
+
+If you implement changes to your queries, you'll need to allow 60 minutes to elapse before you can conclusively determine that the lack of new `depnote` logs means the deprecated behavior has been removed from your code.
+:::
+
+## What’s changing?
+
+The breaking changes are minor, but you should review your queries to make sure the results you are getting are as expected.
+
+Breaking changes are related to:
+#### Pagination
+*  When your tenant is migrated to logs v3 the value of the `total` field returned in the summary result when calling `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` is changing. When searching for logs using search engine v2, the totals field in your results tells you the number of logs that match the query you provided. However, in v3, the totals field tells you how many logs are returned in the page (similar to what the length field returns). To avoid any potential disruption, if your application relies on the total field for pagination purposes, you should update your logic to handle this change appropriately. 
+* There is an existing limit of 100 logs per request. When your tenant is migrated to logs v3 you may only paginate through a maximum of 1,000 search results, resulting in calls for anything over 1,000 results returning an error. To avoid any potential disruption, you should review your queries to avoid this limit or handle errors accordingly.
+#### `q` parameter validation
+* The query syntax when using the `q` parameter in the `GET /api/v2/logs` has minor changes that need to be taken into account. When your tenant is migrated to logs v3 this validation will be enforced resulting in this query returning an error. To avoid any potential disruption, you should review your queries to make sure they comply with the supported query syntax.
+* The `q` parameter includes an invalid field. When your tenant is migrated to logs v3 this validation will be enforced resulting in this call returning an error. To avoid any potential disruption, you should review your queries to make sure that only searchable fields are included. 
+
+## How to Migrate?
+
+After reviewing your queries, you can opt-in to Tenant Logs Search Engine v3 via the Dashboard. Go to *Tenant Settings > Advanced*, then scroll down to *Migrations*. Toggle the *Legacy Logs Search V2* switch to off. 
+Toggling this switch to off disables the deprecated logs search engine v2 and forces the use of search engine v3.
+
+::: note
+If you do not see the **Legacy Logs Search V2** toggle, you've already been migrated to v3. No further action is required.
+:::
+
+![](/media/articles/logs/tenant-logs-migration.png)
+ 
+If you need help with the migration, contact us using the [Support Center](https://support.auth0.com/).
+
+## Keep reading
+
+* [Logs](/logs)
diff --git a/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md b/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md
new file mode 100644
index 0000000000..c8cec6a38d
--- /dev/null
+++ b/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md
@@ -0,0 +1,88 @@
+---
+description: Learn how to retrieve logs using the Auth0 Management API get_logs endpoint by checkpoint or by search criteria. 
+topics:
+  - logs
+contentType: how-to
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+
+# Retrieve Logs Using the Management API
+
+You can use the Management API v2 to retrieve your logs using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, which supports two types of consumption: [by checkpoint](/logs#get-logs-by-checkpoint) or [by search criteria](#get-logs-by-search-criteria).
+
+::: note
+We highly recommend using [the checkpoint approach](#get-logs-by-checkpoint) to export logs to the external system of your choice and perform any search or analysis there, as logs stored in our system are subject to the [retention period](/logs/references/log-data-retention). You can use any of the [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) extensions to export the logs to the system of your choice (like Sumo Logic, Splunk or Loggly).
+:::
+
+If you would like to perform a search for specific events you can also use the [search criteria approach](#get-logs-by-search-criteria), which is also the one used by the Management Dashboard.
+
+::: note
+When you query for logs with the [list or search logs](/api/v2#!/Logs/get_logs) endpoint, you can retrieve a maximium of 100 logs per request.
+:::
+
+## Get logs by checkpoint
+
+This method allows to retrieve logs from a particular `log_id`. For searching by checkpoint use the following parameters:
+
+| Parameter | Description |
+| -- | -- |
+| `from` | Log Event Id to start retrieving logs. You can limit the amount of logs using the take parameter. |
+| `take` | The total amount of entries to retrieve when using the from parameter. |
+
+::: note
+When fetching logs by checkpoint, the `q` or any parameter other than `from` and `take` will be ignored. Also the order by date is not guaranteed.
+:::
+
+## Get logs by search criteria
+
+This method retrieves log entries that match the specified search criteria (or list all entries if no criteria is used). To search by criteria use the following parameters:
+
+| Parameter | Description |
+| -- | -- |
+| `q` | Search Criteria using Query String Syntax. See [Query Syntax](/logs/references/query-syntax) for information of how to build the queries. |
+| `page` | The zero-based page number. |
+| `per_page` | The number of entries per page. |
+| `sort` | The field to use for sorting. Use `field:order`, where `order` is `1` for ascending and `-1` for descending. For example `date:-1`. |
+| `fields:` | A comma-separated field list to include or exclude (depending on `include_fields`) from the result. Leave empty to retrieve all fields. |
+| `include_fields` | `true` if the fields specified are to be included in the result, `false` otherwise. Defaults to `true`. |
+
+For the list of fields that can be used in the search query and the `fields` and `sort` parameters, see [Query Syntax: Searcheable fields](logs/references/query-syntax#searchable-fields).
+
+## Limitations
+
+Besides the limitation of 100 logs per request to retrieve logs, you may only paginate through up to 1,000 search results.
+
+If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+
+::: panel Private Cloud Users
+For Private Cloud users searching tenant logs, note that only the following fields are searchable at this time: 
+
+* `user`
+* `connection`
+* `application`
+* `type`
+* `ip`
+
+Use double quotes for exact searches (e.g., `application:"test"` will search for all log entries specific to the application named `test`, but `application:test` will search log entries for applications with test in their name.
+:::
+
+## Other log endpoints
+
+As an alternative or complement to retrieving logs by checkpoint or search criteria using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, you can also use the following endpoints to look for logs:
+
+* [/api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id): Retrieves the single log entry associated with the provided log id.
+* [/api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user): Retrieves log events for a specific user id.
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [Log Data Retention](/logs/references/log-data-retention)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
+* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/guides/view-log-data-dashboard.md b/ja-jp/articles/logs/guides/view-log-data-dashboard.md
new file mode 100644
index 0000000000..fc0cbcaa41
--- /dev/null
+++ b/ja-jp/articles/logs/guides/view-log-data-dashboard.md
@@ -0,0 +1,32 @@
+---
+description: Learn how to view log data in the Auth0 Dashboard for all events that occur including user authentication and administrative actions such as adding and updating applications, connections, and rules.
+topics:
+  - logs
+contentType: how-to
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# View Log Data in the Dashboard
+
+The **Logs** page of the [Dashboard](${manage_url}/#/logs) displays all events that occur, including user authentication and administrative actions such as adding/updating Applications, Connections, and Rules.
+
+![Log Search](/media/articles/logs/dashboard-logs.png)
+
+Please note that administrative actions will show up in the logs as `API Operation` events.
+
+## Event type filters
+
+You can choose a [filter](/logs/references/log-event-filters) for log error, warning, and success events. For example, you can choose the **Deprecation Notice** warning to filter logs related to deprecation warnings.
+
+![Log Event Filter](/media/articles/logs/log-event-filter.png)
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [Log Data Retention](/logs/references/log-data-retention)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
+* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/index.md b/ja-jp/articles/logs/index.md
new file mode 100644
index 0000000000..b8a85708f2
--- /dev/null
+++ b/ja-jp/articles/logs/index.md
@@ -0,0 +1,29 @@
+---
+description: Understand how Auth0 logs work.
+url: /logs
+classes: topic-page
+topics:
+  - logs
+contentType: index
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# Logs
+
+Using the [Dashboard](${manage_url}/#/logs) or the [Management API logs endpoint](/api/v2#!/Logs/get_logs), you can pull log data on actions performed by administrators using the Dashboard, operations performed via the Management API, and authentications made by your users.
+
+::: warning
+Auth0 does not provide real-time logs for your tenant. While we do our best to index events as they arrive, you may see some delays.
+:::
+
+<%= include('../_includes/_topic-links', { links: [
+  'logs/streams',
+  'logs/references/log-data-retention',
+  'logs/guides/view-log-data-dashboard',
+  'logs/references/log-event-filters',
+  'logs/guides/retrieve-logs-mgmt-api',
+  'logs/references/log-event-type-codes',
+  'logs/references/query-syntax',
+  'logs/concepts/logs-admins-devs'
+] }) %>
diff --git a/ja-jp/articles/logs/references/log-data-retention.md b/ja-jp/articles/logs/references/log-data-retention.md
new file mode 100644
index 0000000000..4ea7b2c72d
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-data-retention.md
@@ -0,0 +1,58 @@
+---
+title: Log Data Retention
+description: Describes how long log data is stored depending on your Auth0 plan.
+topics:
+  - logs
+  - log-data
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Data Retention
+
+Auth0 provides event logging capability and you can scan logs to identify event anomalies. Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services allows you to retain logs outside of this timeframe, and will also provide for log aggregation across your organization.
+
+To understand how you will use the Auth0 logs in your situation, review the log data retention period for your subscription level.
+
+Plan | Log Retention
+-----|--------------
+Free | 2 days
+Developer | 2 days
+Developer Pro | 10 days
+Enterprise | 30 days
+
+You can implement an Auth0 log data export extension to send log data to an external log analytics service. For example, you can use log files for troubleshooting and detecting intermittent errors that may be hard to find with quality assurance testing. You may also want log data in case forensic data is ever needed for security purposes. Log data can also provide comprehensive analytics to help you see patterns in usage trends and anomaly detection triggers.
+
+Auth0 extensions support following third-party services:
+
+- [Application Insights](/extensions/application-insight)
+- [AWS Cloudwatch](/extensions/cloudwatch)
+- [Azure Blob Storage](/extensions/azure-blob-storage)
+- [Logentries](/extensions/logentries)
+- [Loggly](/extensions/loggly)
+- [Logstash](/extensions/logstash)
+- [Mixpanel](/extensions/mixpanel)
+- [Papertrail](/extensions/papertrail)
+- [Sumo Logic](/extensions/sumologic)
+- [Splunk](/extensions/splunk)
+
+You can also export logs to the following services using Auth0 Rules:
+
+* [Keen](/monitoring/guides/send-events-to-keenio)
+* [Segment](/monitoring/guides/send-events-to-segment)
+* [Splunk](/monitoring/guides/send-events-to-splunk)
+
+## Rate limits exceeded and other errors
+
+Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You can set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you can scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls. (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)).
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/references/log-event-filters.md b/ja-jp/articles/logs/references/log-event-filters.md
new file mode 100644
index 0000000000..6faa84fbf8
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-event-filters.md
@@ -0,0 +1,148 @@
+---
+title: Log Event Filters
+description: Lists the log filters for errors, warnings, and success events. 
+topics:
+  - logs
+  - log-data
+  - log-filter
+contentType:
+  - reference
+useCase:
+  - manage-logs
+  - filter-log-events
+---
+# Log Event Filters
+
+You can filter logs for errors, warnings, and success events in the [Dashboard](${manage_url}/#/logs) when you click the **Filter** down arrow. 
+
+## Error event filters
+
+| Filter | Description |
+| -- | -- |
+| Block Account | IP blocked for >10 failed attempts to login to single account |
+| Blocked IP Address | IP blocked for >100 failed login attempts or >50 signup attempts |
+| Breached password | Attempted login with a leaked password |
+| Connector Offline | AD/LDAP Connector is offline |
+| Device Confirmation Canceled by User | User did not confirm device |
+| Error sending MFA Push Notification | Push notification for MFA failed |
+| Error sending MFA SMS | SMS for MFA failed |
+| Failed API Operation | Operation on API failed |
+| Failed Change Email | Failed to change user email |
+| Failed Change Password | Failed to change user password |
+| Failed Change Password Request | Change password request failed |
+| Failed Change Phone Number | Failed to change user phone number |
+| Failed Change Username | Failed to change username |
+| Failed Connector Provisioning | Failed to provision a AD/LDAP connector |
+| Failed Delegation | Failed to generate delegation token |
+| Failed Exchange | Token Exchange |
+| Failed Exchange | Native Socal Login |
+| Failed Exchange | Authorization Code for Access Token |
+| Failed Exchange | Client Credentials for Access Token |
+| Failed Exchange | Password for Access Token |
+| Failed Exchange | Refresh Token for Access Token |
+| Failed Exchange | Password and OOB Challenge for Access Token |
+| Failed Exchange | Password and OTP Challenge for Access Token |
+| Failed Exchange | Password and MFA Recovery code for Access Token |
+| Failed Exchange | Device Code for Access Token |
+| Failed Login | User failed to login |
+| Failed Login (invalid email/username) | User failed to login due to invalid username |
+| Failed Login (wrong password) | User failed to login due to invalid password |
+| Failed Logout | User logout failed |
+| Failed Post Change Password Hook | Post-change password hook failed |
+| Failed Post User Registration Hook | Post user registration hook failed |
+| Failed Sending Notification | Failed to send email notification |
+| Failed Signup | Sign up failed |
+| Failed Silent Auth | Silent authentication failed |
+| Failed User Deletion | User deletion failed |
+| Failed Verification Email | Failed to send verification email |
+| Failed Verification Email Request | Failed to process verification email request |
+| Failed CORS | Origin is not in the Allowed Origins list for the specified application |
+| Failed by Connector | AD/LDAP Connector Failure |
+| Failed cross origin authentication | Cross-origin authentication failed |
+| Failed device activation | Failed to activate device |
+| Failed device authorization request | Device authorization request failed |
+| MFA Enrollment start failed | Multi-factor authentication enroll failed |
+| OTP Auth failed | One-time password authentication failed |
+| OTP Auth rejected | One-time password authentication rejected |
+| Rate Limit on API | Maximum number of requests to the Authentication API in given time has been reached |
+| Recovery failed | Multi-factor recovery code failed |
+| Second factor email failed | Email for MFA failed |
+| Too Many Calls to /delegation | Rate limt exceeded to /delegation endpoint |
+| Too Many Calls to /userinfo | Rate limit exceeded to /userinfo endpoint |
+| Too Many Invalid Device Codes | Rate limit exceeded for invalid device codes |
+
+## Warning event filters 
+
+| Filter | Description |
+| -- | -- |
+| Deprecation Notice | Feature is deprecated |
+| Too many failures | Multi-factor OTP has failed too many times |
+| Too many failures | Mutli-factor recovery code has failed too many times |
+| Users import | Failed to import users |
+| Warning During Login | Warnings during login |
+
+## Success event filters 
+
+| Filter | Description |
+| -- | -- |
+| API Operation | API operation completed successfully |
+| Account unblocked | User block setup by anomay detection has been released |
+| Auth0 OS Update Ended | Auth0 OS update ended |
+| Auth0 OS Update Started | Auth0 OS update started |
+| Auth0 Update Ended | Auth0 update ended |
+| Auth0 Update Launched | New version of Auth0 released |
+| Auth0 Update Started | Auth0 update started |
+| Code Sent | Passwordess login code has been sent |
+| Code/Link Sent | Passwordless lgoin code/link has been sent |
+| Configuration read | PSaaS configuration has been read |
+| Configuration status checked | PSaaS configuration's status has been checked |
+| Configuration updated | PSaaS configuration has been updated |
+| Connector Online | AD/LDAP Connector is online and working |
+| Enroll started | Multi-factor authentication enroll has started |
+| MFA enrollment complete | Multi-factor authentication enroll has completed |
+| MFA settings update | Mutli-factor tenant settings updated |
+| Module switch | Multi-factor module switched |
+| OTP Auth Succeed | One-time password authentication success |
+| Push notification sent | Push notification for MFA successfully sent | 
+| Recovery succeed | Multi-factor recovery code succeeded authorization |
+| SMS Sent | SMS for MFA sent successfully sent |
+| Second factor email sent | Email for MFA successfully sent |
+| Second factor started | Second factor authentication event started for MFA |
+| Success Change Email | Email changed successfully |
+| Success Change Password | Password changed successfully |
+| Success Change Password Request | Change password request succeeded |
+| Success Change Phone Number | Phone number changed successfully |
+| Success Change Username | Username changed successfully |
+| Success Delegation | Delegation token generated successfully |
+| Success Exchange | Authorization Code for Access Token |
+| Success Exchange | Client Credentials for Access Token |
+| Success Exchange | Password for Access Token |
+| Success Exchange | Refresh Token for Access Token |
+| Success Exchange | Token Exchange |
+| Success Exchange | Native Social Login |
+| Success Exchange | Password and OOB Challenge for Access Token |
+| Success Exchange | Password and OTP Challenge for Access Token |
+| Success Exchange | Password and MFA Recovery code for Access Token |
+| Success Exchange | Device Code for Access Token |
+| Success Login | Successful Login |
+| Success Logout | User successfully logged out |
+| Success Post Change Password Hook | Post-change password hook ran successfully |
+| Success Signup | Successful signup |
+| Success Silent Auth | Successful silent authentication |
+| Success Verification Email | Successful verification email |
+| Success Verification Email Request | Successful verification email request |
+| Success cross origin authentication | Successful cross-origin authentication | 
+| Successful User Deletion | User successfully deleted |
+| Unenroll device account | Device used for second factor authentication has been unenrolled |
+| Update device account | Device used for second factor authentication has been updated |
+| User delete | Deleted multi-factor user account |
+| Users import | Successfully imported users |
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/references/log-event-type-codes.md b/ja-jp/articles/logs/references/log-event-type-codes.md
new file mode 100644
index 0000000000..e7496892b8
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-event-type-codes.md
@@ -0,0 +1,132 @@
+---
+title: Log Event Type Codes
+description: Lists the event codes associated with log events. 
+topics:
+  - logs
+  - log-data
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Event Type Codes
+
+The following table lists the codes associated with the each log event.
+
+| **Event Code** | **Event** | **Event Description** | **Additional Info** |
+| --- | --- | --- | --- |
+| `api_limit` | Rate Limit on the Authentication API | The maximum number of requests to the Authentication API in given time has reached. | [Rate Limit Policy](/policies/rate-limits) |
+| `cls` | Code/Link Sent | Passwordless login code/link has been sent | [Passwordless](/connections/passwordless) |
+| `coff` | Connector Offline | AD/LDAP Connector is offline | [Active Directory/LDAP Connector](/connector) |
+| `con` | Connector Online | AD/LDAP Connector is online and working | [Active Directory/LDAP Connector](/connector) |
+| `cs` | Code Sent | Passwordless login code has been sent | [Passwordless](/connections/passwordless) |
+| `depnote` | Deprecation Notice | | |
+| `du` | Deleted User | User has been deleted. | [User Profile](/users/concepts/overview-user-profile) |
+| `f` | Failed Login | | |
+| `fc` | Failed by Connector | | [Active Directory/LDAP Connector](/connector) |
+| `fce` | Failed Change Email | Failed to change user email | [User Profile](/users/concepts/overview-user-profile) |
+| `fco` | Failed by CORS | Origin is not in the Allowed Origins list for the specified application | [Applications](/dashboard/reference/settings-application) |
+| `fcoa` | Failed cross-origin authentication | | |
+| `fcp` | Failed Change Password | | [Changing a User's Password](/connections/database/password-change) |
+| `fcph` | Failed Post Change Password Hook | | |
+| `fcpn` | Failed Change Phone Number | | [User Profile](/users/concepts/overview-user-profile) |
+| `fcpr` | Failed Change Password Request | | [Changing a User's Password](/connections/database/password-change) |
+| `fcpro` | Failed Connector Provisioning | Failed to provision a AD/LDAP connector | [Active Directory/LDAP Connector](/connector) |
+| `fcu` | Failed Change Username | Failed to change username | [User Profile](/users/concepts/overview-user-profile) |
+| `fd` | Failed Delegation | Failed to generate delegation token | [Delegation Tokens](/tokens/delegation) |	
+| `fdeac`   | Failed Device Activation | Failed to activate device. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdeaz`    | Failed Device Authorization Request | Device authorization request failed. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdecc`    | User Canceled Device Confirmation | User did not confirm device. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdu` | Failed User Deletion | | [User Profile](/users/concepts/overview-user-profile) |
+| `feacft` | Failed Exchange | Failed to exchange authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code)
+| `feccft` | Failed Exchange | Failed exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) |
+| `fede`    | Failed Exchange | Failed to exchange Device Code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fens` | Failed Exchange | Failed exchange for Native Social Login | |
+| `feoobft` | Failed Exchange | Failed exchange of Password and OOB Challenge for Access Token | |
+| `feotpft` | Failed Exchange | Failed exchange of Password and OTP Challenge for Access Token | |
+| `fepft` | Failed Exchange | Failed exchange of Password for Access Token | |
+| `fercft` | Failed Exchange | Failed Exchange of Password and MFA Recovery code for Access Token | |
+| `fertft` | Failed Exchange | Failed Exchange of Refresh Token for Access Token | |
+| `ferrt` | Failed Exchange | Failed Exchange of Rotating Refresh Token | |
+| `flo` | Failed Logout | User logout failed | [Logout](/logout) |
+| `fn` | Failed Sending Notification | Failed to send email notification | [Emails](/email) |
+| `fp` | Failed Login (Incorrect Password) | | |
+| `fs` | Failed Signup | | |
+| `fsa` | Failed Silent Auth | | |
+| `fu` | Failed Login (Invalid Email/Username) | | |
+| `fui` | Failed users import | Failed to import users | [User Import/Export](/extensions/user-import-export) |
+| `fv` | Failed Verification Email | Failed to send verification email | [Verification Email](/email/custom#verification-email) |
+| `fvr` | Failed Verification Email Request | Failed to process verification email request | [Verification Email](/email/custom#verification-email) |
+| `gd_auth_failed` | MFA Auth failed | Multi-factor authentication failed. This could happen due to a wrong code entered for SMS/Voice/Email/TOTP factors, or a system failure.  | [Multi-factor Authentication](/mfa) |
+| `gd_auth_rejected` | MFA Auth rejected | A user rejected a Multi-factor authentication request via push-notification. | [Multi-factor Authentication](/mfa) |
+| `gd_auth_succeed` | MFA Auth success | Multi-factor authentication success. | [Multi-factor Authentication](/mfa) |
+| `gd_enrollment_complete` | MFA enrollment complete | A first time MFA user has successfully enrolled using one of the factors.| |
+| `gd_otp_rate_limit_exceed` | Too many failures | A user, during enrollment or authentication, enters an incorrect code more than the maximum allowed number of times. Ex: A user enrolling in SMS enters the 6-digit code wrong more than 10 times in a row.| |
+| `gd_recovery_failed` | Recovery failed | A user enters a wrong recovery code when attempting to authenticate. | [Multi-factor Authentication](/mfa) |
+| `gd_recovery_rate_limit_exceed` | Too many failures | A user enters a wrong recovery code too many times. | [Multi-factor Authentication](/mfa) |
+| `gd_recovery_succeed` | Recovery success | A user successfully authenticates with a recovery code. | [Multi-factor Authentication](/mfa) |
+| `gd_send_pn` | Push notification sent | Push notification for MFA sent successfully sent. | [MFA with Push Notifications](/mfa/concepts/mfa-factors#push-notifications) |
+| `gd_send_sms` | SMS sent | SMS for MFA successfully sent. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) |
+| `gd_send_sms_failure` | SMS sent failures | Attempt to send SMS for MFA failed. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) |
+| `gd_send_voice` | Voice call made | Voice call for MFA successfully made. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) |
+| `gd_send_voice_failure` | Voice call failure | Attempt to make Voice call for MFA failed. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) |
+| `gd_start_auth` | Second factor started | Second factor authentication event started for MFA. | [Multi-factor Authentication](/mfa) |
+| `gd_start_enroll` | Enroll started | Multi-factor authentication enroll has started. | [Multi-factor Authentication](/mfa) |
+| `gd_tenant_update` | Guardian tenant update | | [Hosted MFA Page](/universal-login/multifactor-authentication) |
+| `gd_unenroll` | Unenroll device account | Device used for second factor authentication has been unenrolled. | [Multi-factor Authentication](/mfa) |
+| `gd_update_device_account` | Update device account | Device used for second factor authentication has been updated. | [Multi-factor Authentication](/mfa) |
+| `limit_delegation` | Too Many Calls to /delegation | Rate limit exceeded to `/delegation` endpoint | [API Rate Limit Policy](/policies/rate-limits) |
+| `limit_mu` | Blocked IP Address | An IP address is blocked with 100 failed login attempts using different usernames, all with incorrect passwords in 24 hours, or 50 sign-up attempts per minute from the same IP address. | [Anomaly Detection](/anomaly-detection) |
+| `limit_wc` | Blocked Account | An IP address is blocked with 10 failed login attempts into a single account from the same IP address. | [Anomaly Detection](/anomaly-detection) |
+| `mfar` | MFA Required | A user has been prompted for multi-factor authentication. In the case of Adaptive MFA, details regarding the risk assessment are included. | Available in only [Resource Owner Password Flow](/flows/resource-owner-password-flow). |
+| `pwd_leak` | Breached password | Someone behind the IP address: `ip` attempted to login with a leaked password. | [Anomaly Detection](/anomaly-detection) |
+| `s` | Success Login | Successful login event. | |
+| `sapi` | Success API Operation | | |
+| `sce` | Success Change Email | | [Emails in Auth0](/email) |
+| `scoa` | Success cross-origin authentication | | |
+| `scp` | Success Change Password | | |
+| `scph` | Success Post Change Password Hook | | |
+| `scpn` | Success Change Phone Number | | |
+| `scpr` | Success Change Password Request | | |
+| `scu` | Success Change Username | | |
+| `sd` | Success Delegation | | [Delegation Tokens](/tokens/delegation) |
+| `sdu` | Success User Deletion | User successfully deleted | [User Profile](/users/concepts/overview-user-profile) |
+| `seacft` | Success Exchange | Successful exchange of authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code) |
+| `seccft` | Success Exchange | Successful exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) |
+| `sede`     | Success Exchange | Successful exchange of device code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `sens` | Success Exchange | Native Social Login | |
+| `seoobft` | Success Exchange | Successful exchange of Password and OOB Challenge for Access Token | |
+| `seotpft` | Success Exchange | Successful exchange of Password and OTP Challenge for Access Token | |
+| `sepft` | Success Exchange | Successful exchange of Password for Access Token | |
+| `sercft` | Success Exchange | Successful exchange of Password and MFA Recovery code for Access Token | |
+| `sertft` | Success Exchange | Successful exchange of Refresh Token for Access Token | |
+| `slo` | Success Logout | User successfully logged out | [Logout](/logout) |
+| `ss` | Success Signup | | |
+| `ssa` | Success Silent Auth | | |
+| `sui` | Success users import | Successfully imported users | [User Import/Export](/extensions/user-import-export) |
+| `sv` | Success Verification Email | | |
+| `svr` | Success Verification Email Request | | |
+| `ublkdu` | User login block released | User block setup by anomaly detection has been released | |
+| `w` | Warnings During Login | | |
+
+# Managed Private Cloud Only
+
+These events are only generated in the [Managed Private Cloud](https://auth0.com/docs/private-cloud/managed-private-cloud) deployment model of Auth0.
+
+| **Event Code** | **Event** | **Event Description** | **Additional Info** |
+| --- | --- | --- | --- |
+| `admin_update_launch` | Auth0 Update Launched | |
+| `sys_os_update_end` | Auth0 OS Update Ended | | |
+| `sys_os_update_start` | Auth0 OS Update Started | | |
+| `sys_update_end` | Auth0 Update Ended | | |
+| `sys_update_start` | Auth0 Update Started | | |
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Anomaly Detection](/anomaly-detection)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
diff --git a/ja-jp/articles/logs/references/query-syntax.md b/ja-jp/articles/logs/references/query-syntax.md
new file mode 100644
index 0000000000..c8d5bfe1cb
--- /dev/null
+++ b/ja-jp/articles/logs/references/query-syntax.md
@@ -0,0 +1,129 @@
+---
+title: Log Search Query Syntax
+description: Describes search query syntax using a subset of the Lucene query syntax to refine Auth0 log searches.
+toc: true
+topics:
+  - logs
+  - log-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Search Query Syntax
+
+When searching for logs, you can create queries using a subset of [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) to refine your search.
+
+The query string is parsed into a series of terms and operators:
+
+* A term can be a single word such as `jane` or `smith`.
+* A term can be a phrase surrounded by double quotes (`"customer log"`), which will match all words in the phrase in the same order.
+* A term without a field name will only match [these selected fields](/logs/query-syntax#fields-searchable-against-bare-terms) fields.
+* Multiple terms can be grouped together with parentheses to form sub-queries.
+* All search fields are case sensitive.
+* Operators (`AND`, `OR`, `NOT`) work on all searchable fields.
+
+## Searchable fields
+
+The following list of fields are searchable and case sensitive:
+
+* `log_id`: the id of the log event
+* `date`: The moment when the event occurred.
+* `connection`: The connection name related to the event.
+* `connection_id`: The connection id related to the event.
+* `client_id`: The client id related to the event
+* `client_name`: The name of the client related to the event.
+* `ip`: The IP address from where the request that caused the log entry originated.
+* `user_id`: The user id related to the event.
+* `user_name`: The user name related to the event.
+* `description`: The description of the event.
+* `user_agent`: The user agent that is related to the event.
+* `type`: One of the [possible event types](/logs#log-data-event-listing).
+* `strategy`: The connection strategy related to the event.
+* `strategy_type`: The connection strategy type related to the event.
+* `hostname`: the hostname that is being used for the authentication flow.
+
+## Fields searchable against bare terms
+
+If a search term is entered without a field name, it will only be searched against the following fields:
+
+* `user_name`
+* `connection`
+* `client_name`
+* `type`
+* `ip`
+* `log_id`
+* `description`
+
+## Exact matching
+
+To find exact matches, use double quotes: `description:"Username invalid"`.
+
+For example, to find logs with the description `Username invalid`, use `q=description:"Username invalid"`:
+
+## Wildcards
+
+Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters: `user_name:john*`. They can be used for prefix matching, for example `user_name:j*`. For other uses of wildcards (e.g. suffix matching), literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+
+The question mark character (`?`), is currently not supported.
+
+For example, to find all logs for users whose usernames start with `john`, use `q=user_name:john*`:
+
+## Ranges
+
+You can use ranges in your log search queries. For inclusive ranges use square brackets: `[min TO max]`, and for exclusive ranges use curly brackets: `{min TO max}`.
+
+Curly and square brackets can be combined in the same range expression. You can also use wildcards within ranges.
+
+As an example, to find all logs from December 18, 2018 until the present, use `q=date:[2018-12-18 TO *]`.
+If you'd like to search logs from the beginning of your retention period until, but not including, December 19, 2018, use `q=date:[* TO 2018-12-19}`.
+
+## Example queries
+
+Below are some examples to show the kinds of queries you can make with the Management API.
+
+Use Case | Query
+---------|------
+Search all logs with connections that contains "Pass" | `connection:*pass*`
+Search all logs for users with a user name that contains "fred" | `user_name:*fred*`
+Search all logs with user id's matching exactly "123" | `user_id:"123"`
+Search for all logs with a type starting with "s" | `type:s*`
+Search for user names that start with "jane" and end with "smith" | `user_name:jane*smith`
+Search for all logs in December 2018 | `date:[2018-12 TO 2018-01-01}`
+Search for all logs from December 10, 2018 forward | `date:[2018-12-10 TO *]`
+Search for all logs from January 1, 2019 at 1AM, until, but not including January 1, 2019 at 12:23:45 | `date:[2019-01-01T01:00:00 TO 2019-01-01T12:23:45}`
+
+## Limitations
+
+* If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+* Log fields are not tokenized , so `description:rule` will not match a description with value `Create a rule` nor `Update a rule`. Instead, use `description:*rule`. See [wildcards](#wildcards) and [exact matching](#exact-matching).
+* The `.raw` field extension is not supported. Fields match the whole value that is provided and are not tokenized.
+* To search for a specific value nested in the `details` field, use the path to the field (i.e., `details.request.channel:"https://manage.auth0.com/"`). Bare searches like `details:"https://manage.auth0.com/"` do not work.
+
+## Pagination
+
+When calling the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoints using the `include_totals` parameter, the result is a JSON object containing a summary of the results **and** the requested logs. The JSON object looks something like:
+
+```js
+{
+  "length": 5,
+  "limit": 5,
+  "logs": [...],
+  "start": 0,
+  "total": 5
+}
+```
+
+When searching for logs, the `totals` field tells you how many logs are returned in the page (similar to what the `length` field returns). 
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/streams/amazon-eventbridge.md b/ja-jp/articles/logs/streams/amazon-eventbridge.md
new file mode 100644
index 0000000000..7c9aa10283
--- /dev/null
+++ b/ja-jp/articles/logs/streams/amazon-eventbridge.md
@@ -0,0 +1,86 @@
+---
+title: Amazon EventBridge Log Streams
+description: Learn how to create an event-driven workflow using Amazon EventBridge to send your tenant logs to the targets of your choice, such as AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks.
+toc: true
+topics:
+ - integrations
+ - logs
+ - streams
+ - event-streams
+ - aws
+ - eventbridge
+ - amazon
+contentType: how-to
+---
+# Amazon EventBridge Log Streams
+
+Amazon EventBridge is a serverless event bus that acts as an intermediary allowing you to send data from your applications to AWS services. You can create an event-driven workflow using EventBridge to send your Auth0 tenant logs to the targets of your choice (e.g., AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks).
+
+## Steps
+
+To send Auth0 events to Amazon EventBridge, you will need to:
+
+1. Set up a partner event source (in this case, this is Auth0)
+2. Set up a partner event bus that matches incoming events with the routes to which they should be targeted
+3. Set up rules to route incoming events to your choice of AWS service
+4. Test the integration
+
+You can send events from Auth0 to AWS once you have [matched your partner event source to the partner event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-partner-event-bus.html).
+
+### Set up Auth0 as the partner event source
+
+First, you will need to set up Auth0 for use as the event source in the [Dashboard](${manage_url}).
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+
+2. Navigate to **Logs > Streams**.
+
+3. Click **+ Create Stream**.
+
+4. Select **Amazon EventBridge**, and enter a unique name for your new Amazon EventBridge Event Stream.
+
+5. Create the Event Source by providing your **AWS Account ID** and **AWS Region**. Note that the region you select must match the region in which your Amazon EventBridge resides.
+
+6. Click **Save**. Auth0 provides you with an **Event Source Name**. Make sure to save your **Event Source Name** value because you will be providing it to AWS at a later point to complete the integration.
+
+### Set up event bus in AWS
+
+1. Go to the [Amazon EventBridge partners tab](https://console.aws.amazon.com/events/home?region=us-east-1#/partners) in your AWS account, and make sure you are in the **AWS Region** where the event source was created.
+
+2. Paste the **Event Source Name** in the event source search box to find the newly-created Event Source, and click on it to associate it with an Event Bus.
+**Note**: The Event Source will remain in pending state until it gets associated with an Event Bus, and all the events sent to that Event Source will be dropped.
+
+3. Once you click on the Event Source, click **Associate with Event Bus**.
+
+4. Name the Event Bus the same name as the Event Source. At this point, you can specify permissions for this Event Bus or simply associate it.
+
+### Create EventBridge rules
+
+At this point, the events that you send are available on your Event Bus. However, before you can use the data you send to AWS services, you must [create rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-event-bus.html) that map those events to specific targets.
+
+Amazon EventBridge uses rules, which are definitions specifying how you want incoming events routed to the desired targets. Targets are the services, such as EC2 instances, Lambda functions, Kinesis streams, or ECS tasks, that process the event-driven data that they receive. Data received by targets are JSON-formatted.
+
+A single rule can route to one or more targets (if there are more than one, AWS processes all in parallel).
+
+To create a rule:
+
+1. Go to the [EventBridge page](https://console.aws.amazon.com/events/home?region=us-east-1#/), and click **Create rule**.
+
+2. Provide the name of the Event Bus, and specify your targets.
+
+### Test integration
+
+As soon as Auth0 writes the next tenant log, you should see a copy of the log Auth0 has written in JSON format at the target you defined in your EventBridge rule.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to AWS via a streaming mechanism that sends each event as it is triggered in our system. If EventBridge is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure, and you will see the failure in the **Health** tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/azure-event-grid.md b/ja-jp/articles/logs/streams/azure-event-grid.md
new file mode 100644
index 0000000000..ae1f8b63aa
--- /dev/null
+++ b/ja-jp/articles/logs/streams/azure-event-grid.md
@@ -0,0 +1,113 @@
+---
+title: Azure Event Grid Log Streams
+description: Learn how to create an event-driven workflow using Azure Event Grid and send your tenant logs anywhere within the Azure ecosystem.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: how-to
+---
+
+# Integrate Azure Event Grid with Auth0
+
+Azure Event Grid is a serverless event bus that lets you send event data from any source to any destination.
+
+You can create event-driven workflows using Event Grid to send your Auth0 tenant logs to targets, such as Azure Functions, Event Hubs, Sentinel, and Logic Apps.
+
+For a full list of the event type codes that Auth0 supports, see [Log Event Type Codes](/logs/references/log-event-type-codes).
+
+## Send events from Auth0 to Azure Event Grid
+
+To send Auth0 events to Azure, you must:
+
+1. Enable the Event Grid resource provider.
+2. Set up an event source (in this case, this is Auth0).
+3. Set up an event handler, which is the app or service where the event will be sent.
+
+To learn more, see [Microsoft's Concepts in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/concepts).
+
+### Enable Event Grid resource provider
+
+If you haven’t previously used Event Grid, you will need to register the Event Grid resource provider. If you've used Event Grid before, skip to the next section.
+
+In your Azure portal:
+
+1. Select Subscriptions.
+2. Select the subscription you’re using for Event Grid.
+3. On the left menu, under **Settings**, select Resource providers.
+4. Find `Microsoft.EventGrid`.
+5. Select **Register**.
+6. Refresh to make sure the status changes to `Registered`.
+
+### Set up an Auth0 event source
+
+Use the Auth0 Dashboard to set up Auth0 for use as an event source.
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Azure Event Grid**, and enter a unique name for your new stream.
+5. On the next screen, provide the following settings for your Event Grid stream:
+
+| Setting | Description |
+|---------|-------------|
+| Name | A unique display name to distinguish this integration from other integrations. |
+| Azure Subscription ID | The unique alphanumeric string that identifies your Azure subscription. |
+| Azure Region | The region in which your Azure subscription is hosted. |
+| Resource Group name | The name of the Azure resource group, which allows you to manage all Azure assets within one subscription. |
+
+6. Click **Save**.
+
+#### Activate your Auth0 Partner Topic in Azure
+
+Activating the Auth0 topic in Azure allows events to flow from Auth0 to Azure.
+
+1. Log in to the [Azure Portal](https://portal.azure.com/).
+2. Search `Partner Topics` at the top, and click `Event Grid Partner Topics` under services.
+3. Click on the topic that matches the stream you created in your Auth0 Dashboard.
+4. Confirm that the `Source` field matches your Auth0 account.
+5. Click **Activate**.
+
+#### Subscribe to your Partner Topic
+
+Subscribe to an Event Grid partner topic to tell Event Grid which events to send to your event handler.
+
+1. On the Event Grid partner topic Overview page, select **+ Event Subscription** on the toolbar.
+2. On the Create Event Subscription page:
+    1. Enter a name for the event subscription.
+    2. Select your desired Azure service or WebHook for the Endpoint type.
+    3. Follow the instructions for the particular service.
+    4. Back on the Create Event Subscription page, select Create.
+
+To send events to your topic, please follow the instructions in this article.
+
+### Set up an event handler
+
+Go to your Azure subscription and spin up a service that is supported as an event handler. For a full list of supported event handlers, see [Microsoft's Event Handlers in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/event-handlers).
+
+## Testing
+
+At this point, your Event Grid workflow should be complete.
+
+### Verify the integration
+
+To verify that the integration is working as expected:
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click on your Event Grid stream.
+4. Once on the stream, click the **Health** tab. The stream should be active and as long as you don't see any errors, the stream is working.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will try to redeliver it up to three times. If still unsuccessful, Auth0 will log the failure to deliver, and you will be able see these failures in the Health tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+:::
diff --git a/ja-jp/articles/logs/streams/datadog.md b/ja-jp/articles/logs/streams/datadog.md
new file mode 100644
index 0000000000..6cac684506
--- /dev/null
+++ b/ja-jp/articles/logs/streams/datadog.md
@@ -0,0 +1,96 @@
+---
+title: Datadog Log Streams
+description: Learn how to export your log events in near real-time to Datadog.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: how-to
+---
+
+# Datadog Log Streams
+
+Datadog is a monitoring platform for cloud applications. It brings together data from servers, containers, databases, and third-party services to make your stack entirely observable. You can use it to create monitoring, alerting, and analysis dashboards for Auth0 tenants.
+
+## Prerequisites
+
+To send Auth0 events to Datadog, you will need:
+
+* a `Log Management` plan with Datadog. See [Datadog plans](https://www.datadoghq.com/pricing/).
+* a Datadog API Key. See below.
+* your Datadog dashboard region.
+
+## Steps
+
+To send Auth0 events to Datadog, you will need to:
+
+1. Copy your API Key from Datadog
+2. Set up an Event Stream in Auth0
+
+### Copy API Key from Datadog
+
+1. Log in to the Datadog dashboard.
+2. Navigate to **Integrations** > **APIs**.
+![Integrations Dashboard](/media/articles/logs/datadog/tutorial-1.png)
+3. Expand the API Keys section, and copy the API Key that you would like to use.
+![API Keys Section](/media/articles/logs/datadog/tutorial-2.png)
+
+### Set up Event Stream in Auth0
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Datadog**, and enter a unique name for your new Datadog Event Stream.
+5. On the next screen, provide the following settings for your Datadog Event Stream:
+
+| Setting | Description |
+|---------|-------------|
+| API Key | The Datadog API key you copied from the Datadog dashboard. |
+| Region  | If you are in the Datadog EU site (app.datadoghq.eu), the `Region` should be `EU`; otherwise, it should be `US`. |
+
+![Datadog Settings Form](/media/articles/logs/datadog/tutorial-3.png)
+
+6. Click **Save**.
+7. You're done! When Auth0 writes the next log event, you'll receive a copy of that log event in Datadog with the `source` and `service` set to `auth0`.
+
+### View logs in Datadog
+
+1. Navigate to **Logs** > **Livetail**.
+2. See Auth0 logs by setting the `source` to `auth0`.
+![Datadog Logs Dashboard](/media/articles/logs/datadog/tutorial-4.png)
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will retry delivering it up to three times. If still unsuccessful, Auth0 will log the failure, and you will see these failure in the **Health** tab for your log stream.
+
+## Enhancement to log data
+
+One of the unique values of Datadog as a monitoring tool, specifically when it comes to integrations, is the data enhancement they provide to ensure customers can rely on receiving specific data fields regardless of the system with which they are integrating. As part of this Auth0 Log Streaming integration, Datadog has enhanced our data. The following new fields can be found in our logs when using the Log Streaming integration with Datadog:
+
+| Fields | Auth0 attribute |
+|---------|-------------|
+| Official Log date | `data.date` |
+| `network.client.ip` | `data.ip` |
+| `network.client.geoip` |	`data.ip` (parsed) |
+| `http.useragent` |	`data.user_agent` |
+| `http.useragent_details` |	`data.user_agent` (parsed) |
+| `usr.id` |	`data.user_name` |
+| `usr.name` |	`data.user_name` |
+| `usr.email` |	`data.details.request.auth.user.email` (when available) |
+| `data.type` | `evt.name` |
+| `message` |	Event description (For a list of descriptions, see [Log Event Type Codes](/logs/references/log-event-type-codes).) |
+
+To learn more about Datadog transformations, see:
+
+* For US: [Datadog US Log Pipelines](https://app.datadoghq.com/logs/pipelines)
+* For EU: [Datadog EU Log Pipelines](https://app.datadoghq.EU/logs/pipelines)
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/http-event-to-slack.md b/ja-jp/articles/logs/streams/http-event-to-slack.md
new file mode 100644
index 0000000000..2b245b2d37
--- /dev/null
+++ b/ja-jp/articles/logs/streams/http-event-to-slack.md
@@ -0,0 +1,188 @@
+---
+title: Stream Auth0 Log Events to Slack
+description: Use the HTTP Event Log Streams to send failed events to Slack.
+toc: false
+topics:
+  - logs
+  - streams
+  - event-streams
+  - http-event
+  - Slack
+contentType: how-to
+---
+
+# Send Auth0 Failed Log Events to Slack
+
+This guide explains how to use [Auth0 Log Streaming](/logs/streams) to send specific logged events to Slack. The events sent in this guide include all failures (e.g., logins, signups, token exchange) and limits (e.g., rate limits, anomaly detection).
+
+Using this guide, you will build the following:
+
+![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-diagram.png)
+
+1. Application 1 and 2 both redirect to Auth0 to log in
+2. The login for Application 2 succeeds, but the login for Application 1 fails; both events create a distinct log record
+3. Both applications receive a response from Auth0
+4. These log events are sent together in a JSON payload to the custom webhook
+5. The webhook filters out the successful event
+6. The webhook sends the failed event to Slack
+
+To learn how to adjust the filter used here for different scenarios, see our [Log Event Type Codes](/logs/references/log-event-type-codes) reference.
+
+## What is Slack
+
+Slack is a business communication platform that can be extended using custom applications. Many companies, including Auth0, use Slack for general team communication as well as a notification platform.
+
+## Get started with Slack
+
+Go to [Slack API Applications](https://api.slack.com/apps), and log in to your Slack account. Follow instructions in the [Incoming Webhooks for Slack](https://slack.com/help/articles/115005265063-Incoming-Webhooks-for-Slack) guide to create a Slack endpoint that will accept the failed log events. Make sure to leave your browser tab open or copy the URL provided as you'll need that later in this guide.
+
+## Deploy the webhook
+
+You'll build a simple Express API that provides a single `/api/logs` route accepting POST requests. When any log event happens, it will be sent to this endpoint. If the request is formatted properly, the log events for failures will be parsed and sent to Slack.
+
+ Start with a simple Express application:
+
+```js
+// app.js
+require("dotenv").config();
+
+const express = require("express");
+const http = require("http");
+
+const app = express();
+app.use(express.json());
+
+app.post("/api/logs", require("./api/logs"));
+
+const port = process.env.PORT || 3000;
+http.createServer(app).listen(port, () => {
+  console.log(`Listening on port <%= "${port}" %>`);
+});
+```
+
+Then add the endpoint middleware:
+
+```js
+// api/logs/index.js
+const got = require("got");
+
+module.exports = async (req, res, next) => {
+  const { body, headers } = req;
+
+  if (!body || !Array.isArray(body)) {
+    return res.sendStatus(400);
+  }
+
+  if (headers.authorization !== process.env.AUTH0_LOG_STREAM_TOKEN) {
+    return res.sendStatus(401);
+  }
+
+  const failedLogs = body.filter((log) => {
+    return "f" === log.data.type[0] || /limit/.test(log.data.type);
+  });
+
+  if (failedLogs.length === 0) {
+    return res.sendStatus(204);
+  }
+
+  const reqUrl = process.env.SLACK_WEBHOOK_URL;
+  const reqOpts = {
+    json: {
+      attachments: failedLogs.map((log) => {
+        return {
+          pretext: "*Auth0 log alert*",
+          title: `<%= " ${log.data.description}" %> [type: <%= "${log.data.type}" %>]`,
+          color: "#ff0000",
+          title_link: `https://manage.auth0.com/#/logs/<%= "${log.data.log_id}" %>`
+        };
+      }),
+    },
+  };
+
+  try {
+    const slackResponse = await got.post(reqUrl, reqOpts);
+    res.status(slackResponse.statusCode);
+    return res.end(slackResponse.body);
+  } catch (error) {
+    next(error);
+  }
+};
+```
+
+Finally, add the NPM package file:
+
+```json
+// package.json
+{
+  "dependencies": {
+    "dotenv": "^8.2.0",
+    "express": "^4.17.1",
+    "got": "^10.7.0"
+  },
+  "scripts": {
+    "start": "node app.js",
+  }
+}
+```
+
+To configure this application, you'll also need the following environment variables:
+
+- `SLACK_WEBHOOK_URL`: The URL provided by Slack for your incoming webhook application.
+- `AUTH0_LOG_STREAM_TOKEN`: Optional, but recommended. A long, random string used to protect the endpoint from unauthorized requests. You will use this value in the Auth0 configuration steps below as well.
+
+If you are testing this locally or hosting this endpoint yourself, these can be saved in a `.env` file in the application's root directory. For hosting providers like Heroku, Dokku, and similar, consult the platform's documentation for the correct way to deploy these.
+
+Once configured locally or deployed to your host, you can test the endpoint and its connection to Slack with the following:
+
+```bash
+npm install # If running yourself
+added XX packages from XX contributors in XX.XXs
+
+npm start # If running yourself 
+Listening on port 3000
+
+# Replace the Authorization header below
+curl \
+  --header "Authorization: AUTH0_LOG_STREAM_TOKEN_VALUE" \
+  --header "Content-Type: application/json" \
+  --request POST \
+  --data '[{"data": {"type": "f", "description": "Test failure", "client_id": "TestClientId", "client_name": "Test Client Name", "log_id": "abc1234567890"}}]' \
+  http://localhost:3000/api/logs
+ok
+```
+
+The `ok` above signals that the request was accepted and processed correctly. In Slack, you should see the following message in the channel you configured:
+
+![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-message.png)
+
+## Configure an Auth0 log stream
+
+The final step is to configure Auth0 to send log events to this webhook using an HTTP event stream.
+
+To create a new stream poinint to your deployed Express application, follow the instructions in [HTTP Event](/logs/streams/http-event). Use the following field values:
+
+- **Payload URL**: URL to your deployed webhook like `https://[host domain]/api/logs`
+- **Authorization Token**: Value configured above
+- **Content Type**: Use "application/json"
+- **Content Format**: Use "JSON Array"
+
+Once this is saved, your log stream is ready to use. To test, you'll need to trigger a failing log event. The simplest way to do that is to attempt to log in with an incorrect email or password. If the stream is configured correctly, you should see a Slack message saying:
+
+`Wrong email or password. [type: fu]`
+
+## Troubleshoot
+
+If you're not seeing the Slack message appear after several seconds, you'll need to walk down the same path a log event would:
+
+1. Check the Dashboard **Logs > Search** screen to make sure the record is there.
+2. Check the **Health** tab for the stream ([delivery attempts and retries](/logs/streams/http-event#delivery-attempts-and-retries)).
+3. If the webhook delivery is succeeding, check the logs for your deployed application.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/http-event.md b/ja-jp/articles/logs/streams/http-event.md
new file mode 100644
index 0000000000..a12963907c
--- /dev/null
+++ b/ja-jp/articles/logs/streams/http-event.md
@@ -0,0 +1,52 @@
+---
+title: HTTP Event Log Streams
+description: HTTP Event Log Streams let you export your events in near real-time to your own server.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+ - http-event
+contentType: how-to
+---
+
+# HTTP Event Log Streams
+
+HTTP Event Log Streams let you export your log events to the server or target of your choice. When Auth0 creates a log entry for your tenant, a copy is automatically sent to a given URL via an HTTP POST request.
+
+If you use Amazon Web Services, Auth0 also offers an [AWS EventBridge integration](/logs/streams/amazon-eventbridge).
+
+See our example [HTTP Event Log Stream example using Slack](/logs/streams/http-event-to-slack).
+
+## Create an HTTP Event Stream
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Custom Webhook** and enter a unique name for your new HTTP Event Stream.
+5. On the next screen, provide the following settings for your HTTP Event Stream:
+
+| Setting | Description |
+|---------|-------------|
+| Name | A unique display name to distinguish this integration from other integrations |
+| Payload URL | The URL where the event payloads are sent as HTTP POST requests. |
+| Authorization Token | (Optional) Set in the Authorization header of the request if provided. |
+| Content Type | The media type of the payload that will be delivered to the webhook. |
+
+![Create a new HTTP Event Log Stream](/media/articles/logs/http-event-stream.png)
+
+6. Click **Save**.
+7. You're done! Now when Auth0 writes the next tenant log, you'll receive a copy of that log event as a POST request at the `Payload URL` you provided.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered in our system. If your server is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure to deliver in our system, and you will be able see these failures in the Health tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/index.md b/ja-jp/articles/logs/streams/index.md
new file mode 100644
index 0000000000..73403ee075
--- /dev/null
+++ b/ja-jp/articles/logs/streams/index.md
@@ -0,0 +1,52 @@
+---
+title: Log Streams
+description: Learn about using Log Streams to export your log events in near real-time.
+classes: topic-page
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: index
+---
+
+# Log Streams
+
+Log Streams let you export your log events to a target of your choice given URL or one of our integrations. With Log Streams you can:
+
+* export logs to a tool or service you already use
+* react to events, such as changed passwords or new registrations, with your own business logic by sending log events to custom webhooks
+* send events to Amazon EventBridge or Azure Event Grid
+
+## Log Stream Health
+
+You can troubleshoot potential issues with your stream by looking in the `Health` tab.
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click on a stream.
+4. Select the **Health** tab.
+
+## Log Stream Status
+
+| Status | Description |
+|---------|-------------|
+| Active  | Your stream is enabled with us, and we will attempt to deliver the next log events. |
+| Paused  | You have requested that we stop delivery attempts for the stream. You may click the `Resume Stream` option at any time to change the status back to `Active`. |
+| Disabled | We have disabled your stream because of successive errors. You may click the `Restart Stream` option at any time to change the status back to `Active` and re-attempt delivery for this stream. |
+
+![Pause a Stream](/media/articles/logs/health/pause-a-stream.png)
+
+## Delivery Errors
+
+To help diagnose issues with your stream, you can see the last ten errors we encountered while attempting to deliver logs to your stream within the last 5 days.
+
+![Stream Errors](/media/articles/logs/health/health-errors.png)
+
+<%= include('../../_includes/_topic-links', { links: [
+  'logs/streams/http-event',
+  'logs/streams/http-event-to-slack',
+  'logs/streams/amazon-eventbridge',
+  'logs/streams/datadog',
+  'logs/streams/azure-event-grid'
+] }) %>
diff --git a/ja-jp/articles/mfa/_includes/_authenticator-before-start.md b/ja-jp/articles/mfa/_includes/_authenticator-before-start.md
new file mode 100644
index 0000000000..89d496c5ea
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_authenticator-before-start.md
@@ -0,0 +1,3 @@
+## Prerequisite
+
+Before you can use the MFA APIs, you'll need to enable the MFA grant type for your application. You can enable the MFA grant by going to [Applications > Your Application > Advanced Settings > Grant Types](${manage_url}/#/applications) and selecting MFA.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_configure-sns.md b/ja-jp/articles/mfa/_includes/_configure-sns.md
new file mode 100644
index 0000000000..75d826d044
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_configure-sns.md
@@ -0,0 +1,3 @@
+## Configure SNS for native apps
+
+For your native application to receive push notifications from Guardian, you will need to override the default SNS settings. See [Configure Push Notifications for MFA](/mfa/guides/configure-push) for details.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_enable-push-notifications.md b/ja-jp/articles/mfa/_includes/_enable-push-notifications.md
new file mode 100644
index 0000000000..82be4f2aea
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_enable-push-notifications.md
@@ -0,0 +1,7 @@
+## Enable Guardian push notifications
+
+1. To enable Guardian push notifications for your users, go to the [Multi-factor Auth](${manage_url}/#/guardian) section of the Dashboard. 
+
+2. Toggle the **Push Notification** slider to enable it.
+
+![Enable Push Notifications](/media/articles/mfa/mfa-dashboard.png)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_get_mfa_token.md b/ja-jp/articles/mfa/_includes/_get_mfa_token.md
new file mode 100644
index 0000000000..eda25ae672
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_get_mfa_token.md
@@ -0,0 +1,5 @@
+Depending on when you are triggering enrollment, you can obtain an access token for using the MFA API in different ways: 
+
+- If you are enrolling during authentication, check [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate).
+
+- If you want to let the user enroll a factor at any moment, check [Managing MFA Enrollments](/mfa/guides/mfa-api/manage).
diff --git a/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md b/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md
new file mode 100644
index 0000000000..b0d61e66c7
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md
@@ -0,0 +1 @@
+Get an MFA token following the steps described in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_recovery_codes.md b/ja-jp/articles/mfa/_includes/_recovery_codes.md
new file mode 100644
index 0000000000..e5f6ab8dc8
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_recovery_codes.md
@@ -0,0 +1 @@
+If this is the first time the user is associating an authenticator, you'll notice the response includes `recovery_codes`. Recovery codes are used to access the user's account in the event that they lose access to the account or device used for their second factor authentication. These are one-time usable codes, and new ones are generated as necessary.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_request_association.md b/ja-jp/articles/mfa/_includes/_request_association.md
new file mode 100644
index 0000000000..7d7ce5babc
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_request_association.md
@@ -0,0 +1 @@
+Make a `POST` request to the `/mfa/associate` endpoint to enroll the user's authenticator. The Bearer Token required by this endpoint is the MFA token obtained in the previous step.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_successful_challenge.md b/ja-jp/articles/mfa/_includes/_successful_challenge.md
new file mode 100644
index 0000000000..c68b5367db
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_successful_challenge.md
@@ -0,0 +1,11 @@
+If the call was successful, you'll receive a response in the below format, containing the Access Token:
+
+```
+{
+  "id_token": "eyJ...i",
+  "access_token": "eyJ...i",
+  "expires_in": 600,
+  "scope": "openid profile",
+  "token_type": "Bearer"
+}
+```
diff --git a/ja-jp/articles/mfa/_includes/_successful_confirmation.md b/ja-jp/articles/mfa/_includes/_successful_confirmation.md
new file mode 100644
index 0000000000..1159ca96d2
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_successful_confirmation.md
@@ -0,0 +1,15 @@
+If the call was successful, you'll receive a response in the below format, containing the Access Token:
+
+```
+{
+  "id_token": "eyJ...i",
+  "access_token": "eyJ...i",
+  "expires_in": 600,
+  "scope": "openid profile",
+  "token_type": "Bearer"
+}
+```
+
+At this point, the authenticator is fully associated and ready to be used, and you have the authentication tokens for the user.
+
+You can check at any point to verify whether an authenticator has been confirmed by calling the [`mfa/authenticators` endpoint](/mfa/guides/mfa-api/manage#list-authenticators). If the authenticator is confirmed, the value returned for `active` is `true`.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_test-setup.md b/ja-jp/articles/mfa/_includes/_test-setup.md
new file mode 100644
index 0000000000..ea25a2a065
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_test-setup.md
@@ -0,0 +1,3 @@
+::: warning
+The following steps will add text-message-based multi-factor to the login flow for the tenant in which you're working. We **highly** recommend testing this setup on a [staging or development server](/dev-lifecycle/setting-up-env) before making the changes to your production login flow.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/concepts/guardian.md b/ja-jp/articles/mfa/concepts/guardian.md
new file mode 100644
index 0000000000..65d97d5a10
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/guardian.md
@@ -0,0 +1,96 @@
+---
+title: Auth0 Guardian
+description: Understand how Guardian works and how Guardian SDK helps you build your own authenticator and Guardian-like applications.
+topics:
+  - mfa
+  - guardian
+  - android
+  - iOS
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Auth0 Guardian
+
+Auth0 multi-factor authentication (MFA) supports these authentication factors:
+
+* One-time password (OTP)
+* SMS
+* Voice
+* Push
+* Duo
+* Email
+
+Auth0 Guardian is a mobile app that can deliver push notifications to a user’s pre-registered device - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the press of a button. It can also generate one-time passwords if that factor is preferred.
+
+The push factor is offered with the Guardian mobile app, available for both iOS and Android. In addition, the technology is also available as whitelabelled Guardian SDK which can be used in custom mobile applications to act as second factor push responder. 
+
+Auth0 Guardian is available on ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) and the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833?mt=8)).
+
+::: note
+See the documentation for [Apple Push Notification service (APNs)](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html) for details on setting up APNs. 
+:::
+
+## How it works
+
+Instead of integrating with each vendor-specific push notification service, Auth0 push notification is implemented using AWS Simple Notification Service (SNS) which handles the vendor specific integration. 
+
+![Guardian Functionality](/media/articles/mfa/guardian-functionality.png)
+
+## Guardian and push notifications
+
+When enabling push, end-users will need to have Auth0 Guardian or a custom application built with the Guardian SDK installed in their device. The app is sent push notifications when the user attempts to authenticate, and the user must respond to it in order to login, ensuring that they not only know their login information but also possess the device set up for MFA.
+
+End users will be prompted to download Auth0 Guardian when trying to sign up or log in to your application. Once they indicate that they have successfully downloaded the app, a QR code will appear on screen. They will have a short amount of time in which to scan the code with the designated app. Once this is done, they should see a confirmation screen.
+
+Once this is all set up, when the user attempts to authenticate as normal, their device will receive a push notification via the app, and once they approve the request, they will be logged in.
+
+
    Guardian Push
    
+
+## Guardian and One-Time Passwords
+
+![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png)
+
+Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. 
+
+Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code:
+
+
    Google Authenticator OTP
    
+
+And enter the code at the prompt:
+
+![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png)
+
+Your users will need to have an OTP Authenticator app installed in their mobile devices.
+
+## Guardian SDKs
+
+You can [install the Guardian SDK](/mfa/guides/guardian/install-guardian-sdk), available for [iOS](/mfa/guides/guardian/configure-guardian-ios) and [Android](/mfa/guides/guardian/configure-guardian-android) to build your own whitelabel multi-factor authentication application with complete control over the branding and look-and-feel.
+
+With the Guardian SDK, you can build your own custom mobile applications that works like Guardian or integrate some Guardian functionalities, such as receiving push notifications in your existing mobile applications.
+
+A typical scenario could be for a banking app. You can use the Guardian SDK in your existing mobile app to receive and confirm push notifications when someone performs an ATM transaction.
+
+See [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js) for more information.
+
+## Migration to Firebase Cloud Messaging
+
+Auth0’s Guardian SDKs for iOS and Android help you create custom mobile apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. 
+
+The [Android SDK](/mfa/guides/guardian/guardian-android-sdk) library was built to send push notifications using Google Cloud Messaging, which [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced with Firebase Cloud Messaging. Google Cloud Messaging will stop working on April 11th 2019. **Note that existing applications should [keep working as-is](https://aws.amazon.com/blogs/messaging-and-targeting/the-end-of-google-cloud-messaging-and-what-it-means-for-your-apps/)**.
+
+You can learn more about how to migrate from GCM to FCM by following [Google’s documentation](https://developers.google.com/cloud-messaging/android/android-migrate-fcm).
+
+The main difference between sending notifications to GCM and to FCM is the payload received in the notification. While it was previously possible for customers using the Android SDK to adapt the payload received before calling the SDK method, we have upgraded the library to accept the new payload, making it simpler to adopt FCM. 
+
+The Guardian Android SDK 0.4.0 version is available in Maven Central and includes this change. The sample application was also upgraded, so it can be tested by providing the google-services.json file and a guardian-url. 
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket)
+* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference)
+* [Auth0 Management API](/api/management/v2)
+* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html)
+* [Getting Started with Firebase Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html)
diff --git a/ja-jp/articles/mfa/concepts/mfa-api.md b/ja-jp/articles/mfa/concepts/mfa-api.md
new file mode 100644
index 0000000000..6154ac2805
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-api.md
@@ -0,0 +1,31 @@
+---
+title: Multi-factor Authentication API
+description: Overview of available multi-factor authentication APIs
+topics:
+  - mfa
+  - mfa-api
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication API
+
+Auth0 provides a built-in Multi-factor Authentication (MFA) enrollment and authentication flow using [Universal Login](/universal-login).
+
+You will need to use the MFA API in the following scenarios:
+
+- If you are [authenticating users with the Resource Owner Password Grant](/mfa/guides/mfa-api/authenticate).
+
+- If you want to build an interface to let users [manage their authentication factors](/mfa/guides/mfa-api/manage).
+
+<%= include('../_includes/_authenticator-before-start') %>
+
+## Limitations
+
+The MFA API is designed to work with SMS, Push via Guardian, Email, and OTP factors. It does not currently support enrolling with Duo or with the legacy 'google-authenticator' factor (Google Authenticator can still be enrolled using the OTP factor).
+
+## Keep reading
+
+* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate)
+* [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage)
diff --git a/ja-jp/articles/mfa/concepts/mfa-developer-resources.md b/ja-jp/articles/mfa/concepts/mfa-developer-resources.md
new file mode 100644
index 0000000000..735ce8aee0
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-developer-resources.md
@@ -0,0 +1,35 @@
+---
+description: Learn about developer resources such as the Auth0 MFA API and the Guardian SDKs for MFA.
+topics:
+  - mfa
+  - guardian
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Developer Resources for Multi-factor Authentication
+
+Using Auth0 SDKs, you can customize your users' multi-factor authentication (MFA) experience and even build applications on top of our multi-factor capabilities.
+
+## MFA API
+
+[MFA API](/mfa/concepts/mfa-api) endpoints allow you to enforce MFA when users interact with [the Token endpoints](/api/authentication#get-token), as well enroll and manage MFA factors.
+
+## Customize the multi-factor authentication page
+
+Use the following client libraries to customize the look-and-feel of the MFA page so it matches your organization.
+
+* [Client library for Auth0 MFA](https://github.com/auth0/auth0-guardian.js)
+* [Creating a Custom MFA Widget](https://github.com/auth0/auth0-guardian.js/tree/master/example)
+
+## Manage enrollments
+
+You can [customise the enrollment](/mfa/guides/guardian/create-enrollment-ticket) process for your users.
+
+## Build custom mobile applications
+
+Build custom _white-label_ Guardian-like applications, or add multi-factor functionality into your applications.
+
+* [Guardian for Android](/mfa/guides/guardian/guardian-android-sdk)
+* [Guardian for iOS](/mfa/guides/guardian/guardian-ios-sdk)
diff --git a/ja-jp/articles/mfa/concepts/mfa-factors.md b/ja-jp/articles/mfa/concepts/mfa-factors.md
new file mode 100644
index 0000000000..26141b8f56
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-factors.md
@@ -0,0 +1,77 @@
+---
+description: Understand how MFA works in Auth0, the authentication factors, policies and use cases.
+toc: true 
+topics:
+    - mfa
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication Factors
+
+Auth0 supports a number of different options when it comes to enabling MFA for protecting user account access. An MFA workflow is typically provided via a separate application that runs on a mobile or tablet device. 
+
+If you don’t want your customers to have to download a separate application, Auth0 also provides an [SDK](/mfa/guides/guardian/install-guardian-sdk) that you can use to build a second factor workflow in your existing mobile device app.
+
+On the [Dashboard > Multifactor Auth](${manage_url}/#/mfa) page, you can select the factors to use for MFA for your tenant. 
+
+![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png)
+
+Auth0 supports the following factors for implementing MFA. You must enable at least one to use MFA, but you can choose to enable and make available more than one factor if you wish. Available factors are dependent on your subscription plan.
+
+## Push notifications
+
+Send users push notifications to a their pre-registered devices - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the simple press of a button. Push factor is offered with the [Guardian](/mfa/concepts/guardian) mobile app, available for both [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk). 
+
+## SMS notifications
+
+[Send users a one-time code over SMS](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating.
+
+## Voice notifications
+
+[Deliver users a one-time code through a voice call](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating.
+
+## One-Time passwords
+
+[One-Time Password (OTP)](/mfa/guides/configure-otp) allows you to use an Authenticator application in your personal device - such as Google Authenticator - that will generate a one-time password which changes over time and which can be entered as the second factor to validate a user’s account.
+
+## Email notifications
+
+You can [use email](/mfa/guides/configure-email) when you want to provide users a way to perform MFA when they don't have their phone to receive an SMS or push notification.
+
+## Duo Security
+
+[Duo](/mfa/guides/configure-cisco-duo) is a multi-faceted provider and can only be used if it's the only factor available for the user. Use your Duo account to manage MFA with Auth0. 
+
+## Policies
+
+Policies determine when a user will be prompted to complete additional steps to prove they own a particular account. Use policies to define your own level of acceptable risk. You can choose between **Never** and **Always**. 
+
+You can achieve more refined multifactor configurations (such as per application, per user, etc.) by using [Rules](/rules/references/use-cases#multi-factor-authentication). 
+
+::: note
+Rules affecting MFA take precedence over the policy configuration in the Dashboard.
+:::
+
+## MFA use cases
+
+There are different ways to manage MFA depending on your environment: 
+
+* B2B: Your customers manage MFA factors for their users.
+* B2C: End users manage their own MFA factors via the My MFA Settings Page.
+* B2E: You manage MFA factors for your users.
+
+To learn about the API endpoints you can use to build a user interface that allows users to manage MFA factors, see [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage).
+
+Applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources. For details, see [Step-Up Authentication](/mfa/concepts/step-up-authentication). 
+
+You can configure a rule in **Dashboard > Rules** to define the conditions that will trigger additional authentication challenges. Use rules to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers.
+
+Add contextual MFA which allows you to define arbitrary conditions that will trigger additional authentication challenges to your customers for increased security, for example, geographic location (geo-fencing), address or type of network used (IP filtering), time of day, day of the week or change in the location or device being used to log in.
+
+## Keep reading
+
+* [Enable MFA](/mfa/guides/enable-mfa)
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Developer Resources for Multi-factor Authentication](/mfa/concepts/mfa-developer-resources)
diff --git a/ja-jp/articles/mfa/concepts/step-up-authentication.md b/ja-jp/articles/mfa/concepts/step-up-authentication.md
new file mode 100644
index 0000000000..ce09fe0084
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/step-up-authentication.md
@@ -0,0 +1,57 @@
+---
+description: Understand how step-up authentication works for APIs and web apps to verify that the user has logged in using MFA and if not, require the user to step-up to access certain resources. 
+topics:
+  - mfa
+  - step-up-authentication
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Step-up Authentication
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources.
+
+For example, Fabrikam's Intranet requires users to authenticate with their username and password to access customer data. However, a request for access to employee data (which may contain sensitive salary information) triggers a stronger authentication mechanism like multi-factor authentication (MFA).
+
+You can add step-up authentication to your app with Auth0's extensible multi-factor authentication support. Your app can verify that the user has logged in using multi-factor authentication (MFA) and, if not, require the user to step-up to access certain resources.
+
+![Step-up flow](/media/articles/mfa/step-up-flow.png)
+
+## Step-up Authentication for APIs
+
+When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens and [Rules](/rules/references/use-cases#multi-factor-authentication).
+
+::: note
+An Access Token is a credential you can use to access an API. The actions that you can perform to that API are defined by the scopes your Access Token includes. The rules are JavaScript functions you can use to run custom logic when a user authenticates.
+:::
+
+You can use a rule to trigger the step-up authentication mechanism (for example, prompt MFA) whenever the user requests scopes that map to sensitive resources.
+
+This is best explained with an example.
+
+A user signs into Fabrikam's web app. The standard login gives to this user the ability to interact with their API and fetch the users account list. This means that the Access Token that the application receives after the user authentication contains a scope like `read:accounts`.
+
+Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction. In order to perform this action, the API requires the scope `transfer:funds`.
+
+The Access Token that the user currently has does not include this scope and the application knows it since it knows the set of scopes it requested in the initial authentication call.
+
+The solution is that the application performs another authentication call, but this time it requests the required scope. The browser redirects to Auth0 and a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested.
+
+Once the user successfully authenticates with MFA, a new Access Token which includes the high-value scope is generated and sent. The application will pass the Access Token to the API which will discard it after verification, thereby treating it like a single-use token.
+
+For details and sample code, see [Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis).
+
+## Step-up Authentication for Web Apps
+
+If it is a web app that verifies the authentication level, and not an API, then you do not have an Access Token. In this case you can check if a user has logged in with MFA by reviewing the contents of their [ID Token](/tokens/concepts/id-tokens). You can then configure your application to deny access to pages with sensitive information if the ID Token indicates that the user did not log in with MFA, and use a rule to trigger the step-up authentication mechanism (for example, prompt MFA).
+
+For example, you might have an employee app that authenticates users with username and password, but if a user wants to access salary information, they have to provide a second factor, using for example a mobile push notification.
+
+You can implement this by checking the ID Token when the user tries to access that screen. If the claims show that the user has authenticated with MFA already then display the sensitive information. Otherwise, trigger authentication again, and using a rule, prompt the user to authenticate with MFA.
+
+For details and sample code, see [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-web-apps).
+
+## Keep reading
+
+* [Authentication policy definitions](http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#rfc.section.4)
diff --git a/ja-jp/articles/mfa/guides/a.json b/ja-jp/articles/mfa/guides/a.json
new file mode 100644
index 0000000000..c7a8387871
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/a.json
@@ -0,0 +1 @@
+{ "message_types": ["sms", "voice"] }
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-cisco-duo.md b/ja-jp/articles/mfa/guides/configure-cisco-duo.md
new file mode 100644
index 0000000000..a47cc6ee98
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-cisco-duo.md
@@ -0,0 +1,52 @@
+---
+description: Learn how to configure Cisco Duo for MFA.
+topics:
+  - mfa
+  - duo
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure Cisco Duo for MFA
+
+Cisco Duo is a multi-faceted authentication provider and can only be used on your Auth0 tenant if all other factors are disabled. 
+
+## Administrative setup
+
+Your Duo account can be configured to support push notifications, SMS, OTP, phone callback, and more. See the [Duo documentation](https://duo.com/docs) for more details on Duo setup. 
+
+::: note
+Create an integration in Duo Security of type **Web SDK** and use those credentials to fill in the Duo settings in the Auth0 Dashboard as noted below.
+:::
+
+When enabling Duo in the Dashboard, you will need to click on the Duo factor and fill in a few settings fields in order to link your Duo account to Auth0.
+
+![MFA Duo Settings](/media/articles/mfa/duo-settings.png)
+
+::: warning
+If other factors are enabled alongside Duo, Duo will be unavailable. Duo is only available to end users when it is the **sole** factor enabled.
+:::
+
+## MFA sessions
+
+Duo does not provide an option for "Remember Me" behavior, so a 30-day MFA session is hard-coded to remember a logged-in user and not prompt them every time they log in. If you wish to force end-users to log in with Duo every time, you may implement this functionality by creating a rule with `allowRememberBrowser: false` instead.
+
+```js
+function (user, context, callback) {
+  context.multifactor = {
+    provider: 'any',
+    allowRememberBrowser: false
+  };
+
+  callback(null, user, context);
+}
+```
+
+## End user experience
+
+The user will see a prompt for the second factor with Duo, listing the options you have enabled in your Duo account.
+
+![Duo Login](/media/articles/mfa/duo-login.png)
+
+Your end users can download Duo from [Google Play](https://play.google.com/store/apps/details?id=com.duosecurity.duomobile) or from the [App Store](https://itunes.apple.com/us/app/duo-mobile/id422663827?mt=8) for use as a second factor.
diff --git a/ja-jp/articles/mfa/guides/configure-email.md b/ja-jp/articles/mfa/guides/configure-email.md
new file mode 100644
index 0000000000..0b8c75500f
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-email.md
@@ -0,0 +1,43 @@
+---
+description: Learn how to configure email as an MFA factor for users who don't have their primary factor available. 
+topics:
+  - mfa
+  - email
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure Email Notifications for MFA
+
+Using email as an MFA factor is useful when you want to provide users a way to perform MFA when they don't have their primary factor available (e.g. they don't have their phone to receive an SMS or push notification). 
+
+You can only enable email as an MFA factor if there is already another factor enabled. Email will only be functional as a factor from Universal Login when you have the [New Universal Login Experience](/universal-login/new) enabled.
+
+Once Email MFA is enabled user will be prompted to complete MFA with the other enabled factor. If they have a **verified email** they will be given the option to select Email, and get an one time code in their email which they can then enter to complete MFA.
+
+Users do not need to explicitly enroll with email MFA. They will get be able to use it when they have a verified email. This happens when they completed the email verification flow, when the updated the email_verified field using the Management API, or when they logged-in with a connection that provides verified emails (e.g. Google).
+
+Note that Email is not true multi-factor authentication (MFA) as it does not represent a different factor than the password. It does not represent 'something I have' or 'something I am', but rather just another 'something I know' (the email password). It is also weaker than other factors, in that it's only as secure as the email itself (e.g. is it encrypted end-to-end?).
+
+## End-user experience
+
+After the login step, users will be prompted with the most secure enabled factor. If they select 'Try another method', and then pick Email, they will be sent an email with a six-digit code that they will need to enter to complete the authentication flow.
+
+![Email End User 1](/media/articles/mfa/mfa-email.png)
+
+## Using the MFA API
+
+You can explicitly enroll an email for MFA [using the MFA API](/mfa/guides/mfa-api/email). If users have a verified email and one or more explicitly enrolled emails, they'll be able to select which email they want to use to complete MFA when logging-in using Universal Login.
+
+## Administrative setup
+
+In order to set up Email, you need to enable the Email factor in the Dashboard. You will only be able to enable it if there is another factor enabled. 
+
+![MFA Email Settings](/media/articles/mfa/email-settings.png)
+
+[Auth0 provides a test email provider](/email) but it only allows a limited amount of emails, so you should [configure your own email provider](/email/providers).
+
+## Keep reading
+
+* [Enroll and Challenge Email Authenticators using the MFA API](/mfa/guides/mfa-api/email)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-otp.md b/ja-jp/articles/mfa/guides/configure-otp.md
new file mode 100644
index 0000000000..2ac05eb434
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-otp.md
@@ -0,0 +1,36 @@
+---
+description: Learn how to configure time-based one time passwords for MFA.
+topics:
+  - mfa
+  - duo
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure One Time Passwords for MFA
+
+To use one time passwords as an authentication factor, users need an Authenticator app such as:
+
+* Authy ([Google Play](https://play.google.com/store/apps/details?id=com.authy.authy) / [App Store](https://itunes.apple.com/us/app/authy/id494168017)).
+* Google Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) / [App Store](https://itunes.apple.com/us/app/google-authenticator/id388497605)).
+* Auth0 Guardian ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) / [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833)).
+* Microsoft Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.azure.authenticator) / [App Store](https://itunes.apple.com/us/app/microsoft-authenticator/id983156458)).
+
+![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png)
+
+Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. 
+
+Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code:
+
+
    Google Authenticator OTP
    
+
+And enter the code at the prompt:
+
+![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png)
+
+Your users will need to have an OTP Authenticator app installed in their mobile devices.
+
+## Keep reading
+
+* [Enroll and Challenge OTP Authenticators using the MFA API](/mfa/guides/mfa-api/otp)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-phone.md b/ja-jp/articles/mfa/guides/configure-phone.md
new file mode 100644
index 0000000000..9b37a8fdd1
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-phone.md
@@ -0,0 +1,128 @@
+---
+title: Configure SMS and Voice Notifications for MFA
+description: Learn how to configure SMS and Voice notifications for MFA.
+topics:
+  - mfa
+  - twilio
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure SMS and Voice Notifications for MFA
+
+If you use SMS or Voice as an authentication factor, when an end user attempts to authenticate with your application, they are sent a code via SMS or Voice, which they will have to enter to complete the transaction. This implies that they both know their login credentials and are in possession of the phone number that they have registered for Multi-factor Authentication (MFA) use.
+
+You can configure this factor to send messages through SMS, Voice, or to let the end users choose how they want the code to be delivered.
+
+::: warning
+- Using Voice as an MFA factor is currently a Beta feature. It should not be used in production environments.
+- Voice as an MFA factor is not available when using the [Classic Universal Login Experience](/universal-login/classic).
+::: 
+
+## End user experience - Voice and SMS
+
+When Voice and SMS are enabled, users are given the option to enroll by getting the code sent by SMS or Voice:
+
+![Voice and SMS - End User](/media/articles/mfa/mfa-sms-voice.png)
+
+When only SMS is enabled, the flow is simpler:
+
+![SMS - End User](/media/articles/mfa/mfa-sms.png)
+
+After users are enrolled, the next time they authenticate they will get the Voice or SMS message in their registered phone. 
+
+## Administrative setup
+
+![MFA Phone Message Settings](/media/articles/mfa/mfa-phone-settings.png)
+
+### Message Delivery Provider and Method
+
+To allow users to authenticate with SMS or Voice, you must enable the Phone factor and select your preferred delivery method:
+
+* **Auth0**: Sends the messages using Auth0's internally-configured SMS delivery provider. It can be used for evaluation and testing purposes, and there is a maximum of 100 messages per tenant during the entire tenant lifetime. New codes are not received after reaching the 100 message limit. You can't use this provider to send Voice messages.
+
+* **Twilio**: Sends the messages using the [Twilio Programmable SMS API](https://www.twilio.com/sms) for SMS or [Twilio Programmable Voice API](https://www.twilio.com/voice) for Voice. You will need to provide [your own Twilio credentials](#twilio-configuration). Make sure you use Twilio  **Live Credentials**, not the **Test Credentials**. The test credentials are not meant to be used to send messages in a production environment.
+
+* **Custom**: Sends the messages by invoking the [Send Phone Message Hook](/hooks/extensibility-points/send-phone-message).
+
+You can also choose if you want to give users the option of getting text messages, voice calls, or both.
+
+### Twilio configuration
+
+If you choose to deliver SMS via Twilio, follow these steps to configure your SMS factor.
+
+![MFA Phone Settings](/media/articles/mfa/mfa-phone-twilio.png)
+
+1. Open an account with Twilio. You will need a [Twilio Account SID](https://www.twilio.com/help/faq/twilio-basics/what-is-an-application-sid) and a [Twilio Auth Token](https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it). These are the Twilio API credentials that Auth0 will use to send messages to your users.
+
+  You may also need to enable permissions for your geographic region for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://www.twilio.com/console/voice/calls/geo-permissions). If you use Voice, your account needs to have a Twilio phone number enabled to make Voice calls. This can be an external phone number [verified with Twilio](https://support.twilio.com/hc/en-us/articles/223180048-Adding-a-Verified-Phone-Number-or-Caller-ID-with-Twilio) or you can purchase and set up a Twilio Phone Number from within your account.
+
+2. Configure the connection. Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields.
+
+3. Choose your **SMS Source**.
+
+  * If you choose **Use From**, you will need to enter the **From** phone number that users will see as the sender. You may also configure this in Twilio. 
+
+  * If you choose **Use Messaging Services**, you will need to enter a [Messaging Service SID](https://www.twilio.com/docs/sms/services/services-send-messages).
+
+  If you are using Voice, you always need to configure 'From' even if you are using 'Messaging Services' for SMS. Make sure the phone number is configured to send both SMS and Voice messages.
+
+5. Click **Save**.
+
+### Custom Phone Messaging providers
+
+Phone Messaging providers not currently integrated with Auth0 can be implemented by using the [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook. To learn how to do this in your MFA flow, check the examples for different providers below:
+
+* [Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Twilio](/mfa/send-phone-message-hook-twilio)
+* [Infobip](/mfa/send-phone-message-hook-infobip)
+* [TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Vonage](/mfa/send-phone-message-hook-vonage)
+* [Esendex](/mfa/send-phone-message-hook-esendex)
+* [Mitto](/mfa/send-phone-message-hook-mitto)
+
+## Custom SMS or Voice Notification Templates
+
+Optionally, you can [customize your SMS or Voice notification templates](/mfa/guides/customize-phone-messages).
+
+## Using the Management API to configure Voice or SMS
+
+You can use the Management API to configure which Message Delivery Methods are enabled by using the `/api/v2/guardian/factors/phone/message-types` endpoint. 
+
+The `messages_types` parameter is an array that can have `["sms"]`, `["voice"]`, or `["sms", "voice"]`. You need a [Management API Token](/api/management/v2/tokens) with the `update:guardian_factors` scope as a Bearer Token to call the API:
+
+ ```har
+  {
+      "method": "PUT",
+      "url": "https://${account.namespace}/api/v2/guardian/factors/phone/message-types",
+      "headers": [
+        { "name": "Content-Type", "value": "application/json" },
+   	    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+      ],
+      "postData": {
+          "mimeType": "application/json",
+          "text": "{ \"message_types\": [\"sms\", \"voice\"] }"
+      }
+  }
+```
+
+## Security Considerations
+
+When using any phone messaging provider, you need to be aware that attackers abusing the signup flow could cause you financial damage.
+
+Auth0 will limit a single user to sending up to 10 SMS or voice messages per hour. To further protect your account, you can consider:
+
+- Enabling [Brute Force Protection](/anomaly-detection/references/brute-force-protection-triggers-actions#100-failed-login-attempts-or-50-sign-up-attempts). Auth0 will block an IP if it attempts to do more than 50 signup requests per minute.
+
+- Enable [Log Streaming](/logs/streams) and create alerts using your favorite monitoring tool, when you see spikes in the number of `gd_send_voice` or `gd_send_voice_failure` [log events](/logs/references/log-event-type-codes).
+
+Phone Messaging providers have additional protections. If you are using Twilio, make sure you read the [Anti-Fraud Developer Guide](https://www.twilio.com/docs/usage/anti-fraud-developer-guide). We recommend that you consider the following options:
+
+- Limit the countries that you will send messages for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://support.twilio.com/hc/en-us/articles/223180228-International-Voice-Dialing-Geographic-Permissions-Geo-Permissions-and-How-They-Work). This is particularly useful if there are countries with a higher risk of [toll fraud](https://www.twilio.com/learn/voice-and-video/toll-fraud) or more expensive calling rates in which you do not typically do business.
+
+- Enable Twilio [usage triggers](https://support.twilio.com/hc/en-us/articles/223132387-Protect-your-Twilio-project-from-Fraud-with-Usage-Triggers) to protect your account against fraud and coding mistakes.
+
+## Keep Reading
+
+* [Enroll and Challenge SMS and Voice Authenticators using the MFA API](/mfa/guides/mfa-api/phone)
diff --git a/ja-jp/articles/mfa/guides/configure-push.md b/ja-jp/articles/mfa/guides/configure-push.md
new file mode 100644
index 0000000000..4bed2fc849
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-push.md
@@ -0,0 +1,42 @@
+---
+description: Learn how to configure push notification using Guardian SDKs for multi-factor authentication.
+topics:
+  - mfa
+  - guardian-sdk
+  - push
+contentType:
+  - how-to
+useCase:
+  - configure-push-notifications
+---
+# Configure Push Notifications for MFA
+
+Use a custom app built using the Guardian SDKs for [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk) that relies on vendor-specific push notification services. 
+
+1. [Create an SNS Platform Application](https://console.aws.amazon.com/sns/v3/home?region=us-east-1#/mobile/push-notifications/platform-applications) using AWS Management console and note it’s ARN.
+
+2. Create an AWS Access Key authorized to create Platform application endpoints. Guardian automatically creates a platform application endpoint with appropriate device token as part of a successful enrollment. 
+
+3. To receive push notifications from Guardian, it's necessary to override Guardian's default SNS settings.
+
+    Go to the [Multi-factor Authentication](${manage_url}/#/guardian) section of the Dashboard.
+
+4. Toggle **Custom App** option in the **Push via Auth0 Guardian** section and set your AWS Access Key and ARN from the AWS Management Console. 
+
+    Name | Description
+    -----|------------
+    AWS Access Key Id | Your AWS Access Key ID.
+    AWS Secret Access Key | Your AWS Secret Access Key.
+    AWS Region | Your AWS application's region.
+    APNS ARN | The Amazon Resource Name for your [Apple Push Notification Service](http://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html).
+    GCM ARN | The Amazon Resource Name for your [Firebase Cloud Messaging Service](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html).
+
+5. Click **SAVE**. 
+
+## Keep reading
+
+* [Guardian iOS SDK](/mfa/guides/guardian/guardian-ios-sdk)
+* [Guardian Android SDK](/mfa/guides/guardian/guardian-android-sdk)
+* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket)
+* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference)
+* [Enroll and Challenge Push Authenticators using the MFA API](/mfa/guides/mfa-api/push)
diff --git a/ja-jp/articles/mfa/guides/configure-step-up-apis.md b/ja-jp/articles/mfa/guides/configure-step-up-apis.md
new file mode 100644
index 0000000000..8b5357dc01
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-step-up-apis.md
@@ -0,0 +1,217 @@
+---
+title: Configure Step-up Authentication for APIs
+description: Learn how an API can check if a user has logged in with Multi-factor Authentication by examining their Access Token.
+topics:
+  - mfa
+  - step-up-authentication
+  - apis
+contentType:
+  - how-to
+  - concept
+useCase:
+  - customize-mfa
+---
+# Configure Step-up Authentication for APIs
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions.
+
+For instance, a user of a bankin app may be allowed to transfer money between accounts only after they have confirmed their identity using multi-factor authentication (MFA).
+
+When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens, and [Rules](/rules/references/use-cases#multi-factor-authentication). 
+
+## How it works
+
+When an application wants to access an API's protected resources, it must provide an Access Token. The resources that it will have access to depend on the permissions that are included in the Access Token. These permissions are defined as **scopes**. 
+
+For example, a banking API may accept two different levels of authorization: view account balance (scope `view:balance`) or transfer funds (scope `transfer:funds`). When an application asks the API to retrieve the user's balance, then the Access Token should contain the `view:balance` scope. To transfer money to another account, the Access Token should contain the `transfer:funds` scope.
+
+The flow for this example:
+
+1. The user logs in to the application using username/password authentication. The standard login gives this user the ability to interact with the API and fetch their balance. This means that the Access Token that the app receives after the user authenticates contains the `view:balance` scope.
+2. The application sends a request to the API to retrieve the balance, using the Access Token as credentials.
+3. The API validates the token and sends the balance info to the application, so the user can view it.
+4. Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction that requires the `transfer:funds` scope. The application sends a request to the API using the same Access Token.
+5. The API validates the token and denies access because the token is missing the required `transfer:funds` scope.
+6. The application redirects to Auth0, where a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested. Once the user successfully authenticates with MFA, a new Access Token that includes the correct scope is generated and sent to the application as part of the response.
+7. The application sends another transfer funds request using the new Access Token, which includes the `transfer:funds` scope this time.
+8. The API validates the token, discards it (thereby treating it like a single-use token), and proceeds with the operation.
+
+## Validate Access Tokens
+
+Besides checking the scope, the API must perform additional validation on the Access Token. It must also:
+
+* verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way. 
+
+* validate the standard claims: 
+
+    | Claim | Description |
+    | --- | --- |
+    | `exp` | Token expiration |
+    | `iss` | Token issuer |
+    | `aud` | Intended recipient of the token |
+
+For more information, see [Validate an Access Token: Custom API Access Tokens](/tokens/guides/validate-access-tokens#custom-api-access-tokens).
+
+## Sample scenario
+
+In the following scenario, we will learn how to implement the flow described above.
+
+For this example, we assume that we have already done the following:
+
+- [Registered an application](/applications). For this example, we'll use a single-page web app.
+- [Created a database connection](${manage_url}/#/connections/database).
+- [Registered the API](/apis#how-to-configure-an-api-in-auth0). During this process, we should create two scopes: `view:balance` and `transfer:funds`.
+- [Enabled Multi-factor Authentication](/mfa). For this example, we'll use push notifications.
+
+1. Create a rule that challenges the user to authenticate with MFA when the `transfer:funds` scope is requested. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content:
+
+    ```js
+    function(user, context, callback) {
+
+      var CLIENTS_WITH_MFA = ['${account.clientId}'];
+      // run only for the specified clients
+      if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+        // ask for MFA only if scope transfer:funds was requested
+        if (context.request.query.scope.indexOf('transfer:funds') > -1) {
+          context.multifactor = {
+            provider: 'any',
+            allowRememberBrowser: false
+          };
+        }
+      }
+
+      callback(null, user, context);
+    }
+    ```
+
+    - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.)
+
+    - The `context.request.query.scope` property contains all the scopes for which the authentication request asked. If it includes the value `transfer:funds`, then we ask for MFA by setting the `context.multifactor` property to the appropriate value. In this case, we are asking for MFA using [Push](/mfa/concepts/mfa-factors#push-notifications).
+
+2. Configure the app to send the appropriate authentication request to the API, depending on whether the user is attempting to perform the high-value transaction of transferring funds. Notice that the only difference between the two authentication requests (with or without MFA) is the scope.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+      
    
+    
    
+    
    
+      
    +        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance%20transfer:funds&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+      
    
+    
    
+  
    
+
    
+
+| Parameter | Setting |
+| --- | --- |
+| `audience` | Set to the **Identifier** of your API (find it at [API Settings](${manage_url}/#/apis/)). We set ours to `https://my-banking-api`. |
+| `response_type` | Set to `id_token token` so we get both an ID Token and an Access Token in the response. |
+| `client_id` | Set to the Client ID of your application (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). |
+| `redirect_uri` | Set to a URL in your application that Auth0 should redirect back to after authentication (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). |
+| `nonce` | Set to a secure string value which will be included in the response from Auth0. This is [used to prevent token replay attacks](/api-auth/tutorials/nonce) and is required for `response_type=id_token token`. |
+| `state` | Set to an opaque value that Auth0 includes when redirecting back to the application. This value must be used by the application to [prevent CSRF attacks](/protocols/oauth2/oauth-state). |
+
+3. Configure the API to validate the incoming token according to the steps described in the [Validate Access Tokens](#validate-access-tokens) section and check the authorized permissions. 
+
+    In this scenario, we will configure two endpoints for our API:
+
+    - `GET /balance`: to retrieve the current balance
+    - `POST /transfer`: to transfer funds
+
+    We will use `Node.js` and a number of modules:
+
+    - [express](https://expressjs.com/): adds the Express web application framework.
+    - [jwks-rsa](https://github.com/auth0/node-jwks-rsa): retrieves RSA signing keys from a **JWKS** (JSON Web Key Set) endpoint. Using `expressJwtSecret`, we can generate a secret provider that will issue the right signing key to `express-jwt` based on the `kid` in the JWT header.
+    - [express-jwt](https://github.com/auth0/express-jwt): lets you authenticate HTTP requests using JWT tokens in your Node.js applications. It provides several functions that make working with JWTs easier.
+    - [express-jwt-authz](https://github.com/auth0/express-jwt-authz): checks if the Access Token contains a specific scope.
+
+    Start with installing the dependencies:
+
+    `npm install express express-jwt jwks-rsa express-jwt-authz --save`
+
+    Next, define the API endpoints, create a middleware function to validate the Access Token, and secure the endpoints using that middleware. The code in your `server.js` file should look like the following sample script:
+
+    ```js
+    // set dependencies
+    const express = require('express');
+    const app = express();
+    const jwt = require('express-jwt');
+    const jwksRsa = require('jwks-rsa');
+    const jwtAuthz = require('express-jwt-authz');
+
+    // Create middleware for checking the JWT
+    const checkJwt = jwt({
+      // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint
+      secret: jwksRsa.expressJwtSecret({
+        cache: true,
+        rateLimit: true,
+        jwksRequestsPerMinute: 5,
+        jwksUri: `https://${account.namespace}/.well-known/jwks.json`
+      }),
+
+      // Validate the audience and the issuer
+      audience: 'https://my-banking-api', // replace with your API's audience, available at Dashboard > APIs
+      issuer: 'https://${account.namespace}/',
+      algorithms: [ 'RS256' ] // we are using RS256 to sign our tokens
+    });
+
+    // create retrieve balance endpoint
+    app.get('/balance', checkJwt, jwtAuthz(['view:balance']), function (req, res) {
+      // code that retrieves the user's balance and sends it back to the calling app
+      res.status(201).send({message: "This is the GET /balance endpoint"});
+    });
+
+
+    // create transfer funds endpoint
+    app.post('/transfer', checkJwt, jwtAuthz(['transfer:funds']), function (req, res) {
+      // code that transfers funds from one account to another
+      res.status(201).send({message: "This is the POST /transfer endpoint"});
+    });
+
+    // launch the API Server at localhost:8080
+    app.listen(8080);
+    console.log('Listening on http://localhost:8080');
+    ```
+
+    Each time the API receives a request the following happens:
+
+    1. The endpoint calls the `checkJwt` middleware.
+    2. `express-jwt` decodes the token and passes the request, the header, and the payload to `jwksRsa.expressJwtSecret`.
+    3. `jwks-rsa` downloads all signing keys from the JWKS endpoint and checks if one of the signing keys matches the `kid` in the header of the Access Token. If none of the signing keys match the incoming `kid`, an error is thrown. If there is a match, we pass the right signing key to `express-jwt`.
+    4. `express-jwt` continues its own logic to validate the signature of the token, the expiration, audience, and the issuer.
+    5. `jwtAuthz` checks if the scope that the endpoint requires is part of the Access Token.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Rules Uses Cases](/rules/references/use-cases#multi-factor-authentication)
+* [Scopes](/scopes)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-for-web-apps)
diff --git a/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md b/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md
new file mode 100644
index 0000000000..af00fbc2ed
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md
@@ -0,0 +1,167 @@
+---
+title: Configure Step-up Authentication for Web Apps
+description: Learn how to check if a user has logged in your web app with Multi-factor Authentication by examining their ID Token.
+topics:
+  - mfa
+  - step-up-authentication
+  - web-apps
+contentType:
+  - how-to
+  - concept
+useCase:
+  - customize-mfa
+---
+# Configure Step-up Authentication for Web Apps
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions.
+
+For instance, a user may be allowed to access views with sensitive data or reset their password only after confirming their identity using multi-factor authentication (MFA).
+
+To accomplish step-up authentication for your web app, you will create a rule that challenges the user to authenticate with MFA when the web app asks for it, check the ID Token claims for MFA if the user tries to access a restricted page, and then challenge the user if MFA is not included in the claim. 
+
+## How it works
+
+When a user logs in, you retrieve an [ID Token](/tokens/concepts/id-tokens), which is a JSON Web Token (JWT) that contains information relevant to the user's session in the form of claims. For this scenario, the relevant claim is `amr`, which indicates the authentication method used during login; it **must** be present in the ID Token's payload and **must** contain the value `mfa`. Because it can contain claims other than `mfa`, when validating you must both test for its existence and examine its contents for a value of `mfa`.
+
+::: panel Authentication Methods Reference
+The `amr` claim is a JSON array of strings that indicates the authentication method used during login. Its values may include any of the pre-defined [Authentication Method Reference Values](https://tools.ietf.org/html/rfc8176). For example, the `amr` claim may contains the pre-defined value `mfa`, which indicates that the user has authenticated using MFA. 
+:::
+
+If a user attempts to access a restricted page and the token shows that the user has **not** authenticated with MFA, then you can retrigger authentication, which you have configured to trigger MFA using a rule. Once the user provides the second factor, a new ID Token that contains the `amr` claim is generated and sent to the app.
+
+## Validate ID Tokens for MFA
+
+1. Retrieve the ID Token.
+2. Verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way.
+3. Validate the following claims: 
+
+    | Claim | Description |
+    | --- | --- |
+    | `exp` | Token expiration |
+    | `iss` | Token issuer |
+    | `aud` | Intended recipient of the token |
+    | `amr` | If `amr` does not exist in the payload or does not contain the value `mfa`, the user did not log in with MFA. If `amr` exists in the payload and contains the value `mfa`, then the user did log in with MFA. |
+
+    In the example below, you can compare the potential values included in an ID Token's payload when a user has authenticated with MFA versus when they have not.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054,
+    "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor",
+    "amr": [
+        "mfa"
+    ]
+}
+        
+      
    
+    
    
+    
    
+      
    +        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054
+}
+        
+      
    
+    
    
+  
    
+
    
+
+## Sample scenario
+
+In the following scenario, a web app authenticates users with username and password. When users want to access a specific screen with sensitive information, such as salary data, they must authenticate with another factor, such as Guardian push notifications.
+
+For this example, we assume that we have already done the following:
+
+- [Registered an application](/applications). For this example, we'll use a regular web app.
+- [Created a database connection](${manage_url}/#/connections/database).
+- [Enabled Multi-factor Authentication](/mfa/guides/enable-mfa) using push notifications.
+
+1. Create a rule that challenges the user to authenticate with MFA when the web app requests it. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content:
+
+    ```js
+    function(user, context, callback) {
+
+      var CLIENTS_WITH_MFA = ['${account.clientId}'];
+      // run only for the specified clients
+      if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+        // ask for MFA only if the web app said so in the authentication request
+        if (context.request.query.acr_values === 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'){
+          context.multifactor = {
+            provider: 'any',
+            allowRememberBrowser: false
+          };
+        }
+      }
+
+      callback(null, user, context);
+    }
+    ```
+
+    - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.)
+
+    - The `context.request.query.acr_values` property contains the context class that the Authorization Server is being requested to use when processing requests from the application. It only exists when the application includes it in the authentication request. In this example, our web app will include it in the authentication request, but only when a user who has not already authenticated ith MFA tries to access salary information. When our web app includes it, it will set a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which indicates that we want the Authorization Server to require MFA, and the `context.multifactor` property value that we set in our code will specify MFA via [Push notification](/mfa/concepts/mfa-factors#push-notifications).
+
+2. Configure the app to check that the user has authenticated using MFA when a user tries to acces the restricted salary information page. (When a user has authenticated with MFA, the ID Token claims contain the `amr` claim with a value of `mfa`). If the user has already authenticated with MFA, then the web app will display the restricted page; otherwise, the web app will send a new authentication request that includes the `acr_values` parameter with a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which will trigger our rule. 
+
+    The web app in this scenario uses the [Authorization Code Flow](/flows/concepts/auth-code) to authenticate, so the request is as follows:
+
+    ```text
+    https://${account.namespace}/authorize?
+        audience=https://${account.namespace}/userinfo&
+        scope=openid&
+        response_type=code&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        state=YOUR_OPAQUE_VALUE&
+        acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor
+    ```
+
+    Once the user authenticates with MFA, the web app receives the authorization code, which must be exchanged for the new ID Token, which should now contain the `amr` claim with a value of `mfa`. To learn how to exchange the code for an ID Token, see [Add Login Using the Authorization Code Flow: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens). 
+
+3. Validate the incoming ID Token using the steps described in the [Validate ID Tokens for MFA](#validate-id-tokens-for-mfa) section. In this scenario, we perform these validations using the [JSON Web Token Sample Code](https://github.com/auth0/node-jsonwebtoken), which verifies the token's signature (`jwt.verify`), decodes the token, checks whether the payload contains `amr`, and if so, logs the results in the console.
+
+    ```js
+    const AUTH0_CLIENT_SECRET = '${account.clientSecret}';
+    const jwt = require('jsonwebtoken')
+
+    jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] }, function(err, decoded) {
+      if (err) {
+        console.log('invalid token');
+        return;
+      }
+
+      if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) {
+        console.log('You used mfa');
+        return;
+      }
+
+      console.log('you are not using mfa');
+    });
+    ```
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Rules Use Cases](/rules/references/use-cases#multi-factor-authentication)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [OpenID Connect (OIDC) specification](http://openid.net/specs/openid-connect-core-1_0.html)
+* [Configure Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis)
diff --git a/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md b/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md
new file mode 100644
index 0000000000..876b69c42d
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md
@@ -0,0 +1,174 @@
+---
+description: Learn how to customize MFA pages with Universal Login branding options.
+topics:
+  - mfa
+  - custom-mfa
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Customize Multi-Factor Authentication
+
+::: note
+These customizations do not apply to Duo, which has its own UI.
+:::
+
+The multi-factor authentication pages that appear to your users can be customized by adjusting the Universal Login branding options in the [Universal Login Settings](${manage_url}/#/login_settings) section.
+
+If you need further customization, you can also customize [the full HTML content](/universal-login/multifactor-authentication#customize-the-html-for-the-mfa-page) to reflect your organization's particular UX requirements. 
+
+With the New Universal Login Experience, MFA is presented even more simply to the user. Once they have entered their credentials to log in, they are presented with the MFA screen. If they have no MFA factor enrolled, they will be asked to enroll, and if they do, they will be asked to present their MFA credential.
+
+![MFA with New UL](/media/articles/universal-login/new-ul-mfa1.png)
+
+Note that in addition to complying with the requested factor, a user can also click the link at the bottom and be taken to a screen which presents all available MFA factors for this application, and select another to enroll or use.
+
+![MFA with New UL - Select a Factor](/media/articles/universal-login/new-ul-mfa2.png)
+
+## Customize via Rules
+
+If you need to customize the multi-factor experience you are offering to your users, you may do so via custom rules configurations for multi-factor authentication. This might be needed, for example, if you wish to trigger MFA for only specific applications, or for specific users based on user metadata or on IP addresses.
+
+## MFA API
+
+Additionally, the [MFA API](/mfa/concepts/mfa-api) is available for other customized MFA requirements.
+
+You can configure a [rule](/rules/references/use-cases#multi-factor-authentication) in  [Dashboard > Rules](${manage_url}/#/rules) for custom multi-factor authentication (MFA) processes, which allow you to define the conditions that will trigger additional authentication challenges. Rules can be used to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers.
+
+::: note
+The MFA settings defined in rules will always take precedence over the toggles in the Multi-factor Auth section of the Dashboard.
+:::
+
+## `provider` setting
+
+The `provider` setting is a way to specify whether to force MFA, and which factor to you use. The behavior is different depending if you use the Classic or the New Universal Login experience:
+
+| Provider             | Classic Experience      | New Experience          |
+|----------------------|:-----------------------:|------------------------:|
+| any                  |  Push, SMS or OTP using | Push, SMS, Voice, OTP or Email |
+| guardian             |  Push, SMS or OTP using | Push, SMS, OTP or Email |
+| google-authenticator |  Google Authenticator   | Push, SMS, OTP or Email |
+| duo                  |  Duo                    | Duo                     |
+
+If you are using the New Experience you can get the behavior of the Classic experience if you enable customization of the MFA login page.
+
+The `guardian` and `google-authenticator` options are legacy settings that are kept for backwards compatibility reasons, and should not be used moving forward. We recommend using `any`.  The 'google-authenticator' option does not let users enroll a recovery code.
+
+Setting the `provider` to a specific option manually will override the enabled/disabled toggles in the Dashboard. The following rule will prompt the user to enroll for Duo even if other factor are enabled in the Dashboard:
+
+```js
+function (user, context, callback) {
+
+  // Forcing the provider to Duo programmatically
+  context.multifactor = {
+    provider: 'duo'
+  };
+
+  callback(null, user, context);
+}
+```
+
+## Implement contextual MFA
+
+The exact requirements for configuring Contextual MFA will vary. Below are sample snippets you might consider using as you customize your specific solution.
+
+### Customize MFA for select users
+
+You may customize MFA to run only for users who are authenticating against specific applications in your tenant, or only for users who are marked to use MFA. To enable this behavior you need to have the "Always require Multi-factor Authentication" toggle turned off, and enable MFA using a rule for specific users or applications.
+
+```js
+function (user, context, callback) {
+
+  //var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID'];
+  // run only for the specified applications
+  // if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+    // uncomment the following if clause in case you want to request a second factor only from user's that have user_metadata.use_mfa === true
+    // if (user.user_metadata && user.user_metadata.use_mfa){
+      context.multifactor = {
+        provider: 'any',
+        allowRememberBrowser: false
+      };
+    // }
+  //}
+
+  callback(null, user, context);
+}
+```
+
+If you choose to selectively apply MFA, you will need the appropriate `clientID` values, and the code will be executed as part of a [Rule](/rules) whenever a user logs in.
+
+More specifically, you will uncomment and populate the following line of the rule template above with the appropriate client IDs:
+
+`var CLIENTS_WITH_MFA = ['REPLACE_WITH_CLIENT_ID'];`
+
+By setting `allowRememberBrowser: false`, the user will always be prompted for MFA when they login. This prevents the browser cookie from saving the credentials and helps make logins more secure, especially from untrusted machines. 
+
+### Change authentication request frequency
+
+In some scenarios you may want to avoid prompting the user for MFA each time they log in from the same browser. The default behavior is:
+
+- The user will be prompted for MFA every 30 days when `provider` is set to `google-authenticator` or `duo`
+- The user will be able to decide if they want to skip MFA for the next 30 days when `provider` is set to other values.
+
+You can alter that behavior by using the `allowRememberBrowser` property:
+
+```JS
+function (user, context, callback) {
+
+  if (conditionIsMet()){
+    context.multifactor = {
+      allowRememberBrowser: false,
+      provider: 'any'
+    };
+  }
+
+  callback(null, user, context);
+}
+```
+
+Depending on the property value the behavior will be as follows:
+
+- `true`: when `provider` is set to `google-authenticator` or `duo`, the user will be prompted for MFA once every 30 days. For other provider values, the user will be able to decide if they want to skip MFA for the next 30 days.
+- `false`: the user will be prompted for MFA each time they authenticate.
+
+::: note
+These time values are for active users. If a user is inactive for a period of seven days or more, their cookie will expire anyway, and they will be prompted for MFA on their next login attempt, even if `allowRememberBrowser` is `true` and it has not been thirty days since their last MFA prompt.
+:::
+
+In order to let the user skip MFA, a cookie will be stored in the user's browser. If the user has the cookie set but you still want the user to perform MFA, you have these options:
+
+- Set `allowRememberBrowser` to `false`
+- Set `acr_values` to `http://schemas.openid.net/pape/policies/2007/06/multi-factor` when calling the `/authorize` endpoint.
+
+If you want to require a specific user to be prompted for MFA during their next log in, you can call the [Invalidate Remember Browser API endpoint](https://auth0.com/docs/api/management/v2#!/Users/post_invalidate_remember_browser). This is useful for situations where the user loses a trusted device.
+
+### Customize MFA for users outside the network
+
+Assuming that access to the specified network of internal IP addresses is well controlled, you can also have Auth0 request MFA from only users whose requests originate from outside the corporate network:
+
+```js
+function (user, context, callback) {
+  var ipaddr = require('ipaddr.js');
+  var corp_network = "192.168.1.134/26";
+
+  var current_ip = ipaddr.parse(context.request.ip);
+  if (!current_ip.match(ipaddr.parseCIDR(corp_network))) {
+    context.multifactor = {
+        provider: 'any',
+        allowRememberBrowser: false
+    };
+  }
+
+  callback(null, user, context);
+}
+```
+
+## Customize MFA with social connections
+
+If you are using MFA after an authentication with one or more social providers, you need to use your own application `ID` and `Secret` in the connection to the provider's site in place of the default Auth0 development credentials. For instructions on how to get the credentials for each social provider, select your particular from the list at: [Identity Providers](/identityproviders). In production usage, you should always use your own credentials instead of [Auth0 devkeys](/connections/social/devkeys).
+
+## Keep reading
+
+* [Resource Owner](/mfa/guides/mfa-api/multifactor-resource-owner-password)
+* [Configure Silent Authentication](/api-auth/tutorials/silent-authentication)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/customize-phone-messages.md b/ja-jp/articles/mfa/guides/customize-phone-messages.md
new file mode 100644
index 0000000000..a33701d54b
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/customize-phone-messages.md
@@ -0,0 +1,54 @@
+---
+description: Customize SMS or Voice Messages
+topics:
+  - mfa
+  - guardian
+  - sms
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Customize SMS or Voice Messages
+
+To customize the SMS or Voice messages sent by Auth0 during enrollment or verification, do the following:
+
+First, go to the [Multi-factor Auth page](${manage_url}/#/mfa), then click on the **Phone** box to configure your Phone Messaging settings.
+
+![MFA Phone Settings](/media/articles/mfa/mfa-phone-templates.png)
+
+You have two fields to customize your messages:
+
+* **Enrollment Template**: the message sent by Auth0 during enrollment.
+* **Verification Template**: the message sent by Auth0 during authentication.
+
+[Liquid](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) syntax is the supported templating engine to use when accessing user attributes in SMS templates. The following attributes are available:
+
+* `message_type`: Can be "sms" or "voice", and can be used to indicate which kind of message is being sent.
+* `code`: The Enrollment/Verification code. When sending voice messages, this variable will have the value with dots between the digits (e.g. ‘1.2.3.4.5.6’), so it can be pronounced as independent digits by voice messaging providers.
+* `locale`: When using the New Universal Login experience or the MFA API, it will have the the [language selected for the login flow](/universal-login/i18n). 
+* `requestInfo.lang`: The browser Accept-Language header (ie, `es-AR,es;q=0.8`,`en-US,en`, and so on.). It can be used for localization when using the Classic Login Experience.
+* `tenant.friendlyName`: The **Friendly Name** set in [Tenant Settings](${manage_url}/#/tenant).
+* `pause`: A special variable that can be used when you want to make a pause during a voice message.
+
+## Examples
+
+```
+{% if message_type == "voice" %}
+  {% if locale contains "fr" %}
+  Bonjour, vous avez demandé à recevoir un code de vérification pour vous enregister avec {{tenant.friendly_name}}. Votre code est: {{pause}} {{code}}. Je répète, votre code est: {{pause}}{{code}}.
+  {% elsif locale contains "es" %}
+  Usted ha requerido un código de verificación para inscribirse con {{tenant.friendly_name}}. Su código es: {{pause}}{{code}}. Repito, su código es: {{pause}}{{code}}.
+  {% else %}
+  Hello, you requested a verification code to enroll with {{tenant.friendly_name}}. Your code is: {{pause}}{{code}}. I repeat, your code is: {{pause}}{{code}}.
+  {% endif %}
+{% else %}
+  {% if locale contains "fr" %}
+  {{code}} est votre code de vérification pour vous enregistrer avec {{tenant.friendly_name}}.
+  {% elsif locale contains "es" %}
+  {{code}} es su código para inscribirse con {{tenant.friendly_name}}.
+  {% else %}
+  {{code}} is your verification code to enroll with {{tenant.friendly_name}}.
+  {% endif %}
+{% endif %}
+```
diff --git a/ja-jp/articles/mfa/guides/enable-mfa.md b/ja-jp/articles/mfa/guides/enable-mfa.md
new file mode 100644
index 0000000000..fc86a9e176
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/enable-mfa.md
@@ -0,0 +1,40 @@
+---
+description: Learn how to enable MFA in the Dashboard.
+topics:
+  - mfa
+contentType:
+  - how-to
+useCase:
+  - enable-mfa-dashboard
+---
+# Enable Multi-Factor Authentication
+
+To enable MFA, you toggle on the factors (such as push notifications or SMS) you choose to enable in the Dashboard on your tenant. Next, you perform any further setup required to configure that factor, and last, you choose whether you wish to force MFA for all users or not. 
+
+You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication), to allow MFA to only be required in specific circumstances or force a particular factor to be used.
+
+1. To enable the factors you require, go to [Dashboard > Multifactor Auth](${manage_url}/#/mfa). Here you will find a series of toggles for the MFA factors supported by Auth0. 
+
+![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png)
+
+Any or all of these factors can be enabled simultaneously. When logging in the first time, the user will be shown the most secure factor available, but will be allowed to choose another factor to use if you have more than one factor enabled in the Dashboard. The Phone messaging and the Duo factors require further setup. You will have to click on the factor and fill in a few further settings before continuing.
+
+::: note
+Duo will only be available to end-users as a factor if it is the only factor that is enabled.
+:::
+
+2. Under **Policies**, next to **Require Multi-factor Auth**, choose **Always** or **Never**. If set to **Always**, users will be able to use any of the factors enabled in the Dashboard.
+
+3. Click **Save**.
+
+4. Configure your [factors](/mfa/concepts/mfa-factors). 
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Configure One Time Passwords for MFA](/mfa/guides/configure-otp)
+* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone)
+* [Configure Email Notifications for MFA](/mfa/guides/configure-email)
+* [Configure Cisco Duo](/mfa/guides/configure-cisco-duo)
+* [Customize SMS or Voice Messages](/mfa/guides/customize-phone-messages)
+* [Customize Multi-factor Authentication](/mfa/guides/customize-mfa-universal-login)
diff --git a/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md b/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md
new file mode 100644
index 0000000000..f50d2e5fef
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md
@@ -0,0 +1,134 @@
+---
+description: Learn how to create an enrollment ticket from the MFA API.
+topics:
+  - mfa
+  - step-up-authentication
+  - api
+  - custom-enrollment
+  - tickets
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Create Custom Enrollment Tickets
+
+It is also possible to manage users' enrollments by creating _enrollment tickets_ via the [post_ticket API](/api/management/v2#!/Guardian/post_ticket).
+
+This API will return an _enrollment ticket_ containing a `ticket_id` and a `ticket_url`, which can be used to enroll a user.
+
+The `ticket_url` can be delivered to the user (for instance, via email) and used to kick off the enrollment process.
+
+Alternatively, the ticket can be leveraged inside the [MFA Page](${manage_url}/#/mfa_page) to customize the Auth0 MFA widget's appearance:
+
+```html
+
+
+
+  2nd Factor Authentication
+  
+  
+  
+
+
+
+
+  
    
+    
    
+      
    Welcome! {{ userData.email }} enroll your device
    
+      
    
+
+        
+        
    
+      
    
+    
    
+  
    
+
+  
+
+  
+
+
+```
+
+This custom page displays the Auth0 MFA widget in both enrollment and standard multi-factor authentication (MFA) login scenarios. You can use the ticket variable to check which scenario is in use and control the content accordingly.
+
+For example, the following code displays a different message depending on whether the user is enrolling or authenticating:
+
+```html
+{% if ticket %}
+
    Welcome, {{ userData.email }}, enroll your device below
    
+{% else %}
+
    Welcome back, {{ userData.email }}, authenticate below
    
+{% endif %}
+````
+
+::: note
+The conditional logic around the existence of the `ticket` variable is also used in the initialization of the `Auth0MFAWidget` above.
+:::
+
+## Keep reading
+
+* [MFA Widget Reference](/mfa/references/mfa-widget-reference)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md b/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md
new file mode 100644
index 0000000000..48f60e38c5
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md
@@ -0,0 +1,162 @@
+---
+title: Guardian for Android SDK
+description: Learn how to install, use and configure options for the Guardian for Android SDK. 
+topics:
+  - mfa
+  - guardian
+  - android
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Guardian for Android SDK
+
+The [Guardian for Android SDK](https://github.com/auth0/Guardian.Android) helps you create Android apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization.
+
+## Requirements
+
+Android API level 15+ is required in order to use the Guardian Android SDK.
+
+## Install Guardian Android SDK
+
+Guardian is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). 
+
+1. To start using *Guardian* add these lines to your `build.gradle` dependencies file:
+
+    ```gradle
+    implementation 'com.auth0.android:guardian:0.4.0'
+    ```
+
+::: note
+You can check for the latest version on the repository [Releases](https://github.com/auth0/GuardianSDK.Android/releases) tab, in [Maven](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.auth0.android%22%20AND%20a%3A%22guardian%22), or in [JCenter](https://bintray.com/auth0/android/Guardian.Android).
+:::
+
+2. After adding your Gradle dependency, make sure to remember to sync your project with Gradle files.
+
+<%= include('../../_includes/_enable-push-notifications') %>
+
+<%= include('../../_includes/_configure-sns') %>
+
+## Use the SDK
+
+Guardian is the core of the SDK. You'll need to create an instance of this class for your specific tenant/url.
+
+```java
+Uri url = Uri.parse("https://tenant.guardian.auth0.com/");
+
+Guardian guardian = new Guardian.Builder()
+    .url(url)
+    .build();
+```
+
+or
+
+```java
+String domain = "tenant.guardian.auth0.com";
+
+Guardian guardian = new Guardian.Builder()
+    .domain(domain)
+    .build();
+```
+
+### Enroll
+
+The link between the second factor (an instance of your app on a device) and an Auth0 account is referred to as an enrollment.
+
+You can create an enrollment using the `Guardian.enroll` function, but first you'll have to create a new pair of RSA keys for it. The private key will be used to sign the requests to allow or reject a login. The public key will be sent during the enroll process so the server can later verify the request's signature.
+
+```java
+KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
+keyPairGenerator.initialize(2048); // you MUST use at least 2048 bit keys
+KeyPair keyPair = keyPairGenerator.generateKeyPair();
+```
+
+Next, obtain the enrollment information by scanning the Guardian QR code, and use it to enroll the account:
+
+```java
+Uri enrollmentUriFromQr = ...; // the URI obtained from a Guardian QR code
+
+CurrentDevice device = new CurrentDevice(context, "fcmToken", "deviceName");
+
+Enrollment enrollment = guardian
+    .enroll(enrollmentUriFromQr, device, keyPair)
+    .execute();
+```
+
+Alternatively, you can execute the request in a background thread:
+
+```java
+guardian
+    .enroll(enrollmentUriFromQr, device, keyPair)
+    .start(new Callback {
+        @Override
+        void onSuccess(Enrollment enrollment) {
+            // we have the enrollment data
+        }
+
+        @Override
+        void onFailure(Throwable exception) {
+            // something failed
+        }
+    });
+```
+
+The `deviceName` and `fcmToken` are data that you must provide:
+
+- The `deviceName` is the name that you want for the enrollment. It will be displayed to the user when the second factor is required.
+- The `fcmToken` is the token for Firebase Cloud Messaging push notification service. See the [docs](https://firebase.google.com/docs/cloud-messaging/android/client#sample-register) for more information about the FCM token.
+
+### Unenroll
+
+To disable multi-factor authentication you can delete the enrollment:
+
+```java
+guardian
+    .delete(enrollment)
+    .execute(); // or start(new Callback<> ...)
+```
+
+### Allow a login request
+
+Once you have the enrollment in place, you'll receive a FCM push notification every time the user needs multi-factor authentication.
+
+Guardian provides a method to parse the `Map` data inside the [RemoteMessage](https://firebase.google.com/docs/reference/android/com/google/firebase/messaging/RemoteMessage) received from FCM and return a `Notification` instance ready to be used.
+
+```java
+// at the FCM listener you receive a RemoteMessage
+@Override
+public void onMessageReceived(RemoteMessage message) {
+    Notification notification = Guardian.parseNotification(message.getData());
+    if (notification != null) {
+        // you received a Guardian notification, handle it
+        handleGuardianNotification(notification);
+        return;
+    }
+
+    /* handle other push notifications you might be using ... */
+}
+```
+
+Once you have the notification instance, you can approve the authentication request by using the `allow` method. You'll also need the enrollment that you obtained previously. If there are multiple enrollments, be sure to use the one that has the same `id` as the notification (the `enrollmentId` property).
+
+```java
+guardian
+    .allow(notification, enrollment)
+    .execute(); // or start(new Callback<> ...)
+```
+
+### Reject a login request
+
+To deny an authentication request, use `reject` instead. You can also add an optional reason for the rejection, which will be available in the guardian logs.
+
+```java
+guardian
+    .reject(notification, enrollment) // or reject(notification, enrollment, reason)
+    .execute(); // or start(new Callback<> ...)
+```
+
+## Keep reading
+
+* [Getting Started with Google Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html)
+* 
diff --git a/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md b/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md
new file mode 100644
index 0000000000..125aa8a0c3
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md
@@ -0,0 +1,187 @@
+---
+title: Guardian for iOS SDK
+description: Learn how to install, use and configure options for the Guardian for iOS SDK. 
+topics:
+  - mfa
+  - guardian
+  - ios
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Guardian for iOS SDK
+
+The [Guardian for iOS Software Development Kit](https://github.com/auth0/GuardianSDK.iOS) helps you create iOS apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization.
+
+For more general information on MFA, see [multi-factor authentication](/mfa).
+
+## Requirements
+
+The Guardian iOS SDK requires iOS 9.3+ and Swift 3.
+
+## Install Guardian iOS SDK
+
+### CocoaPods
+
+Guardian.swift is available through [CocoaPods](http://cocoapods.org).
+To install it, simply add the following line to your Podfile:
+
+```ruby
+pod "Guardian"
+```
+
+### Carthage
+
+In your Cartfile add this line
+
+```
+github "auth0/Guardian.swift"
+```
+
+<%= include('../../_includes/_enable-push-notifications') %>
+
+<%= include('../../_includes/_configure-sns') %>
+
+## Using the SDK
+
+`Guardian` is the core of the SDK. To get things going you'll have to import the library:
+
+```swift
+import Guardian
+```
+
+Then you'll need the Auth0 Guarduan domain for your account:
+
+```swift
+let domain = "{YOUR_ACCOUNT_NAME}.guardian.auth0.com"
+```
+
+### Enroll
+
+An enrollment is a link between the second factor and an Auth0 account. When an account is enrolled you'll need it to provide the second factor required to verify the identity.
+
+For an enrollment you need the following things, besides your Guardian Domain:
+
+- Enrollment Uri: The value encoded in the QR Code scanned from Guardian Web Widget or in your enrollment ticket sent to you, for example, by email.
+- APNS Token: Apple APNS token for the device and **MUST** be a `String`containing the 64 bytes (expressed in hexadecimal format)
+- Key Pair: A RSA (Private/Public) key pair used to assert your identity with Auth0 Guardian
+
+::: note
+In case your app is not yet using push notifications or you're not familiar with it, you should check their [docs](https://developer.apple.com/go/?id=push-notifications).
+:::
+
+After your have all of them, you can enroll your device:
+
+```swift
+Guardian
+        .enroll(forDomain: "{YOUR_GUARDIAN_DOMAIN}",
+                usingUri: "{ENROLLMENT_URI}",
+                notificationToken: "{APNS_TOKEN}",
+                keyPair: keyPair)
+        .start { result in
+            switch result {
+            case .success(let enrollment):
+                // success, we have the enrollment data available
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+On success you'll obtain the enrollment information, that should be secured stored in your application. This information includes the enrollment identifier, and the token for Guardian API associated to your device for updating or deleting your enrollment.
+
+#### RSA key pair
+
+Guardian.swift provides a convenience class to generate an RSA key pair and store it in iOS Keychain.
+
+```swift
+let rsaKeyPair = RSAKeyPair.new(
+    usingPublicTag: "com.auth0.guardian.enroll.public",
+    privateTag: "com.auth0.guardian.enroll.private"
+    )
+```
+
+::: note
+The tags should be unique since it's the identifier of each key inside iOS Keychain.
+:::
+
+::: note
+Since the keys are already secured stored inside iOS Keychain, you olny need to store the identifiers
+:::
+
+### Allow a login request
+
+Once you have the enrollment in place, you will receive a push notification every time the user has to validate their identity with MFA.
+
+Guardian provides a method to parse the data received from APNs and return a `Notification` instance ready to be used.
+
+```swift
+if let notification = Guardian.notification(from: notificationPayload) {
+    // we have received a Guardian push notification
+}
+```
+
+Once you have the notification instance, you can easily allow the authentication request by using
+the `allow` method. You'll also need the enrollment that you obtained previously.
+In case you have more than one enrollment, you'll have to find the one that has the same `id` as the
+notification (the `enrollmentId` property).
+
+```swift
+Guardian
+        .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment)
+        .allow(notification: notification)
+        .start { result in
+            switch result {
+            case .success:
+                // the auth request was successfully allowed
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+### Reject a login request
+
+To deny an authentication request call `reject` instead. You can also send an optional reject reason if
+you want. The reject reason will be available in the guardian logs.
+
+```swift
+Guardian
+        .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment)
+        .reject(notification: notification)
+        // or reject(notification: notification, withReason: "hacked")
+        .start { result in
+            switch result {
+            case .success:
+                // the auth request was successfully rejected
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+### Unenroll
+
+If you want to delete an enrollment -for example if you want to disable MFA- you can make the
+following request:
+
+```swift
+Guardian
+        .api(forDomain: "{YOUR_GUARDIAN_DOMAIN}")
+        .device(forEnrollmentId: "{USER_ENROLLMENT_ID}", token: "{ENROLLMENT_DEVICE_TOKEN}")
+        .delete()
+        .start { result in
+            switch result {
+            case .success:
+                // success, the enrollment was deleted
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html)
diff --git a/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md b/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md
new file mode 100644
index 0000000000..a1fe64bcfc
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md
@@ -0,0 +1,221 @@
+---
+description: Learn how to install, use and configure options for the Guardian SDKs. 
+topics:
+  - mfa
+  - guardian
+  - ios
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Install Guardian SDK
+
+The Guardian SDK provides a UI-less client for Guardian.
+
+```text
+npm install auth0-guardian-js
+```
+
+## Source files
+
+* [Full Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.js)
+* [Minified Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.min.js)
+
+## Configure Guardian
+
+```js
+var auth0GuardianJS = require('auth0-guardian-js')({
+	// For US tenants: https://{name}.guardian.auth0.com
+ 	// For AU tenants: https://{name}.au.guardian.auth0.com
+ 	// For EU tenants: https://{name}.eu.guardian.auth0.com
+	serviceUrl: "https://{{ userData.tenant }}.guardian.auth0.com",
+	requestToken: "{{ requestToken }}", // or ticket: "{{ ticket }}" - see below
+
+	issuer: {
+		// The issuer name to show in OTP Generator apps
+		label: "{{ userData.tenantFriendlyName }}",
+		name: "{{ userData.tenant }}",
+	},
+
+	// The account label to show in OTP Generator apps
+	accountLabel: "{{ userData.friendlyUserId }}",
+
+	// Optional, for debugging purpose only,
+	// ID that allows to associate a group of requests
+	// together as belonging to the same "transaction" (in a wide sense)
+	globalTrackingId: "{{ globalTrackingId }}"
+});
+```
+
+Use of `requestToken` or `ticket` depends on the authentication method. Ticket corresponds to a previously generated [enrollment ticket](/mfa/guides/guardian/create-enrollment-ticket).
+
+## Enroll devices
+
+Enrolling devices consists of the following steps:
+
+1. Start the transaction.
+2. (optional) Chck if the user is already enrolled. You cannot enroll twice.
+3. Send the information needed to enroll.
+4. Confirm enrollment.
+5. Show recovery code.
+
+Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. Some of the methods end up completing the authentication, whereas some others need an extra authentication step. You can know that by listening to the `enrollment-complete` event. 
+
+```js
+function enroll(transaction, method) {
+	if (transaction.isEnrolled()) {
+		console.log('You are already enrolled');
+		return;
+	}
+
+	var enrollData = {};
+
+	if (method === 'sms') {
+		enrollData.phoneNumber = prompt('Phone number'); // Collect phone number
+	}
+
+	return transaction.enroll(method, enrollData, function (err, otpEnrollment) {
+		if (err) {
+			console.error(err);
+			return;
+		}
+
+		var uri = otpEnrollment.getUri();
+		if (uri) {
+			showQR(uri);
+		}
+
+		var confirmData = {};
+		if (method === 'otp' || method === 'sms') {
+			confirmData.otpCode = prompt('Otp code'); // Collect verification otp
+		}
+
+		otpEnrollment.confirm(confirmData);
+	});
+}
+
+auth0GuardianJS.start(function(err, transaction) {
+	if (err) {
+		console.error(err);
+		return;
+	}
+
+	transaction.on('error', function(error) {
+		console.error(error);
+	});
+
+	transaction.on('timeout', function() {
+		console.log('Timeout');
+	});
+
+	transaction.on('enrollment-complete', function(payload) {
+		if (payload.recoveryCode) {
+			alert('Recovery code is ' + payload.recoveryCode);
+		}
+
+		if (payload.authRequired) {
+			showAuthenticationFor(transaction, payload.enrollment);
+			return;
+		}
+	});
+
+	transaction.on('auth-response', function(payload) {
+		if (payload.recoveryCode) {
+			alert('The new recovery code is ' + payload.recoveryCode);
+		}
+
+		if (!payload.accepted) {
+			alert('Authentication has been rejected');
+			return;
+		}
+
+		auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature });
+	});
+
+	var availableEnrollmentMethods = transaction.getAvailableEnrollmentMethods();
+
+	method = prompt('What method do you want to use, select one of '
+		+ availableEnrollmentMethods.join(', '));
+
+	enroll(transaction, method) // For sms
+});
+```
+
+## Authenticate
+
+To authenticate with a method you need to execute the following steps:
+
+1. Start the transaction.
+2. (optional) Check if the user is already enrolled. You need to be enrolled to authenticate.
+3. Request the auth (the push notification / sms). Request is a noop for OTP.
+4. Verify the otp (`.verify` is a noop for push)
+
+Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. After the factor is verified or the push accepted you will receive an `auth-response` event with the payload to send to the server, you can use the `auth0GuardianJS.formPostHelper('{{ postActionURL }}', payload)` to post back the message to the server.
+
+You may also receive `auth-rejected` if the push notification was received.
+
+```js
+function authenticate(method) {
+	auth0GuardianJS.start(function (err, transaction) {
+		if (err) {
+			console.error(err);
+			return;
+		}
+
+		if (!transaction.isEnrolled()) {
+			console.log('You are not enrolled');
+			return;
+		}
+
+		transaction.on('error', function(error) {
+			console.error(error);
+		});
+
+		transaction.on('timeout', function() {
+			console.log('Timeout');
+		});
+
+		transaction.on('auth-response', function(payload) {
+			if (payload.recoveryCode) {
+				alert('The new recovery code is ' + payload.recoveryCode);
+			}
+
+			if (!payload.accepted) {
+				alert('Authentication has been rejected');
+				return;
+			}
+
+			auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature });
+		});
+
+		var enrollment = transaction.getEnrollments()[0];
+
+		if (enrollment.getAvailableAuthenticatorTypes().length === 0) {
+			alert('Somethings went wrong, seems that there is no authenticators');
+			return;
+		}
+
+		transaction.requestAuth(enrollment, { method: method } function(err, auth) {
+			if (err) {
+				console.error(err);
+				return;
+			}
+
+			var data = {};
+			if (method === 'sms' || method === 'otp') {
+				data.otpCode = prompt('Otp code');
+			} else if (method === 'recovery-code') {
+				data.recoveryCode = prompt('Recovery code');
+			}
+
+			return auth.verify(data);
+		});
+	});
+}
+```
+
+## Keep reading
+
+* [Full Guardian API](https://github.com/auth0/auth0-guardian.js#full-api)
+* [Guarding SDK Error Code Reference](/mfa/references/guardian-error-code-reference)
diff --git a/ja-jp/articles/mfa/guides/import-user-mfa.md b/ja-jp/articles/mfa/guides/import-user-mfa.md
new file mode 100644
index 0000000000..963de16bd9
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/import-user-mfa.md
@@ -0,0 +1,163 @@
+---
+description: Import MFA enrollments for your existing users.
+topics:
+  - mfa
+contentType:
+  - how-to
+useCase:
+  - import-mfa
+---
+# Import Multi-Factor Authenticators
+
+You can import a user's MFA enrollments with [automatic migration](/users/guides/configure-automatic-migration) and [bulk user imports](/users/guides/bulk-user-imports). The supported enrollment types are:
+
+* Email: for [email](/mfa/concepts/mfa-factors#email-notifications) verification.
+* Phone: for [SMS](/mfa/concepts/mfa-factors#sms-notifications) or [Voice](/mfa/concepts/mfa-factors#voice-notifications) verification.
+* TOTP: for [One-Time Passwords (OTP)](/mfa/concepts/mfa-factors#one-time-passwords) used with authenticator applications, such as Google Authenticator.
+
+Importing MFA enrollments provides a seamless user experience, since users won't have to re-enroll after migration.
+
+::: warning
+Please note that the classic login experience does not support factor selection for users with multiple factors. If you plan to import users with multiple registered factors, consider using the [universal login](/universal-login) experience.
+
+:::
+
+## Schema
+
+The schema applies to MFA factors for both of the aforementioned workflows.
+
+```json
+{
+    "type": "array",
+    "items": {
+        "type": "object",
+        "properties": {
+            "totp": {
+                "type": "object",
+                "properties": {
+                "secret": {
+                    "type": "string",
+                        "pattern": "^[A-Z2-7]+$",
+                        "description": "The OTP secret is used for MFA authentication with Google Authenticator type apps. It must be supplied in un-padded Base32 encoding, such as: JBTWY3DPEHPK3PNP"
+                    },
+                },
+                "additionalProperties": false,
+                "required": ["secret"],
+            },
+            "phone": {
+                "type": "object",
+                "properties": {
+                "value": {
+                    "type": "string",
+                    "pattern": "^\\+[0-9]{1,15}$",
+                    "description": "The phone number for SMS or Voice MFA. The phone number should include a country code and begin with +, such as: +12125550001"
+                },
+                },
+                "additionalProperties": false,
+                "required": ["value"],
+            },
+            "email": {
+                "type": "object",
+                "properties": {
+                    "value": {
+                        "type": "string",
+                        "format": "email",
+                        "description": "The email address for MFA"
+                    },
+                },
+                "additionalProperties": false,
+                "required": ["value"],
+            },
+        },
+        "maxProperties": 1,
+        "additionalProperties": false,
+    },
+    "minItems": 1,
+    "maxItems": 10
+}
+```
+
+## Bulk User Import
+
+To begin, prepare a `users.json` file as described [here](/users/guides/bulk-user-imports). Be sure to include any existing MFA enrollments for each user. Next, start a bulk user import (described in more detail [here](/users/guides/bulk-user-imports#request-bulk-user-import)). You can _update_ the factors of any existing users by enabling the `upsert` option in your initial request.
+
+Once the import job completes, check the response for any errors. If any of the users' MFA factors failed to import, you will see errors such as: 
+
+```json
+{
+  "code": "MFA_FACTORS_FAILED",
+  "message": "Unable to import factors"
+}
+```
+
+When using the `upsert` option, any non-MFA related updates to existing users will have been applied to the user's profile. For example, the following error summary shows the user's `picture` attribute was successfully set to `http://example.org/jdoe.png`, however we were unable to import the provided MFA factors. In cases like this it is safe to retry the import for failed users.
+
+```json
+[
+  {
+    "user": {
+      "email": "antoinette@contoso.com",
+      "picture": "http://example.org/jdoe.png",
+      "mfa_factors": [
+        {
+          "totp": {
+            "secret": "2PRXZWZAYYDAWCD"
+          }
+        },
+        {
+          "phone": {
+            "value": "+15551112233"
+          }
+        },
+        {
+          "email": {
+            "value": "antoinette@antoinette.biz"
+          }
+        }
+      ]
+    },
+    "errors": [
+      {
+        "code": "MFA_FACTORS_FAILED",
+        "message": "Unable to import factors"
+      }
+    ]
+  }
+]
+```
+
+## Automatic Migration
+
+MFA enrollments can also be imported during an [automatic migration](/connections/database/custom-db/overview-custom-db-connections#automatic-migration-scenario). This can be accomplished by providing any existing enrollments in the `mfa_factors` field of the user that is provided to the callback at the end of your custom DB [login script](/connections/database/custom-db/templates/login).
+
+Any failures will appear in your tenant logs as failed logins, and will be distinguishable from other failures by their description: `Unable to import MFA factors`. For instance:
+
+```json
+{
+  "_id": "5e9df3b29ebabe00571c04a7",
+  "date": "2020-04-20T19:10:42.916Z",
+  "type": "fu",
+  "description": "Unable to import MFA factors.",
+  "connection": "Username-Password-Authentication",
+  "connection_id": "con_mMkvaycgzgCS0p0z",
+  "client_id": "aCbTAJNi5HbsjPJtRpSP6BIoLPOrSj2Cgg",
+  "client_name": "All Applications",
+  "ip": "10.12.13.1",
+  "client_ip": null,
+  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
+  "details": {
+    "error": {
+      "message": "Unable to import MFA factors."
+    }
+  },
+  "user_name": "test@test.io",
+  "strategy": "auth0",
+  "strategy_type": "database"
+}
+```
+
+## Recovery Codes
+
+Auth0 does not provide a way to import Recovery Codes. When the users's MFA factors are imported, they won't have a recovery code.
+
+If you want to provide users for a recovery code, you can check if they have one enrolled, and if not, use the [recovery code regeneration](/api/management/v2#!/Users/post_recovery_code_regeneration) API endpoint to generate a new one.
diff --git a/ja-jp/articles/mfa/guides/mfa-api/authenticate.md b/ja-jp/articles/mfa/guides/mfa-api/authenticate.md
new file mode 100644
index 0000000000..219932f6e9
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/authenticate.md
@@ -0,0 +1,137 @@
+---
+title: Authenticate With Resource Owner Password Grant and MFA
+description: Authenticate With Resource Owner Password Grant and MFA
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - otp
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Authenticate With Resource Owner Password Grant and MFA
+
+This guide explains how to use the MFA API to complete the authentication flow using [Resource Owner Password Grant](/api-auth/tutorials/password-grant) when MFA is enabled.
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## 1. Authenticate the User
+
+When you use the Resource Owner Password Grant to authenticate, you call the `/oauth/token` endpoint with the user's username/password: 
+
+```har
+{
+"method": "POST",
+"url": "https://${account.namespace}/oauth/token",
+"headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+],
+"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+    {
+        "name": "grant_type",
+        "value": "password"
+    },
+    {
+        "name": "username",
+        "value": "user@example.com"
+    },
+    {
+        "name": "password",
+        "value": "pwd"
+    },
+    {
+        "name": "client_id",
+        "value": "${account.clientId}"
+    },
+    {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+    },
+    {
+        "name": "audience",
+        "value": "https://someapi.com/api"
+    },
+    {
+        "name": "scope",
+        "value": "openid profile read:sample"
+    }
+    ]
+}
+}
+```
+
+When MFA is enabled, the response will include an `mfa_required` error and a `mfa_token`.
+
+```json
+{
+    "error": "mfa_required",
+    "error_description": "Multifactor authentication required",
+    "mfa_token": "Fe26...Ha"
+}
+```
+
+## 2. Retrieve the Enrolled Authenticators
+
+After getting the error above, you need to find out if the user has an MFA factor enrolled or not. Call [`/mfa/authenticators`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint, using the MFA token obtained in the previous step.
+
+```har
+{
+    "method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+    "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get an array with the available authenticators. The array will be empty if the user did not enroll any factor.
+
+```json
+[
+    {
+        "id": "recovery-code|dev_O4KYL4FtcLAVRsCl",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "email|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "email",
+        "name": "email@address.com"
+    }
+]
+```
+
+## 3. Enroll an MFA Factor
+
+If the user is not enrolled in MFA, use the MFA token obtained earlier, and enroll it using the `/mfa/associate` endpoint. The documents linked below explain how to implement this flow depending on the authentication factor:
+
+- [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice)
+- [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp)
+- [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push)
+- [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email)
+
+## 4. Challenge the User with MFA
+
+If the user is already enrolled in MFA, you need to challenge the user with one of the existing factors. Use the `authenticator_id` returned by the `/mfa/authenticators` endpoint when calling the `/mfa/challenge` endpoint. 
+
+After the challenge is completed, call `/oauth/token` again to finalize the authentication flow and get the authentication tokens. 
+
+The documents linked below explain how to implement this flow depending on the authentication factor:
+
+- [Challenging with SMS](/mfa/guides/mfa-api/phone#challenging-with-sms-or-voice)
+- [Challenging with OTP](/mfa/guides/mfa-api/otp#challenging-with-otp)
+- [Challenging with Push](/mfa/guides/mfa-api/push#challenging-with-push)
+- [Challenging with Email](/mfa/guides/mfa-api/email#challenging-with-email)
+- [Challenging with Recovery Code](/mfa/guides/mfa-api/recovery-code)
+
+## Keep reading
+
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/email.md b/ja-jp/articles/mfa/guides/mfa-api/email.md
new file mode 100644
index 0000000000..4cd4ba8dbb
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/email.md
@@ -0,0 +1,208 @@
+---
+title: Enroll and Challenge Email Authenticators
+description: Build your own MFA flows using email as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - email
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge Email Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+This guide will explain how to enroll and challenge users with Email using the MFA API. Make sure that Email is [enabled as factor](/mfa/guides/configure-email) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+
+::: note
+When Email is enabled as factor, all users with verified emails will be able to use them to complete MFA.
+
+Email authenticators are not supported when using the Classic Universal Login experience.
+:::
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with Email
+
+If you want to enable users enroll additional emails, in addition of the verified email in their primary identity, you need to complete the following steps.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+To enroll with Email, you need to use the following parameters:
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[email]`
+- `email` = `email@address.com`, the user's email address.
+
+  ```har
+  {
+      "method": "POST",
+      "url": "https://${account.namespace}/mfa/associate",
+      "headers": [{
+          "name": "Authorization",
+          "value": "Bearer MFA_TOKEN"
+      }],
+      "postData": {
+          "mimeType": "application/json",
+          "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"email\"], \"email\" : \"email@address.com\" }"
+      }
+  }
+  ```
+
+  If successful, you'll receive a response like this:
+
+  ```json
+  {
+    "authenticator_type": "oob",
+    "binding_method": "prompt",
+    "oob_code" : "Fe26..nWE",
+    "oob_channel": "email",
+    "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ]
+  }
+  ```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the email enrollment
+
+The user should receive an email containing the 6-digit code, which they can provide to the application.
+
+To complete enrollment of the email authenticator make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the email message.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/token",
+    "postData": {
+        "mimeType": "application/x-www-form-urlencoded",
+        "params": [
+          {
+            "name": "grant_type",
+            "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+          },
+          {
+            "name": "mfa_token",
+            "value": "MFA_TOKEN"
+          },
+          {
+            "name": "oob_code",
+            "value": "OOB_CODE"
+          },
+          {
+            "name": "binding_code",
+            "value": "USER_EMAIL_OTP_CODE"
+          },
+          {
+            "name": "client_id",
+            "value": "${account.clientId}"
+          }
+        ]
+    }
+}
+```
+
+For more information on how to customize the email that users get, check [Customizing Your Emails](/email/templates).
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with Email
+
+To challenge a user with Email, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Challenge the user with Email
+
+To challenge the user you first need to obtain the id of the authenticator you want to challenge using the [`/mfa/enrollments`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint.
+
+To trigger an email challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{  \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\",  \"challenge_type\": \"oob\",  \"authenticator_id\": \"email|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 3. Complete authentication using the received code
+
+If successful, you'll get the following response, and the user will get an email message containing the six-digit code:
+
+```json
+{
+  "challenge_type": "oob",
+  "oob_code": "abcd1234...",
+  "binding_method": "prompt"
+}
+```
+
+Your application needs to prompt the user for the code, and send it as part of the request, in the `binding_code` parameter, in the following call to the `/oauth/token` endpoint:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_EMAIL_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep Reading
+
+* [Configure Email Notifications for MFA](/mfa/guides/configure-email)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/manage.md b/ja-jp/articles/mfa/guides/mfa-api/manage.md
new file mode 100644
index 0000000000..128406fe8a
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/manage.md
@@ -0,0 +1,149 @@
+---
+title: Manage Authenticator Factors using the MFA API
+description: Learn how to manage your MFA authenticators
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Manage Authenticator Factors using the MFA API
+
+Auth0 provides several API endpoints to help you manage the authenticators you're using with an application for multi-factor authentication (MFA).
+
+You can use these endpoints to build a complete user interface for letting users manage their authenticator factors. 
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Getting an MFA API Access Token
+
+In order to call the MFA API to manage enrollments, you first need to obtain an Access Token for the MFA API.
+
+If you want to use the MFA API as part of an authentication flow, you can follow the steps detailed in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document.
+
+If you are building a user interface to manage authentication factors, you'll need to obtain a token you can use for the MFA API at any moment, not only during authentication:
+
+* If you are using [Universal Login](/universal-login), redirect to the `/authorize` endpoint, specifying the `https://${account.namespace}/mfa/` audience, before using calling the MFA API.
+* If you are using the Resource Owner Password Grant, you have two options:
+    * Ask for the `https://${account.namespace}/mfa/` audience when logging-in, and use a [Refresh Token](/tokens/concepts/refresh-tokens) to refresh it later.
+    * If you need to list and delete authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) with `/oauth/token`, specifying the `https://${account.namespace}/mfa/` audience. Users will need to complete MFA before being able to list/delete the authentication factors. 
+    * If you only need to list authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) using `/oauth/token`, with username/password. The endpoint will return an `mfa_required` error, and an `mfa_token` you can use to list authenticators. Users will need to provide their password to see their authenticators.
+
+When you request a token for the MFA audience, you can request the following scopes:
+
+* `enroll`: needed to enroll a new authenticator
+* `read:authenticators`: needed to list existing authenticators
+* `remove:authenticators`: needed to delete an authenticator
+
+## List Authenticators
+
+To get the list of the authenticators for a user, you can call the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MFA_TOKEN"
+	}]
+}
+```
+
+You should receive information about the authenticator type(s) in the response:
+
+```json
+[
+  {
+    "authenticator_type": "recovery-code",
+    "id": "recovery-code|dev_IsBj5j3H12VAdOIj",
+    "active": true
+  },
+  {
+    "authenticator_type": "otp",
+    "id": "totp|dev_nELLU4PFUiTW6iWs",
+    "active": true,
+  },
+  {
+    "authenticator_type": "oob",
+    "oob_channels": "sms",
+    "id": "sms|dev_sEe99pcpN0xp0yOO",
+    "name": "+1123XXXXX",
+    "active": true
+  }
+]
+```
+
+For the purposes of building an user interface for end users to manage their factors, you should ignore authenticators that have `active` = `false`. Those authenticators are not confirmed by users, so they can't be used to challenge for MFA.
+
+::: note
+- When a user enrolls with Push, Auth0 creates an OTP enrollment. You will see both when listing enrollments.
+- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`. 
+- When Email MFA is enabled, all verified emails will be listed as authenticators.
+- When a user enrolls any factor Auth0 creates a recovery code that will be listed as an authenticator.
+:::
+
+## Enroll Authenticators
+
+The documents below explain how to enroll with different factors:
+
+* [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice)
+* [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp)
+* [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push)
+* [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email)
+
+You can also [use the Universal Login flow](/mfa/guides/guardian/create-enrollment-ticket) for enrolling users at any moment.
+
+## Delete Authenticators
+
+To delete an associated authenticator, send a `DELETE` request to the `/mfa/authenticators/AUTHENTICATOR_ID` endpoint. You can get the `ID` when listing authenticators.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MFA_TOKEN"
+	}]
+}
+```
+
+If the authenticator was deleted, a 204 response is returned.
+
+:::note
+- When you enroll a Push authenticator, Auth0 also enrolls an OTP one. If you delete any of them, the other one will be also deleted.
+- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`.  When you delete one, the other will also be deleted.
+- If Email MFA is enabled, all verified emails will be listed as authenticators, but you can't delete them. You can only delete email authenticators that were enrolled explicitly.
+:::
+
+## Delete a Recovery Code
+
+To delete a Recovery Code, you need to use Management API's `/api/v2/users/USER_ID/recovery-code-regeneration` endpoint. You previously need to get a [Management API Access Token](/api/management/v2/tokens).
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/recovery-code-regeneration",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MANAGEMENT_API_TOKEN"
+	}]
+}
+```
+
+You will get a new recovery code that the end user will need to capture:
+
+```json
+{
+  "recovery_code": "FA45S1Z87MYARX9RG6EVMAPE"
+}
+```
+
+## Keep reading
+
+* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md b/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md
new file mode 100644
index 0000000000..61398e8c4b
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md
@@ -0,0 +1,347 @@
+---
+title: Multi-factor Authentication and Resource Owner Password
+description: How to use Multi-factor Authentication with Resource Owner Password Grant.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - mfa
+  - resource-owner-password
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Multi-factor Authentication and the Resource Owner Password Grant
+
+Highly-trusted applications can use the [Resource Owner Password Grant](/api-auth/grant/password) to access an API. The flow typically involves prompting the user for username and password as credentials to be submitted to Auth0. In some scenarios, however, stronger authentication may be required. This document outlines using multi-factor authentication (MFA) with the [Resource Owner Password Grant](/api-auth/grant/password).
+
+## Prerequisites
+
+Before you continue, make sure that you've met the following prerequisites:
+
+1. MFA is enabled on the [Auth0 dashboard](${manage_url}). [Duo Security](/mfa/guides/configure-cisco-duo) is __not__ supported as a factor with this flow.
+
+1. An Application is configured to execute the Resource Owner Password Grant (either [password](/api-auth/tutorials/password-grant) or [password-realm](/api-auth/tutorials/password-grant#realm-support) grant types). For details on how to implement this, refer to [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant).
+
+1. End users are enrolled in MFA.
+
+## Initiate Multi-factor Authentication
+
+The flow starts by collecting end-user credentials and sending them to Auth0, as described in [Resource Owner Password Grant](/api-auth/grant/password). Both [password](/api-auth/tutorials/password-grant) and [password-realm](/api-auth/tutorials/password-grant#realm-support) flows are available.
+
+1. The user enters their credentials into the Application.
+
+2. The Application forwards the credentials to Auth0.
+
+3. Auth0 validates the credentials and executes any applicable [rules](/rules).
+
+4. If any rule triggers MFA for the current user, an error code of `mfa_required` is returned. The error will additionally contain an `mfa_token` property.
+
+  ```json
+  HTTP/1.1 403 Forbidden
+  Content-Type: application/json
+  {
+    "error": "mfa_required",
+    "error_description": "Multi-factor authentication required",
+    "mfa_token": "eyJ0eXAiOiJKV1QiLCJhbGci....D3QCiQ"
+  }
+  ```
+
+5. The Application will then make a request to the [MFA challenge](/api/authentication#resource-owner-password-and-mfa) endpoint, specifying the challenge types it supports. Valid challenge types are: [OTP](#challenge-type-otp), [OOB with binding method `prompt`](#challenge-type-oob-and-binding-method-prompt), and [OOB with no binding method](#challenge-type-oob-with-no-binding-method). If you already know that `otp` is supported by the end-user and you don't want to request a different factor, you can skip this and the next steps an go directly to [Challenge Type `OTP`](#challenge-type-otp) below.
+
+6. Auth0 sends a response containing the `challenge_type` derived from the types supported by the Application and the specific user. Additionally, extra information, such as `binding_method` may be included to assist in resolving the challenge and displaying the correct UI to the user.
+
+The supported challenge types are:
+
+- `otp`: A one-time password generated by an app setup with a seed or by token generation hardware. This mechanism does not require an extra channel to prove possession of the device; you can get it directly from the app / hardware device.
+
+- `oob`: The proof of possession of the device here is done 'out of band' via a side channel. There are several different channels, including push notification-based authenticators, SMS, and Voice based authenticators. Depending on the channel and the authenticator chosen at enrollment, you may need to provide a `binding_code` used to bind the side channel and the channel used for authentication.
+
+To execute MFA, follow the next steps according to the challenge type you will use:
+
+- [OTP](#challenge-type-otp): for this challenge type, your application must prompt the end-user for an OTP code and continue the flow using the __mfa-otp__ grant type.
+
+- [OOB and binding method `prompt`](#challenge-type-oob-and-binding-method-prompt): the challenge will be sent through a side channel (such as SMS or Voice), and your application will need to prompt the user for the `binding_code` that was included as part of the challenge sent, as well as the `oob_code` received as response to this request to prove possession of the device.
+
+- [OOB with no binding method](#challenge-type-oob-with-no-binding-method): in this case, the proof of possession will be driven entirely in a side channel (such as a push notification-based authenticator). The response will include an `oob_code` that the Application will use to periodically check for the resolution of the transaction. Continue the flow using the __mfa-oob__ grant type.
+
+## Execute Multi-factor Authentication
+
+The following sections cover how to execute MFA based on the challenge type used.
+
+### Challenge Type: `OTP`
+
+![Resource Owner MFA OTP](/media/articles/api-auth/challenge-type-otp.png)
+
+For this type of challenge, the Application must get an one-time password (`otp`) code from a OTP Generator app, such as Google Authenticator or Microsoft Authenticator.
+
+::: note
+If you already know that the user supports OTP, then steps 5 and 6 above of the [Initiate Multi-factor Authentication](#initiate-multifactor-authentication) section are optional.
+:::
+
+7. The Application prompts the end user to enter an OTP code.
+
+8. The end user enters their OTP into the Application.
+
+9. The Application forwards the OTP code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` obtained in step 4 above.
+
+10. Auth0 validates the provided OTP and returns the Access Token and the Refresh Token.
+
+11. The Application can use the Access Token to call the API on behalf of the end user.
+
+### Challenge Type: `OOB` with Binding Method `prompt`
+
+![Resource Owner MFA OOB Prompt](/media/articles/api-auth/challenge-type-oob-with-binding-method.png)
+
+This challenge type, together with `prompt` binding method, indicates that the challenge will be delivered to the user using a side channel (such as SMS or Voice) and that a `binding_code` is needed to bind the side channel to the one being authenticated. The binding code is sent as part of the challenge message and it is usually an OTP-like code composed of 6 numeric digits.
+
+7. The Application prompts the user for the `binding_code` and stores the `oob_code` from step 6 for future use.
+
+8. The end user receives the challenge on the side channel and enters the `binding_code` into the Application.
+
+9. The Application forwards the `binding_code` to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6).
+
+10. Auth0 validates the `binding_code` and `oob_code` and returns the Access Token and the Refresh Token.
+
+11. The Application can use the Access Token to call the API on behalf of the end user.
+
+### Challenge Type: `OOB` with No Binding Method
+
+![Resource Owner MFA OOB](/media/articles/api-auth/challenge-type-oob-no-binding-method.png)
+
+In this scenario, the challenge will be sent using a side channel, however, there is no need for a `binding_code`. Currently, the only mechanism supported for this scenario is Push Notification with the Guardian Provider.
+
+7. The Application asks the user to accept the delivered challenge and keeps the `oob_code` from step 6 for future use.
+
+8. The Application polls Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6).
+
+9. Auth0 validates the provided `oob_code`, the `mfa_token` and returns:
+    - `authorization_pending` error: if the challenge has not been accepted nor rejected.
+    - `slow_down` error: if the polling is too frequent.
+    - an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point.
+    - `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point.
+
+10. The Application can use the Access Token to call the API on behalf of the end user.
+
+## Using Recovery Codes
+
+::: note
+This flow is not available when the user uses provider = `google-authenticator` or provider = `duo`.
+:::
+
+![Resource Owner MFA Recovery](/media/articles/api-auth/recovery-code.png)
+
+Some providers support using a recovery code to login in case the enrolled device is not available, or if lack of connectivity prevents receiving an OTP code or push notification.
+
+Using a recovery code is similar to using an OTP code to login. The main difference is that a new recovery code will be generated, and that the application must display this new recovery code to the user for secure storage.
+
+Steps 1-4 are the same as above.
+
+5. End user chooses to use the recovery code.
+
+6. The Application prompts the end user to enter recovery code.
+
+7. The end user enters their recovery code into the Application.
+
+8. The Application forwards the recovery code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` from step 4.
+
+9. Auth0 validates the recovery code and returns the Access Token and the Refresh Token.
+
+10. The Application can use the Access Token to call the API on behalf of the end user.
+
+## Samples
+
+The following are sample implementations involving MFA.
+
+### Resource Owner Password Grant Request
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'password',
+     username: 'USERNAME',
+     password: 'PASSWORD',
+     audience: 'API_IDENTIFIER',
+     scope: 'SCOPE',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+  };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  if (body.error === 'mfa_required') {
+    // Show mfa flow and give user option to go to the recovery flow (if supported)
+
+    if (/* MFA Recovery is requested*/) {
+      const recovery_code = // Prompt for recovery code
+      mfaRecovery(body.mfa_token, recovery_code) // See MFA Recovery grant
+    } else {
+      mfaChallenge(body.mfa_token)
+    }
+  }
+});
+```
+
+### Challenge Request
+
+```javascript
+function mfaChallenge(mfa_token) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/mfa/challenge',
+    headers: { 'content-type': 'application/json' },
+    body:
+    { mfa_token: mfa_token,
+      challenge_type: 'oob otp', // Supported challenge types, space separated
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' },
+    json: true };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (body.challenge_type === 'otp') {
+      const otp = // Prompt for otp code (see MFA OTP grant request)
+      mfaOTP(mfa_token, otp)
+    } else if (body.challenge_type === 'oob') {
+      if (body.binding_method === 'prompt') {
+        const binding_code = // Prompt for binding code (see MFA OOB with binding code grant request)
+        mfaOOB(mfa_token, body.oob_code, binding_code)
+      } else if (!body.binding_method) {
+        // Ask the user to accept the challenge and start polling (see MFA OOB without binding code grant request)
+        mfaOOB(mfa_token, body.oob_code)
+      } else {
+        console.error('Unsupported binding_method');
+      }
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+### MFA OTP Grant Request
+
+```javascript
+function mfaOTP(mfa_token, otp) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      otp: otp,
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-otp',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+  };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (response.statusCode === 200) {
+      // The tokens returned depend on the scopes requested on the password grant request
+      console.log(body.access_token, body.id_token, body.refresh_token);
+    } else if (body.error === 'invalid_grant') {
+      // Invalid otp code
+      console.error('Invalid otp');
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+### MFA OOB Grant Request
+
+```javascript
+function mfaOOB(mfa_token, oob_code, /* optional */ binding_code) {
+  makeOOBGrantRequest(mfa_token, oob_code, binding_code, function(error, result) {
+    if (error) { throw error; }
+
+    if (result.state === 'authorization_pending') {
+      // Poll every 10 seconds
+      setTimeout(() => makeOOBGrantRequest(mfa_token, oob_code, binding_code), 10000);
+    } else if (result.state === 'authorized')  {
+      console.log(result.body.access_token, result.body.id_token, result.body.refresh_token);
+    } else {
+      console.error('You are not authorized')
+    }
+  });
+}
+
+function makeOOBGrantRequest(mfa_token, oob_code, /* optional  */ binding_code, cb) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      oob_code: oob_code,
+      binding_code: binding_code, // Only when binding_method = prompt
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-oob',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+    };
+
+  request(options, function (error, response, body) {
+    if (error) { return cb(error); }
+
+    if (response.statusCode === 200) {
+      // The tokens returned depend on the scopes requested on the password grant request
+      cb(null, { state: 'authorized', body });
+    } else if (body.error === 'invalid_grant') {
+      // Invalid otp code
+      cb(null, { state: 'not_authorized' });
+    } else if (body.error === 'authorization_pending') {
+      cb(null, { state: 'authorization_pending' });
+    } else if (body.error === 'slow_down') {
+      // You are polling too fast, slow down the polling rate,
+      // You may want to check rate-limiting headers to manage your polling rate
+      setTimeout(() => cb({ state: 'authorization_pending' }), 20000);
+    } else {
+      cb(new Error('Something went wrong'))
+    }
+  });
+}
+```
+
+### MFA Recovery Grant Request
+
+```javascript
+function mfaRecovery(mfa_token, recovery_code) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      recovery_code: recovery_code,
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+    };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (response.statusCode === 200) {
+      console.log('Please store this new recovery code safely -- the previous code will no longer work.', body.recovery_code)
+
+      // The tokens returned depend on the scopes requested on the password grant request
+      console.log(body.access_token, body.id_token, body.refresh_token);
+    } else if (body.error === 'invalid_grant') {
+      // Invalid recovery code
+      console.error('Invalid recovery_code');
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+## MFA API
+
+See [MFA API](/mfa/concepts/mfa-api) for detailed information about Auth0's MFA API endpoints.
diff --git a/ja-jp/articles/mfa/guides/mfa-api/otp.md b/ja-jp/articles/mfa/guides/mfa-api/otp.md
new file mode 100644
index 0000000000..f2efd0e81a
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/otp.md
@@ -0,0 +1,221 @@
+---
+title: Enroll and Challenge OTP Authenticators
+description: Build your own MFA flows using OTP as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - otp
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge OTP Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+This guide explains how to enroll and challenge users with OTP using the MFA API. First, make sure that OTP is [enabled as factor](/mfa/guides/configure-otp) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with OTP
+
+### 1. Get the MFA Token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+To enroll with OTP you need to set the `authenticator_types` parameter to `[otp]`.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"otp\"] }"
+	}
+}
+```
+
+If successful, you'll receive a response like this:
+
+```json
+{
+  "authenticator_type": "otp",
+  "secret": "EN...S",
+  "barcode_uri": "otpauth://totp/tenant:user?secret=...&issuer=tenant&algorithm=SHA1&digits=6&period=30",
+  "recovery_codes": [ "N3B...XC"]
+}
+```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the OTP enrollment
+
+To confirm the enrollment, the end user will need to enter the secret obtained in the previous step in an OTP generator application like Google Authenticator. They can enter the secret by scanning a QR code with the `barcode_uri` or by typing the `secret` code manually in that OTP application. You should provide users a way to get the `secret` as text in case they cannot scan the QR code (e.g. if they are enrolling from a mobile device, or using a desktop OTP application).
+
+After the users enter the secret, the OTP application will display a 6-digit code, that the user should enter in your application. The application should then make a `POST` request to the `oauth/token` endpoint, including that `otp` value.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-otp"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "otp",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+	}
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with OTP
+
+To challenge a user with OTP, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_qpOkGUOxBpw6R16t",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "totp|dev_6NWz8awwC8brh2dN",
+        "authenticator_type": "otp",
+        "active": true
+    }
+]
+```
+
+### 3. Challenge the user with OTP
+
+To trigger an OTP challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"challenge_type\": \"otp\", \"mfa_token\": \"MFA_TOKEN\", \"authenticator_id\" : \"totp|dev_6NWz8awwC8brh2dN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response: 
+
+```json
+{
+  "challenge_type": "otp"
+}
+```
+
+The user will collect a one-time password, which you will then collect from them. You can the  verify the code and get authentication tokens using the `/oauth/token` endpoint, specifying the one-time password in the `otp` parameter:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-otp"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "otp",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep Reading
+
+* [Configure One-Time Passwords for MFA](/mfa/guides/configure-otp)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge SMS or Voice Authenticators](/mfa/guides/mfa-api/phone)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/phone.md b/ja-jp/articles/mfa/guides/mfa-api/phone.md
new file mode 100644
index 0000000000..02ec707bba
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/phone.md
@@ -0,0 +1,256 @@
+---
+title: Enroll and Challenge SMS or Voice Authenticators
+description: Build your own MFA flows using SMS or Voice as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - sms
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge SMS or Voice Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+::: warning
+Voice MFA is currently a Beta feature. It should not be used in production environments.
+::: 
+
+This guide explains how to enroll and challenge users with SMS or a voice call using the MFA API. First, make sure that Phone is [enabled as factor](/mfa/guides/configure-phone) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with SMS or Voice
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+When a user enrolls with Voice or SMS, they are actually enrolling a phone number that can be challenged either with SMS or Voice.
+
+You need to specify the parameters below to call the endpoint. The `oob_channels` parameter indicates how you want to send the code to the user (SMS or Voice):
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[sms]` or `[voice]`.
+- `phone_number` = `+11...9`, the phone number [E.164 format](https://en.wikipedia.org/wiki/E.164)
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"sms\"], \"phone_number\": \"+11...9\" }"
+	}
+}
+```
+
+If successful, you'll receive a response like the one below:
+
+```json
+{
+  "authenticator_type": "oob",
+  "binding_method": "prompt",
+  "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ],
+  "oob_channels": "sms",
+  "oob_code": "ata6daXAiOi..."
+}
+```
+
+If you get a `User is already enrolled error`, it is because the user already has an MFA factor enrolled. Before associating it with another factor, you need to challenge the user with the existing one.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the SMS or Voice enrollment
+
+Users should receive an message with a 6-digit code that they need to provide to the application.
+
+To complete enrollment, make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the message.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+	}
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with SMS or Voice
+
+To challenge a user with SMS or Voice, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_O4KYL4FtcLAVRsCl",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "sms|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "sms",
+        "name": "XXXXXXXX8730"
+    },
+        {
+        "id": "voice|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "voice",
+        "name": "XXXXXXXX8730"
+    }
+]
+```
+
+Note that you have two authenticators with different `authenticator_id` for Voice or SMS. 
+
+### 3. Challenge the user with SMS or Voice
+
+To trigger the challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` and the MFA Access Token.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"sms|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response, and the user will get a message containing the required six-digit code:
+
+```json
+{
+  "challenge_type": "oob",
+  "oob_code": "asdae35fdt5...",
+  "binding_method": "prompt"
+}
+```
+
+Your application needs to prompt the user for 6-digit code sent in the message, and should be set in the `binding_code` parameter.
+
+You can then verify the code and get the authentication tokens using the `/oauth/token` endpoint, using the `binding_code` and the `oob_code` returned by the previous call:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep reading
+
+* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/push.md b/ja-jp/articles/mfa/guides/mfa-api/push.md
new file mode 100644
index 0000000000..d2d0902bdd
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/push.md
@@ -0,0 +1,250 @@
+---
+title: Enroll and Challenge Push Authenticators
+description: Build your own MFA flows using Push as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge Push using Guardian
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it.
+
+This guide explains to enroll and challenge users using Push Notifications with the Guardian Application or SDK, using the MFA API. First, make sure that Push is [enabled as factor](/mfa/guides/configure-push) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with Push
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+To enroll with Push, you need to use the following parameters:
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[auth0]`
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"auth0\"] }"
+	}
+}
+```
+
+If successful, you'll receive a response like the one below:
+
+```json
+{
+    "authenticator_type": "oob",
+    "barcode_uri": "otpauth://totp/tenant:user?enrollment_tx_id=qfjn2eiNYSjU3xID7dBYeCBSrdREWJPY&base_url=tenan",
+    "recovery_codes": [
+        "ALKE6EJZ4853BJYLM2DM2WU7"
+    ],
+    "oob_channels": "auth0",
+    "oob_code": "Fe26.2...SYAg"
+}
+```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the Push enrollment
+
+To confirm the enrollment, the end user will need to scan the a QR code with the `barcode_uri` in the Guardian App. Once that is done the Guardian App will notify Auth0 that the user enrolled successfully. To know if that happened, you need to poll the `/oauth/token` endpoint with the `oob_code` returned by the `/associate` call:
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      }
+    ]
+	}
+}
+```
+
+If the user did has not scanned the code, it will return an `authorization_pending` response, indicating you need to call `oauth_token` again in a few seconds:
+
+```json
+{
+    "error": "authorization_pending",
+    "error_description": "Authorization pending: please repeat the request in a few seconds."
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with Push
+
+To challenge a user with Push, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_Ahb2Tb0ujX3w7ilC",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "push|dev_ZUla9SQ6tAIHSz6y",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "auth0",
+        "name": "user's device name"
+    },
+    {
+        "id": "totp|dev_gJ6Y6vpSrjnKeT67",
+        "authenticator_type": "otp",
+        "active": true
+    }
+]
+```
+
+Note that when users enroll with Push, they also get enrolled in OTP, as Guardian supports [challenging with OTP](/mfa/guides/mfa-api/otp/#challenging-with-otp) for scenarios where the user does not have connectivity.  
+
+### 3. Challenge the user with Push
+
+To trigger an Push challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"push|dev_ZUla9SQ6tAIHSz6y\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response, and the user will get an Push notification:
+
+```json
+{
+    "challenge_type": "oob",
+    "oob_code": "Fe26...jGco"
+}
+
+```
+
+Your application needs to start polling the `/oauth/token` endpoint until the user accepts the Push notification. If the endpoint returns `
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      }
+    ]
+  }
+}
+```
+
+This call can return one of the following results:
+
+- `authorization_pending` error: if the challenge has not been accepted nor rejected.
+- `slow_down` error: if the polling is too frequent.
+- an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point.
+- `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point.
+
+## Keep Reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md b/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md
new file mode 100644
index 0000000000..038abaefc1
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md
@@ -0,0 +1,91 @@
+---
+description: Use the MFA API to challenge users who lose access to their device or account using recovery codes.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - recovery-codes
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Challenge with Recovery Codes
+
+Auth0 automatically generates recovery codes when users enroll with MFA. These codes can be used when users lost access to the device or account they used to enroll MFA.
+
+This guide explains how to enable users to authenticate using a recovery code using the MFA API.
+
+## 1. Prompt the user for the recovery code
+
+When the user enrolls with MFA, Auth0 generates a recovery code, that the user should capture. That value should be entered in the application for the user to authenticate. 
+
+::: note
+Auth0 does not generate recovery codes for DUO and for the legacy `google-authenticator` factor.
+:::
+
+## 2. Authenticate using the Recovery Code
+
+Call the `/oauth/token` endpoint with the recovery code to authenticate and generate a new recovery code. You need to specify the following parameters:
+
+- `grant_type` : `http://auth0.com/oauth/grant-type/mfa-recovery-code`
+- `recovery_code` : the recovery code provided by the user
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-recovery-code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "recovery_code",
+        "value": "RECOVERY_CODE"
+      }
+    ]
+  }
+}
+```
+
+### 3. Ask the user to capture the new Recovery Code
+
+If the call is successful, you'll get the authentication tokens and a new recovery code:
+
+```json
+{
+    "access_token": "O3...H4",
+    "id_token": "eyJh...w",
+    "scope": "openid profile",
+    "expires_in": 86400,
+    "recovery_code": "K6LGLV3RSH3VERMKET8L7QKU",
+    "token_type": "Bearer"
+}
+```
+
+You should let the user know that a new recovery code was generated and ask them to capture it.
+
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
diff --git a/ja-jp/articles/mfa/guides/reset-user-mfa.md b/ja-jp/articles/mfa/guides/reset-user-mfa.md
new file mode 100644
index 0000000000..fde72fc781
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/reset-user-mfa.md
@@ -0,0 +1,52 @@
+---
+description: Learn how to reset a user's MFA in case they lose their mobile device and do not have a recovery code. 
+topics:
+  - mfa
+  - user-management
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Reset User's MFA
+
+If a user has lost their mobile device, they can use their recovery code to log in. If they do not have a recovery code, they will need their tenant administrator to reset their multi-factor authentication (MFA). 
+
+This action is equivalent to removing or deleting the user's MFA registration. The MFA settings associated with their user will be removed, which allows them to set up MFA as if they were a new user on their next login attempt.
+
+::: note
+If you need to reset an admin's MFA as opposed to an end user's MFA, please contact [Auth0 Support](https://auth0.com/docs/support).
+:::
+
+## Reset MFA in the Dashboard
+
+1. Go to [Dashboard > Users & Roles > Users](${manage_url}/#/users).
+2. Click on the user whose MFA you want to reset.
+3. Click on the **Actions** button on the top right of the screen.
+4. Select **Reset Multi-factor** from the dropdown.
+
+  Admins will also see a **Reset MFA** link at the bottom of the **Multi-Factor Authentication** tab of the **User Details** page if the user is already enrolled in MFA. Both these methods function the same way. 
+
+5. There will be a pop up box to confirm your decision.  Click **YES, RESET IT** to reset the user's MFA.
+
+The next time the user logs in, they will need to setup their MFA just like a new user.
+
+## Reset MFA using the Management API
+
+As an admin, you can also use the Management API to delete a user's MFA enrollment using `DELETE /api/v2/guardian/enrollments/{id}`. This requires getting the enrollment ID first with a `GET` to the same endpoint. If the user has more than one enrollment, you will need to repeat the process for each enrollment.
+
+## Recovery codes
+
+With most MFA factors, the end user will be given a recovery code upon signup, which should be noted and kept secret. If they do not have their device or are otherwise temporarily unable to use their normal MFA process, the user can log in by entering this code after their username and password. 
+
+![MFA Recovery Code](/media/articles/mfa/recovery-code.png)
+
+::: note
+If a recovery code is used, a new recovery code will be provided at that time.
+:::
+
+If a user uninstalls then later re-installs Guardian, they may be prompted to enter their recovery code. If the recovery code has been lost, the user can perform a new installation of the app by disabling automatic restoration of their Guardian backup. To do so, the user will need to uninstall Guardian, temporarily disable automatic restoration of backups within their device settings (steps to do so will vary according to the device), then re-install the app. They will then need to add their MFA account(s) to the app as if performing a first-time setup. If automatic backups or automatic restoration are not enabled on the user's device, re-installation of the app will not prompt for a recovery code and the user will be required to add their MFA account(s) as in a first-time setup.
+
+## Keep reading
+
+* [Reset Auth0 Account Password](/support/reset-account-password)
diff --git a/ja-jp/articles/mfa/index.md b/ja-jp/articles/mfa/index.md
new file mode 100644
index 0000000000..a31faa4646
--- /dev/null
+++ b/ja-jp/articles/mfa/index.md
@@ -0,0 +1,31 @@
+---
+title: Multi-factor Authentication
+description: Understand how MFA works in Auth0.
+classes: topic-page
+topics:
+    - mfa
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication
+
+Multi-factor Authentication (MFA) provides a method to verify a user's identity by requiring them to provide more than one piece of identifying information. This ensures that only valid users can access their accounts even if they use a username and password that may have been compromised from a different application. 
+
+To enable MFA, go to [Dashboard > Multifactor Auth](${manage_url}/#/guardian) and toggle on the factors you want to enable on your tenant, such as push notifications or SMS. Next, perform any further setup required to configure that factor, then choose whether you wish to force MFA for all users or not. You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication) to allow MFA to only be required in specific circumstances or force a particular factor to be used.
+
+See the following sections for more details:
+
+<%= include('../_includes/_topic-links', { links: [
+  'mfa/concepts/mfa-factors',
+  'mfa/guides/enable-mfa',
+  'mfa/concepts/guardian',
+  'mfa/guides/customize-mfa-universal-login',
+  'mfa/guides/reset-user-mfa',
+  'mfa/guides/import-user-mfa',
+  'mfa/concepts/mfa-developer-resources',
+  'mfa/concepts/step-up-authentication',
+  'mfa/references/troubleshoot-mfa'
+] }) %>
+
diff --git a/ja-jp/articles/mfa/references/guardian-error-code-reference.md b/ja-jp/articles/mfa/references/guardian-error-code-reference.md
new file mode 100644
index 0000000000..696d3e70de
--- /dev/null
+++ b/ja-jp/articles/mfa/references/guardian-error-code-reference.md
@@ -0,0 +1,49 @@
+---
+title: Guardian Error Code Reference
+description: Lists Guardian error codes and descriptions.
+topics:
+    - guardian
+contentType:
+  - reference
+useCase:
+  - customize-mfa
+---
+# Guardian Error Code Reference
+
+Use the error codes to display informative messages and to distinguish between recoverable and unrecoverable errors. 
+
+| Error Code |	Description |
+| -- | -- |
+| `invalid_token`	| Invalid request or transaction token
+| `insufficient_scope` | You don't have enought grants to perform the requested operation
+| `invalid_bearer_format`	| The bearer put in authentication header was not valid
+| `enrollment_conflict`	| There is another enrollment for the same user. You cannot enroll twice.
+| `tenant_not_found`	| The tenant associated cannot be found. Should not normally happen at least that you delete the tenant
+| `login_transaction_not_found`	| The mfa auth transaction is not active or has already expired
+| `error_sending_push_notification`	| Push notification delivery failed
+| `push_notification_wrong_credentials`	| Push notification delivery failed because of wrong credentials
+| `invalid_otp`	| Provided otp code was not valid
+| `invalid_recovery_code`	| Provided recovery code was not valid
+| `invalid_body`	| Body validation failed. Bad request.
+| `invalid_query_string`	| Query string validation failed. Bad request.
+| `enrollment_transaction_not_found`	| The mfa enrollment transaction is not active or has expired
+| `invalid_phone_number`	| The provided phone number is invalid
+| `error_sending_sms`	| SMS Delivery error
+| `feature_disabled`	| The requested feature is currently globally not available (contact the provider)
+| `feature_disabled_by_admin`	| The requested feature is currently disabled by your admin
+| `pn_endpoint_disabled`	| We were unable to deliver the push notification after retrying many times. Try removing you account for the device and adding it again.
+| `too_many_sms`	| You have exeed the amount of SMSs assigned to your user
+| `too_many_pn`	| You have exeed the amount of push notifications assigned to your user
+| `too_many_sms_per_tenant`	| You have exeed the amount of SMSs assigned to your tenant
+| `too_many_pn_per_tenant`	| You have exeed the amount of push notifications assigned to your tenant
+| `field_required`	| A field is required to perform the operation (this errors has a field attribute with a code for the field: `otpCode`, `recoveryCode`)
+| `method_not_found`	| You have requested a method that is currently not supported (should not happen)
+| `no_method_available`	| There is currently no method to enroll (all of them are disabled)
+| `enrollment_method_disabled`	| The specified enrollment method is disabled, this error has also a .method field
+| `auth_method_disabled`	| The specified authentication method is disabled, this error has also a .method field
+| `invalid_otp_format`	| OTP format validation error
+| `invalid_recovery_code_format`	| Recovery code format validation error
+| `transaction_expired`	| The transaction has already expired
+| `already_enrolled`	| You are already enrolled, cannot enroll again
+| `not_enrolled`	| You not enrolled. Must enroll first
+| `invalid_enrollment`	| The enrollment provided to transaction#requestAuth method is not valid or is null/undefined
diff --git a/ja-jp/articles/mfa/references/language-dictionary.md b/ja-jp/articles/mfa/references/language-dictionary.md
new file mode 100644
index 0000000000..614f9d1c5f
--- /dev/null
+++ b/ja-jp/articles/mfa/references/language-dictionary.md
@@ -0,0 +1,231 @@
+---
+description: Describes the MFA hosted page configuration options for customizing the theme properties of the MFA pages. 
+topics:
+  - mfa
+  - hosted-pages
+contentType: reference
+useCase: customize-hosted-pages
+---
+# MFA Theme Language Dictionary
+
+## defaultLocation
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  defaultLocation : ['United Kingdom', 'GB', '+44'],
+  
+...
+
+})
+```
+
+## languageDictionary
+
+The `languageDictionary` can be used to override the text for many areas of the MFA process on Universal Login Classic Experience. You do this with the following format:
+
+```
+languageDictionary:
+  optionsCategory:
+    option: value
+```
+
+Here is an example, modifying the `headerText` attribute in `smsEnrollmentConfirm`:
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  languageDictionary:{ // Use the Language Dictionary option
+    smsEnrollmentConfirm:{  // Indicate which category/section you are modifying
+      headerText: "Some custom text - In order to confirm enrollment we need to confirm your phone. Please enter the received code." // Provide the new value for the specific attribute you wish to modify
+    }
+  }
+
+...
+
+})
+```
+
+See below for a list of available categories and options.
+
+### languageDictionary options
+
+```js
+defaults: {
+  iddleHelpUrl: '#',
+  rememberBrowserCheckbox: 'Remember this browser',
+  title: 'Login to {tenantName}'
+},
+
+downloadApp: {
+  headerText: 'Download Auth0 Guardian for free:',
+  pushEnrollmentAction: 'I\'ve already downloaded it',
+  smsAndTotpEnrollmentActions: 'I\'d rather use SMS or Google Authenticator',
+  pushAndTotpEnrollmentActions: 'I\'d rather use Guardian or Google Authenticator',
+  pushAndSmsEnrollmentActions: 'I\'d rather use Guardian or SMS',
+  totpEnrollmentActions: 'I\'d rather use Google Authenticator',
+  smsEnrollmentActions: 'I\'d rather use SMS',
+  pushEnrollmentActions: 'I\'d rather use Guardian',
+  iosLabel: 'App Store',
+  iosUrl: 'https://itunes.apple.com/us/app/auth0-guardian/id1093447833?ls=1&mt=8',
+  iosImg: '',
+  androidLabel: 'Google Play',
+  androidUrl: 'https://play.google.com/store/apps/details?id=com.auth0.guardian',
+  androidImg: ''
+},
+
+pushAuth: {
+  pushSent: {
+    useTotpFallback: 'If you haven\'t received the notification,

    just enter the code manually.'
+  },
+
+  pushTimeout: {
+    resendAction: 'Resend push notification',
+    timeoutText: 'Didn\'t receive the push notification?',
+    useRecoveryCode: 'Lost your device? Use the recovery code',
+    useTotpFallback: 'Enter the code manually'
+  }
+},
+
+totpAuth: {
+  codePlaceholder: 'Enter the 6-digit code',
+  headerText: 'Get a verification code from the Google Authenticator (or similar) app:',
+  useRecoveryCode: 'Lost your device? Use the recovery code'
+},
+
+smsAuth: {
+  codePlaceholder: 'Enter the 6-digit code',
+  headerText: 'Enter the 6-digit code we\'ve just sent to your phone.',
+  useRecoveryCode: 'Lost your device? Use the recovery code'
+},
+
+guardianTotpAuth: {
+  codePlaceholder: 'Enter the 6-digit code',
+  headerText: 'Get a verification code from the Auth0 Guardian app.'
+},
+
+recoveryCodeAuth: {
+  codePlaceholder: 'Enter your code here',
+  headerText: 'We will generate a new recovery code
    once you\'ve logged in:'
+},
+
+pushEnrollment: {
+  headerText: 'Scan this code with Auth0 Guardian:'
+},
+
+enrollmentCongrats: {
+  congrats: 'Congratulations, you are all set.
    In the future when logging in you\'ll want your device handy.',
+  continueButtonText: 'Continue'
+},
+
+reportRecoveryCode: {
+  headerText: 'In the event that you need to login without your device you\'ll need a recovery code. Take a note and keep this somewhere safe:',
+  confirmationLabel: 'I have safely recorded this code'
+},
+
+generalError: {
+  errorsRecoveryHelp: {
+    default: 'Looks like something went wrong.
    Please try logging in again from the application.',
+
+    globalTransactionExpired: 'The login was not successful.
    Please try again.',
+
+    // Auth0 Server Errors
+    guardianInvalidNonce: 'Please try logging in again from the application.',
+    guardianInvalidToken: 'Please try logging in again from the application.',
+    invalidLoginTokenStatus: 'Please try logging in again from the application.',
+    loginTokenInvalidSignature: 'Please try logging in again from the application.',
+    loginTokenTransactionExpired: 'Please try logging in again from the application.'
+  }
+},
+
+smsEnrollmentConfirm: {
+  codePlaceholder: 'Enter the 6-digit code',
+  headerText: 'In order to confirm enrollment we need to confirm your phone. Please enter the received code.'
+},
+
+totpEnrollment: {
+  codePlaceholder: 'Enter your passcode here',
+  headerText: 'Scan this QR code with Google Authenticator (or similar) app:'
+},
+
+totpEnrollmentCode: {
+  codePlaceholder: 'Enter your passcode here',
+  headerText: 'Manually enter the following code into your preferred authenticator app and then enter the provided one-time code below.',
+  copyCodeButton: 'Copy code'
+},
+
+smsEnrollmentAddPhoneNumber: {
+  headerText: 'Please enter your phone
    in order to enroll.',
+  phoneNumberLabel: 'A code will be sent to this number:',
+  phoneNumberPlaceholder: 'Your phone number'
+  // countryCodes: { 'US': 'Translation of United States', ... '': '' }
+},
+
+authCongrats: {
+  congrats: 'We have verified your identity. Redirecting...',
+  congratsNoRedirect: 'We have verified your identity.',
+  continueButtonText: 'Continue'
+},
+
+errorMessages: {
+  alreadyEnrolled: 'You are already enrolled, cannot enroll again',
+  authMethodDisabled: 'The specified authentication method is disabled',
+  connectionError: 'Looks like we cannot contact our server. Please check your internet connection and retry.',
+  default: 'Looks like something went wrong. Please retry.',
+  defaultRequest: 'Looks like we found a problem contacting our server. Please retry.',
+  enrollmentConflict: 'Seems that you have already enrolled. Try logging in again from the application.',
+  enrollmentMethodDisabled: 'The specified enrollment method is disabled',
+  enrollmentNotFound: 'We couldn\'t find your enrollment. You\'ve probably started enrollment from another device. Finish it there or try logging in again from the application.',
+  enrollmentTransactionNotFound: 'The mfa enrollment transaction is not active or has expired. Please try again.',
+  errorSendingPushNotification: 'We found an error sending your notification. Please try again.',
+  errorSendingPushNotificationManualFallback: 'We could not send the push. Please enter the code manually.',
+  errorSendingSms: 'We found an error sending your code. Please try again in a few seconds.',
+  errorSendingSmsManualFallback: 'We could not send the sms. Please try the recovery code.',
+  featureDisabled: 'This module is currently disabled.',
+  featureDisabledByAdmin: 'This module was disabled by the admin.',
+  fieldRequired: 'Please fill out required field.',
+  globalTransactionExpired: 'Your login attempt has timed out.',
+  guardianInvalidNonce: 'There was a problem authenticating your request origin. Have you started too many parallel logins?',
+  guardianInvalidToken: 'There was a problem validating authentication request format.',
+  insufficientScope: 'Seems that you are not authorized to perform this action.',
+  invalidBearerFormat: 'Seems that you are not authorized to perform this action.',
+  invalidLoginTokenStatus: 'Unexpected state validating your request.',
+  invalidOtp: 'Seems that your code is not valid, please check and retry.',
+  invalidOtpFormat: 'OTP Code must have 6 numeric characters',
+  invalidPhoneNumber: 'Seems that your phone number is not valid. Please check and retry.',
+  invalidRecoveryCode: 'Seems that your recovery code is not valid. Please check and try again.',
+  invalidRecoveryCodeFormat: 'Recovery code must have 24 alphanumeric characters',
+  invalidToken: 'Seems that you are not authorized to perform this action.',
+  loginRejected: 'Auth has been rejected. Try again.',
+  loginTokenInvalidSignature: 'We cannot verify who seems to be the issuer for this request',
+  loginTokenTransactionExpired: 'Your authentication request is expired. Is your connection slow?',
+  loginTransactionNotFound: 'Seems that your device has taken too long to login. Please try again.',
+  noMethodAvailable: 'There is currently no authentication method available.',
+  noPublicKeyAvailable: 'We cannot verify your identity. Contact tenant admin.',
+  pnEndpointDisabled: 'Seems that we cannot deliver messages to your cell phone. Please try again.',
+  pushNotificationNotConfigured: 'Seems that enrollment was not finished. Please try logging in again from the application.',
+  pushNotificationWrongCredentials: 'Seems that your device credentials are outdated. Please re-enroll your device or wait for them to be updated.',
+  smsNotConfigured: 'You cannot use this module because you\'ve enrolled with a different one.',
+  socketError: 'We cannot connect to real time channel.',
+  // tenant_not_found | The tenant associated cannot be found. Should not normally happen at least that you delete the tenant
+  tooManyPn: 'You have exceeded the amount of push notifications per minute. Please wait and try again.',
+  tooManyPnPerTenant: 'There are too many push requests right now. Wait a few minutes and try again.',
+  tooManySms: 'You have exceeded the amount of SMSs per hour. Wait a few minutes and try again.',
+  tooManySmsPerTenant: 'There are too many SMSs right now.  Wait a few minutes and try again.'
+  // | transaction_expired | The transaction has already expired |
+},
+
+successMessages: {
+  auth: 'We have successfully verified your identity. Redirecting...',
+  pushSent: 'We\'ve sent a push to: {enrollmentName}',
+  smsSent: 'We\'ve sent an sms to: {phoneNumber}'
+},
+
+infoMessages: {
+  iddle: 'Can we help you?

    Click here to learn more'
+}
+```
diff --git a/ja-jp/articles/mfa/references/mfa-widget-reference.md b/ja-jp/articles/mfa/references/mfa-widget-reference.md
new file mode 100644
index 0000000000..edcdd1dce7
--- /dev/null
+++ b/ja-jp/articles/mfa/references/mfa-widget-reference.md
@@ -0,0 +1,59 @@
+---
+description: Describes the MFA Widget theme options for customizing the theme properties of the MFA pages. 
+topics:
+  - mfa
+  - hosted-pages
+contentType: reference
+useCase: customize-hosted-pages
+---
+# MFA Widget Theme Options
+
+When using your own HTML, it uses the Auth0 MFA Widget, which has the following limitations:
+- It does not support MFA with Email.
+- If users enrolled more than one factor, they cannot select which one to use, the MFA widget will ask them to login with the most secure factor.
+- It does not use Universal Login's [internationalization](/universal-login/i18n) features
+
+There are a few theming options for the MFA Widget, namespaced under the `theme` property.
+
+## icon
+
+The value for `icon` is the URL for an image that will be used in the MFA Widget header, which defaults to the Auth0 logo. It has a recommended max height of `58px` for a better user experience.
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  theme: {
+    icon: 'https://example.com/assets/logo.png'
+  },
+  
+...
+
+})
+```
+
+## primaryColor
+
+The `primaryColor` property defines the primary color of the MFA Widget. This option is useful when providing a custom `icon`, to ensure all colors go well together with the `icon`'s color palette. Defaults to `#ea5323`.
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  theme: {
+    icon: 'https://example.com/assets/logo.png',
+    primaryColor: 'blue'
+  },
+  
+...  
+  
+})
+```
+
+## Keep reading
+
+* [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js)
+* [Widget Example Using auth0-guardian.js](https://github.com/auth0/auth0-guardian.js/tree/master/example)
+* [Multi-factor Authentication with Classic Universal Login](/universal-login/multifactor-authentication)
diff --git a/ja-jp/articles/mfa/references/troubleshoot-mfa.md b/ja-jp/articles/mfa/references/troubleshoot-mfa.md
new file mode 100644
index 0000000000..be1bb19a8e
--- /dev/null
+++ b/ja-jp/articles/mfa/references/troubleshoot-mfa.md
@@ -0,0 +1,63 @@
+---
+description: Describes basic troubleshooting of MFA issues for end-users.
+topics:
+    - mfa
+contentType:
+  - reference
+useCase:
+  - customize-mfa
+---
+# Troubleshoot Multi-Factor Authentication
+
+This guide serves as a troubleshooting reference if you have end-users unable to log in with multi-factor authentication (MFA).
+
+## Generic issues
+
+### If you do not have your mobile device, or your mobile device is turned off
+
+If you have lost your device, you can finish authentication using the recovery code provided when you first signed up. 
+
+1. Enter your email and password to log in, and click the **Use the recovery code** link.
+2. Enter your recovery code.
+
+If you no longer have your recovery code, you will not be able to log in. Contact your system administrator for help accessing your account.
+
+### If you forget your password
+
+If you have forgotten your password, click the **Don't remember your password?** link located underneath the email and password fields. Then, enter your email address to receive an email containing a link you can use to reset your password.
+
+### If your transaction expires
+
+When logging in via MFA, there is a five-minute maximum between providing your first and second factors. You can see how much time has elapsed since you logged in using the first factor by checking the timestamp on the messages provided.
+
+If more than five minutes has elapsed, you will need to log in again and obtain a new code or notification.
+
+If you are requesting SMS or Voice messages, make sure you are not [exceeding rate limits](#sms-rate-limits).
+
+### If you need to remove or delete MFA from a user in your tenant
+
+If you need to remove, delete, or reset MFA for a user, you should [reset MFA](/mfa/guides/reset-user-mfa).
+
+## Phone messaging-related issues
+
+### SMS message rate limits
+
+If a user attempts to send more than ten SMS or Voice messages within one hour, they will see an error message saying so.
+
+When they exceed your messaging limit, they'll need to wait at least an hour after they sent the first message before sending another. They will receive an additional attempt after the passage of each additional hour.
+
+## Rejected Codes
+
+If the 6-digit code in the Guardian or the Google Authenticator app are being rejected for sign in (often with the message `Incorrect Code`), first check that you are selecting the right application from the list in your authenticator app. If you've verified that you're selecting the correct application, make sure that your mobile device's clock settings are correct. One-time passwords are generated using Coordinated Universal Time (UTC), so your device's time must be correct for your code to work.
+
+To check your clock settings:
+
+* **Android Devices** - Go **Settings** > **Date & Time**. Make sure that the box next to **Automatic** is checked.
+
+* **iOS Devices** - Go to  **Settings** > **General** > **Date & Time**. Enable **Set Automatically**. If this setting was already enabled, you can disable it for a moment, then re-enable.
+
+## Duo-related issues
+
+For questions or issues specifically regarding Duo, [see Duo's documentation](https://guide.duo.com).
+
+Android, then tap "Settings." Scroll down to the bottom of the Settings menu, then tap "Date & Time." Tap the box next to "Automatic" to un-check it.
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-amazon-sns.md b/ja-jp/articles/mfa/send-phone-message-hook-amazon-sns.md
new file mode 100644
index 0000000000..e5ad994552
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-amazon-sns.md
@@ -0,0 +1,152 @@
+---
+title: Configure a Custom SMS Provider for MFA using Amazon SNS
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Amazon SNS.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Amazon SNS
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using the Amazon Simple Notification Service (SNS).
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Amazon SNS?
+
+Amazon Simple Notification Service (SNS) is a pub/sub messaging service that enables Auth0 to deliver multi-factor verification via text messages. To learn more, see [Amazon's SNS Overview](https://aws.amazon.com/sns).
+
+## Prerequisites
+
+Before you begin this tutorial, please:
+
+* Sign up for an [Amazon Web Services](https://portal.aws.amazon.com/billing/signup#/start).
+* Capture your Amazon Web Service region.
+* Create a new Amazon IAM User with the `AmazonSNSFullAccess` role.
+* Capture the user's access key and secret key details.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Amazon SNS, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the AWS SNS call](#add-the-aws-sns-call)
+4. [Add the AWS SDK NPM package](#add-the-aws-sdk-npm-package)
+5. [Test your Hook implementation](#test-your-hook-implementation)
+6. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+7. [Test the MFA flow](#test-the-mfa-flow)
+
+Optional: [Troubleshoot](#troubleshoot)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook secrets
+
+Add three [Hook Secrets](/hooks/secrets/create) with keys `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_REGION`, with the corresponding values from your Amazon account.
+
+### Add the AWS SNS call
+
+To make the call to AWS SNS, add the appropriate code to the Hook.
+
+Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling AWS SNS to send a verification code via SMS.
+
+```js
+// Load the SDK
+var AWS = require("aws-sdk");
+
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one-time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function(recipient, text, context, cb) {
+  process.env.AWS_ACCESS_KEY_ID = context.webtask.secrets.AWS_ACCESS_KEY_ID;
+  process.env.AWS_SECRET_ACCESS_KEY = context.webtask.secrets.AWS_SECRET_ACCESS_KEY;
+  process.env.AWS_REGION = context.webtask.secrets.AWS_REGION;
+
+  var params = { Message: text, PhoneNumber: recipient };
+
+  var publishTextPromise = new AWS.SNS({ apiVersion: "2010-03-31" })
+    .publish(params)
+    .promise();
+
+  publishTextPromise
+    .then(function() {
+      cb(null, {});
+    })
+    .catch(function(err) {
+      cb(err);
+    });
+};
+```
+
+### Add the AWS SDK NPM package
+
+The Hook uses the [AWS SDK for JavaScript in Node.js](https://aws.amazon.com/sdk-for-node-js/), so you'll need to include this package in your Hook.
+
+1. Click the **Settings** icon again, and select **NPM Modules**. 
+
+2. Search for `aws-sdk` and add the module that appears.
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes via the Vonage SMS API. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and ensure that:
+
+- The Hook is active and the SMS configuration is set to use `Custom`.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones you created in the Amazon Web Services portal.
+- Your Amazon Web Services user has access to the `AmazonSNSFullAccess` role.
+- Your Amazon Web Services account is active (not suspended).
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-esendex.md b/ja-jp/articles/mfa/send-phone-message-hook-esendex.md
new file mode 100644
index 0000000000..8292c86b70
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-esendex.md
@@ -0,0 +1,150 @@
+---
+title: Configure a Custom SMS Provider for MFA using Esendex
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Esendex.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Esendex
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using Esendex and the Send Phone Message Hook.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Esendex?
+
+Esendex provides an SMS messaging service that can be used by Auth0 to deliver multi-factor verification via text messages. 
+
+## Prequisites
+
+Before you begin this tutorial, please:
+
+- [Sign up with Esendex](https://www.esendex.co.uk/#freetrialformblock) and complete your profile and confirmation steps. Once this is complete, you should be able to access the SMS API. Here, you can try out the API with a test number.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Esendex, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the Esendex call](#add-the-esendex-call)
+4. [Test your Hook implementation](#test-your-hook-implementation)
+5. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+6. [Test the MFA flow](#test-the-mfa-flow)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook Secrets
+
+You're going to store the values needed from Esendex in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+[Add Hook Secrets](/hooks/secrets/create) with the following settings:
+
+* `ESENDEX_ACCOUNT` - Esendex Account (from the [Esendex Dashboard](https://admin.esendex.com/accounts))
+* `ESENDEX_USERNAME` - Esendex Username
+* `ESENDEX_PASSWORD` - Esendex Password
+
+### Add the Esendex call
+
+To make the call to Esendex, add the appropriate code to the Hook.
+
+Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Esendex to send a verification code via SMS. You can learn more about the Esendex API in [Esendex's API documentation](https://developers.esendex.com/api-reference#smsapis).
+
+```js
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function(recipient, text, context, cb) {
+   const axios = require('axios').default;
+
+   const instance = axios.create({
+    baseURL: "https://api.esendex.com/",
+    headers: {
+        "Content-Type": "application/json",
+        "Accept-Encoding": "gzip, deflate, br",
+        "Accept": "application/json"
+    },
+  });
+  instance({
+    method: 'post',
+    auth: {
+      username: context.webtask.secrets.ESENDEX_USERNAME,
+      password: context.webtask.secrets.ESENDEX_PASSWORD
+    },
+    url: '/v1.0/messagedispatcher',
+    data: JSON.stringify({
+        accountreference: context.webtask.secrets.ESENDEX_ACCOUNT,
+        messages: [{ to: recipient, body: text }]
+    })
+  })
+  .then((response) => {
+    cb(null, {});
+  })
+  .catch((error) => {
+    cb(error);
+  });
+};
+```
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and make sure that:
+
+- The Hook is active and the SMS configuration is set to use 'Custom'.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones you got from Esendex.
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-infobip.md b/ja-jp/articles/mfa/send-phone-message-hook-infobip.md
new file mode 100644
index 0000000000..7922543369
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-infobip.md
@@ -0,0 +1,156 @@
+---
+title: Configure a Custom SMS Provider for MFA using Infobip
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Infobip.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Infobip
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using Infohip.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Infobip?
+
+Infobip SMS is a messaging platform that enables Auth0 to deliver multi-factor verification via text messages. To learn more, see [Infobip's SMS Overview](https://www.infobip.com/products/sms).
+
+## Prerequisites
+
+Before you begin this tutorial, please:
+
+* Log in to the [Infobip Portal](https://portal.infobip.com/) or [sign up for a free trial](https://www.infobip.com/signup).
+* Create and capture a new API Key on the [Infobip API Keys](https://portal.infobip.com/.settings/accounts/api-keys) page.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Infobip, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the Infobip call](#add-the-infobip-call)
+4. [Test your Hook implementation](#test-your-hook-implementation)
+5. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+6. [Test the MFA flow](#test-the-mfa-flow)
+
+Optional: [Troubleshoot](#troubleshoot)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook Secrets
+
+You're going to store the value needed from the Infobip portal in a [Hook Secret](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+[Add a Hook Secret](/hooks/secrets/create) with the following settings. You can find the value for the secret on the [Infobip API Keys](https://portal.infobip.com/.settings/accounts/api-keys) page.
+
+* `INFOBIP_API_KEY` - Infobip API key
+
+### Add the Infobip call
+
+To make the call to Infobip, add the appropriate code to the Hook.
+
+Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Infobip to send a verification code via SMS.
+
+```js
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function(recipient, text, context, cb) {
+
+    const axios = require('axios').default;
+    const API_KEY = context.webtask.secrets.API_KEY;;
+    const BASE_URL = 'https://2622w.api.infobip.com';
+    const instance = axios.create({
+        baseURL: BASE_URL,
+        headers: {
+            'Authorization': 'App ' + API_KEY,
+            'Accept': 'application/json',
+            'Content-Type': 'application/json'
+        },
+    });
+    instance({
+        method: 'post',
+        url: '/sms/2/text/advanced',
+        data: {
+            "messages": [
+                {
+                    "destinations": [
+                        { "to": recipient }
+                    ],
+                    "text": text
+                }
+            ]
+        }
+    })
+    .then((response) => {
+        cb(null, {});
+    })
+    .catch((error) => {
+        cb(error);
+    });
+
+};
+```
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes via Infobip. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and make sure that:
+
+- The Hook is active and the SMS configuration is set to use 'Custom'.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones you created in the Infobip portal.
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-mitto.md b/ja-jp/articles/mfa/send-phone-message-hook-mitto.md
new file mode 100644
index 0000000000..3398326f20
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-mitto.md
@@ -0,0 +1,142 @@
+---
+title: Configure a Custom SMS Provider for MFA using Mitto
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Mitto.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Mitto
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using Mitto and the Send Phone Message Hook.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Mitto?
+
+Mitto provides an SMS messaging service that can be used by Auth0 to deliver multi-factor verification via text messages. 
+
+## Prequisites
+
+Before you begin this tutorial, please [create an account with Mitto](https://info.mitto.ch/mitto-auth0). You will get an API Key and a Sender ID that you can then use to invoke Mitto's APIs.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Mitto, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the Mitto call](#add-the-mitto-call)
+4. [Test your Hook implementation](#test-your-hook-implementation)
+5. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+6. [Test the MFA flow](#test-the-mfa-flow)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook Secrets
+
+You're going to store the values needed from Mitto in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+[Add Hook Secrets](/hooks/secrets/create) with the following settings:
+
+* `MITTO_API_KEY` - The API Key provided by Mitto
+
+### Add the Mitto call
+
+To make the call to Mitto, add the appropriate code to the Hook.
+
+Copy the code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Mitto to send a verification code via SMS. You can learn more about the Mitto API in [Mitto's API documentation](https://info.mitto.ch/hubfs/Developer%20Guides/Mitto%20SMS%20API%202.0%20Developer%20Guide%20v2.5.pdf).
+
+```js
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function(recipient, text, context, cb) {
+   const axios = require('axios').default;
+
+   const instance = axios.create({
+      baseURL: "https://rest.mittoapi.com/",    
+      headers: {
+      "Content-Type": "application/json",
+      "X-Mitto-API-Key": context.webtask.secrets.MITTO_API_KEY
+    },
+  });
+  instance({
+    method: 'post',
+    url: '/sms.json',
+    data: JSON.stringify({
+        to: recipient,
+        from: "Mitto SMS", // The Mitto Sender ID
+        text: text
+    })
+  })
+  .then((response) => {
+    cb(null, {});
+  })
+  .catch((error) => {
+    cb(error);
+  });
+};
+```
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and make sure that:
+
+- The Hook is active and the SMS configuration is set to use 'Custom'.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones you got from Mitto.
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-telesign.md b/ja-jp/articles/mfa/send-phone-message-hook-telesign.md
new file mode 100644
index 0000000000..1d13504eaa
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-telesign.md
@@ -0,0 +1,207 @@
+---
+title: Configure a Custom SMS Provider for MFA using TeleSign
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using TeleSign.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using TeleSign
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using Telesign.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Telesign?
+
+Telesign provides two different APIs, both of which may be used alongside Auth0 to deliver multi-factor verification via text messages:
+
+* [TeleSign SMS](https://www.telesign.com/products/sms-api): Allows you to build and manage SMS communications and security verification processes.
+* [TeleSign SMS Verify](https://www.telesign.com/products/sms-verify): Helps you manage the SMS verification process and is available in the Enterprise plan.
+
+## Prerequisites
+
+Before you begin this tutorial, please:
+
+* Log in to your TeleSign portal (either the [TeleSign Enterprise Portal](https://teleportal.telesign.com) or the [TeleSign Standard Portal](https://portal.telesign.com/)).
+* Capture the Customer ID and API Keys from your TeleSign account.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Telesign, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the Telesign call](#add-the-telesign-call)
+4. [Test your Hook implementation](#test-your-hook-implementation)
+5. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+6. [Test the MFA flow](#test-the-mfa-flow)
+
+Optional: [Troubleshoot](#troubleshoot)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook Secrets
+
+You're going to store the values needed from the Telesign portal in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+[Add Hook Secrets](/hooks/secrets/create) with the following settings. You can find the values for the secrets in your Telesign portal.
+
+* `TELESIGN_CUSTOMER_ID`: Telesign Customer ID
+* `TELESIGN_API_KEY`: Telesign API Key
+
+### Add the Telesign call
+
+To make the call to Telesign, add the appropriate code to the Hook.
+
+Copy the appropriate code block below and [edit](/hooks/update) the Send Phone Message Hook code to include it. This function will run each time a user requires MFA, calling Telesign to send a verification code via SMS.
+
+#### SMS API
+
+If you are calling the SMS API, use the following code:
+
+```js
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function (recipient, text, context, cb) {
+
+  const axios = require('axios').default;
+  const querystring = require('querystring');
+
+  const customerId = context.webtask.secrets.TELESIGN_CUSTOMER_ID;
+  const restApiKey = context.webtask.secrets.TELESIGN_REST_API_KEY;
+
+  const instance = axios.create({
+    // If you are using the standard TeleSign plan the URL should be https://rest-api.telesign.com/
+    baseURL: "https://rest-ww.telesign.com",
+    headers: {
+      'Content-Type': 'application/x-www-form-urlencoded'
+    },
+  });
+
+  instance({
+    method: 'post',
+    auth: {
+      username: customerId,
+      password: restApiKey
+    },
+    url: '/v1/messaging',
+    data: querystring.stringify({
+      phone_number: recipient,
+      message_type: 'ARN',
+      message: text
+    })
+  })
+  .then((response) => {
+    cb(null, {});
+
+  })
+  .catch((error) => {
+    cb(error);
+  });
+}
+```
+
+#### SMS Verify API
+
+If you are calling the SMS Verify API, use the following code:
+
+```js
+module.exports = function(recipient, text, context, cb) {
+
+  const axios = require('axios').default;
+  const querystring = require('querystring');
+
+  const customerId =  context.webtask.secrets.TELESIGN_CUSTOMER_ID;
+  const restApiKey = context.webtask.secrets.TELESIGN_API_KEY;
+
+  const instance = axios.create({
+    baseURL: "https://rest-ww.telesign.com",
+    headers: {
+      'Content-Type': 'application/x-www-form-urlencoded'
+    },
+  });
+
+  instance({
+    method: 'post',
+    auth: {
+      username: customerId,
+      password: restApiKey
+    },
+    url: '/v1/verify/sms',
+    data: querystring.stringify({
+      phone_number: recipient,
+      template: text
+    })
+  })
+  .then((response) => {
+      cb(null, {});
+  })
+  .catch((error) => {
+      cb(error);
+  });
+}
+```
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes via the Telesign. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and make sure that:
+
+- The Hook is active and the SMS configuration is set to use 'Custom'.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones provided in the TeleSign portal.
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-twilio.md b/ja-jp/articles/mfa/send-phone-message-hook-twilio.md
new file mode 100644
index 0000000000..6abffb4b49
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-twilio.md
@@ -0,0 +1,211 @@
+---
+title: Configure a Custom SMS Provider for MFA using Twilio
+description: Learn how to configure a Custom SMS Provider for multifactor authentication (MFA) using Twilio.
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Twilio
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using Twilio and the Send Phone Message Hook.
+
+Auth0 has built-in support for sending messages through Twilio. However, you may want to add specific logic before sending a message or want to send a different message depending on the user or the application. In this case, you would configure SMS MFA to use a Send Phone Message Hook.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Twilio?
+
+Twilio provides an SMS messaging service which can be used by Auth0 to deliver multi-factor verification via text messages. It provides two different APIs:
+
+  - [Programmable SMS](https://www.twilio.com/sms) is a flexible API designed to fully automate SMS communications.
+  - [Verify](https://www.twilio.com/verify) is an API designed to send one-time codes while hiding the complexity of SMS delivery.
+
+## Prerequisites
+
+Before you begin this tutorial, please:
+
+* Sign up for a [Twilio](https://www.twilio.com/try-twilio) account.
+* Create a new Messaging Service in the [Programmable SMS console](https://www.twilio.com/console/sms/services) or in the [Verify console](https://www.twilio.com/console/verify/services) depending on the API you want to use.
+* If you use Programmable SMS, you need to add a phone number that is enabled for SMS to your service and capture the number.
+*  If use the Verify API, you need to make sure that the Twilio Verify Service is configured to accept a custom code. At the time of writing, you need to contact Twilio support to get it enabled. 
+* Capture the Account SID and Authorization Token by clicking *Show API Credentials* in the [Twilio SMS Dashboard](https://www.twilio.com/console/sms/dashboard)
+
+## Steps
+
+To configure a custom SMS provider for MFA using Twilio, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Add the Twilio call](#add-the-twilio-call)
+4. [Add the Twilio Node JS Helper NPM package](#add-the-twilio-node-js-helper-npm-package)
+5. [Test your Hook implementation](#test-your-hook-implementation)
+6. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+7. [Test the MFA flow](#test-the-mfa-flow)
+
+### Create a Send Phone Message Hook
+
+You will need to create a [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook, which will hold the code and secrets of your custom implementation.
+
+::: note
+You can only have **one** Send Phone Message Hook active at a time.
+:::
+
+### Configure Hook Secrets
+
+You're going to store the values needed from the Twilio SMS Dashboard in [Hook Secrets](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+[Add Hook Secrets](/hooks/secrets/create) with the following settings. You can find the values for the secrets in your [Twilio SMS Dashboard](https://www.twilio.com/console/sms/dashboard).
+
+* `TWILIO_ACCOUNT_SID`: Twilio Account SID
+* `TWILIO_AUTH_TOKEN`: Twilio Authorization token
+* `TWILIO_PHONE_NUMBER`: Twilio "from" sending number
+
+### Add the Twilio call
+
+To make the call to Twilio, add the appropriate code to the Hook.
+
+[Edit](/hooks/update) the Send Phone Message Hook code and copy of the code snippets below, depending on the API you want to use. This function will run each time a user requires MFA, calling Twilio to send a verification code via SMS.
+
+To use the Programmable SMS API, use the code below.
+
+```js
+/**
+@param {string} recipient - phone number
+@param {string} text - message body
+@param {object} context - additional authorization context
+@param {string} context.factor_type - 'first' or 'second'
+@param {string} context.message_type - 'sms' or 'voice'
+@param {string} context.action - 'enrollment' or 'authentication'
+@param {string} context.language - language used by login flow
+@param {string} context.code - one time password
+@param {string} context.ip - ip address
+@param {string} context.user_agent - user agent making the authentication request
+@param {string} context.client_id - to send different messages depending on the client id
+@param {string} context.name - to include it in the SMS message
+@param {object} context.client_metadata - metadata from client
+@param {object} context.user - To customize messages for the user
+@param {function} cb - function (error, response)
+*/
+module.exports = function(recipient, text, context, cb) {
+
+  const accountSid = context.webtask.secrets.TWILIO_ACCOUNT_SID;
+  const authToken = context.webtask.secrets.TWILIO_AUTH_TOKEN;
+  const fromPhoneNumber = context.webtask.secrets.TWILIO_PHONE_NUMBER;
+
+  const client = require('twilio')(accountSid, authToken); 
+ 
+  if (context.message_type === "sms") {
+    client.messages 
+        .create({ 
+          body: text, 
+          from: fromPhoneNumber,       
+          to: recipient
+        })
+        .then(function() {
+          cb(null, {});
+        })
+        .catch(function(err) {
+          cb(err);
+        });
+  }
+  else {
+    const sayInCall = `
+    
+        Hello, your code is {{code}}.
+    `
+    client.calls
+        .create({
+          twiml: sayInCall,
+          to: recipient,
+          from: fromPhoneNumber,
+          timeout: 30,
+        })
+        .then(function() { 
+          cb(null, {})
+        )
+        .catch(function(err) {
+          cb(err)
+        }
+    };
+  }
+};
+```
+
+To use the Verify API, use the code below.
+
+```js
+module.exports = function(recipient, text, context, cb) {
+
+  const accountSid = context.webtask.secrets.TWILIO_ACCOUNT_SID; 
+  const authToken = context.webtask.secrets.TWILIO_AUTH_TOKEN; 
+  const fromPhoneNumber = context.webtask.secrets.TWILIO_PHONE_NUMBER;
+
+  const client = require('twilio')(accountSid, authToken); 
+ 
+  client.verify.services(accountSid)
+      .verifications
+      .create({
+        to: recipient,
+        channel: 'sms',
+        customCode: context.code
+      })
+      .then(function() {
+        cb(null, {});
+      }) 
+      .catch(function(err) {
+        cb(err);
+      });
+};
+```
+
+### Add the Twilio Node JS Helper NPM package
+
+The Hook uses the [Twilio Node.JS Helper Library](https://github.com/twilio/twilio-node), so you'll need to include this package in your Hook.
+
+1. Click the **Settings** icon again, and select **NPM Modules**. 
+
+2. Search for `twilio-node` and add the module that appears.
+
+### Test your Hook implementation
+
+Click the **Run** icon on the top right to test the Hook. Edit the parameters to specify the phone number to receive the SMS, and click the **Run** button.
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes via Twilio. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+### Test the MFA flow
+
+Trigger an MFA flow and double check that everything works as intended. If you do not receive the SMS, please take a look at the [Hook Logs](/hooks/view-logs).
+
+## Troubleshoot
+
+If you do not receive the SMS, please look at the logs for clues and make sure that:
+
+- The Hook is active and the SMS configuration is set to use 'Custom'.
+- You have configured the Hook Secrets as per Step 2.
+- The configured Hook Secrets are the same ones you created in the Twilio SMS Dashboard.
+- Your are sending the messages from a phone number that is linked to your Twilio account.
+- Your phone number is formatted using the [E.164 format](https://en.wikipedia.org/wiki/E.164).
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Vonage](/mfa/send-phone-message-hook-vonage)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/mfa/send-phone-message-hook-vonage.md b/ja-jp/articles/mfa/send-phone-message-hook-vonage.md
new file mode 100644
index 0000000000..98a46e1a78
--- /dev/null
+++ b/ja-jp/articles/mfa/send-phone-message-hook-vonage.md
@@ -0,0 +1,172 @@
+---
+description: Configure a Custom SMS Provider for MFA using Vonage
+topics:
+  - mfa
+  - sms
+  - custom-sms-provider
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure a Custom SMS Provider for MFA using Vonage
+
+This guide explains how to send Multi-factor Authentication (MFA) text messages using the Vonage (previously Nexmo) SMS API.
+
+<%= include('./_includes/_test-setup') %>
+
+## What is Vonage?
+
+Vonage provides an SMS API which can be used by Auth0 to deliver multi-factor verification via text messages. To learn more, see [Vonage's SMS API Overview](https://www.vonage.com/communications-apis/sms/).
+
+## Get Started with Vonage
+
+First, [sign up with Vonage](https://dashboard.nexmo.com/sign-up) and complete your profile and confirmation steps. Once done, you should be able to access the [SMS API screen of the Vonage dashboard](https://dashboard.nexmo.com/getting-started/sms). Here, you can try out the API with a test number.
+
+![Vonage Dashboard Test SMS API](/media/articles/mfa/01-guide-vonage-dashboard-sms-api-test.png)
+
+Once you've successfully tested the SMS API and can receive a text message, you're ready to integrate with Auth0.
+
+## Steps
+
+To configure a custom SMS provider for MFA using Vonage, you will:
+
+1. [Create a Send Phone Message Hook](#create-a-send-phone-message-hook)
+2. [Configure Hook Secrets](#configure-hook-secrets)
+3. [Include the nexmo module](#include-the-nexmo-module)
+4. [Add the Vonage API Call](#add-the-vonage-api-call)
+5. [Test your Hook implementation](#test-your-hook-implementation)
+6. [Activate the custom SMS factor](#activate-the-custom-sms-factor)
+7. [Test the MFA flow](#test-the-mfa-flow)
+
+Optional: [Troubleshoot](#troubleshoot)
+
+### Create a Send Phone Message Hook
+
+You're going to use a Hook in the Auth0 dashboard to send the text message when MFA is required. To do that, you need the API information for your Vonage account and a simple Node function to send the message.
+
+1. Navigate to the [Hooks screen](${manage_url}/#/hooks) in the Auth0 Dashboard, scroll down to **Send Phone Message**, and click **Create New Hook**.
+
+![Auth0 Dashboard: Add New Hook](/media/articles/mfa/02-guide-auth0-add-new-hook.png)
+
+2. Give the Hook a name, click **Create**, then click the **Edit Hook** button to configure secrets and add the Vonage API call.
+
+![Auth0 dashboard edit SMS hook](/media/articles/mfa/03-guide-auth0-edit-new-sms-hook.png)
+
+### Configure Hook Secrets
+
+You're going to store each of the values needed from the Vonage dashboard in a [Hook Secret](/hooks/secrets). This way, the values are secure and can be used easily in your function.
+
+Click the **Settings** icon (wrench) on the top left and select **Secrets**, then click **Add Secret**, and add the following secrets. You can find the values for all three of these secrets in the [Getting Started Guide](https://dashboard.nexmo.com/getting-started-guide) in the Vonage dashboard.
+
+* `VONAGE_API_KEY`: Vonage API key
+* `VONAGE_API_SECRET`: Vonage API secret
+* `VONAGE_FROM_NUMBER`: Vonage "from" sending number
+
+![Auth0 Dashboard: Add Hook Secret](/media/articles/mfa/04-guide-auth0-add-hook-secrets.png)
+
+### Include the nexmo module
+
+The Hook uses the [Nexmo Client Library for Node.js](https://aws.amazon.com/sdk-for-node-js/), so you'll need to include this package in your Hook.
+
+Next, you'll need to include the `nexmo` module in your hook.
+
+1. Click the **Settings** icon again, and select **NPM Modules**. 
+
+2. Search for `nexmo` and add the module that appears.
+
+![Auth0 Dashboard: Add Hook Module](/media/articles/mfa/05-guide-auth0-add-nexmo-module.png)
+
+## Add the Vonage API call
+
+To make the call to the Vonage API, add the appropriate code to the Hook.
+
+Copy the code block below and paste it into the Hooks code editor. This function will run each time a user requires MFA, calling the Vonage API to send a verification code via SMS.
+
+```js
+module.exports = function(toNumber, text, context, cb) {
+  const Nexmo = require('nexmo');
+  const nexmo = new Nexmo({
+    apiKey: context.webtask.secrets.VONAGE_API_KEY,
+    apiSecret: context.webtask.secrets.VONAGE_API_SECRET,
+  });
+
+  const fromNumber = context.webtask.secrets.VONAGE_FROM_NUMBER;
+  toNumber = toNumber.replace(/\D/g, '');
+
+  nexmo.message.sendSms(fromNumber, toNumber, text, (err, responseData) => {
+    if (err) {
+      return cb(err);
+    }
+
+    const firstMsg = responseData.messages[0];
+    if (firstMsg['status'] !== '0') {
+      return cb(new Error('Message failed: ' + firstMsg['error-text']));
+    }
+
+    return cb(null, {});
+  });
+};
+```
+
+### Test your Hook implementation
+
+Click the **Runner** button to try the completed Hook. Make sure to change the `recipient` value in the body to your test number from the Vonage API.
+
+You should receive a test text message, and the webtask should complete successfully.
+
+![Auth0 Dashboard: Run SMS Hook](/media/articles/mfa/06-guide-auth0-run-sms-hook.png)
+
+### Activate the custom SMS factor
+
+The Hook is now ready to send MFA codes via the Vonage SMS API. The last steps are to configure the SMS Factor to use the custom code and test the MFA flow.
+
+1. Navigate to the [Multifactor Auth](${manage_url}/#/mfa) page in the [Auth0 Dashboard](${manage_url}/), and click the **SMS** factor box.
+
+2. In the modal that appears, select **Custom** for the **SMS Delivery Provider**, then make any adjustments you'd like to the templates. Click **Save** when complete, and close the modal.
+
+3. Enable the SMS factor using the toggle switch.
+
+![Auth0 Dashboard: Activate SMS Factor](/media/articles/mfa/07-guide-auth0-activate-sms-factor.png)
+
+::: note
+To use the SMS factor, your tenant needs to have MFA enabled globally or required for specific contexts using Rules. To learn how to enable the MFA feature itself, see the following docs:
+
+- [Enable Multi-Factor Authentication](/mfa/guides/enable-mfa)
+- [Customize Multi-Factor Authentication](/mfa/guides/customize-mfa-universal-login)
+:::
+
+### Test the MFA flow
+
+You can now test your authentication flow to see the Vonage API in action.
+
+![Test MFA SMS verification](/media/articles/mfa/08-guide-test-sms-verification.png)
+
+## Troubleshoot
+
+If something was misconfigured in Vonage, the Hook, or the SMS Factor, you may see an error message on the login form when trying this factor out for the first time.
+
+![Auth0 Universal Login MFA SMS Error](/media/articles/mfa/09-guide-login-sms-error-message.png)
+
+The best place to start debugging this issue is the [Logs screen](${manage_url}/#/logs) in the Auth0 dashboard. Look for a failed SMS log entry:
+
+![Auth0 Logs: Error Sending MFA SMS](/media/articles/mfa/10-guide-auth0-log-sms-error.png)
+
+To learn which event types to search, see our [Log Event Type Code list](/logs/references/log-event-type-codes). Otherwise, use the **Filter** control to find `MFA` errors.
+
+Once you find a log entry of interest, scroll down in the **Raw** tab to see an error message explaining what went wrong:
+
+![Auth0 Logs: Error Sending MFA SMS Details](/media/articles/mfa/11-guide-auth0-log-sms-error-details.png)
+
+If this does not solve your issue, the next step would be to check the [Vonage SMS API logs](https://dashboard.nexmo.com/sms) for a sent message and check its status. If there is no record of the message with Vonage, then the API call likely failed and the problem is in the Hook code.
+
+## Additional providers
+
+::: next-steps
+* [Configure a Custom SMS Provider for MFA using Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Configure a Custom SMS Provider for MFA using Twilio](/mfa/send-phone-message-hook-twilio)
+* [Configure a Custom SMS Provider for MFA using Infobip](/mfa/send-phone-message-hook-infobip)
+* [Configure a Custom SMS Provider for MFA using TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Configure a Custom SMS Provider for MFA using Esendex](/mfa/send-phone-message-hook-esendex)
+* [Configure a Custom SMS Provider for MFA using Mitto](/mfa/send-phone-message-hook-mitto)
+:::
diff --git a/ja-jp/articles/microsites/add-login/add-login-native-mobile-app.md b/ja-jp/articles/microsites/add-login/add-login-native-mobile-app.md
new file mode 100644
index 0000000000..13eb995054
--- /dev/null
+++ b/ja-jp/articles/microsites/add-login/add-login-native-mobile-app.md
@@ -0,0 +1,83 @@
+---
+title: Add Login to Your Native/Mobile App
+description: Everything you need to know to implement login for a native/mobile app
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/native
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - mobile-apps
+  - desktop-apps
+  - native-apps
+useCase:
+  - add-login
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application.
+
+## How it works
+
+In a native/mobile application, the default experience will open a SafariViewController in iOS or a Custom Chrome Tab in Android. 
+
+1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server.
+2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests the user's ID Token.
+4. Auth0 responds with the user's ID Token.
+
+For security in native/mobile devices, Auth0 uses the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
+
+Flow Overview for Native/Mobile Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure the sign-in methods
    Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

    Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled.
+
+  2. 
    Customize the sign-in UI (optional)
    The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

    Default Login Screen for Native/Mobile Apps
+
+  3. 
    Use the Auth0 SDK to trigger the flow
    The SDK will take care of the details of opening the SafariViewController or Chrome Custom Tab, parsing the response back from Auth0, and validating the ID Token.

    Your app can store the Access Token and a Refresh Token used to renew the Access Token without asking the user to re-enter their credentials. Follow one of our Native/Mobile Quickstarts to get started with the integration.
+
+:::
+
+## Alternative: Use Embedded Login
+
+While we strongly recommend that you use our hosted universal login page, if you prefer to embed your own login pages within your native/mobile app, you can implement our login widget (Lock UI) directly into your app with our:
+
+* [iOS Lock UI Component library](/libraries/lock-ios/v2)
+* [Android Lock UI Component library](/libraries/lock-android/v2)
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Mobile/Native App Quickstarts](/quickstart/native)
+  * [Add login using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce)
+  * [Add Facebook Login to Native Apps](/connections/nativesocial/facebook)
+  * [Add Sign In with Apple to Native iOS Apps](/connections/nativesocial/apple)
+  * [Embedded Passwordless Login in Native Applications](/connections/passwordless/embedded-login-native)
+  * [Customize the universal login page](/universal-login)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Identity Providers supported by Auth0](/connections)
+:::
+
+::: concepts  
+  * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded)
+  * [ID Tokens](/tokens/concepts/id-tokens)
+  * [Access Tokens](/tokens/access-token)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * Most native/mobile apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Native/Mobile App](/microsites/call-api/call-api-native-mobile-app).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+:::
+
diff --git a/ja-jp/articles/microsites/add-login/add-login-regular-web-app.md b/ja-jp/articles/microsites/add-login/add-login-regular-web-app.md
new file mode 100644
index 0000000000..fcab4a04bb
--- /dev/null
+++ b/ja-jp/articles/microsites/add-login/add-login-regular-web-app.md
@@ -0,0 +1,72 @@
+---
+title: Add Login to Your Regular Web App
+description: Everything you need to know to implement login for a regular web app
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/webapp
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - regular-web-apps
+  - server-side
+useCase:
+  - add-login
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application.
+
+## How it works
+
+In a regular web application: 
+
+1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server.
+3. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests the user's ID Token.
+4. Auth0 responds with the user's ID Token.
+
+For security in server-side web apps, Auth0 uses the [Authorization Code Flow](/flows/concepts/auth-code).
+
+Flow Overview for Regular Web Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure the sign-in methods
    Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

    Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled.
+
+  2. 
    Customize the sign-in UI (optional)
    The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

    Default Login Screen for Native/Mobile Apps
+
+  3. 
    Use an SDK for your chosen platform to trigger the flow
    An open-source OpenID Connect (OIDC) SDK for your chosen platform can redirect to the Auth0 Universal Login page and handle the response, validating the ID Token.

    Your app can store the ID Token. Follow one of our Regular Web App Quickstarts to get started with the integration.
+:::
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Regular Web App Quickstarts](/quickstart/webapp)
+  * [Add login using the Authorization Code Flow](/flows/guides/auth-code/add-login-auth-code)
+  * [Customize the universal login page](/universal-login)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Identity Providers supported by Auth0](/connections)
+:::
+
+::: concepts  
+  * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded)
+  * [ID Tokens](/tokens/concepts/id-tokens)
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * Most regular web apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Regular Web App](/microsites/call-api/call-api-regular-web-app).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+:::
+
+
diff --git a/ja-jp/articles/microsites/add-login/add-login-single-page-app.md b/ja-jp/articles/microsites/add-login/add-login-single-page-app.md
new file mode 100644
index 0000000000..7a63e2d626
--- /dev/null
+++ b/ja-jp/articles/microsites/add-login/add-login-single-page-app.md
@@ -0,0 +1,72 @@
+---
+title: Add Login to Your Single-Page App
+description: Everything you need to know to implement login for a single-page app (SPA)
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/spa
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - single-page-apps
+  - client-side
+useCase:
+  - add-login
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token that will be passed back to your application.
+
+## How it works
+
+In a single-page application (SPA): 
+
+1. The user clicks your "login" button or link, and our SDK redirects the user to your Auth0 Authorization Server.
+2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests the user's ID Token.
+4. Auth0 responds with the user's ID Token.
+
+For security in SPAs, Auth0 uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce).
+
+Flow Overview for Single-Page Apps with Auth Code Flow with PKCE
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure the sign-in methods
    Auth0 supports a wide range of authentication methods: regular username/password (users can be stored in Auth0 or your own database), social (i.e., Google, Facebook, and 50+ other providers), passwordless (email magic link, email code, and phone code), and enterprise (e.g., SAML-based, ADFS, Ping, Okta).

    Go to the dashboard and turn on the methods you want to allow; they will automatically show up in the login/sign-up page. By default, email/password and Google are enabled.
+
+  2. 
    Customize the sign-in UI (optional)
    The default experience is demonstrated in the image below and can be completely customized in the dashboard, from changing the logo and primary colors to completely overriding it with your own login screen.

    Default Login Screen for Native/Mobile Apps
+
+  3. 
    Use the Auth0 SDK to trigger the flow
    The SDK will take care of the details of redirecting to Auth0, parsing the response back, and validating the ID Token.

    Your app can keep the ID Token in memory.

    The easiest way to implement the Authorization Code Flow with PKCE is to follow our Single-Page App Quickstarts. You can also use our Auth0 Single-Page App SDK.
+:::
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Single-Page App Quickstarts](/quickstart/spa)
+  * [Add login using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/add-login-auth-code-pkce)
+  * [Add login using the Implicit Flow](/flows/guides/implicit/add-login-implicit)
+  * [Customize the universal login page](/universal-login)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Identity Providers supported by Auth0](/connections)
+:::
+
+::: concepts  
+  * [Universal vs. Embedded Login](/guides/login/universal-vs-embedded)
+  * [ID Tokens](/tokens/concepts/id-tokens)
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * Many single-page apps access APIs to retrieve data, which can also be done using Auth0. Learn how to call your API from your app: [Call Your API from Your Single-Page App](/microsites/call-api/call-api-single-page-app).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+:::
+
diff --git a/ja-jp/articles/microsites/call-api/call-api-device.md b/ja-jp/articles/microsites/call-api/call-api-device.md
new file mode 100644
index 0000000000..c6e23b60fc
--- /dev/null
+++ b/ja-jp/articles/microsites/call-api/call-api-device.md
@@ -0,0 +1,80 @@
+---
+title: Call Your API from an Input-Constrained Device
+description: Everything you need to know to call your API from your input-constrained device. For use with native apps.
+public: false
+template: microsite
+topics:
+  - authorization
+  - oauth2
+  - device
+  - mobile-apps
+  - desktop-apps
+  - native-apps
+useCase:
+  - call-api
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+With input-constrained devices, however, rather than immediately authenticating the user, the device asks the user to go to a link on their computer or smartphone to authenticate. This avoids a poor user experience for devices that do not have an easy way to enter text. If you’ve ever signed in to your Netflix account on a device like a Roku, you’ve already encountered this workflow.
+
+Your user will authenticate on their computer or smartphone, and Auth0 will generate an Access Token that will be passed back to your device application. The Access Token can then be used to call your API.
+
+This flow can be used with native applications only.
+
+## How it works
+
+When your app needs to fetch user data from your API:
+
+1. If the device is not already authorized, your device app calls your Auth0 Authorization Server to retrieve a device code.
+2. Auth0 responds with a URL and user code that your device app can use when asking the user to visit a specific URL on their laptop or smartphone and provide an activation code.
+3. Your device app begins to poll your Auth0 Authorization Server for an Access Token.
+4. The user authenticates with Auth0 on its computer or smartphone using one of your configured login options (e.g., username/password, social identity provider, SAML).
+5. Auth0 responds to your device app with an Access Token.
+6. The Access Token can be used to call your API and retrieve requested data.
+
+For devices, Auth0 uses the [Device Authorization Flow](/flows/concepts/device-auth).
+
+Flow Overview for Device Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Once you have created your API, you will need to authorize your device's application and configure any scopes that applications can request during authorization.
+
+  2. 
    Get an Access Token
    Your device requests an Access Token from your Auth0 Authorization Server using the Device Authorization Flow.
+
+  3. 
    Call your API
    When your device calls your API, it includes the retrieved Access Token in the HTTP Authorization header.
+:::
+
+
+To implement the Device Authorization Flow, you can follow our tutorial: [Call Your API Using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth).
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Backend/API Quickstarts](/quickstart/backend)
+  * [Call Your API Using the Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth)
+  * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Auth0 Authentication API](/api/authentication)
+  * [OAuth 2.0](/protocols/oauth2)
+:::
+
+::: concepts  
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * The device authorization flow works for native apps. Learn how to [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app)
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).[;]
+  "
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+  * Learn more about the ways Auth0 can help you [manage user profiles](/microsites/manage-users/manage-users-and-user-profiles) and [maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data).
+:::
diff --git a/ja-jp/articles/microsites/call-api/call-api-m2m-app.md b/ja-jp/articles/microsites/call-api/call-api-m2m-app.md
new file mode 100644
index 0000000000..5f8d1154f5
--- /dev/null
+++ b/ja-jp/articles/microsites/call-api/call-api-m2m-app.md
@@ -0,0 +1,72 @@
+---
+title: Call Your API from a Machine-to-Machine App
+description: Everything you need to know to call your API from your machine-to-machine (M2M) app
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/backend
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - m2m
+useCase:
+  - call-api
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+With machine-to-machine (M2M) apps, however, the system authenticates and authorizes the app rather than a user.
+
+## How it works
+
+When your app needs to fetch user data from your API:
+
+1. Your M2M application authenticates with your Auth0 Authorization Server.
+2. Auth0 responds with an Access Token.
+3. The Access Token can be used to call your API and retrieve requested data.
+
+For M2M applications, Auth0 uses the [Client Credentials Flow](/flows/concepts/client-credentials).
+
+Flow Overview for Machine-to-Machine Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Once you have created your API, you will need to authorize your M2M application and configure any scopes that applications can request during authorization.
+
+  2. 
    Get an Access Token
    Your app requests an Access Token from your Auth0 Authorization Server using the Client Credentials Flow.
+
+  3. 
    Call your API
    When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header.
+:::
+
+
+To implement the Client Credentials Flow, [follow our Backend/API Quickstarts](/quickstart/backend). The "Calling your API" section shows the required steps.
+
+Or, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials).
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Backend/API Quickstarts](/quickstart/backend)
+  * [Call Your API Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+  * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Auth0 Authentication API](/api/authentication)
+  * [OAuth 2.0](/protocols/oauth2)
+:::
+
+::: concepts  
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+  * Learn more about the ways Auth0 can help you [manage user profiles](/microsites/manage-users/manage-users-and-user-profiles) and [maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data).
+:::
diff --git a/ja-jp/articles/microsites/call-api/call-api-native-mobile-app.md b/ja-jp/articles/microsites/call-api/call-api-native-mobile-app.md
new file mode 100644
index 0000000000..d5442b350d
--- /dev/null
+++ b/ja-jp/articles/microsites/call-api/call-api-native-mobile-app.md
@@ -0,0 +1,87 @@
+---
+title: Call Your API from Your Native/Mobile App
+description: Everything you need to know to call your API from your native/mobile app
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/native
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - mobile-apps
+  - desktop-apps
+  - native-apps
+useCase:
+  - call-api
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API.
+
+## How it works
+
+In a native/mobile application, the default experience will open a SafariViewController in iOS or a Custom Chrome Tab in Android. 
+
+When your app needs to fetch user data from your API:
+
+1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server.
+2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests an ID Token, Access Token, and Refresh Token.
+4. Auth0 responds with the requested tokens.
+5. The Access Token can be used to call your API and retrieve requested data.
+
+For security in native/mobile devices, Auth0 uses the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce).
+
+Flow Overview for Native/Mobile Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Once you have created your API, you will need to configure any scopes that applications can request during authorization.
+
+  2. 
    Get an Access Token
    Your app requests an Access Token (and optionally, a Refresh Token) from your Auth0 Authorization Server using the Authorization Code Flow with PKCE.
+
+  3. 
    Call your API
    When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header.
+  
+  4. 
    Refresh your Access Token
    When the Access Token expires you can use the Refresh Token to get a new one from your Auth0 Authorization Server.
+
+:::
+
+
+The easiest way to implement the Authorization Code Flow with PKCE is to [follow our Mobile/Native Quickstarts](/quickstart/native).
+
+You can also use our mobile SDKs:
+
+* [Auth0 Swift SDK](/libraries/auth0-swift)
+* [Auth0 Android SDK](/libraries/auth0-android)
+
+Finally, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce).
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Mobile/Native App Quickstarts](/quickstart/native)
+  * [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce)
+  * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Auth0 Authentication API](/api/authentication)
+  * [OAuth 2.0](/protocols/oauth2)
+:::
+
+::: concepts  
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+  * If you would like to make your native/mobile app work with input-constrained devices, see [Call Your API from an Input-Constrained Device](/microsites/call-api/call-api-device).
+  * If you need to add login to your own native/mobile app, learn how at: [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app).
+:::
diff --git a/ja-jp/articles/microsites/call-api/call-api-regular-web-app.md b/ja-jp/articles/microsites/call-api/call-api-regular-web-app.md
new file mode 100644
index 0000000000..a13e6cdd73
--- /dev/null
+++ b/ja-jp/articles/microsites/call-api/call-api-regular-web-app.md
@@ -0,0 +1,78 @@
+---
+title: Call Your API from Your Regular Web App
+description: Everything you need to know to call your API from your regular web app
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/webapp
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - regular-web-apps
+  - server-side-apps
+useCase:
+  - call-api
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API and extract attributes for that user (such as name, email, role, or a custom attribute)
+
+## How it works
+
+When your app needs to fetch user data from your API:
+
+1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server.
+2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests an ID Token, Access Token, and Refresh Token.
+4. Auth0 responds with the requested tokens.
+5. The Access Token can be used to call your API and retrieve requested data.
+
+For server-side web apps, Auth0 uses the [Authorization Code Flow](/flows/concepts/auth-code).
+
+Flow Overview for Regular Web Apps
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Once you have created your API, you will need to configure any scopes that applications can request during authorization.
+
+  2. 
    Get an Access Token
    Your app requests an Access Token (and optionally, a Refresh Token) from your Auth0 Authorization Server using the Authorization Code Flow.
+
+  3. 
    Call your API
    When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header.
+  
+  4. 
    Refresh your Access Token
    When the Access Token expires you can use the Refresh Token to get a new one from your Auth0 Authorization Server.
+
+:::
+
+
+The easiest way to implement the Authorization Code Flow is to [follow our Regular Web App Quickstarts](/quickstart/webapp).
+
+Or, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow](/authorization/flows/call-your-api-using-the-authorization-code-flow).
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Regular Web App Quickstarts](/quickstart/webapp)
+  * [Call Your API Using the Authorization Code Flow](/authorization/flows/call-your-api-using-the-authorization-code-flow)
+  * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Auth0 Authentication API](/api/authentication)
+  * [OAuth 2.0](/protocols/oauth2)
+:::
+
+::: concepts  
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+  * If you need to add login to your own regular web app, learn how at: [Add Login to Your Regular Web App](/microsites/add-login/add-login-regular-web-app).
+:::
diff --git a/ja-jp/articles/microsites/call-api/call-api-single-page-app.md b/ja-jp/articles/microsites/call-api/call-api-single-page-app.md
new file mode 100644
index 0000000000..edaf4ea6e8
--- /dev/null
+++ b/ja-jp/articles/microsites/call-api/call-api-single-page-app.md
@@ -0,0 +1,74 @@
+---
+title: Call Your API from Your Single-Page App
+description: Everything you need to know to call your API from your single-page app (SPA)
+ctaText: Go to Quickstart
+ctaLink: /docs/quickstart/spa
+public: false
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - single-page-apps
+  - client-side-apps
+useCase:
+  - call-api
+---
+
+Using Auth0 in your applications means that you will be "outsourcing" the authentication process to a centralized login page in the same way that Gmail, YouTube, and any other Google property redirects to accounts.google.com whenever a user signs in.
+
+Your user will authenticate, and Auth0 will generate an ID Token and Access Token that will be passed back to your application. The Access Token can then be used to call your API.
+
+## How it works
+
+When your app needs to fetch user data from your API:
+
+1. If the user is not already authenticated, our SDK redirects the user to your Auth0 Authorization Server.
+2. The user authenticates with Auth0 using one of your configured login options (e.g., username/password, social identity provider, SAML).
+3. Your app requests an ID Token and Access Token.
+4. Auth0 responds with the requested tokens.
+5. The Access Token can be used to call your API and retrieve requested data.
+
+For single-page apps, Auth0 uses the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce).
+
+Flow Overview for Single-Page Apps with Auth Code Flow with PKCE
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Once you have created your API, you will need to configure any scopes that applications can request during authorization.
+
+  2. 
    Get an Access Token
    Your app requests an Access Token from your Auth0 Authorization Server using the Authorization Code Flow with PKCE.
+
+  3. 
    Call your API
    When your app calls your API, it includes the retrieved Access Token in the HTTP Authorization header.
+:::
+
+The easiest way to implement the Authorization Code Flow with PKCE is to [follow our Single-Page App Quickstarts](/quickstart/spa). You can also use our [Auth0 Single-Page App SDK](/libraries/auth0-spa-js).
+
+Finally, to use our API endpoints, you can follow our tutorial: [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce).
+
+:::: further-reading
+
+::: guides
+  * [Auth0 Single-Page App Quickstarts](/quickstart/spa)
+  * [Call Your API Using the Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce)
+  * [Change scopes and add custom claims to tokens using hooks](/api-auth/tutorials/client-credentials/customize-with-hooks)
+  * [Token Storage](/tokens/concepts/token-storage)
+:::
+
+::: references
+  * [SDKs](/libraries)
+  * [Auth0 Authentication API](/api/authentication)
+  * [OAuth 2.0](/protocols/oauth2)
+:::
+
+::: concepts  
+  * [Access Tokens](/tokens/concepts/access-tokens)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+  * If you need to add login to your own single-page app, learn how at: [Add Login to Your Single-Page App](/microsites/add-login/add-login-single-page-app).
+:::
diff --git a/ja-jp/articles/microsites/manage-users/define-maintain-custom-user-data.md b/ja-jp/articles/microsites/manage-users/define-maintain-custom-user-data.md
new file mode 100644
index 0000000000..64c9a50e4c
--- /dev/null
+++ b/ja-jp/articles/microsites/manage-users/define-maintain-custom-user-data.md
@@ -0,0 +1,81 @@
+---
+title: Define and Maintain Custom User Data
+description: An introduction to how Auth0 helps you manage user metadata and custom profile information 
+contentType: microsite
+topics:
+  - users
+  - user-management
+  - define-user-data
+useCase: manage-users
+template: microsite
+v2: True
+---
+
+After you have set up your [user profiles](/microsites/manage-users/manage-users-and-user-profiles), Auth0 can help you define custom user data using the [metadata](/users/concepts/overview-user-metadata) within the user profiles.
+
+## How it works
+
+There are two kinds of metadata in Auth0:
+
+* **`user_metadata`** stores user attributes (such as preferences) that do not impact users' core functionality. An authenticated user can modify this type of data. 
+* **`app_metadata`** stores information (such as users' support plans, security roles, and access control groups) that can impact users' core functionality. For example, how an application functions or what the user can access. A user cannot modify this type of data. 
+
+For example, suppose the following metadata is stored for a use with the email address `jane.doe@example.com`:
+
+```json
+{
+    "emails": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+To read metadata, simply access the correct property as you would from any JSON object. For example, if you were working with the above example metadata within a Rule or via a call to the Management API, you could reference specific items from the data set as follows:
+
+```js
+console.log(user.email); // "jane.doe@example.com"
+console.log(user.user_metadata.hobby); // "surfing"
+console.log(user.app_metadata.plan); // "full"
+```
+
+## Customize and maintain user data
+
+There are a few different ways you can customize the user metadata:
+
+* Use [Rules](/rules), which execute after a user has been authenticated, to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. 
+
+* Use the `GET/userinfo` endpoint to get a user's `user-metadata`, however you must first write a Rule to [copy metadata properties to the ID Token](/rules/current#copy-user-metadata-to-id-token). 
+
+* If you have a database connection, use the [Authentication API](/api/authentication) with the [Signup](/api/authentication?shell#signup) endpoint to set the `user-metadata` for a user. For an example, refer to [Custom Signup > Using the API](/libraries/custom-signup#using-the-api).
+
+* You can use the [Management API](/api/management/v2) to create, retrieve, or update both the `user-metadata` and `app-metadata` fields. 
+
+After you have customized the user metadata, you can manage and store data related to each of your users that doesn't originate from identity providers in the Auth0 data store or your own custom database.
+
+:::: further-reading
+::: concepts
+  * [User Management](/users)
+  * [User Profiles](/users/concepts/overview-user-profile)
+  * [Metadata](/users/concepts/overview-user-metadata)
+  * [Normalized User Profiles](/users/normalized/auth0)
+:::
+
+::: guides
+  * [Manage User Metadata](/users/guides/manage-user-metadata)
+  * [User Metadata in Rules](/rules/current/metadata-in-rules)
+  :::
+
+::: references
+  * [User Data Storage Best Practices](/users/references/user-data-storage-best-practices)
+  * [User Data Storage Scenario](/users/references/user-data-storage-scenario)
+  * [Authorization Extension](/extensions/authorization-extension/v2)
+:::
+::::
+
+::: whats-next
+* Learn more about the tools available to [manage users and user profiles](/microsites/manage-users/manage-users-and-user-profiles).
+* If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+ :::
diff --git a/ja-jp/articles/microsites/manage-users/manage-users-and-user-profiles.md b/ja-jp/articles/microsites/manage-users/manage-users-and-user-profiles.md
new file mode 100644
index 0000000000..5e564f2bc4
--- /dev/null
+++ b/ja-jp/articles/microsites/manage-users/manage-users-and-user-profiles.md
@@ -0,0 +1,71 @@
+---
+title: Manage Users and User Profiles
+description: An introduction to how Auth0 helps you manage users and their profile information
+contentType: microsite
+public: false
+topics:
+  - users
+  - user-management
+useCase: manage-users
+template: microsite
+v2: true
+---
+
+Auth0 stores user profiles for your application in a hosted cloud database. User profile information can come from your users directly or from any number of other external sources including Social Identity Providers, Enterprise connections like SAML, or custom sources like Active Directory. Auth0 refers to all user profile attribute sources as connections because Auth0 *connects* to them to authenticate the user.
+
+You can manage and store custom user attributes such as favorite color or phone number along with the standard profile information. Using our Rules engine you can modify or enhance the user profiles.   
+
+## How it works
+
+Within the Auth0 database:
+
+1. Auth0 creates a user profile for each unique user of your applications.
+2. Auth0 fills that profile with information provided by the user directly or from their chosen connection. 
+3. If the information is sourced from a connection, Auth0 refreshes that data each time the user authenticates.
+4. Each connection may return a set of attributes about the user, and each provider may use different names for the same attribute, such as surname, last name, and family name. To handle such differences, Auth0 applies a Normalized User Profile, which returns a basic set of information using specific attribute names.
+
+Manage Users and User Profiles
+
+## Manage user identities and profile information
+
+There are several ways you can modify information in a user profile or an ID Token.
+
+* **Scopes**: The authentication flows supported by Auth0 include an optional parameter that allows you to specify a scope. This controls the user profile information (claims) included in the ID Token (JWT).
+
+* **Management Dashboard**: On the dashboard administrators can manually edit portions of the user profile for a particular user. This mechanism can be used to alter the user_metadata and app_metadata portions of the user profile.
+
+* **Management API**: Provides access to read, update, and delete user profiles stored in the Auth0 database.
+
+* **Custom database scripts**: If a custom database is used as the connection, you can write scripts to implement lifecycle events such as create, login, verify, delete and change password. Auth0 provides templates for these scripts that you can modify for the particular database and schema.
+
+* **Rules**: Rules execute after a user has been authenticated. Use Rules to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. 
+
+:::: further-reading
+::: concepts
+  * [User Management](/users)
+  * [User Profiles](/users/concepts/overview-user-profile)
+  * [Metadata](/users/concepts/overview-user-metadata)
+  * [Normalized User Profiles](/users/normalized)
+ :::
+
+::: guides
+  * [Scopes](/scopes)
+  * [Manage Users Using the Dashboard](/users/guides/manage-users-using-the-dashboard)
+  * [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api)
+  * [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
+  * [Custom Database Script Templates](/connections/database/custom-db/templates)
+  * [User Metadata in Rules](/rules/current/metadata-in-rules)
+:::
+
+::: references
+  * [User Profile Structure](/users/references/user-profile-structure)
+  * [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+  * [User Data Storage Scenario](/users/references/user-data-storage-scenario)
+  * [Identity Providers Supported](/identityproviders)
+ :::
+::::
+
+::: whats-next
+* Learn about the tools available to [define and maintain custom user data](/microsites/manage-users/define-maintain-custom-user-data).
+* If you are building your own API and you want to secure the endpoints using Auth0, see [Protect Your API](/microsites/protect-api/protect-api).
+ :::
diff --git a/ja-jp/articles/microsites/protect-api/protect-api.md b/ja-jp/articles/microsites/protect-api/protect-api.md
new file mode 100644
index 0000000000..647d41f77d
--- /dev/null
+++ b/ja-jp/articles/microsites/protect-api/protect-api.md
@@ -0,0 +1,68 @@
+---
+title: Protect Your API
+description: Everything you need to know to protect your API
+template: microsite
+topics:
+  - authentication
+  - oauth2
+  - apis
+useCase:
+  - secure-api
+public: false
+---
+
+Using Auth0 to protect your API means that you will be "outsourcing" the authentication process to a centralized service that will help you ensure only approved applications can access your data. The calling application will authenticate the user, and Auth0 will generate tokens that can be passed to your API. Auth0 can also help you verify the tokens you receive from the applications that call your API.
+
+## How it works
+
+Your API will receive a request including an Access Token: 
+
+1. An app authenticates a user with Auth0.
+2. Auth0 responds with the user's ID Token and Access Token.
+3. The app calls your API, passing along the Access Token.
+4. Your API validates the Access Token.
+5. Your API responds with the requested information.
+
+Flow Overview for Protect API
+
+## Implementation overview
+
+::: steps
+  1. 
    Configure your API
    Auth0 supports access from various application types. If you expect a machine-to-machine (M2M) app to call your API, go to the dashboard and authorize them to request Access Tokens.
    You can also allow your API to skip user consent for your own apps and identify your API's scopes. If you're building a public-facing API, you'll need to let external callers know which of these scopes are available to them and provide guidance on how they can call your API.
+
+  2. 
    Use a JWT validation library to validate tokens
    The library will take care of the details of parsing and validating the received tokens. This consists of a series of steps, and if any of these fails, then you must reject the application's request. Follow one of our Backend/API Quickstarts to get started.
+
+  3. 
    Respond to the request
    Once your token has been successfully validated, respond to the calling application with their requested data.
+
+:::
+
+
+:::: further-reading
+
+::: guides
+  * [Configure an API](/apis#how-to-configure-an-api-in-auth0)
+  * [Auth0 Backend/API Quickstarts](/quickstart/backend)
+  * [Validate an Access Token for custom APIs](/tokens/guides/validate-access-tokens)
+:::
+
+::: references
+  * [OAuth 2.0](/protocols/oauth2)
+  * [Auth0 Authentication API](/api/authentication)
+:::
+
+::: concepts  
+  * [Tokens](/tokens)
+  * [Access Tokens](/tokens/concepts/access-tokens)
+  * [Scopes](/scopes)
+  * [Dynamic client registration](/api-auth/dynamic-client-registration)
+:::
+
+::::
+
+::: whats-next
+  * Auth0 offers many ways to personalize your user's login experience and customize tokens using [rules](/rules) and [hooks](/hooks).
+  * Learn how to call your API from your app: [Call Your API from My Native/Mobile App](/microsites/call-api/call-api-native-mobile-app), [Call Your API from My Regular Web App](/microsites/call-api/call-api-regular-web-app), [Call Your API from Your Single-Page App](/microsites/call-api/call-api-single-page-app), or [Call Your API from a M2M App](/microsites/call-api/call-api-m2m-app).
+  * If you are building your own application and you want to log users in using Auth0, learn to add login to your app: [Add Login to Your Native/Mobile App](/microsites/add-login/add-login-native-mobile-app), [Add Login to Your Regular Web App](/microsites/add-login/add-login-regular-web-app), or [Add Login to Your Single-Page App](/microsites/add-login/add-login-single-page-app).
+:::
+
+
diff --git a/ja-jp/articles/migrations/guides/_forced-logouts.md b/ja-jp/articles/migrations/guides/_forced-logouts.md
new file mode 100644
index 0000000000..91bbc59482
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/_forced-logouts.md
@@ -0,0 +1,3 @@
+::: warning
+When a user's `/oauth/ro` based access token has expired, Auth0 **forces them to reauthenticate** (forced logout required) because the `/oauth/ro` refresh token cannot be used to call `/oauth/token` for a new Access Token. All currently logged in user's must log in again during an `/oauth/ro` to `/oauth/token` migration. 
+:::
diff --git a/ja-jp/articles/migrations/guides/_get-token-auth0js.md b/ja-jp/articles/migrations/guides/_get-token-auth0js.md
new file mode 100644
index 0000000000..52d002f06e
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/_get-token-auth0js.md
@@ -0,0 +1,63 @@
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+// get an ID Token
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: '${account.callback}',
+  scope: 'openid',
+  responseType: 'id_token'
+});
+// create a new instance
+var auth0Manage = new auth0.Management({
+  domain: '${account.namespace}',
+  token: 'ID_TOKEN'
+});
+        
+      
    
+      
    
+        
      
+          
    • Asks for an ID Token in the response (responseType: 'id_token')
      • 
+          
    • Authenticates with the Management API using the ID Token
      • 
+        
    
+      
    
+    
    
+    
    
+      
    +        
+// get an Access Token
+var webAuth = new auth0.WebAuth({
+  clientID: '${account.clientId}',
+  domain: '${account.namespace}',
+  redirectUri: '${account.callback}',
+  audience: 'https://${account.namespace}/api/v2/',
+  scope: '${scope}',
+  responseType: 'token id_token'
+});
+// create a new instance
+var auth0Manage = new auth0.Management({
+  domain: '${account.namespace}',
+  token: 'ACCESS_TOKEN'
+});
+        
+      
    
+      
    
+        
      
+          
    • Asks for both an ID Token and an Access Token in the response (responseType: 'token id_token')
      • 
+          
    • Sets the Management API as the intended audience of the token (audience: 'https://${account.namespace}/api/v2/')
      • 
+          
    • Asks for the required permission (scope: '${scope}')
      • 
+          
    • Authenticates with the Management API using the Access Token
      • 
+        
    
+      
    
+    
    
+  
    
+
    
diff --git a/ja-jp/articles/migrations/guides/_get-token-authorize.md b/ja-jp/articles/migrations/guides/_get-token-authorize.md
new file mode 100644
index 0000000000..304e3c93b9
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/_get-token-authorize.md
@@ -0,0 +1,58 @@
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+https://${account.namespace}/authorize?
+  scope=openid
+  &response_type=id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &nonce=NONCE
+  &state=OPAQUE_VALUE
+        
+      
    
+    
    
+    
    
+      
    +        
+https://${account.namespace}/authorize?
+  audience=https://${account.namespace}/api/v2/
+  &scope=${scope}
+  &response_type=token%20id_token
+  &client_id=${account.clientId}
+  &redirect_uri=${account.callback}
+  &nonce=NONCE
+  &state=OPAQUE_VALUE
+        
+      
    
+    
    
+  
    
+
    
+
+To get an Access Token that can access the Management API:
+- We set the `audience` to `https://${account.namespace}/api/v2/`
+- We asked for the scope `${scope}`
+- We set the `response_type` to `id_token token` so Auth0 will sent us both an ID Token and an Access Token
+
+If we decode the Access Token and review its contents we can see the following:
+
+```text
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|5a620d29a840170a9ef43672",
+  "aud": "https://${account.namespace}/api/v2/",
+  "iat": 1521031317,
+  "exp": 1521038517,
+  "azp": "${account.clientId}",
+  "scope": "${scope}"
+}
+```
+
+Notice that the `aud` is set to your tenant's API URI, the `scope` to `${scope}`, and the `sub` to the user ID of the logged in user.
\ No newline at end of file
diff --git a/ja-jp/articles/migrations/guides/account-linking.md b/ja-jp/articles/migrations/guides/account-linking.md
new file mode 100644
index 0000000000..c56e1766b1
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/account-linking.md
@@ -0,0 +1,246 @@
+---
+description: Auth0 is deprecating the usage of ID Tokens in the Account Linking process. This article will help you migrate your solution from the old implementation to the new one.
+toc: true
+topics:
+  - account-linking
+  - migrations
+contentType:
+  - concept
+  - how-to
+useCase:
+  - manage-accounts
+---
+
+# Migration Guide: Account Linking with Access Tokens vs. ID Tokens
+
+This guide is part of the [Deprecating the usage of ID Tokens on the Auth0 Management API](/migrations#deprecating-the-usage-of-id-tokens-on-the-auth0-management-api) migration, and focuses on the [account linking process](/users/concepts/overview-user-account-linking).
+
+For some use cases you could use [ID Tokens](/tokens/concepts/id-tokens) to link and unlink user accounts. This functionality is being deprecated. You will have to use Access Tokens in all cases.
+
+The changes in account linking are:
+
+- You can no longer use an ID Token at the `Authorization` header, an Access Token must be used instead
+- If you use an Access Token at the `Authorization` header, with `update:users` as the granted permission, then you can send at the request's body either the `user_id` or the ID Token of the secondary account.
+- If you use an Access Token at the `Authorization` header, with `update:current_user_metadata` as the granted permission, then you can only send the ID Token of the secondary account in the request's body.
+- If you send the ID Token of the secondary account in the request's body (that is, the use cases described in the previous two bullets), then the following must apply:
+  - The ID Token must be signed using `RS256` (you can set this value at *Dashboard > Clients > Client Settings > Advanced Settings > OAuth*)
+  - The claim `aud` of the ID Token, must identify the client, and be the same value with the `azp` claim of the Access Token
+
+The change in the unlinking of accounts is that you can no longer use an ID Token at the `Authorization` header. An Access Token must be used instead. See [#security-considerations] below for details. 
+
+::: warning
+This migration is specifically targeted to mitigate a possible security vulnerability. Auth0 strongly recommendeds that you update your code as soon as possible. 
+:::
+
+## Are you affected?
+
+There are several ways you can link and unlink accounts. Some change, some remain the same, and a new variation is introduced. In the following matrix you can see a list of the use cases and their status based on this migration.
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    Use caseStatusMore info
    You link user accounts with the Link a user account endpoint of the Management API, and you send the primary account's ID Token in the Authorization header.
    Affected
    		Link current user accounts with the API
    You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token (with scope update:users) in the Authorization header, and the secondary account's user_id in the payload
    No change
    		N/A
    You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token (with scope update:current_user_identities) in the Authorization header, and the secondary account's user_id in the payload
    Affected
    		Link current user accounts with the API
    You link user accounts with the Link a user account endpoint of the Management API, you send an Access Token in the Authorization header, and the secondary account's ID Token in the payload
    New use case
    		Link any user account with the API
    You link user accounts with the Auth0.js library, and you use the primary account's ID Token to instantiate auth0.Management
    Affected
    		Link current user accounts with Auth0.js
    You link user accounts with the Auth0.js library, and you use an Access Token (with scope update:users) to instantiate auth0.Management
    No change
    		N/A
    You link user accounts with the Auth0.js library, and you use an Access Token (with scope update:current_user_identities) to instantiate auth0.Management
    Affected
    		Link current user accounts with Auth0.js
    You unlink user accounts with the Unlink a user identity endpoint of the Management API, and you send the primary account's ID Token in the Authorization header
    Affected
    		How to unlink accounts
    You unlink user accounts with the Unlink a user identity endpoint of the Management API, and you send an Access Token in the Authorization header
    No change
    		N/A
    
+
+## Link user accounts
+
+In order to link accounts you can either call directly the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint of the Management API, or use the [Auth0.js library](/auth0js#user-management).
+
+### Link current user accounts with the Management API
+
+A common use case is to allow the logged-in user to link their various accounts using your app. 
+
+Until now you could use the primary user's ID Token or Access Token (which contained the `update:current_user_identities` scope) in order to authenticate with the Management API and use the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint.
+
+With this migration, you must get an Access Token (which must contain the `update:current_user_identities` scope) and use that to authenticate with the API and use the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint. The payload must be the ID Token of the secondary user.
+
+First, you must get an Access Token with the `update:current_user_identities` scope. 
+
+::: note
+In the example that follows, we use the [Implicit Flow](/flows/guides/implicit/call-api-implicit), the recommended OAuth 2.0 flow for client-side apps). You can get Access Tokens though for any application type (see [Get Access Tokens](/tokens/get-access-tokens).
+:::
+
+<%= include('./_get-token-authorize.md', { scope: 'update:current_user_identities', idPrevious: 'authZ-id-token', idCurrent: 'authZ-access-token' }) %>
+
+**The following must apply:**
+- The secondary account's ID Token must be signed with `RS256`
+- The `aud` claim in the secondary account's ID Token must identify the client, and hold the same value with the `azp` claim of the Access Token used to make the request.
+
+Once you have the Access Token you can use it to link user accounts. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+### Link current user accounts with Auth0.js
+
+If you use [Auth0.js library](/libraries/auth0js#user-management) to access the Management API and link accounts, then you probably use the ID Token of the user's primary identity to instantiate `auth0.Management` and use it to link accounts.
+
+With this migration, you must get an Access Token (with the `update:current_user_identities` scope) and use that to instantiate the object.
+
+First, you must get an Access Token with the `update:current_user_identities` scope. Then use this token to instantiate `auth0.Management`. The final call to `linkUser` remain the same.
+
+<%= include('./_get-token-auth0js.md', { scope: 'update:current_user_identities' }) %>
+
+### Link any user account with the Management API
+
+If you get an Access Token for account linking, that contains the `update:users` scope, and send the secondary account's `user_id` and `provider` in the request, then you don't have to make any changes.
+
+However, this migration does introduce an alternative to this. You still use an Access Token that contains the `update:users` scope to authenticate with the API, but in the request's payload you can send the secondary's account ID Token (instead of `user_id` and `provider`).
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+**The following must apply:**
+- The secondary account's ID Token must be signed with `RS256`
+- The `aud` claim in the secondary account's ID Token must identify the client, and hold the same value with the `azp` claim of the Access Token used to make the request.
+
+## Unlink user accounts
+
+If you use ID Tokens in order to unlink accounts, then you must update your implementation to use Access Tokens.
+
+First, you must get an Access Token with the `update:current_user_identities` scope.
+
+Use the sample script that follows as a guide. On the **Legacy (ID Token)** panel you can see an implementation of the old approach that gets an ID Token. On the **Current (Access Token)** panel you can see the new approach that gets an Access Token as well.
+
+<%= include('./_get-token-authorize.md', { scope: 'update:current_user_identities', idPrevious: 'unlink-id-token', idCurrent: 'unlink-access-token' }) %>
+
+Once you have the Access Token, you can call the [Unlink a user identity](/api/management/v2#!/Users/delete_user_identity_by_user_id) endpoint of the Management API, using it in the `Authorization` header.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+DELETE https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID
+Authorization: 'Bearer ID_TOKEN-OR-ACCESS_TOKEN'
+        
+      
    
+    
    
+    
    
+      
    +        
+DELETE https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID
+Authorization: 'Bearer ACCESS_TOKEN'
+        
+      
    
+    
    
+  
    
+
    
+
+## Security considerations
+
+We have identified a weakness in a particular account linking flow that could allow it to be misused in specific circumstances. We have found no evidence that this has been used maliciously but have decided to deprecate the flow to prevent that ever happening.
+
+Therefore, Auth0 requires customers using the affected account linking flow to migrate to a more secure implementation before October 19th, 2018. Migration paths are provided in this guide, which should not result in any lost functionality.
+
+On October 19th, 2018 or anytime after, the affected account linking flow will be disabled and customers using it will experience run-time errors.
+
+### What's the impact
+
+You are impacted if you call the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) endpoint using a token (ID or Access Token) with the scope `update:current_user_identities` in the Authorization header and include the secondary account's `user_id` in the payload.
+
+No other use cases are impacted.
+
+## Next steps
+
+You should review all your calls to the account linking endpoint ([/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities)) and update those that make use of the vulnerable flow described above. You can update your calls to either of the following:
+
+1. **Client-side / user-initiated linking scenarios** -- For client-side linking scenarios, make the call to the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) using an Access Token with the `update:current_user_identities` scope, and provide the ID Token of the secondary account in the payload (`link_with`). This ID Token must be obtained through an OAuth/OIDC-conformant flow. See [Link User Accounts Initiated by Users Scenario](/users/references/link-accounts-user-initiated-scenario) for more details.
+2. **Server-side linking scenarios** -- For server-side linking scenarios, make the call to the [/api/v2/users/{USER_ID}/identities](/api/management/v2#!/Users/post_identities) endpoint using an Access Token with the `update:users` scope and provide the `user_id` of the secondary account in the payload. See [Link User Accounts Server-Side Scenario](/users/references/link-accounts-server-side-scenario) for details.
+
+## Keep reading
+
+- [Link User Accounts](/users/guides/link-user-accounts)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/ja-jp/articles/migrations/guides/calling-api-with-idtokens.md b/ja-jp/articles/migrations/guides/calling-api-with-idtokens.md
new file mode 100644
index 0000000000..471a05cdc5
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/calling-api-with-idtokens.md
@@ -0,0 +1,197 @@
+---
+title: "Migration Guide: Management API and ID Tokens"
+description: Auth0 is deprecating the usage of ID Tokens as credentials for the Management API. This article will help you migrate your solution from the old implementation to the new one.
+toc: true
+topics:
+  - migrations
+  - management-api
+  - id-tokens
+  - tokens
+contentType:
+  - concept
+  - how-to
+  - reference
+useCase:
+  - manage-accounts
+---
+
+# Migration Guide: Management API and ID Tokens
+
+For some use cases you could use [ID Tokens](/tokens/concepts/id-tokens) in order to call some of the [Users](/api/management/v2#!/Users/get_users_by_id) and [Device Credentials](/api/management/v2#!/Device_Credentials/get_device_credentials) endpoints of the Management API. 
+
+This functionality is being deprecated. You will have to use proper [Access Tokens](/tokens/access-token) in order to access any of the endpoints of the [Management API](/api/management/v2). Make sure the `Allow ID Tokens for Management API v2 Authentication` toggle is turned off after completing the migration to Access Tokens.
+
+The grace period for this migration started on **March 31, 2018** and at the moment is open-ended. This means that you will still be able to use ID Tokens to access these endpoints. When a mandatory opt-in date is set for this migration customers will be notified beforehand.
+
+Customers are encouraged to migrate to Access Tokens. This guide will help you with that. 
+
+First, we will see which use cases are affected. We will continue with reviewing how you can use [scopes](/scopes) to get tokens with different access rights, and then see all the ways you can use to get an Access Token. Finally, we will review the changes introduced in the [User Account Linking](/users/concepts/overview-user-account-linking) process.
+
+## Does this affect me?
+
+If you use ID Tokens to call any of the following endpoints, then you are affected by this migration:
+
+| **Endpoint** | **Use Case** |
+|-|-|
+| [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id) | Retrieve a user's information |
+| [GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) | Retrieve all [Guardian](/mfa/concepts/guardian) MFA enrollments for a user |
+| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | Update a user's information |
+| [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) | Delete the MFA provider settings for a user |
+| [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) | Create a public key for a device |
+| [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | Delete a device credential |
+| [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) | [Link user accounts](/users/guides/link-user-accounts) from various identity providers |
+| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) | [Unlink user accounts](/users/guides/unlink-user-accounts) |
+
+These endpoints can now accept regular [Access Tokens](/tokens/concepts/access-tokens).
+
+Note that the last two endpoints are used for Account Linking. To review these changes, see [Changes in Account Linking](#changes-in-account-linking).
+
+**Nothing else changes in how the endpoints work**. You should expect the same request and response schemas and only need update the token that you use for authorization.
+
+## Changes in scopes
+
+The actions you can perform with the Management API depend on the [scopes](/scopes/current/api-scopes) that your Access Token contains. With this migration you can either get a "limited" Access Token that can update only the logged-in user's data, or an Access Token that can update the data of any user. In the following matrix you can see the scopes that your token needs to have per case and per endpoint.
+
+| **Endpoint** | **Scope for current user** | **Scope for any user** |
+|-|-|-|
+| [GET /api/v2/users/{id}](/api/management/v2#!/Users/get_users_by_id) | `read:current_user` | `read:users` |
+| [GET /api/v2/users/{id}/enrollments](/api/management/v2#!/Users/get_enrollments) | `read:current_user` | `read:users` |
+| [POST/api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) | `update:current_user_identities` | `update:users` |
+| [DELETE /api/v2/users/{id}/identities/{provider}/{user_id}](/api/management/v2#!/Users/delete_user_identity_by_user_id) | `update:current_user_identities` | `update:users` |
+| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | `update:current_user_metadata` | `update:users` |
+| [PATCH /api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) | `create:current_user_metadata` | `update:users` |
+| [DELETE /api/v2/users/{id}/multifactor/{provider}](/api/management/v2#!/Users/delete_multifactor_by_provider) | `delete:current_user_metadata` | `update:users` |
+| [POST /api/v2/device-credentials](/api/management/v2#!/Device_Credentials/post_device_credentials) | `create:current_user_device_credentials` | `create:device_credentials` |
+| [DELETE /api/v2/device-credentials/{id}](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) | `delete:current_user_device_credentials` | `delete:device_credentials` |
+
+For example, if I get an Access Token that contains the scope `read:users` I can retrieve the data of **any user** using the [GET /api/v2/users/{id} endpoint](/api/management/v2#!/Users/get_users_by_id). But if my token contains the scope `read:current_user` I can only retrieve the information of the **currently logged-in user** (the one that the token was issued for).
+
+## Restrictions
+
+The Access Tokens used to access the Management API **must hold only one value at the `aud` claim**. If your token contains more than one value, then your request to the Management API will error out.
+
+## How to get an Access Token
+
+In this section we will see the changes that are introduced in how you get a token for the aforementioned endpoints. We will see sample scripts side-by-side so you can identify the changes.
+
+There are several variations on how you authenticate a user and get tokens, depending on the technology and the [OAuth 2.0 flow you use to authenticate](/api-auth/which-oauth-flow-to-use):
+- Using the [Authorization endpoint](/api/authentication#authorize-application). This is where you redirect your users to login or sign up. You get your tokens from this endpoint if you authenticate users from a [single-page app](/api/authentication#implicit-grant) (running on the browser).
+- Using the [Token endpoint](/api/authentication#get-token). You get your tokens from this endpoint if you authenticate users from a [web app](/api/authentication#authorization-code) (running on a server), a [mobile app](/api/authentication#authorization-code-pkce-), a [server process](/api/authentication#client-credentials), or a [highly trusted app](/api/authentication#resource-owner-password).
+- Using [Lock](/libraries/lock/v11#cross-origin-authentication) or [auth0.js](/libraries/auth0js/v9#configure-your-auth0-application-for-embedded-login) embedded in your application. In this case you are using [cross-origin authentication](/cross-origin-authentication) (used to authenticate users when the requests come from different domains). 
+
+### The Authorization endpoint
+
+In this section we will use an example to showcase the differences in how you get a token with the [Authorization endpoint](/api/authentication#authorize-application). Keep in mind though that no matter which endpoint you want to migrate, the changes are the same, the only thing that differs is the [scopes](#changes-in-scopes) you will specify in the request.
+
+In the example below, we want to use the [GET User by ID endpoint](/api/management/v2#!/Users/get_users_by_id) to retrieve the full profile information of the logged-in user. To do so, first we will authenticate our user (using the [Implicit grant](/api/authentication?http#implicit-grant)) and retrieve the token(s).
+
+On the `Legacy (ID Token)` panel you can see an implementation of the old approach that gets an ID Token (and then uses it to call the endpoint). On the `Current (Access Token)` panel you can see the new approach that gets an Access Token as well.
+
+<%= include('./_get-token-authorize.md', { scope: 'read:current_user', idPrevious: 'authZ-id-token', idCurrent: 'authZ-access-token' }) %>
+
+Once you have the Access Token you can use it to call the endpoint. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same.
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/users/USER_ID",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  }]
+}
+```
+
+### The Token endpoint
+
+In this section we will use an example to showcase the differences in how you get a token with the [Token endpoint](/api/authentication#get-token). Keep in mind though that no matter which endpoint you want to migrate, the changes are the same, the only thing that differs is the [scopes](#changes-in-scopes) you will specify in the request.
+
+In the example below, we want to use the [GET User by ID endpoint](/api/management/v2#!/Users/get_users_by_id) to retrieve the full profile information of the logged-in user. To do so, first we will authenticate our user (using the [Password Exchange grant](/api/authentication?http#resource-owner-password)) and retrieve the token(s).
+
+On the `Legacy (ID Token)` script you can see an implementation of the old approach that gets an ID Token (and then uses it to call the endpoint). On the `Current (Access Token)` script you can see the new approach that gets an Access Token as well.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+{
+  "grant_type": "password",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "scope": "openid",
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+}
+        
+      
    
+    
    
+    
    
+      
    +        
+POST https://${account.namespace}/oauth/token
+Content-Type: application/x-www-form-urlencoded
+{
+  "grant_type": "password",
+  "username": "USERNAME",
+  "password": "PASSWORD",
+  "audience": "https://${account.namespace}/api/v2/",
+  "scope": "read:current_user",
+  "client_id": "${account.clientId}",
+  "client_secret": "YOUR_CLIENT_SECRET",
+}
+        
+      
    
+    
    
+  
    
+
    
+
+In order to get an Access Token that can access the Management API:
+- We set the `audience` to `https://${account.namespace}/api/v2/`
+- We asked for the scope `read:current_user`
+
+Once you have the Access Token you can use it to call the endpoint. This part remains the same, nothing else changes in the request except for the value you use as `Bearer` token. The response remains also the same.
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/users/USER_ID",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  }]
+}
+```
+
+### Lock or auth0.js (embedded)
+
+If you embed either [Lock v11](/libraries/lock/v11) or [auth0.js v9](/libraries/auth0js/v9) in your application, then you are using [cross-origin authentication](/cross-origin-authentication). This is used to authenticate users when the requests come from different domains.
+
+If you use auth0.js to access the Management API and manage your users, then your script will have to be updated.
+
+<%= include('./_get-token-auth0js.md', { scope: 'read:current_user' }) %>
+
+## Changes in Account Linking
+
+The changes in this functionality are the following:
+
+- You can no longer use an ID Token at the `Authorization` header
+- If you use an Access Token at the `Authorization` header, with `update:users` as the granted permission, then you can send at the request's body either the `user_id` or the ID Token of the secondary account
+- If you use an Access Token at the `Authorization` header, with `update:current_user_metadata` as the granted permission, then you can only send the ID Token of the secondary account in the request's body. The following must apply:
+  - The ID Token must be signed using `RS256` (you can set this value at *Dashboard > Applications > Application Settings > Advanced Settings > OAuth*)
+  - The claim `aud` of the ID Token, must identify the application, and be the same value with the `azp` claim of the Access Token
+
+For a detailed overview of these changes and migration steps per use case, see [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking).
+
+## Keep reading
+
+- [Get Access Tokens](/tokens/guides/get-access-tokens)
+- [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
diff --git a/ja-jp/articles/migrations/guides/clickjacking-protection.md b/ja-jp/articles/migrations/guides/clickjacking-protection.md
new file mode 100644
index 0000000000..877e705f0c
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/clickjacking-protection.md
@@ -0,0 +1,27 @@
+---
+title: Migration Guide: Enabling Clickjacking Protection for Universal Login
+description: Auth0 is adding a way to prevent the Universal Login pages to be embedded in an iframe.
+toc: true
+topics:
+  - universal-login
+  - migrations
+contentType:
+  - concept
+  - how-to
+---
+# Migration Guide: Enabling Clickjacking Protection
+
+Clickjacking is an attack that tricks a user into clicking a web page element which is invisible or disguised as another element. This is done by loading content in an iframe and rendering elements on top of it. In the context of the Universal Login pages, an attacker could trick the user into clicking a 'Login', or 'Reset Password' button.
+
+This can be prevented by setting the following HTTP headers:
+
+```
+X-Frame-Options: deny
+Content-Security-Policy: frame-ancestors 'none'
+```
+
+Even if the potential attack does not entail significant risk, it's a good security practice to add the headers. It is also detected by security scanners, so reports from penetration testers might mention the lack of these headers.
+
+In a case where you are rendering the login page in an iframe, adding these headers could be a breaking change. Instead of adding these headers for all customers, therefore, Auth0 has added an opt-in for these headers which we strongly recommend you to enable.
+
+You can do this by navigating to [Tenant Settings > Advanced Settings](${manage_url}/#/tenant/advanced), scrolling to 'Migrations', and turning OFF the 'Disable clickjacking protection for Classic Universal Login' setting. This action is not required if you are using the [New Universal Login Experience](/universal-login/new) as those headers are always set.
diff --git a/ja-jp/articles/migrations/guides/extensibility-node12.md b/ja-jp/articles/migrations/guides/extensibility-node12.md
new file mode 100644
index 0000000000..2ef5c6f878
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/extensibility-node12.md
@@ -0,0 +1,191 @@
+---
+title: "Migration Guide: Extensibility and Node 12"
+description: Learn about the Auth0 features affected by the Node.js v8 to Node.js v12 migration and review our recommendations for ensuring a smooth migration process.
+toc: true
+topics:
+  - migrations
+  - extensibility
+  - nodejs
+  - rules
+  - hooks
+  - custom-db
+  - custom-social-connections
+  - extensions
+contentType:
+  - concept
+  - how-to
+useCase:
+  - manage-accounts
+  - migrate
+---
+# Migration Guide: Extensibility and Node 12
+
+On December 31, 2019, [Node.js v8 went out of long-term support (LTS)](https://github.com/nodejs/Release#release-schedule), which means that the Node.js development team no longer back-ports critical security fixes to this version. This _could_ expose your extensibility code to security vulnerabilities.
+
+As such, Auth0 is migrating from Node 8 to Node 12.
+
+In this document, we:
+
+* Provide recommendations on how you can ensure a smooth migration for your environment
+* Detail the specific modules affected
+
+## Summary of the migration
+
+The Webtask runtime powering the following Auth0 features use Node 8:
+
+* Rules
+* Hooks
+* Custom database connections
+* Custom social connections
+* Extensions
+
+If you do not use any of the extensibility features mentioned above, you are not affected by this migration.
+
+## Verified extensions
+
+As part of this migration, the Auth0 development team has performed extensive testing to proactively detect any breaking changes.
+
+Verified extensions for Node 12 include:
+
+* Realtime Webtask Logs
+* Deploy extensions (Github, Gitlab, etc.)
+* Deploy CLI
+
+Still, there may be behavioral changes as a result of this migration, so we have provided a migration switch that allows you to control the migration of your environment to the new Webtask runtime using Node 12.
+
+## Enable the Node 12 runtime
+
+Node 12 can be enabled through the new Extensibility panel on the [Advanced Tenant Settings](${manage_url}/#/tenant/advanced) page of the Dashboard.
+
+![Runtime toggle](/media/articles/migrations/node-runtime1.png)
+
+![Runtime toggle options](/media/articles/migrations/node-runtime2.png)
+
+::: warning
+Changing the runtime may break your existing Rules, Hooks, and Custom Database/Social Connections. We recommend that you first switch your development tenant to the Node 12 runtime, test your setup, and switch your production tenant only when you have identified there are no breaking changes.
+:::
+
+## Whitelist the new URLs
+
+The [Delegated Administration Extension](/extensions/delegated-admin) and the [Single Sign-on (SSO) Dashboard Extension](/extensions/sso-dashboard) require whitelisting the URLs used to access extensions and custom webtasks. When you upgrade to Node 12, the URLs you use to access extensions and custom webtasks will change. This is a breaking change for these extensions.
+
+If you use any of these extensions, **you must whitelist the new URLs** both as Allowed Callback and as Allowed Logout URLs.
+
+The region portion of the URL will change from 8 to 12. If you access an extension using the URL `https://${account.tenant}.us8.webtask.io/dummy-extension-url`, when you upgrade to Node 12 the URL will be `https://${account.tenant}.us12.webtask.io/dummy-extension-url`.
+
+To do so, go to [Dashboard > Applications > Settings](${manage_url}/#/applications/${account.clientId}/settings), and add the URL to the fields **Allowed Callback URLs** and **Allowed Logout URLs**.
+
+The execution URLs will also change for custom webtasks in your Auth0 container. You must update any external applications that call those webtasks.
+
+### Authorization Extension Changes
+
+If you use the Authorization Extension, it generates an `auth0-authorization-extension` rule. Republishing this rule from within the Authorization Extension will update the URLs automatically.
+
+To ensure a clean upgrade:
+
+1. Ensure you have upgraded to the latest version of the Authorization Extension from the "Installed Extensions" tab. If the upgrade button is present, click to upgrade. If the button is not present, you are already on the latest version of the extension.
+2. Open the Authorization Extension configuration page.
+3. To update the URL in the rule, publish the rule again by clicking the "Publish Rule" button.
+4. Test to make sure everything is still working.
+5. If you see an "Invalid API Key" error after updating, use the "Rotate" button to generate a new API key.
+
+![Authorization Extension Configuration](/media/articles/migrations/node-auth-ext-config.png)
+
+![Authorization Extension Buttons](/media/articles/migrations/node-auth-ext-buttons.png)
+
+### Delegated Administration URLs
+
+If you use the Delegated Administration Extension, the matrix that follows contains the updated URLs you must configure after you migrate to Node 12. The URL varies based on your location.
+
+| Location | Allowed Callback URL for Node 12 | Allowed Logout URL for Node 12 |
+| --- | --- | --- |
+| USA | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin` |
+| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.eu12.webtask.io/auth0-delegated-admin` |
+| Australia | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin/login` | `https://${account.tenant}.au12.webtask.io/auth0-delegated-admin` |
+
+For example, if you are located in the USA and you use the Delegated Administration, you should update the following fields in your application's settings:
+- **Allowed Callback URLs**: `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin/login`
+- **Allowed Logout URLs**: `https://${account.tenant}.us12.webtask.io/auth0-delegated-admin`
+
+### SSO Dashboard URLs
+
+The matrix that follows contains the updated URLs you must configure after you migrate to Node 12. The URL varies based on your location.
+
+The login URL for **Admins**:
+
+| Location | Allowed Callback URL |
+| --- | --- |
+| USA | `https://${account.tenant}.us12.webtask.io/auth0-sso-dashboard/admins/login` |
+| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-sso-dashboard/admins/login` |
+| Australia | `https://${account.tenant}.au12.webtask.io/auth0-sso-dashboard/admins/login` |
+
+The login URL for **Users**:
+
+| Location | Allowed Callback URL |
+| --- | --- |
+| USA | `https://${account.tenant}.us12.webtask.io/auth0-sso-dashboard/login` |
+| Europe | `https://${account.tenant}.eu12.webtask.io/auth0-sso-dashboard/login` |
+| Australia | `https://${account.tenant}.au12.webtask.io/auth0-sso-dashboard/login` |
+
+### All Extensions
+
+Most extensions use the `PUBLIC_WT_URL` hidden secret for authorization. This secret depends on the runtime version and does not update automatically.
+
+To update it, you need to save the extension's settings (no changes are necessary). To do so, after switching the runtime to `Node 12`, you need to open the extension's settings in the extensions dashboard (gear icon) and hit `Save`. After that, the extensions gallery will update the `PUBLIC_WT_URL` secret accordingly based on the selected runtime.
+
+If you do not update the `PUBLIC_WT_URL` hidden secret, you will receive the following error:
+
+![Misconfiguration or Service Outage Error](/media/articles/migrations/node-hidden-secret-error.png)
+
+## How to ensure a stable migration
+
+As part of the process of introducing Node 12 in our Webtask runtime, we ran a number of tests to determine which modules are not forward-compatible from Node 8 to 12. Most customers _should_ be able to upgrade to Node 12 without any issues.
+
+With that said, before you migrate, we highly recommend testing all of your:
+
+* Rules
+* Hooks
+* Custom Database Connections/Scripts
+* Custom Social Connections
+* Extensions
+
+Furthermore, we recommend that the testing be done in your development tenant and migrating your production tenant only if you see no issues in development.
+
+You can query the Management API for your Rules, Hooks, Custom Database scripts, and Custom Social Connections. This will make it easier for you to move items from your production tenant to development tenant for testing purposes.
+
+Please see our documentation on the [Connections](/api/management/v2#!/Connections), [Rules](/api/management/v2#!/Rules/get_rules), and [Hooks](/api/management/v2/#!/Hooks/get_hooks) endpoints for additional information on this process.
+
+When using the [Connections](/api/management/v2#!/Connections) endpoints in the Management API, Custom Database Scripts can be retrieved or updated using `options.customScripts`.
+
+Similarly, you can find Custom Social Connections in `options.scripts.fetchUserProfile`.
+
+## Affected modules
+
+If you are using the following built-in modules (that is, modules that you did not explicitly require), please be aware that some versions were updated to work with Node 12. The following table summarizes the changes.
+
+| Module name | Old version | New version |
+| - | - | - |
+| couchbase | ~2.5.1 | 2.6.10 |
+| bcrypt | 1.0.3 | 3.0.8 |
+
+These new versions should remain backwards compatible with their previous versions.
+
+### Pinned modules
+
+If you have manually pinned modules, you may need to manually update them so that your code runs with Node 12.
+
+For example, you must change
+
+`var bcrypt = require(‘bcrypt@1.0.3’);`
+
+to
+
+`var bcrypt = require(‘bcrypt’);`
+
+or, if the module must be pinned to a specific version:
+
+`var bcrypt = require(‘bcrypt@3.0.8’);`
+
+### Notes for Node 10 and Node 12 changes
+
+For additional information, please consult Node.js's [Node 10 release notes](https://nodejs.org/fr/blog/release/v10.0.0/) and [Introducing Node.js 12](https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f).
diff --git a/ja-jp/articles/migrations/guides/facebook-graph-api-deprecation.md b/ja-jp/articles/migrations/guides/facebook-graph-api-deprecation.md
new file mode 100644
index 0000000000..39159f0b6e
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/facebook-graph-api-deprecation.md
@@ -0,0 +1,120 @@
+---
+title: Changes to Facebook Graph API
+description: The latest version of the Facebook Graph API changes what permissions and fields can be requested.
+toc: true
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Changes to Facebook Login and Graph API
+ 
+The latest version of the Facebook Graph API changes what permissions and fields can be requested. We've updated Facebook Connections to reflect these changes and tweaked the connection interface for clarity.
+
+::: note
+[Facebook Login Changelog: Recent Changes to Facebook Login](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02)
+:::
+
+This update may not require changes to your code or configuration, but your application might receive additional profile data if the existing permissions allow it. But keep in mind that:
+
+* If your Facebook connection is configured to request one of the removed permissions, your Access Token will not get them in scope.
+* If your Facebook application is marked as "development" then you may still see an error temporarily while trying the connection.
+* If you add new permissions to the connection, end users will be prompted for consent next time they log in. See the Facebook documentation for how to handle actions for users that don't have a specific permission.
+ 
+## Facebook Login Permissions
+ 
+[Facebook Login permissions](https://developers.facebook.com/docs/facebook-login/permissions) are requested by your application when a user logs in using Facebook. If the user is logging in for the first time or if the permissions have changed, they will be shown a consent window in Facebook showing the new permissions requested. Once those permissions are granted, your application can then act on behalf of that user with a Facebook access token.
+ 
+The Facebook Connection interface has been updated to show both the regular name as well as the machine name for all permissions displayed. This makes it easier to find the permissions you need and map that to any code you might be running using these permission names.
+
+![Facebook Connection Permissions](/media/articles/connections/social/facebook/facebook-connection-permissions.png)
+ 
+### Permissions added
+ 
+The following permissions were added to the Facebook connection interface:
+
+- business_management
+- groups_access_member_info
+- leads_retrieval
+- pages_manage_instant_articles
+- publish_to_groups
+- publish_to_groups
+- user_age_range
+- user_gender
+- user_link
+ 
+### Permissions removed
+ 
+The following permissions were removed from the Facebook connection interface:
+ 
+- read_custom_friendlists
+- rsvp_event
+- user_about_me
+- user_actions-books
+- user_actions-fitness
+- user_actions-music
+- user_actions-news
+- user_actions-video
+- user_education_history
+- user_games_activity
+- user_relationship_details
+- user_relationships
+- user_religion_politics
+- user_website
+- user_work_history
+ 
+### Permissions moved to deprecated
+ 
+The following permissions were moved to the **Deprecated** section and should not be used with the latest version of the Graph API:
+ 
+- publish_actions
+- user_managed_groups
+ 
+## Facebook Graph API Fields
+ 
+The [Facebook Graph API](https://developers.facebook.com/docs/graph-api/reference/v3.2/user) is used after a user logs in to retrieve profile data for the Auth0 user. The user data permissions requested determine what information is retrieved from the Graph API. The fields that are returned depend on the permissions requested and the existence of those fields in the Facebook user profile.
+ 
+This change upgraded the Graph API from v2.8 to v3.2 and will ask for the following user data fields on login:
+ 
+- address (added)
+- age_range
+- birthday
+- context
+- cover
+- currency (added)
+- devices
+- email
+- favorite_athletes
+- favorite_teams
+- first_name
+- gender
+- hometown
+- id
+- inspirational_people
+- install_type (added)
+- installed
+- is_verified
+- languages
+- last_name
+- link
+- locale
+- location
+- meeting_for (added)
+- middle_name
+- name
+- name_format
+- picture
+- public_key (added)
+- quotes
+- security_settings (added)
+- short_name (added)
+- significant_other
+- sports (added)
+- third_party_id
+- timezone
+- updated_time
+- verified
+- video_upload_limits (added)
+- viewer_can_send_gift (added)
diff --git a/ja-jp/articles/migrations/guides/facebook-social-context.md b/ja-jp/articles/migrations/guides/facebook-social-context.md
new file mode 100644
index 0000000000..d3a06f3de5
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/facebook-social-context.md
@@ -0,0 +1,32 @@
+---
+title: 'Context' Facebook Field Deprecation
+public: false
+description: Facebook is removing access to the 'social context' field from their profile
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# 'Context' Facebook Field Deprecation
+
+On **July 30th 00:00 UTC**, Facebook connections that request the `context` field will fail, so Auth0 will stop requesting it for all connections at that time.
+
+On April 30th [Facebook deprecated]( https://developers.facebook.com/docs/graph-api/changelog/4-30-2019-endpoint-deprecations) the use of the ‘Social Context’ field for new applications. Auth0 continued to request that field by default for Facebook connections created before April 30th 2019. You can make sure the field is not requested before July 30th by unchecking the ‘Social context’ field in the User Data connection section:
+ 
+![facebook context](/media/articles/migrations/facebook-context.png)
+ 
+Once you uncheck ‘Social context’, the profile data will not include the context field. The field has the following content:
+ 
+```
+"context": {
+  "mutual_likes": {"data": [],"summary": {"total_count": 0}},
+  "id": "dXNlcl9...UZD"
+}
+```
+ 
+**Do I need to take any action?**
+ 
+If you are not using the ‘context’ field in the Facebook profile returned by Auth0 in your application, then your application will keep working without changes. Otherwise, you will need to adjust your application code so it does not rely on it.
+ 
+If you want to make sure your application is not affected on July 30th we recommend you to uncheck the ‘Social context’ field in the Facebook connection properties.
diff --git a/ja-jp/articles/migrations/guides/google_cloud_messaging.md b/ja-jp/articles/migrations/guides/google_cloud_messaging.md
new file mode 100644
index 0000000000..3b8e862174
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/google_cloud_messaging.md
@@ -0,0 +1,27 @@
+---
+title: Google Cloud Messaging Deprecation
+description: This article describes how you can migrate your applications based on the Android Guardian SDK to Firebase Cloud Messaging
+public: false
+contentType:
+  - concept
+  - how-to
+useCase:
+  - customize-mfa
+  - migrate
+---
+# Migration to Firebase Cloud Messaging
+
+Auth0’s Guardian SDKs for iOS and Android helps you create custom Mobile apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. 
+
+The Android SDK library was built to send Push Notifications using Google Cloud Messaging, which [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced with Firebase Cloud Messaging. Google Cloud Messaging will stop working on April 11th 2019. **Note that existing applications should [keep working as-is](https://aws.amazon.com/blogs/messaging-and-targeting/the-end-of-google-cloud-messaging-and-what-it-means-for-your-apps/)**.
+
+You can learn more about how to migrate from GCM to FCM check [Google’s documentation](https://developers.google.com/cloud-messaging/android/android-migrate-fcm).
+
+The main difference between how you send notifications to GCM and FCM is in the payload received in the notification. While it was possible for existing customers using the Android SDK to adapt the payload received before calling the SDK method, we have upgraded the library so it accepts the new payload, making it simpler to adopt FCM. More details [here](https://github.com/auth0/Guardian.Android/pull/84).
+
+The Guardian Android SDK 0.4.0 version is already available in Maven Central and includes this change. The sample application was also upgraded, so it can be tested by providing the google-services.json file and a guardian-url. 
+
+You can check the updated documentation for the [Guardian Android SDK](/mfa/guides/guardian/guardian-android-sdk).
+
+
+
diff --git a/ja-jp/articles/migrations/guides/instagram-deprecation.md b/ja-jp/articles/migrations/guides/instagram-deprecation.md
new file mode 100644
index 0000000000..d801742b37
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/instagram-deprecation.md
@@ -0,0 +1,40 @@
+---
+title: Instagram Connection Deprecation
+description: Instagram is deprecating their Authentication API
+toc: true
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Instagram Connection Deprecation
+
+Facebook [announced](https://developers.facebook.com/blog/post/2019/10/15/launch-instagram-basic-display-api/) that on March 31th, 2020, they will turn off the Instagram legacy APIs in favor of a new set of APIs:
+
+- The [Instagram Graph API](https://developers.facebook.com/docs/instagram-api) which is designed for Instagram Professional Accounts, not for end-user authentication.
+- The [The Instagram Basic Display API](https://developers.facebook.com/docs/instagram-basic-display-api), which is an OAuth2 API, and enables you to grant access to your basic Instagram account data to a third-party app.
+
+Even if it is a common industry practice to use OAuth2 as an authentication API, Facebook is explicitly forbidding using it as such, requiring applications to implement Facebook Login for authentication. Facebook will not approve applications that use the Instagram Basic Display API for authentication.
+
+In order to let existing users continue to access your application, you will need to ask users that are authenticating using Instagram to authenticate in a different way, and use [Account Linking](/link-accounts) to link the new identity with the old one. 
+
+An example flow would be:
+
+- The user authenticates with Instagram.
+- The application tells the user that they won't be able to authenticate with Instagram anymore, and that they should do it in a different way.
+- The application lists the options the user has for authentication, for example:
+    - Facebook
+    - Username and Password
+- After the user authenticates in a different way, you link the accounts using [Account Linking](/link-accounts).
+
+## Why can't Auth0 use the Instagram Basic Display OAuth endpoint
+
+While we could replace our current implementation and use the [Instagram Basic Display OAuth flow](https://developers.facebook.com/docs/instagram-basic-display-api/guides/getting-access-tokens-and-permissions), this would not be accepted by Facebook's policies. You would need to create an Instagram application in Facebook and, in that app, there's a notification saying:
+
+> Note that Basic Display is not an authentication tool. Data returned by the API cannot be used to authenticate your app users or log them into your app. If your app uses API data to authenticate users, it will be rejected during App Review. If you need an authentication solution, use Facebook Login instead.
+
+This means that even if Auth0 implemented this flow, your Instagram application would not be approved by Facebook.
+
+If you need to access Instagram data, you will need to authenticate your user in other way (for example, using Facebook Login or username/password), and implement the Instagram OAuth flow in your application.
+
diff --git a/ja-jp/articles/migrations/guides/legacy-lock-api-deprecation.md b/ja-jp/articles/migrations/guides/legacy-lock-api-deprecation.md
new file mode 100644
index 0000000000..5398d83618
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/legacy-lock-api-deprecation.md
@@ -0,0 +1,175 @@
+---
+title: Legacy Lock API Deprecation
+description: This article covers the Legacy Lock API deprecation and gives direction as to migration paths and changes required.
+toc: true
+public: false
+contentType:
+  - concept
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Legacy Lock API Deprecation
+
+On April 4, 2018, Auth0 publicly disclosed a vulnerability. That vulnerability resulted in the deprecation of two endpoints in the Auth0 API, and the libraries and SDKs which used those endpoints. These endpoints were disabled on **July 16, 2018**, beginning a [brief grace period](https://community.auth0.com/t/soft-removal-of-legacy-lock-api/12949) in which usage of the endpoints could be re-enabled on a per-tenant basis until a migration could be completed. The endpoints have been removed from service as of **August 6, 2018**.
+
+The purpose of this guide is to help you to select the best migration path for your application(s) if you are impacted by the deprecation. 
+
+## Am I affected?
+
+If your applications match any of the following cases, you are affected:
+
+* Use of versions of Lock previous to v11 and versions of Auth0.js previous to v9 in embedded login scenarios
+* Use of /usernamepassword/login endpoint directly from applications 
+* Use of /user/ssodata endpoint directly from applications
+
+If you do not use the above libraries and do not specifically call the above endpoints, you are not affected. No libraries which are not specifically named are affected by this vulnerability, or in turn, by the migration.
+
+### If you already use Universal Login / Hosted Login Page
+
+Applications which log users in via Universal Login through an Auth0-hosted page are not _required_ to update the version of Lock or Auth0.js that they use _inside_ that login page (if you have customized your login page in the [Dashboard](${manage_url}/#/login_page). However, the use of the newest library versions is strongly recommended, even in the Universal Login Page. For those who have not customized their login page, the Lock v11 widget is already in use and no further action is required.
+
+### If you use embedded login
+
+Embedded login with Lock v11 and Auth0.js v9 now rely entirely on [cross-origin authentication](/cross-origin-authentication) for any form of username/password authentication (such as Auth0 DB, Custom DB, or LDAP connections). Cross-origin authentication is the situation in which credentials are collected on one domain, but validated on another.
+
+This cross-origin authentication protocol relies on cookies, which will be considered third-party cookies if the domain of the application and Auth0 tenant do not match. Unfortunately, some browsers block third-party cookies, and even if supported, many users may have manually disabled third-party cookies in their browsers. 
+
+Because of these [cross-origin authentication issues](/cross-origin-authentication#limitations), there are only two general implementations that can be recommended. 
+
+1. [Migrate to Universal Login](#1-migrate-to-universal-login). Universal Login will work with or without [custom domains](/custom-domains), and will work from most application types as well. It requires the least application code to implement and is the most secure option. 
+
+2. [Continue to use embedded login and migrate to newer library versions](#2-continue-to-use-embedded-login-and-migrate). A crucial part of this implementation is employing a custom domain to prevent cross-origin issues. The following caveats apply:
+    * Only one custom domain can be applied per Auth0 tenant, so all applications on the tenant will use the same custom domain (they will need to use the same top-level domain as well).
+    * This option may not be viable for customers who are not eligible to use custom domains, or who choose not to do so. In those cases, Universal Login is the best approach.
+
+<%= include('../../_includes/_embedded_login_warning') %>
+
+If neither of these recommendations (Universal Login or embedded + custom domains) seem to work for your situation, please visit our [Support Center](${env.DOMAIN_URL_SUPPORT}) and file a support ticket or a community post for further guidance.
+
+## What do I do?
+
+All applications _must_ stop using the deprecated endpoints / library versions, as they have been removed from service as of August 6, 2018. Applications using those endpoints will no longer function correctly. There are two options for migration:
+
+### 1. Migrate to Universal Login
+
+Universal Login is **strongly** recommended for most use cases because it [offers many advantages](/guides/login/universal-vs-embedded) over the embedded form of login screen. These advantages include:
+
+* Developed, hosted and maintained by Auth0 (less maintenance required by your team).
+* Provides a single place to make changes.
+* More secure because credentials are collected and verified within the same domain. This reduces exposure of static credentials to multiple applications as well as the possibility of CSRF and man-in-the-middle attacks.
+* Provides reliable Single Sign-on (SSO) functionality without relying on third-party cookies or restricting the domain of applications.
+* Fully customizable in terms of colors, text, logos, buttons as well as [custom domain](/custom-domains).
+* Provides proper cache control to avoid browsers caching old versions.
+* Can leverage either the [Lock Widget](/libraries/lock) or [Auth0.js SDK](/libraries/auth0js) for flexibility in appearance and function.
+* Works with any type of Auth0 connection as well as multi-factor authentication (MFA).
+
+#### Universal Login migration guides
+
+
+
+### 2. Continue to use embedded login and migrate
+
+Embedded login (embedding Lock or a custom authentication UI) should be used only if the Universal Login Page **cannot** be used. If you intend to continue using embedded login, you **must** upgrade applications from deprecated library versions.
+
+#### Embedded login migration guides
+
+
      
+  
    • 
+     Auth0.js v9 Migration Guide
+    
      
+      This document presents an overview of the updates to Auth0.js in version 9 and points to technology and version-specific tutorials to help you with your migration.
+    
      
+  
      • 
+
    
+
+Continued use of embedded login will require the use of [custom domains](/custom-domains) in order to prevent cross-origin authentication issues. The custom domains documentation includes important information on the use of custom domains, how to set them up, and what configuration is required for more intricate use cases, such as custom domains with SAML.
+
+## Other considerations
+
+A few specific items are changing with the new versions / endpoints. If you use any of the following features, you might want to take a look at the corresponding section below.
+
+* [How to get user info](#how-to-get-user-info)
+* [How to check for an existing session](#session-management)
+* [How to log users out](#how-to-log-users-out)
+
+## How to get user info
+
+Once a user has been authenticated, an application may wish to retrieve information about a user. The recommended way to do this now is via the [/userinfo](/api/authentication#get-user-info) endpoint. If you are using Auth0.js v8 or v9 and using the [userInfo()](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) method, you already have made this change.
+
+For customers who are using the [/tokeninfo](/api/authentication#get-token-info) endpoint, this endpoint is being replaced with the /userinfo endpoint. Customers should migrate to use the /userinfo endpoint instead of /tokeninfo. The /userinfo endpoint is the only one that will be maintained going forward and is the only endpoint for user information that is supported with the [custom domains](/custom-domains) feature.
+
+As explained in the /userinfo endpoint docs entry, /userinfo obtains information using the Management API and therefore requires an Access Token (obtained during login) instead of the [ID Token](/tokens/concepts/id-tokens) used by /tokeninfo.
+
+Note also that the [/userinfo response](/api-auth/tutorials/adoption/scope-custom-claims) may vary based on scopes requested and the value of the [OIDC Conformant](/api-auth/tutorials/adoption/oidc-conformant) setting in the [Dashboard](${manage_url}) under **Applications > (Your Application) > Settings > Advanced Settings**. In that case, application code might need adjusted to handle the slightly altered response format.
+
+### Session management
+
+#### Single-Page Applications
+
+If a user navigates to a new page in a Single-Page Application, your application may wish to check if a user already has an existing session. In order to do this, you may have directly called the /ssodata endpoint or utilized the `getSSOData()` function in Auth0.js v8 or prior. The /ssodata endpoint is deprecated and was removed from service on **August 6, 2018**. The `getSSOData()` function will continue to work, but will behave differently, and in most cases, can be replaced with use of `checkSession()`.
+
+::: note
+The `getSSOData()` and `checkSession()` functions should only be used from a Single-Page Application
+:::
+
+##### checkSession()
+
+* The Auth0.js `checkSession()` function can be used to check whether or not a user has an existing session in Auth0.
+* Invoking the `checkSession()` function will trigger an /authorize call, which will in turn result in the execution of [rules](/rules).
+* The new `checkSession()` function is more lightweight and should be used as a replacement for `getSSOData()` unless `getSSOData()` features are needed.
+
+##### getSSOData()
+
+* The Auth0.js v9 `getSSOData()` function will continue to work, but it now behaves differently than in the past.
+* In Auth0.js v9, `getSSOData()` will check if a user has an existing session and perform a further check to determine if the user is the same one as in the last interactive authentication transaction. This supports Lock’s feature of showing the last logged-in user to facilitate subsequent logins.
+* Invoking the `getSSOData()` function will now trigger a call to the [/authorize](/api/authentication#authorize-application) endpoint, which will in turn result in the execution of [rules](/rules).
+
+##### Polling for an existing session
+
+<%= include('../../_includes/_checksession_polling') %>
+
+This was previously done with `getSSOData()`. The `getSSOData()` function performs more work behind the scenes than is needed for this purpose and applications that are not switched to `checkSession()` will suffer a needless performance penalty.
+
+#### Web applications
+
+In "web applications", the backend typically has a session for the user. Over time, the application session may expire, in which case the application should renew the session. The application backend should invoke a call to the [/authorize](/api/authentication#authorize-application) endpoint to get a new token. If the Authorization Server (Auth0 in this case) still has a session for the user, the user will not have to re-enter their credentials to log in again. If Auth0 no longer has a session for the user, the user has to log in again.
+
+Customers with web applications which call the API from their backend should use this approach. Specifically, they should [call /oauth/token](/tokens/guides/use-refresh-tokens) to renew their token.
+
+### How to log users out
+
+The deprecation does not require any changes for [logout](/logout), but if a custom domain has been configured and is used when invoking authentication, the /logout endpoint should be invoked using the custom domain as well.
+
+### Using Lock with AD/LDAP and Kerberos
+
+If your application is using Lock in embedded mode with the goal of detecting IP ranges with AD/LDAP + Kerberos, this will no longer work.
+
+The solution for the Kerberos case is to [migrate to Universal Login](#1-migrate-to-universal-login). Lock will no longer attempt to detect an IP range by itself when embedded in an application. However, when using Universal Login with Lock inside your hosted login page, it will use the /user/ssodata endpoint (which still works from within the login page), and that endpoint will still return “true” when the user is in the Kerberos IP range. That means that using Universal Login you can:
+
+* Use `getSSOData()` to achieve an automatic login
+* Use Lock and get the **Use Windows Authentication** button (log in with Kerberos).
+
+## Troubleshooting
+
+See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors.
diff --git a/ja-jp/articles/migrations/guides/linkedin-api-deprecation.md b/ja-jp/articles/migrations/guides/linkedin-api-deprecation.md
new file mode 100644
index 0000000000..011ba33906
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/linkedin-api-deprecation.md
@@ -0,0 +1,54 @@
+---
+title: Migration to LinkedIn API V2
+description: This article covers the LinkedIn API deprecation and how to update your Auth0 LinkedIn Connection.
+toc: true
+public: false
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Migration to LinkedIn API V2
+
+In December 2018, LinkedIn [deprecated version 1.0 of their sign-in API](https://engineering.linkedin.com/blog/2018/12/developer-program-updates). The final shutdown date we set for March 1st, 2019 then moved to May 1st, 2019. In June 2019, the current status is that "Applications requesting Version 1.0 APIs may experience issues as we begin to remove services."
+
+LinkedIn replaced the sign-in API with [version 2.0, which has some key differences](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq?context=linkedin/consumer/context).
+
+We've added the option to set the LinkedIn API version for LinkedIn Connections. You can change the API version for a LinkedIn Connection through the Auth0 Dashboard by selecting a **Strategy Version** under the connection's settings.
+
+![New LinkedIn Connection Settings](/media/articles/connections/social/linkedin/linkedin-connection-new.png)
+
+Auth0 will not automatically migrate all connections to Version 2 until Version 1 stops working completely. We strongly recommend that you update your connection settings to Version 2. You may need to update your application code to accommodate these API changes.
+
+## What's changed?
+
+There are changes in the user attributes you can request.
+
+For version 1.0 we exposed these attributes:
+
+| **Auth0 Attribute**| **Linkedin Scope**|
+|----------------|---------------|
+| Profile|  r_basicprofile|
+| Full Profile  | r_fullprofile|
+| Network   | r_network|
+| Email | r_emailaddress|
+
+For version 2.0 we expose these options:
+
+| **Auth0 Attribute**| **Linkedin Scope**|
+|----------------|---------------|
+|Profile|   r_liteprofile|
+|Basic Profile| r_basicprofile|
+|Email| r_emailaddress|
+
+As you can see version 2.0:
+
+* Adds support for the `r_liteprofile` scope
+* Removes support for the `r_fullprofile` and `r_network` scopes
+* Supports the `r_basicprofile` scope only for clients that are part of [LinkedIn’s Developer Enterprise](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq#what-are-the-main-differences-with-the-new-sign-in-with-linkedin) services.
+
+::: note
+Not all applications registered with LinkedIn can access their new API. For more details, check [Microsoft’s documentation](https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq#does-my-developer-application-have-access-to-the-linkedin-v2-api).
+:::
diff --git a/ja-jp/articles/migrations/guides/liveid-api-deprecation.md b/ja-jp/articles/migrations/guides/liveid-api-deprecation.md
new file mode 100644
index 0000000000..bdf60569cf
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/liveid-api-deprecation.md
@@ -0,0 +1,118 @@
+---
+title: Microsoft Account Migration
+description: This article covers the Live Connect + SDK deprecation and how to update your Auth0 Microsoft Account Connection.
+toc: true
+public: false
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Microsoft Account Migration to Azure AD (personal accounts) + Microsoft Graph
+
+In October 2017, Microsoft announced the [deprecation of the Live Connect API and Live SDK](https://developer.microsoft.com/en-us/office/blogs/outlook-rest-api-v1-0-office-365-discovery-and-live-connect-api-deprecation). This is a Microsoft deprecation that will affect Auth0 users using the Microsoft social connection. The change implies switching how Auth0 interacts with the Microsoft authentication APIs, and it might imply changes in customers application's code.
+
+The change implies switching:
+
+- From the Live Connect API to the Azure Active Directory v2 and OIDC protocol for Microsoft Account authentication
+- From the Live SDK to Microsoft Graph to be able to get other resources including user profiles, contacts, files, etc
+
+Note that even though Azure AD is used, this connection type will only accept personal accounts. For work or school accounts you should use the enterprise Azure AD connection type.
+
+You can decide if Auth0 uses Live Connect + Live SDK or Azure AD + Microsoft Graph using the 'Strategy Version' field in the Microsoft Account connection settings page. 
+
+![New Microsoft Connection Settings](/media/articles/connections/social/microsoft-account/microsoft-account-azureid.png)
+
+You need to switch to 'Azure AD (personal accounts)' to ensure your applications will keep working after Microsoft decommissions the API.
+
+**Microsoft Application Registration**
+
+Depending on when you created your Live SDK application, it might or not support Azure Active Directory v2. If it's not supported, you will need to create a different application and update your Client ID and Client Secret in the Auth0 Microsoft connection settings. As a rule, if your Client ID looks like `00000000400FFF55`, you'll need to create a new application. 
+
+For more information, check [Microsoft's documentation](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-registration-portal).
+
+
+**User Profile**
+
+Microsoft Graph provides different user profile information compared to the Live Connect and Live SDK user profile. In particular, some of the user profile fields that were previously available are not available anymore:
+ 
+
+***OIDC Profile***
+
+| Field  |  Live SDK |  Microsoft Graph  |
+|--------|---------------|------------------|
+|  picture | Returned a URL for the user picture | Auth0 will build a URL that will return a default picture for the user based on their initials |
+| locale | Returned a string in the format en_US | Not available |
+
+***Raw Profile***
+
+The raw user profile that can be obtained calling the [Get User By Id Endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) has several differences when using Live SDK or Microsoft Graph.
+
+The JSON below shows the fields that are in the Live SDK profile but are not present, or are different, in the Microsoft Graph one:
+
+```js
+{
+    "locale": "en_ZA",
+    "work": [],
+    "emails": [
+        "john.doe@windowslive.com"
+    ],
+    "addresses": {
+        "personal": {
+            "street": null,
+            "street_2": null,
+            "city": null,
+            "state": null,
+            "postal_code": null,
+            "region": null
+        },
+        "business": {
+            "street": null,
+            "street_2": null,
+            "city": null,
+            "state": null,
+            "postal_code": null,
+            "region": null
+        }
+    },
+    "phones": {
+        "personal": null,
+        "business": null,
+        "mobile": null
+    },
+    "nickname": "john.doe@windowslive.com",
+   ]
+}
+```
+
+This other one shows the fields that are in the Microsoft Graph profile but are not present, or are different, in the Live SDK one one:
+
+```js
+{
+    "strategy_version": 2,
+    "displayName": "John Doe",
+    "userPrincipalName": "john.doe@windowslive.com",
+    "businessPhones": [],
+    "nickname": "john.doe",
+}
+```
+
+Key differences are:
+
+- `strategy_version` has the value `1` when the user last logged-in with Live Connect, or `2` when they last logged in with Azure AD.
+- `nickname` has a different format. 
+- `locale`, `work`, `emails` array, `addresses`, `phones` are present in Live SDK but not in Microsoft Graph.
+- `displayName`, `userPrincipalName`, `businessPhones` array are present in Microsoft Graph but not in Live SDK.
+
+If a user that has previously logged in with Live Connect logs in with AzureAD, the profiles will be merged. The new profile will have both the content of the Live ID profile plus the fields from the Microsoft Graph profile.
+
+The `strategy_version` will be set to '2' for users that last logged in with Azure AD, to '1' for users that logged in with Live Connect recently, and will not be present for users that did not login recently. You can use this field to better interpret the profile content.
+
+Note that the `user_id` field will be the same regardless of the API used to connect with Microsoft, even if you had to create another application to use Azure Active Directory v2.
+ 
+**Permissions**
+
+Auth0 lets you select which permissions you want to ask from the Microsoft Graph APIs. The ones that Live SDK and Microsoft Graph support might provide similar functionality, but the data returned by them and their format may be completely different. See [Migrating from Live SDK - Permissions](https://docs.microsoft.com/en-us/onedrive/developer/rest-api/concepts/migrating-from-live-sdk?view=odsp-graph-online#permissions) to understand what changes are required in your code.
+
diff --git a/ja-jp/articles/migrations/guides/management-api-v1-v2.md b/ja-jp/articles/migrations/guides/management-api-v1-v2.md
new file mode 100644
index 0000000000..65ea5d6bfb
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/management-api-v1-v2.md
@@ -0,0 +1,108 @@
+---
+title: Migrate from Management API v1 to v2
+description: Learn how to migrate from Auth0 Management API v1 to v2.
+topics:
+  - management api
+contentType:
+  - concept
+  - how-to
+useCase:
+  - management api
+---
+# Migrate from Management API v1 to v2
+
+Auth0’s Management API v1 was deprecated in 2016 and replaced with the [Auth0 Management API v2](/api/management/v2/). Management API v1 will reach its End Of Life in the Public Cloud on **July 13th, 2020**. Requests will begin failing with a `410` HTTP status code on or after that date. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1.
+
+## Key Dates
+
+The following are key dates for this migration:
+
+| Date | Public Cloud | Private Cloud |
+|------|--------------|---------------|
+| Jan 13, 2020 | Initial Public Announcement | N/A | 
+| May 21, 2020 | N/A | Initial Public Announcement |
+| July 13, 2020 | End of Life for Management API v1 | N/A |
+| November 2020 | N/A | Support removed from release for Mgmt API V1 |
+
+## Am I affected by the migration?
+
+Affected tenants are those who meet all of the following criteria:
+
+* Created before January 2, 2020
+* Actively making requests to Auth0 endpoints directly under the `/api/` path from your application.
+
+The following tenants are NOT affected:
+
+* Created after January 2, 2020
+* Exclusively using the Auth0 Management API v2 endpoints
+* Using the Authentication API exclusively, the Authentication API is not affected by this deprecation.
+
+## How can I check to see if I've migrated all my requests?
+
+Deprecation Notices will be recorded in your Tenant Logs for requests that will fail at API v1’s End of Life. You can search for relevant Deprecation Notices in your tenant logs with the following query:
+
+```
+type:depnote AND description:*APIv1*
+```
+
+::: note
+**Private Cloud Customers**
+
+- You must be running release [2003](https://auth0.com/releases/2003) or later to see Deprecation Notices.
+
+- If searching tenant logs from the Dashboard, search for `type:depnote`. Searching by `description` is not currently supported in the tenant logs search available in the Dashboard. If you [export your logs to an external service](/extensions#logs-export), you can leverage it to query for APIv1 Deprecation Notices using a combination of `type` and `description`.
+:::
+
+![Management API Version 1 Log Query](/media/articles/migrations/apiv1-log-query.png)
+
+To help identify the Application making requests, logs will include the `client_id` used to make the request. You can also find the endpoint being used in the logs `details.path` field.
+
+Note that our current SDKs all use Management API v2. If you're seeing API v1 activity from an Application that is leveraging an older SDK, you should upgrade to the latest version.
+
+![Management API Versiion 1 Log Example](/media/articles/migrations/apiv1-log-example.png)
+
+::: note
+Auth0 generates only one log for each `client_id` and `details.path` combination every 60 minutes. No matter how many calls you make to the deprecated endpoints, you will still see a single log per hour for *each* deprecated endpoint an application calls.
+
+If you implement changes to your requests, you'll need to allow 60 minutes to elapse before you can conclusively determine that the lack of new `depnote` logs means the deprecated endpoints have been removed from your code.
+:::
+
+## What’s changing?
+
+For a complete list of breaking changes associated with this deprecation, see [Management API v2 Changes](/api/management/v2/changes).
+
+## How do I migrate?
+
+After replacing all calls to the Management API v1 with their [Management API v2 replacements](/api/management/v2/changes), you should confirm you are no longer seeing Deprecation Notices in your Tenant Logs and **disable the Management API v1 for your tenant.**
+
+You can disable API v1 by going **Tenant Settings** > **Advanced** > **Migration** in the [Auth0 Dashboard](http://manage.auth0.com/). This will simulate the expected behavior after the End of Life date, causing calls to API v1 to fail with a `410` HTTP status code. You will be able to re-enable API v1 any time before the End of Life date.
+
+By migrating your requests to API v2 and disabling API v1 as soon as possible, you will ensure that your systems will continue to operate uninterrupted after the **July 13th, 2020** End of Life date, at which time the option to enable API v1 will be removed.
+
+![Toggle Management API Version](/media/articles/migrations/apiv1-toggle.png)
+
+::: note
+Note that tenants created after January 2, 2020 will not have access to API v1. If you need API v1 enabled on a tenant for testing your migration, please open a ticket in our [Support Center](https://support.auth0.com/tickets).
+:::
+
+If you need help with the migration, contact us using the [Support Center](https://support.auth0.com/) or our [Community Site](https://community.auth0.com/c/auth0-community/Migrations).
+
+## Auth0 AD/LDAP Connector Health Monitor extension
+
+The [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector) extension v1 uses the API v1 `GET /api/connections/{connection-name}` and `GET /api/connections/{connection-name}/socket` endpoints.
+
+Please upgrade to the latest version of the extension before disabling API v1 support.
+
+## SharePoint Integration Custom Claims Provider
+
+The Custom Claims Provider of the [Auth0 SharePoint Integration](https://auth0.com/docs/integrations/sharepoint) leverages three API v1 endpoints : `/api/enterpriseconnections/users`, `/api/socialconnections/users`, and `/api/connections`.
+
+If you are calling these endpoints from the SharePoint integration, they will continue to work after the API v1 End of Life date. You may continue see `depnote` tenant logs for this activity. If the `client_id` in the tenant log is a SharePoint application, you can disregard this warning. 
+
+If you are calling these endpoints directly from your code, you will need to migrate those calls off of API v1.
+
+## Keep reading
+
+* [Complete list of changes](/api/management/v2/changes)
+* [Management APIv1 documentation](/api/management/v1)
+* [Management APIv2 documentation](/api/management/v2)
diff --git a/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md b/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md
new file mode 100644
index 0000000000..2af6b0ea4e
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken-pwdless.md
@@ -0,0 +1,121 @@
+---
+title: Migration Guide for Resource Owner Passwordless Authentication
+description: Learn how to migrate your Passwordless API calls and responses from /oauth/ro to /oauth/token
+toc: true
+contentType:
+  - concept
+useCase:
+  - secure-an-api
+  - migrate
+---
+# Migration Guide for Resource Owner Passwordless Credentials Exchange
+
+Support for Resource Owner Password was added to [/oauth/token](/api/authentication#authorization-code). Usage of the [/oauth/ro](/api/authentication#resource-owner) endpoint was deprecated on July 08, 2017. This endpoint was used to exchange an OTP received by the end-user by email or SMS with for an `id_token` and an `access_token`. 
+
+We have implemented a new API that replaces `oauth/ro` for this use case, and we recommend customers to migrate to the new implementation.
+
+## Does this affect me ?
+
+This change affects you if you use the resource owner passwordless credentials exchange and call `/oauth/ro` directly without the use of any Auth0 libraries or SDKs. 
+
+<%= include('./_forced-logouts.md') %>
+
+## Changes to requests
+
+Previously, the payload of a request to `/oauth/ro` looked similar to this:
+
+```json
+{
+  "grant_type": "password",
+  "client_id": "123",
+  "username": "alice",
+  "password": "A3ddj3w", 
+  "connection": "my-database-connection",
+  "scope": "openid email favorite_color offline_access",
+  "device": "my-device-name"
+}
+```
+
+These are the changes for the new implementation:
+
+* The endpoint to execute token exchanges is now `/oauth/token`
+* [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (or `realm`). 
+* Auth0 supports the [standard OIDC scopes](/scopes/current/oidc-scopes), along with the scopes which you have defined in your [custom API](/api-auth/apis).
+* A scope that does not fit in one of these categories, such as the above `favorite_color`, is no longer a valid scope.
+* The `device` parameter is removed.
+* The `audience` parameter is optional.
+
+Here is an example of the payload of a request to `/oauth/token`:
+
+```json
+{
+  "grant_type" : "http://auth0.com/oauth/grant-type/passwordless/otp",
+  "client_id": "YOUR_CLIENT_ID",
+  "client_secret": "YOUR_CLIENT_SECRET", // only for web apps, native apps don’t have a client secret
+  "username": "", // or ""
+  "otp": "CODE",
+  "realm": "email", // or "sms" 
+  "audience" : "your-api-audience", // in case you need an access token for a specific API
+  "scopes": "openid profile email" // whatever scopes you need
+}
+```
+
+* The grant type is specified here as `http://auth0.com/oauth/grant-type/passwordless/otp`
+* The parameters `client_id` and `username` are unchanged.
+* The `client_secret` needs to be specified for confidential clients (e.g. regular web apps).
+* The one-time password needs to be sent in the `otp` parameter instead of the `password` parameter.
+* The `realm` is used to identify the connection, and replaces the `connection` parameter from previous calls.
+* The `scope` parameter is mostly the same, but does not accept non-OIDC values.
+* The `audience` parameter can be added, indicating the API audience the token will be intended for.
+
+## Changes to responses
+
+Responses from `/oauth/ro` were similar in format to the following:
+
+```json
+{
+  "access_token": "SlAV32hkKG",
+  "token_type": "Bearer",
+  "refresh_token": "8xLOxBtZp8",
+  "expires_in": 3600,
+  "id_token": "eyJ..."
+}
+```
+
+* The returned Access Token is valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) (provided that the API specified by the `audience` param uses RS256 as [signing algorithm](/tokens/concepts/signing-algorithms)) and optionally the [custom API](/api-auth/apis) if one was specified.
+* The ID Token will be forcibly signed using RS256 if requested by a [public client](/clients/client-types#public-clients).
+* A Refresh Token will be returned only if the `offline_access` scope was granted and the API has **Allow offline access** set.
+
+Here is an example of the response from `/oauth/token`:
+
+```json
+{
+  "access_token": "eyJ...",
+  "token_type": "Bearer",
+  "refresh_token": "8xLOxBtZp8",
+  "expires_in": 3600,
+  "id_token": "eyJ..."
+}
+```
+
+## Code changes when using the SDKs
+
+If your application uses the Auth0 native libraries for Android or iOS, be sure that the version of the library you are including is at least the minimum listed below (or higher). Also, be sure to set the 'OIDC Conformant' flag to `true` when configuring the libraries.
+
+|Library|Minimum Version|
+|---|---|
+|[Android SDK](/libraries/auth0-android/passwordless)|1.2| 
+|[Lock Android](/libraries/lock-android/passwordless)|2.17|
+|[Swift SDK](/libraries/auth0-swift/passwordless)|1.20.0|
+|[Lock iOS](/libraries/lock-ios/passwordless)|2.14.0|
+
+## Verifying your migration
+
+Once you have migrated your codebase, if you would like to be sure that your applications are no longer calling the legacy endpoint.
+
+You can verify whether you are still using the deprecated endpoint by checking the [tenant logs](${manage_url}/#/logs), filtering by "Deprecation Notice" and check for logs saying "oauth/ro passwordless: This feature is being deprecated". You can also perform this search directly with the following query: `type:depnote AND description:*passwordless*`.
+
+Once you made sure your applications are not calling the endpoint, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy `/oauth/ro` Endpoint switch. Turning off this switch will disable the deprecated endpoint for your tenant, preventing it from being used at all.
+
+![Legacy Migration Toggles](/media/articles/libraries/lock/migration-toggles.png)
+
diff --git a/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken.md b/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken.md
new file mode 100644
index 0000000000..cf4d290c1f
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/migration-oauthro-oauthtoken.md
@@ -0,0 +1,102 @@
+---
+title: Migration Guide for Resource Owner Password Credentials Exchange
+description: Learn how to migrate your API calls and responses from /oauth/ro to /oauth/token
+toc: true
+contentType:
+  - concept
+useCase:
+  - secure-an-api
+  - migrate
+---
+# Migration Guide for Resource Owner Password Credentials Exchange
+
+Support for Resource Owner Password was added to [oauth/token](/api/authentication#authorization-code). Usage of the [oauth/ro](/api/authentication#resource-owner) endpoint was deprecated on July 08, 2017.
+
+## Does this affect me ?
+
+This change affects you if you use the resource owner password credentials exchange, and call `/oauth/ro` directly, without the use of any Auth0 libraries or SDKs. The major Auth0 libraries such as [Lock](/libraries/lock) or [Auth0.js](/libraries/auth0js) have already been updated to stop using /oauth/ro internally. If you use the `lock-passwordless` library, you can now use [Passwordless Mode](/libraries/lock/v11#passwordless) in Lock v11 instead.
+
+<%= include('./_forced-logouts.md') %>
+
+## Changes to requests
+
+Previously, the payload of a request to /oauth/ro looked similar to this:
+
+```json
+{
+  "grant_type": "password",
+  "client_id": "123",
+  "username": "alice",
+  "password": "A3ddj3w",
+  "connection": "my-database-connection",
+  "scope": "openid email favorite_color offline_access",
+  "device": "my-device-name"
+}
+```
+
+* The endpoint to execute token exchanges is now /oauth/token
+* [Auth0's own grant type](/api-auth/tutorials/password-grant#realm-support) is used to authenticate users from a specific connection (or `realm`). 
+* Auth0 supports the [standard OIDC scopes](/scopes/current/oidc-scopes), along with the scopes which you have defined in your [custom API](/api-auth/apis).
+* A scope that doesn't fit in one of these categories, such as the above `favorite_color`, is no longer a valid scope.
+* The `device` parameter is removed.
+* The `audience` parameter is optional.
+
+Here is an example of the payload of a request to /oauth/token:
+
+```json
+{
+  "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
+  "client_id": "123",
+  "username": "alice",
+  "password": "A3ddj3w",
+  "realm": "my-database-connection",
+  "scope": "openid email offline_access",
+  "audience": "https://api.example.com"
+}
+```
+
+* The grant type is specified here as `password-realm`, rather than the standard `password`. 
+* The parameters `client_id`, `username`, and `password` are unchanged. 
+* The `realm` is included because we are using Password Realm grant type, and replaces the `connection` parameter from previous calls. 
+* The `scope` parameter is mostly the same, but does not accept non-OIDC values. 
+* The `audience` parameter can be added, indicating the API audience the token will be intended for.
+
+## Changes to responses
+
+Responses from `oauth/ro` were similar in format to the following:
+
+```json
+{
+  "access_token": "SlAV32hkKG",
+  "token_type": "Bearer",
+  "refresh_token": "8xLOxBtZp8",
+  "expires_in": 3600,
+  "id_token": "eyJ..."
+}
+```
+
+* The returned Access Token is valid for calling the [/userinfo endpoint](/api/authentication#get-user-info) (provided that the API specified by the `audience` param uses RS256 as [signing algorithm](/tokens/concepts/signing-algorithms)) and optionally the [custom API](/api-auth/apis) if one was specified.
+* The ID Token will be forcibly signed using RS256 if requested by a [public client](/clients/client-types#public-clients).
+* A Refresh Token will be returned only if the `offline_access` scope was granted and the API has **Allow offline access** set.
+
+Here is an example of the OIDC conformant response from `oauth/token`:
+
+```json
+{
+  "access_token": "eyJ...",
+  "token_type": "Bearer",
+  "refresh_token": "8xLOxBtZp8",
+  "expires_in": 3600,
+  "id_token": "eyJ..."
+}
+```
+
+### Verifying your migration
+
+Once you have migrated your codebase, if you would like to be sure that your applications are no longer calling the legacy endpoint, you can go to the [Dashboard](${manage_url}/#/tenant/advanced) under **Tenant Settings > Advanced** then scroll down to **Migrations** and toggle off the Legacy /oauth/ro Endpoint switch. Turning off this switch will disable the deprecated endpoint for your tenant, preventing it from being used at all.
+
+![Legacy Migration Toggles](/media/articles/libraries/lock/migration-toggles.png)
+
+If turning this switch off results in failed logins, this is a sign that you have yet to completely remove all instances of legacy code from your applications.
+
+Once migrations have been successfully performed in production environments, the switch can be toggled off and left off, to ensure that the deprecated features can no longer be used.
\ No newline at end of file
diff --git a/ja-jp/articles/migrations/guides/passwordless-start.md b/ja-jp/articles/migrations/guides/passwordless-start.md
new file mode 100644
index 0000000000..690d1f5786
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/passwordless-start.md
@@ -0,0 +1,100 @@
+---
+title: Migration Guide for the Use of /passwordless/start from Confidential Applications
+description: Auth0 is deprecating the usage of the /passwordless/start endpoint from confidential applications without a client secret in the request.
+topics:
+  - passwordless
+  - migrations
+contentType:
+  - concept
+  - how-to
+useCase:
+  - customize-connections
+---
+# Migration Guide: Use of /passwordless/start from Confidential Applications
+
+Auth0 is deprecating the use of the `/passwordless/start` endpoint from confidential applications when Auth0 cannot authenticate that the call is made on behalf of the application.
+
+OAuth uses the term 'confidential' for applications that can store secrets. In Auth0, those are 'Regular Web Applications', which serve web pages from a backend app. Single Page Applications and Native Applications are considered 'public' applications, and are not affected by this change.
+
+Auth0 can authenticate calls to `/passwordless/start` when they include a `client_secret` as a parameter, or when the calls are made from the custom login page in Universal Login and forward the `state` parameter.
+
+## Does this affect me?
+
+If any of your applications currently call the `/passwordless/start` endpoint directly to begin passwordless authentication from a Web Application, and you are not sending the `client_secret` as a parameter, this deprecation does affect you. 
+
+If you are implementing passwordless authentication through the Universal Login page and you changed the default way Auth0 libraries are initialized, it might also affect you too.
+
+You can verify whether you are affected by checking the [tenant logs](${manage_url}/#/logs), filtering by "Deprecation Notice" and check for logs saying "Enforce client authentication for passwordless connections". You can also perform this search directly with the following query: `type:depnote AND description:*passwordless*`. Note that this specific query will only work for public cloud tenants, as private cloud logs cannot be searched on the description field.
+
+## What do I need to do?
+
+If you are calling the `/passwordless/start` endpoint without proper application authentication you should:
+
+- Follow the instructions described below to adjust the code to properly call `/passwordless/start`.
+- Check your [tenant logs](${manage_url}/#/logs) to verify the change was made correctly and no deprecation logs are being generated for "Enforce client authentication for passwordless connections".
+- In the **Migrations** section of Advanced Tenant Settings, turn on the **Enforce client authentication for passwordless connections** toggle.
+
+## How I need to change my code?
+
+There are a few use cases that might be affected, but for each, the migration path is fairly straightforward:
+
+### 1. API calls from your backend
+
+For any calls from your backend to the `/passwordless/start` endpoint, your call must include the client secret as a parameter.
+
+If making a POST request directly to `/passwordless/start`, include the `client_secret` as part of the payload: 
+
+```json
+POST https://YOUR_AUTH0_DOMAIN/passwordless/start
+Content-Type: application/json
+{
+  "client_id": "YOUR_CLIENT_ID",
+  "client_secret": "YOUR_CLIENT_SECRET",
+  "connection": "email|sms",
+  "email": "EMAIL", //set for connection=email
+  "phone_number": "PHONE_NUMBER", //set for connection=sms
+  "send": "link|code",
+  "authParams": { 
+    "scope": "openid",
+    "state": "YOUR_STATE"
+  }
+}
+```
+
+If you are using an SDK, add the parameter to the method that initiates the passwordless flow. This is different for each SDK, and not all SDKs have been updated yet. If you are using an SDK that was not updated, you can make the HTTP call directly until that work is completed.
+
+### 2. Using Auth0.js or Lock.js in the Universal Login page
+
+If the Universal Login page is used for Passwordless Authentication for a Web Application, it will be making calls to the `/passwordless/start` endpoint, by either using Lock.js or Auth0.js.
+
+Given you can't store a client secret in a web page, the way to authenticate the call is by forwarding the `state` parameter that is received in the Universal Login page to the `/passwordless/start` endpoint. That parameter is stored in the `config.internalOptions` field in the custom login page. 
+
+The default templates for customizing the login page use it in the following way when initializing Lock.js or auth0.js:
+
+```js
+var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
+  auth: {
+    // .. other fields set
+    params: config.internalOptions
+  })
+```
+
+```js
+var params = Object.assign({
+  // .. some fields set
+}, config.internalOptions);
+
+var webAuth = new auth0.WebAuth(params);
+```
+
+Please check in your custom page implementation to verify that you have not removed that code.
+
+### 3. Calling /passwordless/start from the client in a web application
+
+We found that some customers are calling the `/passwordless/start` endpoint from a page using JavaScript (for example, they might be using auth0.js on the page) from Regular Web Applications. This will not be possible, as you cannot specify a client secret in a call made using JavaScript. If this is currently the case for your application, you will need to change your applications so that `/passwordless/start` is called from the backend of your web application, rather than from the frontend.
+
+## Rate Limits
+
+A consequence of adding client authentication to `/passwordless/start` is that Auth0 can trust the headers sent with the request. Auth0 takes into account the `auth0-forwarded-for` header when enforcing rate limits. If you set that header with the end user's IP address when making the call from the server, Auth0 will rate limit the endpoint based on the end user's IP, instead of the server IP.
+
+You can read more about this in the [passwordless endpoints](/connections/passwordless/relevant-api-endpoints#rate-limiting-in-passwordless-endpoints) documentation.
diff --git a/ja-jp/articles/migrations/guides/unpaginated-requests.md b/ja-jp/articles/migrations/guides/unpaginated-requests.md
new file mode 100644
index 0000000000..6ee5a263c8
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/unpaginated-requests.md
@@ -0,0 +1,67 @@
+---
+title: Migrate to Management API v2 Endpoint Paginated Queries
+description: Query requests to specific Management API endpoints will return up to 50 results instead of all available items. You must now specify `page` and `per_page` parameters.
+topics:
+  - pagination
+  - migrations
+contentType:
+  - concept
+  - how-to
+useCase:
+  - paginated-results
+---
+# Migrate to Management API v2 Endpoint Paginated Queries
+
+After **26 January 2021**, requests to Management API v2 endpoints will return a maximum of 50 items for tenants in the Public Cloud. To retrieve more items, you must include the `page` and `per_page` parameters. Beginning on **21 July 2020**, Auth0 will display tenant logs and a migration toggle to help you prepare for this change. 
+
+Affected tenants are those that meet the following criteria:
+
+* Auth0 Public Cloud (currently)
+* Created **before 21 July 2020**
+* Actively making calls to the affected endpoints without passing the `per_page` parameter for queries that can return more than 1 result.
+
+The following tenants are not affected:
+
+* Created **on or after 21 July 2020**
+* Not using any of the affected endpoints
+* Using the affected endpoints and passing the `per_page` parameter, or making queries that will always return a single result.
+
+## Endpoints affected
+
+Calls to the following Management API v2 endpoints are affected:
+
+* [`GET /api/v2/clients`](/api/management/v2#!/Clients/get_clients)
+* [`GET /api/v2/client_grants`](/api/management/v2#!/Clients/client_grants)
+* [`GET /api/v2/grants`](/api/management/v2#!/Clients/grants)
+* [`GET /api/v2/connections`](/api/management/v2#!/Clients/connections)
+* [`GET /api/v2/device-credentials`](/api/management/v2#!/Clients/device_credentials) (when `type` query parameter is provided)
+* [`GET /api/v2/resource-servers`](/api/management/v2#!/Clients/resource_servers)
+* [`GET /api/v2/rules`](/api/management/v2#!/Clients/rules)
+
+Deprecation notices will be recorded in your tenant logs for all requests without pagination options that are currently returning more than 1 item, once per hour, for each different client and endpoint.
+
+## Actions
+
+1. Replace all calls to the affected endpoints by providing the `page` and `per_page` parameters.
+
+| Parameter | Type | Description |
+| -- | -- | -- |
+| `page` | Integer | Page index of the results to return. First page is 0. If `page` is not specified, it will default to 0.  |
+| `per_page` | Integer | Number of results per page. Paging is disabled if the parameter is not sent. `per_page` has a maximum value of 100. |
+
+2. Confirm that you are no longer seeing deprecation notices in your tenant logs. Check if a request returned more than 50 items. Look at the `details.size_exceeded` field and check if it’s `true`.
+    - Use the following log query to return all calls without pagination options with more than 1 result: `type:depnote AND description:*Unpaginated*`
+    - Use the following log query to return all calls without pagination options with more than 50 results: `type:depnote AND description:*Unpaginated* AND details.size_exceeded:true`
+
+    To identify the application making request, logs will include the `client_id` used to make the request. You can also find the endpoint being used in the logs `details.path` field.
+
+3. Disable Management API unpaginated requests for your tenant. Go to [**Dashboard > Tenant Settings > Advanced > Migration**](${manage_url}/#/tenant/advanced). This will simulate the expected behavior after the migration window closes, causing calls to affected endpoints to return up to 50 results.
+
+    You will be able to re-enable unpaginated requests any time before that date.
+
+### Update extensions
+
+You may need to update from previous versions of [Auth0 Extensions](/extensions) and custom extensions may need to be updated to their latest versions to make sure they are only performing paginated queries.
+
+1. Check your tenant logs for deprecation notices for clients with an ID matching an extension URL. It means you will need to update that extension.
+2. Go to [**Dashboard > Extensions**](${manage_url}/#/extensions), select **Installed Extensions**, and click on the extension's **Update** link if present.
diff --git a/ja-jp/articles/migrations/guides/yahoo-userinfo-updates.md b/ja-jp/articles/migrations/guides/yahoo-userinfo-updates.md
new file mode 100644
index 0000000000..33bd6ea68a
--- /dev/null
+++ b/ja-jp/articles/migrations/guides/yahoo-userinfo-updates.md
@@ -0,0 +1,58 @@
+---
+title: Changes to Yahoo Profile
+description: The latest version of the Yahoo API changes the structure of the user profile
+toc: true
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Changes to Yahoo Profile
+ 
+Yahoo changed the API that applications need to use to retrieve the User Profile from their [Social Directory API](https://developer.yahoo.com/oauth/social-directory-eol/) to a Yahoo `/userinfo` endpoint. This change implies that the structure of the user profile for Yahoo users in Auth0 will change.
+
+Auth0 previously loaded all the profile data that Yahoo returned, and added these additional fields that were mapped from the Yahoo profile:
+
+|Auth0 field|Yahoo field|
+|---|---|
+|user_id|guid|
+|sub|guid|
+|name|nickname|
+|time_zone|timeZone|
+|uri|uri|
+|url|profileUrl|
+|isConnected|isConnected|
+|email_verified|verified|
+|email|email|
+
+Yahoo stopped returning `url`, `profileUrl`, `isConnected`, and a set of other fields listed in [Yahoo’s documentation](https://developer.yahoo.com/oauth/social-directory-eol/) (see ‘List Of Attributes Deprecated in Social Directory Profile Api’). Those other fields will also not be part of the profile.
+
+The Yahoo `/userinfo` endpoint will return different fields depending on the API Permissions you configure in the [Yahoo Application](https://developer.yahoo.com/apps/) definition. 
+
+Yahoo lets you grant one of four permissions in the **Profile (Social Directory)** permissions section:
+
+- Read Public Basic
+- Read Public Extended
+- Read Write Public
+- Read Write Public and Private
+
+When configuring the Yahoo Connection in your Auth0 Dashboard, you need to select the attribute that corresponds to the permissions you granted in your Yahoo setup. If you choose an attribute that does not match what you specified on Yahoo, the login transaction will fail.
+
+|Yahoo Connection Attributes|Profile Fields|
+|--|--|
+|Basic Profile| sub, name, given_name, family_name, locale|
+|Basic Profile Write| sub, name, given_name, family_name, locale|
+|Extended Profile |sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number, nickname |
+|Extended Write | sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number, nickname |
+
+If you do not select any permissions in the Auth0 connection settings, Auth0 will by default ask for the `openid` scope, which will return the profile fields that correspond to whatever API Permission you specified in the Yahoo Application. For example, if your Yahoo application is configured with `Read Public Extended`, it will return the `sub, name, given_name, family_name, locale, email, email_verified, birthdate, profile_images, picture, preferred_username, phone_number and nickname` fields.
+
+**Do I need to take any action?**
+
+Auth0 will default to send the `openid` scope when authenticating with Yahoo.
+
+If you are using the Yahoo connection to authenticate users and get their basic information, your application will continue to work without changes.
+
+If your application is accessing fields in the user profile that are no longer available, then you will need to make sure you enable the right Connection Attribute in the Auth0 dashboard and adjust your application code to use the proper field names.
diff --git a/ja-jp/articles/migrations/past-migrations.md b/ja-jp/articles/migrations/past-migrations.md
new file mode 100644
index 0000000000..5956128735
--- /dev/null
+++ b/ja-jp/articles/migrations/past-migrations.md
@@ -0,0 +1,272 @@
+---
+toc: true
+description: List of Auth0 migrations that have already been enabled for all customers
+topics:
+  - migrations
+contentType:
+  - reference
+useCase:
+  - migrate
+---
+# Past Migrations
+
+These are migrations that have already been enabled for all customers.
+
+## Introducing Lock v11 and Auth0.js v9
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Medium | 2017-12-21 |  2018-08-06 |
+
+We are continually improving the security of our service. As part of this effort, we have deprecated the Legacy Lock API, which consists of the /usernamepassword/login and /ssodata endpoints. These endpoints are used by Lock.js v8, v9, and v10 and Auth0.js, v6, v7, and v8, and can also be called directly from applications.
+
+As of August 6, 2018, Auth0 has permanently disabled the Legacy Lock API. This removal of service fully mitigates the CSRF vulnerability disclosed in April 2018. This also ends the soft removal grace period that was [first announced on July 16, 2018](https://community.auth0.com/t/auth0-legacy-lock-api-disabled-grace-period-available/12949), meaning the Legacy Lock API can no longer be re-enabled.
+
+If your Legacy Lock API migration has not yet been completed, your users may experience an outage, failed logins, or other adverse effects. You will need to complete your migration in order to restore normal functionality. See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) to identify the source(s) of any errors in your tenant logs related to deprecations. 
+
+### Am I affected by the change?
+
+If you are currently implementing login in your application with Lock v8, v9, or v10, or Auth0.js v6, v7, or v8, you are affected by these changes. Additionally, you are affected if your application calls the /usernamepassword/login or /ssodata endpoints directly via the API.
+
+We **recommend** that applications using [Universal Login](/universal-login) update the library versions they use inside of the login page.
+
+However, those who are using Lock or Auth0.js embedded within their applications, or are calling the affected API endpoints directly, are **required** to update, and applications which still use deprecated endpoints will cease to function properly after the removal of service date.
+
+Libraries and SDKs not explicitly named here are not affected by this migration.
+
+## New IP Addresses for Whitelisting in Australia
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Low | 2017-08-22 |  2017-09-30 |
+
+Auth0 is updating its cloud environments, and traffic from these regions will originate from new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules.
+
+### Am I affected by the change?
+
+If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall:
+
+```
+13.55.232.24, 13.54.254.182, 13.210.52.131, 52.62.91.160, 52.63.36.78, 52.64.84.177, 52.64.111.197, 52.64.120.184, 54.66.205.24, 54.79.46.4, 54.153.131.0
+```
+
+If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+## New IP Addresses for Whitelisting in Europe
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Low | 2017-08-22 |  2017-09-30 |
+
+Auth0 is updating its cloud environments, and traffic from these regions will originate from new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules.
+
+### Am I affected by the change?
+
+If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall:
+
+```
+34.253.4.94, 35.156.51.163, 35.157.221.52, 52.16.193.66, 52.16.224.164, 52.28.45.240, 52.28.56.226, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.50.106.250, 52.57.230.214, 52.211.56.181, 52.213.216.142, 52.213.38.246, 52.213.74.69
+```
+
+If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+## CDN provider migration in the Europe and Australia environments
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Low | N/A |  2017-07-12 |
+
+The existing Auth0 CDN service is one of our older services. It was been built and maintained internally since the early days of the company. To improve its scaling and availability, we are changing providers to use Amazon CloudFront on July 12, at 1pm UTC. We have already made this change in the US environment, and are now ready to do so in Europe and Australia.
+
+### Am I using the CDN?
+
+If you use Lock (hosted by our CDN) in Europe or Australia, yes.
+
+### Do I need to do something?
+
+This change shouldn't cause any disruption or change in behavior in your applications, so you don't have to do anything. This notification is for information only.
+
+If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+## Whitelisting IP Address Ranges (Q1 2017)
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Low | 2017-01-15 |  2017-02-20 |
+
+Auth0 is expanding into new US regions, and traffic originating from these regions will have new IP addresses. If you are whitelisting IP addresses, you will need to add the new addresses to your firewall rules.
+
+### Am I affected by the change?
+
+If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to add the following IP addresses to your firewall rules:
+
+```
+138.91.154.99, 54.183.64.135, 54.67.77.38, 54.67.15.170,
+54.183.204.205, 54.173.21.107, 54.85.173.28, 35.167.74.121, 35.160.3.103,
+35.166.202.113, 52.14.40.253,
+52.14.38.78, 52.14.17.114, 52.71.209.77, 34.195.142.251, 52.200.94.42
+```
+
+If you have any questions, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+## Vulnerable Password Flow
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Medium | 2016-03-22 |  2017-02-01 |
+
+The current password reset flow on Auth0 allows a user to enter their email and a new password. This triggers a confirmation email that is sent to the user asking them to confirm that they requested a password reset.
+
+The issue is that the confirmation link may be inadvertently clicked by a user, which would result in the user's password being changed by an attacker.
+
+Lock version 9 and above uses the [new password reset flow](/connections/database/password-change) exclusively. Lock 8 and below does not handle the new password reset flow. We strongly recommend upgrading to Lock 9 or greater as soon as possible.
+
+::: panel Security Warning
+Even if you are not using Lock, the vulnerable reset flow can be accessed directly through the API. (See the [/dbconnections/change_password](/api/authentication/reference#change-password) endpoint for details.) We strongly encourage any app using the current flow to move immediately to the new reset flow and enable this migration.
+:::
+
+## Account Linking Removal
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Medium | 2017-01-03 |  2017-03-01 |
+
+As part of Auth0's efforts to improve security and standards compliance, we will stop supporting account linking as part of the authorization callback (that is, accepting an Access Token as part of the [authorize](/api/authentication#authorization-code-grant) call as stated [in the account linking section](/api/authentication?http#account-linking).
+
+### Am I affected by the change?
+
+If you received an email notification about it, then you are impacted by this change. As you work to update your applications to [use the Management API to link accounts](/api/management/v2#!/Users/post_identities), you can check if you are still impacted, by checking your tenant logs for warnings indicating _"Account linking via /authorize is being deprecated. See [User Account Linking](/users/concepts/overview-user-account-linking) for supported ways to link an account."_. These entries will be logged if you are sending an Access Token in your [authorize](/api/authentication#authorization-code-grant) calls.
+
+If you need help with the migration, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT})
+
+## Password and Refresh Token Exchange Rules Migration Notice
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- |
+| Medium | 2017-02-23 |  2017-05-31 |
+
+As part of Auth0's efforts to improve security, we recently added the ability to execute rules during the OAuth 2.0 Resource Owner Password Grant exchange (the password exchange) and the Refresh Token exchange.
+
+You are using this feature if you are calling the [/oauth/token](/api/authentication#authorization-code) endpoint of our Authentication API with `grant_type = "password"` , `grant_type = "http://auth0.com/oauth/grant-type/password-realm"`, or `grant_type = "refresh_token"`.
+
+### Am I affected by the change?
+
+You could be impacted if you are currently using these exchanges and have Rules defined in Dashboard. In order to ensure a smooth transition, we have disabled the rules execution on these specific exchanges for your tenant. These rules will now execute for all new customers, as well as customers who have not yet used these exchanges.
+
+You can add logic to your rules to alter their behavior for these exchanges by checking the `context.protocol` property:
+- `oauth2-password` indicates the password (and password-realm) exchange
+- `oauth2-refresh-token` indicates the Refresh Token exchange
+
+If you would like to enable the new behavior on this tenant for testing before the mandatory opt-in date, login to [Dashboard](${manage_url}) and enable the __Run Rules on Password and Refresh Token Exchanges__ toggle in [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced).
+
+If you need help with the migration, create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT})
+
+## Email Delivery Changes: "From" Address
+
+| Severity | Platforms | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- | --- |
+| Medium | Auth0 Cloud Only | 2016-04-20 | 2016-04-27 |
+
+Auth0's built-in email provider starting sending all emails from a predefined "from" address (`no-reply@auth0user.net`). Custom Email Providers will now be free for every customer, and to be able to customize the "from" address you can switch to an Auth0-supported [third-party service](/email/providers) ([Amazon SES](https://aws.amazon.com/ses/), [Mandrill](https://www.mandrill.com/signup/), [SendGrid](https://sendgrid.com/pricing)) or another [SMTP-based provider](/email/custom).
+
+If you already use a custom email provider, nothing will change.
+
+For more information, see: [Emails in Auth0](/email).
+
+## TokenInfo endpoint validation
+
+| Severity | Mandatory Opt-In|
+| --- | --- |
+| Low | 2016-06-01 |
+
+When calling the [TokenInfo](/api/authentication/reference#get-token-info) endpoint, the URL of the API call (for example `https://${account.namespace}/`) must match the value of the `iss` attribute of the ID Token being validated.
+
+If these values do not match, the response will be `HTTP 400 - Bad Request`.
+
+### Am I affected by the change?
+
+If you are calling the [tokeninfo](/api/authentication#get-token-info) endpoint directly, make sure that the value of the `iss` attribute of the ID Token being validated matches your Auth0 tenant namespace: `https://${account.namespace}/`.
+
+::: note
+You can use [jwt.io](https://jwt.io/) to decode the token to confirm the `iss` attribute value.
+:::
+
+## Identity Provider Access Tokens removed from user profile and ID Token
+
+| Severity | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- | --- |
+| Medium | 2016-07-11 | 2016-08-18 |
+
+The format of the user profile JSON object (ID Token) that is returned by Auth0 Authentication APIs has been changed to remove the Identity Provider's Access Token, which had been included in the user profile `identities` array.
+
+Now, to obtain a user's IdP Access Token, you will need to make an HTTP GET call to the `/api/v2/users/{user-id}` endpoint containing an API token generated with  `read:user_idp_tokens` scope.
+
+::: note
+You will still have access to the Identity Provider Access Token in the `user` argument in Auth0 [rules](/rules).
+:::
+
+### Am I affected by the change?
+
+You are affected by the change only if you are using the Identity Provider Access Token (`identities[0].access_token` in the user profile) outside of rules to call other services from the Identity Provider (such as Facebook Graph API, Google APIs, and so on).
+
+For more information on how to obtain an Access Token, see: [Call an Identity Provider API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api) and [Identity Provider Access Tokens](/tokens/overview-idp-access-tokens).
+
+::: note
+If your tenant was created after the change, this update will be applied automatically.
+:::
+
+## Email Delivery Changes: Template Customizations
+
+| Severity | Platforms | Grace Period Start | Mandatory Opt-In|
+| --- | --- | --- | --- |
+| Medium | Auth0 Cloud Only | 2016-07-21 | 2016-08-29 |
+
+Auth0's built-in email provider will no longer be supported for use in a production environment. The emails sent using the Auth0 provider will no longer be customizable. They will be restricted to the template and you will not be able to change the *from address* or subject line.
+
+The built-in email service may still be used for test purposes but you must switch to an Auth0-supported [third-party service](/email/providers) ([Amazon SES](https://aws.amazon.com/ses/), [Mandrill](https://www.mandrill.com/signup/), [SendGrid](https://sendgrid.com/pricing)) or another [SMTP-based provider](/email/custom) before moving your apps to production.
+
+If you already use a custom email provider, no action is necessary.
+
+For more information, see: [Emails in Auth0](/email).
+
+## Delete All Users Endpoint Change
+
+| Severity | Effective Date |
+| --- | --- | --- | --- |
+| Low | 2016-09-13 |
+
+The previous endpoint for deleting all users was `DELETE  /api/v2/users`. This is rather similar to the endpoint to delete _one_ user: [DELETE  /api/v2/users](/api/management/v2#!/Users/delete_users_by_id). To prevent accidental requests to the delete all users endpoint, the url has been changed to `DELETE /api/v2/allusers`. This should ensure that only intentional calls to this endpoint get made.
+
+### Am I affected by the change?
+
+You are affected by the change only if you currently make use of the delete all users endpoint. If so, the only change you need to make is to change the URL as explained above.
+
+## State Parameter required on redirect from rule
+
+| Severity | Effective Date |
+| --- | --- | --- | --- |
+| High | 2016-11-01 |
+
+When a redirect is done from an Auth0 rule, Auth0 takes care of generating and sending a state parameter in HTTP and Auth0 will check for a valid state parameter when flow returns to the /continue endpoint.  The site to which the redirect goes has to capture the value of the state parameter and return it by adding it as a parameter when returning to the /continue endpoint.
+
+This is documented [here](/rules/redirect#what-to-do-after-redirecting)
+
+### Am I affected by the change?
+
+You are effected by the change only if you redirect from rules, and do not yet capture and return (to the /continue end point) the state parameter.
+
+## Patch and Post endpoints no longer accept secret_encoded flag
+
+| Severity | Effective Date |
+| --- | --- | --- | --- |
+| High | 2016-12-06 |
+
+The `jwt_configuration.secret_encoded` configuration is no longer accepted by the PATCH and POST applications endpoints.
+
+In order to further comply with the OIDC specification, Auth0 will no longer generate or accept base64 encoded application secrets for new applications.
+
+Existing applications with encoded secrets stored will remain intact and unchanged, but *new* applications will no longer use base64 encoding. The `secret_encoded` flag is no longer accepted or necessary, as a result.
+
+### Am I affected by the change?
+
+You are affected by this change only if you interact with these endpoints directly.
diff --git a/ja-jp/articles/monitoring/_includes/_monitor-private-cloud.md b/ja-jp/articles/monitoring/_includes/_monitor-private-cloud.md
new file mode 100644
index 0000000000..a0dc01777f
--- /dev/null
+++ b/ja-jp/articles/monitoring/_includes/_monitor-private-cloud.md
@@ -0,0 +1,3 @@
+::: panel Monitor a dedicated deployment
+See the [Private Cloud](/private-cloud) documentation for information on [monitoring](/appliance/monitoring) a dedicated deployment.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/monitoring/guides/check-external-services.md b/ja-jp/articles/monitoring/guides/check-external-services.md
new file mode 100644
index 0000000000..3dfbf87d5f
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/check-external-services.md
@@ -0,0 +1,46 @@
+---
+title: Check External Services Status
+description: Learn how to check the status of services external to Auth0. 
+topics:
+  - monitoring
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+---
+
+# Check External Services Status
+
+You may want to monitor any remote identity providers you use with your Auth0 connections to quickly isolate the source of the problem. 
+
+If you see potential issues with your Auth0 service, but [Auth0 Status](https://status.auth0.com) doesn't indicate any problems, check the status of any external services that you use with Auth0, such as:
+
+* [Amazon Web Services](https://status.aws.amazon.com/)
+* [Azure Active Directory](https://azure.microsoft.com/en-us/status/)
+* [Citrix](https://status.cloud.com/)
+* [Facebook](https://developers.facebook.com/status/)
+* [GitHub](https://status.github.com/)
+* [Google Cloud](https://status.cloud.google.com/)
+* [Google's G Suite](https://www.google.com/appsstatus#hl=en&v=status)
+* [Heroku](https://status.heroku.com/)
+* [IBM](https://console.bluemix.net/status)
+* [Mandrill](http://status.mandrillapp.com/)
+* [Microsoft Azure](https://azure.microsoft.com/en-gb/status/)
+* [SAP](https://www.sap.com/about/cloud-trust-center/cloud-service-status.html)
+* [SendGrid](http://status.sendgrid.com/)
+* [SFDC](https://status.salesforce.com/)
+* [Slack](https://status.slack.com/)
+* [Twilio](https://status.twilio.com/)
+* [VM Ware](https://status.vmware-services.io/)
+
+::: note
+Your customers may have some of the same concerns, so you may want to document any monitoring pages or endpoints that they can view to help them troubleshoot and narrow down the location of an issue.
+:::
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
diff --git a/ja-jp/articles/monitoring/guides/check-status.md b/ja-jp/articles/monitoring/guides/check-status.md
new file mode 100644
index 0000000000..98f4181a57
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/check-status.md
@@ -0,0 +1,44 @@
+---
+title: Check Auth0 Status
+description: Learn how to check Auth0 public cloud service availability, incident reports, and historical uptime reports. 
+topics:
+  - monitoring
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+---
+
+# Check Auth0 Status
+
+Auth0 makes every effort to minimize outages, but if there is any disruption to service, it will appear on the [Auth0 Status](https://status.auth0.com) page. To support requirements for root cause analysis documentation after a disruption, Auth0 conducts internal analysis and publishes the results of the disruption notice. If there's an outage listed on the status page, you do not need to file a ticket. Auth0 is already working on the issue. 
+
+## Check status
+
+Go to [Auth0 Status](https://status.auth0.com) to check the service availability of the cloud version of Auth0. 
+
+You can see the status of a region or expand a region and see the status of individual services supporting functionality such as the authentication API or execution of custom code (used within custom DB connections and rules).
+
+## Subscribe to status updates
+
+On the [Auth0 Status](https://status.auth0.com) page, choose your region and environment and click **Subscribe to Updates** to get updates. You can choose from two options to view status: 
+
+* Follow [@auth0status](https://twitter.com/auth0status) on Twitter to get the latest status updates.
+
+* Subscribe to the Auth0 Atom feed to get status updates that affect your tenant. Using an RSS feed aggregator of your choice (such as https://feeder.co/reader), use the following RSS feed URL to view the status of your tenant. Replace `YOUR-TENANT` with your tenant name.
+
+   `status.auth0.com/feed?domain={YOUR-TENANT}.auth0.com`
+
+## Historical uptime reports
+
+Current and historical Auth0 uptime reports are available at [Auth0 Uptime](http://uptime.auth0.com).
+
+## Keep reading
+
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Troubleshooting](/troubleshoot)
+* [Support Options](/support)
diff --git a/ja-jp/articles/monitoring/guides/monitor-applications.md b/ja-jp/articles/monitoring/guides/monitor-applications.md
new file mode 100644
index 0000000000..f84e4eb665
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/monitor-applications.md
@@ -0,0 +1,32 @@
+---
+title: Monitor Applications
+description: Learn how to monitor your own applications and perform  end-to-end testing using your own tests. 
+topics:
+  - monitoring
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+  - synthetic-authentication
+  - synthetic-transactions
+---
+# Monitor Applications
+
+If you would like to monitor your own [application](/applications) or conduct end-to-end testing, you’ll need to set up your own tests. 
+
+If you've extended Auth0 through [rules](/rules) or a [custom database connection](/connections/database/custom-db), you can build a synthetic transaction that exercises these capabilities using the [Resource Owner Password Grant](/api-auth/tutorials/password-grant). One way of doing this is to [Monitor Auth0 Using SCOM](/monitoring/guides/monitor-using-SCOM).
+
+Auth0 recommends using an authentication flow that doesn't require a user interface such as the **Resource Owner Password Grant**. That way, you can use a monitoring tool that doesn't have to mimick the actions of a user. Many monitoring services exist with this capability including:
+
+* [New Relic](http://newrelic.com)
+* [Pingdom](http://pingdom.com)
+
+Use one of these services to execute synthetic authentication requests. 
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
diff --git a/ja-jp/articles/monitoring/guides/monitor-using-SCOM.md b/ja-jp/articles/monitoring/guides/monitor-using-SCOM.md
new file mode 100644
index 0000000000..97918bb43f
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/monitor-using-SCOM.md
@@ -0,0 +1,80 @@
+---
+title: Monitor Auth0 Using System Center Operations Manager
+description: Learn how to monitor Auth0 as a standard web application using System Center Operations Manager (SCOM) or any tool that supports synthetic transactions. 
+toc: true
+topics:
+  - monitoring
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+  - synthetic-authentication
+  - synthetic-transactions
+---
+# Monitor Auth0 Using System Center Operations Manager
+
+You can monitor Auth0 as a standard web application using System Center Operations Manager (SCOM) or any tool that supports synthetic transactions.
+
+We recommend monitoring a synthetic login transaction that includes the extensions your applications rely on (such as rules that execute custom code for integration with your company's other services).
+
+## Set up SCOM
+
+1. Add a new SCOM instance using the **Add Monitoring Wizard**:
+
+   | **Field** | **Description** |
+   | ---| ---|
+   | **Name** | Description name for the SCOM instance. |
+   | **Description** | Description of what this SCOM instance monitors. |
+   | **Select destination management pack** | Default Management Pack |
+
+   When finished, click **Next** to continue.
+
+   ![ss-2014-11-21T15-44-34.png](/media/articles/monitoring/ss-2014-11-21T15-44-34.png)
+
+2. Click **Add** to enter the URLs you want SCOM to monitor. When finished, click **Next** to continue.
+
+   ![ss-2014-11-21T16-31-15.png](/media/articles/monitoring/ss-2014-11-21T16-31-15.png)
+
+3. Click **Add** to set up a location from which you want to monitor.
+
+   In the pop-up dialog, search for **Internal location - Agent**. Select the appropriate address, and click **Add**. Then click **Ok** to finish selecting the location. When finished, click **Next** to continue.
+
+   ![ss-2014-11-21T16-32-25.png](/media/articles/monitoring/ss-2014-11-21T16-32-25.png)
+
+4. Set the frequency with which SCOM collects data from each endpoint:
+
+   | **Data** | **Frequency** |
+   | --- | --- |
+   | **Test frequency** | 60 seconds |
+   | **Performance data collection interval** | 60 seconds |
+   | **Test time-out** | 30 seconds |
+   | **HTTP status code** | Greater than or equals 400 |
+
+   When finished, click **Next** to continue.
+
+   ![ss-2014-11-21T16-33-51.png](/media/articles/monitoring/ss-2014-11-21T16-33-51.png)
+
+## Run SCOM tests
+
+1. Click **Run Test** to test each endpoint and ensure that the connection settings provided are correct.
+
+   ![ss-2014-11-21T16-34-25.png](/media/articles/monitoring/ss-2014-11-21T16-34-25.png)
+
+2. Once you have finished configuring your SCOM instance, you can view activity through the **Monitoring** tab:
+
+   ![ss-2014-11-25T17-20-47.png](/media/articles/monitoring/ss-2014-11-25T17-20-47.png)
+
+## Review test results
+
+Click **Web Application Status** to bring up the information SCOM has gathered.
+
+![ss-2014-11-25T17-22-10.png](/media/articles/monitoring/ss-2014-11-25T17-22-10.png)
+
+## Keep reading
+
+* [Monitoring the AD/LDAP Connector with System Center Operations Manager](/connector/scom-monitoring)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
diff --git a/ja-jp/articles/monitoring/guides/send-events-to-keenio.md b/ja-jp/articles/monitoring/guides/send-events-to-keenio.md
new file mode 100644
index 0000000000..22fc43d835
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/send-events-to-keenio.md
@@ -0,0 +1,77 @@
+---
+title: Send Logging Events to Keen
+description: Learn how to send logging events to Keen from Auth0.
+topics:
+  - monitoring
+  - keenio
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - analyze-external-analytics
+  - integrate-analytics
+---
+# Send Logging Events to Keen
+
+[Keen](http://keen.io) provides a service to capture and analyze events generated in your apps. In their words:
+
+> Analytics transforms data into answers – the kind of answers every company deserves. Unfortunately, a lot of companies a) can't find an analytics service that's right for their specific needs, and b) don't have the resources to develop their own analytics infrastructure. That's why we started Keen IO. Basically, we built it, so you don't have to. And we made it powerful, flexible, and scalable enough that you can use it however you need to – even if those needs change over time.
+
+In this example, you will learn how to connect Auth0 to Keen and stream `signup` events. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline.
+
+![Keen IO Dataflow](/media/articles/tutorials/keen-io-dataflow.png)
+
+## Record a sign-up event in Keen
+
+Create a rule that will record user `signup` events for your apps in Keen. Please note:
+
+* In this example, we expect your Keen credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your **Write Key** here before running your rule. Doing this allows you to use your key in multiple rules and prevents you from having to store it directly in the code.
+
+* For this rule, we send contextual information, such as IP address (can be used to deduce location), user ID, and username. However, you can send any number of properties.
+
+* For this rule, we track the event type using a __persistent__ property called `user.signedUp`. When the property is set to `true`, we return immediately. Otherwise, we assume the event is a new `signup`, and if everything goes well, we set the property to `true`. The next time the user signs in, this rule will be skipped.
+
+
+```js
+function(user, context, callback) {
+
+  var request = require('request');
+
+  if(user.signedUp){
+    return callback(null, user, context);
+  }
+
+  var writeKey = configuration.KEENIO_WRITE_KEY;
+  var projectId = configuration.KEENIO_PROJECT_ID;
+  var eventCollection = 'signups';
+
+  var keenEvent = {
+    userId: user.user_id,
+    name: user.name,
+    ip: context.request.ip //Potentially any other properties in the user profile/context
+  };
+
+  request.post({
+      method: 'POST',
+      url: 'https://api.keen.io/3.0/projects/' + projectId + '/events/' + eventCollection,
+      headers: {
+        "Authorization: " + writeKey,
+        'Content-type': 'application/json'
+      },
+      body: JSON.stringify(keenEvent),
+      }, 
+      function (e, r, body) {
+        if( e ) return callback(e,user,context);
+        //We assume everything went well
+        user.persistent.signedUp = true;
+        return callback(null, user, context);
+       });
+}
+```
+
+## Keep reading
+Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples:
+
+* Rules for access control
+* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com), [Segment](https://segment.com/)
diff --git a/ja-jp/articles/monitoring/guides/send-events-to-segmentio.md b/ja-jp/articles/monitoring/guides/send-events-to-segmentio.md
new file mode 100644
index 0000000000..51f8030308
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/send-events-to-segmentio.md
@@ -0,0 +1,90 @@
+---
+title: Send Logging Events to Segment
+description: Learn how to send logging events to Segment from Auth0.
+topics:
+  - monitoring
+  - segmentio
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - analyze-external-analytics
+  - integrate-analytics
+---
+# Send Logging Events to Segment
+
+[Segment](https://segment.com/) provides a large number of analytics-related functionality with a single, simple to use API.
+
+In this example, you will learn how to connect Auth0 to Segment and stream `signup` and `login` events. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline.
+
+![Segment Flow](/media/articles/monitoring/segment/segment-io-dataflow.png)
+
+You'll be using [Segment's Node.js library](https://github.com/segmentio/analytics-node) to record Auth0 data.
+
+## 1. Find your Segment Write Key
+
+To configure this integration, you'll need your Segment **Write Key**. You can find this under Segment's  **Settings** > **API**.
+
+![Segment API Keys](/media/articles/monitoring/segment/segment-3.png)
+
+## 2. Record sign-up and log-in events in Segment
+
+Create a rule to record user `signup` and `login` events for your apps and send the information to Segment using Segment's Node.js library.
+
+In this example, we expect your Segment credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your **Write Key** here before running your rule. Doing this allows you to use your key in multiple rules and prevents you from having to store it directly in the code.
+
+
+```js
+function(user, context, callback) {
+  var Analytics = require('analytics-node');
+  var analytics = new Analytics(configuration.WRITE_KEY, { flushAt: 1 });
+
+  // Note: Set { flushAt: 1 } and use analytics.flush to ensure
+  // the data is sent to Segment before the rule/Webtask terminates
+
+  // Identify your user
+  analytics.identify({
+      userId: user.user_id,
+      traits: {
+      email: user.email,
+      signed_up: user.created_at,
+      login_count: user.logins_count
+    },
+    "context": {
+      "userAgent": context.request.UserAgent,
+      "ip": context.request.ip
+    }
+  });
+  analytics.track({
+    userId: user.user_id,
+    event: 'Logged In',
+    properties: {
+      clientName: context.clientName,
+      clientID: context.clientID,
+      connection: context.connection
+    },
+    "context": {
+      "userAgent": context.request.UserAgent,
+      "ip": context.request.ip
+    }
+  });
+  analytics.flush(function(err, batch){
+    callback(null, user, context);
+  });
+}
+```
+
+## 3. Check your integration
+
+See if your integration works by checking the Segment Debugger to see if your Auth0 events are appearing.
+
+![Segment Debugger](/media/articles/monitoring/segment/segment-14.png)
+
+
+## Keep reading
+
+Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples:
+
+* Rules for access control
+* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com), [Keen](https://keen.io/)
diff --git a/ja-jp/articles/monitoring/guides/send-events-to-splunk.md b/ja-jp/articles/monitoring/guides/send-events-to-splunk.md
new file mode 100644
index 0000000000..a805b82ebe
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/send-events-to-splunk.md
@@ -0,0 +1,88 @@
+---
+title: Export Logs to Splunk Using Rules
+description: Learn how to send logging events to Splunk from Auth0 using rules.
+topics:
+  - monitoring
+  - splunk
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - analyze-external-analytics
+  - integrate-analytics
+---
+# Export Logs to Splunk Using Rules
+
+[Splunk](http://splunk.com) provides a platform that allows you to easily get insights into all the information generated by your IT infrastructure.
+
+In this example, you will learn how to connect Auth0 to Splunk and stream `signup` and `login` events with user contextual information. To implement this with Auth0, you just need to create one [Rule](/rule) in your pipeline.
+
+![](/media/articles/tutorials/splunk-dataflow.png)
+
+## Record sign-up or log-in event in Splunk
+
+Create a rule that will record user `signup` and `login` events for your apps using the [Splunk REST API](http://dev.splunk.com/view/rest-api-overview/SP-CAAADP8). When enabled, this rule will send events that will then show on Splunk's dashboard:
+
+![](/media/articles/scenarios/splunk/splunk-dashbaord.png)
+
+
+Please note:
+
+* Splunk's API supports basic & token-based auth. In this example, we use token-based auth and expect your Splunk credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your token here before running your rule. Doing this allows you to use your token in multiple rules and prevents you from having to store it directly in the code.
+
+* For this rule, we send contextual information, such as IP address (can be used to deduce location), application name, and username. However, you can send any number of properties.
+
+* For this rule, we track the event type using a property called `user.app_metadata.signedUp`. When the property is set to `true`, we assume the event is a `login`. Otherwise, we assume the event is a new `signup`, and if everything goes well, we set it to `true`. Thus, the next time the user logs in, the event will be recorded as a `login`.
+
+
+```js
+function (user, context, callback) {
+  const request = require('request');
+
+  user.app_metadata = user.app_metadata || {};
+  const endpoint = 'https://http-inputs-mysplunkcloud.example.com:443/services/collector'; // replace with your Splunk HEC endpoint;
+
+  //Add any interesting info to the event
+  const hec_event = {
+    event: {
+      message: user.app_metadata.signedUp ? 'Login' : 'Signup',
+      application: context.clientName,
+      clientIP: context.request.ip,
+      protocol: context.protocol,
+      userName: user.name,
+      userId: user.user_id
+    },
+    source: 'auth0',
+    sourcetype: 'auth0_activity'
+  };
+
+  request.post({
+    url: endpoint,
+    headers: {
+      'Authorization': 'Splunk ' + configuration.SPLUNK_HEC_TOKEN
+    },
+    strictSSL: true, // set to false if using a self-signed cert
+    json: hec_event
+  }, function(error, response, body) {
+    if (error) return callback(error);
+    if (response.statusCode !== 200) return callback(new Error('Invalid operation'));
+    user.app_metadata.signedUp = true;
+    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+      .then(function () {
+        callback(null, user, context);
+      })
+      .catch(function (err) {
+        callback(err);
+      });
+  });
+
+}
+```
+
+## Keep reading
+
+Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples:
+
+* Rules for access control
+* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Segment](https://segment.com/), [Keen](https://keen.io/)
diff --git a/ja-jp/articles/monitoring/guides/test-testall-endpoints.md b/ja-jp/articles/monitoring/guides/test-testall-endpoints.md
new file mode 100644
index 0000000000..df71f9c74d
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/test-testall-endpoints.md
@@ -0,0 +1,69 @@
+---
+title: Check Auth0 Authentication and Supporting Services
+description: Learn how check the status of the Auth0 authentication service as well as supporting services such as the Dashboard and documentation using the test and testall endpoints.
+public: false 
+topics:
+  - monitoring
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+  - synthetic-authentication
+  - synthetic-transactions
+---
+# Check Auth0 Authentication and Supporting Services
+
+::: warning
+The `/test` and `/testall` endpoints are best for determining if everything is functioning but *not* for determining if something is down. They do not provide a complete status picture. 
+:::
+
+Use the `/test` and `/testall` endpoints as a supplement to your other monitoring. You should use synthetic transactions against a test account to ensure that everything is functional. You should also track your own logs and other metrics to calls to Auth0 from servers and/or clients.
+
+## Test endpoint
+
+The `/test` endpoint checks the status of the core Auth0 authentication service. 
+
+Here is an example of a call to the `/test` endpoint:
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/test"
+}
+```
+
+If the service is up, the endpoint returns a `200` HTTP response code; if it is not, it returns a `5xx` response code. 
+
+Additionally, this endpoint returns a JSON object:
+
+```json
+{
+  "clock": 1417220191640
+}
+```
+
+## Testall endpoint
+
+The `/testall` endpoint checks the status of the core Auth0 authentication service, as well as supporting services such as those for the [Dashboard](${manage_url}) and documentation.
+
+Here is an example call to the `/testall` endpoint:
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/testall"
+}
+```
+
+If all services are up, the endpoint returns the `200` HTTP response code and a simple text message of `OK`. If any service is down, it returns a `5xx` response code.
+
+<%= include('../_includes/_monitor-private-cloud.md') %>
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
diff --git a/ja-jp/articles/monitoring/guides/track-leads-salesforce.md b/ja-jp/articles/monitoring/guides/track-leads-salesforce.md
new file mode 100644
index 0000000000..0c277f7219
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/track-leads-salesforce.md
@@ -0,0 +1,186 @@
+---
+title: Track New Leads in Salesforce
+description: Learn how to track new leads in Salesforce and augment user profiles with public information gathered from TowerData.
+topics:
+  - monitoring
+  - marketing
+  - salesforce
+  - towerdata
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - analyze-external-analytics
+  - integrate-analytics
+---
+
+# Track New Leads in Salesforce
+
+You can track new leads in Salesforce with TowerData-Enriched User Profiles. 
+
+Whenever a new user signs up with a website using any social credential we want to:
+
+1. __Augment the user profile__ with additional public information obtained through [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement).
+
+2. __Record the sign-up as a New Lead__ on [Salesforce](http://www.salesforce.com/), so a sales professional can follow up.
+
+To implement this with Auth0, you just need to create two [Rules](/rules) in your pipeline:
+
+![](/media/articles/tutorials/rapleaf-salesforce.png)
+
+## 1. Enrich User Profile with TowerData
+
+Create a rule that will obtain more information about the user by retrieving public information from TowerData's API using the user's email address as input.
+
+Once the call to TowerData completes, we store this additional information in a property called `towerdata`:
+
+:::note
+We ignore certain conditions that exist in the API and only do this when there's a successful call (`statusCode=200`). This rule will also be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 2).
+:::
+
+```js
+function (user, context, callback) {
+
+  //Filter by app
+  //if(context.clientName !== 'AN APP') return callback(null, user, context);
+
+  var request = require('request');
+
+  if (!user.email || !user.email_verified) {
+    return callback(null, user, context);
+  }
+
+  request.get('https://api.towerdata.com/v5/td', {
+      qs: {
+        email: user.email,
+        api_key: configuration.TOWERDATA_API_KEY
+      },
+      json: true
+    },
+    (err, response, body) => {
+      if (err) return callback(err);
+
+      if (response.statusCode === 200) {
+        context.idToken['https://example.com/towerdata'] = body;
+      }
+
+      return callback(null, user, context);
+    });
+}
+```
+
+## 2. Create New Lead in Salesforce
+
+Create a rule that will record the information as a __New Lead__ in Salesforce, so the sales department can follow up. Please note:
+
+* The Salesforce REST API uses an OAuth Access Token. So for this rule, we use the OAuth2 `Resource Owner Password Credential Grant` to obtain this token, and use the `getToken` function, which uses credentials as input, as opposed to an `API-KEY` as was used in the rule in the previous step.
+
+* In this example, we expect your Salesforce credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your credentials here before running your rule. Doing this allows you to use your credentials in multiple rules and prevents you from having to store them directly in the code.
+
+* For this rule, we record only the username and a fixed company name. However, we could use anything available in the enriched user profile we obtained in step 1 to record more information and provide additional context for the sales representative.
+
+* For this rule, we use a property called `user.app_metadata.recordedAsLead`, and if everything goes well, we set it to `true`. The next time the user signs in, this rule will be skipped.
+
+```js
+function (user, context, callback) {
+
+  const request = require('request');
+
+  user.app_metadata = user.app_metadata || {};
+  if (user.app_metadata.recordedAsLead) {
+    return callback(null,user,context);
+  }
+
+  const MY_SLACK_WEBHOOK_URL = 'YOUR SLACK WEBHOOK URL';
+  const slack = require('slack-notify')(MY_SLACK_WEBHOOK_URL);
+
+  //Populate the variables below with appropriate values
+  const SFCOM_CLIENT_ID = configuration.SALESFORCE_CLIENT_ID;
+  const SFCOM_CLIENT_SECRET = configuration.SALESFORCE_CLIENT_SECRET;
+  const USERNAME = configuration.SALESFORCE_USERNAME;
+  const PASSWORD = configuration.SALESFORCE_PASSWORD;
+  getAccessToken(
+    SFCOM_CLIENT_ID,
+    SFCOM_CLIENT_SECRET,
+    USERNAME,
+    PASSWORD,
+    (response) => {
+      if (!response.instance_url || !response.access_token) {
+        slack.alert({
+          channel: '#some_channel',
+          text: 'Error Getting SALESFORCE Access Token',
+          fields: {
+            error: response
+          }
+        });
+
+        return;
+      }
+
+      createLead(
+        response.instance_url,
+        response.access_token,
+        (err, result) => {
+        if (err || !result || !result.id) {
+          slack.alert({
+            channel: '#some_channel',
+            text: 'Error Creating SALESFORCE Lead',
+            fields: {
+              error: err || result
+            }
+          });
+
+          return;
+        }
+
+        user.app_metadata.recordedAsLead = true;
+        auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
+      });
+    });
+
+  //See http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_lead.htm
+  function createLead(url, access_token, callback){
+    //Can use many more fields
+    const data = {
+      LastName: user.name,
+      Company: 'Web channel signups'
+    };
+
+    request.post({
+      url: url + "/services/data/v20.0/sobjects/Lead",
+      headers: {
+        "Authorization": "OAuth " + access_token
+      },
+      json: data
+      }, (err, response, body) => {
+        return callback(err, body);
+      });
+  }
+
+  //Obtains a SFCOM access_token with user credentials
+  function getAccessToken(client_id, client_secret, username, password, callback) {
+    request.post({
+      url: 'https://login.salesforce.com/services/oauth2/token',
+      form: {
+        grant_type: 'password',
+        client_id: client_id,
+        client_secret: client_secret,
+        username: username,
+        password: password
+      }}, (err, respose, body) => {
+        return callback(JSON.parse(body));
+      });
+  }
+
+  // don’t wait for the SF API call to finish, return right away (the request will continue on the sandbox)`
+  callback(null, user, context);
+}
+```
+
+## Keep reading
+
+Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples:
+
+* Rules for access control
+* Integration with other services: [MixPanel](http://mixpanel.com), [Firebase](http://firebase.com), [Parse](http://parse.com), [Splunk](https://www.splunk.com/), [Segment](https://segment.com/), [Keen](https://keen.io/)
diff --git a/ja-jp/articles/monitoring/guides/track-signups-salesforce.md b/ja-jp/articles/monitoring/guides/track-signups-salesforce.md
new file mode 100644
index 0000000000..6120985e99
--- /dev/null
+++ b/ja-jp/articles/monitoring/guides/track-signups-salesforce.md
@@ -0,0 +1,238 @@
+---
+title: Track New Sign-Ups in Salesforce
+description: Learn how to track your sign-ups in Salesforce MixPanel, enrich your user profiles with public information gathered from FullContact, and generate new sales leads.
+topics:
+  - monitoring
+  - marketing
+contentType:
+  - how-to
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - analyze-external-analytics
+  - integrate-analytics
+---
+
+# Track New Sign-Ups in Salesforce
+
+You can track new sign-ups in Salesforce with FullContact-Enriched User Profiles, and Send Auth0 Events to MixPanel.
+
+Whenever a new user signs up with a website using a social credential, you want to:
+
+1. __Record a `signup` event__ in [MixPanel](https://mixpanel.com).
+2. __Augment the user profile__ with additional public information through [FullContact](http://www.fullcontact.com/).
+3. __Record the sign-up as a New Lead__ in [Salesforce](http://www.salesforce.com/), so a sales professional can follow up.
+
+To implement this with Auth0, you need to create three [Rules](/rules) in your pipeline:
+
+![](/media/articles/tutorials/signups.png)
+
+## 1. Record sign-up event in MixPanel
+
+Create a rule to record the event by calling MixPanel. In the example below, we record the application name in the `application` property to help you filter information in MixPanel. However, the full `context` and `user` properties are available as sources of additional information (e.g., IP addresses, agent).
+
+::: note
+This rule will be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 3).
+:::
+
+```js
+function (user, context, callback) {
+
+  const request = require('request');
+
+  const mpEvent = {
+    "event": "Sign up",
+    "properties": {
+        "distinct_id": user.user_id,
+        "token": configuration.MIXPANEL_API_TOKEN,
+        "application": context.clientName
+    }
+  };
+
+  const base64Event = Buffer.from(JSON.stringify(mpEvent)).toString('base64');
+
+  request.get({
+    url: 'http://api.mixpanel.com/track/',
+    qs: {
+      data: base64Event
+    }
+  }, (err, res, body) => {
+      // don’t wait for the MixPanel API call to finish, return right away (the request will continue on the sandbox)`
+      callback(null, user, context);
+  });
+}
+```
+
+## 2. Enrich user profile with FullContact
+
+Create a rule to obtain more information about the user by retrieving public information from FullContact's API using the user's email address as input.
+
+Once the call to FullContact completes, we store this additional information in a property called `fullContactInfo`:
+
+:::note
+We ignore certain conditions that exist in the API and only do this when there's a successful call (`statusCode=200`). This rule will also be skipped if the user has already signed up, which is signaled by the `user.app_metadata.recordedAsLead` property being set to true (see step 3).
+:::
+
+```js
+function (user, context, callback) {
+
+  const request = require('request');
+
+  const FULLCONTACT_KEY = configuration.FULLCONTACT_KEY;
+  const SLACK_HOOK = configuration.SLACK_HOOK_URL;
+
+  const slack = require('slack-notify')(SLACK_HOOK);
+
+  // skip if no email
+  if (!user.email) return callback(null, user, context);
+
+  // skip if fullcontact metadata is already there
+  if (user.user_metadata && user.user_metadata.fullcontact) return callback(null, user, context);
+
+  request.get('https://api.fullcontact.com/v2/person.json', {
+    qs: {
+      email:  user.email,
+      apiKey: FULLCONTACT_KEY
+    },
+    json: true
+  }, (error, response, body) => {
+    if (error || (response && response.statusCode !== 200)) {
+
+      slack.alert({
+        channel: '#slack_channel',
+        text: 'Fullcontact API Error',
+        fields: {
+          error: error ? error.toString() : (response ? response.statusCode + ' ' + body : '')
+        }
+      });
+
+      // swallow fullcontact api errors and just continue login
+      return callback(null, user, context);
+    }
+
+    // if we reach here, it means fullcontact returned info and we'll add it to the metadata
+    user.user_metadata = user.user_metadata || {};
+    user.user_metadata.fullcontact = body;
+
+    auth0.users.updateUserMetadata(user.user_id, user.user_metadata);
+    context.idToken['https://example.com/fullcontact'] = user.user_metadata.fullcontact;
+    return callback(null, user, context);
+  });
+}
+```
+
+## 3. Create New Lead in Salesforce
+
+Create a rule to record the information as a New Lead in Salesforce, so the sales department can follow up. Please note:
+
+* The Salesforce REST API uses an OAuth Access Token. So for this rule, we use the OAuth2 `Resource Owner Password Credential Grant` to obtain this token, and use the `getToken` function, which uses credentials as input, as opposed to an `API-KEY` as was used in the rules in the previous steps.
+
+* In this example, we expect your Salesforce credentials to be stored in the [global `configuration` object](/rules/current#use-the-configuration-object). Be sure to add your credentials here before running your rule. Doing this allows you to use your credentials in multiple rules and prevents you from having to store them directly in the code.
+
+* For this rule, we record only the username and a fixed company name. However, we could use anything available in the enriched user profile we obtained in step 2 to record more information and provide additional context for the sales representative.
+
+* For this rule, we use a property called `user.app_metadata.recordedAsLead`, and if everything goes well, set it to true. The next time the user signs in, all of these rules will be skipped.
+
+
+```js
+function (user, context, callback) {
+
+  const request = require('request');
+
+  user.app_metadata = user.app_metadata || {};
+  if (user.app_metadata.recordedAsLead) {
+    return callback(null,user,context);
+  }
+
+  const MY_SLACK_WEBHOOK_URL = 'YOUR SLACK WEBHOOK URL';
+  const slack = require('slack-notify')(MY_SLACK_WEBHOOK_URL);
+
+  //Populate the variables below with appropriate values
+  const SFCOM_CLIENT_ID = configuration.SALESFORCE_CLIENT_ID;
+  const SFCOM_CLIENT_SECRET = configuration.SALESFORCE_CLIENT_SECRET;
+  const USERNAME = configuration.SALESFORCE_USERNAME;
+  const PASSWORD = configuration.SALESFORCE_PASSWORD;
+  getAccessToken(
+    SFCOM_CLIENT_ID,
+    SFCOM_CLIENT_SECRET,
+    USERNAME,
+    PASSWORD,
+    (response) => {
+      if (!response.instance_url || !response.access_token) {
+        slack.alert({
+          channel: '#some_channel',
+          text: 'Error Getting SALESFORCE Access Token',
+          fields: {
+            error: response
+          }
+        });
+
+        return;
+      }
+
+      createLead(
+        response.instance_url,
+        response.access_token,
+        (err, result) => {
+        if (err || !result || !result.id) {
+          slack.alert({
+            channel: '#some_channel',
+            text: 'Error Creating SALESFORCE Lead',
+            fields: {
+              error: err || result
+            }
+          });
+
+          return;
+        }
+
+        user.app_metadata.recordedAsLead = true;
+        auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
+      });
+    });
+
+  //See http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_lead.htm
+  function createLead(url, access_token, callback){
+    //Can use many more fields
+    const data = {
+      LastName: user.name,
+      Company: 'Web channel signups'
+    };
+
+    request.post({
+      url: url + "/services/data/v20.0/sobjects/Lead",
+      headers: {
+        "Authorization": "OAuth " + access_token
+      },
+      json: data
+      }, (err, response, body) => {
+        return callback(err, body);
+      });
+  }
+
+  //Obtains a SFCOM access_token with user credentials
+  function getAccessToken(client_id, client_secret, username, password, callback) {
+    request.post({
+      url: 'https://login.salesforce.com/services/oauth2/token',
+      form: {
+        grant_type: 'password',
+        client_id: client_id,
+        client_secret: client_secret,
+        username: username,
+        password: password
+      }}, (err, respose, body) => {
+        return callback(JSON.parse(body));
+      });
+  }
+
+  // don’t wait for the SF API call to finish, return right away (the request will continue on the sandbox)`
+  callback(null, user, context);
+}
+```
+
+## Keep reading
+
+Check out our [repository of Auth0 Rules](https://github.com/auth0/rules) for more great examples:
+
+* Rules for access control
+* Integration with other services: [Firebase](http://firebase.com), [TowerData](https://www.towerdata.com/email-intelligence/email-enhancement), [Parse](http://parse.com), [Splunk](https://www.splunk.com/), [Segment](https://segment.com/), [Keen](https://keen.io/)
diff --git a/ja-jp/articles/monitoring/index.md b/ja-jp/articles/monitoring/index.md
new file mode 100644
index 0000000000..7fd1ac6b73
--- /dev/null
+++ b/ja-jp/articles/monitoring/index.md
@@ -0,0 +1,46 @@
+---
+title: Monitor Auth0 Implementations
+description: Understand how to monitor your Auth0 implementation and track your Auth0 usage, as well as how to send events and logs to external tools.
+topics:
+  - monitoring
+contentType:
+  - concept
+  - index
+useCase:
+  - analyze-auth0-analytics
+  - analyze-logs
+  - integrate-analytics
+---
+# Monitor Auth0 Implementations
+
+You can monitor your Auth0 implementation and Auth0 status and services, as well as send logging event data to third-party tools.
+
+<%= include('./_includes/_monitor-private-cloud.md') %>
+
+## Check availability and status
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Auth0 Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+
+## Log events
+
+Need to analyze logs or store them long-term? Auth0 provides extensions to [export logs to external tools](/logs) for analysis and retention. You can also retrieve log data with the Management API. Auth0 only retains logs for a limited period of time, governed by the type of subscription purchased. If your required data retention period is longer than the retention period for your subscription,export logs so you can keep them as long as you wish.
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [Log Data Retention](/logs/references/log-data-retention)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Send Logging Events to Keen](/monitoring/guides/send-events-to-keenio)
+* [Send Logging Events to Segment](/monitoring/guides/send-events-to-segmentio)
+* [Send Logging Events to Splunk](/monitoring/guides/send-events-to-splunk)
+* [Send Logging Events to Loggly](/extensions/loggly)
+* [Send Logging Events to Mixpanel](/extensions/mixpanel)
+
+## Track new signups and leads
+
+* [Track New Sign-Ups in Salesforce](/monitoring/guides/track-signups-salesforce)
+* [Track New Leads in Salesforce](/monitoring/guides/track-leads-salesforce)
diff --git a/ja-jp/articles/onboarding/appliance-sprint.md b/ja-jp/articles/onboarding/appliance-sprint.md
new file mode 100644
index 0000000000..1beb874949
--- /dev/null
+++ b/ja-jp/articles/onboarding/appliance-sprint.md
@@ -0,0 +1,58 @@
+---
+sitemap: false
+section: appliance
+description: PSaaS Appliance Sprint is Auth0’s onboarding program for enterprise customers choosing an PSaaS Appliance. It helps you achieve value quickly with your Auth0 enterprise subscription.
+topics:
+  - appliance
+  - onboarding
+contentType:
+  - concept
+useCase:
+  - appliance
+applianceId: appliance64
+---
+# PSaaS Appliance Deployment Project
+
+PSaaS Appliance Sprint is Auth0’s onboarding program for enterprise customers choosing an PSaaS Appliance. It helps you achieve value quickly with your Auth0 enterprise subscription.
+
+Sprint is Auth0’s onboarding program for enterprise customers.  For customers subscribed to an Auth0 private instance to be deployed on-premises or in the customers cloud provider of choice, the first part of the Sprint program will be the PSaaS Appliance deployment project.  Here's an overview of the main steps:
+
+## PSaaS Appliance Deployment Project Overview
+
+The following sections describe what happens during each step of the PSaaS Appliance deployment process.
+
+### Step 1 - Project Kickoff
+
+**When?**  This session is generally booked within 5 days of signing your subscription agreement.
+
+**What?** Deploying the PSaaS Appliance on your cloud or on-premises infrastructure is a team effort.  This is where we run through how we’re going to get it done!  An Auth0 project manager will work with your designated project manager to build the project plan in this session.
+
+[PSaaS Appliance Docs](/appliance) - Get up to speed on all things PSaaS Appliance in this high level overview doc.
+
+### Step 2 - Infrastructure Ready
+
+**When?**  Varies by customer and complexity of their deployment.  Ideally 1-3 weeks after signing the subscription agreement.
+
+**What?** Your team prepares the relevant infrastructure based on our guidance.
+
+[PSaaS Appliance Infrastructure Requirements Docs](/appliance/infrastructure)
+
+### Step 3 - PSaaS Appliance Setup
+
+**When?**  Varies by customer and complexity of their deployment.  Ideally 2-4 weeks after signing the subscription agreement.
+
+**What?** Our team configures the PSaaS Appliance on your infrastructure.
+
+### Step 4 - PSaaS Appliance Handover
+
+**When?** 30-45 days after signing your subscription agreement.
+
+**What?** An operational handover session with your team to learn how to administer the PSaaS Appliance.
+
+[PSaaS Appliance Configuration](/appliance/dashboard) - See our Docs on the configuration settings within the Appliance.
+
+[PSaaS Appliance Administrator's Manual](/appliance/admin)
+
+## What's next?
+
+Once the PSaaS Appliance is deployed, an Auth0 Technical Account Manager will work with you to build a joint success plan to drive value throughout the subscription lifecycle.
\ No newline at end of file
diff --git a/ja-jp/articles/onboarding/enterprise-support.md b/ja-jp/articles/onboarding/enterprise-support.md
new file mode 100644
index 0000000000..1a2979c5fe
--- /dev/null
+++ b/ja-jp/articles/onboarding/enterprise-support.md
@@ -0,0 +1,123 @@
+---
+toc: true
+section: appliance
+description: Outlines the Auth0 enterprise support options, definitions, coverage offered and procedures to follow for the best support experience.
+topics:
+  - appliance
+  - onboarding 
+contentType:
+  - concept
+useCase:
+  - appliance
+applianceId: appliance66
+---
+# Enterprise Support Guidance
+
+This document outlines the Auth0 enterprise support options, definitions, coverage offered, and procedures to follow for the best support experience.  It is relevant for customers only with Enterprise Plan subscription agreements, which differ from the standard pay-as-you-go/self-service subscription offerings acquired directly from our website.
+
+Refer to your subscription agreement to confirm which support offering is included in your subscription.
+
+## For General Queries
+
+For general queries related to functionality, integration, best practice, or advice, you can use the following resources:
+
+- The [Auth0 Community](https://community.auth0.com/): Post questions to our audience of Customer Success Engineers, as well as other Auth0 users, or search and read existing posts for useful information.
+- Your __Technical Account Manager__: Your Auth0 Technical Account Manager is always available for general queries and helping you navigate to the right Auth0 resource.  The orientation information you received during onboarding should have the contact details for your Technical Account Manager.
+- The [Auth0 Docs](/search#gsc.tab=0)
+
+## For Issues Impacting Production Environments (SLA Applicable)
+
+::: note
+
+Critical Production issues should always be reported via the [Support Center](${env.DOMAIN_URL_SUPPORT}) for fastest response.
+
+[Learn more about creating tickets with Support Center](/support/tickets)
+:::
+
+
+For the purposes of the following descriptions, the following capitalized words and phrases are ascribed the following meanings:
+
+**“Defect”** means a failure of the Auth0 Platform, in the form provided or modified by Auth0, to conform to its applicable specifications set forth in the Documentation. A Defect includes a failure of one or more components of the environment or infrastructure provided by Auth0 or AWS to perform in accordance with their applicable documentation or specifications.
+
+**“Demand Services”** has the meaning ascribed to it in Section 7 below.
+
+**“Fix”** means a modification or an addition to the Auth0 Platform that overcomes a Defect when made or added to the Auth0 Platform. Auth0 may provide a Workaround in lieu of a Fix in Auth0’s sole discretion, but will provide a Fix to you as specified in Section 3.2 below.
+
+**“Response Time”** means, for purposes of this Support Program description, the time between Auth0’s receipt of a Defect notification from you, and Auth0’s confirmation via one of its personnel that Auth0 is working on resolution of the Defect. (While your submission of a trouble ticket may trigger an automated response from Auth0, automated responses are disregarded for purposes of determining Response Times.)
+
+**“Update”** means a patch, correction, or other modification or addition to the Auth0 Platform that Auth0 makes generally available to you for maintenance fixes, Defect corrections, and minor improvements to the Auth0 Platform, including fixes, patches, updates and releases to address any security vulnerabilities. “Update” also includes significant enhancements, or new features or functionalities that Auth0 makes generally available to you.  
+
+**“Workaround”** means a set of procedures that you may follow to circumvent or mitigate the impact of a Defect, notwithstanding that the Defect still exists.
+
+## Defect Resolution Procedures
+
+Auth0 will assign all Defects one of four response priorities, dependent upon the problems caused by the Defect. Auth0 may re-assign prioritization levels assigned by you in Auth0’s trouble ticketing system, to reflect the problem descriptions below. Auth0’s assignment will be consistent with the problem descriptions described below. Priority categories are as follows:
+
+| Severity Level | Description |
+| - | - |
+| 1 (Urgent) | **Emergency Issue**. Defect resulting in full or partial system outage or a condition that makes the Auth0 Platform unusable or unavailable in production for all of your Users. |
+| 2 (High) | **Significant Business Impact**. Defect resulting in a condition where major functionality is impacted or significant performance degradation is experienced; issue is persistent and affects many Users and/or major functionality. |
+| 3 (Normal) | **Minor Feature / Function Issue / General Question**. Defect results in a component of the Auth0 Platform not performing as expected or documented **or** an inquiry by your representatives regarding general technical issues/questions |
+| 4 (Low) | **Minor Problem / Enhancement Request**. Information requested on Auth0 Platform capabilities, navigation, installation, or configuration; enhancement request. |
+
+## Guidance for Logging Support Issues
+
+To ensure that your support issue is assigned the correct priority and SLA, it must be logged via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}). Other methods may not track your issue correctly.
+
+## What to Expect
+
+After you've correctly logged your issue:
+
+1. Your issue will be acknowledged immediately to confirm that it was submitted successfully. You'll be assigned and receive a ticket ID number.
+2. Auth0 support staff may direct you to join a private Slack channel and/or a Zoom web conference to facilitate faster communications. Please remember that you should not initiate support requests via Slack -- you should only use the [Support Center](${env.DOMAIN_URL_SUPPORT}).
+3. Be sure to send any critical information, such as log files, issue-related descriptions, and so on, to the [Support Center](${env.DOMAIN_URL_SUPPORT}) so that they can be attached to the ticket you opened.
+
+Upon resolution of the issue, an Auth0 support staff member will ask you for confirmation the issue has been resolved to you satisfaction. The ticket will be closed only when you have responded and confirmed issue is resolved.
+
+## What to Check Before Logging an Issue
+
+To speed resolution, please check the following before logging an issue:
+
+* Is the issue experienced by all users or just a few?
+  * All? - Could be a service or configuration issue
+    * Check status of Auth0 service
+      * Americas: (https://status.auth0.com)
+      * EU Region: (https://status.auth0.com/?region=EU)
+      * APAC Region: (https://status.auth0.com/?region=AU)
+      * You can subscribe to updates via the button on those pages
+    * Check authentication services (connections) are up and reachable
+    * Check application components - make sure they are functioning
+    * Check certificates - make sure valid/not expired (cert-related errors)
+    * Check NTP running on Auth0 AD/LDAP connector, IDPs
+    * Check if any Rules have changed recently
+    * Check if any recent changes on IDPs that could cause error
+    * Can users log into other apps that use the same authentication provider?
+  * Few users impacted - usually a user profile or browser/device issue
+    * Have user clear cookies and try again
+    * Make sure user isn’t hitting the ‘back’ button
+    * Make sure user has cookies and javascript turned on in browser
+    * Check user profile in the authentication service
+    * Check if any rules changed recently that impact user profile
+    * Is user device in violation of MDM device policies (if used)
+    * Does it happen consistently and can be repeated?
+
+## Information to Provide When Logging an Issue
+
+To speed resolution, please provide the following when logging an issue:
+
+* Name of Auth0 account/tenant
+* Name of application(s)
+* Name of connection(s)
+* Description of the problem - what happens?  How far into login sequence does user get? (for example, does issue happen before or after entering credentials, and so on)
+* When did it start?  (first noticed)
+* Issue experienced by all users or just some?
+* Issue experienced by users every time or just some times?
+* Issue experienced with all browsers or just one?
+* Screenshot of error message (if any)
+* HTTP trace in the form of a [HAR file](/troubleshoot/guides/generate-har-files)
+
+*For Private Cloud Customers*:
+
+* Private Cloud version/build number (top left hand corner of configuration screen on config tenant, such as https://yourmanage.yourdomain.com/configuration#/)
+* Status of nodes (https://yourmanage.yourdomain.com/configuration#/nodes)
+* Status of health check (https://yourmanage.yourdomain.com/configuration#/troubleshoot)
\ No newline at end of file
diff --git a/ja-jp/articles/policies/billing.md b/ja-jp/articles/policies/billing.md
new file mode 100644
index 0000000000..2de85a2518
--- /dev/null
+++ b/ja-jp/articles/policies/billing.md
@@ -0,0 +1,120 @@
+---
+description: Describes the Billing policy which governs requests for billing mechanisms within the Auth0 dashboard
+crews: crew-2
+topics:
+    - auth0-policies
+    - billing
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Billing Policy
+
+The following policy governs requests for billing mechanisms within the Auth0 dashboard.
+
+## Change of billing email address
+
+It is possible to change the billing email address, but for security reasons the request should be performed by a Tenant Administrator by filing a new ticket through our [Support Center](${env.DOMAIN_URL_SUPPORT}). A member of our support team will then contact you in that same ticket with steps on how the request will proceed.
+Please note that if you are not a Tenant Administrator, we will not process this request.
+
+### Special case
+
+Please note that the customers who created tenants via the Heroku hosting platform have to change the billing email address (or any other billing details) in those platforms. We cannot edit any billing information if you have used one of those services.
+
+## Why is my credit card failing?
+
+The only way to determine the reason for the failure is for the customer to contact their credit card company by calling the number on the back. This can be triggered by a credit card reaching the limit or simply being rejected by the bank, for example.
+
+### My credit card is failing and some features are not available anymore
+
+If your credit card fails to be charged, we automatically retry to charge it up to 4 times. If you fix the issue before the fourth failure (by entering new card information or by solving the issue with the bank), then the charge will go through and everything will work as expected.
+
+However, if the problem is not fixed prior to the fourth failure, all past due invoices will be manually initiated by Auth0. This means that you may be charged on an unexpected date.
+
+::: note
+If you are having issues with the service, it is not due to the credit card failing.
+:::
+
+## How can I cancel my subscription?
+
+Please proceed by downgrading your subscription to free or by cancelling your subscription via the Auth0 Dashboard.
+
+1. Login to the [Dashboard](${manage_url}).
+2. Click on your tenant name in the top right corner to bring up the associated dropdown box.
+3. Select **Settings**.
+4. On the [Tenant Settings](${manage_url}/#/tenant/) page, click on the **Subscription** tab.
+5. On the **Subscription** tab, scroll down to the box associated with the Free plan and click **Checkout**.
+6. To confirm your subscription change, click **Subscribe Now**.
+
+## Refunds
+
+### I signed up for a paid plan but haven't used my tenant since then, can I get a refund?
+
+We understand that sometimes developers create tenants for demo or testing purposes. So if you have a subscription plan, but you have not been using our service in a while and you would like to get a refund, you should [downgrade](/tutorials/cancel-paid-subscriptions#downgrade-a-paid-subscription-to-a-free-subscription) your tenant to use a Free Plan. Notice that we do not provide refunds for when a plan is downgraded to another paid one that has less features.
+
+If you have already downgraded, please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide information about why the tenant has not been used and for how long. Please note that this request must come from a Tenant Administrator.
+
+We will evaluate the case and verify that the tenant has not been used in the aforementioned period in order to process the refund. Please note that if we consider the usage of the tenant not to be minimal, we reserve the right to not refund your card.
+
+### I purchased more tenant subscriptions than desired/needed, can I get a refund?
+
+If you bought unneeded subscriptions, you are eligible for a refund. 
+
+Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator.
+
+### I purchased a wrong plan in self service or trial and would like to downgrade, can I get a refund?
+
+You can get a refund only for an unused portion of subscription of 3 months or less, when there has been no logins. 
+
+Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator.
+
+### Any other scenario not mentioned above
+
+Please explain the situation by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}), and provide all the information possible. Please note that this request must come from a Tenant Administrator.
+
+## Where can I get a copy of an invoice?
+
+Invoices can be seen directly in the Dashboard by going to the [Tenant Settings](${manage_url}/#/tenant/) and clicking on the **Payments** tab. There you view all your Payment History, and you can get the invoices by clicking on the corresponding month. Please note that only Tenant Administrators can see the invoices.
+
+## How can I get a receipt for my payment?
+
+The way to do this is by filing a ticket trough our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+Please note that you have to be a Tenant admin to do this request.
+
+Also, more than often the email which receives the receipt is the one that created the Auth0 tenant. Please make sure that you are in touch with the owner of that email. That person can also forward you the receipt of the payment. If you want to change this setting, please let us know through our [Support Center](${env.DOMAIN_URL_SUPPORT}).
+
+## Do you charge sales tax?
+
+For US-based customers, we will charge sales tax where applicable. This is dependent on your state's sales tax laws and requirements. For non-US customers, we will not charge sales tax.
+
+You can determine if you will be responsible for sales tax during the checkout process after you provide your billing address. If the billing address provided is tax-eligible, you'll see the sales tax added to your total. You will also see the sales tax amount on all of your Auth0 invoices and receipts.
+
+## In our pricing, what is the difference between internal and external users? Are they different technically?
+
+An active user is a user that has authenticated with a username/password combination, a Passwordless connection, or any social provider in a given calendar month.
+
+Auth0 counts users on a per-tenant basis. That means that somebody who logs in to multiple applications still counts as one user as long as you've created all of the applications using a single tenant.
+
+You will find that for certain plans, you have the ability to select between being charged for external users or for internal users. There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee.
+
+External users are most likely not going to be using Auth0 on a daily basis, and therefore this plan uses the active users criteria to calculate the price.
+
+On the other hand, internal users have to login everyday to their different tools and platforms in order to get the work done, so for this case you would pay a flat rate per user.
+
+## Can we scale the number of users as needed each month?
+
+Definitely. In the Dashboard, you can do this by going to the upper right corner, and selecting **Settings** from the drop down menu. Then in the **Subscriptions** tab you can select them depending on your needs. More information about it can be found there or in our [Pricing page](https://auth0.com/pricing/).
+
+## Can we combine billing for multiple tenants?
+
+Unfortunately combined billing is not supported for regular self-service tenants. The only two cases where we support combined billing are:
+
+1. For enterprise customers
+2. For customers whose master tenant is billed at $167 per month (or more). In this case, we mark the testing tenant as [a child tenant](https://auth0.com/docs/dev-lifecycle/child-tenants) and bill only the master tenant.
+
+## How can I convert my tenant from a free trial to any other version?
+
+You can do this by heading to the upper right corner of the Dashboard, clicking your tenant name and selecting **Settings**. Then in the **Subscriptions** tab you can select the plan that best suits your needs. More information about this can be found there or in our [Pricing page](https://auth0.com/pricing/).
diff --git a/ja-jp/articles/policies/dashboard-authentication.md b/ja-jp/articles/policies/dashboard-authentication.md
new file mode 100644
index 0000000000..23d1a8d253
--- /dev/null
+++ b/ja-jp/articles/policies/dashboard-authentication.md
@@ -0,0 +1,47 @@
+---
+description: Describes the Dashboard Authentication Policy which governs requests for special authentication mechanisms for the Auth0 dashboard.
+crews: crew-2
+topics:
+    - auth0-policies
+    - dashboard
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Dashboard Authentication Policy
+
+The following policy governs requests for special authentication mechanisms for the Auth0 dashboard.
+
+## Multi-factor Authentication
+
+You can enable multi-factor authentication for logging in to the dashboard with your account.
+
+To enable multi-factor authentication for your account: 
+
+1. Go to your [Account Profile page](${manage_url}/#/profile)
+2. Scroll down to the **Multi-factor** section.
+3. Click the **Enroll Your Device Now** link to get started.
+
+The process for setting up each form of authentication is the same as using MFA with an application, [click here for more information on each type of authentication.](/mfa)
+
+### Unenrolling a Device from Multi-factor
+
+To stop using multi-factor authentication to log in to your dashboard:
+
+1. Go to your [Account Profile page](${manage_url}/#/profile)
+2. Scroll down to the **Multi-factor** section and click the **REMOVE** button next to the enrolled device.
+3. To verify this request you will need to login once more with multi-factor authentication.
+
+## Other forms of authentication
+
+At this time, other forms of authentication for dashboard authentication are not supported.
+
+## Effectivity
+
+This policy is effective April 4, 2016
+
+This policy may be revised when we are able to make configuration and troubleshooting visibility available on a self-service basis for other forms of authentication.
+
+Any accounts with special dashboard authentication implemented before the effective date of this policy shall be allowed to continue.
diff --git a/ja-jp/articles/policies/data-export.md b/ja-jp/articles/policies/data-export.md
new file mode 100644
index 0000000000..e4442cef34
--- /dev/null
+++ b/ja-jp/articles/policies/data-export.md
@@ -0,0 +1,26 @@
+---
+description: Auth0 policies on exporting data.
+topics:
+    - auth0-policies
+    - data 
+    - data-exports
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Data Export Policy
+
+If you would like to export your data from Auth0 there are a several ways you can do this. Please note these tools do not export password hashes of your [Auth0-hosted database users](/connections/database). You can still request this information by opening a [support ticket](https://support.auth0.com/). Please note that in order to make this request you must be signed in to the Developer plan for one month.
+
+## Use the Import/Export Extension
+
+You can use our [Import/Export Extension](/extensions/user-import-export) to export nearly all data in your Auth0 tenant. 
+
+## Use the Management API
+
+If you want to export certain sets of data programmatically, the **Management API** can assist you with this. For more information on using the Management API, you can:
+
+* Browse the [Management API documentation](/api/management/v2).
+* Read about [obtaining a token](/api/management/v2/tokens) which you can use to call the Management API.
+* Read about [searching for users](/users/search) as well as the [query syntax](/users/search/v3/query-syntax) that can be used.
diff --git a/ja-jp/articles/policies/data-transfer.md b/ja-jp/articles/policies/data-transfer.md
new file mode 100644
index 0000000000..e3cd3206a9
--- /dev/null
+++ b/ja-jp/articles/policies/data-transfer.md
@@ -0,0 +1,27 @@
+---
+description: Describes the Data Transfer Policy which governs requests for transfer of data from one Auth0 tenant to another.
+topics:
+    - auth0-policies
+    - data
+    - data-transfer
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Data Transfer Policy
+
+At this time, Auth0 will not transfer data from one Auth0 tenant to another. This applies to both Public Cloud and Private Cloud customers.
+
+All data in your Auth0 tenant is always under your control and is [available through the Management API](/api/v2) at any time. The only information which is not available through the API are the password hashes of your [Auth0-hosted database users](/connections/database) and private keys, for security reasons.
+
+If you are opting to move out from our service, then you might want to check [this section](/moving-out). Please notice that in order to make this request you must be signed in to the Developer plan for one month.
+
+## Frequently made requests that are not supported
+
+* Transfer data from a non-production tenant to a production tenant
+* Rename a tenant
+* Re-use the name of a previously deleted tenant
+* Rename a connection
+* Migrate a tenant from one region to another (for example, from US to EU)
diff --git a/ja-jp/articles/policies/endpoints.md b/ja-jp/articles/policies/endpoints.md
new file mode 100644
index 0000000000..0ad9cc03ba
--- /dev/null
+++ b/ja-jp/articles/policies/endpoints.md
@@ -0,0 +1,32 @@
+---
+description: Lists all the endpoints used by Auth0 public cloud service.
+topics:
+    - auth0-policies
+    - endpoints
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Auth0 Public Cloud Service Endpoints
+
+The following endpoints are used by Auth0 public cloud service:
+
+## United States Region
+
+* https://manage.auth0.com
+* https://auth0.com
+* https://login.us.auth0.com
+* https://cdn.us.auth0.com (or https://cdn.auth0.com if your tenant was created prior to 11 June 2020)
+* https://{YOUR ACCOUNT}.us.auth0.com
+* https://{YOUR ACCOUNT}.guardian.us.auth0.com 
+
+## Europe and Australia Regions
+
+* https://manage.auth0.com
+* https://auth0.com
+* https://login.[eu|au].auth0.com
+* https://cdn.[eu|au].auth0.com
+* https://{YOUR ACCOUNT}.[eu|au].auth0.com
+* https://{YOUR ACCOUNT}.guardian.[eu|au].auth0.com
diff --git a/ja-jp/articles/policies/entity-limits.md b/ja-jp/articles/policies/entity-limits.md
new file mode 100644
index 0000000000..24f00d44c1
--- /dev/null
+++ b/ja-jp/articles/policies/entity-limits.md
@@ -0,0 +1,52 @@
+---
+title: Entity Limit Policy
+description: Describes Auth0's tenant entity limit policy for subscribers.
+topics:
+    - auth0-policies
+    - rate-limits
+    - entity-limits
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Entity Limit Policy
+
+::: note
+This policy is effective for all Developer, Developer Pro, and free subscriptions made on or after May 19, 2020. Starting on **June 18, 2020**, the policy will apply to all Developer, Developer Pro, and free subscriptions.
+:::
+
+Entities in Auth0 are tenant configuration elements such as applications, connections, rules, and API resource servers. 
+
+Auth0 limits the number of entities you can have depending on your subscription level. Auth0 provides notifications to you when you are approaching (80%) and when you have reached your respective entity limits (100% or higher). We will also provide messages to prevent you from attempting to configure entities that would be rejected because they would put you over your limit. Here is an example of a message you would see if you reached your connection limit:
+
+![Entity Limit Reached](/media/articles/policies/entity-limit-reached.png)
+
+::: note
+Entity counts may take a few seconds to update. If you see a warning that you believe is in error, try again after a few seconds or contact support if the issue persists.
+:::
+
+## Developer and Developer Pro subscription limits
+
+| Entity | Maximum | 
+| - | - |
+| Applications | 100 |
+| Connections | 100 |
+| Rules | 100 |
+| API Resource Servers | 100 |
+
+## Free subscription limits
+
+| Entity | Maximum | 
+| - | - |
+| Applications | 10 |
+| Connections | 10 |
+| Rules | 10 |
+| API Resource Servers | 10 |
+
+## Keep reading
+
+* [Rate Limit Policy](/policies/rate-limits)
+* [Management API Endpoint Rate Limits](/policies/rate-limits-mgmt-api)
+* [Authentication API Endpoint Rate Limits](/policies/rate-limits-auth-api)
+* [Legacy Rate Limits](/policies/legacy-rate-limits)
diff --git a/ja-jp/articles/policies/index.md b/ja-jp/articles/policies/index.md
new file mode 100644
index 0000000000..f404b79512
--- /dev/null
+++ b/ja-jp/articles/policies/index.md
@@ -0,0 +1,26 @@
+---
+url: /policies
+description: List of all of Auth0's established operational policies.
+topics:
+    - auth0-policies
+contentType:
+  - index
+useCase:
+  - support
+---
+# Operational Policies
+
+Auth0 has established the following operational policies.
+
+-  [Billing](/policies/billing)
+-  [Dashboard Authentication](/policies/dashboard-authentication)
+-  [Data Export](policies/data-export)
+-  [Data Transfer](/policies/data-transfer)
+-  [Endpoints](/policies/endpoints)
+-  [Load Testing](/policies/load-testing)
+-  [Penetration Testing](/policies/penetration-testing)
+-  [Migrations](/migrations)
+-  [Rate Limits](/policies/rate-limits)
+-  [Entity Limits](/policies/entity-limits)
+-  [Tenant Restoration](/policies/restore-deleted-tenant)
+-  [Unsupported Requests](/policies/unsupported-requests)
\ No newline at end of file
diff --git a/ja-jp/articles/policies/legacy-rate-limits.md b/ja-jp/articles/policies/legacy-rate-limits.md
new file mode 100644
index 0000000000..a1ddda609d
--- /dev/null
+++ b/ja-jp/articles/policies/legacy-rate-limits.md
@@ -0,0 +1,173 @@
+---
+description: Describes Auth0's rate limit policy for subscriptions created before 05-21-2020 when working with Auth0 API endpoints.
+topics:
+    - auth0-policies
+    - rate-limits
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Management API Endpoint Rate Limits before May 19, 2020
+
+**This policy is effective for all paid and free subscriptions made before May 19, 2020.** 
+
+::: warning
+All subscriptions made on or after **May 19, 2020** are subject to the [updated rate limits](/policies/rate-limits-mgmt-api). 
+Starting on **June 18, 2020**, the new limits will apply to all tenants. You will be notified of the new limits through a **Dashboard Notification**. If the changes will impact your tenant, you will be notified directly via email with additional information about minimizing API calls and upgrading plans.
+:::
+
+The rate limits for Auth0 Management API differ depending on whether your tenant is free or paid, production or not.
+
+| Tenant Type | Limit |
+| - | - |
+| Free or Trial | 2 requests per second (and bursts up to 10 requests) |
+| Non-Production (Paid) | 2 requests per second (and bursts up to 10 requests) |
+| Production (Paid) | 15 requests per second (and bursts up to 50 requests) |
+
+The aforementioned rate limits include calls made via [Rules](/rules) and are set **by tenant** and not by endpoint.
+
+The following Auth0 Management API endpoints return rate limit-related headers. For additional information about these endpoints, please consult the [Management API explorer](/api/management/v2).
+
+
+  
+    
+      
+      
+      
+      
+      
+      
+    
+  
+  
+  
+      
+      
+      
+      
+      
+      
+  
+    
+    
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+      
+      
+      
+      
+      
+      
+  
+  
+
    EndpointGETPOSTDELETEPATCHPUT
    Application Grants/client-grants/client-grants/client-grants/{id}/client-grants/{id}
    Signing Keys/keys/signing
    /keys/signing/{id}    		/keys/signing/rotate
    Limited to 5 requests per day    		/keys/signing/{kid}/revoke
    Applications/client 
    /client/{id}    		/client/client/{id}/client/{id}
    Connections/connections 
    /connections/{id}    		/connections/connections/{id} 
    /connections/{id}/users    		/connections/{id}
    Device Credentials/device-credentials/device-credentials/device-credentials/{id}
    Logs/logs 
    /log/{id}
    Rules/rules 
    /rules/{id}    		/rules/rules/{id}/rules/{id}
    User Blocks/user-blocks 
    /user-blocks/{id}    		/user-blocks 
    /user-blocks/{id}
    Users/users 
     /users/{id} 
    /users/{id}/logs 
    /users/{id}/enrollments    		/users 
    /users/{id}/identities    		/users/{id} 
    /users/{id}/identities 
    /users/{id}/multifactor/{provider}    		/users/{id}
    Emails/emails/provider/emails/provider/emails/provider
    Jobs/jobs/{id} 
     /jobs/{id}/errors    		/jobs/verification-email 
    /jobs/users-imports 
    /jobs/users-exports
    Resource Servers/resource-servers 
    /resource-servers/{id}    		/resource-servers/resource-servers/{id}/resource-servers/{id}
    Stats/stats/active-users 
    /stats/daily
    Tenants/tenants/settings/tenants/settings
    
+
+#### Concurrent import users jobs
+
+The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of two concurrent import jobs. Requesting additional jobs while there are two pending returns a `429 Too Many Requests` response:
+
+```json
+{
+  "statusCode": 429,
+  "error": "Too Many Requests",
+  "message": "There are 2 active import users jobs, please wait until some of them are finished and try again
+}
+```
+
+#### Access tokens for SPAs
+
+If you obtain Access Tokens for your SPAs, note that there are rate limits that are applicable when working with the available `current_user`-related [scopes and endpoints](/api/management/v2/get-access-tokens-for-spas#available-scopes-and-endpoints). You are allowed a maximum of **10 requests per minute per user**.
diff --git a/ja-jp/articles/policies/load-testing.md b/ja-jp/articles/policies/load-testing.md
new file mode 100644
index 0000000000..fe8a00fbdb
--- /dev/null
+++ b/ja-jp/articles/policies/load-testing.md
@@ -0,0 +1,71 @@
+---
+description: This page details Auth0's Load Testing Policy.
+topics:
+    - auth0-policies
+    - load-testing
+    - testing
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Load Testing Policy
+
+Auth0 recognizes that customers may occasionally need to perform load tests against its production cloud service. In order to ensure a successful test and maintain a high quality of service for all customers, Auth0 has established the following guidelines. Any load testing in Auth0 must be conducted in accordance with this Policy.
+
+Only customers who have purchased an Enterprise subscription may conduct load testing. Free, Developer, Developer Pro and other non-Enterprise customers may not conduct load testing. Customers with an Enterprise subscription may request one load test (with up to 2 repeats) per year against an Auth0 production tenant. Performance and load testing is only allowed with Auth0's prior written approval. Once approved, testing can only target tenants that we have approved.
+
+::: note
+Auth0 reserves the right to reject the load test request or ask for modifications. Failure to abide by this policy may result in temporary blocking of access to a tenant until the issue is remediated.
+:::
+
+## How to request
+
+Customers must file a load testing request via the Auth0 Support Center. Under the Issue typefield, select Public Cloud Support Incident.
+
+To be considered for approval, the request must:
+
+* Be filed at least two (2) weeks prior to the desired test date; in many cases, Auth0 encourages one (1) month of advance notice to ensure time for a thorough review and any required modifications.
+* Be approved in writing before any testing is conducted.
+* Stay within our [published production rate limits](/policies/rate-limits).
+* Include all information described below.
+
+## Information to include in requests
+
+The load testing request must include the following:
+
+* A description of the test to be done
+* The name and region of the Auth0 tenant to be used during the test
+* The requested date and time of the test, including time zone
+* The requested duration of the test (2 hour maximum)
+* The platforms to be used for the test (desktop/laptop, iOS, Android, other)
+* The Auth0 features (such as rules or email) used during the test
+* The Auth0 API methods and endpoints to be used (for example `GET /api/v2/clients`)
+* The maximum requests per second for each type of request or endpoint
+* The types of Auth0 connections involved in the test
+* Which Auth0 Rules, if any, will execute during the test
+* Which Custom DB, if any, will be used
+* Which Auth0 Webtasks, if any, will be used
+* Whether verification, welcome or other emails will be sent
+* The peak load, specified in requests-per-second, expected for each API endpoint or Auth0 feature involved in the test
+* An explanation/justification for the peak load numbers, including the size of the target user population and realistic estimates of logins per hour
+* The ramp-up rate for the test
+* Contacts who will be available during the test and how to reach them
+* Number of unique users participating in the load test
+
+## Email considerations
+
+Before any testing, customers must:
+
+* Configure their own email provider in Auth0
+* Receive approval from their email provider to send the expected volume of email
+* Make arrangements for bounced emails
+* Establish a mechanism for testing that emails arrived
+
+## Test requirements
+
+Load testing windows are subject to availability so advance notice is highly recommended. Once approved, load testing windows will have a scheduled start and end time not to exceed two (2) hours in duration. All testing must begin and end during this window.
+
+Auth0 strongly recommends including a brief "ramp up" period to the desired load test target numbers. For example, a load test request of 100 RPS might be preceded by three five minute periods: 5 minutes at 25 RPS, 5 minutes at 50 RPS, and 5 minutes at 75 RPS. This ramp up period allows Auth0 and the customer to observe and compare effects at increasing RPS levels prior to peak RPS. If a ramp up period is not possible, please indicate why.
+
+_Updated February 4, 2019_
diff --git a/ja-jp/articles/policies/penetration-testing.md b/ja-jp/articles/policies/penetration-testing.md
new file mode 100644
index 0000000000..850efd2fc0
--- /dev/null
+++ b/ja-jp/articles/policies/penetration-testing.md
@@ -0,0 +1,48 @@
+---
+description: This page details Auth0's Penetration Testing Policy.
+topics:
+    - auth0-policies
+    - penetration-testing
+    - testing
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Penetration Testing Policy
+
+**This policy is effective July 1, 2019.**
+
+If you have a *paid* Auth0 subscription, you may conduct a security test of your application involving Auth0 infrastructure (e.g. `your-tenant.auth0.com`) with **prior approval**.
+
+To conduct a security test, please notify us in advance via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}). Auth0 requires at least **1 week's (7 days')** notice prior to your test's planned start date.
+
+If the test is isolated to your infrastructure (that is, there will be no testing of Auth0 services), you do not need to notify Auth0.
+
+## Information required
+
+Please provide the following information in the support ticket when requesting approval for testing:
+
+1. The specific dates/times of the test and timezone
+2. The high level scope of the test
+3. IP address(es) the scan will come from
+4. The Auth0 tenant(s) involved
+5. Two (2) contacts who will be available during the entire test period in case we need to contact you. If we have any questions, we will make a reasonable attempt to contact you. If you cannot be reached, we reserve the right to take measures to protect the service, which may include shutting down or blocking your tenant and/or the source of the intrusion traffic.
+
+## Requirements
+
+Auth0 requires that:
+
+* The test be restricted to only your tenant
+* You disclose any suspected findings to the Auth0 Security team for explanation/discussion
+* You understand that your tenant will be moved between environments during testing. Auth0 will move your tenant from the Production environment to the Preview environment before the testing commences. Auth0 will then return your tenant to the Production environment once the testing period ends. Note that while your tenant is on the Preview environment it may receive updates more rapidly.
+
+## Private Cloud customers
+
+Private Cloud customers should also request permission to run a penetration test via the [Auth0 support center](${env.DOMAIN_URL_SUPPORT}). Please include the [information listed above](/policies/penetration-testing#information-required) with your support request.
+
+## Restrictions
+
+* You may not conduct any [load testing](/policies/load-testing) (such as Denial of Service testing) per the load testing policy.
+* You may not conduct any penetration testing targeting our management dashboard. Management and Authentication APIs are allowed.
+* You may not conduct any penetration testing targeting tenants that we have not approved.
diff --git a/ja-jp/articles/policies/rate-limits-auth-api.md b/ja-jp/articles/policies/rate-limits-auth-api.md
new file mode 100644
index 0000000000..546658f45a
--- /dev/null
+++ b/ja-jp/articles/policies/rate-limits-auth-api.md
@@ -0,0 +1,297 @@
+---
+title: Authentication API Endpoint Rate Limits
+description: Describes Auth0's rate limit policy when working with Auth0 Authentication API endpoints.
+toc: true
+topics:
+    - auth0-policies
+    - rate-limits
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Authentication API Endpoint Rate Limits
+
+Each Authentication API endpoint is configured with a bucket that defines:
+
+-  Request limit
+-  Rate limit window (per second, per minute, per day, etc.)
+
+```text
+bucket:
+    size: x
+    per_minute: y
+```
+
+For example, the above states that, for the given bucket, there is a maximum request limit of `x` per minute, and for each minute that elapses, permissions for `y` requests are added back. In other words, for each `60 / y` seconds, one additional request is added to the bucket. This occurs automatically until the bucket contains the maximum permitted number of requests.
+
+For some API endpoints, the rate limits are defined per bucket, so the origins of the call do not influence the rate limit changes. For other buckets, the rate limits are defined using different keys, so the originating IP address is considered when counting the number of received API calls.
+
+::: note
+If you are using an API endpoint **not** listed below and you receive rate limit headers as part of your response, see [Anomaly Detection](/anomaly-detection) for more information.
+:::
+
+## Limits for production tenants of paying customers
+
+| Endpoint | Path | Limited By | Rate Limit |
+| - | - | - | - |
+| All Endpoints | [All Authentication API endpoints](/api/authentication) | Sum of all combined requests to any Authentication API endpoint | 100 requests per second |
+| User Profile | `/tokeninfo` (Legacy) | IP Address | 800 requests per minute  |
+|  | `/userinfo` | User ID | 5 requests per minute with bursts up to 10 requests |
+| Delegation | `/delegation` | User ID, IP Address | 10 requests per second |
+| Change Password | `/dbconnections/change_password` | User Email, IP Address | 1 request per minute with bursts up to 10 requests |
+| Signup | `/dbconnections/signup` | IP Address | 50 requests per minute |
+| Get Passwordless Code or Link | `/passwordless/start` | IP Address | 50 requests per hour when using non-authenticated calls. It's considered an Authentication API endpoint otherwise. |
+
+## Limits for non-production tenants of paying customers and all tenants of free customers
+
+| Endpoint | Path | Limited By | Rate Limit |
+| - | - | - | - |
+| User Profile | `/tokeninfo` (Legacy) | IP Address | 800 requests per minute  |
+|  | `/userinfo` | User ID | 5 requests per minute with bursts up to 10 requests |
+| Delegation | `/delegation` | User ID, IP Address | 10 requests per second |
+| Change Password | `/dbconnections/change_password` | User Email, IP Address | 1 request per minute with bursts up to 10 requests |
+| Signup | `/dbconnections/signup` | IP Address | 50 requests per minute |
+| Get Passwordless Code or Link | `/passwordless/start` | IP Address | 50 requests per hour |
+| Get Token | `/oauth/token` | Any request | 30 requests per second |
+| Cross Origin Authentication | `/co/authenticate` | Any request | 5 requests per second |
+| Authentication | `usernamepassword/login` | Any request | 5 requests per second |
+| Resource Owner (Legacy) | `/oauth/ro` | Any request | 10 requests per second |
+| JSON Web Token Keys | `/.well-known/jwks.json` | Any request | 20 requests per second |
+
+## Free tenant global limits
+
+To ensure Auth0's quality of service, the Authentication API is subject to several levels of rate limiting for free subscribers. Auth0's Authentication API has a global limit of **300 requests per minute** for free tenants.  
+
+::: note
+The limit is global for the tenant and not per endpoint.
+:::
+
+### Affected endpoints
+
+The global rate limit applies to all [Authentication API](/api/authentication) endpoints. A complete list of endpoints that are affected by this limit, along with the associated response if the rate limit is exceeded, is a follows:
+
+Endpoint | Response
+---------|---------
+`GET /authorize` |  [Error Page](#error-page)
+`GET /passwordless/verify_redirect` |  [Error Page](#error-page)
+`POST /dbconnections/change_password` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /dbconnections/change_password` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /dbconnections/self_change_password` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /co/authenticate` |  [JSON Error](#json-error) (`access_denied`)
+`POST /delegation` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /delegation` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /activate` | [Error Page](#error-page)
+`POST /activate` | [Error Page](#error-page)
+`POST /oauth/device/code` |  [JSON Error](#json-error) (`access_denied`)
+`POST /oauth/ro` |  [JSON Error](#json-error) (`access_denied`)
+`GET /oauth/ro` |  [JSON Error](#json-error) (`access_denied`)
+`POST /oauth/token` |  [JSON Error](#json-error) (`access_denied`)
+`POST /oauth/introspect` |  [JSON Error](#json-error) (`access_denied`)
+`GET /passwordless/start` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /passwordless/start` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /u/reset-password/request/:connection` | [Error Page](#error-page)
+`GET /u/consent` | [Error Page](#error-page)
+`POST /u/consent` | [Error Page](#error-page)
+`GET /u/login` | [Error Page](#error-page)
+`POST /u/login` | [Error Page](#error-page)
+`GET /u/mfa-country-codes` | [Error Page](#error-page)
+`POST /u/mfa-country-codes` | [Error Page](#error-page)
+`GET /u/mfa-email-challenge` | [Error Page](#error-page)
+`POST /u/mfa-email-challenge` | [Error Page](#error-page)
+`GET /u/mfa-email-enrollment` | [Error Page](#error-page)
+`POST /u/mfa-email-enrollment` | [Error Page](#error-page)
+`GET /u/mfa-email-enrollment-verify` | [Error Page](#error-page)
+`POST /u/mfa-email-enrollment-verify` | [Error Page](#error-page)
+`GET /u/mfa-email-list` | [Error Page](#error-page)
+`POST /u/mfa-email-list` | [Error Page](#error-page)
+`GET /u/mfa-enroll-options` | [Error Page](#error-page)
+`POST /u/mfa-enroll-options` | [Error Page](#error-page)
+`GET /u/mfa-guardian-list` | [Error Page](#error-page)
+`POST /u/mfa-guardian-list` | [Error Page](#error-page)
+`GET /u/mfa-guardian-welcome` | [Error Page](#error-page)
+`POST /u/mfa-guardian-welcome` | [Error Page](#error-page)
+`GET /u/mfa-login-options` | [Error Page](#error-page)
+`POST /u/mfa-login-options` | [Error Page](#error-page)
+`GET /u/mfa-otp-challenge` | [Error Page](#error-page)
+`POST /u/mfa-otp-challenge` | [Error Page](#error-page)
+`GET /u/mfa-otp-enrollment` | [Error Page](#error-page)
+`POST /u/mfa-otp-enrollment` | [Error Page](#error-page)
+`GET /u/mfa-push-challenge` | [Error Page](#error-page)
+`POST /u/mfa-push-challenge` | [Error Page](#error-page)
+`GET /u/mfa-push-enrollment` | [Error Page](#error-page)
+`POST /u/mfa-push-enrollment` | [Error Page](#error-page)
+`GET /u/mfa-recovery-code-challenge` | [Error Page](#error-page)
+`POST /u/mfa-recovery-code-challenge` | [Error Page](#error-page)
+`GET /u/mfa-recovery-code-challenge-new-code` | [Error Page](#error-page)
+`POST /u/mfa-recovery-code-challenge-new-code` | [Error Page](#error-page)
+`GET /u/mfa-recovery-code-enrollment` | [Error Page](#error-page)
+`POST /u/mfa-recovery-code-enrollment` | [Error Page](#error-page)
+`GET /u/mfa-sms-challenge` | [Error Page](#error-page)
+`POST /u/mfa-sms-challenge` | [Error Page](#error-page)
+`GET /u/mfa-sms-enrollment` | [Error Page](#error-page)
+`POST /u/mfa-sms-enrollment` | [Error Page](#error-page)
+`GET /u/mfa-sms-enrollment-verify` | [Error Page](#error-page)
+`POST /u/mfa-sms-enrollment-verify` | [Error Page](#error-page)
+`GET /u/mfa-sms-list` | [Error Page](#error-page)
+`POST /u/mfa-sms-list` | [Error Page](#error-page)
+`GET /u/reset-password` | [Error Page](#error-page)
+`POST /u/reset-password` | [Error Page](#error-page)
+`GET /u/reset-password/request/:connection` | [Error Page](#error-page)
+`GET /u/signup` | [Error Page](#error-page)
+`POST /u/signup` | [Error Page](#error-page)
+`GET /tokeninfo` | Text: "Rate limit exceed"
+`POST /tokeninfo` | Text: "Rate limit exceed"
+`POST /userinfo` | Text: "Rate limit exceed"
+`GET /userinfo` | Text: "Rate limit exceed"
+`POST /usernamepassword/login` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /usernamepassword/login` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /.well-known/jwks.json` | Text: "Rate limit exceed"
+`GET /.well-known/openid-configuration` |  [JSON Error](#json-error) (`access_denied`)
+`GET /cer/:clientID?` | Text: "Rate limit exceed"
+`GET /pb7/:clientID?` | Text: "Rate limit exceed"
+`GET /pem/:clientID?` | Text: "Rate limit exceed"
+`GET /rawpem/:clientID?` | Text: "Rate limit exceed"
+`GET /samlp/:clientID` | Text: "Rate limit exceed"
+`POST /samlp/:clientID` | Text: "Rate limit exceed"
+`GET /samlp/metadata` | Text: "Rate limit exceed"
+`GET /samlp/metadata/:clientID` | Text: "Rate limit exceed"
+`GET /:clientID/trust/mex` | XML Error (`wst:RequestFailed`)
+`POST /:clientID/trust/usernamemixed` | XML Error (`wst:RequestFailed`, Status Code: 500)
+`GET /decision` | [Error Page](#error-page)
+`POST /decision` | [Error Page](#error-page)
+`POST /drwatson` | Text: "Rate limit exceed"
+`POST /mfa/associate` |  [JSON Error](#json-error) (`access_denied`)
+`GET /mfa/authenticators` |  [JSON Error](#json-error) (`access_denied`)
+`DELETE /mfa/authenticators/:authenticator_id` |  [JSON Error](#json-error) (`access_denied`)
+`POST /mfa/challenge` |  [JSON Error](#json-error) (`access_denied`)
+`GET /oauth/access_token` |  [JSON Error](#json-error) (`access_denied`)
+`POST /oauth/access_token` |  [JSON Error](#json-error) (`access_denied`)
+`GET /p/:strategy/:ticket` | Text: "Rate limit exceed"
+`POST /p/:strategy/:ticket` | Text: "Rate limit exceed"
+`GET /p/:strategy/:ticket/info` | Text: "Rate limit exceed"
+`GET /passwordless/verify` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /passwordless/verify` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /rms` | [Error Page](#error-page)
+`GET /rms/:clientID/adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`)
+`POST /rms/:clientID/adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`)
+`GET /rms/:clientID/FederationMetadata/2007-06/FederationMetadata.xml` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /samlp/:clientID/logout` | [Error Page](#error-page)
+`POST /samlp/:clientID/logout` | [Error Page](#error-page)
+`GET /samlp/idp/slo` | Text: "Rate limit exceed"
+`GET /sso_dbconnection_popup/:clientID` |  [JSON Error](#json-error) (`access_denied`)
+`GET /wsfed` | [Error Page](#error-page)
+`GET /wsfed/:clientID` | [Error Page](#error-page)
+`GET /wsfed/:clientID/FederationMetadata/2007-06/FederationMetadata.xml` | [Error Page](#error-page)
+`GET /wsfed/FederationMetadata/2007-06/FederationMetadata.xml` | [Error Page](#error-page)
+`GET /.well-known/apple-app-site-association` |  [JSON Error](#json-error) (`access_denied`)
+`GET /.well-known/assetlinks.json` |  [JSON Error](#json-error) (`access_denied`)
+`GET /adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`)
+`POST /adfs/fs/federationserverservice.asmx` | XML Error (`fed:BadRequest`)
+`GET /apple-app-site-association` |  [JSON Error](#json-error) (`access_denied`)
+`GET /aws-saml/metadata` | Text: "Rate limit exceed"
+`GET /changepwd/completed` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /changepwd/form` | [Error Page](#error-page)
+`POST /changepwd/reset` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /co/verify` | Text: "Rate limit exceed"
+`GET /continue` | [Error Page](#error-page)
+`POST /continue` | [Error Page](#error-page)
+`GET /custom-login/preview` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /dbconnections/delete` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /dbconnections/login` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /dbconnections/login` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /dbconnections/signup` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /dbconnections/signup` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /dbconnections/verify_email` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /FederationMetadata/2007-06/FederationMetadata.xml` | XML Error (`fed:BadRequest`)
+`GET /i/login` | [Error Page](#error-page)
+`GET /i/login/sso/:provider` | Text: "Rate limit exceed"
+`GET /i/oauth2/authorize` |  [JSON Error](#json-error) (`access_denied`)
+`GET /login` | [Error Page](#error-page)
+`GET /login/callback` | [Error Page](#error-page)
+`POST /login/callback` | [Error Page](#error-page)
+`GET /logout` | [Error Page](#error-page)
+`POST /logout` | [Error Page](#error-page)
+`GET /mf` | [Error Page](#error-page)
+`POST /mf` | [Error Page](#error-page)
+`POST /oauth/reverse` |  [JSON Error](#json-error) (`access_denied`)
+`POST /oauth/revoke` |  [JSON Error](#json-error) (`access_denied`)
+`POST /state/introspect` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /unblock` | [Error Page](#error-page)
+`POST /unlink` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /user/ssodata` | Text: "Rate limit exceed"
+`GET /users/:id/impersonate` | [JSON Error](#json-error) (`too_many_requests`)
+`POST /users/:id/impersonate` | [JSON Error](#json-error) (`too_many_requests`)
+`GET /v2/logout` | [Error Page](#error-page)
+
+## Exceeding the Rate Limit
+
+If you exceed the rate limit for a given API endpoint, you'll receive an [HTTP 429 (Too Many Requests)](http://tools.ietf.org/html/rfc6585#section-4) response (except for the cases documented in the [previous section](#affected-endpoints)). The response will also contain [HTTP Response Headers](/policies/rate-limits#http-response-headers) that provide additional information on the rate limits applicable to that endpoint.
+
+If you exceed the global rate limit, the following example log entry will be emitted to your logs: **You have reached the global limit for your account**. There will be a single log entry per hour while your account exceeds the rate limit.
+
+To view the log entries for a subscription, navigate the to [Logs](${manage_url}#/logs) page in the [Dashboard](${manage_url}).
+
+### Reducing the number of calls to Auth0
+
+When you exceed your rate limits, you'll need to reduce the number of calls you make to Auth0. The specifics depend on your use case, but here are some recommendations:
+
+ * Cache `/.well-known/*` responses: This information does not change frequently, so you can usually cache it to reduce the number of times you need to call Auth0.
+ 
+ * Consider requesting an `id_token` instead of calling `/userinfo` to get information about the user.
+
+### Response body
+
+The response body you receive depends on the endpoint. Each endpoint typically provides a return value in a different format (for example, some return an HTTP response, while others redirect to a URL and pass values in the query string). If the endpoint typically provides the response expected as JSON in the HTTP body, then a JSON error response will be sent if a rate limit is reached (exceptions are documented above).
+
+To view the particular response per endpoint, see [Affected endpoints](#affected-endpoints). Descriptions of each possible error are listed below.
+
+#### Error Page
+
+The Error Page response is sent for endpoints that render HTML content to the end user. When you exceed the rate limit, Auth0 renders the [Error Page](/universal-login/custom-error-pages) instead of the expected content.
+
+#### JSON Error
+
+Endpoints that usually provide JSON-formatted responses will return a JSON object containing an error code and description.
+
+```json
+{
+  "error": "access_denied or too_many_requests",
+  "error_description": "Global rate limit exceeded",
+  "error_uri": "https://.../... documentation url"
+}
+```
+
+The error you receive depends on the type of endpoint you're calling:
+
+* `access_denied`: for OAuth endpoints 
+* `too_many_requests`: for endpoints that return JSON
+
+#### XML Error
+
+XML Errors are returned for endpoints that normally return XML.
+
+```xml
+
+ 
+  
+   
+     env:Sender
+     
+      fed:BadRequest or wst:RequestFailed
+     
+   
+   
+     Global rate limit exceeded
+   
+   
+   
+  
+ 
+
+```
+
+The error you receive depends on the type of endpoint you're calling:
+
+- `fed:BadRequest` will be sent for WSFed-related endpoints.
+- `wst:RequestFailed` will be used in for WSTrust-related endpoints.
diff --git a/ja-jp/articles/policies/rate-limits-mgmt-api.md b/ja-jp/articles/policies/rate-limits-mgmt-api.md
new file mode 100644
index 0000000000..6c8340b61b
--- /dev/null
+++ b/ja-jp/articles/policies/rate-limits-mgmt-api.md
@@ -0,0 +1,100 @@
+---
+title: Management API Endpoint Rate Limits
+description: Describes Auth0's rate limit policy when working with Auth0 Management API endpoints.
+toc: true
+topics:
+    - auth0-policies
+    - rate-limits
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Management API Endpoint Rate Limits
+
+**This policy is effective May 19, 2020.**
+
+::: warning
+If you subscribed before **May 19, 2020**, the [previous rate limit policy](/policies/legacy-rate-limits) applies to you until **June 18, 2020**. Starting on **June 18, 2020**, these limits will apply to all tenants. You will be notified of the new limits through a **Dashboard Notification**. If the new limits impact your tenant, you will be notified directly via email with additional information about minimizing API calls and upgrading plans.
+:::
+
+The rate limits for this API differ depending on whether your tenant is free or paid, production or not.
+
+| Tenant Type | Rate Limit (per second) | Rate Limit (per minute) |
+| - | - | - |
+| Free or Trial | 10 | 120 |
+| Developer or Developer Pro (created before May 19, 2020) | 50 | 1000 |
+| Enterprise (Production) | 50 | 1000 |
+| Enterprise (Non-production) | 10 | 120 |
+
+The rate limits include calls made via [Rules](/rules) and are set **by tenant** and not by endpoint.
+
+Each endpoint is configured with a bucket that defines:
+
+-  Request limit
+-  Rate limit window (per second, per minute, per day, etc.)
+
+```text
+bucket:
+    size: x
+    per_minute: y
+```
+
+For example, the above states that, for the given bucket, there is a maximum request limit of `x` per minute, and for each minute that elapses, permissions for `y` requests are added back. In other words, for each `60 / y` seconds, one additional request is added to the bucket. This occurs automatically until the bucket contains the maximum permitted number of requests.
+
+For some API endpoints, the rate limits are defined per bucket, so the origins of the call do not influence the rate limit changes. For other buckets, the rate limits are defined using different keys, so the originating IP address is considered when counting the number of received API calls.
+
+::: note
+If you are using an API endpoint **not** listed below and you receive rate limit headers as part of your response, see [Anomaly Detection](/anomaly-detection) for more information.
+:::
+
+The following Auth0 Management API endpoints return rate limit-related headers. For additional information about these endpoints, please consult the [Management API explorer](/api/management/v2).
+
+## Developer and Developer Pro subscription limits
+
+| Endpoint Group | Path | Rate Limit (per second) | Rate Limit (per minute) |
+| - | - | - | - |
+| Read users | `GET /api/v2/users` | 40 | 500 |
+| | `GET /api/v2/users-by-email` | | |
+| | `GET /api/v2/users/{id}` | | |
+| Write users | `POST /api/v2/users` | 20 | 200 |
+| | `POST /api/v2/users/{id}/identities` | | |
+| | `PATCH /api/v2/users/{id}` | | |
+| | `DELETE /api/v2/connections/{id}/users` | | |
+| | `DELETE /api/v2/users/{id}/identities/{provider}/{user_id}` | | |
+| | `DELETE /api/v2/users/{id}` | | |
+| Read logs | `GET /api/v2/logs` | 10 | 100 |
+| | `GET /api/v2/logs/{id}` | | |
+| | `GET /api/v2/users/{id}/logs` | | |
+| Read clients | `GET /api/v2/clients` | 5 | 100 |
+| | `GET /api/v2/clients/{id}` | | |
+| Read connections | `GET /api/v2/connections` | 10 | 100 |
+| | `GET /api/v2/connections/{id}` | | |
+| Write device credentials | `POST /api/v2/device-credentials` | 5 | 100 | 
+| | `DELETE /api/v2/device-credentials/{id}` | | |
+| All other endpoints combined | | 10 | 150 |
+
+## Endpoint limits for all subscriptions
+
+| Endpoint | Path | Rate Limit (per second) | Rate Limit (per minute) | Rate Limit (per day) |
+| - | - | - | - | - |
+| Verify custom domain | `POST /api/v2/custom-domains{id}/verify` | n/a | 5 | n/a |
+| Register dynamic client | `POST /oidc/register` | 5 | n/a | n/a |
+| Read connection status | `GET /api/v2/connections/{id}/status` | 15 | n/a | n/a |
+| Rotate signing keys | `POST /api/v2/keys/signing/rotate` | n/a | n/a | 5 |
+
+## Concurrent import users job limits
+
+The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of 2 concurrent import jobs. If you request additional jobs while there are 2 pending returns, the following response occurs:
+
+```json
+{
+  "statusCode": 429,
+  "error": "Too Many Requests",
+  "message": "There are 2 active import users jobs, please wait until some of them are finished and try again
+}
+```
+
+## Access token limits for SPAs
+
+If you obtain Access Tokens for your SPAs, there are rate limits that are applicable when working with the available `current_user`-related [scopes and endpoints](/api/management/v2/get-access-tokens-for-spas#available-scopes-and-endpoints). You are allowed a maximum of **10 requests per minute per user**.
diff --git a/ja-jp/articles/policies/rate-limits.md b/ja-jp/articles/policies/rate-limits.md
new file mode 100644
index 0000000000..3c86e92079
--- /dev/null
+++ b/ja-jp/articles/policies/rate-limits.md
@@ -0,0 +1,79 @@
+---
+title: Rate Limit Policy
+description: Describes Auth0's rate limit policy.
+toc: true 
+topics:
+    - auth0-policies
+    - rate-limits
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Rate Limit Policy
+
+Actions such as rapidly updating configuration settings, aggressive polling, or making highly concurrent API calls may result in your app being rate limited.
+
+Auth0's rate limits vary based on the tenant type you have. The tenants that have no credit card associated in the [Dashboard](${manage_url}/#/tenant/billing/payment) are free. There are also variations in terms of paid tenant types (e.g., non-production, production). To set an environment for your tenant (development, staging or production), go to [Support Center > Tenants](${env.DOMAIN_URL_SUPPORT}/tenants/public), find your tenant, select __Assign Environment Tag__, set the environment and save changes.
+
+## API endpoint limits
+
+To ensure the quality of Auth0's services, the Auth0 APIs are subject to rate limiting. Depending on the API endpoint, the request limit and the rate limit window in which the request limit resets, varies. 
+
+Using the Management API for free and trial tenants is restricted to **2 requests per second** (with bursts of up to **10 requests**). Exceeding these values triggers an HTTP 429 error, but the error message states, "Global limit has been reached." These are in addition to those indicated in the rate limit response headers.
+
+If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed.
+
+See the rate limits for [Management API Endpoints](/policies/rate-limits-mgmt-api) and [Authentication API Endpoints](/policies/rate-limits-auth-api) for complete details on each endpoint limitation. 
+
+### Review HTTP response headers
+
+Auth0 reserves the right to modify the rate limits at any time. For the up-to-date information on rate limits, you can review the HTTP response headers returned from rate limited endpoints.
+
+API requests to selected [Authentication](/api/authentication) or [Management API](/api/management/v2) endpoints will return HTTP response headers that provide relevant data on the current status of your rate limits for that endpoint. If you receive a rate limit-related response header, it will include numeric information detailing your status.
+
+* **X-RateLimit-Limit**: The maximum number of requests available in the current time frame.
+* **X-RateLimit-Remaining**: The number of remaining requests in the current time frame.
+* **X-RateLimit-Reset**: A [UNIX timestamp](https://en.wikipedia.org/wiki/Unix_time) of the expected time when the rate limit will reset.
+
+### Handle rates limitations in code
+
+You should add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 429 (Too Many Requests). In this case, if a retry is needed, it is best to allow for a back-off to avoid going into an infinite retry loop.
+
+For scripts and rules that call Auth0 APIs, you should always handle rate limiting by checking the `X-RateLimit-Remaining` header and acting appropriately when the number returned nears 0. 
+
+## Database login limits
+
+For database connections, Auth0 limits certain types of repeat login attempts depending on the user account and IP address. For more information, see [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits).
+
+## SMS/Voice message limits for multi-factor authentication
+
+There's a limit of 10 SMS or Voice messages/hour per user for MFA. For more information, see [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone).
+
+## Native social login limits
+
+Limits are only applied to requests related to the Native Social Login flows, which are identified based on the body of the requests with the following initial criteria:
+
+| Request Type | Body |
+| - | - |
+| `grant_type` | `urn:ietf:params:oauth:grant-type:token-exchange` |
+| `subject_token_type` | `http://auth0.com/oauth/token-type/apple-authz-code` |
+
+### Limits for production tenants of paying customers
+
+| Endpoint | Path | Limited By | Rate Limit |
+| - | - | - | - |
+| Get Token | `/oauth/token` | Any native social login request | 50 per minute with bursts up to 500 requests |
+
+### Limits for non-production tenants of paying customers and all tenants of free customers
+
+| Endpoint | Path | Limited By | Rate Limit |
+| - | - | - | - |
+| Get Token | `/oauth/token` | Native social login requests and IP | 30 per minute |
+
+## Keep reading
+
+* [Management API Endpoint Rate Limits](/policies/rate-limits-mgmt-api)
+* [Authentication API Endpoint Rate Limits](/policies/rate-limits-auth-api)
+* [Legacy Rate Limits](/policies/legacy-rate-limits)
+* [Entity Limit Policy](/policies/entity-limits)
diff --git a/ja-jp/articles/policies/restore-deleted-tenant.md b/ja-jp/articles/policies/restore-deleted-tenant.md
new file mode 100644
index 0000000000..a9e135d7c6
--- /dev/null
+++ b/ja-jp/articles/policies/restore-deleted-tenant.md
@@ -0,0 +1,23 @@
+---
+description: This page details Auth0's deleted tenant restoration policy.
+topics:
+    - auth0-policies
+    - tenants
+    - tenant-restoration
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Tenant Restoration Policy
+
+::: warning
+**Deleted tenants cannot be restored** and the **tenant name may not be used again** when creating new tenants.
+:::
+
+**Before you delete your tenant, please check out the following resources for alternative options:**
+* [Updating a Tenant Admin](https://auth0.com/docs/dashboard/manage-dashboard-admins#update-admin) **for changing ownership of the tenant**
+* [Delete or Reset Tenants](/tutorials/delete-reset-tenant) for reseting tenant configuration.
+
+If you've deleted your tenant, and you require the use of a particular domain name, we recommend configuring a [custom domain name](/custom-domains) for your new tenant.
diff --git a/ja-jp/articles/policies/unsupported-requests.md b/ja-jp/articles/policies/unsupported-requests.md
new file mode 100644
index 0000000000..793fd7ff2f
--- /dev/null
+++ b/ja-jp/articles/policies/unsupported-requests.md
@@ -0,0 +1,41 @@
+---
+description: The following is a list of requests Auth0 currently doesn't support.
+topics:
+    - auth0-policies
+    - support
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Unsupported Requests
+
+Our support team strives to assist you to the best of our ability. However, we are currently unable to grant the following requests:
+
+* Transferring data from a non-production to a production account
+
+* Renaming a tenant
+
+* Renaming a connection
+
+* Re-using the name of a previously deleted tenant
+
+* Migrating a tenant from one region to another (for example, from US to EU)
+
+* Ad hoc usage data reports.
+
+* Restore any deleted or modified data or settings in tenants, including:
+
+  * Database connections and their users and passwords
+  * Users, their profile information, metadata, roles membership
+  * Roles and permissions
+  * Applications
+  * SSO Integrations
+  * APIs
+  * Connections
+  * Rules
+  * Hooks
+  * Extensions
+  * Email templates
+  * Tenant logs once the [standard retention time](/logs/references/log-data-retention) passed
diff --git a/ja-jp/articles/pre-deployment/how-to-run-test.md b/ja-jp/articles/pre-deployment/how-to-run-test.md
new file mode 100644
index 0000000000..f06bf5038a
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/how-to-run-test.md
@@ -0,0 +1,69 @@
+---
+description: How to run the Auth0 Production Check to ensure that your Applications are production-ready
+topics:
+    - pre-deployment
+    - pre-deployments-tests
+    - tests
+    - production-checks
+contentType:
+  - reference
+  - how-to
+useCase:
+  - support
+---
+
+# How to Run the Production Checks
+
+The Production Checks can be reviewed in the [Auth0 Support Center Tenants section](${env.DOMAIN_URL_SUPPORT}/tenants/public).
+
+![](/media/articles/support/pre-deployment-tests/support-home.png)
+
+Once you've logged in to your account, click **Tenants** in the navigation bar.
+
+![](/media/articles/support/pre-deployment-tests/tenants.png)
+
+You'll see a listing of all tenants associated with your Auth0 account. Each tenant displays in its own box. Identify the tenant for which you want to run the Production Checks, and click on the **gear icon** located in the top right-hand corner of its box.
+
+![](/media/articles/support/pre-deployment-tests/tenants-tests.png)
+
+Click **Run Production Check** to launch the testing interface.
+
+At this point, you'll be able to select one or more [Applications](/applications) associated with this tenant for which you want checks run.
+
+![](/media/articles/support/pre-deployment-tests/choose-applications.png)
+
+Once you've selected your applications, click **Run Check**.
+
+When the test is complete, your screen will automatically refresh to display your check results. 
+
+![](/media/articles/support/pre-deployment-tests/results.png)
+
+
+## Production Check Results
+
+There are three types of check results: Required, Recommended, and Best Practices.
+
+| Result Type | Description |
+| ----------- | ----------- |
+| Required | These checks see if you are missing any steps you **must** complete before deploying to Production; otherwise you'll see errors. |
+| Recommended | These checks see if you are missing any steps **recommended** by Auth0. While you do not have to complete the steps suggested, we recommend that you at least review the results to see if any of them are helpful to your implementation.
+| Best Practices | These areas are ones where Auth0 cannot use automated checks. We list areas of possible concern, and we suggest that you review your implementation to see if you're compliant with Auth0 recommendations. |
+
+## How to Read Your Results Set
+
+The following are possible results for your check: Passed, Failed, Unable to Verify.
+
+Under each set of check results, Auth0 tells you how many checks your Application passed, as well as how many checks your Application failed.
+
+![](/media/articles/support/pre-deployment-tests/reading-results.png)
+
+If your Application **failed** one or more checks, Auth0 provides:
+
+* The name of the check
+* Information on what the check is looking for
+* Details on the error thrown to and retrieved by the check
+* Hyperlink to the appropriate area where you can make the required fixes so that your Application passes the check
+
+![](/media/articles/support/pre-deployment-tests/detailed-results.png)
+
+All of the checks that your Application **passed** are grouped together at the bottom of the results set. You can view the name of and information about the check, as well as review the associated documentation and use the hyperlink to go to the corresponding configuration area where you can make changes (if desired).
diff --git a/ja-jp/articles/pre-deployment/index.html b/ja-jp/articles/pre-deployment/index.html
new file mode 100644
index 0000000000..d3f15af976
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/index.html
@@ -0,0 +1,59 @@
+---
+classes: topic-page
+title: Production Checks
+topics:
+    - pre-deployment
+    - pre-deployments-tests
+    - tests
+    - production-checks
+contentType:
+  - index
+useCase:
+  - support
+---
+
+
    
+  
    
+  
    Production Checks
    
+  
    
+    Before you go live, run Auth0's production checks suite to ensure that your tenants are ready for use in a production environment.
+  
    
+
    
+
+
diff --git a/ja-jp/articles/pre-deployment/prelaunch-tips.md b/ja-jp/articles/pre-deployment/prelaunch-tips.md
new file mode 100644
index 0000000000..c82eac9222
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/prelaunch-tips.md
@@ -0,0 +1,65 @@
+---
+title: Pre-Launch Tips 
+description: A list of helpful tips for when getting started with Auth0 services based on feedback and experience from others.
+topics:
+    - pre-deployment
+    - pre-launch
+    - tips-and-tricks
+    - production-checks
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Pre-Launch Tips 
+
+Here is a list of tips our customers have found most useful when first getting started with Auth0 services:
+
+* Check the URLs in your allowed callbacks, CORS and allowed redirect URLs for Logout to make sure they are correct, complete, and do not involve use of `file:///` or `localhost`.  Minimize the use of wildcards and consider carefully the security ramifications of wildcards.
+
+* Separate production use from ongoing development work by [using separate tenants for prod, test and dev.](/dev-lifecycle/setting-up-env)
+
+* Configure your network correctly to allow traffic to and from our sets of public APIs (prod envs might have a different setup than dev/staging).
+
+* Check the expiration date of certificates you have added to your configuration to make sure certificates uploaded during development cycles won’t expire during or shortly after launch.
+
+* Make sure any remote IDPs are running NTP so that the time will be properly synced.
+
+* The number of days of log data available varies by plan up to a max of 30 days. If you need log data for a longer retention period, you should set up one of the [Auth0 extensions](/extensions#export-auth0-logs-to-an-external-service) that will send log data to a third party service. This will enable you to keep log data for longer periods.  Be sure to set this up before you go live so you are sure to have log data when you need it.
+
+* Make sure your usage of our APIs remains within [allowed limits](/policies/rate-limits) and you have written your code to dynamically adjust to rate limit information returned in the header and to handle errors. If you anticipate rate limits being a problem for your application, discuss with us up-front to check if it would be possible to momentarily raise them until the traffic returns to normal. You should consider using a cache of user data in order to not have to query an API endpoint more than necessary.
+
+* If using [social connections](/identityproviders) make sure to obtain your own credentials from the provider and add them to the configuration of the social connection.
+
+* If using [custom DB connections](/connections/database/mysql) make sure all custom DB scripts are implemented and return a consistent user-profile with a unique user ID.
+
+* For sending emails first make sure to [setup a custom email provider.](/email/providers)
+
+* If you use our CDN for the Lock widget, make sure to [pin to a specific version.](/libraries/lock/v10#installation-sources)
+
+* Make sure **external** components called from rules, hooks and custom DB connection scripts can handle the expected load.
+
+* Adequately protect any client secret values.
+
+* Check your [grant types](/applications/concepts/application-grant-types) for your applications. Make sure you have the right ones enabled and more importantly, disable any grant types that aren't needed.
+
+* If you make use of [user_metadata](/users/concepts/overview-user-metadata) confirm that this is data that users should be able to change on their own (eg. not “payment status”).
+
+* Review your [Anomaly Detection settings](${manage_url}/#/anomaly) and read the [Anomaly Detection doc](/anomaly-detection) to understand how to unblock users that have been blocked.
+
+* Review your [Tenant Settings Admin section](${manage_url}/#/tenant/admins) to make sure that only appropriate admins have access to the Auth0 dashboard.
+
+* Make sure you have tested all core use cases for your application on all devices that might be used by the end-user population for your application.  Be sure to test both login, single-sign-on (if supported) and log as well as what happens if a user runs your application in multiple browser tabs.
+
+* Review your [list of rules](${manage_url}/#/rules) and make sure only the appropriate rules are turned on. 
+
+* Review your rule code, any custom DB scripts and any custom code in the login page to ensure that every call has adequate error trapping and handling.  Also review to make sure that return/callback statements are called correctly.
+
+* Configure your application name, support URL and support email in the [Tenant Settings General](${manage_url}/#/tenant) section so when an error occurs your end users will be directed to an appropriate page.
+
+* Make sure that your application is [dynamically obtaining a management API token](/api/management/v2/tokens) and make sure to read the [Management API Access Token FAQs](/api/management/v2/faq-management-api-access-tokens).
+
+* Remove any `console.log` statements from your rules or custom DB scripts. Especially those that might leak user identifiable information such as email, username or password.
+
+* Do not use plain text secrets in rules or db-connections. They should be added in the configuration part of the interface. The configuration is encrypted and provided just in time. Do not log the configuration object. 
diff --git a/ja-jp/articles/pre-deployment/tests/best-practice.md b/ja-jp/articles/pre-deployment/tests/best-practice.md
new file mode 100644
index 0000000000..ff5bd52ff9
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/tests/best-practice.md
@@ -0,0 +1,27 @@
+---
+description: Checks to ensure that your Applications comply with Auth0 best practices
+topics:
+    - pre-deployment
+    - pre-deployments-tests
+    - tests
+    - best-practices
+    - production-checks
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Production Checks: Best Practices
+
+The following checks cannot be automated, so we recommend manually checking these areas prior to deployment to Production.
+
+| Check | Description |
+| ---- | ----------- |
+| [Anomaly Detection](/anomaly-detection) | Review your account's [Anomaly Detection capability and configuration](${manage_url}/#/anomaly). |
+| Externalize [Configuration Parameters](/connections/database/mysql#4-add-configuration-parameters) | [Externalize, instead of hard code, all configuration parameters](${manage_url}/#/connections/database), such as credentials, connection strings, API keys, and so on, when developing Rules, Hooks, or custom database connections. |
+| [Restrict Delegation](/dashboard/reference/settings-application#advanced-settings) | If not using Delegation, set the Allowed Apps and APIs field of your Application Settings to the current Client ID. |
+| Single Sign-on (SSO) Timeout Values | Review the default [SSO cookie timeout values](${manage_url}/#/account/advanced) and ensure they align with your requirements. |
+| Tenants and Administrators | Review all tenants and tenant administrators to ensure they are correct. Decommission tenants that are no longer in use. Ensure that tenant administrators are limited to the necessary users. |
+| Verify Client IDs in App Code | Ensure that the Client IDs in your application code align with their Auth0 Application configurations. |
+| Whitelist Auth0 Public IPs | Whitelist Auth0 IPs if you're connecting to internal services or services behind a firewall when using Rules, Hooks, or custom databases. You can get a list of IP addresses in the tool tip when configuring any of these items. |
diff --git a/ja-jp/articles/pre-deployment/tests/recommended.md b/ja-jp/articles/pre-deployment/tests/recommended.md
new file mode 100644
index 0000000000..77969efda4
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/tests/recommended.md
@@ -0,0 +1,33 @@
+---
+description: Recommendations on how you can improve your Auth0 Application prior to production deployment
+topics:
+    - pre-deployment
+    - pre-deployments-tests
+    - tests
+    - recommendations
+    - production-checks
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Production Checks: Recommended Fixes
+
+The following checks see if you've completed all recommendations (which are optional) for successful deployment to Production.
+
+::: note
+See [How to Read Your Results Set](/pre-deployment/how-to-run-test#how-to-read-your-results-set) for additional information on your checks output.
+:::
+
+| Check | Description |
+| ---- | ----------- |
+| [Authorization Extension](/extensions/authorization-extension/v2) | Evaluate the [Authorization Extension if you have authorization requirements](${manage_url}/#/extensions). |
+| [Custom Domain](/custom-domains) is configured | Use [custom domains with Universal Login](${manage_url}/#/tenant/custom_domains) for the most seamless and secure experience for your end users. |
+| [Custom Error Page](/universal-login/custom-error-pages) is configured | [Configure a Custom Error Page](${manage_url}/#/account) with your application-specific details and corporate branding. |
+| [Email Templates](/email/custom) are configured | [Configure custom email templates](${manage_url}/#/emails) with your application specific details and corporate branding. |
+| [Guardian Multi-factor](/mfa) or other Multi-factor Authentication Providers | Consider [multi-factor authentication](${manage_url}/#/guardian) as part of the authentication strategy. |
+| [MFA for Tenant Administrators](/tutorials/manage-dashboard-admins) is enabled | [Enable multi-factor authentication](${manage_url}/#/account/admins) for tenant administrators. |
+| [Universal Login Password Reset Page](/universal-login/password-reset) is customized | [Configure a Custom Universal Login Page for Password Reset](${manage_url}/#/password_reset) with your application details and corporate branding. |
+| [Redirect Logout URL](/logout#set-the-allowed-logout-urls-at-the-account-level) | Review the [Allowed Redirect Logout URLs](${manage_url}/#/account/advanced) for your Application. |
+| Use RS256 Instead of HS256 | Set the JSONWebToken [Signature Algorithm](/apis#signing-algorithms) to RS256 instead of HS256. |
diff --git a/ja-jp/articles/pre-deployment/tests/required.md b/ja-jp/articles/pre-deployment/tests/required.md
new file mode 100644
index 0000000000..848f2ea432
--- /dev/null
+++ b/ja-jp/articles/pre-deployment/tests/required.md
@@ -0,0 +1,36 @@
+---
+description: Fixes you must make to your Auth0 Application prior to production deployment
+topics:
+    - pre-deployment
+    - pre-deployments-tests
+    - tests
+    - requirements
+    - production-checks
+contentType:
+  - reference
+useCase:
+  - support
+---
+
+# Production Checks: Required Fixes
+
+The following checks see if you've completed all requirements for successful deployment to Production.
+
+::: note
+See [How to Read Your Results Set](/pre-deployment/how-to-run-test#how-to-read-your-results-set) for additional information on your checks output.
+:::
+
+| Check | Description |
+| ---- | ----------- |
+| [Allow ID Tokens for Management API v2 Authentication](/migrations/guides/calling-api-with-idtokens) is disabled | The capabilities for using ID Tokens to authorize some of the Users and Device Credentials endpoints of the Management API are being deprecated. After completing migration to Access Tokens, make sure the [`Allow ID Tokens for Management API v2 Authentication` toggle is turned off](${manage_url}/#/tenant/advanced). If you can't see this setting, then your tenant was created after this feature was deprecated, so it is already disabled by default. |
+| [Allowed Callback URLs](/protocols/oauth2/redirect-users) are not Localhost | Validates the [Application Allowed Callback URLs do not point to localhost](${manage_url}/#/applications), 127.0.0.1, and so on. |
+| [Allowed Origins (CORS)](/cross-origin-authentication) is not Localhost | Validates that the [Location URL for the page does not point to localhost](${manage_url}/#/applications). |
+| [Allowed Web Origins are not Localhost](/dashboard/reference/settings-application) | Validates that the [Allowed Web Origins URLs do not point to localhost](${manage_url}/#/applications). |
+| [Email Provider](/email/providers) is configured | Verifies that the [custom email provider has been configured](${manage_url}/#/emails/provider). |
+| [SMS or Voice Provider](/mfa/guides/configure-phone) is configured (Dependency: MFA is configured) | Ensures that [Twilio SMS is configured](${manage_url}/#/mfa) if you're using MFA with SMS or Voice. |
+| Legacy Lock Migration is disabled | The `/usernamepassword/login` and `/ssodata` endpoints will be removed from service on July 16th, 2018. These are used by Lock.js v8, v9, v10, and auth0.js v6, v7 and v8. After completing the migration to the latest versions, make sure the [`Legacy Lock Migration` toggle is turned off](${manage_url}/#/account/advanced). |
+| [Legacy User Profile](/guides/migration-legacy-flows#user-profiles) is disabled | The legacy authentication flows that allow ID Tokens and the `/userinfo` endpoint to include the complete user profile are being deprecated. After completing the migration to the new OIDC-conformant APIs, make sure the [`Legacy User Profile` toggle is turned off](${manage_url}/#/account/advanced). |
+| [Social Connections](/connections/social/devkeys) are not using Auth0 Developer Keys | Verifies that [Social Connections are not using the default Auth0 developer keys](${manage_url}/#/connections/social). |
+| Support Email is configured | Ensures the [Support Email is configured](${manage_url}/#/account) in Tenant Settings. |
+| Support URL is configured | Ensures the [Support URL is configured](${manage_url}/#/account) in Tenant Settings. |
+| Tenant Environment Tag is configured | Ensures the [tenant environment tag is set](${env.DOMAIN_URL_SUPPORT}/tenants/public) appropriately to Production, Staging, or Development. |
diff --git a/ja-jp/articles/private-cloud/add-ons.md b/ja-jp/articles/private-cloud/add-ons.md
new file mode 100644
index 0000000000..5e5ec04cab
--- /dev/null
+++ b/ja-jp/articles/private-cloud/add-ons.md
@@ -0,0 +1,90 @@
+---
+section: private-cloud
+description: Overview of the add-on options available to Private Cloud customers
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+sitemap: false
+---
+# Private Cloud Add-On Options
+
+The follow add-on options are available to Private Cloud customers:
+
+
+    
+        
+            
+            
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+            
+        
+        
+            
+            
+            
+            
+            
+        
+    
+
    Customer-Hosted MPCAuth0-Hosted MPCPrivate CloudPublic Cloud
    Enhanced Uptime Guarantee (SLA)
    Yes
    Yes
    Yes
    No
    High Capacity
+            
    Yes
    Yes
    Yes
    No
    PCI Certified
+            
    No
    Yes
    Yes
    No
    GEO-HA
    Yes
    Yes
    No
    No
    Additional Pre-Production Environment
    Yes
    Yes
    No
    No
    
+
+## Enhanced Uptime Guarantee (SLA)
+
+The Enhanced Uptime Guarantee (SLA) increases the Private Cloud standard SLA of 99.95% to 99.99%.
+
+While Auth0's Public Cloud offers a 99.9% uptime guarantee, the Private Cloud's single tenant instances with dedicated resources can offer a higher SLA of 99.95%. For an additional cost, you can request the highest SLA of 99.99% uptime.
+
+## High Capacity
+
+The High Capacity add-on increases the maximum requests per second (RPS) the Private Cloud can handle from 500 RPS to 1500 RPS.
+
+Auth0 guarantees that the Private Cloud can handle up to 500 requests per second (RPS), but if you are looking for greater scalability for the most demanding applications, the High Capacity add-on increases this number to 1500 RPS. This is recommended for large-scale production operations supporting over 1 million users or to support your business requirements.
+
+## PCI Certified
+
+Auth0's dedicated deployments are ISO27001, SOC 2 Type II, ISO27018 and HIPAA BAA compliant, but the PCI Certified add-on ensures that your deployment is compliant with PCI-DSS requirements as well.
+
+## GEO-HA
+
+With the Geographic High Availability (GEO-HA) add-on, you will have the highest form of dedicated deployment availability offered by Auth0.
+
+The standard dedicated deployment is a single-region, high availability solution, but the GEO-HA add-on extends the cluster with a geographically-distributed region where the maximum round-trip latency does not exceed 100 milliseconds. This is referred to as a high-availability GEO cluster, which is a warm standby configuration with failure handling for rapid recovery during a regional outage.
+
+## Additional Pre-Production Environment
+
+The Managed Private Cloud includes a fully-isolated and independently-updated instance for development and testing. You can add additional Pre-Production Environments to meet your business requirements. 
+
+::: note
+Guaranteed Requests per Second and SLA do not apply to Pre-Production Environments.
+:::
diff --git a/ja-jp/articles/private-cloud/custom-domain-migration.md b/ja-jp/articles/private-cloud/custom-domain-migration.md
new file mode 100644
index 0000000000..7922c55bae
--- /dev/null
+++ b/ja-jp/articles/private-cloud/custom-domain-migration.md
@@ -0,0 +1,79 @@
+# Custom Domain Migration
+
+Beginning with Private Cloud release 1906, dedicated deployments will include the ability to fully utilize the [Auth0 Custom Domains](/custom-domains) feature.
+
+Existing Private Cloud customers using Custom Domains must complete a migration of their Private Cloud Custom Domains to the Auth0 Custom Domains features. New customers/deployments will automatically use the Auth0 Custom Domains features.
+
+::: note
+The Auth0 Custom Domains feature will be available in release 1905 for those who wish to opt-in early.
+:::
+
+## Background
+
+Auth0 added support for custom domains in the Private Cloud platform in January 2016. This implementation allowed Private Cloud administrators to create one or more custom domains per tenant and invoke the Authentication API endpoints using those domains.
+
+In March 2018, Auth0 added support for custom domains for those deploying on the Public Cloud. However, the feature included additional capabilities not included on the Private Cloud implementation. The following table summarizes the differences.
+
+| Feature | New Custom Domains | Legacy Custom Domains |
+| - | - | - |
+| Use of custom domain in emails | Yes | No |
+| Custom domain protection via API keys | Yes | No |
+| Custom domain registration | Yes | Yes |
+| Token issuer used as custom domain | Yes | No |
+| Auth0-managed certificates | Yes | No |
+| Use of multiple domains | No | Yes |
+
+## Requirements
+
+* A new DNS domain dedicated to the Custom Domain's origin server hostname. This could be a subdomain of your existing Auth0 Domain (i.e., if your domain name is `*.auth.mydomain.com`, the new subdomain would be `*.cd.auth.mydomain.com`).
+* A wildcard public SSL certificate for the new DNS domain.
+* A layer 4 network load balancer. This could be the existing one used by your Private Cloud deployment. Please note that if you are using a layer 7 load balancer, you **must** add a layer 4 load balancer.
+* A DNS record pointing to the layer 4 load balancer.
+
+## Migration
+
+Current Private Cloud customers using the existing Private Cloud Custom Domains functionality **must migrate to the Auth0 Custom Domains** feature to fully benefit from the features available.
+
+## Migration process
+
+The Custom Domains migration process involves three phases, each of which requires several steps.
+
+### Communication Phase
+
+Before beginning the migration process, Auth0 will reach out to you to explain the migration process and discuss the following:
+
+* The certificate management model you would like to use
+
+  Auth0 offers [two certificate management models](/custom-domains/#certificate-management). To simplify the migration process, we suggest using one model for all of your tenants (though you can use a different certificate model for each tenant if necessary).
+
+* The type of load balancer you're using (i.e. network (layer 4) or application (layer 7))
+
+  If your dedicated deployment is AWS-hosted, we will need to confirm the type of load balanced you're using. If you are using an application load balancer, you will need to provision an additional network load balancer.
+
+* Allocating new DNS resources to meet stated requirements (if necessary)
+
+  You will need to have ready the **edge domain name** and accompanying **SSL certificate**, the **CNAME host name**, and the **email address** to be used as the Let's Encrypt contact.
+
+### Infrastructure preparation phase
+
+::: note
+If your Private Cloud deployment resides in an Auth0-hosted environment, Auth0 will prepare your environment for migration on your behalf.
+:::
+
+During this stage, you will need to:
+
+1. Set up the network load balancer
+2. Set up your new DNS records
+3. Validate and verify that your set up is correct
+
+### Migration phase
+
+The goal of the migration phase is to create custom domains that have all the new functionality and to update all dependencies to function correctly with your newly-created domain names.
+
+The first step is to create new domains using the Auth0 [Custom Domains](/custom-domains) feature.
+
+Once done, you may have [additional configuration steps](/custom-domains/additional-configuration#configure-social-identity-providers), depending on the Auth0 features you use.
+
+#### Final configuration
+
+One you have completed all of the required modifications on your applications, a Managed Services Engineer will assist you in completing the migration process.
diff --git a/ja-jp/articles/private-cloud/index.md b/ja-jp/articles/private-cloud/index.md
new file mode 100644
index 0000000000..044901fc2b
--- /dev/null
+++ b/ja-jp/articles/private-cloud/index.md
@@ -0,0 +1,94 @@
+---
+section: private-cloud
+description: Overview of the Private Cloud deployment options
+classes: topic-page
+topics:
+    - private-cloud
+    - managed-private-cloud
+contentType: concept
+useCase: private-cloud
+title: Private Cloud Deployment
+---
+
    
+  
    
+  
    Private Cloud Deployment
    
+  
    
+    A low-friction, dedicated Auth0 deployment that exists in Auth0's Private Cloud or a Customer-Hosted Cloud.
+  
    
+
    
+
+Users with requirements not met by the Auth0 Public Cloud may instead opt for a Private Cloud deployment option.
+
+Auth0 currently offers two Private Cloud deployment models:
+
+* [**Standard** Private Cloud](/private-cloud/standard-private-cloud)
+* [**Managed** Private Cloud](/private-cloud/managed-private-cloud), either hosted by Auth0 or hosted by you on an AWS environment and operated by Auth0 as a managed service
+
+Private Cloud deployments are single-subscriber, isolated instances where none of a customer's resources (software and infrastructure) are shared with any other tenants. This offers increased performance, stability, and availability.
+
+## Private Cloud options and comparison
+
+Here is how the two Private Cloud deployment options compare to each other, as well as how they compare to the Enterprise (Public Cloud) option.
+
+| | Managed | Standard | Public Cloud (Enterprise Subscription Plan) |
+| - | - | - | - |
+| Instance Type | **Dedicated** Cloud Instance | **Dedicated** Cloud Instance | **Shared** Cloud Instance |
+| Deployment Location | Auth0 Private Cloud *or* Customer-Owned AWS Cloud | Auth0 Private Cloud | Auth0 Public Cloud |
+| Pre-Production Environment | Includes fully-isolated and independently updated instance for development and testing | Additional tenants within the same instance as the production tenant available | Additional tenant within the shared environment |
+| Updates | Choice of update frequency to be coordinated with Auth0. Update cycle begins with the Pre-Production Environment | Automatic Monthly Updates | Automatic Updates |
+| Uptime Guarantee | 99.95% SLA with optional upgrade to 99.99% | 99.95% SLA with optional upgrade to 99.99% | 99.90% (no upgrade option available) |
+| Requests per Second | 500 requests per second with optional upgrade to 1500 requests per second | 500 requests per second with optional upgrade to 1500 requests per second | See [Rate Limit Policy for Auth0 APIs](/policies/rate-limits) |
+| [Data Residency](#data-residency) | Region of Choice | Region of Choice | Varies based on tenant location |
+| PCI Certified | Add-on available | Add-on available | No |
+| Geographic High Availability (GEOHA) | Add-on available | No | No |
+
+## Data residency
+
+Private Cloud customers can choose the region where their data is stored -- any region with three (3) availability zones can be used for the Private Cloud. All data will remain and be stored in the chosen region. This is crucial in instances where regulations prevent data from being sent outside the origin region.
+
+For Auth0-hosted Private Cloud customers:
+
+* Backups will be processed and stored in the US
+* Service logs will be processed in the region closest to where the customer hosts their Private Cloud; the current options include Japan, Germany, United Kingdom, United States, Canada, or Australia.
+
+If you are a **Private Cloud** customer with data sovereignty requirements, Auth0 supports Private Cloud deployments in the following regions: USA, Europe, Australia, Canada, and Japan. Otherwise, the Private Cloud can be supported in other regions (except China). Furthermore, Auth0 can:
+
+* Deploy backups to AWS' S3 service in the same region that hosts the Private Cloud
+* Send service logs to Japan, Germany, United Kingdom, United States, Canada, or Australia (regardless of which region you've chosen to host the Private Cloud). You may also opt to not send any service logs
+
+We are currently unable to offer deployments to China.
+
+## Additional information
+
+
\ No newline at end of file
diff --git a/ja-jp/articles/private-cloud/managed-private-cloud/index.md b/ja-jp/articles/private-cloud/managed-private-cloud/index.md
new file mode 100644
index 0000000000..085561e65e
--- /dev/null
+++ b/ja-jp/articles/private-cloud/managed-private-cloud/index.md
@@ -0,0 +1,49 @@
+---
+section: private-cloud
+description: Overview of the Managed Private Cloud deployment option
+topics: managed-private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Managed Private Cloud
+
+Auth0's **Managed Private Cloud** (MPC) is a specially customized Auth0 deployment that gives you greater flexibility and increased input when it comes to day-to-day operations.
+
+## Benefits of the Managed Private Cloud
+
+With a Managed Private Cloud, we work closely with you to make sure that all aspects of your Auth0 environment and deployment are tuned to best meet the needs of your business.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    BenefitDetails
    On-Demand BalancingIf you're expecting a usage spike, contact us and we'll scale your environment so that you have the capacity you need to handle the your traffic load
    Annual Load TestingYou may choose to load test your Auth0 environment if desired. While not required, Auth0 appreciates notification of such tests ahead of time.
    Scheduled UpdatesScheduled updates to create a release cadence to fit your team and your business' schedule
    Staging EnvironmentDedicated environment to test new releases and changes
    GEO-HAOptional. Add-on available for Geographic High Availability.
    Customer-HostingOptional. Can host your Auth0 deployment in an AWS cloud owned by you
    
diff --git a/ja-jp/articles/private-cloud/managed-private-cloud/raci.md b/ja-jp/articles/private-cloud/managed-private-cloud/raci.md
new file mode 100644
index 0000000000..8c343a461b
--- /dev/null
+++ b/ja-jp/articles/private-cloud/managed-private-cloud/raci.md
@@ -0,0 +1,157 @@
+---
+section: private-cloud
+description: Differences between the two Managed Private Cloud deployment options and the Customer-Hosted RACI
+topics: managed-private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Customer-Hosted Differences and RACI
+
+The customer-hosted Managed Private Cloud provides you with everything you need to run Auth0 in your Amazon Web Services environment.
+
+## Differences between the Auth0-Hosted and the Customer-Hosted Managed Private Cloud
+
+
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+    
+        
+        
+        
+    
+
    Auth0-HostedCustomer-Hosted on AWS
    Public-Facing?YesCan be configured to be public-facing or not
    Service and Uptime ReportingAuth0 responsible for monitoringCustomer responsible for monitoring
    Infrastructure and Backup ResponsibilityAuth0 responsible for backupsCustomer responsible for backups
    PCI Compliance Add-OnAvailableNot available
    Breached Password DetectionAvailableNot available
    AWS CostsNot applicableCustomer responsible for all AWS costs associated with running the infrastructure required for a customer-hosted deployment
    
+
+## Responsibilities regarding the Customer-Hosted Private Cloud
+
+Auth0 is responsible for:
+
+* The initial installation
+* General maintenance
+* Installation of patches and updates
+
+The subscriber/customer is responsible for supplying and monitoring the infrastructure on which the Private Cloud runs. This includes, but is not limited to:
+
+* The EC2 hosts
+* Data storage
+* Network resources
+* Any required dependencies
+
+### Detailed Division of Responsibilities
+
+The following RACI Matrix provides an in-depth summary of the roles and responsibilities that will be allocated between Auth0 and the customer/subscriber.
+
+**RACI**:
+
+* **Responsible**: the assigned party who is responsible for executing the task
+* **Accountable**: the assigned party who is accountable for the task being completed
+* **Consulted**: the party/parties whose opinions are requested and with whom there is two-way communication
+* **Informed**: the party/parties who are kept up-to-date with regards to progress and with whom there is one-way communication
+
+
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+    
+
    Private Cloud-Related Tasks or DeliverablesAuth0Customer/SubscriberNotes
    Preparing AWS Infrastructure (including memory, storage, processors, load balances, networks, SSL certificates, DNS records, SMTP servers, enabling Auth0 access via Jumphost/VPN)CR, A (the subscriber's infrastructure engineer)The subscriber will contact Auth0 when the AWS environment is ready and the infrastructure requirements are met
    Set up Development and Production environmentsR, A (the Managed Services Engineer (MSE))IThe Auth0 Managed Service Engineer will SSH into the AWS environment and deploy the Auth0 Private Cloud
    Configure Development and Production environmentsCRThe Auth0 Managed Service Engineer will show the subscriber's infrastructure engineer how to upload the SSL certificates, enter the SMTP credentials, and add administrators
    Operations HandoverRCThe Auth0 Managed Service Engineer and Technical Account Managers will hold an Operations Handover meeting to review information regarding Private Cloud monitoring, backup, and updates and to answer questions
    MonitoringIR, AThe subscriber is responsible for monitoring the Private Cloud Deployment
    Backing UpI (in the event there are issues)R, AThe subscriber is responsible for backing up the Private Cloud deployment using the Command-Line Tools
    User Migration (if required)C, I (in the event there are issues)R, AThe subscriber is responsible for migrating users where appropriate
    UpdatesRR, AThe Auth0 Managed Service Engineers will partner with the subscriber's infrastructure engineers to update the Private Cloud Deployment on an agreed-upon basis. The subscriber is responsible for taking AMI snapshot(s) prior to the update, providing access to the Private Cloud deployment, and being present during the update. Auth0 is responsible for running manual scripts (if required) and informing the subscriber on the status of the update
    Testing Updates in Non-Production Environment(s)C, I (in the event that there are questions/issues)R, AThe subscriber will test the Private Cloud after the Development node has been updated and inform Auth0 of any issues
    Testing Updates in ProductionC, I (in the event that there are questions/issues)R, AThe subscriber will test the Private Cloud after the Production node has been updated and inform Auth0 of any issues
    Issue Identification and Support Ticket SubmissionCR, AThe subscriber is responsible for submitting issues via the Support Center
    Issue ResolutionR, CCAuth0 will provide support for issues within the *core* of the Auth0 product. Auth0 will consult on issues pertaining to integration with the Auth0 product
    
\ No newline at end of file
diff --git a/ja-jp/articles/private-cloud/managed-private-cloud/zones.md b/ja-jp/articles/private-cloud/managed-private-cloud/zones.md
new file mode 100644
index 0000000000..d7452081aa
--- /dev/null
+++ b/ja-jp/articles/private-cloud/managed-private-cloud/zones.md
@@ -0,0 +1,95 @@
+---
+section: private-cloud
+description: Configuring Parameters for a Group of Auth0 Nodes
+topics: managed-private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Work with Zones in the Managed Private Cloud
+
+Beginning with **Managed** Private Cloud Release **1910.0**, you will be able to:
+
+* Group your Auth0 nodes into **zones**
+* Uniquely configure each zone so that each zone has its own parameters and configuration settings
+
+## Zones 101
+
+If you have multiple nodes, you can group the nodes into zones. For example, you might group six nodes as follows:
+
+* **Region 1** consists of nodes `a0-1`, `a0-2`, and `a0-3`.
+* **Region 2** consists of nodes `a0-4`, `a0-5`, and `a0-6`.
+
+Each zone has its own configuration, which informs the base configuration for a zone (therefore, the configuration for a node is inherited from the zone).
+
+## How to create zones
+
+You can create new zones via the Private Cloud Dashboard.
+
+Go to **/psaas/dashboard** (replace **manage_url** with your specific URL). In the left-hand navigation bar, click **Zones**.
+
+![](/media/articles/private-cloud/zones/zones-1.png)
+
+In the top-right corner, click **Create Zone**. Auth0 will create for you a new, inactive zone.
+
+![](/media/articles/private-cloud/zones/zones-2.png)
+
+Click on the downward pointing arrow to reveal the zones creation screen. You'll be asked to provide a **Name** for the zone, as well as the nodes you want to be **Members** of the zone.
+
+![](/media/articles/private-cloud/zones/zones-3.png)
+
+Once you provide a **Name** and indicate the **Members** of the zone, you can click **Save Zones** to persist your changes. Your zone remains inactive until you switch the toggle to **Active** (only one zone may be active at any given time).
+
+![](/media/articles/private-cloud/zones/zones-4.png)
+
+Once you have a zone created, you will see a new drop-down menu in the left-hand navigation bar.
+
+![](/media/articles/private-cloud/zones/zones-6.png)
+
+This new drop-down menu allows you to switch between zones for configuration.
+
+![](/media/articles/private-cloud/zones/zones-5.png)
+
+## Configure zones
+
+To change the configuration for your zone, go to **Cloud Resources** using the left-hand navigation bar.
+
+Recall that the drop-down menu on the left-hand navigation bar allows you to switch between zones for configuration. Make sure that this area shows the zone for which you are adjusting the configuration.
+
+![](/media/articles/private-cloud/zones/zones-7.png)
+
+Once you've made sure that you're adjusting the settings for the correct zone, you can change the **Credentials**, information about the **PostgreSQL instance**, and **Listener** information. 
+
+### Configuration notes
+
+By default, the **Base Configuration**, which contains the configuration parameters all nodes that don't belong to a zone get, is propagated to all nodes and is the default selection.
+
+Any changes you make to the configuration when you have a specific zone selected will be propagated **only to the nodes that are members of that zone**.
+
+When working with zones, modify parameters on a per-zone basis. Any parameters that are shared between multiple nodes should be specified at the Base Configuration level.
+
+### A configuration example
+
+If your **Base Configuration** for your PostgreSQL instance is:
+
+```code
+PostgreSQL:
+    **host**: foo.bar
+    **username**: auth0
+    **password**: password
+```
+
+And you change, for a given zone, the **host**:
+
+```code
+PostgreSQL:
+    **host**: bar.baz
+```
+
+Then the specific configuration applied to a node that's a member of the zone is:
+
+```code
+PostgreSQL:
+    **host**: bar.baz
+    **username**: auth0
+    **password**: password
+```
diff --git a/ja-jp/articles/private-cloud/onboarding/index.md b/ja-jp/articles/private-cloud/onboarding/index.md
new file mode 100644
index 0000000000..d3dbb390a2
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/index.md
@@ -0,0 +1,13 @@
+---
+section: private-saas-deployment
+description: Onboarding
+topics: private-cloud
+contentType: concept
+useCase: private-saas-deployment
+---
+# Onboarding
+
+To provide clarity around the onboarding and implementation processes for the Private SaaS Deployment options, Auth0 has created the following documentation:
+
+* [Private Cloud](/private-saas-deployment/onboarding/private-cloud)
+* [Managed Private Cloud](/private-saas-deployment/onboarding/managed-private-cloud)
\ No newline at end of file
diff --git a/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/index.md b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/index.md
new file mode 100644
index 0000000000..68f9de8246
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/index.md
@@ -0,0 +1,85 @@
+---
+section: private-cloud
+description: Overview of the Private Cloud onboarding process
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Managed Private Cloud Onboarding
+
+This article will cover all facets of the **Managed Private Cloud** (both Auth0-hosted and customer-hosted) onboarding process, including timelines, information about future updates, technical requirements, and implementation instructions for key Managed Private Cloud features.
+
+::: note
+If you are a Private Cloud customer, please see [Private Cloud Onboarding](/private-cloud/onboarding/private-cloud). 
+:::
+
+## Timeline
+
+After your purchase of the Managed Private Cloud, Auth0 will host a **kickoff meeting** with you to begin the implementation process. We strongly recommend that this meeting occur no later than **five (5) days** after the contract signing.
+
+### Auth0-Hosted Managed Private Cloud
+
+Implementation begins immediately after the kickoff meeting, and the process takes **two (2) weeks**. At this point, you're ready for the **Environment Handover**, where your Private Cloud deployment is ready for Production use.
+
+### Customer-Hosted Managed Private Cloud
+
+Implementation begins immediately after the kickoff meeting, and the process takes between **three (3) to four (4) weeks**. The specific amount of time required is highly dependent on the amount of time you need to provision your infrastructure per Auth0 requirements.
+
+At the end of the implementation process, you're ready for the **Environment Handover**. Your Managed Private Cloud deployment is, at this point, ready for Production use.
+
+## Infrastructure
+
+Customers hosting Auth0 using Amazon Web Services should review the [infrastructure requirements](/private-cloud/onboarding/managed-private-cloud/infrastructure), as well as the [IP/Domain and Port List](/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list) required for Private Cloud deployments.
+
+## Updates
+
+Auth0 provides monthly releases to the Managed Private Cloud, of which the four most recent are considered *active*. Updating to an active release is mandatory and ensures that you receive:
+
+* The latest features
+* Security fixes and enhancements
+* Bug fixes
+
+Auth0 will reach out to you to coordinate the specific dates and times during which updates are applied to your deployment.
+
+The [Private Cloud Release Notes](https://auth0.com/releases/) will contain full details on the changes made to your deployment.
+
+## Custom domains
+
+See [Custom Domains](/custom-domains) for instructions on how to map your tenant domain to a custom domain of your choosing, as well as how to manage the required certificates.
+
+If you are a customer-hosted Managed Private Cloud customer using the legacy custom domains feature, you will need to migrate your custom domains to the Auth0 Custom Domains feature. Please consult Auth0 for additional assistance.
+
+## Tenant logging
+
+Auth0 provides [logs](/logs) that are accessible via the Dashboard of the Management API's [`logs` endpoint](/api/v2#!/Logs/get_logs).
+
+You can also choose to send the data logged by Auth0 to an external service. To help with this, there are Auth0 extensions that support automatic log export to services like Sumo Logic or Loggly. The following is a list of Auth0 log export extensions currently available:
+
+* [Auth0 Logs to Application Insights](/extensions/application-insight)
+* [Auth0 Logs to Azure Blob Storage](/extensions/azure-blob-storage)
+* [Auth0 Logs to Loggly](/extensions/loggly)
+* [Auth0 Logs to Papertrail](/extensions/papertrail)
+* [Auth0 Logs to Sumo Logic](/extensions/sumologic)
+* [Auth0 Logs to Splunk](/extensions/splunk)
+* [Auth0 Logs to Logstash](/extensions/logstash)
+* [Auth0 Logs to Mixpanel](/extensions/mixpanel)
+* [Auth0 Logs to Logentries](/extensions/logentries)
+
+## Rate limits
+
+To ensure the quality of Auth0's services, the APIs are subject to rate limiting.
+
+## Support
+
+You can reach out to the Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) team with any questions or concerns you might have. To help expedite your request, please provide as much information as possible in the [Support ticket you open](/support/tickets).
+
+## Remote Access Options
+
+The Managed Private Cloud requires regular access by our Managed Services Engineering team to install patches, updates, and upgrades, troubleshoot and fix issues, and optimize security and performance. See [Remote Access Options](/private-cloud/onboarding/managed-private-cloud/remote-access-options) for information on the options available.
+
+## Create Dashboard administrators
+
+To create additional Dashboard administrators, an *existing* administrator must reach out to Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) requesting that an additional administrative account be made. Please include in your request:
+
+* The name(s) of the tenant(s) for which the new administrator should have access
+* The email addresses of those to be invited
diff --git a/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md
new file mode 100644
index 0000000000..ad68965f76
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/infrastructure.md
@@ -0,0 +1,137 @@
+---
+section: private-cloud
+description: Infrastructure requirements for the customer-hosted Managed Private Cloud
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Infrastructure Requirements for the Customer-Hosted Managed Private Cloud
+
+If you are a Managed Private Cloud customer hosting Auth0 using Amazon Web Services, the following are the requirements you should be aware of when setting up your cloud environment.
+
+## Choosing your AWS regions
+
+The AWS Region(s) in which your deployments are hosted must support:
+
+* At least **three (3)** availability zones
+* Cross-LAN availability zones
+* M4 or M4 instance types
+* RDS for PostgreSQL
+
+## AWS instance types
+
+The size of your AWS instance must be, at minimum, **M4.2xlarge**, though the **M5.2xlarge** size is preferred.
+
+We ask that the individual volumes have the following resource allocation:
+
+
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+    
+        
+        
+        
+        
+        
+    
+
    System / Operating SystemDatabaseUser SearchBackup
    a0-1 (PROD)60 GB100 GB100 GB--
    a0-2 (PROD)60 GB100 GB100 GB--
    a0-3 (PROD)60 GB100 GB100 GB100 GB
    DEV (non-PROD)60 GB50 GB50 GB50 GB
    
+
+Please note that you may have a different number of instances based on your specific deployment type.
+
+## Network
+
+All servers in the cluster must:
+
+* Have outbound access
+* Be on the same subnet
+* Be able to communicate over ports 7777, 27017, 8721, and 8701
+* Listen for and accept traffic from the load balancer over ports 443 and 4443
+
+For a complete listing of IP addresses and ports used, see the [IP/Domain and Port List](/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list).
+
+## Internet connectivity
+
+Internet connectivity is required for all servers in the cluster.
+
+All servers in the cluster require outbound access to:
+* **docker.it.auth0.com** (**52.9.124.234**) on port 443.
+* **cdn.auth0.com** on port 443.
+* Social providers and third-party APIs (as needed)
+
+## DNS records
+
+Each environment (e.g., Development, Staging, Production), which are represented by ``, requires a separate namespace when it comes to DNS records.
+
+You will need DNS records for the following namespaces:
+
+| **Namespace/Environment | Notes |
+| - | - |
+| **Auth0 environment Namespace** (e.g., `*..customer.com`)| You can choose to use a catch-all CNAME record that represents all of your tenants and Dashboard endpoints **or** individual CNAME records for each tenant. The following `env-names` cannot be used: **manage** (reserved for the Dashboard), **config** (reserved for the root tenant authority), **webtask** (reserved for extensibility) |
+| **Auth0 Webtask with Dedicated Domains Namespace** (e.g., `*.wt..customer.com`) | You can choose to use a catch-all CNAME record to represent all of your tenants **or** you can use an individual CNAME record for each tenant pointing to the balanced endpoint |
+| **Custom Domains Namespace** | Requires a catch-all CNAME record redirecting custom domains to the custom domains balanced endpoint **and** an alias record using `edge..customer.com ` that points to the custom domains balanced endpoint |
+
+## Load balancers
+
+You must use either an ALB or ELB. For HTTP health check monitoring, you can use the `testall` endpoint provided by Auth0.
+
+### Software Load Balancers
+
+You can use either NGINX or HA Proxy as the software load balancer in front of the Auth0 environment or for IP whitelisting and/or endpoint filtering (only authentication endpoints are publicly available). If you are using NGINX or HA Proxy as the software load balancer, you must:
+
+* Use TCP mode with Proxy Protocol or HTTPS mode (SSL offloading). In HTTPS mode the connector will not work.
+* Forward the incoming hostname to the nodes
+
+## SSL Certificates
+
+Your SSL certificates must:
+
+* Be signed by a public certificate authority
+* Contain all of the required DNS names (if the certificate is not a wildcard certificate)
+* Be in the PFX or PKCS12 formats
+* Contain the full chain
+
+## TLS
+
+Auth0 requires TLS 1.1 or later.
+
+## SMTP
+
+You must set up and configure a SMTP provider (or a global default email provider) to send emails. Optionally,, you can set up transactional email providers (e.g., SendGrid, Amazon SES, Mandrill) for individual tenants.
+
+STARTTLS is supported by Auth0, but is not required.
+
+## Amazon RDS for PostgreSQL
+
+Amazon RDS for PostgreSQL is currently used to support the Authorization Roles-Based Access Control functionality, but it will be used to support other functionality in the future.
+
+We ask that, at minimum, you use **postgres10, db.r3.xlarge** with 10 GB of storage. You should also allow automated snapshots with seven-day snapshot retention and multi-AZ deployments with automated failover.
+
+## Remote Access
+
+Forthcoming.
\ No newline at end of file
diff --git a/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md
new file mode 100644
index 0000000000..a86e9c3097
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/ip-domain-port-list.md
@@ -0,0 +1,201 @@
+---
+section: private-cloud
+description: Infrastructure requirements for the customer-hosted Managed Private Cloud
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Private Cloud IP/Domain and Port List
+
+Private Cloud deployments require certain ports within the cluster to be open and able to communicate with one another, as well as selected external sites.
+
+## Between Cluster Nodes
+
+When possible, instances within a cluster should have full connectivity to each other so that you do not need to introduce new firewall rules if Auth0 adds new features. However, since this isn't possible in every environment, the following table lists the ports that are required to be open and accessible to other Private Cloud instances in the same cluster:
+
+
+  
+  
+    
+    
+    
+    
+  
+  
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+   
+   
+    
+    
+    
+    
+    
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+
    PortUseRequired?Notes
    27017DatabaseYes
    7777ControlYes
    9001Rate LimitingYesRequired if rate limiting is used
    8721Webtask Logging/ControlYesRequired for logging and debugging
    8701Webtask Logging/ControlYesRequired for logging and debugging
    9200, 9300-9400Elastic SearchYesRequired for Elastic Search
    3000Grafana instrumentationNoRequired if you are using Grafana instrumentation
    22MaintenanceNoEnables maintenance tasks to be done between nodes
    ICMPHealthcheckNoAllows healthchecks between nodes
    
+
+## External Connectivity
+
+Auth0 strives to keep these IP addresses stable, though this is not a given. From time to time, Auth0 may add IP addresses or additional servers. During updates and metrics, you must allow your Private Cloud instances to connect to these addresses.
+
+
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+    
+  
+  
+
    UseDirectionIP/DNSPortNotesRequired?
    AllInboundYour load balancer IP address (often on internal network)80/(443 or 4443)For clusters with more than one node, a load balancer is required for resiliency and performanceYes
    WebtaskOutboundYour load balancer IP address (often on internal network)443Allows rules, webtasks, and extensions to call back to Auth0 endpointsYes
    Command Line InterfaceInbound and OutboundCLI Applications (often on the internal network)10121Allows use of the Private Cloud Command Line InterfaceNo
    UpdatesOutboundapt-mirror.it.auth0.com (52.8.153.197)443Provides update packages for Private Cloud deploymentsYes
    UpdatesOutbounddocker.it.auth0.com (52.9.124.234)443Provides updates for Private Cloud Docker PackagesYes
    Web extensions, Hooks, and Management DashboardOutboundcdn.auth0.com443Required to run web extensions and Hooks; also required for admins to browse to the Management DashboardYes
    ExamplesOutboundgithub.com443Source to download and repackage example applicationsNo
    Usage & TelemetryOutboundapp-gateway.it.auth0.com (52.40.103.203)443Provides usage and telemetry statisticsYes
    MaintenanceInboundJump Host22Allows access to Private Cloud instances for support purposesNo
    Healthcheck  InboundMonitoring Endpoint9110Allows access to Healthcheck endpointsNo
    DNSInbound and OutboundLocal domain servers53Required by the Private Cloud deployment to resolve host names internal and external to your environmentYes
    SMTPOutboundSMTP Server(s)25/587Allows sending of emails from the Private Cloud deploymentNo
    
+
+## Notes
+
+* If you are using social providers for logins, the cluster must be able to connect to the social providers' endpoints.
+* The Jump Host IP is stable and provided at the time of setup.
diff --git a/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md
new file mode 100644
index 0000000000..ecc40318ff
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/managed-private-cloud/remote-access-options.md
@@ -0,0 +1,56 @@
+---
+section: private-cloud
+description: Remote access options for the Managed Private Cloud
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Remote Access Options for the Managed Private Cloud
+
+This article covers the remote access options available to you as a Managed Private Cloud customer.
+
+The Managed Private Cloud requires regular access by our Managed Services Engineering team to install patches, updates, and upgrades, troubleshoot and fix issues, and optimize security and performance.
+
+::: panel Jumphost
+A Jumphost is a security-hardened virtual machine (VM) that acts as a secure communication relay using SSH. The Jumphost initiates the connection from an Auth0 (using a whitelisted IP address) to the Managed Private Cloud VMs. (You would open access to the Jumphost to allow Auth0 access when necessary). 
+
+Auth0's connections originate from a VPN-secured network using public key access to your Jumphost so that only authorized Managed Service Engineers can access connect to your environment.
+:::
+
+## Option 1: Jumphost + Firewall Whitelist
+
+In this configuration, an external Auth0-managed Jumphost is permitted sole SSH management access to the Managed Private Cloud.
+
+![](/media/articles/private-cloud/one-jumphost.png)
+
+*Benefits*: 
+
+* Jumphost provides a single point of access and auditing
+* Auth0 handles tasks related to auditing, session recording, VPN access to Jumphost, and Identity Management
+* Access could be disabled via firewall rules or security groups
+
+## Option 2: Two Jumphosts
+
+Similar to [option 1](#option-1-jumphost--firewall-whitelist), this configuration permits an external Auth0 Jumphost to connect via firewall whitelist to an internal, customer-managed Jumphost. This second Jumphost then provides actual access to the Managed Private Cloud nodes.
+
+![](/media/articles/private-cloud/two-jumphosts.png)
+
+*Benefits*: 
+
+* Jumphost provides a single point of access and auditing
+* Auth0 handles tasks related to auditing, session recording, VPN access to Jumphost, and Identity Management
+* Disabling Auth0 access is as simple as shutting down a server
+* Can be installed in DMZ (if necessary)
+
+*Concerns*: 
+
+* Additional virtual Jumphost required in your infrastructure
+
+## Unsupported configurations
+
+Auth0 does not support other remote access options, such as VDI or Screen Sharing mechanisms. The alternative options introduce compliance concerns, including (but not limited to):
+
+* Not being able to internally audit connections and SSH sessions
+* Not being able to enforce identity management on Auth0 employee accounts
+* Potential exposure to untrusted systems running non-standard software (from where the connections are generated to Auth0 VMs)
+* Inability to verify the identity of participants on the other end
diff --git a/ja-jp/articles/private-cloud/onboarding/private-cloud.md b/ja-jp/articles/private-cloud/onboarding/private-cloud.md
new file mode 100644
index 0000000000..807ed16c83
--- /dev/null
+++ b/ja-jp/articles/private-cloud/onboarding/private-cloud.md
@@ -0,0 +1,63 @@
+---
+section: private-cloud
+description: Overview of the Private Cloud onboarding process
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Private Cloud Onboarding
+
+This article will cover all facets of the **Private Cloud** onboarding process, including timelines, information about future updates, technical requirements, and implementation instructions for key Private Cloud features.
+
+::: note
+If you are a **Managed** Private Cloud customer, please see [Managed Private Cloud Onboarding](/private-cloud/onboarding/managed-private-cloud). 
+:::
+
+## Timeline
+
+After your purchase of the Private Cloud, Auth0 will host a **kickoff meeting** with you to begin the implementation process. We strongly recommend that this meeting occur no later than **five (5) days** after the contract signing.
+
+Implementation begins immediately after the kickoff meeting, and the process takes **two (2) weeks**. At this point, you're ready for the **Environment Handover**, where your Private Cloud deployment is ready for Production use.
+
+## Updates
+
+Auth0 will issue monthly updates to the Private Cloud automatically. The [Private Cloud Release Notes](https://auth0.com/releases/) will contain full details on the changes made to your deployment.
+
+::: note
+The four most recent Private Cloud releases are considered to be the **Active Releases**.
+:::
+
+## Custom domains
+
+See [Custom Domains](/custom-domains) for instructions on how to map your tenant domain to a custom domain of your choosing, as well as how to manage the required certificates.
+
+## Tenant logging
+
+Auth0 provides [logs](/logs) that are accessible via the Dashboard of the Management API's [`logs` endpoint](/api/v2#!/Logs/get_logs).
+
+You can also choose to send the data logged by Auth0 to an external service. To help with this, there are Auth0 extensions that support automatic log export to services like Sumo Logic or Loggly. The following is a list of Auth0 log export extensions currently available:
+
+* [Auth0 Logs to Application Insights](/extensions/application-insight)
+* [Auth0 Logs to Azure Blob Storage](/extensions/azure-blob-storage)
+* [Auth0 Logs to Loggly](/extensions/loggly)
+* [Auth0 Logs to Papertrail](/extensions/papertrail)
+* [Auth0 Logs to Sumo Logic](/extensions/sumologic)
+* [Auth0 Logs to Splunk](/extensions/splunk)
+* [Auth0 Logs to Logstash](/extensions/logstash)
+* [Auth0 Logs to Mixpanel](/extensions/mixpanel)
+* [Auth0 Logs to Logentries](/extensions/logentries)
+
+## Rate limits
+
+To ensure the quality of Auth0's services, the APIs are subject to rate limiting.
+
+## Support
+
+You can reach out to the Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) team with any questions or concerns you might have. To help expedite your request, please provide as much information as possible in the [Support ticket you open](/support/tickets).
+
+## Create Dashboard administrators
+
+To create additional Dashboard administrators, an *existing* administrator must reach out to Auth0 [Support](${env.DOMAIN_URL_SUPPORT}) requesting that an additional administrative account be made. Please include in your request:
+
+* The name(s) of the tenant(s) for which the new administrator should have access
+* The email addresses of those to be invited
\ No newline at end of file
diff --git a/ja-jp/articles/private-cloud/standard-private-cloud/index.md b/ja-jp/articles/private-cloud/standard-private-cloud/index.md
new file mode 100644
index 0000000000..39b3ccb2c8
--- /dev/null
+++ b/ja-jp/articles/private-cloud/standard-private-cloud/index.md
@@ -0,0 +1,14 @@
+---
+section: private-cloud
+description: Overview of the Private Cloud deployment option
+topics: private-cloud
+contentType: concept
+useCase: private-cloud
+---
+# Private Cloud
+
+Auth0's **Private Cloud** option provides you with a dedicated (or single-subscriber) environment. You'll get enhanced performance, security, and compliance over what we include in our standard Public Cloud offering.
+
+With the Private Cloud, Auth0 will handle a majority of the requirements for initial setup and maintenance. Afterward, you'll be on a set update pattern, typically no more frequent than every 30 days.
+
+You'll get the ease of management that comes with using our Public Cloud combined with the power and security of our [Managed Private Cloud](/private-cloud/managed-private-cloud).
diff --git a/ja-jp/articles/product-lifecycle/index.md b/ja-jp/articles/product-lifecycle/index.md
new file mode 100644
index 0000000000..c2e91485da
--- /dev/null
+++ b/ja-jp/articles/product-lifecycle/index.md
@@ -0,0 +1,38 @@
+---
+toc: true
+classes: topic-page
+title: Product Lifecycle
+description: Learn about the Auth0 product lifecycle, including product release stages, deprecations, end-of-life, the migration process, and active migrations.
+topics:
+  - deprecations
+  - migrations
+  - product-lifecycle
+contentType:
+  - index
+  - reference
+useCase:
+  - migrate
+---
+
+
    
+  
    
+  
    Product Lifecycle
    
+  
    
+    We apply an iterative approach to product delivery, including an iterative product release lifecycle that allows us to introduce and improve upon new functionality.
+  
    
+
    
+
+When building Auth0 products, we resolve to
+
+* deliver value to customers early and often, iterating based on their feedback
+* seek a deep understanding of our customers and consider them in every decision
+* relentlessly acquire and analyze data, so we can make better choices
+* visualize and design for current, idealized, and future versions of our whole product when adding features
+
+To best serve these goals, we apply an iterative approach to product delivery, including an iterative product release lifecycle that allows us to introduce and improve upon new functionality.
+
+<%= include('../_includes/_topic-links', { links: [
+'product-lifecycle/product-release-stages',
+'product-lifecycle/migration-process',
+'product-lifecycle/migrations',
+] }) %>
diff --git a/ja-jp/articles/product-lifecycle/migration-process.md b/ja-jp/articles/product-lifecycle/migration-process.md
new file mode 100644
index 0000000000..8443e5a533
--- /dev/null
+++ b/ja-jp/articles/product-lifecycle/migration-process.md
@@ -0,0 +1,41 @@
+---
+toc: true
+title: Migration Process
+description: Learn about the migration process at Auth0, including End of Life announcements, migration windows, and migration guides.
+topics:
+  - migrations
+  - product-lifecycle
+  - breaking-changes
+contentType:
+  - reference
+useCase:
+  - migrate
+---
+
+# Migration Process
+
+To keep our platform stable and secure, we must occasionally modify or remove features or behaviors. These changes will sometimes result in a breaking change.
+
+When we must introduce a breaking change, we first deprecate the affected feature or behavior and announce the Deprecation to our customers. When a new Deprecation is announced, customers should engage in a Migration to move away from the deprecated feature or behavior.
+
+For a list of all Deprecations with active Migrations, see [Active Migrations](/product-lifecycle/migrations).
+
+To learn more about Auth0 product release stages, see [Product Release Stages](/product-lifecycle/product-release-stages).
+
+## End of Life announcement
+
+ When we announce a Deprecation, we typically include the date that the feature or behavior will be moved into the End of Life product release stage and removed from the platform. In some cases, we will immediately deprecate a feature to prevent further adoption and will determine the End of Life date at a later time. End of Life dates can vary between plan types.
+
+## Migration window
+
+When we make an End Of Life announcement, we will also open a migration window to allow customers to prepare for the End of Life date.
+
+Whenever possible, we provide at least a six-month migration window between the End Of Life announcement and the End Of Life date. In case of emergency (for example, critical vulnerabilities that require remediation or changes required by applicable law or third-party certification standards), we may accelerate this time frame. In such cases, we will provide as much prior notice as is reasonable under the circumstances.
+
+## Migration guides
+
+Auth0 Deprecations usually involve replacing deprecated behavior with substantially comparable functionality (although at times, we may elect to discontinue support for some functionality entirely).
+
+To help you migrate to the new functionality and determine the impact on your tenants, we will publish a migration guide, which will detail any necessary modifications to your application's code, inform you of any other required actions, and instruct you about how you opt in to the new behavior prior to the End of Life date.
+
+ Once the End of Life date is reached, the new behavior will automatically be enabled for tenants that did not opt in during the migration window.
\ No newline at end of file
diff --git a/ja-jp/articles/product-lifecycle/migrations.md b/ja-jp/articles/product-lifecycle/migrations.md
new file mode 100644
index 0000000000..253d55524d
--- /dev/null
+++ b/ja-jp/articles/product-lifecycle/migrations.md
@@ -0,0 +1,112 @@
+---
+title: Active Migrations
+description: View all Deprecations with active Migrations that may impact your tenant.
+topics:
+  - migrations
+contentType:
+  - reference
+useCase:
+  - migrate
+---
+
+# Active Migrations
+
+We are actively migrating customers to new behaviors for all Deprecations listed below. Please review these carefully to ensure you've taken any necessary steps to avoid service disruption. To learn more, see [Migration Process](/product-lifecycle/migration-process).
+
+
+  
+    
+      
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+     
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+  
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+  
+
    Feature/BehaviorDeprecatedEnd Of Life DateDetails
    Unpaginated Managment API v2 Request deprecation21 July 2020 (Public Cloud)26 January 2021
+        After 26 January 2021, requests to the following Management API v2 endpoints will return a maximum of 50 items for Public Cloud tenants. To retrieve more items, you must include the page and per_page parameters. Beginning on 21 July 2020, Auth0 will display tenant logs and a migration toggle to help you prepare for this change.
+        
      
+          
    • GET /api/v2/clients
+          
    • GET /api/v2/client-grants
+          
    • GET /api/v2/grants
+          
    • GET /api/v2/connects
+          
    • GET /api/v2/device-crecentials (when type query parameter is used)
+          
    • GET /api/v2/resource-servers
+          
    • GET /api/v2/rules
+        
    
+        All Public Cloud tenants are affected that are created before 21 July 2020 and are actively calling affected endpoints without passing the per_page parameter for queries that can return more than 1 result.
+        Tenants are not affected if they are created after 21 July 2020, are not using the affected endpoints, are using the affected endpoints and passing the per_page parameter, or are making queries that always return only 1 result.
+      
    Node.js v8 Extensibility Runtime15 April 2020TBA
+        The Webtask engine powering Auth0 extensibility points currently uses Node 8. Beginning 31 December 2019, Node.js v8 was no longer under long-term support (LTS). This means that critical security fixes were no longer back-ported to this version. As such, Auth0 is migrating the Webtask runtime from Node.js v8 to Node.js v12.

    On 15 April 2020, we made the Node 12 runtime available for extensibility to all public cloud customers. You have been provided a migration switch that allows you to control your environment's migration to the new runtime environment.

    To learn more about this migration and the steps you should follow to upgrade your implementation, see Migration Guide: Extensibility and Node.js v12.
+      
    Instagram Connection Deprecation5 March 202031 March 2020Facebook announced that on March 31th, 2020, they will turn off the Instagram legacy APIs, and they won't provide an alternative to implement Login with Instagram
    Changes in the Yahoo user profile1 March 20201 March 2020Yahoo changed the way to retrieve the user profile and the information included on it.
    Management API v1October 2016
+        Public Cloud: 13 July 2020
    
+        Private Cloud: November 2020 release
    
+          		Management API v1 will reach its End of Life in the Public Cloud on July 13, 2020. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1. You may be required to take action before that date to ensure no interruption to your service. A migration guide is available to walk you through the required steps. Notifications have been and will continue to be sent to customers that need to complete this migration.
    Useful Resources:
    
+        Management API v1 to v2 Migration Guide
    
+        Management API v2 documentation
    
+        Management API v1 documentation
    
+        Breaking changes
    
+      
    /oauth/ro deprecation for Passwordless Connections8 June 2017
+        TBD
+      On June 8th 2017 we deprecated the /oauth/ro endpoint for passwordless connections. You can now implement the same functionality using the /oauth/token endpoint.
    User Search v26 June 201830 June 2019User Search v2 is being deprecated and you may be required to take action before June 30, 2019. A migration guide is available to walk you through the steps required. Notifications have been and will continue to be sent to customers that need to complete this migration.
    Useful Resources:
    
+        User Search v3
    
+        User Search v3 - Query Syntax
    
+        User Search Best Practices
    
+        User Search v2 to v3 Migration Guide
    
+      
    Tenant Logs Search v221 May 2019
+        Free: 9 July 2019
    
+        Developer: 20 August 2019
    
+        Developer Pro: 20 August 2019
    
+        Enterprise: 4 November 2019
+          		To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3. Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt in for v3 during the provided grace period.  See the migration guide for more information.
    
+
+If you have any questions, please visit the Migrations section of the [Auth0 Community site](https://community.auth0.com/c/auth0-community/Migrations) or create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
diff --git a/ja-jp/articles/product-lifecycle/product-release-stages.md b/ja-jp/articles/product-lifecycle/product-release-stages.md
new file mode 100644
index 0000000000..f663e50032
--- /dev/null
+++ b/ja-jp/articles/product-lifecycle/product-release-stages.md
@@ -0,0 +1,71 @@
+---
+toc: true
+title: Product Release Stages
+description: Learn how we stage, release, and retire product functionality.
+topics:
+  - migrations
+  - product-lifecycle
+contentType:
+  - reference
+useCase:
+  - migrate
+---
+
+# Product Release Stages
+
+Product release stages describe how we stage, release, and retire product functionality. Product features may not progress through all release stages, and the time in each stage will vary depending on the scope and impact of the feature.
+
+## Early Access (Alpha)
+
+Early access offerings give a limited number of subscribers or customer development partners (CDPs) the opportunity to test and provide feedback on future functionality. At this stage, functionality may not be complete, but is ready for validation. 
+
+During this stage, we work with participants to
+
+* confirm that functionality aligns with the intended goal
+* validate that the solution is usable in practice
+* elicit suggested improvement
+
+During this stage, our goal is to ensure that the eventual release provides the maximum value to our customers.
+
+When participating in an early access program, you should understand the following:
+
+* Functionality is under active development, so we do not yet support it for production use.
+* We expect breaking changes, but will do our best to communicate them.
+* The program provides a private preview available to only a limited number of select subscribers.
+* Your feedback may help shape the General Availability (GA) or a subsequent release.
+
+Early Access offerings are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal).
+
+## Beta (Private or Public)
+
+Beta releases give subscribers time to explore and adopt new product capabilities while providing final feedback prior to a General Availability (GA) release. Functionality is code-complete, stable, useful in a variety of scenarios, and believed to meet or almost meet quality expectations for a GA release. Beta releases may be restricted to a select number of subscribers (private) or open to all subscribers (public).
+
+When participating in a beta release, you should understand the following:
+
+* Functionality is feature complete, but we do not yet support it for production use.
+* Breaking changes may occur, and we will do our best to communicate them.
+* Your feedback may help prioritize improvements and fixes in a subsequent release.
+
+Beta releases are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal).
+
+## General Availability
+
+General Availability (GA) releases are fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, we provide a period of backward compatibility in accordance with our deprecation policy and inform customers so they have time to adopt the new release.
+
+## Deprecation
+
+Deprecated features are not supported for use by new subscribers, are not actively being enhanced, and are being only minimally maintained. Tenants using the feature at the time of deprecation will continue to have access. 
+
+Deprecation begins when we introduce new behavior that customers would experience as a breaking change without mediation and ends when the old behavior moves into the End of Life product release stage. During Deprecation, customers should engage in a migration to move away from the deprecated feature or behavior. To learn more, see [Migration Process](/product-lifecycle/migration-process).
+
+Although we know that deprecations can be disruptive, they are necessary to allow us to upgrade technology, improve security and quality, and continue to invest in resources that provide the most value for our customers.
+
+We are committed to transparency, so we try to proactively notify subscribers when deprecations result in breaking changes or cause altered use of Auth0. Additionally, we try to provide end-of-life notices with accompanying recommendations for migration and replacement capabilities where available.
+
+For self-service subscribers, Deprecation is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, Deprecation is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). 
+
+## End Of Life
+
+Features that reach this stage are removed from the platform. Continued use of these features will likely result in errors.
+
+For self-service subscribers, End of Life is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, End of Life is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). 
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/index.html b/ja-jp/articles/protocols/index.html
new file mode 100644
index 0000000000..18daba8d31
--- /dev/null
+++ b/ja-jp/articles/protocols/index.html
@@ -0,0 +1,77 @@
+---
+url: /protocols
+section: articles
+classes: topic-page
+title: Protocols
+description: Which authentication and authorization protocols Auth0 supports and how they work.
+topics:
+  - protocols
+  - oauth2
+  - oidc
+  - saml
+  - ws-fed
+  - ldap
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
    
+  
    
+  
    Protocols
    
+  
    
+    Which authentication and authorization protocols Auth0 supports and how they work.
+  
    
+
    
+
+
    
+  Auth0 implements proven, common and popular identity protocols used in consumer oriented web products (OAuth 2.0, OpenID Connect (OIDC)) and in enterprise deployments (SAML, WS-Federation, LDAP).
+
    
+
+
      
+  
    • 
+    OAuth 2.0
+    
      
+      OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to resources the end-user owns. It is about resource access and sharing.
+    
      
+    
+  
      • 
+  
    • 
+    OpenID Connect
+    
      
+      OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information. At the core, OIDC is about user authentication.
+    
      
+  
      • 
+  
    • 
+    SAML
+    
      
+      Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. The Identity Provider authenticates users and provides to Service Providers an Authentication Assertion that indicates a user has been authenticated.
+    
      
+  
      • 
+  
    • 
+    WS-Federation
+    
      
+      WS-Federation is part of the larger WS-Security framework and an extension to the functionality of WS-Trust. The features of WS-Federation can be used directly by SOAP applications and web services.
+    
      
+  
      • 
+  
    • 
+    LDAP
+    
      
+      Lightweight Directory Access Protocol (LDAP) is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
+    
      
+  
      • 
+
    
diff --git a/ja-jp/articles/protocols/ldap/index.md b/ja-jp/articles/protocols/ldap/index.md
new file mode 100644
index 0000000000..03aaf00b10
--- /dev/null
+++ b/ja-jp/articles/protocols/ldap/index.md
@@ -0,0 +1,24 @@
+---
+description: Details about the LDAP protocol and how it is used by Auth0.
+topics:
+    - protocols
+    - ldap
+contentType:
+  - concept
+useCase:
+  - development
+---
+
+# LDAP
+
+The **Lightweight Directory Access Protocol (LDAP)** is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
+
+The function of LDAP is to enable access to an existing directory, like Active Directory.
+
+In Auth0 we use LDAP to integrate with Active Directory/LDAP through the Active Directory/LDAP Connector that you install in your network.
+
+For more information refer to [Active Directory/LDAP Connector](/connector).
+
+::: note
+You can use [this endpoint proxy implementation](https://github.com/auth0/auth0-ldap-endpoint) to connect a legacy application to Auth0 using the LDAP protocol.
+:::
diff --git a/ja-jp/articles/protocols/oauth2/index.md b/ja-jp/articles/protocols/oauth2/index.md
new file mode 100644
index 0000000000..528c308a9a
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/index.md
@@ -0,0 +1,171 @@
+---
+description: What is the OAuth 2.0 Authorization Framework and how it works.
+toc: true
+topics:
+    - protocols
+    - oauth2
+    - oauth
+contentType:
+  - concept
+useCase:
+  - development
+---
+# OAuth 2.0 Authorization Framework
+
+[OAuth 2.0](https://tools.ietf.org/html/rfc6749) is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. 
+
+OAuth introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token; a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
+
+::: panel Access Token Format
+By default, Auth0 generates Access Tokens for [API Authorization scenarios](/api-auth) in JSON Web Token (JWT) format. JWTs contain three parts: a header, a payload, and a signature:
+- The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+- The payload contains a set of claims, which are statements about the permissions that should be allowed, and other information like the intended audience and the expiration time.
+- The signature is used to validate that the token is trustworthy and has not been tampered with.
+:::
+
+The permissions represented by the access token, in OAuth terms are known as **scopes**. When an application authenticates with Auth0, it specifies the scopes it wants. If those scopes are authorized by the user, then the access token will represent these authorized scopes. For example, a Contacts API may accept three different authorization levels specifying the corresponding scopes: 
+- Reading contacts (`read:contacts`)
+- Creating contacts (scope `create:contacts`)
+- Deleting contacts (scope `delete:contacts`)
+
+For more information refer to [Scopes](/scopes).
+
+## OAuth roles
+
+In any OAuth 2.0 flow we can identify the following roles:
+
+- **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user.
+
+- **Resource Server**: the server hosting the protected resources. This is the API you want to access.
+
+- **Client**: the app requesting access to a protected resource on behalf of the Resource Owner.
+
+- **Authorization Server**: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
+
+## Protocol flow
+
+We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (called authorization grant types) that you can use. For now we will have a more generic look into the flow.
+
+![Generic OAuth Flow](/media/articles/protocols/oauth2-generic-flow.png)
+
+1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
+
+1. Provided that the Resource Owner authorizes this access, the Application receives an **Authorization Grant**. This is a credential representing the Resource Owner's authorization.
+
+1. The Application requests an **Access Token** by authenticating with the Authorization Server and giving the Authorization Grant.
+
+1. Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
+
+1. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
+
+1. Provided that the Access Token is valid, the Resource Server serves the Application's request.
+
+## Authorization grant types
+
+The [OAuth 2.0 Authorization Framework specification](https://tools.ietf.org/html/rfc6749) defines four flows to get an Access Token. These flows are called **grant types**. Deciding which one is suited for your case depends mostly on the type of your application.
+
+- [Authorization Code](/flows/concepts/auth-code): used by Web Apps executing on a server. This is also used by mobile apps, using the [Proof Key for Code Exchange (PKCE) technique](/flows/concepts/auth-code-pkce).
+
+- [Implicit](/flows/concepts/implicit): used by JavaScript-centric apps (Single-Page Applications) executing on the user's browser.
+
+- [Resource Owner Password Credentials](/api-auth/grant/password): used by trusted apps.
+
+- [Client Credentials](/flows/concepts/client-credentials): used for machine-to-machine communication.
+
+The specification also provides an extensibility mechanism for defining additional types.
+
+For details on how each grant type works and when it should be used refer to [API Authorization](/api-auth).
+
+## OAuth endpoints
+
+OAuth 2.0 utilizes two endpoints: the **Authorization** endpoint and the **Token** endpoint.
+
+### Authorization endpoint
+
+The Authorization endpoint is used to interact with the resource owner and get the authorization to access the protected resource. To better understand this, imagine that you want to log in to a service using your Google account. First, the service redirects you to Google in order to authenticate (if you are not already logged in) and then you will get a consent screen, where you will be asked to authorize the service to access some of your data (protected resources); for example, your email address and your list of contacts.
+
+The request parameters of the Authorization endpoint are:
+- `response_type`: Tells the authorization server which grant to execute. Refer to the [How Response Type Works paragraph](#how-response-type-works) for details.
+- `client_id`: The id of the application that asks for authorization.
+- `redirect_uri`: Holds a URL. A successful response from this endpoint results in a redirect to this URL.
+- `scope`: A space-delimited list of permissions that the application requires.
+- `state`: An opaque value, used for security purposes. If this request parameter is set in the request, then it is returned to the application as part of the `redirect_uri`.
+
+#### How response type works
+
+This endpoint is used by the **Authorization Code** and the **Implicit** [grant types](#authorization-grant-types). The authorization server needs to know which grant type the application wants to use, since it affects the kind of credential it will issue: 
+- For **Authorization Code** grant it will issue an authorization code (which can later be exchanged with an access token)
+- For **Implicit** grant it will issue an **access token**.
+
+An access token is an opaque string (or a [JWT](/tokens/concepts/jwts) in an Auth0 implementation) that denotes who has authorized which permissions (scopes) to which application. It is meant to be exchanged with an access token at the [token endpoint](#token-endpoint). 
+
+To inform the authorization server which grant type to use, the `response_type` request parameter is used as follows:
+
+- For **Authorization Code** grant, use `response_type=code` to include an authorization code.
+
+- For **Implicit** grant, use `response_type=token` to include an access token. An alternative is to set `response_type=id_token token` to include both an access token and an ID token.
+
+::: panel ID Token
+The ID Token is a JWT that contains information about the logged in user. It was introduced by **OpenID Connect (OIDC)**. For more info, see [OpenID Connect](/protocols/oidc) and [ID Token](/tokens/concepts/id-tokens).
+:::
+
+#### How response mode works
+
+The [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html) specification added a new parameter that specifies how the result of the authorization request is formatted. This parameter is called `response_mode`, it's optional and can take the following values:
+
+- `query`: This is the default for **Authorization Code** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri`. The response parameters are embedded in the query component (the part after `?`) of the `redirect_uri` in the `Location` header.
+
+  For example, a response might be:
+
+  ```text
+  HTTP/1.1 302 Found
+  Location: https://my-redirect-uri/callback?code=js89p2x1
+  ```
+
+  Where, the `redirect_uri` is `https://my-redirect-uri/callback` and the authorization code is `js89p2x1`.
+
+- `fragment`: This is the default for **Implicit** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri` (which is a request parameter). The response parameters are embedded in the fragment component (the part after `#`) of the `redirect_uri` in the `Location` header.
+
+  For example, a response might be:
+
+  ```text
+  HTTP/1.1 302 Found
+  Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600
+  ```
+
+  Where, the `redirect_uri` is `https://my-redirect-uri/callback`, the Access Token is `eyB...78f`, it's a Bearer token and it expires in 3600 seconds.
+
+- `form_post`: This response mode is defined in the [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) specification. A successful response is `200 OK` and the response parameters are embedded in an HTML form as hidden params. The `action` of the form is the `redirect_uri` and the `onload` attribute is configured to submit the form. After the HTML is loaded by the browser, a redirect to the `redirect_uri` is done.
+
+  For example, a response might be:
+
+  ```html
+  HTTP/1.1 200 OK
+  
+   Submit
+   
+    
    
+      
+      
+    
    
+   
+  
+  ```
+
+- `web_message`: This response mode is defined in the [OAuth 2.0 Web Message Response Mode specification](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00). It uses HTML5 Web Messaging instead of the redirect for the Authorization Response from the Authorization Endpoint. This is particularly useful when using [Silent Authentication](/api-auth/tutorials/silent-authentication). To use this response mode you have to register your app's URL at the __Allowed Web Origins__ field of your [Application's settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+### Token endpoint
+
+The Token endpoint is used by the application in order to get an [access token](/tokens/concepts/access-tokens) or a [refresh token](/tokens/concepts/refresh-tokens). It is used by all flows, except for the [Implicit Flow](/flows/concepts/implicit) (since an access token is issued directly).
+
+- In the [Authorization Code Flow](/flows/concepts/auth-code), the application exchanges the authorization code it got from the Authorization endpoint for an access token.
+
+- In the [Client Credentials Flow](/flows/concepts/client-credentials) and [Resource Owner Password Credentials Grant](/api-auth/grant/password), the application authenticates using a set of credentials and then gets an access token.
+
+## Keep reading
+
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
+* [State Parameter](/protocols/oauth2/oauth-state)
+* [Mitigate CSRF Attacks](/protocols/oauth2/mitigate-csrf-attacks)
+* [Redirect Users](/protocols/oauth2/redirect-users)
diff --git a/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md b/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md
new file mode 100644
index 0000000000..28dc65952a
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md
@@ -0,0 +1,74 @@
+---
+title: Mitigate CSRF Attacks with State Parameters
+description: Learn how to use the OAuth 2.0 state parameters against CSRF attacks.
+topics:
+    - protocols
+    - oauth
+    - state-parameter
+    - csrf
+    - xsrf
+contentType: how-to
+useCase: development
+---
+# Mitigate CSRF Attacks With State Parameters
+
+You can deny malicious requests by using the `state` parameter to hold a correlation value for verification.
+
+A CSRF attack can occur when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate an action instead of getting user data because the attacker has no way to see the response to the forged request.
+
+The state parameter helps mitigate CSRF attacks to ensure that the response belongs to a request that was initiated by the same user. For the most basic cases the state parameter should be a nonce, used to correlate the request with the response received from the authentication. 
+
+::: note
+Most modern OIDC and OAuth2 SDKs, including Auth0.js in single-page applications, handle the state generation and validation automatically. 
+:::
+
+1. Before redirecting a request to the [IdP](/identityproviders), have the application generate a random string. For example:
+
+   ```text
+   xyzABC123
+   ```
+
+::: note
+The allowed length for state is not unlimited. If you get the error `414 Request-URI Too Large` try a smaller value.
+:::
+
+2. Store this string locally. Choose a method based on your type of application. For example:
+
+   * For regular web apps, use a cookie or session
+   * For a single-page app, use local storage in the browser
+   * For a native app, use memory or local storage
+
+   ```text
+   storeStateLocally(xyzABC123)
+   ```
+
+3. Add the `state` parameter to the request (URL-encoding if necessary).
+
+   ```js
+   // Encode the String
+   tenant.auth0.com/authorize?...&state=xyzABC123
+   ```
+
+   After the request is sent, the user is redirected back to the application by Auth0. The `state` value will be included in this redirect. Note that depending on the type of connection used, this value might be in the body of the request or in the query string.
+
+   ```text
+   /callback?...&state=xyzABC123
+   ```
+
+4.  Retrieve the returned `state` value and compare it with the one you stored earlier. If the values match, then approve the authentication response, else deny it.
+
+   ```js
+   // Decode the String
+   var decodedString = Base64.decode(encodedString);
+   if(receivedState === retrieveStateStoredLocally()) {
+    	// Authorized request
+   } else {
+    	// This response is not for us, reject it
+   }
+   ```
+
+## Keep reading
+
+* [State Parameter Overview](/protocols/oauth2/oauth-state)
+* [OAuth 2.0 Framework](/protocols/oauth2)
+* [Protecting against other common threats](/security/common-threats)
diff --git a/ja-jp/articles/protocols/oauth2/oauth-state.md b/ja-jp/articles/protocols/oauth2/oauth-state.md
new file mode 100644
index 0000000000..4667907642
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/oauth-state.md
@@ -0,0 +1,51 @@
+---
+title: State Parameter
+description: Explains how to use the state parameter in authentication requests to help prevent CSRF attacks and restore state
+topics:
+    - protocols
+    - oauth
+    - state-parameter
+    - csrf
+    - xsrf
+    - redirecting
+    - manage-users
+contentType:
+  - concept
+useCase:
+  - development
+---
+
+# State Parameter
+
+Authorization protocols provide a `state` parameter that allows you to restore the previous state of your application. The `state` parameter preserves some state object set by the client in the Authorization request and makes it available to the client in the response.  
+
+## CSRF attacks
+
+The primary reason for using the `state` parameter is to mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery).
+
+When you use `state` for CSRF mitigation on the redirection endpoint, that means that within the `state` value there is a unique and non-guessable value associated with each authentication request about to be initiated. It’s that unique and non-guessable value that allows you to prevent the attack by confirming if the value coming from the response matches the one you expect (the one you generated when initiating the request). The `state` parameter is a string so you can encode any other information in it. 
+
+The way this works is that you send a random value when starting an authentication request and validate the received value when processing the response. This requires you to store something on the client application side (in session or another medium) that allows you to perform the validation. If you receive a response with a state that does not match, you may be the target of an attack because this is either a response for an unsolicited request or someone trying to forge the response. For more information, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks).
+
+![Diagram of CSRF attack](/media/articles/protocols/CSRF_Diagram.png)
+
+::: warning
+The cookie in which the `state` value is stored should be signed to prevent attackers to forge it.
+:::
+
+## Redirect users
+
+You can also use the `state` parameter to encode an application state that will round-trip to the client application after the transaction completes. In this way, the application can put the user where they were before the authentication process happened. For more information, see [Redirect Users With State Parameters](/protocols/oauth2/redirect-users). 
+
+## Limitations
+
+* From a security perspective, neither the request nor the response is integrity-protected so a user can manipulate them. That is true for adding a parameter to the `redirect_uri` as well.
+* The allowed length for `state` is not unlimited. If you get the error `414 Request-URI Too Large`, try a smaller value.
+
+## Keep reading
+
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
+* [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks)
+* [Redirect Users With State Parameters](/protocols/oauth2/redirect-users)
diff --git a/ja-jp/articles/protocols/oauth2/redirect-users.md b/ja-jp/articles/protocols/oauth2/redirect-users.md
new file mode 100644
index 0000000000..5ccdcadfa4
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/redirect-users.md
@@ -0,0 +1,63 @@
+---
+title: Redirect Users With State Parameters
+description: How to redirect users with the OAuth 2.0 state parameter. 
+topics:
+  - users
+  - user-management
+  - state-parameter
+  - redirection
+contentType: how-to
+useCase: manage-users
+---
+# Redirect Users with State Parameters
+
+You can store the application state parameter before you redirect users to authenticate so that you can redirect them back to a URL. For example, if a user intends to access a protected page in your application, and that action triggers the request to authenticate, you can store that URL to redirect the user back to their intended page after the authentication finishes.
+
+Use the `state` parameter to lookup and restore the previous state of your application. Generate and store a `nonce` locally (cookies/session/localstorage), along with any desired state data (like the redirect URL). Use the `nonce` as a state in the protocol message. If the returned state matches the stored nonce, accept the OAuth2 message and fetch the corresponding state data from storage. This is the approach used by Auth0.js.
+
+::: warning
+Passing URLs in plaintext or in any predictable way is unsafe. State should always be unique and opaque to ensure that:
+
+* `state` can be used for defense against CSRF attacks
+* your app is not vulnerable to open redirect exploits, which can lead to phishing attacks
+:::
+
+1. Generate the `nonce` that you will use to protect against CSRF attacks as explained before. Store the `nonce` locally, using it as the key to store all the other application state like the URL where the user intended to go. For example:
+
+   ```json
+   {
+     "xyzABC123" : {
+       redirectUrl: '/protectedResource',
+       expiresOn: [...]
+     }
+   }
+   ```
+
+2. Authenticate the user, sending the generated `nonce` as the state.
+
+3. As part of the callback processing and response validation, verify that the state returned matches the `nonce` stored locally. If it does, retrieve the rest of the application state (like the `redirectUrl`). 
+
+4. Once you complete the callback processing, redirect the user to the URL previously stored.
+
+   Again, how you store the `nonce` and the URL or other information pertinent to the application state depends on your application's type. It can be local storage in single-page or native apps or a cookie in a regular web app. 
+
+## Alternate method
+
+Alternatively, you can:
+
+1. Generate and store a `nonce` locally. 
+
+2. Encode any desired `state` (like the redirect URL) along with the `nonce` in a protected message (that will need to be encrypted/signed to avoid tampering). 
+
+3. In the response processing, unprotect the message, getting the `nonce` and other properties stored. 
+
+4. Validate that the included `nonce` matches what was stored locally and, if so, accept the OAuth2 message.
+
+## Keep reading
+
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [State Parameter](/protocols/oauth2/oauth-state)
+* [Rules](/rules)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
diff --git a/ja-jp/articles/protocols/oidc/identity-providers/okta.md b/ja-jp/articles/protocols/oidc/identity-providers/okta.md
new file mode 100644
index 0000000000..b0e4ca230e
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/identity-providers/okta.md
@@ -0,0 +1,178 @@
+---
+description: How to configure Okta for use as an OpenID Connect identity provider.
+toc: true
+topics:
+    - protocols
+    - oidc
+    - okta
+contentType:
+  - concept
+useCase:
+  - development
+  - add-idp
+---
+# Configure Okta as an OpenID Connect Identity Provider
+
+This article walks you through configuring Okta for use as an OpenID Connect (OIDC) identity provider.
+
+## 1. Create an Okta Application
+
+First, [log in to your Okta account](https://login.okta.com) and head to your Okta dashboard. 
+
+Select **Applications** on the top menu. On the Applications page, click the **Add Application** button to create a new app.
+
+![Okta Applications Dashboard](/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png)
+
+On the **Create New Application** page, select the **Platform** for your application.
+
+![Okta Create Application Select Platform](/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png)
+
+Next, provide the following information for your application settings:
+
+Field | Description
+------|------------
+Name | The name of your application.
+Base URIs (optional) | The domain(s) of your application.
+Login redirect URIs | This should be set to `https://${account.namespace}/login/callback`.
+Group assignments (optional) | The user groups that can sign in to this application.
+Grant type allowed | The grant types to enable for your application.
+
+::: note
+The application settings fields may differ depending on the platform your choose.
+:::
+
+![Okta Create Application Settings](/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png)
+
+Click **Done** to proceed. You'll be taken to the **General** page of your app.
+
+## 2. Get Your Client ID and Client Secret
+
+Go to the **General** page of your app and scroll down to the **Client Credentials** section. This section contains the **Client ID** and **Client Secret** to be used in the next step.
+
+## 3. Create a Custom OpenID Connection with Auth0
+
+At this point, you will configure the integration from the Auth0 side.
+
+Auth0 supports creating custom OpenID Connections by using the [Custom Social Connections Extension](/extensions/custom-social-extensions). Follow the guide to [Setup a New Social Connection](/extensions/custom-social-extensions#set-up-a-new-social-connection) and use the following values for the connection settings:
+
+- __Name__: The name of the connection. Use a name that clearly identify the okta account, you are free to name the connection whatever you would like;
+- __Client ID__: Use the **Client ID** you obtained in the *General* page of your application in Okta;
+- __Client Secret__: Use the **Client Secret** you obtained in the *General* page of your application in Okta;
+- __Authorization URL__: Set `https://{okta-account}/oauth2/v1/authorize`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application;
+- __Token URL__: Set `https://{okta-account}/oauth2/v1/token`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application;
+- __Scope__: The scope parameters to get the profile, as a first approach you can use `openid email profile`;
+- __Fetch User Profile Script__: Use the following Script, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application.
+    ```javascript
+    function(accessToken, ctx, cb) {
+      request({
+        url: "https://{okta-account}/oauth2/v1/userinfo",
+        method: "GET",
+        headers: {
+            "Authorization": "Bearer " + accessToken,
+            "Content-Type": "application/json"
+        }
+        },
+        function(e, r, b) {
+        if (e) return cb(e);
+        if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+        profile = JSON.parse(b);
+        profile.user_id = profile.sub;
+        delete profile.sub;
+        cb(null, profile);
+        }
+      );
+    }
+    ```
+- __Custom Headers__: Leave it empty
+
+Click **Save** to proceed and then continue following the instructions to enable the [connection in your applications](/extensions/custom-social-extensions#new-connection-apps).
+
+## 4. Create an Okta Authorization Server
+
+To retrieve custom claims from Okta, ensure you've set up an Okta authorization server and configured your custom claims in the authorization server settings.
+
+::: note
+For more information on creating an Okta authorization server and adding claims, check out the [Set Up an Authorization Server](https://developer.okta.com/docs/how-to/set-up-auth-server.html) page of the Okta documentation.
+:::
+
+Once the Okta authorization server is set up, continue with the following sections to update the [custom connection](/extensions/custom-social-extensions) you previously created for Okta.
+
+## 5. Get Your Okta Authorization Server Issuer URI
+
+[Log in](https://login.okta.com) to your Okta dashboard and select **Authorization Servers** from the **API** menu at the top.
+
+![Okta Dashboard API Menu](/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png)
+
+On the **Authorization Servers** page, locate the authorization server you created, and make note of the **Issuer URI**. The **Issuer URI** should have the following structure:
+
+`https://{okta-account}/oauth2/{authorization-server-id}`
+
+The **Issuer URI** will be used in the next step.
+
+## 6. Update Your Custom Okta Connection
+
+Visit to the [Extensions](${manage_url}/#/extensions) page on the Auth0 dashboard and click **Custom Social Connections**.
+
+![Manage Auth0 Extensions](/media/articles/oidc/identity-providers/okta/extensions.png)
+
+Next, select your custom Okta connection. In the **Settings** section, update the following fields with your **Issuer URI** and the appropriate endpoint:
+
+Field | Value
+------|------
+Authorization URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/authorize`
+Token URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/token`
+
+Then, scroll down to the **Fetch User Profile Script**, it should look something like this:
+
+```javascript
+function(accessToken, ctx, cb) {
+  request({
+    url: "https://{okta-account}/oauth2/v1/userinfo",
+    method: "GET",
+    headers: {
+        "Authorization": "Bearer " + accessToken,
+        "Content-Type": "application/json"
+    }
+    },
+    function(e, r, b) {
+    if (e) return cb(e);
+    if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+    profile = JSON.parse(b);
+    profile.user_id = profile.sub;
+    delete profile.sub;
+    cb(null, profile);
+    }
+  );
+}
+```
+
+Update the `request.url` with your **Issuer URI** and the `/userinfo` endpoint. For example:
+
+```javascript
+function(accessToken, ctx, cb) {
+  request({
+    url: "https://{okta-account}/oauth2/{authorization-server-id}/v1/userinfo",
+    method: "GET",
+    headers: {
+        "Authorization": "Bearer " + accessToken,
+        "Content-Type": "application/json"
+    }
+    },
+    function(e, r, b) {
+    if (e) return cb(e);
+    if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+    profile = JSON.parse(b);
+    profile.user_id = profile.sub;
+    delete profile.sub;
+    cb(null, profile);
+    }
+  );
+}
+```
+
+Next, click the **Try** button to test the connection. If accepted, you should see the **It Works!** confirmation page.
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/oidc/index.md b/ja-jp/articles/protocols/oidc/index.md
new file mode 100644
index 0000000000..1c0ecdbdf1
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/index.md
@@ -0,0 +1,54 @@
+---
+url: /protocols/oidc
+title: OpenID Connect
+description: Learn about the OpenID Connect (OIDC) protocol and how it works.
+topics:
+    - protocols
+    - connections
+    - oidc
+    - open-id-connect
+contentType:
+  - index
+  - concept
+useCase:
+  - development
+  - oidc
+---
+# OpenID Connect
+
+OpenID Connect (OIDC) is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications.
+
+While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you login, and then taken back to the website.
+
+For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google will send back to Auth0 information about the user and the authentication performed. This information is returned in a JWT. You'll receive an Access Token and, if requested, an ID Token.
+
+## How it works
+
+Let's use the example we mentioned earlier, signing into Auth0 using your Google account, for a high level overview on how the flow works:
+
+1. When you choose to sign in to Auth0 using your Google account, Auth0 sends an **Authorization Request** to Google.
+1. Google authenticates your credentials or asks you to login if you are not already signed in, and asks for your authorization (lists all the permissions that Auth0 wants, for example read your email address, and asks you if you are ok with that).
+1. Once you authenticate and authorize the sign in, Google sends an Access Token, and (if requested) an ID Token, back to Auth0.
+1. Auth0 can retrieve user information from the ID Token or use the Access Token to invoke a Google API.
+
+## Access Tokens
+
+[Access Tokens](/tokens/concepts/access-tokens) are credentials that can be used by an application to access an API. Access Tokens can be an opaque string, JWT, or non-JWT token. Its purpose is to inform the API that the bearer of this token has been granted delegated access to the API and request specific actions (as specified by the scopes that have been granted).
+
+## ID Tokens
+
+The [ID Token](/tokens/id_token) is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth, typically used for UI display. ID Tokens conforms to an industry standard (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) and contain three parts: a header, a body and a signature.
+
+### Claims
+
+JWT Tokens contain [claims](/tokens/concepts/jwt-claims), which are statements (such as name or email address) about an entity (typically, the user) and additional metadata.
+
+The [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) defines a set of [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). The set of standard claims include name, email, gender, birth date, and so on. However, if you want to capture information about a user and there currently isn't a standard claim that best reflects this piece of information, you can create [custom claims and add them to your tokens](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [User Profiles Returned from OIDC-Compliant Pipelines](/users/normalized/oidc)
+* [OIDC Conformant Authentication Adoption Guide](/api-auth/tutorials/adoption)
+* [Webinar: Intro to OpenID Connect](https://auth0.com/resources/webinars/intro-openid-connect)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/oidc/openid-connect-discovery.md b/ja-jp/articles/protocols/oidc/openid-connect-discovery.md
new file mode 100644
index 0000000000..8f2a93e9ca
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/openid-connect-discovery.md
@@ -0,0 +1,72 @@
+---
+description: How to use OpenID Connect discovery to configure applications with Auth0.
+topics:
+    - protocols
+    - oidc-discovery
+    - oidc
+contentType:
+  - how-to
+useCase:
+  - development
+  - configure-apps
+  - oidc-discovery
+---
+
+# Configure Applications with OpenID Connect Discovery
+
+Auth0 exposes OpenID Connect (OIDC) discovery documents (`https://${account.namespace}/.well-known/openid-configuration`). These can be used to automatically configure applications.
+
+A good example is __OpenID Connect middleware for Katana v3 (OWIN)__:
+
+![](/media/articles/oidc-rs256-owin/oidc-discovery.png)
+
+1. Install the nuget package `Microsoft.Owin.Security.OpenIdConnect` (v3.x.x)
+2. Go to `App_Start\Startup.Auth.cs`, and replace your implementation with the following:
+
+  ```cs
+  app.UseCookieAuthentication(new CookieAuthenticationOptions
+  {
+    AuthenticationType = CookieAuthenticationDefaults.AuthenticationType
+  });
+
+  app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+  {
+    Authority = "https://${account.namespace}/",
+    ClientId = "{YOUR_AUTH0_CLIENT_ID}",
+    SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+    ResponseType = "token",
+    Notifications = new OpenIdConnectAuthenticationNotifications
+    {
+      // OPTIONAL: you can read/modify the claims that are populated based on the JWT
+      SecurityTokenValidated = context =>
+      {
+        // add Auth0 Access Token as claim
+        var accessToken = context.ProtocolMessage.AccessToken;
+        if (!string.IsNullOrEmpty(accessToken))
+        {
+          context.AuthenticationTicket.Identity.AddClaim(new Claim("access_token", accessToken));
+        }
+
+        return Task.FromResult(0);
+      }
+    }
+  });
+  ```
+
+## Use RSA algorithm for JWTs
+
+The OpenID Connect middleware does not support JWTs signed with symmetric keys. Make sure you configure your app to use the RSA algorithm using public/private keys:
+
+On the Auth0 dashboard:
+
+1. Go to ${manage_url}/#/applications/{YOUR_AUTH0_CLIENT_ID}/settings
+2. Click on `Show Advanced Settings`.
+3. Set `RS256` as `JsonWebToken Token Signature Algorithm` and click on `Save`.
+
+![RSA 256](/media/articles/oidc-rs256-owin/rsa256.png)
+
+With this setting, Auth0 will issue JWTs signed with your private signing key. Your app will verify them with your public signing key.
+
+## Keep reading
+
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
diff --git a/ja-jp/articles/protocols/saml/adfs.md b/ja-jp/articles/protocols/saml/adfs.md
new file mode 100644
index 0000000000..1651e92e6f
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/adfs.md
@@ -0,0 +1,128 @@
+---
+description: How to Set up an Auth0 SAML Connection Against ADFS
+toc: true
+topics:
+  - saml
+  - adfs
+  - active-directory-federation-services
+contentType:
+  - how-to
+useCase:
+  - add-idp
+  - saml-adfs
+---
+
+# Set Up an ADFS SAML Connection
+
+Create a custom SAML connection to Microsoft's Active Directory Federation Services (ADFS) to get more flexibility when configuring your mappings. 
+
+To create the custom connection, you will need to:
+
+1. Configure ADFS.
+2. Create a SAML connection where Auth0 acts as the service provider.
+3. Edit the Relying Party Trust in ADFS.
+4. Enable and test your integration.
+
+The following sections will guide you through this process. 
+
+## Configure ADFS
+
+### Add a Relying Party Trust
+
+See [Create a relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) for complete details.
+
+1. Launch your instance of ADFS and start the **Add Relying Party Trust** wizard.
+2. On the **Welcome** page, choose **Claims aware** and click **Start**. 
+3. On the **Select Data Source** page, select **Enter data about the relying party manually** and click **Next**.
+4. On the **Specify Display Name** page, provide a descriptive name for your relying party (the typical format is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`) and a brief description under **Notes**. Be sure to replace `YOUR_CONNECTION_NAME` with a unique name you will also use to create a connection in Auth0 in a [later step](#Create-a-SAML-connection-with-Auth0-as-the-service-provider). If you are unsure of the connection name at this time, you can always edit the connection name later. Click **Next**.
+5. On the **Configure Certificate** page, click **Next**. (We will come back to configure the certificate later.)
+6. On the **Configure URL** page, check the box for **Enable support for the SAML 2.0 WebSSO protocol**. The wizard then asks for a **Relying party SAML 2.0 SSO service URL**. For the time being, provide a placeholder URL; we will return to this step later. Click **Next**.
+7. On the **Configure Identifiers** page, indicate that the **Relying party trust identifier** is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (or whatever value you used as the display name when you started using the wizard). Click **Next**.
+8. On the **Choose Access Control Policy** page, select **Permit everyone** and click **Next**.
+9. Review the settings you provided on the **Ready to Add Trust** page and click **Next** to save your information. If you were successful, you'll see a message indicating that on the **Finish** page. 
+10. Make sure that the **Configure claims issuance policy for this application** checkbox is selected, and click **Close**.
+
+### Edit the Claim Issuance Policy
+
+After you close the **Add Relying Party Trust** wizard, the **Edit Claim Issuance Policy** window appears.
+
+1. Click **Add Rule...** to launch the wizard. 
+2. Select **Send LDAP Attributes as Claims** for your **Claim rule template**, and click **Next**.
+3. Provide a value for the **Claim rule name**, such as "LDAP Attributes" (it can be anything you want). 
+4. Choose **Active Directory** as your **Attribute Store**. 
+5. Map your LDAP attributes to the following outgoing claim types:
+
+    | LDAP Attribute | Outgoing Claim |
+    | - | - |
+    | E-Mail-Addresses | E-Mail Address |
+    | Display-Name | Name |
+    | User-Principal-Name | Name ID |
+    | Given-Name | Given Name |
+    | Surname | Surname |
+
+    ::: note
+    The `Name ID` outgoing claim should always be present to ensure correct session handling. We strongly recommend adding all of the claims listed above, especially `E-Mail Address`, since they are the ones most commonly used.
+    :::
+
+    You can add additional claim mappings if necessary. See [Connect Your Application to Microsoft ADFS](/connections/enterprise/adfs#add-additional-ldap-attributes) for details.
+
+6. Click **Finish**.
+7. In the **Edit Claim Issuance Policy** window, click **Apply**. You can now exit out of this window.
+
+### Export the Signing Certificate
+
+Finally, you'll need to export the signing certificate from the ADFS console to upload it to Auth0.
+
+1. Using the left-hand navigation pane, go to **ADFS > Service > Certificates**. Select the **Token-signing** certificate, and right click to select **View Certificate**.
+2. On the **Details** tab, click **Copy to File...**. This launches the **Certificate Export Wizard**. Click **Next**.
+3. Choose **Base-64 encoded X.509 (.CER)** as the format you'd like to use. Click **Next**.
+4. Provide the location to where you want the certificate exported. Click **Next**.
+5. Verify that the settings for your certificate are correct and  click **Finish**.
+
+## Create a SAML connection with Auth0 as the service provider
+
+1. Follow the tutorial on creating a SAML connection where [Auth0 acts as the service provider](/protocols/saml/saml-sp-generic). Where prompted, upload the signing certificate you exported from ADFS.
+
+    The sign in and sign out URLs are usually in the form of `https://your.adfs.server/adfs/ls`.
+
+2. Click **Save**. A page with instructions for creating a new Relying Party Trust in ADFS appears displaying the exact values required for your Auth0 account/connection. Make a note of these values. 
+
+    Here is an example: 
+    
+    | Parameter | Example Value |
+    | - | - |
+    | Post-back URL | `https:///login/callback?connection=YOUR_CONNECTION_NAME` if a [custom domain](/custom-domains) is configured |
+    | --- | `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` if not using custom domains |
+    | Entity ID | `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` |
+    
+## Edit the Relying Party Trust
+
+1. In the ADFS console, go to **ADFS > Relying Party Trusts** using the left-hand navigation pane. Select the Relying Party Trust you created earlier and click **Properties** (located on the right-hand navigation pane). 
+2. Select the **Identifiers** tab, and populate the **Relying Party Identifier** with the **Entity ID** value from the previous screen. Be sure to click **Add** to add the identifier to your list.
+3. Select the **Endpoints** tab, and select the placeholder URL you provided earlier. Click **Edit...**.
+4. Populate the **Trusted URL** with the **Post-back URL** value.
+5. Click **OK**. Finally, click **Apply** and exit the Properties window.
+
+## Optional: Enable sign requests
+
+Optionally, you can sign your SAML requests to the ADFS server.
+
+1. Go to the **Settings** page for your SAMLP Identity Provider in the Auth0 Dashboard.
+2. Enable **Sign Requests**.
+3. Just below the **Sign Requests** toggle is a link to download your certificate.
+4. Return to ADFS and load the downloaded certificate using the **Signatures** tab of the Relying Party properties dialog.
+
+## Enable and test your integration
+
+Before you test your integration, make sure that you've completed the following steps:
+
+* Create a user on the IdP that you can use to test your new connection.
+* [Enable your Connection](/connections) for at least one application.
+
+1. To test your connection, navigate to **Connections > Enterprise > SAML**. 
+2. Click the ADFS row (or the hamburger icon to the right to bring up a list of your SAML connections). 
+3. Select the one you want to test and click the **play** button to test the connection.
+
+## Keep reading
+
+* [Troubleshooting SAML Configuration](/protocols/saml/saml-configuration/troubleshoot)
diff --git a/ja-jp/articles/protocols/saml/identity-providers/index.md b/ja-jp/articles/protocols/saml/identity-providers/index.md
new file mode 100644
index 0000000000..6b88cd5e80
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/index.md
@@ -0,0 +1,24 @@
+---
+title: SAML Identity Providers
+description: How to configure Auth0 to use other SAML Identity Providers.
+classes: topic-page
+topics:
+    - connections
+    - saml
+contentType:
+    - index
+useCase: customize-connections
+---
+
+# SAML Identity Providers
+
+The following articles will cover how you can configure these tools for use with Auth0 as SAML Identity Providers.
+
+<%= include('../../../_includes/_topic-links', { links: [
+  'protocols/saml/identity-providers/okta',
+  'protocols/saml/identity-providers/onelogin',
+  'protocols/saml/identity-providers/ping7',
+  'protocols/saml/identity-providers/salesforce',
+  'protocols/saml/identity-providers/siteminder',
+  'protocols/saml/identity-providers/ssocircle'
+] }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/okta.md b/ja-jp/articles/protocols/saml/identity-providers/okta.md
new file mode 100644
index 0000000000..aa6b9c3a9b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/okta.md
@@ -0,0 +1,78 @@
+---
+title: Okta
+description: How to configure Okta for use as an identity provider.
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - okta
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Okta as an Identity Provider
+
+In this article, we will cover how you can configure Okta for use with Auth0 as a SAML Identity Provider.
+
+## Configure Okta
+
+1. Sign in to the [Okta Developer Console](https://login.okta.com). If you don't already have an Okta account, you will need to create one. 
+2. Use the [App Integration Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm) to add an application for use with Auth0. 
+3. Use Okta's [SAML App Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm#SAMLWizard) to create your SAML integration. When done, you'll be directed to the **Sign On** page for your newly-created app. Click on **View Setup Instructions** to complete the process.
+4. Take note of the **Identity Provider Single Sign-On URL**, and download a copy of the X.509 certificate.
+
+## Configure Auth0
+
+At this point, you will configure the integration from the Auth0 side.
+
+Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection.
+
+You will be prompted to provide the appropriate configuration settings for this Connection.
+
+The only mandatory fields are as follows:
+
+* **Connection Name**: a friendly name for your new Connection;
+* **Sign In URL**: the **Identity Provider Single Sign-On URL** you made note of when you set up your Okta app;
+* **X509 Signing Certificate**: the certificate you downloaded from Okta. You will need to upload the certificate directly to Auth0.
+
+Click **Save** to persist your changes and proceed.
+
+In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration.
+
+## Enable Access to the Connection
+
+Now that you've created and configured your Connection, you'll need to enable access to the Connection for your Application(s).
+
+Using the [Management Dashboard](${manage_url}), go to the [Applications](${manage_url}/#/applications) to see the list of Applications associated with your Auth0 account.
+
+To enable your Connection for a given Application, click **Connections** on its associated row.
+
+Scroll down to the *Enterprise* section, and click the slider to enable your Okta Connection for the associated Application.
+
+## Test your Connection
+
+You can test your Okta-Auth0 integration using the [Management Dashboard](${manage_url}) if you are an Okta user.
+
+Go to **Connections** -> **Enterprise** -> **SAML**. On the row associated with Okta, click the **play** icon to *Try* your Connection.
+
+If your test was successful, you'll see the **It works!** screen. If not, you'll see an error message containing details on what the issue might be.
+
+::: note
+The **Try** button works for users logged in to Auth0 dashboard. You can't send this to an anonymous user, such as a customer. If you don't have a Okta user, you'll need to configure [IdP Initiated SignOn](#idp-initiated-signon) so the someone else can try on their portal.
+:::
+
+## IdP Initiated SignOn
+
+Okta provides an Application Portal/Launcher for their users. If you would like to support the Okta Application Portal/Launcher, change the **Single Sign-on URL** in the Okta dashboard to `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+
+Be sure to change `YOUR_CONNECTION_NAME` to the name of your Auth0 Connection.
+
+See [IdP-Initiated SSO](/protocols/saml/idp-initiated-sso) for information on configuring your Auth0 Connection to route the incoming SAML Response.
+
+## Troubleshooting
+
+The user might see the Okta dashboard after authenticating using a Service Provider-initiated login flow. If you integrated you application with Auth0 using the OpenID Connect (OIDC) protocol, Auth0 takes the value of the `state` parameter and passes it to Okta using the SAML "RelayState" parameter. As such, make sure that you set `state` to a value that Okta can use.
+
+<%= include('../../../connections/_quickstart-links.md') %>
diff --git a/ja-jp/articles/protocols/saml/identity-providers/onelogin.md b/ja-jp/articles/protocols/saml/identity-providers/onelogin.md
new file mode 100644
index 0000000000..373d099c62
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/onelogin.md
@@ -0,0 +1,141 @@
+---
+title: OneLogin
+description: How to configure OneLogin as an identity provider.
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - onelogin
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure OneLogin as an Identity Provider
+
+In this article, we will cover how you can configure OneLogin for use with Auth0 as a SAML Identity Provider.
+
+## Step 1: Configure OneLogin
+
+1. Log in to the [OneLogin](https://www.onelogin.com/) Dashboard, and click **Apps** > **Add Apps**.
+2. Search for **SAML**, and select **SAML Test Connector (IdP w/attr)**.
+3. When prompted, change the **Display Name** of your app. Click **SAVE**.
+4. Go to the **SSO** tab, and copy the values for **SAML 2.0 Endpoint (HTTP)** and **SLO Endpoint (HTTP)**. Click on the **View Details** link at the **X.509 Certificate** field.
+5. Download the X.509 certificate **onelogin.pem**.
+
+## Step 2: Configure the connection using the Auth0 dashboard
+
+At this point, you will configure the integration from the Auth0 side.
+
+Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection.
+
+You will be prompted to provide the appropriate configuration settings for this Connection.
+
+The only mandatory fields are as follows:
+
+* **Sign In URL**: provide the **SAML 2.0 Endpoint (HTTP)** value you made note of when setting up your OneLogin app
+* **Sign Out URL**: provide the **SLO Endpoint (HTTP)** value you made note of when setting up your OneLogin app 
+* **X509 Signing Certificate**: the certificate you downloaded from Onelogin. You will need to upload the certificate directly to Auth0.
+
+Click **Save** to persist your changes and proceed.
+
+In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration.
+
+### Auth0 configuration values
+
+To finish configuration of the SAML application, the admin will need the following information regarding Auth0:
+
+* **SAML Consumer URL**: `https://${account.namespace}/login/callback`
+* **SAML Audience**: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`
+
+Also make sure to copy the values of the **post-back URL** and the **Entity ID** before heading back to the Configuration tab of your [OneLogin](https://www.onelogin.com/) app:
+
+| Auth0 value | OneLogin configuration field |
+| - | - |
+| Post-back URL | ACS (Consumer) URL **and** Recipient |
+| Entity ID | Audience |
+
+You'll also need to provide a valid regular expression for the **ACS (Consumer) URL Validator** (for example, `[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)`)
+
+## Step 3: Test your connection
+
+Before testing your connection:
+
+* Be sure that you have a OneLogin user that you can use for testing. If not, go to the **Users** tab on the OneLogin dashboard and add one
+* Be sure that your new Auth0 SAMLP connection has been associated with an [application](/application) (otherwise you will get an `invalid_request: the connection was disabled` error)
+
+At this point, you are set to test the connection! Next to your **SAML** connection, click the **Try** button.
+
+If all goes well, you will be redirected to a page informing you that the connection works.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard. You cannot provide a link to this to an anonymous user (such as a customer) for testing.
+
+If you don't have a OneLogin user, please read the following section on configuring IdP-Initiated Signon so that your customer can test using their portal.
+:::
+
+## IdP-initiated sign on
+
+OneLogin offers an Application Portal/Launcher to their users. If you want to take advantage of this functionality, you will have to change the **SAML Consumer URL** in OneLogin dashboard to include the `connection` parameter (e.g., `https://${account.namespace}/login/callback?connection=onelogin-customer`). Be sure to replace `onelogin-customer` with the name of your Auth0 connection.
+
+Finally, be sure to pick the application to which your user is redirected *after* the SAML assertion is consumed. You can find more information in the [IdP-Initiated SSO page](/protocols/saml/idp-initiated-sso).
+
+## Edit connection mappings
+
+If you use OneLogin and Auth0 out of the box, users logging in using OneLogin and being created in the Auth0 dashboard will be missing some profile information you might like to have.
+
+To collect additional user information, you must edit the appropriate parameters in the OneLogin dashboard, include the parameters in the SAML assertion, and create the mappings in the Auth0 connection.
+
+### User profile attributes
+
+Sometimes the standard User Profile Attributes are not enough for the functionality you want to build. If this is the case, you can use custom attributes in order to enhance the SAML token. Let's work through a basic example.
+
+The SAML token contains, among others, two attributes: `FirstName` and `LastName`. Let's add a new custom attribute, named `FullName`, that will contain the concatenation of first and last name.
+
+In order to do so, navigate to the OneLogin dashboard and edit your app.
+
+On the __Parameters__ tab, click __Add Parameter__.
+
+In the pop-up, set a name for your new custom attribute using the __Field name__ text box. Make sure you check the __Include in SAML assertion__ flag. Click __Save__.
+
+The new attribute you created is displayed. Click on the __Value__ field, which is currently displaying `- No default -`.
+
+Click the __Value__ dropdown menu and select `- Macro -`.
+
+At the text box, set the value to `{firstname} {lastname}`. Click __Save__.
+
+At this point, we're ready to test our changes.
+
+Go back to [Auth0 dashboard > Connections > Enterprise > SAML](${manage_url}/#/connections/enterprise). On your __SAML__ connection, click the __Try__ button. The result should include the new attribute `FullName`.
+
+::: note
+You can find more information on _Attribute Macros_ at the [OneLogin Help Center](https://support.onelogin.com/hc/en-us/articles/201174464-Attribute-macros).
+:::
+
+### Add new parameter to the SAML assertion
+
+For the purposes of demonstration, let's see how we can add the `EmailAddress` information, which is more than the concatenation of two fields we're already sending, to our login.
+
+### OneLogin configuration
+
+Before you can map users' **EmailAddress**, you must add this field as a custom parameter to the OneLogin dashboard. Set **Field name** to `EmailAddress` and **Value** as `Email`.
+
+You can find details on the steps needed to customize the user profile [in the section above](#customize-the-user-profile).
+
+Once you've made your changes, save them, and test your connection once again. 
+
+Now, review your Auth0 user, making sure that the `EmailAddress` information is now included and that the value is correct.
+
+### Auth0 mappings
+
+You are now ready to proceed with mapping the user information fields in Auth0.
+
+Go to the __Settings__ of your [SAML](${manage_url}/#/connections/enterprise) and navigate to the tab __Mappings__. For the email addresses, copy the mapping below, and paste it into the text box.
+
+```javascript
+{
+  "email": "EmailAddress"
+}
+```
+
+Save your changes, and try your connection again. Once you have successfully logged in, go to [Dashboard > Users](${manage_url}/#/users), and check your login. You will see additional information for the appropriate user.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/ping7.md b/ja-jp/articles/protocols/saml/identity-providers/ping7.md
new file mode 100644
index 0000000000..1165cfb3d1
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/ping7.md
@@ -0,0 +1,69 @@
+---
+title: PingFederate
+description: How to configure PingFederate as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - pingfederate
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure PingFederate as an Identity Provider
+
+In this article, we will cover how you can configure PingFederate for use with Auth0 as a SAML Identity Provider.
+
+PingFederate is a federation server that provides identity management, single sign-on, and API security for the enterprise. To configure Auth0 to use PingFederate as an identity provider, you will use primarily the default values and your Auth0 tenant metadata file to upload the required configuration parameter values for your Auth0 tenant. If the metadata upload fails for some reason, these are the most important configuration parameters:
+
+* __EntityID:__ `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`
+* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback`
+* __Logout URL:__ `https://${account.namespace}/logout`
+* __HTTP-Redirect__ binding for SAML Request
+* __HTTP-POST__ binding for SAML Response
+
+::: panel IdP-Initiated SSO
+If you want to use **IdP-Initiated SSO**, make sure to include the `connection` parameter in the Assertion Consumer Service URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`.
+:::
+
+1. Download your Auth0 metadata file from `https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME`. Make sure that you use your custom domain if you have one configured. You will upload this file to import your Auth0 tenant information into the PingFederate configuration.
+
+2. Sign on to your PingFederated account and select **Create New** from the **SP Connections** section.
+
+3. Configure the __SP Connection__. 
+
+    - Select the __Browser SSO Profiles__ as the __Connection Type__.
+    - Select __Browser SSO__ as the __Connection Options__.
+
+4. Upload the metadata file that you downloaded in step 1. The __Entity ID__, __Connection Name__ and the __Base URL__ will be automatically populated based on the information from the metadata file. 
+
+5. Configure __Browser SSO__. 
+
+    - Select __SP-Initiated SSO__ and __SP-Initiated SLO__ in __SAML Profiles__.
+    - Go to the __Assertion Creation__ section and click __Configure Assertion__. Accept all defaults for the next two screens. 
+
+6. Go to the __IdP Adapter Mapping__ section. This is where users will be authenticated. Likely, you already have one configured in your PingFederate installation. Select one, or add a new one.
+
+    ::: note
+    Auth0 only requires the __NameIdentifier__ claim. All other  attributes will be passed further to the end application.
+    :::
+
+7. Configure __Protocol Settings__. Values for __Protocol Settings__ are imported from the metadata file. Next, you will see the __Assertion Consumer Service URL__ and the Sign-Out URLs. Click __Next__ to the __Allowable SAML Bindings__ section.
+
+8. Leave __POST__ and __Redirect__ enabled. Make sure __SAML Assertion__ is always signed.
+
+9. Configure __Credentials__. On __Digital Signature Settings__, select your signing certificate and make sure you check the option to include it in the `` element.
+
+10. Configure the certificate used to sign incoming requests. You can download the Auth0 certificate (use `https://YOUR_TENANT.auth0.com/pem`) and upload it here. 
+
+    ::: note
+    Auth0 signs `SAMLRequests` by default; you can change that when you configure the connection. 
+    :::
+
+11. Review your settings and set as __Active__ or __Inactive__. 
+
+12. Click __Save__ at the bottom of the screen. You should see the new SP Connection on the __Main__ screen.
+
+## Keep reading
+
+* See the complete PingFederate instructions to [configure PingFederate as an identity provider](https://docs.pivotal.io/p-identity/1-5/pingfederate/config-pingfederate.html). 
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/salesforce.md b/ja-jp/articles/protocols/saml/identity-providers/salesforce.md
new file mode 100644
index 0000000000..35bbe93e2b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/salesforce.md
@@ -0,0 +1,138 @@
+---
+description: How to configure Auth0 to use Salesforce as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - salesforce
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Salesforce as an Identity Provider
+
+In this article, we will cover how you can configure Salesforce for use with Auth0 as a SAML Identity Provider.
+
+There are 6 steps to this sample:
+
+1. Obtain Salesforce certificate and metadata.
+2. Set up Auth0 as a Service Provider.
+3. Configure the Salesforce Identity Provider (IDP).
+4. Grant Privileges to users in Salesforce.
+5. Test the connection to the Salesforce IDP.
+6. Troubleshooting
+
+## 1. Obtain Salesforce Certificate and Metadata
+
+1. Register for a [Salesforce.com](http://salesforce.com) account. You must select one of the account types that include Identity Provider support.
+2. Create your [Salesforce Domain](https://help.salesforce.com/apex/HTViewHelpDoc?id=domain_name_setup.htm&language=en_US).
+2. Log into your Salesforce domain `https://YOUR_DOMAIN.my.salesforce.com` and click on **Setup** on the top right.
+4. In the left menu, expand **Security Controls** and select **Identity Provider**.
+
+5. Create an Identity Provider by clicking **Enable Identity Provider**.
+
+6. Select the default certificate and click **Save**.
+
+7. Click **Download Certificate** to download the Identity Provider certificate.
+
+8. Click **Download Metadata** to download the Identity Provider metadata.
+
+## 2. Set up Auth0 as a Service Provider
+
+In this step, you will configure Auth0 as a Service Provider to communicate with the **Salesforce** Identity Provider for Single Sign-on (SSO).
+
+1. Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard.
+2. Click on **SAML**
+3. Click on **Create New Connection**
+4. In the configuration window, enter the following information:
+
+  **Connection Name:** You can choose any name, such as "SFIDP".
+
+  **Email Domains:** Enter the email domain name that your users will be logging in from. For example, if your users have an email domain of `abc-example.com`, you would enter that into this field. You can enter multiple email domains if needed.
+
+  **Sign In URL:** Open the metaData file you downloaded from Salesforce and locate the line that contains the `SingleSignOnService` binding. The value of the `Location` attribute on this line is your Sign In URL. It will be something like:
+
+    `https://{sf-account-name}.my.salesforce.com/idp/endpoint/HttpRedirect`
+
+  where "{sf-account-name}" is your Salesforce account domain name.
+
+  **Sign Out URL:** enter the same URL that was entered for Sign In URL.
+
+  **Certificate:**  The certificate downloaded from Salesforce is in .crt format. Convert this certificate to .pem format with the following command.
+
+    `openssl x509 -in original.crt -out sfcert.pem -outform PEM`
+
+  where `original.crt` is the filename of the downloaded .crt file.
+
+5. Click **UPLOAD CERTIFICATE**  and select the `.pem` file you just created. (`sfcert.pem` in the example above). You can ignore the rest of the fields for now.
+
+6. Click **SAVE**.
+
+7. Click **CONTINUE**. In the window that appears, SAML metadata for the Auth0 Service Provider will be displayed. Keep this window open since you will need to enter some of this information into Salesforce to finish the configuration.
+
+::: note
+You can always access the metadata for an Auth0 SAML connection with this URL syntax: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+:::
+
+## 3. Configure the Salesforce Identity Provider
+
+In this step, you will configure Salesforce with the metadata from Auth0 so it can receive and respond to SAML-based authentication requests from Auth0.
+
+1. Open **[salesforce.com](http://salesforce.com)**.
+2. Go to **Setup** > **Manage Apps**. Click **Connected Apps**.
+3. Create a new Connected App and fill out the following fields:
+
+  **Entity ID:** `urn:auth0:${account.namespace}:YOUR_CONNECTION_NAME`
+
+  **ACS URL:** `https://${account.namespace}/login/callback`
+
+  **Subject Type:** `Persistent ID`
+
+  **Name ID Format:** Choose the one with emailAddress
+
+  **Issuer:** `https://{your-saleforce-domain}.my.salesforce.com`
+
+6. Click **Save** to complete the configuration of the IDP.
+
+## 4. Grant Privileges to Users in Salesforce
+
+1. Open **[salesforce.com](http://salesforce.com)** and click **Setup**.
+2. Under **Manage Users**, click **Profiles**.
+3. Scroll down to find the profile called **Standard User** (on page 2).
+4. Click on **Edit** to edit the profile.
+5. Scroll down to the **Connected App Access** section.
+6. Check the box next to the name of your connected app to enable it for this profile.
+7. Click **Save**.
+8. Under **Manage Users**, click **Users**.
+9. Click **Edit** to edit your test user and set the profile to **Standard User**.
+
+::: note
+If you wish to use a different Salesforce profile, you must enable the connected app for that profile and ensure that all users that login through the Salesforce Identity Provider have that profile.
+:::
+
+## 5. Test the connection to the Salesforce IDP
+
+In this step, you will test the SAML configuration between Auth0 and Salesforce.
+
+* Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard. Select the **SAMLP Identity Provider**.
+* Click the **Try** button for the SAML connection you created earlier. You should be redirected from Auth0 to the Salesforce login page.
+* Once you are at the **Salesforce login screen**, login with the credentials you provided when you created the Salesforce account.
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says **"It works!!!"**. This page will display the contents of the SAML authentication assertion sent by the Salesforce IDP to Auth0.
+
+If it didn't work, double check the steps above and consult the **troubleshooting** section below.
+
+::: note
+The **Try** button only works for users logged into the Auth0 dashboard.
+:::
+
+## 6. Troubleshooting
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction and save it in a HAR file. See [Generate and Analyze HAR Files](/troubleshoot/guides/generate-har-files) for details.
+
+Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace for the sequence of GETs. You should see a redirect from your original site to the IDP, a post of credentials if you had to log in, and then a redirect back to the callback URL. The HAR file will also contain the SAML response.
+
+Make sure that cookies and JavaScript are enabled for your browser.
+
+Make sure that the user's profile in Salesforce has permission to login via the Salesforce IDP (See section 4 above).
diff --git a/ja-jp/articles/protocols/saml/identity-providers/siteminder.md b/ja-jp/articles/protocols/saml/identity-providers/siteminder.md
new file mode 100644
index 0000000000..f8a0765b73
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/siteminder.md
@@ -0,0 +1,71 @@
+---
+title: SiteMinder
+description: How to configure SiteMinder as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - siteminder
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure SiteMinder as an Identity Provider
+
+In this article, we will cover how you can configure SiteMinder for use with Auth0 as a SAML Identity Provider.
+
+When configuring SiteMinder, you will use the default values for most options. However, you will need the following Auth0-related values in the configuration steps were cover later on in this guide:
+
+* __EntityID:__ `urn:auth0:${account.tenant}`
+* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback`
+* __Logout URL:__ `https://${account.namespace}/logout`
+* __HTTP-Redirect__ binding for SAML Request
+* __HTTP-POST__ binding for SAML Response
+
+The instructions below will guide you into where these values need to be entered in SiteMinder.
+
+### 1. Open the SAML Service Provider Dialog
+
+Provide an appropriate name for this Service Provider. We suggest using:
+
+* __Name:__ `${account.tenant}`
+
+### 2. Defining NameIdentifier
+
+You can define many ways of generating a `NameIdentifier` for users authenticating with SiteMinder. Typically you will map this value to one of the user properties in the User Directory as `uid`.
+
+### 3. Configure the Service Provider General SAML properties
+
+Use the following values when prompted:
+
+* __SP ID:__ `urn:auth0:${account.tenant}`
+* __SAML Version:__ `2.0`
+* __Skew Time:__ `30 seconds`
+
+### 4. Configure the Assertion Consumer Service URL
+
+The __Assertion Consumer Service URL__ is the location where SiteMinder will POST back the SAML Token. This Service Provider (${account.tenant}) only supports the `HTTP-POST` binding for SAML Responses. Use these values:
+
+* __Assertion Consumer Service:__ `https://${account.namespace}/login/callback`
+* __HTTP-Post__: `checked`
+
+### 5. Configure additional user properties to send in the token
+
+Add any other properties you wish to share about the authenticated user to this Service Provider. Common values are: `name`, `lastname`, `email address`, and so on. This Service Provider will use the `NameIdentifier` defined in [step 2](#2-defining-nameidentifier) as a unique handle of the user. These attributes will be treated as reference information.
+
+### 6. Enter the Single Sign-Out URL
+
+* __SLO Location URL:__ `https://${account.namespace}/logout`
+
+### 7. Optional Assertion Encryption
+
+The Service Provider supports encryption of Assertions.
+To use this option, do the following to download the Service Provider public key certificate.
+
+* In the Auth0 Dashboard, click on __Connections__ and then __Enterprise__
+* Click on SAMLP Identity Provider
+* Click on the Setup icon (pencil)
+
+In the window which appears, the seventh (last) bullet gives you links to download the .pem or .cer format certificate.
+
+Download the desired certificate and add it to the SiteMinder __Policy Server Keystore__.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md b/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md
new file mode 100644
index 0000000000..b5b1f0448e
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md
@@ -0,0 +1,188 @@
+---
+title: SAML Single Sign-On with SSOCircle as an Identity Provider
+description: Learn how to configure an application to use Auth0 for SAML Single Sign-on (SSO), authenticating users against SSOCircle
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - ssocircle
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure SSOCircle as an Identity Provider
+
+In this article, we will cover how you can configure SSOCircle for use with Auth0 as a SAML Identity Provider.
+
+::: warning
+As of July 8, 2016, SSOCircle supports integration via [manual configuration using public settings](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration/). If you have previously used account-specific metadata, your integration will still function, though this usage is now deprecated.
+:::
+
+## 1. Obtain the SSOCircle Metadata
+
+Navigate to [SSOCircle's IDP page](https://idp.ssocircle.com/) to see the metadata required for integration. You will be shown an XML file.
+
+From this page, you will need to save the following attributes (you will use these values for Step 2 of this tutorial):
+
+1. The Location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type.
+
+2. The Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type.
+
+[Download](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration) and save the SSOCircle CA Certificate. You will also use this in Step 2.
+
+## 2. Configure an enterprise connection in Auth0
+
+In this step, you will configure the integration from the Auth0 side.
+
+To do so, see [Connect Your App to SAML Identity Providers](/connections/enterprise/saml). 
+
+While setting up your connection, make sure you use the following settings:
+
+| Field | Description |
+| ----- | ----------- |
+| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. |
+| **IdP Domains** (optional) | Comma-separated list of valid domains. Only needed if using the Lock login widget. |
+| **Sign In URL** | SAML single login URL. Enter the location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. |
+| **X.509 Signing Certificate** | Signing certificate (encoded in PEM or CER). Upload the **SSOCircle CA Certificate** you saved in [step 1](#1-obtain-the-ssocircle-metadata). |
+| **Sign Out URL** (optional) | SAML single logout URL. Enter the Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. |
+
+When setting up mappings, use the following JSON to properly map SAML attributes from SSO Circle, and click **Save**:
+
+```json
+{
+  "email": "EmailAddress",
+  "given_name": "FirstName",
+  "family_name": "LastName"
+}
+```
+
+::: note
+In general, you can access the metadata for an Auth0 SAML connection using a URL with the following format: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+You will need to provide this metadata to SSOCircle at a later point during the configuration process.
+:::
+
+## 3. Configure the SSOCircle Identity Provider
+
+In this step, you will configure the integration from the SSOCircle side.
+
+Log in to your [SSOCircle](http://ssocircle.com) account. You will be directed to your user profile, and to the left of that is a navigation bar.
+
+In the navigation bar, click **Manage Metadata**.
+
+Select **Add New Service Provider**, and provide the following information to configure the new service provider (which, in this case, is Auth0):
+
+* **FQDN of the ServiceProvider:** `auth0.com`
+* **Attributes to send in assertion:** check the box for `EmailAddress`
+* **Insert your metadata information:** paste in the XML metadata that you downloaded after you configured your Auth0 Connection (the file begins with `callback URLs includes those to which users will be redirected after authentication. The URL(s) entered here must match the **callback URL** in the HTML code you will create in a later step. Normally, you would enter a URL for your Application, but to keep this example simple, users will simply be sent to the Auth0 JWT Tool.
+
+Click **SAVE CHANGES**.
+
+Returning to the top of **Settings**, click on  **Connections**.
+
+Scroll down to the section with the **Enterprise** heading. Find the row for the SAML Connection you created above and click the on/off toggle to enable the SAML Connection.
+
+## 5. Test the Auth0-SSOCircle Connection
+
+In this step, you will test to make sure the SAML configuration between Auth0 and SSOCircle is working.
+
+To test your connection, see [Test Enterprise Connections](/dashboard/guides/connections/test-connections-enterprise).
+
+During this process you will be asked to log in and consent. Everything should go smoothly, but if the test shows that something didn't work, please review the above steps and consult the [Troubleshooting](#8-troubleshooting) section.
+
+Additionally, if you receive a window that says, "Your session has timed out," click the **Return to Login page** link below the message.
+
+## 6. Create the HTML Page for the Test Application
+
+In this section, you will create a simple HTML page that uses the **Auth0 Lock Widget**. Lock will then trigger the SAML login sequence.
+
+```html
+
+
+  
+    
     Click on the button to log in 
    
+
+    
+    
+    
+  
+
+```
+
+Be sure to fill in the first parameter of the `Auth0Lock` with your Client ID. To find the Client ID, go to **[Auth0 Dashboard](${manage_url}) > [Applications](${manage_url}/#/applications)** and click the **Settings** icon to the right of your Application name. Copy the **Client ID** value.
+
+Save this file. For the purposes of this example, we'll call it `hello-saml.html`.
+
+## 7. Test Your Sample Application
+
+In this step, you will complete an end-to-end test using your sample HTML application that uses the Auth0 SAML connection you set up to perform SSO with SSOCircle.
+
+Open the `hello-saml.html` file with a web browser. You should see a white page with a login button on it.
+
+![Test Homepage](/media/articles/saml/identity-providers/ssocircle/hello-saml.png)
+
+Click **Login**. The **Auth0 Lock** Widget will appear.
+
+::: note
+If you are prompted to enter an email address, make sure the domain for the email address you enter is listed under **Settings** for the Auth0 Application you previously configured.
+:::
+
+Provide the requested log in credentials and click **Access** to initiate the SAML SSO sequence with SSOCircle.
+
+At this point, you will be redirected to the SSOCircle IDP to log in.
+
+![Login Screen](/media/articles/saml/identity-providers/ssocircle/login.png)
+
+Once you have logged in, you will see a SAML Consent Page. Click the box indicating that you're not a robot, then click **Continue SAML Single Sign-On**.
+
+![Consent to SAML Screen Screen](/media/articles/saml/identity-providers/ssocircle/saml-consent.png)
+
+::: note
+Please note that you will not be prompted for your credentials if you still have an active session at SSOCircle. If this is the case, you will simply be redirected to the callback URL specified in `hello-saml.html`.
+:::
+
+If you successfully authenticate, you will be redirected to the callback URL specified in `hello-saml.html` (`http://jwt.io`). You will see the token that your Application receives.
+
+## 8. Troubleshooting
+
+* If logging in to your Application doesn't work the first time, clear your browser's history and cookies before testing again. The browser may not be picking up the latest version of your HTML.
+* When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis (search for "HTTP Trace" to find one appropriate for your needs). Once you have an HTTP tracer, capture the login sequence from start to finish and analyze the trace to see the sequence of `GET` requests to see where the error occurs. You should see:
+  * A redirect from your original site to the IDP;
+  * A post of credentials (if you were asked to log in);
+  * A redirect to the callback URL.
+* Ensure that your browser has enabled cookies and JavaScript.
+* Check to make sure that the callback URL specified in the HTML is also listed in the **Allowed Callback URLs** field in the **Settings** tab of the Auth0 Application.
diff --git a/ja-jp/articles/protocols/saml/idp-initiated-sso.md b/ja-jp/articles/protocols/saml/idp-initiated-sso.md
new file mode 100644
index 0000000000..bf2e5617b9
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/idp-initiated-sso.md
@@ -0,0 +1,91 @@
+---
+title: IdP-Initiated Single Sign-On
+description: How to setup SAML Identity Provider-initiated Single Sign-on (SSO).
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-idp
+---
+
+# IdP-Initiated Single Sign-On
+
+Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider. The service provider redirects the user to the identity provider for the purposes of authentication. This process is commonly used for consumer-facing scenarios.
+
+However, in enterprise scenarios, it is sometimes common to begin with the identity provider initiating SSO, not the service provider. For example, an enterprise company might set up a portal to ensure that users navigate to the correct application after they sign on to the portal.
+
+## Risks of using an IdP-Initiated SSO flow
+
+::: warning
+IdP-Initiated flows carry a security risk and are therefore NOT recommended. Make sure you understand the risks before enabling IdP-Initiated SSO. 
+:::
+
+In an IdP-initiated flow neither Auth0 (which receives the unsolicited response from the Identity Provider) nor the application (that receives the unsolicited response generated by Auth0) can verify that the user actually started the flow. Because of this, enabling this flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/support/solutions/articles/48001048951-login-csrf), where an attacker can trick a legitimate user into unknowingly logging into the application with the identity of the attacker.  
+
+The recommendation is to use SP-Initiated flows whenever possible.
+
+### On IdP-Initiated flows and OpenID Connect
+
+OpenID Connect (OIDC) does not support the concept of an IdP-Initiated flow. So while Auth0 offers the possibility of translating a SAML IdP-Initiated flow (from a SAML connection) into an OIDC response for an application, any application that properly implements the OIDC/OAuth2 protocol will reject an unrequested response. 
+
+When using OIDC applications, the best option is to have the users start the login flow **at the application** or configure the portals to send the user to the application's login initiation endpoint (without an IdP-Initiated SAML response) so that, again, the application starts the authentication flow.
+
+## How to set up IDP-initiated SSO
+
+
+
+To setup IdP-Initiated SSO, go to the [Enterprise Connections](${manage_url}/#/connections/enterprise) section of the dashboard and choose **SAMLP Identity Provider**. Under the **Settings** section you can see the configuration for IdP-Initiated SSO.
+
+![Configure SAML Idp-Initiated SSO Settings](/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png)
+
+**Default Application:** When the IdP initiated login succeeds this is the application where users are routed. This setting shows available applications enabled for this connection. Select the application from the dropdown that you want the users to login with IdP initiated. Only one application can be selected for an IdP-initiated login per SAML connection.
+
+**Response Protocol:** This is the protocol used to connect your selected **Default Application**. Most commonly applications are configured with the OpenID Connect protocol (read [here](#on-idp-initiated-flows-and-OIDC) for possible pitfalls). However if you have configured a SAML2 Web App addon for your application and want to route the SAML assertion you will need to select SAML.
+
+**Query String:** Query string options help to customise the behavior when the OpenID Connect protocol is used. You can set multiple options similar to setting parameters with a [query string](https://en.wikipedia.org/wiki/Query_string). You can set:
+
+* `redirect_uri`: When the IdP-initiated login has completed the request is then redirected to the first URL listed in the **Allowed Callback URLs** for the application. However if you set a `redirect_uri` the IdP will redirect to this URL. This brings flexibility for cases like when you have set subdomain scheme with a wildcard and you only want to redirect to one specific subdomain.
+* `scope`: You could define scopes for the ID Token sent. Note that it is possible to set multiple scopes.
+* `response_type`: This field is used to set the token for Implicit Grant Flow for SPA applications. You could set code for Authorization Code Grant Flow for regular web applications.
+
+Example Query String:
+
+`redirect_uri=https://jwt.io&scope=openid email&response_type=token`
+
+## Post-back URL
+
+When using **IdP-Initiated SSO**, please make sure to include the `connection` parameter in the post-back URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+
+## Lock/Auth0.js
+
+If your application is a Single-Page Application that uses Lock or Auth0.js to process the authentication results, you will have to explicitly indicate that you want to allow IdP-Initiated flows (and thus [open the application to possible Login CSRF attacks](#risks-of-using-an-idp-Initiated-SSO-flow)).
+
+If you are using [Auth0.js](/libraries/auth0js), you have to update the **webAuth.parseHash** of the [library](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) and set the flag **__enableIdPInitiatedLogin** to `true`.
+
+```javascript
+var data = webAuth.parseHash(
+  {
+    ...
+    __enableIdPInitiatedLogin: true
+    ...
+  }
+```
+
+If you're using [Lock](/lock), you can include the flag using the options parameter sent to the constructor.
+
+```javascript
+const lock = new Auth0Lock(clientID, domain, options)
+```
+
+Here's the flag itself:
+
+```javascript
+var options = {
+    _enableIdPInitiatedLogin: true
+};
+```
+
+Note that the **enableIdPInitiatedLogin** flag is preceded by **one** underscore when used with Lock and **two** underscores when used with the auth0.js library.
diff --git a/ja-jp/articles/protocols/saml/index.html b/ja-jp/articles/protocols/saml/index.html
new file mode 100644
index 0000000000..7be7d02149
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/index.html
@@ -0,0 +1,114 @@
+---
+url: /protocols/saml
+section: articles
+classes: topic-page
+title: SAML
+topics:
+  - saml
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
    
+  
    
+  
    SAML
    
+  
    
+    Documentation on SAML protocol.
+  
    
+
    
+
+
diff --git a/ja-jp/articles/protocols/saml/saml-apps/_header.md b/ja-jp/articles/protocols/saml/saml-apps/_header.md
new file mode 100644
index 0000000000..d3708bc803
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/_header.md
@@ -0,0 +1,5 @@
+# ${meta.title}
+
+## SAML Configuration
+
+Use the following SAML configuration:
diff --git a/ja-jp/articles/protocols/saml/saml-apps/atlassian.md b/ja-jp/articles/protocols/saml/saml-apps/atlassian.md
new file mode 100644
index 0000000000..7d2bae9c92
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/atlassian.md
@@ -0,0 +1,73 @@
+---
+description: Learn how to configure Single Sign-on (SSO) with Atlassian.
+topics:
+    - saml
+    - identity-providers
+    - atlassian
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Atlassian SAML Configuration
+
+You can configure Auth0 as the SAML SSO identity provider for Atlassian.
+
+## Prerequisites
+
+* A verified domain in your [Atlassian Organization](https://admin.atlassian.com/).
+* [Atlassian Access](https://www.atlassian.com/software/access)
+
+## Configure Auth0 identity provider application
+
+1. Go to [Dashboard > Applcations](${manage_url}/#/applications) and click **Regular Web Applications** to create an app.
+2. Add connections to your app. Make sure that the correct set of Auth0 connections are associated with your identity provider app.
+3. Go to **Addons** tab and enable the **SAML2 Web App** addon. 
+4. Click the **Usage** tab. Here you will find information to populate SAML metadata in Atlassian Access. Note the settings. 
+
+## Configure Atlassian SAML connection
+
+1. Log in to your [Atlassian Admin](https://admin.atlassian.com/) dashboard.
+2. Go to **Organization > Security > SAML single sign-on**.
+3. Copy the configuration settings from the Auth0 SAML2 Web App addon usage page:
+
+| Setting | Description|
+| -- | -- |
+| **Identity provider Entity ID** | `urn:TENANT.auth0.com` |
+| **Identity provider SSO URL** | `https://TENANT.auth0.com/samlp/APP_ID` |
+| **Public x509 certificate** | Content from your .pem file: `https://TENANT.auth0.com/pem` |
+
+4. Click **Save configuration**.
+5. On the summary page, copy the **SP Assertion Consumer Service URL**.
+
+## Configure callback URL in Auth0
+
+1. Go back to [Dashboard > Applcations](${manage_url}/#/applications) to your applications SAML2 addon settings.
+2. Update the **Application Callback URL** with the **SP Assertion Consumer Service URL** you copied in the previous section.
+3. On the **Settings** tab, update the metadata mapping file. For example:
+
+```js
+{
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+    "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
+  },
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+  ],
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email"
+}
+```
+
+![SAML2 Web App Settings](/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png)
+
+4. Click **Save**.
+
+## Test connection
+
+1. Go to [id.atlassian.com](https://id.atlassian.com/) and log in.
+2. Login with SAML identity provider and return to Atlassian.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md b/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md
new file mode 100644
index 0000000000..4c32cef3d7
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md
@@ -0,0 +1,37 @@
+---
+title: Cisco WebEx SAML Configuration
+description: Cisco WebEx SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - cisco
+    - cisco-webex
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+   "mappings": {
+     "email": ["email", "uid", "Name_ID"]
+   },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+     "email",
+   ]
+}
+```
+
+Notice that Webex has an option to automatically provision new users. You will need to send that info along as claims (lastname, and so on).
+
+:::note
+If you integrate Auth0 with Cisco Spark services, you might find this article helpful: [Single Sign-On with Cisco Spark Services](https://collaborationhelp.cisco.com/article/en-us/lfu88u).
+:::
diff --git a/ja-jp/articles/protocols/saml/saml-apps/datadog.md b/ja-jp/articles/protocols/saml/saml-apps/datadog.md
new file mode 100644
index 0000000000..45b50ab027
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/datadog.md
@@ -0,0 +1,34 @@
+---
+title: Datadog SAML Configuration
+description: Datadog SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - datadog
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://app.datadoghq.com/account/saml/metadata.xml",
+   "mappings": {
+   },
+   "createUpnClaim":       false,
+   "passthroughClaimsWithNoMapping": false,
+   "mapUnknownClaimsAsIs": false,
+   "mapIdentities":        false,
+   "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+   "nameIdentifierProbes": [
+     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+   ],
+}
+```
+
+The **Callback URL** is `https://app.datadoghq.com/account/saml/assertion`.
+
+Notice that Datadog has an option to automatically provision new users. Check [Datadog docs](http://docs.datadoghq.com/guides/saml/) for more details.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/egencia.md b/ja-jp/articles/protocols/saml/saml-apps/egencia.md
new file mode 100644
index 0000000000..6fbc053c54
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/egencia.md
@@ -0,0 +1,33 @@
+---
+title: Egencia SAML Configuration
+description: Egencia SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - egencia
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+  "audience": "https://{YOUR_ACCOUNT_NAME}.egencia.com",
+   "mappings": {
+   },
+   "createUpnClaim":       false,
+   "passthroughClaimsWithNoMapping": false,
+   "mapUnknownClaimsAsIs": false,
+   "mapIdentities":        false,
+   "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+   "nameIdentifierProbes": [
+     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+   ],
+}
+```
+
+The **Callback URL** is `https://www.egencia.com/auth/v1/artifactConsumer`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/eloqua.md b/ja-jp/articles/protocols/saml/saml-apps/eloqua.md
new file mode 100644
index 0000000000..cabc886eb5
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/eloqua.md
@@ -0,0 +1,39 @@
+---
+title: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration
+description: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - eloqua
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+"audience": "",
+ "recipient": "https://login.eloqua.com/auth/saml2/acs",
+   "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+   },
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+        ],
+ "destination": "https://login.eloqua.com/auth/saml2/acs"
+  }
+
+```
+
+The **Callback URL** is `https://login.eloqua.com/auth/saml2/acs`.
+
+::: note
+The Service Provider Entity URL copied from within the IDP settings in Eloqua to set the audience restriction within Auth0.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md b/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md
new file mode 100644
index 0000000000..5e528c57ff
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md
@@ -0,0 +1,39 @@
+---
+title: Freshdesk SAML Configuration
+description: Freshdesk SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - freshdesk
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+The Application Callback URL would found at: Freshworks Dashboard => Security => SAML SSO => Assertion Consumer Service(ACS) URL
+The audience can be at Freshworks Dashboard => Security => SAML SSO => Service Provider(SP) Entity ID URL
+
+```json
+{
+  "audience": "https://{FD Domain}.freshworks.com/sp/SAML/{xxxxxxxxxxxxxxxxxxx}/metadata",
+  "mappings": {
+    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+    "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
+  },
+  "createUpnClaim": false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities": false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://{FD Domain}.freshdesk.com/login/saml`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md b/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md
new file mode 100644
index 0000000000..fdd173f9e9
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md
@@ -0,0 +1,88 @@
+---
+title: Configure Auth0 as Identity Provider for GitHub Enterprise Cloud
+description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Cloud (github.com) organization.
+topics:
+    - saml
+    - identity-providers
+    - github
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for GitHub Enterprise Cloud
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Cloud](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) (i.e., github.com). Note that GitHub requires an Enterprise-level subscription to enable using an external SAML identity provider.
+
+When setting up SAML Single Sign-on (SSO) in your organization, you can test your implementation without affecting your organization members by leaving Require SAML SSO authentication for all members of the organization name organization unchecked. See [GitHub documentation on authentication with SAML](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) for more information.
+
+::: note
+**Heads up!** This article applies to GitHub Enterprise Cloud (github.com). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Server (private instance), check [this page](/protocols/saml/saml-apps/github-server) instead.
+:::
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. 
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}/saml/consume`
+
+- **Settings**:
+
+```json
+{
+  "audience": "https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}",
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  "passthroughClaimsWithNoMapping": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
+  ]
+}
+```
+
+**Note**: Make sure to replace `{YOUR_GITHUB_ORG_NAME}` with the GitHub organization name that corresponds to your subscription.
+
+The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). 
+
+As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this:
+
+```json
+{
+  [...]
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  [...]
+}
+```
+
+## Configure SAML Single Sign-On on GitHub
+Follow the instruction from GitHub's [Enabling and testing SAML Single Sign-on (SSO) for your organization](https://help.github.com/en/articles/enabling-and-testing-saml-single-sign-on-for-your-organization) to complete the configuration on GitHub Enterprise Cloud. You will need the following information:
+
+* **Sign On URL** (for step 6): `https://${account.namespace}/samlp/{CLIENT_ID}`
+  `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0.
+* **Issuer** (step 7): `urn:auth0:${account.tenant}`
+* **Public Certificate** (step 8): Download it from `https://${account.namespace}/pem`. Open the downloaded file with a text editor, copy the contents and paste them in the text area on GitHub.
+* **Signature method** (step 9): `RSA256-SHA256`
+* **Digest method** (step 9): `SHA256`
+
+The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog:
+
+![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png)
+
+As recommended in GitHub's documentation, before enabling SAML SSO for your organization, click **Test SAML configuration** to ensure that the information you've entered is correct.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/github-server.md b/ja-jp/articles/protocols/saml/saml-apps/github-server.md
new file mode 100644
index 0000000000..4495d0bca6
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/github-server.md
@@ -0,0 +1,85 @@
+---
+title: Configure Auth0 as Identity Provider for GitHub Enterprise Server
+description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Server private instance.
+topics:
+    - saml
+    - identity-providers
+    - github
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for GitHub Enterprise Server
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Server](https://help.github.com/en/enterprise/2.16/admin/user-management/using-saml) (i.e. your private GitHub appliance). 
+
+::: note
+**Heads up!** This article applies to GitHub Enterprise Server (deployed as a private instance). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Cloud (github.com), check [this page](/protocols/saml/saml-apps/github-cloud) instead.
+:::
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. 
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `{YOUR_GITHUB_SERVER_URL}/saml/consume`
+
+- **Settings**:
+
+```json
+{
+  "audience": "{YOUR_GITHUB_SERVER_URL}",
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  "passthroughClaimsWithNoMapping": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
+  ]
+}
+```
+
+**Note**: Make sure to replace `{YOUR_GITHUB_SERVER_URL}` with the URL assigned to your GitHub Server (i.e. `https://github.example.com`).
+
+The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). 
+
+As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this:
+
+```json
+{
+  [...]
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  [...]
+}
+```
+
+## Configure SAML Single Sign-on on GitHub
+Follow the instruction from [Using SAML on Enterprise Server- GitHub Help](https://help.github.com/en/enterprise/admin/user-management/using-saml#configuring-saml-settings) to complete the configuration on GitHub Enterprise Cloud. You will need the following information:
+
+* **Sign On URL**: `https://${account.namespace}/samlp/{CLIENT_ID}`
+  `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0.
+* **Issuer**: `urn:auth0:${account.tenant}`
+* **Verification Certificate**: You will need to download it from `https://${account.namespace}/pem` and upload it in this field.
+* **User Attributes**: you should leave the defaults here, as the mapping that we configured in the SAML Web App addon uses the default attribute names proposed by GitHub.
+* **Signature method**: `RSA256-SHA256`
+* **Digest method**: `SHA256`
+
+The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog:
+
+![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png)
diff --git a/ja-jp/articles/protocols/saml/saml-apps/google-apps.md b/ja-jp/articles/protocols/saml/saml-apps/google-apps.md
new file mode 100644
index 0000000000..1bb7255078
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/google-apps.md
@@ -0,0 +1,35 @@
+---
+title: G Suite SAML Configuration
+description: G Suite SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - g-suite
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs",
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+  },
+  "createUpnClaim": false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ],
+}
+```
+
+The **Callback URL** is `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/heroku.md b/ja-jp/articles/protocols/saml/saml-apps/heroku.md
new file mode 100644
index 0000000000..2cefaeeea2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/heroku.md
@@ -0,0 +1,75 @@
+---
+description: Learn how to configure Single Sign-on (SSO) with Heroku.
+topics:
+    - saml
+    - identity-providers
+    - heroku
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Single Sign-on with Heroku
+
+::: note
+You must have administrative rights to your organization account on Heroku to configure Single Sign-on (SSO). Organization accounts are included with Heroku Enterprise plans.
+:::
+
+You can configure Single Sign-on (SSO) so that your users can log into Heroku using any of Auth0's supported [identity providers](/identityproviders).
+
+## 1. Obtain Your Heroku Identifiers
+
+On the Settings page for your organization in Heroku, scroll to the **Single Sign-On (SSO)** section.
+
+![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png)
+
+You will need the following two parameters from this section to integrate with Auth0:
+
+* __Heroku Entity ID__
+* __ACS URL__
+
+## 2. Register Heroku with Auth0
+
+Log in to your [Auth0 Dashboard](${manage_url}/#/applications) and select the [application](/applications) for which you want to configure SSO with Heroku. Go to the __Addons__ section of your Application, and enable __SAML2 Web App__:
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard.png)
+
+Enter the __ACS URL__ from the previous step into the __Application Callback URL__ field and update the settings as follows:
+
+```json
+{
+ "audience":"THE-HEROKU-ENTITY-ID",
+ "mappings": {
+   "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ },
+ "createUpnClaim": false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities": false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ ]
+}
+```
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png)
+
+::: note
+The `audience` parameter is the __Heroku Entity ID__. It will be formatted like this: `https://sso.heroku.com/saml/YOUR-HEROKU-ORG`
+:::
+
+Click **Save**. 
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png)
+
+## 3. Provide Auth0 Metadata to Heroku
+
+Open up the __Usage__ section of the SAML2 Web App Configuration pop-up and download the __Identity Provider Metadata__.
+
+Return to Heroku. Click on __Upload Metadata__ and select the file containing the **Identity Provider Metadata** you downloaded in the previous step.
+
+![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png)
+
+Once you've uploaded your metadata, your SSO integration is fully set up.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md b/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md
new file mode 100644
index 0000000000..cbeb6da827
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md
@@ -0,0 +1,26 @@
+---
+title: Hosted Graphite SAML Configuration
+description: Hosted Graphite SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - hosted-graphite
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://www.hostedgraphite.com/metadata/{YOUR-USER-ID}/",
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/index.md b/ja-jp/articles/protocols/saml/saml-apps/index.md
new file mode 100644
index 0000000000..472ae21b8d
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/index.md
@@ -0,0 +1,44 @@
+---
+title: SAML Configurations for Single Sign-on Integrations
+description: This page lists SAML Configurations for various Single Sign-on (SSO) integrations including G Suite, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday, Pluralsight and Workpath.
+classes: topic-page
+topics:
+    - saml
+    - identity-providers
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
+
    
+  
    
+  
    SAML Configurations for Single Sign-on Integrations
    
+  
    
+    This page lists SAML Configurations for various Single Sign-on (SSO) integrations.
+  
    
+
    
+
+## SAML Configuration Tutorials
+
+<%= include('../../../_includes/_topic-links', { links: [
+  'protocols/saml/saml-apps/atlassian',
+  'protocols/saml/saml-apps/cisco-webex',
+  'protocols/saml/saml-apps/datadog',
+  'protocols/saml/saml-apps/egencia',
+  'protocols/saml/saml-apps/eloqua',
+  'protocols/saml/saml-apps/freshdesk',
+  'protocols/saml/saml-apps/github-cloud',
+  'protocols/saml/saml-apps/github-server',
+  'protocols/saml/saml-apps/google-apps',
+  'protocols/saml/saml-apps/heroku',
+  'protocols/saml/saml-apps/hosted-graphite',
+  'protocols/saml/saml-apps/litmos',
+  'protocols/saml/saml-apps/pluralsight',
+  'protocols/saml/saml-apps/sprout-video',
+  'protocols/saml/saml-apps/tableau-online',
+  'protocols/saml/saml-apps/tableau-server',
+  'protocols/saml/saml-apps/workday',
+  'protocols/saml/saml-apps/workpath'
+] }) %>
diff --git a/ja-jp/articles/protocols/saml/saml-apps/litmos.md b/ja-jp/articles/protocols/saml/saml-apps/litmos.md
new file mode 100644
index 0000000000..756f9ca3b4
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/litmos.md
@@ -0,0 +1,131 @@
+---
+title: Litmos SAML Configuration
+description: Litmos SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - litmos
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "mappings": {
+   "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+   "email":       "Email",
+   "given_name":  "FirstName",
+   "family_name": "LastName"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "https://{YOUR DOMAIN}.litmos.com/integration/samllogin",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ ]
+}
+```
+
+The **Callback URL** is `https://{YOUR DOMAIN}.litmos.com/integration/samllogin`.
+
+## Sample SAML
+
+```xml
+
+    urn:{tenant}.auth0.com
+    
+        
+    
+    
+        urn:{tenant}.auth0.com
+        
+            
+                
+                
+                
+                    
+                        
+                        
+                    
+                    
+                    cdFGeW7M8cxg9xEVh/gLxRKlWDA=
+                
+            
+            *********
+            
+                
+                    *********
+                
+            
+        
+        
+            brandon@litmos.com
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
+            
+        
+        
+            
+                Smith
+            
+            
+                John
+            
+            
+                john@mail.com
+            
+        
+    
+
+```
diff --git a/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md b/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md
new file mode 100644
index 0000000000..ea769d56c2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md
@@ -0,0 +1,37 @@
+---
+title: Pluralsight SAML Configuration
+description: Pluralsight SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - pluralsight
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+  "audience":  "www.pluralsight.com",
+  "mappings": {
+    "user_id":     "id",
+    "email":       "email",
+    "given_name":  "firstName",
+    "family_name": "lastName"
+  },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://prod-pf.pluralsight.com/sp/ACS.saml2`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md b/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md
new file mode 100644
index 0000000000..fd4ada302c
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md
@@ -0,0 +1,32 @@
+---
+title: Sprout Video SAML Configuration
+description: Sprout Video SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - sprout-video
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io",
+ "mappings": {  
+       "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+       "email":       "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+ ],
+}
+```
diff --git a/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md b/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md
new file mode 100644
index 0000000000..685f3b65b4
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md
@@ -0,0 +1,40 @@
+---
+title: Tableau Online SAML Configuration
+description: Tableau Online SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - tableau
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "https://sso.online.tableau.com/public/sp/metadata?alias={YOUR TABLEAU ALIAS}",
+ "recipient": "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}",
+ "mappings": {
+    "email": "Email"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+ ]
+}
+```
+The **Callback URL** is `https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}`.
+The recipient, destination and callback URLL value is same as Assertion Consumer Service URL from Tableau Authentication Page.
+See [https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm](https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm) for more information.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md b/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md
new file mode 100644
index 0000000000..e299a22d92
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md
@@ -0,0 +1,39 @@
+---
+title: Tableau Server SAML Configuration
+description: Tableau Server SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - tableau
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "{YOUR TABLEAU AUDIENCE}",
+ "recipient": "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html",
+ "mappings": {
+    "email": "username"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+ ]
+}
+```
+
+The **Callback URL** is `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/workday.md b/ja-jp/articles/protocols/saml/saml-apps/workday.md
new file mode 100644
index 0000000000..1e3f3f6970
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/workday.md
@@ -0,0 +1,35 @@
+---
+title: Workday SAML Configuration
+description: Workday SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - workday
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "http://www.workday.com",
+  "recipient": "https://www.myworkday.com//login-saml.htmld",
+  "mappings": {
+  },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "signResponse":         true,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+  ],
+  "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:X509",
+}
+```
+
+The **Callback URL** is `https://impl.workday.com//login-saml.htmld`. You may want to change the subdomain `impl` depending on the Workday data center you are using.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/workpath.md b/ja-jp/articles/protocols/saml/saml-apps/workpath.md
new file mode 100644
index 0000000000..60e2f170b2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/workpath.md
@@ -0,0 +1,23 @@
+---
+title: Workpath SAML Configuration
+description: Workpath SAML Configuration
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://api.workpath.com/v1/saml/metadata/{YOUR-WORKPATH-SUBDOMAIN}",
+  "mappings": {
+    "email": "email",
+    "given_name": "first_name",
+    "family_name": "last_name"
+  }
+}
+```
+
+The **Callback URL** is `https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}`.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md
new file mode 100644
index 0000000000..999e7a133b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md
@@ -0,0 +1,30 @@
+---
+description: How to configure Auth0 for use as a SAML service AND identity provider
+topics:
+    - saml  
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as a Service and Identity Provider
+
+::: note
+Auth0 provides a non-exhaustive [list of SAML-compliant providers](/samlp-providers).
+:::
+
+::: warning
+Auth0 only supports:
+* Using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**.
+* Using Auth0 as the identity provider in SAML configurations with **SAML 2.0**.
+:::
+
+When using Auth0 as both the SAML Service and Identity Provider, you need to configure **two** federations:
+
+* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider)
+* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider).
+
+## Using Two Auth0 Tenants
+
+The section above assumes that you're using the same Auth0 tenant as the service provider *and* the identity provider. However, you can also implement a [SAML scenario using **two** Auth0 tenants](/samlsso-auth0-to-auth0) (usually for testing purposes), where one tenant acts as the identity provider and the other acts as the service provider.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md
new file mode 100644
index 0000000000..56178f72e1
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md
@@ -0,0 +1,72 @@
+---
+description: How to configure Auth0 for use as a SAML identity provider
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as an Identity Provider
+
+::: warning
+Auth0 only supports using Auth0 as the identity provider in SAML configurations with **SAML 2.0**.
+:::
+
+Depending on the type of application you're working with, configuring Auth0 to serve as the SAML Identity Provider (IdP) is done in several places.
+
+## Single Sign-on Integrations with Built-in Auth0 Support
+
+For some Single Sign-on (SSO) Integrations that support SAML, the configuring Auth0 is done using the [**SSO Integrations** area of the Management Dashboard](${manage_url}/#/externalapps). To create a new integration, click **Create SSO Integration**.
+
+![](/media/articles/protocols/saml/saml-configuration/sso-integrations.png)
+
+ On the *New Single Sign-On Integration* page, select the integration in which you're interested. Currently, your options are as follows:
+
+* Active Directory
+* Box
+* CloudBees
+* Concur
+* Dropbox
+* Microsoft Dynamics CRM
+* Adobe EchoSign
+* Egnyte
+* New Relic
+* Office 365
+* Salesforce
+* SharePoint
+* Slack
+* SpringCM
+* Zendesk
+* Zoom
+
+![](/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png)
+
+Provide a name for your new integration. Click **Create** to proceed.
+
+You will now see additional configuration instructions that are specific to the integration that you have chosen.
+
+![](/media/articles/protocols/saml/saml-configuration/name-sso-integration.png)
+
+You can also refer to [Using Auth0 in SAML2 Web Apps](/saml2webapp-tutorial) for instructions specific to configuring a given SSO Integration.
+
+## Manually Configure a SSO Integration
+
+If the Service Provider option you've chosen doesn't come with built-in Auth0 support, you can [manually add the configuration](/saml-idp-generic).
+
+Navigate to the [Applications section of the Management Dashboard](${manage_url}/#/applications), find the Application you're working with, and click on **Settings**.
+
+![](/media/articles/protocols/saml/saml-configuration/applications.png)
+
+Switch over to the **Addons** tab.
+
+![](/media/articles/protocols/saml/saml-configuration/add-ons.png)
+
+Enable **SAML2 Web App**. You will see a screen asking you to provide additional configuration information, with details on what the fields mean and what the expected value types are located directly on that page.
+
+![](/media/articles/protocols/saml/saml-configuration/configure-app.png)
+
+In addition, [SAML Settings Needed for Some SSO Integrations](/saml-apps) provide additional information for integrations that require special settings.
+
+When done, click **Save**.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md
new file mode 100644
index 0000000000..7ed558c5f6
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md
@@ -0,0 +1,34 @@
+---
+description: How to configure Auth0 for use as a SAML service provider
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as a Service Provider
+
+::: warning
+Auth0 only supports using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**.
+:::
+
+This video provides an overview of how to configure Auth0 for use as a SAML service provider.
+
+
+
+
+When Auth0 serves as the SAML service provider, you need to use an Auth0 Connection to configure the service provider side of each SAML federation.
+
+Finally, you'll configure the Identity Provider (IdP) portion of your SAML setup. We have docs for the following providers:
+
+* [ADFS](/adfs)
+* [Okta](/okta)
+* [OneLogin](/onelogin)
+* [Ping7](/ping7)
+* [Salesforce](/saml/identity-providers/salesforce)
+* [SiteMinder](/siteminder)
+* [SSOCircle](/ssocircle)
+
+If you are using any other SAML-compliant IdP with Auth0 as the Service Provider, you can use the [Generic Service Provider Configuration Instructions](/saml-sp-generic).
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md b/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md
new file mode 100644
index 0000000000..08d1523ec3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md
@@ -0,0 +1,18 @@
+---
+description: Best practices on deprovision users of your SAML integration
+topics:
+  - saml
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-idp
+---
+
+# Deprovision Users
+
+If you ever need to remove application access for users, you'll need to *deprovision* them, at minimum, with the identity provider. Depending on the identity provider you're using, the steps required to deprovision a user account varies; check with your provider for further instructions.
+
+Once a user's account is removed or disabled with the identity provider, the user will not be able to log in.
+
+You may also want to remove the Auth0 user accounts for those who've been deprovisioned if Auth0 is the service provider or if your app integrates with Auth0. Regardless of whether Auth0 is the identity or service provider, you can remove users using the Management [Dashboard](${manage_url}/#/users) or [API](/api/management/v2#!/Users/delete_users_by_id).
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md b/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md
new file mode 100644
index 0000000000..68ac4fbf90
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md
@@ -0,0 +1,46 @@
+---
+description: Things to consider when designing your SAML integration
+topics:
+  - saml
+contentType:
+  - concept
+useCase:
+  - add-idp
+---
+
+# SAML Design Considerations
+
+Regardless of how you implement SAML Single Sign-on (SSO), it's important to consider:
+
+* Which system(s) will serve as the authoritative source for user profile information if there's ever a conflict between two or more sources;
+* What user profile attributes each application needs;
+* How user profile information will be distributed to the systems that need it.
+
+## Considerations for Using Auth0 as Service Provider
+
+* If Auth0 serves as the Service Provider in a SAML federation, Auth0 can [route authentication requests to an Identity Provider](/hrd) without already having an account pre-created for a specific user. Using the assertion returned by the identity provider, Auth0 can capture information needed to create a user profile for the user (this process is sometimes called just-in-time provisioning).
+
+* Even though Auth0 doesn't require pre-created user accounts prior to the authentication process, the application integrated with Auth0 might. If this is the case, you have several options when it comes to handling this:
+
+  * After the identity provider creates the user, you can use an out-of-band process can create the accompanying user in the application (or Auth0) and add any user profile attributes required by the application. If, after authentication, any attributes are missing in the profile, the application can obtain them from the appropriate source and store them in the Auth0 user profile. The additional attributes are then sent to the application (in addition to any added by the identity provider) the next time the user logs in.
+
+  * You can use an Auth0 [rule](/rules) to call an API to retrieve any missing information and dynamically add it to the Auth0 profile (which is then returned to the application). Rules execute after successful authentication, and your application can retrieve profile attributes each time *or* you can save the attributes to the Auth0 profile.
+
+  * Auth0 can pass the basic profile information from the identity provider to the application, which then retrieves any missing information from another source. With the two sets of information, the application creates a local user profile.
+
+* You can specify email domains as part of the Auth0 SAMLP Connection configuration to control the IDP that handles a select group of users. For example, if you add email domain `example.com` to the Auth0 SAMLP Connection configuration for Company X, all users with emails with the `example.com` domain get handled by the specific IDP for Company X.
+
+## Considerations for Using Auth0 as Identity Provider
+
+If Auth0 is serving as the Identity Provider in a SAML federation, user accounts may be created multiple ways:
+
+* Using a back-end authentication system, such as an LDAP directory, a database, or another SAML identity provider;
+* Using the [Auth0 Management Dashboard](${manage_url}/#/users);
+* Calling the [Auth0 Management API](/api/management/v2#!/Users/post_users);
+* Implementing self-service user signup.
+
+If your application is written to retrieve user profile information from a local store, you'll need to create the local profile after the accounts have been created in Auth0. Some of the ways you might do this include:
+
+ * An out-of-band process creating user profiles in the application;
+ * An Auth0 [rule](/rules) that executes on first login that calls an application API to create the user profile in the application;
+ * Modifying the application to create user profiles dynamically, based on information in the SAML assertion.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/index.md b/ja-jp/articles/protocols/saml/saml-configuration/index.md
new file mode 100644
index 0000000000..0c6ff2b5b3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/index.md
@@ -0,0 +1,57 @@
+---
+description: An overview of the SAML configuration process
+topics:
+  - saml
+  - saml-configuration
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+# SAML Configuration
+
+SAML-based federation involves two parties:
+
+1. An **identity provider** (IdP): authenticates users and provides to Service Providers an Authentication Assertion if successful;
+2. A **service provider** (SP): relies on the Identity Provider to authenticate users.
+
+Auth0 supports the SAML protocol and can serve as the identity provider, the service provider, or both.
+
+## SAML Identity Providers
+
+Some applications (such as Salesforce, Box, and Workday) allow users to authenticate against an external IdP using the SAML protocol. You can then integrate the application with Auth0, which serves as the application's SAML IdP.
+
+Application users will be redirected to Auth0 to log in, and Auth0 can authenticate them using any backend authentication connection, such as an LDAP directory, a database, or another SAML IdP or Social Provider.
+
+Once the user is authenticated, Auth0 returns a SAML assertion to the application that indicates such.
+
+![](/media/articles/saml/saml-configuration/saml-case2.png)
+
+## SAML Service Providers
+
+Applications, especially custom ones, can authenticate users against an external IdP using protocols such as OpenID Connect (OIDC) or OAuth 2.0. However, you might want to leverage an enterprise SAML provider for authentication, even if you wrote your application to utilize either protocol.
+
+![](/media/articles/saml/saml-configuration/saml-case1.png)
+
+## Auth0 as the SAML Service and Identity Providers
+
+You may opt to use Auth0 as both the SAML Service Provider **and** SAML Identity Provider.
+
+![](/media/articles/saml/saml-configuration/saml-case3.png)
+
+## Configuration
+
+The following documentation cover the different aspects of SAML configuration:
+
+* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider)
+* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider)
+* [Configure Auth0 as Both Service and Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider)
+* [SAML Design Considerations](/protocols/saml/saml-configuration/design-considerations)
+* [Supported SAML Options and Bindings](/protocols/saml/saml-configuration/supported-options-and-bindings)
+* [Special Configuration Scenarios](/protocols/saml/saml-configuration/special-configuration-scenarios)
+* [Customize SAML Assertions](/protocols/saml/saml-configuration/saml-assertions)
+* [Select Between Multiple Identity Providers](/hrd)
+* [Logout](/protocols/saml/saml-configuration/logout)
+* [Deprovision Users](/protocols/saml/saml-configuration/deprovision-users)
+* [Troubleshoot](/protocols/saml/saml-configuration/troubleshoot)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/logout.md b/ja-jp/articles/protocols/saml/saml-configuration/logout.md
new file mode 100644
index 0000000000..efc2414f46
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/logout.md
@@ -0,0 +1,76 @@
+---
+description: Learn how to log users out of Auth0 as the SAML identity provider.
+topics:
+  - saml
+  - logout
+  - session-termination
+contentType:
+  - how-to
+useCase:
+  - add-idp
+  - manage-logout
+  - user-management
+---
+# Log Users Out of Auth0 as the SAML Identity Provider
+
+When integrating with a SAML identity provider, there are many ways to implement logout or *user session termination*.
+
+SAML logout is configured differently depending on whether Auth0 acts as the service provider (when you create a SAML **connection**) the identity provider (when you have an application with the SAML2 Web App addon) or both.
+
+## Logout scenarios
+
+When Auth0 is acting as a [SAML Identity Provider](/protocols/saml/saml-idp-generic), you can have the following two scenarios:
+
+* Single logout
+* Non-single logout
+
+### SAML Single Logout (SLO) Scenario
+
+After determining that your service provider supports SAML SLO, configure the service provider to call `https://${account.namespace}/samlp/CLIENT_ID/logout` (also listed in the SAML IdP metadata). 
+
+When a logout request is triggered by the service provider, a SAML logout request is sent to this endpoint. Auth0 starts the SAML SLO flow by notifying the existing session participants using a frontend channel.
+
+1. Log into the [Management Dashboard](${manage_url})
+
+2. Navigate to your [Application's Addons page](${manage_url}/#/applications/${account.clientId}/addons).
+
+3. Click to open the **SAML2 Web App** addon.
+
+4. In the **Settings** editor, uncomment the `logout` portion and update it with your callback URL:
+
+  ```json
+  "logout": {
+    "callback": "CALLBACK_URL"
+  }
+  ```
+
+   To prevent a session participant from being notified, you can set `logout.slo_enabled` to `false` in the `SAML2 Web App` application addon's settings. 
+
+5. Click **Save**.
+
+For SAML-compliant endpoints, Auth0 uses this URL to send SAML logout requests or logout responses (the exact choice depends on whether the service provider initiated the session or not). If you don't want to notify the service provider about a session termination, you can set the `slo_enabled` key inside logout to `false`:
+
+```json
+"logout": {
+  "callback": "CALLBACK_URL",
+  "slo_enabled": false
+}
+```
+
+By default, SAML logout responses are sent using the **HTTP-POST** protocol binding. If you want to use **HTTP-Redirect** you can configure the `binding` key to `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`:
+
+```json
+"logout": {
+  "callback": "CALLBACK_URL"
+},
+"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
+```
+
+### Non-Single Logout Scenario
+
+If your service provider does not support SAML SLO, but provides a redirect URL where the user will be redirected to after logging out of the service provider, configure the redirect URL to `https://${account.namespace}/v2/logout`. This won't notify other session participants that a logout was initiated, but it will remove the session from Auth0.
+
+## Keep reading
+
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Logout](/logout)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md b/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md
new file mode 100644
index 0000000000..797c742986
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md
@@ -0,0 +1,117 @@
+---
+description: How to customize SAML assertions
+topics:
+  - saml
+  - saml-assertions
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Customize SAML Assertions
+
+You can customize your SAML assertions, as well as the SAML and WS-Fed protocol parameters.
+
+## Auth0 as the Identity Provider
+
+To customize your SAML assertions when Auth0 acts as the identity provider, you can do so by configuring the addon itself or using [rules](/rules).
+
+### Use the Application Addon
+
+To customize your SAML assertion using the application add-on, navigate to [Applications > Settings > Addons](${manage_url}/#/applications/${account.clientId}/addons). Click on **SAML2 Web App** to launch the *Settings* tab that allows you to make several types of customizations including:
+
+* Specifying an audience other than the default issuer of the SAML request;
+* Specifying a recipient;
+* Mapping profile attributes to specific attribute statements;
+* Changing the signature or digest algorithm;
+* Specifying whether just the assertion or the entire response should be signed.
+
+### Use Rules
+
+You can use rules to add more extensive or dynamic customizations to the SAML response.
+
+Customizations done in Rules override customizations done using the Application Addons tab.
+
+::: note
+The `context.samlConfiguration.mappings` object is used to override default SAML attributes or add new attributes. The object keys are the name of the SAML attribute to override or add and the values are a string of the `user` object property to use as the attribute value.
+:::
+
+#### Example: Changing the SAML Token Lifetime and Using UPN as NameID
+
+```js
+function (user, context, callback) {
+  // change SAML token lifetime to 10 hours
+  context.samlConfiguration.lifetimeInSeconds = 36000;
+
+  // if available, use upn as NameID
+  if (user.upn) {
+    context.samlConfiguration.mappings = {
+      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "upn" // use user.upn as the value
+    }
+  }
+
+  callback(null, user, context);
+}
+```
+
+#### Example: Include `user_metadata` Attributes in an Assertion
+
+```js
+function (user, context, callback) {
+  user.user_metadata = user.user_metadata || {};
+  user.user_metadata.color = "purple";
+  context.samlConfiguration.mappings = {
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "user_metadata.color", // use user.user_metadata.color as the value
+  };
+  callback(null, user, context);
+}
+```
+
+## Configuration Options
+
+The following is a list of customization options for your SAML assertions.
+
+* **audience** (string): The audience of the SAML Assertion. Default will be the Issuer on SAMLRequest.
+
+* **recipient** (string): The recipient of the SAML Assertion (SubjectConfirmationData). Default is `AssertionConsumerUrl` on SAMLRequest or Callback URL if no SAMLRequest was sent.
+
+* **mappings** (Object): The mappings between Auth0 profile and the output attributes on the SAML Assertion. Default mapping is shown above.
+
+* **createUpnClaim** (bool): Whether or not a UPN claim should be created. Default is true.
+
+* **passthroughClaimsWithNoMapping** (bool): If true (default), for each claim that is not mapped to the common profile, Auth0 will passthrough those in the output assertion. If false, those claims won't be mapped. Default is true.
+
+* **mapUnknownClaimsAsIs** (bool): if `passthroughClaimsWithNoMapping` is true and this is false (default), for each claim that is not mapped to the common profile Auth0 will add a prefix `http://schema.auth0.com`. If true it will passthrough the claim as-is. Default is false.
+
+* **mapIdentities**: If true, it will will add more information in the token like the provider used (google, adfs, ad, and so on) and the Access Token if available. Default is true.
+
+* **signatureAlgorithm**: Signature algorithm to sign the SAML Assertion or response. Default is `rsa-sha1` and it could be `rsa-sha256`.
+
+* **digestAlgorithm**: Digest algorithm to calculate digest of the SAML Assertion or response. Default is `sha1` and it could be `sha256`.
+
+* **destination**: Destination of the SAML Response. If not specified, it will be `AssertionConsumerUrl` of SAMLRequest or Callback URL if there was no SAMLRequest.
+
+* **lifetimeInSeconds** (int): Expiration of the token. Default is `3600` seconds (1 hour).
+
+* **signResponse** (bool): Whether or not the SAML Response should be signed. By default the SAML Assertion will be signed, but not the SAML Response. If true, SAML Response will be signed instead of SAML Assertion.
+
+* **nameIdentifierFormat** (string): Default is `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`.
+
+* **nameIdentifierProbes** (Array): Auth0 will try each of the attributes of this array in order. If one of them has a value, it will use that for the Subject/NameID. The order is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (mapped from user_id), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress (mapped from email), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name (mapped from name).
+
+* **authnContextClassRef** (string): Default is `urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified`.
+
+* **typedAttributes** (bool): Default is `true`. When set to true, we infer the xs:type of the element. Types are `xs:string`, `xs:boolean`, `xs:double `and `xs:anyType`. When set to false all `xs:type` are `xs:anyType`
+
+* **includeAttributeNameFormat** (bool): Default is `true`. When set to `true`, we infer the NameFormat based on the attribute name. NameFormat values are `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`, `urn:oasis:names:tc:SAML:2.0:attrname-format:basic` and `urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified`. If set to `false`, the attribute NameFormat is not set in the assertion.
+
+* **logout** (object): An object that controls SAML logout. It can contain two properties:`callback` (of type `string`), that contains the service provider (client application)'s **Single Logout Service URL**, where Auth0 will send logout requests and responses, and `slo_enabled`(boolean) that controls whether Auth0 should notify service providers of session termination. The default value is`true` (notify service providers).
+
+* **binding** (string): Optionally indicates the protocol binding used for SAML logout responses. By default Auth0 uses `HTTP-POST`, but you can switch to `HTTP-Redirect` by setting `"binding"` to `"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"`.
+
+* **signingCert** (string): Optionally indicates the public key certificate used to validate SAML requests. If set, SAML requests will be required to be signed. A sample value would be
+
+  ```
+  "-----BEGIN PUBLIC KEY-----\nMIGf...bpP/t3\n+JGNGIRMj1hF1rnb6QIDAQAB\n-----END PUBLIC KEY-----\n"
+  ```
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md
new file mode 100644
index 0000000000..09ec481adf
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md
@@ -0,0 +1,66 @@
+---
+  description: Learn to set up IdP-initiated Single Sign-on (SSO)
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Special Configuration Scenarios: IdP-Initiated Single Sign-On
+
+Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider:
+
+1. The service provider returns a browser redirect so that the user authenticates using the identity provider.
+2. After authentication, the browser redirects the user back to the Service Provider with a SAML assertion containing information about the authentication status.
+
+This is commonly used for consumer-facing scenarios.
+
+## Alternative to Service Provider-Initiated SSO
+
+You might choose to begin with the identity provider initiating SSO instead of the service provider. The user:
+
+1. Invokes a URL on the identity provider;
+2. Is prompted to authenticate
+3. Is redirected to the service provider with a SAML assertion
+
+This is commonly used in enterprise scenarios.
+
+For example, an organization might set up a portal to ensure that users navigate to the correct application:
+
+1. The user navigates to the portal's URL;
+2. The user is redirected to the IdP, which authenticates the user;
+3. If successfully authenticated, the user clicks on the appropriate link;
+4. The user is redirected to the service provider with a SAML assertion.
+
+## Risks of Using an IdP-Initiated SSO Flow
+
+In general, it is recommended to use Service-Provided flows whenever available. When an application actively requests an authentication as a first step (as is the case for SP-Initiated flows), it can check that the authentication response matches the original request. 
+In IdP-initiated scenarios, on the other hand, the application can not verify that the user actually started the flow. Because of this, the IdP-Initiated flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/customer/portal/articles/1969819-login-csrf), where an attacker can trick a legitimate user into using a session created by the attacker. 
+
+Login CSRF attacks are generally less of a concern in enterprise-only scenarios, as any would-be attacker would have to come from the same directory of users. But it's definitely a security concern in consumer-facing applications, so we strongly advise against enabling IdP-Inititated flows on SAML connections.
+
+## Auth0 as Service Provider Where IdP Initiates SSO
+
+For information on how to configure IdP-Initiated flows when Auth0 is the Service Provider see [How to setup IdP-Initiated SSO in a SAML connection](/protocols/saml/idp-initiated-sso).
+
+## Auth0 as Identity Provider Where IdP Initiates SSO
+
+If Auth0 acts as the identity provider, you can use the application's SAML Sign In URL endpoint directly (without a SAML request):
+
+* Invoke the IdP-initiated login using the following URL:
+
+  ```text
+  https://${account.namespace}/samlp/${account.clientId}
+  ```
+
+* Append the `RelayState` parameter to the URL to which the service provider redirects the user after processing the SAML response. For example, the following URL is where the service provider redirects the URL after its processed the SAML response from Auth0:
+
+  ```text
+  https://${account.namespace}/samlp
+  /${account.clientId}?RelayState=https://FINAL_DESTINATION_URL
+  ```
+
+Note: it's up to the target application to accept IdP-Initiated flows and use the `RelayState` in a meaningful way if provided.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md
new file mode 100644
index 0000000000..d27d7e9011
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md
@@ -0,0 +1,24 @@
+---
+description: Special configuration scenarios when setting up a SAML Integration
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Special Configuration Scenarios
+
+Once you've set up a basic SAML Integration, there are a number of additional requirements you might need to implement so that your integration reflects your needs and requirements.
+
+## Prerequisites
+
+This article assumes that you've already set up a [Connection](/protocols/saml/saml-configuration/auth0-as-service-provider) or an [Application](/protocols/saml/saml-configuration/auth0-as-identity-provider).
+
+The instructions below assume that you're altering specific settings for an existing SAML integration, not configuring an integration from scratch.
+
+## Scenarios
+
+* [IdP-Initiated SSO](/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso)
+* [Signing and Encrypting SAML Requests](/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md
new file mode 100644
index 0000000000..dc76d7a160
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md
@@ -0,0 +1,255 @@
+---
+description: Signing and encrypting SAML requests
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Special Configuration Scenarios: Signing and Encrypting SAML Requests
+
+To increase the security of your transactions, you can sign or encrypt both your requests and your responses in the SAML protocol. In this article you'll find configurations for specific scenarios, separated under two use cases:
+
+- Auth0 as the SAML **service provider** (i.e. a SAML **Connection**)
+- Auth0 as the SAML **identity provider** (i.e. an **Application** configured with the **SAML Web App Addon**)
+
+## Auth0 as the SAML Service Provider
+
+These scenarios apply when Auth0 is the SAML Service Provider, i.e. Auth0 connects to a SAML identity provider by creating a SAML connection.
+
+### Sign the SAML Authentication Request
+
+If Auth0 is the SAML **service provider**, you can sign the authentication request Auth0 sends to the IdP as follows:
+
+1. For the Connection in which you're interested, navigate to **Enterprise** -> **SAMLP Identity Provider** -> **Settings**.
+2. Enable the **Sign Request** toggle.
+3. Download the certificate beneath the **Sign Request** toggle and provide it to the IdP so that it can validate the signature.
+
+#### Enable/Disable Deflate Encoding
+
+By default, SAML authentication requests are sent via HTTP-Redirect and use deflate encoding, which puts the signature in a query parameter.
+
+To turn off deflate encoding, you can make a [PATCH call to the Management API's Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) and set the `deflate` option to `false`.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload: 
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "deflate": false
+	}
+}
+```
+
+### Use a custom certificate to sign requests
+
+By default, Auth0 uses the tenant private key to sign SAML requests (when the **Sign Request** toggle is enabled). You can also provide your own private/public key pair to sign requests coming from a specific connection.
+
+You can generate your own certificate and private key using this command:
+
+```shell
+openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crt
+```
+
+Changing the key used to sign requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `signing_key` property to the `options` object, as shown in the payload example below.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload:
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "signing_key": {
+				"key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----",
+				"cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----"
+			}
+	}
+}
+```
+
+See [Working with private and public keys as strings](#working-with-certificates-as-strings) for details on how to get the private key and certificate formatted as a JSON string to use in the payload.
+
+### Receive Signed SAML Authentication Responses
+
+If Auth0 is the SAML **service provider**, all SAML responses from your identity provider should be signed to indicate it hasn't been tampered with by an unauthorized third-party.
+
+You will need to configure Auth0 to validate the responses' signatures by:
+
+* Obtaining a signing certificate from the IdP
+* Loading the certificate from the IdP into your Auth0 Connection (in the Management Dashboard, go to the **Upload Certificate** section for your Connection by navigating to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** -> **Settings**)
+
+Auth0 can accept a signed response for the assertion, the response, or both.
+
+### Receive Encrypted SAML Authentication Assertions
+
+If Auth0 is the SAML **service provider**, it may need to receive encrypted assertions from an identity provider. To do this, you must provide tenant's public key certificate to the IdP. The IdP encrypts the SAML assertion using the public key and sends it to Auth0, which decrypts it using the tenant's private key.
+
+To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}), go to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** and click on the **Setup Instructions** button next to the connection.
+
+Navigate to the section titled **Encrypted Assertions** and download the certificate in the format requested by the IdP.
+
+### Use your own key pair to decrypt encrypted responses
+
+As noted above, Auth0 will by default use your tenant's private/public key pair to handle encryption. You can also provide your own public/private key pair if an advanced scenario requires so.
+
+Changing the key pair used to encrypt and decrypt requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `decryptionKey` property to the `options` object, as shown in the payload example below.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload:
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "decryptionKey": {
+				"key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----",
+				"cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----"
+			}
+	}
+}
+```
+
+The SAML metadata available for the connection will be updated with the provided certificate, so that the identity provider can pick it up to sign the SAML response. 
+
+## Auth0 as the SAML Identity Provider
+
+This scenarios apply when Auth0 is the SAML Identity Provider for an application. This is represented in the dashboard by an **Application** that has the SAML Web App Addon enabled.
+
+### Sign the SAML Responses/Assertions
+
+If Auth0 is the SAML **identity provider**, it will sign SAML assertions with the tenant's private key and provide the service provider with the public key/certificate necessary to validate the signature.
+
+To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}):
+
+1. Go to **Applications** -> **Settings** -> **Show Advanced Settings**.
+2. Scroll to the *Certificates* section, and click **Download Certificate* to obtain the signing certificate you need to provide to your IdP.
+3. Send your certificate to the service provider.
+
+By default, Auth0 signs the SAML **assertion** within the response. If you want to sign the SAML **response** instead, follow this instructions:
+
+1. In the [Management Dashboard](${manage_url}), navigate to **Applications**. Find the Application you're interested in go to **Addons** > SAML2 WEB APP > Settings.
+2. Look for the `"signResponse"` key. Add it or uncommented if required, and set its value to `true` (the default value is `false`). The configuration should look like this:
+
+```json
+{
+  [...], // other settings
+  "signResponse": true
+}
+```
+
+#### Change the signing key for SAML responses
+
+Auth0 will by default use the private/public key pair assigned to your tenant to sign SAML responses or assertions. For very specific scenarios you might wish to provide your own key pair. You can do so with a rule like this:
+
+```javascript
+function (user, context, callback) {
+  // replace with the ID of the application that has the SAML Web App Addon enabled
+	// for which you want to change the signing key pair.
+	var samlIdpClientId = 'YOUR_SAML_APP_CLIENT_ID';
+  // only for a specific client
+  if (context.clientID !== samlIdpClientId) {
+    return callback(null, user, context);
+  }
+
+	// provide your own private key and certificate here  
+  context.samlConfiguration.cert = "-----BEGIN CERTIFICATE-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END CERTIFICATE-----\n";
+  context.samlConfiguration.key = "-----BEGIN PRIVATE KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END PRIVATE KEY-----\n";
+      
+  callback(null, user, context);
+}
+```
+
+Take a look at [Working with certificates as strings](#working-with-certificates-as-strings) for information on how to turn the private key and certificate files into strings that you can use in a rule.
+
+### Receive Signed SAML Authentication Requests
+
+If Auth0 is the SAML **identity provider**, it can received requests signed with the service provider's private key. Auth0 will then use the service providers' public key/certificate to validate the signature.
+
+To configure signature validation, you'll need to download the service provider's certificate with the public key and store the value in the `signingCert` key of the SAML Web App Addon `options` JSON object. You can find the `options` JSON object field in the [Management Dashboard](${manage_url}) by going to **Applications** > **Addons** > **SAML2 WEB APP** > **Settings**.
+
+The configuration should look like this:
+
+```json
+{
+  [...], // other settings
+  "signingCert": "-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n"
+}
+```
+
+### Send Encrypted SAML Authentication Assertions
+
+If Auth0 is the SAML **identity provider**, you can use [Rules](/rules) to encrypt the SAML assertions it sends.
+
+You'll need to obtain the certificate and the public key from the service provider. If you only got the certificate, you can derive the public key using `openssl`. Assuming that the certificate file is named `certificate.pem` you can do:
+
+```shell
+openssl x509 -in certificate.pem -pubkey -noout > public_key.pem
+```
+
+Once you get the certificate and public key files, you'll need to [turn them into strings](#working-with-certificates-as-strings) to use them in a rule. The rule will look like this:
+
+```js
+function (user, context, callback) {
+  // this rule sets a specific public key to encrypt the SAML assertion generated from Auth0 
+  if (context.clientID === 'THE_CLIENT_ID_OF_THE_APP_WITH_THE_SAML_APP_ADDON') {
+	  context.samlConfiguration = (context.samlConfiguration || {});
+    context.samlConfiguration.encryptionPublicKey = "-----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PUBLIC KEY-----\n";
+    context.samlConfiguration.encryptionCert = "-----BEGIN CERTIFICATE-----\nnnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n";
+	}
+  callback(null, user, context);
+}
+```
+
+The following algorithms are used:
+
+* AES256 (`http://www.w3.org/2001/04/xmlenc#aes256-cbc`) for assertion encryption
+* RSA-OAEP (including MGF1 with SHA1, `http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p`) for key transport
+
+## Working with certificates as strings
+
+When working with certificates or keys in rules or Management API v2 requests, you will most likely require a string representation of the file.
+
+If you open a certificate file (`cer`, `pem`) with a text editor, you'll see something like this:
+
+```
+-----BEGIN CERTIFICATE-----
+MIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh
+cjEZMBcGA1UEAwwQaHR0cHM6Ly9uaWNvLmNvbTAeFw0xOTA0MDgxODA3NTVaFw0y
+//
+// more lines of base64-encoded information
+//
+nSWyabd+LiBGtLTMB+ZLbOIi3EioWPGw/nHOI8jzPrqhiCLuZCSQmiqrLQYNsc1W
+-----END CERTIFICATE-----
+```
+
+The lines between the `-----BEGIN CERTIFICATE-----` header and `-----END CERTIFICATE-----` footer contain base64-encoded binary information. Public keys and private keys (`.key` files) will look similar, with just a different header/footer.
+
+For a string representation of a certificate/key file, you will need to concatenate everything in one line, with a `\n` (escaped new-line) sequence replacing the actual new lines in the file. So from the above sample you'd obtain something like this:
+
+```
+"-----BEGIN CERTIFICATE-----\nMIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh\n[..all the other lines..]-----END CERTIFICATE-----\n"
+```
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md b/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md
new file mode 100644
index 0000000000..64d9449197
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md
@@ -0,0 +1,24 @@
+---
+description: Supported SAML bindings and options
+topics:
+  - saml
+  - saml-bindings
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+
+# Supported SAML Bindings and Options
+
+Auth0 supports the following SAML bindings:
+
+* HTTP Redirect
+* HTTP POST
+
+Auth0 supports the following SAML options:
+
+* Web Browser SSO Profile
+* Single Logout Profile
+* Name Identifier Management Profile
+* Name Identifier Mapping Profile
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md
new file mode 100644
index 0000000000..39fa5e5c5b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md
@@ -0,0 +1,140 @@
+---
+description: How to troubleshoot SAML-related configuration issues when Auth0 is the identity provider
+toc: true
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Troubleshooting SAML when Auth0 is the Identity Provider
+
+When troubleshooting a SAML login, there are four primary stages to check:
+
+* Stage 1: The user is successfully redirected to IDP and is able to login.
+* Stage 2: After login with the IDP, the user returns to Auth0 with a successful login event recorded.
+* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct.
+* Stage 4: The user successfully redirects back to application and is able to access application.
+
+The following sections describe how to check each stage and how to identify if there are any issues with a given stage.
+
+## A successful login event does not show up in Auth0 logs
+
+In this case, the user successfully logs in with the idp, but a successful login event does *not* show up in auth0 logs.
+
+* If you're using an Auth0 Database Connection:
+
+  * Check that the user exists and the entered password is correct.
+
+  * Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process.
+
+  * If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process.
+
+* If you're using an Auth0 Database Connection **or** a remote SAML connection:
+
+  * Check that the SAML Connection works by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display).
+
+## The user's profile attributes are incorrect
+
+In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, but the user's profile attributes are incorrect.
+
+If the user:
+
+* Appears to log in successfully
+
+* The [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard should successful login events
+
+The next step is to check that the user's profile contains the necessary user profile attributes.
+
+### Checking the user profile
+
+1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider.
+
+If an attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0.
+
+## The user cannot access the application
+
+In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, and the user's profile attributes are correct, but the user cannot access the application.
+
+* Check to see if the user's Auth0 profile populated correctly:
+
+  1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+  2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+  3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider. Ensure that the profile includes all of the details required by the application.
+
+  If a user attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0.
+
+* Check the application's log files to see if there are any error messages indicating why the user is unable to access the application. The two most common causes for this issue are missing user profile information or incorrect/missing authorization information.
+
+* Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files). To analyze the HTTP trace:
+
+  1. View the trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+  2. Scan through the sequence of URLS invoked in the HTTP trace:
+
+    * The first few will be URLs for your application.
+
+    * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`).
+
+    * After one or more intervening URLS, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information. Be sure that the assertion includes this information:
+
+      1. Click on the row for the POST call in the HAR analyzer.
+
+      2. Switch to the POST Data tab, and look for the SAML response.
+
+      3. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+
+      4. Remove the SAML response at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+      5. Click **Decode SAML message** and check the following fields:
+
+        * **Destination**: the application URL that consumes the SAML assertion (and is also known as the Assertion Callback URL)
+
+        * **Status Field**: this field should indicate success: ``
+
+        * **Recipient**: the correct URL appears in the recipient field (indicated by th `urn:{DOMAIN}:{YOUR APPLICATION}`
+
+        * **Naming**: the attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address)
+
+        * **Signature Key**: check that the value indicated by the `X509Certificate` element matches the value provided to your connection
+
+        * **Certificate**: compare the certificate sent to the one that you provided to the application
+
+* Ensure that the SAML assertion contains any additional information required by the application and that the information is present in the attributes expected by the application.
+
+  * If you need to alter the assertion sent from Auth0 to your application, you can add or map attributes using [rules](/rules).
+
+    * Log into Auth0 and [navigate to Rules](${manage_url}/#/rules).
+
+    * Click **Create Rule** and, in the next page, choose the **Change your SAML configuration** template.
+
+    * In the rules editor, uncomment the lines you want to use. Lines 9-17 in the template can be used to map attributes as needed. You can also add lines to implement mappings.  The left side of each line specifies the identifier for the attribute in the assertion. The right side of each line references the Auth0 user profile attribute whose value will be used to populate the outgoing assertion sent to the application.
+
+    ```text
+    //context.samlConfiguration.mappings = {
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":      "user_id",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":        "email",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":                "name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname":           "given_name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname":             "family_name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":                 "upn",
+    //   "http://schemas.xmlsoap.org/claims/Group":                                   "groups"
+    // };
+    ```
+
+    ![](/media/articles/protocols/saml/saml-configuration/saml-rules.png)
+
+## When I try to logout I get the error: No active session(s) found matching LogoutRequest
+
+The `SessionIndex` and `NameID` values in the SAML Logout request need to match the ones received by the service provider in the original SAML assertion.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md
new file mode 100644
index 0000000000..b80302d710
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md
@@ -0,0 +1,212 @@
+---
+description: How to troubleshoot SAML-related configuration issues when Auth0 is the service provider
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Troubleshooting SAML when Auth0 is the Service Provider
+
+When troubleshooting a SAML login, there are four primary stages to check:
+
+* Stage 1: The user is successfully redirected to an identity provider (IdP) and is able to login.
+* Stage 2: After login with the IdP, the user returns to Auth0 with a successful login event recorded.
+* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct.
+* Stage 4: The user successfully redirects back to application and is able to access application.
+
+The following sections describe how to check each stage and how to identify if there are any issues with a given stage.
+
+## Issue: The IdP Login Page Doesn't Display
+
+### Test the Connection
+
+Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Try** (represented by the triangle icon) next to the Connection to test the interaction between Auth0 and the remote IdP.
+
+If the Connection does **not** work, continue with the steps detailed in this section. If it does, [proceed to the next section](#).
+
+  ![](/media/articles/protocols/saml/saml-configuration/test-connection.png)
+
+### Check the Connection's Settings
+
+Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Settings** (represented by the gear icon) to launch the tab associated with your Connection.
+
+  ![](/media/articles/protocols/saml/saml-configuration/check-connection-settings.png)
+
+Check and confirm the following with the IdP administrator:
+
+* That the Sign In URL is the correct Single Sign-on (SSO) URL. This is the URL that Auth0 will redirect the user to for authentication.
+* If the IdP expects HTTP-POST binding or HTTP-Redirect binding. You can switch the default binding in the __Settings__ tab.
+* If your authentication requests should be signed. If so, which signing algorithm does the IdP expect you to use? (Note that authentication requests are not commonly signed.) If you're sending signed requests, enable the Connection Settings **Sign Request** toggle and make sure the **Signing Algorithm** value matches what the IdP expects.
+* Ask the IdP administrator to check for log entries that might provide information on the problem.
+
+## Issue: Auth0 Logs Don't Show Successful Login Event
+
+In this case, the user successfully logs in with the identity provider, but the Auth0 logs do not show a successful login event. You can check the [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard to see if Auth0 shows a successful login event.
+
+If Auth0's logs don't show a successful login event, there is probably an issue with the SAML Authentication Assertion returned by the IdP or Auth0 is unable to consume the assertion.
+
+### Check the SAML Authentication Assertion
+
+Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace.
+
+#### Retrieve the Assertion
+
+You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. First, scan through the sequence of URLs invoked in the HTTP trace.
+    * The first few will be URLs for your application.
+    * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`).
+2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of Auth0, which consumes the assertion and extracts the needed information.
+3. Click on the row for the POST call in the HAR analyzer.
+4. Switch to the POST Data tab, and look for the SAML response.
+5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+#### Check the Assertion
+
+After retrieving and decoding the SAML message, check the following fields:
+
+Field | Description
+------|-------------
+Destination | Check that the destination for the SAML response is the correct Auth0 Tenant and Connection (`https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}`).
+Status Field | This field should indicate success. (``).
+Recipient | Check that the `urn:auth0:{TENANT}:{CONNECTION}`).
+Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address).
+Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection.
+Certificate | Compare the certificate sent to the one that you provided to the application
+
+## Issue: The User's Profile Attributes are Incorrect
+
+In this case the user successfully logs in with the IdP, the Auth0 logs show a successful login event, but the user's profile attributes are __not__ correct
+
+Check to see if the user's Auth0 profile populated correctly:
+
+  1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+  2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+  3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider.
+
+### If the User Profile Attribute is Missing
+
+If the attribute is missing, check to see if the attribute was included in the assertion. You can do this by [decoding the SAML assertion](#), or you can enable debugging for the connection.
+
+To enable debugging for the connection, navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and enable **Debug Mode**.
+
+![](/media/articles/protocols/saml/saml-configuration/debug-connection.png)
+
+With **Debug Mode** enabled, **Success Login** log entries [in the dashboard](${manage_url}/#/logs) will have an `original_profile` property listing every attribute included in the SAML assertion by the Identity Provider. You can use this list to see the information that the IdP is sending and to help you create the mappings. If the missing attribute is not in the assertion at all, please work with the IdP to make sure it is included.
+
+### If the User Profile Attribute is Incorrectly Mapped
+
+If an attribute value exists in the Auth0 user profile, but is not mapped to the right attribute, you can correct this via the Connection Mapping capability.
+
+You can do this by navigating to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and switching over to the **Mappings** tab.
+
+![](/media/articles/protocols/saml/saml-configuration/mappings.png)
+
+Within the provided editor, there is a JSON snippet you can edit to configure your mappings. The name on the left is the Auth0 user profile attribute to which the assertion value will be mapped. The value on the right is the identifier in the SAML assertion from which the attribute comes.
+
+::: warning
+When Auth0 incorporates unmapped SAML attributes into the user profile, attribute identifiers containing dots `.` are replaced with semicolons `:`. While configuring your mappings, ensure the identifiers you provide match those in the SAML assertion.
+:::
+
+## Issue: The User Cannot Access the Application
+
+In this case the user successfully logs in with the identity provider, Auth0 logs show a successful login event, and the user's profile attributes are correct; but the user __cannot__ access the application.
+
+### Check the Application Logs
+
+Check your application's log files to see if there are any error messages indicating why the user is unable to access the application.
+
+The two most common causes for this issue are:
+
+* Missing user profile information
+* Incorrect or missing authorization information.
+
+### Check the SAML Assertion
+
+Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace.
+
+#### Retrieve the Assertion
+
+You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. First, scan through the sequence of URLs invoked in the HTTP trace.
+    * The first few will be URLs for your application.
+    * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`).
+2. After one or more intervening URLs, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information.
+3. Click on the row for the POST call in the HAR analyzer.
+4. Switch to the POST Data tab, and look for the SAML response.
+5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+#### Check the Assertion
+
+After retrieving and decoding the SAML message, check the following fields:
+
+Field | Description
+------|-------------
+Destination | The application URL that consumes the SAML assertion, also known as the Assertion Callback URL.
+Status Field | This field should indicate success. (``).
+Recipient | Check that the correct URL appears in the recipient field (indicated by the `urn:auth0:{TENANT}:{CONNECTION}`).
+Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address).
+Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection.
+Certificate | Compare the certificate sent to the one that you provided to the application.
+
+### Check the ID Token
+
+If your authorization flow uses an OIDC-conformant protocol, you can [capture a HAR trace](/troubleshoot/guides/generate-har-files) and view it using [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. Scan through the sequence of URLs in the trace, and look for the following:
+
+    * The first few will be URLs for your application.
+
+    * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`).
+
+2. Further down is your application's callback URL. Make sure that it's correct.
+
+3. Retrieve the ID Token from this call, and paste it into [a JWT decoder](https://jwt.io/). Check that the claims in the token contain the information needed by the application.
+
+### Troubleshooting IdP-initiated Flows
+
+If you're using an IdP-initiated flow (for example, the user starts at the identity provider in a portal application), be sure that:
+
+* The  Assertion Consumer Service (ACS) URL at the identity provider includes the connection name (for example `https://${account.namespace}/login/callback?connection=CONNECTION_NAME`)
+
+* The IdP-initiated configuration tab for the Connection is properly filled in, including:
+
+  * The application to which the user should be sent;
+
+  * The protocol between the application and Auth0 (which is not necessarily **SAML** like the connection, and most likely is **OpenID Connect**);
+
+  * Any protocol-specific values to include in the query string, such as `scope`, `response_type`, `redirect_uri`, and `audience`. These values should match the ones expected by the application when using a SP-initiated flow.
+
+* Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process.
+
+* If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process.
+
+* Check that the SAML Connection works in an SP-Initiated flow by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display).
+
+## Error: The request could not be performed due to an error on the part of the SAML responder or SAML authority
+
+The error may appear as follows:
+
+```text
+
+
+
+```
+
+### How to Fix
+
+Make sure that the signature algorithm on your Auth0 connection is the same as the configuration on the ADFS side: either `rsa-sha256` or `rsa-sha1`. Alternatively you can contact your ADFS administrator to learn the expected signing method or to see if their logs contain further information about the reason for the error.
+
+![ADFS SAML Properties](/media/articles/protocols/saml-adfs/adfs-saml-properties.png)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md
new file mode 100644
index 0000000000..6f438059d8
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md
@@ -0,0 +1,102 @@
+---
+description: Common SAML errors and troubleshooting steps
+topics:
+  - saml
+  - sso
+  - errors
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Common SAML Errors
+
+This article covers SAML errors you might encounter when Auth0 acts as the service provider and the steps you should take to resolve them.
+
+## Error: The Connection was Disabled
+
+```json
+{
+  "error": "invalid_request",
+  "error_description": "the connection was disabled"
+}
+```
+
+This message indicates that the Application doesn't have an active Connection associated.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *Applications* tab.
+4. Enable at least one Application (if you don't see any in the list, you will need to [create an application](/applications) before proceeding).
+
+## Error: IdP-Initiated Default App Not Configured
+
+```json
+{
+  "invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter."
+}
+```
+
+This error typically occurs because the ACS URL configured in the IdP used the default Auth0 tenant domain, whereas the authentication transaction was started by calling the custom domain `/authorize` endpoint.
+
+The ACS URL should use the same domain as the initial authentication request. If using custom domains, this should use the custom domain callback URL.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the **IdP-Initiated** tab.
+4. Select the **Default Application** and the **Response Protocol** used by that Application, and (optionally) specify any additional parameters you want passed to the Application.
+
+::: panel SP-Initiated Login
+If you see this error when using a SP-initiated flow, one of the following is missing or empty:
+
+* The `RelayState` parameter
+* The `InResponseTo` attribute in the SAML response
+
+If these are missing or empty, Auth0 treats the login as IdP-initiated. You can fix this error by checking your configuration to ensure that both fields are populated and returned appropriately.
+:::
+
+## Error: Missing RelayState
+
+This error occurs when the identity provider doesn't return the `RelayState` parameter along with its response.
+
+### How to Fix
+
+Work with the identity provider to ensure that it returns the `RelayState` parameter.
+
+## Error: Audience is Invalid
+
+This error occurs if the value of the `audience` element from the identity provider's SAML response doesn't match the value expected by Auth0. Auth0 expects the value to be the Entity ID for the Connection.
+
+**Find Your Connection's Entity ID**
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). Find your Connection, and click on **Setup Instructions**.
+2. Under the *Common Settings* section, your **Entity ID** is the second parameter provided.
+
+### How to Fix
+
+Make sure that the identity provider sends the correct `audience` value in the SAML response.
+
+## Error: Specifying the Incorrect Protocol
+
+One common error is specifying the incorrect response protocol on the IdP-Initiated tab. The response protocol is the one used between Auth0 and the Application (not the remote identity provider). For example, if you set this value to **SAML** when your Application expects **OpenID Connect** or **WS-Fed** results in errors due to the incorrect configuration.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Check the value you have set in the **Response Protocol** field.
+
+## Issue: User isn't logged out from the IdP
+
+When ADFS is configured as SAML IdP, if the ADFS is relaying party trust `Name ID` attribute isn't mapped the logout flow fails. For example, with the federated parameter `v2/logout?federated&...` user isn't redirected to the ADFS SAML logout endpoint but redirects back to application callback URL directly. As a consequence, the user isn't logged out from the IdP in that case.
+
+### How to Fix
+
+Add the `Name ID` attribute as a rule on the SAML Relaying Party Trust. 
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md
new file mode 100644
index 0000000000..044c1a5c7c
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md
@@ -0,0 +1,88 @@
+---
+description: Describes troubleshooting for SAML configuration issues.
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - index
+  - reference
+useCase:
+  - add-idp
+---
+
+# Troubleshoot SAML Configuration
+
+This guide serves to help you troubleshoot any issues that may arise during the SAML configuration process. It is not intended to be an exhaustive guide, but one that covers the most commonly encountered issues during setup.
+
+## Understand the Situation
+
+When troubleshooting, it's important that all parties involved are using the same terminology to facilitate understanding. This section describes key vocabulary and situations that will be referred to later in this guide.
+
+* **Is Auth0 serving as the SAML Service Provider (SP), the SAML Identity Provider (IdP), or both?**
+
+  Generally speaking, the SP redirects users elsewhere for authentication. The IdP authenticates the user by prompting them to login and validating the information provided. If your application redirects the user to Auth0 for authentication via SAML, then Auth0 is the IdP. If Auth0 redirects users via a Connection to a remote IdP via SAML, then Auth0 is the SP to the remote IdP.
+
+  Auth0 can act as the SP, IdP, or both.
+
+* **Does your authentication flow use an SP-initiated model, an IdP-initiated model, or both?**
+
+  SP-initiated authentication flows begin with the user navigating to the SP application and getting redirected to the IdP for login. An IdP-initiated flow means the user navigates to the IdP, logs in, and then gets redirected to the SP application.
+
+  Within enterprise settings, the IdP-initiated flow is most common.
+
+* **Which user profile attribute identifies the user at the IdP (during login) and within each application?**
+
+  If the naming attribute differs between the IdP and the application(s), you'll need to configure the appropriate mappings within Auth0 so that it sends the correct user profile attributes to the application(s).
+
+  * From our experience, using the email address as the unique identifier is the easiest option, though there are privacy concerns with this option.
+  * Enterprise organizations often use an internal ID of some type with the IdP, which needs to be mapped to another attribute meaningful to outsourced SaaS applications.
+
+* **Are your authentication requests signed?**
+* **Are your authentication assertions encrypted?**
+
+## Information Gathering
+
+When troubleshooting, we recommend beginning by gathering information that helps answer the following questions:
+
+1. How many users experience the issue? Just one user? All users?
+2. Is this an issue with a new setup, or is this an existing integration that's stopped working?
+3. How many applications does the issue affect?
+4. What is the expected behavior? What is the behavior you're seeing?
+5. How far through the login sequence does the user get?
+
+## Troubleshooting approaches
+
+* [Troubleshooting SAML when Auth0 is the Service Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp)
+* [Troubleshooting SAML when Auth0 is the Identity Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp)
+
+## If the Issue Affects Only One (or Just a Few) Users
+
+* Check the user's profile, browser, or device for any issues.
+* Check to see if it happens in all browsers for the affected users (indicating a data issue) or just certain types of browsers (indicating a browser-specific issue).
+* Check to see if the browser has enabled JavaScript and cookies.
+* Check that the caps lock key is disabled.
+* If the user is using a mobile device, check to see if there's any software that might impact authentication and/or authorization (such as not running some type of required software).
+* Check to see if the user can access some of the app's key URLs, such as the IdP's Single Sign-on (SSO) URL (indicating a network connectivity issue).
+
+## Next Steps
+
+If the troubleshooting steps listed above don't solve the issue you're seeing, please request assistance from Auth0 by opening up a ticket in the Support Center. Be sure to include the following information:
+
+1. The number of users experiencing this issue. One? All?
+2. Whether this issue involves a new setup or if it involves an existing integration that suddenly stopped working
+3. The number of applications affected
+4. What the expected behavior is, as well as what the current behavior is
+5. How far through the login sequence the user gets
+6. The name of the application registered in Auth0 and the identity protocol it uses
+7. The name of the Connection involved
+8. Whether or not you're using the Auth0 Lock widget (if so, what version?)
+9. Is a customized version of Lock used?
+10. An HTTP trace of the SSO interaction in [a .har file](/troubleshoot/guides/generate-har-files)
+11. An Auth0 log entry for the failed authentication
+12. An authentication log file from any third-party applications (such as Sharepoint) involved
+
+### Keep reading
+
+* [Common SAML Errors](/protocols/saml/saml-configuration/troubleshoot/common-saml-errors)
+
diff --git a/ja-jp/articles/protocols/saml/saml-idp-eloqua.md b/ja-jp/articles/protocols/saml/saml-idp-eloqua.md
new file mode 100644
index 0000000000..89817dd1d3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-idp-eloqua.md
@@ -0,0 +1,103 @@
+---
+description: How to configure Auth0 to serve as an Identity Provider for Oracle Eloqua.
+topics:
+  - saml
+  - oracle
+  - eloqua
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for Oracle Eloqua
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [Oracle Eloqua Marketing Cloud](http://www.oracle.com/partners/en/products/applications/eloqua-marketing-cloud-service/get-started/index.html).
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications).
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/eloqua/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `https://login.eloqua.com/auth/saml2/acs`
+
+- **Settings**:
+
+  ```text
+  {
+    "audience": "http://foo",
+    "recipient": "https://login.eloqua.com/auth/saml2/acs",
+    "mappings": {
+      "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+      "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",  
+      "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+      "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",  
+      "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
+      "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
+      "groups": "http://schemas.xmlsoap.org/claims/Group"
+    },
+    "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+    "nameIdentifierProbes": [
+      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+    ],
+    "destination": "https://login.eloqua.com/auth/saml2/acs"
+  }
+
+  ```
+
+Note that the `audience` is set to `http://foo`. This will be changed when the Identity Provider settings are completed on the Eloqua side.
+
+Click **Save**.
+
+Go to the *Usage* tab and download the Identity Provider metadata. This IDP metadata will be used while setting up the configuration in Eloqua.
+
+![Download Identity Provider Metadata](/media/articles/protocols/saml/eloqua/download-idp-metadata.png)
+
+## Configure Oracle Eloqua
+
+Login as Admin on Eloqua and click on *Settings > Users > Single Sign-On > Identity Provider Settings*.
+
+Click **Upload Identity Provider from Metadata**. You should upload here the Identity Provider metadata you downloaded in the previous from the Auth0 dashboard.
+
+![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-1.png)
+
+Browse to find the downloaded metadata file.
+
+![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-2.png)
+
+Edit the newly added identity provider and complete the following steps:
+
+- Set the **User Identity Mapping** to `Assertion contains the Email Address from the User object` and click **Save**.
+
+- From the *Identity Provider Details* copy the **Service Provider Entity URL**.
+
+- Within ELOQUA IDP settings, if this is the default IDP, mark this IDP as default.
+
+
+## Update the Audience Restriction
+
+We will now use the **Service Provider Entity URL** copied from within the IDP settings in Eloqua to set the `audience` restriction within Auth0.
+
+Navigate to __Dashboard > Applications > select your application > Addons > SAML2 Web App > Settings__ and set the `audience` to the value you copied.
+
+## Test
+
+Login to Eloqua with Auth0 should be enabled now. You can sign in to Eloqua with both IDP initiated login and SP initiated login.
+
+### SP Initiated Login
+
+Navigate to [https://login.eloqua.com/auth/saml2](https://login.eloqua.com/auth/saml2) , enter your company name and start the SAML login process with Auth0.
+
+![Eloqua SP Initiated Login](/media/articles/protocols/saml/eloqua/sp-login.png)
+
+
+### IdP Initiated Login
+
+For IDP Initiated login use the **Identity Provider Login URL** defined under the **Dashboard > Applications > select your application > Addons > SAML 2 Web App > Usage**.
+
+![Eloqua IdP Initiated Login](/media/articles/protocols/saml/eloqua/idp-login.png)
diff --git a/ja-jp/articles/protocols/saml/saml-idp-generic.md b/ja-jp/articles/protocols/saml/saml-idp-generic.md
new file mode 100644
index 0000000000..5c5576a8e3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-idp-generic.md
@@ -0,0 +1,80 @@
+---
+title: Auth0 as Identity Provider
+description: How to configure Auth0 to serve as an Identity Provider in a SAML federation.
+toc: true
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Auth0 as Identity Provider
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider in a SAML federation.
+
+## 1. Obtain Information from the Service Provider
+
+You will need to obtain from the Service Provider (application) the URL to which the SAML Authentication Assertion should be sent. This may be called **Assertion Consumer Service URL**, **the Post-back URL**, or **Callback URL**.
+
+## 2. Configure Auth0 as IDP
+
+In this section you will configure Auth0 to serve as an Identity Provider. You will do this by registering an application and using an addon.
+
+1. Go to [Dashboard > Applications](${manage_url}/#/applications).
+1. Click the **+ CREATE APPLICATION** button on the right.
+1. In the **Name** field, enter a name like `MySAMLApp`, and select the [application type](/applications).
+1. Click **SAVE**.
+1. Go back to [Dashboard > Applications](${manage_url}/#/applications).
+1. Find the row for the application you just created, and click on the **Settings** icon to the right of the application name. (the round gear icon)
+1. Scroll down and click on the **Advanced Settings** link.
+1. In the expanded window, select the **Certificates** tab and click on the **DOWNLOAD CERTIFICATE** button.  In the popup which appears, select `PEM` to select a PEM-formatted certificate.  The certificate will be downloaded to a file called `${account.tenant}.pem`.  Save this file as you will need to upload it when you configure the Service Provider.
+    ![Download Certificate](/media/articles/saml/saml-idp-generic/saml-idp-generic1.png)
+1. Select the **Endpoints** tab and scroll down to **SAML**.  Copy the contents of the **SAML Protocol URL** field and save it as you will need to provide it to the Service Provider.
+    ![SAML Protocol URL](/media/articles/saml/saml-idp-generic/saml-idp-generic2.png)
+1. Scroll back up and click on the **Addons** tab.  Then click on **SAML2 WEB APP**.
+    ![SAML2 WEB APP](/media/articles/saml/saml-idp-generic/saml-idp-generic3.png)
+1. In the **Application Callback URL** field, enter the URL of the Service Provider (or application) to which the SAML assertions should be sent after Auth0 has authenticated the user. This is the Assertion Consumer Service (ACS) URL. If your Service Provider is sending multiple ACS URLs in the SAML Request, you will need to whitelist them by adding them to the Application's **Allowed Callback URLs** setting in Application Settings.
+    ![Application Callback URL](/media/articles/saml/saml-idp-generic/saml-idp-generic4.png)
+1.  In the Addon SAML2 Web App popup, click on the **Usage** tab.  This tab will provide you with the information needed to configure the Service Provider application.
+    ![Usage](/media/articles/saml/saml-idp-generic/saml-idp-generic5.png)
+
+## 3. Configure the Service Provider
+
+In this section you will add some information to the Service Provider so they know how to send SAML-based authentication requests to Auth0. 
+
+The instructions provided here are generic. You will need to find the appropriate screens and fields on the Service Provider.
+
+If the Service Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above (**Applications > Addons > Usage**).
+
+If the Service Provider does not support uploading a metadata file, you can configure it manually, using the information from the Auth0 **Applications > Addons > Usage** screen as follows:
+
+- **Identity Provider Login URL**: This is the URL to which the Service Provider should send its SAML Authentication Requests.
+
+Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, instead of using a URL in the format of `https://[YOUR TENANT].auth0.com/samlp/CLIENTID?connection=Username-Password-Authentication` you will want to use one in this format: `https://[YOUR CUSTOM DOMAIN]/samlp/CLIENTID?connection=Username-Password-Authentication`.
+
+If the Service Provider also has a field for a Logout URL, you can enter the same **Identity Provider Login URL**. Both login and logout are handled by the same URL.
+
+The Service Provider will need a certificate from Auth0. 
+
+You can download this certificate from the **Applications > Addons > Usage** screen. This certificate will be used to validate the signature of the SAML Authentication Assertions sent from Auth0 to the Service Provider.
+
+If the Service Provider asks for an Issuer, this can also be obtained from the same screen.
+
+## 4. Test
+
+Once you have completed the above configuration, test the login.
+
+If the Service Provider has been configured correctly, it should redirect the user browser to Auth0 for login. After authenticating the user, Auth0 should redirect the user browser back to the application.
+
+## 5. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+- If your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution.
+
+- When troubleshooting Single Sign-on (SSO), it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for `HTTP Trace` to find some. Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from the Service Provider to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider application.
+
+- Make sure cookies and javascript are enabled for your browser.
+
+- The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool.
diff --git a/ja-jp/articles/protocols/saml/saml-sp-generic.md b/ja-jp/articles/protocols/saml/saml-sp-generic.md
new file mode 100644
index 0000000000..2a110ab059
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-sp-generic.md
@@ -0,0 +1,180 @@
+---
+description: How to configure Auth0 to serve as a Service Provider in a SAML federation.
+toc: true
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Auth0 as Service Provider
+
+These instructions explain how to configure Auth0 to serve as a Service Provider in a SAML federation.
+
+There are **5 sections**, including a troubleshooting section at the end.
+
+1. Obtain information from IDP
+2. Configure Auth0 as Service Provider
+3. Add your Service Provider metadata to the Identity Provider
+4. Test the connection from Service Provider to Identity Provider
+5. Troubleshooting
+
+## 1. Obtain information from IDP
+
+You will need to obtain some information from the Identity Provider.  The instructions here will be generic.  You will have to locate this information in your specific Identity Provider.
+
+* **SSO URL** - The URL at the Identity Provider to which SAML authentication requests should be sent. This is often called a Single Sign-on (SSO) URL.
+* **Logout URL** - The URL at the Identity Provider to which SAML logout requests should be sent.  This is often called a logout URL, a global logout URL or single logout URL.
+* **Signing certificate** - The Identity Provider will digitally sign authentication assertions and the signing certificate is needed by the Service Provider to validate the signature of the signed assertions. There should be a place to download the signing certificate from the Identity Provider. If the certificate is not in .pem or .cer format, you should convert it to one of those formats.
+
+## 2. Configure Auth0 as Service Provider
+
+In this section you will configure Auth0 to serve as a SAML Service Provider.
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Connections"** link at left.
+1. In the list of options below "Connections", click on **"Enterprise"**.
+1. Click on the **"Create Connection"** button.
+
+In the **"New SAML Connection"** window, enter the following information:
+
+- **Connection Name:** You can enter any name, such as `SAML-SP`.
+- **Display Name:** If a value is provided, Universal Login will have the button say "Continue with (Display Name)".
+- **IdP Domains:** (optional) Provide a comma-separated list of the domains that can be authenticated in the Identity Provider. This step is only needed for identifier-first authentication flows  If you leave this field blank, users with any email domain can use the IdP.
+- **Sign In URL:** Enter the **SAML SSO URL** that you obtained from the Identity Provider.
+- **Sign Out URL:** Enter the **SAML Logout URL** obtained from the Identity Provider.
+- **Certificate:**  Click on the red **"UPLOAD CERTIFICATE"** button and select the `.pem` file you obtained from the Identity Provider.
+- **User Id Attribute**: The attribute in the SAML token that will be mapped to the `user_id` property in Auth0. If not set, then the `user_id` will be retrieved from the following (in listed order):
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier`
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn`
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`
+
+You can ignore the rest of the fields for now.
+
+Click on the blue **"SAVE"** button at the bottom.
+
+A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it)
+
+Click on the **"CONTINUE"** button.
+
+In the window that appears, metadata about this SAML service provider is displayed. You will need to use the information from this screen to configure the Identity Provider.
+
+The first bullet is the post-back URL or Assertion Consumer Service (ACS) URL. This is the URL the Identity Provider will send Authentication Assertions to after authenticating a user. Enter this value where the Identity Provider asks for Assertion Consumer Service URL. It may just call this a Service Provider URL.
+
+The second bullet tells you the **"Entity ID"**.  It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__.
+
+Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. Use this value if the Identity Provider asks for Entity ID or SAML Audience.
+
+The third bullet indicates the binding that will be used to send the SAML Request from Auth0 to the Identity Provider. If the Identity Provider provides a choice, select HTTP-Redirect as shown on your metadata screen.
+
+The fourth bullet indicates that Auth0 expects the Identity Provider to respond with an HTTP POST, such as the Authentication Assertion from the Identity Provider will be sent using the HTTP POST binding. If the Identity Provider provides a choice, indicate that HTTP-POST binding should be used for Authentication Assertions.
+
+The nameid format is the format for the attribute that will be used to identify users.
+
+In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_.
+
+In general, you can access the metadata for a SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+Make a note of this metadata URL as you may be able to use it to configure the Identity Provider in the next step.
+
+## 3. Add your Service Provider metadata to the Identity Provider
+
+In this section you will add some information to the Identity Provider so the Identity Provider knows how to receive and respond to SAML-based authentication requests from the Auth0 Service Provider. The instructions provided here are generic. You will need to find the appropriate screens and fields on the Identity Provider.
+
+Locate the screens in the Identity Provider that allow you to configure SAML.
+
+If the Identity Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above.
+
+If the Identity Provider does not support uploading a metadata file, you can configure it manually as follows:
+
+The Identity Provider will need to know where to send the SAML assertions after it has authenticated a user. This is the **Assertion Consumer Service URL** in Auth0. The Identity Provider may call this any of the following:
+
+* Assertion Consumer Service URL
+* Application Callback URL
+
+```text
+https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME
+```
+
+The `connection` URL parameter is required for identity provider-initiated flows.
+
+Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, it should be in the format of `https://YOUR_CUSTOM_COMAIN/login/callback?connection=YOUR_CONNECTION_NAME`.
+
+If the Identity Provider has a field called "Audience" or "Entity ID", you should enter into that field the **Entity ID** from Auth0:
+
+```text
+"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME"
+```
+
+If the Identity Provider provides a choice for bindings, you should select **HTTP-Redirect** for Authentication Requests.
+
+The **Single Logout Service URL**, where SAML logout requests and/or responses from the Identity Provider must be sent, should be configured as:
+
+```text
+https://${account.namespace}/logout
+```
+
+**Signing Logout Requests**: When configuring the Identity Provider, make sure that SAML Logout Requests sent to the Service Provider are signed.
+
+## 4. Test the connection from Service Provider to Identity Provider
+
+In this section, you will test to make sure the SAML configuration between Auth0, the Service Provider, and the remote SAML Identity Provider is working.
+
+* In the [Dashboard](${manage_url}), navigate to:  __Connections > Enterprise > SAMLP Identity Provider__.
+
+* Click on the triangular **Try** button for the SAML connection you created earlier.  This button is to the right of the name of the connection. You can hover your mouse over the button to have the text label appear.
+
+* You will first see a Lock login widget appear that is triggered by the Service Provider.  Enter the username. If you entered an email domain in the SAMLP connection configuration, the username should belong to that email domain.
+
+You will then be redirected to the login screen of the Identity Provider. Login with the credentials for a user that exists in the Identity Provider.
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __It works__.  This page will display the contents of the SAML authentication assertion sent by the Identity Provider to Auth0 Service Provider.
+This means the SAML connection from Auth0 Service Provider to Identity Provider is working.
+
+If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard. You cannot send this to an anonymous user to have them try it.
+:::
+
+Here is a sample of the **It Works** screen:
+
+![](/media/articles/saml/saml-sp-generic/saml-auth0-9.png)
+
+## 5. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your HTML page or it may have stale cookies that impact execution.
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction.  There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for "HTTP Trace" to find some.  Once you have an HTTP trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application.
+
+Be sure to check to make sure cookies and javascript are enabled for your browser.
+
+Check to make sure that the callback URL specified by your application in its authentication request is listed in the **Allowed Callback URLs** field.  
+
+To do so, go to [Dashboard](${manage_url}), click on __Applications__, then on the __Settings__ icon to the right of the application name.
+
+The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool.
+
+## Supported algorithms for signatures
+
+We currently support the following algorithms for processing XML Digital Signatures:
+
+* Canonicalization
+  * 'http://www.w3.org/2001/10/xml-exc-c14n#'
+  * 'http://www.w3.org/2001/10/xml-exc-c14n#WithComments'
+  * 'http://www.w3.org/2000/09/xmldsig#enveloped-signature'
+
+* Signature
+
+  * 'http://www.w3.org/2000/09/xmldsig#rsa-sha1'
+  * 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
+
+* Digest
+
+  * 'http://www.w3.org/2000/09/xmldsig#sha1'
+  * 'http://www.w3.org/2001/04/xmlenc#sha256'
diff --git a/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md b/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md
new file mode 100644
index 0000000000..26cc31a6f7
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md
@@ -0,0 +1,82 @@
+---
+description: How to use Auth0 in a SAML2 web application.
+topics:
+  - saml
+  - web-apps
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Using Auth0 with a SAML2 Web App
+
+You can configure a SAML2 Web Application for use with an Auth0 Application via the Management Dashboard.
+
+## Enable the SAML2 Web App Addon for your Auth0 Application
+
+1. Log in to Auth0, and navigate to the [Applications](${manage_url}/#/applications) page of the [Management Dashboard](${manage_url}).
+
+  ![](/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png)
+
+2. Identify the Application with which you want to use a SAML2 Web Application. Click the Application's name to go to its configuration settings pages.
+3. Go to the *Addons* page for the Application.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/select-addon.png)
+
+4. In the SAML2 Web App box, click the slider to enable the Addon. You will see a *Settings* page for the Addon.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/configure-addon.png)
+
+5. To enable the Addon from the Auth0 side, you will need to provide your **Application Callback URL**, which receives the SAML response, as well as the **Settings** for your setup. Within the *Settings* page, there is a sample object that you can use when determining which settings you want to enable:
+
+```js
+{
+// "audience":  "urn:foo",
+// "recipient": "http://foo",
+// "mappings": {
+//   "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+//   "email":       "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+//   "name":        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+//   "given_name":  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+//   "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
+//   "upn":         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
+//   "groups":      "http://schemas.xmlsoap.org/claims/Group"
+// },
+// "createUpnClaim":       true,
+// "passthroughClaimsWithNoMapping": true,
+// "mapUnknownClaimsAsIs": false,
+// "mapIdentities":        true,
+// "signatureAlgorithm":   "rsa-sha1",
+// "digestAlgorithm":      "sha1",
+// "destination":          "http://foo",
+// "lifetimeInSeconds":    3600,
+// "signResponse":         false,
+// "typedAttributes":      true,
+// "includeAttributeNameFormat":  true,
+// "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
+// "nameIdentifierProbes": [
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+// ],
+// "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified",
+// "logout": {
+//   "callback": "http://foo/logout"
+// }
+}
+```
+
+You can click **Debug** to test if your provided parameters are valid.
+
+Click **Save** when done.
+
+## Provide Your Auth0 Application Details to Your SAML2 Web App
+
+While the specific steps for providing your Auth0 Application details to your SAML2 Web App will vary, you can get the configuration information you need from the *Usage* tab after you have set up the Addon from the Auth0 side.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/usage.png)
+
+## Passive SAML Requests
+
+Currently, the SAML2 Web App addon does *not* support passive SAML requests (e.g. where `isPassive=true`).
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/samlp-providers.md b/ja-jp/articles/protocols/saml/samlp-providers.md
new file mode 100644
index 0000000000..b42a172665
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlp-providers.md
@@ -0,0 +1,38 @@
+---
+description: List of Identity Provider services known to support the SAML protocol.
+topics:
+  - saml
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+# List of SAML-P Identity Providers
+
+This is a list of Identity Provider services known to support the SAML protocol. There may be additional services beyond what is shown below.
+
+## SAML-P
+
+The following providers have participated in a Kantara inter-operability test and are therefore likely to conform well to the SAML spec.
+
+  * __adAS__
+  * __ADFS__
+  * __Dot Net Workflow__
+  * __Elastic SSO Team & Enterprise__
+  * __Entrust GetAccess & IdentityGuard__  (check protocol supported)
+  * __EIC__  (check protocol supported)
+  * __Ilex Sign&go__
+  * __iWelcome__
+  * __NetIQ Access Manager__
+  * __OpenAM__
+  * __RCDevs Open SAMPL IdP__
+  * __Optimal IdM VIS Federation Services__
+  * __Oracle Access Manager__ (Oracle Identity Federation merged into this)
+  * __PingFederate__  (IDP Light)
+  * __RSA Federated Identity__  (IDP Light)
+  * __SecureAuth__
+  * __Symplified__
+  * __Tivoli Federated Identity Manager__
+  * __TrustBuilder__
+  * __Ubisecure SSO__
+  * __WSO2 Identity Server__
diff --git a/ja-jp/articles/protocols/saml/samlp.md b/ja-jp/articles/protocols/saml/samlp.md
new file mode 100644
index 0000000000..3b32321d29
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlp.md
@@ -0,0 +1,74 @@
+---
+title: SAML
+description: SAML Identity Provider Configuration
+topics:
+  - saml
+  - samlp
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+
+# SAML Identity Provider Configuration
+
+## Common settings
+
+These are the parameters used to configure a SAML Identity Provider (IdP):
+
+* The __post-back URL__ (also called __Assertion Consumer Service URL__) is: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+* The __Entity ID__ of the Service Provider is: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (default value). Use `connection.options.entityId` if available. You can obtain this value using the [Get a connection by its id APIv2 endpoint](/api/management/v2#!/Connections/get_connections_by_id):
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer ACCESS_TOKEN"
+    }]
+}
+```
+
+::: note
+You need to replace the `ACCESS_TOKEN` header value, with a Management APIv2 Access Token. For information on how to do that see [Access Tokens for the Management API](/api/management/v2/tokens).
+:::
+
+* The __SAML Request Binding__ (also called the __Protocol Binding__): sent to the IdP from Auth0. If possible, dynamically set the value based on `connection.options.protocolBinding`:
+
+| `connection.options.protocolBinding` value           | SAML Request Binding value |
+| ---------------------------------------------------- | -------------------------- |
+| Empty value ("") or not present                      | `HTTP-Redirect`            |
+| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect` | `HTTP-Redirect`            |
+| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`     | `HTTP-POST`                |
+
+If dynamically setting the value isn't possible, then set as either `HTTP-Redirect` (default) or `HTTP-Post` if you selected this option in **Protocol Binding**
+
+* The __SAML Response Binding__ : how the SAML token is received by Auth0 from IdP, set as `HTTP-Post`
+* The __NameID format__: `unspecified`
+* The SAML assertion, and the SAML response can be individually or simultaneously signed.
+* The __SingleLogout service URL__, where the SAML Identity Provider will send logout requests and responses, is: `https://${account.namespace}/logout`. SAML logout requests must be signed by the Identity Provider.
+
+## Signed assertions
+
+By default, SAML assertions for IdP connections are signed, which we recommend. You can use the following public keys to configure the IdP: 
+
+* [CER](https://${account.namespace}/cer?cert=connection)
+* [PEM](https://${account.namespace}/pem?cert=connection)
+* [raw PEM](https://${account.namespace}/rawpem?cert=connection)
+* [PKCS#7](https://${account.namespace}/pb7?cert=connection)
+* [Fingerprint](https://${account.namespace}/fingerprint?cert=connection)
+
+## IdP-initiated Single Sign-on
+
+[Click here to learn more about IdP-Initiated Single Sign-on (SSO)](/protocols/saml/idp-initiated-sso)
+
+## Metadata
+
+Some SAML Identity Providers can accept importing metadata directly with all the required information. You can access the metadata for your connection in Auth0 here:
+
+```text
+https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME
+```
diff --git a/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md b/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md
new file mode 100644
index 0000000000..6440d44a11
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md
@@ -0,0 +1,340 @@
+---
+description: Learn how to use SAML Single Sign-on (SSO) with Auth0 as both the Service Provider and Identity Provider, using two Auth0 tenants, allowing you to test your Auth0 SAML without configuring another provider to do so.
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# SAML SSO with Auth0 as Service Provider and as an Identity Provider
+
+This tutorial will create a simple example application that uses Auth0 to do SAML Single Sign-on (SSO), using one Auth0 tenant (tenant 1) as a SAML Service Provider(SP), and authenticating users against a second Auth0 tenant (tenant 2) serving as SAML Identity Provider(IDP).  This gives you a way to test your Auth0 SAML tenant (tenant 1) configuration, using Auth0 as an IDP so you don't have to learn and set up another IDP.
+
+There are **9 steps** to this sample and the tenth is a troubleshooting section to help resolve any problems that might arise.
+
+1. [Establish two Auth0 tenants](#1-establish-two-auth0-tenants)
+2. [Set up the Auth0 Identity Provider (IDP) (tenant 2)](#2-set-up-the-auth0-idp-tenant-2-)
+3. [Set up the Auth0 Service Provider (SP) (tenant 1)](#3-set-up-the-auth0-service-provider-tenant-1-)
+4. [Add your Service Provider metadata to the Identity Provider](#4-add-your-service-provider-metadata-to-the-identity-provider)
+5. [Test the Identity Provider](#5-test-identity-provider)
+6. [Register a simple HTML application with which to test the end-to-end connection](#6-register-a-simple-html-application-with-which-to-test-the-end-to-end-connection-)
+7. [Test the connection from Service Provider to Identity Provider](#7-test-the-connection-from-service-provider-to-identity-provider)
+8. [Create the HTML page for the application](#8-create-the-html-page-for-a-test-application)
+9. [Test your sample application](#9-test-your-sample-application)
+10. [Troubleshooting](#10-troubleshooting)
+
+## 1. Establish two Auth0 Tenants
+
+If you do not already have two Auth0 tenants, you will need to create them. If you do already have two tenants, you can skip to step #2.
+
+### In the Auth0 Dashboard
+
+In the upper right corner, click on the name of your tenant and in the popup menu which appears, select **+ Create Tenant**.  
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-01.png)
+
+In the window which appears, enter a name for your second tenant in the **"Your Auth0 domain"** field and press the **"SAVE"** button.
+
+You can switch back and forth between the tenants by going to the upper right corner of the dashboard, clicking on the name of the current tenant, and using the popup menu which appears to switch between your tenants.
+
+## 2. Set up the Auth0 IDP (tenant 2)
+
+In this section you will configure one Auth0 tenant (tenant 2) to serve as an Identity Provider.  You will do this by registering an application, but in this case, the 'application' you register is really a representation of tenant 1, the SAML Service Provider.
+
+Log into **Tenant 2**
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Applications"** link at left.
+
+2. Click on the red **"+ CREATE APPLICATION"** button on the right.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-02.png)
+
+3. In the **Name** field, enter a name like "My-Auth0-IDP".
+
+4. Press the blue **"SAVE"** button.
+
+5. Click on the **"Settings"** tab.
+
+6. Scroll down and click on the **"Show Advanced Settings"** link.
+
+7. In the expanded window, scroll down to the **"Certificates"** section and click on the **"DOWNLOAD CERTIFICATE"** link and select PEM from the dropdown, to download a PEM-formatted certificate.  The certificate will be downloaded to a file called "${account.tenant}.pem".  Save this file as you will need to upload this file when configuring the other Auth0 tenant, tenant 1.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-03.png)
+
+8. Click on the **"Endpoints"** tab and go to the **"SAML"** section.  Copy the entire contents of the **"SAML Protocol URL"** field and save it as in the next step you will need to paste it into the other Auth0 tenant, tenant 1.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-04.jpg)
+
+Next, create a user to use in testing the SAML SSO sequence.
+**In the Auth0 dashboard:**
+
+1. Click on the **"+ CREATE YOUR FIRST USER"** button.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-05.png)
+
+2. In the **Email** field, enter an email for your test user.  The domain name for the email should match what you enter in section 3 below.  For example, if your user is `john.doe@abc-example.com`, you would enter that here, and then enter "abc-example.com" in step 3 below for the Email domain.
+
+3. Enter a password for the user
+
+4. For the Connection, leave it at the default value. (Username-Password-Authentication)
+
+5. Press the blue **"SAVE"** button.
+
+
+## 3. Set up the Auth0 service provider (tenant 1)
+
+In this section you will configure another Auth0 tenant (tenant 1) so it knows how to communicate with the second Auth0 tenant (tenant 2) for SSO via the SAML protocol.
+
+Switch to **Tenant 1**. You can do this using the **Switch tenant** option in the upper-right menu.
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Connections"** link at left.
+2. In the list of options below "Connections", click on **"Enterprise"**
+3. In the middle of the screen, click on **"SAMLP Identity Provider"**
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-06.jpg)
+
+4. Click on the blue **"Create New Connection"** button
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-07.jpg)
+
+In the **"Create SAMLP Identity Provider"** connection window, enter the following information into the "Configuration" tab.
+
+**Connection Name:** You can enter any name, such as "SAML-Auth0-IDP"
+
+**Email Domains:** In this example, we will use the Lock widget, so in the Email Domains field enter the email domain name for the users that will log in via this connection.
+For example, if your users have an email domain of 'abc-example.com', you would enter that into this field. You can enter multiple email domains if needed.  Make sure the test user you created in section 2 has an email address with email domain that matches what you enter here.
+
+**Sign In URL:** enter the **SAML Protocol URL** field that you copied in section 2 above (from tenant 2, go to: **Dashboard > Applications > Settings > Advanced Settings > ENDPOINTS section > SAML tab > SAML Protocol URL field**).
+
+**Sign Out URL:** enter the same URL as for the Sign In URL above.
+
+**X509 Signing Certificate:**  
+Click on the red **"UPLOAD CERTIFICATE..."** button and select the `.pem` file you downloaded from tenant 2 in section 2 above.
+
+You can ignore the rest of the fields for now.
+
+**Save:** Click on the blue **"SAVE"** button at the bottom.
+
+After pressing the **"SAVE"** button, A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it)
+
+Copy and save the URL below the **"CONTINUE"** button, and then click on the **"CONTINUE"** button.
+
+In the window that appears, metadata about this SAML provider (tenant 1) should be displayed. If you are not logged into the Auth0 documentation site, generic SAML provider configuration data will be displayed. Click "Login" in the top right corner of the page, log in with your Auth0 management dashboard credentials, and then go to the URL you saved in the previous step.
+
+You will need to collect two pieces of information about this Auth0 tenant (the service provider) that you will then paste into the other Auth0 tenant you set up (the identity provider).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-08.jpg)
+
+First, look for the second bullet in the list of information that tells you the **"Entity ID"**.  It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__.  
+
+Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. You will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above).
+
+In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_.  
+
+Copy the URL below that line into your browser address bar. Again, you will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above).
+
+In general, you can access the metadata for a given SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+Once you go to that metadata URL, it will display the metadata (or prompt you to save the metadata file) for this connection in tenant 1 (service provider side of the federation). It will look something like the following with your tenant name in place of the 'xxxxx':
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-09.jpg)
+
+You need to locate the row that starts with **"AssertionConsumerService"** and copy the value of the **"Location"** field.  It will be a URL of the form `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`.
+
+Copy and save this URL. This is the URL on Tenant 1 that will receive the SAML assertion from the IDP. In the next section you will give this URL to the IDP so it knows where to send the SAML assertion.
+
+## 4. Add your Service Provider metadata to the Identity Provider
+
+In this section you will go back and add some information about the Service Provider (Tenant 1) to the Identity Provider (tenant 2) so the Identity Provider Auth0 tenant knows how to receive and respond to SAML-based authentication requests from the Service Provider Auth0 tenant.
+
+* Switch back to **Tenant 2**.
+
+**In the Auth0 dashboard:** for Tenant 2
+
+1. Click on **"Applications"** link at left.
+
+2. Find the row for the application you created earlier, and click on the **"Add Ons"** icon to the right of the application name. (the angle bracket and slash icon)
+3. Locate the box with the **"SAML2 WEB APP"** label and click on the circle toggle to turn it green.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-10.jpg)
+
+4. Next, a configuration window will pop up for the **"Addon: SAML2 Web App"**.  Make sure you are in the **Settings**" tab.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-11.png)
+
+5. In the **"Application Callback URL"** field, paste in the **Assertion Consumer Service URL** that you copied and saved in section 3 above (the last step).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-12.png)
+
+6. In the Settings field below, go to line 2 that has the "audience" attribute.  
+
+First remove the "//" at the beginning of the line to uncomment it, and remove the comma (',') from the end of the line.
+
+Next, replace the original value (urn:foo) with the **Entity ID** value you saved and copied in step 3 above (including your actual connection name). The new line 2 should look something like:
+
+```text
+"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME"
+```
+
+7. Click on the blue **"SAVE"** button at the bottom of the screen
+
+## 5. Test Identity Provider
+
+In the same screen, click on the red **"DEBUG"** button.
+
+That will trigger a login screen from tenant 2, the Identity Provider.
+
+Log in with the credentials for the user you created above.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-13.png)
+
+If your configuration is correct, you will see a screen titled **"It works!"**
+
+This screen will show you the encoded and decoded SAML response that would be sent by the Identity Provider.
+
+Check the decoded SAML response and locate (about half-way down) the `""` tag and make sure it matches the **Entity ID** you entered in the previous screen (obtained during step 3).
+
+Click on **"Close this window"** at the bottom of the screen.
+
+## 6. Register a simple HTML application with which to test the end-to-end connection.
+
+In this section, you will register an application in Auth0 that will use the SAML connection you set up in the above steps.
+
+Make sure you are logged into the **Tenant 1 Auth0 dashboard**.
+
+* In the **Auth0 dashboard**, click on the **"Applications"** link at left.
+
+* Click on the red **"+ CREATE APP"** button on the right.
+
+* In the **Name** field, enter a name like "My-HTML-SAML-App".
+
+* Select "Regular Web App"
+
+* Press the blue **"SAVE"** button.
+
+* Click on the **"Settings"** tab.
+
+* Save the **"Domain"** and **"Client ID"** values for use below in step 8.
+
+* In the **"Allowed Callback URLs"** field, enter **[http://jwt.io](http://jwt.io)**.
+
+* The list of allowed callback URLs is a list of URL(s) to which users will be redirected after authentication.  The URL(s) entered here must match the **"callback URL"** in the HTML code created in the next step.  Normally you would enter a URL for your application, but to keep this example simple, users will simply be sent to the Auth0 JWT online tool which will provide some information about the JSON Web Token (JWT) returned at the end of the authentication sequence.
+
+* Press the blue **"SAVE CHANGES"** button at the bottom of the screen.
+
+* In the same screen, click on the blue **"Connections"** tab (In the row that says Quick Start, Settings and so on.
+
+* Scroll down to the section near the bottom where it says **"ENTERPRISE"**.
+
+* Find the row for the SAML connection you created above and click on the on/off toggle at right so that it is green, for "on".  That enables the SAML connection for this application.  
+
+## 7. Test the connection from Service Provider to Identity Provider
+
+In this section, you will test to make sure the SAML configuration between Auth0 tenant 1 (Service Provider) and Auth0 tenant 2 (Identity Provider) is working.
+
+* On the [Dashboard](${manage_url}), navigate to:  __Connections -> Enterprise -> SAMLP Identity Provider__.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-14.jpg)
+
+* Click on the triangular **"Try"** button for the SAML connection you created earlier.  This button is to the right of the name of the connection.  You can hover your mouse over the button to have the text label appear.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-15.png)
+
+* Because you already logged in while testing this connection above, you will likely be sent directly to the "It Works!" page shown previously. If you are presented with the Lock login screen, login using the credentials for the user you created above. On some older tenants, you may see the "Last time you signed in using" dialog as shown below, in which case you can just click on your email address to continue.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-16.png)
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __"It works!"__.  This page will display the contents of the SAML authentication assertion sent by the Auth0 Identity Provider to Auth0 Service Provider.
+This means the SAML connection from Auth0 Service Provider to Auth0 Identity Provider is working.
+
+If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard.  You cannot send this to an anonymous user to have them try it.
+:::
+
+## 8. Create the HTML page for a test application
+
+In this section you will create a very simple HTML page that invokes the **Auth0 Lock Widget** which will trigger the SAML login sequence.  This will enable an end-to-end test of the SAML SSO.
+
+Create an HTML page and insert the following HTML and javascript code:
+
+```html
+
+
+
+
     Click on the button to log in 
    
+
+
+
+
+
+
+
+```
+
+Make sure you replace **YOUR_CLIENT_ID** and **YOUR_DOMAIN** with the actual values of the app you registered in step 6 above. If you did not record these values in step 6, they can be found in the **Auth0 dashboard** for **Tenant 1** by going to "Applications" link and clicking on the "Settings" (gear) icon to the right of your application's name.
+
+You can also replace **audience** with the value appropriate for your Application -- however, for the purposes of this test, a placeholder will work. When specifying the **audience** parameter, be sure that it matches an identifier of an existing API that [has been configured in Auth0](/apis#how-to-configure-an-api-in-auth0).
+
+Save this file in a place where you can access it via a browser.
+For this example, we'll call it **"hello-saml.html"**.
+
+## 9. Test your sample application
+
+In this step, you will test your sample HTML application that uses the Auth0 SAML connection you set up in Tenant 1 to perform SSO via SAML against Tenant 2, serving as the SAML Identity Provider.
+
+* Open the HTML file created above with a browser. You should first see a white page with a login button on it.
+
+* Click on the **login** button.
+
+The **Auth0 Lock** widget should appear with one login option.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-18.png)
+
+If you have other connections turned on for your application, your **Auth0 Lock Widget** may look slightly different.  If you are prompted to enter an email address, make sure the email address you enter has the same domain name as the domain(s) you entered in the __Settings__ tab for the application in the Tenant 1 Auth0 dashboard  (__Applications > Settings__).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-19.png)
+
+After entering your email address, the blue button on the Lock widget may have a new label. Click on the button which may be labeled **"saml"** or **ACCESS** or with the email domain of the email address you are logging in with, to initiate the SAML sso sequence with the Auth0 Identity Provider.
+
+* As above, whether you are prompted for credentials or immediately redirected to the callback URL depends on whether you still have an active session at the Identity Provider.
+
+From the "try me" test you did earlier, you may still have an active session at the Identity Provider.  If this is the case, you will not be prompted to log in again and will simply be redirected to the callback URL specified in the HTML file. (Remember that this callback URL must also be in the __Allowed Callback URLs__ in the application's Settings tab in the Auth0 dashboard.)
+
+If sufficient time has passed, or if you delete your browser cookies before initiating the test, then you will be prompted to login when redirected to the Identity Provider.  Log in to the Identity Provider using the credentials for the test user you created in Auth0 Tenant 2.
+
+## 10. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again.  Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution.
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction.  There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for "HTTP Trace" to find some.  Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get.  You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application.
+
+Be sure to check to make sure cookies and javascript are enabled for your browser.
+
+Check to make sure that the callback URL specified in the HTML file is also listed in the **Allowed Callback URLs** field in the "Settings" tab of the application registered in the Auth0 Dashboard.  (In dashboard, Click on Applications link, then on the "Settings" icon to the right of the application's name.)
+
+The **[http://samltool.io](http://samltool.io)** tool can decode a SAML assertion and is a useful debugging tool.
diff --git a/ja-jp/articles/protocols/ws-fed/index.md b/ja-jp/articles/protocols/ws-fed/index.md
new file mode 100644
index 0000000000..bff4091e38
--- /dev/null
+++ b/ja-jp/articles/protocols/ws-fed/index.md
@@ -0,0 +1,76 @@
+---
+description: The WS-Federation protocol and how it is used in Auth0.
+topics:
+  - saml
+  - ws-federation
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# WS-Federation
+
+WS-Federation (which is short for Web Services Federation) is a protocol that can be used to negotiate the issuance of a token. You can use this protocol for your applications (such as a Windows Identity Foundation-based app) and for identity providers (such as Active Directory Federation Services or Azure AppFabric Access Control Service).
+
+## For Applications (Clients)
+
+By registering your application as an [application](/applications) in Auth0, it will automatically be assigned a WS-Fed endpoint of the form:
+
+```text
+https://${account.namespace}/wsfed/${account.clientId}
+```
+
+You can find all available options for configuring WS-Federation under the [advanced settings](${manage_url}/#/applications/${account.clientId}/settings) area for your application.
+
+![WS-Fed Endpoints](/media/articles/protocols/ws-fed-endpoints.png)
+
+You will need to configure the **Relying Party**, which can be done using the following metadata endpoint:
+
+```text
+https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml
+```
+
+You can also use the **samlConfiguration** object (available in [rules](/rules)) to configure claims sent via the  token, as well as other lower-level WS-Fed and SAML-P settings.
+
+When redirecting your users to your WS-Fed endpoint, you can use the following (optional) parameters:
+
+* `wa=wsignin1.0`: whether Auth0 should issue a token for the relying party (this is the default action)
+* `wa=wsignout1.0`: whether Auth0 should clear the user session/log the user out
+* `wreply={callback_URL}`: specifies where the response should be sent
+* `wctx={state}`: your application's state
+* `whr={connection_name}`: connection to be used (allows users to skip the Auth0 login page)
+* `wfresh=0`: whether the user must re-authenticate, even if there's a session in place (`0` requires re-authentication)
+
+Here's a sample of what your URL with the optional parameters might look like:
+
+```text
+https://${account.namespace}/wsfed/${account.clientId}?whr=google-oauth2
+```
+
+## Identity Providers
+
+If you're using Auth0 with an identity provider that utilizes the WS-Federation protocol (such as Active Directory Federation Services, Azure AppFabric Access Control Service, and IdentityServer), the easiest way to set up your integration is to create and use the **ADFS** connection type. When setting up an ADFS-based connection,  you can import the required parameters by providing Auth0 with the **Federation Metadata** endpoint *or* by importing uploading your Federation Metadata file.
+
+![New Connection Configuration Screen](/media/articles/protocols/create-adfs-connection.png)
+
+Click **Save** to proceed. You will then be presented with the instructions you need to finish configuring the integration.
+
+The Federation Metadata file contains information about the identity provider's certificates. If you provide the Federation Metadata endpoint (typically of the form ending with `/FederationMetadata/2007-06/FederationMetadata.xml`), Auth0 can check daily for changes in the configuration, such as the addition of a new signing certificate that was added in preparation for a rollover.
+
+Because of this, enabling the Federation Metadata endpoint is preferred to providing a standalone metadata file. If you provide a standalone metadata file, we will notify you via email when the certificates are close to their expiration date.
+
+::: note
+If the Federation Metadata contains both the primary **and** secondary certificates, you can use both in Auth0.
+:::
+
+To roll over certificates using the Federation Metadata endpoint, you must:
+
+1. Generate a new certificate and add as the secondary in your ADFS environment at least two days before the certificate expiry of your current primary certificate.
+
+1. Generate a new certificate, and add it as the **secondary certificate** for your ADFS environment. This should be **done at least two days before** the expiration of your active primary certificate.
+
+1. Allow Auth0 to obtain your new certificate from the Federation Metadata endpoint. Auth0 checks your endpoints once a day, so be sure to allow sufficient time for Auth0 to complete this step. 
+	
+	Alternatively, you can manually complete this step by logging in to the Auth0 Dashboard, navigating to the appropriate ADFS connection, and click  **Save**. This action results in Auth0 downloading the certificates immediately.
+
+1. Set the now-secondary certificate as the primary certificate **before** the existing primary certificate expires in your ADFS environment.
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md b/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md
new file mode 100644
index 0000000000..4dd7e6ae4a
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 Angular SDK
+
+Run the following command within your project directory to install the Auth0 Angular SDK:
+
+```bash
+npm install @auth0/auth0-angular
+```
+
+The SDK exposes several types that help you integrate Auth0 with your Angular application idiomatically, including a module and an authentication service.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md b/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md
new file mode 100644
index 0000000000..b01542e23e
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md
@@ -0,0 +1,5 @@
+
+
+:::note
+This guide focuses on using the `useAuth0()` custom React Hook. If you are using class components, check out [these samples using the `withAuth0()` higher-order component](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#use-with-a-class-component).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-react-install.md b/ja-jp/articles/quickstart/_includes/_auth0-react-install.md
new file mode 100644
index 0000000000..e7a4d96fd7
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-react-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 React SDK
+
+Run the following command within your project directory to install the Auth0 React SDK:
+
+```bash
+npm install @auth0/auth0-react
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your React application idiomatically using [React Hooks](https://reactjs.org/docs/hooks-overview.html) or [Higher-Order Components](https://reactjs.org/docs/higher-order-components.html).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md b/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md
new file mode 100644
index 0000000000..c2cc9be635
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 Vue SDK
+
+Run the following command within your project directory to install the Auth0 Vue SDK:
+
+```bash
+npm install @auth0/auth0-vue
+```
+
+The SDK exposes several types that help you integrate Auth0 with your Vue application idiomatically, including a module and an authentication service.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md b/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md
new file mode 100644
index 0000000000..a603228285
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md
@@ -0,0 +1,39 @@
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to `${callback}`.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to `${returnTo}`.
+:::
+
+<% if (typeof showWebOriginInfo !== 'undefined' && showWebOriginInfo === true) { %>
+
+### Configure Allowed Web Origins
+
+An Allowed Web Origin is a URL that you want to be allowed to access to your authentication flow. This must contain the URL of your project. If not properly set, your project will be unable to silently refresh authentication tokens, so your users will be logged out the next time they visit your application or refresh a page.
+
+::: note
+If you are following along with our sample project, set this to `${webOriginUrl}`.
+:::
+
+<% } %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md b/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md
new file mode 100644
index 0000000000..443f2c5a67
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md
@@ -0,0 +1,6 @@
+
+This example demonstrates:
+
+* How to check for a JSON Web Token (JWT) in the `Authorization` header of an incoming HTTP request.
+
+* How to check if the token is valid, using the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) for your Auth0 account. To learn more about validating Access Tokens, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create.html b/ja-jp/articles/quickstart/backend/_includes/_api_create.html
new file mode 100644
index 0000000000..32e85b9c9d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create.html
@@ -0,0 +1,7 @@
+
    Before applying authentication to your resource server/API, you need to create an entry for it in the Auth0 dashboard. This is done from the APIs section which can be found in the sidebar.
    
+
+<% if (account.userName) { %>
+  
    In the APIs section in dashboard, click the Create API button. Provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
    
+<% } else { %>
+  
    Create an Auth0 account (or login) navigate to the APIs section in Dashboard. Click the Create API button and provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
    
+<% } %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md b/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md
new file mode 100644
index 0000000000..4310502988
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md
@@ -0,0 +1,16 @@
+## Configure Auth0 APIs
+
+### Create an API
+
+In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. Leave the **Signing Algorithm** as **RS256**.
+
+![Create API](/media/articles/server-apis/create-api.png)
+
+<% if (typeof sampleLink == 'string') { %>
+<%= include('./_api_jwks_description', { sampleLink: sampleLink }) %>
+<% } else { %>
+<%= include('./_api_jwks_description') %>
+<% }  %>
+
+### Define permissions
+<%= include('./_api_scopes_access_resources') %>
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md b/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md
new file mode 100644
index 0000000000..ba4222d532
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md
@@ -0,0 +1,5 @@
+## Create a Resource Server (API)
+
+In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. For **Signing Algorithm**, select **RS256**.
+
+![Create API](/media/articles/server-apis/create-api.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md b/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md
new file mode 100644
index 0000000000..bc59e707e0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md
@@ -0,0 +1,5 @@
+The routes shown below are available for the following requests:
+
+- `GET /api/public`: available for non-authenticated requests
+- `GET /api/private`: available for authenticated requests containing an access token with no additional scopes
+- `GET /api/private-scoped`: available for authenticated requests containing an access token with the `read:messages` scope granted 
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md
new file mode 100644
index 0000000000..23d2c5b8b4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md
@@ -0,0 +1,7 @@
+By default, your API uses RS256 as the algorithm for signing tokens. Since RS256 uses a private/public keypair, it verifies the tokens against the public key for your Auth0 account. The public key is in the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) format, and can be accessed [here](https://${account.namespace}/.well-known/jwks.json).
+
+<% if (typeof sampleLink == 'string') { %>
+::: note
+We recommend using the default RS256 [signing algorithm](/tokens/concepts/signing-algorithms) for your API. If you need to use the HS256 algorithm, see the [HS256 integration sample](${sampleLink}).
+:::
+<% } %>
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md
new file mode 100644
index 0000000000..a27211ec1f
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md
@@ -0,0 +1 @@
+By default, your API will be set up to use RS256 as the algorithm for signing tokens. Since RS256 works by using a private/public keypair, tokens can be verified against the public key for your Auth0 account. This public key is accessible at [https://${account.namespace}/.well-known/jwks.json](https://${account.namespace}/.well-known/jwks.json).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md b/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md
new file mode 100644
index 0000000000..f7144c1f4c
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md
@@ -0,0 +1,3 @@
+So far, the API is only checking for whether the incoming request has valid authentication information. This solves the case of restricting endpoints such that only authenticated users can access them; however, it doesn't currently provide any way to check for **authorization**.
+
+Authorization can be added to your authentication flow by use of a **scope** claim in the Access Token which provides some indication of what that token allows access to. For more information on how to add scopes to an Access Token, see the [Scopes documentation](/scopes).
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md b/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md
new file mode 100644
index 0000000000..c2bb5146e9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md
@@ -0,0 +1,9 @@
+Permissions let you define how resources can be accessed on behalf of the user with a given access token. For example, you might choose to grant read access to the `messages` resource if users have the manager access level, and a write access to that resource if they have the administrator access level.
+
+You can define allowed permissions in the **Permissions** view of the Auth0 Dashboard's [APIs](${manage_url}/#/apis) section.
+
+![Configure Permissions](/media/articles/server-apis/configure-permissions.png)
+
+::: note
+This example uses the `read:messages` scope.
+:::
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md b/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md
new file mode 100644
index 0000000000..892df4b22d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md
@@ -0,0 +1,46 @@
+
+
+If you configured JWT validation correctly, you will be able to get proper responses from your API when you make requests. However, in the case where you get a 401 (Unauthorized) response from your API, it is because the configuration of your JWT middleware does not match with the JWT which was passed.
+
+This document will help you troubleshoot your JWT middleware configuration.
+
+## How Does a Token Get Validated?
+
+In terms of validating a JWT, there are various things to consider:
+
+1. **Is the token well-formed?** In other words, is this token conforming to the structure of a JSON Web Token (JWT)? To get more information on the structure of a JWT, please refer to [this section on the structure of a JWT](/jwt#what-is-the-json-web-token-structure-)
+
+2. **Has the token been tampered with?** The last part of a JWT is the signature. The signature is used to verify that the token was in fact signed by the sender and not altered in any way.
+
+3. **Has the token been received in its validity period?** JWTs are only valid for a specified time period (as expressed in the `exp` claim).
+
+4. **Is the token coming from the intended Authority?** This consists of 2 parts
+
+    * **Signature Verification**: Can we confirm that the JWT is correctly signed using the key issued by the issuing authority?
+
+    * **Issuer Value**: The Issuer is defined in the `iss` claim. Once again does this claim match up with what your application expects?
+
+5. **Is the token intended for the current application?** So does the `aud` claim of the JWT match with what your application is expecting?
+
+## Inspecting a Token
+
+A quick way to inspect a JWT is by using the [JWT.io](https://jwt.io/) website. It has a handy debugger which allows you to quickly check that a JWT is well-formed, and also inspect the values of the various claims.
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png)
+
+In the screenshot above you can see that the token was signed using the **RS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://rs256.test.api**.
+
+So, in other words, these values in your JWT validation configuration registration must match **exactly** - including the trailing slash for the Issuer, such as
+
+```
+audience = "https://rs256.test.api",
+domain = "https://jerrie.auth0.com/"
+};
+```
+
+For a token signed using HS256, the debugger view will look a little different:
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png)
+
+In the screenshot above you can see that the token was signed using the **HS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://hs256.test.api**.
+
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_using.md b/ja-jp/articles/quickstart/backend/_includes/_api_using.md
new file mode 100644
index 0000000000..c85b97671b
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_using.md
@@ -0,0 +1,120 @@
+
+
+## Calling the API From Your Application
+
+You can call the API from your application by passing an Access Token in the `Authorization` header of your HTTP request as a Bearer token.
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+## Obtaining an Access Token
+
+If you are calling the API from a Single-Page Application or a Mobile/Native application, after the authorization flow is completed, you will get an Access Token. How you get the token and how you make the call to the API will be dependent on the type of application you are developing and the framework you are using. For more information refer to the relevant application Quickstarts which contain detailed instructions:
+
+* [Single-Page Applications](/quickstart/spa)
+* [Mobile / Native Application](/quickstart/native)
+
+If you are calling the API from a command-line tool or another service, where there isn't a user entering their credentials, you need to use the [OAuth Client Credentials flow](/api/authentication#client-credentials). To do that, register a [Machine to Machine Application](${manage_url}/#/applications), and then subsequently use the **Client ID** and **Client Secret** of this application when making the request below and pass those along in the `client_id` and `client_secret` parameters respectively. Also include the Audience for the API you want to call.
+
+:::note
+Read [Application Settings](https://auth0.com/docs/get-started/dashboard/application-settings) for more information on getting the Client ID and Client Secret for your machine-to-machine app.
+:::
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "client_credentials"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "audience",
+        "value": "YOUR_API_IDENTIFIER"
+      }
+    ]
+  }
+}
+```
+
+:::note
+Auth0 customers are billed based on the number of Machine to Machine Access Tokens issued by Auth0. Once your application gets an Access Token it should keep using it until it expires, to minimize the number of tokens requested.
+:::
+
+For testing purposes, you can also get an Access Token from the **Test** tab in your [API settings](${manage_url}/#/apis).
+
+## Test Your API 
+
+**1. Calling the secure endpoint**
+
+You can make a request to the `/api/private` endpoint without passing any Access Token:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private"
+}
+```
+
+The API will return a 401 HTTP (Unauthorized) status code:
+
+![Response for unauthorized API request](/media/articles/server-apis/using/private-unauthorized.png)
+
+Once again, make the same request but this time pass along the Access Token as a Bearer token in the **Authorization** header of the request:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+This time the API will return a successful response:
+
+![Response for authorized API request](/media/articles/server-apis/using/private.png)
+
+**2. Testing the scoped endpoint**
+
+To test the endpoint that requires a scope, pass the Access Token containing the correct scope as a Bearer token in the Authorization header:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private-scoped",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+If the required scope is present, the API call is successful:
+
+![Response for scoped API request](/media/articles/server-apis/using/private-scoped.png)
+
+If the required scope is not present, the API returns a 403 HTTP Status (Forbidden):
+
+![Response for forbidden scoped API request](/media/articles/server-apis/using/private-scoped-forbidden.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_call_api.md b/ja-jp/articles/quickstart/backend/_includes/_call_api.md
new file mode 100644
index 0000000000..eb4073dc35
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_call_api.md
@@ -0,0 +1,19 @@
+
+
+### Make a Call to Your API
+
+To make calls to your API, you need an Access Token. You can get an Access Token for testing purposes from the **Test** view in your [API settings](${manage_url}/#/apis).
+
+![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png)
+
+Provide the Access Token as an `Authorization` header in your requests.
+
+```har
+{
+  "method": "GET",
+  "url": "http://your-domain.com/api_path",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN_HERE" }
+  ]
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md b/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md
new file mode 100644
index 0000000000..2aa91865c6
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md
@@ -0,0 +1,3 @@
+## Update Notice
+
+This doc is currently being updated, please check back soon.
diff --git a/ja-jp/articles/quickstart/backend/_thirdPartyApi.md b/ja-jp/articles/quickstart/backend/_thirdPartyApi.md
new file mode 100644
index 0000000000..f8a12791b9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_thirdPartyApi.md
@@ -0,0 +1,24 @@
+# <%= meta.name %> API
+
+Please follow the steps below to configure your Auth0 tenant to work with <%= meta.name %>.
+
+## 1. Activate the add-on
+
+<% if (account.clientId) { %>
+Go to Application Add-ons page and activate the <%= meta.name %> add-on.
+<% } else { %>
+Go to Application Add-ons page and activate the <%= meta.name %> add-on.
+<% } %>
+
+
+![](/media/articles/server-apis/addons.png)
+
+Each integration is different and requires different parameters and configuration. Once the add-on is activated, you will see tailored instructions with details on how to get this done.
+
+## 2. Use it
+
+The key to this integration is the Delegation endpoint in Auth0. Check the documentation of any of our frontend or Mobile SDKs to learn how to call [the /delegation endpoint](/api/authentication#delegation). You can download your favorite library from any of the [Quickstarts](/).
+
+## 3. You are done!
+
+Congrats! You've implemented Delegation for the <%= meta.name %> API
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md
new file mode 100644
index 0000000000..f2fbe4fe37
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/01-authorization.md
@@ -0,0 +1,188 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to an ASP.NET Core Web API application using the standard JWT middleware.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - aspnetcore
+    - web-api
+github:
+    path: Quickstart/01-Authorization
+contentType: tutorial
+useCase: quickstart
+---
+
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Configure the Sample Project
+
+The sample code has an `appsettings.json` file which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page while logged in, it will be automatically filled. If you use the example from Github, you will need to fill it yourself.
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "Audience": "${apiIdentifier}"
+  }
+}
+```
+
+## Validate Access Tokens
+
+### Install dependencies
+
+The seed project already contains a reference to the `Microsoft.AspNetCore.Authentication.JwtBearer`, which is needed in order to validate Access Tokens.
+However, if you are not using the seed project, add the package to your application by installing it using Nuget:
+
+```text
+Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
+```
+
+### Configure the middleware
+
+The ASP.NET Core JWT Bearer authentication handler downloads the JSON Web Key Set (JWKS) file with the public key. The handler uses the JWKS file and the public key to verify the Access Token's signature.
+
+In your application, register the authentication services:
+
+1. Make a call to the `AddAuthentication` method. Configure `JwtBearerDefaults.AuthenticationScheme` as the default schemes.  
+2. Make a call to the `AddJwtBearer` method to register the JWT Bearer authentication scheme. Configure your Auth0 domain as the authority, and your Auth0 API identifier as the audience. In some cases the access token will not have a `sub` claim which will lead to `User.Identity.Name` being `null`. If you want to map a different claim to `User.Identity.Name` then add it to `options.TokenValidationParameters` within the `AddAuthentication()` call.
+
+```csharp
+// Program.cs
+var builder = WebApplication.CreateBuilder(args);
+var domain = $"https://{builder.Configuration["Auth0:Domain"]}/";
+builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
+.AddJwtBearer(options =>
+{
+    options.Authority = domain;
+    options.Audience = builder.Configuration["Auth0:Audience"];
+    options.TokenValidationParameters = new TokenValidationParameters
+    {
+        NameClaimType = ClaimTypes.NameIdentifier
+    };
+});
+```
+
+To add the authentication and authorization middleware to the middleware pipeline, add a call to the `UseAuthentication` and `UseAuthorization` methods in your Program.cs file:
+
+```csharp
+// Program.cs
+var app = builder.Build();
+
+app.UseAuthentication();
+app.UseAuthorization();
+app.UseEndpoints(endpoints =>
+{
+    endpoints.MapControllers();
+});
+```
+
+### Validate scopes
+
+To make sure that an Access Token contains the correct scope, use the [Policy-Based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) in ASP.NET Core.
+
+Create a new authorization requirement called `HasScopeRequirement`. This requirement checks if the `scope` claim issued by your Auth0 tenant is present. If the `scope` claim exists, the requirement checks if the `scope` claim contains the requested scope.
+
+```csharp
+// HasScopeRequirement.cs
+
+public class HasScopeRequirement : IAuthorizationRequirement
+{
+    public string Issuer { get; }
+    public string Scope { get; }
+
+    public HasScopeRequirement(string scope, string issuer)
+    {
+        Scope = scope ?? throw new ArgumentNullException(nameof(scope));
+        Issuer = issuer ?? throw new ArgumentNullException(nameof(issuer));
+    }
+}
+```
+
+```csharp
+// HasScopeHandler.cs
+
+public class HasScopeHandler : AuthorizationHandler
+{
+    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, HasScopeRequirement requirement)
+    {
+        // If user does not have the scope claim, get out of here
+        if (!context.User.HasClaim(c => c.Type == "scope" && c.Issuer == requirement.Issuer))
+            return Task.CompletedTask;
+
+        // Split the scopes string into an array
+        var scopes = context.User.FindFirst(c => c.Type == "scope" && c.Issuer == requirement.Issuer).Value.Split(' ');
+
+        // Succeed if the scope array contains the required scope
+        if (scopes.Any(s => s == requirement.Scope))
+            context.Succeed(requirement);
+
+        return Task.CompletedTask;
+    }
+}
+```
+
+In your Program.cs file, add a call to the `AddAuthorization` method. To add policies for the scopes, call `AddPolicy` for each scope. Also ensure that you register the `HasScopeHandler` as a singleton:
+
+```csharp
+// Program.cs
+
+builder.Services.AddAuthorization(options =>
+{
+    options.AddPolicy("read:messages", policy => policy.Requirements.Add(new 
+    HasScopeRequirement("read:messages", domain)));
+});
+
+builder.Services.AddSingleton();
+```
+
+## Protect API Endpoints
+
+The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/) and [Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/) mechanisms. 
+
+To secure an endpoint, you need to add the `[Authorize]` attribute to your controller action:
+
+```csharp
+// Controllers/ApiController.cs
+
+[Route("api")]
+[ApiController]
+public class ApiController : ControllerBase
+{
+    [HttpGet("private")]
+    [Authorize]
+    public IActionResult Private()
+    {
+        return Ok(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated to see this."
+        });
+    }
+}
+```
+
+To secure endpoints that require specific scopes, we need to make sure that the correct scope is present in the `access_token`. To do that, add the `Authorize` attribute to the `Scoped` action and pass `read:messages` as the `policy` parameter. 
+
+```csharp
+// Controllers/ApiController.cs
+
+[Route("api")]
+public class ApiController : Controller
+{
+    [HttpGet("private-scoped")]
+    [Authorize("read:messages")]
+    public IActionResult Scoped()
+    {
+        return Ok(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
+        });
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/02-using.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/02-using.md
new file mode 100644
index 0000000000..143001841d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/02-using.md
@@ -0,0 +1,14 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - aspnetcore
+    - web-api
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md
new file mode 100644
index 0000000000..5b80f0b41e
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/03-troubleshooting.md
@@ -0,0 +1,201 @@
+---
+title: Troubleshooting
+description: This document will help you troubleshoot your configuration if you get 401 (Unauthorized) response from your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - aspnetcore
+    - web-api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+If the configuration of your JSON Web Token (JWT) middleware does not match the JWT that was passed to the API, you get a 401 (Unauthorized) response from your API.
+
+This document will help you troubleshoot your JWT middleware configuration.
+
+## Check the Token Validation
+
+There are 5 criteria for validating a JWT token. 
+
+1. **Is the token formed properly?**
+Check if the structure of the token matches the structure of a JSON Web Token. Read more about the [JSON Web Token structure](/jwt#what-is-the-json-web-token-structure-).
+
+2. **Has the token been tampered with?** 
+The last part of a JWT is the signature. The signature is used to verify that the token was signed by the sender and not altered in any way.
+
+3. **Has the token been received in its validity period?**
+JWTs are only valid for a specified time, defined in the `exp` claim.
+
+4. **Is the token coming from the intended Authority?**
+Check the following two criteria: 
+
+    * **Signature verification**: Check if the JWT is correctly signed with the key issued by the issuing authority.
+
+    * **Issuer value**: The Issuer is defined in the `iss` claim. Check if this claim matches up with what your application expects.
+
+5. **Is the token intended for the current application?** 
+Check if the `aud` claim of the JWT matches with what your application expects.
+
+## Inspect a Token
+
+You can inspect a JWT with the [JWT.io](https://jwt.io/) website. Use the debugger on the website to check if your JWT is well formed. You can also inspect values of the various claims.
+
+The screenshot below shows the following information:
+* The token is signed with the RS256 algorithm
+* The issuer of the token is `https://jerrie.auth0.com/`
+* The audience of the token is `https://rs256.test.api`
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png)
+
+Check if the values of the JWT token match exactly the values in your JWT middleware registration. This includes the trailing slash for the Issuer.
+
+```csharp
+var options = new JwtBearerOptions
+{
+    Audience = "https://rs256.test.api",
+    Authority = "https://jerrie.auth0.com/"
+};
+app.UseJwtBearerAuthentication(options);
+```
+
+If your token is signed with the HS256 algorithm, the debugger view is different. 
+
+The screenshot below shows the following information:
+* The token is signed with the HS256 algorithm
+* The issuer of the token is `https://jerrie.auth0.com/`
+* The audience of the token is `https://hs256.test.api`
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png)
+
+If your token is signed with the HS256 algorithm, the middleware needs to be configured in the following way:
+
+```csharp
+var options = new JwtBearerOptions
+{
+    TokenValidationParameters =
+    {
+        ValidIssuer = "https://jerrie.auth0.com/",
+        ValidAudience = "https://hs256.test.api",
+        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your api secret"))
+    }
+};
+app.UseJwtBearerAuthentication(options);
+```
+
+## Debug Configuration Issues Using Log Files 
+
+To debug potential configuration issues, inspect the log files for your application. For more information, refer to the [Logging in ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging) document.
+
+In this example, we run the application from the command line and inspect the console log output.
+
+### 1. Are you passing the JWT in the Authorization header?
+
+Check if you are passing the JWT as a Bearer token in the `Authorization` header of the HTTP request.
+
+If you are not passing the token, you will see the following warning:
+
+![Not specifying an Authorization Header](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png)
+
+Look for the following warning message:
+
+```text
+Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'
+```
+
+To resolve this issue, make sure you are passing the JWT as the Bearer token in the `Authorization` header of the HTTP request.
+
+### 2. Did you configure the JWT middleware for the correct signing algorithm?
+
+Make sure that the [signing algorithm](/tokens/concepts/signing-algorithms) you used to sign your token matches the signing algorithm configured in your middleware. 
+
+The following screenshots show two messages:
+* A warning message: "Authorization failed..." 
+* A message with more information
+
+The following example shows that the JWT is signed with the HS256 algorithm and the middleware is configured to expect RS256 tokens:
+
+![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png)
+
+Look for the following warning message:
+
+```text
+System.ArgumentException: IDX10634: Unable to create the SignatureProvider.
+
+SignatureAlgorithm: 'HS256', SecurityKey: 'Microsoft.IdentityModel.Tokens.RsaSecurityKey' is not supported.
+```
+
+The following example shows that the JWT is signed with the RS256 algorithm and the middleware is configured to expect HS256 tokens:
+
+![Wrong Signature Configured](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png)
+
+Look for the following warning message:
+
+```text
+Bearer was not authenticated. Failure message: IDX10501: Signature validation failed. Unable to match 'kid': 'NTF...'
+```
+
+To resolve this issue, make sure that the algorithm for the JWT matches with the configuration of your middleware. 
+
+### 3. Has your token expired?
+
+Each JSON Web Token is valid until the time defined in the `exp` claim runs out. If you send an expired token, the token will be rejected:
+
+![Token Expired](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-token-expired.png)
+
+Look for the following error message:
+
+```text
+IDX10223: Lifetime validation failed. The token is expired
+```
+
+To resolve this issue, check if the token you are sending has not expired.
+
+::: note
+The value of the `exp` claim is a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time. If you want to see the date/time for the value, visit [EpochConverter](http://www.epochconverter.com/).
+:::
+
+### 4. Did you configure the correct issuer?
+
+The Issuer specified in your token must match exactly with your JWT middleware configuration. 
+
+![Issuer Validation Failed](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-issuer-validation-failed.png)
+
+Look for the following warning message:
+
+::: note
+You will get this message only for the tokens signed with the HS256 algorithm.
+:::
+
+```text
+IDX10205: Issuer validation failed.
+```
+
+To resolve this issue, make sure that you specify the correct issuer for your JWT middleware. 
+
+For HS256 signed tokens, specify the correct value for the `ValidIssuer` property of `TokenValidationParameters`.
+
+::: note
+For RS256 tokens, the JWT middleware downloads the OIDC discovery document from `Authority` and configures the Issuer based on the `issuer` attribute specified in that document. 
+
+If you are using RS256 tokens, the system checks their signature before it checks the Issuer.
+:::
+
+### 5. Does the audience match your JWT middleware configuration?
+
+Check if the audience specified in your token matches your JWT middleware configuration.
+
+![Audience Validation Failed](/media/articles/server-apis/aspnet-core-webapi/troubleshoot-audience-validation-failed.png)
+
+Look for the following error message:
+
+```text
+IDX10214: Audience validation failed
+```
+
+To resolve this issue, make sure you specify the correct audience for your JWT middleware. Depending on how your JWT middleware was configured, do the following:
+* Set the correct `Audience` property of `JwtBearerOptions`
+* Set the `ValidAudience` property of `TokenValidationParameters`
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/download.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/download.md
new file mode 100644
index 0000000000..667eb06da6
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/download.md
@@ -0,0 +1,15 @@
+To run the sample you need [.NET Core](https://www.microsoft.com/net/download) installed, and run the following commands:
+
+```bash
+dotnet restore
+dotnet run
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md
new file mode 100644
index 0000000000..2f9657aef0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/api-controller.md
@@ -0,0 +1,30 @@
+---
+name: ApiController.cs
+language: csharp
+---
+
+```csharp
+[Route("api")]
+public class ApiController : Controller
+{
+    [HttpGet("private")]
+    [Authorize]
+    public IActionResult Private()
+    {
+        return Ok(new
+        {
+            Message = "Hello from a private endpoint!"
+        });
+    }
+
+    [HttpGet("private-scoped")]
+    [Authorize("read:messages")]
+    public IActionResult Scoped()
+    {
+        return Ok(new
+        {
+            Message = "Hello from a private-scoped endpoint!"
+        });
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md
new file mode 100644
index 0000000000..ba8da8ddc4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/appsettings.md
@@ -0,0 +1,13 @@
+---
+name: appsettings.json
+language: json
+---
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "Audience": "${apiIdentifier}"
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md
new file mode 100644
index 0000000000..e2eea05829
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/configure-middleware.md
@@ -0,0 +1,35 @@
+---
+name: Program.cs
+language: csharp
+---
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
+.AddJwtBearer(options =>
+{
+    options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}/";
+    options.Audience = builder.Configuration["Auth0:Audience"];
+    options.TokenValidationParameters = new TokenValidationParameters
+    {
+        NameClaimType = ClaimTypes.NameIdentifier
+    };
+});
+
+    builder.Services
+      .AddAuthorization(options =>
+      {
+          options.AddPolicy(
+            "read:messages",
+            policy => policy.Requirements.Add(
+              new HasScopeRequirement("read:messages", domain)
+            )
+          );
+      });
+
+    builder.Services.AddSingleton();
+
+var app = builder.Build();
+app.UseAuthentication();
+app.UseAuthorization();
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md
new file mode 100644
index 0000000000..71b02ea80f
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-handler.md
@@ -0,0 +1,28 @@
+---
+name: HasScopeHandler.cs
+language: csharp
+---
+
+```csharp
+public class HasScopeHandler : AuthorizationHandler
+{
+  protected override Task HandleRequirementAsync(
+    AuthorizationHandlerContext context,
+    HasScopeRequirement requirement
+  ) {
+    // If user does not have the scope claim, get out of here
+    if (!context.User.HasClaim(c => c.Type == "scope" && c.Issuer == requirement.Issuer))
+      return Task.CompletedTask;
+
+    // Split the scopes string into an array
+    var scopes = context.User
+      .FindFirst(c => c.Type == "scope" && c.Issuer == requirement.Issuer).Value.Split(' ');
+
+    // Succeed if the scope array contains the required scope
+    if (scopes.Any(s => s == requirement.Scope))
+      context.Succeed(requirement);
+
+    return Task.CompletedTask;
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md
new file mode 100644
index 0000000000..f3481fc996
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/files/has-scope-requirement.md
@@ -0,0 +1,18 @@
+---
+name: HasScopeRequirement.cs
+language: csharp
+---
+
+```csharp
+public class HasScopeRequirement : IAuthorizationRequirement
+{
+    public string Issuer { get; }
+    public string Scope { get; }
+
+    public HasScopeRequirement(string scope, string issuer)
+    {
+        Scope = scope ?? throw new ArgumentNullException(nameof(scope));
+        Issuer = issuer ?? throw new ArgumentNullException(nameof(issuer));
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/index.yml b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/index.yml
new file mode 100644
index 0000000000..47a5ed7ab9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/index.yml
@@ -0,0 +1,55 @@
+title: ASP.NET Core Web API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet-platform
+alias:
+  - asp.net core webapi
+  - aspnet core webapi
+  - asp.net core webapi 6.0
+  - asp.net core webapi 7.0
+  - asp.net core webapi 8.0
+language:
+  - C#
+framework:
+  - ASP.NET Core
+author:
+  name: Damien Guard
+  email: damien.guard@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/aspnet-core-webapi/dependencies
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnetcore-webapi-samples
+  branch: master
+requirements:
+  - .NET 6.0
+  - .NET 7.0
+  - .NET 8.0
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/aspnet-core-webapi/interactive.md b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/interactive.md
new file mode 100644
index 0000000000..b4e7b4dea1
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/aspnet-core-webapi/interactive.md
@@ -0,0 +1,168 @@
+---
+title: Add Authorization to an ASP.NET Core Web API application
+description: This tutorial demonstrates how to add authorization to an ASP.NET Core Web API application using the standard JWT middleware.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - aspnetcore
+    - web-api
+github:
+    path: Quickstart/01-Authorization
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/appsettings
+  - files/configure-middleware
+  - files/has-scope-handler
+  - files/has-scope-requirement
+  - files/api-controller
+---
+
+# Add Authorization to Your ASP.NET Core Web API Application
+
+Auth0 allows you to add authentication and access user profile information in almost any application type quickly. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET Web API application using the `Microsoft.AspNetCore.Authentication.JwtBearer` package.
+
+If you haven't created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with. 
+
+Alternatively, you can [read our getting started guide](/get-started/auth0-overview/set-up-apis), which will help you set up your first API through the Auth0 Dashboard.
+
+Note that every API in Auth0 is configured using an API Identifier; your application code will use the API Identifier as the Audience to validate the access token.
+
+
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+## Install dependencies
+
+To allow your application to validate access tokens, add a reference to the `Microsoft.AspNetCore.Authentication.JwtBearer` Nuget package:
+
+```text
+Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
+```
+
+## Configure the middleware {{{ data-action=code data-code="Startup.cs" }}}
+
+Set up the authentication middleware by configuring it in your application's `Program.cs` file:
+
+1. Register the authentication services by making a call to the `AddAuthentication` method. Configure `JwtBearerDefaults.AuthenticationScheme` as the default scheme.
+ 
+2. Register the JWT Bearer authentication scheme by making a call to the `AddJwtBearer` method. Configure your Auth0 domain as the authority and your Auth0 API Identifier as the audience, and be sure that your Auth0 domain and API Identifier are set in your application's **appsettings.json** file. 
+
+:::note
+In some cases, the access token will not have a `sub` claim; in this case, the `User.Identity.Name` will be `null`. If you want to map a different claim to `User.Identity.Name`, add it to `options.TokenValidationParameters` within the `AddJwtBearer()` call.
+:::
+
+3. Add the authentication and authorization middleware to the middleware pipeline by adding calls to the `UseAuthentication` and `UseAuthorization` methods under the `var app = builder.Build();` method.
+
+## Validate scopes {{{ data-action=code data-code="HasScopeHandler.cs" }}}
+
+To ensure that an access token contains the correct scopes, use [Policy-Based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) in the ASP.NET Core:
+
+1. Create a new authorization requirement called `HasScopeRequirement`, which will check whether the `scope` claim issued by your Auth0 tenant is present, and if so, will check that the claim contains the requested scope.
+2. Under your `Program.cs` file's `var builder = WebApplication.CreateBuilder(args);` method, add a call to the `app.AddAuthorization` method.
+3. Add policies for scopes by calling `AddPolicy` for each scope.
+4. Register a singleton for the `HasScopeHandler` class.
+
+## Protect API endpoints {{{ data-action=code data-code="ApiController.cs" }}}
+
+The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/) and [Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/) mechanisms.
+
+To secure an endpoint, add the `[Authorize]` attribute to your controller action (or the entire controller if you want to protect all of its actions).
+
+When securing endpoints that require specific scopes, make sure that the correct scope is present in the `access_token`. To do so, add the `Authorize` attribute to the `Scoped` action and pass `read:messages` as the `policy` parameter.
+
+## Call your API
+
+The way in which you call your API depends on the type of application you are developing and the framework you are using. To learn more, read the relevant application Quickstart:
+
+* [Single-Page Applications](/quickstart/spa)
+* [Mobile / Native Application](/quickstart/native)
+
+### Get an access token
+
+Regardless of the type of application you are developing or the framework you are using, to call your API, you need an access token.
+
+If you are calling your API from a Single-Page Application (SPA) or a Native application, after the authorization flow completes, you will get an access token.
+
+If you are calling the API from a command-line tool or another service where a user entering credentials does not exist, use the [OAuth Client Credentials Flow](/api/authentication#client-credentials). To do so, register a [Machine-to-Machine Application](${manage_url}/#/applications), and pass in the **Client ID** as the `client_id` parameter, the **Client Secret** as the `client_secret` parameter, and the API Identifier (the same value you used to configure the middleware earlier in this quickstart) as the `audience` parameter when making the following request:
+
+:::note
+To learn more about getting the Client ID and Client Secret for your machine-to-machine application, read [Application Settings](/get-started/dashboard/application-settings).
+:::
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "client_credentials"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "audience",
+        "value": "${apiIdentifier}"
+      }
+    ]
+  }
+}
+```
+
+### Call a secure endpoint
+
+Now that you have an access token, you can use it to call secure API endpoints. When calling a secure endpoint, you must include the access token as a Bearer token in the **Authorization** header of the request. For example, you can make a request to the `/api/private` endpoint: 
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+Call the `/api/private-scoped` endpoint in a similar way, but ensure that the API permissions are configured correctly and that the access token includes the `read:messages` scope.
+
+::::checkpoint
+
+:::checkpoint-default
+You should now be able to call the `/api/private` and `/api/private-scoped` endpoints. 
+
+Run your application, and verify that:
+
+- `GET /api/private` is available for authenticated requests.
+- `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure `ValidIssuer` and `ValidAudience` are configured correctly
+- make sure the token is added as the `Authorization` header
+- check that the token has the correct scopes (you can use [jwt.io](https://jwt.io/) to verify)
+
+Still having issues? To get more help, check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com).
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/backend/config.yml b/ja-jp/articles/quickstart/backend/config.yml
new file mode 100644
index 0000000000..4f677dfe66
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - api
diff --git a/ja-jp/articles/quickstart/backend/django/01-authorization.md b/ja-jp/articles/quickstart/backend/django/01-authorization.md
new file mode 100644
index 0000000000..e4a427cddc
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/01-authorization.md
@@ -0,0 +1,276 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to a Django REST Framework API.
+topics:
+    - quickstart
+    - backend
+    - django
+github:
+    path: 01-Authorization
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Setup the Django Application
+
+### Install dependencies
+
+ Add the following dependencies to your `requirements.txt` and run `pip install -r requirements.txt`.
+
+```python
+cryptography~=2.8
+django~=2.2.7
+djangorestframework~=3.10.31
+django-cors-headers~=3.1.1
+drf-jwt~=1.13.3
+pyjwt~=1.7.1
+requests~=2.22.0
+```
+
+### Create a Django project
+
+This guide assumes you already have a Django application set up. If that is not the case, follow the steps in the [Django Tutorial](https://docs.djangoproject.com/en/2.2/intro/tutorial01/).
+
+The sample project was created with the following commands:
+
+```bash
+django-admin startproject apiexample
+cd apiexample
+python manage.py startapp auth0authorization
+```
+
+### Add a Django remote user
+
+You need to define a way to map the username from the Access Token payload to the Django authentication system user.
+
+Add [`RemoteUserMiddleware`](https://docs.djangoproject.com/en/2.2/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) middleware component after `AuthenticationMiddleware` to middleware list.
+
+```python
+# apiexample/settings.py
+
+MIDDLEWARE = [
+    # ...
+    'django.contrib.auth.middleware.AuthenticationMiddleware',
+    'django.contrib.auth.middleware.RemoteUserMiddleware',
+]
+```
+
+Add `ModelBackend` and `RemoteUserBackend` to the Authentication Backends.
+
+```python
+# apiexample/settings.py
+
+AUTHENTICATION_BACKENDS = [
+    'django.contrib.auth.backends.ModelBackend',
+    'django.contrib.auth.backends.RemoteUserBackend',
+]
+```
+
+Create `utils.py` file in your application's folder and define a function that maps the `sub` field from the `access_token` to the username. Then, the [authenticate](https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend.authenticate) method from [RemoteUserBackend](https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) will create a remote user in the Django authentication system and return a User object for the username.
+
+```python
+# auth0authorization/utils.py
+
+from django.contrib.auth import authenticate
+
+def jwt_get_username_from_payload_handler(payload):
+    username = payload.get('sub').replace('|', '.')
+    authenticate(remote_user=username)
+    return username
+```
+
+## Validate Access Tokens
+
+The `settings.py` file contains the configuration of the Django project.
+
+Add `rest_framework` app to the `INSTALLED_APPS` entry.
+
+```python
+# apiexample/settings.py
+
+INSTALLED_APPS = [
+    # ...
+    'rest_framework'
+]
+```
+
+Add `JSONWebTokenAuthentication` to Django REST framework's `DEFAULT_AUTHENTICATION_CLASSES`.
+
+```python
+# apiexample/settings.py
+
+REST_FRAMEWORK = {
+    'DEFAULT_PERMISSION_CLASSES': (
+        'rest_framework.permissions.IsAuthenticated',
+    ),
+    'DEFAULT_AUTHENTICATION_CLASSES': (
+        'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
+        'rest_framework.authentication.SessionAuthentication',
+        'rest_framework.authentication.BasicAuthentication',
+    ),
+}
+```
+
+Configure the [Django REST Framework JWK](https://github.com/Styria-Digital/django-rest-framework-jwt/) by setting the `JWT_AUTH` variable.
+
+Set the `JWT_AUDIENCE` to your API identifier and the `JWT_ISSUER` to your Auth0 domain. By default, those values will be retrieved from the `.env` file.
+
+```python
+# apiexample/settings.py
+
+JWT_AUTH = {
+    'JWT_PAYLOAD_GET_USERNAME_HANDLER':
+        'auth0authorization.utils.jwt_get_username_from_payload_handler',
+    'JWT_DECODE_HANDLER':
+        'auth0authorization.utils.jwt_decode_token',
+    'JWT_ALGORITHM': 'RS256',
+    'JWT_AUDIENCE': '${apiIdentifier}',
+    'JWT_ISSUER': 'https://${account.namespace}/',
+    'JWT_AUTH_HEADER_PREFIX': 'Bearer',
+}
+```
+
+Create the function to fetch the JWKS from your Auth0 account to verify and decode the incoming Access Token.
+
+```python
+# auth0authorization/utils.py
+
+import json
+
+import jwt
+import requests
+
+def jwt_decode_token(token):
+    header = jwt.get_unverified_header(token)
+    jwks = requests.get('https://{}/.well-known/jwks.json'.format('${account.namespace}')).json()
+    public_key = None
+    for jwk in jwks['keys']:
+        if jwk['kid'] == header['kid']:
+            public_key = jwt.algorithms.RSAAlgorithm.from_jwk(json.dumps(jwk))
+
+    if public_key is None:
+        raise Exception('Public key not found.')
+
+    issuer = 'https://{}/'.format('${account.namespace}')
+    return jwt.decode(token, public_key, audience='${apiIdentifier}', issuer=issuer, algorithms=['RS256'])
+```
+
+### Validate scopes
+
+Add the following methods to the `views.py` file to create a decorator that will check the granted scopes from the `access_token`.
+
+```python
+# auth0authorization/views.py
+
+from functools import wraps
+import jwt
+
+from django.http import JsonResponse
+
+def get_token_auth_header(request):
+    """Obtains the Access Token from the Authorization Header
+    """
+    auth = request.META.get("HTTP_AUTHORIZATION", None)
+    parts = auth.split()
+    token = parts[1]
+
+    return token
+
+def requires_scope(required_scope):
+    """Determines if the required scope is present in the Access Token
+    Args:
+        required_scope (str): The scope required to access the resource
+    """
+    def require_scope(f):
+        @wraps(f)
+        def decorated(*args, **kwargs):
+            token = get_token_auth_header(args[0])
+            decoded = jwt.decode(token, verify=False)
+            if decoded.get("scope"):
+                token_scopes = decoded["scope"].split()
+                for token_scope in token_scopes:
+                    if token_scope == required_scope:
+                        return f(*args, **kwargs)
+            response = JsonResponse({'message': 'You don\'t have access to this resource'})
+            response.status_code = 403
+            return response
+        return decorated
+    return require_scope
+```
+
+## Protect API Endpoints 
+
+<%= include('../_includes/_api_endpoints') %>
+
+In the file `views.py` add `public` and `private` endpoints. Add the `@api_view` decorator to all the endpoints to indicate that the method requires authentication. Lastly, add the decorator `@permission_classes([AllowAny])` to the `public` endpoint to accept unauthenticated requests.
+
+```python
+# auth0authorization/views.py
+
+from django.http import JsonResponse
+from rest_framework.decorators import api_view, permission_classes
+from rest_framework.permissions import AllowAny
+
+@api_view(['GET'])
+@permission_classes([AllowAny])
+def public(request):
+    return JsonResponse({'message': 'Hello from a public endpoint! You don\'t need to be authenticated to see this.'})
+
+
+@api_view(['GET'])
+def private(request):
+    return JsonResponse({'message': 'Hello from a private endpoint! You need to be authenticated to see this.'})
+```
+
+Use the `requires_scope` decorator in the methods that require specific scopes granted. The method below requires the `read:messages` scope granted.
+
+```python
+# auth0authorization/views.py
+
+@api_view(['GET'])
+@requires_scope('read:messages')
+def private_scoped(request):
+    return JsonResponse({'message': 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.'})
+```
+
+### Add URL mappings
+
+In previous steps, we added methods to the `views.py` file. We need to map those methods to URLs.
+
+Django has a [URL dispatcher](https://docs.djangoproject.com/en/2.2/topics/http/urls/) that lets you map URL patterns to views.
+
+Create the file `urls.py` in your application folder. Add the URL patterns.
+
+```python
+# auth0authorization/urls.py
+
+from django.urls import path
+
+from . import views
+
+urlpatterns = [
+    path('api/public', views.public),
+    path('api/private', views.private),
+    path('api/private-scoped', views.private_scoped),
+]
+```
+
+The Django project also has a `urls.py` file. Add a reference to your application's `urls.py` file.
+
+```python
+# apiexample/urls.py
+
+from django.contrib import admin
+from django.urls import include, path
+
+urlpatterns = [
+    path('admin/', admin.site.urls),
+    path('', include('auth0authorization.urls'))
+]
+```
diff --git a/ja-jp/articles/quickstart/backend/django/02-using.md b/ja-jp/articles/quickstart/backend/django/02-using.md
new file mode 100644
index 0000000000..00fd101849
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - django
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %> 
diff --git a/ja-jp/articles/quickstart/backend/django/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/django/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/django/download.md b/ja-jp/articles/quickstart/backend/django/download.md
new file mode 100644
index 0000000000..e50de77b51
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/download.md
@@ -0,0 +1,16 @@
+To run it from the command line:
+
+```bash
+pip install -r requirements.txt
+python manage.py migrate 
+python manage.py runserver 3010
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/django/files/urls.md b/ja-jp/articles/quickstart/backend/django/files/urls.md
new file mode 100644
index 0000000000..f5a6dc9e24
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/urls.md
@@ -0,0 +1,20 @@
+---
+name: apiexample/urls.py
+language: python
+---
+
+
+
+```python
+from django.contrib import admin
+from django.urls import path
+from . import views
+
+
+urlpatterns = [
+    path('admin/', admin.site.urls),
+    path('api/public', views.public),
+    path('api/private', views.private),
+    path('api/private-scoped', views.private_scoped)
+]
+```
diff --git a/ja-jp/articles/quickstart/backend/django/files/validator.md b/ja-jp/articles/quickstart/backend/django/files/validator.md
new file mode 100644
index 0000000000..839a4e5abf
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/validator.md
@@ -0,0 +1,31 @@
+---
+name: apiexample/validator.py
+language: python
+---
+
+
+
+```python
+import json
+from urllib.request import urlopen
+
+from authlib.oauth2.rfc7523 import JWTBearerTokenValidator
+from authlib.jose.rfc7517.jwk import JsonWebKey
+
+
+class Auth0JWTBearerTokenValidator(JWTBearerTokenValidator):
+    def __init__(self, domain, audience):
+        issuer = f"https://{domain}/"
+        jsonurl = urlopen(f"{issuer}.well-known/jwks.json")
+        public_key = JsonWebKey.import_key_set(
+            json.loads(jsonurl.read())
+        )
+        super(Auth0JWTBearerTokenValidator, self).__init__(
+            public_key
+        )
+        self.claims_options = {
+            "exp": {"essential": True},
+            "aud": {"essential": True, "value": audience},
+            "iss": {"essential": True, "value": issuer},
+        }
+```
diff --git a/ja-jp/articles/quickstart/backend/django/files/views.md b/ja-jp/articles/quickstart/backend/django/files/views.md
new file mode 100644
index 0000000000..b44ec9baed
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/files/views.md
@@ -0,0 +1,42 @@
+---
+name: apiexample/views.py
+language: python
+---
+
+
+
+```python
+from authlib.integrations.django_oauth2 import ResourceProtector
+from django.http import JsonResponse
+from . import validator
+
+require_auth = ResourceProtector()
+validator = validator.Auth0JWTBearerTokenValidator(
+    "${account.namespace}",
+    "${apiIdentifier}"
+)
+require_auth.register_token_validator(validator)
+
+
+def public(request):
+    """No access token required to access this route
+    """
+    response = "Hello from a public endpoint! You don't need to be authenticated to see this."
+    return JsonResponse(dict(message=response))
+
+
+@require_auth(None)
+def private(request):
+    """A valid access token is required to access this route
+    """
+    response = "Hello from a private endpoint! You need to be authenticated to see this."
+    return JsonResponse(dict(message=response))
+
+
+@require_auth("read:messages")
+def private_scoped(request):
+    """A valid access token and an appropriate scope are required to access this route
+    """
+    response = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
+    return JsonResponse(dict(message=response))
+```
diff --git a/ja-jp/articles/quickstart/backend/django/index.yml b/ja-jp/articles/quickstart/backend/django/index.yml
new file mode 100644
index 0000000000..67bb80cabe
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/index.yml
@@ -0,0 +1,53 @@
+title: Django API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/django.png
+logo: django
+alias:
+  - Django
+languages:
+  - Python
+author:
+  name: Luciano Balmaceda
+  email: luciano.balmaceda@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/django/dependencies
+  setup: server-apis/django/setup
+  use: server-apis/django/use
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+seo_alias: django
+default_article: 01-authorization
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-django-api
+requirements:
+  - Python 3.5 and up
+  - Django 2.2.*
+  - djangorestframework 3.10.*
+  - drf-jwt 1.13.*
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/django/interactive.md b/ja-jp/articles/quickstart/backend/django/interactive.md
new file mode 100644
index 0000000000..3d4301e943
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/django/interactive.md
@@ -0,0 +1,88 @@
+---
+title: Add Authorization to a Django API Application
+description: This tutorial demonstrates how to add authorization to a Python API built with Django.
+interactive: true
+files:
+  - files/validator
+  - files/views
+  - files/urls
+github:
+  - path: 01-Authorization
+  - branch: py-vnext
+---
+
+
+
+# Add Authorization to Your Django API Application
+
+This guide demonstrates how to integrate Auth0 with any new or existing Python API built with [Django](https://www.djangoproject.com/).
+
+If you haven't created an API in your Auth0 Dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with.
+
+Alternatively, you can read our [getting started guide](/get-started/auth0-overview/set-up-apis), which will help you set up your first API through the Auth0 Dashboard.
+
+Every API in Auth0 is configured using an API Identifier that your application code will use as the Audience to validate the Access Token.
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+# Configure Django to use Auth0
+
+## Install dependencies
+
+1. Add the following dependencies to your `requirements.txt`:
+
+```python
+# /requirements.txt
+
+Authlib~=1.0.0
+Django~=4.0.3
+python-dotenv~=0.19.2
+```
+
+2. Run `pip install -r requirements.txt`
+
+### Create a Django application
+
+```shell
+django-admin startproject apiexample
+cd apiexample
+```
+
+## Create the JWT validator {{{ data-action=code data-code="apiexample/validator.py" }}}
+
+You're going to use a library called [Authlib](https://github.com/lepture/authlib) to create a [ResourceProtector](https://docs.authlib.org/en/latest/flask/1/resource-server.html), which is a type of [Django view decorator](https://docs.djangoproject.com/en/4.0/topics/http/decorators/) that protects your resources (API views) with a given validator.
+
+The validator will verify the Access Token that you pass to the resource by checking that it has a valid signature and claims.
+
+You can use AuthLib's `JWTBearerTokenValidator` validator with a few tweaks to make sure it conforms to our requirements on [validating Access Tokens](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens).
+
+To create your `Auth0JWTBearerTokenValidator`, you need to pass it your `domain` and `audience` (API Identifier). It will then get the public key required to verify the token's signature and pass it to the `JWTBearerTokenValidator` class.
+
+You'll then override the class's `claims_options` to make sure the token's `expiry`, `audience`, and `issue` claims are validated according to our requirements.
+
+Create the file `apiexample/validator.py` using the code from the interactive panel.
+
+## Create the API views {{{ data-action=code data-code="apiexample/views.py" }}}
+
+Next, you'll create three API views in `apiexample/views.py`:
+
+- `/api/public`: A public endpoint that requires no authentication.
+- `/api/private`: A private endpoint that requires a valid Access Token JWT.
+- `/api/private-scoped`: A private endpoint that requires a valid Access Token JWT containing the given `scope`.
+
+The protected routes will have a `require_auth` decorator, which is a `ResourceProtector` that uses the `Auth0JWTBearerTokenValidator` you created earlier.
+
+To create the `Auth0JWTBearerTokenValidator`, you'll pass it your tenant's domain and the API Identifier of the API you created earlier.
+
+The `require_auth` decorator on the `private_scoped` route accepts an additional argument `"read:messages"`, which checks the Access Token for the Permission (Scope) you created earlier.
+
+## Add URL mappings {{{ data-action=code data-code="apiexample/urls.py#8:10" }}}
+
+In previous steps, you added methods to the `views.py` file. You need to map those methods to URLs using Django's [URL dispatcher](https://docs.djangoproject.com/en/4.0/topics/http/urls/), which lets you map URL patterns to views.
+
+Add the URL patterns to `apiexample/urls.py`:
+
+<%= include('../_includes/_call_api') %>
diff --git a/ja-jp/articles/quickstart/backend/golang/01-authorization.md b/ja-jp/articles/quickstart/backend/golang/01-authorization.md
new file mode 100644
index 0000000000..8fa1a0a938
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/01-authorization.md
@@ -0,0 +1,257 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to a Go API.
+topics:
+    - quickstart
+    - backend
+    - golang
+github:
+  path: 01-Authorization-RS256
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Validate Access Tokens
+
+### Download dependencies
+
+Add a `go.mod` file to list all the dependencies to be used.
+
+```text
+// go.mod
+
+module 01-Authorization-RS256
+
+go 1.21
+
+require (
+	github.com/auth0/go-jwt-middleware/v2 v2.2.0
+	github.com/joho/godotenv v1.5.1
+)
+```
+
+Download dependencies by running the following shell command:
+
+```shell
+go mod download
+```
+
+### Configure your application
+
+Create a `.env` file within the root of your project directory to store the app configuration, and fill in the
+environment variables:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 API's Identifier.
+AUTH0_AUDIENCE='YOUR_API_IDENTIFIER'
+```
+
+### Create a middleware to validate Access Tokens
+
+Access Token validation will be done in the `EnsureValidToken` middleware function which can be applied to any 
+endpoints you wish to protect. If the token is valid, the resources which are served by the endpoint can be released,
+otherwise a `401 Authorization` error will be returned.
+
+Setup **go-jwt-middleware** middleware to verify Access Tokens from incoming requests.
+
+```go
+// middleware/jwt.go
+
+package middleware
+
+import (
+	"context"
+	"log"
+	"net/http"
+	"net/url"
+	"os"
+	"time"
+
+	jwtmiddleware "github.com/auth0/go-jwt-middleware/v2"
+	"github.com/auth0/go-jwt-middleware/v2/jwks"
+	"github.com/auth0/go-jwt-middleware/v2/validator"
+)
+
+// CustomClaims contains custom data we want from the token.
+type CustomClaims struct {
+	Scope string `json:"scope"`
+}
+
+// Validate does nothing for this example, but we need
+// it to satisfy validator.CustomClaims interface.
+func (c CustomClaims) Validate(ctx context.Context) error {
+	return nil
+}
+
+// EnsureValidToken is a middleware that will check the validity of our JWT.
+func EnsureValidToken() func(next http.Handler) http.Handler {
+	issuerURL, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/")
+	if err != nil {
+		log.Fatalf("Failed to parse the issuer url: %v", err)
+	}
+
+	provider := jwks.NewCachingProvider(issuerURL, 5*time.Minute)
+
+	jwtValidator, err := validator.New(
+		provider.KeyFunc,
+		validator.RS256,
+		issuerURL.String(),
+		[]string{os.Getenv("AUTH0_AUDIENCE")},
+		validator.WithCustomClaims(
+			func() validator.CustomClaims {
+				return &CustomClaims{}
+			},
+		),
+		validator.WithAllowedClockSkew(time.Minute),
+	)
+	if err != nil {
+		log.Fatalf("Failed to set up the jwt validator")
+	}
+
+	errorHandler := func(w http.ResponseWriter, r *http.Request, err error) {
+		log.Printf("Encountered error while validating JWT: %v", err)
+
+		w.Header().Set("Content-Type", "application/json")
+		w.WriteHeader(http.StatusUnauthorized)
+		w.Write([]byte(`{"message":"Failed to validate JWT."}`))
+	}
+
+	middleware := jwtmiddleware.New(
+		jwtValidator.ValidateToken,
+		jwtmiddleware.WithErrorHandler(errorHandler),
+	)
+
+	return func(next http.Handler) http.Handler {
+		return middleware.CheckJWT(next)
+	}
+}
+```
+
+<%= include('../_includes/_api_jwks_description') %>
+
+
+## Protect API Endpoints
+
+To protect individual routes, pass `middleware` (defined above) to the http route.
+
+```go
+// main.go
+
+package main
+
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
+
+	"01-Authorization-RS256/middleware"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Error loading the .env file: %v", err)
+	}
+
+	router := http.NewServeMux()
+
+	// This route is always accessible.
+	router.Handle("/api/public", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		w.Header().Set("Content-Type", "application/json")
+		w.WriteHeader(http.StatusOK)
+		w.Write([]byte(`{"message":"Hello from a public endpoint! You don't need to be authenticated to see this."}`))
+	}))
+
+	// This route is only accessible if the user has a valid access_token.
+	router.Handle("/api/private", middleware.EnsureValidToken()(
+		http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+			// CORS Headers.
+			w.Header().Set("Access-Control-Allow-Credentials", "true")
+			w.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000")
+			w.Header().Set("Access-Control-Allow-Headers", "Authorization")
+
+			w.Header().Set("Content-Type", "application/json")
+			w.WriteHeader(http.StatusOK)
+			w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`))
+		}),
+	))
+
+	log.Print("Server listening on http://localhost:3010")
+	if err := http.ListenAndServe("0.0.0.0:3010", router); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+```
+
+### Validate scopes
+
+The `middleware` above verifies that the Access Token included in the request is valid; however, it doesn't yet include
+any mechanism for checking that the token has the sufficient **scope** to access the requested resources.
+
+Create a function to check and ensure the Access Token has the correct scope before returning a successful response.
+
+```go
+// 👆 We're continuing from the steps above. Append this to your middleware/jwt.go file.
+
+// HasScope checks whether our claims have a specific scope.
+func (c CustomClaims) HasScope(expectedScope string) bool {
+    result := strings.Split(c.Scope, " ")
+    for i := range result {
+        if result[i] == expectedScope {
+            return true
+        }
+    }
+
+    return false
+}
+```
+
+Use this function in the endpoint that requires the scope `read:messages`.
+
+```go
+// 👆 We're continuing from the steps above. Append this to your main.go file.
+
+func main() {
+    // ...
+    
+    // This route is only accessible if the user has a
+    // valid access_token with the read:messages scope.
+	router.Handle("/api/private-scoped", middleware.EnsureValidToken()(
+		http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+			// CORS Headers.
+			w.Header().Set("Access-Control-Allow-Credentials", "true")
+			w.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000")
+			w.Header().Set("Access-Control-Allow-Headers", "Authorization")
+
+			w.Header().Set("Content-Type", "application/json")
+
+			token := r.Context().Value(jwtmiddleware.ContextKey{}).(*validator.ValidatedClaims)
+
+			claims := token.CustomClaims.(*middleware.CustomClaims)
+			if !claims.HasScope("read:messages") {
+				w.WriteHeader(http.StatusForbidden)
+				w.Write([]byte(`{"message":"Insufficient scope."}`))
+				return
+			}
+
+			w.WriteHeader(http.StatusOK)
+			w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`))
+		}),
+	))
+    
+    // ...
+}
+```
+
+In this example, only the `read:messages` scope is checked. You may want to extend the `HasScope` function or make it
+a standalone middleware that accepts multiple scopes to fit your use case.
diff --git a/ja-jp/articles/quickstart/backend/golang/02-using.md b/ja-jp/articles/quickstart/backend/golang/02-using.md
new file mode 100644
index 0000000000..bb649cc040
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - golang
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
diff --git a/ja-jp/articles/quickstart/backend/golang/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/golang/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/golang/download.md b/ja-jp/articles/quickstart/backend/golang/download.md
new file mode 100644
index 0000000000..a33eed6906
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/download.md
@@ -0,0 +1,15 @@
+To run it from the command line:
+
+```bash
+go mod vendor
+go run main.go
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/backend/golang/files/jwt.md b/ja-jp/articles/quickstart/backend/golang/files/jwt.md
new file mode 100644
index 0000000000..d9aba4c4f1
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/files/jwt.md
@@ -0,0 +1,90 @@
+---
+name: middleware/jwt.go
+language: go
+---
+
+
+
+```go
+package middleware
+
+import (
+	"context"
+	"log"
+	"net/http"
+	"net/url"
+	"os"
+	"strings"
+	"time"
+
+	jwtmiddleware "github.com/auth0/go-jwt-middleware/v2"
+	"github.com/auth0/go-jwt-middleware/v2/jwks"
+	"github.com/auth0/go-jwt-middleware/v2/validator"
+)
+
+// CustomClaims contains custom data we want from the token.
+type CustomClaims struct {
+	Scope string `json:"scope"`
+}
+
+// Validate does nothing for this example, but we need
+// it to satisfy validator.CustomClaims interface.
+func (c CustomClaims) Validate(ctx context.Context) error {
+	return nil
+}
+
+// EnsureValidToken is a middleware that will check the validity of our JWT.
+func EnsureValidToken() func(next http.Handler) http.Handler {
+	issuerURL, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/")
+	if err != nil {
+		log.Fatalf("Failed to parse the issuer url: %v", err)
+	}
+
+	provider := jwks.NewCachingProvider(issuerURL, 5*time.Minute)
+
+	jwtValidator, err := validator.New(
+		provider.KeyFunc,
+		validator.RS256,
+		issuerURL.String(),
+		[]string{os.Getenv("AUTH0_AUDIENCE")},
+		validator.WithCustomClaims(
+			func() validator.CustomClaims {
+				return &CustomClaims{}
+			},
+		),
+		validator.WithAllowedClockSkew(time.Minute),
+	)
+	if err != nil {
+		log.Fatalf("Failed to set up the jwt validator")
+	}
+
+	errorHandler := func(w http.ResponseWriter, r *http.Request, err error) {
+		log.Printf("Encountered error while validating JWT: %v", err)
+
+		w.Header().Set("Content-Type", "application/json")
+		w.WriteHeader(http.StatusUnauthorized)
+		w.Write([]byte(`{"message":"Failed to validate JWT."}`))
+	}
+
+	middleware := jwtmiddleware.New(
+		jwtValidator.ValidateToken,
+		jwtmiddleware.WithErrorHandler(errorHandler),
+	)
+
+	return func(next http.Handler) http.Handler {
+		return middleware.CheckJWT(next)
+	}
+}
+
+// HasScope checks whether our claims have a specific scope.
+func (c CustomClaims) HasScope(expectedScope string) bool {
+	result := strings.Split(c.Scope, " ")
+	for i := range result {
+		if result[i] == expectedScope {
+			return true
+		}
+	}
+
+	return false
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/golang/files/main.md b/ja-jp/articles/quickstart/backend/golang/files/main.md
new file mode 100644
index 0000000000..5e8d5498df
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/files/main.md
@@ -0,0 +1,70 @@
+---
+name: main.go
+language: go
+---
+
+
+
+```go
+package main
+
+import (
+	"01-Authorization-RS256/middleware"
+	"log"
+	"net/http"
+
+	jwtmiddleware "github.com/auth0/go-jwt-middleware/v2"
+	"github.com/auth0/go-jwt-middleware/v2/validator"
+	"github.com/joho/godotenv"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Error loading the .env file: %v", err)
+	}
+
+	router := http.NewServeMux()
+
+	// This route is always accessible.
+	router.Handle("/api/public", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		w.Header().Set("Content-Type", "application/json")
+		w.WriteHeader(http.StatusOK)
+		w.Write([]byte(`{"message":"Hello from a public endpoint! You don't need to be authenticated to see this."}`))
+	}))
+
+	// This route is only accessible if the user has a valid access_token.
+	router.Handle("/api/private", middleware.EnsureValidToken()(
+		http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+			w.Header().Set("Content-Type", "application/json")
+			w.WriteHeader(http.StatusOK)
+			w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`))
+		}),
+	))
+
+	// This route is only accessible if the user has a
+	// valid access_token with the read:messages scope.
+	router.Handle("/api/private-scoped", middleware.EnsureValidToken()(
+		http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+			w.Header().Set("Content-Type", "application/json")
+
+			token := r.Context().Value(jwtmiddleware.ContextKey{}).(*validator.ValidatedClaims)
+
+			claims := token.CustomClaims.(*middleware.CustomClaims)
+			if !claims.HasScope("read:messages") {
+				w.WriteHeader(http.StatusForbidden)
+				w.Write([]byte(`{"message":"Insufficient scope."}`))
+				return
+			}
+
+			w.WriteHeader(http.StatusOK)
+			w.Write([]byte(`{"message":"Hello from a private endpoint! You need to be authenticated to see this."}`))
+		}),
+	))
+
+	log.Print("Server listening on http://localhost:3010")
+	if err := http.ListenAndServe("0.0.0.0:3010", router); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+
+```
diff --git a/ja-jp/articles/quickstart/backend/golang/index.yml b/ja-jp/articles/quickstart/backend/golang/index.yml
new file mode 100644
index 0000000000..08e116eafa
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/index.yml
@@ -0,0 +1,54 @@
+title: Go API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/golang.png
+logo: golang
+thirdParty: false
+alias:
+  - go
+  - golang
+languages:
+  - Go
+author:
+  name: Sergiu Ghitea
+  email: sergiu.ghitea@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/golang/dependencies
+  setup: server-apis/golang/setup
+  use: server-apis/golang/use
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+default_article: 01-authorization
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-golang-api-samples
+sdk:
+  name: go-jwt-middleware
+  url: https://github.com/auth0/go-jwt-middleware
+  logo: golang
+requirements:
+  - Go 1.21+
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/golang/interactive.md b/ja-jp/articles/quickstart/backend/golang/interactive.md
new file mode 100644
index 0000000000..3493a2b987
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/golang/interactive.md
@@ -0,0 +1,114 @@
+---
+title: Add authorization to a Go API
+description: This tutorial demonstrates how to add authorization to a Go API.
+topics:
+  - quickstart
+  - backend
+  - golang
+interactive: true
+github:
+  path: 01-Authorization-RS256
+contentType: tutorial
+useCase: quickstart
+files:
+  - files/jwt
+  - files/main
+---
+
+
+
+# Add Authorization to Your Go Application
+This guide demonstrates how to integrate Auth0 with any new or existing Go API application using the [go-jwt-middleware](https://github.com/auth0/go-jwt-middleware) package.
+
+If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API for your project.
+
+To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis).
+
+Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+## Install dependencies
+
+Add a `go.mod` file to list all the necessary dependencies.
+
+```text
+// go.mod
+
+module 01-Authorization-RS256
+
+go 1.21
+
+require (
+	github.com/auth0/go-jwt-middleware/v2 v2.2.0
+	github.com/joho/godotenv v1.5.1
+)
+```
+
+Download dependencies by running the following shell command:
+
+```shell
+go mod download
+```
+
+## Configure your application
+
+Create a `.env` file within the root of your project directory to store the app configuration, and fill in the
+environment variables:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 API's Identifier.
+AUTH0_AUDIENCE='${apiIdentifier}'
+```
+
+## Create a middleware to validate access tokens {{{ data-action=code data-code="middleware/jwt.go" }}}
+
+The `EnsureValidToken` middleware function validates the access token. You can apply this function to any endpoints you wish to protect.
+If the token is valid, the endpoint releases the resources. If the token is not valid, the API returns a `401 Authorization` error.
+
+Setup the **go-jwt-middleware** middleware to verify access tokens from incoming requests.
+
+<%= include('../_includes/_api_jwks_description_no_link') %>
+
+Include a mechanism to check that the token has sufficient **scope** to access the requested resources.
+
+
+Create a function `HasScope` to check and ensure the access token has the correct scope before returning a successful response.
+
+## Protect API endpoints {{{ data-action=code data-code="main.go" }}}
+
+In this example, create an `/api/public` endpoint that does not use the `EnsureToken` middleware as it is accessible to non-authenticated requests.
+
+Create an `/api/private` endpoint that requires the `EnsureToken` middleware as it is only available to authenticated requests containing an access token with no additional scope.
+
+Create an `/api/private-scoped` endpoint that requires the `EnsureToken` middleware and `HasScope` as it is only available for authenticated requests containing an access token with the `read:messages` scope granted.
+
+::: note
+Only the `read:messages` scope is checked by the `HasScope` function, you may want to extend it or make it a standalone middleware that accepts multiple scopes to fit your use case.
+:::
+
+<%= include('../_includes/_call_api') %>
+
+::::checkpoint
+:::checkpoint-default
+Now that you have configured your application, run your application to verify that:
+* `GET /api/public` is available for non-authenticated requests.
+* `GET /api/private` is available for authenticated requests.
+* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify you added the token as the `Authorization` header
+* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/).
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/01-authorization.md b/ja-jp/articles/quickstart/backend/java-spring-security5/01-authorization.md
new file mode 100644
index 0000000000..fa3cf07bb4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/01-authorization.md
@@ -0,0 +1,205 @@
+---
+title: Authorization
+name: How to secure your API with Spring Boot
+description: This tutorial demonstrates how to add authorization to an API using the Okta Spring Boot Starter.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - java
+    - spring-security
+github:
+    path: 01-Authorization-MVC
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+::: note
+This Quickstart uses Spring MVC. If you are using Spring WebFlux, the steps to secure an API are similar, but some of the implementation details are different. Refer to the [Spring Security WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-security5-api-sample/tree/master/01-Authorization-WebFlux) to see how to integrate Auth0 with your Spring WebFlux API.
+:::
+
+
+<%= include('../_includes/_api_create_new') %>
+
+## Configure the Sample Project
+
+The sample project uses a `/src/main/resources/application.yml` file, which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page it will be automatically configured. If you clone the example from GitHub, you will need to fill it in yourself.
+
+```yaml
+okta:
+  oauth2:
+    # Replace with the domain of your Auth0 tenant.
+    issuer: https://${account.namespace}/
+    # Replace with the API Identifier for your Auth0 API.
+    audience: ${apiIdentifier}
+```
+
+| Attribute | Description|
+| --- | --- |
+| `okta.oauth2.audience` | The unique identifier for your API. If you are following the steps in this tutorial it would be `https://quickstarts/api`. |
+| `okta.oauth2.issuer` | The issuer URI of the resource server, which will be the value of the `iss` claim in the JWT issued by Auth0. Spring Security will use this property to discover the authorization server's public keys and validate the JWT signature. The value will be your Auth0 domain with an `https://` prefix and a `/` suffix (the trailing slash is important). |
+
+## Install dependencies
+
+If you are using Gradle, you can add the required dependencies using the [Spring Boot Gradle Plugin](https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/) and the [Dependency Management Plugin](https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/) to resolve dependency versions:
+
+```groovy
+// build.gradle
+
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.5'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+dependencies {
+    implementation 'org.springframework.boot:spring-boot-starter-web'
+    implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+}
+```
+
+If you are using Maven, add the Spring dependencies to your `pom.xml` file:
+
+```xml
+// pom.xml
+
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.5
+    
+
+
+
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        com.okta
+        okta-spring-boot-starter
+        3.0.5
+    
+
+```
+
+## Protect API endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+To configure the application as a Resource Server and validate the JWTs, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), an instance of `SecurityFilterChain`, and add the `@Configuration` annotation.
+
+The example below shows how to secure API methods using the `HttpSecurity` object provided in the `filterChain()` method of the `SecurityConfig` class. Route matchers are used to restrict access based on the level of authorization required:
+
+```java
+// src/main/java/com/auth0/example/security/SecurityConfig.java
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
+        http.authorizeRequests()
+                .mvcMatchers("/api/public").permitAll()
+                .mvcMatchers("/api/private").authenticated()
+                .mvcMatchers("/api/private-scoped").hasAuthority("SCOPE_read:messages")
+                .and().cors()
+                .and().oauth2ResourceServer().jwt();
+        return http.build();
+    }
+}
+```
+
+::: note
+By default, Spring Security will create a `GrantedAuthority` for each scope in the `scope` claim of the JWT. This is what enables using the `hasAuthority("SCOPE_read:messages")` method to restrict access to a valid JWT that contains the `read:messages` scope.
+:::
+
+### Create the API controller
+
+Create a new record named `Message`, which will be the domain object the API will return:
+
+```java
+// src/main/java/com/auth0/example/model/Message.java
+
+public record Message(String message) {}
+```
+
+Create a new class named `APIController` to handle requests to the endpoints:
+
+```java
+// src/main/java/com/auth0/example/web/APIController.java
+
+import com.auth0.example.model.Message;
+import org.springframework.http.MediaType;
+import org.springframework.web.bind.annotation.CrossOrigin;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+
+/**
+ * Handles requests to "/api" endpoints.
+ * @see com.auth0.example.security.SecurityConfig to see how these endpoints are protected.
+ */
+@RestController
+@RequestMapping(path = "api", produces = MediaType.APPLICATION_JSON_VALUE)
+// For simplicity of this sample, allow all origins. Real applications should configure CORS for their use case.
+@CrossOrigin(origins = "*")
+public class APIController {
+
+    @GetMapping(value = "/public")
+    public Message publicEndpoint() {
+        return new Message("All good. You DO NOT need to be authenticated to call /api/public.");
+    }
+
+    @GetMapping(value = "/private")
+    public Message privateEndpoint() {
+        return new Message("All good. You can see this because you are Authenticated.");
+    }
+
+    @GetMapping(value = "/private-scoped")
+    public Message privateScopedEndpoint() {
+        return new Message("All good. You can see this because you are Authenticated with a Token granted the 'read:messages' scope");
+    }
+}
+```
+
+## Run the Application
+
+To build and run the sample project, execute the `bootRun` Gradle task.
+
+Linux or macOS:
+
+```bash
+./gradlew bootRun
+```
+
+Windows:
+
+```bash
+gradlew.bat bootRun
+```
+
+If you are configuring your own application using Maven and the [Spring Boot Maven Plugin](https://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-maven-plugin.html), you can execute the `spring-boot:run` goal.
+
+Linux or macOS:
+
+```bash
+mvn spring-boot:run
+```
+
+Windows:
+
+```bash
+mvn.cmd spring-boot:run
+```
+
+The sample application will be available at `http://localhost:3010/`. Read about how to test and use your API in the [Using Your API](/quickstart/backend/java-spring-security5/02-using) article.
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/02-using.md b/ja-jp/articles/quickstart/backend/java-spring-security5/02-using.md
new file mode 100644
index 0000000000..466de7dabc
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/02-using.md
@@ -0,0 +1,14 @@
+---
+title: Using Your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - java
+    - spring-security
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/download.md b/ja-jp/articles/quickstart/backend/java-spring-security5/download.md
new file mode 100644
index 0000000000..baced1678f
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/download.md
@@ -0,0 +1,27 @@
+The sample can be run from the command line as follows:
+
+Linux / macOS:
+```bash
+./gradlew clean bootRun
+```
+
+Windows:
+```bash
+gradlew.bat clean bootRun
+```
+
+The application will be served from `http://localhost:3010/`.
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# Linux / macOs
+sh exec.sh
+```
+
+```bash
+# Windows
+./exec.ps1
+```
+
+The application will be served from `http://localhost:3010/`, just as if running with Gradle.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/files/api-controller.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/api-controller.md
new file mode 100644
index 0000000000..ece3064bdf
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/api-controller.md
@@ -0,0 +1,34 @@
+---
+name: APIController.java
+language: java
+---
+```java
+import com.auth0.example.model.Message;
+import org.springframework.http.MediaType;
+import org.springframework.web.bind.annotation.CrossOrigin;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+
+@RestController
+@RequestMapping(path = "api", produces = MediaType.APPLICATION_JSON_VALUE)
+// For simplicity of this sample, allow all origins. Real applications should configure CORS for their use case.
+@CrossOrigin(origins = "*")
+public class APIController {
+
+    @GetMapping(value = "/public")
+    public Message publicEndpoint() {
+        return new Message("All good. You DO NOT need to be authenticated to call /api/public.");
+    }
+
+    @GetMapping(value = "/private")
+    public Message privateEndpoint() {
+        return new Message("All good. You can see this because you are Authenticated.");
+    }
+
+    @GetMapping(value = "/private-scoped")
+    public Message privateScopedEndpoint() {
+        return new Message("All good. You can see this because you are Authenticated with a Token granted the 'read:messages' scope");
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/files/application.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/application.md
new file mode 100644
index 0000000000..f12a521ce0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/application.md
@@ -0,0 +1,12 @@
+---
+name: application.yml
+language: yaml
+---
+```yaml
+okta:
+  oauth2:
+    # Replace with the domain of your Auth0 tenant.
+    issuer: https://${account.namespace}/
+    # Replace with the API Identifier for your Auth0 API.
+    audience: ${apiIdentifier}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/files/message.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/message.md
new file mode 100644
index 0000000000..99f4056914
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/message.md
@@ -0,0 +1,11 @@
+---
+name: Message.java
+language: java
+---
+```java
+/**
+ * Simple domain object for our API to return a message.
+ */
+public record Message(String message) {}
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/files/security-config.md b/ja-jp/articles/quickstart/backend/java-spring-security5/files/security-config.md
new file mode 100644
index 0000000000..257bdbaa32
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/files/security-config.md
@@ -0,0 +1,42 @@
+---
+name: SecurityConfig.java
+language: java
+---
+```java
+package com.auth0.example.security;
+
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+/**
+ * Configures our application with Spring Security to restrict access to our API endpoints.
+ */
+@Configuration
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
+        /*
+        This is where we configure the security required for our endpoints and setup our app to serve as
+        an OAuth2 Resource Server, using JWT validation.
+        */
+        return http
+                .authorizeHttpRequests((authorize) -> authorize
+                    .requestMatchers("/api/public").permitAll()
+                    .requestMatchers("/api/private").authenticated()
+                    .requestMatchers("/api/private-scoped").hasAuthority("SCOPE_read:messages")
+                )
+                .cors(withDefaults())
+                .oauth2ResourceServer(oauth2 -> oauth2
+                    .jwt(withDefaults())
+                )
+                .build();
+    }
+}
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/index.yml b/ja-jp/articles/quickstart/backend/java-spring-security5/index.yml
new file mode 100644
index 0000000000..9baab5db4c
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/index.yml
@@ -0,0 +1,62 @@
+title: Spring Boot API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/java.png
+logo: spring
+thirdParty: false
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+sdk:
+  name: Okta Spring Boot Starter
+  url: https://github.com/okta/okta-spring-boot/
+  logo: spring
+alias:
+  - spring security
+  - spring
+languages:
+  - Java
+framework:
+  - Spring
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+default_article: 01-authorization
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-spring-security5-api-sample
+requirements:
+  - Java 17
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: "Part 2: Using Your API"
+      icon: 345
+      href: "/quickstart/backend/java-spring-security5/02-using"
+  - path: 02-using
+    list:
+    - text: "Part 3: Troubleshooting Your API"
+      icon: 345
+      href: "/quickstart/backend/java-spring-security5/03-troubleshooting"
+  - path: 03-troubleshooting
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about Role-Based Access Control
+      icon: 345
+      href: "/authorization/concepts/rbac"
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/java-spring-security5/interactive.md b/ja-jp/articles/quickstart/backend/java-spring-security5/interactive.md
new file mode 100644
index 0000000000..6ec61b3fe1
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/interactive.md
@@ -0,0 +1,156 @@
+---
+title: Spring Boot API
+description: Secure your API using the Okta Spring Boot Starter
+interactive: true
+alias:
+  - spring security
+  - spring
+topics:
+  - quickstart
+  - backend
+  - spring
+files:
+  - files/application
+  - files/security-config
+  - files/message
+  - files/api-controller
+github:
+  path: 01-Authorization-MVC
+---
+
+# Add Authorization to Your Spring Boot Application
+
+Auth0 allows you to quickly add authorization to your application. This guide demonstrates how to integrate Auth0 with any new or existing Spring Boot application.
+
+If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with.
+
+Review [our getting started guide](get-started/auth0-overview/set-up-apis) to set up your first API through the Auth0 dashboard.
+
+Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+## Configure the sample project {{{ data-action=code data-code="application.yml#1:8" }}}
+
+The sample project uses a `/src/main/resources/application.yml` file, which configures it to use the correct Auth0 **domain** and **API Identifier** for your API. If you download the code from this page it will be automatically configured. If you clone the example from GitHub, you will need to fill it in yourself.
+
+| Attribute | Description|
+| --- | --- |
+| `okta.oauth2.audience` | The unique identifier for your API. If you are following the steps in this tutorial it would be `https://quickstarts/api`. |
+| `okta.oauth2.issuer` | The issuer URI of the resource server, which will be the value of the `iss` claim in the JWT issued by Auth0. Spring Security will use this property to discover the authorization server's public keys and validate the JWT signature. The value will be your Auth0 domain with an `https://` prefix and a `/` suffix (the trailing slash is important). 
+
+## Install dependencies {{{ data-action=code data-code="application.yml#1:8" }}}
+
+If you are using Gradle, you can add the required dependencies using the [Spring Boot Gradle Plugin](https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/) and the [Dependency Management Plugin](https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/) to resolve dependency versions:
+
+```groovy
+// build.gradle
+
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.5'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+dependencies {
+    implementation 'org.springframework.boot:spring-boot-starter-web'
+    implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+}
+```
+
+If you are using Maven, add the Spring dependencies to your `pom.xml` file:
+
+```xml
+// pom.xml
+
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.5
+    
+
+
+
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        com.okta.spring
+        okta-spring-boot-starter
+        3.0.5
+    
+
+```
+
+
+## Configure the resource server {{{ data-action=code data-code="SecurityConfig.java" }}}
+
+To configure the application as a Resource Server and validate the JWTs, create a class that will provide an instance of `SecurityFilterChain`, and add the `@Configuration` annotation.
+
+### Protect API endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+The example below shows how to secure API methods using the `HttpSecurity` object provided in the `filterChain()` method of the `SecurityConfig` class. Route matchers restrict access based on the level of authorization required.
+
+::: note
+By default, Spring Security creates a `GrantedAuthority` for each scope in the `scope` claim of the JWT. This scope enables using the `hasAuthority("SCOPE_read:messages")` method to restrict access to a valid JWT that contains the `read:messages` scope.
+:::
+
+## Create the Domain Object {{{ data-action=code data-code="Message.java#1:11" }}}
+
+To make your endpoint return a JSON, you can use a Java record. The member variables of this object is serialized into the key value for your JSON. Create a new record named `Message` as an example domain object to return during the API calls.
+
+## Create the API controller {{{ data-action=code data-code="APIController.java" }}}
+
+Create a new class named `APIController` to handle requests to the endpoints. The `APIController` has three routes as defined in the [Protect API Endpoints](/quickstart/backend/java-spring-security5/interactive/#configure-the-resource-server) section. For this example, allow all origins through `@CrossOrigin` annotation. Real applications should configure `CORS` for their use case.
+
+## Run the application {{{ data-action=code data-code="APIController.java" }}}
+
+To build and run the sample project, execute the `bootRun` Gradle task.
+
+Linux or macOS:
+
+```bash
+./gradlew bootRun
+```
+
+Windows:
+
+```bash
+gradlew.bat bootRun
+```
+
+If you are configuring your own application using Maven and the [Spring Boot Maven Plugin](https://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-maven-plugin.html), you can execute the `spring-boot:run` goal.
+
+Linux or macOS:
+
+```bash
+mvn spring-boot:run
+```
+
+Windows:
+
+```bash
+mvn.cmd spring-boot:run
+```
+
+::::checkpoint
+
+:::checkpoint-default
+
+The sample application will be available at `http://localhost:3010/`. Read about how to test and use your API in the [Using Your API](/quickstart/backend/java-spring-security5/02-using) article.
+:::
+
+:::checkpoint-failure
+If your application did not launch successfully:
+* Use the [Troubleshooting](/quickstart/backend/java-spring-security5/03-troubleshooting) section to check your configuration.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
diff --git a/ja-jp/articles/quickstart/backend/laravel/01-authorization.md b/ja-jp/articles/quickstart/backend/laravel/01-authorization.md
new file mode 100644
index 0000000000..f1611bab94
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/01-authorization.md
@@ -0,0 +1,245 @@
+---
+title: Add Authorization to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+topics:
+  - quickstart
+  - backend
+  - laravel
+  - authorization
+  - php
+  - laravel
+contentType: tutorial
+useCase: quickstart
+github:
+  path: sample
+---
+
+
+
+---
+
+**Backend applications differ from traditional web applications in that they do not handle user authentication or have a user interface. They provide an API that other applications can interact with. They accept [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) from `Authorization` headers in requests to control access to routes.**
+
+Separate front-end applications are usually built to interact with these types of backends. These can be anything from [single-page applications](https://auth0.com/docs/quickstart/spa) or [native or mobile apps](https://auth0.com/docs/quickstart/native) (all of which Auth0 also provides SDKs for!)
+
+When users need to interact with your backend application, they first authenticate with Auth0 using the frontend application. The frontend application then retrieves an access token from Auth0, which it can use to make requests to your backend application on behalf of the user.
+
+As their name implies, [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) are designed to address matters of access control (authorization), and do not contain information about the user. **Backend applications work exclusively with access tokens.** You can retrieve information about the user who created the token using the [Management API](https://auth0.com/docs/api/management/v2), which we will demonstrate later.
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-api
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Backend" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Backend API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Access Control
+
+You can use the Auth0 SDK's authorization guard to restrict access to your application's routes.
+
+To reject requests that do not contain a valid access token in the `Authorization` header, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+  ]);
+})->middleware('auth');
+```
+
+You can also require the provided token to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response()->json([
+      'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.',
+    ]);
+})->middleware('auth')->can('read:messages');
+```
+
+## Token Information
+
+Information about the provided access token is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response()->json([
+      'message' => 'You did not provide a valid token.',
+    ]);
+  }
+
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+    'id' => auth()->id(),
+    'token' => auth()?->user()?->getAttributes(),
+  ]);
+});
+```
+
+## Retrieve User Information
+
+You can retrieve information about the user who created the access token from Auth0 using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). The SDK provides a convenient wrapper for this API, accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, you should grant the `read:users` scope. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/me', function () {
+  $user = auth()->id();
+  $profile = cache()->get($user);
+
+  if (null === $profile) {
+    $endpoint = Auth0::management()->users();
+    $profile = $endpoint->get($user);
+    $profile = Auth0::json($profile);
+
+    cache()->put($user, $profile, 120);
+  }
+
+  $name = $profile['name'] ?? 'Unknown';
+  $email = $profile['email'] ?? 'Unknown';
+
+  return response()->json([
+    'name' => $name,
+    'email' => $email,
+  ]);
+})->middleware('auth');
+```
+
+::: note
+**You should cache user information in your application for brief periods.** This reduces the number of requests your application makes to Auth0, and improves performance. You should avoid storing user information in your application for long periods as this can lead to stale data. You should also avoid storing user information beyond the user's identifier in persistent databases.
+:::
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+## Retrieve a Test Token
+
+You can learn more about [retrieving access tokens here](https://auth0.com/docs/secure/tokens/access-tokens/get-access-tokens). For this quickstart, however, you can simply use an access token from [your API settings' "test" view](https://manage.auth0.com/#/apis).
+
+::: note
+The `/me` route we created above will not work with a test token as there is no actual user associated with it.
+:::
+
+## Checkpoint
+
+Open a shell and try issuing requests to your application.
+
+Begin by requesting the public route:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api \
+  --header 'Accept: application/json'
+```
+
+Next, use your access token in an `Authorization` header to request a protected route:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api/private \
+  --header 'Accept: application/json' \
+  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
+```
+
+Finally, try requesting the scope-protected route, which will only succeed if the access token has the `read:messages` scope granted:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api/scope \
+  --header 'Accept: application/json' \
+  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
+```
+
+If you have any issues, here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/ja-jp/articles/quickstart/backend/laravel/download.md b/ja-jp/articles/quickstart/backend/laravel/download.md
new file mode 100644
index 0000000000..e149badf02
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/download.md
@@ -0,0 +1,8 @@
+Open a shell to the downloaded project directory, and run the following command:
+
+```bash
+composer install
+php artisan migrate
+php artisan key:generate
+php artisan serve
+```
diff --git a/ja-jp/articles/quickstart/backend/laravel/files/api.md b/ja-jp/articles/quickstart/backend/laravel/files/api.md
new file mode 100644
index 0000000000..3fe3a4e6b3
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/files/api.md
@@ -0,0 +1,58 @@
+---
+name: routes/api.php
+language: php
+---
+
+```php
+json([
+    'message' => 'Your token is valid; you are authorized.',
+  ]);
+})->middleware('auth');
+
+Route::get('/scope', function () {
+    return response()->json([
+      'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.',
+    ]);
+})->middleware('auth')->can('read:messages');
+
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response()->json([
+      'message' => 'You did not provide a valid token.',
+    ]);
+  }
+
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+    'id' => auth()->id(),
+    'token' => auth()?->user()?->getAttributes(),
+  ]);
+});
+
+Route::get('/me', function () {
+  $user = auth()->id();
+  $profile = cache()->get($user);
+
+  if (null === $profile) {
+    $endpoint = Auth0::management()->users();
+    $profile = $endpoint->get($user);
+    $profile = Auth0::json($profile);
+
+    cache()->put($user, $profile, 120);
+  }
+
+  $name = $profile['name'] ?? 'Unknown';
+  $email = $profile['email'] ?? 'Unknown';
+
+  return response()->json([
+    'name' => $name,
+    'email' => $email,
+  ]);
+})->middleware('auth');
+```
diff --git a/ja-jp/articles/quickstart/backend/laravel/index.yml b/ja-jp/articles/quickstart/backend/laravel/index.yml
new file mode 100644
index 0000000000..34db441699
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/index.yml
@@ -0,0 +1,36 @@
+title: Laravel API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: laravel
+alias:
+  - laravel
+languages:
+  - PHP
+framework:
+  - Laravel
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+articles:
+  - 01-authorization
+hidden_articles:
+  - interactive
+default_article: 01-authorization
+seo_alias: laravel
+github:
+  org: auth0-samples
+  repo: laravel
+  branch: 7.x
+sdk:
+  name: laravel-auth0
+  url: https://github.com/auth0/laravel-auth0
+  logo: laravel
+requirements:
+  - Laravel 9 / 10
+  - PHP 8.0+
+  - Composer
diff --git a/ja-jp/articles/quickstart/backend/laravel/interactive.md b/ja-jp/articles/quickstart/backend/laravel/interactive.md
new file mode 100644
index 0000000000..0efae4e396
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/laravel/interactive.md
@@ -0,0 +1,263 @@
+---
+title: Add Authorization to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+topics:
+  - quickstart
+  - backend
+  - laravel
+  - authorization
+  - php
+  - laravel
+contentType: tutorial
+useCase: quickstart
+default: true
+github:
+  path: app
+interactive: true
+files:
+  - files/api
+---
+
+# Add Authorization to Your Laravel Application
+
+[Auth0's Laravel SDK](https://github.com/auth0/laravel-auth0) allows you to quickly add token-based authorization and route access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new (or existing) [Laravel 9 or 10](https://github.com/auth0/laravel-auth0#support-policy) application.
+
+---
+
+**Backend applications differ from traditional web applications in that they do not handle user authentication or have a user interface. They provide an API that other applications can interact with. They accept [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) from `Authorization` headers in requests to control access to routes.**
+
+Separate front-end applications are usually built to interact with these types of backends. These can be anything from [single-page applications](https://auth0.com/docs/quickstart/spa) or [native or mobile apps](https://auth0.com/docs/quickstart/native) (all of which Auth0 also provides SDKs for!)
+
+When users need to interact with your backend application, they first authenticate with Auth0 using the frontend application. The frontend application then retrieves an access token from Auth0, which it can use to make requests to your backend application on behalf of the user.
+
+As their name implies, [access tokens](https://auth0.com/docs/secure/tokens/access-tokens) are designed to address matters of access control (authorization), and do not contain information about the user. **Backend applications work exclusively with access tokens.** You can retrieve information about the user who created the token using the [Management API](https://auth0.com/docs/api/management/v2), which we will demonstrate later.
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-api ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-api
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Backend" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Backend API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Access Control {{{ data-action=code data-code="routes/api.php#6:16" }}}
+
+The SDK automatically registers its authorization guard with your Laravel application for use with the `api` middleware, which by default Laravel applies to all routes in your application's `routes/api.php` file.
+
+::: warning
+For the SDK to work as expected without additional configuration, **you should define your routes in the `routes/api.php` file.**
+:::
+
+You can use the Auth0 SDK's authorization guard to restrict access to your application's routes.
+
+To reject requests that do not contain a valid access token in the `Authorization` header, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+  ]);
+})->middleware('auth');
+```
+
+You can also require the provided token to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response()->json([
+      'message' => 'Your token is valid and has the `read:messages` permission; you are authorized.',
+    ]);
+})->middleware('auth')->can('read:messages');
+```
+
+## Token Information {{{ data-action=code data-code="routes/api.php#18:30" }}}
+
+Information about the provided access token is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response()->json([
+      'message' => 'You did not provide a valid token.',
+    ]);
+  }
+
+  return response()->json([
+    'message' => 'Your token is valid; you are authorized.',
+    'id' => auth()->id(),
+    'token' => auth()?->user()?->getAttributes(),
+  ]);
+});
+```
+
+## Retrieve User Information {{{ data-action=code data-code="routes/api.php#32:51" }}}
+
+You can retrieve information about the user who created the access token from Auth0 using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). The SDK provides a convenient wrapper for this API, accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, you should grant the `read:users` scope. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/me', function () {
+  $user = auth()->id();
+  $profile = cache()->get($user);
+
+  if (null === $profile) {
+    $endpoint = Auth0::management()->users();
+    $profile = $endpoint->get($user);
+    $profile = Auth0::json($profile);
+
+    cache()->put($user, $profile, 120);
+  }
+
+  $name = $profile['name'] ?? 'Unknown';
+  $email = $profile['email'] ?? 'Unknown';
+
+  return response()->json([
+    'name' => $name,
+    'email' => $email,
+  ]);
+})->middleware('auth');
+```
+
+::: note
+**You should cache user information in your application for brief periods.** This reduces the number of requests your application makes to Auth0, and improves performance. You should avoid storing user information in your application for long periods as this can lead to stale data. You should also avoid storing user information beyond the user's identifier in persistent databases.
+:::
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+## Retrieve a Test Token
+
+You can learn more about [retrieving access tokens here](https://auth0.com/docs/secure/tokens/access-tokens/get-access-tokens). For this quickstart, however, you can simply use an access token from [your API settings' "test" view](https://manage.auth0.com/#/apis).
+
+::: note
+The `/me` route we created above will not work with a test token as there is no actual user associated with it.
+:::
+
+::::checkpoint
+:::checkpoint-default
+Open a shell and try issuing requests to your application.
+
+Begin by requesting the public route:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api \
+  --header 'Accept: application/json'
+```
+
+Next, use your access token in an `Authorization` header to request a protected route:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api/private \
+  --header 'Accept: application/json' \
+  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
+```
+
+Finally, try requesting the scope-protected route, which will only succeed if the access token has the `read:messages` scope granted:
+
+```shell
+curl --request GET \
+  --url http://localhost:8000/api/scope \
+  --header 'Accept: application/json' \
+  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
+```
+
+:::
+
+:::checkpoint-failure
+Here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+:::
+::::
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/ja-jp/articles/quickstart/backend/nginx/01-authorization.md b/ja-jp/articles/quickstart/backend/nginx/01-authorization.md
new file mode 100644
index 0000000000..0d2db63f36
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nginx/01-authorization.md
@@ -0,0 +1,82 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to use the Auth0 Nginx SDK to add authentication and authorization to your API.
+topics:
+    - quickstart
+    - backend
+    - nginx
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel-info System Requirements
+This tutorial and seed project have been tested with the following:
+* Openresty 1.9.7.2
+:::
+
+**Please follow the steps below to secure your existing API with an Nginx reverse-proxy that's configured to process JWT's generated by your Auth0 account.**
+
+## Install the `nginx-jwt` script into your Nginx server
+
+The [`nginx-jwt`](https://github.com/auth0/nginx-jwt) script is a Lua script that is designed to run on Nginx servers that have the [HttpLuaModule](https://github.com/openresty/lua-nginx-module#readme) installed. But ultimately its dependencies require components available in the [OpenResty](http://openresty.org/) distribution of Nginx. Therefore, it is recommended that you use **OpenResty** as your Nginx server, and these instructions make that assumption.
+
+1. Download the latest archive package from [releases](https://github.com/auth0/nginx-jwt/releases).
+1. Extract the archive and deploy its contents to a directory on your Nginx server.
+1. Specify this directory's path using ngx_lua's [lua_package_path](https://github.com/openresty/lua-nginx-module#lua_package_path) directive:
+
+```lua
+# nginx.conf:
+
+http {
+    lua_package_path "/path/to/lua/scripts;;";
+    ...
+}
+```
+
+## Configure `nginx-jwt` with your Auth0 account
+
+1. Export the `JWT_SECRET` environment variable on the Nginx host, setting it equal to your Client Secret.
+1. Expose this environment variable to the Nginx server:
+
+```lua
+# nginx.conf:
+
+env JWT_SECRET;
+```
+
+## Secure your API
+
+Now, secure one or more locations that point to your backing service endpoints by using the [access_by_lua](https://github.com/openresty/lua-nginx-module#access_by_lua) directive to call the `nginx-jwt` script's [`auth()`](https://github.com/auth0/nginx-jwt#auth) function before executing any [proxy_* directives](http://nginx.org/en/docs/http/ngx_http_proxy_module.html):
+
+
+```lua
+# nginx.conf:
+
+server {
+    location /secure_this {
+        access_by_lua '
+            local jwt = require("nginx-jwt")
+            jwt.auth()
+        ';
+
+        proxy_pass http://my-backend.com$uri;
+    }
+}
+```
+
+Click [here](https://github.com/auth0/nginx-jwt#usage) for more usage examples.
+
+
+## Call Your API
+
+You can now make requests against your secure API by providing the Authorization header in your requests with a valid JWT ID Token.
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:8000/path_to_your_api",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
+  ]
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/nodejs/01-authorization.md b/ja-jp/articles/quickstart/backend/nodejs/01-authorization.md
new file mode 100644
index 0000000000..0dd2779686
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/01-authorization.md
@@ -0,0 +1,93 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to an Express.js API.
+topics:
+    - quickstart
+    - backend
+    - nodejs
+github:
+  path: 01-Authorization-RS256
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new', { sampleLink: 'https://github.com/auth0-samples/auth0-express-api-samples/tree/master/02-Authorization-HS256' }) %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Validate Access Tokens
+
+### Install dependencies
+
+This guide shows you how to protect an Express API using the [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) middleware. 
+
+First install the SDK using npm.
+
+```bash
+npm install --save express-oauth2-jwt-bearer
+```
+### Configure the middleware
+
+Configure `express-oauth2-jwt-bearer` with your Domain and API Identifier.
+
+```js
+// server.js
+
+const express = require('express');
+const app = express();
+const { auth } = require('express-oauth2-jwt-bearer');
+
+// Authorization middleware. When used, the Access Token must
+// exist and be verified against the Auth0 JSON Web Key Set.
+const checkJwt = auth({
+  audience: '${apiIdentifier}',
+  issuerBaseURL: `https://${account.namespace}/`,
+});
+```
+
+The `checkJwt` middleware shown above checks if the user's Access Token included in the request is valid. If the token is not valid, the user gets a 401 Authorization error when they try to access the endpoints. The middleware doesn't check if the token has the sufficient scope to access the requested resources.
+
+## Protect API Endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+To protect an individual route that requires a valid JWT, configure the route with the `checkJwt` `express-oauth2-jwt-bearer` middleware.
+
+```js
+// server.js
+
+// This route doesn't need authentication
+app.get('/api/public', function(req, res) {
+  res.json({
+    message: 'Hello from a public endpoint! You don\'t need to be authenticated to see this.'
+  });
+});
+
+// This route needs authentication
+app.get('/api/private', checkJwt, function(req, res) {
+  res.json({
+    message: 'Hello from a private endpoint! You need to be authenticated to see this.'
+  });
+});
+```
+
+You can configure individual routes to look for a particular scope. To achieve that, set up another middleware with the `requiresScope` method. Provide the required scopes and apply the middleware to any routes you want to add authorization to. 
+
+Pass the `checkJwt` and `requiredScopes` middlewares to the route you want to protect.
+
+```js
+// server.js
+const { requiredScopes } = require('express-oauth2-jwt-bearer');
+
+const checkScopes = requiredScopes('read:messages');
+
+app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) {
+  res.json({
+    message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.'
+  });
+});
+```
+
+In this configuration, only Access Tokens with the `read:messages` scope can access the endpoint.
diff --git a/ja-jp/articles/quickstart/backend/nodejs/02-using.md b/ja-jp/articles/quickstart/backend/nodejs/02-using.md
new file mode 100644
index 0000000000..d7c9301b35
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - nodejs
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %> 
diff --git a/ja-jp/articles/quickstart/backend/nodejs/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/nodejs/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/nodejs/download.md b/ja-jp/articles/quickstart/backend/nodejs/download.md
new file mode 100644
index 0000000000..c65790273f
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/download.md
@@ -0,0 +1,15 @@
+To run the example you need [Node.JS LTS](https://nodejs.org/en/download/) installed, and to run the following commands:
+
+```bash
+npm install
+npm start
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/nodejs/files/server.md b/ja-jp/articles/quickstart/backend/nodejs/files/server.md
new file mode 100644
index 0000000000..859872d4de
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/files/server.md
@@ -0,0 +1,45 @@
+---
+name: server.js
+language: javascript
+---
+
+
+
+```javascript
+const express = require('express');
+const app = express();
+const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');
+
+// Authorization middleware. When used, the Access Token must
+// exist and be verified against the Auth0 JSON Web Key Set.
+const checkJwt = auth({
+  audience: '${apiIdentifier}',
+  issuerBaseURL: `https://${account.namespace}/`,
+});
+
+// This route doesn't need authentication
+app.get('/api/public', function(req, res) {
+  res.json({
+    message: 'Hello from a public endpoint! You don\'t need to be authenticated to see this.'
+  });
+});
+
+// This route needs authentication
+app.get('/api/private', checkJwt, function(req, res) {
+  res.json({
+    message: 'Hello from a private endpoint! You need to be authenticated to see this.'
+  });
+});
+
+const checkScopes = requiredScopes('read:messages');
+
+app.get('/api/private-scoped', checkJwt, checkScopes, function(req, res) {
+  res.json({
+    message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.'
+  });
+});
+
+app.listen(3000, function() {
+  console.log('Listening on http://localhost:3000');
+});
+```
diff --git a/ja-jp/articles/quickstart/backend/nodejs/index.yml b/ja-jp/articles/quickstart/backend/nodejs/index.yml
new file mode 100644
index 0000000000..dd58dfd65c
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/index.yml
@@ -0,0 +1,56 @@
+title: Node (Express) API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/node.png
+logo: nodejs
+thirdParty: false
+alias:
+  - node
+  - nodejs
+  - node.js
+  - express
+languages:
+  - Javascript
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/nodejs/dependencies
+  setup: server-apis/nodejs/setup
+  use: server-apis/nodejs/use
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+default_article: 01-authorization
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-express-api-samples
+sdk:
+  name: express-oauth2-jwt-bearer
+  url: https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer
+  logo: nodejs
+requirements:
+  - express-oauth2-jwt-bearer 1.0.0
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/nodejs/interactive.md b/ja-jp/articles/quickstart/backend/nodejs/interactive.md
new file mode 100644
index 0000000000..75bd51786e
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,76 @@
+---
+title: Add authorization to an Express.js API application
+description: This tutorial demonstrates how to add authorization to an Express.js API.
+topics:
+- quickstart
+- backend
+- express
+github:
+  path: 01-Authorization-RS256
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+- files/server
+---
+
+
+
+# Add Authorization to Your Express.js API Application
+This guide demonstrates how to integrate Auth0 with any new or existing Express.js API application using the `express-oauth2-jwt-bearer` package.
+
+If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing project API.
+
+To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis).
+Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
+
+
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+## Install dependencies
+
+First, install the SDK with `npm`.
+
+```bash
+npm install --save express-oauth2-jwt-bearer
+```
+
+## Configure the middleware {{{ data-action=code data-code="server.js#1:10" }}}
+
+Configure `express-oauth2-jwt-bearer` with your Domain and API Identifier.
+
+The `checkJwt` middleware shown to the right checks if the user's access token included in the request is valid. If the token is not valid, the user gets a 401 Authorization error when they try to access the endpoints.
+
+The middleware does not check if the token has sufficient scope to access the requested resources.
+
+## Protect API endpoints {{{ data-action=code data-code="server.js#12:32" }}}
+
+To protect an individual route by requiring a valid JWT, configure the route with the `checkJwt` middleware constructed from `express-oauth2-jwt-bearer`.
+
+You can configure individual routes to look for a particular scope. To achieve that, set up another middleware with the `requiresScope` method. Provide the required scopes and apply the middleware to any routes you want to add authorization to.
+
+Pass the `checkJwt` and `requiredScopes` middlewares to the route you want to protect.
+
+In this configuration, only access tokens with the `read:messages` scope can access the endpoint.
+
+<%= include('../_includes/_call_api') %>
+
+::::checkpoint
+:::checkpoint-default
+Now that you have configured your application, run your application to verify that:
+* `GET /api/public` is available for non-authenticated requests.
+* `GET /api/private` is available for authenticated requests.
+* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify you added the token as the `Authorization` header
+* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/).
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
diff --git a/ja-jp/articles/quickstart/backend/php/01-authorization.md b/ja-jp/articles/quickstart/backend/php/01-authorization.md
new file mode 100644
index 0000000000..5bf983addd
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/01-authorization.md
@@ -0,0 +1,177 @@
+---
+title: Authorization
+default: true
+description: This guide demonstrates how to integrate Auth0 with a PHP backend API using the Auth0 PHP SDK.
+budicon: 448
+topics:
+  - quickstart
+  - backend
+  - authorization
+  - api
+  - php
+contentType: tutorial
+useCase: quickstart
+github:
+  path: app
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Integrating your PHP Backend API
+
+Let's create a sample application that authorizes an Auth0-signed token with a backend API we've written in PHP. We'll take a simple approach here, appropriate for the written format. Still, you should check out the accompanying [Quickstart app on GitHub](https://github.com/auth0-samples/auth0-php-api-samples/) for a more robust example.
+
+### Installing HTTP Client and Messaging Factories
+
+The Auth0 PHP SDK supports many PHP-FIG standards to offer maximum interoperability with your project's architecture, but two of particular importance are [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/). These standards allow you to "plugin" networking components of your choice to handle messaging and requests. You will need to install compatible libraries in your project for the SDK to use.
+
+The most prolific networking library for PHP is Guzzle, although many are available to pick from within the PHP community. Let's use Guzzle for this sample application:
+
+```sh
+composer require guzzlehttp/guzzle guzzlehttp/psr7 http-interop/http-factory-guzzle
+```
+
+### Installing the PHP SDK
+
+${snippet(meta.snippets.install)}
+
+### Configure the SDK
+
+To begin, let's create a `.env` file within the root of your project directory to store our sample application's configuration and fill in the environment variables:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If we're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='https://${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# Our Auth0 API's Identifier.
+AUTH0_AUDIENCE='YOUR_API_IDENTIFIER'
+```
+
+As PHP isn't able to read our `.env` file by itself, we'll want to install a library to help with that. Although we'll be using a particular library for our sample application's purposes, any 'dotenv' loader of preference will work in a real-world application. From our project directory, let's run the following shell command to install the library:
+
+```sh
+composer require vlucas/phpdotenv
+```
+
+Next, let's create the PHP source file we'll be using for these code samples, `index.php`, and let's configure an instance of the Auth0 PHP SDK for our sample application:
+
+```php
+load();
+
+// Now instantiate the Auth0 class with our configuration:
+$auth0 = new \Auth0\SDK\Auth0([
+    'strategy' => \Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API,
+    'domain' => $_ENV['AUTH0_DOMAIN'],
+    'clientId' => $_ENV['AUTH0_CLIENT_ID'],
+    'clientSecret' => $_ENV['AUTH0_CLIENT_SECRET'],
+    'audience' => ($_ENV['AUTH0_AUDIENCE'] ?? null) !== null ? [trim($_ENV['AUTH0_AUDIENCE'])] : null,
+]);
+```
+
+
+### Authenticating the user
+
+For this sample application, we're focusing on [authorization](https://auth0.com/intro-to-iam/authentication-vs-authorization/). There's numerous routes you could go for authenticating your users before they hit your backend API for authorization, such as using [Auth0's SPA.js library](https://github.com/auth0/auth0-spa-js). This approach is demonstrated in [this Quickstart app accompanying Github project](https://github.com/auth0-samples/auth0-php-api-samples/). Regardless of the approach you take, this sample application expects you to pass your Access Token to it through a request parameter or header to work.
+
+### Authorizing an Access Token
+
+First, we need to extract the JSON Web Token (JWT) from the incoming HTTP request. Let's look for a `?token` parameter in a GET request or an `HTTP_AUTHORIZATION` or `Authorization` header.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+$jwt = $_GET['token'] ?? $_SERVER['HTTP_AUTHORIZATION'] ?? $_SERVER['Authorization'] ?? null;
+```
+
+Next, let's decode the token, if one is present:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// If a token is present, process it.
+if ($jwt !== null) {
+    // Trim whitespace from token string.
+    $jwt = trim($jwt);
+
+    // Remove the 'Bearer ' prefix, if present, in the event we're getting an Authorization header that's using it.
+    if (substr($jwt, 0, 7) === 'Bearer ') {
+        $jwt = substr($jwt, 7);
+    }
+
+    // Attempt to decode the token:
+    try {
+        $token = $auth0->decode($jwt, null, null, null, null, null, null, \Auth0\SDK\Token::TYPE_TOKEN);
+        define('ENDPOINT_AUTHORIZED', true);
+    } catch (\Auth0\SDK\Exception\InvalidTokenException $exception) {
+        // The token wasn't valid. Let's display the error message from the Auth0 SDK.
+        // We'd probably want to show a custom error here for a real world application.
+        die($exception->getMessage());
+    }
+}
+```
+
+Depending on how you configure your API routing, how exactly you integrate these checks might look a little different, but the principle is the same: check the token, and in the event your API endpoint requires authorization, deny access if the token isn't valid or acceptable:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// Is the request authorized?
+if (defined('ENDPOINT_AUTHORIZED')) {
+    // Respond with a JSON response:
+    echo json_encode([
+        'authorized' => true,
+        'data' => $token->toArray()
+    ], JSON_PRETTY_PRINT);
+
+    exit;
+}
+
+// Issue a HTTP 401 Unauthorized status:
+http_response_code(401);
+
+// Respond with a JSON response:
+echo json_encode([
+    'authorized' => false,
+    'error' => [
+        'message' => 'You are NOT authorized to be here!'
+    ]
+], JSON_PRETTY_PRINT);
+```
+
+### Caching
+
+This works, but in a real-world application, we'll want to use caching to ensure we don't hit our Auth0 rate limits or slow down our application with unnecessary network requests. The Auth0 PHP SDK supports a caching interface called [PSR-6](https://www.php-fig.org/psr/psr-6), which you can plug [any compatible caching library](https://packagist.org/providers/psr/cache-implementation) into for the SDK to fit in nicely with your architecture.
+
+For our sample, let's use the [Symfony caching component](https://symfony.com/doc/current/components/cache.html) library. From our root project directory, issue the following shell command:
+
+```sh
+composer require symfony/cache
+```
+
+Next, we need to update our SdkConfiguration to tell the SDK to use it:
+
+```PHP
+// ✋ Insert this BEFORE the token handling we added in the step above, so the SDK uses the cache.
+
+$tokenCache = new \Symfony\Component\Cache\Adapter\FilesystemAdapter();
+$auth0->configuration()->setTokenCache($tokenCache);
+```
+
+Our sample application will now cache our token-related network requests.
diff --git a/ja-jp/articles/quickstart/backend/php/02-using.md b/ja-jp/articles/quickstart/backend/php/02-using.md
new file mode 100644
index 0000000000..6697281ace
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - php
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %> 
diff --git a/ja-jp/articles/quickstart/backend/php/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/php/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/php/download.md b/ja-jp/articles/quickstart/backend/php/download.md
new file mode 100644
index 0000000000..7a3b438ed0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/download.md
@@ -0,0 +1,11 @@
+To run the sample, make sure [PHP](http://php.net/downloads.php) and [Composer](https://getcomposer.org/download/) are installed and execute the following commands in the sample's directory:
+
+```bash
+composer run app
+```
+
+You can also run it from [Docker](https://www.docker.com) with the following commands:
+
+```bash
+composer run docker
+```
diff --git a/ja-jp/articles/quickstart/backend/php/files/index.md b/ja-jp/articles/quickstart/backend/php/files/index.md
new file mode 100644
index 0000000000..171b3b5524
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/files/index.md
@@ -0,0 +1,32 @@
+---
+name: index.php
+language: php
+---
+
+```php
+getBearerToken(
+    get: ['token'],
+    server: ['Authorization']
+  );
+
+  require('router.php');
+```
diff --git a/ja-jp/articles/quickstart/backend/php/files/router.md b/ja-jp/articles/quickstart/backend/php/files/router.md
new file mode 100644
index 0000000000..779733d4b4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/files/router.md
@@ -0,0 +1,63 @@
+---
+name: router.php
+language: php
+---
+
+```php
+ 'Hello from a public endpoint! You don\'t need to be authenticated to see this.',
+      'token' => $token
+    ]);
+  });
+
+  Route::add('/api/private', function() use ($token) {
+    if ($token === null) {
+      http_response_code(401);
+      exit;
+    }
+
+    routeResponse([
+      'message' => 'Hello from a private endpoint! You need to be authenticated to see this.',
+      'token' => $token,
+    ]);
+  });
+
+  Route::add('/api/private-scoped', function() use ($token) {
+    if ($token === null) {
+      http_response_code(401);
+      exit;
+    }
+
+    if (! in_array('read:messages', $token['scopes'], true)) {
+      http_response_code(401);
+      exit;
+    }
+
+    routeResponse([
+      'message' => 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.',
+      'token' => $token,
+    ]);
+  });
+
+  // The following route is just to avoid confusion.
+  // We're not using an 'index route' in this app, so redirect requests to /api/public.
+  Route::add('/', function() {
+    header('Location: /api/public');
+  });
+
+  Route::run();
+```
diff --git a/ja-jp/articles/quickstart/backend/php/index.yml b/ja-jp/articles/quickstart/backend/php/index.yml
new file mode 100644
index 0000000000..0bac6302ec
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/index.yml
@@ -0,0 +1,53 @@
+title: PHP API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: php
+seo_alias: php
+alias:
+  - php
+languages:
+  - PHP
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  install: server-platforms/php/install
+default_article: 01-authorization
+articles:
+  - 01-authorization
+hidden_articles:
+  - 'interactive'
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-php-api-samples
+  branch: main
+sdk:
+  name: Auth0-PHP
+  url: https://github.com/auth0/auth0-php
+  logo: php
+requirements:
+  - PHP 7.4+ (8.0 recommended)
+  - Auth0-PHP 8.0
+  - Composer
+next_steps:
+  - path: 01-authorization
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/backend/php/interactive.md b/ja-jp/articles/quickstart/backend/php/interactive.md
new file mode 100644
index 0000000000..6b7f4ed30e
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/php/interactive.md
@@ -0,0 +1,109 @@
+---
+title: Add endpoint authorization to your PHP application
+description: "Auth0 allows you to add token-based endpoint authorization to your PHP application quickly and to protect your routes. This guide demonstrates how to integrate Auth0 with any new or existing PHP application using the Auth0 PHP SDK."
+interactive: true
+files:
+  - files/index
+  - files/router
+github:
+  path: app
+---
+
+# Add Authorization to Your PHP Application
+
+Auth0 allows you to add token-based endpoint authorization to almost any application type quickly. This guide demonstrates how to integrate Auth0, add token-based authorization, and protect application routes using the Auth0 PHP SDK.
+
+To use this quickstart, you’ll need to:
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working PHP project that you want to integrate with Auth0. Alternatively, you can view or download a sample application after logging in.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application registered in the Auth0 Dashboard. The Auth0 application is where you configure how you want authentication to work for your project.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code uses to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart automatically updates for your application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure an API
+
+Similarly, you need to create a new Auth0 API or use an existing API that represents the project you're integrating from the Dashboard. Choose a unique identifier for the API and make a note of it. You need that identifier to configure your application below.
+
+## Install the Auth0 PHP SDK {{{ data-action=code data-code="index.php" }}}
+
+Auth0 provides a [PHP SDK](https://github.com/auth0/auth0-PHP) (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps.
+
+The Auth0 PHP SDK requires [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/) installed, compatible HTTP libraries for managing network requests. If you don't have libraries available, you can install reliable choices by running the following commands in your terminal:
+
+```bash
+cd 
+composer require symfony/http-client nyholm/psr7
+```
+
+Now, install the Auth0 PHP SDK by running the following command in your terminal:
+
+```bash
+composer require auth0/auth0-php
+```
+
+### Configure the Auth0 SDK {{{ data-action=code data-code="index.php#7:16" }}}
+
+For the SDK to function properly, you must set the following properties in the Auth0 SDK during initialization:
+
+- `strategy`: The strategy helps guide the behavior of the SDK for the use case of your app. In this case, you want to set this to the constant `Auth0\SDK\Configuration\SdkConfiguration::STRATEGY_API`.
+- `domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under Application's Settings in the _Domain_ field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the _Client ID_ field.
+- `clientSecret`: The secret of the Auth0 application you created earlier in this quickstart. Client secret is in the Auth0 Dashboard under your Application's Settings in the _Client Secret_ field.
+- `audience`: The identifier of the Auth0 API you registered above. This must be provided as an array.
+
+::::checkpoint
+:::checkpoint-default
+
+Your Auth0 SDK is now properly configured. Run your application to verify that:
+- The SDK is initializing correctly.
+- Your application is not throwing any errors related to Auth0.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* Make sure the correct application is selected.
+* Did you save after entering your URLs?
+* Make sure the domain and client ID imported correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Listen for bearer tokens {{{ data-action=code data-code="index.php#20:23" }}}
+
+Next, expand your application to retrieve and process bearer tokens. Bearer tokens are access tokens provided to your API with requests from clients on a users' behalf. Access tokens approve or deny access to routes in your application. This is referred to as endpoint authorization.
+
+The easiest way to retrieve access tokens from a request is using the PHP SDK's `getBearerToken()` method. This method fetches tokens from GET parameters, POST bodies, request headers, and other sources. In this case, the PHP SDK processes tokens passed from GET requests in the `token` parameter or from the HTTP `Authorization` header.
+
+## Create and configure routes {{{ data-action=code data-code="router.php" }}}
+
+Now, install a routing library to help direct incoming requests to your application. This isn't a required step, but simplifies the application structure for the purposes of this quickstart.
+
+```bash
+composer require steampixel/simple-php-router
+```
+
+Create a new file in your application called `router.php` to define the routes. Copy in the code from the interactive panel to the right under the router.php tab.
+
+## Configue endpoint authorization {{{ data-action=code data-code="router.php#21:31" }}}
+
+Now that you have configured your Auth0 application, the Auth0 PHP SDK, and you application retrieves bearer tokens from requests, the next step is to set up endpoint authorization for your project. The `getBearerToken()` method you implemented above returns a `Token` class that includes details on the request's access.
+
+Since the `getBearerToken()` method automatically validates and verifies the incoming request, your application determines the details of the access token by evaluating the method's response. When the response is null, no valid token has been provided. Otherwise, inspect the contents of the response to learn more about the request.
+
+In the interactive panel to the right, you can see a check if the response is null or not to filter access to your `/api/private` route.
+
+## Authorize with scopes {{{ data-action=code data-code="router.php#33:48" }}}
+
+In some cases, you may want to filter access to a specific route based on the requested scopes in an access token. As shown in the interactive panel on the right, evaluate the contents of the 'scope' property from the `getBearerToken()` method's response to check the scopes granted by the access token.
diff --git a/ja-jp/articles/quickstart/backend/python/01-authorization.md b/ja-jp/articles/quickstart/backend/python/01-authorization.md
new file mode 100644
index 0000000000..eb175496f5
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/01-authorization.md
@@ -0,0 +1,183 @@
+---
+title: Authorization
+description:  This tutorial demonstrates how to add authorization to a Python API built with Flask.
+topics:
+    - quickstart
+    - backend
+    - python
+github:
+  path: 00-Starter-Seed
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Validate Access Tokens
+
+### Install dependencies
+
+ Add the following dependencies to your `requirements.txt`:
+
+```python
+# /requirements.txt
+
+flask
+python-dotenv
+python-jose
+flask-cors
+six
+```
+
+### Create a Flask application
+
+Create a `server.py` file and initialize the [Flask](http://flask.pocoo.org/) application. Set the domain, audience and the error handling.
+
+```python
+# /server.py
+
+import json
+from six.moves.urllib.request import urlopen
+from functools import wraps
+
+from flask import Flask, request, jsonify, _request_ctx_stack
+from flask_cors import cross_origin
+from jose import jwt
+
+AUTH0_DOMAIN = '${account.namespace}'
+API_AUDIENCE = YOUR_API_AUDIENCE
+ALGORITHMS = ["RS256"]
+
+APP = Flask(__name__)
+
+# Error handler
+class AuthError(Exception):
+    def __init__(self, error, status_code):
+        self.error = error
+        self.status_code = status_code
+
+@APP.errorhandler(AuthError)
+def handle_auth_error(ex):
+    response = jsonify(ex.error)
+    response.status_code = ex.status_code
+    return response
+```
+
+### Create the JWT validation decorator
+
+Add a decorator which verifies the Access Token against your JWKS.
+
+```python
+# /server.py
+
+# Format error response and append status code
+def get_token_auth_header():
+    """Obtains the Access Token from the Authorization Header
+    """
+    auth = request.headers.get("Authorization", None)
+    if not auth:
+        raise AuthError({"code": "authorization_header_missing",
+                        "description":
+                            "Authorization header is expected"}, 401)
+
+    parts = auth.split()
+
+    if parts[0].lower() != "bearer":
+        raise AuthError({"code": "invalid_header",
+                        "description":
+                            "Authorization header must start with"
+                            " Bearer"}, 401)
+    elif len(parts) == 1:
+        raise AuthError({"code": "invalid_header",
+                        "description": "Token not found"}, 401)
+    elif len(parts) > 2:
+        raise AuthError({"code": "invalid_header",
+                        "description":
+                            "Authorization header must be"
+                            " Bearer token"}, 401)
+
+    token = parts[1]
+    return token
+
+def requires_auth(f):
+    """Determines if the Access Token is valid
+    """
+    @wraps(f)
+    def decorated(*args, **kwargs):
+        token = get_token_auth_header()
+        jsonurl = urlopen("https://"+AUTH0_DOMAIN+"/.well-known/jwks.json")
+        jwks = json.loads(jsonurl.read())
+        unverified_header = jwt.get_unverified_header(token)
+        rsa_key = {}
+        for key in jwks["keys"]:
+            if key["kid"] == unverified_header["kid"]:
+                rsa_key = {
+                    "kty": key["kty"],
+                    "kid": key["kid"],
+                    "use": key["use"],
+                    "n": key["n"],
+                    "e": key["e"]
+                }
+        if rsa_key:
+            try:
+                payload = jwt.decode(
+                    token,
+                    rsa_key,
+                    algorithms=ALGORITHMS,
+                    audience=API_AUDIENCE,
+                    issuer="https://"+AUTH0_DOMAIN+"/"
+                )
+            except jwt.ExpiredSignatureError:
+                raise AuthError({"code": "token_expired",
+                                "description": "token is expired"}, 401)
+            except jwt.JWTClaimsError:
+                raise AuthError({"code": "invalid_claims",
+                                "description":
+                                    "incorrect claims,"
+                                    "please check the audience and issuer"}, 401)
+            except Exception:
+                raise AuthError({"code": "invalid_header",
+                                "description":
+                                    "Unable to parse authentication"
+                                    " token."}, 401)
+
+            _request_ctx_stack.top.current_user = payload
+            return f(*args, **kwargs)
+        raise AuthError({"code": "invalid_header",
+                        "description": "Unable to find appropriate key"}, 401)
+    return decorated
+```
+
+### Validate scopes
+
+Individual routes can be configured to look for a particular `scope` in the Access Token by using the following:
+
+```python
+# /server.py
+
+def requires_scope(required_scope):
+    """Determines if the required scope is present in the Access Token
+    Args:
+        required_scope (str): The scope required to access the resource
+    """
+    token = get_token_auth_header()
+    unverified_claims = jwt.get_unverified_claims(token)
+    if unverified_claims.get("scope"):
+            token_scopes = unverified_claims["scope"].split()
+            for token_scope in token_scopes:
+                if token_scope == required_scope:
+                    return True
+    return False
+```
+
+## Protect API Endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+You can use the decorators and functions define above in the corresponding endpoints.
+
+${snippet(meta.snippets.use)}
diff --git a/ja-jp/articles/quickstart/backend/python/02-using.md b/ja-jp/articles/quickstart/backend/python/02-using.md
new file mode 100644
index 0000000000..776d13c743
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - python
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
diff --git a/ja-jp/articles/quickstart/backend/python/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/python/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/python/download.md b/ja-jp/articles/quickstart/backend/python/download.md
new file mode 100644
index 0000000000..e6f16b42ac
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/download.md
@@ -0,0 +1,15 @@
+To run it from the command line:
+
+```bash
+pip install -r requirements.txt 
+python server.py
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/python/files/server.md b/ja-jp/articles/quickstart/backend/python/files/server.md
new file mode 100644
index 0000000000..38a189d539
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/files/server.md
@@ -0,0 +1,60 @@
+---
+name: server.py
+language: python
+---
+
+
+
+```python
+"""Python Flask API Auth0 integration example
+"""
+
+from os import environ as env
+
+from dotenv import load_dotenv, find_dotenv
+from flask import Flask, jsonify
+from authlib.integrations.flask_oauth2 import ResourceProtector
+from validator import Auth0JWTBearerTokenValidator
+
+require_auth = ResourceProtector()
+validator = Auth0JWTBearerTokenValidator(
+    "${account.namespace}",
+    "${apiIdentifier}"
+)
+require_auth.register_token_validator(validator)
+
+APP = Flask(__name__)
+
+
+@APP.route("/api/public")
+def public():
+    """No access token required."""
+    response = (
+        "Hello from a public endpoint! You don't need to be"
+        " authenticated to see this."
+    )
+    return jsonify(message=response)
+
+
+@APP.route("/api/private")
+@require_auth(None)
+def private():
+    """A valid access token is required."""
+    response = (
+        "Hello from a private endpoint! You need to be"
+        " authenticated to see this."
+    )
+    return jsonify(message=response)
+
+
+@APP.route("/api/private-scoped")
+@require_auth("read:messages")
+def private_scoped():
+    """A valid access token and scope are required."""
+    response = (
+        "Hello from a private endpoint! You need to be"
+        " authenticated and have a scope of read:messages to see"
+        " this."
+    )
+    return jsonify(message=response)
+```
diff --git a/ja-jp/articles/quickstart/backend/python/files/validator.md b/ja-jp/articles/quickstart/backend/python/files/validator.md
new file mode 100644
index 0000000000..75d432e488
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/files/validator.md
@@ -0,0 +1,31 @@
+---
+name: validator.py
+language: python
+---
+
+
+
+```python
+import json
+from urllib.request import urlopen
+
+from authlib.oauth2.rfc7523 import JWTBearerTokenValidator
+from authlib.jose.rfc7517.jwk import JsonWebKey
+
+
+class Auth0JWTBearerTokenValidator(JWTBearerTokenValidator):
+    def __init__(self, domain, audience):
+        issuer = f"https://{domain}/"
+        jsonurl = urlopen(f"{issuer}.well-known/jwks.json")
+        public_key = JsonWebKey.import_key_set(
+            json.loads(jsonurl.read())
+        )
+        super(Auth0JWTBearerTokenValidator, self).__init__(
+            public_key
+        )
+        self.claims_options = {
+            "exp": {"essential": True},
+            "aud": {"essential": True, "value": audience},
+            "iss": {"essential": True, "value": issuer},
+        }
+```
diff --git a/ja-jp/articles/quickstart/backend/python/index.yml b/ja-jp/articles/quickstart/backend/python/index.yml
new file mode 100644
index 0000000000..765d5a3e18
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/index.yml
@@ -0,0 +1,55 @@
+title: Python API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/python.png
+logo: python
+alias:
+  - python
+languages:
+  - Python
+author:
+  name: Luciano Balmaceda
+  email: luciano.balmaceda@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/python/dependencies
+  setup: server-apis/python/setup
+  use: server-apis/python/use
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+default_article: 01-authorization
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-python-api-samples
+sdk:
+  name: auth0-python
+  url: https://github.com/auth0/auth0-python
+  logo: python
+hidden_articles:
+  - interactive
+requirements:
+  - Python 3.6 and up
+  - Flask 2.0
+  - Authlib 1.0
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/python/interactive.md b/ja-jp/articles/quickstart/backend/python/interactive.md
new file mode 100644
index 0000000000..dfbeffb192
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,69 @@
+---
+title: Add Authorization to a Flask API application
+description: This tutorial demonstrates how to add authorization to a Python API built with Flask.
+interactive: true
+files:
+  - files/validator
+  - files/server
+github:
+  - path: 00-Starter-Seed
+  - branch: pyvnext-rewrite
+---
+
+
+
+# Add Authorization to Your Flask API Application
+
+This guide demonstrates how to integrate Auth0 with any new or existing Python API built with [Flask](https://flask.palletsprojects.com/).
+
+If you haven't created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API that represents the project you want to integrate with.
+
+Alternatively, you can read [our getting started guide](get-started/auth0-overview/set-up-apis) that helps you set up your first API through the Auth0 dashboard.
+
+Every API in Auth0 is configured using an API Identifier that your application code will use as the Audience to validate the Access Token.
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+# Configure Flask to Use Auth0
+
+## Install dependencies
+
+Add the following dependencies to your `requirements.txt`:
+
+```python
+# /requirements.txt
+
+flask
+Authlib
+```
+
+## Create the JWT validator {{{ data-action=code data-code="validator.py" }}}
+
+We're going to use a library called [Authlib](https://github.com/lepture/authlib) to create a [ResourceProtector](https://docs.authlib.org/en/latest/flask/1/resource-server.html), which is a type of [Flask decorator](https://flask.palletsprojects.com/patterns/viewdecorators/) that protects our resources (API routes) with a given validator.
+
+The validator will validate the Access Token that we pass to the resource by checking that it has a valid signature and claims.
+
+We can use AuthLib's `JWTBearerTokenValidator` validator with a few tweaks to make sure it conforms to our requirements on [validating Access Tokens](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens).
+
+To create our `Auth0JWTBearerTokenValidator` we need to pass it our `domain` and `audience` (API Identifier). It will then get the public key required to verify the token's signature and pass it to the `JWTBearerTokenValidator` class.
+
+We'll then override the class's `claims_options` to make sure the token's expiry, audience and issue claims are validated according to our requirements.
+
+## Create a Flask application {{{ data-action=code data-code="server.py" }}}
+
+Next we'll create a Flask application with 3 API routes:
+
+- `/api/public` A public endpoint that requires no authentication.
+- `/api/private` A private endpoint that requires a valid Access Token JWT.
+- `/api/private-scoped` A private endpoint that requires a valid Access Token JWT that contains the given `scope`.
+
+The protected routes will have a `require_auth` decorator which is a `ResourceProtector` that uses the `Auth0JWTBearerTokenValidator` we created earlier.
+
+To create the `Auth0JWTBearerTokenValidator` we'll pass it our tenant's domain and the API Identifier of the API we created earlier.
+
+The `require_auth` decorator on the `private_scoped` route accepts an additional argument `"read:messages"`, which checks the Access Token for the Permission (Scope) we created earlier.
+
+<%= include('../_includes/_call_api') %>
diff --git a/ja-jp/articles/quickstart/backend/rails/01-authorization.md b/ja-jp/articles/quickstart/backend/rails/01-authorization.md
new file mode 100644
index 0000000000..2d9d33bad0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/01-authorization.md
@@ -0,0 +1,285 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to a Ruby on Rails API.
+topics:
+    - quickstart
+    - backend
+    - rails
+github:
+  path: 01-Authentication-RS256
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new', { sampleLink: 'https://github.com/auth0-samples/auth0-rubyonrails-api-samples/tree/OIDC/02-Authentication-HS256' }) %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Validate Access Tokens
+
+### Install dependencies
+
+This tutorial performs access token validation using the  **[jwt](https://github.com/jwt/ruby-jwt)** Gem within a custom `Auth0Client` class. A Concern called `Secured` is used to authorize endpoints which require authentication through an incoming access token.
+
+Install the **jwt** Gem.
+
+```bash
+gem 'jwt'
+bundle install
+```
+
+### Create an Auth0Client class
+
+Create a class called `Auth0Client` which decodes and verifies the incoming access token taken from the `Authorization` header of the request. The public key for your Auth0 tenant can be fetched to verify the token.
+
+```rb
+# app/lib/auth0_client.rb
+
+# frozen_string_literal: true
+
+require 'jwt'
+require 'net/http'
+
+class Auth0Client 
+
+  # Auth0 Client Objects 
+  Error = Struct.new(:message, :status)
+  Response = Struct.new(:decoded_token, :error)
+
+  # Helper Functions 
+  def self.domain_url
+    "https://#{Rails.configuration.auth0.domain}/"
+  end
+
+  def self.decode_token(token, jwks_hash)
+    JWT.decode(token, nil, true, {
+                 algorithm: 'RS256',
+                 iss: domain_url,
+                 verify_iss: true,
+                 aud: Rails.configuration.auth0.audience,
+                 verify_aud: true,
+                 jwks: { keys: jwks_hash[:keys] }
+               })
+  end
+
+  def self.get_jwks
+    jwks_uri = URI("#{domain_url}.well-known/jwks.json")
+    Net::HTTP.get_response jwks_uri
+  end
+
+  # Token Validation 
+  def self.validate_token(token)
+    jwks_response = get_jwks
+
+    unless jwks_response.is_a? Net::HTTPSuccess
+      error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error)
+      return Response.new(nil, error)
+    end
+
+    jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys
+
+    decoded_token = decode_token(token, jwks_hash)
+
+    Response.new(decoded_token, nil)
+  rescue JWT::VerificationError, JWT::DecodeError => e
+    error = Error.new('Bad credentials', :unauthorized)
+    Response.new(nil, error)
+  end
+end
+```
+
+### Define a Secured concern
+
+Create a Concern called `Secured` which looks for the access token in the `Authorization` header of an incoming request. If the token is present, it should be passed to `Auth0Client.validate_token`.
+
+```rb
+# app/controllers/concerns/secured.rb
+
+# frozen_string_literal: true
+
+module Secured
+  extend ActiveSupport::Concern
+
+  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
+  BAD_CREDENTIALS = {
+    message: 'Bad credentials'
+  }.freeze
+  MALFORMED_AUTHORIZATION_HEADER = {
+    error: 'invalid_request',
+    error_description: 'Authorization header value must follow this format: Bearer access-token',
+    message: 'Bad credentials'
+  }.freeze
+
+  def authorize
+    token = token_from_request
+
+    return if performed?
+    
+    validation_response = Auth0Client.validate_token(token)
+    
+    return unless (error = validation_response.error)
+    
+    render json: { message: error.message }, status: error.status
+  end
+
+  private
+
+  def token_from_request
+    authorization_header_elements = request.headers['Authorization']&.split
+
+    render json: REQUIRES_AUTHENTICATION, status: :unauthorized and return unless authorization_header_elements
+
+    unless authorization_header_elements.length == 2
+      render json: MALFORMED_AUTHORIZATION_HEADER, status: :unauthorized and return
+    end
+
+    scheme, token = authorization_header_elements
+
+    render json: BAD_CREDENTIALS, status: :unauthorized and return unless scheme.downcase == 'bearer'
+
+    token
+  end
+end
+```
+
+### Validate scopes
+
+The `Auth0Client.validate_token` method above verifies that the access token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources.
+
+To look for a particular `scope` in an access token, create a new struct in your `Auth0Client` class called `Token` and define a new method inside, `validate_permissions`, that given an array of required scopes it will check if they are present in the payload of the token.
+
+Go to the `Auth0Client` class. Add the new `Token` struct and update the return value of the `validate_token` method as follows: 
+
+```ruby
+# app/lib/auth0_client.rb
+
+# frozen_string_literal: true
+
+require 'jwt'
+require 'net/http'
+
+class Auth0Client 
+
+  # Auth0 Client Objects 
+  Error = Struct.new(:message, :status)
+  Response = Struct.new(:decoded_token, :error)
+
+  Token = Struct.new(:token) do
+    def validate_permissions(permissions)
+      required_permissions = Set.new permissions
+      scopes = token[0]['scope']
+      token_permissions = scopes.present? ? Set.new(scopes.split(" ")) : Set.new
+      required_permissions <= token_permissions
+    end
+  end
+
+  # ... 
+
+  # Token Validation 
+  def self.validate_token(token)
+    jwks_response = get_jwks
+
+    unless jwks_response.is_a? Net::HTTPSuccess
+      error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error)
+      return Response.new(nil, error)
+    end
+
+    jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys
+
+    decoded_token = decode_token(token, jwks_hash)
+
+    Response.new(Token.new(decoded_token), nil)
+  rescue JWT::VerificationError, JWT::DecodeError => e
+    error = Error.new('Bad credentials', :unauthorized)
+    Response.new(nil, error)
+  end
+end
+```
+
+Next, in the `Secured` concern, define a new error constant `INSUFFICIENT_PERMISSIONS` to return a proper error message in case there was a attempt to request a resource without the right permissions. Next, update the return value of the `Auth0Client.validate_token` call and finally create a new method `validate_permissions` where to check if the token has the right permissions, or return a `403 FORBIDDEN` status code with the `INSUFFICIENT_PERMISSIONS` error message otherwise. 
+
+Apply these changes in your `Secured` concern by adding the following code: 
+
+```rb
+# app/controllers/concerns/secured.rb
+
+# frozen_string_literal: true
+
+module Secured
+  extend ActiveSupport::Concern
+
+  # ... 
+
+  INSUFFICIENT_PERMISSIONS = {
+    error: 'insufficient_permissions',
+    error_description: 'The access token does not contain the required permissions',
+    message: 'Permission denied'
+  }.freeze
+
+  def authorize
+    token = token_from_request
+
+    return if performed?
+
+    validation_response = Auth0Client.validate_token(token)
+
+    @decoded_token = validation_response.decoded_token # Add this line
+
+    return unless (error = validation_response.error)
+
+    render json: { message: error.message }, status: error.status
+  end
+
+  def validate_permissions(permissions)
+    raise 'validate_permissions needs to be called with a block' unless block_given?
+    return yield if @decoded_token.validate_permissions(permissions)
+
+    render json: INSUFFICIENT_PERMISSIONS, status: :forbidden
+  end
+
+  private
+  # ... 
+end
+```
+
+## Protect API Endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+Add the `Secured` concern to the `ApplicationController`: 
+
+```ruby
+class ApplicationController < ActionController::API
+  include Secured
+end
+```
+
+You only ned to protect the `PrivateController` as follows:
+
+```ruby
+class PrivateController < ApplicationController
+  before_action :authorize
+
+  # ...
+end
+```
+
+In order to check that your access token has the right permissions, call the `validate_permissions` method as follows in the `private-scoped` action:
+
+```ruby
+class PrivateController < ApplicationController
+  before_action :authorize
+
+  def private
+    render json: { message: 'Hello from a private endpoint! You need to be authenticated to see this.' }
+  end
+
+  def private_scoped
+    validate_permissions ['read:messages'] do
+      render json: { message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' }
+    end
+  end
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/rails/02-using.md b/ja-jp/articles/quickstart/backend/rails/02-using.md
new file mode 100644
index 0000000000..ea41ac4cc4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - rails
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
diff --git a/ja-jp/articles/quickstart/backend/rails/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/rails/03-troubleshooting.md
new file mode 100644
index 0000000000..1190a67ac8
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/03-troubleshooting.md
@@ -0,0 +1,10 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT validator configuration
+description: This document will help you troubleshoot your configuration if you get unexpected responses from your API.
+budicon: 500
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_troubleshooting') %> 
diff --git a/ja-jp/articles/quickstart/backend/rails/download.md b/ja-jp/articles/quickstart/backend/rails/download.md
new file mode 100644
index 0000000000..e7fdcab9ad
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/download.md
@@ -0,0 +1,15 @@
+To run it from the command line:
+
+```bash
+bundle install
+rails s --port 3010
+```
+
+The sample includes a [Docker](https://www.docker.com) image ready to run with the following command:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/rails/files/application_controller.md b/ja-jp/articles/quickstart/backend/rails/files/application_controller.md
new file mode 100644
index 0000000000..6b31483dfc
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/application_controller.md
@@ -0,0 +1,14 @@
+---
+name: app/controllers/application_controller.rb
+language: ruby
+---
+
+
+
+```ruby
+# frozen_string_literal: true
+
+class ApplicationController < ActionController::API
+  include Secured
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/rails/files/auth0_client.md b/ja-jp/articles/quickstart/backend/rails/files/auth0_client.md
new file mode 100644
index 0000000000..a57b2c9b36
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/auth0_client.md
@@ -0,0 +1,68 @@
+---
+name: app/lib/auth0_client.rb
+language: ruby
+---
+
+
+
+```ruby
+# frozen_string_literal: true
+
+require 'jwt'
+require 'net/http'
+
+# Auth0Client class to handle JWT token validation
+class Auth0Client
+  # Auth0 Client Objects 
+  Error = Struct.new(:message, :status)
+  Response = Struct.new(:decoded_token, :error)
+  Token = Struct.new(:token) do
+    def validate_permissions(permissions)
+      required_permissions = Set.new permissions
+      scopes = token[0]['scope']
+      token_permissions = scopes.present? ? Set.new(scopes.split(" ")) : Set.new
+      required_permissions <= token_permissions
+    end
+  end
+
+  # Helper Functions 
+  def self.domain_url
+    "https://#{Rails.configuration.auth0.domain}/"
+  end
+
+  def self.decode_token(token, jwks_hash)
+    JWT.decode(token, nil, true, {
+                 algorithm: 'RS256',
+                 iss: domain_url,
+                 verify_iss: true,
+                 aud: Rails.configuration.auth0.audience,
+                 verify_aud: true,
+                 jwks: { keys: jwks_hash[:keys] }
+               })
+  end
+
+  def self.get_jwks
+    jwks_uri = URI("#{domain_url}.well-known/jwks.json")
+    Net::HTTP.get_response jwks_uri
+  end
+
+  # Token Validation 
+  def self.validate_token(token)
+    jwks_response = get_jwks
+
+    unless jwks_response.is_a? Net::HTTPSuccess
+      error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error)
+      return Response.new(nil, error)
+    end
+
+    jwks_hash = JSON.parse(jwks_response.body).deep_symbolize_keys
+
+    decoded_token = decode_token(token, jwks_hash)
+
+    Response.new(Token.new(decoded_token), nil)
+  rescue JWT::VerificationError, JWT::DecodeError => e
+    error = Error.new('Bad credentials', :unauthorized)
+    Response.new(nil, error)
+  end
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/rails/files/private.md b/ja-jp/articles/quickstart/backend/rails/files/private.md
new file mode 100644
index 0000000000..65d1d14f24
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/private.md
@@ -0,0 +1,23 @@
+---
+name: app/controllers/private_controller.rb
+language: ruby
+---
+
+
+
+```rb
+# frozen_string_literal: true
+class PrivateController < ApplicationController
+  before_action :authorize
+
+  def private
+    render json: { message: 'Hello from a private endpoint! You need to be authenticated to see this.' }
+  end
+
+  def private_scoped
+    validate_permissions ['read:messages'] do
+      render json: { message: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' }
+    end
+  end
+end
+```
diff --git a/ja-jp/articles/quickstart/backend/rails/files/public.md b/ja-jp/articles/quickstart/backend/rails/files/public.md
new file mode 100644
index 0000000000..841a3118a1
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/public.md
@@ -0,0 +1,15 @@
+---
+name: app/controllers/public_controller.rb
+language: ruby
+---
+
+
+
+```rb
+# frozen_string_literal: true
+class PublicController < ApplicationController
+  def public
+    render json: { message: 'All good. You don\'t need to be authenticated to call this.' }
+  end
+end
+```
diff --git a/ja-jp/articles/quickstart/backend/rails/files/secured.md b/ja-jp/articles/quickstart/backend/rails/files/secured.md
new file mode 100644
index 0000000000..b89e6bc2a0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/files/secured.md
@@ -0,0 +1,69 @@
+---
+name: app/controllers/concerns/secured.rb
+language: ruby
+---
+
+
+
+```rb
+# frozen_string_literal: true
+
+module Secured
+  extend ActiveSupport::Concern
+
+  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
+  BAD_CREDENTIALS = {
+    message: 'Bad credentials'
+  }.freeze
+  MALFORMED_AUTHORIZATION_HEADER = {
+    error: 'invalid_request',
+    error_description: 'Authorization header value must follow this format: Bearer access-token',
+    message: 'Bad credentials'
+  }.freeze
+  INSUFFICIENT_PERMISSIONS = {
+    error: 'insufficient_permissions',
+    error_description: 'The access token does not contain the required permissions',
+    message: 'Permission denied'
+  }.freeze
+
+  def authorize
+    token = token_from_request
+
+    return if performed?
+
+    validation_response = Auth0Client.validate_token(token)
+
+    @decoded_token = validation_response.decoded_token
+
+    return unless (error = validation_response.error)
+
+    render json: { message: error.message }, status: error.status
+  end
+
+  def validate_permissions(permissions)
+    raise 'validate_permissions needs to be called with a block' unless block_given?
+    return yield if @decoded_token.validate_permissions(permissions)
+
+    render json: INSUFFICIENT_PERMISSIONS, status: :forbidden
+  end
+
+  private
+
+  def token_from_request
+    authorization_header_elements = request.headers['Authorization']&.split
+
+    render json: REQUIRES_AUTHENTICATION, status: :unauthorized and return unless authorization_header_elements
+
+    unless authorization_header_elements.length == 2
+      render json: MALFORMED_AUTHORIZATION_HEADER,
+             status: :unauthorized and return
+    end
+
+    scheme, token = authorization_header_elements
+
+    render json: BAD_CREDENTIALS, status: :unauthorized and return unless scheme.downcase == 'bearer'
+
+    token
+  end
+end
+```
diff --git a/ja-jp/articles/quickstart/backend/rails/index.yml b/ja-jp/articles/quickstart/backend/rails/index.yml
new file mode 100644
index 0000000000..0c802dd929
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/index.yml
@@ -0,0 +1,57 @@
+title: Ruby On Rails API
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/rails.png
+logo: rails
+alias:
+  - rails
+  - ror
+languages:
+  - Ruby
+framework:
+  - Ruby on Rails
+author:
+  name: Josh Cunningham
+  email: josh.cunningham@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-apis/rails/dependencies
+  setup: server-apis/rails/setup
+  use: server-apis/rails/use
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+default_article: 01-authorization
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-rubyonrails-api-samples
+sdk:
+  name: omniauth-auth0
+  url: https://github.com/auth0/omniauth-auth0
+  logo: rails
+requirements:
+  - Ruby 2.1.8
+  - Rails 4.2.5
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/backend/rails/interactive.md b/ja-jp/articles/quickstart/backend/rails/interactive.md
new file mode 100644
index 0000000000..4a0af13b65
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,96 @@
+---
+title: Add authorization to a Ruby on Rails API
+description: This tutorial demonstrates how to add authorization to a Ruby on Rails API.
+topics:
+    - quickstart
+    - backend
+    - rails
+github:
+  path: 01-Authentication-RS256
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/application_controller
+  - files/auth0_client
+  - files/secured
+  - files/public
+  - files/private
+---
+
+
+# Add Authorization to Your Ruby on Rails API
+This tutorial performs access token validation using the  **[jwt](https://github.com/jwt/ruby-jwt)** Gem within a custom `Auth0Client` class. A Concern called `Secured` is used to authorize endpoints which require authentication through an incoming access token.
+
+If you have not created an API in your Auth0 dashboard yet, use the interactive selector to create a new Auth0 API or select an existing API for your project.
+
+To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis).
+
+Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+## Install dependencies
+Install the **jwt** Gem.
+
+```bash
+gem 'jwt'
+bundle install
+```
+
+## Create an Auth0Client class {{{ data-action=code data-code="app/lib/auth0_client.rb" }}}
+
+Create a class called `Auth0Client`. This class decodes and verifies the incoming access token taken from the `Authorization` header of the request.
+
+The `Auth0Client` class retrieves the public key for your Auth0 tenant and then uses it to verify the signature of the access token. The `Token` struct defines a `validate_permissions` method to look for a particular `scope` in an access token by providing an array of required scopes and check if they are present in the payload of the token.
+
+## Define a Secured concern {{{ data-action=code data-code="app/controllers/concerns/secured.rb" }}}
+
+Create a Concern called `Secured` which looks for the access token in the `Authorization` header of an incoming request.
+
+If the token is present, the `Auth0Client.validate_token` will use the `jwt` Gem to verify the token's signature and validate the token's claims.
+
+In addition to verifying that the access token is valid, the Concern also includes a mechanism for confirming the token has the sufficient **scope** to access the requested resources. In this example we define a `validate_permissions` method that receives a block and checks the permissions by calling the `Token.validate_permissions` method from the `Auth0Client` class.
+
+For the `/private-scoped` route, the scopes defined will be intersected with the scopes coming in the payload, to determine if it contains one or more items from the other array.
+
+## Include the Secure concern in your ApplicationController {{{ data-action=code data-code="app/controllers/application_controller.rb" }}}
+
+By adding the `Secure` concern to your application controller, you'll only need to use a `before_action` filter in the controller that requires authorization. 
+
+## Create the public endpoint {{{ data-action=code data-code="app/controllers/public_controller.rb" }}}
+
+Create a controller to handle the public endpoint `/api/public`.
+
+The `/public` endpoint does not require any authorization so no `before_action` is needed.
+
+## Create the private endpoints {{{ data-action=code data-code="app/controllers/private_controller.rb" }}}
+
+Create a controller to handle the private endpoints: `/api/private` and `/api/private-scoped`. 
+
+`/api/private` is available for authenticated requests containing an access token with no additional scopes.
+
+`/api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope granted
+
+The protected endpoints need to call the `authorize` method from the `Secured` concern, for that you use `before_action :authorize`, this ensure the `Secured.authorize` method is called before every action in the `PrivateController`. 
+
+<%= include('../_includes/_call_api') %>
+
+::::checkpoint
+:::checkpoint-default
+Now that you have configured your application, run your application to verify that:
+* `GET /api/public` is available for non-authenticated requests.
+* `GET /api/private` is available for authenticated requests.
+* `GET /api/private-scoped` is available for authenticated requests containing an Access Token with the `read:messages` scope.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify you added the token as the `Authorization` header
+* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/).
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/01-authorization.md b/ja-jp/articles/quickstart/backend/webapi-owin/01-authorization.md
new file mode 100644
index 0000000000..364e547522
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/01-authorization.md
@@ -0,0 +1,196 @@
+---
+title: Authorization
+description: This tutorial demonstrates how to add authorization to an ASP.NET OWIN API using the standard JWT middleware.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - webapi-owin
+github:
+    path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+<%= include('../_includes/_api_create_new') %>
+
+<%= include('../_includes/_api_auth_preamble') %>
+
+## Configure the Sample Project
+
+The sample code has an `appsettings` section in `Web.config` which configures it to use the correct Auth0 **Domain** and **API Identifier** for your API. If you download the code from this page it will be automatically filled. If you use the example from Github, you will need to fill it yourself.
+
+```xml
+// web.config
+
+
+  
+  
+
+```
+
+## Validate Access Tokens
+
+### Install dependencies
+
+To use Auth0 Access Tokens with ASP.NET you will use the OWIN JWT Middleware which is available in the `Microsoft.Owin.Security.Jwt` NuGet package.
+
+```bash
+Install-Package Microsoft.Owin.Security.Jwt
+```
+
+### Verifying the token signature
+As the OWIN JWT middleware doesn't use Open ID Connect Discovery by default, you will need to provide a custom `IssuerSigningKeyResolver`. To do this, add the following to the `Support/OpenIdConnectSigningKeyResolver.cs` file:
+
+:::note
+Such a custom resolver was previously published as part of the `Auth0.OpenIdConnectSigningKeyResolver` package through Nuget. As [this package is not available anymore](https://github.com/auth0/auth0-aspnet-owin/blob/master/SECURITY-NOTICE.md), you will need to provide this yourself.
+:::
+
+```javascript
+public class OpenIdConnectSigningKeyResolver
+{
+    private readonly OpenIdConnectConfiguration openIdConfig;
+
+    public OpenIdConnectSigningKeyResolver(string authority)
+    {
+        var cm = new ConfigurationManager($"{authority.TrimEnd('/')}/.well-known/openid-configuration", new OpenIdConnectConfigurationRetriever());
+        openIdConfig = AsyncHelper.RunSync(async () => await cm.GetConfigurationAsync());
+    }
+
+    public SecurityKey[] GetSigningKey(string kid)
+    {
+        return new[] { openIdConfig.JsonWebKeySet.GetSigningKeys().FirstOrDefault(t => t.KeyId == kid) };
+    }
+}
+```
+
+The `OpenIdConnectSigningKeyResolver` will automatically download the JSON Web Key Set used to sign the RS256 tokens from the OpenID Connect Configuration endpoint (at `/.well-known/openid-configuration`). You can then use it subsequently to resolve the Issuer Signing Key, as will be demonstrated in the JWT registration code below.
+
+### Configuration
+
+Go to the `Configuration` method of your `Startup` class and add a call to `UseJwtBearerAuthentication` passing in the configured `JwtBearerAuthenticationOptions`.
+
+The `JwtBearerAuthenticationOptions` needs to specify your Auth0 API Identifier in the `ValidAudience` property, and the full path to your Auth0 domain as the `ValidIssuer`. You will need to configure the `IssuerSigningKeyResolver` to use the instance of `OpenIdConnectSigningKeyResolver` to resolve the signing key:
+
+```csharp
+// Startup.cs
+
+public void Configuration(IAppBuilder app)
+{
+    var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
+    var apiIdentifier = ConfigurationManager.AppSettings["Auth0ApiIdentifier"];
+    var keyResolver = new OpenIdConnectSigningKeyResolver(domain);
+
+    app.UseJwtBearerAuthentication(
+        new JwtBearerAuthenticationOptions
+        {
+            AuthenticationMode = AuthenticationMode.Active,
+            TokenValidationParameters = new TokenValidationParameters()
+            {
+                ValidAudience = apiIdentifier,
+                ValidIssuer = domain,
+                IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid)
+            }
+        });
+
+    // Configure Web API
+    WebApiConfig.Configure(app);
+}
+```
+
+::: panel-warning Do not forget the trailing backslash
+Please ensure that the URL specified for `ValidIssuer` contains a trailing backslash as this needs to match exactly with the issuer claim of the JWT. This is a common misconfiguration error which will cause your API calls to not be authenticated correctly.
+:::
+
+### Validate scopes
+
+The JWT middleware above verifies that the Access Token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources.
+
+Create a class called `ScopeAuthorizeAttribute` which inherits from `System.Web.Http.AuthorizeAttribute`. This Authorization Attribute will check that the `scope` claim issued by your Auth0 tenant is present, and if so it will ensure that the `scope` claim contains the requested scope.
+
+```csharp
+// Controllers/ScopeAuthorizeAttribute.cs
+
+public class ScopeAuthorizeAttribute : AuthorizeAttribute
+{
+    private readonly string scope;
+
+    public ScopeAuthorizeAttribute(string scope)
+    {
+        this.scope = scope;
+    }
+
+    public override void OnAuthorization(HttpActionContext actionContext)
+    {
+        base.OnAuthorization(actionContext);
+
+        // Get the Auth0 domain, in order to validate the issuer
+        var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
+
+        // Get the claim principal
+        ClaimsPrincipal principal = actionContext.ControllerContext.RequestContext.Principal as ClaimsPrincipal;
+
+        // Get the scope claim. Ensure that the issuer is for the correct Auth0 domain
+        var scopeClaim = principal?.Claims.FirstOrDefault(c => c.Type == "scope" && c.Issuer == domain);
+        if (scopeClaim != null)
+        {
+            // Split scopes
+            var scopes = scopeClaim.Value.Split(' ');
+
+            // Succeed if the scope array contains the required scope
+            if (scopes.Any(s => s == scope))
+                return;
+        }
+
+        HandleUnauthorizedRequest(actionContext);
+    }
+}
+```
+
+## Protect API Endpoints
+
+<%= include('../_includes/_api_endpoints') %>
+
+The JWT middleware integrates with the standard ASP.NET Authentication and Authorization mechanisms, so you only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint.
+
+```csharp
+// Controllers/ApiController.cs
+
+[RoutePrefix("api")]
+public class ApiController : ApiController
+{
+    [HttpGet]
+    [Route("private")]
+    [Authorize]
+    public IHttpActionResult Private()
+    {
+        return Json(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated to see this."
+        });
+    }
+}
+```
+
+To ensure that a scope is present in order to call a particular API endpoint, you simply need to decorate the action with the `ScopeAuthorize` attribute and pass the name of the required `scope` in the `scope` parameter.
+
+```csharp
+// Controllers/ApiController.cs
+
+[RoutePrefix("api")]
+public class ApiController : ApiController
+{
+    [HttpGet]
+    [Route("private-scoped")]
+    [ScopeAuthorize("read:messages")]
+    public IHttpActionResult Scoped()
+    {
+        return Json(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
+        });
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/02-using.md b/ja-jp/articles/quickstart/backend/webapi-owin/02-using.md
new file mode 100644
index 0000000000..2c15aa3d87
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/02-using.md
@@ -0,0 +1,13 @@
+---
+title: Using your API
+description: This tutorial will show you how to use your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - webapi-owin
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_api_using') %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/03-troubleshooting.md b/ja-jp/articles/quickstart/backend/webapi-owin/03-troubleshooting.md
new file mode 100644
index 0000000000..329b9ef37e
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/03-troubleshooting.md
@@ -0,0 +1,177 @@
+---
+title: Troubleshooting
+name: Shows how to troubleshoot the JWT middleware configuration
+description: This document will help you troubleshoot your configuration if you get a 401 (Unauthorized) response from your API.
+budicon: 500
+topics:
+    - quickstart
+    - backend
+    - webapi-owin
+contentType: tutorial
+useCase: quickstart
+---
+
+If you configured the JWT middleware correctly, you will be able to get proper responses from your API when you make requests. However, in the case where you get a 401 (Unauthorized) response from your API, it is because the configuration of your JWT middleware does not match with the JWT which was passed.
+
+This document will help you troubleshoot your JWT middleware configuration.
+
+## How does a token get validated?
+
+In terms of validating a JWT, there are various things to consider:
+
+1. **Is the token well-formed?** In other words, is this token conforming to the structure of a JSON Web Token (JWT)? To get more information on the structure of a JWT, please refer to [this section on the structure of a JWT](/jwt#what-is-the-json-web-token-structure-)
+
+2. **Has the token been tampered with?** The last part of a JWT is the signature. The signature is used to verify that the token was in fact signed by the sender and not altered in any way.
+
+3. **Has the token been received in its validity period?** JWTs are only valid for a specified time period (as expressed in the `exp` claim).
+
+4. **Is the token coming from the intended Authority?** This consists of 2 parts
+
+    * **Signature Verification**: Can we confirm that the JWT is correctly signed using the key issued by the issuing authority?
+
+    * **Issuer Value**: The Issuer is defined in the `iss` claim. Once again does this claim match up with what your application expects?
+
+5. **Is the token intended for the current application?** So does the `aud` claim of the JWT match with what your application is expecting?
+
+## Inspecting a token
+
+A quick way to inspect a JWT is by using the [JWT.io](https://jwt.io/) website. It has a handy debugger which allows you to quickly check that a JWT is well-formed, and also inspect the values of the various claims.
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png)
+
+In the screenshot above you can see that the token was signed using the **RS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://quickstarts/api**.
+
+So in other words these values in your JWT middleware registration must match **exactly** - including the trailing slash for the Issuer, such as
+
+```csharp
+var keyResolver = new OpenIdConnectSigningKeyResolver("https://jerrie.auth0.com/");
+app.UseJwtBearerAuthentication(
+    new JwtBearerAuthenticationOptions
+    {
+        AuthenticationMode = AuthenticationMode.Active,
+        TokenValidationParameters = new TokenValidationParameters()
+        {
+            ValidAudience = "https://quickstarts/api",
+            ValidIssuer = "https://jerrie.auth0.com/",
+            IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid)
+        }
+    });
+```
+
+For a token signed using HS256, the debugger view will look a little different:
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png)
+
+In the screenshot above you can see that the token was signed using the **HS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://quickstarts/api/hs256**.
+
+In this case, the middleware needs to be configured as follows:
+
+```csharp
+app.UseJwtBearerAuthentication(
+    new JwtBearerAuthenticationOptions
+    {
+        AuthenticationMode = AuthenticationMode.Active,
+        AllowedAudiences = new[] { "https://quickstarts/api/hs256" },
+        IssuerSecurityKeyProviders = new IIssuerSecurityKeyProvider[]
+        {
+            new SymmetricKeyIssuerSecurityKeyProvider("https://jerrie.auth0.com/",
+              Encoding.UTF8.GetBytes("your api secret"))
+        }
+    });
+```
+
+## Using the log files to debug configuration issues
+
+In order to inspect the log message which are generated by the OWIN middleware, you need to set the logging level to Verbose. So in your `web.config` file, add the following:
+
+```xml
+
+  
+    
+  
+
+```
+
+This will log all OWIN log messages to the Output window in Visual Studio when running your application in Debug Mode.
+
+### 1. Are you actually passing the JWT in the Authorization header?
+
+The first thing is to ensure that you actually pass along the JWT as a Bearer token in the Authorization header of the request. If you get a 401 (Unauthorized) response from your Web API, but you do not see any other error messages being logged to the Output Window, then most likely you are simply not sending the JWT in the Authorization header of the request.
+
+To resolve this issue, ensure that you send the JWT as a bearer token in the Authorization header.
+
+## 2. Did you configure the JWT middleware for the correct signing algorithm?
+
+Another common mistake is that your tokens are signed using the HS256 [signing algorithm](/tokens/concepts/signing-algorithms), but your middleware is configured for RS256 - or vice versa.
+
+In the following screenshot, you can see that we get an error message that the signature validation failed. This is because the JWT middleware was configured to handle tokens signed using RS256, but instead, a token was sent which was signed using HS256.
+
+![Wrong Signature Configured](/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-rs256.png)
+
+The relevant error message to look for is the following:
+
+```text
+IDX10503: Signature validation failed. Keys tried: 'null'.
+```
+
+In the case where you configured your middleware for HS256, but you are sending an RS256 signed token the error message will be different:
+
+![Wrong Signature Configured](/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-hs256.png)
+
+In this case, the relevant error message to look for is the following:
+
+```text
+IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier...
+```
+
+To resolve this issue, be sure that the signature algorithm with which the JWT was signed matches how your middleware is configured.
+
+## 3. Has your token expired?
+
+Each JSON Web Token is only valid until the time specified in the `exp` claim. If you and send a token which has expired, the token will be rejected:
+
+![Token Expired](/media/articles/server-apis/webapi-owin/troubleshoot-token-expired.png)
+
+The error message to look for is the following:
+
+```text
+Expired bearer token received
+```
+
+The resolve this issue, be sure to send a token which has not expired.
+
+::: panel exp
+  The value of the `exp` claim is a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time. If you want to see the actual date/time for the value, you can visit EpochConverter.
+:::
+
+## 4. Did you configure the correct Issuer?
+
+The Issuer specified in your token must match exactly with what is configured in your JWT middleware.
+
+![Issuer Validation Failed](/media/articles/server-apis/webapi-owin/troubleshoot-issuer-validation-failed.png)
+
+The error message to look for is the following:
+
+```text
+IDX10205: Issuer validation failed.
+```
+
+The resolve this issue, ensure that you specify the correct issuer for your JWT middleware. If your middleware is configured for RS256 signed tokens, this means ensuring that you have specified the correct value for the `TokenValidationParameters.ValidIssuer` property of the `JwtBearerAuthenticationOptions` parameter passed when calling `app.UseJwtBearerAuthentication(...)`.
+
+If your middleware is configured for HS256 signed tokens, this means ensuring that you have passed the correct value to the constructor of `SymmetricKeyIssuerSecurityTokenProvider` which was configured as one of the `IssuerSecurityTokenProviders` for the `JwtBearerAuthenticationOptions`.
+
+## 5. Does the audience match?
+
+The audience specified in your token must match exactly with what is configured in your JWT middleware.
+
+![Audience Validation Failed](/media/articles/server-apis/webapi-owin/troubleshoot-audience-validation-failed.png)
+
+The error message to look for is the following:
+
+```text
+IDX10214: Audience validation failed.
+```
+
+The resolve this issue, ensure that you specify the correct audience for your JWT middleware.  If your middleware is configured for RS256 signed tokens, this means ensuring that you have specified the correct value for the `ValidAudience` property of the `TokenValidationParameters`
+
+If your middleware is configured for HS256 signed tokens, this means ensuring that you have added the correct audience to the list of `AllowedAudiences` for the `JwtBearerAuthenticationOptions`.
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/download.md b/ja-jp/articles/quickstart/backend/webapi-owin/download.md
new file mode 100644
index 0000000000..453a159648
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/download.md
@@ -0,0 +1,3 @@
+To run the sample, open the solution in [Visual Studio](https://visualstudio.microsoft.com/vs/).
+
+Click the `Start` button or select the menu option `Debug | Start Debugging` or use the keyboard shortcut `F5`.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/api-controller.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/api-controller.md
new file mode 100644
index 0000000000..9c04dd06e5
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/api-controller.md
@@ -0,0 +1,42 @@
+---
+name: ApiController.cs
+language: csharp
+---
+
+```csharp
+[RoutePrefix("api")]
+public class ApiController : ApiController
+{
+    [HttpGet]
+    [Route("public")]
+    public IHttpActionResult Public()
+    {
+        return Json(new
+        {
+            Message = "Hello from a public endpoint!"
+        });
+    }
+
+    [HttpGet]
+    [Route("private")]
+    [Authorize]
+    public IHttpActionResult Private()
+    {
+        return Json(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated to see this."
+        });
+    }
+
+    [HttpGet]
+    [Route("private-scoped")]
+    [ScopeAuthorize("read:messages")]
+    public IHttpActionResult Scoped()
+    {
+        return Json(new
+        {
+            Message = "Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this."
+        });
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md
new file mode 100644
index 0000000000..a1aaee90b9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/openid-connect-signing-key-resolver.md
@@ -0,0 +1,22 @@
+---
+name: OpenIdConnectSigningKeyResolver.cs
+language: csharp
+---
+
+```csharp
+public class OpenIdConnectSigningKeyResolver
+{
+    private readonly OpenIdConnectConfiguration openIdConfig;
+
+    public OpenIdConnectSigningKeyResolver(string authority)
+    {
+        var cm = new ConfigurationManager($"{authority.TrimEnd('/')}/.well-known/openid-configuration", new OpenIdConnectConfigurationRetriever());
+        openIdConfig = AsyncHelper.RunSync(async () => await cm.GetConfigurationAsync());
+    }
+
+    public SecurityKey[] GetSigningKey(string kid)
+    {
+        return new[] { openIdConfig.JsonWebKeySet.GetSigningKeys().FirstOrDefault(t => t.KeyId == kid) };
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md
new file mode 100644
index 0000000000..ec5670f427
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/scope-authorize-attribute.md
@@ -0,0 +1,41 @@
+---
+name: ScopeAuthorizeAttribute.cs
+language: csharp
+---
+
+```csharp
+public class ScopeAuthorizeAttribute : AuthorizeAttribute
+{
+    private readonly string scope;
+
+    public ScopeAuthorizeAttribute(string scope)
+    {
+        this.scope = scope;
+    }
+
+    public override void OnAuthorization(HttpActionContext actionContext)
+    {
+        base.OnAuthorization(actionContext);
+
+        // Get the Auth0 domain, in order to validate the issuer
+        var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
+
+        // Get the claim principal
+        ClaimsPrincipal principal = actionContext.ControllerContext.RequestContext.Principal as ClaimsPrincipal;
+
+        // Get the scope clain. Ensure that the issuer is for the correcr Auth0 domain
+        var scopeClaim = principal?.Claims.FirstOrDefault(c => c.Type == "scope" && c.Issuer == domain);
+        if (scopeClaim != null)
+        {
+            // Split scopes
+            var scopes = scopeClaim.Value.Split(' ');
+
+            // Succeed if the scope array contains the required scope
+            if (scopes.Any(s => s == scope))
+                return;
+        }
+
+        HandleUnauthorizedRequest(actionContext);
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/files/startup.md b/ja-jp/articles/quickstart/backend/webapi-owin/files/startup.md
new file mode 100644
index 0000000000..5890cc00fd
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/files/startup.md
@@ -0,0 +1,28 @@
+---
+name: Startup.cs
+language: csharp
+---
+
+```csharp
+public void Configuration(IAppBuilder app)
+{
+    var domain = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
+    var apiIdentifier = ConfigurationManager.AppSettings["Auth0ApiIdentifier"];
+    var keyResolver = new OpenIdConnectSigningKeyResolver(domain);
+
+    app.UseJwtBearerAuthentication(
+        new JwtBearerAuthenticationOptions
+        {
+            AuthenticationMode = AuthenticationMode.Active,
+            TokenValidationParameters = new TokenValidationParameters()
+            {
+                ValidAudience = apiIdentifier,
+                ValidIssuer = domain,
+                IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid)
+            }
+        });
+
+    // Configure Web API
+    WebApiConfig.Configure(app);
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/index.yml b/ja-jp/articles/quickstart/backend/webapi-owin/index.yml
new file mode 100644
index 0000000000..9980953c84
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/index.yml
@@ -0,0 +1,48 @@
+title: ASP.NET Web API (OWIN)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet
+alias:
+  - owin
+languages:
+  - C#
+thirdParty: false
+framework:
+  - OWIN
+author:
+  name: Damien Guard
+  email: damien.guard@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+articles:
+  - 01-authorization
+  - 02-using
+  - 03-troubleshooting
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnet-owin-webapi-samples
+requirements:
+  - Microsoft Visual Studio 2015 Update 3
+  - System.IdentityModel.Tokens.Jwt NuGet Package v5.2.2
+  - Microsoft.Owin.Security.Jwt NuGet Package V4.0.0
+next_steps:
+  - path: 01-authorization
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/webapi-owin/interactive.md b/ja-jp/articles/quickstart/backend/webapi-owin/interactive.md
new file mode 100644
index 0000000000..956cd2da2d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/webapi-owin/interactive.md
@@ -0,0 +1,98 @@
+---
+title: Add Authorization to an ASP.NET Owin Web API application
+description: This tutorial demonstrates how to add authorization to an ASP.NET OWIN API using the standard JWT middleware.
+budicon: 448
+topics:
+  - quickstart
+  - backend
+  - webapi-owin
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/startup
+  - files/openid-connect-signing-key-resolver
+  - files/scope-authorize-attribute
+  - files/api-controller
+---
+
+# Add Authorization to Your ASP.NET Owin Web API Application
+Auth0 allows you to add authorization to any kind of application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET Owin Web API application using the `Microsoft.Owin.Security.Jwt` package.
+
+If you have not created an API in your Auth0 dashboard yet, you can use the interactive selector to create a new Auth0 API or select an existing API for your project. 
+
+To set up your first API through the Auth0 dashboard, review [our getting started guide](get-started/auth0-overview/set-up-apis).
+
+Each Auth0 API uses the API Identifier, which your application needs to validate the access token.
+
+
+
+<%= include('../../../_includes/_api_auth_intro') %>
+
+## Define permissions
+<%= include('../_includes/_api_scopes_access_resources') %>
+
+
+## Install dependencies
+
+Install the `Microsoft.Owin.Security.Jwt` NuGetPackage. This package contains the OWIN JWT Middleware necessary to use Auth0 access tokens in the ASP.NET Owin Web API.
+```bash
+Install-Package Microsoft.Owin.Security.Jwt
+```
+
+## Configure the middleware {{{ data-action=code data-code="Startup.cs" }}}
+
+Go to the `Configuration` method of your `Startup` class and add a call to `UseJwtBearerAuthentication` passing in the configured `JwtBearerAuthenticationOptions`.
+
+The `JwtBearerAuthenticationOptions` needs to specify your Auth0 API Identifier in the `ValidAudience` property, and the full path to your Auth0 domain as the `ValidIssuer`. You will need to configure the `IssuerSigningKeyResolver` to use the instance of `OpenIdConnectSigningKeyResolver` to resolve the signing key:
+
+::: panel-warning Do not forget the trailing slash
+Ensure the URL specified for `ValidIssuer` contains a trailing forward slash (`/`). This must match exactly with the JWT issuer claim. API calls will not authenticate correctly if you misconfigured this value.
+:::
+
+## Verifying the token signature {{{ data-action=code data-code="OpenIdConnectSigningKeyResolver.cs" }}}
+The OWIN JWT middleware does not use Open ID Connect Discovery by default, so you must provide a custom `IssuerSigningKeyResolver`. Create the `OpenIdConnectSigningKeyResolver` class and ensure to return the correct `SecurityKey` by implementing `GetSigningKey`.
+This class is then used as `TokenValidationParameters.IssuerSigningKeyResolver` while configuring the middleware in `Startup.cs`.
+
+:::note
+This custom resolver is deprecated and [no longer available](https://github.com/auth0/auth0-aspnet-owin/blob/master/SECURITY-NOTICE.md). You must provider this customer resolver yourself.
+:::
+
+## Validate scopes {{{ data-action=code data-code="ScopeAuthorizeAttribute.cs" }}}
+
+The JWT middleware verifies that the access token included in the request is valid; however, it doesn't yet include any mechanism for checking that the token has the sufficient **scope** to access the requested resources.
+
+Create a class called `ScopeAuthorizeAttribute` which inherits from `System.Web.Http.AuthorizeAttribute`. This attribute will check that the `scope` claim issued by your Auth0 tenant is present, and if so it will ensure that the `scope` claim contains the requested scope.
+
+## Protect API endpoints {{{ data-action=code data-code="ApiController.cs" }}}
+
+<%= include('../_includes/_api_endpoints') %>
+
+The JWT middleware integrates with the standard ASP.NET authentication and authorization mechanisms, so you only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint.
+
+Update the action with the `ScopeAuthorize` attribute and pass the name of the required `scope` in the `scope` parameter. This ensures the correct scope is available to call a specific API endpoing.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured your application, run your application to verify that:
+* `GET /api/public` is available for non-authenticated requests.
+* `GET /api/private` is available for authenticated requests.
+* `GET /api/private-scoped` is available for authenticated requests containing an access token with the `read:messages` scope.
+
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Ensure your configured the  `ValidIssuer` and `ValidAudience` values correctly
+* Verify you added the token as the `Authorization` header
+* Ensure the token has the correct scopes. Verify with [jwt.io](https://jwt.io/).
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/config.yml b/ja-jp/articles/quickstart/config.yml
new file mode 100644
index 0000000000..a99856f831
--- /dev/null
+++ b/ja-jp/articles/quickstart/config.yml
@@ -0,0 +1,4 @@
+author:
+  name: Auth0
+  email: support@auth0.com
+  community: false
diff --git a/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md b/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md
new file mode 100644
index 0000000000..ef210437db
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md
@@ -0,0 +1,11 @@
+First, you will create a rule that assigns users to either an `admin` role, or a single `user` role. Go to the [New Rule](${manage_url}/#/rules/new) page on the Auth0 dashboard and select the **Set Roles To A User** template, under **Access Control**.
+
+By default, this rule will assign the user an `admin` role if their email contains `@example.com`. Otherwise, they will be assigned a regular `user` role.
+
+You can modify this line in the default script to change the domain name to one suitable for your setup:
+
+`if (user.email.indexOf('@example.com') > -1)`
+
+::: note
+You can set roles other than `admin` and `user` or customize the rule as needed.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md b/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md
new file mode 100644
index 0000000000..a96342dad8
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md
@@ -0,0 +1,5 @@
+Many identity providers will supply access claims, like roles or groups, with the user. You can request these in the token by setting `scope: openid roles` or `scope: openid groups`. However, not every identity provider supplies this type of information. Fortunately, Auth0 has an alternative, which is to create a rule for assigning different roles to different users.
+
+::: note
+This tutorial assumes that you have already completed the [rules tutorial](${ruleslink}) and that you know how to implement a basic rule in your app.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md b/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md
new file mode 100644
index 0000000000..8b41d237de
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md
@@ -0,0 +1,9 @@
+
+
+A callback URL is a URL in your application where Auth0 redirects the user after they have been authenticated. Auth0 adds parameters to the callback URL, including a token. 
+
+Callback URLs can be manipulated by attackers. For security, add your application's URL to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). 
+
+If you do not add your application's URL to the list of Allowed Callback URLs, your users will see a mismatch error when they try to log in.
+
+![Callback error](/media/articles/angularjs/callback_error.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md
new file mode 100644
index 0000000000..755ffb537d
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md
@@ -0,0 +1,7 @@
+## Create an Auth0 API
+
+In the [APIs section](${manage_url}/#/apis) of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API.
+You will use the identifier later when you're preparing the Web Authentication.
+For **Signing Algorithm**, select **RS256**.
+
+![Create API](/media/articles/api-auth/create-api.png)
diff --git a/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md
new file mode 100644
index 0000000000..6ea9af9d0b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md
@@ -0,0 +1,11 @@
+## Add a Scope
+
+By default, the Access Token does not contain any authorization information. To limit access to your resources based on authorization, you must use scopes. Read more about scopes in the [scopes documentation](/scopes).
+
+In the Auth0 dashboard, in the [APIs section](${manage_url}/#/apis), click **Scopes**. Add any scopes you need to limit access to your API resources.
+
+::: note
+You can give any names to your scopes. A common pattern is `:`. The example below uses the name `read:messages` for a scope.
+:::
+
+![create scope](/media/articles/api-auth/create-scope.png)
diff --git a/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md b/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md
new file mode 100644
index 0000000000..2c03b6254d
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md
@@ -0,0 +1,30 @@
+To integrate Auth0 in a hybrid Cordova application, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in its settings.
+
+${snippet(meta.snippets.dependencies)}
+
+${snippet(meta.snippets.setup)}
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_create_application.md b/ja-jp/articles/quickstart/native/_includes/_create_application.md
new file mode 100644
index 0000000000..a91678b6e6
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_create_application.md
@@ -0,0 +1,3 @@
+## Create an application
+
+Create a new application in your [Auth0 dashboard](${manage_url}/#/application). For **Type**, select **Native**.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md b/ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md b/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md
new file mode 100644
index 0000000000..9a6db5a92e
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md
@@ -0,0 +1,62 @@
+## Set up the “Continue with Facebook” button
+
+This guide will help you add authentication with Auth0 to the application you built in the first step.
+
+### Request Facebook permissions
+
+Your application is already able to sign in with Facebook. However, to ensure you have a rich user profile, you need to update the permissions with which the Facebook Login Button was set up.
+
+${snippet(meta.snippets.facebook_button_permissions)}
+
+Now, to kick off the authentication process with Auth0, create a new method in which you will prepare the payload to be sent. 
+
+${snippet(meta.snippets.facebook_button_config)}
+
+## Integrate Facebook
+
+When you sign in with Facebook at Auth0, the backend will perform some checks in the background to ensure the user is who they say they are. To achieve this, it needs to be provided with a Session Access Token. 
+
+Furthermore, if a user needs to be created on Auth0 to represent this Facebook user, the backend will require some of their information, such as their name, last name, and email. The email, if provided, will be **flagged as non-verified** on the Auth0 user profile.
+
+To obtain the Session Access Token and the user profile, two additional requests need to be made against the Facebook API.
+
+### Fetch Facebook session Access Token
+
+Make a new GET request against the Facebook API's `/oauth/access_token` endpoint.
+Use the following query parameters:
+- `grant_type`: `fb_attenuate_token`.
+- `fb_exchange_token`: the access token received upon login.
+- `client_id`: your App ID. This value comes from the Facebook Developer's dashboard and should already be in use in your application if you have integrated Facebook Login successfully.
+
+Put the logic from this step in its own method. You will be calling it later from the previously-added method.
+
+${snippet(meta.snippets.facebook_fetch_session_token)}
+
+### Fetch Facebook user profile
+
+Now make another GET request, just like in the step above. The endpoint path will be the User ID value from the Facebook login result (for example, `/904636746222815`).
+Use the following parameters:
+- `access_token`: the access token received upon login.
+- `fields`: the fields from the user profile that you'd like to get back in the response. These are directly tied to the Facebook Login Button permissions that were configured at the beginning. When a permission is optional, the user must first consent to give access to it. For the purpose of signing up a user at Auth0, their full name and email will suffice. 
+
+${snippet(meta.snippets.facebook_fetch_profile)}
+
+## Integrate Auth0
+
+Now that the required artifacts have been obtained, you are ready to trade them for Auth0 user credentials, such as the ID and Access Tokens. But first, you must set up the Auth0 SDK to make that last request.
+
+### Get your application keys
+
+Go to the **Applications** section of the [Auth0 Dashboard](https://manage.auth0.com/) and select the existing application in which you enabled **Sign in with Facebook**. If you need help with this step, please check the requirements section at the top of this article.
+
+Copy the **Domain** and **Client ID** values from the application settings page. These are required by the SDK.
+
+${snippet(meta.snippets.facebook_app_credentials)}
+
+### Install the Auth0 SDK
+
+${snippet(meta.snippets.facebook_install_auth0_sdk)}
+
+### Exchange the received data for Auth0 tokens
+
+${snippet(meta.snippets.facebook_token_exchange)}
diff --git a/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md b/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
new file mode 100644
index 0000000000..ae286d7f70
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
@@ -0,0 +1,6 @@
+This tutorial describes how to implement login with the [Facebook SDK](https://developers.facebook.com/docs/).
+​
+## Before You Start
+​
+- Install and configure the [Facebook Login SDK](https://developers.facebook.com/docs/facebook-login/). You’ll also go through the process of creating a Facebook app in [https://developers.facebook.com](https://developers.facebook.com). **When you finish this step, you should have a mobile app running with Facebook Login integrated.**  
+- Configure your Auth0 application in the dashboard to use Facebook Native Sign In. See [Add Facebook Login to Native Apps](/connections/nativesocial/facebook). **When you finish this step, your application will be able to implement Facebook Native Login.**
diff --git a/ja-jp/articles/quickstart/native/_includes/_getting_started.md b/ja-jp/articles/quickstart/native/_includes/_getting_started.md
new file mode 100644
index 0000000000..23cbcdbe4f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_getting_started.md
@@ -0,0 +1,7 @@
+::: note
+**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Native Applications](/architecture-scenarios/application/mobile-api) and which [protocol](/api-auth/grant/authorization-code-pkce) it uses.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+
diff --git a/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md b/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md
new file mode 100644
index 0000000000..9638a40d51
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md
@@ -0,0 +1,57 @@
+To integrate Auth0 in a hybrid Ionic app, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the application settings.
+
+## Install the Dependencies
+
+The required dependencies for using Auth0 in an Ionic application are **auth0.js** and **auth0-cordova**. Install them with npm or yarn.
+
+```bash
+# installation with npm
+npm install auth0-js @auth0/cordova --save
+
+# installation with yarn
+yarn add auth0-js @auth0/cordova
+```
+
+## Add Cordova Plugins
+
+You must install the `SafariViewController` plugin from Cordova to be able to use Universal Login. The downloadable sample project already has this plugin added, but if you are embedding Auth0 in your own application, install the plugin via the command line.
+
+```bash
+ionic cordova plugin add cordova-plugin-safariviewcontroller
+```
+
+The `CustomURLScheme` plugin from Cordova is also required to handle redirects properly. The sample project has it already, but if you're adding Auth0 to your own project, install this plugin as well.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app identifier
+ionic cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_HOST=${account.namespace} --variable ANDROID_PATHPREFIX=/cordova/{YOUR_PACKAGE_ID}/callback
+```
+
+## Modify config.xml
+
+Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_config.md b/ja-jp/articles/quickstart/native/_includes/_ios_config.md
new file mode 100644
index 0000000000..d5e5a479a9
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_config.md
@@ -0,0 +1,62 @@
+
+
+## Add Auth0 Credentials
+
+You will need some details about this application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 dashboard.
+
+You need the following information: 
+* **Client ID**
+* **Domain**
+
+::: note
+If you download the sample from the top of this page, these details are filled out for you.
+:::
+
+Add your credentials in `Auth0.plist`. If the file does not exist in your project yet, create one with the information below ([Apple documentation on Property List Files](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)):
+
+```xml
+
+
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+<%= include('../../../_includes/_callback_url') %>
+
+In your application's `Info.plist` file, register your iOS Bundle identifier as a custom scheme:
+
+```xml
+
+
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        auth0
+        CFBundleURLSchemes
+        
+            $(PRODUCT_BUNDLE_IDENTIFIER)
+        
+    
+
+```
+
+::: note
+If your `Info.plist` file is not in the format shown above, you can right-click `Info.plist` in Xcode and select **Open As** > **Source Code**.
+:::
+
+Go to your [Dashboard Settings](${manage_url}/#/applications/${account.clientId}/settings) and make sure that the **Allowed Callback URLs** field contains the following callback URL:
+
+```text
+{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback
+```
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md b/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md
new file mode 100644
index 0000000000..86e62af190
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md
@@ -0,0 +1,49 @@
+
+
+## Install Dependencies
+
+### Cocoapods
+
+If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 1.0'
+```
+
+Then run `pod install`.
+
+::: note
+For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Carthage
+
+If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`:
+
+```ruby
+github "auth0/Auth0.swift" ~> 1.0
+```
+
+Then run `carthage bootstrap`.
+
+::: note
+For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+:::
+
+### SPM
+
+If you are using the Swift Package Manager, open the following menu item in Xcode:
+
+**File > Add Packages...**
+
+In the **Search or Enter Package URL** search box enter this url: 
+
+```text
+https://github.com/auth0/Auth0.swift.git
+```
+
+Then select the dependency rule and press **Add Package**.
+
+::: note
+For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/swift_packages/adding_package_dependencies_to_your_app).
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md b/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md
new file mode 100644
index 0000000000..956318d9bb
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md
@@ -0,0 +1,6 @@
+## Link the Accounts
+
+Now, you can link the accounts. To do this, you need the following values: 
+- `id`: the logged-in user's ID (see `profile.sub`)
+- `accessToken`: a Management API access token for the saved account the user initially logged in to; must have the `update:current_user_identities` scope
+- `otherUserToken`: the ID Token for the second account received in the last login response
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md b/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md
new file mode 100644
index 0000000000..c4c1ea1510
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md
@@ -0,0 +1,5 @@
+## Unlink the Accounts
+
+To unlink the accounts, you need to specify the following: 
+* `id`: the logged-in user's ID (see `profile.sub`)
+* `userId` and `provider`: the values in the `identity` object you want to unlink
diff --git a/ja-jp/articles/quickstart/native/_includes/_new_app.html b/ja-jp/articles/quickstart/native/_includes/_new_app.html
new file mode 100644
index 0000000000..6b84b0d4e5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_new_app.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
    Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store somewhere safe. You will need them while configuing Angular in your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.
    
+<% } else { %>
+  
    Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start be downloading the sample after you login as it is configured with your `Default App` credentials
    
+<% } %>
diff --git a/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html b/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html
new file mode 100644
index 0000000000..039e33abfb
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
    Get your credentials (Domain, Client ID, and Client Secret) from the dashboard. Be sure to select Native as the Application Type. 
+<% } else { %>
+  
    Create an Auth0 account (or login) and add an authentication application instance from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). Be sure to select Native as the Application Type.
+<% } %>
diff --git a/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md b/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..c5503ba31a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md
@@ -0,0 +1 @@
+Auth0 allows you to store user information that has not come from the identity provider as metadata. There are two types of metadata, **user_metadata** and **app_metadata**. For more information, see: [Metadata](/users/concepts/overview-user-metadata).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md b/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md
new file mode 100644
index 0000000000..32426a0548
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md
@@ -0,0 +1,11 @@
+To create a rule, go to the [New Rule](${manage_url}/#/rules/new) page. You can create a rule from scratch by selecting an empty rule, or use one of the existing templates. These templates are written by Auth0 to assist you to in executing common tasks. 
+
+For this example, select the **Add country to the user profile** rule.
+
+![Empty rule](/media/articles/rules/rule-choose-add-country-template.png)
+
+This rule extracts the `country_name` from the `context` and adds it to the user profile as a new `country` attribute.
+
+![Add country rule](/media/articles/rules/rule-create-add-country-country.png)
+
+This is just the beginning, you can edit the rule to meet your business needs. Once complete, click **Save**. The rule will execute any time a user logs in, and the country will be added to the user's profile.
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md b/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md
new file mode 100644
index 0000000000..ffd19a504a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md
@@ -0,0 +1 @@
+Rules are one of the most powerful features of Auth0. As JavaScript functions that execute each time a user authenticates, rules serve as middleware to extend the flexibility of your authentication flow. For a detailed description of rules, see the [full documentation](/rules).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md b/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md
new file mode 100644
index 0000000000..af8850b325
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md
@@ -0,0 +1,3 @@
+To see the results of a created rule, login and fetch user profile information as explained in the [User Profile](${profilelink}) step.
+
+Then you can display the user profile's new `country` attribute added by the rule:
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md
new file mode 100644
index 0000000000..368ce98b12
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md
@@ -0,0 +1,7 @@
+
+
+In a Capacitor application, the [Capacitor's Browser plugin](https://capacitorjs.com/docs/apis/browser) performs a redirect to the Auth0 [Universal Login Page](https://auth0.com/universal-login). Set the `openUrl` parameter on the `loginWithRedirect` function to use `Browser.open` so that the URL is opened using the device's system browser component ([SFSafariViewController](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) on iOS, and [Chrome Custom Tabs](https://developer.chrome.com/docs/android/custom-tabs) on Android).
+
+:::note
+By default, the SDK's `loginWithRedirect` method uses `window.location.href` to navigate to the login page in the default browser application on the user's device rather than the system browser component appropriate for the platform. The user would leave your application to authenticate and could make for a suboptimal user experience.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md
new file mode 100644
index 0000000000..0cf81e522f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md
@@ -0,0 +1,13 @@
+
+
+Now that users can log in, you need to configure [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Users must redirect to the Auth0 logout endpoint in the browser to clear their browser session. Again, Capacitor's Browser plugin should perform this redirect so that the user does not leave your app and receive a suboptimal experience.
+
+To achieve this with Ionic and Capacitor in conjunction with the Auth0 SDK:
+
+* Construct the URL for your app Auth0 should use to redirect to after logout. This is a URL that uses your registered custom scheme and Auth0 domain. Add it to your **Allowed Logout URLs** configuration in the Auth0 Dashboard
+* Logout from the SDK by calling `logout`, and pass your redirect URL back as the `logoutParams.returnTo` parameter.
+* Set the `openUrl` parameter to a callback that uses the Capacitor browser plugin to open the URL using `Browser.open`. 
+
+:::note
+Similar to the login step, if you do not set `openUrl` when calling `logout`, the SDK redirects the user to the logout URL using the default browser application on the device, which provides a suboptimal user experience.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md
new file mode 100644
index 0000000000..df7c935695
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md
@@ -0,0 +1,7 @@
+
+
+## Getting started
+
+This quickstart assumes you already have an [Ionic](https://ionicframework.com/) application up and running with [Capacitor](https://capacitorjs.com/). If not, check out the [Using Capacitor with Ionic Framework guide](https://capacitorjs.com/docs/getting-started/with-ionic) to get started with a simple app, or clone [our sample apps](https://github.com/auth0-samples/auth0-ionic-samples).
+
+You should also be familiar with the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow).
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md
new file mode 100644
index 0000000000..e17a9f3f2a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md
@@ -0,0 +1,35 @@
+
+
+<%= include('../../../../_includes/_callback_url') %>
+
+:::note
+Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info.
+:::
+
+Go to the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+You should set the **Allowed Callback URL** to:
+
+```bash
+YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback
+```
+
+<%= include('../../../../_includes/_logout_url') %>
+
+You should set the **Allowed Logout URLs** to
+
+```bash
+YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback
+```
+
+### Configure Origins
+
+To be able to make requests from your application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+```bash
+capacitor://localhost, http://localhost
+```
+
+These origins are required for iOS and Android respectively.
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md
new file mode 100644
index 0000000000..b3ffd9d464
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md
@@ -0,0 +1,43 @@
+
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project.
+
+:::note
+Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info.
+:::
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback`
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback`.
+:::
+
+### Configure Allowed Origins
+
+To be able to make requests from your native application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+::: note
+If you are following along with our sample project, set this to `capacitor://localhost, http://localhost` for iOS and Android respectively.
+:::
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md
new file mode 100644
index 0000000000..eaa4e75188
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md
@@ -0,0 +1,7 @@
+
+
+Once users logs in with the Universal Login Page, they redirect back to your app via a URL with a custom URL scheme. The `appUrlOpen` event must be handled within your app. You can call the `handleRedirectCallback` method from the Auth0 SDK to initialize the authentication state.
+
+You can only use this method on a redirect from Auth0. To verify success, check for the presence of the `code` and `state` parameters in the URL.
+
+The `Browser.close()` method should close the browser when this event is raised.
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md b/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md
new file mode 100644
index 0000000000..b0e37b311a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md
@@ -0,0 +1,16 @@
+
+
+### Install Capacitor plugins
+
+This quickstart and sample make use of some of Capacitor's official plugins. Install these into your app using the following command:
+
+```bash
+npm install @capacitor/browser @capacitor/app
+```
+
+- [`@capacitor/browser`](https://capacitorjs.com/docs/apis/browser) - allows you to interact with the device's system browser and is used to open the URL to Auth0's authorizaction endpoint
+- [`@capacitor/app`](https://capacitorjs.com/docs/apis/app) - allows you to subscribe to high-level app events, useful for handling callbacks from Auth0
+
+:::note
+Capacitor's Browser plugin on iOS uses [`SFSafariViewController`](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller), which on iOS 11+ does not share cookies with Safari on the device. This means that [SSO](https://auth0.com/docs/sso) will not work on those devices. If you need SSO, please instead use a compatible plugin that uses [ASWebAuthenticationSession](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession).
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md b/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md
new file mode 100644
index 0000000000..b5002538c0
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md
@@ -0,0 +1,5 @@
+
+
+:::note
+This article assumes you will be using Custom URL Schemes to handle the callback within your application. To do this, register your `YOUR_PACKAGE_ID` as a URL scheme for your chosen platform. To learn more, read [Defining a Custom URL Scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) for iOS, or [Create Deep Links to App Content](https://developer.android.com/training/app-links/deep-linking) for Android.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md b/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md
new file mode 100644
index 0000000000..89e9cde61f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md
@@ -0,0 +1,9 @@
+
+
+:::warning
+To persist authentication after closing and reopening the application, you may want to set `cacheLocation` to `localstorage` when configuring the SDK, but please be aware of [the risks of storing tokens in localstorage](https://auth0.com/docs/libraries/auth0-single-page-app-sdk#change-storage-options). Also, localstorage should be treated as **transient** in Capacitor app as the data might be recovered unexpectedly in certain circumstances. Please read the [guidance on storage in the Capacitor docs](https://capacitorjs.com/docs/guides/storage#why-cant-i-just-use-localstorage-or-indexeddb).
+
+Additionally, the SDK has the ability to [use a custom cache implementation](https://github.com/auth0/auth0-spa-js/blob/master/EXAMPLES.md#creating-a-custom-cache) to store tokens, if you have a requirement to use a more secure and persistent storage mechanism.
+
+**Note** that we recommend **against** using [Capacitor's Storage plugin](https://capacitorjs.com/docs/apis/storage) to store tokens, as this is backed by [UserDefaults](https://developer.apple.com/documentation/foundation/userdefaults) and [SharedPreferences](https://developer.android.com/reference/android/content/SharedPreferences) on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud.
+:::
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md b/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md
new file mode 100644
index 0000000000..d0fc42be23
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md
@@ -0,0 +1,23 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an Android application using native Facebook Login.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - android
+  - facebook native
+github:
+  path: 00-login-facebook
+contentType: tutorial
+useCase: quickstart
+requirements:
+  - Android Studio 3.6.1
+  - Android SDK 25
+  - Emulator - Nexus 5X - Android 6.0
+---
+
+
+
+<%= include('../_includes/_facebook_login_prerequisites') %>
+<%= include('../_includes/_facebook_login_howto') %>
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/download.md b/ja-jp/articles/quickstart/native/android-facebook-login/download.md
new file mode 100644
index 0000000000..20fbcf5b47
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/download.md
@@ -0,0 +1,16 @@
+To run it from the **command line**:
+
+1) Make sure the target device is available and install the App running the next command:
+
+```bash
+# In Linux / macOS
+./gradlew installDebug
+# In Windows
+gradlew installDebug
+```
+2) On the Android device, locate the App icon on the App Drawer and click it to launch it.
+
+To run it from the **Android Studio IDE**:
+
+1) Open the project on [Android Studio](https://developer.android.com/studio/index.html). 
+2) Click the `Run` button (The green play) or select the menu option `Run | Run 'app'`, and then choose a target device.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/index.yml b/ja-jp/articles/quickstart/native/android-facebook-login/index.yml
new file mode 100644
index 0000000000..28ad3647d3
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/index.yml
@@ -0,0 +1,53 @@
+title: Android - Facebook Login
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.s
+image: /media/platforms/android.png
+logo_name: android
+logo: android
+alias:
+  - Android
+language:
+  - Java
+hybrid: false
+author:
+  name: Luciano Balmaceda
+  email: luciano.balmaceda@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: android-facebook-login
+snippets:
+  facebook_button_permissions: native-platforms/android-facebook-login/facebook-button-permissions
+  facebook_button_config: native-platforms/android-facebook-login/facebook-button-config
+  facebook_fetch_session_token: native-platforms/android-facebook-login/facebook-fetch-session-token
+  facebook_fetch_profile: native-platforms/android-facebook-login/facebook-fetch-profile
+  facebook_app_credentials: native-platforms/android-facebook-login/facebook-app-credentials
+  facebook_install_auth0_sdk: native-platforms/android-facebook-login/facebook-install-auth0-sdk
+  facebook_token_exchange: native-platforms/android-facebook-login/facebook-token-exchange
+default_article: 00-login-facebook
+articles:
+  - 00-login-facebook
+next_steps:
+  - path: 00-login-facebook
+    list:
+    - text: Learn how to securely store tokens
+      icon: 345
+      href: "/libraries/auth0-android/save-and-refresh-tokens"
+    - text: Learn to call an API
+      icon: 345
+      href: "/quickstart/native/android/01-user-metadata"
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Learn more about the Android SDK
+      icon: 345
+      href: "/libraries/auth0-android"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-android-native-social-sample
+requirements:
+  - Android Studio 3.6.1
+  - Android SDK 25
+  - Emulator - Nexus 5X - Android 6.0
diff --git a/ja-jp/articles/quickstart/native/android/00-login.md b/ja-jp/articles/quickstart/native/android/00-login.md
new file mode 100755
index 0000000000..36bdc1e9a5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/00-login.md
@@ -0,0 +1,246 @@
+---
+title: Login
+description: This quickstart demonstrates how to add user login to an Android application using Auth0.
+seo_alias: android
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - android
+github:
+  path: 00-Login-Kt
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/_getting_started', { library: 'Android' }) %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+::: note
+If you are following along with the sample project you downloaded from the top of this page, you should set the **Allowed Callback URL** to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`.
+:::
+
+Replace `YOUR_APP_PACKAGE_NAME` with your application's package name, available as the `applicationId` attribute in the `app/build.gradle` file.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'demo://' + account.namespace + '/android/YOUR_APP_PACKAGE_NAME/callback' }) %>
+
+Replace `YOUR_APP_PACKAGE_NAME` with your application's package name, available as the `applicationId` attribute in the `app/build.gradle` file.
+
+## Install the Auth0 Android SDK
+
+Add the [Auth0 Android](https://github.com/auth0/Auth0.Android) SDK into your project. The library will make requests to the Auth0's Authentication and Management APIs.
+
+### Add Auth0 to Gradle
+
+In your app's `build.gradle` dependencies section, add the following:
+
+```groovy
+dependencies {
+  // Add the Auth0 Android SDK
+  implementation 'com.auth0.android:auth0:2.+'
+}
+```
+
+In the android section, target Java 8 byte code for Android and Kotlin plugins respectively.
+
+```groovy
+android {
+  compileOptions {
+    sourceCompatibility JavaVersion.VERSION_1_8
+    targetCompatibility JavaVersion.VERSION_1_8
+  }
+  kotlinOptions {
+    jvmTarget = '1.8'
+  }
+}
+```
+
+::: panel Sync Project with Gradle Files
+Remember to synchronize using the Android Studio prompt or run `./gradlew clean build` from the command line. For more information about Gradle usage, check [their official documentation](http://tools.android.com/tech-docs/new-build-system/user-guide).
+:::
+
+Add manifest placeholders required by the SDK. The placeholders are used internally to define an `intent-filter` that captures the authentication callback URL. For this, the Auth0 tenant domain and the scheme that take part in the callback URL must be set.
+
+::: note
+We've used a value of `demo` for `auth0Scheme` here, so that a custom URL scheme can be used for the URL that Auth0 redirects to after login. The alternative is `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK readme](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking).
+:::
+
+To add the manifest placeholders, add the next line:
+
+```groovy
+// app/build.gradle
+
+apply plugin: 'com.android.application'
+compileSdkVersion 30
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion 30
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"]
+        // <---
+    }
+}
+```
+
+::: note
+You do not need to declare a specific `intent-filter` for your activity, because you have defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values and the library will handle the redirection for you.
+:::
+
+Finally, ensure that the `android.permissions.INTERNET` permission is specified in the `AndroidManifest.xml` file:
+
+```xml
+
+```
+
+Run **Sync Project with Gradle Files** inside Android Studio or execute `./gradlew clean assembleDebug` from the command line.
+
+::: note
+For more information about using Gradle, check the [Gradle official documentation](https://gradle.org/getting-started-android-build/).
+:::
+
+## Add Login to your App
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features.
+
+In the `onCreate` method, create a new instance of the `Auth0` class to hold user credentials:
+
+```kotlin
+// Import the parts needed by the SDK
+import com.auth0.android.Auth0
+import com.auth0.android.provider.WebAuthProvider
+
+class MainActivity : AppCompatActivity() {
+
+  private lateinit var account: Auth0
+
+  override fun onCreate(savedInstanceState: Bundle?) {
+      super.onCreate(savedInstanceState)
+
+      // Set up the account object with the Auth0 application details
+      account = Auth0(
+          "${account.clientId}",
+          "${account.namespace}"
+      )
+  }
+}
+```
+
+:::note
+We suggest you do not hardcode the values for `clientId` and `domain` as you may need to change them in the future. Instead, use [String Resources](https://developer.android.com/guide/topics/resources/string-resource.html), such as `@string/com_auth0_domain`, to define the values.
+:::
+
+Finally, create a `loginWithBrowser` method and use the `WebAuthProvider` class to authenticate with any connection you enabled on your application in the [Auth0 dashboard](${manage_url}/#/). Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration:
+
+```kotlin
+private fun loginWithBrowser() {
+    // Setup the WebAuthProvider, using the custom scheme and scope.
+
+    WebAuthProvider.login(account)
+        .withScheme("demo")
+        .withScope("openid profile email")
+        // Launch the authentication passing the callback where the results will be received
+        .start(this, object : Callback {
+            // Called when there is an authentication failure
+            override fun onFailure(exception: AuthenticationException) {
+                // Something went wrong!
+            }
+
+            // Called when authentication completed successfully
+            override fun onSuccess(credentials: Credentials) {
+              // Get the access token from the credentials object.
+              // This can be used to call APIs
+              val accessToken = credentials.accessToken
+            }
+        })
+}
+```
+
+After you call the `WebAuthProvider#start` function, the browser launches and shows the login page. Once the user authenticates, the callback URL is called. The callback URL contains the final result of the authentication process.
+
+:::note
+There are many options to customize the authentication with the `WebAuthProvider` builder. You can read about them in the [Auth0 SDK for Android documentation](/libraries/auth0-android).
+
+
    
+  Universal Login
+
    
+:::
+
+:::panel Checkpoint
+Add a button to your application that calls `loginWithBrowser`. When you click it, verify that your Android application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects back to your app.
+:::
+
+## Add Logout to your App
+
+Use `WebAuthProvider` to remove the cookie set by the Browser at authentication time, so that the users are forced to re-enter their credentials the next time they try to authenticate.
+
+Add a `logout` method to your app to remove the user's session and log them out of the app. Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration:
+
+```kotlin
+private fun logout() {
+  WebAuthProvider.logout(account)
+    .withScheme("demo")
+    .start(this, object: Callback {
+      override fun onSuccess(payload: Void?) {
+        // The user has been logged out!
+      }
+
+      override fun onFailure(error: AuthenticationException) {
+        // Something went wrong!
+      }
+    })
+}
+```
+
+The logout is achieved by using the `WebAuthProvider` class. This call will open the Browser and navigate the user to the logout endpoint. If the log out is cancelled, you might want to take the user back to where they were before attempting to log out.
+
+:::panel Checkpoint
+Add a button to your app that calls `logout` and logs the user out of your application. When you click it, verify that your Android app redirects you logout page and back again, and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+Use the `AuthenticationAPIClient` class to [retrieve the user's profile from Auth0](https://auth0.com/docs/users/user-profiles#user-profile-management-api-access). This requires:
+
+- The access token as received during the login phase
+- The `profile` scope to be included when `WebAuthProvider.login` is called
+
+The `email` scope must also be specified if the user's email address is to be retrieved.
+
+:::note
+This quickstart sets the `openid profile email` scopes by default during the login step above.
+:::
+
+The following demonstrates a function that can be used to retrieve the user's profile and show it on the screen:
+
+```kotlin
+private fun showUserProfile(accessToken: String) {
+  var client = AuthenticationAPIClient(account)
+
+  // With the access token, call `userInfo` and get the profile from Auth0.
+  client.userInfo(accessToken)
+    .start(object : Callback {
+        override fun onFailure(exception: AuthenticationException) {
+            // Something went wrong!
+        }
+
+        override fun onSuccess(profile: UserProfile) {
+          // We have the user's profile!
+          val email = profile.email
+          val name = profile.name
+        }
+  })
+}
+```
+
+:::panel Checkpoint
+Call the `showUserProfile` function after login and verify that the user's profile information has been returned in the `onSuccess` callback.
+:::
diff --git a/ja-jp/articles/quickstart/native/android/01-user-metadata.md b/ja-jp/articles/quickstart/native/android/01-user-metadata.md
new file mode 100644
index 0000000000..8ed1322a43
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/01-user-metadata.md
@@ -0,0 +1,127 @@
+---
+title: User Metadata
+description: This quickstart demonstrates how to make API calls to the Auth0 Management API to read and update user metadata.
+seo_alias: android
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - android
+  - api
+github:
+  path: 00-Login-Kt
+sample_download_required_data:
+  - client
+  - api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+::: note
+Before you continue with this tutorial, make sure that you have completed the [Login chapter](/quickstart/native/android)
+:::
+
+As an example of using the SDK to call APIs that may require custom scopes and audiences, we will demonstrate these settings by reading and updating user profile information.
+
+## Read User Metadata
+
+In [the previous chapter](/quickstart/native/android/00-login#show-user-profile-information), you saw how to access [basic user profile information](https://auth0.com/docs/users/user-profiles) using the `/userinfo` endpoint. This profile information may not include everything about a user that you might need. For example, in order to access the user's metadata, you must make an API call to the Management API using the user ID and the access token. With the Android SDK, this is done using the `UsersAPIClient` object.
+
+To be able to correctly read and update the user metadata, ensure the authorization server allows you to read and edit the current user profile by specifying the `openid profile email read:current_user update:current_user_metadata` scopes. In addition, specify the audience for the [Auth0 Management API](https://auth0.com/docs/api), which happens to include the User Info audience as well.
+
+Find the code in your project that initializes the `WebAuthProvider` class, and make the following changes if necessary:
+
+* amend the argument given to `withScope` to be `openid profile email offline_access read:current_user update:current_user_metadata`
+* add a call to `withAudience` and pass the audience for the Auth0 Management API: `https://${account.namespace}/api/v2/` (please note the trailing slash - this is required)
+
+```kotlin
+WebAuthProvider.login(account)
+  .withScheme("demo")
+  // modify the scopes to enable read and write of user_metadata
+  .withScope("openid profile email read:current_user update:current_user_metadata")
+  // specify the audience for the Auth0 Management API  
+  .withAudience("https://${account.namespace}/api/v2/")
+  .start(this, /* .. callback .. */)
+```
+
+:::note
+In the case of the Auth0 Management API, the `read:current_user` and `update:current_user_metadata` scopes let you get an access token that can retrieve user details and update the user's information. In the case of your APIs, you'll define custom [API scopes](https://auth0.com/docs/scopes/current/api-scopes) to implement access control, and you'll identify them in the calls that your client applications make to that API.
+
+In addition, in the case of the Auth0 Management API, the audience is `https://${account.namespace}/api/v2/`. In the case of your APIs, you create an _Identifier_ value that serves as the _Audience_ value whenever you [set up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0.
+:::
+
+Once you have a `UserProfile` instance (retrieved by calling `userInfo` from the previous chapter), get the user's ID and then use the `UsersAPIClient` to get the full profile for the user in another `UserProfile` instance. This profile will include all of the previous user profile information, as well as additional fields such as `user_metadata` and `app_metadata`.
+
+:::note
+Fields such as `user_metadata` and `app_metadata` are not available on the user profile that is returned by calling `userInfo`, as these fields are [proprietary fields to Auth0](https://auth0.com/docs/users/normalized-user-profiles) and not part of the OIDC spec. You must call the [Auth0 Management API](https://auth0.com/docs/users/manage-user-metadata#management-api) to get these fields, which is what you are doing by using the `UsersAPIClient` in the snippet below.
+:::
+
+The metadata can then be retrieved by using the `getUserMetadata` method on the `UserProfile` object.
+
+```kotlin
+fun getUserMetadata(userId: String, accessToken: String) {
+  // Get the user ID and call the full getUser Management API endpoint, to retrieve the full profile information
+  // Create the user API client using the account details and the access token from Credentials
+  val usersClient = UsersAPIClient(account, accessToken)
+
+  // Get the full user profile
+  usersClient
+    .getProfile(userId)
+    .start(object: Callback {
+      override fun onFailure(exception: ManagementException) {
+          // Something went wrong!
+      }
+
+      override fun onSuccess(profile: UserProfile) {
+          // Retrieve the "country" field, if one appears in the metadata
+          val country = profile.getUserMetadata()["country"] as String?
+      }
+  })
+}
+```
+
+:::note
+At this stage, if you are logging in as a brand new user, they are unlikely to have a "country" field inside their metadata. You can [read more about how user metadata](https://auth0.com/docs/users/manage-user-metadata) is managed on our Docs site.
+:::
+
+:::panel Checkpoint
+Add the above code to your application at the point where you already get the basic user profile, and observe that you are able to get the "country" field, which may be empty if the user does not have that field in their user metadata. In the next section you will see how to update the user with this metadata using the Management API.
+:::
+
+## Update User Metadata
+
+Updating user metadata is done in a very similar fashion. Call the `updateMetadata` method on the `UsersAPIClient` object to update the metadata for a specific user. You must also supply a map of data that is used to update the user metadata with.
+
+```kotlin
+fun patchUserMetadata(userId: String, accessToken: String) {
+  // Create the UsersAPIClient with the account details
+  // and the access token from the Credentials object
+  val usersClient = UsersAPIClient(account, accessToken)
+
+  // Create a map of data to update the user metadata with.
+  // In this case, we're adding/updating a custom "country" field
+  val metadata = mapOf("country" to "United States")
+
+  // Call updateMetadata with the id of the user to update, and the map of data
+  usersClient.updateMetadata(userId, metadata)
+    .start(object: Callback {
+      override fun onFailure(exception: ManagementException) {
+          // Something went wrong!
+      }
+
+      override fun onSuccess(profile: UserProfile) {
+          // The metadata was updated and we're given the updated user profile.
+          // Retrieve the "country" field, if one appears in the metadata
+          val country = profile.getUserMetadata()["country"] as String?
+      }
+  })
+}
+```
+
+:::panel Checkpoint
+Add the above code to your application at the point where you already get the basic user profile, and observe that the `onSuccess` callback is executed. Then, re-run the code to _read_ the user metadata, and you should see that a value for "country" is now returned.
+
+You can also see the updated metadata in the [Auth0 Dashboard](https://manage.auth0.com) by [inspecting the user](https://auth0.com/docs/users/manage-users-using-the-dashboard) and looking at the metadata collection in your web browser.
+:::
diff --git a/ja-jp/articles/quickstart/native/android/download.md b/ja-jp/articles/quickstart/native/android/download.md
new file mode 100644
index 0000000000..62632e454f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample first set the **Callback URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+
+```text
+demo://${account.namespace}/android/com.auth0.androidsample/callback
+```
+
+To run the sample first set the **Logout URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+
+```text
+demo://${account.namespace}/android/com.auth0.androidsample/callback
+```
+
+Then, to run it from the **command line**:
+
+1) Make sure the target device is available and install the App running the next command:
+
+```bash
+# In Linux / macOS
+./gradlew installDebug
+# In Windows
+gradlew installDebug
+```
+
+2) On the Android device, locate the App icon on the App Drawer and click it to launch it.
+
+To run it from the **Android Studio IDE**:
+
+1) Open the project on [Android Studio](https://developer.android.com/studio/index.html). 
+2) Click the `Run` button (The green play) or select the menu option `Run | Run 'app'` and then choose a target device.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android/files/build.md b/ja-jp/articles/quickstart/native/android/files/build.md
new file mode 100644
index 0000000000..6ab782ff49
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/build.md
@@ -0,0 +1,25 @@
+---
+name: build.gradle
+language: groovy
+---
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion 30
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "demo"]
+        // <---
+    }
+}
+
+dependencies {
+  // Add the Auth0 Android SDK
+  implementation 'com.auth0.android:auth0:2.+'
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android/files/main.md b/ja-jp/articles/quickstart/native/android/files/main.md
new file mode 100644
index 0000000000..94497915cc
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/main.md
@@ -0,0 +1,77 @@
+---
+name: MainActivity.kt
+language: kotlin
+---
+```kotlin
+import com.auth0.android.Auth0
+import com.auth0.android.provider.WebAuthProvider
+
+class MainActivity : AppCompatActivity() {
+
+  private lateinit var account: Auth0
+
+  override fun onCreate(savedInstanceState: Bundle?) {
+    super.onCreate(savedInstanceState)
+
+    // Set up the account object with the Auth0 application details
+    account = Auth0(
+      getString(R.string.com_auth0_client_id),
+      getString(R.string.com_auth0_domain),
+    )
+  }
+
+  private fun loginWithBrowser() {
+    // Setup the WebAuthProvider, using the custom scheme and scope.
+
+    WebAuthProvider.login(account)
+      .withScheme("demo")
+      .withScope("openid profile email")
+      // Launch the authentication passing the callback where the results will be received
+      .start(this, object : Callback {
+        // Called when there is an authentication failure
+        override fun onFailure(exception: AuthenticationException) {
+          // Something went wrong!
+        }
+
+        // Called when authentication completed successfully
+        override fun onSuccess(credentials: Credentials) {
+          // Get the access token from the credentials object.
+          // This can be used to call APIs
+          val accessToken = credentials.accessToken
+        }
+      })
+  }
+
+  private fun logout() {
+    WebAuthProvider.logout(account)
+      .withScheme("demo")
+      .start(this, object : Callback {
+        override fun onSuccess(payload: Void?) {
+          // The user has been logged out!
+        }
+
+        override fun onFailure(error: AuthenticationException) {
+          // Something went wrong!
+        }
+      })
+  }
+
+  private fun showUserProfile(accessToken: String) {
+    var client = AuthenticationAPIClient(account)
+
+    // With the access token, call `userInfo` and get the profile from Auth0.
+    client.userInfo(accessToken)
+      .start(object : Callback {
+        override fun onFailure(exception: AuthenticationException) {
+          // Something went wrong!
+        }
+
+        override fun onSuccess(profile: UserProfile) {
+          // We have the user's profile!
+          val email = profile.email
+          val name = profile.name
+        }
+      })
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android/files/strings.md b/ja-jp/articles/quickstart/native/android/files/strings.md
new file mode 100644
index 0000000000..7a292938a3
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/files/strings.md
@@ -0,0 +1,10 @@
+---
+name: strings.xml
+language: xml
+---
+```xml
+
+    "YOUR_DOMAIN"
+    "YOUR_CLIENT_ID"
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android/index.yml b/ja-jp/articles/quickstart/native/android/index.yml
new file mode 100755
index 0000000000..0e64b75a56
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/index.yml
@@ -0,0 +1,57 @@
+title: Android
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/android.png
+logo: android
+alias:
+  - Android
+language:
+  - Kotlin
+hybrid: false
+author:
+  name: Luciano Balmaceda
+  email: luciano.balmaceda@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+snippets:
+  dependencies: native-platforms/android/dependencies
+  setup: native-platforms/android/setup
+  use: native-platforms/android/use
+seo_alias: android
+default_article: 00-login
+hidden_articles:
+  - interactive
+articles:
+  - 00-login
+  - 01-user-metadata
+next_steps:
+  - path: 00-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-android-sample
+  branch: master
+sdk:
+  name: Auth0.Android
+  url: https://github.com/auth0/Auth0.Android
+  logo: android
+requirements:
+  - Android Studio 4.1.0
+  - Android SDK 30
+  - Emulator - Android 11.0
diff --git a/ja-jp/articles/quickstart/native/android/interactive.md b/ja-jp/articles/quickstart/native/android/interactive.md
new file mode 100644
index 0000000000..c546e1b21b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android/interactive.md
@@ -0,0 +1,174 @@
+---
+title: Add Login to your Android App
+description: This quickstart demonstrates how to add user login to an Android application using Auth0.
+seo_alias: android
+interactive: true
+files:
+  - files/build
+  - files/strings
+  - files/main
+github:
+  path: 00-Login-Kt
+---
+
+# Add Login to Your Android Application
+
+
+
+
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure authentication in your project.
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure callback URLs
+
+A callback URL is the application URL that Auth0 will direct your users to once they have authenticated. If you do not set this value, Auth0 will not return users to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`.
+:::
+
+### Configure logout URLs
+
+A logout URL is the application URL Auth0 will redirect your users to once they log out. If you do not set this value, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to `demo://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback`.
+:::
+
+## Install the Auth0 Android SDK {{{ data-action=code data-code="build.gradle#18" }}}
+
+Add the [Auth0 Android](https://github.com/auth0/Auth0.Android) SDK into your project. The library will make requests to the Auth0's Authentication and Management APIs.
+
+In your app's `build.gradle` dependencies section, add the following:
+
+```groovy
+implementation 'com.auth0.android:auth0:2.+'
+```
+
+Ensure you target Java 8+ byte code for Android and Kotlin plugins respectively.
+
+## Add manifest placeholders {{{ data-action=code data-code="build.gradle#10:12" }}}
+
+The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set Auth0 tenant domain and the callback URL scheme.
+
+You do not need to declare a specific `intent-filter` for your activity, because you have defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values and the library will handle the redirection for you.
+
+::: note
+We've used a value of `demo` for `auth0Scheme` here, so that a custom URL scheme can be used for the URL that Auth0 redirects to after login. The alternative is `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking).
+:::
+
+## Configure your application {{{ data-action=code data-code="strings.xml#2:3" }}}
+
+For the SDK to function properly, you must set the following properties in `strings.xml`:
+
+- `com_auth0_domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead.
+- `com_auth0_client_id`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+
+Ensure that the `AndroidManifest.xml` file specifies the `android.permissions.INTERNET` permission:
+
+```xml
+
+```
+
+Run **Sync Project with Gradle Files** inside Android Studio or execute `./gradlew clean assembleDebug` from the command line.
+
+::: note
+For more information about using Gradle, check the [Gradle official documentation](https://gradle.org/getting-started-android-build/).
+:::
+
+## Add login to your application {{{ data-action=code data-code="MainActivity.kt#6:38" }}}
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features.
+
+In the `onCreate` method, create a new instance of the `Auth0` class to hold user credentials.
+
+Create a `loginWithBrowser` method and use the `WebAuthProvider` class to authenticate with any connection you enabled on your application in the [Auth0 dashboard](${manage_url}/#/). Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration.
+
+After you call the `WebAuthProvider#start` function, the browser launches and shows the login page. Once the user authenticates, the callback URL is called. The callback URL contains the final result of the authentication process.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Add a button to your application that calls `loginWithBrowser`. When you click it, verify that your Android application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects back to your app.
+
+:::
+
+:::checkpoint-failure
+
+If your application did not launch successfully:
+* Ensure you set the Allowed Callback URLs are correct
+* Verify you saved your changes after entering your URLs
+* Make sure the domain and cliend ID values imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="MainActivity.kt#40:52" }}}
+
+Use `WebAuthProvider` to remove the cookie set by the browser at authentication time, so that the users are forced to re-enter their credentials the next time they try to authenticate.
+
+Add a `logout` method to your app to remove the user's session and log them out of the app. Here, you can pass the scheme value that was used in the `auth0Scheme` manifest placeholder as part of the initial configuration.
+
+Use the `WebAuthProvider` class to implement logout. This call opens the browser and navigates the user to the logout endpoint. If the user cancels the logout, consider redirected the user to their previous URL.
+::::checkpoint
+
+:::checkpoint-default
+
+Add a button to your app that calls `logout` and logs the user out of your application. When you click it, verify that your Android app redirects you logout page and back again, and that you are no longer logged in to your application.
+
+:::
+
+:::checkpoint-failure
+If your application did not logout successfully:
+* Ensure the Allowed Logout URLs are set properly
+* Verify you saved your changes after entering your URLs
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Show user profile information {{{ data-action=code data-code="MainActivity.kt#54:70" }}}
+
+Use the `AuthenticationAPIClient` class to [retrieve the user's profile from Auth0](https://auth0.com/docs/users/user-profiles#user-profile-management-api-access). This requires:
+
+- The access token returned from the login phase
+- The `WebAuthProvider.login` must contain the `profile` scope
+
+You must specify the `email` scope if you need to retreive the user's email address.
+
+:::note
+This quickstart sets the `openid profile email` scopes by default during the login step above.
+:::
+
+The following demonstrates a function that can be used to retrieve the user's profile and show it on the screen:
+
+::::checkpoint
+
+:::checkpoint-default
+Call the `showUserProfile` function after login. Verify the `onSuccess` callback returns the user's profile information. 
+
+:::
+
+:::checkpoint-failure
+If your application did not return user profile information:
+* Verify the `accessToken` is valid
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
diff --git a/ja-jp/articles/quickstart/native/config.yml b/ja-jp/articles/quickstart/native/config.yml
new file mode 100644
index 0000000000..51f64e8751
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - client
diff --git a/ja-jp/articles/quickstart/native/device/01-login.md b/ja-jp/articles/quickstart/native/device/01-login.md
new file mode 100644
index 0000000000..5902c598bf
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/device/01-login.md
@@ -0,0 +1,14 @@
+---
+title: Login
+description: This tutorial demonstrates how to call your API from an input-constrained device using the Device Authorization flow.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - cordova
+github:
+  path: 01-Login
+contentType: tutorial
+useCase: quickstart
+---
+<%= include('../../../flows/guides/device-auth/includes/index.md') %>
diff --git a/ja-jp/articles/quickstart/native/device/index.yml b/ja-jp/articles/quickstart/native/device/index.yml
new file mode 100644
index 0000000000..22ff3ff856
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/device/index.yml
@@ -0,0 +1,24 @@
+title: Device Authorization Flow
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/device.svg
+logo: auth0
+author:
+  name: Rachel Khoriander
+  email: rachel.khoriander@auth0.com
+  community: false
+hybrid: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+alias:
+  - device
+  - device-auth
+  - device-flow
+  - device-authorization-flow
+seo_alias: device
+default_article: 01-login
+articles:
+  - 01-login
+show_steps: false
diff --git a/ja-jp/articles/quickstart/native/flutter/01-login.md b/ja-jp/articles/quickstart/native/flutter/01-login.md
new file mode 100644
index 0000000000..d0c303707b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/01-login.md
@@ -0,0 +1,319 @@
+---
+title: Add login to your Flutter app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Android, iOS, or macOS Flutter app using the Auth0 Flutter SDK
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - flutter
+  - dart
+  - ios
+  - macos
+  - android
+contentType: tutorial
+useCase: quickstart
+files:
+  - files/build
+  - files/main
+  - files/profile
+github:
+  path: sample
+---
+
+# Add login to your Flutter app
+
+Auth0 allows you to quickly add authentication and access user profile information in your app. This guide demonstrates how to integrate Auth0 with a Flutter app using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter).
+
+:::note
+The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS.
+:::
+
+## Getting started
+
+This quickstart assumes you already have a [Flutter](https://flutter.dev/) app up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app.
+
+You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli).
+
+Finally, you will need a **Native** Auth0 application. If you don’t have a Native Auth0 application already, [create one](/get-started/auth0-overview/create-applications/native-apps) before continuing. Avoid using other application types, as they have different configurations and may cause errors.
+
+### Configure the callback and logout URLs
+
+The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie.
+
+If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error.
+
+Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page.
+
+::: note
+On Android, the value of the `SCHEME` placeholder can be `https` or some other custom scheme. `https` schemes require enabling [Android App Links](https://auth0.com/docs/get-started/applications/enable-android-app-links-support).
+
+On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links (`https` scheme) as callback and logout URLs. When enabled, the SDK will fall back to using a custom URL scheme on older iOS / macOS versions –your app's [bundle identifier](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids).
+**This feature requires Xcode 15.3+ and a paid Apple Developer account**.
+:::
+
+#### Android
+
+```text
+SCHEME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback
+```
+
+#### iOS
+
+```text
+https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+#### macOS
+
+```text
+https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be:
+
+```text
+https://example.us.auth0.com/ios/com.example.MyApp/callback,
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+```
+
+## Install the Auth0 Flutter SDK
+
+Add the Auth0 Flutter SDK into the project:
+
+```shell
+flutter pub add auth0_flutter
+```
+
+## Configure Android
+
+If you are not developing for the Android platform, skip this step.
+
+The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set the Auth0 tenant domain and the callback URL scheme.
+
+Modify `app/build.gradle` to include manifest placeholders for `auth0Domain` and `auth0Scheme` inside the `defaultConfig` section:
+
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion flutter.targetSdkVersion
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders += [auth0Domain: "${account.namespace}", auth0Scheme: "https"]
+        // <---
+    }
+}
+```
+
+- `auth0Domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under your **Application Settings** in the Domain field. If you are using a custom domain, you should set this to the value of your custom domain instead.
+- `auth0Scheme`: The scheme to use. Can be a custom scheme, or `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking).
+
+:::note
+You do not need to declare a specific `intent-filter` for your activity because you defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values. The library handles the redirection for you.
+:::
+
+Run **Sync Project with Gradle Files** inside Android Studio to apply your changes.
+
+## Configure iOS/macOS
+
+If you are not developing for the iOS or macOS platforms, skip this step.
+
+::: warning
+This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead.
+:::
+
+#### Configure the Team ID and bundle identifier
+
+Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier.
+
+
    Screenshot of the iOS section inside the Auth0 application settings page
    
+
+This will add your app to your Auth0 tenant's `apple-app-site-association` file.
+
+#### Add the associated domain capability
+
+Open your app in Xcode by running `open ios/Runner.xcworkspace` (or `open macos/Runner.xcworkspace` for macOS). Go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of the **Runner** target settings, and press the **+ Capability** button. Then select **Associated Domains**.
+
+
    Screenshot of the capabilities library inside Xcode
    
+
+Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page.
+
+::: note
+For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application.
+:::
+
+## Add login to your app
+
+[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your app. We recommend using it for the best experience, best security, and the fullest array of features.
+
+Integrate Auth0 Universal Login in your Flutter app by importing the SDK and instantiating the `Auth0` class using your Auth0 domain and Client ID values. See this example, which instantiates the class inside a widget state object:
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+
+class MainView extends StatefulWidget {
+  const MainView({Key? key}) : super(key: key);
+
+  @override
+  State createState() => _MainViewState();
+}
+
+class _MainViewState extends State {
+  Credentials? _credentials;
+
+  late Auth0 auth0;
+
+  @override
+  void initState() {
+    super.initState();
+    auth0 = Auth0('${account.namespace}', '${account.clientId}');
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    // ...
+  }
+}
+```
+
+Next, redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens. See this example of a `ElevatedButton` widget that logs the user in when clicked. Note that `_credentials` is used to determine locally within your app whether or not a user is signed in:
+
+```dart
+if (_credentials == null) {
+  ElevatedButton(
+    onPressed: () async {
+      // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+
+      // useHTTPS is ignored on Android
+      final credentials =
+          await auth0.webAuthentication().login(useHTTPS: true);
+
+      setState(() {
+        _credentials = credentials;
+      });
+    },
+    child: const Text("Log in")
+  )
+}
+```
+
+**Android**: if you are using a custom scheme, pass this scheme to the login method so that the SDK can route to the login page and back again correctly:
+
+```dart
+await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login();
+```
+
+When a user logs in, they are redirected back to your app. Then, you are able to access the ID and access tokens for this user.
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `webAuthentication().login()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your app.
+
+Verify that you can get access to the tokens on the result of calling `login`.
+:::
+
+:::checkpoint-failure
+If your app did not launch successfully:
+
+- Ensure you set the Allowed Callback URLs are correct
+- Verify you saved your changes after entering your URLs
+- Make sure the domain and client ID values are imported correctly
+- If using Android, ensure that the manifest placeholders have been set up correctly, otherwise the redirect back to your app may not work
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your app
+
+To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `webAuthentication().logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout).
+
+See this example of an `ElevatedButton` widget that logs the user out of the app. Note that `_credentials` is set to `null`, indicating that the user is no longer signed in to your app:
+
+```dart
+ElevatedButton(
+  onPressed: () async {
+    // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+
+    // useHTTPS is ignored on Android
+    await auth0.webAuthentication().logout(useHTTPS: true);
+
+    setState(() {
+      _credentials = null;
+    });
+  },
+  child: const Text("Log out"))
+```
+
+**Android**: if you are using a custom scheme, pass this scheme to the logout method so that the SDK can route back to your app correctly:
+
+```
+await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout();
+```
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `webAuthentication().logout()` and logs the user out of your app. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your app.
+:::
+
+:::checkpoint-failure
+If your app did not log out successfully:
+
+- Ensure the Allowed Logout URLs are set properly
+- Verify you saved your changes after entering your URLs
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information
+
+The user profile automatically retrieves user profile properties for you when you call `webAuthentication().login()`. The returned object from the login step contains a `user` property with all the user profile properties, which populates by decoding the ID token.
+
+See this example of a `View` component that displays the user profile on the screen:
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:flutter/material.dart';
+
+class ProfileView extends StatelessWidget {
+  const ProfileView({Key? key, required this.user}) : super(key: key);
+
+  final UserProfile user;
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (user.name != null) Text(user.name!),
+        if (user.email != null) Text(user.email!)
+      ],
+    );
+  }
+}
+```
+
+::::checkpoint
+:::checkpoint-default
+Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`.
+:::
+:::checkpoint-failure
+If your app did not return user profile information:
+
+- Verify the access token is valid
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/native/flutter/_configure_urls_interactive.md b/ja-jp/articles/quickstart/native/flutter/_configure_urls_interactive.md
new file mode 100644
index 0000000000..e1a0c2f280
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/_configure_urls_interactive.md
@@ -0,0 +1,51 @@
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project.
+
+### Configure an Auth0 application
+
+Use the interactive selector to create a new Auth0 application or select an existing **Native** Auth0 application. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample app instead.
+
+### Configure the callback and logout URLs
+
+The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie. If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error.
+
+Set the callback and logout URLs to the following values, depending on your platform.
+
+::: note
+On Android, the value of the `SCHEME` placeholder can be `https` or some other custom scheme. `https` schemes require enabling [Android App Links](https://auth0.com/docs/get-started/applications/enable-android-app-links-support).
+
+On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links (`https` scheme) as callback and logout URLs. When enabled, the SDK will fall back to using a custom URL scheme on older iOS / macOS versions –your app's [bundle identifier](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids).
+**This feature requires Xcode 15.3+ and a paid Apple Developer account**.
+:::
+
+#### Android
+
+```text
+SCHEME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback
+```
+
+#### iOS
+
+```text
+https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+#### macOS
+
+```text
+https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be:
+
+```text
+https://example.us.auth0.com/ios/com.example.MyApp/callback,
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+```
diff --git a/ja-jp/articles/quickstart/native/flutter/download.md b/ja-jp/articles/quickstart/native/flutter/download.md
new file mode 100644
index 0000000000..8973142196
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/download.md
@@ -0,0 +1,25 @@
+
+
+> On every step, if you have a [custom domain](https://auth0.com/docs/customize/custom-domains), replace the `YOUR_AUTH0_DOMAIN` placeholder with your custom domain instead of the value from the settings page.
+
+## 1. Configure the Auth0 application
+
+Open the settings page of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform you want to use.
+
+- Android: `com.auth0.sample://YOUR_AUTH0_DOMAIN/android/com.auth0.sample/callback`
+- iOS: `https://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback`
+- macOS: `https://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback`
+
+## 2. Configure the associated domain (iOS/macOS only)
+
+> **This following requires Xcode 15.3+ and a paid Apple Developer account**. If you do not have a paid Apple Developer account, skip this step, and set the `useHTTPS` parameter to `false` in the `login()` and `logout()` calls at `lib/example_app.dart`.
+
+Open `ios/Runner.xcodeproj` (or `macos/Runner.xcodeproj`, for macOS) in Xcode and go to the settings of the **Runner** app target. In the **Signing & Capabilities** tab, change the bundle identifier from the default `com.auth0.samples.FlutterSample` to another value of your choosing. Then, make sure the **Automatically manage signing** box is checked, and that your Apple Team is selected.
+
+Next, find the `webcredentials:YOUR_AUTH0_DOMAIN` entry under **Associated Domains**, and replace the `YOUR_AUTH0_DOMAIN` placeholder with the domain of your Auth0 application.
+
+Finally, open the settings page of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to the app's bundle identifier.
+
+## 3. Run the app
+
+Use the [Flutter CLI](https://docs.flutter.dev/reference/flutter-cli) to run the app: `flutter run`.
diff --git a/ja-jp/articles/quickstart/native/flutter/files/build.md b/ja-jp/articles/quickstart/native/flutter/files/build.md
new file mode 100644
index 0000000000..39842f5c24
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/build.md
@@ -0,0 +1,21 @@
+---
+name: app/build.gradle
+language: groovy
+---
+
+```groovy
+apply plugin: 'com.android.application'
+
+android {
+    defaultConfig {
+        applicationId "com.auth0.samples"
+        minSdkVersion 21
+        targetSdkVersion flutter.targetSdkVersion
+        // ...
+
+        // ---> Add the next line
+        manifestPlaceholders += [auth0Domain: "${account.namespace}", auth0Scheme: "https"]
+        // <---
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/flutter/files/main.md b/ja-jp/articles/quickstart/native/flutter/files/main.md
new file mode 100644
index 0000000000..b0f41fd59a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/main.md
@@ -0,0 +1,68 @@
+---
+name: main_view.dart
+language: dart
+---
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:flutter/material.dart';
+import 'profile_view.dart';
+
+class MainView extends StatefulWidget {
+  const MainView({Key? key}) : super(key: key);
+
+  @override
+  State createState() => _MainViewState();
+}
+
+class _MainViewState extends State {
+  Credentials? _credentials;
+
+  late Auth0 auth0;
+
+  @override
+  void initState() {
+    super.initState();
+    auth0 = Auth0('${account.namespace}', '${account.clientId}');
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (_credentials == null)
+          ElevatedButton(
+              onPressed: () async {
+                // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+
+                // useHTTPS is ignored on Android
+                final credentials =
+                    await auth0.webAuthentication().login(useHTTPS: true);
+
+                setState(() {
+                  _credentials = credentials;
+                });
+              },
+              child: const Text("Log in"))
+        else
+          Column(
+            children: [
+              ProfileView(user: _credentials!.user),
+              ElevatedButton(
+                  onPressed: () async {
+                    // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+
+                    // useHTTPS is ignored on Android
+                    await auth0.webAuthentication().logout(useHTTPS: true);
+
+                    setState(() {
+                      _credentials = null;
+                    });
+                  },
+                  child: const Text("Log out"))
+            ],
+          )
+      ],
+    );
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/flutter/files/profile.md b/ja-jp/articles/quickstart/native/flutter/files/profile.md
new file mode 100644
index 0000000000..37883b3fa3
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/files/profile.md
@@ -0,0 +1,26 @@
+---
+name: profile_view.dart
+language: dart
+---
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:flutter/material.dart';
+
+class ProfileView extends StatelessWidget {
+  const ProfileView({Key? key, required this.user}) : super(key: key);
+
+  final UserProfile user;
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (user.name != null) Text(user.name!),
+        if (user.email != null) Text(user.email!)
+      ],
+    );
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/flutter/index.yml b/ja-jp/articles/quickstart/native/flutter/index.yml
new file mode 100644
index 0000000000..c09ff74e18
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/index.yml
@@ -0,0 +1,55 @@
+title: Flutter
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/flutter.jpeg
+logo_name: flutter
+logo: flutter
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - flutter
+language:
+  - Dart
+framework:
+  - Flutter
+sdk:
+  name: auth0-flutter
+  url: https://www.github.com/auth0/auth0-flutter/
+  logo: flutter
+hybrid: true
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: flutter
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-flutter-samples
+  branch: main
+requirements:
+  - Flutter 3+
+  - Android API 21+ and Android Studio 4+ (for Android)
+  - iOS 13+ and Xcode 14+ (for iOS)
+  - macOS 11+ and Xcode 14+ (for macOS)
+next_steps:
+  - path: interactive
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about Actions
+        icon: 345
+        href: '/customize/actions'
diff --git a/ja-jp/articles/quickstart/native/flutter/interactive.md b/ja-jp/articles/quickstart/native/flutter/interactive.md
new file mode 100644
index 0000000000..8735a35d88
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/flutter/interactive.md
@@ -0,0 +1,171 @@
+---
+title: Add login to your Flutter app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Android, iOS, or macOS Flutter app using the Auth0 Flutter SDK
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - flutter
+  - dart
+  - ios
+  - macos
+  - android
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/build
+  - files/main
+  - files/profile
+github:
+  path: sample
+---
+
+# Add Login to Your Flutter Application
+
+Auth0 allows you to quickly add authentication and access user profile information in your app. This guide demonstrates how to integrate Auth0 with a Flutter app using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter).
+
+:::note
+The Flutter SDK currently only supports Flutter apps for Android, iOS, and macOS.
+:::
+
+This quickstart assumes you already have a [Flutter](https://flutter.dev/) app up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app.
+
+You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli).
+
+<%= include('_configure_urls_interactive') %>
+
+## Install the Auth0 Flutter SDK
+
+Add the Auth0 Flutter SDK into the project:
+
+```shell
+flutter pub add auth0_flutter
+```
+
+## Configure Android {{{ data-action=code data-code="app/build.gradle#11" }}}
+
+If you are not developing for the Android platform, skip this step.
+
+The SDK requires manifest placeholders. Auth0 uses placeholders internally to define an `intent-filter`, which captures the authentication callback URL. You must set the Auth0 tenant domain and the callback URL scheme.
+
+[The sample](https://github.com/auth0-samples/auth0-flutter-samples/tree/main/sample/android) uses the following placeholders:
+
+- `auth0Domain`: The domain of your Auth0 tenant. Generally, you find this in the Auth0 Dashboard under your **Application Settings** in the Domain field. If you are using a custom domain, you should set this to the value of your custom domain instead.
+- `auth0Scheme`: The scheme to use. Can be a custom scheme, or `https` if you want to use [Android App Links](https://auth0.com/docs/applications/enable-android-app-links). You can read more about setting this value in the [Auth0.Android SDK README](https://github.com/auth0/Auth0.Android#a-note-about-app-deep-linking).
+
+:::note
+You do not need to declare a specific `intent-filter` for your activity because you defined the manifest placeholders with your Auth0 **Domain** and **Scheme** values. The library handles the redirection for you.
+:::
+
+Run **Sync Project with Gradle Files** inside Android Studio to apply your changes.
+
+## Configure iOS/macOS
+
+If you are not developing for the iOS or macOS platforms, skip this step.
+
+::: warning
+This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead.
+:::
+
+### Configure the Team ID and bundle identifier
+
+Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier.
+
+
    Screenshot of the iOS section inside the Auth0 application settings page
    
+
+This will add your app to your Auth0 tenant's `apple-app-site-association` file.
+
+### Add the associated domain capability
+
+Open your app in Xcode by running `open ios/Runner.xcworkspace` (or `open macos/Runner.xcworkspace` for macOS). Go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of the **Runner** target settings, and press the **+ Capability** button. Then select **Associated Domains**.
+
+
    Screenshot of the capabilities library inside Xcode
    
+
+Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page.
+
+::: note
+For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application.
+:::
+
+## Add login to your application {{{ data-action="code" data-code="main_view.dart#29:40" }}}
+
+[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your app. We recommend using it for the best experience, best security, and the fullest array of features.
+
+Integrate Auth0 Universal Login in your Flutter app by using the `Auth0` class. Redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens.
+
+**Android**: if you are using a custom scheme, pass this scheme to the login method so that the SDK can route to the login page and back again correctly:
+
+```dart
+await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login();
+```
+
+When a user logs in, they are redirected back to your app. Then, you are able to access the ID and access tokens for this user.
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `webAuthentication().login()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your app.
+
+Verify that you can get access to the tokens on the result of calling `login`.
+:::
+
+:::checkpoint-failure
+If your app did not launch successfully:
+
+- Ensure you set the Allowed Callback URLs are correct
+- Verify you saved your changes after entering your URLs
+- Make sure the domain and client ID values are imported correctly
+- If using Android, ensure that the manifest placeholders have been set up correctly, otherwise the redirect back to your app may not work
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="main_view.dart#45:55"}}}
+
+To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `webAuthentication().logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout).
+
+**Android**: if you are using a custom scheme, pass this scheme to the logout method so that the SDK can route back to your app correctly:
+
+```
+await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout();
+```
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `webAuthentication().logout()` and logs the user out of your app. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your app.
+:::
+
+:::checkpoint-failure
+If your app did not log out successfully:
+
+- Ensure the Allowed Logout URLs are set properly
+- Verify you saved your changes after entering your URLs
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information {{{ data-action="code" data-code="profile_view.dart" }}}
+
+The user profile automatically retrieves user profile properties for you when you call `webAuthentication().login()`. The returned object from the login step contains a `user` property with all the user profile properties, which populates by decoding the ID token.
+
+::::checkpoint
+:::checkpoint-default
+Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`.
+:::
+:::checkpoint-failure
+If your app did not return user profile information:
+
+- Verify the access token is valid
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/01-login.md b/ja-jp/articles/quickstart/native/ionic-angular/01-login.md
new file mode 100644
index 0000000000..e6f6e8c374
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/01-login.md
@@ -0,0 +1,255 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Angular & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - angular
+  - capacitor
+github:
+  path: angular
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-angular-install') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure your App module
+
+The SDK exports `AuthModule`, a module that contains all the services required for the SDK to function. To register this with your application:
+
+- Open the `app.module.ts` file
+- Import the `AuthModule` type from the `@auth0/auth0-angular` package
+- Add `AuthModule` to the application by calling `AuthModule.forRoot` and adding to your application module's `imports` array
+- Specify the configuration for the Auth0 Angular SDK
+
+```javascript
+// Import the types from the SDK
+import { AuthModule } from '@auth0/auth0-angular';
+import config from '../../capacitor.config';
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+// Register AuthModule with your AppModule
+@NgModule({
+  declarations: [AppComponent],
+  entryComponents: [],
+  imports: [
+    BrowserModule,
+    IonicModule.forRoot(),
+    AppRoutingModule,
+    AuthModule.forRoot({
+      domain: "${account.namespace}",
+      clientId: "${account.clientId}",
+      useRefreshTokens: true,
+      useRefreshTokensFallback: false,
+      authorizationParams: {
+        redirect_uri,
+      }
+    }),
+  ],
+  providers: [{ provide: RouteReuseStrategy, useClass: IonicRouteStrategy }],
+  bootstrap: [AppComponent],
+})
+```
+
+The `AuthModule.forRoot` function takes the following configuration:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-angular with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-angular with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured your app with the Auth0 Angular SDK, run your application to verify that the SDK is initializing without error and that your application runs as it did before.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new `LoginButton` component to your application with the following code:
+
+```js
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { Browser } from '@capacitor/browser';
+import { mergeMap } from 'rxjs/operators';
+
+@Component({
+  selector: 'app-login-button',
+  template: `Login`,
+})
+export class LoginButtonComponent {
+  constructor(public auth: AuthService) {}
+
+  login() {
+    this.auth
+      .loginWithRedirect({
+        async openUrl(url: string) {
+          await Browser.open({ url, windowName: '_self' });
+        }
+      })
+      .subscribe();
+  }
+}
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Modify your `App` component and use the `ngOnInit` method to handle the callback from Auth0.
+
+```js
+import { Component, OnInit, NgZone } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { mergeMap } from 'rxjs/operators';
+import { Browser } from '@capacitor/browser';
+import { App } from '@capacitor/app';
+
+const callbackUri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+@Component({
+  selector: 'app-root',
+  templateUrl: 'app.component.html',
+  styleUrls: ['app.component.scss'],
+})
+export class AppComponent implements OnInit {
+  // Import the AuthService module from the Auth0 Angular SDK
+  constructor(public auth: AuthService, private ngZone: NgZone) {}
+
+  ngOnInit(): void {
+    // Use Capacitor's App plugin to subscribe to the `appUrlOpen` event
+    App.addListener('appUrlOpen', ({ url }) => {
+      // Must run inside an NgZone for Angular to pick up the changes
+      // https://capacitorjs.com/docs/guides/angular
+      ngZone.run(() => {
+        if (url?.startsWith(callbackUri)) {
+          // If the URL is an authentication callback URL..
+          if (
+            url.includes('state=') &&
+            (url.includes('error=') || url.includes('code='))
+          ) {
+            // Call handleRedirectCallback and close the browser
+            this.auth
+              .handleRedirectCallback(url)
+              .pipe(mergeMap(() => Browser.close()))
+              .subscribe();
+          } else {
+            Browser.close();
+          }
+        }
+      });
+    });
+  }
+}
+```
+
+Note that the `appUrlOpen` event callback is wrapped in `ngZone.run`, which means that the changes to observables that occur when `handleRedirectCallback` runs are picked up by the Angular app. Please read [Using Angular with Capacitor](https://capacitorjs.com/docs/guides/angular) for more details. Otherwise, the screen will not update to show the authenticated state after you log in.
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new `LogoutButton` component and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```js
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { Browser } from '@capacitor/browser';
+import { tap } from 'rxjs/operators';
+
+// Build the URL to return back to your app after logout
+const returnTo = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+@Component({
+  selector: 'app-logout-button',
+  template: `Log out`,
+})
+export class LogoutButtonComponent {
+  // Import the AuthService module from the Auth0 Angular SDK
+  constructor(public auth: AuthService) {}
+
+   logout() {
+    this.auth
+      .logout({ 
+        logoutParams: {
+          returnTo,
+        },
+        async openUrl(url: string) {
+          await Browser.open({ url });
+        } 
+      })
+      .subscribe();
+  }
+}
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` property exposed by `AuthService`.
+
+Create a new component `Profile`, and use the following code to display user profile information in your app.
+
+```js
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-profile',
+  template: `
+  
    
+    
+      
+    
+    
    {{ user.name }}
    
+    
    {{ user.email }}
    
+  
    `,
+})
+export class ProfileComponent {
+  constructor(public auth: AuthService) {}
+}
+
+```
+
+:::panel Checkpoint
+Add `ProfileComponent` to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/download.md b/ja-jp/articles/quickstart/native/ionic-angular/download.md
new file mode 100644
index 0000000000..83a60e3629
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/download.md
@@ -0,0 +1,37 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/files/app-component.md b/ja-jp/articles/quickstart/native/ionic-angular/files/app-component.md
new file mode 100644
index 0000000000..7923e1cbd0
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/files/app-component.md
@@ -0,0 +1,49 @@
+---
+name: app.component.ts
+language: javascript
+---
+
+```javascript
+import { Component, OnInit, NgZone } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { mergeMap } from 'rxjs/operators';
+import { Browser } from '@capacitor/browser';
+import { App } from '@capacitor/app';
+
+const callbackUri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+@Component({
+  selector: 'app-root',
+  templateUrl: 'app.component.html',
+  styleUrls: ['app.component.scss'],
+})
+export class AppComponent implements OnInit {
+  // Import the AuthService module from the Auth0 Angular SDK
+  constructor(public auth: AuthService, private ngZone: NgZone) {}
+
+  ngOnInit(): void {
+    // Use Capacitor's App plugin to subscribe to the `appUrlOpen` event
+    App.addListener('appUrlOpen', ({ url }) => {
+      // Must run inside an NgZone for Angular to pick up the changes
+      // https://capacitorjs.com/docs/guides/angular
+      ngZone.run(() => {
+        if (url?.startsWith(callbackUri)) {
+          // If the URL is an authentication callback URL..
+          if (
+            url.includes('state=') &&
+            (url.includes('error=') || url.includes('code='))
+          ) {
+            // Call handleRedirectCallback and close the browser
+            this.auth
+              .handleRedirectCallback(url)
+              .pipe(mergeMap(() => Browser.close()))
+              .subscribe();
+          } else {
+            Browser.close();
+          }
+        }
+      });
+    });
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/files/app-module.md b/ja-jp/articles/quickstart/native/ionic-angular/files/app-module.md
new file mode 100644
index 0000000000..37b7db07fe
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/files/app-module.md
@@ -0,0 +1,37 @@
+---
+name: app.module.ts
+language: javascript
+---
+
+```javascript
+// Import the types from the SDK
+import { AuthModule } from '@auth0/auth0-angular';
+import config from '../../capacitor.config';
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+// Register AuthModule with your AppModule
+@NgModule({
+  declarations: [AppComponent],
+  entryComponents: [],
+  imports: [
+    BrowserModule,
+    IonicModule.forRoot(),
+    AppRoutingModule,
+    AuthModule.forRoot({
+      domain: "${account.namespace}",
+      clientId: "${account.clientId}",
+      useRefreshTokens: true,
+      useRefreshTokensFallback: false,
+      authorizationParams: {
+        redirect_uri
+      }
+    }),
+  ],
+  providers: [{ provide: RouteReuseStrategy, useClass: IonicRouteStrategy }],
+  bootstrap: [AppComponent],
+})
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/files/login-button.md b/ja-jp/articles/quickstart/native/ionic-angular/files/login-button.md
new file mode 100644
index 0000000000..dc3616f928
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/files/login-button.md
@@ -0,0 +1,29 @@
+---
+name: login-button.ts
+language: javascript
+---
+
+```javascript
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { Browser } from '@capacitor/browser';
+import { mergeMap } from 'rxjs/operators';
+
+@Component({
+  selector: 'app-login-button',
+  template: `Login`,
+})
+export class LoginButtonComponent {
+  constructor(public auth: AuthService) {}
+
+  login() {
+    this.auth
+      .loginWithRedirect({
+        async openUrl(url: string) {
+          await Browser.open({ url, windowName: '_self' });
+        }
+      })
+      .subscribe();
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/files/logout-button.md b/ja-jp/articles/quickstart/native/ionic-angular/files/logout-button.md
new file mode 100644
index 0000000000..21ad6aad68
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/files/logout-button.md
@@ -0,0 +1,36 @@
+---
+name: logout-button.ts
+language: javascript
+---
+
+```javascript
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { Browser } from '@capacitor/browser';
+import { tap } from 'rxjs/operators';
+
+// Build the URL to return back to your app after logout
+const returnTo = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+@Component({
+  selector: 'app-logout-button',
+  template: `Log out`,
+})
+export class LogoutButtonComponent {
+  // Import the AuthService module from the Auth0 Angular SDK
+  constructor(public auth: AuthService) {}
+
+   logout() {
+    this.auth
+      .logout({ 
+        logoutParams: {
+          returnTo,
+        },
+        async openUrl(url: string) {
+          await Browser.open({ url });
+        } 
+      })
+      .subscribe();
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/files/user-profile.md b/ja-jp/articles/quickstart/native/ionic-angular/files/user-profile.md
new file mode 100644
index 0000000000..96be742cdd
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/files/user-profile.md
@@ -0,0 +1,24 @@
+---
+name: user-profile.ts
+language: javascript
+---
+
+```javascript
+import { Component, OnInit } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-profile',
+  template: `
+  
    
+    
+      
+    
+    
    {{ user.name }}
    
+    
    {{ user.email }}
    
+  
    `,
+})
+export class ProfileComponent {
+  constructor(public auth: AuthService) {}
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/index.yml b/ja-jp/articles/quickstart/native/ionic-angular/index.yml
new file mode 100644
index 0000000000..8eac1d65b1
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/index.yml
@@ -0,0 +1,55 @@
+title: Ionic & Capacitor (Angular)
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/ionic.jpeg
+logo_name: ionic
+logo: ionic
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - ionic
+  - angular
+  - capacitor
+  - auth0-angular
+language:
+  - Typescript
+framework:
+  - Ionic
+  - Capacitor
+  - Angular
+hybrid: true
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: ionic-angular
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-ionic-samples
+  branch: main
+requirements:
+  - Node & Npm (LTS)
+  - XCode 12+ (for iOS)
+  - Android Studio 4+ (for Android)
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/native/ionic-angular/interactive.md b/ja-jp/articles/quickstart/native/ionic-angular/interactive.md
new file mode 100644
index 0000000000..c6db4b0e82
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-angular/interactive.md
@@ -0,0 +1,135 @@
+---
+title: Add login to your Ionic Angular with Capacitor app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Angular & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - angular
+  - capacitor
+github:
+  path: angular
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/app-module
+  - files/app-component
+  - files/login-button
+  - files/logout-button
+  - files/user-profile
+---
+
+# Add Login to Your Ionic Angular with Capacitor Application
+
+Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (Angular) & Capacitor application using the [Auth0 Angular SDK](https://github.com/auth0/auth0-angular).
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/ionic/_configure_urls_interactive') %>
+
+<%= include('../../_includes/_auth0-angular-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+## Register and configure the authentication module {{{ data-action=code data-code="app.module.ts" }}}
+
+The SDK exports `AuthModule`, a module that contains all the services required for the SDK to function. This module should be registered with your application and be configured with your Auth0 domain and Client ID.
+
+The `AuthModule.forRoot` function takes the following configuration:
+
+- `domain`: The `domain` value present under the **Settings** of the application you created in the Auth0 Dashboard, or your custom domain if you are using Auth0's [custom domains feature](http://localhost:3000/docs/custom-domains).
+- `clientId`: The Client ID value present under the **Settings** of the application you created in the Auth0 Dashboard.
+- `useRefreshTokens`: To use auth0-angular with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-angular with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+::::checkpoint
+:::checkpoint-default
+Now that you have configured your app with the Auth0 Angular SDK, run your application to verify that the SDK is initializing without error, and that your application runs as it did before.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* ensure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and Client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="login-button.ts" }}}
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+::::checkpoint
+::: checkpoint-default
+The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+* ensure that there are no errors in the browser's console window at the point of login
+* ensure the domain and Client ID are correct according to your Auth0 application in the Dashboard
+* if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure
+:::
+::::
+
+## Handling the login callback {{{ data-action=code data-code="app.component.ts" }}}
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Note that the `appUrlOpen` event callback is wrapped in `ngZone.run`. Changes to observables that occur when `handleRedirectCallback` runs are picked up by the Angular app. To learn more, read [Using Angular with Capacitor](https://capacitorjs.com/docs/guides/angular). Otherwise, the screen doesn't update to show the authenticated state after log in.
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+::::checkpoint
+:::checkpoint-default
+Add the `appUrlOpen` to your application's `App` component and log in. The browser window should close once the user authenticates and logs in to your app.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+* check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) for Android
+* if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the error code
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout-button.ts" }}}
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to log out of your application. Verify the redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Make sure users are no longer logged in to your application.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+* check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard
+:::
+::::
+
+## Show the user profile {{{ data-action=code data-code="user-profile.ts" }}}
+
+The Auth0 SDK retrieves the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` property exposed by `AuthService`.
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+* check that you are only reading the user's profile when `isLoading` is `false`
+* check that `user` resolves to an object and is not `undefined`
+:::
+::::
diff --git a/ja-jp/articles/quickstart/native/ionic-react/01-login.md b/ja-jp/articles/quickstart/native/ionic-react/01-login.md
new file mode 100644
index 0000000000..1dd8536765
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/01-login.md
@@ -0,0 +1,228 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - react
+  - capacitor
+github:
+  path: react
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-react-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `Auth0Provider` component
+
+Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK.
+
+Open `src/index.tsx` and wrap the `App` component in the `Auth0Provider` component.
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+  
+    
+  
+);
+```
+
+The `Auth0Provider` component takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.tsx` with the following code:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+const LoginButton: React.FC = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  const login = async () => {
+    await loginWithRedirect({
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log in;
+};
+
+export default LoginButton;
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+<%= include('../../_includes/_auth0-react-classes-info.md') %>
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following `useEffect` hook to your main `App` component:
+
+```js
+// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`,
+// as well as the bits needed for Auth0 and React
+import { App as CapApp } from '@capacitor/app';
+import { Browser } from '@capacitor/browser';
+import { useEffect } from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+// ...
+
+const App: React.FC = () => {
+  // Get the callback handler from the Auth0 React hook
+  const { handleRedirectCallback } = useAuth0();
+
+  useEffect(() => {
+    // Handle the 'appUrlOpen' event and call `handleRedirectCallback`
+    CapApp.addListener('appUrlOpen', async ({ url }) => {
+      if (url.includes('state') && (url.includes('code') || url.includes('error'))) {
+        await handleRedirectCallback(url);
+      }
+      // No-op on Android
+      await Browser.close();
+    });
+  }, [handleRedirectCallback]);
+
+  // ..
+};
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.tsx` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+// This should reflect the URL added earlier to your "Allowed Logout URLs" setting
+// in the Auth0 dashboard.
+const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback';
+
+const LogoutButton: React.FC = () => {
+  const { logout } = useAuth0();
+
+  const doLogout = async () => {
+    await logout({
+      logoutParams: {
+        returnTo: logoutUri,
+      },
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log out;
+};
+
+export default LogoutButton;
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+
+const Profile: React.FC = () => {
+  const { user, isLoading } = useAuth0();
+
+  // If the SDK is not ready, or a user is not authenticated, exit.
+  if (isLoading || !user) return null;
+
+  return (
+    
    
+      {user.name}
+      
    {user.name}
    
+      
    {user.email}
    
+    
    
+  );
+};
+
+export default Profile;
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `Profile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/native/ionic-react/download.md b/ja-jp/articles/quickstart/native/ionic-react/download.md
new file mode 100644
index 0000000000..dc7d46dcf4
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/download.md
@@ -0,0 +1,37 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/app.md b/ja-jp/articles/quickstart/native/ionic-react/files/app.md
new file mode 100644
index 0000000000..4933e1a6de
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/app.md
@@ -0,0 +1,33 @@
+---
+name: app.tsx
+language: javascript
+---
+
+```javascript
+// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`,
+// as well as the bits needed for Auth0 and React
+import { App as CapApp } from '@capacitor/app';
+import { Browser } from '@capacitor/browser';
+import { useEffect } from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+// ...
+
+const App: React.FC = () => {
+  // Get the callback handler from the Auth0 React hook
+  const { handleRedirectCallback } = useAuth0();
+
+  useEffect(() => {
+    // Handle the 'appUrlOpen' event and call `handleRedirectCallback`
+    CapApp.addListener('appUrlOpen', async ({ url }) => {
+      if (url.includes('state') && (url.includes('code') || url.includes('error'))) {
+        await handleRedirectCallback(url);
+      }
+      // No-op on Android
+      await Browser.close();
+    });
+  }, [handleRedirectCallback]);
+
+  // ..
+};
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/index.md b/ja-jp/articles/quickstart/native/ionic-react/files/index.md
new file mode 100644
index 0000000000..762a3d2f70
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/index.md
@@ -0,0 +1,27 @@
+---
+name: index.tsx
+language: javascript
+---
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+  
+    
+  
+);
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/login-button.md b/ja-jp/articles/quickstart/native/ionic-react/files/login-button.md
new file mode 100644
index 0000000000..563b1ee5af
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/login-button.md
@@ -0,0 +1,30 @@
+---
+name: login-button.tsx
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+const LoginButton: React.FC = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  const login = async () => {
+    await loginWithRedirect({
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log in;
+};
+
+export default LoginButton;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/logout-button.md b/ja-jp/articles/quickstart/native/ionic-react/files/logout-button.md
new file mode 100644
index 0000000000..a4a1ceb4f1
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/logout-button.md
@@ -0,0 +1,37 @@
+---
+name: logout-button.tsx
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+// This should reflect the URL added earlier to your "Allowed Logout URLs" setting
+// in the Auth0 dashboard.
+const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback';
+
+const LogoutButton: React.FC = () => {
+  const { logout } = useAuth0();
+
+  const doLogout = async () => {
+    await logout({
+      logoutParams: {
+        returnTo: logoutUri
+      },
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log out;
+};
+
+export default LogoutButton;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/user-profile.md b/ja-jp/articles/quickstart/native/ionic-react/files/user-profile.md
new file mode 100644
index 0000000000..d3d719713b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/files/user-profile.md
@@ -0,0 +1,25 @@
+---
+name: user-profile.tsx
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from '@auth0/auth0-react';
+
+const Profile: React.FC = () => {
+  const { user, isLoading } = useAuth0();
+
+  // If the SDK is not ready, or a user is not authenticated, exit.
+  if (isLoading || !user) return null;
+
+  return (
+    
    
+      {user.name}
+      
    {user.name}
    
+      
    {user.email}
    
+    
    
+  );
+};
+
+export default Profile;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-react/index.yml b/ja-jp/articles/quickstart/native/ionic-react/index.yml
new file mode 100644
index 0000000000..135bac3db8
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/index.yml
@@ -0,0 +1,56 @@
+title: Ionic & Capacitor (React)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/ionic.jpeg
+logo_name: ionic
+logo: ionic
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - ionic
+  - react
+  - capacitor
+  - auth0-react
+language:
+  - Typescript
+framework:
+  - Ionic
+  - Capacitor
+  - React
+hybrid: true
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: ionic-react
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-ionic-samples
+  branch: main
+requirements:
+  - Node & Npm (LTS)
+  - XCode 12+ (for iOS)
+  - Android Studio 4+ (for Android)
+  - React 18
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/native/ionic-react/interactive.md b/ja-jp/articles/quickstart/native/ionic-react/interactive.md
new file mode 100644
index 0000000000..c983cb56e2
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/interactive.md
@@ -0,0 +1,137 @@
+---
+title: Add login to your Ionic React with Capacitor app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - react
+  - capacitor
+github:
+  path: react
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/index
+  - files/login-button
+  - files/logout-button
+  - files/app
+  - files/user-profile
+---
+
+# Add login to your Ionic React with Capacitor app
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (React) & Capacitor application using the [Auth0 React SDK](https://github.com/auth0/auth0-react).
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/ionic/_configure_urls_interactive') %>
+
+<%= include('../../_includes/_auth0-react-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+## Configure the `Auth0Provider` component {{{ data-action=code data-code="index.tsx" }}}
+
+Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` you can import from the SDK.
+
+The `Auth0Provider` component takes the following props:
+
+- `domain`: The `domain` value present under the **Settings** of the application you created in your Auth0 Dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains).
+- `clientId`: The Client ID value present under the **Settings** of the application you created in your Auth0 Dashboard.
+- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::: checkpoint
+:::checkpoint-default
+Add the `Auth0Provider` component in a way that wraps your `App` component, then run your application to verify that the SDK is initializing correctly and your application is not throwing any errors related to Auth0.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- ensure the correct application is selected
+- did you save after entering your URLs?
+- make sure the domain and Client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="login-button.tsx" }}}
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+::::checkpoint
+::: checkpoint-default
+The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- ensure that there are no errors in the browser's console window at the point of login
+- ensure the domain and Client ID are correct according to your Auth0 application in the dashboard
+- if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure
+  :::
+  ::::
+
+## Handle the login callback {{{ data-action=code data-code="app.tsx" }}}
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+::::checkpoint
+:::checkpoint-default
+Add the `appUrlOpen` to your application's `App` component and log in. The browser window should close once the user authenticates and logs in to your app.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) on Android
+- if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the reason for the error
+  :::
+  ::::
+
+## Add logout to your application {{{ data-action=code data-code="logout-button.tsx" }}}
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to log out of your application. Verify that you redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Check that you are no longer logged in to your application.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard
+  :::
+  ::::
+
+## Show the user profile {{{ data-action=code data-code="user-profile.tsx" }}}
+
+The Auth0 React SDK retrieves the [user's profile](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook.
+
+Initializing the SDK is asynchronous, and you should guard the user profile by checking the `isLoading` and `user` properties. Once `isLoading` is `false` and `user` has a value, the user profile can be used.
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that you are only reading the user's profile when `isLoading` is `false`
+- check that `user` resolves to an object and is not `undefined`
+  :::
+  ::::
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/01-login.md b/ja-jp/articles/quickstart/native/ionic-vue/01-login.md
new file mode 100644
index 0000000000..f29168389b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/01-login.md
@@ -0,0 +1,271 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - vue
+  - capacitor
+github:
+  path: vue
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-vue-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `createAuth0` plugin
+
+The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. To register this with your application:
+
+Open `src/main.ts` and install the plugin using `app.use`
+
+```javascript
+import { createApp } from "vue";
+import App from "./App.vue";
+import router from "./router";
+
+import { IonicVue } from "@ionic/vue";
+
+import { createAuth0 } from "@auth0/auth0-vue";
+import config from "./auth.config";
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+const app = createApp(App).use(IonicVue).use(router);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    useRefreshTokens: true,
+    useRefreshTokensFallback: false,
+    authorizationParams: {
+      redirect_uri
+    }
+  })
+);
+
+router.isReady().then(() => {
+  app.mount("#app");
+});
+```
+
+The `createAuth0` plugin takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `createAuth0` plugin, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.vue` with the following code:
+
+```html
+
+
+
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following capacitor application listener to your main `App` component:
+
+```html
+
+
+
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.vue` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```html
+
+
+
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 Vue SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable. Take this `UserProfile` component as an example of how to use it:
+
+```html
+
+
+
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before Vue renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `UserProfile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/download.md b/ja-jp/articles/quickstart/native/ionic-vue/download.md
new file mode 100644
index 0000000000..a0589fcf12
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/download.md
@@ -0,0 +1,38 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/app.md b/ja-jp/articles/quickstart/native/ionic-vue/files/app.md
new file mode 100644
index 0000000000..b8129bb76a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/app.md
@@ -0,0 +1,45 @@
+---
+name: App.vue
+language: html
+---
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/login-button.md b/ja-jp/articles/quickstart/native/ionic-vue/files/login-button.md
new file mode 100644
index 0000000000..a18deea1df
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/login-button.md
@@ -0,0 +1,40 @@
+---
+name: LoginButton.vue
+language: html
+---
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/logout-button.md b/ja-jp/articles/quickstart/native/ionic-vue/files/logout-button.md
new file mode 100644
index 0000000000..43940c7d70
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/logout-button.md
@@ -0,0 +1,44 @@
+---
+name: LogoutButton.vue
+language: html
+---
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/main.md b/ja-jp/articles/quickstart/native/ionic-vue/files/main.md
new file mode 100644
index 0000000000..9585448275
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/main.md
@@ -0,0 +1,38 @@
+---
+name: main.ts
+language: javascript
+---
+
+```javascript
+import { createApp } from "vue";
+import App from "./App.vue";
+import router from "./router";
+
+import { IonicVue } from "@ionic/vue";
+
+import { createAuth0 } from "@auth0/auth0-vue";
+import config from "./auth.config";
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+const app = createApp(App).use(IonicVue).use(router);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    useRefreshTokens: true,
+    useRefreshTokensFallback: false,
+    authorizationParams: {
+      redirect_uri
+    }
+  })
+);
+
+router.isReady().then(() => {
+  app.mount("#app");
+});
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/user-profile.md b/ja-jp/articles/quickstart/native/ionic-vue/files/user-profile.md
new file mode 100644
index 0000000000..e0c6f390ea
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/files/user-profile.md
@@ -0,0 +1,35 @@
+---
+name: UserProfile.vue
+language: html
+---
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/index.yml b/ja-jp/articles/quickstart/native/ionic-vue/index.yml
new file mode 100644
index 0000000000..52cbadde94
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/index.yml
@@ -0,0 +1,55 @@
+title: Ionic & Capacitor (Vue)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/ionic.jpeg
+logo_name: ionic
+logo: ionic
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - ionic
+  - vue
+  - capacitor
+  - auth0-vue
+language:
+  - Typescript
+framework:
+  - Ionic
+  - Capacitor
+  - Vue
+hybrid: true
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: ionic-vue
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-ionic-samples
+  branch: main
+requirements:
+  - Node & Npm (LTS)
+  - XCode 12+ (for iOS)
+  - Android Studio 4+ (for Android)
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/interactive.md b/ja-jp/articles/quickstart/native/ionic-vue/interactive.md
new file mode 100644
index 0000000000..6227d5b364
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/interactive.md
@@ -0,0 +1,137 @@
+---
+title: Add login to your Ionic Vue with Capacitor app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - vue
+  - capacitor
+github:
+  path: vue
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/main
+  - files/login-button
+  - files/logout-button
+  - files/app
+  - files/user-profile
+---
+
+# Add login to your Ionic Vue with Capacitor app
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with an Ionic (Vue) & Capacitor application using the [Auth0 Vue SDK](https://github.com/auth0/auth0-vue).
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/ionic/_configure_urls_interactive') %>
+
+<%= include('../../_includes/_auth0-vue-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+## Configure the `createAuth0` plugin {{{ data-action=code data-code="main.ts" }}}
+
+The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. This composable should be registered with your application and be configured with your Auth0 domain and Client ID.
+
+The `createAuth0` composable takes the following configuration:
+
+- `domain`: The `domain` value present under the **Settings** of the application you created in the Auth0 Dashboard, or your custom domain if you are using Auth0's [custom domains feature](http://localhost:3000/docs/custom-domains).
+- `clientId`: The Client ID value present under the **Settings** of the application you created in the Auth0 Dashboard.
+- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::: checkpoint
+:::checkpoint-default
+Now that you have configured your app with the Auth0 Vue SDK, run your application to verify that the SDK is initializing without error, and that your application runs as it did before.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- ensure the correct application is selected
+- did you save after entering your URLs?
+- make sure the domain and Client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="LoginButton.vue" }}}
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+::::checkpoint
+::: checkpoint-default
+The `loginWithRedirect` function tells the SDK to initiate the login flow, using the `Browser.open` function to open the login URL with the platform's system browser component by setting the `openUrl` parameter. This provides a way for your user to log in to your application. Users redirect to the login page at Auth0 and do not receive any errors.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- ensure that there are no errors in the browser's console window at the point of login
+- ensure the domain and Client ID are correct according to your Auth0 application in the dashboard
+- if you are redirected to Auth0 and receive an error page, check the "technical details" section at the bottom for the reason for the failure
+  :::
+  ::::
+
+## Handle the login callback {{{ data-action=code data-code="App.vue" }}}
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+::::checkpoint
+:::checkpoint-default
+Add the `appUrlOpen` to your application's `App` component setup and log in. The browser window should close once the user authenticates and logs in to your app.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that the custom URL scheme is registered for your chosen platform. On iOS, [define a custom URL scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app), or add an [intent filter with your custom scheme](https://developer.android.com/training/app-links/deep-linking) on Android
+- if the event fires but you receive an error, check the [logs in your Auth0 Dashboard](https://manage.auth0.com/#/logs) for the reason for the error
+  :::
+  ::::
+
+## Add logout to your application {{{ data-action=code data-code="LogoutButton.vue" }}}
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to log out of your application. Verify that you redirect to Auth0 and then to the address you specified in the `returnTo` parameter. Check that you are no longer logged in to your application.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that the URL you provided to in the `returnTo` parameter is registered as an allowed callback URL in your Auth0 Dashboard
+  :::
+  ::::
+
+## Show the user profile {{{ data-action=code data-code="UserProfile.vue" }}}
+
+The Auth0 Vue SDK retrieves the [user's profile](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable.
+
+Initializing the SDK is asynchronous, and you should guard the user profile by checking the `isLoading` and `user` properties. Once `isLoading` is `false` and `user` has a value, the user profile can be used.
+
+::::checkpoint
+:::checkpoint-default
+Provide a way for your users to see their user profile details within the app and verify you are able to retrieve and see your profile information on screen once you have logged in.
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+
+- check that you are only reading the user's profile when `isLoading` is `false`
+- check that `user` resolves to an object and is not `undefined`
+  :::
+  ::::
diff --git a/ja-jp/articles/quickstart/native/ios-swift/01-login.md b/ja-jp/articles/quickstart/native/ios-swift/01-login.md
new file mode 100755
index 0000000000..24cdf22165
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/01-login.md
@@ -0,0 +1,267 @@
+---
+title: Login
+description: This guide demonstrates how to integrate Auth0 with any new or existing iOS / macOS app using the Auth0.swift SDK.
+seo_alias: swift
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ios
+  - macos
+  - swift
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+## Configure Auth0
+
+You will need a **Native** Auth0 application. If you don’t have a Native Auth0 application already, [create one](/get-started/auth0-overview/create-applications/native-apps) before continuing. Avoid using other application types, as they have different configurations and may cause errors.
+
+### Configure the callback and logout URLs
+
+The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your app. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie.
+
+If the callback and logout URLs are not set, users will be unable to log in and out of the app and will get an error.
+
+::: note
+On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links as callback and logout URLs. When enabled, Auth0.swift will fall back to using a custom URL scheme on older iOS / macOS versions.
+
+**This feature requires Xcode 15.3+ and a paid Apple Developer account**.
+:::
+
+Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of the value from the settings page.
+
+#### iOS
+
+```text
+https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+#### macOS
+
+```text
+https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+For example, if your iOS bundle identifier were `com.example.MyApp` and your Auth0 domain were `example.us.auth0.com`, then this value would be:
+
+```text
+https://example.us.auth0.com/ios/com.example.MyApp/callback,
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+```
+
+### Configure the associated domain
+
+::: warning
+This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead.
+:::
+
+#### Configure the Team ID and bundle identifier
+
+Scroll to the end of the settings page of your Auth0 application and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier.
+
+
    Screenshot of the iOS section inside the Auth0 application settings page
    
+
+This will add your app to your Auth0 tenant's `apple-app-site-association` file.
+
+#### Add the associated domain capability
+
+In Xcode, go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of your app's target settings, and press the **+ Capability** button. Then select **Associated Domains**.
+
+
    Screenshot of the capabilities library inside Xcode
    
+
+Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a [custom domain](/customize/custom-domains), use this instead of the Auth0 domain from the settings page.
+
+::: note
+For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application.
+:::
+
+## Install the SDK
+
+Add the [Auth0.swift](https://github.com/auth0/Auth0.swift) SDK to your project. The library will make requests to the Auth0 Authentication and Management APIs.
+
+### Using the Swift Package Manager
+
+Open the following menu item in Xcode:
+
+**File > Add Package Dependencies...**
+
+In the **Search or Enter Package URL** search box enter this URL:
+
+```text
+https://github.com/auth0/Auth0.swift
+```
+
+Then, select the dependency rule and press **Add Package**..
+
+::: note
+For further reference on SPM, check its [official documentation](https://developer.apple.com/documentation/xcode/adding-package-dependencies-to-your-app).
+:::
+
+### Using Cocoapods
+
+Add the following line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 2.0'
+```
+
+Then, run `pod install`.
+
+::: note
+For further reference on Cocoapods, check their [official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Using Carthage
+
+Add the following line to your `Cartfile`:
+
+```text
+github "auth0/Auth0.swift" ~> 2.0
+```
+
+Then, run `carthage bootstrap --use-xcframeworks`.
+
+::: note
+For further reference on Carthage, check their [official documentation](https://github.com/Carthage/Carthage#getting-started).
+:::
+
+## Configure the SDK
+
+The Auth0.swift SDK needs the **Client ID** and **domain** of the Auth0 application to communicate with Auth0. You can find these details in the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application. If you are using a [custom domain](/customize/custom-domains), use the value of your custom domain instead of the value from the settings page.
+
+<% if(typeof hideDashboardScreenshot === 'undefined' || hideDashboardScreenshot !== true) { %>
+![Screenshot of the Auth0 application settings page](/media/articles/dashboard/client_settings.png)
+<% } %>
+
+Create a `plist` file named `Auth0.plist` in your app bundle with the following content:
+
+```xml
+
+
+
+
+    ClientId
+    ${account.clientId}
+    Domain
+    ${account.namespace}
+
+
+```
+
+::: note
+<% if(typeof hideDownloadSample === 'undefined' || hideDownloadSample !== true) { %>
+If you download the sample from the top of this page, these details are filled out for you.
+<% } %>
+You can also configure the SDK programmatically. Check the [README](https://github.com/auth0/Auth0.swift#configure-client-id-and-domain-programmatically) to learn more.
+:::
+
+::: panel Checkpoint
+Now that you have configured Auth0.swift with the Client ID and domain, run your app to verify that it is not producing any errors related to the SDK.
+:::
+
+## Login
+
+Import the `Auth0` module in the file where you want to present the login page.
+
+```swift
+import Auth0
+```
+
+Then, present the [Universal Login](/authenticate/login/auth0-universal-login) page in the action of your **Login** button.
+
+```swift
+Auth0
+    .webAuth()
+    .useHTTPS() // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+
+    .start { result in
+        switch result {
+        case .success(let credentials):
+            print("Obtained credentials: \(credentials)")
+        case .failure(let error):
+            print("Failed with: \(error)")
+        }
+    }
+```
+
+::: note
+You can use async/await or Combine instead of the callback-based API. Check the [README](https://github.com/auth0/Auth0.swift#web-auth-login-ios--macos) to learn more.
+:::
+
+
    Screenshot of the Universal Login page
    
+
+::: panel Checkpoint
+Verify that pressing the **Login** button shows an [alert box](https://github.com/auth0/Auth0.swift#sso-alert-box-ios--macos) asking for consent and that choosing **Continue** opens the Universal Login page in a Safari modal. Verify that you can log in or sign up using a username and password or a social provider.
+
+Once that is complete, verify that the Safari modal closes automatically.
+:::
+
+## Logout
+
+Now that you can log in to your app, you need a way to [log out](/authenticate/login/logout). In the action of your **Logout** button, call the `clearSession()` method to clear the Universal Login session cookie.
+
+```swift
+Auth0
+    .webAuth()
+    .useHTTPS() // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+
+    .clearSession { result in
+        switch result {
+        case .success:
+            print("Logged out")
+        case .failure(let error):
+            print("Failed with: \(error)")
+        }
+    }
+```
+
+::: panel Checkpoint
+Verify that pressing the **Logout** button shows an alert box asking for consent and that choosing **Continue** opens a page in a Safari modal. Verify that the Safari modal closes automatically soon after.
+:::
+
+## Access User Profile Information
+
+The `Credentials` instance you obtained after logging in includes an [ID Token](/secure/tokens/id-tokens). The ID Token contains the profile information associated with the logged-in user, such as their email and profile picture. You can use these details to personalize the user interface of your app.
+
+The Auth0.swift SDK includes a [utility](https://github.com/auth0/JWTDecode.swift) for decoding [JWTs](https://jwt.io/) like the ID Token. Start by importing the `JWTDecode` module in the file where you want to access the user profile information.
+
+```swift
+import JWTDecode
+```
+
+Then, use the `decode(jwt:)` method to decode the ID Token and access the claims it contains.
+
+```swift
+guard let jwt = try? decode(jwt: credentials.idToken),
+      let name = jwt["name"].string,
+      let picture = jwt["picture"].string else { return }
+print("Name: \(name)")
+print("Picture URL: \(picture)")
+```
+
+::: note
+You can retrieve the latest user information with the `userInfo(withAccessToken:)` method. Check the [EXAMPLES](https://github.com/auth0/Auth0.swift/blob/master/EXAMPLES.md#retrieve-user-information) to learn more.
+:::
+
+::: panel Checkpoint
+Verify that you can access the `email`, `picture`, or any other [claim](/secure/tokens/id-tokens/id-token-structure) after you have logged in.
+:::
+
+## What's Next?
+
+Check the SDK documentation to learn how to perform some common tasks, explore more advanced use cases, and discover all the available features:
+
+- [Next steps](https://github.com/auth0/Auth0.swift#next-steps)
+- [API documentation](https://auth0.github.io/Auth0.swift/)
+- [FAQ](https://github.com/auth0/Auth0.swift/blob/master/FAQ.md)
diff --git a/ja-jp/articles/quickstart/native/ios-swift/download.md b/ja-jp/articles/quickstart/native/ios-swift/download.md
new file mode 100644
index 0000000000..4e7e9e3db7
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/download.md
@@ -0,0 +1,20 @@
+
+
+> On every step, if you have a [custom domain](https://auth0.com/docs/customize/custom-domains), replace the `YOUR_AUTH0_DOMAIN` placeholder with your custom domain instead of the value from the settings page.
+
+## 1. Configure the associated domain
+
+> **This requires Xcode 15.3+ and a paid Apple Developer account**. If you do not have a paid Apple Developer account, skip this step, and comment out the two `useHTTPS()` calls in `MainView.swift`.
+
+Open `SwiftSample.xcodeproj` in Xcode and go to the settings of the app target you want to run. There are two app targets available: **SwiftSample (iOS)** and **SwiftSample (macOS)**. Change the bundle identifier from the default `com.auth0.samples.SwiftSample` to another value of your choosing. Then, make sure the **Automatically manage signing** box is checked, and that your Apple Team is selected.
+
+Next, go to the **Signing & Capabilities** tab of the app's target settings. Find the `webcredentials:YOUR_AUTH0_DOMAIN` entry under **Associated Domains**, and replace the `YOUR_AUTH0_DOMAIN` placeholder with the domain of your Auth0 application.
+
+Finally, open the settings page of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to the app's bundle identifier.
+
+## 2. Configure the Auth0 application
+
+Open the settings page of your Auth0 application and add the following URLs to **Allowed Callback URLs** and **Allowed Logout URLs**, depending on the app target you want to run.
+
+- **SwiftSample (iOS)**: `https://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/ios/YOUR_BUNDLE_IDENTIFIER/callback`
+- **SwiftSample (macOS)**: `https://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback,YOUR_BUNDLE_IDENTIFIER://YOUR_AUTH0_DOMAIN/macos/YOUR_BUNDLE_IDENTIFIER/callback`
diff --git a/ja-jp/articles/quickstart/native/ios-swift/files/Auth0.md b/ja-jp/articles/quickstart/native/ios-swift/files/Auth0.md
new file mode 100644
index 0000000000..a989cbd06a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/files/Auth0.md
@@ -0,0 +1,17 @@
+---
+name: Auth0.plist
+language: xml
+---
+
+```xml
+
+
+
+
+    ClientId
+    ${account.clientId}
+    Domain
+    ${account.namespace}
+
+
+```
diff --git a/ja-jp/articles/quickstart/native/ios-swift/files/MainView.md b/ja-jp/articles/quickstart/native/ios-swift/files/MainView.md
new file mode 100644
index 0000000000..e62095b332
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/files/MainView.md
@@ -0,0 +1,54 @@
+---
+name: MainView.swift
+language: swift
+---
+
+```swift
+import SwiftUI
+import Auth0
+
+struct MainView: View {
+    @State var user: User?
+
+    var body: some View {
+        if let user = self.user {
+            VStack {
+                ProfileView(user: user)
+                Button("Logout", action: self.logout)
+            }
+        } else {
+            Button("Login", action: self.login)
+        }
+    }
+}
+
+extension MainView {
+    func login() {
+        Auth0
+            .webAuth()
+            .useHTTPS() // Use a Universal Link callback URL on iOS 17.4+ / macOS 14.4+
+            .start { result in
+                switch result {
+                case .success(let credentials):
+                    self.user = User(from: credentials.idToken)
+                case .failure(let error):
+                    print("Failed with: \(error)")
+                }
+            }
+    }
+
+    func logout() {
+        Auth0
+            .webAuth()
+            .useHTTPS() // Use a Universal Link logout URL on iOS 17.4+ / macOS 14.4+
+            .clearSession { result in
+                switch result {
+                case .success:
+                    self.user = nil
+                case .failure(let error):
+                    print("Failed with: \(error)")
+                }
+            }
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/ios-swift/files/ProfileView.md b/ja-jp/articles/quickstart/native/ios-swift/files/ProfileView.md
new file mode 100644
index 0000000000..e476520a9d
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/files/ProfileView.md
@@ -0,0 +1,19 @@
+---
+name: ProfileView.swift
+language: swift
+---
+
+```swift
+import SwiftUI
+
+struct ProfileView: View {
+    let user: User
+
+    var body: some View {
+        VStack {
+            AsyncImage(url: URL(string: user.picture))
+            Text("Email: \(user.email)")
+        }
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/ios-swift/files/User.md b/ja-jp/articles/quickstart/native/ios-swift/files/User.md
new file mode 100644
index 0000000000..95b9bf43c2
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/files/User.md
@@ -0,0 +1,27 @@
+---
+name: User.swift
+language: swift
+---
+
+```swift
+import JWTDecode
+
+struct User {
+    let id: String
+    let email: String
+    let picture: String
+}
+
+extension User {
+    init?(from idToken: String) {
+        guard let jwt = try? decode(jwt: idToken),
+              let id = jwt.subject,
+              let email = jwt["email"].string,
+              let picture = jwt["picture"].string
+        else { return nil }
+        self.id = id
+        self.email = email
+        self.picture = picture
+    }
+}
+```
diff --git a/ja-jp/articles/quickstart/native/ios-swift/index.yml b/ja-jp/articles/quickstart/native/ios-swift/index.yml
new file mode 100755
index 0000000000..db922d99d6
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/index.yml
@@ -0,0 +1,38 @@
+title: iOS / macOS
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/ios.png
+logo: apple
+alias:
+  - ios
+  - macos
+  - swift
+language:
+  - Swift
+hybrid: false
+author:
+  name: Rita Zerrizuela
+  email: rita.zerrizuela@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: swift
+show_releases: true
+show_steps: true
+requirements:
+  - iOS 13+ or macOS 11+
+  - Xcode 14.x
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+sdk:
+  name: Auth0.swift
+  url: https://github.com/auth0/Auth0.swift
+  logo: apple
+github:
+  org: auth0-samples
+  repo: auth0-ios-swift-sample
+  branch: master
diff --git a/ja-jp/articles/quickstart/native/ios-swift/interactive.md b/ja-jp/articles/quickstart/native/ios-swift/interactive.md
new file mode 100644
index 0000000000..10babccc90
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ios-swift/interactive.md
@@ -0,0 +1,256 @@
+---
+title: Add Login to your iOS or macOS app
+description: This guide demonstrates how to add authentication and gain access to user profile information in any iOS / macOS app using the Auth0.swift SDK.
+interactive: true
+files:
+  - files/Auth0
+  - files/MainView
+  - files/ProfileView
+  - files/User
+seo_alias: swift
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ios
+  - macos
+  - swift
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+---
+
+# Add Login to Your iOS or macOS Application
+
+This guide demonstrates how to add authentication and access user profile information in any iOS / macOS app using the [Auth0.swift](https://github.com/auth0/Auth0.swift) SDK.
+
+To use this quickstart, you need to:
+* Sign up for a free Auth0 account or log in to Auth0.
+* Have an existing iOS / macOS app that you want to integrate. Alternatively, you can view or download a sample app after logging in.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the app you are developing.
+
+### Configure an Auth0 application
+
+Use the interactive selector to create a new Auth0 application or select an existing **Native** Auth0 application. Auth0 assigns every application an alphanumeric, unique Client ID that your app uses to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart automatically update your Auth0 application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample app instead.
+
+### Configure callback and logout URLs
+
+Auth0 invokes the callback and logout URLs to redirect users back to your app. Auth0 invokes the callback URL after authenticating the user and the logout URL after removing the session cookie. If you do not set the callback and login URLs, users will not be able to log in and out of the app, and your app will produce an error.
+
+::: note
+On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links as callback and logout URLs. When enabled, Auth0.swift will fall back to using a custom URL scheme on older iOS / macOS versions.
+
+**This feature requires Xcode 15.3+ and a paid Apple Developer account**.
+:::
+
+Add the following URLs to **Callback URLs** and **Logout URLs**, depending on the platform of your app. If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain.
+
+#### iOS
+
+```text
+https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+#### macOS
+
+```text
+https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback,
+YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback
+```
+
+For example, if your iOS bundle identifier was `com.example.MyApp` and your Auth0 domain was `example.us.auth0.com`, then this value would be:
+
+```text
+https://example.us.auth0.com/ios/com.example.MyApp/callback,
+com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback
+```
+
+### Configure the associated domain
+
+::: warning
+This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead.
+:::
+
+#### Configure the Team ID and bundle identifier
+
+Go to the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application, scroll to the end, and open **Advanced Settings > Device Settings**. In the **iOS** section, set **Team ID** to your [Apple Team ID](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/), and **App ID** to your app's bundle identifier.
+
+
    Screenshot of the iOS section inside the Auth0 application settings page
    
+
+This will add your app to your Auth0 tenant's `apple-app-site-association` file.
+
+#### Add the associated domain capability
+
+In Xcode, go to the **Signing and Capabilities** [tab](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app#Add-a-capability) of your app's target settings, and press the **+ Capability** button. Then select **Associated Domains**.
+
+
    Screenshot of the capabilities library inside Xcode
    
+
+Next, add the following [entry](https://developer.apple.com/documentation/xcode/configuring-an-associated-domain#Define-a-service-and-its-associated-domain) under **Associated Domains**:
+
+```text
+webcredentials:${account.namespace}
+```
+
+If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain.
+
+::: note
+For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application.
+:::
+
+## Install the SDK
+
+### Using the Swift Package Manager
+
+Open the following menu item in Xcode:
+
+**File > Add Package Dependencies...**
+
+In the **Search or Enter Package URL** search box enter this URL:
+
+```text
+https://github.com/auth0/Auth0.swift
+```
+
+Then, select the dependency rule and press **Add Package**.
+
+::: note
+For further reference on SPM, check its [official documentation](https://developer.apple.com/documentation/xcode/adding-package-dependencies-to-your-app).
+:::
+
+### Using Cocoapods
+
+Add the following line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 2.0'
+```
+
+Then, run `pod install`.
+
+::: note
+For further reference on Cocoapods, check their [official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Using Carthage
+
+Add the following line to your `Cartfile`:
+
+```text
+github "auth0/Auth0.swift" ~> 2.0
+```
+
+Then, run `carthage bootstrap --use-xcframeworks`.
+
+::: note
+For further reference on Carthage, check their [official documentation](https://github.com/Carthage/Carthage#getting-started).
+:::
+
+## Configure the SDK {{{ data-action=code data-code="Auth0.plist" }}}
+
+The Auth0.swift SDK needs your Auth0 **domain** and **Client ID**. You can find these values in the [settings page](${manage_url}/#/applications/${account.clientId}/settings) of your Auth0 application.
+
+- **domain**: The domain of your Auth0 tenant. If you have a [custom domain](/customize/custom-domains), use this instead of your Auth0 tenant’s domain.
+- **Client ID**: The alphanumeric, unique ID of the Auth0 application you set up earlier in this quickstart.
+
+Create a `plist` file named `Auth0.plist` in your app bundle containing the Auth0 domain and Client ID values. 
+
+::: note
+You can also configure the SDK programmatically. Check the [README](https://github.com/auth0/Auth0.swift#configure-client-id-and-domain-programmatically) to learn more.
+:::
+
+::::checkpoint
+:::checkpoint-default
+You configured the Auth0.swift SDK. Run your app to verify that it is not producing any errors related to the SDK.
+:::
+
+:::checkpoint-failure
+If your app produces errors related to the SDK:
+- Make sure you selected the correct Auth0 application
+- Verify you saved your URL updates
+- Ensure you set the Auth0 domain and Client ID correctly
+
+Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="MainView.swift#20:31" }}}
+
+Import the `Auth0` module in the file where you want to present the login page. Then, present the [Universal Login](/authenticate/login/auth0-universal-login) page in the action of your **Login** button.
+
+::: note
+You can use async/await or Combine instead of the callback-based API. Check the [README](https://github.com/auth0/Auth0.swift#web-auth-login-ios--macos) to learn more.
+:::
+
+
    Screenshot of the Universal Login page
    
+
+::::checkpoint
+:::checkpoint-default
+Press the **Login** button and verify that:
+- An [alert box](https://github.com/auth0/Auth0.swift#sso-alert-box-ios--macos) shows up asking for consent.
+- Choosing **Continue** opens the Universal Login page in a Safari modal.
+- You can log in or sign up using a username and password or a social provider.
+- The Safari modal closes automatically afterward.
+:::
+
+:::checkpoint-failure
+If login fails or produces errors:
+- Verify you entered the correct callback URL
+- Ensure you set the Auth0 domain and Client ID correctly
+
+Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="MainView.swift#33:44" }}}
+
+Now that you can log in to your app, you need a way to [log out](/authenticate/login/logout). In the action of your **Logout** button, call the `clearSession()` method to clear the Universal Login session cookie.
+
+::::checkpoint
+:::checkpoint-default
+Press the **Logout** button and verify that:
+- An alert box shows up asking for consent.
+- Choosing **Continue** opens a page in a Safari modal.
+- The Safari modal closes automatically soon after.
+:::
+
+:::checkpoint-failure
+If logout fails or produces errors:
+- Verify you entered the correct callback URL
+- Ensure you set the Auth0 domain and Client ID correctly
+
+Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Access user profile information {{{ data-action=code data-code="User.swift#11:14" }}}
+
+The `Credentials` instance you obtained after logging in includes an [ID token](/secure/tokens/id-tokens). The ID token contains the profile information associated with the logged-in user, such as their email and profile picture. You can use these details to personalize the user interface of your app.
+
+The Auth0.swift SDK includes a [utility](https://github.com/auth0/JWTDecode.swift) for decoding [JWTs](https://jwt.io/) like the ID token. Start by importing the `JWTDecode` module in the file where you want to access the user profile information. Then, use the `decode(jwt:)` method to decode the ID token and access the claims it contains.
+
+::: note
+You can retrieve the latest user information with the `userInfo(withAccessToken:)` method. Check the [EXAMPLES](https://github.com/auth0/Auth0.swift/blob/master/EXAMPLES.md#retrieve-user-information) to learn more.
+:::
+
+::::checkpoint
+:::checkpoint-default
+Verify that you can access the `email`, `picture`, or any other [claim](/secure/tokens/id-tokens/id-token-structure) after you have logged in.
+:::
+
+:::checkpoint-failure
+If you cannot access the user information:
+- Verify you imported the `JWTDecode` module where you invoke the `decode(jwt:)` method
+- Make sure you spelled your claims correctly
+
+Still having issues? Check out our [documentation](https://github.com/auth0/Auth0.swift#documentation) or visit our [community forums](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/native/maui/01-login.md b/ja-jp/articles/quickstart/native/maui/01-login.md
new file mode 100755
index 0000000000..3242d02d90
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/01-login.md
@@ -0,0 +1,157 @@
+---
+title: Add login to your MAUI application
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET MAUI application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - xamarin
+  - dotnet
+  - android
+  - ios
+github:
+    path: Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+::: note
+The MAUI SDK supports Android, iOS, macOS, and Windows. Continue reading for platform-specific configuration.
+:::
+
+
+
+
+<%= include('../_includes/_getting_started') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and appends additional parameters to it, including an access code which will be exchanged for an ID Token, Access Token, and Refresh Token.
+
+Since callback URLs can be manipulated, you will need to add your application's URL to your application's *Allowed Callback URLs* for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful.
+
+::: note
+When following along with this quickstart, configure `myapp://callback` as the *Allowed Callback URLs*.
+:::
+
+<%= include('../../../_includes/_logout_url') %>
+
+::: note
+When following along with this quickstart, configure `myapp://callback` as the *Allowed Logout URLs*.
+:::
+
+## Install the Auth0 SDK
+
+Auth0 provides a [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/) SDK to simplify the process of implementing Auth0 authentication in MAUI applications.
+
+Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.MAUI` package.
+
+Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`).
+
+```ps
+Install-Package Auth0.OidcClient.MAUI
+```
+```
+dotnet add package Auth0.OidcClient.MAUI
+```
+
+## Platform specific configuration
+
+You need some platform-specific configuration to use the SDK with Android and Windows.
+
+### Android
+Create a new Activity that extends `WebAuthenticatorCallbackActivity`:
+
+```csharp
+[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)]
+[IntentFilter(new[] { Intent.ActionView },
+              Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
+              DataScheme = CALLBACK_SCHEME)]
+public class WebAuthenticatorActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity
+{
+    const string CALLBACK_SCHEME = "myapp";
+}
+```
+
+The above activity will ensure the application can handle the `myapp://callback` URL when Auth0 redirects back to the Android application after logging in.
+
+### Windows
+To make sure it can properly reactivate your application after being redirected back to Auth0, you need to do two things:
+
+- Add the corresponding protocol to the `Package.appxmanifest`. In this case, this is set to `myapp`, but you can change this to whatever you like (ensure to update all relevant Auth0 URLs as well).
+  ```xml
+  
+    
+      
+        
+          
+        
+      
+    
+  
+  ```
+- Call `Activator.Default.CheckRedirectionActivation()` in the Windows-specific `App.xaml.cs` file.
+  ```csharp
+  public App()
+  {
+    if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation())
+      return;
+  
+    this.InitializeComponent();
+  }
+  ```
+
+## Instantiate the Auth0Client
+
+To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain, Client ID and the required Scopes.
+Additionally, you also need to configure the `RedirectUri` and `PostLogoutRedirectUri` to ensure Auth0 can redirect back to the application using the URL(s) configured.
+
+```csharp
+using Auth0.OidcClient;
+
+var client = new Auth0Client(new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.namespace}",
+    RedirectUri = "myapp://callback",
+    PostLogoutRedirectUri = "myapp://callback",
+    Scope = "openid profile email"
+});
+```
+
+By default, the SDK will leverage Chrome Custom Tabs for Android, ASWebAuthenticationSession for iOS and macOS and use your system's default browser on Windows.
+
+## Add Login to Your Application
+
+Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. 
+
+```csharp
+var loginResult = await client.LoginAsync();
+```
+
+If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`.
+
+## Add Logout to Your Application
+
+Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart.
+
+```csharp
+await client.LogoutAsync();
+```
+
+## Show User Profile Information
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 SDK for MAUI provides user information through the `LoginResult.User` property.
+
+```csharp
+if (loginResult.IsError == false)
+{
+    var user = loginResult.User;
+    var name = user.FindFirst(c => c.Type == "name")?.Value;
+    var email = user.FindFirst(c => c.Type == "email")?.Value;
+    var picture = user.FindFirst(c => c.Type == "picture")?.Value;
+}
+```
diff --git a/ja-jp/articles/quickstart/native/maui/download.md b/ja-jp/articles/quickstart/native/maui/download.md
new file mode 100644
index 0000000000..65c7470855
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/download.md
@@ -0,0 +1,22 @@
+To run the sample first set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings):
+
+  ```text
+myapp://callback
+  ```
+
+Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings):
+
+  ```text
+myapp://callback
+  ```
+
+Then, to run it **on Windows**:
+
+1) Open the Auth0MauiApp.sln in [Visual Studio 2022](https://www.visualstudio.com/vs/).
+2) Click the **Start** button (the green play button), ensure to select your target device. 
+You can also start the application using the **Debug | Start Debugging** option from the main menu.
+
+To run it on **macOS**:
+
+1) Open the Auth0MauiApp.sln in [Visual Studio for Mac](https://visualstudio.microsoft.com/vs/mac/).
+2) Click the **Start** button (the play button), ensure to select your target device. You can also start the application using the **Run | Start Debugging** option from the application menu
diff --git a/ja-jp/articles/quickstart/native/maui/files/main-page.md b/ja-jp/articles/quickstart/native/maui/files/main-page.md
new file mode 100644
index 0000000000..6bb02cb95e
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/files/main-page.md
@@ -0,0 +1,74 @@
+---
+name: MainPage.xaml.cs
+language: csharp
+---
+
+```csharp
+public partial class MainPage : ContentPage
+{
+    Auth0Client client = new Auth0Client(new Auth0ClientOptions
+    {
+        Domain = "${account.namespace}"
+        ClientId = "${account.clientId}",
+        RedirectUri = "myapp://callback",
+        PostLogoutRedirectUri = "myapp://callback",
+        Scope = "openid profile email"
+    });
+
+    public MainPage()
+    {
+        InitializeComponent();
+    }
+
+    private async void OnLoginClicked(object sender, EventArgs e)
+    {
+        var extraParameters = new Dictionary();
+        var audience = ""; // FILL WITH AUDIENCE AS NEEDED
+
+        if (!string.IsNullOrEmpty(audience))
+            extraParameters.Add("audience", audience);
+
+        var result = await client.LoginAsync(extraParameters);
+
+        DisplayResult(result);
+    }
+
+    private async void OnLogoutClicked(object sender, EventArgs e)
+    {
+        BrowserResultType browserResult = await client.LogoutAsync();
+
+        if (browserResult != BrowserResultType.Success)
+        {
+            ErrorLabel.Text = browserResult.ToString();
+            return;
+        }
+
+        LogoutBtn.IsVisible = false;
+        LoginBtn.IsVisible = true;
+
+        HelloLabel.Text = $"Hello, World!";
+        ErrorLabel.Text = "";
+    }
+
+    private void DisplayResult(LoginResult loginResult)
+    {
+        if (loginResult.IsError)
+        {
+            ErrorLabel.Text = loginResult.Error;
+            return;
+        }
+
+        var user = loginResult.User;
+        var name = user.FindFirst(c => c.Type == "name")?.Value;
+        var email = user.FindFirst(c => c.Type == "email")?.Value;
+        var picture = user.FindFirst(c => c.Type == "picture")?.Value;
+        
+        LogoutBtn.IsVisible = true;
+        LoginBtn.IsVisible = false;
+
+
+        HelloLabel.Text = $"Hello, {loginResult.User.Identity.Name}";
+        ErrorLabel.Text = "";
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/maui/index.yml b/ja-jp/articles/quickstart/native/maui/index.yml
new file mode 100755
index 0000000000..f0dc62f629
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/index.yml
@@ -0,0 +1,49 @@
+title: MAUI
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/xamarin.png
+logo: dotnet-platform
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@okta.com
+  community: false
+language:
+  - C#
+framework:
+  - maui
+hybrid: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: maui
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-maui-samples
+sdk:
+  name: auth0-oidc-client-net
+  url: https://github.com/auth0/auth0-oidc-client-net
+  logo: dotnet
+requirements:
+  - Visual Studio 2022+ or Visual Studio for Mac
+  - .NET6+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/native/maui/interactive.md b/ja-jp/articles/quickstart/native/maui/interactive.md
new file mode 100644
index 0000000000..03c9607e77
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,203 @@
+---
+title: Add login to your .NET MAUI application
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET MAUI application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - maui
+  - dotnet
+  - android
+  - ios
+  - windows
+github:
+  path: Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/main-page
+---
+
+# Add Login to Your MAUI Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any .NET MAUI application using the Auth0 SDKs for [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/).
+
+::: note
+The MAUI SDK supports Android, iOS, macOS, and Windows. Continue reading for platform-specific configuration.
+:::
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'myapp://callback',
+  returnTo: 'myapp://callback'
+}) %>
+
+## Install the Auth0 SDK
+
+Auth0 provides a [MAUI](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/) SDK to simplify the process of implementing Auth0 authentication in MAUI applications.
+
+Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.MAUI` package.
+
+Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`).
+
+```ps
+Install-Package Auth0.OidcClient.MAUI
+```
+```
+dotnet add package Auth0.OidcClient.MAUI
+```
+
+## Platform specific configuration
+
+You need some platform-specific configuration to use the SDK with Android and Windows.
+
+### Android
+Create a new Activity that extends `WebAuthenticatorCallbackActivity`:
+
+```csharp
+[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)]
+[IntentFilter(new[] { Intent.ActionView },
+              Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
+              DataScheme = CALLBACK_SCHEME)]
+public class WebAuthenticatorActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity
+{
+    const string CALLBACK_SCHEME = "myapp";
+}
+```
+
+The above activity will ensure the application can handle the `myapp://callback` URL when Auth0 redirects back to the Android application after logging in.
+
+### Windows
+To make sure it can properly reactivate your application after being redirected back to Auth0, you need to do two things:
+
+- Add the corresponding protocol to the `Package.appxmanifest`. In this case, this is set to `myapp`, but you can change this to whatever you like (ensure to update all relevant Auth0 URLs as well).
+  ```xml
+  
+    
+      
+        
+          
+        
+      
+    
+  
+  ```
+- Call `Activator.Default.CheckRedirectionActivation()` in the Windows-specific `App.xaml.cs` file.
+  ```csharp
+  public App()
+  {
+    if (Auth0.OidcClient.Platforms.Windows.Activator.Default.CheckRedirectionActivation())
+      return;
+  
+    this.InitializeComponent();
+  }
+  ```
+
+## Instantiate the Auth0Client {{{ data-action="code" data-code="MainPage.xaml.cs#3-10" }}}
+
+To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain, Client ID and the required Scopes.
+Additionally, you also need to configure the `RedirectUri` and `PostLogoutRedirectUri` to ensure Auth0 can redirect back to the application using the URL(s) configured.
+
+```csharp
+using Auth0.OidcClient;
+
+var client = new Auth0Client(new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.clientId}",
+    RedirectUri = "myapp://callback",
+    PostLogoutRedirectUri = "myapp://callback",
+    Scope = "openid profile email"
+});
+```
+
+By default, the SDK will leverage Chrome Custom Tabs for Android, ASWebAuthenticationSession for iOS and macOS and use your system's default browser on Windows.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Your `Auth0Client` should now be properly instantiated. Run your application to verify that:
+- the `Auth0Client` is instantiated correctly in the `MainPage`.
+- your application is not throwing any errors related to Auth0
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add login to your application {{{ data-action="code" data-code="MainPage.xaml.cs#25" }}}
+
+Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. 
+
+```csharp
+var loginResult = await client.LoginAsync();
+```
+
+If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`.
+
+::::checkpoint
+
+:::checkpoint-default
+
+You should now be able to log in or sign up using a username and password.
+
+Click the login button and verify that:
+* your application redirects you to the Auth0 Universal Login page
+* you can log in or sign up
+* Auth0 redirects you to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's something to double-check:
+* you called `LoginAsync` as expected
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action="code" data-code="MainPage.xaml.cs#32" }}}
+
+Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart.
+
+```csharp
+await client.LogoutAsync();
+```
+
+::::checkpoint
+
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* your application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings
+* you are no longer logged in to your application
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* you configured the correct Logout URL
+* you called `LogoutAsync` as expected.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show User Profile Information {{{ data-action="code" data-code="MainPage.xaml.cs#55-58" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 SDK for MAUI provides user information through the `LoginResult.User` property.
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/01-login.md b/ja-jp/articles/quickstart/native/net-android-ios/01-login.md
new file mode 100755
index 0000000000..992d4e2d37
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/01-login.md
@@ -0,0 +1,227 @@
+---
+title: Add login to your .NET Android or iOS application
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET Android or iOS application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - xamarin
+  - dotnet
+  - android
+  - ios
+github:
+    path: Quickstart/01-Login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: note
+This quickstart focusses on .NET Android and iOS, as they are the next generation of `Xamarin.Android` and `Xamarin.iOS`. If you are still using `Xamarin.Android` and `Xamarin.iOS`, you can follow this guide as well as integration is identical and the SDKs are compatible.
+:::
+
+
+
+<%= include('../_includes/_getting_started', { library: 'Xamarin') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and appends additional parameters to it, including an access code which will be exchanged for an ID Token, Access Token, and Refresh Token.
+
+Since callback URLs can be manipulated, you will need to add your application's URL to your application's *Allowed Callback URLs* for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful.
+
+* For Android, the callback URL will be in the format
+
+  ```text
+  YOUR_ANDROID_PACKAGE_NAME://${account.namespace}/android/YOUR_ANDROID_PACKAGE_NAME/callback
+  ```
+
+  where `YOUR_ANDROID_PACKAGE_NAME` is the Package Name for your application, such as `com.mycompany.myapplication`.
+
+* For iOS, the callback URL will be in the format
+
+  ```text
+  YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback
+  ```
+
+  where `YOUR_BUNDLE_IDENTIFIER` is the Bundle Identifier for your application, such as `com.mycompany.myapplication`.
+
+Ensure that the Callback URL is in lowercase.
+
+<%= include('../../../_includes/_logout_url') %>
+
+::: note
+If you are following along with the sample project you downloaded from the top of this page, the logout URL you need to add to the Allowed Logout URLs field is the same as the callback URL.
+:::
+
+## Install Dependencies
+
+${snippet(meta.snippets.dependencies)}
+
+## Trigger Authentication
+
+To integrate Auth0 login into your application, instantiate an instance of the `Auth0Client` class, configuring the Auth0 Domain and Client ID:
+
+${snippet(meta.snippets.setup)}
+
+Then, call the `LoginAsync` method which will redirect the user to the login screen. You will typically do this in the event handler for a UI control such as a Login button.
+
+```cs
+var loginResult = await client.LoginAsync();
+```
+
+### Handing the callback URL
+
+After a user has logged in, they will be redirected back to your application at the **Callback URL** that was registered before. In both Android and iOS you need to handle this callback to complete the authentication flow.
+
+### Android
+
+Register an intent which will handle this callback URL. An easy way to do this is to register the intent on the same activity from which you called the `LoginAsync` method to initiate the authentication flow.
+
+```csharp
+[Activity(Label = "AndroidSample", MainLauncher = true, Icon = "@drawable/icon",
+    LaunchMode = LaunchMode.SingleTask)]
+[IntentFilter(
+    new[] { Intent.ActionView },
+    Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
+    DataScheme = "YOUR_ANDROID_PACKAGE_NAME",
+    DataHost = "${account.namespace}",
+    DataPathPrefix = "/android/YOUR_ANDROID_PACKAGE_NAME/callback")]
+public class MainActivity : Activity
+{
+    // Code omitted
+}
+```
+
+Replace `YOUR_ANDROID_PACKAGE_NAME` in the code sample above with the actual Package Name for your application, such as `com.mycompany.myapplication`. Also ensure that all the text for the `DataScheme`, `DataHost`, and `DataPathPrefix` is in lower case. Also, set `LaunchMode = LaunchMode.SingleTask` for the `Activity`, otherwise the system will create a new instance of the activity every time the Callback URL gets called.
+
+Now write code to handle the intent. You can do this by overriding the `OnNewIntent` method. Inside the method you need to call the `Send` method on the `ActivityMediator` to complete the authentication cycle:
+
+```csharp
+protected override async void OnNewIntent(Intent intent)
+{
+    base.OnNewIntent(intent);
+
+    Auth0.OidcClient.ActivityMediator.Instance.Send(intent.DataString);
+}
+```
+
+### iOS
+
+Register the URL scheme for your Callback URL which your application should handle:
+
+1. Open your application's `Info.plist` file in Visual Studio for Mac, and go to the **Advanced** tab.
+2. Under **URL Types**, click the **Add URL Type** button
+3. Set the **Identifier** as `Auth0`, the **URL Schemes** the same as your application's **Bundle Identifier**, and the **Role** as `None`
+
+This is an example of the XML representation of your `info.plist` file after you have added the URL Type:
+
+```xml
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        Auth0
+        CFBundleURLSchemes
+        
+            YOUR_BUNDLE_IDENTIFIER
+        
+    
+
+```
+
+You need to handle the Callback URL in the `OpenUrl` event in your `AppDelegate` class.  You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, pass along the URL that was sent in:
+
+```csharp
+using Auth0.OidcClient;
+
+[Register("AppDelegate")]
+public class AppDelegate : UIApplicationDelegate
+{
+    public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation)
+    {
+        ActivityMediator.Instance.Send(url.AbsoluteString);
+
+        return true;
+    }
+}
+```
+
+### Run the application
+
+With the above code in place, a user can log in to your application using Auth0.
+
+
    
+    Universal Login
+
    
+
+## Accessing the User's Information
+
+The returned login result will indicate whether authentication was successful and if so contain the tokens and claims of the user.
+
+### Authentication Error
+
+You can check the `IsError` property of the result to see whether the login has failed. The `ErrorMessage` will contain more information regarding the error which occurred.
+
+```csharp
+var loginResult = await client.LoginAsync();
+
+if (loginResult.IsError)
+{
+    Debug.WriteLine($"An error occurred during login: {loginResult.Error}")
+}
+```
+
+### Accessing the tokens
+
+On successful login, the login result will contain the ID Token and Access Token in the `IdentityToken` and `AccessToken` properties respectively.
+
+```csharp
+var loginResult = await client.LoginAsync();
+
+if (!loginResult.IsError)
+{
+    Debug.WriteLine($"id_token: {loginResult.IdentityToken}");
+    Debug.WriteLine($"access_token: {loginResult.AccessToken}");
+}
+```
+
+### Obtaining the User Information
+
+On successful login, the login result will contain the user information in the `User` property, which is a [ClaimsPrincipal](https://msdn.microsoft.com/en-us/library/system.security.claims.claimsprincipal(v=vs.110).aspx).
+
+To obtain information about the user, you can query the claims. You can, for example, obtain the user's name and email address from the `name` and `email` claims:
+
+```csharp
+if (!loginResult.IsError)
+{
+    Debug.WriteLine($"name: {loginResult.User.FindFirst(c => c.Type == "name")?.Value}");
+    Debug.WriteLine($"email: {loginResult.User.FindFirst(c => c.Type == "email")?.Value}");
+}
+```
+
+::: note
+The exact claims returned will depend on the scopes that were requested. For more information see the [Using Scopes](https://auth0.github.io/auth0-oidc-client-net/documentation/advanced-scenarios/scopes.html) in the Auth0 OIDC Application documentation.
+:::
+
+You can obtain a list of all the claims contained in the ID Token by iterating through the `Claims` collection:
+
+```csharp
+if (!loginResult.IsError)
+{
+    foreach (var claim in loginResult.User.Claims)
+    {
+        Debug.WriteLine($"{claim.Type} = {claim.Value}");
+    }
+}
+```
+
+## Logout
+
+To log the user out call the `LogoutAsync` method.
+
+```csharp
+BrowserResultType browserResult = await client.LogoutAsync();
+```
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md b/ja-jp/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md
new file mode 100644
index 0000000000..471c0f77bb
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/_configure_urls_interactive.md
@@ -0,0 +1,37 @@
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project.
+
+### Configure an application
+
+Use the interactive selector to create a new "Native Application", or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to one of the following URLs, depending on your platform:
+
+**Android**: `YOUR_PACKAGE_NAME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback`
+
+**iOS**: `YOUR_BUNDLE_ID://${account.namespace}/ios/YOUR_BUNDLE_ID/callback`
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to one of the following URLs, depending on your platform:
+
+**Android**: `YOUR_PACKAGE_NAME://${account.namespace}/android/YOUR_PACKAGE_NAME/callback`
+
+**iOS**: `YOUR_BUNDLE_ID://${account.namespace}/ios/YOUR_BUNDLE_ID/callback`
+:::
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/download.md b/ja-jp/articles/quickstart/native/net-android-ios/download.md
new file mode 100644
index 0000000000..6aca335de9
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/download.md
@@ -0,0 +1,22 @@
+To run the sample first set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) so it works for both Android and iOS apps:
+
+  ```text
+com.auth0.quickstart://${account.namespace}/android/com.auth0.quickstart/callback com.auth0.iossample://${account.namespace}/ios/com.auth0.iossample/callback
+  ```
+
+Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) so it works for both Android and iOS apps:
+
+  ```text
+com.auth0.quickstart://${account.namespace}/android/com.auth0.quickstart/callback com.auth0.iossample://${account.namespace}/ios/com.auth0.iossample/callback
+  ```
+
+Then, to run it **on Windows**:
+
+1) Open the AndroidSample.sln or iOSSample.sln solution in [Visual Studio 2017](https://www.visualstudio.com/vs/).
+2) Click the **Start** button (the green play button), optionally selecting your target device. 
+You can also start the application using the **Debug | Start Debugging** option from the main menu.
+
+To run it on **macOS**:
+
+1) Open the AndroidSample.sln or iOSSample.sln solution in [Visual Studio for Mac](https://visualstudio.microsoft.com/vs/mac/).
+2) Click the **Start** button (the play button), optionally selecting your target device. You can also start the application using the **Run | Start Debugging** option from the application menu
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/files/app-delegate.md b/ja-jp/articles/quickstart/native/net-android-ios/files/app-delegate.md
new file mode 100644
index 0000000000..4968ce3e1e
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/app-delegate.md
@@ -0,0 +1,19 @@
+---
+name: AppDelegate.cs
+language: csharp
+---
+
+```csharp
+using Auth0.OidcClient;
+
+[Register("AppDelegate")]
+public class AppDelegate : UIApplicationDelegate
+{
+    public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation)
+    {
+        ActivityMediator.Instance.Send(url.AbsoluteString);
+
+        return true;
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/files/main-activity.md b/ja-jp/articles/quickstart/native/net-android-ios/files/main-activity.md
new file mode 100644
index 0000000000..513b7067ee
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/main-activity.md
@@ -0,0 +1,57 @@
+---
+name: MainActivity.cs
+language: csharp
+---
+
+```csharp
+// Example of a full Android Activity
+[Activity(Label = "AndroidSample", MainLauncher = true, Icon = "@drawable/icon",
+    LaunchMode = LaunchMode.SingleTask)]
+[IntentFilter(
+    new[] { Intent.ActionView },
+    Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
+    DataScheme = "YOUR_ANDROID_PACKAGE_NAME",
+    DataHost = "{yourDomain}",
+    DataPathPrefix = "/android/YOUR_ANDROID_PACKAGE_NAME/callback")]
+public class MainActivity : Activity
+{    
+    private Auth0Client _auth0Client;
+
+    protected override void OnNewIntent(Intent intent)
+    {
+        base.OnNewIntent(intent);
+        ActivityMediator.Instance.Send(intent.DataString);
+    }
+
+    protected override void OnCreate(Bundle bundle)
+    {
+        base.OnCreate(bundle);
+
+        Auth0ClientOptions clientOptions = new Auth0ClientOptions
+        {
+            Domain = "${account.namespace}"
+            ClientId = "${account.clientId}"
+        };
+
+        _auth0Client = new Auth0Client(clientOptions, this);
+    }
+
+    private async void LoginButtonOnClick(object sender, EventArgs eventArgs)
+    {
+        var loginResult = await _auth0Client.LoginAsync();
+
+        if (loginResult.IsError == false)
+        {
+            var user = loginResult.User;
+            var name = user.FindFirst(c => c.Type == "name")?.Value;
+            var email = user.FindFirst(c => c.Type == "email")?.Value;
+            var picture = user.FindFirst(c => c.Type == "picture")?.Value;
+        }
+    }
+
+    private async void LogoutButtonOnClick(object sender, EventArgs e)
+    {
+        await _auth0Client.LogoutAsync();
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/files/my-view-controller.md b/ja-jp/articles/quickstart/native/net-android-ios/files/my-view-controller.md
new file mode 100644
index 0000000000..e67f6d00fc
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/files/my-view-controller.md
@@ -0,0 +1,47 @@
+---
+name: MyViewController.cs
+language: csharp
+---
+
+```csharp
+// Example of a full iOS UIViewController
+public partial class MyViewController : UIViewController
+{
+    private Auth0Client _auth0Client;
+
+    public MyViewController() : base("MyViewController", null)
+    {
+    }
+
+    public override void ViewDidLoad()
+    {
+        base.ViewDidLoad();
+
+        Auth0ClientOptions clientOptions = new Auth0ClientOptions
+        {
+            Domain = "${account.namespace}"
+            ClientId = "${account.clientId}"
+        };
+        
+        _auth0Client = new Auth0Client(clientOptions, this);
+    }
+
+    private async void LoginButton_TouchUpInside(object sender, EventArgs e)
+    {
+        var loginResult = await _auth0Client.LoginAsync();
+
+        if (loginResult.IsError == false)
+        {
+            var user = loginResult.User;
+            var name = user.FindFirst(c => c.Type == "name")?.Value;
+            var email = user.FindFirst(c => c.Type == "email")?.Value;
+            var picture = user.FindFirst(c => c.Type == "picture")?.Value;
+        }
+    }
+
+    private async void LogoutButton_TouchUpInside(object sender, EventArgs e)
+    {
+        await _auth0Client.LogoutAsync();
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/index.yml b/ja-jp/articles/quickstart/native/net-android-ios/index.yml
new file mode 100755
index 0000000000..7c97755a57
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/index.yml
@@ -0,0 +1,53 @@
+title: .NET Android and iOS
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/xamarin.png
+logo: dotnet
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+language:
+  - C#
+framework:
+  - net-android-ios
+hybrid: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: native-platforms/xamarin/dependencies
+  setup: native-platforms/xamarin/setup
+seo_alias: xamarin
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-xamarin-oidc-samples
+sdk:
+  name: auth0-oidc-client-net
+  url: https://github.com/auth0/auth0-oidc-client-net
+  logo: xamarin
+requirements:
+  - Visual Studio 2022+ or Visual Studio for Mac
+  - Xamarin for Visual Studio
+  - .NET6+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/native/net-android-ios/interactive.md b/ja-jp/articles/quickstart/native/net-android-ios/interactive.md
new file mode 100644
index 0000000000..b1a779cc84
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/net-android-ios/interactive.md
@@ -0,0 +1,208 @@
+---
+title: Add login to your .NET Android or iOS application
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to a .NET Android or iOS application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - xamarin
+  - dotnet
+  - android
+  - ios
+github:
+  path: Quickstart/01-Login
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/main-activity
+  - files/app-delegate
+  - files/my-view-controller
+---
+
+# Add Login to Your .NET Android and iOS Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any .NET Android and iOS application using the Auth0 SDKs for [Android](https://www.nuget.org/packages/Auth0.OidcClient.AndroidX/) and [iOS](https://www.nuget.org/packages/Auth0.OidcClient.iOS).
+
+::: note
+This quickstart focusses on .NET Android and iOS, as they are the next generation of `Xamarin.Android` and `Xamarin.iOS`. If you are still using `Xamarin.Android` and `Xamarin.iOS`, you can follow this guide as well as integration is identical and the SDKs are compatible.
+:::
+
+To use this quickstart, you’ll need to:
+
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working Android or iOS project using .NET 6 (or above) that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+<%= include('_configure_urls_interactive') %>
+
+## Install the Auth0 SDK
+
+Auth0 provides an [Android](https://www.nuget.org/packages/Auth0.OidcClient.AndroidX/) and [iOS](https://www.nuget.org/packages/Auth0.OidcClient.iOS) SDK to simplify the process of implementing Auth0 authentication in .NET Android and iOS applications.
+
+Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the `Auth0.OidcClient.AndroidX` or `Auth0.OidcClient.iOS` package, depending on whether you are building an Android or iOS application.
+
+Alternatively, you can use the Nuget Package Manager Console (`Install-Package`) or the `dotnet` CLI (`dotnet add`).
+
+```ps
+Install-Package Auth0.OidcClient.AndroidX
+Install-Package Auth0.OidcClient.iOS
+```
+```
+dotnet add Auth0.OidcClient.AndroidX
+dotnet add Auth0.OidcClient.iOS
+```
+
+## Instantiate the Auth0Client
+
+To integrate Auth0 into your application, instantiate an instance of the `Auth0Client` class, passing an instance of `Auth0ClientOptions` that contains your Auth0 Domain and Client ID.
+
+```csharp
+using Auth0.OidcClient;
+
+var client = new Auth0Client(new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.namespace}"
+}, this);
+```
+
+By default, the SDK will leverage Chrome Custom Tabs for Android and ASWebAuthenticationSession for iOS.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Your `Auth0Client` should now be properly instantiated. Run your application to verify that:
+- the `Auth0Client` is instantiated correctly in the `Activity` (Android) or `UIViewController` (iOS)
+- your application is not throwing any errors related to Auth0
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Configure Android {{{ data-action="code" data-code="MainActivity.cs#2-9,14-18" }}}
+
+After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+To handle the callback on Android devices, you need to register an intent that handles this callback URL. An easy way to do this is to register the intent on the same activity from which you called the LoginAsync method to instantiate the authentication flow.
+
+Ensure to replace `YOUR_ANDROID_PACKAGE_NAME` in the code sample with the actual Package Name for your application, such as com.mycompany.myapplication, and ensure that all the text for the `DataScheme`, `DataHost`, and `DataPathPrefix` is in lower case. Also, set `LaunchMode = LaunchMode.SingleTask` for the Activity, otherwise the system will create a new instance of the activity every time the Callback URL gets called.
+
+Additionally, you need to handle the intent in the `OnNewIntent` event in your `Activity` class. You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, passing along the URL that was sent in.
+
+## Configure iOS {{{ data-action="code" data-code="AppDelegate.cs#6-11" }}}
+
+After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+To handle the callback on iOS devices:
+
+- Open your application's `Info.plist` file in Visual Studio, and go to the **Advanced** tab.
+- Under **URL Types**, click the **Add URL Type** button
+- Set the **Identifier** as Auth0, the **URL Schemes** the same as your application's Bundle Identifier, and the **Role** as None
+
+This is an example of the XML representation of your `info.plist` file after you have added the URL Type:
+
+```xml
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        Auth0
+        CFBundleURLSchemes
+        
+            YOUR_BUNDLE_IDENTIFIER
+        
+    
+
+```
+
+Additionally, you need to handle the Callback URL in the `OpenUrl` event in your `AppDelegate` class. You need to notify the Auth0 OIDC Client to finish the authentication flow by calling the `Send` method of the `ActivityMediator` singleton, passing along the URL that was sent in.
+
+## Add login to your application 
+
+Now that you have configured your Auth0 Application and the Auth0 SDK, you need to set up login for your project. To do this, you will use the SDK’s `LoginAsync()` method to create a login button that redirects users to the Auth0 Universal Login page. 
+
+```csharp
+var loginResult = await client.LoginAsync();
+```
+
+If there isn't any error, you can access the `User`, `IdentityToken`, `AccessToken` and `RefreshToken` on the `LoginResult` returned from `LoginAsync()`.
+
+::::checkpoint
+
+:::checkpoint-default
+
+You should now be able to log in or sign up using a username and password.
+
+Click the login button and verify that:
+* your Android or iOS application redirects you to the Auth0 Universal Login page
+* you can log in or sign up
+* Auth0 redirects you to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's something to double-check:
+* you called `LoginAsync` as expected
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application
+
+Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s `LogoutAsync()` method. When users log out, they will be redirected to your Auth0 logout endpoint, which will then immediately redirect them back to the logout URL you set up earlier in this quickstart.
+
+```csharp
+await client.LogoutAsync();
+```
+
+::::checkpoint
+
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* your Android or iOS application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings
+* you are no longer logged in to your application
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* you configured the correct Logout URL
+* you called `LogoutAsync` as expected.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show User Profile Information
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 SDK for Android and iOS provides user information through the `LoginResult.User` property.
+
+```csharp
+if (loginResult.IsError == false)
+{
+    var user = loginResult.User;
+    var name = user.FindFirst(c => c.Type == "name")?.Value;
+    var email = user.FindFirst(c => c.Type == "email")?.Value;
+    var picture = user.FindFirst(c => c.Type == "picture")?.Value;
+}
+```
diff --git a/ja-jp/articles/quickstart/native/react-native-expo/00-login.md b/ja-jp/articles/quickstart/native/react-native-expo/00-login.md
new file mode 100644
index 0000000000..fcd7798b09
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/react-native-expo/00-login.md
@@ -0,0 +1,221 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an Expo application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - react-native
+  - expo
+github:
+  path: 00-Login-Expo
+contentType: tutorial
+useCase: quickstart
+---
+
+
+This Quickstart is for the Expo framework. To integrate Auth0 into your React Native application, please refer to the [React Native Quickstart](https://auth0.com/docs/quickstart/native/react-native/interactive)
+
+::: warning
+This SDK is not compatible with "Expo Go" app. It is compatible only with Custom Dev Client and EAS builds
+:::
+
+<%= include('../_includes/_getting_started', { library: 'Expo'}) %>
+
+## Install Dependencies
+
+How to install the React Native Auth0 module.
+
+::: note
+Please refer to the [official documentation](https://docs.expo.dev/) for additional details on Expo.
+:::
+
+### Yarn
+
+```bash
+yarn add react-native-auth0
+```
+
+::: note
+For further reference on yarn, check [their official documentation](https://yarnpkg.com/en/docs).
+:::
+
+### npm
+
+```bash
+npm install react-native-auth0 --save
+```
+
+The first step in adding authentication to your application is to provide a way for your users to log in. The fastest, most secure, and most feature-rich way to do this with Auth0 is to use the hosted [login page](/hosted-pages/login).
+
+
    Universal Login
    
+
+## Integrate Auth0 in Your Application
+
+### Setup Auth0 Config Plugin
+
+The Auth0 package runs custom native code that needs to be configured at build time. We will use [Expo Config Plugin](https://docs.expo.dev/guides/config-plugins/) to achieve this.
+
+Add the `react-native-auth0` plugin to the [Expo config](https://docs.expo.dev/workflow/configuration/) file at `app.json` or `app.config.js`.
+
+```json
+{
+  "expo": {
+    ...
+    "plugins": [
+      [
+        "react-native-auth0",
+        {
+          "domain": "${account.namespace}"
+        }
+      ]
+    ]
+  }
+}
+```
+
+### Generate native source code
+
+You must generate the native code for the above configuration to be set. To do this, run the following command:
+
+```bash
+expo prebuild
+```
+
+You will be prompted to provide the [Android package](https://github.com/expo/fyi/blob/main/android-package.md) and [iOS bundle identifier](https://github.com/expo/fyi/blob/main/bundle-identifier.md) if they are not already present in the Expo config:
+
+```bash
+? What would you like your Android package name to be? > com.auth0samples # or your desired package name
+
+? What would you like your iOS bundle identifier to be? > com.auth0samples # or your desired bundle identifier
+```
+
+These values are found in the Expo config file at `app.json` or `app.config.js`. It will be used in the callback and logout URLs:
+
+```json
+{
+    ...
+    "android": {
+      "package": "YOUR_ANDROID_PACKAGE_NAME_IS_FOUND_HERE"
+    },
+    "ios": {
+      "bundleIdentifier": "YOUR_IOS_BUNDLE_IDENTIFIER_IS_FOUND_HERE"
+    }
+  }
+}
+```
+
+### Configure Callback and Logout URLs
+
+The callback and logout URLs are the URLs that Auth0 invokes to redirect back to your application. Auth0 invokes the callback URL after authenticating the user, and the logout URL after removing the session cookie.
+
+If the callback and logout URLs are not set, users will be unable to log in and out of the application and will get an error.
+
+Go to the settings page of your [Auth0 application](${manage_url}/#/applications/${account.clientId}/settings) and add the corresponding URL to **Allowed Callback URLs** and **Allowed Logout URLs**, according to the platform of your application. If you are using a [custom domain](/customize/custom-domains), use the value of your custom domain instead of the Auth0 domain from the settings page.
+
+#### iOS
+```text
+BUNDLE_IDENTIFIER.auth0://${account.namespace}/ios/BUNDLE_IDENTIFIER/callback
+```
+#### Android
+```text
+PACKAGE_NAME.auth0://${account.namespace}/android/PACKAGE_NAME/callback
+```
+
+::: note
+If you are following along with our sample project, set this
+- for iOS - `com.auth0samples.auth0://${account.namespace}/ios/com.auth0samples/callback`
+- for Android - `com.auth0samples.auth0://${account.namespace}/android/com.auth0samples/callback`
+:::
+
+## Add login to your app
+
+First, import the `useAuth0` hook and the `Auth0Provider` component from the `react-native-auth0` package.
+
+```js
+import {useAuth0, Auth0Provider} from 'react-native-auth0';
+```
+
+Next, wrap your application in the `Auth0Provider` component, providing your Auth0 domain and Client ID values:
+
+```js
+const App = () => {
+  return (
+    
+      {/* your application */}
+    
+  );
+};
+```
+
+Finally, present the hosted login screen using the `authorize` method from the `useAuth0` hook. See this usage example showing logging in on a button click:
+
+```js
+const LoginButton = () => {
+    const {authorize} = useAuth0();
+
+    const onPress = async () => {
+        try {
+            await authorize();
+        } catch (e) {
+            console.log(e);
+        }
+    };
+
+    return ',
+  standalone: true
+})
+export class AuthButtonComponent {
+  // Inject the authentication service into your component through the constructor
+  constructor(public auth: AuthService) {}
+}
+```
+
+:::panel Checkpoint
+Add the `AuthButtonComponent` component to your application. When you click it, verify that your Angular application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects back to your application's homepage.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application
+
+Now that you can log in to your Angular application, you need [a way to log out](/logout/guides/logout-auth0). You can create a logout button using the `logout()` method from the `AuthService` service. Executing `logout()` redirects your users to your [Auth0 logout endpoint](/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them to your application.
+
+Here is a modified version of the `AuthButtonComponent` component above that uses both `loginWithRedirect()` and `logout()`, as well as checking the authentication state using the `isAuthenticated$` observable:
+
+```javascript
+import { Component, Inject } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { DOCUMENT } from '@angular/common';
+
+@Component({
+  selector: 'app-auth-button',
+  template: `
+    
+      
+    
+
+    
+      
+    
+  `,
+  standalone: true
+})
+export class AuthButtonComponent {
+  constructor(@Inject(DOCUMENT) public document: Document, public auth: AuthService) {}
+}
+```
+
+Specify the `returnTo` option when calling `logout` to tell Auth0 where it should redirect to after a successful logout. This value must be specified in [the **Allowed Logout URLs** setting](#configure-logout-urls) in the dashboard.
+
+:::note
+Here we use `http://localhost:4200` as the value for `logoutParams.returnTo`, but the associate sample uses `window.location.origin`, which in this case would resolve to the same value. Ultimately, this value should point to the root URL for your application.
+:::
+
+:::panel Checkpoint
+Add a button to the component template that logs the user out of your application. When you click it, verify that your Angular application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 Angular SDK helps you retrieve the [profile information](/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user$` observable exposed by the `AuthService` service. Take this `Profile` component as an example of how to use it:
+
+```javascript
+import { Component } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-user-profile',
+  template: `
+    
      
+      
    • {{ user.name }}
      • 
+      
    • {{ user.email }}
      • 
+    
    `,
+  standalone: true
+})
+export class UserProfileComponent {
+  constructor(public auth: AuthService) {}
+}
+```
+
+The `user$` observable contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. Fortunately, the `user$` observable is configured so that it only starts to emit values once the `isAuthenticated$` observable is true, so there is no need to manually check the authentication state before accessing the user profile data.
+
+:::panel Checkpoint
+Verify that you can display the `user.name` or [any other `user` property](/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/02-calling-an-api.md b/ja-jp/articles/quickstart/spa/angular/02-calling-an-api.md
new file mode 100644
index 0000000000..0bff352ad4
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/02-calling-an-api.md
@@ -0,0 +1,163 @@
+---
+title: Call an API
+description: This tutorial demonstrates how to make API calls to the Auth0 Management API.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - angular
+  - api
+github:
+  path: Standalone
+sample_download_required_data:
+  - client
+  - api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+:::note
+Visit the [Integrate Angular with an API Server](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication#integrate-angular-with-an-api-server) section of the [Angular Authentication By Example](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication) guide for a deep dive into calling a protected API from Angular. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application.
+:::
+
+<%= include('../_includes/_calling_api_preamble_api2") %>
+
+This article builds upon [the previous chapter](/quickstart/spa/angular-next), adding the capability to automatically attach an access token to outgoing requests made using Angular's built-in `HttpClient` service.
+
+:::note
+If you followed the [previous section where you added user log in to Angular](/quickstart/spa/angular-next#add-login-to-your-application), make sure that you log out of your application as you'll need a new access token to call APIs.
+:::
+
+## Provide the HTTP Interceptor
+
+To install and configure the HTTP interceptor, perform the following steps:
+
+* Import the `authHttpInterceptorFn` type from the Auth0 Angular SDK
+* Import `provideHttpClient` from `@angular/common/http`
+* Register `authHttpInterceptorFn` in `provideHttpClient` using `withInterceptors`.
+* Add configuration to specify audience, scope, and which requests should have an `Authorization` header attached automatically
+
+The following is an example of an Angular module (based upon the default implementation when you create a new app using `ng new`) that supports `AuthHttpInterceptor`, configured to call the Auth0 Management API with the ability to read the current user profile:
+
+To begin, open your `app.module.ts` file and add the necessary imports at the top:
+
+```javascript
+// Import the injector module and the HTTP client module from Angular
+import { provideHttpClient, withInterceptors } from '@angular/common/http';
+
+// Import the HTTP interceptor from the Auth0 Angular SDK
+import { authHttpInterceptorFn } from '@auth0/auth0-angular';
+```
+
+Next, add `provideHttpClient` to the `providers` of the `bootstrapApplication` function, and add `authHttpInterceptorFn` using `withInterceptors`:
+
+```javascript
+bootstrapApplication(AppComponent, {
+  providers: [
+    provideHttpClient(withInterceptors([authHttpInterceptorFn])),
+  ]
+});
+```
+
+Finally, modify the configuration given to `provideAuth0()` to specify the `audience` and `scope` values required by the API you want to call, as well as the API routes that should be intercepted by `authHttpInterceptorFn`.
+
+In this case, the audience and scope for the Auth0 Management API are given, which allows your app to retrieve information about the current user.
+
+```javascript
+provideAuth0({
+  // The domain and clientId were configured in the previous chapter
+  domain: '${account.namespace}',
+  clientId: '${account.clientId}',
+
+  authorizationParams: {
+    redirect_uri: window.location.origin,
+    
+    // Request this audience at user authentication time
+    audience: 'https://${account.namespace}/api/v2/',
+
+    // Request this scope at user authentication time
+    scope: 'read:current_user',
+  },
+
+  // Specify configuration for the interceptor              
+  httpInterceptor: {
+    allowedList: [
+      {
+        // Match any request that starts 'https://${account.namespace}/api/v2/' (note the asterisk)
+        uri: 'https://${account.namespace}/api/v2/*',
+        tokenOptions: {
+          authorizationParams: {
+            // The attached token should target this audience
+            audience: 'https://${account.namespace}/api/v2/',
+
+            // The attached token should have these scopes
+            scope: 'read:current_user'
+          }
+        }
+      }
+    ]
+  }
+})
+```
+
+:::note
+As Auth0 can only issue tokens for custom scopes that exist on your API, ensure that you define the scopes used above when [setting up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0.
+:::
+
+Please [refer to the docs](https://github.com/auth0/auth0-angular/blob/main/EXAMPLES.md#configure-authhttpinterceptor-to-attach-access-tokens) for more information on the available options for the HTTP interceptor.
+
+## Make an API Call
+
+With your app module configured with the HTTP interceptor from the Angular SDK, calls you make using Angular's built-in `HttpClient` to the Auth0 Management API will have the appropriate access token specified in the `Authorization` header. Let's use this as an example for showing user metadata.
+
+The following component demonstrates how to display the `user_metadata` field from the authenticated user's profile, by making a call to the `/api/v2/users` endpoint using `HttpClient`:
+
+```js
+import { Component, OnInit } from '@angular/core';
+import { concatMap, tap, map } from 'rxjs/operators';
+
+// Import the HttpClient for making API requests
+import { HttpClient } from '@angular/common/http';
+
+// Import AuthService from the Auth0 Angular SDK to get access to the user
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-metadata',
+  template: `
    
+    
    {{ metadata | json }}
    
+  
    `,
+  standalone: true,
+})
+export class UserMetadataComponent implements OnInit {
+  metadata = {};
+
+  // Inject both AuthService and HttpClient
+  constructor(public auth: AuthService, private http: HttpClient) {}
+
+  ngOnInit(): void {
+    this.auth.user$
+    .pipe(
+      concatMap((user) =>
+        // Use HttpClient to make the call
+        this.http.get(
+          encodeURI(`https://${account.namespace}/api/v2/users/<%= "${user?.sub}" %>`)
+        )
+      ),
+      map((user: any) => user.user_metadata),
+      tap((meta) => (this.metadata = meta))
+    )
+    .subscribe();
+  }
+}
+```
+
+This call succeeds because the HTTP interceptor took care of making sure the correct access token was included in the outgoing request.
+
+:::panel Checkpoint
+Your application will show an empty JSON object if you have not set any `user_metadata` for the logged-in user. To further test out this integration, head to the [Users section of the Auth0 dashboard](https://manage.auth0.com/#/users) and click on the user who is logged in. Update the `user_metadata` section with a value like `{ "theme": "dark" }` and click "Save". Refresh your Angular application and verify that it reflects the new `user_metadata`. 
+:::
+
+Please refer to the [Auth0 API quickstarts](https://auth0.com/docs/quickstart/backend) to learn how to integrate Auth0 with your backend platform.
diff --git a/ja-jp/articles/quickstart/spa/angular/download.md b/ja-jp/articles/quickstart/spa/angular/download.md
new file mode 100644
index 0000000000..6780e018b5
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/download.md
@@ -0,0 +1,29 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:4200
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:4200
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:4200
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm start
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/files/index.md b/ja-jp/articles/quickstart/spa/angular/files/index.md
new file mode 100644
index 0000000000..da47c6b504
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/index.md
@@ -0,0 +1,22 @@
+---
+name: main.ts
+language: javascript
+---
+
+```javascript
+import { bootstrapApplication } from '@angular/platform-browser';
+import { provideAuth0 } from '@auth0/auth0-angular';
+import { AppComponent } from './app.component';
+
+bootstrapApplication(AppComponent, {
+  providers: [
+    provideAuth0({
+      domain: '${account.namespace}',
+      clientId: '${account.clientId}',
+      authorizationParams: {
+        redirect_uri: window.location.origin
+      }
+    }),
+  ]
+});
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/files/login.md b/ja-jp/articles/quickstart/spa/angular/files/login.md
new file mode 100644
index 0000000000..d5c245b6dc
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/login.md
@@ -0,0 +1,22 @@
+---
+name: login-button.ts
+language: javascript
+---
+
+```javascript
+import { Component } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-login-button',
+  template: '',
+  standalone: true
+})
+export class LoginButtonComponent {
+  constructor(private auth: AuthService) {}
+
+  login() {
+    this.auth.loginWithRedirect();
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/files/logout.md b/ja-jp/articles/quickstart/spa/angular/files/logout.md
new file mode 100644
index 0000000000..126448a5e0
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/logout.md
@@ -0,0 +1,34 @@
+---
+name: logout-button.ts
+language: javascript
+---
+
+```javascript
+import { Component, Inject } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+import { DOCUMENT } from '@angular/common';
+
+@Component({
+  selector: 'app-logout-button',
+  template: `
+    
+  `,
+  standalone: true
+})
+export class LogoutButtonComponent {
+  constructor(
+    @Inject(DOCUMENT) public document: Document,
+    private auth: AuthService
+  ) {}
+
+  logout() {
+    this.auth.logout({ 
+      logoutParams: {
+        returnTo: this.document.location.origin 
+      }
+    });
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/files/profile.md b/ja-jp/articles/quickstart/spa/angular/files/profile.md
new file mode 100644
index 0000000000..562ec1280b
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/files/profile.md
@@ -0,0 +1,22 @@
+---
+name: user-profile.ts
+language: javascript
+---
+
+```javascript
+import { Component } from '@angular/core';
+import { AuthService } from '@auth0/auth0-angular';
+
+@Component({
+  selector: 'app-user-profile',
+  template: `
+    
      
+      
    • {{ user.name }}
      • 
+      
    • {{ user.email }}
      • 
+    
    `,
+  standalone: true
+})
+export class UserProfileComponent {
+  constructor(public auth: AuthService) {}
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/angular/index.yml b/ja-jp/articles/quickstart/spa/angular/index.yml
new file mode 100644
index 0000000000..69ed119319
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/index.yml
@@ -0,0 +1,57 @@
+title: Angular
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/angular.png
+logo: angular
+author:
+  name: Steve Hobbs 
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - angular
+logo_name: angular2
+language:
+  - Javascript
+framework:
+  - Angular
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-angular
+  url: https://github.com/auth0/auth0-angular
+  logo: angular
+snippets:
+  dependencies: application-platforms/angular2/dependencies
+  setup: application-platforms/angular2/setup
+  use: application-platforms/angular2/use
+seo_alias: angular
+default_article: 01-login
+articles:
+  - 01-login
+  - 02-calling-an-api
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-angular-samples
+  branch: main
+requirements:
+  - Angular 12+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/spa/angular/interactive.md b/ja-jp/articles/quickstart/spa/angular/interactive.md
new file mode 100644
index 0000000000..7514393223
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/angular/interactive.md
@@ -0,0 +1,160 @@
+---
+title: Add Login to your Angular Application
+description: "Auth0 allows you to add authentication to your Angular application and gain access to user profile information. This guide demonstrates common snippets used to integrate Auth0 with any new or existing Angular application using the Auth0 Angular SDK."
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+github:
+  path: Sample-01
+---
+
+:::note
+Visit the [Angular Authentication By Example](https://developer.auth0.com/resources/guides/spa/angular/basic-authentication) guide for a deep dive into implementing user authentication in Angular. This guide provides additional details on how to create a sign-up button, add route guards, and call a protected API from Angular.
+:::
+
+# Add Login to Your Angular Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Angular application using the [Auth0 Angular SDK](https://github.com/auth0/auth0-angular).
+
+To use this quickstart, you’ll need to:
+
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working Angular project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:4200',
+  returnTo: 'http://localhost:4200',
+  webOriginUrl: 'http://localhost:4200',
+  showWebOriginInfo: true
+}) %>
+
+## Install the Auth0 Angular SDK
+
+Auth0 provides an [Angular SDK](https://github.com/auth0/auth0-angular) to simplify the process of implementing Auth0 authentication and authorization in Angular applications.
+
+Install the Auth0 Angular SDK by running the following command in your terminal:
+
+```bash
+npm install @auth0/auth0-angular
+```
+
+The SDK exposes several types that help integrate Auth0 in an Angular application idiomatically, including a module and an authentication service.
+
+## Register and providing Auth0 {{{ data-action="code" data-code="main.ts#7:13" }}}
+
+The SDK exports `provideAuth0`, which is a provide function that contains all the services required for the SDK to function. To register this with your application:
+
+1. Open the `main.ts` file.
+2. Import the `provideAuth0` function from the `@auth0/auth0-angular` package.
+3. Add `provideAuth0` to the application by adding it to the `providers` inside `bootstrapApplication`.
+4. Inject `AuthService` into `AppComponent`.
+
+The `provideAuth0` function takes the properties `domain` and `clientId`; the values of these properties correspond to the **Domain** and **Client ID** values that you can find under **Settings** in the Single-Page Application (SPA) that you registered with Auth0. On top of that, we configure `authorizationParams.redirect_uri`, which allows Auth0 to redirect the user back to the specific URL after successfully authenticating.
+
+<%= include('../_includes/_auth_note_custom_domains') %>
+
+## Add login to your application {{{ data-action=code data-code="login-button.ts#11:13" }}}
+
+Now that you have configured your Auth0 Application and the Auth0 Angular SDK, you need to set up login for your project. To do this, you will use the SDK’s `loginWithRedirect()` method from the `AuthService` class to redirect users to the Auth0 Universal Login page where Auth0 can authenticate them. After a user successfully authenticates, they will be redirected to your application and the callback URL you set up earlier in this quickstart.
+
+Create a login button in your application that calls `loginWithRedirect()` when selected.
+
+::::checkpoint
+
+:::checkpoint-default
+You should now be able to log in to your application.
+
+Run your application, and select the login button. Verify that:
+
+- you can log in or sign up using a username and password.
+- your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page.
+- you are redirected to Auth0 for authentication.
+- Auth0 successfully redirects back to your application after authentication.
+- you do not receive any errors in the console related to Auth0.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure you configured the correct `authorizationParams.redirect_uri`
+- make sure you added the `LoginButtonComponent` button to the module's declarations
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout-button.ts#19:25" }}}
+
+Users who log in to your project will also need [a way to log out](/logout/guides/logout-auth0). The SDK provides a `logout()` method on the `AuthService` class that you can use to log a user out of your app. When users log out, they will be redirected to your [Auth0 logout endpoint](/api/authentication?javascript#logout), which will then immediately redirect them to your application and the logout URL you set up earlier in this quickstart.
+
+Create a logout button in your application that calls `logout()` when selected.
+
+:::note
+The SDK exposes an `isAuthenticated$` observable on the `AuthService` class that allows you to check whether a user is authenticated or not. You can render the login and logout buttons conditionally based on the value of the `isAuthenticated$` observable. Alternatively, you can use a single button to combine both login and logout buttons as well as their conditional rendering.
+:::
+
+::::checkpoint
+
+:::checkpoint-default
+You should now be able to log out of your application.
+
+Run your application, log in, and select the logout button. Verify that:
+
+- you are redirected to Auth0's logout endpoint.
+- Auth0 successfully redirects back to your application and the correct logout URL.
+- you are no longer logged in to your application.
+- you do not receive any errors in the console related to Auth0.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure that you configured the logout URL as one of the **Allowed Logout URLS** in your application's **Settings**
+- check that you added the `LogoutButtonComponent` to the module's declarations 
+- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+
+:::
+
+::::
+
+## Show user profile information {{{ data-action=code data-code="user-profile.ts" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to personalize the user interface by displaying a logged-in user’s name or profile picture.
+
+The Auth0 Angular SDK provides user information through the `user$` observable exposed by the `AuthService` class. Because the `user$` observable contains sensitive information and artifacts related to the user's identity, its availability depends on the user's authentication status. Fortunately, the `user$` observable is configured to only emit values once the `isAuthenticated$` observable is true, so there is no need to manually check the authentication state before accessing the user profile data.
+
+The SDK also exposes an `isAuthenticated$` observable on the `AuthService` class that allows you to check whether a user is authenticated or not, which you can use to determine whether to show or hide UI elements, for example.
+
+Review the `UserProfileComponent` code in the interactive panel to see examples of how to use these functions.
+
+::::checkpoint
+
+:::checkpoint-default
+You should now be able to view user profile information.
+
+Run your application, and verify that:
+
+- user information displays correctly after you have logged in.
+- user information does not display after you have logged out.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure you are logged in
+- make sure you are trying to access an existing property such as `user.name`
+- make sure you added the `UserProfileComponent` component to the correct module's declarations
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/spa/config.yml b/ja-jp/articles/quickstart/spa/config.yml
new file mode 100644
index 0000000000..51f64e8751
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - client
diff --git a/ja-jp/articles/quickstart/spa/flutter/01-login.md b/ja-jp/articles/quickstart/spa/flutter/01-login.md
new file mode 100644
index 0000000000..a68d11d9fe
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/01-login.md
@@ -0,0 +1,184 @@
+---
+title: Add login to your Flutter app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Flutter Web application using the Auth0 Flutter SDK
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - flutter
+  - dart
+  - ios
+  - android
+contentType: tutorial
+useCase: quickstart
+github:
+  path: sample
+---
+
+
+
+# Add login to your Flutter app
+
+Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with a Flutter Web application using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter).
+
+:::note
+The Flutter SDK currently only supports Flutter applications running on Android, iOS, or Web platforms.
+:::
+
+## Getting started
+
+This quickstart assumes you already have a [Flutter](https://flutter.dev/) application up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app.
+
+You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli).
+
+<%= include('../_includes/_getting_started', { library: 'Flutter', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %>
+
+<%= include('_install_sdk') %>
+
+## Add login to your app
+
+[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security, and the fullest array of features.
+
+Integrate Auth0 Universal Login in your Flutter app by importing the SDK and instantiating the `Auth0` class using your Auth0 domain and Client ID values. See this example, which instantiates the class inside a widget state object:
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:auth0_flutter/auth0_flutter_web.dart';
+
+class MainView extends StatefulWidget {
+  const MainView({Key? key}) : super(key: key);
+
+  @override
+  State createState() => _MainViewState();
+}
+
+class _MainViewState extends State {
+  Credentials? _credentials;
+
+  late Auth0Web auth0;
+
+  @override
+  void initState() {
+    super.initState();
+    auth0 = Auth0Web('${account.namespace}', '${account.clientId}');
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    // ...
+  }
+}
+```
+
+Next, redirect your users to the Auth0 Universal Login page using `loginWithRedirect`. See this example of a `ElevatedButton` widget that logs the user in when clicked:
+
+:::note
+You will normally need to specify the `redirectUrl` parameter to `loginWithRedirect`. Omitting this will cause Auth0 to use the [default login route](https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes), which is not configured by default.
+:::
+
+```dart
+if (_credentials == null) {
+  ElevatedButton(
+    onPressed: () => auth0.loginWithRedirect(redirectUrl: 'http://localhost:3000'),
+    child: const Text("Log in")
+  )
+}
+```
+
+When a user logs in, they are redirected back to your application. You are then able to access the ID and access tokens for this user by calling `onLoad` during startup and handling the credentials that are given to you:
+
+```dart
+auth0.onLoad().then((final credentials) => setState(() {
+    // Handle or store credentials here
+    _credentials = credentials;
+  }));
+```
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `loginWithRedirect()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your application.
+
+Verify that you can access `credentials` as a result of calling `onLoad` and that you're able to access the ID and access tokens.
+:::
+
+:::checkpoint-failure
+If your application did not launch successfully:
+
+- Ensure the Allowed Callback URLs are set properly
+- Verify you saved your changes after entering your URLs
+- Make sure the domain and client ID values are imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your app
+
+To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout).
+
+See this example of an `ElevatedButton` widget that logs the user out of the app:
+
+```dart
+ElevatedButton(
+  onPressed: () async {
+    await auth0.logout();
+  },
+  child: const Text("Log out"))
+```
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `logout()` and logs the user out of your application. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your application.
+:::
+
+:::checkpoint-failure
+If your application did not log out successfully:
+
+- Ensure the Allowed Logout URLs are set properly
+- Verify you saved your changes after entering your URLs
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information
+
+The user profile automatically retrieves user profile properties for you when the page loads, and can be accessed and stored by calling `onLoad` during application startup. The returned object from `onLoad` contains a `user` property with all the user profile properties. This is internally populated by decoding the ID token.
+
+See this example of a `View` component that displays the user profile on the screen:
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:flutter/material.dart';
+
+class ProfileView extends StatelessWidget {
+  const ProfileView({Key? key, required this.user}) : super(key: key);
+
+  final UserProfile user;
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (user.name != null) Text(user.name!),
+        if (user.email != null) Text(user.email!)
+      ],
+    );
+  }
+}
+```
+
+::::checkpoint
+:::checkpoint-default
+Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`.
+:::
+:::checkpoint-failure
+If your application did not return user profile information:
+
+- Verify the ID token is valid
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/spa/flutter/_install_sdk.md b/ja-jp/articles/quickstart/spa/flutter/_install_sdk.md
new file mode 100644
index 0000000000..63b1fb626d
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/_install_sdk.md
@@ -0,0 +1,15 @@
+
+
+## Install the Auth0 Flutter SDK
+
+Add the Auth0 Flutter SDK into the project:
+
+```shell
+flutter pub add auth0_flutter
+```
+
+Add the following script tag to your `index.html` page:
+
+```html
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/flutter/download.md b/ja-jp/articles/quickstart/spa/flutter/download.md
new file mode 100644
index 0000000000..7e0790884d
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/download.md
@@ -0,0 +1,33 @@
+
+
+To run the sample follow these steps:
+
+1. Set the **Allowed Callback URLs** and **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to the following value so it works for both Android and iOS apps:
+
+```text
+com.auth0.samples.FlutterSample://${account.namespace}/ios/com.auth0.samples.FlutterSample/callback,com.auth0.sample://${account.namespace}/android/com.auth0.sample/callback
+```
+
+2. Rename the file `.env.example` to `.env` and fill in the following values:
+
+```sh
+AUTH0_DOMAIN=${account.namespace}
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CUSTOM_SCHEME=com.auth0.sample
+```
+
+3. Rename the file `strings.xml.example` in `android/app/src/main/res/values` to `strings.xml` and fill in the following values:
+
+```xml
+
+
+    ${account.namespace}
+    com.auth0.sample
+
+```
+
+4. Use the [Flutter CLI's](https://docs.flutter.dev/reference/flutter-cli) `run` command to run the app:
+
+```sh
+flutter run
+```
diff --git a/ja-jp/articles/quickstart/spa/flutter/files/main.md b/ja-jp/articles/quickstart/spa/flutter/files/main.md
new file mode 100644
index 0000000000..a1241cf2bf
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/files/main.md
@@ -0,0 +1,59 @@
+---
+name: main_view.dart
+language: dart
+---
+
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:auth0_flutter/auth0_flutter_web.dart';
+import 'package:flutter/material.dart';
+import 'profile_view.dart';
+
+class MainView extends StatefulWidget {
+  const MainView({Key? key}) : super(key: key);
+
+  @override
+  State createState() => _MainViewState();
+}
+
+class _MainViewState extends State {
+  Credentials? _credentials;
+
+  late Auth0Web auth0;
+
+  @override
+  void initState() {
+    super.initState();
+    auth0 = Auth0Web('${account.namespace}', '${account.clientId}');
+
+    auth0.onLoad().then((final credentials) => setState(() {
+        _credentials = credentials;
+      }));
+  }
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (_credentials == null)
+          ElevatedButton(
+              onPressed: () => auth0.loginWithRedirect(redirectUrl: 'http://localhost:3000'),
+              child: const Text("Log in"))
+        else
+          Column(
+            children: [
+              ProfileView(user: _credentials!.user),
+              ElevatedButton(
+                  onPressed: () async {
+                    await auth0.logout(returnToUrl: 'http://localhost:3000');
+                  },
+                  child: const Text("Log out"))
+            ],
+          )
+      ],
+    );
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/spa/flutter/files/profile.md b/ja-jp/articles/quickstart/spa/flutter/files/profile.md
new file mode 100644
index 0000000000..16d93d8620
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/files/profile.md
@@ -0,0 +1,27 @@
+---
+name: profile_view.dart
+language: dart
+---
+
+
+```dart
+import 'package:auth0_flutter/auth0_flutter.dart';
+import 'package:flutter/material.dart';
+
+class ProfileView extends StatelessWidget {
+  const ProfileView({Key? key, required this.user}) : super(key: key);
+
+  final UserProfile user;
+
+  @override
+  Widget build(BuildContext context) {
+    return Column(
+      mainAxisAlignment: MainAxisAlignment.center,
+      children: [
+        if (user.name != null) Text(user.name!),
+        if (user.email != null) Text(user.email!)
+      ],
+    );
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/spa/flutter/index.yml b/ja-jp/articles/quickstart/spa/flutter/index.yml
new file mode 100644
index 0000000000..0b5b439218
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/index.yml
@@ -0,0 +1,52 @@
+title: Flutter (Web)
+logo_name: flutter
+logo: flutter
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+alias:
+  - flutter
+language:
+  - Dart
+framework:
+  - Flutter
+sdk:
+  name: auth0-flutter
+  url: https://www.github.com/auth0/auth0-flutter/
+  logo: flutter
+hybrid: true
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: flutter
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-flutter-samples
+  branch: main
+requirements:
+  - Flutter 3+
+  - Xcode 14+ (for iOS)
+  - Android Studio 4+ (for Android)
+next_steps:
+  - path: interactive
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about Actions
+        icon: 345
+        href: '/customize/actions'
diff --git a/ja-jp/articles/quickstart/spa/flutter/interactive.md b/ja-jp/articles/quickstart/spa/flutter/interactive.md
new file mode 100644
index 0000000000..143ed0b85d
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/flutter/interactive.md
@@ -0,0 +1,116 @@
+---
+title: Add login to your Flutter app
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to a Flutter Web application using the Auth0 Flutter SDK
+budicon: 448
+topics:
+  - quickstarts
+  - flutter
+  - dart
+  - spa
+  - web
+  - browser
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/main
+  - files/profile
+github:
+  path: sample
+---
+
+
+
+# Add Login to Your Flutter Application
+
+Auth0 allows you to quickly add authentication and access user profile information in your application. This guide demonstrates how to integrate Auth0 with a Flutter application using the [Auth0 Flutter SDK](https://github.com/auth0/auth0-flutter).
+
+:::note
+The Flutter SDK currently only supports Flutter applications running on Android, iOS, or Web platforms.
+:::
+
+This quickstart assumes you already have a [Flutter](https://flutter.dev/) application up and running. If not, check out the [Flutter "getting started" guides](https://docs.flutter.dev/get-started/install) to get started with a simple app.
+
+You should also be familiar with the [Flutter command line tool](https://docs.flutter.dev/reference/flutter-cli).
+
+<%= include('../_includes/_getting_started', { library: 'Flutter', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %>
+
+<%= include('_install_sdk') %>
+
+## Add login to your application {{{ data-action="code" data-code="main_view.dart#34" }}}
+
+[Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security, and the fullest array of features.
+
+Integrate Auth0 Universal Login in your Flutter Web app by using the `Auth0Web` class. Redirect your users to the Auth0 Universal Login page using `loginWithRedirect()`.
+
+:::note
+You will normally need to specify the `redirectUrl` parameter to `loginWithRedirect`. Omitting this will cause Auth0 to use the [default login route](https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes), which is not configured by default.
+:::
+
+When a user logs in, they are redirected back to your application. You are then able to access the ID and access tokens for this user by calling `onLoad` during startup and handling the credentials that are given to you:
+
+```dart
+auth0.onLoad().then((final credentials) => setState(() {
+    // Handle or store credentials here
+    _credentials = credentials;
+  }));
+```
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `loginWithRedirect()` and logs the user into your app. Verify that you are redirected to Auth0 for authentication and then back to your application.
+
+Verify that you can access `credentials` as a result of calling `onLoad` and that you're able to access the ID and access tokens.
+:::
+
+:::checkpoint-failure
+If your application did not launch successfully:
+
+- Ensure the Allowed Callback URLs are set properly
+- Verify you saved your changes after entering your URLs
+- Make sure the domain and client ID values are imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="main_view.dart#46"}}}
+
+To log users out, redirect them to the Auth0 logout endpoint to clear their login session by calling the Auth0 Flutter SDK `logout()`. [Read more about logging out of Auth0](https://auth0.com/docs/authenticate/login/logout).
+
+:::note
+You will normally want to specify `returnToUrl` when calling `logout`, otherwise Auth0 [will default to the first URL in the Allowed Logout URLs list](https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout).
+:::
+
+::::checkpoint
+:::checkpoint-default
+Add a button to your app that calls `logout()` and logs the user out of your application. When you select it, verify that your Flutter app redirects you to the logout endpoint and back again. You should not be logged in to your application.
+:::
+
+:::checkpoint-failure
+If your application did not log out successfully:
+
+- Ensure the Allowed Logout URLs are set properly
+- Verify you saved your changes after entering your URLs
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information {{{ data-action="code" data-code="profile_view.dart" }}}
+
+The user profile automatically retrieves user profile properties for you when the page loads, and can be accessed and stored by calling `onLoad` during application startup. The returned object from `onLoad` contains a `user` property with all the user profile properties. This is internally populated by decoding the ID token.
+
+::::checkpoint
+:::checkpoint-default
+Log in and inspect the `user` property on the result. Verify the current user's profile information, such as `email` or `name`.
+:::
+:::checkpoint-failure
+If your application did not return user profile information:
+
+- Verify the ID token is valid
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/spa/react/01-login.md b/ja-jp/articles/quickstart/spa/react/01-login.md
new file mode 100644
index 0000000000..5f432df0b2
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/01-login.md
@@ -0,0 +1,152 @@
+---
+title: Login
+description: "Auth0 allows you to add authentication to your React application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing React application using the Auth0 React SDK."
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - react
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+---
+
+
+:::note
+Visit the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into implementing user authentication in React. This guide provides additional details on how to create a sign-up button and add route guards using React Router.
+:::
+
+<%= include('../_includes/_getting_started', { library: 'React', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %>
+
+<%= include('../../_includes/_auth0-react-install.md') %>
+
+### Configure the `Auth0Provider` component
+
+Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK.
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+
+    
+  ,
+);
+```
+
+The `Auth0Provider` component takes the following props:
+
+- `domain` and `clientId`: The values of these properties correspond to the "Domain" and "Client ID" values present under the "Settings" of the single-page application that you registered with Auth0.
+
+<%= include('../_includes/_auth_note_custom_domains') %>
+
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+`Auth0Provider` stores the authentication state of your users and the state of the SDK — whether Auth0 is ready to use or not. It also exposes helper methods to log in and log out your users, which you can access using the `useAuth0()` hook.
+
+:::panel Checkpoint
+Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+The Auth0 React SDK gives you tools to quickly implement user authentication in your React application, such as creating a [login](https://auth0.com/docs/login) button using the `loginWithRedirect()` method from the `useAuth0()` hook. Executing `loginWithRedirect()` redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application.
+
+```javascript
+import React from "react";
+import { useAuth0 } from "@auth0/auth0-react";
+
+const LoginButton = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  return ;
+};
+
+export default LoginButton;
+```
+
+<%= include('../../_includes/_auth0-react-classes-info.md') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application. When you click it, verify that your React application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` that you used to configure the `Auth0Provider`.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application
+
+Now that you can log in to your React application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). You can create a logout button using the `logout()` method from the `useAuth0()` hook. Executing `logout()` redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them to your application.
+
+```javascript
+import React from "react";
+import { useAuth0 } from "@auth0/auth0-react";
+
+const LogoutButton = () => {
+  const { logout } = useAuth0();
+
+  return (
+    
+  );
+};
+
+export default LogoutButton;
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your React application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it:
+
+```javascript
+import React from "react";
+import { useAuth0 } from "@auth0/auth0-react";
+
+const Profile = () => {
+  const { user, isAuthenticated, isLoading } = useAuth0();
+
+  if (isLoading) {
+    return 
    Loading ...
    ;
+  }
+
+  return (
+    isAuthenticated && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+      
    
+    )
+  );
+};
+
+export default Profile;
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::                                              
+
diff --git a/ja-jp/articles/quickstart/spa/react/02-calling-an-api.md b/ja-jp/articles/quickstart/spa/react/02-calling-an-api.md
new file mode 100644
index 0000000000..fc7b231bc0
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/02-calling-an-api.md
@@ -0,0 +1,165 @@
+---
+title: Call an API
+description: This tutorial demonstrates how to make API calls to the Auth0 Management API.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - react
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+sample_download_required_data:
+  - client
+  - api
+useCase: quickstart
+---
+
+
+:::note
+Visit the [Integrate React with an API Server](https://developer.auth0.com/resources/guides/spa/react/basic-authentication#integrate-react-with-an-api-server) section of the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into calling a protected API from React. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application.
+:::
+
+<%= include('../_includes/_calling_api_preamble_api2") %>
+
+:::note
+If you followed the [previous section where you added user log in to React](/quickstart/spa/auth0-react#add-login-to-your-application), make sure that you log out of your application as you'll need a new access token to call APIs.
+:::
+
+## Set Up the Auth0 Service
+
+The `Auth0Provider` setup is similar to the one discussed in the [Configure the `Auth0Provider` component](/quickstart/spa/auth0-react#configure-the-auth0provider-component) section: you wrap your root component with `Auth0Provider` to which you pass the `domain` and `clientId` props. The values of these two props come from the ["Settings" values](https://auth0.com/docs/quickstart/spa/react#configure-auth0) of the single-page application you've registered with Auth0.
+
+However, your React application needs to pass an access token when it calls a target API to access private resources. You can [request an access token](https://auth0.com/docs/tokens/guides/get-access-tokens) in a format that the API can verify by passing the `audience` and `scope` props to `Auth0Provider` as follows:
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+  
+    
+  
+);
+```
+
+:::note
+As Auth0 can only issue tokens for custom scopes that exist on your API, ensure that you define the scopes used above when [setting up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0.
+:::
+
+Auth0 uses the value of the `authorizationParams.audience` prop to determine which resource server (API) the user is authorizing your React application to access.
+
+:::note
+In the case of the Auth0 Management API, the audience is `https://${account.namespace}/api/v2/`. In the case of your APIs, you create an _Identifier_ value that serves as the _Audience_ value whenever you [set up an API](https://auth0.com/docs/getting-started/set-up-api) with Auth0.
+:::
+
+The actions that your React application can perform on the API depend on the [scopes](https://auth0.com/docs/scopes/current) that your access token contains, which you define as the value of `authorizationParams.scope`. Your React application will request authorization from the user to access the requested scopes, and the user will approve or deny the request.
+
+:::note
+In the case of the Auth0 Management API, the `read:current_user` and `update:current_user_metadata` scopes let you get an access token that can retrieve user details and update the user's information. In the case of your APIs, you'll define custom [API scopes](https://auth0.com/docs/scopes/current/api-scopes) to implement access control, and you'll identify them in the calls that your client applications make to that API.
+:::
+
+## Get an Access Token 
+
+Once you configure `Auth0Provider`, you can easily get the access token using the [`getAccessTokenSilently()`](https://auth0.github.io/auth0-react/interfaces/Auth0ContextInterface.html#getAccessTokenSilently) method from the [`useAuth0()`](https://auth0.github.io/auth0-react/functions/useAuth0.html) custom React Hook wherever you need it. 
+
+Take this `Profile` component as an example:
+
+```javascript
+import React, { useEffect, useState } from "react";
+import { useAuth0 } from "@auth0/auth0-react";
+
+const Profile = () => {
+  const { user, isAuthenticated, getAccessTokenSilently } = useAuth0();
+  const [userMetadata, setUserMetadata] = useState(null);
+
+  return (
+    isAuthenticated && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+        
    User Metadata
    
+        {userMetadata ? (
+          
    {JSON.stringify(userMetadata, null, 2)}
    
+        ) : (
+          "No user metadata defined"
+        )}
+      
    
+    )
+  );
+};
+
+export default Profile;
+```
+
+As it is, `userMetadata` is always `null` in the `Profile` component. Add the following `useEffect()` hook to the component to fetch the user metadata from an API:
+
+```javascript
+useEffect(() => {
+  const getUserMetadata = async () => {
+    const domain = "${account.namespace}";
+
+    try {
+      const accessToken = await getAccessTokenSilently({
+        authorizationParams: {
+          audience: `https://<%= "${domain}" %>/api/v2/`,
+          scope: "read:current_user",
+        },
+      });
+
+      const userDetailsByIdUrl = `https://<%= "${domain}" %>/api/v2/users/<%= "${user.sub}" %>`;
+
+      const metadataResponse = await fetch(userDetailsByIdUrl, {
+        headers: {
+          Authorization: `Bearer <%= "${accessToken}" %>`,
+        },
+      });
+
+      const { user_metadata } = await metadataResponse.json();
+
+      setUserMetadata(user_metadata);
+    } catch (e) {
+      console.log(e.message);
+    }
+  };
+
+  getUserMetadata();
+}, [getAccessTokenSilently, user?.sub]);
+```
+
+You use a React Effect Hook to call an asynchronous `getUserMetadata()` function. The function first calls `getAccessTokenSilently()`, which returns a Promise that resolves to an access token that you can use to make a call to a protected API.
+
+You pass an object with the `authorizationParams.audience` and `authorizationParams.scope` properties as the argument of `getAccessTokenSilently()` to ensure that the access token you get is for the intended API and has the required permissions to access the desired endpoint.
+ 
+:::note
+In the case of the Auth0 Management API, one of the scopes that the [`/api/v2/users/{id}` endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users_by_id) requires is `read:current_user`.
+:::
+ 
+You can then include the access token in the authorization header of the API call that you make. The API will take care of validating the access token and processing the request.
+
+Upon success, you extract the `user_metadata` property from the API response and use `setUserMetadata()` to make React aware of it.
+
+:::panel Checkpoint
+Your application will show "No user metadata defined" if you have not set any `user_metadata` for the logged-in user. To further test out this integration, head to the [Users section of the Auth0 dashboard](https://manage.auth0.com/#/users) and click on the user who is logged in. Update the `user_metadata` section with a value like `{ "theme": "dark" }` and click "Save". Refresh your React application and verify that it reflects the new `user_metadata`. 
+:::
+
+:::note
+The `getAccessTokenSilently()` method can renew the access and ID token for you using [refresh tokens](https://auth0.com/docs/tokens/concepts/refresh-tokens). To [get a refresh token](https://auth0.com/docs/tokens/guides/get-refresh-tokens) when a user logs in, pass `useRefreshTokens={true}` as a prop to `Auth0Provider`. 
+:::
+
+As a final reminder, consult the [Auth0 API quickstarts](https://auth0.com/docs/quickstart/backend) to learn how to integrate Auth0 with your backend platform.
+
diff --git a/ja-jp/articles/quickstart/spa/react/download.md b/ja-jp/articles/quickstart/spa/react/download.md
new file mode 100644
index 0000000000..6f559d951d
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/download.md
@@ -0,0 +1,28 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm start
+```
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/files/app.md b/ja-jp/articles/quickstart/spa/react/files/app.md
new file mode 100644
index 0000000000..7e4b2f7e01
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/files/app.md
@@ -0,0 +1,29 @@
+---
+name: app.js
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from "@auth0/auth0-react";
+import React from "react";
+
+const Profile = () => {
+  const { user, isAuthenticated, isLoading } = useAuth0();
+
+  if (isLoading) {
+    return 
    Loading ...
    ;
+  }
+
+  return (
+    isAuthenticated && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+      
    
+    )
+  );
+};
+
+export default Profile;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/files/index.md b/ja-jp/articles/quickstart/spa/react/files/index.md
new file mode 100644
index 0000000000..e5c5e1d111
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/files/index.md
@@ -0,0 +1,25 @@
+---
+name: index.js
+language: javascript
+---
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+
+    
+  ,
+);
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/files/login.md b/ja-jp/articles/quickstart/spa/react/files/login.md
new file mode 100644
index 0000000000..f00fbd0507
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/files/login.md
@@ -0,0 +1,17 @@
+---
+name: login.js
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from "@auth0/auth0-react";
+import React from "react";
+
+const LoginButton = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  return ;
+};
+
+export default LoginButton;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/files/logout.md b/ja-jp/articles/quickstart/spa/react/files/logout.md
new file mode 100644
index 0000000000..89caeb8029
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/files/logout.md
@@ -0,0 +1,21 @@
+---
+name: logout.js
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from "@auth0/auth0-react";
+import React from "react";
+
+const LogoutButton = () => {
+  const { logout } = useAuth0();
+
+  return (
+    
+  );
+};
+
+export default LogoutButton;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/files/profile.md b/ja-jp/articles/quickstart/spa/react/files/profile.md
new file mode 100644
index 0000000000..6ae27c8bea
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/files/profile.md
@@ -0,0 +1,29 @@
+---
+name: profile.js
+language: javascript
+---
+
+```javascript
+import { useAuth0 } from "@auth0/auth0-react";
+import React from "react";
+
+const Profile = () => {
+  const { user, isAuthenticated, isLoading } = useAuth0();
+
+  if (isLoading) {
+    return 
    Loading ...
    ;
+  }
+
+  return (
+    isAuthenticated && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+      
    
+    )
+  );
+};
+
+export default Profile;
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/react/index.yml b/ja-jp/articles/quickstart/spa/react/index.yml
new file mode 100644
index 0000000000..591b6725fe
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/index.yml
@@ -0,0 +1,65 @@
+title: React
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/react.png
+logo: react
+alias:
+  - react
+  - reactjs
+language:
+  - Javascript
+author:
+  name: Dan Arias
+  email: dan.arias@auth0.com
+  community: false
+framework:
+  - React
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-react
+  url: https://www.github.com/auth0/auth0-react/
+  logo: react
+snippets:
+  dependencies: application-platforms/react/dependencies
+  setup: application-platforms/react/setup
+  use: application-platforms/react/use
+seo_alias: react
+default_article: "01-login"
+articles:
+  - "01-login"
+  - "02-calling-an-api"
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-react-samples
+  branch: master
+requirements:
+  - React 18
+next_steps:
+  - path: 01-login
+    list:
+      - text: "Part 2: Calling an API using an access token"
+        icon: 345
+        href: "/quickstart/spa/react/02-calling-an-api"
+  - path: 02-calling-an-api
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: "/identityproviders"
+      - text: Enable multifactor authentication
+        icon: 345
+        href: "/multifactor-authentication"
+      - text: Learn about attack protection
+        icon: 345
+        href: "/attack-protection"
+      - text: Learn about rules
+        icon: 345
+        href: "/rules"
+troubleshooting_steps:
+
+    
diff --git a/ja-jp/articles/quickstart/spa/react/interactive.md b/ja-jp/articles/quickstart/spa/react/interactive.md
new file mode 100644
index 0000000000..182acd7c70
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/react/interactive.md
@@ -0,0 +1,158 @@
+---
+title: Add Login to your React App
+description: "Auth0 allows you to add authentication to your React application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing React application using the Auth0 React SDK."
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+github:
+  path: Sample-01
+---
+
+:::note
+Visit the [React Authentication By Example](https://developer.auth0.com/resources/guides/spa/react/basic-authentication) guide for a deep dive into implementing user authentication in React. This guide provides additional details on how to create a sign-up button, add route guards using React Router, and call a protected API from React.
+:::
+
+# Add Login to Your React Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any React application using the Auth0 React SDK.
+
+To use this quickstart, you’ll need to:
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working React project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000',
+  returnTo: 'http://localhost:3000',
+  webOriginUrl: 'http://localhost:3000',
+  showWebOriginInfo: true
+}) %>
+
+## Install the Auth0 React SDK {{{ data-action=code data-code="index.js#13:22" }}}
+
+Auth0 provides a [React SDK](https://github.com/auth0/auth0-react) (auth0-react.js) to simplify the process of implementing Auth0 authentication and authorization in React apps.
+
+Install the Auth0 React SDK by running the following commands in your terminal:
+
+```bash
+cd 
+npm install @auth0/auth0-react
+```
+
+### Configure the Auth0Provider component
+
+For the SDK to function properly, you must set the following properties in the Auth0Provider component:
+
+- `domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- `authorizationParams.redirect_uri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. You can also find this value in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Your Auth0Provider component should now be properly configured. Run your application to verify that:
+- the SDK is initializing correctly
+- your application is not throwing any errors related to Auth0
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="login.js#4:7" }}}
+
+Now that you have configured your Auth0 Application and the Auth0 React SDK, you need to set up login for your project. To do this, you will use the SDK’s loginWithRedirect() method to create a login button that redirects users to the Auth0 Universal Login page. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+<%= include('../../_includes/_auth0-react-classes-info.md') %>
+
+Create a new file in your application called `login.js` for the login button component, and copy in the code from the interactive panel to the right, which contains the logic needed for login. Then, update your `index.js` file to include the new login button.
+
+::::checkpoint
+
+:::checkpoint-default
+
+You should now be able to log in or sign up using a username and password.
+
+Click the login button and verify that:
+* your React Application redirects you to the Auth0 Universal Login page
+* you can log in or sign up
+* Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` you used to configure the `Auth0Provider`
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* you configured the correct `authorizationParams.redirect_uri`
+* you added the Login button to the `index.js` file
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout.js#10:18" }}}
+
+Users who log in to your project will also need a way to log out. Create a logout button using the SDK’s logout() method. When users log out, they will be redirected to your [Auth0 logout](https://auth0.com/docs/api/authentication?javascript#logout) endpoint, which will then immediately redirect them to the logout URL you set up earlier in this quickstart.
+
+Create a new file in your application called `logout.js` for the logout button component, and copy in the code from the interactive panel, which contains the logic needed for logout. Then, update your `index.js` file to include the logout button.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* your React application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings
+* you are no longer logged in to your application
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* you configured the correct Logout URL
+* you added the Logout button to the `index.js` file 
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show User Profile Information {{{ data-action=code data-code="profile.js#11:26" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 React SDK provides user information through the `user` property. Review the `profile.js` code in the interactive panel to see an example of how to use it.
+
+Because the `user` property contains sensitive information related to the user's identity, its availability depends on the user's authentication status. To prevent render errors, you should always:
+- use the `isAuthenticated` property to determine whether Auth0 has authenticated the user before React renders any component that consumes the `user` property.
+- ensure that the SDK has finished loading by checking that `isLoading` is false before accessing the `isAuthenticated` property.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Verify that:
+* you can display the `user.name` or any other user property within a component correctly after you have logged in
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* you added the `isLoading` check before accessing the `isAuthenticated` property
+* you added the `Profile` component to the `index.js` file 
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/01-login.md b/ja-jp/articles/quickstart/spa/vanillajs/01-login.md
new file mode 100644
index 0000000000..dc9497c854
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/01-login.md
@@ -0,0 +1,20 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Javascript application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - vanillajs
+  - login
+github:
+    path: 01-Login
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/_getting_started', { library: 'JavaScript', callback: 'http://localhost:3000', showLogoutInfo: true, returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showWebOriginInfo: true, new_js_sdk: true }) %>
+
+<%= include('_includes/_centralized_login') %>
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/02-calling-an-api.md b/ja-jp/articles/quickstart/spa/vanillajs/02-calling-an-api.md
new file mode 100644
index 0000000000..7f4a3b9c04
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/02-calling-an-api.md
@@ -0,0 +1,271 @@
+---
+title: Calling an API
+description: This tutorial demonstrates how to make API calls for protected resources on your server.
+budicon: 546
+topics:
+  - quickstarts
+  - spa
+  - vanillajs
+  - apis
+github:
+    path: 02-Calling-an-API
+sample_download_required_data:
+  - client
+  - api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/_calling_api_preamble') %>
+
+<%= include('../_includes/_calling_api_create_api') %>
+
+## Create a Backend API
+
+In this section, you will modify the [ExpressJS](https://expressjs.com) that you created in part 1 so that it supports a new endpoint. This endpoint will require a valid access token to be sent in the `Authorization` header for the call to be successful.
+
+### Add middleware to the backend
+
+To begin, let's install an NPM package that will be used to validate incoming tokens to the server. From the terminal:
+
+```bash
+npm install express-oauth2-jwt-bearer
+```
+
+Next, open `server.js` and bring in these libraries as imports at the top of the file. Also bring in the `auth_config.json` file so that the script can get access to the authentication credentials that have been configured:
+
+```js
+// .. other imports
+
+const { auth } = require("express-oauth2-jwt-bearer");
+const authConfig = require("./auth_config.json");
+```
+
+- [`express-oauth2-jwt-bearer`](https://npmjs.com/package/express-oauth2-jwt-bearer) - validates JWTs from the `authorization` header and sets the `req.auth` object
+
+Then add a call to `auth()`, which creates the middleware needed in order to validate and parse incoming access tokens. This should go after the `require` statements but before any routes are defined in your app:
+
+```js
+// create the JWT middleware
+const checkJwt = auth({
+  audience: authConfig.audience,
+  issuerBaseURL: `https://<%= "${authConfig.domain}" %>`
+});
+```
+
+This code configures the `express-oauth2-jwt-bearer` middleware with the settings that relate to your Auth0 application.
+
+Next, open the `auth_config.json` file and modify the data so that the `audience` appears as a key within the JSON, using the value that you just used when creating the API:
+
+```json
+{
+  "domain": "${account.namespace}",
+  "clientId": "${account.clientId}",
+  "audience": "${apiIdentifier}"
+}
+```
+
+::: note
+As `auth_config.json` is served publicly, this file should **never** contain sensitive information such as passwords and client secrets.
+:::
+
+The values for `domain` and `clientId` should have already been specified as part of the [Login tutorial](/quickstarts/spa/vanillajs/01-login). They should point to the Domain and Client ID values for your Auth0 app respectively.
+
+### Add a protected endpoint
+
+The last thing to do on the server side is to add an API endpoint that requires an access token to be provided for the call to succeed. This endpoint will use the middleware that you created earlier in the tutorial to provide that protection in a scalable way.
+
+Open `server.js` and add a new route for `/api/external` above the other routes that returns some JSON:
+
+```js
+// ..
+
+app.get("/api/external", checkJwt, (req, res) => {
+  res.send({
+    msg: "Your access token was successfully validated!"
+  });
+});
+
+// ..
+```
+
+Note that `checkJwt` is used as the second argument here. This causes `checkJwt` to be executed before the main route handler, and will reject the call and return a 401 response if:
+
+- there is no access token present in the `Authorization` header,
+- or the token itself is not valid
+
+Finally, add an error handler so that a JSON response is returned from your API in the event of a missing or invalid token:
+
+```js
+// ..
+
+app.use(function(err, req, res, next) {
+  if (err.name === "UnauthorizedError") {
+    return res.status(401).send({ msg: "Invalid token" });
+  }
+
+  next(err, req, res);
+});
+
+//..
+```
+
+At the end, your `server.js` file will look something like the following:
+
+```js
+const express = require("express");
+const { auth } = require("express-oauth2-jwt-bearer");
+const { join } = require("path");
+const authConfig = require("./auth_config.json");
+
+const app = express();
+
+// Serve assets from the /public folder
+app.use(express.static(join(__dirname, "public")));
+
+// Create the JWT validation middleware
+const checkJwt = auth({
+  audience: authConfig.audience,
+  issuerBaseURL: `https://<%= "${authConfig.domain}" %>`
+});
+
+// Create an endpoint that uses the above middleware to
+// protect this route from unauthorized requests
+app.get("/api/external", checkJwt, (req, res) => {
+  res.send({
+    msg: "Your access token was successfully validated!"
+  });
+});
+
+// Serve the auth configuration file
+app.get("/auth_config.json", (req, res) => {
+  res.sendFile(join(__dirname, "auth_config.json"));
+});
+
+// Serve the index page to everything else
+app.get("/*", (req, res) => {
+  res.sendFile(join(__dirname, "index.html"));
+});
+
+// Error handler
+app.use(function(err, req, res, next) {
+  if (err.name === "UnauthorizedError") {
+    return res.status(401).send({ msg: "Invalid token" });
+  }
+
+  next(err, req, res);
+});
+
+module.exports = app;
+```
+
+### Test the API
+
+With this in place, run the application using `npm run dev`. In another terminal window, use the `curl` tool to make a request to this API endpoint and observe the results:
+
+```bash
+curl -I localhost:3000/api/external
+```
+
+You should find that a 401 Unauthorized result is returned, because it requires a valid access token:
+
+```bash
+HTTP/1.1 401 Unauthorized
+X-DNS-Prefetch-Control: off
+X-Frame-Options: SAMEORIGIN
+Strict-Transport-Security: max-age=15552000; includeSubDomains
+X-Download-Options: noopen
+X-Content-Type-Options: nosniff
+X-XSS-Protection: 1; mode=block
+Content-Security-Policy: default-src 'self'
+Content-Type: text/html; charset=utf-8
+Content-Length: 1582
+Date: Wed, 03 Apr 2019 13:10:43 GMT
+Connection: keep-alive
+```
+
+## Calling the API
+
+Now you can turn your attention to the front-end application. You will update the application to provide a button to call a function which will in turn call the API that you created in the previous section.
+
+Open `index.html` and add a new button that will invoke the API call, as well as a `pre` element with an ID of `api-call-result` to show the result of the API call in the browser:
+
+```html
+
+
+
+
    
+```
+
+Next, open `public/js/app.js`. Configure the `auth0` client object to specify the audience value that was added earlier to the `auth_config.json` file:
+
+```js
+const configureClient = async () => {
+  const response = await fetchAuthConfig();
+  const config = await response.json();
+
+  auth0 = await auth0Client.createAuth0Client({
+    domain: config.domain,
+    clientId: config.clientId,
+    authorizationParams: {
+      audience: config.audience   // NEW - add the audience value
+    }
+  });
+};
+```
+
+Add a new function called `callApi` to `app.js`, with the following content:
+
+```js
+const callApi = async () => {
+  try {
+
+    // Get the access token from the Auth0 client
+    const token = await auth0Client.getTokenSilently();
+
+    // Make the call to the API, setting the token
+    // in the Authorization header
+    const response = await fetch("/api/external", {
+      headers: {
+        Authorization: `Bearer <%= "${token}" %>`
+      }
+    });
+
+    // Fetch the JSON result
+    const responseData = await response.json();
+
+    // Display the result in the output element
+    const responseElement = document.getElementById("api-call-result");
+
+    responseElement.innerText = JSON.stringify(responseData, {}, 2);
+
+} catch (e) {
+    // Display errors in the console
+    console.error(e);
+  }
+};
+```
+
+Finally, find the `updateUI` function within `app.js` and modify it so that the button for calling the API is enabled when the user logs in:
+
+```js
+// public/js/app.js
+
+const updateUI = async () => {
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+
+  // NEW - enable the button to call the API
+  document.getElementById("btn-call-api").disabled = !isAuthenticated;
+
+  // .. other code omitted for brevity ..
+};
+```
+
+Now, open the browser in the application at [http://localhost:3000](http://localhost:3000). If the application has been stopped, run it again from the terminal using `npm run dev`.
+
+When the application starts, log in. Then, press the **Call API** button to make a request to the API and put the results on the screen. You should find that the result from the server is displayed on the page.
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md b/ja-jp/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
new file mode 100644
index 0000000000..095335a80e
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
@@ -0,0 +1,401 @@
+
+
+<%= include('../../_includes/_login_preamble', { library: 'JavaScript' }) %>
+
+## Setting Up the Application
+
+### Create a basic HTML page
+
+Create a folder on your machine to house the application, then add an `index.html` file to the root of the project. This HTML page will display a welcome message and have a "gated" section which requires the user to be authenticated before accessing. You can copy/paste the following content into the file. You will be adding more lines as you progress with this article.
+
+Add the following content to the `index.html` file you just created:
+
+```html
+
+
+  
+    
+    SPA SDK Sample
+    
+  
+
+  
+    
    SPA Authentication Sample
    
+    
    Welcome to our page!
    
+    
+    
+  
+
+```
+
+Additionally, create a new folder called `public`, a folder inside that called `css` and a new file in there called `main.css`. This will be used to define how the gated content elements will be hidden in the page.
+
+Open the newly-created `public/css/main.css` file and add the following CSS:
+
+```css
+.hidden {
+  display: none;
+}
+
+label {
+  margin-bottom: 10px;
+  display: block;
+}
+```
+
+Finally, create a new directory in the `public` folder called `js`, and a new file in there called `app.js`. This will house the application-specific logic that you will create over the next few sections.
+
+The folder structure so far should look like the following:
+
+```
+.
+├── index.html
+└── public
+    ├── css
+    │   └── main.css
+    └── js
+        └── app.js
+```
+
+### Reference the SDK
+
+This article is based on the new SPA SDK available [here](https://github.com/auth0/auth0-spa-js/). You can reference the package from the CDN in the `index.html` file by placing the script tags at the very bottom of the `body` tag:
+
+```html
+
+  
+  
+  
+  
+  
+  
+
+```
+
+### Configure credentials
+
+Create an `auth_config.json` in the root of the project. The values from `domain` and `clientId` should be populated from your [Auth0 application settings](${manage_url}/#/applications/${account.clientId}/settings) as configured [above](#get-your-application-keys).
+
+```json
+{
+  "domain": "${account.namespace}",
+  "clientId": "${account.clientId}"
+}
+```
+
+:::note
+As `auth_config.json` is served publicly, this file should **never** contain sensitive information such as passwords and client secrets.
+:::
+
+## Create the server
+
+In this section you will create a basic web server using [ExpressJS](https://expressjs.com). This will be used to serve our HTML page, along with any assets that it requires (JavaScript, CSS, etc).
+
+Run the following command in the same folder as the `index.html` file you created earlier:
+
+```bash
+npm init -y
+```
+
+This will initialize a new NPM project and get us ready to install dependencies.
+
+### Installing dependencies
+
+In the terminal, install the dependencies that are necessary to get the server up and running:
+
+```bash
+npm install express
+```
+
+Also install [`nodemon`](https://npmjs.org/package/nodemon) so that our server can be restarted on any code changes:
+
+```bash
+npm install -D nodemon
+```
+
+Finally, open the `package.json` file and modify the "scripts" entry to look like the following:
+
+```json
+{
+  // ...
+  "scripts": {
+    "start": "node server.js",
+    "dev": "nodemon server.js"
+  },
+  // ...
+}
+```
+
+- `npm start` will run the application as normal
+- `npm run dev` will run the application using `nodemon`, watching for changes as we modify files
+
+### Creating server.js
+
+Next, create a new file in the root of the project alongside `index.html` and `package.json`, called `server.js`. This will be our backend server and will be used to serve the SPA pages.
+
+Populate `server.js` with the following code:
+
+```js
+const express = require("express");
+const { join } = require("path");
+const app = express();
+
+// Serve static assets from the /public folder
+app.use(express.static(join(__dirname, "public")));
+
+// Endpoint to serve the configuration file
+app.get("/auth_config.json", (req, res) => {
+  res.sendFile(join(__dirname, "auth_config.json"));
+});
+
+// Serve the index page for all other requests
+app.get("/*", (_, res) => {
+  res.sendFile(join(__dirname, "index.html"));
+});
+
+// Listen on port 3000
+app.listen(3000, () => console.log("Application running on port 3000"));
+```
+
+The server provides two endpoints:
+
+- one which serves the authentication configuration file to the client-side app
+- another which serves every other request to the `index.html` file, which will provide support for any client-side routing as all routes go to the same page
+
+The app also serves all of the static files, such as the `.js` and `.css` files from the `/public` folder.
+
+## Initialize the SDK
+
+The SDK must be properly initialized with the information of the Auth0 application created above.
+
+To start, open the `public/js/app.js` file and add a variable to hold the Auth0 client object:
+
+```js
+let auth0Client = null;
+```
+
+This must be initialized using the values from the `auth_config.json` file. This can be done by calling the endpoint on the server that was created in the previous section. To do this, create a new function called `fetchAuthConfig` further down the `app.js` file, which can be used to download this information:
+
+```js
+
+// ..
+
+const fetchAuthConfig = () => fetch("/auth_config.json");
+```
+
+Next, create another new function called `configureClient`. This will use `fetchAuthConfig` to download the configuration file and initialize the `auth0Client` variable:
+
+```js
+// ..
+
+const configureClient = async () => {
+  const response = await fetchAuthConfig();
+  const config = await response.json();
+
+  auth0Client = await auth0.createAuth0Client({
+    domain: config.domain,
+    clientId: config.clientId
+  });
+};
+```
+
+This call will also populate the in-memory cache with a valid access token and user profile information if someone has already authenticated before and that session is still valid.
+
+Add a handler for the `window.onload` function that will then make this call to initialize the application:
+
+```js
+// ..
+
+window.onload = async () => {
+  await configureClient();
+}
+```
+
+Now go and access it at [http://localhost:3000](http://localhost:3000). You should see the welcome message and both authentication buttons disabled. Note however that some browsers cache the page sources. When checking each step results you should perform a full page refresh ignoring the cache. This can be achieved by using the `CMD+SHIFT+R` keys on OSX and `CTRL+SHIFT+R` keys on Windows.
+
+<%= include('../../_includes/_silent-auth-social-idp') %>
+
+## Evaluate the authentication state
+
+As a first approach, you want to make sure anyone is able to visit the public page but not the page that is meant for authenticated users only, such as a settings panel or the user profile details. You can decide which content is available by hiding, disabling, or removing it if no user is currently logged in. You do so by checking the result of calling the `auth0Client.isAuthenticated()` method. Use this to enable or disable the **Log in** and **Log out** buttons, which are disabled by default. This can be part of a new `updateUI()` function called from the `window.onload` method right after the initialization.
+
+Still inside the `app.js` file, add a new function called `updateUI` and modify the `onload` handler to call this new function:
+
+```js
+// ..
+
+window.onload = async () => {
+  await configureClient();
+
+  // NEW - update the UI state
+  updateUI();
+};
+
+// NEW
+const updateUI = async () => {
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+};
+```
+
+> **Checkpoint:** If you run the project again, you should see that the "Log in" button is shown as enabled as no user has previously logged in. But clicking it will not do anything as there is no logic associated to that action yet.
+
+## Log In to the Application
+
+Authentication is achieved through a redirect to the Auth0 [Universal Login Page](https://auth0.com/docs/hosted-pages/login). Once the user signs up or logs in, the result will be passed to your app's redirect URI, which is provided with the authorization request.
+
+Inside the `app.js` file, provide a `login` function that calls `auth0Client.loginWithRedirect()` to perform the login step. The `login` function is called by the **Log in** button previously defined in the HTML page. In this sample, you will redirect the user back to the same page they are now. You can obtain that value from `window.location.origin` property:
+
+```js
+// ..
+
+const login = async () => {
+  await auth0Client.loginWithRedirect({
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  });
+};
+```
+
+Additionally, because this is a _single page application_, the result of this call needs to be handled in the same context. This means that when the page is loaded and the user is not authenticated you could be in one of the following two scenarios:
+
+1. The user does not want to authenticate and is just navigating through public content or
+2. The user has recently initiated the authentication process and is now looking to complete it.
+
+This second scenario is the one you need to handle. In your `window.onload` method, check whether the user is authenticated or not, and if the URL query contains both a `code` and `state` parameter. This will indicate that an authentication result is present and needs to be parsed. In that scenario, you do so by calling the `auth0Client.handleRedirectCallback()` method. This will attempt to exchange the result that the Auth0 backend gave you back for real tokens you can use.
+
+In addition, the query parameters must be removed from the URL so that if the user refreshes the page, the app does not try to parse the `state` and `code` parameters again. This is achieved with the `window.history.replaceState` method.
+
+Modify the `window.onload` function inside `app.js` to include these changes:
+
+```js
+// ..
+
+window.onload = async () => {
+
+  // .. code ommited for brevity
+
+  updateUI();
+
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  if (isAuthenticated) {
+    // show the gated content
+    return;
+  }
+
+  // NEW - check for the code and state parameters
+  const query = window.location.search;
+  if (query.includes("code=") && query.includes("state=")) {
+
+    // Process the login state
+    await auth0Client.handleRedirectCallback();
+    
+    updateUI();
+
+    // Use replaceState to redirect the user away and remove the querystring parameters
+    window.history.replaceState({}, document.title, "/");
+  }
+};
+
+// ..
+```
+
+The callback is now handled properly and the authentication can be completed successfully.
+
+Run the project and click the **Log in** button. You should be taken to the Universal Login Page configured for your application. Go ahead and create a new user or log in using a social connection. After authenticating successfully, you will be redirected to the page you were before. This time, the result will be present in the URL query and the exchange will happen automatically. If everything went fine, you will end up with no query parameters in the URL, the user would now be logged in and the "Log out" button will be enabled.
+
+:::note
+If you see any errors from the Auth0 server, check that you have not forgotten to register the callback URL or the allowed origins as explained initially.
+:::
+
+## Log the User Out
+
+You may have noticed that the **Log out** button is clickable when the user is authenticated, but does nothing. You need to add the code that will log the user out from the Auth0 backend.
+
+Start the log out by calling the `auth0Client.logout()` method passing a valid return-to URI. In this sample you will return the user back to the same page they are now. You can obtain that value from `window.location.origin` property. Abstract this logic into a `logout()` method.
+
+```js
+// public/js/app.js
+
+const logout = () => {
+  auth0Client.logout({
+    logoutParams: {
+      returnTo: window.location.origin
+    }
+  });
+};
+```
+
+> **Checkpoint:** Being authenticated click the **Log out** button. You should be taken to the Universal Login Page configured for your application and then back to the page you were before. Now the authentication cookies were cleared and the user is logged out. The "Log in" button will be enabled back again.
+
+If you see any errors from the Auth0 server, check that you have not forgotten to register the logout URL as explained initially.
+
+## Read the User Profile
+
+Every time a user is logged in you get access both to the **access token** and the **ID token**. The user's profile information is then extracted from the ID token. Typically, the token is used to call your backend application and the profile information is used to display their name and profile picture. In this section you are going to display them in separate text areas so you can easily inspect them.
+
+Open the `index.html` file and insert the following lines at the bottom of the body.
+
+```html
+
+  
+
+  
+  
+  
+
+```
+
+Now re-open the `app.js` file and modify the `updateUI()` function declared previously. Add the logic such that when the user is logged in the gated content is shown. Use the existing variables and functions from the SDK client to obtain and display this information on the page.
+
+In addition, at the start of this article you added a `public/css/main.css` file with the definition of the `hidden` class, which can be used to easily hide elements on the page. Using the authenticated flag as shown below, add or remove this class to the elements you want to show or hide in the `updateUI()` function:
+
+```js
+// ...
+
+const updateUI = async () => { 
+  const isAuthenticated = await auth0Client.isAuthenticated();
+
+  document.getElementById("btn-logout").disabled = !isAuthenticated;
+  document.getElementById("btn-login").disabled = isAuthenticated;
+  
+  // NEW - add logic to show/hide gated content after authentication
+  if (isAuthenticated) {
+    document.getElementById("gated-content").classList.remove("hidden");
+
+    document.getElementById(
+      "ipt-access-token"
+    ).innerHTML = await auth0Client.getTokenSilently();
+
+    document.getElementById("ipt-user-profile").textContent = JSON.stringify(
+      await auth0Client.getUser()
+    );
+
+  } else {
+    document.getElementById("gated-content").classList.add("hidden");
+  }
+};
+
+// ..
+```
+
+Note that calls to the SDK instance can throw an exception if the authentication fails, if there is no user currently authenticated, or if the access token needs to be refreshed and that request fails. You will need to put a try/catch block around them to correctly handle any errors. These error checks are not shown on the article but they are available on the final sample app that you can download.
+
+> **Checkpoint:** Go ahead and run the project for the last time. Now if the user is authenticated you will get to see their access token and profile data. See how this content disappears when you log out.
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/download.md b/ja-jp/articles/quickstart/spa/vanillajs/download.md
new file mode 100644
index 0000000000..6f559d951d
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/download.md
@@ -0,0 +1,28 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm start
+```
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/files/app.md b/ja-jp/articles/quickstart/spa/vanillajs/files/app.md
new file mode 100644
index 0000000000..4f8815c99a
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/files/app.md
@@ -0,0 +1,53 @@
+---
+name: app.js
+language: javascript
+---
+
+```javascript
+auth0.createAuth0Client({
+  domain: "${account.namespace}",
+  clientId: "${account.clientId}",
+  authorizationParams: {
+    redirect_uri: window.location.origin
+  }
+}).then(async (auth0Client) => {
+  // Assumes a button with id "login" in the DOM
+  const loginButton = document.getElementById("login");
+
+  loginButton.addEventListener("click", (e) => {
+    e.preventDefault();
+    auth0Client.loginWithRedirect();
+  });
+
+  if (location.search.includes("state=") && 
+      (location.search.includes("code=") || 
+      location.search.includes("error="))) {
+    await auth0Client.handleRedirectCallback();
+    window.history.replaceState({}, document.title, "/");
+  }
+
+  // Assumes a button with id "logout" in the DOM
+  const logoutButton = document.getElementById("logout");
+
+  logoutButton.addEventListener("click", (e) => {
+    e.preventDefault();
+    auth0Client.logout();
+  });
+
+  const isAuthenticated = await auth0Client.isAuthenticated();
+  const userProfile = await auth0Client.getUser();
+
+  // Assumes an element with id "profile" in the DOM
+  const profileElement = document.getElementById("profile");
+
+  if (isAuthenticated) {
+    profileElement.style.display = "block";
+    profileElement.innerHTML = `
+            
    <%= "${userProfile.name}" %>
    
+            " />
+          `;
+  } else {
+    profileElement.style.display = "none";
+  }
+});
+```
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/index.yml b/ja-jp/articles/quickstart/spa/vanillajs/index.yml
new file mode 100644
index 0000000000..69ef28e4e9
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/index.yml
@@ -0,0 +1,63 @@
+title: JavaScript
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/html5.png
+logo: javascript
+language:
+  - JavaScript
+author:
+  name: Steve Hobbs
+  email: steve.hobbs@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-spa-js
+  url: https://github.com/auth0/auth0-spa-js
+  logo: javascript
+snippets:
+  dependencies: application-platforms/vanillajs/dependencies
+  setup: application-platforms/vanillajs/setup
+  use: application-platforms/vanillajs/use
+alias:
+  - vanilla
+  - vanillajs
+  - spa
+  - single-page-app
+  - html5
+  - backendless
+  - javascript-app
+seo_alias: vanillajs
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+  - 02-calling-an-api
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-javascript-samples
+  branch: master
+next_steps:
+  - path: 01-login
+    list:
+      - text: 'Part 2: Calling an API using an access token'
+        icon: 345
+        href: '/quickstart/spa/vanillajs/02-calling-an-api'
+  - path: 02-calling-an-api
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/spa/vanillajs/interactive.md b/ja-jp/articles/quickstart/spa/vanillajs/interactive.md
new file mode 100644
index 0000000000..1e3fbbf521
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vanillajs/interactive.md
@@ -0,0 +1,160 @@
+---
+title: Add login to your JavaScript App
+description: 'Auth0 allows you to add authentication to your JavaScript application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing JavaScript application using the Auth0 SPA SDK.'
+interactive: true
+github:
+  path: 01-Login
+files:
+  - files/app
+---
+
+# Add Login to Your JavaScript Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in a Single-Page Application (SPA) that uses plain JavaScript, using the [Auth0 SPA SDK](https://github.com/auth0/auth0-spa-js).
+
+To use this quickstart, you’ll need to:
+
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+:::note
+This quickstart assumes you are adding Auth0 to a plain JavaScript application, as opposed to using a framework such as React or Angular.
+:::
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000',
+returnTo: 'http://localhost:3000',
+webOriginUrl: 'http://localhost:3000',
+showWebOriginInfo: true
+}) %>
+
+## Add the Auth0 SPA SDK
+
+Auth0 provides a SPA SDK (auth0-spa-js) to simplify the process of implementing Auth0 authentication and authorization in JavaScript applications. You can install the Auth0 SPA SDK as an NPM package or from the CDN. For the purpose of this quickstart, we will use the CDN. Include this script tag on your HTML page:
+
+```html
+
+```
+
+## Create the Auth0 client {{{ data-action=code data-code="app.js#1:7" }}}
+
+Create a new instance of the Auth0 client provided by the Auth0 SPA SDK and provide the Auth0 application details you created earlier in this quickstart.
+
+If a user has previously logged in, the client will refresh the authentication state on page load; the user will still be logged in once the page is refreshed.
+
+## Add login to your application {{{ data-action=code data-code="app.js#8:14" }}}
+
+Now that you have configured your Auth0 Application, added the Auth0 SPA SDK, and created the Auth0 client, you need to set up login for your project. To do this, you will use the SDK’s `loginWithRedirect()` method to redirect users to the Auth0 Universal Login page where Auth0 can authenticate them. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+Create a login button in your application that calls `loginWithRedirect()` when selected.
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to log in to your application.
+
+Run your application, and select the login button. Verify that:
+
+- you can log in or sign up using a username and password
+- your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page
+- you are redirected to Auth0 for authentication
+- Auth0 successfully redirects back to your application after authentication
+- you do not receive any errors in the console related to Auth0
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure that the correct application is selected
+- make sure you saved after entering your URLs
+- make sure the Auth0 client has been correctly configured with your Auth0 domain and client ID
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+
+:::
+::::
+
+## Handle the callback from Auth0 {{{ data-action=code data-code="app.js#16:21" }}}
+
+When the browser is redirected back to your application process, your application should call the `handleRedirectCallback()` function on the Auth0 client only when it detects a callback from Auth0. One way to do this is to only call `handleRedirectCallback()` when `code` and `state` query parameters are detected.
+
+If handling the callback was successful, the parameters should be removed from the URL so the callback handler will not be triggered the next time the page loads.
+
+::::checkpoint
+::: checkpoint-default
+Your callback from Auth0 should now be properly handled.
+
+Run your application, and select the login button again. Verify that:
+
+- Auth0 successfully redirects back to your application after authentication.
+- the query parameters are removed from the URL.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- check that the `redirect_uri` option has been configured to your application's URL
+- if you have an `error` query parameter, inspect it to learn the cause of the error
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="app.js#23:29" }}}
+
+Users who log in to your project will also need [a way to log out](/logout/guides/logout-auth0). The Auth0 client provides a `logout()` method that you can use to log a user out of your app. When users log out, they will be redirected to your [Auth0 logout endpoint](/api/authentication?javascript#logout), which will then immediately redirect them to your application and the logout URL you set up earlier in this quickstart.
+
+Create a logout button in your application that calls `logout()` when selected.
+
+:::note
+The SDK exposes an `isAuthenticated()` function that allows you to check whether a user is authenticated or not. You can render the login and logout buttons conditionally based on the value of the `isAuthenticated()` function. Alternatively, you can use a single button to combine both login and logout buttons as well as their conditional rendering.
+:::
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to log out of your application.
+
+Run your application, log in, and select the logout button. Verify that:
+
+- you are redirected to Auth0's logout endpoint.
+- Auth0 successfully redirects back to your application and the correct logout URL.
+- you are no longer logged in to your application.
+- you do not receive any errors in the console related to Auth0.
+
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- make sure that you configured the logout URL as one of the **Allowed Logout URLS** in your application's **Settings**
+- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
+
+## Show user profile information {{{ data-action=code data-code="app.js#31:45" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to personalize the user interface by displaying a logged-in user’s name or profile picture.
+
+The Auth0 SPA SDK provides user information through the `getUser()` function exposed by the Auth0 client. The Auth0 client also exposes an `isAuthenticated()` function that allows you to check whether a user is authenticated or not, which you can use to determine whether to show or hide UI elements, for example. Review the code in the interactive panel to see examples of how to use these functions.
+
+::::checkpoint
+::: checkpoint-default
+You should now be able to view user profile information.
+
+Run your application, and verify that:
+
+- user information displays correctly after you have logged in.
+- user information does not display after you have logged out.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a few things to double check:
+
+- ensure that all the previous steps work without issue
+- check your code that manages the UI in response to the authentication state
+- inspect the [application logs](https://manage.auth0.com/#/logs) for further errors relating to silent authentication
+
+Still having issues? To get more help, check out our [documentation](/) or visit our [community page](https://community.auth0.com).
+:::
+::::
diff --git a/ja-jp/articles/quickstart/spa/vuejs/01-login.md b/ja-jp/articles/quickstart/spa/vuejs/01-login.md
new file mode 100644
index 0000000000..51ca055afa
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/01-login.md
@@ -0,0 +1,29 @@
+---
+title: Login
+description: This quickstart demonstrates how to add user login to a Vue.JS application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - login
+github:
+  path: 01-Login
+sample_download_required_data:
+  - client
+contentType: tutorial
+useCase: quickstart
+---
+
+
+:::note
+Visit the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication) guide for a deep dive into implementing user authentication in Vue. This guide provides additional details on how to create a sign-up button and add route guards to a Vue application.
+:::
+
+::: warning
+This quickstart is designed for using [Auth0 Vue](https://github.com/auth0/auth0-vue) with Vue 3 applications. If you are using Vue 2, please check out the [Vue 2 Tutorial with Auth0 SPA SDK](https://github.com/auth0/auth0-vue/blob/main/tutorial/vue2-login.md) instead or visit the [Vue.js Authentication 2 By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/v2-javascript) guide.
+:::
+
+<%= include('../_includes/_getting_started', { library: 'Vue.js', callback: 'http://localhost:3000', returnTo: 'http://localhost:3000', webOriginUrl: 'http://localhost:3000', showLogoutInfo: true, showWebOriginInfo: true, new_js_sdk: true, show_install_info: false }) %>
+
+<%= include('_includes/_centralized_login') %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vuejs/02-calling-an-api.md b/ja-jp/articles/quickstart/spa/vuejs/02-calling-an-api.md
new file mode 100644
index 0000000000..2d21253081
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/02-calling-an-api.md
@@ -0,0 +1,113 @@
+---
+title: Calling an API
+description: This quickstart demonstrates how to make calls to an external API from a Vue.JS application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - apis
+github:
+  path: 02-Calling-an-API
+sample_download_required_data:
+  - client
+  - api
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+:::note
+Visit the [Integrate Vue.js with an API Server](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication#integrate-vue-js-with-an-api-server) section of the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication) guide for a deep dive into calling a protected API from Vue. This guide allows you to set up a sample API server using a backend technology of your choice, effectively creating a full-stack application.
+:::
+
+<%= include('../_includes/_calling_api_create_api') %>
+
+## Configuring the plugin
+To call an API, configure the plugin by setting the `audience` to the **API Identifier** of the API you want to call:
+
+```ts
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin,
+      audience: "${apiIdentifier}",
+    }
+  })
+);
+
+app.mount('#app');
+```
+
+## Retrieving an Access Token
+With the plugin configured using an `audience`, Auth0 will return an Access Token that can be sent to your API.
+You can retrieve an Access Token by using the `getAccessTokenSilently` function thats exposed by our SDK.
+
+```html
+
+```
+
+### Using the Options API
+
+If you are using the Options API, you can use the same `getAccessTokenSilently` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+```
+
+## Calling an API
+To call an API, include the token in the `Authorization` header of your request.
+There are many ways to make HTTP calls with Vue. Here is an example using the `fetch` API with Vue's Composition API:
+
+```html
+
+```
diff --git a/ja-jp/articles/quickstart/spa/vuejs/_includes/_centralized_login.md b/ja-jp/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
new file mode 100644
index 0000000000..25d782b80f
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
@@ -0,0 +1,203 @@
+
+
+## Install the SDK
+
+Install the [Auth0 Vue SDK](https://github.com/auth0/auth0-vue) using npm:
+
+```bash
+npm install @auth0/auth0-vue
+```
+
+### Register the plugin
+
+To use the SDK in your Vue application, register the plugin with your Vue application by passing the return value of `createAuth0` to `app.use()`.
+
+```js
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  })
+);
+
+app.mount('#app');
+```
+
+The plugin will register the SDK using both `provide` and `app.config.globalProperties`, allowing the SDK to be used with both the [Composition API](https://v3.vuejs.org/guide/composition-api-introduction.html) and [Options API](https://vuejs.org/guide/introduction.html#options-api).
+
+## Add Login to Your Application
+
+To add login to your application, use the `loginWithRedirect` function that is exposed on the return value of `useAuth0`, which you can access in your component's `setup` function.
+
+```html
+
+
+```
+
+The `loginWithRedirect` function will redirect the user to Auth0, and redirect them back to the `redirect_uri` (provided when calling `createAuth0()`) after entering their credentials.
+
+#### Using the Options API
+If you are using the Options API, you can use the same `loginWithRedirect` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
+
+## Add Logout to Your Application
+Use the `logout` function that is exposed on the return value of `useAuth0`, which you can access in your component's `setup` function, to log the user out of your application.
+
+```html
+
+
+```
+
+The `logout()` function will redirect the user to Auth0 to ensure their session is ended with Auth0 as well. Once the user is logged out successfully, they will be redirected back to the specified `returnTo` parameter.
+
+:::note
+To log the user out of your application but not from Auth0, use `logout({ localOnly: true })`.
+:::
+
+#### Using the Options API
+If you're using the Options API, you can use the same `logout` method from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
+
+## Show User Profile Information
+
+Once the user authenticates, the SDK extracts the user's profile information and stores it in memory. It can be accessed by using the reactive `user` property exposed by the return value of `useAuth0`, which you can access in your component's `setup` function.
+
+```html
+
+
+```
+
+:::note
+Ensure the user is authenticated by implementing login in your application before accessing the user's profile.
+:::
+
+#### Using the Options API
+If you're using the Options API, you can use the same reactive `user` property from the global `$auth0` property through the `this` accessor.
+
+```html
+
+
+
+```
diff --git a/ja-jp/articles/quickstart/spa/vuejs/download.md b/ja-jp/articles/quickstart/spa/vuejs/download.md
new file mode 100644
index 0000000000..cbbe03dedc
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/download.md
@@ -0,0 +1,29 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Callback URL** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+2) Set **Allowed Web Origins** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+3) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to 
+
+```text
+http://localhost:3000
+```
+4) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+```bash
+npm install && npm run serve
+```
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS         
+sh exec.sh                 
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/spa/vuejs/files/index.md b/ja-jp/articles/quickstart/spa/vuejs/files/index.md
new file mode 100644
index 0000000000..71bed0022e
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/index.md
@@ -0,0 +1,22 @@
+---
+name: index.js
+language: javascript
+---
+
+```javascript
+import { createAuth0 } from '@auth0/auth0-vue';
+
+const app = createApp(App);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    authorizationParams: {
+      redirect_uri: window.location.origin
+    }
+  })
+);
+
+app.mount('#app');
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vuejs/files/login.md b/ja-jp/articles/quickstart/spa/vuejs/files/login.md
new file mode 100644
index 0000000000..7fff90e3d7
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/login.md
@@ -0,0 +1,37 @@
+---
+name: login.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vuejs/files/logout.md b/ja-jp/articles/quickstart/spa/vuejs/files/logout.md
new file mode 100644
index 0000000000..08ffe42448
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vuejs/files/profile.md b/ja-jp/articles/quickstart/spa/vuejs/files/profile.md
new file mode 100644
index 0000000000..cd9f847bbd
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/files/profile.md
@@ -0,0 +1,50 @@
+---
+name: profile.js
+language: html
+---
+
+```html
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/spa/vuejs/index.yml b/ja-jp/articles/quickstart/spa/vuejs/index.yml
new file mode 100644
index 0000000000..ead0c3b600
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/index.yml
@@ -0,0 +1,60 @@
+title: Vue
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/vue.png
+logo: vuejs
+language:
+  - Javascript
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+framework:
+  - Vue.js
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+show_releases: true
+sdk:
+  name: auth0-vue
+  url: https://www.github.com/auth0/auth0-vue
+  logo: vuejs
+snippets:
+  dependencies: application-platforms/vuejs/dependencies
+  setup: application-platforms/vuejs/setup
+  use: application-platforms/vuejs/use
+alias:
+  - vue
+  - vuejs
+  - vue.js
+seo_alias: vuejs
+default_article: 01-login
+articles:
+  - 01-login
+  - 02-calling-an-api
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-vue-samples
+  branch: master
+requirements:
+  - Vue 3+
+next_steps:
+  - path: 01-login
+    list:
+    - text: "Part 2: Calling an API using an access token"
+      icon: 345
+      href: "/quickstart/spa/vuejs/02-calling-an-api"
+  - path: 02-calling-an-api
+    list:
+    - text: Accessing ID Token Claims
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#accessing-id-token-claims"
+    - text: Protect a Route
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#protecting-a-route"
+    - text: Handling errors
+      icon: 345
+      href: "https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#error-handling"
diff --git a/ja-jp/articles/quickstart/spa/vuejs/interactive.md b/ja-jp/articles/quickstart/spa/vuejs/interactive.md
new file mode 100644
index 0000000000..e79e07afdd
--- /dev/null
+++ b/ja-jp/articles/quickstart/spa/vuejs/interactive.md
@@ -0,0 +1,182 @@
+---
+title: Add Login to your Vue App
+description: "Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Vue application using the Auth0 Vue SDK."
+topics:
+  - quickstarts
+  - spa
+  - vuejs
+  - login
+github:
+  path: 01-Login
+sample_download_required_data:
+  - client
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+---
+
+:::note
+Visit the [Vue.js Authentication By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/) guide for a deep dive into implementing user authentication in Vue. This guide provides additional details on how to create a sign-up button, add route guards, and call a protected API from Vue.
+:::
+
+# Add Login to Your Vue Application
+
+Auth0 allows you to add authentication to almost any application type. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any Vue application using the Auth0 Vue SDK.
+
+::: warning
+This quickstart is designed for using [Auth0 Vue](https://github.com/auth0/auth0-vue) with Vue 3 applications. If you are using Vue 2, please check out the [Vue 2 Tutorial with Auth0 SPA SDK](https://github.com/auth0/auth0-vue/blob/main/tutorial/vue2-login.md) instead or visit the [Vue.js Authentication 2 By Example](https://developer.auth0.com/resources/guides/spa/vue/basic-authentication/v2-javascript) guide.
+:::
+
+To use this quickstart, you will need:
+- A free Auth0 account or log in to Auth0.
+- A working Vue project that you want to integrate with OR you can download a sample application after logging in.
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000',
+  returnTo: 'http://localhost:3000',
+  webOriginUrl: 'http://localhost:3000',
+  showWebOriginInfo: true
+}) %>
+
+## Install the Auth0 Vue SDK {{{ data-action=code data-code="index.js" }}}
+
+Auth0 provides a [Vue SDK](https://github.com/auth0/auth0-vue) to simplify the process of implementing Auth0 authentication and authorization in Vue 3 apps.
+
+Install the Auth0 Vue SDK by running the following commands in your terminal:
+
+```bash
+cd 
+npm install @auth0/auth0-vue
+```
+
+### Register the plugin
+
+For the SDK to function, you must register the plugin with your Vue application using the following properties:
+
+- `domain`: The domain of your Auth0 tenant. This value is in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- `authorizationParams.redirect_uri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. This value is in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error.
+
+The plugin will register the SDK using both `provide` and `app.config.globalProperties`. This enables both the [Composition API](https://vuejs.org/guide/introduction.html#composition-api) and [Options API](https://vuejs.org/guide/introduction.html#options-api).
+
+::::checkpoint
+
+:::checkpoint-default
+
+The plugin is now configured. Run your application to verify that:
+- the SDK is initializing correctly
+- your application is not throwing any errors related to Auth0
+
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify you selected the correct application
+* Save your changes after entering your URLs
+* Verify the domain and Client ID imported correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add login to your application {{{ data-action=code data-code="login.js" }}}
+
+Next, you will set up login for your project. You will use the SDK’s `loginWithRedirect` function exposed on the return value of `useAuth0`, which you can access in your component's setup function. It will redirect users to the Auth0 Universal Login page. and, after a user authenticates, redirect then back to the callback URL you set up earlier in this quickstart.
+
+### Using the Options API
+If you are using the Options API, you can use the same `loginWithRedirect` method from the global `$auth0` property through the `this` accessor.
+
+
+::::checkpoint
+
+:::checkpoint-default
+
+You should now be able to log in using Auth0 Universal Login.
+
+Click the login button and verify that:
+* your Vue application redirects you to the Auth0 Universal Login page
+* you can log in or sign up
+* Auth0 redirects you to your application using the value of the `authorizationParams.redirect_uri` you used to configure the plugin.
+
+:::
+
+:::checkpoint-failure
+If you were not able to log in using Auth0 Universal Login:
+* Verify you configured the correct `authorizationParams.redirect_uri`
+* Verify the domain and Client ID are set correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout.js" }}}
+
+Users who log in to your project will also need a way to log out. When users log out, your application will redirect them to your [Auth0 logout](https://auth0.com/docs/api/authentication?javascript#logout) endpoint, which will then redirect them to the specified `logoutParams.returnTo` parameter.
+
+Use the `logout` function exposed on the return value of `useAuth0`, which you can access in your component's `setup` function, to log the user out of your application.
+
+:::note
+To log the user out of your application but not from Auth0, use `logout({ openUrl: false })`.
+:::
+
+### Using the Options API
+With the Options API, you can use the same `logout` method from the global `$auth0` property through the `this` accessor.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* your Vue application redirects you to the `logoutParams.returnTo` address
+* you are no longer logged in to your application
+
+:::
+
+:::checkpoint-failure
+If you are not able to logout:
+* Verify you specified a value for `logoutParams.returnTo` when calling `logout`
+* Verify the Allowed Logout URLs in your Application Settings contains the `returnTo` value.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show user profile information {{{ data-action=code data-code="profile.js" }}}
+
+Next, you will configure how to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+Once the user authenticates, the SDK extracts the user's profile information and stores it in memory. The application can access the user profile with the reactive `user` property. To access this property, review your component's `setup` function and find the `userAuth0` return value.
+
+The `user` property contains sensitive information related to the user's identity. It is only available based on the user's authentication status. To prevent render errors, you should always:
+- use the `isAuthenticated` property to determine whether Auth0 has authenticated the user before Vue renders any component that consumes the `user` property.
+
+- ensure that the SDK has finished loading by checking that `isLoading` is false before accessing the `isAuthenticated` property.
+
+### Using the Options API
+For the Options API, use the same reactive `user`, `isLoading`, and `isAuthenticated` properties from the global `$auth0` property through the `this` accessor.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Verify that:
+* you can display the `user` or any of the user properties within a component correctly after you have logged in
+
+:::
+
+:::checkpoint-failure
+If you are having issues with the `user` properties:
+* Verify you added the `isLoading` check before accessing the `isAuthenticated` property
+* Verify you added the `isAuthenticated` check before accessing the `user` property
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/webapp/_callbackRegularWebApp.md b/ja-jp/articles/quickstart/webapp/_callbackRegularWebApp.md
new file mode 100644
index 0000000000..574fec99d9
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_callbackRegularWebApp.md
@@ -0,0 +1,10 @@
+
    
+<% if (account.callback) { %>
+
    For security purposes, you must add the callback URL of your app to your Application Settings.
    
+
    Your callback URL is currently set to:
    
+
    <%= account.callback %>
    
+<% } else { %>
+
    For security purposes, you must add the callback URL of your app to your Application Settings.
    
+<% } %>
+
+
    
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_auth0_authorize.md b/ja-jp/articles/quickstart/webapp/_includes/_auth0_authorize.md
new file mode 100644
index 0000000000..9da2f5a327
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_auth0_authorize.md
@@ -0,0 +1,16 @@
+## Integrate auth0.js
+
+```html
+
+
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md b/ja-jp/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md
new file mode 100644
index 0000000000..202f5cacca
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_auth_note_dev_keys.md
@@ -0,0 +1,5 @@
+
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_callback-url-introduction.md b/ja-jp/articles/quickstart/webapp/_includes/_callback-url-introduction.md
new file mode 100644
index 0000000000..c8a0f44b89
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_callback-url-introduction.md
@@ -0,0 +1,3 @@
+Callback URLs are the URLs that Auth0 invokes after the authentication process. Auth0 routes your application back to this URL and attaches some details to it including a token. Since callback URLs can be manipulated, you will need to add your application's URL in the app's `Allowed Callback URLs` for security. This will enable Auth0 to recognize these URLs as valid. If omitted, authentication will not be successful for the app instance.
+
+![Callback error](/media/articles/angularjs/callback_error.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_create_and_assign_roles.md b/ja-jp/articles/quickstart/webapp/_includes/_create_and_assign_roles.md
new file mode 100644
index 0000000000..d9b7b50cf8
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_create_and_assign_roles.md
@@ -0,0 +1,44 @@
+## Create and Assign Roles
+
+Before you can add Role Based Access Control, you will need to ensure the required roles are created and assigned to the corresponding user(s).
+Follow the guidance explained in [assign-roles-to-users](/users/assign-roles-to-users) to ensure your user gets assigned the `admin` role.
+
+Once the role is created and assigned to the required user(s), you will need to create a [rule](/rules/current) that adds the role(s) to the Id Token so that it is available to your backend. To do so, go to the [new rule page](${manage_url}/#/rules/new) and create an empty rule. Then, use the following code for your rule:
+
+<% if (typeof(rolesClaimType) !== "undefined") { %>
+``` js
+function (user, context, callback) {
+  const assignedRoles = (context.authorization || {}).roles;
+  const idTokenClaims = context.idToken || {};
+
+  idTokenClaims['${rolesClaimType}'] = assignedRoles;
+
+  callback(null, user, context);
+}
+```
+<% } %>
+
+<% if (typeof(rolesClaimType) === "undefined") { %>
+``` js
+function (user, context, callback) {
+  const assignedRoles = (context.authorization || {}).roles;
+  const idTokenClaims = context.idToken || {};
+  
+  idTokenClaims['https://schemas.quickstarts.com/roles'] = assignedRoles;
+
+  callback(null, user, context);
+}
+```
+<% } %>
+
+<% if (typeof(rolesClaimType) !== "undefined") { %>
+The role information is expected to exist in the `${rolesClaimType}` claim, be sure to use that when adding the roles to the ID Token in the Auth0 rule.
+<% } %>
+
+<% if (typeof(rolesClaimType) === "undefined") { %>
+  This quickstart uses `https://schemas.quickstarts.com/roles` for the claim [namespace](/tokens/guides/create-namespaced-custom-claims), but it is suggested that you use a namespace related to your own Auth0 tenant for your claims, e.g. `https://schemas.YOUR_TENANT_NAME.com/roles`.
+<% } %>
+
+::: note
+For more information on custom claims, read [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_getting_started.md b/ja-jp/articles/quickstart/webapp/_includes/_getting_started.md
new file mode 100644
index 0000000000..d5ef61e425
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_getting_started.md
@@ -0,0 +1,13 @@
+
+
+::: note
+**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Regular Web Applications](/architecture-scenarios/web-app-sso) and which [protocol](/flows) it uses.
+:::
+
+<%= include('../../../_includes/_new_app', { showClientSecret: true, isPublicClient: false }) %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+::: note
+If you are following along with the sample project you downloaded from the top of this page, the callback URL you need to add to the **Allowed Callback URLs** field is `${callback}`.
+:::
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_install_auth0js.md b/ja-jp/articles/quickstart/webapp/_includes/_install_auth0js.md
new file mode 100644
index 0000000000..ddb3c65520
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_install_auth0js.md
@@ -0,0 +1,23 @@
+## Install auth0.js
+
+Integrating Auth0 in your application requires the **auth0.js** library. Install it using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save auth0-js
+
+# installation with yarn
+yarn add auth0-js
+```
+
+Once **auth0.js** is installed, add it to your build system or bring it in to your project with a script tag.
+
+```html
+
+```
+
+If you don't want to use a package manager, **auth0.js** can also be retrieved from Auth0's CDN.
+
+```html
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_mfa-enable.md b/ja-jp/articles/quickstart/webapp/_includes/_mfa-enable.md
new file mode 100644
index 0000000000..e0d57218a5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_mfa-enable.md
@@ -0,0 +1,5 @@
+To enable the Auth0 MFA feature, open the [Multi-factor Auth With Guardian](${manage_url}/#/guardian) page and enable the __Push Notifications__ option as shown below:
+
+![dashboard MFA with push notification enabled](/media/articles/mfa/guardian-push-enabled.png)
+
+Click __Save__ and you are ready to test Multi-factor authentication in your application.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_mfa-introduction.md b/ja-jp/articles/quickstart/webapp/_includes/_mfa-introduction.md
new file mode 100644
index 0000000000..2b9ca2db14
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_mfa-introduction.md
@@ -0,0 +1 @@
+Multi-factor authentication (MFA) is an important method for adding an extra layer of security to your authentication flow. With MFA enabled in your Auth0 account, the process to grant user access to your application will require an additional verification step. In addition to a username/password combination, a verification code generated by a mobile application or sent by SMS/Voice will be required. Currently, Auth0 supports several factors for MFA. For more details, see [Multi-factor Authentication](/mfa).
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_mfa-login.md b/ja-jp/articles/quickstart/webapp/_includes/_mfa-login.md
new file mode 100644
index 0000000000..e06881a255
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_mfa-login.md
@@ -0,0 +1,6 @@
+There is no need to update the code you created in the [Login](${loginlink}) step of this tutorial. As soon as a user initiates sign-in they will be prompted to install a second-factor authenticator application (Auth0 Guardian is the default).
+
+![guardian screen](/media/articles/mfa/choose-mfa.png)
+
+For detailed instructions on using Guardian to authenticate users, see [Guardian](/mfa/concepts/guardian).
+
diff --git a/ja-jp/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md b/ja-jp/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..07cd50cfe0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
@@ -0,0 +1 @@
+Auth0 allows you to store data related to each user that has not come from the identity provider. This is known as metadata. There are two kinds of metadata, **user_metadata** and **app_metadata**. You can read about both of these at [app_metadata and user_metadata](/api/v2/changes#app-_metadata-and-user-_metadata).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/apache/01-login.md b/ja-jp/articles/quickstart/webapp/apache/01-login.md
new file mode 100644
index 0000000000..5abac44db3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/01-login.md
@@ -0,0 +1,76 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to use the Auth0 Apache SDK to add authentication and authorization to your web app.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - apache
+  - login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel System Requirements
+This tutorial and seed project have been tested with the following:
+* Apache 2.4
+:::
+
+**Please follow the steps below to configure your application using Apache to work with Auth0 and Open ID Connect.**
+
+## Install and Enable `mod_auth_openidc` Module
+
+First, you need to install the `mod_auth_openidc` module for Apache.
+
+You can get the binaries from [Github](https://github.com/zmartzone/mod_auth_openidc/releases) and install them for your OS. If your OS isn't compatible with any of the binaries, you can still [build it from source](https://github.com/zmartzone/mod_auth_openidc/blob/master/INSTALL)
+
+Once you've installed it, you just need to enable it for Apache (If you are using Windows, you can use [this](https://github.com/enderandpeter/win-a2enmod#installation) to get `a2enmod` working on your system)
+
+${snippet(meta.snippets.dependencies)}
+
+## Configure the Module with Your Auth0 Account Information
+
+Now you should get a new configuration file under the `/etc/apache2/mods-available` folder, where Apache modules are normally installed (On Windows you need to use `/apache/conf/httpd.conf` file).
+
+In there, you must add the following configuration for the `mod_auth_openidc` module
+
+${snippet(meta.snippets.setup)}
+
+## Configuring Auth0 Settings
+
+In your application settings add a new allowed callback which is equal to `OIDCRedirectURI`.
+
+Now, go to OAuth section in advanced settings and change `JsonWebToken Token Signature Algorithm` to RS256.
+
+
+## Authorization
+
+You can configure Apache to protect a certain location based on an attribute of the user. Here is an example:
+
+${snippet(meta.snippets.use)}
+
+Then you can write a rule in Auth0 that would return the `folder` attribute:
+
+```js
+function(user, context, callback) {
+    if (somecondition()) {
+       user.folder = 'example2';
+    }
+
+   user.folder = 'example';
+}
+```
+
+Or you could even use an array of folders and the apache module will check if the array contains any of these values
+
+```js
+function(user, context, callback) {
+    user.folders = [];
+    if (somecondition()) {
+       user.folders.push('example2');
+    }
+
+   user.folders.push('example');
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/apache/index.yml b/ja-jp/articles/quickstart/webapp/apache/index.yml
new file mode 100644
index 0000000000..6484af0cac
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/index.yml
@@ -0,0 +1,18 @@
+title: Apache
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/apache.jpg
+logo: apache
+author:
+  community: true
+topics:
+  - quickstart
+snippets:
+  dependencies: server-platforms/apache/dependencies
+  setup: server-platforms/apache/setup
+  use: server-platforms/apache/use
+seo_alias: apache
+default_article: 01-login
+articles:
+  - 01-login
+contentType: tutorial
+useCase: quickstart
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md
new file mode 100644
index 0000000000..9768084bf7
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/01-login.md
@@ -0,0 +1,160 @@
+---
+title: Add Login to your ASP.NET Core Blazor Server application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core Blazor Server application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - blazor-server
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../../../_includes/_new_app', { showClientSecret: false, isPublicClient: false }) %>
+
+
+
+### Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the SDK to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application in your [Application Settings](${manage_url}/#/applications), this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate Auth0
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, security, and the most complete array of features. This guide uses Universal Login to provide a way for your users to log in to your Blazor Server application.
+
+### Install dependencies
+
+To integrate Auth0 with Blazor Server you can use our SDK by installing the `Auth0.AspNetCore.Authentication` Nuget package to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Install and configure the SDK
+
+To enable authentication in your Blazor Server application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to configure the Auth0 ASP.NET Core SDK.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+```cs
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+var app = builder.Build();
+```
+
+Make sure you have enabled authentication and authorization in your Program.cs file:
+
+```csharp
+app.UseAuthentication();
+app.UseAuthorization();
+```
+
+## Login
+
+To allow users to login to your Blazor Server application, add a `LoginModel` to your `Pages` directory.
+
+Inside the `LoginModel`'s `OnGet` method, call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After successfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+```cs
+public class LoginModel : PageModel
+{
+    public async Task OnGet(string redirectUri)
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            .WithRedirectUri(redirectUri)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
+
+## Display User Profile
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and make them available through the `AuthenticationState`, which you can add as a `CascadingParameter`.
+
+You can create a custom user profile page for displaying the user's name, as well as additional claims (such as email and picture), by retrieving the corresponding information from the `AuthenticationState`'s `User` property and passing it to the view from inside Blazor code.
+
+
+```csharp
+@page "/Profile"
+@attribute [Authorize]
+
+Profile
+
+
    
+    
    
+        
    
+            
    Profile
    
+            
    
+                
    @Username
    
+            
    
+        
    
+    
    
+
    
+
+@code {
+    [CascadingParameter]
+    public Task AuthenticationStateTask { get; set; }
+    private string Username = "";
+
+    protected override async Task OnInitializedAsync()
+    {
+        var state = await AuthenticationStateTask;
+
+        Username = state.User.Identity.Name ?? string.Empty;
+
+        await base.OnInitializedAsync();
+    }
+}
+```
+
+## Logout
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside a `LogoutModel`'s `OnGet` method.
+
+Additionally, if you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `Redirect("/")` or any other appropriate redirect.
+:::
+
+```cs
+[Authorize]
+public class LogoutModel : PageModel
+{
+    public async Task OnGet()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            .WithRedirectUri("/")
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
+
+## What's next?
+
+We put together a few examples of how to use the SDK in more advanced use cases:
+
+- [Configuring Scopes](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#blazor-server)
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/download.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/download.md
new file mode 100644
index 0000000000..49f7a98084
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/download.md
@@ -0,0 +1,30 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [.NET Core](https://www.microsoft.com/net/download) is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md
new file mode 100644
index 0000000000..bb161024d6
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/appsettings.md
@@ -0,0 +1,13 @@
+---
+name: appsettings.json
+language: json
+---
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "ClientId": "${account.clientId}"
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md
new file mode 100644
index 0000000000..c2f7bf7a8a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/login-model.md
@@ -0,0 +1,18 @@
+---
+name: Login.cshtml.cs
+language: csharp
+---
+
+```csharp
+public class LoginModel : PageModel
+{
+    public async Task OnGet(string redirectUri)
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            .WithRedirectUri(redirectUri)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md
new file mode 100644
index 0000000000..8ba8d1d890
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/logout-model.md
@@ -0,0 +1,20 @@
+---
+name: Logout.cshtml.cs
+language: csharp
+---
+
+```csharp
+[Authorize]
+public class LogoutModel : PageModel
+{
+    public async Task OnGet()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            .WithRedirectUri("/")
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
new file mode 100644
index 0000000000..1c6e68f3d7
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/profile.md
@@ -0,0 +1,37 @@
+---
+name: Profile.razor
+language: csharp
+---
+
+```csharp
+@page "/Profile"
+@attribute [Authorize]
+
+Profile
+
+
    
+    
    
+        
    
+            
    Profile
    
+            
    
+                
    @Username
    
+            
    
+        
    
+    
    
+
    
+
+@code {
+    [CascadingParameter]
+    public Task AuthenticationStateTask { get; set; }
+    private string Username = "";
+
+    protected override async Task OnInitializedAsync()
+    {
+        var state = await AuthenticationStateTask;
+
+        Username = state.User.Identity.Name ?? string.Empty;
+
+        await base.OnInitializedAsync();
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md
new file mode 100644
index 0000000000..1364a4d420
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: csharp
+---
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+builder.Services.AddControllersWithViews();
+
+var app = builder.Build();
+
+app.UseAuthentication();
+app.UseAuthorization();
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml
new file mode 100644
index 0000000000..96471ac09d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/index.yml
@@ -0,0 +1,39 @@
+title: ASP.NET Core Blazor Server
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet-platform
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+sdk:
+  name: auth0-aspnetcore-authentication
+  url: https://github.com/auth0/auth0-aspnetcore-authentication
+  logo: dotnet
+snippets:
+  dependencies: server-platforms/aspnet-core/dependencies
+alias:
+  - net-6
+  - net-7
+  - net-8
+seo_alias: aspnet-core-blazor-server
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnetcore-blazor-server-samples
+  branch: main
+requirements:
+  - .NET 6.0
+  - .NET 7.0
+  - .NET 8.0
+sample_download_required_data:
+  - client
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
new file mode 100644
index 0000000000..20a9e39710
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core-blazor-server/interactive.md
@@ -0,0 +1,137 @@
+---
+title: Add Login to your ASP.NET Core Blazor Server application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core Blazor Server application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - blazor-server
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/login-model
+  - files/logout-model
+  - files/profile
+  - files/program
+---
+
+# Add Login to Your Blazor Server Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Blazor Server application using the **Auth0.AspNetCore.Authentication** SDK. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install and Configure the SDK {{{ data-action=code data-code="Program.cs" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with Blazor Server you can use our SDK by installing the `Auth0.AspNetCore.Authentication` [Nuget package](https://www.nuget.org/packages/Auth0.AspNetCore.Authentication/) to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Configure the middleware
+
+To enable authentication in your Blazor Server application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to register the SDK's middleware.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+Make sure you have enabled authentication and authorization in your `Program.cs` file.
+
+## Login {{{ data-action=code data-code="Login.cshtml.cs" }}}
+
+To allow users to login to your Blazor Server application, add a `LoginModel` to your `Pages` directory.
+
+Inside the `LoginModel`'s `OnGet` method, call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After successfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` page will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Display User Profile {{{ data-action=code data-code="Profile.razor" }}}
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and make them available through the `AuthenticationState`, which you can add as a `CascadingParameter`.
+
+You can create a custom user profile page for displaying the user's name, as well as additional claims (such as email and picture), by retrieving the corresponding information from the `AuthenticationState`'s `User` property and passing it to the view from inside Blazor code.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up to render the user's profile, run your application to verify that:
+* Navigating to the endpoint containing the profile after being successfully logged in shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Logout {{{ data-action=code data-code="Logout.cshtml.cs" }}}
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside a `LogoutModel`'s `OnGet` method.
+
+Additionally, if you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `Redirect("/")` or any other appropriate redirect.
+:::
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` page will ensure the user is logged out.
+* When also logging out from Auth0, you should be redirected to Auth0 and instantly redirected back to your own application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/01-login.md b/ja-jp/articles/quickstart/webapp/aspnet-core/01-login.md
new file mode 100644
index 0000000000..81a7c55af0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/01-login.md
@@ -0,0 +1,160 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an ASP.NET Core application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../../../_includes/_new_app', { showClientSecret: false, isPublicClient: false }) %>
+
+
+
+### Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the SDK to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application in your [Application Settings](${manage_url}/#/applications), this URL will mostly take the format `https://YOUR_APPLICATION_URL/callback`.
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Integrate Auth0
+
+[Universal Login](/hosted-pages/login) is the easiest way to set up authentication in your application. We recommend using it for the best experience, best security and the fullest array of features. This guide will use it to provide a way for your users to log in to your ASP.NET Core application.
+
+### Install dependencies
+
+To integrate Auth0 with ASP.NET Core you can use our SDK by installing the `Auth0.AspNetCore.Authentication` Nuget package to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Install and configure the SDK
+
+To enable authentication in your ASP.NET Core application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to configure the Auth0 ASP.NET Core SDK.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+```cs
+var builder = WebApplication.CreateBuilder(args);
+// Cookie configuration for HTTP to support cookies with SameSite=None
+builder.Services.ConfigureSameSiteNoneCookies();
+
+// Cookie configuration for HTTPS
+//  builder.Services.Configure(options =>
+//  {
+//     options.MinimumSameSitePolicy = SameSiteMode.None;
+//  });
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+builder.Services.AddControllersWithViews();
+var app = builder.Build();
+```
+
+::: note
+The `ConfigureSameSiteNoneCookies` method used above was added as part of the [sample application](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/blob/master/Quickstart/Sample/Support/SameSiteServiceCollectionExtensions.cs) in order to ([make cookies with SameSite=None work over HTTP when using Chrome](https://blog.chromium.org/2019/10/developers-get-ready-for-new.html)). We recommend using HTTPS instead of HTTP, which removes the need for the `ConfigureSameSiteNoneCookies` method.
+:::
+
+Make sure you have enabled authentication and authorization in your Program.cs file:
+
+```csharp
+app.UseAuthentication();
+app.UseAuthorization();
+```
+
+## Login
+
+To add the `Login`, call `ChallengeAsync` and pass "Auth0" (`Auth0Constants.AuthenticationScheme`) as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally.
+
+After the OIDC middleware signs the user in, the user is also automatically signed in to the cookie middleware. This allows the user to be authenticated on subsequent requests.
+
+```cs
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+    public async Task Login(string returnUrl = "/")
+    {
+        var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+            // Indicate here where Auth0 should redirect the user after a login.
+            // Note that the resulting absolute Uri must be added to the
+            // **Allowed Callback URLs** settings for the app.
+            .WithRedirectUri(returnUrl)
+            .Build();
+
+        await HttpContext.ChallengeAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+    }
+}
+```
+
+## Display User Profile
+
+The SDK extracts the user's information from the ID Token and makes them available as the `User.Claims` property on the controller.
+
+You can create a custom user profile page for displaying a user's name, email address, and profile image, by passing the corresponding information to the view from inside your controller.
+
+```csharp
+public class AccountController : Controller
+{
+    [Authorize]
+    public IActionResult Profile()
+    {
+        return View(new
+        {
+            Name = User.Identity.Name,
+            EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
+            ProfileImage = User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value
+        });
+    }
+}
+```
+
+## Logout
+
+To add `Logout`, you need to sign the user out of both the Auth0 middleware as well as the cookie middleware.
+
+```cs
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+    [Authorize]
+    public async Task Logout()
+    {
+        var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+            // Indicate here where Auth0 should redirect the user after a logout.
+            // Note that the resulting absolute Uri must be added to the
+            // **Allowed Logout URLs** settings for the app.
+            .WithRedirectUri(Url.Action("Index", "Home"))
+            .Build();
+
+        await HttpContext.SignOutAsync(Auth0Constants.AuthenticationScheme, authenticationProperties);
+        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
+    }
+}
+```
+
+## What's next?
+
+We put together a few examples of how to use the SDK in more advanced use cases:
+
+- [Configuring Scopes](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#scopes)
+- [Obtain an Access Token for Calling an API](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#calling-an-api)
+- [Adding Role-based authorization](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#roles)
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/download.md b/ja-jp/articles/quickstart/webapp/aspnet-core/download.md
new file mode 100644
index 0000000000..49f7a98084
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/download.md
@@ -0,0 +1,30 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [.NET Core](https://www.microsoft.com/net/download) is installed, and run the following commands:
+
+```bash
+dotnet run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/files/account.controller.md b/ja-jp/articles/quickstart/webapp/aspnet-core/files/account.controller.md
new file mode 100644
index 0000000000..7e773fd254
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/files/account.controller.md
@@ -0,0 +1,62 @@
+---
+name: AccountController.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+using Auth0.AspNetCore.Authentication;
+
+public class AccountController : Controller
+{
+  public async Task Login(string returnUrl = "/")
+  {
+    var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
+      // Indicate here where Auth0 should redirect the user after a login.
+      // Note that the resulting absolute Uri must be added to the
+      // **Allowed Callback URLs** settings for the app.
+      .WithRedirectUri(returnUrl)
+      .Build();
+
+    await HttpContext.ChallengeAsync(
+      Auth0Constants.AuthenticationScheme,
+      authenticationProperties
+    );
+  }
+
+  [Authorize]
+  public IActionResult Profile()
+  {
+    return View(new
+    {
+      Name = User.Identity.Name,
+      EmailAddress = User.Claims
+        .FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
+      ProfileImage = User.Claims
+        .FirstOrDefault(c => c.Type == "picture")?.Value
+    });
+  }
+
+  [Authorize]
+  public async Task Logout()
+  {
+    var authenticationProperties = new LogoutAuthenticationPropertiesBuilder()
+      // Indicate here where Auth0 should redirect the user after a logout.
+      // Note that the resulting absolute Uri must be added to the
+      // **Allowed Logout URLs** settings for the app.
+      .WithRedirectUri(Url.Action("Index", "Home"))
+      .Build();
+
+    // Logout from Auth0
+    await HttpContext.SignOutAsync(
+      Auth0Constants.AuthenticationScheme,
+      authenticationProperties
+    );
+    // Logout from the application
+    await HttpContext.SignOutAsync(
+      CookieAuthenticationDefaults.AuthenticationScheme
+    );
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/files/appsettings.md b/ja-jp/articles/quickstart/webapp/aspnet-core/files/appsettings.md
new file mode 100644
index 0000000000..bb161024d6
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/files/appsettings.md
@@ -0,0 +1,13 @@
+---
+name: appsettings.json
+language: json
+---
+
+```json
+{
+  "Auth0": {
+    "Domain": "${account.namespace}",
+    "ClientId": "${account.clientId}"
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/files/program.md b/ja-jp/articles/quickstart/webapp/aspnet-core/files/program.md
new file mode 100644
index 0000000000..1364a4d420
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/files/program.md
@@ -0,0 +1,21 @@
+---
+name: Program.cs
+language: csharp
+---
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services.AddAuth0WebAppAuthentication(options =>
+{
+    options.Domain = builder.Configuration["Auth0:Domain"];
+    options.ClientId = builder.Configuration["Auth0:ClientId"];
+});
+
+builder.Services.AddControllersWithViews();
+
+var app = builder.Build();
+
+app.UseAuthentication();
+app.UseAuthorization();
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/index.yml b/ja-jp/articles/quickstart/webapp/aspnet-core/index.yml
new file mode 100644
index 0000000000..3b3a20f345
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/index.yml
@@ -0,0 +1,39 @@
+title: ASP.NET Core MVC
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet-platform
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+sdk:
+  name: auth0-aspnetcore-authentication
+  url: https://github.com/auth0/auth0-aspnetcore-authentication
+  logo: dotnet
+snippets:
+  dependencies: server-platforms/aspnet-core/dependencies
+alias:
+  - net-6
+  - net-7
+  - net-8
+seo_alias: aspnet-core
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - "interactive"
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnetcore-mvc-samples
+  branch: master
+requirements:
+  - .NET 6.0
+  - .NET 7.0
+  - .NET 8.0
+sample_download_required_data:
+  - client
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-core/interactive.md b/ja-jp/articles/quickstart/webapp/aspnet-core/interactive.md
new file mode 100644
index 0000000000..54ebad8df2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-core/interactive.md
@@ -0,0 +1,134 @@
+---
+title: Add Login to your ASP.NET MVC application
+description: This tutorial demonstrates how to add user login to an ASP.NET Core application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-core
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/program
+  - files/appsettings
+  - files/account.controller
+---
+
+# Add Login to Your ASP.NET MVC Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET MVC application using the **Auth0.AspNetCore.Authentication** SDK. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install and Configure the SDK {{{ data-action=code data-code="Program.cs" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with ASP.NET Core you can use our SDK by installing the `Auth0.AspNetCore.Authentication` [Nuget package](https://www.nuget.org/packages/Auth0.AspNetCore.Authentication/) to your application.
+
+```bash
+Install-Package Auth0.AspNetCore.Authentication
+```
+
+### Configure the middleware
+
+To enable authentication in your ASP.NET Core application, use the middleware provided by the SDK. Go to the `Program.cs` file and call `builder.Services.AddAuth0WebAppAuthentication()` to register the SDK's middleware.
+
+Ensure to configure the `Domain` and `ClientId`, these are required fields to ensure the SDK knows which Auth0 tenant and application it should use.
+
+Make sure you have enabled authentication and authorization in your `Program.cs` file.
+## Login {{{ data-action=code data-code="AccountController.cs#7:20" }}}
+
+To allow users to login to your ASP.NET MVC application, add a `Login` action to your controller.
+
+Call `HttpContext.ChallengeAsync()` and pass `Auth0Constants.AuthenticationScheme` as the authentication scheme. This will invoke the OIDC authentication handler that our SDK registers internally. Be sure to also specify the corresponding `authenticationProperties`, which you can construct using the `LoginAuthenticationPropertiesBuilder`.
+
+After succesfully calling `HttpContext.ChallengeAsync()`, the user will be redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` action will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Display User Profile {{{ data-action=code data-code="AccountController.cs#23:33" }}}
+
+After the middleware has successfully retrieved the tokens from Auth0, it will extract the user's information and claims from the ID Token and makes them available as the `User.Claims` property on the controller.
+
+You can create a custom user profile page for displaying a user's name, email address, and profile image, by retrieving the corresponding information from the `User` and pass it to the view from inside your controller.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up your action to render the user's profile, run your application to verify that:
+* Navigating to your `Profile` action after being succesfully logged in, shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Logout {{{ data-action=code data-code="AccountController.cs#36:52" }}}
+
+Logging out the user from your own application can be done by calling `HttpContext.SignOutAsync` with the `CookieAuthenticationDefaults.AuthenticationScheme` authentication scheme from inside your controller's action.
+
+Additionaly, If you also want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign On), call `HttpContext.SignOutAsync` with the `Auth0Constants.AuthenticationScheme` authentication scheme as well as the appropriate `authenticationProperties` that can be constructed using the `LogoutAuthenticationPropertiesBuilder`.
+
+::: note
+When only logging the user out from your own application but not from Auth0, ensure to return `RedirectToAction("Index", "Home")` or any other appropriate redirect.
+:::
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` action will ensure the user is logged out.
+* When also logging out from Auth0, you should be redirected to Auth0 and instantly redirected back to your own application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md
new file mode 100644
index 0000000000..beb980dd2b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md
@@ -0,0 +1,204 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an ASP.NET OWIN application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-owin
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+sample_download_required_data:
+  - client
+---
+<%= include('../../../_includes/_new_app', { showClientSecret: true, isPublicClient: false }) %>
+
+<%= include('_includes/_setup') %>
+
+## Install and configure the OpenID Connect middleware
+
+::: note
+  This quickstart uses OWIN middleware and as such, you need to use OWIN in your application. If your application is not currently using OWIN, please refer to Microsoft's OWIN documentation to enable it in your application.
+:::
+
+The easiest way to enable authentication with Auth0 in your ASP.NET MVC application is to use the OWIN OpenID Connect middleware, so install the `Microsoft.Owin.Security.OpenIdConnect` NuGet package first:
+
+```bash
+Install-Package Microsoft.Owin.Security.OpenIdConnect
+```
+
+You must also install the following middleware library to enable cookie authentication in your project:
+
+```bash
+Install-Package Microsoft.Owin.Security.Cookies
+```
+
+::: note
+There are issues when configuring the OWIN cookie middleware and System.Web cookies at the same time. Please read about the [System.Web cookie integration issues doc](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues) to learn about how to mitigate these problems
+:::
+
+Now go to the `Configuration` method of your `Startup` class and configure the cookie middleware as well as the Auth0 middleware.
+
+```cs
+// Startup.cs
+using Microsoft.IdentityModel.Protocols.OpenIdConnect;
+using Microsoft.IdentityModel.Tokens;
+using Microsoft.Owin;
+using Microsoft.Owin.Host.SystemWeb;
+using Microsoft.Owin.Security;
+using Microsoft.Owin.Security.Cookies;
+using Microsoft.Owin.Security.OpenIdConnect;
+using MvcApplication.Support;
+using Owin;
+
+public void Configuration(IAppBuilder app)
+{
+    // Configure Auth0 parameters
+    string auth0Domain = ConfigurationManager.AppSettings["auth0:Domain"];
+    string auth0ClientId = ConfigurationManager.AppSettings["auth0:ClientId"];
+    string auth0RedirectUri = ConfigurationManager.AppSettings["auth0:RedirectUri"];
+    string auth0PostLogoutRedirectUri = ConfigurationManager.AppSettings["auth0:PostLogoutRedirectUri"];
+
+    // Set Cookies as default authentication type
+    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
+    app.UseCookieAuthentication(new CookieAuthenticationOptions
+    {
+        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+        LoginPath = new PathString("/Account/Login"),
+
+        // Configure SameSite as needed for your app. Lax works well for most scenarios here but
+        // you may want to set SameSiteMode.None for HTTPS
+        CookieSameSite = SameSiteMode.Lax,
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())
+    });
+
+    // Configure Auth0 authentication
+    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+    {
+        AuthenticationType = "Auth0",
+
+        Authority = $"https://{auth0Domain}",
+
+        ClientId = auth0ClientId,
+
+        RedirectUri = auth0RedirectUri,
+        PostLogoutRedirectUri = auth0PostLogoutRedirectUri,
+        Scope = "openid profile email",
+        TokenValidationParameters = new TokenValidationParameters
+        {
+            NameClaimType = "name"
+        },
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://docs.microsoft.com/en-us/aspnet/samesite/owin-samesite
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()),
+
+        // Configure Auth0's Logout URL by hooking into the RedirectToIdentityProvider notification, 
+        // which is getting triggered before any redirect to Auth0 happens.
+        Notifications = new OpenIdConnectAuthenticationNotifications
+        {
+            RedirectToIdentityProvider = notification =>
+            {
+                // Only when the RequestType is OpenIdConnectRequestType.Logout should we configure the logout URL.
+                // Any other RequestType means a different kind of interaction with Auth0 that isn't logging out.
+                if (notification.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
+                {
+                    var logoutUri = $"https://{auth0Domain}/v2/logout?client_id={auth0ClientId}";
+
+                    var postLogoutUri = notification.ProtocolMessage.PostLogoutRedirectUri;
+                    if (!string.IsNullOrEmpty(postLogoutUri))
+                    {
+                        if (postLogoutUri.StartsWith("/"))
+                        {
+                            // transform to absolute
+                            var request = notification.Request;
+                            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
+                        }
+                        logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
+                    }
+
+                    notification.Response.Redirect(logoutUri);
+                    notification.HandleResponse();
+                }
+                return Task.FromResult(0);
+            }
+        }
+    });
+}
+```
+
+It is essential that you register both the cookie middleware and the OpenID Connect middleware, as they are required (in that order) for the authentication to work. The OpenID Connect middleware will handle the authentication with Auth0. Once the user has authenticated, their identity will be stored in the cookie middleware.
+
+In the code snippet above, note that the `AuthenticationType` is set to **Auth0**. This will be used in the next section to challenge the OpenID Connect middleware and start the authentication flow. Also note code in the `RedirectToIdentityProvider` notification event which constructs the correct [logout URL](/logout).
+
+
+
+
+## Add login to your ASP.NET OWIN application
+
+To allow users to login to your ASP.NET OWIN application, add a `Login` action to your controller.
+
+Call `HttpContext.GetOwinContext().Authentication.Challenge` and pass `"Auth0"` as the authentication scheme. This invokes the OIDC authentication handler that was registered earlier. Be sure to specify the corresponding `AuthenticationProperties`, including a `RedirectUri`.
+
+After successfully calling `HttpContext.GetOwinContext().Authentication.Challenge`, the user is redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow users to be authenticated on subsequent requests.
+
+```cs
+public class AccountController : Controller
+{
+    public ActionResult Login(string returnUrl)
+    {
+        HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties
+            {
+                RedirectUri = returnUrl ?? Url.Action("Index", "Home")
+            },
+            "Auth0");
+        return new HttpUnauthorizedResult();
+    }
+}
+```
+
+## Add logout to your ASP.NET OWIN application
+
+From your controller's action, call `HttpContext.GetOwinContext().Authentication.SignOut` with the `CookieAuthenticationDefaults.AuthenticationType` authentication scheme to log the user out of your application.
+
+Additionally, if you want to log the user out from Auth0 (this might also log them out of other applications that rely on Single Sign-On), call `HttpContext.GetOwinContext().Authentication.SignOut` with the `"Auth0"` authentication scheme.
+
+```cs
+public class AccountController : Controller
+{
+    [Authorize]
+    public void Logout()
+    {
+        HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
+        HttpContext.GetOwinContext().Authentication.SignOut("Auth0");
+    }
+}
+```
+
+## Display the user profile
+
+After the middleware successfully retrieves the tokens from Auth0, it extracts the user's information and claims from the ID token and makes them available as `ClaimsIdentity`. Access the extracted information by using the `User` property on the controller.
+
+To create a user profile, retrieve a user's name, email address, and profile image from `User.Identity` and pass it to the view from inside your controller.
+```csharp
+// Controllers/AccountController.cs
+
+[Authorize]
+public ActionResult UserProfile()
+{
+    var claimsIdentity = User.Identity as ClaimsIdentity;
+
+    return View(new
+    {
+        Name = claimsIdentity?.FindFirst(c => c.Type == claimsIdentity.NameClaimType)?.Value,
+        EmailAddress = claimsIdentity?.FindFirst(c => c.Type == ClaimTypes.Email)?.Value,
+        ProfileImage = claimsIdentity?.FindFirst(c => c.Type == "picture")?.Value
+    });
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
new file mode 100644
index 0000000000..5db5d77940
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
@@ -0,0 +1,9 @@
+## Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the OWIN OpenID Connect middleware to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application. The Callback URL for the seed project is `http://localhost:3000/callback`, so be sure to add this to the **Allowed Callback URLs** section of your application. Also, add `http://localhost:3000/` to the **Allowed Logout URLs**.
+
+If you deploy your application to a different URL you will also need to ensure to add that URL to the **Allowed Callback URLs** and **Allowed Logout URLs**. The `web.config` in the sample projects also contain two keys named `auth0:RedirectUri` and `auth0:PostLogoutRedirectUri` with these URLs. Be sure to change those as well.
+
+That's all you need to start working with Auth0!
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md
new file mode 100644
index 0000000000..5c9fea1bc1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md
@@ -0,0 +1,15 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000
+```
+
+3) Open the project in [Visual Studio](https://visualstudio.microsoft.com/vs/).
+
+4) Click the `Start` button or select the menu option `Debug | Start Debugging` or use the keyboard shortcut `F5`.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/files/account.controller.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/account.controller.md
new file mode 100644
index 0000000000..f3a44a134e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/account.controller.md
@@ -0,0 +1,46 @@
+---
+name: AccountController.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.AspNetCore.Authentication;
+using Microsoft.AspNetCore.Authentication.Cookies;
+
+public class AccountController : Controller
+{
+  public ActionResult Login(string returnUrl = "/")
+  {
+    HttpContext.GetOwinContext().Authentication.Challenge(
+      new AuthenticationProperties
+      {
+          RedirectUri = returnUrl ?? Url.Action("Index", "Home")
+      },
+      "Auth0"
+    );
+  }
+
+  [Authorize]
+  public ActionResult UserProfile()
+  {
+      var claimsIdentity = User.Identity as ClaimsIdentity;
+
+      return View(new UserProfileViewModel()
+      {
+          Name = claimsIdentity?
+            .FindFirst(c => c.Type == claimsIdentity.NameClaimType)?.Value,
+          EmailAddress = claimsIdentity?
+            .FindFirst(c => c.Type == ClaimTypes.Email)?.Value,
+          ProfileImage = claimsIdentity?
+            .FindFirst(c => c.Type == "picture")?.Value
+      });
+  }
+
+  [Authorize]
+  public void Logout()
+  {
+    HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
+    HttpContext.GetOwinContext().Authentication.SignOut("Auth0");
+  }
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/files/startup.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/startup.md
new file mode 100644
index 0000000000..1dcde454f0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/startup.md
@@ -0,0 +1,83 @@
+---
+name: Startup.cs
+language: csharp
+---
+
+```csharp
+using Microsoft.IdentityModel.Protocols.OpenIdConnect;
+using Microsoft.IdentityModel.Tokens;
+using Microsoft.Owin;
+using Microsoft.Owin.Host.SystemWeb;
+using Microsoft.Owin.Security;
+using Microsoft.Owin.Security.Cookies;
+using Microsoft.Owin.Security.OpenIdConnect;
+using MvcApplication.Support;
+using Owin;
+
+public void Configuration(IAppBuilder app)
+{
+    string domain = ConfigurationManager.AppSettings["auth0:Domain"];
+    string clientId = ConfigurationManager.AppSettings["auth0:ClientId"];
+    string redirectUri = "http://localhost:3000/callback";
+    string postLogoutRedirectUri = "http://localhost:3000";
+
+    // Set Cookies as default authentication type
+    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
+    app.UseCookieAuthentication(new CookieAuthenticationOptions
+    {
+        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+        LoginPath = new PathString("/Account/Login"),
+
+        CookieSameSite = SameSiteMode.Lax,
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())
+    });
+
+    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+    {
+        AuthenticationType = "Auth0",
+        Authority = $"https://{domain}",
+        ClientId = clientId,
+        RedirectUri = redirectUri,
+        PostLogoutRedirectUri = postLogoutRedirectUri,
+        ResponseType = OpenIdConnectResponseType.CodeIdToken,
+        Scope = "openid profile email",
+        TokenValidationParameters = new TokenValidationParameters
+        {
+            NameClaimType = "name"
+        },
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://docs.microsoft.com/en-us/aspnet/samesite/owin-samesite
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()),
+        Notifications = new OpenIdConnectAuthenticationNotifications
+        {
+            RedirectToIdentityProvider = notification =>
+            {
+                if (notification.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
+                {
+                    var logoutUri = $"https://{domain}/v2/logout?client_id={clientId}";
+
+                    var postLogoutUri = notification.ProtocolMessage.PostLogoutRedirectUri;
+                    if (!string.IsNullOrEmpty(postLogoutUri))
+                    {
+                        if (postLogoutUri.StartsWith("/"))
+                        {
+                            // transform to absolute
+                            var request = notification.Request;
+                            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
+                        }
+                        logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
+                    }
+
+                    notification.Response.Redirect(logoutUri);
+                    notification.HandleResponse();
+                }
+                return Task.FromResult(0);
+            }
+        }
+    });
+}
+```
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/files/web.config.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/web.config.md
new file mode 100644
index 0000000000..02a8c6b911
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/files/web.config.md
@@ -0,0 +1,14 @@
+---
+name: Web.config
+language: xml
+---
+
+```xml
+
+
+  
+    
+    
+  
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/index.yml b/ja-jp/articles/quickstart/webapp/aspnet-owin/index.yml
new file mode 100644
index 0000000000..a14bac0006
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/index.yml
@@ -0,0 +1,48 @@
+title: ASP.NET (OWIN)
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/asp.png
+logo: dotnet
+author:
+  name: Frederik Prijck
+  email: frederik.prijck@okta.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-platforms/aspnet-owin/dependencies
+  setup: server-platforms/aspnet-owin/setup
+  use: server-platforms/aspnet-owin/use
+alias:
+  - aspnetowin
+  - owin
+seo_alias: aspnet-owin
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-aspnet-owin-mvc-samples
+  branch: master
+requirements:
+  - Microsoft Visual Studio 2017
+  - Microsoft.Owin.Security.OpenIdConnect v4.1.0 and up
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/interactive.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/interactive.md
new file mode 100644
index 0000000000..f54465e77b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/interactive.md
@@ -0,0 +1,141 @@
+---
+title: Add Login to your ASP.NET Owin application
+description: This tutorial demonstrates how to add user login to an ASP.NET Owin application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-owin
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/web.config
+  - files/startup
+  - files/account.controller
+---
+
+# Add login to your ASP.NET Owin application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing ASP.NET OWIN application using the `Microsoft.Owin.Security.OpenIdConnect` Nuget package. 
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Configure the project {{{ data-action=code data-code="Web.config#1:7" }}}
+
+### Install from Nuget
+
+To integrate Auth0 with ASP.NET OWIN, you can use the `Microsoft.Owin.Security.OpenIdConnect` and `Microsoft.Owin.Security.Cookies` Nuget packages.
+
+```bash
+Install-Package Microsoft.Owin.Security.OpenIdConnect
+Install-Package Microsoft.Owin.Security.Cookies
+```
+
+:::note
+Issues occur when configuring the OWIN cookie middleware and System.Web cookies at the same time. To learn more, read [System.Web cookie integration issues doc](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues) to mitigate these problems.
+:::
+
+### Configure the credentials
+For the SDK to function properly, set the following properties in `Web.config`:
+- `auth0:Domain`: The domain of your Auth0 tenant. You can find this in the Auth0 Dashboard under your application's **Settings** in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- `auth0:ClientId`: The ID of the Auth0 application you created in Auth0 Dashboard. You can find this in the Auth0 Dashboard under your application's **Settings** in the Client ID field.
+
+## Configure the middleware {{{ data-action=code data-code="Startup.cs#9:13" }}}
+
+To enable authentication in your ASP.NET OWIN application, go to the `Configuration` method of your `Startup` class and configure the cookie and OIDC middleware.
+
+It is essential that you register both the cookie middleware and the OpenID Connect middleware as both are required (in that order) for authentication to work. The OpenID Connect middleware handles the authentication with Auth0. Once users have authenticated, their identity is stored in the cookie middleware.
+
+In the code snippet, `AuthenticationType` is set to **Auth0**. Use `AuthenticationType` in the next section to challenge the OpenID Connect middleware and start the authentication flow. `RedirectToIdentityProvider` notification event constructs the correct [logout URL](/logout).
+
+## Add login to your application {{{ data-action=code data-code="AccountController.cs#6:15" }}}
+
+To allow users to log in to your ASP.NET OWIN application, add a `Login` action to your controller.
+
+Call `HttpContext.GetOwinContext().Authentication.Challenge` and pass `"Auth0"` as the authentication scheme. This invokes the OIDC authentication handler that was registered earlier. Be sure to specify the corresponding `AuthenticationProperties`, including a `RedirectUri`.
+
+After successfully calling `HttpContext.GetOwinContext().Authentication.Challenge`, the user redirects to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow the users to be authenticated on subsequent requests.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Login, run your application to verify that:
+* Navigating to your `Login` action will redirect to Auth0
+* Entering your credentials will redirect you back to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple of things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Add logout to your application {{{ data-action=code data-code="AccountController.cs#34:39" }}}
+
+From your controller's action, call `HttpContext.GetOwinContext().Authentication.SignOut` with the `CookieAuthenticationDefaults.AuthenticationType` authentication scheme to log the user out of your application.
+
+Additionally, if you want to log the user out from Auth0 (this *might* also log them out of other applications that rely on Single Sign-On), call `HttpContext.GetOwinContext().Authentication.SignOut` with the `"Auth0"` authentication scheme.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have configured Logout, run your application to verify that:
+* Navigating to your `Logout` action ensures the user is logged out.
+* During logout, you redirect to Auth0 and instantly redirect back to your application during log out.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple of things to double-check:
+* make sure the correct application is selected
+* did you save after entering your URLs?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show user profile information {{{ data-action=code data-code="AccountController.cs#18:32" }}}
+
+After the middleware successfully retrieves the tokens from Auth0, it extracts the user's information and claims from the ID token and makes them available as `ClaimsIdentity`. Access the extracted information by using the `User` property on the controller.
+
+To create a user profile, retrieve a user's name, email address, and profile image from the `User` and pass it to the view from inside your controller.
+
+::::checkpoint
+
+:::checkpoint-default
+
+Now that you have set up your action to render the user's profile, run your application to verify that:
+* Navigating to your `Profile` action after being successfully logged in, shows the user's profile.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here are a couple things to double-check:
+* make sure the correct application is selected
+* make sure the domain and client ID are configured correctly
+* Did you set `openid profile email` as the scope?
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/webapp/config.yml b/ja-jp/articles/quickstart/webapp/config.yml
new file mode 100644
index 0000000000..51f64e8751
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - client
diff --git a/ja-jp/articles/quickstart/webapp/django/01-login.md b/ja-jp/articles/quickstart/webapp/django/01-login.md
new file mode 100644
index 0000000000..a137f3bf98
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/01-login.md
@@ -0,0 +1,272 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login to a Python web application built with the Django framework and Authlib OAuth library.
+budicon: 448
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - django
+github:
+    path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Python', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Create application
+
+For this guide we demonstrate how to integrate Auth0 with a Python application using the [Django framework](https://www.djangoproject.com/) and [Authlib](https://authlib.org/). Let's start by ensuring Django is installed on your system. From your shell, run the following command:
+
+```sh
+pip install django~=4.0
+```
+
+If you already have a Python application setup, you can skip to the next step. Otherwise, let's create our new application project. From your shell, run the following command, and switch to the new project folder:
+
+```sh
+django-admin startproject webappexample
+cd webappexample
+```
+
+## Install dependencies
+
+For this integration you'll need few library dependencies, such as Authlib. Go ahead and create a `requirements.txt` file in your project directory, and include the following:
+
+```python
+# 📁 requirements.txt -----
+
+authlib ~= 1.0
+django ~= 4.0
+python-dotenv ~= 0.19
+requests ~= 2.27
+```
+
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+```
+
+## Update `settings.py`
+
+You'll want to make some minor changes to your `webappexample/settings.py` file to read those `.env` values. At the top of the file, add these imports:
+
+```python
+# 📁 webappexample/settings.py -----
+
+import os
+from dotenv import load_dotenv, find_dotenv
+```
+
+Next, beneath the 'BASE_DIR' definition, add the following:
+
+```python
+# 📁 webappexample/settings.py -----
+
+# Add the following line after 'BASE_DIR = ...'
+TEMPLATE_DIR = os.path.join(BASE_DIR, "webappexample", "templates")
+```
+
+Next, find the `TEMPLATES` variable and update the `DIRS` value to add our `TEMPLATE_DIR` string. This tells Django where to look for our template files, once we create them. Keep any other content of this array the same.
+
+```python
+# 📁 webappexample/settings.py -----
+
+TEMPLATES = [
+    {
+        # Leave other lines as they are; we're just updating `DIRS`.
+        "DIRS": [TEMPLATE_DIR],
+    },
+]
+```
+
+Finally, at the end of this file, add the following:
+
+```python
+# 📁 webappexample/settings.py -----
+
+# Load environment definition file
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+
+
+# Load Auth0 application settings into memory
+AUTH0_DOMAIN = os.environ.get("AUTH0_DOMAIN")
+AUTH0_CLIENT_ID = os.environ.get("AUTH0_CLIENT_ID")
+AUTH0_CLIENT_SECRET = os.environ.get("AUTH0_CLIENT_SECRET")
+```
+
+## Setup your application
+
+Now you're ready to start writing your application. Open the `webappexample/views.py` file in your project director.
+
+Begin by importing all the libraries your application will be making use of:
+
+```python
+# 📁 webappexample/views.py -----
+
+import json
+from authlib.integrations.django_client import OAuth
+from django.conf import settings
+from django.shortcuts import redirect, render
+from django.urls import reverse
+from urllib.parse import quote_plus, urlencode
+```
+
+Now you can configure Authlib to handle your application's authentication with Auth0:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+oauth = OAuth()
+
+oauth.register(
+    "auth0",
+    client_id=settings.AUTH0_CLIENT_ID,
+    client_secret=settings.AUTH0_CLIENT_SECRET,
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f"https://{settings.AUTH0_DOMAIN}/.well-known/openid-configuration",
+)
+```
+
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your route handlers
+
+For this demonstration, we'll be adding 4 routes for your application: your login, callback, logout and index routes.
+
+### Triggering authentication with `/login`
+When visitors to your app visit the `/login` route, they'll be redirected to Auth0 to begin the authentication flow.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def login(request):
+    return oauth.auth0.authorize_redirect(
+        request, request.build_absolute_uri(reverse("callback"))
+    )
+```
+
+### Finalizing authentication with `/callback`
+After your users finish logging in with Auth0, they'll be returned to your application at the `/callback` route. This route is responsible for actually saving the session for the user, so when they visit again later, they won't have to sign back in all over again.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def callback(request):
+    token = oauth.auth0.authorize_access_token(request)
+    request.session["user"] = token
+    return redirect(request.build_absolute_uri(reverse("index")))
+```
+
+### Clearing a session with `/logout`
+As you might expect, this route handles signing a user out from your application. It will clear the user's session in your app, and briefly redirect to Auth0's logout endpoint to ensure their session is completely clear, before they are returned to your home route (covered next.)
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def logout(request):
+    request.session.clear()
+
+    return redirect(
+        f"https://{settings.AUTH0_DOMAIN}/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": request.build_absolute_uri(reverse("index")),
+                "client_id": settings.AUTH0_CLIENT_ID,
+            },
+            quote_via=quote_plus,
+        ),
+    )
+```
+
+### There's no place like `/home`
+Last but not least, your home route will serve as a place to either render an authenticated user's details, or offer to allow visitors to sign in.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your webappexample/views.py file.
+
+def index(request):
+    return render(
+        request,
+        "index.html",
+        context={
+            "session": request.session.get("user"),
+            "pretty": json.dumps(request.session.get("user"), indent=4),
+        },
+    )
+```
+
+### Register your routes
+Finally, you'll need to tell Django how to connect these new routes. Replace the contents of your `webappexample/urls.py` file with the following:
+
+```python
+# 📁 webappexample/urls.py -----
+
+from django.urls import path
+
+from . import views
+
+urlpatterns = [
+    path("", views.index, name="index"),
+    path("login", views.login, name="login"),
+    path("logout", views.logout, name="logout"),
+    path("callback", views.callback, name="callback"),
+]
+
+```
+
+## Add templates
+
+Now we just need to create the simple template files used in the routes about (during `render()` calls).
+
+Create a new sub-directory within the `webappexample` folder named `templates`, and create a `index.html` file:
+
+```html
+# 📁 webappexample/templates/index.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+    
    Welcome {{session.userinfo.name}}!
    
+    
    Logout
    
+    
    {{pretty}}
    
+    {% else %}
+    
    Welcome Guest
    
+    
    Login
    
+    {% endif %}
+  
+
+
+```
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 manage.py migrate
+python3 manage.py runserver 3000
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
diff --git a/ja-jp/articles/quickstart/webapp/django/download.md b/ja-jp/articles/quickstart/webapp/django/download.md
new file mode 100644
index 0000000000..7bc0b750da
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/download.md
@@ -0,0 +1,30 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Python](https://www.python.org/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+pip install -r requirements.txt
+python manage.py migrate 
+python manage.py runserver 3000
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/django/files/index.md b/ja-jp/articles/quickstart/webapp/django/files/index.md
new file mode 100644
index 0000000000..7daba88473
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/index.md
@@ -0,0 +1,26 @@
+---
+name: webappexample/templates/index.html
+language: html
+---
+
+
+
+```html
+
+
+  
+  Auth0 Example
+
+
+{% if session %}
+  
    Welcome {{session.userinfo.name}}!
    
+  
    Logout
    
+  
    {{pretty}}
    
+{% else %}
+  
    Welcome Guest
    
+  
    Login
    
+{% endif %}
+
+
+
+```
diff --git a/ja-jp/articles/quickstart/webapp/django/files/settings.md b/ja-jp/articles/quickstart/webapp/django/files/settings.md
new file mode 100644
index 0000000000..a944c7f58d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/settings.md
@@ -0,0 +1,37 @@
+---
+name: webappexample/settings.py
+language: python
+---
+
+
+
+```python
+import os
+from pathlib import Path
+from dotenv import load_dotenv, find_dotenv
+
+# Build paths inside the project like this: BASE_DIR / 'subdir'.
+BASE_DIR = Path(__file__).resolve().parent.parent
+TEMPLATE_DIR = os.path.join(BASE_DIR, "webappexample", "templates")
+
+# ... other settings ...
+
+TEMPLATES = [
+    {
+        # Leave other lines as they are; we're just updating `DIRS`.
+        "DIRS": [TEMPLATE_DIR],
+    },
+]
+
+# ... other settings ...
+
+# Load environment definition file
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+
+# Load Auth0 application settings into memory
+AUTH0_DOMAIN = os.environ.get("AUTH0_DOMAIN")
+AUTH0_CLIENT_ID = os.environ.get("AUTH0_CLIENT_ID")
+AUTH0_CLIENT_SECRET = os.environ.get("AUTH0_CLIENT_SECRET")
+```
diff --git a/ja-jp/articles/quickstart/webapp/django/files/urls.md b/ja-jp/articles/quickstart/webapp/django/files/urls.md
new file mode 100644
index 0000000000..2f77e379a8
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/urls.md
@@ -0,0 +1,19 @@
+---
+name: webappexample/urls.py
+language: python
+---
+
+
+
+```python
+from django.urls import path
+
+from . import views
+
+urlpatterns = [
+    path("", views.index, name="index"),
+    path("login", views.login, name="login"),
+    path("logout", views.logout, name="logout"),
+    path("callback", views.callback, name="callback"),
+]
+```
diff --git a/ja-jp/articles/quickstart/webapp/django/files/views.md b/ja-jp/articles/quickstart/webapp/django/files/views.md
new file mode 100644
index 0000000000..19da7478fe
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/files/views.md
@@ -0,0 +1,61 @@
+---
+name: webappexample/views.py
+language: python
+---
+
+
+
+```python
+import json
+from authlib.integrations.django_client import OAuth
+from django.conf import settings
+from django.shortcuts import redirect, render, redirect
+from django.urls import reverse
+from urllib.parse import quote_plus, urlencode
+
+oauth = OAuth()
+
+oauth.register(
+    "auth0",
+    client_id=settings.AUTH0_CLIENT_ID,
+    client_secret=settings.AUTH0_CLIENT_SECRET,
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f"https://{settings.AUTH0_DOMAIN}/.well-known/openid-configuration",
+)
+
+def login(request):
+    return oauth.auth0.authorize_redirect(
+        request, request.build_absolute_uri(reverse("callback"))
+    )
+
+def callback(request):
+    token = oauth.auth0.authorize_access_token(request)
+    request.session["user"] = token
+    return redirect(request.build_absolute_uri(reverse("index")))
+
+def logout(request):
+    request.session.clear()
+
+    return redirect(
+        f"https://{settings.AUTH0_DOMAIN}/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": request.build_absolute_uri(reverse("index")),
+                "client_id": settings.AUTH0_CLIENT_ID,
+            },
+            quote_via=quote_plus,
+        ),
+    )
+
+def index(request):
+    return render(
+        request,
+        "index.html",
+        context={
+            "session": request.session.get("user"),
+            "pretty": json.dumps(request.session.get("user"), indent=4),
+        },
+    )
+```
diff --git a/ja-jp/articles/quickstart/webapp/django/index.yml b/ja-jp/articles/quickstart/webapp/django/index.yml
new file mode 100644
index 0000000000..a44e0e28d1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/index.yml
@@ -0,0 +1,46 @@
+title: Django
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/python.png
+logo: python
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+snippets:
+  dependencies: server-platforms/django/dependencies
+  setup: server-platforms/django/setup
+  use: server-platforms/django/use
+seo_alias: django
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-django-web-app
+  branch: master
+requirements:
+  - Python 3
+  - Authlib 1.0
+  - Django 4.0
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/webapp/django/interactive.md b/ja-jp/articles/quickstart/webapp/django/interactive.md
new file mode 100644
index 0000000000..195f7cced0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/django/interactive.md
@@ -0,0 +1,147 @@
+---
+title: Add Login to your Django application
+description: This tutorial demonstrates how to add user login to a Django application.
+topics:
+  - quickstarts
+  - webapp
+  - django
+  - login
+github:
+  path: 01-Login
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/index
+  - files/settings
+  - files/urls
+  - files/views
+---
+
+
+
+# Add Login to Your Django Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with a Python [Django](https://www.djangoproject.com/) application using the [Authlib](https://authlib.org/) SDK.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies
+
+For this integration, you will add several library dependencies, such as Authlib. Create a `requirements.txt` file in your project directory, and include the following:
+
+```python
+# 📁 requirements.txt -----
+
+authlib ~= 1.0
+django ~= 4.0
+python-dotenv ~= 0.19
+requests ~= 2.27
+```
+
+Run the following command from your shell to make these dependencies available:
+
+```sh
+pip install -r requirements.txt
+```
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+```
+
+## Create an application
+
+If you already have a Django application setup, skip to the next step. For a new application project, run the following command:   
+
+```sh
+django-admin startproject webappexample
+```
+
+Change to the new project folder:
+
+```sh
+cd webappexample
+```
+
+## Update `settings.py` {{{ data-action=code data-code="webappexample/settings.py" }}}
+
+Open the `webappexample/settings.py` file to review the `.env` values.
+
+At the top of the file, add the `os` and `dotenv` imports.
+
+Next, beneath the `BASE_DIR` definition, add the `TEMPLATE_DIR` variable.
+
+Next, find the `TEMPLATES` variable and update the `DIRS` value to add our `TEMPLATE_DIR` string. This determines the path of the template files, which you will create in a future step.
+Keep any other content of this array the same.
+
+At the end of this file, add the code to load the Auth0 config.
+
+## Setup your application {{{ data-action=code data-code="webappexample/views.py#1:18" }}}
+
+To begin creating your application, open the `webappexample/views.py` file in your IDE.
+
+Import all the libraries your application needs.
+
+Now you can configure Authlib to handle your application's authentication with Auth0.
+
+Learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your route handlers {{{ data-action=code data-code="webappexample/views.py#21:57" }}}
+
+In this example, you will add four routes for your application: the login, callback, logout, and index routes.
+
+- `login` - When visitors to your app visit the `/login` route, they will reach Auth0 to begin the authentication flow.
+- `callback` - After your users finish logging in with Auth0, they will return to your application at the `/callback` route. This route saves the session for the user and bypasses the need for them to login again when they return.
+- `logout` - +The `/logout` route signs users out from your application. This route clears the user session in your app and redirects to the Auth0 logout endpoint to ensure the session is no longer saved. Then, the application redirects the user to your home route.
+- `index` - The home route will render an authenticated user's details or allow visitors to sign in.
+
+## Register your routes {{{ data-action=code data-code="webappexample/urls.py" }}}
+ 
+Replace the contents of your `webappexample/urls.py` file with the code on the right to connect to these new routes.
+
+This will route the `/login`, `/callback`, `/logout` and `/` routes to the correct handlers.
+
+## Add templates {{{ data-action=code data-code="webappexample/templates/index.html" }}}
+
+Next, you will create a template file used in the home page route.
+
+Create a new sub-directory within the `webappexample` folder named `templates`, and create a `index.html` file.
+
+The `index.html` file will contain template code to display the user's info if logged in or present them with a login button if logged out. 
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 manage.py migrate
+python3 manage.py runserver 3000
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
+
+::::checkpoint
+:::checkpoint-default
+Visit [http://localhost:3000](http://localhost:3000) to verify. You should find a login button routing to Auth0 for login, then back to your application to see your profile information.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify any errors in the console.
+* Verify the domain and Client ID imported correctly.
+* Verify your tenant configuration.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/webapp/express/01-login.md b/ja-jp/articles/quickstart/webapp/express/01-login.md
new file mode 100644
index 0000000000..931a1bc97c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/01-login.md
@@ -0,0 +1,117 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login, logout, and profile to a Node.js Express application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - user profile
+  - logout
+  - nodejs
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+
+
+## Configure Auth0
+
+You will need to register your application with Auth0 in order to start authenticating users. Go to the [Applications](${manage_url}/#/applications) screen in the Auth0 dashboard, create a new **Regular Web Application**, and follow the steps below.
+
+### 1. Configure Callback URL
+
+A callback URL is an application route where Auth0 redirects users after they have authenticated. This URL must be registered with Auth0 or else users will be unable to log in to the application and will get a "Callback URL mismatch" error.
+
+The callback URL for the application created in this quickstart is `http://localhost:3000/callback`. Paste that in the **Allowed Callback URLs** field for the application you just created.
+
+### 2. Configure Logout URL
+
+A logout URL is an application route that Auth0 can return users to after logging out. This URL must be registered with Auth0 or else users will be unable to log out of the application and will get a "misconfiguration" error.
+
+The logout URL for the application created in this quickstart is `http://localhost:3000`. Paste that in the **Allowed Logout URLs** field for the application you just created, then scroll down and click **Save Changes**.
+
+### 3. Get Your Application Keys
+
+Finally, copy the following fields for your application for use in step 7:
+
+* **Domain**
+* **Client ID**
+
+## Integrate Auth0
+### 4. Install Dependencies
+Your application will need the [`express-openid-connect`](https://github.com/auth0/express-openid-connect) package which is an Auth0-maintained OIDC-compliant library for Express.
+
+```sh
+npm install express express-openid-connect --save
+```
+
+### 5. Configure Router
+The Express OpenID Connect library provides the `auth` router in order to attach authentication routes to your application. You will need to configure the router with the following configuration keys:
+
+- `authRequired` - Controls whether authentication is required for all routes
+- `auth0Logout` - Uses Auth0 logout feature
+- `baseURL` - The URL where the application is served
+- `secret` - A long, random string used to encrypt the session cookie
+- `issuerBaseURL`  - The Domain as a secure URL found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+- `clientID` - The Client ID found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+Here is an example configuration using this router:
+
+```js
+const { auth } = require('express-openid-connect');
+
+const config = {
+  authRequired: false,
+  auth0Logout: true,
+  baseURL: 'http://localhost:3000',
+  clientID: '${account.clientId}',
+  issuerBaseURL: 'https://${account.namespace}',
+  secret: 'LONG_RANDOM_STRING'
+};
+
+// auth router attaches /login, /logout, and /callback routes to the baseURL
+app.use(auth(config));
+
+// req.isAuthenticated is provided from the auth router
+app.get('/', (req, res) => {
+  res.send(req.oidc.isAuthenticated() ? 'Logged in' : 'Logged out')
+});
+```
+
+For additional configuration options visit the [API documentation](https://auth0.github.io/express-openid-connect).
+
+:::note
+You can generate a suitable string for `LONG_RANDOM_STRING` using `openssl rand -hex 32` on the command line.
+:::
+
+## Login
+A user can now log into your application by visiting the `/login` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/login`](http://localhost:3000/login).
+
+## Display User Profile
+To display the user's profile, your application should provide a protected route.
+
+Add the `requiresAuth` middleware for routes that require authentication.  Any route using this middleware will check for a valid user session and, if one does not exist, it will redirect the user to log in.
+
+```js
+const { requiresAuth } = require('express-openid-connect');
+
+app.get('/profile', requiresAuth(), (req, res) => {
+  res.send(JSON.stringify(req.oidc.user));
+});
+```
+
+## Logout
+A user can log out of your application by visiting the `/logout` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/logout`](http://localhost:3000/logout).
+
+:::note
+For a deep dive into implementing user authentication in Express, visit the [Complete Guide to Node.js User Authentication with Auth0](https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/). This guide provides you with additional details, such as creating a signup button, protecting routes, and making secure calls to an API. 
+:::
+
+## What's next?
+We put together a few examples of how to use [Express OpenID Connect](https://github.com/auth0/express-openid-connect) in more advanced use cases:
+
+* [Route Customization](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#3-route-customization)
+* [Obtaining access tokens for external APIs](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#4-obtaining-access-tokens-to-call-external-apis)
+* [Require auth for specific routes](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#2-require-authentication-for-specific-routes)
diff --git a/ja-jp/articles/quickstart/webapp/express/download.md b/ja-jp/articles/quickstart/webapp/express/download.md
new file mode 100644
index 0000000000..306c9694cd
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample's directory:
+
+```bash
+npm install
+npm start
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/express/files/server.md b/ja-jp/articles/quickstart/webapp/express/files/server.md
new file mode 100644
index 0000000000..5c890e082f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/files/server.md
@@ -0,0 +1,41 @@
+---
+name: server.js
+language: javascript
+---
+
+
+
+```javascript
+const express = require('express');
+const { auth, requiresAuth } = require('express-openid-connect');
+const app = express();
+
+const config = {
+  authRequired: false,
+  auth0Logout: true,
+  baseURL: 'http://localhost:3000',
+  clientID: '${account.clientId}',
+  issuerBaseURL: 'https://${account.namespace}',
+  secret: 'LONG_RANDOM_STRING'
+};
+
+// The `auth` router attaches /login, /logout
+// and /callback routes to the baseURL
+app.use(auth(config));
+
+// req.oidc.isAuthenticated is provided from the auth router
+app.get('/', (req, res) => {
+  res.send(
+    req.oidc.isAuthenticated() ? 'Logged in' : 'Logged out'
+  )
+});
+
+// The /profile route will show the user profile as JSON
+app.get('/profile', requiresAuth(), (req, res) => {
+  res.send(JSON.stringify(req.oidc.user, null, 2));
+});
+
+app.listen(3000, function() {
+  console.log('Listening on http://localhost:3000');
+});
+```
diff --git a/ja-jp/articles/quickstart/webapp/express/index.yml b/ja-jp/articles/quickstart/webapp/express/index.yml
new file mode 100644
index 0000000000..9c819b80d0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/index.yml
@@ -0,0 +1,33 @@
+title: Express
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/node.png
+logo: javascript
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+alias:
+  - node
+  - express
+seo_alias: express
+logo_name: nodejs
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+github:
+  org: auth0-samples
+  repo: auth0-express-webapp-sample
+  branch: master
+sdk:
+  name: express-openid-connect
+  url: https://github.com/auth0/express-openid-connect
+  logo: javascript
+requirements:
+  - NodeJS 10.13+
+  - Express 4.17+
diff --git a/ja-jp/articles/quickstart/webapp/express/interactive.md b/ja-jp/articles/quickstart/webapp/express/interactive.md
new file mode 100644
index 0000000000..ea056cdc19
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,97 @@
+---
+title: Add Login to your Express App
+description: "Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add user login, logout, and profile to a Node.js Express application using the Express OpenID Connect SDK."
+interactive: true
+files:
+- files/server
+github:
+  path: 01-Login
+---
+
+
+
+# Add Login to Your Express Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add user login, logout, and profile to a Node.js Express application using the Express OpenID Connect SDK.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/callback.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/logout.
+:::
+
+## Install the Express OpenID Connect SDK {{{ data-action=code data-code="server.js#3:10" }}}
+
+Your application will need the [`express-openid-connect`](https://github.com/auth0/express-openid-connect) package which is an Auth0-maintained OIDC-compliant SDK for Express.
+
+Install the Express OpenID Connect SDK by running the following commands in your terminal:
+
+```bash
+cd 
+npm install express-openid-connect
+```
+
+### Configure Router
+The Express OpenID Connect library provides the `auth` router in order to attach authentication routes to your application. You will need to configure the router with the following configuration keys:
+
+- `authRequired` - Controls whether authentication is required for all routes
+- `auth0Logout` - Uses Auth0 logout feature
+- `baseURL` - The URL where the application is served
+- `secret` - A long, random string
+- `issuerBaseURL`  - The Domain as a secure URL found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+- `clientID` - The Client ID found in your [Application settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+For additional configuration options visit the [API documentation](https://auth0.github.io/express-openid-connect).
+
+:::note
+You can generate a suitable string for `LONG_RANDOM_STRING` using `openssl rand -hex 32` on the command line.
+:::
+
+::::checkpoint
+:::checkpoint-default
+A user can now log into your application by visiting the `/login` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/login`](http://localhost:3000/login).
+:::
+:::checkpoint-failure
+Sorry about that. You should check the error details on the Auth0 login page to make sure you have entered the callback URL correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Display User Profile {{{ data-action=code data-code="server.js#29:32" }}}
+To display the user's profile, your application should provide a protected route.
+
+Add the `requiresAuth` middleware for routes that require authentication.  Any route using this middleware will check for a valid user session and, if one does not exist, it will redirect the user to log in.
+
+::::checkpoint
+:::checkpoint-default
+A user can log out of your application by visiting the `/logout` route provided by the library. If you are running your project on `localhost:3000` that link would be [`http://localhost:3000/logout`](http://localhost:3000/logout).
+:::
+:::checkpoint-failure
+Sorry about that. You should check that you configured the logout URL correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/webapp/golang/01-login.md b/ja-jp/articles/quickstart/webapp/golang/01-login.md
new file mode 100644
index 0000000000..b2600c857b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/01-login.md
@@ -0,0 +1,500 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Go web application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - golang
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Go', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Configure Go to Use Auth0
+
+### Download dependencies
+
+Start by adding a `go.mod` file to list all the dependencies to be used.
+
+```text
+// go.mod
+
+module 01-Login
+
+go 1.21
+
+require (
+	github.com/coreos/go-oidc/v3 v3.8.0
+	github.com/gin-contrib/sessions v0.0.5
+	github.com/gin-gonic/gin v1.9.1
+	github.com/joho/godotenv v1.5.1
+	golang.org/x/oauth2 v0.15.0
+)
+```
+
+We can now make the dependencies available for us by running the following shell command:
+
+```shell
+go mod download
+```
+
+::: note
+This example uses `gin` for routing, but you can use whichever router you want.
+:::
+
+
+### Configure your application
+
+Create a `.env` file within the root of your project directory to store the app configuration, and fill in the 
+environment variables:
+
+```sh
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# The Callback URL of our application.
+AUTH0_CALLBACK_URL='http://localhost:3000/callback'
+```
+
+### Configure OAuth2 and OpenID Connect packages
+
+Create a file called `auth.go` in the `platform/authenticator` folder. In this package you'll create a method to 
+configure and return [OAuth2](https://godoc.org/golang.org/x/oauth2) and 
+[oidc](https://godoc.org/github.com/coreos/go-oidc) clients, and another one to verify an ID Token.
+
+```go
+// platform/authenticator/auth.go
+
+package authenticator
+
+import (
+	"context"
+	"errors"
+	"os"
+
+	"github.com/coreos/go-oidc/v3/oidc"
+	"golang.org/x/oauth2"
+)
+
+// Authenticator is used to authenticate our users.
+type Authenticator struct {
+	*oidc.Provider
+	oauth2.Config
+}
+
+// New instantiates the *Authenticator.
+func New() (*Authenticator, error) {
+	provider, err := oidc.NewProvider(
+		context.Background(),
+		"https://"+os.Getenv("AUTH0_DOMAIN")+"/",
+	)
+	if err != nil {
+		return nil, err
+	}
+
+	conf := oauth2.Config{
+		ClientID:     os.Getenv("AUTH0_CLIENT_ID"),
+		ClientSecret: os.Getenv("AUTH0_CLIENT_SECRET"),
+		RedirectURL:  os.Getenv("AUTH0_CALLBACK_URL"),
+		Endpoint:     provider.Endpoint(),
+		Scopes:       []string{oidc.ScopeOpenID, "profile"},
+	}
+
+	return &Authenticator{
+		Provider: provider,
+		Config:   conf,
+	}, nil
+}
+
+// VerifyIDToken verifies that an *oauth2.Token is a valid *oidc.IDToken.
+func (a *Authenticator) VerifyIDToken(ctx context.Context, token *oauth2.Token) (*oidc.IDToken, error) {
+	rawIDToken, ok := token.Extra("id_token").(string)
+	if !ok {
+		return nil, errors.New("no id_token field in oauth2 token")
+	}
+
+	oidcConfig := &oidc.Config{
+		ClientID: a.ClientID,
+	}
+
+	return a.Verifier(oidcConfig).Verify(ctx, rawIDToken)
+}
+```
+
+### Setting up your application routes
+
+Create a file called `router.go` in the `platform/router` folder. In this package you'll create a method to configure
+and return our routes using [github.com/gin-gonic/gin](https://github.com/gin-gonic/gin). You will be passing an
+instance of `Authenticator` to the method, so it can be used within the `login` and `callback` handlers.
+
+```go
+// platform/router/router.go
+
+package router
+
+import (
+	"encoding/gob"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-contrib/sessions/cookie"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/middleware"
+	"01-Login/web/app/callback"
+	"01-Login/web/app/login"
+	"01-Login/web/app/logout"
+	"01-Login/web/app/user"
+)
+
+// New registers the routes and returns the router.
+func New(auth *authenticator.Authenticator) *gin.Engine {
+	router := gin.Default()
+
+	// To store custom types in our cookies,
+	// we must first register them using gob.Register
+	gob.Register(map[string]interface{}{})
+
+	store := cookie.NewStore([]byte("secret"))
+	router.Use(sessions.Sessions("auth-session", store))
+
+	router.Static("/public", "web/static")
+	router.LoadHTMLGlob("web/template/*")
+
+	router.GET("/", func(ctx *gin.Context) {
+		ctx.HTML(http.StatusOK, "home.html", nil)
+	})
+	router.GET("/login", login.Handler(auth))
+	router.GET("/callback", callback.Handler(auth))
+	router.GET("/user", user.Handler)
+	router.GET("/logout", logout.Handler)
+
+	return router
+}
+```
+
+::: note
+The router uses the [github.com/gin-contrib/sessions](https://github.com/gin-contrib/sessions) middleware to manage 
+our cookie based sessions.
+:::
+
+### Serving your application
+
+Next, let's create our application's entry point `main.go` and wire everything up together:
+
+```go
+// main.go
+
+package main
+
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/router"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Failed to load the env vars: %v", err)
+	}
+
+	auth, err := authenticator.New()
+	if err != nil {
+		log.Fatalf("Failed to initialize the authenticator: %v", err)
+	}
+
+	rtr := router.New(auth)
+
+	log.Print("Server listening on http://localhost:3000/")
+	if err := http.ListenAndServe("0.0.0.0:3000", rtr); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+```
+
+## Logging In
+
+Create a file called `login.go` in the `web/app/login` folder, and add a `Handler` function to handle the `/login`
+route.
+
+```go
+// web/app/login/login.go
+
+package login
+
+import (
+	"crypto/rand"
+	"encoding/base64"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our login.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		state, err := generateRandomState()
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Save the state inside the session.
+		session := sessions.Default(ctx)
+		session.Set("state", state)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		ctx.Redirect(http.StatusTemporaryRedirect, auth.AuthCodeURL(state))
+	}
+}
+
+func generateRandomState() (string, error) {
+	b := make([]byte, 32)
+	_, err := rand.Read(b)
+	if err != nil {
+		return "", err
+	}
+
+	state := base64.StdEncoding.EncodeToString(b)
+
+	return state, nil
+}
+```
+
+Add a link to `/login` route in the `home.html` template.
+
+```html
+
+
+
    
+    
    Auth0 Example
    
+    
    Zero friction identity infrastructure, built for developers
    
+    SignIn
+
    
+```
+
+## Handling Authentication Callback
+
+Once users have authenticated using Auth0's Universal Login Page, they'll return to the app at the `/callback`
+route that will be handled in the following `Handler` function:
+
+```go
+// web/app/callback/callback.go
+
+package callback
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our callback.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		session := sessions.Default(ctx)
+		if ctx.Query("state") != session.Get("state") {
+			ctx.String(http.StatusBadRequest, "Invalid state parameter.")
+			return
+		}
+
+		// Exchange an authorization code for a token.
+		token, err := auth.Exchange(ctx.Request.Context(), ctx.Query("code"))
+		if err != nil {
+			ctx.String(http.StatusUnauthorized, "Failed to exchange an authorization code for a token.")
+			return
+		}
+
+		idToken, err := auth.VerifyIDToken(ctx.Request.Context(), token)
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, "Failed to verify ID Token.")
+			return
+		}
+
+		var profile map[string]interface{}
+		if err := idToken.Claims(&profile); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		session.Set("access_token", token.AccessToken)
+		session.Set("profile", profile)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Redirect to logged in page.
+		ctx.Redirect(http.StatusTemporaryRedirect, "/user")
+	}
+}
+```
+
+## Displaying User Information
+
+You can access the user information via the `profile` you stored in the session previously.
+
+```go
+// web/app/user/user.go
+
+package user
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logged-in user page.
+func Handler(ctx *gin.Context) {
+	session := sessions.Default(ctx)
+	profile := session.Get("profile")
+
+	ctx.HTML(http.StatusOK, "user.html", profile)
+}
+```
+
+```html
+
+
+
    
+    
+    
    Welcome {{.nickname}}
    
+
    
+```
+
+For information about the userinfo hash, see [User Profile](/users/concepts/overview-user-profile).
+
+## Logging Out
+
+To log the user out, clear the data from the session and redirect the user to the Auth0 logout endpoint. You can find
+more information about this in the [logout documentation](/logout).
+
+Create a file called `logout.go` in the folder `web/app/logout/logout.go`, and add the function `Handler` to redirect
+the user to Auth0's logout endpoint.
+
+```go
+// web/app/logout/logout.go
+
+package logout
+
+import (
+	"net/http"
+	"net/url"
+	"os"
+
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logout.
+func Handler(ctx *gin.Context) {
+	logoutUrl, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/v2/logout")
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	scheme := "http"
+	if ctx.Request.TLS != nil {
+		scheme = "https"
+	}
+
+	returnTo, err := url.Parse(scheme + "://" + ctx.Request.Host)
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	parameters := url.Values{}
+	parameters.Add("returnTo", returnTo.String())
+	parameters.Add("client_id", os.Getenv("AUTH0_CLIENT_ID"))
+	logoutUrl.RawQuery = parameters.Encode()
+
+	ctx.Redirect(http.StatusTemporaryRedirect, logoutUrl.String())
+}
+```
+
+::: note
+The redirect URL needs to be in the list of Allowed Logout URLs in the settings section of the application, For more information, see [Redirect Users After Logout](/logout/guides/redirect-users-after-logout).
+:::
+
+Create a file called `user.js` in the folder `web/static/js`, and add the code to remove the cookie from a logged-in
+user.
+
+```js
+$(document).ready(function () {
+    $('.btn-logout').click(function (e) {
+        Cookies.remove('auth-session');
+    });
+});
+```
+
+::: note
+This sample is using [js.cookie](https://github.com/js-cookie/js-cookie/tree/latest#readme) for cookie handling. 
+You need to add the `js.cookie.js` file to the `web/static/js` folder to use it.
+:::
+
+## Optional Steps
+
+### Checking if the user is authenticated
+
+Create a middleware that will check if the user is authenticated or not based on the `profile` session key:
+
+```go
+// platform/middleware/isAuthenticated.go
+
+package middleware
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// IsAuthenticated is a middleware that checks if
+// the user has already been authenticated previously.
+func IsAuthenticated(ctx *gin.Context) {
+	if sessions.Default(ctx).Get("profile") == nil {
+		ctx.Redirect(http.StatusSeeOther, "/")
+	} else {
+		ctx.Next()
+	}
+}
+```
+
+Finally, set up this middleware for any route that needs authentication by adding it to the router.
+
+```go
+// platform/router/router.go
+
+router.GET("/user", middleware.IsAuthenticated, user.Handler)
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/download.md b/ja-jp/articles/quickstart/webapp/golang/download.md
new file mode 100644
index 0000000000..fe4094c085
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure [Go](https://golang.org/dl/) is installed and execute the following commands in the sample's directory:
+
+```bash
+go mod vendor
+go run main.go
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/auth.md b/ja-jp/articles/quickstart/webapp/golang/files/auth.md
new file mode 100644
index 0000000000..023e58723d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/auth.md
@@ -0,0 +1,63 @@
+---
+name: auth.go
+language: go
+---
+
+```go
+// Save this file in ./platform/authenticator/auth.go
+
+package authenticator
+
+import (
+	"context"
+	"errors"
+	"os"
+
+	"github.com/coreos/go-oidc/v3/oidc"
+	"golang.org/x/oauth2"
+)
+
+// Authenticator is used to authenticate our users.
+type Authenticator struct {
+	*oidc.Provider
+	oauth2.Config
+}
+
+// New instantiates the *Authenticator.
+func New() (*Authenticator, error) {
+	provider, err := oidc.NewProvider(
+		context.Background(),
+		"https://"+os.Getenv("AUTH0_DOMAIN")+"/",
+	)
+	if err != nil {
+		return nil, err
+	}
+
+	conf := oauth2.Config{
+		ClientID:     os.Getenv("AUTH0_CLIENT_ID"),
+		ClientSecret: os.Getenv("AUTH0_CLIENT_SECRET"),
+		RedirectURL:  os.Getenv("AUTH0_CALLBACK_URL"),
+		Endpoint:     provider.Endpoint(),
+		Scopes:       []string{oidc.ScopeOpenID, "profile"},
+	}
+
+	return &Authenticator{
+		Provider: provider,
+		Config:   conf,
+	}, nil
+}
+
+// VerifyIDToken verifies that an *oauth2.Token is a valid *oidc.IDToken.
+func (a *Authenticator) VerifyIDToken(ctx context.Context, token *oauth2.Token) (*oidc.IDToken, error) {
+	rawIDToken, ok := token.Extra("id_token").(string)
+	if !ok {
+		return nil, errors.New("no id_token field in oauth2 token")
+	}
+
+	oidcConfig := &oidc.Config{
+		ClientID: a.ClientID,
+	}
+
+	return a.Verifier(oidcConfig).Verify(ctx, rawIDToken)
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/callback.md b/ja-jp/articles/quickstart/webapp/golang/files/callback.md
new file mode 100644
index 0000000000..8d8e0b2795
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/callback.md
@@ -0,0 +1,59 @@
+---
+name: callback.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/callback/callback.go
+
+package callback
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our callback.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		session := sessions.Default(ctx)
+		if ctx.Query("state") != session.Get("state") {
+			ctx.String(http.StatusBadRequest, "Invalid state parameter.")
+			return
+		}
+
+		// Exchange an authorization code for a token.
+		token, err := auth.Exchange(ctx.Request.Context(), ctx.Query("code"))
+		if err != nil {
+			ctx.String(http.StatusUnauthorized, "Failed to exchange an authorization code for a token.")
+			return
+		}
+
+		idToken, err := auth.VerifyIDToken(ctx.Request.Context(), token)
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, "Failed to verify ID Token.")
+			return
+		}
+
+		var profile map[string]interface{}
+		if err := idToken.Claims(&profile); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		session.Set("access_token", token.AccessToken)
+		session.Set("profile", profile)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Redirect to logged in page.
+		ctx.Redirect(http.StatusTemporaryRedirect, "/user")
+	}
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/env.md b/ja-jp/articles/quickstart/webapp/golang/files/env.md
new file mode 100644
index 0000000000..a7ef95a380
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/env.md
@@ -0,0 +1,21 @@
+---
+name: .env
+language: shell
+---
+
+```shell
+# Save this file in ./.env
+
+# The URL of our Auth0 Tenant Domain.
+# If you're using a Custom Domain, be sure to set this to that value instead.
+AUTH0_DOMAIN='${account.namespace}'
+
+# Our Auth0 application's Client ID.
+AUTH0_CLIENT_ID='${account.clientId}'
+
+# Our Auth0 application's Client Secret.
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+
+# The Callback URL of our application.
+AUTH0_CALLBACK_URL='http://localhost:3000/callback'
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/go-mod.md b/ja-jp/articles/quickstart/webapp/golang/files/go-mod.md
new file mode 100644
index 0000000000..636aa7c45f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/go-mod.md
@@ -0,0 +1,20 @@
+---
+name: go.mod
+language: go-mod
+---
+
+```go-mod
+// Save this file in ./go.mod
+
+module 01-Login
+
+go 1.21
+
+require (
+	github.com/coreos/go-oidc/v3 v3.8.0
+	github.com/gin-contrib/sessions v0.0.5
+	github.com/gin-gonic/gin v1.9.1
+	github.com/joho/godotenv v1.5.1
+	golang.org/x/oauth2 v0.15.0
+)
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/isAuthenticated.md b/ja-jp/articles/quickstart/webapp/golang/files/isAuthenticated.md
new file mode 100644
index 0000000000..810973aae3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/isAuthenticated.md
@@ -0,0 +1,27 @@
+---
+name: isAuthenticated.go
+language: go
+---
+
+```go
+// Save this file in ./platform/middleware/isAuthenticated.go
+
+package middleware
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// IsAuthenticated is a middleware that checks if
+// the user has already been authenticated previously.
+func IsAuthenticated(ctx *gin.Context) {
+	if sessions.Default(ctx).Get("profile") == nil {
+		ctx.Redirect(http.StatusSeeOther, "/")
+	} else {
+		ctx.Next()
+	}
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/login.md b/ja-jp/articles/quickstart/webapp/golang/files/login.md
new file mode 100644
index 0000000000..06dee8ad5e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/login.md
@@ -0,0 +1,54 @@
+---
+name: login.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/login/login.go
+
+package login
+
+import (
+	"crypto/rand"
+	"encoding/base64"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+)
+
+// Handler for our login.
+func Handler(auth *authenticator.Authenticator) gin.HandlerFunc {
+	return func(ctx *gin.Context) {
+		state, err := generateRandomState()
+		if err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		// Save the state inside the session.
+		session := sessions.Default(ctx)
+		session.Set("state", state)
+		if err := session.Save(); err != nil {
+			ctx.String(http.StatusInternalServerError, err.Error())
+			return
+		}
+
+		ctx.Redirect(http.StatusTemporaryRedirect, auth.AuthCodeURL(state))
+	}
+}
+
+func generateRandomState() (string, error) {
+	b := make([]byte, 32)
+	_, err := rand.Read(b)
+	if err != nil {
+		return "", err
+	}
+
+	state := base64.StdEncoding.EncodeToString(b)
+
+	return state, nil
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/logout.md b/ja-jp/articles/quickstart/webapp/golang/files/logout.md
new file mode 100644
index 0000000000..09d04f27ee
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/logout.md
@@ -0,0 +1,45 @@
+---
+name: logout.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/logout/logout.go
+
+package logout
+
+import (
+	"net/http"
+	"net/url"
+	"os"
+
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logout.
+func Handler(ctx *gin.Context) {
+	logoutUrl, err := url.Parse("https://" + os.Getenv("AUTH0_DOMAIN") + "/v2/logout")
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	scheme := "http"
+	if ctx.Request.TLS != nil {
+		scheme = "https"
+	}
+
+	returnTo, err := url.Parse(scheme + "://" + ctx.Request.Host)
+	if err != nil {
+		ctx.String(http.StatusInternalServerError, err.Error())
+		return
+	}
+
+	parameters := url.Values{}
+	parameters.Add("returnTo", returnTo.String())
+	parameters.Add("client_id", os.Getenv("AUTH0_CLIENT_ID"))
+	logoutUrl.RawQuery = parameters.Encode()
+
+	ctx.Redirect(http.StatusTemporaryRedirect, logoutUrl.String())
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/main.md b/ja-jp/articles/quickstart/webapp/golang/files/main.md
new file mode 100644
index 0000000000..ecce4e6b5d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/main.md
@@ -0,0 +1,38 @@
+---
+name: main.go
+language: go
+---
+
+```go
+// Save this file in ./main.go
+
+package main
+
+import (
+	"log"
+	"net/http"
+
+	"github.com/joho/godotenv"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/router"
+)
+
+func main() {
+	if err := godotenv.Load(); err != nil {
+		log.Fatalf("Failed to load the env vars: %v", err)
+	}
+
+	auth, err := authenticator.New()
+	if err != nil {
+		log.Fatalf("Failed to initialize the authenticator: %v", err)
+	}
+
+	rtr := router.New(auth)
+
+	log.Print("Server listening on http://localhost:3000/")
+	if err := http.ListenAndServe("0.0.0.0:3000", rtr); err != nil {
+		log.Fatalf("There was an error with the http server: %v", err)
+	}
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/router.md b/ja-jp/articles/quickstart/webapp/golang/files/router.md
new file mode 100644
index 0000000000..2da2fa8e5b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/router.md
@@ -0,0 +1,51 @@
+---
+name: router.go
+language: go
+---
+
+```go
+// Save this file in ./platform/router/router.go
+
+package router
+
+import (
+	"encoding/gob"
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-contrib/sessions/cookie"
+	"github.com/gin-gonic/gin"
+
+	"01-Login/platform/authenticator"
+	"01-Login/platform/middleware"
+	"01-Login/web/app/callback"
+	"01-Login/web/app/login"
+	"01-Login/web/app/logout"
+	"01-Login/web/app/user"
+)
+
+// New registers the routes and returns the router.
+func New(auth *authenticator.Authenticator) *gin.Engine {
+	router := gin.Default()
+
+	// To store custom types in our cookies,
+	// we must first register them using gob.Register
+	gob.Register(map[string]interface{}{})
+
+	store := cookie.NewStore([]byte("secret"))
+	router.Use(sessions.Sessions("auth-session", store))
+
+	router.Static("/public", "web/static")
+	router.LoadHTMLGlob("web/template/*")
+
+	router.GET("/", func(ctx *gin.Context) {
+		ctx.HTML(http.StatusOK, "home.html", nil)
+	})
+	router.GET("/login", login.Handler(auth))
+	router.GET("/callback", callback.Handler(auth))
+	router.GET("/user", user.Handler)
+	router.GET("/logout", logout.Handler)
+
+	return router
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/files/user.md b/ja-jp/articles/quickstart/webapp/golang/files/user.md
new file mode 100644
index 0000000000..5bae0dcfa2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/files/user.md
@@ -0,0 +1,25 @@
+---
+name: user.go
+language: go
+---
+
+```go
+// Save this file in ./web/app/user/user.go
+
+package user
+
+import (
+	"net/http"
+
+	"github.com/gin-contrib/sessions"
+	"github.com/gin-gonic/gin"
+)
+
+// Handler for our logged-in user page.
+func Handler(ctx *gin.Context) {
+	session := sessions.Default(ctx)
+	profile := session.Get("profile")
+
+	ctx.HTML(http.StatusOK, "user.html", profile)
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/golang/index.yml b/ja-jp/articles/quickstart/webapp/golang/index.yml
new file mode 100644
index 0000000000..38a4052a43
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/index.yml
@@ -0,0 +1,44 @@
+title: Go
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/golang.png
+logo: golang
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Sergiu Ghitea
+  email: sergiu.ghitea@auth0.com
+  community: false
+snippets:
+  dependencies: server-platforms/golang/dependencies
+  setup: server-platforms/golang/setup
+  use: server-platforms/golang/use
+seo_alias: golang
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-golang-web-app
+  branch: master
+requirements:
+  - Go 1.21+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/webapp/golang/interactive.md b/ja-jp/articles/quickstart/webapp/golang/interactive.md
new file mode 100644
index 0000000000..28a401da07
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,183 @@
+---
+title: Add Login to your Go web application
+description: This tutorial demonstrates how to add user login to a Go web application using Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - golang
+github:
+  path: 01-Login
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/auth
+  - files/callback
+  - files/env
+  - files/go-mod
+  - files/isAuthenticated
+  - files/login
+  - files/logout
+  - files/main
+  - files/router
+  - files/user
+---
+
+# Add Login to Your Go Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Go web application.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies {{{ data-action=code data-code="go.mod" }}}
+
+Create a `go.mod` file to list all the dependencies in your application. 
+
+To integrate Auth0 in a Go application, add the`coreos/go-oidc/v3` and `x/oauth2` packages. 
+
+In addition to the OIDC and OAuth2 packages, add`joho/godotenv`, `gin-gonic/gin` and `gin-contrib/sessions`.
+
+::: note
+This example uses `gin` for routing, but you can use whichever router you want.
+:::
+
+Save the `go.mod` file with the necessary dependencies and install them using the following command in your terminal:
+
+```shell
+go mod download
+```
+
+## Configure the environment variables {{{ data-action=code data-code=".env" }}}
+You must set the following environment variables in `.env` within the root of your project directory:
+
+- **AUTH0_DOMAIN**: The domain of your Auth0 tenant. Find your Auth0 Domain in the Auth0 Dashboard under your Application's Settings in the Domain field. For [custom domains](https://auth0.com/docs/custom-domains), set this to the value of your custom domain instead.
+- **AUTH0_CLIENT_ID**: The ID of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- **AUTH0_CLIENT_SECRET**: The Secret of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client Secret field.
+- **AUTH0_CALLBACK_URL**: The URL used by Auth0 to redirect the user after successful authentication.
+
+## Configure OAuth2 and OpenID Connect packages {{{ data-action=code data-code="auth.go" }}}
+
+Next, configure the OAuth2 and OpenID Connect packages.
+
+Create a file called `auth.go` in the `platform/authenticator` folder. In this package, create a method to 
+configure and return [OAuth2](https://godoc.org/golang.org/x/oauth2) and 
+[OIDC](https://godoc.org/github.com/coreos/go-oidc) clients, and another one to verify an ID Token.
+
+## Set up your application routes {{{ data-action=code data-code="router.go" }}}
+
+Create a file called `router.go` in the `platform/router` folder. In this package, create a method to configure
+and return our routes using [github.com/gin-gonic/gin](https://github.com/gin-gonic/gin). You will be passing an
+instance of `Authenticator` to the method, for use with the `login` and `callback` handlers.
+
+::: note
+The router uses the [github.com/gin-contrib/sessions](https://github.com/gin-contrib/sessions) middleware to manage our cookie-based sessions.
+:::
+
+## Add login to your application {{{ data-action=code data-code="login.go" }}}
+
+For the user to authenticate themselves, we need to create a handler function to handle the `/login` route.
+
+Create a file called `login.go` in the `web/app/login` folder, and add a `Handler` function. Upon executing the handler, the user will be redirected to Auth0 where they can enter their credentials.
+
+To call the `/login` route, add a link to `/login` in the `home.html` template located in the `web/template` directory.
+
+```html
+
+
+
    
+    
    Auth0 Example
    
+    
    Zero friction identity infrastructure, built for developers
    
+    SignIn
+
    
+```
+
+## Handle authentication callback {{{ data-action=code data-code="callback.go" }}}
+
+Once users have authenticated using Auth0's Universal Login Page, they will return to the app at the `/callback` route.
+
+Create a file called `callback.go` in the `web/app/callback` folder, and add a `Handler` function.
+
+This handler will take the `code` query string, provided by Auth0, and exchange it for an ID token and an access token.
+
+If the ID token is valid, it will store the profile information and access token in the session. The profile information is based on the claims contained in the ID token. Session storage allows the application to access that information as needed.
+
+## Display user profile information {{{ data-action=code data-code="user.go" }}}
+
+Now that your users can log in, you will likely want to be able to retrieve and use the [profile information](/users/concepts/overview-user-profile) associated with authenticated users. 
+
+You can access that [profile information](/users/concepts/overview-user-profile), such as their nickname or profile picture, through the `profile` that was stored in the session previously.
+
+Create a handler for the `/user` endpoint in `web/app/user/user.go` and return the corresponding HTML file. As the `profile` is being passed to `ctx.HTML()`, you can access the profile information such as `picture` and `nickname` inside that same HTML file. 
+
+An example of such an HTML file could look like the example below, but you can retrieve any [profile information](/users/concepts/overview-user-profile), including custom claims.
+
+```html
+
+
+
    
+    
+    
    Welcome {{.nickname}}
    
+
    
+```
+
+## Add logout to your application {{{ data-action=code data-code="logout.go" }}}
+
+To log the user out, clear the data from the session and redirect the user to the Auth0 logout endpoint. You can find more information about this in the [logout documentation](/logout).
+
+Create a file called `logout.go` in the folder `web/app/logout`, and add the function `Handler` to redirect the user to Auth0's logout endpoint.
+
+::: note
+The `returnTo` URL needs to be in the list of Allowed Logout URLs in the settings section of the application, For more information, see [Redirect Users After Logout](/logout/guides/redirect-users-after-logout).
+:::
+
+Create a file called `user.js` in the folder `web/static/js`, and add the code to remove the cookie from a logged-in
+user.
+
+```js
+// Save this within ./web/static/js/user.js
+
+$(document).ready(function () {
+    $('.btn-logout').click(function (e) {
+        Cookies.remove('auth-session');
+    });
+});
+```
+
+::: note
+This sample is using [js.cookie](https://github.com/js-cookie/js-cookie/tree/latest#readme) for cookie handling. 
+You need to add the `js.cookie.js` file to the `web/static/js` folder to use it.
+:::
+
+## Protect routes {{{ data-action=code data-code="isAuthenticated.go" }}}
+
+Recommended practice dictates certain routes are accessible only to authenticated users. When unauthenticated users try accessing protected routes, your application should redirect them.
+
+In this case, you will implement middleware to hook into the HTTP request. The middleware function determines if the request should route to the endpoint handler or block the request.
+
+Create a file called `isAuthenticated.go` in `platform/middleware` and add a function that checks if the user is authenticated or not based on the `profile` session key. If the user is not authenticated, the middleware will redirect the user to the root of the application.
+
+With the middleware created, we can set it up for any route that needs authentication by adding it to the router.
+
+```go
+// This goes within ./platform/router/router.go
+
+router.GET("/user", middleware.IsAuthenticated, user.Handler)
+```
+
+## Serve your application {{{ data-action=code data-code="main.go" }}}
+
+With both the authenticator and router configured, we can wire things up using our
+application's entry point. Inside `main.go`, create an instance of the authenticator and the router, which gets passed the authenticator instance.
+
+If you are using a `.env` file, you must call `godotenv.Load()` at the very beginning of the `main()` function.
+
+Serve your application by using the following command in your terminal:
+
+```shell
+go run main.go
+```
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/01-login.md b/ja-jp/articles/quickstart/webapp/java-ee/01-login.md
new file mode 100644
index 0000000000..c788d7b41a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/01-login.md
@@ -0,0 +1,21 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Java EE web application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java ee
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Java EE', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/' }) %>
+
+<%= include('_includes/_setup') %>
+
+<%= include('_includes/_login') %>
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/_includes/_login.md b/ja-jp/articles/quickstart/webapp/java-ee/_includes/_login.md
new file mode 100644
index 0000000000..f25ae2479c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/_includes/_login.md
@@ -0,0 +1,391 @@
+## Configure Java EE Security
+
+The Java EE 8 Security API introduced the `HttpAuthenticationMechanism` interface to enable applications to obtain a user's credentials. Default implementations exist for Basic and form-based authentication, and it provides an easy way to configure a custom authentication strategy.
+
+To authenticate with Auth0, provide custom implementations of the following interfaces:
+
+- `HttpAuthenticationMechanism`: Responsible for obtaining a user's credentials and notifying the container of successful (or not) login status ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/authentication/mechanism/http/HttpAuthenticationMechanism.html)).
+- `IdentityStore`: Responsible for validating the user's credentials ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/identitystore/IdentityStore.html)).
+- `CallerPrincipal`: Represents the caller principal of the current HTTP request ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/CallerPrincipal.html)).
+- `Credential`: Represents the credential the caller will use to authenticate ([JavaDoc](https://javaee.github.io/javaee-spec/javadocs/javax/security/enterprise/credential/Credential.html)).
+
+First, make your Auth0 settings available to the application by creating an `@ApplicationScoped` bean to retrieve the values from the web context and make them available via getters:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationConfig.java
+
+@ApplicationScoped
+public class Auth0AuthenticationConfig {
+
+    private String domain;
+    private String clientId;
+    private String clientSecret;
+    private String scope;
+
+    @PostConstruct
+    public void init() {
+        // Get authentication config values from env-entries in web.xml
+        try {
+            Context env = (Context)new InitialContext().lookup("java:comp/env");
+
+            this.domain = (String) env.lookup("auth0.domain");
+            this.clientId = (String) env.lookup("auth0.clientId");
+            this.clientSecret = (String) env.lookup("auth0.clientSecret");
+            this.scope = (String) env.lookup("auth0.scope");
+        } catch (NamingException ne) {
+            throw new IllegalArgumentException("Unable to lookup auth0 configuration properties from web.xml", ne);
+        }
+
+        if (this.domain == null || this.clientId == null || this.clientSecret == null || this.scope == null) {
+            throw new IllegalArgumentException("domain, clientId, clientSecret, and scope must be set in web.xml");
+        }
+    }
+
+    public String getDomain() {
+         return domain;
+    }
+
+    public String getClientId() {
+         return clientId;
+    }
+
+    public String getClientSecret() {
+         return clientSecret;
+    }
+
+    public String getScope() {
+        return scope;
+    }
+}
+```
+
+Next, create a custom `CallerPrincipal` that represents the caller of the current request:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtPrincipal.java
+
+public class Auth0JwtPrincipal extends CallerPrincipal {
+    private final DecodedJWT idToken;
+
+    Auth0JwtPrincipal(DecodedJWT idToken) {
+        super(idToken.getClaim("name").asString());
+        this.idToken = idToken;
+    }
+
+    public DecodedJWT getIdToken() {
+        return this.idToken;
+    }
+}
+```
+
+You can now implement a custom `Credential` that will be used to represent the user's credentials. It will hold information about the principal:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtCredential.java
+
+class Auth0JwtCredential implements Credential {
+    private Auth0JwtPrincipal auth0JwtPrincipal;
+
+    Auth0JwtCredential(String token) {
+        DecodedJWT decodedJWT = JWT.decode(token);
+        this.auth0JwtPrincipal = new Auth0JwtPrincipal(decodedJWT);
+    }
+
+    Auth0JwtPrincipal getAuth0JwtPrincipal() {
+        return auth0JwtPrincipal;
+    }
+}
+```
+
+You now have defined the classes that represent a calling principal and credential. Next, create a custom implementation of `IdentityStore`. This class will be responsible for validating the user's credentials:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0JwtIdentityStore.java
+
+@ApplicationScoped
+public class Auth0JwtIdentityStore implements IdentityStore {
+
+    @Override
+    public CredentialValidationResult validate(final Credential credential) {
+        CredentialValidationResult result = CredentialValidationResult.NOT_VALIDATED_RESULT;
+        if (credential instanceof Auth0JwtCredential) {
+            Auth0JwtCredential auth0JwtCredential = (Auth0JwtCredential) credential;
+            result = new CredentialValidationResult(auth0JwtCredential.getAuth0JwtPrincipal());
+        }
+        return result;
+    }
+}
+```
+
+If the `credential` is an `Auth0Credential`, the calling user is authenticated and valid, so a `CredentialValidationResult` created with the credential is returned to indicate success. If it is not an `Auth0Credential`, return `CredentialValidationResult.NOT_VALIDATED_RESULT`.
+
+Before implementing the `HttpAuthenticationMechanism` interface that will use all these collaborators, create a bean that will provide a configured instance of the `AuthenticationController` from the Auth0 Java MVC SDK. The `AuthenticationController` is used to build the authorization URL where users will login, and handle the token exchange to authenticate users.
+
+* If your Auth0 Application is configured to use the **RS256 signing algorithm** (the default when creating a new Auth0 Application), you need to configure a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options.
+* If your Auth0 Application is configured to use the **HS256 signing algorithm**, there is no need to configure the `JwkProvider`.
+
+::: note
+To learn more about the available signing algorithms, refer to the [documentation](https://auth0.com/docs/tokens/concepts/signing-algorithms).
+:::
+
+The sample below shows how to configure the `AuthenticationController` for use with the **RS256 signing algorithm**:
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationProvider.java
+
+@ApplicationScoped
+public class Auth0AuthenticationProvider {
+
+    @Produces
+    public AuthenticationController authenticationController(Auth0AuthenticationConfig config) {
+        JwkProvider jwkProvider = new JwkProviderBuilder(config.getDomain()).build();
+        return AuthenticationController.newBuilder(config.getDomain(), config.getClientId(), config.getClientSecret())
+                .withJwkProvider(jwkProvider)
+                .build();
+    }
+}
+```
+
+Finally, implement a custom `HttpAuthenticationMechanism`
+
+```java
+// src/main/java/com/auth0/example/security/Auth0AuthenticationMechanism.java
+
+@ApplicationScoped
+@AutoApplySession
+public class Auth0AuthenticationMechanism implements HttpAuthenticationMechanism {
+    private final AuthenticationController authenticationController;
+    private final IdentityStoreHandler identityStoreHandler;
+
+    @Inject
+    Auth0AuthenticationMechanism(AuthenticationController authenticationController, IdentityStoreHandler identityStoreHandler) {
+        this.authenticationController = authenticationController;
+        this.identityStoreHandler = identityStoreHandler;
+    }
+
+    @Override
+    public AuthenticationStatus validateRequest(HttpServletRequest httpServletRequest,
+                                                HttpServletResponse httpServletResponse,
+                                                HttpMessageContext httpMessageContext) throws AuthenticationException {
+
+        // Exchange the code for the ID token, and notify container of result.
+        if (isCallbackRequest(httpServletRequest)) {
+            try {
+                Tokens tokens = authenticationController.handle(httpServletRequest, httpServletResponse);
+                Auth0JwtCredential auth0JwtCredential = new Auth0JwtCredential(tokens.getIdToken());
+                CredentialValidationResult result = identityStoreHandler.validate(auth0JwtCredential);
+                return httpMessageContext.notifyContainerAboutLogin(result);
+            } catch (IdentityVerificationException e) {
+                return httpMessageContext.responseUnauthorized();
+            }
+        }
+        return httpMessageContext.doNothing();
+    }
+
+    private boolean isCallbackRequest(HttpServletRequest request) {
+        return request.getRequestURI().equals("/callback") && request.getParameter("code") != null;
+    }
+}
+```
+
+The class overrides the `validateRequest` method, which is called on every request to our application, and is responsible for notifying the container of the authentication status.
+
+This sample uses the [Authorization Code Flow](https://auth0.com/docs/flows/concepts/auth-code) to exchange an Authorization Code for a token during the authentication flow. If this request is to the `/callback` endpoint and contains the `code` request parameter, it does a few important things:
+
+- Calls the `handle` method of the `AuthenticationController` to exchange the Authorization Code for an ID token and an access token.
+- Uses the ID token to create a new `Auth0Credential`.
+- Calls the `validate` method of the custom `IdentityStore` implementation to obtain the validation result.
+- Notifies the application container of the login status.
+
+If the requested resource is not `/callback`, return `httpMessageContext.doNothing()` to allow the request processing to continue. You will see shortly how to use the authentication information when triggering authentication and displaying web views.
+
+Finally, note that the `@AutoApplySession` annotation has been added to allow the container to create a session for the authenticated user.
+
+## Trigger authentication
+
+To enable a user to log in, create a Servlet that will handle requests to the `/login` path:
+
+```java
+// src/main/java/com/auth0/example/web/LoginServlet.java
+
+@WebServlet(urlPatterns = "/login")
+public class LoginServlet extends HttpServlet {
+    private final Auth0AuthenticationConfig config;
+    private final AuthenticationController authenticationController;
+
+    @Inject
+    LoginServlet(Auth0AuthenticationConfig config, AuthenticationController authenticationController) {
+        this.config = config;
+        this.authenticationController = authenticationController;
+    }
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
+        // URL where the application will receive the authorization code (e.g., http://localhost:3000/callback)
+        String callbackUrl = String.format(
+                "%s://%s:%s/callback",
+                request.getScheme(),
+                request.getServerName(),
+                request.getServerPort()
+        );
+
+        // Create the authorization URL to redirect the user to, to begin the authentication flow.
+        String authURL = authenticationController.buildAuthorizeUrl(request, response, callbackUrl)
+                .withScope(config.getScope())
+                .build();
+
+        response.sendRedirect(authURL);
+    }
+}
+```
+
+The `LoginController` is responsible for redirecting the request to the proper authorization URL, where the user can authenticate with Auth0. It uses the `AuthenticationController` from the Auth0 Java MVC SDK to build the correct authorization URL, using the configuration values injected via `Auth0AuthenticationConfig`. By default, this sample requests the `"openid profile email"` scopes, to allow the application to retrieve basic profile information from the authenticated user. You can read more about these scopes in the [OpenID Connect Scopes](https://auth0.com/docs/scopes/current/oidc-scopes) documentation.
+
+Once the user has entered their credentials and authorized the requested permissions, Auth0 will issue a request to the `callbackUrl`, and include a `code` query parameter which can be exchanged for an ID token and an access token. Recall that the `Auth0HttpAuthenticationMechanism` created above handles this exchange so that it can notify the application container of authentication status. This allows the Servlet that handles requests to the `/callback` path to simply forward the request on to the originally requested resource prior to logging in, or simply redirect to the home page:
+
+```java
+// src/main/com/auth0/example/web/CallbackServlet.java
+
+@WebServlet(urlPatterns = {"/callback"})
+public class CallbackServlet extends HttpServlet {
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
+        String referer = (String) request.getSession().getAttribute("Referer");
+        String redirectTo = referer != null ? referer : "/";
+
+        response.sendRedirect(redirectTo);
+    }
+}
+```
+
+## Display user information
+
+You can use the `Auth0JwtPrincipal` to get profile information for the authenticated user. The following code sample demonstrates how to use the claims on the [ID token](https://auth0.com/docs/tokens/id-token) to set profile data as a request attribute:
+
+```java
+// src/main/java/com/auth0/example/web/HomeServlet.java
+
+@WebServlet(urlPatterns = "")
+public class HomeServlet extends HttpServlet {
+
+    @Override
+    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
+        Principal principal = request.getUserPrincipal();
+
+        if (principal instanceof Auth0JwtPrincipal) {
+            Auth0JwtPrincipal auth0JwtPrincipal = (Auth0JwtPrincipal) principal;
+            request.setAttribute("profile", auth0JwtPrincipal.getIdToken().getClaims());
+        }
+        request.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(request, response);
+    }
+}
+```
+
+You can then use that profile information in your view to display information about the user:
+
+```html
+
+
+
+    ">
+        
  • 
+            
    
+                
+            
    
+        
    • 
+        
+    
+        
  • 
+            
+                
+                " alt="Profile picture"/>
+            
+            
    
+                
+                
    "<%= "${profile.get('name').asString()}" %>"
    
+                Profile
+                Log out
+            
    
+        
    • 
+        
+    
+```
+
+## Handle logout
+
+To log a user out, you should clear the application session and log the user out of Auth0. This is handled in the `LogoutServlet`.
+
+First, clear the session by calling `request.getSession().invalidate()`. Then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, redirect the response to the application's logout URL:
+
+```java
+// src/main/java/com/auth0/example/web/LogoutServlet.java
+
+@WebServlet(urlPatterns = "/logout")
+public class LogoutServlet extends HttpServlet {
+    private final Auth0AuthenticationConfig config;
+
+    @Inject
+    LogoutServlet(Auth0AuthenticationConfig config) {
+        this.config = config;
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+        clearSession(request);
+        response.sendRedirect(getLogoutUrl(request));
+    }
+
+    private void clearSession(HttpServletRequest request) {
+        if (request.getSession() != null) {
+            request.getSession().invalidate();
+        }
+    }
+
+    private String getLogoutUrl(HttpServletRequest request) {
+        String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+        int port = request.getServerPort();
+        String scheme = request.getScheme();
+
+        if (("http".equals(scheme) && port != 80) ||
+                ("https".equals(scheme) && port != 443)) {
+            returnUrl += ":" + port;
+        }
+
+        returnUrl += "/";
+
+        // Build logout URL like:
+        // https://{YOUR-DOMAIN}/v2/logout?client_id={YOUR-CLIENT-ID}&returnTo=http://localhost:3000/
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                config.getDomain(),
+                config.getClientId(),
+                returnUrl
+        );
+
+        return logoutUrl;
+    }
+}
+```
+
+## Run the sample
+
+To build and run the sample, execute the `wildfly:run` Maven goal to start an embedded WildFly application server with this application deployed to it. See the [WildFly Maven Plugin](https://docs.jboss.org/wildfly/plugins/maven/latest/) documentation for more information.
+
+If you are using Linux or MacOS:
+
+```bash
+./mvnw clean wildfly:run
+```
+
+Windows:
+
+```bash
+mvnw.cmd clean wildfly:run
+```
+
+Point your browser to [http://localhost:3000](http://localhost:3000). Follow the **Log In** link to log in or sign up to your Auth0 tenant. 
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+Upon successful login, you will see the user's profile picture and a drop-down menu where the Log In link was. You can then view the user's profile page by clicking the **Profile** link. You can log out by clicking the **Logout** link in the drop-down menu.
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/_includes/_setup.md b/ja-jp/articles/quickstart/webapp/java-ee/_includes/_setup.md
new file mode 100644
index 0000000000..e3a5870230
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/_includes/_setup.md
@@ -0,0 +1,83 @@
+## Configure Java EE to use Auth0
+
+### Set up dependencies
+
+To integrate your Java EE application with Auth0, add the following dependencies:
+
+- **javax.javaee-api**: The Java EE 8 API necessary to write applications using Java EE 8. The actual implementation is provided by the application container, so it does not need to be included in the WAR file.
+- **javax.security.enterprise**: The Java EE 8 Security API that enables handling security concerns in an EE application. Like the `javax.javaee-api` dependency, the implementation is provided by the application container, so is not included in the WAR file.
+- **auth0-java-mvc-commons**: The [Auth0 Java MVC SDK](https://github.com/auth0/auth0-java-mvc-common) allows you to use Auth0 with Java for server-side MVC web applications. It generates the Authorize URL that your application needs to call in order to authenticate a user using Auth0.
+
+If you are using Maven, add these dependencies to your `pom.xml`:
+
+```xml
+
+
+
+    com.auth0
+    mvc-auth-commons
+    [1.0, 2.0)
+
+
+    javax
+    javaee-api
+    8.0.1
+    provided
+
+
+    javax.security.enterprise
+    javax.security.enterprise-api
+    1.0
+    provided
+
+```
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+providedCompile 'javax:javaee-api:8.0.1'
+providedCompile 'javax.security.enterprise:javax.security.enterprise-api:1.0'
+implementation 'com.auth0:mvc-auth-commons:1.+'
+```
+
+### Configure your Java EE application
+
+::: note
+The sample that accompanies this tutorial is written using JSP and tested with the [WildFly](https://wildfly.org/) application server. You may need to adjust some of the steps if you working with a different application container or technologies.
+:::
+
+Your Java EE application needs some information in order to authenticate users with your Auth0 application. The deployment descriptor `web.xml` file can be used to store this information, though you could store them in a different secured location. The required information is:
+
+
+```xml
+
+
+
+    auth0.domain
+    java.lang.String
+    ${account.namespace}
+
+
+    auth0.clientId
+    java.lang.String
+    ${account.clientId}
+
+
+    auth0.clientSecret
+    java.lang.String
+    YOUR_CLIENT_SECRET
+
+
+    auth0.scope
+    java.lang.String
+    openid profile email
+
+```
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [README](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md) of the library.
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/download.md b/ja-jp/articles/quickstart/webapp/java-ee/download.md
new file mode 100644
index 0000000000..e7c987fe4e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./mvnw clean wildfly:run
+# In Windows
+mvnw.cmd clean wildfly:run
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-ee/index.yml b/ja-jp/articles/quickstart/webapp/java-ee/index.yml
new file mode 100644
index 0000000000..1d31b7e94a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-ee/index.yml
@@ -0,0 +1,50 @@
+title: Java EE
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.
+logo_name: java
+image: /media/platforms/java.png
+logo: java
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+alias:
+  - java
+  - java-ee
+languages:
+  - Java
+framework:
+  - Java EE
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: java ee
+articles:
+  - 01-login
+default_article: 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-java-ee-sample
+  branch: master
+sdk:
+  name: auth0-java-mvc-common
+  url: https://github.com/auth0/auth0-java-mvc-common
+  logo: java
+requirements:
+  - Java 11
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/01-login.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/01-login.md
new file mode 100644
index 0000000000..de1c68cb74
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/01-login.md
@@ -0,0 +1,311 @@
+---
+title: Login
+description: The Okta Spring Boot Starter makes it easy to add login to your Spring Boot application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java-spring-boot
+github:
+    path: mvc-login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel Using Spring WebFlux?
+This tutorial uses [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html). If you are using [Spring WebFlux](https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#spring-web-reactive), the steps to add authentication are similar, but some of the implementation details are different. Refer to the [Spring Boot WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/webflux-login) to see how to integrate Auth0 with your Spring Boot WebFlux application.
+:::
+
+<%= include('../_includes/_getting_started', { library: 'Java Spring Security', callback: 'http://localhost:3000/login/oauth2/code/okta' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/' }) %>
+
+## Configure Spring Boot Application
+
+### Add dependencies
+
+To integrate your Spring Boot application with Auth0, include the [Okta Spring Boot Starter](https://github.com/okta/okta-spring-boot/) in your application's dependencies.
+
+:::note
+This guide uses [Thymeleaf](https://www.thymeleaf.org/) and the [Spring Security integration module](https://github.com/thymeleaf/thymeleaf-extras-springsecurity) for the view layer. If you are using a different view technology, the Spring Security configuration and components remain the same.
+:::
+
+If you're using Gradle, you can include these dependencies as shown below.
+
+```groovy
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.4'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+implementation 'org.springframework.boot:spring-boot-starter-web'
+implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
+implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'
+implementation 'nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect'
+```
+
+If you are using Maven:
+
+```xml
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.5
+    
+
+
+
+    
+        com.okta
+        okta-spring-boot-starter
+        3.0.5
+    
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        org.springframework.boot
+        spring-boot-starter-oauth2-client
+    
+    
+        org.springframework.boot
+        spring-boot-starter-thymeleaf
+    
+    
+        org.thymeleaf.extras
+        thymeleaf-extras-springsecurity6
+    
+    
+        nz.net.ultraq.thymeleaf
+        thymeleaf-layout-dialect
+    
+
+```
+
+### Configure Spring Security
+
+The Okta Spring Boot Starter makes it easy to configure your application with Auth0. The sample below uses an `application.yml` file, though you can also use properties files or any of the other [supported externalization mechanisms](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config).
+
+
+```yaml
+# src/main/resources/application.yml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+
+# The sample and instructions above for the callback and logout URL configuration use port 3000.
+# If you wish to use a different port, change this and be sure your callback and logout URLs are
+# configured with the correct port.
+server:
+  port: 3000
+```
+
+## Add Login to Your Application
+
+To enable user login with Auth0, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), and add the `@Configuration` annotation.
+
+```java
+package com.auth0.example;
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults());
+        return http.build();
+    }
+}
+```
+
+:::note
+You can further configure the [HttpSecurity](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html) instance to require authentication on all or certain paths. For example, to require authentication on all paths except the home page:
+
+```java
+ http
+    .authorizeHttpRequests(authorize -> authorize
+        .requestMatchers("/").permitAll()
+        .anyRequest().authenticated()
+    );
+```
+:::
+
+The Okta Spring Boot Starter will use the client configuration you defined earlier to handle login when a user visits the `/oauth2/authorization/okta` path of your application. You can use this to create a login link in your application.
+
+```html
+
+
+    
+        
    
+            Log In
+        
    
+        
    
+            
    You are logged in!
    
+        
    
+    
+
+```
+
+Be sure to create or update a controller to render your view.
+
+```java
+package com.auth0.example;
+
+import org.springframework.security.core.annotation.AuthenticationPrincipal;
+import org.springframework.security.oauth2.core.oidc.user.OidcUser;
+import org.springframework.stereotype.Controller;
+import org.springframework.ui.Model;
+import org.springframework.web.bind.annotation.GetMapping;
+
+/**
+ * Controller for the home page.
+ */
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        return "index";
+    }
+}
+```
+
+:::panel Checkpoint
+Add the login link to your application. When you click it, verify that your application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you to your application and that you are logged in.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](https://auth0.com/docs/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](https://auth0.com/docs/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
+
+## Add Logout to Your Application
+
+Now that users can log into your application, they need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). By default, when logout is enabled, Spring Security will log the user out of your application and clear the session. To enable successful logout of Auth0, you can provide a `LogoutHandler` to redirect users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://${account.namespace}/v2/logout`) and then immediately redirect them to your application.
+
+In the `SecurityConfig` class, provide a `LogoutHandler` that redirects to the Auth0 logout endpoint, and configure the `HttpSecurity` to add the logout handler:
+
+```java
+package com.auth0.example;
+
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+import org.springframework.security.web.authentication.logout.LogoutHandler;
+import org.springframework.web.servlet.support.ServletUriComponentsBuilder;
+
+import java.io.IOException;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Value("<%= "${okta.oauth2.issuer}" %>")
+    private String issuer;
+    @Value("<%= "${okta.oauth2.client-id}" %>")
+    private String clientId;
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .requestMatchers("/", "/images/**").permitAll()
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults())
+
+            // configure logout with Auth0
+            .logout(logout -> logout
+                .addLogoutHandler(logoutHandler()));
+        return http.build();
+    }
+
+    private LogoutHandler logoutHandler() {
+        return (request, response, authentication) -> {
+            try {
+                String baseUrl = ServletUriComponentsBuilder.fromCurrentContextPath().build().toUriString();
+                response.sendRedirect(issuer + "v2/logout?client_id=" + clientId + "&returnTo=" + baseUrl);
+            } catch (IOException e) {
+                throw new RuntimeException(e);
+            }
+        };
+    }
+}
+```
+
+You can then update your view to POST to the `/logout` endpoint (Spring Security provides this by default) to enable users to log out.
+
+```html
+
    
+    
    You are logged in!
    
+    
    
+        
    
+```
+
+:::panel Checkpoint
+Add the logout link in the view of your application. When you click it, verify that your application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+You can retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users through the [OidcUser](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/oidc/user/OidcUser.html) class, which can be used with the [AuthenticationPrincipal annotation](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/core/annotation/AuthenticationPrincipal.html).
+
+In your controller, add the user's profile information to the model:
+
+```java
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        if (principal != null) {
+            model.addAttribute("profile", principal.getClaims());
+        }
+        return "index";
+    }
+}
+```
+
+You can then use this profile information in your view, as shown below.
+
+```html
+
    
+    " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+    
    ">
    
+    
    ">
    
+    Log Out
+
    
+```
+
+:::panel Checkpoint
+Verify that you can display the user name or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/download.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/download.md
new file mode 100644
index 0000000000..9b2aebcefc
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/download.md
@@ -0,0 +1,31 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/login/oauth2/code/auth0
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./gradlew clean bootRun
+# In Windows
+gradlew clean bootRun
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/application.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/application.md
new file mode 100644
index 0000000000..093b036734
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/application.md
@@ -0,0 +1,11 @@
+---
+name: application.yml
+language: yaml
+---
+```yaml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/home-controller.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/home-controller.md
new file mode 100644
index 0000000000..ad510c0ccf
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/home-controller.md
@@ -0,0 +1,28 @@
+---
+name: HomeController.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.security.core.annotation.AuthenticationPrincipal;
+import org.springframework.security.oauth2.core.oidc.user.OidcUser;
+import org.springframework.stereotype.Controller;
+import org.springframework.ui.Model;
+import org.springframework.web.bind.annotation.GetMapping;
+
+/**
+ * Controller for the home page.
+ */
+@Controller
+public class HomeController {
+
+    @GetMapping("/")
+    public String home(Model model, @AuthenticationPrincipal OidcUser principal) {
+        if (principal != null) {
+            model.addAttribute("profile", principal.getClaims());
+        }
+        return "index";
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/index.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/index.md
new file mode 100644
index 0000000000..453bffc798
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/index.md
@@ -0,0 +1,23 @@
+---
+name: index.html
+language: html
+---
+```html
+
+
+    
+        
    
+            Log In
+        
    
+        
    
+            
    You are logged in!
    
+            " th:attr="<%= "alt=${profile.get('name')}" %>"/>
+            
    ">
    
+            
    ">
    
+            
    
+                
    
+    
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md
new file mode 100644
index 0000000000..2b60bcd070
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config-logout.md
@@ -0,0 +1,55 @@
+---
+name: SecurityConfigWithLogout.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+import org.springframework.security.web.authentication.logout.LogoutHandler;
+import org.springframework.web.servlet.support.ServletUriComponentsBuilder;
+
+import java.io.IOException;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Value("<%= "${okta.oauth2.issuer}" %>")
+    private String issuer;
+    @Value("<%= "${okta.oauth2.client-id}" %>")
+    private String clientId;
+
+    @Bean
+    public SecurityFilterChain configure(HttpSecurity http) throws Exception {
+        http
+            .authorizeHttpRequests(authorize -> authorize
+                .requestMatchers("/", "/images/**").permitAll()
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults())
+            .logout(logout -> logout
+                .addLogoutHandler(logoutHandler()));
+        return http.build();
+    }
+
+    private LogoutHandler logoutHandler() {
+        return (request, response, authentication) -> {
+            try {
+                String baseUrl = ServletUriComponentsBuilder.fromCurrentContextPath().build().toUriString();
+                response.sendRedirect(issuer + "v2/logout?client_id=" + clientId + "&returnTo=" + baseUrl);
+            } catch (IOException e) {
+                throw new RuntimeException(e);
+            }
+        };
+    }
+}
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config.md
new file mode 100644
index 0000000000..6c68d3b916
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/files/security-config.md
@@ -0,0 +1,30 @@
+---
+name: SecurityConfig.java
+language: java
+---
+```java
+package com.auth0.example;
+
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.security.config.annotation.web.builders.HttpSecurity;
+import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
+import org.springframework.security.web.SecurityFilterChain;
+
+import static org.springframework.security.config.Customizer.withDefaults;
+
+@Configuration
+@EnableWebSecurity
+public class SecurityConfig {
+
+    @Bean
+    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
+         http
+            .authorizeHttpRequests(authorize -> authorize
+                .anyRequest().authenticated()
+            )
+            .oauth2Login(withDefaults());
+        return http.build();
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/index.yml b/ja-jp/articles/quickstart/webapp/java-spring-boot/index.yml
new file mode 100644
index 0000000000..7674acadc2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/index.yml
@@ -0,0 +1,48 @@
+title: Java Spring Boot
+# TODO remove 'image' and 'logo_name' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/spring.png
+logo_name: spring
+logo: spring
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+alias:
+  - spring boot
+  - spring-security
+seo_alias: java spring
+default_article: 01-login
+articles:
+  - 01-login
+show_steps: true
+hidden_articles:
+  - "interactive"
+sdk:
+  name: Okta Spring Boot Starter
+  url: https://github.com/okta/okta-spring-boot/
+  logo: spring
+github:
+  org: auth0-samples
+  repo: auth0-spring-boot-login-samples
+  branch: master
+requirements:
+  - Java 17
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java-spring-boot/interactive.md b/ja-jp/articles/quickstart/webapp/java-spring-boot/interactive.md
new file mode 100644
index 0000000000..a6aed541da
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,184 @@
+---
+title: Add login to your Spring Webapp
+description: The Okta Spring Boot Starter makes it easy to add login to your Spring Boot application.
+interactive: true
+files:
+  - files/application
+  - files/security-config
+  - files/index
+  - files/home-controller
+  - files/security-config-logout
+github:
+    path: mvc-login
+---
+
+# Add Login to Your Spring Web Application
+
+::: panel Using Spring WebFlux?
+This tutorial uses [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html). If you are using [Spring WebFlux](https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#spring-web-reactive), the steps to add authentication are similar, but some implementation details are different. Refer to the [Spring Boot WebFlux Sample Code](https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/webflux-login) to see how to integrate Auth0 with your Spring Boot WebFlux application.
+:::
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/login/oauth2/code/okta',
+  returnTo: 'http://localhost:3000'
+}) %>
+
+## Configure Spring Boot application
+
+### Add Spring dependencies
+
+To integrate your Spring Boot application with Auth0, include the [Okta Spring Boot Starter](https://github.com/okta/okta-spring-boot/) in your application's dependencies.
+
+:::note
+This guide uses [Thymeleaf](https://www.thymeleaf.org/) and the [Spring Security integration module](https://github.com/thymeleaf/thymeleaf-extras-springsecurity) for the view layer. If you are using a different view technology, the Spring Security configuration and components remain the same.
+:::
+
+If you're using Gradle, you can include these dependencies as shown below.
+
+```groovy
+plugins {
+    id 'java'
+    id 'org.springframework.boot' version '3.1.4'
+    id 'io.spring.dependency-management' version '1.1.3'
+}
+
+implementation 'com.okta.spring:okta-spring-boot-starter:3.0.5'
+implementation 'org.springframework.boot:spring-boot-starter-web'
+implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
+implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'
+implementation 'nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect'
+```
+
+If you are using Maven:
+
+```xml
+
+    org.springframework.boot
+    spring-boot-starter-parent
+    3.1.4
+    
+
+
+
+    
+        com.okta
+        okta-spring-boot-starter
+        3.0.5
+    
+    
+        org.springframework.boot
+        spring-boot-starter-web
+    
+    
+        org.springframework.boot
+        spring-boot-starter-oauth2-client
+    
+    
+        org.springframework.boot
+        spring-boot-starter-thymeleaf
+    
+    
+        org.thymeleaf.extras
+        thymeleaf-extras-springsecurity6
+    
+    
+        nz.net.ultraq.thymeleaf
+        thymeleaf-layout-dialect
+    
+
+```
+
+## Configure Spring Security {{{ data-action=code data-code="application.yml#1:11" }}}
+
+The Okta Spring Boot Starter makes it easy to configure your application with Auth0. The sample below uses an `application.yml` file, though you can also use properties files or any of the other [supported externalization mechanisms](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config).
+
+
+```yaml
+# src/main/resources/application.yml
+okta:
+  oauth2:
+    issuer: https://${account.namespace}/
+    client-id: ${account.clientId}
+    client-secret: YOUR_CLIENT_SECRET
+
+# The sample and instructions above for the callback and logout URL configuration use port 3000.
+# If you wish to use a different port, change this and be sure your callback and logout URLs are
+# configured with the correct port.
+server:
+  port: 3000
+```
+
+## Add login to your application {{{ data-action=code data-code="SecurityConfig.java" }}}
+
+To enable user login with Auth0, create a class that will register a [SecurityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/SecurityFilterChain.html), and add the `@Configuration` annotation.
+
+
+:::note
+You can configure the [HttpSecurity](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html) instance to require authentication on all or certain paths. For example, to require authentication on all paths except the home page:
+
+```java
+ http
+    .authorizeHttpRequests(authorize -> authorize
+        .requestMatchers("/").permitAll()
+        .anyRequest().authenticated()
+    );
+```
+:::
+
+## Add front page {{{ data-action=code data-code="index.html" }}}
+
+The Okta Spring Boot Starter will use the client configuration you defined earlier to handle login when a user visits the `/oauth2/authorization/okta` path of your application. You can use this to create a login link in your application.
+
+This page returns the user attributes when the user authentications. You will use the `/logout` link in the template to implement the logout feature.
+
+## Add controller {{{ data-action=code data-code="HomeController.java" }}}
+
+Create a controller to handle the incoming request. This controller renders the `index.html` page. When the user authenticates, the application retrieves the users's profile information attributes to render the page.
+
+::::checkpoint
+
+:::checkpoint-default
+
+When you click the login link, verify the application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+:::
+
+:::checkpoint-failure
+If your application did not allow login or signup:
+* Verify you configured the correct Callback URL
+* Verify you added the login link to redirect to `/oauth2/authorization/okta`
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+:::note
+Auth0 enables the Google social provider by default on new tenants and offers you developer keys to test logging in with [social identity providers](https://auth0.com/docs/connections/identity-providers-social). However, these developer keys have some limitations that may cause your application to behave differently. For more details on what this behavior may look like and how to fix it, consult the [Test Social Connections with Auth0 Developer Keys](https://auth0.com/docs/connections/social/devkeys#limitations-of-developer-keys) document.
+:::
+
+## Add logout to your application {{{ data-action=code data-code="SecurityConfigWithLogout.java" }}}
+
+Now that users can log into your application, they need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). By default, when logout is enabled, Spring Security will log the user out of your application and clear the session. To enable successful logout of Auth0, you can provide a `LogoutHandler` to redirect users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://${account.namespace}/v2/logout`) and then immediately redirect them to your application.
+
+In the `SecurityConfig` class, provide a `LogoutHandler` that redirects to the Auth0 logout endpoint, and configure the `HttpSecurity` to add the logout handler
+
+::::checkpoint
+
+:::checkpoint-default
+When you click logout link, the application should redirect you to the address you specified as one of the "Allowed Logout URLs" in the "Settings" and you are no longer logged in to your application.
+:::
+
+:::checkpoint-failure
+If your application did not allow logout:
+* Verify you configured the correct logout URL
+* Verify you added the logout link to POST to `/logout`
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
diff --git a/ja-jp/articles/quickstart/webapp/java/01-login.md b/ja-jp/articles/quickstart/webapp/java/01-login.md
new file mode 100644
index 0000000000..e8a096df04
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/01-login.md
@@ -0,0 +1,21 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Java Servlet application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java
+contentType: tutorial
+useCase: quickstart
+github:
+  path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Java Servlet', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000/login' }) %>
+
+<%= include('_includes/_setup') %>
+
+<%= include('_includes/_login') %>
diff --git a/ja-jp/articles/quickstart/webapp/java/_includes/_login.md b/ja-jp/articles/quickstart/webapp/java/_includes/_login.md
new file mode 100644
index 0000000000..73f2db5b42
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/_includes/_login.md
@@ -0,0 +1,199 @@
+### Project Structure
+
+The Login project sample has the following structure:
+
+```text
+- src
+-- main
+---- java
+------ com
+-------- auth0
+---------- example
+------------ Auth0Filter.java
+------------ AuthenticationControllerProvider.java
+------------ HomeServlet.java
+------------ CallbackServlet.java
+------------ LoginServlet.java
+------------ LogoutServlet.java
+---- webapp
+------ WEB-INF
+-------- jsp
+---------- home.jsp
+-------- web.xml
+- build.gradle
+```
+
+The project contains a single JSP: the `home.jsp` which will display the tokens associated with the user after a successful login and provide the option to logout.
+
+The project contains a WebFilter: the `Auth0Filter.java` which will check for existing tokens before giving the user access to our protected `/portal/*` path. If the tokens don't exist, the request will be redirected to the `LoginServlet`.
+
+The project contains also four servlets:
+- `LoginServlet.java`: Invoked when the user attempts to log in. The servlet uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
+- `CallbackServlet.java`: The servlet captures requests to our Callback URL and processes the data to obtain the credentials. After a successful login, the credentials are then saved to the request's HttpSession.
+- `HomeServlet.java`: The servlet reads the previously saved tokens and shows them on the `home.jsp` resource.
+- `LogoutServlet.java`: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the login page, handled by the `LoginServlet`.
+- `AuthenticationControllerProvider`: Responsible to create and manage a single instance of the `AuthenticationController`
+
+## Create the AuthenticationController
+
+To enable users to authenticate, create an instance of the `AuthenticationController` provided by the `auth0-java-mvc-commons` SDK using the `domain`, `clientId`, and `clientSecret`.  The sample shows how to configure the component for use with tokens signed using the RS256 asymmetric signing algorithm, by specifying a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options. If you are using HS256, there is no need to configure the `JwkProvider`. 
+
+:::note
+The `AuthenticationController` does not store any context, and is inteded to be reused. Unneccessary creation may result in additonal resources being created which could impact performance.
+:::
+
+```java
+class AuthenticationControllerProvider {
+
+    private AuthenticationControllerProvider() {}
+
+    private static AuthenticationController INSTANCE;
+
+    // if multiple threads may call this, synchronize this method and consider double locking
+    static AuthenticationController getInstance(ServletConfig config) throws UnsupportedEncodingException {
+        if (INSTANCE == null) {
+            String domain = config.getServletContext().getInitParameter("com.auth0.domain");
+            String clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+            String clientSecret = config.getServletContext().getInitParameter("com.auth0.clientSecret");
+
+            if (domain == null || clientId == null || clientSecret == null) {
+                throw new IllegalArgumentException("Missing domain, clientId, or clientSecret. Did you update src/main/webapp/WEB-INF/web.xml?");
+            }
+
+            // JwkProvider required for RS256 tokens. If using HS256, do not use.
+            JwkProvider jwkProvider = new JwkProviderBuilder(domain).build();
+            INSTANCE = AuthenticationController.newBuilder(domain, clientId, clientSecret)
+                    .withJwkProvider(jwkProvider)
+                    .build();
+        }
+
+        return INSTANCE;
+    }
+```
+
+## Trigger Authentication
+
+To enable users to login, your application will redirect them to the [Universal Login](https://auth0.com/docs/universal-login) page. Using the `AuthenticationController` instance, you can generate the redirect URL by calling the `buildAuthorizeUrl(HttpServletRequest request, HttpServletResponse response, String redirectUrl)` method. The redirect URL must be the URL that was added to the **Allowed Callback URLs** of your Auth0 Application.
+
+```java
+// src/main/java/com/auth0/example/LoginServlet.java
+
+@Override
+protected void doGet(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
+    String redirectUri = req.getScheme() + "://" + req.getServerName();
+    if ((req.getScheme().equals("http") && req.getServerPort() != 80) || (req.getScheme().equals("https") && req.getServerPort() != 443)) {
+        redirectUri += ":" + req.getServerPort();
+    }
+    redirectUri += "/callback";
+
+    String authorizeUrl = authenticationController.buildAuthorizeUrl(req, res, redirectUri)
+            .build();
+    res.sendRedirect(authorizeUrl);
+}
+```
+
+After the user logs in, the result will be received in our `CallbackServlet` via either a GET or POST HTTP request. Because we are using the Authorization Code Flow (the default), a GET request will be sent. If you have configured the library for the Implicit Flow, a POST request will be sent instead.
+
+The request holds the call context that the library previously set by generating the Authorize URL with the `AuthenticationController`. When passed to the controller, you get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, you need to save the credentials somewhere to access them later. You can use the `HttpSession` of the request by using the `SessionsUtils` class included in the library.
+
+```java
+// src/main/java/com/auth0/example/CallbackServlet.java
+
+@Override
+public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+    handle(req, res);
+}
+
+@Override
+public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+    handle(req, res);
+}
+
+private void handle(HttpServletRequest req, HttpServletResponse res) throws IOException {
+    try {
+        // Parse the request
+        Tokens tokens = authenticationController.handle(req, res);
+        SessionUtils.set(req, "accessToken", tokens.getAccessToken());
+        SessionUtils.set(req, "idToken", tokens.getIdToken());
+        res.sendRedirect(redirectOnSuccess);
+    } catch (IdentityVerificationException e) {
+        e.printStackTrace();
+        res.sendRedirect(redirectOnFail);
+    }
+}
+```
+
+::: note
+It is recommended to store the time in which we requested the tokens and the received `expiresIn` value, so that the next time when we are going to use the token we can check if it has already expired or if it's still valid. For the sake of this sample, we will skip that validation.
+:::
+
+## Display the Home Page
+
+Now that the user is authenticated (the tokens exists), the `Auth0Filter` will allow them to access our protected resources. In the `HomeServlet` we obtain the tokens from the request's session and set them as the `userId` attribute so they can be used from the JSP code:
+
+```java
+// src/main/java/com/auth0/example/HomeServlet.java
+
+protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
+    final String accessToken = (String) SessionUtils.get(req, "accessToken");
+    final String idToken = (String) SessionUtils.get(req, "idToken");
+    if (accessToken != null) {
+        req.setAttribute("userId", accessToken);
+    } else if (idToken != null) {
+        req.setAttribute("userId", idToken);
+    }
+    req.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(req, res);
+}
+```
+
+## Handle Logout
+
+To properly handle logout, we need to clear the session and log the user out of Auth0. This is handled in the `LogoutServlet` of our sample application.
+
+First, we clear the session by calling `request.getSession().invalidate()`. We then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, we redirect the response to our logout URL.
+
+
+```java
+// src/main/java/com/auth0/example/LogoutServlet.java
+
+@Override
+protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+    if (request.getSession() != null) {
+        request.getSession().invalidate();
+    }
+
+    String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+    if ((request.getScheme().equals("http") && request.getServerPort() != 80) || (request.getScheme().equals("https") && request.getServerPort() != 443)) {
+        returnUrl += ":" + request.getServerPort();
+    }
+    returnUrl += "/login";
+
+    // Build logout URL like:
+    // https://{YOUR-DOMAIN}/v2/logout?client_id={YOUR-CLIENT-ID}&returnTo=http://localhost:3000/login
+    String logoutUrl = String.format(
+            "https://%s/v2/logout?client_id=%s&returnTo=%s",
+            domain,
+            clientId,
+            returnUrl
+    );
+    response.sendRedirect(logoutUrl);
+}
+```
+
+## Run the Sample
+
+To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
+
+```bash
+./gradlew clean appRun
+```
+
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource [http://localhost:3000/portal/home](http://localhost:3000/portal/home) and note how you're redirected by the `Auth0Filter` to the Auth0 Login Page. The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+After a successful authentication, you'll be able to see the home page contents.
+
+![Display Token](/media/articles/java/display-token.png)
+
+Log out by clicking the **Logout** button at the top right of the home page.
diff --git a/ja-jp/articles/quickstart/webapp/java/_includes/_setup.md b/ja-jp/articles/quickstart/webapp/java/_includes/_setup.md
new file mode 100644
index 0000000000..9d2775b755
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/_includes/_setup.md
@@ -0,0 +1,64 @@
+## Integrate Auth0 in your Application
+
+### Setup Dependencies
+
+To integrate your Java application with Auth0, add the following dependencies:
+
+- **javax.servlet-api**: is the library that allows you to create Java Servlets. You then need to add a Server dependency like Tomcat or Gretty, which one is up to you. Check our sample code for more information.
+- **auth0-java-mvc-commons**: is the [Java library](https://github.com/auth0/auth0-java-mvc-common) that allows you to use Auth0 with Java for server-side MVC web apps. It generates the Authorize URL that you need to call in order to authenticate and validates the result received on the way back to finally obtain the [Auth0 Tokens](/tokens) that identify the user.
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+compile 'com.auth0:mvc-auth-commons:1.+'
+```
+
+If you are using Maven, add them to your `pom.xml`:
+
+```xml
+
+
+
+  com.auth0
+  mvc-auth-commons
+  [1.0, 2.0)
+
+
+  javax.servlet
+  javax.servlet-api
+  3.1.0
+
+```
+
+### Configure your Java App
+
+Your Java App needs some information in order to authenticate against your Auth0 account. The samples read this information from the deployment descriptor file `src/main/webapp/WEB-INF/web.xml`, but you could store them anywhere else. The required information is:
+
+```xml
+
+
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    YOUR_CLIENT_SECRET
+
+```
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [library's documentation](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md).
+
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
diff --git a/ja-jp/articles/quickstart/webapp/java/download.md b/ja-jp/articles/quickstart/webapp/java/download.md
new file mode 100644
index 0000000000..12572623a2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/login
+```
+
+3) Make sure [Java](http://www.oracle.com/technetwork/java/javase/downloads/) is installed and execute the following commands in the sample's directory:
+
+```bash
+# In Linux / macOS
+./gradlew clean appRun
+# In Windows
+gradlew clean appRun
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/authentication-controller-provider.md b/ja-jp/articles/quickstart/webapp/java/files/authentication-controller-provider.md
new file mode 100644
index 0000000000..c722f0beef
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/authentication-controller-provider.md
@@ -0,0 +1,33 @@
+---
+name: AuthenticationControllerProvider.java
+language: java
+---
+```java
+class AuthenticationControllerProvider {
+
+    private AuthenticationControllerProvider() {}
+
+    private static AuthenticationController INSTANCE;
+
+    // if multiple threads may call this, synchronize this method and consider double locking
+    static AuthenticationController getInstance(ServletConfig config) throws UnsupportedEncodingException {
+        if (INSTANCE == null) {
+            String domain = config.getServletContext().getInitParameter("com.auth0.domain");
+            String clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+            String clientSecret = config.getServletContext().getInitParameter("com.auth0.clientSecret");
+
+            if (domain == null || clientId == null || clientSecret == null) {
+                throw new IllegalArgumentException("Missing domain, clientId, or clientSecret. Did you update src/main/webapp/WEB-INF/web.xml?");
+            }
+
+            // JwkProvider required for RS256 tokens. If using HS256, do not use.
+            JwkProvider jwkProvider = new JwkProviderBuilder(domain).build();
+            INSTANCE = AuthenticationController.newBuilder(domain, clientId, clientSecret)
+                    .withJwkProvider(jwkProvider)
+                    .build();
+        }
+
+        return INSTANCE;
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/callback-servlet.md b/ja-jp/articles/quickstart/webapp/java/files/callback-servlet.md
new file mode 100644
index 0000000000..1c60791bd7
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/callback-servlet.md
@@ -0,0 +1,44 @@
+---
+name: CallbackServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/callback"})
+public class CallbackServlet extends HttpServlet {
+
+    private String redirectOnSuccess;
+    private String redirectOnFail;
+    private AuthenticationController authenticationController;
+
+    @Override
+    public void init(ServletConfig config) throws ServletException {
+        super.init(config);
+        redirectOnSuccess = "/portal/home";
+        redirectOnFail = "/login";
+        authenticationController = AuthenticationControllerProvider.getInstance(config);
+    }
+
+    @Override
+    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+        handle(req, res);
+    }
+
+    @Override
+    public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
+        handle(req, res);
+    }
+
+    private void handle(HttpServletRequest req, HttpServletResponse res) throws IOException {
+        try {
+            // Parse the request
+            Tokens tokens = authenticationController.handle(req, res);
+            SessionUtils.set(req, "accessToken", tokens.getAccessToken());
+            SessionUtils.set(req, "idToken", tokens.getIdToken());
+            res.sendRedirect(redirectOnSuccess);
+        } catch (IdentityVerificationException e) {
+            e.printStackTrace();
+            res.sendRedirect(redirectOnFail);
+        }
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/home-servlet.md b/ja-jp/articles/quickstart/webapp/java/files/home-servlet.md
new file mode 100644
index 0000000000..5013342a7b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/home-servlet.md
@@ -0,0 +1,21 @@
+---
+name: HomeServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/portal/home"})
+public class HomeServlet extends HttpServlet {
+
+    @Override
+    protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
+        final String accessToken = (String) SessionUtils.get(req, "accessToken");
+        final String idToken = (String) SessionUtils.get(req, "idToken");
+        if (accessToken != null) {
+            req.setAttribute("userId", accessToken);
+        } else if (idToken != null) {
+            req.setAttribute("userId", idToken);
+        }
+        req.getRequestDispatcher("/WEB-INF/jsp/home.jsp").forward(req, res);
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/login-servlet.md b/ja-jp/articles/quickstart/webapp/java/files/login-servlet.md
new file mode 100644
index 0000000000..34af59e76e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/login-servlet.md
@@ -0,0 +1,31 @@
+---
+name: LoginServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/login"})
+public class LoginServlet extends HttpServlet {
+    private AuthenticationController authenticationController;
+    private String domain;
+
+    @Override
+    public void init(ServletConfig config) throws ServletException {
+        super.init(config);
+        domain = config.getServletContext().getInitParameter("com.auth0.domain");
+        authenticationController = AuthenticationControllerProvider.getInstance(config);
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
+        String redirectUri = req.getScheme() + "://" + req.getServerName();
+        if ((req.getScheme().equals("http") && req.getServerPort() != 80) || (req.getScheme().equals("https") && req.getServerPort() != 443)) {
+            redirectUri += ":" + req.getServerPort();
+        }
+        redirectUri += "/callback";
+
+        String authorizeUrl = authenticationController.buildAuthorizeUrl(req, res, redirectUri)
+                .build();
+        res.sendRedirect(authorizeUrl);
+    }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/logout-servlet.md b/ja-jp/articles/quickstart/webapp/java/files/logout-servlet.md
new file mode 100644
index 0000000000..50c36f2249
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/logout-servlet.md
@@ -0,0 +1,38 @@
+---
+name: LogoutServlet.java
+language: java
+---
+```java
+@WebServlet(urlPatterns = {"/logout"})
+public class LogoutServlet extends HttpServlet {
+
+    private String domain;
+    private String clientId;
+
+    @Override
+    public void init(ServletConfig config) {
+        domain = config.getServletContext().getInitParameter("com.auth0.domain");
+        clientId = config.getServletContext().getInitParameter("com.auth0.clientId");
+    }
+
+    @Override
+    protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
+        if (request.getSession() != null) {
+            request.getSession().invalidate();
+        }
+        String returnUrl = String.format("%s://%s", request.getScheme(), request.getServerName());
+        if ((request.getScheme().equals("http") && request.getServerPort() != 80) || (request.getScheme().equals("https") && request.getServerPort() != 443)) {
+            returnUrl += ":" + request.getServerPort();
+        }
+        returnUrl += "/login";
+        String logoutUrl = String.format(
+                "https://%s/v2/logout?client_id=%s&returnTo=%s",
+                domain,
+                clientId,
+                returnUrl
+        );
+        response.sendRedirect(logoutUrl);
+    }
+
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/files/web.md b/ja-jp/articles/quickstart/webapp/java/files/web.md
new file mode 100644
index 0000000000..df86d7ee74
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/files/web.md
@@ -0,0 +1,20 @@
+---
+name: web.xml
+language: xml
+---
+```xml
+
+    com.auth0.domain
+    ${account.namespace}
+
+
+
+    com.auth0.clientId
+    ${account.clientId}
+
+
+
+    com.auth0.clientSecret
+    YOUR_CLIENT_SECRET
+
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/java/index.yml b/ja-jp/articles/quickstart/webapp/java/index.yml
new file mode 100644
index 0000000000..77afc30ff0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/index.yml
@@ -0,0 +1,47 @@
+title: Java
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/java.png
+logo: java
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+author:
+  name: Jim Anderson
+  email: jim.anderson@auth0.com
+  community: false
+alias:
+  - java
+seo_alias: java
+default_article: 01-login
+articles:
+  - 01-login
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-servlet-sample
+  branch: master
+hidden_articles:
+  - "interactive"
+sdk:
+  name: auth0-java-mvc-common
+  url: https://github.com/auth0/auth0-java-mvc-common
+  logo: java
+requirements:
+  - Java 8
+  - Gradle 3.3 and up
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/webapp/java/interactive.md b/ja-jp/articles/quickstart/webapp/java/interactive.md
new file mode 100644
index 0000000000..5fb7532d8c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,160 @@
+---
+title: Add Login to your Java Servlet application
+description: This tutorial demonstrates how to add user login to a Java Servlet application.
+interactive: true
+files:
+  - files/web
+  - files/authentication-controller-provider
+  - files/login-servlet
+  - files/callback-servlet
+  - files/home-servlet
+  - files/logout-servlet
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - java
+github:
+  path: 01-Login
+---
+
+# Add Login to Your Java Servlet Application
+
+Auth0 allows you to quickly add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Java Servlet application.
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/callback',
+  returnTo: 'http://localhost:3000/login'
+}) %>
+
+## Integrate Auth0 in your application
+
+### Setup dependencies
+
+To integrate your Java application with Auth0, add the following dependencies:
+
+- **javax.servlet-api**: is the library that allows you to create Java Servlets. You then need to add a Server dependency like Tomcat or Gretty, which one is up to you. Check our sample code for more information.
+- **auth0-java-mvc-commons**: is the [Java library](https://github.com/auth0/auth0-java-mvc-common) that allows you to use Auth0 with Java for server-side MVC web apps. It generates the Authorize URL that you need to call in order to authenticate and validates the result received on the way back to finally obtain the [Auth0 Tokens](/tokens) that identify the user.
+
+If you are using Gradle, add them to your `build.gradle`:
+
+```java
+// build.gradle
+
+compile 'javax.servlet:javax.servlet-api:3.1.0'
+compile 'com.auth0:mvc-auth-commons:1.+'
+```
+
+If you are using Maven, add them to your `pom.xml`:
+
+```xml
+
+
+
+  com.auth0
+  mvc-auth-commons
+  [1.0, 2.0)
+
+
+  javax.servlet
+  javax.servlet-api
+  3.1.0
+
+```
+
+## Configure your Java application {{{ data-action=code data-code="web.xml#6:14" }}}
+
+Your Java App needs some information in order to authenticate against your Auth0 account. The samples read this information from the deployment descriptor file `src/main/webapp/WEB-INF/web.xml`, but you could store them anywhere else.
+
+This information will be used to configure the **auth0-java-mvc-commons** library to enable users to login to your application. To learn more about the library, including its various configuration options, see the [library's documentation](https://github.com/auth0/auth0-java-mvc-common/blob/master/README.md).
+
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
+
+### Project structure
+
+The example project, which can be downloaded using the **Download Sample** button, has the following structure:
+
+```text
+- src
+-- main
+---- java
+------ com
+-------- auth0
+---------- example
+------------ Auth0Filter.java
+------------ AuthenticationControllerProvider.java
+------------ HomeServlet.java
+------------ CallbackServlet.java
+------------ LoginServlet.java
+------------ LogoutServlet.java
+---- webapp
+------ WEB-INF
+-------- jsp
+---------- home.jsp
+-------- web.xml
+- build.gradle
+```
+
+The project contains a single JSP: the `home.jsp` which will display the tokens associated with the user after a successful login and provide the option to logout.
+
+The project contains a WebFilter: the `Auth0Filter.java` which will check for existing tokens before giving the user access to our protected `/portal/*` path. If the tokens don't exist, the request will be redirected to the `LoginServlet`.
+
+The project contains also four servlets:
+- `LoginServlet.java`: Invoked when the user attempts to log in. The servlet uses the `client_id` and `domain` parameters to create a valid Authorize URL and redirects the user there.
+- `CallbackServlet.java`: The servlet captures requests to our Callback URL and processes the data to obtain the credentials. After a successful login, the credentials are then saved to the request's HttpSession.
+- `HomeServlet.java`: The servlet reads the previously saved tokens and shows them on the `home.jsp` resource.
+- `LogoutServlet.java`: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the login page, handled by the `LoginServlet`.
+- `AuthenticationControllerProvider`: Responsible to create and manage a single instance of the `AuthenticationController`
+  
+## Create the AuthenticationController {{{ data-action=code data-code="AuthenticationControllerProvider.java#6-32 }}}
+
+To enable users to authenticate, create an instance of the `AuthenticationController` provided by the `auth0-java-mvc-commons` SDK using the `domain`, `clientId`, and `clientSecret`.  The sample shows how to configure the component for use with tokens signed using the RS256 asymmetric signing algorithm, by specifying a `JwkProvider` to fetch the public key used to verify the token's signature. See the [jwks-rsa-java repository](https://github.com/auth0/jwks-rsa-java) to learn about additional configuration options. If you are using HS256, there is no need to configure the `JwkProvider`. 
+
+:::note
+The `AuthenticationController` does not store any context, and is inteded to be reused. Unneccessary creation may result in additonal resources being created which could impact performance.
+:::
+
+## Login Redirection {{{ data-action=code data-code="LoginServlet.java#21:23" }}}
+
+To enable users to log in, your application will redirect them to the [Universal Login](https://auth0.com/docs/universal-login) page. Using the `AuthenticationController` instance, you can generate the redirect URL by calling the `buildAuthorizeUrl(HttpServletRequest request, HttpServletResponse response, String redirectUrl)` method. The redirect URL must be the URL that was added to the **Allowed Callback URLs** of your Auth0 application.
+
+## Handling the tokens {{{ data-action=code data-code="CallbackServlet.java#16:37" }}}
+
+After the user logs in, the result will be received in our `CallbackServlet` via either a GET or POST HTTP request. Because we are using the Authorization Code Flow (the default), a GET request will be sent. If you have configured the library for the Implicit Flow, a POST request will be sent instead.
+
+The request holds the call context that the library previously set by generating the Authorize URL with the `AuthenticationController`. When passed to the controller, you get back either a valid `Tokens` instance or an Exception indicating what went wrong. In the case of a successful call, you need to save the credentials somewhere to access them later. You can use the `HttpSession` of the request by using the `SessionsUtils` class included in the library.
+
+::: note
+It is recommended to store the time in which we requested the tokens and the received `expiresIn` value, so that the next time when we are going to use the token we can check if it has already expired or if it's still valid. For the sake of this sample, we will skip that validation.
+:::
+
+## Display the home page {{{ data-action=code data-code="HomeServlet.java#4:14" }}}
+
+Now that the user is authenticated (the tokens exists), the `Auth0Filter` will allow them to access our protected resources. In the `HomeServlet` we obtain the tokens from the request's session and set them as the `userId` attribute so they can be used from the JSP code.
+
+## Handle logout {{{ data-action=code data-code="LogoutServlet.java#13:30" }}}
+
+To properly handle logout, we need to clear the session and log the user out of Auth0. This is handled in the `LogoutServlet` of our sample application.
+
+First, we clear the session by calling `request.getSession().invalidate()`. We then construct the logout URL, being sure to include the `returnTo` query parameter, which is where the user will be redirected to after logging out. Finally, we redirect the response to our logout URL.
+
+## Run the sample {{{ data-action=code data-code="LogoutServlet.java#13:30" }}}
+
+To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
+
+```bash
+./gradlew clean appRun
+```
+
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource [http://localhost:3000/portal/home](http://localhost:3000/portal/home) and note how you're redirected by the `Auth0Filter` to the Auth0 Login Page. The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+After a successful authentication, you'll be able to see the home page contents.
+
+![Display Token](/media/articles/java/display-token.png)
+
+Log out by clicking the **logout** button at the top right of the home page.
diff --git a/ja-jp/articles/quickstart/webapp/laravel/01-login.md b/ja-jp/articles/quickstart/webapp/laravel/01-login.md
new file mode 100644
index 0000000000..44ac2c72df
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/01-login.md
@@ -0,0 +1,217 @@
+---
+title: Add Login to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+topics:
+  - quickstart
+  - webapp
+  - laravel
+  - authentication
+  - login
+  - user profile
+  - logout
+  - php
+  - laravel
+contentType: tutorial
+useCase: quickstart
+github:
+  path: sample
+---
+
+
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-app
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Application" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Application's API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Login Routes
+
+The SDK automatically registers all the necessary routes for your application's users to authenticate.
+
+| Route       | Purpose                            |
+| ----------- | ---------------------------------- |
+| `/login`    | Initiates the authentication flow. |
+| `/logout`   | Logs the user out.                 |
+| `/callback` | Handles the callback from Auth0.   |
+
+If you require more control over these, or if they conflict with existing routes in your application, you can manually register the SDK's controllers instead. Please see [the SDK's README](https://github.com/auth0/laravel-auth0) for advanced integrations.
+
+## Access Control {{{ data-action=code data-code="routes/web.php#6:12" }}}
+
+Laravel's authentication facilities use "guards" to define how users are authenticated for each request. You can use the Auth0 SDK's authentication guard to restrict access to your application's routes.
+
+To require users to authenticate before accessing a route, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response('Welcome! You are logged in.');
+})->middleware('auth');
+```
+
+You can also require authenticated users to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response('You have the `read:messages` permissions, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+```
+
+## User Information {{{ data-action=code data-code="routes/web.php#14:24" }}}
+
+Information about the authenticated user is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});
+```
+
+## User Management{{{ data-action=code data-code="routes/web.php#26:43" }}}
+
+You can update user information using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/Management.md). All Management endpoints are accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, in which we will update a user's metadata and assign a random favorite color, you should grant the `read:users` and `update:users` scopes. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id());
+  $metadata = Auth0::json($metadata);
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
+
+A quick reference guide of all the SDK's Management API methods is [available here](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md).
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+### Checkpoint
+
+Open your web browser and try accessing the following routes:
+
+- [http://localhost:8000](http://localhost:8000) to see the public route.
+- [http://localhost:8000/private](http://localhost:8000/private) to be prompted to authenticate.
+- [http://localhost:8000](http://localhost:8000) to see the pubic route, now authenticated.
+- [http://localhost:8000/scope](http://localhost:8000/scope) to check if you have the `read:messages` [permission](https://auth0.com/docs/manage-users/access-control/rbac).
+- [http://localhost:8000/update](http://localhost:8000/update) to update the user's profile.
+- [http://localhost:8000/logout](http://localhost:8000/logout) to log out.
+
+If you have any issues, here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/ja-jp/articles/quickstart/webapp/laravel/download.md b/ja-jp/articles/quickstart/webapp/laravel/download.md
new file mode 100644
index 0000000000..e149badf02
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/download.md
@@ -0,0 +1,8 @@
+Open a shell to the downloaded project directory, and run the following command:
+
+```bash
+composer install
+php artisan migrate
+php artisan key:generate
+php artisan serve
+```
diff --git a/ja-jp/articles/quickstart/webapp/laravel/files/web.md b/ja-jp/articles/quickstart/webapp/laravel/files/web.md
new file mode 100644
index 0000000000..77344cc11d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/files/web.md
@@ -0,0 +1,54 @@
+---
+name: routes/web.php
+language: php
+---
+
+```php
+middleware('auth');
+
+Route::get('/scope', function () {
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id()); // Retrieve the user's metadata.
+  $metadata = Auth0::json($metadata); // Convert the JSON to a PHP array.
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
diff --git a/ja-jp/articles/quickstart/webapp/laravel/index.yml b/ja-jp/articles/quickstart/webapp/laravel/index.yml
new file mode 100644
index 0000000000..3379252e0f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/index.yml
@@ -0,0 +1,36 @@
+title: Laravel
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: laravel
+alias:
+  - laravel
+languages:
+  - PHP
+framework:
+  - Laravel
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+default_article: 01-login
+seo_alias: laravel
+github:
+  org: auth0-samples
+  repo: laravel
+  branch: 7.x
+sdk:
+  name: laravel-auth0
+  url: https://github.com/auth0/laravel-auth0
+  logo: laravel
+requirements:
+  - Laravel 9 / 10
+  - PHP 8.0+
+  - Composer
diff --git a/ja-jp/articles/quickstart/webapp/laravel/interactive.md b/ja-jp/articles/quickstart/webapp/laravel/interactive.md
new file mode 100644
index 0000000000..a61c8af6ae
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,229 @@
+---
+title: Add Login to a Laravel Application
+description: Auth0's Laravel SDK allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new or existing Laravel 9 or 10 application.
+budicon: 448
+topics:
+  - quickstart
+  - webapp
+  - laravel
+  - authentication
+  - login
+  - user profile
+  - logout
+  - php
+  - laravel
+github:
+  path: app
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+  - files/web
+---
+
+# Add Login to Your Laravel Application
+
+[Auth0's Laravel SDK](https://github.com/auth0/laravel-auth0) allows you to quickly add authentication, user profile management, and routing access control to your Laravel application. This guide demonstrates how to integrate Auth0 with a new (or existing) [Laravel 9 or 10](https://github.com/auth0/laravel-auth0#support-policy) application.
+
+## Laravel Installation
+
+**If you do not already have a Laravel application set up**, open a shell to a suitable directory for a new project and run the following command:
+
+```shell
+composer create-project --prefer-dist laravel/laravel auth0-laravel-app ^9.0
+```
+
+All the commands in this guide assume you are running them from the root of your Laravel project, directory so you should `cd` into the new project directory:
+
+```shell
+cd auth0-laravel-app
+```
+
+## SDK Installation
+
+Run the following command within your project directory to install the [Auth0 Laravel SDK](https://github.com/auth0/laravel-auth0):
+
+```shell
+composer require auth0/login:^7.8 --update-with-all-dependencies
+```
+
+Then generate an SDK configuration file for your application:
+
+```shell
+php artisan vendor:publish --tag auth0
+```
+
+## SDK Configuration
+
+Run the following command from your project directory to download the [Auth0 CLI](https://github.com/auth0/auth0-cli):
+
+```shell
+curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+```
+
+Then authenticate the CLI with your Auth0 account, choosing "as a user" when prompted:
+
+```shell
+./auth0 login
+```
+
+Next, create a new application with Auth0:
+
+```shell
+./auth0 apps create \
+  --name "My Laravel Application" \
+  --type "regular" \
+  --auth-method "post" \
+  --callbacks "http://localhost:8000/callback" \
+  --logout-urls "http://localhost:8000" \
+  --reveal-secrets \
+  --no-input \
+  --json > .auth0.app.json
+```
+
+You should also create a new API:
+
+```shell
+./auth0 apis create \
+  --name "My Laravel Application's API" \
+  --identifier "https://github.com/auth0/laravel-auth0" \
+  --offline-access \
+  --no-input \
+  --json > .auth0.api.json
+```
+
+This produces two files in your project directory that configure the SDK.
+
+As these files contain credentials it's important to treat these as sensitive. You should ensure you do not commit these to version control. If you're using Git, you should add them to your `.gitignore` file:
+
+```bash
+echo ".auth0.*.json" >> .gitignore
+```
+
+## Login Routes
+
+The SDK automatically registers all the necessary routes for your application's users to authenticate.
+
+| Route       | Purpose                            |
+| ----------- | ---------------------------------- |
+| `/login`    | Initiates the authentication flow. |
+| `/logout`   | Logs the user out.                 |
+| `/callback` | Handles the callback from Auth0.   |
+
+If you require more control over these, or if they conflict with existing routes in your application, you can manually register the SDK's controllers instead. Please see [the SDK's README](https://github.com/auth0/laravel-auth0) for advanced integrations.
+
+## Access Control {{{ data-action=code data-code="routes/web.php#6:12" }}}
+
+Laravel's authentication facilities use "guards" to define how users are authenticated for each request. You can use the Auth0 SDK's authentication guard to restrict access to your application's routes.
+
+To require users to authenticate before accessing a route, you can use Laravel's `auth` middleware:
+
+```php
+Route::get('/private', function () {
+  return response('Welcome! You are logged in.');
+})->middleware('auth');
+```
+
+You can also require authenticated users to have specific [permissions](https://auth0.com/docs/manage-users/access-control/rbac) by combining this with Laravel's `can` middleware:
+
+```php
+Route::get('/scope', function () {
+    return response('You have `read:messages` permission, and can therefore access this resource.');
+})->middleware('auth')->can('read:messages');
+```
+
+## User Information {{{ data-action=code data-code="routes/web.php#14:24" }}}
+
+Information about the authenticated user is available through Laravel's `Auth` Facade, or the `auth()` helper function.
+
+For example, to retrieve the user's identifier and email address:
+
+```php
+Route::get('/', function () {
+  if (! auth()->check()) {
+    return response('You are not logged in.');
+  }
+
+  $user = auth()->user();
+  $name = $user->name ?? 'User';
+  $email = $user->email ?? '';
+
+  return response("Hello {$name}! Your email address is {$email}.");
+});;
+```
+
+## User Management{{{ data-action=code data-code="routes/web.php#26:43" }}}
+
+You can update user information using the [Auth0 Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md). All Management endpoints are accessible through the SDK's `management()` method.
+
+**Before making Management API calls you must enable your application to communicate with the Management API.** This can be done from the [Auth0 Dashboard's API page](https://manage.auth0.com/#/apis/), choosing `Auth0 Management API`, and selecting the 'Machine to Machine Applications' tab. Authorize your Laravel application, and then click the down arrow to choose the scopes you wish to grant.
+
+For the following example, in which we will update a user's metadata and assign a random favorite color, you should grant the `read:users` and `update:users` scopes. A list of API endpoints and the required scopes can be found in [the Management API documentation](https://auth0.com/docs/api/management/v2).
+
+```php
+use Auth0\Laravel\Facade\Auth0;
+
+Route::get('/colors', function () {
+  $endpoint = Auth0::management()->users();
+
+  $colors = ['red', 'blue', 'green', 'black', 'white', 'yellow', 'purple', 'orange', 'pink', 'brown'];
+
+  $endpoint->update(
+    id: auth()->id(),
+    body: [
+        'user_metadata' => [
+            'color' => $colors[random_int(0, count($colors) - 1)]
+        ]
+    ]
+  );
+
+  $metadata = $endpoint->get(auth()->id());
+  $metadata = Auth0::json($metadata);
+
+  $color = $metadata['user_metadata']['color'] ?? 'unknown';
+  $name = auth()->user()->name;
+
+  return response("Hello {$name}! Your favorite color is {$color}.");
+})->middleware('auth');
+```
+
+A quick reference guide of all the SDK's Management API methods is [available here](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md).
+
+## Run the Application
+
+You are now ready to start your Laravel application, so it can accept requests:
+
+```shell
+php artisan serve
+```
+
+::::checkpoint
+:::checkpoint-default
+Open your web browser and try accessing the following routes:
+
+- [http://localhost:8000](http://localhost:8000) to see the public route.
+- [http://localhost:8000/private](http://localhost:8000/private) to be prompted to authenticate.
+- [http://localhost:8000](http://localhost:8000) to see the public route, now authenticated.
+- [http://localhost:8000/scope](http://localhost:8000/scope) to check if you have the `read:messages` [permission](https://auth0.com/docs/manage-users/access-control/rbac).
+- [http://localhost:8000/update](http://localhost:8000/update) to update the user's profile.
+- [http://localhost:8000/logout](http://localhost:8000/logout) to log out.
+
+:::
+
+:::checkpoint-failure
+Here are a couple of things to try:
+
+- Try running `php artisan optimize:clear` to clear Laravel's cache.
+- Ensure your `.auth0.app.json` and `.auth0.api.json` files are at the root of your project.
+- Ensure you have enabled your Laravel application as a Machine-to-Machine application and granted it all the necessary scopes for the `Auth0 Management API` from the [Auth0 Dashboard](https://manage.auth0.com/#/apis/).
+
+Encountering problems? Check the SDK's [documentation](https://github.com/auth0/laravel-auth0) or our [documentation hub](https://auth0.com/docs). You should also consider visiting [the community](https://community.auth0.com) where our team and other community members can help answer your questions.
+
+:::
+::::
+
+### Additional Reading
+
+- [User Repositories and Models](https://github.com/auth0/laravel-auth0/blob/main/docs/Users.md) extends the Auth0 Laravel SDK to use custom user models, and how to store and retrieve users from a database.
+- [Hooking Events](https://github.com/auth0/laravel-auth0/blob/main/docs/Events.md) covers how to listen for events raised by the Auth0 Laravel SDK, to fully customize the behavior of your integration.
+- [Management API](https://github.com/auth0/laravel-auth0/blob/main/docs/Management.md) support is built into the Auth0 Laravel SDK, allowing you to interact with the Management API from your Laravel application.
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/01-login.md b/ja-jp/articles/quickstart/webapp/nextjs/01-login.md
new file mode 100644
index 0000000000..5695369845
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/01-login.md
@@ -0,0 +1,206 @@
+---
+title: Login
+description: "This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK."
+budicon: 448
+topics:
+  - quickstarts
+  - nextjs
+  - next.js
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+---
+
+
+<%= include('../_includes/_getting_started', { library: 'Next.js', callback: 'http://localhost:3000/api/auth/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install the Auth0 Next.js SDK
+
+Run the following command within your project directory to install the Auth0 Next.js SDK:
+
+```sh
+npm install @auth0/nextjs-auth0
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your Next.js application using [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers) on the backend and [React Context](https://reactjs.org/docs/context.html) with [React Hooks](https://reactjs.org/docs/hooks-overview.html) on the frontend.
+
+### Configure the SDK
+
+In the root directory of your project, add the file `.env.local` with the following [environment variables](https://nextjs.org/docs/basic-features/environment-variables):
+
+```sh
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+AUTH0_BASE_URL='http://localhost:3000'
+AUTH0_ISSUER_BASE_URL='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
+
+- `AUTH0_SECRET`: A long secret value used to encrypt the session cookie. You can generate a suitable string using `openssl rand -hex 32` on the command line.
+- `AUTH0_BASE_URL`: The base URL of your application.
+- `AUTH0_ISSUER_BASE_URL`: The URL of your Auth0 tenant domain. If you are using a [Custom Domain with Auth0](https://auth0.com/docs/custom-domains), set this to the value of your Custom Domain instead of the value reflected in the "Settings" tab.
+- `AUTH0_CLIENT_ID`: Your Auth0 application's Client ID.
+- `AUTH0_CLIENT_SECRET`: Your Auth0 application's Client Secret.
+
+The SDK will read these values from the Node.js process environment and automatically configure itself.
+
+### Add the dynamic API route handler
+
+Create a file at `app/api/auth/[auth0]/route.js`. This is your Route Handler file with a [Dynamic Route Segment](https://nextjs.org/docs/app/building-your-application/routing/route-handlers#dynamic-route-segments).
+
+Then, import the `handleAuth` method from the SDK and call it from the `GET` export.
+
+```javascript
+// app/api/auth/[auth0]/route.js
+import { handleAuth } from '@auth0/nextjs-auth0';
+
+export const GET = handleAuth();
+```
+
+This creates the following routes:
+
+- `/api/auth/login`: The route used to perform login with Auth0.
+- `/api/auth/logout`: The route used to log the user out.
+- `/api/auth/callback`: The route Auth0 will redirect the user to after a successful login.
+- `/api/auth/me`: The route to fetch the user profile from.
+
+::: note
+This QuickStart targets the Next.js [App Router](https://nextjs.org/docs/app). If you're using the [Pages Router](https://nextjs.org/docs/pages), check out the example in the SDK's [README](https://github.com/auth0/nextjs-auth0#page-router).
+:::
+
+### Add the `UserProvider` component
+
+On the frontend side, the SDK uses React Context to manage the authentication state of your users. To make that state available to all your pages, you need to override the [Root Layout component](https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#root-layout-required) and wrap the `` tag with a `UserProvider` in the file `app/layout.jsx`. 
+
+Create the file `app/layout.jsx` as follows:
+
+```jsx
+// app/layout.jsx
+import { UserProvider } from '@auth0/nextjs-auth0/client';
+
+export default function RootLayout({ children }) {
+  return (
+    
+    
+      {children}
+    
+    
+  );
+}
+```
+
+The authentication state exposed by `UserProvider` can be accessed in any Client Component using the `useUser()` hook.
+
+:::panel Checkpoint
+Now that you have added the dynamic route and `UserProvider`, run your application to verify that your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+Users can now log in to your application by visiting the `/api/auth/login` route provided by the SDK. Add a link that points to the login route using an **anchor tag**. Clicking it redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application.
+
+:::note
+Next linting rules might suggest using the `Link` component instead of an anchor tag. The `Link` component is meant to perform [client-side transitions between pages](https://nextjs.org/docs/api-reference/next/link). As the link points to an API route and not to a page, you should keep it as an anchor tag.
+:::
+
+```html
+Login
+```
+
+:::panel Checkpoint
+Add the login link to your application. When you click it, verify that your Next.js application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects back to your application.
+:::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application
+
+Now that you can log in to your Next.js application, you need [a way to log out](https://auth0.com/docs/logout/log-users-out-of-auth0). Add a link that points to the `/api/auth/logout` API route. Clicking it redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them back to your application.
+
+```html
+Logout
+```
+
+:::panel Checkpoint
+Add the logout link to your application. When you click it, verify that your Next.js application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings".
+:::
+
+## Show User Profile Information
+
+The Auth0 Next.js SDK helps you retrieve the [profile information](https://auth0.com/docs/users/user-profiles) associated with the logged-in user, such as their name or profile picture, to personalize the user interface.
+
+### From a Client Component
+
+The profile information is available through the `user` property exposed by the `useUser()` hook. Take this [Client Component](https://nextjs.org/docs/getting-started/react-essentials#client-components) as an example of how to use it:
+
+```jsx
+'use client';
+
+import { useUser } from '@auth0/nextjs-auth0/client';
+
+export default function ProfileClient() {
+  const { user, error, isLoading } = useUser();
+
+  if (isLoading) return 
    Loading...
    ;
+  if (error) return 
    {error.message}
    ;
+
+  return (
+    user && (
+      
    
+        {user.name}
+        
    {user.name}
    
+        
    {user.email}
    
+      
    
+    )
+  );
+}
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors:
+
+- Ensure that the SDK has completed loading before accessing the `user` property by checking that `isLoading` is `false`.
+- Ensure that the SDK has loaded successfully by checking that no `error` was produced.
+- Check the `user` property to ensure that Auth0 has authenticated the user before React renders any component that consumes it.
+
+### From a Server Component
+
+The profile information is available through the `user` property exposed by the `getSession` function. Take this [Server Component](https://nextjs.org/docs/getting-started/react-essentials#server-components) as an example of how to use it:
+
+```jsx
+import { getSession } from '@auth0/nextjs-auth0';
+
+export default async function ProfileServer() {
+  const { user } = await getSession();
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
+
+:::panel Checkpoint
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::                                              
+
+## What's next?
+
+We put together a few examples of how to use [nextjs-auth0](https://github.com/auth0/nextjs-auth0) in more advanced use cases:
+
+- [Protecting a Server Side Rendered (SSR) Page](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protecting-a-server-side-rendered-ssr-page)
+- [Protecting a Client Side Rendered (CSR) Page](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protecting-a-client-side-rendered-csr-page)
+- [Protect an API Route](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#protect-an-api-route)
+- [Access an External API from an API Route](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md#access-an-external-api-from-an-api-route)
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/download.md b/ja-jp/articles/quickstart/webapp/nextjs/download.md
new file mode 100644
index 0000000000..01e6c1689f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/download.md
@@ -0,0 +1,27 @@
+
+
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000/api/auth/callback
+```
+
+2) Set **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to
+```text
+http://localhost:3000
+```
+
+3) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the root directory:
+```bash
+npm install && npm run dev
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/auth.md b/ja-jp/articles/quickstart/webapp/nextjs/files/auth.md
new file mode 100644
index 0000000000..4a7cc02805
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/auth.md
@@ -0,0 +1,12 @@
+---
+name: "app/api/auth/[auth0]/route.js"
+language: javascript
+---
+
+
+
+```javascript
+import { handleAuth } from '@auth0/nextjs-auth0';
+
+export const GET = handleAuth();
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/env.md b/ja-jp/articles/quickstart/webapp/nextjs/files/env.md
new file mode 100644
index 0000000000..22abaa809d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/env.md
@@ -0,0 +1,14 @@
+---
+name: .env.local
+language: sh
+---
+
+
+
+```sh
+AUTH0_SECRET='use [openssl rand -hex 32] to generate a 32 bytes value'
+AUTH0_BASE_URL='http://localhost:3000'
+AUTH0_ISSUER_BASE_URL='https://${account.namespace}'
+AUTH0_CLIENT_ID='${account.clientId}'
+AUTH0_CLIENT_SECRET='${account.clientSecret}'
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/layout.md b/ja-jp/articles/quickstart/webapp/nextjs/files/layout.md
new file mode 100644
index 0000000000..8567031642
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/layout.md
@@ -0,0 +1,20 @@
+---
+name: "app/layout.jsx"
+language: jsx
+---
+
+
+
+```jsx
+import { UserProvider } from '@auth0/nextjs-auth0/client';
+
+export default function RootLayout({ children }) {
+  return (
+    
+      
+        {children}
+      
+    
+  );
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/login.md b/ja-jp/articles/quickstart/webapp/nextjs/files/login.md
new file mode 100644
index 0000000000..e245a0cbbd
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/login.md
@@ -0,0 +1,12 @@
+---
+name: "app/login.jsx"
+language: jsx
+---
+
+
+
+```jsx
+export default function Login() {
+  return Login;
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/logout.md b/ja-jp/articles/quickstart/webapp/nextjs/files/logout.md
new file mode 100644
index 0000000000..60fa22031e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/logout.md
@@ -0,0 +1,12 @@
+---
+name: "app/logout.jsx"
+language: jsx
+---
+
+
+
+```jsx
+export default function Logout() {
+  return Logout;
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/profile-client.md b/ja-jp/articles/quickstart/webapp/nextjs/files/profile-client.md
new file mode 100644
index 0000000000..a4ae7102fe
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/profile-client.md
@@ -0,0 +1,29 @@
+---
+name: "app/profile-client/page.jsx"
+language: jsx
+---
+
+
+
+```jsx
+'use client';
+
+import { useUser } from '@auth0/nextjs-auth0/client';
+
+export default function ProfileClient() {
+  const { user, error, isLoading } = useUser();
+
+  if (isLoading) return 
    Loading...
    ;
+  if (error) return 
    {error.message}
    ;
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/files/profile-server.md b/ja-jp/articles/quickstart/webapp/nextjs/files/profile-server.md
new file mode 100644
index 0000000000..1f164c403a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/files/profile-server.md
@@ -0,0 +1,24 @@
+---
+name: "app/profile-server/page.jsx"
+language: jsx
+---
+
+
+
+```jsx
+import { getSession } from '@auth0/nextjs-auth0';
+
+export default async function ProfileServer() {
+  const { user } = await getSession();
+
+  return (
+      user && (
+          
    
+            {user.name}
+            
    {user.name}
    
+            
    {user.email}
    
+          
    
+      )
+  );
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/index.yml b/ja-jp/articles/quickstart/webapp/nextjs/index.yml
new file mode 100644
index 0000000000..ad6a5b3b9a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/index.yml
@@ -0,0 +1,39 @@
+title: Next.js
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/nginx-plus.png
+logo: nextjs
+alias:
+  - next
+  - nextjs
+  - next.js
+language:
+  - Javascript
+framework:
+  - Next.js
+author:
+  name: Rita Zerrizuela
+  email: rita.zerrizuela@auth0.com
+  community: false
+
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+seo_alias: nextjs
+show_releases: true
+show_steps: true
+requirements:
+  - Next.js 13.4+
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+sdk:
+  name: nextjs-auth0
+  url: https://github.com/auth0/nextjs-auth0/
+  logo: nextjs
+github:
+  org: auth0-samples
+  repo: auth0-nextjs-samples
+  branch: main
diff --git a/ja-jp/articles/quickstart/webapp/nextjs/interactive.md b/ja-jp/articles/quickstart/webapp/nextjs/interactive.md
new file mode 100644
index 0000000000..360ae01269
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,172 @@
+---
+title: Add Login to your Next.js application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK.
+topics:
+  - quickstarts
+  - webapp
+  - nextjs
+  - login
+github:
+  path: Sample-01
+contentType: tutorial
+useCase: quickstart
+interactive: true
+files:
+ - files/auth
+ - files/env
+ - files/layout
+ - files/login
+ - files/logout
+ - files/profile-client
+ - files/profile-server
+---
+
+
+
+# Add Login to Your Next.js Application
+
+This guide demonstrates how to integrate Auth0 with any new or existing Next.js application using the Auth0 Next.js SDK. We recommend that you log in to follow this quickstart with examples configured for your account.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/api/auth/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install the Auth0 Next.js SDK
+
+Run the following command within your project directory to install the Auth0 Next.js SDK:
+
+```sh
+npm install @auth0/nextjs-auth0
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your Next.js application using [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers) on the backend and [React Context](https://reactjs.org/docs/context.html) with [React Hooks](https://reactjs.org/docs/hooks-overview.html) on the frontend.
+
+## Configure the SDK {{{ data-action=code data-code=".env.local" }}}
+
+In the root directory of your project, add the file `.env.local` with the following [environment variables](https://nextjs.org/docs/basic-features/environment-variables):
+
+- `AUTH0_SECRET`: A long secret value used to encrypt the session cookie. You can generate a suitable string using `openssl rand -hex 32` on the command line.
+- `AUTH0_BASE_URL`: The base URL of your application.
+- `AUTH0_ISSUER_BASE_URL`: The URL of your Auth0 tenant domain. If you are using a [Custom Domain with Auth0](https://auth0.com/docs/custom-domains), set this to the value of your Custom Domain instead of the value reflected in the "Settings" tab.
+- `AUTH0_CLIENT_ID`: Your Auth0 application's Client ID.
+- `AUTH0_CLIENT_SECRET`: Your Auth0 application's Client Secret.
+
+The SDK will read these values from the Node.js process environment and automatically configure itself.
+
+## Add the dynamic Route Handler {{{ data-action=code data-code="app/api/auth/[auth0]/route.js" }}}
+
+::: note
+This QuickStart targets the Next.js [App Router](https://nextjs.org/docs/app). If you're using the [Pages Router](https://nextjs.org/docs/pages), check out the example in the SDK's [README](https://github.com/auth0/nextjs-auth0#page-router).
+:::
+
+Create a file at `app/api/auth/[auth0]/route.js`. This is your Route Handler file with a [Dynamic Route Segment](https://nextjs.org/docs/app/building-your-application/routing/route-handlers#dynamic-route-segments).
+
+Then, import the `handleAuth` method from the SDK and call it from the `GET` export. This creates the following routes:
+
+- `/api/auth/login`: The route used to perform login with Auth0.
+- `/api/auth/logout`: The route used to log the user out.
+- `/api/auth/callback`: The route Auth0 will redirect the user to after a successful login.
+- `/api/auth/me`: The route to fetch the user profile from.
+
+## Add the `UserProvider` component {{{ data-action=code data-code="app/layout.jsx" }}}
+
+On the frontend side, the SDK uses React Context to manage the authentication state of your users. To make that state available to all your pages, you need to override the [Root Layout component](https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#root-layout-required) and wrap the `` tag with a `UserProvider` in the file `app/layout.jsx`.
+
+The authentication state exposed by `UserProvider` can be accessed in any Client Component using the `useUser()` hook.
+
+::::checkpoint
+:::checkpoint-default
+Now that you have added the route handler and `UserProvider`, run your application to verify that your application is not throwing any errors related to Auth0.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* Are your environment variables populated correctly?
+* did you put the `app/api/auth/[auth0]/route.js` and `app/layout.jsx` files in the correct folder?
+* make sure the domain and client ID are configured correctly
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add Login to Your Application {{{ data-action=code data-code="app/login.jsx" }}}
+
+Users can now log in to your application by visiting the `/api/auth/login` route handler provided by the SDK. Add a link that points to the login route using an **anchor tag**. Clicking it redirects your users to the Auth0 Universal Login Page, where Auth0 can authenticate them. Upon successful authentication, Auth0 will redirect your users back to your application.
+
+:::note
+Next linting rules might suggest using the `Link` component instead of an anchor tag. The `Link` component is meant to perform [client-side transitions between pages](https://nextjs.org/docs/api-reference/next/link). As the link points to an API route and not to a page, you should keep it as an anchor tag.
+:::
+
+::::checkpoint
+:::checkpoint-default
+Add the login link to your application. 
+- When you click it, verify that your Next.js application redirects you to the [Auth0 Universal Login](https://auth0.com/universal-login) page and that you can now log in or sign up using a username and password or a social provider.
+- Once that's complete, verify that Auth0 redirects back to your application.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure that "Allowed Callback URLs" is configured correctly in your tenant
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+![Auth0 Universal Login](/media/quickstarts/universal-login.png)
+
+<%= include('../_includes/_auth_note_dev_keys') %>
+
+## Add Logout to Your Application {{{ data-action=code data-code="app/logout.jsx" }}}
+
+Now that you can log in to your Next.js application, you need [a way to log out](https://auth0.com/docs/logout/log-users-out-of-auth0). Add a link that points to the `/api/auth/logout` API route. Clicking it redirects your users to your [Auth0 logout endpoint](https://auth0.com/docs/api/authentication?javascript#logout) (`https://YOUR_DOMAIN/v2/logout`) and then immediately redirects them back to your application.
+
+::::checkpoint
+:::checkpoint-default
+Add the logout link to your application. When you click it, verify that your Next.js application redirects you to the address you specified as one of the "Allowed Logout URLs" in the "Settings".
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure that "Allowed Logout URLs" is configured correctly in your tenant
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show User Profile Information from a Client Component{{{ data-action=code data-code="app/profile-client/page.jsx" }}}
+
+The Auth0 Next.js SDK helps you retrieve the [profile information](https://auth0.com/docs/users/user-profiles) associated with the logged-in user, such as their name or profile picture, to personalize the user interface.
+
+The profile information is available through the `user` property exposed by the `useUser()` hook. Take this [Client Component](https://nextjs.org/docs/getting-started/react-essentials#client-components) `ProfileClient` as an example of how to use it.
+
+::::checkpoint
+:::checkpoint-default
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure the SDK has finished loading using the `loading` property
+* make sure there are no errors in the `error` property or the console
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show User Profile Information from a Server Component{{{ data-action=code data-code="app/profile-server/page.jsx" }}}
+
+The profile information is available through the `user` property exposed by the `getSession` function. Take this [Server Component](https://nextjs.org/docs/getting-started/react-essentials#server-components) `ProfileServer` as an example of how to use it.
+
+::::checkpoint
+:::checkpoint-default
+Verify that you can display the `user.name` or [any other](https://auth0.com/docs/users/user-profile-structure#user-profile-attributes) `user` property within a component correctly after you have logged in.
+:::
+:::checkpoint-failure
+Sorry about that. Here's a couple of things to double check:
+* are your environment variables populated correctly?
+* make sure you have successfully logged in through the `/api/auth/login` handler.
+* make sure there are no errors in the console
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/01-login.md b/ja-jp/articles/quickstart/webapp/nginx-plus/01-login.md
new file mode 100644
index 0000000000..7a72a42e7f
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/01-login.md
@@ -0,0 +1,79 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to use the `nginx-openid-connect` module to add authentication and authorization to your NGINX server.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - nginx
+  - nginx+
+  - nginx plus
+  - login
+contentType: tutorial
+useCase: quickstart
+---
+
+::: panel System Requirements
+This tutorial and seed project have been tested with the following:
+* NGINX Plus R24
+:::
+
+**Please follow the steps below to configure your application using [NGINX Plus](https://www.nginx.com/products/nginx/) to work with Auth0 and Open ID Connect.**
+
+## Install and Enable `nginx-plus-module-njs` Module
+
+First, you need to install the nginx-plus-module-njs module for NGINX Plus. Follow the [dynamic module installation guide](https://www.nginx.com/products/nginx/dynamic-modules/) to install packages in your host OS. 
+For Linux distributions that use `yum` package manager install as follows:
+
+```bash
+sudo yum install nginx-plus-module-njs jq
+```
+
+Once you've installed it, you need to enable it for NGINX by adding the following line near the top of your `/etc/nginx/nginx.conf` file:
+
+${snippet(meta.snippets.module)}
+
+## Checkout `nginx-openid-connect` Template Repository
+Clone [`nginx-openid-connect` GitHub repository](https://github.com/nginxinc/nginx-openid-connect). This repository comes with a template configuration.
+
+```bash
+git clone https://github.com/nginxinc/nginx-openid-connect
+```
+
+## Configure with Your Auth0 Application Information
+Run the `configure.sh` script inside nginx-openid-connect folder to populate template configuration for your Auth0 application:
+
+${snippet(meta.snippets.setup)}
+
+Next, add your tenant’s logout URL to `openid_connect_configuration.conf` file
+
+${snippet(meta.snippets.logout)}
+
+## Set Accept-Encoding Type for Token and JWKS Endpoints
+
+Add `Accept-Encoding` header in `openid_connect.server_conf`
+
+${snippet(meta.snippets.token)}
+
+## Copy OpenID Connect Config Files to NGINX Server
+
+You need to copy four files to the config folder of NGINX server machine
+
+```bash
+sudo cp openid_connect.js \ 
+   frontend.conf \
+   openid_connect_configuration.conf \
+   openid_connect.server_conf /etc/nginx/conf.d
+```
+        
+## Configuring Auth0 Settings
+
+In your application settings add a new "Allowed Callback URLs" that is equal to `https://server-fqdn/_codexch`.
+
+Then, change "Token Endpoint Authentication Method" to "None" in Auth0 for your Application. This is required for PKCE authorisation code flow.
+
+## Passing Headers to Upstream Application
+Edit `/etc/nginx/conf.d/frontend.conf` and add additional headers from `id_token` to the upstream target:
+
+${snippet(meta.snippets.use)}
diff --git a/ja-jp/articles/quickstart/webapp/nginx-plus/index.yml b/ja-jp/articles/quickstart/webapp/nginx-plus/index.yml
new file mode 100644
index 0000000000..7431ea964a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/index.yml
@@ -0,0 +1,22 @@
+title: NGINX Plus
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/nginx-plus.png
+logo: nginx
+author:
+  name: Amin Abbaspour
+  email: amin.abbaspour@auth0.com
+  community: false
+topics:
+  - quickstart
+snippets:
+  module: server-platforms/nginx-plus/module
+  setup: server-platforms/nginx-plus/setup
+  logout: server-platforms/nginx-plus/logout
+  token: server-platforms/nginx-plus/token
+  use: server-platforms/nginx-plus/use
+seo_alias: nginx
+default_article: 01-login
+articles:
+  - 01-login
+contentType: tutorial
+useCase: quickstart
diff --git a/ja-jp/articles/quickstart/webapp/php/01-login.md b/ja-jp/articles/quickstart/webapp/php/01-login.md
new file mode 100644
index 0000000000..4017d55c00
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/01-login.md
@@ -0,0 +1,216 @@
+---
+title: Login
+default: true
+description: This guide demonstrates how to integrate Auth0 with a PHP application using the Auth0 PHP SDK.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - php
+contentType: tutorial
+useCase: quickstart
+github:
+  path: app
+---
+
+
+<%= include('../_includes/_getting_started', { library: 'PHP', callback: 'http://127.0.0.1:3000/' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://127.0.0.1:3000' }) %>
+
+## Integrate your PHP application
+
+Let's create a sample application that authenticates a user with a PHP application. We'll take a simple approach here, appropriate for the written format. Still, you should check out the accompanying [Quickstart app on GitHub](https://github.com/auth0-samples/auth0-php-web-app/) for a more robust example.
+
+### Installing HTTP Client and Messaging Factories
+
+The Auth0 PHP SDK supports many [PHP-FIG](https://www.php-fig.org) standards offering interoperability options with your architecture. Two of particular importance are [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/). These standards allow you to plug-in networking components of your choice to handle messaging and requests. You will need to install compatible libraries in your project for the SDK to use.
+
+The most prolific networking library for PHP is [Guzzle](https://guzzlephp.org), although many are available to pick from within the PHP community. Let's use Guzzle for this sample application. Once again, from your project directory, run the following shell command:
+
+```sh
+composer require guzzlehttp/guzzle guzzlehttp/psr7 http-interop/http-factory-guzzle
+```
+
+### Installing the PHP SDK
+
+${snippet(meta.snippets.install)}
+
+### Configuring the SDK
+
+To begin, let's create a `.env` file within the root of your project directory to store our sample application's configuration and fill in the environment variables:
+
+```sh
+# Your Auth0 application's Client ID
+AUTH0_CLIENT_ID=${account.clientId}
+
+# The URL of your Auth0 tenant domain
+AUTH0_DOMAIN=${account.namespace}
+
+# Your Auth0 application's Client Secret
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+
+# A long, secret value used to encrypt the session cookie.
+# This can be generated using `openssl rand -hex 32` from your shell.
+AUTH0_COOKIE_SECRET=
+
+# A url your application is accessible from. Update this as appropriate.
+AUTH0_BASE_URL=http://127.0.0.1:3000
+```
+
+As PHP isn't able to read our `.env` file by itself, we'll want to install a library to help with that. Although we'll be using a particular library for our sample application's purposes, in a real world application any 'dotenv' loader of preference will work. From our project directory, let's run the following shell command to install the library:
+
+```sh
+composer require vlucas/phpdotenv
+```
+
+Next, let's create the PHP source file we'll be using for these code samples, `index.php`, and let's configure an instance of the Auth0 PHP SDK for our sample application:
+
+```php
+load();
+
+// Now instantiate the Auth0 class with our configuration:
+$auth0 = new \Auth0\SDK\Auth0([
+    'domain' => $_ENV['AUTH0_DOMAIN'],
+    'clientId' => $_ENV['AUTH0_CLIENT_ID'],
+    'clientSecret' => $_ENV['AUTH0_CLIENT_SECRET'],
+    'cookieSecret' => $_ENV['AUTH0_COOKIE_SECRET']
+]);
+```
+
+### Setting up your application routes
+
+Modern PHP applications use a routing pattern to pass incoming HTTP requests to the code that handles them, determining what should happen when our users visit a particular "page" in our app. There is no single, correct way of implementing routing in your application, and there are many libraries to choose from to implement it. We'll be using one particular library for our sample application's purposes, but feel free to select your own in a real-world application.
+
+From our project directory, let's run the following shell command to install the routing library:
+
+```sh
+composer require steampixel/simple-php-router
+```
+
+Next, let's open our `index.php` back up and give our application life. Start by importing the routing library and defining our sample application's route's full URLs as named constants for convenience sake, as we'll need to reference them in a few places through our sample application:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// Import our router library:
+use Steampixel\Route;
+
+// Define route constants:
+define('ROUTE_URL_INDEX', rtrim($_ENV['AUTH0_BASE_URL'], '/'));
+define('ROUTE_URL_LOGIN', ROUTE_URL_INDEX . '/login');
+define('ROUTE_URL_CALLBACK', ROUTE_URL_INDEX . '/callback');
+define('ROUTE_URL_LOGOUT', ROUTE_URL_INDEX . '/logout');
+```
+
+Now we can move on to adding our application's route handling logic, and the SDK integrations:
+
+## Checking for a session
+
+The Auth0 PHP SDK has a convenient method for checking if our user has authenticated and returned their profile, `getCredentials()`. Let's install this on our index route to print the user profile if they're logged in or report that they need to login.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/', function() use ($auth0) {
+  $session = $auth0->getCredentials();
+
+  if ($session === null) {
+    // The user isn't logged in.
+    echo '
    Please log in.
    ';
+    return;
+  }
+
+  // The user is logged in.
+  echo '
    ';
+  print_r($session->user);
+  echo '
    ';
+
+  echo '
    You can now log out.
    ';
+});
+```
+
+We can access all the properties of our user's profile from the `user` property response, which is an array. So, for example, we can pull the user's nickname using `$session->user['nickname']`, or their email address from `$session->user['email']`. The structure is a [normalized user profile](https://auth0.com/docs/users/user-profile-structure), which you can learn more about [here](https://auth0.com/docs/users/normalized-user-profiles).
+
+It's important to note that the content of the user profile will vary depending on the social provider(s) you use, so you should never assume that a particular value will always be there within your application logic. Use PHP language constructs like `isset` or null coalescence to gracefully handle a value's presence, or lack thereof, for example:
+
+```PHP
+// ✋ We don't need to include this in our sample application, it's just an example.
+$name = $session->user['name'] ?? $session->user['nickname'] ?? $session->user['email'] ?? 'Unknown';
+```
+
+## Logging in
+
+Now let's create our /login route, which will use the Auth0 PHP SDK's `login()` method to set up the user session and return a customized URL to Auth0's Universal Login Page for this user to login.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/login', function() use ($auth0) {
+    // It's a good idea to reset user sessions each time they go to login to avoid "invalid state" errors, should they hit network issues or other problems that interrupt a previous login process:
+    $auth0->clear();
+
+    // Finally, set up the local application session, and redirect the user to the Auth0 Universal Login Page to authenticate.
+    header("Location: " . $auth0->login(ROUTE_URL_CALLBACK));
+    exit;
+});
+```
+
+## Handling authentication callback
+
+After our users return from authenticating with the Auth0's Universal Login Page, they'll return to our sample application at our callback route, `/callback` which we'll handle in this step.
+
+When Auth0 passes our users back to us, it includes a few essential parameters in the query of the HTTP request. The Auth0 PHP SDK's `exchange()` method handles working with those, so finishing our authentication flow is straightforward:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/callback', function() use ($auth0) {
+    // Have the SDK complete the authentication flow:
+    $auth0->exchange(ROUTE_URL_CALLBACK);
+
+    // Finally, redirect our end user back to the / index route, to display their user profile:
+    header("Location: " . ROUTE_URL_INDEX);
+    exit;
+});
+```
+
+## Logging out
+
+Last but not least, let's properly handle logging our users out. The `logout()` method of the Auth0 PHP SDK handles clearing our sample application's session cookies, redirecting the user to Auth0's [/logout endpoint](https://auth0.com/docs/logout) (which logs out Auth0 session layer and any identify provider session layers), and then return the user to our / index route.
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+Route::add('/logout', function() use ($auth0) {
+    // Clear the user's local session with our app, then redirect them to the Auth0 logout endpoint to clear their Auth0 session.
+    header("Location: " . $auth0->logout(ROUTE_URL_INDEX));
+    exit;
+});
+```
+
+## Run your app!
+
+Last but not least, we need to tell our routing middleware to actually route requests:
+
+```PHP
+// 👆 We're continuing from the steps above. Append this to your index.php file.
+
+// This tells our router that we've finished configuring our routes, and we're ready to begin routing incoming HTTP requests:
+Route::run('/');
+```
+
+That's it! You're ready to run your new application; once again, from your project directory, run the following shell command:
+
+```sh
+php -S 127.0.0.1:3000 index.php
+```
+
+Open your browser to http://127.0.0.1:3000 and try it out.
diff --git a/ja-jp/articles/quickstart/webapp/php/download.md b/ja-jp/articles/quickstart/webapp/php/download.md
new file mode 100644
index 0000000000..f7fe450755
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/download.md
@@ -0,0 +1,25 @@
+To run the sample follow these steps:
+
+1. Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://127.0.0.1:3000/callback
+```
+
+2. Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://127.0.0.1:3000/logout
+```
+
+3. Make sure [PHP](http://php.net/downloads.php) and [Composer](https://getcomposer.org/download/) are installed and execute the following commands in the sample's directory:
+
+```bash
+composer run app
+```
+
+You can also run it from [Docker](https://www.docker.com) with the following commands:
+
+```bash
+composer run docker
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/files/callback.md b/ja-jp/articles/quickstart/webapp/php/files/callback.md
new file mode 100644
index 0000000000..6d75868f9c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/files/callback.md
@@ -0,0 +1,39 @@
+---
+name: callback.php
+language: php
+---
+
+```php
+exchange();
+    } catch (\Throwable $th) {
+      printf('Unable to complete authentication: %s', $th->getMessage());
+      exit;
+    }
+  }
+
+  // When authentication was unsuccessful, the end user will be returned with an ?error in their request.
+  if ($hasAuthenticationFailure) {
+    printf('Authentication failure: %s', htmlspecialchars(strip_tags(filter_input(INPUT_GET, 'error'))));
+    exit;
+  }
+
+  // Nothing to do: redirect to index route.
+  header('Location: /');
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/files/index.md b/ja-jp/articles/quickstart/webapp/php/files/index.md
new file mode 100644
index 0000000000..f68135b6cd
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/files/index.md
@@ -0,0 +1,27 @@
+---
+name: index.php
+language: php
+---
+
+```php
+login()));
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/files/logout.md b/ja-jp/articles/quickstart/webapp/php/files/logout.md
new file mode 100644
index 0000000000..e497de4cf5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/files/logout.md
@@ -0,0 +1,18 @@
+---
+name: logout.php
+language: php
+---
+
+```php
+logout()));
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/files/profile.md b/ja-jp/articles/quickstart/webapp/php/files/profile.md
new file mode 100644
index 0000000000..1b5c48b9c6
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/files/profile.md
@@ -0,0 +1,25 @@
+---
+name: profile.php
+language: php
+---
+
+```php
+getCredentials();
+  $authenticated = $session !== null;
+
+  $template = [
+    'name' => $authenticated ? $session->user['email'] : 'guest',
+    'picture' => $authenticated ? $session->user['picture'] : null,
+    'session' => $authenticated ? print_r($session, true) : '',
+    'auth:route' => $authenticated ? 'logout' : 'login',
+    'auth:text' => $authenticated ? 'out' : 'in',
+  ];
+
+  printf('
    Welcome, %s.
    ', $template['name']);
+  printf('
    %s
    ', $template['session']);
+  printf('
    Log %s
    ', $template['auth:route'], $template['auth:text']);
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/files/router.md b/ja-jp/articles/quickstart/webapp/php/files/router.md
new file mode 100644
index 0000000000..ca4bf82b9b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/files/router.md
@@ -0,0 +1,34 @@
+---
+name: router.php
+language: php
+---
+
+```php
+This quickstart is configured to be run from http://localhost:3000.
    ');
+  }
+
+  Route::add('/', function() use ($sdk) {
+    require('profile.php');
+  });
+
+  Route::add('/login', function() use ($sdk) {
+    require('login.php');
+  });
+
+  Route::add('/callback', function() use ($sdk) {
+    require('callback.php');
+  });
+
+  Route::add('/logout', function() use ($sdk) {
+    require('logout.php');
+  });
+
+  Route::run();
+```
diff --git a/ja-jp/articles/quickstart/webapp/php/index.yml b/ja-jp/articles/quickstart/webapp/php/index.yml
new file mode 100644
index 0000000000..2613a515a4
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/index.yml
@@ -0,0 +1,53 @@
+title: PHP
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/php.png
+logo: php
+seo_alias: php
+alias:
+  - php
+languages:
+  - PHP
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+thirdParty: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  install: server-platforms/php/install
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - 'interactive'
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-php-web-app
+  branch: main
+sdk:
+  name: Auth0-PHP
+  url: https://github.com/auth0/auth0-php
+  logo: php
+requirements:
+  - PHP 7.4+ (8.0 recommended)
+  - Auth0-PHP 8.0
+  - Composer
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/webapp/php/interactive.md b/ja-jp/articles/quickstart/webapp/php/interactive.md
new file mode 100644
index 0000000000..c127953da3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/php/interactive.md
@@ -0,0 +1,194 @@
+---
+title: Add Login to your PHP application
+description: "Auth0 allows you to add authentication to your PHP application quickly and to gain access to user profile information. This guide demonstrates how to integrate Auth0 with any new or existing PHP application using the Auth0 PHP SDK."
+interactive: true
+files:
+  - files/index
+  - files/login
+  - files/logout
+  - files/profile
+  - files/router
+  - files/callback
+github:
+  path: app
+---
+
+# Add Login to Your PHP Application
+
+Auth0 allows you to add authentication to almost any application type quickly. This guide demonstrates how to integrate Auth0, add authentication, and display user profile information in any PHP application using the Auth0 PHP SDK.
+
+To use this quickstart, you’ll need to:
+- Sign up for a free Auth0 account or log in to Auth0.
+- Have a working PHP project that you want to integrate with. Alternatively, you can view or download a sample application after logging in.
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000/callback.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000.
+:::
+
+### Configure Allowed Web Origins
+
+An Allowed Web Origin is a URL that you want to be allowed to access to your authentication flow. This must contain the URL of your project. If not properly set, your project will be unable to silently refresh authentication tokens, so your users will be logged out the next time they visit your application or refresh a page.
+
+::: note
+If you are following along with our sample project, set this to http://localhost:3000.
+:::
+
+## Install the Auth0 PHP SDK {{{ data-action=code data-code="index.php" }}}
+
+Auth0 provides a [PHP SDK](https://github.com/auth0/auth0-PHP) (Auth0-PHP) to simplify the process of implementing Auth0 authentication and authorization in PHP apps.
+
+The Auth0 PHP SDK requires [PSR-17](https://www.php-fig.org/psr/psr-17/) and [PSR-18](https://www.php-fig.org/psr/psr-18/) compatible HTTP libraries to be installed for managing network requests. If you don't have libraries available, you can install reliable choices by running the following commands in your terminal:
+
+```bash
+cd 
+composer require symfony/http-client nyholm/psr7
+```
+
+Now install the Auth0 PHP SDK by running the following command in your terminal:
+
+```bash
+composer require auth0/auth0-php
+```
+
+### Configure the Auth0 SDK
+
+Create a new file in your application called `index.php`, and copy in the code from the interactive panel to the right under the index.php tab.
+
+For the SDK to function properly, you must set the following properties in the Auth0 SDK during initialization:
+
+- `domain`: The domain of your Auth0 tenant. Generally, you can find this in the Auth0 Dashboard under your Application's Settings in the Domain field. If you are using a [custom domain](https://auth0.com/docs/custom-domains), you should set this to the value of your custom domain instead.
+- `clientId`: The ID of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
+- `clientSecret`: The secret of the Auth0 Application you set up earlier in this quickstart. You can find this in the Auth0 Dashboard under your Application's Settings in the Client Secret field.
+- `redirectUri`: The URL in your application that you would like Auth0 to redirect users to after they have authenticated. This corresponds to the callback URL you set up earlier in this quickstart. You can also find this value in the Auth0 Dashboard under your Application's Settings in the Callback URLs field. Make sure what you enter in your code matches what you set up earlier or your users will see an error.
+- `cookieSecret`: A long secret value used to encrypt the session cookie. You can generate a suitable string by running `openssl rand -hex 32` in your terminal.
+
+::::checkpoint
+:::checkpoint-default
+
+Your Auth0 SDK should now be properly configured. Run your application to verify that:
+- The SDK is initializing correctly.
+- Your application is not throwing any errors related to Auth0.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* Make sure the correct application is selected.
+* Did you save after entering your URLs?
+* Make sure the domain and client ID imported correctly.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Create routes {{{ data-action=code data-code="router.php" }}}
+
+Now install a routing library, to help direct incoming requests to your application. This isn't a required step, but simplifies our application structure for the purposes of this quickstart.
+
+```bash
+composer require steampixel/simple-php-router
+```
+
+Create a new file in your application called `router.php` to define our routes, and copy in the code from the interactive panel to the right.
+
+## Add login to your application {{{ data-action=code data-code="login.php" }}}
+
+Now that you have configured your Auth0 Application and the Auth0 PHP SDK, you need to set up login for your project. To do this, you will use the SDK’s `login()` method to create a login button that redirects users to the Auth0 Universal Login page. After a user successfully authenticates, they will be redirected to the callback URL you set up earlier in this quickstart.
+
+Create a new file in your application called `login.php` to handle logging process, and copy in the code from the interactive panel to the right, which contains the logic needed for login.
+
+::::checkpoint
+:::checkpoint-default
+
+You should now be able to log in or sign up using a username and password.
+
+Click the login link and verify that:
+* Your application redirects you to the Auth0 Universal Login page.
+* You can log in or sign up.
+* Auth0 redirects you back to your application using the value of the `redirectUri` you used to configure the SDK.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You configured the correct `redirectUri`.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
+
+## Add logout to your application {{{ data-action=code data-code="logout.php" }}}
+
+Users who log in to your project will also need a way to log out. We will handle a logout button using the SDK’s `logout()` method. When users log out, they will be redirected to your [Auth0 logout](https://auth0.com/docs/api/authentication?http#logout) endpoint, which will then immediately redirect them to the logout URL you set up earlier in this quickstart.
+
+Create a new file in your application called `logout.php` for handling the process, and copy in the code from the interactive panel, which contains the logic needed for logout. Then, update your `index.php` file to include the logout button.
+
+::::checkpoint
+:::checkpoint-default
+
+Run your application and click the logout button, verify that:
+* Your application redirects you to the address you specified as one of the Allowed Logout URLs in your Application Settings.
+* You are no longer logged in to your application.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You configured the correct Logout URL.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+
+::::
+
+## Show User Profile Information {{{ data-action=code data-code="profile.php" }}}
+
+Now that your users can log in and log out, you will likely want to be able to retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with authenticated users. For example, you may want to be able to display a logged-in user’s name or profile picture in your project.
+
+The Auth0 PHP SDK provides user information through the `getCredentials()` method. Review the `profile.php` code in the interactive panel to see an example of how to use it.
+
+Because the method contains sensitive information related to the user's identity, its availability depends on the user's authentication status. To prevent render errors, you should always check if the `getCredentials()` method returns an `object` or `null` to determine whether Auth0 has authenticated the user before your application consumes the results.
+
+::::checkpoint
+:::checkpoint-default
+
+Verify that:
+* You can display the `nickname` or any other user property correctly after you have logged in.
+
+:::
+
+:::checkpoint-failure
+Sorry about that. Here's a couple things to double check:
+* You created the `profile.php` file and are logged in.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+
+:::
+::::
diff --git a/ja-jp/articles/quickstart/webapp/python/01-login.md b/ja-jp/articles/quickstart/webapp/python/01-login.md
new file mode 100644
index 0000000000..0a570d856c
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/01-login.md
@@ -0,0 +1,219 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login to a Python web Application built with the Flask framework and Authlib OAuth library.
+budicon: 448
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - flask
+github:
+    path: 01-Login
+---
+<%= include('../_includes/_getting_started', { library: 'Python', callback: 'http://localhost:3000/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install dependencies
+
+For the purposes of this example, we'll be using the [Authlib](https://authlib.org/) OAuth library and [Flask](https://flask.palletsprojects.com/en/2.0.x/).
+
+Begin by creating a `requirements.txt` file in your project directory:
+
+```python
+# 📁 requirements.txt -----
+
+flask>=2.0.3
+python-dotenv>=0.19.2
+authlib>=1.0
+requests>=2.27.1
+```
+
+You should now run `pip install -r requirements.txt` from your shell to make these dependencies available to your project.
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+APP_SECRET_KEY=
+
+```
+
+- Generate a suitable string for `APP_SECRET_KEY` using `openssl rand -hex 32` from your shell.
+
+## Setup your application
+
+Now you're ready to start writing your application. Create a `server.py` file in your project directory - this file will hold all of your application logic.
+
+Begin by importing all the libraries your application will be making use of:
+
+```python
+# 📁 server.py -----
+
+import json
+from os import environ as env
+from urllib.parse import quote_plus, urlencode
+
+from authlib.integrations.flask_client import OAuth
+from dotenv import find_dotenv, load_dotenv
+from flask import Flask, redirect, render_template, session, url_for
+```
+
+Next, your application will need to load the configuration `.env` file you made in the previous step:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+```
+
+Now you can configure Flask for your application's needs:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+app = Flask(__name__)
+app.secret_key = env.get("APP_SECRET_KEY")
+```
+
+Finally, you can now configure Authlib to handle your application's authentication with Auth0:
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+oauth = OAuth(app)
+
+oauth.register(
+    "auth0",
+    client_id=env.get("AUTH0_CLIENT_ID"),
+    client_secret=env.get("AUTH0_CLIENT_SECRET"),
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f'https://{env.get("AUTH0_DOMAIN")}/.well-known/openid-configuration'
+)
+```
+
+You can learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your routes
+
+For this demonstration, we'll be adding 4 routes for your application: your login, callback, logout and home routes.
+
+### Triggering authentication with `/login`
+When visitors to your app visit the `/login` route, they'll be redirected to Auth0 to begin the authentication flow.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/login")
+def login():
+    return oauth.auth0.authorize_redirect(
+        redirect_uri=url_for("callback", _external=True)
+    )
+```
+
+### Finalizing authentication with `/callback`
+After your users finish logging in with Auth0, they'll be returned to your application at the `/callback` route. This route is responsible for actually saving the session for the user, so when they visit again later, they won't have to sign back in all over again.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/callback", methods=["GET", "POST"])
+def callback():
+    token = oauth.auth0.authorize_access_token()
+    session["user"] = token
+    return redirect("/")
+```
+
+### Clearing a session with `/logout`
+As you might expect, this route handles signing a user out from your application. It will clear the user's session in your app, and briefly redirect to Auth0's logout endpoint to ensure their session is completely clear, before they are returned to your home route (covered next.)
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/logout")
+def logout():
+    session.clear()
+    return redirect(
+        "https://" + env.get("AUTH0_DOMAIN")
+        + "/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": url_for("home", _external=True),
+                "client_id": env.get("AUTH0_CLIENT_ID"),
+            },
+            quote_via=quote_plus,
+        )
+    )
+```
+
+### There's no place like `/home`
+Last but not least, your home route will serve as a place to either render an authenticated user's details, or offer to allow visitors to sign in.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+@app.route("/")
+def home():
+    return render_template("home.html", session=session.get('user'), pretty=json.dumps(session.get('user'), indent=4))
+```
+
+### Server instantiation
+Finally, you'll need to add some small boilerplate code for Flask to actually run your app and listen for connections.
+
+```python
+# 👆 We're continuing from the steps above. Append this to your server.py file.
+
+if __name__ == "__main__":
+    app.run(host="0.0.0.0", port=env.get("PORT", 3000))
+```
+
+## Add templates
+
+Now we just need to create the simple template files used in the routes about (during `render_template()` calls).
+
+Create a new sub-directory in your project folder named `templates`, and create two files within: `dashboard.html` and `home.html`. You can paste the content from the two fields below into those files, respectfully:
+
+```html
+# 📁 templates/home.html -----
+
+
+  
+    
+    Auth0 Example
+  
+  
+    {% if session %}
+        
    Welcome {{session.userinfo.name}}!
    
+        
    Logout
    
+        
    {{pretty}}
    
+    {% else %}
+        
    Welcome Guest
    
+        
    Login
    
+    {% endif %}
+  
+
+```
+
+## Run your application
+
+You're ready to run your application! From your project directory, open a shell and use:
+
+```sh
+python3 server.py
+```
+
+Your application should now be ready to open from your browser at [http://localhost:3000](http://localhost:3000).
diff --git a/ja-jp/articles/quickstart/webapp/python/download.md b/ja-jp/articles/quickstart/webapp/python/download.md
new file mode 100644
index 0000000000..588081ac0e
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/download.md
@@ -0,0 +1,27 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000
+```
+
+3) Make sure [Python](https://www.python.org/downloads/) is installed and execute the following commands in the sample's directory:
+```bash
+pip install -r requirements.txt
+python3 server.py
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/ja-jp/articles/quickstart/webapp/python/files/home.md b/ja-jp/articles/quickstart/webapp/python/files/home.md
new file mode 100644
index 0000000000..8a0f7e8dc5
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/files/home.md
@@ -0,0 +1,25 @@
+---
+name: templates/home.html
+language: html
+---
+
+
+
+```html
+
+
+  
+  Auth0 Example
+
+
+  {% if session %}
+      
    Welcome {{session.userinfo.name}}!
    
+      
    Logout
    
+      
    {{pretty}}
    
+  {% else %}
+    
    Welcome Guest
    
+    
    Login
    
+  {% endif %}
+
+
+```
diff --git a/ja-jp/articles/quickstart/webapp/python/files/server.md b/ja-jp/articles/quickstart/webapp/python/files/server.md
new file mode 100644
index 0000000000..d0fd583839
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/files/server.md
@@ -0,0 +1,72 @@
+---
+name: server.py
+language: python
+---
+
+
+
+```python
+import json
+from os import environ as env
+from urllib.parse import quote_plus, urlencode
+
+from authlib.integrations.flask_client import OAuth
+from dotenv import find_dotenv, load_dotenv
+from flask import Flask, redirect, render_template, session, url_for
+
+
+ENV_FILE = find_dotenv()
+if ENV_FILE:
+    load_dotenv(ENV_FILE)
+    
+app = Flask(__name__)
+app.secret_key = env.get("APP_SECRET_KEY")
+
+oauth = OAuth(app)
+
+oauth.register(
+    "auth0",
+    client_id=env.get("AUTH0_CLIENT_ID"),
+    client_secret=env.get("AUTH0_CLIENT_SECRET"),
+    client_kwargs={
+        "scope": "openid profile email",
+    },
+    server_metadata_url=f'https://{env.get("AUTH0_DOMAIN")}/.well-known/openid-configuration'
+)
+
+
+@app.route("/login")
+def login():
+    return oauth.auth0.authorize_redirect(
+        redirect_uri=url_for("callback", _external=True)
+    )
+
+@app.route("/callback", methods=["GET", "POST"])
+def callback():
+    token = oauth.auth0.authorize_access_token()
+    session["user"] = token
+    return redirect("/")
+
+@app.route("/logout")
+def logout():
+    session.clear()
+    return redirect(
+        "https://" + env.get("AUTH0_DOMAIN")
+        + "/v2/logout?"
+        + urlencode(
+            {
+                "returnTo": url_for("home", _external=True),
+                "client_id": env.get("AUTH0_CLIENT_ID"),
+            },
+            quote_via=quote_plus,
+        )
+    )
+
+@app.route("/")
+def home():
+    return render_template("home.html", session=session.get('user'), pretty=json.dumps(session.get('user'), indent=4))
+
+
+if __name__ == "__main__":
+    app.run(host="0.0.0.0", port=env.get("PORT", 3000))
+```
diff --git a/ja-jp/articles/quickstart/webapp/python/index.yml b/ja-jp/articles/quickstart/webapp/python/index.yml
new file mode 100644
index 0000000000..b94c1a9d6d
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/index.yml
@@ -0,0 +1,50 @@
+title: Python
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/python.png
+logo: python
+author:
+  name: Evan Sims
+  email: evan.sims@auth0.com
+  community: false
+topics:
+  - quickstart
+contentType: tutorial
+useCase: quickstart
+snippets:
+  dependencies: server-platforms/python/dependencies
+  setup: server-platforms/python/setup
+  use: server-platforms/python/use
+seo_alias: python
+default_article: 01-login
+articles:
+  - 01-login
+hidden_articles:
+  - interactive
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-python-web-app
+  branch: master
+sdk:
+  name: auth0-python
+  url: https://github.com/auth0/auth0-python
+  logo: python
+requirements:
+  - Python 3
+  - Authlib 1.0
+  - Flask 2.0
+next_steps:
+  - path: 01-login
+    list:
+      - text: Configure other identity providers
+        icon: 345
+        href: '/identityproviders'
+      - text: Enable multifactor authentication
+        icon: 345
+        href: '/multifactor-authentication'
+      - text: Learn about attack protection
+        icon: 345
+        href: '/attack-protection'
+      - text: Learn about rules
+        icon: 345
+        href: '/rules'
diff --git a/ja-jp/articles/quickstart/webapp/python/interactive.md b/ja-jp/articles/quickstart/webapp/python/interactive.md
new file mode 100644
index 0000000000..50d2735b13
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/python/interactive.md
@@ -0,0 +1,114 @@
+---
+title: Add login to your Python Flask app
+description: This tutorial demonstrates how to add user login to a Python web application built with the Flask framework and Authlib OAuth library.
+interactive: true
+files:
+- files/server
+- files/home
+contentType: tutorial
+useCase: quickstart
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - python
+  - flask
+github:
+  path: 01-Login
+---
+
+
+
+# Add Login to Your Python Flask Application
+
+Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with a Python [Flask](https://flask.palletsprojects.com) application using the [Authlib](https://authlib.org/) SDK.
+
+<%= include('../../_includes/_configure_auth0_interactive', {
+callback: 'http://localhost:3000/callback',
+returnTo: 'http://localhost:3000'
+}) %>
+
+## Install dependencies
+
+Create a `requirements.txt` file in your project directory:
+
+```python
+# 📁 requirements.txt -----
+
+flask>=2.0.3
+python-dotenv>=0.19.2
+authlib>=1.0
+requests>=2.27.1
+```
+
+Run the following command from your shell to enable these dependencies in your project:
+
+```sh
+pip install -r requirements.txt
+```
+
+## Configure your `.env` file
+
+Next, create an `.env` file in your project directory. This file will hold your client keys and other configuration details.
+
+```ini
+# 📁 .env -----
+
+AUTH0_CLIENT_ID=${account.clientId}
+AUTH0_CLIENT_SECRET=${account.clientSecret}
+AUTH0_DOMAIN=${account.namespace}
+APP_SECRET_KEY=
+```
+
+- Generate a string for `APP_SECRET_KEY` using `openssl rand -hex 32` from your shell.
+
+## Setup your application {{{ data-action=code data-code="server.py#1:27" }}}
+
+Next, set up your application. Create a `server.py` file in your project directory - this file will contain your application logic.
+
+Import all the libraries your application needs.
+
+Load the configuration `.env` file you made in the previous step.
+
+Configure Authlib to handle your application's authentication with Auth0. To learn more about the configuration options available for Authlib's OAuth `register()` method from [their documentation.](https://docs.authlib.org/en/latest/client/frameworks.html#using-oauth-2-0-to-log-in)
+
+## Setup your routes {{{ data-action=code data-code="server.py#30:59" }}}
+
+In this example, you will add four routes to the application: login, callback, logout, and home.
+
+When visitors to your app visit the `/login` route, your application will route them to the Auth0 login page.
+
+After your users log in with Auth0, your application will route them to the `/callback` route. This route saves the session for the user and bypasses the need for them to login again when they return.
+
+The `/logout` route signs users out from your application. This route clears the user session in your app and redirects to the Auth0 logout endpoint to ensure the session is no longer saved. Then, the application redirects the user to your home route.
+
+Your `/ ` home route either renders an authenticated user's details or  allows visitors to sign in.
+
+## Add templates {{{ data-action=code data-code="templates/home.html" }}}
+
+Next, create the template file used in the home route (during `render_template()` calls).
+
+Create a new sub-directory in your project folder named `templates`, and create `home.html`  in the directory. Paste the content from the right into that file.
+
+## Run your application
+
+To run your application, navigate to the root of your project directory and open a terminal. Run the following command:
+
+```sh
+python3 server.py
+```
+
+::::checkpoint
+:::checkpoint-default
+Visit [http://localhost:3000](http://localhost:3000) to verify. You should find a login button routing to Auth0 for login, then back to your application to see your profile information.
+:::
+
+:::checkpoint-failure
+If your application did not start successfully:
+* Verify any errors in the console.
+* Verify the domain and Client ID imported correctly.
+* Verify your tenant configuration.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
diff --git a/ja-jp/articles/quickstart/webapp/rails/01-login.md b/ja-jp/articles/quickstart/webapp/rails/01-login.md
new file mode 100644
index 0000000000..ac61efa322
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/01-login.md
@@ -0,0 +1,197 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to a Ruby on Rails application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - rails
+contentType: tutorial
+useCase: quickstart
+---
+
+<%= include('../_includes/_getting_started', { library: 'Rails', callback: 'http://localhost:3000/auth/auth0/callback' }) %>
+
+<%= include('../../../_includes/_logout_url', { returnTo: 'http://localhost:3000' }) %>
+
+## Install the Auth0 SDK
+
+### Install Dependencies
+
+This tutorial uses `omniauth-auth0`, a custom [OmniAuth strategy](https://github.com/intridea/omniauth#omniauth-standardized-multi-provider-authentication), to handle the authentication flow.  Add the following dependencies to your `Gemfile`:
+
+```ruby
+gem 'omniauth-auth0', '~> 3.0'
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+```
+
+Once your gems are added, install the gems with `bundle install`:
+
+### Initialize Auth0 Configuration
+
+Create an Auth0 config file `./config/auth0.yml`
+
+```yaml
+# ./config/auth0.yml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: 
+```
+
+Create the following initializer file `./config/initializers/auth0.rb` and [configure](https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#send-additional-authentication-parameters) the **OmniAuth** middleware.
+
+```ruby
+# ./config/initializers/auth0.rb
+AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+Rails.application.config.middleware.use OmniAuth::Builder do
+  provider(
+    :auth0,
+    AUTH0_CONFIG['auth0_client_id'],
+    AUTH0_CONFIG['auth0_client_secret'],
+    AUTH0_CONFIG['auth0_domain'],
+    callback_path: '/auth/auth0/callback',
+    authorize_params: {
+      scope: 'openid profile'
+    }
+  )
+end
+```
+
+### Add an Auth0 controller
+Create an Auth0 controller for handling the authentication callback. Run the command `rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine`. 
+
+Inside of the callback method assign the hash of user information, returned as `request.env['omniauth.auth']`, to the active session.
+
+```ruby
+# ./app/controllers/auth0_controller.rb
+class Auth0Controller < ApplicationController
+  def callback
+    # OmniAuth stores the information returned from Auth0 and the IdP in request.env['omniauth.auth'].
+    # In this code, you will pull the raw_info supplied from the id_token and assign it to the session.
+    # Refer to https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#example-of-the-resulting-authentication-hash for complete information on 'omniauth.auth' contents.
+    auth_info = request.env['omniauth.auth']
+    session[:userinfo] = auth_info['extra']['raw_info']
+
+    # Redirect to the URL you want after successful auth
+    redirect_to '/dashboard'
+  end
+
+  def failure
+    # Handles failed authentication -- Show a failure page (you can also handle with a redirect)
+    @error_msg = request.params['message']
+  end
+
+  def logout
+    # you will finish this in a later step
+  end
+end
+```
+
+Add the following routes to your `./config/routes.rb` file:
+
+```ruby
+# ./config/routes.rb
+Rails.application.routes.draw do
+  # ..
+  get '/auth/auth0/callback' => 'auth0#callback'
+  get '/auth/failure' => 'auth0#failure'
+  get '/auth/logout' => 'auth0#logout'
+end
+```
+
+## Add Login to Your Application
+A user can now log into your application by visiting the `/auth/auth0` endpoint.
+
+::: warning
+To [prevent forged authentication requests](https://github.com/cookpad/omniauth-rails_csrf_protection), use the `link_to` or `button_to` helper methods with the `:post` method
+:::
+
+```erb
+  
+  ${"<%= button_to 'Login', '/auth/auth0', method: :post, data: \{ turbo: false \} %>"}
+```
+
+## Add Logout to Your Application
+Now that you can log in to your Rails application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Revisit the Auth0Controller you created earlier, and finish up the logout method added there.
+
+You will need to clear out your session and then redirect the user to the Auth0 logout endpoint.
+
+To clear out all the objects stored within the session, call the `reset_session` method within the `auth0_controller/logout` method. [Learn more about reset_session here](http://api.rubyonrails.org/classes/ActionController/Base.html#M000668).  Add the following code to `./app/controllers/auth0_controller.rb`:
+
+```ruby
+# ./app/controllers/auth0_controller.rb
+class Auth0Controller < ApplicationController
+  # ..
+  # ..Insert the code below
+  def logout
+    reset_session
+    redirect_to logout_url, allow_other_host: true
+  end
+
+  private
+
+  def logout_url
+    request_params = {
+      returnTo: root_url,
+      client_id: AUTH0_CONFIG['auth0_client_id']
+    }
+
+    URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: request_params.to_query).to_s
+  end
+end
+```
+
+::: note
+The final destination URL (the `returnTo` value) needs to be in the list of `Allowed Logout URLs` . See the [logout documentation](/logout/guides/redirect-users-after-logout) for more.
+:::
+
+The user will now be able to logout of your application by visiting the `/auth/logout` endpoint.
+
+```erb
+  
+  ${"<%= button_to 'Logout', 'auth/logout', method: :get, data: \{ turbo: false \} %>"}
+```
+
+## Show User Profile Information
+To display the user's profile, your application should provide a protected route. You can use a controller `concern` to control access to routes. Create the following file `./app/controllers/concerns/secured.rb`
+
+```ruby
+# ./app/controllers/concerns/secured.rb
+module Secured
+  extend ActiveSupport::Concern
+
+  included do
+    before_action :logged_in_using_omniauth?
+  end
+
+  def logged_in_using_omniauth?
+    redirect_to '/' unless session[:userinfo].present?
+  end
+end
+```
+
+After you have created the secured controller concern, include it in any controller that requires a logged in user. You can then access the user from the session `session[:userinfo]`.
+
+```ruby
+# ./app/controllers/dashboard_controller.rb
+class DashboardController < ApplicationController
+  include Secured
+
+  def show
+    # session[:userinfo] was saved earlier on Auth0Controller#callback
+    @user = session[:userinfo]
+  end
+end
+```
+
+Now that you have loaded the user from the session, you can use it to display information in your frontend.
+```erb
+
+
    
+  
    Normalized User Profile:${"<%= JSON.pretty_generate(@user[:info])%>"}
    
+  
    Full User Profile:${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}
    
+
    
+```
diff --git a/ja-jp/articles/quickstart/webapp/rails/02-troubleshooting.md b/ja-jp/articles/quickstart/webapp/rails/02-troubleshooting.md
new file mode 100644
index 0000000000..7300a3beae
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/02-troubleshooting.md
@@ -0,0 +1,118 @@
+---
+title: Troubleshooting
+description: Troubleshooting tips for using Rails with Auth0.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - login
+  - rails
+contentType: tutorial
+useCase: quickstart
+---
+
+# Troubleshooting
+
+The following are troubleshooting topics that you might run into when using the Rails quickstart.
+
+## Using a reverse proxy
+
+The `redirect_uri` parameter that OmniAuth generates when redirecting to login is based on the `Host` header that is passed to Rails. This can cause incorrect callback URLs to be passed when using this strategy (and OmniAuth in general) with a reverse proxy. You can adjust the host used by OmniAuth with the following snippet:
+
+```ruby
+OmniAuth.config.full_host = lambda do |env|
+    scheme         = env['rack.url_scheme']
+    local_host     = env['HTTP_HOST']
+    forwarded_host = env['HTTP_X_FORWARDED_HOST']
+    forwarded_host.blank? ? "#{scheme}://#{local_host}" : "#{scheme}://#{forwarded_host}"
+end
+```
+
+[See this StackOverflow thread for more information](https://stackoverflow.com/a/7135029/728480). 
+
+## ActionController::InvalidAuthenticityToken
+
+This is likely caused by a missing CSRF token needed to POST the login request. If you inspect the login button in your browser, you should see something like this:
+
+```html
+Login
+```
+
+... and in the `` element for the page, you should have CSRF meta tags like these:
+
+```html
+
+
+```
+
+With those elements in place, Rails will convert the login link to POST the CSRF token to the backend to verify it before redirecting to login.
+
+## ActionDispatch::Cookies::CookieOverflow
+
+This error means that a cookie session is being used and because the whole profile is being stored, it overflows the max-size of 4 kb. If you are unable to access the user profile, or you get an error similar to `NoMethodError`, `undefined method '[]' for nil:NilClass`, try using In-Memory store for development.
+
+Go to `/config/initializers/session_store.rb` (or create it if it does not exist) and add the following:
+
+```ruby
+Rails.application.config.session_store :cache_store
+```
+
+Go to `/config/environments/development.rb` and add the following:
+
+```ruby
+config.cache_store = :memory_store
+```
+
+Restart your Rails server for these changes to take effect.
+
+:::note
+It is recommended that a memory store, such as MemCached, is being used for production applications.
+:::
+
+## SSL Issues
+
+Under some configurations, Ruby may not be able to find certification authority certificates (CA certs).
+
+Download the CA certs bundle to the project directory:
+
+```bash
+curl -L -o lib/ca-bundle.crt http://curl.haxx.se/ca/ca-bundle.crt
+```
+
+Add this initializer to `config/initializers/fix_ssl.rb`:
+
+```ruby
+# config/initializers/fix_ssl.rb
+
+require 'open-uri'
+require 'net/https'
+
+module Net
+  class HTTP
+    alias_method :original_use_ssl=, :use_ssl=
+
+    def use_ssl=(flag)
+      path = ( Rails.env == "development") ? "lib/ca-bundle.crt" : "/usr/lib/ssl/certs/ca-certificates.crt"
+      self.ca_file = Rails.root.join(path).to_s
+      self.verify_mode = OpenSSL::SSL::VERIFY_PEER
+      self.original_use_ssl = flag
+    end
+  end
+end
+```
+
+## "failure message=invalid_credentials"
+
+This issue doesn't occur when working locally but may happen in a staging or production environment. The error message may be displayed as:
+
+```
+omniauth: (auth0) Authentication failure! invalid_credentials: OAuth2::Error, server_error: The redirect URI is wrong. You send [wrong url], and we expected [callback url set in your app settings]
+```
+
+To solve this, add the following to `config/environments/staging.rb` or `production.rb`:
+
+```ruby
+OmniAuth.config.full_host = "http://www.example.com"
+```
+
+Substitute `http://www.example.com` with the actual URL you'll be using in your application.
diff --git a/ja-jp/articles/quickstart/webapp/rails/download.md b/ja-jp/articles/quickstart/webapp/rails/download.md
new file mode 100644
index 0000000000..df98776181
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/download.md
@@ -0,0 +1,29 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+```text
+http://localhost:3000/auth/auth0/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+
+ ```text
+http://localhost:3000
+```
+
+3) Make sure [Rails](http://installrails.com/) is installed and execute the following commands in the sample's directory:
+
+```bash
+bundle install
+rails s --port 3000
+```
+
+You can also run it from a [Docker](https://www.docker.com) image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/concern.md b/ja-jp/articles/quickstart/webapp/rails/files/concern.md
new file mode 100644
index 0000000000..a3782a7023
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/concern.md
@@ -0,0 +1,18 @@
+---
+name: secured.rb
+language: ruby
+---
+
+```ruby
+module Secured
+  extend ActiveSupport::Concern
+
+  included do
+    before_action :logged_in_using_omniauth?
+  end
+
+  def logged_in_using_omniauth?
+    redirect_to '/' unless session[:userinfo].present?
+  end
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/config.md b/ja-jp/articles/quickstart/webapp/rails/files/config.md
new file mode 100644
index 0000000000..b838b819bf
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/config.md
@@ -0,0 +1,11 @@
+---
+name: config/auth0.yml
+language: yml
+---
+
+```yaml
+development:
+  auth0_domain: ${account.namespace}
+  auth0_client_id: ${account.clientId}
+  auth0_client_secret: 
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/controller.md b/ja-jp/articles/quickstart/webapp/rails/files/controller.md
new file mode 100644
index 0000000000..610d4a7ab0
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/controller.md
@@ -0,0 +1,48 @@
+---
+name: auth0_controller.rb
+language: ruby
+---
+
+```ruby
+class Auth0Controller < ApplicationController
+  def callback
+    # OmniAuth stores the informatin returned from
+    # Auth0 and the IdP in request.env['omniauth.auth'].
+    # In this code, you will pull the raw_info supplied 
+    # from the id_token and assign it to the session.
+    # Refer to https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#example-of-the-resulting-authentication-hash 
+    # for complete information on 'omniauth.auth' contents.
+    auth_info = request.env['omniauth.auth']
+    session[:userinfo] = auth_info['extra']['raw_info']
+
+    # Redirect to the URL you want after successful auth
+    redirect_to '/dashboard'
+  end
+
+  def failure
+    # Handles failed authentication
+    @error_msg = request.params['message']
+  end
+
+  def logout
+    reset_session
+    redirect_to logout_url
+  end
+
+  private
+  AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+  def logout_url
+    request_params = {
+      returnTo: root_url,
+      client_id: AUTH0_CONFIG['auth0_client_id']
+    }
+
+    URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: to_query(request_params)).to_s
+  end
+
+  def to_query(hash)
+    hash.map { |k, v| "#{k}=#{CGI.escape(v)}" unless v.nil? }.reject(&:nil?).join('&')
+  end
+end
+```
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/initializer.md b/ja-jp/articles/quickstart/webapp/rails/files/initializer.md
new file mode 100644
index 0000000000..a1695fdefc
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/initializer.md
@@ -0,0 +1,21 @@
+---
+name: auth0.rb
+language: ruby
+---
+
+```ruby
+AUTH0_CONFIG = Rails.application.config_for(:auth0)
+
+Rails.application.config.middleware.use OmniAuth::Builder do
+  provider(
+    :auth0,
+    AUTH0_CONFIG['auth0_client_id'],
+    AUTH0_CONFIG['auth0_client_secret'],
+    AUTH0_CONFIG['auth0_domain'],
+    callback_path: '/auth/auth0/callback',
+    authorize_params: {
+      scope: 'openid profile'
+    }
+  )
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/rails/files/routes.md b/ja-jp/articles/quickstart/webapp/rails/files/routes.md
new file mode 100644
index 0000000000..209615d89a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/files/routes.md
@@ -0,0 +1,13 @@
+---
+name: routes.rb
+language: ruby
+---
+
+```ruby
+Rails.application.routes.draw do
+  # ..
+  get '/auth/auth0/callback' => 'auth0#callback'
+  get '/auth/failure' => 'auth0#failure'
+  get '/auth/logout' => 'auth0#logout'
+end
+```
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/rails/index.yml b/ja-jp/articles/quickstart/webapp/rails/index.yml
new file mode 100644
index 0000000000..35e85c2158
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/index.yml
@@ -0,0 +1,53 @@
+title: Ruby On Rails
+# TODO remove 'image' once new QS page is live. Then only use 'logo'.
+image: /media/platforms/rails.png
+logo: rails
+author:
+  name: David Patrick
+  email: david.patrick@auth0.com
+  community: false
+topics:
+  - quickstart
+  - ruby
+  - rails
+  - ruby on rails
+contentType: tutorial
+useCase: quickstart
+alias:
+  - ruby-rails
+  - sinatra
+  - omniauth
+seo_alias: rails
+default_article: 01-login
+hidden_articles:
+  - interactive
+articles:
+  - 01-login
+  - 02-troubleshooting
+show_steps: true
+github:
+  org: auth0-samples
+  repo: auth0-rubyonrails-sample
+  branch: master
+  path: sample
+sdk:
+  name: omniauth-auth0
+  url: https://github.com/auth0/omniauth-auth0
+  logo: rails
+requirements:
+  - Ruby 2.5.0+ | Rails 6.0+ or Rails 5.0+ or Rails 4.2+
+next_steps:
+  - path: 01-login
+    list:
+    - text: Configure other identity providers
+      icon: 345
+      href: "/identityproviders"
+    - text: Enable multifactor authentication
+      icon: 345
+      href: "/multifactor-authentication"
+    - text: Learn about attack protection
+      icon: 345
+      href: "/attack-protection"
+    - text: Learn about rules
+      icon: 345
+      href: "/rules"
diff --git a/ja-jp/articles/quickstart/webapp/rails/interactive.md b/ja-jp/articles/quickstart/webapp/rails/interactive.md
new file mode 100644
index 0000000000..4a3af555e2
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,161 @@
+---
+title: Add Login to Your Ruby on Rails Application
+description: This tutorial demonstrates how to add user login to a Ruby on Rails application using OmniAuth.
+interactive: true
+files:
+  - files/config
+  - files/initializer
+  - files/controller
+  - files/routes
+  - files/concern
+---
+
+# Add Login to Your Ruby on Rails Application
+
+<%= include('../../_includes/_configure_auth0_interactive', { 
+  callback: 'http://localhost:3000/auth/auth0/callback',
+  returnTo: 'http://localhost:3000',
+  webOriginUrl: 'http://localhost:3000',
+  showWebOriginInfo: true
+}) %>
+
+## Add dependencies
+
+Use `omniauth-auth0`, a custom [OmniAuth strategy](https://github.com/intridea/omniauth#omniauth-standardized-multi-provider-authentication), to handle the authentication flow.
+
+Add the following dependencies to your `Gemfile`:
+
+```ruby
+gem 'omniauth-auth0', '~> 3.0'
+gem 'omniauth-rails_csrf_protection', '~> 1.0' # prevents forged authentication requests
+```
+
+Once your gems are added, install the gems with `bundle install`.
+
+## Configure the SDK {{{ data-action=code data-code="auth0.yml" }}}
+
+Create a configuration file `./config/auth0.yml` to specify your Auth0 domain, client ID, and client secret values located in your Auth0 Dashboard under application **Settings**.
+
+## Configure OmniAuth middleware {{{ data-action=code data-code="auth0.rb" }}}
+
+Create the following initializer file `./config/initializers/auth0.rb` and [configure](https://github.com/auth0/omniauth-auth0/blob/master/EXAMPLES.md#send-additional-authentication-parameters) the **OmniAuth** middleware with the configuration file you created in the previous step.
+
+Ensure that `callback_path` matches the value given in the "Allowed Callback URLs" setting in your Auth0 application.
+
+## Add an Auth0 controller {{{ data-action=code data-code="auth0_controller.rb" }}}
+
+Create an Auth0 controller to handle the authentication callback, `logout` action, and methods for constructing the logout URL.
+
+Run the command: `rails generate controller auth0 callback failure logout --skip-assets --skip-helper --skip-routes --skip-template-engine`. 
+
+Inside the callback method, assign the hash of user information - returned as `request.env['omniauth.auth']` - to the active session.
+
+To configure logout, clear all the objects stored within the session by calling the `reset_session` method within the `logout` action. Then, redirect to the Auth0 logout endpoint. To learn more about `reset_session`, read[Ruby on Rails ActionController documentation](http://api.rubyonrails.org/classes/ActionController/Base.html#M000668).
+
+## Configure routes {{{ data-action=code data-code="routes.rb" }}}
+
+Add these routes to your `./config/routes.rb` file.
+
+Routes must be in place so Rails knows how to route the various Auth0 callback URLs to the Auth0 controller you created in the previous step.
+
+::::checkpoint
+::: checkpoint-default
+Run your application to verify it continues to work as intended and you aren't receive any errors relating to Auth0.
+:::
+
+::: checkpoint-failure
+Sorry about that. Please double-check that the previous steps completed without error.
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add login to your application
+
+A user can now log into your application by visiting the `/auth/auth0` endpoint.
+
+::: warning
+To [prevent forged authentication requests](https://github.com/cookpad/omniauth-rails_csrf_protection), use the `link_to` or `button_to` helper methods with the `:post` method
+:::
+
+```erb
+
+${"<%= button_to 'Login', '/auth/auth0', method: :post %>"}
+```
+
+::::checkpoint
+::: checkpoint-default
+Add a button to your application that redirects the user to the `/auth/auth0` endpoint when selected. Observe that you redirect to Auth0 to log in, and then back to your app after successful authentication.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a couple of things you can check:
+
+- Ensure that the correct URLs have been set in your Auth0 application as per the first step in this quickstart
+- Check that all the required gems installed correctly
+- Check that the routes have been set up and the Auth0 configuration has been set up in your app
+- [Check the logs](https://manage.auth0.com/#/logs) for any other errors or messages that may have prevented login from working
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Add logout to your application
+
+Now that you can log in to your Rails application, you need [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Log out a user by redirecting to the `auth/logout` action, which redirects them to the Auth0 logout endpoint.
+
+:::note
+To test this after the previous step, you may need to clear out your session and then redirect the user to the Auth0 logout endpoint.
+:::
+
+```erb
+
+${"<%= button_to 'Logout', 'auth/logout', method: :get %>"}
+```
+
+::::checkpoint
+::: checkpoint-default
+Add a button to your application that redirects the user to the `/auth/logout` endpoint when selected. Verify that you redirect to Auth0 and then quickly back to your application, and that you are no longer logged in.
+:::
+
+::: checkpoint-failure
+Sorry about that. Here are a couple of things you can check:
+
+- Ensure that the correct URLs have been set in your Auth0 client as per the first step in this quickstart
+- Check that the routes have been set up and the Auth0 configuration has been set up in your app
+- [Check the logs](https://manage.auth0.com/#/logs) for any other errors or messages that may have prevented login from working
+
+Still having issues? Check out our [documentation](https://auth0.com/docs) or visit our [community page](https://community.auth0.com) to get more help.
+:::
+::::
+
+## Show user profile information {{{ data-action=code data-code="secured.rb" }}}
+
+To display the user's profile, your application should provide a protected route. You can use a [Concern](https://guides.rubyonrails.org/getting_started.html#using-concerns) to control access to routes that can be shared across multiple controllers. The concern should automatically redirect to Auth0 when the user is unauthenticated. Otherwise, the concern should return the current user profile.
+
+Once you have a Concern, include it in any controller that requires a logged in user. You can then access the user from the session `session[:userinfo]` as in the following example:
+
+```ruby
+class DashboardController < ApplicationController
+  include Secured
+
+  def show
+    @user = session[:userinfo]
+  end
+end
+```
+
+Once the user loads from the session, use it to display information in your frontend:
+
+```erb
+
    
+  
    Normalized User Profile:${"<%= JSON.pretty_generate(@user[:info])%>"}
    
+  
    Full User Profile:${"<%= JSON.pretty_generate(@user[:extra][:raw_info])%>"}
    
+
    
+```
+
+::::checkpoint
+::: checkpoint-default
+Add the `Secured` concern to your app and then include it in the controller that requires an authenticated user to access it. Verify that an authenticated user has access to actions within that controller and that unauthenticated users are redirected to Auth0 for authentication.
+:::
+::::
diff --git a/ja-jp/articles/rules/_includes/_context-prop-authentication.md b/ja-jp/articles/rules/_includes/_context-prop-authentication.md
new file mode 100644
index 0000000000..3019eaff7f
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_context-prop-authentication.md
@@ -0,0 +1,28 @@
+An object containing information related to the authentication transaction with the following properties:
+
+- `methods`: an array of objects containing the authentication methods a user has completed during their session. For example, a user that has completed a password-based authentication followed by MFA may have the following methods:
+
+```json
+[
+  {
+    "name": "pwd",
+    "timestamp": 1434454643024
+  },
+  {
+    "name": "mfa",
+    "timestamp": 1534454643881
+  }
+]
+```
+
+The method objects will contain the following properties:
+
+- `name`: a string representing the name of the authentication method that has been completed. It can be one of the following values (additional values may be supported in the future):
+  - `federated`: a social or enterprise connection was used to authenticate the user
+  - `pwd`: a database connection was used to authenticate the user
+  - `sms`: a Passwordless SMS connection was used to authenticate the user
+  - `email`: a Passwordless Email connection was used to authenticate the user
+  - `mfa`: the user completed a multi-factor authentication
+- `timestamp`: an integer indicating the time in seconds at which the authentication method took place in Unix Epoch time
+
+You can see a sample use case of the `context.authentication.methods` property in the [Require MFA once per session Rule](https://github.com/auth0/rules/blob/master/src/rules/require-mfa-once-per-session.js).
diff --git a/ja-jp/articles/rules/_includes/_context-prop-authorization.md b/ja-jp/articles/rules/_includes/_context-prop-authorization.md
new file mode 100644
index 0000000000..5625777e2f
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_context-prop-authorization.md
@@ -0,0 +1,3 @@
+An object containing information related to the authorization transaction with the following properties:
+
+- `roles`: an array of strings containing the names of a user's assigned roles. You can see a sample use case using the `context.authorization.roles` property to add roles to tokens in [Sample Use Cases: Rules with Authorization](/authorization/concepts/sample-use-cases-rules#add-user-roles-to-tokens).
\ No newline at end of file
diff --git a/ja-jp/articles/rules/_includes/_context-prop-protocol.md b/ja-jp/articles/rules/_includes/_context-prop-protocol.md
new file mode 100644
index 0000000000..7a76ff8125
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_context-prop-protocol.md
@@ -0,0 +1,13 @@
+The authentication protocol. Possible values:
+- `oidc-basic-profile`: most used, web based login
+- `oidc-implicit-profile`: used on mobile devices and single-page apps
+- `oauth2-device-code`: transaction using the [Device Authorization Flow](/flows/concepts/device-auth)
+- `oauth2-resource-owner`: user/password login typically used on database connections
+- `oauth2-resource-owner-jwt-bearer`: login using a bearer JWT signed with user's private key
+- `oauth2-password`: login using the password exchange
+- `oauth2-refresh-token`: refreshing a token using the Refresh Token exchange
+- `samlp`: SAML protocol used on SaaS apps
+- `wsfed`: WS-Federation used on Microsoft products like Office365
+- `wstrust-usernamemixed`: WS-trust user/password login used on CRM and Office365
+- `delegation`: when calling the [Delegation endpoint](/api/authentication#delegation)
+- `redirect-callback`: when a redirect rule is resumed
diff --git a/ja-jp/articles/rules/_includes/_context-prop-request.md b/ja-jp/articles/rules/_includes/_context-prop-request.md
new file mode 100644
index 0000000000..7ebe99591c
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_context-prop-request.md
@@ -0,0 +1,15 @@
+An object containing useful information of the request. It has the following properties:
+- `userAgent`: the user-agent of the application that is trying to log in.
+- `ip`: the originating IP address of the user trying to log in.
+- `hostname`: the hostname that is being used for the authentication flow.
+- `query`: an object containing the querystring properties of the login transaction sent by the application. 
+- `body`: the body of the POST request on login transactions used on `oauth2-resource-owner`, `oauth2-resource-owner-jwt-bearer` or `wstrust-usernamemixed` protocols.
+- `geoip`: an object containing geographic IP information. It has the following properties:
+  - `country_code`: a two-character code for the country associated with the IP address
+  - `country_code3`: a three-character code for the country associated with the IP address
+  - `country_name`: the country name associated with the IP address
+  - `city_name`: the city or town name associated with the IP address
+  - `latitude`: the latitude associated with the IP address.
+  - `longitude`: the longitude associated with the IP address.
+  - `time_zone`: the timezone associated with the IP address.
+  - `continent_code`: a two-character code for the continent associated with the IP address.
diff --git a/ja-jp/articles/rules/_includes/_context-prop-sso.md b/ja-jp/articles/rules/_includes/_context-prop-sso.md
new file mode 100644
index 0000000000..834c9ce793
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_context-prop-sso.md
@@ -0,0 +1,4 @@
+This object will contain information about the Single Sign-on (SSO) transaction (if available)
+- `with_auth0`: when a user signs in with SSO to an application where the `Use Auth0 instead of the IdP to do Single Sign-On` setting is enabled (only for legacy tenants).
+- `with_dbconn`: an SSO login for a user that logged in through a database connection.
+- `current_clients`: client IDs using SSO.
diff --git a/ja-jp/articles/rules/_includes/_supported-modules.md b/ja-jp/articles/rules/_includes/_supported-modules.md
new file mode 100644
index 0000000000..0ae32fe785
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_supported-modules.md
@@ -0,0 +1 @@
+Rules run in a JavaScript sandbox. The sandbox supports the ECMAScript 6 language and a large number of Node.js (version 8+) modules. For a list of supported sandbox modules, check out [Can I require: Auth0 Extensibility](https://auth0-extensions.github.io/canirequire/).
\ No newline at end of file
diff --git a/ja-jp/articles/rules/_includes/_user-prop-identities.md b/ja-jp/articles/rules/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..4647b53706
--- /dev/null
+++ b/ja-jp/articles/rules/_includes/_user-prop-identities.md
@@ -0,0 +1,9 @@
+Contains info retrieved from the identity provider with which the user originally authenticates. Users may also [link their profile to multiple identity providers](/users/concepts/overview-user-account-linking); those identities will then also appear in this array. The contents of an individual identity provider object varies by provider, but it will typically include the following:
+
+- `connection` (text): Name of the Auth0 connection used to authenticate the user.
+- `isSocial` (boolean): Indicates whether the connection is a social one.
+- `provider` (text): Name of the entity that is authenticating the user, such as Facebook, Google, SAML, or your own provider.
+- `user_id` (text): User's unique identifier for this connection/provider.
+- `profileData` (object): User information associated with the connection. When profiles are linked, it is populated with the associated user info for secondary accounts.
+
+In some cases, it will also include an API Access Token to be used with the provider. 
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/automatically-generate-leads-shopify.md b/ja-jp/articles/rules/guides/automatically-generate-leads-shopify.md
new file mode 100644
index 0000000000..f01f3cdeb8
--- /dev/null
+++ b/ja-jp/articles/rules/guides/automatically-generate-leads-shopify.md
@@ -0,0 +1,54 @@
+---
+title: Automatically Generate Leads in Shopify
+description: Learn how to automatically generate leads in Shopify using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Automatically Generate Leads in Shopify
+
+To increase e-commerce sales, you may want to integrate with Shopify. With Auth0, you can not only [configure Shopify as a social identity provider](/connections/social/shopify) out-of-the-box, you can also automatically generate leads in Shopify using a specialized rule template.
+
+In this example, we will use a rule to automatically generate a lead with Shopify when a user authenticates.
+
+## Prerequisites
+
+Before connecting your Auth0 app to Shopify, you must [sign up for and configure your account with Shopify](https://www.shopify.com/).
+
+## Steps
+
+To connect your app to Shopify, you will:
+
+1. [Set up your app in Shopify](#set-up-your-app-in-shopify)
+2. [Get your Shopify credentials](#get-your-shopify-credentials)
+3. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Set up your app in Shopify
+
+Create an app in Shopify and generate credentials for it, using Shopify's [Authenticate a Private App with Shopify Admin](https://shopify.dev/tutorials/authenticate-a-private-app-with-shopify-admin). During this process, Shopify will generate an **API Key** and **API Password** for your application; make note of these.
+
+### Get your Shopify credentials
+
+You will also need to get your Shopify API URL. To learn about the structure of your Shopify API URL, see Shopify's [Make Your First Shopify API Request](https://shopify.dev/tutorials/make-your-first-shopify-api-request#making-your-first-request).
+
+Once you have retrieved your Shopify API URL, keep this value on hand because we will use it in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **shopify-leads-from-login** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| SHOPIFY_API_KEY | API Key for the application you previously set up in Shopify. |
+| SHOPIFY_API_PWD | API Password for the application you previously set up in Shopify. |
+| SHOPIFY_API_URL | Your Shopify API URL. |
+
+By default, your rule will be activated upon save.
diff --git a/ja-jp/articles/rules/guides/cache-resources.md b/ja-jp/articles/rules/guides/cache-resources.md
new file mode 100644
index 0000000000..38f2e6fb5e
--- /dev/null
+++ b/ja-jp/articles/rules/guides/cache-resources.md
@@ -0,0 +1,35 @@
+---
+description: How to cache expensive resources in your Rules code.
+topics:
+  - rules
+  - extensibility
+  - cache
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Cache Expensive Resources in Rules
+
+In Rules you can store expensive resources using the `global` object. The `global` object survives individual execution, so you can reuse things stored there instead of creating them every time a Rule is run. However, the Rules environment can be recycled at any time so your code __must__ always check that `global` contains what you expect.
+
+This example shows how to use the `global` object to keep a [MongoDB](https://www.mongodb.com/) connection:
+
+```js
+//If the db object is there, use it.
+if (global.db){
+  return query(global.db, callback);
+}
+
+//If not, get the db (mongodb in this case)
+mongo('mongodb://user:pass@mymongoserver.com/my-db',  function (db){
+  global.db = db;
+  return query(db, callback);
+});
+
+//Do the actual work
+function query(db, cb){
+  // Do something with db
+  ...
+  return cb(null, user, context);
+}
+```
diff --git a/ja-jp/articles/rules/guides/configuration.md b/ja-jp/articles/rules/guides/configuration.md
new file mode 100644
index 0000000000..bad1fd86d4
--- /dev/null
+++ b/ja-jp/articles/rules/guides/configuration.md
@@ -0,0 +1,60 @@
+---
+title: Store Configuration for Rules
+description: A list of the Node.js modules and libraries that are available when creating Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Store Configuration for Rules
+
+The global `configuration` object is available in Rules for storing commonly used values, such as URLs. Sensitive information, such as credentials or API keys, should be stored through the `configuration` object and kept out of your Rules code.
+
+## Configure values
+
+You can set configuration values in your [Rules Settings](${manage_url}/#/rules/) on the Dashboard.
+
+To edit or change a configuration key's value, remove the existing configuration setting and replace it with the updated value.
+
+![Rules Configuration](/media/articles/rules/rules-configuration.png)
+
+::: note
+You need to have created at least one Rule to see the configuration area, otherwise, the Rules demo shows instead.
+:::
+
+## Use the `configuration` object
+
+Any configuration values you set can be accessed through the `configuration` object by key in your Rules code.
+
+```js
+var MY_API_KEY = configuration.MY_API_KEY;
+```
+
+The following example is a Rule for sending a Slack message when a new user has signed up. The [Slack Webhook](https://api.slack.com/incoming-webhooks) is a `configuration` value set with the key `SLACK_HOOK_URL`.
+
+```js
+function (user, context, callback) {
+  // short-circuit if the user signed up already or is using a Refresh Token
+  if (context.stats.loginsCount > 1 || context.protocol === 'oauth2-refresh-token') {
+    return callback(null, user, context);
+  }
+
+  // get your slack's hook url from: https://slack.com/services/10525858050
+  const SLACK_HOOK = configuration.SLACK_HOOK_URL;
+
+  const slack = require('slack-notify')(SLACK_HOOK);
+  const message = 'New User: ' + (user.name || user.email) + ' (' + user.email + ')';
+  const channel = '#some_channel';
+
+  slack.success({
+    text: message,
+    channel: channel
+  });
+
+  // don’t wait for the Slack API call to finish, return right away (the request will continue on the sandbox)`
+  callback(null, user, context);
+}
+```
diff --git a/ja-jp/articles/rules/guides/debug.md b/ja-jp/articles/rules/guides/debug.md
new file mode 100644
index 0000000000..b269e370a5
--- /dev/null
+++ b/ja-jp/articles/rules/guides/debug.md
@@ -0,0 +1,47 @@
+---
+title: Debug Rules
+description: Learn how to debug your Auth0 rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - debug
+contentType: how-to
+useCase: extensibility-rules
+---
+# Debug Rules
+
+To debug any [Rule](/rules) you have created in Auth0, you can use `console.log` from within your rule code. You can see `console.log` output by using the [**Try this Rule** feature](#try-this-rule), viewing the logs available with the [Real-time Webtask Logs extension](#real-time-logs-extension), or for legacy clients, using the [Debug Rule CLI](#debug-rule-cli).
+
+## Try this Rule
+
+In the [Rules Editor](${manage_url}/#/rules/create), the **TRY THIS RULE** button lets you run a Rule in isolation with mock **user** and **context** objects. Clicking **TRY** will run the Rule with those two objects as input and will display any `console.log` output.
+
+![Try this Rule](/media/articles/rules/try-rule.png)
+
+::: note
+The **TRY THIS RULE** feature functions outside a specific client context. When using this feature, you may run into issues if your Rule depends on data that would be provided when called from an actual application.
+:::
+
+## Real-time logs extension
+
+The [Real-time Webtask Logs](/extensions/realtime-webtask-logs) extension displays all logs in real-time for all custom code in your account, which includes all `console.log` output and exceptions.
+
+## Debug Rule CLI
+
+<%= include('../../_includes/_webtask') %>
+
+In the [Rules Editor](${manage_url}/#/rules/create)], the **DEBUG RULE** button displays instructions for installing, configuring, and running the [webtask CLI](https://github.com/auth0/wt-cli) for debugging Rules. Paste these commands into a terminal to see the `console.log` output and any unhandled exceptions that occur during Rule execution.
+
+For example:
+
+```sh
+  ~  npm install -g wt-cli
+  ~  wt init --container "youraccount" --url "https://sandbox.it.auth0.com" --token "eyJhbGci...WMPGI" -p "youraccount-default-logs"
+  ~  wt logs -p "youraccount-default-logs"
+  [18:45:38.179Z]  INFO wt: connected to streaming logs (container=youraccount)
+  [18:47:37.954Z]  INFO wt: webtask container assigned
+  [18:47:38.167Z]  INFO wt: ---- checking email_verified for some-user@mail.com! ----
+```
+
+This debugging method works for Rules tried from the Dashboard and for those actually running during user authentication.
diff --git a/ja-jp/articles/rules/guides/integrate-efm-solutions.md b/ja-jp/articles/rules/guides/integrate-efm-solutions.md
new file mode 100644
index 0000000000..4c6d8539fd
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-efm-solutions.md
@@ -0,0 +1,48 @@
+---
+title: Integrate with Enterprise Fraud Management Solutions
+description: Learn how to integrate Enterprise Fraud Management solutions using rules. The given example uses Socure, but can be modified to use any EFM service. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with Enterprise Fraud Management Solutions
+
+To create trust with consumers, you may want to integrate with an Enterprise Fraud Management (EFM) service, such as Socure, Maxmind, or SAS. Although this example shows how to configure an integration with Socure, you may modify it to use any EFM service.
+
+In this example, we will use a rule to make a call to Socure to request that they return a user fraud score for the user who is authenticating, based on their email address and IP address. If a user has a high fraud score, you may choose to put them on a watch list or require them to provide additional information before they can make any transactions. 
+
+## Prerequisites
+
+Before connecting your Auth0 app to an EFM service, you must have configured an account with the chosen service. For this example, you will need to [sign up for and configure your account with Socure](https://developer.socure.com/guide/start).
+
+## Steps
+
+To connect your app to your EFM service, you will:
+
+1. [Get your EFM service's credentials](#get-your-efm-services-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your EFM service's credentials
+
+First, you will need to retrieve the URL of your EFM's API and your API Key. To learn how to do this for Socure, see [Socure's Developer docs](https://developer.socure.com/guide/overview). To access all content, you will need to log in to your Socure account.
+
+Once you have retrieved the EFM API's URL and your API Key, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Detect Fraud Users** template from the **Enrich Profile** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | URL of the EFM's API |
+| socurekey | Key for the EFM's API. You may use global variables to configure this in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first. |
+
+::: note
+Although in this example we configure a rule to integrate with Socure, you may modify this rule to use any EFM service.
+:::
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/integrate-erfm-solutions.md b/ja-jp/articles/rules/guides/integrate-erfm-solutions.md
new file mode 100644
index 0000000000..29597e769b
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-erfm-solutions.md
@@ -0,0 +1,53 @@
+---
+title: Integrate with eCommerce and Retail Fraud Management Solutions
+description: Learn how to integrate eCommerce and Retail Fraud Management solutions using rules. The given example uses Signifyd, but can be modified to use any ERFM service. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with eCommerce and Retail Fraud Management Solutions
+
+
+To more effectively contain fraud and counter fast-changing fraud patterns, you may want to integrate with an eCommerce and Retail Fraud Management (ERFM) service, such as Signifyd, Cybersource, or Forter. Although this example shows how to configure an integration with Signifyd, you may modify it to use any ERFM service.
+
+In this example, we will use a rule to make a call to Signifyd to detect whether or not the user who is authenticating is fraudulent, based on their transaction history.
+
+## Prerequisites
+
+Before connecting your Auth0 app to an ERFM service, you must have configured an account with the chosen service. For this example, you will need to [sign up for and configure your account with Signifyd](https://www.signifyd.com/).
+
+## Steps
+
+To connect your app to your ERFM service, you will:
+
+1. [Get your ERFM service's credentials](#get-your-erfm-services-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your ERFM service's credentials
+
+First, you will need to retrieve the URL of your ERFM's API and your API Key. To learn how to do this for Signifyd, see Signifyd's [API Reference: Get Case](https://developer.signifyd.com/api/#/reference/cases/get-case) and [Create a Team](https://www.signifyd.com/resources/faq/working-with-teams/how-do-i-create-a-team/) docs.
+
+Once you have retrieved the ERFM API's URL and your API Key, keep these values on hand because we will use them in the next step.
+
+::: note
+This rule template also passes the API a `caseId` that you should have already saved in the authenticating user's `app_metadata` profile field. To learn how to modify metadata in the Auth0 user profile, see [Metadata](/users/concepts/overview-user-metadata).
+:::
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Detect eCommerce Fraud Users** template from the **Enrich Profile** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | URL of the ERFM's API |
+| headers | Replace the example API Key with the API Key you retrieved in Step 1. |
+
+::: note
+Although in this example we configure a rule to integrate with Signifyd, you may modify this rule to use any ERFM service.
+:::
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/integrate-hubspot.md b/ja-jp/articles/rules/guides/integrate-hubspot.md
new file mode 100644
index 0000000000..f80a3ea207
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-hubspot.md
@@ -0,0 +1,53 @@
+---
+title: Integrate with HubSpot Marketing Software
+description: Learn how to integrate HubSpot Marketing Software using rules. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with HubSpot Marketing Software
+
+To help increase traffic and leads, you may want to integrate with HubSpot Marketing Software. You can do this using a specialized rule template.
+
+In this example, we will use a rule to add a new contact to a specified list in HubSpot.
+
+## Prerequisites
+
+Before connecting your Auth0 app to HubSpot, you must [sign up for and configure your account with HubSpot](https://www.hubspot.com/).
+
+## Steps
+
+To connect your app to HubSpot, you will:
+
+1. [Get your HubSpot credentials](#get-your-hubspot-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your HubSpot credentials
+
+First, you will need to retrieve your HubSpot API Key and the list ID of the HubSpot list to which you want to add a new member.
+
+To learn how to get your HubSpot API Key, see [HubSpot's Access your HubSpot API Key doc](https://knowledge.HubSpot.com/integrations/how-do-i-get-my-HubSpot-api-key).
+
+You can find the ID of any list in HubSpot by navigating to the list in your portal and inspecting the URL. The format of the URL is:
+`https://app.hubspot.com/contacts/{portal id}/lists/{list id}`
+
+Once you have retrieved your HubSpot API Key and HubSpot List ID, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Add New Contact to HubSpot for Marketing** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| HUBSPOT_API_KEY | Your HubSpot API Key. |
+| HUBSPOT_NEW_MEMBER_LIST_ID | ID of the HubSpot list to which you want to add a new member. |
+
+By default, your rule will be activated upon save. Upon authentication, users will now show up as Contacts and be added to the specified list in HubSpot.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/integrate-maxmind.md b/ja-jp/articles/rules/guides/integrate-maxmind.md
new file mode 100644
index 0000000000..4078db7c80
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-maxmind.md
@@ -0,0 +1,48 @@
+---
+title: Integrate with MaxMind minFraud
+description: Learn how to integrate MaxMind minFraud using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with MaxMind minFraud
+
+To assess the risk profile of a user before authenticating them, you may want to integrate with MaxMind minFraud services, a risk-based authentication solution. You can do this using a specialized rule template.
+
+In this example, we will use a rule to call MaxMind and determine whether or not the user is fraudulent based on their device fingerprint.
+
+## Prerequisites
+
+Before connecting your Auth0 app to MaxMind, you must [sign up for and configure your account with MaxMind](https://www.maxmind.com/en/solutions/minfraud-services).
+
+## Steps
+
+To connect your app to MaxMind, you will:
+
+1. [Get your MaxMind credentials](#get-your-maxmind-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your MaxMind credentials
+
+First, you will need to retrieve your MaxMind Account ID and generate a License Key. To locate your Account ID, see [MaxMind Support](https://support.maxmind.com/). To learn how to generate a License Key, see [MaxMind's Generating License Keys for Your Account](https://www.maxmind.com/en/accounts/current/license-key).
+
+Once you have retrieved your MaxMind Account ID and License Key, keep these values on hand because we will use them in the next step. In particular, keep track of your License Key because MaxMind will display it to you only once--at the time of generation.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Alternate Risk Score** template from the **Enrich Profile** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| MINFRAUD_ACCOUNT_ID | MaxMind minFraud Account ID. |
+| MINFRAUD_LICENSE_KEY | MaxMind minFraud License Key. |
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/integrate-mixpanel.md b/ja-jp/articles/rules/guides/integrate-mixpanel.md
new file mode 100644
index 0000000000..64681528b6
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-mixpanel.md
@@ -0,0 +1,44 @@
+---
+title: Integrate with MixPanel Product Analytics
+description: Learn how to integrate MixPanel Product Analytics using rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with MixPanel Product Analytics
+
+To help convert, engage, and retain users, you may want to integrate with MixPanel Product Analytics. You can do this using a specialized rule template.
+
+In this example, we will use a rule to send a sign-in event to MixPanel and will include the application to which the user is logging in as a property.
+
+## Prerequisites
+
+Before connecting your Auth0 app to MixPanel, you must [sign up for and configure your account with MixPanel](https://mixpanel.com/).
+
+## Steps
+
+To connect your app to MixPanel, you will:
+
+1. [Get your MixPanel credentials](#get-your-mixpanel-credentials)
+2. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Get your MixPanel credentials
+
+First, you will need to retrieve the URL of MixPanel's API and your API Token. To learn how to do this, see [MixPanel's Ingestion API HTTP spec](https://developer.mixpanel.com/docs/http).
+
+Once you have retrieved the MixPanel API's URL and your API Token, keep these values on hand because we will use them in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Tracks Logins in Mixpanel** template from the **Webhook** section, then use the following settings:
+
+| Variable | Value |
+| -------- | ----- |
+| url | MixPanel API URL |
+| token | MixPanel API Token. You may use global variables to configure this in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first. |
+
+By default, your rule will be activated upon save.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/integrate-salesforce.md b/ja-jp/articles/rules/guides/integrate-salesforce.md
new file mode 100644
index 0000000000..0199086e95
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-salesforce.md
@@ -0,0 +1,72 @@
+---
+title: Integrate with Salesforce
+description: Learn how to integrate Salesforce using rules. 
+toc: true
+topics:
+  - rules
+  - extensibility
+  - integration
+contentType: how-to
+useCase: extensibility-rules
+---
+# Integrate with Salesforce
+
+To automate and manage your customer life cycle, you may want to integrate with Salesforce's customer relationship management solution. You can do this using a specialized rule template.
+
+In this example, we will use a rule to record a new Salesforce Lead when a new user first authenticates. The rule will also send a notification for the new Lead to a specified Slack channel.
+
+## Prerequisites
+
+Before connecting your Auth0 app to Salesforce, you must [sign up for and configure your account with Salesforce](https://www.salesforce.com/).
+
+## Steps
+
+To connect your app to Salesforce, you will:
+
+1. [Set up your app in Salesforce](#set-up-your-app-in-salesforce)
+2. [Get your Salesforce credentials](#get-your-salesforce-credentials)
+3. [Get your Slack channel hook URL](#get-your-slack-channel-hook-url)
+4. [Create and activate a rule in Auth0](#create-and-activate-a-rule-in-auth0)
+
+### Set up your app in Salesforce
+
+Create an app in Salesforce and generate credentials for it, using [Salesforce's Create a Connected App](https://help.salesforce.com/articleView?id=connected_app_create.htm&type=0) docs. During this process, Salesforce will generate a **Consumer Key** and **Consumer Secret** for your application; make note of these.
+
+While setting up your app, make sure you use the following settings:
+
+| Field | Value to Provide |
+| - | - |
+| App URL | `https://${account.namespace}` |
+| Callback URL | `https://${account.namespace}/login/callback` |
+
+<%= include('../../connections/_find-auth0-domain-redirects') %>
+
+### Get your Salesforce credentials
+
+You will also need to get your Salesforce username and password that you use to authenticate with the Salesforce API. This username will appear as the creator of the Lead.
+
+Once you have retrieved your Salesforce username and password, keep these values on hand because we will use them in a future step.
+
+### Get your Slack channel hook URL
+
+To send a notification for the new Lead to a specified Slack channel, you will need to get the Slack channel's hook URL from your [Slack Workspace's Integrations](https://slack.com/services/10525858050).
+
+Make note of the Slack channel's hook URL because we will use it in the next step.
+
+### Create and activate a rule in Auth0
+
+[Set up a rule](/dashboard/guides/rules/create-rules) in Auth0. While setting up your rule, select the **Create a New Lead in Salesforce on First Login** template from the **Webhook** section, then use the following settings:
+
+::: warning
+You may use global variables to configure these in your rule. If so, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first.
+:::
+
+| Variable | Value |
+| -------- | ----- |
+| SFCOM_CLIENT_ID | Consumer Key for the application you previously set up in Salesforce. |
+| SFCOM_CLIENT_SECRET | Consumer Secret for the application you previously set up in Salesforce. |
+| USERNAME | Username you use to authenticate with Salesforce's API. |
+| PASSWORD | Password you use to authenticate with Salesforce's API. |
+| MY_SLACK_WEBHOOK_URL | Hook URL for the Slack channel to which you want to send a notification of a new Salesforce Lead. |
+
+By default, your rule will be activated upon save.
diff --git a/ja-jp/articles/rules/guides/integrate-user-id-verification.md b/ja-jp/articles/rules/guides/integrate-user-id-verification.md
new file mode 100644
index 0000000000..fbfe64ed0b
--- /dev/null
+++ b/ja-jp/articles/rules/guides/integrate-user-id-verification.md
@@ -0,0 +1,56 @@
+---
+title: Integrate User ID Verification Services Using Rules
+description: Learn how to integrate third-party user identity verification services using rules.  
+topics:
+  - rules
+  - extensibility
+  - identity-providers
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Integrate User ID Verification Services Using Rules
+
+Auth0 allows integration with third-party vendors that offer identity verification. Such integration can be done by either connecting the third-party vendor as a federated identity provider using either a [custom OIDC Connection](/connections/enterprise/oidc) or the [SAML protocol](/saml), or by using [Auth0 Rules](/rules).
+
+In this example, you will integrate with OnFido, a third-party vendor providing Document ID and Facial Biometrics Verification, using a [redirect rule](/rules/guides/redirect) in Auth0.
+
+## Prerequisites
+
+Before connecting your Auth0 app to OnFido, you must [sign up for and configure your account with OnFido](https://onfido.com/us/).
+
+## User ID verification login experience
+
+The authentication flow contains the following steps:
+
+1. An app initiates an authentication request to Auth0.
+2. Auth0 routes the request to an Identity Provider through a configured connection.
+3. The user authenticates successfully.
+4. The [ID Token](/tokens/concepts/id-tokens) and/or Access Token is passed through the Rules pipeline, then sent to the app.
+
+The user will see the following screens when the third-party verification service is part of the authentication flow.
+
+The user chooses to login with Google. 
+
+![OnFido Verification Login Screen](/media/articles/rules/onfido-verification-login1.png)
+
+The login process then prompts the user to select a document to use to verify their identity.
+
+![OnFido Verify Identity](/media/articles/rules/onfido-verify-identity.png)
+
+After the user performs the steps to verify their identity, uploading documents and/or images, the verification service determines if the credentials are valid and then continues.
+
+![OnFido Verify Success](/media/articles/rules/onfido-verify-success.png)
+
+## Metadata example
+
+The information of the OnFido verification is then stored in a [user’s app metadata](/users/concepts/overview-user-metadata) within the Auth0 user profile.
+
+![OnFido Metadata Example](/media/articles/rules/onfido-metadata-example.png)
+
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
diff --git a/ja-jp/articles/rules/guides/management-api.md b/ja-jp/articles/rules/guides/management-api.md
new file mode 100644
index 0000000000..bc49ddd310
--- /dev/null
+++ b/ja-jp/articles/rules/guides/management-api.md
@@ -0,0 +1,49 @@
+---
+title: Use the Management API from within Rules
+description: Learn how to use the Management API from within rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - management-api
+contentType: how-to
+useCase: extensibility-rules
+---
+# Use the Management API from within Rules
+
+From within any [Rule](/rules) you write, you can update a user's `app_metadata` or `user_metadata` using the [`auth0` object](/best-practices/rules#auth0-object), which is a specially-restricted instance of `ManagementClient` (defined in the [node-auth0](https://github.com/auth0/node-auth0) Node.js client library) and provides limited access to the [Auth0 Management API](/api/management/v2). 
+
+To access additional Management API endpoints from inside Rules, you have to use another version of the library.
+
+::: note
+The Access Token for the Management API, which is available through `auth0.accessToken`, is limited to the `read:users` and `update:users` scopes. If you require a broader range of scopes, you can request a token using the Client Credentials grant. See [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production).
+:::
+
+## Access a newer version of the library
+
+You can load a newer version of the Auth0 Node.js client library by requiring the specific version of the library. For up-to-date version information, check the [repository](https://github.com/auth0/node-auth0).
+
+In this example, we load version `2.9.1` of the library, then query the list of users and logs the users to the console (to be inspected with the [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs)).
+
+:::warning
+[Searching for users](/best-practices/search-best-practices) from inside Rules may affect the performance of your logins; we advise against it. 
+:::
+
+```js
+function (user, context, callback) {
+  var ManagementClient = require('auth0@2.9.1').ManagementClient;
+  var management = new ManagementClient({
+    token: auth0.accessToken,
+    domain: auth0.domain
+  });
+
+  management.getUsers(function (err, users) {
+    console.log(users);
+    callback(null, user, context);
+  });
+}
+```
+
+::: note
+For a filtered list of available libraries that can be set as required, check the [available library versions](https://auth0-extensions.github.io/canirequire/#auth0).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/rules/guides/metadata.md b/ja-jp/articles/rules/guides/metadata.md
new file mode 100644
index 0000000000..3a8247c063
--- /dev/null
+++ b/ja-jp/articles/rules/guides/metadata.md
@@ -0,0 +1,498 @@
+---
+description: Learn how to work with app metadata, user metadata, and client metadata in Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - metadata
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Use Metadata in Rules
+
+You can read, update, and delete [metadata](/metadata) using [Rules](/rules).
+
+::: panel-warning `app_metadata` field names
+Avoid using the same name for `app_metadata` fields and root profile fields. Within the rules scope, `app_metadata` is squashed into the root profile and may override root properties.
+
+For example, if a SAML identity provider returns a `groups` field and the user has an `app_metadata.groups` field, then `user.groups` will be equal to `app_metadata.groups` and not `user.groups`.
+:::
+
+In the following sections, we will refer to this example where the user and their information is represented by the following JSON snippet:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+## Read Metadata
+
+To read the available metadata, you will need to access the correct user property.
+
+### Read `app_metadata`
+
+Using rules, you can make a decision based on the user's roles:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  if (user.app_metadata.roles.indexOf('writer')){
+    // code to be executed
+  }
+  ...
+}
+```
+
+### Read `user_metadata`
+
+Similarly, you can base decisions on specific preferences, such as a color preference:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  if (user.user_metadata.preferences.color === 'black'){
+    // code to be executed
+  }
+  ...
+}
+```
+
+## Update metadata
+
+### Read `client_metadata`
+
+`clientMetadata` is an optional, top-level property of the context object. Existing applications will have no value for this property.
+
+```js
+function(user, context, callback){
+  context.clientMetadata = context.clientMetadata || {};
+  if (context.clientMetadata.usersuppliedkey1 === 'black'){
+    // this code would not be executed for the user
+  }
+  ...
+}
+```
+
+#### Read `client_metadata` with the Management API
+
+`client_metadata` is included in the response to the `GET /api/v2/clients` and `GET /api/v2/client/{id}` endpoints
+
+#### Create applications with `client_metadata` properties
+
+A `client_metadata` object can be included when creating a new application via the `POST /api/v2/` applications endpoint.
+
+#### Create `client_metadata` properties in the dashboard
+
+`client_metadata` key value pairs can also be added in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section, enter the key and value then click **CREATE**.
+
+![Create application metadata](/media/articles/rules/adv-settings-create.png)
+
+All rules include an `auth0` object (which is an instance of the [node-auth0 SDK](https://github.com/auth0/node-auth0)) that is capable of calling the [Auth0 Management API v2](/api/management/v2). The `auth0` object is preconfigured with the necessary permissions to update users.
+
+### Update `app_metadata`
+
+To add an administrative role to the user:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = user.app_metadata.roles || [];
+  user.app_metadata.roles.push('administrator');
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer", "administrator" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+### Update `user_metadata`
+
+To add the user's `fontSize` preference to the user profile:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  user.user_metadata.preferences.fontSize = 12;
+
+  // persist the user_metadata update
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue",
+      "fontSize": 12
+    }
+  }
+}
+```
+
+### Update `app_metadata` and `user_metadata` simultaneously
+
+To reduce the rule's processing time, you may update both the `app_metadata` and `user_metadata` in the same rule:
+
+```js
+function(user, context, callback){
+
+  var q = require('q');
+
+  user.app_metadata = user.app_metadata || {};
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  user.user_metadata.preferences.fontSize = 12;
+
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = user.app_metadata.roles || [];
+  user.app_metadata.roles.push('admin');
+
+  // persist the app_metadata update
+  var appMetadataPromise  = auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
+
+  // persist the user_metadata update
+  var userMetadataPromise = auth0.users.updateUserMetadata(user.user_id, user.user_metadata);
+
+  // using q library to wait for all promises to complete
+  q.all([userMetadataPromise, appMetadataPromise])
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer", "admin" ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue",
+      "fontSize": 12
+    }
+  }
+}
+```
+
+## Manage `client_metadata`
+
+`client_metadata` is a multi-purpose key/value hash to store information about an application (i.e. a “client” in OIDC/OAuth2 lingo). You might store, for example, the URL for the application’s home page (a field that Auth0 doesn’t provide by default in the application settings).
+
+You get or set `client_metadata` either using the [clients API](/api/v2/clients/{client_id}) or in the Dashboard, in the application’s advanced settings. The `client_metadata` is stored as part of the application (client) properties.
+
+::: panel Where to store a secret to be returned in a JWT
+Where to store the secret depends on the scope of the secret:
+
+* Is it just one secret per application? Then `client_metadata` would be a good place. But if this is the case, you should consider storing the secret directly in the application instead, to avoid putting the secret in the ID token.
+* Is it the same secret for the whole system (i.e. for all application, or many)? Then the rule’s configuration values might be a better choice
+* Is it a different secret for each user? Then `app_metadata` might be better.
+:::
+
+`clientMetadata` is an optional, top-level property of the `context` object. Existing applications will have no value for this property.
+
+```js
+function(user, context, callback){
+  context.clientMetadata = context.clientMetadata || {};
+  if (context.clientMetadata.usersuppliedkey1 === 'black'){
+    // this code would not be executed for the user
+  }
+  ...
+}
+```
+
+::: warning
+Claims in the ID Token are not encrypted, so depending on the flow that you use the user might be able to get the token and inspect the contents. Auth0 does **not** recommend storing a secret in that way. 
+:::
+
+You can read and add to the `client_metadata` using either the Management API or the Dashboard. 
+
+* In the Management API, the `client_metadata` is included in the response to the `GET /api/v2/clients` and `GET /api/v2/client/{id}` endpoints. A `client_metadata` object can be included when creating a new application via the `POST /api/v2/` endpoint.
+
+* In the Dashboard, you can add the `client_metadata` key value pairs in [Applications](${manage_url}/#/applications). 
+  * Select the settings (the gear icon) of the application you wish to edit. 
+  * Scroll down and click the link **Show Advanced Settings**. 
+  * In the **Application Metadata** section, enter the key and value then click **CREATE**.
+
+![Create application metadata](/media/articles/rules/adv-settings-create.png)
+
+Application metadata can be updated using the [`PATCH /api/v2/clients/{id}`](/api/management/v2#!/Users/patch_users_by_id) endpoint, supplying an application object with the `client_metadata property`, whose value is an object containing the metadata you'd like to change.
+
+*Application Before*
+
+```
+{
+  ...
+  "name": "myclient",
+  "client_metadata": {
+    "mycolor": "red",
+    "myflavor": "grape"
+  }
+  ...
+}
+```
+
+Request: `PATCH /api/v2/client/myclientid123` with body:
+
+```
+{ "client_metadata": { "mycolor": "blue" } }
+```
+
+*Application After*
+
+```
+{
+  "name": "myclient",
+  "client_metadata": {
+    "mycolor": "blue",
+    "myflavor": "grape"
+  }
+  ...
+}
+```
+
+#### Update `client_metadata` in the dashboard
+
+Application metadata can also be updated in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section. For the key value, enter the name of the key you wish to edit. Then enter the new value that you want to update. 
+
+Click **UPDATE**. A popup window will appear to confirm your overwrite.
+
+![Confirm Update](/media/articles/rules/confirm-overwrite.png)
+
+## Delete Metadata
+
+### Delete `app_metadata` properties and values
+
+To delete a property, set the property's value to `null`.
+
+For example, to delete the user's roles:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  // update the app_metadata that will be part of the response
+  user.app_metadata.roles = null;
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": { },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+To delete a single value of a property, remove that value specifically.
+
+For example, to remove the `writer` role from the user profile:
+
+```js
+function(user, context, callback){
+  user.app_metadata = user.app_metadata || {};
+  user.app_metadata.roles = user.app_metadata.roles || [];
+
+  var index = user.app_metadata.roles.indexOf('writer');
+
+  if (index !== -1){
+    // update the app_metadata that will be part of the response
+    user.app_metadata.roles.splice(index, 1);
+  }
+
+  // persist the app_metadata update
+  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "google-oauth2|1234",
+  "email": "john.doe@gmail.com",
+  "app_metadata": {
+    "roles": [ ]
+  },
+  "user_metadata": {
+    "preferences": {
+      "color": "blue"
+    }
+  }
+}
+```
+
+Note that the `roles` property still exists but does not contain any value.
+
+### Delete `user_metadata` properties and values
+
+To delete the user's color preference:
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  // update the user_metadata that will be part of the response
+  user.user_metadata.preferences = user.user_metadata.preferences || {};
+  delete user.user_metadata.preferences.color;
+
+  // persist the user_metadata update
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+  });
+}
+```
+
+This results in the following JSON representation of the user profile details:
+
+```json
+{
+  "user_id": "jdoe",
+  "email": "john.doe@example.com",
+  "app_metadata": {
+    "roles": [ "writer" ]
+  },
+  "user_metadata": {
+    "preferences": { }
+  }
+}
+```
+
+### Delete `client_metadata` properties and values
+
+`client_metadata` keys can be removed by issuing a PATCH, [as described above](#updating-application_metadata), but supplying a null for the key value. This behavior matches that of the `user_metadata` and `app_metadata` properties in the `PATCH` [/api/v2/users/{id}](/api/management/v2#!/Users/patch_users_by_id) endpoint.
+
+#### Delete `client_metadata` properties and values in the dashboard
+
+`client_metadata` keys can also be removed in [the dashboard](${manage_url}/#/applications), by going to **Applications**. Then select the settings(the gear icon) of the application you wish to edit.
+
+Scroll down and click the link **Show Advanced Settings**. Then you will be in the **Application Metadata** section, click the **REMOVE** button for the key/value pair you wish to delete.
+
+![Remove application metadata](/media/articles/rules/adv-settings-remove.png)
+
+## Considerations
+
+The metadata must be a valid JSON object and can not contain a dot in key field names in `user_metadata`, `app_metadata` or `client_metadata`.
+
+This is not allowed:
+
+```js
+{
+  "preference.color" : "pink"
+}
+```
+
+This, however, is accepted:
+
+```js
+{
+  "color" : "light.blue"
+}
+```
+
+If you use a key field name with a dot in it you will get an Internal Server (500) error.
+
+As a workaround, you can convert the first example to something like this.
+
+```js
+{
+  "preference" : {"color" : "pink" }
+}
+```
+
+Or you could use a different delimiter character besides `.` (dot) or `$` (dollar sign).
+
+`client_metadata` is an object, whose keys and values are strings, with a maximum length of 255 characters. Also `client_metadata` is restricted to having a maximum 10 keys.
+
+## Keep reading
+
+::: next-steps
+* [Use the Management API in rules](/rules/current/management-api)
+* [Properties of the Context Argument](/rules/current/context)
+:::
diff --git a/ja-jp/articles/rules/guides/redirect.md b/ja-jp/articles/rules/guides/redirect.md
new file mode 100644
index 0000000000..160a5dcf45
--- /dev/null
+++ b/ja-jp/articles/rules/guides/redirect.md
@@ -0,0 +1,248 @@
+---
+title: Redirect Users From Within Rules
+description: Learn how to customize authentication flows by redirecting users using rules. Example areas that can be customized include MFA, privacy policy acceptance, and gathering user data.
+toc: true
+topics:
+  - rules
+  - extensibility
+  - redirection
+contentType: how-to
+useCase: extensibility-rules
+---
+
+# Redirect Users From Within Rules
+
+You can use [Rules](/rules) to redirect users before an authentication transaction is complete. This lets you implement custom authentication flows that require additional user interaction beyond the standard login form. Redirect rules can be used for:
+
+* [Custom Multi-factor Authentication (MFA)](/mfa/guides/customize-mfa-universal-login).
+* Custom privacy policy acceptance, terms of service, and data disclosure forms.
+* Securely performing a one-time collection of additional required profile data.
+* Allowing remote Active Directory users to change their password.
+* Requiring users to provide additional verification when logging in from unknown locations.
+* Gathering more information about your users than they provided at initial signup.
+
+::: note
+You can redirect a user **once** per authentication flow. If you have one rule that redirects a user, you **cannot** invoke a second rule to redirect the user at a later time.
+:::
+
+## Start redirect and resume authentication
+
+1. Set the `context.redirect` property as follows:
+
+    ```js
+    function (user, context, callback) {
+        context.redirect = {
+            url: "https://example.com/foo"
+        };
+        return callback(null, user, context);
+    }
+    ```
+
+    Once all rules have finished executing, Auth0 redirects the user to the URL specified in the `context.redirect.url` property. Auth0 also passes a `state` parameter in that URL. For example:
+
+    ```
+    https://example.com/foo?state=abc123
+    ```
+
+    Your redirect URL will need to extract the `state` parameter and send it back to Auth0 to resume the authentication transaction. State is an opaque value, used to prevent [Cross-Site Request Forgery (CSRF) attacks](/security/common-threats#cross-site-request-forgery).
+
+2. After the redirect, resume authentication by redirecting the user to the `/continue` endpoint and include the `state` parameter you received in the URL. 
+
+    ::: warning
+    If you do not send the original state back to the `/continue` endpoint, Auth0 will lose the context of the login transaction and the user will not be able to log in due to an `invalid_request` error.
+    :::
+
+    For example:
+
+    ```http
+    https://${account.namespace}/continue?state=THE_ORIGINAL_STATE
+    ```
+
+    If you're using a custom domain:
+
+    ```http
+    https://YOUR_AUTH0_CUSTOM_DOMAIN/continue?state=THE_ORIGINAL_STATE
+    ```
+
+    `THE_ORIGINAL_STATE` is the value that Auth0 generated and sent to the redirect URL. For example, if your rule redirected to `https://example.com/foo`, Auth0 would use a redirect URL similar to `https://example.com/foo?state=abc123`. So `abc123` would be the `THE_ORIGINAL_STATE`. To resume the authentication transaction, you would redirect to
+
+    ```http
+    https://${account.namespace}/continue?state=abc123
+    ```
+
+    When a user has been redirected to the `/continue` endpoint, **all rules will be run again**, however, the `context.redirect` will be ignored to allow authentication to continue.
+
+::: note
+When a user has been redirected from a rule to the `/continue` endpoint, the user object won't be refreshed. So any updates to user account information during the redirect will not be reflected in the user object. For example, metadata updates that occurred during redirect will not be available.
+:::
+
+## Validate resumed login
+
+To distinguish between user-initiated logins and resumed login flows, check the `context.protocol` property:
+
+```js
+function (user, context, callback) {
+    if (context.protocol === "redirect-callback") {
+        // User was redirected to the /continue endpoint
+    } else {
+        // User is logging in directly
+    }
+}
+```
+
+## Force password change example
+
+In some cases, you may want to force users to change their passwords under specific conditions. You can write a rule that has the following behavior:
+
+1. The user attempts to log in and needs to change their password.
+2. The user is redirected to an application-specific page with a JWT in the query string. This JWT ensures that only this user's password can be changed and **must be validated** by the application.
+3. The user changes their password in the application-specific page by having the application call the [Auth0 Management API](/api/v2#!/Users/patch_users_by_id)
+4. Once the user has successfully changed their password, the application extracts the `authorize_again` claim from the verified and decoded JWT, then proceeds to redirect the user to that URL allowing them to sign in with their new password.
+
+```js
+function(user, context, callback) {
+   /*
+   * Prerequisites:
+   * 1. Implement a `mustChangePassword` function
+   * 2. Set configuration variables for the following:
+   *    - CLIENT_ID
+   *    - CLIENT_SECRET
+   *    - ISSUER
+   */
+
+  const url = require('url@0.10.3');
+  const req = context.request;
+
+  function mustChangePassword() {
+    // TODO: implement function
+    return true;
+  }
+
+  if (mustChangePassword()) {
+    // User has initiated a login and is forced to change their password
+    // Send user's information and query params in a JWT to avoid tampering
+    function createToken(clientId, clientSecret, issuer, user) {
+      const options = {
+        expiresInMinutes: 5,
+        audience: clientId,
+        issuer: issuer
+      };
+      return jwt.sign(user, clientSecret, options);
+    }
+
+    const token = createToken(
+      configuration.CLIENT_ID,
+      configuration.CLIENT_SECRET,
+      configuration.ISSUER,
+      {
+        sub: user.user_id,
+        email: user.email,
+        authorize_again: url.format({
+          protocol: 'https',
+          hostname: auth0.domain,
+          pathname: '/authorize',
+          query: req.query
+        })
+      }
+    );
+
+    context.redirect = {
+      url: `<%= "https://example.com/change-pw?token=${token}"%>`
+    };
+  }
+
+  return callback(null, user, context);
+}
+```
+
+## Where to store data
+
+Beware of storing too much data in the Auth0 profile. This data is intended to be used for authentication and authorization purposes. The metadata and search capabilities of Auth0 are not designed for marketing research or anything else that requires heavy search or update frequency. Your system is likely to run into scalability and performance issues if you use Auth0 for this purpose. A better approach is to store data in an external system and store a pointer (the user ID) in Auth0 so that backend systems can fetch the data if needed. A simple rule to follow is to store only items that you plan to use in rules to add to tokens or make decisions.  
+
+## Security considerations
+
+Passing information back and forth in the front channel opens up surface area for bad actors to attack.  This should definitely be done only in conditions where you must take action in the rule (such as rejecting the authorization attempt with `UnauthorizedError`). 
+
+If, however, you need to communicate directly back to Auth0 and give it instructions for restricting access (you are implementing CAPTCHA checks or custom MFA), then you must have a way to securely tell Auth0 that the requirements of that operation were performed.  Likewise, if you need to hand information to the application that you are redirecting to, then you must have a secure way to ensure that the information transferred has not been tampered with.  
+
+### Ensure app is logging into the same user
+
+The application is going to redirect the user back to the Auth0 tenant, so any data related to the user can be gathered through the ID token that is returned to the application.  However, you may want to ensure that the application is logging into the same user that is being redirected from to ensure that there is no tampering of any sort in-between.  Therefore you will likely want to send a token along with the request.
+
+The token sent to the app should have the following requirements:
+
+| Token Element | Description |
+| -- | -- |
+| `sub` | The Auth0 `user_id` of the user. |
+| `iss` | An identifier that identifies the rule itself. |
+| `aud` | The application that is targeted for the redirect. |
+| `jti` | A randomly generated string that is stored for confirmation in the user object (in the rule code, set user.jti = uuid.v4(); and then add it as a jti to the token you create).  user.jti will still be set when rules run again when /continue is called.  This is inline with specifications. |
+| `exp` | Should be as short as possible to avoid re-use of the token. |
+| `other` | Any other custom claims information you need to pass. |
+| `signature` | Assuming that the application has a secure place to store a secret, you can use HS256 signed signatures.  This greatly reduces the complexity of the solution and since the token being passed back will have to be signed as well, this is a requirement of this solution.  You can use RS256, but it requires the creating of a certificate and updating that certificate when it expires.  If you are not passing any information directly back to the rules, then you could use an SPA for this intermediate app and then may prefer RS256 so that the application doesn't have to store the info.  It would require you to have a way to validate the token, either through an introspection endpoint or through a public JWKS endpoint. |
+
+::: warning
+This token should **not** be treated as a Bearer token!  It is a signed piece of information for use in the application.  The application should still redirect back to Auth0 to authenticate the user.
+:::
+
+### Pass information back to the rule
+
+In most scenarios, even if you want to pass information from the rule to the application.  The application will hopefully be able to safely store the information in whatever storage is necessary.  Even if the idea is to update the app or user metadata in Auth0, that can be done using the management API and the user information will be updated as long as it has been completed before redirecting the user back to the `/continue` endpoint.  Only if the rule itself must get information and that information is only relevant to this particular sign in session should you pass information back to the rule.
+
+When passing information back to the `/continue` endpoint, the token passed should have the following requirements:
+
+| Token Element | Description |
+| -- | -- |
+| `sub` | The Auth0 `user_id` of the user. |
+| `iss` | The application that is targeted for the redirect. |
+| `aud` | Some identifier that identifies the rule itself. |
+| `jti` | The same JTI that was stored in the token passed to the application (NOTE: it should match user.jti or fail). |
+| `exp` | Should be as short as possible to avoid reuse of the token. |
+| `other` | Any other custom claims information you need to pass. |
+| `signature` | Assuming that the application has a secure place to store a secret, you can use HS256 signed signatures.  This greatly reduces the complexity of the solution and since the token being passed back will have to be signed as well, this is a requirement of this solution.  You can use RS256, but it requires the creating of a certificate and updating that certificate when it expires. |
+
+It should be sent using POST and then fetched at `context.request.body.token` (or something similar) rather than passing it as a query parameter.  This is similar to the form-post method for authentication.
+
+If you are not passing information back to the `/continue` endpoint, you may want to blacklist the JTI unless your expiration times are short enough that replay attacks will be almost impossible. 
+
+## Restrictions and limitations
+
+Redirect Rules won't work with:
+- [Resource Owner endpoint](/api/authentication/reference#resource-owner)
+- [Password exchange](/api-auth/grant/password)
+- [Refresh Token exchange](/tokens/concepts/refresh-token#rules)
+
+You can detect the above cases by checking `context.protocol`:
+- For Password exchange: `context.protocol === 'oauth2-password'`
+- For Refresh Token exchange: `context.protocol === 'oauth2-refresh-token'`
+- For Resource Owner logins: `context.protocol === 'oauth2-resource-owner'`
+
+### Resource Owner endpoint
+
+It is impossible to use redirect rules in the context where you are calling /oauth/token directly for the Resource Owner Password Grant.  Since the user is not in a redirect flow to begin with, you can not redirect the user in a rule.  If you attempt to set context.redirect you will get a failed login attempt with the error interaction_required.
+
+### Flows where `prompt=none`
+
+Since the goal of `prompt=none` is to avoid any scenario where the user will be required to enter input, any redirection will result in an `error=interaction_required`.
+
+Since rules run after an authentication session is created, you cannot use `prompt=none` if you have a redirect rule that is attempting to block access to tokens under certain conditions (custom MFA, CAPTCHA with login, etc.).  
+
+You cannot create a redirect flow that blocks token access and bypasses the redirect rule if `prompt=none` because after a failed attempt, a user can simply call again with `prompt=none` and get tokens because their authentication session has been created even though rules failed the first time.
+
+### Refresh tokens
+
+Due to the fact that using a refresh token requires a backchannel call to `/oauth/token`, this will also fail if you set `context.redirect`.
+
+It is difficult to securely verify that any restrictions on login were carried out. There is not a consistent session ID in the context that could be used to collect information associated with the session such as *this user passed MFA challenges*. Therefore, you cannot use `prompt=none` at all. 
+
+Anytime `context.redirect` is set in a rule, if `prompt=none` was passed, then the authorization fails with `error=interaction_required`, but since the user's session is created even if rules fail, we can't trust that a user passed all `context.redirect` challenges and therefore can't use `prompt=none` as a way to get tokens.  
+
+In this specific case, we recommend that you use refresh tokens exclusively, because you can ensure that a user passed challenges if those challenges are required to generate a refresh token.
+
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Resume Authentication](/rules/guides/redirect#resume-authentication)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
diff --git a/ja-jp/articles/rules/index.md b/ja-jp/articles/rules/index.md
new file mode 100644
index 0000000000..87116867e7
--- /dev/null
+++ b/ja-jp/articles/rules/index.md
@@ -0,0 +1,76 @@
+---
+description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+  - concept
+  - index
+useCase: extensibility-rules
+---
+
+# Rules
+
+Rules are JavaScript functions that execute when a user authenticates to your application. They run once the authentication process is complete, and you can use them to customize and extend Auth0's capabilities. For security reasons, your Rules code executes isolated from the code of other Auth0 tenants in a sandbox.
+
+Please note that rules also run during the [token refresh](/tokens/concepts/refresh-tokens) flow.
+
+## Authentication transaction flow
+
+![Rule Flow](/media/articles/rules/flow.png)
+
+1. An app initiates an authentication request to Auth0.
+2. Auth0 routes the request to an Identity Provider through a configured connection.
+3. The user authenticates successfully.
+4. The [ID Token](/tokens/concepts/id-tokens) and/or Access Token is passed through the Rules pipeline, then sent to the app.
+
+## What can I use Rules for?
+
+Among many possibilities, rules can be used to:
+
+* __Enrich user profiles__: query for information on the user from a database/API, and add it to the user profile object.
+* Create __authorization rules__ based on complex logic (anything that can be written in JavaScript).
+* __Normalize attributes__ from different providers beyond what is provided by Auth0.
+* Reuse information from existing databases or APIs for migration scenarios.
+* Keep a __white-list of users__ and deny access based on email.
+* __Notify__ other systems through an API when a login happens in real-time.
+* Enable counters or persist other information. For information on storing user data, see: [Metadata in Rules](/rules/guides/metadata).
+* Modify tokens: Change the returned __scopes__ of the Access Token and/or add claims to it, and to the ID Token.
+
+There are [many uses for Rules](/rules/references/use-cases). In the Dashboard, you can find example templates to help you get started with Rules under [**Rules > Create Rule**](${manage_url}/#/rules/new). The examples help you with things like MFA, external webhooks, enriching profile information, altering the authentication process, and more. You can use these templates as a starting point, then customizing them to suit your specific needs.
+
+::: warning How to Handle Rate Limits when calling Auth0 APIs
+For rules that call Auth0 APIs, you should always handle rate limiting by checking the X-RateLimit-Remaining header and acting appropriately when the number returned nears 0. You should also add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 429 (Too Many Requests); in this case, if a re-try is needed, it is best to allow for a back-off to avoid going into an infinite re-try loop. For more information about rate limits, see [Rate Limit Policy For Auth0 APIs](/policies/rate-limits).
+:::
+
+## Syntax
+
+A Rule is a function with the following arguments:
+
+* `user`: the user object as it comes from the identity provider. See [User Object in Rules](/rules/references/user-object) for a list of the available user properties. (However, if you execute the rule in the context of a call made to the delegation endpoint, the `user` object will also include the original JSON Web Token (JWT) claims.)
+
+* `context`: an object containing contextual information of the current authentication transaction, such as the user's IP address, application, or location. Check out the [Context Object in Rules](/rules/references/context-object) page for a list of the available context properties.
+
+* `callback`: a function to send potentially modified tokens back to Auth0, or an error. Because of the async nature of Node.js, it is important to always call the `callback` function or else the script will timeout.
+
+## Execution order
+
+In general, rules execute in the order shown on the Auth0 Dashboard. If a rule depends on the execution of another rule, move the dependent rule lower in the list.
+
+::: note
+Remember that rules run at a specific point within the authentication transaction flow. After rules run, the Redirect, Multi-factor Authentication (MFA), and Consent features must still run (in that order and only if they are required).
+:::
+
+## Available modules
+
+<%= include('./_includes/_supported-modules.md') %> 
+
+## Keep reading
+
+* [Context Object in Rules](/rules/references/context-object)
+* [User Object in Rules](/rules/references/user-object)
+* [Node.js Modules Available in Rules](/rules/references/modules)
+* [Sample Rules](/rules/references/samples)
+* [Rules (Legacy)](/rules/references/legacy)
diff --git a/ja-jp/articles/rules/references/context-object.md b/ja-jp/articles/rules/references/context-object.md
new file mode 100644
index 0000000000..929edfcfb3
--- /dev/null
+++ b/ja-jp/articles/rules/references/context-object.md
@@ -0,0 +1,53 @@
+---
+title: Context Object in Rules
+description: Describes the properties of the context object in Rules that stores information about users' IP addresses, applications, and location. 
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Context Object in Rules
+
+The `context` object stores contextual information about the current authentication transaction, such as the user's IP address, application, or location.
+
+::: note
+If you change token content using the context object within a rule, your changes will be available in tokens after all rules have finished running. If your application also requires multifactor authentication or user consent, the user will be prompted before changes in the token are available.
+:::
+
+## Properties
+
+The following properties are available for the `context` object.
+
+| Property | Description |
+|-|-|
+| `context.tenant` | A string containing the name of the tenant |
+| `context.clientID` | The client id of the application the user is logging in to. |
+| `context.clientName` | The name of the application (as defined on the dashboard). |
+| `context.clientMetadata` | An object for holding other application properties. Its keys and values are strings. |
+| `context.connectionID` | A string containing the connection's unique identifier |
+| `context.connection` | The name of the connection used to authenticate the user (such as: `twitter` or `some-g-suite-domain`) |
+| `context.connectionStrategy` | The type of connection. For social connection `connectionStrategy` === `connection`. For enterprise connections, the strategy will be `waad` (Windows Azure AD), `ad` (Active Directory/LDAP), `auth0` (database connections), and so on. |
+| `context.connectionOptions` | An object representing the options defined on the connection. `connectionOptions.tenant_domain` is a string containing the domain being used for authentication when using an Enterprise connection. `connectionOptions.domain_aliases` is an array containing the optional domains registered as aliases in addition to the primary domain (specified in the `connectionOptions.tenant_domain` property). |
+| `context.connectionMetadata` | An object representing metadata defined on the connection. Its keys and values are strings. |
+| `context.samlConfiguration` | An object that controls the behavior of the SAML and WS-Fed endpoints. Useful for advanced claims mapping and token enrichment (only available for `samlp` and `wsfed` protocol). |
+| `context.protocol` | <%= include('../_includes/_context-prop-protocol.md') %> |
+| `context.stats` | An object containing specific user stats, like `stats.loginsCount`. Note that any of the counter variables returned as part of the `stats` object do not increase during [silent authentication](/api-auth/tutorials/silent-authentication) (as when `prompt=none`). There are also scenarios where the counter variables might increase yet a rule or set of rules do not execute, as in the case of a successful cross-origin authentication followed by a failed token request. |
+| `context.sso` | <%= include('../_includes/_context-prop-sso.md') %> |
+| `context.accessToken` | An object representing the options defined on the Access Token. You can use this object to [add custom namespaced claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token) to the Access Token. `context.accessToken.scope` can be used to [change the Access Token's returned scopes](/rules/references/samples#modify-scope-of-access-token).  When provided, it is an array containing permissions in string format. Custom claims will be included in the Access Token after all rules have run. |
+| `context.idToken` | An object representing the options defined on the [ID Token](/tokens/concepts/id-tokens). Used to add custom [namespaced](/tokens/guides/create-namespaced-custom-claims) claims to the ID Token. Custom claims will be included in the ID Token after all rules have run. |
+| `context.original_protocol` | After a [redirect rule](/rules/current/redirect) has executed and the authentication transaction is resumed, this property will be populated with the original protocol used to initiate the transaction. |
+| `context.multifactor` | An object representing the multifactor settings used in [implementing contextual MFA](/mfa). |
+| `context.redirect` | The object used to [implement the redirection of a user from a rule](/rules/current/redirect#how-to-implement-a-redirect). |
+| `context.sessionID` | An internal identification for the authentication session. Value is kept only if `prompt=none` is used in the authorization request. Note that the session ID can change **after** rule execution on other flows, so the value available in `context.sessionID` might not match the new session ID that the user will receive. This makes this value only meaningful when `prompt=none` is used. |
+| `context.request` | <%= include('../_includes/_context-prop-request.md') %> |
+| `context.primaryUser` | The unique user id of the primary account for the user. Used to [link user accounts](/users/concepts/overview-user-account-linking#automatic-account-linking) from various identity providers. |
+| `context.authentication` | <%= include('../_includes/_context-prop-authentication.md') %> |
+| `context.authorization` | <%= include('../_includes/_context-prop-authorization.md') %> |
+
+## Read more
+
+* [Debug Rules](/rules/guides/debug)
+* [User Object](/rules/references/user-object)
+* [Sample Use Cases - Scopes and Claims: Add custom claims to a token](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
\ No newline at end of file
diff --git a/ja-jp/articles/rules/references/legacy.md b/ja-jp/articles/rules/references/legacy.md
new file mode 100644
index 0000000000..99cf62c5fb
--- /dev/null
+++ b/ja-jp/articles/rules/references/legacy.md
@@ -0,0 +1,287 @@
+---
+description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+useCase: extensibility-rules
+---
+
+# Rules (Legacy)
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline and the way rules can be used. We recommend you use the latest version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+**Rules** are functions written in JavaScript that are executed when a user authenticates to your application. They run once the authentication process is complete and you can use them to customize and extend Auth0's capabilities. They can be chained together for modular coding and can be turned on and off individually.
+
+![Rules Flow](/media/articles/rules/flow.png)
+
+1. An app initiates an authentication request to Auth0.
+1. Auth0 routes the request to an Identity Provider through a configured connection.
+1. The user authenticates successfully.
+1. The `user` object representing the logged in user is passed through the Rules pipeline, and returned to the app.
+
+Among many possibilities, Rules can be used to:
+
+* __Profile enrichment__: query for information on the user from a database/API, and add it to the user profile object.
+* Create __authorization rules__ based on complex logic (anything that can be written in JavaScript).
+* __Normalize attributes__ from different providers beyond what is provided by Auth0.
+* Reuse information from existing databases or APIs for migration scenarios.
+* Keep a __white-list of users__ and deny access based on email.
+* __Notify__ other systems through an API when a login happens in real-time.
+* Enable counters or persist other information. (For information on storing user data, see: [Metadata in Rules](/rules/metadata-in-rules).)
+* Enable __multifactor__ authentication, based on context (such as last login, IP address of the user, location, and so on).
+
+## Video: Using Rules
+
+Watch this video learn all about rules in just a few minutes.
+
+<%= include('../../_includes/_video', { id: 'g7dy1fpwc3' }) %>
+
+## Rule Syntax
+
+A Rule is a function with the following arguments:
+
+* `user`: the user object as it comes from the identity provider. For a complete list of the user properties, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes).
+
+* `context`: an object containing contextual information of the current authentication transaction, such as user's IP address, application, location. For a complete list of context properties, see [Context Argument Properties in Rules](/rules/references/context-object).
+
+::: note
+Due to the asynchronous nature of Node.js, you __must__ call the `callback` function. If not, this acts as a blocker and the next rule will not execute. The entire rules sequence must complete within __20 seconds__, otherwise the process times out.
+:::
+
+### Global Functions
+
+If you need to use a function in multiple Rules, you can place the shared function in its own Rule. Within this rule, assign the function to the global object so that you can later call the function in a separate rule.
+
+```js
+if (!global.foo) {
+  global.foo = function () { };
+}
+
+if (!global.bar) {
+  global.bar = function (baz) { };
+}
+```
+
+Rules containing shared functions should be placed at the top of the [Rules list in the Management Dashboard](${manage_url}/#/rules). If this is not the case, calling these functions results in an undefined function error when the Rules execute.
+
+## Examples
+
+To create a Rule, or try the examples below, go to [New Rule](${manage_url}/#/rules/create) in the Rule Editor on the dashboard.
+
+### *Hello World*
+
+This rule will add a `hello` attribute to all users authenticating through any provider.
+
+```js
+function (user, context, callback) {
+  user.hello = 'world';
+  console.log('===> set "hello" for ' + user.name);
+  callback(null, user, context);
+}
+```
+
+::: note
+You can add `console.log` lines for [debugging](#debugging) or use the [Real-time Webtask Logs Extension](/extensions/realtime-webtask-logs).
+:::
+
+
+### Add roles to a user
+
+In this example, all authenticated users will get a **guest** role, but `johnfoo@gmail.com` will also be an **admin**:
+
+```js
+function (user, context, callback) {
+  user.roles = [];
+  // only johnfoo is admin
+  if (user.email === 'johnfoo@gmail.com') {
+    user.roles.push('admin');
+  }
+
+  // all users are guest
+  user.roles.push('guest');
+
+  callback(null, user, context);
+}
+```
+
+At the beginning of the rules pipeline, John's `user` object will be:
+
+```js
+{
+  "email": "johnfoo@gmail.com",
+  "family_name": "Foo",
+  "user_id": "google-oauth2|103547991597142817347"
+  //... other properties ...
+}
+```
+
+The `context` object will be:
+
+```js
+{
+  "clientID": "...client_id_of_the_app...",
+  "clientName": "my app",
+  "clientMetadata": {
+    "myKey1": "myValue2",
+    "myKey2": "myValue2"
+  }
+  "connection": "google-oauth2"
+}
+```
+
+After the rule executes, the output that the application will receive is the following `user` object:
+
+```js
+{
+  "email": "johnfoo@gmail.com",
+  "family_name": "Foo",
+  "user_id": "google-oauth2|103547991597142817347",
+
+  //... other props ...
+
+  "roles": ["guest", "admin"]  // NEW PROPERTY ADDED BY THE RULE
+}
+```
+
+::: note
+Properties added in a rule are __not persisted__ in the Auth0 user store. Persisting properties requires calling the Auth0 Management API.
+:::
+
+### Deny access based on a condition
+
+In addition to adding and removing properties from the user object, you can return an *access denied* error.
+
+```js
+function (user, context, callback) {
+  if (user.roles.indexOf('admin') === -1) {
+    return callback(new UnauthorizedError('Only admins can use this'));
+  }
+
+  callback(null, user, context);
+}
+```
+
+This will cause a redirect to your callback URL with an `error` querystring parameter containing the message you set. (such as `https://yourapp.com/callback?error=unauthorized&error_description=Only%20admins%20can%20use%20this`). Make sure to call the callback with an instance of `UnauthorizedError` (not `Error`).
+
+::: note
+Error reporting to the app depends on the protocol. OpenID Connect (OIDC) apps will receive the error in the querystring. SAML apps will receive the error in a `SAMLResponse`.
+:::
+
+## Create Rules with the Management API
+
+Rules can also be created by creating a POST request to `/api/v2/rules` using the [Management APIv2](/api/management/v2#!/Rules/post_rules).
+
+This will creates a new rule according to the following input arguments:
+
+- ``name``: The name of the rule. It can only contain alphanumeric characters, spaces and '-', and cannot start nor end with '-' or spaces.
+
+- ``script`` : Τhe script that contains the rule's code. This is the same as what you would enter when creating a new rule using the [dashboard](${manage_url}/#/rules/create).
+
+- ``order``: This field is optional and contains a `number`. This number represents the rule's order in relation to other rules. A rule with a lower order than another rule executes first. If no order is provided it will automatically be one greater than the current maximum.
+
+- ``enabled``: This field can contain an optional `boolean`. If `true`, the rule will be enabled, if it's `false` it will be disabled.
+
+Example of a body schema:
+
+```
+{
+  "name": "my-rule",
+  "script": "function (user, context, callback) {\n  callback(null, user, context);\n}",
+  "order": 2,
+  "enabled": true
+}
+```
+Use this to create the POST request:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/rules",
+  "headers": [{
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"name\":\"my-rule\",\"script\":\"function (user, context, callback) {callback(null, user, context);}\",\"order\":2,\"enabled\":true}"
+  }
+}
+```
+
+
+## How to Debug Rules
+
+You can add `console.log` lines in the rule's code for debugging. The [Rule Editor](${manage_url}/#/rules/create)  provides two ways for seeing the output:
+
+![Rules Editor](/media/articles/rules/rule-editor.png)
+
+1. **TRY THIS RULE**: opens a pop-up where you can run a rule in isolation. The tool provides a mock **user** and **context** objects. Clicking **TRY** will result on the Rule being run with those two objects as input. `console.log` output will be displayed too.
+
+![Try this Rule](/media/articles/rules/try-rule.png)
+
+2. **REALTIME LOGS**: an [extension](${manage_url}/#/extensions) that displays all logs in real-time for all custom code in your account. This includes all `console.log` output, and exceptions.
+
+3. **DEBUG RULE**: similar to the above, displays instructions for installing, configuring and running the [webtask CLI](https://github.com/auth0/wt-cli) for debugging rules. Paste these commands into a terminal to see the `console.log` output and any unhandled exceptions that occur during Rule execution.
+
+<%= include('../../_includes/_webtask') %>
+
+  For example:
+
+  ```sh
+  ~  npm install -g wt-cli
+  ~  wt init --container "youraccount" --url "https://sandbox.it.auth0.com" --token "eyJhbGci...WMPGI" -p "youraccount-default-logs"
+  ~  wt logs -p "youraccount-default-logs"
+  [18:45:38.179Z]  INFO wt: connected to streaming logs (container=youraccount)
+  [18:47:37.954Z]  INFO wt: webtask container assigned
+  [18:47:38.167Z]  INFO wt: ---- checking email_verified for some-user@mail.com! ----
+  ```
+
+  This debugging method works for rules tried from the dashboard and those actually running during user authentication.
+
+## Cache expensive resources
+
+The code sandbox Rules run on allows storing _expensive_ resources that will survive individual execution.
+
+This example, shows how to use the `global` object to keep a mongodb connection:
+
+```js
+
+  ...
+
+  //If the db object is there, use it.
+  if (global.db){
+    return query(global.db, callback);
+  }
+
+  //If not, get the db (mongodb in this case)
+  mongo('mongodb://user:pass@mymongoserver.com/my-db',  function (db){
+    global.db = db;
+    return query(db, callback);
+  });
+
+  //Do the actual work
+  function query(db, cb){
+    //Do something with db
+    ...
+  });
+
+  ...
+
+```
+
+Notice that the code sandbox in which Rules run on, can be recycled at any time. So your code __must__ always check `global` to contain what you expect.
+
+## Available modules
+
+For security reasons, the Rules code runs in a JavaScript sandbox where you can use the full power of the ECMAScript 5 language.
+
+For a list of currently supported sandbox modules, see: [Modules Supported by the Sandbox](https://auth0-extensions.github.io/canirequire/).
+
+## Read more
+
+* [Redirecting users from within rules](/rules/redirect)
diff --git a/ja-jp/articles/rules/references/modules.md b/ja-jp/articles/rules/references/modules.md
new file mode 100644
index 0000000000..aee9a8c3b9
--- /dev/null
+++ b/ja-jp/articles/rules/references/modules.md
@@ -0,0 +1,13 @@
+---
+title: Node.js Modules Available in Rules
+description: A list of the Node.js modules and libraries that are available when creating Rules.
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Node.js Modules Available in Rules
+
+<%= include('../_includes/_supported-modules.md') %> 
diff --git a/ja-jp/articles/rules/references/samples.md b/ja-jp/articles/rules/references/samples.md
new file mode 100644
index 0000000000..e24de4191a
--- /dev/null
+++ b/ja-jp/articles/rules/references/samples.md
@@ -0,0 +1,154 @@
+---
+title: Rule Examples
+description: A collection of sample Rules.
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType: reference
+useCase: extensibility-rules
+---
+
+# Rule Examples
+
+In this article you'll find a collection of sample Rules. For more examples, see our Github repo at [auth0/rules](https://github.com/auth0/rules).
+
+## Hello World
+
+This Rule will add a `hello` claim (with the value `world`) to the ID Token that will be afterwards sent to the application.
+
+```js
+function (user, context, callback) {
+  context.idToken["http://mynamespace/hello"] = "world";
+  console.log('===> set "hello" for ' + user.name);
+  callback(null, user, context);
+}
+```
+
+Note that the claim is [namespaced](/tokens/guides/create-namespaced-custom-claims): we named it `http://mynamespace/hello` instead of just `hello`. This is what you have to do in order to add arbitrary claims to an ID Token or Access Token.
+
+::: panel Namespace Identifiers
+Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. Exceptions are `webtask.io` and `webtask.run`, which are Auth0 domains and therefore cannot be used. The namespace URL does not have to point to an actual resource; it's only used as an identifier and will not be called by Auth0. For more information, refer to [User profile claims and scope](/api-auth/tutorials/adoption/scope-custom-claims).
+:::
+
+## Add roles to a user
+
+In this example, all authenticated users will get a **guest** role, but `johnfoo@gmail.com` will also be an **admin**:
+
+```js
+function (user, context, callback) {
+  if (user.email === 'johnfoo@gmail.com') {
+    context.idToken["http://mynamespace/roles"] = ['admin', 'guest'];
+  }else{
+    context.idToken["http://mynamespace/roles"] = ['guest'];
+  }
+
+  callback(null, user, context);
+}
+```
+
+At the beginning of the Rules pipeline, John's `context` object will be:
+
+```json
+{
+  "clientID": "YOUR_CLIENT_ID",
+  "clientName": "YOUR_CLIENT_NAME",
+  "clientMetadata": {},
+  "connection": "YOUR_CONNECTION_NAME",
+  "connectionStrategy": "auth0",
+  "protocol": "oidc-implicit-profile",
+  "accessToken": {},
+  "idToken": {},
+  //... other properties ...
+}
+```
+
+After the Rule executes, the `context` object will have the added namespaced claim as part of the ID Token:
+
+```json
+{
+  "clientID": "YOUR_CLIENT_ID",
+  "clientName": "YOUR_CLIENT_NAME",
+  "clientMetadata": {},
+  "connection": "YOUR_CONNECTION_NAME",
+  "connectionStrategy": "auth0",
+  "protocol": "oidc-implicit-profile",
+  "accessToken": {},
+  "idToken": { "http://mynamespace/roles": [ "admin", "guest" ] },
+  //... other properties ...
+}
+```
+
+When your application receives the ID Token, it will verify and decode it in order to access this added custom claim. The payload of the decoded ID Token will be similar to the following sample:
+
+```json
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|USER_ID",
+  "aud": "YOUR_CLIENT_ID",
+  "exp": 1490226805,
+  "iat": 1490190805,
+  "nonce": "...",
+  "at_hash": "...",
+  "http://mynamespace/roles": [
+    "admin",
+    "guest"
+  ]
+}
+```
+
+For more information on the ID Token, refer to [ID Token](/tokens/concepts/id-tokens).
+
+::: note
+Properties added in a Rule are __not persisted__ in the Auth0 user store. Persisting properties requires calling the Auth0 Management API.
+:::
+
+## Deny access based on a condition
+
+In addition to adding claims to the ID Token, you can return an *access denied* error.
+
+```js
+function (user, context, callback) {
+  if (context.clientID === "BANNED_CLIENT_ID") {
+    return callback(new UnauthorizedError('Access to this application has been temporarily revoked'));
+  }
+
+  callback(null, user, context);
+}
+```
+
+This will cause a redirect to your callback URL with an `error` querystring parameter containing the message you set. (such as `https://yourapp.com/callback?error=unauthorized&error_description=Access%20to%20this%20application%20has%20been%20temporarily%20revoked`). Make sure to call the callback with an instance of `UnauthorizedError` (not `Error`).
+
+::: note
+Error reporting to the app depends on the protocol. OpenID Connect (OIDC) apps will receive the error in the querystring. SAML apps will receive the error in a `SAMLResponse`.
+:::
+
+## Copy user metadata to ID Token
+
+This will read the `favorite_color` user metadata, and add it as a namespaced claim at the ID Token.
+
+```js
+function(user, context, callback) {
+
+  // copy user metadata value in ID Token
+  context.idToken['http://fiz/favorite_color'] = user.user_metadata.favorite_color;
+
+  callback(null, user, context);
+}
+```
+
+## Add claims to Access Token
+
+This will add one custom namespaced claim at the Access Token.
+
+```js
+function(user, context, callback) {
+
+  // add custom claims to Access Token
+  context.accessToken['http://foo/bar'] = 'value';
+
+  callback(null, user, context);
+}
+```
+
+After this Rule executes, the Access Token will contain one additional namespaced claim: `http://foo/bar=value`.
\ No newline at end of file
diff --git a/ja-jp/articles/rules/references/use-cases.md b/ja-jp/articles/rules/references/use-cases.md
new file mode 100644
index 0000000000..0db47d8b72
--- /dev/null
+++ b/ja-jp/articles/rules/references/use-cases.md
@@ -0,0 +1,233 @@
+---
+description: Rules use cases for Auth0
+title: Rules Use Cases
+classes: topic-page
+toc: true
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+  - index
+useCase: extensibility-rules
+---
+
+
    
+  
    
+  
    Rules Use Cases
    
+  
    The following is a list of Rules for implementing a variety of functionality in Auth0.
    
+  
    Before proceeding, please review our best practice recommendations for working with Rules. See also our security bulletin regarding vulnerable patterns when working with custom rules code.
    
+
    
+
+
    API Authorization
    
+
+
+
+
    Authorization
    
+
+
+
+
    Compliance
    
+
+
+
+
    Connections
    
+
+
+
+
    Email
    
+
+
+
+
    Extensions
    
+
+
+
+
    Integrations
    
+
+
+
+
    Login
    
+
+
+
+
    Monitoring
    
+
+
+
+
    Monitoring
    
+
+
+
+
    Multi-Factor Authentication
    
+
+
+
+
    SAML
    
+
+
+
+
    Tokens
    
+
+
+
+
    User Management
    
+
+
diff --git a/ja-jp/articles/rules/references/user-object.md b/ja-jp/articles/rules/references/user-object.md
new file mode 100644
index 0000000000..9ceda737ca
--- /dev/null
+++ b/ja-jp/articles/rules/references/user-object.md
@@ -0,0 +1,45 @@
+---
+title: User Object in Rules
+description: Describes the properties of the user object that stores information about the logged in user, returned by the identity provider. 
+topics:
+  - rules
+  - extensibility
+  - identity-providers
+contentType: reference
+useCase: extensibility-rules
+---
+
+# User Object in Rules
+
+The `user` object stores information about the logged-in user, returned by the identity provider. It is generated when a user authenticates and before rules run. Because of the [order of events](/rules#authentication-transaction-flow) when a user authenticates, changes made to a user's profile from within a rule will only be available in the current user object if you also save the changes to the user object from within the same rule.
+
+## Properties
+
+The following properties are available for the `user` object.
+
+| Property | Data Type        | Description |
+|----------|------------------|-------------|
+| `user.app_metadata` | object | Custom fields that store info about a user that influences the user's access, such as support plan, security roles, or access control groups. For more info, see [Metadata](/metadata). |
+| `user.created_at` | date time | Timestamp indicating when the user profile was first created. |
+| `user.email` | text | (unique) The user's email address. |
+| `user.email_verified` | boolean | Indicates whether the user has verified their email address. |
+| `user.family_name` | text | The user's family name. |
+| `user.given_name` | text | The user's given name. |
+| `user.identities` | array (object) |  <%= include('../_includes/_user-prop-identities.md') %> |
+| `user.last_password_reset` | date time | Timestamp indicating the last time the user's password was reset/changed. At user creation, this field does not exist. This property is only available for Database connections. |
+| `user.multifactor` | array (text) | List of multi-factor authentication (MFA) providers with which the user is enrolled. This array is updated when the user logs in with MFA successfully for the first time, and is not updated when enrollment is completed or when an administrator resets a user's MFA. |
+| `user.name` | text | The user's full name. |
+| `user.nickname` | text | The user's nickname. |
+| `user.permissions` | text | The permissions assigned to the user's ID token |
+| `user.phone_number` | text  | The user's phone number. Only valid for users with SMS connections. |
+| `user.phone_verified` | boolean | Indicates whether the user has verified their phone number. Only valid for users with SMS connections. |
+| `user.picture` | text | URL pointing to [the user's profile picture](/user-profile/user-picture). |
+| `user.updated_at` | date time | Timestamp indicating when the user's profile was last updated/modified. Changes to `last_login` are considered updates, so most of the time, `updated_at` will match `last_login`. |
+| `user.user_id` | text | (unique) The user's unique identifier. |
+| `user.user_metadata` | object | Custom fields that store info about a user that does not impact what they can or cannot access, such as work address, home address, or user preferences. For more info, see [Metadata](/metadata). |
+| `user.username` | text | (unique) The user's username. |
+
+## Read more
+
+* [Debug Rules](/rules/guides/debug)
+* [Context Object](/rules/references/context-object)
\ No newline at end of file
diff --git a/ja-jp/articles/scopes/current/api-scopes.md b/ja-jp/articles/scopes/current/api-scopes.md
new file mode 100644
index 0000000000..dae3ed63a1
--- /dev/null
+++ b/ja-jp/articles/scopes/current/api-scopes.md
@@ -0,0 +1,76 @@
+---
+title: API Scopes
+description: Understand the principle of scopes and how it is used with APIs.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+useCase:
+  - development
+  - call-api
+  - secure-api
+---
+# API Scopes
+
+As an [API](/apis) developer, you need to:
+
+1. Decide which information you would like applications to be able to access on a user's behalf.
+2. Define these access levels as custom scopes.
+3. Identify these scopes so that calling applications can use them. 
+
+## Ways to use API scopes
+
+You can use API scopes in different ways:
+
+* In an API where the calling application is a third-party, or external, application. In this case, the calling application will request authorization from the user to access the requested scopes, and the user will approve or deny the request.
+* In an API where the calling application is a first-party application, or application that is registered under the same Auth0 domain as the API it is calling. In this case, by default, user consent is not requested, but you may configure consent to be required.
+* In an API where the calling application is a back-end service, whether third-party or first-party, and no user exists. In this case, user consent is never requested.
+
+::: note
+All of these examples use scopes to limit access through use of a token. If you so choose, your API may also use additional logic beyond the token to enforce more extensive access control.
+:::
+
+For an example showing how to request custom API access for your application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#request-custom-API-access).
+
+### Example: An API called by a third-party application
+
+Let's say you are building an API that provides bank account information to online payment applications. At various times, apps may need to read account balances or transfer funds. To do this, you create two scopes for your API: one that authorizes read access to an account balance (`read:balance`), one that authorizes fund transfers (`transfer:funds`). Your API is registered with Auth0.
+
+A calling application will request authorization from the user to access the requested scopes, and the user will approve or deny the request. The app may request read access to the user's balance by including the `read:balance` scope in its request, access to make fund transfers by including the `transfer:funds` scope in its request, or access to both read the user's balance and transfer funds by including both the `read:balance` and `transfer:funds` scopes in its request. 
+
+Now, when the app calls your API, it will include a token which verifies that the user has provided authorization to access their content and also indicates which scopes the user has approved. Your API should respect the approved scopes and only release information that was authorized by the user to the calling application. 
+
+### Example: An API called by a first-party application
+
+Let's say you are building an API that provides data to an events application, which you have also written. You implement [role-based access control (RBAC)](/authorization/concepts/rbac), creating a role of `organizer` and a role of `participant`. Users with a role of `organizer` need to create and update events, whereas users with a role of `participant` need to view events and register for events. To do this, you create four scopes for your API: one that authorizes create access for events(`create:events`), one that authorizes update access for events (`update:events`), one that authorizes read-only access for events (`view:events`), and one that authorizes registration access for events (`register:events`). Both your API and event application are registered with Auth0, and the **Allow Skipping User Consent** for first-party applications option is enabled for your API. You have installed the Authorization Extension and configured an `organizer` role and created the `create:events` and `update:events` scopes for it, and assigned it to User A. You have also configured a `participant` role and created the `view:events` and `register:events` scopes for it, and assigned it to User B.
+
+User A authenticates with the calling application, which requests the necessary scopes, but because it is a first-party application, user consent will not be requested. The app may request any combination of `create:events`, `update:events`, `view:events`, and `register:events` scopes, but User A is recognized as having the role of `organizer` and therefore is only granted the `create:events` and `update:events` scopes.
+
+Now, when the app calls your API, it will include a token which verifies that it has authorization for only the scopes associated with the role of the authenticated user.
+
+### Example: An API called by a back-end service
+
+Let's say you work for a hospital and have an API that produces large amounts of imaging data whenever a patient gets an MRI. You store the imaging data locally for six months, but the hospital needs the images to be stored long-term for the purpose of regulatory compliance. Because of this, the hospital has a service that copies imaging data to an offsite cold storage solution on a nightly basis and deletes all local medical data after six months of storage.
+
+To do this, you create two scopes for your API: one that authorizes read access to your imaging data (`read:images`) and one that authorizes delete access to your imaging data (`delete:images`). Your API and automated service are registered with Auth0, and you have authorized the automated service to request tokens for your API.
+
+The calling automated service will request the necessary scopes, but because there is no user, consent will not be requested. The service may request read access to your imaging data by including the `read:images` scope in its request, delete access by including the `delete:images` scope in its request, or both read and delete access by including the `read:images` and `delete:images` scopes in its request.
+
+Now, when the automated service calls your API, it will include a token which verifies that it has authorization for the requested scopes.
+
+## Limit API scopes
+
+An application can include any scope defined for an API in its request. Instead of allowing all available scopes to be requested, however, you can limit scopes for certain users. For example, a user of your application can be given a role so that requests on their behalf are limited to just the scopes assigned to that role. To do this, you can use the [Authorization Extension](/extensions/authorization-extension) and a custom [Rule](/rules).
+
+We discuss this approach in more depth in our [SPA+API Architecture Scenario](/architecture-scenarios/spa-api). Specifically, you can review the [Configure the Authorization Extension](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension) section to learn how to configure the Authorization Extension and create a custom Rule that will ensure scopes are granted based on a user's role.
+
+
+## Keep reading
+
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Add API Permissions (Scopes)](/dashboard/guides/apis/add-permissions-apis)
+- [How to Customize the Consent Prompt](/scopes/current/guides/customize-consent-prompt)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
diff --git a/ja-jp/articles/scopes/current/guides/customize-consent-prompt.md b/ja-jp/articles/scopes/current/guides/customize-consent-prompt.md
new file mode 100644
index 0000000000..437fdd21df
--- /dev/null
+++ b/ja-jp/articles/scopes/current/guides/customize-consent-prompt.md
@@ -0,0 +1,77 @@
+---
+title: Customize the Consent Prompt
+description: Learn how to customize the consent prompt presented to users during authorization.
+topics:
+  - scopes
+  - permissions
+  - authorization
+  - consent-prompt
+  - mgmt-api
+contentType:
+  - how-to
+useCase:
+  - development
+  - secure-api
+---
+# Customize the Consent Prompt
+
+When a third-party application requests scopes, users see a consent prompt. By default, this prompt uses the scope **name** to generate text and groups all scopes for a resource, displaying the resource's actions in a single line.
+
+<%= include('../../../_includes/_parental-consent') %>
+
+For example, let's say you have an Auth0-registered API with the following defined scopes:
+
+* `read:messages`: Be able to read your email messages
+* `write:messages`: Write messages
+
+The consent prompt will display: **Messages: read and write your messages**.
+
+Instead, you can use your defined scope **description** to generate this text. In this case, the consent dialog would display: **Be able to read your email messages**, **Write messages**.
+
+::: warning
+This change is made at the tenant level, so it will affect consent prompts for all APIs on the tenant.
+:::
+
+## Use scope descriptions to generate consent prompt text
+
+Set your tenant's **use_scope_descriptions_for_consent** flag to `true` by making the following API call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": true } }"
+  }
+}
+```
+
+## Use scope names to generate consent prompt text
+
+Set your tenant's **use_scope_descriptions_for_consent** flag to `false` by making the following API call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"flags\": { \"use_scope_descriptions_for_consent\": false } }"
+  }
+}
+```
+
+## Keep reading
+
+- [How to Define Scopes for an API Using the Auth0 Dashboard](/scopes/current/guides/define-api-scopes-dashboard)
diff --git a/ja-jp/articles/scopes/current/index.md b/ja-jp/articles/scopes/current/index.md
new file mode 100644
index 0000000000..e510f4a386
--- /dev/null
+++ b/ja-jp/articles/scopes/current/index.md
@@ -0,0 +1,62 @@
+---
+url: /scopes/current
+section: articles
+classes: topic-page
+title: Scopes
+description: Understand the principle of scopes and explore general examples of their use.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+  - index
+useCase:
+  - development
+  - add-login
+  - secure-api
+  - call-api
+---
+# Scopes
+
+Different pieces of user information are often stored across a number of online resources. Users may upload and store photos with a service like Flickr, keep digital files on Dropbox, and store contacts and events in Google Calendar or on Facebook.
+
+Often, new applications will want to make use of the information that has already been created in an online resource. To do so, the application must ask for authorization to access this information on a user's behalf. _Scopes_ define the specific actions applications can be allowed to do on a user's behalf.
+
+## Ways to use scopes
+
+When an app requests permission to access a resource through an authorization server, it uses the `scope` parameter to specify what access it needs, and the authorization server uses the `scope` parameter to respond with the access that was actually granted (if the granted access was different from what was requested).
+
+Generally, you use scopes in three ways:
+
+* From an [application](/applications), to verify the identity of a user and get basic profile information about the user, such as their email or picture. In this scenario, the scopes available to you include those implemented by the OpenID Connect (OIDC) protocol. For details, see [OpenID Connect Scopes](/scopes/current/oidc-scopes).
+
+* In an [API](/apis), to implement access control. In this case, you need to define custom scopes for your API and then identify these scopes so that calling applications can use them. For details, see [API Scopes](/scopes/current/api-scopes).
+
+* From an application, to call an API that has implemented its own custom scopes. In this case, you need to know which custom scopes are defined for the API you are calling. For an example of calling a custom API from an application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#request-custom-API-access)
+
+## Best practices
+
+Understand your use case and choose the most restrictive scopes possible. 
+
+If you are requesting scopes, make sure you ask for enough access for your application to function, but only request what you absolutely need. Are you establishing a user's identity or asking the user to allow you to interact with their data? There's a big difference between importing a user's Facebook profile information and posting to their wall. By only requesting what you need, you are more likely to gain user consent when required since users are more likely to grant access for limited, clearly-specified scopes. 
+
+Similarly, when creating custom scopes for an API, consider what levels of granular access applications may need and design accordingly.
+
+## Requested scopes versus granted scopes
+
+In certain cases, users get to consent to the access being requested. While usually the scopes returned will be identical to those requested, users can edit granted scopes (both during initial consent and sometimes after, depending on the resource), thereby granting an app less access than it requested. 
+
+As an application developer, you should be aware of this possibility and handle these cases in your app. For example, your app could warn the user that they will see reduced functionality. It could also send the user back through the authorization flow to ask for additional permissions. But again, remember that when asked for consent, users can always say no.
+
+::: note
+By default, Auth0 skips user consent for first-party applications, which are applications that are registered under the same Auth0 domain as the API they are calling; however, you can configure your API in Auth0 to require user consent from first-party applications. Third-party applications, which are external applications, require user consent.
+:::
+
+## Keep reading
+
+- [OpenID Connect Scopes](/scopes/current/oidc-scopes)
+- [API Scopes](/scopes/current/api-scopes)
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
diff --git a/ja-jp/articles/scopes/current/oidc-scopes.md b/ja-jp/articles/scopes/current/oidc-scopes.md
new file mode 100644
index 0000000000..58c9fbe902
--- /dev/null
+++ b/ja-jp/articles/scopes/current/oidc-scopes.md
@@ -0,0 +1,59 @@
+---
+title: OpenID Connect Scopes
+description: Understand scopes and claims used with the OpenID Connect (OIDC) protocol.
+topics:
+  - scopes
+  - permissions
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+---
+# OpenID Connect Scopes
+
+:::note 
+This document discusses scopes included within the OpenID Connect (OIDC) authentication protocol. For more info about OIDC itself, see our docs on [OpenID Connect](/protocols/oidc).
+:::
+
+OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to a user's details, like name and picture. Each scope returns a set of user attributes, which are called _claims_. The scopes an application should request depend on which user attributes the application needs. Once the user authorizes the requested scopes, the claims are returned in an ID Token and are also available through the [/userinfo endpoint](/api/authentication#get-user-info).
+
+For example, let's say you have built a regular web application, registered it with Auth0, and have configured it to allow a user to log in using a username and password. Once a user logs in to your app, you want to auto-generate and send a personalized welcome email, including the user's name.
+
+1. A user clicks **Login** within your app.
+2. Your app redirects the user to the Auth0 Authorization Server (**/authorize** endpoint), including the following scopes: 
+* `openid` (required; to indicate that the application intends to use OIDC to verify the user's identity)
+* `profile` (so you can personalize the email with the user's name)
+* `email` (so you know where to send the welcome email)
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user authenticates and sees a consent page listing the scopes Auth0 will give to your app, which include access to their profile information and email address.
+5. The user accepts and authorizes your app to have this level of access to their information stored by Auth0.
+6. Your app now has access to the user's profile information and email address.
+
+## Standard claims
+
+Standard claims are intended to provide an application with user details, such as name, email, and picture, and are pre-defined for the OIDC protocol. These claims are returned in an ID Token and are also available through the [/userinfo endpoint](/api/authentication#get-user-info).
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a rule. 
+:::
+
+The basic (and required) scope for OIDC is `openid`, which indicates that an application intends to use the OIDC protocol to verify a user's identity. Beyond that, an application can ask for additional scopes by listing the requested scope names in the `scope` parameter, separated by spaces. 
+
+Standard claims included in the most commonly-used scopes are listed below, but for a full list of available standard claims, refer to the [OIDC specification: Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). For a full list of Scopes, see [OIDC specification: Requesting Claims Using Scope Values](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims).
+
+
+| Scope     | Claims          |
+|-----------|-----------------|
+| `openid`  | (required) Returns the `sub` claim, which uniquely identifies the user. In an ID Token, `iss`, `aud`, `exp`, `iat`, and `at_hash` claims will also be present. For more information about the ID Token claims, see [ID Tokens](/tokens/concepts/id-tokens#id-token-payload). |
+| `profile` | Returns claims that represent basic profile information, including `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `picture`, and `updated_at`. |
+| `email`   | Returns the `email` claim, which contains the user's email address, and `email_verified`, which is a boolean indicating whether the email address was verified by the user. |
+
+For an example showing how to request standard claims for your application, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#authenticate-a-user-and-request-standard-claims).
+
+## Keep reading
+
+- [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
+- [Scopes](/scopes)
+- [Custom Claims](/tokens/concepts/jwt-claims#custom-claims)
+- [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
diff --git a/ja-jp/articles/scopes/current/sample-use-cases.md b/ja-jp/articles/scopes/current/sample-use-cases.md
new file mode 100644
index 0000000000..fe4ea0d57c
--- /dev/null
+++ b/ja-jp/articles/scopes/current/sample-use-cases.md
@@ -0,0 +1,233 @@
+---
+title: Sample Use Cases - Scopes and Claims
+description: Learn how to use scopes and claims with applications and APIs.
+topics:
+  - scopes
+contentType:
+  - how-to
+useCase:
+  - development
+  - add-login
+  - call-api
+  - secure-api
+---
+# Sample Use Cases: Scopes and Claims
+
+In these examples, we use the [Authorization Code Flow](/flows/concepts/auth-code) to authenticate a user and request the necessary permissions (scopes) and tokens. For details on the request parameters or to learn how to fully implement this flow, refer to our tutorial: [Add Login to Regular Web Applications](/flows/guides/auth-code/add-login-auth-code).
+
+## Authenticate a user and request standard claims
+
+In this example, we want to authenticate a user and get user details that will allow us to personalize our UI. To do this, we want to get an ID Token that contains the user's name, nickname, profile picture, and email information.
+
+1. Initiate the authentication flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}&
+  scope=openid%20profile%20email&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example: 
+
+* the `response_type` parameter includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the ID Token we need for authentication.)
+* the `scope` parameter includes three values, the requested OIDC scopes: 
+  * `openid` (to indicate that the application intends to use OIDC to verify the user's identity)
+  * `profile` (to get `name`, `nickname`, and `picture`)
+  * `email` (to get `email` and `email_verified`)
+
+2. After the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the ID Token from the response and [decode it](/tokens/id-tokens#id-token-payload).
+
+You should see the following claims:
+
+```json
+{
+  "name": "John Doe",
+  "nickname": "john.doe",
+  "picture": "https://myawesomeavatar.com/avatar.png",
+  "updated_at": "2017-03-30T15:13:40.474Z",
+  "email": "john.doe@test.com",
+  "email_verified": false,
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|USER-ID",
+  "aud": "${account.clientId}",
+  "exp": 1490922820,
+  "iat": 1490886820,
+  "nonce": "crypto-value",
+  "at_hash": "IoS3ZGppJKUn3Bta_LgE2A"
+}
+```
+
+Your app now can retrieve the user attributes and use them to personalize your UI.
+
+
+## Request custom API access
+
+In this example, we request a custom scope for a calendar API that will authorize the calling application to read appointments for the user. To do this, we want to get an Access Token containing the proper scope to read appointments from the API. Note that requesting an Access Token is not dependent on requesting an ID Token.
+
+::: note
+Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and [define the scopes for your API using the Auth0 Dashboard](/scopes/current/guides/define-api-scope-dashboard). You can also use defined permissions to [customize the consent prompt](/scopes/current/guides/customize-consent-prompt) for your users.
+:::
+
+1. Initiate the authorization flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}& 
+  scope=read:appointments&
+  audience=YOUR_API_AUDIENCE&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example:
+
+* the `response_type` parameter still includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the Access Token that we can use to call our API.)
+* the `scope` parameter includes one value, the requested API scope: 
+  * `read:appointments` (to allow us to read the user's appointments from the API)
+* the `audience` parameter is new and includes one value:
+  * the unique identifier of the API from which we want to read the user's appointments
+
+2. As in the previous example, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the Access Token from the response, and call the API using the Access Token as credentials.
+
+
+## Authenticate a user and request standard claims and custom API access
+
+In this example, we combine our previous two examples to authenticate a user, request standard claims, and also request a custom scope for a calendar API that will allow the calling application to read appointments for the user. To do this, we want to get two tokens--an ID Token that contains the user's name, nickname, profile picture, and email information, and an Access Token containing the proper scope to read appointments from the API. Note that requesting an Access Token is not dependent on requesting an ID Token.
+
+::: note
+Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and [define the scopes for your API using the Auth0 Dashboard](/scopes/current/guides/define-api-scope-dashboard). You can also use defined permissions to [customize the consent prompt](/scopes/current/guides/customize-consent-prompt) for your users.
+:::
+
+1. Initiate the authentication flow by sending the user to the authorization URL:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code&
+  client_id=${account.clientId}&
+  redirect_uri=${account.callback}& 
+  scope=openid%20profile%20email%20read:appointments&
+  audience=YOUR_API_AUDIENCE&
+  state=YOUR_STATE_VALUE
+```
+
+Notice that in this example:
+
+* the `response_type` parameter still includes one value:
+  * `code` (because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive both the ID Token we need for authentication and the Access Token that we can use to call our API.)
+* the `scope` parameter is used for both OIDC scopes and API scopes, so now includes four values: 
+  * `openid` (to indicate that the application intends to use OIDC to verify the user's identity)
+  * `profile` (to get `name`, `nickname`, and `picture`)
+  * `email` (to get `email` and `email_verified`)
+  * `read:appointments` (to allow us to read the user's appointments from the API)
+* the `audience` parameter includes one value:
+  * the unique identifier of the API from which we want to read the user's appointments
+
+2. As in the previous examples, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (For details, refer to [Add Login to Regular Web Applications: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens).)
+
+3. Extract the ID Token from the response, [decode it](/tokens/id-tokens#id-token-payload), and retrieve the user attributes and use them to personalize your UI.
+
+4. Extract the Access Token from the response, and call the API using the Access Token as credentials.
+
+
+## Add custom claims to a token
+
+In this example, we add a user's favorite color and preferred contact method to the ID Token. To do this, we create a [rule](/rules) to customize the token by adding these claims using a [namespaced format](/tokens/guides/create-namespaced-custom-claims). Once added, we will also be able to obtain the custom claims when calling the `/userinfo` endpoint (though the rule will run only during the authentication process).
+
+<%= include('../../_includes/_enforce-claim-namespacing') %>
+
+Suppose that:
+
+* The user logged in using an identity provider that returned a `favorite_color` claim as part of their user profile.
+* At some point, the user selected a `preferred_contact` method of `email`, and we saved it as part of the [user's `user_metadata`](/users/concepts/overview-user-metadata).
+* We've used the Auth0 Management API to set application-specific information for this user.
+
+In this case, the Auth0-stored [normalized user profile](/users/normalized) is:
+
+```json
+{
+  "email": "jane@example.com",
+  "email_verified": true,
+  "user_id": "custom|123",
+  "favorite_color": "blue",
+  "user_metadata": {
+    "preferred_contact": "email"
+  }
+}
+```
+
+For this profile, Auth0 would normally return the following ID Token claims to your application:
+
+```json
+{
+  "email": "jane@example.com",
+  "email_verified": true,
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "custom|123",
+  "aud": "my_client_id",
+  "iat": 1311280970,
+  "exp": 1311281970
+}
+```
+
+Notice that in this example:
+
+ * the `sub` claim contains the value of the `user_id` property
+ * neither the `favorite_color` nor `user_metadata` properties are present because OpenID Connect (OIDC) does not define standard claims that represent `favorite_color` or `user_metadata`
+ 
+To receive the custom data, create a rule to customize the token with [namespaced](/tokens/guides/create-namespaced-custom-claims) [custom claims](/tokens/concepts/jwt-claims#custom-claims) that represent these properties from the user profile. Custom data will be available in the token after all rules have run.
+
+```js
+function(user, context, callback) {
+  const namespace = 'https://myapp.example.com/';
+  context.idToken[namespace + 'favorite_color'] = user.favorite_color;
+  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
+  callback(null, user, context);
+}
+```
+
+::: note
+This example shows custom claims being added to an ID Token, which uses the `context.idToken` property. To add to an Access Token, use the `context.accessToken` property instead. To learn more, see [Context Object in Rules](/rules/references/context-object).
+:::
+
+::: warning
+When creating your rule, make sure to set some logic that determines when to include additional claims. Injecting custom claims into every ID Token that is issued is not ideal.
+:::
+
+With this rule enabled, Auth0 will include the `favorite_color` and `preferred_contact` custom claims in the ID Token:
+
+```json
+{
+  "https://myapp.example.com/favorite_color": "blue",
+  "https://myapp.example.com/preferred_contact": "email",
+  "email": "jane@example.com",
+  "email_verified": true,
+  "iss": "https://my-domain.auth0.com/",
+  "sub": "custom|123",
+  "aud": "my_client_id",
+  "iat": 1311280970,
+  "exp": 1311281970
+}
+```
+
+## Keep reading
+
+- [Scopes](/scopes)
+- [OpenID Connect (OIDC) Scopes](/scopes/current/oidc-scopes)
+- [Custom Claims](/tokens/concepts/jwt-claims#custom-claims)
+- [API Scopes](/scopes/current/api-scopes)
+- [Add API Permissions (Scopes)](/dashboard/guides/apis/add-permissions-apis)
+- [Customize the Consent Prompt](/scopes/current/guides/customize-consent-prompt)
+- [Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis)
+- [Restrict Access to APIs](/api-auth/restrict-access-api)
+- [SPA + API Architecture Scenario: Restrict API Scopes Based on Authorization Extension Groups](/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)
+
diff --git a/ja-jp/articles/scopes/index.yml b/ja-jp/articles/scopes/index.yml
new file mode 100644
index 0000000000..effcc8c22d
--- /dev/null
+++ b/ja-jp/articles/scopes/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: scopes
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/ja-jp/articles/scopes/legacy/index.md b/ja-jp/articles/scopes/legacy/index.md
new file mode 100644
index 0000000000..7fceba1b84
--- /dev/null
+++ b/ja-jp/articles/scopes/legacy/index.md
@@ -0,0 +1,79 @@
+---
+description: Overview of scopes with a client-side authorization transaction.
+topics:
+  - scopes
+contentType:
+  - reference
+  - concept
+  - index
+useCase:
+  - development
+---
+
+# Scopes
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline and the way scopes should be used. We recommend you use the latest version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+When initiating a client-side authorization transaction through the [`/authorize` endpoint](/api/authentication/reference#social), only an opaque Access Token will be returned by default. To also return a JWT that authenticates the user and contains their profile information, the `scope` parameter can be sent as part of the request.
+
+## Example (implicit flow)
+
+The following URL logs a user in using Google and requests a JWT that authenticates the user.
+
+```html
+
    +https://example.auth0.com/authorize
+  ?response_type=token
+  &client_id=${account.clientId}
+  &redirect_uri=http://jwt.io&connection=google-oauth2
+  &scope=openid
+
    
+```
+
+After a successful transaction, the user would be redirected here:
+
+```html
+
+
    +http://jwt.io/
+  #access_token=s213Mvz1QW7XpjoX
+  &id_token=eyJ0...
+  &token_type=Bearer
+  &state=mep7BLYt1lAsLC94
+
    
+    
+```
+
+When decoded, this token contains the following claims:
+
+```json
+{
+  "iss": "https://example.auth0.com/",
+  "sub": "google-oauth2|112396309096036300109",
+  "aud": "jGMow0KO3WDJELW8XIxolqb1XIitjkYL",
+  "exp": 1437560381,
+  "iat": 1437510381
+}
+```
+
+## Requesting specific claims
+
+The attributes included in the issued token can be controlled with the `scope` parameter as follows:
+
+* `scope=openid`: will only return `iss`, `sub`, `aud`, `exp` and `iat` claims.
+* `scope=openid email nickname favorite_food`: will return claims for `openid` in addition to the `email`, `nickname` and `favorite_food` fields if they are available.
+* `scope=openid profile`: will return all the user attributes in the token. Beware when you use this option because if you have too many user attributes the ID Token will increase in size and might break the URL limits for some browsers.
+
+::: note
+The `scope` parameter can be used in the same way when calling the [Resource Owner endpoint](/api/authentication/reference#resource-owner).
+:::
+
+## Keep reading
+
+::: next-steps
+* [Sending a `scope` parameter with Lock](/libraries/lock/sending-authentication-parameters#scope-string-)
+* [Retrieving the full user profile with an Access Token](/api/authentication/reference#get-user-info)
+* [Validating a JWT and obtaining the full user profile](/api/authentication/reference#get-token-info)
+:::
diff --git a/ja-jp/articles/security/blacklisting-attributes.md b/ja-jp/articles/security/blacklisting-attributes.md
new file mode 100644
index 0000000000..32b85c318a
--- /dev/null
+++ b/ja-jp/articles/security/blacklisting-attributes.md
@@ -0,0 +1,78 @@
+---
+description: How to blacklist user attributes that you do not want to save in Auth0 databases
+toc: true
+crews: crew-2
+topics:
+  - security
+  - security-bulletins
+  - blacklisting
+  - users
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Blacklist User Attributes
+
+If there are user fields that should not be stored in Auth0 databases due to privacy reasons, you can blacklist them.
+
+## Use the Management API
+
+To blacklist attributes make a `PATCH` call to the [Update Connection](/api/management/v2#!/Connections/patch_connections_by_id) endpoint of the Management API.
+
+### Step 1. Get a token
+
+First, you need a valid Access Token to access that endpoint. The token must include the `update:connections` scope. 
+
+For detailed steps on how to get one, see [Access Tokens for the Management API](/api/management/v2/tokens).
+
+### Step 2. Call the API
+
+Once you have the token (and the list of attributes to be blacklisted), you are ready to call the API. 
+
+Here is a sample HTTP request that blacklists two attributes: `ethnicity` and `gender`.
+
+
+```js
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_TOKEN" }
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+  "queryString" : [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"options\": {\"non_persistent_attrs\": [\"ethnicity\", \"gender\"]}}"
+  },
+  "headersSize" : -1,
+  "bodySize" : -1,
+  "comment" : ""
+}
+```
+
+Where:
+
+- `YOUR_CONNECTION_ID` is the Id of the connection for which these attributes will be blacklisted
+- `YOUR_TOKEN` is the Access Token you got in the previous step
+- The `options.non_persistent_attrs` object holds an array of the attributes that will be blacklisted
+
+## Limitations
+
+- Only [root fields](/users/references/user-profile-structure#attributes) (such as `user.email` or `user.phone_number`) can be blacklisted
+  - If `user.name` or `user.nickname` are blacklisted they will not be included in tokens.
+  - If `user.email` is blacklisted the value cannot be mapped to a custom claim. For example, in a rule, `context.idToken[namespace + 'work_email'] = user.email` would not work.
+- When you blacklist attributes, they will be still be available via rules and outgoing tokens. However, if any of the following apply, the blacklist attributes will **not** be included in tokens:
+  - You have enabled multi-factor authentication (MFA)
+  - You have performed a redirect via rules
+  - Your app is using delegation (and you haven't set `scope = passthrough`)
+  - Your app is using impersonation
+  - You have enabled the **Use Auth0 instead of the IdP to do Single Sign-On** setting (legacy tenants only)
+- For SAMLP connections, if you enable Debug mode, your logs will contain information on the blacklisted attributes
+
+:::panel Working around the limitations
+If any of these limitations are unacceptable, you can write a [rule](/rules) to encrypt the data and have the data persist to the `user.app_metadata` object.
+:::
diff --git a/ja-jp/articles/security/bulletins/2019-01-10_rules.md b/ja-jp/articles/security/bulletins/2019-01-10_rules.md
new file mode 100644
index 0000000000..27fa3bdea6
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/2019-01-10_rules.md
@@ -0,0 +1,313 @@
+---
+title: Auth0 Security Bulletin for Vulnerable Patterns in Custom Rule Code
+description: Cases where improper custom rule code may create vulnerabilities in the authentication flow.
+topics:
+  - security
+  - security-bulletins
+  - rules
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Auth0 Security Bulletin for Rules
+
+**Published**: January 10, 2019
+
+## Overview
+
+This security bulletin covers several scenarios that customers should avoid in custom rule code, as they may create vulnerabilities in the authentication flow. A description of each issue and, where possible, an alternative way to write the same rule, is provided below.
+
+- Custom rule code containing conditional logic to enforce multi-factor authentication (MFA) may introduce the ability to bypass MFA altogether, especially when using silent authentication.
+- Custom rule code implementing authorization controls based on a specific substring without appropriate logic may result in elevated privileges.
+- Custom rule code sending diagnostic information to third party services, rather than using Auth0's built-in debugging features, may result in sensitive information disclosure.
+- Custom rule code triggering paid services may introduce the ability for an adversary to incur unwanted billing charges.
+- Custom rule code granting authorization based on unverified email addresses may allow adversaries to acquire those privileges through a secondary connection type.
+- Custom rule code containing hardcoded secrets, such as API keys, rather than using the global configuration object, increases the risk of exposing such secrets.
+
+## Table of Contents
+
+-   [Improper MFA rules](#improper-mfa-rules)
+    -   [Silent authentication](#silent-authentication)
+    -   [Silent authentication with redirection to custom MFA provider](#silent-authentication-with-redirection-to-custom-mfa-provider)
+    -   [Improper verification](#improper-verification)
+-   [Improper substring verification](#improper-substring-verification)
+-   [Debugging using external services](#debugging-using-external-services)
+-   [Rules using a paid service](#rules-using-a-paid-service)
+-   [Authorization based on unverified email address](#authorization-based-on-unverified-email-address)
+-   [Plaintext secrets within rule code](#plaintext-secrets-within-rule-code)
+
+## Improper MFA rules
+
+### Silent authentication
+Within a single-page application (SPA) using the implicit flow, silent authentication enables new access tokens to be issued without user interaction as long as the current session is valid against the authorization server.
+
+Auth0 offers silent authentication through a special parameter which is added to the authorization endpoint as follows:
+`/authorize?prompt=none`
+
+If MFA is added to the silent authentication process, however, then user interaction becomes necessary.
+
+Conditional logic based on silent authentication to bypass MFA should not be used as a workaround. Rules such as this allow complete MFA bypass and should not be utilized:
+
+```
+function (user, context, callback) {
+  if (context.request.query && context.request.query.prompt === 'none') {
+  // skip MFA for silent token requests
+  return callback(null, user, context);
+  }
+...
+}
+```
+
+### Silent authentication with redirection to custom MFA provider
+Rules that determine whether to redirect to custom multi-factor authentication based on silent authentication may allow MFA bypass in some unusual circumstances. For example, avoid the following:
+```
+function (user, context, callback) {
+  if (context.request.query && context.request.query.prompt === 'none') {
+  //redirect to custom MFA
+  context.redirect = {
+    url: "https://example.com/"
+  };
+...
+}
+```
+
+### Improper verification
+Utilizing rules to bypass multi-factor authentication given specific conditions may bypass MFA when the checks in place are inadequate for determining the veracity of a desired state.
+
+In these cases, the root of the issue is that rules can never determine whether MFA was successfully executed, as MFA happens after rule execution. Rules configured in this manner (see examples below) prematurely update the user record under the incorrect assumption that MFA will be successfully executed while relying on the same user record to skip MFA under given conditions.
+
+The examples below illustrate improper verification checks which can result in full multi-factor authentication bypass.
+
+#### Device fingerprint
+
+```
+function (user, context, callback) {
+
+  var crypto = require('crypto');
+
+  var deviceFingerPrint = getDeviceFingerPrint();
+  user.app_metadata = user.app_metadata || {};
+
+  // Inadequate verification check
+  if (user.app_metadata.lastLoginDeviceFingerPrint !== deviceFingerPrint) {
+    user.app_metadata.lastLoginDeviceFingerPrint = deviceFingerPrint;
+    context.multi-factor = {
+      ...
+    };
+    ...
+  }
+  function getDeviceFingerPrint() {
+    var shasum = crypto.createHash('sha1');
+    shasum.update(context.request.userAgent);
+    shasum.update(context.request.ip);
+    return shasum.digest('hex');
+  }
+}
+```
+
+#### Country code
+
+```
+function (user, context, callback) {
+  user.app_metadata = user.app_metadata || {};
+
+  // Inadequate verification check
+  if (user.app_metadata.last_location !== context.request.geoip.country_code) {
+    user.app_metadata.last_location = context.request.geoip.country_code;
+    context.multi-factor = {
+    ...
+    };
+  }
+```
+
+### Am I affected?
+If you utilize any of the previously illustrated rule logic, an adversary who has successfully logged in with the first authentication factor may be able to bypass MFA on your application.
+
+### Mitigation steps
+**If you are affected by the silent authentication scenario**, remove the conditional logic based on `prompt === 'none'`. This will trigger multi-factor authentication on each silent authentication call to check session status.
+
+**If you are affected by the silent authentication with redirection scenario**, remove the conditional logic based on `prompt === 'none'` and switch to an Auth0-supported multi-factor authentication provider.
+
+To avoid prompting the user for MFA too often, you can set the parameter `allowRememberBrowser` to true, which will enable end-users to check a box so they will only be prompted for multi-factor authentication every 30 days. For example:
+
+```
+  context.multi-factor = {
+    provider: 'guardian',
+    allowRememberBrowser: true
+  };
+```
+
+You may want to notify your end users about checking the box to avoid being prompted too frequently.
+
+**If you are affected by rules utilizing improper verification for skipping MFA**, ensure to use sound verification checks, discontinue MFA exceptions entirely, or use the `allowRememberBrowser` configuration option described above.
+
+### Will this update impact my users?
+Depending on how you adjust your rules or configuration, this update may impact your users by prompting them for MFA more than usual.
+
+## Improper substring verification
+If you have rule logic that requires access control based on an exact match of a particular string, such as an email domain, but you are only checking for a substring instead of an exact string match, your logic may not function as you intend. For example:
+
+```
+  if( _.findIndex(connection.options.domain_aliases,function(d){
+    return user.email.indexOf(d) >= 0;
+```
+
+The above logic would return true given emails such as these:
+- `user.domain.com@not-domain.com`
+- `"user@domain.com"@not-domain.com` (quotes included)
+
+### Am I affected?
+Only customers using conditional logic in rules as described above, are affected.
+
+### Mitigation steps
+Utilize logic such as:
+
+```
+  const emailSplit = user.email.split('@');
+  const userEmailDomain = emailSplit[emailSplit.length - 1].toLowerCase();
+```
+
+Please refer to the following rule template for more information:
+https://github.com/auth0/rules/blob/master/src/rules/check-domains-against-connection-aliases.js
+
+Alternatively, in the _Rules_ section of the Auth0 dashboard, view the rule template named "Check if user email domain matches configured domain".
+
+### Will this update impact my users?
+Possibly. The recommended change to rules with logic based on substring checks may impact end users, though you will be the best judge of the intent of your rules and whether any recommended changes are likely to impact your end users.
+
+## Debugging using external services
+If you have rule logic that sends the Auth0 context object to an external service, you are exposing items such as `id_token` or `access_token` associated with the request. For example:
+
+```
+  request.post({
+    url: 'http://requestbin.fullcontact.com/YourBinUrl',
+    json: {
+      user: user,
+      context: context,
+    },
+    timeout: 15000
+  }, function(err, response, body){
+    if (err) return callback(err);
+    return callback(null, user, context);
+  });
+```
+
+### Am I affected?
+Only customers with rule logic as described above are affected.
+
+### Mitigation steps
+You should modify your rule so it no longer sends the entire context object to _requestbin_, as this may expose any `id_token` or `access_token` associated with each request. Instead, you should send a subset of attributes from the context object that are less sensitive.
+The variables contained in the context object are detailed here: https://auth0.com/docs/rules/current/context
+
+Please refer to the following rule template for more information:
+https://github.com/auth0/rules/blob/master/src/rules/requestbin.js
+
+Alternatively, in the _Rules_ section of the Auth0 dashboard, view the rule template named "Dump rule variables to RequestBin".
+
+Auth0 also offers built-in methods for debugging rules without sending information to external services. Visit https://auth0.com/docs/rules/guides/debug for details.
+
+### Will this update impact my users?
+No. The impacted rule was typically used for debugging purposes. Modification should not impact end users.
+
+## Rules using a paid service
+If you have rule logic that involves a paid service, such as sending SMS messages via _Twilio_, as part of the authentication process, you may be vulnerable to increased costs because an adversary with a valid username and password may be able to trigger a call to the service and incur costs without having to complete the entire authentication process specified by rules. For example:
+
+```
+  //Sends user SMS via Twilio
+  function notifyUser(done) {
+    const request = require('request');
+    const twilioAccount = 'YOUR_TWILIO_ACCOUNT';
+    const twilioAuthToken = 'YOUR_TWILIO_AUTH_TOKEN';
+
+    request.post({
+      url: 'https://api.twilio.com/2010-04-01/Accounts/' + twilioAccount + '/Messages.json',
+      auth: {
+        'user': twilioAccount,
+        'pass': twilioAuthToken,
+      },
+      form: {
+        body: 'You\'ve logged in from a different device or location.',
+        to: user.phone,
+        from: '+18668888888'
+      }
+    }, function (error, response, body) {
+      if (error) return done(error);
+      if (response.statusCode !== 201) return done(new Error(response.statusCode));
+      return done(null);
+    });
+  }
+```
+
+### Am I affected?
+Only customers with rule logic as described above, and whose rule logic can be triggered by any untrusted user, are affected.
+
+### Mitigation steps
+To mitigate this risk, consider one or more of the following actions:
+
+- Disallow public sign-ups, if not needed, to reduce the numbers of users who can sign up and trigger calls to paid services.
+- Mitigate the risk of credential theft to avoid account takeover by hackers who might use hijacked accounts to trigger calls to paid services.
+- Ensure your users have strong passwords when using Database connections.
+- Ensure your users utilize multi-factor authentication.
+- Ensure that the rule only gets triggered for an authorized subset of users, or under other appropriate conditions. For example, you may wish to add logic that checks if a user has a particular email domain, role/group, or subscription level before triggering the call to the paid service.
+
+### Will this update impact my users?
+The impact to end users depends on which of the options described above you choose to mitigate the issue.
+
+## Authorization based on unverified email address
+If you have rule logic that requires access control based on a particular email or email domain, but you are failing to check whether that user has verified their email, an adversary could potentially gain additional privileges by using a second connection type. For example:
+
+```
+  var userHasAccess = allowList.some(function (email) {
+    return email === user.email;
+  });
+```
+
+The above logic would return **true** if an adversary could create an account using a different connection type (such as _social_) with an email address present in the allow-list. This happens because the same email can exist in different connection types.
+
+### Am I affected?
+Only customers using conditional logic in rules as described above, and allowing for multiple connection types, are affected.
+
+### Mitigation steps
+Whenever granting authorization based on email addresses, always start the rule with the following logic:
+
+```
+function (user, context, callback) {
+  // Access should only be granted to verified users.
+  if (!user.email || !user.email_verified) {
+    return callback(new UnauthorizedError('Access denied.'));
+  }
+```
+
+::: warning
+Sometimes even a verified email may not be an adequate check for the authorization you want to perform. To find out more about such cases, please read about the [Email Verified Usage](/users/guides/email-verified)
+:::
+
+### Will this update impact my users?
+This will only affect existing users if they have not verified their email addresses.
+
+## Plaintext secrets within rule code
+If you specify sensitive information, such as API keys, within rule code, you should configure those values in rule settings instead. For example:
+
+```
+  const myApiKey = 'abcdefghijklmnopqrstuvwxyz';
+```
+
+Such sensitive values, being present in the rule code, will remain unencrypted in our systems and suffer the risk of being exposed.
+
+### Am I affected?
+If your rules contain sensitive values within the rule code itself, you are affected.
+
+### Mitigation steps
+Place the sensitive values in the _Settings_ area of the main _Rules_ section of the Auth0 dashboard and then access them in your rule via the following:
+
+```
+  const myApiKey = configuration.myApiKey;
+```
+
+This will ensure that all sensitive values are encrypted within Auth0's systems, reducing the risk of exposure.
+
+### Will this update impact my users?
+This will not impact your users.
+
diff --git a/ja-jp/articles/security/bulletins/2019-09-05_scopes.md b/ja-jp/articles/security/bulletins/2019-09-05_scopes.md
new file mode 100644
index 0000000000..93bd59afda
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/2019-09-05_scopes.md
@@ -0,0 +1,35 @@
+---
+title: Auth0 Security Bulletin for Assigning Scopes Based on Email Address
+description: Cases where improper custom rule code may create vulnerabilities in the authentication flow.
+topics:
+  - security
+  - security-bulletins
+  - rules
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Auth0 Security Bulletin for Assigning Scopes Based on Email Address
+
+## Overview
+
+If you:
+
+* Use rules to assign scopes to users based on their email addresses **and**
+* Your application uses multiple connections
+
+There is a possibility that your scopes could be compromised.
+
+## How This Works
+
+Auth0 requires that email addresses are unique on a per-connection basis. However, there are no limitations on a per-application basis.
+
+Therefore, it is possible for user A to sign up for the application using one connection *and* user B to sign up for the application with the _same email address_ using a different connection.
+
+If your rules assign scopes to users based on email address, the second user has now been given the same scopes as the first user, despite being a different individual.
+
+## How do I fix this?
+
+The most straightforward mitigation is to require users to [verify their email address](/api/management/v2#!/Jobs/post_verification_email) after signing up and before being allowed to log in.
\ No newline at end of file
diff --git a/ja-jp/articles/security/bulletins/2020-03-31_wpauth0.md b/ja-jp/articles/security/bulletins/2020-03-31_wpauth0.md
new file mode 100644
index 0000000000..a5a6f4d6bc
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/2020-03-31_wpauth0.md
@@ -0,0 +1,47 @@
+---
+title: Security Update for WordPress Plugin for Auth0 
+description: Security Update for WordPress Plugin for Auth0 (CVE-2020-5391, CVE-2020-5392, CVE-2020-6753, CVE-2020-7948, CVE-2020-7947)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - wordpress
+  - wp-auth0
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Update for WordPress Plugin for Auth0
+
+**Published**: March 31, 2020
+
+**CVE numbers**: CVE-2020-5391, CVE-2020-5392, CVE-2020-6753, CVE-2020-7948, CVE-2020-7947
+
+**Credit**: Muhamad Visat
+
+## Overview
+
+Auth0 has released a new major version of the [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) to address several vulnerabilities.
+
+We recommend you review the following security advisories and upgrade to the new major version:
+
+- CSRF controls missing for domain field in Auth0 WP plugin: [CVE-2020-5391](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5391)
+- Stored XSS in Auth0 WP plugin (Settings page): [CVE-2020-5392](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5392)
+- Stored XSS in Auth0 WP plugin (multiple pages): [CVE-2020-6753](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6753)
+- CSV injection vulnerabilities in Auth0 WP plugin: [CVE-2020-7947](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7947)
+- Insecure direct object reference in Auth0 WP plugin: [CVE-2020-7948](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7948)
+
+## Am I affected?
+
+Customers using any version of the WordPress Plugin for Auth0 3.11.3 or earlier can be affected. 
+
+## How to fix that?
+
+Customers using [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) need to upgrade to version 4.0.0 or higher. 
+
+
+## Will this update impact my users?
+
+The [release notes](https://github.com/auth0/wp-auth0/blob/master/CHANGELOG.md) provide more in-depth information about the changes that were made, and the [migration instructions](https://github.com/auth0/wp-auth0/blob/master/MIGRATE-v3-TO-v4.md) provide more in-depth information about the upgrade path.
diff --git a/ja-jp/articles/security/bulletins/cve-2017-16897.md b/ja-jp/articles/security/bulletins/cve-2017-16897.md
new file mode 100644
index 0000000000..2dd3913dfc
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2017-16897.md
@@ -0,0 +1,68 @@
+---
+title: Auth0 Security Bulletin CVE 2017-16897
+description: Security Update for passport-wsfed-saml2 Passport strategy library (CVE 2017-16897)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - passport-wsfed-saml2
+  - passport
+  - wsfed
+  - saml
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for passport-wsfed-saml2 Passport Strategy Library
+
+**Published**: December 22, 2017
+
+**CVE number**: CVE 2017-16897
+
+**Credit**: Alan Bishop
+
+## Overview
+
+A vulnerability has been discovered in the [passport-wsfed-saml2 library](https://github.com/auth0/passport-wsfed-saml2) affecting versions < `3.0.5`.
+
+:::note
+**passport-wsfed-saml2** is a WS-Federation protocol and SAML2 tokens authentication provider for [Passport.js](http://passportjs.org/).
+:::
+
+This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider does not sign the full SAML response, but instead only signs the assertion within the response.
+
+An attacker who successfully exploits this vulnerability could use that response to craft a request with a different **NameIdentifier** in order to log in as a different user. A malicious actor could also perform a privilege escalation attack if authenticating as a specific user with administrative privileges. The attacker must have an existing account, or be able to intercept the encrypted traffic and modify the SAML response on the fly. 
+
+This update addresses the vulnerability by avoiding wrapping attacks for **Assertion** and **Response** elements, as well as providing some defensive changes in XPath expressions. An update has also been implemented to improve the method of logging information about the signing of the SAML response.
+
+Patching this vulnerability requires a library upgrade. 
+
+## Am I affected?
+
+This vulnerability affected cloud tenants utilizing the **SAMLP Identity Provider Connection** wherein the identity provider either:
+
+- signed SAML response and signed assertion
+- did not sign SAML response and signed assertion
+
+No action is required for Auth0 cloud tenants. 
+
+The vulnerability scope also extended to those using the [passport-wsfed-saml2 strategy with passport.js](https://github.com/auth0/passport-wsfed-saml2), which requires a library upgrade (see the next section).
+
+## How to fix that?
+
+Developers using the **passport-wsfed-saml2** library need to upgrade to the latest version: `3.0.5`.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "passport-wsfed-saml2": "^3.0.5"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/cve-2017-17068.md b/ja-jp/articles/security/bulletins/cve-2017-17068.md
new file mode 100644
index 0000000000..9721c1184b
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2017-17068.md
@@ -0,0 +1,56 @@
+---
+title: Auth0 Security Bulletin CVE 2017-17068
+description: Security Update for auth0.js Popup Callback Vulnerability (CVE 2017-17068)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+  - auth0js-popup
+  - callbacks
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for auth0.js Popup Callback Vulnerability
+
+**Published**: December 4, 2017
+
+**CVE number**: CVE 2017-17068
+
+**Credit**: [@AppCheckNG](https://twitter.com/AppCheckNG)
+
+## Overview
+
+A vulnerability has been identified in the [auth0.js JavaScript library](/libraries/auth0js), affecting versions < `8.12`.
+
+If your site or application uses a popup callback page with `auth0.popup.callback()` then an attacker can take advantage of unrestricted cross-origin post message requests and gain access to the tokens of logged-in users. A malicious website could then use any acquired Access Tokens to invoke services on behalf of the user.
+
+This update addresses the vulnerability by implementing origin verification so the message cannot be posted to a page that is not in a specified domain. If no domain is specified, only the domain where the callback page is hosted is allowed. An attacker would receive a cross-origin request error.
+
+Patching this vulnerability requires a library upgrade.
+
+## Am I affected?
+
+If the following apply you are affected by this vulnerability:
+- You use a version of auth0.js lower than `8.12`
+- You use a popup callback page with `auth0.popup.callback()` in your code
+
+## How to fix that?
+
+Developers using the auth0.js library need to upgrade to the latest version: `8.12`.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "auth0-js": "^8.12.0"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
\ No newline at end of file
diff --git a/ja-jp/articles/security/bulletins/cve-2018-11537.md b/ja-jp/articles/security/bulletins/cve-2018-11537.md
new file mode 100644
index 0000000000..8fb96b3033
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2018-11537.md
@@ -0,0 +1,56 @@
+---
+title: Auth0 Security Bulletin CVE 2018-11537
+description: Security Update for angular-jwt Whitelist Bypass (CVE 2018-11537)
+toc: true
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for angular-jwt Whitelist Bypass
+
+**Published**: June 5, 2018
+
+**CVE number**: CVE 2018-11537
+
+**Credit**: Stephan Hauser
+
+## Overview
+
+The [domain whitelisting](https://github.com/auth0/angular-jwt#whitelisting-domains) feature can be bypassed. For example, if the setting is initialized with 
+
+```js
+jwtInterceptorProvider.whiteListedDomains = ['whitelisted.Example.com'];
+```
+
+An attacker can set up a domain `whitelistedXexample.com` that will pass the whitelist filter. The root cause for this is that `angular-jwt` always treats `whiteListedDomains` entries as regular expressions and causes `.` separator to match any character.
+
+## Am I affected?
+
+If the following apply you are affected by this vulnerability:
+- You use a version of angular-jwt lower than `0.1.10`
+- You use domain whitelisting in your code
+
+## How to fix that?
+
+Developers using the angular-jwt library need to upgrade to the latest version: `0.1.10`.
+
+Updated package is available on [NPM](https://npmjs.com):
+
+```bash
+npm install angular-jwt@0.1.10
+```
+
+To make it easier to keep up with security updates in the future, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries:
+
+```json
+{
+  "dependencies": {
+    "angular-jwt": "^0.1.10"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/cve-2018-15121.md b/ja-jp/articles/security/bulletins/cve-2018-15121.md
new file mode 100644
index 0000000000..df5674586f
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2018-15121.md
@@ -0,0 +1,43 @@
+---
+title: Auth0 Security Bulletin CVE 2018-15121
+description: Security vulnerability in deprecated Auth0 middleware for ASP.NET
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - aspnet
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Vulnerability in auth0-aspnet and auth0-aspnet-owin
+
+**Published**: August 6, 2018
+
+**CVE number**: CVE 2018-15121
+
+**Credit**: Kévin Chalet
+
+## Overview
+
+All versions of the [auth0-aspnet](https://github.com/auth0/auth0-aspnet) and [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) packages have a security vulnerability that leave client applications vulnerable to a Cross-Site Request Forgery (CSRF) attack during authorization and authentication operations.
+
+The root cause of this vulnerability is lack of use and verification of the `state` parameter in OAuth 2.0 and OpenID Connect (OIDC) protocols that allows an attacker to inject their authorization code into victim's session.
+
+## Am I affected?
+
+If you use any version of `auth0-aspnet` or `auth0-aspnet-owin`, you are affected by this vulnerability.
+
+## How to fix that?
+
+Further development of the [auth0-aspnet](https://github.com/auth0/auth0-aspnet) and [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) packages has been discontinued. We strongly recommend moving to OWIN 4 and the official `Microsoft.Owin.Security.OpenIdConnect` package, which is not vulnerable.
+
+See the [migration guide](/quickstart/webapp/aspnet-owin/04-migrating) for more details.
+
+If your application is not currently making use of OWIN, please refer to Microsoft's [OWIN documentation](https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/) to enable it in your application.
+
+### Will this update impact my users?
+
+Current user states and sessions will be invalidated, as different libraries will handle authentication.
diff --git a/ja-jp/articles/security/bulletins/cve-2018-6873.md b/ja-jp/articles/security/bulletins/cve-2018-6873.md
new file mode 100644
index 0000000000..546d8d75b7
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2018-6873.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2018-6873
+description: Details about a security vulnerability identified in the Auth0 authentication service
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - tokens
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability in the Auth0 Authentication Service
+
+**Published**: April 4, 2018
+
+**CVE number**: CVE 2018-6873
+
+**Credit**: [Cinta Infinita](http://www.cintainfinita.com/)
+
+## Overview
+
+A vulnerability was identified in the Auth0 authentication service. It affected all Auth0 tenants, and was patched on October 15th, 2017 within four hours of report for all public cloud customers. This notice is informational and is intended to explain the vulnerability and the mitigation taken.
+
+As part of an user authentication flow employed by the Auth0 service, a JSON Web Token (JWT) is passed to the `/login/callback` endpoint identifying the user. This token contains a reference to which audience - an Auth0 tenant - it is intended for. A flaw in the Auth0 service did not properly validate this audience, and therefore allowed tokens intended for one tenant to be used at another. Further, the custom database functionality available to all Auth0 tenants allows for authenticated tokens to be generated with any desired identifier. Therefore, could an attacker learn the user identifier of an intended victim at a target tenant - which is generally considered public information - they could construct a token with that identifier. Due to the improper audience checking the target tenant would accept it, and establish a login session recognizing the attacker as the victim. This allowed for privilege escalation, among other possible attack vectors. 
+
+A specific concern was the potential use of this attack on the Auth0 management service. Auth0 tenants are managed by tenant administrators, who have accounts on an "authority tenant" with relevant permissions. If an attacker could learn the user identifier of a tenant administrator on the tenant authority (such as by social engineering), this allowed the attacker to login as the administrator by the described attack method. The attacker could then undertake administration actions and view all information at the tenant.
+
+The attack was never effective if the user had multifactor authentication enabled, which is recommended.
+
+## Am I affected?
+
+All Auth0 tenants were affected, but have been patched. Public cloud tenants were patched within four hours of the vulnerability report.
+
+The attack was never effective if the user had multifactor authentication enabled.
+
+## How to fix that?
+
+The vulnerability was fixed by Auth0, accomplished by adding proper validation of the audience parameter. No additional actions are required of our customers.
+
+### Will this update impact my users?
+
+The fix was invisible to all users.
diff --git a/ja-jp/articles/security/bulletins/cve-2018-6874.md b/ja-jp/articles/security/bulletins/cve-2018-6874.md
new file mode 100644
index 0000000000..c90b549af7
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2018-6874.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2018-6874
+description: Details about a security vulnerability identified in the Auth0 authentication service
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability in the Auth0 Authentication Service
+
+**Published**: April 4, 2018
+
+**CVE number**: CVE 2018-6874
+
+**Credit**: Internal
+
+## Overview
+
+A vulnerability has been identified in the Auth0 authentication service. Tenants of the service with the Legacy Lock API flag enabled in the service’s management dashboard are affected. If the flag is not visible, it is disabled. Disabling the flag may break applications employing the [auth0.js](/libraries/auth0js) library with version `< 9.0.0` or the [Lock](/libraries/lock) library with version `< 11.0.0` for crossdomain username/password based authentication - also known as [embedded login](/guides/login/universal-vs-embedded). Further, any cross-domain use of the `/usernamepassword/login` authentication api endpoint outside of those libraries may also be affected.
+
+After the verification of user credentials on `/usernamepassword/login`, an HTML form is rendered into the user’s browser and automatically executed. It POSTs a JSON Web Token (JWT) to the `/login/callback` endpoint. This authenticated token maintains state regarding the identity of the user; this cannot be done directly due to crossdomain session management restrictions maintained by most modern browsers. Due to the lack of session binding, this form post is susceptible to [CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)). An attacker with valid user credentials at an Auth0 tenant can use them to gain such a form, and then employ techniques such as social engineering or clickjacking to have a victim’s browser execute it. The victim will then have a login session at the Auth0 tenant under the attacker’s account - and therefore be recognized as the attacker by any downstream application in its federation. Should the user undertake any actions while maliciously logged in as such, those actions and any related information will be visible to the attacker.
+
+The attack does not allow any escalation of privileges on behalf of the attacker, and the victim’s actions visible to the attacker are restricted to whatever permissions have been granted to that attacker within the system. The victim will also be fully recognized as the attacker within the federation, and so may be shown account information or other context clues that reveal they are not operating within the auspices of their own account.
+
+## Am I affected?
+
+You are affected if you employ username/password authentication (with any database and/or connection) for your Auth0 tenant, and the Legacy Lock API flag in the Auth0 management dashboard is visible and flagged on.
+
+## How to fix that?
+
+To mitigate the vulnerability, toggle the flag to off. The `/usernamepassword/login` endpoint will still work for logins from the Universal Login page hosted on `/login`, however these - as same-domain logins - will be protected from CSRF. Otherwise, toggling the flag will disable cross-domain authentication on that endpoint.
+
+For applications employing [auth0.js](/libraries/auth0js) version `< 9.0.0` or [Lock](/libraries/lock) version `< 11.0.0`, this may break user logins. Upgrading to [auth0.js](/libraries/auth0js) version `> 9.0.0` or [Lock](/libraries/lock) version `> 11.0.0` will restore embedded username/password authentication using [cross-origin authentication](/cross-origin-authentication) (note the [limitations](/cross-origin-authentication#limitations)). Applications are also encouraged to [migrate to Universal Login](/guides/login/migration-embedded-universal).
+
+Private SaaS Appliances running versions `> 14591` with the Legacy Lock API flag set to off are not affected by this vulnerability.
+
+### Will this update impact my users?
+
+If the Legacy Lock API is disabled without applications having migrated, then all user logins employing the affected functionality will break. Auth0 intends to enforce disablement of the Legacy Lock API for all tenants on July 16th, 2018. The choice of migration may affect the specific user experience of logging into your service, however users, their information, and their sessions will not be otherwise impacted.
diff --git a/ja-jp/articles/security/bulletins/cve-2018-7307.md b/ja-jp/articles/security/bulletins/cve-2018-7307.md
new file mode 100644
index 0000000000..7887c5fd03
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2018-7307.md
@@ -0,0 +1,50 @@
+---
+title: Auth0 Security Bulletin CVE 2018-7307
+description: Details about a security vulnerability identified for auth0.js < 9.3
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Vulnerability for auth0.js < 9.3
+
+**Published**: February 26, 2018
+
+**CVE number**: CVE 2018-7307
+
+**Credit**: Internal
+
+## Overview
+
+A vulnerability has been identified in the [auth0.js JavaScript library](/libraries/auth0js), affecting versions < `9.3`.
+
+This vulnerability allows an attacker to bypass the CSRF check from the [state parameter](/protocols/oauth2/oauth-state) if it's missing from the authorization response, leaving the client vulnerable to CSRF attacks.
+
+Patching this vulnerability requires a library upgrade.
+
+## Am I affected?
+
+If you use a version of auth0.js lower than `9.3` then you are affected by this vulnerability.
+
+## How to fix that?
+
+Developers using the auth0.js library need to upgrade to the version `9.3` or higher.
+
+Updated packages are available on npm. To ensure delivery of additional bug fixes moving forward, please make sure your `package.json` file is updated to take patch and minor level updates of our libraries.
+
+```text
+{
+  "dependencies": {
+    "auth0-js": "^9.3.0"
+  }
+}
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/cve-2019-13483.md b/ja-jp/articles/security/bulletins/cve-2019-13483.md
new file mode 100644
index 0000000000..c8cedc4767
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2019-13483.md
@@ -0,0 +1,39 @@
+---
+title: Auth0 Security Bulletin CVE-2019-13483
+description: Details about a security vulnerability in Passport-SharePoint 
+topics:
+ - security
+ - security-bulletins
+ - authentication
+ - passport
+contentType:
+ - reference
+useCase:
+ - development
+---
+
+# Security Vulnerability in Passport-SharePoint
+
+**Published**: 7/23/2019
+
+**CVE number**: CVE-2019-13483
+
+## Overview
+
+Versions of [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) prior to **0.4.0** do not validate the JWT signature of an Access Token before processing.
+
+This vulnerability allows attackers to forge tokens and bypass authentication and authorization mechanisms.
+
+## Am I affected?
+
+You are affected by this vulnerability if you use a [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) version earlier than 0.4.0.
+
+## How do I fix this?
+
+Developers using the [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) library must upgrade to version `0.4.0`.
+
+Please note that Auth0 has deprecated and will no longer maintain this library. Developers should plan to discontinue its use.
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but it will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/cve-2019-16929.md b/ja-jp/articles/security/bulletins/cve-2019-16929.md
new file mode 100644
index 0000000000..5922b85b6c
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2019-16929.md
@@ -0,0 +1,42 @@
+---
+title: Auth0 Security Bulletin CVE-2019-16929
+description: Security vulnerability in auth0.net 
+topics:
+ - security
+ - security-bulletins
+ - authentication
+contentType:
+ - reference
+useCase:
+ - development
+---
+
+# Security Vulnerability in auth0.net
+
+**Published**: 10/03/2019
+
+**CVE number**: CVE-2019-16929
+
+**Credit**: Dennis Detering (Spike Reply GmbH)
+
+## Overview
+
+Versions of [auth0.net](https://github.com/auth0/auth0.net) and associated NuGet Package [Auth0.AuthenticationAPI](https://www.nuget.org/packages/Auth0.AuthenticationApi/) from `5.8.0` to `6.5.3` inclusive include a class named `IdentityTokenValidator` with a public `ValidateAsync` method, that performs limited validation suitable only for auth0 issued tokens.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using the `IdentityTokenValidator` to validate untrusted ID tokens
+- You are using a version of Auth0.AuthenticationAPI between `5.8.0` and `6.5.3` inclusive
+
+## How to fix that?
+
+Developers should not use the `IdentityTokenValidator` class to validate untrusted ID tokens. See https://auth0.com/docs/tokens/guides/validate-id-tokens for our recommendations for validating ID tokens. https://jwt.io/ is a good resource on open source JWT validation libraries and their capabilities. Note that additional logic may be required based upon your use case.
+
+Developers using the [auth0.net](https://github.com/auth0/auth0.net) and associated NuGet Package [Auth0.AuthenticationAPI](https://www.nuget.org/packages/Auth0.AuthenticationApi/) between `5.8.0` and `6.5.3` inclusive should upgrade to the latest version `6.5.4` to prevent accidental usage of the `IdentityTokenValidator` class.
+
+### Will this update impact my users?
+
+No. This fix patches the client library that your application runs, but will not impact your users, their current state, or any existing sessions.
+
diff --git a/ja-jp/articles/security/bulletins/cve-2019-20173.md b/ja-jp/articles/security/bulletins/cve-2019-20173.md
new file mode 100644
index 0000000000..884f10df9d
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2019-20173.md
@@ -0,0 +1,44 @@
+---
+title: Auth0 Security Bulletin CVE 2019-20173
+description: Security Update for WordPress Plugin for Auth0 (CVE 2019-20173)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - wordpress
+  - wp-auth0
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Update for WordPress Plugin for Auth0 [wp-auth0](https://github.com/auth0/wp-auth0)
+
+**Published**: January 31, 2020
+
+**CVE number**: CVE-2019-20173
+
+**Credit**: Muhamad Visat
+
+
+## Overview
+
+The WordPress Plugin for Auth0 versions 3.11.0, 3.11.1, and 3.11.2 do not properly sanitize the `wle` query parameter. This could allow an attacker to run a cross-site scripting (XSS) attack on the login page.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following apply:
+
+* You are using the WordPress Plugin for Auth0 versions 3.11.0, 3.11.1, or 3.11.2
+* The “Original Login Form on wp-login.php” setting under Basic settings is set to either of the two options:
+  * “Via a link under the Auth0 form” (default option)
+  * “When "wle" query parameter is present”
+
+## How to fix that?
+
+Developers using WordPress Plugin for Auth0 need to upgrade to version 3.11.3 or later.
+
+## Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/cve-2019-20174.md b/ja-jp/articles/security/bulletins/cve-2019-20174.md
new file mode 100644
index 0000000000..0c6c6a2cf0
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2019-20174.md
@@ -0,0 +1,71 @@
+---
+title: Auth0 Security Bulletin CVE 2019-20174
+description: Security Update for Auth0 Lock library (CVE 2019-20174)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for Auth0 Lock Library
+
+**Published**: January 30, 2020
+
+**CVE number**: CVE 2019-20174
+
+**Credit**: Muhamad Visat
+
+## Overview
+
+Auth0 Lock version 11.20.4 and earlier did not properly sanitize the generated HTML code. Customers using the `additionalSignUpFields` customization option to add a checkbox to the sign-up dialog who are passing a `placeholder` property obtained from an untrusted source (e.g., a query parameter) could allow cross-site scripting (XSS) on their sign-up pages.
+
+## Am I affected?
+
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using Auth0 Lock version 11.20.4 or earlier.
+- You pass `additionalSignUpFields` as an option when initializing Lock, and it includes a field of type `checkbox` with a `placeholder` value obtained from an untrusted source.
+
+An example of a vulnerable snippet is the following where the `placeholder` value is partially user-controlled by the `name` query parameter:
+
+```javascript
+
+```
+
+## How to fix that?
+
+Developers using Auth0’s Lock sign-in solution need to upgrade to version 11.21.0 or later. Version 11.21.0 introduces two changes:
+
+1. The existing `placeholder` property is now treated as plain text to mitigate the problem.
+2. A new `placeholderHTML` property is introduced that indicates the level of control it provides and that its value should be supplied only from trusted sources.
+
+## Will this update impact my users?
+
+This fix patches the Auth0 Lock widget and may require changes in application code, but it will not impact your users, their current state, or any existing sessions.
+
+Developers using the `placeholder` property with HTML content from a trusted source should start using the `placeholderHTML` property to continue providing the same user experience.
diff --git a/ja-jp/articles/security/bulletins/cve-2019-7644.md b/ja-jp/articles/security/bulletins/cve-2019-7644.md
new file mode 100644
index 0000000000..19a9e1eb95
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2019-7644.md
@@ -0,0 +1,54 @@
+---
+title: Auth0 Security Bulletin CVE-2019-7644
+description: Security vulnerability in Auth0-WCF-Service-JWT for ASP.NET
+topics:
+  - security
+  - security-bulletins
+  - authentication
+  - aspnet
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Security Vulnerability in Auth0-WCF-Service-JWT
+
+**Published**: February 15, 2019
+
+**CVE number**: CVE-2019-7644
+
+**Credit**: Conny Dahlgren, Security Researcher at DevilSec AB
+
+## Overview
+
+All versions of [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) NuGet package lower than 1.0.4 include sensitive information about the expected JWT signature in an error message emitted when JWT signature validation fails:
+
+```
+Invalid signature. Expected 8Qh5lJ5gSaQylkSdaCIDBoOqKzhoJ0Nutkkap8RgB1Y= got 8Qh5lJ5gSaQylkSdaCIDBoOqKzhoJ0Nutkkap8RgBOo=
+```
+
+This vulnerability allows attackers to use this error message to obtain a valid signature for arbitrary JWT tokens. This way attackers can forge tokens to bypass authentication and authorization mechanisms.
+
+## Am I affected?
+
+You are affected by this vulnerability if the following conditions apply:
+
+- You use a version of [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) NuGet package lower than 1.0.4
+- You show signature verification exception message in the user interface or make it otherwise available to the attacker (for example through logs or diagnostic messages)
+
+
+## How to fix that?
+
+Developers using the [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) library need to upgrade to the latest version 1.0.4.
+
+The updated package is available on [NuGet](https://www.nuget.org):
+
+```
+Install-Package Auth0-WCF-Service-JWT -Version 1.0.4
+```
+
+### Will this update impact my users?
+
+No. This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
+
diff --git a/ja-jp/articles/security/bulletins/cve-2020-15084.md b/ja-jp/articles/security/bulletins/cve-2020-15084.md
new file mode 100644
index 0000000000..895eff253d
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2020-15084.md
@@ -0,0 +1,54 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15084
+description: Security Update for express-jwt library (CVE 2020-15084)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for express-jwt Library
+
+**Published**: June 30, 2020
+
+**CVE number**: CVE 2020-15084
+
+**Credit**: IST Group
+
+## Overview
+Versions before and including 5.3.3, we are not enforcing the **algorithms** entry to be specified in the configuration.
+When **algorithms** is not specified in the configuration, with the combination of jwks-rsa or potentially other asymmetric crypto libraries, it may lead to authorization bypass. 
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+You are using express-jwt
+AND 
+You do not have **algorithms**  configured in your express-jwt configuration.
+AND
+You are using libraries such as jwks-rsa as the **secret**. 
+
+## How to fix that?
+Specify **algorithms** in the express-jwt configuration. The following is an example of a proper configuration
+
+``` 
+const checkJwt = jwt({
+  secret: jwksRsa.expressJwtSecret({
+    rateLimit: true,
+    jwksRequestsPerMinute: 5,
+    jwksUri: `https://{DOMAIN}/.well-known/jwks.json`
+  }),
+  // Validate the audience and the issuer.
+  audience: process.env.AUDIENCE,
+  issuer: `https://{DOMAIN}/`,
+  // restrict allowed algorithms
+  algorithms: ['RS256']
+}); 
+```
+
+## Will this update impact my users?
+The fix provided in the patch will not affect your users if you specified the algorithms allowed. The patch now makes **algorithms** a required configuration. 
diff --git a/ja-jp/articles/security/bulletins/cve-2020-15119.md b/ja-jp/articles/security/bulletins/cve-2020-15119.md
new file mode 100644
index 0000000000..d86ffb1b10
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2020-15119.md
@@ -0,0 +1,42 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15119
+description: Security Update for Auth0 Lock Library (CVE 2020-15119)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - lock
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for Auth0 Lock Library
+
+**Published**: August 16, 2020
+
+**CVE number**: CVE-2020-15119
+
+**Credit**: Muhamad Visat https://github.com/mvisat
+
+## Overview
+Versions before and including `11.25.1` are using `dangerouslySetInnerHTML` to display an informational message when used with a Passwordless or Enterprise connection.
+
+- For Passwordless connection, the value of the input (email or phone number) is displayed back to the user while waiting for verification code input.
+- For Enterprise connection, the value of the input (IdP Domain) from the Enterprise connection setup screen (Auth0 Dashboard) is displayed back to the user when the lock widget opens.
+
+When Passwordless or Enterprise connection is used, the application and its users might be exposed to cross-site scripting (XSS) attacks.
+
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using auth0-lock
+- You are using Passwordless or Enterprise connection mode
+
+
+## How to fix that?
+Upgrade to version `11.26.3`
+
+## Will this update impact my users?
+The fix provided in patch will not affect your users.
diff --git a/ja-jp/articles/security/bulletins/cve-2020-15125.md b/ja-jp/articles/security/bulletins/cve-2020-15125.md
new file mode 100644
index 0000000000..075fe0240e
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2020-15125.md
@@ -0,0 +1,37 @@
+---
+title: Auth0 Security Bulletin CVE 2020-15125
+description: Security Update for node-auth0 library (CVE 2020-15125)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for node-auth0 Library
+
+**Published**: July 28, 2020
+
+**CVE number**: CVE-2020-15125
+
+**Credit**: Omar Diab http://github.com/osdiab
+
+## Overview
+Versions before and including `2.27.0` use a block list of specific keys that should be sanitized from the request object contained in the error object. When a request to Auth0 management API fails, the key for `Authorization` header is not sanitized and the `Authorization` header value can be logged exposing a bearer token.
+
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using auth0 npm package
+- You are using a Machine to Machine application authorized to use Auth0's management API https://auth0.com/docs/flows/concepts/client-credentials
+
+
+## How to fix that?
+Upgrade to version `2.27.1`
+
+## Will this update impact my users?
+The fix provided in patch will not affect your users.
diff --git a/ja-jp/articles/security/bulletins/cve-2020-5263.md b/ja-jp/articles/security/bulletins/cve-2020-5263.md
new file mode 100644
index 0000000000..a7a282b891
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/cve-2020-5263.md
@@ -0,0 +1,38 @@
+---
+title: Auth0 Security Bulletin CVE 2020-5263
+description: Security Update for auth0.js library (CVE 2020-5263)
+toc: true
+topics:
+  - security
+  - security-bulletins
+  - auth0js
+contentType:
+  - reference
+useCase:
+  - development
+---
+# Security Update for auth0.js Library
+
+**Published**: April 09, 2020
+
+**CVE number**: CVE-2020-5263
+
+**Credit**: Bogdan Vitoc (Spatial Systems Inc)
+
+## Overview
+Between versions 8.0.0 and  9.13.1 (inclusive), in the case of an (authentication) error, the error object returned by the library contains the original request of the user, which may include the plaintext password the user entered. 
+
+If the error object is exposed or logged without modification, the application risks password exposure.
+
+## Am I affected?
+You are affected by this vulnerability if all of the following conditions apply:
+
+- You are using Auth0.js version between 8.0.0 and 9.13.1 (inclusive).
+- You store or display error objects without filtering. 
+
+## How to fix that?
+Developers should upgrade auth0.js to version 9.13.2 or later where user inputted passwords are masked in errors. If upgrading is not possible, a temporary fix may include not storing the error object or displaying it publicly without modification.
+
+## Will this update impact my users?
+
+This fix patches the Auth0.js and may require changes in application code due to password no longer available in error object, but it will not impact your users, their current state, or any existing sessions.
diff --git a/ja-jp/articles/security/bulletins/index.md b/ja-jp/articles/security/bulletins/index.md
new file mode 100644
index 0000000000..63ad7bf6e1
--- /dev/null
+++ b/ja-jp/articles/security/bulletins/index.md
@@ -0,0 +1,48 @@
+---
+classes: topic-page
+title: Auth0 Security Bulletins
+description: List of bulletins addressing security vulnerabilities in Auth0 software, with info on how to fix them.
+topics:
+  - security
+  - security-bulletins
+contentType:
+  - index
+  - reference
+useCase:
+  - development
+---
+
    
+  
    
+  
    Auth0 Security Bulletins
    
+  
    
+    List of bulletins addressing security vulnerabilities in Auth0 software.
+  
    
+
    
+
+This page contains a list of all the published security vulnerabilities of Auth0 software.
+
+Each bulletin contains a description of the vulnerability, how to identify if you are affected, and what to do to fix it.
+
+## Bulletins
+
+| **Date** | **Bulletin number** | **Title** | **Affected software** |
+|-|-|-|-|
+| August 16, 2020 | [CVE-2020-15119](/security/bulletins/cve-2020-15119) | Security Update for Auth0 Lock <= 11.25.1 | [Auth0 Lock](https://github.com/auth0/lock) |
+| July 28, 2020 | [CVE-2020-15125](/security/bulletins/cve-2020-15125) | Auth0 Security Bulletin for node-auth0 <= 2.27.0 | [node-auth0](https://github.com/auth0/node-auth0) |
+| June 30, 2020 | [CVE 2020-15084](/security/bulletins/cve-2020-15084) | Auth0 Security Bulletin for express-jwt versions < 6.0.0 | [express-jwt](https://github.com/auth0/express-jwt) |
+| April 09, 2020 | [CVE 2020-5263](/security/bulletins/cve-2020-5263) | Auth0 Security Bulletin for auth0.js versions <= 9.13.1 | [Auth0.js](/libraries/auth0js) |
+| March 31, 2020 | [Auth0 Bulletin](/security/bulletins/2020-03-31_wpauth0) | Auth0 Security Bulletin for WordPress Plugin for Auth0 versions < 4.0.0 | [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) |
+| January 31, 2020 | [CVE 2019-20173](/security/bulletins/cve-2019-20173) | Auth0 Security Bulletin for WordPress Plugin for Auth0 versions 3.11.0, 3.11.1 and 3.11.2 | [WordPress Plugin for Auth0](https://github.com/auth0/wp-auth0) |
+| January 30, 2020 | [CVE 2019-20174](/security/bulletins/cve-2019-20174) | Auth0 Security Bulletin for Auth0 Lock < 11.21.0 | [Auth0 Lock](https://github.com/auth0/lock) |
+| October 04, 2019 | [CVE 2019-16929](/security/bulletins/cve-2019-16929) | Auth0 Security Bulletin for auth0.net between versions 5.8.0 and 6.5.3 inclusive | [auth0.net](https://www.nuget.org/packages/Auth0.AuthenticationApi/) |
+| September 05, 2019 | [Auth0 bulletin](/security/bulletins/2019-09-05_scopes) | Auth0 Security Bulletin for assigning scopes based on email address | Custom code within Auth0 rules |
+| July 23, 2019 | [CVE 2019-13483](/security/bulletins/cve-2019-13483) | Security Bulletin for Passport-SharePoint < 0.4.0 | [Passport-SharePoint](https://github.com/auth0/passport-sharepoint) |
+| February 15, 2019 | [CVE 2019-7644](/security/bulletins/cve-2019-7644) | Security Bulletin for Auth0-WCF-Service-JWT < 1.0.4 | [Auth0-WCF-Service-JWT](https://www.nuget.org/packages/Auth0-WCF-Service-JWT/) |
+| January 10, 2019 | [Auth0 bulletin](/security/bulletins/2019-01-10_rules) | Auth0 Security Bulletin for Vulnerable Patterns in Custom Rule Code | Custom code within Auth0 Rules |
+| August 6, 2018 | [CVE 2018-15121](/security/bulletins/cve-2018-15121) | Security vulnerability in deprecated Auth0 middleware for ASP.NET | [auth0-aspnet](https://github.com/auth0/auth0-aspnet), [auth0-aspnet-owin](https://github.com/auth0/auth0-aspnet-owin) |
+| June 5, 2018 | [CVE 2018-11537](/security/bulletins/cve-2018-11537) | Security update for angular-jwt whitelist bypass | [angular-jwt](https://github.com/auth0/angular-jwt) |
+| April 4, 2018 | [CVE 2018-6874](/security/bulletins/cve-2018-6874) | Security vulnerability for Auth0 authentication service | Auth0 Authentication Service |
+| April 4, 2018 | [CVE 2018-6873](/security/bulletins/cve-2018-6873) | Security vulnerability for Auth0 authentication service | Auth0 Authentication Service |
+| February 26, 2018 | [CVE 2018-7307](/security/bulletins/cve-2018-7307) | Security vulnerability for auth0.js < 9.3 | [Auth0.js](/libraries/auth0js) |
+| December 22, 2017 | [CVE 2017-16897](/security/bulletins/cve-2017-16897) | Security update for **passport-wsfed-saml2** Passport strategy library | **passport-wsfed-saml2** Passport strategy library |
+| December 4, 2017 | [CVE 2017-17068](/security/bulletins/cve-2017-17068) | Security update for auth0.js popup callback vulnerability | [Auth0.js](/libraries/auth0js) |
diff --git a/ja-jp/articles/security/common-threats.md b/ja-jp/articles/security/common-threats.md
new file mode 100644
index 0000000000..2da556c201
--- /dev/null
+++ b/ja-jp/articles/security/common-threats.md
@@ -0,0 +1,63 @@
+---
+description: Describes different types of cyber attacks and what steps can be taken to prevent them.
+topics:
+  - security
+  - security-bulletins
+  - prevention
+  - common-threats
+  - MitM
+  - CSRF
+  - XSRF
+  - replay
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Common Threats and How to Prevent Them
+
+## Man-in-the-Middle (MitM) attacks
+
+One type of threat is a Man-in-the-middle attack, sometimes called a bucket brigade attack. With this attack the attacker gets between two parties, where each party thinks they are interacting over a private connection, but it is actually being controlled by the third-party attacker. For this type of attack to succeed the attacker must create mutual authentication between both parties.
+
+Usually MitM attacks involve the attacker using a WiFi router to intercept a user's communication. The user connects to the attacker's router then visits a website and logs in with their confidential credentials. The attacker saves that user's login credentials for which they can then use to impersonate the user.
+
+Some MitM attacks can also modify the data transmitted between the application and the server. Attacks can occur from new PC trial and preinstalled software, software update tools, and other software vulnerabilities. In a worst case scenario this could result in remote code execution, backdooring the system, installing malware, and so on. This could also lead to the compromise of other network assets.
+
+### Preventing MitM attacks
+
+To help defend against this type of attack it is important to use strong encryption and authentication between the application and the server. Using encryption the server authenticates the application's request by presenting a digital certificate, and only then can the connection be established.  For example, HTTPS uses the secure sockets layer (SSL) capability of the browser to mask web traffic. To decrypt HTTPS, a man-in-the-middle attacker would have to obtain the keys used to encrypt the network traffic.
+
+With the configuration of TLS on your servers we suggest using the [Mozilla OpSec recommendations](https://wiki.mozilla.org/Security/Server_Side_TLS) which use TLSv1.2. Mozilla also provides an [SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/), to use this first choose which platform your server is running and then choose the most modern configuration based on what your application base can support. The more modern configurations provide stronger ciphers to help prevent attacks.
+
+## Replay attacks
+
+Replay attacks allow attackers to:
+
+* Gain access to a network and information which would not have been easily accessible 
+* Complete a duplicate transaction
+
+These are attacks on the security protocol using replays of data transmission from a different sender into the intended receiving system. The attacks fool the participants into believing they have successfully completed the data transmission. 
+
+A replay attack is also known as a playback attack.
+
+### Preventing Replay attacks
+
+Replay attacks can be avoided by using session tokens. However, if these credentials are stolen from local storage (like during an XSS attack), there are ways to prevent someone from holding on to a valid token forever:
+
+* Set a short expiration time for tokens
+* Provide a way to blacklist tokens that have been used (and possibly even the users)
+* Use one-time passwords
+
+The [JWT](/tokens/concepts/jwts) spec provides the `jti` field as a way to prevent replay attacks. Though Auth0 tokens currently don't return the `jti`, you can blacklist using the `jti` to prevent a token being used more than a specified number of times. In this way, you are implementing something similar to a nonce (think of the token's signature as the nonce). If a token gets stolen or it gets used more than the specified number of times, it should be blacklisted. This prevents a valid token from being used maliciously. Once the token expires, the attacker will no longer be able to impersonate the user.
+
+You can also avoid replay attacks by using one-time passwords. With Auth0, you can use [Passwordless Authentication](/passwordless), which relies on single-use codes and email links instead of traditional passwords. Auth0 also provides multi-factor authentication (MFA) which uses one-time passwords as a second-factor authentication which can be sent via push notifications and texts.
+
+## Cross-site Request Forgery
+
+A Cross-site Request Forgery (CSRF or XSRF) attack occurs when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate a type of action instead of getting user data because the attacker has no way to see the response of the forged request.
+
+### Preventing CSRF attacks
+
+One way to verify the requests that are being sent is to utilize the OAuth 2.0 protocol `state` parameter to authenticate the response. For more information, see [State Parameter](/protocols/oauth-state).
diff --git a/ja-jp/articles/security/index.md b/ja-jp/articles/security/index.md
new file mode 100644
index 0000000000..829e78deb8
--- /dev/null
+++ b/ja-jp/articles/security/index.md
@@ -0,0 +1,47 @@
+---
+url: /security
+classes: topic-page
+title: Auth0 Security
+description: Read about various security-related topics and keep up-to-date with released Auth0 security bulletins
+topics:
+  - security
+  - security-bulletins
+contentType:
+  - reference
+  - index
+useCase:
+  - development
+---
+
+
    
+  
    
+  
    Auth0 Security
    
+  
    
+    Read about various security-related topics and keep up-to-date with released Auth0 security bulletins
+  
    
+
    
+
+## Security bulletins
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/bulletins'
+] }) %>
+
+## Handling tokens
+
+<%= include('../_includes/_topic-links', { links: [
+  'tokens',
+  'tokens/concepts/token-storage'
+] }) %>
+
+## Preventing security attacks
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/common-threats'
+] }) %>
+
+## Data privacy
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/blacklisting-attributes'
+] }) %>
diff --git a/ja-jp/articles/services/_includes/_further-help.md b/ja-jp/articles/services/_includes/_further-help.md
new file mode 100644
index 0000000000..5aba279e75
--- /dev/null
+++ b/ja-jp/articles/services/_includes/_further-help.md
@@ -0,0 +1,3 @@
+::: note
+We provide continuous education and knowledge transfer throughout any engagement. If any part of your project requires more specialized attention and/or implementation assistance, or you would like some specialized training, then your Auth0 Solution Architect will be happy to help you understand how additional Professional Services can help you further to reach your goal.
+:::
diff --git a/ja-jp/articles/services/architectural-design.md b/ja-jp/articles/services/architectural-design.md
new file mode 100644
index 0000000000..8f842b97e7
--- /dev/null
+++ b/ja-jp/articles/services/architectural-design.md
@@ -0,0 +1,32 @@
+---
+description: Project to establish a foundational set up of Auth0 platform architecture.
+topics:
+  - professional services
+  - architecture
+  - solutions-architecture
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Architectural Design Sessions
+
+This is a fixed scope project designed to establish a foundational set up of Auth0 platform architecture: setup connectivity and configuration of your environment to meet your organization’s needs, and enable a technical solution for pre-defined business scenarios involving Auth0.
+
+## Estimated effort
+
+This is typically a 4-6 week part-time engagement effort with an Auth0 Solutions Architect and your development team.
+
+## Typical work-streams
+
+* **Working sessions:** architecture, design and implementation of a base identity services, and infrastructure in the customer's Auth0 subscription model. Provide knowledge transfer to customer staff to prepare them to operate the Solution and to expand Auth0 usage into other scenarios.
+* **Building a Prototype:** leading the development of a scoped down prototype that illustrates customer business scenarios being addressed, and the technical solution, including trade-offs.
+* **Pair-programming your scenario:** our engineers will join the customer's development team during the initial phases of development, under a pair-programming model, taking responsibilities for Auth0-related code.
+
+## Deliverables
+
+* Solution Design memo
+* First Integration Working Prototype
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/code-review.md b/ja-jp/articles/services/code-review.md
new file mode 100644
index 0000000000..03287053c2
--- /dev/null
+++ b/ja-jp/articles/services/code-review.md
@@ -0,0 +1,28 @@
+---
+description: Project to help customers analyze common design patterns.
+topics:
+  - professional services
+  - code-review
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Code Review
+
+An offering to analyze common design patterns and review customer's code flows and integrations. Goal is to detect potential pitfalls and problems, and provide guidance to address these.
+
+## Estimated effort
+
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and the customer's development team.
+
+## Typical work-streams
+
+* **Design Patterns review:** common authorization and authentication scenarios. Identification of anti-patterns. Guidance.
+
+## Deliverables
+
+* Technical document: code review findings, sample code and recommended configuration.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/custom-implementation.md b/ja-jp/articles/services/custom-implementation.md
new file mode 100644
index 0000000000..3046dec8f1
--- /dev/null
+++ b/ja-jp/articles/services/custom-implementation.md
@@ -0,0 +1,35 @@
+---
+title: Custom Implementation
+description: Learn how Professional Services can help you implement your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - custom
+    - implementation
+contentType: concept
+useCase:
+  - custom-implementation
+---
+# Custom Implementation
+
+In addition to enablement activities, Professional Services provides **custom implementation services** to help you accelerate your integration with Auth0. Auth0 is a unique service that offers developers unrivaled flexibility and extensibility, and our expert Professional Services team knows how to extend Auth0 in ways that are the most optimal for the platform and for your environment.
+
+Professional Services can provide a wide range of custom implementation to help you achieve the product functionality, service connectivity, operational readiness, and/or quality assurance you require to get to production. This includes: 
+
+* **Custom rules, hooks, DB scripts, login pages, and email templates:** Solve a user experience, 3rd-party service integration, or other logical problem within a customer’s Auth0 authentication and authorization workflow. These customizations happen in-product and do not require additional infrastructure to deploy.
+
+* **Custom endpoints and libraries:** Solve a service communication, user experience, or tenant management problem through the use of a custom web services endpoint or code library. Typically deployed on customer or third-party infrastructure.
+
+* **Custom utilities:** Solve a quality assurance or operations problem that is out-of-band from extending core product functionality, such as performance testing or deployment scripts.
+
+* **Custom code samples:** Demonstrate how a developer integrates with Auth0 using a specific language or technology stack. Used primarily for education.
+
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Solution Design](/services/solution-design)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+* [Gallery](/services/gallery)
+
diff --git a/ja-jp/articles/services/discover-and-design.md b/ja-jp/articles/services/discover-and-design.md
new file mode 100644
index 0000000000..8d1b6fcba7
--- /dev/null
+++ b/ja-jp/articles/services/discover-and-design.md
@@ -0,0 +1,31 @@
+---
+title: Discover & Design
+description: Learn how Professional Services can help you design and architect your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - design
+contentType: concept
+useCase:
+  - design
+  - solution-design
+---
+# Discover & Design
+
+The first stage in a successful implementation involves discovering, designing, and architecting your Identity and Access Management solution, and our Discover & Design services are here to help. We work together with your product and engineering teams to **architect an Identity solution** for your environment and build an **incremental Go-Live plan** that solves the most-pressing identity problems early. Auth0 Professional Services help your projects quickly reach success by addressing your business objectives in a pragmatic, step-by-step manner. 
+
+<%= include('./_includes/_further-help.md') %>
+
+## Architectural Discovery
+
+Focused on discovering the optimum design based on your requirements, Architectural Discovery services provide best practice guidance on topics such as requirements determination, Auth0 Tenant deployment strategies, your use cases, and integration with the software development process in your organization. Engaging with Auth0 Professional Services will help to provide you with a clear understanding of what you need to tackle, and when, in order to fulfill your particular needs. Delivered as part of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).
+
+## Scenario Guidance
+
+Guiding you through your use case scenarios, our Scenario Guidance services help you navigate the possible paths through your discovered use cases in a best practice manner. Covering topics such as OpenID Connect (OIDC) flows, Authorization server capabilities, session management, and Single Sign-On (SSO), engagement with the Auth0 Professional Services team provides visibility into the things you need to prepare you to address what's required. Delivered as part of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).
+
+## Keep reading
+
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
diff --git a/ja-jp/articles/services/implement.md b/ja-jp/articles/services/implement.md
new file mode 100644
index 0000000000..515db956b8
--- /dev/null
+++ b/ja-jp/articles/services/implement.md
@@ -0,0 +1,41 @@
+---
+title: Implement
+description: Learn how Professional Services can help you implement your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - implementation
+contentType: concept
+useCase:
+  - implementation
+---
+# Implement
+
+To help you accelerate your integration with Auth0, we provide a wide range of implementation services that you can leverage to achieve the product functionality, service connectivity, operational readiness, and/or quality assurance required to get you into production. Auth0 is a unique service that offers developers unrivaled flexibility and extensibility, and our expert Professional Services team knows how to integrate with Auth0 in ways that are the most optimal for the platform and for your environment.
+
+<%= include('./_includes/_further-help.md') %>
+
+## Programming Advisory
+
+Focused on accelerating your development team’s understanding of Auth0 SDKs, APIs, extensibility and integration points, our Programming Advisory services give you the opportunity to engage with our team to get best practice guidance on a wide range of topics. We can provide your development teams with code samples and programming guidance that will help you integrate with Auth0 faster and more effectively, whatever your chosen language or technology stack. Delivered through a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages).    
+
+## Deployment Preparation
+
+Provides for validation on an implemented solution, typically prior to go-live. Our Deployment Preparation services primarily focus on review of integration—including usage of the Auth0 SDKs, APIs, and extensibility—as well as setup configuration of Auth0 and Auth0 Tenant. We can provide you with the peace of mind that the systems you deploy will be safe and secure. Delivered via a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages). 
+
+## Custom Implementation
+
+In addition, our Custom Implementation services—delivered as part of a number of our [Discover, Design, & Implement packages](/services/packages#discover-design-and-implement-packages)—provide a wide range of customized implementations to help you accelerate your integration with Auth0. Custom Implementation gives you the opportunity to leverage our implementation services in cases where you need more than the standard out-of-box functionality: 
+
+* **Custom rules, hooks, DB scripts, login pages, and email templates:** Solve user experience, 3rd-party service integration, or other logical problem within a customer’s Auth0 authentication and authorization workflow. These customizations happen in-product and do not require additional infrastructure to deploy.
+
+* **Custom APIs and libraries:** Solve service communication, user experience, or tenant management problem through the use of a custom web services endpoint or code library. Typically deployed on customer or third-party infrastructure.
+
+* **Custom utilities:** Solve quality assurance or operations problems that are out-of-band from extending core product functionality, such as performance testing or deployment scripts.
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+
diff --git a/ja-jp/articles/services/index.md b/ja-jp/articles/services/index.md
new file mode 100644
index 0000000000..4fbecde974
--- /dev/null
+++ b/ja-jp/articles/services/index.md
@@ -0,0 +1,72 @@
+---
+url: /services
+classes: topic-page
+title: Auth0 Professional Services
+description: Professional Services offered by Auth0.
+topics:
+  - professional services
+contentType:
+  - index
+useCase:
+  - development
+---
+
+
    
+  
    
+  
    Auth0 Professional Services
    
+  
    
+    The Auth0 Professional Services portfolio consists of innovative, specialized service offerings designed to optimize customers' investments in Auth0. Professional Services help customers deploy, implement, and maintain solutions based on proven practices, avoiding common pitfalls and reducing risk.
+  
    
+
    
+
+## How Professional Services can help with your project
+
+Customers buy software to solve a business problem. The longer it takes to integrate with that software, the longer the business problem remains unsolved. If integration stalls or fails, it’s a lost opportunity and a major additional cost both for you and for Auth0; at worst, it can become an even bigger security issue or legal nightmare. That's why it's of the utmost importance to plan, design, and implement your IAM solution securely, effectively, and expediently. This is where Auth0 Professional Services (PS) come in. 
+
+### Get to production faster
+
+
      
+
+We can help consolidate all the enablement activities leading to a successful adoption into three major milestones; the goal of a Professional Services engagement is to identify, document, and build consensus with you on these milestones as the path to successful Auth0 adoption: 
+
+* **Discovery and Design:** where our Solution Architects will work with your teams to identify the core goals, features, and functionality that constitute your successful IAM implementation. We'll also help you uncover any legacy architectural issues or design requirements that may need more careful consideration.
+
+* **Initial Go-Live:** designed to be impactful enough to make material differences in your overall Identity project. At the same time, it's limited enough that it can be reached quickly—ideally within 30 days of the project start—to keep the positive momentum. Initial Go-Live typically includes migration off a legacy IDP, must-have features, and possibly a subset of all your applications.
+
+* **Advanced Go-Live:** which can be easily broken into multiple sub-milestones—especially if you have multiple applications or development teams. This helps manage the complexity of a large project and is designed to help you achieve incremental and steady progress. 
+
+
    
+
+
      
+  
    • 
+    Services
+
+Designed to optimize our customers' investment in Auth0, our service offerings provide the proven best practice assistance required to help avoid common pitfalls and reduce risk when tackling the range of activities involved as part of integrating with Auth0:
+    
+  
      • 
+
    
+
+
      
+  
    • 
+    Packages
+
+Our packages provide our customers with the services they need, in a manner structured to help them engage with our experts in a way that best suits their requirements. [See a full list of the packages we offer](/services/packages) and discover which of them would be a good fit for you.
+  
      • 
+
    
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
diff --git a/ja-jp/articles/services/maintain-and-improve.md b/ja-jp/articles/services/maintain-and-improve.md
new file mode 100644
index 0000000000..6a65da44bb
--- /dev/null
+++ b/ja-jp/articles/services/maintain-and-improve.md
@@ -0,0 +1,28 @@
+---
+title: Maintain and Improve
+description: Learn how Professional Services can help you maintain and improve on your Auth0 investment.
+toc: true
+topics:
+    - ps
+    - maintain
+    - improvement
+contentType: concept
+useCase:
+  - maintain-and-improve
+---
+# Maintain and Improve
+
+Once complete, we can work with your teams to review your identity environment, optimize and improve your solution, advise on new features, and answer any questions; all of these services are designed to help you maintain and improve on your Auth0 investment. To support this, we recommend scheduling an annual HealthCheck engagement with Professional Services via one of our [Maintain and Improve packages](/services/packages#maintain-and-improve-packages).
+
+For our larger customers, we also provide our “Premier Success” post-implementation consulting service via our [Maintain and Improve packages](/services/packages#maintain-and-improve-packages). This assigns a dedicated Solutions Architect to meet with your team on a weekly, bi-weekly, or monthly basis to provide you with the ongoing assistance a demanding environment can often require.
+ 
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Solution Design](/services/solution-design)
+* [Custom Implementation](/services/custom-implementation)
+* [Packages](/services/packages)
+ 
+
+
diff --git a/ja-jp/articles/services/packages.md b/ja-jp/articles/services/packages.md
new file mode 100644
index 0000000000..79947158d6
--- /dev/null
+++ b/ja-jp/articles/services/packages.md
@@ -0,0 +1,131 @@
+---
+title: Professional Service Packages
+description: Learn how to get Auth0 Professional Services help through one of our many packaged offerings
+toc: true
+topics:
+    - ps
+    - packages
+contentType: 
+    - index
+    - concept
+useCase:
+  - packages
+---
+# Professional Service Packages
+
+Auth0 Professional Services provides packaged offerings designed to optimize our customers' investments in Auth0 by helping design, deploy, implement, and maintain solutions based on proven practices, which allows our customers to avoid common pitfalls and reduces risk. Packaged offerings generally fall into two main categories: Discover, Design, and Implement packages, and Maintain and Improve packages. To get more information and to order any of these service offerings, please contact your Auth0 Account Representative.
+
+## Discover, Design, and Implement packages
+
+
    
+	
+	
+		 Discovery Workshop
+
    
+
+* 2 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 90 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+
+
    
+	
+	
+		 Basic Package
+
    
+
+* 5 days of services
+* Remote only
+* Expires in 90 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+
+
    
+	
+	
+		 Standard Package
+
    
+
+* 12 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 180 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+  * Some [Custom Implementation](/services/implement#custom-implementation)
+
+
    
+	
+	
+		 Advanced Package
+
    
+
+* 25 days of services
+* On-site
+* Expires in 180 days
+* Terms and Conditions apply
+* Services typically included:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery)
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance)
+  * [Programming Advisory](/services/implement#programming-advisory)
+  * [Deployment Preparation](/services/implement#deployment-preparation)
+  * [Custom Implementation](/services/implement#custom-implementation)
+
+
    
+	
+	
+		 Custom Implementation Package
+
    
+
+* 15 or more days of services
+* Remote only
+* Expires in 180 days
+* Terms and Conditions apply
+* Full range of [Custom Implementation](/services/implement#custom-implementation) services, including:
+  * [Architectural Discovery](/services/discover-and-design#architectural-discovery), 
+  * [Scenario Guidance](/services/discover-and-design#scenario-guidance) and 
+  * [Programming Advisory](/services/implement#programming-advisory)
+  
+## Maintain and Improve packages
+
+
    
+	
+	
+		 Implementation HealthCheck Package
+
    
+
+* 1 to 3 days of services
+* Remote/on-site, as mutually agreed
+* Expires in 90 days
+* Terms and Conditions apply
+* Wide range of [maintain and improve](/services/maintain-and-improve) services
+ 
+
+
    
+	
+	
+		 Premier Success Package
+
    
+
+* 24 days of services
+* On-site
+* Expires in 365 days
+* Terms and Conditions apply
+* Full range of [maintain and improve](/services/maintain-and-improve) services
+
+
+## Keep reading
+
+* [Discover & Design](/services/discover-and-design)
+* [Implement](/services/implement)
+* [Maintain and Improve](/services/maintain-and-improve)
diff --git a/ja-jp/articles/services/pair-programming.md b/ja-jp/articles/services/pair-programming.md
new file mode 100644
index 0000000000..a2aff15193
--- /dev/null
+++ b/ja-jp/articles/services/pair-programming.md
@@ -0,0 +1,29 @@
+---
+description: Project to co-develop integration points with Auth0.
+topics:
+  - professional services
+  - pair-programming
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Pair Programming
+
+Auth0 engineers will join the customer development teams during initial phases of development, under a pair-programming mode, focusing on Auth0 related code and integration points. The goal is to speed-up development and mitigate risks.
+
+## Estimated effort
+
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and customer's development team.
+
+## Typical work-streams
+
+* **Pair-programming sessions:** co-implement with customer development teams, common authentication flows using Auth0.
+
+
+## Deliverables
+
+* Jointly developed code.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/performance-scalability.md b/ja-jp/articles/services/performance-scalability.md
new file mode 100644
index 0000000000..47ec47f31b
--- /dev/null
+++ b/ja-jp/articles/services/performance-scalability.md
@@ -0,0 +1,34 @@
+---
+description: Project to assist customers with common performance testing needs, including a correct planning, and test automation guidance.
+topics:
+  - professional services
+  - performance
+  - scalability
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Performance and Scalability
+
+An offering to assist customers with common performance testing needs, including a correct planning, and test automation guidance.
+
+## Estimated effort
+
+This is typically a 4-6 week part-time engagement effort with an Auth0 Managed Service Engineer and your infrastructure team.
+
+## Typical work-streams
+
+* **Planning:** gather customer requirements for setting benchmarks.
+* **Performance Lab Design:** lab environment for testing, including network topology, artifacts required, load generation tools, automation scripts.
+* **Test runs:** work with the customer on 3 testing and tuning iterations.
+* **Results Analysis:** documenting findings and recommendations.
+
+## Deliverables
+
+* Architecture document
+* Test execution document
+* Recommendations document
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/private-cloud-configuration.md b/ja-jp/articles/services/private-cloud-configuration.md
new file mode 100644
index 0000000000..023a05dd68
--- /dev/null
+++ b/ja-jp/articles/services/private-cloud-configuration.md
@@ -0,0 +1,34 @@
+---
+description: A project to assist with design and deployment of a Private Cloud Auth0 environment.
+topics:
+  - professional services
+  - private-cloud
+  - design
+  - deployment
+  - configuration
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Hours: Private Cloud reconfiguration
+
+A project to assist with the design, and deployment of a Private Cloud Auth0 environment; including HA and DR scenarios.
+
+## Estimated effort
+
+This is typically a 2-3 week part-time engagement effort with an Auth0 Managed Service Engineer and your infrastructure team.
+
+## Typical work-streams
+
+* **Requirements gathering:** understanding customer Private Cloud deployment requirements and constraints.
+* **Risk analysis:** reviewing and providing guidance for High Availability, and Disaster Recovery alternatives.
+
+## Deliverables
+
+* Technical documentation.
+* Deployment checklist.
+* Assist with deployment.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/private-cloud-management.md b/ja-jp/articles/services/private-cloud-management.md
new file mode 100644
index 0000000000..9670cf91b2
--- /dev/null
+++ b/ja-jp/articles/services/private-cloud-management.md
@@ -0,0 +1,29 @@
+---
+description: A workshop designed to provide IT organizations with core Auth0 Private Cloud management concepts.
+topics:
+  - professional services
+  - private-cloud
+  - management
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Training: Private Cloud Management Workshop
+
+A workshop designed to provide IT organizations with core concepts on availability, reliability, on-going operations and security in their Private Cloud Auth0 service.
+
+## Duration
+
+Two (2) working sessions with an Auth0 Managed Service Engineer.
+
+## Level
+
+**Level 300**, assumes in-depth understanding of Auth0's core features.
+
+## Topics covered
+
+Operations and Administration Tasks, Roles & Responsibilities, complete Dashboard review, review Support procedures, and operational best practices.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/scenario-guidance.md b/ja-jp/articles/services/scenario-guidance.md
new file mode 100644
index 0000000000..fc211feb9e
--- /dev/null
+++ b/ja-jp/articles/services/scenario-guidance.md
@@ -0,0 +1,33 @@
+---
+description: Project to help customers address specific requirements related to a current project that is expected to use Auth0.
+topics:
+  - professional services
+  - product-lifecycle
+  - solutions-architecture
+  - architecture
+contentType:
+  - reference
+useCase:
+  - development
+---
+
+# Advisory Sessions: Scenario guidance
+
+An offering to help customers address specific requirements related to a current project that is expected to use Auth0. This service is applicable in all phases of a product lifecycle, delivered remotely in a variety of ways (such as technology briefings, Q&A sessions, and so on).
+
+## Estimated effort
+
+Includes up to three (3) working sessions, where we will jointly draft a high-level solution to address the requirements of your scenario with an Auth0 Solutions Architect. We will provide a recommendations memo afterwards for your reference.
+
+Diagrams or information you deem relevant should be provided prior to this engagement so that we can optimize the time available.
+
+
+## Typical work-streams
+
+* **Working sessions:** review requirements, jointly discuss architecture solution. Document findings and agreements.
+
+## Deliverables
+
+* Technical document: infrastructure decisions, requirements, setup details, processes, simulation details.
+
+<%= include('../_includes/_contact-sales') %>
diff --git a/ja-jp/articles/services/solution-design.md b/ja-jp/articles/services/solution-design.md
new file mode 100644
index 0000000000..c693dd13f1
--- /dev/null
+++ b/ja-jp/articles/services/solution-design.md
@@ -0,0 +1,40 @@
+---
+title: Solution Design
+description: Learn how Professional Services can help you design and architect your Auth0 solution.
+toc: true
+topics:
+    - ps
+    - solution
+    - design
+contentType: concept
+useCase:
+  - solution-design
+---
+# Solution Design
+
+The first step in a successful implementation is designing and architecting your Identity and Access Management solution, and our Solution Design services are here to help. We work together with your product and engineering teams to **architect an Identity solution** for your environment and build an **incremental Go-Live plan** that solves the most-pressing identity problems early. Auth0 Professional Services help your project reach success quickly and address your business objectives in a pragmatic, step-by-step manner. 
+
+PS Solutions Architects have decades of combined industry expertise and Auth0-specific training. We have delivered **thousands of successful IAM projects and integrations**. Let us help you steer clear of costly security pitfalls and build a solid foundation for your identity needs, all while reducing risk.
+
+## Get to production faster
+
+We can consolidate all the enablement activities leading to a successful adoption into three major milestones or phases; the goal of a Professional Services engagement is to identify, document, and build consensus with you on these milestones as the path to successful Auth0 adoption: 
+
+* Solution discovery and architectural design
+* Initial Go-Live
+* Advanced Go-Live
+
+In the discovery phase, our Solution Architects will work with your teams to identify the core goals, features, and functionality that constitute your successful IAM implementation. We will also uncover any legacy architectural issues or design requirements that may need more careful consideration.
+
+The initial Go-Live milestone is designed to be impactful enough to make material differences in the overall Identity project. At the same time, it is limited enough that it can be reached quickly—ideally within 30 days of the project start—to keep the positive momentum. The initial Go-Live typically includes migration off a legacy Identity Provider (IdP), must-have features, and possibly a subset of all applications.
+
+The last milestone, Advanced Go-Live, can be broken into multiple sub-milestones, especially if you have multiple applications or development teams. This helps manage the complexity of a large project and achieves incremental and steady progress. 
+
+<%= include('./_includes/_further-help.md') %>
+
+## Keep reading
+
+* [Custom Implementation](/services/custom-implementation)
+* [Maintain and Improve](/services/maintain-and-improve)
+* [Packages](/services/packages)
+* [Gallery](/services/gallery)
diff --git a/ja-jp/articles/sessions/concepts/cookie-attributes.md b/ja-jp/articles/sessions/concepts/cookie-attributes.md
new file mode 100644
index 0000000000..72a9db75de
--- /dev/null
+++ b/ja-jp/articles/sessions/concepts/cookie-attributes.md
@@ -0,0 +1,128 @@
+---
+description: Understand how browser changes, such as the samesite cookie attribute, affects your web applications that embed content from third-party domains. 
+topics:
+  - saml
+  - identity-providers
+  - oidc
+  - cookies
+  - samesite
+  - google-chrome
+  - microsoft-edge
+contentType:
+  - concept
+useCase:
+  - third-party-content
+  - use-samesite-cookie-attribute
+  - maintain-browser-compatiblity
+---
+# sameSite Cookie Attributes
+
+Cookies, which are used for authentication and the maintenance of sessions, can be secured by setting its attributes.
+
+Auth0 uses cookies for the following:
+
+* OIDC Enterprise with `form_post`
+* SAML HTTP-POST Binding
+* Web message (aka `checkSession`)
+
+## The `sameSite` attribute
+
+The `sameSite` cookie attribute restricts browser behavior. It may prevent the browser from sending the cookie's key-value pair based on the type of interaction that triggered the HTTP request.
+
+Accepted attribute values are as follows:
+
+| Attribute | Description |
+| -- | -- |
+| `strict` | Send the cookie if the user is navigating within the website origin bounds it came from |
+| `lax` | Send the cookie if the user is navigating within the website origin bounds it came from or if they're being redirected to it |
+| `none` | Send the cookie with requests crossing the website origin bounds. Unless other conditions are present (i.e., third-party cookies are blocked), do not send the cookie. |
+
+Some of the cookie attributes you may be familiar with include:
+
+| Attribute | Description |
+| - | - |
+| `httpOnly` | Allows a cookie to be sent only with HTTP requests; not readable using Javascript's `document.cookie` |
+| `secure` | Allows the browser to send the cookie only to a secure context; whether the context is considered secure or not is browser-dependent, but this typically requires the use of HTTPS |
+| `max-age / expires` | Controls whether the cookie is a **session** cookie (e.g., dropped when your browser terminates its session) or **persistent** (e.g., the cookie persists beyond the browser session) |
+
+Please note that these attributes can also be provided by the server using the `set-cookie` headers included with HTTP responses. The browser, upon receipt, parses the headers and updates its cookie jar accordingly.
+
+## Changes Auth0 is making
+
+Effective February 2020, Google Chrome v80 will change the way it handles cookies. To that end, Auth0 plans on implementing the following changes to how it handles cookies:
+
+* Cookies without the `samesite` attribute set will be set to `lax`
+* Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar
+
+The goal of these changes are to improve security and help mitigate CSRF attacks.
+
+These changes affect the following cookies:
+
+* `auth0` (handles user sessions)
+* `auth0-mf` (handles information relevant to multi-factor authentication)
+* `did` (the identifier for a device/user agent)
+
+For these cookies, Auth0 will:
+
+* Set the `sameSite` attribute to `none`, with the cookie requiring the use of HTTPS (regardless of environment).
+* Set fallback cookies in the event that a legacy browser does not support `sameSite` being set to `None`. These fallback cookies are `auth0_compat`, `auth0-mf_compat` and `did_compat`.
+
+## Changes you need to make
+
+To prepare for this change, you should:
+
+* Review the list of [unsupported browsers](https://www.chromium.org/updates/same-site/incompatible-clients).
+
+* Set your application to use `sameSite=none` if it uses `response_mode=form_post` when interacting with Auth0 (note that Chrome makes no exceptions, even for `localhost`)
+
+* Set your cookie as secure if its `sameSite` attribute equals `None`, otherwise it will be rejected by the browser. If you use HTTP for your Callback URLs, these will break if you use such cookies for binding the authorization request state/nonce. Therefore, you must either use HTTPS or set `sameSite=lax`.
+
+## How this works
+
+The diagram below shows what happens during a fresh interaction.
+
+The end user requests a page they have not visited before. The server wishes to change the way it renders when the visitor returns so it sets a *seen* cookie. The grey part of the `set-cookie` header is the actual cookie key-value, the red portion are the cookie attributes the browser stores in its cookie jar to decide later if it should include the cookie key+value pair in its requests.
+
+![Fresh Interaction](/media/articles/sessions/cookie-fresh-interaction.png)
+
+The following diagram shows what happens if you make the same request using the same browsing session.
+
+The request goes to the same server, and because the cookie attributes don't prohibit the *seen* cookie to be sent, it is automatically included as a cookie header in the request. The server will now respond differently based on the fact that it received this cookie.
+
+![Fresh Interaction](/media/articles/sessions/cookie-return-interaction.png)
+
+## Effect of the changes to the `sameSite` cookie attribute
+
+The table below shows how the `sameSite` attribute changes may affect your apps.
+
+| App Behavior | Affected by Change |
+| -- | -- |
+| Cookies set as `sameSite=none` while the website is not `https://` | Yes |
+| Cookies don't have explicit `sameSite` attribute value set and are required in a cross-origin context (such as HTTP Form Post, embedding an iframe) | Yes |
+| Native apps (everything not cookies + web based) | No (M2M) |
+| Already setting an explicit `sameSite` cookie attribute value | No |
+| Different subdomain on the same eTLD+1 (app is on the same eTLD+1 as the custom domain Auth0 tenant) | Potentially |
+
+If you are using a web app with sessions (e.g. for saving user preferences, shopping carts, etc.), and you allow users to sign in using identity providers such as Google, Apple or Auth0, then you rely on cookies to achieve that functionality. There are browser cookie behavior changes that may break your user experience. Google Chrome, for example, is going to be the first browser vendor to roll out a change that might not be compatible with your web application.
+
+You may notice that the Google Chrome and Microsoft Edge specs for setting `sameSite` to undefined has changed from `sameSite` defaulting to `none` to `lax` instead. 
+
+For example, let's say you are building a new UI and have several services that you proxy to via an Auth0 gateway. At this gateway, you create a cookie session. If you make a cross-origin request, you may see this warning in the Javascript console:
+
+``` text
+A cookie associated with a cross-site resource (URL) was set without the SameSite attribute. 
+A future release of Chrome will only deliver cookies with cross-site requests if they are 
+set with SameSite=None and Secure. You can review cookies in developer tools under 
+Application>Storage>Cookies and see more details at 
+https://www.chromestatus.com/feature/5088147346030592 and 
+https://www.chromestatus.com/feature/5633521622188032
+```
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Web Apps vs Web APIs/Cookies vs Tokens](/design/web-apps-vs-web-apis-cookies-vs-tokens)
+* [Cross-Origin Authentication](/cross-origin-authentication)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Security](/security)
diff --git a/ja-jp/articles/sessions/concepts/cookies.md b/ja-jp/articles/sessions/concepts/cookies.md
new file mode 100644
index 0000000000..cf6ce50b56
--- /dev/null
+++ b/ja-jp/articles/sessions/concepts/cookies.md
@@ -0,0 +1,65 @@
+---
+title: Cookies
+description: Understand what cookies are and how they can be used with sessions to track user authentication.
+toc: true
+topics:
+  - cookies
+  - sessions
+  - authentication
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Cookies
+
+Cookies are strings of data that a web server sends to the browser. When a browser sends a future request to the web server, it sends the same string to the web server along with its request.
+
+Websites typically use cookies to ensure that users are recognized when they move between pages, so they don't get asked to log in again every time. Websites also use cookies to remember information users have entered. For example, e-commerce sites use cookies to remember the items placed in a shopping cart. 
+
+Users can choose whether to accept cookies by changing the settings in their browser.
+
+## Use cookies with authentication
+
+When you build an application that requires authentication, you can use [sessions](/sessions) and cookies to determine if a user is authenticated each time a request is made. To do this, you can choose to use either stateful or stateless cookies.
+
+### Stateful cookies
+
+Stateful cookies contain a pointer to a database record that stores the session information.
+
+**Pros**:
+
+* Have no limitations on amount of session information stored.
+* Can easily clear a user's session--just remove the record from the database.
+
+**Cons**:
+
+* Requires a database to store the session data (but most web applications already have this).
+* Increases latency because you have to make database calls to read the session (and sometimes write it) for each HTTP request a user makes.
+* Can be challenging to scale when you have many users and therefore many reads/writes to your database.
+
+### Stateless cookies
+
+Stateless cookies are self-contained; they include all session information that you need (for authenticated users, the user ID) and reside on the client. To prevent external tampering, stateless cookies should be encrypted (or at least signed).
+
+**Pros**:
+
+* Can implement easily; doesn’t require a special backend.
+* Reduces latency because you don't have to call a database.
+* Easy to scale.
+
+**Cons**:
+
+* Must restrict stored session information because cookies are limited in size (max 4KB in most browsers). Although session information may be split between multiple cookies, we don't recommend it.
+* Makes it difficult to revoke a session, because there is no record in a database you can delete; you’ll need to find other methods to forcefully clear a session.
+* If using multiple web servers, must make sure all servers have the key to encrypt/decrypt or sign the cookie.
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
diff --git a/ja-jp/articles/sessions/concepts/session-layers.md b/ja-jp/articles/sessions/concepts/session-layers.md
new file mode 100644
index 0000000000..d013992e1a
--- /dev/null
+++ b/ja-jp/articles/sessions/concepts/session-layers.md
@@ -0,0 +1,64 @@
+---
+description: Understand the differences between application, Auth0, and identity provider sessions and how logout works in the different sessions. 
+toc: true
+topics:
+  - sessions
+  - sso-session
+  - auth0-session
+  - idp-session
+  - application-session
+  - federated logout
+contentType: concept
+useCase:
+  - sessions
+  - session-logout
+  - session-lifetime
+  - using-cookies
+---
+
+# Session Layers
+
+There are typically three session layers that can be created when your users log in: 
+
+* **Application Session Layer**: This layer is the session inside your application. Though your application uses Auth0 to authenticate users, your application also tracks that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a [cookie](/sessions/concepts/cookies). 
+
+* **Auth0 Session Layer**: Auth0 also maintains a session on the Authorization Server for the user and stores their user information inside a cookie. This layer is used so that the next time a user is redirected to Auth0 for login the user's information will be remembered. This session layer makes the [Single Sign-On (SSO)](/sso) experience possible for [inbound SSO implementations](/sso/current/inbound).
+
+* **Identity Provider Session Layer**: When users attempt to sign in using an identity providers such as Facebook or Google, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in though they may be asked to give permission to share their information with Auth0 and, in turn, your application. See [How to set up IdP-initiated SSO](/protocols/saml/idp-initiated-sso#how-to-set-up-idp-initiated-sso) for more information. 
+
+## Session logout
+
+
    
+
+Logout in the context of Auth0 implementations is the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. 
+
+Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
+
+* **Application Session Layer Logout**: Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination. This will require you to utilize whatever application session stack you are using to clear out any session related information. Note that some of the Auth0 SDKs do provide some support for application sessions; please check the documentation to see if there is any local SDK session removal that needs to be done.
+
+* **Auth0 Session Layer Logout**: You can log users out of the Auth0 session layer by redirecting them to the Auth0 logout endpoint so Auth0 can clear the [Single Sign-on (SSO)](/sso) cookie.
+
+* **Identity Provider Session Layer Logout**: It is not necessary to log the users out of this session layer, but you can use Auth0 to force the logout if required. 
+
+### Redirect URLs
+
+Logging out of your Auth0 Session Layer will require you to redirect the user to `https:///v2/logout` - typically performed via use of the appropriate method in the Auth0 SDK for your technology stack. This will clear your Auth0 session. You will also want to add a query parameter for that request called `returnTo` - this parameter should contain a URL that has been pre-registered and protects you against open redirect attacks. For more information, see [Authentication API: Logout](/api/authentication?javascript#logout).
+
+Auth0 only redirects to whitelisted URLs after logout and there are two places you can configure these. The first place you can set this is at your Auth0 tenant level where you can put the set of logout URLs that are shared between all applications. The second place is in the application settings: if you need different redirects for each application, you can whitelist the URLs in your application settings. This allows you to set logout URLs in an application-specific context. 
+
+### Session lifetime and session timeout
+
+You can also set the behavior in cases where a user doesn’t explicitly logout of your application. Auth0 provides for [session lifetime limits](/sessions/concepts/session-lifetime) to deal with Auth0 session termination in this scenario. 
+
+### Federated logout
+
+Alternatively you may desire to also [log the users out of the Identity Provider Session Layer](/logout/guides/logout-idps). While this is not recommended, for many providers, Auth0 will give you this behavior by simply having you add the `federated` query parameter to the redirect to `/v2/logout`. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
+* [Auth0 Ruby on Rails SDK Quickstarts: Session Handling](/quickstart/webapp/rails/02-session-handling)
+* [Auth0 Android SDK Quickstarts: Session Handling](/quickstart/native/android/03-session-handling)
diff --git a/ja-jp/articles/sessions/concepts/session-lifetime.md b/ja-jp/articles/sessions/concepts/session-lifetime.md
new file mode 100644
index 0000000000..2ae61eecaa
--- /dev/null
+++ b/ja-jp/articles/sessions/concepts/session-lifetime.md
@@ -0,0 +1,71 @@
+---
+title: Session Lifetime
+description: Understand what session lifetimes are and learn about the relevant settings.
+topics:
+  - sessions
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Session Lifetime
+
+Session lifetime limits determine how long the system should retain a login session.  In Auth0, two settings can be configured for session lifetime:
+
+* **Inactivity timeout**: Timeframe after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 3 days for self-service plans or 100 days for enterprise plans.
+
+* **Require log in after**: Timeframe after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 30 days for self-service plans or 365 days for enterprise plans.
+
+These settings are configured on the [tenant](/getting-started/the-basics#account-and-tenants); you can [configure them](/dashboard/guides/tenants/configure-session-lifetime-settings) using either the Auth0 Dashboard or the Management API.
+
+## Application-specific logout URLs
+
+There are two important things to consider when you use application-specific logout URLs:
+
+* You **must** send `client_id` as a query parameter when calling the `/v2/logout` endpoint and the `returnTo` URL must be in the application’s list of allowed logout URLs.
+
+* This will end the Auth0 Session for the entire tenant - i.e. for all defined applications, not just the one that matches the `client_id` supplied. Passing the `client_id` tells the `logout` endpoint where to look for the logout URL white-list.
+
+After the user logout occurs Auth0 will only redirect to a URL that is defined in this list. 
+
+::: warning
+If you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out - and, if desired, you can also warn them that they may still be logged into their identity provider.
+:::
+
+In the case a user has not taken any actions that would cause the Auth0 session to be updated it is recommended that warning be raised to the user to choose to explicitly continue their session.
+
+The intent of this approach allows the session to go inactive if the user is no longer present, but otherwise provides a means to trigger the silent token refresh so that they can continue their session without the need to be prompted again for credentials.
+
+* **Inactivity Timer**: A rolling timer should be added to the React SDK wrapper that aligns with the maximum idle lifetime of the Auth0 session.  Each time a token is returned to the application the timer should be reset.
+
+* **Timeout Modal**: When the timer hits 60 seconds from expiration a timeout modal should render requesting the user to logout or continue their session. 
+
+    * **Continue the session**: In the case the user chooses to continue their session the getTokenSilently() method can be used to request a new token without needing to redirect the user from the page they are currently interacting with.
+
+    * **Logging out**: In the case the user chooses to logout the logout() method should be called to assure the Auth0 session is ended as well.
+
+    * **Idle Timeout**: In the case that the idle timeout is reached no immediate action is necessary.  To handle the fact that the user may still be active in another tab, the behavior **should not** be to log the user out. 
+
+    Other options might include updating the modal with a login button, using the window.onfocus event to trigger `getTokenSilently()`, or redirecting the user to landing page.
+
+## Examples: Session lifetime limits
+
+Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session. Let's look at an example.
+
+1. You set the **Inactivity timeout** limit to 3 days and the **Require log in after** limit to 30 days.
+2. A user logs in and your entered values are set for their session. 
+  * If the user is active within the three-day **Inactivity timeout** timeframe, the session lifetime is extended for another three days. As long as the user is active within the next three days, their session lifetime will be extended for another three days, until the **Require log in after** limit is reached. At this point, the user will be required to log in again.
+  * If the user is inactive for three days, they will automatically be logged out. 
+3. While the user is logged in, you extend the existing session lifetime limits. The new settings will not take effect until the existing session ends, and the user logs in again.
+4. While the user is logged in, you reduce the existing lifetime limits. The new settings will take effect immediately upon the user's next activity. This allows you to shorten session lifetimes for security purposes.
+
+## Keep reading
+
+* [Auth0 Privacy & Cookie Policy](https://auth0.com/privacy)
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
+* [Example: Short-lived session management workflow](/sessions/references/example-short-lived-session-mgmt)
+* [Auth0 Ruby on Rails SDK Quickstarts: Session Handling](/quickstart/webapp/rails/02-session-handling)
+* [Auth0 Android SDK Quickstarts: Session Handling](/quickstart/native/android/03-session-handling)
diff --git a/ja-jp/articles/sessions/index.md b/ja-jp/articles/sessions/index.md
new file mode 100644
index 0000000000..d653876353
--- /dev/null
+++ b/ja-jp/articles/sessions/index.md
@@ -0,0 +1,25 @@
+---
+title: Sessions
+classes: topic-page
+description: Understand what sessions are and how to implement them.
+topics:
+  - sessions
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Sessions
+
+A session is a group of interactions between a user and an application that take place within a given timeframe. A single session can contain multiple activities (such as page views, events, social interactions, and e-commerce transactions), all of which the session stores temporarily while the user is connected.
+
+By default, when a user leaves a website or closes their browser, their session ends. To keep users from having to log in every time they return, applications can extend sessions by storing session information in a cookie. Sessions end when a user logs out or when session lifetime limits are reached. Password resets cause Auth0 sessions to expire. 
+
+<%= include('../_includes/_topic-links', { links: [
+  'sessions/concepts/session-layers',
+  'sessions/concepts/session-lifetime',
+  'sessions/concepts/cookies',
+  'sessions/concepts/cookie-attributes',
+  'logout',
+  'sessions/references/sample-use-cases-sessions',
+  'sessions/references/example-short-lived-session-mgmt'
+ ] }) %>
diff --git a/ja-jp/articles/sessions/references/example-short-lived-session-mgmt.md b/ja-jp/articles/sessions/references/example-short-lived-session-mgmt.md
new file mode 100644
index 0000000000..4ad8a94cf1
--- /dev/null
+++ b/ja-jp/articles/sessions/references/example-short-lived-session-mgmt.md
@@ -0,0 +1,99 @@
+---
+description: Example workflow shows how the auth0-spa-js SDK should be implemented to support multi-site session management.
+toc: true
+topics:
+  - sessions
+  - sso-session
+  - auth0-session
+  - application-session
+contentType: concept
+useCase:
+  - application-session-workflow
+---
+
+# Example: Application Sessions and SSO Sessions Workflow
+
+This workflow shows how the `auth0-spa-js` SDK should be implemented to support multi-site session management.  In this scenario, it is assumed that the tenant SSO Inactivity Timeout is set to 300 seconds, and the ID Token Expiration of each SPA application is set to 150 seconds. This is considered a "short-lived" session. 
+
+::: panel Support for Long-Lived Sessions
+Auth0 supports long-lived sessions for enterprise Auth0 customers. With long-lived sessions, you can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout). If you have quarterly, monthly, or other timelines, this allows you to reduce friction for end-users and provide access to low-risk content and capabilities. In addition, media companies can leverage long-lived sessions for improving user experiences through seamless access to content. You can also make the choices between long-lived sessions and password validation based on your requirements around user experience and security. 
+
+Workflow details would change in the case of a long-lived session where the application session would most likely be shorter than the [Single Sign-on (SSO)](/sso) session.
+
+You can also see [Configure Session Lifetime Limits](/sso/current/configure-session-lifetime-limits) and [Update Access Token Lifetime](/dashboard/guides/apis/update-token-lifetime) for more information.
+:::
+
+## SDK features
+
+### PKCE flow
+
+For all methods of retrieving an ID Token or Access Token, the SDK manages all the intricacies of the Proof Key for Code Exchange workflow. No additional effort or configuration is needed for this to work.
+
+### Deep linking
+
+To improve the user experience the SDK includes an `appState` parameter for the `loginWithRedirect()` method. Details about the current app are packaged as part of the request to the Auth server that will be returned upon successful authentication. Allowing a seamless continuation of the user journey. 
+
+In the Quickstart, the `PrivateRoute` component sets a state parameter of `targetUrl` and the `onRedirectCallback` function of `index.js` unpacks this value to redirect the user when authentication is complete.
+
+### Token storage
+
+To keep the returned tokens stored in the safest manner possible all tokens are placed into a local cache. The ID and Access Tokens are stored as pairs with the audience and scope values being used to retrieve the tokens as needed.
+
+Additionally the cache tokens are removed once either the ID Token or Access Token expires so that if a token is in the cache it can be assumed to stil be valid.
+
+### Calling APIs
+
+The `getTokenSilently()` method is used to leverage the token cache first, and if none exists, will launch an invisible iframe to retrieve a new token.  For this purpose all requests to APIs can use this method to construct the bearer token header without the need for additional logic to handle for expired tokens.
+
+In the Quickstart, the `ExternalService` view makes a request to the express API using this feature.
+
+### Warn users to continue their sessions
+
+In the case where a user has not taken any actions that would cause the Auth0 session to be updated, Auth0 recommends that you raise a warning to the user to choose to explicitly continue their session.
+
+The intent of this approach allows the session to go inactive if the user is no longer present, but otherwise provides a means to trigger the silent token refresh so that the can continue their session without the need to be prompted again for credentials. 
+
+See [Application-specific logout URLs](/sessions/concepts/session-lifetime#application-specific-logout-urls) for more information about inactivity timers and timeout modals. 
+
+## Example workflow
+
+1. [Initial Authentication](#initial-authentication)
+2. [Maintaining Auth0 Session](#maintaining-auth0-session)
+3. [Seamless SSO](#seamless-sso)
+4. [Prompting user to extend session](#prompting-user-to-extend-session)
+5. [User explicitly logs out of application](#user-explicitly-logs-out-of-application)
+6. [User returns to initial app after logging out](#user-returns-to-initial-app-after-logging-out)
+
+### Initial authentication
+
+![Initial Authentication](/media/articles/sessions/initial-authentication.png)
+
+### Maintaining Auth0 session
+
+![Maintain Auth0 Session](/media/articles/sessions/maintain-auth0-session.png)
+
+### Seamless SSO
+
+![Seamless SSO](/media/articles/sessions/seamless-sso.png)
+
+### Prompting user to extend session
+
+![Prompting User to Extend Session](/media/articles/sessions/prompt-user-extend-session.png)
+
+### User explicitly logs out of application
+
+![User Explicitly Logs Out of Application](/media/articles/sessions/user-explicitly-logs-out-of-app.png)
+
+### User returns to initial application after logging out
+
+![User Returns to Initial Application After Logging Out](/media/articles/sessions/user-returns-to-initial-app.png)
+
+## Keep reading
+
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Cookies](/sessions/concepts/cookies)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [Logout](/logout)
+* [Session Use Cases](/sessions/references/sample-use-cases-sessions)
diff --git a/ja-jp/articles/sessions/references/sample-use-cases-sessions.md b/ja-jp/articles/sessions/references/sample-use-cases-sessions.md
new file mode 100644
index 0000000000..d6757b2d36
--- /dev/null
+++ b/ja-jp/articles/sessions/references/sample-use-cases-sessions.md
@@ -0,0 +1,103 @@
+---
+description: Explore sample use cases to understand how sessions work with authentication in Auth0.
+topics:
+  - sessions
+  - sample-use-case
+contentType: concept
+useCase:
+  - build-an-app
+---
+# Session Use Cases
+
+## For SPAs using Authorization Code grant
+
+Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session.
+
+When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. These examples are for SPAs that have a lightweight backend and are using the Authorization Code grant (also, native apps and regular web apps. 
+
+Let's say you've built an OIDC-compliant e-commerce website called Storezero.io. 
+
+![View Sample Web Site: Storezero.io](/media/articles/sessions/use-case-storezero.png)
+
+When checking out, a user can optionally log in to the site, but to view the "My Account" pages, the user _must_ log in.
+
+Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
+
+### User logs in with username and password
+
+1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session, then redirects the user to the login and authorization prompt.
+3. The user authenticates using their username and password and may see a consent page listing the permissions Auth0 will give to the application.
+4. Your Auth0 Authorization Server updates the previously-created session to indicate that the user is logged in.
+5. Your Auth0 Authorization Server redirects the user back to the application, along with either an ID Token or code (depending on which flow that you use).
+6. The application authenticates the user and creates a local session.
+
+Two sessions are created:
+
+* The local session (storezero.io): Allows the application to know if a user is authenticated.
+
+* The session on the Authorization Server (storezero.auth0.com): Allows the Authorization Server to know if a user is authenticated and optionally, tracks other information. For example, the Authorization Server can track whether a user has authenticated using [Multi-factor Authentication (MFA)](/mfa). If so, the next time the user arrives at the Authorization Server, they won't need to see a login page or be prompted to use MFA again.
+
+### User logs in with identity provider
+
+Let's say that instead of using their username and password, the user decides to log in with Facebook. 
+
+1. Auth0's SDK creates a local session and redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session.
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user chooses to log in with Facebook. 
+5. Your Auth0 Authorization Server redirects the user to Facebook's server.
+6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.
+7. Facebook redirects the user back to the Authorization Server, where the Authorization Server updates its session to indicate that the user is logged in.
+8. The Authorization Server redirects the user back to the application, along with either an ID Token or code (depending on which flow you use).
+9. The application authenticates the user and updates it's local session to indicate that the user is logged in.
+
+In addition to the two sessions created in the previous example, a third session is created:
+
+* The session on Facebook's server (facebook.com): Allows Facebook to know if the user is authenticated and if so, provides a [Single Sign-on (SSO)](/sso) experience for the user. Since there’s a high probability that the user is already logged in to Facebook, if they choose to log in to storezero.io using Facebook, they will likely not be prompted to enter their credentials.
+
+## For SPAs with no backend using the Implicit grant
+
+When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. This example is accurate for SPAs that have no backend and are using the Implicit grant. 
+
+Let's say you've built an OIDC-compliant e-commerce website called Storezero.io. 
+
+![View Sample Web Site: Storezero.io](/media/articles/sessions/use-case-storezero.png)
+
+When checking out, a user can optionally log in to the site, but to view the "My Account" pages, the user _must_ log in.
+
+Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
+
+### User logs in with identity provider
+
+Let's say that the user decides to log in with Facebook. 
+
+1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
+2. Your Auth0 Authorization Server creates a session.
+3. Your Auth0 Authorization Server redirects the user to the login prompt.
+4. The user chooses to log in with Facebook. 
+5. Your Auth0 Authorization Server redirects the user to Facebook's server.
+6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.
+7. Facebook redirects the user back to the Authorization Server, where the Authorization Server updates its session to indicate that the user is logged in.
+8. The Authorization Server redirects the user back to the application, passing an ID Token and Access Token.
+9. The application authenticates the user.
+
+Since we are using the Implicit Grant, the client (storezero.io) can consume the ID Token to authenticate the user and can use the Access Token to interact with the API (until it expires). So no local session is created to keep the user logged in.
+
+### Keep the user logged in without a local session
+
+Since we have no local session to keep the user logged in, we can use the session on the Authorization Server to determine whether to force the user to reauthenticate. We do this through [Silent Authentication](/api-auth/tutorials/silent-authentication).
+
+We create a hidden iframe that redirects to the Authorization Server adding the `prompt=none` parameter, which tells the server not to prompt the user for any input. If the session on the Authorization Server has not expired, the transaction continues seamlessly, and the client gets a new Access Token through WMRM (Web Message Response Mode), which leverages postMessage.
+
+If the session on the Authorization Server has expired or the user logs out, the redirect in the iframe will return an error, indicating that the application needs to redirect the user to the Authorization Server to reauthenticate.
+
+## Keep reading
+
+* [Sessions](/sessions)
+* [Session Layers](/sessions/concepts/session-layers)
+* [Cookies](/sessions/concepts/cookies)
+* [sameSite Cookie Attributes](/sessions/concepts/cookie-attributes)
+* [Session Lifetime](/sessions/concepts/session-lifetime)
+* [Logout](/logout)
+* [Example: Application Sessions and SSO Sessions Workflow](/sessions/references/example-short-lived-session-mgmt)
diff --git a/ja-jp/articles/sso/current/inbound.md b/ja-jp/articles/sso/current/inbound.md
new file mode 100644
index 0000000000..3533e94697
--- /dev/null
+++ b/ja-jp/articles/sso/current/inbound.md
@@ -0,0 +1,49 @@
+---
+title: Inbound Single Sign-On
+description: Overview of Inbound Single Sign-on (SSO).
+toc: true
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Inbound Single Sign-On
+
+For inbound Single Sign-On (SSO) implementations, Auth0 is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application presents the user with one or more external identity providers.
+2. The user selects an identity provider to authenticate with and logs in.
+3. Upon successful authentication, the user is returned to the application with an active session.
+
+Inbound SSO in Auth0 is handled by [connections](/connections).
+
+## Auth0 SSO sessions vs. Application sessions
+
+When users log in, various [session layers](/sessions/concepts/session-layers) can be created. For inbound SSO implementations, it's important to understand that the SSO experience is made possible by the Auth0 Session Layer, which is stored centrally on the Authorization Server. Leveraging this session layer, users can easily authenticate to different applications, each of which may have its own application session to track whether the user is logged into it specifically. 
+
+For an example of session usage with SSO, see [Example: Application Sessions and SSO Sessions Workflow](/sessions/references/example-short-lived-session-mgmt).
+
+## Build-Your-Own Implementations
+
+## OIDC/OAuth
+
+* [Social Identity Providers](/connections#social)
+* [Add a generic OAuth2 Authorization Server to Auth0](/connections/social/oauth2)
+* [Custom Social Connections Extension](/extensions/custom-social-extensions)
+
+## SAML
+
+* [SAML Identity Providers](/protocols/saml/identity-providers)
+* [Auth0 as Service Provider](/protocols/saml/saml-sp-generic)
+* [IdP-Initiated Single Sign-On](/protocols/saml/idp-initiated-sso)
+
+## Limitations
+
+* Native applications can only use [Universal Login](/universal-login).
+* [OpenID Connect (OIDC)](/protocols/oidc) does not support identity provider-initiated SSO.
\ No newline at end of file
diff --git a/ja-jp/articles/sso/current/index.md b/ja-jp/articles/sso/current/index.md
new file mode 100644
index 0000000000..5ca58fe4e8
--- /dev/null
+++ b/ja-jp/articles/sso/current/index.md
@@ -0,0 +1,115 @@
+---
+title: Single Sign-On
+description: Overview of what Single Sign-on (SSO) is and how it works.
+toc: true
+topics:
+  - sso
+  - authentication
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Single Sign-On
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on).
+
+For example, if you login to a Google service such as Gmail, you are automatically authenticated to YouTube, AdSense, Google Analytics, and other Google apps. Likewise, if you log out of your Gmail or other Google apps, you are automatically logged out of all the apps; this is known as Single Logout.
+
+## Benefits
+
+SSO provides a seamless experience for users when using your applications and services. Instead of having to remember separate sets of credentials for each application or service, users can simply login once and access your full suite of applications.
+
+## User experience
+
+Whenever users go to a domain that requires authentication, they are redirected to the authentication domain where they may be asked to log in. If the user is already logged in at the authentication domain, they can be immediately redirected to the original domain without signing in again.
+
+## How it works
+
+Single Sign-on and Single Logout are possible through the use of [sessions](/sessions). There may be up to three different sessions for a user with SSO:
+
+* Local session maintained by the application
+* Authorization Server session, if SSO is enabled
+* Identity Provider session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)
+
+With SSO, a central domain performs authentication and then shares the session with other domains. The way a session is shared may differ between SSO protocols, but the general concept is the same.
+
+For example, the authentication domain may generate a signed [JSON Web Token (JWT)](/tokens/concepts/jwts) (encrypted using JSON Web Encryption (JWE)), which contains all the information needed to identify the user for any other domain requiring authentication. This token is passed to the client, but because it is signed, it cannot be modified in any way by the client. The token can be passed to the original domain by a redirect and used by the authentication domain and any other domains to identify the user.
+
+## Protocols
+
+### Security Assertion Markup Language & Web Services Federation
+
+[Security Assertion Markup Language (SAML)](/protocols/saml) and [Web Services Federation (WS-Fed)](/protocols/ws-fed) are both protocols that are widely used in SSO implementations. Both SAML and WS-Fed exchange authorization and authentication data in XML format; the main parts of this exchange are the user, the identity provider, and the service provider.
+
+With SAML or WS-Fed:
+
+1. A user requests a resource from the service provider.
+2. The service provider checks with the identity provider to see if the user should have access to the resource. 
+3. The identity provider verifies the user's identity, and if valid, asserts back to the service provider that the user should have access.
+
+### OpenID Connect
+
+[OpenID Connect (OIDC)](/protocols/oidc) is an authentication protocol commonly used in consumer-facing SSO implementations. The OIDC protocol handles authentication through [JSON Web Tokens](/tokens/concepts/jwts) and a central identity provider.
+
+With OIDC:
+
+1. A user requests access to an application.
+2. The application redirects the user to the identity provider for authentication.
+3. The identity provider verifies the user, and if successful, prompts the user to grant data access to the application.
+4. If access is granted, the identity provider generates an ID Token, which contains user identity information that the application can consume. 
+5. The identity provider returns the user to the application.
+
+### Lightweight Directory Access Protocol + Active Directory
+
+[Lightweight Directory Access Protocol (LDAP)](/protocols/ldap) is an application protocol used to access a directory of credentials that can be shared by multiple applications; it is commonly used by intranets. When paired with Active Directory (AD), LDAP provides a centralized location for user identity, so the application makes an authentication request to the LDAP/AD server. The LDAP protocol exchanges information in LDAP Data Interchange Format (LDIF).
+
+## Inbound SSO
+
+For [inbound SSO](/sso/current/inbound), Auth0 is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application presents the user with one or more external identity providers.
+2. The user selects an identity provider to authenticate with and logs in.
+3. Upon successful authentication, the user is returned to the application.
+
+Inbound SSO in Auth0 is handled by [connections](/connections).
+
+## Outbound SSO
+
+For [outbound SSO](/sso/current/outbound), a third-party identity provider is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application redirects the user to an identity provider.
+2. The third-party identity provider performs authentication and authorization.
+3. Upon successful authentication, the user is returned to the application.
+
+### Auth0's SSO Dashboard Extension
+
+When planning an outbound SSO implementation, you may choose to use Auth0's [SSO Dashboard Extension](/extensions/sso-dashboard), which allows you to create a dashboard that lists multiple enterprise applications that can be enabled for SSO. This dashboard is then presented to your users to log in.
+
+## Use Cases
+
+For examples and implementation guides, check out our [Architecture Scenarios](/architecture-scenarios).
+
+### Business to Business
+
+For Business to Business (B2B) scenarios, SSO can simplify packaging your application for enterprise consumption. With Auth0 your applications can support common enterprise federation scenarios such as Active Directory, Lightweight Directory Access Protocol (LDAP), Ping, or Security Assertion Markup Language (SAML). This allows your partners and enterprise customers to login with their preferred enterprise identity technologies.
+
+* [Case Study: Safari](https://auth0.com/learn/safari-case-study/)
+
+### Business to Consumer / Customer Identity Access Management
+
+For Business to Consumer (B2C) or Customer Identity Access Management (CIAM) scenarios, SSO can provide frictionless access to your applications or services. You can let customers authenticate through popular social identity providers such as Google, Facebook, LinkedIn, Twitter, and Microsoft instead of requiring them to make another account.
+
+* [Case Study: Giving Compass](https://auth0.com/learn/giving-compass-case-study/)
+
+### Business to Employees
+
+For Business to Employees (B2E) scenarios, SSO can simplify the provisioning and management of employee credentials. Instead of keeping track of credentials for each and every service, employees can login once and gain access to everything they need. And if an employee leaves, deprovisioning a single account is much easier.
+
+* [Case Study: Schneider Electric](https://auth0.com/learn/schneider-electric-case-study/)
\ No newline at end of file
diff --git a/ja-jp/articles/sso/current/index_old.md b/ja-jp/articles/sso/current/index_old.md
new file mode 100644
index 0000000000..065b76fe02
--- /dev/null
+++ b/ja-jp/articles/sso/current/index_old.md
@@ -0,0 +1,43 @@
+---
+title: Single Sign-On and Single Logout
+description: Learn about Single Sign-on (SSO) and Single Logout
+classes: topic-page
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Single Sign-On and Single Logout
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on).
+
+Similarly, Single Logout occurs when you terminate the session of each application or service where a user is logged in. For more info, see [Logout](/logout).
+
+Single Sign-on and Single Logout are possible through the use of [sessions](/sessions). There may be up to three different layers of sessions for a user with SSO:
+
+* Local session maintained by the application
+* Authorization Server session, if SSO is enabled
+* Identity Provider session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)
+
+## Single Sign-on and Single Logout Example
+
+Google's implementation of login for their products, such as Gmail, YouTube, and Google Analytics, is an example of SSO. Any user that logs in to one of Google's products is automatically logged in to their other products as well.
+
+SSO usually makes use of a **Central Service** to orchestrate the single sign-on between multiple applications. For Google, this central service is [Google Accounts](https://accounts.google.com). When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services:
+
+1. The user accesses the first Google product, which redirects them to Google Accounts, where the user logs in and receives a Google Accounts-generated cookie.
+2. The user navigates to another Google product, which again redirects them to Google Accounts.
+3. Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product without requiring reauthentication.
+
+When the user logs out from one Google product, they are automatially also logged out from all other Google products.
+
+## Keep reading
+
+- [Understand how Single Sign-On works with Auth0](/sso/current/sso-auth0)
+- Learn how to [enable SSO in Auth0](/dashboard/guides/tenants/enable-sso-tenant)
+- [Understand session lifetime](/sessions/concepts/session-lifetime)
+- Learn how to [configure session lifetime settings](/dashboard/guides/tenants/configure-session-lifetime-settings)
+- Learn how to [log users out](/logout)
\ No newline at end of file
diff --git a/ja-jp/articles/sso/current/outbound.md b/ja-jp/articles/sso/current/outbound.md
new file mode 100644
index 0000000000..e2b83c2d38
--- /dev/null
+++ b/ja-jp/articles/sso/current/outbound.md
@@ -0,0 +1,55 @@
+---
+title: Outbound Single Sign-On
+description: Overview of Outbound Single Sign-on (SSO).
+toc: true
+topics:
+  - sso
+contentType:
+  - index
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Outbound Single Sign-On
+
+For outbound [Single Sign-On (SSO)](/sso), a third-party [Identity Provider (IdP)](/identityproviders) is the SSO provider. 
+
+When a user logs in to an application:
+
+1. The application redirects the user to an identity provider.
+2. The third-party identity provider performs authentication and authorization.
+3. Upon successful authentication, the user is returned to the application.
+
+## Pre-Defined Integrations
+
+Auth0 provides outbound [SSO Integrations](/integrations/sso) for the following services:
+
+- [Active Directory RMS](/integrations/sso/ad-rms)
+- [Box](/integrations/sso/box)
+- [CloudBees](/integrations/sso/cloudbees)
+- [Concur](/integrations/sso/concur)
+- [Disqus](/integrations/sso/disqus)
+- [Dropbox](/integrations/sso/dropbox)
+- [Microsoft Dynamics CRM](/integrations/sso/dynamics-crm)
+- [Adobe Echosign](/integrations/sso/echosign)
+- [Egnyte](/integrations/sso/egnyte)
+- [New Relic](/integrations/sso/new-relic)
+- [Office 365](/integrations/sso/office-365)
+- [Salesforce](/integrations/sso/salesforce)
+- [SharePoint](/integrations/sso/sharepoint)
+- [Slack](/integrations/sso/slack)
+- [SpringCM](/integrations/sso/springcm)
+- [Zendesk](/integrations/sso/zendesk)
+- [Zoom](/integrations/sso/zoom)
+
+## Build-Your-Own Implementations
+
+## SAML
+
+* [SAML Identity Provider Configuration](/protocols/saml/samlp)
+
+## OIDC
+
+* [Configure Okta as an OpenID Connect Identity Provider](/protocols/oidc/identity-providers/okta)
+
diff --git a/ja-jp/articles/sso/current/relevant-api-endpoints.md b/ja-jp/articles/sso/current/relevant-api-endpoints.md
new file mode 100644
index 0000000000..fb6e10f24f
--- /dev/null
+++ b/ja-jp/articles/sso/current/relevant-api-endpoints.md
@@ -0,0 +1,67 @@
+---
+title: Relevant API Endpoints for Single Sign-On
+description: Learn about Auth0 Authentication API and Management API endpoints that are relevant when implementing Single Sign-on (SSO).
+topics:
+    - sso
+    - api
+contentType: reference
+useCase: sso
+---
+# Relevant API Endpoints for Single Sign-On
+
+When implementing [Single Sign-on (SS0)](/sso) and configuring its settings, the following API endpoints will be helpful to you.
+
+## Authentication API
+
+### POST /login/callback
+
+For SSO flows initiated by an [Identity Provider (IdP)](/identityproviders), the [POST /login/callback](/api/authentication#idp-initiated-single-sign-on-sso-flow) endpoint can accept a sign-on SAML request from the IdP.
+
+## Management API
+
+The Management API features several endpoints designed to help you manage SSO.
+
+To call any of the Management API endpoints, you will need to [obtain an Access Token](/api/management/v2/tokens).
+
+### Clients
+
+All of your client applications/SSO integrations feature information relevant to your SSO implementation. You can retrieve or change this information by calling one of the Clients endpoints. 
+
+Of-interest parameters for each client include:
+
+* `sso`: Flag applicable only for clients created via SSO integrations. If `true`, Auth0 handles SSO; if `false`, the IdP handles SSO.
+
+* `sso_disabled`: Flag used to enable/disable SSO. If `true`, then SSO is disabled; if `false`, SSO is enabled. This option can only be set via the Management API.
+
+* `app_type`: Application type. If the client was created using one of Auth0's built-in SSO integrations, the name of the SSO integration would be listed (e.g., `box` or `concur` instead of `native` or `spa`)
+
+#### Get all clients
+
+The [GET /api/v2/clients](/api/management/v2#!/Clients/get_clients) endpoint can be used to return information about the client applications you have configured for your tenant.
+
+#### Create a client
+
+The [POST /api/v2/clients](/api/management/v2#!/Clients/post_clients) endpoint can be used to create a new client application.
+
+#### Get a client
+
+The [GET /api/v2/clients/{id}](/api/management/v2#!/Clients/get_clients_by_id) endpoint can be used to return information about a specific client you have configured for your tenant.
+
+#### Update a client
+
+The [PATCH /api/v2/clients/{id}](/api/management/v2#!/Clients/patch_clients_by_id) endpoint can be used to update a specific client, including its SSO-related parameters.
+
+### Tenants
+
+Auth0 allows you to control the following tenant-level parameters that may affect your SSO implementation:
+
+* `session_lifetime`: Length of time for which the user's Auth0 session will stay valid.
+* `idle_session_lifetime`: Amount of time that may elapse before the user must sign in again due to inactivity.
+
+### Get tenant settings
+
+The [GET /api/v2/tenants/settings](/api/management/v2#!/Tenants/get_settings) endpoint retrieves the settings for your tenant.
+
+### Update tenant settings
+
+The [POST /api/v2/connections](/api/management/v2#!/Tenants/patch_settings) endpoint allows you to update your tenant settings.
\ No newline at end of file
diff --git a/ja-jp/articles/sso/current/sso-auth0.md b/ja-jp/articles/sso/current/sso-auth0.md
new file mode 100644
index 0000000000..fa8aef4898
--- /dev/null
+++ b/ja-jp/articles/sso/current/sso-auth0.md
@@ -0,0 +1,50 @@
+---
+title: Single Sign-On with Auth0
+description: Learn how Single Sign-on (SSO) works with Auth0.
+toc: true
+topics:
+  - sso
+contentType:
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Single Sign-On with Auth0
+
+The easiest and most secure way to implement Single Sign-on (SSO) with Auth0 is by using [Universal Login](/universal-login) for authentication. In fact, currently SSO is only possible with native platforms (like iOS or Android) if the application uses Universal Login. The [Swift](/quickstart/native/ios-swift/00-login) and [Android](/quickstart/native/android/00-login) quickstarts provide some examples of using Universal Login.
+
+If you cannot use Universal Login with your application, review the following for additional info on embedded authentication:
+
+* [Lock](/libraries/lock)
+* [Auth0.js](/libraries/auth0js)
+
+## SSO on first login
+
+For SSO with Auth0, the **Central Service** is the Auth0 Authorization Server.
+
+Let's look at an example of the SSO flow when a user logs in for the first time:
+
+1. Your application redirects the user to the login page.
+2. Auth0 checks to see whether there is an existing SSO cookie.
+3. Because this is the first time the user is visiting the login page and no SSO cookie is present, the user will be asked to log in using one of the [connections](/connections) you have configured.
+
+![](/media/articles/sso/single-sign-on/lock-no-sso-cookie.png)
+
+4. Once the user has logged in, Auth0 will set an SSO cookie and redirect the user to your application, returning an ID Token that contains identity information for the user.
+
+## SSO on subsequent logins
+
+Let's look at an example of the SSO flow when a user returns to your website for a subsequent visit:
+
+1. Your application redirects the user to the login page.
+2. Auth0 checks to see whether there is an existing SSO cookie.
+3. Auth0 finds the SSO cookie, and if necessary, updates it. No login screen is shown.
+4. Auth0 redirects the user to your application, returning an ID Token that contains identity information for the user.
+
+## Check a user's SSO status 
+
+You can check a user's SSO status from an application by calling the `checkSession` method of the `auth0.js` SDK, which will attempt to [silently authenticate](/api-auth/tutorials/silent-authentication) the user within an iframe. Whether the authentication is successful or not indicates whether the user has an active SSO [cookie](/sessions/concepts/cookies).
+
+## Keep reading
+
+- Learn how to [enable SSO in Auth0](/dashboard/guides/tenants/enable-sso-tenant).
\ No newline at end of file
diff --git a/ja-jp/articles/sso/index.yml b/ja-jp/articles/sso/index.yml
new file mode 100644
index 0000000000..3fc1f73b02
--- /dev/null
+++ b/ja-jp/articles/sso/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: sso
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/ja-jp/articles/sso/legacy/index.md b/ja-jp/articles/sso/legacy/index.md
new file mode 100644
index 0000000000..8283021d59
--- /dev/null
+++ b/ja-jp/articles/sso/legacy/index.md
@@ -0,0 +1,107 @@
+---
+toc: true
+description: Introduction to Single Sign-on (SSO) with Auth0.
+topics:
+  - sso
+contentType:
+  - index
+useCase:
+  - integrate-saas-sso
+---
+# What is Single Sign-On?
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time hence the naming of the feature (Single Sign-on).
+
+Google's implementation of login for their products, such as Gmail, YouTube, Google Analytics, and so on, is an example of SSO. Any user that is logged in to one of Google's products are automatically logged in to their other products as well.
+
+SSO usually makes use of a *Central Service* which orchestrates the single sign-on between multiple applications. In the example of Google, this central service is [Google Accounts](https://accounts.google.com). When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services. The process flow is as follows:
+
+1. The user accesses the first Google product.
+2. The user receives a Google Accounts-generated cookie.
+3. The user navigates to another Google product.
+4. The user is redirected again to Google Accounts.
+5. Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
+
+## An overview of how SSO works with Auth0
+
+In the case of SSO with Auth0, the *Central Service* is the Auth0 Authorization Server.
+
+Let's look at how the SSO flow looks when using Auth0 and a user visits your application for the first time:
+
+1. Your application will redirect the user to the Auth0 Hosted Lock page where they can log in.
+2. Auth0 will check to see whether there is an existing SSO cookie.
+3. Because this is the first time the user visits this Hosted Lock page, and no SSO cookie is present, they may be presented with username and password fields and also possibly some Social Identity Providers such as LinkedIn, GitHub, and so on (The exact layout of the Lock screen will depend on the [Identity Providers](/identityproviders) you have configured.
+
+    ![](/media/articles/sso/single-sign-on/lock-no-sso-cookie.png)
+
+4. Once the user has logged in, Auth0 will set an SSO cookie
+5. Auth0 will also redirect back to your web application and will return an ID Token containing the identity of the user.
+
+Now let's look at flow when the user returns to your website for a subsequent visit:
+
+1. Your application will redirect the user to the Auth0 Hosted Lock page where they can sign in.
+2. Auth0 will check to see whether there is an existing SSO cookie.
+3. This time Auth0 finds an SSO cookie and instead of displaying the normal Lock screen with the username and password fields, it will display a Lock screen which indicates that we know you the user is, as they have already logged in before. They can simply confirm that they want to log in with that same account.
+
+    ![](/media/articles/sso/single-sign-on/lock-sso-cookie.png)
+
+4. Auth0 will update the SSO cookie if required
+5. Auth0 will also redirect back to your web application and will return an ID Token containing the identity of the user.
+
+If an SSO cookie is present you can also sign the user in silently, that is, without even displaying Lock so they can enter their credentials. This is covered in more detail in the next section.
+
+## How to Implement SSO with Auth0
+
+::: note
+Prior to enabling SSO for a given Application, you must first [configure the Identity Provider(s)](/identityproviders) you want to use.
+:::
+
+To configure SSO for one of your Applications (recall that each Application is independent of one another), navigate to the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications). Click on **Settings** (represented by the gear icon) for the Application with which you want to use SSO.
+
+![](/media/articles/sso/single-sign-on/clients-dashboard.png)
+
+Near the bottom of the *Settings* page, toggle **Use Auth0 instead of the IdP to do Single Sign-on**.
+
+![](/media/articles/sso/single-sign-on/sso-flag.png)
+
+Alternatively you can also set the Application's SSO flag using the [Auth0 Management API](/api/management/v2#!/Clients/patch_clients_by_id).
+
+Once you have set the SSO flag for your Application in the Auth0 Dashboard, you must add logic to your application to check the user's SSO status. Checking the user's SSO status can only be done via JavaScript by making use of the [`getSSOData`](/libraries/auth0js#sso) function in the [auth0.js library](/libraries/auth0js).
+
+The result of this function will indicate whether an SSO cookie is present, and if so it will return the SSO data of the user which can then subsequently be used to log the user in silently without even displaying Lock.
+
+For more detailed information on how to implement this, please refer to the following documents:
+
+* [Client-Side SSO (Single-Page Apps)](/sso/legacy/single-page-apps-sso)
+* [Server-Side SSO (Regular Web Apps)](/sso/legacy/regular-web-apps-sso)
+
+::: note
+Please see the [Auth0 SSO Sample](https://github.com/auth0/auth0-sso-sample) repo for an example of SSO with both Single-Page Apps and Regular Web Apps.
+:::
+
+### Length of SSO Sessions
+
+If the SSO flag is set for an application, Auth0 will maintain an SSO session for any user authenticating via that Application. If the user remains active, the session will last no more than **7 days**, but if not, the session will terminate after **3 days**. To be considered active, the user must access the Application that created the session within the given timeframe.
+
+## What is Single Logout?
+
+Single Logout is the process where you terminate the session of each application or service where the user is logged in. To continue with the Google example, if you logout from Gmail, you get logged out also from YouTube, Google Analytics, and so on.
+
+There may be up to three different layers of sessions for a user with SSO.
+
+* A session from an Identity Provider such as Google, Facebook or an enterprise SAML Identity Provider
+* A session from Auth0 if the above SSO flag is turned on
+* A session maintained by an application
+
+See the [Logout URL docs](/logout) for information on terminating the first two sessions listed above.
+
+## Using Social Identity Providers
+
+SSO works with Social Identity Providers given the following conditions:
+
+1. You need to enable "Use Auth0 instead of the IdP to do Single Sign-on" when configuring the Application
+2. Your social connection can not be using the developer keys. You will need to register an app in the relevant social provider and then use that Client ID and Client Secret when configuring the connection. You can read more about the [caveats of using the Auth0 developer keys](/connections/social/devkeys#caveats).
diff --git a/ja-jp/articles/sso/legacy/regular-web-apps-sso.md b/ja-jp/articles/sso/legacy/regular-web-apps-sso.md
new file mode 100644
index 0000000000..3f8fc043fc
--- /dev/null
+++ b/ja-jp/articles/sso/legacy/regular-web-apps-sso.md
@@ -0,0 +1,123 @@
+---
+toc: true
+description: Server-side Single Sign-on (SSO) with regular web applications.
+topics:
+  - sso
+  - web-apps
+contentType:
+  - how-to
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+
+# Server-side Single Sign-On (Regular Web Apps)
+
+To log a user in silently (that is, without displaying the Lock screen) the following conditions need to be met:
+
+1. The Application needs to be configured to **Use Auth0 instead of the IdP to do Single Sign-on** in the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications)
+2. A Single Sign-on (SSO) cookie must exist for the tenant's domain. In other words the user must have signed in previously, and the SSO cookie which was saved is still valid.
+3. When calling the Auth0 authentication endpoint, the connection name is passed along for which the user must be signed in. This connection name is the same as the one specified in the SSO cookie. You can pass the connection name along either as a parameter when calling the `signin` function of the [**auth0.js** Library](https://auth0.com/docs/libraries/auth0js), or by passing the `connection` query string parameter when calling the `/authorize` endpoint of the [Authentication API](/api/authentication)
+
+## The SSO scenario
+
+In our SSO scenario, let's say we have 3 applications
+
+* App 1: app1.com (Single-Page App)
+* App 2: app2.com (Single-Page App)
+* App 3: app3.com (Regular Web app)
+
+If a user logs in to any of these applications, and then subsequently navigates from this application to any of the other applications, we would want the user to be logged in automatically.
+
+In this document we will be looking specifically how to achieve this in a Regular Web Application
+
+## Case 1: The user is already logged in and clicks on a link that redirects to a specific URL app3.com
+
+The user logs in on one of the Single-Page Applications and click on a link that should take them to a particular URL on app3.com. In this case, you can create an endpoint on the target application (app3) that will redirect to the URL the user wanted to go after SSO. For example:
+
+```text
+https://app3.com/sso?targetUrl=/foo/bar&connection=CONNECTION_NAME
+```
+
+This endpoint would check if the user is already logged in to this app. If they are, then redirect to the target URL. If the user is not logged in to the application, then redirect to Auth0 for SSO, passing along the name of the connection to use:
+
+```text
+handle("/sso")
+  if (user is already logged in)
+    redirect to targetUrl
+  else
+    redirect to "https://${account.namespace}/authorize?client_id=${account.clientId}&connection=CONNECTION_NAME&redirect_uri=${account.callback}&response_type=code&state=' + targetUrl
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/sso', function(req,res, next) {
+  if (req.isAuthenticated()) {
+    if (/^http/.test(req.query.targetUrl)) return res.send(400, "url must be relative");
+    // Here we'd redirect to req.query.targetUrl like following
+    // res.redirect(req.query.targetUrl);
+    // But in this case we'll go to User anyway
+    res.redirect('/user?targetUrl=' + req.query.targetUrl);
+  } else {
+    console.log("Authenticating with Auth0 for SSO");
+    passport.authenticate('auth0', {
+      state: req.query.targetUrl,
+      connection: req.query.connection
+    })(req, res, next);
+  }
+});
+```
+
+When the user comes back from Auth0 you should check for the `state` parameter and redirect to the original target URL.
+
+```js
+handle("/callback")
+  // process login with SDK
+  if (state) redirect to url on state parameter
+  else redirect to base logged in URL
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/callback',
+    passport.authenticate('auth0'),
+    function(req, res) {
+      if (req.query.state) {
+        res.redirect(req.query.state);
+      } else {
+        res.redirect("/user");
+      }
+    });
+```
+
+## Case 2: The user is already logged in and goes to app3.com
+
+The user is logged in on app1.com and opens a new tab and goes to app3.com. You would expect the user to be automatically signed in. To do that, you need to redirect the user to the following URL in a filter or a middleware:
+
+```text
+https://${account.namespace}/authorize?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}
+```
+
+Here is an example in node.js:
+
+```js
+app.get('/',
+    // This redirects to https://YOURS.auth0.com....
+    passport.authenticate('auth0', {}),
+    function(req, res) {
+      // Once user is logged in, redirect to the user page
+      res.redirect('/user');
+    });
+```
+
+If the user was already logged in before, then Auth0 will automatically redirect back to the application with a new token. If not, then it will show the Auth0 Login Page.
+
+## Case 3: The user has never logged in
+
+The user has never logged in to any app. In this case, the filter or middleware mentioned in the previous point checks if the user is authenticated or not, and in the case they're not, redirects the user to the following URL:
+
+```text
+https://${account.namespace}/authorize?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}
+```
diff --git a/ja-jp/articles/sso/legacy/single-page-apps.md b/ja-jp/articles/sso/legacy/single-page-apps.md
new file mode 100644
index 0000000000..e726c4d78a
--- /dev/null
+++ b/ja-jp/articles/sso/legacy/single-page-apps.md
@@ -0,0 +1,189 @@
+---
+description: Client-side Single Sign-on (SSO) with single-page applications.
+toc: true
+topics:
+  - sso
+  - spas
+contentType:
+  - how-to
+  - concept
+useCase:
+  - integrate-saas-sso
+---
+# Client-side Single Sign-On (Single-Page Apps)
+
+::: version-warning
+This document covers an outdated version of the Auth0 authentication pipeline. We recommend you use the current version. For more on the latest authentication pipeline refer to [Introducing OIDC Conformant Authentication](/api-auth/intro).
+:::
+
+To log a user in silently (that is, without displaying the Lock screen) the following conditions need to be met:
+
+1. The Application needs to be configured to **Use Auth0 instead of the IdP to do Single Sign-on** in the [Applications section of the Auth0 Management Dashboard](${manage_url}/#/applications)
+2. A Single Sign-on (SSO) cookie must exist for the tenant's domain. In other words the user must have signed in previously, and the SSO cookie which was saved is still valid.
+3. When calling the Auth0 authentication endpoint, the connection name is passed along for which the user must be signed in. This connection name is the same as the one specified in the SSO cookie. You can pass the connection name along either as a parameter when calling the `signin` function of the [**auth0.js** Library](/libraries/auth0js), or by passing the `connection` query string parameter when calling the `/authorize` endpoint of the [Authentication API](/api/authentication)
+
+## The SSO scenario
+
+In our SSO scenario, let's say we have 3 applications
+
+* App 1: app1.com (Single-Page App)
+* App 2: app2.com (Single-Page App)
+* App 3: app3.com (Regular Web app)
+
+If a user logs in to any of these applications, and then subsequently navigates from this application to any of the other applications, we would want the user to be logged in automatically.
+
+In this document we will be looking specifically how to achieve this in a Single-Page (JavaScript) Application
+
+## Obtaining the SSO cookie information  
+
+If a users logs in to any of the applications and then subsequently tries to log in to any of the other applications, you can check to see whether an SSO session is active for that user by making use of the `getSSOData` function in the [auth0.js library](/libraries/auth0js#sso).
+
+```js
+auth0.getSSOData(function (err, ssoData) {
+  if (err) return console.log(err.message);
+  expect(ssoData.sso).to.exist;
+});
+```
+
+This function will return an `ssoData` object which will indicate whether an active SSO session exist. The `ssoData` object will contain the fields as per the following example:
+
+```json
+{
+  sso: true,
+  sessionClients: [
+    "jGMow0KO3WDJELW8XIxolqb1XIitjkYL"
+  ],
+  lastUsedClientID: "jGMow0KO3WDJELW8XIxolqb1XIitjkYL",
+  lastUsedUsername: "alice@example.com",
+  lastUsedConnection: {
+    name: "Username-Password-Authentication",
+    strategy: "auth0"
+  }
+}
+```
+
+## Passing the Connection Name when logging the user in
+
+You can then use this information to call the `signin` function to log the user in. When you call the `signin` function you pass along the name of the connection used in the active SSO session as the `connection` parameter. Auth0 will determine that an SSO cookie is saved for that connection, and will log the user directly without displaying the Lock user interface.
+
+
+```js
+auth0.getSSOData(function (err, ssoData) {
+  if (!err && ssoData.sso) {
+    auth0.signin({
+      connection: ssoData.lastUsedConnection.name,
+      scope: 'openid name picture',
+      state: getQueryParameter('targetUrl')
+    });
+  } else {
+    // Display regular login option, such as a Login button which will invoke Lock
+  }
+});
+```
+
+## Full SSO Sample Code
+
+Below is an expanded code sample of how you can implement this in a SPA application using jQuery to either show or hide the Login button or user information depending on whether a user is logged in or not.
+
+The full code sample for both the SPA applications as well as the normal web application can be found in [this github repository](https://github.com/auth0/auth0-sso-sample/tree/master/app1.com)
+
+```html
+
+
+
+
+  
+
+```
+
+## Single Logout
+
+If the user logged out from app1.com, then we want to clean up the token on app2.com (and app3.com). Read more about [Single Logout](/logout).
+
+To do that, you have to check every X amount of time whether the SSO session is still alive in Auth0. If it is not, then remove the token from Local Storage for the application. This will ensure that the user's local session is cleared.
+
+```js
+setInterval(function() {
+  // if the token is not in local storage, there is nothing to check (that is, the user is already logged out)
+  if (!localStorage.getItem('userToken')) return;
+
+  auth0.getSSOData(function (err, data) {
+    // if there is still a session, do nothing
+    if (err || (data && data.sso)) return;
+
+    // if we get here, it means there is no session on Auth0,
+    // then remove the token and redirect to #login
+    localStorage.removeItem('userToken');
+    window.location.href = '#login'
+
+  });
+}, 5000)
+```
diff --git a/ja-jp/articles/support/_delete-tenant.md b/ja-jp/articles/support/_delete-tenant.md
new file mode 100644
index 0000000000..339c60adc2
--- /dev/null
+++ b/ja-jp/articles/support/_delete-tenant.md
@@ -0,0 +1,21 @@
+## Delete tenants
+
+This process deletes only one tenant. If you have other tenants that need to be removed, you will need to repeat these steps for each tenant. If you are an [enterprise customer](#for-enterprise-customers) or have a [paid subscription](#for-paid-subscription-customers), please review our caveats before proceeding.
+
+::: warning
+You **cannot** restore a deleted tenant and you cannot reuse a tenant name when creating new tenants.
+:::
+
+1. Log in to the [Dashboard](${manage_url}).
+2. Click on your username in the top right corner to display the dropdown box.
+3. Select **Settings** to open the **Tenant Settings** page.
+4. On the **Tenant Settings** page, select the **Advanced** tab.
+5. Scroll down to the **Danger Zone** at the bottom of the page, and click **Delete**.
+
+### For enterprise customers
+
+If you are an Enterprise customer, you may have multiple child tenants as part of your Auth0 contract. While it is not possible to delete the main tenant from the dashboard (you will need to contact support for that), the child tenants can be deleted at any time. Rest assured that if you choose to delete a child tenant, this will have no impact on your agreement with Auth0. We recommend speaking with your Technical Account Manager if you have any concerns about your Enterprise agreement.
+
+### For paid subscription customers
+
+If you have a paid subscription with one or more child tenants, deleting the main subscription is not possible from the Dashboard. Please contact support for that. It is possible to delete child tenants from the Dashboard, and deleting such tenants should have no impact on your subscription plan. This is because activity and usage on child tenants counts toward the main tenant's activity and usage limitations.
diff --git a/ja-jp/articles/support/_reset-tenant.md b/ja-jp/articles/support/_reset-tenant.md
new file mode 100644
index 0000000000..f055220c71
--- /dev/null
+++ b/ja-jp/articles/support/_reset-tenant.md
@@ -0,0 +1,11 @@
+## Reset tenants
+
+To reset your tenant to its initial state, you can use the [Deploy CLI Tool](/extensions/deploy-cli). This creates a "clean" environment for development or test purposes and removes unwanted items.
+
+1. Install the tool `a0deploy` by running the following in your command-line interface: `npm i -g auth0-deploy-cli`
+
+2. Get a snapshot of the state you would like to preserve: `a0deploy export --config_file config.json --format yaml --output_folder ./`
+
+3. [Update the configuration file](/extensions/deploy-cli/guides/import-export-yaml-file#import-tenant-configuration) used for the import.
+
+4. Update your tenant with its stored state: `a0deploy import --config_file config.json --format yaml --input_file ./tenant.yaml`
\ No newline at end of file
diff --git a/ja-jp/articles/support/cancel-paid-subscriptions.md b/ja-jp/articles/support/cancel-paid-subscriptions.md
new file mode 100644
index 0000000000..df35bb82d8
--- /dev/null
+++ b/ja-jp/articles/support/cancel-paid-subscriptions.md
@@ -0,0 +1,40 @@
+---
+description: To cancel your Auth0 subscription, you can downgrade to a free subscription or delete your tenant.
+crews: crew-2
+topics:
+    - support
+    - subscriptions
+    - cancellation
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Cancel Your Auth0 Subscription
+
+If you wish to cancel your Auth0 subscription, you should:
+
+1. [Downgrade](#downgrade-a-paid-subscription-to-a-free-subscription) a paid subscription to a free subscription
+2. [Delete](#delete-your-auth0-tenant) your Auth0 tenant
+
+## Downgrade to a free subscription
+
+1. Log in to the [dashboard](${manage_url}).
+2. Click on your tenant name in the top right corner to display the  dropdown box.
+
+![](/media/articles/subscriptions/dashboard.png)
+
+3. Select **Settings** to open the **Tenant Settings** page.
+4. On the **Tenant Settings** page, click on the **Subscription** tab.
+
+![](/media/articles/subscriptions/subscription.png)
+
+5. On the **Subscription** tab, scroll down to the box associated with the **Free** plan and click **Checkout**.
+
+![](/media/articles/subscriptions/free-subscription.png)
+
+6. To confirm your subscription change, click **Subscribe Now**.
+
+<%= include('./_delete-tenant') %>
diff --git a/ja-jp/articles/support/delete-reset-tenant.md b/ja-jp/articles/support/delete-reset-tenant.md
new file mode 100644
index 0000000000..5b89c4de31
--- /dev/null
+++ b/ja-jp/articles/support/delete-reset-tenant.md
@@ -0,0 +1,35 @@
+---
+description: How to delete or reset your tenant
+topics:
+    - support
+    - delete-tenant
+    - reset-tenant
+    - tenants
+contentType:
+  - how-to
+useCase:
+  - support
+---
+
+# Delete or Reset Tenants
+
+::: warning
+If you are using custom domains, when deleting a tenant, first delete the custom domain. If you delete the tenant before removing the custom domain, you will not be able to reuse your custom domain elsewhere.
+:::
+
+If you want to completely remove an unwanted tenant, we recommend deleting it. This option is useful if you have created a test or demo tenant that you won't be using again, so you don't care about keeping your tenant name.
+
+If you want to keep using your tenant name, we recommend resetting your tenant by using the **Deploy CLI Tool** to remove any unwanted items. This will return your tenant to its initial state and retain your tenant name.
+
+<%= include('./_delete-tenant') %>
+
+<%= include('./_reset-tenant') %>
+
+## Keep reading
+
+* If you've deleted your tenant, and you require the use of a particular domain name, we recommend configuring a [custom domain name](/custom-domains) for your new tenant.
+* [Cancel Your Auth0 Subscription](/support/cancel-paid-subscriptions) to downgrade to a free account.
+* [Change or Upgrade Your Auth0 Subscription](/support/subscription)
+* [Update a Tenant Admin](/dashboard/manage-dashboard-admins#update-admin) to change ownership of the tenant.
+* [Export Data Out of Auth0](/support/removing-auth0-exporting-data)
+* [Reset Your Auth0 Account Password](/support/reset-account-password)
diff --git a/ja-jp/articles/support/how-auth0-versions-software.md b/ja-jp/articles/support/how-auth0-versions-software.md
new file mode 100644
index 0000000000..0d3109b493
--- /dev/null
+++ b/ja-jp/articles/support/how-auth0-versions-software.md
@@ -0,0 +1,50 @@
+---
+title: How Auth0 versioning works
+description: Understand how Auth0 versioning works.
+topics:
+    - support
+    - auth0-versioning
+    - versioning
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Versioning
+
+We believe versioning is a crucial part of our offering. By providing a consistent versioning scheme for our products we are able to help our users manage and predict how our changes will impact usage.
+
+## Semantic versioning
+
+::: note
+This scheme is used in Auth0 Lock, [Auth0 AD Connector](https://github.com/auth0/ad-ldap-connector), [Auth0.js](https://github.com/auth0/auth0.js) and SDKs.
+:::
+
+[Semantic versioning](http://semver.org) (also known as semver) is a versioning strategy whose main feature is making breaking changes discoverable. A version is composed of 3 numbers separated by dots: `{major}.{minor}.{patch}`. For instance, `2.12.5`, `0.1.0` and `10.5.35` are valid semver numbers. 
+
+- The first number represents a **major change**: **the library API has changed in a non-backwards compatible way**. When the major part of a version is bumped, the public API of that library has changed. For example, code and functionality previously marked as deprecated is removed from the code base.
+- The second number represents a **minor change**: **the library API has new functionality added or marked as deprecated while keeping backward compatibility**. The new minor version is expected to be safe for use and we encourage customers to update. However, as it is impossible to know every way customers use a component, there is always a chance that changes might have impact on the current usage of the component. Therefore, we recommend verifying and testing before performing an update.
+- The third number, represents **a patch change**: **A bug has been fixed and should not have any impact on the user facing API**. This should be safe to update but testing is always encouraged.
+
+More information about this versioning scheme can be found at [semver](http://semver.org)
+
+### Production usage
+
+Auth0 provides links to our [Content Delivery Network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) where we serve some of our libraries. The way you reference a component in your code will impact whether and when you automatically pick up changes.  For instance, if you link to the major release from within a script, and there is a new minor, you will get the update as soon as it is released. We encourage this practice for development environments and experimenting with Auth0. Here are examples of embedding the source files:
+
+```js
+
+
+
+
+
+
+
+
+```
+
+**When Auth0 components are deployed to production, we encourage our users to anchor to a full version and thoroughly test using that version**. Although adding new features in a backwards compatible way shouldn’t break your code, the interactions with the component outcome could be hard to predict.  Even trivial bug fixes may introduce changes in the assumptions you were making about the component which may no longer be true.
+
+::: note
+Each Auth0 open source component that follows semver will have a tag matching a released version in its git repository. As some of the projects use [npm](https://npmjs.com) tooling to release versions the tags will have a `v` letter as a prefix. For instance, version `5.2.3` tag will be `v5.2.3`.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/support/index.md b/ja-jp/articles/support/index.md
new file mode 100644
index 0000000000..d579b97fee
--- /dev/null
+++ b/ja-jp/articles/support/index.md
@@ -0,0 +1,208 @@
+---
+url: /support
+toc: true
+description: Explains the different types of support options provided by Auth0.
+topics:
+    - support
+contentType:
+  - index
+useCase:
+  - support
+---
+# Support Options
+
+The following page contains information about the Auth0 support program.
+
+## Support Options Overview
+
+Auth0 offers the following support plans:
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Community SupportCustomers with Auth0's free subscription plan can seek support through the Auth0 Community.
    Standard SupportFor customers with a paid (non-Enterprise) subscription plan or those in the initial trial period.
    Enterprise SupportFor customers with an Enterprise subscription plan.
    Premier SupportFor customers with an Enterprise subscription plan that have added the Premier Support option.
    Preferred SupportFor customers with an Enterprise subscription plan that have added the Preferred Support option. This offering is no longer for sale.
    
+
+### Community Support
+
+Customers with Auth0's free community subscription plan can seek support through the [Auth0 Community](${auth0_community}). Response times may vary and are not guaranteed.
+
+If you have a free account and your account has been compromised, please post in Community and reach out to us via DM on [Twitter](https://twitter.com/auth0community).
+
+:::panel Trial Subscriptions
+New Auth0 customers receive Standard Support during the 22-day trial period (customers may check on how many trial days they have left by logging into the [Dashboard](${manage_url})).
+
+At the end of the trial period, customers who have not opted to purchase a paid subscription can use the [Auth0 Community](${auth0_community}) for assistance. They will no longer be able to access or open tickets in the [Support Center](https://support.auth0.com/).
+:::
+
+### Standard Support
+
+Customers with a paid Auth0 subscription plan receive Standard Support, which offers access to the following channels:
+
+* Auth0 Community;
+* Auth0 Support Center.
+
+The Auth0 Support Center offers ticketed support, where support specialists are available to provide assistance.
+
+### Enterprise Support (with or without Premier Support)
+
+Customers with an Enterprise Subscription Plan receive extended support hours for outages, quicker response times, and access to the Customer Success Team.
+
+## Support Channels
+
+Auth0 offers the following support channels.
+
+### Auth0 Community
+
+Auth0's public [question and answer community](${auth0_community}) offers support for __all__ subscribers. All customers, even those on free tenants, can search through existing questions and post a new question if theirs hasn't been answered. There are no guaranteed response times for questions posted.
+
+### Support Center
+
+In addition to the Auth0 Community, paid subscribers can create a private ticket via [Support Center](${env.DOMAIN_URL_SUPPORT}). All tenant administrators will be able to view and add comments to Support Center tickets. Support Center can be accessed by clicking on the **Get Support** link on the [dashboard](${manage_url}).
+
+[Learn more about creating tickets with Support Center](/support/tickets)
+
+Critical Production issues should always be reported via the [Support Center](https://support.auth0.com/) for fastest response.
+
+#### Add Support-Only Users
+
+You can add support-only users to your Auth0 tenant. This will allow them to open, view, and comment on [Support Center](${env.DOMAIN_URL_SUPPORT}) tickets, receive relevant notifications, and see service details.  They do not, however, have full administration access to the [Auth0 Dashboard](${manage_url}).
+
+To add one or more support-only users, go to [Support Center](${env.DOMAIN_URL_SUPPORT}). Click on your name in the top right, and click **Invite Users to Support Center**. Note that only tenant administrators with `All Applications` access can add Support-Only users.
+
+![](/media/articles/support/support-center-users.png)
+
+If this is the first time you've used this feature or there are no support-only users, you'll be redirected immediately to a screen that allows you to invite users.
+
+![](/media/articles/support/invite-users.png)
+
+Provide the user's email address, select the Auth0 service to which they should have support access, and click **Send Invitation**. Auth0 will then send the user an email inviting them to register for and log into the Support Center.
+
+Administrative accounts will be able to see details about support-only accounts.
+
+![](/media/articles/support/manage-users.png)
+
+Using this page, you can:
+
+* Search for users;
+* See the account details for users;
+* Revoke privileges.
+
+## Program Features
+
+Your Sales Order will indicate whether you are subscribed to the **Standard** Support Program, **Enterprise** Support Program, or **Premier** Support Program.
+
+The following features are provided with **every** support plan:
+
+- Answer questions concerning usage issues related to Auth0 Platform specific features, options and configurations
+- Provide initial and high-level suggestions regarding the appropriate usage, features, or solution configurations for the particular type of reporting, analysis, or functionality
+- Isolate, document, and find alternative solutions for reported Defects
+- Work with Auth0 Operations, Product, Software Development, and QA staff to submit Change Requests, Enhancement Requests, and provide Fixes for the Auth0 Platform as necessary
+- Address your concerns with online or printed documentation, providing additional examples or explanation for concepts requiring clarification
+- Access to online release notes for Updates
+- Access to Auth0’s online library of Support webinars and knowledgebase
+- Access to Auth0’s Customer Community forums to collaborate with fellow Auth0 customers
+
+The following table describes feature differences of each Auth0 support plan:
+
+| Support Feature | Standard | Enterprise | Preferred | Premier |
+| - | - | - | - | - |
+| Enhanced Response Times | No | Yes | Yes | Yes |
+| Enhanced Hours of Support | No | Yes | Yes | Yes |
+| Ticket Review | No | No | Yes | Yes |
+| Phone Support | No | No | No | Yes |
+| Designated team of Developer Support Engineers | No | No | No | Yes |
+
+## Defect Resolution Procedures
+
+Auth0 will assign all Defects one of four response priorities, dependent upon the problems caused by the Defect. Auth0 may re-assign prioritization levels assigned by you in Auth0’s trouble ticketing system, to reflect the problem descriptions below. Auth0’s assignment will be consistent with the problem descriptions described below. Priority categories are as follows:
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Severity LevelDescription
    1 (Urgent)Emergency Issue. Defect resulting in full or partial system outage or a condition that makes the Auth0 Platform unusable or unavailable in production for all of your Users.
    2 (High)Significant Business Impact. Defect resulting in a condition where major functionality is impacted or significant performance degradation is experienced; issue is persistent and affects many Users and/or major functionality.
    3 (Normal)Minor Feature / Function Issue / General Question. Defect results in a component of the Auth0 Platform not performing as expected or documented or an inquiry by your representatives regarding general technical issues/questions
    4 (Low)Minor Problem / Enhancement Request. Information requested on Auth0 Platform capabilities, navigation, installation, or configuration; enhancement request.
    
+
+### Defect Responses
+
+The priority of a Defect will dictate the timing and nature of the response as specified in the table below:
+
+| Defect Severity Level & Business Impact | Standard Target Response Time | Enterprise Target Response Time | Preferred Target Response Time (no longer for sale) | Premier Target Response Time | Solution Definition (one or more of the following) |
+| --- | --- | --- | --- | --- | -- |
+| **1 (Urgent)**
    Emergency Issue | 1 business hour
    24x7x365 | 30 minutes
    24x7x365 | 30 minutes
    24x7x365 | 30 minutes
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix is provided.
      •  
    • Fix incorporated into future release.
     |
+| **2 (High)**
    Significant Business Impact | 4 business hours
    6AM to 6PM, Mon to Fri (local time) | 2 hours
    24 hours a day, Mon to Fri (local time) | 1 hour
    24 hours a day, Mon to Fri (local time) | 1 hour
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix is provided.
      •  
    • Fix incorporated into future release.
     |
+| **3 (Normal)**
    Minor Feature / Function Issue, General Question | 1 business day
    6AM to 6PM, Mon to Fri (local time) | 12 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24x7x365 | 
    • Issue is resolved.
      •  
    • Workaround is provided.
      •  
    • Fix incorporated into future release.
      •  
    • Answer to question is provided.
     |
+| **4 (Low)**
    Minor Problem, Enhancement Request | 2 business days
    6AM to 6PM, Mon to Fri (local time) | 24 hours
    24 hours a day, Mon to Fri (local time) | 12 hours
    24 hours a day, Mon to Fri (local time) | 8 hours
    24x7x365 | 
    • Answer to question is provided.
      •  
    • Enhancement request logged.
     |
+
+## Program Hours
+
+Auth0 will provide support for Severity Level 1 Defects on a 24x7x365 basis.
+
+For all other defects, Auth0 will provide support during the hours specified below:
+
+| Standard | Enterprise/Preferred | Premier |
+| - | - | - |
+| 6AM to 6PM (your local time) Monday to Friday | 24 hours a day, Monday to Friday (your local time) | 24 hours a day, 7 days a week, 365 days a year |
+
+## Support Languages
+
+We provide all technical support in English, but we will make an effort to accommodate other languages if possible.
+
+## Upgrades
+
+During the Subscription Term, Auth0 will provide or install Updates if and when they are made generally commercially available by Auth0 to its customers, at no additional cost to you.
+
+## Pricing
+
+For pricing information on Auth0's subscription plans, please see [Pricing Page](https://auth0.com/pricing) or your [Tenant Settings](${manage_url}/#/tenant/billing/subscription).
+
+## Auth0 Status
+The [Auth0 status page](https://status.auth0.com) contains information on current production status and will be updated during an outage.  After an outage, a root-cause analysis is performed and made available via the page.
+
+Please check the [status page](https://status.auth0.com) before filing a ticket.  If the status page contains a notification about an outage, our team will already be working on restoring service as quickly as possible.  Once the issue is resolved, the status page will be updated to reflect that.  There is a button on the page to subscribe to notifications of any changes.  A root-cause analysis will be published to the status page once an investigation has been done.
+
+## Whitehat Support Tickets
+
+All customers, even those with free subscription plans, may report security concerns via [Auth0 Whitehat](https://auth0.com/whitehat).
+
+[Additional Details](https://auth0.com/legal)
diff --git a/ja-jp/articles/support/matrix.md b/ja-jp/articles/support/matrix.md
new file mode 100644
index 0000000000..1d8783c5bc
--- /dev/null
+++ b/ja-jp/articles/support/matrix.md
@@ -0,0 +1,518 @@
+---
+title: Auth0 Product Support Matrix
+description: This doc covers what features, platforms, and software configurations Auth0 supports.
+toc: true
+classes: support-matrix-page
+topics:
+    - support
+    - support-matrix
+contentType:
+  - reference
+useCase:
+  - support
+---
+# Auth0 Product Support Matrix
+
+For customers with valid [subscriptions](${manage_url}/#/account/billing/subscription), this article covers the features, platforms, and software configurations that are eligible for Auth0 support.
+
+Auth0 provides support in alignment with the [Terms of Service](https://auth0.com/terms) and Pricing and Support plans.
+
+## Auth0 Support Coverage
+
+Official support provided by Auth0 is limited to the languages, platforms, versions, and technologies specifically listed as such on this page. Anything that is **not** listed, or is listed as **community-supported**, is ineligible for Auth0 support.
+
+If you have questions about unsupported items, you can post your question on the [Auth0 public forum](https://community.auth0.com/).
+
+For community-supported items, you can ask for help by contacting the developers responsible for those items (such as submitting issues on the GitHub repositories for the specific libraries or software development kits (SDKs)).
+
+::: note
+Auth0 support is limited to the most recent version of the technologies listed (unless otherwise specified). If you are using an older version, you will be required to upgrade prior to seeking support.
+:::
+
+### Definitions
+
+Throughout this article, we will use the following terms to indicate the varying levels of support Auth0 will provide.
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    LabelDescription
    Supported
    		Auth0 has formally tested, will support, and provide both new features and bug fixes (if applicable) for these items.
    Sustained
    		Auth0 will support and may provide bug fixes (if applicable) for these items.
    Bug fixes
    		May receive bug fixes
    Community
    		Auth0 does not support these items, and all assistance regarding these items will come from the general community.
    
+
+## Browsers
+
+This section covers the browsers that Auth0 will support when using the Auth0 Dashboard or Lock Library, or executing authentication transactions.
+
+### Auth0 Dashboard
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    BrowserLevel of Support
    Google Chrome (Latest version)
    Supported
    Apple Safari (Latest version)
    Sustained
    Microsoft Edge (Latest version)
    Sustained
    Mozilla Firefox (Latest version)
    Sustained
    
+
+::: note
+At this time, Auth0 only supports use of the Dashboard with desktop browsers.
+:::
+
+### Auth0 Lock and Authentication
+
+#### Desktop Browsers
+
+
+  
+    
+      
+      
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    BrowserLevel of Support
+    
    Google Chrome (Latest version)
    Supported
    Apple Safari (Latest version)
    Sustained
    Microsoft Internet Explorer 10/11
    Sustained
    Microsoft Edge (Latest version)
    Sustained
    Mozilla Firefox (Latest version)
    Sustained
    
+
+#### Mobile Browsers
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    Mobile browserLevel of Support
    Apple Safari for iOS 9 (or later)
    Supported
    Google Chrome for Android KitKat (4.4) or later
    Supported
    
+
+## Operating Systems
+
+This section covers the operating systems (OS) that Auth0 will support when using the Auth0 Dashboard, Lock Library or executing authentication transactions.
+
+::: note
+Auth0 support is limited to the most recent version of the OS listed (unless otherwise specified). If you are using an older version, please upgrade prior to seeking support.
+:::
+
+### Auth0 Dashboard
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    OSLevel of Support
    Apple MacOS (when using Google Chrome as your browser)
    Supported
    Apple MacOS (when using any browser besides Google Chrome)
    Sustained
    Linux (Ubuntu)
    Sustained
    Microsoft Windows
    Sustained
    
+
+### Auth0 Lock and Authentication
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    OSLevel of Support
    Apple iOS 9 (or later)
    Supported
    Google Android KitKat (4.4) or later
    Supported
    
+
+## SDKs and Libraries
+
+### Auth0 Lock Widgets
+
+<%= include('../_includes/_libraries_support_lock') %>
+
+### Auth0 SDKs
+
+<%= include('../_includes/_libraries_support_sdks') %>
+
+### Framework and Platform Integration SDKs
+
+<%= include('../_includes/_libraries_support_frameworks') %>
+
+### Auth0 Analytics SDK
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+  
+
    LibraryVersionLevel of Support
    auth0-analytics.jsv1
    Supported
    
+
+### Content Management Systems Plugins
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
    CMSLevel of Support
    WordPress
    Supported
    Drupal
    Community
    Joomla
    Community
    
+
+## Quickstarts and Samples
+
+### Mobile/Native Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    Android
    Supported
    Cordova
    Supported
    Device Authorization Flow
    Supported
    Ionic 4
    Supported
    iOS - Swift
    Supported
    React Native
    Supported
    Windows Universal App C#
    Supported
    WPF/Winforms
    Supported
    Xamarin
    Supported
    
+
+### Single-Page Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    Angular
    Supported
    JavaScript
    Supported
    React
    Supported
    Vue.js
    Supported
    
+
+### Regular Web Applications
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+        
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    ASP.NET (OWIN)
    Supported
    ASP.NET Core v2.1
    Supported
    ASP.NET Core v3.1
    Supported
    Go
    Supported
    Java
    Supported
    Java Spring Boot
    Supported
    Node.js
    Supported
    PHP
    Supported
    PHP (Laravel)
    Supported
    Python
    Supported
    Ruby on Rails
    Supported
    
+
+### Backends/APIs
+
+
+  
+    
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    TechnologySampleLevel of Support
    ASP.NET Core Web API
    Supported
    ASP.NET Web API (OWIN)
    Supported
    Go
    Supported
    Java Spring Security
    Supported
    Node.js (Express)
    Supported
    PHP
    Supported
    Laravel
    Supported
    Python
    Supported
    Ruby on Rails
    Supported
    
+
+## Extensions
+
+::: note
+Auth0 does not provide support for custom extensions.
+:::
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+  
+
    ExtensionsLevel of Support
    Extensions created by Auth0 and published to the Management Dashboard
    Sustained
    
+
+Feature requests should be requested at the GitHub repository of each extension. Please note there is no commitment from Auth0 to implement requests.
+
+
diff --git a/ja-jp/articles/support/removing-auth0-exporting-data.md b/ja-jp/articles/support/removing-auth0-exporting-data.md
new file mode 100644
index 0000000000..c9cc3013e5
--- /dev/null
+++ b/ja-jp/articles/support/removing-auth0-exporting-data.md
@@ -0,0 +1,47 @@
+---
+description: How to export data out of Auth0.
+topics:
+    - support
+    - data
+    - data-export
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Export Data Out of Auth0
+
+All data in your Auth0 tenant is always under your control and is [available through the management API](/api/v2) at any time.
+The only information which is not available through the API (for security reasons) are the password hashes of your [Auth0-hosted database users](/connections/database) and private keys.
+You can request the password hashes by opening a [support ticket](${env.DOMAIN_URL_SUPPORT}). Please note that this operation is not available for our Free subscription tier, and we are unable to accept or guarantee requests for exports at a specific time and date.
+
+## Keep user credentials on your infrastructure
+
+If you want to store user passwords on your database, you can set up a [custom database connection](/connections/database/mysql) which Auth0 will query each time a user logs in.
+In this case Auth0 will never store any password hashes, unless you choose to [progressively migrate users to Auth0](/connections/database/migrating).
+
+## If you don't want to use proprietary Auth0 components
+
+Auth0 primarily uses OpenID Connect (OIDC) as its authentication protocol, so you should be able to implement an integration to your application using standard libraries. The same situation applies when [integrating Auth0 through SAML](/saml-configuration).
+
+All of Auth0's SDKs, libraries, and samples [are published on GitHub as free software](https://github.com/auth0/).
+
+## Social identity providers
+
+If you choose not to use Auth0 but keep using the same OAuth client IDs and secrets for your social identity providers, you will retain access to user information without needing to display new consent dialogs.
+
+## Custom code
+
+All of Auth0's custom code features (rules, custom database scripts, custom OAuth connections, and so on) run on a Node.js sandbox service.
+
+All libraries available on the sandbox service are also available on npm for use with standard Node.js code.
+
+## Keep reading
+
+::: next-steps
+* [Auth0 privacy policy](https://auth0.com/privacy)
+* [Availability and trust](https://auth0.com/availability-trust)
+* [Data security and confidentiality policies](https://auth0.com/security)
+:::
diff --git a/ja-jp/articles/support/reset-account-password.md b/ja-jp/articles/support/reset-account-password.md
new file mode 100644
index 0000000000..05c72bd204
--- /dev/null
+++ b/ja-jp/articles/support/reset-account-password.md
@@ -0,0 +1,32 @@
+---
+description: Learn how to reset your Auth0 account password.
+crews: crew-2
+topics:
+    - support
+    - passwords
+    - password-reset
+contentType: how-to
+useCase:
+  - support
+  - reset-passwrod
+---
+
+# Reset Auth0 Account Password
+
+If you need to change your password or you have forgotten the password to your Auth0 account, in most cases, you can set a new password from the Auth0 Dashboard. Password resets cause Auth0 sessions to expire. 
+
+1. On the Auth0 account login screen, click **Don't remember your password?**
+
+2. Provide your email address, and click the **right arrow** to submit. You will receive an email that provides further instructions on resetting your password.
+
+3. If your request was successfully received, you'll be directed back to the login screen with a message that says, "We've just sent you an email to reset your password."
+
+## Special password reset circumstances
+
+- If you've enabled multi-factor authentication (MFA) and need an MFA reset for your admin account, you will need to contact [Auth0 Support](https://auth0.com/docs/support).
+- If you're using a social or enterprise account to log in to Auth0, you will need to reset your password with the appropriate identity provider.
+- If you are an administrator trying to reset a *user's* password, see [Change Users' Passwords](/connections/database/password-change).
+
+## Keep reading
+
+* [Customize Hosted Password Reset Page](/universal-login/password-reset)
diff --git a/ja-jp/articles/support/sld.md b/ja-jp/articles/support/sld.md
new file mode 100644
index 0000000000..ac13357746
--- /dev/null
+++ b/ja-jp/articles/support/sld.md
@@ -0,0 +1,32 @@
+---
+title: Auth0 Service Level Description
+description: Details on the Auth0 Service Level Description
+topics:
+    - sld
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+# Auth0 Service Level Description
+
+::: warning
+This document summarizes the key elements of Auth0’s Service Level Agreement. For full details, please see the **Support Program and Service Levels** in [Auth0 Legal](https://auth0.com/legal).
+:::
+
+The average availability of the Auth0 Platform in each month will be at least 99.90%.
+
+## Availability Credits
+
+If Auth0 fails to meet its availability service level  during any given month and you request a service level credit, then Auth0 will provide you with a credit as described in the table below. If any credits are unutilized upon expiration of your subscription, then we will apply such credits to any other fees or expenses you owe us. If there are no such other fees or expenses, then we will pay you the credit amount.
+
+| Auth0 Platform Availability Level | Service Level Credit |
+| - | - |
+| < 99.9% - >= 99.0% | 10.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+| < 99.0% - >= 95.0% | 20.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+| < 95% | 50.0% of the Monthly Subscription Fee applicable to month in which failure occurred |
+
+Auth0 publishes [status](https://status.auth0.com) and [uptime](http://uptime.auth0.com) monthly reports.
+
+If you require a higher availability commitment or a dedicated instance of Auth0 in your own IT environment, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales) for additional information.
diff --git a/ja-jp/articles/support/subscription.md b/ja-jp/articles/support/subscription.md
new file mode 100644
index 0000000000..bda497694e
--- /dev/null
+++ b/ja-jp/articles/support/subscription.md
@@ -0,0 +1,52 @@
+---
+title: Change or Upgrade Your Auth0 Subscription
+description: How to upgrade or change your Auth0 subscription.
+topics:
+    - support
+    - subscriptions
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+# Change or Upgrade Your Auth0 Subscription
+
+You can make changes to your Auth0 subscription plan via the [Auth0 Management Dashboard](${manage_url}).
+
+1. Log in to the Auth0 [Management Dashboard](${manage_url}).
+2. Click on your tenant name in the top right corner to bring up the associated dropdown box.
+
+  ![](/media/articles/support/subscriptions/account-dropdown.png)
+
+3.  Select **Settings** to open the [Tenant Settings](${manage_url}/#/tenant/) page.
+4. On the **Tenant Settings** page, click on the **Subscription** tab. Note that you have the option of paying for your plan on a **monthly** or **yearly** basis.
+
+  ![](/media/articles/support/subscriptions/subscription.png)
+
+## Upgrade a subscription
+
+You can use the [Management Dashboard](${manage_url}) to upgrade your subscription from:
+
+* The Free plan to the Developer or Developer Pro plan;
+* The Developer plan to the Developer Pro plan.
+
+::: note
+If you would like to upgrade to an Enterprise plan, please [contact Auth0 Sales](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales).
+:::
+
+On the **Subscription** tab, scroll down to the panels describing the plan options available to you.
+
+  ![](/media/articles/support/subscriptions/upgrades.png)
+
+To select a new plan, click **Checkout** in the associated box to upgrade. If you do not have your billing information stored with Auth0, you'll need to provide it at this point.
+
+  ![](/media/articles/support/subscriptions/billing.png)
+
+Click **Subscribe Now** to confirm your information and activate your new subscription.
+
+## Downgrade to a free subscription
+
+On the **Subscription** tab, scroll down to the box associated with the **Free** plan and click **Checkout**.
+
+To confirm your subscription change, click **Subscribe Now**.
diff --git a/ja-jp/articles/support/testing.md b/ja-jp/articles/support/testing.md
new file mode 100644
index 0000000000..cf2c67b86a
--- /dev/null
+++ b/ja-jp/articles/support/testing.md
@@ -0,0 +1,55 @@
+---
+title: Testing Your Auth0 Implementation
+description: Guidelines for testing your Auth0 implementation prior to deployment to Production environments
+topics:
+    - support
+    - testing
+    - pre-deployment-testing
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Testing Your Auth0 Implementation
+
+You should run unit and integration tests before implementing Auth0 on a live application or service.
+
+Performing tests against Auth0 APIs may lead to your account being rate limited, so we recommend creating mock Auth0 APIs during testing. Depending on your development environment, your test tools may also provide mock API functionality. There are also numerous API mocking tools available, such as [MockServer](http://www.mock-server.com/) or [JSON Server](https://github.com/typicode/json-server), that enable you to quickly create fake APIs for testing. You can also [use Postman to set up a mock server](https://www.getpostman.com/docs/postman/mock_servers/setting_up_mock).
+
+::: note
+Enterprise customers may [request load testing against Auth0](/policies/load-testing).
+:::
+
+## Performance Testing
+
+When conducting performance testing, you may encounter issues with your implementation. The following are steps you can take to begin the troubleshooting process and identify where there might be issues of concern.
+
+### The Auth0 Dashboard
+
+The [Logs section of the Auth0 Dashboard](${manage_url}/#/logs) stores data on:
+
+* Actions taken in the Dashboard by administrators
+* Authentications made by your users
+
+There are also [extensions](/extensions) that you can use for logging purposes, including [exporting logs to third-party tools](/extensions#export-auth0-logs-to-an-external-service) and [gathering information on the use of custom code in your account](/extensions#access-to-real-time-webtask-logs).
+
+### Third-Party Testing Tools
+
+There are a number of third-party testing tools that you can use for performance testing against RESTful APIs. Here are some options you might consider (note that Auth0 does not endorse any particular product or tool):
+
+* [Apache JMeter](http://jmeter.apache.org/)
+* [Artillery](https://artillery.io/)
+* [Micro Focus LoadRunner](https://www.radview.com/)
+* [Loader](https://loader.io/)
+* [RadView Webload](https://www.radview.com/)
+* [SmartBear LoadUI](https://smartbear.com/)
+* [Vegeta](https://github.com/tsenart/vegeta)
+* [Wrk](https://github.com/wg/wrk)
+
+These tools should provide activity logs that help you identify anything that is concerning. If you need assistance with deciphering your log or identifying the potential issue, please contact Support.
+
+### HAR Files
+
+If you discover an issue that you can reproduce, you can [create a HAR file](/tutorials/troubleshooting-with-har-files) and send it to our Support team for additional assistance.
\ No newline at end of file
diff --git a/ja-jp/articles/support/tickets.md b/ja-jp/articles/support/tickets.md
new file mode 100644
index 0000000000..f2a7253f40
--- /dev/null
+++ b/ja-jp/articles/support/tickets.md
@@ -0,0 +1,66 @@
+---
+description: How to open and manage tickets with Support Center.
+topics:
+    - support
+    - support-tickets
+    - tickets
+contentType:
+  - how-to
+  - reference
+useCase:
+  - support
+---
+
+# Open and Manage Support Tickets
+
+With [Support Center](${env.DOMAIN_URL_SUPPORT}), you can create tickets for questions or issues you are experiencing. You can access Support Center if you are a full administrator of an Auth0 account, or have received an invitation to Support Center from an administrator. 
+
+If you are an existing Private Cloud customer, you will need to create an Auth0 cloud-based account to log in to the Support Center. This account can also be used for Dev/Test purposes at no additional cost. Please contact your Technical Account Manager or Sales Executive to associate your cloud-based account to your existing Private Cloud subscription.
+
+## Open a new ticket
+
+1. From [Support Center](${env.DOMAIN_URL_SUPPORT}), click on the **Open Ticket** button. If you don't see this button, then you do not have access to support (only paying and trial customers have access to Support). In this case you can use our [Community](https://community.auth0.com/) instead (click **Ask our Community**).
+![Support Center](/media/articles/support/open-ticket.png)
+1. Choose **Affected Tenant** from the dropdown menu.
+1. Under **Issue Type** select the type of issue that best fits your case.
+![Issue types](/media/articles/support/issue-types.png)
+    * **I have a question or issue regarding Auth0** or **I have a question or issue regarding Auth0 or my Private Cloud instance(s)** - (the second option is only available to Private Cloud customers)
+        * If you are not a Trial Tenant customer, you will be asked to select a severity:
+            * **Low: Product Question** - You have questions about how things work, whether we support something
+            * **Normal: General Support Question** - You are in development and have a question about how to configure something or how to resolve an error
+            * **High: Production Application Issue** - Your Production application is experiencing a minor outage impacting some users/feature(s)
+            * **Urgent: Production Application Offline** - Your Production application is experiencing a critical outage impacting all users
+        *  Depending on the issue type you chose, after you select the severity you may need to answer the **What can we help you with?** question. Choose the answer that best matches your issue. 
+![Customer Reason](/media/articles/support/customer-reason.png)
+        * After you make your selection, you can choose to answer some follow-up questions to further refine your request. You can also choose to skip this step by clicking the toggle. 
+![Follow-up questions](/media/articles/support/follow-up.png)
+    * **I would like something new or changed in Auth0** - You would like to suggested product improvements or enhancement requests
+    * **I have a question regarding billing or my recent payments** - You are experiencing issues such as incorrect billing, charges to the incorrect account, and so on
+    * **I have a Compliance or legal question** - You would like to report security vulnerabilities or legal questions
+    * **I have a question regarding my Auth0 account** - You need operational assistance with your account or tenant, or would like to file a request for testing according to our Load and Penetration Testing policies
+::: note
+Selection of severity is not available to Trial Tenant customers or those who have selected any of the following issue types: **I would like something new or changed in Auth0**, **I have a question regarding billing or my recent payments**, **I have a Compliance or legal question**.
+:::
+1. Next, provide a clear summary of the question/issue in the **Subject** field.
+1. In the **Description** box, provide as much detail as possible about the issue. When writing in this box, you can style your text with [Markdown](https://guides.github.com/features/mastering-markdown) and preview what you have written by clicking on **Preview**.
+    When writing your description, please try to include the following information (if applicable):
+    * What were you trying to do?
+    * What did you expect to happen?
+    * Where did things go wrong?
+    * Were there any error messages or screen shots showing the problem? If so, please include them.
+    * Has this worked before, or are you trying a new configuration?
+    * Does the problem occur for all users or just a few?
+    * What troubleshooting steps have you tried?
+1. When you have completed all the fields, click on the **SUBMIT** button.
+
+## Update an existing ticket
+
+1. You can view the existing tickets you have filed by going to the [Support Center](${env.DOMAIN_URL_SUPPORT}) page and clicking on the **Home** link. Select the ticket that you want to update by clicking on its subject.
+![Select ticket](/media/articles/support/select-ticket.png)
+
+1. Enter any additional details into the text box and then click the **REPLY** button. If you are the ticket requester and the ticket is assigned to an agent, but is not solved or closed, you have the option to change the status of your ticket to **Solved** by checking the **Submit as solved** box next to the **REPLY** button.
+![Update ticket](/media/articles/support/update-ticket.png)
+
+### Closed tickets
+
+If your ticket has been closed, but you'd like to continue working with Auth0 on the issue, please create a new [Support Center ticket](${env.DOMAIN_URL_SUPPORT}). Be sure to include the reference number for the original ticket(s).
diff --git a/ja-jp/articles/tokens/_includes/_rtr_enabled.md b/ja-jp/articles/tokens/_includes/_rtr_enabled.md
new file mode 100644
index 0000000000..3b92633b1c
--- /dev/null
+++ b/ja-jp/articles/tokens/_includes/_rtr_enabled.md
@@ -0,0 +1,3 @@
+::: note
+In compliance with the OAuth2 specifications, when a browser requests a Refresh Token from the `/token` endpoint, Auth0 will only return a Refresh Token if [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) is enabled for that client.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/_includes/_validate-id-token.md b/ja-jp/articles/tokens/_includes/_validate-id-token.md
new file mode 100644
index 0000000000..92aa63be6b
--- /dev/null
+++ b/ja-jp/articles/tokens/_includes/_validate-id-token.md
@@ -0,0 +1,3 @@
+::: warning
+Be sure to [validate an ID Token](/tokens/guides/validate-id-tokens) before using the information it contains! You can use a [library](https://jwt.io/#libraries-io) to help with this task.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/concepts/access-tokens.md b/ja-jp/articles/tokens/concepts/access-tokens.md
new file mode 100644
index 0000000000..9b5a68de41
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/access-tokens.md
@@ -0,0 +1,56 @@
+---
+title: Access Tokens
+description: Understand how Access Tokens are used in token-based authentication to allow an application to access an API after a user successfully authenticates and authorizes access.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+# Access Tokens
+
+Access Tokens are used in token-based authentication to allow an application to access an API. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target API. The passed token informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the [**scope**](/scopes) that was granted during authorization.
+
+In addition, if you have chosen to allow users to log in through an [Identity Provider (IdP)](/identityproviders), such as Facebook, the IdP will issue its own Access Token to allow your application to call the IDP's API. For example, if your user authenticates using Facebook, the Access Token issued by Facebook can be used to call the Facebook Graph API. These tokens are controlled by the IdP and can be issued in any format. To learn more, see [Identity Provider Access Tokens](/tokens/concepts/idp-access-tokens). 
+
+## Opaque Access Tokens
+
+Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token needs to call the server that issued the token.
+
+Opaque Access Tokens are tokens whose format you cannot access. Opaque Access Tokens issued by Auth0 can be used with the [`/userinfo` endpoint](/api/authentication#get-user-info) to return a user's profile. 
+
+## JSON Web Token Access Tokens
+
+JSON Web Token (JWT) Access Tokens conform to the [JSON Web Token standard](https://tools.ietf.org/html/rfc7519) and contain information about an entity in the form of claims. They are self-contained in that it is not necessary for the recipient to call a server to validate the token.
+
+Access Tokens issued for the [Auth0 Management API](/api/info) and Access Tokens issued for any custom API that you have registered with Auth0 will follow the [JSON Web Token (JWT)](/tokens/concepts/jwts) standard, which means that their basic structure conforms to the typical [JWT Structure](/tokens/references/jwt-structure), and they contain standard [JWT Claims](/tokens/concepts/jwt-claims) asserted about the token itself.
+
+## Access Token security
+
+You should follow [token best practices](/best-practices/token-best-practices) when using Access Tokens, and for [JWTs](/tokens/concepts/jwts#security), make sure that you [validate an Access Token](/tokens/guides/validate-access-tokens) before assuming that its contents can be trusted.
+
+## Access Token lifetime
+
+### Custom APIs
+
+By default, an Access Token for a custom API is valid for 86400 seconds (24 hours). We recommend that you set the validity period of your token based on the security requirements of your API. For example, an Access Token that accesses a banking API should expire more quickly than one that accesses a to-do API.  
+
+To learn how to change the Access Token expiration time, see [Update Access Token Lifetime](/dashboard/guides/apis/update-token-lifetime).
+
+### /userinfo endpoint
+
+Access Tokens issued strictly for the purpose of accessing the OpenID Connect (OIDC) [`/userinfo` endpoint](/api/authentication#get-user-info) have a default lifetime and can't be changed. The length of lifetime depends on the flow used to obtain the token:
+
+| Flow | Lifetime |
+| ---- | -------- |
+| Implicit | 7200 seconds (2 hours) |
+| Authorization Code/Hybrid | 86400 seconds (24 hours) |
+
+## Keep reading
+
+* [Get Access Tokens](/tokens/guides/get-access-tokens)
+* [Use Access Tokens](/tokens/guides/use-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
diff --git a/ja-jp/articles/tokens/concepts/delegation-tokens.md b/ja-jp/articles/tokens/concepts/delegation-tokens.md
new file mode 100644
index 0000000000..19057c78fb
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/delegation-tokens.md
@@ -0,0 +1,44 @@
+---
+description: Understand how Auth0 delegation tokens work in Auth0.
+topics:
+  - tokens
+  - delegation
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+
+# Delegation Tokens
+
+<%= include('../../_includes/_uses-delegation') %>
+
+A delegation token should be obtained and used when an application needs to call the API of an Application Add-on, such as Firebase or SAP, registered and configured in Auth0, in the same tenant as the calling program.
+
+Given an existing token, this endpoint will generate a new token signed with the `target` application's secret. This is used to flow the identity of the user from the application to an API.
+
+The type of the delegation token varies depending on the provider. For example, if it is issued for Azure Blob Storage, it will be an SAS (Shared Access Signature). If it is for the Firebase Add-on, it will be a JWT.
+
+The ID Token for an authenticated user can be used with the [Delegation endpoint](/api/authentication#delegation) to request a delegation token for a particular target. The target can be an application Add-on configured in Auth0. The Add-ons for which this can be done are those that are not SAML or WS-Fed Add-ons. The Add-on must be configured in Auth0 with secrets obtained from the Add-on service, such as Firebase. Instructions for setting up the secrets are available from the Add-on configuration page for each Add-on. The secrets are used to sign the delegation token so that the Add-on API can validate and trust the token.
+
+The delegation endpoint allows you to set several parameters which govern the contents of the delegation token including the `target`, the `scope`, the API to be called (`api_type`), and an additional free-form area for additional parameters.
+
+See the [Delegation endpoint](/api/authentication#delegation) for more information.
+
+## Auth0.js example
+
+For an example on how to get a new token for an Add-on that you have activated, using __Auth0.js__, refer to [Delegation Token Request](/libraries/auth0js/v7#delegation-token-request). Note that this example is for **version 7** of the __Auth0.js__ library; delegation is **not supported** in version 8 of __Auth0.js__.
+
+## Validity period and termination
+
+The validity period and the ability to revoke a delegation token, varies by individual Add-on. The documentation available from the provider of any Add-on API should be consulted for further information.
+
+## Use Delegation Tokens with public applications
+
+There is an important caveat to note when using the delegation endpoint with [Public Applications](/applications/concepts/app-types-confidential-public#public-applications).
+
+If you call the [Token endpoint](/api/authentication#get-token) from a Public Application, the ID Token will be forcibly signed using `RS256`, even if the _JsonWebToken Signature Algorithm_ in the Application settings is configured as `HS256`.
+
+If you then subsequently call the delegation endpoint with that ID Token, it will fail if the Application's _JsonWebToken Signature Algorithm_ was configured as `HS256`. This is because delegation performs validation according to the Application's settings, but the ID Token was issued with a different algorithm because of the forced algorithm change.
+
+It is therefore important that if you intend to use delegation with a Public Application, that you configure the _JsonWebToken Signature Algorithm_ of your application as `RS256`.
diff --git a/ja-jp/articles/tokens/concepts/id-tokens.md b/ja-jp/articles/tokens/concepts/id-tokens.md
new file mode 100644
index 0000000000..3dce442869
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/id-tokens.md
@@ -0,0 +1,41 @@
+---
+title: ID Tokens
+description: Understand how ID Tokens are used in token-based authentication to cache user profile information and provide it to a client application.  
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - concept
+useCase:
+  - add-login
+  - authentication
+---
+# ID Tokens
+
+ID Tokens are used in token-based authentication to cache user profile information and provide it to a client application, thereby providing better performance and experience. The application receives an ID Token after a user successfully authenticates, then consumes the ID Token and extracts user information from it, which it can then use to personalize the user's experience.
+
+For example, let's say you have built a [regular web application](/applications), [registered it with Auth0](/dashboard/guides/applications/register-app-regular-web), and have [configured it to allow a user to log in using Google](/connections/social/google). Once a user logs in to your app, you can use the ID Token to gather information, such as name and email address, which you can then use to auto-generate and send a personalized welcome email.
+
+## ID Token security
+
+As with any other [JWTs](/tokens/concepts/jwts#security), you should follow [token best practices](/best-practices/token-best-practices) when using ID Tokens.
+
+<%= include('../_includes/_validate-id-token') %>
+
+## ID Token lifetime
+
+By default, an ID Token is valid for 36000 seconds (10 hours). If there are security concerns, you can shorten the time period before the token expires, keeping in mind that one of the purposes of the token is to improve user experience by caching user information. 
+
+To learn how to change the ID Token expiration time, see [Update ID Token Lifetime](/dashboard/guides/applications/update-token-lifetime).
+
+## Keep reading
+
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [Invalid Token Errors](/troubleshoot/references/invalid-token)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [ID Token Structure](/tokens/references/id-token-structure)
+* [Scopes](/scopes)
+* [Get Tokens Using Lock](/libraries/lock#implementing-lock)
diff --git a/ja-jp/articles/tokens/concepts/idp-access-tokens.md b/ja-jp/articles/tokens/concepts/idp-access-tokens.md
new file mode 100644
index 0000000000..8e8effd1f9
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/idp-access-tokens.md
@@ -0,0 +1,49 @@
+---
+title: Identity Provider Access Tokens
+description: Understand third-party Access Tokens issued by identity providers after user authentication and how to use them to call the third-party APIs. 
+topics:
+  - tokens
+  - idp
+  - access-tokens
+contentType:
+  - concept
+useCase:
+  - invoke-api
+---
+
+# Identity Provider Access Tokens
+
+Third-party Access Tokens are issued by [Identity Providers](/identityproviders) after a user authenticates with that provider. Use the Access Tokens to call the API of the third-party provider that issued them. For example, an Access Token issued after authentication to Facebook could be used to call the Facebook Graph API.
+
+The user authenticates with the IdP by making an HTTP `GET` call to [the /api/v2/user/{user-id} endpoint](/api/management/v2#!/Users/get_users_by_id). To call this endpoint you need an [Access Token for the Management API](/api/management/v2/tokens) that includes the `read:user_idp_tokens` scope. The Access Token for the IdP will be available in the `identities` array, under the element for the particular connection. For information on how to call an IdP API, see [Call an Identity Provider API](/connections/calling-an-external-idp-api).
+
+::: warning
+The contents of third-party Access Tokens will vary depending on the issuing identity provider. Because tokens are created and managed by a third-party (such as Facebook, GitHub, etc.), **the validity period for third-party tokens will vary by the issuing IdP**. If you believe these tokens have been compromised, you will need to revoke or reset them with the third-party that issued them.
+:::
+
+## Renew tokens
+
+There is no standard way to renew IdP Access Tokens through Auth0. The mechanism for renewing IdP Access Tokens varies for each provider.
+
+For certain identity providers, Auth0 can store a [Refresh Token](/tokens/concepts/refresh-token), which you can use to obtain a new Access Token for the IdP. Here is a list of some of the identity providers:
+
+* BitBucket
+* Google OAuth 2.0 (pass the parameter `access_type=offline`, as well the `connection_scope` parameter with required scopes, when calling the Auth0 `/authorize` endpoint)
+* Any other OAuth 2.0 IdP
+* SharePoint
+* Azure AD
+
+Get the IdP Refresh Tokens in the same way as Access Tokens, using [the /api/v2/user/{user-id} endpoint](/api/management/v2#!/Users/get_users_by_id). The Refresh Tokens will be available in the `identities` array, under the element for the particular connection.
+
+## Validate tokens
+
+If you have received an Access Token from an [Identity Provider (IdP)](/identityproviders), in general, you don't need to validate it. You can pass it to the issuing IdP, and the IdP takes care of the rest.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Identity Providers Supported by Auth0](/identityproviders)
+* [Access Tokens for the Management API](/api/management/v2/tokens)
+* [Scopes](/scopes)
+* [Call an Identity Provider API](/connections/calling-an-external-idp-api)
+* [Add Scopes/Permissions to Call Identity Provider's APIs](/connections/adding-scopes-for-an-external-idp)
diff --git a/ja-jp/articles/tokens/concepts/jwks.md b/ja-jp/articles/tokens/concepts/jwks.md
new file mode 100644
index 0000000000..38ef6ab6f1
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/jwks.md
@@ -0,0 +1,39 @@
+---
+title: JSON Web Key Set
+description: A JSON Web Key set is a JSON object which represents a set of JSON Web Keys (a JSON object that represents a cryptographic key).
+topics:
+  - tokens
+  - jwks
+  - jwt
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# JSON Web Key Set
+
+The JSON Web Key Set (JWKS) is a set of keys which contains the public keys used to verify any JSON Web Token (JWT) issued by the authorization server and signed using the RS256 [signing algorithm](/tokens/concepts/signing-algorithms). 
+
+When creating applications and APIs in Auth0, two algorithms are supported for signing JWTs: **RS256** and **HS256**. RS256 generates an asymmetric signature, which means a private key must be used to sign the JWT and a different public key must be used to verify the signature.
+
+Auth0 uses the [JSON Web Key (JWK) specification](https://tools.ietf.org/html/rfc7517) to represent the cryptographic keys used for signing RS256 tokens. This specification defines two high-level data structures: **JSON Web Key (JWK)** and **JSON Web Key Set (JWKS)**. Here are the definitions from the specification:
+
+| Item | Description |
+| - | - |
+| **JSON Web Key (JWK)** | A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value. |
+| **JSON Web Key Set (JWKS)** | A JSON object that represents a set of JWKs. The JSON object MUST have a `keys` member, which is an array of JWKs. |
+
+Auth0 exposes a JWKS endpoint for each tenant, which is found at `https://${account.namespace}/.well-known/jwks.json`. This endpoint will contain the JWK used to sign all Auth0-issued JWTs for this tenant.
+
+::: note
+Currently, Auth0 signs with only one JWK at a time; however, it is important to assume this endpoint could contain multiple JWKs. As an example, multiple keys can be found in the JWKS when [rotating application signing keys](/tokens/guides/manage-signing-keys).
+:::
+
+## Keep reading
+
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Key Sets](/tokens/guides/locate-jwks)
+* [Backend/API Quickstarts](/quickstart/backend)
diff --git a/ja-jp/articles/tokens/concepts/jwt-claims.md b/ja-jp/articles/tokens/concepts/jwt-claims.md
new file mode 100644
index 0000000000..867a5efe32
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/jwt-claims.md
@@ -0,0 +1,89 @@
+---
+title: JSON Web Token Claims
+description: Learn about JSON Web Token (JWT) claims and how they are used in Auth0.
+toc: false
+topics:
+  - tokens
+  - jwt
+  - claims
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+  - invoke-api
+  - secure-api
+---
+# JSON Web Token Claims
+
+::: note
+This page describes the standard types of claims available when using the JSON Web Token (JWT) standard. To learn about OpenID Connect (OIDC) standard claims, see [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims) and [OpenID Connect Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
+:::
+
+[JSON Web Token (JWT)](/tokens/concepts/jwts) claims are pieces of information asserted about a subject. For example, an [ID Token](/tokens/concepts/id-tokens) (which is always a JWT) may contain a claim called `name` that asserts that the name of the user authenticating is "John Doe".
+
+In a JWT, a claim appears as a name/value pair where the name is always a string and the value can be any JSON value. Generally, when we talk about a claim in the context of a JWT, we are referring to the name (or *key*). For example, the following JSON object contains three claims (`sub`, `name`, `admin`):
+
+```
+{
+    "sub": "1234567890",
+    "name": "John Doe",
+    "admin": true
+}
+```
+
+## JWT claim types
+
+There are two types of JSON Web Token (JWT) claims:
+
+* **[Reserved](#reserved-claims)**: Claims defined by the [JWT specification](https://tools.ietf.org/html/rfc7519) to ensure interoperability with third-party, or external, applications. [OpenID Connect (OIDC) standard claims](/scopes/current/oidc-scopes#standard-claims) are reserved claims.
+* **[Custom](#custom-claims)**: Claims that you define yourself. Name these claims carefully, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires), to avoid collision with reserved claims or other custom claims. It can be challenging to deal with two claims of the same name that contain differing information.
+
+### Reserved claims
+
+The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with [third-party applications](/applications/guides/enable-third-party-apps). These are:
+
+* iss (issuer): Issuer of the JWT
+* sub (subject): Subject of the JWT (the user)
+* aud (audience): Recipient for which the JWT is intended
+* exp (expiration time): Time after which the JWT expires
+* nbf (not before time): Time before which the JWT must not be accepted for processing
+* iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
+* jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)
+
+You can see a full list of reserved claims at the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims). 
+
+Note that [OpenID Connect (OIDC) standard claims](/scopes/current/oidc-scopes#standard-claims) returned in [ID Tokens](/tokens/concepts/id-tokens) are reserved claims. For an example showing how to add OIDC standard claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#authenticate-a-user-and-request-standard-claims).
+
+### Custom claims
+
+For your specific use case, you can define your own custom claims, which you control and can add to a token using a [rule](/rules). For example, you may want to add a user's email address to an Access Token and use that to uniquely identify the user, or you may want to add custom information stored in an Auth0 user profile to an ID Token. As long as your rule is in place, the custom claims it adds will appear in new tokens issued when using a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+You can name a custom claim anything that is not already listed in the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims), and you should use collision-resistant names, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires).
+
+For an example showing how to add custom claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+#### Public claims
+
+You can create custom claims for public consumption, which might contain generic information like "name" and "email". If you create public claims, you *must* either register them or use collision-resistant names through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 requires) and take reasonable precautions to make sure you are in control of the namespace you use.
+
+In the [IANA JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml#claims), you can see some examples of public claims registered by OpenID Connect (OIDC): 
+
+* auth_time
+* acr
+* nonce
+
+#### Private claims
+
+You can create private custom claims to share information specific to your application. For example, while a public claim might contain generic information like "name" and "email", private claims would be more specific, such as "employee ID" and "department name".
+
+According to the JWT standard, you *should* name private claims cautiously to avoid collision, such as through [namespacing](/tokens/guides/create-namespaced-custom-claims) (which Auth0 still requires). Private claims should not share names with reserved or public claims.
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims)
+* [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token)
diff --git a/ja-jp/articles/tokens/concepts/jwts.md b/ja-jp/articles/tokens/concepts/jwts.md
new file mode 100644
index 0000000000..8a8c3aeb7a
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/jwts.md
@@ -0,0 +1,58 @@
+---
+title: JSON Web Tokens
+description: Understand what a JWT is and how it is used.
+topics:
+  - tokens
+  - jwt
+  - id-token
+  - access-token
+contentType:
+  - concept
+useCase:
+  - development
+  - add-login
+  - invoke-api
+  - secure-api
+---
+# JSON Web Tokens
+
+JSON Web Token (JWT), pronounced "jot", is an open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. Because of its relatively small size, a JWT can be sent through a URL, through a POST parameter, or inside an HTTP header, and it is transmitted quickly. A JWT contains all the required information about an entity to avoid querying a database more than once. The recipient of a JWT also does not need to call a server to validate the token.
+
+Let's talk about the benefits of JWT when compared to Simple Web Token (SWT) and Security Assertion Markup Language (SAML) tokens.
+
+* **More compact**: JSON is less verbose than XML, so when it is encoded, a JWT is smaller than a SAML token. This makes JWT a good choice to be passed in HTML and HTTP environments.
+
+  ![Comparing the length of an encoded JWT and an encoded SAML](/media/articles/jwt/comparing-jwt-vs-saml2.png)
+  _Comparison of the length of an encoded JWT and an encoded SAML_
+
+* **More secure**: JWTs can use a public/private key pair in the form of an X.509 certificate for signing. A JWT can also be symmetrically signed by a shared secret using the HMAC algorithm. And while SAML tokens can use public/private key pairs like JWT, signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON. 
+
+* **More common**: JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn't have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.
+
+* **Easier to process**: JWT is used at internet scale. This means that it is easier to process on user's devices, especially mobile.
+
+JWT is a standard, which means that **all JWTs are tokens, but not all tokens are JWTs**. JWTs can be used in various ways:
+
+- **Authentication**: When a user successfully logs in using their credentials, an [ID Token](/tokens/concepts/id-tokens) is returned. According to the [OpenID Connect (OIDC) specs](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), an ID Token is always a JWT. 
+
+- **Authorization**: Once a user is successfully logged in, an application may request to access routes, services, or resources (e.g., APIs) on behalf of that user. To do so, in every request, it must pass an Access Token, which *may* be in the form of a JWT. Single Sign-on (SSO) widely uses JWT because of the small overhead of the format, and its ability to easily be used across different domains. 
+
+- **Information Exchange**: JWTs are a good way of securely transmitting information between parties because they can be signed, which means you can be sure that the senders are who they say they are. Additionally, the structure of a JWT allows you to verify that the content hasn't been tampered with.
+
+## Security
+
+The information contained within the JSON object can be verified and trusted because it is digitally signed. Although JWTs can also be encrypted to provide secrecy between parties, Auth0-issued JWTs are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, we will focus on *signed* tokens, which can *verify the integrity* of the claims contained within them, while encrypted tokens *hide* those claims from other parties.
+
+In general, JWTs can be signed using a secret (with the **HMAC** algorithm) or a public/private key pair using **RSA** or **ECDSA** (although Auth0 supports only HMAC and RSA). When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
+
+Before a received JWT is used, it should be [properly validated using its signature](/tokens/guides/validate-jwts#check-the-signature). Note that a successfully validated token only means that the information contained within the token has not been modified by anyone else. This doesn't mean that others weren't able to see the content, which is stored in plain text. Because of this, you should never store sensitive information inside a JWT and should take other steps to ensure that JWTs are not intercepted, such as by sending JWTs only over HTTPS, following [best practices](/best-practices/token-best-practices), and using only secure and up-to-date libraries.
+
+## Keep reading
+
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Key Sets](/tokens/guides/locate-jwks)
+* [Tokens Best Practices](/best-practices/token-best-practices)
+* [Web Apps vs. Web APIs / Cookies vs Tokens](/design/web-apps-vs-web-apis-cookies-vs-tokens)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/ja-jp/articles/tokens/concepts/refresh-token-rotation.md b/ja-jp/articles/tokens/concepts/refresh-token-rotation.md
new file mode 100644
index 0000000000..4f48c8014b
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/refresh-token-rotation.md
@@ -0,0 +1,79 @@
+---
+description: Understand how Refresh Token rotation provides greater security by issuing a new Refresh Token with each request made to Auth0 for a new Access Token by a client using Refresh Tokens.
+topics:
+  - tokens
+  - refresh-token-rotation
+contentType: concept
+useCase:
+  - refresh-token-rotation
+  - silent-authentication
+---
+# Refresh Token Rotation
+
+Refresh Token Rotation is a technique for getting new Access Tokens using Refresh Tokens that goes beyond silent authentication. Refresh Tokens are typically longer lived and can be used to request new Access Tokens after the shorter-lived Access Tokens expire. Refresh Tokens are often used in native applications on mobile devices in conjunction with short-lived Access Tokens to provide seamless UX without having to issue long-lived Access Tokens. 
+
+With Refresh Token Rotation enabled on the Auth0 Dashboard, every time a client exchanges a Refresh Token to get a new Access Token, a new Refresh Token is also returned. Therefore, you no longer have a long-lived Refresh Token that, if compromised, could provide illegitimate access to resources. As Refresh Tokens are continually exchanged and invalidated, the threat is reduced. 
+
+The way Refresh Token rotation works in Auth0 conforms with the [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) and works with the following flows:
+* [Authorization Code Flow](/flows/concepts/auth-code)
+* [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+* [Device Authorization Flow](/flows/concepts/device-auth)
+* [Resource Owner Password Credentials Exchange](/api-auth/tutorials/adoption/password)
+
+## Maintaining user sessions in SPAs
+
+Until very recently, SPAs maintained the user’s session by using the [Authorization Code Flow with PKCE](/flows/concepts/auth-code-pkce) in conjunction with [Silent Authentication](/api-auth/tutorials/silent-authentication). Recent developments in browser privacy technology, such as Intelligent Tracking Prevention (ITP) prevent access to the Auth0 session cookie, thereby requiring users to reauthenticate. 
+
+![Refresh Token and Access Tokens](/media/articles/tokens/rt-and-at.png)
+
+Unfortunately, long-lived Refresh Tokens are not suitable for SPAs because there is no persistent storage mechanism in a browser that can assure access by the intended application only. As there are vulnerabilities that can be exploited to obtain these high-value artifacts and grant malicious actors access to protected resources, using Refresh Tokens in SPAs has been strongly discouraged. 
+
+Refresh Token Rotation offers a remediation to end-user sessions being lost due to side-effects of browser privacy mechanisms. Because Refresh Token Rotation does not rely on access to the Auth0 session cookie, it is not affected by ITP or similar mechanisms.
+
+The following state diagram illustrates how Refresh Token Rotation is used in conjunction with the Authorization Code Flow with PKCE, but the general principle of getting a new refresh token with each exchange applies to all supported flows.
+
+![Refresh Token Rotation State Diagram](/media/articles/tokens/rtr-state-diagram.png)
+
+This means you can safely use Refresh Tokens to mitigate the adverse effects of browser privacy tools and provide continuous access to end-users without disrupting the user experience.
+
+## Automatic reuse detection
+
+When a client needs a new Access Token, it sends the Refresh Token with the request to Auth0 to get a new token pair. As soon as the new pair is issued by Auth0, the Refresh Token used in the request is invalidated. This safeguards your app from replay attacks resulting from compromised tokens.
+
+Without enforcing sender-constraint, it’s impossible for the authorization server to know which actor is legitimate or malicious in the event of a replay attack. So it’s important that the most recently issued Refresh Token is also immediately invalidated when a previously-used Refresh Token (already invalidated) is sent to the authorization server. This prevents any Refresh Tokens in the same token family (all Refresh Tokens descending from the original Refresh Token issued for the client) from being used to get new Access Tokens.
+
+For example, consider the following scenario: 
+
+![Reuse Detection](/media/articles/tokens/reuse-detection1.png)
+
+1. Legitimate Client has **Refresh Token 1**, and it is leaked to or stolen by Malicious Client. 
+2. Legitimate Client uses **Refresh Token 1** to get a new Refresh Token/Access Token pair.
+3. Auth0 returns **Refresh Token 2/Access Token 2**.
+4. Malicious Client then attempts to use **Refresh Token 1** to get an Access Token. Auth0 recognizes that Refresh Token 1 is being reused, and immediately invalidates the Refresh Token family, including **Refresh Token 2**.
+5. Auth0 returns an **Access Denied** response to Malicious Client.
+6. **Access Token 2** expires and Legitimate Client attempts to use **Refresh Token 2** to request a new token pair. Auth0 returns an **Access Denied** response to Legitimate Client.
+7. Re-authentication is required.
+
+This protection mechanism works regardless of whether the legitimate client or the malicious client is able to exchange **Refresh Token 1** for a new token pair before the other. As soon as reuse is detected, all subsequent requests will be denied until the user re-authenticates. When reuse is detected, Auth0 captures detected reuse events (such as `ferrt` indicating a failed exchange) in logs. This can be especially useful in conjunction with Auth0’s log streaming capabilities.
+
+Another example is where the malicious client steals Refresh Token 1 and successfully uses it to acquire an Access Token before the legitimate client attempts to use Refresh Token 1. In this case, the malicious client’s access would be short-lived because Refresh Token 2 (or any subsequently issued RTs) is automatically revoked when the legitimate client tries to use Refresh Token 1, as shown in the following diagram:
+
+![Reuse Detection](/media/articles/tokens/reuse-detection2.png)
+
+## SDK support
+
+The following SDKs include support for Refresh Token Rotation and automatic reuse detection. 
+
+* [Auth0 SPA SDK](/libraries/auth0-spa-js)
+* [Auth0 Swift (iOS) SDK](/libraries/auth0-swift)
+* [Auth0 Android SDK](/libraries/auth0-android)
+
+You can opt-in to storing tokens in either local storage or browser memory, the default being in browser memory. See [Token Storage](/tokens/concepts/token-storage) for details.
+
+## Keep reading
+
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+* [Use Refresh Token Rotation](/tokens/guides/use-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12)
diff --git a/ja-jp/articles/tokens/concepts/refresh-tokens.md b/ja-jp/articles/tokens/concepts/refresh-tokens.md
new file mode 100644
index 0000000000..8879806c8c
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/refresh-tokens.md
@@ -0,0 +1,82 @@
+---
+description: Understand how refresh tokens work to allow the application to ask Auth0 to issue a new Access Token or ID Token without having to re-authenticate the user.
+topics:
+  - tokens
+  - refresh-tokens
+contentType: concept
+useCase:
+  - invoke-api
+---
+# Refresh Tokens
+
+Auth0 issues an [Access Token](/tokens/concepts/access-tokens) or an [ID Token](/tokens/concepts/id-tokens) in response to an [authentication request](/api-auth). You can use Access Tokens to make authenticated calls to a secured API, while the ID Token contains user profile attributes represented in the form of *claims*. Both are [JWTs](/tokens/concepts/jwts) and therefore have expiration dates indicated using the `exp` claim, as well as security measures, like signatures. Typically, a user needs a new Access Token when gaining access to a resource for the first time, or after the previous Access Token granted to them expires.
+
+A Refresh Token is a special kind of token used to obtain a renewed Access Token. You can request new Access Tokens until the Refresh Token is blacklisted. Applications must [store Refresh Tokens securely](/tokens/concepts/token-storage) because they essentially allow a user to remain authenticated forever.
+
+For native applications, refresh tokens improve the authentication experience significantly. The user has to authenticate only once, through the web authentication process. Subsequent re-authentication can take place without user interaction, using the Refresh Token.
+
+You can increase security by using [Refresh Token rotation](/tokens/concepts/refresh-token-rotation) which issues a new Refresh Token and invalidates the predecessor token with each request made to Auth0 for a new Access Token. Rotating the Refresh Token reduces the risk of a compromised Refresh Token. 
+
+::: panel OIDC-Conformant Apps
+The Refresh Token behavior is applicable to [OIDC-conformant applications](/api-auth/tutorials/adoption/oidc-conformant). You can configure an application to be OIDC-conformant in one of the following two ways:
+
+1. Enabling the **OIDC Conformant** flag for an app.
+2. Passing an `audience` to the `/authorize` endpoint of the Authentication API.
+
+For more information on our authentication pipeline, see [Introducing OIDC-Conformant Authentication](/api-auth/intro).
+:::
+
+## SDK support
+
+### Web apps
+
+Auth0 SDKs support Refresh Tokens including: 
+
+- [Node.js](/quickstart/webapp/nodejs)
+- [ASP.NET Core](/quickstart/webapp/aspnet-core)
+- [PHP](/quickstart/webapp/php)
+- [Java](/dev-centers/java)
+
+For a complete listing, see [Quickstarts](/quickstart/webapp).
+
+### Single-page apps
+
+Providing secure authentication in SPAs has a number of challenges based on your application’s use case. New browser privacy controls like Intelligent Tracking Prevention (ITP) adversely impact the user experience in SPAs by preventing access to third-party cookies.
+
+Auth0 recommends using [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation) which provides a secure method for using Refresh Tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
+
+Auth0’s former guidance was to use the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) in conjuntion with [Silent Authentication](/api-auth/tutorials/silent-authentication) in SPAs. This is more secure solution than the Implicit Flow but not as secure as the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce) with Refresh Token Rotation. 
+
+### Native/Mobile apps
+
+For information on using Refresh Tokens with our mobile SDKs, see:
+
+* [Mobile / Native Quickstarts](/quickstart/native)
+* [Lock Android: Refreshing JWT Tokens](/libraries/lock-android/refresh-jwt-tokens)
+* [Lock iOS: Saving and Refreshing JWT Tokens](/libraries/lock-ios/v2)
+
+## Restrictions and limitations
+
+* You can only get a Refresh Token if you are implementing the following flows:
+  - [Authorization Code Flow](/flows/concepts/auth-code)
+  - [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+  - [Resource Owner Password Grant](/api-auth/grant/password)
+  - [Device Authorization Flow](/flows/concepts/device-auth)
+
+* If you limit offline access to your API, a safeguard configured via the **Allow Offline Access** switch on the [API Settings](${manage_url}/#/apis), Auth0 will not return a Refresh Token for the API (even if you include the `offline_access` scope in your request).
+
+* Rules will run for the [Refresh Token Exchange](/tokens/guides/use-refresh-tokens). To execute special logic, you can look at the `context.protocol` property in your rule. If the value is `oauth2-refresh-token`, then the rule is running during the exchange.
+
+  ::: warning
+  If you try to do a redirect with context.redirect, the authentication flow will return an error.
+  :::
+
+* If you have added custom claims to your tokens using a rule, the custom claims will appear in new tokens issued when using a Refresh Token for as long as your rule is in place. Although new tokens do not automatically inherit custom claims, rules run during the Refresh Token flow, so the same code will be executed. This allows you to add or change custom claims in newly-issued tokens without forcing previously-authorized applications to obtain a new Refresh Token.
+
+## Keep reading
+
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation)
+* [Token Storage](/tokens/concepts/token-storage)
diff --git a/ja-jp/articles/tokens/concepts/signing-algorithms.md b/ja-jp/articles/tokens/concepts/signing-algorithms.md
new file mode 100644
index 0000000000..5a47dcd750
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/signing-algorithms.md
@@ -0,0 +1,46 @@
+---
+title: Signing Algorithms
+description: Learn the basics of signing algorithms and recommendations for configuring them in the Auth0 Dashboard.
+topics:
+  - api-authentication
+  - oidc
+  - apis
+  - applications
+  - signing-algorithms
+  - RS256
+  - HS256
+contentType: concept
+useCase:
+  - add-login
+  - secure-api
+  - call-api
+---
+# Signing Algorithms
+
+The algorithm used to sign tokens issued for your application or API. A [signature](/tokens/references/jwt-structure#signature) is part of a [JSON Web Token (JWT)](/tokens/concepts/jwts) and is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way.
+
+You can select from the following signing algorithms:
+
+- **RS256** (RSA Signature with SHA-256): An [asymmetric algorithm](https://en.wikipedia.org/wiki/Public-key_cryptography), which means that there are two keys: one public key and one private key that must be kept secret. Auth0 has the private key used to generate the signature, and the consumer of the JWT retrieves a public key from the metadata endpoints provided by Auth0 and uses it to [validate the JWT signature](/tokens/guides/validate-jwts).
+
+- **HS256** (HMAC with SHA-256): A [symmetric algorithm](https://en.wikipedia.org/wiki/Symmetric-key_algorithm), which means that there is only one private key that must be kept secret, and it is shared between the two parties. Since the same key is used both to generate the signature and to validate it, care must be taken to ensure that the key is not compromised. This private key (or secret) is created when you [register your Application](/getting-started/set-up-app) (**Client Secret**) or [API](/getting-started/set-up-api) (**Signing Secret**) and choose the HS256 signing algorithm.
+
+## Our recommendation
+
+The most secure practice, and our recommendation, is to use **RS256** because:
+
+- With RS256, you are sure that only the holder of the private key (Auth0) can sign tokens, while anyone can check if the token is valid using the public key.
+
+- With RS256, you can request a token that is valid for multiple audiences.
+
+- With RS256, if the private key is compromised, you can implement key rotation without having to re-deploy your application or API with the new secret (which you would have to do if using HS256).
+
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JSON Web Key Set](/tokens/concepts/jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/ja-jp/articles/tokens/concepts/token-storage.md b/ja-jp/articles/tokens/concepts/token-storage.md
new file mode 100644
index 0000000000..c880df666c
--- /dev/null
+++ b/ja-jp/articles/tokens/concepts/token-storage.md
@@ -0,0 +1,108 @@
+---
+description: Understand how and where to store tokens used in token-based authentication.
+toc: true 
+topics:
+  - security
+  - tokens
+  - token storage
+contentType:
+  - concept
+useCase:
+  - store-tokens
+---
+
+# Token Storage
+
+Securing single page apps (SPAs) that make API calls come with their own set of concerns. You'll need to ensure that tokens and other sensitive data are not vulnerable to [cross-site scripting](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) and can't be read by malicious JavaScript.
+
+## Next.js static site scenarios
+
+When you're building a Next.js application, authentication might be needed in the following cases:
+
+1. When accessing a page
+2. When accessing an API route
+3. When your application calls an API hosted outside of your Next.js application on behalf of the user
+
+Where a server is available, your app can handle the interaction with Auth0 and create a session, but in this model, we don't have a backend. All of the work happens on the frontend:
+
+1. The user is redirected to Auth0.
+2. When the user is successfully signed in, they will be redirected back to the application.
+3. The client-side will complete the code exchange with Auth0 and retrieve the user's `id_token` and `access_token` which will be stored in memory.
+
+![In-Memory Token Storage](/media/articles/tokens/in-memory-token-storage.png)
+
+## Traditional web app scenarios
+
+If your app is using a sign in scenario that doesn't require API calls, only an ID Token is required. There is no need to store it. You can validate it and get the data from it that you required. 
+
+If your app needs to call APIs on behalf of the user, Access Tokens and (optionally) Refresh Tokens are needed. These can be stored server-side or in a session cookie. The cookie needs to be encrypted and have a maximum size of 4 KB. If the data to be stored is large, storing tokens in the session cookie is not a viable option. 
+
+Use the following flow types in these scenarios: 
+
+- [Authorization Code Flow](/flows/concepts/auth-code)
+- [Regular Web App Quickstarts](/quickstart/webapp)
+
+## Native/Mobile app scenarios
+
+Store tokens in a secure storage that the OS offers and limit access to that storage. For example, leverage KeyStore for Android and KeyChain for iOS.
+
+Use the following flow types in these scenarios:
+
+- [Authorization Code Flow with Proof Key for Code Exchange](/flows/concepts/auth-code-pkce)
+- [Saving and Renewing Tokens for Android](/libraries/auth0-android/save-and-refresh-tokens)
+- [Saving and Renewing Tokens for Swift](/libraries/auth0-swift/save-and-refresh-jwt-tokens)
+- [Native/Mobile Apps Quickstarts](/quickstart/native)
+
+## Single-page app scenarios
+
+We recommend using the [Auth0 SPA SDK](/libraries/auth0-spa-js) to handle token storage, session management, and other details for you.
+
+When the SPA calls only an API that is served from a domain that can share cookies with the domain of the SPA, no tokens are needed. OAuth adds additional attack vectors without providing any additional value and should be avoided in favor of a traditional cookie-based approach. For an overview of this approach and an example implementation, see [SPA  Authentication Using Cookies](/login/spa/authenticate-with-cookies).
+
+When the SPA calls multiple APIs that reside in a different domain, access and optionally refresh tokens are needed.
+
+-  If the SPA backend can handle the API calls, handle tokens server-side using:
+    - [Authorization Code Flow](/flows/concepts/auth-code)
+    - [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/concepts/auth-code-pkce)
+
+- If the SPA backend cannot handle the API calls, the tokens should be stored in the SPA backend but the SPA needs to fetch the tokens from the backend to perform requests to the API. A protocol needs to be established between the backend and the SPA to allow the secure transfer of the token from the backend to the SPA.
+
+- If you have a SPA with **no** corresponding backend server, your SPA should request new tokens on login and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.
+
+<%= include('../_includes/_rtr_enabled') %>
+
+### Browser in-memory scenarios
+
+Auth0 recommends storing tokens in browser memory as the most secure option. Using [Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) to handle the transmission and storage of tokens is the best way to protect the tokens, as Web Workers run in a separate global scope than the rest of the application. Use [Auth0 SPA SDK](/libraries/auth0-spa-js) whose default storage option is in-memory storage leveraging Web Workers.
+
+If you cannot use Web Workers, Auth0 recommends as an alternative that you use [JavaScript closures](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Emulating_private_methods_with_closures) to emulate private methods.
+
+ Use [Auth0 SPA SDK](/libraries/auth0-spa-js) whose default storage option is in-memory storage to leverage both Web Workers and JavaScript closures depending on the type of token.
+
+::: warning
+The in-memory method for browser storage **does not** provide persistence across page refreshes and browser tabs. 
+:::
+
+### Browser local storage scenarios
+
+Using browser local storage can be viable alternative to mechanisms that require retrieving the Access Token from an iframe and to cookie-based authentication across domains when these are not possible due to browser restrictions (e.g. ITP2).
+
+::: warning
+Storing tokens in browser local storage provides persistence across page refreshes and browser tabs, however if an attacker can achieve running JavaScript in the SPA using a cross-site scripting (XSS) attack, they can retrieve the tokens stored in local storage. A vulnerability leading to a successful XSS attack can be either in the SPA source code or in any third-party JavaScript code (such as bootstrap, jQuery, or Google Analytics) included in the SPA.
+:::
+
+::: panel Reduce Security Risks with Local Storage
+If the SPA is using Implicit (although it is recommended that authorization code with PKCE is used) or Hybrid Flows, the absolute token expiration time can be reduced. This will reduce the impact of a reflected XSS (but not of a persistent one). To do so, go to **Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds)**.
+
+Reduce the amount of third party JavaScript code included from a source outside your domain to the minimum needed (such as links to jQuery, Bootstrap, Google Analytics etc.) Reducing third-party JS code reduces the possibility of an XSS vulnerability. Performing [Subresource Integrity (SRI)](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) checking in third-party scripts (where possible) to verify that the resources fetched are delivered without unexpected manipulation is also more secure.
+:::
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Auth0 SPA SDK](https://github.com/auth0/auth0-spa-js)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
+* [Using Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers)
diff --git a/ja-jp/articles/tokens/guides/configure-refresh-token-rotation.md b/ja-jp/articles/tokens/guides/configure-refresh-token-rotation.md
new file mode 100644
index 0000000000..835ee5a4bb
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/configure-refresh-token-rotation.md
@@ -0,0 +1,94 @@
+---
+description: Learn how to configure Refresh Token rotation.
+topics:
+  - tokens
+  - refresh-tokens
+  - refresh-token-rotation
+contentType: how-to
+useCase:
+  - enable-refresh-token-rotation
+  - configure-refresh-token-rotation
+---
+# Configure Refresh Token Rotation
+
+Configure Refresh Token Rotation for each application using the Dashboard or the auth-spa-js SDK. When Refresh Token Rotation is enabled, the transition for the end-user is seamless. The application uses the previous non-rotating Refresh Token which has expired and swaps it for a rotating Refresh Token. 
+
+Migration scenarios accommodate automatic token revocation when migrating from a non-rotating Refresh Token to a rotating Refresh Token and vice-versa.
+
+- Exchanging a non-rotating Refresh Token when Refresh Token Rotation is enabled deletes all the non-rotating tokens issued for the same `client_id`, resource server, and user and tenant.
+- Exchanging a rotating Refresh Token when Refresh Token Rotation is disabled issues a non-rotating Refresh Token and revokes the Rotating Refresh Token family.
+
+## Using the Dashboard
+
+1. Go to [Dashboard > Application Settings](${manage_url}/#/applications). Scroll to the **Application Tokens** section. Set **Refresh Token Behavior** to **Rotating**. 
+
+    ![Application Token Settings - Rotating Refresh Tokens](/media/articles/tokens/rotating-tokens.png)
+
+2. Set **Refresh Token Lifetime (Absolute)** for when a Refresh Token will expire in seconds. 
+
+    The Refresh Token lifetime is the *absolute* lifetime that Refresh Tokens can be used to get new Access Tokens, after which time, the user has to re-authenticate. The default Refresh Token expiration period is 30 days (2592000 seconds). You can configure up to 90 days (7776000 seconds). *The lifetime does not extend when tokens are rotated.* 
+
+3. Set **Refresh Token Reuse Interval** to allow a reuse interval for a Refresh Token to account for lag between request and response time due to the end-user's network, device, and/or location (in seconds). 
+
+4. Click **Save Changes**.
+
+::: note
+Refresh Token Rotation is only supported for OIDC-conformant applications having the Refresh Token grant type enabled.
+:::
+
+## Using the Auth0 SPA SDK
+
+You can also use the Auth0 SPA SDK to enable Refresh Token rotation:
+
+1. Install the latest version of the `auth0-spa-js` SDK.
+
+    ```text
+    npm install @auth0/auth0-spa-js
+    ```
+
+2. Enable the feature on the SDK by setting `useRefreshTokens: true` to start sending the `offline_access` scope.
+
+    ```js
+    const auth0 = await createAuth0Client({
+      domain: '',
+      client_id: '',
+      audience: '',
+      useRefreshTokens: true
+    });
+    ```
+
+3. Configure the Refresh Token rotation settings. For example:  
+
+    ```js
+    PATCH /api/v2/clients/{client_id}
+    {
+      "refresh_token": {
+        "rotation_type": "rotating",
+        "expiration_type": "expiring",
+        "token_lifetime": "2592000",
+        "leeway": 3
+      }
+    }
+    ```
+
+    | Attribute | Description |
+    | -- | -- |
+    | `rotation_type` | Text string: "rotating" or "non-rotating" |
+    | `expiration_type` | Text string: "expiring" or "non-expiring" |
+    | `token_lifetime` | The default Refresh Token expiration period, when Refresh Token Rotation is enabled, is 30 days (2592000 seconds). You can configure up to 90 days (7776000 seconds). **The lifetime does not extend when tokens are rotated.** |
+    | `leeway` | Allow the same Refresh Token to be used within the time period to account for potential network concurrency issues that would otherwise invalidate the token should the client attempt to retry using the same Refresh Token. By default leeway is disabled. Configurable in seconds. |
+
+    ::: panel What is *leeway*?
+    The concept of *leeway* is to avoid concurrency issues when exchanging the Rotating Refresh Token multiple times within a given timeframe. During the leeway window which is configurable on a per second basis, the breach detection features don't apply and therefore a new rotating Refresh Token is issued. Only the previous token can be reused, meaning if the second to last one is exchanged, the breach detection will apply. 
+    :::
+
+## Refresh Tokens and reuse detection
+
+If a previously invalidated token is used, the entire set of Refresh Tokens issued since that invalidated token was issued will immediately be revoked along with the grant, requiring the end-user to re-authenticate. See [Automatic Reuse Detection](/tokens/concepts/refresh-token-rotation#automatic-reuse-detection) for an example. 
+
+## Keep reading
+
+* [Use Refresh Token Rotation](/tokens/guides/use-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [Token Storage](/tokens/concepts/token-storage)
diff --git a/ja-jp/articles/tokens/guides/create-namespaced-custom-claims.md b/ja-jp/articles/tokens/guides/create-namespaced-custom-claims.md
new file mode 100644
index 0000000000..fa954ad2aa
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/create-namespaced-custom-claims.md
@@ -0,0 +1,49 @@
+---
+title: Create Namespaced Custom Claims
+description: Learn about creating collision-resistant names for custom claims by using namespacing.
+toc: false
+topics:
+  - tokens
+  - jwt
+  - claims
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - secure-api
+---
+# Create Namespaced Custom Claims
+
+To keep your custom claims from colliding with any [reserved claims](/tokens/concepts/jwt-claims#reserved-claims) or claims from other resources, you must give them a globally unique name using a namespaced format.
+
+<%= include('../../_includes/_enforce-claim-namespacing') %>
+
+Namespaces are arbitrary identifiers, so technically you can call your namespace anything you want. However, using the URI of a resource you control is conventional (following the way XML namespaces are defined).
+
+Example namespace:
+`http://www.myexample.com/`
+
+Because a URI must be unique and because this URI is under your control, you can generally avoid the risk that someone else is using the same namespace. You can also optionally store the definition of your namespace at the URI, making your namespace self-documenting.
+
+## Guidelines
+
+* Any non-Auth0 `HTTP` or `HTTPS` URL can be used as a namespace identifier. Auth0 domains, which cannot be used as namespace identifiers, include: `auth0.com`, `webtask.io`, and `webtask.run`.
+
+* Although ideally you will use a URI that you control, the namespace URI does not have to point to an actual resource. It is only being used as an identifier; it will not be called.
+
+* You can use any number of namespaces.
+
+## Add a namespace to a claim
+
+Once you have chosen your namespace, you append the claim to it to create a namespaced claim, which can be added to a token.
+
+Example namespaced claim:
+`http://www.myexample.com/favorite_color`
+
+For an example showing how to add custom claims to a token, see [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+## Read more
+
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [OpenID Connect Scopes: Standard Claims](/scopes/current/oidc-scopes#standard-claims)
+* [Sample Use Cases: Scopes and Claims](/scopes/current/sample-use-cases)
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/guides/disable-refresh-token-rotation.md b/ja-jp/articles/tokens/guides/disable-refresh-token-rotation.md
new file mode 100644
index 0000000000..44e2c223ad
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/disable-refresh-token-rotation.md
@@ -0,0 +1,51 @@
+---
+description: Learn how to disable Refresh Token rotation.
+topics:
+  - tokens
+  - refresh-tokens
+  - refresh-token-rotation
+contentType: how-to
+useCase:
+  - disable-refresh-token-rotation
+  - configure-refresh-token-rotation
+---
+# Disable Refresh Token Rotation
+
+You can disable Refresh Token Rotation for each application using Dashboard or the Management API.
+
+## Using the Dashboard
+
+1. Go to [Dashboard > Application Settings](${manage_url}/#/applications). Scroll to the **Application Tokens** section. Next to **Refresh Token Behavior** select **Non-Rotating**.  
+
+    ![Application Token Settings - Non-Rotating Refresh Tokens](/media/articles/tokens/non-rotating-tokens.png)
+
+2. Click **Save Changes**.
+
+## Using the Management API
+
+2. Disable Refresh Token Rotation for each application using the Management API: 
+
+    ```js
+    const auth0 = await createAuth0Client({
+      domain: '',
+      client_id: '',
+      audience: '',
+      useRefreshTokens: false
+    });
+    ```
+
+2. Configure the non-rotating Refresh Token settings as follows:
+
+    ```js
+    PATCH /api/v2/clients/{client_id}
+    {
+      "refresh_token": {
+        "rotation_type": "non-rotating",
+        "expiration_type": "non-expiring"
+      }
+    }
+    ```
+
+## Keep reading
+
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
diff --git a/ja-jp/articles/tokens/guides/get-access-tokens.md b/ja-jp/articles/tokens/guides/get-access-tokens.md
new file mode 100644
index 0000000000..fc658579f4
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/get-access-tokens.md
@@ -0,0 +1,60 @@
+---
+title: Get Access Tokens
+description: Learn how to request Access Tokens using the Authorize endpoint when authenticating users and include the target audience and scope of access requested by the app and granted by the user.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+---
+# Get Access Tokens
+
+To get an [Access Token](/tokens/concepts/access-tokens), you need to request one when [authenticating](/application-auth) a user.
+
+Auth0 makes it easy for your app to authenticate users using:
+
+* [Quickstarts](/quickstarts): The easiest way to implement authentication, which can show you how to use [Universal Login](/universal-login), the [Lock widget](/lock), and Auth0's language and framework-specific [SDKs](/libraries#sdks). Our [Lock documentation](/libraries/lock) and [Auth0.js documentation](/libraries/auth0js) both provide specifics about retrieving an Access Token after authentication.
+* [Authentication API](/api/authentication): If you prefer to roll your own, you can call our API directly. First, you need to know [which flow to use](/api-auth/which-oauth-flow-to-use) before following the appropriate [flow tutorial](/flows).
+
+## Control Access Token audience 
+
+When a user authenticates, you request an Access Token and include the target audience and scope of access in your request. This access is both requested by the application and granted by the user during authentication using the [Authorize endpoint](/api/authentication#authorize-application).
+
+You may configure your tenant to always include a [default audience](/dashboard/reference/settings-tenant#api-authorization-settings).
+
+| Token Use | Format | Requested Audience | Requested Scope |
+|-----------|--------|--------------------|-------|
+| [/userinfo endpoint](/api/authentication#get-user-info) | [Opaque](/tokens/concepts/access-tokens#opaque-access-tokens) | tenant name (`${account.namespace}`), no value for `audience` parameter, no `audience` parameter passed | `openid` |
+| Auth0 Management API | [JWT](/tokens/concepts/jwts) | Management API v2 identifier (`https://{tenant}.auth0.com/api/v2/`) |  |
+| Your own custom API | [JWT](/tokens/concepts/jwts) | The API Identifier for your custom API registered in the Auth0 Dashboard |  |
+
+::: panel Multiple Audiences
+In only one specific instance, Access Tokens can have multiple target audiences. This requires that your custom API's [signing algorithm](/tokens/concepts/signing-algorithms) is set to **RS256**. 
+
+If you specify an `audience` of your custom API identifier and a `scope` of `openid`, then the resulting Access Token's `aud` claim will be an array rather than a string, and the Access Token will be valid for both your custom API and for the `/userinfo` endpoint. Other than in the use case of a single custom API as well as Auth0's `/userinfo` endpoint, your Access Tokens will be unable to have two or more audiences.
+:::
+
+::: panel Custom Domains and the Management API
+Auth0 issues tokens with an issuer (`iss` claim) of whichever domain you used when requesting the token. [Custom domain](/custom-domains) users may use either their custom domain or their Auth0 domain. For example, say you have a custom domain of **https://login.northwind.com**. If you request an Access Token from **https://login.northwind.com/authorize**, your token's `iss` claim will be **https://login.northwind.com/**. However, if you request an Access Token from **https://northwind.auth0.com/authorize**, your token's `iss` claim will be **https://northwind.auth0.com/**. 
+
+For an Access Token with the target audience of the [Auth0 Management API](/api/management/v2), if you have requested an Access Token from your custom domain, then you **must** call the Management API from your custom domain or else your Access Token will be considered invalid.
+:::
+
+## Renew Access Tokens
+
+By default, an Access Token for a Custom API is valid for 86400 seconds (24 hours). If there are security concerns, you can [shorten the time period before the token expires](/dashboard/guides/apis/update-token-lifetime). 
+
+After an Access Token has expired, you may want to renew your Access Token. To renew the Access Token, you can either reauthenticate the user using Auth0 or use a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Use Access Tokens](/tokens/guides/use-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Token](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/ja-jp/articles/tokens/guides/get-id-tokens.md b/ja-jp/articles/tokens/guides/get-id-tokens.md
new file mode 100644
index 0000000000..edaec2e697
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/get-id-tokens.md
@@ -0,0 +1,47 @@
+---
+title: Get ID Tokens
+description: Learn how to request an ID Token when authenticating users that includes claims about the user by including OIDC scopes.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Get ID Tokens
+
+To get an [ID Token](/tokens/concepts/id-tokens), you need to request one when [authenticating](/application-auth) a user. Auth0 makes it easy for your app to authenticate users using:
+
+* [Quickstarts](/quickstarts): The easiest way to implement authentication, which can show you how to use [Universal Login](/universal-login), the [Lock widget](/lock), and Auth0's language and framework-specific [SDKs](/libraries#sdks). Our [Lock documentation](/libraries/lock) and [Auth0.js documentation](/libraries/auth0js) both provide specifics about retrieving an ID Token after authentication.
+* [Authentication API](/api/authentication): If you prefer to roll your own, you can call our API directly. First, you need to know [which flow to use](/api-auth/which-oauth-flow-to-use) before following the appropriate [flow tutorial](/flows).
+
+## Control ID Token contents
+
+You control which claims about the authenticated user are included in the ID Token consumed by your application by including specific [OpenID Connect Scopes](/scopes/current/oidc-scopes) in the `scope` parameter when you request tokens while authenticating users.
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a rule. 
+:::
+
+As with any other [JWTs](/tokens/concepts/jwts#security), you should follow [token best practices](/best-practices/token-best-practices) when using ID Tokens and [validate an ID Token](/tokens/guides/validate-id-tokens) before assuming that its contents can be trusted.
+
+## Renew ID Tokens
+
+By default, an ID Token is valid for 36000 seconds (10 hours). If there are security concerns, you can [shorten the time period before the token expires](/dashboard/guides/applications/update-token-lifetime), but remember that one of the purposes of this token is to improve performance by caching user information. 
+
+After an ID Token has expired, you may want to renew your ID Token. To renew the ID Token, you can either reauthenticate the user using Auth0, or use a [Refresh Token](/tokens/concepts/refresh-tokens).
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [OpenID Connect Scopes](/scopes/oidc-scopes)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/ja-jp/articles/tokens/guides/get-refresh-tokens.md b/ja-jp/articles/tokens/guides/get-refresh-tokens.md
new file mode 100644
index 0000000000..a302814794
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/get-refresh-tokens.md
@@ -0,0 +1,99 @@
+---
+title: Get Refresh Tokens
+description: Learn how to get a Refresh Token when you initiate a request using the Authorize endpoint.
+topics:
+  - access-tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Get Refresh Tokens
+
+To get a Refresh Token, you must include the `offline_access` [scope](/scopes) when you initiate an authentication request through the [authorize](/api/authentication/reference#authorize-application) endpoint.
+
+For example, if you are using the [Authorization Code Flow](/flows/concepts/auth-code), the authentication request would look like the following:
+
+```text
+https://${account.namespace}/authorize?
+    audience={API_AUDIENCE}&
+    scope=offline_access&
+    response_type=code&
+    client_id=${account.clientId}&
+    redirect_uri=${account.callback}&
+    state={OPAQUE_VALUE}
+```
+
+The Refresh Token is stored in session. Then, when a session needs to be refreshed (for example, a preconfigured timeframe has passed or the user tries to perform a sensitive operation), the app uses the Refresh Token on the backend to obtain a new ID Token, using the `/oauth/token` endpoint with `grant_type=refresh_token`.
+
+Once the user authenticates successfully, the application will be redirected to the `redirect_uri`, with a `code` as part of the URL: `${account.callback}?code=BPPLN3Z4qCTvSNOy`. You can exchange this code with an Access Token using the `/oauth/token` endpoint.
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "authorization_code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "code",
+        "value": "YOUR_AUTHORIZATION_CODE"
+      },
+      {
+        "name": "redirect_uri",
+        "value": "${account.callback}"
+      }
+    ]
+  }
+}
+```
+
+The response should contain an Access Token and a Refresh Token.
+
+```text
+{
+  "access_token": "eyJz93a...k4laUWw",
+  "refresh_token": "GEbRxBN...edjnXbL",
+  "token_type": "Bearer"
+}
+```
+
+If you are requesting a Refresh Token for a mobile app using the corresponding Native Client (which is public), then you don't need to send the `client_secret` in the request since it's only required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications).
+
+::: warning
+Refresh Tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever.
+:::
+
+For more information on how to implement this using the Authorization Code Flow, refer to our tutorial, [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code). For other grants, see [API Authorization](/api-auth).
+
+::: note
+If the response did not include a Refresh Token, check that you comply with the [Restrictions](#restrictions-on-refresh-token-usage) listed in this document.
+:::
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Revoke Refresh Tokens](tokens/guides/revoke-refresh-tokens)
diff --git a/ja-jp/articles/tokens/guides/locate-jwks.md b/ja-jp/articles/tokens/guides/locate-jwks.md
new file mode 100644
index 0000000000..9f990231aa
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/locate-jwks.md
@@ -0,0 +1,45 @@
+---
+title: Locate JSON Web Key Sets
+description: Learn how to use the JSON Web Keys (JWKs) discovered using the JSON Web Key Set (JWKS) endpoint to verify a JWT signature.
+topics:
+  - tokens
+  - jwks
+  - jwt
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# Locate JSON Web Key Sets
+
+Auth0 exposes a discovery endpoint, which exists at `https://${account.namespace}/.well-known/openid-configuration`. You can use this endpoint to configure your application or API to automatically locate the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) endpoint (`jwks_uri`), which contains the JWKS used to sign all Auth0-issued JSON Web Tokens (JWTs) signed with the RS256 [signing algorithm](/tokens/concepts/signing-algorithms).
+
+When [validating a JWT](/tokens/guides/validate-jwts) using a JWKS, you will need to:
+
+1. Retrieve the JWKS from the Auth0 discovery endpoint, and filter for potential signing keys (e.g., any keys missing a public key or with a `kid` property).
+2. Grab the `kid` property from the Header of the decoded JWT.
+3. Search your filtered JWKS for the key with the matching `kid` property.
+4. Build a certificate using the corresponding `x5c` property in your JWKS.
+5. Use the certificate to verify the JWT's signature.
+
+For an example that uses JWKS to verify a JWT's signature, check out our [Backend/API Quickstarts](/quickstart/backend).
+
+For more info about the structure of a JWT, see [JSON Web Token Structure](/tokens/references/jwt-structure).
+
+::: note
+It's good practice to assume that multiple signing keys could be present in your JWKS. This may seem unnecessary since the Auth0 JWKS endpoint typically contains a single signing key; however, multiple keys can be found in the JWKS when rotating signing certificates.
+:::
+
+::: panel Best Practice
+You can cache your signing keys to improve application performance and avoid running into [rate limits](/policies/rate-limits), but you will want to make sure that if decoding a token fails, you invalidate the cache and retrieve new signing keys before trying **only one** more time.
+:::
+
+## Keep reading
+
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [Validate a JSON Web Token](/tokens/guides/validate-jwt)
+* [Backend/API Quickstarts](/quickstart/backend)
diff --git a/ja-jp/articles/tokens/guides/manage-signing-keys.md b/ja-jp/articles/tokens/guides/manage-signing-keys.md
new file mode 100644
index 0000000000..a15dd9ebb5
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/manage-signing-keys.md
@@ -0,0 +1,92 @@
+---
+description: Learn how to manage your tenant's application signing key, which is used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions that are sent to your application.
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+  - assertions
+  - SAML
+- signing-keys
+  - certificates
+contentType:
+  - concept
+useCase:
+  - invoke-api
+  - add-login
+  - secure-api
+---
+
+# Manage Signing Keys
+
+When you select our recommended [signing algorithm](/tokens/concepts/signing-algorithms) (RS256), Auth0 uses public-key cryptography to establish trust with your applications. In more general terms, we use a signing key that consists of a public and private key pair.
+
+When a user signs in to your application, we create a token that contains information about the user and sign the token using its private key before we send it back to your application. Auth0 secures the private key, which is unique per tenant.
+
+To verify that the token is valid and originated from Auth0, your application validates the token’s signature using the public key that we expose in the following ways:
+
+* your [tenant settings](/dashboard/reference/settings-tenant) in the Auth0 Dashboard
+* your tenant's [OpenID Connect discovery document](/tokens/guides/locate-jwks)
+
+For security purposes, you may manually rotate your signing key on a periodic basis.
+
+::: note
+We use the application signing key to sign assertions that are sent to applications. These assertions may include ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions that are sent to your application. Note that these keys are different from those used to sign interactions with connections, including signing SAML Requests to IdPs and encrypting responses from IdPs.
+
+By default, SAML assertions for IdP connections are signed, which we recommend. To get public keys you can use to configure the IdP, see [SAML Identity Provider Configuration: Signed Assertions](/protocols/saml/samlp#signed-assertions). 
+:::
+
+## Transition your application gracefully
+
+We have designed the rotation and revocation process to both support your personal preferences and promote a graceful transition for your application. If you prefer to update your application first, then rotate and revoke your key, you may do that. Alternatively, if you prefer to rotate your key, and then update your application and revoke your old key, you may also do that.
+
+For this reason, available keys include:
+
+* **Currently used**: Key that is currently being used to sign all new assertions.
+* **Previously used**: Key that was previously used, but has been rotated out. Assertions that were generated with this key will still work.
+* **Next in queue**: Key that is queued and will replace the current key when the application signing key is next rotated.
+
+::: warning
+Regardless of the method you use, you should always test on a development tenant before rotating application signing keys in production.
+:::
+
+## Rotate your signing key
+
+Auth0 allows you to manually rotate your application signing key on a periodic basis. So, for security purposes, any application that integrates with Auth0 should be prepared to handle key rotation regardless of how infrequently it may occur. If your application does not handle signing key rotation and attempts to use an expired signing key to verify a token, the authentication request will fail.
+
+Although Auth0 signs with only one signing key at a time, your tenant's [OpenID Connect discovery document](/tokens/guides/locate-jwks) always contains multiple keys. Specifically, it will always include both the current key and the next key, but it may also include the previous key if the previous key has not yet been revoked. To provide a seamless experience in case of emergency, your application should be able to use any of the keys specified in the document.
+
+You can rotate your application signing key using either the Auth0 Dashboard or Management API. To learn more, see [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys).
+
+::: warning
+All tokens signed with the previous key will still be valid until the previous key is revoked.
+
+Make sure you have updated your application with the new key before you revoke the previous key.
+:::
+
+## Manage your signing keys
+
+We provide other application security key management capabilities through both our Dashboard and Management API. Through the Management API and Dashboard, you can:
+
+* [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys)
+* [Revoke Signing Keys](/dashboard/guides/tenants/revoke-signing-keys)
+* [View Signing Keys](/dashboard/guides/tenants/view-signing-keys)
+
+In addition, the Dashboard allows you to view, copy, and download the signing certificates for your application signing keys. Additional application signing certificates links are as follows:
+
+* [CER](https://${account.namespace}/cer)
+* [PEM](https://${account.namespace}/pem)
+* [raw PEM](https://${account.namespace}/rawpem)
+* [PB7](https://${account.namespace}/pb7)
+* [Fingerprint](https://${account.namespace}/fingerprint)
+
+### Limitations
+
+* Rotating your signing key will be subject to a smaller rate limit than other API endpoints. To learn more, see [Rate Limits: Management API v2](/policies/rate-limits#management-api-v2).
+
+## Keep reading
+
+* [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys)
+* [Revoke Signing Keys](/dashboard/guides/tenants/revoke-signing-keys)
+* [View Signing Keys](/dashboard/guides/tenants/view-signing-keys)
+* [Locate JSON Web Key Sets (JWKS)](/tokens/guides/locate-jwks)
+* [Signing Algorithms](/tokens/concepts/signing-algorithms)
diff --git a/ja-jp/articles/tokens/guides/revoke-refresh-tokens.md b/ja-jp/articles/tokens/guides/revoke-refresh-tokens.md
new file mode 100644
index 0000000000..479b53b56b
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/revoke-refresh-tokens.md
@@ -0,0 +1,159 @@
+---
+title: Revoke Refresh Tokens
+description: Learn how to revoke a Refresh Token if it gets compromised using the Authentication API, the Management API, or the Auth0 Dashboard. 
+topics:
+  - access-tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Revoke Refresh Tokens
+
+Since Refresh Tokens never expire, it is essential to be able to revoke them in case they get compromised.
+
+For the Device Authorization Flow, the only way to force a device to reauthorize is to revoke the Refresh Token assigned to the device. To learn how, see [Unlink Devices from Users](/dashboard/guides/users/unlink-user-devices). Note that the device will not be forced to reauthorize until the current Access Token expires and the application tries to use the revoked Refresh Token.
+
+Auth0 handles token revocation as though the token has been potentially exposed to malicious adversaries. Therefore, each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant. This means that **all Refresh Tokens that have been issued for the same user, application, and audience will be revoked**.
+
+You can revoke a Refresh Token by:
+
+* Posting a request to [the Authentication API's /oauth/revoke endpoint](/api/authentication#revoke-refresh-token)
+* Posting a request to [the Management API's /api/v2/device-credentials endpoint](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) 
+* Using the [dashboard](${manage_url}).
+
+## Use the Authentication API
+
+To revoke a Refresh Token, you can send a `POST` request to `https://${account.namespace}/oauth/revoke`.
+
+Use the `/api/v2/device-credentials` endpoint to revoke Refresh Tokens. 
+
+::: note
+The `/oauth/revoke` endpoint revokes the entire grant not just a specific token.
+:::
+
+The API first validates the application credentials and then verifies whether the token was issued to the application making the revocation request.  If this validation fails, the request is refused, and the application is informed of the error. Next, the API invalidates the token. The invalidation takes place immediately, and the token cannot be used again after the revocation. Each revocation request invalidates all the tokens that have been issued for the same authorization grant.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/revoke",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData" : {
+      "mimeType": "application/json",
+      "text" : "{ \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"token\": \"YOUR_REFRESH_TOKEN\" }"
+    },
+    "headersSize" : 150,
+    "bodySize" : 0,
+    "comment" : ""
+}
+```
+
+Where:
+
+| Parameter        | Description |
+|:-----------------|:------------|
+| `client_id` 
    Required | Your application's Client ID. The application should match the one the Refresh Token was issued for. |
+| `client_secret` | Your application's Client Secret. Required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications). |
+| `token` 
    Required | The Refresh Token you want to revoke. |
+
+The application should match the one for which the Refresh Token was issued.
+
+::: panel Revoke a token without the Client Secret
+For applications that cannot keep the Client Secret safe (e.g., native apps), the [Revoke endpoint](/api/authentication#revoke-refresh-token) supports access without the Client Secret. However, the application itself must have the property `tokenEndpointAuthMethod` set to `none`. You can change the `tokenEndpointAuthMethod` value, either from the UI ([Dashboard > Clients > Application Settings](${manage_url}/#/applications/${account.clientId}/settings)), or using the [Management API](/api/management/v2#!/Clients/patch_clients_by_id).
+:::
+
+If the request is valid, the Refresh Token is revoked, and the response is `HTTP 200`, with an empty response body. Otherwise, the response body contains the error code and description.
+
+```json
+{
+  "error": "invalid_request|invalid_client",
+  "error_description": "Description of the error"
+}
+```
+
+The possible responses are:
+
+| HTTP Status | Description |
+| --- | --- |
+| 200 | The Refresh Token is revoked, does not exist, or was not issued to the application making the revocation request. The response body is empty. |
+| 400 | The required parameters were not sent in the request (`"error": "invalid_request"`). |
+| 401 | The request is not authorized (`"error": "invalid_client"`). Check that the application credentials (`client_id` and `client_secret`) are present in the request and hold valid values. |
+
+## Use the Management API
+
+To revoke a Refresh Token using the Auth0 Management API, you need the `id` of the Refresh Token you wish to revoke. To obtain a list of existing Refresh Tokens, call the [List device credentials](/api/management/v2#!/Device_Credentials/get_device_credentials) endpoint, specifying `type=refresh_token` and `user_id` with an Access Token containing `read:device_credentials` scope. To narrow the results, you can also specify the `client_id` associated with the token (if known).
+
+```text
+GET https://${account.namespace}/api/v2/device-credentials?
+  type=refresh_token
+  &client_id=
+  &user_id=
+
+{
+  "Authorization":   "Bearer {your_access_token}"
+}
+```
+
+Response body:
+
+```text
+[
+  {
+    "id": "dcr_dFJiaAxbEroQ5xxx",
+    "device_name": "my-device" // the value of 'device' provided in the /authorize call when creating the token
+  }
+]
+```
+
+To revoke a __Refresh Token__, call the [Delete a device credential](/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id) endpoint with an Access Token containing `delete:device_credentials` scope and the value of `id` obtained above:
+
+```text
+DELETE https://${account.namespace}/api/v2/device-credentials/{id}
+
+{
+  "Authorization":   "Bearer {your_access_token}"
+}
+
+```
+
+The response will be an **HTTP 204**: The credential no longer exists.
+
+::: note
+When using Refresh Token rotation, If a previously invalidated token is used, the entire set of Refresh Tokens issued since that invalidated token was issued will immediately be revoked, requiring the end-user to re-authenticate.
+
+- Use the `/oauth/revoke` endpoint to revoke a Refresh Token. This endpoint revokes the entire grant not just a specific token.
+
+- Use the `/api/v2/device-credentials` endpoint to revoke Refresh Tokens configured for rotation.
+:::
+
+## Use the Dashboard
+
+Strictly speaking, the following process shows you how to revoke a user's authorized access to the application that issued the token. This renders the Refresh Token invalid, which is functionally identical to revoking the token itself.
+
+To do this, go to the [Users section](${manage_url}/#/users) of the [dashboard](${manage_url}). Click the name of the user to view their *Details* page.
+
+Select the *Authorized Applications* tab. This page lists all the applications to which the user has authorized access. Revoking an authorized application also revokes its associated Refresh Tokens.
+
+To revoke the user's access to an authorized application, and hence invalidate the Refresh Token, click **Revoke**.
+
+![Revoke a Refresh Token using the dashboard](/media/articles/tokens/dashboard-revoke-refresh-token.png)
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
+* [Use Refresh Tokens](/tokens/guides/use-refresh-tokens)
+* [Refresh Tokens and Reuse Detection](/tokens/guides/configure-refresh-token-rotation#refresh-tokens-and-reuse-detection)
diff --git a/ja-jp/articles/tokens/guides/revoke-tokens.md b/ja-jp/articles/tokens/guides/revoke-tokens.md
new file mode 100644
index 0000000000..b6d495869f
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/revoke-tokens.md
@@ -0,0 +1,25 @@
+---
+description: Learn to use tokens to control user access.
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - add-login
+  - secure-api
+---
+
+# Revoke Tokens
+
+Once issued, Access Tokens and ID Tokens cannot be revoked in the same way as cookies with session ids for server-side sessions. 
+
+As a result, tokens should be issued for relatively short periods, and then [refreshed](/tokens/concepts/refresh-tokens) periodically if the user remains active.
+
+## Keep reading
+
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
+
diff --git a/ja-jp/articles/tokens/guides/use-access-tokens.md b/ja-jp/articles/tokens/guides/use-access-tokens.md
new file mode 100644
index 0000000000..decece8005
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/use-access-tokens.md
@@ -0,0 +1,65 @@
+---
+title: Use Access Tokens
+description: Learn how to use Access Tokens to call APIs.
+topics:
+  - tokens
+  - access-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+---
+
+# Use Access Tokens
+
+Access Tokens are used in token-based authentication to allow an application to access an API. For example, a Calendar application needs access to a Calendar API in the cloud so that it can read the user's scheduled events and create new events.
+
+Once an application has received an Access Token, it will include that token as a credential when making API requests. To do so, it should transmit the Access Token to the API as a **Bearer** credential in an HTTP **Authorization** header.
+
+For example:
+
+```text
+GET /calendar/v1/events
+Host​: api.example.com
+
+Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuYXV0aDAuY29tLyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1YiI6InVzcl8xMjMiLCJpYXQiOjE0NTg3ODU3OTYsImV4cCI6MTQ1ODg3MjE5Nn0.CA7eaHjIHz5NxeIJoFK9krqaeZrPLwmMmgI_XiQiIkQ
+```
+
+In this example, the Access Token is a [JSON Web Token (JWT)](/tokens/concepts/jwts) that decodes to the following [claims](/tokens/concepts/jwt-claims):
+
+```json
+{
+  "alg": "RS256",
+  "typ": "JWT"
+}
+.
+{
+  "iss": "https://example.auth0.com/",
+  "aud": "https://api.example.com/calendar/v1/",
+  "sub": "usr_123",
+  "scope": "read write",
+  "iat": 1458785796,
+  "exp": 1458872196
+}
+```
+
+Before permitting access to the API using this token, the API must [validate the Access Token](/tokens/guides/validate-access-tokens).
+
+Once the Access Token has been successfully validated, the API can be sure that:
+
+* The token was issued by Auth0.
+* The token was issued to an application being used by a user with an identifier of `usr_123`.
+* The user granted the application access to read from and write to their calendar.
+
+The API can now process the request, allowing the application to read from and write to user `usr_123`'s calendar.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Get Access Tokens](/tokens/guides/get-access-tokens)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [Quickstarts](/quickstarts)
+* [Authentication and Authorization Flows](/flows)
diff --git a/ja-jp/articles/tokens/guides/use-refresh-token-rotation.md b/ja-jp/articles/tokens/guides/use-refresh-token-rotation.md
new file mode 100644
index 0000000000..2a954f8834
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/use-refresh-token-rotation.md
@@ -0,0 +1,67 @@
+---
+title: Use Refresh Token Rotation
+description: Learn how to use Refresh Token rotation for you received during authorization.
+topics:
+  - refresh-tokens
+  - refresh-token-rotation
+contentType:
+  - how-to
+useCase:
+  - use-refresh-token-rotation
+---
+# Use Refresh Token Rotation
+
+To use Refresh Token rotation, you will use the [Auth0 Single Page App SDK](/libraries/auth0-spa-js). The Auth0 SPA SDK handles token storage, session management, and other details for you.
+
+## Prerequisite
+
+[Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+
+## Enable useRefreshTokens
+
+<%= include('../_includes/_rtr_enabled') %>
+
+Use the option `useRefreshTokens` on `createAuth0Client` which defaults to `false`. With this option set to `false`, when `getTokenSilently()` is invoked and a new Access Token is required, the SDK attempts to acquire a new Access Token using a hidden iframe and `prompt=none`.
+
+If you set to this option to `true`, the `offline_access` scope is automatically requested when using `loginWithRedirect(), loginWithPopup()` and `getTokenSilently()`. When `getTokenSilently()` is invoked and the Access Token has expired, the SDK attempts to renew the ID and Access Tokens by calling the `/token` endpoint using the `refresh_token` grant type along with the Refresh Token from the cache.
+
+Silent re-authentication is achieved by sending a `prompt=none` parameter upon the authentication request and using a hidden iframe, provided that there is an active user session on the authorization server. The SDK uses the iframe method if you have set `useRefreshTokens` to `true` but no Refresh Token is available in the cache. This helps users to silently migrate to using Refresh Tokens without making them log in again.
+
+::: note
+If the exchange fails because `useRefreshTokens` is `true` but there isn't a Refresh Token in the cache, then it falls back to the iframe method (which could also fail if third-party cookies are blocked).
+:::
+
+For more details and examples, see [Use rotating Refresh Tokens](/libraries/auth0-spa-js#use-rotating-refresh-tokens). 
+
+## Token storage
+
+With SPAs, ID and Access Tokens are obtained from the authorization server and typically cached in memory. Token renewal (due to refreshing the browser, memory cache eviction budgets, or expiration) is handled by the SDK. See [Token Storage](/tokens/concepts/token-storage) for details. 
+
+## Example
+
+The following example shows how to configure the SDK to use both local storage and refresh tokens:
+
+```js
+const auth0 = await createAuth0Client({
+    domain: '',
+    client_id: '',
+    cacheLocation: 'localstorage',
+    useRefreshTokens: true
+});
+
+// Logging-in will automatically request the offline_access scope
+// and store the resulting refresh token
+auth0.loginWithRedirect();
+
+// Silently refreshing the access token will use the /token endpoint
+// with ‘refresh_token’ grant and the refresh token from the cache
+await auth0.getTokenSilently();
+```
+
+## Keep reading
+
+* [Refresh Token Rotation](/tokens/concepts/refresh-token-rotation)
+* [Configure Refresh Token Rotation](/tokens/guides/configure-refresh-token-rotation)
+* [Disable Refresh Token Rotation](/tokens/guides/disable-refresh-token-rotation)
+* [Revoke Refresh Tokens](/tokens/guides/revoke-refresh-tokens)
+* [Token Storage](/tokens/concepts/token-storage)
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/guides/use-refresh-tokens.md b/ja-jp/articles/tokens/guides/use-refresh-tokens.md
new file mode 100644
index 0000000000..7a43aacab0
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/use-refresh-tokens.md
@@ -0,0 +1,75 @@
+---
+title: Use Refresh Tokens
+description: Learn how to use a Refresh Token you received during authorization.
+topics:
+  - refresh-tokens
+contentType:
+  - how-to
+useCase:
+  - use-refresh-tokens
+---
+# Use Refresh Tokens
+
+To exchange the Refresh Token you received during authorization for a new Access Token, make a `POST` request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/token",
+    "headers": [
+      { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+    ],
+    "postData" : {
+      "mimeType": "application/x-www-form-urlencoded",
+      "params": [
+        {
+          "name": "grant_type",
+          "value": "refresh_token"
+        },
+        {
+          "name": "client_id",
+          "value": "${account.clientId}"
+        },
+        {
+          "name": "client_secret",
+          "value": "YOUR_CLIENT_SECRET"
+        },
+        {
+          "name": "refresh_token",
+          "value": "YOUR_REFRESH_TOKEN"
+        }
+      ]
+    }
+}
+```
+
+| Attriburte | Description |
+| - | - |
+| `grant_type` | The type of grant to execute (the `/token` endpoint is used for various grants, for more information refer to the [Authentication API](/api/authentication#get-token)). To refresh a token, use `refresh_token` |
+| `client_id` | Your application's Client ID |
+| `client_secret` | Optional. Your application's Client Secret. Only required for [confidential applications](/applications/concepts/app-types-confidential-public#confidential-applications) |
+| `refresh_token` | The Refresh Token to use |
+
+The response will include a new Access Token, its type, its lifetime (in seconds), and the granted scopes. If the scope of the initial token included `openid`, then a new ID Token will be in the response as well.
+
+```json
+{
+  "access_token": "eyJ...MoQ",
+  "expires_in": 86400,
+  "scope": "openid offline_access",
+  "id_token": "eyJ...0NE",
+  "token_type": "Bearer"
+}
+```
+
+::: panel Rate limits
+You should only ask for a new token if the Access Token has expired or you want to refresh the claims contained in the ID Token. For example, it's a bad practice to call the endpoint to get a new Access Token every time you call an API. There are rate limits in Auth0 that will throttle the number of requests to this endpoint that can be executed using the same token from the same IP.
+:::
+
+## Keep reading
+
+* [Tokens](/tokens)
+* [Refresh Tokens](/tokens/concepts/refresh-tokens)
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get Refresh Tokens](/tokens/guides/get-refresh-tokens)
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/guides/validate-access-tokens.md b/ja-jp/articles/tokens/guides/validate-access-tokens.md
new file mode 100644
index 0000000000..baf23003a7
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/validate-access-tokens.md
@@ -0,0 +1,93 @@
+---
+title: Validate Access Token
+description: Learn how to validate an Access Token.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - access-tokens
+  - authorization
+contentType: 
+  - tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Validate Access Tokens
+
+::: note
+This document discusses validation of Access Tokens issued by Auth0. If you have received an Access Token from an [Identity Provider (IdP)](/identityproviders), in general, you don't need to validate it. You can pass it to the issuing IdP, and the IdP takes care of the rest.
+:::
+
+An Access Token is a credential that can be used by an application to access an API. Before you can validate an [Access Token](/tokens/concepts/access-tokens), you first need to know the format of the token. Auth0 issues Access Tokens in two formats: opaque and [JSON Web Token (JWT)](/tokens/concepts/jwts).
+
+::: warning
+Remember that an Access Token is meant for an API and should be validated only by the API for which it was intended. Client applications should not depend on the Access Token to be any specific format, and instead treat it as if it is opaque (regardless of whether it actually is).
+:::
+
+## Opaque Access Tokens
+
+Opaque Access Tokens can be used with the [`/userinfo` endpoint](/api/authentication#get-user-info) to return a user's profile. If you receive an opaque Access Token, you don't need to validate it. You can use it with the `/userinfo` endpoint, and Auth0 takes care of the rest. 
+
+To learn more about getting an opaque Access Token for the `userinfo` endpoint, see [Get Access Tokens](/tokens/guides/get-access-tokens#opaque-access-tokens).
+
+## JWT Access Tokens
+
+Access Tokens issued for the Auth0 Management API and Access Tokens issued for any custom API that you have registered with Auth0 will always be [JSON Web Tokens](/tokens/concepts/jwts).
+
+### Auth0 Management API Access Tokens
+
+An Access Token issued for the Auth0 Management API should be treated as opaque (regardless of whether it actually is), so you don't need to validate it. You can use it with the Auth0 Management API, and Auth0 takes care of the rest. 
+
+To learn more about getting an Access Token for the Auth0 Management API, see [Auth0 Management API Tokens](/api/management/v2/tokens).
+
+### Custom API Access Tokens
+
+::: warning
+If validation of your Custom API Access Token fails, make sure it was issued with your custom API as the `audience`. To learn more about getting an Access Token for your Custom API, see [Get an Access Token: Control Access Token Audience](/tokens/guides/get-access-tokens#control-access-token-audience).
+:::
+
+To validate a JWT issued for a custom API that you have registered with Auth0, you will need to:
+
+1. Perform standard JWT validation
+2. Check additional standard claims
+3. Check permissions (scopes)
+
+If any of these checks fail, the token is considered invalid, and the request must be rejected.
+
+#### Perform standard JWT validation
+
+Because the Access Token is a JWT, you will first need to perform the standard JWT validation steps. To learn about JWT validation, see [Validate JSON Web Tokens](/tokens/guides/validate-jwts).
+
+#### Check additional standard claims
+
+If you've performed the standard JWT validation, you have already decoded the [JWT's Payload](/tokens/references/jwt-structure#payload) and looked at its standard claims. Some additional claims to verify for Access Tokens include:
+
+* **Token audience** (`aud`, array of strings): Depending on the initial token request, the `aud` field could contain both an audience corresponding to your custom API and an audience corresponding to the `userinfo`endpoint. At least one of the audience values for the token must match the unique identifier of the target API as defined in your [API's Settings](${manage_url}/#/apis) in the **Identifier** field. To learn more about getting Access Tokens with multiple audiences, see [Get an Access Token](/tokens/guides/get-access-tokens).
+
+If this check fails, the token is considered invalid, and the request must be rejected.
+
+#### Check permissions
+
+The final step is to verify that the Application has been granted the permissions required to access your API. To do so, you will need to check an additional claim in the decoded JWT's Payload:
+
+* **Scopes** (`scope`, space-separated list of strings): Should match the permissions required for the endpoint being accessed.
+
+For example, say your custom API provides three endpoints to read, create, or delete a user record: `/create`, `/read`, and `/delete`. When you [registered your API with Auth0](/getting-started/set-up-api), you created three corresponding permissions:
+
+- `create:users` provides access to the `/create` endpoint
+- `read:users` provides access to the `/read` endpoint
+- `delete:users` provides access to the `/delete` endpoint
+
+In this case, if an Application requests to access the `/create` endpoint, but the Access Token's `scope` claim does not include the value `create:users`, then the API should reject the request with `403 Forbidden`.
+
+For an example using a simple timesheet API in Node.js, see [Architecture Scenarios: Server Client + API - Node.js API Implementation](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-client-permissions), an implementation of a Client Credentials grant for a hypothetical scenario. To see the complete solution, visit [Architecture Scenarios: Server Client + API](/architecture-scenarios/application/server-api).
+
+## Keep reading
+
+- [RFC 7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519)
+- [JSON Web Tokens](/tokens/concepts/jwts)
+- [APIs in Auth0](/apis)
+- [Tokens](/tokens)
+- [Architecture Scenarios: Server Client + API - Node.js API Implementation](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-application-permissions)
+- [How to implement API authentication and authorization scenarios](/api-auth)
diff --git a/ja-jp/articles/tokens/guides/validate-id-tokens.md b/ja-jp/articles/tokens/guides/validate-id-tokens.md
new file mode 100644
index 0000000000..0d743a1c98
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/validate-id-tokens.md
@@ -0,0 +1,34 @@
+---
+title: Validate ID Tokens
+description: Learn how to validate an ID Token.
+topics:
+  - tokens
+  - api-authentication
+  - oidc
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - development
+---
+# Validate ID Tokens 
+
+An [ID Token](/tokens/concepts/id-tokens), which contains user profile attributes, is consumed by an app and is typically used for user interface display. Auth0 issues all ID Tokens in [JSON Web Token (JWT)](/tokens/concepts/jwts) format.
+
+::: warning
+If any of these checks fail, the token is considered invalid, and the request must be rejected.
+:::
+
+1. [Validate the JSON Web Token](/tokens/guides/validate-jwts). 
+
+2. Check additional standard claims. If you've performed the standard JWT validation, you have already decoded the [JWT's Payload](/tokens/references/jwt-structure#payload) and looked at its standard claims. Additional claims to verify for ID Tokens include:
+
+    * **Token audience** (`aud`, string): The audience value for the token must match the client ID of the application as defined in your [Application's Settings](${manage_url}/#/applications) in the **Client ID** field.
+    * **Nonce** (`nonce`, string): Passing a nonce in the token request is recommended (required for the [Implicit Flow](/flows/concepts/implicit)) to help prevent replay attacks. The nonce value in the token must exactly match the original nonce sent in the request. To learn more how to use nonces in token requests, see [Mitigate Replay Attacks](/api-auth/tutorials/nonce).
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Invalid Token Errors](/troubleshoot/references/invalid-token)
diff --git a/ja-jp/articles/tokens/guides/validate-jwts.md b/ja-jp/articles/tokens/guides/validate-jwts.md
new file mode 100644
index 0000000000..2099af5dce
--- /dev/null
+++ b/ja-jp/articles/tokens/guides/validate-jwts.md
@@ -0,0 +1,122 @@
+---
+title: Validate JSON Web Tokens
+description: Learn how to parse and validate a JSON Web Token (JWT).
+topics:
+  - jwt
+  - tokens
+  - id-tokens
+contentType:
+  - how-to
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# Validate JSON Web Tokens
+
+::: note
+This document is intended for developers implementing a regular web, native, or SPA application. All of our [backend API quickstarts](/quickstart/backend) use SDKs that perform JWT validation and parsing for you.
+
+If you'd like to visually inspect a JWT, visit [JWT.io](https://jwt.io/) or use the [JWT Debugger Chrome Extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd?hl=en)).
+:::
+
+To parse and validate a JSON Web Token (JWT), you can:
+
+* Use any existing [middleware](#middleware) for your web framework.
+* Choose a [third-party library](#third-party-libraries) from [JWT.io](https://jwt.io/#libraries-io).
+* [Manually implement the checks](#manually-implement-the-checks) described in [specification RFC 7519 > 7.2 Validating a JWT](https://tools.ietf.org/html/rfc7519#section-7.2).
+
+::: warning
+We strongly recommend that you use middleware or one of the existing open source third-party libraries to parse and validate JWTs. At [JWT.io](https://jwt.io/#libraries-io), you can find libraries for various platforms and languages, such as .NET, Python, Java, Ruby, Objective-C, Swift, and PHP.
+:::
+
+## Middleware
+
+Many web frameworks, such as [ASP.NET Core](/quickstart/backend/aspnet-core-webapi), include JWT middleware that handles JWT validation. Typically, this is the best route to take because the middleware integrates well with the framework's overall authentication mechanisms.
+
+## Third-party libraries
+
+If you choose a third-party library, remember to pick a library that supports the [signing algorithm](/tokens/concepts/signing-algorithms) you selected when you registered your application or API with Auth0. Also, be aware that not all libraries validate all JWT claims. At [JWT.io](https://jwt.io/), you can see which validations each library supports (look for the green check marks).
+
+Most third-party libraries will implement one method to verify a JWT and build in various arguments to allow you to customize the verification.
+
+For example, if you are using Node.js and the [node-jsonwebtoken library](https://github.com/auth0/node-jsonwebtoken), then you would call the [jwt.verify()](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback) method. This method supports an `algorithms` argument to allow you to customize your allowed algorithms (make sure you disallow `none`), a `secretOrPublicKey` argument that you populate with either the secret or the RSA public key (depending on selected signing algorithm), and other input arguments that allow you to customize claim validation. If parsing fails, then the library returns a [JsonWebTokenError error](https://github.com/auth0/node-jsonwebtoken#jsonwebtokenerror) with the message `jwt malformed`, after which you **must** reject the associated request.
+
+## Manually implement the checks
+
+::: note
+All Auth0-issued JSON Web Tokens (JWTs) are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, this section describes validation for JWSs. If you need to validate a JSON Web Encryption (JWE), see [RFC 7519](https://tools.ietf.org/html/rfc7519#section-7.2) for instructions specific to that type of JWT.
+:::
+
+To validate a JWT, your application needs to:
+
+1. Check that the JWT is well formed.
+2. Check the signature.
+3. Check the standard claims.
+
+If any of these steps fail, then the associated request must be rejected.
+
+::: note
+Most JWT libraries take care of JWT validation for you, so be sure to visit [JWT.io](https://jwt.io/#libraries-io) to find a JWT library for your platform and programming language.
+:::
+
+## Check that the JWT is well-formed
+
+Ensure that the JWT conforms to the [structure of a JWT](/tokens/references/jwt-structure). If this fails, the token is considered invalid, and the request must be rejected.
+
+1. Verify that the JWT contains three segments, separated by two period ('.') characters.
+2. Parse the JWT to extract its three components. The first segment is the Header, the second is the Payload, and the third is the Signature. Each segment is base64url encoded.
+3. Base64url-decode the Header, ensuring that no line breaks, whitespace, or other additional characters have been used, and verify that the decoded Header is a valid JSON object.
+4. Base64url-decode the Payload, ensuring that no line breaks, whitespace, or other additional characters have been used, and verify that the decoded Payload is a valid JSON object.
+
+## Check the signature
+
+The last segment of a JWT is the Signature, which is used to verify that the token was signed by the sender and not altered in any way. The Signature is created using the Header and Payload segments, a [signing algorithm](/tokens/concepts/signing-algorithms), and a secret or public key (depending on the chosen signing algorithm).
+
+To verify the signature, you will need to:
+
+1. Check the signing algorithm.
+
+    1. Retrieve the `alg` property from the decoded Header.
+    2. Ensure that it is an allowed algorithm. Specifically, to avoid certain attacks, make sure you disallow `none`.
+    3. Check that it matches the algorithm you selected when you [registered your Application](/getting-started/set-up-app) or [API](/getting-started/set-up-api) with Auth0.
+2. Confirm that the token is correctly signed using the proper key.
+
+    To verify that the signature is correct, you need to generate a new Base64url-encoded signature using the public key (RS256) or secret (HS256) and verify that it matches the original Signature included with the JWT:
+
+    1. Take the original Base64url-encoded Header and original Base64url-encoded Payload segments (Base64url-encoded Header + "." + Base64url-encoded Payload), and hash them with SHA-256.
+    2. Encrypt using either HMAC or RSA (depending on your selected signing algorithm) and the appropriate key.
+    3. Base64url-encode the result.
+
+    ::: panel Locate Public Key
+
+    For RS256:
+    Retrieve the public key from the [JWKS](/tokens/concepts/jwks) located by using your [Auth0 discovery endpoint](/tokens/guides/locate-jwks).
+
+    For debugging purposes, you can visually inspect your token at [jwt.io](jwt.io); for this purpose, you can also locate your public key in the Auth0 Dashboard. Look in **Applications**>**Settings**>**Advanced Settings**>**Certificates** and locate the **Signing Certificate** field.
+
+    For HS256:
+    Retrieve the `client_secret` from Auth0's Management API using the [Get a Client endpoint](/api/management/v2/#!/Clients/get_clients_by_id). 
+
+    For debugging purposes, you can visually inspect your token at [jwt.io](jwt.io); for this purpose, you can also locate your secret in the Auth0 Dashboard. For applications, look in **Settings** and locate the **Client Secret** field. For APIs, look in **Settings** and locate the **Signing Secret** field. (Note that this field is only displayed for APIs using the HS256 [signing algorithm](/tokens/concepts/signing-algorithms).)
+    :::
+
+    If the generated signature does not match the original Signature included with the JWT, the token is considered invalid, and the request must be rejected.
+
+## Check standard claims
+
+Before using the token, you should retrieve the following standard claims from the decoded Payload and perform the following checks:
+
+* **Token expiration** (`exp`, Unix timestamp): The expiration date/time must be after the current date/time.
+* **Token issuer** (`iss`, string): The issuing authority inside the token must match the issuing authority (`issuer`) identified in your Auth0 tenant's discovery document, which exists at `https://${account.namespace}/.well-known/openid-configuration`.
+
+Additional checks are required depending on whether the JWT you are validating is an ID Token or an Access Token. To learn about the additional requirements, see [Validate ID Tokens](/tokens/guides/validate-id-tokens) or [Validate Access Tokens](/tokens/guides/validate-access-tokens).
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Token Claims](/tokens/concepts/jwt-claims)
+* [Token Best Practices](/best-practices/token-best-practices)
+* [JSON Web Key Set](/tokens/concepts/jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/ja-jp/articles/tokens/index.md b/ja-jp/articles/tokens/index.md
new file mode 100644
index 0000000000..b8eefdde25
--- /dev/null
+++ b/ja-jp/articles/tokens/index.md
@@ -0,0 +1,92 @@
+---
+title: Tokens
+description: Learn about the types of tokens related to identity and authentication and how they are used by Auth0.
+classes: topic-page
+topics:
+  - tokens
+  - access-tokens
+  - id-tokens
+  - idp-access-tokens
+  - managment-api-tokens
+contentType:
+  - index
+useCase:
+  - tokens
+---
+# Tokens
+
+There are basically two main types of tokens that are related to identity: ID Tokens and Access Tokens. 
+
+## ID Tokens
+
+[ID Tokens](/tokens/concepts/id-tokens) are [JSON Web Tokens (JWTs)](/tokens/concepts/jwts) meant for use by the application only. For example, if there's an app that uses Google to log in users and to sync their calendars, Google sends an ID Token to the app that includes information about the user. The app then parses the [token's contents](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and uses the information (including details like name and profile picture) to customize the user experience.
+
+<%= include('./_includes/_validate-id-token') %>
+
+ID Tokens should *not* be used to gain access to an API. Each token contains information for the intended audience (which is usually the recipient). Per the OpenID Connect specification, the audience of the ID Token (indicated by the **aud** claim) must be the **client ID** of the application making the authentication request. If this is not the case, you should not trust the token. Conversely, an API expects a token with the **aud** value to equal the API's unique identifier. Therefore, unless you maintain control over both the application and the API, sending an ID Token to an API will generally not work. Since the ID Token is not signed by the API, the API would have no way of knowing if the application had modified the token (e.g., adding more scopes) if it were to accept the ID Token. See the [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook) for more information.
+
+## Access Tokens
+
+[Access Tokens](/tokens/concepts/access-tokens) (which aren't always JWTs) are used to inform an API that the bearer of the token has been authorized to access the API and perform a predetermined set of actions (specified by the **scopes** granted). 
+
+In the Google example above, Google sends an Access Token to the app after the user logs in and provides consent for the app to read or write to their Google Calendar. Whenever the app wants to write to Google Calendar, it sends a request to the Google Calendar API, including the Access Token in the HTTP **Authorization** header.
+
+Access Tokens must *never* be used for authentication. Access Tokens cannot tell if the user has authenticated. The only user information the Access Token possesses is the user ID, located in the **sub** claim.
+
+Your applications should treat Access Tokens as *opaque strings* since they are meant for APIs. Your application should *not* attempt to decode them or expect to receive tokens in a particular format.
+
+## Token examples
+
+To better clarify the concepts we covered above, let's look at the contents of some sample ID and Access Tokens.
+
+The decoded contents of a sample ID Token looks like the following:
+
+```json
+{
+  "iss": "http://${account.namespace}/",
+  "sub": "auth0|123456",
+  "aud": "${account.clientId}",
+  "exp": 1311281970,
+  "iat": 1311280970,
+  "name": "Jane Doe",
+  "given_name": "Jane",
+  "family_name": "Doe",
+  "gender": "female",
+  "birthdate": "0000-10-31",
+  "email": "janedoe@example.com",
+  "picture": "http://example.com/janedoe/me.jpg"
+}
+```
+
+This token **authenticates the user to the application**. The audience (the **aud** claim) of the token is set to the application's identifier, which means that only this specific application should consume this token.
+
+For comparison, let's look at the contents of an Access Token:
+
+```json
+{
+  "iss": "https://${account.namespace}/",
+  "sub": "auth0|123456",
+  "aud": [
+    "my-api-identifier",
+    "https://${account.namespace}/userinfo"
+  ],
+  "azp": "${account.clientId}",
+  "exp": 1489179954,
+  "iat": 1489143954,
+  "scope": "openid profile email address phone read:appointments"
+}
+```
+
+Note that the token does not contain any information about the user itself besides their ID (**sub** claim). It only contains authorization information about which actions the application is allowed to perform at the API (**scope** claim). This is what makes it useful for securing an API, but not for authenticating a user.
+
+In many cases, you might find it useful to retrieve additional user information at the API, so the Access Token is also valid for calling [the /userinfo API](/api/authentication#user-profile), which returns the user's profile information. The intended audience (indicated by the **aud** claim) for this token is both your custom API as specified by its identifier (such as `https://my-api-identifier`) and the **/userinfo** endpoint (such as `https://${account.namespace}/userinfo`).
+
+## Other specialized tokens used by Auth0
+
+There are three specialized tokens used in Auth0's token-based authentication scenarios:
+
+<%= include('../_includes/_topic-links', { links: [
+  'tokens/concepts/idp-access-tokens',
+  'tokens/concepts/refresh-tokens',
+  'api/management/v2/tokens'
+] }) %>
diff --git a/ja-jp/articles/tokens/references/id-token-structure.md b/ja-jp/articles/tokens/references/id-token-structure.md
new file mode 100644
index 0000000000..c8808ea8ad
--- /dev/null
+++ b/ja-jp/articles/tokens/references/id-token-structure.md
@@ -0,0 +1,39 @@
+---
+title: ID Token Structure
+description: Describes how ID Tokens conform to the JWT standard and contain JWT claims asserted about the token itself, standard OIDC claims about the authenticated user, and custom claims that you define, control, and add to a token using a rule.
+topics:
+  - tokens
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+# ID Token Structure
+
+ID Tokens follow the [JSON Web Token (JWT)](/tokens/concepts/jwts) standard, which means that their basic structure conforms to the typical [JWT Structure](/tokens/references/jwt-structure), and they contain standard [JWT Claims](/tokens/concepts/jwt-claims) asserted about the token itself.
+
+However, beyond what is required for JWT, ID Tokens also contain claims asserted about the authenticated user, which are pre-defined by the [OpenID Connect (OIDC)](/protocols/oidc) protocol, and are thus known as standard OIDC claims. Some standard OIDC claims include:
+
+* `name`
+* `nickname`
+* `picture`
+* `email`
+* `email_verified`
+
+For a full list of standard OIDC claims, see [OIDC specification: Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
+
+You control which OIDC claims are included in the ID Token consumed by your application by including specific [OpenID Connect Scopes](/scopes/oidc-scopes) in a parameter when you request tokens while authenticating users. To learn how to request an ID Token, see [Get ID Tokens](/tokens/guides/get-id-tokens).
+
+::: note 
+You can also create [custom claims](/tokens/concepts/jwt-claims#custom-claims), which are claims that you define, control, and add to a token using a [rule](/rules). 
+:::
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Get ID Tokens](/tokens/guides/get-id-tokens)
+* [Token Storage](/tokens/concepts/token-storage)
+* [Validate ID Tokens](/tokens/guides/validate-id-tokens)
+* [Revoke Tokens](/tokens/guides/revoke-tokens)
diff --git a/ja-jp/articles/tokens/references/jwks-properties.md b/ja-jp/articles/tokens/references/jwks-properties.md
new file mode 100644
index 0000000000..ea229c7aff
--- /dev/null
+++ b/ja-jp/articles/tokens/references/jwks-properties.md
@@ -0,0 +1,62 @@
+---
+title: JSON Web Key Set Properties
+description: Describes the properties available in a JSON Web Key Set (JWKS).
+toc: false
+topics:
+  - tokens
+  - jwks
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+---
+# JSON Web Key Set Properties
+
+Here is an example of the JSON Web Key Set (JWKS) used by a sample tenant, containing a single JSON Web Key (JWK):
+
+```json
+{
+"keys": [
+  {
+    "alg": "RS256",
+    "kty": "RSA",
+    "use": "sig",
+    "x5c": [
+      "MIIC+DCCAeCgAwIBAgIJBIGjYW6hFpn2MA0GCSqGSIb3DQEBBQUAMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTAeFw0xNjExMjIyMjIyMDVaFw0zMDA4MDEyMjIyMDVaMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnjZc5bm/eGIHq09N9HKHahM7Y31P0ul+A2wwP4lSpIwFrWHzxw88/7Dwk9QMc+orGXX95R6av4GF+Es/nG3uK45ooMVMa/hYCh0Mtx3gnSuoTavQEkLzCvSwTqVwzZ+5noukWVqJuMKNwjL77GNcPLY7Xy2/skMCT5bR8UoWaufooQvYq6SyPcRAU4BtdquZRiBT4U5f+4pwNTxSvey7ki50yc1tG49Per/0zA4O6Tlpv8x7Red6m1bCNHt7+Z5nSl3RX/QYyAEUX1a28VcYmR41Osy+o2OUCXYdUAphDaHo4/8rbKTJhlu8jEcc1KoMXAKjgaVZtG/v5ltx6AXY0CAwEAAaMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUQxFG602h1cG+pnyvJoy9pGJJoCswDQYJKoZIhvcNAQEFBQADggEBAGvtCbzGNBUJPLICth3mLsX0Z4z8T8iu4tyoiuAshP/Ry/ZBnFnXmhD8vwgMZ2lTgUWwlrvlgN+fAtYKnwFO2G3BOCFw96Nm8So9sjTda9CCZ3dhoH57F/hVMBB0K6xhklAc0b5ZxUpCIN92v/w+xZoz1XQBHe8ZbRHaP1HpRM4M7DJk2G5cgUCyu3UBvYS41sHvzrxQ3z7vIePRA4WF4bEkfX12gvny0RsPkrbVMXX1Rj9t6V7QXrbPYBAO+43JvDGYawxYVvLhz+BJ45x50GFQmHszfY3BR9TPK8xmMmQwtIvLu1PMttNCs7niCYkSiUv2sc2mlq1i3IashGkkgmo="
+    ],
+    "n": "yeNlzlub94YgerT030codqEztjfU_S6X4DbDA_iVKkjAWtYfPHDzz_sPCT1Axz6isZdf3lHpq_gYX4Sz-cbe4rjmigxUxr-FgKHQy3HeCdK6hNq9ASQvMK9LBOpXDNn7mei6RZWom4wo3CMvvsY1w8tjtfLb-yQwJPltHxShZq5-ihC9irpLI9xEBTgG12q5lGIFPhTl_7inA1PFK97LuSLnTJzW0bj096v_TMDg7pOWm_zHtF53qbVsI0e3v5nmdKXdFf9BjIARRfVrbxVxiZHjU6zL6jY5QJdh1QCmENoejj_ytspMmGW7yMRxzUqgxcAqOBpVm0b-_mW3HoBdjQ",
+    "e": "AQAB",
+    "kid": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg",
+    "x5t": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg"
+  }
+]}
+```
+
+Each property in the key is defined by the JWK specification [RFC 7517 Section 4](https://tools.ietf.org/html/rfc7517#section-4) or, for algorithm-specific properties, in [RFC 7518](https://tools.ietf.org/html/rfc7518)].
+
+| Property name | Description                |
+|---------------|----------------------------|
+| `alg`         | The specific cryptographic algorithm used with the key. |
+| `kty`         | The family of cryptographic algorithms used with the key. |
+| `use`         | How the key was meant to be used; `sig` represents the signature. |
+| `x5c`         | The x.509 certificate chain. The first entry in the array is the certificate to use for token verification; the other certificates can be used to verify this first certificate.|
+| `n`           | The modulus for the [RSA public key](https://tools.ietf.org/html/rfc7518#page-30). |
+| `e`           | The exponent for the [RSA public key](https://tools.ietf.org/html/rfc7518#page-30). |
+| `kid`         | The unique identifier for the key. |
+| `x5t`         | The thumbprint of the x.509 cert (SHA-1 thumbprint). |
+
+::: note
+Auth0 only supports HMAC and RSA; it does not currently support Elliptic Curve encryption (ECDSA).
+:::
+
+For an example that uses JWKS to verify a JWT's signature, check out our [Backend/API Quickstarts](/quickstart/backend).
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [JSON Web Token Structure](/tokens/references/jwt-structure)
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Token Key Sets](/tokens/guides/locate-jwks)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/tokens/references/jwt-structure.md b/ja-jp/articles/tokens/references/jwt-structure.md
new file mode 100644
index 0000000000..a1d3af35dd
--- /dev/null
+++ b/ja-jp/articles/tokens/references/jwt-structure.md
@@ -0,0 +1,100 @@
+---
+title: JSON Web Token Structure
+description: Understand how JSON Web Tokens (JWTs) are structured.
+toc: true
+topics:
+  - tokens
+  - jwt
+contentType:
+  - reference
+useCase:
+  - invoke-api
+  - secure-api
+  - add-login
+---
+
+# JSON Web Token Structure
+
+::: note
+All Auth0-issued JSON Web Tokens (JWTs) are JSON Web Signatures (JWS), meaning they are signed rather than encrypted. As such, this document describes the JWS structure of a JWT.
+:::
+
+A well-formed JSON Web Token (JWT) consists of three concatenated Base64url-encoded strings, separated by dots (`.`): 
+
+- **Header**: contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+- **Payload** (set of [claims](/tokens/concepts/jwt-claims)): contains verifiable security statements, such as the identity of the user and the permissions they are allowed.
+- **Signature**: used to validate that the token is trustworthy and has not been tampered with. You must [verify this signature](/tokens/guides/validate-id-tokens#verify-the-signature) before storing and using a JWT.
+
+A JWT typically looks like this:
+![Encoded JWT](/media/articles/jwt/encoded-jwt3.png)
+
+To see for yourself what is inside a JWT, use the [JWT.io Debugger](http://jwt.io). It will allow you to quickly check that a JWT is well formed and manually inspect the values of the various claims.
+
+![JWT.IO Debugger](/media/articles/jwt/legacy-app-auth-5.png)
+
+::: panel Where can I find my secret or public key?
+
+For RS256:
+1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view.
+2. Scroll to the bottom of the page, click **Advanced Settings**, and click the **Certificates** tab. You will find the Public Key in the **Signing Certificate** field.
+
+For HS256:
+1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. You will find your Secret in the **Client Secret** field.
+:::
+
+## Header
+
+The header *typically* consists of two parts: the hashing algorithm being used (e.g., HMAC SHA256 or RSA) and the type of the token (JWT).
+
+```
+{
+  "alg": "HS256",
+  "typ": "JWT"
+}
+```
+
+
+## Payload
+
+The payload contains statements about the entity (typically, the user) and additional entity attributes, which are called [claims](/tokens/concepts/jwt-claims). In this example, our entity is a user.
+
+```
+{
+  "sub": "1234567890",
+  "name": "John Doe",
+  "admin": true
+}
+```
+
+::: note
+When working with [JWT claims](https://tools.ietf.org/html/rfc7519#section-4), you should be aware of the different [claim types and naming rules](/tokens/concepts/jwt-claims). 
+:::
+
+
+## Signature
+
+The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
+
+To create the signature, the Base64-encoded header and payload are taken, along with a secret, and signed with the algorithm specified in the header.
+
+For example, if you are creating a signature for a token using the HMAC SHA256 algorithm, you would do the following:
+
+```
+HMACSHA256(
+  base64UrlEncode(header) + "." +
+  base64UrlEncode(payload),
+  secret)
+```
+
+::: warning
+How ever you use a JWT, you must [check its signature](/tokens/guides/validate-jwts) before storing and using it.
+:::
+
+## Keep reading
+
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [Validate JSON Web Tokens](/tokens/guides/validate-jwts)
+* [Locate JSON Web Token Key Sets](/tokens/guides/locate-jwks)
+* [JSON Web Key Sets](/tokens/concepts/jwks)
+* [JSON Web Key Set Properties](/tokens/references/jwks-properties)
+* [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook)
diff --git a/ja-jp/articles/topics/guides/index.md b/ja-jp/articles/topics/guides/index.md
new file mode 100644
index 0000000000..ee6731da0f
--- /dev/null
+++ b/ja-jp/articles/topics/guides/index.md
@@ -0,0 +1,34 @@
+---
+classes: topic-page
+title: Guides
+description: Helpful docs for implementing Auth0
+topics:
+  - architecture
+  - tokens
+  - user-management
+  - users
+  - mfa
+  - email
+  - guides
+contentType: index
+useCase: development
+---
+
+
    
+  
    
+  
    Guides
    
+  
    
+    In addition to the docs featured on the documentation homepage, there are other materials many find useful. The following is a list of commonly-used docs, guides, and tutorials you may find helpful as you implement Auth0.
+  
    
+
    
+
+<%= include('../../_includes/_topic-links', { links: [
+  'architecture-scenarios',
+  'tokens',
+  'users',
+  'mfa',
+  'integrations',
+  'flows',
+  'product-lifecycle',
+  'best-practices'
+] }) %>
diff --git a/ja-jp/articles/troubleshoot/_includes/_log_events_link.md b/ja-jp/articles/troubleshoot/_includes/_log_events_link.md
new file mode 100644
index 0000000000..36c5fa4a28
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/_includes/_log_events_link.md
@@ -0,0 +1,3 @@
+::: panel Log Events
+See [Log Events](/monitoring#log-events) for more details on each of the log events that can help you troubleshoot issues. 
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/concepts/auth-issues.md b/ja-jp/articles/troubleshoot/concepts/auth-issues.md
new file mode 100644
index 0000000000..a9e9c62cf8
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/concepts/auth-issues.md
@@ -0,0 +1,24 @@
+---
+title: Troubleshoot Authentication Issues
+description: Learn where to look for steps to troubleshoot authentication and authorization issues such as API calls, login, logout, user profiles, MFA and SAML. 
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot Authentication Issues
+
+<%= include('../../_includes/_topic-links', { links: [
+  'troubleshoot/guides/check-api-calls',
+  'troubleshoot/guides/check-login-logout-issues',
+  'troubleshoot/guides/check-user-profiles',
+  'authorization/concepts/troubleshooting',
+  'mfa/references/troubleshoot-mfa',
+  'protocols/saml/saml-configuration/troubleshoot',
+  'extensions/authorization-extension/v2/troubleshooting'
+] }) %>
diff --git a/ja-jp/articles/troubleshoot/concepts/basics.md b/ja-jp/articles/troubleshoot/concepts/basics.md
new file mode 100644
index 0000000000..8d268cbffe
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/concepts/basics.md
@@ -0,0 +1,23 @@
+---
+title: Basic Troubleshooting
+description: Learn where to look for basic troubleshooting steps to eliminate common problems such as Auth0 status, platform, connections, rules, domains, and how to generate HAR files and validate JWTs. 
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Basic Troubleshooting
+
+<%= include('../../_includes/_topic-links', { links: [
+  'troubleshoot/guides/verify-platform',
+  'troubleshoot/guides/verify-connections',
+  'troubleshoot/guides/verify-domain',
+  'troubleshoot/guides/verify-rules',
+  'troubleshoot/guides/check-error-messages',
+  'monitoring/guides/monitor-applications'
+  ] }) %>
diff --git a/ja-jp/articles/troubleshoot/concepts/integration-extensibility-issues.md b/ja-jp/articles/troubleshoot/concepts/integration-extensibility-issues.md
new file mode 100644
index 0000000000..64a8588f0d
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/concepts/integration-extensibility-issues.md
@@ -0,0 +1,25 @@
+---
+title: Troubleshoot Integration and Extensibility
+description: Learn where to look for steps to troubleshoot integration and extensibility issues such as partner connections, Sign in With Apple, custom databases and domains, Deploy CLI, and extensions.   
+classes: topic-page
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot Integration and Extensibility
+
+<%= include('../../_includes/_topic-links', { links: [
+  'connections/how-to-test-partner-connection',
+  'connections/apple-siwa/troubleshooting',
+  'connections/database/custom-db/error-handling',
+  'custom-domains/troubleshoot',
+  'connector/troubleshooting',
+  'extensions/troubleshoot',
+  'extensions/deploy-cli/references/troubleshooting', 
+  'libraries/auth0-php/troubleshooting'
+] }) %>
diff --git a/ja-jp/articles/troubleshoot/guides/check-api-calls.md b/ja-jp/articles/troubleshoot/guides/check-api-calls.md
new file mode 100644
index 0000000000..d1c28f4542
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/check-api-calls.md
@@ -0,0 +1,45 @@
+---
+title: Check API Calls
+description: Learn how to check API calls to troubleshoot issues. 
+topics:
+  - management-api-calls
+  - api-calls
+  - access-tokens
+contentType: how-to
+useCase: troubleshooting
+---
+# Check API Calls
+
+## Check Management API calls
+
+* Do you have a [Management API Access Token](/api/management/v2/tokens)?
+* Did the Access Token expire?
+* Did the Access Token contain the scopes needed for the call you made?
+* If a rule adjusts the scopes in the Access Token or checks whether specific users are allowed to have the scopes, have you checked the rule to make sure it is executing correctly?  
+* Get the Access Token from a [HAR file](/troubleshoot/guides/generate-har-files) and test it in the [Auth0 Management API Explorer](/api/management/v2/) to see if it works there.
+* If you are calling the Auth0 Management API from an application that authenticates with [Client Credentials flow](/flows/guides/client-credentials/call-api-client-credentials), note that rules are not executed in this context. The Client Credentials Exchange Hook can be used in this context instead, for functionality similar to a rule.
+
+## Check other API calls
+
+* Check in the [HAR file](/troubleshoot/guides/generate-har-files) if the Access Token contains correct scopes to call the API.
+* Check if the response to the `/authorize` endpoint call contains a scopes object. If so, check if the returned scopes are different from the requested scopes.
+* Make sure your API can [validate the Access Token](/tokens/guides/validate-access-tokens).  It should validate the audience, issuer, client (if any), signature algorithm, signature, claims and permissions.
+* If you experience errors with Access Token expiration, they could be caused by [clock skew differences manifested across different systems](/connector/troubleshooting#clock-skew) or even different language libraries, such as Java and Node.js.  This can be handled by running NTP on servers and configuring a clock skew tolerance in libraries used to validate tokens such as [jwt.verify](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback).
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Learn Identity Video: Calling an API](/videos/learn-identity/04-calling-an-api)
+* [Best Practices: Minimize API requests](/best-practices/performance#minimize-api-requests)
+* [Best Practices: Consider use of explicit timeouts when making API calls](/best-practices/performance#consider-use-of-explicit-timeouts-when-making-api-calls)
+* [Call APIs Using the Implicit Flow](/flows/guides/implicit/call-api-implicit)
+* [Call APIs Using the Client Credentials Flow](/flows/guides/client-credentials/call-api-client-credentials)
+* [Call APIs Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code)
+* [Call APIs Using Authorization Code Flow with PKCE](/flows/guides/auth-code-pkce/call-api-auth-code-pkce)
+* [Call APIs Using Device Authorization Flow](/flows/guides/device-auth/call-api-device-auth)
+* [Call Identity Provider APIs](/connections/calling-an-external-idp-api)
+* [Call APIs with Auth0 Tokens](/api-auth/tutorials/adoption/api-tokens)
+* [Call APIs from Highly Trusted Applications](/api-auth/grant/password)
+* [Call APIs from Machine-to-Machine Applications](/microsites/call-api/call-api-m2m-app)
+* [Call AWS APIs and Resources Securely with Tokens](/integrations/aws/tokens)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/guides/check-deprecation-errors.md b/ja-jp/articles/troubleshoot/guides/check-deprecation-errors.md
new file mode 100644
index 0000000000..e8e70e3298
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/check-deprecation-errors.md
@@ -0,0 +1,76 @@
+---
+title: Check Deprecation Errors
+description: Learn how to search logs for deprecation errors. 
+topics:
+    - errors
+    - deprecation
+contentType: how-to
+useCase: error-management
+---
+# Check Deprecation Errors
+
+There are two different ways to search for warning messages showing usage of deprecated features: The Dashboard or the Management API. Note that in either case, the [log retention period](/logs#how-long-is-log-file-data-available-) is governed by the subscription level of your account.
+
+## Search logs using the Dashboard
+
+If your application uses a deprecated feature, a Deprecation Notice message will show up in the Logs section of the [Dashboard](${manage_url}/#/).
+
+::: note
+So the logs aren't full of repetitive messages, they only show deprecation notes once per hour the first time it occurs within that hour.
+:::
+
+1. Navigate to the **Logs** screen in the Dashboard. 
+
+2. Enter `type:depnote` in the query box. 
+
+    A list of deprecation related warning messages from your logs will be shown, if any exist. The **Description** field provides information on the particular deprecated feature used. 
+
+2. Click the link in the **Event** column for each item to show additional information such as the client id which identifies the client application using the deprecated feature.
+
+3. Click each item and select **Context Data** for details about the item.
+
+## Search logs using the Management API
+
+Use the Management API to search through logs for deprecation messages by looking for  "Type" = "depnote".
+
+1. Go to the [Management API](/api/management/v2) console.
+
+2. If you have not already done so, [get and get an API token](/api/management/v2/tokens).
+
+3. On the left, navigate to **Logs > Search log events** and then scroll down to **Parameters**.
+
+4. In the **q** field enter `type:"depnote"`.
+
+5. Click on the **TRY** button. If successful, you should see a screen similar to the one below.
+
+![Management API - Logs - Results](/media/articles/errors/libraries/management-api-logs-results.png)
+
+    * The results will match one of the messages + descriptions below.
+    * The **Client ID** field in the results will indicate which application (client) on your tenant is using the deprecated feature.
+
+## Deprecation log messages 
+
+### Legacy Lock API
+
+**Log entry**: `up-idp-initiated`
+
+**Error Message:** "Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application."
+
+| Cause | Resolution |
+| --- | --- |
+| You are using a legacy version of embedded Lock or Auth0.js SDK. | Migrate away from the deprecated library versions as soon as possible. |
+| Calling the /usernamepassword/login endpoint directly. | Use the Lock or Auth0.js libraries instead. |
+| Automatic monitoring tools making requests to login page | If you have an automatic monitoring tool making requests to the login page, the tool will likely not preserve state correctly and will cause the Legacy Lock API error to occur in your logs. Use of the tool should either be discontinued, or accounted for when considering causes of the log notices. |
+| Coding errors in a customized [Universal Login Page](/universal-login) | Make sure the `state` and `_csrf` fields are passed to Lock or Auth0.js in your customized login page. They are by default included in the `config.internalOptions` object, but if this is removed during customization, the error occurs. |
+
+Tenant log entries regarding the Legacy Lock API may include the referrer and information about the SDK used. This information can be used to see if any of your applications use outdated libraries.
+
+### SSOdata endpoint
+
+**Log entry**: `ssodata`
+
+**Error Message:** "SSOdata endpoint: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application."
+
+**Cause**: Either calling the `/ssodata` endpoint directly or using old versions of embedded Lock or Auth0.js SDK to call a function which called the `/ssodata` endpoint. 
+
+**Resolution**: [Migrate to Universal Login](/guides/login/migration-embedded-universal) or [migrate to Lock v11 or Auth0.js v9](/migrations#introducing-lock-v11-and-auth0-js-v9).
diff --git a/ja-jp/articles/troubleshoot/guides/check-error-messages.md b/ja-jp/articles/troubleshoot/guides/check-error-messages.md
new file mode 100644
index 0000000000..7fde71b5d5
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/check-error-messages.md
@@ -0,0 +1,113 @@
+---
+title: Check Error Messages
+description: Learn how to check for error message to troublshoot issues. 
+topics:
+  - error-messages
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check Error Messages
+
+Check for error messages displayed in any of the following locations:
+
+* Browsers and HTML page responses
+* Developer tools network and console tabs
+* Authorization Server responses
+* Deprecation errors
+
+## Check browser errors
+
+A HAR file is a JSON formatted log of a web browser's interactions with a web server. If authentication isn't working as expected, you can [generate and analyze HAR files](/troubleshoot/guides/generate-har-files) to find issues.
+
+## Check login screen
+
+The Lock login widget shows error messages for certain types of issues, such as an incorrect username or password. Check the **More Information** link if you're using Auth0's standard error page.
+
+## Check logs
+
+Auth0 stores [log data](/logs) including Dashboard administrator actions, successful and failed user authentications, and password change requests. You can view the logs in the [Dashboard](${manage_url}/#/logs).
+
+::: note
+Some types of errors do not appear in the logs. For example, if an error occurs at a remote Identity Provider, where authentication doesn’t complete and the user is never returned to Auth0, there won’t be any entry in logs. 
+:::
+
+You can export [Auth0 logs](/logs) and either store them yourself or automatically push them to external log services. This functionality can help you with data retention requirements, as well as log analysis requirements. You can install and configure an Auth0 Extension to export logs automatically to another provider like Sumo Logic or Loggly. For a list of available providers and detailed steps to configure each, see [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service).
+
+<%= include('../_includes/_log_events_link') %>
+
+You can also use the Management API to export logs and store them. There are the two available endpoints, each providing slightly different information.
+
+### Search all logs `/get_logs` endpoint
+
+The [Search log events endpoint](/api/management/v2#!/Logs/get_logs) retrieves log entries that match the search criteria you provided. If you do not provide any search criteria, you will get a list of all available entries. 
+
+You can provide search criteria using the **q** parameter and retrieve specific fields using the **fields** parameter. 
+
+To access the API, you need a [Management APIv2 token](/api/management/v2/tokens).
+
+This sample request retrieves all logs for successful logins (the event acronym for successful login is `s`). The list of fields we will retrieve per log entry is: **date**, **description**, **client_id**, and **log_id**.
+
+```har
+{
+"method": "GET",
+"url": "https://${account.namespace}/api/v2/logs",
+"httpVersion": "HTTP/1.1",
+"headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+}],
+"queryString":  [
+    {
+      "name": "fields",
+      "value": "date,description,client_id,log_id"
+    },
+    {
+      "name": "type",
+      "value": "s"
+    }
+]
+}
+```
+
+For details on the search criteria you can use and a list with the event acronyms, see the [Search log events endpoint](/api/management/v2#!/Logs/get_logs).
+
+### Get a single log entry `/get_logs_by_id` endpoint
+
+The [Get a log event by ID endpoint](/api/management/v2#!/Logs/get_logs_by_id) retrieves the log entry associated with the provided ID.
+
+This sample request retrieves a single log entry with the ID `90020180129170850881585554625888895190928456277777449010`.
+
+```har
+{
+"method": "GET",
+"url": "https://${account.namespace}/api/v2/logs/90020180129170850881585554625888895190928456277777449010",
+"httpVersion": "HTTP/1.1",
+"headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+}]
+}
+```
+
+## Check logs for deprecation errors
+
+When Auth0 features are deprecated, there may be errors or notices in the tenant logs that show up to indicate that your applications are using the deprecated features. You can [search the logs for specific deprecation entries](/troubleshoot/guides/check-deprecation-errors) that may indicate that a feature has been deprecated. 
+
+## Rate limits and other errors
+
+Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You should set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you will find it helpful to scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)).
+
+::: panel Best Practice
+Calling the Management API to retrieve user profile information from within a Rule is a common cause of rate limit errors because such API calls can execute for every login as well as periodic session checks.
+:::
+
+## Check real-time webtask logs error console
+
+You can put `console.log()` statements into Rules, Hooks, Custom DB scripts, and Webtasks. The output from those statements is viewable in the Realtime Web Log. If you install the Real-time Webtask Logs extension, you can initiate a view of this log console from the **Debug** buttons underneath the Rules, Hooks, and custom DB script editor windows, or from the webtask console for webtasks.
+
+## Keep reading
+
+* [Standard Error Responses](/api/authentication#standard-error-responses)
+* [Auth0.js Error Codes and Descriptions](/libraries/auth0js/v9#error-codes-and-descriptions)
+* [Errors with Code `invalid_token`](/troubleshoot/references/invalid-token)
diff --git a/ja-jp/articles/troubleshoot/guides/check-login-logout-issues.md b/ja-jp/articles/troubleshoot/guides/check-login-logout-issues.md
new file mode 100644
index 0000000000..067b5c888b
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/check-login-logout-issues.md
@@ -0,0 +1,85 @@
+---
+title: Check Login and Logout Issues
+description: Learn how to check login and logout to troubleshoot issues. 
+topics:
+  - login-issues
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check Login and Logout Issues
+
+Here are things to check to help you narrow down when issues occur during login and logout.
+
+## Login Issues
+
+### Is the user prompted for login credentials?
+
+* Does the HAR file show a call to the authorization server (`/authorize` endpoint)?
+* Is the connection enabled for the application?
+* Is the remote authorization service available? 
+* If using the [Auth0 Universal Login Page](/universal-login), try turning off customization and see if authentication works. If login works without your customizations, review your Universal Login Page customization code.
+
+### Is an error message shown after entering credentials?
+
+* Can you test login another way to ensure credentials are correct?
+* If password expiration is a possibility, check if password has expired.
+* Check your browser's developer tools or web inspector console for errors in the flow before returning to Auth0.
+* Check the HAR file - does it show a return to Auth0 (`/login/callback`endpoint)?
+    - If not, check that the identity provider has the correct callback URL for Auth0.
+
+### Is a login session established for the user at the authorization server?
+
+* To test this, open a second tab in the same browser and go to the same URL. Are you prompted to log in again?
+    - If you're not prompted to log in, a session is there.
+
+### Is a log entry created in your Auth0 Logs?
+
+* If no log entry was created the authentication transaction did not complete or return to Auth0.
+* Check the response from the authorization server for error messages.
+* Check authorization server logs (if possible) for errors.
+
+### Is an entry created in Auth0 user’s screen with all correct profile info?
+
+* If not, check the response from authorization server in the HAR file. It may not be returning information about the user
+* If you're using rules, check your rules scripts for issues.
+* If you're using a custom database connection, check your database action scripts for issues.
+* If you're using LDAP, check the profile mapper script (`profileMapper.js`) for issues.
+* Check your social connection configurations for what profile information is requested.
+
+### Does the HAR file show a token or assertion returned to application?
+
+* Look in the [HAR file](/troubleshoot/guides/generate-har-files) for the call to your application callback URL.
+* Find the ID Token (`id_token`) and check if it has the information needed by the application.
+
+### If you decode the token or assertion does it have information you expect?
+
+* View JWTs with [JWT.io](http://jwt.io).
+* View SAML assertions with [SAMLTool.io](http://samltool.io).
+
+### If the logged in user cannot access another application with Single Sign-on
+
+1. Is the user trying to login to the second application from the same browser as their initial login?
+2. Go to your [Tenant Settings > Advanced Settings](${manage_url}/#/tenant/advanced) and check the **Log In Session Management** settings. Was the second login attempt within the timeout periods?
+3. Check the value passed as the `prompt` parameter in `/authorize` call.
+4. Is the connection used to log in to the first application enabled for the second application?
+5. Did the second application receive all the necessary user profile information?
+6. If using a mobile device, you'll need to use a browser-based flow. For more information, see [Browser-Based vs. Native Login Flows on Mobile Devices](/design/browser-based-vs-native-experience-on-mobile).
+
+### Check application logs
+
+* Do your application logs show any errors?
+* Did the application receive all the information it needs, such as groups or user profile attributes?
+
+## Logout issues
+
+* Did you whitelist your logout redirect URLs? If you are using a redirect URL in a logout call it must be registered in either the tenant or application settings.
+* If you need federated logout, did you append the `?federated` parameter to the logout call?
+* Make sure that the logout redirect URL is different from the login callback URL.
+* Make the logout redirect URL an anonymous page (not protected by login) so that redirects to the logout redirect URL do not immediately trigger a login, which may confuse users.
+
+## Keep reading
+
+* [Common Auth0 Library Authentication Errors](/libraries/error-messages)
+* [Troubleshoot Passwordless Authentication](/connections/passwordless/troubleshoot)
+* [Troubleshoot WordPress Plugin](/cms/wordpress/troubleshoot)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/guides/check-user-profiles.md b/ja-jp/articles/troubleshoot/guides/check-user-profiles.md
new file mode 100644
index 0000000000..7b551af860
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/check-user-profiles.md
@@ -0,0 +1,26 @@
+---
+title: Check User Profiles
+description: Learn how to check user profiles to troubleshoot issues. 
+topics:
+  - login-issues
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Check User Profiles
+
+1. Is user profile information correct at the source (authorization server)?
+2. Generate and check the [HAR file](/troubleshoot/guides/generate-har-files), look for an `id_token`.
+3. Decode the `id_token` at [JWT.io](https://jwt.io) to see if it has the correct information.
+4. Check any custom database scripts or rule logic.
+5. Check if you called `/tokeninfo` endpoint and have a custom domain configured within Auth0. If so, you need to use `/userinfo` endpoint instead
+6. Check if you called `/userinfo` endpoint properly. You should pass an access token. You should call this endpoint with the default Auth0 domain even if the tenant has a custom domain enabled.  
+7. Check if you specified the correct [scope](/scopes) to get an Access Token.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [User Profiles Overview](/users/concepts/overview-user-profile)
+* [Normalized User Profiles](/users/normalized/auth0)
+* [User Profile Structure](/users/references/user-profile-structure)
diff --git a/ja-jp/articles/troubleshoot/guides/generate-har-files.md b/ja-jp/articles/troubleshoot/guides/generate-har-files.md
new file mode 100644
index 0000000000..b073f99123
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/generate-har-files.md
@@ -0,0 +1,78 @@
+---
+title: Generate and Analyze HAR Files
+description: Learn how to troubleshoot with HAR files and steps to generate a HAR file.
+topics:
+  - troubleshoot
+  - har-files
+  - http-archive
+contentType: how-to
+useCase: troubleshoot
+---
+
+# Generate and Analyze HAR Files
+
+A [HAR](https://en.wikipedia.org/wiki/.har) (HTTP Archive) file shows the sequence of redirects that happen during a login transaction. It's an excellent tool for debugging authentication issues, as it can identify where things get stuck. A HAR file is a JSON formatted log of a web browser's interactions with a web server. If authentication isn't working as expected, you can generate and analyze HAR files to find issues. Including a HAR file in your [support requests](${env.DOMAIN_URL_SUPPORT}) can help speed up the troubleshooting process.
+
+::: warning
+Before sending the HAR file to Auth0, ensure that you remove or obfuscate any sensitive information (such as passwords and client secrets) using a text editor. 
+:::
+
+## Generate HAR files with browsers
+
+### Google Chrome
+
+1. Close all __incognito__ windows in Google Chrome.
+2. Open a __new incognito__ window in Google Chrome.
+3. Go to **View > Developer > Developers Tools**.
+4. In the Developer Tools pane, choose the **Network** tab. 
+5. Check the __Preserve Log__ checkbox to record all interactions.
+6. Visit the page and complete the steps that trigger the issue.
+7. Choose the __Network__ tab.
+8. Click the down arrow to export the HAR file.
+9. Save the HAR file. 
+
+### Safari
+
+1. Ensure that **Show Develop menu in menu bar** checkbox is checked under **Safari > Preferences > Advanced**.
+2. Choose **File > Open New Private Window**.
+3. Visit the web page where the issue occurs. 
+4. Choose **Develop > Show Web Inspector**. The Web Inspector window appears.
+5. Complete the steps on the page that trigger the issue.
+6. Select the **Network** tab.
+7. Click **Export** on the upper right side of the pane. 
+8. Save the HAR file. 
+
+### Firefox
+
+1. Close all __private__ windows in Firefox.
+2. Open a __new private__ window in Firefox.
+3. Go to __Tools > Developer > Network__ or **ctrl-shift-E**.
+4. Visit the page and complete the steps that trigger the issue.
+5. Choose the __Network__ tab and right click and then select **Save All As Har**.
+6. Save the HAR file.
+
+
+### Internet Explorer
+
+1. Close all __InPrivate__ windows in Internet Explorer.
+2. Open a __new InPrivate__ window in Internet Explorer (**ctrl-shift-P**.)
+3. Go to __Tools > F12 Developer Options > Network__.
+4. Ensure **Clear entries on navigate** is switched off.
+5. Visit the page and complete the steps that trigger the issue.
+6. Choose the __Network__ tab and select **Export as HAR (Ctrl+S)**.
+7. Save the HAR file.
+
+## Analyze HAR files
+
+1. To view the HAR file, use a tool such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/). 
+2. Analyze the list of web requests captured in the HAR file. In particular, check the sequence of redirects to see how far you get in the authentication process. This helps identify where the issue is happening. 
+3. Compare the sequence of redirects to the expected sequence for your authentication flow.
+
+    For example:
+
+    * There should be a call to the `/authorize` endpoint to start the authentication flow.
+    * There may be redirects to remote identity providers to prompt the user to log in.
+    * Then there should be a redirect back to Auth0 `/login/callback` (`https://login.auth0.com/login/callback`).
+    * Then there should be a redirect back to your application’s callback URL.
+
+<%= include('../_includes/_log_events_link') %>
diff --git a/ja-jp/articles/troubleshoot/guides/verify-connections.md b/ja-jp/articles/troubleshoot/guides/verify-connections.md
new file mode 100644
index 0000000000..8c001cfeda
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/verify-connections.md
@@ -0,0 +1,37 @@
+---
+title: Verify Connections
+description: Learn how to verify connection transactions and external service dependencies to troubleshoot issues. 
+topics:
+  - connections
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Connections
+
+An authentication transaction often has several parts. Auth0 provides methods so you can try individual parts of the transaction to help you find the possible source of the problem.
+
+Most identity provider connections have a **TRY** button to see if the connection is working. If that fails, you can debug the connection without involving the rest of the application. If the connection works, then you can start debugging the application.
+
+1. Use the **TRY** button on a connection to test just the connection.  
+2. If the test with the **TRY** button fails, you know it is not an issue with your application but rather something with the connection configuration or the connection provider.
+3. Check the response from the test with the **TRY** button to see if the response contains a useful error message or other information.
+4. Try logging into the same service through a different path.
+5. If the same issue occurs you’ll know it’s some sort of issue with the account
+6. If a test with the **TRY** button fails for a custom DB connection, it is frequently caused by an issue in the custom DB scripts. Putting console.log statements into them and viewing output in the Console Log can help debug them.
+
+## Verify external service dependencies
+
+1. If your authentication uses external services, like social identity providers, and it suddenly stops working, [check external services status](/monitoring/guides/check-external-services).
+2. If a connection is not working, even with the **TRY** button, check the connection.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Verify Rules](/troubleshoot/verify/rules)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/guides/verify-domain.md b/ja-jp/articles/troubleshoot/guides/verify-domain.md
new file mode 100644
index 0000000000..76ea9bba52
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/verify-domain.md
@@ -0,0 +1,26 @@
+---
+title: Verify Domain
+description: Learn how to verify your domain to troubleshoot issues.
+topics:
+  - domains
+  - custom-domains
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Domain
+
+* Ensure that the domain is the same as that used during authentication.
+* If using an Auth0 [Custom Domain](/custom-domains), it is important to use the same domain as used in the application to invoke authentication. See [Troubleshoot Custom Domains](/custom-domains/troubleshoot) for details. 
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Rules](/troubleshoot/guides/verify-rules)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/guides/verify-platform.md b/ja-jp/articles/troubleshoot/guides/verify-platform.md
new file mode 100644
index 0000000000..a131ec5578
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/verify-platform.md
@@ -0,0 +1,90 @@
+---
+title: Verify Platform
+description: Learn how to verify your platform to troubleshoot issues.
+topics:
+  - platform
+  - language
+  - browser
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Platform
+
+Ensure that you are on current versions of your technology stack. If you're using an older version of a programming language or library consider updating to the current version.
+
+* Check the [Auth0 support matrix](/support/matrix) to see if the language or library versions you're using is supported.
+* If there's a problem in one environment (such as development) but not another (such as production), compare the versions of the technology stack across the two environments.
+* If not, upgrade your technology stack and browser to the latest versions and test again before creating a support request.
+
+## Check the scope of the issue
+
+Testing on different browsers, platforms, locations, and users can help narrow down the source of a problem when it occurs. Perform the following tests and review the [logs in your Auth0 dashboard](${manage_url}/#/logs) after each test for more information.
+
+<%= include('../_includes/_log_events_link') %>
+
+### Test with different browsers
+
+* Does the issue happen with all browsers or just some?
+* Test in a new incognito or private browser session (no previous state).
+* Upgrade to the latest browser version and re-test.
+* Turn off browser plugins and re-test to see if a plug-in contributes to the issue.
+
+### Test with different users
+
+* Does the issue occur for all users or just some?  
+* If some, is there a pattern? Such as location, connection, or role?
+
+### Test with different connections (if possible)
+
+* Does the issue happen with all connections or just one?
+
+### Test with different client applications (if you have more than one)
+
+* Does the issue happen with all clients or just one?
+
+### Test across different environments
+
+* Try the development, staging, and production environments of your application(s).
+* Try across different Auth0 tenants to see if any differences.
+
+## Check if the issue is consistent or intermittent
+
+* If the issue is consistent, note the steps to reliably duplicate the issue.
+* If the issue intermittent, note any pattern that might cause it.
+* Is this an issue with a new setup, or did it work before and is now broken?  
+    - If it just broke, what changes were made? 
+    - Does undoing the changes fix the issue?
+
+## Issues that affect only one or a few users
+
+* [Check the user's profile](/troubleshoot/guides/verify-user-profiles), browser, or device for any issues.
+* Check to see if it happens in all browsers for the affected users (indicating a data issue) or just certain types of browsers (indicating a browser-specific issue).
+* Check to see if the browser has enabled JavaScript and cookies.
+* Check that the caps lock key is disabled.
+* If the user is using a mobile device, check to see if there's any software that might impact authentication and/or authorization (such as not running some type of required software).
+* Check to see if the user can access some of the application's key URLs, such as the identity provider's Single Sign-on (SSO) URL (indicating a network connectivity issue).
+
+## Issues that occur after go-live (worked before, then stopped working)
+
+* Check if any recent changes to your application or any APIs you call?
+* Check if any recent network changes (load balancer, firewall, proxy config changes).
+* Check if any recent infrastructure changes (e.g. credentials for LDAP or DB servers?)
+* Check for any patches or updates to applications, infrastructure, or technology stacks.
+* Check that all your servers are running NTP and have accurate time sync
+* Check if any of your certificates have expired.
+* Check with owners of any remote identity providers if anything changed.
+    - Check network connectivity to any remote identity providers.
+* Check notifications in Auth0 dashboard/migrations - any changes you overlooked?
+* Check Auth0 change log - any recent configuration changes related to your issue?
+* Check if any component in the technology stack has been updated or patched recently?
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Verify Rules](/troubleshoot/guides/verify-rules)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/guides/verify-rules.md b/ja-jp/articles/troubleshoot/guides/verify-rules.md
new file mode 100644
index 0000000000..acaf441314
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/guides/verify-rules.md
@@ -0,0 +1,31 @@
+---
+title: Verify Rules
+description: Learn how to verify rules to troubleshoot issues. 
+topics:
+  - rules
+contentType: how-to
+useCase: troubleshooting
+---
+
+# Verify Rules
+
+Failures in a rule can often cause authentication issues. Perform the following checks to see if rules could be behind your issue.
+
+* Turn rules off and see if the issue still occurs.
+* Check that your rules catch all possible errors that might be returned. Uncaught errors could cause failures.
+* Check that your rules are calling the `callback` function only once for each logical branch in your code.
+* Add `console.log()` statements to your rules to debug and check state. For example: `console.log(“output = “ + some_variable);`.
+* Click **Debug Rule** in the Dashboard to view the output from your `console.log` statements.
+* View the output in the Real-time Webtask Logs to get more information about your rules’ execution.
+
+<%= include('../_includes/_log_events_link') %>
+
+## Keep reading
+
+* [Verify Connections](/troubleshoot/guides/verify-connections)
+* [Verify Platform](/troubleshoot/guides/verify-platform)
+* [Verify Domain](/troubleshoot/guides/verify-domain)
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Check External Services Status](/monitoring/guides/check-external-services)
+* [Monitor Applications](/monitoring/guides/monitor-applications)
+* [Monitor Using System Center Operations Manager](/monitoring/guides/monitor-using-SCOM)
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/index.md b/ja-jp/articles/troubleshoot/index.md
new file mode 100644
index 0000000000..eaa75352cd
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/index.md
@@ -0,0 +1,49 @@
+---
+title: Troubleshoot
+description: Running into an issue? Here are the things you should check to troubleshoot and solve common issues in Auth0.
+topics:
+  - troubleshooting
+  - errors
+contentType:
+  - index
+useCase:
+  - troubleshooting
+---
+
+# Troubleshoot
+
+::: note
+Follow [@auth0status](https://twitter.com/auth0status) on Twitter to get the latest status updates. 
+:::
+
+Before submitting a ticket to Auth0 [Support Center](https://support.auth0.com/), review the following troubleshooting guides to identify and possibly fix the issue. If you still cannot address the issue, you can create a support ticket. 
+
+## Basic areas to check and verify first
+
+There are a few [basic](/troubleshoot/concepts/basics) areas to check and verify before you submit a support ticket. These areas include platform, connections, domain, rules, and deprecations.  
+
+## Authentication & authorization issues
+
+We provide checklists and guidelines for checking [authentication and authorization](/troubleshoot/concepts/auth-issues) issues with API calls, login, user profiles, MFA, and SAML. 
+
+## Integration & extensibility issues
+
+We provide troubleshooting tips for issues you may have pertaining to [integrations and extensibility](/troubleshoot/concepts/integration-extensibility-issues) such as partner connections, custom databases, and custom domains. 
+
+## Tools
+
+Here are some helpful tools to help you troubleshoot issues:
+
+* [Auth0 Logs](/logs)
+* [HAR files](/troubleshoot/guides/generate-har-files)
+* [JWT Inspector](https://jwt.io/)
+* [Authentication API Debugger](/extensions/authorization-extension/v2/troubleshooting)
+
+## Keep reading
+
+* [Check Auth0 Status](/monitoring/guides/check-status)
+* [Supported versions](/support/matrix)
+* [Support Plans and Service Level Agreements](/support#defect-responses)
+* [Operational Policies](/policies)
+* [Open and Manage Support Tickets](/support/tickets)  
+* [Professional Services](/services)
diff --git a/ja-jp/articles/troubleshoot/references/invalid-token.md b/ja-jp/articles/troubleshoot/references/invalid-token.md
new file mode 100644
index 0000000000..d858c6bfec
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/invalid-token.md
@@ -0,0 +1,46 @@
+---
+title: Invalid Token Errors
+description: Describes how to troubleshoot invalid token errors. 
+topics:
+  - errors
+  - tokens
+contentType:
+  - reference
+useCase: error-management
+---
+
+# Invalid Token Errors
+
+## Parsing an HS256-Signed ID Token Without an Access Token
+
+**Error Message**: The ID Token cannot be validated because it was signed using the HS256 algorithm and public applications (such as a browser) can’t store secrets. Please read the associated doc for ways to fix this.
+
+### Why this error occurred
+
+Beginning with **auth0.js version 9** and **Lock version 11**, when ID Tokens are signed with HS256, they are discarded and a call to **/userinfo** is made to retrieve user information. 
+
+Calling **/userinfo** requires an Access Token. If you don't ask for an Access Token when authenticating, you will receive the following error:
+
+```
+The id_token cannot be validated because it was signed with the HS256 algorithm
+and public applications (like a browser) can’t store secrets.
+Please read the associated doc for possible ways to fix this.
+```
+
+### Ways to fix this error
+
+There are two ways to fix the error:
+
+1. **(RECOMMENDED)** Change the application signature algorithm to RS256 instead of HS256.
+2. Change the value of your **responseType** parameter to **token id_token** (instead of the default), so that you receive an Access Token in the response.
+
+To change the application signature algorithm to RS256 instead of HS256:
+
+    1. Go to [Dashboard > Applications]({$manage_url}/#/applications).
+    1. Select your application.
+    1. Scroll to the bottom of the **Settings** tab, and click **Show Advanced Settings**.
+    1. Open up the **OAuth** tab. Change the value of **JsonWebToken Signature Algorithm** to **RS256**.
+    1. Scroll to the bottom of the page and click **Save Changes**.
+
+    If you proceed with this option and you are using the ID Token to call your APIs, be sure to change your server code so that it validates tokens using the RS256 algorithm instead of HS256. Note that using ID Tokens to call APIs [is not recommended](/tokens).
+
diff --git a/ja-jp/articles/troubleshoot/references/mgmtv2-errors.md b/ja-jp/articles/troubleshoot/references/mgmtv2-errors.md
new file mode 100644
index 0000000000..3c98b12c0b
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/mgmtv2-errors.md
@@ -0,0 +1,12 @@
+---
+public: false
+topics:
+  - errors
+  - dashboard
+  - api
+contentType:
+  - reference
+useCase: error-management
+---
+
+# Management API Errors
\ No newline at end of file
diff --git a/ja-jp/articles/troubleshoot/references/oauth-errors.md b/ja-jp/articles/troubleshoot/references/oauth-errors.md
new file mode 100644
index 0000000000..4c0642b44d
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/oauth-errors.md
@@ -0,0 +1,15 @@
+---
+public: false
+topics:
+  - errors
+  - oauth1
+  - oauth2
+contentType:
+  - reference
+useCase: error-management
+---
+
+# OAuth Errors
+
+<%= include('../../_includes/_co_authenticate_errors', { library : 'Lock v11'}) %>
+
diff --git a/ja-jp/articles/troubleshoot/references/saml-errors.md b/ja-jp/articles/troubleshoot/references/saml-errors.md
new file mode 100644
index 0000000000..64b586983c
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/saml-errors.md
@@ -0,0 +1,99 @@
+---
+public: false
+topics:
+  - errors
+  - saml
+contentType:
+  - reference
+useCase: error-management
+---
+
+# SAML Errors
+
+## Invalid request - connection disabled
+
+```json
+{
+  "error": "invalid_request",
+  "error_description": "the connection was disabled"
+}
+```
+
+### Cause
+
+This message indicates that the Application doesn't have an active Connection associated.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *Applications* tab.
+4. Enable at least one Application (if you don't see any in the list, you will need to [create an application](/applications) before proceeding).
+
+## IdP-Initiated Default App Not Configured
+
+```json
+{
+  "invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter."
+}
+```
+
+### Cause
+
+This error appears if you haven't provided the necessary information to support IdP-initiated login flows.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Select the **Default Application** and the **Response Protocol** used by that Application, and (optionally) specify any additional parameters you want passed to the Application.
+
+::: panel SP-Initiated Login
+If you see this error when using a SP-initiated flow, one of the following is missing or empty:
+
+* The `RelayState` parameter
+* The `InResponseTo` attribute in the SAML response
+
+If these are missing or empty, Auth0 treats the login as IdP-initiated. You can fix this error by checking your configuration to ensure that both fields are populated and returned appropriately.
+:::
+
+## Missing RelayState parameter
+
+### Cause
+
+This error occurs when the identity provider doesn't return the `RelayState` parameter along with its response.
+
+### Solution
+
+Work with the identity provider to ensure that it returns the `RelayState` parameter.
+
+## Audience is Invalid
+
+This error occurs if the value of the `audience` element from the identity provider's SAML response doesn't match the value expected by Auth0. Auth0 expects the value to be the Entity ID for the Connection.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). Find your Connection, and click on **Setup Instructions**.
+2. Under the *Common Settings* section, your **Entity ID** is the second parameter provided.
+
+Make sure that the identity provider sends the correct `audience` value in the SAML response.
+
+## Incorrect protocol specified
+
+There is an incorrect response protocol on the **IdP-Initiated** tab. The response protocol is the one used between Auth0 and the Application (not the remote identity provider). For example, if you set this value to **SAML** when your Application expects **OpenID Connect** or **WS-Fed** results in errors due to the incorrect configuration.
+
+### Solution
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Check the value you have set in the **Response Protocol** field.
+
+## User isn't logged out from the IdP
+
+When ADFS is configured as SAML IdP, if the ADFS is relaying party trust `Name ID` attribute isn't mapped the logout flow fails. For example, with the federated parameter `v2/logout?federated&...` user isn't redirected to the ADFS SAML logout endpoint but redirects back to application callback URL directly. As a consequence, the user isn't logged out from the IdP in that case.
+
+### Solution
+
+Add the `Name ID` attribute as a rule on the SAML Relaying Party Trust. 
diff --git a/ja-jp/articles/troubleshoot/references/self_change_password.md b/ja-jp/articles/troubleshoot/references/self_change_password.md
new file mode 100644
index 0000000000..739ba41d28
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/self_change_password.md
@@ -0,0 +1,40 @@
+---
+description: Error messages for the self change password API.
+public: false
+topics:
+  - errors
+  - passwords
+contentType: reference
+useCase: error-management
+---
+# Self Change Password Errors
+
+Below you will find the errors codes and possible solutions to various errors that can occur with the self change password api.
+
+## Error Format
+
+Error messages are returned in the standard format:
+
+```json
+{
+  "error": "error_code",
+  "error_description": "the description of the error.",
+  "error_uri": "https://auth0.com/docs/troubleshoot/references/errors/self_change_password"
+}
+```
+
+## Error Codes
+
+### `invalid_request`
+
+This error results when you supply invalid parameters. Error messages will describe the issue such as a required parameter or invalid format.
+
+
+### `invalid_user_password`
+
+This error results from a bad `username`/`email` and `old_password` combination being sent. Retry the request with the correct username and `old_password`.
+
+
+### `change_password_error`
+
+This error results from various conditions with the underlying identity provider. Generally, this happens when you are using a custom database and have not implemented the change password script.
diff --git a/ja-jp/articles/troubleshoot/references/wsfed-errors.md b/ja-jp/articles/troubleshoot/references/wsfed-errors.md
new file mode 100644
index 0000000000..d5da13e030
--- /dev/null
+++ b/ja-jp/articles/troubleshoot/references/wsfed-errors.md
@@ -0,0 +1,11 @@
+---
+public: false
+topics:
+  - errors
+  - ws-fed
+contentType:
+  - reference
+useCase: error-management
+---
+
+# WS-Fed Errors
\ No newline at end of file
diff --git a/ja-jp/articles/universal-login/_implement_universal_login.md b/ja-jp/articles/universal-login/_implement_universal_login.md
new file mode 100644
index 0000000000..bb54d23afc
--- /dev/null
+++ b/ja-jp/articles/universal-login/_implement_universal_login.md
@@ -0,0 +1 @@
+For detailed instructions on setting up your application to use Universal Login, check out our [Quickstart guides](/quickstarts) and choose the one that best fits your chosen technologies. The Quickstart guides will walk you through all of the implementation steps.
\ No newline at end of file
diff --git a/ja-jp/articles/universal-login/classic.md b/ja-jp/articles/universal-login/classic.md
new file mode 100644
index 0000000000..25d02460bc
--- /dev/null
+++ b/ja-jp/articles/universal-login/classic.md
@@ -0,0 +1,20 @@
+---
+description: Classic Universal Login Experience
+topics:
+  - login
+  - universal-login
+contentType: index
+---
+# Classic Universal Login Experience
+
+Auth0's Classic Universal Login experience is built on top of Auth0's JavaScript libraries ([Lock.js](/libraries/lock), [auth0.js](/libraries/auth0js), MFA Widget, Password Reset). Compared to the New Universal Login experience, it currently offers a more complete feature set.
+
+When you [customize the HTML in the Dashboard](${manage_url}/#/login_page) for Universal Login pages, the default templates will also use the same JavaScript libraries, so from a UX and functional perspective, the transition between the default user interface and a custom one is more natural.
+
+The Classic Experience has extensive [customization options](/universal-login/customization-classic) available. After choosing one of the templates, you can modify them to meet your needs. The Lock widget, if used, has a variety of both appearance and behavior options that can be changed. The Auth0.js based templates have even more flexibility, as the UI is entirely custom made and can be modified to match your application's styles if you wish to do so.
+
+Given that it is being used by a significant percentage of Auth0 customers, the Classic Universal Login Experience will be maintained for the foreseeable future. However, the majority of significant new feature development will be done on the [New Universal Login Experience](/universal-login/new).
+
+## Implement Universal Login
+
+<%= include('./_implement_universal_login') %>
diff --git a/ja-jp/articles/universal-login/custom-error-pages.md b/ja-jp/articles/universal-login/custom-error-pages.md
new file mode 100644
index 0000000000..2ff0888a57
--- /dev/null
+++ b/ja-jp/articles/universal-login/custom-error-pages.md
@@ -0,0 +1,112 @@
+---
+title: Custom Error Pages
+description: How to setup a custom error page for authorization error events.
+toc: true
+crews: crew-2
+topics:
+  - custom-error-pages
+  - hosted-pages
+contentType:
+    - how-to
+useCase: customize-hosted-pages
+---
+# Custom Error Pages
+
+In the event of an authorization error, you may choose to display to your users either [the default Auth0 error page](/universal-login/error-pages) or a customized error page.
+
+This article will show you how to use a customized error page. For details on the default Auth0 error page see [Error Pages](/universal-login/error-pages).
+
+## How to customize the error page
+
+If you choose to display a custom error page, you have two options:
+
+-  [Redirect the user to a custom error page](#redirect-users-to-a-custom-error-page)
+-  [Configure Auth0 to render a custom error page on your behalf](#render-a-custom-error-page). This feature is only available via the Management API.
+
+### Redirect users to a custom error page
+
+You can configure Auth0 to redirect users to a custom error page, using the Dashboard or the Management API.
+
+If you use the Dashboard, follow these steps:
+
+1. Log in to the [Dashboard](${manage_url}).
+1. Click on your tenant name in the top right corner to bring up the associated dropdown box.
+1. Select **Settings** to open the [Tenant Settings](${manage_url}/#/tenant/) page.
+1. Scroll down to the Error Pages section.
+1. Select the option **Redirect users to your own error page**.
+1. Provide the URL of the error page you would like your users to see.
+
+## Customize error pages via the Management API
+
+Instead of using the Management Portal, you may configure your error pages by making the appropriate `PATCH /api/v2/tenants/settings` call to the Management API.
+
+### Redirect users to a custom error page
+
+To redirect users to a custom error page, update the `url` field of your JSON body to point to the location of the error page.
+
+![Error Page Redirect Option](/media/articles/error-pages/redirect-error-page.png)
+
+If you use the API instead, use the `PATCH /api/v2/tenants/settings` endpoint. Update the `url` field of your JSON body to point to the location of the error page.
+
+```har
+{
+    "method": "PATCH",
+    "url": "https://${account.namespace}/api/v2/tenants/settings",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Authorization", "value": "Bearer YOUR_TOKEN"},
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData": {
+        "mimeType": "application/json",
+        "text": "{\"error_page\": {\"html\": \"\", \"show_log_link\":false, \"url\": \"http://www.example.com\"}}"
+    },
+    "headersSize" : -1,
+    "bodySize" : -1,
+    "comment" : ""
+}
+```
+The following parameters are appended to the `url` as query string to include the error information. Note that the parameters presented in the `url` vary depending on the error type.
+* `client_id`
+* `connection`
+* `lang`
+* `error`
+* `error_description`
+* `tracking`
+
+### Render a custom error page
+
+You can render your custom error page with Liquid syntax using the following variables:
+
+* `{client_id}`
+* `{connection}`
+* `{lang}`
+* `{error}`
+* `{error_description}`
+* `{tracking}`
+* `{log_url}`
+
+To provide the appropriate HTML, pass in a string containing the appropriate Liquid syntax to the `html` element:
+
+```har
+{
+    "method": "PATCH",
+    "url": "https://login.auth0.com/api/v2/tenants/settings",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [
+      { "name": "Authorization", "value": "Bearer YOUR_TOKEN"},
+      { "name": "Content-Type", "value": "application/json" }
+    ],
+    "queryString" : [],
+    "postData": {
+        "mimeType": "application/json",
+    "text": "{\"error_page\": {\"html\": \"
    {{error | escape }} {{error_description | escape }} This error was generated {{'now' | date: '%Y %h'}}.
    \", \"show_log_link\": false, \"url\": \"\"}}"
+    },
+    "headersSize" : -1,
+    "bodySize" : -1,
+    "comment" : ""
+}
+```
diff --git a/ja-jp/articles/universal-login/customization-classic.md b/ja-jp/articles/universal-login/customization-classic.md
new file mode 100644
index 0000000000..6f26ed7249
--- /dev/null
+++ b/ja-jp/articles/universal-login/customization-classic.md
@@ -0,0 +1,79 @@
+---
+description: Overview of advanced customization of the login page for the Universal Login classic experience.
+topics:
+  - login
+  - universal-login
+  - customization
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Classic Universal Login UI Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+These settings, once changed, will take effect on all your Universal Login pages if you have not enabled customization of the pages' code. The settings will also work if you have enabled customization but are using the predefined templates and have not changed those options in the code.
+
+## Advanced Customization
+
+In addition to the basic settings described above, you can alter the actual code of the Universal Login flow. You can customize the HTML code for Login, Password Reset and MFA pages.
+
+![Login Page](/media/articles/universal-login/login.png)
+
+::: panel-warning Responsibility for Updates
+When the customization toggle is flipped on, you then become responsible for updates and maintenance of the pages, as it can no longer be automatically updated by Auth0. This includes updating the version numbers for any included Auth0 SDK or widget.
+
+You should also exercise caution regarding the use of third-party JavaScript on your Login Page, since sensitive security-related information often flows through the page and the introduction of cross-site scripting ([XSS](/security/common-threats#cross-site-request-forgery)) vulnerabilities is of particular concern.
+
+If you have enabled customization to inspect the page code, and then decide **not** to customize your login page, you should make sure to disable the **Customize Login Page** toggle, so Auth0 will render the default pages.
+:::
+
+
+## Login
+
+### Choose a template to begin
+
+If you intend to perform advanced customization to the content of the login page, you'll first want to choose the template that you would like to start from. You will find these templates in a dropdown just above the code editor for the login page, if you have toggled customization on. 
+
+The templates use the libraries linked below to provide the login experience for the end-user. Feel free to read the documentation for each library below, to better understand how they can be customized for your needs. 
+
+::: note
+These libraries can be used within the Universal Login page, but they can also be embedded directly into an application. While in this case we are discussing using them as part of the Universal Login flow, if you read their documentation, you will notice both use cases being explained.
+:::
+
+- [Lock](/libraries/lock) - Lock is a pre-built, customizable login widget that will allow your users to quickly and easily login to your application.
+- [Lock (Passwordless Mode)](/libraries/lock/v11#passwordless) - Lock in Passwordless Mode uses the same Lock interface, but rather than offering identity providers as login options, will simply ask the user to enter an email or SMS number to begin a passwordless authentication transaction.
+- [Auth0.js](/libraries/auth0js) - Auth0.js is the SDK used for interacting with the Auth0 [authentication API](/api/authentication). Primarily, you would use the SDK if you need to build your own custom login UI, or implement more complex functionality than simply allowing your users to login. 
+
+
+
+### Modify the code of the login page
+
+If you are using the default login page and just wish to modify it a bit further than the Simple Customization options allow, you may want to modify the behavior of the Lock widget used on the Universal Login page. The Lock widget can be configured to behave or appear in many ways, including the following:
+
+- Show the user the signup page by default instead of the login page
+- Have different colors, text, or languages shown by default on the login widget
+- Show specific connections only
+
+To learn more about how to do these, and many other customizations, take a look at the [Lock Configuration Guide](/libraries/lock/v11/configuration) for help configuring the Lock widget which is used in the page.
+
+If you intend to significantly change the page's appearance, you may wish to use the Custom Login Form template instead of the Lock template. You can use the example in the Custom Login Form template as a guideline that shows you how to get the values and information you need into the login page and how to use the Auth0.js SDK to do so, then do the styling and layout in whatever manner you wish. You may perform whatever CSS customizations that you like, as long as they are included in this one file, as there is no option to host a separate CSS file on your Auth0 tenant.
+
+## Other facets of Universal Login
+
+Auth0 offers you the ability to customize and display several other pages containing Auth0-related functionality and to which Auth0 redirects your users during the authorization process, beyond just the login page described above. You can modify the following types of pages from your [Dashboard](${manage_url}):
+
+* [Customize Hosted Password Reset Page](/universal-login/password-reset)
+* [Multi-factor Authentication Page](/universal-login/multifactor-authentication)
+* [Error Pages](/universal-login/error-pages)
+
+While Auth0 hosts these custom pages, you can still manage your pages using the [version control system of your choice](https://auth0.com/docs/universal-login/version-control).
\ No newline at end of file
diff --git a/ja-jp/articles/universal-login/customization-new.md b/ja-jp/articles/universal-login/customization-new.md
new file mode 100644
index 0000000000..256be1d688
--- /dev/null
+++ b/ja-jp/articles/universal-login/customization-new.md
@@ -0,0 +1,43 @@
+---
+description: New Universal Login UI Customization
+topics:
+  - login
+  - universal-login
+  - customization
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# New Universal Login UI Customization
+
+## Simple Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+You can also configure the favicon URL and a custom font URL using [the Branding API](/api/management/v2#!/Branding). 
+
+## Page Templates
+
+You can further the New Universal Login pages by providing a Page Template using the [Liquid template language](https://shopify.github.io/liquid/). Learn more in the [Page Template documentation](/universal-login/page-templates).
+
+## Combining New Universal Login and Classic Universal Login
+
+Given the Classic Universal Login experience is still more flexible than the New Universal Login experience, you could want to combine pages from both flows. 
+
+For example, if you want to implement Passwordless with MFA, you can use the 'Classic' login page for Passwordless and the 'New' MFA page for MFA, you can do so as follows:
+
+1. Enable the New Universal Login Experience.
+1. Customize the HTML page of the Login page with whatever content you want, for example, the `Auth0LockPasswordless` widget. 
+
+In this case, users will get a customized Classic behavior login page that allows them to log in via a passwordless connection, but will get the MFA page that looks like the New Universal Login page.
+
+Check the [Classic Universal Login customization documentation](/universal-login/customization-classic) to learn more.
diff --git a/ja-jp/articles/universal-login/default-login-url.md b/ja-jp/articles/universal-login/default-login-url.md
new file mode 100644
index 0000000000..f63742f5c8
--- /dev/null
+++ b/ja-jp/articles/universal-login/default-login-url.md
@@ -0,0 +1,77 @@
+---
+title: Tenant's and Application’s Default Login Route
+description: How to configure your tenant's and application's default login route.
+toc: true
+topics:
+  - applications
+contentType: how-to
+---
+# Configure Default Login Routes
+
+In certain cases (described below), Auth0 could need to redirect back to the application's login initiation endpoint, using [OIDC Third Party Initiated Login](https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin).
+
+You can configure these URIs in [Application Settings](/dashboard/reference/settings-application) or [Tenant Advanced Settings](/dashboard/reference/settings-tenant).
+
+You can also do this using the Management API:
+
+**Application level**
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/clients/${account.clientId}",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text": "{\"initiate_login_uri\": \"\"}"
+  }
+}
+```
+
+**Tenant level**
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" },
+    { "name": "Cache-Control", "value": "no-cache" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text": "{\"default_redirection_uri\": \"\"}"
+  }
+}
+```
+
+The `login_url` should point to a route in the application that ends up redirecting to Auth0's `/authorize` endpoint, e.g. `https://mycompany.org/login`. Note that it requires `https` and it cannot point to `localhost`.
+
+## Scenarios for redirecting to the default login route
+
+### Users bookmarking the login page
+
+When an application initiates the login process, it navigates to `https://${account.namespace}/authorize` with a set of [required parameters](/api/authentication#login). Auth0 then redirects end-users to a `https://${account.namespace}/login` page, with a URL that looks like:
+
+`https://${account.namespace}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&...`
+
+The `state` parameter points to a record in an internal database where we track the status of the authorization transaction. Whenever the transaction completes, or after X time passes, the record is deleted from the internal database.
+
+Sometimes users bookmark the login page, and when they navigate to the bookmarked `/login` URL, the transaction record is no longer there and Auth0 cannot continue with the login flow. In that case, Auth0 will redirect to the default client URL if configured, or the tenant level URL if not. If no default login URL is set, Auth0 will render an error page.
+
+### Completing the password reset flow
+
+When the password reset flow is completed and the default URI for the application or tenant is configured, users will see a button that will let them navigate back to the login page.
+
+This behavior only happens when the [New Universal Login Experience](/universal-login/new) is enabled. In Classic mode, you will need to [configure the Redirect URL in the Password Reset Email Template](/email/templates#configuring-the-redirect-to-url).
+
+### Completing the email verification flow
+
+As part of the signup process, users get an email to verify their email address. If they click on the link, they will land on a page that says that the email was verified, with a button to go back to the application. When clicked, users will be redirected to the login page, and if they already have a valid session, they'll end up being redirected to the application.
+
+This behavior only happens when the [New Universal Login Experience](/universal-login/new) is enabled. In Classic mode, you will need to [configure the Redirect URL in the Verification Email Template](/email/templates#configuring-the-redirect-to-url).
diff --git a/ja-jp/articles/universal-login/error-pages.md b/ja-jp/articles/universal-login/error-pages.md
new file mode 100644
index 0000000000..d7ea9a8325
--- /dev/null
+++ b/ja-jp/articles/universal-login/error-pages.md
@@ -0,0 +1,51 @@
+---
+description: Guide on how to use the hosted error pages for authorization error events
+crews: crew-2
+topics:
+  - error-pages
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+
+# Error Pages
+
+## Generic Error Page
+
+Throughout the authentication process, your users may encounter errors. Auth0 provides you the option of using [custom error pages](/hosted-pages/custom-error-pages), but you may also choose to use the generic error page that Auth0 provides by default.
+
+To find the default page name for the generic error page, see [How to Use Version Control to Manage Your Universal Login Pages](/universal-login/version-control).
+
+If you configure the following fields in your [Tenant Settings](${manage_url}/#/tenant/), the provided information will be included in the generic error page:
+
+* **Friendly Name**: the name of your company
+* **Logo URL**: the URL of your company logo
+* **Support Email**: the email address of your company's support team
+* **Support URL**: the URL for your company's support page
+
+``` note
+Auth0 will display the **Tenant** information exactly as entered on the Tenant Settings page.
+```
+
+In addition to these fields, the error page returns some contextual information to assist you in troubleshooting the source of an error. The following fields will be returned based on the request which resulted in the error:
+
+* **Client ID**: the identifier for the Auth0 application
+* **Connection**: the connection used at the time of error
+* **Language**: the language set to be used at the time of error
+* **Error**: the status code corresponding to the error
+* **Error Description**: a description of the error
+* **Show Log URL**: a link to the error in your tenant logs
+* **Title**: the friendly name of the tenant
+* **Tenant**: the tenant information (friendly name, logo URL, support email, and support URL)
+
+::: note
+The error page can only return information that was available in the request. If, for example, the request which resulted in an error did not contain a `client_id`, no client ID will be returned by the error page.
+:::
+
+Fields returned by the error page will be appended as query string parameters to the page's URL.
+
+## Custom Error Pages
+
+In the event of an authorization error, you may choose to display to your users either the default Auth0 error page or a customized error page. If you choose to use a customized error page, you may do so by either redirecting users to your own error page or by updating the generic error page to display customized HTML.
+
+See [Custom Error Pages](/universal-login/custom-error-pages) for details on how to configure your own custom error page for use with Auth0.
diff --git a/ja-jp/articles/universal-login/i18n.md b/ja-jp/articles/universal-login/i18n.md
new file mode 100644
index 0000000000..2500143f81
--- /dev/null
+++ b/ja-jp/articles/universal-login/i18n.md
@@ -0,0 +1,86 @@
+---
+description: Internationalization in Universal Login
+topics:
+  - universal-login
+  - internationalization
+toc: true
+---
+# Universal Login Internationalization
+
+## Internationalization in the New Universal Login Experience
+
+The New Universal Login Experience is currently localized to the languages below, with more languages to be added over time:
+
+| Code   | Language  |
+|--------|-----------|
+| cs     | Czech     |
+| da     | Danish    |
+| de     | German    |
+| en     | English   |
+| es     | Spanish   |
+| fi     | Finnish   |
+| fr-FR  | French    |
+| fr-CA  | French (Canada) |
+| hi     | Hindi     |
+| hu     | Hungarian |
+| it     | Italian   |
+| ja     | Japanese  |
+| ko     | Korean    |
+| nb     | Norwegian |
+| nl     | Dutch     |
+| po     | Polish    |
+| pt-BR  | Portuguese (Brazilian)|
+| pt-PT  | Portuguese (Portugal) |
+| ro     | Romanian  |
+| ru     | Russian   |
+| sk     | Slovak    |
+| sv     | Swedish   |
+| zh-CN  | Chinese (Simplified)  |
+| zh-TW  | Chinese (Traditional) |
+
+### Language Selection
+
+The language to render the pages will be selected based on:
+
+- The languages supported by Auth0, which are listed above.
+- The list of languages configured in Tenant Settings, where you can select the languages your tenant supports and select a default one. By default, the list has only English, so if you want to support other languages you first need to update the list.
+- The value of the `ui_locales` parameter sent to the [authorization request endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), which can be used to constrain the language list for an application or session.
+- The `Accept-Language` HTTP header sent by the browser. The pages will be rendered in this language if it is allowed by the settings above. If not, pages will be rendered in the default language.
+
+### Setting the tenant supported languages
+
+You can set the supported and default languages in the Dashboard's [Tenant Settings](${manage_url}/#/tenant) section.
+
+![](/media/articles/universal-login/languages.png)
+
+You can also specify the enabled languages for the tenant via the Management API using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings). The first language in the list will be the default one.
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/tenants/settings",
+  "headers": [
+    { "name": "Content-Type", "value": "application/json" },
+    { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }
+  ],
+  "postData": {
+      "mimeType": "application/json",
+      "text" : "{ \"enabled_locales\" : [ \"en\", \"es\"]}"
+  }
+}
+```
+
+### Current Limitations
+
+- It is not possible for you to add additional languages (although Auth0 will be adding more over time).
+- The `ui_locales` parameter can only be used in OAuth flows, as it’s not available in SAML or WS-Federation.
+- The `ui_locales` parameter is not forwarded to upstream IdPs.
+- It is not possible to localize the scopes in the Consent page.
+
+## Internationalization in the Classic Universal Login Experience
+
+In the Classic Universal Login experience, localization is done using our JavaScript widgets for [login](/libraries/lock/v11/i18n), the [password reset page](/universal-login/password-reset) and [password policies](/i18n/password-options). 
+
+The [MFA page](/universal-login/multifactor-authentication) by default uses the Auth0 MFA Widget, which cannot be localized. You can create localized versions by using [guardian.js](https://github.com/auth0/auth0-guardian.js).
+
+It is not possible to localize the Consent page.
diff --git a/ja-jp/articles/universal-login/index.md b/ja-jp/articles/universal-login/index.md
new file mode 100644
index 0000000000..1753159969
--- /dev/null
+++ b/ja-jp/articles/universal-login/index.md
@@ -0,0 +1,93 @@
+---
+description: Overview of Universal Login with Auth0
+topics:
+  - login
+  - universal-login
+  - password-reset
+  - mfa
+  - error-pages
+  - hosted-pages
+contentType: index
+toc: true
+useCase: customize-hosted-pages
+---
+# Auth0 Universal Login
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. Each time a user needs to prove their identity, your applications redirect to Universal Login and Auth0 will do what is needed to guarantee the user's identity. 
+
+By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. You can start off using a simple username and password. With a simple toggle switch, you can add new features such as social login and multi-factor authentication (MFA). All of this is dynamic, and adjustable in real-time without requiring application-level changes, since all functionality is driven dynamically by the web pages served by the centralized Authentication Server. Your application will benefit from all improvements Auth0 does in the login flow without you changing a single line of code. 
+
+The login page appearance and behavior is customizable right from the [Dashboard](${manage_url}). The logo and colors of the login pages can be changed, and in more advanced use cases, the code of each page itself can be modified.
+
+For information on the differences between Universal Login and traditional embedded login within your application, see [our comparison guide](/guides/login/universal-vs-embedded).
+
+## Choosing an experience
+
+There are two available experiences in Universal Login. The Classic Universal Login Experience uses JavaScript controls for each page. The New Universal Login experience does not _require_ JavaScript to work, and it offers a simpler and faster experience for end-users.
+
+In the Dashboard, the dialog shown below lets you select which Experience will be used for default, non-customized pages:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+**Choose an experience to learn more about:**
+
+* [Classic Universal Login Experience](/universal-login/classic)
+* [New Universal Login Experience](/universal-login/new) (and its [current limitations](/universal-login/new-experience-limitations))
+
+## Customizing Universal Login
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo (recommended size: 150 x 150 pixels)
+* Primary Color
+* Background Color
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+You can further customize login pages:
+
+- Customizing the [Classic Universal Login Experience](/universal-login/customization-classic)
+- Customizing the [New Universal Login Experience](/universal-login/customization-new)
+
+## Implement Universal Login
+
+In addition to configuring Universal Login for your tenant's applications, you will also need to complete a few other steps:
+
+1. Set up a connection(s) in the [Dashboard](${manage_url}) (Choose **Connections** in the Dashboard's sidebar, then choose a type and pick one to configure, such as a database or a social login provider). 
+1. Set up your application in the [Dashboard](${manage_url}/#/applications). 
+1. Configure your application's code to call Auth0's [`/authorize`](/api/authentication#login) endpoint in order to trigger Universal Login, and then to deal with the response. You can either do this directly, or use one of our SDKs to make the process easier.
+
+### Navigating to the login page
+
+You can navigate to the login page from any browser:
+
+```text
+https://${account.namespace}/authorize?
+  response_type=code|token&
+  client_id=${account.clientId}&
+  connection=CONNECTION&
+  redirect_uri=${account.callback}&
+  state=STATE
+```
+
+You can (optionally) specify a connection, but you must [specify a state](/protocols/oauth2/oauth-state) and choose whether you want a `code` or `token` response (the choice you make depends on your app type and the flow you are using). Finally, make sure to fill in the domain, client ID, and redirect URI if they haven't been pre-filled.
+
+### Using the SPA SDK
+
+If you are already using Auth0's [Single-Page App SDK](/libraries/auth0-spa-js), using the `auth0.loginWithRedirect()` or `auth0.loginWithPopup()` methods will bring you to the authorize endpoint.
+
+```html
+
+```
+
+```js
+$('#login').click(async () => {
+  await auth0.loginWithRedirect();
+});
+```
+
+### Further instructions
+
+<%= include('./_implement_universal_login') %>
diff --git a/ja-jp/articles/universal-login/multifactor-authentication.md b/ja-jp/articles/universal-login/multifactor-authentication.md
new file mode 100644
index 0000000000..f8df08134a
--- /dev/null
+++ b/ja-jp/articles/universal-login/multifactor-authentication.md
@@ -0,0 +1,63 @@
+---
+description: Learn how to customize the MFA page.
+topics:
+  - mfa
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+# Multi-factor Authentication with Classic Universal Login
+
+You can enable [Multi-factor authentication](/mfa) from the [Dashboard > Multifactor Auth](${manage_url}/#/mfa) section.
+
+![Universal Login MFA Page](/media/articles/mfa/mfa-dashboard.png)
+
+You can customize the MFA pages using the Universal Login's [basic customization features](/universal-login#simple-customization). 
+
+If you need further customizations, you can provide your own HTML for the MFA page. 
+
+::: note
+When using your own HTML, it uses the Auth0 MFA Widget, which has the following limitations:
+- It does not support MFA with Email.
+- If users enrolled more than one factor, they cannot select which one to use, the MFA widget will ask them to login with the most secure factor.
+- It does not use Universal Login's [internationalization](/universal-login/i18n) features
+::: 
+
+## Customize the HTML for the MFA page
+
+To customize the MFA page, go to [Dashboard > Universal Login > Guardian Multi-factor](${manage_url}/#/mfa_page) and enable the __Customize Guardian Page__ switch.
+
+Once you do that, you'll be able to use the text editor built into the Auth0 Dashboard to change your HTML, style your page using CSS, and alter the JavaScript used to retrieve custom variables. Once you've made your changes, and make sure to click __Save__.
+
+If you'd like to revert to an earlier design, you have two options:
+
+* Reverting to the last saved template by clicking **Reset to Last**;
+* Reverting to the default template provided by Auth0 by clicking **Reset to Default**.
+
+Please note that MFA page works without customization (Auth0 will also update the included scripts as required). However, once you toggle the customization to **on**, you are responsible for the updating and maintaining the script (including changing version numbers, such as that for the MFA widget), since Auth0 can no longer update it automatically.
+
+For information about how to override the text for many areas of the MFA process on Universal Login Classic Experience, see [MFA Configuration Options](/mfa/references/language-dictionary).
+
+For information about the MFA Widget Theme options, see [MFA Widget Theme Options](/mfa/references/mfa-widget-reference).
+
+## Render "Invited Enrollments" vs. Standard Scenarios
+
+There are two different possible scenarios in which the page is rendered. If a user has been directed to this page specifically for enrollment (for instance, from an email with an enrollment link) then the property **ticket** will be available. Otherwise, the property **requestToken** will be available.
+
+## HTML + Liquid syntax
+
+The hosted page uses [Liquid](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) syntax for templating.
+The following parameters are available to assist in rendering your page:
+
+* `userData.email` 
+* `userData.friendlyUserId`
+* `userData.tenant`
+* `userData.tenantFriendlyName`
+* `iconUrl`
+
+Most of the parameters that are used in the MFA Widget need to be passed to Guardian as shown in the default template provided in the customization area.
+If you need a higher level of customization you could use [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js/tree/master/example).
+
+::: note
+For information about customizing MFA with the New Universal Login Experience, see [Customize Multi-factor Authentication](/mfa/guides/customize-mfa-universal-login).
+:::
diff --git a/ja-jp/articles/universal-login/new-experience-limitations.md b/ja-jp/articles/universal-login/new-experience-limitations.md
new file mode 100644
index 0000000000..1d8ef31edf
--- /dev/null
+++ b/ja-jp/articles/universal-login/new-experience-limitations.md
@@ -0,0 +1,31 @@
+---
+description: New Universal Login Limitations
+topics:
+  - login
+  - universal-login
+contentType: index
+toc: true
+---
+# New Universal Login Experience Limitations
+
+The New Universal Login Experience currently has these limitations:
+
+- You can create [Page Templates](/universal-login/page-templates) to customize the universal login flow UI, but you can't create a completely custom UI. If you want to do that, you need to customize the HTML pages for each prompt (Login / Password Reset / MFA), where by default you will get pages that behave like the Classic Experience. 
+
+- [Identifier-First login](/universal-login/identifier-first) is not available. This would allow users to login with their corporate email addresses and be redirected to their enterprise's login pages. The current implementation will add a button for each enterprise connection. This makes it not suitable for this scenario which is very common for B2B customers.
+
+- [Kerberos](/connector/kerberos) for AD/LDAP connections is not supported. Users will still be able to type their credentials to log in using an AD/LDAP connection, but only if:
+  - the username is in email format.
+  - there are no other database connections enabled.
+
+- The Signup page only lets users enter username / email / password, and does not offer the ability to prompt users to accept terms of service.
+
+- You cannot specify additional fields to have the user fill out in the signup page. Users can only sign up with username, email and password. If you need to capture additional data, you will need to do it after signup, from within your application (such as with [progressive profiling](/users/concepts/overview-progressive-profiling)).
+
+- In order to be able to use [DUO](/mfa/guides/configure-cisco-duo) as an MFA factor, it needs to be the only factor enabled. It will render the same pages as in the Classic Experience.
+
+- [Passwordless login](/connections/passwordless) is not supported.
+
+- [MFA Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket) will keep using the Classic Experience even when the New Experience is enabled.
+
+- When starting password reset by a call to the Management API password change endpoint, the password reset UI doesn't grant the user the option to click a button to redirect after the password change is complete (when using the New Universal Login Experience).
diff --git a/ja-jp/articles/universal-login/new.md b/ja-jp/articles/universal-login/new.md
new file mode 100644
index 0000000000..a49d7e6c84
--- /dev/null
+++ b/ja-jp/articles/universal-login/new.md
@@ -0,0 +1,99 @@
+---
+description: New Universal Login Experience
+topics:
+  - login
+  - universal-login
+contentType: index
+toc: true
+---
+# New Universal Login Experience
+
+Auth0's New Universal Login Experience provides a reimagined login flow, with a fresh UX design and lightweight pages. When you pick this new experience, Auth0 will use it for all pages that haven't been customized. You can enable it from the [Universal Login Settings](${manage_url}/#/login_settings) dashboard section:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+The key structural difference from the [Classic Experience](/universal-login/classic) is that the former uses Javascript widgets in all the pages, while the New Experience is rendered on the server and does not require Javascript. 
+
+From a functional perspective, the New Experience has much better support for [Localization](/universal-login/i18n), consistent UI customization with [Page Templates](/universal-login/page-templates), a better MFA experience, and several improvements across all pages. 
+
+The New Experience is being actively developed, so new features are regularly added. However, there is still a [feature gap](/universal-login/new-experience-limitations) with the Classic Experience, and some pages in the New Experience have certain differences detailed below.
+
+## User Interface Customization
+
+Learn how to [customize](/universal-login/customization-new) the New Universal Login user interface.
+
+## Internationalization
+
+The New Experience provides a consistent approach for [Internationalization](/universal-login/i18n). 
+
+## Text Customization
+
+You can override any text in the New Experience by using the [Text Customization API](/universal-login/text-customization). 
+
+## Login
+
+- If you are using Development Keys for Social Providers:
+
+    - Single Sign-on (SSO) and Silent Authentication will work properly, which does not happen in the Classic Experience.
+
+    - Users will see a warning in the login page mentioning that the tenant is configured with [Development Keys](/connections/social/devkeys).
+
+- A button will be rendered for each social and enterprise connection. 
+
+- A 'show password' icon will be displayed next to the password field.
+
+- If you redirect users to the `/login` page directly, they will get an error unless they have configured the [default login route](/universal-login/default-login-url). You should always redirect users to the proper authorization request endpoint (e.g., `/authorize` if you are using OpenID Connect).
+
+- You can specify the `login_hint` when redirecting to Auth0, and it will be used to populate the username/email field for the login or signup page.
+
+## Signup
+
+- You can make users land directly on the Signup page instead of the Login page by specifying the `screen_hint=signup` parameter when redirecting to `/authorize`. Note that this can be combined with `prompt=login`, which indicates whether you want to always show the authentication page or you want to skip if there's an existing session. 
+
+|`/authorize` parameters | No existing session  | Existing session |
+|--|--|--|
+|no extra parameters   | Shows the login page  | Redirects to the callback url |
+|`screen_hint=signup`  | Shows the signup page | Redirects to the callback url |
+|`prompt=login`        | Shows the login page  | Shows the login page          |
+|`prompt=login&screen_hint=signup`| Shows the signup page | Shows the signup page |
+
+## Multi-Factor Authentication
+
+- If users have more than one multi-factor authentication (MFA) factor enrolled (e.g., SMS and Push notifications), the new MFA page will let the user select which one they want to use.
+
+- You can use [Email as an MFA factor](/mfa/concepts/mfa-factors#email-notifications).
+
+- You can use [Voice as an MFA factor](/mfa/concepts/mfa-factors#voice-notifications).
+
+- If you are using the Guardian SDK to create your own native application to handle Push Notifications, you can configure the name of the application and the URLs to download them in the "Push via Auth0 Guardian" option in the MFA [Dashboard > MFA](${manage_url}/#/mfa) section.
+
+- If you have a rule that sets the MFA provider to `google-authenticator` you need to enable the OTP factor in the [Dashboard > MFA](${manage_url}/#/mfa) section.
+
+## Password Reset
+
+- In the Classic Experience, you can [configure a url](/email/templates#redirect-to-results-for-the-change-password-email-template) to redirect users after completing the password reset. The URL will receive a success indicator and a message. The New Experience will redirect the users to the [default login route](/universal-login/default-login-url) when it succeeds and will handle the error cases as part of the Universal Login flow. The Redirect URL in the email template will be ignored.  
+
+Please note that you must provide an **Application Login URI** under [Application Settings](/dashboard/reference/settings-application) for the redirect URLs to work.
+
+- A 'show password' icon will be displayed next to the password fields.
+
+- If the Database Connection is set to ['Require Username'](/connections/database/require-username), the password reset flow will ask the user for the username and send a password reset email to the associated email address.
+
+## Email Verification
+
+- After a user clicks the email verification link, they'll be redirected to a page that will confirm that their email is verified. If the [default login route](/universal-login/default-login-url) is configured, users will be able to click a button and get redirected to it.
+
+## Consent
+
+- The logo and colors selected in the dashboard configuration section will be properly applied. (Recommended logo size is 150 x 150 pixels.)
+
+## Custom DB Connections
+
+When using [Custom DB Connections](/connections/database/custom-db):
+
+- The password reset flow will function properly even if you return errors from the change password script.
+- The [errors](/connections/database/custom-db/error-handling) returned in `ValidationErrors` or `WrongUsernameOrPasswordError` will be displayed in the corresponding pages.
+
+## Implement Universal Login
+
+<%= include('./_implement_universal_login') %>
diff --git a/ja-jp/articles/universal-login/page-templates.md b/ja-jp/articles/universal-login/page-templates.md
new file mode 100644
index 0000000000..f04413f65a
--- /dev/null
+++ b/ja-jp/articles/universal-login/page-templates.md
@@ -0,0 +1,253 @@
+---
+description: Customizing the New Universal Login Page with Page Templates
+topics:
+  - universal-login
+  - internationalization
+toc: true
+beta: true
+---
+# Customizing the New Universal Login Pages with Pages Templates
+
+You can customize the New Universal Login pages by providing a Page Template using the [Liquid template language](https://shopify.github.io/liquid/). 
+
+::: warning
+This capability can only be used if the tenant has [Custom Domains](/custom-domains) enabled.
+:::
+
+Page Templates let you define the content that is displayed around the Universal Login widgets (e.g. the Login box, the MFA box). The same template is used for all pages, which helps you to implement a consistent login with minimum effort.
+
+The simplest template you can write is:
+
+```html
+
+
+  
+    {%- auth0:head -%}
+  
+  
+    {%- auth0:widget -%}
+  
+
+```
+
+The following tags need to be present in the template:
+
+|||
+|:-----------------|:------------|
+|`auth0:widget`| Includes the HTML for the widget that is displayed in every page (Login, Reset Password, etc.) |
+|`auth0:head`| Includes tags that are required to render the widget |
+
+## Page Templates Variables
+
+The Page Templates have a set of context variables that can be used to impact how the page is rendered. This allows you to implement scenarios like:
+
+* Render different content depending on the Application (for example, you own two brands that need a different page design).
+* Render different content depending on the Prompt (for example, in the Login page you want to add content explaining what the application does, but in the MFA flow, you prefer to only have the MFA box).
+* Add a footer with links to the tenant's support page or email.
+
+### Available Variables
+
+The available variables are:
+
+* The login page [application's settings](/dashboard/reference/settings-application#basic-settings):
+    * application.id
+    * application.name
+    * application.logo_uri
+    * application.metadata
+
+* Universal Login [branding settings](${manage_url}/#/login_settings):
+    * branding.logo_url
+    * branding.colors.primary
+    * branding.colors.page_background
+
+* Tenant's [settings](/dashboard/reference/settings-tenant#basic-settings):
+    * tenant.friendly_name
+    * tenant.support_email
+    * tenant.support_url
+
+* Information about the current universal login screen.
+    * locale: Locale used to render the login pages, matching one of the [supported tenant languages](/universal-login/i18n)
+    * prompt.name: The name of the Universal Login prompt being rendered 
+    * prompt.screen.name: The name of the Universal Login screen being rendered.
+    * prompt.screen.texts: All the [localized texts](/universal-login/text-customization) needed in the screen being rendered.
+  
+  <%= include('text-customization-prompts/_prompt_definition') %>
+
+
+* Information about the current user, for pages rendered after the user authenticates:
+    * user.user_id
+    * user.picture
+    * user.email
+    * user.email_verified
+    * user.app_metadata
+    * user.user_metadata
+    * user.family_name
+    * user.given_name
+    * user.name
+    * user.nickname
+    * user.username
+
+## CSS Customization
+
+Given you can edit the HTML for the Universal Login page, you could also override the CSS classes that are used in the Universal Login widgets. **This is not supported yet**. 
+
+If you override the CSS for our built-in classes, your login page **will break** whenever we change the CSS used in the page. However, certain level of CSS customization will be supported in the future.
+
+## Examples
+
+### Login Box + Image Layout
+
+The following template will show the login box to the left, and an image to the right only for the login / signup pages. The rest of the pages will look like the default ones.
+
+```html
+
+
+  
+    {%- auth0:head -%}
+    
+    {{ prompt.screen.texts.pageTitle }}
+  
+  
+    {% if prompt.name == "login" or prompt.name == "signup" %} 
+        
    
+        {%- auth0:widget -%}
+        
    
+    {% else %}
+        {%- auth0:widget -%}
+    {% endif %}
+  
+
+```
+![Page Templates Layout](/media/articles/universal-login/page-templates-layout.png)
+
+### Page Footers
+
+The example below adds a gray footer with links to Privacy Policy and Terms of Services:
+
+```html
+
+
+  
+    {%- auth0:head -%}
+    
+     {{ prompt.screen.texts.pageTitle }}
+  
+  
+    {%- auth0:widget -%}
+    
+  
+
+```
+
+![Page Templates Footer](/media/articles/universal-login/page-templates-footer.png)
+## Page Templates API
+
+To set the Page Template you need to use the Management API. You first need to get a Management API token with the `update:branding`,`read:branding`, `delete:branding` scopes. If you are using the 'API Explorer Application' to generate tokens, make sure those scopes are enabled for the 'Auth0 Management API'.
+
+To set the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "PUT",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" },
+    { "name": "Content-Type", "value": "text/html" }
+  ],
+  "postData": {
+    "mimeType": "text/html",
+    "text": "{%- auth0:head -%}{%- auth0:widget -%}"
+  }
+}
+```
+
+To retrieve the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+  ]
+}
+```
+
+To delete the template, you need to use the following endpoint:
+
+```har
+{
+  "method": "DELETE",
+  "url": "https://${account.namespace}/api/v2/branding/templates/universal-login",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+  ]
+}
+```
+
+:::note
+The maximum size for the Page Template is 100KB. If that is not big enough, consider moving images/css files outside of the Page Template code.
+:::
+
+## Troubleshooting
+
+If the template is not being applied, check that you are navigating to `/authorize`. When you navigate to `${account.namespace}/authorize` Auth0 will not render the page template.
diff --git a/ja-jp/articles/universal-login/password-reset.md b/ja-jp/articles/universal-login/password-reset.md
new file mode 100644
index 0000000000..965874977c
--- /dev/null
+++ b/ja-jp/articles/universal-login/password-reset.md
@@ -0,0 +1,136 @@
+---
+description: Learn how to customize a hosted password reset page.
+topics:
+  - password-reset
+  - hosted-pages
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Customize Hosted Password Reset Page
+
+::: note
+If you are:
+
+* An administrator trying to reset a user's password, see [Change Users' Passwords](/connections/database/password-change)
+* A user trying to reset your own password, see [Reset Auth0 Account Password](/support/reset-account-password)
+:::
+
+The Password Reset Page provides your applications' users with a way to change their passwords if they can't log in.
+
+With the Password Reset Page, Auth0 handles all required functionality, including:
+
+* Hosting the page itself
+* Redirecting the user wanting to reset their password as necessary (there is no URL to which the user can point their browsers)
+* Ensuring that the user's password meets your stated requirements and is updated accordingly
+* Automatically redirecting the user after they reset their password
+
+The Password Reset Page includes use of the Password Reset Widget. You can, however, [customize the page](/universal-login/customization-classic) to display the personalized information you deem appropriate and to maintain consistency in the appearance of your Auth0 pages (e.g., Login, Password Reset, and MFA).
+
+## Enable Customization of the Password Reset Page
+
+By default, the Password Reset Page is enabled for all Auth0 users. The Password Reset Page **works as is *without* customization**. However, if you want to change the page to match your other pages and present your branding, you can enable customization of the Password Reset Page.
+
+To do so, log in to the [Dashboard](${manage_url}/#/password_reset). Go to **Universal Login** > **Password Reset**. Toggle **Customize Password Reset Page** to enable customization. 
+
+![Hosted Password Reset Page](/media/articles/universal-login/password-reset.png)
+
+## Edit the Password Reset Page
+
+Once you've enabled the customization toggle for the Password Reset Page, you can use the built-in text editor to change its HTML, style the page using CSS, and change the JavaScript used to retrieve and display custom variables. Be sure to **Save** any changes you make.
+
+### Display custom information on the Password Reset Page
+
+You can display personalized information on the Password Reset Page. This is done by editing the embedded JavaScript using the Password Reset Page Editor:
+
+```js
+  
+```
+
+For example, the sample template snippet below shows the variable `tenant.picture_url`. This variable returns the **Logo URL** value defined in [Tenant Settings](${manage_url}/#/tenant).
+
+```js
+  
+```
+
+Auth0 retrieves the logo at the URL and displays it on the Password Reset Widget. If Auth0 can't resolve the URL, it'll display that the default image.
+
+#### Custom variables
+
+The following custom variables can be used to display personalized information on the Password Reset Page:
+
+| Variable | Description |
+| - | - |
+| `email` | The email address of the user requesting the password change | 
+| `ticket` | The ticket representing the given password reset request | 
+| `csrf_token` | Token used to prevent CSRF activity | 
+| `tenant.name` | The name associated with your Auth0 tenant | 
+| `tenant.friendly_name` | The name displayed for your Auth0 tenant | 
+| `tenant.picture_url` | The URL leading to the logo representing you in Auth0 | 
+| `tenant.support_email` | The support email address for your company displayed to your Auth0 users |
+| `tenant.support_url` | The support URL for your company displayed to your Auth0 users | 
+| `lang` | The user's language | 
+| `password_policy` | The active connection's security policy. You can see what this is using `${manage_url}/#/connections/database/con_YOUR-CONNECTION-ID/security`. Be sure to provide your connection ID in the URL.) |
+| `password_complexity_options` | Object containing settings for the password complexity requirements |
+| `min_length` | The minimum length required for newly-created passwords. Can range from 1 to 128 characters in length | 
+
+**Notes:**
+
+* You can set/check the values for your `tenant` variables in the **Settings** area in [Tenant Settings](${manage_url}/#/tenant)
+* You cannot conditionalize customizations based on the Application ID (`client_id`).
+
+## Update the Password Reset Widget
+
+ If you **do not enable customization of the Password Reset Page**, Auth0 will handle updates necessary for the script, including changes to the version number of the included Password Reset Widget.
+
+**Once you have enabled customization of the Password Reset Page, it is your responsibility to update and maintain the script**. This includes updating the version number for the Password Reset Widget. With customization enabled, Auth0 cannot update your script automatically without potentially interfering with changes you've made. 
+
+## Revert your changes
+
+If you'd like to revert the Password Reset Page to an earlier design, you have two options:
+
+* Reverting to the last saved template by clicking **Reset to Last**;
+* Reverting to the default template provided by Auth0 by clicking **Reset to Default**.
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/_prompt_definition.md b/ja-jp/articles/universal-login/text-customization-prompts/_prompt_definition.md
new file mode 100644
index 0000000000..6deafd6d70
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/_prompt_definition.md
@@ -0,0 +1,3 @@
+The term `prompt` is used to refer to a specific step in the login flow. Each `prompt` can have one or more screens. Below is the list of available prompts, and you can find all the screens for each one by following the links:
+
+<%= include('_prompts') %>
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/_prompts.md b/ja-jp/articles/universal-login/text-customization-prompts/_prompts.md
new file mode 100644
index 0000000000..2cb6ef964e
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/_prompts.md
@@ -0,0 +1,24 @@
+- [consent](/universal-login/text-customization-prompts/consent)
+- [device-flow](/universal-login/text-customization-prompts/device-flow)
+- [email-otp-challenge](/universal-login/text-customization-prompts/email-otp-challenge)
+- [email-verification](/universal-login/text-customization-prompts/email-verification)
+- [invitation](/universal-login/text-customization-prompts/invitation)
+- [login](/universal-login/text-customization-prompts/login)
+- [login-email-verification](/universal-login/text-customization-prompts/login-email-verification)
+- [login-id](/universal-login/text-customization-prompts/login-id)
+- [login-password](/universal-login/text-customization-prompts/login-password)
+- [logout](/universal-login/text-customization-prompts/logout)
+- [mfa](/universal-login/text-customization-prompts/mfa)
+- [mfa-email](/universal-login/text-customization-prompts/mfa-email)
+- [mfa-otp](/universal-login/text-customization-prompts/mfa-otp)
+- [mfa-phone](/universal-login/text-customization-prompts/mfa-phone)
+- [mfa-push](/universal-login/text-customization-prompts/mfa-push)
+- [mfa-recovery-code](/universal-login/text-customization-prompts/mfa-recovery-code)
+- [mfa-sms](/universal-login/text-customization-prompts/mfa-sms)
+- [mfa-voice](/universal-login/text-customization-prompts/mfa-voice)
+- [mfa-webauthn](/universal-login/text-customization-prompts/mfa-webauthn)
+- [organizations](/universal-login/text-customization-prompts/organizations)
+- [reset-password](/universal-login/text-customization-prompts/reset-password)
+- [signup](/universal-login/text-customization-prompts/signup)
+- [signup-id](/universal-login/text-customization-prompts/signup-id)
+- [signup-password](/universal-login/text-customization-prompts/signup-password)
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/common.md b/ja-jp/articles/universal-login/text-customization-prompts/common.md
new file mode 100755
index 0000000000..986a88477d
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/common.md
@@ -0,0 +1,13 @@
+# Prompt: common
+
+## Screen: redeem-ticket
+
+
    
+  redeem-ticket reference screenshot
+
    
+
+|Key|Value|
+|----------|----------|
+|pageTitle|Loading...|
+|description|Javascript is not enabled on your browser, please click button to continue.|
+|buttonText|Continue|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/consent.md b/ja-jp/articles/universal-login/text-customization-prompts/consent.md
new file mode 100644
index 0000000000..dd8686c924
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/consent.md
@@ -0,0 +1,22 @@
+# Prompt: consent
+
+## Screen: consent
+
+
    
+  consent reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Authorize <%= "${clientName}" %>|`pageTitle`|
+|Authorize App|`title`|
+|Hi <%= "${userName}" %>,|`pickerTitle`|
+|Tenant and Audience selector|`audiencePickerAltText`|
+|<%= "${clientName}" %> is requesting access to your account.|`messageMultipleTenants`|
+|<%= "${clientName}" %> is requesting access to your <%= "${companyName}" %> account.|`messageSingleTenant`|
+|Accept|`acceptButtonText`|
+|Decline|`declineButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Invalid action|`invalid-action`|
+|Audience is required|`invalid-audience`|
+|Invalid scope, must be an array|`invalid-scope`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/device-flow.md b/ja-jp/articles/universal-login/text-customization-prompts/device-flow.md
new file mode 100644
index 0000000000..47c986c704
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/device-flow.md
@@ -0,0 +1,60 @@
+# Prompt: device-flow
+
+## Screen: device-code-activation
+
+
    
+  device-code-activation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your device code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|Enter the code displayed on your device|`description`|
+|Enter your one-time code|`placeholder`|
+|Device Activation|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Please enter the code displayed on your device|`no-code`|
+|The code you entered is invalid|`invalid-code`|
+
+## Screen: device-code-activation-allowed
+
+
    
+  device-code-activation-allowed reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Login successful | <%= "${clientName}" %>|`pageTitle`|
+|Your device is now connected.|`description`|
+|Congratulations, you're all set!|`eventTitle`|
+
+## Screen: device-code-activation-denied
+
+
    
+  device-code-activation-denied reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Login error | <%= "${clientName}" %>|`pageTitle`|
+|We are not able to activate your device.|`description`|
+|Activation Denied|`eventTitle`|
+
+## Screen: device-code-confirmation
+
+
    
+  device-code-confirmation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Confirm your device code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Please confirm this is the code displayed on your <%= "${clientName}" %>:|`description`|
+|Secure code|`inputCodeLabel`|
+|Device Confirmation|`title`|
+|Confirm|`confirmButtonText`|
+|Cancel|`cancelButtonText`|
+|If you did not initiate this action or you do not recognize this device select cancel.|`confirmationText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/email-otp-challenge.md b/ja-jp/articles/universal-login/text-customization-prompts/email-otp-challenge.md
new file mode 100644
index 0000000000..eed23ea0a6
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/email-otp-challenge.md
@@ -0,0 +1,22 @@
+# Prompt: email-otp-challenge
+
+## Screen: email-otp-challenge
+
+
    
+  email-otp-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|We've sent an email with your code to <%= "${email}" %>|`description`|
+|Enter the code|`placeholder`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Identity|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/email-verification.md b/ja-jp/articles/universal-login/text-customization-prompts/email-verification.md
new file mode 100644
index 0000000000..5be91db924
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/email-verification.md
@@ -0,0 +1,22 @@
+# Prompt: email-verification
+
+## Screen: email-verification-result
+
+
    
+  email-verification-result reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Email verification status | <%= "${clientName}" %>|`pageTitle`|
+|Email Verified|`verifiedTitle`|
+|Error|`errorTitle`|
+|Your email address was successfully verified.|`verifiedDescription`|
+|This account is already verified.|`alreadyVerifiedDescription`|
+|User account does not exist or the verification code is invalid.|`invalidAccountOrCodeDescription`|
+|Your email address could not be verified.|`unknownErrorDescription`|
+|Back to <%= "${clientName}" %>|`buttonText`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/invitation.md b/ja-jp/articles/universal-login/text-customization-prompts/invitation.md
new file mode 100644
index 0000000000..c7f8e2c459
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/invitation.md
@@ -0,0 +1,15 @@
+# Prompt: invitation
+
+## Screen: accept-invitation
+
+
    
+  accept-invitation reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Accept your invitation to sign up | <%= "${clientName}" %>|`pageTitle`|
+|You've Been Invited!|`title`|
+|<%= "${inviterName}" %> has invited you (<%= "${email}" %>) to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`description`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/login-email-verification.md b/ja-jp/articles/universal-login/text-customization-prompts/login-email-verification.md
new file mode 100644
index 0000000000..9df537aa48
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/login-email-verification.md
@@ -0,0 +1,23 @@
+# Prompt: login-email-verification
+
+## Screen: login-email-verification
+
+
    
+  login-email-verification reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|We've sent an email with your code to <%= "${email}" %>|`description`|
+|Enter the code|`placeholder`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Email|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/login-id.md b/ja-jp/articles/universal-login/text-customization-prompts/login-id.md
new file mode 100644
index 0000000000..3b6adb518f
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/login-id.md
@@ -0,0 +1,44 @@
+# Prompt: login-id
+
+## Screen: login-id
+
+
    
+  login-id reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Phone number|`phonePlaceholder`|
+|Edit|`editEmailText`|
+|Alerts|`alertListTitle`|
+|Enter a valid phone number|`error-invalid-phone-number`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|Email does not match any enterprise directory|`no-hrd-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/login-password.md b/ja-jp/articles/universal-login/text-customization-prompts/login-password.md
new file mode 100644
index 0000000000..0f0f999b43
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/login-password.md
@@ -0,0 +1,48 @@
+# Prompt: login-password
+
+## Screen: login-password
+
+
    
+  login-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your password to log in | <%= "${clientName}" %>|`pageTitle`|
+|Enter Your Password|`title`|
+|Enter your password for <%= "${companyName}" %> to continue to <%= "${clientName}" %>|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Forgot password?|`forgotPasswordText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Edit email address|`editLinkScreenReadableText`|
+|Alerts|`alertListTitle`|
+|You've Been Invited!|`invitationTitle`|
+|Log in to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use Fingerprint or Face Recognition|`useBiometricsText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/login.md b/ja-jp/articles/universal-login/text-customization-prompts/login.md
new file mode 100644
index 0000000000..24366e6e9c
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/login.md
@@ -0,0 +1,46 @@
+# Prompt: login
+
+## Screen: login
+
+
    
+  login reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Sign up|`signupActionLinkText`|
+|Don't have an account?|`signupActionText`|
+|Forgot password?|`forgotPasswordText`|
+|Password|`passwordPlaceholder`|
+|Username or email address|`usernamePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Alerts|`alertListTitle`|
+|You've Been Invited!|`invitationTitle`|
+|Log in to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|Wrong username or password|`wrong-credentials`|
+|The code you entered is invalid|`invalid-code`|
+|Invalid or expired user code|`invalid-expired-code`|
+|Email is not valid.|`invalid-email-format`|
+|Wrong email or password|`wrong-email-credentials`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We are sorry, something went wrong when attempting to login|`authentication-failure`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Invalid connection|`no-db-connection`|
+|We have detected a potential security issue with this account. To protect your account, we have prevented this login. Please reset your password to proceed.|`password-breached`|
+|Your account has been blocked after multiple consecutive login attempts.|`user-blocked`|
+|Too many login attempts for this user. Please wait, and try again later.|`same-user-login`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|Username is required|`no-username`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/logout.md b/ja-jp/articles/universal-login/text-customization-prompts/logout.md
new file mode 100644
index 0000000000..462232eba0
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/logout.md
@@ -0,0 +1,17 @@
+# Prompt: logout
+
+## Screen: logout
+
+
    
+  logout reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Logout | <%= "${clientName}" %>|`pageTitle`|
+|Logout|`title`|
+|Hi <%= "${userName}" %>,|`userSalute`|
+|Are you sure you want to log out from <%= "${clientName}" %>?|`description`|
+|Yes|`acceptButtonText`|
+|No|`declineButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-email.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-email.md
new file mode 100644
index 0000000000..99b440c987
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-email.md
@@ -0,0 +1,40 @@
+# Prompt: mfa-email
+
+## Screen: mfa-email-challenge
+
+
    
+  mfa-email-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your email code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Go Back|`backText`|
+|Continue|`buttonText`|
+|We've sent an email with your code to|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive an email?|`resendText`|
+|Verify Your Identity|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|We couldn't send the email. Please try again later.|`mfa-email-challenge-authenticator-error`|
+
+## Screen: mfa-email-list
+
+
    
+  mfa-email-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available email addresses | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Enrolled Email Addresses|`title`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-otp.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-otp.md
new file mode 100644
index 0000000000..737b738045
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-otp.md
@@ -0,0 +1,66 @@
+# Prompt: mfa-otp
+
+## Screen: mfa-otp-enrollment-qr
+
+
    
+  mfa-otp-enrollment-qr reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Scan the code to log in using a one-time password | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Scan the QR Code below using your preferred authenticator app and then enter the provided one-time code below.|`description`|
+|Continue|`buttonText`|
+|Trouble Scanning?|`codeEnrollmentText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Then|`separatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|You are already enrolled on MFA.|`user-already-enrolled`|
+
+## Screen: mfa-otp-enrollment-code
+
+
    
+  mfa-otp-enrollment-code reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Copy the code to log in using a one-time password | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Continue|`buttonText`|
+|Secure code to copy|`altText`|
+|Copy code|`copyCodeButtonText`|
+|Manually enter the following code into your preferred authenticator app and then enter the provided one-time code below.|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Secure Your Account|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+
+## Screen: mfa-otp-challenge
+
+
    
+  mfa-otp-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your one-time password to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Check your preferred one-time password application for a code.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your one-time code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use password|`usePasswordText`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-phone.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-phone.md
new file mode 100644
index 0000000000..43373360ab
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-phone.md
@@ -0,0 +1,57 @@
+# Prompt: mfa-phone
+
+## Screen: mfa-phone-challenge
+
+
    
+  mfa-phone-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use your phone number to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We will send a 6-digit code to the following phone number:|`description`|
+|Continue|`continueButtonText`|
+|Choose another phone number.|`changePhoneText`|
+|Text message|`smsButtonText`|
+|Voice call|`voiceButtonText`|
+|How do you want to receive the code?|`chooseMessageTypeText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|There was a problem making the voice call|`send-voice-failed`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|It seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-phone-enrollment
+
+
    
+  mfa-phone-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a phone code | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your country code and phone number to which we can send a 6-digit code:|`description`|
+|Continue|`continueButtonText`|
+|Text message|`smsButtonText`|
+|Voice call|`voiceButtonText`|
+|How do you want to receive the code?|`chooseMessageTypeText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|There was a problem making the voice call|`send-voice-failed`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|It seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-push.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-push.md
new file mode 100644
index 0000000000..ae05b309d5
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-push.md
@@ -0,0 +1,74 @@
+# Prompt: mfa-push
+
+## Screen: mfa-push-welcome
+
+
    
+  mfa-push-welcome reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Install the application | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|In order to continue, install the <%= "${appName}" %> app via the app store from your mobile device.|`description`|
+|Google Play|`androidButtonText`|
+|Continue|`buttonText`|
+|App Store|`iosButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+
+## Screen: mfa-push-enrollment-qr
+
+
    
+  mfa-push-enrollment-qr reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Scan the code to log in using a push notification | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Scan the QR Code below using the <%= "${appName}" %> app on your mobile device.|`description`|
+|Try another method|`pickAuthenticatorText`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|You must scan the QR code with the <%= "${appName}" %> app on your mobile device.|`enrollment-transaction-pending`|
+
+## Screen: mfa-push-challenge-push
+
+
    
+  mfa-push-challenge-push reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Accept the push notification to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We’ve sent a notification to the following device via the <%= "${appName}" %> app:|`description`|
+|I've responded on my device|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive a notification?|`resendText`|
+|Manually Enter Code|`enterOtpCode`|
+|OR|`separatorText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|You must accept the notification via the <%= "${appName}" %> app on your mobile device.|`challenge-transaction-pending`|
+|We have not received a confirmation, please slow down.|`polling-interval-exceeded`|
+|We have received too many notification requests. Wait a few minutes and try again.|`too-many-push`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|We have not received a confirmation, please try scanning the code again.|`mfa-push-verify-transaction-pending`|
+|We couldn't verify the enrollment. Please try again later.|`mfa-push-verify-authenticator-error`|
+|We couldn't send the notification. Please try again later.|`mfa-push-challenge-authenticator-error`|
+|Notification rejected|`transaction-rejected`|
+
+## Screen: mfa-push-list
+
+
    
+  mfa-push-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available devices | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Registered Devices|`title`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-recovery-code.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-recovery-code.md
new file mode 100644
index 0000000000..48cd305483
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-recovery-code.md
@@ -0,0 +1,41 @@
+# Prompt: mfa-recovery-code
+
+## Screen: mfa-recovery-code-enrollment
+
+
    
+  mfa-recovery-code-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Copy your recovery code for safe keeping | <%= "${clientName}" %>|`pageTitle`|
+|Almost There!|`title`|
+|Copy this recovery code and keep it somewhere safe. You’ll need it if you ever need to log in without your device.|`description`|
+|Secure code to copy|`altText`|
+|Continue|`buttonText`|
+|I have safely recorded this code|`checkboxText`|
+|Copy code|`copyCodeButtonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Please confirm you have recorded the code|`no-confirmation`|
+
+## Screen: mfa-recovery-code-challenge
+
+
    
+  mfa-recovery-code-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your recovery code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Enter the recovery code you were provided during your initial enrollment.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your recovery code|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The code you entered is invalid|`invalid-code`|
+|Recovery code must have 24 alphanumeric characters|`invalid-code-format`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|Please confirm you have recorded the code|`no-confirmation`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-sms.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-sms.md
new file mode 100644
index 0000000000..a5aa3222dd
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-sms.md
@@ -0,0 +1,80 @@
+# Prompt: mfa-sms
+
+## Screen: mfa-country-codes
+
+
    
+  mfa-country-codes reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Select your country code | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Select a Country Code|`title`|
+
+## Screen: mfa-sms-enrollment
+
+
    
+  mfa-sms-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a text message | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your phone number below. An SMS will be sent to that number with a code to enter on the next screen.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|Seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-sms-challenge
+
+
    
+  mfa-sms-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We've sent a text message to:|`description`|
+|Continue|`buttonText`|
+|Edit|`editText`|
+|Edit phone number|`editLinkScreenReadableText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the 6-digit code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Resend|`resendActionText`|
+|Didn't receive a code?|`resendText`|
+|or|`resendVoiceActionSeparatorTextBefore`|
+|get a call|`resendVoiceActionText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|We couldn't send the SMS. Please try again later.|`sms-authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+
+## Screen: mfa-sms-list
+
+
    
+  mfa-sms-list reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of available phone numbers | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Enrolled Phone Numbers|`title`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-voice.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-voice.md
new file mode 100644
index 0000000000..4917d756dc
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-voice.md
@@ -0,0 +1,56 @@
+# Prompt: mfa-voice
+
+## Screen: mfa-voice-enrollment
+
+
    
+  mfa-voice-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone number to log in using a phone code | <%= "${clientName}" %>|`pageTitle`|
+|Secure Your Account|`title`|
+|Enter your phone number below. A voice call will be placed on that number with a code to enter on the next screen.|`description`|
+|Continue|`buttonText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter your phone number|`placeholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|There was a problem sending the SMS|`send-sms-failed`|
+|Phone number can only include digits.|`invalid-phone-format`|
+|Seems that your phone number is not valid. Please check and retry.|`invalid-phone`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-sms`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
+|Please enter a phone number|`no-phone`|
+
+## Screen: mfa-voice-challenge
+
+
    
+  mfa-voice-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your phone code to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|We've sent a 6-digit code via voice phone call to the following phone number:|`description`|
+|Continue|`buttonText`|
+|Edit|`editText`|
+|Edit phone number|`editLinkScreenReadableText`|
+|Choose another phone number.|`changePhoneText`|
+|Try another method|`pickAuthenticatorText`|
+|Enter the 6-digit code|`placeholder`|
+|Remember this device for 30 days|`rememberMeText`|
+|Call again|`resendActionText`|
+|Didn't receive a call?|`resendText`|
+|or|`resendSmsActionSeparatorTextBefore`|
+|send a text|`resendSmsActionText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|OTP Code must have 6 numeric characters|`invalid-otp-code-format`|
+|The code you entered is invalid|`invalid-code`|
+|There was a problem making the voice call|`send-voice-failed`|
+|We couldn't verify the code. Please try again later.|`authenticator-error`|
+|We couldn't make the voice call. Please try again later.|`voice-authenticator-error`|
+|Notification was not sent. Try resending the code.|`no-transaction-in-progress`|
+|Too many failed codes. Wait for some minutes before retrying.|`too-many-failures`|
+|You have exceeded the maximum number of phone messages per hour. Wait a few minutes and try again.|`too-many-voice`|
+|Your enrollment transaction expired, you will need to start again.|`transaction-not-found`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa-webauthn.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa-webauthn.md
new file mode 100644
index 0000000000..d1a5be36e1
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa-webauthn.md
@@ -0,0 +1,153 @@
+# Prompt: mfa-webauthn
+
+## Screen: mfa-webauthn-platform-enrollment
+
+
    
+  mfa-webauthn-platform-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Log in faster on this device | <%= "${clientName}" %>|`pageTitle`|
+|Log In Faster on This Device|`title`|
+|Trust this device? You can quickly and securely log in the next time using this device's fingerprint or face recognition.|`description`|
+|Awaiting device confirmation|`awaitingConfirmation`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Continue|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remind me later|`snoozeEnrollmentButtonText`|
+|Not on this device|`refuseAddingDeviceText`|
+|Not now|`skipAddingDeviceText`|
+|We could not start the device enrollment. Please try again later.|`webauthn-platform-associate-error`|
+
+## Screen: mfa-webauthn-roaming-enrollment
+
+
    
+  mfa-webauthn-roaming-enrollment reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Register your security key | <%= "${clientName}" %>|`pageTitle`|
+|Adding Your Security Key|`title`|
+|Security Keys can be used as an additional authentication factor.|`description`|
+|Awaiting Security Key|`awaitingConfirmation`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use security key|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Connect your Security Key and continue.|`instructions1`|
+|Follow the steps on the browser.|`instructions2`|
+|Name your Security Key to easily identify it later.|`instructions3`|
+|We could not start the security key enrollment. Please try again later.|`webauthn-associate-error`|
+
+## Screen: mfa-webauthn-platform-challenge
+
+
    
+  mfa-webauthn-platform-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use fingerprint or face recognition to login | <%= "${clientName}" %>|`title`|
+|Press the button below and follow your browser's steps to log in.|`description`|
+|Awaiting device confirmation|`awaitingConfirmation`|
+|Too many failed authentication attempts. Please try again later.|`too-many-webauthn-challenge-attempts-error`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Continue|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Use password|`usePasswordText`|
+|Remember this device for 30 days|`rememberMeText`|
+|We could not start the device verification. Please try again later.|`webauthn-platform-challenge-error`|
+
+## Screen: mfa-webauthn-roaming-challenge
+
+
    
+  mfa-webauthn-roaming-challenge reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Use your security key to log in | <%= "${clientName}" %>|`pageTitle`|
+|Verify Your Identity|`title`|
+|Make sure your Security Key is nearby. Once you continue, you will be prompted to use it.|`description`|
+|Awaiting Security Key|`awaitingConfirmation`|
+|Too many failed authentication attempts. Please try again later.|`too-many-webauthn-challenge-attempts-error`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Use security key|`continueButtonText`|
+|Try another method|`pickAuthenticatorText`|
+|Remember this device for 30 days|`rememberMeText`|
+|We could not start the security key verification. Please try again later.|`webauthn-challenge-error`|
+
+## Screen: mfa-webauthn-change-key-nickname
+
+
    
+  mfa-webauthn-change-key-nickname reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Name your security key | <%= "${clientName}" %>|`title`|
+|If you own multiple keys, this alias will help you identify the right one.|`description`|
+|<%= "${userName}" %>'s key|`nickname`|
+|Security key name|`nicknamePlaceholder`|
+|Name your device | <%= "${clientName}" %>|`titlePlatform`|
+|If you own multiple devices, this alias will help you identify the right one.|`descriptionPlatform`|
+|<%= "${userName}" %>'s <%= "${deviceName}" %>|`nicknamePlatform`|
+|Device name|`nicknamePlaceholderPlatform`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|We could not update your key's name. Please try again.|`webauthn-patch-nickname-error`|
+|We could not update your Device's name. Please try again.|`webauthn-platform-patch-nickname-error`|
+|Name is required|`no-nickname`|
+|Name is too short|`nickname-too-short`|
+|Name is too long|`nickname-too-long`|
+|An error occurred while retrieving your information. Please try again.|`error-while-retrieving-authenticator`|
+|An error occurred while trying to save the name . Please try again.|`error-while-patching`|
+
+## Screen: mfa-webauthn-enrollment-success
+
+
    
+  mfa-webauthn-enrollment-success reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Security key successful | <%= "${clientName}" %>|`title`|
+|Device registration successful | <%= "${clientName}" %>|`titlePlatform`|
+|You have successfully registered your Security Key.|`description`|
+|You have successfully registered your device.|`descriptionPlatform`|
+|Continue|`buttonText`|
+|<%= "${companyName}" %>|`logoAltText`|
+
+## Screen: mfa-webauthn-error
+
+
    
+  mfa-webauthn-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Try again|`tryAgainLinkText`|
+|Try another method|`pickAuthenticatorText`|
+|Security key registration error | <%= "${clientName}" %>|`errorTitle`|
+|Security Key Verification Failed|`errorTitleChallenge`|
+|Device registration error | <%= "${clientName}" %>|`errorTitlePlatform`|
+|Something Went Wrong|`errorTitlePlatformChallenge`|
+|Something went wrong. Please try again or try using another method.|`description`|
+|If you already registered this device, please try again. If not, try using another method.|`descriptionPlatform`|
+|No Thanks|`refuseAddingAuthenticatorText`|
+|Use password|`usePasswordText`|
+
+## Screen: mfa-webauthn-not-available-error
+
+
    
+  mfa-webauthn-not-available-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Security keys are not supported | <%= "${clientName}" %>|`pageTitle`|
+|Security Keys Are Not Supported|`errorTitle`|
+|We are sorry but your browser or device does not support Security Keys. Try using another browser or log in from another device.|`errorDescription`|
+|Try another method|`pickAuthenticatorText`|
+|Use password|`usePasswordText`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/mfa.md b/ja-jp/articles/universal-login/text-customization-prompts/mfa.md
new file mode 100644
index 0000000000..283fa545a0
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/mfa.md
@@ -0,0 +1,80 @@
+# Prompt: mfa
+
+## Screen: mfa-detect-browser-capabilities
+
+
    
+  mfa-detect-browser-capabilities reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Try another method|`pickAuthenticatorText`|
+|Reload|`reloadButtonText`|
+|JavaScript Required|`noJSErrorTitle`|
+|Your browser does not have JavaScript enabled. Please enable and press the Reload page button.|`noJSErrorDescription`|
+
+## Screen: mfa-enroll-result
+
+
    
+  mfa-enroll-result reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|MFA enrollment status|`pageTitle`|
+|You're All Set!|`enrolledTitle`|
+|You have successfully added a new authentication factor.|`enrolledDescription`|
+|Invalid Link|`invalidTicketTitle`|
+|This link is invalid or expired.|`invalidTicketDescription`|
+|Expired Link|`expiredTicketTitle`|
+|This link is expired.|`expiredTicketDescription`|
+|Already used|`alreadyUsedTitle`|
+|This link has already been used. Please get a new link to enroll with Multi-factor Authentication.|`alreadyUsedDescription`|
+|Two-factor Verification has Already Been Enabled.|`alreadyEnrolledDescription`|
+|Something Went Wrong|`genericError`|
+
+## Screen: mfa-login-options
+
+
    
+  mfa-login-options reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|List of other login methods | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Other Methods|`title`|
+|SMS|`authenticatorNamesSMS`|
+|Phone|`authenticatorNamesVoice`|
+|Phone|`authenticatorNamesPhone`|
+|Notification via <%= "${appName}" %> app|`authenticatorNamesPushNotification`|
+|Google Authenticator or similar|`authenticatorNamesOTP`|
+|Email|`authenticatorNamesEmail`|
+|Recovery code|`authenticatorNamesRecoveryCode`|
+|Notification via DUO app|`authenticatorNamesDUO`|
+|Security Key|`authenticatorNamesWebauthnRoaming`|
+|Fingerprint or Face Recognition|`authenticatorNamesWebauthnPlatform`|
+
+## Screen: mfa-begin-enroll-options
+
+
    
+  mfa-begin-enroll-options reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Add another authentication method | <%= "${clientName}" %>|`pageTitle`|
+|Go back|`backText`|
+|Keep Your Account Safe|`title`|
+|Add another authentication method.|`description`|
+|<%= "${companyName}" %>|`logoAltText`|
+|SMS|`authenticatorNamesSMS`|
+|Phone|`authenticatorNamesVoice`|
+|Phone|`authenticatorNamesPhone`|
+|Notification via <%= "${appName}" %> app|`authenticatorNamesPushNotification`|
+|Google Authenticator or similar|`authenticatorNamesOTP`|
+|Email|`authenticatorNamesEmail`|
+|Recovery code|`authenticatorNamesRecoveryCode`|
+|Notification via DUO app|`authenticatorNamesDUO`|
+|Security Key|`authenticatorNamesWebauthnRoaming`|
+|Fingerprint or Face Recognition|`authenticatorNamesWebauthnPlatform`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/organizations.md b/ja-jp/articles/universal-login/text-customization-prompts/organizations.md
new file mode 100644
index 0000000000..0cf5837020
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/organizations.md
@@ -0,0 +1,17 @@
+# Prompt: organizations
+
+## Screen: organization-selection
+
+
    
+  organization-selection reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Enter your organization | <%= "${clientName}" %>|`pageTitle`|
+|Continue|`buttonText`|
+|Enter your <%= "${companyName}" %> Organization Name to continue|`description`|
+|Enter your Organization Name|`placeholder`|
+|Enter Organization|`title`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The organization you entered is invalid|`invalid-organization`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/reset-password.md b/ja-jp/articles/universal-login/text-customization-prompts/reset-password.md
new file mode 100644
index 0000000000..dcb8debd5c
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/reset-password.md
@@ -0,0 +1,103 @@
+# Prompt: reset-password
+
+## Screen: reset-password-request
+
+
    
+  reset-password-request reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Reset your password | <%= "${clientName}" %>|`pageTitle`|
+|Forgot Your Password?|`title`|
+|Back to <%= "${clientName}" %>|`backToLoginLinkText`|
+|Continue|`buttonText`|
+|Enter your email address and we will send you instructions to reset your password.|`descriptionEmail`|
+|Enter your username and we will send you instructions to reset your password.|`descriptionUsername`|
+|Email address|`placeholderEmail`|
+|Username|`placeholderUsername`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Email is not valid.|`invalid-email-format`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We had a problem sending the email, please try again later.|`reset-password-error`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-email`|
+|You have exceeded the amount of emails. Wait a few minutes and try again.|`too-many-requests`|
+|Please enter an email address|`no-email`|
+|Username is required|`no-username`|
+
+## Screen: reset-password-email
+
+
    
+  reset-password-email reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Check your email | <%= "${clientName}" %>|`pageTitle`|
+|Check Your Email|`title`|
+|Please check the email address <%= "${email}" %> for instructions to reset your password.|`emailDescription`|
+|Resend email|`resendLinkText`|
+|Please check the email address associated with the username <%= "${email}" %> for instructions to reset your password.|`usernameDescription`|
+
+## Screen: reset-password
+
+
    
+  reset-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Reset your password | <%= "${clientName}" %>|`pageTitle`|
+|Change Your Password|`title`|
+|Enter a new password below to change your password.|`description`|
+|Reset password|`buttonText`|
+|New password|`passwordPlaceholder`|
+|Re-enter new password|`reEnterpasswordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Password contains user information|`password-contains-user-information`|
+
+## Screen: reset-password-success
+
+
    
+  reset-password-success reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Password reset successful | <%= "${clientName}" %>|`pageTitle`|
+|Password Changed!|`eventTitle`|
+|Your password has been changed successfully.|`description`|
+|Back to <%= "${clientName}" %>|`buttonText`|
+
+## Screen: reset-password-error
+
+
    
+  reset-password-error reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Password reset error | <%= "${clientName}" %>|`pageTitle`|
+|Back to <%= "${clientName}" %>|`backToLoginLinkText`|
+|To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionExpired`|
+|To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionGeneric`|
+|This link has already been used. To reset your password, return to the login page and select "Forgot Your Password" to send a new email.|`descriptionUsed`|
+|Link Expired|`eventTitleExpired`|
+|Invalid Link|`eventTitleGeneric`|
+|Invalid Link|`eventTitleUsed`|
+|This ticket was expired.|`auth0-users-expired-ticket`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|This ticket was already used.|`auth0-users-used-ticket`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|We had a problem sending the email, please try again later.|`reset-password-error`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/signup-id.md b/ja-jp/articles/universal-login/text-customization-prompts/signup-id.md
new file mode 100644
index 0000000000..e7d89bd0c8
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/signup-id.md
@@ -0,0 +1,49 @@
+# Prompt: signup-id
+
+## Screen: signup-id
+
+
    
+  signup-id reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Sign up | <%= "${clientName}" %>|`pageTitle`|
+|Create Your Account|`title`|
+|Sign Up to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Phone number|`phonePlaceholder`|
+|Email address|`emailPlaceholder`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|Enter a valid phone number|`error-invalid-phone-number`|
+|<%= "${companyName}" %>|`logoAltText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Email does not match any enterprise directory|`no-hrd-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/signup-password.md b/ja-jp/articles/universal-login/text-customization-prompts/signup-password.md
new file mode 100644
index 0000000000..50e26d2102
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/signup-password.md
@@ -0,0 +1,54 @@
+# Prompt: signup-password
+
+## Screen: signup-password
+
+
    
+  signup-password reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Create a password to sign up | <%= "${clientName}" %>|`pageTitle`|
+|Create Your Account|`title`|
+|Set your password for <%= "${companyName}" %> to continue to <%= "${clientName}" %>|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Email address|`emailPlaceholder`|
+|Edit|`editEmailText`|
+|Edit email address|`editLinkScreenReadableText`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|Accept your invitation to sign up | <%= "${clientName}" %>|`invitationTitle`|
+|Sign Up to accept <%= "${inviterName}" %>'s invitation to join <%= "${companyName}" %> on <%= "${clientName}" %>.|`invitationDescription`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Password contains user information|`password-contains-user-information`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
+|This combination of credentials was detected in a public data breach on another website. Before your account is created, please use a different password to keep it secure.|`password-breached`|
diff --git a/ja-jp/articles/universal-login/text-customization-prompts/signup.md b/ja-jp/articles/universal-login/text-customization-prompts/signup.md
new file mode 100644
index 0000000000..137e38141f
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization-prompts/signup.md
@@ -0,0 +1,50 @@
+# Prompt: signup
+
+## Screen: signup
+
+
    
+  signup reference screenshot
+
    
+
+|Text|Key|
+|----------|----------|
+|Sign up | <%= "${clientName}" %>|`pageTitle`|
+|Welcome|`title`|
+|Sign Up to <%= "${companyName}" %> to continue to <%= "${clientName}" %>.|`description`|
+|Or|`separatorText`|
+|Continue|`buttonText`|
+|Email address|`emailPlaceholder`|
+|Continue with <%= "${connectionName}" %>|`federatedConnectionButtonText`|
+|Log in|`loginActionLinkText`|
+|Already have an account?|`loginActionText`|
+|Password|`passwordPlaceholder`|
+|Your password must contain:|`passwordSecurityText`|
+|Username|`usernamePlaceholder`|
+|<%= "${companyName}" %>|`logoAltText`|
+|Show password|`showPasswordText`|
+|Hide password|`hidePasswordText`|
+|The user already exists.|`email-in-use`|
+|Email is not valid.|`invalid-email-format`|
+|The password is too weak|`password-too-weak`|
+|The password is too weak|`password-policy-not-conformant`|
+|The password is too common|`password-too-common`|
+|Password has previously been used|`password-previously-used`|
+|Passwords don't match|`password-mismatch`|
+|Password contains user information|`password-contains-user-information`|
+|Username can only contain alphanumeric characters or: '<%= "${characters}" %>'. Username should have between <%= "${min}" %> and <%= "${max}" %> characters.|`invalid-username`|
+|The username must not be longer than <%= "${max}" %> characters.|`invalid-username-max-length`|
+|The username must have at least <%= "${min}" %> characters.|`invalid-username-min-length`|
+|The username has invalid characters.|`invalid-username-invalid-characters`|
+|The username cannot be an email.|`invalid-username-email-not-allowed`|
+|The username provided is in use already.|`username-taken`|
+|Something went wrong, please try again later.|`custom-script-error-code`|
+|Something went wrong, please try again later|`auth0-users-validation`|
+|Invalid connection|`invalid-connection`|
+|We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|`ip-blocked`|
+|Too many signups from the same IP|`ip-signup-blocked`|
+|Invalid connection|`no-db-connection`|
+|Please enter an email address|`no-email`|
+|Password is required|`no-password`|
+|New password confirmation is missing|`no-re-enter-password`|
+|Username is required|`no-username`|
+|This combination of credentials was detected in a public data breach on another website. Before your account is created, please use a different password to keep it secure.|`password-breached`|
diff --git a/ja-jp/articles/universal-login/text-customization.md b/ja-jp/articles/universal-login/text-customization.md
new file mode 100644
index 0000000000..eddd3e613f
--- /dev/null
+++ b/ja-jp/articles/universal-login/text-customization.md
@@ -0,0 +1,107 @@
+---
+description: Text Customization for the New Universal Login Experience
+topics:
+  - universal-login
+  - localization
+contentType: how-to
+toc: true
+useCase: customize-hosted-pages
+---
+# Text Customization for the New Universal Login Experience
+
+The New Universal Login Experience consists of a set of pages that perform several account-related actions such as logging in, enrolling multi-factor authentication factors, or changing their password. The text displayed on those pages is provided by Auth0 in several languages. 
+
+In some cases you might wish to modify the wording on these pages to better match your application's tone or specific needs.
+
+Auth0 provides an API that you can use to customize all the text displayed in the [New Universal Login Experience](/universal-login/new) for every [supported language](/universal-login/i18n).
+
+The API is defined with the following structure:
+
+```
+PUT '/api/v2/prompts/PROMPT/custom-text/LANGUAGE',
+{
+ "SCREEN1": {
+   "TEXT1_ID": "text1 in language"
+ },
+ "SCREEN2": {
+   "TEXT2_ID": "text2 in language"
+ }
+}
+ ```
+ 
+You need to provide the proper values to the `prompt`, `language`, `screen`, `text id` fields.
+
+You can find the list of available languages on the [Universal Login Internationalization page](/universal-login/i18n).
+
+<%= include('text-customization-prompts/_prompt_definition') %>
+
+Each screen has a set of `text id`s, which are listed in the documentation for each prompt linked above.
+
+## Available variables 
+
+Some screens have variables in the text that are replaced in runtime based on context information. The available variables are different per-screen, so it is not guaranteed that they will work anywhere other than the screens they originally appear in. 
+
+| Variable | Description |
+| ------------- |-------------| 
+| <%= "${clientName}" %>| Auth0 Application Name | 
+| <%= "${connectionName}" %> | Connection Name (e.g. 'Google')
+| <%= "${companyName}" %>| Auth0 Tenant name| 
+| <%= "${userName}" %>| Name of the logged user| 
+| <%= "${email}" %> | Email of the logged user| 
+| <%= "${appName}" %>| Name of the custom Guardian Push application | 
+
+## Calling the API
+
+You can use the GET and PUT HTTP verbs when calling the API. Note that PUT will replace all customizations for specific prompts with the new ones. If you customized one screen and then want to customize another one, you will need to send both when updating the prompt's text.
+
+To call the API you need an Access Token that has the `read:prompts` and `update:prompts` scopes. If you are using the API Explorer Machine to Machine application, make sure the scopes are selected.
+
+### Examples
+
+If you want to change the **description** field for the `login` prompt so that it does not say "Log in to <%= "${companyName}" %> to continue to <%= "${clientName}" %>" you can do it with the following  API call:
+
+```har
+{
+	"method": "PUT",
+	"url": "https://${account.namespace}/api/v2/prompts/login/custom-text/en",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": 
+	[
+	    { "name": "Content-Type", "value": "application/json" },
+		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	],
+	"queryString": [],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"login\": { \"description\": \"Login to ACME's Website\" } }"
+	},
+	"headersSize": -1,
+	"bodySize": -1,
+	"comment": ""
+}
+```
+
+If you want to delete all custom text for the `login` prompt you can send an empty array:
+
+```har
+{
+	"method": "PUT",
+	"url": "https://${account.namespace}/api/v2/prompts/login/custom-text/en",
+	"httpVersion": "HTTP/1.1",
+	"cookies": [],
+	"headers": 
+	[
+	    { "name": "Content-Type", "value": "application/json" },
+		{ "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+	],
+	"queryString": [],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ }"
+	},
+	"headersSize": -1,
+	"bodySize": -1,
+	"comment": ""
+}
+```
diff --git a/ja-jp/articles/universal-login/version-control.md b/ja-jp/articles/universal-login/version-control.md
new file mode 100644
index 0000000000..571f0310dc
--- /dev/null
+++ b/ja-jp/articles/universal-login/version-control.md
@@ -0,0 +1,38 @@
+---
+description: Learn how to back up your Universal Login pages using the Auth0 version control extensions
+topics:
+  - version-control
+  - hosted-pages
+contentType: how-to
+useCase: customize-hosted-pages
+---
+# How to Use Version Control to Manage Your Universal Login Pages
+
+You can use version control software to manage the source code of your pages.
+To do so, you can use the Auth0-provided extension that works with the version control system you're using:
+
+* [GitLab Extension](/extensions/gitlab-deploy#deploy-hosted-pages)
+* [GitHub Extension](/extensions/github-deploy#deploy-hosted-pages)
+* [BitBucket Extension](/extensions/bitbucket-deploy#deploy-hosted-pages)
+* [Visual Studio Team Services Extension](/extensions/visual-studio-team-services-deploy#deploy-hosted-pages)
+
+While the specific documentation pages contain detailed information for the extensions, the general deploying process requires just the following steps:
+
+1. Create a folder in your version control repository with the appropriate name (`pages`).
+2. Create an HTML page (`login.html`, `password_reset.html`, `guardian_multifactor.html`, or `error_page.html`) within your folder.
+3. Create a JSON file with the same name as your HTML page for each hosted page that you wish to source control. To enable the page, the JSON file needs to contain the following:
+
+```json
+{
+  "enabled": true
+}
+```
+
+
+### File Naming Example
+
+
+```text
+your-repo/pages/error_page.html
+your-repo/pages/error_page.json
+```
diff --git a/ja-jp/articles/users/_includes/_account-linking-id-tokens.md b/ja-jp/articles/users/_includes/_account-linking-id-tokens.md
new file mode 100644
index 0000000000..a0f35dedb5
--- /dev/null
+++ b/ja-jp/articles/users/_includes/_account-linking-id-tokens.md
@@ -0,0 +1,3 @@
+::: panel Account Linking ID Token Usage Deprecated
+Previously, in some cases, you could use [ID Tokens](/tokens/concepts/id-tokens) to link and unlink user accounts. This functionality is being deprecated. You will have to use Access Tokens in all cases. The change in the unlinking of accounts is that you can no longer use an ID Token in the `Authorization` header. An Access Token must be used instead. The functionality is still available but not recommended and affected users are encouraged to migrate. See [Migration Guide: Account Linking with Access Tokens vs. ID Tokens](/migrations/guides/account-linking) for details.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/users/_includes/_connection-synch-note.md b/ja-jp/articles/users/_includes/_connection-synch-note.md
new file mode 100644
index 0000000000..a9f14724eb
--- /dev/null
+++ b/ja-jp/articles/users/_includes/_connection-synch-note.md
@@ -0,0 +1,3 @@
+::: note
+Rather than storing profile-related information in `user_metadata`, you can edit these user attributes on the normalized user profile. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/users/_includes/_password-encoding-description.md b/ja-jp/articles/users/_includes/_password-encoding-description.md
new file mode 100644
index 0000000000..0031b41049
--- /dev/null
+++ b/ja-jp/articles/users/_includes/_password-encoding-description.md
@@ -0,0 +1,20 @@
+The encoding of the password used to generate the hash. Must be one of:
+
+* `ascii`
+* `utf8`
+* `utf16le`
+* `ucs2`
+* `latin1`
+* `binary`
+
+On login, the user-provided password will be transcoded from `password.encoding` before being checked against the provided hash.
+
+For example; if your hash was generated from a `ucs2` encoded string, then you would set:
+
+```json
+{
+  "password": {
+    "encoding": "ucs2"
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/users/_includes/_user-prop-identities.md b/ja-jp/articles/users/_includes/_user-prop-identities.md
new file mode 100644
index 0000000000..cbd83244dd
--- /dev/null
+++ b/ja-jp/articles/users/_includes/_user-prop-identities.md
@@ -0,0 +1,9 @@
+Contains info retrieved from the identity provider with which the user originally authenticates. Users may also [link their profile to multiple identity providers](/users/concepts/overview-user-account-linking); those identities will then also appear in this array. The contents of an individual identity provider object varies by provider, but it will typically include the following:
+
+- `connection` (text): Name of the Auth0 connection used to authenticate the user.
+- `isSocial` (boolean): Indicates whether the connection is a social one.
+- `provider` (text): Name of the entity that is authenticating the user, such as Facebook, Google, SAML, or your own provider.
+- `user_id` (text): User's unique identifier for this connection/provider.
+- `profileData` (object): User info associated with the connection. When profiles are linked, it is populated with the associated user info for secondary accounts.
+
+In some cases, it will also include an API Access Token to be used with the provider. 
\ No newline at end of file
diff --git a/ja-jp/articles/users/concepts/overview-progressive-profiling.md b/ja-jp/articles/users/concepts/overview-progressive-profiling.md
new file mode 100644
index 0000000000..b6595ba26b
--- /dev/null
+++ b/ja-jp/articles/users/concepts/overview-progressive-profiling.md
@@ -0,0 +1,55 @@
+---
+description: Understand how progressive profiling can gather more information about your users over time as they engage with your website or application thereby enhancing their experience by not asking them too many questions up front.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - progressive-profiling
+contentType: concept
+useCase: manage-users
+v2: true
+---
+# Progressive Profiling
+
+Progressive profiling is the act of collecting more information about your users over time as they engage with your website or application. This way, you can gather just the right amount of information at just the right time and enhance your users' experience by not asking them too many questions at signup. For example, you might collect just the user's name, email, and password on initial signup. At the next login, you might ask for the name of their company and their title or their birth date. When asking users for additional information, avoid asking for information that you may already have. For example, if a user signs up using a social network you may already have some of the information you need. 
+
+Progressive profiling provides the following benefits:
+
+* Shorter registration forms
+* Higher conversion rates
+* Collecting more relevant information about your users
+* Enhancing the user experience by avoiding repetitious questions
+
+::: note
+Users logging in with social networks will typically **consent** to disclose their information.
+:::
+
+## How progressive profiling works with Auth0
+
+Every time a user authenticates through Auth0, Auth0 updates their user profile and with data that can come from different sources:
+
+* Properties supplied by the identity provider (such as LinkedIn, Facebook, or any [connection](/identityproviders)).
+* Attributes that are dynamically created in [Auth0 Rules](/rules) .
+* Attributes obtained by calling APIs such as [FullContact](https://www.fullcontact.com/) and [Clearbit](https://clearbit.com/).
+* Application-specific attributes that developers can collect in their apps and save. In Auth0, this information is called **user metadata**.
+
+![Progressive Profiling](/media/articles/user-profile/progressive-profiling.png)
+
+The first source is generally not directly related to **progressive profiling** however it can supply some user information. 
+
+You can use redirect Rules to collect more information than was given at initial signup like the user's birthday. For an example of how to create rules to implement progressive profiling, see [Progressive Profiling example](/rules/guides/redirect#progressive-profiling-example).
+
+You can use the Auth0 [Users API](/api/v2#!/Users/patch_users_by_id) to augment the profile of any authenticated user with any information. Auth0 metadata objects can contain any serializable data structure. Auth0 provides two [metadata](/users/concepts/overview-user-metadata) attributes: **user metadata** and **app metadata**. You can update the contents of your metadata fields with the [Management APIv2](/api/management/v2). It is up to you what information to collect, when to collect it, and how to collect it. Each application implements progressive profiling differently. Your application may already do so, in fact. 
+
+The use of progressive profiling within your application makes it very easy to control what information gets collected and when. As this happens, you can enrich the user profile with the data you've collected:
+
+![Progressive profiling example](/media/articles/user-profile/progressive-profiling-example.png)
+
+In the example above, the application collects **last name** and **first name** on signup. It then collects the user's **title** and **company** at a later point. Finally, in the context of an article that might interest the user, the app adds information to the **subscribed** property. 
+
+## Keep reading
+
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Redirect Users From Within Rules](/rules/guides/redirect)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
+
diff --git a/ja-jp/articles/users/concepts/overview-user-account-linking.md b/ja-jp/articles/users/concepts/overview-user-account-linking.md
new file mode 100644
index 0000000000..d872887ad9
--- /dev/null
+++ b/ja-jp/articles/users/concepts/overview-user-account-linking.md
@@ -0,0 +1,204 @@
+---
+title: User Account Linking
+description: Understand how user accounts can be linked in Auth0 from various identity providers.
+crews: crew-2
+toc: true
+topics:
+  - account-linking
+contentType:
+  - concept
+useCase:
+  - manage-accounts
+---
+# User Account Linking
+
+Auth0 supports the linking of user accounts from various identity providers. This allows a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. This feature requires a paid subscription to the **Developer**, **Developer Pro** or **Enterprise** plan (see [Pricing](https://auth0.com/pricing)).
+
+Auth0 treats all identities as separate by default. For example, if a user logs in first against the Auth0 database and then via Google or Facebook, these two attempts would appear to Auth0 as two separate users. You can implement functionality to enable a user to explicitly link accounts. In this scenario, the user would log in with an initial provider, perhaps Google. Your application would provide a link or button to enable them to link another account to the first one.  The user would click on this link/button and your application would make a call so that when the user logs in with the second provider, the second account is linked with the first.
+
+## Advantages of linking accounts
+
+* Allows users to log in with any identity provider without creating a separate profile for each
+* Allows registered users to use a new social or passwordless login but continue using their existing profile
+* Allows users that registered using a passwordless login to link to an account with a more complete profile
+* Allows your apps to retrieve user profile data stored in various connections
+
+## How it works
+
+The process of linking accounts merges two existing user profiles into a single one. When linking accounts, a **primary account** and a **secondary account** must be specified.
+
+In the example below you can see how the resulting linked profile will be for the sample primary and secondary accounts.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+      
    +        {
+  "email": "your0@email.com",
+  "email_verified": true,
+  "name": "John Doe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "picture": "https://lh3.googleusercontent..../photo.jpg",
+  "gender": "male",
+  "locale": "en",
+  "user_id": "google-oauth2|115015401343387192604",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "115015401343387192604",
+      "connection": "google-oauth2",
+      "isSocial": true
+    }
+  ],
+  "user_metadata": {
+    "color": "red"
+  },
+  "app_metadata": {
+    "roles": [
+      "Admin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+    
    
+      
    +        {
+  "phone_number": "+14258831929",
+  "phone_verified": true,
+  "name": "+14258831929",
+  "updated_at": "2015-10-08T18:35:18.102Z",
+  "user_id": "sms|560ebaeef609ee1adaa7c551",
+  "identities": [
+    {
+      "user_id": "560ebaeef609ee1adaa7c551",
+      "provider": "sms",
+      "connection": "sms",
+      "isSocial": false
+    }
+  ],
+  "user_metadata": {
+    "color": "blue"
+  },
+  "app_metadata": {
+    "roles": [
+      "AppAdmin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+    
    
+      
    +        {
+  "email": "your0@email.com",
+  "email_verified": true,
+  "name": "John Doe",
+  "given_name": "John",
+  "family_name": "Doe",
+  "picture": "https://lh3.googleusercontent..../photo.jpg",
+  "gender": "male",
+  "locale": "en",
+  "user_id": "google-oauth2|115015401343387192604",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "115015401343387192604",
+      "connection": "google-oauth2",
+      "isSocial": true
+    },
+    {
+      "profileData": {
+        "phone_number": "+14258831929",
+        "phone_verified": true,
+        "name": "+14258831929"
+      },
+      "user_id": "560ebaeef609ee1adaa7c551",
+      "provider": "sms",
+      "connection": "sms",
+      "isSocial": false
+    }
+  ],
+  "user_metadata": {
+    "color": "red"
+  },
+  "app_metadata": {
+    "roles": [
+      "Admin"
+    ]
+  },
+  ...
+}
+        
+      
    
+    
    
+  
    
+
    
+
+Note that:
+
+* The `user_id` and all other main profile properties continue to be those of the primary identity
+* The secondary account is now embedded in the `identities` array of the primary profile
+* The attributes of the secondary account are placed inside the `profileData` field of the corresponding identity inside the array
+* The `user_metadata` and `app_metadata` of the primary account have not changed
+* The `user_metadata` and `app_metadata` of the secondary account are discarded
+* There is no automatic merging of user profiles with associated identities
+* The secondary account is removed from the users list
+
+### Metadata merge
+
+[Metadata](/users/concepts/overview-user-metadata) are not automatically merged during account linking. If you want to merge them you have to do it manually, using the [Auth0 APIv2 Update User endpoint](/api/v2#!/Users/patch_users_by_id).
+
+The [Auth0 Node.js SDK for APIv2](https://github.com/auth0/node-auth0/tree/v2) is also available. 
+
+## Scenarios
+
+There are two different ways of implementing account linking:
+
+* [User-initiated account linking](#user-initiated-account-linking): allow your users to link their accounts using an admin screen in your app.
+* [Suggested account linking](#suggested-account-linking): identify accounts with the same email address and prompt the user in your app to link them.
+
+### User-initiated account linking
+
+Typically, account linking will be initiated by an authenticated user. Your app must provide the UI, such as a **Link accounts** button on the user's profile page.
+
+![Sample user profile page](/media/articles/link-accounts/spa-user-settings.png)
+
+You can read more about how to implement user-initiated account linking in a Single Page Application in the [Client-Side Account Linking](/users/references/link-accounts-client-side-scenario) article.
+
+### Suggested account linking
+
+You can find accounts with the same email, and prompt the users to link them. For example, a user can create an account with Google with the user@gmail.com, and then log in with Facebook, with an account linked to the same email. 
+
+If that occurs, you can show users the list of available accounts so they can link them, by first authenticating with the account they will be linking to.
+
+You can also use the [Account Link Extension](/extensions/account-link) to achieve the same outcome. 
+
+![Suggested Account Linking](/media/articles/link-accounts/account-linking-webapp-small.png)
+
+You can read more about how to implement user-initiated account linking in a Regular Web Application in the [Server-Side Account Linking](/users/references/link-accounts-server-side-scenario) article.
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/ja-jp/articles/users/concepts/overview-user-metadata.md b/ja-jp/articles/users/concepts/overview-user-metadata.md
new file mode 100644
index 0000000000..44fed097d4
--- /dev/null
+++ b/ja-jp/articles/users/concepts/overview-user-metadata.md
@@ -0,0 +1,61 @@
+---
+description: Understand how user metadata and app metadata can be used to store information that does not originate from an identity provider.
+topics: 
+   - metadata
+   - rules
+   - endpoints
+contentType: concept
+useCase: manage-users
+---
+
+# Metadata
+
+In addition to the [Normalized User Profile](/users/normalized) information, you can use metadata to store information that does not originate from an identity provider, or that overrides what an identity provider supplies.
+
+There are three types of data typically stored in the `app_metadata` field:
+
+* **Permissions**: privileges granted to certain users allowing them rights within the application that others do not have.
+* **Plan information**: settings that cannot be changed by the user without confirmation from someone with the appropriate authority.
+* **External IDs**: identifying information used to associate users with external accounts. 
+
+Auth0 distinguishes between two types of metadata used to store specific kinds of information:
+
+* **User metadata**: stores user attributes such as preferences that do *not* impact a user's core functionality. Logged in users can edit their data stored in `user_metadata` if you build a form for them using the Management API [`PATCH` endpoint](/api/management/v2#!/Users/patch_users_by_id) with the scope `update:current_user_metadata`. 
+* **App metadata**: stores information (such as, support plan subscriptions, security roles, or access control groups) that can impact a user's core functionality, such as how an application functions or what the user can access. Data stored in `app_metadata` cannot be edited by users. See [App metadata restrictions](/best-practices/metadata-best-practices#app-metadata-restrictions) for what cannot be stored in this field. 
+
+::: note
+Data unrelated to user authentication should always be stored in an external database and not in the user profile metadata. 
+:::
+
+In the following example, the user `jane.doe@example.com` has the following metadata stored with their profile. 
+
+```json
+{
+    "emails": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+In the above example metadata, within a [Rule](/rules) or via a [call to the Management API](/users/guides/read-metadata), you could reference specific items from the data set as follows:
+
+```js
+console.log(user.email); // "jane.doe@example.com"
+console.log(user.user_metadata.hobby); // "surfing"
+console.log(user.app_metadata.plan); // "full"
+```
+
+<%= include('../_includes/_connection-synch-note.md') %>
+
+## Keep reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [User Metadata in Rules](/rules/current/metadata-in-rules)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Metadata Best Practices](/best-practices/metadata-best-practices)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
diff --git a/ja-jp/articles/users/concepts/overview-user-migration.md b/ja-jp/articles/users/concepts/overview-user-migration.md
new file mode 100644
index 0000000000..7f516fafdc
--- /dev/null
+++ b/ja-jp/articles/users/concepts/overview-user-migration.md
@@ -0,0 +1,69 @@
+---
+description: Overview of importing users from external applications into Auth0.
+topics:
+  - users
+  - user-management
+  - migrations
+contentType:
+  - concept
+useCase:
+  - manage-users
+  - migrate
+---
+# Import and Export Users
+
+Auth0 supports importing users from external applications using custom database connections, the Auth0 Management API, or the User Import/Export Extension.
+
+## Automatic migrations
+
+Auth0 supports automatic migration of users from a [custom database connection](/connections/database/custom-db) to Auth0. By activating this feature, your users are:
+
+* Moved to Auth0 the first time they log in after you set up the integration. 
+* Not asked to reset their password as a result of the migration.
+
+::: panel Feature availability
+- Only **Developer**, **Developer Pro**, and **Enterprise** subscription plans include the database migration feature.
+- Only **Enterprise** subscription plans include the ability to connect to an existing store or database via JavaScript running on Auth0's servers for every authentication request.
+
+For more information refer to [Auth0 pricing plans](https://auth0.com/pricing).
+:::
+
+When a user authenticates via a custom database connection marked for import to Auth0, the following process takes place:
+
+![Migration Diagram](/media/articles/connections/database/migrating-diagram.png)
+
+* Auth0 authenticates migrated users against the Auth0 database. 
+* If the user has not been migrated, Auth0 executes your custom login script and, upon successfully log in, adds the user to the Auth0 database. 
+* Subsequent logins result in the user's credentials retrieved from Auth0, **NOT** your custom database.
+* New users are automatically added to the Auth0 database.
+
+::: note
+Auth0 can only assist users in the Auth0 database with password reset.
+:::
+
+## Bulk user imports with the Management API
+
+If you already have a user database, you can use our [`/post_users_imports`](/api/management/v2#!/Jobs/post_users_imports) Management API endpoint to populate a database connection with this information. 
+
+## Migrate users with the User Import/Export Extension
+
+The User Import/Export Extension allows you to:
+
+* Bulk import your existing database users into Auth0.
+* Search for and export some (or all) of your Auth0 database users.
+
+::: note
+You must be a Dashboard Admin to use this extension.
+:::
+
+You can import and export user data using the User Import/Export Extension available on the [Extensions](${manage_url}/#/extensions) section of the Dashboard. Select the **User Import / Export** extension and install it. For more information, see [User Import/Export Extension](/extensions/user-import-export).
+
+## Keep reading
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Example](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
+* [Migrate a User Database to Auth0](https://auth0.com/learn/migrate-user-database-auth0/)
diff --git a/ja-jp/articles/users/concepts/overview-user-profile.md b/ja-jp/articles/users/concepts/overview-user-profile.md
new file mode 100644
index 0000000000..71e68414a4
--- /dev/null
+++ b/ja-jp/articles/users/concepts/overview-user-profile.md
@@ -0,0 +1,119 @@
+---
+description: Explains the basics of Auth0 user profiles.
+toc: true
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: concept
+useCase: manage-users
+v2: true
+---
+# User Profiles
+
+Auth0 stores user information for your tenant in a hosted cloud database. Those users have access to applications connected to that tenant. User profiles contain information about your users such as name and contact information. Auth0 provides a variety of tools to help you manage user profiles such as the Dashboard and the Management API. You can create, search, view, and delete users.  
+
+## Data sources
+
+User information is stored in a *user profile* and can come from a variety of sources such as [identity providers](/identityproviders), your own databases, and enterprise connections (Active Directory, SAML, etc.). You can normalize user data that comes from a variety of data sources.
+
+The user profile attributes can also include information from the authenticating services (such as Facebook or LinkedIn). The authentication service might be an enterprise provider, such as Active Directory, or a SAML-compliant authentication service operated by a business or other organization. For example, attributes can be a person's contacts and their profile picture, or in the case of Enterprise users, an employee number or the name of the department to which an employee belongs.
+
+Attributes can also come from custom databases and web services. Auth0 refers to all attribute sources as **connections** because Auth0 connects to them to authenticate the user.
+
+## Data normalization
+
+Auth0 supports a wide variety of connections. Each connection may return a different set of attributes about the user, and each provider may use different names for the same attribute, such as *surname*, *last name* and *family name*. To handle the increased complexity this presents, Auth0 provides a [Normalized User Profile](/users/normalized). Auth0 returns a basic set of information using specific attribute names so programs can rely on using those same names to retrieve information such as `user_id`, `name`, `nickname`, and `picture`. If available, additional attributes such as `given_name` and `family_name` are also included in the Normalized User Profile.
+
+## Caching user profiles
+
+Auth0 caches the user profile received from a connection prior to passing it on to the calling application. This cache is stored in the Auth0 database. The information in the cache that originates from a connection is refreshed each time the user authenticates. See [Update User Profile Using Your Database](/users/guides/update-user-profiles-using-your-database#user-profile-cache)
+
+## Data structure
+
+There are several components to the User Profile data structure in Auth0. This structure can be viewed by clicking on the [Users tab](${manage_url}/#/users) in the Auth0 Dashboard and then on a particular user. See [User Profile Structure](/users/references/user-profile-structure).
+
+## Custom user profile data 
+
+Auth0 allows you to store **metadata**, which is data related to each user that has not come from the identity provider. 
+You can use `user_metadata` to store custom attributes such as the user's favorite color or hobby. See [Metadata](/users/concepts/overview-user-metadata).
+
+Auth0 provides a [JS widget](https://github.com/auth0/auth0-editprofile-widget) that allows the user to update their own profile information. 
+
+## User profile application access
+
+The User Profile will be provided to an application once authentication is complete and control is returned to the app. At a low level, this can be accomplished using one of the [application protocols](/protocols) supported by Auth0. However, most developers prefer to leverage the Auth0 SDKs that are available as [Quickstarts](/quickstarts).
+
+One SDK is the Auth0 Lock widget, which provides a user login interface:
+
+* [Web interface](/libraries/lock)
+* [Lock for iOS and OSX](/libraries/lock-ios)
+* [Lock for Android](/libraries/lock-android)
+
+Alternatively, if you'd like your web app to have a custom login UI, you can use [auth0.js](/libraries/auth0js), a headless JavaScript library for Auth0, which invokes authentication flow (as well as other tasks) and receives a User Profile object in return.
+
+## User profile Management API access
+
+Auth0 provides a REST API that allows applications and services to access and manipulate the User Profile object.
+
+The [API Explorer](/api/v2) allows users to interactively explore the Management API, view the API calls available, the information required for each call, and the information returned by each call. The explorer allows users to try out each endpoint in the explorer UI or via a CuRL command on the command line. To try out one of the Management API commands, select the access required under **Scopes** within that command, such as `update:users`, and then click on "TRY".
+
+Finally, there is the Authentication API specifically used for authentication flows. See [Authentication API Explorer](/api/authentication) for more information. Typically, most of these endpoints are used by the various Auth0 SDKs, not your own code.
+
+## User profile vs. tokens
+
+In the authentication flows described above, Auth0 returns a set of tokens in lieu of a full User Profile.
+
+One of the returned tokens is the ID Token, which is a [JSON Web Token](/tokens/concepts/jwts) (or JWT) that contains user profile attributes represented in the form of *claims*. These claims are statements about the user, which can be trusted if the consumer of the token can verify its signature, which is generated with the Auth0 app's Client Secret in the case of `HS256`. In case the application uses `RS256` encryption then the ID Token will be signed with a private key and verified with a public key. The app can then decode the JWT and get the user information contained in its payload, like the user's name, email, and so forth, typically used for UI display.
+
+The claims within a JWT generally contain a subset of the information available on the user profile in order to minimize the overall size. For further information on controlling the claims returned in a JWT, see the [Scopes](#scopes) section below.
+
+There are three other types of tokens that can be returned during authentication:
+
+* Auth0 Access Token
+* Third-party provider Access Token
+* Refresh Token
+
+For more information on tokens and claims see [Tokens](/tokens).
+
+## User profile data modification
+
+The information contained in a user profile and in an ID Token can be modified in a number of ways.
+
+* [**Scopes**](/scopes): The authentication flows supported by Auth0 includes an optional parameter that allows you to specify a scope. This controls the user profile information (claims) included in the ID Token (JWT). 
+
+* [**Management Dashboard**](/users/guides/manage-users-using-the-dashboard): The dashboard allows administrators to manually edit portions of the user profile for a particular user. This mechanism can be used to alter the `user_metadata` and `app_metadata` portions of the user profile.
+
+* [**Management API**](/users/guides/manage-users-using-the-management-api): Provides access to read, update, and delete user profiles stored in the Auth0 database.
+
+* [**Custom database scripts**](/connections/database/custom-db/templates): If a custom database is used as the connection, you can write scripts to implement lifecycle events such as create, login, verify, delete and change password. Auth0 provides templates for these scripts that you can modify for the particular database and schema.
+
+* [**Rules**](/rules/metadata-in-rules): Rules execute after a user has been authenticated. Use Rules to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. 
+
+## User profile attribute mapping
+
+### AD/LDAP connector
+
+For Active Directory or any other LDAP connections that use the Auth0 AD/LDAP connector, there is a mechanism for mapping User Profile attributes in the directory service to the Auth0 User Profile. This mapping takes place when a user authenticates via such a Connection and attributes specified in this mapping are reflected in the Auth0 User Profile.
+
+This mapping is implemented in a file called `profileMapper.js` located in the installation directory of the AD/LDAP connector.
+
+### SAML assertions
+
+If the SAML protocol is used between Auth0 and the application, there are two places where user attribute mapping can occur.
+
+If Auth0 is serving as a SAML Service Provider, the "Mappings" tab for a SAML connection is used to map attributes coming from an IDP to attributes in the Auth0 User Profile.
+
+`Connections -> Enterprise -> SAMLP -> {Name of Connection} -> Settings -> Mappings`
+
+If Auth0 is serving as a SAML Identity Provider, the Settings tab of Application AddOns is used to map attributes from the Auth0 User Profile to attributes in the SAML Assertion sent back to the Service Provider: **[Dashboard](${manage_url}) > Applications > name of your app > Addons > SAML2 Web App > Settings**.
+
+## Account linking
+
+Users can log into an application initially via one connection (such as a database), then log in via another connection (such as Facebook). In this case, the `user_id` for the second authentication will be different from that for the first authentication. 
+
+Auth0 provides a mechanism to [link](/users/concepts/overview-user-account-linking) the two accounts. If this is done, the `identities` array portion of the user profile will have multiple elements, one for each provider for which account linking has been done.
+
+::: note
+The user profile attributes from multiple providers are not merged. The core user profile attributes are sourced from the first provider used.
+:::
diff --git a/ja-jp/articles/users/guides/azure-access-control.md b/ja-jp/articles/users/guides/azure-access-control.md
new file mode 100644
index 0000000000..29e9fd4940
--- /dev/null
+++ b/ja-jp/articles/users/guides/azure-access-control.md
@@ -0,0 +1,78 @@
+---
+title: Migrate from Azure Access Control Service to Auth0
+description: How to migrate from Azure Access Control Service to Auth0.
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - azure
+contentType:
+  - concept
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Migrate from Azure Access Control Service to Auth0
+
+::: note
+Azure Access Control Service will be [retired in November 2018](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-acs-migration).
+:::
+
+In this article, you'll learn how to migrate from Azure Access Control (ACS) to Auth0, and connect to a [WS-Federation](/protocols/ws-fed) identity provider such as Azure Active Directory, Active Directory Federation Services, or IdentityServer.
+
+## Before you start
+
+* WS-Federation identity provider connections in Auth0 return tokens in SAML2 format. If your ACS configuration uses WS-Federation protocol with JWT tokens, you'll need to update your applications when migrating to Auth0.
+* Auth0 offers both [cloud and on-premises deployments](/getting-started/deployment-models).
+* Review the [Getting Started](/getting-started) documentation for an overview of Auth0.
+
+## Set up your account
+
+Start by [signing up for Auth0](https://auth0.com/signup). After creating your account, you'll be prompted to create a new [tenant](/getting-started/the-basics#account-and-tenants). Tenants in Auth0 are like namespaces in ACS: `${account.namespace}`.
+
+## Create an application
+
+In order for an application to use Auth0 it must be registered as a [application](/applications). Create a new application on the [Dashboard](https://manage.auth0.com/#/applications).
+
+![Create Application window](/media/articles/applications/create-client-popup.png)
+
+## Add Auth0 to your identity provider
+
+Next add Auth0 as a relying party to your identity provider using the following information:
+
+* Realm Identifier: `urn:auth0:${account.tenant}`
+* Return URL: `https://${account.namespace}/login/callback`
+
+## Create a WS-Federation connection
+
+To create a connection between Auth0 and your identity provider, navigate to [Dashboard > Connections > Enterprise](${manage_url}/#/connections/enterprise). For WS-Federation identity providers, create a new **ADFS** connection and provide the following information:
+
+* __Connection Name__: A descriptive name for the connection.
+* __Email Domains__: (Optional) A comma-separated list of valid domains. Only needed if you want to use the [Lock login widget](/libraries/lock).
+
+Next, either enter your WS-Federation server URL in the __ADFS URL__ field or upload a Federation Metadata file. 
+
+If you set a WS-Federation server URL, Auth0 will retrieve the Federation Metadata endpoint and import the required parameters, certificates, and URLs. You must make sure that the URL is publicly accessible and the SSL certificate on your ADFS installation is valid.
+
+![New Connection](/media/articles/connections/enterprise/ws-fed/new.png)
+
+After saving the new connection you'll see a list of your registered [applications](${manage_url}/#/applications). Enable the connection for your application.
+
+## Update your application
+
+Depending on your application and use case, you'll have to update your application to use Auth0 for authentication instead of ACS. There are several ways to integrate Auth0 with your application:
+
+- Configure the [Lock](/libraries#lock) authentication widget.
+- Use [Auth0 SDKs](/libraries#auth0-sdks) such as [Auth0.NET](https://github.com/auth0/Auth0.net).
+- Connect to the [Authentication API](/api/authentication).
+
+## Next Steps
+
+::: next-steps
+* [Add Rules to customize user authentication](/rules/current)
+* [Set up the Universal Login Page](/universal-login)
+* [Manage user access with groups, roles, and permissions](/extensions/authorization-extension)
+:::
diff --git a/ja-jp/articles/users/guides/block-and-unblock-users.md b/ja-jp/articles/users/guides/block-and-unblock-users.md
new file mode 100644
index 0000000000..45e57f08d9
--- /dev/null
+++ b/ja-jp/articles/users/guides/block-and-unblock-users.md
@@ -0,0 +1,46 @@
+---
+description: Describes how to block and unblock users. 
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Block and Unblock Users
+
+You can use the Dashboard to restrict a specific user's access to your application.
+
+## Block a user
+
+To disable a user's access to your apps, you can block the user in the Dashboard:
+
+1. Go to the [Users](${manage_url}/#/users) page in the Dashboard
+2. Click the name of the user you want to block
+3. When the User Details page opens, click the **Actions** button.
+4. Select **Block User** from the dropdown menu.
+
+![Block a User](/media/articles/user-profile/user4.png)
+
+If a blocked user tries to access an application, they will be redirected to the application with the error message `user is blocked` in the URL.
+
+::: note
+Blocking does not expire. You must unblock the user to allow the user to have access to your apps. 
+:::
+
+## Unblock a user
+
+To reinstate a user's access to your apps, you can unblock the user in the Dashboard:
+
+1. Go to the [Users](${manage_url}/#/users) page in the Dashboard. 
+2. Click the name of the user you want to unblock. 
+3. When the User Details page opens, click the **Actions** button. 
+4. Select **Unblock User** from the dropdown menu.
+
+![Unblock a User](/media/articles/user-profile/user4.png)
+
+## Keep reading
+
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/bulk-user-exports.md b/ja-jp/articles/users/guides/bulk-user-exports.md
new file mode 100644
index 0000000000..3eb1aada24
--- /dev/null
+++ b/ja-jp/articles/users/guides/bulk-user-exports.md
@@ -0,0 +1,243 @@
+---
+title: Bulk User Exports
+description: Learn how to export lists of users and user metadata.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Bulk User Exports
+
+You can use the [`POST /api/v2/jobs/users-exports`](/api/management/v2#!/Jobs/post_users_exports) endpoint to create a job that exports all users associated with a [connection](/identityproviders).
+
+For a list of user profile fields that can be exported, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes).
+
+When you create your job, you'll need to provide:
+
+* ID for the connection whose users you want exported
+* Format of the export file (CSV or JSON-compatible)
+* Maximum number of user records to be exported (optional, will export all records if omitted)
+* User-related fields (such as user ID or name) that you want included in the export
+
+<%= include('../search/v3/_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+    "queryString": [],
+    "postData": {
+        "mimeType": "application/json",
+        "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"csv\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, { \"name\": \"identities[0].connection\", \"export_as\": \"provider\" }]}" 
+    },
+    "headersSize": -1,
+    "bodySize": -1,
+    "comment": ""
+}
+```
+
+### Sample results
+
+```json
+{
+  "type": "users_export",
+  "status": "pending",
+  "connection_id": "con_0000000000000001",
+  "format": "csv",
+  "limit": 5,
+  "fields": [
+    {
+      "name": "user_id"
+    },
+    {
+      "name": "name"
+    },
+    {
+      "name": "email"
+    },
+    {
+      "name": "identities[0].connection",
+      "export_as": "provider"
+    }
+  ],
+  "connection": "Username-Password-Authentication",
+  "created_at": "2017-11-02T23:34:03.803Z",
+  "id": "job_coRQCC3MHztpuTlo"
+}
+```
+
+## Include user metadata
+
+### CSV format
+
+If you export user data in CSV format and want to include metadata information, specify each metadata field that you want to include. 
+
+For example, for metadata structured like this:
+
+```json
+{
+  "consent": {
+      "given": true,
+      "date": "01/23/2019",
+      "text_details": "some-url"
+  }
+}
+```
+
+The export request (for all three fields) will looks like this:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"csv\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, {\"name\": \"user_metadata.consent.given\"}, {\"name\": \"user_metadata.consent.date\"}, {\"name\": \"user_metadata.consent.text_details\"}]}" 
+    },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+::: note
+Auth0 allows you to export the entirety of the `app_metadata` or `user_metadata` in one field. For example, if you want the full `app_metadata` field exported, your mapping should be `"app_metadata": "app_metadata"`. You do not need to specify each parameter individually to return the entire metadata field.
+:::
+
+### JSON-compatible format
+
+If you export the data in JSON-compatible format, you only need to provide the root property; you do not need to name each individual inner property since they will be included automatically.
+
+::: note
+Auth0's export files use the [ndjson](http://ndjson.org/) format due to the large size of the export files, while the import functionality expects a JSON file.
+
+Before you can import users using an export generated by Auth0, you'll need to convert the file from **ndjson** to **json** using the library of your choice (such as [jq](https://stedolan.github.io/jq/)).
+:::
+
+In this case, for the same example we used before, the request will look like this:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/jobs/users-exports",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  },
+  {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"connection_id\": \"YOUR_CONNECTION_ID\", \"format\": \"json\", \"limit\": 5, \"fields\": [{\"name\": \"email\"}, {\"name\": \"user_metadata.consent\"}]}" 
+    },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+## Check export status
+
+Once you've created your job to export your users, you can check on its status using the [Get a Job endpoint](/api/management/v2#!/Jobs/get_jobs_by_id). 
+
+Provide the ID of the job (which you received in the response when creating the job). If you're using the sample request below, replace the placeholder `YOUR_JOB_ID` with the value of the ID.
+
+*Require Scopes*: `create:users`, `read:users`, `create:passwords_checking_job`
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/YOUR_JOB_ID",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+  }]
+}
+```
+
+### Sample results
+
+```json
+{
+  "type": "users_export",
+  "status": "completed",
+  "connection_id": "con_lCvO...a",
+  "format": "csv",
+  "limit": 5,
+  "fields": [
+    {
+      "name": "user_id"
+    },
+    {
+      "name": "name"
+    },
+    {
+      "name": "email"
+    },
+    {
+      "name": "identities[0].connection",
+      "export_as": "provider"
+    }
+  ],
+  "location": "https://user-exports.auth0.com/job_coRQCC3MHztpuTlo/auth0docs2.csv.gz?Expires=1509725589&Key-Pair-Id=APKAJPL62IJALBDMSSCA&Signature=l2JaFXP~BATnfagb64PK-qbX9QaZREDYNW0q5QeHuV-MaDpZjpABDXfHHLh2SsCMQz~UO-QsCSfI81l0lvCKzZPZL6cZHK7f~ixlZOK~MHKJuvMqsUZMbNluNAwhFmgb2fZ86yrB1c-l2--H3lMELAk7hKUwwSrNBlsfbMgQ-i41nMNnsYdy3AVlNVQkwZyx~w-IEHfJDHsqyjia-jfDbIOLQvr8~D9PwZ-xOzROxDwgxrt3undtz80bkgP5hRKOAbHC7Y-iKWa2bzNZYHqzowTrlh7Ta60cblJR46NfF9cNqn9jqRGVv-lsvUD9FxnImCCk~DL6npJnzNLjHvn4-CaWq6KdQnwWgCnZ3LZkxXDVWLLIQQaoc6i~xbuGnnbtKRePFSnpqbt2mAUYasdxTOWuUVK8wHhtfZmRYtCpwZcElXFO9Qs~PTroYZEiS~UHH5byMLt2x4ChkHnTG7pIhLAHN~bCOLk8BN2lOkDBUASEVtuJ-1i6cKCDqI2Ro9YaKZcCYzeQvKwziX6cgnMchmaZW77~RMOGloi2EffYE31OJHKiSVRK7RGTykaYN5S2Sg7W0ZOlLPKBtCGRvGb8rJ6n3oPUiOC3lSp7v0~dkx1rm-jO8mKWZwVtC0~4DVaXsn8KXNbj0LB4mjKaDHwXs16uH1-aCfFnMK7sZC2VyCU_",
+  "connection": "Username-Password-Authentication",
+  "created_at": "2017-11-02T23:34:03.803Z",
+  "id": "job_coRQCC3MHztpuTlo"
+}
+```
+
+## Find export data
+
+You can access your export files using the URL provided as the value for the **location** parameter. The name of your tenant is also the name of your file. For example, if your tenant name is `auth0docs`, then your file will be `auth0docs.csv` or `auth0docs.json`. When you navigate to the URL, you will automatically begin downloading the file. 
+
+::: note
+The download link is valid for 60 seconds. If this time period expires, you will need to initiate a new job.
+:::
+
+![Exported user data](/media/articles/users/data.png)
+
+## Job timeouts
+All user export jobs timeout after **eight (8) hours**. If your job does not complete within this time frame, it is marked as failed.
+Furthermore, all of your job-related data is automatically deleted after 24 hours and cannot be accessed afterward. As such, **we strongly recommend storing the job results using the storage mechanism of your choice**.
+
+## Keep reading
+
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/ja-jp/articles/users/guides/bulk-user-imports.md b/ja-jp/articles/users/guides/bulk-user-imports.md
new file mode 100644
index 0000000000..3545080a49
--- /dev/null
+++ b/ja-jp/articles/users/guides/bulk-user-imports.md
@@ -0,0 +1,288 @@
+---
+title: Bulk User Imports
+description: Learn how to perform bulk user imports with the Management API.
+crews: crew-2
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - bulk-imports
+contentType:
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Bulk User Imports
+
+This tutorial shows you how to bulk import user data into Auth0 using the [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint. Bulk imports are useful for migrating users from an existing database or service to Auth0.
+
+## Before you start
+
+Before you launch the import users job:
+
+* [Configure a database connection](/connections/database) to import the users into and enable it for at least one application.
+* If you are importing passwords, make sure the passwords are hashed using one of the [supported algorithms](/users/references/bulk-import-database-schema-examples#supported-hash-algorithms). Users with passwords hashed by unsupported algorithms will need to reset their password when they log in for the first time after the bulk import.
+* If you are importing MFA enrollments, make sure they are a [supported type](/users/references/bulk-import-database-schema-examples#mfa-factors): `email`, `phone`, or `totp`. 
+* Get a [Management API Token](/api/management/v2/tokens) for job endpoint requests.
+
+## Create users JSON file
+
+First you'll need to create a JSON file with the user data you want to import into Auth0. How you export user data to a JSON file will vary depending on your existing user database. To see the JSON file schema and examples, visit [Bulk Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples).
+
+The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
+
+## Request bulk user import
+
+To start a bulk user import job, make a `POST` request encoded as type `multipart/form-data` to the [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN`, `USERS_IMPORT_FILE.json`, `CONNECTION_ID`, and `EXTERNAL_ID` placeholder values with your Management API Access Token, users JSON file, database connection ID, and external ID, respectively.
+
+```har
+{ 
+  "method":"POST",
+  "url":"https://${account.namespace}/api/v2/jobs/users-imports",
+  "headers":[ 
+    { 
+      "name":"Content-Type",
+      "value":"multipart/form-data"
+    },
+    { 
+      "name":"Authorization",
+      "value":"Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ],
+  "postData":{ 
+    "mimeType":"multipart/form-data",
+    "params":[ 
+      { 
+        "name":"users",
+        "fileName":"USERS_IMPORT_FILE.json",
+        "contentType":"application/json"
+      },
+      { 
+        "name":"connection_id",
+        "value":"CONNECTION_ID"
+      },
+      { 
+        "name":"external_id",
+        "value":"EXTERNAL_ID"
+      }
+    ]
+  }
+}
+```
+
+| Parameter | Description |
+|-----------|-------------|
+| `users` | [File in JSON format](/users/references/bulk-import-database-schema-examples#examples) that contains the users to import. |
+| `connection_id` | ID of the connection to which users will be inserted. You can retrieve the ID using the [GET /api/v2/connections](/api/management/v2#!/Connections/get_connections) endpoint. |
+| `upsert` | Boolean value; `false` by default. When set to `false`, pre-existing users that match on email address, user ID, or username will fail. When set to `true`, pre-existing users that match on any of these fields will be updated, but only with upsertable attributes. For a list of user profile fields that can be upserted during import, see [User Profile Attributes](/users/references/user-profile-structure#user-profile-attributes). |
+| `external_id` | Optional user-defined string that can be used to correlate multiple jobs. Returned as part of the job status response. |
+| `send_completion_email` | Boolean value; `true` by default. When set to `true`, sends a completion email to all tenant owners when the import job is finished. If you do *not* want emails sent, you must explicitly set this parameter to `false`. |
+
+If the request is successful, you'll receive a response similar to the following:
+
+```json
+{
+  "status": "pending",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "upsert": false,
+  "external_id": "EXTERNAL_ID",
+  "send_completion_email": true
+}
+```
+
+The returned entity represents the import job.
+
+When the user import job finishes and if `send_completion_email` was set to `true`, the tenant administrator(s) will get an email notifying them that job either failed or succeeded. An email for a job that failed might notify the administrator(s) that it failed to parse the users JSON file when importing users.
+
+### Concurrent import jobs
+
+The [create import users job](/api/management/v2#!/Jobs/post_users_imports) endpoint has a limit of two concurrent import jobs. Requesting additional jobs while there are two pending returns a `429 Too Many Requests` response:
+
+```json
+{
+  "statusCode": 429,
+  "error": "Too Many Requests",
+  "message": "There are 2 active import users jobs, please wait until some of them are finished and try again
+}
+```
+
+## Check job status
+
+To check a job's status, make a `GET` request to the [get a job](/api/management/v2#!/Jobs/get_jobs_by_id) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN` and `JOB_ID` placeholder values with your Management API Access Token and user import job ID.
+
+```har
+{ 
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/JOB_ID",
+  "headers": [ 
+    { 
+      "name": "Content-Type",
+      "value": "application/json"
+    },
+    { 
+      "name": "Authorization",
+      "value": "Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ]
+}
+```
+
+Depending on the status of the user import job, you'll receive a response similar to one of the following:
+
+### Pending
+
+```json
+{
+  "status": "pending",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID"
+}
+```
+
+### Processing
+
+```json
+{
+  "status": "processing",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "percentage_done": 0,
+  "time_left_seconds": 0
+}
+```
+
+### Completed
+
+If a job is completed, the job status response will include totals of successful, failed, inserted, and updated records.
+
+```json
+{
+  "status": "completed",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "location": "https://${account.namespace}/EXAMPLE",
+  "summary": {
+    "failed": 0,
+    "updated": 0,
+    "inserted": 1,
+    "total": 1
+  }
+}
+```
+
+## Failed
+
+If there is an error in the job, it will return as failed. However, note that invalid user information, such as an invalid email, will not make the entire job fail.
+
+```json
+{
+  "status": "failed",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID",
+  "summary": {
+    "failed": 1,
+    "updated": 0,
+    "inserted": 0,
+    "total": 1
+  }
+}
+```
+
+To learn how to get details for failed entries, see [Retrieve failed entries](#retrieve-failed-entries). 
+
+### Expired
+
+Expired jobs are completed jobs that were created more than 2 hours ago.
+
+```json
+{
+  "status": "expired",
+  "type": "users_import",
+  "created_at": "",
+  "id": "job_abc123",
+  "connection_id": "CONNECTION_ID",
+  "external_id": "EXTERNAL_ID"
+}
+```
+
+Additionally, the job status is added to [Tenant Logs](${manage_url}/#/logs), which allows for a custom WebHook to be triggered using the [WebHook Logs Extension](/extensions/management-api-webhooks).
+
+## Job timeouts
+
+All user import jobs timeout after two (2) hours. If your job does not complete within this time frame, it is marked as failed.
+
+## Retrieve failed entries
+
+::: warning
+All of the job-related data is automatically deleted after 24 hours and cannot be accessed thereafter. Because of this, we strongly recommend storing the job results using the storage mechanism of your choice.
+:::
+
+If there were errors in the user import job, you can get the error details by making a `GET` request to the [get job error details](/api/management/v2#!/Jobs/get_errors) endpoint. Be sure to replace the `MGMT_API_ACCESS_TOKEN` and `JOB_ID` placeholder values with your Management API Access Token and user import job ID.
+
+```har
+{ 
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/jobs/JOB_ID/errors",
+  "headers": [ 
+    { 
+      "name": "Content-Type",
+      "value": "application/json"
+    },
+    { 
+      "name": "Authorization",
+      "value": "Bearer MGMT_API_ACCESS_TOKEN"
+    }
+  ]
+}
+```
+
+If the request is successful, you'll receive a response similar to the following. Sensitive fields such as `hash.value` will be redacted in the response.
+
+```json
+[
+    {
+        "user": {
+            "email": "test@test.io",
+            "user_id": "7af4c65cb0ac6e162f081822422a9dde",
+            "custom_password_hash": {
+                "algorithm": "ldap",
+                "hash": {
+                    "value": "*****"
+                }
+            }
+        },
+        "errors": [
+            {
+                "code": "...",
+                "message": "...",
+                "path": "..."
+            }
+        ]
+    }
+]
+```
+
+## Related pages
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Examples](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
diff --git a/ja-jp/articles/users/guides/change-user-pictures.md b/ja-jp/articles/users/guides/change-user-pictures.md
new file mode 100644
index 0000000000..44585a59aa
--- /dev/null
+++ b/ja-jp/articles/users/guides/change-user-pictures.md
@@ -0,0 +1,86 @@
+---
+description: How to use the user_metadata to change a user's picture field and how to change the default picture for all users.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - user-picture
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Change User Pictures
+
+Auth0 [normalizes](/users/normalized) common profile properties in the User Profile, this includes the `name` and `picture` field and more. The picture field is populated by either the social provider profile picture or the Gravatar image associated with the user's email address. By default, all database users will have a placeholder image with their initials. When you authenticate the user, this picture field is referred by as `user.picture`.
+
+![User Picture](/media/articles/user-profile/user-picture.png)
+
+1. By default, the `user.picture` attribute is not directly editable when provided by identity providers other than Auth0 (such as Google, Facebook, Twitter). If you want to be able to edit this attribute, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+
+Alternatively, you can use the [Metadata](/users/concepts/overview-user-metadata) to store the picture attribute for users, but this is not recommended for scalability.
+
+For example, if your app provides a way to upload profile pictures, once the picture is uploaded, you can set the URL to the picture in `user.user_metadata.picture`:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/USER_ID",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"picture\": \"https://example.com/some-image.png\"}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+2. To ensure that the picture from the `user_metadata` is returned in the ID Token, you need to create a [Rule](/rules) to check whether the `user.user_metadata.picture` attribute is present, and if so replace the `user.picture` attribute with that value. This will ensure that the picture from the `user_metadata` is returned in the `picture` claim of the ID Token.
+
+Here is an example of the code you can use in your Rule:
+
+```js
+function (user, context, callback) {
+  if (user.user_metadata.picture)
+    user.picture = user.user_metadata.picture;
+
+  callback(null, user, context);
+}
+```
+
+## Change the default picture for all users
+
+To change the default picture of all users who do not have a profile picture set, you can use a rule to do this.
+
+Example:
+
+```js
+
+function (user, context, callback) {
+  if (user.picture.indexOf('cdn.auth0.com') > -1) {
+    const url = require('url');
+    const u = url.parse(user.picture, true);
+    u.query.d = 'URL_TO_YOUR_DEFAULT_PICTURE_HERE';
+    delete u.search;
+    user.picture = url.format(u);
+  }
+  callback(null, user, context);
+}
+
+```
+
+## Keep reading
+
+- [User Profile Structure](/users/references/user-profile-structure)
+- [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/configure-automatic-migration.md b/ja-jp/articles/users/guides/configure-automatic-migration.md
new file mode 100644
index 0000000000..bf8c2b6c20
--- /dev/null
+++ b/ja-jp/articles/users/guides/configure-automatic-migration.md
@@ -0,0 +1,114 @@
+---
+title: Configure Automatic Migration from Your Database
+description: Learn how to enable automatic user migration with your custom database. 
+topics:
+  - users
+  - user-management
+  - migrations
+  - automatic-user-migration
+  - custom-db
+contentType: how-to
+useCase:
+  - manage-users
+  - migrate
+---
+
+# Configure Automatic Migration from Your Database
+
+After you create a database connection in the Dashboard, you enable user migration from that database and create custom scripts to determine how the migration happens. 
+
+These custom scripts are Node.js code that run in the tenant's sandbox. Auth0 provides templates for most common databases, such as: **ASP.NET Membership Provider**, **MongoDB**, **MySQL**, **PostgreSQL**, **SQLServer**, **Windows Azure SQL Database**, and for a web service accessed by **Basic Auth**. For more information on implementing these scripts, see [Authenticate Users using a Custom Database](/connections/database/mysql).
+
+1. Navigate to the [Connections > Database](${manage_url}/#/connections/database) page in the [Auth0 Dashboard](${manage_url}/), and click **Create DB Connection**.
+
+![Dashboard: Database Connection List](/media/articles/dashboard/connections/database/dashboard-connections-database-list.png)
+
+2. Click the **Custom Database** tab, and enable the **Use my own database** option:
+
+![Dashboard: Enable Use My Own Database Option](/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png)
+
+3. Click the **Settings** tab, and enable the **Import Users to Auth0** option:
+
+![Dashboard: Enable Import Users Option](/media/articles/dashboard/connections/database/connections-db-settings-main-2.png)
+
+## Configure the scripts 
+
+1. Click the **Custom Database** tab, and locate **Database Action Scripts** to see the scripts you need to configure.
+
+![Dashboard: Configure Database Action Scripts](/media/articles/dashboard/connections/database/connections-db-settings-custom-1.png)
+
+- **Login**: Executes each time a user that is not found in the Auth0 database attempts to log in. Verifies that the user exists in the legacy database without re-prompting the user for their password.
+
+- **Get User**: Executes following any of these actions:
+    * user attempts to *sign-up*.
+    * user clicks on valid [password change confirmation](/libraries/lock/customization#rememberlastlogin-boolean-) link.
+    * Management API receives a call to the [update a user's email or username](/api/v2#!/Users/patch_users_by_id) endpoint.
+
+:::panel-warning Passwords for Un-Migrated Users
+If an un-migrated user confirms a password change, their user profile will be created in Auth0 with the new password. This user profile will contain all the information returned in the **Get User** script. All subsequent logins of this user will be performed in Auth0 directly.
+
+You may see unexpected behavior if you return differing user profiles in the `login` and `get_user` scripts.
+:::
+
+## Verify the migration
+
+After you've enabled migration, you can verify the users that have migrated by doing one or both of the following tasks:
+
+1. Use the [List or search users](/api/v2#!/Users/get_users) Management API endpoint.
+
+2. Navigate to the [Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and review the list of users.
+
+![View Users](/media/articles/dashboard/users-roles/users-list.png)
+
+## Convert the database 
+
+Once all your users are in the Auth0 database, you are ready to convert the database so that it uses only users stored in Auth0.
+
+1. Go to your custom database connection on the [Dashboard](${manage_url}/#/connections/database).
+
+2. Update the **Login** Database Action Script to the following:
+
+```
+function login (email, password, callback) {
+  return callback(null, null);
+}
+```
+
+3. Update the **Get User** Database Action Script to the following:
+
+```
+function getByEmail (email, callback) {
+  return callback(null, null);
+}
+```
+
+By doing this, you are changing the **Login** and **Get User** [Database Action Scripts](/connections/database/mysql#3-provide-action-scripts) to NO-OP functions, essentially making it behave as a non-custom database connection.
+
+:::panel-warning Leave Import Users to Auth0 turned on
+Make sure to leave the **Import Users to Auth0** option turned on. If you turn this option off Auth0 will only use the scripts to authenticate and perform other user actions instead of using the users that were imported locally.
+:::
+
+## Disconnect the legacy database
+
+1. After you have verified the migration, you can disconnect your legacy database (**not** the Auth0 database). If you modified the scripts as instructed above, Auth0 will not try to connect to your legacy database.
+
+2. Keep **Import Users to Auth0** (on the **Settings** page) enabled. This, combined with the NO-OP script changes, will ensure that only the Auth0 users database is used. 
+
+3. Configure [rules](/rules) to execute other functions when a user authenticates to your application.
+
+## Troubleshoot migration errors
+
+The most common error message that you may encounter when importing users from a legacy database to an Auth0 custom database is "The user already exists." 
+
+When a user is imported, a partial user state is first created on the Auth0 end to make this migration possible. If you delete this user from the Auth0 connection then later recreate the user, you may receive this error. In addition, the **Get User** script is called on user creation. If you attempt to create a new user in the Auth0 custom database connection and the user already exists in your external database, you will receive this error.
+
+If you encounter a "user already exists" error message, use the Management API's [endpoint to delete a connection user](/api/management/v2#!/Connections/delete_users_by_email) to delete the user. Confirm that the user does not exist in your legacy database, then recreate the user. 
+
+## Keep reading
+
+* [User Migration Overview](/users/concepts/overview-user-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Bulk Import Database Schema and Example](/users/references/bulk-import-database-schema-examples)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
diff --git a/ja-jp/articles/users/guides/create-users.md b/ja-jp/articles/users/guides/create-users.md
new file mode 100644
index 0000000000..92470960c1
--- /dev/null
+++ b/ja-jp/articles/users/guides/create-users.md
@@ -0,0 +1,55 @@
+---
+description: How to create users in the Auth0 Dashboard.
+crews: crew-2
+topics:
+  - dashboard
+  - users
+contentType: how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Create Users Using the Dashboard
+
+You can manually create users via the [Dashboard](${manage_url}).
+
+1. Log in and open up the Dashboard. Navigate to the _Users_ tab.
+
+![](/media/articles/users/dashboard.png)
+
+2. Click on the __Create User__ button near the top right-hand side of the screen.
+
+![](/media/articles/users/users-tab.png)
+
+3. Provide the following information for the new user:
+    * **Email**: The user's email address. The maximum length is 64 characters for the user/local part and 256 characters for the domain part.
+    * **Password**: The user's password. There is no maximum limit for password length. For more information, refer to [Password Strength in Auth0 Database Connections](/connections/database/password-strength). 
+    * **Repeat Password**: Confirm password.
+    * **Connection**: The database connection to use to authenticate the user. The dropdown lists all the configured database connections in your tenant. The connection you use must be associated with an application. 
+
+4. When finished, click __Save__ to create the new user.
+
+::: note
+The connection you use must be associated with an application, otherwise you will receive an error message that says, The connection is disabled. You can enable connections for Applications from the Dashboard, in  Application Settings > Connections, or from the Connection Settings > Applications.
+:::
+
+![](/media/articles/users/create-user.png)
+
+At this point, the user is created, and you will be directed to the newly-created user's profile.
+
+![](/media/articles/users/user-profile.png)
+
+::: panel Pending Users
+The User Details page will show `pending` when a user is first created until they have logged in for the first time.
+:::
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [Manage Users Using the Dashboard](/users/guides/manage-users-using-the-dashboard)
+* [View Users](/users/guides/view-users)
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
+* [User Search](/users/search)
diff --git a/ja-jp/articles/users/guides/delete-users.md b/ja-jp/articles/users/guides/delete-users.md
new file mode 100644
index 0000000000..b18a00679d
--- /dev/null
+++ b/ja-jp/articles/users/guides/delete-users.md
@@ -0,0 +1,32 @@
+---
+description: Describes how to delete users.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Delete Users
+
+1. To permanently delete a user, navigate to the [Users](${manage_url}/#/users) page in the Dashboard. 
+
+2. Click the name of the user you want to delete. 
+
+3. When the User Details page opens, click the **Actions** button. 
+
+4. Select **Delete User** from the dropdown menu.
+
+![Delete a User](/media/articles/user-profile/user4.png)
+
+A popup will warn you that the action cannot be undone and prompt you to confirm that you want to delete the user. 
+
+5. Click the **Yes, Delete It** button to confirm. This will permanently delete the user.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/email-verified.md b/ja-jp/articles/users/guides/email-verified.md
new file mode 100644
index 0000000000..02fc5a021d
--- /dev/null
+++ b/ja-jp/articles/users/guides/email-verified.md
@@ -0,0 +1,71 @@
+---
+title: Email Verified Usage
+description: Outlines proper usage of the email_verified field in a user profile.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType:
+    - how-to
+    - reference
+useCase: manage-users
+---
+# Verified Email Usage
+
+The `email_verified` field of a user profile indicates whether the user has verified their email address. Email verification is optional, but valid email addresses are required for certain actions, such as sending email communications, password reset/recovery links, and passwordless magic links to users.
+
+An email is usually verified immediately after the user account is created or when the user logs in to the application for the first time. It's a good way to know that the person signing up actually owns the email at that moment. 
+
+Since email verification happens once at that specific moment, we can't ensure that a person who logs in with the user account at a later time still owns the email address that was verified. 
+
+In case of federated identity providers, they sometimes report if the user has a verified email, and based on that, Auth0 sets the `email_verified` field in the user profile. This, however, transfers the responsibility to the identity provider to do it properly - something we can't ensure. We also don't know if the verified email from that provider is still owned by the user.
+ 
+For all of these reasons, we need to be careful on what we can assume based on a verified email.
+
+## When does Auth0 sets emails as verified?
+
+When users signup with email and password, they will get a [verification email](/email/templates#verification-email) with a link. When they click the link, their email will be verified. 
+
+When users authenticate with a federated identity provider (e.g. a social or enterprise connection), the value of the `email_verified` field will match what the identity provider returns in the user profile. If they identity provider does not return any value, it will be set to `false`.
+
+## Verified Emails and Account Linking
+
+When you want to [link two user accounts](/articles/users/concept/overview-user-account-linking), you need to make sure that the user still has access to both accounts. The only way to achieve that is to have users authenticate with both accounts before linking them. 
+
+You **should not automatically link accounts based on the user's emails**. Always prompt users to authenticate again before doing that. This will prevent scenarios like:
+
+- John Doe, an employee of Travel0, signs up to a site using his corporate email `john.doe@travel0.com` and a password. Months later, John Doe leaves Travel0, and a new John Doe is hired, with the same email account. That person goes to the same website, and authenticates with his corporate identity provider (e.g. GSuite), and gets the account automatically linked to the other user.
+
+- Federated identity providers can make mistakes on how they handle email verification, and can report that users own an email they do not. 
+
+On the other hand, we recommend you to still check for the `email_verified` field *before* performing account linking, to mitigate scenarios like:
+
+- An attacker creates a Google account 'attacker@gmail.com'
+- Attacker creates a new database users with the victim's email (e.g. 'victim@hotmail.com').
+- Attacker links both accounts.
+- Attacker sends a phishing attack to victim.
+- The victim tries to sign-up, they are told the user already exists, and get offered to reset the password.
+- The user enters their password, and logs into the attacker's account, which now has access to whatever data the victim enters in the application.
+
+## Verified Emails and Authorization Decisions
+
+In the same way you can't fully trust the email, you can't fully trust the email domain. 
+
+If your application needs to restrict access based on the user's employer, the fact that a user is logged in with an email from a specific corporate domain does not guarantee that it should be granted access.
+
+For example:
+
+- If your application allows customers to sign up for new accounts, and employees from different companies authenticate using their corporate credentials, a user that signs up with a user@acme.com account shouldn't be granted access to the same feature set that a user authenticating with acme.com's corporate directory.
+
+- If your application supports authenticating with Azure AD, and the directory supports guests users, you can get users from any domain logging-in from that Azure AD tenant. You should not give guest users the same access level as the rest of the users authenticating with that tenant.
+
+As a general recommendation, **you should not use the email's domain to make authorization decisions**. If you need to check if the user belongs to a specific organization, it's better to rely on the connection they used to authenticate, or in connection-specific attributes like the Azure AD's tenant id.
+
+## Keep reading
+
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [Email Verification for Azure AD and ADFS connections](/connections/azuread-adfs-email-verification)
diff --git a/ja-jp/articles/users/guides/get-user-information-with-unbounce-landing-pages.md b/ja-jp/articles/users/guides/get-user-information-with-unbounce-landing-pages.md
new file mode 100644
index 0000000000..78dc41b345
--- /dev/null
+++ b/ja-jp/articles/users/guides/get-user-information-with-unbounce-landing-pages.md
@@ -0,0 +1,74 @@
+---
+description: How to get user information with one-click social authentication on Unbounce landing pages.
+topics:
+  - users
+  - user-management
+  - search
+  - unbounce
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Get User Information on Unbounce Landing Pages
+
+## Auth0 Configuration
+
+1. Create an Auth0 account and navigate to the [dashboard](${manage_url}).
+1. Go to [Applications](${manage_url}/#/applications) and click **+ Create Application**. Pick the `Single-Page Application` option and go to **Settings**. Note the **Client ID** and **Domain**. Also, add the `callback URL` in both **Allowed Callback URLs** and **Allowed Origins (CORS)** (it should be your Unbounce page URL. For example:`http://unbouncepages.com/changeit`).
+1. Go to **Connections > Social** and enable the social providers you want to support.
+
+![Social Connections](/media/articles/scenarios/unbounce/social-connections.png)
+
+## Unbounce Configuration
+
+* Add a button (or whatever UI element you consider) that will trigger the login with the provider. Take note of the button ID under **Properties > Element Metadata**.
+* Add a new JavaScript to your Unbounce landing page, select `Before Body End Tag` under `Placement` and add this code. Also make sure to check jQuery as a dependency.
+
+```html
+
+
+```
+
+::: note
+You should use the clientID and Domain of the application you just configured.
+:::
+
+* You need a way to pass the information coming from the social providers to Unbounce. The way you do that is by creating a Form and adding `Hidden fields` for each field. In the following example we are using the fields `name` and `email`.
+  ![](/media/articles/scenarios/unbounce/custom-fields.png)
+* Finally, go back to the JavaScript editor at Unbounce and add a click handler for each button to trigger the social authentication. Here, you must replace the button ID you took note of previously and the connection name, which can be seen in the [dashboard](${manage_url}) under under **Connections > Social** and expanding the provider. For example, for Google you would use `google-oauth2` and for LinkedIn, `linkedin`. Also, make sure that you replace the IDs properly, so instead of `#name` and `#email` you should put the ID of the form fields in question (you can see them while editing the form, under `Field Name and ID`).
+
+```js
+$('#REPLACE_WITH_BUTTON_ID').bind('click', function() { 
+  webAuth.authorize({
+    connection: 'YOUR CONNECTION NAME'
+  });
+});
+
+// After authentication occurs, the parseHash method parses a URL hash fragment to extract the result of an Auth0 authentication response.
+
+webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) { 
+  if (err) { 
+    return console.log(err); 
+  }
+
+  if (authResult != null && authResult.accessToken != null) {
+    webAuth.client.userInfo(authResult.accessToken, function(err, user) {
+      $('#name').val(user.name); 
+      $('#email').val(user.email); 
+    }); 
+  } 
+
+});
+```
+
+Now you will be able to see the information provided by the IdP in the `Leads` section of your Unbounce Admin Panel, after the user submits the form.
diff --git a/ja-jp/articles/users/guides/impersonate-users-using-the-dashboard.md b/ja-jp/articles/users/guides/impersonate-users-using-the-dashboard.md
new file mode 100644
index 0000000000..7eaac0e5a9
--- /dev/null
+++ b/ja-jp/articles/users/guides/impersonate-users-using-the-dashboard.md
@@ -0,0 +1,114 @@
+---
+description: Learn how to impersonate users using the Dashboard to view their information as they would see it. 
+sitemap: false
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Impersonate Users Using the Dashboard
+
+<%= include('../../_includes/_deprecate-impersonation') %>
+
+You may need to impersonate other users for testing or troubleshooting purposes. You can:
+
+* Log in to an app as a specific user.
+* See everything exactly as that user sees it.
+* Do everything exactly as that user does it.
+
+Auth0 provides a __Sign in As__ feature for user impersonation, and provides the following features and information:
+
+* Detailed auditing of who impersonated when.
+* Restrictions on impersonation which allows you to reject an impersonated authentication transaction based on, for instance, corporate policies around privacy and sensitive data.
+* Unlimited customization on who can impersonate who, when, depending on whatever context, using our [Rules](/rules) engine. In a Rule, you have access to `user.impersonated` (the impersonated login) and `user.impersonator` (the impersonating login) and you can write arbitrary Javascript to define how it works.
+
+::: note
+Any [Rules](/rules) that you have implemented will run when you impersonate a user, including any actions that update the user.
+:::
+
+::: panel Impersonation does not work with Authorization API
+Impersonation **does not work** with the [API Authorization](/api-auth) features. This means that the `audience` parameter will be ignored, and the [Access Token](/tokens/concepts/overview-access-tokens) returned to applications when using this flow is only valid for requests to [the /userinfo endpoint](/api/authentication#get-user-info). 
+:::
+
+## Impersonation and Login CSRF attacks
+
+To avoid [Login CSRF attacks](/protocols/oauth2/mitigate-csrf-attacks), the OAuth 2.0 specification recommends that applications use the **state** parameter to make sure that the response they receive matches the authentication request and originates from the same session.
+
+However, applications that check for a valid **state** parameter will *not* work with Impersonation, since Impersonation works by sending authenticated responses to applications that never requested authentication. If you are building a single-page application where the authentication results are processed by Lock or Auth0.js, you can disable checking of **state** to allow Impersonation.
+
+::: warning
+Impersonation leaves your application vulnerable to CSRF attacks, since the flag allows the bypassing of the CSRF check from the [state parameter](/protocols/oauth2/oauth-state) if this parameter is missing from the authorization response. By using impersonation, you acknowledge that you understand and accept these risks.
+:::
+
+If you are using [Auth0.js](/libraries/auth0js), you have to update the **webAuth.parseHash** of the [library](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) and set the flag **__enableIdPInitiatedLogin** to `true`.
+
+```javascript
+var data = webAuth.parseHash(
+  {
+    ...
+    __enableIdPInitiatedLogin: true
+    ...
+  }
+```
+
+If you're using [Lock](/lock), you can include the flag using the options parameter sent to the constructor.
+
+```javascript
+const lock = new Auth0Lock(clientID, domain, options)
+```
+
+Here's the flag itself:
+
+```javascript
+var options = {
+    _enableIdPInitiatedLogin: true
+};
+```
+
+Note that the **enableIdPInitiatedLogin** flag is preceded by **one** underscore when used with Lock and **two** underscores when used with the auth0.js library.
+
+## Impersonate users using the Dashboard
+1. Use the Dashboard to log in to your app as a user.
+
+2. Navigate to the [Users](${manage_url}/#/users) page in the Auth0 Dashboard and select the user you want to log in as. Click on the __Sign in as User__ and select the application you want to log in to using the dropdown menu.
+
+![Impersonate a User](/media/articles/user-profile/user2.png)
+
+::: panel I can't see the button
+Can't see the button? The following conditions are required for the button display:
+- The applications registered in the tenant must have at least one callback URL listed.
+- The applications must have the connections that the impersonated user belongs to turned on.
+:::
+
+A popup displays the URL to be used in order to impersonate the user. You can choose either to copy the URL into the clipboard (white button) or open it in a separate browser tab/window (blue button).
+
+3. Copy the URL into the clipboard (white button) or open the URL in a separate browser tab/window (blue button).
+
+![Impersonate a User](/media/articles/user-profile/user3.png)
+
+::: panel Acquiring a token
+Impersonating a user using the [Dashboard](${manage_url}) will not return an [ID Token](/tokens/concepts/id-tokens) to your application by default. There are two ways to achieve this. You can alter the **Response Type** setting in the impersonation menu's [Advanced Settings](#advanced-settings) from `Code` to `Token` (**Sign in as user** -> **Show Advanced Settings**). Alternatively, you can add `additionalParameters.scope: "openid"` to the request body while calling the [impersonation endpoint](/api/authentication/reference#impersonation) manually.
+:::
+
+### Advanced settings
+
+When impersonating a user in Dashboard, after clicking **Sign in as User** you will see a link to expand "Advanced Settings."
+
+![Advanced Settings](/media/articles/user-profile/impersonation-adv.png)
+
+This reveals fields to make it easier to [Impersonate a User Using the Impersonation API](/users/guides/impersonate-users-using-the-impersonation-api):
+
+- **Response mode**: `GET` or `POST`. This is only for server side apps, client side apps default to `GET`.
+- **Response type**: `Code` or `Token`. This is only for server side apps, client side apps default to `Token`.
+- **Scope**: This field will have `openid` in it is as default, [other scopes](/scopes) can be added as a list using whitespace as separator.
+- **State**: The `state` is a required parameter and leaving it blank may lead to errors like `Impersonation - Bad mac`. For more information, see [State Parameter](/protocols/oauth2/oauth-state).
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/impersonate-users-using-the-impersonation-api.md b/ja-jp/articles/users/guides/impersonate-users-using-the-impersonation-api.md
new file mode 100644
index 0000000000..f7b7edc0b7
--- /dev/null
+++ b/ja-jp/articles/users/guides/impersonate-users-using-the-impersonation-api.md
@@ -0,0 +1,190 @@
+---
+description: Learn how to impersonate a user using the Impersonation API.
+sitemap: false
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Impersonate Users Using the Impersonation API
+
+<%= include('../../_includes/_deprecate-impersonation') %>
+
+Use the [Impersonation API](/api/authentication/reference#impersonation) to generate a link that can be used **only once** to log in as a specific user. To distinguish between real logins and impersonation logins, the profile of the impersonated user will also contain additional `impersonated` and `impersonator` properties. 
+
+The following steps assume that you have two apps, `app1` and `app2`, and you want to impersonate the users of `app2`. You will need to locate the `user_id` of the user you wish to impersonate, either via the Dashboard or the Management API. Next, you will need to obtain an authorization code via the impersonation endpoint. Finally, you will need to exchange your code for a valid Access Token, and your impersonation process will be complete. You can walk through the steps below which use the example `app1` and `app2`.
+
+1. Use one of two methods to locate the `user_id` of a given user that you want to impersonate. You can either use the Management API v2 to retrieve it, or you can use the Dashboard.
+
+   - **Option A: Use the Management API**
+     First, you will need an APIv2 token, if you want to retrieve the `user_id` via the Management API. You can get one by making a `POST` request to the [Token endpoint](/api/authentication#client-credentials). For details on how to do that see [Access Tokens for the Management API](/api/management/v2/concepts/tokens).
+
+     The Management APIv2 Token will be valid for 24 hours, so you should ask for a token every time you make a request to the API, or be prepared to handle a high volume of  `401` responses.
+
+     After you have a token, you will have to use the token to retrieve the user id of the user that you want to impersonate (in this example, a user of `app2`). You can retrieve this information with the [Management API /api/v2/users](/api/management/v2#!/Users/get_users) endpoint.
+
+     ```har
+     {
+        "method": "GET",
+        "url": "https://${account.namespace}/api/v2/users",
+        "headers": [
+          { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+        ]
+     }
+     ```
+
+     Replace `YOUR_ACCESS_TOKEN` with the Management APIv2 token you got in the previous step.
+
+   - **Option B: Use the Dashboard**
+     Alternatively, you can retrieve the `user_id` information from the Dashboard. Go to the [Users](${manage_url}/#/users) section and look at the user's profile. The `user_id` is displayed under the **Identity Provider Attributes** section.
+
+2. Get an Authorization Code. Before calling the call the [Impersonation API](/api/authentication/reference#impersonation) you will need to generate a Bearer token. You can generate it with the [Management API V1 /oauth/token endpoint](/api/management/v1#authentication) with your **Global Client ID** and **Global Client Secret** which both can be found in the Dashboard under [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced).
+
+![Global Client Information](/media/articles/user-profile/global-client-info.png)
+
+3. You can now send a request to the [impersonation endpoint](/api/authentication/reference#impersonation) by sending an `Authorization` header with `Bearer `.
+
+   The data part of the request includes the following parameters:
+
+   - `protocol`: The protocol to use against the identity provider. It could be `oauth2` again or something else. (for example, Office 365 uses WS-Federation, G Suite uses OAuth2, AD will use LDAP or Kerberos).
+
+   - `impersonator_id`: The `user_id` of the impersonator, the user from `app1` that wants to impersonate a user from `app2`.
+
+   - `client_id`: The `client_id` of the app that is generating the impersonation link, in this example `app1`.
+
+   - `additionalParameters`: This is a JSON object. For a regular web app, you should set the `response_type` to be `code`, the `callback_url` to be the callback url to which Auth0 will redirect with the authorization code, and the `scope` to be the JWT claims that you want included in the JWT. For example:
+  
+     ```json
+     {
+       "response_type": "code",
+       "state": "",
+       "callback_url" : "http://localhost:3001/register",
+       "scope" : "openid email name user_metadata"
+     }
+     ```
+
+   - `state`: is an optional parameter, but we strongly recommend you use it to [mitigate CSRF attacks](/protocols/oauth2/mitigate-csrf-attacks).
+
+   - `callback_url`: Must match what is defined in your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+   - `scope`: There are various possible values for `scope`:
+
+     - `scope: 'openid'`: _(default)_ Returns an opaque Access Token **and** an [ID Token](/tokens/concepts/id-tokens), which is a JSON Web Token ([JWT](/tokens/concepts/jwts)). The JWT will only contain the user ID (`sub` claim).
+     - `scope: 'openid {attr1} {attr2} {attrN}'`: Returns only specific user's attributes to be part of the [ID Token](/tokens/concepts/id-tokens) (for example, `scope: 'openid name email picture'`).
+
+     For more information, see [Scopes documentation](/scopes).
+
+     ::: note
+     Impersonation cannot be used to return [Access Tokens](/tokens/concepts/overview-access-tokens) to your APIs.
+     :::
+
+     Your request should look like the following:
+
+     ```har
+     {
+       "method": "POST",
+       "url": "https://${account.namespace}/users/USER_ID/impersonate",
+       "headers": [
+         { "name": "Content-Type", "value": "application/json" },
+         { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+       ],
+       "postData": {
+         "mimeType": "application/json",
+         "text": "{\"protocol\": \"PROTOCOL_TO_USE\",\"impersonator_id\": \"IMPERSONATOR_ID\",\"client_id\": \"${account.clientId}\",\"additionalParameters\":{\"response_type\": \"code\",\"state\": \"\"}}"
+       }
+     }
+     ```
+
+4. Replace the required values as follows:
+
+   - `YOUR_USER_ID`: The `user_id` you retrieved at the second step (the user to impersonate)
+   - `YOUR_ACCESS_TOKEN`: The token already retrieved at the first step
+   - `PROTOCOL_TO_USE`: The protocol to use against the identity provider, for example `oauth2`
+   - `IMPERSONATOR_ID`: The `user_id` of the impersonator
+
+   A successful response returns a URL which can be used to authenticate as the user. The URL should look like the following:
+
+   ```text
+   https://${account.namespace}/users/IMPERSONATOR_ID/impersonate?&abc=XYZ123
+   ```
+
+5. Perform a GET request on the URL you received to get a new URL with a `code` and `state` value. The response should look like the following:
+
+   ```text
+   ${account.callback}/?code=AUTHORIZATION_CODE&state=STATE_VALUE
+   ```
+
+   - `${account.callback}` is the URL you specified as `callback_url` (and configured in your [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings))
+   - `state` should match the `state` value you sent with your request
+   - `code` is the authorization code you need
+
+   ::: panel Single-Page Apps
+   The process described applies to regular web apps. In case yours is a single-page app (SPA) you should use `"response_type":"token"` when invoking the [Impersonation API](/api/authentication/reference#impersonation). Auth0 will redirect to your SPA _Callback URL_ with Access Token and ID Token in the `#` params. You can read more on the OAuth 2.0 Implicit flow [here](/protocols/oauth2/oauth-implicit-protocol).
+   :::
+
+6. Exchange the authorization code you received for a token. 
+
+   ::: note
+   This should already be implemented if you have a regular web app and are using the OAuth Server Side flow for authenticating normal users. If not, you should send a `POST` request to the [Token endpoint in Auth0](/api/authentication#authorization-code). You will need to send the authorization code obtained before along with your Client ID and Client Secret.
+   :::
+
+   ```har
+   {
+     "method": "POST",
+     "url": "https://${account.namespace}/oauth/token",
+     "headers": [
+       { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+     ],
+     "postData": {
+        "mimeType": "application/x-www-form-urlencoded",
+        "params": [
+          {
+            "name": "grant_type",
+            "value": "authorization_code"
+          },
+          {
+            "name": "client_id",
+            "value": "${account.clientId}"
+          },
+          {
+            "name": "client_secret",
+            "value": "YOUR_CLIENT_SECRET"
+          },
+          {
+            "name": "code",
+            "value": "YOUR_AUTHORIZATION_CODE"
+          },
+          {
+            "name": "redirect_uri",
+            "value": "${account.callback}"
+          }
+        ]
+     }
+   }
+   ```
+
+7. Replace the `AUTHORIZATION_CODE` with the `code` you received previously. Also, replace `${account.callback}` with your application's callback URL. 
+
+   If the request is successful, you will get a JSON object with an Access Token. You can use this token to call the Auth0 APIs and get additional information such as the user profile.
+
+   ```json
+   HTTP/1.1 200 OK
+   Content-Type: application/json
+   {
+     "access_token":"eyJz93a...k4laUWw",
+     "id_token":"eyJ0XAi...4faeEoQ",
+     "token_type":"Bearer",
+     "expires_in":86400
+   }
+   ```
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/link-user-accounts-auth-api.md b/ja-jp/articles/users/guides/link-user-accounts-auth-api.md
new file mode 100644
index 0000000000..6de0c67af4
--- /dev/null
+++ b/ja-jp/articles/users/guides/link-user-accounts-auth-api.md
@@ -0,0 +1,129 @@
+---
+description: How to link accounts using the Authentication API (Deprecated)
+public: false
+topics:
+  - authentication-api
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+
+# Link Accounts using Authentication API (Deprecated)
+
+::: warning
+This method of linking accounts using the linking endpoint of the [Authentication API](/api/authentication#link), either through **Lock** or by manually calling the API, is **deprecated** and should no longer be used. The [POST /api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) should be used instead. For more information refer to the [Migration Notice](/migrations/past-migrations#account-linking-removal).
+:::
+
+## Link through Auth0 Login Widget
+
+```js
+
+
+
+Add account
+```
+
+::: note
+Notice the `access_token` fragment of the URL that is normally not present. Auth0 generates this `access_token` when a user logs in and uses it to uniquely identify the user.
+:::
+
+## Manual initiation
+
+The following example will manually initiate the authentication transaction:
+
+`https://${account.namespace}/authorize?response_type=code&scope=openid`
+`&client_id=${account.clientId}`
+`&redirect_uri=${account.callback}`
+`&access_token=...LOGGED_IN_USER_ACCESS_TOKEN...`
+
+## Obtain an authenticated user's *access_token*
+
+The SDK for your platform should make the `access_token` available in simplest way for your platform. For example:
+
+* If you are using Lock in [Popup Mode](/libraries/lock/v10/popup-mode) in a SPA, the `access_token` is available as a callback parameter:
+
+  ```js
+  var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+
+  lock.show(function(err, profile, id_token, access_token) {
+    //save access_token here for linking other accounts
+  })
+  ```
+
+* If you are using [passport-auth0](https://github.com/auth0/passport-auth0) in a regular Node.js web app, the `access_token` is available in the `strategy` callback and can be saved to the session for later use:
+
+  ```js
+  var Auth0Strategy = require('passport-auth0'),
+      passport = require('passport');
+
+  var strategy = new Auth0Strategy({
+     domain:       '${account.namespace}',
+     clientID:     '${account.clientId}',
+     clientSecret: 'YOUR_CLIENT_SECRET',
+     callbackURL:  '${account.callback}',
+     passReqToCallback: true //need this to save the accessToken to session
+    },
+    function(req, accessToken, refreshToken, extraParams, profile, done) {
+      // save accessToken to session to be able to link accounts later
+      req.session.accessToken = accessToken;
+      // profile has all the information from the user
+      return done(null, profile);
+    }
+  );
+
+  passport.use(strategy);
+  ```
+
+* If you are using ASP.NET, the `access_token` is available as a claim:
+
+  ```
+  ${'<%= ClaimsPrincipal.Current.FindFirst("access_token").Value %>'}
+  ```
+
+* If you are building your own implementation, the `access_token` will be available through the standard OAuth2 flow:
+
+  1. User logs in and returns to the app with a `code`
+  2. The app exchanges the `code` for the `access_token`
+
+  The details of these exchanges are available at [Identity Protocols supported by Auth0](/protocols).
+
+## Unlinking Accounts
+
+To unlink a specific account, POST request to the following url:
+
+`https://${account.namespace}/unlink`
+
+The body should be:
+
+```
+{
+    access_token: "LOGGED_IN_USER_ACCESS_TOKEN", // Primary identity access_token
+    user_id: "LINKED_USER_ID" // (provider|id)
+}
+```
+
+## Keep reading
+
+* [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/ja-jp/articles/users/guides/link-user-accounts.md b/ja-jp/articles/users/guides/link-user-accounts.md
new file mode 100644
index 0000000000..8de250860c
--- /dev/null
+++ b/ja-jp/articles/users/guides/link-user-accounts.md
@@ -0,0 +1,188 @@
+---
+title: Link User Accounts
+description: Learn how to link user accounts from various identity providers, so your users can authenticate from any of their accounts and still be recognized by your app and associated with the same user profile.
+topics:
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+# Link User Accounts
+
+Link user accounts together to form a primary and secondary relationship. On successful linking, the endpoint returns the new array of the primary account identities. 
+
+Auth0 supports the linking of user accounts from various identity providers. This allows a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. This feature requires a paid subscription to the **Developer**, **Developer Pro** or **Enterprise** plan (see [Pricing](https://auth0.com/pricing)).
+
+::: note
+Auth0 treats all identities as separate by default. For example, if a user logs in first against the Auth0 database and then via Google or Facebook, these two attempts would appear to Auth0 as two separate users.
+:::
+
+There are three ways to link accounts:
+
+* Use the Account Link extension
+* Use the Management API 
+* Use Auth0.js 
+
+Use the tabs below to see the details for each option.
+
+
    
+  
    
+    
+  
    
+  
    
+    
    
+
+## Account Link extension
+
+Install and configure the [Account Link Extension](/extensions/account-link) extension in the Dashboard to prompt users that may have created a second account to link the new account with their old one on their first login. The user can choose to either link the two accounts or keep them separate if it was intentional.
+    
    
+    
    
+
+## Management API endpoint
+
+The Auth0 Management API provides the [Link a user account](/api/v2#!/Users/post_identities) endpoint, which can be invoked in two ways:
+
+* User initiated account linking using Access Tokens with the `update:current_user_identities` scope
+* Server-side account linking using Access Token that contains the `update:users` scope
+
+### User initiated client-side account linking 
+
+For user initiated account linking from client-side code, use an Access Token that contains the following items in the payload:
+- `update:current_user_identites` scope
+- `user_id` of the primary account as part of the URL
+- ID Token of the secondary account must be signed with `RS256` and an `aud` claim identifying the client that matches the value of the requesting Access Token's `azp` claim. 
+
+An Access Token that contains the `update:current_user_identities` scope can **only** be used to update the information of the currently logged-in user. Therefore, this method is suitable for scenarios where the user initiates the linking process.
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+### Server-side account linking 
+
+For server-side account linking, use an Access Token that contains the following items in the payload:
+- `update:users` scope
+- `user_id` of the primary account as part of the URL
+- `user_id` of the secondary account 
+- ID Token of the secondary account must be signed with `RS256` and an `aud` claim identifying the client that matches the value of the requesting Access Token's `azp` claim. 
+
+Access Tokens that contain the `update:users` scope can be used to update the information of **any** user. Therefore, this method is intended for use in server-side code only.
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"provider\":\"SECONDARY_ACCOUNT_PROVIDER\", \"user_id\": \"SECONDARY_ACCOUNT_USER_ID\"}"
+  }
+}
+```
+
+The `SECONDARY_ACCOUNT_USER_ID` and `SECONDARY_ACCOUNT_PROVIDER` can be deduced by the unique ID of the user. For example, if the user ID is `google-oauth2|108091299999329986433`, set the `google-oauth2` part as the `provider`, and the `108091299999329986433` part as the `user_id` at your request.
+
+Instead of the `provider` and `user_id`, you can send the secondary account's ID Token as part of the payload:
+
+```js
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities",
+  "httpVersion": "HTTP/1.1",
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ACCESS_TOKEN"
+  },
+  {
+    "name": "content-type",
+    "value": "application/json"
+  }],
+  "postData" : {
+    "mimeType": "application/json",
+    "text": "{\"link_with\":\"SECONDARY_ACCOUNT_ID_TOKEN\"}"
+  }
+}
+```
+
+  
    
+  
    
+
+## Auth0.js library
+
+You can use the [Auth0.js](/libraries/auth0js) library.
+
+First, you must get an Access Token that can be used to call the Management API. You can do it by specifying the `https://${account.namespace}/api/v2/` audience when initializing Auth0.js. You will get the Access Token as part of the authentication flow. Alternatively, you can use the `checkSession` method.
+
+Once you have the Access Token, you can create a new `auth0.Management` instance by passing it the account's Auth0 domain, and the Access Token.
+
+For more information and sample scripts, see [Auth0.js > User management](/libraries/auth0js/v9#user-management).
+    
    
+  
    
+
    
+
+## Add missing information with Rules
+
+When a user logs in, apps receive user information from the **primary identity**. Auth0 does not attempt to automatically complete missing profile fields with information from the secondary identities. For example, if the primary identity comes from a database connection and is missing the `given_name` and `family_name` properties, and the secondary identity comes from a Google social connection that includes the first and last name of the user, then the application will **not** receive data contained in the second identity.
+
+To add missing information to primary identities with information from secondary identities, you can write a [rule](/rules) like the following example:
+
+```js
+function(user, context, callback) {
+  
+  const propertiesToComplete = ["given_name", "family_name", "name"];
+
+  // go over each property and try to get missing
+  // information from secondary identities
+  for(var property of propertiesToComplete) {
+    if (!user[property]) {
+      for(var identity of user.identities) {
+        if (identity.profileData && identity.profileData[property]) {
+          user[property] = identity.profileData[property];
+          break;
+        }
+      }
+    }
+  }
+  
+  callback(null, user, context);
+}
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/ja-jp/articles/users/guides/manage-user-access-to-applications.md b/ja-jp/articles/users/guides/manage-user-access-to-applications.md
new file mode 100644
index 0000000000..f16c8845b8
--- /dev/null
+++ b/ja-jp/articles/users/guides/manage-user-access-to-applications.md
@@ -0,0 +1,30 @@
+---
+description: Explains the basics of a user profile, how to create a user and view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+---
+# Manage User Access to Applications
+
+All users associated with a single Auth0 tenant are shared between the tenant's applications (and therefore have access to the applications). To keep users separate and restrict their access, we recommend creating an additional tenant:
+
+1. Click on tenant name on top right of the dashboard and select **+ Create Tenant** . If you have multiple tenants, you can easily switch between them from the tenants menu.
+
+2. To restrict some users' access to certain applications, you can use [rules](/rules). Inside a rule, the `context.clientName` and `context.clientID` variables are available to check which application the user is using for login. See [this rule for an example](https://github.com/auth0/rules/blob/aeaf93bc058408e260192d0941a688963449d6be/src/rules/simple-user-whitelist-for-app.js).
+
+3. To restrict users from applications by configuring a new connection and only giving access to a specific application. 
+
+   * Go to the the **Settings** section for a connection.
+   * Click on the **Applications** tab and enable/disable any application.
+
+4. To disable users' access to your applications, you can [block and unblock users](/users/guides/block-and-unblock-users) in the Dashboard.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [Update Users Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/ja-jp/articles/users/guides/manage-user-metadata.md b/ja-jp/articles/users/guides/manage-user-metadata.md
new file mode 100644
index 0000000000..79b85743c9
--- /dev/null
+++ b/ja-jp/articles/users/guides/manage-user-metadata.md
@@ -0,0 +1,70 @@
+---
+description: How to create and update metadata using the Auth0 APIs and Lock and how to work with custom databases.
+toc: true
+crews: crew-2
+topics:
+  - metadata
+  - apis
+  - management-api
+contentType: how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Manage User Metadata
+
+You can create and update metadata using [Rules](/rules/current/metadata-in-rules), the [Authentication API](/api/authentication), the [Management API](/api/management/v2), and the [Lock](/libraries/lock) library.
+
+## Rules
+
+[Rules](/rules) are JavaScript functions executed as part of the Auth0 authentication process (prior to authorization). Using rules, you can read, create, or update user metadata and have such changes affect the results of the authorization process. 
+
+For more information and examples, see [User Metadata in Rules](/rules/current/metadata-in-rules).
+
+## Authentication API
+
+If you have a [custom database connection](/connections/database#using-your-own-user-store), you can use the [Authentication API](/api/authentication) [Signup](/api/authentication?shell#signup) endpoint to set the `user_metadata` for a user. For an example of working with metadata during a custom signup process, see [Custom Signup > Using the API](/libraries/custom-signup#using-the-api).
+
+<%= include('../../_includes/_metadata_on_signup_warning') %>
+
+You can also use the [GET /userinfo endpoint](/api/authentication#get-user-info) to get a user's `user_metadata`, however you must first [write a Rule](/rules/guides/metadata) to copy `user_metadata` properties to the ID Token.
+
+## Management API
+
+Use the following [Management API](/api/management/v2) endpoints to view, create, update, and delete the `user_metadata` and `app_metadata` fields.
+
+| **Task** | **Endpoint** | **Scope** | 
+| -- | -- | -- |
+| View | [`GET /api/v2/user/{id}`](/api/management/v2#!/Users/get_users_by_id) | `read:current_user_metadata` | 
+| Create | [`PATCH /api/v2/users/{id}`](/api/management/v2#!/Users/post_users) | `create:current_user_metadata` |
+| Update | [`PATCH /api/v2/users/{id}`](/api/management/v2#!/Users/patch_users_by_id) | `update:current_user_metadata` | 
+| Delete | [`DELETE /api/v2/users/{id}/multifactor/{provider}`](/api/management/v2#!/Users/delete_multifactor_by_provider) | `delete:current_user_metadata` | 
+
+::: note
+The Auth0 Management APIv2 token is required to call the Auth0 Management API. Learn more about [Access Tokens for the Management API](/api/management/v2/tokens) and [Get Management API Tokens for SPAs](/api/management/v2/get-access-tokens-for-spas).
+:::
+
+## Lock library
+
+You can define, add, read, and update the `user_metadata` using Auth0's [Lock](/libraries/lock) library. For information on adding `user_metadata` on signup, see [Additional Signup Fields](/libraries/lock/v10/customization#additionalsignupfields-array-).
+
+When using Lock, you can read the user's `user_metadata` properties the same way you would for any other user profile property. For example, the following code snippet retrieves the value associated with `user_metadata.hobby` and assigns it to an element on the page:
+
+```js
+// Use the accessToken acquired upon authentication to call getUserInfo
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    document.getElementById('hobby').textContent = profile.user_metadata.hobby;
+  }
+});
+```
+
+## Keep reading
+
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Metadata Best Practices](/best-practices/metadata-best-practices)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
diff --git a/ja-jp/articles/users/guides/manage-users-using-the-dashboard.md b/ja-jp/articles/users/guides/manage-users-using-the-dashboard.md
new file mode 100644
index 0000000000..865cef7e1b
--- /dev/null
+++ b/ja-jp/articles/users/guides/manage-users-using-the-dashboard.md
@@ -0,0 +1,34 @@
+---
+description: Describes how to manage users in the Auth0 Dashboard.
+crews: crew-2
+topics:
+  - dashboard
+  - users
+contentType: how-to
+useCase:
+  - manage-users
+v2: True
+---
+
+# Manage Users Using the Dashboard
+
+You can use the Dashboard to manage your users. To begin, go to [Dashboard > Users](${manage_url}/#/users). This is where you'll go to create, view, modify, or delete users.
+
+::: note
+User Management is included as part of the **Developer** subscription plan. You may need to [upgrade your plan](${manage_url}/#/tenant/billing/subscription) to access these features.
+:::
+
+::: warning
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+:::
+
+![User Profile Dashboard](/media/articles/user-profile/user1.png)
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [View Users](/users/guides/view-users)
+* [Manage User Access to Applications](/users/guides/manage-user-access-to-applications)
+* [Manage Users Using the Management API](/users/guides/manage-users-using-the-management-api)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
+* [User Search](/users/search)
diff --git a/ja-jp/articles/users/guides/manage-users-using-the-management-api.md b/ja-jp/articles/users/guides/manage-users-using-the-management-api.md
new file mode 100644
index 0000000000..c1ede2f52b
--- /dev/null
+++ b/ja-jp/articles/users/guides/manage-users-using-the-management-api.md
@@ -0,0 +1,48 @@
+---
+description: Explains the basics of a user profile, how to create a user and view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+# Manage Users Using the Management API
+
+In addition to using the Dashboard, you can retrieve, create, update or delete users using our [Management API](/api/management/v2#!/Users/get_users).
+
+## How to manage users
+
+If you want to call the Management API directly, you will first need to generate the appropriate Access Token. For information on how to do that refer to [Access Tokens for the Management API](/api/management/v2/tokens).
+
+Alternatively, you can use an SDK to implement the functionality you need to call the Management API from your application. For a list of available SDKs, refer to [the SDKs section of our Support Matrix](/support/matrix#sdks).
+
+::: note
+You can setup Access Control List (ACL)/Roles functionality using our [Role-based Access Control (RBAC)](/authorization/concepts/rbac).
+:::
+
+## Limitations
+
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+
+### Set passwords
+
+The password can be set via the `create` or `update` calls, but for security purposes, it cannot be viewed via the `get` or `list user` commands. The right side of the API explorer provides hints on the user profile attributes which can be viewed or modified for any given call.
+
+## Endpoints
+
+* You can use the [`/users`](/api/v2#!/Users/get_users) endpoint to retrieve information about all users. You can also include search criteria to find specific users.
+
+* Use the [`/user_id`](/api/v2#!/Users/get_users_by_id) to retrieve information about one user based on the `user_id`. The `user_id` is an internal identifier that consists of a connection name and a unique identifier for the user. The `user_id` is different from the ID Token.
+
+* The [`/userinfo`](/api/authentication/reference#get-user-info) endpoint takes as input the Auth0 Access Token and returns user profile information. This endpoint will include the results of any rules that may have altered the user profile during the authentication transaction, but the resulting user profile will not be filtered by any [Scoping](#scopes).
+
+* The [`/tokeninfo`](/api/authentication/reference#get-token-info) endpoint takes as input the Auth0 ID Token and returns User Profile information. This endpoint will return a result that does not include the results of any rules that alter the User Profile.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/read-metadata.md b/ja-jp/articles/users/guides/read-metadata.md
new file mode 100644
index 0000000000..6392c91e8c
--- /dev/null
+++ b/ja-jp/articles/users/guides/read-metadata.md
@@ -0,0 +1,75 @@
+---
+description: Retrieve metadata using the Management API or Lock.
+topics: 
+   - metadata
+   - rules
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Read Metadata
+
+You can read metadata using rules with the Management API and with Lock. You can also search for profile-related information in `user_metadata`, such as:
+
+- `name`
+- `nickname`
+- `given_name`
+- `family_name`
+
+<%= include('../_includes/_connection-synch-note.md') %>
+
+::: note 
+When using the deprecated [Search v2](/users/search/v2), beginning **1 September 2017** new tenants cannot search any of the  `app_metadata` fields. Only tenants associated with paid subscriptions that were created on/before **31 August 2017** can search the `app_metadata` fields.
+This limitation does not apply to [Search v3](/users/search/v3).
+:::
+
+As an example, assume the following metadata is stored for a user with the email address `jane.doe@example.com`:
+
+```json
+{
+    "emails": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+## Read metadata with the Management API
+
+Using the example metadata above, you can refer to specific items from the dataset in [Rules](/rules) or via a call to the [Management API](/users/guides/manage-user-metadata) as follows:
+
+```js
+console.log(user.email); // "jane.doe@example.com"
+console.log(user.user_metadata.hobby); // "surfing"
+console.log(user.app_metadata.plan); // "full"
+```
+Any valid JSON snippet can be used as metadata.
+
+::: note
+In Management APIv1, all metadata is stored in the `metadata` field. Data stored in this field is **now** available from the Management APIv2 as `app_metadata`.
+:::
+
+## Read metadata with Lock
+
+Using the Lock library, you can read the user's `user_metadata` properties the same way you would read any other user profile property. This example retrieves the value associated with `user_metadata.hobby` using the example user metadata listed above:
+
+```js
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    document.getElementById('hobby').textContent = profile.user_metadata.hobby;
+  }
+});
+```
+
+For details on how to initialize `lock` refer to [Auth0Lock(clientID, domain, options)](https://github.com/auth0/lock#new-auth0lockclientid-domain-options).
+
+## Keep Reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
diff --git a/ja-jp/articles/users/guides/redirect-users-after-login.md b/ja-jp/articles/users/guides/redirect-users-after-login.md
new file mode 100644
index 0000000000..72258e9615
--- /dev/null
+++ b/ja-jp/articles/users/guides/redirect-users-after-login.md
@@ -0,0 +1,64 @@
+---
+description: How to redirect users to URLs that have not been whitelisted
+topics:
+  - users
+  - user-management
+  - redirection
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Redirect Users After Login Authentication
+
+You can return users to specific pages (URLs) within your application after validating their ID Tokens (authentication). To see an example of how this works, try the [React: Login Quickstart](/quickstart/spa/react). 
+
+## Redirect users to whitelisted callback URLs
+
+Because callback URLs can be manipulated by unauthorized parties, Auth0 recognizes only whitelisted URLs set in the **Allowed Callback URLs** field of an [Application's Settings](${manage_url}/#/applications/${account.clientId}/settings) as valid. To return users to whitelisted callback URLs, it is necessary for your application to know how to continue the user on their journey. 
+
+There are two methods for doing this:
+
+* Using cookies and browser sessions
+* Using `state` parameters
+
+During a user's authentication, the `redirect_uri` request parameter is used as a callback URL. This is where your application receives and processes the response from Auth0, and is often the URL to which users are redirected once the authentication is complete. For more information on how the `redirect_uri` works, see [OAuth 2.0](/protocols/oauth2).
+
+### Use cookies or browser sessions
+
+You can use a cookie or the browser session to store a return URL value. This is a simple solution to implement, however it can cause issues in cases where a cookie does not persist. There are two separate user sessions initiated in this situation. Each serves a separate purpose and requires some consideration to achieve the desired user experience.
+
+* **Auth0-provided OIDC SSO Session**: Auth0 provides a session for enabling [OIDC Single Sign On (SSO)](/api-auth/tutorials/adoption/single-sign-on) to allow your user to maintain an authentication session without being prompted for credentials more than once. This session is maintained by Auth0 and referenced as a cookie bound to your tenant domain (or `CNAME`). There are two [tenant settings](/sso/current/configure-session-lifetime-limits) that determine the length of the Auth0 Session:
+  - The `idle_session_lifetime` is how long the session will remain alive without interaction.  
+  - The `session_lifetime` is the maximum duration that the session is allowed to remain alive. 
+  
+  These settings apply to all applications within your tenant and should be configured to align with the security model that matches your use case.  
+
+* **Application Session**: Your application must also maintain a concept of session.  Throughout the user session, your application may need to request additional tokens or renew expired ones. You should store these tokens in your application and reference them using an identifier passed back to the browser using a secure cookie. 
+
+Once your user has authenticated with Auth0 it is up to your application to determine how long it persists this session.
+
+### Use `state` parameters
+
+As an alternative method, you can create a [deep link using the `state` parameter](/protocols/oauth2/redirect-users) which your callback would interpret to determine a forwarding path. This solution takes a little more work to implement but guarantees that the application has the information it needs once the redirect is complete. 
+
+In essence, you send a random value when starting an authentication request and validate the received value when processing the response (this implies you store something on the client application side, in session or other medium, that allows you to perform the validation). If you receive a response with a state that does not match, you were likely the target of an attack because this is either a response for an unsolicited request or someone trying to forge a response.
+
+Your application type determines the best place to keep the data that allows your app to validate the response. For example, assuming a pregressive web app is leveraging a SPA framework then it could store this in local storage while a traditional web app framework would store it in server-side session.
+
+## Redirect users to other URLs
+
+Sometimes, the callback URL is not necessarily where you want users redirected after authentication. For example, if a user intends to access a protected page in your application, and that action triggers the request to authenticate, you can store that URL to redirect the user back to their intended page after the authentication finishes. Store the desired URL using the following methods:
+
+* [Redirect users with state parameters](/protocols/oauth2/redirect-users)
+* [Redirect users from within rules](/rules/current/redirect)
+
+Choose the option that works best for your application type and the type of [flow](/api-auth/which-oauth-flow-to-use) that you are using. Create the necessary logic in your application to retrieve the stored URL and redirect your users where you want them to go. The [Auth0 SDKs](/libraries/auth0js/v9#available-parameters) also include support for redirect URLs.
+  
+## Keep reading
+
+* [Progressive Profiling](/users/concepts/overview-progressive-profiling)
+* [Redirect Users After Logout](/logout/guides/redirect-users-after-logout)
+* [Redirect Rule Best Practices](/best-practices/rules#redirection)
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [API Authorization](/api-auth)
diff --git a/ja-jp/articles/users/guides/set-metadata-properties-on-creation.md b/ja-jp/articles/users/guides/set-metadata-properties-on-creation.md
new file mode 100644
index 0000000000..4568835620
--- /dev/null
+++ b/ja-jp/articles/users/guides/set-metadata-properties-on-creation.md
@@ -0,0 +1,60 @@
+---
+description: Describes how to set metadata properties on creation using the Management API.
+topics: metadata
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Set Metadata Properties on Creation
+
+To create a user with the following profile details:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+Make the following `POST` call to the [Create User endpoint of the Management API](/api/management/v2#!/Users/post_users), to create the user and set the property values:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/api/v2/users",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"email\": \"jane.doe@example.com\", \"user_metadata\": {\"hobby\": \"surfing\"}, \"app_metadata\": {\"plan\": \"full\"}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+::: panel Define User Metadata on Signup
+For information on adding `user_metadata` on signup, see the section on Lock [Additional Signup Fields](/libraries/lock/v10/customization#additionalsignupfields-array-)
+:::
+
+## Keep Reading
+
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Update Metadata with the Management API](users/guides/update-metadata-properties-with-management-api)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
\ No newline at end of file
diff --git a/ja-jp/articles/users/guides/unlink-user-accounts.md b/ja-jp/articles/users/guides/unlink-user-accounts.md
new file mode 100644
index 0000000000..1604457605
--- /dev/null
+++ b/ja-jp/articles/users/guides/unlink-user-accounts.md
@@ -0,0 +1,182 @@
+---
+title: Unlink User Accounts
+description: Learn how to use the Management API Unlink a User Account endpoint to unlink an identity from the target user account making it a separate user account again.
+topics:
+  - account-linking
+contentType:
+  - how-to
+useCase:
+  - manage-accounts
+---
+# Unlink User Accounts
+
+Use the Auth0 Management API [Unlink a user account](/api/management/v2#!/Users/delete_user_identity_by_user_id) endpoint or the Auth0.js library to unlink an identity from the target user account making it a separate user account again. 
+
+The result of the unlinking process is the following:
+* The secondary account is removed from the identities array of the primary account.
+* A new secondary user account is created.
+* The secondary account will have no metadata.
+
+::: note
+If your goal is to delete the secondary identity entirely, you must first unlink the accounts, and then [delete the newly created secondary account](/users/guides/delete-users).
+:::
+
+Depending on from where you call the endpoint, use one of these two scopes:
+
+* `update:current_user_identities` from [client-side code](/users/references/link-accounts-client-side-scenario)
+* `update:users` from [server-side code](/users/references/link-accounts-server-side-scenario)
+
+The endpoint uses the following parameters:
+
+| Parameter | Type | Description |
+| -- | -- | -- | 
+| `id` | `string` | ID of the primary user account (required) |
+| `provider` | `string` | identity provider name of the secondary linked account (e.g. `google-oauth2`) |
+| `user_id` | `string` | ID of the secondary linked account (e.g. `123456789081523216417` part after the `|` in `google-oauth2|123456789081523216417`) |
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Response example
+
+```js
+[
+  {
+    "connection": "Initial-Connection",
+    "user_id": "5457edea1b8f22891a000004",
+    "provider": "auth0",
+    "isSocial": false,
+    "access_token": "",
+    "profileData": {
+      "email": "",
+      "email_verified": false,
+      "name": "",
+      "username": "johndoe",
+      "given_name": "",
+      "phone_number": "",
+      "phone_verified": false,
+      "family_name": ""
+    }
+  }
+]
+```
+
+## Use JWT from the primary account
+
+To unlink accounts, call the Management API [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using the JWT from the primary account for authorization:
+
+```js
+function unlinkAccount(secondaryProvider, secondaryUserId){
+  var primaryUserId = localStorage.getItem('user_id');
+  var primaryJWT = localStorage.getItem('id_token');
+  $.ajax({
+    type: 'DELETE',
+    url: 'https://' + '${account.namespace}' + '/api/v2/users/' + primaryUserId +
+         '/identities/' + secondaryProvider + '/' + secondaryUserId,
+    headers: {
+      'Authorization': 'Bearer ' + primaryJWT
+    }
+  }).then(function(identities){
+    alert('unlinked!');
+    showLinkedAccounts(identities);
+  }).fail(function(jqXHR){
+    alert('Error unlinking Accounts: ' + jqXHR.status + ' ' + jqXHR.responseText);
+  });
+}
+```
+
+## Use Access Token with the `update:users` scope
+
+If you need to unlink two or more user accounts, call the Management API [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using an [Management API Access Token](/api/v2/tokens) with the `update:users` scope.
+
+```js
+function unlinkAccount(secondaryProvider, secondaryUserId) {
+  var primaryUserId = localStorage.getItem('user_id');
+  var primaryAccessToken = localStorage.getItem('access_token');
+
+  // Uses the Access Token of the primary user as a bearer token to identify the account
+  // which will have the account unlinked to, and the user id of the secondary user, to identify
+  // the user that will be unlinked from the primary account.
+
+  $.ajax({
+    type: 'DELETE',
+    url: 'https://' + AUTH0_DOMAIN +'/api/v2/users/' + primaryUserId +
+         '/identities/' + secondaryProvider + '/' + secondaryUserId,
+    headers: {
+      'Authorization': 'Bearer ' + primaryAccessToken
+    }
+  }).then(function(identities){
+    alert('unlinked!');
+    showLinkedAccounts(identities);
+  }).fail(function(jqXHR){
+    alert('Error unlinking Accounts: ' + jqXHR.status + ' ' + jqXHR.responseText);
+  });
+}
+```
+
+## Unlink accounts from server-side code
+
+1. Update the user in session with the new array of identities (each of which represent a separate user account).
+
+    ```js
+    const ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn();
+    const Auth0Client = require('../Auth0Client');
+    const express = require('express');
+    const router = express.Router();
+    ...
+    router.post('/unlink-accounts/:targetUserProvider/:targetUserId',ensureLoggedIn, (req,res,next) => {
+      Auth0Client.unlinkAccounts(req.user.id, req.params.targetUserProvider, req.params.targetUserId)
+      .then( identities => {
+        req.user.identities = req.user._json.identities = identities;
+        res.send(identities);
+      })
+      .catch( err => {
+        console.log('Error unlinking accounts!',err);
+        next(err);
+      });
+    });
+    ```
+
+2. Call the Management API v2 [Unlink a User Account endpoint](/api/v2#!/Users/delete_user_identity_by_user_id) using an [Management API Access Token](/api/v2/tokens) with the `update:users` scope.
+
+    ```js
+    const request = require('request');
+
+    class Auth0Client {
+      ...
+      unlinkAccounts(rootUserId, targetUserProvider, targetUserId){
+        return new Promise((resolve,reject) => {
+          var reqOpts = {
+            method: 'DELETE',
+            url: 'https://${account.namespace}/api/v2/users/' + rootUserId +
+                '/identities/' + targetUserProvider + '/' + targetUserId,
+            headers: {
+              'Authorization': 'Bearer ' + process.env.AUTH0_APIV2_TOKEN
+            }
+          };
+          request(reqOpts,(error, response, body) => {
+            if (error) {
+              return reject(error);
+            } else if (response.statusCode !== 200) {
+              return reject('Error unlinking accounts. Status: '+ response.statusCode + ' ' + JSON.stringify(body));
+            } else {
+              resolve(JSON.parse(body));
+            }
+          });
+        });
+      }
+    }
+
+    module.exports = new Auth0Client();
+    ```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Account Link Extension](/extensions/account-link)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
+
+* [Migration Guide: Account Linking and ID Tokens](/migrations/guides/account-linking)
diff --git a/ja-jp/articles/users/guides/update-metadata-properties-with-management-api.md b/ja-jp/articles/users/guides/update-metadata-properties-with-management-api.md
new file mode 100644
index 0000000000..766b76747c
--- /dev/null
+++ b/ja-jp/articles/users/guides/update-metadata-properties-with-management-api.md
@@ -0,0 +1,153 @@
+---
+description: Learn how to update user metadata with the Management API.
+crews: crew-2
+topics:
+  - metadata
+  - lock
+contentType: how-to
+useCase: manage-users
+v2: true
+---
+
+# Update Metadata with the Management API
+
+You can update a user's metadata by making a `PATCH` call to the [Update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint.
+
+Assuming you created a user with the following metadata values:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing"
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+To update `user_metadata` and add the user's home address as a second-level property:
+
+```json
+{
+    "addresses": {
+        "home": "123 Main Street, Anytown, ST 12345"
+    }
+}
+```
+
+You would make the following `PATCH` call:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"addresses\": {\"home\": \"123 Main Street, Anytown, ST 12345\"}}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+The user's profile will now appear as follows:
+
+```json
+{
+    "email": "jane.doe@example.com",
+    "user_metadata": {
+        "hobby": "surfing",
+        "addresses": {
+            "home": "123 Main Street, Anytown, ST 12345"
+        }
+    },
+    "app_metadata": {
+        "plan": "full"
+    }
+}
+```
+
+::: warning
+When you send a `PATCH` call in which you have set a property's value to `null` (for example, `{user_metadata: {color: null}}`), Auth0 **deletes** the property/value from the database. Also, patching the metadata itself with an empty object removes the metadata completely (see [Deleting](#deleting)).
+:::
+
+## Merge properties
+
+Only properties at the root level are merged into the object. All lower-level properties will be replaced.
+
+For example, to add a user's work address as an additional inner property, you would have to include the complete contents of the `addresses` property. Since the `addresses` object is a root-level property, it will be merged into the final JSON object representing the user, but its sub-properties will not.
+
+```json
+{
+  "user_metadata": {
+    "addresses": {
+      "home": "123 Main Street, Anytown, ST 12345",
+      "work": "100 Industrial Way, Anytown, ST 12345"
+    }
+  }
+}
+```
+
+Therefore, the corresponding `PATCH` call to the API would be:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://YOURACCOUNT.auth0.com/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer ABCD"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"addresses\": {\"home\": \"123 Main Street, Anytown, ST 12345\", \"work\": \"100 Industrial Way, Anytown, ST 12345\"}}}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+## Delete properties
+
+Patching the metadata with an empty object removes the metadata completely. For example, sending this body removes everything in `app_metadata`:
+
+```json
+{
+  "app_metadata": {}
+}
+```
+
+Similarly, this clears out `user_metadata`:
+
+```json
+{
+  "user_metadata": {}
+}
+```
+
+## Keep reading
+
+* [Access Tokens for the Management API](/api/management/v2/concepts/tokens)
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Read Metadata](/users/guides/read-metadata)
+* [Set Metadata Properties on Creation](/users/guides/set-metadata-properties-on-creation)
diff --git a/ja-jp/articles/users/guides/update-user-profiles-using-your-database.md b/ja-jp/articles/users/guides/update-user-profiles-using-your-database.md
new file mode 100644
index 0000000000..2bd4d91c41
--- /dev/null
+++ b/ja-jp/articles/users/guides/update-user-profiles-using-your-database.md
@@ -0,0 +1,70 @@
+---
+description: Learn how to update user profiles when using your own database as an identity provider.
+topics:
+    - updating-users
+    - user-management
+    - users
+    - custom-database
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+
+# Update User Profiles Using Your Database
+
+Update user profiles when using [your own database as an identity provider](/connections/database/custom-db) by doing the following tasks:
+
+* Use the [Management API](/api/management/v2#!/Users/patch_users_by_id).
+* Update the user in your database.
+* [Configure user migration](/users/guides/configure-automatic-migration) from your database to Auth0.
+
+## Update users with the Management API
+
+When using your own database for authentication, you can use the [Management API](/api/management/v2) to update the following fields:
+
+* `app_metadata`
+* `user_metadata`
+* `blocked`
+
+If you need to update other user fields, you will need to do it directly in your database.
+
+## Update users in your database
+
+You can update user profiles in your database as you normally do, and Auth0 will update its cached user profile the next time that user logs in.
+
+The user profile in the custom database can be implemented with any user profile structure, but you need to map it in the Login call to the Auth0 normalized user profile attributes as shown in the "Login" custom database template. 
+
+Access the custom database templates are accessed via
+*Connections* -> *Database* -> *Custom Database*. Be sure to turn on the "Use my own database" toggle to enable editing the scripts.
+
+See the [User profile cache](#user-profile-cache) section below for a brief overview of how Auth0 caches user profiles.
+
+## Update users through migration
+
+If you have [enabled user migration](/connections/database/migrating), and a user has already been migrated to the Auth0 database, then Auth0 will not query your database again for the user profile. Therefore, all changes made in the custom database for that user will never reflect in Auth0.
+
+Once a user has been migrated, you will also be able to update fields, such as `name`, `nickname`, `given_name`, `family_name`, `picture`, `email`, and `email_verified` via the Management API.
+
+However, rules for updating other user fields will still apply as described in the [Normalized User Profile](/users/normalized).
+
+## User profile cache
+
+Auth0 caches the user profile received from a [database connection](/connections/database) before sending it to the client application. This cache is stored in the Auth0 database and is refreshed each time the user authenticates.
+
+The cached values for the [Normalized User Profile](/users/normalized/auth0/normalized-user-profile-schema) fields are based on the values returned from the Login Script of your custom database connection.
+
+The User Profile is cached for several reasons. First, caching allows you the option of implementing [Single Sign-on (SSO)](/sso) at the Auth0 layer to avoid going to the Connection for every request. Additionally, this provides resilience if a Connection is temporarily unavailable.
+
+## Keep reading
+
+* [User Profiles](/users/concepts/overview-user-profile)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [Manage User Metadata](/users/guides/manage-user-metadata)
+* [Manage Users Using the Management API](users/guides/manage-users-using-the-management-api)
+* [Update Metadata with the Management API](/users/guides/update-metadata-properties-with-management-api)
+* [Read Metadata](/users/guides/read-metadata)
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [User Data Storage Scenario](/users/references/user-data-storage-scenario)
+* [View Users](/users/guides/view-users)
diff --git a/ja-jp/articles/users/guides/view-users.md b/ja-jp/articles/users/guides/view-users.md
new file mode 100644
index 0000000000..733afddc62
--- /dev/null
+++ b/ja-jp/articles/users/guides/view-users.md
@@ -0,0 +1,63 @@
+---
+description: How to view users and their profile details.
+topics:
+    - users
+    - user-management
+    - user-profiles
+contentType: how-to
+useCase: manage-users
+---
+# View Users
+
+The [Users](${manage_url}/#/users) page lists the users who are associated with your apps. To open a particular user, click the user profile picture or name in the "Name" column. The User Details page will open and display information for that user.
+
+The User Details page has links for five tabs:
+
+1. Details
+2. Devices
+3. History
+4. Locations
+5. Raw JSON
+
+## User Details: Details Tab
+
+The Details tab contains three sections that provide a high-level overview of the information in the user's profile:
+
+* **User Identity** provides at-a-glance details about the user, including their email address, associated Connections, and access rights.
+* **Metadata** displays the `app_metadata` and `user_metadata` information. You can edit these values.
+* **Identity Provider Attributes** displays the information retrieved from the authentication provider. Note that identity provider attributes are read-only.
+
+## User Details: Devices Tab
+
+The Devices tab lists the devices with which the user has requested authentication. Requesting authorization on a device links the device to the user's account.
+
+Login details for the user are associated with the Refresh Token assigned to that device. To revoke the Refresh Token, click **Unlink** next to the device.
+
+## User Details: History Tab
+
+The History tab displays a log of the user's account activity for the past 2 days.
+
+The logs include information about:
+
+* Events that have occurred
+* When the events occurred
+* The apps associated with the events
+* The identity provider used for authentication
+* The originating IP addresses for the events
+* Where the events originated
+
+## User Details: Locations Tab
+
+The Locations tab displays a map with pins indicating the user's location(s) when they logged in to the apps.
+
+## User Details: Raw JSON Tab
+
+The Raw JSON tab displays all of the information contained on the user's profile in JSON format so you can quickly view all of the available information about the user.
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Normalized User Profiles](/users/normalized)
+* [Metadata Overview](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
+* [Update Users Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/ja-jp/articles/users/index.md b/ja-jp/articles/users/index.md
new file mode 100644
index 0000000000..2b8b93b77d
--- /dev/null
+++ b/ja-jp/articles/users/index.md
@@ -0,0 +1,30 @@
+---
+url: /users
+title: Manage Users
+description: Learn about working with users, user profiles, and user metadata in Auth0.
+classes: topic-page
+topics:
+  - users
+  - user-management
+contentType:
+  - index
+useCase:
+  - manage-users
+v2: true
+---
+# Manage Users
+
+Auth0's hosted cloud database stores a variety of information on your users that is accessible to you. This information is available to you via a *user profile*, and your users are grouped by tenant. The user information itself can come from a variety of sources, including identity providers, your own databases, and enterprise connections (Active Directory, SAML).
+
+<%= include('../_includes/_topic-links', { links: [
+  'users/concepts/overview-user-profile',
+  'users/concepts/overview-user-metadata',
+  'sessions',
+  'users/guides/manage-users-using-the-dashboard',
+  'users/guides/manage-users-using-the-management-api',
+  'users/guides/email-verified',
+  'extensions/account-link',
+  'security/blacklisting-attributes',
+  'users/concepts/overview-user-migration',
+  'users/search/v3'
+] }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/users/normalized/auth0/identify-users.md b/ja-jp/articles/users/normalized/auth0/identify-users.md
new file mode 100644
index 0000000000..4fab34f775
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/identify-users.md
@@ -0,0 +1,42 @@
+---
+description: Learn how to uniquely identify users.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+# Identify Users
+
+There are two recommended options to uniquely identify your users:
+
+1. By the `user_id` property. This is guaranteed to be unique (within a tenant) per user (such as `{identity provider id}|{unique id in the provider}`, or `facebook|1234567890`). A user may have the same `user_id` property across multiple Auth0 tenants, but consistency is not guaranteed.
+2. By a *natural* key, like the `email` property. In this case, it is recommended that you enable email verification and only use this option with providers that require that users verify their emails.
+
+If you use [custom databases](/connections/database/mysql), you must return a unique `user_id` property. If you have multiple custom databases and expect possible collisions between ids from different connections, you should use a prefix identifying the connection. For example:
+
+```javascript
+function login (email, password, callback) {
+  var user = getUserFromDB(email);
+  var profile = {
+    user_id: 'MyConnection1|' + user.id,
+    email: user.email,
+    [...]
+  };
+  callback(null, profile);
+}
+```
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/ja-jp/articles/users/normalized/auth0/index.md b/ja-jp/articles/users/normalized/auth0/index.md
new file mode 100644
index 0000000000..5593c4d5da
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/index.md
@@ -0,0 +1,37 @@
+---
+description: Understand how Auth0 normalizes common user properties in the user profile.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - index
+  - concept
+useCase:
+  - manage-users
+v2: true
+---
+
+# Normalized User Profiles
+
+::: warning
+This version describes the user profile as normalized by Auth0. Use the dropdown to locate the user profile structure that conforms with the OIDC specification and includes only the standard claims.
+:::
+
+The Normalized User Profile is an Auth0-specific way of standardizing and storing user-related information. Because every [Identity Provider](/connections) (IdP) provides a different set of information about a user, Auth0 normalizes common profile properties into a protocol-agnostic representation of the user when storing user-related claims. For example, `family_name` in the normalized user profile contains details that may be returned to an IdP as `surname` or `last_name`.
+
+As such, the Auth0 claims included in the normalized user profile differ from the standard set of claims that can be returned in ID Tokens from the [Authentication API's `oauth/token` endpoint](/api/authentication#get-token) or in the response from the [/userinfo](/api/authentication#user-profile) endpoint (both of which follow the requirements detailed in the OIDC specification). 
+
+To learn about the attributes included in the Normalized User Profile and understand how you can work with them, visit [User Profile Structure](/users/references/user-profile-structure).
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Retrieve User Profiles](/users/search)
+* [Update User Profile Root Attributes](/users/normalized/auth0/update-root-attributes)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/ja-jp/articles/users/normalized/auth0/normalized-user-profile-schema.md b/ja-jp/articles/users/normalized/auth0/normalized-user-profile-schema.md
new file mode 100644
index 0000000000..63c43e0532
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/normalized-user-profile-schema.md
@@ -0,0 +1,67 @@
+---
+description: Normalized User Profile schema reference. 
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - reference
+useCase:
+  - manage-users
+v2: true
+---
+# Normalized User Profile Schema
+
+The attributes that Auth0 maps to a common schema are listed below.
+
+Fields that are always generated:
+
+* **`name`**: the user's full name.
+* **`nickname`**: the user's username if available, else the local-part of the user's email.
+* **`picture`**: the URL of the [user's picture](/users/guides/change-user-pictures). If unavailable, Auth0 uses the Gravatar image associated with the user's email address.
+* **`user_id`**: the user's unique identifier. This is unique per Connection, but the same for all apps that authenticate via that Connection.
+
+By default, a user's `name`, `nickname`, and `picture` attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable since they are updated from the identity provider each time a user logs in. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API.
+
+Fields that are generated when the details are available:
+
+* **`email`**: the user's email address.
+* **`email_verified`**: a boolean indicating if the user's email address has been verified.
+* **`given_name`**: the user's first name.
+* **`family_name`**: the user's last name.
+
+::: note
+When creating a user with the [create a User Management API endpoint](/api/management/v2#!/Users/post_users) you can submit the `given_name` and `family_name`. By default, a user's `given_name` and `family_name` attributes provided by identity providers other than Auth0 (such as Google, Facebook, Twitter) are not directly editable since they are updated from the identity provider each time a user logs in. If you want to be able to edit these attributes, you must [configure your connection sync with Auth0](/dashboard/guides/connections/configure-connection-sync) so that user attributes will be updated from the identity provider only on user profile creation. Root attributes will then be available to be [edited individually](/api/management/guides/users/update-root-attributes-users) or [by bulk import](/api/management/guides/users/update-root-attributes-users) using the Management API
+:::
+
+::: panel Custom Databases
+If you are writing a login script for a [custom database](/connections/database/mysql) you are responsible for returning the information in the user profile. A unique and immutable `user_id` property is mandatory to correctly identify the user (see [Uniquely Identify Users](/users/normalized/auth0/identify-users)).
+:::
+
+## Additional Attributes
+
+The User Profile includes an array of identities. In the most common case (logging in with a single provider), the array contains only one element. If the user has multiple accounts linked, the array will have an element for each associated account. See [User Account Linking](/users/concepts/overview-user-account-linking) for more information. 
+:::
+
+The `identities` array contains the following attributes:
+
+* `connection`: the name of the connection.
+* `isSocial`: indicates if the provider is a Social provider.
+* `provider`: the provider of the connection.
+* `user_id`: the unique identifier of the user for this connection.
+
+::: note
+Auth0 will pass to your app all other properties supplied by the identity provider, even if those that are not mapped to the standard attributes listed above.
+:::
+
+## Keep reading
+
+* [User Profile Structure](/users/references/user-profile-structure)
+* [Update User Profile Root Attributes](/users/normalized/auth0/update-root-attributes)
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/ja-jp/articles/users/normalized/auth0/sample-user-profiles.md b/ja-jp/articles/users/normalized/auth0/sample-user-profiles.md
new file mode 100644
index 0000000000..1a12d81ad6
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/sample-user-profiles.md
@@ -0,0 +1,132 @@
+---
+description: Examples of user profiles.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - reference
+useCase:
+  - manage-users
+v2: true
+---
+# Sample User Profiles
+
+## Google User Profile
+
+This is a sample user profile from a user that logged in through **Google**:
+
+```json
+{
+  "email": "johnfoo@gmail.com",
+  "email_verified": true,
+  "family_name": "Foo",
+  "gender": "male",
+  "given_name": "John",
+  "identities": [
+    {
+      "provider": "google-oauth2",
+      "user_id": "103547991597142817347",
+      "connection": "google-oauth2",
+      "isSocial": true
+    }
+  ],
+  "locale": "en",
+  "name": "John Foo",
+  "nickname": "FooJon",
+  "picture": "https://lh4.googleusercontent.com/-OdsbOXom9qE/AAAAAAAAAAI/AAAAAAAAADU/_j8SzYTOJ4I/photo.jpg",
+  "user_id": "google-oauth2|103547991597142817347"
+}
+```
+
+## Microsoft Account User Profile
+
+This is a sample profile from **Microsoft Account**:
+
+```json
+{
+  "email": "bobdoe@outlook.com",
+  "email_verified": true,
+  "emails": [
+    "bobdoe@outlook.com",
+    "bobdoe@outlook.com"
+  ],
+  "family_name": "Doe",
+  "given_name": "Bob",
+  "identities": [
+    {
+      "provider": "windowslive",
+      "user_id": "4cf0a30169d55031",
+      "connection": "windowslive",
+      "isSocial": true
+    }
+  ],
+  "locale": "en_US",
+  "name": "Bob Doe",
+  "nickname": "doebob@outlook.com",
+  "picture": "https://secure.gravatar.com/avatar/c89b2bb92df91508e14172097a5e17da?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "user_id": "windowslive|4cf0a30169d55031"
+}
+```
+
+## Office 365 User Profile
+
+This is a sample profile from **Office 365 (Microsoft Azure Active Directory)**:
+
+```json
+{
+  "email": "jeff@foo.onmicrosoft.com",
+  "family_name": "Jeff",
+  "given_name": "Beth",
+  "identities": [
+    {
+      "user_id": "10030000838D23AF@MicrosoftOnline.com",
+      "provider": "office365",
+      "connection": "foo-onmicrosoft",
+      "isSocial": false
+    }
+  ],
+  "name": "Jeff Beth",
+  "nickname": "jeff@auth0.onmicrosoft.com",
+  "picture": "https://secure.gravatar.com/avatar/a7f86ddd090d5a4cb833b97baab2aca1?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "tenantid": "75696069-df44-4310-9bcf-08b45e3007c9",
+  "upn": "jeff@foo.onmicrosoft.com",
+  "user_id": "office365|10030000838D23AF@MicrosoftOnline.com"
+}
+```
+
+## ADFS User Profile
+
+This is a sample profile from **ADFS (Active Directory Federation Services)**:
+
+```json
+{
+  "email": "john@fabrikam.com",
+  "family_name": "Fabrikam",
+  "email_verified": false,
+  "given_name": "John",
+  "identities": [
+    {
+      "user_id": "john@fabrikam.com",
+      "provider": "adfs",
+      "connection": "auth10.com",
+      "isSocial": false
+    }
+  ],
+  "issuer": "https://adfs.fabrikam.com",
+  "name": "John Fabrikam",
+  "nickname": "john",
+  "picture": "https://secure.gravatar.com/avatar/5426f6b9d63ad92d60e6fe9fdf83aa21?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
+  "user_id": "adfs|john@fabrikam.com"
+}
+```
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Store User Data](/users/normalized/auth0/store-user-data)
+* [Retrieve User Profiles](/users/search)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/ja-jp/articles/users/normalized/auth0/store-user-data.md b/ja-jp/articles/users/normalized/auth0/store-user-data.md
new file mode 100644
index 0000000000..d6bc8a02b9
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/store-user-data.md
@@ -0,0 +1,29 @@
+---
+description: Learn how to store user data in tables.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+v2: true
+---
+# Store User Data
+
+When outsourcing user authentication, there is usually no need to maintain your own users/passwords table. Even so, you may still want to associate application data to authenticated users.
+
+For example, you could have a *Users table* that lists each user authenticated by Auth0. Every time a users logs in, you could search the table for that user. If the user does not exist, you would create a new record. If they do exist, you would update all fields, essentially keeping a local copy of all user data.
+
+Alternatively, you could store the user identifier in each table/collection that has user-associated data. This is a simpler implementation suited to smaller applications.
+
+## Keep reading
+
+* [Normalized User Profiles Overview](/users/normalized)
+* [Retrieve User Profiles](/users/search)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+* [Claims for User Profile Returned via OIDC-Compliant Authorization Flow](/users/normalized/oidc)
diff --git a/ja-jp/articles/users/normalized/auth0/update-root-attributes.md b/ja-jp/articles/users/normalized/auth0/update-root-attributes.md
new file mode 100644
index 0000000000..222a954535
--- /dev/null
+++ b/ja-jp/articles/users/normalized/auth0/update-root-attributes.md
@@ -0,0 +1,54 @@
+---
+title: Updating User Profile Root Attributes
+description: Learn about root attributes available for the Auth0 normalized user profile and methods of updating them.
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - auth0-user-profiles
+contentType:
+  - how-to
+useCase:
+  - manage-users
+---
+# Updating User Profile Root Attributes
+
+Auth0's normalized user profile contains a number of root attributes (attributes stored at the first, or root, level of the object), some of which may be updated. [Learn more about the user profile structure and its attributes.](/users/references/user-profile-structure) 
+
+Methods for updating root attributes vary depending on connection type.
+
+## Auth0 as the Identity Provider
+
+When Auth0 is the Identity Provider (IdP), subscribers may: 
+
+* Set root attributes [on user sign-up](/api/management/guides/users/set-root-attributes-user-signup) (via the Management API or via public signup)
+or [on import](/api/management/guides/users/set-root-attributes-user-import)
+* [Update root attributes individually](/api/management/guides/users/update-root-attributes-users) via the Management API
+
+Auth0 is the IdP for the following connection types:
+
+* [regular database connections](/connections/database)
+* [custom database connections](/connections/database/custom-db) with import mode
+* [passwordless connections](/connections/passwordless)
+
+## Upstream Identity Providers
+
+When an upstream IdP (like Google or Facebook) is used, subscribers have two options:
+
+* The upstream IdP sets the root attributes when users are first created and then
+automatically updates them with each subsequent login. This is the default behavior.
+* The upstream IdP sets the root attributes on user creation only and does not
+update them on subsequent logins, thereby allowing subscribers to [update root attributes individually](/api/management/guides/users/update-root-attributes-users) via the Management API. To enable this, you will need to [configure your connection sync with Auth0](/api/management/guides/connections/configure-connection-sync).
+
+Upstream Identity Providers handle the following connection types:
+
+* [social connections](/connections#social)
+* [enterprise connections](/connections#enterprise)
+* [legal identity connections](/connections#legal-identities)
+
+## Keep reading
+
+* [Set Root Attributes During User Sign-Up](/api/management/guides/users/set-root-attributes-user-signup)
+* [Set Root Attributes During User Import](/api/management/guides/users/set-root-attributes-user-import)
+* [Update Root Attributes](/api/management/guides/users/update-root-attributes-users)
+* [Configure Connection Sync with Auth0](/api/management/guides/connections/configure-connection-sync)
\ No newline at end of file
diff --git a/ja-jp/articles/users/normalized/index.yml b/ja-jp/articles/users/normalized/index.yml
new file mode 100644
index 0000000000..b833aeb219
--- /dev/null
+++ b/ja-jp/articles/users/normalized/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: users/normalized
+  current: auth0
+  versions:
+    - auth0
+    - oidc
+  defaultArticles:
+    auth0: index
+    oidc: index
\ No newline at end of file
diff --git a/ja-jp/articles/users/normalized/oidc/index.md b/ja-jp/articles/users/normalized/oidc/index.md
new file mode 100644
index 0000000000..d63f0591db
--- /dev/null
+++ b/ja-jp/articles/users/normalized/oidc/index.md
@@ -0,0 +1,97 @@
+---
+description: Claims for a user profile returned via an OIDC-Compliant authorization flow
+topics:
+  - user-profile
+  - normalized-user-profile
+  - users
+  - oidc-user-profiles
+contentType:
+  - index
+  - concept
+  - reference
+useCase:
+  - manage-users
+---
+# User Profiles Returned from OIDC-Compliant Pipelines
+
+::: version-warning
+This article describes the user profile that includes only the [OpenID Connect (OIDC) standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Use the toggle for information on the Auth0 normalized profile, which might contain information from many identity providers.
+:::
+
+When you're using an OIDC-conformant authentication flow, the user profile you receive in return may differ slightly from the [Auth0 Normalized User Profile](/users/normalized/auth0).
+
+The following is a [non-normative example of such a response](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims):
+
+```json
+  {
+   "sub": "248289761001",
+   "name": "Jane Doe",
+   "given_name": "Jane",
+   "family_name": "Doe",
+   "middle_name": "",
+   "nickname": "",
+   "preferred_username": "j.doe",
+   "profile": "",
+   "picture": "http://example.com/janedoe/me.jpg",
+   "website": "http://example.com",
+   "email": "janedoe@example.com",
+   "email_verified": true,
+   "gender": "female",
+   "birthdate": "",
+   "zoneinfo": "",
+   "locale": "",
+   "phone_number": "",
+   "phone_number_verified": false,
+   "address": {
+      "street_address": "",
+      "locality": "",
+      "region": "",
+      "postal_code": "",
+      "country": ""
+   },
+   "updated_at": "",
+  }
+```
+
+## Retrieve User Profiles using ID Tokens
+
+You can retrieve the user profile by retrieving an ID Token using the Authentication API's [`oauth/token` endpoint](/api/authentication#get-token) or the [`/userinfo` endpoint](/api/authentication#get-user-info). Auth0's [Lock](https://auth0.com/docs/libraries#lock-login-signup-widgets) widget and the [Auth0 client-side SDKs](/libraries#auth0-client-side-sdks) also return the OIDC-compliant user profile.
+
+Additionally, the User Profile section of our [Quickstarts](/quickstarts) return user profiles compliant with the OIDC specification. Some of our more popular Quickstarts are:
+
+- [ASP.NET Core](/quickstart/webapp/aspnet-core/04-user-profile)
+- [Android](/quickstart/native/android/04-user-profile)
+- [Angular 2](/quickstart/spa/angular2/03-user-profile)
+- [Node.js](/quickstart/webapp/nodejs)
+- [React](/quickstart/spa/react/02-user-profile)
+
+## Claims
+
+| Parameter | Definition |
+| --------- | ---------- |
+| `sub` | unique identifier for the user |
+| `name` | name of the user |
+| `given_name` | the first/given name of the user |
+| `family_name` | the surname/last name of the user |
+| `middle_name` | the middle name of the user |
+| `nickname` | casual name of the user that may/may not be the same as the `given_name` |
+| `preferred_username` | identifier by which the user wishes to be referred to |
+| `profile` | URL of the user's profile page |
+| `picture` | URL of the user's profile picture |
+| `website` | URL of the user's website/blog |
+| `email` | preferred email address of the user |
+| `email_verified` 
    Boolean | `true` if user's email address is verified; else, `false` |
+| `gender` | gender of the user |
+| `birthdate` | birthday of the user |
+| `zoneinfo` | time zone in which the user is located |
+| `locale` | two-part code representing the end user's language and location (e.g., `fr-CA` for a user located in Canada and working in French) |
+| `phone_number` | preferred telephone number for the user |
+| `phone_number_verified` 
    Boolean | `true` if user's phone number is verified; else, `false` |
+| `address` 
    JSON Object | preferred postal address of the user |
+| `updated_at` 
    Number | time when the user's profile was last updated |
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [OIDC Conformant Authentication Adoption Guide](/api-auth/tutorials/adoption)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/users/references/bulk-import-database-schema-examples.md b/ja-jp/articles/users/references/bulk-import-database-schema-examples.md
new file mode 100644
index 0000000000..241bef14dc
--- /dev/null
+++ b/ja-jp/articles/users/references/bulk-import-database-schema-examples.md
@@ -0,0 +1,612 @@
+---
+title: Bulk User Import Database Schema and Examples
+description: How to perform bulk user imports with the Management API.
+toc: true
+topics:
+  - users
+  - user-management
+  - migrations
+  - bulk-imports
+contentType:
+  - reference
+useCase:
+  - manage-users
+  - migrate
+---
+# Bulk User Import Database Schema and Examples
+
+The users file must have an array with the users' information in JSON format.
+
+## User JSON schema
+
+The following [JSON schema](http://json-schema.org) describes valid users:
+
+```json
+{
+    "type": "object",
+    "properties": {
+        "email": {
+            "type": "string",
+            "description": "The user's email address.",
+            "format": "email"
+        },
+        "email_verified": {
+            "type": "boolean",
+            "default": false,
+            "description": "Indicates whether the user has verified their email address."
+        },
+        "user_id": {
+            "type": "string",
+            "description": "The user's unique identifier. This will be prepended by the connection strategy."
+        },
+        "username": {
+            "type": "string",
+            "description": "The user's username."
+        },
+        "given_name": {
+            "type": "string",
+            "description": "The user's given name."
+        },
+        "family_name": {
+            "type": "string",
+            "description": "The user's family name."
+        },
+        "name": {
+            "type": "string",
+            "description": "The user's full name."
+        },
+        "nickname": {
+            "type": "string",
+            "description": "The user's nickname."
+        },
+        "picture": {
+          "type": "string",
+          "description": "URL pointing to the user's profile picture."
+        },
+        "blocked": {
+            "type": "boolean",
+            "description": "Indicates whether the user has been blocked."
+        },
+        "password_hash": {
+            "type": "string",
+            "description":"Hashed password for the user. Passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds."
+        },
+        "custom_password_hash": {
+            "type": "object",
+            "description": "A more generic way to provide the users password hash. This can be used in lieu of the password_hash field when the users password hash was created with an alternate algorithm. Note that this field and password_hash are mutually exclusive.",
+            "properties": {
+                "algorithm": {
+                    "type": "string",
+                    "enum": ["argon2", "bcrypt", "hmac", "ldap", "md4", "md5", "sha1", "sha256", "sha512", "pbkdf2"],
+                    "description": "The algorithm that was used to hash the password."
+                },
+                "hash": {
+                    "type": "object",
+                    "properties": {
+                        "value": {
+                            "type": "string",
+                            "description": "The password hash."
+                        },
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["base64", "hex", "utf8"],
+                            "description": "The encoding of the provided hash. Note that both upper and lower case hex variants are supported, as well as url-encoded base64."
+                        },
+                        "digest": {
+                            "type": "string",
+                            "description": "The algorithm that was used to generate the HMAC hash",
+                            "enum": ["md4", "md5", "ripemd160", "sha1", "sha224", "sha256", "sha384", "sha512", "whirlpool"]
+                        },
+                        "key": {
+                            "type": "object",
+                            "description": "The key that was used to generate the HMAC hash",
+                            "required": ["value"],
+                            "properties": {
+                                "value": {
+                                    "type": "string",
+                                    "description": "The key value"
+                                },
+                                "encoding": {
+                                    "type": "string",
+                                    "enum": ["base64", "hex", "utf8"],
+                                    "default": "utf8",
+                                    "description": "The key encoding"
+                                }
+                            }
+                        }
+                    }
+                },
+                "salt": {
+                    "type": "object",
+                    "properties": {
+                        "value": {
+                            "type": "string",
+                            "description": "The salt value used to generate the hash."
+                        },
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["base64", "hex", "utf8"],
+                            "default": "utf8",
+                            "description": "The encoding of the provided salt. Note that both upper and lower case hex variants are supported, as well as url-encoded base64."
+                        },
+                        "position": {
+                            "type": "string",
+                            "enum": ["prefix", "suffix"],
+                            "description": "The position of the salt when the hash was calculated. For example; MD5('salt' + 'password') = '67A1E09BB1F83F5007DC119C14D663AA' would have \"position\":\"prefix\"."
+                        }
+                    },
+                    "required": ["value", "position"]
+                },
+                "password": {
+                    "type": "object",
+                    "properties": {
+                        "encoding": {
+                            "type": "string",
+                            "enum": ["ascii", "utf8", "utf16le", "ucs2", "latin1", "binary"],
+                            "default": "utf8",
+                            "description": "The encoding of the password used to generate the hash. On login, the user-provided password will be transcoded from utf8 before being checked against the provided hash. For example; if your hash was generated from a ucs2 encoded string, then you would supply \"encoding\":\"ucs2\"."
+                        }
+                    }
+                }
+            },
+            "required": ["algorithm", "hash"],
+            "additionalProperties": false
+        },
+        "app_metadata": {
+            "type": "object",
+            "description": "Data related to the user that does affect the application's core functionality."
+        },
+        "user_metadata": {
+            "type": "object",
+            "description": "Data related to the user that does not affect the application's core functionality."
+        },
+        "mfa_factors": {
+            "type": "array",
+            "items": {
+                "type": "object",
+                "properties": {
+                    "totp": {
+                        "type": "object",
+                        "properties": {
+                        "secret": {
+                            "type": "string",
+                                "pattern": "^[A-Z2-7]+$",
+                                "description": "The OTP secret is used with authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass). It must be supplied in un-padded Base32 encoding, such as: JBTWY3DPEHPK3PNP"
+                            },
+                        },
+                        "additionalProperties": false,
+                        "required": ["secret"],
+                    },
+                    "phone": {
+                        "type": "object",
+                        "properties": {
+                        "value": {
+                            "type": "string",
+                            "pattern": "^\\+[0-9]{1,15}$",
+                            "description": "The phone number for SMS or Voice MFA. The phone number should include a country code and begin with +, such as: +12125550001"
+                        },
+                        },
+                        "additionalProperties": false,
+                        "required": ["value"],
+                    },
+                    "email": {
+                        "type": "object",
+                        "properties": {
+                            "value": {
+                                "type": "string",
+                                "format": "email",
+                                "description": "The email address for MFA"
+                            },
+                        },
+                        "additionalProperties": false,
+                        "required": ["value"],
+                    },
+                },
+                "maxProperties": 1,
+                "additionalProperties": false,
+            },
+            "minItems": 1,
+            "maxItems": 10
+        }
+    },
+    "required": ["email"],
+    "additionalProperties": false
+}
+```
+
+## Properties
+
+You can import users with the following properties:
+
+| Property | Type | Description | Upsert During Import? |
+|----------|------|-------------|-----------------------|
+| `app_metadata` | object | Data that can affect the application's core functionality or what the user can access. Data stored in `app_metadata` cannot be edited by users. This may include things such as support plans, roles or access groups. | Yes |
+| `blocked` | boolean | Indicates whether the user has been blocked. | No |
+| `email` | string | The user's email address. | No |
+| `email_verified` | boolean | Indicates whether the user has verified their email address. | Yes |
+| `family_name` | string | The user's family name. | Yes |
+| `given_name` | string | The user's given name. | Yes |
+| `name` | string | The user's full name. | Yes |
+| `nickname` | string | The user's nickname. | Yes |
+| `picture` | string | URL pointing to the user's profile picture. | Yes |
+| `user_id` | string | The user's unique identifier. This will be prepended by the connection strategy. | No |
+| `user_metadata` | object | Data that does not impact what users can or cannot access, such as work address, home address, or user preferences. | Yes |
+| `username` | string | The user's username. | No |
+| `password_hash` | string | Hashed password for the user's connection. When users are created, Auth0 uses `bcrypt` to secure the password. Importing hashed passwords lets users keep their passwords for a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds. This property can only be provided when the user is first imported and cannot be updated later. | No |
+| `custom_password_hash` | object | A more generic way to provide the user's password hash. This can be used instead of the `password_hash` field when the user's password hash was created with an alternate algorithm. This property can only be provided when the user is first imported and cannot be updated later. | Yes |
+| `password_set_date` | datetime | Timestamp indicating when the password for the user's connection was set. At user creation, this field exists, and `last_password_reset` does not. If the user has reset their password, this field and `last_password_reset` are identical. | No |
+| `mfa_factors` | array | The MFA factors that can be used to authenticate this user | Yes |
+
+For more information on `app_metadata` and `user_metadata`, check out the [Metadata Overview](/users/concepts/overview-user-metadata).
+
+## App metadata
+
+The `user.app_metadata` object must **not** contain any of these properties:
+
+* `__tenant`
+* `_id`
+* `blocked`
+* `clientID`
+* `created_at`
+* `email_verified`
+* `email`
+* `globalClientID`
+* `global_client_id`
+* `identities`
+* `lastIP`
+* `lastLogin`
+* `loginsCount`
+* `metadata`
+* `multifactor_last_modified`
+* `multifactor`
+* `updated_at`
+* `user_id`
+
+## Custom password hash
+
+The `user.custom_password_hash` object can be used instead of the `user.password_hash` property when the user's password hash was created with an alternate algorithm. Note this field and `password_hash` are mutually exclusive.
+
+The `user.custom_password_hash` object has the following properties:
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `algorithm` | string | The algorithm used to hash the password. Must be one of: 
    • `argon2`
    • `bcrypt`
    • `hmac`
    • `ldap`
    • `md4`
    • `md5`
    • `sha1`
    • `sha256`
    • `sha512`
    • `pbkdf2`
     |
+| `hash` | object |   |
+| `hash.value` | string | The password hash. |
+| `hash.encoding` | string | The encoding of the provided hash. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
    Upper and lower case hex variants are supported, as well as url-encoded base64. |
+| `hash.digest` | string | The algorithm used to generate the HMAC hash. Must be one of: 
    • `md4`
    • `md5`
    • `ripemd160`
    • `sha1`
    • `sha224`
    • `sha256`
    • `sha384`
    • `sha512`
    • `whirlpool`
     |
+| `hash.key` | object | The key used to generate the HMAC hash. |
+| `hash.key.value` | string | The key value. |
+| `hash.key.encoding` | string | The key encoding. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
    By default, `hash.key.encoding` is `utf8`. |
+| `hash.salt` | object |   |
+| `hash.salt.value` | string | The salt value used to generate the hash. |
+| `hash.salt.encoding` | string | The encoding of the provided salt. Must be one of: 
    • `base64`
    • `hex`
    • `utf8`
     Upper and lower case hex variants are supported, as well as url-encoded base64. By default, `hash.salt.encoding` is `utf8`. |
+| `hash.salt.position` | string | The position of the salt when the hash was calculated. |
+| `password.encoding` | string | <%= include('../_includes/_password-encoding-description.md') %> |
+
+### Supported hash algorithms
+
+Auth0 currently supports imports of user passwords hashed by:
+
+* [Argon2](https://github.com/p-h-c/phc-winner-argon2)
+* [bcrypt](https://www.npmjs.com/package/bcrypt)
+* [LDAP](https://tools.ietf.org/html/rfc2307#section-5.3) (`RFC-2307 "userPassword"`)
+* [HMAC](https://tools.ietf.org/html/rfc2104)
+* [MD4](https://tools.ietf.org/html/rfc1320)
+* [MD5](https://tools.ietf.org/html/rfc1321)
+* [SHA1](https://tools.ietf.org/html/rfc3174)
+* [SHA256 and SHA512](https://tools.ietf.org/html/rfc4634)
+* [PBKDF2](https://tools.ietf.org/html/rfc2898#section-5.2)
+
+Please consider the following sections when providing a `custom_password_hash`.
+
+#### Argon2
+
+When the `algorithm` is set to `argon2`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` should be in [PHC string format](https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md) and conform to [these requirements](https://github.com/auth0/magic#magicpasswordhash--magicverifypassword).
+- `hash.value` must include the base64 encoded salt (as specified in the `PHC` documentation).
+
+#### bcrypt
+
+When the `algorithm` is set to `bcrypt`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` must be prefixed with either `$2a$` or `$2b$`. Other prefixes such as `$2$`, `$sha1$`, `$2x$`, etc. are not supported at this time. For instance, `$2b$10$nFguVi9LsCAcvTZFKQlRKeLVydo8ETv483lkNsSFI/Wl1Rz1Ypo1K` was generated from the string `hello` using with a cost parameter of 10.
+
+#### HMAC
+
+When the `algorithm` is set to `hmac`:
+
+- `hash.encoding` must be either `hex` or `base64`.
+- `hash.digest` is required and must be one of these:
+  - `md4`
+  - `md5`
+  - `ripemd160`
+  - `sha1`
+  - `sha224`
+  - `sha256`
+  - `sha384`
+  - `sha512`
+  - `whirlpool`
+- `hash.key.value` is required.
+- `hash.key.encoding` must be either `base64` or `hex` or `utf8`.
+
+#### LDAP
+
+When the `algorithm` is set to `ldap`:
+
+- `hash.encoding` must be `utf8`.
+- `salt` is not allowed.
+- `hash.value` must adhere to the format outlined in [RFC-2307 section-5.3](https://tools.ietf.org/html/rfc2307#section-5.3).
+- The scheme should be one of `md5|smd5|sha*|ssha*` see [here](https://www.openldap.org/faq/data/cache/347.html) for more info.
+- Note that the [crypt](https://www.openldap.org/faq/data/cache/344.html) scheme is **not supported** due to system/implementation dependent behavior. For more information, check out [Open LDAP Admin Guide - 14.4.2. CRYPT password storage scheme](https://www.openldap.org/doc/admin24/guide.html#CRYPT%20password%20storage%20scheme).
+
+#### MD* or SHA*
+
+When the `algorithm` is set to `md4`, `md5`, `sha1`, `sha256`, or `sha512`:
+
+- `hash.encoding` must be either `hex` or `base64`.
+
+#### PBKDF2
+
+When the `algorithm` is set to `pbkdf2`:
+
+- `hash.encoding` must be `utf8`.
+- `hash.salt` is not allowed.
+- `hash.value` should be in [PHC string format](https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md).
+- `hash.value` must include the B64 encoded salt (base64 omitting padding characters `=`, as specified in the `PHC` documentation).
+- `hash.value` should include `i` (iterations) and `l` (keylen) parameters. If these parameters are omitted, they will default to `i=100000` and `l=64`.
+- The `id` should be in a `pbkdf2-` format (`pbkdf2-sha512`, `pbkdf2-md5`, etc). The supported digests are:
+    - `RSA-MD4`
+    - `RSA-MD5`
+    - `RSA-MDC2`
+    - `RSA-RIPEMD160`
+    - `RSA-SHA1`
+    - `RSA-SHA1-2`
+    - `RSA-SHA224`
+    - `RSA-SHA256`
+    - `RSA-SHA384`
+    - `RSA-SHA512`
+    - `md4`
+    - `md4WithRSAEncryption`
+    - `md5`
+    - `md5WithRSAEncryption`
+    - `mdc2`
+    - `mdc2WithRSA`
+    - `ripemd`
+    - `ripemd160`
+    - `ripemd160WithRSA`
+    - `rmd160`
+    - `sha1`
+    - `sha1WithRSAEncryption`
+    - `sha224`
+    - `sha224WithRSAEncryption`
+    - `sha256`
+    - `sha256WithRSAEncryption`
+    - `sha384`
+    - `sha384WithRSAEncryption`
+    - `sha512`
+    - `sha512WithRSAEncryption`
+    - `ssl3-md5`
+    - `ssl3-sha1`
+    - `whirlpool`
+
+### MFA factors
+
+The `user.mfa_factors` array contains [MFA enrollments](/mfa) for the user. Importing enrollments prevents the need for users to re-enroll in MFA after they're imported. The supported enrollment types are:
+
+| Property | Type | Description |
+|---------|------|-------------|
+| `email` | object |   |
+| `email.value` | string | The email address for MFA. |
+| `phone` | object |   |
+| `phone.value` | string | The phone number for SMS or Voice MFA. Must have a country code and begin with `+`, such as: `"+12125550001"` |
+| `totp` | object |   |
+| `totp.secret` | string | The OTP secret for MFA authentication with authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass). Must be in un-padded Base32 encoding, for example: `"JBTWY3DPEHPK3PNP"` |
+
+## Examples
+
+### Basic
+
+A file with the following contents is valid:
+
+```json
+[
+  {
+    "email": "john.doe@contoso.com",
+    "email_verified": false,
+    "app_metadata": {
+        "roles": ["admin"],
+        "plan": "premium"
+    },
+    "user_metadata": {
+        "theme": "light"
+    }
+  }
+]
+```
+
+### Custom Password Hash
+
+Some example users with hashes provided:
+
+```json
+[
+    {
+        "email": "antoinette@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "md4",
+            "hash": {
+                "value": "AbuUujgF0pPPkJPSFRTpmA==",
+                "encoding": "base64"
+            }
+        }
+    },
+    {
+        "email": "mary@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "sha256",
+            "hash": {
+                "value": "d24e794fce503c3ddb1cd1ba1dd5d9b250cf9917336a0316fefd87fecf79200f",
+                "encoding": "hex"
+            },
+            "salt": {
+                "value": "abc123",
+                "position": "prefix"
+            }
+        }
+    },
+    {
+        "email": "velma@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "bcrypt",
+            "hash": {
+                "value": "$2b$10$C9hB01.YxRSTcn/ZOOo4j.TW7xCKKFKBSF.C7E0xiUwumqIDqWUXG"
+            }
+        }
+    },
+    {
+        "email": "edward@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "argon2",
+            "hash": {
+                "value": "$argon2id$v=19$m=65536,t=2,p=1$J6Q/82PCyaNpYKRELJyTZg$m04qUAB8rexWDR4+/0f+SFB+4XMFxt7YAvAq2UycYos"
+            }
+        }
+    },
+    {
+        "email": "terrell@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "pbkdf2",
+            "hash": {
+                "value": "$pbkdf2-md4$i=100000,l=64$+N375B8q0Fw$fp2R9KAM4hK/votGHC5Fu+jhqbxUD8+Nic/EMSGvNC3UP/k7wSHI0uXluHRSkZfl/BOheYqNOemayG90ZaSSQw",
+                "encoding": "utf8"
+            }
+        }
+    },
+    {
+        "email": "cecil@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "pbkdf2",
+            "hash": {
+                "value": "$pbkdf2-sha512$i=100000,l=64$KNyFsA2rWoE$I2CQGI9H0JxdDf3kERRI97kPCGxh0KWBIV3MxyaS191gDGfzVBGyS4BibhgqWQ0/ails8mHuU9ckASxHOOq58w"
+            }
+        }
+    },
+    {
+        "email": "sean@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "ldap",
+            "hash": {
+                "value": "{SSHA384}/cgEjdoZh85DhurDeOQEMO1rMlAur93SVPbYe5XSD4lF7nNuvrBju5hUeg9A6agRemgSXGl5YuE=",
+                "encoding": "utf8"
+            }
+        }
+    },
+    {
+        "email": "peter@contoso.com",
+        "email_verified": false,
+        "custom_password_hash": {
+            "algorithm": "hmac",
+            "hash": {
+                "value": "cg7f42jH39/2EaAU4wNd4s2lKIk=",
+                "encoding": "base64",
+                "digest": "sha1",
+                "key": {
+                    "value": "736868",
+                    "encoding": "hex"
+                }
+            }
+        }
+    }
+]
+```
+
+### MFA Factors
+
+As you might expect, the `user.mfa_factors` array allows you to provide the user's [MFA enrollments](/mfa). The supported enrollment types are:
+
+* Phone: Used for sms or voice-based verification.
+* TOTP: OTP secret for use with MFA type apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass).
+* Email: Used for email-based verification.
+
+Some examples of users with MFA factors:
+
+```json
+[
+    {
+        "email": "antoinette@contoso.com",
+        "mfa_factors": [
+            {
+                "totp": {
+                    "secret": "2PRXZWZAYYDAWCD"
+                }
+            },
+            {
+                "phone": {
+                    "value": "+15551112233"
+                }
+            },
+            {
+                "email": {
+                    "value": "antoinette@antoinette.biz"
+                }
+            }
+        ]
+    },
+    {
+        "email": "mary@contoso.com",
+        "mfa_factors": [
+            {
+                "totp": {
+                    "secret": "JTF18P5973P1KCZN"
+                }
+            }
+        ]
+    },
+    {
+        "email": "velma@contoso.com",
+        "mfa_factors": [
+            {
+                "phone": {
+                    "value": "+15551234567"
+                }
+            },
+        ]
+    },
+    {
+        "email": "edward@contoso.com",
+        "mfa_factors": [
+            {
+                "email": {
+                    "value": "edward@edward.biz"
+                }
+            }
+        ]
+    }
+]
+```
+
+::: note
+The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
+:::
+
+## Keep reading
+
+* [User Migration Overview](/users/concepts/overview-user-migration)
+* [Configure Automatic Migration](/users/guides/configure-automatic-migration)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [User Migration Scenarios](/users/references/user-migration-scenarios)
+
diff --git a/ja-jp/articles/users/references/link-accounts-client-side-scenario.md b/ja-jp/articles/users/references/link-accounts-client-side-scenario.md
new file mode 100644
index 0000000000..82b00b0e95
--- /dev/null
+++ b/ja-jp/articles/users/references/link-accounts-client-side-scenario.md
@@ -0,0 +1,82 @@
+---
+title: User Initiated Account Linking - Client-Side Implementation
+description: Learn how to provide a client-side UI that allows users to authenticate to their other accounts and link these to their primary account using a SPA.
+crews: crew-2
+topics:
+  - account-linking
+  - client-side
+contentType:
+  - reference
+useCase:
+  - manage-accounts
+---
+
+# User Initiated Account Linking - Client-Side Implementation
+
+Auth0 supports the linking of user accounts from various identity providers. One way to implement this functionality is to enable the user to explicitly link accounts. In this scenario, the user authenticates through the UI of your Single Page Application (SPA) and can later use a link or button to link another account to the first one. When the user clicks on this link/button, your application makes a call so that when the user logs in with the second provider, the second account is linked with the first.
+
+When you initiate account linking, you can select which identity to use as the primary account and which to use as the secondary. This choice depends on which set of attributes you want to retain in the primary profile, as you will only retain the attributes from the primary account.
+
+You can find the full source of this sample application [on GitHub](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/SPA).
+
+1. Log the user in to your application. 
+
+    The user authenticates to your SPA using using [Universal Login](/universal-login), requesting an [Access Token for the Management API](/api/management/v2/get-access-tokens-for-spas).
+
+    In the typical SPA login, the callback is handled client-side by the same page, and a JWT is received after successful authentication. For details, see the [Single-Page App Quickstarts](/quickstart/spa).
+
+2. The user initiates account linking. Your SPA must provide a UI for the user to initiate a link to their other accounts. For example, your SPA could contain a user's settings page:
+
+    ![SPA User Settings Example](/media/articles/link-accounts/account-linking-spa.png)
+
+    When the user clicks on the **Link Account** button, your app redirects the user to the Universal Login page, when they log in with the connection they want to link to. After successful authentication, use the obtained token to link the accounts.
+
+    You could also add a button for each connection (e.g. 'Link Facebook Account', 'Link Google Account') and redirect the user to `/authorize` with the `connection` parameter set (e.g. `/authorize?connection=facebook`).
+
+3. Link accounts by calling the Auth0 Management API's [Link a User Account endpoint](/api/v2#!/Users/post_identities).
+
+    ::: warning
+    To retain and merge the `user_metadata` from the secondary account, you must retrieve and merge it into the metadata for the primary account before calling the API endpoint. After the accounts are linked, the metadata for the secondary account is discarded. 
+    
+    When you initiate account linking, you can select which identity will be used as the primary account and which as the secondary. This choice will depend on which set of attributes you want to retain in the primary profile.
+    :::
+
+    In the `linkAccount` function, call the Management API. Authenticate with the API using the primary JWT, which is the Access Token, and link using the primary user's ID and the secondary JWT, which is the secondary user's ID Token.
+
+```
+  const linkAccount = async () => {
+  const accessToken = await auth0.getTokenSilently();
+  const { sub } = await auth0.getUser();
+  const {
+    __raw: targetUserIdToken,
+    email_verified,
+    email,
+  } = await authenticateUser();
+
+  if (!email_verified) {
+    throw new Error(
+      `Account linking is only allowed to a verified account. Please verify your email <%= "${email}" %>.`
+    );
+  }
+
+  await fetch(`https://${account.namespace}/api/v2/users/<%= "${sub}" %>/identities`, {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      Authorization: `Bearer <%= "${accessToken}" %>`,
+    },
+    body: JSON.stringify({
+      link_with: targetUserIdToken,
+    }),
+  });
+};
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [Suggested Account Linking - Server-Side Implementation](/users/references/link-accounts-server-side-scenario)
diff --git a/ja-jp/articles/users/references/link-accounts-server-side-scenario.md b/ja-jp/articles/users/references/link-accounts-server-side-scenario.md
new file mode 100644
index 0000000000..5650982f28
--- /dev/null
+++ b/ja-jp/articles/users/references/link-accounts-server-side-scenario.md
@@ -0,0 +1,204 @@
+---
+title: Suggested Account Linking - Server-Side Implementation
+description: Describes how to link user accounts with a regular web app using server-side code using a sample scenario.
+crews: crew-2
+topics:
+  - account-linking
+  - server-side
+contentType:
+  - reference
+useCase:
+  - manage-accounts
+---
+
+# Suggested Account Linking - Server-Side Implementation
+
+Auth0 supports the linking of user accounts from various identity providers. You can use server-side code to link accounts on a regular web application, engaging the user and asking them for permission before proceeding. Your code will authenticate users and search for and identify users using their email addresses. Your application will then prompt the user to link their accounts by authenticating with the target account's credentials, and later link the accounts.
+
+You can find the full source of this sample application [on GitHub](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/RegularWebApp).
+
+1. Log the user in to your application.
+
+    The user authenticates to your application using [Universal Login](/universal-login). For details, see the [Regular Web App Quickstarts](/quickstart/webapp), asking for a token for the Auth0 Management API audience (audience=`https://${account.namespace}/api/v2/`).
+
+2. Search for users with identical email addresses.
+
+    In the `/user` route implementation, we'll get the user profile and the list of users with the same verified email/
+
+```js
+router.get("/", async (req, res) => {
+  const { sub, email_verified } = req.openid.user;
+  //fetch user profile containing the user_metadata and app_metadata properties
+  try {
+    let getUsersWithSameVerifiedEmail = [];
+    const getUserProfile = auth0Client.getUser(sub);
+    if (email_verified)
+      // account linking is only offered verified email
+      getUsersWithSameVerifiedEmail = auth0Client.getUsersWithSameVerifiedEmail(
+        req.openid.user
+      );
+
+    const [user, suggestedUsers] = await Promise.all([
+      getUserProfile,
+      getUsersWithSameVerifiedEmail,
+    ]);
+
+    const flashError = clear(req);
+    res.render("user", {
+      user,
+      suggestedUsers,
+      wrongAccountError: flashError && flashError === Errors.WrongAccount,
+    });
+  } catch (err) {
+    debug("GET /user[s] failed: %o", err);
+    res.render("error", err);
+  }
+});
+```
+
+  To get a list of all of the user records with the same email address, your application calls the Auth0 Management API's [Get Users By Email endpoint](/api/v2#!/users-by-email/) using a [Management API Access Token](/api/management/v2/tokens) with the `read:users` scope.
+
+  ```js
+  const request = require('request');
+  class Auth0Client {
+    ...
+    async getUsersWithSameVerifiedEmail({ sub, email }) {
+      return await this.request({
+        url: `${process.env.ISSUER_BASE_URL}/api/v2/users`,
+        qs: {
+          search_engine: "v3",
+          q: `email:"<%= "${email}" %>" AND email_verified:true -user_id:"<%= "${sub}" %>"`,
+      } ,
+    });
+  }
+  ```
+
+3. Prompt the user to link accounts. 
+
+    If Auth0 returns one or more records with matching email addresses, the user will see the list along with the following message prompting them to link the accounts.
+
+    If the user wants to link a given account, they can click **Link** next to the appropriate account.
+
+![WebApp User Settings Example](/media/articles/link-accounts/account-linking-webapp-small.png)
+
+4. When the user clicks **Link**, your application will ask the user to authenticate with the target account, and then perform account linking. 
+
+    ::: warning
+    To retain and merge the `user_metadata` from the secondary account, you must retrieve and merge it into the metadata for the primary account before calling the API endpoint. After the accounts are linked, the metadata for the secondary account is discarded. 
+    
+    When calling account linking, you can select which identity will be used as the primary account and which as the secondary. This choice will depend on which set of attributes you want to retain in the primary profile.
+    :::
+
+    The following code snippet shows how to verify and merge metadata:
+
+  ```js
+  async function accountLink(req, res, next) {
+    const {
+      linking: { targetUserId },
+    } = req.appSession;
+    const { sub: authenticatedTargetUserId } = req.openidTokens.claims();
+    if (authenticatedTargetUserId !== targetUserId) {
+      debug(
+        "Skipping account linking as the authenticated user(%s)  is different than target linking user (%s)",
+        authenticatedTargetUserId,
+        targetUserId
+      );
+      set(req, Errors.WrongAccount);
+      return next();
+    }
+
+    debug(
+      "User %s succesfully authenticated. Account linking with %s... ",
+      authenticatedTargetUserId,
+      targetUserId
+    );
+    const { id_token: targetIdToken } = req.openidTokens;
+    const { sub: primaryUserId } = req.appSession.claims;
+
+    try {
+      await mergeMetadata(primaryUserId, authenticatedTargetUserId);
+      await auth0Client.linkAccounts(primaryUserId, targetIdToken);
+      debug("Accounts linked.");
+    } catch (err) {
+      debug("Linking failed %o", err);
+    } finally {
+      next();
+    }
+  }
+  ```
+
+5. Your application calls the Auth0 Management API's [Link a User Account endpoint](/api/v2#!/Users/post_identities) using a [Management API Access Token](/api/management/v2/tokens) with the `update:users` scope.
+
+```js
+async function accountLink(req, res, next) {
+  const {
+    linking: { targetUserId },
+  } = req.appSession;
+  const { sub: authenticatedTargetUserId } = req.openidTokens.claims();
+  if (authenticatedTargetUserId !== targetUserId) {
+    set(req, Errors.WrongAccount);
+    return next();
+  }
+
+  const { id_token: targetIdToken } = req.openidTokens;
+  const { sub: primaryUserId } = req.appSession.claims;
+
+  try {
+    await mergeMetadata(primaryUserId, authenticatedTargetUserId);
+    await auth0Client.linkAccounts(primaryUserId, targetIdToken);
+  } catch (err) {
+    debug("Linking failed %o", err);
+  } finally {
+    next();
+  }
+}
+```
+
+## Metadata merge example
+
+The following example shows explicitly how the `user_metadata` and `app_metadata` from the secondary account gets merged into the primary account using the [Node.js Auth0 SDK for API V2](https://github.com/auth0/node-auth0/tree/v2).
+
+```js
+/*
+ * Recursively merges user_metadata and app_metadata from secondary into primary user.
+ * Data of primary user takes preponderance.
+ * Array fields are joined.
+ */
+async function mergeMetadata(primaryUserId, secondaryUserId) {
+  // load both users with metedata.
+  const [primaryUser, secondaryUser] = await Promise.all(
+    [primaryUserId, secondaryUserId].map((uid) => auth0Client.getUser(uid))
+  );
+
+  const customizerCallback = function (objectValue, sourceValue) {
+    if (_.isArray(objectValue)) {
+      return sourceValue.concat(objectValue);
+    }
+  };
+  const mergedUserMetadata = _.merge(
+    {},
+    secondaryUser.user_metadata,
+    primaryUser.user_metadata,
+    customizerCallback
+  );
+  const mergedAppMetadata = _.merge(
+    {},
+    secondaryUser.app_metadata,
+    primaryUser.app_metadata,
+    customizerCallback
+  );
+  await auth0Client.updateUser(primaryUserId, {
+    user_metadata: mergedUserMetadata,
+    app_metadata: mergedAppMetadata,
+  });
+}
+```
+
+<%= include('../_includes/_account-linking-id-tokens.md') %>
+
+## Keep reading
+
+* [User Account Linking Overview](/users/concepts/overview-user-account-linking)
+* [Link User Accounts](/users/guides/link-user-accounts)
+* [Unlink User Accounts](/users/guides/unlink-user-accounts)
+* [User Initiated Account Linking - Client-Side Implementation](/users/references/link-accounts-client-side-scenario)
diff --git a/ja-jp/articles/users/references/user-data-storage-scenario.md b/ja-jp/articles/users/references/user-data-storage-scenario.md
new file mode 100644
index 0000000000..ee6a0624e3
--- /dev/null
+++ b/ja-jp/articles/users/references/user-data-storage-scenario.md
@@ -0,0 +1,277 @@
+---
+title: User Data Storage Scenario
+description: Recommendations for using Auth0 storage mechanisms.
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - data-storage
+    - swift
+    - ios
+    - nodejs
+    - api
+contentType: reference
+useCase: manage-users
+---
+# User Data Storage Scenario
+
+Auth0 provides a sample app, a mobile music application, that reflects the end-to-end user experience when using Auth0 with an custom external database. The sample app is an iOS app created using the [Auth0 iOS seed project](/quickstart/native/ios-swift). The backend uses the [Node.js API](/quickstart/backend/nodejs). 
+
+For a visualization of the application's overall structure, see the [Mobile + API architecture scenario](/architecture-scenarios/application/mobile-api).
+
+## Metadata
+
+### App metadata
+
+The following data points from our mobile music application are appropriate to store in `app_metadata`:
+
+* User's subscription plan
+* User's right (or lack thereof) to edit featured playlists
+
+These two data points should be stored in `app_metadata` instead of `user_metadata` because they should not be directly changeable by the user.
+
+### User metadata
+
+The following data points from our mobile music application are appropriate to store in `user_metadata`:
+
+* Application preferences;
+* Any details chosen by the user to alter their experience of the app upon login.
+
+Note that, unlike the data points for `app_metadata`, the user can easily and readily change those stored in `user_metadata`.
+
+We can let the user change their `displayName`, which is the name the user sees upon logging in and is displayed to other users of the app.
+
+To display the user's chosen identifier whenever they log in, we use a rule to get the `user.user_metadata` value.
+
+```js
+function(user, context, callback){
+  user.user_metadata = user.user_metadata || {};
+  user.user_metadata.displayName = user.user_metadata.displayName || "user";
+
+  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
+    .then(function(){
+      callback(null, user, context);
+    })
+    .catch(function(err){
+      callback(err);
+    });
+}
+```
+
+Here's a look at the screen the user would use to change their `displayName`:
+
+![](/media/articles/tutorials/data-scenarios/4-settings.png)
+
+To save the changes to the database, the application makes a call to the [Get a User](/api/management/v2#!/Users/get_users_by_id) endpoint of the [Management API](/api/management/v2) to identify the appropriate user:
+
+```har
+{
+	"method": "GET",
+	"url": "https://YOURACCOUNT.auth0.com/api/v2/users/user_id",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer YOUR_ID_TOKEN_HERE"
+	}]
+}
+```
+
+This is followed by a call to the [Update a User](/api/management/v2#!/Users/patch_users_by_id) endpoint to update the `user_metadata` field:
+
+```har
+{
+  "method": "PATCH",
+  "url": "https://${account.namespace}/api/v2/users/user_id",
+  "httpVersion": "HTTP/1.1",
+  "cookies": [],
+  "headers": [{
+    "name": "Authorization",
+    "value": "Bearer YOUR_ACCESS_TOKEN"
+  }, {
+    "name": "Content-Type",
+    "value": "application/json"
+  }],
+  "queryString": [],
+  "postData": {
+    "mimeType": "application/json",
+    "text": "{\"user_metadata\": {\"displayName\": \"J-vald3z\"}"
+  },
+  "headersSize": -1,
+  "bodySize": -1,
+  "comment": ""
+}
+```
+
+You must replace `YOUR_ACCESS_TOKEN` with a [Management API Access Token](/api/management/v2/concepts/tokens).
+
+## User data permission rules
+
+Use [rules](/rules) to implement permissions on whether a user can edit featured playlists or not.
+
+### Assign Playlist Editor role
+
+The first rule sends a request to our Node API, which then queries the database connected to Heroku to check how many plays the user’s playlist has. If the number is 100 or greater, we assign `playlist_editor` as a value in the `roles` array in `app_metadata`.
+
+```js
+function (user, context, callback) {
+
+  var request = require('request');
+
+  user.app_metadata = user.app_metadata || {};
+  user.app_metadata.roles = user.roles || [];
+
+  var CLIENT_SECRET = configuration.AUTH0_CLIENT_SECRET;
+  var CLIENT_ID = configuration.AUTH0_CLIENT_ID;
+
+  var scope = {
+    user_id: user.user_id,
+    email: user.email,
+    name: user.name
+  };
+
+  var options = {
+    subject: user.user_id,
+    expiresInMinutes: 600,
+    audience: CLIENT_ID,
+    issuer: 'https://example.auth0.com'
+  };
+
+  var id_token = jwt.sign(scope, CLIENT_SECRET, options);
+
+  var auth = 'Bearer ' + id_token;
+
+  request.get({
+    url: 'https://example.com/playlists/getPlays',
+    headers: {
+       'Authorization': auth,
+      'Content-Type': 'text/html'
+    },
+    timeout: 15000
+  }, function(err, response, body){
+    if (err)
+      return callback(new Error(err));
+    var plays = parseInt(body, 10);
+
+    if (plays >= 100 && user.roles.indexOf('playlist_editor') < 0){
+      user.app_metadata.roles.push('playlist_editor');
+      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+        .then(function(){
+          callback(null, user, context);
+        })
+        .catch(callback);
+    }
+
+    else if (plays < 100 && user.roles.indexOf('playlist_editor') >= 0){
+      user.app_metadata.roles = [];
+      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
+        .then(function(){
+          callback(null, user, context);
+        })
+        .catch(callback);
+    }
+    else{
+      callback(null, user, context);
+    }
+
+  });
+
+}
+```
+
+### Scope parameter specifies role 
+
+The second rule gets the `app_metadata` field and assigns the `roles` array to a field in the user object so it can be accessed without calling `app_metadata` on the application. The `scope` parameter can then specify `roles` upon the user logging in without including everything in `app_metadata` in the user object:
+
+```js
+function(user, context, callback) {
+   if (user.app_metadata) {
+      user.roles = user.app_metadata.roles;
+   }
+   user.roles = user.roles || [];
+   callback(null, user, context);
+}
+```
+
+After we've implemented these two rules, the app recognizes whether the user is a playlist editor or not and changes the welcome screen accordingly. If `playlist_editor` is in the `roles` array stored in the user's `app_metadata`, the user will be welcomed as an **EDITOR** after signing in:
+
+![](/media/articles/tutorials/data-scenarios/3-home.png)
+
+### Associate a user's music with the user
+
+We need to associate a user's music with that user, but this information is not required for authentication. Here's how to store this information in a separate database that is integrated with the backend of the application.
+
+The user's unique identifier is their [user_id](/users/normalized#storing-user-data). Here is a sample row from the `songs` table in our database:
+
+| song_id   | songname           | user_id                    |
+| --------- | ------------------ | -------------------------- |
+| 1         | Number One Hit     | google-oauth2|xxxyyy123    |
+
+The Node.js backend authenticates requests to the URI associated with getting the user’s personal data from the database by validating a JSON Web Token.
+
+::: note
+[Learn about token-based authentication and how to implement JWT in your Applications.](/tokens/concepts/jwts)
+:::
+
+Here is the code implementing JWT validation from the [Node.js seed project](/quickstart/backend/nodejs):
+
+```js
+var genres = require('./routes/genres');
+var songs = require('./routes/songs');
+var playlists = require('./routes/playlists');
+var displayName = require('./routes/displayName');
+
+var authenticate = jwt({
+  secret: process.env.AUTH0_CLIENT_SECRET,
+  audience: process.env.AUTH0_CLIENT_ID,
+  algorithms: ['RS256']
+});
+
+app.use('/genres', authenticate, genres);
+app.use('/songs', authenticate, songs);
+app.use('/playlists', authenticate, playlists);
+app.use('/displayName', authenticate, displayName);
+```
+
+We can add functionality to handle different data requests from our Application. For example, if we receive a `GET` request to `/secured/getFavGenre`, the API calls the `queryGenre()` function, which queries the database for and responds with the user’s favorite genre.
+
+```swift
+@IBAction func getGenre(sender: AnyObject) {
+        let request = buildAPIRequest("/genres/getFav", type:"GET")
+        let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {[unowned self](data, response, error) in
+            let genre = NSString(data: data!, encoding: NSUTF8StringEncoding)
+            dispatch_async(dispatch_get_main_queue(), {
+                self.favGenre.text = "Favorite Genre:  \(genre!)"
+            })
+        }
+        task.resume()
+    }
+```
+
+::: note
+The function `buildAPIRequest()` takes the path and HTTP method of the request as parameters and builds a request using the base URL of our Node.js API that's hosted on Heroku.
+:::
+
+In the Application, the `getGenre()` function makes a request to the API and changes the app's interface to display the request response to `/genres/getFav`. The backend retrieves the required data for this action using the `queryGenre()` function and returns the results to the Application:
+
+```js
+function queryGenre(user_id, res){
+
+  db.connect(process.env.DATABASE_URL, function(err, client) {
+  if (err) throw err;
+
+  client
+    .query('SELECT fav_genre as value FROM user_data WHERE user_id = $1', [user_id], function(err, result) {
+
+      if(err) {
+        return console.error('error running query', err);
+      }
+      res.send(result.rows[0].value);
+    });
+  });
+
+};
+```
+
+## Keep reading
+
+* [User Data Storage Best Practices](/best-practices/user-data-storage-best-practices)
+* [Rules](/rules)
diff --git a/ja-jp/articles/users/references/user-migration-scenarios.md b/ja-jp/articles/users/references/user-migration-scenarios.md
new file mode 100644
index 0000000000..fa834ca472
--- /dev/null
+++ b/ja-jp/articles/users/references/user-migration-scenarios.md
@@ -0,0 +1,314 @@
+---
+title: User Migration Scenarios
+description: User migrations scenarios from various platforms using multiple methods.
+toc: true 
+topics:
+  - users
+  - user-management
+  - migrations
+  - gigya
+  - okta
+  - stormpath
+contentType:
+  - how-to
+useCase:
+  - manage-users
+  - migrate
+---
+# User Migration Scenarios
+
+Here are some sample scenarios for migrating users from Gigya, Okta, and Stormpath to Auth0. Each of these scenarios assumes that you have accounts on those platforms.
+
+## Prerequisites
+
+Configure the custom database connection.
+
+1. Create a new database connection in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard. 
+   
+![Create a new DB Connection](/media/articles/users/migrations/create-database-connection.png)
+
+2. Connect the database to the application. Navigate to the **Applications** tab of your database settings, under the **Applications Using This Connection** heading you can enable the database connection for each application.
+   
+![Database Connection Applications](/media/articles/users/migrations/enable-clients.png)
+
+## Scenario 1: Migrate Users from Gigya to Auth0
+
+1. Export Gigya users. Use [Gigya's IdentitySync](https://developers.gigya.com/display/GD/IdentitySync) to transform and export user data to match a target schema. For more details on this process, see [Gigya IdentitySync: Using IdentitySync](https://developers.gigya.com/display/GD/IdentitySync#IdentitySync-apiUsingIdentitySync).
+
+   Follow the instructions to transform your Gigya database's user data to the correct [schema](/users/references/bulk-import-database-schema-examples) and export the transformed data to JSON format.
+
+2. Import your Gigya users into Auth0 with the User Import/Export Extension or the Management API.
+   - Go to the [Extensions](${manage_url}/#/extensions) section of the Dashboard. Select the **User Import / Export** extension and install it. Once the extension is installed, you can click it to open an import/export interface that looks like this:
+
+     ![User Import/Export Extension](/media/articles/extensions/user-import-export/import.png)
+
+     Drag your exported Gigya users JSON file into the designated upload area and select the database you created earlier. Click the **Start Importing Users** button to begin your import. For more information, see [User Import/Export Extension](//extensions/user-import-export).
+   
+   - Alternatively, you can use the Management API. [Create a job](/api/management/v2#!/Jobs/post_users_imports) to import your users to Auth0. For detailed instructions, see [Bulk User Imports](/users/guides/bulk-user-imports).
+
+## Scenario 2: Migrate Users from Okta to Auth0
+
+1. Navigate to the  **Settings** page for your database connection, and enable the **Import Users to Auth0** option:
+
+![Enable Import Users](/media/articles/dashboard/connectionsdatabase/connections-db-settings-main-2.png)
+
+2. Create the [Login script](/connections/database/custom-db/templates/login). The **Login** script is executed when a user attempts to log in, but their account is not found in the Auth0 database. You will need to create a script which will call the Okta [Primary Authentication](https://developer.okta.com/docs/api/resources/authn.html#primary-authentication) endpoint, passing the email and password as the `username` and `password` parameters.
+
+On successful authentication, Okta will return an [Authentication Transaction object](https://developer.okta.com/docs/api/resources/authn.html#authentication-transaction-model), containing the [user's profile](https://developer.okta.com/docs/api/resources/authn.html#user-profile-object) in the [embedded resources](https://developer.okta.com/docs/api/resources/authn.html#embedded-resources). You can then simply extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function login (email, password, callback) {
+  // Replace YOUR-OKTA-DOMAIN with your own Okta domain
+  var url = 'https:/YOUR-OKTA-DOMAIN/api/v1/authn';
+
+  // Make the POST request to authenticate a user
+  request({
+    url: url,
+    method: 'POST',
+    headers: {
+      'Content-Type': 'application/json',
+      'Accept': 'application/json'
+    },
+    body: {
+      username: email,
+      password: password,
+      options: {
+        multiOptionalFactorEnroll: false,
+        warnBeforePasswordExpired: false
+      }
+    },
+    json: true
+  }, function (error, response, body) {
+    // Ensure we have a successful response
+    if (response.statusCode !== 200) return callback();
+    
+    // Get the user from the response body
+    var user = body._embedded.user;
+    
+    // Set the data we want to store in Auth0 and migrate the user
+    return callback(null, {
+        user_id : user.id,
+        username: user.profile.login,
+        email: user.profile.login,
+        // We set the users email_verified to true as we assume if they were a valid
+        // user in Okta, they have already verified their email
+        // If this field is not set, the user will get an email asking them to verify
+        // their account
+        email_verified: true,
+        name: user.profile.firstName + ' ' + user.profile.lastName
+      });
+  });
+}
+```
+
+You can click the **Try** button above the script to test and see whether the script works.
+
+3. Create the Get User Script. The **Get User** script is executed when the user attempts to do a password reset but their account is not found in the Auth0 database. You will need to create a script which will call the Okta [Get User with Login](https://developer.okta.com/docs/api/resources/users.html#get-user-with-login) endpoint, passing the user's email as the `login` parameter.
+
+You will also need to [Create an API token](https://developer.okta.com/docs/api/getting_started/getting_a_token.html) which must be passed to this endpoint in the `Authorization` header.
+
+If successful, Okta will return a [User object](https://developer.okta.com/docs/api/resources/users.html#user-model) with the user's information. Once again, you can extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function getByEmail(email, callback) {
+  // Replace YOUR-OKTA-DOMAIN with your own Okta domain
+  var url = 'https://YOUR-OKTA-DOMAIN/api/v1/users/' + encodeURIComponent(email);
+
+  // Make a GET request to find a user by email
+  // Replace YOUR-OKTA-API-TOKEN with an Okta API Token 
+  // (see https://developer.okta.com/docs/api/getting_started/getting_a_token.html) 
+  request({
+    url: url,
+    method: 'GET',
+    headers: {
+      'Content-Type': 'application/json',
+      'Accept': 'application/json',
+      'Authorization': 'SSWS ' + 'YOUR-OKTA-API-TOKEN'
+    },
+    json: true
+  }, function (error, response, body) {
+    // Ensure we have a successful response
+    if (response.statusCode !== 200) return callback();
+
+    // Set the data we want to store in Auth0 and migrate the user
+    return callback(null, {
+      user_id: body.id,
+      username: body.profile.login,
+      email: body.profile.login,
+      email_verified: true,
+      name: body.profile.firstName + ' ' + body.profile.lastName
+    });
+  });
+}
+```
+
+Click the **Try** button above the script to test and see whether the script works.
+
+4. Test the custom database connection to ensure that it works.
+
+   - Click on **Try connection**:
+
+      ![Try Connection](/media/articles/connections/database/okta/try-connection.png)
+
+      The Auth0 Lock widget will appear. Enter the email address and password for the Okta user, and click on **Log In**:
+
+      ![Try Connection - Lock](/media/articles/connections/database/okta/try-connection-lock.png)
+
+      You should see a web page indicating that the connection works, with information about the user:
+
+      ![Try Connection - Success](/media/articles/connections/database/okta/try-connection-success.png)
+
+   - Navigate to the [Users](${manage_url}/#/users) section in the Auth0 Dashboard to see the newly imported users listed:
+
+     ![Imported User](/media/articles/connections/database/okta/user-imported.png)
+
+## Scenario 3: Migrate users from Stormpath to Auth0
+
+1. Navigate to the **Settings** page for your database connection, and enable the **Import Users to Auth0** option:
+
+   ![Enable Import Users](/media/articles/dashboard/connectionsdatabase/connections-db-settings-main-2.png)
+
+2. Navigate to the **Applications** tab of your database connection. Here you can choose the applications which will use the database connection.
+
+   ![Database Connection Applications](/media/articles/users/migrations/enable-clients.png)
+
+3. Create the Login Script. The **Login** script is executed when a user attempts to log in, but their account is not found in the Auth0 database. You will need to create a script that calls Stormpath's API to authenticate the user, passing the user credentials as the `username` and `password` parameters.
+
+   On successful authentication, the response from Stormpath will include the user account URL. Perform a second request to the account URL to retrieve the user's information. You can then extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function login(username, password, callback) {
+  // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
+  var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/loginAttempts';
+
+  // Stormpath requires the user credentials be passed in as a base64 encoded message
+  var message = username + ':' + password;
+  var pass = new Buffer(message).toString('base64');
+
+  // Here we are making the POST request to authenticate a user
+  request({
+    url: url,
+    method: 'POST',
+    auth: {
+      // Your API Client ID
+      user: '{STORMPATH-CLIENT-ID}',
+      // YOUR API Client Secret
+      password: '{STORMPATH-CLIENT-SECRET}'
+    },
+    headers: {
+      'Content-Type': 'application/json'
+    },
+    json: {
+      type: 'basic',
+      // Passing in the base64 encoded credentials
+      value: pass
+    }
+  }, function (error, response, body) {
+    // If response is successful we'll continue
+    if (response.statusCode !== 200) return callback();
+    // A successful response will return a URL to get the user information
+    var accountUrl = body.account.href;
+
+    // We'll make a second request to get the user info. This time it will be a GET request
+    request({
+      url: accountUrl,
+      method: 'GET',
+      auth: {
+        // Your API Client ID
+        user: '{STORMPATH-CLIENT-ID}',
+        // YOUR API Client Secret
+        password: '{STORMPATH-CLIENT-SECRET}'
+      }
+    }, function (errorUserInfo, responseUserInfo, bodyUserInfo) {
+      // If we get a successful response, we'll process it
+      if (responseUserInfo.statusCode !== 200) return callback();
+
+      var parsedBody = JSON.parse(bodyUserInfo);
+      // To get the user identifier, we'll strip out the Stormpath API
+      var id = parsedBody.href.replace('https://api.stormpath.com/v1/accounts/', '');
+
+      // Finally, we'll set the data we want to store in Auth0 and migrate the user
+      return callback(null, {
+        user_id : id,
+        username: parsedBody.username,
+        email: parsedBody.email,
+        // We set the users email_verified to true as we assume if they were a valid
+        // user in Stormpath, they have already verified their email
+        // If this field is not set, the user will get an email asking them to verify
+        // their account
+        email_verified: true,
+        // Add any additional fields you would like to carry over from Stormpath
+      });
+    });
+  });
+}
+```
+
+Click the **Try** button above the script to test and see whether the script works.
+
+4. Create the Get User Script. The **Get User** script is executed when the user attempts to do a password reset but their account is not found in the Auth0 database. You will need to create a script which will call the `/accounts` endpoint of the Stormpath API, passing the user's email as the `email` parameter.
+
+   If successful, Stormpath will return a the user's information. You can extract the user's information and pass it to Auth0 in the callback function.
+
+```js
+function getByEmail(email, callback) {
+  // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
+  var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/accounts';
+
+  request({
+    url: url,
+    method: 'GET',
+    auth: {
+      // Your API Client ID
+      user: '{STORMPATH-CLIENT-ID}',
+      // YOUR API Client Secret
+      password: '{STORMPATH-CLIENT-SECRET}'
+    },
+    qs: { q: email }
+  }, function (error, response, body) {
+    if (response.statusCode !== 200) return callback();
+
+    var parsedBody = JSON.parse(body);
+    var user = parsedBody.items[0];
+
+    if (!user) return callback();
+
+    var id = user.href.replace('https://api.stormpath.com/v1/accounts/', '');
+
+    return callback(null, {
+      user_id: id,
+      username: user.username,
+      email: user.email,
+      email_verified: true,
+      // Add any additional fields you would like to carry over from Stormpath
+    });
+  });
+}
+```
+
+   Click the **Try** button above the script to test and see whether the script works.
+
+5. Test the custom database connection to ensure that it works.
+
+   - Click on **Try connection**:
+
+     ![Try Connection](/media/articles/users/migrations/try-connection.png)
+
+     The Auth0 Lock widget will appear. Enter the email address and password for the Stormpath user, and click on **Log In**:
+
+     ![Try Connection - Lock](/media/articles/users/migrations/try-connection-lock.png)
+
+     You should see a web page indicating that the connection works, with information about the user:
+
+     ![Try Connection - Success](/media/articles/users/migrations/try-connection-success.png)
+
+   - Navigate to the [Users](${manage_url}/#/users) section in the Auth0 Dashboard, you will see the newly imported user listed:
+
+     ![Imported User](/media/articles/users/migrations/user-imported.png)
+
+## Keep reading
+
+* [Configure Automatic Migration from Your Database](/users/guides/configure-automatic-migration)
+* [Login Script Templates](/connections/database/custom-db/templates/login)
+* [Bulk User Imports](/users/guides/bulk-user-imports)
+* [User Import/Export Extension](/extensions/user-import-export)
diff --git a/ja-jp/articles/users/references/user-profile-structure.md b/ja-jp/articles/users/references/user-profile-structure.md
new file mode 100644
index 0000000000..3dddca16be
--- /dev/null
+++ b/ja-jp/articles/users/references/user-profile-structure.md
@@ -0,0 +1,75 @@
+---
+description: Lists the attributes that are available on the Auth0 user profile
+topics:
+    - users
+    - user-management
+    - user-profiles
+    - user-profile-structure
+contentType: reference
+useCase: manage-users
+v2: true
+---
+
+# User Profile Structure
+
+Auth0's normalized user profile consists of a few different components: 
+
+* **Details**: Core User Profile object, which contains basic info, such as name, email, and timestamp of the user's latest login, in pre-defined attributes. This object may also contain info from a user's source [connection](/connections). Most of the user attributes are root attributes (attributes stored at the first, or root, level of the `user` object), and some of these are editable.
+
+* **Metadata**: Two sub-objects that operate as secondary storage to store additional user info in customizable attributes: `user_metadata` and `app_metadata`. See [Metadata](/users/concepts/overview-user-metadata) for more information, including when to use `app_metadata` and `user_metadata`.
+
+## User profile attributes
+
+The following attributes are available on the user profile. Many are root attributes (attributes stored at the first, or root, level of the `user` object), and some may be updated, imported, and exported, as noted below.
+
+::: panel Blacklist user attributes
+If there are user fields that should not be stored by Auth0 due to privacy reasons, you can blacklist the attributes you do not want persisting in Auth0 databases. For details, see [Blacklist User Attributes](/security/blacklisting-attributes).
+:::
+
+::: warning
+<%= include('../../_includes/_users_update_normalized_profile_attributes') %>
+:::
+
+| Name             | Type | Description | [Search?](/users/search) | [Update?](/api/management/guides/users/update-root-attributes-users) | [Import?](/users/guides/bulk-user-imports) | [Upsert during import?](/users/guides/bulk-user-imports#request-bulk-import) | [Export?](/users/guides/bulk-user-exports) |
+|-|-|-|-|-|-|-|-|-|
+| `app_metadata`   | object | Custom fields that store info about a user that influences the user's access, such as support plan, security roles (if not using the Authorization Core feature set), or access control groups. For more info, see [Metadata Overview](/users/concepts/overview-user-metadata). | Y | Y | Y | Y | Y |
+| `blocked`        | boolean | Indicates whether the user has been blocked. Importing enables subscribers to ensure that users remain blocked when migrating to Auth0. | Y | Y | Y | N | Y |
+| `created_at`     | date time | Timestamp indicating when the user profile was first created. | Y | N | N | N | Y |
+| `email`          | text | (unique) The user's email address. | Y | Y | Y | N | Y |
+| `email_verified` | boolean | Indicates whether the user has verified their email address. | Y | Y | Y | Y | Y |
+| `family_name` | text | The user's family name. | Y | Y | Y | Y | Y |
+| `given_name` | text | The user's given name. | Y | Y | Y | Y | Y |
+| `identities`     | array (object) | <%= include('../_includes/_user-prop-identities.md') %> |  Y | N | N | N | Y |
+| `last_ip`       | text | IP address associated with the user's last login. | Y | N | N | N | Y |
+| `last_login`    | date time | Timestamp indicating when the user last logged in. If a user is blocked and logs in, the blocked session updates `last_login`. If you are using this property from inside a [Rule](/rules) using the `user` object, its value will be associated with the login that triggered the rule; this is because rules execute after login. | Y | N | N | N | Y |
+| `last_password_reset` | date time | Timestamp indicating the last time the user's password was reset/changed. At user creation, this field does not exist. This property is only available for Database connections. | N | N | N | N | N |
+| `logins_count` | integer | Number of times the user has logged in. If a user is blocked and logs in, the blocked session is counted in `logins_count`. | Y | N | N | N | Y |
+| `multifactor`   | text | List of multi-factor providers with which the user is enrolled. | N | N | N | N | Y |
+| `name`          | text | The user's full name. | Y | Y | Y | Y | Y |
+| `nickname`      | text | The user's nickname. | Y | Y | Y | Y | Y |
+| `phone_number` | text | The user's phone number. Only valid for users with SMS connections. | Y | Y | N | N | Y |
+| `phone_verified` | boolean | Indicates whether the user has been verified their phone number. Only valid for users with SMS connections. | Y | Y | N | N | Y |
+| `picture` | text | URL pointing to [the user's profile picture](/users/guides/change-user-pictures). | N | Y | Y | Y | Y |
+| `updated_at` | date time | Timestamp indicating when the user's profile was last updated/modified. Changes to `last_login` are considered updates, so most of the time, `updated_at` will match `last_login`. | Y | N | N | N | Y |
+| `user_id` | text | (unique) The user's identifier. Importing allows user records to be synchronized across multiple systems without using mapping tables. | Y | N | Y | N | Y |
+| `user_metadata` | object | Custom fields that store info about a user that does not impact what they can or cannot access, such as work address, home address, or user preferences. For more info, see [Metadata Overview](/users/concepts/overview-user-metadata). | Y | Y | Y | Y | Y |
+| `username` | text | (unique) The user's username. | Y | Y | Y | N | Y |
+
+::: note
+Three other fields are not technically part of the user profile, but may be of interest when importing users:
+
+* `password_hash` (text): Hashed password for the user's connection. When users are created, Auth0 uses [bcrypt](https://www.npmjs.com/package/bcrypt) to secure the password. Importing compatible hashed passwords allows users to retain their passwords, thereby providing a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds. Note that this field can only be provided when the user is first imported — it can not be updated later.
+* `custom_password_hash` (object): A more generic way to provide the users password hash. This can be used in lieu of the password_hash field when the users password hash was created with an alternate algorithm. Note that this field can only be provided when the user is first imported — it can not be updated later.
+* `password_set_date` (date time): Timestamp indicating when the password for the user's connection was set. At user creation, this field exists, and `last_password_reset` does not. If the user has reset their password, this field and `last_password_reset` are identical.
+:::
+
+## View user profile
+
+To view the user profile, navigate to [Users](${manage_url}/#/users) in the [Auth0 Dashboard](${manage_url}), and then click a user you want to view.
+
+## Keep reading
+
+* [Normalized User Profiles](/users/normalized)
+* [Metadata](/users/concepts/overview-user-metadata)
+* [View Users](/users/guides/view-users)
+* [Update User Profiles Using Your Database](/users/guides/update-user-profiles-using-your-database)
diff --git a/ja-jp/articles/users/search/index.yml b/ja-jp/articles/users/search/index.yml
new file mode 100644
index 0000000000..1a8c5c46c4
--- /dev/null
+++ b/ja-jp/articles/users/search/index.yml
@@ -0,0 +1,8 @@
+versioning:
+  baseUrl: users/search
+  current: v3
+  versions:
+    - v2
+    - v3
+  defaultArticles:
+    v3: index
\ No newline at end of file
diff --git a/ja-jp/articles/users/search/v2/index.md b/ja-jp/articles/users/search/v2/index.md
new file mode 100644
index 0000000000..df2b8516b9
--- /dev/null
+++ b/ja-jp/articles/users/search/v2/index.md
@@ -0,0 +1,141 @@
+---
+description: This page lists several examples of user search queries using query string syntax.
+crews: crew-2
+toc: true
+topics:
+  - users
+  - user-management
+  - search
+contentType:
+  - reference
+  - how-to
+  - index
+useCase:
+  - manage-users
+---
+# User Search
+
+::: version-warning
+For all deployment models except Private Cloud, user search v2 has reached its end of life as of **June 30, 2019**. For information on migrating from user search v2 to v3, see [Migrate from search engine v2 to v3](/users/search/v3/migrate-search-v2-v3).
+:::
+
+Auth0 allows you, as an administrator, to search for users using [Lucene Query Syntax](http://www.lucenetutorial.com/lucene-query-syntax.html).
+
+This document provides sample queries and demonstrates how you can search for users. We also suggest that you refer to [Query String Syntax](/api/management/v2/query-string-syntax) for more examples of query string syntax.
+
+::: warning
+The user search endpoint allows you to return a maximum of **10,000** users. For additional results, please use either the [User Export Job endpoint](/api/management/v2#!/Jobs/post_users_exports) or the [User Export Extension](/extensions/user-import-export).
+:::
+
+## Search for users using the Management API
+
+You can also search for users using the [Management API](/api/v2). Two of the easiest ways to do this is by either making use of the **API Explorer** or by using **Postman**. These two techniques are discussed briefly below, but please note that the Auth0 Management API is a REST API, so you can make API calls using anything that can make HTTP requests, or by using one of the [Auth0 SDKs](/support/matrix#sdks).
+
+In order to make requests to the Management API, you will need a token. Please refer to [Access Tokens for the Management API](/api/management/v2/tokens) for more information.
+
+### Search using the API Explorer
+
+To search users using the [Management API Explorer](/api/management/v2#!/Users/get_users), go to the **Users** section and then select **List or search users**. Scroll down to the `q` parameter. You can use any query string which uses the [query string syntax](/api/management/v2/query-string-syntax) in this field.
+
+![Searching users in API Explorer](/media/articles/api/search-users-api.png)
+
+### Search using Postman
+
+You can also search users using the Postman Collection for the Management API. Make sure you read [Using the Auth0 API with our Postman Collections](/api/postman) for more information on how to install the collection and also configure your Postman environment correctly.
+
+Once you have downloaded the collection, and configured your environment, select the **Management API** collection. Navigate to the **Users** folder and select **List or search users**. You can enter your query in the `q` parameter of the URL:
+
+![Searching users in Postman](/media/articles/api/postman/get-users-postman.png)
+
+::: note
+For general information on making Postman request, please refer to the [Postman documentation](https://www.getpostman.com/docs/requests).
+:::
+
+## Sorting search results 
+
+To sort the list of users returned from the Management API, you can make use of the `sort` parameter.  Use the format `field:order` for the value of the `sort` field, where `field` is the name of the field you want to sort by, and `order` can be `1` for ascending and `-1` for descending. For example, to sort users in ascending order by the `created_at` field you can pass the value of `created_at:1` for the `sort` parameter. Sorting by `app_metadata` or `user_metadata` is not supported.
+
+For more information on the `sort` and other parameters, please refer to the [Management API Explorer documentation](/api/v2#!/Users/get_users).
+
+::: note
+If there is no default sort field specified, some users that have never logged in, may not appear. No default sort field may also result in duplicate records returned and the order of list of users may appear random.
+:::
+
+## Exact matching and tokenization
+
+Because of the manner in which ElasticSearch handles tokenization on `+` and `-`, unexpected results can occur when searching by some fields. For example, when searching for a user whose `name` is `jane` (`name:"jane"`), the results will be both for `jane` and `jane-doe`, because both of these _contain_ the exact search term that you used. The difference may not affect some searches, but it will affect others, and provide unanticipated results.
+
+You can solve this problem either by using structured JSON in your metadata, or by using the raw subfield.
+
+## Using the `raw` subfield
+
+If you wish to avoid the potential pitfalls of analyzed data and search for an exact match to your term - an exact string comparison - then for some fields you can use the `raw` subfield, which will be `not_analyzed`.
+
+So, in the example `name.raw:"jane"`, the user data for `jane` would match, but `jane-doe` would not.
+
+The fields that support `raw` subfield queries are:
+
+* `identities.connection⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`identities.provider⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`identities.user_id⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`email⁠`
+* ⁠⁠⁠⁠`phone_number⁠⁠`
+* ⁠⁠⁠⁠`family_name⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`given_name⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`username⁠⁠⁠⁠`
+* ⁠⁠⁠⁠`name⁠⁠`
+* ⁠⁠⁠⁠`nickname`
+
+## Example queries
+
+Below are some example queries to illustrate the kinds of queries that are possible using the Management API V2.
+
+Use Case | Query
+---------|----------
+Search for all users whose name _contains_ "john" | `name:"john"`
+Search all users whose name _is_ exactly "john" | `name.raw:"john"`
+Search for all user names starting with "john" | `name:john*`
+Search for user names that start with "john" and end with "smith" | `name:john*smith`
+Search for all users whose email _is_ exactly "john@contoso\.com" | `email.raw:"john@contoso.com"`
+Search for all users whose email is exactly "john@contoso\.com" or "mary@contoso\.com" using `OR` | `email.raw:("john@contoso.com" OR "mary@contoso.com")`
+Search for users without verified email | `email_verified:false OR NOT _exists_:email_verified`
+Search for users who have the `user_metadata` field named `name` with the value of "John Doe" | `user_metadata.name:"John Doe"`
+Search for users from a specific connection or provider | `identities.provider:"google-oauth2"`
+Search for all users that have never logged in | `(NOT _exists_:logins_count OR logins_count:0)` 
+Search for all users who logged in before 2015 | `last_login:[* TO 2014-12-31]`
+Fuzziness: Search for terms that are similar to, but not exactly like, `jhn` | `name:jhn~`
+All users with more than 100 logins | `logins_count:>100`
+Logins count >= 100 and <= 200 | `logins_count:[100 TO 200]`
+Logins count >= 100 | `logins_count:[100 TO *]`
+Logins count > 100 and < 200 | `logins_count:{100 TO 200}`
+
+### Example request
+
+Below is an example request for searching all users whose email is exactly "john@contoso.com".
+
+```har
+{
+  "method": "GET",
+  "url": "https://${account.namespace}/api/v2/users",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer ACCESS_TOKEN" }
+  ],
+  "queryString": [
+    {
+      "name": "q",
+      "value": "email.raw:\"john@contoso.com\"",
+      "comment": "Query in Lucene query string syntax"
+    },
+    {
+      "name": "search_engine",
+      "value": "v2",
+      "comment": "Use 'v2' if you want to try our new search engine"
+    }
+  ]
+}
+```
+
+## Keep reading
+
+* [Query Syntax](/users/search/v2/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
diff --git a/ja-jp/articles/users/search/v2/query-syntax.md b/ja-jp/articles/users/search/v2/query-syntax.md
new file mode 100644
index 0000000000..69e99dbdf0
--- /dev/null
+++ b/ja-jp/articles/users/search/v2/query-syntax.md
@@ -0,0 +1,197 @@
+---
+toc: true
+description: This page explains query string syntax, which you can use to construct custom queries when searching using Auth0's Management API.
+crews: crew-2
+topics:
+  - users
+  - user-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-users
+---
+
+# User Search Query Syntax
+
+::: version-warning
+This document covers a previous version of user search. We recommend you use [user search v3](/users/search/v3).
+:::
+
+This page explains query string syntax, the mini-language used by the Query String Query.
+
+When searching using Auth0's [List or search users](/api/v2/#!/Users/get_users) endpoint, you can construct custom queries using this syntax for the value of the `q` field.
+
+The query string is parsed into a series of *terms* and *operators*. A term can be a single word  (`john` or `smith`) or a phrase surrounded by double quotes (`"john smith"`) which will match all the words in the phrase in the same order.
+
+## Searchable fields
+
+You can search for users using the following fields:
+
+* All the [normalized user profile](/users/normalized/auth0/normalized-user-profile-schema) fields
+
+* __Only__ the profile information under the `user_metadata` object:
+  - `name`
+  - `nickname`
+  - `given_name`
+  - `family_name`
+
+::: warning
+New tenants, starting September 1st 2017, cannot search any of the `app_metadata` fields. Paid tenants (that is, tenants that have a credit card associated in the [Dashboard](${manage_url}/#/tenant/billing/payment)) that were created up to August 31st 2017, can search using the `app_metadata` fields.
+Note that [Search v3](/users/search/v3/query-syntax) does not have this restriction.
+:::
+For more information, see the [Metadata Overview](/users/concepts/overview-user-metadata).
+
+### Field name examples
+
+Some examples of query string syntax are:
+
+* Where the `created_at` field contains `2016`: `created_at:2016`
+
+* Where the `user_name` field contains `john` or `smith`. If you omit the OR operator the default operator will be used.
+
+    `user_name: (john OR smith)`
+    `user_name: (john smith)`
+
+* Where the `user_name` field contains the exact phrase `"john smith"`: `user_name: "john smith"`
+
+* Where the field `nickname` has no value or is missing: `NOT _exists_: nickname`
+
+* Where the field `nickname` has any non-null value: `_exists_: nickname`
+
+* Your query can search across more than one field by using the `AND` & `OR` condition. Where the username field is exactly `"john"` AND the field `nickname` has any non-null value: `username: "john" AND _exists_: nickname`
+
+## Wildcards
+
+Wildcard searches can be run on individual terms, using `?` to replace a single character, and `*` to replace zero or more characters: `2016-0?-*`
+
+Note that certain wildcard queries will require an enormous amount of memory and perform poorly. (For example, imagine how many terms need to be queried to match the query string `"a* b* c*"`.)
+
+## Regular expressions
+
+Regular expression patterns can be embedded in the query string by wrapping them in forward-slashes ("/"): `name:/joh?n(ath[oa]n)/`
+
+::: note
+A detailed explanation of the supported regular expression syntax is explained on the Elastic's site at [Regular Expression Syntax](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html#regexp-syntax).
+:::
+
+## Fuzziness
+
+You can search for terms that are similar to, but not exactly like, your search terms using the `~` as a "fuzzy" operator: `oauth~`
+
+This is useful for commonly misspelled fields.
+
+## Proximity searches
+
+While a phrase query (eg `"john smith"`) matches all of the terms in  the exact same order, a proximity query allows the specified words to be further apart or in a different order. In the same way that a fuzzy query can specify a maximum edit distance between characters in a word, a proximity search allows you to specify a maximum distance between words in a phrase: `"fox quick"~5`
+
+The closer the text in a field is to the original order specified in the query string, the more relevant that result is ranked. When compared to the above example query, the phrase `"quick fox"` would be considered more relevant than `"quick brown fox"`.
+
+## Ranges
+
+Inclusive ranges are specified with square brackets: `[min TO max]` and exclusive ranges with curly brackets: `{min TO max}`. Curly and square brackets can be combined in the same range expression: `logins_count:[100 TO 200}`.
+
+Ranges can be specified for date, numeric or string fields.
+
+Some examples of range queries are:
+
+* Last login date of 2015:
+
+    `last_login:[2015-01-01 TO 2015-12-31]`
+
+* Users who have logged in between 1-5 times:
+
+    `logins_count:[1 TO 5]`
+
+* Last login between two dates, excluding the first and last day:
+
+    `last_login:{2012-01-01 TO 2012-12-31}`
+
+* Users that have logged on over 10 times:
+
+    `logins_count:[10 TO *]`
+
+* Logins before 2015:
+
+    `last_login{* TO 2015-01-01}`
+
+Curly and square brackets can be combined in the same range expression:
+
+* Logins count > 100 and < 200:
+
+    `logins_count:[100 TO 200}`
+
+For ranges with one side unbounded, you can use the following syntax:
+
+`logins_count:>10`
+`logins_count:>=10`
+`logins_count:<10`
+`logins_count:<=10`
+
+To combine an upper and lower bound with the simplified syntax, you need to join two clauses with an `AND` operator:
+
+`logins_count:(>=10 AND <20)`
+`logins_count:(+>=10 +<20)`
+
+The parsing of ranges in query strings can be complex and error prone. It is more reliable to use an explicit [range query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html).
+
+## Boosting
+
+Use the boost operator ^ to make one term more relevant than another. For instance, if you want to find all documents about foxes, but are especially interested in quick foxes:
+
+`quick^2 fox`
+
+The default *boost* value is 1, but it can be any positive floating-point number. Boost values between 0 and 1 reduce relevance of the matching result.
+
+Boosts can also be applied to phrases or groups:
+
+`"john smith"^2   (foo bar)^4`
+
+## Boolean operators
+
+By default, all terms are optional as long as one term matches. A search for `foo bar baz` will find any document that contains one or more of `foo` or `bar` or `baz`.
+
+Use of the `default_operator`, which allows you to force all terms to be required, is [discussed above](#field-name-examples). However, there are Boolean operators that can be used in the query string itself for more control.
+
+The preferred operators are `+` (this term *must* be present) and `-` (this term *must not* be present). All other terms are optional. For example, this query:
+
+`quick brown +fox -news`
+
+states that:
+
+* `fox` must be present
+* `news` must not be present
+* `quick` and `brown` are optional but their presence will increase the relevance of the result.
+
+The familiar operators `AND`,` OR` and `NOT `(also written `&&`,`||` and `!`) are also supported. However, the effects of these operators can be more complicated than is obvious at first. `NOT` takes precedence over `AND`, which takes precedence over `OR`. While the `+` and `-` only affect the term to the right of the operator, `AND` and `OR` can affect both the terms to the left and to the right.
+
+## Grouping
+
+Multiple terms or clauses can be grouped together with parentheses to form sub-queries:
+
+`(quick OR brown) AND fox`
+
+Groups can be used to target a particular field, or to boost the result of a sub-query:
+
+`status:(active OR pending) title:(full text search)^2`
+
+## Reserved characters
+
+If you need to use any of the characters which function as operators in the query itself as literal text (not as operators), then you must escape them with a leading backslash. For instance, to search for "(1+1)=2", you would need to write your query as `\(1\+1\)\=2`.
+
+The reserved characters are: `+ - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /`
+
+Failing to escape these special characters correctly could lead to a syntax error which will prevent your query from executing correctly.
+
+## Empty query
+
+If the query string is empty or contains only whitespaces, the query will yield an empty result set.
+
+## Additional Information
+
+For example queries for searching users, see [Users Search](/api/v2/user-search).
+
+::: note
+The preceding information is adapted from Elastic's [Elasticsearch Reference](http://elastic.co).
+:::
diff --git a/ja-jp/articles/users/search/v3/_valid-access-token.md b/ja-jp/articles/users/search/v3/_valid-access-token.md
new file mode 100644
index 0000000000..5093842c08
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/_valid-access-token.md
@@ -0,0 +1,3 @@
+## Prerequisite
+
+To use the user search endpoints, you'll need to obtain a valid [Access Token](/api/management/v2/tokens) and provide it in the header of your call (replace the `YOUR_MGMT_API_ACCESS_TOKEN` placeholder value).
diff --git a/ja-jp/articles/users/search/v3/get-users-by-email-endpoint.md b/ja-jp/articles/users/search/v3/get-users-by-email-endpoint.md
new file mode 100644
index 0000000000..ca3b478de6
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/get-users-by-email-endpoint.md
@@ -0,0 +1,85 @@
+---
+title: Retrieve Users with the Get Users by Email Endpoint 
+description: Learn how to retrieve lists of users using the get-users-by-email endpoint. 
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users by Email Endpoint 
+
+The [`GET /api/v2/users-by-email` endpoint](/api/management/v2#!/Users_By_Email/get_users_by_email) allows you to search for users using their email addresses. The search looks for an exact match to the provided email address and is case-sensitive.
+
+This endpoint is **immediately consistent**, and as such, we recommend that you use this endpoint for:
+
+* User searches run during the authentication process. 
+* User searches run as part of the account linking process.
+
+<%= include('./_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users-by-email?email=USER_EMAIL_ADDRESS",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }]
+}
+```
+
+### Sample results 
+
+```json
+[
+  {
+    "email": "john.doe@gmail.com",
+    "email_verified": false,
+    "username": "johndoe",
+    "phone_number": "+199999999999999",
+    "phone_verified": false,
+    "user_id": "usr_5457edea1b8f33391a000004",
+    "created_at": "",
+    "updated_at": "",
+    "identities": [
+      {
+        "connection": "Initial-Connection",
+        "user_id": "5457edea1b8f22891a000004",
+        "provider": "auth0",
+        "isSocial": false
+      }
+    ],
+    "app_metadata": {},
+    "user_metadata": {},
+    "picture": "",
+    "name": "",
+    "nickname": "",
+    "multifactor": [
+      ""
+    ],
+    "last_ip": "",
+    "last_login": "",
+    "logins_count": 0,
+    "blocked": false,
+    "given_name": "",
+    "family_name": ""
+  }
+]
+```
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/ja-jp/articles/users/search/v3/get-users-by-id-endpoint.md b/ja-jp/articles/users/search/v3/get-users-by-id-endpoint.md
new file mode 100644
index 0000000000..e5df676ad3
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/get-users-by-id-endpoint.md
@@ -0,0 +1,87 @@
+---
+title: Retrieve Users with the Get Users by ID Endpoint 
+description: Learn how to retrieve lists of users using the get-users-by-id endpoint.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users by ID Endpoint 
+
+The [`GET /api/v2/users/{id}` endpoint](/api/management/v2#!/Users/get_users_by_id) allows you to retrieve a specific user using their Auth0 user ID.
+
+This endpoint is **immediately consistent**, and as such, we recommend that you use this endpoint for:
+
+* User searches run during the authentication process. 
+* User searches run as part of the account linking process.
+
+::: note
+The user ID should be URL encoded since it may contain characters that do not work well in a URL.
+:::
+
+<%= include('./_valid-access-token') %>
+
+## Syntax
+
+*Required Scopes*: `read:users`
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users/USER_ID",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }]
+}
+```
+
+### Sample results
+
+```json
+{
+  "email": "john.doe@gmail.com",
+  "email_verified": false,
+  "username": "johndoe",
+  "phone_number": "+199999999999999",
+  "phone_verified": false,
+  "user_id": "usr_5457edea1b8f33391a000004",
+  "created_at": "",
+  "updated_at": "",
+  "identities": [
+    {
+      "connection": "Initial-Connection",
+      "user_id": "5457edea1b8f22891a000004",
+      "provider": "auth0",
+      "isSocial": false
+    }
+  ],
+  "app_metadata": {},
+  "user_metadata": {},
+  "picture": "",
+  "name": "",
+  "nickname": "",
+  "multifactor": [
+    ""
+  ],
+  "last_ip": "",
+  "last_login": "",
+  "logins_count": 0,
+  "blocked": false,
+  "given_name": "",
+  "family_name": ""
+}
+```
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/ja-jp/articles/users/search/v3/get-users-endpoint.md b/ja-jp/articles/users/search/v3/get-users-endpoint.md
new file mode 100644
index 0000000000..034a45a562
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/get-users-endpoint.md
@@ -0,0 +1,141 @@
+---
+title: Retrieve Users with the Get Users Endpoint
+description: Learn how to retrieve lists of users using the get_users endpoint.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Retrieve Users with the Get Users Endpoint 
+
+The [`GET /api/v2/users` endpoint](/api/management/v2#!/Users/get_users) allows you to retrieve a list of users. Using this endpoint, you can:
+
+* Search based on a variety of criteria
+* Select the fields to be returned
+* Sort the returned results
+
+This endpoint is **eventually consistent**, and as such, we recommend that you use this endpoint for back office processes such as changing the display name of an existing user.
+
+<%= include('./_valid-access-token') %>
+
+## Search for users
+
+To search for users, make a `GET` request to the [/api/v2/users endpoint](/api/management/v2#!/Users/get_users). Pass your search query to the `q` parameter and set the `search_engine` parameter to `v3`.
+
+### Example request
+
+For example, to search for a user whose email is exactly `jane@exampleco.com`, use `q=email:"jane@exampleco.com"`:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "email:\"jane@exampleco.com\""
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+For more information on other available parameters, check out the [Management API Explorer documentation](/api/management/v2#!/Users/get_users).
+
+### Sample queries
+
+Below are some examples to show the kinds of queries you can make with the Management API.
+
+Use case | Query
+---------|------
+Search for all users whose name contains "john" | `name:*john*`
+Search all users whose name is exactly "jane" | `name:"jane"`
+Search for all user names starting with "john" | `name:john*`
+Search for user names that start with "jane" and end with "smith" | `name:jane*smith`
+Search for all users whose email is exactly "john@exampleco.com" | `email:"john@exampleco.com"`
+Search for all users whose email is exactly "john@exampleco.com" or "jane@exampleco.com" using `OR` | `email:("john@exampleco.com" OR "jane@exampleco.com")`
+Search for users without verified email | `email_verified:false OR NOT _exists_:email_verified`
+Search for users who have the `user_metadata` field named `full_name` with the value of "John Smith" | `user_metadata.full_name:"John Smith"`
+Search for users from a specific connection | `identities.connection:"google-oauth2"`
+Search for all users that have never logged in | `(NOT _exists_:logins_count OR logins_count:0)`
+Search for all users who logged in before 2018 | `last_login:[* TO 2017-12-31]`
+Search for all users whose last login was in December 2017 | `last_login:{2017-11 TO 2017-12]`, `last_login:[2017-12-01 TO 2017-12-31]`
+Search for all users with logins count >= 100 and <= 200 | `logins_count:[100 TO 200]`
+Search for all users with logins count >= 100 | `logins_count:[100 TO *]`
+Search for all users with logins count > 100 and < 200 | `logins_count:{100 TO 200}`
+Search for all users whose email domain is "exampleco.com" | `email.domain:"exampleco.com"`
+
+### Sample results
+
+Successful calls to the endpoint return a JSON object similar to the following:
+
+```json
+[
+  {
+    "email": "john.doe@gmail.com",
+    "email_verified": false,
+    "username": "johndoe",
+    "phone_number": "+199999999999999",
+    "phone_verified": false,
+    "user_id": "usr_5457edea1b8f33391a000004",
+    "created_at": "",
+    "updated_at": "",
+    "identities": [
+      {
+        "connection": "Initial-Connection",
+        "user_id": "5457edea1b8f22891a000004",
+        "provider": "auth0",
+        "isSocial": false
+      }
+    ],
+    "app_metadata": {},
+    "user_metadata": {},
+    "picture": "",
+    "name": "",
+    "nickname": "",
+    "multifactor": [
+      ""
+    ],
+    "last_ip": "",
+    "last_login": "",
+    "logins_count": 0,
+    "blocked": false,
+    "given_name": "",
+    "family_name": ""
+  }
+]
+```
+
+## Limitations
+
+This endpoint allows you to retrieve a maximum of 1000 users (if the `page` parameter is set; if not set, we return a maximum of 50 users). If your results exceed this threshold, redefine your search. If you need a complete export of all of your users, instead use the [export job](/api/management/v2#!/Jobs/post_users_exports) or the [User Import / Export](/extensions/user-import-export) extension.
+
+If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+
+We do **not** recommend that you use this endpoint for:
+
+* Operations that require immediate consistency. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint) or the [Get Users by ID endpoint](/users/search/v3/get-users-by-id-endpoint).
+* User exports. Instead, use the [User Export endpoint](/users/guides/bulk-user-exports).
+* Operations that require user search as part of authentication processes. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint) or the [Get Users by ID endpoint](/users/search/v3/get-users-by-id-endpoint).
+* Searching for Users for [Account Linking](/users/concepts/overview-user-account-linking) by Email. Instead, use the [Get Users by Email endpoint](/users/search/v3/get-users-by-email-endpoint).
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/ja-jp/articles/users/search/v3/index.md b/ja-jp/articles/users/search/v3/index.md
new file mode 100644
index 0000000000..fe39072f3a
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/index.md
@@ -0,0 +1,56 @@
+---
+title: User Search
+description: Understand how the Auth0 Management API search endpoints allow you to search for and retrieve user profiles.
+topics:
+  - users
+  - user-management
+  - user-profile
+  - normalized-user-profile
+  - auth0-user-profiles
+  - search
+contentType:
+  - index
+  - concept
+useCase:
+  - manage-users
+---
+# User Search
+
+User search allows you to retrieve user profile details using Auth0's [Management API](/api/management/v2). Search results can be [viewed](/users/search/v3/view-search-results-by-page), [sorted](/users/search/v3/sort-search-results), and [exported](/users/guides/bulk-user-exports).
+
+::: note
+Most user profile fields are not returned as part of an [ID Token](/tokens/concepts/id-tokens), nor are they included in the response from the [/userinfo endpoint](/api/authentication#get-user-info) of the Authentication API. 
+:::
+
+When searching for users in Auth0, you can use multiple endpoints to search for ID, email, or other criteria:
+
+| Requirement | Endpoint to Use |
+| - | - |
+| Searches involving user attributes | [Get Users](/users/search/v3/get-users-endpoint) |
+| Searches returning multiple users | [Get Users](/users/search/v3/get-users-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Operations requiring [immediate consistency](#search-result-terminology) | [Get Users by ID](/users/search/v3/get-users-by-id-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Actions requiring user search as part of authentication processes | [Get Users by ID](/users/search/v3/get-users-by-id-endpoint) or [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+| Searching for users for account linking by email | [Get Users by Email](/users/search/v3/get-users-by-email-endpoint) |
+
+## Search Result Terminology
+
+We use the following terms to describe the user search results:
+
+* **Eventually consistent**: Search results may not reflect a recently-completed write operation. However, if you repeat your request after a short period of time, the response will return up-to-date data.
+
+* **Immediately consistent**: Search results will reflect the results of all successful write operations, including those that occurred shortly prior to your request.
+
+## Search Best Practices
+
+For info on best practices, see [User Search Best Practices](/best-practices/search-best-practices).
+
+## Keep reading
+
+* [Migrate from Search V2 to V3](/users/search/v3/migrate-search-v2-v3)
+* [User Search Query Syntax](/users/search/v3/query-syntax)
+* [Search Best Practices](/best-practices/search-best-practices)
+* [Normalized User Profiles Overview](/users/normalized)
+* [Identify Users](/users/normalized/auth0/identify-users)
+* [Normalized User Profile Schema](/users/normalized/auth0/normalized-user-profile-schema) 
+* [Sample User Profiles](/users/normalized/auth0/sample-user-profiles)
+
diff --git a/ja-jp/articles/users/search/v3/migrate-search-v2-v3.md b/ja-jp/articles/users/search/v3/migrate-search-v2-v3.md
new file mode 100644
index 0000000000..7496f010a4
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/migrate-search-v2-v3.md
@@ -0,0 +1,87 @@
+---
+title: Migrate from Search v2 to v3
+description: Learn how to migrate from Auth0 Search v2 to v3.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Migrate from Search v2 to v3
+
+User search v2 has reached its end of life as of **June 30, 2019**. We highly recommend migrating user search functionality to search engine v3 (`search_engine=v3`) as soon as possible.
+
+## Migration considerations
+
+Before you start migrating, there are a few things you should know:
+
+* To ensure that your queries are using search engine v3 prior to v2 becoming unavailable, you must update all your calls to the `GET /api/v2/users` endpoint to include the `search_engine=v3` parameter. This will enable you to see whether any queries need to be updated, so that you will not experience downtime when v2 becomes unavailable.
+* If you are performing user search operations through any of the [impacted SDKs](#impacted-sdks), you must also pass the `search_engine=v3` parameter as outlined above.
+* Search values for the normalized user fields (`email`, `name`, `given_name`, `family_name`, and `nickname`) are case insensitive. All other fields (including all `app_metadata`/`user_metadata` fields) are case sensitive.
+* v3 limits the number of users you can retrieve to 1000. If you are reaching this limit, we recommend that you redefine your search query to obtain more granular results. If you need a list of more than 1000 users at a given time, we recommend that you use the [export job](/api/management/v2#!/Jobs/post_users_exports) API endpoint or [User Import / Export extension](/extensions/user-import-export) instead.
+* Range and wildcard searches are not available on `app_metadata`/`user_metadata` fields. See [searchable fields](/users/search/v3/query-syntax#searchable-fields).
+* User fields are not tokenized like in v2, so `user_id:auth0` will not match a `user_id` with value `auth0|12345`, instead, use `user_id:auth0*`. See [wildcards](/users/search/v3/query-syntax#wildcards) and [exact matching](/users/search/v3/query-syntax#exact-match).
+* Wildcards can be used for prefix matching, for example `name:j*`. For other uses of wildcards (e.g. suffix matching), literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+* The `.raw` field extension is no longer supported and must be removed. In v3, fields match the whole value that is provided and are not tokenized as they were in v2 without the `.raw` suffix.
+* The `connection` field is not supported in v3. You should use its alias `identities.connection` instead. 
+
+## Queries to migrate
+
+Use case | v2 | v3
+---------|----|---
+Search by date | `updated_at:>=2018-01-15` | `updated_at:[2018-01-15 TO *]`
+Search by date | `updated_at:>2018-01-15` | `updated_at:{2018-01-15 TO *]`
+Search by date | `updated_at:<=2018-01-15` | `updated_at:[* TO 2018-01-15]`
+Search by date | `updated_at:<2018-01-15` | `updated_at:[* TO 2018-01-15}`
+Search by date | `last_login:<=2017-12` | `last_login:[* TO 2017-12]`
+String exact match | `name.raw:"john richard doe"` | `name:"john richard doe"`
+Phrase contains a word | `name:"richard"`, `name:richard` | `name:*richard*`
+Phrase contains a word (with less than 3 characters) | `name:*ri`,`name:*a`, `name:*ab*` | _(not supported)_
+
+## Impacted SDKs
+
+The following SDKs make use of the User Search engine. If you are using them, make sure you are using the versions listed below (or a later version), and pass the `search_engine=v3` parameter when performing user search operations.
+
+SDK | Version with support for v3 | Impacted methods | Considerations
+----|-----------------------------|------------------|---------------
+[Auth0 Java](https://github.com/auth0/auth0-java) | 1.8.0 | com.auth0.client.mgmt.UsersEntity.list | Provide a `UserFilter` with `withSearchEngine("v3")`
+[Auth0 Python](https://github.com/auth0/auth0-python) | 3.0.0 | management.Users.list | Provide the parameter `search_engine='v3'`
+[Auth0 Node](https://github.com/auth0/node-auth0) | 2.0.0 | UsersManager.getAll, ManagementClient.getUsers | Provide the parameter `search_engine:'v3'`
+[Auth0 .NET](https://github.com/auth0/auth0.net) | 3.0.0 or 4.0.0 | Auth0.ManagementApi.IUsersClient.GetAllAsync | Provide a `GetUsersRequest` object with `SearchEngine` = `"v3"`
+[Auth0 PHP](https://github.com/auth0/auth0-php) | 5.2.0 | Auth0.SDK.API.Management.Users.getAll | Provide the parameter `'search_engine' => 'v3'`
+[Auth0 Ruby](https://github.com/auth0/ruby-auth0) | 4.5.0 | Auth0.Api.V2.Users.users | Provide the parameter `search_engine: 'v3'`
+
+## Impacted Extensions
+
+The following Extensions make use of the User Search engine. If you have them installed, make sure you are using the versions listed below (or a later version).
+
+Extension | Version with support for v3 | Considerations
+----------|-----------------------------|---------------
+[Authorization Extension](/extensions/authorization-extension/v2) | 2.5.0 | If you are using an earlier version, you need to manually update the extension from the [Extensions](https://manage.auth0.com/#/extensions) page.
+[Delegated Administration](/extensions/delegated-admin/v3) | 3.1 | If you are using an earlier version, you need to manually update the extension from the [Extensions](https://manage.auth0.com/#/extensions) page. The `SEARCH_ENGINE` configuration setting no longer exists in 3.1, because only User Search v3 is available.
+
+## Leverage your tenant logs to find usage of User Search v2
+
+You can leverage the [logs](/logs) in the [Dashboard](${manage_url}/#/logs) to find calls to the `/api/v2/users` endpoint that use the User Search v2 engine, including calls performed by SDKs. Those logs will help you identify where code changes might be needed in your applications.
+
+Use the following query to retrieve all the logs related to User Search v2: `type:w AND description:*search_engine*`. The logs will provide additional information in the description field, in the following cases:
+
+- Queries that might produce different results in v3
+- Queries with syntax incompatible with v3
+- Queries that do not meet the paging requirements of v3
+
+If no additional details are specified in the log entries, it's likely that your queries are compatible with v3. Our recommendation, however, is still that you test the queries before deploying your changes to production.
+
+::: note
+Please note that only one log of the same type will be generated within 60 minutes. This means that even though you may be doing multiple calls to the User Search endpoint, you will only see one log of each type per hour.
+:::
+
+## Keep reading
+
+* [User Search Overview](/users/search)
+* [Authorization Extension](/extensions/authorization-extension/v2)
+* [Delegated Administration](/extensions/delegated-admin/v3)
+* [User Import/Export Extension](/extensions/user-import-export)
+* [Management API Explorer](/api/management/v2#!/Users/get_users)
diff --git a/ja-jp/articles/users/search/v3/query-syntax.md b/ja-jp/articles/users/search/v3/query-syntax.md
new file mode 100644
index 0000000000..ce0d124d4b
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/query-syntax.md
@@ -0,0 +1,166 @@
+---
+title: User Search Query Syntax
+description: Describes Auth0's user search query string syntax.
+toc: true
+topics:
+  - users
+  - user-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-users
+---
+
+# User Search Query Syntax
+
+When searching for users, you can create queries using [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) to refine your search.
+
+The query string is parsed into a series of terms and operators:
+
+* A term can be a single word such as `jane` or `smith`.
+* A term can be a phrase surrounded by double quotes (`"green apple"`), which will match all words in the phrase in the same order.
+* A term without a field name will not match text in the [user metadata](/users/concepts/overview-user-metadata) fields.
+* Multiple terms can be grouped together with parentheses to form sub-queries.
+* Search values for the normalized user fields (`email`, `name`, `given_name`, `family_name`, and `nickname`) are case insensitive. All other fields (including all `app_metadata`/`user_metadata` fields) are case sensitive.
+* Operators (`AND`, `OR`, `NOT`) work on all normalized user fields and root metadata fields.
+
+## Searchable fields
+
+You can search for users using all the [normalized user profile fields](/users/normalized/auth0/normalized-user-profile-schema) and the fields below:
+
+Search Field | Data Type | Description
+------|------|-----
+`phone_number` | text | The user's phone number. Only valid for users with SMS connections.
+`phone_verified` | boolean | The `true/false` value indicating whether the user's phone number has been verified. Only valid for users with SMS connections.
+`logins_count` | integer | The number of times the user has logged in. If a user is blocked and logs in, the blocked session is counted in `logins_count` and updates the `last_login` value.
+`created_at` | date time | The timestamp of when the user profile was first created.
+`updated_at` | date time | The timestamp of when the user's profile was last updated/modified.
+`last_login` | date time | The timestamp of when the user last logged in. In case you are this property from inside a [Rule](/rules) using the `user` object, its value will be the one associated with the login that triggered the rule (since rules execute after the actual login).
+`last_ip` | text (valid IP address) | The IP address associated with the user's last login.
+`blocked` | boolean | The `true` or `false` value indicating if the user has been blocked. Note: `true` *only* brings back users who are blocked via the Admin Dashboard and Management API; it does not bring back users blocked by brute force anomaly detection.
+`email.domain` | text | The domain part of the user's email.
+
+[Metadata](/users/concepts/overview-user-metadata) fields may be used with:
+    
+* Boolean
+* Numeric: (integer or double)
+* Text
+* Objects: In order to search a scalar value nested in another object, use the path to the field. For example, `app_metadata.subscription.plan:"gold"`
+* Arrays: In order to search fields in objects nested arrays, use the path to the field and ignore the array level. For example, `user_metadata.addresses.city:"Paris"`
+
+Range and wildcard searches are not available on user metadata fields.
+
+## Exact match
+
+To find exact matches, use double quotes: `name:"jane smith"`.
+
+For example, to find users with the name `jane smith`, use `q=name:"jane smith"`:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "name:\"jane smith\""
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Wildcards
+
+Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters. 
+
+Here are some examples: 
+
+* `name:john*` returns all users with `john` at the beginning of their names. 
+
+* `name:j*` returns all users with `j` at the beginning of their names.
+
+* `q=name:john*` returns all users whose names start with `john`.
+
+* For suffix matching, literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+
+### Sample query with wildcards
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "name:john*"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Ranges
+
+You can use ranges in your user search queries. 
+
+* For inclusive ranges use square brackets: `[min TO max]`.
+
+* For exclusive ranges use curly brackets: `{min TO max}`.
+
+* Curly and square brackets can be combined in the same range expression: `logins_count:[100 TO 200}`. 
+
+* Use ranges in combination with wildcards. For example, to find all users with more than 100 logins, use `q=logins_count:{100 TO *]`.
+
+### Sample query with ranges
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:{100 TO *]"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Limitation
+
+Range and wildcard searches are not available on user metadata fields.
+
+## Keep reading
+
+* [Sort Search Results](/users/search/v3/sort-search-results)
+* [View Search Results by Page](/users/search/v3/view-search-results-by-page)
+* [Bulk User Exports](/users/guides/bulk-user-exports)
+* [Search Best Practices](/best-practices/search-best-practices)
diff --git a/ja-jp/articles/users/search/v3/sort-search-results.md b/ja-jp/articles/users/search/v3/sort-search-results.md
new file mode 100644
index 0000000000..b62fd85aeb
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/sort-search-results.md
@@ -0,0 +1,52 @@
+---
+title: Sort Search Results
+description: Learn how to sort search results by passing a field:order value to the sort parameter.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# Sort Search Results
+
+To sort user search results, pass a `field:order` value to the `sort` parameter when making your request. The `field` is the name of the field to sort by, while order can be set to `1` for ascending order and `-1` for descending. 
+
+::: note
+Sorting by `app_metadata` or `user_metadata` is not supported.
+:::
+
+## Sample request
+
+For example, to sort users in ascending order by the `created_at` field you can pass the value `created_at:1` to the `sort` parameter:
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:[100 TO 200]"
+        },
+        {
+          "name": "sort",
+          "value": "created_at:1"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Keep reading
+
+For more information on `sort` and other parameters, see the [Management API Explorer](/api/management/v2#!/Users/get_users) documentation.
diff --git a/ja-jp/articles/users/search/v3/view-search-results-by-page.md b/ja-jp/articles/users/search/v3/view-search-results-by-page.md
new file mode 100644
index 0000000000..a097227034
--- /dev/null
+++ b/ja-jp/articles/users/search/v3/view-search-results-by-page.md
@@ -0,0 +1,89 @@
+---
+title: View Search Results by Page
+description: Learn how to view search results page by page and include totals.
+topics:
+  - users
+  - user-management
+  - search
+contentType: how-to 
+useCase:
+  - manage-users
+---
+# View Search Results by Page
+
+To page the user search results, use the `page`, `per_page`, and `include_totals` parameters at your request.
+
+Parameter | Description
+----------|------------
+`page` | The page number, zero based. When this is not set, we return a maximum of 50 records, regardless of how many records exist.
+`per_page` | The amount of users per page.
+`include_totals` | Set to `true` to include a query summary as part of the result.
+
+## Sample request
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/users",
+    "httpVersion": "HTTP/1.1",
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN"
+    }],
+    "queryString":  [
+        {
+          "name": "q",
+          "value": "logins_count:[100 TO 200]"
+        },
+        {
+          "name": "page",
+          "value": "2"
+        },
+        {
+          "name": "per_page",
+          "value": "10"
+        },
+        {
+          "name": "include_totals",
+          "value": "true"
+        },
+        {
+          "name": "search_engine",
+          "value": "v3"
+        }
+    ]
+}
+```
+
+## Sample response
+
+A sample response body for the values set in the above sample request is as follows:
+
+```json
+{
+    "start": 20,
+    "limit": 10,
+    "length": 10,
+    "users": [
+        {
+            ...
+        }
+    ],
+    "total": 79
+}
+```
+
+Parameter | Description
+----------|------------
+`start`   | Record position from which the page starts.
+`limit`   | Maximum number of records that can be shown on the page.
+`length`  | Number of records shown on the page.
+`total`   | Total number of records found.
+
+## Limitation
+
+Auth0 limits the total number of users you can retrieve to 1000 (for example, 100 users per page for 10 pages). When the `page` parameter is not set, we return a maximum of 50 records, regardless of how many records exist.
+
+## Keep reading
+
+For more information on the `page`, `per_page` and other parameters, see the [Management API Explorer](/api/management/v2#!/Users/get_users) documentation.
diff --git a/ja-jp/articles/videos/get-started/01-architecture-your-tenant.md b/ja-jp/articles/videos/get-started/01-architecture-your-tenant.md
new file mode 100644
index 0000000000..a7b9bbcbab
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/01-architecture-your-tenant.md
@@ -0,0 +1,161 @@
+---
+description: What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
+classes: video-page
+public: false 
+---
+
+# Architect: Your Tenant
+
+Learn what an Auth0 tenant is and how to configure it in the Auth0 Dashboard. Understand why you may want more than one tenant if you have different user communities, and also how you can use more than one tenant to support your Software Development Life Cycle (SDLC). Understand the importance of tenant naming and custom domain usage best practices. Also learn how to set up additional tenant administrators and how to associate tenants with your Auth0 account.
+
+
    
+
+## Transcript
+  
+
    
+  Introduction
+  
+  In this video, we will talk about what an Auth0 tenant is, and show you how to configure it in the Auth0 Dashboard. We will also briefly explain why you may want to use more than one tenant if you have different user communities, and also how you can use more than one tenant in support of your Software Development Life Cycle. We’ll also describe the importance of tenant naming, use of custom domains, provisioning additional tenant admins, and how to associate tenants with your Auth0 account. 
+
+  Once you create your account in Auth0, you will be asked to create a Tenant. This is a logical isolation unit. The term tenant is borrowed from the phrase "software multi-tenancy" and refers to an architecture where a single instance of the software serves multiple tenants. No tenant can access the instance of another tenant, even though the software might be running on the same machine (hence the logical isolation).
+
+  When it comes to figuring out how to define your Auth0 tenants and accounts as part of your application integration, the value of investing time in the architectural “landscape” up front will pay dividends in the long run, and there are a number of things you’ll want to consider. 
+
+  It’s important to understand how your applications need to function within your infrastructure, and this will help you understand how to configure your tenants to accomplish your goals. How your Auth0 tenants are configured—the architecture of your Auth0 deployment—will form the basis for the grouping of your Auth0 assets to leverage features such as Single Sign On, centralized user profile management, and consolidated billing capabilities. 
+
+  The number of tenants you create can grow quickly, especially if you have different user communities and different phases for development, testing, and production. So, for ease of maintenance and simple organization, it is really important to consider exactly what you will need. 
+
+  For example, it’s not uncommon for companies to have identity requirements that address multiple user communities such as customers, partners, and employees. There may also be other groups within your organization that are working with Auth0; it’s not uncommon for our customers to have disparate departments that serve different user communities. Identifying these early will potentially influence your choices, and doing so could mitigate decisions that might prove costly later on.
+
+  So you will need to decide how many different production tenants you will require. Most companies only need a single production tenant, but if you have a set of applications for just employees, you may want a separate tenant for that. In some situations, you may also need different production tenants for different customer user communities. 
+
+  Another reason you would want to create multiple tenants is to support your Software Development Life Cycle. Auth0 can fit into your process by allowing you to have a separate tenant for each phase—such as one for development, one for testing, and one for production. Even if you don’t use an SDLC methodology, you will most likely want to create at least two tenants: one for development and one for production. 
+
+  You may want to name one tenant “company-dev” to serve as a shared environment where your development work occurs, and name another tenant “company-qa” for testing your Auth0 integration. You can then name a third tenant “company-prod” to serve as your production tenant. 
+
+  You can also create tenants to serve as sandboxes to test potential changes, like different deployment scripts, without compromising your environment. Auth0 lets you create as many free tenants as you like, but you may be limited for the number of tenants where all paid features are enabled. You can have up to three tenants where all features are available.
+
+  It’s also important to consider exactly what you will name your tenants. The ultimate goal is to end up with one or more production tenants that are branded exactly the way you want them to appear to your users. Tenant naming patterns are very important, so it’s good to plan the tenant names in advance because you won’t be able to change them once you create them, or use them again if you delete them.
+
    
+
+
    
+  Configure your tenant
+
+  Now let’s see how easy it is to configure your tenants. Everything you need to configure your Auth0 tenant is available via the Auth0 Dashboard. Here you’ll determine how you’ll use Auth0 features and where assets like applications, connections, and user profiles will be stored. 
+
+  We’ll talk about these in other videos, but for now, we’re going to concentrate on Tenant Settings, accessible via the drop-down menu by going to the upper-right corner of the Dashboard and clicking on your tenant name. From this menu, you can also create additional tenants at any time by clicking on Create Tenant.
+
    
+
+
    
+  General settings
+
+   Starting with the General settings tab, you can specify your company name, a path to your company logo, and your company’s support email address and support URL. This is the information that is shown in the default error page that appears to your users, so they can contact your support if they have an issue. You may also want to consider creating a custom error page and configure Auth0 to use that instead. 
+
+  Out-of-the-box, client-facing URLs are Auth0 branded; however, we recommend using the Auth0 custom domain capability to provide a consistent corporate identity and to also address potential user confidence concerns before they arise. Your company name as part of the URL, for example, will support your brand and should tell your users that they can trust that they are in the right place to enter their identity information. It’s also harder to phish your domain if you have a Custom Domain (a.k.a. vanity) URL because the phisher also has to create one to mimic yours. A centralized domain for authentication across multiple product or service brands so users see a consistent interface is also important. And keep in mind that some browsers make it harder to communicate in an iFrame if you don’t have a shared domain.
+
+  Having more than one Auth0 Dashboard administrator is a good idea, and periodically reviewing the list of Auth0 Dashboard administrators to see that the right people have access to your Auth0 tenants will help you make sure that each person has a legitimate need for admin access. You should make sure that former employees no longer have access. We also recommend that you enable multi-factor authentication for all your admins for added security. Having more than one admin can alleviate the burden of Auth0 tenant administration, but if you only have one admin they may get locked out if they lose their phone. If you have more than one admin, however, another can temporarily disable MFA for the admin who lost their phone.
+
    
+
+
    
+  Advanced settings
+ 
+  There are also some advanced tenant settings that you can configure for your tenant. There are a couple of things you need to consider when you configure these items. 
+
+  Logout is the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. This is usually achieved via the provision of some “logout” option on the UI. There are multiple types of sessions that could be created when a user logs in. For example, a local application session, Auth0 session, and/or a third-party Identity Provider session. You’ll need to determine which should be terminated when the user clicks on any “logout” option. You can configure the application to have a logout redirect URL.
+
+  Session timeout settings allow you to specify when the SSO cookie times out. The value you set is the login session lifetime which is how long the session will stay valid, measured in minutes. The default setting is set for 10,080 minutes or 7 days. 
+
+  Your contractual agreement with Auth0 should cover all the tenants you want to use. Make sure all your tenants are associated with your company account. If you have developers who want to create their own sandboxes for testing, make sure the tenants are associated with your account so they have the same permissions and Auth0 features available too. 
+
+  If you need to add a tenant to your account, contact the Auth0 Support Center at  Specify your production tenant so you can get higher rate limits than non-production tenants. Only one tenant per subscription can be set as the production tenant. 
+
    
+
+
    
+  Summary
+  
+  So, to summarize, we described what an Auth0 tenant is, how to configure it, and why you may need more than one tenant. We also described the importance of tenant naming, and how to associate tenants with your Auth0 accounts to save money and leverage Auth0 features across your organization.
+
+  In the next video, we’ll talk about provisioning your users and configuring user stores, and in a future video, we’ll talk more about Custom Domains too.
+
    
+
+## Up next
+
+
      
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them.  
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0.  
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
diff --git a/ja-jp/articles/videos/get-started/02-provision-user-stores.md b/ja-jp/articles/videos/get-started/02-provision-user-stores.md
new file mode 100644
index 0000000000..71769b3b55
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/02-provision-user-stores.md
@@ -0,0 +1,192 @@
+---
+description: How user profiles are provisioned within an Auth0 tenant.
+classes: video-page
+public: false
+---
+
+# Provision: User Stores
+
+Learn how user profiles are provisioned within an Auth0 tenant. Users can come from a multitude of places: directly through creating an account using self sign-up, indirectly through using their favorite trusted social media platform, or collectively through a trusted enterprise directory. Auth0 makes it simple to quickly connect your tenant to multiple types of user stores. We group these users stores into three categories: database, social, and enterprise.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, we will show you how user profiles are provisioned within an Auth0 tenant. Users can come from a multitude of places: directly through creating an account using self sign up, indirectly through using their favorite trusted social media platform, or collectively through a trusted enterprise directory.
+
+  Auth0 makes it simple to quickly connect your tenant to multiple types of user stores. We group these users stores into three categories: database, social, and enterprise.
+
+  * Database connections solve many traditional username and password based scenarios. By default, Auth0 offers identity storage out of the box that can be leveraged to manage the burden of storing user credentials safely and securely. Auth0 is also capable of providing proxies to existing legacy identity stores.
+
+  * Social connections give users a simplified registration and login experience by using an existing authentication from a social network provider like Facebook, Twitter, or Google. Not only are popular social networks supported but close to 40 business, professional and industry-based connections are available. In fact, any OAuth2-conformant identity provider can be configured as a user store.
+
+  * Finally, Enterprise connections allow business customers or partners to manage their own users within an Auth0 tenant. This is a very powerful feature that allows any set of businesses to collaborate in a secure way. 
+
    
+
+
    
+  User store connections in the Dashboard
+
+  Auth0 can be configured for any number and combination of connections to provide user identity for applications. Auth0 sits between the applications and their sources of users, which adds a level of abstraction so the application is isolated from any changes to and idiosyncrasies of each source's implementation.
+
+  Now let’s dive a little deeper and discover how to establish each type of user store connection directly in the Auth0 Dashboard. This can be accomplished independently of any modifications or implementation within an application.
+
+  First, let’s take a look at how to jump right in and authenticate users via username and password using infrastructure provided by Auth0. Out-of-the-box, each Auth0 tenant is preconfigured with an authentication database connection. This connection provides the best performance for the authentication process since all data is stored in Auth0.
+
+  The Auth0-hosted database is highly secure. Passwords are never stored or logged in plain text but are hashed with bcrypt. Varying levels of password security requirements can also be enforced.
+
+  The default database can be found on the Auth0 Dashboard for your tenant. From the Dashboard, click the **Connections** link in the left-hand navigation menu which will expand a list of the available connection types. Click **Database** and a list of all database connections will be displayed.
+
+  As you can see, a database connection named **Username-Password-Authentication** is already available. By clicking the name of the connection we are taken to the configuration section for this database.
+
+  The database configuration is split into a series of tabs: **Settings**, **Password Policy**, **Custom Database**, **Applications**, and **Try Connection**.
+
+  By default, database connections authenticate users using their email and password. If you require the use of usernames, it can be enabled on the settings tab as well as setting minimum and maximum lengths for the username.
+
+  There is also the ability to disable new user sign ups. This prevents new accounts from being created in the database by user-facing dialogs. Users can still be created using the Management API or directly in the Dashboard. 
+
+  There is also a way to completely delete this database. Be careful though, as is mentioned, this is a destructive operation that is not reversible.
+
    
+
+
    
+  Passwords
+
+  Finally, we see an option to import users to Auth0. I will cover how this is used in a future video on migrations.
+
+  On the password policy tab are several settings that allow you to align this database with your company password policy. Even if you do not have a password policy currently, it is worth considering each of the options available on this tab.
+
+  By default, Auth0 has configured the password strength to a quality of Good which at a minimum requires a length of 8 characters containing both upper and lower case letters, numbers and special characters. For convenience, a tester is available that allows you to test the user experience of these settings.
+
+  The password history policy, when enabled, will prevent users from reusing passwords they have previously used. Up to 24 previous passwords can be saved in the history.
+
+  Enabling the password dictionary prevents the use of 10,000 of the most common passwords. There is even an option to add custom values to this list that might not be obvious like company names or a list of conference rooms in your building.
+
+  The personal data option ensures that no data contained in the user's profile is used in the password as well.
+
    
+
+
    
+  Custom Database
+
+  The **Custom Database** tab allows you to configure this database connection to connect to an external database that is not managed by Auth0. This is useful for organizations who have data retention policies that do not allow external storage of data. For information on configuring a custom database connection, see the documentation linked below.
+
+  I will talk more about custom database connections in a future video.
+
    
+
+
    
+  Applications
+
+  The **Applications** tab show us a list of applications that are currently using this database connection. Enabling or disabling an apps ability to use this connection is as simple a flipping a switch.
+
    
+
+
    
+  Try connection
+
+  Finally, the **Try Connection** tab will allow us to try out the database connection in a special test application configured just for this connection.
+
+  Using this test application, we can verify all of our settings work as expected. Successfully authenticating will take us to a success page showing the user profile data that will be provided to applications using this database connection.
+
+  Of course, from the database list, we can easily create a new database connection. You are free to create as many database connections as you need to support all of your applications and users.
+
    
+
+
    
+  Summary
+
+  In a future video, I will show you two powerful ways to add your existing users using either bulk imports or a more gradual migration using custom database connections.
+
+  Next, let’s look at how to connect applications to social login providers. Auth0 offers simple integrations with dozens of popular social login providers. Additionally, you can add any OAuth2 Authorization Server you need.
+
+  Social logins bring single sign-on semantics to end users. Using existing login information from a social network provider like Facebook, Twitter, or Google, the user can sign into an application instead of creating a new account specifically for that application. This simplifies registrations and logins for end users.
+
+  Social login connections can be found on the Auth0 Dashboard. From the Dashboard, click the **Connections** link in the left-hand navigation menu which will expand a list of the available connection types. Click **Social** and a list of all available social connections will be displayed.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous video
+
+
      
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+   
      • 
+
+
    
+
diff --git a/ja-jp/articles/videos/get-started/03-provision-import-users.md b/ja-jp/articles/videos/get-started/03-provision-import-users.md
new file mode 100644
index 0000000000..f81cf4b4a5
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/03-provision-import-users.md
@@ -0,0 +1,200 @@
+---
+description: How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
+classes: video-page
+public: false
+---
+
+# Provision: Import Users
+
+Learn how Auth0 allows you to move your existing users to an Auth0 user store and why you may want to use a combination of both automatic and bulk migration methods. Learn why it's a good idea to have an API between the cloud and your legacy database and how custom database scripts work.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  Customers building new systems can easily take advantage of various types of user stores Auth0 supports to authenticate users. Now we will take a look at how Auth0 helps you import your existing users two ways: Automatic Migration and Bulk Migration. In this video we will show you the advantages to using both methods together and how to get the results you want.
+
+  We’ve found that most customers don’t want to force their users to reset their passwords just because they chose to implement Auth0, so we’ve provided tools to help you move your users to a custom database as they authenticate over time or, depending on the algorithm you have used to hash the user’s passwords, you can bulk import the password hashes with the users. 
+
+  Automatic migrations give your users a seamless migration experience that doesn’t require them to reset their passwords. You also benefit from only migrating active users, helping you to clean up your user data in the process. 
+
+  Bulk migrations have the advantage of getting the migration done at the beginning in one effort and allow you to turn off your legacy system and remove legacy code sooner. If you are using a particular hashing algorithm and technique, you can even bulk migrate the passwords and not require a password reset.
+
    
+
+
    
+  Auth0 Database Connections in the Dashboard
+
+  Both Automatic and Bulk migration are supported using Auth0 Database Connections. After you create a database connection in the Dashboard, you enable user migration from that legacy database and create custom scripts to determine how the migration happens.
+
+  First, you need to set up a custom database connection. Create a new database connection in the **Connections > Database** section of the Dashboard.
+
+  Connect the database to the application. Navigate to the **Applications** tab of your database settings, under the **Applications Using This Connection** heading you can enable the database connection for each application.
+
+  On the **Custom Database** page, enable the **Use my own database** option.
+
+  On the **Settings** page for your database, enable the **Import Users to Auth0** option.
+
    
+
+
    
+  Create API Front End to Your Database 
+
+  Next, if you don’t have an API already, we recommend that you create a simple API in front of your legacy database instead of allowing access directly from Auth0.
+
+  Unless you have a private instance or enterprise cloud deployment, you probably don’t want to expose your entire database interface to the Auth0 IPs because those are shared IP addresses. Though you can whitelist Auth0 IPs, those IPs are shared in the cloud environment. 
+
+  In compliance with the principle of least privilege, Auth0 recommends that you protect your database from too many actors directly talking directly to it. The easiest way to do that is to create a simple API endpoint that each script within Auth0 can call. Protect the API using an access token.  This access token can be created using the client-credentials grant. This grant type is for us in machine-to-machine contexts, like this one, where you don’t have the context of a particular user. 
+
    
+
+
    
+  Custom Database Script Templates
+
+  Next, we’ll show you how to use Auth0’s custom database script templates to perform certain actions on the user data stored in the database. 
+
+  The script templates are pre-populated in the Dashboard script editor. The scripts cover Get User and Login.
+
+  Here are some best practices that we’ve found work for most customers:
+
+  * Set a `user_id` on the returned user profile that is consistent for the same user every time. This is important because if you set a random `user_id` in the `get_user` script, then call forgot password and change the password, the user will get duplicated every time they log in. In the non-migration scenario, if you set a random `user_id` you can end up with duplicate users for every login.
+
+  * If using a username, ensure that you aren't returning the same email address for two different users in the `get_user` or `login` script. Auth0 will produce an error if you do this, but it is better to catch it in the script itself.
+
+  * If setting `app_metadata`, call it `metadata` in the script. To support backwards compatibility, `app_metadata` is called `metadata` in `custom DB` scripts. If you don't use `metadata` in the script, you will get an error where `app_metadata` will work but if you use the API to merge `app_metadata` with a user, it will appear as if all of your metadata was lost. NOTE: `user_metadata` is not affected by this and can simply be called `user_metadata`.
+
+  * Ensure you restrict access to that audience with a rule. As with any API that you create, if you create it solely for client credentials, then you will want to restrict access to the API in a rule. By default, Auth0 gives you a token for any API if you authenticate successfully and include the audience. Someone could intercept the redirect to authorize and add the audience to your legacy database API. If you don’t block this in a rule, they could get an access token.  You will also want to update the API to expect the subject claim of the token to end in `@clients`.
+
+  * Make sure the `login` script and the `get_user` script both return the same user profile. Because of the two different flows (logging in, or using forgot password), if the `get_user` and `login` scripts return different user profiles, then depending on how a user migrates (either by logging in directly, or using the forgot password flow) they will end up with different profile information in Auth0.
+
+  * If setting `app_metadata` or `user_metadata`, use a rule to fetch the metadata if it is missing. The metadata is not migrated until `https://YOUR_TENANT.auth0.com/login/callback` is called. However, the user credentials are migrated during the post to `https://YOUR_TENANT.auth0.com/usernamepassword/login`. 
+
+    This means that if the flow is interrupted after the username password/login, but before login/callback, then they will have a user in the Auth0 database, but their app and user metadata are lost. It is really important, therefore, to create a rule that looks a lot like your `get_user` script to fetch the profile if app and user metadata are blank. This should only execute once per user at most and usually never.
+
+  * Use a rule to mark users as migrated. This is not a hard requirement, but it does protect against one scenario in which a user changes their email address, then changes it back to the original email address. A rule should call out to the legacy database to mark the user as being migrated in the original database so that `get_user` can return false.
+
    
+
+
    
+  Bulk Importing Users
+
+  Next, let’s look at bulk importing users directly into the Auth0 database. It’s important to note that when you use Bulk Migration, you *can* migrate the user’s password if it was hashed using bcrypt with 10 salt rounds, otherwise you will have to force your users to reset their passwords.
+
+  Before you launch the import users job, a database to which the users will be imported must already exist and it must be enabled for at least one application in your tenant. 
+
+  You can then import a file containing your user data with our Management API. The file must have an array with the users' information in JSON format. You can use the `POST /api/v2/jobs/users/post_users_importsendpoint` to populate a database connection with the user information in the file. 
+
+  The users import endpoint requires that your POST request use the `multipart/form-data` encoding type. See our documentation for a list of the parameters that must be part of the request. 
+
+  There are some rate and file size limitations for bulk imports: 
+
+  * Calls to the Management API are subject to rate limiting. The rate limits for this API differ depending on whether your tenant is free or paid, production or not. 
+    * For all free and non-production tenants, you can have up to 2 requests per second and bursts up to 10 requests.
+    * For paid tenants, you can have up to 15 requests per second and bursts up to 50 requests. 
+    * The rate limits include calls made via Auth0 Rules. Note, that the limit is set by tenant and not by endpoint. For additional information about these endpoints, please consult the Management API explorer.
+  * There is also an import JSON file size limitation of 500 kilobytes.  If your user database would result in a file larger than this, you will need to break the users up into chunks that keep each file smaller than 500 KB.
+
+  Auth0 does provide an User Import/Export Extension however, we recommend that you use the Management API Bulk Migration for all but the most simple cases.
+
+  After you’ve migrated your users to the Auth0 database, you can use the **List** or **Search** Management API endpoint to make sure the users are there. You can also view the users list in the Dashboard.
+
+  We’ve found that customers often opt for a two-phased approach to user migration, employing Automatic Migration first in order to migrate as many active users as possible, and then turning off Automatic Migration and performing Bulk Migration for the users that remain.
+
    
+
+
    
+  Summary
+  
+  After you have verified the migration of the final set of users, you can set the `login` and `get_user` scripts to simply `“return callback()”` in the Dashboard. Keep **Import Users to Auth0** enabled on the Settings page so that your users will be directed to the new database workflow.
+
+  This gives your active users a nice experience by not forcing them to reset their passwords, even if your hashing algorithm is not compatible with bulk import, while still allowing you to decommission the legacy identity store.
+
+  In the next video, we will take a look at user authentication.
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/04_01-authenticate-how-it-works.md b/ja-jp/articles/videos/get-started/04_01-authenticate-how-it-works.md
new file mode 100644
index 0000000000..8aa2ee856c
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/04_01-authenticate-how-it-works.md
@@ -0,0 +1,161 @@
+---
+description: How user authentication works and various ways to accomplish it with Auth0.
+classes: video-page
+public: false
+---
+
+# Authenticate: How It Works
+
+Learn about the difference between authentication, authorization, and access control. Understand when and why you might use each type of authentication method: first factors, second factors, and multi-factor. Learn about the OpenID Connect (OIDC) authentication protocol.   
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  Before you can provide services to your users through your applications, you need to identify who they are, and that process is called *user authentication*. 
+
+  In this video, we will show you a few ways to go about this. For example, you can authenticate users via their social media accounts or with their usernames and passwords. You can add an additional level of certainty about their identities with a second authentication factor; this is called *Multi-factor Authentication* (MFA).
+
+  Before you start, think about security and user experience, if you want to offer multiple primary authentication methods, and if you want to add multi-factor authentication. Planning how you want the authentication process to work before you do the steps required to implement the actual authentication is critical because it will determine how you configure your application integration.
+
+  One way to make sure you’ve considered all your authentication requirements is to adopt an iterative release style. For example, you may have three or four applications you need to integrate and, instead of tackling them all at once, you can make a series of iterations, tackling one application at a time. This way your teams can benefit from the experience, and you can leverage this approach to help increase velocity with each iteration.
+
    
+
+
    
+  Authentication, authorization, and access control
+
+  It’s important to distinguish between Authentication, Authorization, and Access Control. Your Auth0 tenant, the Authorization Server, is responsible for Authentication and some or all of Authorization. Access Control is the responsibility of the API or Application itself because access control is almost always contextual.
+
+  So, to summarize:  
+  * **Authentication** is the process of determining if the user is who they say they are
+  * **Authorization** is declaring what that user is allowed to do in the system
+  * **Access Control** is limiting a user to only perform actions they are allowed to do based on a combination of their identity, their authorization information, and their consent.
+
+  In this video, we are only going to focus on authentication, we will address the other options such as MFA in a separate video. There are different types of connections you can make in the Dashboard that will enable authentication. 
+
    
+
+
    
+  Social connections
+
+  You can choose from among many social connections including the most commonly used ones like Google and Facebook. Choose connections that your users will most frequently have accounts with. 
+
+  If you have more than one application, you will almost certainly want to have Single Sign-On between those applications. This is one of the easiest ways to give your users a good user experience without compromising on security.
+
+  As you may already know, the OpenID Connect specification—or OIDC—is the most widely used industry-standard authentication specification when it comes to customer-facing applications. It is intended as a way to provide SSO between applications. OIDC is based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens—or JWT—that you obtain using flows conforming to the OAuth 2.0 specifications. When a user signs in using their Google account, then they’ve used OIDC.
+
+  We’ve made it easy to enable this type of authentication with Universal Login. The way this works is you delegate the authentication of a user by redirecting them to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application.
+
+  If each of your applications does this then Auth0 remembers whether the user has already logged in and sends them back to the new application without requiring them to re-enter their credentials. This is how we accomplish Single Sign On.
+
+  The next step is to figure out how to do this in your application. To help you out we’ve provided some guides to help you get started.
+
    
+
+
    
+  Auth0 Quickstarts
+
+  Before figuring out which quickstart to use, it is important to figure out which one most closely represents your application. You answer two questions to make this determination:
+
+  1. What type of application do you have? Do you have a traditional web application, a single page application, or a native mobile application?
+
+    * A traditional web application is generally an application written in PHP, Java, or C#.  It is an application where the browser opens a page, the page is rendered on the server side and then the HTML is sent to the browser.  When someone performs an action it refreshes the page. There is a frontend, the code on the browser, which may include some javascript, and a backend, the code that executes on the server side.  The backend can maintain the state of the application on the server.  Most applications fall into this category.
+
+    * A single page application is an application that renders once on the server and then the rest of the execution happens on the users’ browser.  The application must call API’s to perform actions that happen server side, but those APIs don’t maintain any state for the session.  You must give the API the information it needs.  Note that there is non-session state that can be stored in a database, but the API doesn’t know which instance of the application is calling it, so there is not sessions associated with your browser instance.
+
+    * A native and/or mobile application is an application that is installed on a mobile device or desktop OS.  It must call an API to perform actions on the server side as well.
+
+  2. Are you going to need an access token to call a separate API? If your application needs to call a separate API, then you will need to do some extra work after the quickstart to enable your SDK to get you an access token. You can learn more about that in the video that discusses Authorization.
+
+  In the next video, we are going to show you how to use a quickstart guide to integrate a javascript single-page app and a backend. 
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+
    
\ No newline at end of file
diff --git a/ja-jp/articles/videos/get-started/04_02-authenticate-spa-example.md b/ja-jp/articles/videos/get-started/04_02-authenticate-spa-example.md
new file mode 100644
index 0000000000..8e588388c4
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/04_02-authenticate-spa-example.md
@@ -0,0 +1,160 @@
+---
+description: An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login.
+classes: video-page
+public: false
+---
+
+# Authenticate: SPA Example
+
+See an example using the Auth0 Quickstart for a single-page application (SPA) implementation and learn how Auth0's Universal Login feature does most of the authentication work for you. Understand how security and user experience work with the authentication process to determine how to plan your application integration to Auth0. See how Single-Sign On (SSO) works between applications when you use Universal Login. 
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In part 1, we described a few of the ways that you can provide services to your users through your applications using user authentication. You can authenticate users via their social media accounts or with their usernames and passwords. You can add an additional level of certainty about their identities with Multi-factor Authentication (MFA).
+
+  In this video, we will look at how the Quickstart single page application or SPA implementation uses Universal Login—which is the preferred method for authentication workflow in Auth0. 
+
    
+
+
    
+  Quickstart: SPA with Backend
+
+  You can find the quickstarts at https://auth0.com/docs/quickstarts. It is a good idea to login to a specific tenant. Here I am using the **product-training** tenant. This will make the user experience better later on.
+
+  Next, we need to select the type of application we want to use. We can start with single page application. Then select the vanilla javascript quickstart.
+
+  Here we are offered two options; the first is a detailed step-by-step guide to implementing authentication in an existing javascript application, and the second is to download a fully functional sample application.
+
+  Let’s download the sample application. Because we are authenticated, the quickstart download gives us an option to select an existing application from our tenant. The downloaded sample application will be configured to use this applications credentials for authentication.
+
+  We are also instructed to add our localhost development url to the **Callback URL** and **Allowed Web Origins** lists.
+
+  Finally, assuming that `node.js` is installed we can install our dependences and start the application.
+
+  Now we can test the authentication by clicking the **Login** button.
+
    
+
+
    
+  Universal Login
+
+  Now that we have an application connected, let’s take a look at Universal Login. You can choose from Classic or New to create your own login pages that will authenticate your users. Later in another video, we will show you how to provide more extensive branding for these pages and more. 
+
+  The buttons that appear on the login page depend on a number of factors including the connections that have been enabled and the current state of a session the user may already have. These settings are dynamic and adjustable in real-time—no coding changes are required—since the functionality is driven by the web pages served by the Auth0 Authentication Server.
+ 
+  If you have **Enable seamless SSO** enabled or if you have a new tenant, where this option is enabled by default and can’t be turned off, Auth0 will show the login UI only if the user doesn’t have a session. There may or may not be other prompts as well like MFA or consent, but if no user interaction is required then the application will get the results immediately. Therefore, in most cases, applications don’t really check if the user is logged in into the identity provider: they just request an authentication.
+
+  Universal Login works by effectively delegating the authentication of a user; the user is redirected to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application. In most cases, when your application needs to authenticate the user, it will request authentication from the OIDC provider, Auth0, via an `/authorize` request. As you can see from the quickstart, the best approach to implementing this is to use one of the language-specific Auth0 SDKs or some third-party middleware applicable to your technology stack. How to actually do this depends on the SDK and application type used.
+
+  Once authenticated, and when using an OIDC authentication workflow, Auth0 will redirect the user back to your callback URL with an ID token or a code to fetch the ID token.
+
+  For OIDC, Auth0 returns profile information in the ID token in a structured claim format as defined by the OIDC specification. This means that custom claims added to ID Tokens must conform to a namespaced format to avoid possible collisions with standard OIDC claims. For example, if you choose the namespace `https://foo.com/` and you want to add a custom claim named myclaim, you would name the claim `https://foo.com/myclaim`, instead of `myclaim`.
+
+  By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. You can start off using a simple username and password, and with a simple toggle switch, you can add new features such as social login and multi-factor authentication. 
+
    
+
+
    
+  Integrate a second application
+
+  Next, we’ll see how easy it is to integrate Auth0 in your second application. If you run another quickstart, for example, to integrate a web application, you don’t have to do anything else. Running the second quickstart against the same tenant will configure SSO between your applications automatically. 
+
+  Let’s download another quickstart and see this in action.
+
+  This time around, I will select the Regular Web App application type and `asp.net core` sample. `Asp.net core` is a typical enterprise server side rendered web application framework.
+
+  The steps are the same as before: Select the application, set local development urls, download and run the sample.
+
+  After authenticating the user and redirecting them to an identity provider, you can check for active SSO sessions.
+
    
+
+## Up next
+
+
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+
    
diff --git a/ja-jp/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md b/ja-jp/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md
new file mode 100644
index 0000000000..9550161f31
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/05_01-authorize-id-tokens-access-control.md
@@ -0,0 +1,141 @@
+---
+description: What ID Tokens are and how you can add custom claims to customize them and make access control decisions for your users.
+classes: video-page
+public: false
+---
+
+# Authorize: ID Tokens and Access Control
+
+Learn about Auth0 authorization via the use of ID Tokens. Understand what an ID Token is, and learn how to add custom claims to customize tokens and make access control decisions for your users.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, you will see how to use custom ID Token claims to support specific authorization requirements in your application. 
+
+  As a refresher, if you’ve just seen the Authentication video, then you know that it’s important to correctly distinguish between Authentication, Authorization, and Access Control. Your Auth0 tenant is your Authorization Server and responsible for Authentication and some or all of Authorization, and sometimes some coarse-grained access control. In contrast, your application or API is responsible for most Access Control because most access control is contextual and too fine-grained for a central service to manage effectively.
+
    
+
+
    
+  Access restrictions
+
+  Auth0 allows you to apply coarse-grained access restrictions to certain applications or APIs using Rule extensibility or provide authorization information to an application through custom claims. For example: 
+
+  * You can return an `UnauthorizedError` from a Rule, allowing Auth0 to provide coarse-grained denial of access to an application if the user doesn’t have the right claim or claims in their user profile metadata.
+  * You can return an `UnauthorizedError` from a Rule, allowing Auth0 to provide coarse-grained denial of access to an API if a call is coming from a restricted application or location. 
+  * You can add additional or custom claims to an OIDC-compliant ID Token via  Auth0 Rule extensibility. That information will appear in the body or payload of the returned ID Token and can be used by your application, in combination with application specific data, for fine-grained access control. 
+
    
+
+
    
+  Apply different access restriction levels
+
+  We’ll talk about API level integration in a future video, but for now, we’ll concentrate on how Auth0 can be leveraged to provide for both coarse-grained and fine-grained application-level authorization.
+
+  First, you should decide if you require coarse-grained or fine-grained control. With coarse-grained control, you can use Auth0 extensibility to prevent allocation of an ID Token, thus denying access to the application overall. If you require fine-grained control, then you will need to decide what information your application requires in order to make access control decisions (for example the user may have a role associated with them or specific permissions associated with their profile). In this case, you can use Auth0 extensibility to add this information as custom claims to an ID Token, which can then be verified and used by the application, in combination with application specific data, to apply any access control restrictions. We recommend that you add this information to the user profile metadata, that way you don’t have to call an external API to fetch the information which could negatively impact the performance and scalability of the login sequence. 
+
+
    
+
+
    
+  Role Based Access Control
+
+  Additionally, Auth0 has out-of-box support for Role Based Access Control or RBAC. RBAC refers to assigning permissions to users based on their role within an organization. Use RBAC for simpler, fine-grained access control that is often less prone to error.
+
+  Be wary of adding too fine-grained detail to the user profile. Application specific access control data should live with the application, and not in the user profile. Trying to put all access control information in the user profile can quickly grow into a complicated system to maintain. Limit the authorization information stored against the user to apply to attributes about the user themselves, but not about individual items they can access. For example: if a user has access to a document repository, you could store the fact that the user is an administrator of the document repository application in the user’s app_metadata, but you wouldn’t want to store the specific documents the user has access to.
+
+  In the next video, we'll dig into some of the details on how authorization works with Auth0.
+
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+
    
+
diff --git a/ja-jp/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md b/ja-jp/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md
new file mode 100644
index 0000000000..bc933daba7
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/05_02-authorize-get-validate-id-tokens.md
@@ -0,0 +1,183 @@
+---
+description: How to get and validate ID Tokens before storing and using them.
+classes: video-page
+public: false
+---
+
+# Authorize: Get and Validate ID Tokens
+
+Learn how to get and validate an ID Token in JSON Web Token (JWT) format.
+
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+  In this video, we'll take a closer look at how authorization works, in Auth0, and we'll start by digging into ID Tokens. 
+
+  The ID Token contains user profile information, such as the user's name and email, represented in the form of claims. These claims are statements about the user, which can be trusted if you can verify its signature. 
+
+  You can get an ID Token for a user after they successfully authenticate and you must validate it before storing and using it. 
+
    
+
+
    
+  Obtain an ID Token
+
+  The first step is to obtain the ID token by authenticating the user. The previous video on authentication demonstrates how to do this. The best approach is to use your language specific SDK to redirect the user to your Auth0 tenant to authenticate the user. Then Auth0 will redirect the user back to your callback URL with the ID token (or a code to fetch the ID token).
+
+  You can then add custom claims to the token using Auth0 Rules as we mentioned. The claim name must conform to a namespaced format something similar to the following: 
+
+  `http://MY_NAMESPACE/CLAIM_NAME`
+  
+  Where `MY_NAMESPACE` is any domain except `auth0.com`, `webtask.io`, or `webtask.run`.  `CLAIM_NAME` can be anything you want. Some examples: `http://example.com/role` or `https://example.com/claims/locale`.
+
+  The ID Token acts as a *cache* for user information and by default, the token is valid for 36,000 seconds—or 10 hours. You can shorten this lifetime limit if you have security concerns. Remember, that the ID Token helps ensure optimal performance by reducing the need to contact the Identity Provider every time the user performs an action.
+
    
+
+
    
+  ID Token format
+
+  Auth0 generates the ID Token in JSON Web Token, or *JWT* format. A JWT is an open, industry standard RFC 7519 method for representing claims securely between two parties. At Auth0, ID Tokens are always returned in JWT format, and Access Tokens can be either JWT format or opaque strings depending on the context. 
+
+  A correctly formatted JWT consists of three concatenated base64url-encoded strings, separated by dots.
+
+  * The first string is the **Header** which contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+  * The second string is the **Body**, also called the *payload*, which contains identity claims about a user. Here’s where you will see any custom claims that you’ve added. Note that in cases where the JWT is returned via a URL, you need to make sure to limit the custom claims to keep the JWT within browser size limitations for URLs. The ID Token payload can contain some or all of the following items: name, email, picture, sub, issuer, audience, and expiration. 
+  * The third string contains the **Signature** which is used to validate that the token is trustworthy and has not been tampered with.
+
    
+
+
    
+  Check the ID Token
+
+  Next, we are going to walk through the three things your application will need to check for in the returned JWT. 
+
+  1. The JWT format is correct.
+  2. The contents contain the right claims
+  3. The signature is trustworthy. 
+
+  To check that the JWT format is correct, your application should parse the ID Token to make sure it conforms to the established structure of a JWT.  Your language specific SDK should have a method for validating the JWT.  Make sure this method actually checks the `aud`, `iss`, `exp`, and `nonce` (where applicable) claims, and validates the signature.
+
+  You can decode well-formed JWTs at using the [jwt.io](https://jwt.io) debugger to view the claims. 
+
    
+
+
    
+  Validate the ID Token claims
+
+  Next, you need to verify that the standard claims and any custom claims you’ve added are in the payload. Remember it should contain some or all of the following items (depending on which openid scopes you requested): `name`, `email`, `picture`, `nonce`, `sub`, `iss`, `aud`, and `exp`.
+
+  * Make sure the token expiration, named `exp`, which is a Unix timestamp, is set to be after the current date and time and matches what you require for token lifetime. 
+
+  * Make sure the token issuer, named `iss`, matches the issuing authority identified in your Auth0 tenant’s discovery document which you can find at `https://YOUR_DOMAIN/.well-known/openid-configuration`. 
+
+  * Make sure that the token audience, named `aud`, is the correct recipient for which the token is intended. The value must match the client ID of your Auth0 application.
+  
+  * The nonce claim is recommended (required for implicit flow) to pass in a single unique identifier when redirecting to Auth0 to authenticate, and helps in the prevention of replay attack scenarios.
+
+  * There are also other claims which are used in specific use case scenarios.
+
    
+
+
    
+  Verify the ID Token signature
+
+  To verify the ID Token’s signature, you will need to base64url-decode the signature. You can check the signing algorithm and confirm that the token is correctly signed using the proper key.  We recommend you use an SDK to validate the signature, and [jwt.io](https://jwt.io) provides a list of SDKs that can be used for this purpose.
+
    
+
+
    
+  Summary
+
+  Now that you have validated that the token is legitimate, you can use the custom claims you added to the token combined with your application data to perform fine-grained access control. 
+
+  We will go into more depth about API integration in a separate video, and in our next video, we’ll talk about how to manage user profiles. 
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/06-user-profiles.md b/ja-jp/articles/videos/get-started/06-user-profiles.md
new file mode 100644
index 0000000000..5556638b13
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/06-user-profiles.md
@@ -0,0 +1,211 @@
+---
+description: What user profiles are, what they contain, and how you can use them to manage users.
+classes: video-page
+title: Explore User Profiles
+public: false
+---
+
+# Explore User Profiles
+
+Learn what Auth0 User Profiles are used for and what they contain. Understand how Auth0 normalizes user profile data from various identity providers and uses metadata and root attributes. You can manage user profiles with the Auth0 Dashboard.  
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+Auth0 creates user profiles to contain information about your users such as name, email address, and last login. A user profile in Auth0 is essentially the cache of information obtained from an identity provider; together with any Auth0 specific information for a user—such as user metadata—the profile is stored in a user account record contained in the user account storage associated with an Auth0 tenant,
+
+Depending on which connections you choose, there will most likely be data formatting differences between various identity providers. It is also likely that there will be different information provided too. To compensate for this, Auth0 provides standardized user profile claims in what is referred to as the Normalized User Profile.
+
+Auth0 also provides a variety of tools in the Dashboard to help you manage certain aspects of a users’ profile. You can also use the Auth0 Management API to manage user profiles. You can use these tools to create, search, view, and delete users, and you can also define, manage, and store custom metadata too—unique profile attributes, which can hold information like favorite color, language preference, contact information, location, internal IDs, or access information.
+
    
+
+
    
+  How Auth0 uses user profiles, metadata, and root attributes
+
+Let’s now look at how Auth0 makes use of these user profiles.
+
+When a user logs in, Auth0 populates or updates the User Profile with data supplied by the identity provider. By default, there is one user profile created for each user identity.
+
+As discussed, Auth0 can store associated metadata with a user’s profile, that contains information such as language preferences or accessibility preferences that you can use to enhance your users’ experience with your application. There are two types of metadata available in Auth0: user metadata and app metadata. 
+
+* User Metadata is information that can be stored against a user profile and that a user can read/update as part of any self-service profile management. Metadata of this nature may be something like salutation for a user, or perhaps a user’s preferred language—used to customize the emails sent by Auth0. Any information that will be used to customize Auth0 emails—such as information used to determine the language for an email—should be stored in Metadata, and preferably user_metadata if the user is allowed to change it.
+
+* App Metadata is information that can be stored against a user profile but which can only be read or updated with appropriate authorization; app_metadata is not directly accessible to a user. Metadata of this nature might be something like a flag to indicate the last set of valid terms and conditions accepted by the user, and perhaps a date to indicate when the user accepted them.
+
+There are also user profile attributes that are updatable called *root attributes*. 
+
    
+
+
    
+  Use the Dashboard to manage user profile information
+
+You can use the Auth0 Dashboard to manage aspects of a user’s profile—such as metadata and root attributes—during your development process, but we recommend you don’t use the Dashboard to make changes in a production environment. Instead, you can use the Auth0 Management API to build your own management tool or integrate with any already built UI for Profile Management. Managing a user’s profile using the Dashboard is more of an administrative provision, however, it can be extremely useful during design and development, as it provides a simple way to manipulate user profiles while you make adjustments to how your application uses the data.
+
+Now we’ll show you a few of the management actions you can take with the user profile data and in what circumstances you can perform them.
+
    
+
+
    
+  Create a user
+
+First, let’s create a user to see how it works. 
+
+You can see that we’ve created a user called John Doe. Clicking on the user’s name (by default his/her email address) will allow us to view the user’s profile details. 
+
+In the main section, you’ll find essential data such as the user's email and login access information.
+
    
+
+
    
+  Metadata
+
+The next three sections on this page in the Dashboard are related to MFA, metadata, and identity provider attributes. Note that we’ll be covering MFA in a separate video. 
+
+In the **Metadata** section, you can see parts of the metadata you can modify. You can see fields for the two types of metadata: *user metadata* and *app metadata*.
+
+If you’re an Auth0 hosted subscriber, you can update selected root attributes which are name, given_name, family_name, nickname, and picture. Methods for updating root attributes vary depending on your connection type. 
+
+* If you are using Auth0 as the identity provider, you can set root attributes on user sign-up using the Management API, through public signup, or on import. Auth0 is the identity provider for regular database connections, custom database connections with import mode, and for passwordless connections.
+
+* If you are using an upstream identity provider such as Google or Facebook, the identity provider sets the root attributes when users are first created and then automatically updates them with each subsequent login. This is the default behavior. You can opt to have the identity provider set the root attributes on user creation only and not update them on subsequent logins, thereby allowing you to update them individually using the Management API. To enable this, you need to configure your connection sync with Auth0 in the dashboard. 
+
+Let’s walk through how to do this. Go to the Dashboard and click **Connections**. Let’s choose **Social** and choose **Google** for this example. 
+
+Click the name of the connection to see its settings.
+Toggle the **Sync user profile attributes at each login** to the setting you want and click **Save**. 
+
    
+
+
    
+  Root attributes
+
+Because user profile root attributes are a new feature in Auth0, we’ve made it easy for you to transition from using `user_metadata` in the old way. We built a Rule in the **Enrich Profile** rule category named **Move user_metadata attributes to profile root attributes**. When you use this, the rule moves the attribute from your old metadata to the appropriately named root attribute and removes it from the user_metadata. 
+
+Let’s look at this new Rule.
+
+Note that this rule will be executed on each login event. For signup scenarios, you should only consider using this rule if you currently use a custom signup form or Authentication Signup API, as these signup methods do not support setting the root attributes.
+
    
+
+
    
+  Other tabs in the Dashboard
+
+Now, let’s go back to our new user and walk through the other information you can view in the Dashboard.
+
+In the **Identity Provider Attributes** section you’ll find all the information retrieved from each identity provider.
+
+The **Devices** tab lists the devices with which the user has requested authentication. Authenticating via a device links the device to the user's account; login details for the user are associated with any Refresh Token assigned to that device. To revoke the Refresh Token, click Unlink next to the device.
+
+The History tab displays a log of the user's account activity for the past 2 days. The logs include information about:
+
+* Events that have occurred
+* When the events occurred
+* The apps associated with the events
+* The identity provider used for authentication
+* The originating IP addresses for the events
+* Where the events originated
+
+The **Raw JSON** tab displays all of the information contained on the user's profile in JSON format so you can quickly view all of the available information about the user.
+
+The **Authorized Applications** tab displays the applications that the user has been given permission to use. All users associated with a single Auth0 tenant are shared between the tenant's applications, and therefore have access to the applications. If you need to keep users separate and restrict their access to groups of applications, we recommend creating an additional tenant.
+
+The **Permissions** tab lists the permissions assigned to the user. You can assign permissions here.
+
    
+
+
    
+  Roles
+
+The **Roles** tab lists the roles assigned to the users. You create roles on another page and assign them here. The roles you create appear in the drop-down on this tab. 
+
+In the upper right corner of the User Details page, click the **Actions** button to see the list of actions you can perform. You can block or delete the user, send them a verification email, change their email address, and change their password. Note that you should never change a user’s password unless you have a system set up to force them to change it themselves the next time they log in, except in development or test environments. 
+
+In the next video, we’ll talk about how to brand your sign up, login, and password reset pages.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/07_01-brand-how-it-works.md b/ja-jp/articles/videos/get-started/07_01-brand-how-it-works.md
new file mode 100644
index 0000000000..64c99d14ab
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/07_01-brand-how-it-works.md
@@ -0,0 +1,150 @@
+---
+description: Why your branding is important for your users and how it works with Auth0.
+classes: video-page
+public: false
+---
+
+# Brand: How It Works
+
+Learn how branding works with Auth0. Add your company name and logo, and choose colors for your pages.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+The way your sign up and login pages look to your users makes a difference in their overall experience. If those pages have your company branding and URL, your customers will have peace of mind that your application can be trusted and is secure. 
+
+In this video, we’ll start by explaining what Auth0 Universal Login is and what it does for you, and then show you how easy it is to set up your branded pages.
+
    
+
+
    
+  How Universal Login works
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. Each time a user needs to prove their identity, your application redirects to your Auth0 tenant and Auth0 will do what's needed to verify the user's identity which often includes redirecting the user to the Universal Login Page to collect their credentials and/or provide them other options for login, such as social or enterprise identity providers.
+
+By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. When you customize the login page, the customizations you make will persist, even when you add new features such as social logins, and multi-factor authentication.
+
+You also benefit from all improvements Auth0 does in the login flow without you changing a single line of code in your application. 
+
    
+
+
    
+  Use the Dashboard to customize your pages
+
+The login page appearance and behavior is customizable right from the Dashboard. You can change the logo and colors of the login pages, and in more advanced use cases, you can modify the HTML code of each page. You can also customize the look of the URL used to navigate to the Universal Login page. Creating this *vanity URL* not only aligns with the idea of a consistent user experience, but also offers you complete control over the certificate management process, if you need it—so for example, you can use Extra Validation (EV) SSL certificates or similar to provide the visual, browser-based cues that offer your visitors additional peace of mind.
+
+Let’s see how this is done.
+
+First, we'll add a meaningful name to your application. Next, we'll configure the universal login settings, adding your company logo, then we'll specify a custom primary and background color. 
+
+Now we'll configure the tenant settings, specifying a friendly name, a logo, a support email and a support url.
+
+Next, we'll configure your custom vanity URL, by click on **Custom Domains** tab.
+
+Go back to the **Tenant Settings page** and click the **Custom Domains** tab. 
+
+1. Type in your custom domain URL—such as `accounts.acme.com`.
+2. Select **Auth0-managed certificates** and click **Add Domain**.
+3. Now you need to verify that you own that domain so you need to add the CNAME verification record listed in the Dashboard to your domain’s DNS record. Then click **Verify**. 
+
+The steps may vary by domain provider but it’s easy to verify your domain.
+
    
+
+
    
+  Summary
+
+There may be additional steps you have to complete depending on which Auth0 features you are using. For example, if you are using Auth0.js or one of the other SDKs, or if you are using G Suite connections, there are some additional domain name related steps you will need to take. We provide documentation on the Auth0/docs website to help you. 
+
+In the next video, we'll look at how to set up Universal Login.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/07_02-brand-signup-login-pages.md b/ja-jp/articles/videos/get-started/07_02-brand-signup-login-pages.md
new file mode 100644
index 0000000000..ed2a4cd9c8
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/07_02-brand-signup-login-pages.md
@@ -0,0 +1,140 @@
+---
+description: How to use Universal Login to customize your sign up and login pages. 
+classes: video-page
+public: false
+---
+
+# Brand: Sign Up and Login Pages
+
+Learn how to use Auth0’s Universal Login feature to customize your sign up and login pages to include your brand.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+In this video, we'll look at how you can setup Universal Login.
+
+In the Dashboard, you can see the settings for your login page by navigating to **Universal Login** and looking at the **Settings** tab.
+
    
+
+
    
+  Settings
+
+The settings available here are **Logo**, **Primary Color**, and **Background Color**. These settings once changed, will take effect on all pages where you have not enabled customization of the pages' code. Note that the settings will also work if you have enabled customization but assume you are using predefined templates and have not changed those options in the code.
+
+1. Add the URL to your logo image.
+2. Select a primary color.
+3. Select a background color.  
+
    
+
+
    
+  Customize login pages
+
+Now we’ll move to the **Login** tab and enable the login page customization. 
+
+Click the **Login** tab and toggle **Customize Login Page**.
+
+Note that when the customization toggle is flipped on, irrespective of the page you are customizing, you then become responsible for updates and maintenance of that page; it can no longer be automatically updated by Auth0. This includes updating the version numbers for any included Auth0 SDK or widget.
+
+If you have enabled customization to inspect the page code, and then decide not to customize your login page, you should make sure to disable the customize page—in this case the **Customize Login Page**—toggle, so Auth0 will render the default page. You can also use version control software to manage the source code of your pages. To do so, you can use an Auth0-provided extension that works with the version control system you're using, like GitHub for example. 
+
+You should also exercise caution regarding the use of third-party JavaScript on your pages—particularly the Login Page—since sensitive security-related information often flows through pages and the introduction of cross-site scripting or XSS vulnerabilities can be a concern.
+
    
+
+
    
+  Summary
+
+In the next video, we’ll talk about how to customize emails and error pages, and in a future video, we’ll talk about customizing the Guardian multi-factor authentication page too.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
      
+
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What an ID Token is and how you can add custom claims to make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+
    
diff --git a/ja-jp/articles/videos/get-started/08-brand-emails-error-pages.md b/ja-jp/articles/videos/get-started/08-brand-emails-error-pages.md
new file mode 100644
index 0000000000..81f7840e35
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/08-brand-emails-error-pages.md
@@ -0,0 +1,179 @@
+---
+description: How to use email templates and customize error pages. 
+classes: video-page
+public: false
+---
+
+# Brand: Emails and Error Pages
+
+Learn how to use Auth0 email templates and make changes to the reply email address, subject, redirect URL, and URL lifetime. You can configure your email provider and customize how verify emails look. Learn how to use your own error pages.
+
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+In the previous video we showed you how to add branding to your login pages using the universal login  Settings in the Auth0 Dashboard. In this video, we are going to show how easy it is to brand the rest of the things that your users might see, such as emails, and error pages.
+
    
+
+
    
+  Email templates
+
+First let’s take a look at email templates. 
+
+We’ll start by choosing a template to customize. In this example, we’ll work on the **Change Password** template. This is the email that will be sent whenever a user requests a password change; the password will not be changed until the user follows the link in the email. 
+
+Note that we enabled **Customize Password Reset Page** in the **Universal Login Password Reset** tab in the last video. If you haven’t done that yet, go ahead and do that now.
+
+Enter all the information into the fields to determine the reply email address, subject, redirect URL, and URL lifetime. Email templates in Auth0 support [Liquid syntax](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers), and allow you to include a number of Auth0 provided common variables 
+
+1. For the Reply Email Address, you can include any of the common variables like {{ application.name }}. For example: `{{ application.name }} `.  For this field, however, you can not use liquid syntax as part of the email address itself.
+
+2. For the Subject line, you can include any of the common variables like `{{ application.name }}` and `{{ user.email }}`. For example: Welcome to `{{ application.name }}!`.
+
+3. For the Redirect URL, enter the URL that you want the user to be redirected to after the action finishes. You can use the `{{ application.name }}` and `{{ application.callback_domain }}` variables. 
+
+4. The URL Lifetime default is set to 432,000 seconds which is 5 days. After that time has passed, the URL link will expire.
+
+5. Click Save.
+
+At the bottom, you can see the HTML code of message body. You can edit the HTML directly. You can also use common variables in the email message body. You can use liquid syntax in the body of the email to do everything—from just changing some of the text to be user specific, to using if/then statements to provide localization of the text. 
+
    
+
+
    
+  Custom email providers
+
+Now we will show you how easy it is to configure a custom email provider to use. In order to use a custom email template you will need to setup one of the out of box third-party email provider services, or provide credentials from any SMTP service that supports basic authentication. 
+
+You can use an external email provider to manage, monitor, and troubleshoot your email communications. It’s as simple as opening the right ports and whitelisting inbound connections from specific IP addresses. Auth0 currently supports the following providers:
+
+* Mandrill
+* Amazon SES
+* SendGrid
+* SparkPost
+* Or any Other SMTP provider (e.g., Gmail, Yahoo)
+
+Note that you can only configure one email provider, which will be used for all emails.
+
+You can also use your own SMTP server to send emails. This works well for testing your email templates without spamming your users. There are three requirements for the SMTP server:
+
+* It must support LOGIN authentication.
+* It must support TLS 1.0 or higher.
+* And It must use a certificate signed by a public certificate authority (CA).
+
+1. Open the **Custom Email Provider** page on the Auth0 Dashboard.
+2. Click on **Use my own Email Provider**.
+3. Click the **SMTP** logo.
+4. Enter your SMTP server Host, Port, Username and Password in the appropriate fields.
+5. Click **Save**.
+
+Common SMTP ports include 25 and 587. Port 25 is generally reserved for unencrypted traffic and so should not be used; this is particularly important for emails from Auth0 since they often contain sensitive information. 
+
+Now you can send a test email using the **SEND TEST EMAIL** button on the **Custom Email Provider** page of the Auth0 Dashboard. If you don't receive an email after a few minutes, check your dashboard logs for any failures.
+
    
+
+
    
+  Custom error pages
+
+Now we’re going to look at customizing error pages. 
+
+By default, if your users encounter any problems at sign up or log in, Auth0 provides generic error pages, that includes the support URL and support email address, that's entered right here.
+
+Down near the bottom of the page, under the **Error Pages** heading, you can select **Redirect users to your own error page** if desired
+
+Using your own error pages allows you to add your branding (not Auth0’s) and provide user information about what your users should do next. To do this, you simply enter the URL for your error page.  When Auth0 redirects users to your own error pages, additional query parameters will be included in your URL, which provides additional information about the error that was encountered.
+
+In the next video, we'll look at the user logout process.
+
    
+
+## Up next
+
+
      
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
+
    
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/10-logout.md b/ja-jp/articles/videos/get-started/10-logout.md
new file mode 100644
index 0000000000..ea9301a1de
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/10-logout.md
@@ -0,0 +1,177 @@
+---
+description: How to configure different kinds of user logout behavior using callback URLs.
+classes: video-page
+public: false
+---
+
+# Logout
+
+Learn about different kinds of logout behavior and different session layers. Learn how to configure callback URLs in the application and tenant settings in the Dashboard.
+
+
    
+
+## Video transcript
+
+
    
+  Introduction
+
+When we talk about logout in the context of Auth0 implementations, we are talking about the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties. 
+
+Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
+
    
+
+
    
+  Session layers
+
+There are typically three session layers that can be created when you login and the logout behavior you choose for your applications should make it clear to users which have terminated—ideally displaying a visual confirmation of this. 
+
+The first layer is the session inside your application or the *Application Session Layer*. Though your application uses Auth0 to authenticate users, you'll still need to track that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a cookie. 
+
+Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination. This will require you to utilize whatever application session stack you are using to clear out any session related information. Note that some of the Auth0 SDKs do provide some support for application sessions; please check the documentation to see if there is any local SDK session removal that needs to be done.
+
+Auth0 also maintains a session for the user and stores their information inside a cookie, this is the *Auth0 Session Layer*. This layer is used so that the next time a user is redirected to Auth0 for login the user's information will be remembered. You can log users out of the Auth0 session layer by redirecting them to the Auth0 logout endpoint so Auth0 can clear the (single sign-on; SSO) cookie.
+
+The last session layer is the *Identity Provider Session Layer*, for example, Facebook, Google or an Enterprise SAML provider. When users attempt to sign in using any of these providers, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in—though they may be asked to give permission to share their information with Auth0 and, in turn, your application. It is not necessary to log the users out of this session layer, but you can use Auth0 to force the logout if required. 
+
+Logging out of your Auth0 Session Layer will require you to redirect the user to `https:///v2/logout`—typically performed via use of the appropriate method in the Auth0 SDK for your technology stack. This will clear your Auth0 session. You will also want to add a query parameter for that request called `returnTo`—this parameter should contain a URL that has been pre-registered and protects you against open redirect attacks.  
+
    
+
+
    
+  Set whitelisted URLs
+
+Auth0 only redirects to whitelisted URLs after logout and there are two places you can configure these. 
+
+The first place you can set this is at the tenant level—this is where you can put the set of logout URLs that are common to (that is shared between) all applications. 
+
+The second place would be in the application settings: if you need different redirects for each application, you can whitelist the URLs in your application settings. This allows you to set logout URLs in an application-specific context. 
+
    
+
+
    
+  Session timeouts
+
+You can also set the behavior in cases where a user doesn’t explicitly logout of your application. Auth0 provides for session timeout to deal with Auth0 session termination in this scenario. We’ll cover the topic of session timeout in more detail in a future video.
+
    
+
+
    
+  Application-specific logout URLs
+There are two important things to consider when you use application-specific logout URLs:
+
+1. You MUST send client_id as a query parameter when calling the /v2/logout endpoint. and the returnTo URL must be in the application’s list of allowed logout URLs.
+
+2. This will end the Auth0 Session for the entire tenant, i.e. for all defined applications, not just the one that matches the client_id supplied!  Passing the client_id just tells the logout endpoint where to look for the logout URL white-list.
+
+In either place, under **Allowed LogoutURLs**, specify the logout URLs; you must include the protocol—either `http://` or, as we would recommend, `https://`—otherwise the call will fail. Https should always be used for production environments. The URLs provided in the Allowed Logout URLs list are also case-sensitive, so the URL used for logout must match the case of the logout URLs configured on the dashboard. However, do note that the scheme and host parts are case insensitive. For example, if your URL is `http://www.Example.Com/FooHoo.html`, the `http://www.Example.Com` portion is case insensitive, while the `FooHoo.html` portion is case sensitive.
+
+After the user logout occurs Auth0 will only redirect to a URL that is defined in this list. 
+
+Note that if you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out and, if desired, you can also warn them that they may still be logged into their identity provider.
+
    
+
+
    
+  Identity provider session layer logout
+
+Alternatively you may desire to also log the users out of the Identity Provider Session Layer; for many providers, Auth0 will give you this behavior by simply having you add the federated query parameter to the redirect to /v2/logout. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+There are a few limitations with logout to keep in mind:
+ 
+* No validation is performed on any URL provided as a value to the `returnTo` parameter, nor any querystring or hash information provided as part of the URL.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the `returnTo` parameter differently and for some, it will not work. Please check your social provider's settings to determine how it will behave.
+
+* If you are working with social identity providers such as Google or Facebook, you must set your Client ID and Secret for these providers in the Dashboard for the logout to function properly.
+
+* If you are an Auth0 Enterprise user, you will typically have SSO enabled for multiple applications, for example, SharePoint, a few .NET applications, a few Java applications, Zendesk, etc. In this case, it's very common that when users sign out, this needs to happen for all of their applications.  
+
+  However, redirecting users to the Auth0 log out endpoint does not currently cover all scenarios where users need to be signed out of all of the applications they use. Other than when Auth0 is using SAML, Auth0 does not natively support Single Logout. Single Logout can be achieved by having each application check the active session after their tokens expire, or you can force log out by terminating your application sessions at the application level. 
+
+  You can configure Single Logout URLs for SAML that can log out of all SAML sessions, although Auth0 supports front-channel SAML SLO only, Auth0 does not support back-channel SLO.
+
    
+
+
    
+  Summary
+
+Auth0 provides quickstart guides that show you how to implement logout functionality in your specific type of application and provides sample code. These quickstarts support native/mobile apps, single-page apps, and web apps. 
+
    
+
+## Previous videos
+
+
diff --git a/ja-jp/articles/videos/get-started/index.md b/ja-jp/articles/videos/get-started/index.md
new file mode 100644
index 0000000000..ae0f8f4e28
--- /dev/null
+++ b/ja-jp/articles/videos/get-started/index.md
@@ -0,0 +1,112 @@
+---
+description: Learn how to get started implementing Auth0 features with your applications.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/videos/get-started/get-started.png
+topics: 
+   - tenant architecture
+   - tenants
+   - provisioning
+   - user stores
+   - import users
+   - authorization
+   - authentication
+   - branding
+   - emails
+   - error pages
+   - logout
+   - user profiles
+public: false
+---
+# Get Started with Auth0 Video Series
+
+## Introduction
+
+
    
+
+
     
    
+
+
      
+  
    • 
+    8:33
+    
+    Architect: Your Tenant
+    
      What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
      
+  
      • 
+
+  
    • 
+    2:14
+    
+    Provision: User Stores
+    
      How user profiles are provisioned within an Auth0 tenant.
      
+  
      • 
+
+  
    • 
+    10:00
+    
+    Provision: Import Users
+    
      How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.
      
+  
      • 
+
+  
    • 
+    5:57
+    
+    Authenticate: How It Works
+    
      How user authentication works and various ways to accomplish it with Auth0.
      
+  
      • 
+
+  
    • 
+    7:01
+    
+    Authenticate: SPA Example
+    
      An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login. 
      
+  
      • 
+
+  
    • 
+    3:18
+    
+    Authorize: ID Tokens and Access Control
+    
      What ID Tokens are and how you can add custom claims to customize them and make access control decisions for your users. 
      
+  
      • 
+
+  
    • 
+    6:02
+    
+    Authorize: Get and Validate ID Tokens
+    
      How to get and validate ID Tokens before storing and using them. 
      
+  
      • 
+
+  
    • 
+    8:59
+    
+    User Profiles
+    
      What user profiles are, what they contain, and how you can use them to manage users. 
      
+  
      • 
+
+  
    • 
+    4:00
+    
+    Brand: How It Works
+    
      Why your branding is important for your users and how it works with Auth0. 
      
+  
      • 
+
+  
    • 
+    2:20
+    
+    Brand: Sign Up and Login Pages
+    
      How to use Universal Login to customize your sign up and login pages. 
      
+  
      • 
+
+  
    • 
+    5:42
+    
+    Brand: Emails and Error Pages
+    
      How to use email templates and customize error pages. 
      
+  
      • 
+
+  
    • 
+    8:12
+    
+    Logout
+    
      How to configure different kinds of user logout behavior using callback URLs. 
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/index.md b/ja-jp/articles/videos/index.md
new file mode 100644
index 0000000000..7d5ef5c972
--- /dev/null
+++ b/ja-jp/articles/videos/index.md
@@ -0,0 +1,32 @@
+---
+description: Learn about digital identity including OAuth2, OpenID Connect, calling APIs, and get started with your Auth0 Implementation.
+classes: video-page
+public: false
+---
+# Auth0 Videos
+
+## Learn Identity Series
+
+[Learn about digital identity](/videos/learn-identity) including OAuth2, OpenID Connect, calling APIs, and more! In this video series, we cover:
+
+* The history of modern identity and some of the foundational concepts and terminology
+* Protocols, open standards, SSO, JWTs, OAuth2, and OpenID Connect
+* Web application authentication
+* How to call an API with a web application
+* Native applications, including those for mobile, desktop, and command line use
+* Single-page applications
+
+## Get Started Series
+
+Check out the [Get Started](/videos/get-started) series of videos to learn the basics of implementing Auth0 features with your applications. In this video series, you can learn the following:
+
+* What an Auth0 tenant is
+* How Auth0 manages user information
+* How to move your existing users to an Auth0 user store  
+* The difference between authentication, authorization, and access control, and when and why you use each one
+* How Auth0's Universal Login feature works
+* How Auth0 authorization works using ID tokens
+* How to get and validate an ID token
+* How to manage users
+* How branding works with Auth0 for signup, login, emails, and error pages
+* How to configure how your users logout
diff --git a/ja-jp/articles/videos/learn-identity/01-introduction-to-identity.md b/ja-jp/articles/videos/learn-identity/01-introduction-to-identity.md
new file mode 100644
index 0000000000..4718aee76b
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/01-introduction-to-identity.md
@@ -0,0 +1,115 @@
+---
+description: A whirlwind tour of identity history, concepts, and terminology - protocols, open standards, SSO, OAuth2, OpenID Connect and more.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Introduction to Identity
+
+A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
+
+
    
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/02-oidc-and-oauth.md b/ja-jp/articles/videos/learn-identity/02-oidc-and-oauth.md
new file mode 100644
index 0000000000..9684482b63
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/02-oidc-and-oauth.md
@@ -0,0 +1,90 @@
+---
+description: OpenID Connect and OAuth specifications, roles, and grants.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# OpenID Connect and OAuth2
+
+OpenID Connect and OAuth specifications, roles and grants.
+
+
    
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/03-web-sign-in.md b/ja-jp/articles/videos/learn-identity/03-web-sign-in.md
new file mode 100644
index 0000000000..2a4385a506
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/03-web-sign-in.md
@@ -0,0 +1,123 @@
+---
+description: Authentication for web applications using OpenID Connect.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Web Sign-In
+
+Authentication for web applications using OpenID Connect.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 1: Web Sign-On](/identity-labs/01-web-sign-in)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/04-calling-an-api.md b/ja-jp/articles/videos/learn-identity/04-calling-an-api.md
new file mode 100644
index 0000000000..2b4de9ae1b
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/04-calling-an-api.md
@@ -0,0 +1,136 @@
+---
+description: How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Calling an API
+
+How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 2: Calling an API](/identity-labs/02-calling-an-api)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/05-desktop-and-mobile-apps.md b/ja-jp/articles/videos/learn-identity/05-desktop-and-mobile-apps.md
new file mode 100644
index 0000000000..7994284e33
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/05-desktop-and-mobile-apps.md
@@ -0,0 +1,129 @@
+---
+description: Authentication and delegated authorization for desktop and mobile applications and a public client overview.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Desktop and Mobile Apps
+
+Authentication and delegated authorization for desktop and mobile applications and a public client overview.
+
+
    
+
+## Related Identity Lab
+
+[ Lab 3: Mobile Applications](/identity-labs/03-mobile-native-app)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
    
+  
+
    
+
+
    Expand Links 
    
+
+## Up Next
+
+
      
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/06-single-page-apps.md b/ja-jp/articles/videos/learn-identity/06-single-page-apps.md
new file mode 100644
index 0000000000..b873dee324
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/06-single-page-apps.md
@@ -0,0 +1,117 @@
+---
+description: Authentication and delegated authorization for single page applications.
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+
+# Single Page Apps
+
+Authentication and delegated authorization for single page applications.
+
+
    
+
+[ Lab 4: Single-Page Applications](/identity-labs/04-single-page-app)
+
+## Jump to Section
+
+Jump to a section in the video for explanation on a specific topic.
+
+
+
+
    Expand Links 
    
+
+## Previous
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
    
diff --git a/ja-jp/articles/videos/learn-identity/index.md b/ja-jp/articles/videos/learn-identity/index.md
new file mode 100644
index 0000000000..a8a9a172d0
--- /dev/null
+++ b/ja-jp/articles/videos/learn-identity/index.md
@@ -0,0 +1,55 @@
+---
+description: Learn about digital identity including OAuth2, OpenID Connect, calling APIs, and more!
+classes: video-page
+image: https://cdn2.auth0.com/docs/media/articles/learn-identity/learn-identity-og-image.jpg
+public: false
+---
+# Learn Identity
+
+[![Learn Identity with Auth0](/media/articles/learn-identity/learn-identity-intro.jpg)](/videos/learn-identity/01-introduction-to-identity)
+
+
     
    
+
+
      
+  
    • 
+    48:54
+    
+    Introduction to Identity
+    
      A whirlwind tour of identity history, concepts, and terminology: protocols, open standards, SSO, OAuth2, OpenID Connect and more.
      
+  
      • 
+
+  
    • 
+    14:58
+    
+    OpenID Connect and OAuth2
+    
      OpenID Connect and OAuth specifications, roles, and grants.
      
+  
      • 
+
+  
    • 
+    34:56
+    
+    Web Sign-In
+    
      Authentication for web applications using OpenID Connect.
      
+  
      • 
+
+  
    • 
+    53:12
+    
+    Calling an API
+    
      How to obtain and use access and refresh tokens for delegated authorization in a traditional web application.
      
+  
      • 
+
+  
    • 
+    41:01
+    
+    Desktop and Mobile Apps
+    
      Authentication and delegated authorization for desktop and mobile applications and a public client overview.
      
+  
      • 
+
+  
    • 
+    37:29
+    
+    Single Page Apps
+    
      Authentication and delegated authorization for single page applications.
      
+  
      • 
+